From owner-freebsd-arm@FreeBSD.ORG Tue Mar 10 03:25:05 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60710C38 for ; Tue, 10 Mar 2015 03:25:05 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7DBA232 for ; Tue, 10 Mar 2015 03:25:04 +0000 (UTC) Received: by wghk14 with SMTP id k14so25900254wgh.3 for ; Mon, 09 Mar 2015 20:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tmUpvpeeGxlgpfpkP7V0AJHG1Vucn5gZoxoH1g5klOk=; b=ZLARBN4puPvzFb77s18CTCAfcKRK0meeVS9Br2fYKfZ5gdrPNg19LoITxN/SUvJCvy TMax0k+FDMw5DMA41raUQBxE4Ylz7utIKYQ35aO+jM55bLMT0YWGg8yuxbzZoS/lmErv tKW+vnd84s4El2n8OuQ5tfYQDOn2wzjZpnoNANnX1hKQ66ONmN/JHBV3F/tyLJmpILcO UFlMc+H85GvOnBsHAVRRIEGJAPTaAU0M1B0tHpnHOKYUX9KenAFiYj2awSaTv39RG4f2 fXNXFfLR68Q/CI+X5k3aLxWIRCO00TdZMVrL+cD6HbrIbmeOqQa0sXn280BXmnqoTuFO x8eg== MIME-Version: 1.0 X-Received: by 10.194.24.35 with SMTP id r3mr4119771wjf.125.1425957903061; Mon, 09 Mar 2015 20:25:03 -0700 (PDT) Received: by 10.180.195.99 with HTTP; Mon, 9 Mar 2015 20:25:02 -0700 (PDT) In-Reply-To: <20150308204438.18f403a1@zeta.dino.sk> References: <20150308204438.18f403a1@zeta.dino.sk> Date: Tue, 10 Mar 2015 00:25:02 -0300 Message-ID: Subject: Re: Raspberry Pi and PiTFT display - problem with driver From: Luiz Otavio O Souza To: Milan Obuch Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 03:25:05 -0000 On 8 March 2015 at 16:44, Milan Obuch wrote: > Hi, > > I am trying to write a driver for PiTFT display, small 320x240 pixel > panel with touch screen. From software perspective, there are two > devices, touch screen controller with GPIO expander, STMPE610, and TFT > display controller/driver, ILI9341. Both are connected via SPI bus, > with one GPIO pin for the later. > > This is where a problem is - I found a way how to use SPI bus to > program STMPE610, how to read and write to its register, at present, > read chip identification and set/reset GPIO used to control LED > backlight. I did it a bit hackish for now, using sysctl, but it is > simple to use and works. Definitive aproach should be to create a child > device, gpioc, possibly, but it is much more complicated and takes more > time to do. > > ILI9341, on the other side, uses SPI with GPIO, so there is a question > how to do this - and, because this GPIO pin is used as 'command byte > flag', it is quite vital for proper function. > > So, first, how can I describe this requirement in FDT? Currently, I > just put there simple fragment: > > spi0 { > ili0 { > compatible = "st,ili"; > spi-chipselect = <0>; > }; > > tsc0 { > compatible = "st,stmpe_tc"; > spi-chipselect = <1>; > }; > }; > > but this does not descibe fact ILI9341 uses one GPIO pin, in case of > PiTFT, GPIO 25. It is in some way similar to what gpioiic does, but > there is only one parent device, while I have two, spi bus and gpio > pin... I need some hint... > > Second, I need some way to 'acquire' this pin in driver, so it is not > possible to change its status with gpioctl, and obtain correct values > for use in GPIOBUS_PIN_* calls to set pin's value. > > Third, it is not yet clear to me how would be the best way to implement > this. According the docs, ILI9341 is programmed with series of short > data exchanges, with exactly one command byte send to device, being > flagged with active DC pin (connected to GPIO 25), followed with short > series of bytes being written to device or, in case of status read and > similar, being read from device, all with DC pin being inactive. DC is > short for 'data/command'. > > Anybody out there with some hint? I will try to write something working > first, which will be surely not nice at the beginning, but it is much > easier to change something you know a bit about already... > > Regards, > Milan Hi, If you need help with the GPIO expander on STMPE610, let me know. Whenever is possible, we should try to use the default/vendor DTS for device. I think this is the one used by PiTFT: https://github.com/notro/fbtft/blob/master/dts/rpi.dts [...] &spi0 { pitft@0{ compatible = "ilitek,ili9340"; reg = <0>; status = "disabled"; spi-max-frequency = <32000000>; rotate = <90>; bgr; buswidth = <8>; dc-gpios = <&gpio 25 0>; [...] In this case you can make use of ofw_gpiobus_parse_gpios() to parse the 'dc-gpios' property, here is an usage example: http://pastebin.com/4mbZFuv1 The struct gpiobus_pin contains everything you need to manipulate the GPIO pin (as in the example). Luiz