Re: [PATCH 1/2] UIO: add device clock support

[Magnus Damm]

On Fri, Jun 26, 2009 at 2:47 AM, Paul Mundt<lethal@xxxxxxxxxxxx> wrote:
> On Fri, Jun 26, 2009 at 12:17:03AM +0900, Magnus Damm wrote:
>> On Thu, Jun 25, 2009 at 3:41 AM, Paul Mundt<lethal@xxxxxxxxxxxx> wrote:
>> > On Wed, Jun 24, 2009 at 09:34:14AM -0700, Greg KH wrote:
>> >> On Wed, Jun 24, 2009 at 05:30:24PM +0200, Daniel Mack wrote:
>> >> > Add a pointer to a 'struct clk' to uio_info. Drivers can set
>> >> > this pointer if a clock is needed, and the UIO core will care
>> >> > to enable and disable it upon device open and release.
>> >>
>> >> Do you have a UIO driver that needs this?
>> >>
>> >> If so, please submit it at the same time, otherwise adding
>> >> infrastructure for no driver that needs it, is pretty pointless.
>> >>
>> > We can use this for the uio_pdrv_genirq case on sh, but open/release is a
>> > bit coarse grained. Presently we default-enable clocks for devices that
>> > are handled through uio, so doing it at open/release is at least better
>> > than that. The other thing to consider is if we really want to add a
>> > HAVE_CLK depdendency outright, or just ifdef around it..
>>
>> Yeah, we export quite a few UIO devices on SuperH, and
>> stopping/starting clocks is on my TODO list.
>>
>> Like Paul says, open/release only is a bit coarse grained. I'd like to
>> be able to keep the device open in user space, having a bunch of
>> memory windows mmap()ed but still being able to power down the
>> hardware block somehow.
>>
>> The patch seems to be about enabling and disabling clocks, the actual
>> clock frequency is not really exposed to user space what I can tell. I
>> was more thinking along the lines of having an array of clocks per uio
>> device - pretty much like the memory windows - and just expose the
>> clocks and their frequencies to user space and letting user space
>> enable and disable using sysfs.
>>
> This is longer term work that still needs to be discussed and agreed
> upon, which is totally out of scope for this patch. Doing it at
> open/close time is already better than what we have today, so I am
> inclined to roll this patch in to a topic branch and convert the existing
> sh users over to it. Any improvement with regards to making it more fine
> grained, or deciding what to expose to userspace, is something to look at
> much later, particularly as the runtime pm code is going to be a
> prerequisite for a lot of it (ie, 2.6.33).

Performing clk_enable()/clk_disable() at open()/close() time sounds
good, but we probably also want to extend the uio_pdrv_genirq driver
to do clk_get()/clk_put() at probe()/remove() time well.

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