[RFC 4/4] drm/panel/ili9341: Support mi0283qt

[Daniel Vetter]

On Tue, Jul 30, 2019 at 07:33:28PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 30.07.2019 19.12, skrev Emil Velikov:
> > On 2019/07/30, Daniel Vetter wrote:
> >> On Tue, Jul 30, 2019 at 4:30 PM Noralf Trønnes <noralf at tronnes.org> wrote:
> >>>
> >>>
> >>>
> >>> Den 29.07.2019 21.55, skrev Noralf Trønnes:
> >>>> Signed-off-by: Noralf Trønnes <noralf at tronnes.org>
> >>>> ---
> >>>>  drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 179 ++++++++++++++++++-
> >>>>  1 file changed, 170 insertions(+), 9 deletions(-)
> >>>>
> >>>
> >>> I have realised that this will change the DRM driver name from mi0283qt
> >>> to drm_mipi_dbi. This means that this panel will loose its MESA kmsro[1]
> >>> support. I haven't tried it, but this is the first thing that gives this
> >>> driver any real advantage over its fbdev counterpart in
> >>> drivers/staging/fbtft, so I don't want to loose that.
> >>> So even if MIPI DBI panel support is implemented in some form, I will
> >>> wait with converting mi0283qt until someone has updated the kmsro driver.
> >>
> >> Why does it change? You should be able to stuff whatever you feel like
> >> into the drm driver name, this doesn't have to match either your
> >> platform/spi/whatever driver name nor the module option.
> > 
> > Last time i've looked DRM drivers using the mipi dsi helpers do _not_
> > have "drm_mipi_dsi" as their driver name. Hence drivers using the mipi
> > dbi should not have "drm_mipi_dbi".
> > 
> 
> What purpose does the DRM driver name serve for userspace?
> Why can't it be called drm_mipi_dbi? Because multiple panel drivers will
> use the same name? You're statement implies that there are some rules
> regarding DRM driver naming.

Worst case kmalloc a drm_driver at runtime and set the driver name to
match the panel name? Imo that makes sense for these
panel-as-full-drm_driver drivers ...

> > That said, we should probably highlight even more that the driver name
> > is an ABI.
> > 
> 
> This I didn't know.

kmsro and mesa in general uses it to figure out which userspace driver
needs to be loaded for which kernel driver. That makes it uapi, and yeah I
guess we should document it. I think aside from kmsro it's not relevant
for display-only drivers, but for anything that does rendering and has
custom ioctls it very much is the only real way to figure out what kind of
driver you have.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch