All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: "Hennerich, Michael" <Michael.Hennerich@analog.com>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Drivers <Drivers@analog.com>
Subject: Re: IIO_CONST_ATTR_SCAN_EL_TYPE add result shift?
Date: Tue, 05 Oct 2010 13:02:36 +0100	[thread overview]
Message-ID: <4CAB13DC.9080600@cam.ac.uk> (raw)
In-Reply-To: <544AC56F16B56944AEC3BD4E3D5917712F0DB8ACC8@LIMKCMBX1.ad.analog.com>

On 10/05/10 12:52, Hennerich, Michael wrote:
> Jonathan Cameron wrote on 2010-10-05:
>> On 10/05/10 12:24, Hennerich, Michael wrote:
>>> /**
>>>  * IIO_CONST_ATTR_SCAN_EL_TYPE - attr to specify the data format of a
>>>  scan el * @name: the scan el name (may be more general and cover a set
>>>  of scan elements * @_sign: either s or u for signed or unsigned *
>>>  @_bits: number of actual bits occuplied by the value * @_storagebits:
>>>  number of bits _bits is padded to when read out of
>>> buffer  **/ #define IIO_CONST_ATTR_SCAN_EL_TYPE(_name, _sign, _bits,
>>> _storagebits) \
>>>         IIO_CONST_ATTR(_name##_type, #_sign#_bits"/"#_storagebits);
>>> There are cases where bits < storagebits and the result is not alligned
>>> to the LSB. Lets say we have an 10-bit ADC. The output is stored in a
>>> 16-bit word, with four leading zeros, then the 10-bit datum, followed
>>> by 2 don't care bits.
>>>
>>> So it would be good to provide an additional shift value?
>>> Or how shall we handle these cases?
>> This was discussed in the original debate and we simply proposed
>> leaving it until we had a user.  So the question is how to describe
>> the shift.
>>
>> So taking your example, how about:
>>
>> u10/16>>2
>>
>> Where the shift is optional.
>>
>> Other suggestions welcome given I made that up with 2 seconds thought.
> 
> I think this is sufficient. I can only think about right shifts being useful.
> This notation would consistently allow both, that's why I like it.
It would be decidedly odd for right shift to make sense.
> 
> A bit off topic - some common defines for signed/unsigned types might also be useful.
> 
> #define IIO_SCAN_EL_TYPE_SIGNED         's'
> #define IIO_SCAN_EL_TYPE_UNSIGNED       'u'
Fine with me.
> 
> Greetings,
> Michael
> 
> Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
> Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
> 
> 
> 


  reply	other threads:[~2010-10-05 11:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-05 11:24 IIO_CONST_ATTR_SCAN_EL_TYPE add result shift? Hennerich, Michael
2010-10-05 11:41 ` Jonathan Cameron
2010-10-05 11:52   ` Hennerich, Michael
2010-10-05 12:02     ` Jonathan Cameron [this message]
2010-10-05 12:06       ` Hennerich, Michael
2010-10-05 12:25         ` Jonathan Cameron

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=4CAB13DC.9080600@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=Drivers@analog.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=linux-iio@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.