Hello Thomas,
Thanks for your feedback and comments.
On 5/13/22 12:48, Thomas Zimmermann wrote:
> Hi Javier,
>
> thanks again for providing the examples. I think I now better get what
> you're trying to solve.
>
You are welcome.
> First of all let's merge patch 3, as it seems unrelated.
>
Agreed. I can push it to drm-misc-next.
> For the other patches, I'd like to take a step back and try to solve the
> broader problem. IIRC we talked about this briefly already.
>
Yes, that's what we discussed on IRC some time ago.
> From my understanding, the problem of the current code is that removal
> of the firmware device is build around drivers (either DRM or fbdev).
> Everything works fine if a driver is bound to the firmware device and
> the native driver can remove it. In other case, we have to manually
And this is the common case, since most kernels will have some driver
that binds to a platform device registered to provide the firmware FB.
> disable sysfb and force-remove unbound firmware devices. And the
> patchset doesn't even cover firmware devices that come from DT nodes.
>
Indeed.
> But what we really want is to track resource ownership based on devices.
> When we add a firmware device (via sysfb or DT), we immediately add it
> to a list of firmware devices. When the native driver arrives, it can
> remove the firmware device even if no driver has been bound.
>
> We can also operate in the other way if the native drivers implicitly
> reserves the framebuffer range. If sysfb would try to register a
> firmware device in that range, he can let it fail. No more need to fully
> disable sysfb on the first arriving native device.
>
> We already track the memory ranges in drm aperture helpers. We'd need to
> move the code to a more prominent location (e.g., <linux/aperture.h>)
> and change fbdev to use it. Sysfb and DT code needs to insert platform
> devices upon creation. We can then implement the more fancy stuff, such
> as tracking native-device memory. (And if we ever get to fix all usage
> of Linux' request-mem-region, we can even move all the functionality there).
>
Agreed. And as mentioned, the race that these patches attempt to fix are for
the less common case when a native driver probes but either no generic driver
registered a framebuffer yet or the platform device wasn't registered yet.
But this can only happen if for example a native driver is built-in but the
generic driver is build as a module, which is not the common configuration.
What most distros do is the opposite, to have {simple,of,efi,vesa}fb or
simpledrm built-in and the native drivers built as modules.
So there's no rush to fix this by piling more hacks on top of the ones we
already have and instead try to fix it more properly as you suggested.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
