On Fri, Feb 5, 2016 at 4:30 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: >>> + clk_div = DIV_ROUND_UP(clk_get_rate(spi_engine->ref_clk), >>> + xfer->speed_hz * 2); >> >>> + if (clk_div > 255) >>> + clk_div = 255; >>> + else if (clk_div > 0) >>> + clk_div -= 1; >> >> 255 is okay, 254 is not, 253- is okay. Why 254 is so special? > > I don't see that. The condition is > 255, so everything greater or equal > than 256 gets mapped to 255. Everything else to x - 1, so 255 to 254, 254 to > 253. Ah, you are right. >>> + for (i = 0; i < m; i++) >>> + writel_relaxed(buf[i], addr); >> >> writesl() ? > > Hm, maybe. Does it really have the same semantics? It's a loop inside, so it has a count parameter. Otherwise it should be similar. >>> +static int spi_engine_transfer_one_message(struct spi_master *master, >>> + struct spi_message *msg) >> >> And you are not using transfer_one() because of..? > > transfer_one() does flow control in software. Execution is passed back to > software after each transfer and it also takes care of handling the chip > select assertion/deassertion as well as the delays. It's useful for hardware > which does not support hardware flow control. In this case the hardware > supports flow control including chip-select logic as well as delays. Making > use of this generates far less context switches per message and also has > predictable timings between transfers within a message. Maybe the hardware flow control implementation is needed? Do we have more SPI hosts that support HW flow control? -- With Best Regards, Andy Shevchenko -- 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
