From: Jonathan Cameron <jic23@kernel.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: Matti Vaittinen <mazziesaccount@gmail.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Paul Gazzillo <paul@pgazz.com>,
Shreeya Patel <shreeya.patel@collabora.com>,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
Zhigang Shi <Zhigang.Shi@liteon.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH v1 2/3] iio: light: ROHM BU27008 color sensor
Date: Mon, 1 May 2023 16:32:42 +0100 [thread overview]
Message-ID: <20230501163242.62b5bc97@jic23-huawei> (raw)
In-Reply-To: <91494388-9d2e-6cd6-9731-aea18271260b@fi.rohmeurope.com>
On Mon, 24 Apr 2023 06:21:23 +0000
"Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> On 4/23/23 15:57, Jonathan Cameron wrote:
> > On Fri, 21 Apr 2023 12:39:36 +0300
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> >
> >> The ROHM BU27008 is a sensor with 5 photodiodes (red, green, blue, clear
> >> and IR) with four configurable channels. Red and green being always
> >> available and two out of the rest three (blue, clear, IR) can be
> >> selected to be simultaneously measured. Typical application is adjusting
> >> LCD backlight of TVs, mobile phones and tablet PCs.
> >>
> >> Add initial support for the ROHM BU27008 color sensor.
> >> - raw_read() of RGB and clear channels
> >> - triggered buffer w/ DRDY interrtupt
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> >
> > Hi Matti,
> >
> > Biggest issue in here is some confusion over data packing when some channels
> > are enabled. The driver must pack the channels that are enabled (seen
> > from active_scan_mask) according to general IIO rules. So naturally aligned
> > buffers. Thus for this device it should always be packed into
> >
> > struct scan {
> > __le16 chans[4];
> > s64 ts __aligned(8); /*it's aligned anyway but better not to make reviewers think ;) */
> > };
> >
> > Even though there are 5 possible channels. If one in the middle isnt' enabled (e.g. blue)
> > then clear and IR shift to lower words. of the buffer.
>
> Ah, right. So I had misunderstood how the buffer works. I thought the
> scan_mask was only used to disallow unsupported channel-enabling
> configurations. If I understand your statement correctly, the scan_mask
> is used to determine the 'place of data' in the buffer when certain
> configuration is used. (I'll check this from the code but if the IIO
> handles data as I now think - that's cool! It should indeed simplify the
> buffer in driver side!).
'Place' is a little confusing (English is imprecise sometimes). Order
is perhaps more precise.
Place can mean same as order - as in 1st place in a race, but it can
also mean a specific location such as a place at a table where only
some seats are full.
The handling for this came about as part of the multiple consumer
support for SoC ADCs but it was also useful for ripping out a whole
load of driver specific handling that did similar repacking and letting
the generic code handle repacking data. It is fairly optimal and
does things like larger memcpys if there are a set of channels
that need moving, and cleanly makes it a noop if there is nothing
to do at all. All those tricks came IIRC from individual drivers
that had previously been doing this magic.
Jonathan
next prev parent reply other threads:[~2023-05-01 15:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 9:37 [PATCH v1 0/3] Support ROHM BU27008 RGB sensor Matti Vaittinen
2023-04-21 9:38 ` [PATCH v1 1/3] dt-bindings: iio: light: ROHM BU27008 Matti Vaittinen
2023-04-24 10:12 ` Krzysztof Kozlowski
2023-04-24 10:26 ` Matti Vaittinen
2023-04-21 9:39 ` [PATCH v1 2/3] iio: light: ROHM BU27008 color sensor Matti Vaittinen
2023-04-23 12:57 ` Jonathan Cameron
2023-04-24 6:21 ` Vaittinen, Matti
2023-05-01 15:32 ` Jonathan Cameron [this message]
2023-04-24 10:14 ` Matti Vaittinen
2023-05-01 15:36 ` Jonathan Cameron
[not found] ` <82ae3f4eb27b64554d7804c46febbb4a7f9fe7ae.1682067567.git.mazziesaccount@gmail.com>
2023-04-21 9:44 ` [PATCH v1 3/3] MAINTAINERS: Add ROHM BU27008 Matti Vaittinen
2023-04-23 12:04 ` [PATCH v1 0/3] Support ROHM BU27008 RGB sensor Jonathan Cameron
2023-04-24 5:35 ` Vaittinen, Matti
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=20230501163242.62b5bc97@jic23-huawei \
--to=jic23@kernel.org \
--cc=Matti.Vaittinen@fi.rohmeurope.com \
--cc=Zhigang.Shi@liteon.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dmitry.osipenko@collabora.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mazziesaccount@gmail.com \
--cc=paul@pgazz.com \
--cc=shreeya.patel@collabora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox