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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, Oct 13, 2022 at 02:08:54PM +0300, Tony Lindgren wrote:
> Hi,
> 
> * Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> [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 :)

FWIW

Acked-by: Sebastian Reichel <sre@xxxxxxxxxx>

for removal of those two omapfb panel drivers.

> 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.

Is that upstream? omapfb (and omapdrm) both have this:

	/*
	 * HACK
	 * We don't have a working driver for rfbi, so skip it here always.
	 * Otherwise dss will never get probed successfully, as it will wait
	 * for rfbi to get probed.
	 */
	if (strstr(dev_name(dev), "rfbi"))
		return 0;

I've seen a few old drivers being removed by marking them as BROKEN
(and updating Kconfig help text to explain the situation). Then the
code is dropped 1-2 cycles later assuming nobody complained.

-- Sebastian

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux