[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171027180035.i5iwyzxt7duhvz4w@earth>
Date: Fri, 27 Oct 2017 20:00:35 +0200
From: Sebastian Reichel <sebastian.reichel@...labora.co.uk>
To: Tomi Valkeinen <tomi.valkeinen@...com>
Cc: Tony Lindgren <tony@...mide.com>, linux-omap@...r.kernel.org,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support
Hi,
On Thu, Oct 26, 2017 at 02:59:10PM +0300, Tomi Valkeinen wrote:
> 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).
Sure.
> 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 have N950, N9 and Droid 4 (omap4 based).
All of them have command mode panels.
> 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 =).
This patchset is also for OMAP4 (Droid 4).
> I'll have a look at this series when I find a bit of spare time.
Thanks.
-- Sebastian
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists