Messages in this thread | | | Date | Thu, 14 Jun 2018 13:19:42 +0900 | From | Wolfram Sang <> | Subject | Re: [PATCH v4 01/10] i3c: Add core I3C infrastructure |
| |
Hi Boris,
> +/** > + * struct i3c_priv_xfer - I3C SDR private transfer > + * @rnw: encodes the transfer direction. true for a read, false for a write > + * @len: transfer length in bytes of the transfer > + * @data: input/output buffer > + */ > +struct i3c_priv_xfer { > + bool rnw; > + u16 len; > + union { > + void *in; > + const void *out; > + } data;
So, this is probably where most payloads end up?
I didn't notice any sign of DMA in these patches, but given my experiences, DMA will come sooner or later. And in I2C, this was problematic because then a lot of drivers were in the wild getting their buffers from everywhere (stack!). We now have an opt-in approach to mark buffers as DMA-safe.
I don't know if typical I3C transfers will be similar to I2C with usually small payloads where DMA usually makes not much sense. Yet, I think, that it might be a good idea to think about how this shall be handled with I3C right away. Maybe simply enforcing buffers to be DMA-safe. Or whatever.
A clear rule on that might save you hazzle later.
Regards,
Wolfram
[unhandled content-type:application/pgp-signature] | |