All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajendra Nayak <rnayak@ti.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
Date: Tue, 26 Jun 2012 05:12:26 +0000	[thread overview]
Message-ID: <4FE941EA.7050108@ti.com> (raw)
In-Reply-To: <1340630090.3395.85.camel@deskari>

On Monday 25 June 2012 06:44 PM, Tomi Valkeinen wrote:
> venc and hdmi use clk_enable/disable in runtime PM callbacks (suspend&
> resume). If I understand correctly, the callbacks are not called in
> atomic context if pm_runtime_irq_safe() has not been used. And it is not
> used in omapdss.
>
> dsi uses clk_enable/disable in a different manner, but not in atomic
> context.
>
> So as far as I see, clocks are never handled in atomic context. Is
> everything related to the base clk stuff already in mainline? Can I take
> the clk_prepare/unprepare patch into my omapdss tree?

Well the Common Clk framework is already in mainline, but we still don;t
have CONFIG_COMMON_CLK enabled for our builds yet. So until we do so,
clk_prepare/unprepare will just be stubs which do nothing.
I will repost the patch getting rid of the clk_prepare/unprepare and
adding clk_prepare_enable/disable_unprepare instead.

>
>
> A question about clk_prepare/unprepare, not directly related: let's say
> I have a driver for some HW block. The driver doesn't use clk functions,
> but uses runtime PM. The driver also sets pm_runtime_irq_safe().
>
> Now, the driver can call pm_runtime_get_sync() in an atomic context, and
> this would lead to the underlying framework (hwmod, omap_device, I don't
> know who =) enabling the func clock for that HW. But this would happen
> in atomic context, so the underlying framework can't use clk_prepare.
>
> How does the underlying framework handle that case? (sorry if that's a
> stupid question =).

No, its not a stupid question at all. I have been thinking about this
too to figure out whats the best way to handle this. For now, the
patches I posted, do an early clk_prepare (like I did for dss) for all
hwmod clocks as I have no way to know which ones will have their
_enable, _idle etc called in atomic context. Maybe I should see if there
is a way I can do so only for those devices which end up calling a
pm_runtime_irq_safe() and not do it early for all.

>


WARNING: multiple messages have this Message-ID (diff)
From: Rajendra Nayak <rnayak@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: paul@pwsan.com, mturquette@ti.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
Date: Tue, 26 Jun 2012 10:30:26 +0530	[thread overview]
Message-ID: <4FE941EA.7050108@ti.com> (raw)
In-Reply-To: <1340630090.3395.85.camel@deskari>

On Monday 25 June 2012 06:44 PM, Tomi Valkeinen wrote:
> venc and hdmi use clk_enable/disable in runtime PM callbacks (suspend&
> resume). If I understand correctly, the callbacks are not called in
> atomic context if pm_runtime_irq_safe() has not been used. And it is not
> used in omapdss.
>
> dsi uses clk_enable/disable in a different manner, but not in atomic
> context.
>
> So as far as I see, clocks are never handled in atomic context. Is
> everything related to the base clk stuff already in mainline? Can I take
> the clk_prepare/unprepare patch into my omapdss tree?

Well the Common Clk framework is already in mainline, but we still don;t
have CONFIG_COMMON_CLK enabled for our builds yet. So until we do so,
clk_prepare/unprepare will just be stubs which do nothing.
I will repost the patch getting rid of the clk_prepare/unprepare and
adding clk_prepare_enable/disable_unprepare instead.

>
>
> A question about clk_prepare/unprepare, not directly related: let's say
> I have a driver for some HW block. The driver doesn't use clk functions,
> but uses runtime PM. The driver also sets pm_runtime_irq_safe().
>
> Now, the driver can call pm_runtime_get_sync() in an atomic context, and
> this would lead to the underlying framework (hwmod, omap_device, I don't
> know who =) enabling the func clock for that HW. But this would happen
> in atomic context, so the underlying framework can't use clk_prepare.
>
> How does the underlying framework handle that case? (sorry if that's a
> stupid question =).

No, its not a stupid question at all. I have been thinking about this
too to figure out whats the best way to handle this. For now, the
patches I posted, do an early clk_prepare (like I did for dss) for all
hwmod clocks as I have no way to know which ones will have their
_enable, _idle etc called in atomic context. Maybe I should see if there
is a way I can do so only for those devices which end up calling a
pm_runtime_irq_safe() and not do it early for all.

