From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>,
Matt Ranostay <mranostay@gmail.com>,
marex@denx.de, matt@ohporter.com, pantelis.antoniou@gmail.com
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR
Date: Sun, 2 Aug 2015 20:52:58 +0100 [thread overview]
Message-ID: <55BE751A.5040308@kernel.org> (raw)
In-Reply-To: <55BE63F2.5080204@metafoo.de>
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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>,
Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
marex-ynQEQJNshbs@public.gmane.org,
matt-agtwNxEcTQJWk0Htik3J/w@public.gmane.org,
pantelis.antoniou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR
Date: Sun, 2 Aug 2015 20:52:58 +0100 [thread overview]
Message-ID: <55BE751A.5040308@kernel.org> (raw)
In-Reply-To: <55BE63F2.5080204-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2015-08-02 19:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-01 3:58 [PATCH 0/2] iio: proximity: add PulsedLight LIDAR sensor support Matt Ranostay
2015-08-01 3:58 ` Matt Ranostay
2015-08-01 3:58 ` [PATCH 1/2] devicetree: add PulsedLight vendor prefix Matt Ranostay
2015-08-01 3:58 ` Matt Ranostay
2015-08-01 3:58 ` [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR Matt Ranostay
2015-08-01 3:58 ` Matt Ranostay
2015-08-01 8:39 ` Vladimir Barinov
2015-08-01 8:39 ` Vladimir Barinov
2015-08-01 21:17 ` Jonathan Cameron
2015-08-01 21:17 ` Jonathan Cameron
2015-08-01 22:22 ` Matt Ranostay
2015-08-01 22:22 ` Matt Ranostay
2015-08-02 7:36 ` Vladimir Barinov
2015-08-02 7:36 ` Vladimir Barinov
2015-08-02 18:18 ` Jonathan Cameron
2015-08-02 18:18 ` Jonathan Cameron
2015-08-02 9:42 ` Lars-Peter Clausen
2015-08-02 9:42 ` Lars-Peter Clausen
2015-08-02 18:23 ` Jonathan Cameron
2015-08-02 18:23 ` Jonathan Cameron
2015-08-02 18:39 ` Lars-Peter Clausen
2015-08-02 18:39 ` Lars-Peter Clausen
2015-08-02 19:52 ` Jonathan Cameron [this message]
2015-08-02 19:52 ` Jonathan Cameron
2015-08-02 21:28 ` Matt Ranostay
2015-08-02 21:28 ` Matt Ranostay
2015-08-03 8:00 ` Lars-Peter Clausen
2015-08-03 8:00 ` Lars-Peter Clausen
2015-08-03 8:19 ` Matt Ranostay
2015-08-03 8:19 ` Matt Ranostay
2015-08-02 9:45 ` Lars-Peter Clausen
2015-08-02 9:45 ` Lars-Peter Clausen
-- strict thread matches above, loose matches on Subject: below --
2015-08-12 6:01 [PATCH v5 0/2] iio: proximity: add PulsedLight LIDAR sensor support Matt Ranostay
2015-08-12 6:01 ` [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR Matt Ranostay
2015-08-12 6:01 ` Matt Ranostay
2015-08-16 8:24 ` Jonathan Cameron
2015-08-16 8:24 ` Jonathan Cameron
2015-08-18 2:33 ` Matt Ranostay
2015-08-18 2:33 ` Matt Ranostay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55BE751A.5040308@kernel.org \
--to=jic23@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=marex@denx.de \
--cc=matt@ohporter.com \
--cc=mranostay@gmail.com \
--cc=pantelis.antoniou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.