From owner-freebsd-arm@FreeBSD.ORG Fri Mar 6 18:20:08 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC1A3714 for ; Fri, 6 Mar 2015 18:20:07 +0000 (UTC) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62E38DD8 for ; Fri, 6 Mar 2015 18:20:07 +0000 (UTC) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 06 Mar 2015 19:19:58 +0100 id 00DCAA26.54F9EFCE.000031BD Date: Fri, 6 Mar 2015 19:19:57 +0100 From: Milan Obuch To: Luiz Otavio O Souza Subject: Re: Raspberry Pi SPI device example? Message-ID: <20150306191957.0603e0f3@zeta.dino.sk> In-Reply-To: References: <20150216093418.3d1be83b@zeta.dino.sk> <20150219075342.7d2e7eec@zeta.dino.sk> <20150302124103.689135d3@zeta.dino.sk> <20150303215040.13f8439f@zeta.dino.sk> <20150305123903.1050694f@zeta.dino.sk> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i386-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Fri, 06 Mar 2015 18:20:08 -0000 On Fri, 6 Mar 2015 11:38:09 -0300 Luiz Otavio O Souza wrote: > On 5 March 2015 at 08:39, Milan Obuch wrote: [ snip ] > > With following result in dmesg: > > > > spi0: mem 0x204000-0x20401f irq 62 on > > simplebus0 spibus0: on spi0 > > tsc0: at cs 0 on spibus0 > > tsc0: chip id 00 00 (err 0) > > tsc1: at cs 1 on spibus0 > > tsc1: chip id 00 00 (err 0) > > > > As the first one is actually ILI9341, where undefined command 0x80 > > is treated as NOP, and the second one should read device > > identification of STMPE610, 0x811 according the docs, I think my > > SPI transaction does not work the expected way. Code snippet was > > taken from mx25l_get_status function almost verbatim, I did not > > find any docs for spibus, so that's the only source I have to > > study. Some description of various fields of spi_command structure > > would be helpfull, too, but there is none. > > > > Do I need anything more to do, like some pin setup or spi > > initialisation? I did not see anything like this in sources present > > in our tree. > > > > Again, any hint greatly appreciated. > > > > Regards, > > Milan > > The SPI driver for RPi uses interrupts to do the data tx/rx and as > such, it won't work that early (at proble/attach time). > > You have to use config_intrhook_establish() to set a callback that > will run when interrupts are enabled. > > Look at the mx25l patch to see how convert an existent driver: > http://loos.com.br/mx25l-fdt-intr.diff > > Regards, > Luiz OK, understand now, when I saw your patch for the first time, it was not clear to me why the modification is put there. Now I changed my code similarly and I am able to read chip id in start task. Your help is really appreciated. Now I get (dmesg | grep tsc) this: tsc0: at cs 1 on spibus0 tsc0: read 01 08 (err 0) tsc0: read 04 11 (err 0) tsc0: read 08 03 (err 0) tsc0: chip id 0811, rev. 03 Three 'read' lines are just kind of debug, they will be left out later. Now there is another problem to solve - there are two devices on the spibus0, ILI9341 and STMPE610, on chip selects 0 and 1 respectively. In the end, there will be 'ili' driver for the former and 'tsc' driver for the later. Both will use SPIBUS_TRANSFER to transfer their respective bytes, but could they interfere as they are on the same bus? Is it necessary to use some kind of protection against that or does spi bus driver ensure transfers cound not interfere? And one more question - STMPE610 is actually a spi/i2c connected register file, in my aplication spi is selected, and part of that register file controls touchscreen controller while other part is for some gpio. How to do that in a driver? Do we have an example of such a compound device in our sources? And how should this be described in FDT? As usual, all hints are welcomed. Regards, Milan