[PATCH] vchiq driver

[Stefan Wahren]

Hi Steve,

Am 13.08.22 um 15:56 schrieb 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.

in case you want to measure the CPU temperature there is the 
CONFIG_BCM2711_THERMAL driver which doesn't require a vendor specific 
userspace tool.

>
> I don't know about the other functions of the driver.
The driver provides the necessary interface for the audio driver (A/V 
jack) and the old camera interface.
>
> 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.
Yes, this is something we want to avoid.
>
>     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
>