On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter <daniel@xxxxxxxx> wrote:
>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark <robdclark@xxxxxxxxx> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
