RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
>From: Nurkkala Eero.An (EXT-Offcode/Oulu) >Sent: 19 February, 2010 21:04 > >> Oops, I seemed to copy Q1.14 instead of Q14.1, but isn't it >still the same. >> When I added some debug messages it still seemed to be corret. >> >> Lowest number (-32768) is represented with 16th bit '1' and >the rest are >> zeros, right? That is 0x8000. >> -1 has all the bits set (0x) and 0 has all the bit >cleared (0x). >> Highest positive value has 16th bit cleared and the rest set >(0x7fff). >> >> Or did I interpret something wrong? >> >> Cheers, Ilkka > >I guess it's just fine, but let's see. Maybe I was lost in the >Q1.14: m + n + 1 ~ >binary: [sign bit, (m), (n)] where m is the integer portion, 0 >or 1, n is 14 bits.. >so if your input was [-32768... 32767] -> [-2,2] then, for example, >-32768 is in hex: 0x8000, but the 2nd most significant bit is >zero, which means >the integer portion (m) is not 1, which makes me doubt the >gain -32768 is >actually -1 (or 0), not -2. But then, as it's a two's >complement, it maybe just correct. > >So most likely it's just fine; I just had a thinko. Ok, now I got your point :) However, as far as I can understand the Q notation right, it basically defines how to interpret the value. That is, where is the decimal point. Thus, I would say that the code should work fine and based on quick tests, the gain control seems to behave ok too. Cheers, Ilkka-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
> Oops, I seemed to copy Q1.14 instead of Q14.1, but isn't it still the same. > When I added some debug messages it still seemed to be corret. > > Lowest number (-32768) is represented with 16th bit '1' and the rest are > zeros, right? That is 0x8000. > -1 has all the bits set (0x) and 0 has all the bit cleared (0x). > Highest positive value has 16th bit cleared and the rest set (0x7fff). > > Or did I interpret something wrong? > > Cheers, Ilkka I guess it's just fine, but let's see. Maybe I was lost in the Q1.14: m + n + 1 ~ binary: [sign bit, (m), (n)] where m is the integer portion, 0 or 1, n is 14 bits.. so if your input was [-32768... 32767] -> [-2,2] then, for example, -32768 is in hex: 0x8000, but the 2nd most significant bit is zero, which means the integer portion (m) is not 1, which makes me doubt the gain -32768 is actually -1 (or 0), not -2. But then, as it's a two's complement, it maybe just correct. So most likely it's just fine; I just had a thinko. - Eero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
>From: Nurkkala Eero.An (EXT-Offcode/Oulu) >Sent: 19 February, 2010 14:58 > >> I'm a bit confused. What do you mean by that? >> >> AFAICS, Q1.14 defines values [-16384.0, +16383.5], which are >mapped in the >> driver to integers [-32768, 32767], right? Moreover, those >Q1.14 values in >> registers are mapped to [-2, 2] in HW. So is there a problem >somewhere? >> >> Cheers, Ilkka > >No, don't get me wrong, not saying there's a problem with the >positive gains, >Q1.14: its range is [-16384.0, +16383.5] = [0x8000, 0x8001 … 0x, >0x, 0x0001 … 0x7FFE, 0x7FFF] >if I read this correctly, your min is 0x, but the real min maybe >0x8000? To be honest, it may be just me interpreting that incorrectly.. >...as if the value is in two's complement, it goes the opposite: >http://en.wikipedia.org/wiki/Two%27s_complement , see: >1 0 0 0 0 0 0 0 = −128 >1 1 1 1 1 1 1 1 = −1 >what do you think? maybe try it out to see the truth.. Oops, I seemed to copy Q1.14 instead of Q14.1, but isn't it still the same. When I added some debug messages it still seemed to be corret. Lowest number (-32768) is represented with 16th bit '1' and the rest are zeros, right? That is 0x8000. -1 has all the bits set (0x) and 0 has all the bit cleared (0x). Highest positive value has 16th bit cleared and the rest set (0x7fff). Or did I interpret something wrong? Cheers, Ilkka
RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
> I'm a bit confused. What do you mean by that?
>
> AFAICS, Q1.14 defines values [-16384.0, +16383.5], which are mapped in the
> driver to integers [-32768, 32767], right? Moreover, those Q1.14 values in
> registers are mapped to [-2, 2] in HW. So is there a problem somewhere?
>
> Cheers, Ilkka
No, don't get me wrong, not saying there's a problem with the positive gains,
Q1.14: its range is [-16384.0, +16383.5] = [0x8000, 0x8001 … 0x,
0x, 0x0001 … 0x7FFE, 0x7FFF]
if I read this correctly, your min is 0x, but the real min maybe
0x8000? To be honest, it may be just me interpreting that incorrectly..
...as if the value is in two's complement, it goes the opposite:
http://en.wikipedia.org/wiki/Two%27s_complement , see:
1 0 0 0 0 0 0 0 = −128
1 1 1 1 1 1 1 1 = −1
what do you think? maybe try it out to see the truth..
- Eero
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
On Fri, 19 Feb 2010, Nurkkala Eero.An (EXT-Offcode/Oulu) wrote:
+
+static const struct snd_kcontrol_new omap_mcbsp2_st_controls[] = {
+ SOC_SINGLE_EXT("McBSP2 Sidetone Switch", 1, 0, 1, 0,
+ omap_mcbsp_st_get_mode, omap_mcbsp_st_put_mode),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP2 Sidetone Channel 0 Volume",
+ -32768, 32767,
+ omap_mcbsp2_get_st_ch0_volume,
+ omap_mcbsp2_set_st_ch0_volume),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP2 Sidetone Channel 1 Volume",
+ -32768, 32767,
+ omap_mcbsp2_get_st_ch1_volume,
+ omap_mcbsp2_set_st_ch1_volume),
+};
+
+static const struct snd_kcontrol_new omap_mcbsp3_st_controls[] = {
+ SOC_SINGLE_EXT("McBSP3 Sidetone Switch", 2, 0, 1, 0,
+ omap_mcbsp_st_get_mode, omap_mcbsp_st_put_mode),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP3 Sidetone Channel 0 Volume",
+ -32768, 32767,
+ omap_mcbsp3_get_st_ch0_volume,
+ omap_mcbsp3_set_st_ch0_volume),
+ OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP3 Sidetone Channel 1 Volume",
+ -32768, 32767,
+ omap_mcbsp3_get_st_ch1_volume,
+ omap_mcbsp3_set_st_ch1_volume),
+};
+
Just a short note, "Gain values are in the interval (-2..2) in Q1.14
format, negative values are expressed in 2's complement."
So, from:
http://en.wikipedia.org/wiki/Q_(number_format)
"
The notation used is Qm.n, where:
* Q designates that the number is in Q format notation — the Texas
Instruments representation for signed fixed-point numbers.
* m (optional; default=0) is the number of bits used to designate the
two's complement integer portion of the number, exclusive of the sign
bit.
* n is the number of bits used to designate the two's complement
fractional portion of the number, i.e. the number of bits to the right
of the binary point. "
..so if you do tests, and find out the gains behave "irrationally"
occasionally, you can't possibly claim it isn't working as expected ;)
I'm a bit confused. What do you mean by that?
AFAICS, Q1.14 defines values [-16384.0, +16383.5], which are mapped in the
driver to integers [-32768, 32767], right? Moreover, those Q1.14 values in
registers are mapped to [-2, 2] in HW. So is there a problem somewhere?
Cheers, Ilkka
RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
> +
> +static const struct snd_kcontrol_new omap_mcbsp2_st_controls[] = {
> + SOC_SINGLE_EXT("McBSP2 Sidetone Switch", 1, 0, 1, 0,
> + omap_mcbsp_st_get_mode, omap_mcbsp_st_put_mode),
> + OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP2 Sidetone Channel 0 Volume",
> + -32768, 32767,
> + omap_mcbsp2_get_st_ch0_volume,
> + omap_mcbsp2_set_st_ch0_volume),
> + OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP2 Sidetone Channel 1 Volume",
> + -32768, 32767,
> + omap_mcbsp2_get_st_ch1_volume,
> + omap_mcbsp2_set_st_ch1_volume),
> +};
> +
> +static const struct snd_kcontrol_new omap_mcbsp3_st_controls[] = {
> + SOC_SINGLE_EXT("McBSP3 Sidetone Switch", 2, 0, 1, 0,
> + omap_mcbsp_st_get_mode, omap_mcbsp_st_put_mode),
> + OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP3 Sidetone Channel 0 Volume",
> + -32768, 32767,
> + omap_mcbsp3_get_st_ch0_volume,
> + omap_mcbsp3_set_st_ch0_volume),
> + OMAP_MCBSP_SOC_SINGLE_S16_EXT("McBSP3 Sidetone Channel 1 Volume",
> + -32768, 32767,
> + omap_mcbsp3_get_st_ch1_volume,
> + omap_mcbsp3_set_st_ch1_volume),
> +};
> +
Just a short note,
"Gain values are in the interval (-2..2) in Q1.14 format, negative values are
expressed in
2's complement."
So, from:
http://en.wikipedia.org/wiki/Q_(number_format)
"
The notation used is Qm.n, where:
* Q designates that the number is in Q format notation — the Texas
Instruments representation for signed fixed-point numbers.
* m (optional; default=0) is the number of bits used to designate the two's
complement integer portion of the number, exclusive of the sign bit.
* n is the number of bits used to designate the two's complement fractional
portion of the number, i.e. the number of bits to the right of the binary point.
"
..so if you do tests, and find out the gains behave "irrationally"
occasionally, you can't possibly claim it isn't working as expected ;)
- Eero--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
