[PATCH 0/4] drm/panel: s6e63m0: Add DSI transport

[Linus Walleij]

On Thu, Aug 27, 2020 at 11:04 AM Linus Walleij <linus.walleij at linaro.org> wrote:
> On Tue, Aug 18, 2020 at 7:10 PM Sam Ravnborg <sam at ravnborg.org> wrote:
>
> > How does this patchset relate to the patchset posted by Paul?
> > https://lore.kernel.org/dri-devel/20200727164613.19744-1-paul@crapouillou.net/
>
> Not much. S6E63M0 uses "spi" as it is right now and is not using
> the existing DBI code.
>
> So it would require it to start using the DBI core to begin with.
> If it can. Which is kind of an orthogonal task.
>
> What would be the defining character for it to
> be "DBI"? I do see that the driver sends MIPI standard commands
> over SPI. I suspect this is another standard without public specs...
>
> > Seems that two different approcahes are used for the same type of
> > problem.
>
> This approach is based on the approach from IIO, se e.g.:
> drivers/iio/accel/bmc150-accel-core.c
> drivers/iio/accel/bmc150-accel.h
> drivers/iio/accel/bmc150-accel-i2c.c
> drivers/iio/accel/bmc150-accel-spi.c
>
> > Is it possible to find a common solution?
>
> I'm happy to rework it any direction. If the other patch set is going to
> take time to finalize (as in: will not merge it the coming week, need to
> hack and stuff) then I'd prefer to apply this so I know my display works
> in v5.10. I can certainly rework it into Paul's framework when that
> arrives.

Is it OK to merge this as-is? I'm fishing for an ACK here...

I will certainly adapt to the DBI framework when/if it arrives,
and I think my track record makes that claim believeable.

Yours,
Linus Walleij