On Tue, Jul 11, 2017 at 9:53 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
> On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter <daniel@xxxxxxxx> wrote:
>> 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.
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
