What is the difference between using IOCTL to write/read IO ports vs. modifying IOPM and using _INP/OUTP_ ??
in [Device Drivers]
|
Prev: Problem with WinUsb_ReadPipe
Next: What is the difference between using IOCTL to write/read IO ports vs. modifying IOPM and using _INP/OUTP_ ??
From: Maxim S. Shatskih on 1 Sep 2009 18:47 > have said. But why is it so slow when I do that? Is there THAT much > overhead? What is the METHOD_xxx code of the IOCTL? Also note that IO ports are not designed to be fast and sustain major data flows. Major data flows are all via DMA these days. IO ports are a) declared obsolete by MS since around 1999 b) only used for control/status registers. Also, you can use KERNRATE or Intel vTune to find the bottleneck. Probably this will be the handle validation in NtDeviceIoControlFile or such. Also, if you want more speed accessing IO ports, at least use REP INSW and REP OUTSW opcodes, which are READ/WRITE_PORT_BUFFER_USHORT in the kernel. The IOCTL should also be "write port X with data buffer D of length L". This is actually the first thing to start with. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Maxim S. Shatskih on 1 Sep 2009 18:51 > clocks in the data at about 40MHz. Sending in multiple DWORD in the > same PCI transaction would be pointless as our hardware below can not > clock in that fast. It will not be pointless, since it saves lots of host time which would otherwise be spent for initial/termination phases of the PCI transaction. Surely you will also need some FIFO in the PCI card to match the different clock rates, but this is the good way to go. Also, the external hardware can be designed as SCSI "processor" class and attached to the old aic78xx or similar controller via old SCSI-3 external cable. For 40MHz, this is OK. aic78xx, which was a high-end storage controller around 1993, is by far smarter then a stupid device with a single IO port at 0x300. Also consider USB. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Maxim S. Shatskih on 1 Sep 2009 19:34 >correctly. So basically, you're saying that my software now is >bypassing the I/O manager and the HAL? Surely. >Or is it communicating >straight to the HAL? >based on this NT archicture model: http://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg HAL is conceptually the "driver for timers, interrupt controllers and machine reboot hardware". The driver for the things which are not essential part of the CPU, but is very close to it. Since x64 Win6+ have 1 and only 1 HAL, the concept is dead. I will not be surprised if MS will merge the HAL to the kernel itself someday :-) >commands in Visual C (dll) are actually macros for the assembly INP/ >OUTP commands in assembly. Yes. >part of the hardware layer, takes these assembly instructions and >sends it to either the HAL or the processor? Is it the I/O Manager or >the HAL itself? The CPU itself executes them. The OS does not know. >which layer is receiving these instructions No software layer at all. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Maxim S. Shatskih on 1 Sep 2009 19:41 >sends it to either the HAL or the processor? Is it the I/O Manager or >the HAL itself? IN/OUT are implemented in the hardware of the CPU, OS does not knows on them at all. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Alberto on 2 Sep 2009 11:55
Are you sure you don't want to memory map that BAR region ? It might save you gobs of aggravation. Alberto. On Sep 1, 4:44 pm, L337 <vern.engineer...(a)gmail.com> wrote: > On Sep 1, 1:12 pm, Kalle Olavi Niemitalo <k...(a)iki.fi> wrote: > > > L337 <vern.engineer...(a)gmail.com> writes: > > > -the x86 processors (intel-based) have built-in routines to handle IN/ > > > OUT instructions on a "processor-level" command. So does this mean, > > > there is a kernel driver, maybe NTIO.DLL or something that passes the > > > IN/OUT command straight to the processor level, thereby bypassing the > > > entire IO Manager? > > > After UserPort has changed the I/O permission map, the processor > > does not trap to the kernel at all when it executes the in and > > out instructions in your program. It thus avoids not only the > > overhead of the I/O manager but the rest of the kernel as well. > > Interesting, someone told this but I didn't understand it quite > correctly. So basically, you're saying that my software now is > bypassing the I/O manager and the HAL? Or is it communicating > straight to the HAL? > based on this NT archicture model:http://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg > > The part that I do not understand quite clearly is that the INP/OUTP > commands in Visual C (dll) are actually macros for the assembly INP/ > OUTP commands in assembly. So I read that these are actual x86 intel > assembly "processor-level" instructions. But what i like to > understand is, after when I send these commands via software, which > part of the hardware layer, takes these assembly instructions and > sends it to either the HAL or the processor? Is it the I/O Manager or > the HAL itself? I just don't understand in the NT model, that after > I have changed the IOPM, and while using IN/OUT commands via DLL, > which layer is receiving these instructions and passing it down to the > HAL? > > Thanks. |