On Mon, Aug 4, 2014 at 9:25 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Sat, Aug 02, 2014 at 11:09:09AM +0200, Geert Uytterhoeven wrote: >> On Sat, Aug 2, 2014 at 4:06 AM, Brian Norris >> > On Wed, Jul 30, 2014 at 11:46:07AM +0100, Mark Brown wrote: > >> >> I don't know what DDR is in this context, sorry. > >> > I think it's just the ability to latch data on both the rising and >> > falling edges of the SPI clock. For SPI flash, it seems to be used for >> > the data portion of the opcode/address/data sequence. > >> > Yeah, I suppose it could be wedged in later if drivers/spi/ ever adopts >> > a solution. > >> I think this can just be another SPI_* spi_device.mode flag. > > Sounds like it yes - I was wondering if this might be one of the modes > with extra clock cycles that I've heard mentioned before which might be > a little more fun. > >> Do we need bindings for this in >> Documentation/devicetree/bindings/spi/spi-bus.txt? >> Unlike Quad SPI transfer support, this doesn't need special wiring, so DDR >> capability is an intrinsic property of the SPI slave, and the mode bit can just >> be set in the SPI slave driver, without any DT magic? > > Right, unless we run into things like board design issues causing > constraints this is something that can be enabled by the two drivers > without needing DT configuration. All: we plan resume this work. I need direction how go ahead further. I go through this email thread. The discussion focus on how to get dummy cycle information. Shijie get it from DT. Brain suggest get from CFI or map id table if I understand correct. Accodring to spec http://www.spansion.com/Support/Datasheets/S25FL128S_256S_00.pdf Table 8.10 Dummy cycle depend on frequency, read command. if information saved in driver, it will be huge table. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
