numbering TTP credits rules

I'm an embedded system engineer in Japan.

By using Linux command ircp + lib OpenObex, I transfered a file  between my
Knoppix4.0 based Linux box with IRDA-USB dongle and PDA (Sony Clie).
Process during this transmission is recorded by irdadump.

There is one following question about TTP credits.
Could anyone answer the question?

Question:
What rules is applied to set the value of TTP credits in the flame ?

The following is monitoring results.

=== monitoring results ===
01:05:38.623229 xid:cmd ffffffff < 1be25a10 S=6 s=0 (14)
01:05:38.706404 xid:cmd ffffffff < 1be25a10 S=6 s=1 (14)
01:05:38.796309 xid:cmd ffffffff < 1be25a10 S=6 s=2 (14)
01:05:38.878335 xid:cmd ffffffff < 1be25a10 S=6 s=3 (14)
01:05:38.966043 xid:cmd ffffffff < 1be25a10 S=6 s=4 (14)
01:05:38.966194 xid:rsp d9a81d43 > 1be25a10 S=6 s=4 Knoppix hint=8420 [
Computer IrOBEX ] (24)
01:05:39.086245 xid:cmd ffffffff < 1be25a10 S=6 s=5 (14)
01:05:39.162273 xid:cmd ffffffff < 1be25a10 S=6 s=* TanakaClie hint=8220 [
PDA/Palmtop IrOBEX ] (28)
01:05:39.192273 snrm:cmd ca=fe pf=1 d9a81d43 < 1be25a10 new-ca=5e
     LAP QoS: Baud Rate=115200bps Max Turn Time=500ms Data Size=512B Window
Size=1 Add BOFS=0 Min Turn Time=5000us Link Disc=40s (32)
01:05:39.192891 ua:rsp ca=5e pf=1 d9a81d43 > 1be25a10
     LAP QoS: Baud Rate=9600bps Max Turn Time=500ms Data Size=2048B Window

IRDA bugs in bugzilla

I was doing a bugzilla summary of network driver bugs, the following need
to be looked at and fixed, resolved, closed?

http://bugzilla.kernel.org/show_bug.cgi?id=2708

http://bugzilla.kernel.org/show_bug.cgi?id=3048

http://bugzilla.kernel.org/show_bug.cgi?id=3073

http://bugzilla.kernel.org/show_bug.cgi?id=3373

http://bugzilla.kernel.org/show_bug.cgi?id=3524

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: numbering TTP credits rules

h_tanaka wrote :
> 
> Question:
> What rules is applied to set the value of TTP credits in the flame ?

	You can set pretty much whatever you like, up to the maximum,
the IrDA standard doesn't put any requirement on you.
	 The TTP credits are used for flow control, the other end will
only send as many packets as the number of credits you sent it, and
sending 0 credit makes sure you won't receive any packets. So,
reastically, this is link to the amount of receive buffers you have
available.
	Note that credits are differential, when you send N credits,
it adds to the credits you have previously sent. And they are
automatically decremented each time one sends a frame.

> 01:05:39.342978 i:cmd  < ca=5e pf=1 nr=2 ns=2 LM slsap=02 dlsap=1a CONN_CMD
> TTP credits=1 (7)
> 01:05:39.343644 rr:rsp > ca=5e pf=1 nr=3 (2)
> 01:05:39.373221 rr:cmd < ca=5e pf=1 nr=2 (2)
> 01:05:39.373270 i:rsp  > ca=5e pf=1 nr=3 ns=2 LM slsap=1a dlsap=02 CONN_RSP
> TTP credits=16 (7)

	The first thing is to check the initial number of credits,
because everything else will be relative to that.
	The phone is very careful, it send only 1 credits, which means
that it has enough receive buffer to only receive one packet.
	Linux is more flexible, it allow the phone to send up to 16
packets.

Re: numbering TTP credits rules

Dear Jean;

Your reply is very helpful to me.

>The TTP credits are used for flow control, the other end will
>only send as many packets as the number of credits you sent it, and
>sending 0 credit makes sure you won't receive any packets.

After my previous posting, I reffered the TinyTP specification and some
document that can be found in following Website.

"Modelling and Optimizing TinyTP over IrDA Stacks"
decweb.bournemouth.ac.uk/staff/ phuang/publications/TinyTP_Eurasip.pdf

TinyTP specification says
DeltaCredit Specifies the number (0-127) of additional Data-Carrying Data
TTP-PDUs that may be sent in the reverse direction.

InitialCredit Specifies the initial number (0-127) of Data-Carrying Data
TTP-PDUs that may be sent in the reverse direction.

Above paper says
TinyTP adds one byte of header carrying information including its own
buffer size and the segmentation status.

These quotations support what you say.

Thank you

[donauboe] problems loading module on toshiba 110ct

Hi *!

