[driver-discuss] solaris x86 and serial driver

Garrett D'Amore garrett_damore at tadpole.com
Fri Feb 23 11:58:38 PST 2007


This whole topic really underscores that I need to get my serial and
UART framework into shape.  I've not spent any time with it lately, but
the devices I need to support are multiport serial boards that export
multiple BARs for different serial ports.

asy.c is an ugly hackery, and I really want to clean it up as part of
this rewrite.  The end result will be that it will be able to create new
drivers that use UART-like devices, without having to do much beyond
provide some simple accessor functions to get at registers.  (There is a
little more glue in attach, but not much.)

Someone please kick me in a couple of weeks if I haven't done anything
with this yet. :-)

    -- Garrett

Dana H. Myers wrote:
> jf simon wrote:
>   
>> Dana H. Myers wrote:
>>
>>     
>>> I think it will be a little more work to please the driver; I suspect
>>> the reason asy chokes on the PCI UART is that it has many more than
>>> just the 8 registers for 16550 compatibility, and is, in fact, a
>>> multi-function device.
>>>
>>> What's the output of prtconf -v for the Exar UART device?
>>>
>>>       
>> I have found that my problem was that there wasn't any PCI IO defined
>> reg property under the PCI DUART node. There is only one BAR (BAR0) for
>> that EXAR device, and the BIOS set it as PCI MEM. I will talk to our
>> BIOS people and see if they can change this.
>>     
>
> You won't be able to change the fact that the Exar device is not
> simply a UART - it's a multi-function device.
>
>   
>> In the meantime I have patched the asy.c driver as follows
>>
>>          switch (reglist[i].pci_phys_hi & PCI_ADDR_MASK) {
>> //       case PCI_ADDR_IO:               /* I/O bus reg property */
>>          case PCI_ADDR_MEM32:            /* MEM bus reg property */
>>                         if (regnum == -1) /* use only the first one */
>>                                 regnum = i;
>>                         break;
>>
>> and the driver now attaches all right:
>>
>>            pci13a8,152, instance #2   (NOTE: the 2 first instances are ISA)
>>                 System software properties:
>>                     name='interrupt-priorities' type=int items=1
>>                         value=0000000c
>>                 Driver properties:
>>                     name='uart' type=string items=1 dev=(106,2)
>>                         value='16550A'
>>                 Hardware properties:
>>                     name='interrupts' type=int items=1
>>                         value=00000001
>>                     name='device-id' type=int items=1
>>                         value=00000152
>>                     name='vendor-id' type=int items=1
>>                         value=000013a8
>>                     name='reg' type=byte items=40
>>
>> value=00.28.03.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.10.28.03.02.00.00.00.00.00.00.00.00.00.00.00.00.00.04.00.00
>>
>>                 Interrupt Specifications:
>>                     Interrupt Priority=0xc (ipl 12), vector=0xa (10)
>>                 Device Minor Nodes:
>>                     dev=(106,2)
>>                         dev_path=/pci at 0,0/pci1022,7460 at 6/pci13a8,152 at 5:2
>>                             spectype=chr type=minor
>>                             dev_link=/dev/term/0
>>                     dev=(106,131074)
>>                         dev_path=/pci at 0,0/pci1022,7460 at 6/pci13a8,152 at 5:2,cu
>>                             spectype=chr type=minor
>>                             dev_link=/dev/cua/0
>>
>>
>>
>> But since the EXAR has two UART 16500 ports  (1st set of 16550 8 regs is
>> at off 0x000 and 2nd is at 0x200), I am trying to have solaris call the
>> driver twice, so that I can fix the offset to point to the right set of
>> 16550 registers. And thus i am hoping I will have two PCI uart instances
>> created.
>>
>> I have modified asy.conf as follows:
>>     
>
> I don't believe this approach is the correct path.  Solaris in general, and
> the asy driver specifically, is designed to treat each PCI function as an
> instance of a device. The Exar device, like other multi-port PCI serial
> devices, contains multiple instances of devices on a single PCI function.
> We have a solution for this under development, which is to create a bus
> nexus driver for the multi-port device, and this exposes a single devinfo
> node for each individual function. This avoids hacking asy to deal with
> the details of many different PCI multi-port/multi-function devices.  It
> is especially problematic when the PCI device contains both serial and
> parallel devices in the same PCI function, BTW.
>
> Keith, have you investigated the Exar serial MFIO device?
>
> Dana
> _______________________________________________
> driver-discuss mailing list
> driver-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191




More information about the driver-discuss mailing list