Hi Arnd > > > dmaengine: shdma: use normal interface for passing slave id > > > > > > The shmobile platform is one of only two users of the slave_id field > > > in dma_slave_config, which is incompatible with the way that the > > > dmaengine API normally works. > > > > > > I've had a closer look at the existing code now and found that all > > > slave drivers that pass a slave_id in dma_slave_config for SH do that > > > right after passing the same ID into shdma_chan_filter, so we can just > > > rely on that. However, the various shdma drivers currently do not > > > remember the slave ID that was passed into the filter function when > > > used in non-DT mode and only check the value to find a matching channel, > > > unlike all other drivers. > > > > > > There might still be drivers that are not part of the kernel that rely > > > on setting the slave_id to some other value, so to be on the safe side, > > > this adds another 'real_slave_id' field to shdma_chan that remembers > > > the ID and uses it when a driver passes a zero slave_id in dma_slave_config, > > > like most drivers do. > > > > > > Eventually, the real_slave_id and slave_id fields should just get merged > > > into one field, but that requires other changes. > > > > > > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx> > > > ---- (snip) > I was actually hoping that you could pick up my patch and send it as a > follow-up to your series once you have a working version. As I mentioned, > the driver changes to remove the slave_id assignment can be done either > together with the base patch or as a follow-up. OK, I can do it if you want :) Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
