Date: Sun, 14 Feb 1999 20:25:36 +0100 From: Nicolas Souchu <nsouch@teaser.fr> To: Chuck Robey <chuckr@mat.net> Cc: freebsd-current@FreeBSD.ORG Subject: Re: New print interface Message-ID: <19990214202536.07924@breizh.prism.uvsq.fr> In-Reply-To: <Pine.BSF.4.05.9902141309290.340-100000@picnic.mat.net>; from Chuck Robey on Sun, Feb 14, 1999 at 01:16:11PM -0500 References: <19990214190015.52233@breizh.prism.uvsq.fr> <Pine.BSF.4.05.9902141309290.340-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 14, 1999 at 01:16:11PM -0500, Chuck Robey wrote: >> >ppc0 at 0x378 irq 7 drq 3 on isa >> >ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode >> >ppc0: FIFO with 16/16/15 bytes threshold >> >ppb0: IEEE1284 device found /NIBBLE/ECP >> >Probing for PnP devices on ppbus0: >> >ppbus0: <HEWLETT-PACKARD DESKJET 690C> MLC,PCL,PML >> >plip0: <PLIP network interface> on ppbus 0 >> >lpt0: <generic printer> on ppbus 0 >> >lpt0: Interrupt-driven port >> >ppi0: <generic parallel i/o> on ppbus 0 >> >lppps0: <Pulse per second Timing Interface> on ppbus 0 >> > >> >Notice how the ppbus finds and correctly IDs my printer (yea!) but then >> >the lpt0 and ppi0 lines find generic ... this is a little odd, isn't it? >> >Even if the lpt0 and ppi0 parts are less intelligent, they should share >> >info to at least some degree, shouldn't they? >> >> i/o is generic here. > >If IO is generic, then printing the type of printer it finds is >meaningless, right? It's going to announce "generic" no matter what, >then it should stay silent, right? Better to say nothing than to get it >wrong every time, especially with the correct info sitting mere lines >above, advertising the mistake. ppi and lpt are really different. ppb probe and lpt too; and finally, ppb probe and ppi are quite different also ;) The ppbus architecture is made of an interface layer (ppc), a mid level (ppbus or ppb) and a device level (lpt, ppi, pps..). ppc does the chipset detection, here you have an SMC chipset, and properly configure it respecting the SMC datasheets. Not usual for a parallel port chip ;) It also detect ECP FIFO and test it. Then it calls the ppb level power_up routine. During ppb level power_up, the parallel port bus is probed, trying to find out an IEEE1284 device and only one (further developments could be made to find _every_ IEEE1284 devices daisy chain to the port, thanks to the IEEE1284-3 standard). IEEE1284 devices shall have an device_id feature that let the host retrieve identification info from them. This is referenced as the NIBBLE_ID mode. Once done, the ppb level initializes every device it knows about. lpt have been there before any IEEE1284 support. Actually, lpt _is_ the old lpt driver with machine-independent calls to the ppc interface and some request/release calls to the bus to allow bus sharing with a ZIP or what else. That's why lpt support is generic. No matter with the previous probe. IEEE1284 support is only a set of functions any device driver may call to take advantage of it. Actually, lpt uses it since recently. When you do a 'cat /dev/lpt0', it tries to negocition NIBBLE mode with the printer and fetch data if the peripheral has some. Yours doesn't seem to. But I'm not sure, since I know some peripherals fails to say they have/dont_have data to send. You should really dig into this with DEBUG_1284 option enabled. Since there are things specific and things that are not, I prefered to differenciate it in the past. But you're probably rigth, only this printer driver may ever exist. Look at the ppbus(4) architecture, the ppi code and tell me if I shall change the boot outputs. > >> >2nd note ... you said I should use lptcontrol -e. I did that, exactly, >> >and it came back to tell me that it had switched me to extended mode >> >(which I expected) AND to polled mode (which I neither expected nor >> >wanted). The man page says that only one action is taken at a time. I >> >was able to switch on the interrupt mode again (which I did want) by >> >using the -i switch (advertised correctly on the man page now) but isn't >> >this wrong, switching to polled mode like that on entering the -e? >> >> Hmm, yes. It is interrupt driven tough. > >Then the lptcontrol command should not announce, when you enter >'lptcontrol -e' that it's setting polled mode (which it did). If it's >still in interrupt mode (which is good) then it's fibbing to me, right? > I agree. But it was to simple ;) >> >> But, can you print with extended mode set?! > >I can't cat /dev/lpt0 and get any status. I did the lptcontrol -e, so I >*think* I;m in extended mode, and it *does* print. I guess I have to ^^^^^^ Ahhhh! Try, DEBUG_1284 to see what happen with lpt read. >find out what I can buy to play with this further. I would like to have >some logic level outputs, so I can do some direct machine control, and >doing it via my printer port sounds cool. Know anything like that? > >Having my computer be my alarm clock would be neat. I have 5 different >wakeup times (because of odd class schedules) and that would, in fact, >be a real nice win. A better idea would be to do it with I2C. Which I also promote in FreeBSD ;) See http://www.freebsd.org/~nsouch/iicbus.html > > If true, imagine you use >> DMA+FIFO when printing! If not convinced, enable PPC_DEBUG when compiling >> i386/isa/ppc.c. > >OK, experimenting. > >What about 'cat /dev/lpt0' doing nothing? Am I doing that right? What >did you expect me to see, when you asked that? DEBUG_1284. -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990214202536.07924>