Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

On Wed, Nov 08, 2017 at 10:50:37PM +0000, Mark Brown wrote:
> On Sat, Nov 04, 2017 at 09:20:00PM +0100, Wolfram Sang wrote:
> 
> > While previous versions until v3 tried to magically apply bounce buffers when
> > needed, it became clear that detecting DMA safe buffers is too fragile. This
> > approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The
> > outcome so far is very convincing IMO. The core additions are simple and easy
> > to understand. The driver changes for the Renesas IP cores became easy to
> > understand, too.
> 
> It would really help a lot of things if there were a way to detect if a
> given memory block is DMA safe, having to pass the information around
> causes so much pain.

I so agree.

> > I am still not sure how we can teach regmap this new flag. regmap is a heavy
> > user of I2C, so broonie's opinion here would be great to have. The rest should
> > mostly be updating individual drivers which can be done when needed.
> 
> We pretty much assume everything is DMA safe already, the majority of
> transfers go to/from kmalloc()ed scratch buffers so actually are DMA
> safe but for bulk transfers we use the caller buffer and there might be
> some problem users.

So, pretty much the situation I2C was in before this patch set: we
pretty much assume DMA safety but there might be problem users.

> I can't really think of a particularly good way of
> handling it off the top of my head, obviously not setting the flag is
> easy but doesn't get the benefit while always using a bounce buffer
> would involve lots of unneeded memcpy().  Doing _dmasafe() isn't
> particularly appealing either but might be what we end up with.

Okay. That sounds you are fine with the approach taken here, in general?

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]