generic_buffer and 24 bits samples

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 ?

Quoted 20 lines · 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 ??

Quoted 5 lines

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.

Quoted 27 lines · Lars-Peter Clausen

Quoted 25 lines · 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 ?

Quoted 4 lines

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.

Quoted 28 lines · Crestez Dan Leonard

Quoted 27 lines · Lars-Peter Clausen

Quoted 25 lines · 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 ?

Quoted 6 lines

Quoted 4 lines

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 ;)

Quoted 4 lines

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?

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

On Fri, Apr 15, 2016 at 04:06:14PM +0300, Crestez Dan Leonard wrote:
[snip...]

Quoted 4 lines

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.

Quoted 5 lines

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.