All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Sekhar Nori <nsekhar@ti.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
Date: Tue, 8 Apr 2014 11:17:17 -0400	[thread overview]
Message-ID: <534412FD.5030308@ti.com> (raw)
In-Reply-To: <53440D73.6060504@ti.com>

On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
> On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
>> On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
>>> diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
>>> index f8b8dac..6b2a056 100644
>>> --- a/arch/arm/mach-omap2/omap4-common.c
>>> +++ b/arch/arm/mach-omap2/omap4-common.c
>>> @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
>>>  
>>>  	return omap_l2_cache_init(aux_ctrl, 0xc19fffff);
>>>  }
>>> +
>>> +int __init am43xx_l2_cache_init(void)
>>> +{
>>> +	u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
>>> +		       L310_AUX_CTRL_INSTR_PREFETCH;
>>
>> It would be good to documenting the difference between this and OMAP4,
>> and why you have chosen different values.
> 
> There are two main differences:
> 
> 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
> not needed even in OMAP4 with latest kernel, but I am not sure if I can
> do this safely without breaking any usecase currently working with OMAP4.
> 
Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
which needs that.

> 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
> searched through the commit history of L2 cache support on OMAP4 but
> there is no mention of why this was needed on OMAP4. I am checking
> internally on the history behind this.
>
These have also come from the aligned settings with hardware folks.
 
> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
> since thats the default anyway. We can probably drop this setting even
> from OMAP4.
> 
Don't change anything on OMAP4 since these settings have come up from
multiple alignments.

In my view, Aegis can use exact same setting as OMAP4. Things like
shared bit etc would not make much difference because of UP config,
keeping that doesn't hurt either.

Why don't you just re-use that as is ? Sorry if I have missed any
other discussion on the thread.

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: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
Date: Tue, 8 Apr 2014 11:17:17 -0400	[thread overview]
Message-ID: <534412FD.5030308@ti.com> (raw)
In-Reply-To: <53440D73.6060504@ti.com>

On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
> On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
>> On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
>>> diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
>>> index f8b8dac..6b2a056 100644
>>> --- a/arch/arm/mach-omap2/omap4-common.c
>>> +++ b/arch/arm/mach-omap2/omap4-common.c
>>> @@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
>>>  
>>>  	return omap_l2_cache_init(aux_ctrl, 0xc19fffff);
>>>  }
>>> +
>>> +int __init am43xx_l2_cache_init(void)
>>> +{
>>> +	u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
>>> +		       L310_AUX_CTRL_INSTR_PREFETCH;
>>
>> It would be good to documenting the difference between this and OMAP4,
>> and why you have chosen different values.
> 
> There are two main differences:
> 
> 1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
> not needed even in OMAP4 with latest kernel, but I am not sure if I can
> do this safely without breaking any usecase currently working with OMAP4.
> 
Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
which needs that.

> 2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
> searched through the commit history of L2 cache support on OMAP4 but
> there is no mention of why this was needed on OMAP4. I am checking
> internally on the history behind this.
>
These have also come from the aligned settings with hardware folks.
 
> 3) OMAP4 sets cache replacement policy to RR which is not a big deal
> since thats the default anyway. We can probably drop this setting even
> from OMAP4.
> 
Don't change anything on OMAP4 since these settings have come up from
multiple alignments.

In my view, Aegis can use exact same setting as OMAP4. Things like
shared bit etc would not make much difference because of UP config,
keeping that doesn't hurt either.

Why don't you just re-use that as is ? Sorry if I have missed any
other discussion on the thread.

Regards,
Santosh

  reply	other threads:[~2014-04-08 15:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04 10:10 [PATCH v2 0/3] ARM: OMAP2+: AM437x: L2 cache support Sekhar Nori
2014-04-04 10:10 ` Sekhar Nori
2014-04-04 10:10 ` [PATCH v2 1/3] ARM: OMAP2+: L2 cache: allow different aux ctrl settings Sekhar Nori
2014-04-04 10:10   ` Sekhar Nori
2014-04-04 10:10 ` [PATCH v2 2/3] ARM: OMAP2+: L2 cache: get rid of init call Sekhar Nori
2014-04-04 10:10   ` Sekhar Nori
2014-04-04 10:10 ` [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support Sekhar Nori
2014-04-04 10:10   ` Sekhar Nori
2014-04-04 10:18   ` Russell King - ARM Linux
2014-04-04 10:18     ` Russell King - ARM Linux
2014-04-08 14:53     ` Sekhar Nori
2014-04-08 14:53       ` Sekhar Nori
2014-04-08 15:17       ` Santosh Shilimkar [this message]
2014-04-08 15:17         ` Santosh Shilimkar
2014-04-09  9:44         ` Sekhar Nori
2014-04-09  9:44           ` Sekhar Nori
2014-04-09 16:33         ` Russell King - ARM Linux
2014-04-09 16:33           ` Russell King - ARM Linux
2014-04-09 16:52           ` Santosh Shilimkar
2014-04-09 16:52             ` Santosh Shilimkar
2014-04-10 12:08             ` Sekhar Nori
2014-04-10 12:08               ` Sekhar Nori
2014-04-09 16:23       ` Russell King - ARM Linux
2014-04-09 16:23         ` Russell King - ARM Linux
2014-04-10 11:56         ` Sekhar Nori
2014-04-10 11:56           ` Sekhar Nori
2014-04-10 12:03           ` Russell King - ARM Linux
2014-04-10 12:03             ` Russell King - ARM Linux
2014-04-10 12:16             ` Sekhar Nori
2014-04-10 12:16               ` Sekhar Nori
2014-04-10 13:27               ` Sekhar Nori
2014-04-10 13:27                 ` Sekhar Nori
2014-04-10 13:40                 ` Russell King - ARM Linux
2014-04-10 13:40                   ` Russell King - ARM Linux
2014-04-11  5:33                   ` Sekhar Nori
2014-04-11  5:33                     ` Sekhar Nori
2014-04-11 11:25                     ` Russell King - ARM Linux
2014-04-11 11:25                       ` Russell King - ARM Linux
2014-04-11 12:01                       ` Sekhar Nori
2014-04-11 12:01                         ` Sekhar Nori
2014-04-22  5:48                       ` Sekhar Nori
2014-04-22  5:48                         ` Sekhar Nori

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=534412FD.5030308@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --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.