Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1563347 > unrolled thread

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-20 08:50 +0100
    Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-21 08:40 +0100
      Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-23 09:10 +0100
        Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-26 09:50 +0100
          Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Geert Uytterhoeven <geert@linux-m68k.org> - 2017-01-26 10:10 +0100
            Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Finn Thain <fthain@telegraphics.com.au> - 2017-01-27 03:00 +0100
          Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Michael Schmitz <schmitzmic@gmail.com> - 2017-01-27 05:30 +0100

#1563347 — Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

Hi Finn,

Am 15.01.2017 um 17:42 schrieb Finn Thain:

>> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
>> registers) without touching the ST-DMA. The moment we select a FDC or 
>> SCSI register for read, DMA is terminated no questions asked.
>>
> 
> Perhaps we can convert DMA operations to PDMA (by polling with local irqs 
> disabled) and avoid the whole problem of interrupt handlers executing 
> during DMA transfers. The docs suggest that it is doable.
> 
> "Poll or service the Disk Driver Controller interrupt on the MK68901 MFP 
> General Purpose I/O Register to detect the completion of a WD1772 FDC 
> command. Do not poll the FDC Busy or DMA Sector Count Zero status bits." 
> -- ST HW Spec, p. 36.
> http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf

The MFP interrupt in question is the same as the one used by IDE
(wired-OR of IDE, FDC and SCSI), so we would still have to figure out
where the interrupt originated. Polling instead of taking the interrupt
does not change that fundamental problem (unless I'm missing something).

> 
> On page 18 there is an algorithm for floppy writes which is interesting.

That one (and the ACSI algorithm which would apply to SCSI for Falcon)
does suggest it won't be possible to peek at the sector count register
to detect end of DMA. The addendum (note 841017G) makes it clear that a
write to the DMA mode register is required to look at the status
register error bit (which might terminate DMA).

Maybe the DMA address register can be used to check for DMA completion
... it's used to check for residual or lost bytes anyway so that appears
to work. And the FDC driver does use the same strategy to check if
enough track data have been read.

Leaves the case where DMA hasn't completed but may have been aborted by
a NCR5380 interrupt. I suppose we can detect that by checking for any
change in the DMA address while repeatedly reading the DMA address
register. No change means the DMA has got stuck. Not exactly pretty but
all I can come up with.

> 
> I suspect that we will need to keep the FDC idle during SCSI transfers 
> (and vice versa) much as the present stdma.c lock does.
> 
> "The interrupt outputs of the internal floppy disk controller and the 
> external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP will 
> read as a '0' if either the FDC or a selected ACSI device controller is 
> asserting its interrupt request."
> -- ACSI/DMA Integration Guide, p.16.
> http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf

On Falcon, the IDE interrupt is also OR'ed to the above two interrupt
lines, hence the need for including IDE in the locking scheme there.

> 
> Polling the logically OR'ed interrupt sources to detect end-of-DMA will 
> not be reliable unless we disable those sources that aren't relevant. 
> Otherwise we access the DMA registers too early (which IIUC would kill the 
> transfer). I'm afraid we shall have to expect that a few transfers will be 
> interrupted by other devices in this way, and carefully check for this. 
> 
> For example, the 5380 SCSI bus reset interrupt is not maskable, which 
> could affect FDC transfers. If this terminated the polling for DMA 
> completion, the FDC driver then has to access the FDC registers and 
> confirm that the transfer was not terminated early.
> 

We'll have to make sure FDC and SCSI don't clash in their DMA and
interrupt use.

Cheers,

	Michael

[toc] | [next] | [standalone]

#1564068

On Fri, 20 Jan 2017, Michael Schmitz wrote:

> Am 15.01.2017 um 17:42 schrieb Finn Thain:
> 
> >> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
> >> registers) without touching the ST-DMA. The moment we select a FDC or 
> >> SCSI register for read, DMA is terminated no questions asked.
> >>
> > 
> > Perhaps we can convert DMA operations to PDMA (by polling with local 
> > irqs disabled) and avoid the whole problem of interrupt handlers 
> > executing during DMA transfers. The docs suggest that it is doable.
> > 
> > "Poll or service the Disk Driver Controller interrupt on the MK68901 
> > MFP General Purpose I/O Register to detect the completion of a WD1772 
> > FDC command. Do not poll the FDC Busy or DMA Sector Count Zero status 
> > bits." -- ST HW Spec, p. 36. 
> > http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf
> 
> The MFP interrupt in question is the same as the one used by IDE 
> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out 
> where the interrupt originated.

