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