[PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Lucas Stach]

Hi Shawn,

Am Dienstag, den 28.05.2019, 09:38 +0800 schrieb Shawn Guo:
> Hi Lucas,
> 
> On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > We have been looking at how to support DCSS in mainline for a while,
> > but most of the actual work got pushed behind in schedule due to other
> > priorities.
> 
> I have some time to contribute.  Would you suggest how I should help
> here?
> 
> 1. You guys already have something close to completion and do not need
>    more hands.
> 2. You guys already have some preliminary code and can use help from
>    others.
> 3. You guys haven't got anything to start with, but just some design
>    principles that anyone who wants to work on it should consider.
> 
> Which is the one that you want me to read?

Mostly the 3rd. We spent some time on getting the DCSS driver to work
on upstream kernel and familiarize with the hardware, but we don't have
any close to mainline quality code.

> > One thing I can can say for certain is that DCSS should not be
> > integrated into imx-drm. It's a totally different hardware and
> > downstream clearly shows that it's not a good idea to cram it into imx-
> > drm.
> 
> I haven't gone deeper into the vendor code, but from a brief looking I
> didn't see so many problems with integrating DCSS into imx-drm.  It's
> not so unreasonable to take imx-drm as an imx-display-subsystem which
> can have multiple CRTCs.  So can you please elaborate a bit on why it's
> really a bad idea?

It's a totally different hardware, with very different behavior, so
there is basically no potential for any code sharing. The downstream
driver is a hell of "oh, things are different here, let's introduce yet
another function pointer to make the distinction between the HW". It
complicates the imx-drm for no good reason. Our experience with imx-drm 
is that it is already at a complexity level that makes it hard to
reason about things when hunting bugs.

The boiler plate required to write a atomic KMS driver is not that
much, so I would rather have a clean split between the two hardware
drivers. Frankly they don't share anything except both being a atomic
KMS driver and running on a SoC called i.MX.

> > Also the artificial split between hardware control in
> > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > no video input capabilities the driver could be simplified a lot by
> > moving it all into a single DRM driver.
> 
> Agreed on this.

Regards,
Lucas