I thought you said the driver you're testing does not use any interrupt -- 
I was assuming that only atari_scsi and ataflop drivers share the 
interupt.

> Polling instead of taking the interrupt does not change that fundamental 
> problem (unless I'm missing something).
> 

Actually, the fundamental problem you are describing is partly solved. By 
polling for DMA completion with local irqs disabled, we mostly avoid the 
need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can 
never interfere with a FDC/SCSI DMA process that might be underway.

> > 
> > On page 18 there is an algorithm for floppy writes which is 
> > interesting.
> 
> That one (and the ACSI algorithm which would apply to SCSI for Falcon) 
> does suggest it won't be possible to peek at the sector count register 
> to detect end of DMA. The addendum (note 841017G) makes it clear that a 
> write to the DMA mode register is required to look at the status 
> register error bit (which might terminate DMA).
> 
> Maybe the DMA address register can be used to check for DMA completion 
> ... it's used to check for residual or lost bytes anyway so that appears 
> to work. And the FDC driver does use the same strategy to check if 
> enough track data have been read.
> 
> Leaves the case where DMA hasn't completed but may have been aborted by 
> a NCR5380 interrupt. I suppose we can detect that by checking for any 
> change in the DMA address while repeatedly reading the DMA address 
> register. No change means the DMA has got stuck. Not exactly pretty but 
> all I can come up with.
> 

We don't have to poll any DMA registers (and I don't believe that it is 
viable to do so). I was talking about polling for end of DMA by polling 
for the interrupt (as per docs) but with local irqs disabled for the 
duration of the transfer (which provides exlusive access to the DMA chip).

> > 
> > I suspect that we will need to keep the FDC idle during SCSI transfers 
> > (and vice versa) much as the present stdma.c lock does.
> > 
> > "The interrupt outputs of the internal floppy disk controller and the 
> > external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP 
> > will read as a '0' if either the FDC or a selected ACSI device 
> > controller is asserting its interrupt request." -- ACSI/DMA 
> > Integration Guide, p.16. 
> > http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf
> 
> On Falcon, the IDE interrupt is also OR'ed to the above two interrupt 
> lines, hence the need for including IDE in the locking scheme there.
> 

I don't think the IDE/ATA driver needs to be included. atari_scsi and 
ataflop would though (if both drivers need DMA transfers).

> > 
> > Polling the logically OR'ed interrupt sources to detect end-of-DMA 
> > will not be reliable unless we disable those sources that aren't 
> > relevant. Otherwise we access the DMA registers too early (which IIUC 
> > would kill the transfer). I'm afraid we shall have to expect that a 
> > few transfers will be interrupted by other devices in this way, and 
> > carefully check for this.
> > 
> > For example, the 5380 SCSI bus reset interrupt is not maskable, which 
> > could affect FDC transfers. If this terminated the polling for DMA 
> > completion, the FDC driver then has to access the FDC registers and 
> > confirm that the transfer was not terminated early.
> > 
> 
> We'll have to make sure FDC and SCSI don't clash in their DMA and 
> interrupt use.
> 

The point I was trying to make above is that stdma lock only gets you so 
far: if SCSI or FDC generate an interrupt that can't be disabled, it could 
mess up the interrupt polling (and the interrupt polling is a necessary 
consequence of IDE operating without stdma lock). This would lead to a 
short transfer (which could be easily detected).

So the chips clash in their interrupt line use (rarely). The drivers need 
not clash at all.

Anyway, we seem to be talking past each other somewhat. I suggest we start 
coding and discuss actual patches ... unless you can convince me that this 
won't work ...

-- 

> Cheers,
> 
> 	Michael
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[toc] | [prev] | [next] | [standalone]

#1564750

Hi Finn,

Am 21.01.2017 um 20:37 schrieb Finn Thain:

>> The MFP interrupt in question is the same as the one used by IDE 
>> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out 
>> where the interrupt originated.
> 
> I thought you said the driver you're testing does not use any interrupt -- 
> I was assuming that only atari_scsi and ataflop drivers share the 
> interupt.

My mistake - I was considering options to allow IDE to share the
interrupt, without the complexities of the old locking scheme.

