Hi Andy, On Wed, 2016-08-10 at 15:15 +-0300, Andy Shevchenko wrote: +AD4- On Wed, 2016-08-10 at 11:06 +-0000, Eugeniy Paltsev wrote: +AD4- +AD4- +AD4- +AD4- dmatest on ARC SDP with DW DMAC became broken after df5c7386 +AD4- +AD4- (+ACI-dmaengine: dw: some Intel devices has no memcpy support+ACI-) and +AD4- +AD4- 30cb2639 (+ACI-dmaengine: dw: don't override platform data with autocfg+ACI-) +AD4- +AD4- commits. +AD4- +AD4- +ACo- After df5c7386 commit +ACI-DMA+AF8-MEMCPY+ACI- capability option doesn't +AD4- +AD4- get set correctly in platform driver version. +AD4- +AD4- +ACo- After 30cb2639 commit +AD4- +AD4- +ACI-data+AF8-width+ACI- and +ACI-nollp+ACI- parameters don't get set correctly in +AD4- +AD4- platform +AD4- +AD4- driver version. +AD4- +AD4- +AD4- +AD4- This happens because in old driver version there are three sources+AKA- +AD4- +AD4- of parameters: pdata, device tree and autoconfig hardware registers.+AKA- +AD4- +AD4- Some parameters were read from pdata and others from autoconfig +AD4- +AD4- hardware registers. If pdata was absent some pdata structure+AKA- +AD4- +AD4- fields were filled with parameters from device tree. But 30cb2639 +AD4- +AD4- commit disabled overriding pdata with autocfg, so if we use platform +AD4- +AD4- driver version without pdata some parameters will not be set. +AD4- +AD4- Yes, that's correct behaviour right now. You have to provide platform +AD4- code which registers device with all platform data provided. But given autocfg registers exist in HW why don't we rely on their contents? +AD4- +AD4- I'm wondering what would be the best way to fix this situation? +AD4- +AD4- Ideally we have to switch to use built-in device properties +AD4- (drivers/base/property.c) and platform code in your case has to provide +AD4- properties. What do you mean saying +ACI-built-in device properties+ACI-? Setting pdata structure? In our particular case we use device tree for DW DMAC setup. -Alexey-- 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
