Hi Eric, On Tuesday 16 May 2017 11:46:36 Eric Anholt wrote: [snip] > In terms of physical connections: > > [15-pin "DSI" connector on 2835] > > | I2C | DSI > / \ SPI | > [TS] [Atmel]------[TC358762] > \ | > \PWM | > \ | DPI > [some backlight]------[some unknown panel] > > The binding I'm trying to create is to expose what's necessary for a > driver that talks I2C to the Atmel, which then controls the PWM and does > the command sequence over SPI to the Toshiba that sets up its end of the > DSI link. According to the documentation I've been able to find, the TC358762 has an SPI master port through which it can output the commands DCS received from the DSI port, and an I2C slave port through which it can be configured by an external device. If the connection between the microcontroller and the TC358762 is indeed SPI and not I2C, I assume it's used by the microcontroller to receive the DCS commands and perform control of the backlight (and possibly other components) accordingly. By the way, is there any place where I can find a leaked version of the non-public panel schematics ? ;-) As far as I can tell from your patch series, you don't need to send any command to the TC358762 over DSI. In that case I would model the panel in DT as an I2C device, as all control goes through the I2C bus. The DSI video data connection should then be modelled using the OF graph DT bindings. The result will be a black box panel with a custom black box panel driver, using a single DT node. There's no need for a separate bridge instance. That's the cleanest option I can come up with so far, and I agree that splitting TC358762 support into a standalone bridge driver makes no sense in this case. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
