Hi Wolfram, Geert,
On Tue, Dec 9, 2014 at 11:09 PM, Wolfram Sang <wsa@xxxxxxxxxxxxx> 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 <wsa@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
