All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajendra Nayak <rnayak@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Date: Thu, 07 Jun 2012 16:22:45 +0530	[thread overview]
Message-ID: <4FD087FD.9040401@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1206070104060.6684@utopia.booyaka.com>

Hi Paul,

On Thursday 07 June 2012 12:37 PM, Paul Walmsley wrote:
> Hi
>
> On Thu, 7 Jun 2012, Rajendra Nayak wrote:
>
>> On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote:
>>> clkdm assocations with clocks in the clock framework are useful
>>> only for 'gate' clocks which have enable/disable ops populated.
>>> Get rid of the clkdm_names populated in any other type of clocks.
>
> I don't really see the point in changing this before the common clock
> conversion.  The design of most of the current low-level OMAP PM layers
> was predicated on each clock belonging to a clockdomain.  The testing
> overhead of changing this before the common clock conversion is something
> that I don't have time for, and almost no one else seems interested in
> doing.
>
> Your common clock conversion moots this patch anyway, right?

Yes, I can include this as part of the common clock conversion series.
What I was trying to say is that neither the clock framework not any
other OMAP PM layer today makes any use of this information except for
gate clocks. The only 2 places in the clock framework this is used is
in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which
are nops for non gate clocks.
So I don;t fully understand what you mean by our current low-level PM
design being based on this assumption that every clock belongs to a
clockdomain.
Did I miss anything else our PM frameworks do with the clock<->clkdm
association? The reason I am asking is because I am doing a lot of 
changes around based on this assumption and would really like to know
if I am missing something.

regards,
Rajendra

>
> - Paul
>


WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks
Date: Thu, 07 Jun 2012 16:22:45 +0530	[thread overview]
Message-ID: <4FD087FD.9040401@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1206070104060.6684@utopia.booyaka.com>

Hi Paul,

On Thursday 07 June 2012 12:37 PM, Paul Walmsley wrote:
> Hi
>
> On Thu, 7 Jun 2012, Rajendra Nayak wrote:
>
>> On Thursday 17 May 2012 03:54 PM, Rajendra Nayak wrote:
>>> clkdm assocations with clocks in the clock framework are useful
>>> only for 'gate' clocks which have enable/disable ops populated.
>>> Get rid of the clkdm_names populated in any other type of clocks.
>
> I don't really see the point in changing this before the common clock
> conversion.  The design of most of the current low-level OMAP PM layers
> was predicated on each clock belonging to a clockdomain.  The testing
> overhead of changing this before the common clock conversion is something
> that I don't have time for, and almost no one else seems interested in
> doing.
>
> Your common clock conversion moots this patch anyway, right?

Yes, I can include this as part of the common clock conversion series.
What I was trying to say is that neither the clock framework not any
other OMAP PM layer today makes any use of this information except for
gate clocks. The only 2 places in the clock framework this is used is
in omap2_dflt_clk_enable()/omap2_dflt_clk_disable() functions, which
are nops for non gate clocks.
So I don;t fully understand what you mean by our current low-level PM
design being based on this assumption that every clock belongs to a
clockdomain.
Did I miss anything else our PM frameworks do with the clock<->clkdm
association? The reason I am asking is because I am doing a lot of 
changes around based on this assumption and would really like to know
if I am missing something.

regards,
Rajendra

>
> - Paul
>

  reply	other threads:[~2012-06-07 10:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-17 10:24 [PATCH] ARM: omap: clock: Get rid of unwanted clkdm assocations within clks Rajendra Nayak
2012-05-17 10:24 ` Rajendra Nayak
2012-06-07  6:28 ` Rajendra Nayak
2012-06-07  6:28   ` Rajendra Nayak
2012-06-07  7:07   ` Paul Walmsley
2012-06-07  7:07     ` Paul Walmsley
2012-06-07 10:52     ` Rajendra Nayak [this message]
2012-06-07 10:52       ` Rajendra Nayak
2012-06-08  7:40       ` Paul Walmsley
2012-06-08  7:40         ` Paul Walmsley
2012-06-08  8:08         ` Rajendra Nayak
2012-06-08  8:08           ` Rajendra Nayak
2012-06-08 14:24           ` Paul Walmsley
2012-06-08 14:24             ` Paul Walmsley
2012-06-11  9:01             ` Rajendra Nayak
2012-06-11  9:01               ` Rajendra Nayak

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=4FD087FD.9040401@ti.com \
    --to=rnayak@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    /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.