>


WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
Date: Tue, 26 Jun 2012 10:30:26 +0530	[thread overview]
Message-ID: <4FE941EA.7050108@ti.com> (raw)
In-Reply-To: <1340630090.3395.85.camel@deskari>

On Monday 25 June 2012 06:44 PM, Tomi Valkeinen wrote:
> venc and hdmi use clk_enable/disable in runtime PM callbacks (suspend&
> resume). If I understand correctly, the callbacks are not called in
> atomic context if pm_runtime_irq_safe() has not been used. And it is not
> used in omapdss.
>
> dsi uses clk_enable/disable in a different manner, but not in atomic
> context.
>
> So as far as I see, clocks are never handled in atomic context. Is
> everything related to the base clk stuff already in mainline? Can I take
> the clk_prepare/unprepare patch into my omapdss tree?

Well the Common Clk framework is already in mainline, but we still don;t
have CONFIG_COMMON_CLK enabled for our builds yet. So until we do so,
clk_prepare/unprepare will just be stubs which do nothing.
I will repost the patch getting rid of the clk_prepare/unprepare and
adding clk_prepare_enable/disable_unprepare instead.

>
>
> A question about clk_prepare/unprepare, not directly related: let's say
> I have a driver for some HW block. The driver doesn't use clk functions,
> but uses runtime PM. The driver also sets pm_runtime_irq_safe().
>
> Now, the driver can call pm_runtime_get_sync() in an atomic context, and
> this would lead to the underlying framework (hwmod, omap_device, I don't
> know who =) enabling the func clock for that HW. But this would happen
> in atomic context, so the underlying framework can't use clk_prepare.
>
> How does the underlying framework handle that case? (sorry if that's a
> stupid question =).

No, its not a stupid question at all. I have been thinking about this
too to figure out whats the best way to handle this. For now, the
patches I posted, do an early clk_prepare (like I did for dss) for all
hwmod clocks as I have no way to know which ones will have their
_enable, _idle etc called in atomic context. Maybe I should see if there
is a way I can do so only for those devices which end up calling a
pm_runtime_irq_safe() and not do it early for all.

