2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-28 23:23:55 +08:00
linux-next/drivers/pwm/pwm-crc.c

136 lines
3.2 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright (C) 2015 Intel Corporation. All rights reserved.
*
* Author: Shobhit Kumar <shobhit.kumar@intel.com>
*/
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/mfd/intel_soc_pmic.h>
#include <linux/pwm.h>
#define PWM0_CLK_DIV 0x4B
#define PWM_OUTPUT_ENABLE BIT(7)
#define PWM_DIV_CLK_0 0x00 /* DIVIDECLK = BASECLK */
#define PWM_DIV_CLK_100 0x63 /* DIVIDECLK = BASECLK/100 */
#define PWM_DIV_CLK_128 0x7F /* DIVIDECLK = BASECLK/128 */
#define PWM0_DUTY_CYCLE 0x4E
#define BACKLIGHT_EN 0x51
#define PWM_MAX_LEVEL 0xFF
pwm: crc: Fix period / duty_cycle times being off by a factor of 256 While looking into adding atomic-pwm support to the pwm-crc driver I noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and there is a clock-divider which divides this with a value between 1-128, and there are 256 duty-cycle steps. The pwm-crc code before this commit assumed that a clock-divider setting of 1 means that the PWM output is running at 6 MHZ, if that is true, where do these 256 duty-cycle steps come from? This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that seems unlikely for a PMIC which is using a silicon process optimized for power-switching transistors. It is way more likely that there is an 8 bit counter for the duty cycle which acts as an extra fixed divider wrt the PWM output frequency. The main user of the pwm-crc driver is the i915 GPU driver which uses it for backlight control. Lets compare the PWM register values set by the video-BIOS (the GOP), assuming the extra fixed divider is present versus the PWM frequency specified in the Video-BIOS-Tables: Device: PWM Hz set by BIOS PWM Hz specified in VBT Asus T100TA 200 200 Asus T100HA 200 200 Lenovo Miix 2 8 23437 20000 Toshiba WT8-A 23437 20000 So as we can see if we assume the extra division by 256 then the register values set by the GOP are an exact match for the VBT values, where as otherwise the values would be of by a factor of 256. This commit fixes the period / duty_cycle calculations to take the extra division by 256 into account. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-9-hdegoede@redhat.com
2020-09-03 19:23:28 +08:00
#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
#define PWM_MAX_PERIOD_NS 5461333 /* 183 Hz */
/**
* struct crystalcove_pwm - Crystal Cove PWM controller
* @chip: the abstract pwm_chip structure.
* @regmap: the regmap from the parent device.
*/
struct crystalcove_pwm {
struct pwm_chip chip;
struct regmap *regmap;
};
static inline struct crystalcove_pwm *to_crc_pwm(struct pwm_chip *pc)
{
return container_of(pc, struct crystalcove_pwm, chip);
}
static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
{
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
return 0;
}
static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
{
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
}
static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
int duty_ns, int period_ns)
{
struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
struct device *dev = crc_pwm->chip.dev;
int level;
if (period_ns > PWM_MAX_PERIOD_NS) {
dev_err(dev, "un-supported period_ns\n");
return -EINVAL;
}
if (pwm_get_period(pwm) != period_ns) {
int clk_div;
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
pwm: crc: Fix period / duty_cycle times being off by a factor of 256 While looking into adding atomic-pwm support to the pwm-crc driver I noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and there is a clock-divider which divides this with a value between 1-128, and there are 256 duty-cycle steps. The pwm-crc code before this commit assumed that a clock-divider setting of 1 means that the PWM output is running at 6 MHZ, if that is true, where do these 256 duty-cycle steps come from? This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that seems unlikely for a PMIC which is using a silicon process optimized for power-switching transistors. It is way more likely that there is an 8 bit counter for the duty cycle which acts as an extra fixed divider wrt the PWM output frequency. The main user of the pwm-crc driver is the i915 GPU driver which uses it for backlight control. Lets compare the PWM register values set by the video-BIOS (the GOP), assuming the extra fixed divider is present versus the PWM frequency specified in the Video-BIOS-Tables: Device: PWM Hz set by BIOS PWM Hz specified in VBT Asus T100TA 200 200 Asus T100HA 200 200 Lenovo Miix 2 8 23437 20000 Toshiba WT8-A 23437 20000 So as we can see if we assume the extra division by 256 then the register values set by the GOP are an exact match for the VBT values, where as otherwise the values would be of by a factor of 256. This commit fixes the period / duty_cycle calculations to take the extra division by 256 into account. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-9-hdegoede@redhat.com
2020-09-03 19:23:28 +08:00
clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
/* enable back */
crc_pwm_enable(c, pwm);
}
/* change the pwm duty cycle */
level = duty_ns * PWM_MAX_LEVEL / period_ns;
regmap_write(crc_pwm->regmap, PWM0_DUTY_CYCLE, level);
return 0;
}
static const struct pwm_ops crc_pwm_ops = {
.config = crc_pwm_config,
.enable = crc_pwm_enable,
.disable = crc_pwm_disable,
};
static int crystalcove_pwm_probe(struct platform_device *pdev)
{
struct crystalcove_pwm *pwm;
struct device *dev = pdev->dev.parent;
struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
if (!pwm)
return -ENOMEM;
pwm->chip.dev = &pdev->dev;
pwm->chip.ops = &crc_pwm_ops;
pwm->chip.base = -1;
pwm->chip.npwm = 1;
/* get the PMIC regmap */
pwm->regmap = pmic->regmap;
platform_set_drvdata(pdev, pwm);
return pwmchip_add(&pwm->chip);
}
static int crystalcove_pwm_remove(struct platform_device *pdev)
{
struct crystalcove_pwm *pwm = platform_get_drvdata(pdev);
return pwmchip_remove(&pwm->chip);
}
static struct platform_driver crystalcove_pwm_driver = {
.probe = crystalcove_pwm_probe,
.remove = crystalcove_pwm_remove,
.driver = {
.name = "crystal_cove_pwm",
},
};
builtin_platform_driver(crystalcove_pwm_driver);