> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 25, 2007 7:54 PM > To: Garrett D'Amore > Cc: Steinke, Dave; [email protected] > Subject: Re: [driver-discuss] FW: How to hardware properties get set on > x86? > > Garrett D'Amore wrote: > > Yech! ISA devices are "special". You have to put properties in the > > .conf files for the driver, indicating the port ranges used. > > > > Please understand, ISA are not self-identifying devices. One reason I > > utterly despise them.... is there some compelling reason your device > > isn't accessible in PCI space? > > > > -- Garrett > > > > Steinke, Dave wrote: > >> Hi, > >> Sorry for the newbie driver question, but I've searched all the docs > and can't seem to get my question answered.... > >> Any help you can offer would be greatly appreciated! > >> > >> I'm porting the "asy" async driver to the board my company makes. > >> Our board has 6 UARTS, instead of the usual 2 or 4. > >> The first two UARTS are at the normal IO addresses of 0x3f8 and 0x2f8. > >> The remaining four UARTs are at 0x3e8, 0x2e8, 0x3e0 and 0x2e0. > >> > >> I can successfully attach the driver to the first two UARTS and the > properties (via prtconf -v) look correct (see below). > >> I cannot get the other 4 UARTs to attach. > >> The properties that are passed back from the "kernel" says the 3rd UART > is at IO address 0xFFFF, which is obviously wrong. > >> > >> Our BIOS guy tells me that BIOS creates two tables in the ACPI > configuration data for the UARTS. > >> I've checked his data, it looks good. > As Dan has asked, we'd like to see the relevant ACPI table(s) which > enumerates these UARTs. > >> > >> Question 1: > >> How does the ACPI table get converted into "properties" that are > returned to the driver when the driver reads them via this strip of code: > The ACPI table(s) are scanned early during boot to create devinfo nodes; > nothing > special is done for UARTs - devinfo nodes are created using information > gleaned > from the ACPI tables. Have a look at > usr/src/uts/intel/io/acpica/acpi_enum.c for > starters. > >> > >> How can I get the driver to attach my other 4 instances? > >> > The best thing we can do is make sure that the ACPI tables are correct > and that Solaris is correctly interpreting them. > >> Following is dump from prtconf: > >> > >> isa, instance #0 > >> Hardware properties: > >> name='bus-type' type=string items=1 > >> value='isa' > >> name='device_type' type=string items=1 > >> value='isa' > >> asy, instance #0 <<<<<<<< First Good > Instance > >> Driver properties: > >> name='uart' type=string items=1 dev=(106,0) > >> value='16550A' > >> Hardware properties: > >> name='interrupts' type=int items=1 > >> value=00000004 > >> name='reg' type=int items=3 > >> value=00000001.000003f8.00000008 > >> name='acpi-namespace' type=string items=1 > >> value='\_SB_.PCI0.LPC_.COM1' > >> name='model' type=string items=1 > >> value='16550A-compatible COM port' > >> name='compatible' type=string items=1 > >> value='PNP0501' > >> Register Specifications: > >> Bus Type=0x1, Address=0x3f8, Size=0x8 > >> Interrupt Specifications: > >> Interrupt Priority=0x5 (ipl 5), vector=0x4 (4) > >> Device Minor Nodes: > >> dev=(106,0) > >> dev_path=/isa/[EMAIL PROTECTED],3f8:a > >> spectype=chr type=minor > >> dev_link=/dev/tty00 > >> dev_link=/dev/ttya > >> dev_link=/dev/term/a > >> dev=(106,131072) > >> dev_path=/isa/[EMAIL PROTECTED],3f8:a,cu > >> spectype=chr type=minor > >> dev_link=/dev/cua/a > >> dev_link=/dev/cua0 > >> dev_link=/dev/ttyd0 > >> asy, instance #1 <<<<<<<<<<< second good instance > >> Driver properties: > >> name='uart' type=string items=1 dev=(106,1) > >> value='16550A' > >> Hardware properties: > >> name='interrupts' type=int items=1 > >> value=00000003 > >> name='reg' type=int items=3 > >> value=00000001.000002f8.00000008 > >> name='acpi-namespace' type=string items=1 > >> value='\_SB_.PCI0.LPC_.COM2' > >> name='model' type=string items=1 > >> value='16550A-compatible COM port' > >> name='compatible' type=string items=1 > >> value='PNP0501' > >> Register Specifications: > >> Bus Type=0x1, Address=0x2f8, Size=0x8 > >> Interrupt Specifications: > >> Interrupt Priority=0x5 (ipl 5), vector=0x3 (3) > >> Device Minor Nodes: > >> dev=(106,1) > >> dev_path=/isa/[EMAIL PROTECTED],2f8:b > >> spectype=chr type=minor > >> dev_link=/dev/tty01 > >> dev_link=/dev/ttyb > >> dev_link=/dev/term/b > >> dev=(106,131073) > >> dev_path=/isa/[EMAIL PROTECTED],2f8:b,cu > >> spectype=chr type=minor > >> dev_link=/dev/cua/b > >> dev_link=/dev/cua1 > >> dev_link=/dev/ttyd1 > >> ... > >> asy (driver not attached) <<<<<<<<<<<<< bogus instances > follow > >> Hardware properties: > >> name='reg' type=int items=3 > >> value=00000001.0000ffff.00000008 <<<<<< Note > the bogus IO address FFFF > >> name='acpi-namespace' type=string items=1 > >> value='\_SB_.PCI0.LPC_.UAR1' > >> name='model' type=string items=1 > >> value='16550A-compatible COM port' > >> name='compatible' type=string items=1 > >> value='PNP0501' > >> asy (driver not attached) <<<<<<<<< Also bogus > >> Hardware properties: > >> name='reg' type=int items=3 > >> value=00000001.0000ffff.00000008 > >> name='acpi-namespace' type=string items=1 > >> value='\_SB_.PCI0.LPC_.UAR2' > >> name='model' type=string items=1 > >> value='16550A-compatible COM port' > >> name='compatible' type=string items=1 > >> value='PNP0501' > >> asy (driver not attached) <<<<<<<<< Also bogus > >> Hardware properties: > >> name='reg' type=int items=3 > >> value=00000001.0000ffff.00000008 > >> name='acpi-namespace' type=string items=1 > >> value='\_SB_.PCI0.LPC_.UAR3' > >> name='model' type=string items=1 > >> value='16550A-compatible COM port' > >> name='compatible' type=string items=1 > >> value='PNP0501' > >> asy (driver not attached) <<<<<<<<< Also bogus > >> Hardware properties: > >> name='reg' type=int items=3 > >> value=00000001.0000ffff.00000008 > >> name='acpi-namespace' type=string items=1 > >> value='\_SB_.PCI0.LPC_.UAR4' > >> name='model' type=string items=1 > >> value='16550A-compatible COM port' > >> name='compatible' type=string items=1 > >> value='PNP0501' > >> > > Based on this snippet, it's clear that acpi_enum.c found > > \_SB.PCI0.LPC_.UAR1 > \_SB.PCI0.LPC_.UAR2 > \_SB.PCI0.LPC_.UAR3 > \_SB.PCI0.LPC_.UAR4 > > but, in each case, evaluated the current resource assignment to 0xFFFF. > We really > need to see the ACPI tables for this machine. > > Dana
Sorry if I insulted any of the Sun people in my comments about the "bugs". I must have misread the code... Our in-house BIOS guy made the changes to add the extra serial ports to the ACPI tables. The actual configuration is: - 2 Ports on the Intel 6300 ICH - 4 ports on a Super I/O chip hanging off the LPC bus attached to the ICH The BIOS guy created two tables, one for each device. He believes they were done correctly, and we all know that people sometimes make mistakes. I have the source code for the ACPI tables, but that may not help, if it is getting converted incorrectly. If you want to see it, please let me know, I could send it to you out-of-band. It's very possible an error in our BIOS is causing ACPI to fail to properly enumerate the devices. As we can see by the output of prtconf, there is some information from ACPI about the missing 4 devices, but the 'reg' values are wrong. I'd prefer to do things correctly without hacking the driver.conf file. I'd be very happy to dump the ACPI tables from the live machine, if I knew how to. Would someone be so kind as to give me a pointer to how to do this? Dave Steinke _______________________________________________________________________ This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this email and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail. _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
