Re: [PATCH 1/2] [RFC] spi: rspi: Handle dmaengine_prep_slave_sg() failures gracefully

[Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>]

Hi Laurent,

On Thu, Jul 10, 2014 at 1:05 PM, Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> On Wednesday 09 July 2014 12:26:22 Geert Uytterhoeven wrote:
>> As typically a shmobile SoC has less DMA channels than devices that can use
>> DMA, we may want to prioritize access to the DMA channels in the future.
>> This means that dmaengine_prep_slave_sg() may start failing arbitrarily.
>>
>> Handle dmaengine_prep_slave_sg() failures gracefully by falling back to
>> PIO.
>
> Just a random thought, do you think there would be performance-sensitive cases
> where failing the transfer completely would be better than using PIO ?

QSPI Flash reads gain most from DMA.

However, failing transfers (and thus the whole SPI message, which typically
consists of multiple transfers) means we'll have to retry the message later.
This could be done by the SPI driver, the SPI subsystem, or the upper layer.
E.g. m25p80 and mtd do not retry SPI FLASH reads and writes.

>> Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
>
> -EAGAIN might not be the best error code to return in this case, as it would
> imply that the caller should just call rspi_dma_transfer() again. On the other
> hand I don't see another error code that would be a perfect match, so

I followed the exact same reasoning to arrive at -EAGAIN...

BTW, calling rspi_dma_transfer() again is an option ;-)

> Acked-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html