IDE driver in polling mode

IDE driver in polling mode

[Michael]

Hi.
I have a board with MPC8541(PPC PQ3) platform running 2.6.14 Linux.

I'd like to know whether it is possible to use IDE driver (ide-disk)
in polling mode, instead of using IRQ.

In case you wonder - the reason why I need this weired thing is that I
have a compact flash connected directly to the host local bus using
memory mode. It is more-or-less IDE-compatible, except that it doesn't
issue interrupts.

Thanks,
             Michael.

Re: IDE driver in polling mode

[Sergei Shtylyov]

Hello.

Michael wrote:

> I'd like to know whether it is possible to use IDE driver (ide-disk)
> in polling mode, instead of using IRQ.

    I generally wouldn't recommend using this mode since the ATA polling 
protocol had been racy for years, WRT to the interrupt pending condition.

> In case you wonder - the reason why I need this weired thing is that I
> have a compact flash connected directly to the host local bus using
> memory mode. It is more-or-less IDE-compatible, except that it doesn't
> issue interrupts.

    Ah, no interrupts at all...
    The old IDE core in drivers/ide/ certainly doesn't support polling mode 
and IRQ-less devices. AFAICS, libata also doesn't support the latter...

MBR, Sergei

Re: IDE driver in polling mode

[Sergei Shtylyov]

Hello.

Michael wrote:

> I'd like to know whether it is possible to use IDE driver (ide-disk)
> in polling mode, instead of using IRQ.

    I generally wouldn't recommend using this mode since the ATA polling 
protocol had been racy for years, WRT to the interrupt pending condition.

> In case you wonder - the reason why I need this weired thing is that I
> have a compact flash connected directly to the host local bus using
> memory mode. It is more-or-less IDE-compatible, except that it doesn't
> issue interrupts.

    Ah, no interrupts at all...
    The old IDE core in drivers/ide/ certainly doesn't support polling mode 
and IRQ-less devices. AFAICS, libata also doesn't support the latter...

MBR, Sergei

Re: IDE driver in polling mode

[Mark Lord]

> Michael wrote:
> 
>> I'd like to know whether it is possible to use IDE driver (ide-disk)
>> in polling mode, instead of using IRQ.

This should be doable, with a small amount of hacking.
Mostly, you just need to use add_timer() to set up a polling
function that simply calls ide_intr() and then does add_timer()
again for the next poll.

For your purposes, it could be as simple as five lines of C.

Cheers

Re: IDE driver in polling mode

[Michael]

Thanks, looks like a good plan...

On 4/10/07, Mark Lord <liml@rtr.ca> wrote:
> > Michael wrote:
> >
> >> I'd like to know whether it is possible to use IDE driver (ide-disk)
> >> in polling mode, instead of using IRQ.
>
> This should be doable, with a small amount of hacking.
> Mostly, you just need to use add_timer() to set up a polling
> function that simply calls ide_intr() and then does add_timer()
> again for the next poll.
>
> For your purposes, it could be as simple as five lines of C.
>
> Cheers
>

Re: IDE driver in polling mode

[Alan Cox]

>     Ah, no interrupts at all...
>     The old IDE core in drivers/ide/ certainly doesn't support polling mode 
> and IRQ-less devices. AFAICS, libata also doesn't support the latter...

libata has much of the framework to do this as it originally did all of
its PIO work much this way. That is probably the most productive place to
start hacking.

Alan

Re: IDE driver in polling mode

[Jeff Garzik]

Alan Cox wrote:
>>     Ah, no interrupts at all...
>>     The old IDE core in drivers/ide/ certainly doesn't support polling mode 
>> and IRQ-less devices. AFAICS, libata also doesn't support the latter...
> 
> libata has much of the framework to do this as it originally did all of
> its PIO work much this way. That is probably the most productive place to
> start hacking.

Yep.

The only real restriction in libata is in ata_device_add(), which 
unconditionally registers an irq handler.  Make a few changes there, add 
a few flags, and the existing polling code will kick in.

Once we have higher priority stuff sorted, I would like to look into 
things like activating the polling code when it becomes obvious that the 
system is not delivering interrupts.

	Jeff

Re: IDE driver in polling mode

[Jeff Garzik]

Alan Cox wrote:
>>     Ah, no interrupts at all...
>>     The old IDE core in drivers/ide/ certainly doesn't support polling mode 
>> and IRQ-less devices. AFAICS, libata also doesn't support the latter...
> 
> libata has much of the framework to do this as it originally did all of
> its PIO work much this way. That is probably the most productive place to
> start hacking.

