On 03/19/2015 07:05 AM, Greg Knight wrote: > Hi, Mark, > > I've attached a patch which adds a device-tree field "ti,dma-min-bytes" > which replaces the macro DMA_MIN_BYTES. Adjusting this field addresses > issues we've had where, in our particular use case, the usleep() in the > SPI worker thread eats a full 20% of our CPU (AM3359). > > I opted to implement it as a device-tree parameter and keep the original > value (160) as the default, in order to avoid impacting anyone else. > > The patch is attached. Patches 1-2 are an unrelated McASP change (see my > other message). > > What is the process for getting this upstreamed? Please follow the guidelines in Documentation/SubmittingPatches. Patches as attachments are not preferred since it makes replying/commenting on the patches hard. Strictly speaking the dma-min-bytes should not be in DT, it is a software parameter for the Linux SPI driver implementation. Also, when changing DT bindings, please update the documentation as well (and CC the relevant lists with that). This threshold of 160 bytes in the omap2-mcspi driver is artificial anyways it is changed from 8 to 160 by this commit: 8b66c13474e16 spi/omap2_mcspi: change default DMA_MIN_BYTES value to 160 It has been changed because of wl1271, but I'm not sure if banging bytes over the bus when the transfer is less then 160bytes is that great thing. I would guess that the sweet spot is at around the low tens. But if it is really like this that different devices perform better with different threshold for choosing between PIO or DMA transfer then this setting should come from the slave device and should only affect the transfer setup when communicating with that device. Probably adding a parameter (optional) to spi_device struct, so drivers can pass dma_over_poi_threshold? If it is not set, than just use whatever is the default. But I don't think this setting should be in the DT. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
