Linux Kernel Mailing List wrote:
> ChangeSet 1.1374, 2003/07/09 13:40:53-07:00, [email protected]
>
> Fix IDE initialization when we don't probe for interrupts.
>
> The driver obviously cannot rely on the interrupt handler
> when it is probing for interrupts, so the identify code is
> written to not use interrupts and the probing code will
> disable the interrupt after having figured out which one it
> is.
>
> The non-probe code should do the same, otherwise confusion
> happens.
> diff -Nru a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
> --- a/drivers/ide/ide-probe.c Wed Jul 9 14:10:54 2003
> +++ b/drivers/ide/ide-probe.c Wed Jul 9 14:10:54 2003
> @@ -390,6 +390,14 @@
> cookie = probe_irq_on();
> /* enable device irq */
> hwif->OUTB(drive->ctl, IDE_CONTROL_REG);
> + } else {
> + /*
> + * Disable device irq if we don't need to
> + * probe for it. Otherwise we'll get spurious
> + * interrupts during the identify-phase that
> + * the irq handler isn't expecting.
> + */
> + hwif->OUTB(drive->ctl|2, IDE_CONTROL_REG);
Yeah, my driver does probing with interrupts disabled, too.
I'm curious where interrupts are re-enabled, though?
Jeff
On Wed, 9 Jul 2003, Jeff Garzik wrote:
>
> I'm curious where interrupts are re-enabled, though?
The low-level drivers seem to do it at every IO. Don't ask me why. But it
gets done automatically by any code that does
hwif->OUTB(drive->ctl, IDE_CONTROL_REG);
which is pretty common (just grep for "IDE_CONTROL_REG" and you'll see
what I mean).
I note that I should have made this "disable irq" be dependent on
IDE_CONTROL_REG being non-zero. Although I don't see when that register
_can_ be zero, it would be a major bummer not to have access to the
control register.
(Obviously it must be zero for some architecture, though, or those
conditionals woulnd't make sense. Alan? Bartlomiej? What kind of sick
pseudo-IDE controller doesn't have a control register?).
Linus
On Wed, 9 Jul 2003, Linus Torvalds wrote:
> On Wed, 9 Jul 2003, Jeff Garzik wrote:
> >
> > I'm curious where interrupts are re-enabled, though?
>
> The low-level drivers seem to do it at every IO. Don't ask me why. But it
> gets done automatically by any code that does
>
> hwif->OUTB(drive->ctl, IDE_CONTROL_REG);
>
> which is pretty common (just grep for "IDE_CONTROL_REG" and you'll see
> what I mean).
>
> I note that I should have made this "disable irq" be dependent on
> IDE_CONTROL_REG being non-zero. Although I don't see when that register
> _can_ be zero, it would be a major bummer not to have access to the
> control register.
>
> (Obviously it must be zero for some architecture, though, or those
> conditionals woulnd't make sense. Alan? Bartlomiej? What kind of sick
> pseudo-IDE controller doesn't have a control register?).
Amiga X-Surf and Amiga Gayle with IDE doubler...
--
Bartlomiej
> Linus
Linus Torvalds wrote:
Thanks.
> (Obviously it must be zero for some architecture, though, or those
> conditionals woulnd't make sense. Alan? Bartlomiej? What kind of sick
> pseudo-IDE controller doesn't have a control register?).
I asked Andre or Russell King or somebody this a while ago... IIRC it is
some obscure ATARI IDE controller, or somesuch.
Jeff
On Mer, 2003-07-09 at 23:08, Jeff Garzik wrote:
> > + * Disable device irq if we don't need to
> > + * probe for it. Otherwise we'll get spurious
> > + * interrupts during the identify-phase that
> > + * the irq handler isn't expecting.
> > + */
> > + hwif->OUTB(drive->ctl|2, IDE_CONTROL_REG);
>
>
> Yeah, my driver does probing with interrupts disabled, too.
> I'm curious where interrupts are re-enabled, though?
In the command write. BTW note that there are a few devices
out there that dont honour the nIEN stuff.
IDE is such fun
On 10 Jul 2003, Alan Cox wrote:
> On Mer, 2003-07-09 at 23:08, Jeff Garzik wrote:
> > > + * Disable device irq if we don't need to
> > > + * probe for it. Otherwise we'll get spurious
> > > + * interrupts during the identify-phase that
> > > + * the irq handler isn't expecting.
> > > + */
> > > + hwif->OUTB(drive->ctl|2, IDE_CONTROL_REG);
> >
> >
> > Yeah, my driver does probing with interrupts disabled, too.
> > I'm curious where interrupts are re-enabled, though?
>
> In the command write. BTW note that there are a few devices
> out there that dont honour the nIEN stuff.
Indeed. E.g. some old Western Digital Caviars.
I remember these giving me a bad time on Amiga. Apparently the problem didn't
show up on PC, since (in those days) IDE didn't share its interrupt with some
other device, unlike on Amiga.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Wed, 9 Jul 2003, Linus Torvalds wrote:
> On Wed, 9 Jul 2003, Jeff Garzik wrote:
> > I'm curious where interrupts are re-enabled, though?
>
> The low-level drivers seem to do it at every IO. Don't ask me why. But it
> gets done automatically by any code that does
>
> hwif->OUTB(drive->ctl, IDE_CONTROL_REG);
>
> which is pretty common (just grep for "IDE_CONTROL_REG" and you'll see
> what I mean).
>
> I note that I should have made this "disable irq" be dependent on
> IDE_CONTROL_REG being non-zero. Although I don't see when that register
> _can_ be zero, it would be a major bummer not to have access to the
> control register.
>
> (Obviously it must be zero for some architecture, though, or those
> conditionals woulnd't make sense. Alan? Bartlomiej? What kind of sick
> pseudo-IDE controller doesn't have a control register?).
IDE can live without the control register (what do you _really_ need it for?).
Hence some hardware doesn't provide it, by leaving out the second bank of 8 IDE
registers.
Another trick is the `IDE doubler' for Amiga (but I guess you can make it work
on any IDE interface): with a few diodes you can map the second bank of 8 IDE
registers to a second IDE chain, doubling the number of devices you can
attach.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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