On Fri, Mar 16, 2012 at 2:04 PM, Guennadi Liakhovetski <[email protected]> wrote: > > * - We tell the controller to keep the chipselect active from the > * beginning of an mmc_host_ops.request until the end. So beware > * of SPI controller drivers that mis-handle the cs_change flag! > > is also not extremely optimistic... > I had actually tested MMC over bitbanging SPI to compare working of the spi-s3c64xx.c
>But anyway, my yesterday's patch-series > > http://sourceforge.net/mailarchive/forum.php?thread_name=Pine.LNX.4.64.1203152230190.2988%40axis700.grange&forum_name=spi-devel-general > > preserves that behaviour. But what I still don't understand: > > * ... On multi-device SPI busses > * with nothing blocking messages going to other devices, this is just > * a performance hint; starting a message to another device deselects > * this one. But in other cases, this can be used to ensure correctness. > * Some devices need protocol transactions to be built from a series of > * spi_message submissions, where the content of one message is determined > * by the results of previous messages and where the whole transaction > * ends when the chipselect goes intactive. > > So, is this just an optional "hint" or something, that must be obeyed to > to guarantee functionality? At least, my above proposal offers a method to > distinguish between those two cases. > Message to a different device unconditionally de-selects the current device(obviously). Other than mmc_spi.c, I never came across a protocol driver using it. But as quoted above, some devices actually count upon it. So implementing it is always a safe bet. -jassi ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
