[irda-users] Re: Problems with incoming connections

[Jean T. <jt...@bo...>]

Martin Diehl wrote :
>  On Mon, 30 Sep 2002, Daniele Peri wrote:
>  
>  > > 	One of the "particularity" of the SMC driver is that it wrap
>  > > around irport for all SIR operation. So, most often, you end up using
>  > > code in irport.c, not in smc-ircc.c.
>  > I know. That's why I got rid of irport and wrote a brand new driver for 
>  > smsc-ircc. Now I have just a module to cope with. By now it just work 
>  > exactly as the old couple irport & smc-ircc but I can easier control how 
>  > it is working. I plan to add some more functionalities to my module so 
>  > if there isn't anyone else interested in it I could take care of the 
>  > smsc-ircc driver maintenance.
>  
>  Well, I'm not using smc-ircc, but this sounds like very good news for
>  quite a number of people! Note that I am (was) somewhat concerned with my
>  partial irport rewrite/unification with irtty because smc-ircc used to
>  rely on irport. Sure, given smc-ircc being the only one we could just
>  bundle existing irport with smc-ircc to keep it working (well, "as is",
>  you know ;-) but this wouldn't bring any progress to smc-ircc. So if you
>  plan to submit a rewritten smc-ircc independent from current irport this
>  would be helpful for both sides, I believe.

	Yes, this is great news, as many laptops use this chipset
(including Compaq ;-). As mentionned on my web page, I would really
apreciate if someone could be maintainer of smc-ircc, and you seems to
be a good candidate.
	To start with, we probably could keep the old smc-ircc around
(like I was supposed to do with toshoboe before getting delayed by
other stuff). That would allow to "fast track" the driver to the
kernel (compared to other IrDA changes).

	Note that in 2.5.X, I did some cleanup of the locking and
other minor issues in irport and smc-ircc. You may want to grab 2.5.39
and look at my changes (but not apply them blindly). Also, a look at
the new "serial.c" (i.e. 8550.c) would help make the irport part
better.
	Also, I wonder if you Toshsat1800-irdasetup could not become
an optional part of the new smc-ircc, but I don't really know what I'm
talking about here.

>  Note that I am (was) somewhat concerned with my
>  partial irport rewrite/unification

	Now that 2.5.39 contains a IrDA stack that is "usable", the
irtty rewrite has become priority number one. Currently, I'm taking
time for other stuff (Obex, ...), so wake me up when you feel that
your code should be merged.

>  > > 	The difference between incomming and outgoing connections, as
>  > > far as speed change are concerned, is that outgoing speed changes are
>  > > done with a extra zero byte frame, while incomming speed change are
>  > > done by piggybacking the new speed on the "ua:rsp".
>  > 
>  > I realized it. But my question is why all this works fine with nsc-ircc 
>  > (Am I right?)... Interrupt management is different there though.
> 
>  AFAICS recent nsc-ircc has all the stuff to deal with this situation. Some
>  (most?) other drivers are probably questionable, IMHO. Of course the
>  driver also needs to stop the queue to prevent the stack from sending more
>  frames while the speed change is pending and some spin_lock_irqsave() for
>  correct serialization with the interrupt handler.

	I believe nsc-ircc does it right, at least for FIR
operation. Note that Martin and me are talking about the version in
2.5.39, the version in 2.4.X still has a few bugs in this departement.

>  > By now I'm guessing it's something related to the interrupt context or 
>  > routing. I'll make some specific tests.

	With nsc-ircc, the interrupt mask was set wrong after some
speed changes. Check the diff between 2.4.X and 2.5.X (those diffs are
on my web page as well).
	But, you may have other issues...

>  > Irtty already works fine with my chipset but I don't like it very much 
>  > and not just because it doesn't support FIR.

	That's exactly the point, irtty just works.

>  > Lucky as I am, the only FIR-like device I hold is my buggy T39m with its 
>  > MIR mode ;-). I'll make some test with FIR capable laptops soon but I 
>  > would like to circumvent T39m bugs as other operating systems seems to 
>  > do :-( Any pointer?

	There are patches for T39 bugs on my web page ("handle invalid
QoS" and "chat over IrCOMM" - don't forget to set max_tx_window to
1). Send the logs, and we'll fix this T39 for good.
	Most laptop are either nsc-ircc or smc-ircc and FIR capable,
so if you pick another laptop at random, even old, it should be
good. I also know that Martin is using a IrDA-USB dongle.

>  >  > 	Buona fortuna...
>  > Good italian... ;-)

	E colpa della mia mogie, queste donne italiane sono veramente
irresistibile...

	Jean