linux-kernel - Re: [PATCHv1 00/14] omapdrm: DSI command mode panel 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: <d96752eb-45a0-9766-0022-7eb1594761af@ti.com>
Date:   Thu, 26 Oct 2017 14:59:10 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...com>
To:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>
CC:     Tony Lindgren <tony@...mide.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        <dri-devel@...ts.freedesktop.org>, <linux-omap@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

On 24/10/17 01:01, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Oct 13, 2017 at 10:12:08AM -0700, Tony Lindgren wrote:
>> * Tomi Valkeinen <tomi.valkeinen@...com> [171012 01:46]:
>>> On 29/09/17 16:26, Sebastian Reichel wrote:
>>>> Hi Tomi & Laurent,
>>>>
>>>> ping?
>>>
>>> I've been having quick glances at this every now and then, but I'm not
>>> sure what to do with the series.
>>>
>>> We have one work item that more or less overrides everything but
>>> critical fixes: moving to common DRM encoder/panel drivers. Anything
>>> that makes that work more difficult should be postponed.
>>>
>>> Especially patch 6 in this series most likely falls into that category,
>>> and might require a very different implementation with common DRM
>>> drivers. Also everything in panel-dsi-cm needs to be ported to a common
>>> DRM panel driver when can use them.
>>>
>>> So my gut feeling is that it's best to keep this out for now, and rework
>>> it after Laurent gets the common DRM drivers working with omapdrm.
>>
>> Laurent, got any other comments?
>>
>> Maybe some of patches can be already applied to shrink down this
>> set a bit?
> 
> I talked with Laurent at ELCE about this patchset and he is fine
> with this series going in before his work assuming its fine
> otherwise. He has not yet reviewed it, though and is busy the
> next two weeks.
> 
> Regarding the panel-dsi-cm porting work: I will take care of this
> once the driver uses common DRM drivers. I don't expect major
> problems once omapdrm implements common drm's mipi_dsi_host. I
> do use the standard DT properties already.
> 
> I do agree, that not applying this series makes Laurent's porting
> work easier, since he can rip out all of DSI. It's not used by
> anything except panel-dsi-cm, which is broken without this patchset.
> I don't think that's a fair thing to do, though.
> 
> P.S.: I got asked by different people about the status of this
> patchset, which is required for display support on N9, N950 and
> Droid 4. It's not just me and Tony, that are interested in this :)

Ok. If you agree to help with the DSI part in the future, I have no
problems applying these (after review and testing, of course).

My worry is not only with complicating Laurent's work towards common DRM
drivers, but also with the maintenance burden this brings. Keeping DSI
working in the future may be challenging due to the lack of users and
(easy to use) boards. I do have a N950 and OMAP4 Blaze Tablet, though,
so I'm able to test both command and video modes. But getting those boot
up is not always trivial, especially for the blaze tablet.

I've also spent many hours this year debugging obscure OMAP3 DSS HW
issues, so my opinion about adding more OMAP3 DSS features may be a bit
biased =).

I'll have a look at this series when I find a bit of spare time.

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki