Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Message-ID: <7181e56e-9488-25c9-3d03-64e49b2c952a@gmail.com>
Date:   Thu, 21 Sep 2023 11:17:41 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US, en-GB
To:     Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc:     Jonathan Cameron <jic23@kernel.org>,
        Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Angel Iglesias <ang.iglesiasg@gmail.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Andreas Klinger <ak@it-klinger.de>,
        Benjamin Bara <bbara93@gmail.com>, linux-iio@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
References: <cover.1694760170.git.mazziesaccount@gmail.com>
 <f378a401cec4fb0b9287b52ab159f00dd77569a6.1694760170.git.mazziesaccount@gmail.com>
 <20230917113518.7c4bb1a0@jic23-huawei>
 <a5c19874-32ba-60bf-6e72-9139a2873c7e@gmail.com>
 <c987f401-81c4-00e5-51a7-88a6a38a2ca2@gmail.com>
 <20230919155340.0000076f@Huawei.com>
From:   Matti Vaittinen <mazziesaccount@gmail.com>
Subject: Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390
In-Reply-To: <20230919155340.0000076f@Huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 9/19/23 17:53, Jonathan Cameron wrote:
> On Tue, 19 Sep 2023 14:28:29 +0300
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> On 9/18/23 15:56, Matti Vaittinen wrote:
>>> On 9/17/23 13:35, Jonathan Cameron wrote:
>>>> On Fri, 15 Sep 2023 09:56:19 +0300
>>>> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>>>>   
>>>>> Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure
>>>>> pressures ranging from 300 hPa to 1300 hPa with configurable measurement
>>>>> averaging and internal FIFO. The sensor does also provide temperature
>>>>> measurements.
>>>>>
>>>>> Sensor does also contain IIR filter implemented in HW. The data-sheet
>>>>> says the IIR filter can be configured to be "weak", "middle" or
>>>>> "strong". Some RMS noise figures are provided in data sheet but no
>>>>> accurate maths for the filter configurations is provided. Hence, the IIR
>>>>> filter configuration is not supported by this driver and the filter is
>>>>> configured to the "middle" setting (at least not for now).
>>>>>
>>>>> The FIFO measurement mode is only measuring the pressure and not the
>>>>> temperature. The driver measures temperature when FIFO is flushed and
>>>>> simply uses the same measured temperature value to all reported
>>>>> temperatures. This should not be a problem when temperature is not
>>>>> changing very rapidly (several degrees C / second) but allows users to
>>>>> get the temperature measurements from sensor without any additional
>>>>> logic.
>>>>>
>>>>> This driver allows the sensor to be used in two muitually exclusive
>>>>> ways,
>>>>>
>>>>> 1. With trigger (data-ready IRQ).
>>>>> In this case the FIFO is not used as we get data ready for each
>>>>> collected
>>>>> sample. Instead, for each data-ready IRQ we read the sample from sensor
>>>>> and push it to the IIO buffer.
>>>>>
>>>>> 2. With hardware FIFO and watermark IRQ.
>>>>> In this case the data-ready is not used but we enable watermark IRQ. At
>>>>> each watermark IRQ we go and read all samples in FIFO and push them
>>>>> to the
>>>>> IIO buffer.
>>>>>
>>>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ...
>>
>>>>> +
>>>>> +static const unsigned long bm1390_scan_masks[] = {
>>>>> +    BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0
>>>> Why?  Doesn't look hard to support just one or the other?
>>>> Normally we only do this sort of limitation when there is a heavily
>>>> optimized read routine for a set of channels and it is better
>>>> to grab them all and throw away the ones we don't care about.
>>>> That doesn't seem to be true here. So if the fifo grabbed both
>>>> temp and pressure it would makes sense here, but doesn't seem
>>>> like it does.
>>>
>>> I have a feeling I have misunderstood how this mask works. I have
>>> assumed all the channels with corresponding mask bit _can_ be enabled
>>> simultaneously, but I have not understood they _must_ all be enabled. I
>>> think I must go back studying this, but if all channels really _must_ be
>>> enabled, then you are correct. It actually makes a lot of sense to
>>> support the pressure values alone, as, according to the data-sheet, the
>>> HW is doing a "MEMS temperature compensation" to the pressure values.
>>> So, my assuimption is the temperature data may not be required to be
>>> captured.
>>>
>>> This also means I should revise the scan masks for the BU27008, BU27010
>>> and BU27034 light sensors as I don't think all the users want all the
>>> channels enabled. I wonder how I have not noticed any problems when I
>>> tested those things - did I really always enable all the channels...? @_@
>>>
>>> Anyways, Thanks.
>>
>> Hi Jonathan,
>>
>> There's something in IIO scan_masks / buffer demuxing that I don't quite
>> understand

Thank You for the patience and the explanation Jonathan. I have a - 
hopefully not totally wrong - feeling I understand this better. I didn't 
understand that IIO framework has this extra logic and that 
available_scan_masks was not really meant for telling what IIO allows 
_users_ to enable - but it was for driver to tell IIO core what the 
driver can give. (Naturally this impacts to what IIO allows users to 
enable, but not directly). Eg, if I now get it right, the 
'available_scan_masks' is information what data flows between driver and 
IIO. Similarly, 'active_scan_mask' tells what the IIO core 'expects' to 
get from the driver, right? So, in bm1390 case, if I set both:

BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP),
and
BIT(BM1390_CHAN_PRESSURE),

