| Message ID | 20160907090919.27187-1-wens@csie.org (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Headers | show |
Hi, On 07-09-16 11:09, Chen-Yu Tsai wrote: > simplefb gets unregister when a proper framebuffer driver comes in and > kicks it out. However the claimed clocks and regulators stay enabled > as they are only released in the platform device remove function, which > in theory would never get called. > > Move the clock/regulator cleanup into the framebuffer destroy callback, > which gets called as part of the framebuffer unregister process. > > Note this introduces asymmetry in how the resources are claimed and > released. > > Signed-off-by: Chen-Yu Tsai <wens@csie.org> Good catch, patch LGTM: Reviewed-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans > --- > drivers/video/fbdev/simplefb.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c > index e9cf19977285..3620d10a0d00 100644 > --- a/drivers/video/fbdev/simplefb.c > +++ b/drivers/video/fbdev/simplefb.c > @@ -74,8 +74,14 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue, > return 0; > } > > +struct simplefb_par; > +static void simplefb_clocks_destroy(struct simplefb_par *par); > +static void simplefb_regulators_destroy(struct simplefb_par *par); > + > static void simplefb_destroy(struct fb_info *info) > { > + simplefb_regulators_destroy(info->par); > + simplefb_clocks_destroy(info->par); > if (info->screen_base) > iounmap(info->screen_base); > } > @@ -487,11 +493,8 @@ error_fb_release: > static int simplefb_remove(struct platform_device *pdev) > { > struct fb_info *info = platform_get_drvdata(pdev); > - struct simplefb_par *par = info->par; > > unregister_framebuffer(info); > - simplefb_regulators_destroy(par); > - simplefb_clocks_destroy(par); > framebuffer_release(info); > > return 0; >
On Wed, Sep 7, 2016 at 11:09 AM, Chen-Yu Tsai <wens@csie.org> wrote: > simplefb gets unregister when a proper framebuffer driver comes in and > kicks it out. However the claimed clocks and regulators stay enabled > as they are only released in the platform device remove function, which > in theory would never get called. > > Move the clock/regulator cleanup into the framebuffer destroy callback, > which gets called as part of the framebuffer unregister process. Is this called before or after the new proper framebuffer driver kicks in? If before, it may cause glitches. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi, On 07-09-16 13:12, Geert Uytterhoeven wrote: > On Wed, Sep 7, 2016 at 11:09 AM, Chen-Yu Tsai <wens@csie.org> wrote: >> simplefb gets unregister when a proper framebuffer driver comes in and >> kicks it out. However the claimed clocks and regulators stay enabled >> as they are only released in the platform device remove function, which >> in theory would never get called. >> >> Move the clock/regulator cleanup into the framebuffer destroy callback, >> which gets called as part of the framebuffer unregister process. > > Is this called before or after the new proper framebuffer driver kicks in? > If before, it may cause glitches. It is called by the new proper framebuffer driver's probe method, so it can make sure that it has already claimed / enabled the clocks/regulators before it calls remove_conlicting_framebuffers, avoiding the glitch. Regards, Hans
Hi Hans, On Wed, Sep 7, 2016 at 1:29 PM, Hans de Goede <hdegoede@redhat.com> wrote: > On 07-09-16 13:12, Geert Uytterhoeven wrote: >> On Wed, Sep 7, 2016 at 11:09 AM, Chen-Yu Tsai <wens@csie.org> wrote: >>> simplefb gets unregister when a proper framebuffer driver comes in and >>> kicks it out. However the claimed clocks and regulators stay enabled >>> as they are only released in the platform device remove function, which >>> in theory would never get called. >>> >>> Move the clock/regulator cleanup into the framebuffer destroy callback, >>> which gets called as part of the framebuffer unregister process. >> >> >> Is this called before or after the new proper framebuffer driver kicks in? >> If before, it may cause glitches. > > > It is called by the new proper framebuffer driver's probe method, > so it can make sure that it has already claimed / enabled the > clocks/regulators before it calls remove_conlicting_framebuffers, > avoiding the glitch. OK, thx! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 07/09/16 12:09, Chen-Yu Tsai wrote: > simplefb gets unregister when a proper framebuffer driver comes in and > kicks it out. However the claimed clocks and regulators stay enabled > as they are only released in the platform device remove function, which > in theory would never get called. > > Move the clock/regulator cleanup into the framebuffer destroy callback, > which gets called as part of the framebuffer unregister process. > > Note this introduces asymmetry in how the resources are claimed and > released. > > Signed-off-by: Chen-Yu Tsai <wens@csie.org> > --- > drivers/video/fbdev/simplefb.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) Thanks, queued for 4.9. Tomi
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c index e9cf19977285..3620d10a0d00 100644 --- a/drivers/video/fbdev/simplefb.c +++ b/drivers/video/fbdev/simplefb.c @@ -74,8 +74,14 @@ static int simplefb_setcolreg(u_int regno, u_int red, u_int green, u_int blue, return 0; } +struct simplefb_par; +static void simplefb_clocks_destroy(struct simplefb_par *par); +static void simplefb_regulators_destroy(struct simplefb_par *par); + static void simplefb_destroy(struct fb_info *info) { + simplefb_regulators_destroy(info->par); + simplefb_clocks_destroy(info->par); if (info->screen_base) iounmap(info->screen_base); } @@ -487,11 +493,8 @@ error_fb_release: static int simplefb_remove(struct platform_device *pdev) { struct fb_info *info = platform_get_drvdata(pdev); - struct simplefb_par *par = info->par; unregister_framebuffer(info); - simplefb_regulators_destroy(par); - simplefb_clocks_destroy(par); framebuffer_release(info); return 0;
simplefb gets unregister when a proper framebuffer driver comes in and kicks it out. However the claimed clocks and regulators stay enabled as they are only released in the platform device remove function, which in theory would never get called. Move the clock/regulator cleanup into the framebuffer destroy callback, which gets called as part of the framebuffer unregister process. Note this introduces asymmetry in how the resources are claimed and released. Signed-off-by: Chen-Yu Tsai <wens@csie.org> --- drivers/video/fbdev/simplefb.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)