On 05/18/2013 10:26 PM, Russell King - ARM Linux wrote:
On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
The device for tda998x yes, but not the driver. Anyway, Russel decided
to have tda998x probed by his drm_driver.
For the simple reason that _that_ is how DRM slave encoders work.
Sometimes, reading the code of the subsystem you're using is well
worth the effort.
I agree and add that the probing itself doesn't prevent you from using
DT for tda driver at all. You can still have an marvell,external-slave
property pointing to the phandle of tda node. With that you get the
adapter and i2c slave address for what is currently called
dove_tda19989.c and may become e.g. dove_ext_i2c.c. In tda998x_drv you
find the node and get all properties for input config or interrupt
gpio.
I have done that in the drivers before, but DT node parsing here is
_added_ to the driver as it can be used on other non-DT platforms as
well.
The connection of Dove LCD and tda998x is _not_ Cubox specific, it is
also on the D2Plug. To be precise, even "Dove LCD" is not Dove specific
as you can find the very same controller on other Marvell SoCs with
little differences.
Well, to spoil the argument a little, actually, the interconnection
between the two is in no way "standardized". There's many different
ways to wire the two chips together and have it work - because the
TDA998x chips have a set of input muxes and swaps which allow you to
connect the red, green, blue high/low nibbles in various ways and
still have a correctly working system. The TDA998x connectivity is
_highly_ configuable.
So, just because one board connects LCD_D0 (red bit 0) to a particular
pin on the TDA998x does not mean that another board does it that way
too.
So Jean-Francois is quite correct that this data needs to be provided
by the board in some manner. The question is - how to do that sensibly.
One possible stop-gap solution is to provide a default set which just
happens to match the cubox, and allow OF to override it. :)
While I agree, Rob may have a different view on that for tda998x ;)
There is so much to take care of like pixel format on lcd pins driving
an external encoder (_not_ only tda998x), what gpio pin is connected to
TDA interrupt line, one or two lcds, ...
Luckily, drivers/gpu/drm/i2c/tda998x.c does not make use of the IRQ
signal at present - it's fairly basic and it currently operates by
polling. Eventually, this could change of course. :)
Again, that is in the driver Jean-Francois has available. Make sure irq
handler runs in a separate thread from get_edid and hpd and you will
be interrupted on hpd. Having said, that should finally lead to the
slave encoder setting .connector_type and .polled as this is where you
know it.
Sebastian
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