Yep.

The only real restriction in libata is in ata_device_add(), which 
unconditionally registers an irq handler.  Make a few changes there, add 
a few flags, and the existing polling code will kick in.

Once we have higher priority stuff sorted, I would like to look into 
things like activating the polling code when it becomes obvious that the 
system is not delivering interrupts.

	Jeff

Re: IDE driver in polling mode

[Alan Cox]

> The only real restriction in libata is in ata_device_add(), which 
> unconditionally registers an irq handler.  Make a few changes there, add 
> a few flags, and the existing polling code will kick in.

Obvious thing to do would be to do this if the IRQ number passed in is 0
rather than aborting as we do now. In theory ISAPnP devices may be
IRQless too.

Alan

Re: IDE driver in polling mode

[Michael]

Doesn't libata have to do with SCSI devices? I'm afraid it wouldn't
work with CF, which is P-ATA compatible.

Wouldn't it work just to call ide_intr() explicitly from some polling
function, as Mark suggested?

Michael

On 4/10/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > The only real restriction in libata is in ata_device_add(), which
> > unconditionally registers an irq handler.  Make a few changes there, add
> > a few flags, and the existing polling code will kick in.
>
> Obvious thing to do would be to do this if the IRQ number passed in is 0
> rather than aborting as we do now. In theory ISAPnP devices may be
> IRQless too.
>
> Alan
>

Re: IDE driver in polling mode

[Michael]

Doesn't libata have to do with SCSI devices? I'm afraid it wouldn't
work with CF, which is P-ATA compatible.

Wouldn't it work just to call ide_intr() explicitly from some polling
function, as Mark suggested?

Michael

On 4/10/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > The only real restriction in libata is in ata_device_add(), which
> > unconditionally registers an irq handler.  Make a few changes there, add
> > a few flags, and the existing polling code will kick in.
>
> Obvious thing to do would be to do this if the IRQ number passed in is 0
> rather than aborting as we do now. In theory ISAPnP devices may be
> IRQless too.
>
> Alan
>

Re: IDE driver in polling mode

[Alan Cox]

On Wed, 11 Apr 2007 10:39:58 +0200
Michael <michaelzwrk@gmail.com> wrote:

> Doesn't libata have to do with SCSI devices? I'm afraid it wouldn't
> work with CF, which is P-ATA compatible.

libata drives PATA and SATA devices, including CF.

> Wouldn't it work just to call ide_intr() explicitly from some polling
> function, as Mark suggested?

No. See the ATA spec - polling command issue is subtly different.

Alan

Re: IDE driver in polling mode

[Michael]

I see.
The problem is I am constrained to 2.6.14 kernel.
Is it still correct to say it is P-ATA compatible?

On 4/11/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Wed, 11 Apr 2007 10:39:58 +0200
> Michael <michaelzwrk@gmail.com> wrote:
>
> > Doesn't libata have to do with SCSI devices? I'm afraid it wouldn't
> > work with CF, which is P-ATA compatible.
>
> libata drives PATA and SATA devices, including CF.
>
> > Wouldn't it work just to call ide_intr() explicitly from some polling
> > function, as Mark suggested?
>
> No. See the ATA spec - polling command issue is subtly different.
>
> Alan
>

Re: IDE driver in polling mode

[Michael]

I see.
The problem is I am constrained to 2.6.14 kernel.
Is it still correct to say it is P-ATA compatible?

On 4/11/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Wed, 11 Apr 2007 10:39:58 +0200
> Michael <michaelzwrk@gmail.com> wrote:
>
> > Doesn't libata have to do with SCSI devices? I'm afraid it wouldn't
> > work with CF, which is P-ATA compatible.
>
> libata drives PATA and SATA devices, including CF.
>
> > Wouldn't it work just to call ide_intr() explicitly from some polling
> > function, as Mark suggested?
>
> No. See the ATA spec - polling command issue is subtly different.
>
> Alan
>

Re: IDE driver in polling mode

[Alan Cox]

On Wed, 11 Apr 2007 17:10:12 +0200
Michael <michaelzwrk@gmail.com> wrote:

> I see.
> The problem is I am constrained to 2.6.14 kernel.

Make sure you backport any relevant network security fixes in that case.

