[PATCH] drm: msm: Fix build when legacy fbdev support isn't set

Rob Clark robdclark at gmail.com
Mon Feb 23 07:03:21 PST 2015


On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
>> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja <architt at codeaurora.org> wrote:
>> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
>> > selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev
>> > support is disabled in msm. Wrap around these functions with #ifdef checks to
>> > prevent build break.
>>
>> hmm, perhaps rather than solving this in each driver, we should do
>> some stub versions of those fb-helper fxns?
>>
>> There are at least one or two other drivers that can build without
>> fbdev, and I guess more going forward..
>
> It's not quite that easy since you also have to start/stop the vt
> subsystem at the right point in time in your own driver. See
> intel_fbdev_set_suspend. If you don't do that there's no synchronization
> between fbcon shutting down/resuming and your driver, which in the best
> case means fbcon does some writes to nowhere and worst case means your
> chip dies (mmio to offline chip blocks) or writes go to somewhere random
> in system memory (iommu contains some stale ptes since not yet fully
> restored, more an issue with hibernate).

I guess I don't fully follow the vt/fbcon interaction if there is no
fbdev driver...  but then again I don't have vesafb/efifb to contend
with, so I'm assuming something to do with that..

> And because the console_lock is massively contended we do that in a async
> worker in i915.
>
> But anyway I agree it would still simply drivers quite a bit if we'd have
> support for dummy fb helpers in the core, maybe with an explicit Kconfig.
> Then drivers could switch to using that for the additional #ifdef (like
> the vt stuff i915 does) and otherwise rely upon dummy static inline. That
> would give us fbdev-less support for most drivers for free, which is kinda
> neat.

I guess at least for all the arm drivers, life without fbdev doesn't
have these extra complications, so at least they could use stubs..

Plus, I kind of expect phone/tablet/chromebook type stuff would lead
the charge into an fbdev-less world..

BR,
-R


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


More information about the dri-devel mailing list