Message-ID: <20150223153940.GZ24485@phenom.ffwll.local>
Date:	Mon, 23 Feb 2015 16:39:40 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Rob Clark <robdclark@...il.com>
Cc:	Archit Taneja <architt@...eaurora.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set

On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
> On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter <daniel@...ll.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@...eaurora.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..

It's the other way round: There's interaction when we have fbdev enabled
beyond just calling a few fbdev helper functions. And we should compile
that out too since the console_lock is way too evil ;-)

Only with these additional #ifdefs is i915 completely console_lock free if
you disable i915 fbdev support. Just stubbing out the fbdev helper
functions is not enough.

> > 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..

Does the problem sound more tricky with the above clarification? If you
don't do the fb_set_suspend call then I expect you'll have some
interesting problems.

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

Yeah, that's another reason to support fbdev-less in the helpers instead
of each driver.
-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists