From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Wed, 06 Feb 2008 11:22:15 -0500 Subject: [U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup() In-Reply-To: <200802061057.27603.vapier@gentoo.org> References: <1202214493-11719-1-git-send-email-hskinnemoen@atmel.com> <20080206105015.137863c3@dhcp-252-066.norway.atmel.com> <47A9CFDB.3090309@gmail.com> <200802061057.27603.vapier@gentoo.org> Message-ID: <47A9DEB7.8030300@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Mike Frysinger wrote: > On Wednesday 06 February 2008, Ben Warren wrote: > >> Haavard Skinnemoen wrote: >> >>> On Tue, 5 Feb 2008 23:34:46 -0500 >>> Mike Frysinger wrote: >>> >>>> there isnt a function to pair up with spi_setup() ? for example, the >>>> normal communication flow with a SPI flash: >>>> - spi_setup - turn on SPI >>>> - spi_cs_activate - assert CS >>>> - spi_xfer - >>>> - op code (read/write/erase) >>>> - address >>>> - actual block data >>>> - spi_cs_deactivate - deassert CS >>>> - ??? - turn off SPI >>>> >>> Right. I thought of spi_setup() more as a function that needs to be >>> called one time per slave to set up communications parameters, not >>> really for turning the SPI on as such. >>> >>> But perhaps it would make sense to combine those two functions. How >>> about we turn it into >>> >>> /* Set slave-specific parameters and enable SPI */ >>> int spi_claim_bus(int cs, unsigned int max_hz, unsigned int mode); >>> >>> /* Disable SPI */ >>> void spi_release_bus(int cs); >>> >>> The claim/release naming also makes it clear that the SPI device driver >>> has exclusive access to the bus between those two calls. >>> >> If there really is a need to turn off the controller, or change the >> transfer rate on the fly, then this is good. OTOH, this is a bootloader, >> not an OS, and probably the vast majority of use cases would just be to >> initialize the controller to a speed that all devices can handle, >> transfer some data to/from one or more devices, then boot an OS. Maybe >> some people need to do more, I don't know. >> > > U-Boot's design principles dictates that you get in, do your thing, and get > out. getting out means breaking down/releasing/turning off/however you want > to describe it. there is also the possibility of slight power savings as > Haavard points out. you could also have board functions that reuse the pins > for some other purpose (say they have muxing in place or something). > > True. I just want to be careful we don't over-engineer this... >>>> also, what's the deal with spi_xfer() taking a length in # of bits ? is >>>> it realistic to transmit anything less tan 8 bits ? the Linux kernel >>>> driver does not support this, so it cant be a big need ... >>>> >>> I don't know. That's unchanged from the original API. But I certainly >>> wouldn't object if we turned it into a length in bytes. >>> >> I seem to remember working with a Broadcom device where some of the >> transfers were odd numbers of nibbles (e.g. 12 bits). Not necessarily a >> reason to keep bit granularity, but I don't see a reason to artificially >> limit things either. >> > > but is there any real spi controllers that can transmit less than a byte at a > time ? i guess if you consider gpio-based soft spi ... > -mike > Sure, the Freescale SPI controller that I wrote a driver for (MPC8xxx) can send an arbitrary number of bits. Not sure exactly where that's useful, but my worldview is limited to high-powered telecom/datacom equipment. regards, Ben