Re: [PATCH 2/3] ARM: dts: am437x-gp/epos-evm: drop unused panel timings

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

 



Hi Tomi,

On Tue, Feb 11, 2020 at 12:01:31PM +0200, Tomi Valkeinen wrote:
> On 13/01/2020 14:01, Tomi Valkeinen wrote:
> > On 12/12/2019 22:35, Laurent Pinchart wrote:
> >> On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote:
> >>> On 11/12/2019 18:53, Tony Lindgren wrote:
> >>>> * Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> [191202 13:05]:
> >>>>> Hi Tomi,
> >>>>>
> >>>>> Thank you for the patch.
> >>>>>
> >>>>> On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote:
> >>>>>> panel-simple now handled panel osd070t1718-19ts, and we no longer need
> >>>>>> the panel timings in the DT file. So remove them.
> >>>>>
> >>>>> Should you in that case drop the panel-dpi compatible string too, as the
> >>>>> panel-dpi bindings require panel timings in DT ?
> >>>>
> >>>> Yeah sounds like if panel-dpi is no longer usable for this device it
> >>>> should be dropped from the compatible list.
> >>>
> >>> Ok, I agree.
> >>>
> >>> Looking at the dts files, panel-dpi is used in a bunch of boards. But
> >>> we even have 3 dts files with panel-dpi, without the detailed panel
> >>> model in compatible...
> >>>
> >>> Fixing those will break the compatibility with old dtbs and new
> >>> kernel, unless we add timings-from-dt to a panel driver that handles
> >>> panel-dpi.
> >>
> >> I know, and I don't have a perfect answer for this :-( I don't see a
> >> third option, it's either breaking DT backward compatibility or adding
> >> timings parsing to a panel driver (either a new panel-dpi driver or to
> >> panel-simple). What's your preferred option ?
> > 
> > Hmm, I just realized that changing these will break omapfb. It
> > relies on panel-dpi and timings from DT...
> 
> If no one objects, I think we should just drop the timings from the
> .dts, and say that these boards are no longer supported with omapfb. I
> don't think there's much point in trying to keep omapfb working fine
> for boards that are fully supported by omapdrm.

No objection from me.

> Hopefully soon (in five years? =) we can say that omapdrm supports all
> the boards, and we can deprecate omapfb.

I'd love to send a patch to remove omapfb, but I'll let you do the
honours :-)

-- 
Regards,

Laurent Pinchart



[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