All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Nicolas Pitre <nico@fluxnic.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH v4 0/5] ARM: decompressor: use by-VA cache maintenance for v7 cores
Date: Thu, 27 Feb 2020 16:53:33 +0000	[thread overview]
Message-ID: <bb66152dddd84d34d2cf8c7a98c486a1@kernel.org> (raw)
In-Reply-To: <CAKv+Gu_smwr3RDW=B8BQ8AG1+aOibFHwvoTSR=F2TxDguV2ELQ@mail.gmail.com>

On 2020-02-27 16:47, Ard Biesheuvel wrote:
> On Thu, 27 Feb 2020 at 17:01, Marc Zyngier <maz@kernel.org> wrote:
>> 
>> On 2020-02-27 10:11, Linus Walleij wrote:
>> > On Wed, Feb 26, 2020 at 5:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>> >
>> >> So instead, switch to the by-VA cache maintenance that the
>> >> architecture
>> >> requires for v7 and later (and ARM1176, as a side effect).
>> >>
>> >> Changes since v3:
>> >> - ensure that the region that is cleaned after self-relocation of the
>> >> zImage
>> >>   covers the appended DTB, if present
>> >>
>> >> Apologies to Linus, but due to this change, I decided not to take your
>> >> Tested-by into account, and I would appreciate it if you could retest
>> >> this version of the series? Thanks.
>> >
>> > No problem, I have tested it on the following:
>> >
>> > - ARMv7 Cortex A9 x 2 Qualcomm APQ8060 DragonBoard
>> > - ARM PB11MPCore (4 x 1176)
>> 
>> <pedant>
>> 
>> The ARM11MPCore isn't a bunch of 1176s glued together. It is actually 
>> a
>> very
>> different CPU, designed by a different team.
>> 
>> </pedant>
>> 
> 
> It still takes the same code path in the cache routines, afaict:
> - the architecture field in the main id register == 0xf, so it uses
> __armv7_mmu_cache_flush
> - ID_MMFR1[19:16] == 0x2, so it does not take the 'hierarchical' code
> path which is modified by these patches

Absolutely. From a SW perspective, this is treated in a similar way as
ARM1176. The underlying HW is very different though...

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	Nicolas Pitre <nico@fluxnic.net>,
	Tony Lindgren <tony@atomide.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 0/5] ARM: decompressor: use by-VA cache maintenance for v7 cores
Date: Thu, 27 Feb 2020 16:53:33 +0000	[thread overview]
Message-ID: <bb66152dddd84d34d2cf8c7a98c486a1@kernel.org> (raw)
In-Reply-To: <CAKv+Gu_smwr3RDW=B8BQ8AG1+aOibFHwvoTSR=F2TxDguV2ELQ@mail.gmail.com>

On 2020-02-27 16:47, Ard Biesheuvel wrote:
> On Thu, 27 Feb 2020 at 17:01, Marc Zyngier <maz@kernel.org> wrote:
>> 
>> On 2020-02-27 10:11, Linus Walleij wrote:
>> > On Wed, Feb 26, 2020 at 5:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>> >
>> >> So instead, switch to the by-VA cache maintenance that the
>> >> architecture
>> >> requires for v7 and later (and ARM1176, as a side effect).
>> >>
>> >> Changes since v3:
>> >> - ensure that the region that is cleaned after self-relocation of the
>> >> zImage
>> >>   covers the appended DTB, if present
>> >>
>> >> Apologies to Linus, but due to this change, I decided not to take your
>> >> Tested-by into account, and I would appreciate it if you could retest
>> >> this version of the series? Thanks.
>> >
>> > No problem, I have tested it on the following:
>> >
>> > - ARMv7 Cortex A9 x 2 Qualcomm APQ8060 DragonBoard
>> > - ARM PB11MPCore (4 x 1176)
>> 
>> <pedant>
>> 
>> The ARM11MPCore isn't a bunch of 1176s glued together. It is actually 
>> a
>> very
>> different CPU, designed by a different team.
>> 
>> </pedant>
>> 
> 
> It still takes the same code path in the cache routines, afaict:
> - the architecture field in the main id register == 0xf, so it uses
> __armv7_mmu_cache_flush
> - ID_MMFR1[19:16] == 0x2, so it does not take the 'hierarchical' code
> path which is modified by these patches

Absolutely. From a SW perspective, this is treated in a similar way as
ARM1176. The underlying HW is very different though...

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-02-27 16:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 16:57 [PATCH v4 0/5] ARM: decompressor: use by-VA cache maintenance for v7 cores Ard Biesheuvel
2020-02-26 16:57 ` Ard Biesheuvel
2020-02-26 16:57 ` [PATCH v4 1/5] efi/arm: Work around missing cache maintenance in decompressor handover Ard Biesheuvel
2020-02-26 16:57   ` Ard Biesheuvel
2020-02-26 16:57 ` [PATCH v4 2/5] efi/arm: Pass start and end addresses to cache_clean_flush() Ard Biesheuvel
2020-02-26 16:57   ` Ard Biesheuvel
2020-02-26 16:57 ` [PATCH v4 3/5] ARM: decompressor: factor out routine to obtain the inflated image size Ard Biesheuvel
2020-02-26 16:57   ` Ard Biesheuvel
2020-02-26 16:57 ` [PATCH v4 4/5] ARM: decompressor: prepare cache_clean_flush for doing by-VA maintenance Ard Biesheuvel
2020-02-26 16:57   ` Ard Biesheuvel
2020-02-26 16:57 ` [PATCH v4 5/5] ARM: decompressor: switch to by-VA cache maintenance for v7 cores Ard Biesheuvel
2020-02-26 16:57   ` Ard Biesheuvel
2020-02-26 19:14 ` [PATCH v4 0/5] ARM: decompressor: use " Tony Lindgren
2020-02-26 19:14   ` Tony Lindgren
2020-02-27 10:11 ` Linus Walleij
2020-02-27 10:11   ` Linus Walleij
2020-02-27 16:01   ` Marc Zyngier
2020-02-27 16:01     ` Marc Zyngier
2020-02-27 16:47     ` Ard Biesheuvel
2020-02-27 16:47       ` Ard Biesheuvel
2020-02-27 16:53       ` Marc Zyngier [this message]
2020-02-27 16:53         ` Marc Zyngier

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=bb66152dddd84d34d2cf8c7a98c486a1@kernel.org \
    --to=maz@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=nico@fluxnic.net \
    --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.