From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com ([192.55.52.88]:36523 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716AbcDOJ4y (ORCPT ); Fri, 15 Apr 2016 05:56:54 -0400 Subject: Re: generic_buffer and 24 bits samples To: Lars-Peter Clausen , Gregor Boirie , "linux-iio@vger.kernel.org" References: <570FB712.5070903@parrot.com> <570FBE87.9050006@metafoo.de> From: Crestez Dan Leonard Message-ID: <5710BADC.3000000@intel.com> Date: Fri, 15 Apr 2016 12:56:44 +0300 MIME-Version: 1.0 In-Reply-To: <570FBE87.9050006@metafoo.de> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org 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: >> >> /* ... */ >> .scan_type = { >> .sign = 'u', >> .realbits = 24, >> .storagebits = 24, >> .endianness = IIO_LE, >> }, >> >> >> 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