linux-kernel - Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

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:   Fri, 17 Mar 2017 17:45:34 -0700
From:   Eric Anholt <eric@...olt.net>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     dri-devel@...ts.freedesktop.org, tom.cooksey@....com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

Russell King - ARM Linux <linux@...linux.org.uk> writes:

> On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote:
>> This is a modesetting driver for the pl111 CLCD display controller
>> found on various ARM platforms such as the Versatile Express. The
>> driver has only been tested on the bcm911360_entphn platform so far,
>> with PRIME-based buffer sharing between vc4 and clcd.
>> 
>> It reuses the existing devicetree binding, while not using quite as
>> many of its properties as the fbdev driver does (those are left for
>> future work).
>
> As we're multiplatform on ARM, and this is using the PL11x AMBA IDs,
> we must ensure that it's compatible with everything that the fbdev
> driver is compatible with... however, I suspect that's not worth the
> effort (unless Linus W wants it?)
>
> If we make it PL111 specific, then we don't need to handle Integrator
> CP, or the Versatile PB/AB weirdness.  The only thing left is the
> power etc enable bits on Realview which uses the PL111.  See the
> code for Realview in drivers/video/fbdev/amba-clcd-versatile.c.

Restricting to PL111 for now sounds good to me.

Those Realview bits look like they're turning on a power domain --
shouldn't we represent those as a regulator or a power domain?  If we
did, then plugging that into a panel driver sounds straightforward.
(that's assuming that they're powering panel. not the controller -- I
can't quite tell from the code I've browsed so far)


Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)