Hi Wolfram, Geert, On Tue, Dec 9, 2014 at 11:09 PM, Wolfram Sang <[email protected]> wrote: > On Tue, Dec 09, 2014 at 11:53:45AM +0100, Geert Uytterhoeven wrote: >> Hi Wolfram, >> >> On Fri, Nov 7, 2014 at 11:11 AM, Wolfram Sang <[email protected]> wrote: >> > --- a/drivers/i2c/busses/i2c-sh_mobile.c >> > +++ b/drivers/i2c/busses/i2c-sh_mobile.c >> > @@ -727,6 +886,21 @@ static int sh_mobile_i2c_probe(struct platform_device >> > *dev) >> > if (ret) >> > return ret; >> > >> > + /* Init DMA */ >> > + sg_init_table(&pd->sg, 1); >> > + pd->dma_direction = DMA_NONE; >> > + ret = sh_mobile_i2c_request_dma_chan(pd->dev, DMA_DEV_TO_MEM, >> > + res->start + ICDR, >> > &pd->dma_rx); >> > + if (ret == -EPROBE_DEFER) >> > + return ret; >> > + >> > + ret = sh_mobile_i2c_request_dma_chan(pd->dev, DMA_MEM_TO_DEV, >> > + res->start + ICDR, >> > &pd->dma_tx); >> > + if (ret == -EPROBE_DEFER) { >> > + sh_mobile_i2c_release_dma(pd); >> > + return ret; >> > + } >> > + >> >> If the DTS contains "dma" and "dma-names" properties, but CONFIG_RCAR_DMAC >> is disabled, sh_mobile_i2c_request_dma_chan() returns -EPROBE_DEFER, >> and the driver fails to initialize. >> >> If I remove the "dma" and "dma-names" properties, the driver does fall back >> to PIO mode. >> >> I think this is a regression. > > The only solution I can think of is to not bail out here and retry again > before every transfer? Doesn't sound elegant, though...
I think we have to request for each and every transfer. And fall back to PIO as default in a transparent way. This because the number of DMA channels are limited compared to number of potential consumers, so request failure may happen at any time. Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
