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.