| Message ID | 20170711133822.31978-4-robdclark@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark <robdclark@gmail.com> wrote: > +static unsigned long hijack_firmware_fb(struct drm_device *dev) > +{ > + struct msm_drm_private *priv = dev->dev_private; > + unsigned long size; > + int i; > + > + /* if we have simplefb/efifb, find it's aperture and hijack > + * that before we kick out the firmware fb's. > + * > + * TODO we probably should hold registration_lock > + */ > + for (i = 0; i < FB_MAX; i++) { > + struct fb_info *fb = get_fb_info(i); > + > + if (IS_ERR_OR_NULL(fb)) > + continue; > + > + if (!fb->apertures->count) > + continue; > + > + /* if we find efifb or simplefb, we are about to > + * kick them out, so hijack their memory: > + */ > + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || > + (strcmp(fb->fix.id, "simple") == 0)) { > + > + priv->vram.paddr = fb->apertures->ranges[0].base; > + size = fb->apertures->ranges[0].size; > + } > + > + put_fb_info(fb); > + > + if (size) > + return size; > + } > + > + return 0; > +} I think this should be a helper function in at least drm_fb_helper.c, which would then fill in both base&size in a passed-in struct. But yeah this seems a lot better than the old one. In the future we could then also extend this with kicking out other firmware fb things. -Daniel
Quoting Rob Clark (2017-07-11 14:38:22) > +static unsigned long hijack_firmware_fb(struct drm_device *dev) > +{ > + struct msm_drm_private *priv = dev->dev_private; > + unsigned long size; > + int i; > + > + /* if we have simplefb/efifb, find it's aperture and hijack > + * that before we kick out the firmware fb's. > + * > + * TODO we probably should hold registration_lock > + */ > + for (i = 0; i < FB_MAX; i++) { > + struct fb_info *fb = get_fb_info(i); > + > + if (IS_ERR_OR_NULL(fb)) > + continue; > + > + if (!fb->apertures->count) Does get_fb_info() not return a reference if its apertures->count==0? > + continue; > + > + /* if we find efifb or simplefb, we are about to > + * kick them out, so hijack their memory: > + */ > + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || > + (strcmp(fb->fix.id, "simple") == 0)) { > + > + priv->vram.paddr = fb->apertures->ranges[0].base; > + size = fb->apertures->ranges[0].size; > + } > + > + put_fb_info(fb); > + > + if (size) > + return size; size is never initialised to 0. Perhaps just return the reference to the matching fb? Hopefully sidestepping a few of the worries about it disappearing during the probe. -Chris -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark <robdclark@gmail.com> wrote: >> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >> +{ >> + struct msm_drm_private *priv = dev->dev_private; >> + unsigned long size; >> + int i; >> + >> + /* if we have simplefb/efifb, find it's aperture and hijack >> + * that before we kick out the firmware fb's. >> + * >> + * TODO we probably should hold registration_lock >> + */ >> + for (i = 0; i < FB_MAX; i++) { >> + struct fb_info *fb = get_fb_info(i); >> + >> + if (IS_ERR_OR_NULL(fb)) >> + continue; >> + >> + if (!fb->apertures->count) >> + continue; >> + >> + /* if we find efifb or simplefb, we are about to >> + * kick them out, so hijack their memory: >> + */ >> + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || >> + (strcmp(fb->fix.id, "simple") == 0)) { >> + >> + priv->vram.paddr = fb->apertures->ranges[0].base; >> + size = fb->apertures->ranges[0].size; >> + } >> + >> + put_fb_info(fb); >> + >> + if (size) >> + return size; >> + } >> + >> + return 0; >> +} > > I think this should be a helper function in at least drm_fb_helper.c, > which would then fill in both base&size in a passed-in struct. But > yeah this seems a lot better than the old one. Yeah, I guess we could do that.. but probably not in drm_fb_helper.c since that is compile-time optional. Better suggestions about where it should live? If you have fbdev but not DRM_FBDEV_EMULATION you still want to do this, I think. Otherwise we can't completely take over the display setup by firmware (ie. no way to create plane->state->fb). BR, -R > In the future we could then also extend this with kicking out other > firmware fb things. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 11, 2017 at 10:17 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > Quoting Rob Clark (2017-07-11 14:38:22) >> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >> +{ >> + struct msm_drm_private *priv = dev->dev_private; >> + unsigned long size; >> + int i; >> + >> + /* if we have simplefb/efifb, find it's aperture and hijack >> + * that before we kick out the firmware fb's. >> + * >> + * TODO we probably should hold registration_lock >> + */ >> + for (i = 0; i < FB_MAX; i++) { >> + struct fb_info *fb = get_fb_info(i); >> + >> + if (IS_ERR_OR_NULL(fb)) >> + continue; >> + >> + if (!fb->apertures->count) > > Does get_fb_info() not return a reference if its apertures->count==0? yeah, you are right.. overlooked that when converting from iterating registered_fb[] table directly without taking a reference.. >> + continue; >> + >> + /* if we find efifb or simplefb, we are about to >> + * kick them out, so hijack their memory: >> + */ >> + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || >> + (strcmp(fb->fix.id, "simple") == 0)) { >> + >> + priv->vram.paddr = fb->apertures->ranges[0].base; >> + size = fb->apertures->ranges[0].size; >> + } >> + >> + put_fb_info(fb); >> + >> + if (size) >> + return size; > > size is never initialised to 0. Perhaps just return the reference to the > matching fb? Hopefully sidestepping a few of the worries about it > disappearing during the probe. I guess that would be a useful approach if I wanted a single helper that did both this and kicking out firmware fb's.. BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark <robdclark@gmail.com> wrote: > On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark <robdclark@gmail.com> wrote: >>> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >>> +{ >>> + struct msm_drm_private *priv = dev->dev_private; >>> + unsigned long size; >>> + int i; >>> + >>> + /* if we have simplefb/efifb, find it's aperture and hijack >>> + * that before we kick out the firmware fb's. >>> + * >>> + * TODO we probably should hold registration_lock >>> + */ >>> + for (i = 0; i < FB_MAX; i++) { >>> + struct fb_info *fb = get_fb_info(i); >>> + >>> + if (IS_ERR_OR_NULL(fb)) >>> + continue; >>> + >>> + if (!fb->apertures->count) >>> + continue; >>> + >>> + /* if we find efifb or simplefb, we are about to >>> + * kick them out, so hijack their memory: >>> + */ >>> + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || >>> + (strcmp(fb->fix.id, "simple") == 0)) { >>> + >>> + priv->vram.paddr = fb->apertures->ranges[0].base; >>> + size = fb->apertures->ranges[0].size; >>> + } >>> + >>> + put_fb_info(fb); >>> + >>> + if (size) >>> + return size; >>> + } >>> + >>> + return 0; >>> +} >> >> I think this should be a helper function in at least drm_fb_helper.c, >> which would then fill in both base&size in a passed-in struct. But >> yeah this seems a lot better than the old one. > > Yeah, I guess we could do that.. but probably not in drm_fb_helper.c > since that is compile-time optional. Better suggestions about where > it should live? If you have fbdev but not DRM_FBDEV_EMULATION you > still want to do this, I think. Otherwise we can't completely take > over the display setup by firmware (ie. no way to create > plane->state->fb). Hm right, maybe add a drm_fwfb_helper.c or so. If you look at i915_kick_out_vgacon(), that might be another candidate for that file. Putting it into fbdev itself seems like a bad idea, because maintenance pains. -Daniel
On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark <robdclark@gmail.com> wrote: >> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark <robdclark@gmail.com> wrote: >>>> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >>>> +{ >>>> + struct msm_drm_private *priv = dev->dev_private; >>>> + unsigned long size; >>>> + int i; >>>> + >>>> + /* if we have simplefb/efifb, find it's aperture and hijack >>>> + * that before we kick out the firmware fb's. >>>> + * >>>> + * TODO we probably should hold registration_lock >>>> + */ >>>> + for (i = 0; i < FB_MAX; i++) { >>>> + struct fb_info *fb = get_fb_info(i); >>>> + >>>> + if (IS_ERR_OR_NULL(fb)) >>>> + continue; >>>> + >>>> + if (!fb->apertures->count) >>>> + continue; >>>> + >>>> + /* if we find efifb or simplefb, we are about to >>>> + * kick them out, so hijack their memory: >>>> + */ >>>> + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || >>>> + (strcmp(fb->fix.id, "simple") == 0)) { >>>> + >>>> + priv->vram.paddr = fb->apertures->ranges[0].base; >>>> + size = fb->apertures->ranges[0].size; >>>> + } >>>> + >>>> + put_fb_info(fb); >>>> + >>>> + if (size) >>>> + return size; >>>> + } >>>> + >>>> + return 0; >>>> +} >>> >>> I think this should be a helper function in at least drm_fb_helper.c, >>> which would then fill in both base&size in a passed-in struct. But >>> yeah this seems a lot better than the old one. >> >> Yeah, I guess we could do that.. but probably not in drm_fb_helper.c >> since that is compile-time optional. Better suggestions about where >> it should live? If you have fbdev but not DRM_FBDEV_EMULATION you >> still want to do this, I think. Otherwise we can't completely take >> over the display setup by firmware (ie. no way to create >> plane->state->fb). > > Hm right, maybe add a drm_fwfb_helper.c or so. If you look at > i915_kick_out_vgacon(), that might be another candidate for that file. > Putting it into fbdev itself seems like a bad idea, because > maintenance pains. Hmm, would it be weird to have an: obj-$(CONFIG_FB) += drm_fbfw_helper.o in drm/Makefile? Or is there a better way to do that? I'm also wondering a bit about the CONFIG_FB=n case.. you might still have CONFIG_EFI, so maybe we should fall back to pulling this out of screen_info and looking for a simple-framebuffer node in the CONFIG_OF case? (also maybe worth noting that on ARM/ARM64 we don't have CONFIG_VGA_CONSOLE.. so there are a lot of fun permutations..) BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 11, 2017 at 9:53 PM, Rob Clark <robdclark@gmail.com> wrote: > On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark <robdclark@gmail.com> wrote: >>> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter <daniel@ffwll.ch> wrote: >>>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark <robdclark@gmail.com> wrote: >>>>> +static unsigned long hijack_firmware_fb(struct drm_device *dev) >>>>> +{ >>>>> + struct msm_drm_private *priv = dev->dev_private; >>>>> + unsigned long size; >>>>> + int i; >>>>> + >>>>> + /* if we have simplefb/efifb, find it's aperture and hijack >>>>> + * that before we kick out the firmware fb's. >>>>> + * >>>>> + * TODO we probably should hold registration_lock >>>>> + */ >>>>> + for (i = 0; i < FB_MAX; i++) { >>>>> + struct fb_info *fb = get_fb_info(i); >>>>> + >>>>> + if (IS_ERR_OR_NULL(fb)) >>>>> + continue; >>>>> + >>>>> + if (!fb->apertures->count) >>>>> + continue; >>>>> + >>>>> + /* if we find efifb or simplefb, we are about to >>>>> + * kick them out, so hijack their memory: >>>>> + */ >>>>> + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || >>>>> + (strcmp(fb->fix.id, "simple") == 0)) { >>>>> + >>>>> + priv->vram.paddr = fb->apertures->ranges[0].base; >>>>> + size = fb->apertures->ranges[0].size; >>>>> + } >>>>> + >>>>> + put_fb_info(fb); >>>>> + >>>>> + if (size) >>>>> + return size; >>>>> + } >>>>> + >>>>> + return 0; >>>>> +} >>>> >>>> I think this should be a helper function in at least drm_fb_helper.c, >>>> which would then fill in both base&size in a passed-in struct. But >>>> yeah this seems a lot better than the old one. >>> >>> Yeah, I guess we could do that.. but probably not in drm_fb_helper.c >>> since that is compile-time optional. Better suggestions about where >>> it should live? If you have fbdev but not DRM_FBDEV_EMULATION you >>> still want to do this, I think. Otherwise we can't completely take >>> over the display setup by firmware (ie. no way to create >>> plane->state->fb). >> >> Hm right, maybe add a drm_fwfb_helper.c or so. If you look at >> i915_kick_out_vgacon(), that might be another candidate for that file. >> Putting it into fbdev itself seems like a bad idea, because >> maintenance pains. > > Hmm, would it be weird to have an: > > obj-$(CONFIG_FB) += drm_fbfw_helper.o > > in drm/Makefile? Or is there a better way to do that? > > I'm also wondering a bit about the CONFIG_FB=n case.. you might still > have CONFIG_EFI, so maybe we should fall back to pulling this out of > screen_info and looking for a simple-framebuffer node in the CONFIG_OF > case? > > (also maybe worth noting that on ARM/ARM64 we don't have > CONFIG_VGA_CONSOLE.. so there are a lot of fun permutations..) I'd include the source always (because of the above, e.g. kicking vgacon doesn't depend on CONFIG_FB), and then we'll probably have to sprinkle a pile of ugly #ifdef all over that file. Still better to have these hacks in one place only at least. -Daniel
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index f487437fb9d0..7c1ff26a3c13 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -304,6 +304,45 @@ static void kick_out_firmware_fb(void) kfree(ap); } +static unsigned long hijack_firmware_fb(struct drm_device *dev) +{ + struct msm_drm_private *priv = dev->dev_private; + unsigned long size; + int i; + + /* if we have simplefb/efifb, find it's aperture and hijack + * that before we kick out the firmware fb's. + * + * TODO we probably should hold registration_lock + */ + for (i = 0; i < FB_MAX; i++) { + struct fb_info *fb = get_fb_info(i); + + if (IS_ERR_OR_NULL(fb)) + continue; + + if (!fb->apertures->count) + continue; + + /* if we find efifb or simplefb, we are about to + * kick them out, so hijack their memory: + */ + if ((strcmp(fb->fix.id, "EFI VGA") == 0) || + (strcmp(fb->fix.id, "simple") == 0)) { + + priv->vram.paddr = fb->apertures->ranges[0].base; + size = fb->apertures->ranges[0].size; + } + + put_fb_info(fb); + + if (size) + return size; + } + + return 0; +} + static int msm_init_vram(struct drm_device *dev) { struct msm_drm_private *priv = dev->dev_private; @@ -335,39 +374,46 @@ static int msm_init_vram(struct drm_device *dev) of_node_put(node); if (ret) return ret; - size = r.end - r.start; + size = r.end - r.start - 1; DRM_INFO("using VRAM carveout: %lx@%pa\n", size, &r.start); + } else if ((size = hijack_firmware_fb(dev))) { + DRM_INFO("hijacking VRAM carveout: %lx@%pa\n", + size, &priv->vram.paddr); + } else if (!iommu_present(&platform_bus_type)) { /* if we have no IOMMU, then we need to use carveout allocator. * Grab the entire CMA chunk carved out in early startup in * mach-msm: */ - } else if (!iommu_present(&platform_bus_type)) { DRM_INFO("using %s VRAM carveout\n", vram); size = memparse(vram, NULL); } if (size) { - unsigned long attrs = 0; - void *p; - priv->vram.size = size; - drm_mm_init(&priv->vram.mm, 0, (size >> PAGE_SHIFT) - 1); + drm_mm_init(&priv->vram.mm, 0, (size >> PAGE_SHIFT)); spin_lock_init(&priv->vram.lock); - attrs |= DMA_ATTR_NO_KERNEL_MAPPING; - attrs |= DMA_ATTR_WRITE_COMBINE; - - /* note that for no-kernel-mapping, the vaddr returned - * is bogus, but non-null if allocation succeeded: - */ - p = dma_alloc_attrs(dev->dev, size, - &priv->vram.paddr, GFP_KERNEL, attrs); - if (!p) { - dev_err(dev->dev, "failed to allocate VRAM\n"); - priv->vram.paddr = 0; - return -ENOMEM; + if (!priv->vram.paddr) { + unsigned long attrs = 0; + void *p; + + attrs |= DMA_ATTR_NO_KERNEL_MAPPING; + attrs |= DMA_ATTR_WRITE_COMBINE; + + /* note that for no-kernel-mapping, the vaddr returned + * is bogus, but non-null if allocation succeeded: + */ + p = dma_alloc_attrs(dev->dev, size, + &priv->vram.paddr, GFP_KERNEL, attrs); + if (!p) { + dev_err(dev->dev, "failed to allocate VRAM\n"); + priv->vram.paddr = 0; + return -ENOMEM; + } + } else { + request_region(priv->vram.paddr, size, "stolen"); } dev_info(dev->dev, "VRAM: %08x->%08x\n",
If we are kicking out efifb or simplefb then we want to hijack the outgoing fb's memory and wrap it in a gem object so that it can be allocated for use by fbdev helpers. This way we keep the same scanout buffer that the display is already using. This is prep-work for enabling drm/msm to take over a display that is enabled already by the bootloader. Signed-off-by: Rob Clark <robdclark@gmail.com> --- drivers/gpu/drm/msm/msm_drv.c | 82 +++++++++++++++++++++++++++++++++---------- 1 file changed, 64 insertions(+), 18 deletions(-)