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 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 expensive,
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 cores
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
grand
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
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 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
- a
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
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 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
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 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'm
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 within
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 source from
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
mean.
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 device-tree is
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 feature
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 chaos
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 during
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: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 the idea
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 chips. I
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: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 to use
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 to
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_lookup
26 matches
Mail list logo