to 'available_scan_masks', then it means driver is telling IIO it can 
give both pressure and temperature, or temperature alone. As a result, 
IIO can set either both temp and pressure to 'active_scan_mask' - in 
which case driver should push both in the buffers - or just the 
pressure, in which case the driver should not push the temperature.

>>
>> The bm1390 driver as sent in v2 does not do demuxing but always pushes
>> whole chunk of data and trusts IIO to do demuxing.
> 
> Yup. That should work.  But in this case you can trivially decide not to read
> or fill in the temperature and hence save some bus cycles.
> 
>>
>> 2) I noticed the 'available_scan_masks' was marked as an optional field.
>> So, I think that if there is no restrictions to which of the channels
>> can be enabled, then we can omit setting it. This is what I tried.
>>
>> It appears that when we do not populate the 'available_scan_masks' with the:
>>   >>> +static const unsigned long bm1390_scan_masks[] = {
>>   >>> +    BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0
>>
>> things change. When I tested enabling only temperature and ran the
>> iio_generic_buffer -c 20 -N 0 -t bm1390data-rdy-dev0 - the reported
>> values seemed completely random.
> 
> You need to pack the data correctly yourself in the driver.
> So it adds small amount of code complexity but potentially saves bus
> traffic.

...

>>
>> Based on this experimenting (and headache obtained from reading the
>> demuxing code) - the IIO framework does not do channel demuxing if the
>> 'available_scan_masks' is not given? To me this was somewhat unexpected.
> 
> Yes.  If you don't tell it what channel setups are available (note there can
> be lots) you are saying that we support any random combination and have
> to do the data packing by hand.
> 

Okay... I think it kind of makes sense to leave an option where the 
driver can create buffer as it wants. I am not sure I can wrap my head 
around this to the extent that I knew when the IIO does not know what 
channels the driver has enabled - and thus, what types of data there 
will be - but I can accept the answer that such situations can exist :) 
Besides, allowing the driver to do the buffer formatting may allow some 
'use-case specific, custom optimizations' when user-space knows what to 
expect (for example, regarding the data alignments and ordering to for 
example save space).

...This leads to another thing I noticed - and to another question :)

I was experimenting with the bm1390 scan masks and iio_generic_buffer 
tool. It seems to me that the iio_generic_buffer does not expect the 
padding when the data in buffer is u32 + u16. When I enable the pressure 
(32bits) and temperature (16 bits) in bm1390 and keep the time-stamp 
disabled, the user-space will get buffer where 2 bytes of padding is 
added to each temperature sample so the next pressure sample stays 
correctly aligned. I believe kernel side does sane job here.

