IrDA speed w/LinuxPPC: again [long, sorry]

I still had no success in changing the speed of the IrDA if on my Apple
PowerBook 1999 with Linux2.2.17pre20-ben3. To understand better what goes on, I
enabled all debugging in the macserial and irda drivers, adding/expanding some
more messages to the latter ones.

I first successfully tried to change the speed of the serial device to 115.2
kBd:

kernel: rs_open ttyS1, count = 0
kernel: startup() (ttyS1, irq 16)
kernel: starting up ttyS1 (irq 16)...
kernel: ttyS01: powering up hardware
kernel: setting up ttys1 SCC...
kernel: set speed to 4800 bds, <6>8 bits, <6>1 stop, <6>timeout=3/100s, base:0
kernel: enabling IRQ on ttyS1 (irq 16)...
kernel: rs_interrupt: irq 16, zs_intreg 0x1
kernel: rs_interrupt: irq 16, zs_intreg 0x0
kernel: rs_open ttys1 successful...
kernel: set speed to 115200 bds, <6>8 bits, <6>1 stop, <6>timeout=3/100s, base:0
kernel: rs_close ttys1, count = 1
kernel: waiting end of Tx... (timeout:3000)
kernel: waiting end of Rx...
kernel: Shutting down serial port 1 (irq 16)....
kernel: ttyS01: shutting down hardware

Then, I started the IrDA stuff:

kernel: IrDA (tm) Protocols for Linux-2.2 (Dag Brattli)
[...]
kernel: IrCOMM protocol (Dag Brattli)
kernel: rs_open ttyS1, count = 0
kernel: startup() (ttyS1, irq 16)
kernel: starting up ttyS1 (irq 16)...
kernel: ttyS01: powering up hardware
kernel: setting up ttys1 SCC...
kernel: set speed to 115200 bds, <6>8 bits, <6>1 stop, <6>timeout=3/100s, base:0
kernel: enabling IRQ on ttyS1 (irq 16)...
kernel: rs_interrupt: irq 16, zs_intreg 0x1
kernel: rs_interrupt: irq 16, zs_intreg 0x0
kernel: rs_open ttys1 successful...
kernel: set speed to 9600 bds, <6>8 bits, <6>1 stop, <6>timeout=3/100s, base:0
kernel: hashbin_insert()
kernel: enqueue_first()
kernel: IrDA: Registered device irda0
irattach: 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli
irattach: 1.1 Tue Nov  9 15:30:55 1999 Dag Brattli
test: irattach startup succeeded
irattach: executing: 'echo 1 > /proc/sys/net/irda/discovery'
kernel: rs_open ttyS1, count = 1
kernel: startup() (ttyS1, irq 16)
kernel:  -> already inited
kernel: rs_open ttys1 successful...
kernel: rs_close ttys1, count = 2
irattach: Starting device irda0
[...]

Obviously, IrDA sets the speed of the associated tty device back to 9.k kBd. I
tried to change the speed of /dev/ircomm0 with a stty command, which gave the
following result:

[...]
kernel: ircomm_tty_do_event: state=IRCOMM_TTY_IDLE,
event=IRCOMM_TTY_ATTACH_CABLE
kernel: ircomm_tty_state_idle: state=IRCOMM_TTY_IDLE,
event=IRCOMM_TTY_ATTACH_CABLE
kernel: ircomm_tty_next_state: next state=IRCOMM_TTY_SEARCH, service type=6
kernel: irlmp_discovery_confirm()
kernel: ircomm_tty_block_til_ready()
kernel: ircomm_tty_block_til_ready(), O_NONBLOCK requested!
kernel: ircomm_tty_ioctl(cmd 1076655123 w/arg 0x7ffff818)
kernel: ircomm_tty_ioctl: ioctl 1076655123 = 0x402c7413     ##
kernel: ircomm_tty_ioctl(cmd -2144570347 w/arg 0x7ffff8e8)
kernel: ircomm_tty_ioctl: ioctl -2144570347 = 0x802c7415     ##
kernel: ircomm_tty_wait_until_sent()
kernel: ircomm_tty_set_termios()
kernel: ircomm_tty_change_speed()
kernel: ircomm_tty_change_speed 115200 baud
kernel: ircomm_tty_change_speed request 115200 baud
kernel: ircomm_param_request()
kernel: ircomm_param_data_rate(), data rate = 115200
kernel: irda_insert_integer(), pi=0x10, pl=4, pi=115200
kernel: ircomm_param_request(), skb->len=6
kernel: ircomm_param_request()
kernel: irda_insert_integer(), pi=0x11, pl=1, pi=318767104
kernel: ircomm_param_request(), skb->len=9
kernel: ircomm_param_request()
kernel: ircomm_param_flow_control(), flow control = 0x00
kernel: irda_insert_integer(), pi=0x12, pl=1, pi=0
kernel: ircomm_param_request(), skb->len=12
kernel: ircomm_tty_do_softint()
kernel: ircomm_tty_ioctl(cmd 1076655123 w/arg 0x7ffff818)
kernel: ircomm_tty_ioctl: ioctl 1076655123 = 0x402c7413     ##

