Hi Lucas,
On 7 September 2018 at 10:56, Lucas Stach <l.st...@pengutronix.de> wrote:
> Am Donnerstag, den 06.09.2018, 16:43 +0200 schrieb Lukas F. Hartmann:
>> Hi,
>>
>> I've updated to and rebuilt the latest git versions of linux, drm, mesa
>> and kmscube on an imx6qp system. I tried both with etnaviv as a module
>> and compiled into the kernel (no difference).
>>
>> Mesa no longer picks up etnaviv for GL rendering, but always reverts to
>> softpipe. A bit of debugging revealed that the following codepath fails:
>>
>> imx_drm_screen_create -> loader_open_render_node("etnaviv") ->
>> drmGetDevices2 -> drmProcessPlatformDevice(... "/dev/dri/renderD128") ->
>> drmParsePlatformBusInfo -> sysfs_uevent_get
>>
>> The latter function opens /sys/dev/char/226:128/device/uevent and looks
>> for OF_FULLNAME, but this key is not present on my system. The node
>> contains only:
>>
>> DRIVER=etnaviv
>> MODALIAS=platform:etnaviv
>>
>> Whereas /sys/dev/char/226:0/device/uevent contains:
>>
>> DRIVER=imx-drm
>> OF_NAME=display-subsystem
>> OF_FULLNAME=/display-subsystem
>> OF_COMPATIBLE_0=fsl,imx-display-subsystem
>> OF_COMPATIBLE_N=1
>>
>> Which is not the render node.
>>
>> > According to https://patchwork.kernel.org/patch/9487631/#19940985 there
>> should be more lines (device tree related?) in the uevent file for the
>> render node, and I wonder why they don't exist.
>
> Since kernel 4.17 (drm/etnaviv: remove the need for a gpu-subsystem DT
> node) the etnaviv DRM driver doesn't have an associated DT node
> anymore. This is technically correct, as the etnaviv device is a
> virtual device driving multiple hardware devices.
>
> libdrm should be fixed to properly deal with this.
>
Pardon for the delay - your reply was out just as I hit the holiday mode.
Let's start with the more obvious thing:
- Are the OF entries part of the ABI or not? Can we have that
documented anywhere?
There are very few mentions in the official kernel doc - Documentation/ABI/
Obviously it doesn't mention anything OF_* but it neither does DRIVER
or MODALIAS but if we change those !world will break ;-)
- How can we distinguish between devices on the same "bus"?
I guess ones like PCI and USB we could, for platform/host1x, with no
OF data, we cannot.
We could rework the implementation to drop the "de-duplicate devices
sitting on the same bus". Patches welcome, since I don't know exactly
when I'll get to it.
All that said, I'm perfectly fine with reverting the Mesa patch. I'll
leave the call to Christian who wrote it in the first place.
HTH
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
