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 <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