I think there are two interesting things to remark:

1. The new speed is inserted in some sort of "command queue". I think
   ircomm_tty_ioctl is called to set some, maybe these, parameters, but the cmd
   arg of this function seems to be invalid, as EACH call falls through to the
   "default" branch (lines maked with "##"; cmd printed). I could not track down
   where this ioctl is actually called, but cmd is definitely NO valid tty
   ioctl.

2. This may be a result of the ioctl above, but the macserial speed change is
   never called.

Any help or comment on this is really welcome!

Thanks in advance, Albrecht.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Albrecht Dreß wrote:

I still had no success in changing the speed of the IrDA if on my Apple
PowerBook 1999 with Linux2.2.17pre20-ben3. To understand better what goes on, I
enabled all debugging in the macserial and irda drivers, adding/expanding some
more messages to the latter ones.

I first successfully tried to change the speed of the serial device to 115.2
kBd:

[snip the long story]

Any help or comment on this is really welcome!

Thanks in advance, Albrecht.

Part of what you are seeing is the working of the IrDA spec. Everything
starts at 9600baud to negotiate a connection. Part of this negotiation
is the speed it will switch to when a connection is established. This
appears to to be working. It is pointless to preset your tty speed. I
don't know where the cmd garbage is coming from.
Garst

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

"Garst R. Reese" wrote:

Part of what you are seeing is the working of the IrDA spec. Everything
starts at 9600baud to negotiate a connection. Part of this negotiation
is the speed it will switch to when a connection is established. This

Does this mean that I do not have any chance to change the speed after the
device is found? I tried a "stty -F /dev/irlpt0 115200" after the printer was
discovered, but there is no hint at all in the debug logs that this command got
through.

The following extract from the debug messages seems to be the establishing of
the connection to the printer, right? Why does it set the baud rate to zero? Is
it possible to get more details of the negotiation process to see if there is
something weird going on?

kernel: irlap_initiate_connection_state()
kernel: irda_param_extract(), pi=[0,1], type=0
kernel: Requested BAUD_RATE: 0x0000
kernel: Final BAUD_RATE: 0x0000
kernel: irda_param_extract(), pi=[1,2], type=1
kernel: irda_param_extract(), pi=[1,3], type=1
kernel: irda_param_extract(), pi=[1,4], type=1
kernel: irda_param_extract(), pi=[1,5], type=1
kernel: irda_param_extract(), pi=[1,6], type=1
kernel: irda_param_extract(), pi=[0,8], type=1
kernel: LINK_DISC: 07
kernel: Final LINK_DISC: 07
kernel: irlap_qos_negotiate(), Compression not seen!
kernel: irlap_adjust_qos_settings()
kernel: irlap_max_line_capacity(), speed=0, max_turn_time=500
kernel: irlap_max_line_capacity(), line capacity=200000 bytes
kernel: Setting BAUD_RATE to 0 bps.
kernel: Setting DATA_SIZE to 256 bytes
kernel: Setting WINDOW_SIZE to 1
kernel: Setting XBOFS to 0
kernel: Setting MAX_TURN_TIME to 500 ms.
kernel: Setting MIN_TURN_TIME to 10000 usecs.
kernel: Setting LINK_DISC to 12 secs.
kernel: Setting COMPRESSION to 0
kernel: irlap_apply_connection_parameters()
kernel: irlap_change_speed(), setting speed to 0
kernel: irlap_max_line_capacity(), speed=0, max_turn_time=500
kernel: irlap_max_line_capacity(), line capacity=200000 bytes
kernel: Setting N1 = 6
kernel: Setting N2 = 24
kernel: async_wrap_skb(), xbofs=0
kernel: rs_interrupt: irq 16, zs_intreg 0x2
kernel: rs_interrupt: irq 16, zs_intreg 0x0
kernel: next LAP state = LAP_NRM_P
kernel: irlap_connect_confirm()

Thanks, Albrecht.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/