Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190318100605.29120-1-benjamin.gaignard@st.com> <20190318104343.GA15574@e107155-lin>
In-Reply-To: <20190318104343.GA15574@e107155-lin>
From:   Benjamin Gaignard <benjamin.gaignard@linaro.org>
Date:   Mon, 18 Mar 2019 12:05:54 +0100
Message-ID: <CA+M3ks6bsiGXCKEQmaFmzBRhWPVhV5wBjVhgyfCa-25DohnsOg@mail.gmail.com>
Subject: Re: [RESEND PATCH 0/7] Introduce bus domains controller framework
To:     Sudeep Holla <sudeep.holla@arm.com>
Cc:     Benjamin Gaignard <benjamin.gaignard@st.com>,
        Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>, Shawn Guo <shawnguo@kernel.org>,
        s.hauer@pengutronix.de, Fabio Estevam <fabio.estevam@nxp.com>,
        Loic PALLARDY <loic.pallardy@st.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-imx@nxp.com, kernel@pengutronix.de,
        Linux ARM <linux-arm-kernel@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Le lun. 18 mars 2019 =C3=A0 11:43, Sudeep Holla <sudeep.holla@arm.com> a =
=C3=A9crit :
>
> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
> > Bus domains controllers allow to divided system on chip into multiple d=
omains
> > that can be used to select by who hardware blocks could be accessed.
> > A domain could be a cluster of CPUs (or coprocessors), a range of addre=
sses or
> > a group of hardware blocks.
> >
> > Framework architecture is inspirated by pinctrl framework:
> > - a default configuration could be applied before bind the driver
> > - configurations could be apllied dynamically by drivers
> > - device node provides the bus domains configurations
> >
> > An example of bus domains controller is STM32 ETZPC hardware block
> > which got 3 domains:
> > - secure: hardware blocks are only accessible by software running on tr=
ust
> >   zone.
> > - non-secure: hardware blocks are accessible by non-secure software (i.=
e.
> >   linux kernel).
> > - coprocessor: hardware blocks are only accessible by the corpocessor.
> > Up to 94 hardware blocks of the soc could be managed by ETZPC and
> > assigned to one of the three domains.
> >
>
> You fail to explain why do we need this in non-secure Linux ?
> You need to have solid reasons as why this can't be done in secure
> firmware. And yes I mean even on arm32. On platforms with such hardware
> capabilities you will need some secure firmware to be running and these
> things can be done there. I don't want this enabled for ARM64 at all,
> firmware *has to deal* with this.

We use ETZPC to define if hardware blocks can be used by Cortex A7 or Corte=
x M4
(both non-secure) on STM32MP1 SoC, this new framework allow to change hardw=
are
block split at runtime. This could be done even on non-secure world
because their is
nothing critical to change hardware blocks users.
For example you can do "complex" tasks like display pipe configuration
on Cortex A7
where linux is running and handover the control of this hardware block
to Cortex M4 to
offload drawing on framebuffer.

Benjamin

>
> --
> Regards,
> Sudeep