[PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D

[Florian Fainelli]

On 4/16/24 10:21, Conor Dooley wrote:
> On Tue, Apr 16, 2024 at 07:13:51AM -0300, Maíra Canal wrote:
>> On 4/16/24 02:30, Stefan Wahren wrote:
>>> Hi Maíra,
>>>
>>> Am 16.04.24 um 03:02 schrieb Maíra Canal:
>>>> On 4/15/24 13:54, Andre Przywara wrote:
>>>>> On Mon, 15 Apr 2024 13:00:39 -0300
>>>>> Maíra Canal <mcanal at igalia.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
>>>>>> the RPi. Currently, the downstream kernel uses an overlay to enable the
>>>>>> GPU and use GPU hardware acceleration. When deploying a mainline kernel
>>>>>> to the RPi 0-3, we end up without any GPU hardware acceleration
>>>>>> (essentially, we can't use the OpenGL driver).
>>>>>>
>>>>>> Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel.
>>>>>
>>>>> So I think Krzysztof's initial comment still stands: What does that
>>>>> patch
>>>>> actually change? If I build those DTBs as of now, none of them has a
>>>>> status property in the v3d node. Which means it's enabled:
>>>>> https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status
>>>>>
>>>>> So adding an explicit 'status = "okay";' doesn't make a difference.
>>>>>
>>>>> What do I miss here?
>>>>
>>>> As mentioned by Stefan in the last version, in Raspberry Pi OS, there is
>>>> a systemd script which is trying to check for the V3D driver (/usr/lib
>>>> /systemd/scripts/gldriver_test.sh). Within the first check, "raspi-
>>>> config nonint is_kms" is called, which always seems to fail. What
>>>> "raspi-config" does is check if
>>>> /proc/device-tree/soc/v3d at 7ec00000/status is equal to "okay". As
>>>> /proc/device-tree/soc/v3d at 7ec00000/status doesn't exists, it returns
>>>> false.
>>> yes, but i also mention that the V3D driver starts without this patch.
>>> The commit message of this patch suggests this is a DT issue, which is not.
>>>
>>> I hadn't the time to update my SD card to Bookworm yet. Does the issue
>>> still exists with this version?
>>
>> I'm using a 32-bit kernel and the recommended OS for 32-bit is Bullseye.
>> But I checked the Bookworm code and indeed, Bookworm doesn't check
>> the device tree [1].
>>
>> I'm thinking about sending a patch to the Bullseye branch to fix this
>> issue.
> 
> I think you should, sounds like they're making invalid assumptions about
> the status property.

Agreed, fix the script, not the DTSes.
-- 
Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240416/8f64b8b1/attachment.p7s>