Re: dmatest no longer works on ARC SDP with DW DMAC

[Alexey Brodkin]

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