From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753245AbdEPQyZ (ORCPT ); Tue, 16 May 2017 12:54:25 -0400 Received: from galahad.ideasonboard.com ([185.26.127.97]:45888 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750876AbdEPQyY (ORCPT ); Tue, 16 May 2017 12:54:24 -0400 From: Laurent Pinchart To: Eric Anholt Cc: Rob Herring , dri-devel , Thierry Reding , Mark Rutland , Archit Taneja , Andrzej Hajda , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes. Date: Tue, 16 May 2017 19:54:30 +0300 Message-ID: <3768334.nZM7df9y4L@avalon> User-Agent: KMail/4.14.10 (Linux/4.9.16-gentoo; KDE/4.14.32; x86_64; ; ) In-Reply-To: <87h90ku4sq.fsf@eliezer.anholt.net> References: <20170511235625.22427-1-eric@anholt.net> <87h90ku4sq.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On Tuesday 16 May 2017 09:47:49 Eric Anholt wrote: > Rob Herring writes: > > On Mon, May 15, 2017 at 7:03 PM, Eric Anholt wrote: > >> Laurent Pinchart writes: > >>> Hi Eric, > >>> > >>> Thank you for the patch. > >>> > >>> On Thursday 11 May 2017 16:56:23 Eric Anholt wrote: > >>>> The Raspberry Pi 7" Touchscreen is a DPI touchscreen panel with > >>>> DSI->DPI bridge and touchscreen controller integrated, that connects > >>>> to the Raspberry Pi through its 15-pin "DSI" connector (some lines are > >>>> DSI, some lines are I2C). > >>>> > >>>> This device is represented in the DT as three nodes (DSI device, I2C > >>>> device, panel). Input will be left to a separate binding later, as it > >>>> will be a basic I2C client device. > >>>> > >>>> Signed-off-by: Eric Anholt > >>>> --- > >>>> > >>>> .../raspberrypi,7inch-touchscreen-bridge.txt | 68 ++++++++++++++ > >>>> .../panel/raspberrypi,7inch-touchscreen-panel.txt | 7 +++ > >>>> 2 files changed, 75 insertions(+) > >>>> create mode 100644 > >>>> > >>>> Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touc > >>>> hscreen-bridge.txt create mode 100644 > >>>> Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touch > >>>> screen-panel.txt > >>>> > >>>> diff --git > >>>> a/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to > >>>> uchscreen-bridge.txt > >>>> b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to > >>>> uchscreen-bridge.txt new file mode 100644 > >>>> index 000000000000..a5669beaf68f > >>>> --- /dev/null > >>>> +++ > >>>> b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to > >>>> uchscreen-bridge.txt > >>>> @@ -0,0 +1,68 @@ > >>>> +Official 7" (800x480) Raspberry Pi touchscreen panel's bridge. > >>>> + > >>>> +This DSI panel contains: > >>>> + > >>>> +- TC358762 DSI->DPI bridge > >>>> +- Atmel microcontroller on I2C for power sequencing the DSI bridge and > >>>> + controlling backlight > >>>> +- Touchscreen controller on I2C for touch input > >>>> + > >>>> +and this covers the TC358762 bridge and Atmel microcontroller, while > >>>> +../panel/raspberrypi,7inch-touchscreen-panel.txt covers the panel. > >>> > >>> The TC358762 is a standalone bridge that doesn't depend on the ATTiny > >>> microcontroller used by the RPI. As it's usable standalone, I believe > >>> this binding should be split in two. > >> > >> Do you have a plan for how I would implement a driver on top of that > >> binding change, though? Note that we don't program the Toshiba > >> directly, we only send commands to the Atmel. > > > > I agree. If it is a black box and the interface to the host is defined > > by the Atmel uC firmware, then that's what the DT should describe. > > Perhaps a diagram here or pointer to one would help and remove > > mentioning what kind of bridge chip it is. > > It's a *very* black box. I have some non-public schematics that don't > even say what panel is involved, and no documentation of the uc > interface. The driver code is just replicating the firmware's > programming sequence. > > I would certainly love to be building a generic TC358762 driver, which > would be a lot more satisfying. I just don't think it's doable for this > panel. Given that, what do I need to do to the DT? Should I just drop > mention of the Toshiba and talk about this being a bridge with a custom > microcontroller firmware? I think that would be best, yes. Could you share a simple block-diagram of the hardware ? It would help turning my random advices into semi-random advices :-) -- Regards, Laurent Pinchart