Re: [GIT PULL] extcon fixes for v5.1-rc4
Dear Greg, Gently ping. Best Regards, Chanwoo Choi On 19. 4. 5. 오전 10:21, Chanwoo Choi wrote: > Dear Greg, > > This is extcon-fixes pull request for v5.1-rc4. I add detailed description of > this pull request on below. Please pull extcon with following updates. > > Best Regards, > Chanwoo Choi > > The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6: > > Linux 5.1-rc3 (2019-03-31 14:39:29 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-fixes-for-5.1-rc4 > > for you to fetch changes up to 86baf800de84eb89615c138d368b14bff5ee7d8a: > > extcon: ptn5150: fix COMPILE_TEST dependencies (2019-04-05 10:08:37 +0900) > > > Arnd Bergmann (1): > extcon: ptn5150: fix COMPILE_TEST dependencies > > drivers/extcon/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 19/19] PM / devfreq: Introduce driver for NVIDIA Tegra20
v_pm_opp_put(opp);
> +
> + err = clk_set_min_rate(tegra->clk, rate);
> + if (err)
> + return err;
> +
> + err = clk_set_rate(tegra->clk, 0);
> + if (err)
When fail happen, I think that you have to control
the restoring sequence for previous operation like clk_set_min_rate().
> + return err;
> +
> + return 0;
> +}
> +
> +static int tegra_devfreq_get_dev_status(struct device *dev,
> + struct devfreq_dev_status *stat)
> +{
> + struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> +
> + stat->busy_time = readl_relaxed(tegra->regs + MC_STAT_EMC_COUNT);
> + stat->total_time = readl_relaxed(tegra->regs + MC_STAT_EMC_CLOCKS) / 8;
> + stat->current_frequency = clk_get_rate(tegra->clk);
> +
> + writel_relaxed(EMC_GATHER_CLEAR, tegra->regs + MC_STAT_CONTROL);
> + writel_relaxed(EMC_GATHER_ENABLE, tegra->regs + MC_STAT_CONTROL);
> +
> + return 0;
> +}
> +
> +static struct devfreq_dev_profile tegra_devfreq_profile = {
> + .polling_ms = 500,
> + .target = tegra_devfreq_target,
> + .get_dev_status = tegra_devfreq_get_dev_status,
> +};
> +
> +static struct tegra_mc *tegra_get_memory_controller(void)
> +{
> + struct platform_device *pdev;
> + struct device_node *np;
> + struct tegra_mc *mc;
> +
> + np = of_find_compatible_node(NULL, NULL, "nvidia,tegra20-mc-gart");
> + if (!np)
> + return ERR_PTR(-ENOENT);
> +
> + pdev = of_find_device_by_node(np);
> + of_node_put(np);
> + if (!pdev)
> + return ERR_PTR(-ENODEV);
> +
> + mc = platform_get_drvdata(pdev);
> + if (!mc)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return mc;
> +}
> +
> +static int tegra_devfeq_probe(struct platform_device *pdev)
> +{
> + struct tegra_devfreq *tegra;
> + struct tegra_mc *mc;
> + unsigned long max_rate;
> + unsigned long rate;
> + int err;
> +
> + mc = tegra_get_memory_controller();
> + if (IS_ERR(mc)) {
> + err = PTR_ERR(mc);
> + dev_err(>dev, "failed to get mc: %d\n", err);
How about using 'memory controller' instead of 'mc'?
Because 'mc' is not standard expression.
> + return err;
> + }
> +
> + tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
> + if (!tegra)
> + return -ENOMEM;
> +
> + tegra->clk = devm_clk_get(>dev, "emc");
> + if (IS_ERR(tegra->clk)) {
> + err = PTR_ERR(tegra->clk);
> + dev_err(>dev, "failed to get emc clock: %d\n", err);
> + return err;
> + }
Don't you need to enable the 'emc' clock'?
Because this patch doesn't enable this clock.
> +
> + tegra->regs = mc->regs;
> +
> + max_rate = clk_round_rate(tegra->clk, ULONG_MAX);
> +
> + for (rate = 0; rate <= max_rate; rate++) {
> + rate = clk_round_rate(tegra->clk, rate);
> + dev_pm_opp_add(>dev, rate, 0);
> + }
> +
> + writel_relaxed(0x, tegra->regs + MC_STAT_CONTROL);
> + writel_relaxed(0x, tegra->regs + MC_STAT_EMC_CONTROL);
> + writel_relaxed(0x, tegra->regs + MC_STAT_EMC_CLOCK_LIMIT);
You better to add the comments of what are the meaning
of 0x/0x. Without the detailed comments,
it is difficult to understand of meaning.
> +
> + platform_set_drvdata(pdev, tegra);
> +
> + tegra->devfreq = devfreq_add_device(>dev, _devfreq_profile,
> + DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
> + if (IS_ERR(tegra->devfreq))
> + return PTR_ERR(tegra->devfreq);
> +
> + return 0;
> +}
> +
> +static int tegra_devfreq_remove(struct platform_device *pdev)
> +{
> + struct tegra_devfreq *tegra = platform_get_drvdata(pdev);
> +
> + devfreq_remove_device(tegra->devfreq);
> + dev_pm_opp_remove_all_dynamic(>dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver tegra_devfeq_driver = {
> + .probe = tegra_devfeq_probe,
> + .remove = tegra_devfreq_remove,
> + .driver = {
> + .name = "tegra20-devfreq",
How can you bind this driver without compatible name for Devicetree?
And I tried to find the name ("tegra20-devfreq") in
the MFD drivers.
> + },
> +};
> +module_platform_driver(tegra_devfeq_driver);
> +
> +MODULE_ALIAS("platform:tegra20-devfreq");
> +MODULE_AUTHOR("Dmitry Osipenko ");
> +MODULE_DESCRIPTION("NVIDIA Tegra20 devfreq driver");
> +MODULE_LICENSE("GPL v2");
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 05/19] PM / devfreq: tegra: Replace write memory barrier with the read barrier
Hi,
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> The write memory barrier isn't needed because the BUS buffer is flushed
> by read after write that happens after the removed wmb(), we will also
> use readl() instead of the relaxed version to ensure that read is indeed
> completed.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index d62fb1b0d9bb..f0f0d78f6cbf 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -243,8 +243,7 @@ static void tegra_devfreq_update_wmark(struct
> tegra_devfreq *tegra,
> static void actmon_write_barrier(struct tegra_devfreq *tegra)
> {
> /* ensure the update has reached the ACTMON */
> - wmb();
> - actmon_readl(tegra, ACTMON_GLB_STATUS);
> + readl(tegra->regs + ACTMON_GLB_STATUS);
I think that this meaning of actmon_write_barrier() keeps
the order of 'store' assembly command without the execution change
from compiler optimization by using the wmb().
But, this patch edits it as following:
The result of the following two cases are same?
[original code]
wmb()
read_relaxed()
[new code by this patch]
readl_relaxed()
rmb()
> }
>
> static void actmon_isr_device(struct tegra_devfreq *tegra,
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 17/19] PM / devfreq: tegra: Support Tegra30
Hi,
On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote:
> The devfreq driver can be used on Tegra30 without any code change and
> it works perfectly fine, the default Tegra124 parameters are good enough
> for Tegra30.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/Kconfig | 4 ++--
> drivers/devfreq/tegra-devfreq.c | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index a78dffe603c1..78c33ddd4eea 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -92,8 +92,8 @@ config ARM_EXYNOS_BUS_DEVFREQ
> This does not yet operate with optimal voltages.
>
> config ARM_TEGRA_DEVFREQ
> - tristate "Tegra DEVFREQ Driver"
> - depends on ARCH_TEGRA_124_SOC
> + tristate "NVIDIA Tegra30+ DEVFREQ Driver"
Looks good to me. But, I have a question.
'Tegra30+' expression is enough in order to indicate
the support for both tegra30 and tegra124?
In my case, it is difficult to catch the meaning
of which tegra30+ support the kind of tegra124.
> + depends on ARCH_TEGRA
> select PM_OPP
> help
> This adds the DEVFREQ driver for the Tegra family of SoCs.
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index f0711d5ad27d..0a2465a58cf5 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -719,6 +719,7 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id tegra_devfreq_of_match[] = {
> + { .compatible = "nvidia,tegra30-actmon" },
> { .compatible = "nvidia,tegra124-actmon" },
> { },
> };
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 18/19] PM / devfreq: tegra: Enable COMPILE_TEST for the driver
On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote: > The driver's compilation doesn't have any specific dependencies, hence > the COMPILE_TEST option can be supported in Kconfig. > > Signed-off-by: Dmitry Osipenko > --- > drivers/devfreq/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index 78c33ddd4eea..bd6652863e7d 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -93,7 +93,7 @@ config ARM_EXYNOS_BUS_DEVFREQ > > config ARM_TEGRA_DEVFREQ > tristate "NVIDIA Tegra30+ DEVFREQ Driver" > - depends on ARCH_TEGRA > + depends on ARCH_TEGRA || COMPILE_TEST > select PM_OPP > help > This adds the DEVFREQ driver for the Tegra family of SoCs. > I think that it doesn't need to make it a separate patch. You can merge this patch to patch17 and then drop this patch. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 15/19] PM / devfreq: tegra: Synchronize IRQ after masking it in hardware
Hi,
In this patchset,
the patch11 adds new 'disable_interrupt' goto statement
and then patch15 removes 'disable_interrupt' goto statement again.
Actually, it is inefficient.
If you change the order of patches,
you could remove this stuff.
On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote:
> There is no guarantee that interrupt handling isn't running in parallel,
> hence it is necessary to synchronize IRQ in order to ensure that interrupt
> is indeed disabled.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 33 -
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 46c61af8ca33..cfbfbe28e7bf 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -171,6 +171,8 @@ struct tegra_devfreq {
> struct notifier_block rate_change_nb;
>
> struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
> +
> + int irq;
> };
>
> struct tegra_actmon_emc_ratio {
> @@ -432,6 +434,8 @@ static void tegra_actmon_disable_interrupts(struct
> tegra_devfreq *tegra)
> }
>
> actmon_write_barrier(tegra);
> +
> + synchronize_irq(tegra->irq);
> }
>
> static void tegra_actmon_configure_device(struct tegra_devfreq *tegra,
> @@ -603,7 +607,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> struct resource *res;
> unsigned int i;
> unsigned long rate;
> - int irq;
> int err;
>
> tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
> @@ -659,18 +662,18 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> tegra_actmon_configure_device(tegra, dev);
> }
>
> + tegra->irq = platform_get_irq(pdev, 0);
> + if (tegra->irq < 0) {
> + err = tegra->irq;
> + dev_err(>dev, "Failed to get IRQ: %d\n", err);
> + return err;
> + }
> +
> for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
> rate = clk_round_rate(tegra->emc_clock, rate);
> dev_pm_opp_add(>dev, rate, 0);
> }
>
> - irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - err = irq;
> - dev_err(>dev, "Failed to get IRQ: %d\n", err);
> - goto remove_opps;
> - }
> -
> platform_set_drvdata(pdev, tegra);
>
> err = devfreq_add_governor(_devfreq_governor);
> @@ -689,10 +692,11 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> goto remove_governor;
> }
>
> - err = request_threaded_irq(irq, NULL, actmon_thread_isr, IRQF_ONESHOT,
> -"tegra-devfreq", tegra);
> + err = devm_request_threaded_irq(>dev, tegra->irq, NULL,
> + actmon_thread_isr, IRQF_ONESHOT,
> + "tegra-devfreq", tegra);
> if (err) {
> - dev_err(>dev, "Interrupt request failed\n");
> + dev_err(>dev, "Interrupt request failed: %d\n", err);
> goto remove_devfreq;
> }
>
> @@ -701,14 +705,11 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> if (err) {
> dev_err(>dev,
> "Failed to register rate change notifier\n");
> - goto disable_interrupt;
> + goto remove_devfreq;
> }
>
> return 0;
>
> -disable_interrupt:
> - free_irq(irq, tegra);
> -
> remove_devfreq:
> devfreq_remove_device(tegra->devfreq);
>
> @@ -727,10 +728,8 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> static int tegra_devfreq_remove(struct platform_device *pdev)
> {
> struct tegra_devfreq *tegra = platform_get_drvdata(pdev);
> - int irq = platform_get_irq(pdev, 0);
>
> clk_notifier_unregister(tegra->emc_clock, >rate_change_nb);
> - free_irq(irq, tegra);
>
> devfreq_remove_device(tegra->devfreq);
> dev_pm_opp_remove_all_dynamic(>dev);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 14/19] PM / devfreq: tegra: Move governor registration to driver's probe
On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote:
> There is no need to register the ACTMON's governor separately from
> the driver, hence let's move the registration into the driver's probe
> function for consistency and to make code cleaner a tad.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 44 +
> 1 file changed, 12 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 832e4f5aa11b..46c61af8ca33 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -673,6 +673,12 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, tegra);
>
> + err = devfreq_add_governor(_devfreq_governor);
> + if (err) {
> + dev_err(>dev, "Failed to add governor: %d\n", err);
> + goto remove_opps;
> + }
> +
> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
> tegra->devfreq = devfreq_add_device(>dev,
> _devfreq_profile,
> @@ -680,7 +686,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> NULL);
> if (IS_ERR(tegra->devfreq)) {
> err = PTR_ERR(tegra->devfreq);
> - goto remove_opps;
> + goto remove_governor;
> }
>
> err = request_threaded_irq(irq, NULL, actmon_thread_isr, IRQF_ONESHOT,
> @@ -706,6 +712,9 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> remove_devfreq:
> devfreq_remove_device(tegra->devfreq);
>
> +remove_governor:
> + devfreq_remove_governor(_devfreq_governor);
> +
> remove_opps:
> dev_pm_opp_remove_all_dynamic(>dev);
>
> @@ -729,7 +738,7 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> reset_control_reset(tegra->reset);
> clk_disable_unprepare(tegra->clock);
>
> - return 0;
> + return devfreq_remove_governor(_devfreq_governor);
> }
>
> static const struct of_device_id tegra_devfreq_of_match[] = {
> @@ -747,36 +756,7 @@ static struct platform_driver tegra_devfreq_driver = {
> .of_match_table = tegra_devfreq_of_match,
> },
> };
> -
> -static int __init tegra_devfreq_init(void)
> -{
> - int ret = 0;
> -
> - ret = devfreq_add_governor(_devfreq_governor);
> - if (ret) {
> - pr_err("%s: failed to add governor: %d\n", __func__, ret);
> - return ret;
> - }
> -
> - ret = platform_driver_register(_devfreq_driver);
> - if (ret)
> - devfreq_remove_governor(_devfreq_governor);
> -
> - return ret;
> -}
> -module_init(tegra_devfreq_init)
> -
> -static void __exit tegra_devfreq_exit(void)
> -{
> - int ret = 0;
> -
> - platform_driver_unregister(_devfreq_driver);
> -
> - ret = devfreq_remove_governor(_devfreq_governor);
> - if (ret)
> - pr_err("%s: failed to remove governor: %d\n", __func__, ret);
> -}
> -module_exit(tegra_devfreq_exit)
> +module_platform_driver(tegra_devfreq_driver);
>
> MODULE_LICENSE("GPL v2");
> MODULE_DESCRIPTION("Tegra devfreq driver");
>
Looks good to me.
Reviewed-by : Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 13/19] PM / devfreq: tegra: Mark ACTMON's governor as immutable
Hi,
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> The ACTMON's governor supports only the Tegra's devfreq device and there
> is no need to use any other governor, hence let's mark Tegra governor as
> immutable to permanently stick it with Tegra's devfreq device.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/Kconfig | 1 -
> drivers/devfreq/tegra-devfreq.c | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 6a172d338f6d..a78dffe603c1 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -94,7 +94,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
> config ARM_TEGRA_DEVFREQ
> tristate "Tegra DEVFREQ Driver"
> depends on ARCH_TEGRA_124_SOC
> - select DEVFREQ_GOV_SIMPLE_ONDEMAND
> select PM_OPP
> help
> This adds the DEVFREQ driver for the Tegra family of SoCs.
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index f1a6f951813a..832e4f5aa11b 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -593,6 +593,7 @@ static struct devfreq_governor tegra_devfreq_governor = {
> .name = "tegra_actmon",
> .get_target_freq = tegra_governor_get_target,
> .event_handler = tegra_governor_event_handler,
> + .immutable = true,
> };
>
> static int tegra_devfreq_probe(struct platform_device *pdev)
>
Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 12/19] PM / devfreq: tegra: Avoid inconsistency of current frequency value
Hi,
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> The frequency value potentially could change in-between. It doesn't
> cause any real problem at all right now, but that could change in the
> future. Hence let's avoid the inconsistency.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index a668e4fbc874..f1a6f951813a 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -496,13 +496,15 @@ static int tegra_devfreq_get_dev_status(struct device
> *dev,
> {
> struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> struct tegra_devfreq_device *actmon_dev;
> + unsigned long cur_freq;
>
> - stat->current_frequency = tegra->cur_freq * KHZ;
> + cur_freq = READ_ONCE(tegra->cur_freq);
>
> /* To be used by the tegra governor */
> stat->private_data = tegra;
>
> /* The below are to be used by the other governors */
> + stat->current_frequency = cur_freq * KHZ;
>
> actmon_dev = >devices[MCALL];
>
> @@ -513,7 +515,7 @@ static int tegra_devfreq_get_dev_status(struct device
> *dev,
> stat->busy_time *= 100 / BUS_SATURATION_RATIO;
>
> /* Number of cycles in a sampling period */
> - stat->total_time = ACTMON_SAMPLING_PERIOD * tegra->cur_freq;
> + stat->total_time = ACTMON_SAMPLING_PERIOD * cur_freq;
>
> stat->busy_time = min(stat->busy_time, stat->total_time);
>
>
The read/write access of tegra->cur_freq is in the single routine
of update_devfreq() as following. I think that there are no any
potential problem about the inconsistency of tegra->cur_freq.
IMHO, if there are no any problem now, I'm not sure that we need
to apply this patch.
update_devfreq()
{
devfreq->governor->get_target_freq()
devfreq_update_stats(devfreq)
tegra_devfreq_get_dev_status()
stat->current_frequency = tegra->cur_freq * KHZ;
devfreq_set_target()
tegra_devfreq_target()
clk_set_min_rate(emc_rate, )
tegra_actmon_rate_notify_cb()
tegra->cur_freq = data->new_rate / KHZ;
clk_set_rate(emc_rate, )
tegra_actmon_rate_notify_cb()
tegra->cur_freq = data->new_rate / KHZ;
}
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 11/19] PM / devfreq: tegra: De-initialize properly on driver's probe error
Hi Dmitry,
I already replied against patch6 about the exception handling
of tegra_devfreq_probe(). This patchset split out the patch
related to error handling for probe(). I think that you can
squash the patches regarding of exception handling for probe()
to one patch instead of split out the multiple patches.
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> Reset hardware, disable ACTMON clock, release OPP's and free IRQ before
> removing devfreq device since there is no guarantee that interrupt
> handling won't run after masking interrupt in hardware.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 53 -
> 1 file changed, 26 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 69b557df5084..a668e4fbc874 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -663,28 +663,28 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> - dev_err(>dev, "Failed to get IRQ: %d\n", irq);
> - return irq;
> + err = irq;
> + dev_err(>dev, "Failed to get IRQ: %d\n", err);
> + goto remove_opps;
> }
>
> platform_set_drvdata(pdev, tegra);
>
> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
> - tegra->devfreq = devm_devfreq_add_device(>dev,
> - _devfreq_profile,
> - "tegra_actmon",
> - NULL);
> + tegra->devfreq = devfreq_add_device(>dev,
> + _devfreq_profile,
> + "tegra_actmon",
> + NULL);
> if (IS_ERR(tegra->devfreq)) {
> err = PTR_ERR(tegra->devfreq);
> - return err;
> + goto remove_opps;
> }
>
> - err = devm_request_threaded_irq(>dev, irq, NULL,
> - actmon_thread_isr, IRQF_ONESHOT,
> - "tegra-devfreq", tegra);
> + err = request_threaded_irq(irq, NULL, actmon_thread_isr, IRQF_ONESHOT,
> +"tegra-devfreq", tegra);
> if (err) {
> dev_err(>dev, "Interrupt request failed\n");
> - goto remove_opps;
> + goto remove_devfreq;
> }
>
> tegra->rate_change_nb.notifier_call = tegra_actmon_rate_notify_cb;
> @@ -692,14 +692,23 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> if (err) {
> dev_err(>dev,
> "Failed to register rate change notifier\n");
> - goto remove_opps;
> + goto disable_interrupt;
> }
>
> return 0;
>
> +disable_interrupt:
> + free_irq(irq, tegra);
> +
> +remove_devfreq:
> + devfreq_remove_device(tegra->devfreq);
> +
> remove_opps:
> dev_pm_opp_remove_all_dynamic(>dev);
>
> + reset_control_reset(tegra->reset);
> + clk_disable_unprepare(tegra->clock);
> +
> return err;
> }
>
> @@ -707,24 +716,14 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> {
> struct tegra_devfreq *tegra = platform_get_drvdata(pdev);
> int irq = platform_get_irq(pdev, 0);
> - u32 val;
> - unsigned int i;
> -
> - devm_devfreq_remove_device(>dev, tegra->devfreq);
> - dev_pm_opp_remove_all_dynamic(>dev);
> -
> - for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
> - val = device_readl(>devices[i], ACTMON_DEV_CTRL);
> - val &= ~ACTMON_DEV_CTRL_ENB;
> - device_writel(>devices[i], val, ACTMON_DEV_CTRL);
> - }
> -
> - actmon_write_barrier(tegra);
> -
> - devm_free_irq(>dev, irq, tegra);
>
> clk_notifier_unregister(tegra->emc_clock, >rate_change_nb);
> + free_irq(irq, tegra);
> +
> + devfreq_remove_device(tegra->devfreq);
> + dev_pm_opp_remove_all_dynamic(>dev);
>
> + reset_control_reset(tegra->reset);
> clk_disable_unprepare(tegra->clock);
>
> return 0;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 10/19] PM / devfreq: tegra: Drop primary interrupt handler
> static int tegra_actmon_rate_notify_cb(struct notifier_block *nb,
> @@ -386,7 +373,6 @@ static int tegra_actmon_rate_notify_cb(struct
> notifier_block *nb,
> struct tegra_devfreq *tegra;
> struct tegra_devfreq_device *dev;
> unsigned int i;
> - unsigned long flags;
>
> if (action != POST_RATE_CHANGE)
> return NOTIFY_OK;
> @@ -398,9 +384,7 @@ static int tegra_actmon_rate_notify_cb(struct
> notifier_block *nb,
When I review this patch, I have a question
about why tegra_actmon_rate_notify_cb is needed.
tegra_actmon_rate_notify_cb() do something
when the clock rate of emc_clock is changed.
I think that 'emc_clock' is changed by this driver.
It means that the this driver can catch the change timing
of emc_clock rate without notifier.
IMO, it is possible to call tegra_devfreq_update_wmark()
directly without clock notifier before calling
'clk_set_min_rate()/clk_set_rate()' in the tegra_devfreq_target().
With clock notifier, it cannot restore something for
tegra_devfreq_update_wmark(tegra, dev) when failed to
set the rate of emc_clk by 'clk_set_min_rate()/clk_set_rate()'.
> for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
> dev = >devices[i];
>
> - spin_lock_irqsave(>lock, flags);
> tegra_devfreq_update_wmark(tegra, dev);
> - spin_unlock_irqrestore(>lock, flags);
> }
>
> actmon_write_barrier(tegra);
> @@ -668,7 +652,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> dev = tegra->devices + i;
> dev->config = actmon_device_configs + i;
> dev->regs = tegra->regs + dev->config->offset;
> - spin_lock_init(>lock);
>
> tegra_actmon_configure_device(tegra, dev);
> }
> @@ -696,8 +679,8 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> - err = devm_request_threaded_irq(>dev, irq, actmon_isr,
> - actmon_thread_isr, IRQF_SHARED,
> + err = devm_request_threaded_irq(>dev, irq, NULL,
> + actmon_thread_isr, IRQF_ONESHOT,
> "tegra-devfreq", tegra);
> if (err) {
> dev_err(>dev, "Interrupt request failed\n");
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 06/19] PM / devfreq: tegra: Fix missed error checking on devfreq initialization failure
Hi,
patch6/7/8/9 are for handling of exception handling in probe() function.
Actually, I'm not sure that there are special reason to split out
the patches. I think that you can squash patch6/7/8/9 to only one patch.
Also, even if patch6/7/8/9 handle the exception handling in probe(),
the tegra_devfreq_probe() doesn't support the restoring sequence
when fail happen. I think that if you want to fix the fail case of probe(),
please add the restoring sequence about following function.
- clk_disable_unprepare()
- clk_notifier_unregister()
- dev_pm_opp_remove()
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> The code doesn't check for devfreq initialization failure, fix it.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index f0f0d78f6cbf..aa0478464b35 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -707,6 +707,10 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>_devfreq_profile,
>"tegra_actmon",
>NULL);
> + if (IS_ERR(tegra->devfreq)) {
> + err = PTR_ERR(tegra->devfreq);
> + return err;
> + }
>
> return 0;
> }
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 04/19] PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe
Hi,
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> There is no real benefit from doing so, hence let's drop that rate setting
> for consistency.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 69581c9082d4..d62fb1b0d9bb 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -648,8 +648,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return PTR_ERR(tegra->emc_clock);
> }
>
> - clk_set_rate(tegra->emc_clock, ULONG_MAX);
> -
It seems like that initialize the emc_clock as the supported maximum clock.
But, if the rate for emc_clock initialized by either bootloader or clock driver
and it's well working until this code, actually, it is not necessary.
Looks good to me.
Reviewed-by: Chanwoo Choi
> tegra->rate_change_nb.notifier_call = tegra_actmon_rate_notify_cb;
> err = clk_notifier_register(tegra->emc_clock, >rate_change_nb);
> if (err) {
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 03/19] PM / devfreq: tegra: Don't ignore clk errors
Hi,
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> The clk_set_min_rate() could fail and in this case clk_set_rate() sets
> rate to 0, which may drop EMC rate to minimum and make machine very
> difficult to use.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 0c0909fba545..69581c9082d4 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -487,6 +487,7 @@ static int tegra_devfreq_target(struct device *dev,
> unsigned long *freq,
> struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> struct dev_pm_opp *opp;
> unsigned long rate;
> + int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> @@ -496,8 +497,13 @@ static int tegra_devfreq_target(struct device *dev,
> unsigned long *freq,
> rate = dev_pm_opp_get_freq(opp);
> dev_pm_opp_put(opp);
>
> - clk_set_min_rate(tegra->emc_clock, rate);
> - clk_set_rate(tegra->emc_clock, 0);
> + err = clk_set_min_rate(tegra->emc_clock, rate);
> + if (err)
> + return err;
> +
> + err = clk_set_rate(tegra->emc_clock, 0);
> + if (err)
Why don't you restore the previous minimum clock for tegra->emc_clock
when failed to execute 'clk_set_rate(tegra->emc_clock, 0);'?
I think that if you control the restoring the previous minimum clock,
it is more nice to handle the error handling.
> + return err;
>
> return 0;
> }
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 01/19] PM / devfreq: tegra: Fix kHz to Hz conversion
Hi,
I add one minor comment (KHZ -> hz).
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> The kHz to Hz is incorrectly converted in a few places in the code,
> this results in a wrong frequency being calculated because devfreq core
> uses OPP frequencies that are given in Hz to clamp the rate, while
> tegra-devfreq gives to the core value in kHz and then it also expects to
> receive value in kHz from the core. In a result memory freq is always set
> to a value which is close to ULONG_MAX because of the bug. Hence the EMC
> frequency is always capped to the maximum and the driver doesn't do
> anything useful. This patch was tested on Tegra30 and Tegra124 SoC's, EMC
> frequency scaling works properly now.
>
> Cc: # 4.14+
> Tested-by: Steev Klimaszewski
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index c89ba7b834ff..02905978abe1 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -486,9 +486,9 @@ static int tegra_devfreq_target(struct device *dev,
> unsigned long *freq,
> {
> struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> struct dev_pm_opp *opp;
> - unsigned long rate = *freq * KHZ;
> + unsigned long rate;
>
> - opp = devfreq_recommended_opp(dev, , flags);
> + opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> dev_err(dev, "Failed to find opp for %lu KHz\n", *freq);
Need to change it as following:
- KHz -> Hz
> return PTR_ERR(opp);
> @@ -499,8 +499,6 @@ static int tegra_devfreq_target(struct device *dev,
> unsigned long *freq,
> clk_set_min_rate(tegra->emc_clock, rate);
> clk_set_rate(tegra->emc_clock, 0);
>
> - *freq = rate;
> -
> return 0;
> }
>
> @@ -510,7 +508,7 @@ static int tegra_devfreq_get_dev_status(struct device
> *dev,
> struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> struct tegra_devfreq_device *actmon_dev;
>
> - stat->current_frequency = tegra->cur_freq;
> + stat->current_frequency = tegra->cur_freq * KHZ;
>
> /* To be used by the tegra governor */
> stat->private_data = tegra;
> @@ -565,7 +563,7 @@ static int tegra_governor_get_target(struct devfreq
> *devfreq,
> target_freq = max(target_freq, dev->target_freq);
> }
>
> - *freq = target_freq;
> + *freq = target_freq * KHZ;
>
> return 0;
> }
>
It looks good to me if modify it in accordance with my comment.
Reviewed-by: Chanwoo Choi
Regards,
Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor
egister(_data);
> + } else {
> + devm_devfreq_unregister_notifier(dev, parent, nb,
> + DEVFREQ_TRANSITION_NOTIFIER);
> + }
ditto.
> break;
> default:
> break;
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index fbffa74bfc1b..e8235fbe49e6 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -265,6 +265,38 @@ struct devfreq_simple_ondemand_data {
> #endif
>
> #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
> +/**
> + * struct devfreq_cpu_state - holds the per-cpu state
> + * @freq:holds the current frequency of the cpu.
> + * @min_freq:holds the min frequency of the cpu.
> + * @max_freq:holds the max frequency of the cpu.
> + * @first_cpu: holds the cpumask of the first cpu of a policy.
> + *
> + * This structure stores the required cpu_state of a cpu.
> + * This is auto-populated by the governor.
> + */
> +struct devfreq_cpu_state {
> + unsigned int freq;
> + unsigned int min_freq;
> + unsigned int max_freq;
> + unsigned int first_cpu;
> +};
> +
> +/**
> + * struct devfreq_map - holds mapping from cpu frequency
> + * to devfreq frequency
> + * @cpu_khz: holds the cpu frequency in Khz
> + * @dev_hz: holds the devfreq device frequency in Hz
> + *
> + * This structure stores the lookup table between cpu
> + * and the devfreq device. This is auto-populated by the
> + * governor.
> + */
> +struct devfreq_map {
How about changing the structure name as following or others?
- devfreq_freq_map or devfreq_cpufreq_map or others.
Because this structure name guessing the meaning of mapping
between devfreq frequency and cpufreq frequency.
> + unsigned int cpu_khz;
> + unsigned int dev_hz;
> +};
> +
> /**
> * struct devfreq_passive_data - void *data fed to struct devfreq
> * and devfreq_add_device
> @@ -278,11 +310,13 @@ struct devfreq_simple_ondemand_data {
> * the next frequency, should use this callback.
> * @this:the devfreq instance of own device.
> * @nb: the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
> + * @state: holds the state min/max/current frequency of all online cpu's
As I commented above, how about using 'cpu_state' instead of 'state'?
in order to get the meaning from just variable name.
nitpick. Also, I think that you can skip 'holds' from the description
of 'state' variable.
> + * @map: holds the maps between cpu frequency and device frequency
How about using 'cpufreq_map' instead of 'map' for the readability?
IMHO, Because this variable is only used when parent device is cpu.
I think that if you add to specify the meaningful prefix about cpu to variable
name,
it is easy to catch the meaning of variable.
- map -> cpufreq_map.
nitpick. Also, I think that you can skip 'holds' from the description
of 'map' variable.
> *
> * The devfreq_passive_data have to set the devfreq instance of parent
> * device with governors except for the passive governor. But, don't need to
> - * initialize the 'this' and 'nb' field because the devfreq core will handle
> - * them.
> + * initialize the 'this', 'nb', 'state' and 'map' field because the devfreq
If you agree my opinion above,
- state -> cpu_state.
- map -> cpufreq_map
> + * core will handle them.
> */
> struct devfreq_passive_data {
> /* Should set the devfreq instance of parent device */
> @@ -291,9 +325,14 @@ struct devfreq_passive_data {
> /* Optional callback to decide the next frequency of passvice device */
> int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
>
> + /* Should be set if the devfreq device wants to be scaled with cpu*/
> + u8 cpufreq_type;
The devfreq devices with passive governor have always parent
either devfreq device or cpufreq device. So, you better to specify
the parent type as following: I think that it is more clear to check
the type of parent device.
enum devfreq_parent_dev_type {
DEVFREQ_PARENT_DEV,
CPUFREQ_PARENT_DEV,
};
enum devfreq_parent_dev_type parent_type;
> +
> /* For passive governor's internal use. Don't need to set them */
> struct devfreq *this;
> struct notifier_block nb;
> + struct devfreq_cpu_state *state[NR_CPUS];
> + struct devfreq_map **map;
ditto.
> };
> #endif
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2] extcon: axp288: Add a depends on ACPI to the Kconfig entry
Dear all,
+ sta...@vger.kernel.org
It should be posted to sta...@vger.kernel.org
in order to merge it to stable tree.
Regards,
Chanwoo Choi
On 19. 4. 12. 오전 8:30, Chanwoo Choi wrote:
> On 19. 4. 4. 오후 11:17, Yue Haibing wrote:
>> From: YueHaibing
>>
>> As Hans de Goede pointed, using this driver without ACPI
>> makes little sense, so add ACPI dependency to Kconfig entry
>> to fix a build error while CONFIG_ACPI is not set.
>>
>> drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe':
>> drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to
>> incomplete type
>> put_device(>dev);
>>
>> Fixes: 0cf064db948a ("extcon: axp288: Convert to use
>> acpi_dev_get_first_match_dev()")
>> Reported-by: Hulk Robot
>> Suggested-by: Hans de Goede
>> Signed-off-by: YueHaibing
>> ---
>> v2: rework patch
>> ---
>> drivers/extcon/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>> index 1ed4b45..de06faf 100644
>> --- a/drivers/extcon/Kconfig
>> +++ b/drivers/extcon/Kconfig
>> @@ -30,7 +30,7 @@ config EXTCON_ARIZONA
>>
>> config EXTCON_AXP288
>> tristate "X-Power AXP288 EXTCON support"
>> -depends on MFD_AXP20X && USB_SUPPORT && X86
>> +depends on MFD_AXP20X && USB_SUPPORT && X86 && ACPI
>> select USB_ROLE_SWITCH
>> help
>>Say Y here to enable support for USB peripheral detection
>>
>
> Applied it. Thanks.
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] extcon: arizona: Disable mic detect if running when driver is removed
Hi Charles,
On 19. 4. 5. 오전 1:33, Charles Keepax wrote:
> Microphone detection provides the button detection features on the
> Arizona CODECs as such it will be running if the jack is currently
> inserted. If the driver is unbound whilst the jack is still inserted
> this will cause warnings from the regulator framework as the MICVDD
> regulator is put but was never disabled.
>
> Correct this by disabling microphone detection on driver removal and if
> the microphone detection was running disable the regulator and put the
> runtime reference that was currently held.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index da0e9bc4262fa..9327479c719c2 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1726,6 +1726,16 @@ static int arizona_extcon_remove(struct
> platform_device *pdev)
> struct arizona_extcon_info *info = platform_get_drvdata(pdev);
> struct arizona *arizona = info->arizona;
> int jack_irq_rise, jack_irq_fall;
> + bool change;
> +
> + regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> + ARIZONA_MICD_ENA, 0,
> + );
> +
> + if (change) {
> + regulator_disable(info->micvdd);
> + pm_runtime_put(info->dev);
> + }>
> gpiod_put(info->micd_pol_gpio);
>
>
Applied it.
IMO, I think that this driver have to handle the exception handling
when regmap_update_bits_check() returns error or 'change' value
is not changed. This driver have same issue about exception handling
on multiple places. Please take it on separate patche.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2] extcon: axp288: Add a depends on ACPI to the Kconfig entry
On 19. 4. 4. 오후 11:17, Yue Haibing wrote:
> From: YueHaibing
>
> As Hans de Goede pointed, using this driver without ACPI
> makes little sense, so add ACPI dependency to Kconfig entry
> to fix a build error while CONFIG_ACPI is not set.
>
> drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe':
> drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to
> incomplete type
> put_device(>dev);
>
> Fixes: 0cf064db948a ("extcon: axp288: Convert to use
> acpi_dev_get_first_match_dev()")
> Reported-by: Hulk Robot
> Suggested-by: Hans de Goede
> Signed-off-by: YueHaibing
> ---
> v2: rework patch
> ---
> drivers/extcon/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 1ed4b45..de06faf 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -30,7 +30,7 @@ config EXTCON_ARIZONA
>
> config EXTCON_AXP288
> tristate "X-Power AXP288 EXTCON support"
> - depends on MFD_AXP20X && USB_SUPPORT && X86
> + depends on MFD_AXP20X && USB_SUPPORT && X86 && ACPI
> select USB_ROLE_SWITCH
> help
> Say Y here to enable support for USB peripheral detection
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[GIT PULL] extcon fixes for v5.1-rc4
Dear Greg, This is extcon-fixes pull request for v5.1-rc4. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6: Linux 5.1-rc3 (2019-03-31 14:39:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-fixes-for-5.1-rc4 for you to fetch changes up to 86baf800de84eb89615c138d368b14bff5ee7d8a: extcon: ptn5150: fix COMPILE_TEST dependencies (2019-04-05 10:08:37 +0900) Arnd Bergmann (1): extcon: ptn5150: fix COMPILE_TEST dependencies drivers/extcon/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH v2] clocksource: exynos_mct: Increase priority over ARM arch timer
Hi Marek,
On 19. 3. 21. 오후 5:26, Marek Szyprowski wrote:
> Exynos Multi-Core Timer driver (exynos_mct) must be started before ARM
> Architected Timers (arch_timer), because they both share some common
> hardware blocks (global system counter) and turning on MCT is needed
> to get ARM Architected Timer working properly. Increase MCT timer rating
> and hotplug priority over ARM Archictected timer driver to achieve that.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Krzysztof Kozlowski
> ---
> v2: added comments about the relation to ARM arch timer
> rebased onto v5.1-rc1
> v1: https://patchwork.kernel.org/patch/10814921/
> ---
> drivers/clocksource/exynos_mct.c | 4 ++--
> include/linux/cpuhotplug.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index 34bd250d46c6..6aa10cbc1d59 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -209,7 +209,7 @@ static void exynos4_frc_resume(struct clocksource *cs)
>
> static struct clocksource mct_frc = {
> .name = "mct-frc",
> - .rating = 400,
> + .rating = 450, /* use value higher than ARM arch timer */
> .read = exynos4_frc_read,
> .mask = CLOCKSOURCE_MASK(32),
> .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> @@ -464,7 +464,7 @@ static int exynos4_mct_starting_cpu(unsigned int cpu)
> evt->set_state_oneshot_stopped = set_state_shutdown;
> evt->tick_resume = set_state_shutdown;
> evt->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
> - evt->rating = 450;
> + evt->rating = 500; /* use value higher than ARM arch timer */
>
> exynos4_mct_write(TICK_BASE_CNT, mevt->base + MCT_L_TCNTB_OFFSET);
>
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index e78281d07b70..53fb48de9589 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -115,10 +115,10 @@ enum cpuhp_state {
> CPUHP_AP_PERF_ARM_ACPI_STARTING,
> CPUHP_AP_PERF_ARM_STARTING,
> CPUHP_AP_ARM_L2X0_STARTING,
> + CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
> CPUHP_AP_ARM_ARCH_TIMER_STARTING,
> CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
> CPUHP_AP_JCORE_TIMER_STARTING,
> - CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
> CPUHP_AP_ARM_TWD_STARTING,
> CPUHP_AP_QCOM_TIMER_STARTING,
> CPUHP_AP_TEGRA_TIMER_STARTING,
>
As the cover-letter, the arch-timer of Exynos SoC
used the h/w block of MCT. I agree.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] PM / devfreq: exynos-bus: Suspend all devices on system shutdown
Hi Marek,
On 19. 3. 21. 오후 6:01, Marek Szyprowski wrote:
> Force all Exynos buses to safe operation points before doing the system
> reboot operation. There are board on which some aggressive power saving
> operation points are behind the capabilities of the bootloader to properly
> reset the hardware and boot the board. This way one can avoid board crash
> early after reboot.
>
> This fixes reboot issue on OdroidU3 board both with eMMC and SD boot.
>
> Reported-by: Markus Reichl
> Signed-off-by: Marek Szyprowski
> ---
> This is an alternative to https://patchwork.kernel.org/patch/10781433/
> limited only to Exynos-bus driver.
> ---
> drivers/devfreq/exynos-bus.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index c25658b26598..486cc5b422f1 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -514,6 +514,13 @@ static int exynos_bus_probe(struct platform_device *pdev)
> return ret;
> }
>
> +static void exynos_bus_shutdown(struct platform_device *pdev)
> +{
> + struct exynos_bus *bus = dev_get_drvdata(>dev);
> +
> + devfreq_suspend_device(bus->devfreq);
> +}
> +
> #ifdef CONFIG_PM_SLEEP
> static int exynos_bus_resume(struct device *dev)
> {
> @@ -556,6 +563,7 @@ MODULE_DEVICE_TABLE(of, exynos_bus_of_match);
>
> static struct platform_driver exynos_bus_platdrv = {
> .probe = exynos_bus_probe,
> + .shutdown = exynos_bus_shutdown,
> .driver = {
> .name = "exynos-bus",
> .pm = _bus_pm,
>
Actually, I already agreed the previous patch.
Also, it looks good to me.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 0/2] extcon: Introduce support of Basin Cove PMIC
Hi Andy, On 19. 3. 19. 오후 11:30, Andy Shevchenko wrote: > On Intel Merrifield platforms the Basin Cove PMIC responsible for USB DR > detection among other things. > > Here is the extcon driver to support USB DR and charger detection. > > Since v2: > - rebase on top of extcon-next > - update copyright year > - address most of Chanwoo's comments > (rest is left in similarity with other Intel extcon drivers) > > Andy Shevchenko (2): > extcon: intel: Split out some definitions to a common header > extcon: mrfld: Introduce extcon driver for Basin Cove PMIC > > drivers/extcon/Kconfig | 7 + > drivers/extcon/Makefile | 1 + > drivers/extcon/extcon-intel-cht-wc.c | 21 +- > drivers/extcon/extcon-intel-mrfld.c | 284 +++ > drivers/extcon/extcon-intel.h| 20 ++ > 5 files changed, 319 insertions(+), 14 deletions(-) > create mode 100644 drivers/extcon/extcon-intel-mrfld.c > create mode 100644 drivers/extcon/extcon-intel.h > Applied them to extcon-next branch. Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH] extcon: fix a missing check of regmap_read
Hi,
You better to edit the patch title as following
in order to sustain the title format for extcon:
extcon: fix a missing check of regmap_read
-> extcon: axp288: Fix a missing check of regmap_read
On 19. 3. 20. 오후 4:35, Kangjie Lu wrote:
> When regmap_read fails, it doesn't make sense to use the read
> value "val" because it can be uninitialized.
>
> The fix returns if regmap_read fails.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/extcon/extcon-axp288.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
> index a983708b77a6..b2ba5f073aa7 100644
> --- a/drivers/extcon/extcon-axp288.c
> +++ b/drivers/extcon/extcon-axp288.c
> @@ -143,6 +143,10 @@ static void axp288_extcon_log_rsi(struct
> axp288_extcon_info *info)
> int ret;
>
> ret = regmap_read(info->regmap, AXP288_PS_BOOT_REASON_REG, );
> + if (ret) {
> + dev_err(info->dev, "failed to read BOOT_REASON_REG: %d\n", ret);
> + return;
> + }
Have to add the blank line. time.
And I think that axp288_extcon_log_rsi() have to return the 'error value'
instead of 'void' return type. And then should handle the return value
of axp288_extcon_log_rsi() within the axp288_extcon_probe().
For example,
ret = axp288_extcon_log_rsi(info)
if (ret < 0)
return ret;
> for (i = 0, rsi = axp288_pwr_up_down_info; *rsi; rsi++, i++) {
> if (val & BIT(i)) {
> dev_dbg(info->dev, "%s\n", *rsi);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 5/5] arm64: dts: rockchip: Enable dmc and dfi nodes on gru.
Hi Gaël,
On 19. 3. 20. 오전 3:13, Gaël PORTAY wrote:
> From: Lin Huang
>
> Enable the DMC (Dynamic Memory Controller) and the DFI (DDR PHY Interface)
> nodes on gru/kevin boards so we can support DDR DVFS.
>
> Signed-off-by: Lin Huang
> Signed-off-by: Enric Balletbo i Serra
> Signed-off-by: Gaël PORTAY
> ---
>
> Changes in v2:
> - [PATCH 8/8] Move center-supply attribute of dmc node in file
> rk3399-gru-chromebook.dtsi (where ppvar_centerlogic is
> defined).
>
> Changes in v1: None
>
> .../dts/rockchip/rk3399-gru-chromebook.dtsi | 4
> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 20 +++
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
> 3 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> index 931640e9aed4..cfb81356c61e 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> @@ -400,3 +400,7 @@ ap_i2c_tp: {
> rockchip,pins = <0 8 RK_FUNC_GPIO _pull_none>;
> };
> };
> +
> + {
> + center-supply = <_centerlogic>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> index da03fa9c5662..d14dce679e7a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> @@ -289,6 +289,12 @@
> status = "okay";
> };
>
> +_opp_table {
> + opp04 {
> + opp-suspend;
> + };
> +};
> +
> /*
> * Set some suspend operating points to avoid OVP in suspend
> *
> @@ -368,6 +374,10 @@
> <2>;
> };
>
> +_subsystem {
> + devfreq = <>;
> +};
When I checked the rockchip_drm_drv.c on linux-next.git (20190320),
there are no any codes about this. Maybe it should be removed.
> +
> _phy {
> status = "okay";
> };
> @@ -489,6 +499,16 @@ ap_i2c_audio: {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + upthreshold = <25>;
> + downdifferential = <15>;
> +};
> +
> {
> /*
>* Signal integrity isn't great at 200 MHz and 150 MHz (DDR) gives the
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 8fe86a3e7658..010b3e5267a0 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -156,7 +156,7 @@
> };
> };
>
> - display-subsystem {
> + display_subsystem: display-subsystem {
> compatible = "rockchip,display-subsystem";
> ports = <_out>, <_out>;
> };
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 2/2] extcon: mrfld: Introduce extcon driver for Basin Cove PMIC
Hi Andy,
On 19. 3. 18. 오후 9:46, Andy Shevchenko wrote:
> On Mon, Mar 18, 2019 at 07:38:26PM +0900, Chanwoo Choi wrote:
>
>> Thanks for comment. I add my comments
>> and then you have to rebase it on latest v5.0-rc1
>> because the merge conflict happen on v5.0-rc1.
>
> Thanks for review, see my answers below.
> Non-answered items will be fixed accordingly.
>
>>>> +config EXTCON_INTEL_MRFLD
>>>
>>>> + tristate "Intel MErrifield Basin Cove PMIC extcon driver"
>>>
>>> ME -> Me (will be fixed)
>>>
>>>> + depends on INTEL_SOC_PMIC_MRFLD
>>
>> This driver uses the regmap interface. So, you better to add
>> following dependency?
>
>> - select REGMAP_I2C or REGMAP_SPI
>
> None of them fits this or MFD driver. See below.
>
>> But, if 'INTEL_SOC_PMIC_MRFLE' selects already REGMAP_*
>> configuration. It is not necessary.
>
> https://lore.kernel.org/lkml/20190318095316.69278-1-andriy.shevche...@linux.intel.com/
>
> It selects REGMAP_IRQ which selects necessary bits from regmap API.
OK.
>
>>>> + help
>>>> +Say Y here to enable extcon support for charger detection / control
>>>> +on the Intel Merrifiel Basin Cove PMIC.
>>
>> What is correct word?
>> - Merrifield? is used on above
>> - Merrifiel?
>
> Merrifield is a correct one. Thanks for spotting this.
>
>>>> +static int mrfld_extcon_set(struct mrfld_extcon_data *data, unsigned int
>>>> reg,
>>>> + unsigned int mask)
>>>> +{
>>>> + return regmap_update_bits(data->regmap, reg, mask, 0xff);
>>>> +}
>>
>> mrfld_extcon_clear() and mrfld_extcon_set() are just wrapper function
>> for regmap interface. I think that you better to define
>> the meaningful defintion for '0x00' and '0xff' as following:
>>
>> (just example, you may make the more correct name)
>> #define INTEL_MRFLD_RESET0x00
>> #define INTEL_MRFLD_SET 0xff
>
> It makes a little sense here, the idea is to reduce parameters.
>
> I could ideally write
> (..., mask, ~mask) for clear
> and
> (..., mask, mask) for set
>
>> And then you better to use the 'regmap_update_bits()' function
>> directly instead of mrfld_extcon_clear/set'.
>
> It will bring duplication of long definitions and reduce readability of the
> code.
Actually, it is not critical issue. If you don't agree my comments,
you keep your style on next version. I have no any strong objection.
>
>>>> + /*
>>>> + * It seems SCU firmware clears the content of BCOVE_CHGRIRQ1
>>>> + * and makes it useless for OS. Instead we compare a previously
>>>> + * stored status to the current one, provided by BCOVE_SCHGRIRQ1.
>>>> + */
>>>> + ret = regmap_read(regmap, BCOVE_SCHGRIRQ1, );
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (!(status ^ data->status))
>>>> + return -ENODATA;
>>>> +
>>>> + if ((status ^ data->status) & BCOVE_CHGRIRQ_USBIDDET)
>>>> + ret = mrfld_extcon_role_detect(data);
>> This line gets the return value from mrfld_extcon_role_detect(data)
>> without any error handling and then the below line just saves 'status'
>> to 'data->status' regardless of 'ret' value.
>>
>> I think that you have to handle the error case of
>> 'ret = mrfld_extcon_role_detect(data)'.
>
> I'm not sure of the consequences of such change.
> I will give it some tests, and then will proceed accordingly.
OK. Thanks.
>
>>>> + .name = KBUILD_MODNAME,
>>
>> Where is the definition of KBUILD_MODNAME? Are you missing?
>
> In the Makefile.
> Nothing is missed here.
>
> But I could put its content explicitly here.
OK. Thanks.
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] extcon: fix a missing check of regmap_read
Hi,
On 19. 3. 19. 오전 1:41, Kangjie Lu wrote:
> When regmap_read fails, it doesn't make sense to use the read
> value "val" because it can be uninitialized.
>
> The fix returns if regmap_read fails.
>
> Signed-off-by: Kangjie Lu
> ---
> drivers/extcon/extcon-axp288.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
> index a983708b77a6..b2ba5f073aa7 100644
> --- a/drivers/extcon/extcon-axp288.c
> +++ b/drivers/extcon/extcon-axp288.c
> @@ -143,6 +143,10 @@ static void axp288_extcon_log_rsi(struct
> axp288_extcon_info *info)
> int ret;
>
> ret = regmap_read(info->regmap, AXP288_PS_BOOT_REASON_REG, );
> + if (ret) {
> + dev_dbg(info->dev, "regmap_read error %d\n", ret);
dev_err is correct for handling the error case
instead of dev_dbg. And I recommend that you use following error log
because extcon-axp288.c already used the 'failed to ...' log style.
If there is no special reason, you better to keep the consistency
for the readability.
- dev_err(info->dev, "failed to read BOOT_REASON_REG: %d\n", ret);
> + return;
> + }
> for (i = 0, rsi = axp288_pwr_up_down_info; *rsi; rsi++, i++) {
> if (val & BIT(i)) {
> dev_dbg(info->dev, "%s\n", *rsi);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 2/2] extcon: mrfld: Introduce extcon driver for Basin Cove PMIC
Hi Andy, On 19. 3. 18. 오후 7:38, Chanwoo Choi wrote: > Hi Andy, > > Thanks for comment. I add my comments > and then you have to rebase it on latest v5.0-rc1 > because the merge conflict happen on v5.0-rc1. Please rebase the extcon-next branch instead of v5.0-rc1. > > On 19. 3. 18. 오후 7:11, Andy Shevchenko wrote: >> On Mon, Mar 18, 2019 at 12:52:25PM +0300, Andy Shevchenko wrote: >>> TBD >> >> Oops. >> I though I have written it already. >> >> I will wait for other comments today and sent a new version with commit >> message >> filled as follows: >> >> On Intel Merrifield the Basin Cove PMIC provides a feature to detect >> the USB connection type. This driver utilizes the feature in order to support >> the USB dual role detection. >> >>> >>> Signed-off-by: Andy Shevchenko >>> --- >>> drivers/extcon/Kconfig | 7 + >>> drivers/extcon/Makefile | 1 + >>> drivers/extcon/extcon-intel-mrfld.c | 256 >>> 3 files changed, 264 insertions(+) >>> create mode 100644 drivers/extcon/extcon-intel-mrfld.c >>> >>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig >>> index 8e17149655f0..75349c6cc89e 100644 >>> --- a/drivers/extcon/Kconfig >>> +++ b/drivers/extcon/Kconfig >>> @@ -60,6 +60,13 @@ config EXTCON_INTEL_CHT_WC >>> Say Y here to enable extcon support for charger detection / control >>> on the Intel Cherrytrail Whiskey Cove PMIC. >>> >>> +config EXTCON_INTEL_MRFLD >> >>> + tristate "Intel MErrifield Basin Cove PMIC extcon driver" >> >> ME -> Me (will be fixed) >> >>> + depends on INTEL_SOC_PMIC_MRFLD > > This driver uses the regmap interface. So, you better to add > following dependency? > - select REGMAP_I2C or REGMAP_SPI > > But, if 'INTEL_SOC_PMIC_MRFLE' selects already REGMAP_* > configuration. It is not necessary. > >>> + help >>> + Say Y here to enable extcon support for charger detection / control >>> + on the Intel Merrifiel Basin Cove PMIC. > > What is correct word? > - Merrifield? is used on above > - Merrifiel? > > >>> + >>> config EXTCON_MAX14577 >>> tristate "Maxim MAX14577/77836 EXTCON Support" >>> depends on MFD_MAX14577 >>> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile >>> index 261ce4cfe209..d3941a735df3 100644 >>> --- a/drivers/extcon/Makefile >>> +++ b/drivers/extcon/Makefile >>> @@ -11,6 +11,7 @@ obj-$(CONFIG_EXTCON_AXP288) += extcon-axp288.o >>> obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o >>> obj-$(CONFIG_EXTCON_INTEL_INT3496) += extcon-intel-int3496.o >>> obj-$(CONFIG_EXTCON_INTEL_CHT_WC) += extcon-intel-cht-wc.o >>> +obj-$(CONFIG_EXTCON_INTEL_MRFLD) += extcon-intel-mrfld.o >>> obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o >>> obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o >>> obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o >>> diff --git a/drivers/extcon/extcon-intel-mrfld.c >>> b/drivers/extcon/extcon-intel-mrfld.c >>> new file mode 100644 >>> index ..d45db4975b5f >>> --- /dev/null >>> +++ b/drivers/extcon/extcon-intel-mrfld.c >>> @@ -0,0 +1,256 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Extcon driver for Basin Cove PMIC >>> + * >>> + * Copyright (c) 2018, Intel Corporation. >> >> 2019 I suppose :-) > > Right. > >> >>> + * Author: Andy Shevchenko >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include "extcon-intel.h" >>> + >>> +#define BCOVE_USBIDCTRL0x19 >>> +#define BCOVE_USBIDCTRL_ID BIT(0) >>> +#define BCOVE_USBIDCTRL_ACABIT(1) >>> +#define BCOVE_USBIDCTRL_ALL(BCOVE_USBIDCTRL_ID | >>> BCOVE_USBIDCTRL_ACA) >>> + >>> +#define BCOVE_USBIDSTS 0x1a >>> +#define BCOVE_USBIDSTS_GND BIT(0) >>> +#define BCOVE_USBIDSTS_RARBRC_MASK GENMASK(2, 1) >>> +#define BCOVE_USBIDSTS_RARBRC_SHIFT1 >>> +#define BCOVE_USBIDSTS_NO_ACA 0 >>> +#define BCOVE_USBIDSTS_R_ID_A 1 >>>
Re: [PATCH 2/2] extcon: Add fsa9480 extcon driver
s first */
> + fsa9480_handle_change(usbsw, usbsw->dev & ~val, false);
> +
> + /* then handle attached ones */
> + fsa9480_handle_change(usbsw, val & ~usbsw->dev, true);
> +
> + usbsw->dev = val;
> +}
> +
> +static irqreturn_t fsa9480_irq_handler(int irq, void *data)
> +{
> + struct fsa9480_usbsw *usbsw = data;
> + struct i2c_client *client = usbsw->client;
> + int intr = 0;
> +
> + /* clear interrupt */
> + fsa9480_read_irq(client, );
> + if (!intr)
> + return IRQ_NONE;
> +
> + /* device detection */
> + fsa9480_detect_dev(usbsw);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int fsa9480_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct fsa9480_usbsw *info;
> + int ret;
> +
> + if (!client->irq) {
> + dev_err(>dev, "no interrupt provided\n");
> + return -EINVAL;
> + }
> +
> + info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> + info->client = client;
> +
> + i2c_set_clientdata(client, info);
> +
> + /* External connector */
> + info->edev = devm_extcon_dev_allocate(>dev,
> + fsa9480_extcon_cable);
> + if (IS_ERR(info->edev)) {
> + dev_err(>dev, "failed to allocate memory for extcon\n");
> + ret = -ENOMEM;
> + return ret;
> + }
> +
> + ret = devm_extcon_dev_register(>dev, info->edev);
> + if (ret) {
> + dev_err(>dev, "failed to register extcon device\n");
> + return ret;
> + }
> +
> + /* ADC Detect Time: 500ms */
> + fsa9480_write_reg(client, FSA9480_REG_TIMING1, TIMING1_ADC_500MS);
> +
> + /* configure automatic switching */
> + fsa9480_write_reg(client, FSA9480_REG_CTRL, CON_MASK);
> +
> + /* unmask interrupt (attach/detach only) */
> + fsa9480_write_reg(client, FSA9480_REG_INT1_MASK,
> + INT1_MASK & ~(INT_ATTACH | INT_DETACH));
> + fsa9480_write_reg(client, FSA9480_REG_INT2_MASK, INT2_MASK);
> +
> + ret = devm_request_threaded_irq(>dev, client->irq, NULL,
> + fsa9480_irq_handler,
> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> + "fsa9480", info);
> + if (ret) {
> + dev_err(>dev, "failed to request IRQ\n");
> + return ret;
> + }
> +
> + device_init_wakeup(>dev, true);
> + fsa9480_detect_dev(info);
> +
> + ret = sysfs_create_group(>dev.kobj, _group);
Please remove it.
> + if (ret) {
> + dev_err(>dev,
> + "failed to create fsa9480 attribute group\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int fsa9480_remove(struct i2c_client *client)
> +{
> + sysfs_remove_group(>dev.kobj, _group);
Please remove it.
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int fsa9480_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> +
> + if (device_may_wakeup(>dev) && client->irq)
> + enable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +
> +static int fsa9480_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> +
> + if (device_may_wakeup(>dev) && client->irq)
> + disable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops fsa9480_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(fsa9480_suspend, fsa9480_resume)
> +};
> +
> +static const struct i2c_device_id fsa9480_id[] = {
> + { "fsa9480", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, fsa9480_id);
> +
> +static const struct of_device_id fsa9480_of_match[] = {
> + { .compatible = "fcs,fsa9480", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, fsa9480_of_match);
> +
> +static struct i2c_driver fsa9480_i2c_driver = {
> + .driver = {
> + .name = "fsa9480",
> + .pm = _pm_ops,
> + .of_match_table = fsa9480_of_match,
> + },
> + .probe = fsa9480_probe,
> + .remove = fsa9480_remove,
> + .id_table = fsa9480_id,
> +};
> +
> +static int __init fsa9480_module_init(void)
> +{
> + return i2c_add_driver(_i2c_driver);
> +}
> +subsys_initcall(fsa9480_module_init);
> +
> +static void __exit fsa9480_module_exit(void)
> +{
> + i2c_del_driver(_i2c_driver);
> +}
> +module_exit(fsa9480_module_exit);
> +
> +MODULE_DESCRIPTION("Fairchild Semiconductor FSA9480 extcon driver");
> +MODULE_AUTHOR("Tomasz Figa ");
> +MODULE_LICENSE("GPL");
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 1/2] dt-bindings: extcon: Add support for fsa9480 switch
Hi,
Sorry for late reply.
On 19. 2. 26. 오전 1:58, Paweł Chmiel wrote:
> From: Tomasz Figa
>
> This patch adds documentation for binding of extcont Fairchild
> Semiconductor FSA9480 microusb switch.
> This usb port accessory detector and switch, can be found for example in
> some Samsung s5pv210 based phones.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Paweł Chmiel
> ---
> .../bindings/extcon/extcon-fsa9480.txt| 21 +++
> 1 file changed, 21 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> new file mode 100644
> index ..ebced7b18eb5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt
> @@ -0,0 +1,21 @@
> +FAIRCHILD SEMICONDUCTOR FSA9480 MICROUSB SWITCH
> +
> +The FSA9480 is a USB port accessory detector and switch. The FSA9480 is fully
> +controlled using I2C and enables USB data, stereo and mono audio, video,
> +microphone, and UART data to use a common connector port.
> +
> +Required properties:
> + - compatible : Must be "fcs,fsa9480"
> + - reg : Specifies i2c slave address. Must be 0x25.
> + - interrupt-parent : Phandle to interrupt controller to which interrupt
> + signal of the chip is connected.
> + - interrupts : Should contain one entry specifying interrupt signal of
> + interrupt parent to which interrupt pin of the chip is connected.
> +
> + Example:
> + musb@25 {
> + compatible = "fcs,fsa9480";
> + reg = <0x25>;
> + interrupt-parent = <>;
> + interrupts = <7 0>;
> + };
> \ No newline at end of file
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 2/2] extcon: mrfld: Introduce extcon driver for Basin Cove PMIC
low line just saves 'status'
to 'data->status' regardless of 'ret' value.
I think that you have to handle the error case of
'ret = mrfld_extcon_role_detect(data)'.
>> +
>> +data->status = status;
nitpick. better to add one blank line.
>> +return ret;
>> +}
>> +
>> +static irqreturn_t mrfld_extcon_interrupt(int irq, void *dev_id)
>> +{
>> +struct mrfld_extcon_data *data = dev_id;
>> +int ret;
>> +
>> +ret = mrfld_extcon_cable_detect(data);
>> +
>> +mrfld_extcon_clear(data, BCOVE_MIRQLVL1, BCOVE_LVL1_CHGR);
>> +
>> +return ret ? IRQ_NONE: IRQ_HANDLED;
>> +}
>> +
>> +static int mrfld_extcon_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct intel_soc_pmic *pmic = dev_get_drvdata(dev->parent);
>> +struct regmap *regmap = pmic->regmap;
>> +struct mrfld_extcon_data *data;
>> +unsigned int id;
>> +int irq, ret;
>> +
>> +irq = platform_get_irq(pdev, 0);
>> +if (irq < 0)
>> +return irq;
>> +
>> +data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>> +if (!data)
>> +return -ENOMEM;
>> +
>> +data->dev = dev;
>> +data->regmap = regmap;
>> +
>> +data->edev = devm_extcon_dev_allocate(dev, mrfld_extcon_cable);
>> +if (IS_ERR(data->edev))
>> +return -ENOMEM;
>> +
>> +ret = devm_extcon_dev_register(dev, data->edev);
>> +if (ret < 0) {
>> +dev_err(dev, "can't register extcon device: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +ret = devm_request_threaded_irq(dev, irq, NULL, mrfld_extcon_interrupt,
>> +IRQF_ONESHOT | IRQF_SHARED, pdev->name,
>> +data);
>> +if (ret)
>> +return ret;
You better add the error log with dev_err.
>> +
>> +ret = regmap_read(regmap, BCOVE_ID, );
>> +if (ret)
>> +return ret;
ditto for error log.
>> +
>> +data->id = id;
>> +
>> +mrfld_extcon_set(data, BCOVE_CHGRCTRL0, BCOVE_CHGRCTRL0_SWCONTROL);
>> +
>> +/* Get initial state */
>> +mrfld_extcon_role_detect(data);
Please handle the return value for exception handling with log.
>> +
>> +mrfld_extcon_clear(data, BCOVE_MIRQLVL1, BCOVE_LVL1_CHGR);
>> +mrfld_extcon_clear(data, BCOVE_MCHGRIRQ1, BCOVE_CHGRIRQ_ALL);
>> +
>> +mrfld_extcon_set(data, BCOVE_USBIDCTRL, BCOVE_USBIDCTRL_ALL);
>> +
>> +platform_set_drvdata(pdev, data);
nitpick. better to add one blank line.
>> +return 0;
>> +}
>> +
>> +static int mrfld_extcon_remove(struct platform_device *pdev)
>> +{
>> +struct mrfld_extcon_data *data = platform_get_drvdata(pdev);
>> +
>> +mrfld_extcon_clear(data, BCOVE_CHGRCTRL0, BCOVE_CHGRCTRL0_SWCONTROL);
nitpick. better to add one blank line.
>> +return 0;
>> +}
>> +
>> +static const struct platform_device_id mrfld_extcon_id_table[] = {
>> +{ .name = "mrfld_bcove_extcon" },
I think that it is not proper to use 'extcon' word for the compatible name
because 'extcon' word is linuxium. So, I recommend that you remove
the 'extcon' word. Instead, you better to use new word related to h/w.
>> +{}
>> +};
>> +MODULE_DEVICE_TABLE(platform, mrfld_extcon_id_table);
>> +
>> +static struct platform_driver mrfld_extcon_driver = {
>> +.driver = {
>> +.name = KBUILD_MODNAME,
Where is the definition of KBUILD_MODNAME? Are you missing?
>> +},
>> +.probe = mrfld_extcon_probe,
>> +.remove = mrfld_extcon_remove,
>> +.id_table = mrfld_extcon_id_table,
>> +};
>> +module_platform_driver(mrfld_extcon_driver);
>> +
>> +MODULE_AUTHOR("Andy Shevchenko ");
>> +MODULE_DESCRIPTION("Extcon driver for Basin Cove PMIC");
Add the 'Merrifield' word in front of 'Basin Cove PMIC' as following:
- Merrifield Basic Cove PMIC
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.20.1
>>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 1/2] extcon: intel: Split out some definitions to a common header
Hi,
Looks good to me. But just there is minor one comment as following:
- 2018 -> 2019
On 19. 3. 18. 오후 6:52, Andy Shevchenko wrote:
> We are going to use some definitions in the other Intel extcon drivers,
> thus, split out them to a common header file.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/extcon/extcon-intel-cht-wc.c | 21 +++--
> drivers/extcon/extcon-intel.h| 20
> 2 files changed, 27 insertions(+), 14 deletions(-)
> create mode 100644 drivers/extcon/extcon-intel.h
>
> diff --git a/drivers/extcon/extcon-intel-cht-wc.c
> b/drivers/extcon/extcon-intel-cht-wc.c
> index 5ef215297101..110bd38a4d24 100644
> --- a/drivers/extcon/extcon-intel-cht-wc.c
> +++ b/drivers/extcon/extcon-intel-cht-wc.c
> @@ -17,6 +17,8 @@
> #include
> #include
>
> +#include "extcon-intel.h"
> +
> #define CHT_WC_PHYCTRL 0x5e07
>
> #define CHT_WC_CHGRCTRL0 0x5e16
> @@ -65,15 +67,6 @@
> #define CHT_WC_VBUS_GPIO_CTLO_DRV_OD BIT(4)
> #define CHT_WC_VBUS_GPIO_CTLO_DIR_OUTBIT(5)
>
> -enum cht_wc_usb_id {
> - USB_ID_OTG,
> - USB_ID_GND,
> - USB_ID_FLOAT,
> - USB_RID_A,
> - USB_RID_B,
> - USB_RID_C,
> -};
> -
> enum cht_wc_mux_select {
> MUX_SEL_PMIC = 0,
> MUX_SEL_SOC,
> @@ -101,9 +94,9 @@ static int cht_wc_extcon_get_id(struct cht_wc_extcon_data
> *ext, int pwrsrc_sts)
> {
> switch ((pwrsrc_sts & CHT_WC_PWRSRC_USBID_MASK) >>
> CHT_WC_PWRSRC_USBID_SHIFT) {
> case CHT_WC_PWRSRC_RID_GND:
> - return USB_ID_GND;
> + return INTEL_USB_ID_GND;
> case CHT_WC_PWRSRC_RID_FLOAT:
> - return USB_ID_FLOAT;
> + return INTEL_USB_ID_FLOAT;
> case CHT_WC_PWRSRC_RID_ACA:
> default:
> /*
> @@ -111,7 +104,7 @@ static int cht_wc_extcon_get_id(struct cht_wc_extcon_data
> *ext, int pwrsrc_sts)
>* the USBID GPADC channel here and determine ACA role
>* based on that.
>*/
> - return USB_ID_FLOAT;
> + return INTEL_USB_ID_FLOAT;
> }
> }
>
> @@ -221,7 +214,7 @@ static void cht_wc_extcon_pwrsrc_event(struct
> cht_wc_extcon_data *ext)
> }
>
> id = cht_wc_extcon_get_id(ext, pwrsrc_sts);
> - if (id == USB_ID_GND) {
> + if (id == INTEL_USB_ID_GND) {
> /* The 5v boost causes a false VBUS / SDP detect, skip */
> goto charger_det_done;
> }
> @@ -248,7 +241,7 @@ static void cht_wc_extcon_pwrsrc_event(struct
> cht_wc_extcon_data *ext)
> ext->previous_cable = cable;
> }
>
> - ext->usb_host = ((id == USB_ID_GND) || (id == USB_RID_A));
> + ext->usb_host = ((id == INTEL_USB_ID_GND) || (id == INTEL_USB_RID_A));
> extcon_set_state_sync(ext->edev, EXTCON_USB_HOST, ext->usb_host);
> }
>
> diff --git a/drivers/extcon/extcon-intel.h b/drivers/extcon/extcon-intel.h
> new file mode 100644
> index ..455986b2b004
> --- /dev/null
> +++ b/drivers/extcon/extcon-intel.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Header file for Intel extcon hardware
> + *
> + * Copyright (C) 2018 Intel Corporation. All rights reserved.
2018 -> 2019
> + */
> +
> +#ifndef __EXTCON_INTEL_H__
> +#define __EXTCON_INTEL_H__
> +
> +enum extcon_intel_usb_id {
> + INTEL_USB_ID_OTG,
> + INTEL_USB_ID_GND,
> + INTEL_USB_ID_FLOAT,
> + INTEL_USB_RID_A,
> + INTEL_USB_RID_B,
> + INTEL_USB_RID_C,
> +};
> +
> +#endif /* __EXTCON_INTEL_H__ */
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] devfreq: Suspend all devices on system shutdown
Hi Pavel, On 19. 3. 7. 오전 8:10, Pavel Machek wrote: > On Fri 2019-01-25 14:54:03, Marek Szyprowski wrote: >> This way devfreq core ensures that all its devices will be set to safe >> operation points before reboot operation. There are board on which some >> aggressive power saving operation points are behind the capabilities of >> the bootloader to properly reset the hardware and boot the board. This >> way one can avoid board crash early after reboot. >> >> Similar pattern is used in CPUfreq subsystem. > > This looks somehow dangerous to me. I guess this will break someone's > shutdown, and on battery-powered devices, that's quite bad thing to > do. This patch executes the devfreq_suspend() for all devfreq devices. The devfreq_suspend() does the following: 1. (mandatory) stop the polling of governor. 2. (optional) If devfreq device specifies the 'opp-suspend' property in DT, the devfreq changes the frequency by using the devfreq->suspend_freq. If the user of devfreq device doesn't want to change the frequency during the system shutdown, just don't add the 'opp-suspend' property in DT. And the devfreq_suspend() will just stop the polling for governor. Even if on battery-powered devices, I think it is not problem to stop the polling of governor during the system shutdown. In my case, I don't know what is dangerous. Could you explain it more detailed. > > Could we explicitely do it only for devices that need it? > Pavel > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v4 4/8] drivers: devfreq: add DMC driver for Exynos5422
Hi Sylwester,
On 19. 3. 6. 오후 10:44, Sylwester Nawrocki wrote:
> Hi,
>
> On 2/3/19 13:23, Chanwoo Choi wrote:
>
>> 2019년 2월 2일 (토) 오전 2:42, Lukasz Luba 님이 작성:
>
>>> +/**
>>> + * exynos5_dmc_pause_on_switching() - Controls a pause feature in DMC
>>> + * @dmc: device which is used for changing this feature
>>> + * @set: a boolean state passing enable/disable request
>>> + *
>>> + * There is a need of pausing DREX DMC when divider or MUX in clock tree
>>> + * changes its configuration. In such situation access to the memory is
>>> blocked
>>> + * in DMC automatically. This feature is used when clock frequency change
>>> + * request appears and touches clock tree.
>>> + */
>>> +static int exynos5_dmc_pause_on_switching(struct exynos5_dmc *dmc, bool
>>> set)
>>
>> Don't need to make it as the separate function. It is only used on
>> probe() function.
>
> It seems fine to me to have this functionality in a separate function,
> it's self-contained and it's now pretty well documented.
>
>>> +{
>>> + unsigned int val;
>>> +
>>> + val = readl(dmc->base_clk + DMC_PAUSE_CTRL);
>>> + if (set)
>>> + val |= DMC_PAUSE_ENABLE;
>>> + else
>>> + val &= ~DMC_PAUSE_ENABLE;
>>> + writel(val, dmc->base_clk + DMC_PAUSE_CTRL);
>>
>> The dt-binding file doesn't explain the 'reg' property for 'base_clk'.
>> You are missing.
>> When I tried to find what are the base address, it is the register map
>> of clock-controller.
>> This driver accesed the register of clock controller without any
>> functions of CCF
>> (common clock framework). It is wrong.
>>
>> If you need to get the some information of clock, must have to use the CCF.
> We talked a little about this issue with Lukasz in person and it looks
> like there are some DMC related registers in the clock controller register
> region, I'd say those registers are better handled by the DMC driver rather
> than the clocks controller driver. Moreover, we should avoid abusing clk API
> for not strictly clocks related functionality as it appears to be above.
> It might be more appropriate to add in the dmc DT node a phandle to a regmap
> exposed by the clock-controller node. It seems there will be even no single
> register that would be shared between the DMC and the clock controller.
>
I agree to share the regmap instance of clock controller
with syscon_regmap_lookup_by_phandle() and then add the detailed
description about this to dt-binding documentation.
And,
This patch has the another quetion about the clocks in
exynos5_dmc_init_clks(). This functions used 'clk_set_parent'
to make the hierarchy between clocks. I think it is possible to make
the relation of clocks in DT by using the 'assigned-clocks'.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] extcon-ptn5150: fix COMPILE_TEST dependencies
Hi,
On 19. 3. 6. 오후 8:08, Arnd Bergmann wrote:
> The PTN5150 dependencies look like they were meant to do the
> right thing, but they actually should not allow building without
> I2C for compile testing, as that results in a Kconfig warning
> and subsequent build failure:
>
> WARNING: unmet direct dependencies detected for REGMAP_I2C
> Depends on [m]: I2C [=m]
> Selected by [y]:
> - EXTCON_PTN5150 [=y] && EXTCON [=y] && (I2C [=m] && GPIOLIB [=y] ||
> COMPILE_TEST [=y])
> Selected by [m]:
> - EEPROM_AT24 [=m] && I2C [=m] && SYSFS [=y]
> - KEYBOARD_CAP11XX [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && OF
> [=y] && I2C [=m]
> - INPUT_DRV260X_HAPTICS [=m] && !UML && INPUT_MISC [=y] && INPUT [=y] &&
> I2C [=m] && (GPIOLIB [=y] || COMPILE_TEST [=y])
> - ... [many others]
>
> Add parentheses around the expression so we can compile-test
> without GPIOLIB but not without I2C.
>
> Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/extcon/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 8e17149655f0..540e8cd16ee6 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -116,7 +116,7 @@ config EXTCON_PALMAS
>
> config EXTCON_PTN5150
> tristate "NXP PTN5150 CC LOGIC USB EXTCON support"
> - depends on I2C && GPIOLIB || COMPILE_TEST
> + depends on I2C && (GPIOLIB || COMPILE_TEST)
> select REGMAP_I2C
> help
> Say Y here to enable support for USB peripheral and USB host
>
Applied it to extcon-fixes branch for v5.0-rc2.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] extcon-ptn5150: fix COMPILE_TEST dependencies
Hi Randy,
On 19. 3. 7. 오전 12:49, Randy Dunlap wrote:
> On 3/6/19 3:08 AM, Arnd Bergmann wrote:
>> The PTN5150 dependencies look like they were meant to do the
>> right thing, but they actually should not allow building without
>> I2C for compile testing, as that results in a Kconfig warning
>> and subsequent build failure:
>>
>> WARNING: unmet direct dependencies detected for REGMAP_I2C
>> Depends on [m]: I2C [=m]
>> Selected by [y]:
>> - EXTCON_PTN5150 [=y] && EXTCON [=y] && (I2C [=m] && GPIOLIB [=y] ||
>> COMPILE_TEST [=y])
>> Selected by [m]:
>> - EEPROM_AT24 [=m] && I2C [=m] && SYSFS [=y]
>> - KEYBOARD_CAP11XX [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && OF
>> [=y] && I2C [=m]
>> - INPUT_DRV260X_HAPTICS [=m] && !UML && INPUT_MISC [=y] && INPUT [=y] &&
>> I2C [=m] && (GPIOLIB [=y] || COMPILE_TEST [=y])
>> - ... [many others]
>>
>> Add parentheses around the expression so we can compile-test
>> without GPIOLIB but not without I2C.
>>
>> Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver")
>> Signed-off-by: Arnd Bergmann
>
> Hi Chanwoo,
>
> You might want to drop my patch and use this one from Arnd instead...
Thanks for your comment. I'll do that.
>
>
>> ---
>> drivers/extcon/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>> index 8e17149655f0..540e8cd16ee6 100644
>> --- a/drivers/extcon/Kconfig
>> +++ b/drivers/extcon/Kconfig
>> @@ -116,7 +116,7 @@ config EXTCON_PALMAS
>>
>> config EXTCON_PTN5150
>> tristate "NXP PTN5150 CC LOGIC USB EXTCON support"
>> -depends on I2C && GPIOLIB || COMPILE_TEST
>> +depends on I2C && (GPIOLIB || COMPILE_TEST)
>> select REGMAP_I2C
>> help
>>Say Y here to enable support for USB peripheral and USB host
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v5 2/8] clk: samsung: add new clocks for DMC for Exynos5422 SoC
mout_mx_mspll_ccore_p, SRC_TOP7, 16, 2),
> + mout_mx_mspll_ccore_p, SRC_TOP7, 16, 3),
> MUX_F(CLK_MOUT_MAU_EPLL, "mout_mau_epll_clk", mout_mau_epll_clk_5800_p,
> SRC_TOP7, 20, 2, CLK_SET_RATE_PARENT, 0),
> - MUX(0, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
> + MUX(CLK_SCLK_BPLL, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
> MUX(0, "mout_epll2", mout_epll2_5800_p, SRC_TOP7, 28, 1),
>
> MUX(0, "mout_aclk550_cam", mout_group3_5800_p, SRC_TOP8, 16, 3),
> @@ -648,7 +662,7 @@ static const struct samsung_mux_clock exynos5x_mux_clks[]
> __initconst = {
>
> MUX(0, "mout_sclk_mpll", mout_mpll_p, SRC_TOP6, 0, 1),
> MUX(CLK_MOUT_VPLL, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1),
> - MUX(0, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
> + MUX(CLK_MOUT_SCLK_SPLL, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
> MUX(0, "mout_sclk_ipll", mout_ipll_p, SRC_TOP6, 12, 1),
> MUX(0, "mout_sclk_rpll", mout_rpll_p, SRC_TOP6, 16, 1),
> MUX_F(CLK_MOUT_EPLL, "mout_sclk_epll", mout_epll_p, SRC_TOP6, 20, 1,
> @@ -817,6 +831,8 @@ static const struct samsung_div_clock exynos5x_div_clks[]
> __initconst = {
> DIV(CLK_DOUT_CLK2X_PHY0, "dout_clk2x_phy0", "dout_sclk_cdrex",
> DIV_CDREX0, 3, 5),
>
> + DIV(0, "dout_pclk_drex0", "dout_cclk_drex0", DIV_CDREX0, 28, 3),
> +
> DIV(CLK_DOUT_PCLK_CORE_MEM, "dout_pclk_core_mem", "mout_mclk_cdrex",
> DIV_CDREX1, 8, 3),
>
> @@ -1170,6 +1186,36 @@ static const struct samsung_gate_clock
> exynos5x_gate_clks[] __initconst = {
> GATE_TOP_SCLK_ISP, 12, CLK_SET_RATE_PARENT, 0),
>
> GATE(CLK_G3D, "g3d", "mout_user_aclk_g3d", GATE_IP_G3D, 9, 0, 0),
> +
> + /* CDREX */
> + GATE(CLK_CLKM_PHY0, "clkm_phy0", "dout_sclk_cdrex",
> + GATE_BUS_CDREX0, 0, 0, 0),
> + GATE(CLK_CLKM_PHY1, "clkm_phy1", "dout_sclk_cdrex",
> + GATE_BUS_CDREX0, 1, 0, 0),
nitpick. Add the blank line because of clocks of the different register.
> + GATE(0, "mx_mspll_ccore_phy", "mout_mx_mspll_ccore_phy",
> + SRC_MASK_TOP7, 0, CLK_IGNORE_UNUSED, 0),
> +
> + GATE(CLK_ACLK_PPMU_DREX1_1, "aclk_ppmu_drex1_1", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 12, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_ACLK_PPMU_DREX1_0, "aclk_ppmu_drex1_0", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 13, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_ACLK_PPMU_DREX0_1, "aclk_ppmu_drex0_1", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 14, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_ACLK_PPMU_DREX0_0, "aclk_ppmu_drex0_0", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 15, CLK_IGNORE_UNUSED, 0),
> +
> + GATE(CLK_PCLK_PPMU_DREX1_1, "pclk_ppmu_drex1_1", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 26, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_PCLK_PPMU_DREX1_0, "pclk_ppmu_drex1_0", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 27, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_PCLK_PPMU_DREX0_1, "pclk_ppmu_drex0_1", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 28, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_PCLK_PPMU_DREX0_0, "pclk_ppmu_drex0_0", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 29, CLK_IGNORE_UNUSED, 0),
> +
> + GATE(CLK_CDREX_PAUSE, "clk_cdrex_pause", NULL, CDREX_PAUSE, 0, 0, 0),
nitpick. Add the blank line because of clocks of the different register.
> + GATE(CLK_CDREX_TIMING_SET, "clk_cdrex_timing_set", NULL,
> + CDREX_LPDDR3PHY_CON3, 28, 0, 0),
> };
>
> static const struct samsung_div_clock exynos5x_disp_div_clks[] __initconst =
> {
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v5 5/8] drivers: devfreq: add DMC driver for Exynos5422
t;mout_mclk_cdrex");
> + if (IS_ERR(dmc->mout_mclk_cdrex))
> + return PTR_ERR(dmc->mout_mclk_cdrex);
> +
> + dmc->mout_bpll = devm_clk_get(dev, "mout_bpll");
> + if (IS_ERR(dmc->mout_bpll))
> + return PTR_ERR(dmc->mout_bpll);
> +
> + dmc->mout_mx_mspll_ccore = devm_clk_get(dev, "mout_mx_mspll_ccore");
> + if (IS_ERR(dmc->mout_mx_mspll_ccore))
> + return PTR_ERR(dmc->mout_mx_mspll_ccore);
> +
> + dmc->dout_clk2x_phy0 = devm_clk_get(dev, "dout_clk2x_phy0");
> + if (IS_ERR(dmc->dout_clk2x_phy0))
> + return PTR_ERR(dmc->dout_clk2x_phy0);
> +
> + dmc->mout_spll = devm_clk_get(dev, "ff_dout_spll2");
> + if (IS_ERR(dmc->mout_spll))
> + return PTR_ERR(dmc->mout_spll);
> +
> + dmc->cdrex_pause = devm_clk_get(dev, "clk_cdrex_pause");
> + if (IS_ERR(dmc->cdrex_pause))
> + return PTR_ERR(dmc->cdrex_pause);
> +
> + dmc->timing_set = devm_clk_get(dev, "clk_cdrex_timing_set");
> + if (IS_ERR(dmc->timing_set))
> + return PTR_ERR(dmc->timing_set);
> + /*
> + * Convert frequency to KHz values and set it for the governor.
> + */
> + dmc->curr_rate = clk_get_rate(dmc->mout_mclk_cdrex);
> + dmc->curr_rate = exynos5_dmc_align_init_freq(dmc, dmc->curr_rate);
> + exynos5_dmc_df_profile.initial_freq = dmc->curr_rate;
> +
> + ret = exynos5_dmc_get_volt_freq(dev, >curr_rate, _rate,
> + _volt, 0);
> + if (ret)
> + return ret;
> +
> + dmc->curr_volt = target_volt;
> +
> + clk_prepare_enable(dmc->mout_spll);
> + clk_set_parent(dmc->mout_mx_mspll_ccore, dmc->mout_spll);
> + clk_prepare_enable(dmc->mout_mx_mspll_ccore);
> +
> + clk_prepare_enable(dmc->fout_bpll);
> + clk_prepare_enable(dmc->mout_bpll);
> +
> + clk_prepare_enable(dmc->cdrex_pause);
> + clk_prepare(dmc->timing_set);
> +
> + return 0;
> +}
> +
> +/**
> + * exynos5_performance_counters_init() - Initializes performance DMC's
> counters
> + * @dmc: DMC for which it does the setup
> + *
> + * Initialization of performance counters in DMC for estimating usage.
> + * The counter's values are used for calculation of a memory bandwidth and
> based
> + * on that the governor changes the frequency.
> + * The counters are not used when the governor is GOVERNOR_USERSPACE.
> + */
> +static int exynos5_performance_counters_init(struct exynos5_dmc *dmc)
> +{
> + int counters_size;
> + int ret, i;
> +
> + dmc->num_counters = devfreq_event_get_edev_count(dmc->dev);
> + if (dmc->num_counters < 0) {
> + dev_err(dmc->dev, "could not get devfreq-event counters\n");
> + return dmc->num_counters;
> + }
> +
> + counters_size = sizeof(struct devfreq_event_dev) * dmc->num_counters;
> + dmc->counter = devm_kzalloc(dmc->dev, counters_size, GFP_KERNEL);
> + if (!dmc->counter)
> + return -ENOMEM;
> +
> + for (i = 0; i < dmc->num_counters; i++) {
> + dmc->counter[i] =
> + devfreq_event_get_edev_by_phandle(dmc->dev, i);
> + if (IS_ERR_OR_NULL(dmc->counter[i]))
> + return -EPROBE_DEFER;
> + }
> +
> + ret = exynos5_counters_enable_edev(dmc);
> + if (ret < 0) {
> + dev_err(dmc->dev, "could not enable event counter\n");
> + return ret;
> + }
> +
> + ret = exynos5_counters_set_event(dmc);
> + if (ret < 0) {
> + dev_err(dmc->dev, "counld not set event counter\n");
> + return ret;
> + }
> +
> + mutex_lock(>lock);
> + dmc->counters_enabled = true;
> + mutex_unlock(>lock);
> +
> + return 0;
> +}
> +
> +/**
> + * exynos5_dmc_probe() - Probe function for the DMC driver
> + * @pdev:platform device for which the driver is going to be initialized
> + *
> + * Initialize basic components: clocks, regulators, performance counters,
> etc.
> + * Read out product version and based on the information setup
> + * internal structures for the controller (frequency and voltage) and for
> DRAM
> + * memory parameters: timings for each operating frequency.
> + * Register new devfreq device for controlling DVFS of the DMC.
> + */
> +static int exynos5_dmc_probe(struct platform_device *pdev)
> +{
> + int ret = 0;
> + struct exynos5_dmc *dmc;
> + struct device *dev = >dev;
> + struct resource *res;
> +
> + dmc = devm_kzalloc(dev, sizeof(*dmc), GFP_KERNEL);
> + if (!dmc)
> + return -ENOMEM;
> +
> + mutex_init(>lock);
> +
> + dmc->dev = dev;
> + platform_set_drvdata(pdev, dmc);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + dmc->base_drexi0 = devm_ioremap_resource(dev, res);
> + if (IS_ERR(dmc->base_drexi0))
> + return PTR_ERR(dmc->base_drexi0);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + dmc->base_drexi1 = devm_ioremap_resource(dev, res);
> + if (IS_ERR(dmc->base_drexi1))
> + return PTR_ERR(dmc->base_drexi1);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + dmc->chip_id = devm_ioremap_resource(dev, res);
> + if (IS_ERR(dmc->chip_id))
> + return PTR_ERR(dmc->chip_id);
> +
> + ret = exynos5_dmc_chip_revision_settings(dmc);
> + if (ret)
> + return ret;
> +
> + ret = exynos5_init_freq_table(dev, dmc, _dmc_df_profile);
> + if (ret)
> + return ret;
> +
> + ret = of_get_dram_timings(dmc);
> + if (ret)
> + return ret;
> +
> + dmc->vdd_mif = devm_regulator_get(dev, "vdd_mif");
> + if (IS_ERR(dmc->vdd_mif)) {
> + ret = PTR_ERR(dmc->vdd_mif);
> + dev_warn(dev, "couldn't get regulator\n");
> + return ret;
> + }
> +
> + ret = exynos5_dmc_init_clks(dev, dmc);
> + if (ret) {
> + dev_warn(dev, "couldn't initialize clocks\n");
> + return ret;
> + }
> +
> + ret = exynos5_performance_counters_init(dmc);
> + if (ret) {
> + dev_warn(dev, "couldn't probe performance counters\n");
> + goto remove_clocks;
> + }
> + /*
> + * Setup default thresholds for the devfreq governor.
> + * The values are chosen based on experiments.
> + */
> + dmc->gov_data.upthreshold = 30;
> + dmc->gov_data.downdifferential = 5;
> +
> + dmc->df = devm_devfreq_add_device(dev, _dmc_df_profile,
> + DEVFREQ_GOV_USERSPACE,
> + >gov_data);
> +
> + if (IS_ERR(dmc->df)) {
> + ret = PTR_ERR(dmc->df);
> + goto err_devfreq_add;
> + }
> +
> + dev_info(>dev, "DMC init for prod_id=0x%08x pkg_id=0x%08x\n",
> + dmc->prod_rev, dmc->pkg_rev);
> +
> + return 0;
> +
> +err_devfreq_add:
> + exynos5_counters_disable_edev(dmc);
> +remove_clocks:
> + clk_disable_unprepare(dmc->mout_mx_mspll_ccore);
> + clk_disable_unprepare(dmc->mout_spll);
> +
> + return ret;
> +}
> +
> +/**
> + * exynos5_dmc_remove() - Remove function for the platform device
> + * @pdev:platform device which is going to be removed
> + *
> + * The function relies on 'devm' framework function which automatically
> + * clean the device's resources. It just calls explicitly disable function
> for
> + * the performance counters.
> + */
> +static int exynos5_dmc_remove(struct platform_device *pdev)
> +{
> + struct exynos5_dmc *dmc = dev_get_drvdata(>dev);
> +
> + exynos5_counters_disable_edev(dmc);
> +
> + clk_disable_unprepare(dmc->mout_mx_mspll_ccore);
> + clk_disable_unprepare(dmc->mout_spll);
> +
> + dev_pm_opp_remove_table(>dev);
> +
> + dev_info(>dev, "DMC removed\n");
> +
> + return 0;
> +}
> +
> +static const struct of_device_id exynos5_dmc_of_match[] = {
> + { .compatible = "samsung,exynos5422-dmc", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, exynos5_dmc_of_match);
> +
> +static struct platform_driver exynos5_dmc_platdrv = {
> + .probe = exynos5_dmc_probe,
> + .remove = exynos5_dmc_remove,
> + .driver = {
> + .name = "exynos5-dmc",
> + .of_match_table = exynos5_dmc_of_match,
> + },
> +};
> +module_platform_driver(exynos5_dmc_platdrv);
> +MODULE_DESCRIPTION("Driver for Exynos5422 Dynamic Memory Controller dynamic
> frequency and voltage change"
> +);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Samsung");
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v5 4/8] dt-bindings: devfreq: add Exynos5422 DMC device description
Hi Lukasz,
On 19. 3. 6. 오후 4:14, Lukasz Luba wrote:
> Hi Chanwoo,
>
> On 3/6/19 5:18 AM, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> On 19. 3. 5. 오후 7:19, Lukasz Luba wrote:
>>> The patch adds description for DT binding for a new Exynos5422 Dynamic
>>> Memory Controller device.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> .../devicetree/bindings/devfreq/exynos5422-dmc.txt | 177
>>> +
>>> 1 file changed, 177 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>> b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>> new file mode 100644
>>> index 000..0e73e98
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt
>>> @@ -0,0 +1,177 @@
>>> +* Exynos5422 frequency and voltage scaling for Dynamic Memory Controller
>>> device
>>> +
>>> +The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which
>>> the DRAM
>>> +memory chips are connected. The driver is to monitor the controller in
>>> runtime
>>> +and switch frequency and voltage. To monitor the usage of the controller in
>>> +runtime, the driver uses the PPMU (Platform Performance Monitoring Unit),
>>> which
>>> +is able to measure the current load of the memory.
>>> +When 'userspace' governor is used for the driver, an application is able to
>>> +switch the DMC frequency.
>>> +
>>> +Required properties for DMC device for Exynos5422:
>>> +- compatible: Should be "samsung,exynos5422-bus".
>>> +- clock-names : the name of clock used by the bus, "bus".
>>> +- clocks : phandles for clock specified in "clock-names" property.
>>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>>
>>
>> I already replied with following comments on v4 patch[1].
>> But, you didn't reply anything. We can reduce the duplicate
>> review by keeping the basic review rule.
> I have lost these changes while I was adding the OPPs, timings into the
> dt-binding.
>>
>> - Re: [PATCH v4 5/8] dt-bindings: devfreq: add Exynos5422 DMC device
>> description
>> [1] https://do-db2.lkml.org/lkml/2019/2/3/64
>>
>>
>> [Following comments were replied on v4 patch[1]]
>>
>>> +- compatible: Should be "samsung,exynos5422-bus".
>>
>> The compatible name is wrong.
>> - exynos5422-bus -> exynos5422-dmc
>>
>>> +- clock-names : the name of clock used by the bus, "bus".
>>
>> 'bus' is right?
> right
As I knew, the clocks of exynos5422-dmc is for DMC.
Why do you think 'bus' is right insted of DMC?.
I think that it is not a 'bus' driver.
>>
>>> +- clocks : phandles for clock specified in "clock-names" property.
>>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>>
>> The dt-binging file doesn't contain the any description for 'reg' properties.
> There are 3 regs: cdrex0, cdrex1, chip_id. I will add this description.
>
> The patch set has this OPPs and timings coming from DT as you requested
> but I am not sure if it is in the right place in the DT.
> Thus dt-binding you may consider as 'in-progress' till the DT entries
> are fixed
>
> Regards,
> Lukasz
>>
>>
>>
>>> +
>>> +The example definition of a DMC and PPMU devices declared in DT is shown
>>> below:
>>> +
>>> + ppmu_dmc0_0: ppmu@10d0 {
>>> + compatible = "samsung,exynos-ppmu";
>>> + reg = <0x10d0 0x2000>;
>>> + clocks = < CLK_PCLK_PPMU_DREX0_0>;
>>> + clock-names = "ppmu";
>>> + status = "okay";
>>> + events {
>>> + ppmu_event_dmc0_0: ppmu-event3-dmc0_0 {
>>> + event-name = "ppmu-event3-dmc0_0";
>>> + };
>>> + };
>>> + };
>>> +
>>> +
>>> + ppmu_dmc0_1: ppmu@10d1 {
>>> + compatible = "samsung,exynos-ppmu";
>>> + reg = <0x10d1 0x2000>;
>>> + clocks = < CLK_PCLK_PPMU_DREX0_1>;
>>> + clock-names = "ppmu";
>>> + status = "okay";
>>>
Re: [PATCH v3 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks
Hi, On 19. 3. 6. 오전 4:22, Hans de Goede wrote: > Hi, > > On 03-03-19 21:16, Yauhen Kharuzhy wrote: >> At implementation of charging support for Lenovo Yoga Book (Intel Cherry >> Trail based with Whiskey Cove PMIC), two pitfalls were found: >> >> - for detection of charger type by PMIC, bit 6 in the CHGRCTRL1 register >> should be set in 0 (and set to 1 for Host mode). Pick up its definition >> and logic from from Intel code drop[1]; >> >> - "#CHARGE ENABLE" signal of external charger (bq25892) in Yoga Book is >> connected to one of PMIC outputs controlled by CHGDISCTRL register. >> Enable charging at driver initialization. Pick up this from Lenovo's code >> drop[2,3]. >> >> >> v3 changes: >> - Don't restore of initial state of CHGDISCTRL and CHGRCTRL0 at exit but >> switch them into HW-controlled mode (as discussed in mailing list); >> - Use regmap_update_bits() instead of regmap_readi()/regmap_write() in >> the cht_wc_extcon_set_otgmode(); >> - Coding style and constant names changed as Andy and Hans recommended. > > Series looks good to me now, and I've also tested that it does not > cause any charging or 5v boost related regressions on a GPD pocket > laptop, so for the series: > > Reviewed-by: Hans de Goede > Tested-by: Hans de Goede > > Regards, > > Hans > Applied it. Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH -next & mmotm] extcon: fix EXTCON_PTP5150 kconfig warnings and build errors
Hi, Applied it for v5.1-rc2. I'll send the pull request it for v5.1-rc2. Best Regards, Chanwoo Choi On 19. 2. 26. 오전 9:17, Randy Dunlap wrote: > From: Randy Dunlap > > Having COMPILE_TEST here is causing problems. I reported one > last week and have another one today. Although I support > using COMPILE_TEST when possible, this one is better removed. > > Fixes these warnings and build errors: > > WARNING: unmet direct dependencies detected for REGMAP_I2C > Depends on [m]: I2C [=m] > Selected by [y]: > - EXTCON_PTN5150 [=y] && EXTCON [=y] && (I2C [=m] && GPIOLIB [=y] || > COMPILE_TEST [=y]) > Selected by [m]: > - EEPROM_AT24 [=m] && I2C [=m] && SYSFS [=y] > - KEYBOARD_CAP11XX [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && OF > [=y] && I2C [=m] > - I2C_MUX_LTC4306 [=m] && I2C [=m] && I2C_MUX [=m] > - GPIO_TS4900 [=m] && GPIOLIB [=y] && I2C [=m] && (SOC_IMX6 || COMPILE_TEST > [=y]) > - SENSORS_LTC2945 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_LTC4222 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_MAX6621 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_LM75 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_NCT7802 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_EMC1403 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_ADS7828 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_INA2XX [=m] && HWMON [=y] && I2C [=m] > - SENSORS_INA3221 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_TMP102 [=m] && HWMON [=y] && I2C [=m] > - SENSORS_TMP103 [=m] && HWMON [=y] && I2C [=m] > - MFD_BCM590XX [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_AXP20X_I2C [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MADERA_I2C [=m] && HAS_IOMEM [=y] && MFD_MADERA [=m] && I2C [=m] > - MFD_DA9062 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_DA9063 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_DA9150 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MC13XXX_I2C [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_88PM800 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_88PM805 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MAX14577 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_MAX77686 [=m] && HAS_IOMEM [=y] && I2C [=m] && (OF [=y] || > COMPILE_TEST [=y]) > - MFD_MAX8907 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_RT5033 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_RN5T618 [=m] && HAS_IOMEM [=y] && I2C [=m] && OF [=y] > - MFD_SI476X_CORE [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_SKY81452 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TI_LMU [=m] && HAS_IOMEM [=y] && I2C [=m] > - TPS6105X [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TPS65086 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TPS65217 [=m] && HAS_IOMEM [=y] && I2C [=m] && OF [=y] > - MFD_TI_LP873X [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_TPS65218 [=m] && HAS_IOMEM [=y] && I2C [=m] && OF [=y] > - MFD_TPS65912_I2C [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_LM3533 [=m] && HAS_IOMEM [=y] && I2C [=m] > - MFD_WM8994 [=m] && HAS_IOMEM [=y] && I2C [=m] > - REGULATOR_88PG86X [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_DA9211 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_FAN53555 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_LTC3676 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_MAX8649 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_MT6311 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_PFUZE100 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_PV88060 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_PV88080 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_SY8106A [=m] && REGULATOR [=y] && I2C [=m] && (OF [=y] || > COMPILE_TEST [=y]) > - REGULATOR_TPS62360 [=m] && REGULATOR [=y] && I2C [=m] > - REGULATOR_TPS65023 [=m] && REGULATOR [=y] && I2C [=m] > - DRM_ANALOGIX_ANX78XX [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] > - DRM_TOSHIBA_TC358767 [=m] && HAS_IOMEM [=y] &
Re: [PATCH v5 4/8] dt-bindings: devfreq: add Exynos5422 DMC device description
e = "samsung,exynos5422-dmc";
> + reg = <0x10c2 0x1>, <0x10c3 0x1>,
> + <0x1000 0x1000>;
> + clocks =< CLK_FOUT_SPLL>,
> + < CLK_MOUT_SCLK_SPLL>,
> + < CLK_FF_DOUT_SPLL2>,
> + < CLK_FOUT_BPLL>,
> + < CLK_MOUT_BPLL>,
> + < CLK_SCLK_BPLL>,
> + < CLK_MOUT_MX_MSPLL_CCORE>,
> + < CLK_MOUT_MX_MSPLL_CCORE_PHY>,
> + < CLK_MOUT_MCLK_CDREX>,
> + < CLK_DOUT_CLK2X_PHY0>,
> + < CLK_CLKM_PHY0>,
> + < CLK_CLKM_PHY1>,
> + < CLK_CDREX_PAUSE>,
> + < CLK_CDREX_TIMING_SET>;
> + clock-names = "fout_spll",
> + "mout_sclk_spll",
> + "ff_dout_spll2",
> + "fout_bpll",
> + "mout_bpll",
> + "sclk_bpll",
> + "mout_mx_mspll_ccore",
> + "mout_mx_mspll_ccore_phy",
> + "mout_mclk_cdrex",
> + "dout_clk2x_phy0",
> + "clkm_phy0",
> + "clkm_phy1",
> + "clk_cdrex_pause",
> + "clk_cdrex_timing_set";
> + status = "okay";
> + operating-points-v2 = <_opp_table>;
> + devfreq-events = <_dmc0_0>, <_dmc0_1>,
> + <_dmc1_0>, <_dmc1_1>;
> + };
> +
> +The needed timings of DRAM memory are stored in dedicated nodes.
> +There are two nodes with regular timings and for bypass mode.
> +
> + dmc_bypass_mode: bypass_mode {
> + compatible = "samsung,dmc-bypass-mode";
> +
> + freq-hz = <4>;
> + volt-uv = <887500>;
> + dram-timing-row = <0x365a9713>;
> + dram-timing-data = <0x4740085e>;
> + dram-timing-power = <0x543a0446>;
> + };
> +
> + dram_timing: timing {
> + compatible = "samsung,dram-timing";
> +
> + dram-timing-names = "165MHz", "206MHz", "275MHz", "413MHz",
> + "543MHz", "633MHz", "728MHz", "825MHz";
> + dram-timing-row = <0x11223185>, <0x112331C6>, <0x12244287>,
> + <0x1B35538A>, <0x244764CD>, <0x2A48758F>,
> + <0x30598651>, <0x365A9713>;
> + dram-timing-data = <0x2720085E>, <0x2720085E>, <0x2720085E>,
> +<0x2720085E>, <0x3730085E>, <0x3730085E>,
> +<0x3730085E>, <0x4740085E>;
> + dram-timing-power = <0x140C0225>, <0x180F0225>, <0x1C140225>,
> + <0x2C1D0225>, <0x38270335>, <0x402D0335>,
> + <0x4C330336>, <0x543A0446>;
> + };
> +
> +The frequencies supported by the DMC are stored in OPP table v2.
> +
> + dmc_opp_table: opp_table2 {
> + compatible = "operating-points-v2";
> +
> + opp00 {
> + opp-hz = /bits/ 64 <16500>;
> + opp-microvolt = <875000>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <20600>;
> + opp-microvolt = <875000>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <27500>;
> + opp-microvolt = <875000>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <41300>;
> + opp-microvolt = <887500>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <54300>;
> + opp-microvolt = <937500>;
> + };
> + opp05 {
> + opp-hz = /bits/ 64 <63300>;
> + opp-microvolt = <1012500>;
> + };
> + opp06 {
> + opp-hz = /bits/ 64 <72800>;
> + opp-microvolt = <1037500>;
> + };
> + opp07 {
> + opp-hz = /bits/ 64 <82500>;
> + opp-microvolt = <105>;
> + };
> + };
> +
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v5 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi Lukasz,
I'm talking about it repeatedly. How many times already, I mentioned
that you have to resend the patch after completed the discussion.
I replied this v3 patch[2]. But, you didn't reply or answer anything
and then just send the same patch without any consent.
- Re: [PATCH v3 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
[2] https://lkml.org/lkml/2019/2/11/198
On 19. 3. 5. 오후 7:19, Lukasz Luba wrote:
> Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory
> Controller frequencies for driver's DRAM timings.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 6da5875..6f5db70 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -1331,6 +1331,17 @@ static const struct samsung_pll_rate_table
> exynos5420_pll2550x_24mhz_tbl[] __ini
> PLL_35XX_RATE(24 * MHZ, 2, 200, 3, 3),
> };
>
> +static const struct samsung_pll_rate_table exynos5422_bpll_rate_table[] = {
> + PLL_35XX_RATE(24 * MHZ, 82500, 275, 4, 1),
> + PLL_35XX_RATE(24 * MHZ, 72800, 182, 3, 1),
> + PLL_35XX_RATE(24 * MHZ, 63300, 211, 4, 1),
> + PLL_35XX_RATE(24 * MHZ, 54300, 181, 2, 2),
> + PLL_35XX_RATE(24 * MHZ, 41300, 413, 6, 2),
> + PLL_35XX_RATE(24 * MHZ, 27500, 275, 3, 3),
> + PLL_35XX_RATE(24 * MHZ, 20600, 206, 3, 3),
> + PLL_35XX_RATE(24 * MHZ, 16500, 110, 2, 3),
> +};
> +
> static const struct samsung_pll_rate_table exynos5420_epll_24mhz_tbl[] = {
> PLL_36XX_RATE(24 * MHZ, 6U, 100, 2, 1, 0),
> PLL_36XX_RATE(24 * MHZ, 4U, 200, 3, 2, 0),
> @@ -1473,7 +1484,7 @@ static void __init exynos5x_clk_init(struct device_node
> *np,
> exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
> exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> - exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> + exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
> }
>
> samsung_clk_register_pll(ctx, exynos5x_plls, ARRAY_SIZE(exynos5x_plls),
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 2/2] drivers: devfreq: add tracing for scheduling work
Hi Lukasz, On 19. 2. 19. 오전 3:21, Lukasz Luba wrote: > This patch add basic tracing of the devfreq workqueue and delayed work. > It aims to capture changes of the polling intervals and device state. > > Signed-off-by: Lukasz Luba > --- > drivers/devfreq/devfreq.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 0ae3de7..660365a 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -29,6 +29,9 @@ > #include > #include "governor.h" > > +#define CREATE_TRACE_POINTS > +#include > + > static struct class *devfreq_class; > > /* > @@ -394,6 +397,8 @@ static void devfreq_monitor(struct work_struct *work) > queue_delayed_work(devfreq_wq, >work, > msecs_to_jiffies(devfreq->profile->polling_ms)); > mutex_unlock(>lock); > + > + trace_devfreq_monitor(devfreq); > } > > /** > Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v3 1/2] trace: events: add devfreq trace event file
Hi Lukasz,
On 19. 2. 19. 오전 3:21, Lukasz Luba wrote:
> The patch adds a new file for with trace events for devfreq
> framework. They are used for performance analysis of the framework.
> It also contains updates in MAINTAINERS file adding new entry for
> devfreq maintainers.
>
> Signed-off-by: Lukasz Luba
> ---
> MAINTAINERS| 1 +
> include/trace/events/devfreq.h | 40
> 2 files changed, 41 insertions(+)
> create mode 100644 include/trace/events/devfreq.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 41ce5f4..9c44076 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4447,6 +4447,7 @@ S: Maintained
> F: drivers/devfreq/
> F: include/linux/devfreq.h
> F: Documentation/devicetree/bindings/devfreq/
> +F: include/trace/events/devfreq.h
>
> DEVICE FREQUENCY EVENT (DEVFREQ-EVENT)
> M: Chanwoo Choi
> diff --git a/include/trace/events/devfreq.h b/include/trace/events/devfreq.h
> new file mode 100644
> index 000..cf5b877
> --- /dev/null
> +++ b/include/trace/events/devfreq.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM devfreq
> +
> +#if !defined(_TRACE_DEVFREQ_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_DEVFREQ_H
> +
> +#include
> +#include
> +
> +TRACE_EVENT(devfreq_monitor,
> + TP_PROTO(struct devfreq *devfreq),
> +
> + TP_ARGS(devfreq),
> +
> + TP_STRUCT__entry(
> + __field(unsigned long, freq)
> + __field(unsigned long, busy_time)
> + __field(unsigned long, total_time)
> + __field(unsigned int, polling_ms)
> + __string(dev_name, dev_name(>dev))
> + ),
> +
> + TP_fast_assign(
> + __entry->freq = devfreq->previous_freq;
> + __entry->busy_time = devfreq->last_status.busy_time;
> + __entry->total_time = devfreq->last_status.total_time;
> + __entry->polling_ms = devfreq->profile->polling_ms;
> + __assign_str(dev_name, dev_name(>dev));
> + ),
> +
> + TP_printk("dev_name=%s freq=%lu polling_ms=%u load=%lu",
> + __get_str(dev_name), __entry->freq, __entry->polling_ms,
> + __entry->total_time == 0 ? 0 :
> + (100 * __entry->busy_time) / __entry->total_time)
> +);
> +#endif /* _TRACE_DEVFREQ_H */
> +
> +/* This part must be outside protection */
> +#include
>
I think that it is necessary for devfreq. Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 4/4] PM / devfreq: Handle monitor start/stop in the devfreq core
Hi Matthias,
On 19. 2. 16. 오전 7:56, Matthias Kaehlcke wrote:
> Hi Chanwoo,
>
> On Fri, Feb 15, 2019 at 09:33:05AM +0900, Chanwoo Choi wrote:
>> Hi Matthias,
>>
>> On 19. 2. 15. 오전 9:19, Matthias Kaehlcke wrote:
>>> Hi Chanwoo,
>>>
>>> On Fri, Feb 15, 2019 at 08:42:30AM +0900, Chanwoo Choi wrote:
>>>> Hi Matthias,
>>>>
>>>> On 19. 2. 15. 오전 4:28, Matthias Kaehlcke wrote:
>>>>> Hi Chanwoo,
>>>>>
>>>>> On Thu, Feb 14, 2019 at 11:17:36PM +0900, Chanwoo Choi wrote:
>>>>>> Hi Matthias,
>>>>>>
>>>>>> As I commented on the first patch, it is not possible to call some codes
>>>>>> according to the intention of each governor between 'devfreq_moniotr_*()'
>>>>>> and some codes which are executed before or after 'devfreq_moniotr_*()'
>>>>>>
>>>>>> For example, if some governor requires the following sequence,
>>>>>> after this patch, it is not possible.
>>>>>>
>>>>>> case DEVFREQ_GOV_xxx:
>>>>>> /* execute some code before devfreq_monitor_xxx() */
>>>>>> devfreq_monitor_xxx()
>>>>>> /* execute some code after devfreq_monitor_xxx() */
>>>>>
>>>>> As for the suspend/resume case I agree that the patch introduces this
>>>>> limitation, but I'm not convinced that this is an actual problem.
>>>>>
>>>>> For governor_start(): why can't the governor execute the code
>>>>> before polling started, does it make any difference to the governor
>>>>> that a work is scheduled?
>>>>
>>>> The some governors might want to do something before starting
>>>> the work and do something after work started. I think that
>>>> the existing style is more flexible.
>>>
>>> Could you provide a practical example that answers my question above:
>>>
>>> "why can't the governor execute the code before polling started, does
>>> it make any difference to the governor that a work is scheduled?"
>>
>> Actually, as for now, I don't know the correct practice and now.
>> I want to say that the existing style is more flexible for the
>> new governor in the future.
>
> If you try submitting 'flexible' code in other parts of the kernel
> without users of this flexibility and no solid arguments why this
> flexibility is needed it would most likely be rejected.
>
> Unnecessary flexibility can be a burden, rather than an advantage.
>
>> If there are no any special benefits I think we don't need to harm
>> the flexibility.
>
> There are multiple benefits, the following shortcomings of the current
> approach are eliminated:
>
> - it is error prone and allows governors to do the wrong thing, e.g.
> - start monitoring before the governor is fully ready
> - keep monitoring when the governor is partially 'stopped'
> - omit mandatory calls
> - delegates tasks to the governors which are responsibility of the
> core
> - code is harder to read
> - switch from common code to governor code and back
> - unecessary boilerplate code in governors
> - option to replace ->event_handler() with ->start(), ->stop(), etc,
> which is cleaner
>
> I'm easily convinced if the flexibility is really needed. I'm not even
> expecting a real world example, just be creative and make something
> up that sounds reasonable.
>
> start/resume()
> {
> // prepare governor
>
> // start polling
>
> =>what needs to be done here that couldn't have been done
> =>before polling was started?
> }
>
> stop/suspend()
> {
> =>what needs to be done here that couldn't be done after polling
> =>is stopped?
>
> // stop polling
>
> // 'unprepare' governor
> }
>
>>>> And,
>>>> It has one more problem when changing the governor on the fly
>>>> from simple_ondemand to other governors like performance,
>>>> powersave and so on.
>>>>
>>>> Even if other governors don't need to monitor the utilization,
>>>> the work timer will be executed continually because the devfreq
>>>> device has the polling_ms value. It is not necessary
>>>> of the other governors such as performance, powersave.
>>>>
>>>> It means that only specific governor like simple_ondemand
>>>> have to call the devfreq_monitor_start() by itself
>>>&
Re: [PATCH v2 1/2] trace: events: add devfreq trace event file
Hi Lukasz,
On 19. 2. 15. 오후 10:05, Lukasz Luba wrote:
> The patch adds a new file for with trace events for devfreq
> framework. They are used for performance analysis of the framework.
> It also contains updates in MAINTAINERS file adding new entry for
> devfreq maintainers.
>
> Signed-off-by: Lukasz Luba
> ---
> MAINTAINERS| 1 +
> include/trace/events/devfreq.h | 40
> 2 files changed, 41 insertions(+)
> create mode 100644 include/trace/events/devfreq.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 41ce5f4..9c44076 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4447,6 +4447,7 @@ S: Maintained
> F: drivers/devfreq/
> F: include/linux/devfreq.h
> F: Documentation/devicetree/bindings/devfreq/
> +F: include/trace/events/devfreq.h
>
> DEVICE FREQUENCY EVENT (DEVFREQ-EVENT)
> M: Chanwoo Choi
> diff --git a/include/trace/events/devfreq.h b/include/trace/events/devfreq.h
> new file mode 100644
> index 000..ce83dba
> --- /dev/null
> +++ b/include/trace/events/devfreq.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM devfreq
> +
> +#if !defined(_TRACE_DEVFREQ_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_DEVFREQ_H
> +
> +#include
> +#include
> +
> +TRACE_EVENT(devfreq_monitor,
> + TP_PROTO(struct devfreq *devfreq),
> +
> + TP_ARGS(devfreq),
> +
> + TP_STRUCT__entry(
> + __field(unsigned long, freq)
> + __field(unsigned long, busy_time)
> + __field(unsigned long, total_time)
> + __field(unsigned int, polling_ms)
> + __string(dev_name, dev_name(>dev))
> + ),
> +
> + TP_fast_assign(
> + __entry->freq = devfreq->previous_freq;
> + __entry->busy_time = devfreq->last_status.busy_time;
> + __entry->total_time = devfreq->last_status.total_time;
> + __entry->polling_ms = devfreq->profile->polling_ms;
> + __assign_str(dev_name, dev_name(>dev));
> + ),
> +
> + TP_printk("dev_name=%s freq=%lu polling_ms=%u load=%lu",
> + __get_str(dev_name), __entry->freq, __entry->polling_ms,
> + __entry->total_time == 0 ? 100 :
I case of __entry->total_time is zero,
why do you show '100' instead of '0'(zero)?
I think that it might make the some confusion for user.
If it show the '100' in case of "__entry->total_time is zero",
it cannot distinguish between the real 100% utilization
and "total_time is zero".
> + (100 * __entry->busy_time) / __entry->total_time)
> +);
> +#endif /* _TRACE_DEVFREQ_H */
> +
> +/* This part must be outside protection */
> +#include
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 2/2] drivers: devfreq: add tracing for scheduling work
Hi Lukasz, On 19. 2. 15. 오후 10:05, Lukasz Luba wrote: > This patch add basic tracing of the devfreq workqueue and delayed work. > It aims to capture changes of the polling intervals and device state. > > Signed-off-by: Lukasz Luba > --- > drivers/devfreq/devfreq.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 0ae3de7..660365a 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -29,6 +29,9 @@ > #include > #include "governor.h" > > +#define CREATE_TRACE_POINTS > +#include > + > static struct class *devfreq_class; > > /* > @@ -394,6 +397,8 @@ static void devfreq_monitor(struct work_struct *work) > queue_delayed_work(devfreq_wq, >work, > msecs_to_jiffies(devfreq->profile->polling_ms)); > mutex_unlock(>lock); > + > + trace_devfreq_monitor(devfreq); > } > > /** > Looks good to me. Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 3/3] PM / devfreq: tegra: remove unneeded variable
On 19. 2. 17. 오전 12:18, Yangtao Li wrote:
> This variable is not used after initialization, so
> remove it. And in order to unify the code style,
> move the location where the dev_get_drvdata is called
> by the way.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/tegra-devfreq.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index c59d2eee5d30..c89ba7b834ff 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -573,10 +573,7 @@ static int tegra_governor_get_target(struct devfreq
> *devfreq,
> static int tegra_governor_event_handler(struct devfreq *devfreq,
> unsigned int event, void *data)
> {
> - struct tegra_devfreq *tegra;
> - int ret = 0;
> -
> - tegra = dev_get_drvdata(devfreq->dev.parent);
> + struct tegra_devfreq *tegra = dev_get_drvdata(devfreq->dev.parent);
>
> switch (event) {
> case DEVFREQ_GOV_START:
> @@ -600,7 +597,7 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
> break;
> }
>
> - return ret;
> + return 0;
> }
>
> static struct devfreq_governor tegra_devfreq_governor = {
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 1/3] PM / devfreq: rk3399_dmc: remove unneeded semicolon
Hi, On 19. 2. 17. 오전 12:18, Yangtao Li wrote: > The semicolon is unneeded, so remove it. > > Signed-off-by: Yangtao Li > --- > drivers/devfreq/rk3399_dmc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c > index e795ad2b3f6b..a228dad2bee4 100644 > --- a/drivers/devfreq/rk3399_dmc.c > +++ b/drivers/devfreq/rk3399_dmc.c > @@ -322,7 +322,7 @@ static int rk3399_dmcfreq_probe(struct platform_device > *pdev) > > dev_err(dev, "Cannot get the clk dmc_clk\n"); > return PTR_ERR(data->dmc_clk); > - }; > + } > > data->edev = devfreq_event_get_edev_by_phandle(dev, 0); > if (IS_ERR(data->edev)) > Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 2/3] PM / devfreq: rockchip-dfi: remove unneeded semicolon
Hi,
On 19. 2. 17. 오전 12:18, Yangtao Li wrote:
> The semicolon is unneeded, so remove it.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/event/rockchip-dfi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/event/rockchip-dfi.c
> b/drivers/devfreq/event/rockchip-dfi.c
> index 22b113363ffc..fcbf76ebf55d 100644
> --- a/drivers/devfreq/event/rockchip-dfi.c
> +++ b/drivers/devfreq/event/rockchip-dfi.c
> @@ -211,7 +211,7 @@ static int rockchip_dfi_probe(struct platform_device
> *pdev)
> if (IS_ERR(data->clk)) {
> dev_err(dev, "Cannot get the clk dmc_clk\n");
> return PTR_ERR(data->clk);
> - };
> + }
>
> /* try to find the optional reference to the pmu syscon */
> node = of_parse_phandle(np, "rockchip,pmu", 0);
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks
Hi Yauhen, You are missing me on cc list. I didn't know this patchset. On next, please use the get_maintainer script in order to send the correct list. On 19. 2. 11. 오전 5:36, Yauhen Kharuzhy wrote: > At implementation of charging support for Lenovo Yoga Book (Intel Cherry Trail > based with Whiskey Cove PMIC), two pitfalls were found: > > - for detection of charger type by PMIC, bit 6 in the CHGRCTRL1 register > should be set in 0 (and set to 1 for Host mode). Pick up its definition > and logic from from Intel code drop[1]; > > - "#CHARGE ENABLE" signal of external charger (bq25892) in Yoga Book is > connected to one of PMIC outputs controlled by CHGDISCTRL register. > Enable charging at driver initialization. Pick up this from Lenovo's code > drop[2,3]. > > Please keep in mind that I have no docs for Whiskey Cove PMIC, so this patches > are based on some kind of reverse engineering and suppositions, correct me if > this semantic is wrong for common case. > > [1]. > https://github.com/01org/ProductionKernelQuilts/uefi/cht-m1stable/patches/0001-power_supply-intel-pmic-ccsm-driver.patch > [2]. > https://github.com/jekhor/yogabook-linux-android-kernel/blob/b7aa015ab794b516da7b6cb76e5e2d427e3b8b0c/drivers/power/bq2589x_charger.c#L2257 > [3]. > https://github.com/01org/ProductionKernelQuilts/uefi/cht-m1stable/patches/EM-Charger-Disable-battery-charging-in-S3-and-enable.patch > > Yauhen Kharuzhy (2): > extcon-intel-cht-wc: Make charger detection co-existed with OTG host mode > extcon intel-cht-wc: Enable external charger > > drivers/extcon/extcon-intel-cht-wc.c | 71 +++++++- > 1 file changed, 70 insertions(+), 1 deletion(-) > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 4/4] PM / devfreq: Handle monitor start/stop in the devfreq core
Hi Matthias, On 19. 2. 15. 오전 9:19, Matthias Kaehlcke wrote: > Hi Chanwoo, > > On Fri, Feb 15, 2019 at 08:42:30AM +0900, Chanwoo Choi wrote: >> Hi Matthias, >> >> On 19. 2. 15. 오전 4:28, Matthias Kaehlcke wrote: >>> Hi Chanwoo, >>> >>> On Thu, Feb 14, 2019 at 11:17:36PM +0900, Chanwoo Choi wrote: >>>> Hi Matthias, >>>> >>>> As I commented on the first patch, it is not possible to call some codes >>>> according to the intention of each governor between 'devfreq_moniotr_*()' >>>> and some codes which are executed before or after 'devfreq_moniotr_*()' >>>> >>>> For example, if some governor requires the following sequence, >>>> after this patch, it is not possible. >>>> >>>> case DEVFREQ_GOV_xxx: >>>> /* execute some code before devfreq_monitor_xxx() */ >>>> devfreq_monitor_xxx() >>>> /* execute some code after devfreq_monitor_xxx() */ >>> >>> As for the suspend/resume case I agree that the patch introduces this >>> limitation, but I'm not convinced that this is an actual problem. >>> >>> For governor_start(): why can't the governor execute the code >>> before polling started, does it make any difference to the governor >>> that a work is scheduled? >> >> The some governors might want to do something before starting >> the work and do something after work started. I think that >> the existing style is more flexible. > > Could you provide a practical example that answers my question above: > > "why can't the governor execute the code before polling started, does > it make any difference to the governor that a work is scheduled?" Actually, as for now, I don't know the correct practice and now. I want to say that the existing style is more flexible for the new governor in the future. If there are no any special benefits, I think we don't need to harm the flexibility. > >> And, >> It has one more problem when changing the governor on the fly >> from simple_ondemand to other governors like performance, >> powersave and so on. >> >> Even if other governors don't need to monitor the utilization, >> the work timer will be executed continually because the devfreq >> device has the polling_ms value. It is not necessary >> of the other governors such as performance, powersave. >> >> It means that only specific governor like simple_ondemand >> have to call the devfreq_monitor_start() by itself >> instead of calling it on devfreq core. > > yes, I noticed that too, it can be easily fixed with a flag in the > governor. Right, If we add some codes like flag, it is easy. Actually, it is just difference how to support them. I think that the existing style has not any problem and is not complicated to develop the new governor. If there are no some benefits, IMO, we better to keep the flexibility. It can give the flexibility to the developer of governor. > >>> For governor_stop(): why would the governor require polling to be >>> active during stop? If it needs update_devfreq() to run (called by >>> devfreq_monitor()) it can call it directly, instead of waiting for the >>> monitor to run at some later time. >> >> As I knew, if the current governors are performance/powersave/ >> userspace, the monitoring is already stopped and not used. >> Because they don't need to handle the codes related to the work >> like queue_delayed_work(), cancel_delayed_work_sync(). >> >> And, >> In case of the existing style for calling devfreq_monitor_*(), >> other governors like performance/powersave/userspace/passice >> don't need to call the devfreq_monitor_stop() because they >> didn't use the work timer. > > As per above, the governor could have a flag indicating that it > doesn't need load monitoring. About this, I commented above. Pleas check it. > > I think it should be avoided to expect the governors to do the right > thing if certain actions are mandatory and common for all governors > (unless the feature in question is not used). It should be handled in > the core code, unless there are good reasons not to do this. I agree to distinguish for common code and specific code depends on governor. But, it is harm for the flexibility. We know that there are no problem after applying this patchset. But, as I commented, I'm not sure that it is meaningful to harm the flexibility. > > With thispatch set the amount of code remains essentially the same, > and no new code needs to be added for governors that don't do anything > special in start/stop/suspend/resume. > > TBH I think probably the entire event handler multiplexing should go > away and be changed to a struct devfreq_ops with optional callbacks > for start, stop, suspend, resume and update interval. As far as I can > tell the multiplexing isn't needed and separate ops would result in > cleaner code, in both the devfreq core and the governors. > > Cheers > > Matthias > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 1/4] PM / devfreq: Track overall load monitor state instead of 'stop_polling'
Hi Matthias, On 19. 2. 15. 오전 1:59, Matthias Kaehlcke wrote: > Hi Chanwoo, > > On Thu, Feb 14, 2019 at 11:25:52PM +0900, Chanwoo Choi wrote: >> Hi Matthias, >> >> 2019년 2월 14일 (목) 오후 7:16, Matthias Kaehlcke 님이 작성: >>> >>> The field ->stop_polling indicates whether load monitoring should be/is >>> stopped, it is set in devfreq_monitor_suspend(). Change the variable to >>> hold the general state of load monitoring (stopped, running, suspended). >>> Besides improving readability of conditions involving the field and this >>> prepares the terrain for moving some duplicated code from the governors >>> into the devfreq core. >>> >>> Hold the devfreq lock in devfreq_monitor_start/stop() to ensure proper >>> synchronization. >> >> IMHO, I'm not sure that there are any benefits changing >> from 'stop_polling' to 'monitor_state'. I have no objections >> if Myungjoo confirms it. > > I agree that as an isolated change there isn't a clear benefit. > However in the context of the series the change is needed to > avoid resuming a load monitor that wasn't even started. > > In case this series isn't accepted I'd still suggest to change the > name from 'stop_polling' to 'suspended'. I read 'stop_polling' as a > call for action, while 'suspended' is a state. IMO at least in some > contexts conditions using a state is clearer. I agree to change the variable name 'stop_polling' to 'suspended' for using the correct meaningful name. > > Cheers > > Matthias > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 4/4] PM / devfreq: Handle monitor start/stop in the devfreq core
Hi Matthias, On 19. 2. 15. 오전 4:28, Matthias Kaehlcke wrote: > Hi Chanwoo, > > On Thu, Feb 14, 2019 at 11:17:36PM +0900, Chanwoo Choi wrote: >> Hi Matthias, >> >> As I commented on the first patch, it is not possible to call some codes >> according to the intention of each governor between 'devfreq_moniotr_*()' >> and some codes which are executed before or after 'devfreq_moniotr_*()' >> >> For example, if some governor requires the following sequence, >> after this patch, it is not possible. >> >> case DEVFREQ_GOV_xxx: >> /* execute some code before devfreq_monitor_xxx() */ >> devfreq_monitor_xxx() >> /* execute some code after devfreq_monitor_xxx() */ > > As for the suspend/resume case I agree that the patch introduces this > limitation, but I'm not convinced that this is an actual problem. > > For governor_start(): why can't the governor execute the code > before polling started, does it make any difference to the governor > that a work is scheduled? The some governors might want to do something before starting the work and do something after work started. I think that the existing style is more flexible. And, It has one more problem when changing the governor on the fly from simple_ondemand to other governors like performance, powersave and so on. Even if other governors don't need to monitor the utilization, the work timer will be executed continually because the devfreq device has the polling_ms value. It is not necessary of the other governors such as performance, powersave. It means that only specific governor like simple_ondemand have to call the devfreq_monitor_start() by itself instead of calling it on devfreq core. > > For governor_stop(): why would the governor require polling to be > active during stop? If it needs update_devfreq() to run (called by > devfreq_monitor()) it can call it directly, instead of waiting for the > monitor to run at some later time. As I knew, if the current governors are performance/powersave/ userspace, the monitoring is already stopped and not used. Because they don't need to handle the codes related to the work like queue_delayed_work(), cancel_delayed_work_sync(). And, In case of the existing style for calling devfreq_monitor_*(), other governors like performance/powersave/userspace/passice don't need to call the devfreq_monitor_stop() because they didn't use the work timer. > > Cheers > > Matthias > > > > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 3/4] PM / devfreq: Add devfreq_governor_start/stop()
Hi Matthias,
When I contributed the something to devfreq.c, if the newly added functions
are internal/static, just added the function without 'devfreq_' prefix
in order to distinguish them from the exported function as following:
- find_available_min_freq()
- find_available_max_freq()
- set_freq_table()
So, the governor_start/stop are the static function used only in devfreq.c,
in order to sustain the consistency of function naming, I recommened
that changes them as following:
- devfreq_governor_start -> governor_start
- devfreq_governor_stop -> governor_stop
2019년 2월 14일 (목) 오후 11:12, Chanwoo Choi 님이 작성:
>
> Hi Matthias,
>
> Looks good to me for making the function to remove the duplicate code.
> But, When I just tested the kernel build, following warnings occur
> about devfreq_governor_stop().
>
> In file included from ./include/linux/devfreq.h:16:0,
> from drivers/devfreq/devfreq.c:23:
> drivers/devfreq/devfreq.c: In function ‘devfreq_governor_stop’:
> drivers/devfreq/devfreq.c:619:17: warning: format ‘%s’ expects
> argument of type ‘char *’, but argument 4 has type ‘int’ [-Wformat=]
>dev_warn(dev, "%s: Governor %s not stopped: %d\n",
> ^
> ./include/linux/device.h:1380:22: note: in definition of macro ‘dev_fmt’
> #define dev_fmt(fmt) fmt
> ^
> drivers/devfreq/devfreq.c:619:3: note: in expansion of macro ‘dev_warn’
>dev_warn(dev, "%s: Governor %s not stopped: %d\n",
>^
> drivers/devfreq/devfreq.c:619:17: warning: format ‘%d’ expects a
> matching ‘int’ argument [-Wformat=]
>dev_warn(dev, "%s: Governor %s not stopped: %d\n",
> ^
> ./include/linux/device.h:1380:22: note: in definition of macro ‘dev_fmt’
> #define dev_fmt(fmt) fmt
> ^
> drivers/devfreq/devfreq.c:619:3: note: in expansion of macro ‘dev_warn’
>dev_warn(dev, "%s: Governor %s not stopped: %d\n",
>
> 2019년 2월 14일 (목) 오후 7:16, Matthias Kaehlcke 님이 작성:
> >
> > The following pattern is repeated multiple times:
> >
> > - call governor event handler with DEVFREQ_GOV_START/STOP
> > - check return value
> > - in case of error log a message
> >
> > Add devfreq_governor_start/stop() helper functions with this code
> > and call them instead.
> >
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > drivers/devfreq/devfreq.c | 96 +++
> > 1 file changed, 58 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> > index 7fab6c4cf719b..eb86461648d74 100644
> > --- a/drivers/devfreq/devfreq.c
> > +++ b/drivers/devfreq/devfreq.c
> > @@ -580,6 +580,53 @@ static int devfreq_notifier_call(struct notifier_block
> > *nb, unsigned long type,
> > return ret;
> > }
> >
> > +/**
> > + * devfreq_governor_start() - Start the devfreq governor of the device.
> > + * @devfreq: the devfreq instance
> > + */
> > +static int devfreq_governor_start(struct devfreq *devfreq)
> > +{
> > + struct device *dev = devfreq->dev.parent;
> > + int err;
> > +
> > + if (WARN(mutex_is_locked(>lock),
> > +"mutex must *not* be held by the caller\n"))
> > + return -EINVAL;
> > +
> > + err = devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_START,
> > + NULL);
> > + if (err) {
> > + dev_err(dev, "Governor %s not started: %d\n",
> > + devfreq->governor->name, err);
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * devfreq_governor_stop() - Stop the devfreq governor of the device.
> > + * @devfreq: the devfreq instance
> > + */
> > +static int devfreq_governor_stop(struct devfreq *devfreq)
> > +{
> > + struct device *dev = devfreq->dev.parent;
> > + int err;
> > +
> > + if (WARN(mutex_is_locked(>lock),
> > +"mutex must *not* be held by the caller\n"))
> > + return -EINVAL;
> > +
> > + err = devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_STOP,
> > NULL);
> > + if (err) {
> > + dev_warn(dev, "%s: Governor %s not stopped: %d\n",
> > +devfreq->governor->name, err);
> > + return err;
> > + }
> > +
> > + return 0;
> >
Re: [PATCH 1/4] PM / devfreq: Track overall load monitor state instead of 'stop_polling'
update(struct devfreq *devfreq,
> unsigned int *delay)
> mutex_unlock(>lock);
> cancel_delayed_work_sync(>work);
> mutex_lock(>lock);
> - if (!devfreq->stop_polling)
> + if (devfreq->monitor_state != DEVFREQ_MONITOR_SUSPENDED)
> queue_delayed_work(devfreq_wq, >work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
> }
> @@ -1372,7 +1388,7 @@ static ssize_t trans_stat_show(struct device *dev,
> int i, j;
> unsigned int max_state = devfreq->profile->max_state;
>
> - if (!devfreq->stop_polling &&
> + if ((devfreq->monitor_state == DEVFREQ_MONITOR_RUNNING) &&
> devfreq_update_status(devfreq,
> devfreq->previous_freq))
> return 0;
> if (max_state == 0)
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index fbffa74bfc1bb..0a618bbb8b294 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -130,7 +130,7 @@ struct devfreq_dev_profile {
> * @max_freq: Limit maximum frequency requested by user (0: none)
> * @scaling_min_freq: Limit minimum frequency requested by OPP interface
> * @scaling_max_freq: Limit maximum frequency requested by OPP interface
> - * @stop_polling: devfreq polling status of a device.
> + * @monitor_state: State of the load monitor.
> * @suspend_freq: frequency of a device set during suspend phase.
> * @resume_freq:frequency of a device set in resume phase.
> * @suspend_count: suspend requests counter for a device.
> @@ -168,7 +168,7 @@ struct devfreq {
> unsigned long max_freq;
> unsigned long scaling_min_freq;
> unsigned long scaling_max_freq;
> - bool stop_polling;
> + int monitor_state;
>
> unsigned long suspend_freq;
> unsigned long resume_freq;
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
--
Best Regards,
Chanwoo Choi
Re: [PATCH 4/4] PM / devfreq: Handle monitor start/stop in the devfreq core
* if current delay is zero, start polling with new delay */
> if (!cur_delay) {
> - queue_delayed_work(devfreq_wq, >work,
> - msecs_to_jiffies(devfreq->profile->polling_ms));
> + devfreq_monitor_start(devfreq);
> goto out;
> }
>
> /* if current delay is greater than new delay, restart polling */
> if (cur_delay > new_delay) {
> - mutex_unlock(>lock);
> - cancel_delayed_work_sync(>work);
> - mutex_lock(>lock);
> + devfreq_monitor_stop(devfreq);
> if (devfreq->monitor_state != DEVFREQ_MONITOR_SUSPENDED)
> - queue_delayed_work(devfreq_wq, >work,
> - msecs_to_jiffies(devfreq->profile->polling_ms));
> + devfreq_monitor_start(devfreq);
> }
> out:
> mutex_unlock(>lock);
> @@ -601,6 +596,8 @@ static int devfreq_governor_start(struct devfreq *devfreq)
> return err;
> }
>
> + devfreq_monitor_start(devfreq);
> +
> return 0;
> }
>
> @@ -624,6 +621,8 @@ static int devfreq_governor_stop(struct devfreq *devfreq)
> return err;
> }
>
> + devfreq_monitor_stop(devfreq);
> +
> return 0;
> }
>
> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
> index d136792c0cc91..47efe747b6f79 100644
> --- a/drivers/devfreq/governor.h
> +++ b/drivers/devfreq/governor.h
> @@ -57,8 +57,6 @@ struct devfreq_governor {
> unsigned int event, void *data);
> };
>
> -extern void devfreq_monitor_start(struct devfreq *devfreq);
> -extern void devfreq_monitor_stop(struct devfreq *devfreq);
> extern void devfreq_interval_update(struct devfreq *devfreq,
> unsigned int *delay);
>
> diff --git a/drivers/devfreq/governor_simpleondemand.c
> b/drivers/devfreq/governor_simpleondemand.c
> index 52eb0c734b312..e0f0944a9c7aa 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -91,14 +91,6 @@ static int devfreq_simple_ondemand_handler(struct devfreq
> *devfreq,
> unsigned int event, void *data)
> {
> switch (event) {
> - case DEVFREQ_GOV_START:
> - devfreq_monitor_start(devfreq);
> - break;
> -
> - case DEVFREQ_GOV_STOP:
> - devfreq_monitor_stop(devfreq);
> - break;
> -
> case DEVFREQ_GOV_INTERVAL:
> devfreq_interval_update(devfreq, (unsigned int *)data);
> break;
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 79efa1e51bd06..515fb852dbad6 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -580,13 +580,11 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
>
> switch (event) {
> case DEVFREQ_GOV_START:
> - devfreq_monitor_start(devfreq);
> tegra_actmon_enable_interrupts(tegra);
> break;
>
> case DEVFREQ_GOV_STOP:
> tegra_actmon_disable_interrupts(tegra);
> - devfreq_monitor_stop(devfreq);
> break;
>
> case DEVFREQ_GOV_SUSPEND:
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
--
Best Regards,
Chanwoo Choi
Re: [PATCH 3/4] PM / devfreq: Add devfreq_governor_start/stop()
> devfreq->governor->event_handler(devfreq,
> - DEVFREQ_GOV_STOP,
> NULL);
> - if (ret) {
> - dev_warn(dev,
> -"%s: Governor %s stop =
> %d\n",
> -__func__,
> -devfreq->governor->name,
> ret);
> - }
> + ret = devfreq_governor_stop(devfreq);
> +
> /* Fall through */
> }
> +
> devfreq->governor = governor;
> - ret = devfreq->governor->event_handler(devfreq,
> - DEVFREQ_GOV_START, NULL);
> - if (ret) {
> - dev_warn(dev, "%s: Governor %s start=%d\n",
> -__func__, devfreq->governor->name,
> -ret);
> - }
> + devfreq_governor_start(devfreq);
> }
> }
>
> @@ -1081,7 +1113,6 @@ int devfreq_remove_governor(struct devfreq_governor
> *governor)
> goto err_out;
> }
> list_for_each_entry(devfreq, _list, node) {
> - int ret;
> struct device *dev = devfreq->dev.parent;
>
> if (!strncmp(devfreq->governor_name, governor->name,
> @@ -1093,13 +1124,8 @@ int devfreq_remove_governor(struct devfreq_governor
> *governor)
> continue;
> /* Fall through */
> }
> - ret = devfreq->governor->event_handler(devfreq,
> - DEVFREQ_GOV_STOP, NULL);
> - if (ret) {
> - dev_warn(dev, "%s: Governor %s stop=%d\n",
> -__func__, devfreq->governor->name,
> -ret);
> - }
> +
> + devfreq_governor_stop(devfreq);
> devfreq->governor = NULL;
> }
> }
> @@ -1149,19 +1175,13 @@ static ssize_t governor_store(struct device *dev,
> struct device_attribute *attr,
> }
>
> if (df->governor) {
> - ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
> - if (ret) {
> - dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
> -__func__, df->governor->name, ret);
> + ret = devfreq_governor_stop(df);
> + if (ret)
> goto out;
> - }
> }
> df->governor = governor;
> strncpy(df->governor_name, governor->name, DEVFREQ_NAME_LEN);
> - ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> - if (ret)
> - dev_warn(dev, "%s: Governor %s not started(%d)\n",
> -__func__, df->governor->name, ret);
> + ret = devfreq_governor_start(df);
> out:
> mutex_unlock(_list_lock);
>
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
--
Best Regards,
Chanwoo Choi
Re: [PATCH 2/4] PM / devfreq: Handle monitor suspend/resume in the devfreq core
* to be called from governor in response to DEVFREQ_GOV_RESUME
> - * event or when polling interval is set to non-zero.
> + * Helper function to resume devfreq device load monitoring.
> */
> -void devfreq_monitor_resume(struct devfreq *devfreq)
> +static void devfreq_monitor_resume(struct devfreq *devfreq)
> {
> unsigned long freq;
>
> @@ -501,7 +496,6 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
> out:
> mutex_unlock(>lock);
> }
> -EXPORT_SYMBOL(devfreq_monitor_resume);
>
> /**
> * devfreq_interval_update() - Update device devfreq monitoring interval
> @@ -903,6 +897,8 @@ int devfreq_suspend_device(struct devfreq *devfreq)
> DEVFREQ_GOV_SUSPEND, NULL);
> if (ret)
> return ret;
> +
> + devfreq_monitor_suspend(devfreq);
> }
>
> if (devfreq->suspend_freq) {
> @@ -944,6 +940,8 @@ int devfreq_resume_device(struct devfreq *devfreq)
> DEVFREQ_GOV_RESUME, NULL);
> if (ret)
> return ret;
> +
> + devfreq_monitor_resume(devfreq);
> }
>
> return 0;
> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
> index f53339ca610fc..d136792c0cc91 100644
> --- a/drivers/devfreq/governor.h
> +++ b/drivers/devfreq/governor.h
> @@ -59,8 +59,6 @@ struct devfreq_governor {
>
> extern void devfreq_monitor_start(struct devfreq *devfreq);
> extern void devfreq_monitor_stop(struct devfreq *devfreq);
> -extern void devfreq_monitor_suspend(struct devfreq *devfreq);
> -extern void devfreq_monitor_resume(struct devfreq *devfreq);
> extern void devfreq_interval_update(struct devfreq *devfreq,
> unsigned int *delay);
>
> diff --git a/drivers/devfreq/governor_simpleondemand.c
> b/drivers/devfreq/governor_simpleondemand.c
> index c0417f0e081e0..52eb0c734b312 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -103,14 +103,6 @@ static int devfreq_simple_ondemand_handler(struct
> devfreq *devfreq,
> devfreq_interval_update(devfreq, (unsigned int *)data);
> break;
>
> - case DEVFREQ_GOV_SUSPEND:
> - devfreq_monitor_suspend(devfreq);
> - break;
> -
> - case DEVFREQ_GOV_RESUME:
> - devfreq_monitor_resume(devfreq);
> - break;
> -
> default:
> break;
> }
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index c59d2eee5d309..79efa1e51bd06 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -591,11 +591,9 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
>
> case DEVFREQ_GOV_SUSPEND:
> tegra_actmon_disable_interrupts(tegra);
> - devfreq_monitor_suspend(devfreq);
> break;
>
> case DEVFREQ_GOV_RESUME:
> - devfreq_monitor_resume(devfreq);
> tegra_actmon_enable_interrupts(tegra);
> break;
> }
> --
> 2.20.1.791.gb4d0f1c61a-goog
>
--
Best Regards,
Chanwoo Choi
Re: [PATCH v3 6/7] trace: events: add devfreq trace event file
Hi Lukasz,
On 19. 2. 13. 오후 10:35, Lukasz Luba wrote:
> Hi Steven,
>
> On 2/13/19 12:14 AM, Steven Rostedt wrote:
>> On Tue, 12 Feb 2019 23:23:57 +0100
>> Lukasz Luba wrote:
>>
>>> The patch adds a new file for with trace events for devfreq
>>> framework. They are used for performance analysis of the framework.
>>> It also contains updates in MAINTAINERS file adding new entry for
>>> devfreq maintainers.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> MAINTAINERS| 1 +
>>> include/trace/events/devfreq.h | 39
>>> +++
>>> 2 files changed, 40 insertions(+)
>>> create mode 100644 include/trace/events/devfreq.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 9919840..c042fda 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -4447,6 +4447,7 @@ S:Maintained
>>> F:drivers/devfreq/
>>> F: include/linux/devfreq.h
>>> F:Documentation/devicetree/bindings/devfreq/
>>> +F: include/trace/events/devfreq.h
>>>
>>> DEVICE FREQUENCY EVENT (DEVFREQ-EVENT)
>>> M:Chanwoo Choi
>>> diff --git a/include/trace/events/devfreq.h b/include/trace/events/devfreq.h
>>> new file mode 100644
>>> index 000..fec9304
>>> --- /dev/null
>>> +++ b/include/trace/events/devfreq.h
>>> @@ -0,0 +1,39 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#undef TRACE_SYSTEM
>>> +#define TRACE_SYSTEM devfreq
>>> +
>>> +#if !defined(_TRACE_DEVFREQ_H) || defined(TRACE_HEADER_MULTI_READ)
>>> +#define _TRACE_DEVFREQ_H
>>> +
>>> +#include
>>> +#include
>>> +
>>> +TRACE_EVENT(devfreq_monitor,
>>> + TP_PROTO(const char *dev_name, unsigned long freq,
>>> +unsigned int polling_ms, unsigned long busy_time,
>>> +unsigned long total_time),
>>> +
>>> + TP_ARGS(dev_name, freq, polling_ms, busy_time, total_time),
>>> +
>>> + TP_STRUCT__entry(
>>> + __string(dev_name, dev_name)
>>> + __field(unsigned long, freq)
>>> + __field(unsigned int, polling_ms)
>>> + __field(unsigned int, load)
>>> + ),
>>> +
>>> + TP_fast_assign(
>>> + __assign_str(dev_name, dev_name);
>>> + __entry->freq = freq;
>>> + __entry->polling_ms = polling_ms;
>>> + __entry->load = (100 * busy_time) / total_time;
>>
>> How critical is the code that this trace event is called in. If it is
>> not that critical (it is a slow path), then this is fine, but if this
>> is not a slow path (something triggered 100 HZ or less), then I would
>> recommend moving the above calculation to TP_printk(). A divide is a
>> slow operation, and is best to do that in the post processing. The
>> current location does the divide at the time of the tracepoint is
>> called.
> I wasn't aware of these two stages, good to know.
> I will move it to TP_printk().
>>
>> I would also have a check to make sure that total_time is not zero
>> here, otherwise that could be bad.
>>
>> __entry->busy_time = busy_time;
>> __entry->total_time = total_time;
>>
>
>>> + ),
>>> +
>>> + TP_printk("dev_name=%s freq=%lu polling_ms=%u load=%u",
>>
>>
>>> + __get_str(dev_name), __entry->freq, __entry->polling_ms,
>>
>> __entry->total_time == 0 ? 100 :
>> __entry->busy_time / __entry->total_time)
> Thank you for the review.
> I will add this check.
>
> Regards,
> Lukasz
>>
>> -- Steve
>>
>>> + __entry->load)
>>> +);
>>> +#endif /* _TRACE_DEVFREQ_H */
>>> +
>>> +/* This part must be outside protection */
>>> +#include
>>
>>
>>
>
>
I agree that trace point is necessary for devfreq framework.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 7/7] drivers: devfreq: add tracing for scheduling work
Hi Lukasz, On 19. 2. 13. 오전 7:23, Lukasz Luba wrote: > This patch add basic tracing of the devfreq workqueue and delayed work. > It aims to capture changes of the polling intervals and device state. > > Signed-off-by: Lukasz Luba > --- > drivers/devfreq/devfreq.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 29e99ce..c1d0d8c 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -29,6 +29,9 @@ > #include > #include "governor.h" > > +#define CREATE_TRACE_POINTS > +#include > + > /* The ~30% load threshold used for load calculation (due to fixed point > * arithmetic) */ > #define LOAD_THRESHOLD_IN_DEVICE_USAGE (300) > @@ -418,6 +421,7 @@ static void devfreq_monitor(struct work_struct *work) > struct devfreq *devfreq = container_of(work, > struct devfreq, work.work); > unsigned int polling_ms; > + const char *df_name = dev_name(>dev); nit: You can use 'dev_name(>dev)' directly without defining the separate df_name. > > mutex_lock(>lock); > polling_ms = devfreq_get_polling_delay(devfreq); > @@ -429,6 +433,10 @@ static void devfreq_monitor(struct work_struct *work) > schedule_delayed_work(>work, > msecs_to_jiffies(polling_ms)); > mutex_unlock(>lock); > + > + trace_devfreq_monitor(df_name, devfreq->previous_freq, polling_ms, > + devfreq->last_status.busy_time, > + devfreq->last_status.total_time); Regardless of type of work, I think that trace point is necessary for devfreq framework. Reviewed-by: Chanwoo Choi > } > > /** > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v3 4/7] include: devfreq: add polling_idle_ms to 'profile'
Hi Lukasz,
If the user can select the type of work in accordance with
their choice, either deferrable work or delayed work
for periodic without stop on idle state,
I think that the existing polling_ms is enough.
Because, user determine to use the 'delayed work' for periodic timer,
user can change the polling_ms through already provided sysfs interface
according to multiple situation.
In fact,
If the user want to use the periodic timer without stop on idle state
instead of deferrable work, it means that the user always want to
monitor/check the current load/status of device at the correct interval
and then changing the frequency without any latency.
On 19. 2. 13. 오전 7:23, Lukasz Luba wrote:
> Add needed fields to support new state: idle, where different polling
> interval is in use. It provides better control of the devfreq device
> and lower the power consumption when the device is not busy.
>
> Signed-off-by: Lukasz Luba
> ---
> include/linux/devfreq.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index fbffa74..5140970 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -72,6 +72,11 @@ struct devfreq_dev_status {
> * @initial_freq:The operating frequency when devfreq_add_device() is
> * called.
> * @polling_ms: The polling interval in ms. 0 disables polling.
> + * @polling_idle_ms: The polling interval in 'idle state' in ms.
> + * When the device is running at lowest frequency and has
> + * low-load, it is considered as in 'idle state'.
> + * Thus, longer polling interval is used for the device
> + * to save some power.
> * @target: The device should set its operating frequency at
> * freq or lowest-upper-than-freq value. If freq is
> * higher than any operable frequency, set maximum.
> @@ -98,6 +103,7 @@ struct devfreq_dev_status {
> struct devfreq_dev_profile {
> unsigned long initial_freq;
> unsigned int polling_ms;
> + unsigned int polling_idle_ms;
>
> int (*target)(struct device *dev, unsigned long *freq, u32 flags);
> int (*get_dev_status)(struct device *dev,
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 2/7] drivers: devfreq: change devfreq workqueue mechanism
Hi Lukasz,
This patch depends on first patch. Firstly, we need to discuss
the first patch and then I'll review this patch.
[1] [PATCH v3 1/7] drivers: devfreq: change deferred work into delayed
On 19. 2. 13. 오전 7:23, Lukasz Luba wrote:
> There is no need for creating another workqueue in the system,
> the existing one should meet the requirements.
> This patch removes devfreq's custom workqueue and uses system one.
> It switches from queue_delayed_work() to schedule_delayed_work().
> It also does not wake up the system when it enters suspend (this
> functionality stays the same).
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/devfreq/devfreq.c | 25 ++---
> 1 file changed, 6 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 0c9bff8..c200b3c 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -31,13 +31,6 @@
>
> static struct class *devfreq_class;
>
> -/*
> - * devfreq core provides delayed work based load monitoring helper
> - * functions. Governors can use these or can implement their own
> - * monitoring mechanism.
> - */
> -static struct workqueue_struct *devfreq_wq;
> -
> /* The list of all device-devfreq governors */
> static LIST_HEAD(devfreq_governor_list);
> /* The list of all device-devfreq */
> @@ -391,8 +384,8 @@ static void devfreq_monitor(struct work_struct *work)
> if (err)
> dev_err(>dev, "dvfs failed with (%d) error\n", err);
>
> - queue_delayed_work(devfreq_wq, >work,
> - msecs_to_jiffies(devfreq->profile->polling_ms));
> + schedule_delayed_work(>work,
> + msecs_to_jiffies(devfreq->profile->polling_ms));
> mutex_unlock(>lock);
> }
>
> @@ -409,7 +402,7 @@ void devfreq_monitor_start(struct devfreq *devfreq)
> {
> INIT_DELAYED_WORK(>work, devfreq_monitor);
> if (devfreq->profile->polling_ms)
> - queue_delayed_work(devfreq_wq, >work,
> + schedule_delayed_work(>work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
> }
> EXPORT_SYMBOL(devfreq_monitor_start);
> @@ -473,7 +466,7 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>
> if (!delayed_work_pending(>work) &&
> devfreq->profile->polling_ms)
> - queue_delayed_work(devfreq_wq, >work,
> + schedule_delayed_work(>work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
>
> devfreq->last_stat_updated = jiffies;
> @@ -516,7 +509,7 @@ void devfreq_interval_update(struct devfreq *devfreq,
> unsigned int *delay)
>
> /* if current delay is zero, start polling with new delay */
> if (!cur_delay) {
> - queue_delayed_work(devfreq_wq, >work,
> + schedule_delayed_work(>work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
> goto out;
> }
> @@ -527,7 +520,7 @@ void devfreq_interval_update(struct devfreq *devfreq,
> unsigned int *delay)
> cancel_delayed_work_sync(>work);
> mutex_lock(>lock);
> if (!devfreq->stop_polling)
> - queue_delayed_work(devfreq_wq, >work,
> + schedule_delayed_work(>work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
> }
> out:
> @@ -1430,12 +1423,6 @@ static int __init devfreq_init(void)
> return PTR_ERR(devfreq_class);
> }
>
> - devfreq_wq = create_freezable_workqueue("devfreq_wq");
> - if (!devfreq_wq) {
> - class_destroy(devfreq_class);
> - pr_err("%s: couldn't create workqueue\n", __FILE__);
> - return -ENOMEM;
> - }
> devfreq_class->dev_groups = devfreq_groups;
>
> return 0;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 1/7] drivers: devfreq: change deferred work into delayed
Hi Lukasz,
On 19. 2. 13. 오전 7:23, Lukasz Luba wrote:
> This patch changes deferred work to delayed work, which is now not missed
> when timer is put on CPU that entered idle state.
> The devfreq framework governor was not called, thus changing the device's
> frequency did not happen.
> Benchmarks for stressing Dynamic Memory Controller show x2 (in edge cases
> even x5) performance boost with this patch when 'simpleondemand_governor'
> is responsible for monitoring the device load and frequency changes.
>
> With this patch, the delayed work is done no mater CPUs' idle.
> All of the drivers in devfreq which rely on periodic, guaranteed wakeup
> intervals should benefit from it.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/devfreq/devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 0ae3de7..0c9bff8 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -407,7 +407,7 @@ static void devfreq_monitor(struct work_struct *work)
> */
> void devfreq_monitor_start(struct devfreq *devfreq)
> {
> - INIT_DEFERRABLE_WORK(>work, devfreq_monitor);
> + INIT_DELAYED_WORK(>work, devfreq_monitor);
As I commented, I can't agree that just changing the type of work
from deferrable to delayed for the always periodic timer.
Instead, if devfreq framework supports both deferrable
and delayed work according to selecting the kind of work
by user, I agree.
> if (devfreq->profile->polling_ms)
> queue_delayed_work(devfreq_wq, >work,
> msecs_to_jiffies(devfreq->profile->polling_ms));
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 0/2] drivers: devfreq: fix and optimize workqueue mechanism
Hi Lukasz, On 19. 2. 13. 오후 7:47, Lukasz Luba wrote: > Hi Chanwoo, > > On 2/13/19 2:09 AM, Chanwoo Choi wrote: >> Hi Lukasz, >> >> On 19. 2. 12. 오후 9:05, Lukasz Luba wrote: >>> Hi Chanwoo >>> >>> On 2/12/19 6:46 AM, Chanwoo Choi wrote: >>>> Hi Lukasz, >>>> >>>> On 19. 2. 12. 오전 12:30, Lukasz Luba wrote: >>>>> This patch set changes workqueue related features in devfreq framework. >>>>> First patch switches to delayed work instead of deferred. >>>>> The second switches to regular system work and deletes custom 'devfreq'. >>>>> >>>>> Using deferred work in this context might harm the system performance. >>>>> When the CPU enters idle, deferred work is not fired. The devfreq device's >>>>> utilization does not have to be connected with a particular CPU. >>>>> The drivers for GPUs, Network on Chip, cache L3 rely on devfreq governor. >>>>> They all are missing opportunity to check the HW state and react when >>>>> the deferred work is not fired. >>>>> A corner test case, when Dynamic Memory Controller is utilized by CPUs >>>>> running >>>>> on full speed, might show x5 worse performance if the crucial CPU is in >>>>> idle. >>>> >>>> The devfreq framework keeps the balancing between performance >>>> and power-consumption. It is wrong to focus on only either >>>> performance or power. >>> IMO it just does not work, please see my explanation below. >>>> >>>> This cover-letter focus on the only performance without any >>>> power-consumption >>>> disadvantages. It is easy to raise the performance with short sampling rate >>>> with polling modes. To get the performance, it is good as short as possible >>>> of period. >>> The cover-letter mentioned about missing functionality. The interface >>> has 'polling_ms' field, which driver developer would assume works. >>> I have test cases where it would not be called for seconds or even >>> never. >>> In your driver drivers/devfreq/exynos-bus.c polling_ms = 50 >>> The driver is controlling many devices including Network-on-Chip (NOC). >>> It is using 'simple_ondemand' governor. When it is missing opportunity >>> to change the frequency, it can either harm the performance or power >>> consumption, depending of the frequency the device stuck on. >> >> Almost everyone knew that DVFS governor is never perfect in the linux kernel. >> I don't want to discuss it with this too generic opinion which doesn't >> include the real measured data. >> >>> >>>> >>>> Sometimes, when cpu is idle, the device might require the busy state. >>>> It is very difficult to catch the always right timing between them. >>> I will try to address them in the next patch set. >>>> >>>> Also, this patch cannot prevent the unneeded wakeup from idle state. >> >> Please answer this question. >> >> When release the real mobile product like galaxy phone, >> it is very important issue to remove the unneeded wakeup on idle state. > I would say that these devfreq wake-ups are important and people thought > that they are periodic and rely on it. Since the devfreq does not have > trace events no one knew what is actually happening inside. I agree that adding the trace events for devfreq. But, just I mentioned the 'unneeded wakeup from idle state'. As I already replied on patch, v2 patchset don't provide the any tunable interface for the kind of work. The v2 patches just changed the work from deferrable to delayed. Someone want to keep the deferrable or someone want to use the periodic without considering idle. But, in this series, just remove the deferrable work without any choice. It is my point to discuss your patch. > Profiling the whole devfreq framework just for one product is not fair. > The devfreq clients are not only mobiles, there are other type of > embedded devices. There are embedded devices (based on TI, iMX, etc) > which are not powered from battery and are used i.e. for streaming video > from camera or image recognition. I agree absolutely. There are many kind of embedded devices. For one embedded device, I don't want to remove the previous benefit. To remove the any confusion, I mention my opinion once again. It is not proper to just remove the deferrable work without any tunable interface. Instead, if devfreq framework supports both deferrable and delayed work according to tunable interface, I agree. >> >> >&
Re: [PATCH] devfreq: Use of_node_name_eq for node name comparisons
Hi Rob,
On 19. 2. 14. 오전 1:09, Rob Herring wrote:
> On Wed, Dec 5, 2018 at 1:50 PM Rob Herring wrote:
>>
>> Convert string compares of DT node names to use of_node_name_eq helper
>> instead. This removes direct access to the node name pointer.
>>
>> For instances using of_node_cmp, this has the side effect of now using
>> case sensitive comparisons. This should not matter for any FDT based
>> system which all of these are.
>>
>> Cc: Chanwoo Choi
>> Cc: MyungJoo Ham
>> Cc: Kyungmin Park
>> Cc: Kukjin Kim
>> Cc: Krzysztof Kozlowski
>> Cc: linux...@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-samsung-...@vger.kernel.org
>> Signed-off-by: Rob Herring
>> ---
>> drivers/devfreq/devfreq-event.c | 2 +-
>> drivers/devfreq/event/exynos-ppmu.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Can someone apply this please.
Myungjoo picked up this patch[1] on devfreq.git
but has not yet sent the pull request.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/commit/?h=for-next=0c1e8ce295acc3becc95e393e88a9a6da233074f
>
>>
>> diff --git a/drivers/devfreq/devfreq-event.c
>> b/drivers/devfreq/devfreq-event.c
>> index d67242d87744..87e93406d7cd 100644
>> --- a/drivers/devfreq/devfreq-event.c
>> +++ b/drivers/devfreq/devfreq-event.c
>> @@ -240,7 +240,7 @@ struct devfreq_event_dev
>> *devfreq_event_get_edev_by_phandle(struct device *dev,
>> }
>>
>> list_for_each_entry(edev, _event_list, node) {
>> - if (!strcmp(edev->desc->name, node->name))
>> + if (of_node_name_eq(node, edev->desc->name))
>> goto out;
>> }
>> edev = NULL;
>> diff --git a/drivers/devfreq/event/exynos-ppmu.c
>> b/drivers/devfreq/event/exynos-ppmu.c
>> index c61de0bdf053..c2ea94957501 100644
>> --- a/drivers/devfreq/event/exynos-ppmu.c
>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>> @@ -529,7 +529,7 @@ static int of_get_devfreq_events(struct device_node *np,
>> if (!ppmu_events[i].name)
>> continue;
>>
>> - if (!of_node_cmp(node->name, ppmu_events[i].name))
>> + if (of_node_name_eq(node, ppmu_events[i].name))
>> break;
>> }
>>
>> --
>> 2.19.1
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 0/7] drivers: devfreq: fix and optimize workqueue mechanism
Hi Lukasz, On 19. 2. 13. 오후 8:14, Lukasz Luba wrote: > Hi Chanwoo, > > On 2/13/19 1:18 AM, Chanwoo Choi wrote: >> On 19. 2. 13. 오전 7:23, Lukasz Luba wrote: >>> This patch set changes workqueue related features in devfreq framework. >>> First patch switches to delayed work instead of deferred. >>> The second switches to regular system work and deletes custom 'devfreq'. >>> >>> Using deferred work in this context might harm the system performance. >>> When the CPU enters idle, deferred work is not fired. The devfreq device's >>> utilization does not have to be connected with a particular CPU. >>> The drivers for GPUs, Network on Chip, cache L3 rely on devfreq governor. >>> They all are missing opportunity to check the HW state and react when >>> the deferred work is not fired. >>> A corner test case, when Dynamic Memory Controller is utilized by CPUs >>> running >>> on full speed, might show x5 worse performance if the crucial CPU is in >>> idle. >>> >>> There was a discussion regarding v2 that the power usage because of waking >>> up >> >> We have not yet finished the any discussion. We only just had a few reply >> and you didn't wait for any reply from other. As I already commented >> on exynos5422-dmc series, please don't send the next patch >> without any final agreement. >> >> In this series, patch1/patch2 are same at version 2 patchset. >> Even if we need to discuss more them, you just send same patches >> without any agreement among reviewers. At least, you have to wait the reply >> instead of just sending the new patchset. It is basic review rule on mailing >> list. > I think you are blocking the fixes. > Matthias is currently fixing devfreq governors which lack 'case SUSPEND' > and he is interested in these v3. I have fixed a month ago issue with > system suspend and OPP state of devfreq devices, which Tobias was rising > and sending patches a few years ago, but you have blocked them. I never blocked any something. I spent many times to review the devfreq patches to imporve the devfreq frameworw. In case of Tobias's patch, I just suggested other opinion and approach, but he didn't finish them. If I blocked some patches for devfreq, why am I review your suspend patch and agree them? It is very ridiculous of your thinking. > > These version is ready for comments regarding 'battery powered devices'. > The v3 has introduced approach for 2 polling intervals similar to > thermal framework. > It also has trace events. The trace events are *really* important in > this discussion because we need some measurements. > > You said: > 'When release the real mobile product like galaxy phone, > it is very important issue to remove the unneeded wakeup on idle state.' > Was it a real reason for profiling the devfreq framework and core > workqueue mechanism? There are embedded devices which are not using Yes. I think that deferrable workqueue is very important for some case. But, on the other hand, it might be always true. I don't just want to remove the deferrable work. But, I agree that to support both delayed and deferrable work according to the choice of devfreq device drivers. If remove the deferrable work, it always wakeup the idle state. The device driver never handle them. Someone want to get the high-performance but, someone don't want to wakeup from idle state. On your v2 patchset, just remove the deferrable work without any tunable feature. So, I try to discuss them. But, you just sent next patches without any discussion. And then, you also asked that we had to check the next patches. It is wrong for review sequence. I have to wait the review /discuss before sending the next patches. Once again, I don't just want to remove the deferrable work without any tunable interface. But, I agree that to support both delayed and deferrable work according to the choice of devfreq device drivers. > battery and probably developers were not aware because there was no > traces which could give any information about devfreq behavior. > Power is important, performance is important but relaying on randomness > is not the best solution. As I said earlier, your driver can stuck on > highest OPP waiting for next callback which will not come... > > Regards, > Lukasz >> >> >>> an idle CPU would be too high. In my opinion it won't and fixing bug is more >>> important than < 1% more power used [1]. >>> I have addressed also this issue. In this patch set there is a mechanism >>> which prevents from to frequent checks when there is no need. >>> When the device enters its lowest state (OPP) the framework sets polling >>> interval to 'polling_id
Re: [PATCH 3/4] clk: samsung: exynos5410: Add gate clock for ADC
Hi,
On 19. 2. 13. 오전 2:50, Krzysztof Kozlowski wrote:
> Add the gate clock for ADC block on Exynos5410.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/clk/samsung/clk-exynos5410.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5410.c
> b/drivers/clk/samsung/clk-exynos5410.c
> index 0a0b09591e6f..b2da2c8fa0c7 100644
> --- a/drivers/clk/samsung/clk-exynos5410.c
> +++ b/drivers/clk/samsung/clk-exynos5410.c
> @@ -209,6 +209,7 @@ static const struct samsung_gate_clock
> exynos5410_gate_clks[] __initconst = {
> GATE(CLK_USI1, "usi1", "aclk66", GATE_IP_PERIC, 11, 0, 0),
> GATE(CLK_USI2, "usi2", "aclk66", GATE_IP_PERIC, 12, 0, 0),
> GATE(CLK_USI3, "usi3", "aclk66", GATE_IP_PERIC, 13, 0, 0),
> + GATE(CLK_TSADC, "tsadc", "aclk66", GATE_IP_PERIC, 15, 0, 0),
> GATE(CLK_PWM, "pwm", "aclk66", GATE_IP_PERIC, 24, 0, 0),
>
> GATE(CLK_SCLK_UART0, "sclk_uart0", "div_uart0",
>
I checked it on Exynos5410 TRM. Looks good to me.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 2/4] dt-bindings: clock: exynos: Add ADC clock ID to Exynos5410
Hi, On 19. 2. 13. 오전 2:50, Krzysztof Kozlowski wrote: > Add ID for TSADC clock to Exynos5410. Choose the same value of ID as in > Exynos5420 to make it simpler/compatible in future (although clock > driver code is not shared). > > Signed-off-by: Krzysztof Kozlowski > --- > include/dt-bindings/clock/exynos5410.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/dt-bindings/clock/exynos5410.h > b/include/dt-bindings/clock/exynos5410.h > index 5b911ede0534..86c2ad56c5ef 100644 > --- a/include/dt-bindings/clock/exynos5410.h > +++ b/include/dt-bindings/clock/exynos5410.h > @@ -45,6 +45,7 @@ > #define CLK_USI1 266 > #define CLK_USI2 267 > #define CLK_USI3 268 > +#define CLK_TSADC270 > #define CLK_PWM 279 > #define CLK_MCT 315 > #define CLK_WDT 316 > Acked-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 1/4] dt-bindings: clock: exynos: Put CLK_UART3 in order
Hi, On 19. 2. 13. 오전 2:50, Krzysztof Kozlowski wrote: > Order the CLK_UART3 by ID. No change in functionality. > > Signed-off-by: Krzysztof Kozlowski > --- > include/dt-bindings/clock/exynos5410.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/dt-bindings/clock/exynos5410.h > b/include/dt-bindings/clock/exynos5410.h > index f179eabbcdb7..5b911ede0534 100644 > --- a/include/dt-bindings/clock/exynos5410.h > +++ b/include/dt-bindings/clock/exynos5410.h > @@ -36,6 +36,7 @@ > #define CLK_UART0257 > #define CLK_UART1258 > #define CLK_UART2259 > +#define CLK_UART3260 > #define CLK_I2C0 261 > #define CLK_I2C1 262 > #define CLK_I2C2 263 > @@ -44,7 +45,6 @@ > #define CLK_USI1 266 > #define CLK_USI2 267 > #define CLK_USI3 268 > -#define CLK_UART3260 > #define CLK_PWM 279 > #define CLK_MCT 315 > #define CLK_WDT 316 > Acked-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 0/2] drivers: devfreq: fix and optimize workqueue mechanism
Hi Lukasz, On 19. 2. 12. 오후 9:05, Lukasz Luba wrote: > Hi Chanwoo > > On 2/12/19 6:46 AM, Chanwoo Choi wrote: >> Hi Lukasz, >> >> On 19. 2. 12. 오전 12:30, Lukasz Luba wrote: >>> This patch set changes workqueue related features in devfreq framework. >>> First patch switches to delayed work instead of deferred. >>> The second switches to regular system work and deletes custom 'devfreq'. >>> >>> Using deferred work in this context might harm the system performance. >>> When the CPU enters idle, deferred work is not fired. The devfreq device's >>> utilization does not have to be connected with a particular CPU. >>> The drivers for GPUs, Network on Chip, cache L3 rely on devfreq governor. >>> They all are missing opportunity to check the HW state and react when >>> the deferred work is not fired. >>> A corner test case, when Dynamic Memory Controller is utilized by CPUs >>> running >>> on full speed, might show x5 worse performance if the crucial CPU is in >>> idle. >> >> The devfreq framework keeps the balancing between performance >> and power-consumption. It is wrong to focus on only either >> performance or power. > IMO it just does not work, please see my explanation below. >> >> This cover-letter focus on the only performance without any power-consumption >> disadvantages. It is easy to raise the performance with short sampling rate >> with polling modes. To get the performance, it is good as short as possible >> of period. > The cover-letter mentioned about missing functionality. The interface > has 'polling_ms' field, which driver developer would assume works. > I have test cases where it would not be called for seconds or even > never. > In your driver drivers/devfreq/exynos-bus.c polling_ms = 50 > The driver is controlling many devices including Network-on-Chip (NOC). > It is using 'simple_ondemand' governor. When it is missing opportunity > to change the frequency, it can either harm the performance or power > consumption, depending of the frequency the device stuck on. Almost everyone knew that DVFS governor is never perfect in the linux kernel. I don't want to discuss it with this too generic opinion which doesn't include the real measured data. > >> >> Sometimes, when cpu is idle, the device might require the busy state. >> It is very difficult to catch the always right timing between them. > I will try to address them in the next patch set. >> >> Also, this patch cannot prevent the unneeded wakeup from idle state. Please answer this question. When release the real mobile product like galaxy phone, it is very important issue to remove the unneeded wakeup on idle state. >> Apparently, it only focuses on performance without considering >> the power-consumption disadvantage. In the embedded device, >> the power-consumption is very important point. We can not ignore >> the side effect. > Power consumption is important, but we cannot rely on randomness > when we develop core features in a framework. Sure, I agree that as I commented, the devfreq framework keep the balancing between performance and power-consumption. Instead, this patch only focus on the performance without considering the power-consumption side-effect. >> >> Always, I hope to improve the devfreq framwork more that older. >> But, frankly, it is difficult to agree because it only consider >> the performance without considering the side-effect. >> >> The power management framework always have to consider >> the power-consumption issue. This point is always true. > I do agree that the power vs. performance trade-off must be considered > in the devfreq framework. I have developed 2 additional patches and You should only mention the posted patches on mailing list. > I am going to post them today (you can now check them on Tizen gerrit, > change 198160). It is not good to mention the some specific gerrit. I just only review the patches on mailing list. First of all, please answer the question on above > > We cannot simply pin the *device* load with *CPU* load or idle state. > It is not an implication. > The device like GPU, NoC or Dynamic Memory Controller can have > completely different utilization (i.e in Exynos the GPU is connected > to DDR memory through NoC and DMC). In order to get the high performance, the performance of GPU depends on CPU. h/w have depended on them tightly coupled. So, it is not easy to show the just relationship between them. We need the comprehensive measured data for both performance and power-consumption on all cases without the corner cases. > Some developers who use OpenCL on GPU might be interested in
Re: [PATCH v3 0/7] drivers: devfreq: fix and optimize workqueue mechanism
On 19. 2. 13. 오전 7:23, Lukasz Luba wrote: > This patch set changes workqueue related features in devfreq framework. > First patch switches to delayed work instead of deferred. > The second switches to regular system work and deletes custom 'devfreq'. > > Using deferred work in this context might harm the system performance. > When the CPU enters idle, deferred work is not fired. The devfreq device's > utilization does not have to be connected with a particular CPU. > The drivers for GPUs, Network on Chip, cache L3 rely on devfreq governor. > They all are missing opportunity to check the HW state and react when > the deferred work is not fired. > A corner test case, when Dynamic Memory Controller is utilized by CPUs running > on full speed, might show x5 worse performance if the crucial CPU is in idle. > > There was a discussion regarding v2 that the power usage because of waking up We have not yet finished the any discussion. We only just had a few reply and you didn't wait for any reply from other. As I already commented on exynos5422-dmc series, please don't send the next patch without any final agreement. In this series, patch1/patch2 are same at version 2 patchset. Even if we need to discuss more them, you just send same patches without any agreement among reviewers. At least, you have to wait the reply instead of just sending the new patchset. It is basic review rule on mailing list. > an idle CPU would be too high. In my opinion it won't and fixing bug is more > important than < 1% more power used [1]. > I have addressed also this issue. In this patch set there is a mechanism > which prevents from to frequent checks when there is no need. > When the device enters its lowest state (OPP) the framework sets polling > interval to 'polling_idle_ms'. In default Kconfig it is 500ms, so 2 times per > second. > It is tunable from the sysfs interface per device, thus driver developer can > experiment and choose best intervals for the system. > > Changes: > v3: > - reordered first two patches > - added functionality to lower power consumption when the device is less busy; > there is a new polling interval enabled when device enters lowest frequency; > - added trace events to capture the behaviour of the system > v2: > - single patch split into two > - added cover letter > > link for the previous version and discussion: > https://marc.info/?l=linux-pm=154989907416072=2 > https://marc.info/?l=linux-pm=154904631226997=2 > > Regards, > Lukasz Luba > > [1] https://marc.info/?l=linux-kernel=155000641622443=2 > > Lukasz Luba (7): > drivers: devfreq: change deferred work into delayed > drivers: devfreq: change devfreq workqueue mechanism > Kconfig: drivers: devfreq: add default idle polling > include: devfreq: add polling_idle_ms to 'profile' > drivers: devfreq: add longer polling interval in idle > trace: events: add devfreq trace event file > drivers: devfreq: add tracing for scheduling work > > MAINTAINERS | 1 + > drivers/devfreq/Kconfig | 13 +++ > drivers/devfreq/devfreq.c | 184 > -- > drivers/devfreq/governor.h| 3 +- > drivers/devfreq/governor_simpleondemand.c | 6 +- > include/linux/devfreq.h | 6 + > include/trace/events/devfreq.h| 39 +++ > 7 files changed, 218 insertions(+), 34 deletions(-) > create mode 100644 include/trace/events/devfreq.h > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v4 2/8] clk: samsung: add new clocks for DMC for Exynos5422 SoC
Hi Lukasz,
On 19. 2. 11. 오후 8:11, Lukasz Luba wrote:
> Hi Chanwoo,
>
> On 2/3/19 10:56 AM, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> I recommend that please don't send the version up patchset before
>> finishing the discussion.
>>
>> 2019년 2월 2일 (토) 오전 2:47, Lukasz Luba 님이 작성:
>>>
>>> This patch provides support for clocks needed for Dynamic Memory Controller
>>> in Exynos5422 SoC. It adds CDREX base register addresses, new DIV, MUX and
>>> GATE entries.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> drivers/clk/samsung/clk-exynos5420.c | 46
>>>
>>> 1 file changed, 42 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>>> b/drivers/clk/samsung/clk-exynos5420.c
>>> index 34cce3c..f1a4f56 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -132,6 +132,8 @@
>>> #define BPLL_LOCK 0x20010
>>> #define BPLL_CON0 0x20110
>>> #define SRC_CDREX 0x20200
>>> +#define GATE_BUS_CDREX00x20700
>>> +#define GATE_BUS_CDREX10x20704
>>> #define DIV_CDREX0 0x20500
>>> #define DIV_CDREX1 0x20504
>>> #define KPLL_LOCK 0x28000
>>> @@ -248,6 +250,8 @@ static const unsigned long exynos5x_clk_regs[]
>>> __initconst = {
>>> DIV_CDREX1,
>>> SRC_KFC,
>>> DIV_KFC0,
>>> + GATE_BUS_CDREX0,
>>> + GATE_BUS_CDREX1,
>>> };
>>>
>>> static const unsigned long exynos5800_clk_regs[] __initconst = {
>>> @@ -425,6 +429,10 @@ PNAME(mout_group13_5800_p) = { "dout_osc_div",
>>> "mout_sw_aclkfl1_550_cam" };
>>> PNAME(mout_group14_5800_p) = { "dout_aclk550_cam", "dout_sclk_sw" };
>>> PNAME(mout_group15_5800_p) = { "dout_osc_div", "mout_sw_aclk550_cam"
>>> };
>>> PNAME(mout_group16_5800_p) = { "dout_osc_div", "mout_mau_epll_clk" };
>>> +PNAME(mout_mx_mspll_ccore_phy_p) = { "sclk_bpll", "mout_sclk_dpll",
>>> + "mout_sclk_mpll", "ff_dout_spll2",
>>> + "mout_sclk_spll", "mout_sclk_epll"};
>>> +
>>
>> Remove unneeded extra blank line.
> OK
>>
>>>
>>> /* fixed rate clocks generated outside the soc */
>>> static struct samsung_fixed_rate_clock
>>> @@ -450,7 +458,7 @@ static const struct samsung_fixed_factor_clock
>>> static const struct samsung_fixed_factor_clock
>>> exynos5800_fixed_factor_clks[] __initconst = {
>>> FFACTOR(0, "ff_dout_epll2", "mout_sclk_epll", 1, 2, 0),
>>> - FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
>>> + FFACTOR(CLK_FF_DOUT_SPLL2, "ff_dout_spll2", "mout_sclk_spll", 1, 2,
>>> 0),
>>> };
>>>
>>> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst =
>>> {
>>> @@ -472,11 +480,14 @@ static const struct samsung_mux_clock
>>> exynos5800_mux_clks[] __initconst = {
>>> MUX(0, "mout_aclk300_disp1", mout_group5_5800_p, SRC_TOP2, 24, 2),
>>> MUX(0, "mout_aclk300_gscl", mout_group5_5800_p, SRC_TOP2, 28, 2),
>>>
>>> + MUX(CLK_MOUT_MX_MSPLL_CCORE_PHY, "mout_mx_mspll_ccore_phy",
>>> + mout_mx_mspll_ccore_phy_p, SRC_TOP7, 0, 3),
>>> +
>>> MUX(CLK_MOUT_MX_MSPLL_CCORE, "mout_mx_mspll_ccore",
>>> - mout_mx_mspll_ccore_p, SRC_TOP7, 16, 2),
>>> + mout_mx_mspll_ccore_p, SRC_TOP7, 16, 3),
>>> MUX_F(CLK_MOUT_MAU_EPLL, "mout_mau_epll_clk",
>>> mout_mau_epll_clk_5800_p,
>>> SRC_TOP7, 20, 2, CLK_SET_RATE_PARENT, 0),
>>> - MUX(0, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
>>> + MUX(CLK_SCLK_BPLL, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
>>> MUX(0, "mout_epll2", mout_epll2_5800_p, SRC_TOP7, 28, 1),
>>>
>>> MUX(0, "mout_aclk550_cam", mout_group3_5800_p, SRC_TOP8, 16, 3),
>>> @@ -648
Re: [PATCH v2 0/2] drivers: devfreq: fix and optimize workqueue mechanism
Hi Lukasz, On 19. 2. 12. 오전 12:30, Lukasz Luba wrote: > This patch set changes workqueue related features in devfreq framework. > First patch switches to delayed work instead of deferred. > The second switches to regular system work and deletes custom 'devfreq'. > > Using deferred work in this context might harm the system performance. > When the CPU enters idle, deferred work is not fired. The devfreq device's > utilization does not have to be connected with a particular CPU. > The drivers for GPUs, Network on Chip, cache L3 rely on devfreq governor. > They all are missing opportunity to check the HW state and react when > the deferred work is not fired. > A corner test case, when Dynamic Memory Controller is utilized by CPUs running > on full speed, might show x5 worse performance if the crucial CPU is in idle. The devfreq framework keeps the balancing between performance and power-consumption. It is wrong to focus on only either performance or power. This cover-letter focus on the only performance without any power-consumption disadvantages. It is easy to raise the performance with short sampling rate with polling modes. To get the performance, it is good as short as possible of period. Sometimes, when cpu is idle, the device might require the busy state. It is very difficult to catch the always right timing between them. Also, this patch cannot prevent the unneeded wakeup from idle state. Apparently, it only focuses on performance without considering the power-consumption disadvantage. In the embedded device, the power-consumption is very important point. We can not ignore the side effect. Always, I hope to improve the devfreq framwork more that older. But, frankly, it is difficult to agree because it only consider the performance without considering the side-effect. The power management framework always have to consider the power-consumption issue. This point is always true. > > Changes: > v2: > - single patch split into two > - added cover letter > > link for the previous version and discussion: > https://marc.info/?l=linux-pm=154904631226997=2 > > Regards, > Lukasz Luba > > Lukasz Luba (2): > drivers: devfreq: change devfreq workqueue mechanism > drivers: devfreq: change deferred work into delayed > > drivers/devfreq/devfreq.c | 27 +++-------- > 1 file changed, 7 insertions(+), 20 deletions(-) > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 3/3] devfreq: add mediatek cci devfreq
_dev, "proc");
> + ret = PTR_ERR_OR_ZERO(cci_devdata->proc_reg);
> + if (ret) {
> + if (ret == -EPROBE_DEFER)
> + pr_err("cci regulator not ready, retry\n");
ditto.
> + else
> + pr_err("no regulator for cci: %d\n", ret);
How about changing the log like below?
"failed to get regulator for CCI"
> +
> + goto out_free_resources;
> + }
> +
> + platform_set_drvdata(pdev, cci_devdata);
> +
> + /* create cci_devfreq and add to cci device.
> + * governor is voltage_monitor.
> + * governor will get platform_device data to make decision.
> + */
I think that you don't need to explain the kind of governor and how to
decide the next frequency by governor. It is enough to call the
devm_devfreq_add_device.
> + cci_devdata->devfreq = devm_devfreq_add_device(cci_dev,
> +_devfreq_profile,
> +"voltage_monitor",
> +NULL);
> +
> + nb->notifier_call = cci_devfreq_regulator_notifier;
> + regulator_register_notifier(cci_devdata->proc_reg,
> + nb);
As I commented, regulator_register_notifier() should be handled in
event_handler function.
> +
> + return 0;
> +
> +out_free_resources:
> + if (!IS_ERR(cci_devdata->cci_clk))
> + clk_put(cci_devdata->cci_clk);
> + if (!IS_ERR(cci_devdata->proc_reg))
> + regulator_put(cci_devdata->proc_reg);
> +
> + return ret;
> +}
> +
> +static const struct of_device_id mediatek_cci_devfreq_of_match[] = {
> + { .compatible = "mediatek,mt8183-cci" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, mediatek_cci_devfreq_of_match);
> +
> +static struct platform_driver cci_devfreq_driver = {
> + .probe = mtk_cci_devfreq_probe,
> + .driver = {
> + .name = "mediatek-cci-devfreq",
> + .of_match_table = mediatek_cci_devfreq_of_match,
> + },
> +};
> +
> +static int __init mtk_cci_devfreq_init(void)
> +{
> + int ret = 0;
> +
> + ret = devfreq_add_governor(_cci_devfreq_governor);
> + if (ret) {
> + pr_err("%s: failed to add governor: %d\n", __func__, ret);
> + return ret;
> + }
> +
> + ret = platform_driver_register(_devfreq_driver);
> + if (ret)
> + devfreq_remove_governor(_cci_devfreq_governor);
> +
> + return ret;
> +}
> +module_init(mtk_cci_devfreq_init)
> +
> +static void __exit mtk_cci_devfreq_exit(void)
> +{
> + int ret = 0;
> +
> + platform_driver_unregister(_devfreq_driver);
> +
> + ret = devfreq_remove_governor(_cci_devfreq_governor);
> + if (ret)
> + pr_err("%s: failed to remove governor: %d\n", __func__, ret);
> +}
> +module_exit(mtk_cci_devfreq_exit)
> +
> +MODULE_LICENSE("GPL v2");
nitpick. better to move it under MODULE_AUTHOR("")
> +MODULE_DESCRIPTION("Mediatek CCI devfreq driver");
> +MODULE_AUTHOR("andrew-sh.cheng");
Add full name and email as following:
- MODULE_AUTHOR("Andrew-sh.Cheng "
> +
>
Remove unneeded blank line.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 2/3] dt-bindings: devfreq: add compatible for mt8183 cci devfreq
Hi Andrew-sh.Cheng,
On 19. 1. 29. 오후 3:35, Andrew-sh Cheng wrote:
> From: "Andrew-sh.Cheng"
>
> This adds dt-binding documentation of cci devfreq
> for Mediatek MT8183 SoC platform.
>
> Signed-off-by: Andrew-sh.Cheng
> ---
> .../bindings/devfreq/mt8183-cci-devfreq.txt | 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt
> b/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt
> new file mode 100644
> index 000..e2b61cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/mt8183-cci-devfreq.txt
> @@ -0,0 +1,19 @@
> +* Mediatek CCI frequency device
You have to add more detailed what to do on this driver.
Also, please add the full alphabet for CCI.
> +
> +Required properties:
> +- compatible: should contain "mediatek,mt8183-cci" for cci devfreq
Usually, dt-binding document only specifies h/w information
and how to bind device. 'devfreq' is the word of linux-side.
It means that 'devfreq' cannot indicate the any h/w device.
You should use the h/w device information and word of CCI for writing
the dt-binding document without linux-side word like devfreq.
For example,
- cci devfreq -> frequency scaling of CCI
> +
Remove unneeded blank line.
> +- clocks: for cci devfreq
ditto of 'devfreq' word.
> +
ditto of blank line
> +- clock-names: for cci devfreq driver to reference
ditto of 'devfreq' word.
> +
ditto of blank line
> +- operating-points-v2: for cci devfreq opp table
ditto of 'devfreq' word.
> +
> +Example:
> + cci: cci {
> + compatible = "mediatek,cci";
> + clocks = < CLK_APMIXED_CCIPLL>;
> + clock-names = "cci_clock";
> + operating-points-v2 = <_opp>;
> + };
> +
>
This document is missing the 'regulator' property. Please add it
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] clk: samsung: s3c2443: Mark expected switch fall-through
Hi Gustavo, On 19. 2. 12. 오전 3:15, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > This patch fixes the following warnings: > > drivers/clk/samsung/clk-s3c2443.c: In function ‘s3c2443_common_clk_init’: > drivers/clk/samsung/clk-s3c2443.c:390:3: warning: this statement may fall > through [-Wimplicit-fallthrough=] >samsung_clk_register_alias(ctx, s3c2450_aliases, >^~~~ > ARRAY_SIZE(s3c2450_aliases)); > > drivers/clk/samsung/clk-s3c2443.c:393:2: note: here > case S3C2416: > ^~~~ > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > Notice that, in this particular case, the code comment is modified > in accordance with what GCC is expecting to find. > > This patch is part of the ongoing efforts to enable > -Wimplicit-fallthrough. Except for level 5 of -Wimplicit-fallthrough, level 4 is more strict to show the warnings. Why don't you support level 4 for -Wimplicit-fallthrough? I think that you want to fix for -Wimplicit-fallthrough warning, you better to support level 4. What do you think? > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/clk/samsung/clk-s3c2443.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clk/samsung/clk-s3c2443.c > b/drivers/clk/samsung/clk-s3c2443.c > index 884067e4f1a1..f38f0e24e3b6 100644 > --- a/drivers/clk/samsung/clk-s3c2443.c > +++ b/drivers/clk/samsung/clk-s3c2443.c > @@ -389,7 +389,7 @@ void __init s3c2443_common_clk_init(struct device_node > *np, unsigned long xti_f, > ARRAY_SIZE(s3c2450_gates)); > samsung_clk_register_alias(ctx, s3c2450_aliases, > ARRAY_SIZE(s3c2450_aliases)); > - /* fall through, as s3c2450 extends the s3c2416 clocks */ > + /* fall through - as s3c2450 extends the s3c2416 clocks */ > case S3C2416: > samsung_clk_register_div(ctx, s3c2416_dividers, > ARRAY_SIZE(s3c2416_dividers)); > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v3 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi Lukasz,
On 19. 2. 11. 오후 7:21, Lukasz Luba wrote:
> Hi Chanwoo,
>
> On 2/3/19 8:54 AM, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> 2019년 2월 1일 (금) 오후 11:22, Lukasz Luba 님이 작성:
>>
>>>
>>> Hi Chanwoo,
>>>
>>> On 2/1/19 9:44 AM, Chanwoo Choi wrote:
>>>> Hi,
>>>>
>>>> On 19. 1. 31. 오후 5:49, Lukasz Luba wrote:
>>>>> Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory
>>>>> Controller frequencies for driver's DRAM timings.
>>>>>
>>>>> CC: Sylwester Nawrocki
>>>>> CC: Chanwoo Choi
>>>>> CC: Michael Turquette
>>>>> CC: Stephen Boyd
>>>>> CC: Kukjin Kim
>>>>> CC: Krzysztof Kozlowski
>>>>> CC: linux-samsung-...@vger.kernel.org
>>>>> CC: linux-...@vger.kernel.org
>>>>> CC: linux-arm-ker...@lists.infradead.org
>>>>> CC: linux-kernel@vger.kernel.org
>>>>> Signed-off-by: Lukasz Luba
>>>>> ---
>>>>>drivers/clk/samsung/clk-exynos5420.c | 15 ++-
>>>>>1 file changed, 14 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>>>>> b/drivers/clk/samsung/clk-exynos5420.c
>>>>> index 3e87421..8bf9579 100644
>>>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>>>> @@ -1325,6 +1325,19 @@ static const struct samsung_pll_rate_table
>>>>> exynos5420_pll2550x_24mhz_tbl[] __ini
>>>>> PLL_35XX_RATE(24 * MHZ, 2, 200, 3, 3),
>>>>>};
>>>>>
>>>>> +static const struct samsung_pll_rate_table exynos5422_bpll_rate_table[]
>>>>> = {
>>>>> +PLL_35XX_RATE(24 * MHZ, 93300, 311, 4, 1),
>>>>> +PLL_35XX_RATE(24 * MHZ, 82500, 275, 4, 1),
>>>>> +PLL_35XX_RATE(24 * MHZ, 72800, 182, 3, 1),
>>>>> +PLL_35XX_RATE(24 * MHZ, 63300, 211, 4, 1),
>>>>> +PLL_35XX_RATE(24 * MHZ, 54300, 181, 2, 2),
>>>>> +PLL_35XX_RATE(24 * MHZ, 41300, 413, 6, 2),
>>>>> +PLL_35XX_RATE(24 * MHZ, 27500, 275, 3, 3),
>>>>> +PLL_35XX_RATE(24 * MHZ, 20600, 206, 3, 3),
>>>>> +PLL_35XX_RATE(24 * MHZ, 16500, 110, 2, 3),
>>>>> +PLL_35XX_RATE(24 * MHZ, 13800, 184, 2, 4),
>>>>
>>>> Except for 825Mhz, I can't find the target frequency
>>>> on Exynos5422 TRM document. Usually, Exynos TRM specified
>>>> the supported stable clocks. It means that undefined clocks
>>>> are not stable as I knew. Where do you find them?
>>>>
>>>> When I calculated the PLL frequency with PMS value, it is correct.
>>>> But, just we need to check the reference of undefined clocks on TRM
>>>> in order to guarantee the stable operation.
>>> They values live in vendor code for Android.
>>> I have tested the DMC & DDR with these ratios in stress scenarios
>>> for a few days and it was stable.
>>
>> If possible, please share the url of original vendor code.
> Here is the vendor code for the BPLL values:
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/clk/samsung/clk-exynos5422.c#L2026
Thanks for sharing.
bpll_rate_table has two different supported frequency
according to exynos5422 revision as following:
But, this patch only has only one frequency set
for CONFIG_SOC_EXYNOS5422_REV_0.
Could you guarantee that all Exynos5422-based Odroid-xu3 board
has CONFIG_SOC_EXYNOS5422_REV_0 ersion? If not guaranteed,
some board might be fault because of using the unsupported
frequencies.
It is dangerous and unstable to use the unsupported frequencies to SoC.
struct samsung_pll_rate_table bpll_rate_table[] = {
/* rate p m s k */
#ifdef CONFIG_SOC_EXYNOS5422_REV_0
{ 93300U, 4, 311,1, 0},
{ 92500U, 4, 307,1, 0},
{ 82500U, 4, 275,1, 0},
{ 72800U, 3, 182,1, 0},
{ 63300U, 4, 211,1, 0},
{ 54300U, 2, 181,2, 0},
{ 41300U, 6, 413,2, 0},
{ 27500U, 3, 275,3, 0},
{ 20600U, 3, 206,3, 0},
{ 16500U, 2, 110,3, 0},
{ 13800U, 2, 184,4, 0},
#else
{ 93300U, 4, 311,1, 0},
{ 8U, 3, 200,1, 0},
{ 73300U, 2, 122,1, 0},
{
[GIT PULL] extcon next for v5.1
Dear Greg, This is extcon-next pull request for v5.1. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-5.1 for you to fetch changes up to 3dfed89512d3b65f6f092cfaaee53b0698bbf75e: extcon: ptn5150: Fix return value check in ptn5150_i2c_probe() (2019-02-11 17:21:38 +0900) Vijai Kumar K (1): extcon: Add support for ptn5150 extcon driver Wei Yongjun (1): extcon: ptn5150: Fix return value check in ptn5150_i2c_probe() .../devicetree/bindings/extcon/extcon-ptn5150.txt | 27 ++ drivers/extcon/Kconfig | 8 + drivers/extcon/Makefile| 1 + drivers/extcon/extcon-ptn5150.c| 339 + 4 files changed, 375 insertions(+) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt create mode 100644 drivers/extcon/extcon-ptn5150.c
Re: [PATCH v4 5/8] dt-bindings: devfreq: add Exynos5422 DMC device description
gt;, > + < CLK_FOUT_BPLL>, > + < CLK_MOUT_BPLL>, > + < CLK_SCLK_BPLL>, > + < CLK_MOUT_MX_MSPLL_CCORE>, > + < CLK_MOUT_MX_MSPLL_CCORE_PHY>, > + < CLK_MOUT_MCLK_CDREX>, > + < CLK_DOUT_CLK2X_PHY0>, > + < CLK_CLKM_PHY0>, > + < CLK_CLKM_PHY1>; > + clock-names = "fout_spll", > + "mout_sclk_spll", > + "ff_dout_spll2", > + "fout_bpll", > + "mout_bpll", > + "sclk_bpll", > + "mout_mx_mspll_ccore", > + "mout_mx_mspll_ccore_phy", > + "mout_mclk_cdrex", > + "dout_clk2x_phy0", > + "clkm_phy0", > + "clkm_phy1"; > + > + status = "okay"; > + devfreq-events = <_dmc0_0>, <_dmc0_1>, > + <_dmc1_0>, <_dmc1_1>; > + }; > + > + > diff --git a/MAINTAINERS b/MAINTAINERS > index e81dfbf..ab0d8a5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3316,6 +3316,7 @@ L:linux...@vger.kernel.org > L: linux-samsung-...@vger.kernel.org > S: Maintained > F: drivers/devfreq/exynos5422-dmc.c > +F: Documentation/devicetree/bindings/devfreq/exynos5422-dmc.txt > > BUSLOGIC SCSI DRIVER > M: Khalid Aziz > -- > 2.7.4 > -- Best Regards, Chanwoo Choi
Re: [PATCH v4 4/8] drivers: devfreq: add DMC driver for Exynos5422
Hi Lukasz, As I already commented on the other patch, please don't send next version patchset until finishing the discussion. 2019년 2월 2일 (토) 오전 2:42, Lukasz Luba 님이 작성: > > This patch adds driver for Exynos5422 Dynamic Memory Controller. > The driver provides support for dynamic frequency and voltage scaling for > DMC and DRAM. It supports changing timings of DRAM running with different > frequency. > The patch also contains needed MAINTAINERS file update. > > Signed-off-by: Lukasz Luba > --- > MAINTAINERS |7 + > drivers/devfreq/Kconfig | 13 + > drivers/devfreq/Makefile |1 + > drivers/devfreq/exynos5422-dmc.c | 1274 > ++ > 4 files changed, 1295 insertions(+) > create mode 100644 drivers/devfreq/exynos5422-dmc.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9f64f8d..e81dfbf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3310,6 +3310,13 @@ S: Maintained > F: drivers/devfreq/exynos-bus.c > F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt > > +DMC FREQUENCY DRIVER FOR SAMSUNG EXYNOS5422 > +M: Lukasz Luba > +L: linux...@vger.kernel.org > +L: linux-samsung-...@vger.kernel.org > +S: Maintained > +F: drivers/devfreq/exynos5422-dmc.c > + > BUSLOGIC SCSI DRIVER > M: Khalid Aziz > L: linux-s...@vger.kernel.org > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig > index 6a172d3..2a876ad 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -113,6 +113,19 @@ config ARM_RK3399_DMC_DEVFREQ >It sets the frequency for the memory controller and reads the > usage counts >from hardware. > > +config ARM_EXYNOS5422_DMC_DEVFREQ Move it under ARM_EXYNOS_BUS_DEVFREQ alphabetically. > + tristate "ARM EXYNOS5422 DMC DEVFREQ Driver" > + depends on ARCH_EXYNOS || COMPILE_TEST > + select DEVFREQ_GOV_SIMPLE_ONDEMAND The exynos5422-dmc.c driver use the 'userspace' governor. Why do you add the DEVFREQ_GOV_SIMPLE_ONDEMAND dependency instead of GOV_USERSPACE? Even if you use userspace governor with devfreq_add_device() you added the 'struct devfreq_dev_profile' for simple_ondemand governor. Why don't you use 'simple_ondemand' governor as the default governor? This patch description doesn't contain the something of simple_ondemand governor. > + select DEVFREQ_GOV_PASSIVE The exynos5422-dmc.c doesn't use 'passive' governor. Maybe you just copied from ARM_EXYNOS_BUS_DEVFREQ's config. Remove this dependency. > + select PM_DEVFREQ_EVENT > + select PM_OPP > + help > + This adds DEVFREQ driver for Exynos5422 DMC (Dynamic Memory > Controller). > + The driver provides support for Dynamic Voltage and Frequency > Scaling in > + DMC and DRAM. It also supports changing timings of DRAM running with > + different frequency. > + > source "drivers/devfreq/event/Kconfig" > > endif # PM_DEVFREQ > diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile > index 32b8d4d..d011835 100644 > --- a/drivers/devfreq/Makefile > +++ b/drivers/devfreq/Makefile > @@ -11,6 +11,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o > obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o > obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o > obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o > +obj-$(CONFIG_ARM_EXYNOS5422_DMC_DEVFREQ) += exynos5422-dmc.o Move it under CONFIG_ARM_EXYNOS_BUS_DEVFREQ alphabetically. > > # DEVFREQ Event Drivers > obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/ > diff --git a/drivers/devfreq/exynos5422-dmc.c > b/drivers/devfreq/exynos5422-dmc.c > new file mode 100644 > index 000..8a19281 > --- /dev/null > +++ b/drivers/devfreq/exynos5422-dmc.c > @@ -0,0 +1,1274 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 Samsung Electronics Co., Ltd. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRIVER_DESC "Driver for Exynos5422 Dynamic Memory Controller dynamic > frequency and voltage change" Don't need to define the separate constant because MODULE_DESCRIPTION only use it. You can describe it with MODULE_DESCRIPTION. Remove the separate definition. > + > +#define EXYNOS5422_REV_0 (0x1) > +#define EXYNOS5422_PROD_REV_MAIN_MASK (0xf0) > +#define EXYNOS5422_PROD_REV_SUB_MASK (0xf) The above three definitions are never used on this driver. > + > +#define EXYNOS5_DREXI_TIMINGAREF (0x0030) > +#define EXYNOS5_DREXI_TIMINGROW0 (0x0034) > +#define EXYNOS5_DREXI_TIMINGDATA0 (0x0038) > +#define EXYNOS5_DREXI_TIMINGPOWER0 (0x003C) > +#define EXYNOS5_DREXI_TIMINGROW1 (0x00E4) > +#define EXYNOS5_DREXI_TIMINGDATA1 (0x00E8) > +#define EXYNOS5_DREXI_TIMINGPOWER1 (0x00EC) > + > +#define
Re: [PATCH v4 2/8] clk: samsung: add new clocks for DMC for Exynos5422 SoC
MUX(0, "mout_sclk_rpll", mout_rpll_p, SRC_TOP6, 16, 1),
> MUX_F(CLK_MOUT_EPLL, "mout_sclk_epll", mout_epll_p, SRC_TOP6, 20, 1,
> @@ -817,6 +828,8 @@ static const struct samsung_div_clock exynos5x_div_clks[]
> __initconst = {
> DIV(CLK_DOUT_CLK2X_PHY0, "dout_clk2x_phy0", "dout_sclk_cdrex",
> DIV_CDREX0, 3, 5),
>
> + DIV(0, "dout_pclk_drex0", "dout_cclk_drex0", DIV_CDREX0, 28, 3),
Before applied this patch, on line 809, DIV_CDREX0[28:30] was already
defined with "dout_pclk_cdrex" gate clock name. Why do you redefine it
with same register/same bit with the different clock name? The clock
driver have to get only unique clock for the same register/same bit
information.
808 /* CDREX Block */
809 DIV(CLK_DOUT_PCLK_CDREX, "dout_pclk_cdrex",
"dout_aclk_cdrex1",
810 DIV_CDREX0, 28, 3),
And also, you don't use "dout_pclk_drex0" defined by you for
CLK_ACLK_PPMU_DREX* gate clock on below. Instead, you use the already
defined 'dout_pclk_cdrex' as I commented.
> +
> DIV(CLK_DOUT_PCLK_CORE_MEM, "dout_pclk_core_mem", "mout_mclk_cdrex",
> DIV_CDREX1, 8, 3),
>
> @@ -1170,6 +1183,31 @@ static const struct samsung_gate_clock
> exynos5x_gate_clks[] __initconst = {
> GATE_TOP_SCLK_ISP, 12, CLK_SET_RATE_PARENT, 0),
>
> GATE(CLK_G3D, "g3d", "mout_user_aclk_g3d", GATE_IP_G3D, 9, 0, 0),
> +
Add the following comment for the readability in order to sustain the
consistency of this driver.
/* CDREX Block */ or /* CDREX */
> + GATE(CLK_CLKM_PHY0, "clkm_phy0", "dout_sclk_cdrex",
> + GATE_BUS_CDREX0, 0, 0, 0),
> + GATE(CLK_CLKM_PHY1, "clkm_phy1", "dout_sclk_cdrex",
> + GATE_BUS_CDREX0, 1, 0, 0),
> + GATE(0, "mx_mspll_ccore_phy", "mout_mx_mspll_ccore_phy",
> + SRC_MASK_TOP7, 0, CLK_IGNORE_UNUSED, 0),
> +
> + GATE(CLK_ACLK_PPMU_DREX0_0, "aclk_ppmu_drex0_0", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 15, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_ACLK_PPMU_DREX0_1, "aclk_ppmu_drex0_1", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 14, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_ACLK_PPMU_DREX1_0, "aclk_ppmu_drex1_0", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 13, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_ACLK_PPMU_DREX1_1, "aclk_ppmu_drex1_1", "dout_aclk_cdrex1",
> + GATE_BUS_CDREX1, 12, CLK_IGNORE_UNUSED, 0),
You better to move the gate clock of GATE_BUS_CDREX[15:12] under the
gate clock of GATE_BUS_CDREX[29:26]
for the decending order because you defined them as the decending order.
> +
> + GATE(CLK_PCLK_PPMU_DREX0_0, "pclk_ppmu_drex0_0", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 29, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_PCLK_PPMU_DREX0_1, "pclk_ppmu_drex0_1", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 28, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_PCLK_PPMU_DREX1_0, "pclk_ppmu_drex1_0", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 27, CLK_IGNORE_UNUSED, 0),
> + GATE(CLK_PCLK_PPMU_DREX1_1, "pclk_ppmu_drex1_1", "dout_pclk_cdrex",
> + GATE_BUS_CDREX1, 26, CLK_IGNORE_UNUSED, 0),
> };
>
> static const struct samsung_div_clock exynos5x_disp_div_clks[] __initconst =
> {
> --
> 2.7.4
>
--
Best Regards,
Chanwoo Choi
Re: [PATCH v3 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi Lukasz,
2019년 2월 1일 (금) 오후 11:22, Lukasz Luba 님이 작성:
>
> Hi Chanwoo,
>
> On 2/1/19 9:44 AM, Chanwoo Choi wrote:
> > Hi,
> >
> > On 19. 1. 31. 오후 5:49, Lukasz Luba wrote:
> >> Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory
> >> Controller frequencies for driver's DRAM timings.
> >>
> >> CC: Sylwester Nawrocki
> >> CC: Chanwoo Choi
> >> CC: Michael Turquette
> >> CC: Stephen Boyd
> >> CC: Kukjin Kim
> >> CC: Krzysztof Kozlowski
> >> CC: linux-samsung-...@vger.kernel.org
> >> CC: linux-...@vger.kernel.org
> >> CC: linux-arm-ker...@lists.infradead.org
> >> CC: linux-kernel@vger.kernel.org
> >> Signed-off-by: Lukasz Luba
> >> ---
> >> drivers/clk/samsung/clk-exynos5420.c | 15 ++-
> >> 1 file changed, 14 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> >> b/drivers/clk/samsung/clk-exynos5420.c
> >> index 3e87421..8bf9579 100644
> >> --- a/drivers/clk/samsung/clk-exynos5420.c
> >> +++ b/drivers/clk/samsung/clk-exynos5420.c
> >> @@ -1325,6 +1325,19 @@ static const struct samsung_pll_rate_table
> >> exynos5420_pll2550x_24mhz_tbl[] __ini
> >> PLL_35XX_RATE(24 * MHZ, 2, 200, 3, 3),
> >> };
> >>
> >> +static const struct samsung_pll_rate_table exynos5422_bpll_rate_table[] =
> >> {
> >> +PLL_35XX_RATE(24 * MHZ, 93300, 311, 4, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 82500, 275, 4, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 72800, 182, 3, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 63300, 211, 4, 1),
> >> +PLL_35XX_RATE(24 * MHZ, 54300, 181, 2, 2),
> >> +PLL_35XX_RATE(24 * MHZ, 41300, 413, 6, 2),
> >> +PLL_35XX_RATE(24 * MHZ, 27500, 275, 3, 3),
> >> +PLL_35XX_RATE(24 * MHZ, 20600, 206, 3, 3),
> >> +PLL_35XX_RATE(24 * MHZ, 16500, 110, 2, 3),
> >> +PLL_35XX_RATE(24 * MHZ, 13800, 184, 2, 4),
> >
> > Except for 825Mhz, I can't find the target frequency
> > on Exynos5422 TRM document. Usually, Exynos TRM specified
> > the supported stable clocks. It means that undefined clocks
> > are not stable as I knew. Where do you find them?
> >
> > When I calculated the PLL frequency with PMS value, it is correct.
> > But, just we need to check the reference of undefined clocks on TRM
> > in order to guarantee the stable operation.
> They values live in vendor code for Android.
> I have tested the DMC & DDR with these ratios in stress scenarios
> for a few days and it was stable.
If possible, please share the url of original vendor code.
>
> >
> > Remove 933/138Mhz because exynos5433-dmc.c doesn't use 933Mhz and 138Mhz
> > and also Exynos5422 TRM doesn't define 933/138Mhz on pll table.
> OK, I will remove them.
> >
> >> +};
> >> +
> >> static const struct samsung_pll_rate_table exynos5420_epll_24mhz_tbl[] =
> >> {
> >> PLL_36XX_RATE(24 * MHZ, 6U, 100, 2, 1, 0),
> >> PLL_36XX_RATE(24 * MHZ, 4U, 200, 3, 2, 0),
> >> @@ -1467,7 +1480,7 @@ static void __init exynos5x_clk_init(struct
> >> device_node *np,
> >> exynos5x_plls[apll].rate_table =
> >> exynos5420_pll2550x_24mhz_tbl;
> >> exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
> >> exynos5x_plls[kpll].rate_table =
> >> exynos5420_pll2550x_24mhz_tbl;
> >> - exynos5x_plls[bpll].rate_table =
> >> exynos5420_pll2550x_24mhz_tbl;
> >> +exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
> >
> > Exynos5422 used the same PLL table for apll, kpll, bpll and so on.
> > You don't need to make the separate pll table. Just add new entries
> > to exynos5420_pll2550x_24mhz_tbl table.
> OK, I will extend the exynos5420_pll2550x_24mhz_tbl table.
>
> In v4 patch set, it will be fixed.
>
> Regards,
> Lukasz
> >
> >> }
> >>
> >> samsung_clk_register_pll(ctx, exynos5x_plls,
> >> ARRAY_SIZE(exynos5x_plls),
> >>
> >
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 2/8] clk: samsung: add new clocks for DMC for Exynos5422 SoC
Hi,
There are some wrong comments by me. Sorry for confusion.
On 19. 2. 1. 오후 5:07, Chanwoo Choi wrote:
> Hi,
>
> When I reviewed this patch, the almost changes are wrong.
> Frankly, I can't believe that you had tested and verified it
> on real board. Please check my comments.
> If I misunderstood, please let me know.
>
> On 19. 1. 31. 오후 5:49, Lukasz Luba wrote:
>> This patch provides support for clocks needed for Dynamic Memory Controller
>> in Exynos5422 SoC. It adds CDREX base register addresses, new DIV, MUX and
>> GATE entries.
>>
>> CC: Sylwester Nawrocki
>> CC: Chanwoo Choi
>> CC: Michael Turquette
>> CC: Stephen Boyd
>> CC: Kukjin Kim
>> CC: Krzysztof Kozlowski
>> CC: linux-samsung-...@vger.kernel.org
>> CC: linux-...@vger.kernel.org
>> CC: linux-arm-ker...@lists.infradead.org
>> CC: linux-kernel@vger.kernel.org
>> Signed-off-by: Lukasz Luba
>> ---
>> drivers/clk/samsung/clk-exynos5420.c | 48
>> +---
>> 1 file changed, 44 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 34cce3c..3e87421 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -132,6 +132,8 @@
>> #define BPLL_LOCK 0x20010
>> #define BPLL_CON0 0x20110
>> #define SRC_CDREX 0x20200
>> +#define GATE_BUS_CDREX0 0x20700
>> +#define GATE_BUS_CDREX1 0x20704
>> #define DIV_CDREX0 0x20500
>> #define DIV_CDREX1 0x20504
>> #define KPLL_LOCK 0x28000
>> @@ -248,6 +250,8 @@ static const unsigned long exynos5x_clk_regs[]
>> __initconst = {
>> DIV_CDREX1,
>> SRC_KFC,
>> DIV_KFC0,
>> +GATE_BUS_CDREX0,
>> +GATE_BUS_CDREX1,
>> };
>>
>> static const unsigned long exynos5800_clk_regs[] __initconst = {
>> @@ -425,6 +429,10 @@ PNAME(mout_group13_5800_p) = { "dout_osc_div",
>> "mout_sw_aclkfl1_550_cam" };
>> PNAME(mout_group14_5800_p) = { "dout_aclk550_cam", "dout_sclk_sw" };
>> PNAME(mout_group15_5800_p) = { "dout_osc_div", "mout_sw_aclk550_cam" };
>> PNAME(mout_group16_5800_p) = { "dout_osc_div", "mout_mau_epll_clk" };
>> +PNAME(mout_mx_mspll_ccore_phy_p) = { "sclk_bpll", "mout_dpll_ctrl",
>> +"mout_mpll_ctrl", "ff_dout_spll2",
>> +"mout_sclk_spll"};
>
> - mout_dpll_ctrl was not defined. This patch doesn't define it.
> - mout_mpll_ctrl was not defined. ditto.
> - ff_dout_spll2 was only registered when SOC is EXYNOS5800.
> It meant that ff_dout_spll2 was not registered on exynos5422 board.
>
> It is wrong patch. You would have not checked the parent clocks
> except for sclk_bpll.
>
> Also,
> In the exynos5422 datasheet, MUX_MX_MSPLL_CCORE_PHY_SEL is possible
> having the six parents as following:
> - sclk_bpll
> - sclk_dpll
> - sclk_mpll
> - sclk_spll2
> - sclk_spll
> - sclk_epll
>
> Why do you missing last 'sclk_epll'?
>
>
>> +
>>
>> /* fixed rate clocks generated outside the soc */
>> static struct samsung_fixed_rate_clock
>> @@ -450,7 +458,7 @@ static const struct samsung_fixed_factor_clock
>> static const struct samsung_fixed_factor_clock
>> exynos5800_fixed_factor_clks[] __initconst = {
>> FFACTOR(0, "ff_dout_epll2", "mout_sclk_epll", 1, 2, 0),
>> -FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
>> +FFACTOR(CLK_FF_DOUT_SPLL2, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
>
> It doesn't affect the Exynos5422 because exynos5800_fixed_factor_clks[]
> is registered when SOC is EXYNOS5800. Exynos5422 board cannot use this clock.
It is my fault. Please ignore this comment.
>
>> };
>>
>> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst = {
>> @@ -472,11 +480,14 @@ static const struct samsung_mux_clock
>> exynos5800_mux_clks[] __initconst = {
>> MUX(0, "mout_aclk300_disp1", mout_group5_5800_p, SRC_TOP2, 24, 2),
>> MUX(0, "mout_aclk300_gscl", mout_group5_5800_p, SRC_TOP2, 28, 2),
>>
>> +MUX(CLK_MOUT_MX_MSPLL_CCORE_PHY, "mout_mx_mspll_ccore_phy",
>> +mout_mx_mspll_ccore_phy_p, SRC_TOP7, 0, 3),
>> +
>
> Why do you modify the e
Re: [PATCH v3 3/8] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi,
On 19. 1. 31. 오후 5:49, Lukasz Luba wrote:
> Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory
> Controller frequencies for driver's DRAM timings.
>
> CC: Sylwester Nawrocki
> CC: Chanwoo Choi
> CC: Michael Turquette
> CC: Stephen Boyd
> CC: Kukjin Kim
> CC: Krzysztof Kozlowski
> CC: linux-samsung-...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 3e87421..8bf9579 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -1325,6 +1325,19 @@ static const struct samsung_pll_rate_table
> exynos5420_pll2550x_24mhz_tbl[] __ini
> PLL_35XX_RATE(24 * MHZ, 2, 200, 3, 3),
> };
>
> +static const struct samsung_pll_rate_table exynos5422_bpll_rate_table[] = {
> + PLL_35XX_RATE(24 * MHZ, 93300, 311, 4, 1),
> + PLL_35XX_RATE(24 * MHZ, 82500, 275, 4, 1),
> + PLL_35XX_RATE(24 * MHZ, 72800, 182, 3, 1),
> + PLL_35XX_RATE(24 * MHZ, 63300, 211, 4, 1),
> + PLL_35XX_RATE(24 * MHZ, 54300, 181, 2, 2),
> + PLL_35XX_RATE(24 * MHZ, 41300, 413, 6, 2),
> + PLL_35XX_RATE(24 * MHZ, 27500, 275, 3, 3),
> + PLL_35XX_RATE(24 * MHZ, 20600, 206, 3, 3),
> + PLL_35XX_RATE(24 * MHZ, 16500, 110, 2, 3),
> + PLL_35XX_RATE(24 * MHZ, 13800, 184, 2, 4),
Except for 825Mhz, I can't find the target frequency
on Exynos5422 TRM document. Usually, Exynos TRM specified
the supported stable clocks. It means that undefined clocks
are not stable as I knew. Where do you find them?
When I calculated the PLL frequency with PMS value, it is correct.
But, just we need to check the reference of undefined clocks on TRM
in order to guarantee the stable operation.
Remove 933/138Mhz because exynos5433-dmc.c doesn't use 933Mhz and 138Mhz
and also Exynos5422 TRM doesn't define 933/138Mhz on pll table.
> +};
> +
> static const struct samsung_pll_rate_table exynos5420_epll_24mhz_tbl[] = {
> PLL_36XX_RATE(24 * MHZ, 6U, 100, 2, 1, 0),
> PLL_36XX_RATE(24 * MHZ, 4U, 200, 3, 2, 0),
> @@ -1467,7 +1480,7 @@ static void __init exynos5x_clk_init(struct device_node
> *np,
> exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
> exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> - exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> + exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
Exynos5422 used the same PLL table for apll, kpll, bpll and so on.
You don't need to make the separate pll table. Just add new entries
to exynos5420_pll2550x_24mhz_tbl table.
> }
>
> samsung_clk_register_pll(ctx, exynos5x_plls, ARRAY_SIZE(exynos5x_plls),
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 2/8] clk: samsung: add new clocks for DMC for Exynos5422 SoC
Hi,
When I reviewed this patch, the almost changes are wrong.
Frankly, I can't believe that you had tested and verified it
on real board. Please check my comments.
If I misunderstood, please let me know.
On 19. 1. 31. 오후 5:49, Lukasz Luba wrote:
> This patch provides support for clocks needed for Dynamic Memory Controller
> in Exynos5422 SoC. It adds CDREX base register addresses, new DIV, MUX and
> GATE entries.
>
> CC: Sylwester Nawrocki
> CC: Chanwoo Choi
> CC: Michael Turquette
> CC: Stephen Boyd
> CC: Kukjin Kim
> CC: Krzysztof Kozlowski
> CC: linux-samsung-...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 48
> +---
> 1 file changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 34cce3c..3e87421 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -132,6 +132,8 @@
> #define BPLL_LOCK0x20010
> #define BPLL_CON00x20110
> #define SRC_CDREX0x20200
> +#define GATE_BUS_CDREX0 0x20700
> +#define GATE_BUS_CDREX1 0x20704
> #define DIV_CDREX0 0x20500
> #define DIV_CDREX1 0x20504
> #define KPLL_LOCK0x28000
> @@ -248,6 +250,8 @@ static const unsigned long exynos5x_clk_regs[]
> __initconst = {
> DIV_CDREX1,
> SRC_KFC,
> DIV_KFC0,
> + GATE_BUS_CDREX0,
> + GATE_BUS_CDREX1,
> };
>
> static const unsigned long exynos5800_clk_regs[] __initconst = {
> @@ -425,6 +429,10 @@ PNAME(mout_group13_5800_p) = { "dout_osc_div",
> "mout_sw_aclkfl1_550_cam" };
> PNAME(mout_group14_5800_p) = { "dout_aclk550_cam", "dout_sclk_sw" };
> PNAME(mout_group15_5800_p) = { "dout_osc_div", "mout_sw_aclk550_cam" };
> PNAME(mout_group16_5800_p) = { "dout_osc_div", "mout_mau_epll_clk" };
> +PNAME(mout_mx_mspll_ccore_phy_p) = { "sclk_bpll", "mout_dpll_ctrl",
> + "mout_mpll_ctrl", "ff_dout_spll2",
> + "mout_sclk_spll"};
- mout_dpll_ctrl was not defined. This patch doesn't define it.
- mout_mpll_ctrl was not defined. ditto.
- ff_dout_spll2 was only registered when SOC is EXYNOS5800.
It meant that ff_dout_spll2 was not registered on exynos5422 board.
It is wrong patch. You would have not checked the parent clocks
except for sclk_bpll.
Also,
In the exynos5422 datasheet, MUX_MX_MSPLL_CCORE_PHY_SEL is possible
having the six parents as following:
- sclk_bpll
- sclk_dpll
- sclk_mpll
- sclk_spll2
- sclk_spll
- sclk_epll
Why do you missing last 'sclk_epll'?
> +
>
> /* fixed rate clocks generated outside the soc */
> static struct samsung_fixed_rate_clock
> @@ -450,7 +458,7 @@ static const struct samsung_fixed_factor_clock
> static const struct samsung_fixed_factor_clock
> exynos5800_fixed_factor_clks[] __initconst = {
> FFACTOR(0, "ff_dout_epll2", "mout_sclk_epll", 1, 2, 0),
> - FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
> + FFACTOR(CLK_FF_DOUT_SPLL2, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
It doesn't affect the Exynos5422 because exynos5800_fixed_factor_clks[]
is registered when SOC is EXYNOS5800. Exynos5422 board cannot use this clock.
> };
>
> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst = {
> @@ -472,11 +480,14 @@ static const struct samsung_mux_clock
> exynos5800_mux_clks[] __initconst = {
> MUX(0, "mout_aclk300_disp1", mout_group5_5800_p, SRC_TOP2, 24, 2),
> MUX(0, "mout_aclk300_gscl", mout_group5_5800_p, SRC_TOP2, 28, 2),
>
> + MUX(CLK_MOUT_MX_MSPLL_CCORE_PHY, "mout_mx_mspll_ccore_phy",
> + mout_mx_mspll_ccore_phy_p, SRC_TOP7, 0, 3),
> +
Why do you modify the exynos5800_mux_clks instead of exynos5420_mux_clks
or exynos5x_mux_clks? In the coverletter this patch is for Exynos5422 board.
Did you test it?
> MUX(CLK_MOUT_MX_MSPLL_CCORE, "mout_mx_mspll_ccore",
> - mout_mx_mspll_ccore_p, SRC_TOP7, 16, 2),
> + mout_mx_mspll_ccore_p, SRC_TOP7, 16, 3),
ditto.
> MUX_F(CLK_MOUT_MAU_EPLL, "mout_mau_epll_clk", mout_mau_epll_clk_5800_p,
> SRC_TOP7, 20, 2, CLK_SET_RATE_PARENT, 0),
> - MUX(0, "sclk_bpll", mout_bpll_p, SRC_TOP7
Re: [PATCH v3 1/8] clk: samsung: add needed IDs for DMC clocks in Exynos5420
Hi, On 19. 1. 31. 오후 5:49, Lukasz Luba wrote: > Define new IDs for clocks used by Dynamic Memory Controller in > Exynos5422 SoC. > > CC: Sylwester Nawrocki > CC: Chanwoo Choi > CC: Rob Herring > CC: Mark Rutland > CC: Kukjin Kim > CC: Krzysztof Kozlowski > CC: linux-samsung-...@vger.kernel.org > CC: devicet...@vger.kernel.org > CC: linux-arm-ker...@lists.infradead.org > CC: linux-kernel@vger.kernel.org > Signed-off-by: Lukasz Luba > --- > include/dt-bindings/clock/exynos5420.h | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/include/dt-bindings/clock/exynos5420.h > b/include/dt-bindings/clock/exynos5420.h > index 355f469..1827a64 100644 > --- a/include/dt-bindings/clock/exynos5420.h > +++ b/include/dt-bindings/clock/exynos5420.h > @@ -60,6 +60,7 @@ > #define CLK_MAU_EPLL 159 > #define CLK_SCLK_HSIC_12M160 > #define CLK_SCLK_MPHY_IXTAL24161 > +#define CLK_SCLK_BPLL162 > > /* gate clocks */ > #define CLK_UART0257 > @@ -195,6 +196,16 @@ > #define CLK_ACLK432_CAM 518 > #define CLK_ACLK_FL1550_CAM 519 > #define CLK_ACLK550_CAM 520 > +#define CLK_CLKM_PHY0521 > +#define CLK_CLKM_PHY1522 > +#define CLK_ACLK_PPMU_DREX0_0523 > +#define CLK_ACLK_PPMU_DREX0_1524 > +#define CLK_ACLK_PPMU_DREX1_0525 > +#define CLK_ACLK_PPMU_DREX1_1526 > +#define CLK_PCLK_PPMU_DREX0_0527 > +#define CLK_PCLK_PPMU_DREX0_1528 > +#define CLK_PCLK_PPMU_DREX1_0529 > +#define CLK_PCLK_PPMU_DREX1_1530 > > /* mux clocks */ > #define CLK_MOUT_HDMI640 > @@ -217,6 +228,10 @@ > #define CLK_MOUT_EPLL657 > #define CLK_MOUT_MAU_EPLL658 > #define CLK_MOUT_USER_MAU_EPLL 659 > +#define CLK_MOUT_DPLL660 > +#define CLK_MOUT_ACLK_G3D661 The second patch don't implement some clocks for CLK_MOUT_DPLL, CLK_MOUT_ACLK_G3D. Why do you define them? (snip) -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH] MAINTAINERS: Change entry name of samsung exynos bus frequency driver
Dear all, Gently Ping. Best Regards, Chanwoo Choi On 18. 12. 12. 오전 10:41, Chanwoo Choi wrote: > The Samsung Exynos's device drivers have the 'SASMUNG EXYNOS' prefix > in front of the specific device driver name. In order to keep the > consistent naming format, change the entry name of bus frequency driver > for Samsung Exynos and then reorder it alpabetically. > - old : BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS > - new : SAMSUNG EXYNOS BUS FREQUENCY DRIVER > > Also, remove the unneeded git repository information. > > Signed-off-by: Chanwoo Choi > --- > MAINTAINERS | 17 - > 1 file changed, 8 insertions(+), 9 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8119141a926f..f180b8499036 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3248,15 +3248,6 @@ S: Odd fixes > F: Documentation/media/v4l-drivers/bttv* > F: drivers/media/pci/bt8xx/bttv* > > -BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS > -M: Chanwoo Choi > -L: linux...@vger.kernel.org > -L: linux-samsung-...@vger.kernel.org > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git > -S: Maintained > -F: drivers/devfreq/exynos-bus.c > -F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt > - > BUSLOGIC SCSI DRIVER > M: Khalid Aziz > L: linux-s...@vger.kernel.org > @@ -13102,6 +13093,14 @@ S: Supported > F: sound/soc/samsung/ > F: Documentation/devicetree/bindings/sound/samsung* > > +SAMSUNG EXYNOS BUS FREQUENCY DRIVER > +M: Chanwoo Choi > +L: linux...@vger.kernel.org > +L: linux-samsung-...@vger.kernel.org > +S: Maintained > +F: drivers/devfreq/exynos-bus.c > +F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt > + > SAMSUNG EXYNOS PSEUDO RANDOM NUMBER GENERATOR (RNG) DRIVER > M: Krzysztof Kozlowski > L: linux-cry...@vger.kernel.org >
Re: [PATCH 1/8] clk: samsung: add needed IDs for DMC clocks in Exynos5420
Hi Lukasz, This patchset don't contain the cover-letter. Please send the cover-letter which explains what to do on this patchset. And is it supporting all Exynos5 for both 32bit(5420,5422) and 64bit(5433) or only Exynos542x(32bit)? If it only support the Exynos 542x series, you have to change the driver name from 'exynos5-dmc.c' to 'exynos5420-dmc.c' or 'exynos5422-dmc.c' in order to prevent the confusion according to the driver name. On 19. 1. 29. 오전 4:21, Lukasz Luba wrote: > Define new IDs for clocks used by Dynamic Memory Controller in > Exynos5422 SoC. > > CC: Sylwester Nawrocki > CC: Chanwoo Choi > CC: Rob Herring > CC: Mark Rutland > CC: Kukjin Kim > CC: Krzysztof Kozlowski > CC: linux-samsung-...@vger.kernel.org > CC: devicet...@vger.kernel.org > CC: linux-arm-ker...@lists.infradead.org > CC: linux-kernel@vger.kernel.org > Signed-off-by: Lukasz Luba > --- > include/dt-bindings/clock/exynos5420.h | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/include/dt-bindings/clock/exynos5420.h > b/include/dt-bindings/clock/exynos5420.h > index 355f469..1827a64 100644 > --- a/include/dt-bindings/clock/exynos5420.h > +++ b/include/dt-bindings/clock/exynos5420.h > @@ -60,6 +60,7 @@ > #define CLK_MAU_EPLL 159 > #define CLK_SCLK_HSIC_12M160 > #define CLK_SCLK_MPHY_IXTAL24161 > +#define CLK_SCLK_BPLL162 > > /* gate clocks */ > #define CLK_UART0257 > @@ -195,6 +196,16 @@ > #define CLK_ACLK432_CAM 518 > #define CLK_ACLK_FL1550_CAM 519 > #define CLK_ACLK550_CAM 520 > +#define CLK_CLKM_PHY0521 > +#define CLK_CLKM_PHY1522 > +#define CLK_ACLK_PPMU_DREX0_0523 > +#define CLK_ACLK_PPMU_DREX0_1524 > +#define CLK_ACLK_PPMU_DREX1_0525 > +#define CLK_ACLK_PPMU_DREX1_1526 > +#define CLK_PCLK_PPMU_DREX0_0527 > +#define CLK_PCLK_PPMU_DREX0_1528 > +#define CLK_PCLK_PPMU_DREX1_0529 > +#define CLK_PCLK_PPMU_DREX1_1530 > > /* mux clocks */ > #define CLK_MOUT_HDMI640 > @@ -217,6 +228,10 @@ > #define CLK_MOUT_EPLL657 > #define CLK_MOUT_MAU_EPLL658 > #define CLK_MOUT_USER_MAU_EPLL 659 > +#define CLK_MOUT_DPLL660 > +#define CLK_MOUT_ACLK_G3D661 > +#define CLK_MOUT_SCLK_SPLL 662 > +#define CLK_MOUT_MX_MSPLL_CCORE_PHY 663 > > /* divider clocks */ > #define CLK_DOUT_PIXEL 768 > @@ -248,8 +263,9 @@ > #define CLK_DOUT_CCLK_DREX0 794 > #define CLK_DOUT_CLK2X_PHY0 795 > #define CLK_DOUT_PCLK_CORE_MEM 796 > +#define CLK_FF_DOUT_SPLL2797 > > /* must be greater than maximal clock id */ > -#define CLK_NR_CLKS 797 > +#define CLK_NR_CLKS 798 > > #endif /* _DT_BINDINGS_CLOCK_EXYNOS_5420_H */ > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH] devfreq: Suspend all devices on system shutdown
Hi,
On 19. 1. 25. 오후 10:54, Marek Szyprowski wrote:
> This way devfreq core ensures that all its devices will be set to safe
> operation points before reboot operation. There are board on which some
> aggressive power saving operation points are behind the capabilities of
> the bootloader to properly reset the hardware and boot the board. This
> way one can avoid board crash early after reboot.
>
> Similar pattern is used in CPUfreq subsystem.
>
> Reported-by: Markus Reichl
> Signed-off-by: Marek Szyprowski
> ---
> drivers/devfreq/devfreq.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 0ae3de76833b..f6aba8344c56 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1422,6 +1423,10 @@ static struct attribute *devfreq_attrs[] = {
> };
> ATTRIBUTE_GROUPS(devfreq);
>
> +static struct syscore_ops devfreq_syscore_ops = {
> + .shutdown = devfreq_suspend,
> +};
> +
> static int __init devfreq_init(void)
> {
> devfreq_class = class_create(THIS_MODULE, "devfreq");
> @@ -1438,6 +1443,8 @@ static int __init devfreq_init(void)
> }
> devfreq_class->dev_groups = devfreq_groups;
>
> + register_syscore_ops(_syscore_ops);
> +
> return 0;
> }
> subsys_initcall(devfreq_init);
>
Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH v3] extcon: Add support for ptn5150 extcon driver
From: Vijai Kumar K
PTN5150 is a small thin low power CC (Configurationn Channel)
Logic chip supporting the USB Type-C connector application with
CC control logic detection and indication functions.
Signed-off-by: Vijai Kumar K
[cw00.choi: fix indentation of binding document and change patch subject]
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/extcon/extcon-ptn5150.txt | 27 ++
drivers/extcon/Kconfig | 8 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-ptn5150.c| 339 +
4 files changed, 375 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
create mode 100644 drivers/extcon/extcon-ptn5150.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
new file mode 100644
index ..936fbdf12815
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
@@ -0,0 +1,27 @@
+* PTN5150 CC (Configuration Channel) Logic device
+
+PTN5150 is a small thin low power CC logic chip supporting the USB Type-C
+connector application with CC control logic detection and indication functions.
+It is interfaced to the host controller using an I2C interface.
+
+Required properties:
+- compatible: should be "nxp,ptn5150"
+- reg: specifies the I2C slave address of the device
+- int-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the PTN5150's INTB pin.
+- vbus-gpio: should contain a phandle and GPIO specifier for the GPIO pin which
+ is used to control VBUS.
+- pinctrl-names : a pinctrl state named "default" must be defined.
+- pinctrl-0 : phandle referencing pin configuration of interrupt and vbus
+ control.
+
+Example:
+ ptn5150@1d {
+ compatible = "nxp,ptn5150";
+ reg = <0x1d>;
+ int-gpio = < 78 GPIO_ACTIVE_HIGH>;
+ vbus-gpio = < 148 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+ status = "okay";
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index de15bf55895b..b9cc027e89ab 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -114,6 +114,14 @@ config EXTCON_PALMAS
Say Y here to enable support for USB peripheral and USB host
detection by palmas usb.
+config EXTCON_PTN5150
+ tristate "NXP PTN5150 CC LOGIC USB EXTCON support"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say Y here to enable support for USB peripheral and USB host
+ detection by NXP PTN5150 CC (Configuration Channel) logic chip.
+
config EXTCON_QCOM_SPMI_MISC
tristate "Qualcomm USB extcon support"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0888fdeded72..261ce4cfe209 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
+obj-$(CONFIG_EXTCON_PTN5150) += extcon-ptn5150.o
obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += extcon-qcom-spmi-misc.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
new file mode 100644
index ..b6d0557030d3
--- /dev/null
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -0,0 +1,339 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// extcon-ptn5150.c - PTN5150 CC logic extcon driver to support USB detection
+//
+// Based on extcon-sm5502.c driver
+// Copyright (c) 2018-2019 by Vijai Kumar K
+// Author: Vijai Kumar K
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PTN5150 registers */
+enum ptn5150_reg {
+ PTN5150_REG_DEVICE_ID = 0x01,
+ PTN5150_REG_CONTROL,
+ PTN5150_REG_INT_STATUS,
+ PTN5150_REG_CC_STATUS,
+ PTN5150_REG_CON_DET = 0x09,
+ PTN5150_REG_VCONN_STATUS,
+ PTN5150_REG_RESET,
+ PTN5150_REG_INT_MASK = 0x18,
+ PTN5150_REG_INT_REG_STATUS,
+ PTN5150_REG_END,
+};
+
+#define PTN5150_DFP_ATTACHED 0x1
+#define PTN5150_UFP_ATTACHED 0x2
+
+/* Define PTN5150 MASK/SHIFT constant */
+#define PTN5150_REG_DEVICE_ID_VENDOR_SHIFT 0
+#define PTN5150_REG_DEVICE_ID_VENDOR_MASK \
+ (0x3 << PTN5150_REG_DEVICE_ID_VENDOR_SHIFT)
+
+#define PTN5150_REG_DEVICE_ID_VERSION_SHIFT3
+#define PTN5150_REG_DEVICE_ID_VERSION_MASK \
+ (0x1f << PTN5150_REG_DEVICE_ID_VERSION_SHIFT)
+
+#defi
Re: linux-next: build warning after merge of the extcon tree
Hi Stephen,
Thanks for the test and report. I'll fix it.
On 19. 1. 24. 오후 12:47, Stephen Rothwell wrote:
> Hi Chanwoo,
>
> After merging the extcon tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in drivers/extcon/extcon-ptn5150.o
> see include/linux/module.h for more information
>
> Introduced by commit
>
> 58963276749e ("extcon: Add support for ptn5150 extcon driver")
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH V2] drivers: extcon: Add support for ptn5150
Hi Vijai,
Looks good to me. But, there are minor modification by myself as following:
After fixed them, applied it to extcon-next. Thanks.
- PTN5150A -> PTN5150 because this patch usually used the 'ptn5150' word
without 'A'.
- Modify the patch subject to keep the same format of extcon drivers
- before : drivers: extcon: Add support for ptn5150
- after : extcon: Add support for ptn5150 extcon driver
- Remove the space in extcon-ptn5150.txt and then use tab for indentation
- Limit the under 80 char on one line
[Modified version]
extcon: Add support for ptn5150 extcon driver
PTN5150 is a small thin low power CC (Configurationn Channel)
Logic chip supporting the USB Type-C connector application with
CC control logic detection and indication functions.
Signed-off-by: Vijai Kumar K
Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
+* PTN5150 CC (Configuration Channel) Logic device
+
+PTN5150 is a small thin low power CC logic chip supporting the USB Type-C
+connector application with CC control logic detection and indication functions.
+It is interfaced to the host controller using an I2C interface.
+
+Required properties:
+- compatible: should be "nxp,ptn5150"
+- reg: specifies the I2C slave address of the device
+- int-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the PTN5150's INTB pin.
+- vbus-gpio: should contain a phandle and GPIO specifier for the GPIO pin which
+ is used to control VBUS.
+- pinctrl-names : a pinctrl state named "default" must be defined.
+- pinctrl-0 : phandle referencing pin configuration of interrupt and vbus
+ control.
+
--
Best Regards,
Chanwoo Choi
Samsung Electronics
On 19. 1. 23. 오후 9:46, Vijai Kumar K wrote:
> PTN5150A is a small thin low power CC Logic chip supporting
> the USB Type-C connector application with Configurationn Channel(CC)
> control logic detection and indication functions.
>
> Add driver, Kconfig and Makefile entries.
>
> Signed-off-by: Vijai Kumar K
> ---
> Hi Chanwoo,
>
> I have implemented the review comments and below is the updated patchset.
> Can you please review it?
>
> Highlights:
> - extcon.h -> extcon-provider.h
> - Remove dummy implementations for .remove, _suspend/_resume
> - Change license format to SPDX
> - remove extcon-ptn5150.h and collapse definitions to extcon-ptn5150.c
> - Replace tabs with spaces
> - Update Documentation
> - Fix coding style issues
>
> Thanks
> Vijai Kumar K
>
> .../devicetree/bindings/extcon/extcon-ptn5150.txt | 27 ++
> drivers/extcon/Kconfig | 8 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-ptn5150.c| 335
> +
> 4 files changed, 371 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> create mode 100644 drivers/extcon/extcon-ptn5150.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> new file mode 100644
> index 000..e772d42
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
> @@ -0,0 +1,27 @@
> +
> +* PTN5150 CC (Configuration Channel) Logic device
> +PTN5150A is a small thin low power CC logic chip supporting the USB Type-C
> +connector application with Configuration Channel (CC) control logic
> detection and
> +indication functions. It is interfaced to the host controller using an I2C
> interface.
> +
> +Required properties:
> +- compatible: Should be "nxp,ptn5150"
> +- reg: Specifies the I2C slave address of the device
> +- int-gpio: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the PTN5150's INTB pin.
> +- vbus-gpio: should contain a phandle and GPIO specifier for the GPIO pin
> which
> + is used to control VBUS.
> +- pinctrl-names : a pinctrl state named "default" must be defined.
> +- pinctrl-0 : phandle referencing pin configuration of interrupt and vbus
> control.
> +
> +Example:
> +
> + ptn5150@1d {
> + compatible = "nxp,ptn5150";
> + reg = <0x1d>;
> + int-gpio = < 78 GPIO_ACTIVE_HIGH>;
> + vbus-gpio = < 148 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_default>;
> + status = "okay";
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index de15bf5..405cd76 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -114,6 +114,14 @@ config EXTCON_PALMAS
>
Re: [PATCH] drivers: extcon: Add support for ptn5150
ribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#ifndef __LINUX_EXTCON_PTN5150_H
> +#define __LINUX_EXTCON_PTN5150_H
> +
> +enum ptn5150_types {
> + TYPE_PTN5150A,
Do you have additional plan to suppor other type for extcon-ptn5150.c driver?
If extcon-ptn5150.c supports only one driver, you don't need to this
enumeration.
> +};
> +
> +/* PTN5150 registers */
> +enum ptn5150_reg {
> + PTN5150_REG_DEVICE_ID = 0x01,
> + PTN5150_REG_CONTROL,
> + PTN5150_REG_INT_STATUS,
> + PTN5150_REG_CC_STATUS,
> + PTN5150_REG_CON_DET = 0x09,
> + PTN5150_REG_VCONN_STATUS,
> + PTN5150_REG_RESET,
> + PTN5150_REG_INT_MASK = 0x18,
> + PTN5150_REG_INT_REG_STATUS,
> + PTN5150_REG_END,
> +};
> +
> +#define PTN5150_DFP_ATTACHED 0x1
> +#define PTN5150_UFP_ATTACHED 0x2
> +
> +/* Define PTN5150 MASK/SHIFT constant */
> +#define PTN5150_REG_DEVICE_ID_VENDOR_SHIFT 0
> +#define PTN5150_REG_DEVICE_ID_VERSION_SHIFT 3
> +#define PTN5150_REG_DEVICE_ID_VENDOR_MASK(0x3 <<
> PTN5150_REG_DEVICE_ID_VENDOR_SHIFT)
> +#define PTN5150_REG_DEVICE_ID_VERSION_MASK (0x1f <<
> PTN5150_REG_DEVICE_ID_VERSION_SHIFT)
> +
> +#define PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT 2
> +#define PTN5150_REG_CC_PORT_ATTACHMENT_MASK (0x7 <<
> PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT)
> +#define PTN5150_REG_CC_VBUS_DETECTION_SHIFT 7
> +#define PTN5150_REG_CC_VBUS_DETECTION_MASK (0x1 <<
> PTN5150_REG_CC_VBUS_DETECTION_SHIFT)
> +#define PTN5150_REG_INT_CABLE_ATTACH_SHIFT 0
> +#define PTN5150_REG_INT_CABLE_ATTACH_MASK(0x1 <<
> PTN5150_REG_INT_CABLE_ATTACH_SHIFT)
> +#define PTN5150_REG_INT_CABLE_DETACH_SHIFT 1
> +#define PTN5150_REG_INT_CABLE_DETACH_MASK(0x1 <<
> PTN5150_REG_CC_CABLE_DETACH_SHIFT)
> +#endif /* __LINUX_EXTCON_PTN5150_H */
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] drivers: extcon: Add support for ptn5150
Hi Vijai,
On 19. 1. 22. 오후 1:42, Vijai Kumar K wrote:
> Hi Chanwoo Choi,
>
> This is the first time I am sending a driver to LKML. I have a few doubts. Can
> you please clarify them when you are free?
>
> 1. I have developed and tested this patch on 4.14.89 kernel. When trying to
> mainline the driver should I rebase and send the patch on top of current
> tree(v5.0-rc2)?
You better to rebase your patch on extcon-next branch (v5.0-rc1).
because the extcon.git[1] keep the v5.0-rc1 version. But, if you use over
v5.0-rc1 version,
it doesn't matter. Maybe, this patch doesn't get the any impact from the
modification
of v5.0-rcX.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
>
> 2. Is there any specific git on which I should test this driver on? Like
> below?
> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
Yes.
>
> Thanks,
> Vijai Kumar K
>
> On Tue, Jan 22, 2019 at 08:05:33AM +0800, kbuild test robot wrote:
>> Hi Vijai,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on chanwoo-extcon/extcon-next]
>> [also build test ERROR on v5.0-rc2]
>> [if your patch is applied to the wrong git tree, please drop us a note to
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Vijai-Kumar-K/drivers-extcon-Add-support-for-ptn5150/20190122-041153
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
>> extcon-next
>> config: sh-allyesconfig (attached as .config)
>> compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
>> reproduce:
>> wget
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
>> ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> GCC_VERSION=8.2.0 make.cross ARCH=sh
>>
>> All error/warnings (new ones prefixed by >>):
>>
>>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_irq_work':
>>>> drivers//extcon/extcon-ptn5150.c:93:5: error: implicit declaration of
>>>> function 'extcon_set_state_sync'; did you mean 'extcon_get_state'?
>>>> [-Werror=implicit-function-declaration]
>> extcon_set_state_sync(info->edev,
>> ^
>> extcon_get_state
>>drivers//extcon/extcon-ptn5150.c: In function 'ptn5150_i2c_probe':
>>>> drivers//extcon/extcon-ptn5150.c:255:15: error: implicit declaration of
>>>> function 'devm_extcon_dev_allocate'; did you mean 'extcon_get_state'?
>>>> [-Werror=implicit-function-declaration]
>> info->edev = devm_extcon_dev_allocate(info->dev, ptn5150_extcon_cable);
>> ^~~~
>> extcon_get_state
>>>> drivers//extcon/extcon-ptn5150.c:255:13: warning: assignment to 'struct
>>>> extcon_dev *' from 'int' makes pointer from integer without a cast
>>>> [-Wint-conversion]
>> info->edev = devm_extcon_dev_allocate(info->dev, ptn5150_extcon_cable);
>> ^
>>>> drivers//extcon/extcon-ptn5150.c:262:8: error: implicit declaration of
>>>> function 'devm_extcon_dev_register'; did you mean 'devm_pinctrl_register'?
>>>> [-Werror=implicit-function-declaration]
>> ret = devm_extcon_dev_register(info->dev, info->edev);
>>^~~~
>>devm_pinctrl_register
>>cc1: some warnings being treated as errors
>>
>> vim +93 drivers//extcon/extcon-ptn5150.c
>>
>> 51
>> 52 static void ptn5150_irq_work(struct work_struct *work)
>> 53 {
>> 54 struct ptn5150_info *info = container_of(work,
>> 55 struct ptn5150_info, irq_work);
>> 56 int ret = 0;
>> 57 unsigned int reg_data;
>> 58 unsigned int port_status;
>> 59 unsigned int vbus;
>> 60 unsigned int cable_attach;
>> 61 unsigned int int_status;
>> 62
>> 63 if (!info->edev)
>> 64 return;
>> 65
>> 66 mutex_lock(>mutex);
>> 67
>> 68 ret = regmap_read(info->regmap, PTN5150_REG_CC_STATUS,
>> _data);
>> 69 if (ret) {
>> 70 dev_err(info->dev,
>> 71 "failed to read CC
Re: [PATCH 1/3] PM / devfreq: fix indentation in devfreq_add_device()
Hi, On 19. 1. 20. 오전 1:04, Yangtao Li wrote: > To beautify the code format. > > Signed-off-by: Yangtao Li > --- > drivers/devfreq/devfreq.c | 17 - > 1 file changed, 8 insertions(+), 9 deletions(-) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 0ae3de76833b..076b1c2f40a4 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -683,16 +683,15 @@ struct devfreq *devfreq_add_device(struct device *dev, > goto err_out; > } > > - devfreq->trans_table = > - devm_kzalloc(>dev, > - array3_size(sizeof(unsigned int), > - devfreq->profile->max_state, > - devfreq->profile->max_state), > - GFP_KERNEL); > + devfreq->trans_table = devm_kzalloc(>dev, > + array3_size(sizeof(unsigned int), > + devfreq->profile->max_state, > + devfreq->profile->max_state), > + GFP_KERNEL); > devfreq->time_in_state = devm_kcalloc(>dev, > - devfreq->profile->max_state, > - sizeof(unsigned long), > - GFP_KERNEL); > + devfreq->profile->max_state, > + sizeof(unsigned long), > + GFP_KERNEL); > devfreq->last_stat_updated = jiffies; > > srcu_init_notifier_head(>transition_notifier_list); > Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 3/3] PM / devfreq: fix mem leak in devfreq_add_device()
Hi, On 19. 1. 20. 오전 1:04, Yangtao Li wrote: > 'devfreq' is malloced in devfreq_add_device() and should be freed in > the error handling cases, otherwise it will cause memory leak. > > Signed-off-by: Yangtao Li > --- > drivers/devfreq/devfreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > index 923889229a0b..fe6c157cb7e0 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -651,7 +651,7 @@ struct devfreq *devfreq_add_device(struct device *dev, > mutex_unlock(>lock); > err = set_freq_table(devfreq); > if (err < 0) > - goto err_out; > + goto err_dev; > mutex_lock(>lock); > } > > Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH] PM / devfreq: consistent indentation
On 19. 1. 21. 오전 11:19, MyungJoo Ham wrote:
> Following up with complaints on inconsistent indentation from
> Yangtao Li, this fixes indentation inconsistency.
>
> In principle, this tries to put arguments aligned to the left
> including the first argument except for in the case where
> the first argument is on the far-right side.
>
> Signed-off-by: MyungJoo Ham
> ---
> drivers/devfreq/devfreq.c | 49
> +++
> 1 file changed, 24 insertions(+), 25 deletions(-)
Looks better before.
Reviewed-by: Chanwoo Choi
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 4af608a..428a1de 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -528,7 +528,7 @@ void devfreq_interval_update(struct devfreq *devfreq,
> unsigned int *delay)
> mutex_lock(>lock);
> if (!devfreq->stop_polling)
> queue_delayed_work(devfreq_wq, >work,
> - msecs_to_jiffies(devfreq->profile->polling_ms));
> + msecs_to_jiffies(devfreq->profile->polling_ms));
> }
> out:
> mutex_unlock(>lock);
> @@ -537,7 +537,7 @@ EXPORT_SYMBOL(devfreq_interval_update);
>
> /**
> * devfreq_notifier_call() - Notify that the device frequency requirements
> - * has been changed out of devfreq framework.
> + *has been changed out of devfreq framework.
> * @nb: the notifier_block (supposed to be devfreq->nb)
> * @type:not used
> * @devp:not used
> @@ -683,12 +683,11 @@ struct devfreq *devfreq_add_device(struct device *dev,
> goto err_out;
> }
>
> - devfreq->trans_table =
> - devm_kzalloc(>dev,
> - array3_size(sizeof(unsigned int),
> - devfreq->profile->max_state,
> - devfreq->profile->max_state),
> - GFP_KERNEL);
> + devfreq->trans_table = devm_kzalloc(>dev,
> + array3_size(sizeof(unsigned int),
> + devfreq->profile->max_state,
> + devfreq->profile->max_state),
> + GFP_KERNEL);
> if (!devfreq->trans_table) {
> mutex_unlock(>lock);
> err = -ENOMEM;
> @@ -696,9 +695,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
> }
>
> devfreq->time_in_state = devm_kcalloc(>dev,
> - devfreq->profile->max_state,
> - sizeof(unsigned long),
> - GFP_KERNEL);
> + devfreq->profile->max_state,
> + sizeof(unsigned long),
> + GFP_KERNEL);
> if (!devfreq->time_in_state) {
> mutex_unlock(>lock);
> err = -ENOMEM;
> @@ -1184,7 +1183,7 @@ static ssize_t available_governors_show(struct device
> *d,
>*/
> if (df->governor->immutable) {
> count = scnprintf([count], DEVFREQ_NAME_LEN,
> -"%s ", df->governor_name);
> + "%s ", df->governor_name);
> /*
>* The devfreq device shows the registered governor except for
>* immutable governors such as passive governor .
> @@ -1497,8 +1496,8 @@ EXPORT_SYMBOL(devfreq_recommended_opp);
>
> /**
> * devfreq_register_opp_notifier() - Helper function to get devfreq notified
> - * for any changes in the OPP availability
> - * changes
> + *for any changes in the OPP availability
> + *changes
> * @dev: The devfreq user device. (parent of devfreq)
> * @devfreq: The devfreq object.
> */
> @@ -1510,8 +1509,8 @@ EXPORT_SYMBOL(devfreq_register_opp_notifier);
>
> /**
> * devfreq_unregister_opp_notifier() - Helper function to stop getting
> devfreq
> - *notified for any changes in the OPP
> - *availability changes anymore.
> + * notified for any changes in the OPP
> + * availability changes anymore.
> * @dev: The devfreq user device. (parent of devfreq)
> * @devfreq: The devfreq object.
> *
> @@ -1530,8 +1529,8 @@ static void devm_devfr
Re: [PATCH v4 5/5] clk: samsung: exynos5433: add imem clocks
Hi Kamil,
2019년 1월 18일 (금) 오후 10:18, Kamil Konieczny
님이 작성:
>
> Add imem clocks for exynos5433. This will enable to use crypto Slim
> Security SubSystem (in short SlimSSS) IP block.
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/clk/samsung/clk-exynos5433.c | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5433.c
> b/drivers/clk/samsung/clk-exynos5433.c
> index 24c3360db65b..dae1c96de933 100644
> --- a/drivers/clk/samsung/clk-exynos5433.c
> +++ b/drivers/clk/samsung/clk-exynos5433.c
> @@ -5467,6 +5467,35 @@ static const struct samsung_cmu_info cam1_cmu_info
> __initconst = {
> .clk_name = "aclk_cam1_400",
> };
>
> +/*
> + * Register offset definitions for CMU_IMEM
> + */
> +#define ENABLE_ACLK_IMEM_SLIMSSS 0x080c
> +#define ENABLE_PCLK_IMEM_SLIMSSS 0x0908
> +
> +static const unsigned long imem_clk_regs[] __initconst = {
> + ENABLE_ACLK_IMEM_SLIMSSS,
> + ENABLE_PCLK_IMEM_SLIMSSS,
> +};
> +
> +static const struct samsung_gate_clock imem_gate_clks[] __initconst = {
> + /* ENABLE_ACLK_IMEM_SLIMSSS */
> + GATE(CLK_ACLK_SLIMSSS, "aclk_slimsss", "aclk_imem_sssx_266",
> + ENABLE_ACLK_IMEM_SLIMSSS, 0, CLK_IGNORE_UNUSED, 0),
> +
> + /* ENABLE_PCLK_IMEM_SLIMSSS */
> + GATE(CLK_PCLK_SLIMSSS, "pclk_slimsss", "aclk_imem_200",
> + ENABLE_PCLK_IMEM_SLIMSSS, 0, CLK_IGNORE_UNUSED, 0),
> +};
> +
> +static const struct samsung_cmu_info imem_cmu_info __initconst = {
> + .gate_clks = imem_gate_clks,
> + .nr_gate_clks = ARRAY_SIZE(imem_gate_clks),
> + .nr_clk_ids = IMEM_NR_CLK,
> + .clk_regs = imem_clk_regs,
> + .nr_clk_regs= ARRAY_SIZE(imem_clk_regs),
> + .clk_name = "aclk_imem_200",
> +};
>
> struct exynos5433_cmu_data {
> struct samsung_clk_reg_dump *clk_save;
> @@ -5654,6 +5683,9 @@ static const struct of_device_id
> exynos5433_cmu_of_match[] = {
> }, {
> .compatible = "samsung,exynos5433-cmu-mscl",
> .data = _cmu_info,
> + }, {
> + .compatible = "samsung,exynos5433-cmu-imem",
> + .data = _cmu_info,
> }, {
> },
> };
> --
> 2.20.0
>
Looks good to me.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
