Re: [Mesa-dev] imx/etnaviv: loader_open_render_node() fails
Hi Lucas,
On 7 September 2018 at 10:56, Lucas Stach 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
Re: [Mesa-dev] imx/etnaviv: loader_open_render_node() fails
Hi Emil,
Am Freitag, den 07.09.2018, 10:52 +0100 schrieb Emil Velikov:
> Hi Lukas,
>
> Adding the etnaviv ML - people in there may have some tips.
>
> > On 6 September 2018 at 15:43, Lukas F. Hartmann wrote:
> > 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.
> >
>
> Have you considered checking other kernels?
>
> AFAICT entries like that should not just disappear from the uevent file.
> My personal, slightly biased, opinion is to track down what broke in
> kernel land.
I've just pointed out the kernel change that broke things in my other
mail. While it did apparently break libdrm it is a technically correct
change, so I would rather see libdrm fixed to deal with this than
reverting the kernel change (I'll still do it to not violate the kernel
no regressions rule if someone insists)
This should still be possible, as the regression is only present in the
master branch of mesa and won't end up in any currently tagged mesa
version.
Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] imx/etnaviv: loader_open_render_node() fails
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.
Regards,
Lucas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] imx/etnaviv: loader_open_render_node() fails
Hi Lukas,
Adding the etnaviv ML - people in there may have some tips.
On 6 September 2018 at 15:43, Lukas F. Hartmann wrote:
> 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.
>
Have you considered checking other kernels?
AFAICT entries like that should not just disappear from the uevent file.
My personal, slightly biased, opinion is to track down what broke in
kernel land.
HTH
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
