From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Kevin Hilman <khilman@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>,
linux-omap@vger.kernel.org, paul@pwsan.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
Date: Wed, 16 May 2012 17:53:54 +0530 [thread overview]
Message-ID: <4FB39C5A.5080404@ti.com> (raw)
In-Reply-To: <4FB3707B.2080200@ti.com>
Kevin,
On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
> On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
>> Santosh,
>>
>> Tero Kristo <t-kristo@ti.com> writes:
>>
>>> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>
>>> GIC distributor control register has changed between CortexA9 r1pX and
>>> r2pX. The Control Register secure banked version is now composed of 2
>>> bits:
>>> bit 0 == Secure Enable
>>> bit 1 == Non-Secure Enable
>>> The Non-Secure banked register has not changed.
>>
>> For those without the r1pX TRM handy, please include what this look like
>> before (presumably 1 bit?) The changelog and in-code comments should
>> both be enhanced.
>>
> You are right. There was only one bit previously which was used for
> secure/non-secure mode. So ROM over-writes the non-secure bit
> accidentally.
>
>>> Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration
>>> will cause a problem to CPU0 Non-Secure SW.
>>
>> Please describe the problem, so we can better understand the specifics
>> of the workaround.
>>
Below is the updated changelog.
--------------
ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control
register change
With MPUSS programmed to OSWR(Open Switch retention), GIC context is
lost. On the CPU wakeup paths, ROM code gets executed which will setup
GIC secure configurations and restore the GIC context if it was saved
based on SAR_BACKUP_STATUS.
The ROM Code GIC distributor restoration is split in two parts:
CPU specific register done by each CPU and common register done by
only one CPU. If the GIC Distributor Control Register = 1, the
second CPU will not do the common GIC restoration.
GIC distributor control register has changed between CortexA9 r1pX and
r2pX. The Control Register secure banked version is now composed of 2
bits vs only one bit before r1px:
bit 0 == Secure Enable
bit 1 == Non-Secure Enable
Hence the value of Control register will be 3 and not 1 as the r1pX
based ROM code expects. So he CPU1 on it's wakeup ROM code path, will
go to the GIC initialization procedure and will so reset the full GIC
and NS GIC distributor Enable bit will get cleared.
Since the GIC distributor gets disabled in a live system, CPU1 will
hang because the interrupts stop firing.
Workaround for the issue:
1) Before doing the CPU1 wakeup, CPU0 must disable
the GIC distributor and wait for it to be enabled.
2) CPU1 must re-enable the GIC distributor on
it's wakeup path.
With this procedure, the GIC configuration done between the
CPU0 wakeup and CPU1 wakeup will not be lost but during this
short windows, the CPU0 will not receive interrupts.
The BUG is applicable to only OMAP4460(r2pX) devices.
OMAP4470(r2Px), ROM code is fixed for this BUG.
----------------
Let me know if it clarifies the issue ?
Regards
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change
Date: Wed, 16 May 2012 17:53:54 +0530 [thread overview]
Message-ID: <4FB39C5A.5080404@ti.com> (raw)
In-Reply-To: <4FB3707B.2080200@ti.com>
Kevin,
On Wednesday 16 May 2012 02:46 PM, Santosh Shilimkar wrote:
> On Wednesday 16 May 2012 03:14 AM, Kevin Hilman wrote:
>> Santosh,
>>
>> Tero Kristo <t-kristo@ti.com> writes:
>>
>>> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>
>>> GIC distributor control register has changed between CortexA9 r1pX and
>>> r2pX. The Control Register secure banked version is now composed of 2
>>> bits:
>>> bit 0 == Secure Enable
>>> bit 1 == Non-Secure Enable
>>> The Non-Secure banked register has not changed.
>>
>> For those without the r1pX TRM handy, please include what this look like
>> before (presumably 1 bit?) The changelog and in-code comments should
>> both be enhanced.
>>
> You are right. There was only one bit previously which was used for
> secure/non-secure mode. So ROM over-writes the non-secure bit
> accidentally.
>
>>> Since the ROM Code is based on the r1pX GIC, the CPU1 GIC restoration
>>> will cause a problem to CPU0 Non-Secure SW.
>>
>> Please describe the problem, so we can better understand the specifics
>> of the workaround.
>>
Below is the updated changelog.
--------------
ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control
register change
With MPUSS programmed to OSWR(Open Switch retention), GIC context is
lost. On the CPU wakeup paths, ROM code gets executed which will setup
GIC secure configurations and restore the GIC context if it was saved
based on SAR_BACKUP_STATUS.
The ROM Code GIC distributor restoration is split in two parts:
CPU specific register done by each CPU and common register done by
only one CPU. If the GIC Distributor Control Register = 1, the
second CPU will not do the common GIC restoration.
GIC distributor control register has changed between CortexA9 r1pX and
r2pX. The Control Register secure banked version is now composed of 2
bits vs only one bit before r1px:
bit 0 == Secure Enable
bit 1 == Non-Secure Enable
Hence the value of Control register will be 3 and not 1 as the r1pX
based ROM code expects. So he CPU1 on it's wakeup ROM code path, will
go to the GIC initialization procedure and will so reset the full GIC
and NS GIC distributor Enable bit will get cleared.
Since the GIC distributor gets disabled in a live system, CPU1 will
hang because the interrupts stop firing.
Workaround for the issue:
1) Before doing the CPU1 wakeup, CPU0 must disable
the GIC distributor and wait for it to be enabled.
2) CPU1 must re-enable the GIC distributor on
it's wakeup path.
With this procedure, the GIC configuration done between the
CPU0 wakeup and CPU1 wakeup will not be lost but during this
short windows, the CPU0 will not receive interrupts.
The BUG is applicable to only OMAP4460(r2pX) devices.
OMAP4470(r2Px), ROM code is fixed for this BUG.
----------------
Let me know if it clarifies the issue ?
Regards
Santosh
next prev parent reply other threads:[~2012-05-16 12:24 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 10:03 [PATCHv5 0/8] ARM: OMAP4: core retention support Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 1/8] ARM: OMAP4: suspend: Program all domains to retention Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-15 19:52 ` Kevin Hilman
2012-05-15 19:52 ` Kevin Hilman
2012-05-16 8:37 ` Tero Kristo
2012-05-16 8:37 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 2/8] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-15 21:44 ` Kevin Hilman
2012-05-15 21:44 ` Kevin Hilman
2012-05-16 8:54 ` Tero Kristo
2012-05-16 8:54 ` Tero Kristo
2012-05-16 9:16 ` Santosh Shilimkar
2012-05-16 9:16 ` Santosh Shilimkar
2012-05-16 12:23 ` Santosh Shilimkar [this message]
2012-05-16 12:23 ` Santosh Shilimkar
2012-05-16 16:51 ` Kevin Hilman
2012-05-16 16:51 ` Kevin Hilman
2012-05-17 6:46 ` Shilimkar, Santosh
2012-05-17 6:46 ` Shilimkar, Santosh
2012-05-17 17:15 ` Kevin Hilman
2012-05-17 17:15 ` Kevin Hilman
2012-05-18 6:05 ` Shilimkar, Santosh
2012-05-18 6:05 ` Shilimkar, Santosh
2012-05-18 14:13 ` Kevin Hilman
2012-05-18 14:13 ` Kevin Hilman
2012-05-16 12:31 ` Santosh Shilimkar
2012-05-16 12:31 ` Santosh Shilimkar
2012-05-14 10:03 ` [PATCHv5 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 5/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-29 19:32 ` Menon, Nishanth
2012-05-29 19:32 ` Menon, Nishanth
2012-05-30 8:02 ` Tero Kristo
2012-05-30 8:02 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 6/8] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-15 22:36 ` Kevin Hilman
2012-05-15 22:36 ` Kevin Hilman
2012-05-16 8:55 ` Tero Kristo
2012-05-16 8:55 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 7/8] ARM: OMAP4: PM: Add next_logic_state param to power_state Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-14 10:03 ` [PATCHv5 8/8] ARM: OMAP4: PM: Added option for enabling OSWR Tero Kristo
2012-05-14 10:03 ` Tero Kristo
2012-05-15 22:41 ` Kevin Hilman
2012-05-15 22:41 ` Kevin Hilman
2012-05-16 9:10 ` Tero Kristo
2012-05-16 9:10 ` Tero Kristo
2012-05-16 18:03 ` Kevin Hilman
2012-05-16 18:03 ` Kevin Hilman
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=4FB39C5A.5080404@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.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.