Skip to contentSkip to conversation

parport/ieee1284: replace

PATCH In review Nishanth Aravamudan 2 participants 3 messages Jul 27, 2004 – Jul 28, 2004

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 parport/ieee1284: replace

I would appreciate any comments from the janitors list. This is one (of many) cases where I made a decision about replacing

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(some_time);

with

msleep(jiffies_to_msecs(some_time));

msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch.

Thanks,
Nish

Applys-to: 2.6.7

Description: Uses msleep() instead of schedule_timeout() to guarantee the task delays the desired time.

drivers/parport/ieee1284.c +2 -4
@@ -212,13 +212,11 @@ int parport_wait_peripheral(struct parpo
 		if ((status & mask) == result)
 			return 0;
 
-		if (!ret) {
+		if (!ret) 
 			/* parport_wait_event didn't time out, but the
 			 * peripheral wasn't actually ready either.
 			 * Wait for another 10ms. */
-			__set_current_state (TASK_INTERRUPTIBLE);
-			schedule_timeout ((HZ+ 99) / 100);
-		}
+			msleep(10);
 	}
 
 	return 1;

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#1 lore raw

PATCH 1/1 parport/ieee1284_ops: replace

I would appreciate any comments from the janitors list. This is one (of many) cases where I made a decision about replacing

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(some_time);

with

msleep(jiffies_to_msecs(some_time));

msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch.

Thanks,
Nish

Applys-to: 2.6.7

Description: Uses msleep() instead of schedule_timeout() to guarantee the task delays the desired time.

drivers/parport/ieee1284_ops.c +1 -2
@@ -542,8 +542,7 @@ size_t parport_ieee1284_ecp_read_data (s
 			/* Yield the port for a while. */
 			if (count && dev->port->irq != PARPORT_IRQ_NONE) {
 				parport_release (dev);
-				__set_current_state (TASK_INTERRUPTIBLE);
-				schedule_timeout ((HZ + 24) / 25);
+				msleep(40);
 				parport_claim_or_block (dev);
 			}
 			else

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#2 lore raw

Re: [Kernel-janitors] [PATCH] parport/ieee1284:

In reply to Nishanth Aravamudan

I think TASK_INTERRUPTIBLE is needed here. The top of the loop the schedule_timeout is in looks for signals.

Quoted 52 lines · Nishanth Aravamudan

I would appreciate any comments from the janitors list. This is one (of many) cases where I made a decision about replacing

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(some_time);

with

msleep(jiffies_to_msecs(some_time));

msleep() is not exactly the same as the previous code, but I only did this replacement where I thought long delays were *desired*. If this is not the case here, then just disregard this patch.

Thanks,
Nish

Applys-to: 2.6.7

Description: Uses msleep() instead of schedule_timeout() to guarantee the task delays the desired time.

drivers/parport/ieee1284.c +2 -5
@@ -212,13 +212,11 @@ int parport_wait_peripheral(struct parpo
 		if ((status & mask) == result)
 			return 0;
 
-		if (!ret) {
+		if (!ret) 
 			/* parport_wait_event didn't time out, but the
 			 * peripheral wasn't actually ready either.
 			 * Wait for another 10ms. */
-			__set_current_state (TASK_INTERRUPTIBLE);
-			schedule_timeout ((HZ+ 99) / 100);
-		}
+			msleep(10);
 	}
 
 	return 1;
 
 
------------------------------------------------------------------------

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Signature · 2 lines
--------------------------
Mark Hollomon

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors