All of lore.kernel.org
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
Date: Fri, 1 Feb 2013 17:54:53 +0530	[thread overview]
Message-ID: <510BB415.70200@ti.com> (raw)
In-Reply-To: <20130201121137.GC23869@e102568-lin.cambridge.arm.com>

On Friday 01 February 2013 05:41 PM, Lorenzo Pieralisi wrote:
> On Fri, Feb 01, 2013 at 11:29:44AM +0000, Santosh Shilimkar wrote:
>> + Lorenzo,
>>
>> On Thursday 31 January 2013 10:35 PM, dinguyen at altera.com wrote:
>>> From: Dinh Nguyen <dinguyen@altera.com>
>>>
>>> mach-socfpga is another platform that needs to use
>>> v7_invalidate_l1 to bringup additional cores. There was a comment that
>>> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>>>
>>> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
>>> Acked-by: Simon Horman <horms+renesas@verge.net.au>
>>> Tested-by: Pavel Machek <pavel@denx.de>
>>> Reviewed-by: Pavel Machek <pavel@denx.de>
>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Olof Johansson <olof@lixom.net>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Rob Herring <rob.herring@calxeda.com>
>>> Cc: Sascha Hauer <kernel@pengutronix.de>
>>> Cc: Magnus Damm <magnus.damm@gmail.com>
>>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>>> ---
>>>    arch/arm/mach-imx/headsmp.S      |   47 -------------------------------------
>>>    arch/arm/mach-shmobile/headsmp.S |   48 --------------------------------------
>>>    arch/arm/mach-tegra/headsmp.S    |   43 ----------------------------------
>>>    arch/arm/mm/cache-v7.S           |   46 ++++++++++++++++++++++++++++++++++++
>>>    4 files changed, 46 insertions(+), 138 deletions(-)
>>>
>> [..]
>>
>>> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
>>> index 7539ec2..15451ee 100644
>>> --- a/arch/arm/mm/cache-v7.S
>>> +++ b/arch/arm/mm/cache-v7.S
>>> @@ -19,6 +19,52 @@
>>>    #include "proc-macros.S"
>>>
>>>    /*
>>> + * The secondary kernel init calls v7_flush_dcache_all before it enables
>>> + * the L1; however, the L1 comes out of reset in an undefined state, so
>>> + * the clean + invalidate performed by v7_flush_dcache_all causes a bunch
>>> + * of cache lines with uninitialized data and uninitialized tags to get
>>> + * written out to memory, which does really unpleasant things to the main
>>> + * processor.  We fix this by performing an invalidate, rather than a
>>> + * clean + invalidate, before jumping into the kernel.
>>> + *
>>> + * This function is cloned from arch/arm/mach-tegra/headsmp.S, and needs
>>> + * to be called for both secondary cores startup and primary core resume
>>> + * procedures.
>>> + */
>>> +ENTRY(v7_invalidate_l1)
>> Now since we are moving the code under common place, probably we should
>> update this a function a bit so that it invalidates the CPU cache till
>> line of unification. Just to be consistent with other flush API.
>>
>> Lorenzo,
>> Does that make sense ?
>
> Well, on latest processors (A15, A7) caches are invalidated on reset unless
> the chip is programmed to skip that on reset (ie L2 retained).
>
> But it makes sense, for sure it should not be called v7_invalidate_l1,
> but invalidate_louis, and instead of forcing level 0 we should be
> reading LoUIS and invalidate up to that level as we do in the clean and
> invalidate function.
>
That is exactly what I was thinking.

> Is it worth adding a v7 cache function where the only difference wrt the clean
> and invalidate operation is a coprocessor opcode ? Probably not IMHO, why add
> the set/way loop again ?
>
Probably same function can be re-used with the parameter passing to 
differentiate the inv and flush.

> It is never called from C code, so I do not think there is a point in
> adding a C API either.
>
I agree. C API isn't needed.

Regards,
Santosh

  reply	other threads:[~2013-02-01 12:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31 17:05 [PATCHv2 for soc 0/4] Enabling socfpga on hardware dinguyen at altera.com
2013-01-31 17:05 ` [PATCHv2 for soc 1/4] arm: socfpga: Add new device tree source for actual socfpga HW dinguyen at altera.com
2013-02-01  3:46   ` Olof Johansson
2013-02-01 15:23     ` Dinh Nguyen
2013-01-31 17:05 ` [PATCHv2 for soc 2/4] arm: socfpga: Add entries to enable make dtbs socfpga dinguyen at altera.com
2013-01-31 17:05 ` [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S dinguyen at altera.com
2013-01-31 18:11   ` Stephen Warren
2013-02-01  3:47   ` Olof Johansson
2013-02-01 11:29   ` Santosh Shilimkar
2013-02-01 11:32     ` Russell King - ARM Linux
2013-02-01 11:44       ` Santosh Shilimkar
2013-02-01 12:48         ` Russell King - ARM Linux
2013-02-01 13:04           ` Santosh Shilimkar
2013-02-01 13:20             ` Russell King - ARM Linux
2013-02-01 14:09               ` Santosh Shilimkar
2013-02-01 12:11     ` Lorenzo Pieralisi
2013-02-01 12:24       ` Santosh Shilimkar [this message]
2013-02-01 12:54       ` Russell King - ARM Linux
2013-02-01 14:10         ` Lorenzo Pieralisi
2013-02-01 14:19           ` Russell King - ARM Linux
2013-02-01 14:31             ` Russell King - ARM Linux
2013-02-01 14:43               ` Santosh Shilimkar
2013-02-01 14:49                 ` Russell King - ARM Linux
2013-02-01 14:53                   ` Santosh Shilimkar
2013-02-01 14:34             ` Lorenzo Pieralisi
2013-01-31 17:05 ` [PATCHv2 for soc 4/4] arm: socfpga: Add SMP support for actual socfpga harware dinguyen at altera.com
2013-02-01  3:50   ` Olof Johansson
2013-02-01 10:46     ` Pavel Machek
2013-02-01 15:27       ` Dinh Nguyen
2013-02-01 15:31         ` Russell King - ARM Linux
2013-02-01 16:39           ` Dinh Nguyen
2013-02-02 19:24             ` Pavel Machek
2013-02-02 21:37               ` Dinh Nguyen
2013-02-03 18:36                 ` Pavel Machek
2013-02-04 16:12                   ` Dinh Nguyen
2013-02-01 10:50   ` Pavel Machek

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=510BB415.70200@ti.com \
    --to=santosh.shilimkar@ti.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.