Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

On Tue, Jul 11, 2017 at 9:53 PM, Rob Clark [off-list ref] wrote:

On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter [off-list ref] wrote:

quoted

On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark [off-list ref] wrote:

quoted

On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter [off-list ref] wrote:

quoted

On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark [off-list ref] wrote:

quoted

+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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch