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@xxxxxxxxxxx> wrote: > >>> > >>> > >>> > >>> Den 29.07.2019 21.55, skrev Noralf Trønnes: > >>>> Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx> > >>>> --- > >>>> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
