Date: Fri, 3 Jun 2011 09:48:26 -0400 From: John Baldwin <jhb@freebsd.org> To: Willy@offermans.rompen.nl Cc: freebsd-hardware@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV Message-ID: <201106030948.26246.jhb@freebsd.org> In-Reply-To: <20110603123454.GB3433@vpn.offrom.nl> References: <20110521092037.GB3271@vpn.offrom.nl> <201105311101.23905.jhb@freebsd.org> <20110603123454.GB3433@vpn.offrom.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, June 03, 2011 8:34:54 am Willy Offermans wrote:
> Dear John and FreeBSD friends,
>
> On Tue, May 31, 2011 at 11:01:23AM -0400, John Baldwin wrote:
> > On Monday, May 30, 2011 5:25:14 am Willy Offermans wrote:
> > > Hello John and FreeBSD friends,
> > >
> > > On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote:
> > > > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote:
> > > > > Dear John and FreeBSD friends,
> > > > >
> > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote:
> > > > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote:
> > > > > > > On 5/26/2011 4:12 PM, John Baldwin wrote:
> > > > > > > >
> > > > > > > > Hmm, can you get 'pciconf -lb' output?
> > > > > > > >
> > > > > > > > Hmm, wow, I wonder how uart(4) works at all. It tries to
reuse it's softc
> > > > > > > > structure in uart_bus_attach() that was setup in
uart_bus_probe(). Since
> > > > > > it
> > > > > > > > doesn't return 0 from its probe routine, that is forbidden.
I guess it
> > > > > > > > accidentally works because of the hack where we call
DEVICE_PROBE() again
> > > > > > > > to make sure the device description is correct.
> > > > > > >
> > > > > > >
> > > > > > > I think this is a similar card. Had it laying about for a while
and
> > > > > > > popped it in. cu -l to it, attaches, but I am not able to
interact with it.
> > > > > > >
> > > > > > > none3@pci0:5:0:0: class=0x070002 card=0x20282205
chip=0x015213a8
> > > > > > > rev=0x02 hdr=0x00
> > > > > > > vendor = 'Exar Corp.'
> > > > > > > device = 'XR17C/D152 Dual PCI UART'
> > > > > > > class = simple comms
> > > > > > > subclass = UART
> > > > > > > bar [10] = type Memory, range 32, base 0xe8950000, size
1024, enabled
> > > > > > >
> > > > > > >
> > > > > > > NetBSD supposedly has support for this card
> > > > > >
> > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it
work if you
> > > > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use
speed / 8
> > > > > > as the speed to '-s'.)
> > > > > >
> > > > > > Also, is your card a modem or a dual-port card?
> > > > > >
> > > > > > --
> > > > > > John Baldwin
> > > > >
> > > > > It is a modem.
> > > > >
> > > > > As suggested:
> > > > >
> > > > > kosmos# cu -l /dev/cuau0 -s 1200
> > > > > Stale lock on cuau0 PID=3642... overriding.
> > > > > Connected
> > > > > at&F
> > > > > OK
> > > > > atdt0045*******
> > > > > NO DIALTONE
> > > >
> > > > Ok, try this updated patch. After this you should be able to use the
correct
> > > > speed:
> > > >
> > > > Index: uart_bus_pci.c
> > > > ===================================================================
> > > > --- uart_bus_pci.c (revision 222285)
> > > > +++ uart_bus_pci.c (working copy)
> > > > @@ -110,6 +110,8 @@ static struct pci_id pci_ns8250_ids[] = {
> > > > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus
16950 UART",
> > > > 0x10, 16384000 },
> > > > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem",
0x10 },
> > > > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10,
> > > > + 8 * DEFAULT_RCLK },
> > > > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 },
> > > > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 },
> > > > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10
},
> > > >
> > > > --
> > > > John Baldwin
> > >
> > > The structure you have provided in your magic line would also need
> > > some explanation. The data concerns the description of the chip and the
> > > card I guess and can be gained by `pciconf -lv`
> > >
> > > uart0@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8
rev=0x02 hdr=0x00
> > > vendor = 'Exar Corp.'
> > > device = 'XR17C/D152 Dual PCI UART'
> > > class = simple comms
> > > subclass = UART
> > >
> > >
> > > A more detailed explanation would not harm. The data 0x10 and
> > > 8 * DEFAULT_RCLK are still totally miraculous to me.
> >
> > 0x10 is the resource id for the first PCI BAR (rids for PCI device
resources
> > use the offset in PCI config space of the associated BAR). It would
perhaps
> > be more obvious if uart(4) and puc(4) used PCIR_BAR(0) rather than 0x10.
> > Bumping the clock by a multiple of 8 was based on looking at the change in
> > NetBSD that Mike Tancsa pointed to and that you verified by noting that
> > 'cu -s 1200' connected at 9600 (9600 / 1200 == 8).
> >
> > One question though, would you be able to test the patch for puc(4) that I
> > sent to Mike Tancsa to see if your modem works with puc(4)? The puc(4)
> > patch is more general and if it works fine for your modem I'd rather just
> > commit that.
> >
> > --
> > John Baldwin
>
> I have applied the suggested patch.
>
> The outcome was a new /usr/src/sys/dev/puc/pucdata.c file, which I have
> enclosed.
Hmm, there was a newer puc patch. Please try this one instead:
Index: pucdata.c
===================================================================
--- pucdata.c (revision 222565)
+++ pucdata.c (working copy)
@@ -48,8 +48,8 @@ __FBSDID("$FreeBSD$");
#include <dev/puc/puc_bfe.h>
static puc_config_f puc_config_amc;
-static puc_config_f puc_config_cronyx;
static puc_config_f puc_config_diva;
+static puc_config_f puc_config_exar;
static puc_config_f puc_config_icbook;
static puc_config_f puc_config_quatech;
static puc_config_f puc_config_syba;
@@ -548,11 +548,25 @@ const struct puc_cfg puc_pci_devices[] = {
PUC_PORT_8S, 0x18, 0, 8,
},
+ { 0x13a8, 0x0152, 0xffff, 0,
+ "Exar XR17C/D152",
+ DEFAULT_RCLK * 8,
+ PUC_PORT_2S, 0x10, 0, -1,
+ .config_function = puc_config_exar
+ },
+
+ { 0x13a8, 0x0154, 0xffff, 0,
+ "Exar XR17C154",
+ DEFAULT_RCLK * 8,
+ PUC_PORT_4S, 0x10, 0, -1,
+ .config_function = puc_config_exar
+ },
+
{ 0x13a8, 0x0158, 0xffff, 0,
- "Cronyx Omega2-PCI",
+ "Exar XR17C158",
DEFAULT_RCLK * 8,
PUC_PORT_8S, 0x10, 0, -1,
- .config_function = puc_config_cronyx
+ .config_function = puc_config_exar
},
{ 0x13a8, 0x0258, 0xffff, 0,
@@ -1014,28 +1028,28 @@ puc_config_amc(struct puc_softc *sc, enum puc_cfg_
}
static int
-puc_config_cronyx(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
+puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
intptr_t *res)
{
+ const struct puc_cfg *cfg = sc->sc_cfg;
+
if (cmd == PUC_CFG_GET_OFS) {
- *res = port * 0x200;
+ if (cfg->subdevice == 0x1282) /* Everest SP */
+ port <<= 1;
+ else if (cfg->subdevice == 0x104b) /* Maestro SP2 */
+ port = (port == 3) ? 4 : port;
+ *res = port * 8 + ((port > 2) ? 0x18 : 0);
return (0);
}
return (ENXIO);
}
static int
-puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
+puc_config_exar(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
intptr_t *res)
{
- const struct puc_cfg *cfg = sc->sc_cfg;
-
if (cmd == PUC_CFG_GET_OFS) {
- if (cfg->subdevice == 0x1282) /* Everest SP */
- port <<= 1;
- else if (cfg->subdevice == 0x104b) /* Maestro SP2 */
- port = (port == 3) ? 4 : port;
- *res = port * 8 + ((port > 2) ? 0x18 : 0);
+ *res = port * 0x200;
return (0);
}
return (ENXIO);
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106030948.26246.jhb>