On 02/08/15 19:39, Lars-Peter Clausen wrote:
> On 08/02/2015 08:23 PM, Jonathan Cameron wrote:
>> On 02/08/15 10:42, Lars-Peter Clausen wrote:
>>> On 08/01/2015 05:58 AM, Matt Ranostay wrote:
>>> [...]
>>>> +
>>>> +struct lidar_data {
>>>> + struct mutex lock;
>>>> + struct iio_dev *indio_dev;
>>>> + struct i2c_client *client;
>>>> +
>>>> + /* config */
>>>> + int calib_bias;
>>>> +
>>>> + u16 buffer[5]; /* 2 byte distance + 8 byte timestamp */
>>>
>>> Needs to be in its own cacheline to avoid issues if the I2C controller is
>>> using DMA.
>> Would do if spi, but in the case of i2c I thought all bus drivers were
>> obliged to deal with this rather than leaving it to the client drivers?
>
> Where did you find this? There definitely seem to be I2C drivers which
> directly map the i2c_msg buffers.
Right now I can't track down an explicit reference. However, all sorts
of nastiness occurs if we end up using the i2c_smbus_xfer_emulated as
that uses local buffers on the stack.
Hmm. Will look into this more when I get a chance. We have a lot of
i2c drivers that don't have aligned buffers...
>
> But I just realized that in this case the buffer is not passed to the i2c
> driver anyway so we should be fine.
>
> - Lars
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
