All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benoit Cousson <bcousson@baylibre.com>
To: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>,
	tony@atomide.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 3/3] ARM: OMAP2+: Let DT say what devices should not to idled or reset
Date: Wed, 09 Oct 2013 10:19:01 +0200	[thread overview]
Message-ID: <52551175.3070705@baylibre.com> (raw)
In-Reply-To: <525507A4.9010308@ti.com>

Hi Rajendra,

On 09/10/2013 09:37, Rajendra Nayak wrote:
> On Wednesday 09 October 2013 12:54 PM, Paul Walmsley wrote:
>> Hi Benoît, Rajendra,
>>
>> On Tue, 20 Aug 2013, Rajendra Nayak wrote:
>>
>>> Now that we have DT bindings to specify which devices on the SoC should not
>>> be reset or idled, get rid of the same information existing as part of the
>>> hwmod data files and pass this info from DT instead.
>>>
>>> For GPMC, the HWMOD_INIT_NO_RESET flag seems to be added in hwmod not due to
>>> any errata around the GPMC IP, but rather because any timings
>>> set by the bootloader are not being correctly programmed by the kernel.
>>> This seems like something that needs to be fixed as part of GPMC driver
>>> in the kernel, and hence the flag is left as is in hwmod, which can be
>>> removed once the driver does what its expected to.
>>>
>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>> ---
>>>   arch/arm/boot/dts/am33xx.dtsi              |    2 ++
>>>   arch/arm/boot/dts/omap4.dtsi               |    3 +++
>>>   arch/arm/boot/dts/omap5.dtsi               |    2 ++
>>>   arch/arm/mach-omap2/omap_hwmod_33xx_data.c |    4 ++--
>>>   arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    4 +---
>>>   arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    2 --
>>>   6 files changed, 10 insertions(+), 7 deletions(-)
>>
>> Looking at this one, maybe the best thing for this patch is for Rajendra
>> to split it into two patches.  Benoît can merge the DTS patch first, then
>> I can merge the hwmod side as a cleanup once the first one goes in.  That
>> will avoid conflicts from other DTS and hwmod changes going into the tree.
>>
>> Rajendra, when you do the split, please add in the DT documentation part
>> from patch 2.  Am going to strip that out from the second patch and just
>> merge the hwmod changes.
>>
>> Sound good?
>
> Sure Paul, I'll repost the complete series with proper splits such that its
> easier for you and Benoit to pick them up independently.

If you could do it soon, I'm about to send an early pull request to Tony 
to avoid the trouble we had last time.

Thanks,
Benoit


