[13/13] IR: Port ene driver to new IR subsystem and enable it.
Commit Message
note that error_adjustment module option is added.
This allows to reduce input samples by a percent.
This makes input on my system more correct.
Default is 4% as it works best here.
Note that only normal input is adjusted. I don't know
what ajustements to apply to fan tachtometer input.
Maybe it is accurate already.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
---
MAINTAINERS | 6 +
drivers/media/IR/Kconfig | 14 +
drivers/media/IR/Makefile | 1 +
drivers/media/IR/ene_ir.c | 591 +++++++++++++++++----------------------------
drivers/media/IR/ene_ir.h | 47 ++---
5 files changed, 258 insertions(+), 401 deletions(-)
Comments
On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
<maximlevitsky@gmail.com> wrote:
> note that error_adjustment module option is added.
> This allows to reduce input samples by a percent.
> This makes input on my system more correct.
>
> Default is 4% as it works best here.
>
> Note that only normal input is adjusted. I don't know
> what adjustments to apply to fan tachometer input.
> Maybe it is accurate already.
Do you have the manual for the ENE chip in English? or do you read Chinese?
Maybe you can figure out why the readings are off by 4%. I suspect
that someone has set a clock divider wrong when programming the chip.
For example setting the divider for a 25Mhz clock when the clock is
actually 26Mhz would cause the error you are seeing. Or they just made
a mistake in computing the divisor. It is probably a bug in the BIOS
of your laptop. If that's the case you could add a quirk in the
system boot code to fix the register setting.
On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> <maximlevitsky@gmail.com> wrote:
> > note that error_adjustment module option is added.
> > This allows to reduce input samples by a percent.
> > This makes input on my system more correct.
> >
> > Default is 4% as it works best here.
> >
> > Note that only normal input is adjusted. I don't know
> > what adjustments to apply to fan tachometer input.
> > Maybe it is accurate already.
>
> Do you have the manual for the ENE chip in English? or do you read Chinese?
The datasheet for a similar chip, the KB3700, is out there in English,
but it doesn't have CIR.
You might find these links mildly interesting:
http://www.coreboot.org/Embedded_controller
http://wiki.laptop.org/go/Embedded_controller
http://lists.laptop.org/pipermail/openec/2008-July/000108.html
Regards,
Andy
> Maybe you can figure out why the readings are off by 4%. I suspect
> that someone has set a clock divider wrong when programming the chip.
> For example setting the divider for a 25Mhz clock when the clock is
> actually 26Mhz would cause the error you are seeing. Or they just made
> a mistake in computing the divisor. It is probably a bug in the BIOS
> of your laptop. If that's the case you could add a quirk in the
> system boot code to fix the register setting.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> > <maximlevitsky@gmail.com> wrote:
> > > note that error_adjustment module option is added.
> > > This allows to reduce input samples by a percent.
> > > This makes input on my system more correct.
> > >
> > > Default is 4% as it works best here.
> > >
> > > Note that only normal input is adjusted. I don't know
> > > what adjustments to apply to fan tachometer input.
> > > Maybe it is accurate already.
> >
> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>
> The datasheet for a similar chip, the KB3700, is out there in English,
> but it doesn't have CIR.
>
> You might find these links mildly interesting:
>
> http://www.coreboot.org/Embedded_controller
> http://wiki.laptop.org/go/Embedded_controller
> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
Nope, I have read that.
>
> Regards,
> Andy
>
> > Maybe you can figure out why the readings are off by 4%. I suspect
> > that someone has set a clock divider wrong when programming the chip.
> > For example setting the divider for a 25Mhz clock when the clock is
> > actually 26Mhz would cause the error you are seeing. Or they just made
> > a mistake in computing the divisor. It is probably a bug in the BIOS
> > of your laptop. If that's the case you could add a quirk in the
> > system boot code to fix the register setting.
I figured out how windows driver compensates for the offset, and do the
same in my driver. I think the problem is solved.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>> > <maximlevitsky@gmail.com> wrote:
>> > > note that error_adjustment module option is added.
>> > > This allows to reduce input samples by a percent.
>> > > This makes input on my system more correct.
>> > >
>> > > Default is 4% as it works best here.
>> > >
>> > > Note that only normal input is adjusted. I don't know
>> > > what adjustments to apply to fan tachometer input.
>> > > Maybe it is accurate already.
>> >
>> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>>
>> The datasheet for a similar chip, the KB3700, is out there in English,
>> but it doesn't have CIR.
>>
>> You might find these links mildly interesting:
>>
>> http://www.coreboot.org/Embedded_controller
>> http://wiki.laptop.org/go/Embedded_controller
>> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
>
> Nope, I have read that.
>>
>> Regards,
>> Andy
>>
>> > Maybe you can figure out why the readings are off by 4%. I suspect
>> > that someone has set a clock divider wrong when programming the chip.
>> > For example setting the divider for a 25Mhz clock when the clock is
>> > actually 26Mhz would cause the error you are seeing. Or they just made
>> > a mistake in computing the divisor. It is probably a bug in the BIOS
>> > of your laptop. If that's the case you could add a quirk in the
>> > system boot code to fix the register setting.
>
> I figured out how windows driver compensates for the offset, and do the
> same in my driver. I think the problem is solved.
>
Should that be a <= or >= instead of !=?
+ if (pll_freq != 1000)
Programming the PLL wrong would cause the 4% error.
hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
+ pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+ (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
+
+ if (pll_freq != 1000)
+ dev->rx_period_adjust = 4;
+ else
+ dev->rx_period_adjust = 2;
+
+
+ ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
+
if (hw_revision == 0xFF) {
>
> Best regards,
> Maxim Levitsky
>
>
On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> >> > <maximlevitsky@gmail.com> wrote:
> >> > > note that error_adjustment module option is added.
> >> > > This allows to reduce input samples by a percent.
> >> > > This makes input on my system more correct.
> >> > >
> >> > > Default is 4% as it works best here.
> >> > >
> >> > > Note that only normal input is adjusted. I don't know
> >> > > what adjustments to apply to fan tachometer input.
> >> > > Maybe it is accurate already.
> >> >
> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
> >>
> >> The datasheet for a similar chip, the KB3700, is out there in English,
> >> but it doesn't have CIR.
> >>
> >> You might find these links mildly interesting:
> >>
> >> http://www.coreboot.org/Embedded_controller
> >> http://wiki.laptop.org/go/Embedded_controller
> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
> >
> > Nope, I have read that.
> >>
> >> Regards,
> >> Andy
> >>
> >> > Maybe you can figure out why the readings are off by 4%. I suspect
> >> > that someone has set a clock divider wrong when programming the chip.
> >> > For example setting the divider for a 25Mhz clock when the clock is
> >> > actually 26Mhz would cause the error you are seeing. Or they just made
> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
> >> > of your laptop. If that's the case you could add a quirk in the
> >> > system boot code to fix the register setting.
> >
> > I figured out how windows driver compensates for the offset, and do the
> > same in my driver. I think the problem is solved.
> >
>
> Should that be a <= or >= instead of !=?
> + if (pll_freq != 1000)
This is how its done in windows driver.
>
> Programming the PLL wrong would cause the 4% error.
>
> hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
> old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
>
> + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> +
> + if (pll_freq != 1000)
> + dev->rx_period_adjust = 4;
> + else
> + dev->rx_period_adjust = 2;
> +
> +
> + ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
> +
> if (hw_revision == 0xFF) {
>
>
>
> >
> > Best regards,
> > Maxim Levitsky
> >
> >
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>> >> > <maximlevitsky@gmail.com> wrote:
>> >> > > note that error_adjustment module option is added.
>> >> > > This allows to reduce input samples by a percent.
>> >> > > This makes input on my system more correct.
>> >> > >
>> >> > > Default is 4% as it works best here.
>> >> > >
>> >> > > Note that only normal input is adjusted. I don't know
>> >> > > what adjustments to apply to fan tachometer input.
>> >> > > Maybe it is accurate already.
>> >> >
>> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>> >>
>> >> The datasheet for a similar chip, the KB3700, is out there in English,
>> >> but it doesn't have CIR.
>> >>
>> >> You might find these links mildly interesting:
>> >>
>> >> http://www.coreboot.org/Embedded_controller
>> >> http://wiki.laptop.org/go/Embedded_controller
>> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
>> >
>> > Nope, I have read that.
>> >>
>> >> Regards,
>> >> Andy
>> >>
>> >> > Maybe you can figure out why the readings are off by 4%. I suspect
>> >> > that someone has set a clock divider wrong when programming the chip.
>> >> > For example setting the divider for a 25Mhz clock when the clock is
>> >> > actually 26Mhz would cause the error you are seeing. Or they just made
>> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
>> >> > of your laptop. If that's the case you could add a quirk in the
>> >> > system boot code to fix the register setting.
>> >
>> > I figured out how windows driver compensates for the offset, and do the
>> > same in my driver. I think the problem is solved.
>> >
>>
>> Should that be a <= or >= instead of !=?
>> + if (pll_freq != 1000)
>
> This is how its done in windows driver.
That doesn't mean it is bug free.
Experimenting with changing the PLL frequency register may correct the
error. Try taking 96% of pll_freq and write it back into these
register. This would be easy to fix with a manual. The root problem is
almost certainly a bug in the way the PLLs were programmed.
I don't like putting in fudge factors like the 4% correction. What
happens if a later version of the hardware has fixed firmware? I
normal user is never going to figure out that they need to change the
fudge factor.
+ pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
+ (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
+
>>
>> Programming the PLL wrong would cause the 4% error.
>>
>> hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
>> old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
>>
>> + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
>> + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>> +
>> + if (pll_freq != 1000)
>> + dev->rx_period_adjust = 4;
>> + else
>> + dev->rx_period_adjust = 2;
>> +
>> +
>> + ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
>> +
>> if (hw_revision == 0xFF) {
>>
>>
>>
>> >
>> > Best regards,
>> > Maxim Levitsky
>> >
>> >
>>
>>
>>
>
>
>
On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
>>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>>> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
>>> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
>>> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
>>> >> > <maximlevitsky@gmail.com> wrote:
>>> >> > > note that error_adjustment module option is added.
>>> >> > > This allows to reduce input samples by a percent.
>>> >> > > This makes input on my system more correct.
>>> >> > >
>>> >> > > Default is 4% as it works best here.
>>> >> > >
>>> >> > > Note that only normal input is adjusted. I don't know
>>> >> > > what adjustments to apply to fan tachometer input.
>>> >> > > Maybe it is accurate already.
>>> >> >
>>> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
>>> >>
>>> >> The datasheet for a similar chip, the KB3700, is out there in English,
>>> >> but it doesn't have CIR.
>>> >>
>>> >> You might find these links mildly interesting:
>>> >>
>>> >> http://www.coreboot.org/Embedded_controller
>>> >> http://wiki.laptop.org/go/Embedded_controller
>>> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
>>> >
>>> > Nope, I have read that.
>>> >>
>>> >> Regards,
>>> >> Andy
>>> >>
>>> >> > Maybe you can figure out why the readings are off by 4%. I suspect
>>> >> > that someone has set a clock divider wrong when programming the chip.
>>> >> > For example setting the divider for a 25Mhz clock when the clock is
>>> >> > actually 26Mhz would cause the error you are seeing. Or they just made
>>> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
>>> >> > of your laptop. If that's the case you could add a quirk in the
>>> >> > system boot code to fix the register setting.
>>> >
>>> > I figured out how windows driver compensates for the offset, and do the
>>> > same in my driver. I think the problem is solved.
>>> >
>>>
>>> Should that be a <= or >= instead of !=?
>>> + if (pll_freq != 1000)
>>
>> This is how its done in windows driver.
>
> That doesn't mean it is bug free.
>
> Experimenting with changing the PLL frequency register may correct the
> error. Try taking 96% of pll_freq and write it back into these
> register. This would be easy to fix with a manual. The root problem is
> almost certainly a bug in the way the PLLs were programmed.
>
> I don't like putting in fudge factors like the 4% correction. What
> happens if a later version of the hardware has fixed firmware? I
> normal user is never going to figure out that they need to change the
> fudge factor.
>
> + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
I can understand the shift of the high bits, but that shift of the low
bits is unlikely. A manual would tell us if it is right.
> +
>
>
>>>
>>> Programming the PLL wrong would cause the 4% error.
>>>
>>> hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
>>> old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
>>>
>>> + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
>>> + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>>> +
>>> + if (pll_freq != 1000)
>>> + dev->rx_period_adjust = 4;
>>> + else
>>> + dev->rx_period_adjust = 2;
>>> +
>>> +
>>> + ene_printk(KERN_NOTICE, "PLL freq = %d\n", pll_freq);
>>> +
>>> if (hw_revision == 0xFF) {
>>>
>>>
>>>
>>> >
>>> > Best regards,
>>> > Maxim Levitsky
>>> >
>>> >
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
> On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >> On Fri, 2010-07-30 at 07:51 -0400, Jon Smirl wrote:
> >>> On Fri, Jul 30, 2010 at 7:36 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >>> > On Thu, 2010-07-29 at 23:46 -0400, Andy Walls wrote:
> >>> >> On Thu, 2010-07-29 at 22:39 -0400, Jon Smirl wrote:
> >>> >> > On Thu, Jul 29, 2010 at 10:17 PM, Maxim Levitsky
> >>> >> > <maximlevitsky@gmail.com> wrote:
> >>> >> > > note that error_adjustment module option is added.
> >>> >> > > This allows to reduce input samples by a percent.
> >>> >> > > This makes input on my system more correct.
> >>> >> > >
> >>> >> > > Default is 4% as it works best here.
> >>> >> > >
> >>> >> > > Note that only normal input is adjusted. I don't know
> >>> >> > > what adjustments to apply to fan tachometer input.
> >>> >> > > Maybe it is accurate already.
> >>> >> >
> >>> >> > Do you have the manual for the ENE chip in English? or do you read Chinese?
> >>> >>
> >>> >> The datasheet for a similar chip, the KB3700, is out there in English,
> >>> >> but it doesn't have CIR.
> >>> >>
> >>> >> You might find these links mildly interesting:
> >>> >>
> >>> >> http://www.coreboot.org/Embedded_controller
> >>> >> http://wiki.laptop.org/go/Embedded_controller
> >>> >> http://lists.laptop.org/pipermail/openec/2008-July/000108.html
> >>> >
> >>> > Nope, I have read that.
> >>> >>
> >>> >> Regards,
> >>> >> Andy
> >>> >>
> >>> >> > Maybe you can figure out why the readings are off by 4%. I suspect
> >>> >> > that someone has set a clock divider wrong when programming the chip.
> >>> >> > For example setting the divider for a 25Mhz clock when the clock is
> >>> >> > actually 26Mhz would cause the error you are seeing. Or they just made
> >>> >> > a mistake in computing the divisor. It is probably a bug in the BIOS
> >>> >> > of your laptop. If that's the case you could add a quirk in the
> >>> >> > system boot code to fix the register setting.
> >>> >
> >>> > I figured out how windows driver compensates for the offset, and do the
> >>> > same in my driver. I think the problem is solved.
> >>> >
> >>>
> >>> Should that be a <= or >= instead of !=?
> >>> + if (pll_freq != 1000)
> >>
> >> This is how its done in windows driver.
> >
> > That doesn't mean it is bug free.
This PLL frequency is likely to be chip internal frequency.
And windows driver doesn't touch it.
Its embedded controller, so I don't want to touch things I am not sure
about.
> >
> > Experimenting with changing the PLL frequency register may correct the
> > error. Try taking 96% of pll_freq and write it back into these
> > register. This would be easy to fix with a manual. The root problem is
> > almost certainly a bug in the way the PLLs were programmed.
> >
> > I don't like putting in fudge factors like the 4% correction. What
> > happens if a later version of the hardware has fixed firmware? I
> > normal user is never going to figure out that they need to change the
> > fudge factor.
I don't think that is a hardware bug, rather a limitation.
Lets leave it as is.
I will soon publish the driver on launchpad or something like that and
try to contact users I debugged that driver with, and then see what
ranges PLL register takes.
> >
> > + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> > + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>
> I can understand the shift of the high bits, but that shift of the low
> bits is unlikely. A manual would tell us if it is right.
>
This shift is correct (according to datasheet, which contains mostly
useless info, but it does dociment this reg briefly.)
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
> > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>
> > >
> > > + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> > > + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> >
>
>
> > I can understand the shift of the high bits, but that shift of the low
> > bits is unlikely. A manual would tell us if it is right.
> >
> This shift is correct (according to datasheet, which contains mostly
> useless info, but it does dociment this reg briefly.)
The KB3700 series datasheet indicates that the value from ENE_PLLFRL
should be shifted by >> 4 bits, not by >> 2. Of course, the KB3700
isn't the exact same chip.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote:
> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
> > > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>
> >
> > > >
> > > > + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> > > > + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> > >
> >
> >
> > > I can understand the shift of the high bits, but that shift of the low
> > > bits is unlikely. A manual would tell us if it is right.
> > >
> > This shift is correct (according to datasheet, which contains mostly
> > useless info, but it does dociment this reg briefly.)
>
> The KB3700 series datasheet indicates that the value from ENE_PLLFRL
> should be shifted by >> 4 bits, not by >> 2. Of course, the KB3700
> isn't the exact same chip.
You are right about that, thanks!
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky
<maximlevitsky@gmail.com> wrote:
> On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote:
>> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
>> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
>> > > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>>
>> >
>> > > >
>> > > > + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
>> > > > + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
>> > >
>> >
>> >
>> > > I can understand the shift of the high bits, but that shift of the low
>> > > bits is unlikely. A manual would tell us if it is right.
>> > >
>> > This shift is correct (according to datasheet, which contains mostly
>> > useless info, but it does dociment this reg briefly.)
>>
>> The KB3700 series datasheet indicates that the value from ENE_PLLFRL
>> should be shifted by >> 4 bits, not by >> 2. Of course, the KB3700
>> isn't the exact same chip.
> You are right about that, thanks!
I looked at KB3700 manual. It says it is trying to make a 32Mhz clock
by multiplying 32.768Khz * 1000.
32,768 * 1000 = 32.768Mhz is a 2.4% error.
When you are computing the timings of the pulses did you assume a
32Mhz clock? It looks like the clock is actuall 32.768Mhz.
>
> Best regards,
> Maxim Levitsky
>
>
On Sat, 2010-07-31 at 10:37 -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 10:28 AM, Maxim Levitsky
> <maximlevitsky@gmail.com> wrote:
> > On Sat, 2010-07-31 at 09:55 -0400, Andy Walls wrote:
> >> On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> >> > On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
> >> > > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> > > > On Fri, Jul 30, 2010 at 7:54 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> >>
> >> >
> >> > > >
> >> > > > + pll_freq = (ene_hw_read_reg(dev, ENE_PLLFRH) << 4) +
> >> > > > + (ene_hw_read_reg(dev, ENE_PLLFRL) >> 2);
> >> > >
> >> >
> >> >
> >> > > I can understand the shift of the high bits, but that shift of the low
> >> > > bits is unlikely. A manual would tell us if it is right.
> >> > >
> >> > This shift is correct (according to datasheet, which contains mostly
> >> > useless info, but it does dociment this reg briefly.)
> >>
> >> The KB3700 series datasheet indicates that the value from ENE_PLLFRL
> >> should be shifted by >> 4 bits, not by >> 2. Of course, the KB3700
> >> isn't the exact same chip.
> > You are right about that, thanks!
>
> I looked at KB3700 manual. It says it is trying to make a 32Mhz clock
> by multiplying 32.768Khz * 1000.
>
> 32,768 * 1000 = 32.768Mhz is a 2.4% error.
>
> When you are computing the timings of the pulses did you assume a
> 32Mhz clock? It looks like the clock is actuall 32.768Mhz.
No, I just take the samples hardware give me.
Lets just leave this as is.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2010-07-30 at 15:45 +0300, Maxim Levitsky wrote:
> On Fri, 2010-07-30 at 08:07 -0400, Jon Smirl wrote:
> > On Fri, Jul 30, 2010 at 8:02 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > >>> >
> > >>>
> > >>> Should that be a <= or >= instead of !=?
> > >>> + if (pll_freq != 1000)
> > >>
> > >> This is how its done in windows driver.
> > >
> > > That doesn't mean it is bug free.
>
> This PLL frequency is likely to be chip internal frequency.
> And windows driver doesn't touch it.
> Its embedded controller, so I don't want to touch things I am not sure
> about.
The KB3700 datasheet states there are 4 clock domains in the chip.
One of the clock domains is a PLL LOW domain, used to clock
miscellaneous peripherials (which probably includes CIR on similar
chips). The defualt for this clock appears to be 32.768 kHz clock
derived from a 32.768 MHz clock from which a 32.768 kHz clock is
derived. It seems to be set up in the EC (ACPI 2.0 Embedded Controller)
register bank of the KB3700 chip.
That 1000 (0x3e8) is the default divider value to go from 32.768 MHz to
32.768 kHz. I suspect it could be off by one - 0x3e7 might be the right
value - but that is only a 30 ns difference in the 30 us clock period.
So the check for 1000 by the Windows driver is likely a check for the
chip being in it's default configuration. Looking at the CLKCFG2
register, the PLL can apparently output a 25 MHz clock instead of a
32.768 MHz clock.
While I'm looking at CLKCFG2, I note the default divider value of 0x1f
(31) for 1000 ns is wrong as well:
32 / 32.768 MHz ~= 977 ns = 0.977 us (-2.3%)
where as
33 / 32.768 MHz ~= 1007 ns = 1.007 us (+0.7%)
so the CLKCFG2 register programmed with 0x20 (32) would a better divisor
for a 1 us time period, if the functions in the chip can tolerate being
a little late vs. early.
I also read that the PLL reference comes from the LPC portion of the
chip which is the PCI clock domain. So if a 33 MHz reference is used
instead of 32.768 MHz, then the default CLKCFG2 value yields this for a
nominal 1 us:
32 / 33.333 MHz ~= 960 ns = 0.960 us (-4.0%)
> > > Experimenting with changing the PLL frequency register may correct the
> > > error. Try taking 96% of pll_freq and write it back into these
> > > register. This would be easy to fix with a manual. The root problem is
> > > almost certainly a bug in the way the PLLs were programmed.
> > >
> > > I don't like putting in fudge factors like the 4% correction. What
> > > happens if a later version of the hardware has fixed firmware? I
> > > normal user is never going to figure out that they need to change the
> > > fudge factor.
> I don't think that is a hardware bug, rather a limitation.
>
> Lets leave it as is.
> I will soon publish the driver on launchpad or something like that and
> try to contact users I debugged that driver with, and then see what
> ranges PLL register takes.
I think you won't be able to fix the problem conclusively either way. A
lot of how the chip's clocks should be programmed depends on how the
GPIOs are used and what crystal is used.
I suspect many designers will use some reference design layout from ENE,
but it won't be good in every case. The wire-up of the ENE of various
motherboards is likely something you'll have to live with as unknowns.
This is a case where looser tolerances in the in kernel decoders could
reduce this driver's complexity and/or get rid of arbitrary fudge
factors in the driver.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> I think you won't be able to fix the problem conclusively either way. A
> lot of how the chip's clocks should be programmed depends on how the
> GPIOs are used and what crystal is used.
>
> I suspect many designers will use some reference design layout from ENE,
> but it won't be good in every case. The wire-up of the ENE of various
> motherboards is likely something you'll have to live with as unknowns.
>
> This is a case where looser tolerances in the in kernel decoders could
> reduce this driver's complexity and/or get rid of arbitrary fudge
> factors in the driver.
The tolerances are as loose as they can be. The NEC protocol uses
pulses that are 4% longer than JVC. The decoders allow errors up to 2%
(50% of 4%). The crystals used in electronics are accurate to
0.0001%+. The 4% error in this driver is because the hardware is not
being programmed accurately. This needs to be fixed in the driver and
not in the upper layers.
How is sample period being computed, where is the complete source to
this driver?
dev->tx_period = 32;
Where is sample_period computed?
@@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
hw_value &= ENE_SAMPLE_VALUE_MASK;
hw_sample = hw_value * sample_period;
+
+ if (dev->rx_period_adjust) {
+ hw_sample *= (100 - dev->rx_period_adjust);
+ hw_sample /= 100;
+ }
}
I suspect sample_period is set to 32us. For 32.768Mhz the period needs
to be 30.5us. I don't see the code for how it was computed.
You have to be careful with rounding errors when doing this type of
computation. What looks like a minor error can amplify into a large
error. Sometimes I do the math in 64b ints just to keep the round off
errors from accumulating. Instead of doing the math in calculator and
plugging in 32. Use #defines and do the math in the code.
Maybe something like
#define sample_period (1 / (32768 * 1000))
Then don't store this constant in a variable since it will cause a
round off. Just use it directly in the computation.
>
> Regards,
> Andy
>
>
On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> > I think you won't be able to fix the problem conclusively either way. A
> > lot of how the chip's clocks should be programmed depends on how the
> > GPIOs are used and what crystal is used.
> >
> > I suspect many designers will use some reference design layout from ENE,
> > but it won't be good in every case. The wire-up of the ENE of various
> > motherboards is likely something you'll have to live with as unknowns.
> >
> > This is a case where looser tolerances in the in kernel decoders could
> > reduce this driver's complexity and/or get rid of arbitrary fudge
> > factors in the driver.
>
> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%). The crystals used in electronics are accurate to
> 0.0001%+. The 4% error in this driver is because the hardware is not
> being programmed accurately. This needs to be fixed in the driver and
> not in the upper layers.
Let me explain again.
I get samples in 4 byte buffer. each sample is a count of sample
periods.
Sample period is programmed into hardware, at 'ENE_CIR_SAMPLE_PERIOD'
(it is in us)
Default sample period is 50 us.
The error source isn't 'electronics' fault.
The device is microprocessor.
I don't read the samples 'directly' from hardware, but rather from ram
of that microprocessor.
I don't know how it samples the input.
A expiration of sample period might just cause a IRQ inside that
microprocessor, and it can't process it instantly. That is probably the
source of the delay.
Or something like that.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2010-07-31 at 12:25 -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> > I think you won't be able to fix the problem conclusively either way. A
> > lot of how the chip's clocks should be programmed depends on how the
> > GPIOs are used and what crystal is used.
> >
> > I suspect many designers will use some reference design layout from ENE,
> > but it won't be good in every case. The wire-up of the ENE of various
> > motherboards is likely something you'll have to live with as unknowns.
> >
> > This is a case where looser tolerances in the in kernel decoders could
> > reduce this driver's complexity and/or get rid of arbitrary fudge
> > factors in the driver.
>
> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%). The crystals used in electronics are accurate to
> 0.0001%+. The 4% error in this driver is because the hardware is not
> being programmed accurately. This needs to be fixed in the driver and
> not in the upper layers.
>
> How is sample period being computed, where is the complete source to
> this driver?
>
> dev->tx_period = 32;
>
> Where is sample_period computed?
>
> @@ -672,13 +583,25 @@ static irqreturn_t ene_isr(int irq, void *data)
> pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
> hw_value &= ENE_SAMPLE_VALUE_MASK;
> hw_sample = hw_value * sample_period;
> +
> + if (dev->rx_period_adjust) {
> + hw_sample *= (100 - dev->rx_period_adjust);
> + hw_sample /= 100;
> + }
> }
>
> I suspect sample_period is set to 32us. For 32.768Mhz the period needs
> to be 30.5us. I don't see the code for how it was computed.
>
> You have to be careful with rounding errors when doing this type of
> computation. What looks like a minor error can amplify into a large
> error. Sometimes I do the math in 64b ints just to keep the round off
> errors from accumulating. Instead of doing the math in calculator and
> plugging in 32. Use #defines and do the math in the
There is no reason to worry about rounding here.
hw_sample is maximum of 127 * 50, so when I muliply by 100 I get exact
result.
Then I do one divide.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jon,
on 31 Jul 10 at 12:25, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
> wrote:
>> I think you won't be able to fix the problem conclusively either way. A
>> lot of how the chip's clocks should be programmed depends on how the
>> GPIOs are used and what crystal is used.
>>
>> I suspect many designers will use some reference design layout from ENE,
>> but it won't be good in every case. The wire-up of the ENE of various
>> motherboards is likely something you'll have to live with as unknowns.
>>
>> This is a case where looser tolerances in the in kernel decoders could
>> reduce this driver's complexity and/or get rid of arbitrary fudge
>> factors in the driver.
> The tolerances are as loose as they can be. The NEC protocol uses
> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> (50% of 4%). The crystals used in electronics are accurate to
> 0.0001%+.
But the standard IR receivers are far from being accurate enough to allow
tolerance windows of only 2%.
I'm surprised that this works for you. LIRC uses a standard tolerance of
30% / 100 us and even this is not enough sometimes.
For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
If the receiver just misses one pulse, you already have an error of 1/22
> 4%.
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi Jon,
>
> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>> wrote:
>>> I think you won't be able to fix the problem conclusively either way. A
>>> lot of how the chip's clocks should be programmed depends on how the
>>> GPIOs are used and what crystal is used.
>>>
>>> I suspect many designers will use some reference design layout from ENE,
>>> but it won't be good in every case. The wire-up of the ENE of various
>>> motherboards is likely something you'll have to live with as unknowns.
>>>
>>> This is a case where looser tolerances in the in kernel decoders could
>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>> factors in the driver.
>
>> The tolerances are as loose as they can be. The NEC protocol uses
>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>> (50% of 4%). The crystals used in electronics are accurate to
>> 0.0001%+.
>
> But the standard IR receivers are far from being accurate enough to allow
> tolerance windows of only 2%.
> I'm surprised that this works for you. LIRC uses a standard tolerance of
> 30% / 100 us and even this is not enough sometimes.
>
> For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
> If the receiver just misses one pulse, you already have an error of 1/22
>> 4%.
There are different types of errors. The decoders can take large
variations in bit times. The problem is with cumulative errors. In
this case the error had accumulated up to 450us in the lead pulse.
That's just too big of an error and caused the JVC code to be
misclassified as NEC.
I think he said lirc was misclassifying it too. So we both did the same thing.
>
> Christoph
>
On Sat, Jul 31, 2010 at 2:14 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>> wrote:
>>>> I think you won't be able to fix the problem conclusively either way. A
>>>> lot of how the chip's clocks should be programmed depends on how the
>>>> GPIOs are used and what crystal is used.
>>>>
>>>> I suspect many designers will use some reference design layout from ENE,
>>>> but it won't be good in every case. The wire-up of the ENE of various
>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>
>>>> This is a case where looser tolerances in the in kernel decoders could
>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>> factors in the driver.
>>
>>> The tolerances are as loose as they can be. The NEC protocol uses
>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>> (50% of 4%). The crystals used in electronics are accurate to
>>> 0.0001%+.
>>
>> But the standard IR receivers are far from being accurate enough to allow
>> tolerance windows of only 2%.
>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>> 30% / 100 us and even this is not enough sometimes.
>>
>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
>> If the receiver just misses one pulse, you already have an error of 1/22
>>> 4%.
>
> There are different types of errors. The decoders can take large
> variations in bit times. The problem is with cumulative errors. In
> this case the error had accumulated up to 450us in the lead pulse.
> That's just too big of an error and caused the JVC code to be
> misclassified as NEC.
I only see two solutions to this problem:
1) fix the driver to semi-accurately report correct measurements. A
consistent off by 4% error is simply too much since the NEC protocol
is a 4% stretched version of the JVC protocol. If the driver is
stretching JVC by 4% it has effectively converted it into a broken NEC
message. And that's what the decoders detected. Given that the NEC
protocol is a 4% stretched JVC the largest safe timing variance is 2%
(half of 4%). That 2% number is nothing to do with the code, it is
caused by the definitions of the JVC and NEC protocol timings.
2) Implement a record and match mode that knows nothing about
protocols. LIRC has this in the raw protocol. That would fix this
problem, but we're treating the symptom not the disease. The disease
is the broken IR driver.
I'd rather hold off on the raw protocol and try to fix the base IR
drivers first.
>
> I think he said lirc was misclassifying it too. So we both did the same thing.
>
>
>>
>> Christoph
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> > Hi Jon,
> >
> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
> >> wrote:
> >>> I think you won't be able to fix the problem conclusively either way. A
> >>> lot of how the chip's clocks should be programmed depends on how the
> >>> GPIOs are used and what crystal is used.
> >>>
> >>> I suspect many designers will use some reference design layout from ENE,
> >>> but it won't be good in every case. The wire-up of the ENE of various
> >>> motherboards is likely something you'll have to live with as unknowns.
> >>>
> >>> This is a case where looser tolerances in the in kernel decoders could
> >>> reduce this driver's complexity and/or get rid of arbitrary fudge
> >>> factors in the driver.
> >
> >> The tolerances are as loose as they can be. The NEC protocol uses
> >> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> >> (50% of 4%). The crystals used in electronics are accurate to
> >> 0.0001%+.
> >
> > But the standard IR receivers are far from being accurate enough to allow
> > tolerance windows of only 2%.
> > I'm surprised that this works for you. LIRC uses a standard tolerance of
> > 30% / 100 us and even this is not enough sometimes.
> >
> > For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
> > If the receiver just misses one pulse, you already have an error of 1/22
> >> 4%.
>
> There are different types of errors. The decoders can take large
> variations in bit times. The problem is with cumulative errors. In
> this case the error had accumulated up to 450us in the lead pulse.
> That's just too big of an error
Hi Jon,
Hmmm. Leader marks are, by protocol design, there to give time for the
receiver's AGC to settle. We should make it OK to miss somewhat large
portions of leader marks. I'm not sure what the harm is in accepting
too long of a leader mark, but I'm pretty sure a leader mark that is too
long will always be due to systematic error and not noise errors.
However, if we know we have systematic errors caused by unknowns, we
should be designing and imlpementing a decoding system that reasonably
deals with those systematic errors. Again the part of the system almost
completely out of our control is the remote controls, and we *have no
control* over systematic errors introduced by remotes.
Obviously we want to reduce or elimiinate systematic errors by
determining the unknowns and undoing their effects or by compensating
for their overall effect. But in the case of the ENE receiver driver,
you didn't seem to like the Maxim's software compensation for the
systematic receiver errors.
> and caused the JVC code to be
> misclassified as NEC.
I still have not heard why we need protocol discrimination/classifcation
in the kernel. Doing discrimination between two protocols with such
close timings is whose requirement again?
Since these two protocols have such close timings that systematic errors
can cause misclassifcation when using simple mark or space measurments
against fixed thresholds, it indicates that a more sophisticated
discrimation mechanism would be needed. Perhaps one that takes multiple
successive measurments into account?
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> > Hi Jon,
>> >
>> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
>> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>> >> wrote:
>> >>> I think you won't be able to fix the problem conclusively either way. A
>> >>> lot of how the chip's clocks should be programmed depends on how the
>> >>> GPIOs are used and what crystal is used.
>> >>>
>> >>> I suspect many designers will use some reference design layout from ENE,
>> >>> but it won't be good in every case. The wire-up of the ENE of various
>> >>> motherboards is likely something you'll have to live with as unknowns.
>> >>>
>> >>> This is a case where looser tolerances in the in kernel decoders could
>> >>> reduce this driver's complexity and/or get rid of arbitrary fudge
>> >>> factors in the driver.
>> >
>> >> The tolerances are as loose as they can be. The NEC protocol uses
>> >> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>> >> (50% of 4%). The crystals used in electronics are accurate to
>> >> 0.0001%+.
>> >
>> > But the standard IR receivers are far from being accurate enough to allow
>> > tolerance windows of only 2%.
>> > I'm surprised that this works for you. LIRC uses a standard tolerance of
>> > 30% / 100 us and even this is not enough sometimes.
>> >
>> > For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
>> > If the receiver just misses one pulse, you already have an error of 1/22
>> >> 4%.
>>
>> There are different types of errors. The decoders can take large
>> variations in bit times. The problem is with cumulative errors. In
>> this case the error had accumulated up to 450us in the lead pulse.
>> That's just too big of an error
>
> Hi Jon,
>
> Hmmm. Leader marks are, by protocol design, there to give time for the
> receiver's AGC to settle. We should make it OK to miss somewhat large
> portions of leader marks. I'm not sure what the harm is in accepting
> too long of a leader mark, but I'm pretty sure a leader mark that is too
> long will always be due to systematic error and not noise errors.
>
> However, if we know we have systematic errors caused by unknowns, we
> should be designing and implementing a decoding system that reasonably
> deals with those systematic errors. Again the part of the system almost
> completely out of our control is the remote controls, and we *have no
> control* over systematic errors introduced by remotes.
We haven't encountered remotes with systematic errors. If remotes had
large errors in them they wouldn't be able to reliably control their
target devices. Find a remote that won't work with the protocol
engines and a reasonably accurate receiver.
>
> Obviously we want to reduce or eliminate systematic errors by
> determining the unknowns and undoing their effects or by compensating
> for their overall effect. But in the case of the ENE receiver driver,
> you didn't seem to like the Maxim's software compensation for the
> systematic receiver errors.
I would be happier if we could track down the source of the error
instead of sticking a bandaid on at the end of the process.
>> and caused the JVC code to be
>> misclassified as NEC.
>
> I still have not heard why we need protocol discrimination/classifcation
> in the kernel. Doing discrimination between two protocols with such
> close timings is whose requirement again?
If we don't do protocol engines we have to revert back to raw
recording and having everyone train the system with their remotes. The
goal is to eliminate the training step. We would also have to have
large files (LIRC configs) for building the keymaps and a new API to
deal with them. With the engines the key presses are identified by
short strings.
A use case: install mythtv, add an IR receiver. Myth UI says to set
your universal remote to a Motorola DVR profile. Remote works - no
training step needed.
LIRC has protocol engines too. irrecord first tries to fit the remote
into a protocol engine. If it can't it reverts to raw mode. Let's
analyze those cases where lirc ends up in raw mode and see if we can
figure out what's going wrong.
For example I know of two things that will trip up irrecord that are
fixed in the kernel system
1) the ene driver. we know now it had a 4% error in the reported periods
2) Sony remotes - they mix protocols on a single remote.
> Since these two protocols have such close timings that systematic errors
> can cause misclassification when using simple mark or space measurements
> against fixed thresholds, it indicates that a more sophisticated
> discrimination mechanism would be needed. Perhaps one that takes multiple
> successive measurements into account?
If we get to the point where we need more sophisticated
classifications we can build it. But are we at that point yet? I'd
prefer to initially leave everything pretty strict as a way of
flushing out driver implementation bugs.
Find some remotes and receivers that break the current system.
>
> Regards,
> Andy
>
>
On Sat, 2010-07-31 at 17:53 -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> > On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
> >> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> >> > Hi Jon,
> >> >
> >> > on 31 Jul 10 at 12:25, Jon Smirl wrote:
> >> >> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
> >> >> wrote:
> >> >>> I think you won't be able to fix the problem conclusively either way. A
> >> >>> lot of how the chip's clocks should be programmed depends on how the
> >> >>> GPIOs are used and what crystal is used.
> >> >>>
> >> >>> I suspect many designers will use some reference design layout from ENE,
> >> >>> but it won't be good in every case. The wire-up of the ENE of various
> >> >>> motherboards is likely something you'll have to live with as unknowns.
> >> >>>
> >> >>> This is a case where looser tolerances in the in kernel decoders could
> >> >>> reduce this driver's complexity and/or get rid of arbitrary fudge
> >> >>> factors in the driver.
> >> >
> >> >> The tolerances are as loose as they can be. The NEC protocol uses
> >> >> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
> >> >> (50% of 4%). The crystals used in electronics are accurate to
> >> >> 0.0001%+.
> >> >
> >> > But the standard IR receivers are far from being accurate enough to allow
> >> > tolerance windows of only 2%.
> >> > I'm surprised that this works for you. LIRC uses a standard tolerance of
> >> > 30% / 100 us and even this is not enough sometimes.
> >> >
> >> > For the NEC protocol one signal consists of 22 individual pulses at 38kHz.
> >> > If the receiver just misses one pulse, you already have an error of 1/22
> >> >> 4%.
> >>
> >> There are different types of errors. The decoders can take large
> >> variations in bit times. The problem is with cumulative errors. In
> >> this case the error had accumulated up to 450us in the lead pulse.
> >> That's just too big of an error
> >
> > Hi Jon,
> >
> > Hmmm. Leader marks are, by protocol design, there to give time for the
> > receiver's AGC to settle. We should make it OK to miss somewhat large
> > portions of leader marks. I'm not sure what the harm is in accepting
> > too long of a leader mark, but I'm pretty sure a leader mark that is too
> > long will always be due to systematic error and not noise errors.
> >
> > However, if we know we have systematic errors caused by unknowns, we
> > should be designing and implementing a decoding system that reasonably
> > deals with those systematic errors. Again the part of the system almost
> > completely out of our control is the remote controls, and we *have no
> > control* over systematic errors introduced by remotes.
>
> We haven't encountered remotes with systematic errors. If remotes had
> large errors in them they wouldn't be able to reliably control their
> target devices. Find a remote that won't work with the protocol
> engines and a reasonably accurate receiver.
>
> >
> > Obviously we want to reduce or eliminate systematic errors by
> > determining the unknowns and undoing their effects or by compensating
> > for their overall effect. But in the case of the ENE receiver driver,
> > you didn't seem to like the Maxim's software compensation for the
> > systematic receiver errors.
>
> I would be happier if we could track down the source of the error
> instead of sticking a bandaid on at the end of the process.
This isn't a bandaid.
Windows driver programs the period to 52 but treats it as a 50.
(I don't do that because I set period to 75 - otherwise leading pulse of
NEC/JVC is almost missing. I know the reason for that, and it isn't
important).
>
> >> and caused the JVC code to be
> >> misclassified as NEC.
> >
> > I still have not heard why we need protocol discrimination/classifcation
> > in the kernel. Doing discrimination between two protocols with such
> > close timings is whose requirement again?
>
> If we don't do protocol engines we have to revert back to raw
> recording and having everyone train the system with their remotes. The
> goal is to eliminate the training step. We would also have to have
> large files (LIRC configs) for building the keymaps and a new API to
> deal with them. With the engines the key presses are identified by
> short strings.
>
> A use case: install mythtv, add an IR receiver. Myth UI says to set
> your universal remote to a Motorola DVR profile. Remote works - no
> training step needed.
>
> LIRC has protocol engines too. irrecord first tries to fit the remote
> into a protocol engine. If it can't it reverts to raw mode. Let's
> analyze those cases where lirc ends up in raw mode and see if we can
> figure out what's going wrong.
>
> For example I know of two things that will trip up irrecord that are
> fixed in the kernel system
> 1) the ene driver. we know now it had a 4% error in the reported periods
No it doesn't....
It even works if leading large pulse is missing.
I would never ever think of doing the adjustments, because lircds
tolerance is much better.
I am tired of this discussion.
My ENE receiver does work now, it gives correct samples, it applies same
adjustment, and thats all.
And thanks to my patches, the in-kernel decoding actually works well
with all protocols it supports.
Besides, main target is RC5/6 and it doesn't have long pulses,
therefore, it won't have that issue.
> 2) Sony remotes - they mix protocols on a single remote.
>
> > Since these two protocols have such close timings that systematic errors
> > can cause misclassification when using simple mark or space measurements
> > against fixed thresholds, it indicates that a more sophisticated
> > discrimination mechanism would be needed. Perhaps one that takes multiple
> > successive measurements into account?
>
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
>
> Find some remotes and receivers that break the current system.
>
> >
> > Regards,
> > Andy
> >
> >
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jon,
on 31 Jul 10 at 17:53, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> On Sat, 2010-07-31 at 14:14 -0400, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way..
>>>>>> A lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from
>>>>>> ENE, but it won't be good in every case. The wire-up of the ENE of
>>>>>> various motherboards is likely something you'll have to live with as
>>>>>> unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%). The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at
>>>> 38kHz. If the receiver just misses one pulse, you already have an error
>>>> of 1/22
>>>>> 4%.
>>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error
>>
>> Hi Jon,
>>
>> Hmmm. Leader marks are, by protocol design, there to give time for the
>> receiver's AGC to settle. We should make it OK to miss somewhat large
>> portions of leader marks. I'm not sure what the harm is in accepting
>> too long of a leader mark, but I'm pretty sure a leader mark that is too
>> long will always be due to systematic error and not noise errors.
>>
>> However, if we know we have systematic errors caused by unknowns, we
>> should be designing and implementing a decoding system that reasonably
>> deals with those systematic errors. Again the part of the system almost
>> completely out of our control is the remote controls, and we *have no
>> control* over systematic errors introduced by remotes.
> We haven't encountered remotes with systematic errors. If remotes had
> large errors in them they wouldn't be able to reliably control their
> target devices. Find a remote that won't work with the protocol
> engines and a reasonably accurate receiver.
>>
>> Obviously we want to reduce or eliminate systematic errors by
>> determining the unknowns and undoing their effects or by compensating
>> for their overall effect. But in the case of the ENE receiver driver,
>> you didn't seem to like the Maxim's software compensation for the
>> systematic receiver errors.
> I would be happier if we could track down the source of the error
> instead of sticking a bandaid on at the end of the process.
>>> and caused the JVC code to be
>>> misclassified as NEC.
>>
>> I still have not heard why we need protocol discrimination/classifcation
>> in the kernel. Doing discrimination between two protocols with such
>> close timings is whose requirement again?
> If we don't do protocol engines we have to revert back to raw
> recording and having everyone train the system with their remotes. The
> goal is to eliminate the training step. We would also have to have
> large files (LIRC configs) for building the keymaps and a new API to
> deal with them. With the engines the key presses are identified by
> short strings.
Only 437 of 3486 config files on lirc.org use raw mode (probably what you
mean with large files). Many of them are recorded with an very old
irrecord version. Current versions of irrecord wouldn't create a raw mode
config file for these remotes.
> A use case: install mythtv, add an IR receiver. Myth UI says to set
> your universal remote to a Motorola DVR profile. Remote works - no
> training step needed.
+ Myth UI reconfigures lircd with an existing Motorola DVR config file.
Where's the difference?
> LIRC has protocol engines too. irrecord first tries to fit the remote
> into a protocol engine.
With the sublte difference to your approach that LIRC does not make any
assumptions on any timings in contrast to hardcoded values in the kernel.
> If it can't it reverts to raw mode. Let's
> analyze those cases where lirc ends up in raw mode and see if we can
> figure out what's going wrong.
>
> For example I know of two things that will trip up irrecord that are
> fixed in the kernel system
> 1) the ene driver. we know now it had a 4% error in the reported periods
Wrong.
> 2) Sony remotes - they mix protocols on a single remote.
This is a long known issue. I didn't care to fix it because in practice it
does not matter.
>> Since these two protocols have such close timings that systematic errors
>> can cause misclassification when using simple mark or space measurements
>> against fixed thresholds, it indicates that a more sophisticated
>> discrimination mechanism would be needed. Perhaps one that takes multiple
>> successive measurements into account?
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
>
> Find some remotes and receivers that break the current system.
>>
>> Regards,
>> Andy
>>
>>
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jon,
on 31 Jul 10 at 14:14, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>> wrote:
>>>> I think you won't be able to fix the problem conclusively either way. A
>>>> lot of how the chip's clocks should be programmed depends on how the
>>>> GPIOs are used and what crystal is used.
>>>>
>>>> I suspect many designers will use some reference design layout from ENE,
>>>> but it won't be good in every case. The wire-up of the ENE of various
>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>
>>>> This is a case where looser tolerances in the in kernel decoders could
>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>> factors in the driver.
>>
>>> The tolerances are as loose as they can be. The NEC protocol uses
>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>> (50% of 4%). The crystals used in electronics are accurate to
>>> 0.0001%+.
>>
>> But the standard IR receivers are far from being accurate enough to allow
>> tolerance windows of only 2%.
>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>> 30% / 100 us and even this is not enough sometimes.
>>
>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>> If the receiver just misses one pulse, you already have an error of 1/22
>>> 4%.
> There are different types of errors. The decoders can take large
> variations in bit times. The problem is with cumulative errors. In
> this case the error had accumulated up to 450us in the lead pulse.
> That's just too big of an error and caused the JVC code to be
> misclassified as NEC.
>
> I think he said lirc was misclassifying it too. So we both did the same
> thing.
No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
JVC with NEC signals?
LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
generates the config file using your receiver it will compensate for any
timing error. It will work with pulses cut down to 50 us like IrDA
hardware does and it will work when half of the bits are swollowed like
the IgorPlug USB receiver does.
But of course the driver should try to generate timings as accurate as
possible.
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi Jon,
>
> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>> wrote:
>>> Hi Jon,
>>>
>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>> wrote:
>>>>> I think you won't be able to fix the problem conclusively either way. A
>>>>> lot of how the chip's clocks should be programmed depends on how the
>>>>> GPIOs are used and what crystal is used.
>>>>>
>>>>> I suspect many designers will use some reference design layout from ENE,
>>>>> but it won't be good in every case. The wire-up of the ENE of various
>>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>>
>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>> factors in the driver.
>>>
>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>> (50% of 4%). The crystals used in electronics are accurate to
>>>> 0.0001%+.
>>>
>>> But the standard IR receivers are far from being accurate enough to allow
>>> tolerance windows of only 2%.
>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>> 30% / 100 us and even this is not enough sometimes.
>>>
>>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>>> If the receiver just misses one pulse, you already have an error of 1/22
>>>> 4%.
>
>> There are different types of errors. The decoders can take large
>> variations in bit times. The problem is with cumulative errors. In
>> this case the error had accumulated up to 450us in the lead pulse.
>> That's just too big of an error and caused the JVC code to be
>> misclassified as NEC.
>>
>> I think he said lirc was misclassifying it too. So we both did the same
>> thing.
>
> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
> JVC with NEC signals?
>
> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
> generates the config file using your receiver it will compensate for any
At the end of the process we can build a record and match raw mode if
we have to.
> timing error. It will work with pulses cut down to 50 us like IrDA
> hardware does and it will work when half of the bits are swallowed like
> the IgorPlug USB receiver does.
The code for fixing IrDA and IgorPLug should live inside their low
level device drivers. The characteristics of the errors produced by
this hardware are known so a fix can be written to compensate. The
IgorPlug people might find it easier to fix their firmware. You don't
have to get the timing exactly right for the protocol engines to work,
you just need to get the big systematic errors out.
Before doing raw the low level IR drivers should be fixed to provide
the most accurate data possible. I don't think it is good design for a
low level driver to be injecting systematic errors and then have the
next layer of code remove them. The source of the systematic errors
should be characterized and fixed in the low level driver. That also
allows the fixed to be constrained to fixing data from only a single
receiver type.
I have been burnt twice in the past from fixing errors in a low level
driver higher in the stack. I have learned the hard way that it is a
bad thing to do. As the fixes accumulate in the higher layers you will
reach a point where they conflict and no solution is possible. Bugs in
the low level drivers need to be fixed in that driver.
Show me a case that can't be fixed in the low level driver and we can
explore the options.
>
> But of course the driver should try to generate timings as accurate as
> possible.
>
> Christoph
>
On Sun, Aug 1, 2010 at 10:00 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way. A
>>>>>> lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from ENE,
>>>>>> but it won't be good in every case. The wire-up of the ENE of various
>>>>>> motherboards is likely something you'll have to live with as unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%). The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at 38kHz..
>>>> If the receiver just misses one pulse, you already have an error of 1/22
>>>>> 4%.
>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error and caused the JVC code to be
>>> misclassified as NEC.
>>>
>>> I think he said lirc was misclassifying it too. So we both did the same
>>> thing.
>>
>> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
>> JVC with NEC signals?
>>
>> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
>> generates the config file using your receiver it will compensate for any
>
> At the end of the process we can build a record and match raw mode if
> we have to.
>
>> timing error. It will work with pulses cut down to 50 us like IrDA
>> hardware does and it will work when half of the bits are swallowed like
>> the IgorPlug USB receiver does.
>
> The code for fixing IrDA and IgorPLug should live inside their low
> level device drivers. The characteristics of the errors produced by
> this hardware are known so a fix can be written to compensate. The
> IgorPlug people might find it easier to fix their firmware. You don't
> have to get the timing exactly right for the protocol engines to work,
> you just need to get the big systematic errors out.
There is a real benefit to strict protocol engines. If the IgorPlus
people had strict protocol engines to test against they would have
discovered their firmware bugs during the initial development process.
>
> Before doing raw the low level IR drivers should be fixed to provide
> the most accurate data possible. I don't think it is good design for a
> low level driver to be injecting systematic errors and then have the
> next layer of code remove them. The source of the systematic errors
> should be characterized and fixed in the low level driver. That also
> allows the fixed to be constrained to fixing data from only a single
> receiver type.
>
> I have been burnt twice in the past from fixing errors in a low level
> driver higher in the stack. I have learned the hard way that it is a
> bad thing to do. As the fixes accumulate in the higher layers you will
> reach a point where they conflict and no solution is possible. Bugs in
> the low level drivers need to be fixed in that driver.
>
> Show me a case that can't be fixed in the low level driver and we can
> explore the options.
>
>>
>> But of course the driver should try to generate timings as accurate as
>> possible.
>>
>> Christoph
>>
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
Hi!
Jon Smirl "jonsmirl@gmail.com" wrote:
> On Sun, Aug 1, 2010 at 5:50 AM, Christoph Bartelmus <lirc@bartelmus.de>
> wrote:
>> Hi Jon,
>>
>> on 31 Jul 10 at 14:14, Jon Smirl wrote:
>>> On Sat, Jul 31, 2010 at 1:47 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>> wrote:
>>>> Hi Jon,
>>>>
>>>> on 31 Jul 10 at 12:25, Jon Smirl wrote:
>>>>> On Sat, Jul 31, 2010 at 11:12 AM, Andy Walls <awalls@md.metrocast.net>
>>>>> wrote:
>>>>>> I think you won't be able to fix the problem conclusively either way.
>>>>>> A lot of how the chip's clocks should be programmed depends on how the
>>>>>> GPIOs are used and what crystal is used.
>>>>>>
>>>>>> I suspect many designers will use some reference design layout from
>>>>>> ENE, but it won't be good in every case. The wire-up of the ENE of
>>>>>> various motherboards is likely something you'll have to live with as
>>>>>> unknowns.
>>>>>>
>>>>>> This is a case where looser tolerances in the in kernel decoders could
>>>>>> reduce this driver's complexity and/or get rid of arbitrary fudge
>>>>>> factors in the driver.
>>>>
>>>>> The tolerances are as loose as they can be. The NEC protocol uses
>>>>> pulses that are 4% longer than JVC. The decoders allow errors up to 2%
>>>>> (50% of 4%). The crystals used in electronics are accurate to
>>>>> 0.0001%+.
>>>>
>>>> But the standard IR receivers are far from being accurate enough to allow
>>>> tolerance windows of only 2%.
>>>> I'm surprised that this works for you. LIRC uses a standard tolerance of
>>>> 30% / 100 us and even this is not enough sometimes.
>>>>
>>>> For the NEC protocol one signal consists of 22 individual pulses at
>>>> 38kHz.. If the receiver just misses one pulse, you already have an error
>>>> of 1/22
>>>>> 4%.
>>
>>> There are different types of errors. The decoders can take large
>>> variations in bit times. The problem is with cumulative errors. In
>>> this case the error had accumulated up to 450us in the lead pulse.
>>> That's just too big of an error and caused the JVC code to be
>>> misclassified as NEC.
>>>
>>> I think he said lirc was misclassifying it too. So we both did the same
>>> thing.
>>
>> No way. JVC is a 16 bit code. NEC uses 32 bits. How can you ever confuse
>> JVC with NEC signals?
>>
>> LIRC will work if there is a 4% or 40% or 400% error. Because irrecord
>> generates the config file using your receiver it will compensate for any
> At the end of the process we can build a record and match raw mode if
> we have to.
I'm not talking about raw mode here. lircd will happily decode the signals
despite of any timing error as long it's consistent.
I'm still interested how JVC can be confused with NEC codes.
>> timing error. It will work with pulses cut down to 50 us like IrDA
>> hardware does and it will work when half of the bits are swallowed like
>> the IgorPlug USB receiver does.
> The code for fixing IrDA and IgorPLug should live inside their low
> level device drivers. The characteristics of the errors produced by
> this hardware are known so a fix can be written to compensate.
The function f(x) = 50 is not bijective. No way to compensate.
Missing bits cannot be magically regenerated by the driver.
> The
> IgorPlug people might find it easier to fix their firmware.
There is a firmware patch available? Do you have a pointer?
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
...
> > Since these two protocols have such close timings that systematic errors
> > can cause misclassification when using simple mark or space measurements
> > against fixed thresholds, it indicates that a more sophisticated
> > discrimination mechanism would be needed. Perhaps one that takes multiple
> > successive measurements into account?
>
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
>
> Find some remotes and receivers that break the current system.
Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
ported over the weekend, but this remote just won't decode correctly w/the
in-kernel RC5 decoder.
Working:
Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
Streamzap receiver + RC5 (Streamzap) remote, lirc decoding
Not working:
Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding
Failure mode is identical between the two, leading me to believe my
streamzap port is good to go, we just have an issue to track down with rc5
decoding.
Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
space provided by both receivers, then gets rolling with (I believe) the
first pulse. It then gets all the way to STATE_FINISHED, and bails,
because it should be on a space there, but its on a pulse.
I've twiddled the decoder to proceed even if its a pulse, but the
resulting decoding is still no good, as multiple adjacent keys (which have
proper decoded values that only differ by 1, per lirc decoding) get
decoded to the same value as one another.
Still poking around trying to figure out the problem, but here's what the
(slightly modified to not bail when it gets to STATE_FINISHED with a
pulse) rc5 decoder is seeing/doing:
ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
ir_rc5_decode: RC5 usually ends w/space, wtf?
ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
ir_getkeycode: unknown key for scancode 0x1129
This was for the OK button on the remote, which in lircd, decodes to
scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons.
At least, I think I'm decoding lircd.conf correctly. See here to be sure:
http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap
On Mon, Aug 2, 2010 at 11:12 AM, Jarod Wilson <jarod@redhat.com> wrote:
> On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> ...
>> > Since these two protocols have such close timings that systematic errors
>> > can cause misclassification when using simple mark or space measurements
>> > against fixed thresholds, it indicates that a more sophisticated
>> > discrimination mechanism would be needed. Perhaps one that takes multiple
>> > successive measurements into account?
>>
>> If we get to the point where we need more sophisticated
>> classifications we can build it. But are we at that point yet? I'd
>> prefer to initially leave everything pretty strict as a way of
>> flushing out driver implementation bugs.
>>
>> Find some remotes and receivers that break the current system.
>
> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> ported over the weekend, but this remote just won't decode correctly w/the
> in-kernel RC5 decoder.
Manchester encoding may need a decoder that waits to get 2-3 edge
changes before deciding what the first bit. As you decode the output
is always a couple bits behind the current input data.
You can build of a table of states
L0 S1 S0 L1 - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge
By doing it that way you don't have to initially figure out the bit clock.
The current decoder code may not be properly tracking the leading
zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
off by 1/2 a bit cycle.
Did you note the comment that Extended RC-5 has only a single start
bit instead of two?
>
> Working:
> Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
> Streamzap receiver + RC5 (Streamzap) remote, lirc decoding
>
> Not working:
> Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
> MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding
>
> Failure mode is identical between the two, leading me to believe my
> streamzap port is good to go, we just have an issue to track down with rc5
> decoding.
>
> Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
> space provided by both receivers, then gets rolling with (I believe) the
> first pulse. It then gets all the way to STATE_FINISHED, and bails,
> because it should be on a space there, but its on a pulse.
>
> I've twiddled the decoder to proceed even if its a pulse, but the
> resulting decoding is still no good, as multiple adjacent keys (which have
> proper decoded values that only differ by 1, per lirc decoding) get
> decoded to the same value as one another.
>
> Still poking around trying to figure out the problem, but here's what the
> (slightly modified to not bail when it gets to STATE_FINISHED with a
> pulse) rc5 decoder is seeing/doing:
>
> ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
> ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
> ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
> ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
> ir_rc5_decode: RC5 usually ends w/space, wtf?
> ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
> ir_getkeycode: unknown key for scancode 0x1129
>
> This was for the OK button on the remote, which in lircd, decodes to
> scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons.
> At least, I think I'm decoding lircd.conf correctly. See here to be sure:
>
> http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap
>
> --
> Jarod Wilson
> jarod@redhat.com
>
>
Hi!
Jon Smirl "jonsmirl@gmail.com" wrote:
[...]
>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> ported over the weekend, but this remote just won't decode correctly w/the
>> in-kernel RC5 decoder.
> Manchester encoding may need a decoder that waits to get 2-3 edge
> changes before deciding what the first bit. As you decode the output
> is always a couple bits behind the current input data.
>
> You can build of a table of states
> L0 S1 S0 L1 - emit a 1, move forward an edge
> S0 S1 L0 L1 - emit a 0, move forward an edge
>
> By doing it that way you don't have to initially figure out the bit clock.
>
> The current decoder code may not be properly tracking the leading
> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> off by 1/2 a bit cycle.
>
> Did you note the comment that Extended RC-5 has only a single start
> bit instead of two?
It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13.
The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5.
Did I mention this already? Yes. ;-)
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> Hi!
>
> Jon Smirl "jonsmirl@gmail.com" wrote:
> [...]
>>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>>> ported over the weekend, but this remote just won't decode correctly w/the
>>> in-kernel RC5 decoder.
>
>> Manchester encoding may need a decoder that waits to get 2-3 edge
>> changes before deciding what the first bit. As you decode the output
>> is always a couple bits behind the current input data.
>>
>> You can build of a table of states
>> L0 S1 S0 L1 - emit a 1, move forward an edge
>> S0 S1 L0 L1 - emit a 0, move forward an edge
>>
>> By doing it that way you don't have to initially figure out the bit clock.
>>
>> The current decoder code may not be properly tracking the leading
>> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
>> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
>> off by 1/2 a bit cycle.
>>
>> Did you note the comment that Extended RC-5 has only a single start
>> bit instead of two?
>
> It has nothing to do with start bits.
> The Streamzap remote just sends 14 (sic!) bits instead of 13.
> The decoder expects 13 bits.
> Yes, the Streamzap remote does _not_ use standard RC-5.
> Did I mention this already? Yes. ;-)
If the remote is sending a weird protocol then there are several choices:
1) implement raw mode
2) make a Stream-Zap protocol engine (it would be a 14b version of
RC-5). Standard RC5 engine will still reject the messages.
3) throw away your Stream-Zap remotes
I'd vote for #3, but #2 will probably make people happier.
>
> Christoph
>
On Mon, Aug 02, 2010 at 06:42:00PM +0200, Christoph Bartelmus wrote:
> Hi!
>
> Jon Smirl "jonsmirl@gmail.com" wrote:
> [...]
> >> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >> ported over the weekend, but this remote just won't decode correctly w/the
> >> in-kernel RC5 decoder.
>
> > Manchester encoding may need a decoder that waits to get 2-3 edge
> > changes before deciding what the first bit. As you decode the output
> > is always a couple bits behind the current input data.
> >
> > You can build of a table of states
> > L0 S1 S0 L1 - emit a 1, move forward an edge
> > S0 S1 L0 L1 - emit a 0, move forward an edge
> >
> > By doing it that way you don't have to initially figure out the bit clock.
> >
> > The current decoder code may not be properly tracking the leading
> > zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> > They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> > off by 1/2 a bit cycle.
> >
> > Did you note the comment that Extended RC-5 has only a single start
> > bit instead of two?
>
> It has nothing to do with start bits.
> The Streamzap remote just sends 14 (sic!) bits instead of 13.
> The decoder expects 13 bits.
> Yes, the Streamzap remote does _not_ use standard RC-5.
> Did I mention this already? Yes. ;-)
D'oh, yeah, sorry, completely forgot you already mentioned this. That
would certainly explain why the rc5 decoder isn't happy with it. So the
*receiver* itself is perfectly functional, its just a goofy IR protocol
sent by its default remote. Blah. So yet another reason having ongoing
lirc compatibility is a Good Thing. ;)
On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> > Hi!
> >
> > Jon Smirl "jonsmirl@gmail.com" wrote:
> > [...]
> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >>> ported over the weekend, but this remote just won't decode correctly w/the
> >>> in-kernel RC5 decoder.
> >
> >> Manchester encoding may need a decoder that waits to get 2-3 edge
> >> changes before deciding what the first bit. As you decode the output
> >> is always a couple bits behind the current input data.
> >>
> >> You can build of a table of states
> >> L0 S1 S0 L1 - emit a 1, move forward an edge
> >> S0 S1 L0 L1 - emit a 0, move forward an edge
> >>
> >> By doing it that way you don't have to initially figure out the bit clock.
> >>
> >> The current decoder code may not be properly tracking the leading
> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> >> off by 1/2 a bit cycle.
> >>
> >> Did you note the comment that Extended RC-5 has only a single start
> >> bit instead of two?
> >
> > It has nothing to do with start bits.
> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
> > The decoder expects 13 bits.
> > Yes, the Streamzap remote does _not_ use standard RC-5.
> > Did I mention this already? Yes. ;-)
>
> If the remote is sending a weird protocol then there are several choices:
> 1) implement raw mode
> 2) make a Stream-Zap protocol engine (it would be a 14b version of
> RC-5). Standard RC5 engine will still reject the messages.
> 3) throw away your Stream-Zap remotes
>
> I'd vote for #3, but #2 will probably make people happier.
Hm. Yeah, I know a few people who are quite attached to their Streamzap
remotes. I'm not a particularly big fan of it, I only got the thing off
ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
probably not the best route. But I don't know that I'm a huge fan of #2
either. Another decoder engine just for one quirky remote seems excessive,
and there's an option #4:
4) just keep passing data out to lirc by default.
Let lircd handle the default remote in this case. If you want to use
another remote that actually uses a standard protocol, and want to use
in-kernel decoding for that, its just an ir-keytable call away.
For giggles, I may tinker with implementing another decoder engine though,
if only to force myself to actually pay more attention to protocol
specifics. For the moment, I'm inclined to go ahead with the streamzap
port as it is right now, and include either an empty or not-empty, but
not-functional key table.
On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>> > Hi!
>> >
>> > Jon Smirl "jonsmirl@gmail.com" wrote:
>> > [...]
>> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> >>> ported over the weekend, but this remote just won't decode correctly w/the
>> >>> in-kernel RC5 decoder.
>> >
>> >> Manchester encoding may need a decoder that waits to get 2-3 edge
>> >> changes before deciding what the first bit. As you decode the output
>> >> is always a couple bits behind the current input data.
>> >>
>> >> You can build of a table of states
>> >> L0 S1 S0 L1 - emit a 1, move forward an edge
>> >> S0 S1 L0 L1 - emit a 0, move forward an edge
>> >>
>> >> By doing it that way you don't have to initially figure out the bit clock.
>> >>
>> >> The current decoder code may not be properly tracking the leading
>> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
>> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
>> >> off by 1/2 a bit cycle.
>> >>
>> >> Did you note the comment that Extended RC-5 has only a single start
>> >> bit instead of two?
>> >
>> > It has nothing to do with start bits.
>> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
>> > The decoder expects 13 bits.
>> > Yes, the Streamzap remote does _not_ use standard RC-5.
>> > Did I mention this already? Yes. ;-)
>>
>> If the remote is sending a weird protocol then there are several choices:
>> 1) implement raw mode
>> 2) make a Stream-Zap protocol engine (it would be a 14b version of
>> RC-5). Standard RC5 engine will still reject the messages.
>> 3) throw away your Stream-Zap remotes
>>
>> I'd vote for #3, but #2 will probably make people happier.
>
> Hm. Yeah, I know a few people who are quite attached to their Streamzap
> remotes. I'm not a particularly big fan of it, I only got the thing off
> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
> probably not the best route. But I don't know that I'm a huge fan of #2
> either. Another decoder engine just for one quirky remote seems excessive,
> and there's an option #4:
>
> 4) just keep passing data out to lirc by default.
That's a decent idea. Implement the mainstream, standard protocols in
the kernel and kick the weird stuff out to LIRC. We can avoid the
whole world of raw mode, config files, etc. Let LIRC deal with all
that. If the weird stuff gets enough users bring it in-kernel. Maybe
StreamZap will suddenly sell a million units, you never know.
It is easy to implement a StreamZap engine. Just copy the RC5 one.
Rename everything and adjust it to require one more bit. You'll have
to modify the RC5 to wait for a bit interval (timeout) before sending
the data up. If you want to get fancy use a weak symbol in the
StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
you can decide to wait the extra bit interval or not.
> Let lircd handle the default remote in this case. If you want to use
> another remote that actually uses a standard protocol, and want to use
> in-kernel decoding for that, its just an ir-keytable call away.
>
> For giggles, I may tinker with implementing another decoder engine though,
> if only to force myself to actually pay more attention to protocol
> specifics. For the moment, I'm inclined to go ahead with the streamzap
> port as it is right now, and include either an empty or not-empty, but
> not-functional key table.
>
> --
> Jarod Wilson
> jarod@redhat.com
>
>
On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
>> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
...
>>> > It has nothing to do with start bits.
>>> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
>>> > The decoder expects 13 bits.
>>> > Yes, the Streamzap remote does _not_ use standard RC-5.
>>> > Did I mention this already? Yes. ;-)
>>>
>>> If the remote is sending a weird protocol then there are several choices:
>>> 1) implement raw mode
>>> 2) make a Stream-Zap protocol engine (it would be a 14b version of
>>> RC-5). Standard RC5 engine will still reject the messages.
>>> 3) throw away your Stream-Zap remotes
>>>
>>> I'd vote for #3, but #2 will probably make people happier.
>>
>> Hm. Yeah, I know a few people who are quite attached to their Streamzap
>> remotes. I'm not a particularly big fan of it, I only got the thing off
>> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
>> probably not the best route. But I don't know that I'm a huge fan of #2
>> either. Another decoder engine just for one quirky remote seems excessive,
>> and there's an option #4:
>>
>> 4) just keep passing data out to lirc by default.
>
> That's a decent idea. Implement the mainstream, standard protocols in
> the kernel and kick the weird stuff out to LIRC. We can avoid the
> whole world of raw mode, config files, etc. Let LIRC deal with all
> that. If the weird stuff gets enough users bring it in-kernel. Maybe
> StreamZap will suddenly sell a million units, you never know.
>
> It is easy to implement a StreamZap engine. Just copy the RC5 one.
> Rename everything and adjust it to require one more bit. You'll have
> to modify the RC5 to wait for a bit interval (timeout) before sending
> the data up. If you want to get fancy use a weak symbol in the
> StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
> you can decide to wait the extra bit interval or not.
The other thought I had was to not load the engine by default, and
only auto-load it from the streamzap driver itself.
>> Let lircd handle the default remote in this case. If you want to use
>> another remote that actually uses a standard protocol, and want to use
>> in-kernel decoding for that, its just an ir-keytable call away.
>>
>> For giggles, I may tinker with implementing another decoder engine though,
>> if only to force myself to actually pay more attention to protocol
>> specifics. For the moment, I'm inclined to go ahead with the streamzap
>> port as it is right now, and include either an empty or not-empty, but
>> not-functional key table.
So I spent a while beating on things the past few nights for giggles
(and for a sanity break from "vacation" with too many kids...). I
ended up doing a rather large amount of somewhat invasive work to the
streamzap driver itself, but the end result is functional in-kernel
decoding, and lirc userspace decode continues to behave correctly. RFC
patch here:
http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
Core changes to streamzap.c itself:
- had to enable reporting of a long space at the conclusion of each
signal (which is what the lirc driver would do w/timeout_enabled set),
otherwise I kept having issues with key bounce and/or old data being
buffered (i.e., press up, cursor moves up. push down, cursor moves up
then down, press left, it moves down, then left, etc.). Still not
quite sure what the real problem is there, the lirc userspace decoder
has no problems with it either way.
- removed streamzap's internal delay buffer, as the ir-core kfifo
seems to provide the necessary signal buffering just fine by itself.
Can't see any significant difference in decode performance either
in-kernel or via lirc with it removed, anyway. (Christoph, can you
perhaps expand a bit on why the delay buffer was originally needed/how
to reproduce the problem it was intended to solve? Maybe I'm just not
triggering it yet.)
Other fun stuff to note:
- currently, loading up an rc5-sz decoder unconditionally, have
considered only auto-loading it from the streamzap driver itself. Its
a copy of the rc5 decoder with relatively minor tweaks to deal with
the extra bit and resulting slightly different bit layout. Might
actually be possible to merge back into the rc5 decoder itself,
haven't really looked into that yet (should be entirely doable if
there's an easy way to figure out early on if we need to grab 15
bits).
- not sure the decoder is 100% correct, but it does get to the same
scancodes as the lirc userspace now (with both a streamzap and mceusb
receiver).
Hi Jarod,
on 11 Aug 10 at 10:38, Jarod Wilson wrote:
> On Mon, Aug 2, 2010 at 4:42 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson <jarod@redhat.com> wrote:
>>> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>>>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus <lirc@bartelmus.de>
>>>> wrote:
> ....
>>>>> It has nothing to do with start bits.
>>>>> The Streamzap remote just sends 14 (sic!) bits instead of 13.
>>>>> The decoder expects 13 bits.
>>>>> Yes, the Streamzap remote does _not_ use standard RC-5.
>>>>> Did I mention this already? Yes. ;-)
>>>>
>>>> If the remote is sending a weird protocol then there are several choices:
>>>> 1) implement raw mode
>>>> 2) make a Stream-Zap protocol engine (it would be a 14b version of
>>>> RC-5). Standard RC5 engine will still reject the messages.
>>>> 3) throw away your Stream-Zap remotes
>>>>
>>>> I'd vote for #3, but #2 will probably make people happier.
>>>
>>> Hm. Yeah, I know a few people who are quite attached to their Streamzap
>>> remotes. I'm not a particularly big fan of it, I only got the thing off
>>> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
>>> probably not the best route. But I don't know that I'm a huge fan of #2
>>> either. Another decoder engine just for one quirky remote seems excessive,
>>> and there's an option #4:
>>>
>>> 4) just keep passing data out to lirc by default.
>>
>> That's a decent idea. Implement the mainstream, standard protocols in
>> the kernel and kick the weird stuff out to LIRC. We can avoid the
>> whole world of raw mode, config files, etc. Let LIRC deal with all
>> that. If the weird stuff gets enough users bring it in-kernel. Maybe
>> StreamZap will suddenly sell a million units, you never know.
>>
>> It is easy to implement a StreamZap engine. Just copy the RC5 one.
>> Rename everything and adjust it to require one more bit. You'll have
>> to modify the RC5 to wait for a bit interval (timeout) before sending
>> the data up. If you want to get fancy use a weak symbol in the
>> StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
>> you can decide to wait the extra bit interval or not.
> The other thought I had was to not load the engine by default, and
> only auto-load it from the streamzap driver itself.
>>> Let lircd handle the default remote in this case. If you want to use
>>> another remote that actually uses a standard protocol, and want to use
>>> in-kernel decoding for that, its just an ir-keytable call away.
>>>
>>> For giggles, I may tinker with implementing another decoder engine though,
>>> if only to force myself to actually pay more attention to protocol
>>> specifics. For the moment, I'm inclined to go ahead with the streamzap
>>> port as it is right now, and include either an empty or not-empty, but
>>> not-functional key table.
> So I spent a while beating on things the past few nights for giggles
> (and for a sanity break from "vacation" with too many kids...). I
> ended up doing a rather large amount of somewhat invasive work to the
> streamzap driver itself, but the end result is functional in-kernel
> decoding, and lirc userspace decode continues to behave correctly. RFC
> patch here:
>
> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
>
> Core changes to streamzap.c itself:
>
> - had to enable reporting of a long space at the conclusion of each
> signal (which is what the lirc driver would do w/timeout_enabled set),
> otherwise I kept having issues with key bounce and/or old data being
> buffered (i.e., press up, cursor moves up. push down, cursor moves up
> then down, press left, it moves down, then left, etc.). Still not
> quite sure what the real problem is there, the lirc userspace decoder
> has no problems with it either way.
>
> - removed streamzap's internal delay buffer, as the ir-core kfifo
> seems to provide the necessary signal buffering just fine by itself.
> Can't see any significant difference in decode performance either
> in-kernel or via lirc with it removed, anyway. (Christoph, can you
> perhaps expand a bit on why the delay buffer was originally needed/how
> to reproduce the problem it was intended to solve? Maybe I'm just not
> triggering it yet.)
Should be fine. Current lircd with timeout support shouldn't have a
problem with that anymore. I was already thinking of suggesting to remove
the delay buffer.
>
> Other fun stuff to note:
>
> - currently, loading up an rc5-sz decoder unconditionally, have
> considered only auto-loading it from the streamzap driver itself. Its
> a copy of the rc5 decoder with relatively minor tweaks to deal with
> the extra bit and resulting slightly different bit layout. Might
> actually be possible to merge back into the rc5 decoder itself,
> haven't really looked into that yet (should be entirely doable if
> there's an easy way to figure out early on if we need to grab 14
> bits).
There is no way until you see the 14th bit.
> - not sure the decoder is 100% correct, but it does get to the same
> scancodes as the lirc userspace now (with both a streamzap and mceusb
> receiver).
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
...
>> So I spent a while beating on things the past few nights for giggles
>> (and for a sanity break from "vacation" with too many kids...). I
>> ended up doing a rather large amount of somewhat invasive work to the
>> streamzap driver itself, but the end result is functional in-kernel
>> decoding, and lirc userspace decode continues to behave correctly. RFC
>> patch here:
>>
>> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
>>
>> Core changes to streamzap.c itself:
>>
>> - had to enable reporting of a long space at the conclusion of each
>> signal (which is what the lirc driver would do w/timeout_enabled set),
>> otherwise I kept having issues with key bounce and/or old data being
>> buffered (i.e., press up, cursor moves up. push down, cursor moves up
>> then down, press left, it moves down, then left, etc.). Still not
>> quite sure what the real problem is there, the lirc userspace decoder
>> has no problems with it either way.
>>
>> - removed streamzap's internal delay buffer, as the ir-core kfifo
>> seems to provide the necessary signal buffering just fine by itself.
>> Can't see any significant difference in decode performance either
>> in-kernel or via lirc with it removed, anyway. (Christoph, can you
>> perhaps expand a bit on why the delay buffer was originally needed/how
>> to reproduce the problem it was intended to solve? Maybe I'm just not
>> triggering it yet.)
>
> Should be fine. Current lircd with timeout support shouldn't have a
> problem with that anymore. I was already thinking of suggesting to remove
> the delay buffer.
Cool, sounds like a plan then, I'll go ahead with it.
>> Other fun stuff to note:
>>
>> - currently, loading up an rc5-sz decoder unconditionally, have
>> considered only auto-loading it from the streamzap driver itself. Its
>> a copy of the rc5 decoder with relatively minor tweaks to deal with
>> the extra bit and resulting slightly different bit layout. Might
>> actually be possible to merge back into the rc5 decoder itself,
>> haven't really looked into that yet (should be entirely doable if
>> there's an easy way to figure out early on if we need to grab 14
>> bits).
>
> There is no way until you see the 14th bit.
Hm. Was afraid of that. I gave it a shot to see if I could make that
work, pretty shaky results. About 2/3 of the keys get decoded as
15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't
match anything in the keytable (and often duplicate one another). So
it looks like at least for the time being, a separate parallel decoder
is the way to go. I'm thinking that I like the approach of only
explicitly loading it from the streamzap driver though.
On Mon, 2010-08-16 at 00:04 -0400, Jarod Wilson wrote:
> On Thu, Aug 12, 2010 at 2:46 AM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
> ...
> >> So I spent a while beating on things the past few nights for giggles
> >> (and for a sanity break from "vacation" with too many kids...). I
> >> ended up doing a rather large amount of somewhat invasive work to the
> >> streamzap driver itself, but the end result is functional in-kernel
> >> decoding, and lirc userspace decode continues to behave correctly. RFC
> >> patch here:
> >>
> >> http://wilsonet.com/jarod/ir-core/IR-streamzap-in-kernel-decode.patch
> >>
> >> Core changes to streamzap.c itself:
> >>
> >> - had to enable reporting of a long space at the conclusion of each
> >> signal (which is what the lirc driver would do w/timeout_enabled set),
> >> otherwise I kept having issues with key bounce and/or old data being
> >> buffered (i.e., press up, cursor moves up. push down, cursor moves up
> >> then down, press left, it moves down, then left, etc.). Still not
> >> quite sure what the real problem is there, the lirc userspace decoder
> >> has no problems with it either way.
> >>
> >> - removed streamzap's internal delay buffer, as the ir-core kfifo
> >> seems to provide the necessary signal buffering just fine by itself.
> >> Can't see any significant difference in decode performance either
> >> in-kernel or via lirc with it removed, anyway. (Christoph, can you
> >> perhaps expand a bit on why the delay buffer was originally needed/how
> >> to reproduce the problem it was intended to solve? Maybe I'm just not
> >> triggering it yet.)
> >
> > Should be fine. Current lircd with timeout support shouldn't have a
> > problem with that anymore. I was already thinking of suggesting to remove
> > the delay buffer.
>
> Cool, sounds like a plan then, I'll go ahead with it.
>
> >> Other fun stuff to note:
> >>
> >> - currently, loading up an rc5-sz decoder unconditionally, have
> >> considered only auto-loading it from the streamzap driver itself. Its
> >> a copy of the rc5 decoder with relatively minor tweaks to deal with
> >> the extra bit and resulting slightly different bit layout. Might
> >> actually be possible to merge back into the rc5 decoder itself,
> >> haven't really looked into that yet (should be entirely doable if
> >> there's an easy way to figure out early on if we need to grab 14
> >> bits).
> >
> > There is no way until you see the 14th bit.
>
> Hm. Was afraid of that. I gave it a shot to see if I could make that
> work, pretty shaky results. About 2/3 of the keys get decoded as
> 15-bit streamzap, the other 1/3 get decoded as 14-bit RC5, and don't
> match anything in the keytable (and often duplicate one another). So
> it looks like at least for the time being, a separate parallel decoder
> is the way to go. I'm thinking that I like the approach of only
> explicitly loading it from the streamzap driver though.
Just one minor nitpick.
You could 'use' the original RC5 decoder, but add a knob to it to make
it accept 15 bits instead of 14.
However, this will require some interface changes.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 16, 2010 at 11:30 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 16-08-2010 21:14, Jarod Wilson escreveu:
>
>>> Just one minor nitpick.
>>> You could 'use' the original RC5 decoder, but add a knob to it to make
>>> it accept 15 bits instead of 14.
>>> However, this will require some interface changes.
>>
>> Well, I think that still falls down if someone, for some reason, wants
>> to use both an old RC5 remote and the Streamzap remote at the same
>> time. I think a parallel decoder is probably the best situation for
>> the moment, as both 14-bit RC5 and Streamzap RC5 can be decoded
>> simultaneously.
>
> One option could be to change rc5 decoder to work with 3 different modes,
> controlled by a sysfs node:
> 1) just 14 bits code;
> 2) just 15 bits code;
> 3) both 14 and 15 bits code.
>
> For (3), it will need a timeout logic for a short period (like 2T), for the
> 15th bit. If nothing happens, it will assume it is 14 bits, producing a code
> and resetting the finite-state machine.
>
> By default, it would be working on 14-bits mode for normal RC decoders, and
> on 15-bits mode for Streamzap.
>
> Yet, IMHO, the better is to commit what you have currently. Just my 2 cents.
Yeah, I don't doubt that we *could* come up with some way to make them
coexist in the same decoder, but I think its probably not worth the
effort or added complexity over simply having a separate parallel
decoder (which is only loaded by default if the receiver bundled with
the funky remote is plugged in).
@@ -2188,6 +2188,12 @@ F: drivers/misc/cb710/
F: drivers/mmc/host/cb710-mmc.*
F: include/linux/cb710.h
+ENE KB2426 (ENE0100/ENE020XX) INFRARED RECEIVER
+M: Maxim Levitsky <maximlevitsky@gmail.com>
+S: Maintained
+F: drivers/media/IR/ene_ir.c
+F: drivers/media/IR/ene_ir.h
+
EPSON 1355 FRAMEBUFFER DRIVER
M: Christopher Hoover <ch@murgatroid.com>
M: Christopher Hoover <ch@hpl.hp.com>
@@ -105,4 +105,18 @@ config IR_MCEUSB
To compile this driver as a module, choose M here: the
module will be called mceusb.
+config IR_ENE
+ tristate "ENE eHome Receiver/Transciever (pnp id: ENE0100/ENE02xxx)"
+ depends on PNP
+ depends on IR_CORE
+ ---help---
+ Say Y here to enable support for integrated infrared receiver
+ /transciever made by ENE.
+
+ You can see if you have it by looking at lspnp output.
+ Output should include ENE0100 ENE0200 or something similiar.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ene_ir.
+
endif #IR_CORE
@@ -16,3 +16,4 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_ENE) += ene_ir.o
@@ -1,5 +1,5 @@
/*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ * driver for ENE KB3926 B/C/D CIR (pnp id: ENE0XXX)
*
* Copyright (C) 2010 Maxim Levitsky <maximlevitsky@gmail.com>
*
@@ -25,20 +25,21 @@
#include <linux/io.h>
#include <linux/interrupt.h>
#include <linux/sched.h>
-#include <linux/uaccess.h>
-#include "lirc_ene0100.h"
+#include <linux/slab.h>
+#include <linux/input.h>
+#include <media/ir-core.h>
+#include <media/ir-common.h>
+#include "ene_ir.h"
static int sample_period = -1;
static int enable_idle = 1;
-static int enable_duty_carrier;
+static int error_adjustment = 4;
static int input = 1;
static int debug;
static int txsim;
-static void ene_rx_set_idle(struct ene_device *dev, int idle);
static int ene_irq_status(struct ene_device *dev);
-static void ene_send_sample(struct ene_device *dev, unsigned long sample);
/* read a hardware register */
static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
@@ -160,7 +161,7 @@ static int ene_hw_detect(struct ene_device *dev)
}
/* this enables/disables IR input via gpio40*/
-static void ene_enable_gpio40_recieve(struct ene_device *dev, int enable)
+static void ene_enable_gpio40_receive(struct ene_device *dev, int enable)
{
ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, enable ?
0 : ENE_CIR_CONF2_GPIO40DIS,
@@ -168,13 +169,13 @@ static void ene_enable_gpio40_recieve(struct ene_device *dev, int enable)
}
/* this enables/disables IR via standard input */
-static void ene_enable_normal_recieve(struct ene_device *dev, int enable)
+static void ene_enable_normal_receive(struct ene_device *dev, int enable)
{
ene_hw_write_reg(dev, ENE_CIR_CONF1, enable ? ENE_CIR_CONF1_RX_ON : 0);
}
/* this enables/disables IR input via unused fan tachtometer input */
-static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
+static void ene_enable_fan_receive(struct ene_device *dev, int enable)
{
if (!enable)
ene_hw_write_reg(dev, ENE_FAN_AS_IN1, 0);
@@ -186,7 +187,7 @@ static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
}
-/* Sense current recieved carrier */
+/* Sense current received carrier */
static int ene_rx_sense_carrier(struct ene_device *dev)
{
int period = ene_hw_read_reg(dev, ENE_RX_CARRIER);
@@ -209,37 +210,37 @@ static int ene_rx_sense_carrier(struct ene_device *dev)
/* determine which input to use*/
static void ene_rx_set_inputs(struct ene_device *dev)
{
- int learning_mode = dev->learning_enabled || dev->rx_carrier_sense;
+ int learning_mode = dev->learning_enabled;
- ene_dbg("RX: setup reciever, learning mode = %d", learning_mode);
+ ene_dbg("RX: setup receiver, learning mode = %d", learning_mode);
- ene_enable_normal_recieve(dev, 1);
+ ene_enable_normal_receive(dev, 1);
/* old hardware doesn't support learning mode for sure */
if (dev->hw_revision <= ENE_HW_B)
return;
- /* reciever not learning capable, still set gpio40 correctly */
+ /* receiver not learning capable, still set gpio40 correctly */
if (!dev->hw_learning_and_tx_capable) {
- ene_enable_gpio40_recieve(dev, !dev->hw_gpio40_learning);
+ ene_enable_gpio40_receive(dev, !dev->hw_gpio40_learning);
return;
}
/* enable learning mode */
if (learning_mode) {
- ene_enable_gpio40_recieve(dev, dev->hw_gpio40_learning);
+ ene_enable_gpio40_receive(dev, dev->hw_gpio40_learning);
/* fan input is not used for learning */
if (dev->hw_fan_as_normal_input)
- ene_enable_fan_recieve(dev, 0);
+ ene_enable_fan_receive(dev, 0);
/* disable learning mode */
} else {
if (dev->hw_fan_as_normal_input) {
- ene_enable_fan_recieve(dev, 1);
- ene_enable_normal_recieve(dev, 0);
+ ene_enable_fan_receive(dev, 1);
+ ene_enable_normal_receive(dev, 0);
} else
- ene_enable_gpio40_recieve(dev,
+ ene_enable_gpio40_receive(dev,
!dev->hw_gpio40_learning);
}
@@ -249,6 +250,16 @@ static void ene_rx_set_inputs(struct ene_device *dev)
ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, learning_mode ?
ENE_CIR_CONF2_LEARN2 : 0, ENE_CIR_CONF2_LEARN2);
+
+ if (dev->rx_fan_input_inuse) {
+ dev->props->rx_resolution = ENE_SAMPLE_PERIOD_FAN * 1000;
+
+ dev->props->timeout =
+ ENE_FAN_VALUE_MASK * ENE_SAMPLE_PERIOD_FAN * 1000;
+ } else {
+ dev->props->rx_resolution = sample_period * 1000;
+ dev->props->timeout = ENE_MAXGAP * 1000;
+ }
}
/* Enable the device for receive */
@@ -277,147 +288,33 @@ static void ene_rx_enable(struct ene_device *dev)
/* ack any pending irqs - just in case */
ene_irq_status(dev);
- /* enter idle mode */
- ene_rx_set_idle(dev, 1);
-
/* enable firmware bits */
ene_hw_write_reg_mask(dev, ENE_FW1,
ENE_FW1_ENABLE | ENE_FW1_IRQ,
ENE_FW1_ENABLE | ENE_FW1_IRQ);
+
+ /* enter idle mode */
+ ir_raw_event_set_idle(dev->idev, 1);
+ ir_raw_event_reset(dev->idev);
+
}
-/* Disable the device reciever */
+/* Disable the device receiver */
static void ene_rx_disable(struct ene_device *dev)
{
/* disable inputs */
- ene_enable_normal_recieve(dev, 0);
+ ene_enable_normal_receive(dev, 0);
if (dev->hw_fan_as_normal_input)
- ene_enable_fan_recieve(dev, 0);
+ ene_enable_fan_receive(dev, 0);
/* disable hardware IRQ and firmware flag */
ene_hw_write_reg_mask(dev, ENE_FW1, 0, ENE_FW1_ENABLE | ENE_FW1_IRQ);
- ene_rx_set_idle(dev, 1);
-}
-
-/* send current sample to the user */
-static void ene_rx_flush(struct ene_device *dev, int timeout)
-{
- unsigned long value;
-
- value = dev->rx_sample_pulse ? LIRC_PULSE(dev->rx_sample) :
- LIRC_SPACE(dev->rx_sample);
- ene_send_sample(dev, value);
- dev->rx_sample = 0;
- dev->rx_sample_pulse = 0;
+ ir_raw_event_set_idle(dev->idev, 1);
+ ir_raw_event_reset(dev->idev);
}
-/* recieve new sample and process it */
-static void ene_rx_sample(struct ene_device *dev, int sample, int is_pulse)
-{
- ene_dbg("RX: sample %8d (%s)", sample, is_pulse ? "pulse" : "space");
-
- /* ignore spaces in idle mode, can get them on revC */
- /* also ignore a space in front of first pulse */
- if (dev->rx_idle && !is_pulse)
- return;
-
- /* get out of idle mode now */
- if (dev->rx_idle)
- ene_rx_set_idle(dev, 0);
-
- if (!dev->rx_sample) {
- dev->rx_sample = sample;
- dev->rx_sample_pulse = is_pulse;
- } else if (is_pulse == dev->rx_sample_pulse)
- dev->rx_sample += sample;
- else {
- ene_rx_flush(dev, 0);
- dev->rx_sample = sample;
- dev->rx_sample_pulse = is_pulse;
- }
-
- if (is_pulse)
- return;
-
- /* overflow sample from fan input recieved, enable idle mode */
- if (dev->rx_fan_input_inuse &&
- sample == ENE_FAN_VALUE_MASK * ENE_SAMPLE_PERIOD_FAN) {
- ene_rx_set_idle(dev, 1);
- return;
- }
-
- if (!dev->rx_fan_input_inuse) {
- /* Report timeout if enabled */
- if (dev->rx_timeout && dev->rx_send_timeout_packet &&
- !dev->rx_timeout_sent &&
- dev->rx_sample > dev->rx_timeout) {
- ene_dbg("RX: sending timeout sample");
- ene_send_sample(dev, LIRC_TIMEOUT(dev->rx_sample));
- dev->rx_timeout_sent = 1;
- }
-
- /* too large sample accumulated via normal input.
- note that on revC, hardware idle mode turns on automaticly,
- so max gap should be less that the gap after which
- hw stops sending samples */
- if (dev->rx_sample > ENE_MAXGAP) {
- ene_rx_set_idle(dev, 1);
- return;
- }
- }
-}
-
-/* enable or disable idle mode */
-static void ene_rx_set_idle(struct ene_device *dev, int idle)
-{
- struct timeval now;
- int disable_sampler = 0;
-
-
- /* Also put hardware sampler in 'idle' mode on revB*/
- /* revC and higher do that automaticly (firmware does?) */
- if ((dev->hw_revision < ENE_HW_C) && enable_idle)
- if (idle)
- disable_sampler = 1;
-
- ene_hw_write_reg_mask(dev, ENE_CIR_SAMPLE_PERIOD,
- disable_sampler ? 0 : ENE_CIR_SAMPLE_OVERFLOW,
- ENE_CIR_SAMPLE_OVERFLOW);
- dev->rx_idle = idle;
-
- /* remember when we have entered the idle mode */
- if (idle) {
- ene_dbg("RX: going into idle mode");
- do_gettimeofday(&dev->rx_gap_start);
- return;
- }
-
- ene_dbg("RX: back from idle mode");
-
- /* send the gap between keypresses now */
- do_gettimeofday(&now);
-
- if (dev->rx_sample_pulse) {
- ene_dbg("RX: somehow we recieved a pulse before idle mode???");
- return;
- }
-
- /* manually calculate and recieve the gap between keypresses */
- if (now.tv_sec - dev->rx_gap_start.tv_sec > 16)
- dev->rx_sample = LIRC_SPACE(LIRC_VALUE_MASK);
- else
- dev->rx_sample +=
- 1000000ull * (now.tv_sec - dev->rx_gap_start.tv_sec)
- + now.tv_usec - dev->rx_gap_start.tv_usec;
-
- if (dev->rx_sample > LIRC_SPACE(LIRC_VALUE_MASK))
- dev->rx_sample = LIRC_SPACE(LIRC_VALUE_MASK);
-
- ene_rx_flush(dev, 0);
- dev->rx_timeout_sent = 0;
-}
/* prepare transmission */
static void ene_tx_prepare(struct ene_device *dev)
@@ -436,6 +333,8 @@ static void ene_tx_prepare(struct ene_device *dev)
/* Set carrier */
if (dev->tx_period) {
+ /* NOTE: duty cycle handling is just a guess, it might
+ not be aviable. Default values were tested */
int tx_period_in500ns = dev->tx_period * 2;
int tx_pulse_width_in_500ns =
@@ -459,7 +358,6 @@ static void ene_tx_prepare(struct ene_device *dev)
conf1 &= ~ENE_CIR_CONF1_TX_CARR;
ene_hw_write_reg(dev, ENE_CIR_CONF1, conf1);
- dev->tx_underway = 1;
}
@@ -467,11 +365,11 @@ static void ene_tx_prepare(struct ene_device *dev)
static void ene_tx_complete(struct ene_device *dev)
{
ene_hw_write_reg(dev, ENE_CIR_CONF1, dev->saved_conf1);
- dev->tx_underway = 0;
+ dev->tx_buffer = NULL;
}
/* set transmit mask */
-static void ene_tx_set_transmiter_mask(struct ene_device *dev)
+static void ene_tx_hw_set_transmiter_mask(struct ene_device *dev)
{
u8 txport1 = ene_hw_read_reg(dev, ENE_TX_PORT1) & ~ENE_TX_PORT1_EN;
u8 txport2 = ene_hw_read_reg(dev, ENE_TX_PORT2) & ~ENE_TX_PORT2_EN;
@@ -492,8 +390,8 @@ static void ene_tx_sample(struct ene_device *dev)
u8 raw_tx;
u32 sample;
- if (!dev->tx_underway) {
- ene_dbg("TX: attempt to transmit while hw isn't setup");
+ if (!dev->tx_buffer) {
+ ene_dbg("TX: attempt to transmit NULL buffer");
return;
}
@@ -623,6 +521,7 @@ static irqreturn_t ene_isr(int irq, void *data)
int carrier = 0;
irqreturn_t retval = IRQ_NONE;
struct ene_device *dev = (struct ene_device *)data;
+ struct ir_raw_event ev;
spin_lock_irqsave(&dev->hw_lock, flags);
@@ -646,12 +545,13 @@ static irqreturn_t ene_isr(int irq, void *data)
goto unlock;
- if ((debug && dev->learning_enabled) || dev->rx_carrier_sense)
+ if (dev->carrier_detect_enabled || debug)
carrier = ene_rx_sense_carrier(dev);
-
- if (dev->rx_carrier_sense && carrier)
- ene_send_sample(dev, LIRC_FREQUENCY(carrier));
-
+#if 0
+ /* TODO */
+ if (dev->carrier_detect_enabled && carrier)
+ ir_raw_event_report_frequency(dev->idev, carrier);
+#endif
for (i = 0; i < ENE_SAMPLES_SIZE; i++) {
hw_value = ene_hw_read_reg(dev,
@@ -672,13 +572,25 @@ static irqreturn_t ene_isr(int irq, void *data)
pulse = !(hw_value & ENE_SAMPLE_SPC_MASK);
hw_value &= ENE_SAMPLE_VALUE_MASK;
hw_sample = hw_value * sample_period;
+
+ if (error_adjustment && error_adjustment < 100) {
+ hw_sample *= (100 - error_adjustment);
+ hw_sample /= 100;
+ }
}
/* no more data */
if (!(hw_value))
break;
- ene_rx_sample(dev, hw_sample, pulse);
+ ene_dbg("RX: %d (%s)", hw_sample, pulse ? "pulse" : "space");
+
+
+ ev.duration = hw_sample * 1000;
+ ev.pulse = pulse;
+ ir_raw_event_store_with_filter(dev->idev, &ev);
}
+
+ ir_raw_event_handle(dev->idev);
unlock:
spin_unlock_irqrestore(&dev->hw_lock, flags);
return retval;
@@ -687,8 +599,6 @@ unlock:
/* Initialize default settings */
static void ene_setup_settings(struct ene_device *dev)
{
- dev->rx_send_timeout_packet = 0;
- dev->rx_timeout = ENE_MAXGAP;
dev->tx_period = 32;
dev->tx_duty_cycle = 25; /*%*/
dev->transmitter_mask = 3;
@@ -698,11 +608,7 @@ static void ene_setup_settings(struct ene_device *dev)
dev->learning_enabled =
(input == 2 && dev->hw_learning_and_tx_capable);
- /* Clear accumulated sample bufer */
- dev->rx_sample = 0;
- dev->rx_sample_pulse = 0;
dev->rx_pointer = -1;
- dev->rx_carrier_sense = 0;
}
@@ -732,144 +638,97 @@ static void ene_close(void *data)
spin_unlock_irqrestore(&dev->hw_lock, flags);
}
-/* outside interface for settings */
-static int ene_ioctl(struct inode *node, struct file *file,
- unsigned int cmd, unsigned long arg)
+/* outside interface: set transmitter mask */
+static int ene_set_tx_mask(void *data, u32 tx_mask)
{
- int lvalue = 0, retval, tmp;
+ struct ene_device *dev = (struct ene_device *)data;
unsigned long flags;
- struct ene_device *dev = lirc_get_pdata(file);
-
-
- switch (cmd) {
- case LIRC_SET_SEND_CARRIER:
- case LIRC_SET_SEND_DUTY_CYCLE:
- case LIRC_SET_TRANSMITTER_MASK:
- case LIRC_SET_MEASURE_CARRIER_MODE:
- case LIRC_SET_REC_CARRIER:
- /* All these aren't possible without this */
- if (!dev->hw_learning_and_tx_capable)
- return -ENOSYS;
- /* Fall through */
- case LIRC_SET_REC_TIMEOUT:
- case LIRC_SET_REC_TIMEOUT_REPORTS:
- retval = get_user(lvalue, (unsigned int *) arg);
- if (retval)
- return retval;
+ ene_dbg("TX: attempt to set transmitter mask %02x", tx_mask);
+
+ /* invalid txmask */
+ if (!tx_mask || tx_mask & ~0x3) {
+ ene_dbg("TX: invalid mask");
+ /* return count of transmitters */
+ return 2;
}
- switch (cmd) {
- case LIRC_SET_SEND_CARRIER:
- ene_dbg("TX: attempt to set tx carrier to %d kHz", lvalue);
- tmp = 1000000 / lvalue; /* (1 / freq) (* # usec in 1 sec) */
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ dev->transmitter_mask = tx_mask;
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+ return 0;
+}
- if (tmp && (tmp > ENE_TX_PERIOD_MAX ||
- tmp < ENE_TX_PERIOD_MIN)) {
+/* outside interface : set tx carrier */
+static int ene_set_tx_carrier(void *data, u32 carrier)
+{
+ struct ene_device *dev = (struct ene_device *)data;
+ unsigned long flags;
+ u32 period = 1000000 / carrier; /* (1 / freq) (* # usec in 1 sec) */
- ene_dbg("TX: out of range %d-%d carrier, "
- "falling back to 32 kHz",
- 1000 / ENE_TX_PERIOD_MIN,
- 1000 / ENE_TX_PERIOD_MAX);
+ ene_dbg("TX: attempt to set tx carrier to %d kHz", carrier);
- tmp = 32; /* this is just a coincidence!!! */
- }
- ene_dbg("TX: set carrier to %d kHz", lvalue);
+ if (period && (period > ENE_TX_PERIOD_MAX ||
+ period < ENE_TX_PERIOD_MIN)) {
- spin_lock_irqsave(&dev->hw_lock, flags);
- dev->tx_period = tmp;
- spin_unlock_irqrestore(&dev->hw_lock, flags);
- break;
- case LIRC_SET_SEND_DUTY_CYCLE:
- ene_dbg("TX: attempt to set duty cycle to %d%%", lvalue);
+ ene_dbg("TX: out of range %d-%d carrier, "
+ "falling back to 32 kHz",
+ 1000 / ENE_TX_PERIOD_MIN,
+ 1000 / ENE_TX_PERIOD_MAX);
- if ((lvalue >= 100) || (lvalue <= 0)) {
- retval = -EINVAL;
- break;
- }
- spin_lock_irqsave(&dev->hw_lock, flags);
- dev->tx_duty_cycle = lvalue;
- spin_unlock_irqrestore(&dev->hw_lock, flags);
- break;
- case LIRC_SET_TRANSMITTER_MASK:
- ene_dbg("TX: attempt to set transmitter mask %02x", lvalue);
-
- /* invalid txmask */
- if (!lvalue || lvalue & ~0x3) {
- ene_dbg("TX: invalid mask");
- /* this supposed to return num of transmitters */
- retval = 2;
- break;
- }
- spin_lock_irqsave(&dev->hw_lock, flags);
- dev->transmitter_mask = lvalue;
- spin_unlock_irqrestore(&dev->hw_lock, flags);
- break;
- case LIRC_SET_REC_CARRIER:
- tmp = (lvalue > ENE_NORMAL_RX_HI || lvalue < ENE_NORMAL_RX_LOW);
-
- if (tmp != dev->learning_enabled) {
- spin_lock_irqsave(&dev->hw_lock, flags);
- dev->learning_enabled = tmp;
- ene_rx_set_inputs(dev);
- spin_unlock_irqrestore(&dev->hw_lock, flags);
- }
- break;
- case LIRC_SET_REC_TIMEOUT:
- spin_lock_irqsave(&dev->hw_lock, flags);
- dev->rx_timeout = lvalue;
- spin_unlock_irqrestore(&dev->hw_lock, flags);
- ene_dbg("RX: set rx report timeout to %d", dev->rx_timeout);
- break;
- case LIRC_SET_REC_TIMEOUT_REPORTS:
- spin_lock_irqsave(&dev->hw_lock, flags);
- dev->rx_send_timeout_packet = lvalue;
- spin_unlock_irqrestore(&dev->hw_lock, flags);
- ene_dbg("RX: %sable timeout reports",
- dev->rx_send_timeout_packet ? "en" : "dis");
- break;
- case LIRC_SET_MEASURE_CARRIER_MODE:
- if (dev->rx_carrier_sense == lvalue)
- break;
- spin_lock_irqsave(&dev->hw_lock, flags);
- dev->rx_carrier_sense = lvalue;
- ene_rx_set_inputs(dev);
- spin_unlock_irqrestore(&dev->hw_lock, flags);
- break;
- case LIRC_GET_REC_RESOLUTION:
- tmp = dev->rx_fan_input_inuse ?
- ENE_SAMPLE_PERIOD_FAN : sample_period;
- retval = put_user(tmp, (unsigned long *) arg);
- break;
- default:
- retval = -ENOIOCTLCMD;
- break;
+ period = 32; /* this is just a coincidence!!! */
}
+ ene_dbg("TX: set carrier to %d kHz", carrier);
- return retval;
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ dev->tx_period = period;
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+ return 0;
}
-/* outside interface: transmit */
-static ssize_t ene_transmit(struct file *file, const char *buf,
- size_t n, loff_t *ppos)
+
+/* outside interface: enable learning mode */
+static int ene_set_learning_mode(void *data, int enable)
{
- struct ene_device *dev = lirc_get_pdata(file);
+ struct ene_device *dev = (struct ene_device *)data;
unsigned long flags;
+ if (enable == dev->learning_enabled)
+ return 0;
- if (!dev)
- return -EFAULT;
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ dev->learning_enabled = enable;
+ ene_rx_set_inputs(dev);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+ return 0;
+}
- if (!dev->hw_learning_and_tx_capable)
- return -ENODEV;
+/* outside interface: set rec carrier */
+static int ene_set_rec_carrier(void *data, u32 min, u32 max)
+{
+ struct ene_device *dev = (struct ene_device *)data;
+ ene_set_learning_mode(dev,
+ max > ENE_NORMAL_RX_HI || min < ENE_NORMAL_RX_LOW);
+ return 0;
+}
- if (n % sizeof(int))
- return -EINVAL;
+/* outside interface: enable or disable idle mode */
+static void ene_rx_set_idle(void *data, int idle)
+{
+ struct ene_device *dev = (struct ene_device *)data;
+ ene_dbg("%sabling idle mode", idle ? "en" : "dis");
- if (n > ENE_TXBUF_SIZE * sizeof(int))
- return -ENOMEM;
+ ene_hw_write_reg_mask(dev, ENE_CIR_SAMPLE_PERIOD,
+ (enable_idle && idle) ? 0 : ENE_CIR_SAMPLE_OVERFLOW,
+ ENE_CIR_SAMPLE_OVERFLOW);
+}
- if (copy_from_user(dev->tx_buffer, buf, n))
- return -EFAULT;
+/* outside interface: transmit */
+static int ene_transmit(void *data, int *buf, u32 n)
+{
+ struct ene_device *dev = (struct ene_device *)data;
+ unsigned long flags;
+
+ dev->tx_buffer = buf;
dev->tx_len = n / sizeof(int);
dev->tx_pos = 0;
dev->tx_reg = 0;
@@ -881,7 +740,7 @@ static ssize_t ene_transmit(struct file *file, const char *buf,
spin_lock_irqsave(&dev->hw_lock, flags);
- ene_tx_set_transmiter_mask(dev);
+ ene_tx_hw_set_transmiter_mask(dev);
ene_tx_prepare(dev);
/* Transmit first two samples */
@@ -897,80 +756,35 @@ static ssize_t ene_transmit(struct file *file, const char *buf,
spin_unlock_irqrestore(&dev->hw_lock, flags);
} else
ene_dbg("TX: done");
-
return n;
}
-/* Sends one sample to the user */
-static void ene_send_sample(struct ene_device *dev, unsigned long sample)
-{
- if (!lirc_buffer_full(dev->lirc_driver->rbuf)) {
- lirc_buffer_write(dev->lirc_driver->rbuf, (void *)&sample);
- wake_up(&dev->lirc_driver->rbuf->wait_poll);
- }
-}
-
-static const struct file_operations ene_fops = {
- .owner = THIS_MODULE,
- .write = ene_transmit,
- .ioctl = ene_ioctl,
-};
-
-/* main load function */
-static int ene_probe(struct pnp_dev *pnp_dev,
- const struct pnp_device_id *dev_id)
+/* probe entry */
+static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
{
- struct ene_device *dev;
- struct lirc_driver *lirc_driver;
int error = -ENOMEM;
+ struct ir_dev_props *ir_props;
+ struct input_dev *input_dev;
+ struct ene_device *dev;
+ /* allocate memory */
+ input_dev = input_allocate_device();
+ ir_props = kzalloc(sizeof(struct ir_dev_props), GFP_KERNEL);
dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL);
- if (!dev)
- goto err1;
-
- dev->pnp_dev = pnp_dev;
- pnp_set_drvdata(pnp_dev, dev);
-
- /* prepare lirc interface */
- error = -ENOMEM;
- lirc_driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
-
- if (!lirc_driver)
- goto err2;
-
- dev->lirc_driver = lirc_driver;
-
- strcpy(lirc_driver->name, ENE_DRIVER_NAME);
- lirc_driver->minor = -1;
- lirc_driver->code_length = sizeof(int) * 8;
- lirc_driver->features = LIRC_CAN_REC_MODE2 |
- LIRC_CAN_GET_REC_RESOLUTION |
- LIRC_CAN_SET_REC_TIMEOUT;
- lirc_driver->data = dev;
- lirc_driver->set_use_inc = ene_open;
- lirc_driver->set_use_dec = ene_close;
- lirc_driver->dev = &pnp_dev->dev;
- lirc_driver->owner = THIS_MODULE;
- lirc_driver->fops = &ene_fops;
- lirc_driver->min_timeout = ENE_MINGAP;
- lirc_driver->max_timeout = ENE_MAXGAP;
- lirc_driver->rbuf = kzalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
-
- if (!lirc_driver->rbuf)
- goto err3;
-
- if (lirc_buffer_init(lirc_driver->rbuf, sizeof(int), sizeof(int) * 512))
- goto err4;
+ if (!input_dev || !ir_props || !dev)
+ goto error;
/* validate resources */
+ error = -ENODEV;
+
if (!pnp_port_valid(pnp_dev, 0) ||
pnp_port_len(pnp_dev, 0) < ENE_MAX_IO)
- goto err5;
+ goto error;
if (!pnp_irq_valid(pnp_dev, 0))
- goto err5;
+ goto error;
dev->hw_io = pnp_port_start(pnp_dev, 0);
dev->irq = pnp_irq(pnp_dev, 0);
@@ -979,16 +793,19 @@ static int ene_probe(struct pnp_dev *pnp_dev,
/* claim the resources */
error = -EBUSY;
if (!request_region(dev->hw_io, ENE_MAX_IO, ENE_DRIVER_NAME))
- goto err5;
+ goto error;
if (request_irq(dev->irq, ene_isr,
IRQF_SHARED, ENE_DRIVER_NAME, (void *)dev))
- goto err6;
+ goto error;
+
+ pnp_set_drvdata(pnp_dev, dev);
+ dev->pnp_dev = pnp_dev;
/* detect hardware version and features */
error = ene_hw_detect(dev);
if (error)
- goto err7;
+ goto error;
ene_setup_settings(dev);
@@ -1000,19 +817,21 @@ static int ene_probe(struct pnp_dev *pnp_dev,
"Simulation of TX activated\n");
}
- if (dev->hw_learning_and_tx_capable) {
- lirc_driver->features |= LIRC_CAN_SEND_PULSE |
- LIRC_CAN_SET_SEND_CARRIER |
- LIRC_CAN_SET_TRANSMITTER_MASK;
+ ir_props->driver_type = RC_DRIVER_IR_RAW;
+ ir_props->allowed_protos = IR_TYPE_ALL;
+ ir_props->priv = dev;
+ ir_props->open = ene_open;
+ ir_props->close = ene_close;
+ ir_props->min_timeout = ENE_MINGAP * 1000;
+ ir_props->max_timeout = ENE_MAXGAP * 1000;
+ ir_props->timeout = ENE_MAXGAP * 1000;
- if (enable_duty_carrier)
- lirc_driver->features |= LIRC_CAN_SET_SEND_DUTY_CYCLE;
+ if (dev->hw_revision == ENE_HW_B)
+ ir_props->s_idle = ene_rx_set_idle;
- if (input == 0)
- lirc_driver->features |= LIRC_CAN_SET_REC_CARRIER;
- init_completion(&dev->tx_complete);
- }
+ dev->props = ir_props;
+ dev->idev = input_dev;
/* don't allow too short/long sample periods */
if (sample_period < 5 || sample_period > 0x7F)
@@ -1029,29 +848,50 @@ static int ene_probe(struct pnp_dev *pnp_dev,
sample_period = 75;
}
+ ir_props->rx_resolution = sample_period * 1000;
+
+ if (dev->hw_learning_and_tx_capable) {
+
+ ir_props->s_learning_mode = ene_set_learning_mode;
+
+ if (input == 0)
+ ir_props->s_rx_carrier_range = ene_set_rec_carrier;
+
+ init_completion(&dev->tx_complete);
+ ir_props->tx_ir = ene_transmit;
+ ir_props->s_tx_mask = ene_set_tx_mask;
+ ir_props->s_tx_carrier = ene_set_tx_carrier;
+ ir_props->tx_resolution = ENE_TX_SMPL_PERIOD * 1000;
+ /* ir_props->s_carrier_report = ene_set_carrier_report; */
+ }
+
+
device_set_wakeup_capable(&pnp_dev->dev, 1);
device_set_wakeup_enable(&pnp_dev->dev, 1);
+ if (dev->hw_learning_and_tx_capable)
+ input_dev->name = "ENE eHome Infrared Remote Transceiver";
+ else
+ input_dev->name = "ENE eHome Infrared Remote Receiver";
+
+
error = -ENODEV;
- if (lirc_register_driver(lirc_driver))
- goto err7;
+ if (ir_input_register(input_dev, RC_MAP_RC6_MCE, ir_props,
+ ENE_DRIVER_NAME))
+ goto error;
+
ene_printk(KERN_NOTICE, "driver has been succesfully loaded\n");
return 0;
-
-err7:
- free_irq(dev->irq, dev);
-err6:
- release_region(dev->hw_io, ENE_MAX_IO);
-err5:
- lirc_buffer_free(lirc_driver->rbuf);
-err4:
- kfree(lirc_driver->rbuf);
-err3:
- kfree(lirc_driver);
-err2:
+error:
+ if (dev->irq)
+ free_irq(dev->irq, dev);
+ if (dev->hw_io)
+ release_region(dev->hw_io, ENE_MAX_IO);
+
+ input_free_device(input_dev);
+ kfree(ir_props);
kfree(dev);
-err1:
return error;
}
@@ -1067,9 +907,8 @@ static void ene_remove(struct pnp_dev *pnp_dev)
free_irq(dev->irq, dev);
release_region(dev->hw_io, ENE_MAX_IO);
- lirc_unregister_driver(dev->lirc_driver->minor);
- lirc_buffer_free(dev->lirc_driver->rbuf);
- kfree(dev->lirc_driver);
+ ir_input_unregister(dev->idev);
+ kfree(dev->props);
kfree(dev);
}
@@ -1113,6 +952,7 @@ static const struct pnp_device_id ene_ids[] = {
{.id = "ENE0100",},
{.id = "ENE0200",},
{.id = "ENE0201",},
+ {.id = "ENE0202",},
{},
};
@@ -1160,13 +1000,18 @@ module_param(txsim, bool, S_IRUGO);
MODULE_PARM_DESC(txsim,
"Simulate TX features on unsupported hardware (dangerous)");
-module_param(enable_duty_carrier, bool, S_IRUGO);
-MODULE_PARM_DESC(enable_duty_carrier,
- "Enable a code that might allow to to set TX carrier duty cycle");
+
+module_param(error_adjustment, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(error_adjustment,
+ "Correct incoming samples by error_adjustment percent\n"
+ "A default value of 4% seems to help with signal decoding");
+
+
+
MODULE_DEVICE_TABLE(pnp, ene_ids);
MODULE_DESCRIPTION
- ("LIRC driver for KB3926B/KB3926C/KB3926D "
+ ("Infrared input driver for KB3926B/KB3926C/KB3926D "
"(aka ENE0100/ENE0200/ENE0201) CIR port");
MODULE_AUTHOR("Maxim Levitsky");
@@ -1,5 +1,5 @@
/*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ * driver for ENE KB3926 B/C/D CIR (also known as ENE0XXX)
*
* Copyright (C) 2010 Maxim Levitsky <maximlevitsky@gmail.com>
*
@@ -19,8 +19,7 @@
* USA
*/
#include <linux/spinlock.h>
-#include <media/lirc.h>
-#include <media/lirc_dev.h>
+
/* hardware address */
#define ENE_STATUS 0 /* hardware status - unused */
@@ -62,7 +61,7 @@
/* transmitter ports */
#define ENE_TX_PORT2 0xFC01 /* this enables one or both */
#define ENE_TX_PORT2_EN 0x20 /* TX ports */
-#define ENE_TX_PORT1 0xFC08
+#define ENE_TX_PORT1 0xFC08
#define ENE_TX_PORT1_EN 0x02
/* IRQ registers block (for revision B) */
@@ -88,7 +87,7 @@
#define ENE_CIR_CONF1 0xFEC0
#define ENE_CIR_CONF1_TX_CLEAR 0x01 /* clear that on revC */
/* while transmitting */
-#define ENE_CIR_CONF1_RX_ON 0x07 /* normal reciever enabled */
+#define ENE_CIR_CONF1_RX_ON 0x07 /* normal receiver enabled */
#define ENE_CIR_CONF1_LEARN1 0x08 /* enabled on learning mode */
#define ENE_CIR_CONF1_TX_ON 0x30 /* enabled on transmit */
#define ENE_CIR_CONF1_TX_CARR 0x80 /* send TX carrier or not */
@@ -112,7 +111,7 @@
/* Unknown TX setting - TX sample period ??? */
#define ENE_TX_UNK1 0xFECB /* set to 0x63 */
-/* Current recieved carrier period */
+/* Current received carrier period */
#define ENE_RX_CARRIER 0xFECC /* RX period (500 ns) */
#define ENE_RX_CARRIER_VALID 0x80 /* Register content valid */
@@ -162,8 +161,7 @@
/******************************************************************************/
-#define ENE_DRIVER_NAME "enecir"
-#define ENE_TXBUF_SIZE (500 * sizeof(int)) /* 500 samples (arbitary) */
+#define ENE_DRIVER_NAME "ene_ir"
#define ENE_IRQ_RX 1
#define ENE_IRQ_TX 2
@@ -188,7 +186,8 @@
struct ene_device {
struct pnp_dev *pnp_dev;
- struct lirc_driver *lirc_driver;
+ struct input_dev *idev;
+ struct ir_dev_props *props;
int in_use;
/* hw IO settings */
@@ -198,43 +197,35 @@ struct ene_device {
/* HW features */
int hw_revision; /* hardware revision */
- int hw_learning_and_tx_capable; /* learning capable */
- int hw_gpio40_learning; /* gpio40 is learning */
- int hw_fan_as_normal_input; /* fan input is used as */
+ bool hw_learning_and_tx_capable; /* learning capable */
+ bool hw_gpio40_learning; /* gpio40 is learning */
+ bool hw_fan_as_normal_input; /* fan input is used as */
/* regular input */
/* HW state*/
int rx_pointer; /* hw pointer to rx buffer */
- int rx_fan_input_inuse; /* is fan input in use for rx*/
+ bool rx_fan_input_inuse; /* is fan input in use for rx*/
int tx_reg; /* current reg used for TX */
u8 saved_conf1; /* saved FEC0 reg */
- int learning_enabled; /* learning input enabled */
-
- /* RX sample handling */
- int rx_sample; /* current recieved sample */
- int rx_sample_pulse; /* recieved sample is pulse */
- int rx_idle; /* idle mode for RX activated */
- struct timeval rx_gap_start; /* time of start of idle */
- int rx_timeout; /* time in ms of RX timeout */
- int rx_send_timeout_packet; /* do we send RX timeout */
- int rx_timeout_sent; /* we sent the timeout packet */
- int rx_carrier_sense; /* sense carrier */
/* TX sample handling */
unsigned int tx_sample; /* current sample for TX */
- int tx_sample_pulse; /* current sample is pulse */
+ bool tx_sample_pulse; /* current sample is pulse */
/* TX buffer */
- int tx_buffer[ENE_TXBUF_SIZE]; /* input samples buffer*/
+ int *tx_buffer; /* input samples buffer*/
int tx_pos; /* position in that bufer */
int tx_len; /* current len of tx buffer */
- int tx_underway; /* TX is under way*/
int tx_done; /* done transmitting */
/* one more sample pending*/
struct completion tx_complete; /* TX completion */
struct timer_list tx_sim_timer;
- /*TX settings */
+ /* TX settings */
int tx_period;
int tx_duty_cycle;
int transmitter_mask;
+
+ /* RX settings */
+ bool learning_enabled; /* learning input enabled */
+ bool carrier_detect_enabled; /* carrier detect enabled */
};