linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: Locking in the clk API
Date: Wed, 12 Jan 2011 08:40:09 +0100	[thread overview]
Message-ID: <20110112074009.GX24920@pengutronix.de> (raw)
In-Reply-To: <4D2D1F0D.5040208@codeaurora.org>

Hi Saravana,

On Tue, Jan 11, 2011 at 07:25:01PM -0800, Saravana Kannan wrote:
> On 01/11/2011 06:35 AM, Jeremy Kerr wrote:
> >Hi Paul,
> >
> >>Again, you are approaching it from the angle that an atomic clock is a
> >>special requirement rather than the default behaviour.
> >
> >I'm not considering it a special requirement, but it's still a requirement
> >(that the called function does not sleep).
> >
> >The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that
> >now you've made the caller need to know what kind of clock it has, or might
> >have one day.
> 
> I think it's just a matter of how you interpret the name of the API
> in English. It doesn't make the decision making of the developer any
> easier.
> 
> Just having a _atomic suffix doesn't mean the driver developer
> doesn't need to know what type of clock it is. They are still making
> the assumption that the enable/disable for that clock can be done
> atomically -- namely an "atomic clock".
But there is a difference to 'one function to rule both sleepable and
atomic clocks'.  When calling _atomic on a sleepable clock you get
-ESOMETHING back (and the clock stays off).  With a generic clk_enable
you get an oops and so cannot handle the error.

> Similarly, when a driver developer calls the _sleepable APIs in
> their code, for all practical purposes, they are making an
> assumption that the enable/disable for that clock *needs to* (not
> may) sleep.
IMHO this is not right.  If the driver developer doesn't care if the
clock sleeps or not (which is the norm I think) he calls the _sleepable
function and if the clock happen to be an atomic one it doesn't hurt
him.

And looking at the usage of the sleeping functions in the gpio API, I'd
bet that at least 50% of the calls to gpio_set_value can/should be
gpio_set_value_cansleep.  That's because driver developers don't care or
are not aware of the issue.  If it would be gpio_set_value
vs.gpio_set_value_atomic most developers would use the sleeping variant
and the few that should use the _atomic function would notice that when
seeing the corresponding oops.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  reply	other threads:[~2011-01-12  7:40 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
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 [this message]
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=20110112074009.GX24920@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --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).