On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter <daniel@xxxxxxxx> 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@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). 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
