All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cousson, Benoit" <b-cousson@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/7] ARM: OMAP2+: hwmod/timer: first set of cleanups for 3.4
Date: Tue, 31 Jan 2012 09:19:52 +0100	[thread overview]
Message-ID: <4F27A428.3020803@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1201310111300.10061@utopia.booyaka.com>

On 1/31/2012 9:14 AM, Paul Walmsley wrote:
> Hi
>
> On Tue, 31 Jan 2012, Cousson, Benoit wrote:
>
>> Thanks to the L3 log error:
>> [    0.838439] L3 custom error: MASTER:DucatiM3 TARGET:GPMC
>>
>> I guess that I understand why I was not releasing the hardreset at boot time
>> before:-)
>>
>> DSP and CortexM3 cannot be released from reset until someone loaded a firmware
>> in memory. Otherwise they will start executing some random instructions that
>> in this case are trying to access an area that is not accessible.
>>
>> We have to let the driver handle the hardreset because it is mainly used for
>> processors.
>
> Currently we're not asserting hardreset in the hwmod code during _reset().

Ooops, you're right we were talking about asserting the reset not 
de-asserting it.

> I had that patch in the series at some point, but took it out before
> posting it.  So maybe that might resolve this particular issue.  Also
> sounds like we should make sure that we keep the processor IPs in
> hardreset until some driver explicitly releases it; we'll need to make
> sure the code does that too.

So maybe in that case, this is because the reset line is already 
de-asserted by the fast boot and by enabling the clock we start 
executing some random code in the CortexM3... but this is still weird 
that this error was not happening before.

Regards,
Benoit

WARNING: multiple messages have this Message-ID (diff)
From: b-cousson@ti.com (Cousson, Benoit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/7] ARM: OMAP2+: hwmod/timer: first set of cleanups for 3.4
Date: Tue, 31 Jan 2012 09:19:52 +0100	[thread overview]
Message-ID: <4F27A428.3020803@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1201310111300.10061@utopia.booyaka.com>

On 1/31/2012 9:14 AM, Paul Walmsley wrote:
> Hi
>
> On Tue, 31 Jan 2012, Cousson, Benoit wrote:
>
>> Thanks to the L3 log error:
>> [    0.838439] L3 custom error: MASTER:DucatiM3 TARGET:GPMC
>>
>> I guess that I understand why I was not releasing the hardreset at boot time
>> before:-)
>>
>> DSP and CortexM3 cannot be released from reset until someone loaded a firmware
>> in memory. Otherwise they will start executing some random instructions that
>> in this case are trying to access an area that is not accessible.
>>
>> We have to let the driver handle the hardreset because it is mainly used for
>> processors.
>
> Currently we're not asserting hardreset in the hwmod code during _reset().

Ooops, you're right we were talking about asserting the reset not 
de-asserting it.

> I had that patch in the series at some point, but took it out before
> posting it.  So maybe that might resolve this particular issue.  Also
> sounds like we should make sure that we keep the processor IPs in
> hardreset until some driver explicitly releases it; we'll need to make
> sure the code does that too.

So maybe in that case, this is because the reset line is already 
de-asserted by the fast boot and by enabling the clock we start 
executing some random code in the CortexM3... but this is still weird 
that this error was not happening before.

Regards,
Benoit

  reply	other threads:[~2012-01-31  8:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 10:18 [PATCH 0/7] ARM: OMAP2+: hwmod/timer: first set of cleanups for 3.4 Paul Walmsley
2012-01-30 10:18 ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 1/7] ARM: OMAP2+: hwmod: control all hardreset lines attached to a hwmod Paul Walmsley
2012-01-30 10:18   ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 2/7] ARM: OMAP4: hwmod data: remove pseudo-hwmods associated with hardreset lines Paul Walmsley
2012-01-30 10:18   ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 3/7] ARM: OMAP2+: hwmod: ensure that SYSCONFIG bits are reprogrammed after a reset Paul Walmsley
2012-01-30 10:18   ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 4/7] ARM: OMAP2+: hwmod: provide a function to return the address space of the MPU RT Paul Walmsley
2012-01-30 10:18   ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 5/7] ARM: OMAP2+: hwmod: add omap_hwmod_get_mpu_irq() and omap_hwmod_get_mpu_rt_pa() Paul Walmsley
2012-01-30 10:18   ` Paul Walmsley
2012-01-30 17:13   ` Tony Lindgren
2012-01-30 17:13     ` Tony Lindgren
2012-01-30 21:36     ` Paul Walmsley
2012-01-30 21:36       ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 6/7] ARM: OMAP2+: timer: use a proper interface to get hwmod data Paul Walmsley
2012-01-30 10:18   ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 7/7] ARM: OMAP2+: hwmod: split the _setup() function Paul Walmsley
2012-01-30 10:18   ` Paul Walmsley
2012-01-30 23:14 ` [PATCH 0/7] ARM: OMAP2+: hwmod/timer: first set of cleanups for 3.4 Kevin Hilman
2012-01-30 23:14   ` Kevin Hilman
2012-01-30 23:36   ` Paul Walmsley
2012-01-30 23:36     ` Paul Walmsley
2012-01-31  8:05   ` Cousson, Benoit
2012-01-31  8:05     ` Cousson, Benoit
2012-01-31  8:14     ` Paul Walmsley
2012-01-31  8:14       ` Paul Walmsley
2012-01-31  8:19       ` Cousson, Benoit [this message]
2012-01-31  8:19         ` Cousson, Benoit

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=4F27A428.3020803@ti.com \
    --to=b-cousson@ti.com \
    --cc=khilman@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.