All of lore.kernel.org
 help / color / mirror / Atom feed
From: amit.virdi@st.com (Amit Virdi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: asm: Configure caches as per the defconfig
Date: Thu, 28 Nov 2013 17:15:41 +0530	[thread overview]
Message-ID: <52972CE5.6060103@st.com> (raw)
In-Reply-To: <20131128101154.GT16735@n2100.arm.linux.org.uk>

On 11/28/2013 3:41 PM, Russell King - ARM Linux wrote:
> On Thu, Nov 28, 2013 at 11:12:55AM +0530, Amit Virdi wrote:
>> On 11/27/2013 5:44 PM, Russell King - ARM Linux wrote:
>>> On Wed, Nov 27, 2013 at 05:24:04PM +0530, Amit Virdi wrote:
>>>> From: Amit VIRDI <Amit.VIRDI@st.com>
>>>>
>>>> In the current implementation of the decompression code, the caches are enabled
>>>> irrespective of their configuration in the deconfig. This makes setting the
>>>> ICACHE and DCACHE disable options from the menuconfig irrelevant. Change this
>>>> implementation to enable caches only if specified in the defconfig.
>>>
>>> NAK.  These options are provided more for ARM Ltd's validation of CPUs
>>> rather than for users, and it's not supposed to be used with the
>>> decompressor.
>>>
>>
>> It is perfectly true that these options are used only during CPU
>> validations and not in the end product. Still, it doesn't justify why
>> these options are not to be used with decompressor. Or alternately, why
>> would a user intend to disable a cache when it has been implemented
>> correctly and is stable? Without this change, the effect of disabling
>> cache is not reflected in entirety.
>
> When doing CPU validations, the compressed image isn't used.
>

Well, I have been using compressed images many a times on the FPGA 
platforms during initial hw design phases when the bitstream isn't 
stable with caches. I do not see any harm incorporating this patch. It 
only adds more logic to the existing implementation.

Regards
Amit Virdi

WARNING: multiple messages have this Message-ID (diff)
From: Amit Virdi <amit.virdi@st.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"nico@linaro.org" <nico@linaro.org>,
	"marc.ceeeee@gmail.com" <marc.ceeeee@gmail.com>,
	"spear--sw-devel@codex.cro.st.com"
	<spear--sw-devel@codex.cro.st.com>
Subject: Re: [PATCH] ARM: asm: Configure caches as per the defconfig
Date: Thu, 28 Nov 2013 17:15:41 +0530	[thread overview]
Message-ID: <52972CE5.6060103@st.com> (raw)
In-Reply-To: <20131128101154.GT16735@n2100.arm.linux.org.uk>

On 11/28/2013 3:41 PM, Russell King - ARM Linux wrote:
> On Thu, Nov 28, 2013 at 11:12:55AM +0530, Amit Virdi wrote:
>> On 11/27/2013 5:44 PM, Russell King - ARM Linux wrote:
>>> On Wed, Nov 27, 2013 at 05:24:04PM +0530, Amit Virdi wrote:
>>>> From: Amit VIRDI <Amit.VIRDI@st.com>
>>>>
>>>> In the current implementation of the decompression code, the caches are enabled
>>>> irrespective of their configuration in the deconfig. This makes setting the
>>>> ICACHE and DCACHE disable options from the menuconfig irrelevant. Change this
>>>> implementation to enable caches only if specified in the defconfig.
>>>
>>> NAK.  These options are provided more for ARM Ltd's validation of CPUs
>>> rather than for users, and it's not supposed to be used with the
>>> decompressor.
>>>
>>
>> It is perfectly true that these options are used only during CPU
>> validations and not in the end product. Still, it doesn't justify why
>> these options are not to be used with decompressor. Or alternately, why
>> would a user intend to disable a cache when it has been implemented
>> correctly and is stable? Without this change, the effect of disabling
>> cache is not reflected in entirety.
>
> When doing CPU validations, the compressed image isn't used.
>

Well, I have been using compressed images many a times on the FPGA 
platforms during initial hw design phases when the bitstream isn't 
stable with caches. I do not see any harm incorporating this patch. It 
only adds more logic to the existing implementation.

Regards
Amit Virdi

  reply	other threads:[~2013-11-28 11:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27 11:54 [PATCH] ARM: asm: Configure caches as per the defconfig Amit Virdi
2013-11-27 11:54 ` Amit Virdi
2013-11-27 12:14 ` Russell King - ARM Linux
2013-11-27 12:14   ` Russell King - ARM Linux
2013-11-28  5:42   ` Amit Virdi
2013-11-28  5:42     ` Amit Virdi
2013-11-28 10:11     ` Russell King - ARM Linux
2013-11-28 10:11       ` Russell King - ARM Linux
2013-11-28 11:45       ` Amit Virdi [this message]
2013-11-28 11:45         ` Amit Virdi

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=52972CE5.6060103@st.com \
    --to=amit.virdi@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.