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
prev parent reply other threads:[~2012-01-31 8:19 UTC|newest]
Thread overview: 15+ 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 ` [PATCH 1/7] ARM: OMAP2+: hwmod: control all hardreset lines attached to a hwmod 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 ` [PATCH 3/7] ARM: OMAP2+: hwmod: ensure that SYSCONFIG bits are reprogrammed after a reset 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 ` [PATCH 5/7] ARM: OMAP2+: hwmod: add omap_hwmod_get_mpu_irq() and omap_hwmod_get_mpu_rt_pa() Paul Walmsley
2012-01-30 17:13 ` Tony Lindgren
2012-01-30 21:36 ` Paul Walmsley
2012-01-30 10:18 ` [PATCH 7/7] ARM: OMAP2+: hwmod: split the _setup() function 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 23:14 ` [PATCH 0/7] ARM: OMAP2+: hwmod/timer: first set of cleanups for 3.4 Kevin Hilman
2012-01-30 23:36 ` Paul Walmsley
2012-01-31 8:05 ` Cousson, Benoit
2012-01-31 8:14 ` Paul Walmsley
2012-01-31 8:19 ` Cousson, Benoit [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=4F27A428.3020803@ti.com \
--to=b-cousson@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