>

  reply	other threads:[~2012-06-26  5:12 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22 13:47 [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk Rajendra Nayak
2012-06-22 13:47 ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 01/11] ARM: omap: clk: add clk_prepare and clk_unprepare Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 17:42   ` Pankaj Jangra
2012-06-22 17:42     ` Pankaj Jangra
2012-06-25  5:36     ` Rajendra Nayak
2012-06-25  5:36       ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 02/11] mmc: omap: " Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 18:23   ` S, Venkatraman
2012-06-22 18:23     ` S, Venkatraman
2012-06-22 18:34     ` Paul Walmsley
2012-06-22 18:34       ` Paul Walmsley
2012-06-25  5:25       ` Rajendra Nayak
2012-06-25  5:25         ` Rajendra Nayak
2012-06-25  6:18         ` Paul Walmsley
2012-06-25  6:18           ` Paul Walmsley
2012-06-25  7:13           ` Rajendra Nayak
2012-06-25  7:13             ` Rajendra Nayak
2012-06-25  5:32     ` Rajendra Nayak
2012-06-25  5:32       ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 03/11] hwrng: " Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 04/11] mfd: omap-usb: " Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 19:04   ` Paul Walmsley
2012-06-22 19:04     ` Paul Walmsley
2012-06-25  8:55     ` Munegowda, Keshava
2012-06-25  8:55       ` Munegowda, Keshava
2012-06-22 13:48 ` [PATCH 05/11] OMAPDSS: " Rajendra Nayak
2012-06-22 13:51   ` Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-25  6:07   ` Tomi Valkeinen
2012-06-25  6:07     ` Tomi Valkeinen
2012-06-25  6:07     ` Tomi Valkeinen
2012-06-25  6:59     ` Rajendra Nayak
2012-06-25  7:11       ` Rajendra Nayak
2012-06-25  6:59       ` Rajendra Nayak
2012-06-25  7:58       ` Tomi Valkeinen
2012-06-25  7:58         ` Tomi Valkeinen
2012-06-25  7:58         ` Tomi Valkeinen
2012-06-25 11:48         ` Rajendra Nayak
2012-06-25 11:52           ` Rajendra Nayak
2012-06-25 11:48           ` Rajendra Nayak
2012-06-25 13:14           ` Tomi Valkeinen
2012-06-25 13:14             ` Tomi Valkeinen
2012-06-25 13:14             ` Tomi Valkeinen
2012-06-26  5:00             ` Rajendra Nayak [this message]
2012-06-26  5:12               ` Rajendra Nayak
2012-06-26  5:00               ` Rajendra Nayak
2012-06-26  6:55               ` Tomi Valkeinen
2012-06-26  6:55                 ` Tomi Valkeinen
2012-06-26  6:55                 ` Tomi Valkeinen
2012-06-26  7:36                 ` Rajendra Nayak
2012-06-26  7:48                   ` Rajendra Nayak
2012-06-26  7:36                   ` Rajendra Nayak
2012-06-27  0:47             ` Mike Turquette
2012-06-27  0:47               ` Mike Turquette
2012-06-27  0:47               ` Mike Turquette
2012-06-27  4:19               ` Tomi Valkeinen
2012-06-27  4:19                 ` Tomi Valkeinen
2012-06-27  4:19                 ` Tomi Valkeinen
2012-06-27  5:19                 ` Rajendra Nayak
2012-06-27  5:31                   ` Rajendra Nayak
2012-06-27  5:19                   ` Rajendra Nayak
2012-06-25 11:22     ` Russell King - ARM Linux
2012-06-25 11:22       ` Russell King - ARM Linux
2012-06-25 11:22       ` Russell King - ARM Linux
2012-06-22 13:48 ` [PATCH 06/11] gpio/omap: " Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 15:57   ` Pankaj Jangra
2012-06-22 15:57     ` Pankaj Jangra
2012-06-22 19:17   ` Paul Walmsley
2012-06-22 19:17     ` Paul Walmsley
2012-06-25  5:30     ` Rajendra Nayak
2012-06-25  5:30       ` Rajendra Nayak
2012-06-25  6:11       ` DebBarma, Tarun Kanti
2012-06-25  6:11         ` DebBarma, Tarun Kanti
2012-06-25  7:02         ` Rajendra Nayak
2012-06-25  7:02           ` Rajendra Nayak
2012-06-25 10:22           ` DebBarma, Tarun Kanti
2012-06-25 10:22             ` DebBarma, Tarun Kanti
2012-06-22 13:48 ` [PATCH 07/11] w1: omap_hdq: " Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 18:35   ` Paul Walmsley
2012-06-22 18:35     ` Paul Walmsley
2012-06-25  5:25     ` Rajendra Nayak
2012-06-25  5:25       ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 08/11] crypto: omap: " Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 18:58   ` Paul Walmsley
2012-06-22 18:58     ` Paul Walmsley
2012-06-25  5:29     ` Rajendra Nayak
2012-06-25  5:29       ` Rajendra Nayak
2012-06-26 10:39       ` Paul Walmsley
2012-06-26 10:39         ` Paul Walmsley
2012-06-26 10:58         ` Rajendra Nayak
2012-06-26 10:58           ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 09/11] iommu: " Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 10/11] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-22 13:48 ` [PATCH 11/11] ARM: omap: clk: Remove all direct dereferencing of struct clk Rajendra Nayak
2012-06-22 13:48   ` Rajendra Nayak
2012-06-27 12:50 ` [PATCH 00/11] Prepare for OMAP2+ movement to Common Clk Laurent Pinchart
2012-06-27 12:50   ` Laurent Pinchart
2012-06-27 16:36   ` Paul Walmsley
2012-06-27 16:36     ` Paul Walmsley
2012-06-27 18:05     ` Laurent Pinchart
2012-06-27 18:05       ` Laurent Pinchart
2012-06-27 18:45       ` Laurent Pinchart
2012-06-27 18:45         ` Laurent Pinchart
2012-06-27 19:56         ` Laurent Pinchart
2012-06-27 19:56           ` Laurent Pinchart
2012-06-27 19:59         ` Paul Walmsley
2012-06-27 19:59           ` Paul Walmsley
2012-06-27 20:25           ` Laurent Pinchart
2012-06-27 20:25             ` Laurent Pinchart

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=4FE941EA.7050108@ti.com \
    --to=rnayak@ti.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.