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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Feb 2015 10:03:21 -0500
From:	Rob Clark <robdclark@...il.com>
To:	Rob Clark <robdclark@...il.com>,
	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>
Cc:	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 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..

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