VC4 DRM/KMS - use correct dma-ranges

[6by9]

This is the suggested approach by @mripard to use the dma-ranges from the HVS (or firmware-kms) driver for the base DRM device, and therefore allocations should be done with the correct cache alias information for when it is passed to the HVS later.

[pelwell]

You state that the firmware needs access to the cache aliases, so why use the rpi-firmware-kms node rather than using the firmware node? As written, aren't you also relying on the fact that rpi-firmware-kms node is also in /soc, which wasn't a stated assumption?

[6by9]

Maxime's comment via email was

Since it's a virtual node, it shouldn't really be put under /soc, however, the
underlying issue is that the DRM device is also virtual, and therefore doesn't
really reflect the DMA capabilities of the devices that compose it.

The basic idea remains though, you have to "inherit" the DMA
configuration of the HVS on the main, virtual, DRM device that will perform all
the allocations, and you can do that using of_dma_configure with a different
device_node pointer. In your case, you'd use it on the drm_device's device, with
the HVS device_node.

I guess taking it further you could have a Pi3 with vc4_drv (brcm,bcm2835-vc4), vc4_v3d (brcm,bcm2835-v3d), and rpi-firmware enabled, but no composition pipeline. That would (correctly?) fail to find dma ranges in the current code, but not if looking for rpi-firmware which isn't a dependency.

Then again Pi0-3 V3D also needs the dma ranges, so perhaps we need to add a list of preferred devices for copying the DMA ranges from. Pass in a list to of_find_matching_node_and_match and allow it to find our preferred node to copy from.

[pelwell]

My problem stems from the wording "the firmware also requires the VideoCore cache aliases as defined by the dma-ranges under /soc, so also look for a rpi-firmware-kms node". What you meant (I now realise) was "the firmware display support requires that addresses are passed with the correct VideoCore cache aliases, and the rpi-firmware-kms node is guaranteed to have the correct dma-ranges, so copy that as a fallback", whereas I read it as "the firmware node also has the correct dma-ranges to use VideoCore cache aliases, so copy that as a fallback". I think both approaches are valid, but the commit message could be better.

[6by9]

Sorry, I had revised but not pushed based on your comments, but you've now merged.
I've pushed the alternate version (which has reworded commits) to https://github.com/6by9/linux/commits/rpi-5.4.y.

Revert and take the alternate, or keep the current?

[pelwell]

I've rewound rpi-5.4.y, so we can use the updated version.

[6by9]

Thanks. Sorry for not having replied earlier.