This, however, did result (at least my version of) the 
iio_generic_buffer tool to read garbage values after the first sample. 
My assumption is that the iio_generic_buffer does not add the padding 
bytes to the end of last data in the scan in order to ensure also the 
next scan will be correctly aligned.

I did following change to the iio_generic_buffer:

Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Thu Sep 21 10:15:19 2023 +0300

     tools: iio: iio_generic_buffer ensure alignment

     The iio_generic_buffer can return garbage values when the total size of
     scan data is not a multiple of largest element in the scan. This can be
     demonstrated by reading a scan consisting for example of one 4 byte and
     one 2 byte element, where the 4 byte elemnt is first in the buffer.

     The IIO generic buffert code does not take into accunt the last two
     padding bytes that are needed to ensure that the 4byte data for next
     scan is correctly aligned.

     Add padding bytes required to align the next sample into the scan size.

     Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c
index 44bbf80f0cfd..fc562799a109 100644
--- a/tools/iio/iio_generic_buffer.c
+++ b/tools/iio/iio_generic_buffer.c
@@ -54,9 +54,12 @@ enum autochan {
  static unsigned int size_from_channelarray(struct iio_channel_info 
*channels, int num_channels)
  {
         unsigned int bytes = 0;
-       int i = 0;
+       int i = 0, max = 0;
+       unsigned int misalignment;

         while (i < num_channels) {
+               if (channels[i].bytes > max)
+                       max = channels[i].bytes;
                 if (bytes % channels[i].bytes == 0)
                         channels[i].location = bytes;
                 else
@@ -66,6 +69,16 @@ static unsigned int size_from_channelarray(struct 
iio_channel_info *channels, in
                 bytes = channels[i].location + channels[i].bytes;
                 i++;
         }
+       /*
+        * We wan't the data in next sample to also be properly aligned so
+        * we'll add padding at the end if needed. TODO: should we use fixed
+        * 8 byte alignment instead of the size of the biggest samnple?
+        */
+       misalignment = bytes % max;
+       if (misalignment) {
+               printf("Misalignment %u. Adding Padding %u\n", 
misalignment,  max - misalignment);
+               bytes += max - misalignment;
+       }

         return bytes;
  }

I can send this as a proper patch if you guys think it is correct.


>>
>> Finally, when the watermark IRQ is used, we can't omit reading the
>> pressure data because clearing the WMI is done based on the pressure
>> data in FIFO.
> 
> Hmm. That is a good reason to keep the available scan masks set.
> Add a comment on that next to the mask.
> 
>>
>> So, I would propose we do:
>>
>> static const unsigned long bm1390_scan_masks[] = {
>> 	BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP),
>> 	BIT(BM1390_CHAN_PRESSURE), 0
> 
> Makes sense given need to read the pressure channel.
>>
>> which better reflects what the hardware is capable of - and, unless I am
>> missing something, also allows us to offload the buffer demuxing to the IIO.
>>
>> Still, as mentioned in 1), the
>>
>>   >>> +static const unsigned long bm1390_scan_masks[] = {
>>   >>> +    BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0
>>
>> does not seem to prevent enabling only the temperature channel - so in
>> the driver buffer handler we still must unconditionally read the
>> pressure data regardles the active_scan_mask.
> 
> active_scan_mask should match the above - it's separate from what is enabled.
> active_scan_mask is on the data capture side of the demux - the buffers
> are then fed repacked data reflecting what is enabled.

Cool! So, the driver can rely on IIO asking for the pressure (in 
active_scan_mask) after it has correctly set the available scan mask. It 
may not be a big thing but I like it. It is enough to take care of 
ensuring all required stuff is read from HW in one place (in available 
scan masks) and not to worry about it in actual data reading path but 
just read stuff IIO is asking to be read. I like it.

Another thing to note is that, when we build the available_scan_mask 
array - we should either pay attention to the order of masks - or change 
the iio_scan_mask_match() to not accept first matching subset but to go 
through all of the masks unless it finds and exactly matching one (and 
in general prefer the smallest subset). Not sure this is worth the extra 
cycles though.

Thanks again - feel like I've learned something today :)

Yours,
	-- Matti Vaittinen

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~