From owner-freebsd-bugs@FreeBSD.ORG Mon Nov 9 21:50:02 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7CF1065692 for ; Mon, 9 Nov 2009 21:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 793E58FC1B for ; Mon, 9 Nov 2009 21:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nA9Lo2dx037350 for ; Mon, 9 Nov 2009 21:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nA9Lo2M9037349; Mon, 9 Nov 2009 21:50:02 GMT (envelope-from gnats) Date: Mon, 9 Nov 2009 21:50:02 GMT Message-Id: <200911092150.nA9Lo2M9037349@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: David Wood Cc: Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wood List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 21:50:02 -0000 The following reply was made to PR kern/134878; it has been noted by GNATS. From: David Wood To: blortz@pacbell.net Cc: bug-followup@FreeBSD.org Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips Date: Mon, 9 Nov 2009 21:44:57 +0000 Hi Bill, Thanks for your follow-up for my patch. In message <01b201ca60a6$0f633d00$2e29b700$@net>, Bill Lortz writes >I have the FreeTech PCI-e mini card with 1 serial and 1 parallel port (part >#PEX1S1PMINI) that claims to use the Oxford OXPCIe952 chip. The computer >is a FITPC2 (Intel Atom-based computer). From the device ID you give, it's definitely OXPCIe952 based. >After applying the puc patch, enabling puc in the kernel and re-compiling, >the card is recognized, but no driver was assigned. > >I ran a pciconf -lv to list the pci devices and found the chip id's didn't >match anything in the patched driver. Correct; the current version of the patch only attempts to support the OXPCIe952 when it's configured as two serial ports. >So, I changed an entry in the patched code for the 952 chip from "0x1415, >0x15d" to "0x1415, 0xc11b" so that it matched the output from the pciconf. >Since I was only interested in the serial function, I didn't try to patch >for the parallel port function. After recompiling the kernel it worked >and assigned a device driver to the UART. Great! I suspect that you'd rather the card used the OXPCIe952 to offer two serial ports rather than one serial and one parallel port. At the moment, mini PCI Express cards are not that common and I couldn't find one that had two serial ports. >I wasn't comfortable in my patch to add a new table entry, so that is why I >changed an existing entry. I suspect the proper patch would be to add a >new table entry. I've included the output from my "pciconf" that shows >the pci card and chip ids for both the serial and parallel ports. Notice >that it assigned a device puc0 to the UART. The OXPCIe952 can be used in many different configurations. The patch as it currently stands only supports the '2 native UARTs' function of the OXPCIe952, but on re-reading the data sheet, I realise that the patch should also support the '1 native UART' function that your card is offering. I'll check the hex arithmetic again before updating the patch, but I believe that the relevant entries for '1 native UART' are: 0x1415, 0xc11b (function 3) 0x1415, 0xc11f (function 3) 0x1415, 0xc138 (function 0) 0x1415, 0xc13d (function 1) This means that there's actually four table entries to add. My patch doesn't attempt to add support OXPCIe952 legacy UARTs or parallel ports; I don't have any suitable hardware to test with. >none3@pci0:3:0:0: class=0x070102 card=0xc1181415 chip=0xc1181415 >rev=0x00 hdr=0x00 > > vendor = 'Oxford Semiconductor Ltd' > > class = simple comms > > subclass = parallel port > >puc0@pci0:3:0:3: class=0x070002 card=0xc11b1415 chip=0xc11b1415 >rev=0x00 hdr=0x00 > > vendor = 'Oxford Semiconductor Ltd' > > class = simple comms > > subclass = UART That looks correct - there's no support for the parallel port, though it shouldn't be that hard to add. OXPCIe952 legacy UARTs and parallel ports should be much more straightforward than the native UARTs that the current patch supports. They may just need table entries, though I haven't checked too carefully. It's hard to write drivers for hardware that you don't have. Most importantly, does the serial port work with your amended patch? Does /var/run/dmesg.boot contain a line: puc0: 1 UARTs detected >I'm very new to FreeBSD and am not sure if I approached notification of my >findings in the correct way by submitting this followup. You did the right thing by replying to me and cc'ing bug-followup@FreeBSD.org The only suggestion I have is to send plain text emails; GNATS makes a bit of a mess of HTML as you can see at http://www.freebsd.org/cgi/query-pr.cgi?pr=134878 >In any case, I >hope it is helpful since I assume it is hard for the developers to test on >every combination of computer and card. Indeed. My main aim was to support my OXPCIe954 based card, but I wanted to support other cards in the family where possible. >If a new patch is released, I'd be happy to test it out. I'll attempt to update the patch some time this week to cover the '1 native UART' functions on the OXPCIe952, which will mean the patch supports your serial port. I may also have a go at the parallel port and legacy UART functions. Could you test the parallel port if I attempt to support it, or have you not got any parallel devices? I suspect that most people have left parallel port devices behind by now - printers have used USB for many years. I'm also planning to revisit the patch to attempt to add support for MSI-X on these Oxford UARTs, though that requires changing some of the main puc code, not just pucdata.c. I want to use my OXPCIe954 based card for NTP master clocks - using MSI-X offers the prospect of reducing interrupt latency and jitter. It's just a matter of finding the necessary time. Best wishes, David -- David Wood david@wood2.org.uk