Hi, Lorenzo.
2010/11/25 Lorenzo Paulatto <paulax@...>
> Dear all,
> I have an infrared receiver integrated in my HP3600 laptop; the chip is of
> the it87 family with ID1=85 and ID2=12. Until I upgraded to ubuntu 10.10 I
> was able to use it with an hacked driver that you can find here:
> <http://ubuntuforums.org/showthread.php?t=1028640> (post #39).
>
The kernel provided with Ubuntu 10.10 seems to have been caught in the
middle of the current efforts to put LIRC support/drivers into the kernel.
These efforts include a completely new driver framework with in-kernel IR
decoding. The lirc_XXX drivers are the "old ones", included in the kernel
staging area, waiting to get converted...
> The driver seem to be based on some old version of lirc, something like
> 0.6.3 or 0.6.6 but is not really similar to any of those: the structure of
> the .c file is quite consistent: the smae functions are called grossly in
> the same place. On the other hand, all the named constats (e.g.
> LIRC_XXX_YYY) and in general the .h file are different: different names
> and combined in different ways.
>
I've had a look at the hacked driver, and indeed it seems to be an adaption
of the original driver for 8704/8712 devices lirc_it87. After comparing the
data sheets for it87xx and it85xx devices, both series of devices share a
good bit of functionality. Most of the differences seem to be
renamed/relocated registers, shuffled bits, and the ability for it85xx
devices to have a wake-up code and wake-up behavior specified.
The resultig driver compiles and loads, but does not work properly. When
> loaded it does not give any sign of problems (dmesg):
>
> however, when i try to access the device using irw I get a funny oops:
>
> [24815.632714] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000080
> [24815.632725] IP: [<ffffffffa011957e>] irctl_ioctl+0x3e/0x3b0 [lirc_dev]
>
I guess this has more to do with a mismatch of LIRC ioctl structures
(different userspace and kernel versions) or something like that...
I have tried to integrate the hacked driver in the current it87 module,
> but it is over my capacities. Apart from the trivial task of inserting
> 8512 as a valid identifier, all the differences between the hacked driver
> and the official it87 one is that each call to outb is bracketed with some
> instructions that are totally obscure to me:
>
> int hrae;
> spin_lock_irqsave(&hardware_lock, hw_flags);
>
> hrae = inb(io + 0x7); // HRAE is located in bit 7 with offset 07H C0TCR /
> C0WPS
> hrae &= 0xFF ; // set HRAE
> hrae |= 0x80;
> outb(hrae ,io + 0x7);
>
> outb(((inb(io + it87_CIR_C0CFR) & (it87_CIR_C0CFR_RESEVED |
> it87_CIR_C0CFR_HCFS)) |
> it87_freq - it87_CIR_FREQ_MIN)),
> io + it87_CIR_C0CFR);
>
> hrae = inb(io + 0x7); // HRAE is located in bit 7 with offset 07H C0TCR /
> C0WPS
> hrae &= 0x7F ; // clear HRAE
> outb(hrae ,io + 0x7);
>
The funny thing is that there's nothing like HRAE in the documents I've
found online for the it8512, and the offsets for the registers are shuffled.
Even if HRAE means High Register Address Enable or something like that,
things don't seem to match. The bit it's flipping would be a DLLLOCK bit of
C0SCK (not C0TCR) if the registers were mapped linearly in the host I/O
space.
So here I am to ask your help to either get the hacked driver to work or
> (better) get the hacked driver merged in lirc; I'll provide all the help
> that is necessary for testing, compiling and crashing kernels, but I've
> very little experience with driver programming, I'll do what I can.
>
I've just rewritten the support for the it87xx devices for the new driver
framework. My new driver, if accepted, would replace the original lirc_it87
one. Perhaps we could extend my driver to support your hardware too. If we
ignore the wake-up functionality, the register bits are more or less the
same, just in different places. Would you like us to try?
If the answer is yes, could you please provide the output of lspnp -v with
the standard Ubuntu kernel and no patched driver loaded?
Best regards,
Juan Jesús.
--
:wq
|