On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote:
> On Tuesday, January 15, 2013 10:44:33 am Andre Albsmeier wrote:
> > On Mon, 14-Jan-2013 at 21:02:58 +0100, John Baldwin wrote:
> > > On Thursday, January 10, 2013 2:40:52 am Andre Albsmeier wrote:
> > > > [Retrying here, maybe anyone can help...}
> > > >
> > > > I want my printer port back on 9.1 ;-(
> > > >
> > > > I have this card:
> > > >
> > > > puc0@pci0:4:1:0: class=0x078000 card=0x00121000 chip=0x98359710
> > > rev=0x01 hdr=0x00
> > > > vendor = 'NetMos Technology'
> > > > device = 'PCI 9835 Multi-I/O Controller'
> > > > class = simple comms
> > > >
> > > > It attached and worked under 7.4-STABLE (as long as I disabled
> > > > the interrupt using hint.ppc.0.irq=""):
> > > >
> > > > puc0: <NetMos NM9835 Dual UART and 1284 Printer port> port
> > > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07
> > > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4
> > > > puc0: [FILTER]
> > > > uart0: <Non-standard ns8250 class UART with FIFOs> on puc0
> > > > uart0: [FILTER]
> > > > uart1: <Non-standard ns8250 class UART with FIFOs> on puc0
> > > > uart1: [FILTER]
> > > > ppc0: <Parallel port> on puc0
> > > > ppc0: Generic chipset (ECP/EPP/PS2/NIBBLE) in ECP+EPP mode (EPP 1.9)
> > > > ppbus0: <Parallel port bus> on ppc0
> > > > lpt0: <Printer> on ppbus0
> > > > lpt0: Polled port
> > > >
> > > >
> > > > Under 9.1 the card does not attach the ppc anymore. The hint entries
> > > >
> > > > hint.ppc.0.at=puc0
> > > > hint.ppc.0.irq=""
> > > > hint.ppc.0.flags=0x2F
> > > >
> > > > get ignored and so it probes as ppc1 (failing due to the interrupt
> > > > problem as it was in 7.4 without hints):
> > > >
> > > > puc0: <NetMos NM9835 Dual UART and 1284 Printer port> port
> > > 0xdf00-0xdf07,0xde00-0xde07,0xdd00-0xdd07
> > > > ,0xdc00-0xdc07,0xdb00-0xdb07,0xda00-0xda0f irq 17 at device 1.0 on pci4
> > > > uart2: <Non-standard ns8250 class UART with FIFOs> at port 1 on puc0
> > > > uart3: <16550 or compatible> at port 2 on puc0
> > > > ppc1: <Parallel port> at port 3 on puc0
> > > > ppc1: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
> > > > ppc1: failed to register interrupt handler: 6
> > > > device_attach: ppc1 attach returned 6
> > > >
> > > > Any ideas? How do I construct the hint entries under 9.1 so that
> > > >
> > > > 1. it does not want to use the interrupt (which made it attach under
> 7.4)
> > > > 2. it takes the flags 0x2F as it did before.
> > > >
> > > > I have also never understood if ppc itself needs to attach to
> > > > the irq as well (I thought this all would be handled by puc).
> > >
> > > Well, ppc wants to use puc's interrupt, and it should be finding puc's
> > > interrupt. Ah, I think I found the bug. Try this patch to
> sys/dev/puc/puc.c:
> > >
> > > Index: puc.c
> > > ===================================================================
> > > --- puc.c (revision 245225)
> > > +++ puc.c (working copy)
> > > @@ -622,7 +628,7 @@ puc_bus_setup_intr(device_t dev, device_t child, s
> > > if (cookiep == NULL || res != port->p_ires)
> > > return (EINVAL);
> > > /* We demand that serdev devices use filter_only interrupts. */
> > > - if (ihand != NULL)
> > > + if (port->p_type == PUC_TYPE_SERIAL && ihand != NULL)
> > > return (ENXIO);
> > > if (rman_get_device(port->p_ires) != originator)
> > > return (ENXIO);
> > >
> > > This should let your ppc device re-use IRQ 17 from your puc device.
> >
> > True, this really makes ppc use puc's interrupt: I removed
> > my local hack (more on this later) which brought the lost
> > hint.ppc.0.flags functionality back and applied the patch.
> > Now ppc attaches to puc without errors and which also is
> > confirmed by lpt:
> >
> > lpt0: <Printer> on ppbus0
> > lpt0: Interrupt-driven port
> >
> > (And, yes, I even printed a page with it ;-))
>
> Great! I've committed that fix to HEAD and will MFC.
Thanks!
>
> > I have no idea if this has ever worked before -- in FreeBSD-7 I
> > also had to use the "do not use interrupt"-flag 0x20 in loader.conf
> > or ppc wouldn't have attached...
> >
> > Which brings me back to the initial problem: Hints like
> >
> > hint.ppc.0.at=puc0
> > hint.ppc.0.irq=""
> > hint.ppc.0.flags=0x2F
> >
> > seems to be ignored in 9.1. While the interrupt thing seems
> > to be fixed now, one possibly still wants to used the other
> > flags. I have helped myself with this (ugly) patch to ppc
> >
> > --- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100
> > +++ ppc.c 2013-01-12 18:07:24.000000000 +0100
> > @@ -1729,6 +1729,11 @@
> > ppc->ppc_base = rman_get_start(ppc->res_ioport);
> >
> > ppc->ppc_flags = device_get_flags(dev);
> > + if( ppc->ppc_flags == 0 ) {
> > + int tmp;
> > + if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp)
> == 0 )
> > + ppc->ppc_flags = tmp;
> > + }
> >
> > if (!(ppc->ppc_flags & 0x20)) {
> > ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ,
> >
> > in order to get at least the flags applied as it was the case
> > before in FreeBSD-7. Unfortuantely, I have no idea how to fix
> > that properly ;-(...
>
> This should not be needed for "flags". Look for 'devflags' in
> sys/kern/subr_bus.c. The kernel always reads the current 'flags' hint during
> device probe and stores them in dev->devflags and leaves them there after a
> successful probe (so they should be seen by attach). Specifically, note:
>
> /* Set the winning driver, devclass, and flags. */
> if (!child->devclass) {
> result = device_set_devclass(child, best->driver->name);
> if (result != 0)
> return (result);
> }
> result = device_set_driver(child, best->driver);
> if (result != 0)
> return (result);
> resource_int_value(best->driver->name, child->unit,
> "flags", &child->devflags);
>
> This 'devflags' variable is what device_get_flags() returns. You should be
> able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no
> other hints meaning no "at", etc.)
Hmm, you are right. It now works even without my hackish patch.
Apparently, the "flags" hints (indicating that no interrupt
should be used) were not observed when I tried to use them to
work around the bug (which you fixed now). But after a
successful attach they are used and this is what's really
important.
Thanks for you help,
-Andre
_______________________________________________
freebsd-hardware@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org"
