On 11/12/2013 08:35 AM, Li Xiubo wrote:
+static int fsl_sai_probe(struct platform_device *pdev) {
[...]
+
+ sai->dma_params_rx.addr = res->start + SAI_RDR;
+ sai->dma_params_rx.maxburst = 6;
+ index = of_property_match_string(np, "dma-names", "rx");
+ ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
index,
+ &dma_args);
+ if (ret)
+ return ret;
+ sai->dma_params_rx.slave_id = dma_args.args[1];
+
+ sai->dma_params_tx.addr = res->start + SAI_TDR;
+ sai->dma_params_tx.maxburst = 6;
+ index = of_property_match_string(np, "dma-names", "tx");
+ ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
index,
+ &dma_args);
+ if (ret)
+ return ret;
+ sai->dma_params_tx.slave_id = dma_args.args[1];
The driver should not have to manually parse the dma devicetree
properties, this is something that should be handled by the dma
engine driver.
What do you think about the DMA slave_id ?
I have been noticed by one colleague that this should be parsed here,
which is from your opinions ?
Sure slave_id can be parsed here, but IMO it should be programmed via the
dma_slave_confog into the respective channel
Actually, these are parsed for cpu_dai->playback_dma_data and
cpu_dai->capture_dma_data dynamically, whose type is struct dma_slave_config.
And now I must parse them here, because the platform eDMA driver's newest version
will check and use the slave_ids to select and configure the eDMA channels via
dma_device->device_control().
Parsing them here is a layering violation. The format of the DMA specifier
depends on the DMA controller. A DMA slave should not make any assumptions
about how the specifier looks like, it should not even look at them. You should
fix the DMA controller driver to work without slave_id in the devicetree case.
- Lars
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