> 
>> Polling instead of taking the interrupt does not change that fundamental 
>> problem (unless I'm missing something).
>>
> 
> Actually, the fundamental problem you are describing is partly solved. By 
> polling for DMA completion with local irqs disabled, we mostly avoid the 
> need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can 
> never interfere with a FDC/SCSI DMA process that might be underway.

I hadn't considered that. Can PDMA for Falcon SCSI coexist with
interrupt-using DMA for TT SCSI in the same driver (i.e. as runtime
options)? How much overhead and latency would polling for DMA completion
add?

>> Maybe the DMA address register can be used to check for DMA completion 
>> ... it's used to check for residual or lost bytes anyway so that appears 
>> to work. And the FDC driver does use the same strategy to check if 
>> enough track data have been read.
>>
>> Leaves the case where DMA hasn't completed but may have been aborted by 
>> a NCR5380 interrupt. I suppose we can detect that by checking for any 
>> change in the DMA address while repeatedly reading the DMA address 
>> register. No change means the DMA has got stuck. Not exactly pretty but 
>> all I can come up with.
>>
> 
> We don't have to poll any DMA registers (and I don't believe that it is 
> viable to do so). I was talking about polling for end of DMA by polling 
> for the interrupt (as per docs) but with local irqs disabled for the 
> duration of the transfer (which provides exlusive access to the DMA chip).

atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending
condition if you want to poll for it. That's actually given me another
idea to pursue - if we can ensure the IDE interrupt handler is always
run first, and check whether the interrupt is still pending when the
SCSI or floppy interrupt handler runs and DMA has been in progress, we
should be able to avoid calling the respective handlers unnecessarily.

(The output of atari_irq_pending() does not directly reflect the status
of the MFP IRQ inputs - that would require testing bits in
st_mfp.par_dt_reg instead. )

> I don't think the IDE/ATA driver needs to be included. atari_scsi and 
> ataflop would though (if both drivers need DMA transfers).

If we manage to separate interrupt sharing from DMA access locking, IDE
would not need to take part in the locking. I'm assuming that IDE can
cope with spurious interrupts and won't get confused by a SCSI interrupt.

>>> For example, the 5380 SCSI bus reset interrupt is not maskable, which 
>>> could affect FDC transfers. If this terminated the polling for DMA 
>>> completion, the FDC driver then has to access the FDC registers and 
>>> confirm that the transfer was not terminated early.
>>>
>>
>> We'll have to make sure FDC and SCSI don't clash in their DMA and 
>> interrupt use.
>>
> 
> The point I was trying to make above is that stdma lock only gets you so 
> far: if SCSI or FDC generate an interrupt that can't be disabled, it could 
> mess up the interrupt polling (and the interrupt polling is a necessary 
> consequence of IDE operating without stdma lock). This would lead to a 
> short transfer (which could be easily detected).

Point taken - that problem still remains but is already being detected
(though not properly handled IIRC),

> So the chips clash in their interrupt line use (rarely). The drivers need 
> not clash at all.
> 
> Anyway, we seem to be talking past each other somewhat. I suggest we start 
> coding and discuss actual patches ... unless you can convince me that this 
> won't work ...

I think it could work both ways - polling for DMA completion or avoiding
to call the SCSI interrupt handler the interrupt was caused by IDE only.
But it's indeed time to put that to the test.

Cheers,

	Michael

[toc] | [prev] | [next] | [standalone]

#1567182

On Mon, 23 Jan 2017, Michael Schmitz wrote:

> 
> Am 21.01.2017 um 20:37 schrieb Finn Thain:
> 
> > 
> > Actually, the fundamental problem you are describing is partly solved. 
> > By polling for DMA completion with local irqs disabled, we mostly 
> > avoid the need for the stdma.c "lock" because FDC/SCSI/IDE interrupt 
> > handlers can never interfere with a FDC/SCSI DMA process that might be 
> > underway.
> 
> I hadn't considered that. Can PDMA for Falcon SCSI coexist with 
> interrupt-using DMA for TT SCSI in the same driver (i.e. as runtime 
> options)?

Sure, why not?

> How much overhead and latency would polling for DMA completion add?
> 

A polled DMA transfer should be faster than PDMA (i.e. mac_scsi, g_NCR5380 
etc). mac_scsi gets about 0.5 MBps from PDMA with sg_tablesize == 1, and I 
hope that DMA could get twice that (notwithstanding dumb hardware design). 

This would imply CPU overhead that is half of that which mac_scsi incurs. 
That's the best case, but I see no reason to expect worse performance than 
PDMA gets.

> atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending 
> condition if you want to poll for it.

The difficulty will be arranging for disabled FDC & IDE interrupt sources 
during SCSI DMA, and disabled SCSI & IDE interrupt sources during FDC DMA. 
(Not all 5380 interrupts can be disabled; no idea about the IDE device or 
WD1772 FDC.)

But if that is impossible, we just have to detect the short DMA that might 
result from an undesired interrupt.

> That's actually given me another idea to pursue - if we can ensure the 
> IDE interrupt handler is always run first,

