hpoj-devel

[hpoj-devel] 2.4 kernel issues

[Burkhard K. <bu...@bu...>]

Hi everyone,

I tried to get hpoj-0.7 running with kernel 2.4.0-test12. I encountered
the same compiler errors someone else reported earlier to this list.
But after changing the ieee12844pp.c module accordingly (define 
PARPORT_CONTROL_DIRECTION, substitue parport_write_econtrol, and 
substitute queue_task(tq_scheduler) with schedule_task) I was not
able to run anything but ./hpo devid. ./hpo listpml would yield 
error -100 in mlcpp_intr and scanimage MLCError 7.

I thus tried to replace parport_write_econtrol with the original
code (outb(PAR_ECP_CONTROL_BIDIRECTIONAL 0x34, ECONTROL(l->port))
since using parport_write_control (as recommended by the original
poster) was not very sensible. This did not change the outcome.

With debugging turned on in ieee12844pp.o I see the following
log for ./hpo listpml:
	do_neg(c5067d9c,mode=0x04): in_1284=0, neg_mode=0x10.
	c5067d9c: event=2.
	c5067d9c: event=6.
	negotiate(c5067d9c,mode=0x04): rejected!
	mlcpp0: mlcpp_intr ERROR -100
	state=2 event=6 reset=1 recv=4 rcv=0 send=2
	do_neg(c5067d9c,mode=0x00): in_1284=1, neg_mode=0x04.
	c5067d9c: event=23.
	PAR_WAIT_SET_CLEAR(l=c5067d9c,set=0x0088,clear=0x0050):
		timed out waiting for event=23!

One further note on compiling the modules. The recommended compiler
for 2.4.0 kernels is now egcs 1.1.2. But with many distributions 
comes gcc 2.95.x. linux/Documentation/Changes strongly recommends
to use 2.95 with the -fno_strict_aliasing flag. I therefore suggest
to add an EXTRA_CFLAGS=-fno_strict_aliasing field to the makefile, 
which might be uncommented by gcc 2.95.x users.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] 2.4 kernel issues

[<pa...@rc...>]

Burkhard Kohl wrote:
> Somewhere between test8 and test12 the parport interface has changed
> substantially enough to break the ieee12844 modules.
> 
> I have tried to take care of this changes by adapting ieee12844pp.c
> and managed to compile with the patch appended. 
Hi, Burkhard.  Thanks for looking into this problem.  (I'm actually replying
to your earlier version of this message that didn't make it to the mailing
list.)

> But my compilate does not work properly:
> When I try ./hpo list_pml I get:
> 	IEEE1284.4 protocol layer for Linux installed
> 	ieee12844pp: init_module.
> 	mlcpp_attach: New device found on parport0
> 	ieee12844pp: IEEE1284.4 device found on parport0:
> 	HEWLETT-PACKARD OFFICEJET R40;
> 	device registered to IEEE1284.4 protocol layer as link mlcpp0
> 	mlcpp_attach: links: 1.
> 	parport0 (mlcpp): use data_reverse for this!
> 	do_neg(c9067d1c,mode=0x04): in_1284=1, neg_mode=0x04.
> 	c9067d1c: event=23.
> 	PAR_WAIT_SET_CLEAR(l=c9067d1c,set=0x0088,clear=0x0050):
> 	timed out waiting for event=23!
> 	mlcpp0: mlcpp_intr ERROR -110
> 	state=2 event=23 reset=1 recv=0 rcv=0 send=0
> 	do_neg(c9067d1c,mode=0x00): in_1284=1, neg_mode=0x04.
> 	c9067d1c: event=23.
> 	PAR_WAIT_SET_CLEAR(l=c9067d1c,set=0x0088,clear=0x0050):
> 	timed out waiting for event=23!
> 
> David, can you make sense out of these messages? Does it mean that
> I did not successfully set the ECR to bidirectional? 
It looks like it failed during the termination phase (event 23) of getting
the device ID string (do_neg(mode=0x04)), which is before it even attempts
to change the ECR.  The problem might have to do with the polling-timer
changes, because when it's waiting for a signal response from the
peripheral, it spins in a poll loop for a bit, then reschedules itself
in the task queue, which as you discovered has been changed.

> The message "use data_reverse for this!" stems from 
> parport_pc_write_control in the parport_pc module which means, that
> now an inline parport_pc_data_reverse() is calling parport_pc_frob_control()
> with the value of 0x20. This is just a cosmetical change but it 
> looks that the parport interface in future 2.4 kernels will change
> further and more breakage has to be expected. I have the feeling
> that ieee12844pp.c will need some redesign to work with 2.4.
All this madness of a constantly changing/breaking kernel interface is one
of many reasons why I'm trying to move towards a user-level driver approach.
I'm actively pursuing a solution to that problem at work, and if all goes
well (keep your fingers crossed!) I may be able to provide a solution in the
near future.  Of course, for now we should do what we can to fix the current
code just in case things don't work out in our favor.

> It looks
> that access to some parport registers is now considered lowlevel 
> enough to justify hiding it from driver developers.
I can understand removing direct register access from individual drivers,
but I can't understand not providing an alternative interface.

> A further note on compiling the kernel modules: egcs 1.1.2
> is now the recommended compiler. But on the other hand many 
> distributions supply users with gcc 2.95.2. Linux/Documentation/Changes 
> strongly recommends to use 2.95.x with the -fno-strict_aliasing option.
> I thus added EXTRA_CFLAGS to ieee12844/Makefile which has to be 
> activated by gcc 2.95.x users. Is there a way to handle this via 
> configure?
That shouldn't be a problem.

David

Re: [hpoj-devel] 2.4 kernel issues

[Tim W. <tw...@re...>]

On Sun, Dec 31, 2000 at 11:10:34AM -0800, David Paschal wrote:

