From: skannan@codeaurora.org (Saravana Kannan)
To: linux-arm-kernel@lists.infradead.org
Subject: Locking in the clk API
Date: Thu, 20 Jan 2011 20:12:45 -0800 [thread overview]
Message-ID: <4D3907BD.4040900@codeaurora.org> (raw)
In-Reply-To: <AANLkTimwBruVgGQWs5NQG7U3PcF6RQHZ6Pd1hjxyGpcA@mail.gmail.com>
On 01/20/2011 06:06 PM, Dima Zavin wrote:
> On Thu, Jan 20, 2011 at 1:30 PM, Nicolas Pitre<nicolas.pitre@linaro.org> wrote:
>> On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:
>>
>>> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
>>>> I really don't like the fact that people are doing these things in
>>>> atomic contexts, and I think we should apply some pressure to move
>>>> the atomic caller cases to use systems where they can sleep such as
>>>> using threaded-irq handlers (they work very nicely)
>>>
>>> How do you ensure that printk is always called from a non-atomic
>>> context?
>>
>> Is this a good example? I don't think that power sensitive systems such
>> as a cellphone should keep printk() enabled in the final product. The
>> output from printk() over a serial port is a debugging convenience, and
>> trying to aggressively turn on/off the serial clock around each call to
>> printk() is a bit silly. Better simply turn the serial clock on
>> whenever its console facility is opened, and turn it off when the
>> console is closed, which should be good enough in that context.
[fixing top post]
> Here's a better one.
>
> Many devices use serial display panels sitting on either MDDI or MIPI
> links. The interface clocks need to be on, but they stay in low-power
> mode while the display is on. The display controller however does not
> need to be on since the serial panels typically have a local
> framebuffer that does the idle panel refresh on it's own. When a new
> frame comes in to be displayed, you need to clock on the display
> controller, DMA the data to the panel, and when it's done turn the
> controller off. The clk_enable may or may not happen at irq context,
> depending on whether or not you are starting the DMA from a
> vsync/tear-effect irq or simply from the screen_update() function. The
> clk_disable will most certainly happen from the DMA_DONE irq.
Why do we need to turn on the clock in the IRQ? Why not defer it to a
workqueue (or whatever is the method of the day to defer work from an
IRQ)? The advantage of doing the clk_enable in the IRQ should be
negligible compared to the time it takes to do the DMA.
In my opinion, the only major reason for needing atomic clk APIs was due
to device_ops->suspend being atomic. Since that's not the case anymore,
I really don't see a justification for atomic clocks. Sure, I might have
missed some exceptions, but in that case we should make the atomic APIs
an exception (add clk_enable_atomic) and not the norm.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2011-01-21 4:12 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 2:16 Locking in the clk API Jeremy Kerr
2011-01-11 3:15 ` Paul Mundt
2011-01-11 4:11 ` Jeremy Kerr
2011-01-11 4:54 ` Paul Mundt
2011-01-20 16:32 ` Ben Dooks
2011-01-20 18:57 ` Russell King - ARM Linux
2011-01-21 3:43 ` Saravana Kannan
2011-01-21 9:31 ` Russell King - ARM Linux
2011-01-11 9:03 ` Sascha Hauer
2011-01-11 9:28 ` Russell King - ARM Linux
2011-01-11 14:34 ` Pavel Machek
2011-01-20 16:29 ` Ben Dooks
2011-01-20 18:56 ` Russell King - ARM Linux
2011-01-20 21:30 ` Nicolas Pitre
2011-01-21 2:06 ` Dima Zavin
2011-01-21 4:12 ` Saravana Kannan [this message]
2011-01-21 9:32 ` Russell King - ARM Linux
2011-01-22 1:53 ` Saravana Kannan
2011-01-22 2:24 ` Colin Cross
2011-01-22 2:56 ` Saravana Kannan
2011-01-22 9:15 ` Russell King - ARM Linux
2011-01-24 19:31 ` Saravana Kannan
2011-01-21 21:03 ` Dima Zavin
2011-01-21 21:53 ` Nicolas Pitre
2011-01-21 22:02 ` Russell King - ARM Linux
2011-01-21 22:28 ` Colin Cross
2011-01-21 23:21 ` Benjamin Herrenschmidt
2011-01-21 23:50 ` Nicolas Pitre
2011-01-22 1:35 ` Saravana Kannan
2011-01-22 2:22 ` Colin Cross
2011-01-21 22:29 ` Nicolas Pitre
2011-01-21 23:28 ` Bryan Huntsman
2011-01-11 9:16 ` Russell King - ARM Linux
2011-01-11 9:44 ` Jeremy Kerr
2011-01-11 10:13 ` Paul Mundt
2011-01-11 10:30 ` Jeremy Kerr
2011-01-11 12:18 ` Paul Mundt
2011-01-11 13:52 ` Uwe Kleine-König
2011-01-11 14:35 ` Jeremy Kerr
2011-01-12 3:25 ` Saravana Kannan
2011-01-12 7:40 ` Uwe Kleine-König
2011-01-12 1:54 ` Saravana Kannan
2011-01-12 2:25 ` Paul Mundt
2011-01-20 16:57 ` Ben Dooks
2011-01-20 16:53 ` Ben Dooks
2011-01-20 16:40 ` Ben Dooks
2011-01-11 10:39 ` Uwe Kleine-König
2011-01-11 10:47 ` Russell King - ARM Linux
2011-01-11 10:56 ` Uwe Kleine-König
2011-01-11 11:15 ` Richard Zhao
2011-01-20 17:02 ` Ben Dooks
2011-01-20 19:08 ` Russell King - ARM Linux
2011-01-21 0:09 ` Jassi Brar
2011-01-21 4:47 ` Jassi Brar
2011-01-21 9:39 ` Russell King - ARM Linux
2011-01-21 10:11 ` Jassi Brar
2011-01-22 4:08 ` Richard Zhao
2011-01-22 5:30 ` Jassi Brar
2011-01-21 7:16 ` Saravana Kannan
2011-01-21 9:40 ` Russell King - ARM Linux
2011-01-22 1:47 ` Saravana Kannan
2011-01-27 4:34 ` Saravana Kannan
2011-01-27 8:54 ` Russell King - ARM Linux
2011-01-27 20:30 ` Saravana Kannan
2011-01-27 20:43 ` Russell King - ARM Linux
2011-01-27 21:07 ` Alan Cox
2011-01-27 21:11 ` Russell King - ARM Linux
2011-01-27 21:15 ` Russell King - ARM Linux
2011-01-28 3:29 ` Saravana Kannan
2011-01-28 3:27 ` Saravana Kannan
2011-01-11 12:11 ` Jassi Brar
2011-01-12 2:56 ` Saravana Kannan
2011-01-12 9:03 ` Russell King - ARM Linux
2011-01-15 14:02 ` Christer Weinigel
2011-01-15 14:53 ` Russell King - ARM Linux
2011-01-15 15:03 ` Uwe Kleine-König
2011-01-15 15:15 ` Russell King - ARM Linux
2011-01-15 16:03 ` Uwe Kleine-König
2011-01-15 16:21 ` Russell King - ARM Linux
2011-01-15 16:31 ` Uwe Kleine-König
2011-01-16 6:59 ` Grant Likely
2011-01-15 17:07 ` Christer Weinigel
2011-01-15 17:20 ` Russell King - ARM Linux
2011-01-15 17:44 ` Christer Weinigel
2011-01-15 20:30 ` Russell King - ARM Linux
2011-01-17 1:19 ` Jeremy Kerr
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=4D3907BD.4040900@codeaurora.org \
--to=skannan@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).