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

[Lucas Stach]

Hi Laurentiu,

Am Dienstag, den 28.05.2019, 10:04 +0000 schrieb Laurentiu Palcu:
> Lucas and Daniel,

[...]

> > > 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.
> > 
> > We've also made lots of improvements in the helpers, I think a clean
> > driver will be quiet a bit smaller than an imx based one. ARM is doing
> > the same with komeda and the malidp driver btw. Another option would
> > be 2 kms drivers in one .ko, which is what nouveau does with pre-nv50
> > and post-nv50. But that only makes sense if you have also the render
> > side in the same driver because it's all from the same vendor. msm is
> > similar, with msm4 vs msm5.
> > 
> > But for soc display-only I think two separate drivers, if the hw
> > really changed enough, is the best option. You can still stuff them
> > into the same subdir ofc.
> 
> Sounds good to me. I'll rewrite the DCSS driver and make it separate
> from imx-drm. Though, to be honest, this defeats the whole purpose of
> imx-drm in the first place... Wasn't this supposed to act like a glue
> and gather all i.MX related display controllers under the imx-drm
> umbrella?

Not really. We never had a plan to support all kinds of i.MX display
hardware in a single driver.

At some point imx-drm acted as the glue to bring all the components of
the i.MX display pipeline together, but much of that functionality has
since been split out and is now available as infrastructure in the
kernel, like the DRM bridges, devicetree graph bindings and device
links. All those infrastructure parts make it easy to write a separate
DRM driver, without duplicating lots of code from imx-drm.

It made sense to extend imx-drm as long as the hardware was close
and/or an extension to already existing hardware. But DCSS is totally
different from the currently supported IPU design.

> But, on the other hand, I agree it would be best, going forward, to have
> it separate. Easier to maintain and, most likely, simpler.

Seems we agree on the direction this should take. :)

Regards,
Lucas