Re: [RFC PATCH 2/4] i2c: add docs to clarify DMA handling

[Geert Uytterhoeven]

Hi Wolfram,

On Tue, Jun 6, 2017 at 12:24 PM, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote:
>> > +Therefore, it is *not* mandatory that the buffer of an i2c message is DMA safe.
>> > +It does not seem reasonable to apply additional burdens when the feature is so
>> > +rarely used. However, it is recommended to use a DMA-safe buffer, if your
>> > +message size is likely applicable for DMA (FIXME: > 8 byte?).
>>
>> So you expect drivers to fall back to PIO automatically if the buffer is
>> not DMA safe.  Sounds good to me.
>
> Yes, I strongly recommend that. Otherwise, drivers can always deal with
> bounce buffers on their own.
>
>> However, your check for a DMA-capable buffer is invoked only if
>> CONFIG_DMA_API_DEBUG is enabled:
>
> is *NOT* enabled!

Oops ;-)

>>     #if !defined(CONFIG_DMA_API_DEBUG)
>>            if (!virt_addr_valid(msg->buf) || object_is_on_stack(msg->buf)) {
>>                    pr_debug("msg buffer to 0x%04x might not be DMA capable\n",
>>                             msg->addr);
>>                    return -EFAULT;
>>            }
>>     #endif
>>
>
> The #if block is there because DMA_API_DEBUG does a lot more, but if the
> check in the helper is enabled, the core will fall back to PIO and you
> won't get the additional info from DMA_API_DEBUG.
>
> I think this needs a comment :)
>
> Now OK?

So it won't fall back to PIO if CONFIG_DMA_API_DEBUG is enabled?

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