> > It looks
> > that access to some parport registers is now considered lowlevel=20
> > enough to justify hiding it from driver developers.
> I can understand removing direct register access from individual drivers,
> but I can't understand not providing an alternative interface.

It's because of other architectures that don't even have those
registers.

Tim.
*/

Re: [hpoj-devel] 2.4 kernel issues

[Burkhard K. <bu...@bu...>]

Tim Waugh
> On Sun, Dec 31, 2000 at 11:10:34AM -0800, David Paschal wrote:
> 
> > > It looks
> > > that access to some parport registers is now considered lowlevel 
> > > enough to justify hiding it from driver developers.
> > I can understand removing direct register access from individual drivers,
> > but I can't understand not providing an alternative interface.
> 
> It's because of other architectures that don't even have those
> registers.
> 

Thanks Tim for commenting on this. I certainly see your argument.

I hope you don't mind if I ask you some questions, maybe you 
can help:

What would be the proper replacement for a statement like
      outb(PAR_ECP_CONTROL_BIDIRECTIONAL, ECONTROL(l->port));
when switching from ecp forward to reverse? Or is that now obsolete
because it could handled by the parport_pc module? Unfortunately
we can't use the ieee1284 functions.

From the parport driver sources I see that there is no BECP support 
for now - do you expect to have it in the near future? In ieee12844pp.c
there is actually only one event (41) referring to becp when switching
from ecp reverse to forward when the peripheral is idle.

Regards,

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] 2.4 kernel issues

[Tim W. <tw...@re...>]

On Thu, Jan 04, 2001 at 01:40:29AM +0100, Burkhard Kohl wrote:

> What would be the proper replacement for a statement like
>       outb(PAR_ECP_CONTROL_BIDIRECTIONAL, ECONTROL(l->port));
> when switching from ecp forward to reverse? Or is that now obsolete
> because it could handled by the parport_pc module? Unfortunately
> we can't use the ieee1284 functions.

(If you're not using the in-kernel parport support, why do you need to
replace it?)  parport_pc doesn't even use the ECR for this (rightly or
wrongly), it just does it by hand.

As I understand it, the reason you need to avoid the IEEE 1284
functions is to do with blocking.  Is that right?  In 2.4 there was a
new function 'parport_set_timeout' which was for handling this
requirement.

> >From the parport driver sources I see that there is no BECP support=20
> for now - do you expect to have it in the near future? In ieee12844pp.c
> there is actually only one event (41) referring to becp when switching
> from ecp reverse to forward when the peripheral is idle.

It's not something that there's ever been demand for; in fact, you're
the first person who's even mentioned it. :-)

Tim.
*/

Re: [hpoj-devel] 2.4 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> It looks like it failed during the termination phase (event 23) of getting
> the device ID string (do_neg(mode=0x04)), which is before it even attempts
> to change the ECR.  The problem might have to do with the polling-timer
> changes, because when it's waiting for a signal response from the
> peripheral, it spins in a poll loop for a bit, then reschedules itself
> in the task queue, which as you discovered has been changed.

I think the debug messages were a bit misleading. I resolved this
to be a failure during the transmit mode negotiation phase due 
to the parport being set to reverse mode. This can be cured by
inserting a 
	parport_data_forward(l->port);
statement just before the 
	parDataWrite(l, ...);
statement of event 0. (or inside the parDataWrite() function call).

It seems the initial state of the parport DIRECTION registers depends
on the hardware - that's why the other poster did not encounter
these probs.

Besides that I have learned a lot about parport transmit mode 
negotiation ;-) 

But now the driver runs into another problem - the peripheral answers
the hosts MLCConfigSocket command for socket 1 with MLCError 7 after
a succesful MLCInit/InitReply pair:

	mlcpp0: Got device ID string: <MFG:HEWLETT-PACKARD;MDL:OFFICEJET R40;CMD:MLC,PCL,PML,SCL;CLS:PRINTER;DES:Hewlett-Packard OfficeJet R40;CMT:OFFICEJET PRO;SERN:SGD98AH3MWWZ;VSTATUS:$HB0$FC0,ff,DN,IDLE,CUT;LSS:01;LDF:1;LDE:1;>
	mlcpp0: usebecp=0.
	do_neg(c9068320,mode=0x10): in_1284=1, neg_mode=0x04.
	put_ecp_byte(c9068320): byte=0xCE, cmd=1.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0xCD, cmd=1.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x03, cmd=0.
	s_idle(c9068320): Reverse data available.
	parport0 (mlcpp): use data_reverse for this!
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x09.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x80.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x03.
	mlc: configuring socket
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x0D, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x07, cmd=0.
	put_ecp_byte(c9068320): byte=0x01, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x06, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x06, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	s_idle(c9068320): Reverse data available.
	parport0 (mlcpp): use data_reverse for this!
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x08.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x7F.
	ecp_read_byte(c9068320): byte=0x07.
	mlc: mlcpp0: Got MLCError 07
	mlc_getsockopt: c411e134
	mlc_sendmsg: c411e134 credit=0, flags=0
	mlc_release: c411e134
	do_neg(c9068320,mode=0x00): in_1284=1, neg_mode=0x10.
	ieee12844pp: unregistering device at parport0 (link mlcpp0)

To me this seems to be a gross misunderstanding between host and
peripheral. From the specs I can't see no reason why this should
happen. 

For now I am rather clueless.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] 2.4 kernel issues

[Tim W. <tw...@re...>]

On Thu, Jan 04, 2001 at 01:05:42AM +0100, Burkhard Kohl wrote:

> It seems the initial state of the parport DIRECTION registers depends
> on the hardware - that's why the other poster did not encounter
> these probs.

Odd.  parport_pc should set it to forward when it initialises.

Tim.
*/