Steinke, Dave wrote:
>> -----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
>
>   
Having read this, please disregard my last message...
Sorry,
thanks,
max

_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss

Reply via email to