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

From: Daniel Vetter
Date: Mon Feb 23 2015 - 09:07:37 EST


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@xxxxxxxxxxxxxx> 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).

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.
-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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/