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 updatelee@xxxxxxxxx On Wed, Jul 17, 2013 at 7:41 PM, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: > On Wed, Jul 17, 2013 at 8:30 PM, Chris Lee <updatelee@xxxxxxxxx> 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 <updatelee@xxxxxxxxx> > > 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 <dheitmueller@xxxxxxxxxxxxxx> > > -- > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
