| Message ID | 20220707153952.32264-11-tzimmermann@suse.de |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fbdev: Maintain device ownership with aperture helpers | expand |
On 7/7/22 17:39, Thomas Zimmermann wrote: > When registering a generic framebuffer, automatically acquire ownership > of the framebuffer's I/O range. The device will now be handled by the > aperture helpers. Fbdev-based conflict handling is no longer required. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- > drivers/video/fbdev/core/fbmem.c | 33 ++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c > index 2237049327db..e556ad69f48f 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -13,6 +13,7 @@ > > #include <linux/module.h> > > +#include <linux/aperture.h> > #include <linux/compat.h> > #include <linux/types.h> > #include <linux/errno.h> > @@ -1739,6 +1740,32 @@ static void do_unregister_framebuffer(struct fb_info *fb_info) > put_fb_info(fb_info); > } > > +static int fbm_aperture_acquire_for_platform_device(struct fb_info *fb_info) > +{ What's the meaning of 'm' here ? Misc, memory ? I would just call it 'fb_'. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Hi Am 11.07.22 um 13:29 schrieb Javier Martinez Canillas: > On 7/7/22 17:39, Thomas Zimmermann wrote: >> When registering a generic framebuffer, automatically acquire ownership >> of the framebuffer's I/O range. The device will now be handled by the >> aperture helpers. Fbdev-based conflict handling is no longer required. >> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >> --- >> drivers/video/fbdev/core/fbmem.c | 33 ++++++++++++++++++++++++++++++++ >> 1 file changed, 33 insertions(+) >> >> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c >> index 2237049327db..e556ad69f48f 100644 >> --- a/drivers/video/fbdev/core/fbmem.c >> +++ b/drivers/video/fbdev/core/fbmem.c >> @@ -13,6 +13,7 @@ >> >> #include <linux/module.h> >> >> +#include <linux/aperture.h> >> #include <linux/compat.h> >> #include <linux/types.h> >> #include <linux/errno.h> >> @@ -1739,6 +1740,32 @@ static void do_unregister_framebuffer(struct fb_info *fb_info) >> put_fb_info(fb_info); >> } >> >> +static int fbm_aperture_acquire_for_platform_device(struct fb_info *fb_info) >> +{ > > What's the meaning of 'm' here ? Misc, memory ? I would just call it 'fb_'. 'managed' as in drmm_ But using fb_ is also good. I actually wasn't sure about this naming. Best regards Thomas > > Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> >
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 2237049327db..e556ad69f48f 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -13,6 +13,7 @@ #include <linux/module.h> +#include <linux/aperture.h> #include <linux/compat.h> #include <linux/types.h> #include <linux/errno.h> @@ -1739,6 +1740,32 @@ static void do_unregister_framebuffer(struct fb_info *fb_info) put_fb_info(fb_info); } +static int fbm_aperture_acquire_for_platform_device(struct fb_info *fb_info) +{ + struct apertures_struct *ap = fb_info->apertures; + struct device *dev = fb_info->device; + struct platform_device *pdev; + unsigned int i; + int ret; + + if (!ap) + return 0; + + if (!dev_is_platform(dev)) + return 0; + + pdev = to_platform_device(dev); + + for (ret = 0, i = 0; i < ap->count; ++i) { + ret = devm_aperture_acquire_for_platform_device(pdev, ap->ranges[i].base, + ap->ranges[i].size); + if (ret) + break; + } + + return ret; +} + /** * remove_conflicting_framebuffers - remove firmware-configured framebuffers * @a: memory range, users of which are to be removed @@ -1789,6 +1816,12 @@ register_framebuffer(struct fb_info *fb_info) { int ret; + if (fb_info->flags & FBINFO_MISC_FIRMWARE) { + ret = fbm_aperture_acquire_for_platform_device(fb_info); + if (ret) + return ret; + } + mutex_lock(®istration_lock); ret = do_register_framebuffer(fb_info); mutex_unlock(®istration_lock);
When registering a generic framebuffer, automatically acquire ownership of the framebuffer's I/O range. The device will now be handled by the aperture helpers. Fbdev-based conflict handling is no longer required. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> --- drivers/video/fbdev/core/fbmem.c | 33 ++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)