Re: [PATCH v4 02/24] PM / devfreq: tegra30: Keep interrupt disabled while governor is stopped
On 19. 7. 16. 오후 10:03, Dmitry Osipenko wrote:
> 16.07.2019 14:47, Chanwoo Choi пишет:
>> On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
>>> There is no real need to keep interrupt always-enabled, will be nicer
>>> to keep it disabled while governor is inactive.
>>>
>>> Suggested-by: Thierry Reding
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/devfreq/tegra30-devfreq.c | 43 ---
>>> 1 file changed, 22 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/tegra30-devfreq.c
>>> b/drivers/devfreq/tegra30-devfreq.c
>>> index a27300f40b0b..5e2b133babdd 100644
>>> --- a/drivers/devfreq/tegra30-devfreq.c
>>> +++ b/drivers/devfreq/tegra30-devfreq.c
>>> @@ -11,6 +11,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -416,8 +417,6 @@ static void tegra_actmon_start(struct tegra_devfreq
>>> *tegra)
>>> {
>>> unsigned int i;
>>>
>>> - disable_irq(tegra->irq);
>>> -
>>> actmon_writel(tegra, ACTMON_SAMPLING_PERIOD - 1,
>>> ACTMON_GLB_PERIOD_CTRL);
>>>
>>> @@ -442,8 +441,6 @@ static void tegra_actmon_stop(struct tegra_devfreq
>>> *tegra)
>>> }
>>>
>>> actmon_write_barrier(tegra);
>>> -
>>> - enable_irq(tegra->irq);
>>> }
>>>
>>> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
>>> @@ -552,6 +549,12 @@ static int tegra_governor_event_handler(struct devfreq
>>> *devfreq,
>>> {
>>> struct tegra_devfreq *tegra = dev_get_drvdata(devfreq->dev.parent);
>>>
>>> + /*
>>> +* Couple device with the governor early as it is needed at
>>> +* the moment of governor's start (used by ISR).
>>> +*/
>>> + tegra->devfreq = devfreq;
>>
>> I'm not sure it is necessary. Almost devfreq device get
>> the devfreq instance on probe timing through devfreq_add_device directly.
>
> This is necessary because this assignment is for the "governor" and not
> the "device". Governor is started during of devfreq_add_device(), hence
> there is no better way to assign device to the driver's governor.
OK. I understand.
But, I have a question. Is it working before this patch?
How can you test it on that tegra->devfreq is NULL?
>
>>> +
>>> switch (event) {
>>> case DEVFREQ_GOV_START:
>>> devfreq_monitor_start(devfreq);
>>> @@ -586,10 +589,11 @@ static struct devfreq_governor tegra_devfreq_governor
>>> = {
>>>
>>> static int tegra_devfreq_probe(struct platform_device *pdev)
>>> {
>>> - struct tegra_devfreq *tegra;
>>> struct tegra_devfreq_device *dev;
>>> - unsigned int i;
>>> + struct tegra_devfreq *tegra;
>>> + struct devfreq *devfreq;
>>> unsigned long rate;
>>> + unsigned int i;
>>> int err;
>>>
>>> tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
>>> @@ -625,6 +629,16 @@ static int tegra_devfreq_probe(struct platform_device
>>> *pdev)
>>> }
>>> tegra->irq = err;
>>>
>>> + irq_set_status_flags(tegra->irq, IRQ_NOAUTOEN);
>>> +
>>> + 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: %d\n", err);
>>> + return err;
>>> + }
>>> +
>>> reset_control_assert(tegra->reset);
>>>
>>> err = clk_prepare_enable(tegra->clock);
>>> @@ -672,28 +686,15 @@ static int tegra_devfreq_probe(struct platform_device
>>> *pdev)
>>> }
>>>
>>> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
>>> - tegra->devfreq = devfreq_add_device(>dev,
>>> - _devfreq_profile,
>>> - "tegra_actmon",
>>> - NULL);
>>> + devfreq = devfreq_add_device(>dev, _devfreq_profile,
>>> +"tegra_actmon", NULL);
>>> if (IS_ERR(tegra->devfreq)) {
>>
>> Have to check 'devfreq' instead of 'tegra->devfreq'.
>> Did you test it? It might be failed because 'tegra->devfreq is NULL.
>
> That's a good catch! Thank you very much.
>
>>> err = PTR_ERR(tegra->devfreq);
>>
>> ditto.
>
> Ok
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 15/24] PM / devfreq: tegra30: Fix integer overflow on CPU's freq max out
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> There is another kHz-conversion bug in the code, resulting in integer
> overflow. Although, this time the resulting value is 4294966296 and it's
> close to ULONG_MAX, which is okay in this case.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 0de1efdaabf4..60ebf9c9cd86 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -172,7 +172,7 @@ struct tegra_actmon_emc_ratio {
> };
>
> static const struct tegra_actmon_emc_ratio actmon_emc_ratios[] = {
> - { 140, ULONG_MAX },
> + { 140, ULONG_MAX / KHZ },
> { 120,75 },
> { 1100000,60 },
> { 100, 500000 },
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 14/24] PM / devfreq: tegra30: Ensure that target freq won't overflow
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote: > Potentially very high boosting could cause an integer overflow for a > highly clocked memory after conversion to MHz. > > Signed-off-by: Dmitry Osipenko > --- > drivers/devfreq/tegra30-devfreq.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/devfreq/tegra30-devfreq.c > b/drivers/devfreq/tegra30-devfreq.c > index 2f59c78930bd..0de1efdaabf4 100644 > --- a/drivers/devfreq/tegra30-devfreq.c > +++ b/drivers/devfreq/tegra30-devfreq.c > @@ -460,6 +460,7 @@ static unsigned long actmon_update_target(struct > tegra_devfreq *tegra, > unsigned long target_freq; > > target_freq = dev->avg_count / ACTMON_SAMPLING_PERIOD + dev->boost_freq; > + target_freq = min(target_freq, ULONG_MAX / KHZ); Did you meet this corner case? If have to change it, you better to use 'tegra->max_freq' as following: min(target_freq, tegra->max_freq); > target_freq = tegra_actmon_account_cpu_freq(tegra, dev, target_freq); > > return target_freq; > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v4 13/24] PM / devfreq: tegra30: Constify structs
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> Constify unmodifiable structs for consistency.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 1a10df5dbbed..2f59c78930bd 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -106,7 +106,7 @@ enum tegra_actmon_device {
> MCCPU,
> };
>
> -static struct tegra_devfreq_device_config actmon_device_configs[] = {
> +static const struct tegra_devfreq_device_config actmon_device_configs[] = {
> {
> /* MCALL: All memory accesses (including from the CPUs) */
> .offset = 0x1c0,
> @@ -171,7 +171,7 @@ struct tegra_actmon_emc_ratio {
> unsigned long emc_freq;
> };
>
> -static struct tegra_actmon_emc_ratio actmon_emc_ratios[] = {
> +static const struct tegra_actmon_emc_ratio actmon_emc_ratios[] = {
> { 140, ULONG_MAX },
> { 120,75 },
> { 110,60 },
> @@ -210,7 +210,7 @@ static inline unsigned long do_percent(unsigned long val,
> unsigned int pct)
>
> static unsigned long actmon_cpu_to_emc_rate(struct tegra_devfreq *tegra)
> {
> - struct tegra_actmon_emc_ratio *ratio = actmon_emc_ratios;
> + const struct tegra_actmon_emc_ratio *ratio = actmon_emc_ratios;
> unsigned int cpu_freq = cpufreq_get(0);
> unsigned int i;
>
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 12/24] PM / devfreq: tegra30: Inline all one-line functions
Hi Dmitry,
I'm not sure that it is necessary.
As I knew, usally, the 'inline' is used on header file
to define the empty functions.
Do we have to change it with 'inline' keyword?
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> Depending on a kernel's configuration, a single line functions may not be
> inlined by compiler (like enabled ftracing for example). Let's inline such
> functions explicitly for consistency.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index c6c4a07d3e07..1a10df5dbbed 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -181,28 +181,29 @@ static struct tegra_actmon_emc_ratio
> actmon_emc_ratios[] = {
> { 25,10 },
> };
>
> -static u32 actmon_readl(struct tegra_devfreq *tegra, u32 offset)
> +static inline u32 actmon_readl(struct tegra_devfreq *tegra, u32 offset)
> {
> return readl_relaxed(tegra->regs + offset);
> }
>
> -static void actmon_writel(struct tegra_devfreq *tegra, u32 val, u32 offset)
> +static inline void actmon_writel(struct tegra_devfreq *tegra,
> + u32 val, u32 offset)
> {
> writel_relaxed(val, tegra->regs + offset);
> }
>
> -static u32 device_readl(struct tegra_devfreq_device *dev, u32 offset)
> +static inline u32 device_readl(struct tegra_devfreq_device *dev, u32 offset)
> {
> return readl_relaxed(dev->regs + offset);
> }
>
> -static void device_writel(struct tegra_devfreq_device *dev, u32 val,
> - u32 offset)
> +static inline void device_writel(struct tegra_devfreq_device *dev,
> + u32 val, u32 offset)
> {
> writel_relaxed(val, dev->regs + offset);
> }
>
> -static unsigned long do_percent(unsigned long val, unsigned int pct)
> +static inline unsigned long do_percent(unsigned long val, unsigned int pct)
> {
> return val * pct / 100;
> }
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 11/24] PM / devfreq: tegra30: Add debug messages
Hi Dmitry,
Usually, the kernel log print for all users
such as changing the frequency, fail or success.
But, if the log just show the register dump,
it is not useful for all users. It is just used
for only specific developer.
I recommend that you better to add more exception handling
code on many points instead of just showing the register dump.
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> Add debug messages to know about what's happening in hardware and how
> driver reacts.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 878c9396bb8c..c6c4a07d3e07 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -41,6 +41,7 @@
> #define ACTMON_DEV_AVG_UPPER_WMARK 0x10
> #define ACTMON_DEV_AVG_LOWER_WMARK 0x14
> #define ACTMON_DEV_COUNT_WEIGHT 0x18
> +#define ACTMON_DEV_COUNT 0x1c
> #define ACTMON_DEV_AVG_COUNT 0x20
> #define ACTMON_DEV_INTR_STATUS 0x24
>
> @@ -276,6 +277,9 @@ static void tegra_actmon_get_lower_upper(struct
> tegra_devfreq *tegra,
>unsigned long *lower,
>unsigned long *upper)
> {
> + struct device *ddev = tegra->devfreq->dev.parent;
> + u32 offset = dev->config->offset;
> +
> /*
>* Memory frequencies are guaranteed to have 1MHz granularity
>* and thus we need this rounding down to get a proper watermarks
> @@ -288,6 +292,9 @@ static void tegra_actmon_get_lower_upper(struct
> tegra_devfreq *tegra,
> *lower = tegra_actmon_lower_freq(tegra, target_freq);
> *upper = tegra_actmon_upper_freq(tegra, target_freq);
>
> + dev_dbg(ddev, "%03x: target_freq %lu lower freq %lu upper freq %lu\n",
> + offset, target_freq, *lower, *upper);
> +
> *lower /= KHZ;
> *upper /= KHZ;
>
> @@ -367,11 +374,31 @@ static void tegra_devfreq_update_wmark(struct
> tegra_devfreq *tegra,
> device_writel(dev, lower + delta, ACTMON_DEV_LOWER_WMARK);
> }
>
> +static void actmon_device_debug(struct tegra_devfreq *tegra,
> + struct tegra_devfreq_device *dev,
> + const char *prefix)
> +{
> + dev_dbg(tegra->devfreq->dev.parent,
> + "%03x: %s: 0x%08x 0x%08x a %u %u %u c %u %u %u b %lu cpu %u\n",
> + dev->config->offset, prefix,
> + device_readl(dev, ACTMON_DEV_INTR_STATUS),
> + device_readl(dev, ACTMON_DEV_CTRL),
> + device_readl(dev, ACTMON_DEV_AVG_COUNT),
> + device_readl(dev, ACTMON_DEV_AVG_LOWER_WMARK),
> + device_readl(dev, ACTMON_DEV_AVG_UPPER_WMARK),
> + device_readl(dev, ACTMON_DEV_COUNT),
> + device_readl(dev, ACTMON_DEV_LOWER_WMARK),
> + device_readl(dev, ACTMON_DEV_UPPER_WMARK),
> + dev->boost_freq, cpufreq_get(0));
> +}
> +
> static void actmon_isr_device(struct tegra_devfreq *tegra,
> struct tegra_devfreq_device *dev)
> {
> u32 intr_status, dev_ctrl, avg_intr_mask;
>
> + actmon_device_debug(tegra, dev, "isr+");
> +
> dev->avg_count = device_readl(dev, ACTMON_DEV_AVG_COUNT);
> intr_status = device_readl(dev, ACTMON_DEV_INTR_STATUS);
> dev_ctrl = device_readl(dev, ACTMON_DEV_CTRL);
> @@ -422,6 +449,8 @@ static void actmon_isr_device(struct tegra_devfreq *tegra,
>
> device_writel(dev, dev_ctrl, ACTMON_DEV_CTRL);
> device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
> +
> + actmon_device_debug(tegra, dev, "isr-");
> }
>
> static unsigned long actmon_update_target(struct tegra_devfreq *tegra,
> @@ -712,6 +741,7 @@ static struct devfreq_dev_profile tegra_devfreq_profile =
> {
> static int tegra_governor_get_target(struct devfreq *devfreq,
>unsigned long *freq)
> {
> + struct device *ddev = devfreq->dev.parent;
> struct devfreq_dev_status *stat;
> struct tegra_devfreq *tegra;
> struct tegra_devfreq_device *dev;
> @@ -734,6 +764,11 @@ static int tegra_governor_get_target(struct devfreq
> *devfreq,
> dev_target_freq = actmon_update_target(tegra, dev);
>
> target_freq = max(target_freq, dev_target_freq);
> +
> + dev_dbg(ddev, "%03x: upd: dev_target_freq %lu\n",
> + dev->config->offset, dev_target_freq);
> +
> + actmon_device_debug(tegra, dev, "upd");
> }
>
> *freq = target_freq * KHZ;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 10/24] PM / devfreq: tegra30: Don't enable consecutive-down interrupt on startup
Hi Dmitry, On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote: > The consecutive-down event tells that we should perform frequency > de-boosting, but boosting is in a reset state on start and hence the > event won't do anything useful for us and it will be just a dummy > interrupt request. > > Signed-off-by: Dmitry Osipenko > --- > drivers/devfreq/tegra30-devfreq.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/devfreq/tegra30-devfreq.c > b/drivers/devfreq/tegra30-devfreq.c > index 32fe95458ee7..878c9396bb8c 100644 > --- a/drivers/devfreq/tegra30-devfreq.c > +++ b/drivers/devfreq/tegra30-devfreq.c > @@ -558,7 +558,6 @@ static void tegra_actmon_configure_device(struct > tegra_devfreq *tegra, > << ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_NUM_SHIFT; > val |= ACTMON_DEV_CTRL_AVG_ABOVE_WMARK_EN; > val |= ACTMON_DEV_CTRL_AVG_BELOW_WMARK_EN; > - val |= ACTMON_DEV_CTRL_CONSECUTIVE_BELOW_WMARK_EN; > val |= ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_EN; > val |= ACTMON_DEV_CTRL_ENB; > > Maybe, I think that better to review it by Thierry. I'm not sure it is right or not because it depend on h/w. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v4 09/24] PM / devfreq: tegra30: Reset boosting on startup
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> Governor could be stopped while boosting is active. We have assumption
> that everything is reset on governor's restart, including the boosting
> value, which was missed.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index d5d04c25023b..32fe95458ee7 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -536,6 +536,9 @@ static void tegra_actmon_configure_device(struct
> tegra_devfreq *tegra,
> {
> u32 val = 0, target_freq;
>
> + /* we don't want boosting on restart */
nitpick.
I think that following comment is proper in my case.
In my case, I think 'we' expression is not good
/* Reset the boost frequency on restart */
> + dev->boost_freq = 0;
> +
> target_freq = clk_get_rate(tegra->emc_clock) / KHZ;
> dev->avg_count = target_freq * ACTMON_SAMPLING_PERIOD;
> device_writel(dev, dev->avg_count, ACTMON_DEV_INIT_AVG);
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 08/24] PM / devfreq: tegra30: Move clk-notifier's registration to governor's start
Hi Dmitiry,
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> There is no point in receiving of the notifications while governor is
> stopped, let's keep them disabled like we do for the CPU freq-change
> notifications. This also fixes a potential use-after-free bug if
> notification happens after device's removal.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 33 ++-
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 48a799fa5f63..d5d04c25023b 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -576,6 +576,19 @@ static int tegra_actmon_start(struct tegra_devfreq
> *tegra)
> actmon_writel(tegra, ACTMON_SAMPLING_PERIOD - 1,
> ACTMON_GLB_PERIOD_CTRL);
>
> + /*
> + * CLK notifications are needed in order to reconfigure the upper
> + * consecutive watermark in accordance to the actual clock rate
> + * to avoid unnecessary upper interrupts.
> + */
> + err = clk_notifier_register(tegra->emc_clock,
> + >clk_rate_change_nb);
> + if (err) {
> + dev_err(tegra->devfreq->dev.parent,
> + "Failed to register rate change notifier\n");
> + return err;
> + }
> +
> for (i = 0; i < ARRAY_SIZE(tegra->devices); i++)
> tegra_actmon_configure_device(tegra, >devices[i]);
>
> @@ -602,6 +615,8 @@ static int tegra_actmon_start(struct tegra_devfreq *tegra)
> for (i = 0; i < ARRAY_SIZE(tegra->devices); i++)
> tegra_actmon_stop_device(>devices[i]);
>
> + clk_notifier_unregister(tegra->emc_clock, >clk_rate_change_nb);
> +
> return err;
> }
>
> @@ -618,6 +633,8 @@ static void tegra_actmon_stop(struct tegra_devfreq *tegra)
>
> for (i = 0; i < ARRAY_SIZE(tegra->devices); i++)
> tegra_actmon_stop_device(>devices[i]);
> +
> + clk_notifier_unregister(tegra->emc_clock, >clk_rate_change_nb);
> }
>
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> @@ -862,22 +879,14 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, tegra);
>
> + tegra->clk_rate_change_nb.notifier_call = tegra_actmon_clk_notify_cb;
> tegra->cpu_rate_change_nb.notifier_call = tegra_actmon_cpu_notify_cb;
> INIT_WORK(>update_work, tegra_actmon_delayed_update);
>
> - tegra->clk_rate_change_nb.notifier_call = tegra_actmon_clk_notify_cb;
> - err = clk_notifier_register(tegra->emc_clock,
> - >clk_rate_change_nb);
> - if (err) {
> - dev_err(>dev,
> - "Failed to register rate change notifier\n");
> - goto remove_opps;
> - }
> -
> err = devfreq_add_governor(_devfreq_governor);
> if (err) {
> dev_err(>dev, "Failed to add governor: %d\n", err);
> - goto unreg_notifier;
> + goto remove_opps;
> }
>
> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
> @@ -893,9 +902,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> remove_governor:
> devfreq_remove_governor(_devfreq_governor);
>
> -unreg_notifier:
> - clk_notifier_unregister(tegra->emc_clock, >clk_rate_change_nb);
> -
> remove_opps:
> dev_pm_opp_remove_all_dynamic(>dev);
>
> @@ -912,7 +918,6 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> devfreq_remove_device(tegra->devfreq);
> devfreq_remove_governor(_devfreq_governor);
>
> - clk_notifier_unregister(tegra->emc_clock, >clk_rate_change_nb);
> dev_pm_opp_remove_all_dynamic(>dev);
>
> reset_control_reset(tegra->reset);
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 07/24] PM / devfreq: tegra30: Use CPUFreq notifier
tmon_configure_device(tegra, >devices[i]);
>
> + /*
> + * We are estimating CPU's memory bandwidth requirement based on
> + * amount of memory accesses and system's load, judging by CPU's
> + * frequency. We also don't want to receive events about CPU's
> + * frequency transaction when governor is stopped, hence notifier
> + * is registered dynamically.
> + */
> + err = cpufreq_register_notifier(>cpu_rate_change_nb,
> + CPUFREQ_TRANSITION_NOTIFIER);
> + if (err) {
> + dev_err(tegra->devfreq->dev.parent,
> + "Failed to register rate change notifier: %d\n", err);
> + goto err_stop;
> + }> +
> enable_irq(tegra->irq);
> +
> + return 0;
> +
> +err_stop:
> + for (i = 0; i < ARRAY_SIZE(tegra->devices); i++)
> + tegra_actmon_stop_device(>devices[i]);
> +
> + return err;
> }
>
> static void tegra_actmon_stop(struct tegra_devfreq *tegra)
> @@ -546,11 +611,13 @@ static void tegra_actmon_stop(struct tegra_devfreq
> *tegra)
>
> disable_irq(tegra->irq);
>
> - for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
> - device_writel(>devices[i], 0x, ACTMON_DEV_CTRL);
> - device_writel(>devices[i], ACTMON_INTR_STATUS_CLEAR,
> - ACTMON_DEV_INTR_STATUS);
> - }
> + cpufreq_unregister_notifier(>cpu_rate_change_nb,
> + CPUFREQ_TRANSITION_NOTIFIER);
> +
> + cancel_work_sync(>update_work);
> +
> + for (i = 0; i < ARRAY_SIZE(tegra->devices); i++)
> + tegra_actmon_stop_device(>devices[i]);
> }
>
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> @@ -659,6 +726,7 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
> unsigned int event, void *data)
> {
> struct tegra_devfreq *tegra = dev_get_drvdata(devfreq->dev.parent);
> + int ret = 0;
>
> /*
>* Couple device with the governor early as it is needed at
> @@ -669,7 +737,7 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
> switch (event) {
> case DEVFREQ_GOV_START:
> devfreq_monitor_start(devfreq);
> - tegra_actmon_start(tegra);
> + ret = tegra_actmon_start(tegra);
> break;
>
> case DEVFREQ_GOV_STOP:
> @@ -684,11 +752,11 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
>
> case DEVFREQ_GOV_RESUME:
> devfreq_monitor_resume(devfreq);
> - tegra_actmon_start(tegra);
> + ret = tegra_actmon_start(tegra);
> break;
> }
>
> - return 0;
> + return ret;
> }
>
> static struct devfreq_governor tegra_devfreq_governor = {
> @@ -794,9 +862,12 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, tegra);
>
> - tegra-> .notifier_call = tegra_actmon_rate_notify_cb;
> + tegra->cpu_rate_change_nb.notifier_call = tegra_actmon_cpu_notify_cb;
> + INIT_WORK(>update_work, tegra_actmon_delayed_update);
> +
> + tegra->clk_rate_change_nb.notifier_call = tegra_actmon_clk_notify_cb;
> err = clk_notifier_register(tegra->emc_clock,
> - >rate_change_nb);
> + >clk_rate_change_nb);
> if (err) {
> dev_err(>dev,
> "Failed to register rate change notifier\n");
> @@ -823,7 +894,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> devfreq_remove_governor(_devfreq_governor);
>
> unreg_notifier:
> - clk_notifier_unregister(tegra->emc_clock, >rate_change_nb);
> + clk_notifier_unregister(tegra->emc_clock, >clk_rate_change_nb);
>
> remove_opps:
> dev_pm_opp_remove_all_dynamic(>dev);
> @@ -841,7 +912,7 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> devfreq_remove_device(tegra->devfreq);
> devfreq_remove_governor(_devfreq_governor);
>
> - clk_notifier_unregister(tegra->emc_clock, >rate_change_nb);
> + clk_notifier_unregister(tegra->emc_clock, >clk_rate_change_nb);
> dev_pm_opp_remove_all_dynamic(>dev);
>
> reset_control_reset(tegra->reset);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 06/24] PM / devfreq: tegra30: Tune up boosting thresholds
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> Now that average-sustain coefficient / multiplier is gone, it won't hurt
> to re-tune the boosting thresholds to get a bit harder boosting for MCALL
> clients, resulting in a more reactive governing in a case of multimedia
> applications usage like 3d / video.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 16f7e6cf3b99..2bf65409ddd8 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -111,8 +111,8 @@ static struct tegra_devfreq_device_config
> actmon_device_configs[] = {
> .irq_mask = 1 << 26,
> .boost_up_coeff = 200,
> .boost_down_coeff = 50,
> - .boost_up_threshold = 60,
> - .boost_down_threshold = 40,
> + .boost_up_threshold = 50,
> + .boost_down_threshold = 25,
> },
> {
> /* MCCPU: memory accesses from the CPUs */
>
It just adjusts the tunable point.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 04/24] PM / devfreq: tegra30: Drop write-barrier
Hi Dmitry,
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> There is no need in a write-barrier now, given that interrupt masking is
> handled by CPU's GIC now. Hence we know exactly that interrupt won't fire
> after stopping the devfreq's governor. In other cases we don't care about
> potential buffering of the writes to hardware and thus there is no need to
> stall CPU.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 5e606ae3f238..4be7858c33bc 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -230,12 +230,6 @@ static void tegra_devfreq_update_wmark(struct
> tegra_devfreq *tegra,
> ACTMON_DEV_LOWER_WMARK);
> }
>
> -static void actmon_write_barrier(struct tegra_devfreq *tegra)
> -{
> - /* ensure the update has reached the ACTMON */
> - readl(tegra->regs + ACTMON_GLB_STATUS);
> -}
> -
> static void actmon_isr_device(struct tegra_devfreq *tegra,
> struct tegra_devfreq_device *dev)
> {
> @@ -287,8 +281,6 @@ static void actmon_isr_device(struct tegra_devfreq *tegra,
> device_writel(dev, dev_ctrl, ACTMON_DEV_CTRL);
>
> device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
> -
> - actmon_write_barrier(tegra);
> }
>
> static unsigned long actmon_cpu_to_emc_rate(struct tegra_devfreq *tegra,
> @@ -376,8 +368,6 @@ static int tegra_actmon_rate_notify_cb(struct
> notifier_block *nb,
> tegra_devfreq_update_wmark(tegra, dev);
> }
>
> - actmon_write_barrier(tegra);
> -
> return NOTIFY_OK;
> }
>
> @@ -423,8 +413,6 @@ static void tegra_actmon_start(struct tegra_devfreq
> *tegra)
> for (i = 0; i < ARRAY_SIZE(tegra->devices); i++)
> tegra_actmon_configure_device(tegra, >devices[i]);
>
> - actmon_write_barrier(tegra);
> -
> enable_irq(tegra->irq);
> }
>
> @@ -439,8 +427,6 @@ static void tegra_actmon_stop(struct tegra_devfreq *tegra)
> device_writel(>devices[i], ACTMON_INTR_STATUS_CLEAR,
> ACTMON_DEV_INTR_STATUS);
> }
> -
> - actmon_write_barrier(tegra);
> }
>
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 03/24] PM / devfreq: tegra30: Handle possible round-rate error
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> The EMC clock rate rounding technically could fail, hence let's handle
> the error cases properly.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 5e2b133babdd..5e606ae3f238 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -592,8 +592,8 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> struct tegra_devfreq_device *dev;
> struct tegra_devfreq *tegra;
> struct devfreq *devfreq;
> - unsigned long rate;
> unsigned int i;
> + long rate;
> int err;
>
> tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
> @@ -650,8 +650,14 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> reset_control_deassert(tegra->reset);
>
> - tegra->max_freq = clk_round_rate(tegra->emc_clock, ULONG_MAX) / KHZ;
> + rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
> + if (rate < 0) {
> + dev_err(>dev, "Failed to round clock rate: %ld\n", rate);
> + return rate;
> + }
> +
> tegra->cur_freq = clk_get_rate(tegra->emc_clock) / KHZ;
> + tegra->max_freq = rate / KHZ;
>
> for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
> dev = tegra->devices + i;
> @@ -662,6 +668,13 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
> rate = clk_round_rate(tegra->emc_clock, rate);
>
Please remove unneeded blank line.
> + if (rate < 0) {
> + dev_err(>dev,
> + "Failed to round clock rate: %ld\n", rate);
> + err = rate;
> + goto remove_opps;
> + }
Also, this patch doesn't contain code which restore the previous
tegra->cur_freq/max_freq when error happen.
> +
> err = dev_pm_opp_add(>dev, rate, 0);
> if (err) {
> dev_err(>dev, "Failed to add OPP: %d\n", err);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 02/24] PM / devfreq: tegra30: Keep interrupt disabled while governor is stopped
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> There is no real need to keep interrupt always-enabled, will be nicer
> to keep it disabled while governor is inactive.
>
> Suggested-by: Thierry Reding
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 43 ---
> 1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index a27300f40b0b..5e2b133babdd 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -416,8 +417,6 @@ static void tegra_actmon_start(struct tegra_devfreq
> *tegra)
> {
> unsigned int i;
>
> - disable_irq(tegra->irq);
> -
> actmon_writel(tegra, ACTMON_SAMPLING_PERIOD - 1,
> ACTMON_GLB_PERIOD_CTRL);
>
> @@ -442,8 +441,6 @@ static void tegra_actmon_stop(struct tegra_devfreq *tegra)
> }
>
> actmon_write_barrier(tegra);
> -
> - enable_irq(tegra->irq);
> }
>
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> @@ -552,6 +549,12 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
> {
> struct tegra_devfreq *tegra = dev_get_drvdata(devfreq->dev.parent);
>
> + /*
> + * Couple device with the governor early as it is needed at
> + * the moment of governor's start (used by ISR).
> + */
> + tegra->devfreq = devfreq;
I'm not sure it is necessary. Almost devfreq device get
the devfreq instance on probe timing through devfreq_add_device directly.
> +
> switch (event) {
> case DEVFREQ_GOV_START:
> devfreq_monitor_start(devfreq);
> @@ -586,10 +589,11 @@ static struct devfreq_governor tegra_devfreq_governor =
> {
>
> static int tegra_devfreq_probe(struct platform_device *pdev)
> {
> - struct tegra_devfreq *tegra;
> struct tegra_devfreq_device *dev;
> - unsigned int i;
> + struct tegra_devfreq *tegra;
> + struct devfreq *devfreq;
> unsigned long rate;
> + unsigned int i;
> int err;
>
> tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
> @@ -625,6 +629,16 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> }
> tegra->irq = err;
>
> + irq_set_status_flags(tegra->irq, IRQ_NOAUTOEN);
> +
> + 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: %d\n", err);
> + return err;
> + }
> +
> reset_control_assert(tegra->reset);
>
> err = clk_prepare_enable(tegra->clock);
> @@ -672,28 +686,15 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> }
>
> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
> - tegra->devfreq = devfreq_add_device(>dev,
> - _devfreq_profile,
> - "tegra_actmon",
> - NULL);
> + devfreq = devfreq_add_device(>dev, _devfreq_profile,
> + "tegra_actmon", NULL);
> if (IS_ERR(tegra->devfreq)) {
Have to check 'devfreq' instead of 'tegra->devfreq'.
Did you test it? It might be failed because 'tegra->devfreq is NULL.
> err = PTR_ERR(tegra->devfreq);
ditto.
> goto remove_governor;
> }
>
> - 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: %d\n", err);
> - goto remove_devfreq;
> - }
> -
> return 0;
>
> -remove_devfreq:
> - devfreq_remove_device(tegra->devfreq);
> -
> remove_governor:
> devfreq_remove_governor(_devfreq_governor);
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 01/24] PM / devfreq: tegra30: Change irq type to unsigned int
Hi Dmitry,
On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
> IRQ numbers are always positive, hence the corresponding variable should
> be unsigned to keep types consistent. This is a minor change that cleans
> up code a tad more.
>
> Suggested-by: Thierry Reding
> Acked-by: MyungJoo Ham
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index a6ba75f4106d..a27300f40b0b 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -160,7 +160,7 @@ struct tegra_devfreq {
>
> struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
>
> - int irq;
> + unsigned intirq;
> };
>
> struct tegra_actmon_emc_ratio {
> @@ -618,12 +618,12 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return PTR_ERR(tegra->emc_clock);
> }
>
> - tegra->irq = platform_get_irq(pdev, 0);
> - if (tegra->irq < 0) {
> - err = tegra->irq;
> + err = platform_get_irq(pdev, 0);
> + if (err < 0) {
> dev_err(>dev, "Failed to get IRQ: %d\n", err);
> return err;
> }
> + tegra->irq = err;
>
> reset_control_assert(tegra->reset);
>
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 2/4] devfreq: exynos-bus: convert to use dev_pm_opp_set_rate()
Hi,
On 19. 7. 16. 오후 7:59, Bartlomiej Zolnierkiewicz wrote:
>
> On 7/16/19 12:33 PM, Chanwoo Choi wrote:
>> Hi Bartlomiej,
>>
>> On 19. 7. 16. 오후 7:13, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi Chanwoo,
>>>
>>> On 7/16/19 5:56 AM, Chanwoo Choi wrote:
>>>> Hi Kamil,
>>>>
>>>> Looks good to me. But, this patch has some issue.
>>>> I added the detailed reviews.
>>>>
>>>> I recommend that you make the separate patches as following
>>>> in order to clarify the role of which apply the dev_pm_opp_* function.
>>>>
>>>> First patch,
>>>> Need to consolidate the following two function into one function.
>>>> because the original exynos-bus.c has the problem that the regulator
>>>> of parent devfreq device have to be enabled before enabling the clock.
>>>> This issue did not happen because bootloader enables the bus-related
>>>> regulators before kernel booting.
>>>> - exynos_bus_parse_of()
>>>> - exynos_bus_parent_parse_of()
>>>>> Second patch,
>>>> Apply dev_pm_opp_set_regulators() and dev_pm_opp_set_rate()
>>>>
>>>>
>>>> On 19. 7. 15. 오후 9:04, Kamil Konieczny wrote:
>>>>> Reuse opp core code for setting bus clock and voltage. As a side
>>>>> effect this allow useage of coupled regulators feature (required
>>>>> for boards using Exynos5422/5800 SoCs) because dev_pm_opp_set_rate()
>>>>> uses regulator_set_voltage_triplet() for setting regulator voltage
>>>>> while the old code used regulator_set_voltage_tol() with fixed
>>>>> tolerance. This patch also removes no longer needed parsing of DT
>>>>> property "exynos,voltage-tolerance" (no Exynos devfreq DT node uses
>>>>> it).
>>>>>
>>>>> Signed-off-by: Kamil Konieczny
>>>>> ---
>>>>> drivers/devfreq/exynos-bus.c | 172 ++-
>>>>> 1 file changed, 66 insertions(+), 106 deletions(-)
>>>>>
>>>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>>>> index 486cc5b422f1..7fc4f76bd848 100644
>>>>> --- a/drivers/devfreq/exynos-bus.c
>>>>> +++ b/drivers/devfreq/exynos-bus.c
>>>>> @@ -25,7 +25,6 @@
>>>>> #include
>>>>>
>>>>> #define DEFAULT_SATURATION_RATIO 40
>>>>> -#define DEFAULT_VOLTAGE_TOLERANCE2
>>>>>
>>>>> struct exynos_bus {
>>>>> struct device *dev;
>>>>> @@ -37,9 +36,9 @@ struct exynos_bus {
>>>>>
>>>>> unsigned long curr_freq;
>>>>>
>>>>> - struct regulator *regulator;
>>>>> + struct opp_table *opp_table;
>>>>> +
>>>>> struct clk *clk;
>>>>> - unsigned int voltage_tolerance;
>>>>> unsigned int ratio;
>>>>> };
>>>>>
>>>>> @@ -99,56 +98,25 @@ static int exynos_bus_target(struct device *dev,
>>>>> unsigned long *freq, u32 flags)
>>>>> {
>>>>> struct exynos_bus *bus = dev_get_drvdata(dev);
>>>>> struct dev_pm_opp *new_opp;
>>>>> - unsigned long old_freq, new_freq, new_volt, tol;
>>>>> int ret = 0;
>>>>> -
>>>>> - /* Get new opp-bus instance according to new bus clock */
>>>>> + /*
>>>>> + * New frequency for bus may not be exactly matched to opp, adjust
>>>>> + * *freq to correct value.
>>>>> + */
>>>>
>>>> You better to change this comment with following styles
>>>> to keep the consistency:
>>>>
>>>>/* Get correct frequency for bus ... */
>>>>
>>>>> new_opp = devfreq_recommended_opp(dev, freq, flags);
>>>>> if (IS_ERR(new_opp)) {
>>>>> dev_err(dev, "failed to get recommended opp instance\n");
>>>>> return PTR_ERR(new_opp);
>>>>> }
>>>>>
>>>>> - new_freq = dev_pm_opp_get_freq(new_opp);
>>>>> - new_volt = dev_pm_opp_get_voltage(new_opp);
>>>>> dev_pm_opp_put(new_opp);
>>>>>
>>>>> - old_freq = bus->curr_freq;
>>>>> -
>>>>> - if (old_freq == new_freq)
>>>>> - return
Re: [PATCH v2 2/4] devfreq: exynos-bus: convert to use dev_pm_opp_set_rate()
Hi Bartlomiej,
On 19. 7. 16. 오후 7:13, Bartlomiej Zolnierkiewicz wrote:
>
> Hi Chanwoo,
>
> On 7/16/19 5:56 AM, Chanwoo Choi wrote:
>> Hi Kamil,
>>
>> Looks good to me. But, this patch has some issue.
>> I added the detailed reviews.
>>
>> I recommend that you make the separate patches as following
>> in order to clarify the role of which apply the dev_pm_opp_* function.
>>
>> First patch,
>> Need to consolidate the following two function into one function.
>> because the original exynos-bus.c has the problem that the regulator
>> of parent devfreq device have to be enabled before enabling the clock.
>> This issue did not happen because bootloader enables the bus-related
>> regulators before kernel booting.
>> - exynos_bus_parse_of()
>> - exynos_bus_parent_parse_of()
>>> Second patch,
>> Apply dev_pm_opp_set_regulators() and dev_pm_opp_set_rate()
>>
>>
>> On 19. 7. 15. 오후 9:04, Kamil Konieczny wrote:
>>> Reuse opp core code for setting bus clock and voltage. As a side
>>> effect this allow useage of coupled regulators feature (required
>>> for boards using Exynos5422/5800 SoCs) because dev_pm_opp_set_rate()
>>> uses regulator_set_voltage_triplet() for setting regulator voltage
>>> while the old code used regulator_set_voltage_tol() with fixed
>>> tolerance. This patch also removes no longer needed parsing of DT
>>> property "exynos,voltage-tolerance" (no Exynos devfreq DT node uses
>>> it).
>>>
>>> Signed-off-by: Kamil Konieczny
>>> ---
>>> drivers/devfreq/exynos-bus.c | 172 ++-
>>> 1 file changed, 66 insertions(+), 106 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 486cc5b422f1..7fc4f76bd848 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -25,7 +25,6 @@
>>> #include
>>>
>>> #define DEFAULT_SATURATION_RATIO 40
>>> -#define DEFAULT_VOLTAGE_TOLERANCE 2
>>>
>>> struct exynos_bus {
>>> struct device *dev;
>>> @@ -37,9 +36,9 @@ struct exynos_bus {
>>>
>>> unsigned long curr_freq;
>>>
>>> - struct regulator *regulator;
>>> + struct opp_table *opp_table;
>>> +
>>> struct clk *clk;
>>> - unsigned int voltage_tolerance;
>>> unsigned int ratio;
>>> };
>>>
>>> @@ -99,56 +98,25 @@ static int exynos_bus_target(struct device *dev,
>>> unsigned long *freq, u32 flags)
>>> {
>>> struct exynos_bus *bus = dev_get_drvdata(dev);
>>> struct dev_pm_opp *new_opp;
>>> - unsigned long old_freq, new_freq, new_volt, tol;
>>> int ret = 0;
>>> -
>>> - /* Get new opp-bus instance according to new bus clock */
>>> + /*
>>> +* New frequency for bus may not be exactly matched to opp, adjust
>>> +* *freq to correct value.
>>> +*/
>>
>> You better to change this comment with following styles
>> to keep the consistency:
>>
>> /* Get correct frequency for bus ... */
>>
>>> new_opp = devfreq_recommended_opp(dev, freq, flags);
>>> if (IS_ERR(new_opp)) {
>>> dev_err(dev, "failed to get recommended opp instance\n");
>>> return PTR_ERR(new_opp);
>>> }
>>>
>>> - new_freq = dev_pm_opp_get_freq(new_opp);
>>> - new_volt = dev_pm_opp_get_voltage(new_opp);
>>> dev_pm_opp_put(new_opp);
>>>
>>> - old_freq = bus->curr_freq;
>>> -
>>> - if (old_freq == new_freq)
>>> - return 0;
>>> - tol = new_volt * bus->voltage_tolerance / 100;
>>> -
>>> /* Change voltage and frequency according to new OPP level */
>>> mutex_lock(>lock);
>>> + ret = dev_pm_opp_set_rate(dev, *freq);
>>> + if (!ret)
>>> + bus->curr_freq = *freq;
>>
>> Have to print the error log if ret has minus error value.
>
> dev_pm_opp_set_rate() should print the error message on all
> errors so wouldn't printing the error log also here be superfluous?
>
> [ Please also note that the other user of dev_pm_opp_set_rate()
> (cpufreq-dt cpufreq driver) doesn't do this. ]
OK. Thanks for the explanation.
>
>> Modify it as following:
>>
>> if (ret < 0) {
>> dev_err(dev, "failed to se
Re: [PATCH v1 08/50] clk: samsung: change aclk266_isp clocks definitions Exynos5420
_MSPLL_CCORE, "mout_mx_mspll_ccore",
> mout_group5_5800_p, SRC_TOP7, 16, 2),
> MUX_F(0, "mout_mau_epll_clk", mout_mau_epll_clk_p, SRC_TOP7, 20, 2,
> @@ -641,8 +656,6 @@ static const struct samsung_mux_clock exynos5x_mux_clks[]
> __initconst = {
> SRC_TOP4, 8, 1),
> MUX(0, "mout_user_aclk333_432_isp0", mout_user_aclk333_432_isp0_p,
> SRC_TOP4, 12, 1),
> - MUX(0, "mout_user_aclk266_isp", mout_user_aclk266_isp_p,
> - SRC_TOP4, 16, 1),
> MUX(0, "mout_user_aclk266", mout_user_aclk266_p, SRC_TOP4, 20, 1),
> MUX(0, "mout_user_aclk166", mout_user_aclk166_p, SRC_TOP4, 24, 1),
> MUX(CLK_MOUT_USER_ACLK333, "mout_user_aclk333", mout_user_aclk333_p,
>
I checked it on Exynos5420/5422 TRM.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 10/50] clk: samsung: change ACLK100_NOC clocks definitions Exynos5x
Hi,
I checked the range of ratio as following: Looks good to me.
But, you better to make it to fix the ratio range without adding ID.
Please merge the code related to adding IDs into one patch.
- Exynos5422 TRM ACLK_100_NOC_RATIO [23:20]
- Exynos5420 TRM ACLK_100_NOC_RATIO [22:20]
On 19. 7. 15. 오후 9:43, Lukasz Luba wrote:
> The ACLK100_NOC has different topology in Exynos5420 and 5422/5800. In
> Exynos5420 this clock divider has 3 bits while in 5422/5800 has 4 bits.
> The patch adds needed dividers in the exynos5800_div_clks, updates
> exynos5x_div_clks and exynos5420_div_clks properly. It also adds IDs to
> manage clocks from DT.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 6164d0ca75e0..c13f34d3d9a1 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -471,7 +471,8 @@ static const struct samsung_mux_clock
> exynos5800_mux_clks[] __initconst = {
> SRC_TOP0, 4, 3),
> MUX(CLK_MOUT_ACLK400_WCORE, "mout_aclk400_wcore", mout_group2_5800_p,
> SRC_TOP0, 16, 3),
> - MUX(0, "mout_aclk100_noc", mout_group1_5800_p, SRC_TOP0, 20, 2),
> + MUX(CLK_MOUT_ACLK100_NOC, "mout_aclk100_noc", mout_group1_5800_p,
> + SRC_TOP0, 20, 2),
Please squash this code to the patch which add the IDs.
Actually, it is not related to fix the rate range of clock.
>
> MUX(0, "mout_aclk333_432_gscl", mout_group6_5800_p, SRC_TOP1, 0, 2),
> MUX(0, "mout_aclk333_432_isp", mout_group6_5800_p, SRC_TOP1, 4, 2),
> @@ -534,6 +535,8 @@ static const struct samsung_mux_clock
> exynos5800_mux_clks[] __initconst = {
> static const struct samsung_div_clock exynos5800_div_clks[] __initconst = {
> DIV(CLK_DOUT_ACLK400_WCORE, "dout_aclk400_wcore",
> "mout_aclk400_wcore", DIV_TOP0, 16, 3),
> + DIV(CLK_DOUT_ACLK100_NOC, "dout_aclk100_noc", "mout_aclk100_noc",
> + DIV_TOP0, 20, 4),
> DIV(CLK_DOUT_ACLK266_ISP, "dout_aclk266_isp", "mout_aclk266_isp",
> DIV_TOP8, 12, 3),
> DIV(0, "dout_aclk550_cam", "mout_aclk550_cam",
> @@ -569,7 +572,8 @@ static const struct samsung_mux_clock
> exynos5420_mux_clks[] __initconst = {
> SRC_TOP0, 4, 2),
> MUX(CLK_MOUT_ACLK400_WCORE, "mout_aclk400_wcore", mout_group1_p,
> SRC_TOP0, 16, 2),
> - MUX(0, "mout_aclk100_noc", mout_group1_p, SRC_TOP0, 20, 2),
> + MUX(CLK_MOUT_ACLK100_NOC, "mout_aclk100_noc", mout_group1_p,
> + SRC_TOP0, 20, 2),
ditto.
Please squash this code to the patch which add the IDs.
Actually, it is not related to fix the rate range of clock.
>
> MUX(0, "mout_aclk333_432_gscl", mout_group4_p, SRC_TOP1, 0, 2),
> MUX(0, "mout_aclk333_432_isp", mout_group4_p,
> @@ -600,6 +604,8 @@ static const struct samsung_mux_clock
> exynos5420_mux_clks[] __initconst = {
> static const struct samsung_div_clock exynos5420_div_clks[] __initconst = {
> DIV(CLK_DOUT_ACLK400_WCORE, "dout_aclk400_wcore",
> "mout_aclk400_wcore", DIV_TOP0, 16, 3),
> + DIV(CLK_DOUT_ACLK100_NOC, "dout_aclk100_noc", "mout_aclk100_noc",
> + DIV_TOP0, 20, 3),
> };
>
> static const struct samsung_gate_clock exynos5420_gate_clks[] __initconst = {
> @@ -798,8 +804,6 @@ static const struct samsung_div_clock exynos5x_div_clks[]
> __initconst = {
> DIV_TOP0, 8, 3),
> DIV(CLK_DOUT_ACLK200_FSYS2, "dout_aclk200_fsys2", "mout_aclk200_fsys2",
> DIV_TOP0, 12, 3),
> - DIV(CLK_DOUT_ACLK100_NOC, "dout_aclk100_noc", "mout_aclk100_noc",
> - DIV_TOP0, 20, 3),
> DIV(CLK_DOUT_PCLK200_FSYS, "dout_pclk200_fsys", "mout_pclk200_fsys",
> DIV_TOP0, 24, 3),
> DIV(CLK_DOUT_ACLK200_FSYS, "dout_aclk200_fsys", "mout_aclk200_fsys",
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 01/50] clk: samsung: add new IDs for Exynos5420 clocks
Hi, Usually, when developing the clock controller driver, define the same sequence between the definition sequence in dt-bibing and clock driver. As I replied, if you squash patches, it is easy. For example, This series add clock id as following. 569 MUX(CLK_MOUT_ACLK400_ISP, "mout_aclk400_isp", mout_group1_p, 570 SRC_TOP0, 0, 2), 571 MUX(CLK_MOUT_ACLK400_MSCL, "mout_aclk400_mscl", mout_group1_p, 572 SRC_TOP0, 4, 2), 573 MUX(CLK_MOUT_ACLK400_WCORE, "mout_aclk400_wcore", mout_group1_p, 574 SRC_TOP0, 16, 2), 575 MUX(CLK_MOUT_ACLK100_NOC, "mout_aclk100_noc", mout_group1_p, 576 SRC_TOP0, 20, 2), In case of this code, you can define the IDs as following sequentially: #define CLK_MOUT_ACLK400_ISP ... #define CLK_MOUT_ACLK400_MSCL ... #define CLK_MOUT_ACLK400_WCORE ... #define CLK_MOUT_ACLK100_NOC ... But, this series define the ID as following: #define CLK_MOUT_ACLK400_WCORE 662 #define CLK_MOUT_SCLK_DPLL 663 #define CLK_MOUT_ACLK100_NOC664 #define CLK_MOUT_ACLK200_FSYS2 665 #define CLK_MOUT_PCLK200_FSYS 666 #define CLK_MOUT_ACLK200_FSYS 667 #define CLK_MOUT_ACLK400_ISP668 #define CLK_MOUT_ACLK400_MSCL 669 #define CLK_MOUT_SCLK_MPLL 700 #define CLK_MOUT_ACLK266701 #define CLK_MOUT_UART0 702 #define CLK_MOUT_UART1 703 #define CLK_MOUT_UART2 704 #define CLK_MOUT_UART3 7 On 19. 7. 15. 오후 9:43, Lukasz Luba wrote: > There is a need of new IDs which will be used for modeling proper hierarchy > in the Exynos54xx SoCs. Previous implementation rely on bootloader > settings, which are not configuring properly some clocks. > These IDs provide interface to set proper parents. > > Signed-off-by: Lukasz Luba > --- > include/dt-bindings/clock/exynos5420.h | 27 +- > 1 file changed, 26 insertions(+), 1 deletion(-) > > diff --git a/include/dt-bindings/clock/exynos5420.h > b/include/dt-bindings/clock/exynos5420.h > index 02d5ac469a3d..c37a28eeaf7e 100644 > --- a/include/dt-bindings/clock/exynos5420.h > +++ b/include/dt-bindings/clock/exynos5420.h > @@ -230,6 +230,30 @@ > #define CLK_MOUT_USER_MAU_EPLL 659 > #define CLK_MOUT_SCLK_SPLL 660 > #define CLK_MOUT_MX_MSPLL_CCORE_PHY 661 > +#define CLK_MOUT_ACLK400_WCORE 662 > +#define CLK_MOUT_SCLK_DPLL 663 > +#define CLK_MOUT_ACLK100_NOC 664 > +#define CLK_MOUT_ACLK200_FSYS2 665 > +#define CLK_MOUT_PCLK200_FSYS666 > +#define CLK_MOUT_ACLK200_FSYS667 > +#define CLK_MOUT_ACLK400_ISP 668 > +#define CLK_MOUT_ACLK400_MSCL669 > +#define CLK_MOUT_SCLK_MPLL 700 > +#define CLK_MOUT_ACLK266 701 > +#define CLK_MOUT_UART0 702 > +#define CLK_MOUT_UART1 703 > +#define CLK_MOUT_UART2 704 > +#define CLK_MOUT_UART3 705 > +#define CLK_MOUT_SCLK_CPLL 706 > +#define CLK_MOUT_PWM 707 > +#define CLK_MOUT_ACLK266_G2D 708 > +#define CLK_MOUT_SW_ACLK400_WCORE709 > +#define CLK_MOUT_SW_ACLK400_MSCL 710 > +#define CLK_MOUT_SW_ACLK400_ISP 711 > +#define CLK_MOUT_SW_ACLK266_ISP 712 > +#define CLK_MOUT_USER_ACLK266_ISP713 > +#define CLK_MOUT_ACLK266_ISP 714 > +#define CLK_MOUT_MMC0715 > > /* divider clocks */ > #define CLK_DOUT_PIXEL 768 > @@ -264,8 +288,9 @@ > #define CLK_FF_DOUT_SPLL2797 > #define CLK_DOUT_PCLK_DREX0 798 > #define CLK_DOUT_PCLK_DREX1 799 > +#define CLK_DOUT_ACLK266_ISP 800 > > /* must be greater than maximal clock id */ > -#define CLK_NR_CLKS 800 > +#define CLK_NR_CLKS 801 > > #endif /* _DT_BINDINGS_CLOCK_EXYNOS_5420_H */ > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v1 13/50] clk: samsung: add DPLL rate table in Exynos5420
Hi,
Also, you better to merge patch13/patch15/patch16 to one patch
in order to add the PLL table for DPLL/MPLL/SPLL.
And I have a question. Are there any use-case to change
the PLL frequency for DPLL/MPLL/SPLL?
On 19. 7. 15. 오후 9:43, Lukasz Luba wrote:
> The DPLL has fixed frequency left by the bootloader and it is not possible
> to change it. With this patch the DPLL gets rate table the same for the
> whole PLL family (similar as APLL, KPLL according to RM) so the frequency
> might be changed to one of the values defined there.
> It is needed for further patches which change the DPLL frequency to feed
> the clocks with proper base.
> It also sets CLK_IS_CRITICAL for SCLK_DPLL due to some drivers which could
> disable master clock, which is then populated higher and tries to disable
> PLL, which casues system crash. The flag is needed for this kind of use
> cases.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 7f8221527633..2395b02ce8c5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -694,7 +694,8 @@ static const struct samsung_mux_clock exynos5x_mux_clks[]
> __initconst = {
> 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,
> CLK_SET_RATE_PARENT, 0),
> - MUX(0, "mout_sclk_dpll", mout_dpll_p, SRC_TOP6, 24, 1),
> + MUX_F(CLK_MOUT_SCLK_DPLL, "mout_sclk_dpll", mout_dpll_p,
> + SRC_TOP6, 24, 1, CLK_IS_CRITICAL, 0),
> MUX(0, "mout_sclk_cpll", mout_cpll_p, SRC_TOP6, 28, 1),
>
> MUX(CLK_MOUT_SW_ACLK400_ISP, "mout_sw_aclk400_isp",
> @@ -1514,6 +1515,7 @@ static void __init exynos5x_clk_init(struct device_node
> *np,
>
> if (_get_rate("fin_pll") == 24 * MHZ) {
> exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> + exynos5x_plls[dpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
> exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> }
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 02/50] clk: samsung: add IDs for Exynos5420 NoC clocks
Hi,
You don't need to make the separate patches according to
the type of clock just in order to add the ID by handling them
from devicetree.
Please merge following patches to one patch
- patch2, patch4~patch7, patch9, patch11, patch12, patch14, patch17
and separate from patch13, patch15, patch16 for adding the ID
On 19. 7. 15. 오후 9:43, Lukasz Luba wrote:
> The patch adds NoC WCORE clock IDs needed used for changing parent of the
> main NoC clock from the DT device.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 16ad498e3f3f..d353870e7fda 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -463,7 +463,8 @@ static const struct samsung_fixed_factor_clock
> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst = {
> MUX(0, "mout_aclk400_isp", mout_group3_5800_p, SRC_TOP0, 0, 3),
> MUX(0, "mout_aclk400_mscl", mout_group3_5800_p, SRC_TOP0, 4, 3),
> - MUX(0, "mout_aclk400_wcore", mout_group2_5800_p, SRC_TOP0, 16, 3),
> + MUX(CLK_MOUT_ACLK400_WCORE, "mout_aclk400_wcore", mout_group2_5800_p,
> + SRC_TOP0, 16, 3),
> MUX(0, "mout_aclk100_noc", mout_group1_5800_p, SRC_TOP0, 20, 2),
>
> MUX(0, "mout_aclk333_432_gscl", mout_group6_5800_p, SRC_TOP1, 0, 2),
> @@ -548,7 +549,8 @@ static const struct samsung_mux_clock
> exynos5420_mux_clks[] __initconst = {
>
> MUX(0, "mout_aclk400_isp", mout_group1_p, SRC_TOP0, 0, 2),
> MUX(0, "mout_aclk400_mscl", mout_group1_p, SRC_TOP0, 4, 2),
> - MUX(0, "mout_aclk400_wcore", mout_group1_p, SRC_TOP0, 16, 2),
> + MUX(CLK_MOUT_ACLK400_WCORE, "mout_aclk400_wcore", mout_group1_p,
> + SRC_TOP0, 16, 2),
> MUX(0, "mout_aclk100_noc", mout_group1_p, SRC_TOP0, 20, 2),
>
> MUX(0, "mout_aclk333_432_gscl", mout_group4_p, SRC_TOP1, 0, 2),
> @@ -674,8 +676,8 @@ static const struct samsung_mux_clock exynos5x_mux_clks[]
> __initconst = {
> SRC_TOP10, 8, 1),
> MUX(0, "mout_sw_aclk200_fsys2", mout_sw_aclk200_fsys2_p,
> SRC_TOP10, 12, 1),
> - MUX(0, "mout_sw_aclk400_wcore", mout_sw_aclk400_wcore_p,
> - SRC_TOP10, 16, 1),
> + MUX(CLK_MOUT_SW_ACLK400_WCORE, "mout_sw_aclk400_wcore",
> + mout_sw_aclk400_wcore_p, SRC_TOP10, 16, 1),
> MUX(0, "mout_sw_aclk100_noc", mout_sw_aclk100_noc_p,
> SRC_TOP10, 20, 1),
> MUX(0, "mout_sw_pclk200_fsys", mout_sw_pclk200_fsys_p,
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 04/50] clk: samsung: add IDs to manage aclk400_mscl in Exynos5420
Hi,
The patch4~patch7 just add the ID to control the clock from DT.
You can squash them to one patch instead of splitting out according to
the type of clock.
On 19. 7. 15. 오후 9:43, Lukasz Luba wrote:
> Add needed IDs to MUXes which are used from DT to properly set clock
> hierarchy.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 361ee53fc9fc..8f1d39cb2f1e 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -462,7 +462,8 @@ static const struct samsung_fixed_factor_clock
>
> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst = {
> MUX(0, "mout_aclk400_isp", mout_group3_5800_p, SRC_TOP0, 0, 3),
> - MUX(0, "mout_aclk400_mscl", mout_group3_5800_p, SRC_TOP0, 4, 3),
> + MUX(CLK_MOUT_ACLK400_MSCL, "mout_aclk400_mscl", mout_group3_5800_p,
> + SRC_TOP0, 4, 3),
> MUX(CLK_MOUT_ACLK400_WCORE, "mout_aclk400_wcore", mout_group2_5800_p,
> SRC_TOP0, 16, 3),
> MUX(0, "mout_aclk100_noc", mout_group1_5800_p, SRC_TOP0, 20, 2),
> @@ -548,7 +549,8 @@ static const struct samsung_mux_clock
> exynos5420_mux_clks[] __initconst = {
> TOP_SPARE2, 4, 1),
>
> MUX(0, "mout_aclk400_isp", mout_group1_p, SRC_TOP0, 0, 2),
> - MUX(0, "mout_aclk400_mscl", mout_group1_p, SRC_TOP0, 4, 2),
> + MUX(CLK_MOUT_ACLK400_MSCL, "mout_aclk400_mscl", mout_group1_p,
> + SRC_TOP0, 4, 2),
> MUX(CLK_MOUT_ACLK400_WCORE, "mout_aclk400_wcore", mout_group1_p,
> SRC_TOP0, 16, 2),
> MUX(0, "mout_aclk100_noc", mout_group1_p, SRC_TOP0, 20, 2),
> @@ -670,8 +672,8 @@ static const struct samsung_mux_clock exynos5x_mux_clks[]
> __initconst = {
>
> MUX(0, "mout_sw_aclk400_isp", mout_sw_aclk400_isp_p,
> SRC_TOP10, 0, 1),
> - MUX(0, "mout_sw_aclk400_mscl", mout_sw_aclk400_mscl_p,
> - SRC_TOP10, 4, 1),
> + MUX(CLK_MOUT_SW_ACLK400_MSCL, "mout_sw_aclk400_mscl",
> + mout_sw_aclk400_mscl_p, SRC_TOP10, 4, 1),
> MUX(CLK_MOUT_SW_ACLK200, "mout_sw_aclk200", mout_sw_aclk200_p,
> SRC_TOP10, 8, 1),
> MUX(0, "mout_sw_aclk200_fsys2", mout_sw_aclk200_fsys2_p,
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v1 03/50] clk: samsung: change parent of dout_aclk400_wcore in Exynos5420
On 19. 7. 15. 오후 9:43, Lukasz Luba wrote:
> Change parent of dout_aclk400_wcore to mout_aclk400_wcore which reflects
> topology described in the RM.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index d353870e7fda..361ee53fc9fc 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -577,7 +577,7 @@ static const struct samsung_mux_clock
> exynos5420_mux_clks[] __initconst = {
>
> static const struct samsung_div_clock exynos5420_div_clks[] __initconst = {
> DIV(CLK_DOUT_ACLK400_WCORE, "dout_aclk400_wcore",
> - "mout_aclk400_wcore_bpll", DIV_TOP0, 16, 3),
> + "mout_aclk400_wcore", DIV_TOP0, 16, 3),
> };
>
> static const struct samsung_gate_clock exynos5420_gate_clks[] __initconst = {
>
Acked-by: Chanwoo Choi
If possible, you better to send it to stable mailing list
with Fixes information.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 3/4] ARM: dts: exynos: add initial data for coupled regulators for Exynos5422/5800
Hi,
On 19. 7. 15. 오후 9:04, Kamil Konieczny wrote:
> Declare Exynos5422/5800 voltage ranges for opp points for big cpu core and
> bus wcore and couple their voltage supllies as vdd_arm and vdd_int should
> be in 300mV range.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kamil Konieczny
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 34 +--
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 4 +++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +++
> arch/arm/boot/dts/exynos5800.dtsi | 32 -
> 4 files changed, 41 insertions(+), 33 deletions(-)
Reviewed-by: Chanwoo Choi
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 5fb2326875dc..0cbf74750553 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -48,62 +48,62 @@
> opp-shared;
> opp-18 {
> opp-hz = /bits/ 64 <18>;
> - opp-microvolt = <125>;
> + opp-microvolt = <125 125 150>;
> clock-latency-ns = <14>;
> };
> opp-17 {
> opp-hz = /bits/ 64 <17>;
> - opp-microvolt = <1212500>;
> + opp-microvolt = <1212500 1212500 150>;
> clock-latency-ns = <14>;
> };
> opp-16 {
> opp-hz = /bits/ 64 <16>;
> - opp-microvolt = <1175000>;
> + opp-microvolt = <1175000 1175000 150>;
> clock-latency-ns = <14>;
> };
> opp-15 {
> opp-hz = /bits/ 64 <15>;
> - opp-microvolt = <1137500>;
> + opp-microvolt = <1137500 1137500 150>;
> clock-latency-ns = <14>;
> };
> opp-14 {
> opp-hz = /bits/ 64 <14>;
> - opp-microvolt = <1112500>;
> + opp-microvolt = <1112500 1112500 150>;
> clock-latency-ns = <14>;
> };
> opp-13 {
> opp-hz = /bits/ 64 <13>;
> - opp-microvolt = <1062500>;
> + opp-microvolt = <1062500 1062500 150>;
> clock-latency-ns = <14>;
> };
> opp-12 {
> opp-hz = /bits/ 64 <12>;
> - opp-microvolt = <1037500>;
> + opp-microvolt = <1037500 1037500 150>;
> clock-latency-ns = <14>;
> };
> opp-11 {
> opp-hz = /bits/ 64 <11>;
> - opp-microvolt = <1012500>;
> + opp-microvolt = <1012500 1012500 150>;
> clock-latency-ns = <14>;
> };
> opp-10 {
> opp-hz = /bits/ 64 <10>;
> - opp-microvolt = < 987500>;
> + opp-microvolt = < 987500 987500 150>;
> clock-latency-ns = <14>;
> };
> opp-9 {
> opp-hz = /bits/ 64 <9>;
> - opp-microvolt = < 962500>;
> + opp-microvolt = < 962500 962500 150>;
> clock-latency-ns = <14>;
> };
> opp-8 {
> opp-hz = /bits/ 64 <8>;
> - opp-microvolt = < 937500>;
> + opp-microvolt = < 937500 937500 150>;
> clock-lat
Re: [PATCH v2 4/4] dt-bindings: devfreq: exynos-bus: remove unused property
Hi, On 19. 7. 15. 오후 9:04, Kamil Konieczny wrote: > Remove unused DT property "exynos,voltage-tolerance". > > Signed-off-by: Kamil Konieczny > --- > Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > index f8e946471a58..e71f752cc18f 100644 > --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > @@ -50,8 +50,6 @@ Required properties only for passive bus device: > Optional properties only for parent bus device: > - exynos,saturation-ratio: the percentage value which is used to calibrate > the performance count against total cycle count. > -- exynos,voltage-tolerance: the percentage value for bus voltage tolerance > - which is used to calculate the max voltage. > > Detailed correlation between sub-blocks and power line according to Exynos > SoC: > - In case of Exynos3250, there are two power line as following: > Acked-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 1/4] opp: core: add regulators enable and disable
Hi Kamil,
On 19. 7. 15. 오후 9:04, Kamil Konieczny wrote:
> Add enable regulators to dev_pm_opp_set_regulators() and disable
> regulators to dev_pm_opp_put_regulators(). This prepares for
> converting exynos-bus devfreq driver to use dev_pm_opp_set_rate().
IMHO, it is not proper to mention the specific driver name.
If you explain the reason why enable the regulator before using it,
it is enough description.
>
> Signed-off-by: Kamil Konieczny
> --
> Changes in v2:
>
> - move regulator enable and disable into loop
>
> ---
> drivers/opp/core.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 0e7703fe733f..069c5cf8827e 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -1570,6 +1570,10 @@ struct opp_table *dev_pm_opp_set_regulators(struct
> device *dev,
> goto free_regulators;
> }
>
> + ret = regulator_enable(reg);
> + if (ret < 0)
> + goto disable;
> +
> opp_table->regulators[i] = reg;
> }
>
> @@ -1582,9 +1586,15 @@ struct opp_table *dev_pm_opp_set_regulators(struct
> device *dev,
>
> return opp_table;
>
> +disable:
> + regulator_put(reg);
> + --i;
> +
> free_regulators:
> - while (i != 0)
> - regulator_put(opp_table->regulators[--i]);
> + for (; i >= 0; --i) {
> + regulator_disable(opp_table->regulators[i]);
> + regulator_put(opp_table->regulators[i]);
> + }
>
> kfree(opp_table->regulators);
> opp_table->regulators = NULL;
> @@ -1610,8 +1620,10 @@ void dev_pm_opp_put_regulators(struct opp_table
> *opp_table)
> /* Make sure there are no concurrent readers while updating opp_table */
> WARN_ON(!list_empty(_table->opp_list));
>
> - for (i = opp_table->regulator_count - 1; i >= 0; i--)
> + for (i = opp_table->regulator_count - 1; i >= 0; i--) {
> + regulator_disable(opp_table->regulators[i]);
> regulator_put(opp_table->regulators[i]);
> + }
>
> _free_set_opp_data(opp_table);
>
>
I agree to enable the regulator before using it.
The bootloader might not enable the regulators
and the kernel need to enable regulator in order to increase
the reference count explicitly event if bootloader enables it.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 2/4] devfreq: exynos-bus: convert to use dev_pm_opp_set_rate()
t; @@ -314,22 +253,15 @@ static int exynos_bus_parent_parse_of(struct
> device_node *np,
> if (of_property_read_u32(np, "exynos,saturation-ratio", >ratio))
> bus->ratio = DEFAULT_SATURATION_RATIO;
>
> - if (of_property_read_u32(np, "exynos,voltage-tolerance",
> - >voltage_tolerance))
> - bus->voltage_tolerance = DEFAULT_VOLTAGE_TOLERANCE;
> -
> return 0;
> -
> -err_regulator:
> - regulator_disable(bus->regulator);
> -
> - return ret;
> }
>
> static int exynos_bus_parse_of(struct device_node *np,
> - struct exynos_bus *bus)
> + struct exynos_bus *bus, bool passive)
> {
> struct device *dev = bus->dev;
> + struct opp_table *opp_table;
> + const char *vdd = "vdd";
> struct dev_pm_opp *opp;
> unsigned long rate;
> int ret;
> @@ -347,11 +279,22 @@ static int exynos_bus_parse_of(struct device_node *np,
> return ret;
> }
>
> + if (!passive) {
> + opp_table = dev_pm_opp_set_regulators(dev, , 1);
> + if (IS_ERR(opp_table)) {
> + ret = PTR_ERR(opp_table);
> + dev_err(dev, "failed to set regulators %d\n", ret);
> + goto err_clk;/
> + }
> +
> + bus->opp_table = opp_table;
> + }
This driver has exynos_bus_parent_parse_of() function for parent devfreq device.
dev_pm_opp_set_regulators() have to be called in exynos_bus_parent_parse_of()
because the regulator is only used by parent devfreq device.
> +
> /* Get the freq and voltage from OPP table to scale the bus freq */
> ret = dev_pm_opp_of_add_table(dev);
> if (ret < 0) {
> dev_err(dev, "failed to get OPP table\n");
> - goto err_clk;
> + goto err_regulator;
> }
>
> rate = clk_get_rate(bus->clk);
> @@ -362,6 +305,7 @@ static int exynos_bus_parse_of(struct device_node *np,
> ret = PTR_ERR(opp);
> goto err_opp;
> }
> +
> bus->curr_freq = dev_pm_opp_get_freq(opp);
> dev_pm_opp_put(opp);
>
> @@ -369,6 +313,13 @@ static int exynos_bus_parse_of(struct device_node *np,
>
> err_opp:
> dev_pm_opp_of_remove_table(dev);
> +
> +err_regulator:
> + if (bus->opp_table) {
> + dev_pm_opp_put_regulators(bus->opp_table);
> + bus->opp_table = NULL;
> + }
As I mentioned above, it it wrong to call dev_pm_opp_put_regulators()
after removing the opp_table by dev_pm_opp_of_remove_table().
> +
> err_clk:
> clk_disable_unprepare(bus->clk);
>
> @@ -386,6 +337,7 @@ static int exynos_bus_probe(struct platform_device *pdev)
> struct exynos_bus *bus;
> int ret, max_state;
> unsigned long min_freq, max_freq;
> + bool passive = false;
>
> if (!np) {
> dev_err(dev, "failed to find devicetree node\n");
> @@ -395,12 +347,18 @@ static int exynos_bus_probe(struct platform_device
> *pdev)
> bus = devm_kzalloc(>dev, sizeof(*bus), GFP_KERNEL);
> if (!bus)
> return -ENOMEM;
> +
> mutex_init(>lock);
> bus->dev = >dev;
> platform_set_drvdata(pdev, bus);
> + node = of_parse_phandle(dev->of_node, "devfreq", 0);
> + if (node) {
> + of_node_put(node);
> + passive = true;
> + }
>
> /* Parse the device-tree to get the resource information */
> - ret = exynos_bus_parse_of(np, bus);
> + ret = exynos_bus_parse_of(np, bus, passive);
> if (ret < 0)
> return ret;
>
> @@ -410,13 +368,10 @@ static int exynos_bus_probe(struct platform_device
> *pdev)
> goto err;
> }
>
> - node = of_parse_phandle(dev->of_node, "devfreq", 0);
> - if (node) {
> - of_node_put(node);
> + if (passive)
> goto passive;
> - } else {
> - ret = exynos_bus_parent_parse_of(np, bus);
> - }
> +
> + ret = exynos_bus_parent_parse_of(np, bus);
>
Remove unneeded blank line.
> if (ret < 0)
> goto err;
> @@ -509,6 +464,11 @@ static int exynos_bus_probe(struct platform_device *pdev)
>
> err:
> dev_pm_opp_of_remove_table(dev);
> + if (bus->opp_table) {
> + dev_pm_opp_put_regulators(bus->opp_table);
> + bus->opp_table = NULL;
> + }
> +
ditto.
Have to disable regulator after disabling the clock
to prevent the h/w fault.
I think that you should call them with following sequence:
clk_disable_unprepare(bus->clk);
if (bus->opp_table)
dev_pm_opp_put_regulators(bus->opp_table);
dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
>
> return ret;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] devfreq: tegra20: add COMMON_CLK dependency
Hi Arnd,
Thanks for fixup.
Reviewed-by: Chanwoo Choi
Hi Myungjoo,
This patch have to be merged for linux 5.3 before sending pull-request
because it fixed the build error of merged patch[1] on devfreq.git.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/commit/?h=for-next=028b3793284fa1bb4db73a90608d7cb24664480c
Best Regards,
Chanwoo Choi
On 19. 6. 28. 오후 7:32, Arnd Bergmann wrote:
> Compile-testing the new driver on platforms without CONFIG_COMMON_CLK
> leads to a link error:
>
> drivers/devfreq/tegra20-devfreq.o: In function `tegra_devfreq_target':
> tegra20-devfreq.c:(.text+0x288): undefined reference to `clk_set_min_rate'
>
> Add a dependency on COMMON_CLK to avoid this.
>
> Fixes: 1d39ee8dad6d ("PM / devfreq: Introduce driver for NVIDIA Tegra20")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/devfreq/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index f3b242987fd9..defe1d438710 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -107,6 +107,7 @@ config ARM_TEGRA_DEVFREQ
> config ARM_TEGRA20_DEVFREQ
> tristate "NVIDIA Tegra20 DEVFREQ Driver"
> depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST
> + depends on COMMON_CLK
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> select PM_OPP
> help
>
Re: [PATCH 41/43] docs: extcon: convert it to ReST and move to acpi dir
Hi Mauro,
On 19. 6. 28. 오후 9:20, Mauro Carvalho Chehab wrote:
> The intel-int3496.txt file is a documentation for an ACPI driver.
>
> There's no reason to keep it on a separate directory.
>
> So, instead of keeping it on some random location, move it
> to a sub-directory inside the ACPI documentation dir,
> renaming it to .rst.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../acpi/extcon-intel-int3496.rst} | 14 ++
> Documentation/firmware-guide/acpi/index.rst| 1 +
> MAINTAINERS| 6 +++---
> 3 files changed, 14 insertions(+), 7 deletions(-)
> rename Documentation/{extcon/intel-int3496.txt =>
> firmware-guide/acpi/extcon-intel-int3496.rst} (66%)
>
> diff --git a/Documentation/extcon/intel-int3496.txt
> b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> similarity index 66%
> rename from Documentation/extcon/intel-int3496.txt
> rename to Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> index 8155dbc7fad3..5137ca834b54 100644
> --- a/Documentation/extcon/intel-int3496.txt
> +++ b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> @@ -1,5 +1,6 @@
> +=
> Intel INT3496 ACPI device extcon driver documentation
> --
> +=
>
> The Intel INT3496 ACPI device extcon driver is a driver for ACPI
> devices with an acpi-id of INT3496, such as found for example on
> @@ -13,15 +14,20 @@ between an USB host and an USB peripheral controller.
> The ACPI devices exposes this functionality by returning an array with up
> to 3 gpio descriptors from its ACPI _CRS (Current Resource Settings) call:
>
> -Index 0: The input gpio for the id-pin, this is always present and valid
> -Index 1: The output gpio for enabling Vbus output from the device to the otg
> +===
> =
> +Index 0 The input gpio for the id-pin, this is always present and valid
> +Index 1 The output gpio for enabling Vbus output from the device to the otg
> port, write 1 to enable the Vbus output (this gpio descriptor may
> be absent or invalid)
> -Index 2: The output gpio for muxing of the data pins between the USB host and
> +Index 2 The output gpio for muxing of the data pins between the USB host and
> the USB peripheral controller, write 1 to mux to the peripheral
> controller
> +===
> =
>
> There is a mapping between indices and GPIO connection IDs as follows
> +
> + === ===
> id index 0
> vbusindex 1
> mux index 2
> + === ===
> diff --git a/Documentation/firmware-guide/acpi/index.rst
> b/Documentation/firmware-guide/acpi/index.rst
> index ae609eec4679..90c90d42d9ad 100644
> --- a/Documentation/firmware-guide/acpi/index.rst
> +++ b/Documentation/firmware-guide/acpi/index.rst
> @@ -24,3 +24,4 @@ ACPI Support
> acpi-lid
> lpit
> video_extension
> + extcon-intel-int3496
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fd6fab0dec77..2cf8abf6d48e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -321,7 +321,7 @@ F:drivers/pnp/pnpacpi/
> F: include/linux/acpi.h
> F: include/linux/fwnode.h
> F: include/acpi/
> -F: Documentation/acpi/
> +F: Documentation/firmware-guide/acpi/
> F: Documentation/ABI/testing/sysfs-bus-acpi
> F: Documentation/ABI/testing/configfs-acpi
> F: drivers/pci/*acpi*
> @@ -4896,7 +4896,7 @@ S: Maintained
> F: Documentation/
> F: scripts/kernel-doc
> X: Documentation/ABI/
> -X: Documentation/acpi/
> +X: Documentation/firmware-guide/acpi/
> X: Documentation/devicetree/
> X: Documentation/i2c/
> X: Documentation/media/
> @@ -6073,7 +6073,7 @@ S: Maintained
> F: drivers/extcon/
> F: include/linux/extcon/
> F: include/linux/extcon.h
> -F: Documentation/extcon/
> +F: Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> F: Documentation/devicetree/bindings/extcon/
>
> EXYNOS DP DRIVER
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] misc: fsa9480: Delete this driver
Hi Linus, On 19. 6. 30. 오후 11:03, Linus Walleij wrote: > The FSA9480 has a new driver more appropriately located > in the drivers/extcon subsystem. It is also more complete > and includes device tree support. Delete the old misc > driver. > > Cc: Paweł Chmiel > Cc: Chanwoo Choi > Cc: Arnd Bergmann > Signed-off-by: Linus Walleij > --- > drivers/misc/Kconfig | 9 - > drivers/misc/Makefile | 1 - > drivers/misc/fsa9480.c| 547 -- > include/linux/platform_data/fsa9480.h | 24 -- > 4 files changed, 581 deletions(-) > delete mode 100644 drivers/misc/fsa9480.c > delete mode 100644 include/linux/platform_data/fsa9480.h > Reviewed-by: Chanwoo Choi Best Regards, Chanwoo Choi
[GIT PULL] extcon next for v5.3
Dear Greg, This is extcon-next pull request for v5.3. I add detailed description of this pull request on below. Please pull extcon with following updates. [Detailed description for this pull request] 1. Add new extcon-fsa9480 extcon provider driver - It is extcon provider driver for Fairchild Semiconductor FSA9480 microUSB switch and accessory detector chip which detects the kind of external connector like usb, charger, audio, video and so on. 2. - Add the exception handling code for extcon-arizona.c when using the regmap interface. Best Regards, Chanwoo Choi The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-5.3 for you to fetch changes up to 0937fbb7abeb165ef0ac6a56a3a6f041eca6dbde: extcon: fsa9480: Fix Kconfig warning and build errors (2019-06-26 17:27:39 +0900) Charles Keepax (1): extcon: arizona: Correct error handling on regmap_update_bits_check Randy Dunlap (1): extcon: fsa9480: Fix Kconfig warning and build errors Tomasz Figa (2): dt-bindings: extcon: Add support for fsa9480 switch extcon: Add fsa9480 extcon driver .../devicetree/bindings/extcon/extcon-fsa9480.txt | 19 + drivers/extcon/Kconfig | 12 + drivers/extcon/Makefile| 1 + drivers/extcon/extcon-arizona.c| 33 +- drivers/extcon/extcon-fsa9480.c| 395 + 5 files changed, 447 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt create mode 100644 drivers/extcon/extcon-fsa9480.c
Re: [PATCH v4 4/5] Documentation: devicetree: add PPMU events description
Hi Lukasz, On 19. 6. 26. 오후 11:17, Lukasz Luba wrote: > Hi Krzysztof, > > On 6/26/19 4:03 PM, Krzysztof Kozlowski wrote: >> On Wed, 26 Jun 2019 at 15:58, Lukasz Luba wrote: >>> >>> Hi Chanwoo, >>> >>> On 6/26/19 10:23 AM, Chanwoo Choi wrote: >>>> Hi Lukasz, >>>> >>>> 2019년 6월 5일 (수) 18:14, Lukasz Luba >>> <mailto:l.l...@partner.samsung.com>>님이 작성: >>>> >>>> Extend the documenation by events description with new >>>> 'event-data-type' >>>> field. Add example how the event might be defined in DT. >>>> >>>> Signed-off-by: Lukasz Luba >>> <mailto:l.l...@partner.samsung.com>> >>>> Signed-off-by: Chanwoo Choi >>> <mailto:cw00.c...@samsung.com>> >>>> --- >>>>.../bindings/devfreq/event/exynos-ppmu.txt| 26 >>>> +-- >>>>1 file changed, 24 insertions(+), 2 deletions(-) >>>> >>>> >>>> >>>> Acked-by: Chanwoo Choi >> >>> Thank you for the ACKs for this a 2/5 patch. >>> Do you think the v4 could be merged now? >> >> I think you have all necessary acks. I can take the DTS patch (5/5) >> although probably for next merge window as I just sent one. > There was one patch 3/5 > https://protect2.fireeye.com/url?k=82dd0d0cbe2abd04.82dc8643-d13ecd7e5f989b8d=https://lkml.org/lkml/2019/6/5/215 > which was waiting ACK or I missed the email somehow. When I was in vacation, your patches are removed on my email account because of the email expiration. So, I replied with my Ack through gmail account on mobile phone. But, there are some problem. My reply didn't arrive the mailing list. I have no any way to reply about this at company. After leaving one's office, I'll reply with Ack again at home. > > Regards, > Lukasz > >> >> Best regards, >> Krzysztof >> >> > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH -next] extcon: fix fsa9480 Kconfig warning and build errors
Hi, On 19. 6. 26. 오전 10:10, Randy Dunlap wrote: > From: Randy Dunlap > > Fix Kconfig dependency warning and subsequent build errors caused by > the Kconfig entry for EXTCON-FSA9480. It should not select > REGMAP_I2C unless I2C is already set/enabled. > > WARNING: unmet direct dependencies detected for REGMAP_I2C > Depends on [n]: I2C [=n] > Selected by [y]: > - EXTCON_FSA9480 [=y] && EXTCON [=y] && INPUT [=y] > > ../drivers/base/regmap/regmap-i2c.c: In function ‘regmap_smbus_byte_reg_read’: > ../drivers/base/regmap/regmap-i2c.c:25:2: error: implicit declaration of > function ‘i2c_smbus_read_byte_data’ [-Werror=implicit-function-declaration] > ret = i2c_smbus_read_byte_data(i2c, reg); > ^ > ../drivers/base/regmap/regmap-i2c.c: In function > ‘regmap_smbus_byte_reg_write’: > ../drivers/base/regmap/regmap-i2c.c:43:2: error: implicit declaration of > function ‘i2c_smbus_write_byte_data’ [-Werror=implicit-function-declaration] > return i2c_smbus_write_byte_data(i2c, reg, val); > ../drivers/base/regmap/regmap-i2c.c: In function ‘regmap_smbus_word_reg_read’: > ../drivers/base/regmap/regmap-i2c.c:61:2: error: implicit declaration of > function ‘i2c_smbus_read_word_data’ [-Werror=implicit-function-declaration] > ret = i2c_smbus_read_word_data(i2c, reg); > ../drivers/base/regmap/regmap-i2c.c: In function > ‘regmap_smbus_word_reg_write’: > ../drivers/base/regmap/regmap-i2c.c:79:2: error: implicit declaration of > function ‘i2c_smbus_write_word_data’ [-Werror=implicit-function-declaration] > return i2c_smbus_write_word_data(i2c, reg, val); > ../drivers/base/regmap/regmap-i2c.c: In function > ‘regmap_smbus_word_read_swapped’: > ../drivers/base/regmap/regmap-i2c.c:97:2: error: implicit declaration of > function ‘i2c_smbus_read_word_swapped’ [-Werror=implicit-function-declaration] > ret = i2c_smbus_read_word_swapped(i2c, reg); > ../drivers/base/regmap/regmap-i2c.c: In function > ‘regmap_smbus_word_write_swapped’: > ../drivers/base/regmap/regmap-i2c.c:115:2: error: implicit declaration of > function ‘i2c_smbus_write_word_swapped’ > [-Werror=implicit-function-declaration] > return i2c_smbus_write_word_swapped(i2c, reg, val); > ../drivers/base/regmap/regmap-i2c.c: In function ‘regmap_i2c_write’: > ../drivers/base/regmap/regmap-i2c.c:129:2: error: implicit declaration of > function ‘i2c_master_send’ [-Werror=implicit-function-declaration] > ret = i2c_master_send(i2c, data, count); > ../drivers/base/regmap/regmap-i2c.c: In function ‘regmap_i2c_gather_write’: > ../drivers/base/regmap/regmap-i2c.c:150:2: error: implicit declaration of > function ‘i2c_check_functionality’ [-Werror=implicit-function-declaration] > if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_NOSTART)) > ../drivers/base/regmap/regmap-i2c.c:163:2: error: implicit declaration of > function ‘i2c_transfer’ [-Werror=implicit-function-declaration] > ret = i2c_transfer(i2c->adapter, xfer, 2); > ../drivers/base/regmap/regmap-i2c.c: In function ‘regmap_i2c_smbus_i2c_write’: > ../drivers/base/regmap/regmap-i2c.c:218:2: error: implicit declaration of > function ‘i2c_smbus_write_i2c_block_data’ > [-Werror=implicit-function-declaration] > return i2c_smbus_write_i2c_block_data(i2c, ((u8 *)data)[0], count, > ../drivers/base/regmap/regmap-i2c.c: In function ‘regmap_i2c_smbus_i2c_read’: > ../drivers/base/regmap/regmap-i2c.c:233:2: error: implicit declaration of > function ‘i2c_smbus_read_i2c_block_data’ > [-Werror=implicit-function-declaration] > ret = i2c_smbus_read_i2c_block_data(i2c, ((u8 *)reg)[0], val_size, val); > > ../drivers/extcon/extcon-fsa9480.c: In function ‘fsa9480_module_init’: > ../drivers/extcon/extcon-fsa9480.c:383:2: error: implicit declaration of > function ‘i2c_add_driver’ [-Werror=implicit-function-declaration] > return i2c_add_driver(_i2c_driver); > ../drivers/extcon/extcon-fsa9480.c: In function ‘fsa9480_module_exit’: > ../drivers/extcon/extcon-fsa9480.c:389:2: error: implicit declaration of > function ‘i2c_del_driver’ [-Werror=implicit-function-declaration] > i2c_del_driver(_i2c_driver); > > Signed-off-by: Randy Dunlap > Cc: Tomasz Figa > Cc: MyungJoo Ham > Cc: Chanwoo Choi > --- > Found in mmotm; applies to linux-next. > > To extcon maintainers: there are a few more extcon driver Kconfig > entries that seem to have this same problem of selecting REGMAP_I2C > without checking that I2C is set/enabled. Thanks for your fixup. I'll check it with more effort. Applied it. > > drivers/extcon/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- mmotm-2019-0625-1620.orig/drivers/extcon/Kconfig > +++ mmotm-2019-0625-1620/drivers/extcon/Kconfig > @@ -39,7 +39,7 @@ config EXTCON_AXP288 > > config EXTCON_FSA9480 > tristate "FSA9480 EXTCON Support" > - depends on INPUT > + depends on INPUT && I2C > select IRQ_DOMAIN > select REGMAP_I2C > help > > > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH RFC 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor
Hello Sibi and Hsin-Yi, On 19. 6. 20. 오후 6:41, Sibi Sankar wrote: > Hey Hsin-Yi, Chanwoo > > On 2019-06-20 15:02, Hsin-Yi Wang wrote: >> Hi Chanwoo Choi, Saravana Kannan and Sibi Sankar, >> >> I've also tested Sibi Sankar's patch[1] locally with mt8183-cci, and >> it works fine too! >> It'd be great if Sibi Sankar or anyone who is familiar with the >> original design can finish this implementation. But if no one has time >> to do that, I think I can also help on address the comments. Thanks! > > Now that we have a user :) I am happy > to repost the patch with the comments > addressed. > > https://lkml.org/lkml/2019/6/14/4 > Also with ^^ patch and few more in the > series the dt parsing of required-opps > should get further simplified. Even if patch[1] suggested by Saravana is merged, the patch[2] is necessary. Because, until now, the child devfreq device cannot catch the timing of CPU frequency without CPUFREQ notification. The existing passive governor only supports between devfreq device and other devfreq device. [1] https://lkml.org/lkml/2019/6/14/4 [2] [PATCH RFC 0/9] Add CPU based scaling support to Passive governor - https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/ [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor - https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/#m1cafb7baf687d2a680d39c85d3ec7d1b590b68fc > >> >> >> [1] >> [RFC,2/9] OPP: Export a number of helpers to prevent code duplication >> - https://patchwork.kernel.org/patch/10875199/ >> [RFC,3/9] PM / devfreq: Add cpu based scaling support to passive_governor >> - https://patchwork.kernel.org/patch/10875195/ >> >> Hsin-Yi >> >> On Thu, Jun 20, 2019 at 2:56 PM Chanwoo Choi wrote: >>> >>> + Sibi Sankar >>> >>> Hi, Hsin-Yi Wang, Saravana Kannan and Sibi Sankar >>> >>> I summarized the history of the related patch about this title. >>> >>> Firstly, >>> As I knew, Saravana sent the patch[1] which contains >>> 'governor_cpufreq_map.c' last year. According to the Myungoo's comment, >>> >>> Secondly, >>> Sibi Sankar modified the 'governor_passive.c'[2] in order to support >>> the mapping between cpu frequency and device frequency. >>> Unfortunately, Sibi Sankar stopped the development about this >>> because he had found the other method to get his purpose as I knew. >>> >>> Thirdly, >>> Hsin-Yi Wang send the original patch of Saravana without modification. >>> >>> >>> Sincerely, I think that the mapping between cpu frequency and device >>> frequency is necessary. And I prefer the Sibi's approach which implements >>> stuff to the existing 'passive' governor. >>> >>> We need to discuss about how to implement them by whom. >>> >>> >>> [1] [v3,1/2] PM / devfreq: Generic CPU frequency to device frequency >>> mapping governor >>> - https://patchwork.kernel.org/patch/10553171/ >>> >>> [2] >>> [PATCH RFC 0/9] Add CPU based scaling support to Passive governor >>> - >>> https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/ >>> [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to >>> passive_governor >>> - >>> https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/#m1cafb7baf687d2a680d39c85d3ec7d1b590b68fc >>> >>> >>> Best Regards, >>> Chanwoo Choi >>> >>> On 19. 6. 18. 오후 1:14, Hsin-Yi Wang wrote: >>> > From: Saravana Kannan >>> > >>> > From: Saravana Kannan >>> > >>> > Many CPU architectures have caches that can scale independent of the CPUs. >>> > Frequency scaling of the caches is necessary to make sure the cache is not >>> > a performance bottleneck that leads to poor performance and power. The >>> > same >>> > idea applies for RAM/DDR. >>> > >>> > To achieve this, this patch adds a generic devfreq governor that takes the >>> > current frequency of each CPU frequency domain and then adjusts the >>> > frequency of the cache (or any devfreq device) based on the frequency of >>> > the CPUs. It listens to CPU frequency transition notifiers to keep itself >>> > up to date on the current CPU frequency. >>> > >>> > To decide the frequency of the device, the governor does one of the >>> > following: >>>
Re: [PATCH v2 4/4] PM / devfreq: Add required OPPs support to passive governor
Hi Saravana,
On 19. 6. 26. 오전 6:33, Saravana Kannan wrote:
> Look at the required OPPs of the "parent" device to determine the OPP that
> is required from the slave device managed by the passive governor. This
> allows having mappings between a parent device and a slave device even when
> they don't have the same number of OPPs.
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/devfreq/governor_passive.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/devfreq/governor_passive.c
> b/drivers/devfreq/governor_passive.c
> index 3bc29acbd54e..f6de03de7a64 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -22,7 +22,7 @@ static int devfreq_passive_get_target_freq(struct devfreq
> *devfreq,
> = (struct devfreq_passive_data *)devfreq->data;
> struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
> unsigned long child_freq = ULONG_MAX;
> - struct dev_pm_opp *opp;
> + struct dev_pm_opp *opp = NULL, *p_opp = NULL;
> int i, count, ret = 0;
>
> /*
> @@ -59,13 +59,20 @@ static int devfreq_passive_get_target_freq(struct devfreq
> *devfreq,
>* list of parent device. Because in this case, *freq is temporary
>* value which is decided by ondemand governor.
>*/
> - opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0);
> - if (IS_ERR(opp)) {
> - ret = PTR_ERR(opp);
> + p_opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0);
> + if (IS_ERR(p_opp)) {
> + ret = PTR_ERR(p_opp);
> goto out;
> }
>
> - dev_pm_opp_put(opp);
> + if (devfreq->opp_table && parent_devfreq->opp_table)
> + opp = dev_pm_opp_xlate_opp(parent_devfreq->opp_table,
> +devfreq->opp_table, p_opp);
> + if (opp) {
> + *freq = dev_pm_opp_get_freq(opp);
> + dev_pm_opp_put(opp);
> + goto out;
> + }
>
> /*
>* Get the OPP table's index of decided freqeuncy by governor
> @@ -92,6 +99,9 @@ static int devfreq_passive_get_target_freq(struct devfreq
> *devfreq,
> *freq = child_freq;
>
> out:
> + if (!IS_ERR_OR_NULL(opp))
> + dev_pm_opp_put(p_opp);
> +
> return ret;
> }
>
>
I agree this approach. It is necessary.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 3/4] PM / devfreq: Cache OPP table reference in devfreq
Hi Saravana,
On 19. 6. 26. 오전 6:33, Saravana Kannan wrote:
> The OPP table can be used often in devfreq. Trying to get it each time can
> be expensive, so cache it in the devfreq struct.
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/devfreq/devfreq.c | 6 ++
> include/linux/devfreq.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 6b6991f0e873..ac62b78dc035 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -597,6 +597,8 @@ static void devfreq_dev_release(struct device *dev)
> if (devfreq->profile->exit)
> devfreq->profile->exit(devfreq->dev.parent);
>
> + if (devfreq->opp_table)
> + dev_pm_opp_put_opp_table(devfreq->opp_table);
> mutex_destroy(>lock);
> kfree(devfreq);
> }
> @@ -677,6 +679,10 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->max_freq = devfreq->scaling_max_freq;
>
> devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
> + devfreq->opp_table = dev_pm_opp_get_opp_table(dev);
> + if (IS_ERR(devfreq->opp_table))
> + devfreq->opp_table = NULL;
> +
> atomic_set(>suspend_count, 0);
>
> dev_set_name(>dev, "devfreq%d",
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index fbffa74bfc1b..0d877c9513d7 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -156,6 +156,7 @@ struct devfreq {
> struct devfreq_dev_profile *profile;
> const struct devfreq_governor *governor;
> char governor_name[DEVFREQ_NAME_LEN];
> + struct opp_table *opp_table;
> struct notifier_block nb;
> struct delayed_work work;
>
>
Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v10 09/13] drivers: devfreq: events: add Exynos PPMU new events
On 19. 6. 25. 오후 4:31, Lukasz Luba wrote:
>
>
> On 6/22/19 3:10 PM, Chanwoo Choi wrote:
>> Hi,
>>
>> 2019년 6월 14일 (금) 오후 6:54, Lukasz Luba 님이 작성:
>>>
>>> Define new performance events supported by Exynos5422 SoC counters.
>>> The counters are built-in in Dynamic Memory Controller and provide
>>> information regarding memory utilization.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> drivers/devfreq/event/exynos-ppmu.c | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/event/exynos-ppmu.c
>>> b/drivers/devfreq/event/exynos-ppmu.c
>>> index c2ea94957501..ce658c262c27 100644
>>> --- a/drivers/devfreq/event/exynos-ppmu.c
>>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>>> @@ -89,6 +89,12 @@ static struct __exynos_ppmu_events {
>>> PPMU_EVENT(d1-cpu),
>>> PPMU_EVENT(d1-general),
>>> PPMU_EVENT(d1-rt),
>>> +
>>> + /* For Exynos5422 SoC */
>>> + PPMU_EVENT(dmc0_0),
>>> + PPMU_EVENT(dmc0_1),
>>> + PPMU_EVENT(dmc1_0),
>>> + PPMU_EVENT(dmc1_1),
>>> };
>>>
>>> static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev *edev)
>>> --
>>> 2.17.1
>>>
>>
>> Acked-by: Chanwoo Choi
>>
> Thank you Chanwoo.
It[1] was merged to devfreq.git.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/commit/?h=for-next
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] extcon: gpio: Request reasonable interrupts
On 19. 6. 8. 오전 6:24, Linus Walleij wrote: > On Tue, Jun 4, 2019 at 3:30 AM Chanwoo Choi wrote: >> On 19. 5. 31. 오전 3:39, Linus Walleij wrote: > >>> + /* >>> + * It is unlikely that this is an acknowledged interrupt that goes >>> + * away after handling, what we are looking for are falling edges >>> + * if the signal is active low, and rising edges if the signal is >>> + * active high. >>> + */ >>> + if (gpiod_is_active_low(data->gpiod)) >>> + irq_flags = IRQF_TRIGGER_FALLING; >> >> If gpiod_is_active_low(data->gpiod) is true, irq_flags might be >> IRQF_TRIGGER_LOW instead of IRQF_TRIGGER_FALLING. How can we sure >> that irq_flags is always IRQF_TRIGGER_FALLING? > > OK correct me if I'm wrong, but this is an external connector and > the GPIO goes low/high when the connector is physically inserted. > If it was level trigged, it would lock up the CPU with interrupts until > it was unplugged again, since there is no way to acknowledge a > level IRQ. > > I think level IRQ on GPIOs are only used for logic peripherals > such as ethernet controllers etc where you can talk to the peripheral > and get it to deassert the line and thus acknowledge the IRQ. > > So the way I see it only edge triggering makes sense for extcon. > > Correct me if I'm wrong. Sorry for late reply because of vacation. Actually, I have not thought that the kind of irq_flags are fixed according to the category of specific h/w device. Until now, as I knew, the h/w device have to initialize the the kind of irq_flags for each peripheral device dependency. The each vendor of peripheral device might design the kind of the kind of irq-flags for detection. If possible, could you provide some example on mainline kernel? -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 0/2] extcon: Add fsa9480 extcon driver
On 19. 6. 21. 오후 8:13, Paweł Chmiel wrote: > This small patchset adds support for Fairchild Semiconductor FSA9480 > microUSB switch. > > It has been tested on Samsung Galaxy S and Samsung Fascinate 4G, > but it can be found also on other Samsung Aries (s5pv210) based devices. > > Tomasz Figa (2): > dt-bindings: extcon: Add support for fsa9480 switch > extcon: Add fsa9480 extcon driver > > Changes from v1: > - Added newline at end of dt-bindings file > - Removed interrupt-parent from dt-bindings file > - Added Acked-by to dt-bindings patch > - Remove license sentences from driver > - Remove custom sysfs entries and manual switch code > - Switch to using regmap api > > .../bindings/extcon/extcon-fsa9480.txt| 19 + > drivers/extcon/Kconfig| 12 + > drivers/extcon/Makefile | 1 + > drivers/extcon/extcon-fsa9480.c | 395 ++ > 4 files changed, 427 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt > create mode 100644 drivers/extcon/extcon-fsa9480.c > Applied this series to extcon-next after checked the build warning on extcon-testing branch. Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support
Hi Dmitry, On 19. 6. 24. 오전 2:17, Dmitry Osipenko wrote: > 05.06.2019 2:09, Dmitry Osipenko пишет: >> 04.06.2019 3:49, Chanwoo Choi пишет: >>> On 19. 6. 4. 오전 1:52, Dmitry Osipenko wrote: >>>> 03.05.2019 3:52, Dmitry Osipenko пишет: >>>>> 03.05.2019 3:31, Chanwoo Choi пишет: >>>>>> Hi Dmitry, >>>>>> >>>>>> On 19. 5. 2. 오전 8:37, Dmitry Osipenko wrote: >>>>>>> Changelog: >>>>>>> >>>>>>> v4: Addressed all review comments that were made by Chanwoo Choi to v3: >>>>>>> >>>>>>> - changed the driver removal order to match the probe exactly >>>>>>> - added clarifying comment for 1/8 ratio to the Tegra20 driver >>>>>>> >>>>>>> Chanwoo, please also note that the clk patch that should fix >>>>>>> compilation problem that was reported the kbuild-test-robot is >>>>>>> already >>>>>>> applied and available in the recent linux-next. >>>>>> >>>>>> I knew that Stephen picked up your path about clock. >>>>> >>>>> Hi Chanwoo, >>>>> >>>>> Okay, good. Thank you very much for reviewing this series! I assume it's >>>>> too late now for v5.2, but it should be good to go for v5.3. >>>>> >>>> >>>> Hello Chanwoo, >>>> >>>> Will be nice to see the patches in the linux-next before they'll hit >>>> mainline. We have tested that >>>> everything works fine on a selective devices, but won't hurt to get some >>>> extra testing beforehand. >>>> AFAIK, at least NVIDIA people are regularly testing -next on theirs dev >>>> boards. Please note that >>>> this not very important, so don't bother if there is some hurdle with >>>> pushing to the tracking branch >>>> for now. Also please let me know if you're expecting to see some ACK's on >>>> the patches, I'm sure >>>> we'll be able to work out that with Thierry and Jon if necessary. >>>> >>>> >>> >>> Hi Dmitry, >>> I think that it is enough for applying to mainline branch. >>> The devfreq.git is maintained by Myungjoo. He will be merged or >>> reviewed if there are th remained review point. >> >> Thank you very much! >> >>> >>> Hi Myungjoo, >>> I reviewed the Dmitry's patches from v1 to v4 patches. >>> And then I tested them on my testing branch[1] for catching >>> the build warning and error. In result, it is clean. >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing >>> >>> Please review or apply these patches for v5.3. >>> >> >> Hello Myungjoo, >> >> I think this patchset should be completed now. Thierry has some extra >> comments to the patches, but seems nothing critical so far and all the >> concerns could be addressed in a follow-up series. Please let me know if >> you're fine with this, I can re-spin v5 as well if necessary. >> > > Hello Chanwoo, > > It looks like Myungjoo is inactive at the moment. Do you know if he'll > be back to the time of the merge window opening or you'll be curating > the pull request for 5.3 this time? Myungoo works in the same place. I'll talk with him. > > Secondly, I'll send a few more patches on top of this series, addressing > Thierry's comments and making more improvements. Please let me know if > this causes any problems and I should re-spin the whole series. OK. I'll review them. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v3] arm64: defconfig: Enable Panfrost and Lima drivers
On 19. 6. 24. 오전 4:16, Krzysztof Kozlowski wrote: > On Sun, 23 Jun 2019 at 06:31, Chanwoo Choi wrote: >> >> Hi Krzysztof, >> >> 2019년 6월 23일 (일) 오전 4:20, Krzysztof Kozlowski 님이 작성: >>> >>> Enable support for Mali GPU with Panfrost and Lima drivers for: >>> 1. Samsung Exynos5433 and Exynos7 (having Mali T760), >>> 2. Allwiner A64 and H5 (Mali 400/450). >>> >>> Signed-off-by: Krzysztof Kozlowski >>> >>> --- >>> >>> Changes since v1: >>> 1. Enable Lima driver >>> --- >>> arch/arm64/configs/defconfig | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig >>> index fbbc065415d4..3d31611368af 100644 >>> --- a/arch/arm64/configs/defconfig >>> +++ b/arch/arm64/configs/defconfig >>> @@ -518,6 +518,8 @@ CONFIG_DRM_HISI_HIBMC=m >>> CONFIG_DRM_HISI_KIRIN=m >>> CONFIG_DRM_MESON=m >>> CONFIG_DRM_PL111=m >>> +CONFIG_DRM_LIMA=m >>> +CONFIG_DRM_PANFROST=m >>> CONFIG_FB=y >>> CONFIG_FB_MODE_HELPERS=y >>> CONFIG_BACKLIGHT_GENERIC=m >>> @@ -718,7 +720,6 @@ CONFIG_ARCH_TEGRA_194_SOC=y >>> CONFIG_ARCH_K3_AM6_SOC=y >>> CONFIG_SOC_TI=y >>> CONFIG_TI_SCI_PM_DOMAINS=y >>> -CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y >> >> Exynos5433-tm2 board support the exynos-bus device which >> used the simple_ondmenad governor of devfreq. >> Why do you remove this configuration from the defconfig? > > It is selected by default by DRM_PANFROST. The difference is that > PANFROST selects it as module. The 'y' is chosen because of: > SCSI_UFSHCD [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && SCSI_DMA [=y] When I tried to find the history of CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND for defconfig, the following patch[1] added this configuration. [1] b972ff75f2938c39e2205c23ea0e531d36b27f86 - "arm64: defconfig: Enable UFS on msm8996" I think that this patch will affect the opration of 'USF on msm8998'. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v3] arm64: defconfig: Enable Panfrost and Lima drivers
Hi Krzysztof, 2019년 6월 23일 (일) 오전 4:20, Krzysztof Kozlowski 님이 작성: > > Enable support for Mali GPU with Panfrost and Lima drivers for: > 1. Samsung Exynos5433 and Exynos7 (having Mali T760), > 2. Allwiner A64 and H5 (Mali 400/450). > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Enable Lima driver > --- > arch/arm64/configs/defconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index fbbc065415d4..3d31611368af 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -518,6 +518,8 @@ CONFIG_DRM_HISI_HIBMC=m > CONFIG_DRM_HISI_KIRIN=m > CONFIG_DRM_MESON=m > CONFIG_DRM_PL111=m > +CONFIG_DRM_LIMA=m > +CONFIG_DRM_PANFROST=m > CONFIG_FB=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_BACKLIGHT_GENERIC=m > @@ -718,7 +720,6 @@ CONFIG_ARCH_TEGRA_194_SOC=y > CONFIG_ARCH_K3_AM6_SOC=y > CONFIG_SOC_TI=y > CONFIG_TI_SCI_PM_DOMAINS=y > -CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y Exynos5433-tm2 board support the exynos-bus device which used the simple_ondmenad governor of devfreq. Why do you remove this configuration from the defconfig? > CONFIG_EXTCON_USB_GPIO=y > CONFIG_EXTCON_USBC_CROS_EC=y > CONFIG_MEMORY=y > -- > 2.17.1 > -- Best Regards, Chanwoo Choi
Re: [PATCH v1 2/3] OPP: Add function to look up required OPP's for a given OPP
Hi,
2019년 6월 23일 (일) 오전 6:42, Saravana Kannan 님이 작성:
>
> On Sat, Jun 22, 2019 at 4:50 AM Chanwoo Choi wrote:
> >
> > Hi,
> >
> > Absolutely, I like this approach. I think that it is necessary to make
> > the connection
> > between frequencies of devices.
>
> Happy to hear that.
>
> > But, I have a question on below.
> >
> > 2019년 6월 22일 (토) 오전 9:35, Saravana Kannan 님이 작성:
> > >
> > > Add a function that allows looking up required OPPs given a source OPP
> > > table, destination OPP table and the source OPP.
> > >
> > > Signed-off-by: Saravana Kannan
> > > ---
> > > drivers/opp/core.c | 54 ++
> > > include/linux/pm_opp.h | 11 +
> > > 2 files changed, 65 insertions(+)
> > >
> > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > > index 74c7bdc6f463..4f7870bffbf8 100644
> > > --- a/drivers/opp/core.c
> > > +++ b/drivers/opp/core.c
> > > @@ -1830,6 +1830,60 @@ void dev_pm_opp_put_genpd_virt_dev(struct
> > > opp_table *opp_table,
> > > dev_err(virt_dev, "Failed to find required device
> > > entry\n");
> > > }
> > >
> > > +/**
> > > + * dev_pm_opp_xlate_opp() - Find required OPP for src_table OPP.
> > > + * @src_table: OPP table which has dst_table as one of its required OPP
> > > table.
> > > + * @dst_table: Required OPP table of the src_table.
> > > + * @pstate: OPP of the src_table.
> > > + *
> > > + * This function returns the OPP (present in @dst_table) pointed out by
> > > the
> > > + * "required-opps" property of the OPP (present in @src_table).
> > > + *
> > > + * The callers are required to call dev_pm_opp_put() for the returned
> > > OPP after
> > > + * use.
> > > + *
> > > + * Return: destination table OPP on success, otherwise NULL on errors.
> > > + */
> > > +struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
> > > + struct opp_table *dst_table,
> > > + struct dev_pm_opp *src_opp)
> > > +{
> > > + struct dev_pm_opp *opp, *dest_opp = NULL;
> > > + int i;
> > > +
> > > + if (!src_table || !dst_table || !src_opp)
> > > + return NULL;
> > > +
> > > + for (i = 0; i < src_table->required_opp_count; i++) {
> > > + if (src_table->required_opp_tables[i]->np ==
> > > dst_table->np)
> > > + break;
> > > + }
> > > +
> > > + if (unlikely(i == src_table->required_opp_count)) {
> > > + pr_err("%s: Couldn't find matching OPP table (%p: %p)\n",
> > > + __func__, src_table, dst_table);
> > > + return NULL;
> > > + }
> > > +
> > > + mutex_lock(_table->lock);
> > > +
> > > + list_for_each_entry(opp, _table->opp_list, node) {
> > > + if (opp == src_opp) {
> > > + dest_opp = opp->required_opps[i];
> >
> > Correct me if I am wrong. This patch assume that 'i' index is same on
> > between
> > [1] and [2]. But in order to guarantee this assumption, all OPP entries
> > in the same opp_table have to have the same number of 'required-opps'
> > properties
> > and keep the sequence among 'required-opps' entries.
> >
> > [1] src_table->required_opp_tables[i]->np
> > [2] opp->required_opps[I];
> >
> > For example, three OPP entries in the 'parent_bus_opp'
> > have the different sequence of 'required-opps' and the different
> > number of 'required-opps'. Is it no problem?
> >
> > parent_bus_opp: opp_table {
> > compatible = "operating-points-v2";
> >
> > opp2 {
> > opp-hz = /bits/ 64 <20>;
> > required-opps = <_bus_a_opp2>, <_bus_b_opp2>,
> > <_bus_c_opp2>;
> > };
> >
> > opp1 {
> > opp-hz = /bits/ 64 <20>;
> > // change the sequence between child_bus_b_opp2 and
> > child_bus_c_opp2
> > required-opps = <_bus_a_opp2>, <_bus_c_opp2>,
> > <_bus_b_opp2>
> > };
> >
> > opp0 {
> > opp-hz = /bits/ 64 <20>;
> > /
Re: [PATCH v10 09/13] drivers: devfreq: events: add Exynos PPMU new events
Hi,
2019년 6월 14일 (금) 오후 6:54, Lukasz Luba 님이 작성:
>
> Define new performance events supported by Exynos5422 SoC counters.
> The counters are built-in in Dynamic Memory Controller and provide
> information regarding memory utilization.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/devfreq/event/exynos-ppmu.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/devfreq/event/exynos-ppmu.c
> b/drivers/devfreq/event/exynos-ppmu.c
> index c2ea94957501..ce658c262c27 100644
> --- a/drivers/devfreq/event/exynos-ppmu.c
> +++ b/drivers/devfreq/event/exynos-ppmu.c
> @@ -89,6 +89,12 @@ static struct __exynos_ppmu_events {
> PPMU_EVENT(d1-cpu),
> PPMU_EVENT(d1-general),
> PPMU_EVENT(d1-rt),
> +
> + /* For Exynos5422 SoC */
> + PPMU_EVENT(dmc0_0),
> + PPMU_EVENT(dmc0_1),
> + PPMU_EVENT(dmc1_0),
> + PPMU_EVENT(dmc1_1),
> };
>
> static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev *edev)
> --
> 2.17.1
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Re: [PATCH v2 0/2] extcon: Add fsa9480 extcon driver
Hi, I applied this series to extcon-testing branch. If there are no build problem for few days, I'll move them to extcon-next branch. Best Regards, Chanwoo Choi 2019년 6월 21일 (금) 오후 8:14, Paweł Chmiel 님이 작성: > > This small patchset adds support for Fairchild Semiconductor FSA9480 > microUSB switch. > > It has been tested on Samsung Galaxy S and Samsung Fascinate 4G, > but it can be found also on other Samsung Aries (s5pv210) based devices. > > Tomasz Figa (2): > dt-bindings: extcon: Add support for fsa9480 switch > extcon: Add fsa9480 extcon driver > > Changes from v1: > - Added newline at end of dt-bindings file > - Removed interrupt-parent from dt-bindings file > - Added Acked-by to dt-bindings patch > - Remove license sentences from driver > - Remove custom sysfs entries and manual switch code > - Switch to using regmap api > > .../bindings/extcon/extcon-fsa9480.txt| 19 + > drivers/extcon/Kconfig| 12 + > drivers/extcon/Makefile | 1 + > drivers/extcon/extcon-fsa9480.c | 395 ++ > 4 files changed, 427 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt > create mode 100644 drivers/extcon/extcon-fsa9480.c > > -- > 2.17.1 >
Re: [PATCH v1 3/3] PM / devfreq: Add required OPPs support to passive governor
Hi,
Absolutely, I agree this approach.
But, I add some comments on below. please check them.
2019년 6월 22일 (토) 오전 9:36, Saravana Kannan 님이 작성:
>
> Look at the required OPPs of the "parent" device to determine the OPP that
> is required from the slave device managed by the passive governor. This
> allows having mappings between a parent device and a slave device even when
> they don't have the same number of OPPs.
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/devfreq/governor_passive.c | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/governor_passive.c
> b/drivers/devfreq/governor_passive.c
> index 3bc29acbd54e..bd4a98bb15b1 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -21,8 +21,9 @@ static int devfreq_passive_get_target_freq(struct devfreq
> *devfreq,
> struct devfreq_passive_data *p_data
> = (struct devfreq_passive_data *)devfreq->data;
> struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
> + struct opp_table *opp_table = NULL, *c_opp_table = NULL;
In this function, the base device is passive devfreq device.
So, I think that better to define the 'parent_opp_table' instead of 'opp_table'
indicating the OPP table of parent devfreq device. And better to define
just 'opp_table' instead of 'c_opp_table' indicating the passive devfreq device.
- opp_table -> parent_opp_table
- c_opp_table -> opp_table
> unsigned long child_freq = ULONG_MAX;
> - struct dev_pm_opp *opp;
> + struct dev_pm_opp *opp = NULL, *c_opp = NULL;
Ditto. I think that better to define the variables as following:
- opp -> parent_opp
- c_cpp -> opp
> int i, count, ret = 0;
>
> /*
> @@ -65,7 +66,20 @@ static int devfreq_passive_get_target_freq(struct devfreq
> *devfreq,
> goto out;
> }
>
> - dev_pm_opp_put(opp);
> + opp_table = dev_pm_opp_get_opp_table(parent_devfreq->dev.parent);
devfreq_passive_get_target_freq() is called frequently for DVFS support.
I think that you have to add 'struct opp_table *opp_table' instance to
'struct devfreq'
and then get 'opp_table' instance in the devfreq_add_device().
devfreq_add_device() already get the OPP information by using
dev_pm_opp_get_suspend_opp_freq().
You can add following code nearby dev_pm_opp_get_suspend_opp_freq() in
devfreq_add_device().
- devfreq->opp_table = dev_pm_opp_get_opp_table(dev);
> + if (IS_ERR_OR_NULL(opp_table)) {
> + ret = PTR_ERR(opp_table);
> + goto out;
> + }
> +
> + c_opp_table = dev_pm_opp_get_opp_table(devfreq->dev.parent);
> + if (!IS_ERR_OR_NULL(c_opp_table))
> + c_opp = dev_pm_opp_xlate_opp(opp_table, c_opp_table, opp);
> + if (c_opp) {
> + *freq = dev_pm_opp_get_freq(c_opp);
> + dev_pm_opp_put(c_opp);
> + goto out;
> + }
>
> /*
> * Get the OPP table's index of decided freqeuncy by governor
> @@ -92,6 +106,13 @@ static int devfreq_passive_get_target_freq(struct devfreq
> *devfreq,
> *freq = child_freq;
>
> out:
> + if (!IS_ERR_OR_NULL(opp_table))
> + dev_pm_opp_put_opp_table(opp_table);
> + if (!IS_ERR_OR_NULL(c_opp_table))
> + dev_pm_opp_put_opp_table(c_opp_table);
> + if (!IS_ERR_OR_NULL(opp))
> + dev_pm_opp_put(opp);
> +
> return ret;
> }
>
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
--
Best Regards,
Chanwoo Choi
Re: [PATCH v1 2/3] OPP: Add function to look up required OPP's for a given OPP
e(struct opp_table *src_table, struct
> opp_table *dst_table, unsigned int pstate);
> +struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
> + struct opp_table *dst_table,
> + struct dev_pm_opp *src_opp);
> int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq);
> int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, const struct cpumask
> *cpumask);
> int dev_pm_opp_get_sharing_cpus(struct device *cpu_dev, struct cpumask
> *cpumask);
> @@ -307,6 +310,14 @@ static inline int
> dev_pm_opp_xlate_performance_state(struct opp_table *src_table
> return -ENOTSUPP;
> }
>
> +static inline struct dev_pm_opp *dev_pm_opp_xlate_opp(
> + struct opp_table *src_table,
> + struct opp_table *dst_table,
> + struct dev_pm_opp *src_opp)
> +{
> + return NULL;
> +}
> +
> static inline int dev_pm_opp_set_rate(struct device *dev, unsigned long
> target_freq)
> {
> return -ENOTSUPP;
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
--
Best Regards,
Chanwoo Choi
Re: Pointers on using the extcon-adc-jack driver
Hi George, On 19. 6. 13. 오전 2:59, George Hilliard wrote: > I have question about using the extcon-adc-jack code, which uses an > ADC to provide an extcon device. This is exactly what I need for my > hardware. > > Currently it seems like it's set up to only be called from other C > "platform" code, although I can't find any examples of such code on > the internet at all, never mind in the kernel tree. I am interested > in putting this driver in the device tree for my board. Would you be > amenable to patches adding device tree support for this driver (and > maybe other related extcon drivers)? Or have I overlooked the > "correct" way to use this module? > Until now, extcon-adc-jack driver has not yet supported the dt-binding on the latest mainline kernel. Actually, extcon-adc-jack has the similar issue with extcon-gpio about dt-binding. When I tried to do it[1] for extcon-gpio dt bidnings and someone tried it[2] again, but, it was not finished. You can check the threads[1][2]. [1] https://lkml.org/lkml/2015/10/21/8 [2] https://lore.kernel.org/patchwork/patch/681550/ In order to support the dt-binding for extcon-adc-jack, have to find the proper compatible name indicating the device connector and defines the properties to get the ADC value from devicetree. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
Hi Enric,
For extcon parth,
Acked-by: Chanwoo Choi
Best Regards,
Chanwoo Choi
On 19. 6. 15. 오전 1:36, Enric Balletbo i Serra wrote:
> Now, the ChromeOS EC core driver has nothing related to an MFD device, so
> move that driver from the MFD subsystem to the platform/chrome subsystem.
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Andy Shevchenko
> Acked-by: Thierry Reding
> Acked-by: Mark Brown
> Acked-by: Wolfram Sang
> Acked-by: Neil Armstrong
> Acked-by: Alexandre Belloni
> Acked-by: Jonathan Cameron
> Acked-by: Benjamin Tissoires
> Acked-by: Dmitry Torokhov
> Acked-by: Sebastian Reichel
> ---
>
> Changes in v2: None
>
> drivers/extcon/Kconfig | 2 +-
> drivers/hid/Kconfig| 2 +-
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/iio/common/cros_ec_sensors/Kconfig | 2 +-
> drivers/input/keyboard/Kconfig | 2 +-
> drivers/media/platform/Kconfig | 3 +--
> drivers/mfd/Kconfig| 14 +-
> drivers/mfd/Makefile | 2 --
> drivers/platform/chrome/Kconfig| 21 +
> drivers/platform/chrome/Makefile | 1 +
> drivers/{mfd => platform/chrome}/cros_ec.c | 0
> drivers/power/supply/Kconfig | 2 +-
> drivers/pwm/Kconfig| 2 +-
> drivers/rtc/Kconfig| 2 +-
> sound/soc/qcom/Kconfig | 2 +-
> 15 files changed, 29 insertions(+), 30 deletions(-)
> rename drivers/{mfd => platform/chrome}/cros_ec.c (100%)
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index de06fafb52ff..5b0996b10d40 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -168,7 +168,7 @@ config EXTCON_USB_GPIO
>
> config EXTCON_USBC_CROS_EC
> tristate "ChromeOS Embedded Controller EXTCON support"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> Say Y here to enable USB Type C cable detection extcon support when
> using Chrome OS EC based USB Type-C ports.
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index c3c390ca3690..b8022c158cb7 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -375,7 +375,7 @@ config HOLTEK_FF
>
> config HID_GOOGLE_HAMMER
> tristate "Google Hammer Keyboard"
> - depends on USB_HID && LEDS_CLASS && MFD_CROS_EC
> + depends on USB_HID && LEDS_CLASS && CROS_EC
> ---help---
> Say Y here if you have a Google Hammer device.
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 26186439db6b..f2c2ab7eeffa 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -1335,7 +1335,7 @@ config I2C_SIBYTE
>
> config I2C_CROS_EC_TUNNEL
> tristate "ChromeOS EC tunnel I2C bus"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> If you say yes here you get an I2C bus that will tunnel i2c commands
> through to the other side of the ChromeOS EC to the i2c bus
> diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig
> b/drivers/iio/common/cros_ec_sensors/Kconfig
> index 135f6825903f..c7d5b140491f 100644
> --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> @@ -3,7 +3,7 @@
> #
> config IIO_CROS_EC_SENSORS_CORE
> tristate "ChromeOS EC Sensors Core"
> - depends on SYSFS && MFD_CROS_EC
> + depends on SYSFS && CROS_EC
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> help
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 82398827b64f..fb843b56d439 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -728,7 +728,7 @@ config KEYBOARD_W90P910
> config KEYBOARD_CROS_EC
> tristate "ChromeOS EC keyboard"
> select INPUT_MATRIXKMAP
> - depends on MFD_CROS_EC
> + depends on CROS_EC
> help
> Say Y here to enable the matrix keyboard used by ChromeOS devices
> and implemented on the ChromeOS EC. You must enable one bus option
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 011c1c2fcf19..9883526c5ff0 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -557,10 +557,9 @@ if CEC_PLATFORM_DRIVERS
>
> config VIDEO_CROS_EC_CEC
> tristate "ChromeOS EC CEC driver"
> - depends on MFD_CROS_EC
> + depends on CROS_EC
Re: [PATCH v2 06/10] mfd / platform: cros_ec: Reorganize platform and mfd includes
Hi Enric,
For extcon part,
Acked-by: Chanwoo Choi
Best Regards,
Chanwoo choi
On 19. 6. 15. 오전 1:36, Enric Balletbo i Serra wrote:
> There is a bit of mess between cros-ec mfd includes and platform
> includes. For example, we have a linux/mfd/cros_ec.h include that
> exports the interface implemented in platform/chrome/cros_ec_proto.c. Or
> we have a linux/mfd/cros_ec_commands.h file that is non related to the
> multifunction device (in the sense that is not exporting any function of
> the mfd device). This causes crossed includes between mfd and
> platform/chrome subsystems and makes the code difficult to read, apart
> from creating 'curious' situations where a platform/chrome driver includes
> a linux/mfd/cros_ec.h file just to get the exported functions that are
> implemented in another platform/chrome driver.
>
> In order to have a better separation on what the cros-ec multifunction
> driver does and what the cros-ec core provides move and rework the
> affected includes doing:
>
> - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h
> - Get rid of the parts that are implemented in the
> platform/chrome/cros_ec_proto.c
>driver from include/linux/mfd/cros_ec.h to a new file
>include/linux/platform_data/cros_ec_proto.h
> - Update all the drivers with the new includes, so
>- Drivers that only need to know about the protocol include
> - linux/platform_data/cros_ec_proto.h
> - linux/platform_data/cros_ec_commands.h
>- Drivers that need to know about the cros-ec mfd device also include
> - linux/mfd/cros_ec.h
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Andy Shevchenko
> Acked-by: Mark Brown
> Acked-by: Wolfram Sang
> Acked-by: Neil Armstrong
> Acked-by: Alexandre Belloni
> Acked-by: Jonathan Cameron
> Acked-by: Benjamin Tissoires
> Acked-by: Dmitry Torokhov
> Acked-by: Sebastian Reichel
> ---
>
> Changes in v2: None
>
> drivers/extcon/extcon-usbc-cros-ec.c | 3 +-
> drivers/hid/hid-google-hammer.c | 4 +-
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 +-
> drivers/iio/accel/cros_ec_accel_legacy.c | 3 +-
> .../common/cros_ec_sensors/cros_ec_sensors.c | 3 +-
> .../cros_ec_sensors/cros_ec_sensors_core.c| 3 +-
> drivers/iio/light/cros_ec_light_prox.c| 3 +-
> drivers/iio/pressure/cros_ec_baro.c | 3 +-
> drivers/input/keyboard/cros_ec_keyb.c | 4 +-
> .../media/platform/cros-ec-cec/cros-ec-cec.c | 4 +-
> drivers/mfd/cros_ec_dev.c | 3 +-
> drivers/platform/chrome/cros_ec.c | 3 +-
> drivers/platform/chrome/cros_ec_debugfs.c | 3 +-
> drivers/platform/chrome/cros_ec_i2c.c | 4 +-
> drivers/platform/chrome/cros_ec_lightbar.c| 3 +-
> drivers/platform/chrome/cros_ec_lpc.c | 4 +-
> drivers/platform/chrome/cros_ec_lpc_reg.c | 4 +-
> drivers/platform/chrome/cros_ec_proto.c | 3 +-
> drivers/platform/chrome/cros_ec_rpmsg.c | 4 +-
> drivers/platform/chrome/cros_ec_spi.c | 4 +-
> drivers/platform/chrome/cros_ec_sysfs.c | 3 +-
> drivers/platform/chrome/cros_ec_trace.c | 2 +-
> drivers/platform/chrome/cros_ec_trace.h | 4 +-
> drivers/platform/chrome/cros_ec_vbc.c | 3 +-
> drivers/platform/chrome/cros_usbpd_logger.c | 5 +-
> drivers/power/supply/cros_usbpd-charger.c | 5 +-
> drivers/pwm/pwm-cros-ec.c | 4 +-
> drivers/rtc/rtc-cros-ec.c | 3 +-
> .../linux/iio/common/cros_ec_sensors_core.h | 3 +-
> include/linux/mfd/cros_ec.h | 306 -
> .../{mfd => platform_data}/cros_ec_commands.h | 0
> include/linux/platform_data/cros_ec_proto.h | 315 ++
> sound/soc/codecs/cros_ec_codec.c | 4 +-
> 33 files changed, 377 insertions(+), 349 deletions(-)
> rename include/linux/{mfd => platform_data}/cros_ec_commands.h (100%)
> create mode 100644 include/linux/platform_data/cros_ec_proto.h
>
> diff --git a/drivers/extcon/extcon-usbc-cros-ec.c
> b/drivers/extcon/extcon-usbc-cros-ec.c
> index 43c0a936ab82..5290cc2d19d9 100644
> --- a/drivers/extcon/extcon-usbc-cros-ec.c
> +++ b/drivers/extcon/extcon-usbc-cros-ec.c
> @@ -6,10 +6,11 @@
>
> #include
> #include
> -#include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> index ee5e0bdcf078..84f8c127ebdc 100644
> --- a/drivers/hid/hid-google-hammer.c
> +++ b/drivers/hid/hid-google-hammer.c
> @@ -16,9 +16,
Re: [PATCH RFC 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor
+ Sibi Sankar Hi, Hsin-Yi Wang, Saravana Kannan and Sibi Sankar I summarized the history of the related patch about this title. Firstly, As I knew, Saravana sent the patch[1] which contains 'governor_cpufreq_map.c' last year. According to the Myungoo's comment, Secondly, Sibi Sankar modified the 'governor_passive.c'[2] in order to support the mapping between cpu frequency and device frequency. Unfortunately, Sibi Sankar stopped the development about this because he had found the other method to get his purpose as I knew. Thirdly, Hsin-Yi Wang send the original patch of Saravana without modification. Sincerely, I think that the mapping between cpu frequency and device frequency is necessary. And I prefer the Sibi's approach which implements stuff to the existing 'passive' governor. We need to discuss about how to implement them by whom. [1] [v3,1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor - https://patchwork.kernel.org/patch/10553171/ [2] [PATCH RFC 0/9] Add CPU based scaling support to Passive governor - https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/ [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor - https://lore.kernel.org/lkml/08c3cff8c39e3d82e044db93e992d...@codeaurora.org/T/#m1cafb7baf687d2a680d39c85d3ec7d1b590b68fc Best Regards, Chanwoo Choi On 19. 6. 18. 오후 1:14, Hsin-Yi Wang wrote: > From: Saravana Kannan > > From: Saravana Kannan > > Many CPU architectures have caches that can scale independent of the CPUs. > Frequency scaling of the caches is necessary to make sure the cache is not > a performance bottleneck that leads to poor performance and power. The same > idea applies for RAM/DDR. > > To achieve this, this patch adds a generic devfreq governor that takes the > current frequency of each CPU frequency domain and then adjusts the > frequency of the cache (or any devfreq device) based on the frequency of > the CPUs. It listens to CPU frequency transition notifiers to keep itself > up to date on the current CPU frequency. > > To decide the frequency of the device, the governor does one of the > following: > > * Uses a CPU frequency to device frequency mapping table > - Either one mapping table used for all CPU freq policies (typically used > for system with homogeneous cores/clusters that have the same OPPs). > - One mapping table per CPU freq policy (typically used for ASMP systems > with heterogeneous CPUs with different OPPs) > > OR > > * Scales the device frequency in proportion to the CPU frequency. So, if > the CPUs are running at their max frequency, the device runs at its max > frequency. If the CPUs are running at their min frequency, the device > runs at its min frequency. And interpolated for frequencies in between. > > Signed-off-by: Saravana Kannan > Signed-off-by: Hsin-Yi Wang > --- > .../bindings/devfreq/devfreq-cpufreq-map.txt | 53 ++ > drivers/devfreq/Kconfig | 8 + > drivers/devfreq/Makefile | 1 + > drivers/devfreq/governor_cpufreq_map.c| 583 ++ > 4 files changed, 645 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > create mode 100644 drivers/devfreq/governor_cpufreq_map.c > > diff --git > a/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > new file mode 100644 > index ..982a30bcfc86 > --- /dev/null > +++ b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > @@ -0,0 +1,53 @@ > +Devfreq CPUfreq governor > + > +devfreq-cpufreq-map is a parent device that contains one or more child > devices. > +Each child device provides CPU frequency to device frequency mapping for a > +specific device. Examples of devices that could use this are: DDR, cache and > +CCI. > + > +Parent device name shall be "devfreq-cpufreq-map". > + > +Required child device properties: > +- cpu-to-dev-map, or cpu-to-dev-map-: > + A list of tuples where each tuple consists of a > + CPU frequency (KHz) and the corresponding device > + frequency. CPU frequencies not listed in the table > + will use the device frequency that corresponds to the > + next rounded up CPU frequency. > + Use "cpu-to-dev-map" if all CPUs in the system should > + share same mapping. > + Use cpu-to-dev-map- to describe different > + mappings for different CPUs. The property should be > + list
Re: [PATCH] extcon: gpio: Request reasonable interrupts
Hi Linus,
On 19. 5. 31. 오전 3:39, Linus Walleij wrote:
> The only thing that makes sense is to request a falling edge interrupt
> if the line is active low and a rising edge interrupt if the line is
> active high, so just do that and get rid of the assignment from
> platform data. The GPIO descriptor knows if the line is active high
> or low.
>
> Also make irq a local variable in probe(), it's not used anywhere else.
>
> Signed-off-by: Linus Walleij
> ---
> drivers/extcon/extcon-gpio.c | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 13ba3a6e81d5..a0674f1f3849 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -30,26 +30,22 @@
> /**
> * struct gpio_extcon_data - A simple GPIO-controlled extcon device state
> container.
> * @edev:Extcon device.
> - * @irq: Interrupt line for the external connector.
> * @work:Work fired by the interrupt.
> * @debounce_jiffies:Number of jiffies to wait for the GPIO to
> stabilize, from the debounce
> * value.
> * @gpiod: GPIO descriptor for this external connector.
> * @extcon_id: The unique id of specific external connector.
> * @debounce:Debounce time for GPIO IRQ in ms.
> - * @irq_flags: IRQ Flags (e.g., IRQF_TRIGGER_LOW).
> * @check_on_resume: Boolean describing whether to check the state of gpio
> * while resuming from sleep.
> */
> struct gpio_extcon_data {
> struct extcon_dev *edev;
> - int irq;
> struct delayed_work work;
> unsigned long debounce_jiffies;
> struct gpio_desc *gpiod;
> unsigned int extcon_id;
> unsigned long debounce;
> - unsigned long irq_flags;
> bool check_on_resume;
> };
>
> @@ -77,6 +73,8 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> {
> struct gpio_extcon_data *data;
> struct device *dev = >dev;
> + unsigned long irq_flags;
> + int irq;
> int ret;
>
> data = devm_kzalloc(dev, sizeof(struct gpio_extcon_data), GFP_KERNEL);
> @@ -96,9 +94,20 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> data->gpiod = devm_gpiod_get(dev, "extcon", GPIOD_IN);
> if (IS_ERR(data->gpiod))
> return PTR_ERR(data->gpiod);
> - data->irq = gpiod_to_irq(data->gpiod);
> - if (data->irq <= 0)
> - return data->irq;
> + irq = gpiod_to_irq(data->gpiod);
> + if (irq <= 0)
> + return irq;
> +
> + /*
> + * It is unlikely that this is an acknowledged interrupt that goes
> + * away after handling, what we are looking for are falling edges
> + * if the signal is active low, and rising edges if the signal is
> + * active high.
> + */
> + if (gpiod_is_active_low(data->gpiod))
> + irq_flags = IRQF_TRIGGER_FALLING;
If gpiod_is_active_low(data->gpiod) is true, irq_flags might be
IRQF_TRIGGER_LOW instead of IRQF_TRIGGER_FALLING. How can we sure
that irq_flags is always IRQF_TRIGGER_FALLING?
> + else
> + irq_flags = IRQF_TRIGGER_RISING;
>
> /* Allocate the memory of extcon devie and register extcon device */
> data->edev = devm_extcon_dev_allocate(dev, >extcon_id);
> @@ -117,8 +126,8 @@ static int gpio_extcon_probe(struct platform_device *pdev)
>* Request the interrupt of gpio to detect whether external connector
>* is attached or detached.
>*/
> - ret = devm_request_any_context_irq(dev, data->irq,
> - gpio_irq_handler, data->irq_flags,
> + ret = devm_request_any_context_irq(dev, irq,
> + gpio_irq_handler, irq_flags,
> pdev->name, data);
> if (ret < 0)
> return ret;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support
On 19. 6. 4. 오전 1:52, Dmitry Osipenko wrote: > 03.05.2019 3:52, Dmitry Osipenko пишет: >> 03.05.2019 3:31, Chanwoo Choi пишет: >>> Hi Dmitry, >>> >>> On 19. 5. 2. 오전 8:37, Dmitry Osipenko wrote: >>>> Changelog: >>>> >>>> v4: Addressed all review comments that were made by Chanwoo Choi to v3: >>>> >>>> - changed the driver removal order to match the probe exactly >>>> - added clarifying comment for 1/8 ratio to the Tegra20 driver >>>> >>>> Chanwoo, please also note that the clk patch that should fix >>>> compilation problem that was reported the kbuild-test-robot is already >>>> applied and available in the recent linux-next. >>> >>> I knew that Stephen picked up your path about clock. >> >> Hi Chanwoo, >> >> Okay, good. Thank you very much for reviewing this series! I assume it's >> too late now for v5.2, but it should be good to go for v5.3. >> > > Hello Chanwoo, > > Will be nice to see the patches in the linux-next before they'll hit > mainline. We have tested that > everything works fine on a selective devices, but won't hurt to get some > extra testing beforehand. > AFAIK, at least NVIDIA people are regularly testing -next on theirs dev > boards. Please note that > this not very important, so don't bother if there is some hurdle with pushing > to the tracking branch > for now. Also please let me know if you're expecting to see some ACK's on the > patches, I'm sure > we'll be able to work out that with Thierry and Jon if necessary. > > Hi Dmitry, I think that it is enough for applying to mainline branch. The devfreq.git is maintained by Myungjoo. He will be merged or reviewed if there are th remained review point. Hi Myungjoo, I reviewed the Dmitry's patches from v1 to v4 patches. And then I tested them on my testing branch[1] for catching the build warning and error. In result, it is clean. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing Please review or apply these patches for v5.3. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2] extcon: arizona: Correct error handling on regmap_update_bits_check
Hi Charles,
On 19. 5. 29. 오후 6:46, Charles Keepax wrote:
> Ensure the case when regmap_update_bits_check fails and the change
> variable is not updated is handled correctly.
>
> Signed-off-by: Charles Keepax
> ---
>
> Changes since v1:
> - Print error message in driver remove
>
> Thanks,
> Charles
>
> drivers/extcon/extcon-arizona.c | 33 -
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 9327479c719c2..519e89aedd4a0 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -335,10 +335,12 @@ static void arizona_start_mic(struct
> arizona_extcon_info *info)
>
> arizona_extcon_pulse_micbias(info);
>
> - regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> - ARIZONA_MICD_ENA, ARIZONA_MICD_ENA,
> - );
> - if (!change) {
> + ret = regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> +ARIZONA_MICD_ENA, ARIZONA_MICD_ENA,
> +);
> + if (ret < 0) {
> + dev_err(arizona->dev, "Failed to enable micd: %d\n", ret);
> + } else if (!change) {
> regulator_disable(info->micvdd);
> pm_runtime_put_autosuspend(info->dev);
> }
> @@ -350,12 +352,14 @@ static void arizona_stop_mic(struct arizona_extcon_info
> *info)
> const char *widget = arizona_extcon_get_micbias(info);
> struct snd_soc_dapm_context *dapm = arizona->dapm;
> struct snd_soc_component *component = snd_soc_dapm_to_component(dapm);
> - bool change;
> + bool change = false;
> int ret;
>
> - regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> - ARIZONA_MICD_ENA, 0,
> - );
> + ret = regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> +ARIZONA_MICD_ENA, 0,
> +);
> + if (ret < 0)
> + dev_err(arizona->dev, "Failed to disable micd: %d\n", ret);
>
> ret = snd_soc_component_disable_pin(component, widget);
> if (ret != 0)
> @@ -1727,12 +1731,15 @@ static int arizona_extcon_remove(struct
> platform_device *pdev)
> struct arizona *arizona = info->arizona;
> int jack_irq_rise, jack_irq_fall;
> bool change;
> + int ret;
>
> - regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> - ARIZONA_MICD_ENA, 0,
> - );
> -
> - if (change) {
> + ret = regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> +ARIZONA_MICD_ENA, 0,
> +);
> + if (ret < 0) {
> + dev_err(>dev, "Failed to disable micd on remove: %d\n",
> + ret);
> + } else if (change) {
> regulator_disable(info->micvdd);
> pm_runtime_put(info->dev);
> }
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] extcon: arizona: Correct error handling on regmap_update_bits_check
Hi,
On 19. 5. 29. 오전 1:50, Charles Keepax wrote:
> Ensure the case when regmap_update_bits_check fails and the change
> variable is not updated is handled correctly.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 9327479c719c2..ba2d16de161f8 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -335,10 +335,12 @@ static void arizona_start_mic(struct
> arizona_extcon_info *info)
>
> arizona_extcon_pulse_micbias(info);
>
> - regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> - ARIZONA_MICD_ENA, ARIZONA_MICD_ENA,
> - );
> - if (!change) {
> + ret = regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> +ARIZONA_MICD_ENA, ARIZONA_MICD_ENA,
> +);
> + if (ret < 0) {
> + dev_err(arizona->dev, "Failed to enable micd: %d\n", ret);
> + } else if (!change) {
> regulator_disable(info->micvdd);
> pm_runtime_put_autosuspend(info->dev);
> }
> @@ -350,12 +352,14 @@ static void arizona_stop_mic(struct arizona_extcon_info
> *info)
> const char *widget = arizona_extcon_get_micbias(info);
> struct snd_soc_dapm_context *dapm = arizona->dapm;
> struct snd_soc_component *component = snd_soc_dapm_to_component(dapm);
> - bool change;
> + bool change = false;
> int ret;
>
> - regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> - ARIZONA_MICD_ENA, 0,
> - );
> + ret = regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> +ARIZONA_MICD_ENA, 0,
> +);
> + if (ret < 0)
> + dev_err(arizona->dev, "Failed to disable micd: %d\n", ret);
>
> ret = snd_soc_component_disable_pin(component, widget);
> if (ret != 0)
> @@ -1726,7 +1730,7 @@ 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;
> + bool change = false;
>
> regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
>ARIZONA_MICD_ENA, 0,
You better to check the return value as the part of this patch.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor
Hi Sibi,
On 19. 5. 27. 오후 5:23, Sibi Sankar wrote:
> Hey Chanwoo,
>
> Thanks a lot for reviewing the patch. Like I
> had indicated earlier we decided to go with
> a simpler approach instead on qualcomm SoCs.
> I am happy to re-spin this patch with your
> comments addressed if we do find other users
> for this feature.
Actually, I think that this approach is necessary.
On many real released product like smartphone
have the dependency between cpufreq and devfreq
for memory bus bandwidth. For example, when playing
the video or get the 60fps without loss.
If possible, this patch should be ongoing on either
now or future. Thanks.
>
> On 2019-04-12 13:09, Chanwoo Choi wrote:
>> Hi,
>>
>> I agree this approach absolutely.
>> Just I add some comments. Please check it.
>>
>> On 19. 3. 29. 오전 12:28, Sibi Sankar wrote:
>>> From: Saravana Kannan
>>>
>>> Many CPU architectures have caches that can scale independent of the
>>> CPUs. Frequency scaling of the caches is necessary to make sure the cache
>>> is not a performance bottleneck that leads to poor performance and
>>> power. The same idea applies for RAM/DDR.
>>>
>>> To achieve this, this patch add support for cpu based scaling to the
>>> passive governor. This is accomplished by taking the current frequency
>>> of each CPU frequency domain and then adjusts the frequency of the cache
>>> (or any devfreq device) based on the frequency of the CPUs. It listens
>>> to CPU frequency transition notifiers to keep itself up to date on the
>>> current CPU frequency.
>>>
>>> To decide the frequency of the device, the governor does one of the
>>> following:
>>> * Constructs a CPU frequency to device frequency mapping table from
>>> required-opps property of the devfreq device's opp_table
>>>
>>> * Scales the device frequency in proportion to the CPU frequency. So, if
>>> the CPUs are running at their max frequency, the device runs at its
>>> max frequency. If the CPUs are running at their min frequency, the
>>> device runs at its min frequency. It is interpolated for frequencies
>>> in between.
>>>
>>> Signed-off-by: Saravana Kannan
>>> [Sibi: Integrated cpu-freqmap governor into passive_governor]
>>> Signed-off-by: Sibi Sankar
>>> ---
>>> drivers/devfreq/Kconfig | 4 +
>>> drivers/devfreq/governor_passive.c | 276 -
>>> include/linux/devfreq.h | 43 -
>>> 3 files changed, 315 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>>> index 6a172d338f6d..9a45f464a56b 100644
>>> --- a/drivers/devfreq/Kconfig
>>> +++ b/drivers/devfreq/Kconfig
>>> @@ -72,6 +72,10 @@ config DEVFREQ_GOV_PASSIVE
>>> device. This governor does not change the frequency by itself
>>> through sysfs entries. The passive governor recommends that
>>> devfreq device uses the OPP table to get the frequency/voltage.
>>> + Alternatively the governor can also be chosen to scale based on
>>> + the online CPUs current frequency. A CPU frequency to device
>>> + frequency mapping table(s) is auto-populated by the governor
>>> + for this purpose.
>>>
>>> comment "DEVFREQ Drivers"
>>>
>>> diff --git a/drivers/devfreq/governor_passive.c
>>> b/drivers/devfreq/governor_passive.c
>>> index 3bc29acbd54e..2506682b233b 100644
>>> --- a/drivers/devfreq/governor_passive.c
>>> +++ b/drivers/devfreq/governor_passive.c
>>> @@ -11,10 +11,63 @@
>>> */
>>>
>>> #include
>>> +#include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> #include "governor.h"
>>>
>>> +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data
>>> *data,
>>> + unsigned int cpu)
>>> +{
>>> + unsigned int cpu_min, cpu_max;
>>> + struct devfreq *devfreq = (struct devfreq *)data->this;
>>> + unsigned int dev_min, dev_max, cpu_percent, cpu_freq = 0, freq = 0;
>>> + unsigned long *freq_table = devfreq->profile->freq_table;
>>> + struct device *dev = devfreq->dev.parent;
>>> + struct devfreq_map *map;
>>> + int opp_cnt, i;
>>> +
>>> + if (!data->state[cpu] || data->state[cpu
Re: [PATCH] PM / devfreq: try_then_request_governor should not return NULL
Hi Rob, You're right. It have to be posted to sta...@vger.kernel.org. As you recommended, I send it[1] to sta...@vger.kernel.org for fixup. [1]https://lkml.org/lkml/2019/5/27/547 Best Regards, Chanwoo Choi On 19. 5. 24. 오후 10:15, Rob Clark wrote: > Ahh, thanks, I've not moved to the latest -rc yet.. > > That commit would be a good candidate for 5.1.y stable branch > > BR, > -R > > On Fri, May 24, 2019 at 12:13 AM Chanwoo Choi wrote: >> >> Hi, >> >> This issue[1] is already fixed on latest linux.git >> You can check it. Thanks. >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b53b0128052ffd687797d5f4deeb76327e7b5711 >> >> Regards, >> Chanwoo Choi >> >> >> On 19. 5. 24. 오전 6:58, Rob Clark wrote: >>> From: Rob Clark >>> >>> The two spots it is called expect either an IS_ERR() or a valid pointer, >>> but not NULL. >>> >>> Fixes this crash that I came across: >>> >>>Unable to handle kernel NULL pointer dereference at virtual address >>> 0030 >>>Mem abort info: >>> ESR = 0x9605 >>> Exception class = DABT (current EL), IL = 32 bits >>> SET = 0, FnV = 0 >>> EA = 0, S1PTW = 0 >>>Data abort info: >>> ISV = 0, ISS = 0x0005 >>> CM = 0, WnR = 0 >>>[0030] user address but active_mm is swapper >>>Internal error: Oops: 9605 [#1] PREEMPT SMP >>>Modules linked in: >>>Process kworker/2:1 (pid: 212, stack limit = 0x(ptrval)) >>>CPU: 2 PID: 212 Comm: kworker/2:1 Not tainted >>> 5.1.0-43338-g460e6984675c-dirty #54 >>>Hardware name: Google Cheza (rev3+) (DT) >>>Workqueue: events deferred_probe_work_func >>>pstate: 00c9 (nzcv daif +PAN +UAO) >>>pc : devfreq_add_device+0x2e4/0x410 >>>lr : devfreq_add_device+0x2d4/0x410 >>>sp : ff8013d93740 >>>x29: ff8013d93790 x28: ffc0f54f8670 >>>x27: 0001 x26: 0007 >>>x25: ff80124abfd8 x24: >>>x23: ffc0fabc4048 x22: ffc0fabc4388 >>>x21: ffc0fabc4010 x20: ffc0fa243010 >>>x19: ffc0fabc4000 x18: 91c3d373 >>>x17: 0400 x16: 001a >>>x15: 00019e06d400 x14: 0001 >>>x13: x12: 06b6 >>>x11: x10: >>>x9 : ffc0fa18ba00 x8 : >>>x7 : x6 : ff80127a3d9a >>>x5 : ff8013d93550 x4 : >>>x3 : x2 : >>>x1 : 00fe x0 : >>>Call trace: >>> devfreq_add_device+0x2e4/0x410 >>> devm_devfreq_add_device+0x64/0xac >>> msm_gpu_init+0x320/0x5c0 >>> adreno_gpu_init+0x21c/0x274 >>> a6xx_gpu_init+0x68/0xf4 >>> adreno_bind+0x158/0x284 >>> component_bind_all+0x110/0x204 >>> msm_drm_bind+0x118/0x5b8 >>> try_to_bring_up_master+0x15c/0x19c >>> component_master_add_with_match+0xb4/0xec >>> msm_pdev_probe+0x1f0/0x27c >>> platform_drv_probe+0x90/0xb0 >>> really_probe+0x120/0x298 >>> driver_probe_device+0x64/0xfc >>> __device_attach_driver+0x8c/0xa4 >>> bus_for_each_drv+0x88/0xd0 >>> __device_attach+0xac/0x134 >>> device_initial_probe+0x20/0x2c >>> bus_probe_device+0x34/0x90 >>> deferred_probe_work_func+0x74/0xac >>> process_one_work+0x210/0x428 >>> worker_thread+0x278/0x3e4 >>> kthread+0x120/0x130 >>> ret_from_fork+0x10/0x18 >>>Code: aa0003f8 b13ffc1f 54000762 f901c278 (f9401b08) >>>---[ end trace a6ecc18ce5894375 ]--- >>>Kernel panic - not syncing: Fatal exception >>> >>> Signed-off-by: Rob Clark >>> --- >>> 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 0ae3de76833b..d29f66f0e52a 100644 >>> --- a/drivers/devfreq/devfreq.c >>> +++ b/drivers/devfreq/devfreq.c >>> @@ -254,7 +254,7 @@ static struct devfreq_governor >>> *try_then_request_governor(const char *name) >>> /* Restore previous state before return */ >>> mutex_lock(_list_lock); >>> if (err) >>> - return NULL; >>> + return ERR_PTR(err); >>> >>> governor = find_devfreq_governor(name); >>> } >>> >> >> >> -- >> Best Regards, >> Chanwoo Choi >> Samsung Electronics > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [RESEND PATCH] PM / devfreq: Fix static checker warning in try_then_request_governor
Cc: sta...@vger.kernel.org
Dear all,
It missed to send this patch to 'sta...@vger.kernel.org'.
So, I add it to mailing list.
Regards,
Chanwoo Choi
On 19. 3. 13. 오후 9:22, Enric Balletbo i Serra wrote:
> The patch 23c7b54ca1cd: "PM / devfreq: Fix devfreq_add_device() when
> drivers are built as modules." leads to the following static checker
> warning:
>
> drivers/devfreq/devfreq.c:1043 governor_store()
> warn: 'governor' can also be NULL
>
> The reason is that the try_then_request_governor() function returns both
> error pointers and NULL. It should just return error pointers, so fix
> this by returning a ERR_PTR to the error intead of returning NULL.
>
> Fixes: 23c7b54ca1cd ("PM / devfreq: Fix devfreq_add_device() when drivers are
> built as modules.")
> Reported-by: Dan Carpenter
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chanwoo Choi
> ---
> Hi,
>
> This is a resend of [1] as seems that got lost at some point and I just
> noticed that was never merged.
>
> Thanks,
> Enric
>
> [1] https://lkml.org/lkml/2018/10/16/744
>
>
> drivers/devfreq/devfreq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 0ae3de76833b..839621b044f4 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -228,7 +228,7 @@ static struct devfreq_governor
> *find_devfreq_governor(const char *name)
> * if is not found. This can happen when both drivers (the governor driver
> * and the driver that call devfreq_add_device) are built as modules.
> * devfreq_list_lock should be held by the caller. Returns the matched
> - * governor's pointer.
> + * governor's pointer or an error pointer.
> */
> static struct devfreq_governor *try_then_request_governor(const char *name)
> {
> @@ -254,7 +254,7 @@ static struct devfreq_governor
> *try_then_request_governor(const char *name)
> /* Restore previous state before return */
> mutex_lock(_list_lock);
> if (err)
> - return NULL;
> + return ERR_PTR(err);
>
> governor = find_devfreq_governor(name);
> }
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] PM / devfreq: try_then_request_governor should not return NULL
Hi, This issue[1] is already fixed on latest linux.git You can check it. Thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b53b0128052ffd687797d5f4deeb76327e7b5711 Regards, Chanwoo Choi On 19. 5. 24. 오전 6:58, Rob Clark wrote: > From: Rob Clark > > The two spots it is called expect either an IS_ERR() or a valid pointer, > but not NULL. > > Fixes this crash that I came across: > >Unable to handle kernel NULL pointer dereference at virtual address > 0030 >Mem abort info: > ESR = 0x9605 > Exception class = DABT (current EL), IL = 32 bits > SET = 0, FnV = 0 > EA = 0, S1PTW = 0 >Data abort info: > ISV = 0, ISS = 0x0005 > CM = 0, WnR = 0 >[0030] user address but active_mm is swapper >Internal error: Oops: 9605 [#1] PREEMPT SMP >Modules linked in: >Process kworker/2:1 (pid: 212, stack limit = 0x(ptrval)) >CPU: 2 PID: 212 Comm: kworker/2:1 Not tainted > 5.1.0-43338-g460e6984675c-dirty #54 >Hardware name: Google Cheza (rev3+) (DT) >Workqueue: events deferred_probe_work_func >pstate: 00c9 (nzcv daif +PAN +UAO) >pc : devfreq_add_device+0x2e4/0x410 >lr : devfreq_add_device+0x2d4/0x410 >sp : ff8013d93740 >x29: ff8013d93790 x28: ffc0f54f8670 >x27: 0001 x26: 0007 >x25: ff80124abfd8 x24: >x23: ffc0fabc4048 x22: ffc0fabc4388 >x21: ffc0fabc4010 x20: ffc0fa243010 >x19: ffc0fabc4000 x18: 91c3d373 >x17: 0400 x16: 001a >x15: 00019e06d400 x14: 0001 >x13: x12: 06b6 >x11: x10: >x9 : ffc0fa18ba00 x8 : >x7 : x6 : ff80127a3d9a >x5 : ff8013d93550 x4 : >x3 : x2 : >x1 : 00fe x0 : >Call trace: > devfreq_add_device+0x2e4/0x410 > devm_devfreq_add_device+0x64/0xac > msm_gpu_init+0x320/0x5c0 > adreno_gpu_init+0x21c/0x274 > a6xx_gpu_init+0x68/0xf4 > adreno_bind+0x158/0x284 > component_bind_all+0x110/0x204 > msm_drm_bind+0x118/0x5b8 > try_to_bring_up_master+0x15c/0x19c > component_master_add_with_match+0xb4/0xec > msm_pdev_probe+0x1f0/0x27c > platform_drv_probe+0x90/0xb0 > really_probe+0x120/0x298 > driver_probe_device+0x64/0xfc > __device_attach_driver+0x8c/0xa4 > bus_for_each_drv+0x88/0xd0 > __device_attach+0xac/0x134 > device_initial_probe+0x20/0x2c > bus_probe_device+0x34/0x90 > deferred_probe_work_func+0x74/0xac > process_one_work+0x210/0x428 > worker_thread+0x278/0x3e4 > kthread+0x120/0x130 > ret_from_fork+0x10/0x18 >Code: aa0003f8 b13ffc1f 54000762 f901c278 (f9401b08) >---[ end trace a6ecc18ce5894375 ]--- >Kernel panic - not syncing: Fatal exception > > Signed-off-by: Rob Clark > --- > 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 0ae3de76833b..d29f66f0e52a 100644 > --- a/drivers/devfreq/devfreq.c > +++ b/drivers/devfreq/devfreq.c > @@ -254,7 +254,7 @@ static struct devfreq_governor > *try_then_request_governor(const char *name) > /* Restore previous state before return */ > mutex_lock(_list_lock); > if (err) > - return NULL; > + return ERR_PTR(err); > > governor = find_devfreq_governor(name); > } > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v7 01/13] clk: samsung: add needed IDs for DMC clocks in Exynos5420
On 19. 5. 7. 오후 5:51, Lukasz Luba wrote: > Hi Chanwoo, > > On 5/7/19 9:33 AM, Chanwoo Choi wrote: >> Hi Lukasz, >> >> On 19. 5. 7. 오전 12:11, Lukasz Luba wrote: >>> Define new IDs for clocks used by Dynamic Memory Controller in >>> Exynos5422 SoC. >>> >>> Acked-by: Rob Herring >>> Signed-off-by: Lukasz Luba >>> --- >>> include/dt-bindings/clock/exynos5420.h | 28 ++-- >>> 1 file changed, 22 insertions(+), 6 deletions(-) >>> >>> diff --git a/include/dt-bindings/clock/exynos5420.h >>> b/include/dt-bindings/clock/exynos5420.h >>> index 355f469..bf50d8a 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_12M 160 >>> #define CLK_SCLK_MPHY_IXTAL24 161 >>> +#define CLK_SCLK_BPLL 162 >>> >>> /* gate clocks */ >>> #define CLK_UART0 257 >>> @@ -195,6 +196,16 @@ >>> #define CLK_ACLK432_CAM 518 >>> #define CLK_ACLK_FL1550_CAM 519 >>> #define CLK_ACLK550_CAM 520 >>> +#define CLK_CLKM_PHY0 521 >>> +#define CLK_CLKM_PHY1 522 >>> +#define CLK_ACLK_PPMU_DREX0_0 523 >>> +#define CLK_ACLK_PPMU_DREX0_1 524 >>> +#define CLK_ACLK_PPMU_DREX1_0 525 >>> +#define CLK_ACLK_PPMU_DREX1_1 526 >>> +#define CLK_PCLK_PPMU_DREX0_0 527 >>> +#define CLK_PCLK_PPMU_DREX0_1 528 >>> +#define CLK_PCLK_PPMU_DREX1_0 529 >>> +#define CLK_PCLK_PPMU_DREX1_1 530 >>> >>> /* mux clocks */ >>> #define CLK_MOUT_HDMI 640 >>> @@ -217,6 +228,8 @@ >>> #define CLK_MOUT_EPLL 657 >>> #define CLK_MOUT_MAU_EPLL 658 >>> #define CLK_MOUT_USER_MAU_EPLL659 >>> +#define CLK_MOUT_SCLK_SPLL 660 >>> +#define CLK_MOUT_MX_MSPLL_CCORE_PHY661 >>> >>> /* divider clocks */ >>> #define CLK_DOUT_PIXEL768 >>> @@ -243,13 +256,16 @@ >>> #define CLK_DOUT_ACLK300_GSCL 789 >>> #define CLK_DOUT_ACLK400_DISP1790 >>> #define CLK_DOUT_PCLK_CDREX 791 >>> -#define CLK_DOUT_SCLK_CDREX792 >>> -#define CLK_DOUT_ACLK_CDREX1 793 >>> -#define CLK_DOUT_CCLK_DREX0794 >>> -#define CLK_DOUT_CLK2X_PHY0795 >>> -#define CLK_DOUT_PCLK_CORE_MEM 796 >> >> The your previous patch didn't change the id number >> of already exiting clocks. It cause the fault. >> In order to keep the compatibility, you keep >> the original id number without modification. > True, the previous patch didn't change these IDs. > I have not seen any faults during builds and stress tests, though. If you use the built dtb file before modification, it cause the fault. It is advantage of device-tree style to split out the dependency between kernel image and dtb. >> >> Please don't change the id number of the existing clocks >> and then just add the new clocks. > OK, I will add CLK_DOUT_PCLK_DREX0and CLK_DOUT_PCLK_DREX1 > at the end: > -->8-- > @@ -248,8 +261,11 @@ > #define CLK_DOUT_CCLK_DREX0794 > #define CLK_DOUT_CLK2X_PHY0795 > #define CLK_DOUT_PCLK_CORE_MEM 796 > +#define CLK_FF_DOUT_SPLL2 797 > +#define CLK_DOUT_PCLK_DREX0798 > +#define CLK_DOUT_PCLK_DREX1799 > > /* must be greater than maximal clock id */ > -#define CLK_NR_CLKS797 > +#define CLK_NR_CLKS800 > -8<--- > > Can I add your ack in the modified version? I agree. > > Regards, > Lukasz >> >> >>> +#define CLK_DOUT_PCLK_DREX0792 >>> +#define CLK_DOUT_PCLK_DREX1793 >>> +#define CLK_DOUT_SCLK_CDREX794 >>> +#define CLK_DOUT_ACLK_CDREX1 795 >>> +#define CLK_DOUT_CCLK_DREX0796 >>> +#define CLK_DOUT_CLK2X_PHY0797 >>> +#define CLK_DOUT_PCLK_CORE_MEM 798 >>> +#define CLK_FF_DOUT_SPLL2 799 >>> >>> /* must be greater than maximal clock id */ >>> -#define CLK_NR_CLKS797 >>> +#define CLK_NR_CLKS800 >>> >>> #endif /* _DT_BINDINGS_CLOCK_EXYNOS_5420_H */ >>> >> > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v7 02/13] clk: samsung: add new clocks for DMC for Exynos5422 SoC
+ * synchronization between the BUS and DREXs (two external memory
> + * interfaces).
> + * They are put here to show this HW assumption and for clock
> + * information summary completeness.
> + */
> DIV(CLK_DOUT_PCLK_CDREX, "dout_pclk_cdrex", "dout_aclk_cdrex1",
> DIV_CDREX0, 28, 3),
> + DIV(CLK_DOUT_PCLK_DREX0, "dout_pclk_drex0", "dout_cclk_drex0",
> + DIV_CDREX0, 28, 3),
> + DIV(CLK_DOUT_PCLK_DREX1, "dout_pclk_drex1", "dout_cclk_drex0",
> + DIV_CDREX0, 28, 3),
> +
> DIV_F(CLK_DOUT_SCLK_CDREX, "dout_sclk_cdrex", "mout_mclk_cdrex",
> DIV_CDREX0, 24, 3, CLK_SET_RATE_PARENT, 0),
> DIV(CLK_DOUT_ACLK_CDREX1, "dout_aclk_cdrex1", "dout_clk2x_phy0",
> @@ -817,6 +840,7 @@ 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),
>
> +
Maybe, it is not related to this patch? Please remove it.
> DIV(CLK_DOUT_PCLK_CORE_MEM, "dout_pclk_core_mem", "mout_mclk_cdrex",
> DIV_CDREX1, 8, 3),
>
> @@ -1170,6 +1194,32 @@ 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),
> + 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),
> };
>
> static const struct samsung_div_clock exynos5x_disp_div_clks[] __initconst =
> {
>
If you fix minor issue about adding the unneeded blanke line,
feel free to add my acked-by tag:
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v7 03/13] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi Lukasz,
On 19. 5. 7. 오전 12:11, 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 | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index af62b6d..23c60a5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -1335,6 +1335,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),
> @@ -1477,9 +1488,13 @@ 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;
> }
>
> + if (soc == EXYNOS5420)
> + exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
> + else
> + exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
> +
> samsung_clk_register_pll(ctx, exynos5x_plls, ARRAY_SIZE(exynos5x_plls),
> reg_base);
> samsung_clk_register_fixed_rate(ctx, exynos5x_fixed_rate_clks,
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v7 01/13] clk: samsung: add needed IDs for DMC clocks in Exynos5420
Hi Lukasz, On 19. 5. 7. 오전 12:11, Lukasz Luba wrote: > Define new IDs for clocks used by Dynamic Memory Controller in > Exynos5422 SoC. > > Acked-by: Rob Herring > Signed-off-by: Lukasz Luba > --- > include/dt-bindings/clock/exynos5420.h | 28 ++-- > 1 file changed, 22 insertions(+), 6 deletions(-) > > diff --git a/include/dt-bindings/clock/exynos5420.h > b/include/dt-bindings/clock/exynos5420.h > index 355f469..bf50d8a 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,8 @@ > #define CLK_MOUT_EPLL657 > #define CLK_MOUT_MAU_EPLL658 > #define CLK_MOUT_USER_MAU_EPLL 659 > +#define CLK_MOUT_SCLK_SPLL 660 > +#define CLK_MOUT_MX_MSPLL_CCORE_PHY 661 > > /* divider clocks */ > #define CLK_DOUT_PIXEL 768 > @@ -243,13 +256,16 @@ > #define CLK_DOUT_ACLK300_GSCL789 > #define CLK_DOUT_ACLK400_DISP1 790 > #define CLK_DOUT_PCLK_CDREX 791 > -#define CLK_DOUT_SCLK_CDREX 792 > -#define CLK_DOUT_ACLK_CDREX1 793 > -#define CLK_DOUT_CCLK_DREX0 794 > -#define CLK_DOUT_CLK2X_PHY0 795 > -#define CLK_DOUT_PCLK_CORE_MEM 796 The your previous patch didn't change the id number of already exiting clocks. It cause the fault. In order to keep the compatibility, you keep the original id number without modification. Please don't change the id number of the existing clocks and then just add the new clocks. > +#define CLK_DOUT_PCLK_DREX0 792 > +#define CLK_DOUT_PCLK_DREX1 793 > +#define CLK_DOUT_SCLK_CDREX 794 > +#define CLK_DOUT_ACLK_CDREX1 795 > +#define CLK_DOUT_CCLK_DREX0 796 > +#define CLK_DOUT_CLK2X_PHY0 797 > +#define CLK_DOUT_PCLK_CORE_MEM 798 > +#define CLK_FF_DOUT_SPLL2799 > > /* must be greater than maximal clock id */ > -#define CLK_NR_CLKS 797 > +#define CLK_NR_CLKS 800 > > #endif /* _DT_BINDINGS_CLOCK_EXYNOS_5420_H */ > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v5 3/6] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.
Hi
Also, this patch was applied to linux-pm.git for for v5.2-rc1.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge=adfe3b76608ffe547af5a74415f15499b798f32a
On 19. 5. 3. 오전 2:58, Gaël PORTAY wrote:
> From: Enric Balletbo i Serra
>
> Trusted Firmware-A (TF-A) for rk3399 implements a SiP call to get the
> on-die termination (ODT) and auto power down parameters from kernel,
> this patch adds the functionality to do this. Also, if DDR clock
> frequency is lower than the on-die termination (ODT) disable frequency
> this driver should disable the DDR ODT.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Chanwoo Choi
> Signed-off-by: Gaël PORTAY
> Acked-by: MyungJoo Ham
> ---
>
> Changes in v5: None
>
> Changes in v4:
> - [PATCH v3 3/5] Add Acked-by: MyungJoo Ham .
>
> Changes in v3:
> - [PATCH v2 3/5] Add Signed-off-by: Gaël PORTAY .
>Remove comments.
>Move pmu dt parsing after dt-parsing of timings to fix
> data->odt_dis_freq value.
>
> Changes in v2: None
>
> Changes in v1:
> - [RFC 3/10] Add an explanation for platform SIP calls.
> - [RFC 3/10] Change if statement for a switch.
> - [RFC 3/10] Rename ddr_flag to odt_enable to be more clear.
>
> drivers/devfreq/rk3399_dmc.c| 71 -
> include/soc/rockchip/rockchip_sip.h | 1 +
> 2 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> index e795ad2b3f6b..daf19e121c99 100644
> --- a/drivers/devfreq/rk3399_dmc.c
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -18,14 +18,17 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
> +#include
> #include
>
> struct dram_timing {
> @@ -69,8 +72,11 @@ struct rk3399_dmcfreq {
> struct mutex lock;
> struct dram_timing timing;
> struct regulator *vdd_center;
> + struct regmap *regmap_pmu;
> unsigned long rate, target_rate;
> unsigned long volt, target_volt;
> + unsigned int odt_dis_freq;
> + int odt_pd_arg0, odt_pd_arg1;
> };
>
> static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
> @@ -80,6 +86,8 @@ static int rk3399_dmcfreq_target(struct device *dev,
> unsigned long *freq,
> struct dev_pm_opp *opp;
> unsigned long old_clk_rate = dmcfreq->rate;
> unsigned long target_volt, target_rate;
> + struct arm_smccc_res res;
> + bool odt_enable = false;
> int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> @@ -95,6 +103,19 @@ static int rk3399_dmcfreq_target(struct device *dev,
> unsigned long *freq,
>
> mutex_lock(>lock);
>
> + if (target_rate >= dmcfreq->odt_dis_freq)
> + odt_enable = true;
> +
> + /*
> + * This makes a SMC call to the TF-A to set the DDR PD (power-down)
> + * timings and to enable or disable the ODT (on-die termination)
> + * resistors.
> + */
> + arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
> + dmcfreq->odt_pd_arg1,
> + ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
> + odt_enable, 0, 0, 0, );
> +
> /*
>* If frequency scaling from low to high, adjust voltage first.
>* If frequency scaling from high to low, adjust frequency first.
> @@ -294,11 +315,13 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> {
> struct arm_smccc_res res;
> struct device *dev = >dev;
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.of_node, *node;
> struct rk3399_dmcfreq *data;
> int ret, index, size;
> uint32_t *timing;
> struct dev_pm_opp *opp;
> + u32 ddr_type;
> + u32 val;
>
> data = devm_kzalloc(dev, sizeof(struct rk3399_dmcfreq), GFP_KERNEL);
> if (!data)
> @@ -354,10 +377,56 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> }
> }
>
> + node = of_parse_phandle(np, "rockchip,pmu", 0);
> + if (node) {
> + data->regmap_pmu = syscon_node_to_regmap(node);
> + if (IS_ERR(data->regmap_pmu))
> + return PTR_ERR(data->regmap_pmu);
> + }
> +
> + regmap_read(data->regmap_pmu, RK3399_PMUGRF_OS_REG2, );
> + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> + RK3399_
Re: [PATCH v5 1/6] devfreq: rockchip-dfi: Move GRF definitions to a common place.
Hi Gaël,
The patch1 was already applied to devfreq.git
and then it was applied to linux-pm.git through
pull request of devfreq.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge=adfe3b76608ffe547af5a74415f15499b798f32a
On 19. 5. 3. 오전 2:58, Gaël PORTAY wrote:
> From: Enric Balletbo i Serra
>
> Some rk3399 GRF (Generic Register Files) definitions can be used for
> different drivers. Move these definitions to a common include so we
> don't need to duplicate these definitions.
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Chanwoo Choi
> Signed-off-by: Gaël PORTAY
> Acked-by: MyungJoo Ham
> ---
>
> Changes in v5: None
>
> Changes in v4:
> - [PATCH v3 1/5] Add Acked-by: MyungJoo Ham .
>
> Changes in v3:
> - [PATCH v2 1/5] Add Signed-off-by: Gaël PORTAY .
>
> Changes in v2:
> - [PATCH 1/8] Really add Acked-by: Chanwoo Choi .
>
> Changes in v1:
> - [RFC 1/10] Add Acked-by: Chanwoo Choi
> - [RFC 1/10] s/Generic/General/ (Robin Murphy)
> - [RFC 4/10] Removed from the series. I did not found a use case where not
> holding the mutex causes the issue.
> - [RFC 7/10] Removed from the series. I did not found a use case where this
> matters.
>
> drivers/devfreq/event/rockchip-dfi.c | 23 +++
> include/soc/rockchip/rk3399_grf.h| 21 +
> 2 files changed, 28 insertions(+), 16 deletions(-)
> create mode 100644 include/soc/rockchip/rk3399_grf.h
>
> diff --git a/drivers/devfreq/event/rockchip-dfi.c
> b/drivers/devfreq/event/rockchip-dfi.c
> index 22b113363ffc..2fbbcbeb644f 100644
> --- a/drivers/devfreq/event/rockchip-dfi.c
> +++ b/drivers/devfreq/event/rockchip-dfi.c
> @@ -26,6 +26,8 @@
> #include
> #include
>
> +#include
> +
> #define RK3399_DMC_NUM_CH2
>
> /* DDRMON_CTRL */
> @@ -43,18 +45,6 @@
> #define DDRMON_CH1_COUNT_NUM 0x3c
> #define DDRMON_CH1_DFI_ACCESS_NUM0x40
>
> -/* pmu grf */
> -#define PMUGRF_OS_REG2 0x308
> -#define DDRTYPE_SHIFT13
> -#define DDRTYPE_MASK 7
> -
> -enum {
> - DDR3 = 3,
> - LPDDR3 = 6,
> - LPDDR4 = 7,
> - UNUSED = 0xFF
> -};
> -
> struct dmc_usage {
> u32 access;
> u32 total;
> @@ -83,16 +73,17 @@ static void rockchip_dfi_start_hardware_counter(struct
> devfreq_event_dev *edev)
> u32 ddr_type;
>
> /* get ddr type */
> - regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
> - ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
> + regmap_read(info->regmap_pmu, RK3399_PMUGRF_OS_REG2, );
> + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> + RK3399_PMUGRF_DDRTYPE_MASK;
>
> /* clear DDRMON_CTRL setting */
> writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
>
> /* set ddr type to dfi */
> - if (ddr_type == LPDDR3)
> + if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
> writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
> - else if (ddr_type == LPDDR4)
> + else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
> writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
>
> /* enable count, use software mode */
> diff --git a/include/soc/rockchip/rk3399_grf.h
> b/include/soc/rockchip/rk3399_grf.h
> new file mode 100644
> index ..3eebabcb2812
> --- /dev/null
> +++ b/include/soc/rockchip/rk3399_grf.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Rockchip General Register Files definitions
> + *
> + * Copyright (c) 2018, Collabora Ltd.
> + * Author: Enric Balletbo i Serra
> + */
> +
> +#ifndef __SOC_RK3399_GRF_H
> +#define __SOC_RK3399_GRF_H
> +
> +/* PMU GRF Registers */
> +#define RK3399_PMUGRF_OS_REG20x308
> +#define RK3399_PMUGRF_DDRTYPE_SHIFT 13
> +#define RK3399_PMUGRF_DDRTYPE_MASK 7
> +#define RK3399_PMUGRF_DDRTYPE_DDR3 3
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR2 5
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR3 6
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR4 7
> +
> +#endif
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support
Hi Dmitry,
On 19. 5. 2. 오전 8:37, Dmitry Osipenko wrote:
> Changelog:
>
> v4: Addressed all review comments that were made by Chanwoo Choi to v3:
>
> - changed the driver removal order to match the probe exactly
> - added clarifying comment for 1/8 ratio to the Tegra20 driver
>
> Chanwoo, please also note that the clk patch that should fix
> compilation problem that was reported the kbuild-test-robot is already
> applied and available in the recent linux-next.
I knew that Stephen picked up your path about clock.
>
> v3: Addressed all review comments that were made by Chanwoo Choi to v2.
>
> Patch "Synchronize IRQ after masking it in hardware" morphed into
> "Properly disable interrupts", which disables interrupts more solidly.
>
> Added new minor patch: "Rename tegra-devfreq.c to tegra30-devfreq.c".
>
> Added missed error handlings for dev_pm_opp_add().
>
> v2: The patchset was quite heavily reworked since v1, few patches we
> dropped or squashed into the new ones and more patches we added.
> In a result more bugs and potential problems are fixed now, driver's
> code got more clean up.
>
> The Tegra20 driver-addition patch is now a part of this series, it has
> no changes since v1.
>
> Dmitry Osipenko (16):
> PM / devfreq: tegra: Fix kHz to Hz conversion
> PM / devfreq: tegra: Replace readl-writel with relaxed versions
> PM / devfreq: tegra: Replace write memory barrier with the read
> barrier
> PM / devfreq: tegra: Don't ignore clk errors
> PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe
> PM / devfreq: tegra: Drop primary interrupt handler
> PM / devfreq: tegra: Properly disable interrupts
> PM / devfreq: tegra: Clean up driver's probe / remove
> PM / devfreq: tegra: Avoid inconsistency of current frequency value
> PM / devfreq: tegra: Mark ACTMON's governor as immutable
> PM / devfreq: tegra: Move governor registration to driver's probe
> PM / devfreq: tegra: Reconfigure hardware on governor's restart
> PM / devfreq: tegra: Support Tegra30
> PM / devfreq: tegra: Enable COMPILE_TEST for the driver
> PM / devfreq: tegra: Rename tegra-devfreq.c to tegra30-devfreq.c
> PM / devfreq: Introduce driver for NVIDIA Tegra20
>
> MAINTAINERS | 8 +
> drivers/devfreq/Kconfig | 15 +-
> drivers/devfreq/Makefile | 3 +-
> drivers/devfreq/tegra20-devfreq.c | 212
> .../{tegra-devfreq.c => tegra30-devfreq.c}| 315 --
> 5 files changed, 379 insertions(+), 174 deletions(-)
> create mode 100644 drivers/devfreq/tegra20-devfreq.c
> rename drivers/devfreq/{tegra-devfreq.c => tegra30-devfreq.c} (81%)
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v6 03/10] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi Lukasz,
On 19. 4. 19. 오후 11: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 d9e6653..ddee8bd 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -1323,6 +1323,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),
> @@ -1465,7 +1476,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;
According to your previous reply, the released odroid-xu3 board by hardkernel
might be only CONFIG_SOC_EXYNOS5422_REV_0. Because the kernel configurattion
from hardkernel has 'CONFIG_SOC_EXYNOS5422_REV_0=y'. I'm ok about adding bpll
rate_table.
But, just I have one question. I think that this bpll rate_table is for
only Exynos5422 series. Because the kernel of hardkernel used
driver/clk/samsung/clk-exynos5422.c instead of clk-exynos5420.c commonn driver.
It means that the clk-exynos5422.c of hardkernel's kernel support only
Exynos5422
without any considering the Exynos5420 series.
I think that it might need to check the soc version to use
bpll rate_table as following:
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1438,7 +1438,10 @@ 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 = exynos5422_bpll_rate_table;
+
+ if (soc == EXYNOS5800)
+ 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 v6 06/10] dt-bindings: memory-controllers: add Exynos5422 DMC device description
Hi Lukasz,
On 19. 5. 1. 오전 5:30, Lukasz Luba wrote:
> Hi Chanwoo,
>
> On 4/30/19 6:46 AM, Chanwoo Choi wrote:
>> On 19. 4. 19. 오후 11:19, Lukasz Luba wrote:
>>> The patch adds description for DT binding for a new Exynos5422 Dynamic
>>> Memory Controller device.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> .../bindings/memory-controllers/exynos5422-dmc.txt | 73
>>> ++
>>> 1 file changed, 73 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
>>> b/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
>>> new file mode 100644
>>> index 000..133b3cc
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
>>> @@ -0,0 +1,73 @@
>>> +* 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 and memory frequency.
>>> +
>>> +Required properties for DMC device for Exynos5422:
>>> +- compatible: Should be "samsung,exynos5422-bus".
>>
>> As I already mentioned on many times, it is not fixed.
>> You have to fix it as following:
>> - exynos5422-bus -> exynos5422-dmc
> I don't know how I missed it on my list. My apologies.
>>
>>> +- clock-names : the name of clock used by the bus, "bus".
>>
>> The below examples doesn't contain the 'bus' clock name.
> True. Thank you for pointing this out. I will it.
>
> Regards,
> Lukasz
>>
>>> +- clocks : phandles for clock specified in "clock-names" property.
>>> +- devfreq-events : phandles for PPMU devices connected to this DMC.
>>> +- vdd-supply : phandle for voltage regulator which is connected.
>>> +- reg : registers of two CDREX controllers, chip information, clocks
>>> subsystem.
>>> +- operating-points-v2 : phandle for OPPs described in v2 definition.
>>> +- device-handle : phandle of the connected DRAM memory device. For more
>>> + information please refer to Documentation
>>> +- devfreq-events : phandles of the PPMU events used by the controller.
>>> +
>>> +Example:
>>> +
>>> + 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";
>>> + };
>>> + };
>>> + };
>>> +
>>> + dmc: memory-controller@10c2 {
>>> + compatible = "samsung,exynos5422-dmc";
>>> + reg = <0x10c2 0x1>, <0x10c3 0x1>,
>>> + <0x1000 0x1000>, <0x1003 0x1000>;
As I discussed about the register region of clock subsystem
with Sylwester on patch[1], I expected that you used the regmap
interface to control the register region of clock subsystem.
But, this dt-binding documents doesn't include any information
about regmap interface.
[1] https://lkml.org/lkml/2019/3/6/878
>>> + 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
Re: [PATCH v3 2/4] drivers: devfreq: events: extend events by type of counted data
Hi Lukasz,
On 19. 5. 1. 오전 6:19, Lukasz Luba wrote:
> Hi Chanwoo,
>
> On 4/30/19 9:34 AM, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> On 19. 4. 19. 오후 10:48, Lukasz Luba wrote:
>>> This patch adds posibility to choose what type of data should be counted
>>> by the PPMU counter. Now the type comes from DT where the event has been
>>> defined. When there is no 'event-data-type' the default value is used,
>>> which is 'read data in bytes'.
>>> It is needed when you want to know not only read+write data bytes but
>>> i.e. only write data in byte, or number of read requests, etc.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> drivers/devfreq/event/exynos-ppmu.c | 61
>>> +
>>> include/linux/devfreq-event.h | 6
>>> 2 files changed, 48 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/event/exynos-ppmu.c
>>> b/drivers/devfreq/event/exynos-ppmu.c
>>> index c61de0b..073bf2c 100644
>>> --- a/drivers/devfreq/event/exynos-ppmu.c
>>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>>> @@ -154,9 +154,9 @@ static int exynos_ppmu_set_event(struct
>>> devfreq_event_dev *edev)
>>> if (ret < 0)
>>> return ret;
>>>
>>> - /* Set the event of Read/Write data count */
>>> + /* Set the event of proper data type monitoring */
>>> ret = regmap_write(info->regmap, PPMU_BEVTxSEL(id),
>>> - PPMU_RO_DATA_CNT | PPMU_WO_DATA_CNT);
>>> + edev->desc->data_type);
>>> if (ret < 0)
>>> return ret;
>>>
>>> @@ -368,23 +368,11 @@ static int exynos_ppmu_v2_set_event(struct
>>> devfreq_event_dev *edev)
>>> if (ret < 0)
>>> return ret;
>>>
>>> - /* Set the event of Read/Write data count */
>>> - switch (id) {
>>> - case PPMU_PMNCNT0:
>>> - case PPMU_PMNCNT1:
>>> - case PPMU_PMNCNT2:
>>> - ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
>>> - PPMU_V2_RO_DATA_CNT | PPMU_V2_WO_DATA_CNT);
>>> - if (ret < 0)
>>> - return ret;
>>> - break;
>>> - case PPMU_PMNCNT3:
>>> - ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
>>> - PPMU_V2_EVT3_RW_DATA_CNT);
>>> - if (ret < 0)
>>> - return ret;
>>> - break;
>>> - }
>>> + /* Set the event of proper data type monitoring */
>>> + ret = regmap_write(info->regmap, PPMU_V2_CH_EVx_TYPE(id),
>>> + edev->desc->data_type);
>>> + if (ret < 0)
>>> + return ret;
>>>
>>> /* Reset cycle counter/performance counter and enable PPMU */
>>> ret = regmap_read(info->regmap, PPMU_V2_PMNC, );
>>> @@ -508,6 +496,7 @@ static int of_get_devfreq_events(struct device_node *np,
>>> struct device *dev = info->dev;
>>> struct device_node *events_np, *node;
>>> int i, j, count;
>>> + int ret;
>>>
>>> events_np = of_get_child_by_name(np, "events");
>>> if (!events_np) {
>>> @@ -544,6 +533,40 @@ static int of_get_devfreq_events(struct device_node
>>> *np,
>>> desc[j].driver_data = info;
>>>
>>> of_property_read_string(node, "event-name", [j].name);
>>> + ret = of_property_read_u32(node, "event-data-type",
>>> + [j].data_type);
>>> + if (ret) {
>>> + /* Set the event of proper data type counting.
>>> +* Check if the data type has been defined in DT,
>>> +* use default if not.
>>> +*/
>>> + if (of_device_is_compatible(np,
>>> + "samsung,exynos-ppmu-v2")) {
>>
>> It is not proper to compare the compatible string again
>> in the device driver. Instead, you can define the ppmu device type
>> as following and then use 'struct of_device_id' in order to
>> identify the device type.
> I have been thinking about modifying the code in similar fashion as you
> did. Good to see similar approach. I'll take your changes wit
Re: [PATCH v3 2/4] drivers: devfreq: events: extend events by type of counted data
@@ -23,6 +24,11 @@
#include "exynos-ppmu.h"
+enum exynos_ppmu_type {
+ EXYNOS_TYPE_PPMU,
+ EXYNOS_TYPE_PPMU_V2,
+};
+
struct exynos_ppmu_data {
struct clk *clk;
};
@@ -36,6 +42,7 @@ struct exynos_ppmu {
struct regmap *regmap;
struct exynos_ppmu_data ppmu;
+ enum exynos_ppmu_type ppmu_type;
};
#define PPMU_EVENT(name) \
/* Reset cycle counter/performance counter and enable PPMU */
ret = regmap_read(info->regmap, PPMU_V2_PMNC, );
@@ -483,31 +476,23 @@ static const struct devfreq_event_ops exynos_ppmu_v2_ops
= {
static const struct of_device_id exynos_ppmu_id_match[] = {
{
.compatible = "samsung,exynos-ppmu",
- .data = (void *)_ppmu_ops,
+ .data = (void *)EXYNOS_TYPE_PPMU,
}, {
.compatible = "samsung,exynos-ppmu-v2",
- .data = (void *)_ppmu_v2_ops,
+ .data = (void *)EXYNOS_TYPE_PPMU_V2,
},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, exynos_ppmu_id_match);
-static struct devfreq_event_ops *exynos_bus_get_ops(struct device_node *np)
-{
- const struct of_device_id *match;
-
- match = of_match_node(exynos_ppmu_id_match, np);
- return (struct devfreq_event_ops *)match->data;
-}
-
static int of_get_devfreq_events(struct device_node *np,
struct exynos_ppmu *info)
{
struct devfreq_event_desc *desc;
- struct devfreq_event_ops *event_ops;
struct device *dev = info->dev;
struct device_node *events_np, *node;
int i, j, count;
events_np = of_get_child_by_name(np, "events");
if (!events_np) {
@@ -515,7 +500,6 @@ static int of_get_devfreq_events(struct device_node *np,
"failed to get child node of devfreq-event devices\n");
return -EINVAL;
}
- event_ops = exynos_bus_get_ops(np);
count = of_get_child_count(events_np);
desc = devm_kcalloc(dev, count, sizeof(*desc), GFP_KERNEL);
@@ -540,11 +524,38 @@ static int of_get_devfreq_events(struct device_node *np,
continue;
}
- desc[j].ops = event_ops;
+ switch (info->ppmu_type) {
+ case EXYNOS_TYPE_PPMU:
+ desc[j].ops = _ppmu_ops;
+ break;
+ case EXYNOS_TYPE_PPMU_V2:
+ desc[j].ops = _ppmu_v2_ops;
+ break;
+ }
+
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 3/4] Documentation: devicetree: add PPMU events description
Hi Lukasz,
On 19. 4. 19. 오후 10:48, Lukasz Luba wrote:
> Extend the documenation by events description with new 'event-data-type'
> field. Add example how the event might be defined in DT.
>
> Signed-off-by: Lukasz Luba
> ---
> .../devicetree/bindings/devfreq/event/exynos-ppmu.txt | 18
> ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> index 3e36c1d..47feb5f 100644
> --- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> @@ -145,3 +145,21 @@ Example3 : PPMUv2 nodes in exynos5433.dtsi are listed
> below.
> reg = <0x104d 0x2000>;
> status = "disabled";
> };
> +
> +The 'event' type specified in the PPMU node defines 'event-name'
> +which also contains 'id' number and optionally 'event-data-type'.
> +
> +Example:
> +
> + events {
> + ppmu_leftbus_0: ppmu-event0-leftbus {
> + event-name = "ppmu-event0-leftbus";
> + event-data-type = ;
> + };
> + };
> +
> +The 'event-data-type' defines the type of data which shell be counted
> +by the counter. You can check include/dt-bindings/pmu/exynos_ppmu.h for
> +all possible type, i.e. count read requests, count write data in bytes,
> +etc. This field is optional and when it is missing, the driver code will
> +use default data type.
>
How about editing it as following?
--- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -10,14 +10,23 @@ The Exynos PPMU driver uses the devfreq-event class to
provide event data
to various devfreq devices. The devfreq devices would use the event data when
derterming the current state of each IP.
-Required properties:
+Required properties for PPMU device:
- compatible: Should be "samsung,exynos-ppmu" or "samsung,exynos-ppmu-v2.
- reg: physical base address of each PPMU and length of memory mapped region.
-Optional properties:
+Optional properties for PPMU device:
- clock-names : the name of clock used by the PPMU, "ppmu"
- clocks : phandles for clock specified in "clock-names" property
+Required properties for 'events' child node of PPMU device:
+- event-name : the unique event name among PPMU device
+Optional properties for 'events' child node of PPMU device:
+- event-data-type : Define the type of data which shell be counted
+by the counter. You can check include/dt-bindings/pmu/exynos_ppmu.h for
+all possible type, i.e. count read requests, count write data in bytes,
+etc. This field is optional and when it is missing, the driver code
+will use default data type.
+
Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a {
@@ -145,3 +154,16 @@ Example3 : PPMUv2 nodes in exynos5433.dtsi are listed
below.
reg = <0x104d 0x2000>;
status = "disabled";
};
+
+Example4 : 'event-data-type' in exynos4412-ppmu-common.dtsi are listed below.
+
+ _dmc0 {
+ status = "okay";
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ event-data-type = <(PPMU_RO_DATA_CNT |
+ PPMU_WO_DATA_CNT)>;
+ };
+ };
+ };
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 4/4] DT: arm: exynos4412: add event data type which is monitored
Hi,
On 19. 4. 19. 오후 10:48, Lukasz Luba wrote:
> The patch adds new field in the PPMU event which shows explicitly
> what kind of data the event is monitoring. It is possible to change it
> using defined values in exynos_ppmu.h file.
>
> Signed-off-by: Lukasz Luba
> ---
> arch/arm/boot/dts/exynos4412-ppmu-common.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
> b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
> index 3a3b2fa..549faba 100644
> --- a/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
> @@ -6,12 +6,16 @@
> * Author: Chanwoo Choi
> */
>
> +#include
> +
> _dmc0 {
> status = "okay";
>
> events {
> ppmu_dmc0_3: ppmu-event3-dmc0 {
> event-name = "ppmu-event3-dmc0";
> +event-data-type = <(PPMU_RO_DATA_CNT |
> +PPMU_WO_DATA_CNT)>;
> };
> };
> };
> @@ -22,6 +26,8 @@
> events {
> ppmu_dmc1_3: ppmu-event3-dmc1 {
> event-name = "ppmu-event3-dmc1";
> +event-data-type = <(PPMU_RO_DATA_CNT |
> +PPMU_WO_DATA_CNT)>;
> };
> };
> };
> @@ -32,6 +38,8 @@
> events {
> ppmu_leftbus_3: ppmu-event3-leftbus {
> event-name = "ppmu-event3-leftbus";
> +event-data-type = <(PPMU_RO_DATA_CNT |
> +PPMU_WO_DATA_CNT)>;
> };
> };
> };
> @@ -42,6 +50,8 @@
> events {
> ppmu_rightbus_3: ppmu-event3-rightbus {
> event-name = "ppmu-event3-rightbus";
> +event-data-type = <(PPMU_RO_DATA_CNT |
> +PPMU_WO_DATA_CNT)>;
> };
> };
> };
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 1/4] include: dt-bindings: add Performance Monitoring Unit for Exynos
Hi, I agree of this patch. But, I add the minor comments. If you edit them according to my comment, feel free to add my following tag: Acked-by: Chanwoo Choi On 19. 4. 19. 오후 10:48, Lukasz Luba wrote: > This patch add support of a new feature which can be used in DT: > Performance Monitoring Unit with defined event data type. > In this patch the event data types are defined for Exynos PPMU. > The patch also updates the MAINTAINERS file accordingly and > adds the header file to devfreq event subsystem. > > Signed-off-by: Lukasz Luba > --- > MAINTAINERS | 1 + > include/dt-bindings/pmu/exynos_ppmu.h | 26 ++ > 2 files changed, 27 insertions(+) > create mode 100644 include/dt-bindings/pmu/exynos_ppmu.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3671fde..1ba4b9b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4560,6 +4560,7 @@ T: git > git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git > S: Supported > F: drivers/devfreq/event/ > F: drivers/devfreq/devfreq-event.c > +F: include/dt-bindings/pmu/exynos_ppmu.h > F: include/linux/devfreq-event.h > F: Documentation/devicetree/bindings/devfreq/event/ > > diff --git a/include/dt-bindings/pmu/exynos_ppmu.h > b/include/dt-bindings/pmu/exynos_ppmu.h > new file mode 100644 > index 000..08fdce9 > --- /dev/null > +++ b/include/dt-bindings/pmu/exynos_ppmu.h > @@ -0,0 +1,26 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Samsung Exynos PPMU event types for counting in regs > + * > + * Copyright (c) 2019, Samsung Mabye, "Samsung Electronics" instead of 'Samsung'. > + * Author: Lukasz Luba > + */ > + > +#ifndef __DT_BINDINGS_PMU_EXYNOS_PPMU_H > +#define __DT_BINDINGS_PMU_EXYNOS_PPMU_H > + > + Remove unneeded blank line. > +#define PPMU_RO_BUSY_CYCLE_CNT 0x0 > +#define PPMU_WO_BUSY_CYCLE_CNT 0x1 > +#define PPMU_RW_BUSY_CYCLE_CNT 0x2 > +#define PPMU_RO_REQUEST_CNT 0x3 > +#define PPMU_WO_REQUEST_CNT 0x4 > +#define PPMU_RO_DATA_CNT 0x5 > +#define PPMU_WO_DATA_CNT 0x6 > +#define PPMU_RO_LATENCY 0x12 > +#define PPMU_WO_LATENCY 0x16 > +#define PPMU_V2_RO_DATA_CNT 0x4 > +#define PPMU_V2_WO_DATA_CNT 0x5 > +#define PPMU_V2_EVT3_RW_DATA_CNT 0x22 > + > +#endif > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v6 01/10] clk: samsung: add needed IDs for DMC clocks in Exynos5420
Hi, On 19. 4. 19. 오후 11:19, Lukasz Luba wrote: > Define new IDs for clocks used by Dynamic Memory Controller in > Exynos5422 SoC. > > Acked-by: Rob Herring > 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..abb1842 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,18 @@ > #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 > +#define CLK_CDREX_PAUSE 531 > +#define CLK_CDREX_TIMING_SET 532 I cannot find the usage code of both CLK_CDREX_PAUSE and CLK_CDREX_TIMING_SET in these patchset. Please remove them. (snip) -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v6 06/10] dt-bindings: memory-controllers: add Exynos5422 DMC device description
On 19. 4. 19. 오후 11:19, Lukasz Luba wrote:
> The patch adds description for DT binding for a new Exynos5422 Dynamic
> Memory Controller device.
>
> Signed-off-by: Lukasz Luba
> ---
> .../bindings/memory-controllers/exynos5422-dmc.txt | 73
> ++
> 1 file changed, 73 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
>
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
> b/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
> new file mode 100644
> index 000..133b3cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
> @@ -0,0 +1,73 @@
> +* 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 and memory frequency.
> +
> +Required properties for DMC device for Exynos5422:
> +- compatible: Should be "samsung,exynos5422-bus".
As I already mentioned on many times, it is not fixed.
You have to fix it as following:
- exynos5422-bus -> exynos5422-dmc
> +- clock-names : the name of clock used by the bus, "bus".
The below examples doesn't contain the 'bus' clock name.
> +- clocks : phandles for clock specified in "clock-names" property.
> +- devfreq-events : phandles for PPMU devices connected to this DMC.
> +- vdd-supply : phandle for voltage regulator which is connected.
> +- reg : registers of two CDREX controllers, chip information, clocks
> subsystem.
> +- operating-points-v2 : phandle for OPPs described in v2 definition.
> +- device-handle : phandle of the connected DRAM memory device. For more
> + information please refer to Documentation
> +- devfreq-events : phandles of the PPMU events used by the controller.
> +
> +Example:
> +
> + 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";
> + };
> + };
> + };
> +
> + dmc: memory-controller@10c2 {
> + compatible = "samsung,exynos5422-dmc";
> + reg = <0x10c2 0x1>, <0x10c3 0x1>,
> + <0x1000 0x1000>, <0x1003 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>;
> + 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";
> + operating-points-v2 = <_opp_table>;
> + devfreq-events = <_event3_dmc0_0>, <_event3_dmc0_1>,
> + <_event3_dmc1_0>, <_event3_dmc1_1>;
> + operating-points-v2 = <_opp_table>;
> + device-handle = <_K3QF2F20DB>;
> + vdd-supply = <_reg>;
> + };
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v6 02/10] clk: samsung: add new clocks for DMC for Exynos5422 SoC
Hi Lukasz,
I have no objection about this patch.
Instead, as I commented on v4, in order to reduce the confusion
about multiple clock definitions with same bit range of DIV_CDREX0,
You need to add the additional comment and you better to
define the three clocks at the nearby in this driver.
(CLKDIV_PCLK_CDREX, CLKDIV_PCLK_DREX0, CLKDIV_PCLK_DREX1)
If they are scattered, it is difficult for understanding
why they are developed like this.
[1] [v4,2/8] clk: samsung: add new clocks for DMC for Exynos5422 SoC
- https://lkml.org/lkml/2019/2/12/12
Regards,
Chanwoo Choi
On 19. 4. 19. 오후 11:19, 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.
>
> 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..d9e6653 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -134,6 +134,8 @@
> #define SRC_CDREX0x20200
> #define DIV_CDREX0 0x20500
> #define DIV_CDREX1 0x20504
> +#define GATE_BUS_CDREX0 0x20700
> +#define GATE_BUS_CDREX1 0x20704
> #define KPLL_LOCK0x28000
> #define KPLL_CON00x28100
> #define SRC_KFC 0x28200
> @@ -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,9 @@ 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"};
>
> /* fixed rate clocks generated outside the soc */
> static struct samsung_fixed_rate_clock
> @@ -450,7 +457,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 +479,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,7 +658,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
Re: [PATCH v3 12/16] PM / devfreq: tegra: Reconfigure hardware on governor's restart
; +
> + disable_irq(tegra->irq);
> +
> + for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
> + device_writel(>devices[i], 0x, ACTMON_DEV_CTRL);
> + device_writel(>devices[i], ACTMON_INTR_STATUS_CLEAR,
> + ACTMON_DEV_INTR_STATUS);
> + }
>
> actmon_write_barrier(tegra);
> +
> + enable_irq(tegra->irq);
> }
>
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> @@ -580,22 +567,22 @@ static int tegra_governor_event_handler(struct devfreq
> *devfreq,
> switch (event) {
> case DEVFREQ_GOV_START:
> devfreq_monitor_start(devfreq);
> - tegra_actmon_enable_interrupts(tegra);
> + tegra_actmon_start(tegra);
> break;
>
> case DEVFREQ_GOV_STOP:
> - tegra_actmon_disable_interrupts(tegra);
> + tegra_actmon_stop(tegra);
> devfreq_monitor_stop(devfreq);
> break;
>
> case DEVFREQ_GOV_SUSPEND:
> - tegra_actmon_disable_interrupts(tegra);
> + tegra_actmon_stop(tegra);
> devfreq_monitor_suspend(devfreq);
> break;
>
> case DEVFREQ_GOV_RESUME:
> devfreq_monitor_resume(devfreq);
> - tegra_actmon_enable_interrupts(tegra);
> + tegra_actmon_start(tegra);
> break;
> }
>
> @@ -664,15 +651,10 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> tegra->max_freq = clk_round_rate(tegra->emc_clock, ULONG_MAX) / KHZ;
> tegra->cur_freq = clk_get_rate(tegra->emc_clock) / KHZ;
>
> - actmon_writel(tegra, ACTMON_SAMPLING_PERIOD - 1,
> - ACTMON_GLB_PERIOD_CTRL);
> -
> for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
> dev = tegra->devices + i;
> dev->config = actmon_device_configs + i;
> dev->regs = tegra->regs + dev->config->offset;
> -
> - tegra_actmon_configure_device(tegra, dev);
> }
>
> for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
>
I agree to always initialize the device when START or RESUME
and also to reset the device when STOP or SUSPEND.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 16/16] PM / devfreq: Introduce driver for NVIDIA Tegra20
Hi Dmitry,
Looks good to me. But, just I have one minor comment
about '8' divider value in the tegra_devfreq_get_dev_status().
On the next version, you better to add the comment about the meaning
of '8' divider value.
Reviewed-by: Chanwoo Choi
On 19. 4. 18. 오전 7:29, Dmitry Osipenko wrote:
> Add devfreq driver for NVIDIA Tegra20 SoC's. The driver periodically
> reads out Memory Controller counters and adjusts memory frequency based
> on the memory clients activity.
>
> Signed-off-by: Dmitry Osipenko
> ---
> MAINTAINERS | 8 ++
> drivers/devfreq/Kconfig | 10 ++
> drivers/devfreq/Makefile | 1 +
> drivers/devfreq/tegra20-devfreq.c | 202 ++
> 4 files changed, 221 insertions(+)
> create mode 100644 drivers/devfreq/tegra20-devfreq.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 002d564efbe5..c70896550a27 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10070,6 +10070,14 @@ F: include/linux/memblock.h
> F: mm/memblock.c
> F: Documentation/core-api/boot-time-mm.rst
>
> +MEMORY FREQUENCY SCALING DRIVER FOR NVIDIA TEGRA20
> +M: Dmitry Osipenko
> +L: linux...@vger.kernel.org
> +L: linux-te...@vger.kernel.org
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
> +S: Maintained
> +F: drivers/devfreq/tegra20-devfreq.c
> +
> MEMORY MANAGEMENT
> L: linux...@kvack.org
> W: http://www.linux-mm.org
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index a6bba6e1e7d9..1530dbefa31f 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -100,6 +100,16 @@ config ARM_TEGRA_DEVFREQ
> It reads ACTMON counters of memory controllers and adjusts the
> operating frequencies and voltages with OPP support.
>
> +config ARM_TEGRA20_DEVFREQ
> + tristate "NVIDIA Tegra20 DEVFREQ Driver"
> + depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select PM_OPP
> + help
> + This adds the DEVFREQ driver for the Tegra20 family of SoCs.
> + It reads Memory Controller counters and adjusts the operating
> + frequencies and voltages with OPP support.
> +
> config ARM_RK3399_DMC_DEVFREQ
> tristate "ARM RK3399 DMC DEVFREQ Driver"
> depends on ARCH_ROCKCHIP
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 47e5aeeebfd1..338ae8440db6 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) += tegra30-devfreq.o
> +obj-$(CONFIG_ARM_TEGRA20_DEVFREQ)+= tegra20-devfreq.o
>
> # DEVFREQ Event Drivers
> obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> new file mode 100644
> index ..ec2cec6808ed
> --- /dev/null
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * NVIDIA Tegra20 devfreq driver
> + *
> + * Copyright (C) 2019 GRATE-DRIVER project
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "governor.h"
> +
> +#define MC_STAT_CONTROL 0x90
> +#define MC_STAT_EMC_CLOCK_LIMIT 0xa0
> +#define MC_STAT_EMC_CLOCKS 0xa4
> +#define MC_STAT_EMC_CONTROL 0xa8
> +#define MC_STAT_EMC_COUNT0xb8
> +
> +#define EMC_GATHER_CLEAR (1 << 8)
> +#define EMC_GATHER_ENABLE(3 << 8)
> +
> +struct tegra_devfreq {
> + struct devfreq *devfreq;
> + struct clk *clk;
> + void __iomem *regs;
> +};
> +
> +static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> + u32 flags)
> +{
> + struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> + struct devfreq *devfreq = tegra->devfreq;
> + struct dev_pm_opp *opp;
> + unsigned long rate;
> + int err;
> +
> + opp = devfreq_recommended_opp(dev, freq, flags);
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> +
> + rate = dev_pm_opp_get_freq(opp);
> + dev_pm_opp_put(opp);
> +
> + err = clk_set_min_rate(tegra->clk, rate);
> + if
Re: [PATCH v3 08/16] PM / devfreq: tegra: Clean up driver's probe / remove
+remove_opps:
> + dev_pm_opp_remove_all_dynamic(>dev);
> +
> + reset_control_reset(tegra->reset);
> + clk_disable_unprepare(tegra->clock);
> +
> + return err;
> }
>
> 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;
> -
> - 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);
> + devfreq_remove_device(tegra->devfreq);
> + dev_pm_opp_remove_all_dynamic(>dev);
>
> clk_notifier_unregister(tegra->emc_clock, >rate_change_nb);
nitpick: the probe function has following call sequence if error case,
First, clk_notifier_unregister()
Second, dev_pm_opp_remove_all_dynamic()
If possible, you better to keep the same sequence
in the tegra_devfreq_remove(). But, it is just opinion.
If you think that it doesn't break the routine of device removal,
jut keep this code.
>
> + reset_control_reset(tegra->reset);
> clk_disable_unprepare(tegra->clock);
>
> return 0;
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 07/16] PM / devfreq: tegra: Properly disable interrupts
On 19. 4. 18. 오전 7:29, Dmitry Osipenko wrote:
> There is no guarantee that interrupt handling isn't running in parallel
> with tegra_actmon_disable_interrupts(), hence it is necessary to protect
> DEV_CTRL register accesses and clear IRQ status with ACTMON's IRQ being
> disabled in the Interrupt Controller in order to ensure that device
> interrupt is indeed being disabled.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index b65313fe3c2e..ce1eb97a2090 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 {
> @@ -417,6 +419,8 @@ static void tegra_actmon_disable_interrupts(struct
> tegra_devfreq *tegra)
> u32 val;
> unsigned int i;
>
> + disable_irq(tegra->irq);
> +
> for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
> dev = >devices[i];
>
> @@ -427,9 +431,14 @@ static void tegra_actmon_disable_interrupts(struct
> tegra_devfreq *tegra)
> val &= ~ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_EN;
>
> device_writel(dev, val, ACTMON_DEV_CTRL);
> +
> + device_writel(dev, ACTMON_INTR_STATUS_CLEAR,
> + ACTMON_DEV_INTR_STATUS);
> }
>
> actmon_write_barrier(tegra);
> +
> + enable_irq(tegra->irq);
> }
>
> static void tegra_actmon_configure_device(struct tegra_devfreq *tegra,
> @@ -604,7 +613,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);
> @@ -673,15 +681,16 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> dev_pm_opp_add(>dev, rate, 0);
> }
>
> - irq = platform_get_irq(pdev, 0);
> - if (irq < 0) {
> - dev_err(>dev, "Failed to get IRQ: %d\n", irq);
> - return irq;
> + 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;
> }
>
> platform_set_drvdata(pdev, tegra);
>
> - err = devm_request_threaded_irq(>dev, irq, NULL,
> + err = devm_request_threaded_irq(>dev, tegra->irq, NULL,
> actmon_thread_isr, IRQF_ONESHOT,
> "tegra-devfreq", tegra);
> if (err) {
>
It is ok to disable the hardware interrupt line
before completing the some operation about registers
in order to protect the interrupt occur.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[GIT PULL] extcon next for v5.2
Dear Greg, This is extcon-next pull request for v5.2. I add detailed description of this pull request on below. Please pull extcon with following updates. [Detailed description for this pull request] 1. Add new extcon-intel-mrfld.c extcon provider driver - 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. 2. Update the extcon provider drivers - For extcon-intel-cht-wc.c, make charger detection co-existed with OTG host mode and enable external charger. - For intel extcon driver, add common header file (extcon-intel.h) in order to remove the duplicate definitions. - For extcon-arizonal.c, disable microphone detection on driver removal. 3. - Edit comment of extcon_unregister_notifer() to fix a build warning - Add CONFIG_ACPI dependency to Kconfig to fix a build error for extcon-axp.c Best Regards, Chanwoo Choi The following changes since commit 86baf800de84eb89615c138d368b14bff5ee7d8a: extcon: ptn5150: fix COMPILE_TEST dependencies (2019-04-05 10:08:37 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-5.2 for you to fetch changes up to 00053de52231117ddc154042549f2256183ffb86: extcon: arizona: Disable mic detect if running when driver is removed (2019-04-12 09:38:40 +0900) Andy Shevchenko (2): extcon: intel: Split out some definitions to a common header extcon: mrfld: Introduce extcon driver for Basin Cove PMIC Charles Keepax (1): extcon: arizona: Disable mic detect if running when driver is removed Valdis Kletnieks (1): extcon: Fix build warning for extcon_unregister_notifier comment Yauhen Kharuzhy (2): extcon: intel-cht-wc: Make charger detection co-existed with OTG host mode extcon: intel-cht-wc: Enable external charger YueHaibing (1): extcon: axp288: Add a depends on ACPI to the Kconfig entry drivers/extcon/Kconfig | 9 +- drivers/extcon/Makefile | 1 + drivers/extcon/devres.c | 2 +- drivers/extcon/extcon-arizona.c | 10 ++ drivers/extcon/extcon-intel-cht-wc.c | 81 -- drivers/extcon/extcon-intel-mrfld.c | 284 +++ drivers/extcon/extcon-intel.h| 20 +++ 7 files changed, 389 insertions(+), 18 deletions(-) create mode 100644 drivers/extcon/extcon-intel-mrfld.c create mode 100644 drivers/extcon/extcon-intel.h
Re: [PATCH v3 06/16] PM / devfreq: tegra: Drop primary interrupt handler
return NOTIFY_OK;
> @@ -398,9 +382,7 @@ static int tegra_actmon_rate_notify_cb(struct
> notifier_block *nb,
> 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);
> @@ -682,7 +664,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);
> }
> @@ -700,8 +681,8 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, tegra);
>
> - 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");
>
Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 04/16] PM / devfreq: tegra: Don't ignore clk errors
On 19. 4. 18. 오전 7:29, 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 | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 7d7b9a5895b2..c7428c5eee23 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -484,8 +484,10 @@ static int tegra_devfreq_target(struct device *dev,
> unsigned long *freq,
> u32 flags)
> {
> struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> + struct devfreq *devfreq = tegra->devfreq;
> struct dev_pm_opp *opp;
> unsigned long rate;
> + int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> @@ -495,10 +497,20 @@ 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)
> + goto restore_min_rate;
>
> return 0;
> +
> +restore_min_rate:
> + clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
> +
> + return err;
> }
>
> static int tegra_devfreq_get_dev_status(struct device *dev,
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 15/16] PM / devfreq: tegra: Rename tegra-devfreq.c to tegra30-devfreq.c
On 19. 4. 18. 오전 7:29, Dmitry Osipenko wrote:
> In order to reflect that driver serves NVIDIA Tegra30 and later SoC
> generations, let's rename the driver's source file to "tegra30-devfreq.c".
> This will make driver files to look more consistent after addition of a
> driver for Tegra20.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/Makefile | 2 +-
> drivers/devfreq/{tegra-devfreq.c => tegra30-devfreq.c} | 0
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename drivers/devfreq/{tegra-devfreq.c => tegra30-devfreq.c} (100%)
>
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 32b8d4d3f12c..47e5aeeebfd1 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -10,7 +10,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
> # DEVFREQ Drivers
> 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_TEGRA_DEVFREQ) += tegra30-devfreq.o
>
> # DEVFREQ Event Drivers
> obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
> diff --git a/drivers/devfreq/tegra-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> similarity index 100%
> rename from drivers/devfreq/tegra-devfreq.c
> rename to drivers/devfreq/tegra30-devfreq.c
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 13/16] PM / devfreq: tegra: Support Tegra30
On 19. 4. 18. 오전 7:29, 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..56db9dc05edb 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/114/124/210 DEVFREQ Driver"
> + 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 e9ab49394d35..029afc5fb6a9 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -738,6 +738,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: [GIT PULL] extcon fixes for v5.1-rc4
Dear Greg, On 19. 4. 16. 오후 7:46, Greg KH wrote: > On Fri, Apr 05, 2019 at 10:21:25AM +0900, 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(-) > > Now pulled, sorry for the delay, was on vacation. Thanks for merge. > > greg k-h > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH 3/3] Documentation: devicetree: add PPMU events description
Hi Lukasz,
On 19. 4. 17. 오후 4:48, Lukasz Luba wrote:
> Extend the documenation by events description with new 'event-data-type'
> field. Add example how the event might be defined in DT.
>
> Signed-off-by: Lukasz Luba
> ---
> .../devicetree/bindings/devfreq/event/exynos-ppmu.txt | 18
> ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> index 3e36c1d..47feb5f 100644
> --- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
> @@ -145,3 +145,21 @@ Example3 : PPMUv2 nodes in exynos5433.dtsi are listed
> below.
> reg = <0x104d 0x2000>;
> status = "disabled";
> };
> +
> +The 'event' type specified in the PPMU node defines 'event-name'
> +which also contains 'id' number and optionally 'event-data-type'.
> +
> +Example:
> +
> + events {
> + ppmu_leftbus_0: ppmu-event0-leftbus {
> + event-name = "ppmu-event0-leftbus";
> + event-data-type = ;
> + };
> + };
> +
> +The 'event-data-type' defines the type of data which shell be counted
> +by the counter. You can check include/dt-bindings/pmu/exynos_ppmu.h for
I replied about 'pmu' name on patch2. Please check it.
> +all possible type, i.e. count read requests, count write data in bytes,
> +etc. This field is optional and when it is missing, the driver code will
> +use default data type.
>
Looks good to me.
But, If you want to add the new 'event-data-type' property,
you better to add 'event-data-type' to Exynos dts file including
PPMU device.
If the dts file contain the data type information,
I think it is easy to understand for the user
what is monitoring on PPMU device.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 2/3] drivers: devfreq: events: extend events by type of counted data
r exynos5433,
desc[i].data_type = PPMU_RO_DATA_CNT | PPMU_WO_DATA_CNT;
For exynos5433,
desc[i].data_type = PPMU_V2_EVT3_RW_DATA_CNT;
>
> j++;
> }
> diff --git a/include/linux/devfreq-event.h b/include/linux/devfreq-event.h
> index 4db00b0..cc160b1 100644
> --- a/include/linux/devfreq-event.h
> +++ b/include/linux/devfreq-event.h
> @@ -81,14 +81,20 @@ struct devfreq_event_ops {
> * struct devfreq_event_desc - the descriptor of devfreq-event device
> *
> * @name : the name of devfreq-event device.
> + * @data_type: the data type which is going to be counted in the
> register.
> * @driver_data : the private data for devfreq-event driver.
> * @ops : the operation to control devfreq-event device.
> *
> * Each devfreq-event device is described with a this structure.
> * This structure contains the various data for devfreq-event device.
> + * The data_type describes what is going to be counted in the register.
> + * It might choose to count e.g. read requests, write data in bytes, etc.
> + * The full supported list of types is present in specyfic header in:
> + * include/dt-bindings/pmu/.
Why did you make the path name as the 'pmu' instead of 'ppmu'?
It might have some confusion because 'pmu' has
the two meaning in linux kernel.
- PMU, Power Management Unit
- PMU, Performance Monitoring Unit
> */
> struct devfreq_event_desc {
> const char *name;
> + u32 data_type;
> void *driver_data;
>
> const struct devfreq_event_ops *ops;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 1/3] include: dt-bindings: add Performance Monitoring Unit for Exynos
Hi Lukasz, On 19. 4. 17. 오후 4:48, Lukasz Luba wrote: > This patch add support of a new feature which can be used in DT: > Performance Monitoring Unit with defined event data type. > In this patch the event data types are defined for Exynos PPMU. > The patch also updates the MAINTAINERS file accordingly. > > Signed-off-by: Lukasz Luba > --- > MAINTAINERS | 5 + > include/dt-bindings/pmu/exynos_ppmu.h | 24 > 2 files changed, 29 insertions(+) > create mode 100644 include/dt-bindings/pmu/exynos_ppmu.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3671fde..f4aac78 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -12376,6 +12376,11 @@ L: linux-s...@vger.kernel.org > S: Supported > F: drivers/scsi/pm8001/ > > +PMU EXYNOS DT BINDINGS > +M: Lukasz Luba > +S: Maintained > +F: include/dt-bindings/pmu/exynos_ppmu.h > + IMHO, I'm not sure that it is right of adding one dt-binding header file to MAINTAINERS file. If right, I'm OK. > PNP SUPPORT > M: "Rafael J. Wysocki" > S: Maintained > diff --git a/include/dt-bindings/pmu/exynos_ppmu.h > b/include/dt-bindings/pmu/exynos_ppmu.h > new file mode 100644 > index 000..a6971eb > --- /dev/null > +++ b/include/dt-bindings/pmu/exynos_ppmu.h > @@ -0,0 +1,24 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Samsung Exynos PPMU event types for counting in regs > + * > + * Copyright (c) 2019, Samsung > + * Author: Lukasz Luba > + */ > + > +#ifndef __DT_BINDINGS_PMU_EXYNOS_PPMU_H > +#define __DT_BINDINGS_PMU_EXYNOS_PPMU_H > + > + > +#define PPMU_RO_BUSY_CYCLE_CNT 0x0 > +#define PPMU_WO_BUSY_CYCLE_CNT 0x1 > +#define PPMU_RW_BUSY_CYCLE_CNT 0x2 > +#define PPMU_RO_REQUEST_CNT 0x3 > +#define PPMU_WO_REQUEST_CNT 0x4 > +#define PPMU_RO_DATA_CNT 0x5 > +#define PPMU_WO_DATA_CNT 0x6 > +#define PPMU_RO_LATENCY 0x12 > +#define PPMU_WO_LATENCY 0x16 > +#define PPMU_V2_EVT3_RW_DATA_CNT 0x22 If we can select the data type for monitoring, it looks good to me. But, when I developed the Exynos PPMU, I has not tested other data type except for PPMU_RO_DATA_CNT and PPMU_WO_DATA_CNT. Do you test all data types with PPMU device? > + > +#endif > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 02/19] PM / devfreq: tegra: Replace readl-writel with relaxed versions
Hi,
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> There is no need to insert memory barrier on each readl/writel
> invocation, hence use the relaxed versions.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 02905978abe1..0c0909fba545 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -191,23 +191,23 @@ static struct tegra_actmon_emc_ratio
> actmon_emc_ratios[] = {
>
> static u32 actmon_readl(struct tegra_devfreq *tegra, u32 offset)
> {
> - return readl(tegra->regs + offset);
> + return readl_relaxed(tegra->regs + offset);
> }
>
> static void actmon_writel(struct tegra_devfreq *tegra, u32 val, u32 offset)
> {
> - writel(val, tegra->regs + offset);
> + writel_relaxed(val, tegra->regs + offset);
> }
>
> static u32 device_readl(struct tegra_devfreq_device *dev, u32 offset)
> {
> - return readl(dev->regs + offset);
> + return readl_relaxed(dev->regs + offset);
> }
>
> static void device_writel(struct tegra_devfreq_device *dev, u32 val,
> u32 offset)
> {
> - writel(val, dev->regs + offset);
> + writel_relaxed(val, dev->regs + offset);
> }
>
> static unsigned long do_percent(unsigned long val, unsigned int pct)
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 06/19] PM / devfreq: tegra: Fix missed error checking on devfreq initialization failure
Hi, On 19. 4. 16. 오후 11:29, Dmitry Osipenko wrote: > 16.04.2019 5:32, Chanwoo Choi пишет: >> 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. > > Indeed, I was rebasing and reordering patches multiple times and looks like > there is no reason not to squash these patches now. > >> 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() > > When all of 6/7/8/9 patches are applied, the clk_notifier_register() becomes > the last invocation of the probe function and clk_enable() is kept at the > first place of the probe order. Hence the sequence you're suggesting is > already incorrect because error-unwinding order usually should be opposite to > the probe order. It looks to me that the current final result of these > patches is already correct. You're right. When I replied it, I have not considered the order. Sorry, it made you some confusion. > > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 05/19] PM / devfreq: tegra: Replace write memory barrier with the read barrier
On 19. 4. 16. 오후 10:57, Dmitry Osipenko wrote:
> 16.04.2019 11:00, Chanwoo Choi пишет:
>> 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().
>
> The IO mapped memory is strongly-ordered on ARM, hence all readl/writel
> accesses are guaranteed to be ordered by default. I think wmb() here is just
> a cut-n-pasted relic from old downstream driver.
OK.
>
>> 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()
>
> Yes, the result is the same. The wmb() is not just about IO accesses, but
> about all kind of memory accesses and at least on Tegra30 it is quite
> expensive operation because it translates into L2XO cache syncing
> (arm_heavy_mb) + dsb(). It should be more efficient to flush out writes with
> a read-back and then wait for that read operation to be completed.
>
>
OK. Thanks for explanation.
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. 17. 오전 12:40, Dmitry Osipenko wrote:
> 16.04.2019 10:15, Chanwoo Choi пишет:
>> 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.
>
> No, that's wrong assumption. The tegra->cur_freq is changed by the clock
> notifier that runs asynchronously with the devfreq driver when EMC clock rate
> is changed by something else in the kernel.
>
>> 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;
>> }
>>
>>
>
> The cur_freq value is changed by the clock notifier that runs asynchronously
> with the rest of the devfreq driver. Hence potentially compiler may generate
> two separate fetches of the cur_freq value, then the clock rate could be
> changed by other CPU core simultaneously with tegra_devfreq_get_dev_status()
> or kernel may re-schedule preemptively, changing the clock rate in-between of
> the two fetches.
>
>
Thanks. I understand why have to consider the inconsistency of clock
which is used on the multiple points.
Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 10/19] PM / devfreq: tegra: Drop primary interrupt handler
Hi,
On 19. 4. 17. 오전 12:23, Dmitry Osipenko wrote:
> 16.04.2019 8:56, Chanwoo Choi пишет:
>> Hi,
>>
>> It looks good to me to drop the primary interrupt handler
>> but I have some comments. Please check it.
>>
>> On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
>>> There is no real need in the primary interrupt handler, hence move
>>> everything to the secondary (threaded) handler. In a result locking
>>> is consistent now and there are no potential races with the interrupt
>>> handler because it is protected with the devfreq's mutex.
>>>
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/devfreq/tegra-devfreq.c | 61 -
>>> 1 file changed, 22 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/tegra-devfreq.c
>>> b/drivers/devfreq/tegra-devfreq.c
>>> index 2a1464098200..69b557df5084 100644
>>> --- a/drivers/devfreq/tegra-devfreq.c
>>> +++ b/drivers/devfreq/tegra-devfreq.c
>>> @@ -144,7 +144,6 @@ static struct tegra_devfreq_device_config
>>> actmon_device_configs[] = {
>>> struct tegra_devfreq_device {
>>> const struct tegra_devfreq_device_config *config;
>>> void __iomem *regs;
>>> - spinlock_t lock;
>>>
>>> /* Average event count sampled in the last interrupt */
>>> u32 avg_count;
>>> @@ -249,11 +248,8 @@ static void actmon_write_barrier(struct tegra_devfreq
>>> *tegra)
>>> static void actmon_isr_device(struct tegra_devfreq *tegra,
>>> struct tegra_devfreq_device *dev)
>>> {
>>> - unsigned long flags;
>>> u32 intr_status, dev_ctrl;
>>>
>>> - spin_lock_irqsave(>lock, flags);
>>> -
>>> dev->avg_count = device_readl(dev, ACTMON_DEV_AVG_COUNT);
>>> tegra_devfreq_update_avg_wmark(tegra, dev);
>>>
>>> @@ -302,26 +298,6 @@ static void actmon_isr_device(struct tegra_devfreq
>>> *tegra,
>>> device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
>>>
>>> actmon_write_barrier(tegra);
>>> -
>>> - spin_unlock_irqrestore(>lock, flags);
>>> -}
>>> -
>>> -static irqreturn_t actmon_isr(int irq, void *data)
>>> -{
>>> - struct tegra_devfreq *tegra = data;
>>> - bool handled = false;
>>> - unsigned int i;
>>> - u32 val;
>>> -
>>> - val = actmon_readl(tegra, ACTMON_GLB_STATUS);
>>> - for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
>>> - if (val & tegra->devices[i].config->irq_mask) {
>>> - actmon_isr_device(tegra, tegra->devices + i);
>>> - handled = true;
>>> - }
>>> - }
>>> -
>>> - return handled ? IRQ_WAKE_THREAD : IRQ_NONE;
>>> }
>>>
>>> static unsigned long actmon_cpu_to_emc_rate(struct tegra_devfreq *tegra,
>>> @@ -348,35 +324,46 @@ static void actmon_update_target(struct tegra_devfreq
>>> *tegra,
>>> unsigned long cpu_freq = 0;
>>> unsigned long static_cpu_emc_freq = 0;
>>> unsigned int avg_sustain_coef;
>>> - unsigned long flags;
>>> + u32 avg_count;
>>>
>>> if (dev->config->avg_dependency_threshold) {
>>> cpu_freq = cpufreq_get(0);
>>> static_cpu_emc_freq = actmon_cpu_to_emc_rate(tegra, cpu_freq);
>>> }
>>>
>>> - spin_lock_irqsave(>lock, flags);
>>> -
>>> - dev->target_freq = dev->avg_count / ACTMON_SAMPLING_PERIOD;
>>> + avg_count = dev->avg_count;
>>> + dev->target_freq = avg_count / ACTMON_SAMPLING_PERIOD;
>>
>> Actually, this change is not related to this patch.
>> Please keep the original code.
>>
>>> avg_sustain_coef = 100 * 100 / dev->config->boost_up_threshold;
>>> dev->target_freq = do_percent(dev->target_freq, avg_sustain_coef);
>>> dev->target_freq += dev->boost_freq;
>>>
>>> - if (dev->avg_count >= dev->config->avg_dependency_threshold)
>>> + if (avg_count >= dev->config->avg_dependency_threshold)
>>
>> ditto.
>
> Good catch, it's a leftover from v1 that I forgot to revert. Thank you.
>
> [snip]
>
>>
>> When I review this patch, I have a question
>> about why tegra_actmon_rate_notify_cb is needed.
>>
>> t
Re: [PATCH v2 17/19] PM / devfreq: tegra: Support Tegra30
On 19. 4. 17. 오전 12:49, Dmitry Osipenko wrote:
> 16.04.2019 10:48, Chanwoo Choi пишет:
>> 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.
>
> The ACTMON serves Tegra30, Tegra124 and Tegra210 SoC's. The later Tegra
> generations also have the ACTMON hardware unit, but most of actual drivers
> have been moved into firmware on the later gens, including the ACTMON driver.
> I'll change the wording to "Tegra30/124/210" for clarity. Note that Tegra210
> support isn't implemented at the moment by the driver, but that may change in
> the future.
OK. Thanks.
>
>>> + 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
>>
>
> Thanks.
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 18/19] PM / devfreq: tegra: Enable COMPILE_TEST for the driver
On 19. 4. 17. 오전 12:52, Dmitry Osipenko wrote: > 16.04.2019 10:43, Chanwoo Choi пишет: >> 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. >> > > I'd prefer to have this change as a separate patch because this is a > logically distinct change from the patch 17. > > OK. Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 19/19] PM / devfreq: Introduce driver for NVIDIA Tegra20
Hi, On 19. 4. 17. 오전 1:11, Dmitry Osipenko wrote: > 16.04.2019 11:31, Chanwoo Choi пишет: >> Hi, >> >> On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote: >>> Add devfreq driver for NVIDIA Tegra20 SoC's. The driver periodically >>> reads out Memory Controller counters and adjusts memory frequency based >>> on the memory clients activity. >>> >>> Signed-off-by: Dmitry Osipenko >>> --- >>> MAINTAINERS | 8 ++ >>> drivers/devfreq/Kconfig | 10 ++ >>> drivers/devfreq/Makefile | 1 + >>> drivers/devfreq/tegra20-devfreq.c | 177 ++ >>> 4 files changed, 196 insertions(+) >>> create mode 100644 drivers/devfreq/tegra20-devfreq.c >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 80b59db1b6e4..91f475ec4545 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -10056,6 +10056,14 @@ F: include/linux/memblock.h >>> F: mm/memblock.c >>> F: Documentation/core-api/boot-time-mm.rst >>> >>> +MEMORY FREQUENCY SCALING DRIVER FOR NVIDIA TEGRA20 >>> +M: Dmitry Osipenko >>> +L: linux...@vger.kernel.org >>> +L: linux-te...@vger.kernel.org >>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git >>> +S: Maintained >>> +F: drivers/devfreq/tegra20-devfreq.c >>> + >>> MEMORY MANAGEMENT >>> L: linux...@kvack.org >>> W: http://www.linux-mm.org >>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >>> index bd6652863e7d..af4c86c4e0f6 100644 >>> --- a/drivers/devfreq/Kconfig >>> +++ b/drivers/devfreq/Kconfig >>> @@ -100,6 +100,16 @@ config ARM_TEGRA_DEVFREQ >>> It reads ACTMON counters of memory controllers and adjusts the >>> operating frequencies and voltages with OPP support. >>> >>> +config ARM_TEGRA20_DEVFREQ >>> + tristate "NVIDIA Tegra20 DEVFREQ Driver" >>> + depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST >>> + select DEVFREQ_GOV_SIMPLE_ONDEMAND >>> + select PM_OPP >>> + help >>> + This adds the DEVFREQ driver for the Tegra20 family of SoCs. >>> + It reads Memory Controller counters and adjusts the operating >>> + frequencies and voltages with OPP support. >>> + >>> config ARM_RK3399_DMC_DEVFREQ >>> tristate "ARM RK3399 DMC DEVFREQ Driver" >>> depends on ARCH_ROCKCHIP >>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile >>> index 32b8d4d3f12c..6fcc5596b8b7 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_TEGRA20_DEVFREQ) += tegra20-devfreq.o >>> >>> # DEVFREQ Event Drivers >>> obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/ >>> diff --git a/drivers/devfreq/tegra20-devfreq.c >>> b/drivers/devfreq/tegra20-devfreq.c >>> new file mode 100644 >>> index ..18c9aad7a9d7 >>> --- /dev/null >>> +++ b/drivers/devfreq/tegra20-devfreq.c >>> @@ -0,0 +1,177 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * NVIDIA Tegra20 devfreq driver >>> + * >>> + * Author: Dmitry Osipenko >>> + */ >> >> It doesn't any "Copyright (c) 2019 ..." sentence. > > I'll add one in v3. > >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >> >> I can find the '' header file >> on mainline branch. But mc.h is included in linux-next.git. >> >> If you don't share the patch related to mc.h, >> the kernel build will be failed when apply it the devfreq.git >> on final step. Actually, it should make the immutable branch >> between two related maintainers in order to remove the build fail. > > The '' header file exists since v3.18 [0], seems you just > missed something. > > [0] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/soc/tegra/mc.h?h=v3.18=891
Re: [PATCH v2 3/4] dt-bindings: devfreq: add compatible for mt8183 cci devfreq
Hi,
I already reviewed this patch on v1[1].
[1] https://lkml.org/lkml/2019/2/11/2228
But, the second version patch doesn't include the anything
about review. Please check it[1].
On 19. 3. 29. 오후 3:46, Andrew-sh.Cheng wrote:
> 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
> +
> +Required properties:
> +- compatible: should contain "mediatek,mt8183-cci" for cci devfreq
> +
> +- clocks: for cci devfreq
> +
> +- clock-names: for cci devfreq driver to reference
> +
> +- operating-points-v2: for cci devfreq opp table
> +
> +Example:
> + cci: cci {
> + compatible = "mediatek,cci";
> + clocks = < CLK_APMIXED_CCIPLL>;
> + clock-names = "cci_clock";
> + operating-points-v2 = <_opp>;
> + };
> +
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v2 4/4] devfreq: add mediatek cci devfreq
dev_err(cci_dev, "Fail to init CCI OPP table\n");
> + goto err_put_reg;
> + }
> +
> + platform_set_drvdata(pdev, cci_df);
> +
> + cci_df->devfreq = devm_devfreq_add_device(cci_dev,
> +_devfreq_profile,
> +"mtk_cci_vmon",
> +NULL);
> + if (IS_ERR(cci_df->devfreq)) {
> + dev_err(cci_dev, "cannot create cci devfreq device\n", ret);
> + goto err_put_reg;
> + }
> +
> + return 0;
> +
> +err_put_reg:
> + regulator_put(cci_df->proc_reg);
> +err_put_clk:
> + clk_put(cci_df->cci_clk);
If you use devm_clk_get()/devm_regulator_get(),
'err_put_reg' and 'err_put_clk' are unneeded.
> +
> + 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;
> +
> + 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;
> +
> + ret = devfreq_remove_governor(_cci_devfreq_governor);
> + if (ret)
> + pr_err("%s: failed to remove governor: %d\n", __func__, ret);
> +
> + platform_driver_unregister(_devfreq_driver);
> +}
> +module_exit(mtk_cci_devfreq_exit)
> +
> +MODULE_DESCRIPTION("Mediatek CCI devfreq driver");
> +MODULE_AUTHOR("Andrew-sh.Cheng ");
> +MODULE_LICENSE("GPL v2");
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
