From nobody@FreeBSD.org  Sat May 23 18:23:42 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B190F106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 23 May 2009 18:23:42 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 845CA8FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 23 May 2009 18:23:42 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n4NINgWp050450
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 23 May 2009 18:23:42 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n4NINfiN050439;
	Sat, 23 May 2009 18:23:41 GMT
	(envelope-from nobody)
Message-Id: <200905231823.n4NINfiN050439@www.freebsd.org>
Date: Sat, 23 May 2009 18:23:41 GMT
From: David Wood <david@wood2.org.uk>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         134878
>Category:       kern
>Synopsis:       [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jhb
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat May 23 18:30:01 UTC 2009
>Closed-Date:    Wed Jun 08 21:11:28 UTC 2011
>Last-Modified:  Wed Jun 08 21:11:28 UTC 2011
>Originator:     David Wood
>Release:        7.2-RELEASE amd64
>Organization:
>Environment:
FreeBSD manganese.wood2.org.uk 7.2-RELEASE FreeBSD 7.2-RELEASE #2: Sat May 23 10:41:30 BST 2009     david@manganese.wood2.org.uk:/scratch/usr/obj/usr/src/sys/MANGANESE  amd64
>Description:
puc(4) doesn't support the Oxford PCI Express Expresso family devices, which are used on many native PCI Express serial boards, such as:

eMegatech MP954ER4 (4 port) and MP958ER8 (8 port)
<URL:http://www.emegatech.com.tw/pdrs232pcie.html>

Lindy 51189 (4 port)
<URL:http://www.lindy.com> <URL:http://tinyurl.com/lindy-51189>

StarTech.com PEX4S952 (4 port) and PEX8S952 (8 port)
<URL:http://www.startech.com>
>How-To-Repeat:

>Fix:
A patch against 7.2-RELEASE can be found at http://www.wood2.org.uk/freebsd/oxford-pci-e-pucdata.c.7.2-release.patch - this has been tested with a Lindy 51189 board, which uses an OXPCIe954, in a Dell PowerEdge 2950 III.

A patch against HEAD can be found at http://www.wood2.org.uk/freebsd/oxford-pci-e-pucdata.c.patch - this has not been tested.


Whilst I'm here, I've updated the URL for manufacturer's data - Oxford Semiconductor has now been taken over by PLX Technology.


The patch assumes that the number of ports are the number of ports on the chip connected to the PCI Express bus. A possible future enhancement is to read the number of UARTs from BAR 0 offset 0x4, which reflects any ports on a slave chip (this appears to be non-trivial, as bus_allocate_resource(9) hasn't been called on the BAR before the number of ports is required). Fortunately, very few designs are likely to use a slave chip, especially with the 8 port OXPCIe958 available.

MSI-X support has not been attempted, though would be nice to have.


Note: Oxford OXPCIe952 is most likely to appear as two separate devices, each with a single UART. I'm hopeful that uart(4) (or sio(4) if you're still using that) will recognise those UARTs without the need of a helping hand from puc(4). I haven't added support for the unlikely configuration of OXPCIe952 appearing as a single device with two UARTs, especially as I don't have a suitable boardto test with.

>Release-Note:
>Audit-Trail:

From: David Wood <david@wood2.org.uk>
To: bug-followup@FreeBSD.org, david@wood2.org.uk, marcel@FreeBSD.org
Cc:  
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Sat, 6 Jun 2009 09:48:50 +0100

 [marcel@ cc'd, as I believe he is maintaining puc(4)]
 
 I have updated the patches to:
 
 * Support the '2 native UARTs' configuration of the OXPCIe952
 
 * Read the number of UARTs from BAR 0 (rid 0x10) offset 0x4, so boards 
 with slave chips or some UARTs disabled by EEPROM are now fully 
 supported.
 
 * Print the number of UARTs found.
 
 * Set the enhanced mode bit on each UART, so uart(4) detects them as 
 16950 and should make use of the deeper FIFOs.
 
 
 Apart from MSI-X support (which would be nice), all the features of 
 these chips that are within the ambit of puc(4) rather than uart(4) are 
 now supported.
 
 
 The Lindy 51189 board in my Dell PowerEdge 2950 III running 7.2-RELEASE 
 amd64 with the patch applied appears as:
 
 boot (extract):
 
 puc0: <Oxford Semiconductor OXPCIe954 UARTs> mem 
 0xd5efc000-0xd5efffff,0xd5c00000-0xd5dfffff,0xd5a00000-0xd5bfffff irq 18 
 at device 0.0 on pci8
 puc0: 4 UARTs detected
 puc0: [FILTER]
 uart0: <16950 or compatible> on puc0
 uart0: [FILTER]
 uart1: <16950 or compatible> on puc0
 uart1: [FILTER]
 uart2: <16950 or compatible> on puc0
 uart2: [FILTER]
 uart3: <16950 or compatible> on puc0
 uart3: [FILTER]
 
 
 pciconf -lcv (extract):
 
 puc0@pci0:8:0:0:        class=0x070002 card=0xc2081415 chip=0xc2081415 
 rev=0x00 hdr=0x00
      vendor     = 'Oxford Semiconductor Ltd'
      class      = simple comms
      subclass   = UART
      cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
      cap 10[70] = PCI-Express 1 endpoint
      cap 11[b0] = MSI-X supports 16 messages in map 0x14
 
 
 Kernel configuration (partial):
 
 include GENERIC
 
 ident MANGANESE
 
 # SERIAL
 
 # Multi-port serial cards
 device puc
 
 # Disable sio(4) so that uart(4) is used
 nodevice sio
 
 
 
 The latest patches are in the same locations as the old ones:
 
 7.2-RELEASE (tested):
 http://www.wood2.org.uk/freebsd/oxford-pci-e-pucdata.c.7.2-release.patch
 
 HEAD (untested):
 http://www.wood2.org.uk/freebsd/oxford-pci-e-pucdata.c.patch
 
 
 The old patches are still available - suffix the URLs with .old
 
 
 
 With best wishes,
 
 
 
 
 David
 -- 
 David Wood
 david@wood2.org.uk

From: "Bill Lortz" <blortz@pacbell.net>
To: <bug-followup@FreeBSD.org>, <david@wood2.org.uk>
Cc:  
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Sun, 8 Nov 2009 11:02:46 -0800

 This is a multi-part message in MIME format.
 
 ------=_NextPart_000_01B3_01CA6063.01402410
 Content-Type: text/plain;
 	charset="us-ascii"
 Content-Transfer-Encoding: 7bit
 
 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).
 
  
 
 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.
 
  
 
 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.
 
  
 
 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.
 
  
 
  
 
 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
 
  
 
 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.   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.
 
  
 
 If a new patch is released, I'd be happy to test it out.
 
  
 
 Bill Lortz
 
  
 
 
 ------=_NextPart_000_01B3_01CA6063.01402410
 Content-Type: text/html;
 	charset="us-ascii"
 Content-Transfer-Encoding: quoted-printable
 
 <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
 xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
 xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
 xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
 xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
 xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
 xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
 xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
 xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
 xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
 xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
 xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
 xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
 xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
 xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
 xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
 xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
 xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
 xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
 xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
 xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
 xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
 xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
 xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
 xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
 xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
 xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
  xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
 xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
 xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
 xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
 xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
 xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
 xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
 xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
 xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
 xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
 nature" =
 xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
 " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
 xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
 ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
 xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
  =
 xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
 es" =
 xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
 " =
 xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
 lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
 xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
 
 <head>
 <meta http-equiv=3DContent-Type content=3D"text/html; =
 charset=3Dus-ascii">
 <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
 <style>
 <!--
  /* Font Definitions */
  @font-face
 	{font-family:"Cambria Math";
 	panose-1:2 4 5 3 5 4 6 3 2 4;}
 @font-face
 	{font-family:Calibri;
 	panose-1:2 15 5 2 2 2 4 3 2 4;}
  /* Style Definitions */
  p.MsoNormal, li.MsoNormal, div.MsoNormal
 	{margin:0in;
 	margin-bottom:.0001pt;
 	font-size:11.0pt;
 	font-family:"Calibri","sans-serif";}
 a:link, span.MsoHyperlink
 	{mso-style-priority:99;
 	color:blue;
 	text-decoration:underline;}
 a:visited, span.MsoHyperlinkFollowed
 	{mso-style-priority:99;
 	color:purple;
 	text-decoration:underline;}
 span.EmailStyle17
 	{mso-style-type:personal-compose;
 	font-family:"Calibri","sans-serif";
 	color:windowtext;}
 .MsoChpDefault
 	{mso-style-type:export-only;}
 @page Section1
 	{size:8.5in 11.0in;
 	margin:1.0in 1.0in 1.0in 1.0in;}
 div.Section1
 	{page:Section1;}
 -->
 </style>
 <!--[if gte mso 9]><xml>
  <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
 </xml><![endif]--><!--[if gte mso 9]><xml>
  <o:shapelayout v:ext=3D"edit">
   <o:idmap v:ext=3D"edit" data=3D"1" />
  </o:shapelayout></xml><![endif]-->
 </head>
 
 <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
 
 <div class=3DSection1>
 
 <p class=3DMsoNormal>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.&nbsp;&nbsp;
 The computer is a FITPC2 (Intel Atom-based computer).<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>After applying the puc patch, enabling puc in the =
 kernel and
 re-compiling, the card is recognized, but no driver was assigned. =
 <o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>I ran a pciconf &#8211;lv to list the pci devices =
 and found
 the chip id&#8217;s didn&#8217;t match anything in the patched =
 driver.<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>So, I changed an entry in the patched code for the =
 952 chip from
 &#8220;0x1415, 0x15d&#8221;&nbsp; &nbsp;to &#8220;0x1415, 0xc11b&#8221; =
 so that
 it matched the output from the pciconf.&nbsp;&nbsp; Since I was only =
 interested
 in the serial function, I didn&#8217;t try to patch for the parallel =
 port
 function. &nbsp;&nbsp;&nbsp;After recompiling the kernel it worked and =
 assigned
 a device driver to the UART.<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>I wasn&#8217;t comfortable in my patch to add a new =
 table
 entry, so that is why I changed an existing entry.&nbsp;&nbsp; I suspect =
 the
 proper patch would be to add a new table entry.&nbsp;&nbsp;&nbsp;&nbsp; =
 I&#8217;ve
 included the output from my &#8220;pciconf&#8221; that shows the pci =
 card and
 chip ids for both the serial and parallel ports.&nbsp;&nbsp; Notice that =
 it
 assigned a device puc0 to the UART.<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p =
 class=3DMsoNormal>none3@pci0:3:0:0:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 class=3D0x070102 card=3D0xc1181415 chip=3D0xc1181415 rev=3D0x00 =
 hdr=3D0x00<o:p></o:p></p>
 
 <p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; vendor&nbsp;&nbsp;&nbsp;&nbsp; =
 =3D 'Oxford
 Semiconductor Ltd'<o:p></o:p></p>
 
 <p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; =
 class&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
 simple comms<o:p></o:p></p>
 
 <p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; subclass&nbsp;&nbsp; =3D =
 parallel port<o:p></o:p></p>
 
 <p =
 class=3DMsoNormal>puc0@pci0:3:0:3:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
 sp;
 class=3D0x070002 card=3D0xc11b1415 chip=3D0xc11b1415 rev=3D0x00 =
 hdr=3D0x00<o:p></o:p></p>
 
 <p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; vendor&nbsp;&nbsp;&nbsp;&nbsp; =
 =3D 'Oxford
 Semiconductor Ltd'<o:p></o:p></p>
 
 <p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; =
 class&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =3D
 simple comms<o:p></o:p></p>
 
 <p class=3DMsoNormal>&nbsp;&nbsp;&nbsp; subclass&nbsp;&nbsp; =3D =
 UART<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>I&#8217;m very new to FreeBSD and am not sure if I
 approached notification of my findings in the correct way by submitting =
 this
 followup.&nbsp;&nbsp; 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.<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>If a new patch is released, I&#8217;d be happy to =
 test it
 out.<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>Bill Lortz<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 </div>
 
 </body>
 
 </html>
 
 ------=_NextPart_000_01B3_01CA6063.01402410--
 

From: David Wood <david@wood2.org.uk>
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 
 <blortz@pacbell.net> 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

From: "Bill Lortz" <blortz@pacbell.net>
To: "'David Wood'" <david@wood2.org.uk>
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 22:57:39 -0800

 David:
 
 I'm glad to hear that I wasn't way off base.
 
 To answer your questions:
 
 
 
 > Most importantly, does the serial port work with your amended patch?
 
 > Does /var/run/dmesg.boot contain a line:
 > puc0: 1 UARTs detected
 
 Yes, the serial port works great.  I'm using with NTPD and have a GPS PPS
 signal from a Garmin 18x LVC GPS on pin 1 (DSR) along with TX/RX and GND on
 the appropriate pins.  NTPD and the kernel are seeing the PPS signal and
 receiving a NMEA data just fine.   I don't know if NTPD tries to transmit
 anything though, so it is possible the transmit function isn't working and I
 don't know it.   If you'd like me to test that specifically, I can probably
 find something else to plug in besides the GPS and try it out - even a null
 modem to another PC might work.
 
 The relevant lines in dmesg.boot are: 
 
 pci3: <ACPI PCI bus> on pcib2
 pci3: <simple comms, parallel port> at device 0.0 (no driver attached)puc0:
 <Oxford Semiconductor OXPCIe952 UARTs (function 1)> mem
 0xd8200000-0xd8203fff,0xd8600000-0xd87fffff,0xd8400000-0xd85fffff irq 16 at
 device 0.3 on pci3
 puc0: 1 UARTs detected
 puc0: [FILTER]
 uart2: <16950 or compatible> on puc0
 
 I do remember seeing some sort of weird message when I did the verbose boot
 logging.   Something about assigning a memory block and some conflict with
 an entry (sorry about being so vague).   If you do have time to come up with
 an updated patch, I'll try both unknowns: "transmitting" and to get the
 message from the verbose boot log for you.
 
 The device names in /dev that it created didn't match anything I saw online,
 but I took a chance and used them in NTPD which worked.  The names it
 created were: /dev/cuau2 /dev/cuau2.init /dev/cuau2.lock /dev/ttyu2
 /dev/ttyu2.init /dev/ttyu2.lock
 I used the /dev/cuau2 for NTPD by using some symbolic links.
 
 
 
 >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
 
 Yes.   I actually searched on google by the patch id and some other words
 and found the "Current FreeBSD problem reports" page.   I clicked on the
 followup link and it wound up launching Microsoft Outlook with the correct
 "to:" and "cc:" elements.    I didn't realize that it was sending HTML also
 until (with horror) I saw my reply on that case with all the HTML garbage
 afterwards.   On this message, Outlook is claiming to send Plain Text.
 We'll see... :)
 
 
 >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.
 
 Sure.   I'll have to open the computer case and temporarily attach the
 parallel port cable to the card.   I'll probably have to pick up the right
 kind of adapter cable, but I think that I have a couple of printers around
 that can accept parallel.   If not at home, I do at work.
 
 
 >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.
 
 That sounds like something that would help my little NTPD/GPS clock setup.
 Let me know if there is anything I can help you with.   
 
 
 
 Bill
 

From: Joerg Traeger <jt@xoasis.de>
To: bug-followup@FreeBSD.org
Cc: david@wood2.org.uk
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Wed, 2 Mar 2011 08:35:04 +0100

 Hi all,
 
 I would like to report success using a PCIe card with Oxford 958 and 32 (2 x 
 16) serial ports. Its name is EXSYS EX-44032. OS is FreeBSD 8.2.
 Using the patch mentioned puc recognizes all ports and the card works fine.
 Will this patch be commited in the future?
 
 Thanks!
 
 Joerg Traeger

From: David Wood <david@wood2.org.uk>
To: jt@xoasis.de
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Wed, 2 Mar 2011 12:11:25 +0000

 Hi Joerg,
 
 In message <201103020835.04483.jt@xoasis.de>, Joerg Traeger 
 <jt@xoasis.de> writes
 >I would like to report success using a PCIe card with Oxford 958 and 32 (2 x
 >16) serial ports. Its name is EXSYS EX-44032. OS is FreeBSD 8.2.
 >Using the patch mentioned puc recognizes all ports and the card works fine.
 >Will this patch be commited in the future?
 
 I'm glad to hear that the patch works correctly for such a 'mega' serial 
 card.
 
 
 I would still like to implement MSI-X interrupt handling. With standard 
 IRQs, I found that the jitter is too high on my OXPCIe954 based card for 
 pulse per second to work optimally with NTP, though it is usable.
 
 The most important thing is that this driver works 'as is' for a range 
 of cards on several FreeBSD versions. I hope it will be committed so 
 that others can use these excellent PCIe serial chips without patching 
 their kernels.
 
 
 I did my best to try to interest some committers, though without 
 success. The PR is on linimon's list of easy PRs
 http://people.freebsd.org/~linimon/studies/prs/easy_prs.html
 
 I keep hoping that someone will commit this and close a PR that has been 
 open for 21 months. If you want to try some advocacy amongst committers, 
 be my guest!
 
 
 
 With best wishes,
 
 
 
 
 David
 -- 
 David Wood
 david@wood2.org.uk

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/134878: commit references a PR
Date: Thu, 28 Apr 2011 19:19:40 +0000 (UTC)

 Author: jhb
 Date: Thu Apr 28 19:19:25 2011
 New Revision: 221182
 URL: http://svn.freebsd.org/changeset/base/221182
 
 Log:
   Add support for Oxford PCI Express Expresso family devices.
   For these devices, the number of supported ports is read from a register
   in BAR 0.
   
   PR:		kern/134878
   Submitted by:	David Wood  david of wood2 org uk
   MFC after:	1 week
 
 Modified:
   head/sys/dev/puc/pucdata.c
 
 Modified: head/sys/dev/puc/pucdata.c
 ==============================================================================
 --- head/sys/dev/puc/pucdata.c	Thu Apr 28 19:08:31 2011	(r221181)
 +++ head/sys/dev/puc/pucdata.c	Thu Apr 28 19:19:25 2011	(r221182)
 @@ -56,6 +56,7 @@ static puc_config_f puc_config_syba;
  static puc_config_f puc_config_siig;
  static puc_config_f puc_config_timedia;
  static puc_config_f puc_config_titan;
 +static puc_config_f puc_config_oxford_pcie;
  
  const struct puc_cfg puc_pci_devices[] = {
  
 @@ -619,7 +620,7 @@ const struct puc_cfg puc_pci_devices[] =
  	 * Boards with an Oxford Semiconductor chip.
  	 *
  	 * Oxford Semiconductor provides documentation for their chip at:
 -	 * <URL:http://www.oxsemi.com/products/uarts/index.html>
 +	 * <URL:http://www.plxtech.com/products/uart/>
  	 *
  	 * As sold by Kouwell <URL:http://www.kouwell.com/>.
  	 * I/O Flex PCI I/O Card Model-223 with 4 serial and 1 parallel ports.
 @@ -679,6 +680,63 @@ const struct puc_cfg puc_pci_devices[] =
  	    PUC_PORT_4S, 0x10, 0, 8,
  	},
  
 +	/*
 +	 * Oxford Semiconductor PCI Express Expresso family
 +	 *
 +	 * Found in many 'native' PCI Express serial boards such as:
 +	 *
 +	 * eMegatech MP954ER4 (4 port) and MP958ER8 (8 port)
 +	 * <URL:http://www.emegatech.com.tw/pdrs232pcie.html>
 +	 *
 +	 * Lindy 51189 (4 port)
 +	 * <URL:http://www.lindy.com> <URL:http://tinyurl.com/lindy-51189>
 +	 * 
 +	 * StarTech.com PEX4S952 (4 port) and PEX8S952 (8 port)
 +	 * <URL:http://www.startech.com>
 +	 */
 +
 +	{   0x1415, 0xc158, 0xffff, 0,
 +	    "Oxford Semiconductor OXPCIe952 UARTs",
 +	    DEFAULT_RCLK * 0x22,
 +	    PUC_PORT_NONSTANDARD, 0x10, 0, -1,
 +	    .config_function = puc_config_oxford_pcie
 +	},
 +
 +	{   0x1415, 0xc15d, 0xffff, 0,
 +	    "Oxford Semiconductor OXPCIe952 UARTs (function 1)",
 +	    DEFAULT_RCLK * 0x22,
 +	    PUC_PORT_NONSTANDARD, 0x10, 0, -1,
 +	    .config_function = puc_config_oxford_pcie
 +	},
 +
 +	{   0x1415, 0xc208, 0xffff, 0,
 +	    "Oxford Semiconductor OXPCIe954 UARTs",
 +	    DEFAULT_RCLK * 0x22,
 +	    PUC_PORT_NONSTANDARD, 0x10, 0, -1,
 +	    .config_function = puc_config_oxford_pcie
 +	},
 +
 +	{   0x1415, 0xc20d, 0xffff, 0,
 +	    "Oxford Semiconductor OXPCIe954 UARTs (function 1)",
 +	    DEFAULT_RCLK * 0x22,
 +	    PUC_PORT_NONSTANDARD, 0x10, 0, -1,
 +	    .config_function = puc_config_oxford_pcie
 +	},
 +
 +	{   0x1415, 0xc308, 0xffff, 0,
 +	    "Oxford Semiconductor OXPCIe958 UARTs",
 +	    DEFAULT_RCLK * 0x22,
 +	    PUC_PORT_NONSTANDARD, 0x10, 0, -1,
 +	    .config_function = puc_config_oxford_pcie
 +	},
 +
 +	{   0x1415, 0xc30d, 0xffff, 0,
 +	    "Oxford Semiconductor OXPCIe958 UARTs (function 1)",
 +	    DEFAULT_RCLK * 0x22,
 +	    PUC_PORT_NONSTANDARD, 0x10, 0, -1,
 +	    .config_function = puc_config_oxford_pcie
 +	},
 +
  	{   0x14d2, 0x8010, 0xffff, 0,
  	    "VScom PCI-100L",
  	    DEFAULT_RCLK * 8,
 @@ -1253,6 +1311,81 @@ puc_config_timedia(struct puc_softc *sc,
  }
  
  static int
 +puc_config_oxford_pcie(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
 +    intptr_t *res)
 +{
 +	const struct puc_cfg *cfg = sc->sc_cfg;
 +	int idx;
 +	struct puc_bar *bar;
 +	uint8_t value;
 +
 +	switch (cmd) {
 +	case PUC_CFG_SETUP:
 +		device_printf(sc->sc_dev, "%d UARTs detected\n",
 +			sc->sc_nports);
 +
 +		/* Set UARTs to enhanced mode */
 +		bar = puc_get_bar(sc, cfg->rid);
 +		if (bar == NULL)
 +			return (ENXIO);
 +
 +		for (idx = 0; idx < sc->sc_nports; idx++) {
 +			value = bus_read_1(bar->b_res, 0x1000 + (idx << 9)
 +				+ 0x92);
 +			bus_write_1(bar->b_res, 0x1000 + (idx << 9) + 0x92,
 +				value | 0x10);
 +		}
 +
 +		return (0);
 +	case PUC_CFG_GET_LEN:
 +		*res = 0x200;
 +		return (0);
 +	case PUC_CFG_GET_NPORTS:
 +		/*
 +		 * Check if we are being called from puc_bfe_attach()
 +		 * or puc_bfe_probe(). If puc_bfe_probe(), we cannot
 +		 * puc_get_bar(), so we return a value of 16. This has cosmetic
 +		 * side-effects at worst; in PUC_CFG_GET_DESC,
 +		 * (int)sc->sc_cfg_data will not contain the true number of
 +		 * ports in PUC_CFG_GET_DESC, but we are not implementing that
 +		 * call for this device family anyway.
 +		 *
 +		 * The check is for initialisation of sc->sc_bar[idx], which is
 +		 * only done in puc_bfe_attach().
 +		 */
 +		idx = 0;
 +		do {
 +			if (sc->sc_bar[idx++].b_rid != -1) {
 +				sc->sc_cfg_data = 16;
 +				*res = sc->sc_cfg_data;
 +				return (0);
 +			}
 +		} while (idx < PUC_PCI_BARS);
 +
 +		bar = puc_get_bar(sc, cfg->rid);
 +		if (bar == NULL)
 +			return (ENXIO);
 +
 +		value = bus_read_1(bar->b_res, 0x04);
 +		if (value == 0)
 +			return (ENXIO);
 +
 +		sc->sc_cfg_data = value;
 +		*res = sc->sc_cfg_data;
 +		return (0);
 +	case PUC_CFG_GET_OFS:
 +		*res = 0x1000 + (port << 9);
 +		return (0);
 +	case PUC_CFG_GET_TYPE:
 +		*res = PUC_TYPE_SERIAL;
 +		return (0);
 +	default:
 +		break;
 +	}
 +	return (ENXIO);
 +}
 +
 +static int
  puc_config_titan(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
      intptr_t *res)
  {
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: jhb 
State-Changed-When: Thu Apr 28 19:21:21 UTC 2011 
State-Changed-Why:  
Patch committed to HEAD.  Will merge to 7 and 8 in a week or so. 


Responsible-Changed-From-To: freebsd-bugs->jhb 
Responsible-Changed-By: jhb 
Responsible-Changed-When: Thu Apr 28 19:21:21 UTC 2011 
Responsible-Changed-Why:  
Patch committed to HEAD.  Will merge to 7 and 8 in a week or so. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=134878 

From: David Wood <david@wood2.org.uk>
To: bug-followup@FreeBSD.org, david@wood2.org.uk,
 John Baldwin <jhb@freebsd.org>
Cc:  
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Mon, 6 Jun 2011 15:44:18 +0100

 Hi John,
 
 Thanks so much for merging this patch to HEAD.
 
 Is there any chance of MFCing the patch to 8-stable, as was envisaged 
 earlier in the PR?
 
 
 Many thanks,
 
 
 
 David
 -- 
 David Wood
 david@wood2.org.uk

From: John Baldwin <jhb@freebsd.org>
To: David Wood <david@wood2.org.uk>
Cc: bug-followup@freebsd.org,
 bde@freebsd.org
Subject: Re: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Mon, 6 Jun 2011 11:32:10 -0400

 On Monday, June 06, 2011 10:44:18 am David Wood wrote:
 > Hi John,
 > 
 > Thanks so much for merging this patch to HEAD.
 > 
 > Is there any chance of MFCing the patch to 8-stable, as was envisaged 
 > earlier in the PR?
 
 Bruce Evans (cc'd) had some questions about enabling enhanced mode here
 in puc(4) rather than in uart(4) (I think).  I had been wanting to clear
 that up before I did an MFC, but I only replied to Bruce's earlier
 e-mail today (my fault).  I do intend to merge these to 8-stable however.
 
 -- 
 John Baldwin
State-Changed-From-To: patched->closed 
State-Changed-By: jhb 
State-Changed-When: Wed Jun 8 21:11:08 UTC 2011 
State-Changed-Why:  
Merged to 8. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=134878 
>Unformatted:
