lkml.org 
[lkml]   [2008]   [Mar]   [27]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
/
DateThu, 27 Mar 2008 13:08:37 +0300
FromDmitry <>
SubjectRe: [PATCH 1/3] Clocklib: add generic framework for managing clocks.
Hi,

2008/3/27, Haavard Skinnemoen <haavard.skinnemoen@atmel.com>:
> [domen.puncer@telargo.com keeps bouncing on me, removed from Cc]
>
>  On Thu, 27 Mar 2008 09:33:01 +0000
>
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
>
> > On Thu, Mar 27, 2008 at 10:26:48AM +0100, Haavard Skinnemoen wrote:
>  > > You can extend the struct, put the rate there and use the same
>  > > getrate() function for all the clocks that need to keep track of the
>  > > current rate this way.
>  >
>  > Well, if you're really concerned about size, you could do what I did with
>  > PXA and introduce a struct clk_ops to contain all the constant function
>  > pointers, rather than mashing the function pointers together - which
>  > saves far more than trying to combine them.
>
>
> I don't see what this has to do with the paragraph you quoted, but
>  yeah, good point. I don't think it should be used as an excuse for
>  filling up struct clk with platform-specific crap, however.
>
>  So how about something like this?
>
>  struct clk_ops {
>         struct module   *owner;
>
>
>         int (*can_get)  (struct clk *, struct device *);
>         int (*set_parent) (struct clk *, struct clk *);
>
>         int (*enable)   (struct clk *);
>         void (*disable) (struct clk *);
>
>         unsigned long (*getrate) (struct clk*);
>
>         int (*setrate)  (struct clk *, unsigned long);
>
>         long (*roundrate) (struct clk *, unsigned long);
>
> };
>
>
>  struct clk {
>         struct list_head node;
>         struct clk      *parent;
>
>         const char      *name;
>
>         int             users;
>
>         const struct clk_ops *ops;
>  };

I like this idea! This would also allow to cleanup the references code, etc.
Also after I saw such refactored struct clk, I thought that it looks
nearly like kobject. Maybe we should switch to the kobject-based
structs? What do you think?

-- 
With best wishes
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2008-03-27 10:11    [W:0.793 / U:0.130 seconds]
©2003-2008 Jasper Spaans