WARNING: multiple messages have this Message-ID (diff)
From: bcousson@baylibre.com (Benoit Cousson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: OMAP2+: Let DT say what devices should not to idled or reset
Date: Wed, 09 Oct 2013 10:19:01 +0200	[thread overview]
Message-ID: <52551175.3070705@baylibre.com> (raw)
In-Reply-To: <525507A4.9010308@ti.com>

Hi Rajendra,

On 09/10/2013 09:37, Rajendra Nayak wrote:
> On Wednesday 09 October 2013 12:54 PM, Paul Walmsley wrote:
>> Hi Beno?t, Rajendra,
>>
>> On Tue, 20 Aug 2013, Rajendra Nayak wrote:
>>
>>> Now that we have DT bindings to specify which devices on the SoC should not
>>> be reset or idled, get rid of the same information existing as part of the
>>> hwmod data files and pass this info from DT instead.
>>>
>>> For GPMC, the HWMOD_INIT_NO_RESET flag seems to be added in hwmod not due to
>>> any errata around the GPMC IP, but rather because any timings
>>> set by the bootloader are not being correctly programmed by the kernel.
>>> This seems like something that needs to be fixed as part of GPMC driver
>>> in the kernel, and hence the flag is left as is in hwmod, which can be
>>> removed once the driver does what its expected to.
>>>
>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>> ---
>>>   arch/arm/boot/dts/am33xx.dtsi              |    2 ++
>>>   arch/arm/boot/dts/omap4.dtsi               |    3 +++
>>>   arch/arm/boot/dts/omap5.dtsi               |    2 ++
>>>   arch/arm/mach-omap2/omap_hwmod_33xx_data.c |    4 ++--
>>>   arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    4 +---
>>>   arch/arm/mach-omap2/omap_hwmod_54xx_data.c |    2 --
>>>   6 files changed, 10 insertions(+), 7 deletions(-)
>>
>> Looking at this one, maybe the best thing for this patch is for Rajendra
>> to split it into two patches.  Beno?t can merge the DTS patch first, then
>> I can merge the hwmod side as a cleanup once the first one goes in.  That
>> will avoid conflicts from other DTS and hwmod changes going into the tree.
>>
>> Rajendra, when you do the split, please add in the DT documentation part
>> from patch 2.  Am going to strip that out from the second patch and just
>> merge the hwmod changes.
>>
>> Sound good?
>
> Sure Paul, I'll repost the complete series with proper splits such that its
> easier for you and Benoit to pick them up independently.

If you could do it soon, I'm about to send an early pull request to Tony 
to avoid the trouble we had last time.

Thanks,
Benoit

  reply	other threads:[~2013-10-09  8:19 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20  7:32 [PATCH 0/3] OMAP: Add DT bindings to specify when devices should not be idled or reset Rajendra Nayak
2013-08-20  7:32 ` Rajendra Nayak
2013-08-20  7:32 ` [PATCH 1/3] ARM: OMAP2+: hwmod: cleanup HWMOD_INIT_NO_RESET usage Rajendra Nayak
2013-08-20  7:32   ` Rajendra Nayak
2013-08-20  7:32 ` [PATCH 2/3] ARM: OMAP2+: Add new bindings for OMAP Rajendra Nayak
2013-08-20  7:32   ` Rajendra Nayak
2013-08-21  7:45   ` Tony Lindgren
2013-08-21  7:45     ` Tony Lindgren
2013-08-21  8:47     ` Rajendra Nayak
2013-08-21  8:47       ` Rajendra Nayak
2013-08-21  8:53       ` Tony Lindgren
2013-08-21  8:53         ` Tony Lindgren
2013-08-21  9:22         ` Rajendra Nayak
2013-08-21  9:22           ` Rajendra Nayak
2013-08-21 12:23           ` Tony Lindgren
2013-08-21 12:23             ` Tony Lindgren
2013-08-21 12:39             ` Rajendra Nayak
2013-08-21 12:39               ` Rajendra Nayak
2013-08-21 12:44               ` Rajendra Nayak
2013-08-21 12:44                 ` Rajendra Nayak
2013-08-21 12:51               ` Tony Lindgren
2013-08-21 12:51                 ` Tony Lindgren
2013-08-21 13:12                 ` Benoit Cousson
2013-08-21 13:12                   ` Benoit Cousson
2013-08-21  9:29     ` Benoit Cousson
2013-08-21  9:29       ` Benoit Cousson
2013-08-21 11:49       ` Rajendra Nayak
2013-08-21 11:49         ` Rajendra Nayak
2013-08-20  7:32 ` [PATCH 3/3] ARM: OMAP2+: Let DT say what devices should not to idled or reset Rajendra Nayak
2013-08-20  7:32   ` Rajendra Nayak
2013-10-09  7:24   ` Paul Walmsley
2013-10-09  7:24     ` Paul Walmsley
2013-10-09  7:37     ` Rajendra Nayak
2013-10-09  7:37       ` Rajendra Nayak
2013-10-09  8:19       ` Benoit Cousson [this message]
2013-10-09  8:19         ` Benoit Cousson
2013-10-09  8:49         ` Rajendra Nayak
2013-10-09  8:49           ` 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=52551175.3070705@baylibre.com \
    --to=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=rnayak@ti.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.