Hi Javier.
On Thu, Jun 09, 2022 at 03:09:21PM +0200, Javier Martinez Canillas wrote:
Hello Thomas,
On 6/9/22 13:49, Thomas Zimmermann wrote:
Hi Javier
Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
From: Daniel Vetter daniel.vetter@ffwll.ch
Well except when the olpc dcon fbdev driver is enabled, that thing digs around in there in rather unfixable ways.
There is fb_client_register() to set up a 'client' on top of an fbdev. The client would then get messages about modesetting, blanks, removals, etc. But you'd probably need an OLPC to convert dcon, and the mechanism itself is somewhat unloved these days.
Your patch complicates the fbdev code AFAICT. So I'd either drop it or, even better, build a nicer interface for dcon.
The dcon driver appears to look only at the first entry. Maybe add fb_info_get_by_index() and fb_info_put() and export those. They would be trivial wrappers somewhere in fbmem.c:
#if IS_ENABLED(CONFIG_FB_OLPC_DCON) struct fb_info *fb_info_get_by_index(unsigned int index) { return get_fb_info(index); } EXPORT_SYMBOL() void fb_info_put(struct fb_info *fb_info) { put_fb_info(fb_info); } EXPORT_SYMBOL() #endif
In dcon itself, using the new interfaces will actually acquire a reference to keep the display alive. The code at [1] could be replaced. And a call to fb_info_put() needs to go into dcon_remove(). [2]
Thanks for your suggestions, that makes sense to me. I'll drop this patch from the set and post as a follow-up a different approach as you suggested.
To repeat myself from irc. olpc_dcon is a staging driver and we should avoid inventing anything in core code for to make staging drivers works. Geert suggested EXPORT_SYMPBOL_NS_GPL() that could work and narrow it down to olpc_dcon. The better approach is to mark said driver BROKEN and then someone can fix it it there is anyone who cares. Last commit to olpc_dcon was in 2019: e40219d5e4b2177bfd4d885e7b64e3b236af40ac and maybe Jerry Lin cares enough to fix it.
Added Jerry and Greg to the mail.
Sam