All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Chris Packham <judge.packham@gmail.com>
Cc: "Pierre-Clément Tosi" <ptosi@google.com>,
	u-boot <u-boot@lists.denx.de>, "Bin Meng" <bmeng.cn@gmail.com>,
	"Marc Zyngier" <maz@kernel.org>, "Peng Fan" <peng.fan@nxp.com>,
	"Simon Glass" <sjg@chromium.org>,
	"Will Deacon" <willdeacon@google.com>, "Ye Li" <ye.li@nxp.com>,
	"Ying-Chun Liu (PaulLiu)" <paul.liu@linaro.org>,
	meitao <meitaogao@asrmicro.com>,
	"Alistair Delva" <adelva@google.com>
Subject: Re: [PATCH 0/3] Revert HAFDBS changes
Date: Fri, 17 Nov 2023 14:41:55 -0500	[thread overview]
Message-ID: <20231117194155.GR170968@bill-the-cat> (raw)
In-Reply-To: <CAFOYHZAbkKLuC9KiH0KNz7hj31QsYohmJRCgu-Pk_yr4yXtEDw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Fri, Nov 10, 2023 at 06:38:40PM +1300, Chris Packham wrote:
> On Fri, 10 Nov 2023, 10:33 am Tom Rini, <trini@konsulko.com> wrote:
> 
> > On Fri, Oct 27, 2023 at 01:22:37PM -0400, Tom Rini wrote:
> > > On Fri, Oct 27, 2023 at 10:49:47AM +0100, Pierre-Clément Tosi wrote:
> > > > Hi Chris,
> > > >
> > > > On Fri, Oct 27, 2023 at 01:23:51PM +1300, Chris Packham wrote:
> > > > > As discussed this series reverts the HAFDBS changes that caused an
> > issue
> > > > > on AC5/AC5X. I think there are some improvements that can be made to
> > the
> > > > > initial memory map for the AC5/AC5X but so far nothing I've found
> > makes
> > > > > it compatible with the HAFDBS changes.
> > > >
> > > > Would you mind briefly explaining what those issues are and/or point
> > me to the
> > > > discussion where it was decided to revert these patches?
> > > >
> > > > The feature is quite useful for users of CONFIG_CMO_BY_VA_ONLY, to
> > speed up the
> > > > boot sequence: instead of reverting these patches altogether, would a
> > reasonable
> > > > alternative be to put them behind a build option?
> > > >
> > > > Also, could you confirm that the "initial memory map" you are
> > referring to above
> > > > only describes actual memory as, IIRC, some boards were using mappings
> > **much**
> > > > larger than their DRAM address space?
> > >
> > > The most details are in this thread:
> > >
> > https://lore.kernel.org/u-boot/CAFOYHZC_Dveax85n0fLr5BFyZcLqsvUssn=J0oHyvN75bTaCUw@mail.gmail.com/
> > > with some follow-up in:
> > >
> > https://lore.kernel.org/u-boot/CAFOYHZB7jJWwD24oWzx6u55w2whHYjK56f=QyN0LWU4Z8dSP+Q@mail.gmail.com/
> >
> > Checking to see if you have any feedback for these platforms? I would
> > like to have them working again one way or another in v2024.01, thanks.
> >
> 
> Either this series or
> https://lore.kernel.org/u-boot/20231018205358.1557234-1-judge.packham@gmail.com/
> will get the AC5X boards back working. I'm out of other ideas but happy to
> test patches.

Following up here on the cover letter as well that I've applied the
revert for now. I'm happy to revert the revert if we can get the AC5X
platforms fixed, and perhaps a little documentation about what was going
wrong as I believe the other thread at least hinted that other platforms
might be doing a workaround as well but didn't spell out why.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

      reply	other threads:[~2023-11-17 19:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-27  0:23 [PATCH 0/3] Revert HAFDBS changes Chris Packham
2023-10-27  0:23 ` [PATCH 1/3] Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present" Chris Packham
2023-11-17 19:42   ` Tom Rini
2023-10-27  0:23 ` [PATCH 2/3] Revert "arm64: Use level-2 for largest block mappings " Chris Packham
2023-11-17 19:42   ` Tom Rini
2023-10-27  0:23 ` [PATCH 3/3] Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available" Chris Packham
2023-11-17 19:42   ` Tom Rini
2023-10-27  9:49 ` [PATCH 0/3] Revert HAFDBS changes Pierre-Clément Tosi
2023-10-27 17:22   ` Tom Rini
2023-11-09 21:33     ` Tom Rini
2023-11-10  5:38       ` Chris Packham
2023-11-17 19:41         ` Tom Rini [this message]

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=20231117194155.GR170968@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=adelva@google.com \
    --cc=bmeng.cn@gmail.com \
    --cc=judge.packham@gmail.com \
    --cc=maz@kernel.org \
    --cc=meitaogao@asrmicro.com \
    --cc=paul.liu@linaro.org \
    --cc=peng.fan@nxp.com \
    --cc=ptosi@google.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=willdeacon@google.com \
    --cc=ye.li@nxp.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.