Re: [PATCHv2 1/3] Add support for GMT G762/G763 PWM fan controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 04, 2013 at 11:23:07PM +0200, Simon Guinot wrote:
> On Tue, Jun 04, 2013 at 08:52:12AM +0200, Arnaud Ebalard wrote:
> > Hi Simon,
> > 
> > Simon Guinot <simon.guinot@xxxxxxxxxxxx> writes:
> > 
> > > On Sat, Jun 01, 2013 at 07:26:54PM +0200, Arnaud Ebalard wrote:
> > >> Hi Simon and Guenter,
> > >> 
> > >> Simon Guinot <simon.guinot@xxxxxxxxxxxx> writes:
> > >> 
> > >> > On Tue, May 28, 2013 at 12:03:14AM +0200, Arnaud Ebalard wrote:
> > >> >> 
> > >> >> Signed-off-by: Arnaud Ebalard <arno@xxxxxxxxxxxx>
> > >> >> ---
> > >> >>  drivers/hwmon/Kconfig              |   10 +
> > >> >>  drivers/hwmon/Makefile             |    1 +
> > >> >>  drivers/hwmon/g762.c               | 1012 ++++++++++++++++++++++++++++++++++++
> > >> >>  include/linux/platform_data/g762.h |   54 ++
> > >> >>  4 files changed, 1077 insertions(+)
> > >> >>  create mode 100644 drivers/hwmon/g762.c
> > >> >>  create mode 100644 include/linux/platform_data/g762.h
> > >> >
> > >> > Hi Arnaud,
> > >> >
> > >> > After more tests on my 2Big Network v2 board, it appears that the fan
> > >> > doesn't rotate when PWM mode (the preferred operating mode for this
> > >> > board) is selected. Nevertheless, DC mode is usable (even if not ideal
> > >> > given the hardware). After some investigations I noticed that an extra
> > >> > initialization is needed to enable PWM mode on my board: the set_cnt
> > >> > register must be set to 0 while the default value is 0xff. Is that
> > >> > specific to my hardware ? Is PWM mode working on your ReadyNAS with
> > >> > the default set_cnt value ?
> > >> 
> > >> First, thanks for testing this!
> > >> 
> > >> Regarding your problem, I first started by booting current version of my
> > >> driver on the Duo v2 w/o touching chip registers (only clock reference
> > >> value). This way, I inherit the values installed by (NETGEAR's) u-boot:
> > >> 
> > >> $ for k in fan* pwm* ; do echo -n "$k:" ; echo `cat $k `; done
> > >> fan1_alarm:0
> > >> fan1_div:2
> > >> fan1_fault:0
> > >> fan1_input:1807
> > >> fan1_target:1807
> > >> pwm1:221
> > >> pwm1_enable:2        /* closed-loop, i.e. config is done via set_cnt */
> > >> pwm1_mode:1          /* PWM mode */ 
> > >
> > > Sorry, I realize that I have not been very accurate in my description of
> > > the problem: The fan doesn't rotate when PWM _and_ open-loop control are
> > > selected. On the 2Big2 board, 2 wires are used to drive the fan.
> > >
> > > Then with pwm1_mode=1, pwm1_enable=1 and set_cnt=0xff (default value),
> > > nothing happen whatever the value I write in pwm1.
> > 
> > After boot, with set_cnt and set_out untouched by me (set_cnt set to
> > 0x5a by u-boot, i.e. 255-0x5a read on pwm1):
> > 
> > fan1_alarm:0
> > fan1_div:1
> > fan1_fault:0
> > fan1_input:1365
> > fan1_target:1365
> > pwm1:0                  /* set_out is 0 (considering fan1_target,
> >                            set_cnt is 0x5a)*/
> > pwm1_enable:2           /* closed-loop */
> > pwm1_mode:0             /* DC mode */
> > 
> > # echo 1 > pwm1_mode    /* PWM mode */       # fan rotates 
> > # echo 1 > pwm1_enable  /* open-loop */      # fan stops rotating
> > 
> > At that point we have:
> > 
> > fan1_alarm:0
> > fan1_div:1
> > fan1_fault:0
> > fan1_input:0
> > fan1_target:1365
> > pwm1:0                  /* set_out is 0, set_cnt is still 0x5a */
> > pwm1_enable:1
> > pwm1_mode:1
> > 
> > Then:
> > 
> > # echo 100 > pwm1                            # fan rotates
> 
> OK you are lucky. Your bootloader initialize set_cnt with 0x5a. Mine
> don't and it is precisely the issue: set_cnt is still 0xff (the default
> value) when the driver controls the fan.
> 
> Please, could you try open-loop mode with set_cnt set to 0xff ?  Maybe
> you can enforce this value for the test purpose ?
> 
> If you observe the same behaviour than me, then could modify the driver
> to ensure that set_cnt is not 0xff when open-loop mode is selected ?
> Maybe by systematically setting a different value (as 0) ?
> 
I think it would make sense to set it to 0 when open-loop mode is selected, or
at least to set it to a value != 0xff. Question would be if the value has any
meaning in open loop mode, other than to enable/disable fan control entirely.

Thanks,
Guenter

> > 
> > 
> > > By testing, I have discovered that writing 0 into set_cnt allows to work
> > > around the issue. I can do this by using the closed-loop control:
> > > pwm1_mode=1, pwm1_enable=2 and pwm=255. Now, set_cnt worths 0 and if I
> > > switch back to open-loop control, all works as expected.
> > >
> > > Can you try open-loop control and PWM mode with your board ? I wonder if
> > > this issue is specific to the 2Big2 hardware.
> > 
> > AFAICT, set_cnt has never been set to 0 in my test and PWM+open-loop
> > works as expected, i.e. just by setting a non-zero value in set_out.
> > Tell me if I missed something or if you want me to perform another
> > test.
> 
> Actually, I have only problems when set_cnt worths 0xff. Please, could
> you try the tests mentioned above ?
> 
> Thanks in advance,
> 
> Simon
> 
> > 
> > Cheers,
> > 
> > a+
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux