From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 14 Feb 2013 13:21:34 -0700 Subject: [U-Boot] [PATCH 05/14] spi: add common fdt SPI driver interface In-Reply-To: <20130214200750.GD32695@badger> References: <1360725802-5518-1-git-send-email-amartin@nvidia.com> <1360725802-5518-6-git-send-email-amartin@nvidia.com> <511C165D.50807@wwwdotorg.org> <20130214200750.GD32695@badger> Message-ID: <511D474E.7020003@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/14/2013 01:07 PM, Allen Martin wrote: > On Wed, Feb 13, 2013 at 02:40:29PM -0800, Stephen Warren wrote: >> On 02/12/2013 08:23 PM, Allen Martin wrote: >>> Add a common interface to fdt based SPI drivers. Each driver is >>> represented by a table entry in fdt_spi_drivers[]. If there are >>> multiple SPI drivers in the table, the first driver to return success >>> from spi_init() will be registered as the SPI driver. >> >> I don't think there should be a global concept of "the" SPI driver; >> instances of both SPI blocks exist on Tegra20, so they should be able to >> co-exist, using the SFLASH driver for 1 SPI port, and the SLINK driver >> for the other 4 ports. > > I agree, but that's probably beyond the scope of this series, as > that's a more global problem. Other drivers call directly into the > SPI driver by use of well known function names, so that would need to > be abstracted to fix. It should be simple to fix; you already have a table of all known (DT-based) SPI drivers; simply iterate over all entries in the table always, rather than stopping when you hit the first one. Also, don't store /a/ pointer to the driver, but store a pointer per instance. I think the modifications to your patch series to solve this shouldn't be large at all. >> How does this patch interact with any SPI-related device manager work? > > I'm not sure what device manager is in the context of u-boot. Is that > the same as the unified driver model that's being documented in > doc/driver-model? Yes. > If so I think this fits in really well with that. > The "struct ops" described there is almost identical to the callbacks > I added in "struct fdt_spi_driver" The code certainly looks like a move in the right direction. I was thinking more along the lines of: Is anyone actively working on this right now, so your patches will conflict.