If you are working to 2.6.14, then your easiest route may be to write a
polling CF driver from scratch. If you only have to support PIO and you
only do ATA not ATAPI then it isn't a large amount of code.

Alan

Re: IDE driver in polling mode

[Alan Cox]

On Wed, 11 Apr 2007 17:10:12 +0200
Michael <michaelzwrk@gmail.com> wrote:

> I see.
> The problem is I am constrained to 2.6.14 kernel.

Make sure you backport any relevant network security fixes in that case.

If you are working to 2.6.14, then your easiest route may be to write a
polling CF driver from scratch. If you only have to support PIO and you
only do ATA not ATAPI then it isn't a large amount of code.

Alan

Re: IDE driver in polling mode

[Mark Lord]

Michael,

Here is a patch to have drivers/ide use polling
for all operations, in addition to IRQs.

Patch is against 2.6.21, but should apply and work equally well
on earlier kernels (including 2.6.14).

This quick hack is *not* for general kernel inclusion.
It works for me.  I tested it using a CF card in a PC-CARD adapter.

Signed-off-by:  Mark Lord <mlord@pobox.com>

--- 2.6.21/drivers/ide/ide-probe.c	2007-04-11 00:18:51.000000000 -0400
+++ new/drivers/ide/ide-probe.c	2007-04-12 09:26:14.000000000 -0400
@@ -1014,6 +1014,27 @@
  * but anything else has led to problems on some machines.  We re-enable
  * interrupts as much as we can safely do in most places.
  */
+struct timer_list polling_timer;
+static void ide_polling (unsigned long data)
+{
+	ide_hwgroup_t *hwgroup = (void *)data;
+	ide_hwif_t *hwif;
+	int irq = 0;
+
+	if (hwgroup) {
+		hwif = hwgroup->hwif;
+		if (hwif)
+			irq = hwif->irq;
+	}
+
+	ide_intr(irq, hwgroup);
+	init_timer(&polling_timer);
+	polling_timer.expires = jiffies + 1;
+	polling_timer.function = &ide_polling;
+	polling_timer.data = (unsigned long) hwgroup;
+	add_timer(&polling_timer);
+}
+
 static int init_irq (ide_hwif_t *hwif)
 {
 	unsigned int index;
@@ -1110,9 +1131,12 @@
 		if (hwif->io_ports[IDE_CONTROL_OFFSET])
 			/* clear nIEN */
 			hwif->OUTB(0x08, hwif->io_ports[IDE_CONTROL_OFFSET]);
-
+#if 0
 		if (request_irq(hwif->irq,&ide_intr,sa,hwif->name,hwgroup))
 	       		goto out_unlink;
+#else
+		ide_polling((unsigned long)hwgroup);
+#endif
 	}
 
 	/*
@@ -1156,6 +1180,7 @@
 	printk("\n");
 	up(&ide_cfg_sem);
 	return 0;
+#if 0
 out_unlink:
 	spin_lock_irq(&ide_lock);
 	if (hwif->next == hwif) {
@@ -1176,6 +1201,7 @@
 		BUG_ON(hwgroup->hwif == hwif);
 	}
 	spin_unlock_irq(&ide_lock);
+#endif
 out_up:
 	up(&ide_cfg_sem);
 	return 1;
--- 2.6.21/drivers/ide/ide.c	2007-04-11 00:18:51.000000000 -0400
+++ new/drivers/ide/ide.c	2007-04-12 09:31:59.000000000 -0400
@@ -569,6 +569,8 @@
  *	This is raving bonkers.
  */
 
+extern struct timer_list polling_timer;
+
 void ide_unregister(unsigned int index)
 {
 	ide_drive_t *drive;
@@ -612,7 +614,11 @@
 		g = g->next;
 	} while (g != hwgroup->hwif);
 	if (irq_count == 1)
+#if 0
 		free_irq(hwif->irq, hwgroup);
+#else
+		del_timer(&polling_timer);
+#endif
 
 	spin_lock_irq(&ide_lock);
 	/*

Re: IDE driver in polling mode

[Mark Lord]

Michael,

Here is a patch to have drivers/ide use polling
for all operations, in addition to IRQs.

Patch is against 2.6.21, but should apply and work equally well
on earlier kernels (including 2.6.14).

This quick hack is *not* for general kernel inclusion.
It works for me.  I tested it using a CF card in a PC-CARD adapter.

Signed-off-by:  Mark Lord <mlord@pobox.com>

--- 2.6.21/drivers/ide/ide-probe.c	2007-04-11 00:18:51.000000000 -0400
+++ new/drivers/ide/ide-probe.c	2007-04-12 09:26:14.000000000 -0400
@@ -1014,6 +1014,27 @@
  * but anything else has led to problems on some machines.  We re-enable
  * interrupts as much as we can safely do in most places.
  */
