headers
Jochen Eisinger | 1 Feb 2004 11:45

ppSCSI driver suite for linux 2.6

Hi,

the ppSCSI drivers are used by SANE to access several scanner models.
Since some users are migrating to linux 2.6 now, there is a growing
demand for a ppSCSI patch for 2.6

I understand the the ppSCSI suite isn't maintained at the moment, and I
don't want to maintain it myself - due to the lack of time, and I don't
own such an adapter anyway. However, I modified the patch for linux 2.5
so it compiles with linux 2.6.1, and I will try to keep it up to date.

I'd be grateful to receive feedback on the patch, whether it works or
not, etc..

The patch is available from http://penguin-breeder.org/kernel/download/

kind regards
-- jochen
Permalink | Reply | 0 comments |
headers
Mark Thorp Duxbury | 2 Feb 2004 05:33

Shuttle EPST

Greetings,

Does anybody know whether anyone is maintaining the epst patch at all (even 
just a little bit)?  More specifically, has anyone ported it, or done any 
work on porting it, to the 2.6 series kernel?  Am I on my own?

Thanks,

Mark
Permalink | Reply | 0 comments |
headers
Ondrej Certik | 2 Feb 2004 15:10
Picon
Gravatar

ppSCSI driver suite for linux 2.6

Hello,

thanks to Jochen Eisinger for modifying the patch ppSCSI for kernel 2.6.
The patch has applied cleanly to 2.6.0 from debian unstable, compiled ok, 
and my Microtek Phantom 330 CX scanner is functioning allright. 
I only compiled and tested ppscsi and onscsi.

Ondrej Certik
Permalink | Reply | 0 comments |
headers
Michael Kastner | 4 Feb 2004 18:05
Picon
Picon

EPP mode for PCI interface card

Hi everyone,

I am trying to access a PCI parallel port card (Netmos 9805CV chip) directly
from RTLinux in hardware EPP mode. The device that I want to control is a
CCD line camera. However, it seems like the EPP handshake doesn't really work
well. Each byte I read from the camera is repaeted a couple of times before
the value changes. Also there is no difference in the time needed for the
transfer wether I have the camera connected or not (the timeout bit isn't set in
this case either).
Doing the same thing with the builtin parallel port works as expected.
Another problem is that when I turn the cameras power off and on again in
EPP mode (only when connected to the PCI card), the whole system freezes.
Here is my initialization code:

...
/* switch to epp mode */
outb_p(0x00, port_hi + 2); /* switch back to mode 0 */ outb_p(0x84, port_hi
+ 2); /* epp mode, no interrupts */ ...

...
/* write to camera */
outb_p(0, port + 2); /* direction write */ outb(c->controlByte, port + 4);
outb(c->timerByte, port + 4); ...
/* read from camera */
outb_p(0x20, (*c).port + 2); /* direction read */
c->ioIn = inb(port + 4);
for (i = 0; i < DESIGNATION_LENGTH; i++)
  c->designation[i] = inb(port + 4);
...
(Continue reading)

Permalink | Reply | 0 comments |
headers
vdb128 | 7 Feb 2004 02:09

EPP mode for PCI interface card

Netmos chips NOR interrupt conditions to the PCI INTX# line, irrespective 
of the selected mode.  To disable all interrupts/EPP, you need to write 0x94 
to the ECR.  This masks the nFault/nError line from your camera and should 
solve the lockups.

Best regards
Permalink | Reply | 0 comments |
headers
Mark Hounschell | 8 Feb 2004 20:02
Picon

LPTIME?

I can't seem to make the LPTIME ioctl to /dev/lp0 do what the
documentation says it's supposed to do. If I'm understanding the doc
correctly,

  Set the amount  of time in jiffies that the driver waits
  if the printer doesn't take a character in the number
  of tries dictated by the LPCHAR ioctl

After looking through the kernel sources for my problem, in particular
ieee1284_ops.c parport_ieee1284_write_compat routine, I would expect
this LPTIME ioctl to affect the 
dev->timeout used in this routine. After inserting some printks in the
module, it doesn't seem to. 

I'm writting some software that will be using some old dataproducts line
printers. I'm using a centronics-to-dataproducts adapter. As long as I
don't use the LPABORT ioctl I don't get any timeouts. As soon as I
enable aborts on writes via the LPABORT ioctl I get timeouts when ever I
send a FF (0x0c) or LF (0x0a) char followed by anything else.
The parport_ieee1284_write_compat routine times out waiting for the
Form-Feed or Line-Feed from the previous byte to complete.

