public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: rnayak@ti•com (Rajendra Nayak)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/2] OMAP2+: optional clock handling fixes
Date: Thu, 8 May 2014 12:29:51 +0530	[thread overview]
Message-ID: <536B2B67.9070808@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1405080000400.23579@utopia.booyaka.com>

On Thursday 08 May 2014 05:38 AM, Paul Walmsley wrote:
> Hi Rajendra,
> 
> On Wed, 23 Apr 2014, Rajendra Nayak wrote:
> 
>> The patches fix some opt clock handling in gpio and in
>> hwmod.
>>
>> Rajendra Nayak (2):
>>   gpio: omap: prepare and unprepare the debounce clock
>>   ARM: OMAP2+: hwmod: Don't leave the optional clocks in
>>     clk_prepare()ed state
>>
>>  arch/arm/mach-omap2/omap_hwmod.c |   13 ++-----------
>>  drivers/gpio/gpio-omap.c         |   10 +++++-----
>>  2 files changed, 7 insertions(+), 16 deletions(-)
> 
> Can these patches be merged separately?  Looks to me that the two options 
> are either to:
> 
> A. to merge them together, or 
> 
> B. to merge patch 1 first, then patch 2

Thats right.

> 
> Or will things break if only patch 1 is merged?

Things will break if only patch 2 is merged as gpios clk_enable()
request would fail. Merging only patch 1 has no issues.

> 
> 
> If we merge them together, I'd say the best situation would be to take 
> them through the OMAP tree, since the changes are all OMAP-specific.  In 
> that case we'll want an ack for the first patch from the GPIO maintainers, 
> Linus Walleij <linus.walleij@linaro•org> and Alexandre Courbot 
> <gnurou@gmail•com>.
> 
> Otherwise the path of least resistance would be (B) - you can get patch 1 
> merged via the GPIO tree.  The GPIO maintainers can then provide a 
> stable branch for us to base our changes on, or we can wait until the 
> change reaches Linus.  Then we can subsequently merge patch 2 via the  
> OMAP side.
> 
> Thoughts?

I am fine either way. I will check with Linus W. what he prefers. Thanks.

regards,
Rajendra
> 
> 
> - Paul
> 

      reply	other threads:[~2014-05-08  6:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23  6:11 [PATCH 0/2] OMAP2+: optional clock handling fixes Rajendra Nayak
2014-04-23  6:11 ` [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock Rajendra Nayak
2014-05-08  7:06   ` Rajendra Nayak
2014-05-08  9:26     ` Javier Martinez Canillas
2014-05-08 11:10       ` Rajendra Nayak
2014-05-08 12:04         ` Javier Martinez Canillas
2014-05-08 12:06           ` Rajendra Nayak
2014-05-13  9:24     ` Linus Walleij
2014-05-08 14:40   ` Santosh Shilimkar
2014-05-08 14:45   ` Santosh Shilimkar
2014-04-23  6:11 ` [PATCH 2/2] ARM: OMAP2+: hwmod: Don't leave the optional clocks in clk_prepare()ed state Rajendra Nayak
2014-05-08  0:08 ` [PATCH 0/2] OMAP2+: optional clock handling fixes Paul Walmsley
2014-05-08  6:59   ` Rajendra Nayak [this message]

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=536B2B67.9070808@ti.com \
    --to=rnayak@ti$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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