[PATCH] vchiq driver

[Steven A. Falco]

On 8/13/22 08:21 AM, Arnd Bergmann wrote:
> 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?

It works to the degree that it lets me use the vcgencmd tool to measure temperature, arm clock speed, etc.

I don't know about the other functions of the driver.

But, if you decide to change just the kernel device tree, then that would break things.  Therefore, I'd like to see my patch or something similar go in at the same time, because that would at least allow the driver to keep functioning for use with the vcgencmd tool, and perhaps for other uses too.

	Steve

> 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.
> 
> 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.
> 
>          Arnd