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

[Thierry Reding <thierry.reding@gmail.com>]

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

On Mon, Jan 27, 2020 at 12:56:24AM +0300, Dmitry Osipenko wrote:
[...]
> 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>;
> 
> interconnect-names = "dma-mem", "read", "write", "dma-read", "dma-write";
> 
> Looks like there is a problem with having a full MC-EMEM path being
> defined for each memory client.. it's not very practical in terms of
> memory frequency scaling.
> 
> Take Display Controller for example, it has a memory client for each
> display (overlay) plane. If planes are not overlapping on the displayed
> area, then the required total memory bandwidth equals to the peak
> bandwidth selected among of the visible planes. But if planes are
> overlapping, then the bandwidths of each overlapped plane are
> accumulated because overlapping planes will issue read request
> simultaneously for the overlapping areas.
> 
> The Memory Controller doesn't have any knowledge about the Display
> Controller's specifics. Thus in the end it should be a responsibility of
> Display Controller's driver to calculate the required bandwidth for the
> hardware unit, since only the driver has all required knowledge about
> planes overlapping state and whatnot.

I agree that the device-specific knowledge should live in the device-
specific drivers. However, what you're doing above is basically putting
the OS-specific knowledge into the device tree.

The memory client interfaces are a real thing in hardware that can be
described using the corresponding IDs. But there is no such thing as the
"BPMP" memory client. Rather it's composed of the other four.

So I think a better thing to do would be for the consumer driver to deal
with all of that. If looking at only bandwidth, the consumer driver can
simply pick any one of the clients/paths for any of the bandwidth
requests and for per-interface settings like latency allowance the
consumer would choose the appropriate path.

> The similar applies to multimedia things, like GPU or Video Decoder.
> They have multiple memory clients and (I'm pretty sure that) nobody is
> going to calculate memory bandwidth requirements for every client, it's
> simply impractical.
> 
> So, I'm suggesting that we should have a single "dma-mem" ICC path for
> every hardware unit.
> 
> The rest of the ICC paths could be memory_client -> memory_controller
> paths, providing knobs for things like MC arbitration (latency)
> configuration for each memory client. I think this variant of
> description is actually closer to the hardware, since the client's
> arbitration configuration ends in the Memory Controller.

Not necessarily. The target of the access doesn't always have to be the
EMC. It could equally well be IRAM, in which case there are additional
controls that need to be programmed within the MC to allow the memory
client to access IRAM. If you don't have a phandle to IRAM in the
interconnect properties, there's no way to make this distinction.

Thierry

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