| Message ID | 201408161412275930052@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Em Sat, 16 Aug 2014 14:12:32 +0800 "nibble.max" <nibble.max@gmail.com> escreveu: > The current m88ts2022 driver will miss the following high symbol rate transponders on Telstar 18 138.0. > 12385 H 43200, > 12690 H 43200, > 12538 V 41250... > the code for f_3db_hz will overflow for the high symbol rate. > for example, symbol rate=41250 KS/s > symbol_rate * 135UL = 5568750000(1 4BEC 61B0), the value is larger than unsigned int on 32bit platform. > that makes the wrong result. > Exchanging the div and mul position fixs it. > > Signed-off-by: Nibble Max <nibble.max@gmail.com> > --- > drivers/media/tuners/m88ts2022.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/tuners/m88ts2022.c b/drivers/media/tuners/m88ts2022.c > index 40c42de..65c8acc 100644 > --- a/drivers/media/tuners/m88ts2022.c > +++ b/drivers/media/tuners/m88ts2022.c > @@ -314,7 +314,7 @@ static int m88ts2022_set_params(struct dvb_frontend *fe) > div_min = gdiv28 * 78 / 100; > div_max = clamp_val(div_max, 0U, 63U); > > - f_3db_hz = c->symbol_rate * 135UL / 200UL; > + f_3db_hz = (c->symbol_rate / 200UL) * 135UL; Hmm... wouldn't this make worse for low symbol rates? IMHO, the better is to use a u64 instead, and do_div64(). > f_3db_hz += 2000000U + (frequency_offset_khz * 1000U); > f_3db_hz = clamp(f_3db_hz, 7000000U, 40000000U); > Regards,
On 08/16/2014 02:38 PM, Mauro Carvalho Chehab wrote: > Em Sat, 16 Aug 2014 14:12:32 +0800 > "nibble.max" <nibble.max@gmail.com> escreveu: > >> The current m88ts2022 driver will miss the following high symbol rate transponders on Telstar 18 138.0. >> 12385 H 43200, >> 12690 H 43200, >> 12538 V 41250... >> the code for f_3db_hz will overflow for the high symbol rate. >> for example, symbol rate=41250 KS/s >> symbol_rate * 135UL = 5568750000(1 4BEC 61B0), the value is larger than unsigned int on 32bit platform. >> that makes the wrong result. >> Exchanging the div and mul position fixs it. >> >> Signed-off-by: Nibble Max <nibble.max@gmail.com> >> --- >> drivers/media/tuners/m88ts2022.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/media/tuners/m88ts2022.c b/drivers/media/tuners/m88ts2022.c >> index 40c42de..65c8acc 100644 >> --- a/drivers/media/tuners/m88ts2022.c >> +++ b/drivers/media/tuners/m88ts2022.c >> @@ -314,7 +314,7 @@ static int m88ts2022_set_params(struct dvb_frontend *fe) >> div_min = gdiv28 * 78 / 100; >> div_max = clamp_val(div_max, 0U, 63U); >> >> - f_3db_hz = c->symbol_rate * 135UL / 200UL; >> + f_3db_hz = (c->symbol_rate / 200UL) * 135UL; > > Hmm... wouldn't this make worse for low symbol rates? > > IMHO, the better is to use a u64 instead, and do_div64(). > >> f_3db_hz += 2000000U + (frequency_offset_khz * 1000U); >> f_3db_hz = clamp(f_3db_hz, 7000000U, 40000000U); >> I will look that more carefully on end of next week, go through possible symbol rates and rounding errors. Maybe it should be something like that (didn't test any way, may not even compile): f_3db_hz = div_u64((u64) (c->symbol_rate * 135), 200); Antti
>Em Sat, 16 Aug 2014 14:12:32 +0800 >"nibble.max" <nibble.max@gmail.com> escreveu: > >> The current m88ts2022 driver will miss the following high symbol rate transponders on Telstar 18 138.0. >> 12385 H 43200, >> 12690 H 43200, >> 12538 V 41250... >> the code for f_3db_hz will overflow for the high symbol rate. >> for example, symbol rate=41250 KS/s >> symbol_rate * 135UL = 5568750000(1 4BEC 61B0), the value is larger than unsigned int on 32bit platform. >> that makes the wrong result. >> Exchanging the div and mul position fixs it. >> >> Signed-off-by: Nibble Max <nibble.max@gmail.com> >> --- >> drivers/media/tuners/m88ts2022.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/media/tuners/m88ts2022.c b/drivers/media/tuners/m88ts2022.c >> index 40c42de..65c8acc 100644 >> --- a/drivers/media/tuners/m88ts2022.c >> +++ b/drivers/media/tuners/m88ts2022.c >> @@ -314,7 +314,7 @@ static int m88ts2022_set_params(struct dvb_frontend *fe) >> div_min = gdiv28 * 78 / 100; >> div_max = clamp_val(div_max, 0U, 63U); >> >> - f_3db_hz = c->symbol_rate * 135UL / 200UL; >> + f_3db_hz = (c->symbol_rate / 200UL) * 135UL; > >Hmm... wouldn't this make worse for low symbol rates? > The unit of symbol rate for Satellite is KS/s(1000S/s). So it is safe to divide 200 at the first. >IMHO, the better is to use a u64 instead, and do_div64(). > >> f_3db_hz += 2000000U + (frequency_offset_khz * 1000U); >> f_3db_hz = clamp(f_3db_hz, 7000000U, 40000000U); >> > >Regards, >-- > >Cheers, >Mauro
On 16.08.2014 14:53, Antti Palosaari wrote: > > > I will look that more carefully on end of next week, go through possible > symbol rates and rounding errors. > > Maybe it should be something like that (didn't test any way, may not > even compile): > f_3db_hz = div_u64((u64) (c->symbol_rate * 135), 200); > In this case c->symbol_rate * 135 is still 32bits wide, but maybe signed because 135 is signed. So there will be an overflow on 32bit platforms at symbol rates equal to 15907287. So better cast symbol_rate to u64 before. Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/tuners/m88ts2022.c b/drivers/media/tuners/m88ts2022.c index 40c42de..65c8acc 100644 --- a/drivers/media/tuners/m88ts2022.c +++ b/drivers/media/tuners/m88ts2022.c @@ -314,7 +314,7 @@ static int m88ts2022_set_params(struct dvb_frontend *fe) div_min = gdiv28 * 78 / 100; div_max = clamp_val(div_max, 0U, 63U); - f_3db_hz = c->symbol_rate * 135UL / 200UL; + f_3db_hz = (c->symbol_rate / 200UL) * 135UL; f_3db_hz += 2000000U + (frequency_offset_khz * 1000U); f_3db_hz = clamp(f_3db_hz, 7000000U, 40000000U);
The current m88ts2022 driver will miss the following high symbol rate transponders on Telstar 18 138.0. 12385 H 43200, 12690 H 43200, 12538 V 41250... the code for f_3db_hz will overflow for the high symbol rate. for example, symbol rate=41250 KS/s symbol_rate * 135UL = 5568750000(1 4BEC 61B0), the value is larger than unsigned int on 32bit platform. that makes the wrong result. Exchanging the div and mul position fixs it. Signed-off-by: Nibble Max <nibble.max@gmail.com> --- drivers/media/tuners/m88ts2022.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)