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

Powered by blists - more mailing lists