| Message ID | 20200809215104.1830206-1-linus.walleij@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/panel: s6e63m0: Add DSI transport | expand |
Hi Linus. On Sun, Aug 09, 2020 at 11:51:00PM +0200, Linus Walleij wrote: > This begins to modify the Samsung S6E63M0 driver to provide > DSI support. > > After these initial changes the driver can already be used > with the Samsung GT-I8190 (Golden) phone. > > After this initial support we will make more changes to > support more gammas (more levels of backlight), special > biasing on different display types and handling of the > ESD IRQ. > > But let's begin with this. How does this patchset relate to the patchset posted by Paul? https://lore.kernel.org/dri-devel/20200727164613.19744-1-paul@crapouillou.net/ Seems that two different approcahes are used for the same type of problem. Is it possible to find a common solution? Sam > > Linus Walleij (4): > drm/panel: s6e63m0: Break out SPI transport > drm/panel: s6e63m0: Add DSI transport > drm/panel: s6e63m0: Add reading functionality > drm/panel: s6e63m0: Add code to identify panel > > drivers/gpu/drm/panel/Kconfig | 23 ++- > drivers/gpu/drm/panel/Makefile | 2 + > .../gpu/drm/panel/panel-samsung-s6e63m0-dsi.c | 145 +++++++++++++++++ > .../gpu/drm/panel/panel-samsung-s6e63m0-spi.c | 101 ++++++++++++ > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 146 ++++++++++-------- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.h | 13 ++ > 6 files changed, 363 insertions(+), 67 deletions(-) > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0-spi.c > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.h > > -- > 2.26.2
On Tue, Aug 18, 2020 at 7:10 PM Sam Ravnborg <sam@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. Yours, Linus Walleij
On Thu, Aug 27, 2020 at 11:04 AM Linus Walleij <linus.walleij@linaro.org> wrote: > On Tue, Aug 18, 2020 at 7:10 PM Sam Ravnborg <sam@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