Skip to contentSkip to conversation

transform udelay to mdelay

PATCH In review Thierry Merle 2 participants 2 messages Aug 26, 2008 – Aug 27, 2008 Media (V4L/DVB)

lore
Share & tools
lore

Thierry Merle

author
#0 lore raw

PATCH 1/1 transform udelay to mdelay

Hello,
following the conversation on the v4l-dvb-maitainer ML:
http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2008-August/007753.html
Contents:

Quoted 37 lines · Thierry Merle

Hi Martin

Quoted 18 lines · Martin Michlmayr

budget.ko fails to build on ARM with:

ERROR: "__bad_udelay" [drivers/media/dvb/ttpci/budget.ko] undefined! make[1]: *** [__modpost] Error 1

__bad_udelay is specifically designed on ARM to fail when udelay is called in a bad way. arch/arm/include/asm/delay.h has this to say about __bad_udelay:

/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value. *
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);

Quoted 4 lines

Can you check why your driver is calling udelay() with a value > 2000?

Right, I experienced the same problem with the em28xx (from mcentral.de) driver compilation on my NSLU2 target.
I guess you are doing the same thing for this driver.
The solution was to use mdelay when possible.
It solves the compilation on these low-power-consuming-but-high-capacities targets. Here are all the udelay with value greater than 2000 in v4l-dvb/:
linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c:
udelay(12500);
linux/drivers/media/dvb/bt8xx/dst.c: udelay(3000);
linux/drivers/media/dvb/bt8xx/dst.c: udelay(3000);
linux/drivers/media/dvb/ttpci/budget-patch.c:

Quoted 9 lines

udelay(12500);
linux/drivers/media/dvb/ttpci/budget.c: udelay(12500);
linux/drivers/media/video/bt8xx/bttv-cards.c: udelay(2500);
I attached a patch that replaces all these calls to mdelay, and additional udelay if necessary.
I cannot test it since I do not own any of these devices so this is just a proposal. Cheers,
Thierry

Here is the patch I proposed, this should be harmless but I have no device to test them.

Cheers,
Thierry

Signed-off-by Thierry Merle <[email protected]>
linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c +2 -1
diff -r a4843e1304e6 linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
@@ -137,7 +137,8 @@ static int flexcop_send_diseqc_msg(struc
 			flexcop_diseqc_send_byte(fe, 0xff);
 		else {
 			flexcop_set_tone(fe, SEC_TONE_ON);
-			udelay(12500);
+			mdelay(12);
+			udelay(500);
 			flexcop_set_tone(fe, SEC_TONE_OFF);
 		}
 		msleep(20);
linux/drivers/media/dvb/bt8xx/dst.c +2 -2
diff -r a4843e1304e6 linux/drivers/media/dvb/bt8xx/dst.c
@@ -1244,7 +1244,7 @@ static int dst_command(struct dst_state 
 		goto error;
 	}
 	if (state->type_flags & DST_TYPE_HAS_FW_1)
-		udelay(3000);
+		mdelay(3);
 	if (read_dst(state, &reply, GET_ACK)) {
 		dprintk(verbose, DST_DEBUG, 1, "Trying to recover.. ");
 		if ((dst_error_recovery(state)) < 0) {

@@ -1260,7 +1260,7 @@ static int dst_command(struct dst_state 
 	if (len >= 2 && data[0] == 0 && (data[1] == 1 || data[1] == 3))
 		goto error;
 	if (state->type_flags & DST_TYPE_HAS_FW_1)
-		udelay(3000);
+		mdelay(3);
 	else
 		udelay(2000);
 	if (!dst_wait_dst_ready(state, NO_DELAY))
linux/drivers/media/dvb/ttpci/budget-patch.c +2 -1
diff -r a4843e1304e6 linux/drivers/media/dvb/ttpci/budget-patch.c
@@ -116,7 +116,8 @@ static int SendDiSEqCMsg (struct budget 
 			DiseqcSendByte(budget, 0xff);
 		else {
 			saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTHI);
-			udelay(12500);
+			mdelay(12);
+			udelay(500);
 			saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTLO);
 		}
 		msleep(20);
linux/drivers/media/dvb/ttpci/budget.c +2 -1
diff -r a4843e1304e6 linux/drivers/media/dvb/ttpci/budget.c
@@ -108,7 +108,8 @@ static int SendDiSEqCMsg (struct budget 
 			DiseqcSendByte(budget, 0xff);
 		else {
 			saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTHI);
-			udelay(12500);
+			mdelay(12);
+			udelay(500);
 			saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTLO);
 		}
 		msleep(20);
linux/drivers/media/video/bt8xx/bttv-cards.c +2 -1
diff -r a4843e1304e6 linux/drivers/media/video/bt8xx/bttv-cards.c
@@ -4103,7 +4103,8 @@ static void __devinit boot_msp34xx(struc
 
 	gpio_inout(mask,mask);
 	gpio_bits(mask,0);
-	udelay(2500);
+	mdelay(2);
+	udelay(500);
 	gpio_bits(mask,mask);
 
 	if (bttv_gpio)

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#1 lore raw
Quoted 8 lines · Thierry Merle
Quoted 6 lines

Right, I experienced the same problem with the em28xx (from mcentral.de) driver compilation on my NSLU2 target.
I guess you are doing the same thing for this driver.
The solution was to use mdelay when possible.
It solves the compilation on these low-power-consuming-but-high-capacities targets.

Here is the patch I proposed, this should be harmless but I have no device to test them.

I think mdelay and udelay should be safe for this. I know that generally msleep(2) will produce a much shorter sleep than "msleep(1);msleep(1);"

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb