> > > > +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().
--
Xiubo
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
