Michael Engel wrote :
> Hi,
>
> 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...
> 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.
> 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.
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...
> - 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.
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).
> Best regards,
> Michael Engel ([EMAIL PROTECTED])
Good luck !
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
