From: Magnus Damm <magnus.damm@gmail.com>
To: Paul Mundt <lethal@linux-sh.org>, Greg KH <gregkh@suse.de>,
Daniel Mack <daniel@caiaq.de>,
linux-kernel@vger.kernel.org, hjk@linutronix.de,
magnus.damm@gmail.com
Subject: Re: [PATCH 1/2] UIO: add device clock support
Date: Fri, 26 Jun 2009 00:17:03 +0900 [thread overview]
Message-ID: <aec7e5c30906250817t486e7d2cr1d3b6718cc345cc9@mail.gmail.com> (raw)
In-Reply-To: <20090624184120.GA12953@linux-sh.org>
On Thu, Jun 25, 2009 at 3:41 AM, Paul Mundt<lethal@linux-sh.org> 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.
I wonder if it would be possible to enable the clock in open() and
stop the clock automatically from the ISR and use writenotify and/or
some kind of trapping mechanism to restart the clock when page faults
are received. If this works or not will probably vary from device to
device so it's probably not a good idea either.
Also, there may be some overlap with the Runtime PM code since this
seems more to be about stopping clocks than exposing frequencies to
user space.
Cheers,
/ magnus
next prev parent reply other threads:[~2009-06-25 15:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-24 15:30 Two small UIO patches Daniel Mack
2009-06-24 15:30 ` [PATCH 1/2] UIO: add device clock support Daniel Mack
2009-06-24 15:30 ` [PATCH 2/2] UIO: remove 'default n' from Kconfig Daniel Mack
2009-06-24 16:34 ` Greg KH
2009-06-24 18:32 ` Daniel Mack
2009-06-24 18:32 ` Greg KH
2009-06-24 16:34 ` [PATCH 1/2] UIO: add device clock support Greg KH
2009-06-24 18:29 ` Daniel Mack
2009-06-24 18:32 ` Greg KH
2009-06-24 18:41 ` Paul Mundt
2009-06-25 15:17 ` Magnus Damm [this message]
2009-06-25 17:47 ` Paul Mundt
2009-06-26 8:28 ` Magnus Damm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aec7e5c30906250817t486e7d2cr1d3b6718cc345cc9@mail.gmail.com \
--to=magnus.damm@gmail.com \
--cc=daniel@caiaq.de \
--cc=gregkh@suse.de \
--cc=hjk@linutronix.de \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®