On Tuesday 29 July 2014 18:49:14 Andy Shevchenko wrote: > > > > > > > > It sets the dw_dma_slave information from slave_data_ptr(sl) here, > > > > and does not attempt to set a slave_id at all, the slave_config > > > > call only sets the required fields. > > > > > > > > Do you still see a problem here? > > > > > > Sorry, I was talking about master defaults regarding to your patch that > > > proposes to remove that part from dw_dmac. I mean it should be set in > > > function mentioned early. > > > > Ok. So atmci_filter is still correct because chan->private contains > > a pointer to a structure with both request and master settings, right? > > Right, but we can't set them unconditionally in set_runtime_config(). > > Currently I have implemented "generic" filter function for dw_dmac users > (under linux/dw_dmac.h of course). It filters channel and assigns > necessary data (request line, masters) to the structure. We converted > SPI and HSUART to use it. Besides it has dependency to an actual DMA > driver (which is dependent on hardware), it looks more or less okay and > it works. > > But for the Atmel drivers we have to reuse it or leave that code you > suggested to remove in the dw/core.c. > > Or we can use private dw_dma_slave structure for the SPI/UART cases with > the additional field of request line. In such case filter function could > be really simple and we may unconditionally set data in > set_runtime_config(). Also we have to require users to provide that > structure. > > Latter looks better for me. Right. Actually dw_dma_slave contains cfg_hi/cfg_lo register values, which IIRC are equivalent to request line numbers, just in a less convenient format for the user. Adding the request line would be easy, but replacing the registers with the request line may be even better. > > I think for each PCI ID, you will have to add the > > correct settings to some table that is used in the filter function. > > > > Are there any cases you know where we can't hardcode them? > > I can't see how it helps. > > Case 1: > - PCI ID for DMA is AAA (one AHB master) > - PCI ID for DMA user is BBB > > Case 2: > - PCI ID for DMA is CCC (two AHB masters) > - PCI ID for DMA user is BBB > > DMA driver knows this info, but actual user doesn't. If it provides > wrong master it wouldn't work I suppose. I didn't realize that the PCI devices were distinct, I thought there was just one PCI device with multiple functions so you could go from one to the other. I guess if you can't tell by the PCI ID and there is no additional firmware data, you can't have a good autoconfiguration at all. Arnd -- 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
