[PATCH] vchiq driver

[Stefan Wahren]

Hi Arnd,

Am 13.08.22 um 14:21 schrieb Arnd Bergmann:
> On Sat, Aug 13, 2022 at 8:15 AM Stefan Wahren <stefan.wahren at i2se.com> wrote:
>> Am 12.08.22 um 22:57 schrieb Steven A. Falco:
>>> On 8/12/22 04:31 PM, Stefan Wahren wrote:
>>>> Hi Steven,
>>>>
>>>> Am 12.08.22 um 19:13 schrieb Steven A. Falco:
>>>>> I am using Fedora Linux on a Raspberry Pi 4B.  When I use the
>>>>> kernel-provided device tree, I have a /dev/vchiq node, but if I
>>>>> instead use the firmware-provided device tree, this node is not
>>>>> created.
>>>> not sure which kernel is meant, but it's not the mainline kernel.
>>> I'm running Fedora Rawhide, which has kernel 5.19.0-65.fc37.aarch64.
>>> I thought that kernel was current, but I can see that I was wrong. :-)
>> sorry, i was wrong. I checked this. The wrong vchiq compatible is
>> accidentally enabled on the Raspberry Pi 4 & Co. Thanks for reporting
>> this issue
>>
>>           mailbox at 7e00b840 {
>>               compatible = "brcm,bcm2835-vchiq";
>>               reg = <0x7e00b840 0x3c>;
>>               interrupts = <0x00 0x22 0x04>;
>>           };
>>
>> @Florian, @Arnd
>>
>> What do you think about how to handle this? The vchiq driver is in
>> staging and Greg is not very happy about new features like bcm2711
>> support until the TODOs are finished.
>>
>> Replacing the compatible with the proper one would fix the device tree,
>> but would stop probing of the driver for the few brave mainline users
>> (regression from user point of view).
>>
>> Should we add "brcm,bcm2711-vchiq" to compatibles even the driver
>> doesn't supported it yet or better keep as it is?
> Does the staging driver work with the bcm2711 vchiq at the moment?
there is a userspace tool for testing the vchiq interface and it fails. 
But it's possible that some consumer driver of vchiq work in some 
scenarios.
> If the device is compatible with the old interface, keeping both the
> old and the new ID is not wrong, and I don't see a problem with adding
> the more specific identifier along with it.
We already had a similiar situation before. We had the problem that 
newer SoC like the BCM2836 or BCM2837 didn't work as expected because of 
the wrong cache line size. So we introduced brcm,bcm2836 and kept the 
older compatible.
> The question is whether there need to be any additional properties
> that have to be documented in the binding first, otherwise establishing
> a new compatible string may get us into backwards compatibility
> problems later on.

Since this is just a interface to the VideoCore firmware, we tried to 
avoid additional properties.

Best regards

>
>          Arnd