Linux Post codes during runtime, possibly OT

Unless there are chips which need DELAY between accesses to DMA controller ;-) And I'm sure there are such. Also, if DMA controller is integrated on board, outb is done in different speed than ISA forwarded cycle to postcode port.

Just in case, on my VIA, 1e6 outb(0,0x80) tooks 2.07s, 1e6 outb(0,0x19) tooks 2.33s - so there is definitely difference - although in other direction than I expected. (What you can expect from this ....)
Petr Vandrovec [email protected]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Each board has its own implimentation. This is what bothers Peter and others. Embedded chip-sets don't do ISA bus-cycles. Some DMA controllers now are accessed through a PCI/ISA bridge. Some are not, etc. Even if you try to use a "spare" port existing in a Super I/O chip, this if it exists at all, will run at a different speed than the old board-mounted MFG port (where POST codes are written).

So. Here's stuff to test with. The only thing on most machines that actually uses the DMA controller is the floppy disk. I have done the following.

(1) Made a Linux floppy boot disk.
(2) Did the following RAW copy:
cp /dev/fd0 /tmp/foo
cp /tmp/foo /dev/fd0
... A script that does this ten times.

Then I booted the machine from the floppy. It works okay. From this I deduce that using the DMA scratch register doesn't hurt anything.

Here is a patch to try:

@@ -20,6 +20,9 @@
  * Went back to the 1MB limit, as some people had problems with the floppy
  * driver otherwise. It doesn't matter much for performance anyway, as most
  * floppy accesses go through the track buffer.
+ *
+ * Changed slow-down I/O port from 0x80 to 0x19.   [email protected]
+ *
  */
 #define _CROSS_64KB(a,s,vdma) \
 (!vdma && ((unsigned long)(a)/K_64 != ((unsigned long)(a) + (s) - 1) / K_64))

@@ -90,7 +93,7 @@
 4:     	movb (%2),%0
 	outb %b0,%w4
 5:	decw %w4
-	outb %0,$0x80
+	outb %0,$0x19
 	decl %1
 	incl %2
 	testl %1,%1

@@ -32,12 +32,15 @@
   *  isa_memset_io, isa_memcpy_fromio, isa_memcpy_toio added,
   *  isa_read[wl] and isa_write[wl] fixed
   *  - Arnaldo Carvalho de Melo <[email protected]>
+  *
+  *  Changed the slow-down I/O port from 0x80 to 0x19. 0x19 is a
+  *  DMA controller scratch register.  [email protected]
   */
 
 #ifdef SLOW_IO_BY_JUMPING
 #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
 #else
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+#define __SLOW_DOWN_IO "\noutb %%al,$0x19"
 #endif
 
 #ifdef REALLY_SLOW_IO

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Does anyone remember where __SLOW_DOWN_IO is needed any more?

udelay() makes sense. Modern drivers use small udelays themselves to confirm to chip specs.

Some ISA drivers appear to use outb_p "just to be on the safe side", no idea if it's appropriate or not. Some even mix outb and outb_p based on educated guesses. I know, I've written such code :-)

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

NOT! It takes almost exactly 300 ns to do port I/O on the motherboards that actually do port I/O.

Slowing down I/O is absolutely necessary any time you set an index register or a page register. For instance, to access the CMOS chip, you write an index value out port 0x70, then you read or write from port 0x71. Modern CPUs can execute instructions MUCH faster than the port index can be switched. If you don't force the CPU to wait until the hardware has actually switched the port offset, then you read/write to/from the wrong location.

The same thing occurs with DMA page registers, i.e., 64 k chunks of addresses. If takes time for hardware to switch in a new page -- a LOT more time than it takes to read/write RAM. If you don't wait, you read/write to the wrong place.

The delay must be sufficient for the hardware to have accomplished the switch. That's why writing to a hardware port is ideal. If you have fast hardware, the delay is low. If you have slow hardware, the delay is longer.

I'm not going to debate this. If you understand hardware there is nothing to debate.

udelay() on a 33 MHz '486 makes no sense at all. The delay is always much longer than the input value unless the input value exceeds 100.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Ah, I've always wondered when it's appropriate to use outb_p and when to use outb. The lack of comments in <asm-i386/io.h> kept this a mystery. Modern bus hardware doesn't need this sort of thing -- it enforces the required delays itself.

Is the list of ports for which outb_p is appropriate a small and well defined one?

Agreed, however it's not that obvious. Not all delays are to synchronise at bus rates. Sometimes the delay is because some _other_ component on a board, not directly connected to the bus, needs a short delay. E.g. a chip that can only be clocked at max. 1MHz. The driver author uses outb_p because he thinks that limits the rate to 0.5MHz, and there is no other way to get that sort of data rate, but no it limits the rate to 3MHz on your board. Ah well.

If it was really as simple as matching the bus rate, there would be no need for REALLY_SLOW_IO on some machines would there? (Are REALLY_SLOW_IO and SLOW_IO_BY_JUMPING ever used?)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/