All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gerlach <d-gerlach@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX
Date: Mon, 16 Jun 2014 15:19:02 -0500	[thread overview]
Message-ID: <539F5136.60605@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1406160441150.26773@utopia.booyaka.com>

Paul,

On 06/15/2014 11:43 PM, Paul Walmsley wrote:
> Dave,
>
> On Mon, 9 Jun 2014, Dave Gerlach wrote:
>
>> am43xx reset register layout is more similar to am33xx than omap4 so
>> use the am33xx functions for hwmod hardreset soc_ops rather than the
>> currently used omap4 functions. Without this, assert_hardreset and
>> deassert_hardreset will not work on am43xx.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>>   arch/arm/mach-omap2/omap_hwmod.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>> index 66c60fe..1c0885b 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -4251,9 +4251,9 @@ void __init omap_hwmod_init(void)
>>   		soc_ops.enable_module = _omap4_enable_module;
>>   		soc_ops.disable_module = _omap4_disable_module;
>>   		soc_ops.wait_target_ready = _omap4_wait_target_ready;
>> -		soc_ops.assert_hardreset = _omap4_assert_hardreset;
>> -		soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
>> -		soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
>> +		soc_ops.assert_hardreset = _am33xx_assert_hardreset;
>> +		soc_ops.deassert_hardreset = _am33xx_deassert_hardreset;
>> +		soc_ops.is_hardreset_asserted = _am33xx_is_hardreset_asserted;
>>   		soc_ops.init_clkdm = _init_clkdm;
>>   	} else if (soc_is_am33xx()) {
>>   		soc_ops.enable_module = _am33xx_enable_module;
>
> Should AM43XX be using the _am33xx_{enable,disable}_module and
> wait_target_ready functions?

AM43xx has been using the _omap4_{enable,disable}_module functions 
without issue. Nothing is currently using the hardreset ops for am43xx 
which is why it went unnoticed but I saw the issue when I tried to use 
them for the wkup_m3 hwmod and they failed during internal development.

With that said, am43xx clockdomains have prcm_partition defined as part 
of their data which is only used by the _omap4_{enable,disable}_module 
functions and not the _am33xx functions so as the current configuration 
stands the _omap4 variants are the right choice.

Regards,
Dave

>
>
> - Paul
>


WARNING: multiple messages have this Message-ID (diff)
From: d-gerlach@ti.com (Dave Gerlach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX
Date: Mon, 16 Jun 2014 15:19:02 -0500	[thread overview]
Message-ID: <539F5136.60605@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1406160441150.26773@utopia.booyaka.com>

Paul,

On 06/15/2014 11:43 PM, Paul Walmsley wrote:
> Dave,
>
> On Mon, 9 Jun 2014, Dave Gerlach wrote:
>
>> am43xx reset register layout is more similar to am33xx than omap4 so
>> use the am33xx functions for hwmod hardreset soc_ops rather than the
>> currently used omap4 functions. Without this, assert_hardreset and
>> deassert_hardreset will not work on am43xx.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>>   arch/arm/mach-omap2/omap_hwmod.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>> index 66c60fe..1c0885b 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -4251,9 +4251,9 @@ void __init omap_hwmod_init(void)
>>   		soc_ops.enable_module = _omap4_enable_module;
>>   		soc_ops.disable_module = _omap4_disable_module;
>>   		soc_ops.wait_target_ready = _omap4_wait_target_ready;
>> -		soc_ops.assert_hardreset = _omap4_assert_hardreset;
>> -		soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
>> -		soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
>> +		soc_ops.assert_hardreset = _am33xx_assert_hardreset;
>> +		soc_ops.deassert_hardreset = _am33xx_deassert_hardreset;
>> +		soc_ops.is_hardreset_asserted = _am33xx_is_hardreset_asserted;
>>   		soc_ops.init_clkdm = _init_clkdm;
>>   	} else if (soc_is_am33xx()) {
>>   		soc_ops.enable_module = _am33xx_enable_module;
>
> Should AM43XX be using the _am33xx_{enable,disable}_module and
> wait_target_ready functions?

AM43xx has been using the _omap4_{enable,disable}_module functions 
without issue. Nothing is currently using the hardreset ops for am43xx 
which is why it went unnoticed but I saw the issue when I tried to use 
them for the wkup_m3 hwmod and they failed during internal development.

With that said, am43xx clockdomains have prcm_partition defined as part 
of their data which is only used by the _omap4_{enable,disable}_module 
functions and not the _am33xx functions so as the current configuration 
stands the _omap4 variants are the right choice.

Regards,
Dave

>
>
> - Paul
>

  reply	other threads:[~2014-06-16 20:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-09 20:59 [PATCH] ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX Dave Gerlach
2014-06-09 20:59 ` Dave Gerlach
2014-06-13 19:40 ` Paul Walmsley
2014-06-13 19:40   ` Paul Walmsley
2014-06-16  1:56   ` Paul Walmsley
2014-06-16  1:56     ` Paul Walmsley
2014-06-16 20:11     ` Dave Gerlach
2014-06-16 20:11       ` Dave Gerlach
2014-06-16  4:43 ` Paul Walmsley
2014-06-16  4:43   ` Paul Walmsley
2014-06-16 20:19   ` Dave Gerlach [this message]
2014-06-16 20:19     ` Dave Gerlach

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=539F5136.60605@ti.com \
    --to=d-gerlach@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.