generic_buffer and 24 bits samples

generic_buffer and 24 bits samples

[Gregor Boirie]

Greetings,

I'm trying to use an st_pressure based sensor to sample pressure
data using generic_buffer tool. However it seems that it does not
support data packed onto 24 bits samples.
st_pressure driver defines scan_type for my device as:
<code>
/* ... */
     .scan_type = {
         .sign = 'u',
         .realbits = 24,
         .storagebits = 24,
         .endianness = IIO_LE,
     },
</code>

What is the proper way to make this work ? Using 32 bits storagebits
field ? Enhance generic_buffer to support 24 bits samples ? Anything
else ??

It seems iio_compute_scan_bytes consider sample data as a simple byte
stream. So I'm wondering what are the alignment constraints for sample
start address ? Should they be aligned onto their natural "word"
boundaries, i.e. 16 bits for u16, 32 bits for u32, etc... ? And for
24 bits samples ?

Regards.
Grégor

Re: generic_buffer and 24 bits samples

[Lars-Peter Clausen]

On 04/14/2016 05:28 PM, Gregor Boirie wrote:
> Greetings,
> 
> I'm trying to use an st_pressure based sensor to sample pressure
> data using generic_buffer tool. However it seems that it does not
> support data packed onto 24 bits samples.
> st_pressure driver defines scan_type for my device as:
> <code>
> /* ... */
>     .scan_type = {
>         .sign = 'u',
>         .realbits = 24,
>         .storagebits = 24,
>         .endianness = IIO_LE,
>     },
> </code>
> 
> What is the proper way to make this work ? Using 32 bits storagebits
> field ? Enhance generic_buffer to support 24 bits samples ? Anything
> else ??
> 
> It seems iio_compute_scan_bytes consider sample data as a simple byte
> stream. So I'm wondering what are the alignment constraints for sample
> start address ? Should they be aligned onto their natural "word"
> boundaries, i.e. 16 bits for u16, 32 bits for u32, etc... ? And for
> 24 bits samples ?

IIO really only supports powers of two >= 8 for the storagebits size.
Everything else is undefined.

Samples are aligned to their storage size.

Re: generic_buffer and 24 bits samples

[Crestez Dan Leonard]

On 04/14/2016 07:00 PM, Lars-Peter Clausen wrote:
> On 04/14/2016 05:28 PM, Gregor Boirie wrote:
>> Greetings,
>>
>> I'm trying to use an st_pressure based sensor to sample pressure
>> data using generic_buffer tool. However it seems that it does not
>> support data packed onto 24 bits samples.
>> st_pressure driver defines scan_type for my device as:
>> <code>
>> /* ... */
>>      .scan_type = {
>>          .sign = 'u',
>>          .realbits = 24,
>>          .storagebits = 24,
>>          .endianness = IIO_LE,
>>      },
>> </code>
>>
>> What is the proper way to make this work ? Using 32 bits storagebits
>> field ? Enhance generic_buffer to support 24 bits samples ? Anything
>> else ??
>>
>> It seems iio_compute_scan_bytes consider sample data as a simple byte
>> stream. So I'm wondering what are the alignment constraints for sample
>> start address ? Should they be aligned onto their natural "word"
>> boundaries, i.e. 16 bits for u16, 32 bits for u32, etc... ? And for
>> 24 bits samples ?
>
> IIO really only supports powers of two >= 8 for the storagebits size.
> Everything else is undefined.
>
> Samples are aligned to their storage size.

How does 24-bit alignment work?

Maybe the IIO core should check that storagebits is one of 8/16/32/64 
and otherwise fail at register time? A quick grep finds only 2 drivers 
using storagebits = 24 and they could easily be modified to 32.

--
Regards,
Leonard

Re: generic_buffer and 24 bits samples

[Lars-Peter Clausen]

On 04/15/2016 11:56 AM, Crestez Dan Leonard wrote:
> On 04/14/2016 07:00 PM, Lars-Peter Clausen wrote:
>> On 04/14/2016 05:28 PM, Gregor Boirie wrote:
>>> Greetings,
>>>
>>> I'm trying to use an st_pressure based sensor to sample pressure
>>> data using generic_buffer tool. However it seems that it does not
>>> support data packed onto 24 bits samples.
>>> st_pressure driver defines scan_type for my device as:
>>> <code>
>>> /* ... */
>>>      .scan_type = {
>>>          .sign = 'u',
>>>          .realbits = 24,
>>>          .storagebits = 24,
>>>          .endianness = IIO_LE,
>>>      },
>>> </code>
>>>
>>> What is the proper way to make this work ? Using 32 bits storagebits
>>> field ? Enhance generic_buffer to support 24 bits samples ? Anything
>>> else ??
>>>
>>> It seems iio_compute_scan_bytes consider sample data as a simple byte
>>> stream. So I'm wondering what are the alignment constraints for sample
>>> start address ? Should they be aligned onto their natural "word"
>>> boundaries, i.e. 16 bits for u16, 32 bits for u32, etc... ? And for
>>> 24 bits samples ?
>>
>> IIO really only supports powers of two >= 8 for the storagebits size.
>> Everything else is undefined.
>>
>> Samples are aligned to their storage size.
> 
> How does 24-bit alignment work?

