| Message ID | 20170117134540.9988-1-abailon@baylibre.com |
|---|---|
| Headers | show |
| Series | dmaengine: cppi41: Make CPPI 4.1 driver more generic | expand |
* Alexandre Bailon <abailon@baylibre.com> [170117 05:46]: > Most of the patch of this series were part of > "[PATCH 00/11] dmaengine: cppi41: Add dma support to da8xx" > > This series intend to make the CPPI 4.1 more generic in order to > add a new platform (the DA8xx). > To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved > to MUSB DSPS driver. > Other changes mainly update the glue layer and platform code to make the > whole driver more generic. So does da8xx use CPPI 4.1 DMA for other devices also in addition to musb? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/17/2017 06:55 PM, Tony Lindgren wrote: >> Most of the patch of this series were part of >> "[PATCH 00/11] dmaengine: cppi41: Add dma support to da8xx" >> >> This series intend to make the CPPI 4.1 more generic in order to >> add a new platform (the DA8xx). >> To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved >> to MUSB DSPS driver. >> Other changes mainly update the glue layer and platform code to make the >> whole driver more generic. > > So does da8xx use CPPI 4.1 DMA for other devices also in addition to > musb? No. DA8xx CPPI 4.1 is implemented as a part of the MUSB peripheral. But there were a SoC (support for which never got merged upstream) where CPPI 4.1 DMA is not limited to USB. > Regards, > > Tony MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> [170117 08:06]: > On 01/17/2017 06:55 PM, Tony Lindgren wrote: > > > > Most of the patch of this series were part of > > > "[PATCH 00/11] dmaengine: cppi41: Add dma support to da8xx" > > > > > > This series intend to make the CPPI 4.1 more generic in order to > > > add a new platform (the DA8xx). > > > To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved > > > to MUSB DSPS driver. > > > Other changes mainly update the glue layer and platform code to make the > > > whole driver more generic. > > > > So does da8xx use CPPI 4.1 DMA for other devices also in addition to > > musb? > > No. DA8xx CPPI 4.1 is implemented as a part of the MUSB peripheral. > But there were a SoC (support for which never got merged upstream) where > CPPI 4.1 DMA is not limited to USB. OK thanks for confirming it may pop up in some other devices too. Anyways that means we can make the cppi41.c runtime PM support simpler as it's always guaranteed to be enabled when in use with musb. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/17/2017 06:09 PM, Sergei Shtylyov wrote: > On 01/17/2017 04:45 PM, Alexandre Bailon wrote: > >> Despite the driver is already using DT to get the number of channels, >> init_sched() is using an hardcoded value to get it. >> Use DT to get the number of channels. >> >> Signed-off-by: Alexandre Bailon <abailon@baylibre.com> >> --- >> drivers/dma/cppi41.c | 33 ++++++++++++++++++++------------- >> 1 file changed, 20 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c >> index 3b2f57f..303ccee 100644 >> --- a/drivers/dma/cppi41.c >> +++ b/drivers/dma/cppi41.c > [...] >> @@ -832,7 +829,7 @@ static int init_descs(struct device *dev, struct >> cppi41_dd *cdd) >> return 0; >> } >> >> -static void init_sched(struct cppi41_dd *cdd) >> +static int init_sched(struct device *dev, struct cppi41_dd *cdd) >> { >> unsigned ch; >> unsigned word; > [...] >> @@ -850,9 +847,11 @@ static void init_sched(struct cppi41_dd *cdd) >> cppi_writel(reg, cdd->sched_mem + DMA_SCHED_WORD(word)); >> word++; >> } >> - reg = 15 * 2 * 2 - 1; >> + reg = cdd->n_chans * 2 - 1; >> reg |= DMA_SCHED_CTRL_EN; >> cppi_writel(reg, cdd->sched_mem + DMA_SCHED_CTRL); >> + >> + return 0; >> } >> >> static int init_cppi41(struct device *dev, struct cppi41_dd *cdd) >> @@ -871,12 +870,14 @@ static int init_cppi41(struct device *dev, >> struct cppi41_dd *cdd) >> >> ret = init_descs(dev, cdd); >> if (ret) >> - goto err_td; >> + goto deinit; >> >> cppi_writel(cdd->td_queue.submit, cdd->ctrl_mem + DMA_TDFDQ); >> - init_sched(cdd); >> + ret = init_sched(dev, cdd); >> + if (ret) > > What's the point if init_sched() always returns 0? In older version of this patch, I was able to return non zero in case of error. I will fix it. Best Regards, Alexandre > > [...] > > MBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html