On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote: > > Or alternatively we could publish the limitations of the channel using > > capabilities so SPI knows I have a dmaengine channel and it can transfer max N > > length transfers so would be able to break rather than guessing it or coding > > in DT. Yes it may come from DT but that should be dmaengine driver rather > > than client driver :) > > > > This can be done by dma_get_slave_caps(chan, &caps) > > > > And we add max_length as one more parameter to existing set > > > > Also all this could be handled in generic SPI-dmaengine layer so that > > individual drivers don't have to code it in > > > > Let me know if this idea is okay, I can push the dmaengine bits... > > It would be ok if there was a fixed limit. However, the limit depends > on SPI slave settings. Presumably for other buses using the dmaengine > the limit would depend on the bus or slave settings as well. I do not > see a sane way of passing this all the way to the dmaengine driver. I don't see why this should be client (SPI) dependent. The max length supported is a dmaengine constraint, typically flowing from max blocks/length it can transfer. Know this limit can allow clients to split transfers. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
