[Openpvrsgx-devgroup] two pvr devices created for omap4

Tony Lindgren tony at atomide.com
Fri Nov 1 01:05:41 CET 2019


* H. Nikolaus Schaller <hns at goldelico.com> [191031 20:46]:
> > Am 31.10.2019 um 18:36 schrieb Tony Lindgren <tony at atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns at goldelico.com> [191031 06:38]:
> >>> Am 31.10.2019 um 05:17 schrieb Tony Lindgren <tony at atomide.com>:
> >>>> ioctl(12, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x42, 0x48), 0xbed39a30) = -1 EINVAL (Invalid argument)
> > 
> > Uhh the ioctl above is going to be in the maybe unfixable
> > category for the old userspace..
> 
> Yes, this users-space code is really ugly...
> 
> > 
> > The old pvr-omap4 userspace blobs assume the old
> > drivers/staging/omapdrm driver that has pvr kernel
> > module call omap_drm_register_plugin() exported by the
> > omapdrm driver that sets up proxying for the ioctl
> > handlers.
> 
> Ok.
> 
> > After the first 0x42 ioctl, there's a following "standard"
> > initial pvr init call is the usual:
> > 
> > ioctl(3, _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c), 0xbea3f2bc) = -1 EINVAL (Invalid argument)
> > 
> > But that now fails as it's for the the wrong dri device
> > and we have mainline omapdrm implement it's own ioctl
> > handlers which is for DRM_IOCTL_OMAP_GET_PARAM.
> 
> So we would have to patch this code?
> 
> > Probably the only sane fix for this is to do some
> > LD_PRELOAD wrapper for the old userspace that swaps
> > the /dev/dri device path to point to the right instance.
> > 
> > Maybe there's some other mainline kernel solution.
...
> At least we will learn a lot about how this beast
> works - until we can tame it.

We may be able to have just a minimal quirk handling for
pvr-omap4, let's see. Anyways, I'll rewrite the module
init stuff for pvr_probe and pvr_remove and get rid of
all the plugin ifdefs all over the place. And I'll add
basic quirk handling depending on the dts compatible.

> As you maybe see in the CC: I have tried to set up
> a new mailing list for these discussions. I am not
> exactly sure if it already works (mailman and postfix
> with virtual host addresses isn't that easy to
> manage - especially on a system that is running some
> years now without many modifications).

OK great, let's hope it works. Do you already have
some list archive available if it's an existing
server?

Regards,

Tony


More information about the Openpvrsgx-devgroup mailing list