i386/105616: UART PCI device just silent...

[Helge Oldach]

The following reply was made to PR i386/105616; it has been noted by GNATS.

From: puc-uart at oldach.net (Helge Oldach)
To: xcllnt at mac.com (Marcel Moolenaar)
Cc: FreeBSD-gnats-submit at FreeBSD.org
Subject: Re: i386/105616: UART PCI device just silent...
Date: Sat, 18 Nov 2006 19:14:22 +0100 (CET)

 Hi Marcel,
 
 thanks for your response.
 
 Marcel Moolenaar:
 >On Nov 16, 2006, at 12:46 PM, Helge Oldach wrote:
 >
 >> --- sys/dev/uart/uart_bus_pci.c.ctm	Wed Aug  2 16:24:19 2006
 >> +++ sys/dev/uart/uart_bus_pci.c	Wed Nov 15 10:18:56 2006
 >> @@ -101,6 +101,8 @@
 >>  	8 * DEFAULT_RCLK },
 >>  { 0x1409, 0x7168, 0x1409, 0x4028, "Timedia Technology Serial  
 >> Port", 0x10,
 >>  	8 * DEFAULT_RCLK },
 >> +{ 0x1409, 0x7168, 0x1409, 0x4037, "Timedia Technology Serial  
 >> Port", 0x10,
 >> +	8 * DEFAULT_RCLK },
 >>  { 0x1409, 0x7168, 0x1409, 0x5025, "Timedia Technology Serial  
 >> Port", 0x10,
 >>  	8 * DEFAULT_RCLK },
 >>  { 0x1409, 0x7168, 0x1409, 0x5027, "Timedia Technology Serial  
 >> Port", 0x10,
 >>
 >
 >The patch is not right. The PCI device you talk about is a *dual* serial
 >I/O card. As such, puc(4) needs to attach to it, not uart(4). Adding the
 >PCI ids to uart(4) will only cause a conflict, not to mention that if
 >uart(4) attaches, it only attaches to the first.
 
 Am I mistaken or, is it actually the case that puc(4) attaches to the
 board and not uart(4)?
 
 puc0: <Dolphin Peripherals 4036> port 0x2000-0x201f irq 10 at device 14.0 on pci0
 uart2: <16550 or compatible> on puc0
 uart2: fast interrupt
 uart3: <16550 or compatible> on puc0
 uart3: fast interrupt
 
 >However, the patch shows that the clock on these cards is 8 times the
 >default clock.
 
 That was just a rough guess, copied from seemingly similar cards.
 
 So I understand no specific puc(4) attribution needs to be made for this
 card. It is already properly recognized, albeit with misleading text in
 pucdata.c:
 
         {   "Dolphin Peripherals 4036",
             {   0x1409, 0x7168, 0,      0       },
             {   0xffff, 0xffff, 0,      0       },
             {
                 { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ * 8 },
                 { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ * 8 },
             },
         },
 
 >I think that is why puc(4)+uart(4) doesn't work. If
 >you select a baudrate that 8 times lower than what you know the baudrate
 >should be, then you should be able to transmit and receive data. If
 >that's the case, then puc(4) needs to be fixed to have the correct
 >clock value for these boards.
 
 I will give this a try to see if it helps.
 
 Note that also pucdata.c assumes 8 times baudrate.
 
 >Note also that I have not heard of uart(4) being wrong in classifying
 >the type as 16550, 1660 or otherwise.
 
 Fine with me. I am not claiming the source mentioned is correct. I just
 say there appears to be some disagreement.
 
 Thanks for your response anyway.
 
 Regards,
 Helge