From owner-freebsd-i386@FreeBSD.ORG Sat Nov 18 18:40:50 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9FF9816A4A0 for ; Sat, 18 Nov 2006 18:40:50 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id C426E43D49 for ; Sat, 18 Nov 2006 18:40:29 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAIIeOsD089946 for ; Sat, 18 Nov 2006 18:40:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAIIeOIe089943; Sat, 18 Nov 2006 18:40:24 GMT (envelope-from gnats) Date: Sat, 18 Nov 2006 18:40:24 GMT Message-Id: <200611181840.kAIIeOIe089943@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Marcel Moolenaar Cc: Subject: Re: i386/105616: UART PCI device just silent... X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcel Moolenaar List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 18:40:50 -0000 The following reply was made to PR i386/105616; it has been noted by GNATS. From: Marcel Moolenaar To: Helge Oldach 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: 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