Hi Mike, On Thu, Apr 22, 2010 at 11:28:27PM -0400, Mike Frysinger wrote:
> +static short mmc_spi_init_card(struct mmc_spi_dev *pdev) > +{ > + unsigned short cntr = 0; > + > + /* for making init process beeing silent */ > + init_mode = 1; > + /* save length of log for external usage */ > + pdev->log_len = LOG_LEN; > + > + /* 10 bytes(80 cycles) with CS de-asserted */ > + mmc_spi_dummy_clocks(pdev, 10); > + pdev->doassert(); > + if (send_cmd_and_wait(pdev, GO_IDLE_STATE, 0, R1_IDLE_STATE, > MMC_INIT_TIMEOUT)) > + return 1; > + pdev->deassert(); > + /* Send One Byte Delay */ > + if (pdev->write(Null_Word, 1, pdev->priv_data) < 0) > + return 1; > + pdev->doassert(); [...] Is there any reason to use doassert() and deassert() except to generate the "dummy" cycles needed to initialize the card? Which driver does _need_ an explicit cs_activate() and cs_deactivate() outside the write() and read() functions? CS control is done automatically by most drivers. According to include/spi.h, the _board_code_ is supposed to supply spi_cs_[de]activate() to be used by the driver in case the hardware can not control the chip selects automatically. The documentation is not clear about it, but from my point of view spi_cs_[de]activate() are not part of the SPI API. I think we should not clutter client drivers with such implementation specific things. I have to clean up my code and try to migrate to your newer code base, but I did implement a modified version using SPI_XFER_BEGIN, spi_setup_slave() (to clear the CS) and SPI_CS_HIGH to achieve the CS switching in a way compliant with e.g. the coldfire SPI driver. (Although IIRC I had to add SPI_CS_HIGH there, too) Regards, Wolfgang _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot