summaryrefslogtreecommitdiffstats
path: root/drivers/pwm/pwm-cros-ec.c
Commit message (Collapse)AuthorAgeFilesLines
* pwm: cros-ec: Fix transposed param settingsNick Vaccaro2017-07-061-2/+2
| | | | | | | | | | | | | The __cros_ec_pwm_get_duty() routine was transposing the insize and outsize fields when calling cros_ec_cmd_xfer_status(). The original code worked without error due to size of the two particular parameter blocks passed to cros_ec_cmd_xfer_status(), so this change is not fixing an actual runtime problem, just correcting the calling usage. Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
* pwm: cros-ec: Add __packed to prevent paddingBrian Norris2016-09-061-2/+2
| | | | | | | | | | | | | | | | | | While the particular usage in question is likely safe (struct cros_ec_command is 32-bit aligned, followed by <= 32-bit fields), it's been suggested this is not a great pattern to follow for the general case -- for example, if we follow a 'struct cros_ec_command' (which is 32-bit- but not 64-bit-aligned) with a struct that starts with a 64-bit type (e.g., u64), the compiler may add padding. Let's add __packed, to inform the compiler of our true intention -- to have no padding between these struct elements -- and to future proof for any refactorings that might occur. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
* pwm: Add ChromeOS EC PWM driverBrian Norris2016-07-251-0/+260
Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control one or more PWMs attached to the Embedded Controller. Because the EC allows us to modify the duty cycle (as a percentage, where U16_MAX is 100%) but not the period, we assign the period a fixed value of EC_PWM_MAX_DUTY and reject all attempts to change it. This driver supports only device tree at the moment, because that provides a very flexible way of describing the relationship between PWMs and their consumer devices (e.g., backlight). On a non-DT system, we'll probably want to use the non-GENERIC addressing (i.e., we'll need to make special device instances that will use EC_PWM_TYPE_KB_LIGHT or EC_PWM_TYPE_DISPLAY_LIGHT), as well as the relatively inflexible pwm_lookup infrastructure for matching devices. Defer that work for now. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
OpenPOWER on IntegriCloud