Hi All,
I am new to driver and I need your help for understand about how bus driver and device driver transfer data.I will need to make driver for PCI card with multi-serial so I will ask question related to this specific type but any suggestion or other guide to understand about bus and device driver communication will be also be welcomed. I image the card will have 1 interrupt shared by, let say 8 serial ports, and all UART registers are separated. I have read in OSR and it seems the structure should be :
- Bus driver talk PCI downward and Serial upward
- Serial drivers for each port.
When an interrupt came, i will need to check all registers of all 8 serial ports to verify which Serial generate interrupt. In here I have a questions that if it is possible when i checked, two serial can be marked as both generated interrupt ? If yes i think i will need to keep track of which Serial in 8 ports generated interrupt. And then in DPC, i need to transfer data from bus to serial driver or is there another way to transfer it ? In here i am pretty clueless. Is there any sample or guide i can read about this part ?
Thank you all,
On Jan 11, 2017, at 12:23 AM, xxxxx@yahoo.com.vn wrote:
I am new to driver and I need your help for understand about how bus driver and device driver transfer data.I will need to make driver for PCI card with multi-serial so I will ask question related to this specific type but any suggestion or other guide to understand about bus and device driver communication will be also be welcomed. I image the card will have 1 interrupt shared by, let say 8 serial ports, and all UART registers are separated. I have read in OSR and it seems the structure should be :
- Bus driver talk PCI downward and Serial upward
- Serial drivers for each port.
I would expect the bus driver to do little more than arbitrate access to the shared resources. I would expect it to hand control of the UART registers to the individual serial port drivers. So, you’d have some private scheme where the serial drivers register themselves with the bus driver when they are able to handle interrupts. Then, when the bus driver gets an interrupt, it sees which ports have fired, and notifies the responsible port driver(s). The drivers can then operate autonomously.
When an interrupt came, i will need to check all registers of all 8 serial ports to verify which Serial generate interrupt. In here I have a questions that if it is possible when i checked, two serial can be marked as both generated interrupt ?
Only you can answer that question. How does your hardware behave? I would assume that it’s easily possible for several ports to demand attention before you’re able to get around to servicing them.
If yes i think i will need to keep track of which Serial in 8 ports generated interrupt.
You would have to do that anyway.
And then in DPC, i need to transfer data from bus to serial driver or is there another way to transfer it ? In here i am pretty clueless. Is there any sample or guide i can read about this part ?
I wouldn’t do the transfer in the bus driver. Have the bus driver notify the port driver, and let each serial driver think it is the only one in the world. The only difference between this and a normal serial port is the arbitrated access to the shared interrupt.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The bus driver will partition the registers, and probably has to hold the
interrupt service routine. Assuming you are using an Altera design (I’ve
seen this way too often since they claim a windows compatible design which
requires a lot of software work), you will need:
To break out the registers for the specific com port
Provide an ISR in the bus driver that calls a callback routine that
the given com ports function driver registers
Support in the bus driver a routine to emulate
WdfInterruptSynchronize
The simplest way to do this is to have a device interface that the function
driver can query to the bus drivers PDO to get the resources. Don’t try to
use the regular PnP model, it was explained years ago on this list how that
can cause interesting bugs.
You will also have a bunch of changes you will need to do to the serial port
sample to make this all work. I’ve done this a number of times for clients
to the point I now just sell them a license for the code. The first time
will take you a few months to get stable, unless you are really fast.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com.vn
Sent: Wednesday, January 11, 2017 3:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Data communication between Bus driver and device driver
Hi All,
I am new to driver and I need your help for understand about how bus driver
and device driver transfer data.I will need to make driver for PCI card with
multi-serial so I will ask question related to this specific type but any
suggestion or other guide to understand about bus and device driver
communication will be also be welcomed. I image the card will have 1
interrupt shared by, let say 8 serial ports, and all UART registers are
separated. I have read in OSR and it seems the structure should be :
- Bus driver talk PCI downward and Serial upward
- Serial drivers for each port.
When an interrupt came, i will need to check all registers of all 8 serial
ports to verify which Serial generate interrupt. In here I have a questions
that if it is possible when i checked, two serial can be marked as both
generated interrupt ? If yes i think i will need to keep track of which
Serial in 8 ports generated interrupt. And then in DPC, i need to transfer
data from bus to serial driver or is there another way to transfer it ? In
here i am pretty clueless. Is there any sample or guide i can read about
this part ?
Thank you all,
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>