Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3806 bytes --]

On 12/05/14 18:51, Tony Lindgren wrote:

>> It's already in v3.15.
> 
> Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
> even acked it :( Looks like there's also the custom mux hacks. And
> custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add

The omap2_dss_hwmod_data, create_dss_pdev and create_simple_dss_pdev,
omap_display_init stuff can be removed when the DT conversion has been done.

For the omap4_dsi_mux_pads (or the omap5 dsi muxing that was recently
discussed) I still have no solution, but I haven't spent time on it. I
have dropped the omap5 dsi muxing from the latest series for that reason.

dispc_disable_outputs and omap_dss_reset are needed because omap_device
doesn't handle resetting DSS properly, as special steps need to be done
for that. omap_dss_reset is called from the hwmod/omap_device code, so I
don't think this code can be anywhere else.

For the omap_display_get_version() I have no good solution. Making
separate .dts versions for all the needed OMAP ES versions seems like a
huge hassle to me, but that is one solution.

I think that would mean having separate .dtsi files for omapdss for
omap3_es1, omap3_es3plus, omap4_es1, omap4_es2, omap4_es3plus, and then
having separate omapxxxx.dtsi files for all of those, and then separate
board .dts files for the ES versions used on each board.

Or is there some sane way to define such things in dts?

> _any_ new crap into arch/arm/mach-omap2/display.c.
> 
> So please consider this a huge eternal NAK to add any more crap to
> arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
> the soc_is_am43xx() you have in linux next. No more adding 
> of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
> 
> And no more new panel remapping in this file as soon as you have found
> a better solution. Preferrably by v3.17 merge window. This file just
> needs to disappear. Yuk.

Do you object to the compatible string remapping as such, or just that
it's in arch/arm/mach-omap2?

I guess nothing prevents me from moving it to drivers/, and having some
early-ish initcall doing the job.

If the remapping as such is horrible, I'm all ears for better ideas. I
spent quite a lot of time on it, and that's the best I could come up with.

It's rather simple prefixing of the compatible strings for selected
devices. The purpose of that is to have proper data in the .dts files
(which I think is very important) with the cost of having some rather
simple internal hacks in the kernel, which can be removed immediately
when we have a common display driver framework.

>> I'm not sure what it would give us to try to be compatible with
>> simple-panel.txt. The simple-panel bindings won't probably be compatible
>> with the future common display drivers in any case, as the simple-panel
>> binding is just too limited and doesn't describe the hardware fully.
> 
> Hmm what else does a panel need where the existing binding cannot be
> extended? 

The existing simple-panel binding doesn't describe the connections of
the panel, i.e. its video input. I guess it can be extended, but I don't
see what the benefit is of trying to create new panel bindings
compatible with the simple-panel bindings. As I see, the simple-panel
bindings work only with very limited use cases, where the drivers make
assumptions. Simple panel bindings cannot be used with omapdss, nor can
it be used with the future common display framework.

But I'm not really familiar with using extending current bindings, and
making new bindings compatible with old ones. Can you explain why it'd
be good to have the sharp panel bindings compatible with simple-panel?
In what kind of scenario would it be used?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]