Date: Sat, 18 Nov 2006 18:40:24 GMT From: Marcel Moolenaar <xcllnt@mac.com> To: freebsd-i386@FreeBSD.org Subject: Re: i386/105616: UART PCI device just silent... Message-ID: <200611181840.kAIIeOIe089943@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: Marcel Moolenaar <xcllnt@mac.com>
To: Helge Oldach <puc-uart@oldach.net>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: i386/105616: UART PCI device just silent...
Date: Sat, 18 Nov 2006 10:31:52 -0800
On Nov 18, 2006, at 10:14 AM, Helge Oldach wrote:
> 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
As it shows, puc0 attaches to the pci0 bus. This logically represents
that puc checks the PCI ids. It also shows that uart2 and uart3 attach
to puc0. Consequently (by design), uart gets the clock information from
puc. If puc has it wrong, then uart will not work well.
>> 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 },
> },
> },
Hmmm, if puc currently has a clock of 8 times the default, then
we may have another problem. Could you check if puc got it
wrong as it is? Simply select a baudrate that's 8 times higher than
the baudrate you want. If you can communicate, then your card
does *not* have a clock that's 8 times default.
If you can't get any data transmitted or received when you select
differing baudrates (to compensate for a lock that's wrong) then
we obviously have another problem.
>> 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.
The disagreement may be important. Maybe your card has "false"
PCI ids and is recognized for something it isn't. Of course,
there may also be bugs in the source code that exhibit them-
selves this way. It would be good to find out what it is...
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611181840.kAIIeOIe089943>