Re: [RFC 2/2] dt-bindings: firmware: tegra186-bpmp: Document interconnects property

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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

On Mon, Jan 27, 2020 at 01:03:57AM +0300, Dmitry Osipenko wrote:
> 27.01.2020 00:56, Dmitry Osipenko пишет:
> [snip]
> > Thinking a bit more about how to define the ICC, I'm now leaning to a
> > variant like this:
> > 
> > interconnects =
> >     <&mc TEGRA186_MEMORY_CLIENT_BPMP &emc TEGRA_ICC_EMEM>,
> 
> >     <&mc TEGRA186_MEMORY_CLIENT_BPMPR>,
> >     <&mc TEGRA186_MEMORY_CLIENT_BPMPW>,
> >     <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR>,
> >     <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW>;
> 
> I forgot that each ICC path should have SRC and DST, but you got the idea.
> 
> This should be a more correct variant:
> 
> 	<&mc TEGRA186_MEMORY_CLIENT_BPMPR &mc TEGRA_ICC_MC>,
> 	<&mc TEGRA186_MEMORY_CLIENT_BPMPW &mc TEGRA_ICC_MC>,
> 	<&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &mc TEGRA_ICC_MC>,
> 	<&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &mc TEGRA_ICC_MC>;

This seems wrong again, because now we need to make up this TEGRA_ICC_MC
ID that doesn't exist anywhere in the hardware. So we're no longer
providing a hardware description, but instead are building hints for a
use by a Linux-specific framework into the DT.

Thierry

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