The data streams I have to send to these printers are text only with
normal CR, LF, and FF's in the data stream.

I've manually modified the above routine by setting the value of
dev->timeout to 1000, which appears to be the value used when I don't
use the (LPABORT, TRUE) ioctl. Then all works ok. No timeouts. When I
use the (LPABORT, TRUE) ioctl the valu of dev->timeout is 1. When I use
the (LPABORT, FALSE) it ends up being 1000. ?????
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Kastner | 7 Feb 2004 18:48
Picon
Picon

Re: EPP mode for PCI interface card

> Netmos chips NOR interrupt conditions to the PCI INTX# line, 
> irrespective of the selected mode.  To disable all interrupts/EPP, you 
> need to write 0x94 to the ECR.  This masks the nFault/nError line from 
> your camera and should solve the lockups.

Thanks a lot!
That indeed solved the annoying lockup problem.
The EPP protocol itself still doesn't work properly.
I emulated EPP in SPP mode, setting the required lines one by one.
This works without problems - but it is very slow (4ms for 1100 bytes).

Regards,
  Michael

--

-- 
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Permalink | Reply | 0 comments |
headers
Eric BENARD / Free | 9 Feb 2004 11:24
Picon
Favicon

Parport signals stability with SiS chipset

Hi !

I'm trying to get a small jtag software to run under Linux and I meet problems 
with the parallel port :
- on two PC (a Dell Intel based Notebook and an Asus VIA/AMD based), 
everything is ok, I can write and read correct data to the board (an ARM7 
cpu)
- on the other PC (Asus Pundit with SiS651/962 chipset & Celeron4 CPU), the 
parport IO are always swinging so data gets corrupted.

Both PC have the same settings (SPP). I tried with 2.4.23 & 2.6.1 & 2.6.2 
kernels on the Asus without any success.

I quickly tested on a SiS630 PC and I have the same problems than on the 
Pundit, so this could come from a problem with the SiS chipset handling 
parport.

Of course, I checked that no other software was trying to use the parport. I 
unloaded lp, and only ppdev is loaded.

The problem is the same if I try to access the parport directly (io  <at>  0x378) 
or through ppdev (/dev/parport0).

Here is the schematic used for the JTAG adapter : 
http://axl.freeyellow.com/iPAQ/xilinx-DLC5-pp2jtag.pdf

Do you have an idea of what could be wrong ? Or maybe where I should look to 
get more details and solve this problem ?

Many thanks for your help & best regards
(Continue reading)

Permalink | Reply | 6 comments |
headers
Oscar Díaz | 10 Feb 2004 18:42
Picon

PLIP support

Hi, list

I'm looking info about plip, because I need another fast and cheap connection (I already have some ethernet
cards). But when I saw in <kenrel-source>/Documentation/networking/PLIP.txt that only "Parallel
Transfer Mode 0" are supported in the kernel source, and both machines have bi-directional parallel
ports; so I want to use "Parallel Transfer Mode 1". After, I read the plip source code, and there only have
support for mode 0. Where can I get support for this transfer mode? Any patch?

Thanks... Oscar
Permalink | Reply | 0 comments |
headers
mike dillon | 14 Feb 2004 21:49

EPP mode on SIIG Cyberparallel PCI

Hello-

I just bought a Cyberparallel PCI card from SIIG to get an EPP-capable
parallel port on a new legacy-free motherboard. My goal is to use it to
drive an old UMAX parallel-port scanner.

The problem is that the port is not being recognized as supporting EPP.
I am attempting to use the card under the 2.6.2-1.74 kernel from Fedora
Core development.

Here is the output of `lspci -vvv` for the card:

0000:03:05.0 Parallel controller: Siig Inc CyberParallel (1-port) (prog-if 02 [ECP])
        Subsystem: Siig Inc CyberParallel (1-port)
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 4
        Region 0: I/O ports at 8800
        Region 1: I/O ports at 8c00 [size=4]
        Capabilities: [a0] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Here is the parport driver output from dmesg:

PCI parallel port detected: 131f:2020, I/O at 0x8800(0x8c00)
parport0: PC-style at 0x8800 (0x8c00) [PCSPP,TRISTATE]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane