V4L/DVB fixes
PATCH 1/1 V4L/DVB fixes
Linus,
Please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
master
For two driver regression fixes:
- bttv: VIDIOCGMBUF ioctl hangs on bttv driver
- ivtv: udelay has to be changed *after* the eeprom was read, not before
Cheers,
Mauro.
---
drivers/media/video/bt8xx/bttv-driver.c | 4 +--- drivers/media/video/ivtv/ivtv-driver.c | 4 ++++ drivers/media/video/ivtv/ivtv-i2c.c | 5 +---- 3 files changed, 6 insertions(+), 7 deletions(-)
Gregor Jasny (1):
V4L/DVB (6944a): Fix Regression VIDIOCGMBUF ioctl hangs on bttv driver
Hans Verkuil (1):
V4L/DVB (6916): ivtv: udelay has to be changed *after* the eeprom was
read, not before
---------------------------------------------------
V4L/DVB development is hosted at http://linuxtv.org
Am Montag, 7. Januar 2008 schrieb Mauro Carvalho Chehab:
Quoted 4 lines
Hans Verkuil (1):
V4L/DVB (6916): ivtv: udelay has to be changed *after* the eeprom
was read, not before
boils down to this patch:
89dab3573aa1d95fd222ee4551f964bfa4c16823
drivers/media/video/ivtv/ivtv-driver.c | 4 ++++ drivers/media/video/ivtv/ivtv-i2c.c | 5 +---- 2 files changed, 5 insertions(+), 4 deletions(-)
(quoted diff) +0 -0
b/drivers/media/video/ivtv/ivtv-driver.c
index 6d2dd87..10d6faf 100644
drivers/media/video/ivtv/ivtv-driver.c +4 -0
@@ -1076,6 +1076,10 @@ static int __devinit ivtv_probe(struct pci_dev *dev,ivtv_process_eeprom (itv); } +/* The mspx4xx chips need a longer delay for some reason */ +if (!(itv->hw_flags &IVTV_HW_MSP34XX )) + itv->i2c_algo.udelay =5 ; +if (itv->std ==0 ) { itv->std =V4L2_STD_NTSC_M ; }
(quoted diff) +0 -0
b/drivers/media/video/ivtv/ivtv-i2c.c
index 44678fe..36e54f7 100644
drivers/media/video/ivtv/ivtv-i2c.c +0 -0
@@ -541,7 +541,7 @@ static const struct i2c_algo_bit_data
ivtv_i2c_algo_template = {
.setscl = ivtv_setscl_old,
.getsda = ivtv_getsda_old,
.getscl = ivtv_getscl_old,
- .udelay = 5,
+ .udelay = 10,
.timeout = 200,
};
@@ -718,9 +718,6 @@ int init_ivtv_i2c(struct ivtv *itv)
sizeof(struct i2c_adapter));
memcpy(&itv->i2c_algo, &ivtv_i2c_algo_template,
sizeof(struct i2c_algo_bit_data));
- /* The mspx4xx chips need a longer delay for some reason */
- if (itv->hw_flags & IVTV_HW_MSP34XX)
- itv->i2c_algo.udelay = 10;
itv->i2c_algo.data = itv; itv->i2c_adap.algo_data = &itv->i2c_algo;
}
where the logic in hunk #1 was switched, resulting in a now misleading comment over there.
How about something in the line of:
/* * We started with a bigger udelay in order to fulfill the needs of the * mspx4xx chips: cut it down here for all other members of the family. */
Cheers,
Pete
Quoted 7 lines · On Wed, 9 Jan 2008 16:43:51 +0100 Hans-Peter Jansen <[email protected]> wrote:
drivers/media/video/ivtv/ivtv-driver.c +4
-0+/* The mspx4xx chips need a longer delay for some reason */ +if (!(itv->hw_flags &IVTV_HW_MSP34XX )) + itv->i2c_algo.udelay =5 ; +where the logic in hunk #1 was switched, resulting in a now misleading comment over there.
If you notice the ! at the above line, and remind that the original value for udelay is 10, you can understand the comment ;)
Quoted 7 lines
How about something in the line of:
/* * We started with a bigger udelay in order to fulfill the needs of the * mspx4xx chips: cut it down here for all other members of the family. */
Your suggestion seems clearer to my eyes. Still the other possibilities are not from Micronas msp34xx family, but audio decoder chips from other vendors - as weel as other kind of i2c devices, like IR chips, video encoders, etc.
So, IMO, a better comment would be something like:
/*
* We started with a bigger udelay in order to avoid troubles with some
* msp34xx chips. Boards without msp34xx are known to work with the full
* i2c 100 kHz speed. */
I'm C/C the patch author (Hans) for his comments about this, since he is the one who faced with the problems with msp34xx and ivtv.
Cheers,
Mauro