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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87shjwy5tl.fsf@eliezer.anholt.net>
Date:   Mon, 22 May 2017 13:50:14 -0700
From:   Eric Anholt <eric@...olt.net>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Archit Taneja <architt@...eaurora.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        "devicetree\@vger.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

Laurent Pinchart <laurent.pinchart@...asonboard.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.

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)