On Wed, May 06, 2015 at 10:13:42AM +0200, Ludovic Desroches wrote: > > ah yes but then you can use the channel for either direction without setting > > slave_dma_config... > > > > I still need dma_slave_config. In my device_config function, I don't > copy the dma_slave_config but I take information from it to compute a > dev2mem and mem2dev configuration. Then I will select the right one in > the prep function. I think it's quite close from that you want. since you do not know the direction here, you dont know how to compute dev2mem or mem2dev configurations > > In the device_config, I convert the maxburst value to a comprehensive > one for my controller. If it is not a supported one then I'll return an > error? thats fine as long as direction is not used, implicitly as well > Are you okay with this procedure? If not, I have totally misunderstood > what you want... > > My concern is that a device can fill only what it needs in the > dma_slave_config structure. When doing the configuration, the controller > doesn't care about the direction as you asked but if a maxburst > configuration is not set, I will have a zero value which is not a valid > one. I will return an error but is not... Yes that is why many drivers will save configuration. Checking values for sanity makes sense. No point in accepting config for 64 max burst if device support upto 32! Then you use direction is prepare_ api to compute parameters and if you detect further errors in configuration for said txn then you are valid to return error. Again if client has sent one direction parameters and in prepare you will not return error as direction will be apt so current issue will be fixed as well -- ~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
