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

[Conor Dooley]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240416/cbe385d7/attachment.sig>