All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Peng Fan <peng.fan@nxp.com>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: gic700 shareability question
Date: Mon, 03 Apr 2023 09:08:13 +0100	[thread overview]
Message-ID: <86355hwfpu.wl-maz@kernel.org> (raw)
In-Reply-To: <DU0PR04MB9417FCF524FA0BB9808B4E8088929@DU0PR04MB9417.eurprd04.prod.outlook.com>

On Mon, 03 Apr 2023 02:36:31 +0100,
Peng Fan <peng.fan@nxp.com> wrote:
> 
> Hi Marc,
> 
> > Subject: Re: gic700 shareability question
> > 
> > + Lorenzo
> > 
> > On Tue, 28 Mar 2023 13:48:19 +0100,
> > Peng Fan <peng.fan@nxp.com> wrote:
> > >
> > > Hi Marc,
> > >
> > > We have an SoC that use GIC-700, but not support shareability,
> > 
> > Define this. The IP does support shareability, but your integration doesn't?
> > 
> > > Currently I just hack the code as below. Do you think it is feasible
> > > to add firmware bindings such that these can be used to define the
> > > correct shareability/cacheability instead of relying on the
> > > programmability of the CBASER register?
> > >
> > > Saying with "broken-shareability", we just clear all the shareability
> > > settings.
> > 
> > This is the same thing as the Rockchip crap, so you are in good company.
> > 
> > I've repeatedly stated that this needs to be handled:
> > 
> > - either by describing the full system topology and describe what is
> >   in the same inner-shareable domain as the CPUs, which needs to
> >   encompass both DT and ACPI (starting with DT seems reasonable),
> > 
> 
> We will give a look on this. But honestly not have a good idea on how.

For each node that can initiate memory transactions in the system, you
have a phandle to a node that describe the shareability. In your case,
you would have two nodes: one inner-shareable with at least the CPUs
and whatever IP block that is in the same IS domain, and another that
describe the outer-shareable domain.

Or another variation on the same theme.

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-04-03  8:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 12:48 gic700 shareability question Peng Fan
2023-03-31 10:21 ` Marc Zyngier
2023-04-03  1:36   ` Peng Fan
2023-04-03  8:08     ` Marc Zyngier [this message]
2023-04-03  8:32     ` Lorenzo Pieralisi
2023-04-03  9:11       ` Peng Fan

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=86355hwfpu.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=peng.fan@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.