Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 12月, 2009 1 次提交
  3. 06 12月, 2009 32 次提交
  5. 04 12月, 2009 1 次提交
  7. 28 11月, 2009 1 次提交
    • A
      V4L/DVB (13530): Fix wrong parameter order in memset · 361c9511
      由 Alan Cox 提交于 
      Edwin Török found the following:

In function ‘memset’,
inlined from ‘ir_input_init’ at drivers/media/common/ir-functions.c:67:
/home/edwin/builds/linux-2.6/arch/x86/include/asm/string_64.h:61:
warning: call to ‘__warn_memset_zero_len’ declared with attribute
warning: memset used with constant zero length parameter; this could be
due to transposed parameters
memset(ir->ir_codes, sizeof(ir->ir_codes), 0);

In actual practice the only caller I can find happens to already have cleared
the buffer before calling ir_input_init.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      361c9511
  9. 07 11月, 2009 2 次提交
    • S
      V4L/DVB (13109): tda18271: fix signedness issue in tda18271_rf_tracking_filters_init · a57c1dcb
      由 Seth Barry 提交于 
      While having tda18271 module set with debug=17 (cal & info prints) and
cal=0 (delay calibration process until first use) - I discovered that
during the calibration process, if the frequency test for 69750000
returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that
the tuner wouldn't be able to pickup any of the frequencies in the range
(all the other frequencies bands returned bcal=1).  I spent some time
going over the code and the NXP's tda18271 spec (ver.4 of it i think) and
adding a lot of debug prints and walking/stepping through the calibration
process.  I found that when the powerscan fails to find a frequency, the
rf calibration is not run and the default value is supposed to be used in
its place (pulled from the RF_CAL_map table) - but something was getting
goofed up there.

Now, my c coding skills are very rusty, but i think root of the problem is
a signedness issue with the math operation for calculating the rf_a1 and
rf_a2 values in tda18271_rf_tracking_filters_init func, which results in
values like 20648 for rf_a1 (when it should probably have a value like 0,
or so slightly negative that it should be zero - this bad value for rf_a1
would in turn makes the approx calc within
tda18271c2_rf_tracking_filters_correction go out of whack).  The simplest
solution i found was to explicitly convert the signedness of the
denominator to avoid the implicit conversion.  The values placed into the
u32 rf_freq array should never exceed about 900mhz, so i think the s32 max
value shouldn't be an issue in this case.

I've tested it out a little, and even when i get a bcal=0 with the
modified code, the default calibration value gets used, rf_a1 is zero, and
the tuner seems to lock on the stream and mythtv seems to play it fine.
Signed-off-by: NSeth Barry <seth@cyberseth.com>
Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a57c1dcb
    • M
      V4L/DVB (13107): tda18271: fix overflow in FM radio frequency calculation · 4d831787
      由 Michael Krufky 提交于 
      Multiplication by 62500 causes an overflow in the 32 bit freq variable,
which is later divided by 1000 when using FM radio.

This patch prevents the overflow by scaling the frequency value correctly
upfront.  Thanks to Henk Vergonet for spotting the problem and providing
a preliminary patch, which this changeset was based upon.

Cc: Henk Vergonet <Henk.Vergonet@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      4d831787
  11. 19 9月, 2009 3 次提交