+struct timer_list polling_timer;
+static void ide_polling (unsigned long data)
+{
+	ide_hwgroup_t *hwgroup = (void *)data;
+	ide_hwif_t *hwif;
+	int irq = 0;
+
+	if (hwgroup) {
+		hwif = hwgroup->hwif;
+		if (hwif)
+			irq = hwif->irq;
+	}
+
+	ide_intr(irq, hwgroup);
+	init_timer(&polling_timer);
+	polling_timer.expires = jiffies + 1;
+	polling_timer.function = &ide_polling;
+	polling_timer.data = (unsigned long) hwgroup;
+	add_timer(&polling_timer);
+}
+
 static int init_irq (ide_hwif_t *hwif)
 {
 	unsigned int index;
@@ -1110,9 +1131,12 @@
 		if (hwif->io_ports[IDE_CONTROL_OFFSET])
 			/* clear nIEN */
 			hwif->OUTB(0x08, hwif->io_ports[IDE_CONTROL_OFFSET]);
-
+#if 0
 		if (request_irq(hwif->irq,&ide_intr,sa,hwif->name,hwgroup))
 	       		goto out_unlink;
+#else
+		ide_polling((unsigned long)hwgroup);
+#endif
 	}
 
 	/*
@@ -1156,6 +1180,7 @@
 	printk("\n");
 	up(&ide_cfg_sem);
 	return 0;
+#if 0
 out_unlink:
 	spin_lock_irq(&ide_lock);
 	if (hwif->next == hwif) {
@@ -1176,6 +1201,7 @@
 		BUG_ON(hwgroup->hwif == hwif);
 	}
 	spin_unlock_irq(&ide_lock);
+#endif
 out_up:
 	up(&ide_cfg_sem);
 	return 1;
--- 2.6.21/drivers/ide/ide.c	2007-04-11 00:18:51.000000000 -0400
+++ new/drivers/ide/ide.c	2007-04-12 09:31:59.000000000 -0400
@@ -569,6 +569,8 @@
  *	This is raving bonkers.
  */
 
+extern struct timer_list polling_timer;
+
 void ide_unregister(unsigned int index)
 {
 	ide_drive_t *drive;
@@ -612,7 +614,11 @@
 		g = g->next;
 	} while (g != hwgroup->hwif);
 	if (irq_count == 1)
+#if 0
 		free_irq(hwif->irq, hwgroup);
+#else
+		del_timer(&polling_timer);
+#endif
 
 	spin_lock_irq(&ide_lock);
 	/*

Re: IDE driver in polling mode

[Mark Lord]

Mark Lord wrote:
> Michael,
> 
> Here is a patch to have drivers/ide use polling
> for all operations, in addition to IRQs.

s/in addition to/instead of/

If you need IRQs + polling, then just un-ifdef
the request_irq() and free_irq() lines.

Cheers

Re: IDE driver in polling mode

[Mark Lord]

Mark Lord wrote:
> Michael,
> 
> Here is a patch to have drivers/ide use polling
> for all operations, in addition to IRQs.

s/in addition to/instead of/

If you need IRQs + polling, then just un-ifdef
the request_irq() and free_irq() lines.

Cheers

Re: IDE driver in polling mode

[Mark Lord]

Alan Cox wrote:
> Michael <michaelzwrk@gmail.com> wrote:
> 
>> Wouldn't it work just to call ide_intr() explicitly from some polling
>> function, as Mark suggested?
> 
> No. See the ATA spec - polling command issue is subtly different.

I beg to differ, and have posted a patch to demonstrate it.

Cheers!

Re: IDE driver in polling mode

[Mark Lord]

Alan Cox wrote:
> Michael <michaelzwrk@gmail.com> wrote:
> 
>> Wouldn't it work just to call ide_intr() explicitly from some polling
>> function, as Mark suggested?
> 
> No. See the ATA spec - polling command issue is subtly different.

I beg to differ, and have posted a patch to demonstrate it.

Cheers!