There are no interrupts from the ATA driver you're testing, right? If you 
would re-introduce them, the whole polled DMA idea is moot.

> and check whether the interrupt is still pending when the SCSI or floppy 
> interrupt handler runs and DMA has been in progress, we should be able 
> to avoid calling the respective handlers unnecessarily.
> 
> (The output of atari_irq_pending() does not directly reflect the status 
> of the MFP IRQ inputs - that would require testing bits in 
> st_mfp.par_dt_reg instead. )
> 
> > I don't think the IDE/ATA driver needs to be included. atari_scsi and 
> > ataflop would though (if both drivers need DMA transfers).
> 
> If we manage to separate interrupt sharing from DMA access locking, IDE 
> would not need to take part in the locking. I'm assuming that IDE can 
> cope with spurious interrupts and won't get confused by a SCSI 
> interrupt.
> 

The ATA driver will never have to cope with a spurious interrupt under my 
simplifying assumptions discussed earlier, so the spurious interrupt 
question seems to belong to some alternative approach...

> I think it could work both ways - polling for DMA completion or avoiding 
> to call the SCSI interrupt handler the interrupt was caused by IDE only. 
> But it's indeed time to put that to the test.
> 

... "Both ways"? I don't follow. I don't see how IDE can share the FDC and 
SCSI interrupt line without sharing the stdma.c locking scheme. What is 
the alternative approach (i.e not polled DMA) that you alude to?

-- 

[toc] | [prev] | [next] | [standalone]

#1567194

Hi Finn,

On Thu, Jan 26, 2017 at 9:47 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> The difficulty will be arranging for disabled FDC & IDE interrupt sources
> during SCSI DMA, and disabled SCSI & IDE interrupt sources during FDC DMA.
> (Not all 5380 interrupts can be disabled; no idea about the IDE device or
> WD1772 FDC.)

IDE interrupts are disabled at the device level.
Unfortunately some hard drives (e.g. Western Digital Caviar) didn't honour
the ATA disable IRQ bit, so they caused an interrupt deadlock if you probed
for them on Amiga with the IDE interrupt enabled. The problem didn't show
up on PC because they had no shared interrupts, while on A4000 the IDE
interrupt is shared with Zorro Ethernet, which was still enabled.

That was fixed (in 1995 or 1996?) by disabling the IDE interrupt at the
IRQ controller level.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1567862

On Thu, 26 Jan 2017, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Thu, Jan 26, 2017 at 9:47 AM, Finn Thain <fthain@telegraphics.com.au> 
> wrote:
> > The difficulty will be arranging for disabled FDC & IDE interrupt 
> > sources during SCSI DMA, and disabled SCSI & IDE interrupt sources 
> > during FDC DMA. (Not all 5380 interrupts can be disabled; no idea 
> > about the IDE device or WD1772 FDC.)
> 
> IDE interrupts are disabled at the device level. Unfortunately some hard 
> drives (e.g. Western Digital Caviar) didn't honour the ATA disable IRQ 
> bit, so they caused an interrupt deadlock if you probed for them on 
> Amiga with the IDE interrupt enabled. The problem didn't show up on PC 
> because they had no shared interrupts, while on A4000 the IDE interrupt 
> is shared with Zorro Ethernet, which was still enabled.
> 
> That was fixed (in 1995 or 1996?) by disabling the IDE interrupt at the 
> IRQ controller level.
> 

As I undersand it, masking these interrupts at the IRQ controller level 
won't work because these interrupt sources are all logically-OR'd together 
to generate the input that is to be polled during DMA. (And accessing the 
individual device registers is impossible during DMA!)

Anyway, the end result is that both IDE and SCSI have the potential to 
(occasionally) mess up the DMA polling during and FDC or SCSI transfer. 

For SCSI, I believe that we can detect this when it happens (by checking 
the sector count registers in the DMA chip) and return the SCSI command 
with an error result, so that the mid-layer will retry it.

I don't know how it would be handled in the case of an FDC transfer but I 
presume that a similar mechanism is available in the block layer.

-- 

> Gr{oetje,eeting}s,
> 
>                         Geert
> 

[toc] | [prev] | [next] | [standalone]

#1567890

Hi Finn,


Am 26.01.2017 um 21:47 schrieb Finn Thain:

