X-Authentication-Warning: ulab-17.ms.mff.cuni.cz: prak3264 owned process doing -bs Date: Wed, 5 Nov 1997 00:07:05 +0100 (MET) From: Patrik Rak X-Sender: prak3264@ulab-17.ms.mff.cuni.cz To: Jesper Skov , linux-m68k@lists.linux-m68k.org Subject: L68K: Fastlane patches Sender: owner-linux-m68k@phil.uni-sb.de Hi! Here are my patches to the 2.1.61 kernel concerning esp.c and fastlane.c in drivers/scsi/. Anybody interested is welcome to check out my comments and express his opion... Jesper, could you please build two kernels for me, one with this patch as is and one with the "check for both DMA_IACT and STAT_INTR" as noted in the comment? Thanks in advance... (As you can see, I reverted to using dma_irq_exit() again...). Patrik --- linux-2.1.61/drivers/scsi/fastlane.c 1997/11/04 22:27:41 1.1 +++ linux-2.1.61/drivers/scsi/fastlane.c 1997/11/04 23:58:53 @@ -43,8 +43,12 @@ #include +/* Keep it enabled for now -- patrik */ + +#if 0 /* Let this defined unless you really need to enable DMA IRQ one day */ #define NODMAIRQ +#endif static int dma_bytes_sent(struct NCR_ESP *esp, int fifo_count); static int dma_can_transfer(struct NCR_ESP *esp, Scsi_Cmnd *sp); @@ -55,6 +59,7 @@ static void dma_ints_off(struct NCR_ESP *esp); static void dma_ints_on(struct NCR_ESP *esp); static int dma_irq_p(struct NCR_ESP *esp); +static void dma_irq_exit(struct NCR_ESP *esp); static void dma_led_off(struct NCR_ESP *esp); static void dma_led_on(struct NCR_ESP *esp); static int dma_ports_p(struct NCR_ESP *esp); @@ -113,7 +118,7 @@ esp->dma_drain = 0; esp->dma_invalidate = 0; esp->dma_irq_entry = 0; - esp->dma_irq_exit = 0; + esp->dma_irq_exit = &dma_irq_exit; esp->dma_led_on = &dma_led_on; esp->dma_led_off = &dma_led_off; esp->dma_poll = 0; @@ -267,24 +272,41 @@ *t = 0 ; } - static void dma_ints_off(struct NCR_ESP *esp) { + /* Should this perhaps disable the FASTLANE_DMA_EDI|ESI bits instead/also? + * We could stop using the dma_irq_exit() call then... + * -- patrik + */ disable_irq(esp->irq); } static void dma_ints_on(struct NCR_ESP *esp) { + /* See above */ enable_irq(esp->irq); } +static void dma_irq_exit(struct NCR_ESP *esp) +{ + struct fastlane_dma_registers *dregs = + (struct fastlane_dma_registers *) (esp->dregs); + + /* XXX - I think it is necessary to strobe this register otherwise + * we do not receive any further interrupts since the interrupt + * remains pending, causing infinite loop. Is it right? -- patrik + */ + + dregs->ctrl_reg = ctrl_data & ~(FASTLANE_DMA_EDI|FASTLANE_DMA_ESI); + dregs->ctrl_reg = ctrl_data; +} + static int dma_irq_p(struct NCR_ESP *esp) { struct fastlane_dma_registers *dregs = (struct fastlane_dma_registers *) (esp->dregs); #if 0 unsigned char dma_status; - int r = 0; dma_status = dregs->cond_reg; @@ -298,18 +320,33 @@ #endif (!(dma_status & FASTLANE_DMA_MINT)) && ((((struct ESP_regs *) (esp->eregs))->esp_status) & ESP_STAT_INTR)) - r = 1; + return 1 ; - dregs->ctrl_reg = (ctrl_data & ~(FASTLANE_DMA_EDI|FASTLANE_DMA_ESI) ); - dregs->ctrl_reg = ctrl_data; - - return r; + return 0 ; #else - int r; - r = (((struct ESP_regs *) (esp->eregs))->esp_status) & ESP_STAT_INTR; - dregs->ctrl_reg = ctrl_data & ~(FASTLANE_DMA_EDI|FASTLANE_DMA_ESI); - dregs->ctrl_reg = ctrl_data; - return r; +#endif + /* Just report the status of the esp interrupt bit as other + * amiga esp drivers do. + * + * This is really weird, since the sparc version does report + * whether or not the DMA interrupt is pending, not the esp one + * (as the name dma_irq_p suggests). Should this function perhaps + * do something like + * + * struct fastlane_dma_registers *dregs = + * (struct fastlane_dma_registers *) (esp->dregs); + * return ! (dregs->cond_reg & FASTLANE_DMA_IACT ) ; + * + * instead (DMA interrupts must be enabled then, of course) ? + * Or should it perhaps check for both? I assume the case above + * might be incorrect, since it checks just for the esp only interrupts. + * -- patrik + */ + return +#if 0 + (!(dregs->cond_reg & FASTLANE_DMA_IACT )) && +#endif + (((struct ESP_regs *) (esp->eregs))->esp_status) & ESP_STAT_INTR; #endif } --- linux-2.1.61/drivers/scsi/esp.c 1997/11/04 22:26:27 1.1 +++ linux-2.1.61/drivers/scsi/esp.c 1997/11/04 23:53:08 @@ -44,20 +44,6 @@ #include #include -/* This is really ugly (Jesper?) -Patrik */ - -#ifndef DMA_IRQ_P -#define DMA_IRQ_P(regs) (esp->dma_irq_p(esp)) -#endif /* DMA_IRQ_P */ - -#ifndef DMA_INTSON -#define DMA_INTSON(regs) (esp->dma_ints_on(esp)) -#endif /* DMA_INTSON */ - -#ifndef DMA_INTSOFF -#define DMA_INTSOFF(regs) (esp->dma_ints_off(esp)) -#endif /* DMA_INTSOFF */ - /* Command phase enumeration. */ enum { not_issued = 0x00, /* Still in the issue_SC queue. */ @@ -1422,6 +1408,10 @@ } } + /* Don't forget to enable interrupts when returning -- patrik */ + if(don) + esp->dma_ints_on(esp); + /* Yuck, the command to abort is disconnected, it is not * worth trying to abort it now if something else is live * on the bus at this time. So, we let the SCSI code wait @@ -3654,6 +3644,10 @@ repeat: again = 0; for_each_esp(esp) { + /* Jesper, I have not found this anywhere. Is the one below correct + * or is some masking necessary too? -- patrik + */ +#define INO_TO_PIL(esp) ((esp)->irq) if(INO_TO_PIL(esp) == irq) { if(esp->dma_irq_p(esp)) { again = 1; From pstehlik@zln.cz Wed Nov 5 13:42:13 1997 Date: Wed, 05 Nov 1997 13:41:08 +0100 From: Petr Stehlik Organization: Sophics To: Roman Hodek Cc: linux-m68k@lists.linux-m68k.org, dmlittle@compuserve.com Subject: Re: [stehlik@cas3.zlin.vutbr.cz: Re: L68K: Linux-2.1.61] X-Priority: 3 (Normal) References: <9711051217.AA09309@faui21.informatik.uni-erlangen.de> Roman Hodek wrote: > Hi Doug & Petr! Hi Roman & Doug :-) > The only point that differs between Doug and me is the transparent > translation: He *enables* it for the whole address space, whereas the > original Linux code leaves them alone, assuming that the TOS reset > code will initialize them. (At least TOS 3.01 on my TT does this...) > Maybe the AB40 TOS simply doesn't init the transp transl regs, and > this is the cause of the trouble. Roman, a very very important point: Afterburner040 is a card with just MC68040 and FastRAM slots. After boot-up it has to execute old TOS 4.04, which does know ANYTHING about 68040. Actually it contains a lot of 68030 only instructions (MMU, caches) and it's a mirracle the 68040 survives the illegal instructions and boots at all! So, please don't assume AB40 TOS will initialize transp transl regs. Also, I am not sure about the transparent translation, but maybe that enabling it for whole address space is important for accessing hardware registers at 0xFFFFabcd, you know. Petr