Date: Tue, 31 May 2011 11:01:23 -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, Mike Tancsa <mike@sentex.net> Subject: Re: modem support MT9234ZPX-PCIE-NV Message-ID: <201105311101.23905.jhb@freebsd.org> In-Reply-To: <20110530092514.GB4558@vpn.offrom.nl> References: <20110521092037.GB3271@vpn.offrom.nl> <201105271043.34268.jhb@freebsd.org> <20110530092514.GB4558@vpn.offrom.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201105311101.23905.jhb>