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,
	tony@atomide.com, linux-gpio@vger.kernel.org
Subject: Re: [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
> 


WARNING: multiple messages have this Message-ID (diff)
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  7:01 UTC|newest]

Thread overview: 26+ 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 ` Rajendra Nayak
2014-04-23  6:11 ` [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock Rajendra Nayak
2014-04-23  6:11   ` Rajendra Nayak
2014-05-08  7:06   ` Rajendra Nayak
2014-05-08  7:06     ` Rajendra Nayak
2014-05-08  9:26     ` Javier Martinez Canillas
2014-05-08  9:26       ` Javier Martinez Canillas
2014-05-08 11:10       ` Rajendra Nayak
2014-05-08 11:10         ` Rajendra Nayak
2014-05-08 12:04         ` Javier Martinez Canillas
2014-05-08 12:04           ` Javier Martinez Canillas
2014-05-08 12:06           ` Rajendra Nayak
2014-05-08 12:06             ` Rajendra Nayak
2014-05-13  9:24     ` Linus Walleij
2014-05-13  9:24       ` Linus Walleij
2014-05-08 14:40   ` Santosh Shilimkar
2014-05-08 14:40     ` Santosh Shilimkar
2014-05-08 14:45   ` 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-04-23  6:11   ` Rajendra Nayak
2014-05-08  0:08 ` [PATCH 0/2] OMAP2+: optional clock handling fixes Paul Walmsley
2014-05-08  0:08   ` Paul Walmsley
2014-05-08  6:59   ` Rajendra Nayak [this message]
2014-05-08  6:59     ` 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=536B2B67.9070808@ti.com \
    --to=rnayak@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=tony@atomide.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.