Re: [PATCH 1/4] ARM: dts: omap3-n900: fix LCD reset line polarity

[Tony Lindgren <tony@atomide.com>]

Hi,

* Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> [221013 06:13]:
> I would just go with the above for the time being. It should be an easy
> change, and as these omapfb and drm panel drivers are kind of copies of each
> other, I think it makes sense to use the same code in both.

Maybe if a fix is needed, sure let's fix things first, then drop
the unused panel drivers.

We already have drivers/gpu/drm/panel driver for both of these two
omapfb panels:

drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c

The compatible strings used translate to these dts files:

arch/arm/boot/dts/motorola-mapphone-common.dtsi
arch/arm/boot/dts/omap3-n900.dts
arch/arm/boot/dts/omap3-n950.dts
arch/arm/boot/dts/omap4-sdp.dts

These devices work with omapdrm and there should not be any need to
stick with the omapfb driver. We can just drop the omapfb panel
drivers for panel-sony-acx565akm.c and panel-dsi-cm.c. Let's put
the limited effort where there is activity instead :)

The vrfb rotation work has been discussed on the lists, so seems
like we will eventually have that for omapdrm. Meanwhile, software
rotation is being used for postmarketos and leste with omapdrm
AFAIK.

> That said, I personally don't mind fixing the dts files and the drivers, and
> even dropping the omapfb panel drivers. However, as I don't know if someone
> needs the omapfb drivers or has to use an old dtb, I don't want to step on
> that possible mine field. If someone else wants to go there (without my
> involvement), fine for me =).

I belive the only valid use case for omap2 omapfb is the n8x0 rfbi
driver that has no omapdrm driver.

Regards,

Tony