[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