Message-ID: <d62c54db-7699-69fa-5928-1c55313da1f0@st.com>
Date:   Fri, 18 Jan 2019 09:56:47 +0000
From:   Benjamin GAIGNARD <benjamin.gaignard@...com>
To:     Rob Herring <robh@...nel.org>
CC:     Mark Brown <broonie@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Loic PALLARDY <loic.pallardy@...com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>
Subject: Re: [RFC 0/7] Introduce bus domains controller framework


On 1/17/19 6:57 PM, Rob Herring wrote:
> On Mon, Jan 14, 2019 at 8:42 AM Benjamin Gaignard
> <benjamin.gaignard@...com> wrote:
>> The goal of this framework is to offer an interface for the
>> hardware blocks controlling bus accesses rights.
>>
>> Bus domains controllers are typically used to control if a
>> hardware block can perform read or write operations on bus.
> Lots of things are domains. Power domains, clock domains, etc. But
> naming is hard.

I use 'domains' because it regroup hardware sharing the same access rights.
It is maybe not the best word.

>
> We now have the inter-connect binding which ATM only deals with
> bandwidth. Any reason we can't add access controls to that?

Because the targeted hardware block isn't the inter-connect but something
that is acting as a firewall on the bus to control the accesses rights on
hardware blocks.
'bus firewall' could have been a name for this framework but, for me, it
sound like something related to networking and that is not the case...
I could go in 'firewall' direction: driver will become 'bus firewall controller'
and apply 'firewall configurations' to grant/revoke accesses rights.
Does that sound better for you ?

>
>> Smarter domains controllers could be able to define accesses
>> rights per hardware blocks to control where they can read
>> or write.
>>
>> Domains controller configurations are provided in device node,
>> parsed by the framework and send to the driver to apply them.
>> Each controller may need different number and type of inputs
>> to configure a domain so device-tree properties size have to
>> be define by using "#domainctrl-cells".
>> Domains configurations properties have to be named "domainsctrl-X"
>> on device node.
>> "domainsctrl-names" keyword can also be used to give a name to
>> a specific configuration.
>>
>> 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 trust
>>    zone.
>> - non-secure: hardware blocks are accessible by non-secure software (i.e.
>>    linux kernel).
>> - coprocessor: hardware blocks are only accessible by the corpocessor.
> We already have a way to assign secure vs. non-secure with 'status'.
> Ignoring co-processors for a minute, why does that not work for you?

I aim to be able to dynamically change the configuration (like for pinctrl)
so status is not enough. It is true that stm32 etzpc is limited to control
the split between main and remote processors but other controllers could have
another granularity.

>
> Co-processors are so varied in terms of capabilities and view of the
> system, I'm not sure we can define something generic.

It isn't not about define co-precessors capabilities but about define
a new API for hardware blocks controlling accesses on the bus.

>
>> Up to 94 hardware blocks of the soc could be managed by ETZPC and
>> assigned to one of the three domains.
>>
>> It is an RFC, comments are welcome to help to create this framework, thanks.
> Finally, for a new, common binding, I'd like to see more than one
> platform using it (or at least an intent to use it).

I kwon at least two other hardware block who can take benefits of this:
- ARM TCZ 400: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0504c/index.html
   which is able to manage up to 8 regoins in address space.
- IMX Ressource Domain Controller (RDC): supports four domains and up to eight regions

I hope that others will show up when reading this thread.

Benjamin


>
> Rob

Powered by blists - more mailing lists