Date: Sat, 18 Nov 2006 18:20:30 GMT From: puc-uart@oldach.net (Helge Oldach) To: freebsd-i386@FreeBSD.org Subject: Re: i386/105616: UART PCI device just silent... Message-ID: <200611181820.kAIIKU0w087693@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/105616; it has been noted by GNATS.
From: puc-uart@oldach.net (Helge Oldach)
To: xcllnt@mac.com (Marcel Moolenaar)
Cc: FreeBSD-gnats-submit@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611181820.kAIIKU0w087693>