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-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