I'm having troubles insmod the donauboe FIR module with 2.6 kernels on
the Toshiba Libretto 110. Currently 2.6.15-ck1, but also version 2.6.xx
seem to do not work. Have never tried loading the module on early than
2.6.12 kernels -- however, it has been told 2.4 is ok. Here's the dmesg 
output when doing modprobe donauboe (irda and crc-ccitt get loaded too).
ioports, irqs and lspci below.

[dmesg]
NET: Registered protocol family 23
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKC] -> GSI 11 (level,
low) -> IRQ 11
toshoboe: can't get iobase of 0xffe0
donauboe: probe of 0000:00:11.0 failed with error -16

[/proc/ioports] 
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0330-0331 : MPU401 UART

Re: [donauboe] problems loading module on toshiba 110ct

Also sprach Richard Mittendorfer <delist@...> (Thu, 19 Jan 2006
10:56:14 +0100):
> I'm having troubles insmod the donauboe FIR module with 2.6 kernels on
> the Toshiba Libretto 110. Currently 2.6.15-ck1, but also version
> 2.6.xx seem to do not work. Have never tried loading the module on
> early than 2.6.12 kernels -- however, it has been told 2.4 is ok.
> Here's the dmesg  output when doing modprobe donauboe (irda and
> crc-ccitt get loaded too). ioports, irqs and lspci below.
> [...]

[update] It successfully loads without ACPI turned on. May be some DSDT 
flaw. I tried a custom DSDT from acpi.sourcefoge.net -- unfortunately 
without success.

sl ritch

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: stir4210 device

Hi

(sorry for not replying - was not receiving the list last September)

Just wanted to contribute, that at 
http://althaia.across.sk/~naiki/linux/index.html there's a port of the 
driver from Sigmatel for 2.4 to 2.6 by Naiki (my Czech is not too good, 
but I do think he was the author, as follows from 
http://www.abclinuxu.cz/forum/show/81434). After applying the patch below 
it also works quite well, apart from one thing: similar to 2.4 kernel we 
have a problem when some disturbances come while in FIr mode. We test with 
a PPP connection to another Linux system in FIr mode with 4mbps. As the 
connection gets lost, the parties switch back to SIr 9600, but even before 
that still in FIr __sometimes__ the 4210 seems to just stop reacting to 
USB requests to the bulk emdpoinds. Here is a snipplet from the usbmon 
under 2.6.15:

dd5bc9c0 503711873 S Bi:003:02 -115 2324 <
dd5bc9c0 503715872 C Bi:003:02 0 1512 = 0000000a 161f1000 ff030021 450805dc 8fd54000 40068b3a 0a010301 0a010302

(Here it still works - you see data comming from a bulk-in (Bi above) 
endpoint. I was doing an ftp get)

dd5bc940 503715873 S Bi:003:02 -115 2324 <
dd5bcac0 503715885 S Bo:003:01 -115 64 = 0000050b 90101f02 ff030021 45080034 6a544000 4006b663 0a010302 0a010301
dd5bcac0 503716874 C Bo:003:01 0 64 >
dd5bc940 503721872 C Bi:003:02 0 1512 = 0000000a 281f1001 ff030021 450805dc 8fd64000 40068b39 0a010301 0a010302

(Here it still works too, you see a bulk-in request, bulk-out 
request-response and a bulk-in response)

Re: [PATCH2.6] nsc-ircc to platform device + suspend/resume redo

Hi Rudolf,

Rudolf Marek <r.marek <at> ...> writes:

> I would like to know if I need to call .._change_speed
> even when the device was down to provide some defined state
> of those registers, I'm setting speed to 9600.
I don't think it is necessary, since it will be overwritten when the interface
will be brought up.
If the interface is up, it's probably a safe bet to call change_speed() with the
current speed, which is what you do.

> diff -Naur a/drivers/net/irda/nsc-ircc.c b/drivers/net/irda/nsc-ircc.c
> --- a/drivers/net/irda/nsc-ircc.c	2005-12-19 01:36:54.000000000 +0100
> +++ b/drivers/net/irda/nsc-ircc.c	2005-12-23 22:31:58.000000000 +0100
>   <at>  <at>   -158,12 +172,20   <at>  <at>  
>  {
>  	chipio_t info;
>  	nsc_chip_t *chip;
> -	int ret = -ENODEV;
> +	int ret;
This is useless, since you're setting it to -ENODEV later on.

>  	int cfg_base;
>  	int cfg, id;
>  	int reg;
>  	int i = 0;
> -
> +        
> +	ret = platform_driver_register(&nsc_ircc_driver);                          

STLabs 4220 dongle problem

[patch] off-by-one error in irattach.c

Hello list.

a bugreporter found an off-by-one error in irattach/irattach.c line 671.
I included a trivial fix for this.

Stefan