Re: [PATCH 13/13] IR: Port ene driver to new IR subsystem and enable it.

[Maxim Levitsky <maximlevitsky@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