summaryrefslogtreecommitdiff
path: root/include/pwm.h
Commit message (Collapse)AuthorAgeFilesLines
* fix ChromiumOS authors and whitespace warningsMary Ruthven2022-09-131-1/+1
| | | | | | | | | | | BUG=none TEST=none Change-Id: I61b0b0106a43f723ec3bc805eb190aef00bbd05b Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3894391 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
* LICENSE: remove unnecessary (c) after CopyrightTom Hughes2019-06-191-1/+1
| | | | | | | | | | | | | | | | Ran the following command: git grep -l 'Copyright (c)' | \ xargs sed -i 's/Copyright (c)/Copyright/g' BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* common: replace 1 << digits, with BIT(digits)Gwendal Grignou2019-03-261-6/+6
| | | | | | | | | | | | | | | | Requested for linux integration, use BIT instead of 1 << First step replace bit operation with operand containing only digits. Fix an error in motion_lid try to set bit 31 of a signed integer. BUG=None BRANCH=None TEST=compile Change-Id: Ie843611f2f68e241f0f40d4067f7ade726951d29 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518659 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* Reland "npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is ↵Mulin Chao2019-03-071-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zero." This is a reland of 93d7bcea8121869520b0d02bf94f95eb261bee05 with a fix for fan_is_stalled. Original change's description: > npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is zero. > > In npcx pwm driver, it turns off pwm module directly when its duty cycle > is set to zero. But we saw pwm signal isn't turned off by the following > sequence: > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > > Please notice setting zero in DCRn doesn't mean duty cycle is zero. > (NPCX duty cycle: ( (DCRn+1) / (CTRn+1) ) x 100). Hence in step 2, we > can observe a very low duty cycle once the driver enables pwm module. > > According to figure. 24 in npcx5's datasheet, setting DCRn greater than > CTRn means that the result of 16-bits comparator is always false. It > equals the duty cycle is zero. This CL adopts this method to present it > and removes the dependency between pwm_enable()/ pwm_get_enabled() and > pwm_set_raw_duty()/pwm_get_duty(). > > In order to make sure DCRn can be greater than CTRn, we also defined > the PWN maximum duty cycle is (0xFFFF -1) since both DCR and CTR are > 16-bits registers. > > BRANCH=none > BUG=b:123552920 > TEST=No build errors for npcx5/7 series. > > Test pwm console command on npcx5/7 evbs by the following sequence. > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > And no symptoms are observed. PWM_CONFIG_ACTIVE_LOW flag is tested also > and no symptom occurred. > > Test fan control by faninfo & fanset console commands. Connect Sunon > 4-pins PWM fan and evb by following steps: > 1. Connect PWM0 to PWM pin of fan. > 2. Connect TA1_TACH1 and 3.3 PU on Tacho pin of fan. > 3. Connect 5V and GND pins of fan to power supply. > No symptoms are observed. > > Change-Id: I92517ff0bf3e027ae191be00112cd71ec4b55a2b > Signed-off-by: Mulin Chao <mlchao@nuvoton.com> > Reviewed-on: https://chromium-review.googlesource.com/1475096 > Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> > Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Bug: b:123552920 Change-Id: I4ea76c51811507ee4a35e5c0edfb70e9fb6c4c8b Reviewed-on: https://chromium-review.googlesource.com/1506115 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* Revert "npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is ↵Daisuke Nojiri2019-03-061-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zero." This reverts commit 93d7bcea8121869520b0d02bf94f95eb261bee05. Reason for revert: fan_is_stalled is broken Original change's description: > npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is zero. > > In npcx pwm driver, it turns off pwm module directly when its duty cycle > is set to zero. But we saw pwm signal isn't turned off by the following > sequence: > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > > Please notice setting zero in DCRn doesn't mean duty cycle is zero. > (NPCX duty cycle: ( (DCRn+1) / (CTRn+1) ) x 100). Hence in step 2, we > can observe a very low duty cycle once the driver enables pwm module. > > According to figure. 24 in npcx5's datasheet, setting DCRn greater than > CTRn means that the result of 16-bits comparator is always false. It > equals the duty cycle is zero. This CL adopts this method to present it > and removes the dependency between pwm_enable()/ pwm_get_enabled() and > pwm_set_raw_duty()/pwm_get_duty(). > > In order to make sure DCRn can be greater than CTRn, we also defined > the PWN maximum duty cycle is (0xFFFF -1) since both DCR and CTR are > 16-bits registers. > > BRANCH=none > BUG=b:123552920 > TEST=No build errors for npcx5/7 series. > > Test pwm console command on npcx5/7 evbs by the following sequence. > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > And no symptoms are observed. PWM_CONFIG_ACTIVE_LOW flag is tested also > and no symptom occurred. > > Test fan control by faninfo & fanset console commands. Connect Sunon > 4-pins PWM fan and evb by following steps: > 1. Connect PWM0 to PWM pin of fan. > 2. Connect TA1_TACH1 and 3.3 PU on Tacho pin of fan. > 3. Connect 5V and GND pins of fan to power supply. > No symptoms are observed. > > Change-Id: I92517ff0bf3e027ae191be00112cd71ec4b55a2b > Signed-off-by: Mulin Chao <mlchao@nuvoton.com> > Reviewed-on: https://chromium-review.googlesource.com/1475096 > Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> > Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Bug: b:123552920 Change-Id: Iece29c665d3a7518159514291f3c17a7b58c3284 Reviewed-on: https://chromium-review.googlesource.com/1505014 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is zero.Mulin Chao2019-03-051-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In npcx pwm driver, it turns off pwm module directly when its duty cycle is set to zero. But we saw pwm signal isn't turned off by the following sequence: 1. pwm_set_raw_duty(ch, 0); 2. pwm_enable(ch, 1); Please notice setting zero in DCRn doesn't mean duty cycle is zero. (NPCX duty cycle: ( (DCRn+1) / (CTRn+1) ) x 100). Hence in step 2, we can observe a very low duty cycle once the driver enables pwm module. According to figure. 24 in npcx5's datasheet, setting DCRn greater than CTRn means that the result of 16-bits comparator is always false. It equals the duty cycle is zero. This CL adopts this method to present it and removes the dependency between pwm_enable()/ pwm_get_enabled() and pwm_set_raw_duty()/pwm_get_duty(). In order to make sure DCRn can be greater than CTRn, we also defined the PWN maximum duty cycle is (0xFFFF -1) since both DCR and CTR are 16-bits registers. BRANCH=none BUG=b:123552920 TEST=No build errors for npcx5/7 series. Test pwm console command on npcx5/7 evbs by the following sequence. 1. pwm_set_raw_duty(ch, 0); 2. pwm_enable(ch, 1); And no symptoms are observed. PWM_CONFIG_ACTIVE_LOW flag is tested also and no symptom occurred. Test fan control by faninfo & fanset console commands. Connect Sunon 4-pins PWM fan and evb by following steps: 1. Connect PWM0 to PWM pin of fan. 2. Connect TA1_TACH1 and 3.3 PU on Tacho pin of fan. 3. Connect 5V and GND pins of fan to power supply. No symptoms are observed. Change-Id: I92517ff0bf3e027ae191be00112cd71ec4b55a2b Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1475096 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* npcx: Move pwm open-drain functionality from gpio to pwm driver.Mulin Chao2017-03-241-0/+4
| | | | | | | | | | | | | | | | Setting PWM IO type in gpio driver seems not a proper way. This CL moves this functionality to pwm driver and introduces a new flag PWM_CONFIG_OPEN_DRAIN to achieve it when user declared it in board driver. BRANCH=none BUG=none TEST=test pwm functionality on npcx_evb. Change-Id: I90c60445d1fb10902244ddf0f635d8304e72f4ab Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/458043 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* gru: control LEDs by changing frequencyDavid Schneider2016-12-051-0/+6
| | | | | | | | | | | | | | | | gru has circuitrythat selects the charge LED color based on the frequency of the PWM. By adjusting the PWM frequency instead of just the duty, we gain more control over the brightness of the charge LED. BUG=chrome-os-partner:54155 BRANCH=gru TEST=activate each LED in turn and confirm color and brightness Change-Id: Ie653125a528595c1ec68aea4d02cb70595a1b151 Signed-off-by: David Schneider <dnschneid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/415517 Reviewed-by: Shawn N <shawnn@chromium.org>
* pwm: Increse PWM duty resolution to 16bitsSam Hurst2016-09-021-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current PWM interface allows for a pwm duty setting ranging from 0 to 100, resulting in a very coarse adjustment. To alleviate the problem, the interface now allows for a pwm duty setting in the range of 0 to 65535. BUG=chromium:615109 BRANCH=None TEST=Manual on chell. `ectool pwmsetduty 1 65535` - Verify LCD backlight goes to 100% `ectool pwmgetduty 1` - Prints 65535 `ectool pwmsetduty 1 0` - Verify LCD backlight goes to 0% `ectool pwmgetduty 1` - Prints 0 terminal pwmduty tests: >pwmduty PWM channels: 0: 100% 1: 62% 2: 100% 3: 80% > pwmduty 1 50 Setting channel 1 to 50% 1: 50% > pwmduty 1 0 Setting channel 1 to 0% 1: disabled > pwmduty 1 100 Setting channel 1 to 100% 1: 100% > pwmduty 1 raw 0 Setting channel 1 to raw 0% 1: disabled > pwmduty 1 raw 65535 Setting channel 1 to raw 65535% 1: 65535 > pwmduty PWM channels: 0: 100% 1: 100% 2: 100% 3: 80% > pwmduty 1 raw 30000 Setting channel 1 to raw 30000% 1: 30000 > pwmduty PWM channels: 0: 100% 1: 46% 2: 100% 3: 80% Change-Id: I299b77585f3988e72d9ac918bdde7dc5fa3df6de Reviewed-on: https://chromium-review.googlesource.com/374481 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Shawn N <shawnn@chromium.org>
* pwm: Add PWM_CONFIG_DSLEEP config flagShawn Nematbakhsh2016-04-271-1/+4
| | | | | | | | | | | | | | | | | | | Add PWM_CONFIG_DSLEEP PWM config flag, which can be set to keep a channel active during low-power idle / deep sleep. Currently it's supported by npcx and mec1322. BUG=chrome-os-partner:52783 BRANCH=glados TEST=Manual on chell w/ subsequent commit + CONFIG_LOW_POWER_S0. Verify KB backlight does not flicker during idle. Change-Id: Ib9df5879aaa7dfa5764de1583496de84d40d2bb5 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/341002 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* stm32: pwm: Allow configuration of pwm frequency + complementary outputsShawn Nematbakhsh2015-12-041-3/+8
| | | | | | | | | | | | | | | | | | | Allow boards to customize both the PWM frequency / period and the enabling of complementary output signals. BUG=chrome-os-partner:48044 TEST=Manual with snoball w/ subsequent commit. Run `pwm <ch> 50` for each channel, verify with `adc` that each PD output voltage is approximately VBUCK / 2. BRANCH=None Change-Id: I61cbb4a5b656f41ec7cec59339f5247902256295 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/315141 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pwm: Add option for alternate clock sourceDuncan Laurie2015-11-131-0/+5
| | | | | | | | | | | | | | | | | | | | | The PWM clock on some chips can be configured to use different sources, which will have a dramatic effect on the actual PWM frequency. In order to support a variety of devices attached to PWM outputs add an option to select an alternate source. This is then implemented on the mec1322 chip to use the 100kHz clock source for PWM which will allow it to drive a keyboard backlight at appropriate frequencies. BUG=chrome-os-partner:47435 BRANCH=none TEST=verify that kblight brightness can be changed on chell Change-Id: Ibe93a8e029baae5a2d5f520d590b0cc4ab9a7f93 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/312509 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* Separate fan_t from pwm_tBill Richardson2013-10-301-0/+3
| | | | | | | | | | | | | | | | There is a logical difference between PWM controls for things like backlights and fan controls for actual fans. This change separates them into two different data structures, for better abstraction. BUG=chrome-os-partner:23530 BRANCH=none TEST=manual make runtests, make all boards, test on Link and Falco. Change-Id: Ib63f2d1518fcc2ee367f81bf5d803360c1aa5c76 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175151
* Refactor PWM moduleVic Yang2013-08-271-10/+18
| | | | | | | | | | | | | | | | | | | | This unifies the PWM module interface for LM4 and STM32. Now PWM channels are defined in board.h/board.c. Instead of calling functions named pwm_set_fan_duty(x), one can now use pwm_set_duty(PWM_CH_FAN, x), which prevents additional functions added when we have a new PWM channel. BUG=chrome-os-partner:18343 TEST=Limit input current on Spring. TEST=Check power LED in S0/S3/S5 on Snow. TEST=Check keyboard backlight functionality on Link. TEST=Check fan speed control/detecting on Link. BRANCH=None Change-Id: Ibac4d79f72e65c94776d503558a7592f7db859dc Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/64450 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Completely new thermal/fan implementationBill Richardson2013-08-231-36/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problems with existing thermal control loop: * Not multi-board friendly. thermal.c only supports Link and needs refactoring. Temp thresholds and fan speeds are hard-coded. * Only the PECI temp is used to determine the fan speed. Other temp sensors are ignored. * Has confusing data structures. Values in the CPU temp thresholds array mix ACPI thresholds with fan step values. With this change, the thermal task monitors all temp sensors in order to perform two completely independent functions: Function one: Determine if the host needs to be throttled by or informed of any thermal events. For thermal events, each temp sensor will have three threshold levels. TEMP_HOST_WARN * When any sensor goes above this level, host_throttle_cpu(1) will be called to ask the CPU to slow itself down. * When all sensors drop below this level, host_throttle_cpu(0) will be called. * Exactly AT this level, nothing happens (this provides hysteresis). TEMP_HOST_HIGH * When any sensor goes above this level, chipset_throttle_cpu(1) will be called to slow the CPU down whether it wants to or not. * When all sensors drop below this level, chipset_throttle_cpu(0) will be called. * Exactly AT this level, nothing happens (this provides hysteresis). TEMP_HOST_SHUTDOWN * When any sensor is above this level, chipset_force_shutdown() will be called to halt the CPU. * Nothing turns the CPU back on again - the user just has to wait for things to cool off. Pressing the power button too soon will just trigger shutdown again as soon as the EC can read the host temp. Function two: Determine the amount of fan cooling needed For fan cooling, each temp sensor will have two levels. TEMP_FAN_OFF * At or below this temperature, no active cooling is needed. TEMP_FAN_MAX * At or above this temperature, active cooling should be running at maximum. The highest level of all temp sensors will be used to request the amount of active cooling needed. The function pwm_fan_percent_to_rpm() is invoked to convert the amount of cooling to the target fan RPM. The default pwm_fan_percent_to_rpm() function converts smoothly between the configured CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX for percentages between 1 and 100. 0% means "off". The default function probably provide the smoothest and quietest behavior, but individual boards can provide their own pwm_fan_percent_to_rpm() to implement whatever curves, hysteresis, feedback, or other hackery they wish. BUG=chrome-os-partner:20805 BRANCH=none TEST=manual Compile-time test with make BOARD=falco runtests On the EC console, the existing fan commands should work correctly: faninfo - display the fan state fanduty NUM - force the fan PWM to the specified percentage (0-100) fanset RPM - force the fan to the specified RPM fanset NUM% - force the fan to the specified percentage (0-100) between its configured minimum and maximum speeds from board.h (CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX) fanauto - let the EC control the fan automatically You can test the default pwm_fan_percent_to_rpm() with fanset 1% faninfo The fan should be turning at CONFIG_PWM_FAN_RPM_MIN. Let the EC control it automatically again with fanauto Also on the EC console, the thermal settings can be examined or changed: > temps PECI : 327 K = 54 C ECInternal : 320 K = 47 C G781Internal : 319 K = 46 C G781External : 318 K = 45 C > > thermalget sensor warn high shutdown fan_off fan_max name 0 373 387 383 333 363 PECI 1 0 0 0 0 0 ECInternal 2 0 0 0 0 0 G781Internal 3 0 0 0 0 0 G781External > > help thermalset Usage: thermalset sensor warn [high [shutdown [fan_off [fan_max]]]] set thermal parameters (-1 to skip) > > thermalset 2 -1 -1 999 sensor warn high shutdown fan_off fan_max name 0 373 387 383 333 363 PECI 1 0 0 0 0 0 ECInternal 2 0 0 999 0 0 G781Internal 3 0 0 0 0 0 G781External > From the host, ectool can be used to get and set these parameters with nearly identical commands: ectool thermalget ectool thermalset 2 -1 -1 999 Change-Id: Idb27977278f766826045fb7d41929953ec6b1cca Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66688 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Clean up configuring GPIO alternate functionsRandall Spangler2013-08-071-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GPIO alternate functions used to be configured throughout the code, which made it hard to tell which ones you needed to configure yourself in board.c. It also sometimes (chip/lm4/i2c.c) led to GPIOs being configured as alternate functions even if they weren't used on a given board. With this change, every board has a table in board.c which lists ALL GPIOs which have alternate functions. This is now the only place where alternate functions are configured. Each module then calls gpio_init_module() to set up its GPIOs. This also fixes a bug where gpio_set_flags() ignored most of the flags passed to it (only direction and level were actually used). On stm32f, gpio_set_alternate() does not exist, and pins are configured via direct register writes from board.c. Rather than attempt to change that in the same CL, I've stubbed out gpio_set_alternate() for stm32f, and will fix the register writes in a follow-up CL. BUG=chrome-os-partner:21618 BRANCH=peppy (fixes I2C1 being initialized even though those pins are used for other things) TEST=boot link, falco, pit, spring Change-Id: I40f47025d8f767e0723c6b40c80413af9ba8deba Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64400
* lm4: make configure_kblight_gpios() board dependentAaron Durbin2013-07-161-0/+5
| | | | | | | | | | | | | | The configure_kblight_gpios() funciton was specific to the link board. Therefore, move the function to be defined within the board-specific file. BUG=chrome-os-partner:20372 BRANCH=None TEST=Built. Tested similar change on bolt. Change-Id: Ib5847130450024c50d6526d2c1a64d67ab501637 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/62209
* lm4: break out board-specific fan/tach pin configAaron Durbin2013-05-161-0/+5
| | | | | | | | | | | | | | | | | The current lm4 pwm module was using board-specific pins during this configuration. Move the implementation of configure_fan_gpios() to the board-specific files so that the pin configuration policy isn't a part of the common infrastructure. BUG=chrome-os-partner:19504 BRANCH=none TEST=successfully booted slippy with backlight turning on in OS. Change-Id: I325f1ac4639b4a78d8b860df7a8b688ca385b71b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51471 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Split pwm.c into pwm_fan.c and pwm_kblight.cBill Richardson2013-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sadly, the existence of fans may not always imply the existence of keyboard backlights. BUG=chrome-os-partner:18825 BRANCH=slippy TEST=manual Use the Link EC console to make sure that both functions still behave. faninfo fanset 4400 faninfo fanset 9999 faninfo autofan faninfo fanduty 50 faninfo fanduty 100 faninfo autofan kblight 0 kblight 100 kblight 50 kbligth 100 Change-Id: I2e07cd46c21bce2d0d4162275a8ea6ae40135e96 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/49355
* Clean up pwm moduleRandall Spangler2012-10-251-15/+36
| | | | | | | | | | | | | No functional changes. But hey, I'm having lots of fun reformatting comments. BUG=chrome-os-partner:15579 BRANCH=none TEST=fanset -1; fanset 0; fanset 4000 Change-Id: Iddcea5b8e59fa6668cdd347b6d31155c28991521 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36585 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* link:re-enable fan RPM controller when neededRandall Spangler2012-10-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, any command which set the fan duty manually would leave the PWM RPM controller disabled. Setting the fan back to auto mode via 'ectool autofanctrl' or 'autofan' or 'ectool pwmsetfanrpm' wouldn't turn the controller back on. Now it does. BUG=chrome-os-partner:14307 BRANCH=link TEST=manual - Reboot in recovery mode and wait for INSERT screen - From EC console fanduty 100 -> fan turns on all the way faninfo -> mode is duty fanset 6000 -> fan turns down to a lower level faninfo -> mode is rpm fanduty 0 -> fan turns off all the way faninfo -> mode is duty (wait a min or so for the system to heat up) autofan -> fan turns on faninfo -> mode is rpm - Reboot normally - From root shell ectool fanduty 100 -> fan turns on all the way ectool pwmsetfanrpm 6000 -> fan turns down to a lower level Change-Id: I3b07e8b49500f5f8a42f20909d2869cf63987d6d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35335 Reviewed-by: Sameer Nanda <snanda@chromium.org>
* Add 'fanduty' command both EC console and ectool.Bill Richardson2012-06-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This forces the fan PWM duty cycle to a fixed percentage (0-100). It's only used for airflow testing. BUG=chrome-os-partner:10747 TEST=manual Using this ectool, try ectool fanduty 0 ectool pwmgetfanrpm ectool fanduty 50 ectool pwmgetfanrpm ectool fanduty 100 ectool pwmgetfanrpm You should see (and hear) the fan speed up. If you have an EC console, you can run faninfo and it should show that the 'Target:' is unrelated to the 'Actual:' value. Change-Id: Iac332fb3ba63f96726cf7f64061b3ce22d2e76fd Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/25965 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Make ectool correctly report when keyboard backlight is offVic Yang2012-05-261-0/+3
| | | | | | | | | | | When keyboard backlight is disabled, make 'ectool pwmgetkblight' reports 'disabled'. BUG=chrome-os-partner:9966 TEST='ectool pwmgetkblight' shows 'Keyboard backlight disabled' when lid closed. Change-Id: Ica690159e30431ccb530275fcc2311fb8f54a9aa
* Added HOOK_INIT for driver module initsRandall Spangler2012-04-191-6/+0
| | | | | | | | | | | | This covers modules which need to initialize before task_start(), but don't particularly care in what order they're initialized. Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=none TEST=if it boots, it works Change-Id: I69829aac8d1c3c14ee04916a794b84bbf03a09eb
* Disable screen and keyboard backlights when lid is closed.Randall Spangler2012-04-131-7/+10
| | | | | | | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:7832 TEST=manual 1. Power on system 2. From ec console: kblight 100 3. Use a magnet next to the left shift key to trigger the lid switch. Screen and keyboard should go dark. 4. Remove the magnet and they should light up again. Change-Id: I298ea94930976153d8dcd102316b010ee28cd747
* EC_LPC_COMMAND_PWM_GET_FAN_RPM return target RPMVic Yang2012-02-271-0/+3
| | | | | | | | | | | | Actual RPM is now read from LPC mapped space. Modify this command to return target RPM so we can verify EC receives target RPM. Signed-off-by: Vic Yang <victoryang@chromium.org> BUG=chrome-os-partner:8238 TEST=Get the same value after setting target RPM. Change-Id: I9bcc9edd327cec1311b51fd0fcbc4a43b353daff
* Disable fan PWM when +5VS is disabledRandall Spangler2012-02-271-0/+4
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:8097 TEST=manual faninfo should report fan is disabled powerbtn system turns on, fan turns on faninfo should report fan is enabled powerbtn system turns off, fan turns off faninfo should report fan is disabled again Change-Id: I1be67004edb23ccd18ad434c9340bfbecc22e7c4
* Revert "Disable fan PWM when +5VS is disabled"Dave Tu2012-02-271-4/+0
| | | | | This is causing a merge conflict on https://gerrit.chromium.org/gerrit/#change,16827. This reverts commit 3a460ea765417ce70bd760b91f46feca7cccb828
* Disable fan PWM when +5VS is disabledRandall Spangler2012-02-271-0/+4
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:8097 TEST=manual faninfo should report fan is disabled powerbtn system turns on, fan turns on faninfo should report fan is enabled powerbtn system turns off, fan turns off faninfo should report fan is disabled again Change-Id: I8e94c142bf18d07f83bac05287bcd503a098cee7
* Add EC host commands for keyboard backlightRandall Spangler2012-02-211-1/+4
| | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:8128 TEST='ectool setkblight X && ectool getkblight' for X=1, 20, 99, 100, 0 Change-Id: I540fd2d05f4caa110cd1dc45e9b5184fc8777a06
* Initial sources import 1/3Randall Spangler2011-12-071-0/+28
source files mainly done by Randall. Signed-off-by: Randall Spangler <rspangler@chromium.org> Change-Id: Iaff83a842b17f3350fb6f2a3f1597ad4c29bd12a
View Lorry Controller Status