[Letux-kernel] drm/omap: Remove panel-dpi driver

Tomi Valkeinen tomi.valkeinen at ti.com
Thu Apr 11 09:19:46 CEST 2019


On 11/04/2019 09:57, H. Nikolaus Schaller wrote:
> 
>> Am 11.04.2019 um 08:32 schrieb Tomi Valkeinen <tomi.valkeinen at ti.com>:
>>
>> On 11/04/2019 09:14, H. Nikolaus Schaller wrote:
>>
>>>> You will need the panel data to be added to the simple panel driver, as
>>>> it won't read the timings from the DT (unfortunately, in my opinion).
>>>
>>> Hm. How does this work? Is there a description? I have no experience with
>>> DRM simple panel.
>>
>> See drivers/gpu/drm/panel/panel-simple.c, it just has a list of
>> compatibles, and pointers to the (more or less) same data as is in the
>> DT. And see a commit that adds a new panel, e.g. "drm/panel: simple: Add
>> OSD070T1718-19TS panel support".
> 
> Ok, I see. So the task is converting the nice and tested DTS properties to
> magic numbers in code... Let's hope without introducing new bugs.

Yes, it's unfortunately easy to make mistakes there (been there, done
that). A good and simple thing to do here is first do a DSS regdump with
the old kernel and panel-dpi. Then do the same with the new kernel and
simple panel. And compare.

>>> So with this DTB stability policy in mind it seems too early to remove the
>>> panel-dpi driver unless there is a compatible solution which does not break
>>> existing DTB.
>>
>> Well, maybe just reverting "drm/omap: Remove panel-dpi driver" would be
>> enough. I didn't try, but I think all the plumbing is still there to
>> keep the legacy omapdrm panels working.
>>
>> If I'm not mistaken, Laurent did try to get the simple-panel to get the
>> timings from the DT, but it was rejected.
> 
> What has been the reason?

In-driver embedded panel database was the approach chosen for
panel-simple, and the approach maintained by its maintainer.

> I can only imagine one: if several boards use the same panel it is easier
> to define the timings once for all. And the only location where this can
> happen is the (common) driver. Unless there will be some dts/panels/$panelname.dtsi
> which every DTS can/must include.
> 
>> Perhaps backward-compatibility
>> with out-of-tree dtbs would be a valid reason to get it accepted?
>> Laurent, what do you think?
> 
> And a second argument may be: with all these tables in simple-panel we carry
> along a big set (ca. 60?) of unused code and struct drm_display_mode tables.
> With timings from DT we just have the timings a specific device needs.
> 
> My assumption would be that the DTB approach needs a lot less code/data
> (unless someone adds a big set of CONFIG options to the simple panel driver).

This has been discussed back and forth during the years, multiple times.
Both approaches have the pros and cons. I can't even recall all the
reasons, either way, but your points above are valid.

>> That said, in my opinion, we should not care too much about out-of-tree
>> stuff. It's a nightmare to support things that you're not even aware of.
> 
> I basically agree, but learned from the gpiolib/spi-cs-high discussion
> that this is not the general view.
> 
>> In this particular case, adding the out-of-tree panels to simple-panel
>> should be a very straightforward task, and doesn't need a change in the
>> dtbs themselves.
> 
> Yes, but it is unnecessary work which distracts us from doing significant
> things...

I agree, but it also goes the other way around: if we spend time on
mainline to ensure backward compatibility with out-of-tree code, that
time is away from doing significant things =).

But for this particular problem at hand, see if reverting the patch I
mentioned helps. That should be a quick fix. I don't want to revert it
in mainline, because that will then prevent us from using simple-panel.

Sooner or later the panel-simple needs to be extended to support your
panels, though, as that's the only long term solution (or the maintainer
to agree adding DT parsing code, which I find unlikely).

We _have_ to move to common DRM panels and bridges, rather sooner than
later. This transition period is a bit difficult for all sides,
unfortunately. But we've done our best to not break things.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


More information about the Letux-kernel mailing list