From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Tony Lindgren <tony@atomide.com>
Cc: Sekhar Nori <nsekhar@ti.com>, Felipe Balbi <balbi@ti.com>,
Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
Nishanth Menon <nm@ti.com>
Subject: Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
Date: Wed, 9 Jul 2014 10:06:59 -0400 [thread overview]
Message-ID: <53BD4C83.7020700@ti.com> (raw)
In-Reply-To: <20140707134008.GU3705@n2100.arm.linux.org.uk>
On Monday 07 July 2014 09:40 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 07, 2014 at 05:39:26AM -0700, Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [140707 05:17]:
>>> On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
>>>> OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
>>>> does not have this register. So unless there is a ROM API that was
>>>> introduced after OMAP4430, this would not be there even for other
>>>> OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.
>>>>
>>>> Before creating the patch, I checked with ROM team handling AM437x and
>>>> they denied an API to write to this register was present in AM437x ROM.
>>>
>>> Okay, so why are we trying to write to this register then...
>>>
>>> Ah, we have a bug in cache-l2x0.c:
>>>
>>> #define L2X0_CACHE_ID_PART_MASK (0xf << 6)
>>> #define L2X0_CACHE_ID_RTL_MASK 0x3f
>>> #define L310_CACHE_ID_RTL_R3P0 0x05
>>>
>>> unsigned rev = readl_relaxed(base + L2X0_CACHE_ID) & L2X0_CACHE_ID_PART_MASK;
>>>
>>> if (rev >= L310_CACHE_ID_RTL_R2P0) {
>>> ...
>>> if (rev >= L310_CACHE_ID_RTL_R3P0) {
>>> l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN | L310_STNDBY_MODE_EN,
>>> base, L310_POWER_CTRL);
>>>
>>> So, because we're masking the wrong bits, we end up with these tests
>>> always succeeding.
>>>
>>> So that's a NACK for the original patch, it's the wrong fix. The
>>> right fix is to avoid writing this register by fixing the RTL masking.
>>
>> Okie dokie, dropping the omap specific fix.
>
> Here's the revision mask fix - with the existing code, the revision checks
> are all useless since they would all pass irrespective of the actual
> revision. (Had the L2C series been better tested rather than being largely
> ignored, this may have been noticed before it was merged...) Anyway, what
> isn't clear from Sekhar's message is which revision L2C310 is in the AM437x.
>
Sorry for joining late on the thread. Yes the power control register API
isn't provided and write should be avoiding.
> From: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> Subject: [PATCH] ARM: l2c: fix revision checking
>
> The revision checking in l2c310_enable() was not correct; we were
> masking the part number rather than the revision number. Fix this
> to use the correct macro.
>
> Fixes: 4374d64933b1 ("ARM: l2c: add automatic enable of early BRESP")
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
Right. Feel free add my ack if you need one.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> arch/arm/mm/cache-l2x0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 948f12cf6180..0b5068256baf 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -732,7 +732,7 @@ static int l2c310_cpu_enable_flz(struct notifier_block *nb, unsigned long act, v
>
> static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned num_lock)
> {
> - unsigned rev = readl_relaxed(base + L2X0_CACHE_ID) & L2X0_CACHE_ID_PART_MASK;
> + unsigned rev = readl_relaxed(base + L2X0_CACHE_ID) & L2X0_CACHE_ID_RTL_MASK;
> bool cortex_a9 = read_cpuid_part() == ARM_CPU_PART_CORTEX_A9;
>
> if (rev >= L310_CACHE_ID_RTL_R2P0) {
>
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
Date: Wed, 9 Jul 2014 10:06:59 -0400 [thread overview]
Message-ID: <53BD4C83.7020700@ti.com> (raw)
In-Reply-To: <20140707134008.GU3705@n2100.arm.linux.org.uk>
On Monday 07 July 2014 09:40 AM, Russell King - ARM Linux wrote:
> On Mon, Jul 07, 2014 at 05:39:26AM -0700, Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [140707 05:17]:
>>> On Mon, Jul 07, 2014 at 05:20:27PM +0530, Sekhar Nori wrote:
>>>> OMAP4430 had L2 cache controller version r2p0 (per the public TRM) which
>>>> does not have this register. So unless there is a ROM API that was
>>>> introduced after OMAP4430, this would not be there even for other
>>>> OMAP4s. Public TRM of OMAP4470 does not indicate an API for this.
>>>>
>>>> Before creating the patch, I checked with ROM team handling AM437x and
>>>> they denied an API to write to this register was present in AM437x ROM.
>>>
>>> Okay, so why are we trying to write to this register then...
>>>
>>> Ah, we have a bug in cache-l2x0.c:
>>>
>>> #define L2X0_CACHE_ID_PART_MASK (0xf << 6)
>>> #define L2X0_CACHE_ID_RTL_MASK 0x3f
>>> #define L310_CACHE_ID_RTL_R3P0 0x05
>>>
>>> unsigned rev = readl_relaxed(base + L2X0_CACHE_ID) & L2X0_CACHE_ID_PART_MASK;
>>>
>>> if (rev >= L310_CACHE_ID_RTL_R2P0) {
>>> ...
>>> if (rev >= L310_CACHE_ID_RTL_R3P0) {
>>> l2c_write_sec(L310_DYNAMIC_CLK_GATING_EN | L310_STNDBY_MODE_EN,
>>> base, L310_POWER_CTRL);
>>>
>>> So, because we're masking the wrong bits, we end up with these tests
>>> always succeeding.
>>>
>>> So that's a NACK for the original patch, it's the wrong fix. The
>>> right fix is to avoid writing this register by fixing the RTL masking.
>>
>> Okie dokie, dropping the omap specific fix.
>
> Here's the revision mask fix - with the existing code, the revision checks
> are all useless since they would all pass irrespective of the actual
> revision. (Had the L2C series been better tested rather than being largely
> ignored, this may have been noticed before it was merged...) Anyway, what
> isn't clear from Sekhar's message is which revision L2C310 is in the AM437x.
>
Sorry for joining late on the thread. Yes the power control register API
isn't provided and write should be avoiding.
> From: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: [PATCH] ARM: l2c: fix revision checking
>
> The revision checking in l2c310_enable() was not correct; we were
> masking the part number rather than the revision number. Fix this
> to use the correct macro.
>
> Fixes: 4374d64933b1 ("ARM: l2c: add automatic enable of early BRESP")
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
Right. Feel free add my ack if you need one.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> arch/arm/mm/cache-l2x0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 948f12cf6180..0b5068256baf 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -732,7 +732,7 @@ static int l2c310_cpu_enable_flz(struct notifier_block *nb, unsigned long act, v
>
> static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned num_lock)
> {
> - unsigned rev = readl_relaxed(base + L2X0_CACHE_ID) & L2X0_CACHE_ID_PART_MASK;
> + unsigned rev = readl_relaxed(base + L2X0_CACHE_ID) & L2X0_CACHE_ID_RTL_MASK;
> bool cortex_a9 = read_cpuid_part() == ARM_CPU_PART_CORTEX_A9;
>
> if (rev >= L310_CACHE_ID_RTL_R2P0) {
>
next prev parent reply other threads:[~2014-07-09 14:07 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 10:34 [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting Sekhar Nori
2014-06-17 10:34 ` Sekhar Nori
2014-06-17 13:19 ` Felipe Balbi
2014-06-17 13:19 ` Felipe Balbi
2014-07-01 19:47 ` Felipe Balbi
2014-07-01 19:47 ` Felipe Balbi
2014-07-02 8:11 ` Tony Lindgren
2014-07-02 8:11 ` Tony Lindgren
2014-07-07 10:47 ` Tony Lindgren
2014-07-07 10:47 ` Tony Lindgren
2014-07-07 10:49 ` Russell King - ARM Linux
2014-07-07 10:49 ` Russell King - ARM Linux
2014-07-07 11:02 ` Tony Lindgren
2014-07-07 11:02 ` Tony Lindgren
2014-07-07 11:50 ` Sekhar Nori
2014-07-07 11:50 ` Sekhar Nori
2014-07-07 12:15 ` Russell King - ARM Linux
2014-07-07 12:15 ` Russell King - ARM Linux
2014-07-07 12:39 ` Tony Lindgren
2014-07-07 12:39 ` Tony Lindgren
2014-07-07 13:40 ` Russell King - ARM Linux
2014-07-07 13:40 ` Russell King - ARM Linux
2014-07-07 15:10 ` Felipe Balbi
2014-07-07 15:10 ` Felipe Balbi
2014-07-08 4:54 ` Sekhar Nori
2014-07-08 4:54 ` Sekhar Nori
2014-07-08 8:29 ` Tony Lindgren
2014-07-08 8:29 ` Tony Lindgren
2014-07-09 9:25 ` Tony Lindgren
2014-07-09 9:25 ` Tony Lindgren
2014-07-09 12:26 ` Sekhar Nori
2014-07-09 12:26 ` Sekhar Nori
2014-07-09 12:31 ` Tony Lindgren
2014-07-09 12:31 ` Tony Lindgren
2014-07-09 12:39 ` Russell King - ARM Linux
2014-07-09 12:39 ` Russell King - ARM Linux
2014-07-09 14:15 ` Santosh Shilimkar
2014-07-09 14:15 ` Santosh Shilimkar
2014-07-14 10:46 ` Sekhar Nori
2014-07-14 10:46 ` Sekhar Nori
2014-07-09 13:55 ` Felipe Balbi
2014-07-09 13:55 ` Felipe Balbi
2014-07-14 10:41 ` Sekhar Nori
2014-07-14 10:41 ` Sekhar Nori
2014-07-09 13:51 ` Felipe Balbi
2014-07-09 13:51 ` Felipe Balbi
2014-07-09 14:06 ` Santosh Shilimkar [this message]
2014-07-09 14:06 ` Santosh Shilimkar
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=53BD4C83.7020700@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=balbi@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nm@ti.com \
--cc=nsekhar@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.