History log of /freebsd/sys/dev/puc/pucdata.c (Results 26 – 50 of 257)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 3b8f0845 28-Apr-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head


# 84e51a1b 23-Apr-2014 Alan Somers <asomers@FreeBSD.org>

IFC @264767


# 10bcada8 15-Apr-2014 Marius Strobl <marius@FreeBSD.org>

Correct a typo in a device description added in r264257.


# bdc8dbd2 10-Apr-2014 Marius Strobl <marius@FreeBSD.org>

Refine r264257; given that I later on decided to nuke the wildcard for
the Sunix 0x1999 line of chips there actually is no need to explicitly
keep puc(4) from attaching to the single port version any

Refine r264257; given that I later on decided to nuke the wildcard for
the Sunix 0x1999 line of chips there actually is no need to explicitly
keep puc(4) from attaching to the single port version anymore.

show more ...


# 50c0e894 08-Apr-2014 Marius Strobl <marius@FreeBSD.org>

Distinguish between the different variants and configurations of Sunix
{MIO,SER}5xxxx chips instead of treating all of them as PUC_PORT_2S.
Among others, this fixes the hang seen when trying to probe

Distinguish between the different variants and configurations of Sunix
{MIO,SER}5xxxx chips instead of treating all of them as PUC_PORT_2S.
Among others, this fixes the hang seen when trying to probe the none-
existent second UART on an actually 1-port chip.

Obtained from: NetBSD (BAR layouts)
MFC after: 3 days
Sponsored by: Bally Wulff Games & Entertainment GmbH

show more ...


# 1709ccf9 29-Mar-2014 Martin Matuska <mm@FreeBSD.org>

Merge head up to r263906.


# 9725900b 13-Mar-2014 Ryan Stone <rstone@FreeBSD.org>

Add MSI support to puc(9)

Add support for MSI interrupts in the puc(9) driver. By default the driver
will prefer MSI interrupts to legacy interrupts. A tunable,
hw.puc.msi_disable, has been added

Add MSI support to puc(9)

Add support for MSI interrupts in the puc(9) driver. By default the driver
will prefer MSI interrupts to legacy interrupts. A tunable,
hw.puc.msi_disable, has been added to force the allocation of legacy
interrupts.

Reviewed by: jhb@
MFC after: 2 weeks
Sponsored by: Sandvine Inc.

show more ...


Revision tags: release/10.0.0, release/9.2.0
# d1d01586 05-Sep-2013 Simon J. Gerraty <sjg@FreeBSD.org>

Merge from head


# 40f65a4d 07-Aug-2013 Peter Grehan <grehan@FreeBSD.org>

IFC @ r254014


# 552311f4 17-Jul-2013 Xin LI <delphij@FreeBSD.org>

IFC @253398


# cfe30d02 19-Jun-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Merge fresh head.


# d5e0798e 14-Jun-2013 Marius Strobl <marius@FreeBSD.org>

All of Oxford/PLX OX16PCI954, OXm16PCI954 and OXu16PCI954 share the
exact same (subsystem) device and vendor IDs. However, the reference
design for the OXu16PCI954 uses a 14.7456 MHz clock (as does t

All of Oxford/PLX OX16PCI954, OXm16PCI954 and OXu16PCI954 share the
exact same (subsystem) device and vendor IDs. However, the reference
design for the OXu16PCI954 uses a 14.7456 MHz clock (as does the EXSYS
EX-41098-2 equipped with these), while at least the OX16PCI954 defaults
to a 1.8432 MHz one. According to the datasheets of these chips, the
only difference in PCI configuration space is that OXu16PCI954 have
a revision ID of 1 while the other two are at 0. So employ the latter
for determining the default clock rates of this family.
Note that one might think that the actual clock could be derived from
the Clock Prescaler Register (CPR) of these chips. Unfortunately, this
is not that case and its use and content are orthogonal to the frequency
of the crystal employed.
Tested with an EXSYS EX-41098-2, which identifies and attaches as:
pcib4@pci0:19:0:0: class=0x060400 card=0x02dd1014 chip=0x10801b21
rev=0x03 hdr=0x01
vendor = 'ASMedia Technology Inc.'
device = 'ASM1083/1085 PCIe to PCI Bridge'
class = bridge
subclass = PCI-PCI
puc0@pci0:20:4:0: class=0x070006 card=0x00001415 chip=0x95011415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)'
class = simple comms
subclass = UART
puc1@pci0:20:4:1: class=0x068000 card=0x00001415 chip=0x95111415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)'
class = bridge
puc2@pci0:20:8:0: class=0x070006 card=0x00001415 chip=0x95011415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)'
class = simple comms
subclass = UART
puc3@pci0:20:8:1: class=0x068000 card=0x00001415 chip=0x95111415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)'
class = bridge

