Re: [PATCH 1/2] dt-bindings: crypto: update ccree optional params

From: Gilad Ben-Yossef
Date: Tue Sep 29 2020 - 14:08:32 EST


Hןת

On Wed, Sep 23, 2020 at 4:57 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Wed, Sep 16, 2020 at 10:19:49AM +0300, Gilad Ben-Yossef wrote:
> > Document ccree driver supporting new optional parameters allowing to
> > customize the DMA transactions cache parameters and ACE bus sharability
> > properties.
> >
> > Signed-off-by: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx>
> > ---
> > Documentation/devicetree/bindings/crypto/arm-cryptocell.txt | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> > index 6130e6eb4af8..1a1603e457a8 100644
> > --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> > +++ b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> > @@ -13,6 +13,10 @@ Required properties:
> > Optional properties:
> > - clocks: Reference to the crypto engine clock.
> > - dma-coherent: Present if dma operations are coherent.
> > +- awcache: Set write transactions cache attributes
> > +- arcache: Set read transactions cache attributes
>
> dma-coherent already implies these are 011x, 101x or 111x. In my limited
> experience configuring these (Calxeda SATA and ethernet), writeback,
> write-allocate was pretty much always optimal.

Indeed and these are the default. But not all SoC are born equal and
we got a request to allow setting these.

Maybe instead of numerical values have three possible verbal setting
would be better?


> > +- awdomain: Set write transactions ACE sharability domain (712, 703, 713 only)
> > +- ardomain: Set read transactions ACE sharability domain (712, 703, 713 only)
>
> This probably needs something common. We may need something for Mali,
> too. I don't think different settings for read and write makes much
> sense nor does anything beyond IS or OS.

I agree. Maybe

sharability_domain: either "IS" or "OS"?

>
> These could also just be implied by the compatible string (and requiring
> an SoC specific one).

hm... we could do it but this will require us to know (and publicly
acknowledge) of every SoC making use of this piece of hardware design.
There is currently no other part of the driver that needs this.

Gilad




--
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!