Hi,
Jean Tourrilhes wrote:
> Michael Engel wrote :
> > I've recently started working on a Fast IrDA driver for the StrongARM
> > 1100/1110
> > CPUs (specifically Compaq's iPAQ).
>
> Great ! That's wonderful. Please go on !
>
> > While reading the code in drivers/net/sa1100_ir.c
>
> Where is this code available ? It's not in my standard
> kernel. Anyway, this could might rather be in
> drivers/net/irda/sa1100_ir.c...
Oops, sorry, you're correct ...
> > I stumbled across a few things I'd like to know - perhaps s.o. on this
> > list
> > can help me here:
> >
> > - in sa1100_irda_set_speed there is a case statement that should
> > (basically) select
> > SIR or FIR operation based on the baudrate passed as a parameter. This
> > function
> > is called from several places in the driver (suspend, resume etc.).
> > What interests
> > me is the sa1100_irda_ioctl function which should be the right place
> > to
> > control switching between SIR and FIR operation.
>
> Not only. I guess that when you reset the hardware, you want
> to put it in a consistent state.
Yep, of course.
> > Currently, sa1100_irda_set_speed always receives 9600 as speed
> > parameter. Is
> > there a way to access the ioctl from user mode (i.e. which device is
> > associated
> > when I'm not using irattach to bind IrDA to a serial port) ?
>
> The way IrDA work is that it always start at 9600. This is the
> speed used for discoveries and to establish LAP connections. Once the
> connection start, the 2 devices negociate the speed they want to use
> and each one set the speed on its interface.
> 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 ?
> By the way, it's quite easy to write a program opening the
> irda stub (via a socket) and passing ioctl to it. Sometimes the
> networking stack do filter out ioctls, so that's why it might not come
> to the driver. But (SIOCDEVPRIVATE + 2) should work fine. Look in
> iwpriv.c (Wireless Tools) some example on how to do that...
OK, in the meantime I also found this and can now successfully switch
between several baudrates with my tiny four-line program :-).
> > - Do you think it generally makes sense to integrate a SIR and FIR
> > driver in one
> > kernel module ? Autosensing for speed is not supported anyway AFAIK
> > and there's
> > not too much code in comon between the two drivers.
>
> The speed selection is changed dynamically by the IrDA stack
> (dependingon the negociation), and the IrDA stack doesn't support
> switching module on the fly when the speed change.
> 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.
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. 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.
> 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.
regards,
Michael
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
