Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Eric Anholt <eric@anholt.net>]

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

Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:

> 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 ? ;-)

Not that I know of.

I don't know that you can control the backlight over DCS, given that I
have no docs.  We only send commands from Atmel to TC, not the other way
around.

> 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.

I agree, it's just that when I submitted to drm-panel I was told that it
didn't make sense as a single driver, so I went to all of this work
instead.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]