Michael Engel wrote :
> Jean Tourrilhes wrote:
> > In other word, it's only when another device will advertise a
> > speed higher than 9600 (assuming you do the same) that the IrDA stack
> > will ask you to set a speed greater than 9600. So get a Linux desktop
> > with a dongle or a laptop to exercise this functionality.
>
> But Fast IrDA is different, right ? Or is there any way to negotiate a
> Fast IrDA transfer from SIR mode ?
No, FIR is the same, it just adds a few more speed in the pool
of available speed. When you use FIR (1.1, 4 or 16 Mb/s), the
discovery and the initial LAP connection are still done at 9600.
Check net/irda/qos.c -> baud_rates[] for details.
In fact, some hardware offer a common interface to handle all
the speed, so you have only one piece of code. On the other hand, the
usual interface for SIR is a serial port, which is much simpler, but
this doesn't keep up with high speed. That may explain why you have
two separate interface to access IrDA.
> > On the other hand, remember that it's the same Ir transceiver
> > that is driven by both hardware path, so someone has to ensure
> > exclusion between the two paths. You also need to keep track of which
> > mode you are in (SIR/FIR) to know what to do when the IrDA stack ask
> > you to change the speed.
>
> Yep but that's no big problem as the speed is encoded in the status
> struct
> anyway. The ugly thing would be getting the IRQ handler to handle the
> correct speed without losing too many cycles.
The IrDA stack will tell you when to change speed and will
allow you some time to perform this operation (anyway, the hardware
need to be reconfigured which is not instantaneous). I think the
driver may even advertise its speed change delay.
So, while you are changing speed, you may change on-the-fly
the interrupt handler, and have two separate handler for SIR and
FIR. Tricky, but doable ;-)
> I can currently generate FIR transmit interrupts and they seem to work
> (I'm
> still searching for a FIR capable Linux machine, I thought my Toshiba
> Libretto
> 30 could do FIR but I didn't manage to get the toshoboe module loading -
> it always complains about device or resource busy.
Ask the maintainer of it.
> I'll have to try the G3
> Powerbook). But the iPaq definitely sends IR data out - I can check the
> IR intensity level with a tool on my Palm V.
>
> > As those two pieces of code will always been use together,
> > yes, it make sense to have them in the same module. But you can still
> > organise the code logically, for example by separating it in different
> > files. You may also create 2 sub-modules for each functionality
> > controlled by a meta-module (just entry point and dispatch).
>
> OK, I'll try to keep both modes together. The most complicated thing
> will
> probably be getting the DMA running as the IRQ load of running FIR
> without
> DMA will probably be a bit high.
Depend if its IRQ per character or per packet. If it's per
character, you are dead ;-)
> > Good luck !
>
> Thanks, so far things are looking good and the intel StrongARM docs are
> really great ... I hope I can find some time to continue hacking the
> driver
> over the weekend.
Good. Keep us posted, I'm really excited ;-)
> regards,
> Michael
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
