linux-kernel - Re: [PATCHv2 10/10] ARM: dts: n950: add display support

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]

Message-ID: <38bb9030-5244-1751-1606-4d6598139bf0@ti.com>
Date:   Fri, 24 Mar 2017 17:20:31 +0200
From:   Tomi Valkeinen <tomi.valkeinen@...com>
To:     Tony Lindgren <tony@...mide.com>
CC:     Sebastian Reichel <sre@...nel.org>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        David Airlie <airlied@...ux.ie>, <linux-omap@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv2 10/10] ARM: dts: n950: add display support

On 24/03/17 17:12, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@...com> [170324 08:01]:
>> On 24/03/17 16:29, Tony Lindgren wrote:
>>> * Sebastian Reichel <sre@...nel.org> [170304 16:45]:
>>>> Add basic panel support for the Nokia N950. It must be tweaked a
>>>> little bit later, since the panel was built into the device
>>>> upside-down. Also the first 5 and the last 5 pixels are covered
>>>> by plastic.
>>>
>>> This one seems safe to apply separately to shrink the pending
>>> patches a bit. Please confirm if that's the case and I'll apply
>>> this one.
>>
>> No, I think there are too many open questions to apply this one. And we
>> need to move to common DRM drivers at some point (hopefully soon) so the
>> bindings must be aligned with those if and when possible.
> 
> Hmm so what are the open questions and do you have in mind for
> the panel bindings?

Well, until we have driver that supports the panel without problems, we
can't be sure if we have everything in the binding. At least the TE was
missing or broken.

Normal videotimings don't really make sense for DSI command mode panels,
so I'm not overly enthusiastic in having them in the bindings. Possibly
that's the easy way to go, but I'm not sure yet.

There are the "TODO" parts in the bindings, that's a clear sign of open
questions.

I haven't looked at how the other DRM drivers handle DSI command mode
panels. That's something to study, before adding anything new to the
omap specific bindings.

> Naturally we still need to support the current bindings too.

Do the current bindings work? I guess they did work on omapfb... Do
these new bindings work with omapfb?

Generally speaking, I've been bitten badly enough with DT bindings that
weren't up to the task after all, and then changing the later was a
major pain (or working around it). So I'd rather not merge anything to
DT if there are any unclarities, and a driver not working which uses
those bindings is an unclarity. Especially if the only reason to merge
is to get a single patch out from a bigger patch series, without
actually enabling anything.

 Tomi

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