pci20: <ACPI PCI bus> on pcib4
puc0: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5000-0x501f,
0x5020-0x503f mem 0xc6000000-0xc6000fff,0xc6001000-0xc6001fff irq 16 at
device 4.0 on pci20
uart1: <16950 or compatible> at port 1 on puc0
uart2: <16950 or compatible> at port 2 on puc0
uart3: <16950 or compatible> at port 3 on puc0
uart4: <16950 or compatible> at port 4 on puc0
puc1: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port
0x5040-0x505f,0x5060-0x507f mem 0xc6002000-0xc6002fff,0xc6003000-0xc6003fff
irq 16 at device 4.1 on pci20
puc2: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5080-0x509f,
0x50a0-0x50bf mem 0xc6004000-0xc6004fff,0xc6005000-0xc6005fff irq 16 at
device 8.0 on pci20
uart5: <16950 or compatible> at port 1 on puc2
uart6: <16950 or compatible> at port 2 on puc2
uart7: <16950 or compatible> at port 3 on puc2
uart8: <16950 or compatible> at port 4 on puc2
puc3: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port
0x50c0-0x50df,0x50e0-0x50ff mem 0xc6006000-0xc6006fff,0xc6007000-0xc6007fff
irq 16 at device 8.1 on pci20

MFC after: 2 weeks

show more ...


# d13dfb64 13-Jun-2013 Marius Strobl <marius@FreeBSD.org>

Fix whitespace and normalize some entries.


Revision tags: release/8.4.0
# 69e6d7b7 12-Apr-2013 Simon J. Gerraty <sjg@FreeBSD.org>

sync from head


# 520268fb 19-Mar-2013 Martin Matuska <mm@FreeBSD.org>

MFC @248493


# 3aff0961 18-Mar-2013 Ryan Stone <rstone@FreeBSD.org>

Correct the definition for Exar XR17V258IV: we must use a config_function
to specify the offset into the PCI memory spare at which each serial port
will find its registers. This was already done for

Correct the definition for Exar XR17V258IV: we must use a config_function
to specify the offset into the PCI memory spare at which each serial port
will find its registers. This was already done for other Exar PCI serial
devices; it was accidentally omitted for this specific device.

Sponsored by: Sandvine Incorporated
MFC after: 1 week

show more ...


# 876a84e8 18-Mar-2013 Martin Matuska <mm@FreeBSD.org>

MFC @248461


# 8de2c77b 15-Mar-2013 Ryan Stone <rstone@FreeBSD.org>

Add support for Exar XR17V358 8-port serial device to puc(4)

Reviewed by: marius
Sponsored by: Sandvine Inc.
MFC after: 1 week


# 00ff5de5 01-Mar-2013 Marius Strobl <marius@FreeBSD.org>

- Apparently, r186520 was just wrong and the clock of Oxford OX16PCI958 is
neither DEFAULT_RCLK * 2 nor DEFAULT_RCLK * 10 but plain DEFAULT_RCLK
and there's no (open) source indicating otherwise.

- Apparently, r186520 was just wrong and the clock of Oxford OX16PCI958 is
neither DEFAULT_RCLK * 2 nor DEFAULT_RCLK * 10 but plain DEFAULT_RCLK
and there's no (open) source indicating otherwise. This was tested with
an EXSYS EX-41098-2, whose clock is not configurable and identifies as:
puc0@pci0:5:1:0: class=0x070200 card=0x06711415 chip=0x95381415 rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
class = simple comms
subclass = multiport serial

Note that this exactly matches the card mentioned in PR 129665 so no
sub-device/sub-vendor based quirking of the latter is possible. So maybe
we should grow some sort of tunable, in case non-default cards such as
the latter aren't configurable either (this also wouldn't be the first
time an allegedly tested commit turns out to be wrong though).
- Make the TiMedia tables const.

MFC after: 1 week

show more ...


# d9a44755 08-Feb-2013 David E. O'Brien <obrien@FreeBSD.org>

Sync with HEAD.


Revision tags: release/9.1.0
# 300675f6 27-Nov-2012 Alexander Motin <mav@FreeBSD.org>

MFC


# e477abf7 27-Nov-2012 Alexander Motin <mav@FreeBSD.org>

MFC @ r241285


# 7d3d462b 13-Nov-2012 Neel Natu <neel@FreeBSD.org>

IFC @ r242940


# a10c6f55 11-Nov-2012 Neel Natu <neel@FreeBSD.org>

IFC @ r242684


# 5bcc8e2f 09-Nov-2012 Eitan Adler <eadler@FreeBSD.org>

Add support for Advantech PCI-1602 RS-485/RS-422 serial card

PR: kern/169726
Submitted by: Jan Mikkelsen <janm@transactionware.com>
Approved by: cperciva (implicit)
MFC after: 5 days


1234567891011