It does not work ;)

> 
> Maybe the IIO core should check that storagebits is one of 8/16/32/64 and
> otherwise fail at register time? A quick grep finds only 2 drivers using
> storagebits = 24 and they could easily be modified to 32.

Yes, sounds reasonable. Do you want to send a patch?

Thanks,
- Lars

Re: generic_buffer and 24 bits samples

[Crestez Dan Leonard]

On 04/15/2016 01:31 PM, Lars-Peter Clausen wrote:
> On 04/15/2016 11:56 AM, Crestez Dan Leonard wrote:
>> On 04/14/2016 07:00 PM, Lars-Peter Clausen wrote:
>>> On 04/14/2016 05:28 PM, Gregor Boirie wrote:
>>>> Greetings,
>>>>
>>>> I'm trying to use an st_pressure based sensor to sample pressure
>>>> data using generic_buffer tool. However it seems that it does not
>>>> support data packed onto 24 bits samples.
>>>> st_pressure driver defines scan_type for my device as:
>>>> <code>
>>>> /* ... */
>>>>       .scan_type = {
>>>>           .sign = 'u',
>>>>           .realbits = 24,
>>>>           .storagebits = 24,
>>>>           .endianness = IIO_LE,
>>>>       },
>>>> </code>
>>>>
>>>> What is the proper way to make this work ? Using 32 bits storagebits
>>>> field ? Enhance generic_buffer to support 24 bits samples ? Anything
>>>> else ??
>>>>
>>>> It seems iio_compute_scan_bytes consider sample data as a simple byte
>>>> stream. So I'm wondering what are the alignment constraints for sample
>>>> start address ? Should they be aligned onto their natural "word"
>>>> boundaries, i.e. 16 bits for u16, 32 bits for u32, etc... ? And for
>>>> 24 bits samples ?
>>>
>>> IIO really only supports powers of two >= 8 for the storagebits size.
>>> Everything else is undefined.
>>>
>>> Samples are aligned to their storage size.
>>
>> How does 24-bit alignment work?
>
> It does not work ;)
>
>>
>> Maybe the IIO core should check that storagebits is one of 8/16/32/64 and
>> otherwise fail at register time? A quick grep finds only 2 drivers using
>> storagebits = 24 and they could easily be modified to 32.
>
> Yes, sounds reasonable. Do you want to send a patch?
Not really, I don't want to break stuff.

The only drivers that seem to use an unusual storagebits value are 
st_pressure (the one that this thread is about) and AD5791 which doesn't 
seem to actually expose buffer support.

There is also the curious case of AD7303 which specifies realbits and 
storage bits as the char value '8', again without exposing buffer support.

Perhaps storagebits=24 in st_pressure should be considered a bug. Maybe 
try to modify this to 32 and check the readings?

I don't have any of these devices.

Regards,
Leonard

Re: generic_buffer and 24 bits samples

[Gregor Boirie]

On Fri, Apr 15, 2016 at 04:06:14PM +0300, Crestez Dan Leonard wrote:
[snip...]
> The only drivers that seem to use an unusual storagebits value are
> st_pressure (the one that this thread is about) and AD5791 which doesn't
> seem to actually expose buffer support.
> 
> There is also the curious case of AD7303 which specifies realbits and
> storage bits as the char value '8', again without exposing buffer support.
> 
> Perhaps storagebits=24 in st_pressure should be considered a bug. Maybe try
> to modify this to 32 and check the readings?
I'll take care of st_pressure since I'm currently working on a patch series. I
don't have AD7303 device however.
Regards.
> 
> I don't have any of these devices.
> 
> Regards,
> Leonard

Re: generic_buffer and 24 bits samples

[Lars-Peter Clausen]

On 04/15/2016 04:35 PM, Gregor Boirie wrote:
> On Fri, Apr 15, 2016 at 04:06:14PM +0300, Crestez Dan Leonard wrote:
> [snip...]
>> The only drivers that seem to use an unusual storagebits value are
>> st_pressure (the one that this thread is about) and AD5791 which doesn't
>> seem to actually expose buffer support.
>>
>> There is also the curious case of AD7303 which specifies realbits and
>> storage bits as the char value '8', again without exposing buffer support.
>>
>> Perhaps storagebits=24 in st_pressure should be considered a bug. Maybe try
>> to modify this to 32 and check the readings?
> I'll take care of st_pressure since I'm currently working on a patch series. I
> don't have AD7303 device however.

I'll send a patch, but is non-critical as it does not have buffer support yet.