It could be an off by one, I dont have a datasheet for the au8522 to
know for sure.
I filled in the blanks, ie
0 270
2 250
so I guessed that 1 is 260
Chris
update...@gmail.com
On Wed, Jul 17, 2013 at 7:41 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Wed, Jul 17, 2013 at 8:30 PM, Chris Lee update...@gmail.com wrote:
This patch fixes an if() statement that was preventing the last
element in the table from ever being utilized, preventing the snr from
ever displaying 27db. Also some of the gaps in the lookup table were
filled in.
Signed-off-by: Chris Lee update...@gmail.com
I don't have any specific objection to this patch, other than that I
have no idea if the values he's adding are actually correct. I'd have
to pull out the datasheet and see what the formula looks like to
actually calculate the correct values.
This is of course assuming Chris didn't have the formula and just
picked numbers that were roughly in between the adjacent values.
The off-by-one is legit (syntactically at least - there is indeed no
value that would result in 0 being selected), although frankly I don't
know whether value 0 is supposed to be 26.0 or 27.0. It's entirely
possible that 0=26.0 and the whole table is off by one value (this was
actually the case with the QAM256 table, except in that case it was
much worse because it was oscillating between 40.0 and 0.00).
Anyway, hard to argue this isn't an improvement and thus shouldn't be
accepted -- except for the real possibility that the patch introduces
wrong values into the table.
Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