>> I hadn't considered that. Can PDMA for Falcon SCSI coexist with 
>> interrupt-using DMA for TT SCSI in the same driver (i.e. as runtime 
>> options)?
> 
> Sure, why not?
> 
>> How much overhead and latency would polling for DMA completion add?
>>
> 
> A polled DMA transfer should be faster than PDMA (i.e. mac_scsi, g_NCR5380 
> etc). mac_scsi gets about 0.5 MBps from PDMA with sg_tablesize == 1, and I 
> hope that DMA could get twice that (notwithstanding dumb hardware design). 

DMA contends with the processor use of the data bus but that's true for
many DMA designs. Don't think Atari made any more dumb decisions (the
opaque DMA FIFO is probably the worst feature there but that could be
worked around at considerable expense by programming the DMA and the
SCSI bus transfer for one additional 512 byte block. Let's not go there.)

> This would imply CPU overhead that is half of that which mac_scsi incurs. 
> That's the best case, but I see no reason to expect worse performance than 
> PDMA gets.

But how much more overhead would we have compared to using the SCSI
interrupt to signal DMA completion?

>> atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending 
>> condition if you want to poll for it.
> 
> The difficulty will be arranging for disabled FDC & IDE interrupt sources 
> during SCSI DMA, and disabled SCSI & IDE interrupt sources during FDC DMA. 
> (Not all 5380 interrupts can be disabled; no idea about the IDE device or 
> WD1772 FDC.)
> 
> But if that is impossible, we just have to detect the short DMA that might 
> result from an undesired interrupt.

I think that's infeasible - IDE interrupts could be disabled at disk
level as Geert suggests but I don't think there is a kernel API for
other drivers to do so?

At the IRQ controller level, it's all or none due to the wired-OR design
as you pointed out in the reply to Geert's mail.

>> That's actually given me another idea to pursue - if we can ensure the 
>> IDE interrupt handler is always run first,
> 
> There are no interrupts from the ATA driver you're testing, right? If you 
> would re-introduce them, the whole polled DMA idea is moot.

The libata driver currently does disable the IDE interrupt and uses
polling, but I'd like to change that if at all possible. Sorry I didn't
make that clear.

As far as I could see during my testing, the current libata driver
coexists just fine with interrupt driven SCSI operation. I've once seen
a 'lost arbitration' message in the very first test when loading the
SCSI driver, but that's not been repeated. No problems seen otherwise.

>> If we manage to separate interrupt sharing from DMA access locking, IDE 
>> would not need to take part in the locking. I'm assuming that IDE can 
>> cope with spurious interrupts and won't get confused by a SCSI 
>> interrupt.
>>
> 
> The ATA driver will never have to cope with a spurious interrupt under my 
> simplifying assumptions discussed earlier, so the spurious interrupt 
> question seems to belong to some alternative approach...

I was assuming IDE could have interrupts reenabled in libata for that
discussion.

>> I think it could work both ways - polling for DMA completion or avoiding 
>> to call the SCSI interrupt handler the interrupt was caused by IDE only. 
>> But it's indeed time to put that to the test.
>>
> 
> ... "Both ways"? I don't follow. I don't see how IDE can share the FDC and 
> SCSI interrupt line without sharing the stdma.c locking scheme. What is 
> the alternative approach (i.e not polled DMA) that you alude to?

Since IDE does not use the ST-DMA and does not share any registers with
ST-DMA, peeking at the IDE status register in order to decide whether
the interrupt was raised by the IDE interface won't hurt the running DMA
process (regardless of whether FDC or SCSI started it). Nor will
servicing the IDE interrupt.

If at the end of the IDE interrupt processing the interrupt status is
cleared in the IDE interface, the interrupt line should go high again
before the IDE inthandler returns.

If we can ensure that the FDC/SCSI interrupt handler runs after the IDE
handler, we can then make that handler check the interrupt line status
and bail out if there's nothing to be done. (For the sake of simplicity,
this check can be done in stdma_int() since we need to retain mutual
locking of the DMA interface by SCSI and FDC anyway.) We can ensure the
IDE interrupt is called first by using a special interrupt controller to
register separate IDE and FDC/SCSI interrupts with (I've done that to
provide distinct interrupt numbers and handlers for the timer D
interrupt that's used to poll ethernet and USB interface status on the
ROM port).

That way, we can ensure IDE interrupts do not step on the ST-DMA state,
and all that remains are premature SCSI interrupts terminating DMA
transfer (which we already face anyway).

Am I missing a potential race here? Does IDE send the next request off
to the disk from inside the interrupt handler so we could see IDE
immediately raise the next interrupt?  In that case, we'd also need to
check the IDE interrupt status in the interface status register, and
bail out for another pass through the IDE/FDC/SCSI handlers until IDE is
no longer posting an interrupt...

Cheers,

	Michael

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web