On Sat, Aug 15, 2009 at 4:18 PM, Benjamin
Herrenschmidt wrote:
> For ppc we really don't have much of a choice here anyway because we
> support multiple platforms compiled in the same kernel as long as they
> have a CPU core that's the same overall family, and that can be very
> wide. For example,
On Sat, 2009-08-15 at 13:43 +0100, Russell King wrote:
> On Fri, Aug 14, 2009 at 10:07:44PM +1000, Benjamin Herrenschmidt wrote:
> > My idea is that struct clock would contain function pointers for the
> > enable/disable/get_rate/ etc... methods
>
> If you look at OMAP, doing that gets very expens
On Fri, Aug 14, 2009 at 10:07:44PM +1000, Benjamin Herrenschmidt wrote:
> My idea is that struct clock would contain function pointers for the
> enable/disable/get_rate/ etc... methods
If you look at OMAP, doing that gets very expensive, both in terms of
number of lines of code, size of structure
On Fri, 2009-08-14 at 13:29 +0200, Guennadi Liakhovetski wrote:
> but since they are quite long, in short, in them a patch has been
> discussed, that allowed to re-use an MMC driver, used on some MFDs, on
> SuperH SoCs. The patch was taking the "easy route" of adding the
> possibility to use the
On Fri, 14 Aug 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-13 at 16:59 +0800, Li Yang-R58472 wrote:
> > >Now, I know there is at least one person on earth
> > >contemplating sharing some drivers between PPC and ARM. I
> > >won't tell much more at this stage, but it makes sense in the
On Thu, 2009-08-13 at 16:59 +0800, Li Yang-R58472 wrote:
> >Now, I know there is at least one person on earth
> >contemplating sharing some drivers between PPC and ARM. I
> >won't tell much more at this stage, but it makes sense in the
> >grand scheme of things to see SoC vendors put similar IO
>Now, I know there is at least one person on earth
>contemplating sharing some drivers between PPC and ARM. I
>won't tell much more at this stage, but it makes sense in the
>grand scheme of things to see SoC vendors put similar IO cores
>into either PPC or ARM and providing that clock API is a
On Thu, 2009-08-13 at 00:40 +0100, Russell King wrote:
> Maybe - and since you're just starting to look at clkdev, I'll point
> out that it's actually not intuitive which way around the "wildcard"
> matching works in clkdev. The clk_get() arguments aren't the
> wildcards, they're in the clk_looku
> > Ok. So I may have misunderstood what names were for. In my mind, those
> > were the name of the clock input on the HW device :-)
>
> Oh, I do hope I didn't say that was wrong, because that is quite
> correct. What the idea with passing a NULL 'name' with drivers
> which only had one input was
On Thu, Aug 13, 2009 at 08:52:49AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 23:28 +0100, Russell King wrote:
>
> > On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> > > Maybe we can make clock-names non-optional though in the DT as an
> > > incentive not
> The problem is that you've got a chip which has a clock tree of its own
> which could benefit from using the clock API internally (in this case
> because it helps generalisation to the case where it's on the CPU for
> the MMC block to be able to just use the clock API for its clocks).
I see.
>
On Thu, Aug 13, 2009 at 08:32:53AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 23:20 +0100, Mark Brown wrote:
> > There was a recent thread on linux-kernel (last week) about the tmio_mmc
> > drivers - it's a MMC controller which is present in both some SH CPUs
> > and some MFD chi
On Wed, 2009-08-12 at 23:28 +0100, Russell King wrote:
> On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> > Maybe we can make clock-names non-optional though in the DT as an
> > incentive not to use the simple 1-clock "NULL" path.
>
> We used to pass names. Everyone got
On Wed, Aug 12, 2009 at 11:28:43PM +0100, Russell King wrote:
> We used to pass names. Everyone got the idea that they could ignore
> the struct device argument, and chaos ensued in drivers - people wanted
> to name each of their individual clk structures uniquely, and pass
> clock names, or even
On Wed, 2009-08-12 at 23:20 +0100, Mark Brown wrote:
> ...which is much easier if you discourage people from using the NULL
> name in the first place :)
Agreed.
> My concern is more about new device tree and
> older driver code than the other way round (which wouldn't suprise me,
> if only dur
On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> Maybe we can make clock-names non-optional though in the DT as an
> incentive not to use the simple 1-clock "NULL" path.
We used to pass names. Everyone got the idea that they could ignore
the struct device argument, and ch
On Thu, Aug 13, 2009 at 07:56:32AM +1000, Benjamin Herrenschmidt wrote:
> Maybe we can make clock-names non-optional though in the DT as an
> incentive not to use the simple 1-clock "NULL" path.
Yeah, that was more what I was thinking - apply some pressure on people
not to use the NULL clock feat
On Wed, 2009-08-12 at 22:44 +0100, Mark Brown wrote:
> On Thu, Aug 13, 2009 at 07:34:07AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
>
> > > What happens if another clock gets added or the list gets reordered for
> > > some reason?
>
> > The devi
On Thu, Aug 13, 2009 at 07:34:07AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
> > What happens if another clock gets added or the list gets reordered for
> > some reason?
> The device-tree is mostly static in that regard. I'm not sure what you
> me
On Wed, 2009-08-12 at 13:35 +0100, Mark Brown wrote:
> On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
>
> > - From the above, question: Do we want to keep that parent pointer ?
> > Does it make sense ? Will we have objects that are clock providers and
> > themselves sourc
On Wed, 2009-08-12 at 07:31 -1000, Mitch Bradley wrote:
> Padding a string violates a core principle of property representation,
> namely the "no alignment assumptions" one. The reason for that
> principle was the fact that alignment needs are not stable across
> processor families, or even wi
On Wed, 2009-08-12 at 08:40 -0500, Kumar Gala wrote:
> I'm in the same boat as you Josh. I think there is value and utility
> here but not sure what problem Ben's trying to solve.
Well, there's several things here.
First, it would be nice to improve clock management on some existing
SoCs. I'
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
> - Device-tree: The idea on top of my mind would be to define a
> clock-map property that has the following format:
>
> A list of:
>- zero terminated string clock ID, padded with zeros
> to a cell boundary
On Aug 12, 2009, at 6:19 AM, Josh Boyer wrote:
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt
wrote:
Hi folks !
(Russell, let us know if you want to dropped from the CC list, but I
felt you may have some useful input to provide here).
So I think it would be valuable to pro
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
> - From the above, question: Do we want to keep that parent pointer ?
> Does it make sense ? Will we have objects that are clock providers and
> themselves source from multiple parent ? Or we don't care and it becomes
That
On Wed, Aug 12, 2009 at 05:57:05PM +1000, Benjamin Herrenschmidt wrote:
>Hi folks !
>
>(Russell, let us know if you want to dropped from the CC list, but I
>felt you may have some useful input to provide here).
>
>So I think it would be valuable to provide the ARM clock API exposed by
>include/linu
On Wed, 2009-08-12 at 17:57 +1000, Benjamin Herrenschmidt wrote:
> - Device-tree: The idea on top of my mind would be to define a
> clock-map property that has the following format:
>
> A list of:
> - zero terminated string clock ID, padded with zeros
> to a cell boundary
>
Hi folks !
(Russell, let us know if you want to dropped from the CC list, but I
felt you may have some useful input to provide here).
So I think it would be valuable to provide the ARM clock API exposed by
include/linux/clk.h on various PowerPC embedded hardware.
However, that brings various iss
28 matches
Mail list logo
