Re: [PATCH V3 02/20] OPP: Make dev_pm_opp_set_regulators() accept NULL terminated list
On 22. 7. 4. 21:07, Viresh Kumar wrote:
> Make dev_pm_opp_set_regulators() accept a NULL terminated list of names
> instead of making the callers keep the two parameters in sync, which
> creates an opportunity for bugs to get in.
>
> Suggested-by: Greg Kroah-Hartman
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq-dt.c| 9 -
> drivers/cpufreq/ti-cpufreq.c| 7 +++
> drivers/devfreq/exynos-bus.c| 4 ++--
> drivers/gpu/drm/lima/lima_devfreq.c | 3 ++-
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 4 ++--
> drivers/opp/core.c | 18 --
> drivers/soc/tegra/pmc.c | 4 ++--
> include/linux/pm_opp.h | 9 -
> 8 files changed, 31 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> index 8fcaba541539..be0c19b3ffa5 100644
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -193,7 +193,7 @@ static int dt_cpufreq_early_init(struct device *dev, int
> cpu)
> struct private_data *priv;
> struct device *cpu_dev;
> bool fallback = false;
> - const char *reg_name;
> + const char *reg_name[] = { NULL, NULL };
> int ret;
>
> /* Check if this CPU is already covered by some other policy */
> @@ -218,10 +218,9 @@ static int dt_cpufreq_early_init(struct device *dev, int
> cpu)
>* OPP layer will be taking care of regulators now, but it needs to know
>* the name of the regulator first.
>*/
> - reg_name = find_supply_name(cpu_dev);
> - if (reg_name) {
> - priv->opp_table = dev_pm_opp_set_regulators(cpu_dev, _name,
> - 1);
> + reg_name[0] = find_supply_name(cpu_dev);
> + if (reg_name[0]) {
> + priv->opp_table = dev_pm_opp_set_regulators(cpu_dev, reg_name);
> if (IS_ERR(priv->opp_table)) {
> ret = PTR_ERR(priv->opp_table);
> if (ret != -EPROBE_DEFER)
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index 8f9fdd864391..560d67a6bef1 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -173,7 +173,7 @@ static struct ti_cpufreq_soc_data omap34xx_soc_data = {
> *seems to always read as 0).
> */
>
> -static const char * const omap3_reg_names[] = {"cpu0", "vbb"};
> +static const char * const omap3_reg_names[] = {"cpu0", "vbb", NULL};
>
> static struct ti_cpufreq_soc_data omap36xx_soc_data = {
> .reg_names = omap3_reg_names,
> @@ -326,7 +326,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
> const struct of_device_id *match;
> struct opp_table *ti_opp_table;
> struct ti_cpufreq_data *opp_data;
> - const char * const default_reg_names[] = {"vdd", "vbb"};
> + const char * const default_reg_names[] = {"vdd", "vbb", NULL};
> int ret;
>
> match = dev_get_platdata(>dev);
> @@ -387,8 +387,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
> if (opp_data->soc_data->reg_names)
> reg_names = opp_data->soc_data->reg_names;
> ti_opp_table = dev_pm_opp_set_regulators(opp_data->cpu_dev,
> - reg_names,
> -
> ARRAY_SIZE(default_reg_names));
> + reg_names);
> if (IS_ERR(ti_opp_table)) {
> dev_pm_opp_put_supported_hw(opp_data->opp_table);
> ret = PTR_ERR(ti_opp_table);
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index e689101abc93..541baff93ee8 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -180,10 +180,10 @@ static int exynos_bus_parent_parse_of(struct
> device_node *np,
> {
> struct device *dev = bus->dev;
> struct opp_table *opp_table;
> - const char *vdd = "vdd";
> + const char *supplies[] = { "vdd", NULL };
> int i, ret, count, size;
>
> - opp_table = dev_pm_opp_set_regulators(dev, , 1);
> + opp_table = dev_pm_opp_set_regulators(dev, supplies);
> if (IS_ERR(opp_table)) {
> ret = PTR_ERR(opp_table);
> dev_err(dev, "failed to set regulators %d\n", ret);
Reviewed-by: Chanwoo Choi
(snip)
--
Best Regards,
Samsung Electronics
Chanwoo Choi
Re: [PATCH 6/6] i2c: Make remove callback return void
Hi Uwe,
On 22. 6. 28. 23:03, Uwe Kleine-König wrote:
> static const struct of_device_id atmel_sha204a_dt_ids[] = {
> diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
> index 40c07f4d656e..d1c674f3f2b9 100644
> --- a/drivers/extcon/extcon-rt8973a.c
> +++ b/drivers/extcon/extcon-rt8973a.c
> @@ -647,13 +647,11 @@ static int rt8973a_muic_i2c_probe(struct i2c_client
> *i2c,
> return 0;
> }
>
> -static int rt8973a_muic_i2c_remove(struct i2c_client *i2c)
> +static void rt8973a_muic_i2c_remove(struct i2c_client *i2c)
> {
> struct rt8973a_muic_info *info = i2c_get_clientdata(i2c);
>
> regmap_del_irq_chip(info->irq, info->irq_data);
> -
> - return 0;
> }
>
> static const struct of_device_id rt8973a_dt_match[] = {
> diff --git a/drivers/gpio/gpio-adp5588.c b/drivers/gpio/gpio-adp5588.c
> index e388e75103f4..acb673dc9005 100644
> --- a/drivers/gpio/gpio-adp5588.c
> +++ b/drivers/gpio/gpio-adp5588.c
> @@ -411,14 +411,12 @@ static int adp5588_gpio_probe(struct i2c_client *client)
> return 0;
> }
Reviewed-by: Chanwoo Choi
--
Best Regards,
Samsung Electronics
Chanwoo Choi
Re: [PATCH] devfreq: Register devfreq as a cooling device
Hi Daniel,
As Lukasz's comment, actually some devfreq devices like memory bus
might not affect the thermal critically. In the mainline,
there are four types devfreq as following:
1. GPU
2. UFS Storage
3. DMC (Memory Controller)
4. Memory bus like AMBA AXI
I think that you can specify this devfreq device will be used
for cooling device by editing the devfreq_dev_profile structure.
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index bf3047896e41..77966a17d03f 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -935,6 +935,13 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(_list_lock);
+ if (devfreq->profile->is_cooling_device) {
+ devfreq->cdev = devfreq_cooling_em_register(devfreq, NULL);
+ if (IS_ERR(devfreq->cdev))
+ dev_info(dev,
+ "Failed to register devfreq cooling
device\n");
+ }
+
return devfreq;
err_init:
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 26ea0850be9b..26dc69f1047b 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -103,6 +103,7 @@ struct devfreq_dev_profile {
unsigned long initial_freq;
unsigned int polling_ms;
enum devfreq_timer timer;
+ bool is_cooling_device;
int (*target)(struct device *dev, unsigned long *freq, u32 flags);
int (*get_dev_status)(struct device *dev,
Thanks
Chanwoo Choi
On 21. 3. 4. 오후 9:50, Daniel Lezcano wrote:
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.
There are no so many and actually it makes more sense to register the
devfreq device when adding it.
Consequently, every devfreq becomes a cooling device like cpufreq is.
Having a devfreq being registered as a cooling device can not mitigate
a thermal zone if it is not bound to this one. Thus, the current
configurations are not impacted by this change.
Signed-off-by: Daniel Lezcano
---
drivers/devfreq/devfreq.c | 8
drivers/gpu/drm/lima/lima_devfreq.c | 13 -
drivers/gpu/drm/lima/lima_devfreq.h | 2 --
drivers/gpu/drm/msm/msm_gpu.c | 11 ---
drivers/gpu/drm/msm/msm_gpu.h | 2 --
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
include/linux/devfreq.h | 3 +++
7 files changed, 11 insertions(+), 41 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index b6d63f02d293..19149b31b000 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -26,6 +27,7 @@
#include
#include
#include
+#include
#include
#include "governor.h"
@@ -935,6 +937,10 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(_list_lock);
+ devfreq->cdev = devfreq_cooling_em_register(devfreq, NULL);
+ if (IS_ERR(devfreq->cdev))
+ dev_info(dev, "Failed to register devfreq cooling device\n");
+
return devfreq;
err_init:
@@ -960,6 +966,8 @@ int devfreq_remove_device(struct devfreq *devfreq)
if (!devfreq)
return -EINVAL;
+ thermal_cooling_device_unregister(devfreq->cdev);
+
if (devfreq->governor) {
devfreq->governor->event_handler(devfreq,
DEVFREQ_GOV_STOP, NULL);
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..a696eff1642c 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -7,7 +7,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -90,11 +89,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
{
struct lima_devfreq *devfreq = >devfreq;
- if (devfreq->cooling) {
- devfreq_cooling_unregister(devfreq->cooling);
- devfreq->cooling = NULL;
- }
-
if (devfreq->devfreq) {
devm_devfreq_remove_device(ldev->dev, devfreq->devfreq);
devfreq->devfreq = NULL;
@@ -110,7 +104,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
int lima_devfreq_init(struct lima_device *ldev)
{
- struct thermal_cooling_device *cooling;
struct device *dev = ldev->dev;
struct opp_table *opp_table;
struct devfreq *devfreq;
@@ -173,12 +166,6 @@ int lima_devfreq_init(struct lima_device *ldev)
ldevfreq->devfreq = devfreq;
- cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
- if (IS_ERR(cooling))
- dev_info(dev, "Failed to register cooling device\n");
- else
-
Re: [PATCH] dt-bindings: Add missing array size constraints
Hi Rob, On Tue, Jan 5, 2021 at 8:03 AM Rob Herring wrote: > > DT properties which can have multiple entries need to specify what the > entries are and define how many entries there can be. In the case of > only a single entry, just 'maxItems: 1' is sufficient. > > Add the missing entry constraints. These were found with a modified > meta-schema. Unfortunately, there are a few cases where the size > constraints are not defined such as common bindings, so the meta-schema > can't be part of the normal checks. > > Cc: Jens Axboe > Cc: Stephen Boyd > Cc: Thierry Reding > Cc: MyungJoo Ham > Cc: Chanwoo Choi > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: Jonathan Cameron > Cc: Dmitry Torokhov > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Mauro Carvalho Chehab > Cc: Chen-Yu Tsai > Cc: Ulf Hansson > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Sebastian Reichel > Cc: Ohad Ben-Cohen > Cc: Bjorn Andersson > Cc: Greg Kroah-Hartman > Signed-off-by: Rob Herring > --- > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-g...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-in...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-ser...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > --- > .../socionext,uniphier-system-cache.yaml | 4 ++-- > .../bindings/ata/sata_highbank.yaml | 1 + > .../bindings/clock/canaan,k210-clk.yaml | 1 + > .../bindings/display/brcm,bcm2711-hdmi.yaml | 1 + > .../bindings/display/brcm,bcm2835-hdmi.yaml | 1 + > .../display/panel/jdi,lt070me05000.yaml | 1 + > .../display/panel/mantix,mlaf057we51-x.yaml | 3 ++- > .../display/panel/novatek,nt36672a.yaml | 1 + > .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 +- > .../devicetree/bindings/eeprom/at25.yaml | 3 +-- > .../bindings/extcon/extcon-ptn5150.yaml | 2 ++ For extcon part, Acked-by: Chanwoo Choi (snip) Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/31] PM / devfreq: imx8m-ddrc: convert to use devm_pm_opp_* API
Hi Yangtao,
On Tue, Jan 5, 2021 at 1:13 PM Chanwoo Choi wrote:
>
> On Sun, Jan 3, 2021 at 12:58 PM Yangtao Li wrote:
> >
> > Use devm_pm_opp_* API to simplify code.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > drivers/devfreq/imx8m-ddrc.c | 15 ++-
> > 1 file changed, 2 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/devfreq/imx8m-ddrc.c b/drivers/devfreq/imx8m-ddrc.c
> > index bc82d3653bff..9383d6e5538b 100644
> > --- a/drivers/devfreq/imx8m-ddrc.c
> > +++ b/drivers/devfreq/imx8m-ddrc.c
> > @@ -370,11 +370,6 @@ static int imx8m_ddrc_check_opps(struct device *dev)
> > return 0;
> > }
> >
> > -static void imx8m_ddrc_exit(struct device *dev)
> > -{
> > - dev_pm_opp_of_remove_table(dev);
> > -}
> > -
> > static int imx8m_ddrc_probe(struct platform_device *pdev)
> > {
> > struct device *dev = >dev;
> > @@ -419,7 +414,7 @@ static int imx8m_ddrc_probe(struct platform_device
> > *pdev)
> > return ret;
> > }
> >
> > - ret = dev_pm_opp_of_add_table(dev);
> > + ret = devm_pm_opp_of_add_table(dev);
> > if (ret < 0) {
> > dev_err(dev, "failed to get OPP table\n");
> > return ret;
> > @@ -427,12 +422,11 @@ static int imx8m_ddrc_probe(struct platform_device
> > *pdev)
> >
> > ret = imx8m_ddrc_check_opps(dev);
> > if (ret < 0)
> > - goto err;
> > + return ret;
> >
> > priv->profile.polling_ms = 1000;
> > priv->profile.target = imx8m_ddrc_target;
> > priv->profile.get_dev_status = imx8m_ddrc_get_dev_status;
> > - priv->profile.exit = imx8m_ddrc_exit;
> > priv->profile.get_cur_freq = imx8m_ddrc_get_cur_freq;
> > priv->profile.initial_freq = clk_get_rate(priv->dram_core);
> >
> > @@ -441,13 +435,8 @@ static int imx8m_ddrc_probe(struct platform_device
> > *pdev)
> > if (IS_ERR(priv->devfreq)) {
> > ret = PTR_ERR(priv->devfreq);
> > dev_err(dev, "failed to add devfreq device: %d\n", ret);
> > - goto err;
> > }
> >
> > - return 0;
> > -
> > -err:
> > - dev_pm_opp_of_remove_table(dev);
> > return ret;
>
> devm_devfreq_add_device() doesn't return any integer value.
> Even if devm_devfreq_add_device() returns the right devfreq instance,
> the 'ret' value is not the return value of devm_devfreq_add_device().
>
> On this patch, 'ret' value of 'return ret' is from imx8m_ddrc_check_opps().
> Surely, it is well working with this modification. But, it is not code
> for exception handling.
> So, we need to remain the following codes:
>
> return 0;
> err:
> return ret;
>
'err' is not necessary. You better to edit it as following:
if (IS_ERR(priv->devfreq)) {
dev_err(dev, "failed to add devfreq device: %d\n", ret);
return PTR_ERR(priv->devfreq);
}
return 0;
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 31/31] PM / devfreq: convert to devm_pm_opp_register_notifier and remove unused API
On Sun, Jan 3, 2021 at 12:59 PM Yangtao Li wrote:
>
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/devfreq.c | 66 +--
> include/linux/devfreq.h | 23 --
> 2 files changed, 1 insertion(+), 88 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 6aa10de792b3..f593f30529ec 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -2004,40 +2004,6 @@ struct dev_pm_opp *devfreq_recommended_opp(struct
> device *dev,
> }
> EXPORT_SYMBOL(devfreq_recommended_opp);
>
> -/**
> - * devfreq_register_opp_notifier() - Helper function to get devfreq notified
> - * for any changes in the OPP availability
> - * changes
> - * @dev: The devfreq user device. (parent of devfreq)
> - * @devfreq: The devfreq object.
> - */
> -int devfreq_register_opp_notifier(struct device *dev, struct devfreq
> *devfreq)
> -{
> - return dev_pm_opp_register_notifier(dev, >nb);
> -}
> -EXPORT_SYMBOL(devfreq_register_opp_notifier);
> -
> -/**
> - * devfreq_unregister_opp_notifier() - Helper function to stop getting
> devfreq
> - *notified for any changes in the OPP
> - *availability changes anymore.
> - * @dev: The devfreq user device. (parent of devfreq)
> - * @devfreq: The devfreq object.
> - *
> - * At exit() callback of devfreq_dev_profile, this must be included if
> - * devfreq_recommended_opp is used.
> - */
> -int devfreq_unregister_opp_notifier(struct device *dev, struct devfreq
> *devfreq)
> -{
> - return dev_pm_opp_unregister_notifier(dev, >nb);
> -}
> -EXPORT_SYMBOL(devfreq_unregister_opp_notifier);
> -
> -static void devm_devfreq_opp_release(struct device *dev, void *res)
> -{
> - devfreq_unregister_opp_notifier(dev, *(struct devfreq **)res);
> -}
> -
> /**
> * devm_devfreq_register_opp_notifier() - Resource-managed
> * devfreq_register_opp_notifier()
> @@ -2047,40 +2013,10 @@ static void devm_devfreq_opp_release(struct device
> *dev, void *res)
> int devm_devfreq_register_opp_notifier(struct device *dev,
>struct devfreq *devfreq)
> {
> - struct devfreq **ptr;
> - int ret;
> -
> - ptr = devres_alloc(devm_devfreq_opp_release, sizeof(*ptr),
> GFP_KERNEL);
> - if (!ptr)
> - return -ENOMEM;
> -
> - ret = devfreq_register_opp_notifier(dev, devfreq);
> - if (ret) {
> - devres_free(ptr);
> - return ret;
> - }
> -
> - *ptr = devfreq;
> - devres_add(dev, ptr);
> -
> - return 0;
> + return devm_pm_opp_register_notifier(dev, >nb);
> }
> EXPORT_SYMBOL(devm_devfreq_register_opp_notifier);
>
> -/**
> - * devm_devfreq_unregister_opp_notifier() - Resource-managed
> - * devfreq_unregister_opp_notifier()
> - * @dev: The devfreq user device. (parent of devfreq)
> - * @devfreq: The devfreq object.
> - */
> -void devm_devfreq_unregister_opp_notifier(struct device *dev,
> -struct devfreq *devfreq)
> -{
> - WARN_ON(devres_release(dev, devm_devfreq_opp_release,
> - devm_devfreq_dev_match, devfreq));
> -}
> -EXPORT_SYMBOL(devm_devfreq_unregister_opp_notifier);
Need to support devm_devfreq_unregister_opp_notifier()
because sometimes, the user wants to release the resource by himself.
(snip)
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 30/31] PM / devfreq: exynos: convert to use devm_pm_opp_* API
q(opp); > dev_pm_opp_put(opp); > > return 0; > > -err_opp: > - dev_pm_opp_of_remove_table(dev); > err_clk: > clk_disable_unprepare(bus->clk); > > @@ -425,7 +405,7 @@ static int exynos_bus_probe(struct platform_device *pdev) > /* Parse the device-tree to get the resource information */ > ret = exynos_bus_parse_of(np, bus); > if (ret < 0) > - goto err_reg; > + return ret; > > if (passive) > ret = exynos_bus_profile_init_passive(bus, profile); > @@ -456,11 +436,7 @@ static int exynos_bus_probe(struct platform_device *pdev) > return 0; > > err: > - dev_pm_opp_of_remove_table(dev); > clk_disable_unprepare(bus->clk); > -err_reg: > - dev_pm_opp_put_regulators(bus->opp_table); > - bus->opp_table = NULL; > > return ret; > } > -- > 2.25.1 > -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/31] PM / devfreq: imx-bus: convert to use devm_pm_opp_* API
On Sun, Jan 3, 2021 at 12:58 PM Yangtao Li wrote:
>
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/imx-bus.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/devfreq/imx-bus.c b/drivers/devfreq/imx-bus.c
> index 4f38455ad742..ff26ef049b1b 100644
> --- a/drivers/devfreq/imx-bus.c
> +++ b/drivers/devfreq/imx-bus.c
> @@ -61,7 +61,6 @@ static void imx_bus_exit(struct device *dev)
> {
> struct imx_bus *priv = dev_get_drvdata(dev);
>
> - dev_pm_opp_of_remove_table(dev);
> platform_device_unregister(priv->icc_pdev);
> }
>
> @@ -123,7 +122,7 @@ static int imx_bus_probe(struct platform_device *pdev)
> }
> platform_set_drvdata(pdev, priv);
>
> - ret = dev_pm_opp_of_add_table(dev);
> + ret = devm_pm_opp_of_add_table(dev);
> if (ret < 0) {
> dev_err(dev, "failed to get OPP table\n");
> return ret;
> @@ -141,18 +140,11 @@ static int imx_bus_probe(struct platform_device *pdev)
> if (IS_ERR(priv->devfreq)) {
> ret = PTR_ERR(priv->devfreq);
> dev_err(dev, "failed to add devfreq device: %d\n", ret);
> - goto err;
> + return ret;
> }
>
> - ret = imx_bus_init_icc(dev);
> - if (ret)
> - goto err;
> -
> - return 0;
> + return imx_bus_init_icc(dev);
Remove the unneeded blank line under '.return imx_bus_init_icc(dev);".
> -err:
> - dev_pm_opp_of_remove_table(dev);
> - return ret;
> }
>
> static const struct of_device_id imx_bus_of_match[] = {
> --
> 2.25.1
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/31] PM / devfreq: imx8m-ddrc: convert to use devm_pm_opp_* API
On Sun, Jan 3, 2021 at 12:58 PM Yangtao Li wrote:
>
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/imx8m-ddrc.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/devfreq/imx8m-ddrc.c b/drivers/devfreq/imx8m-ddrc.c
> index bc82d3653bff..9383d6e5538b 100644
> --- a/drivers/devfreq/imx8m-ddrc.c
> +++ b/drivers/devfreq/imx8m-ddrc.c
> @@ -370,11 +370,6 @@ static int imx8m_ddrc_check_opps(struct device *dev)
> return 0;
> }
>
> -static void imx8m_ddrc_exit(struct device *dev)
> -{
> - dev_pm_opp_of_remove_table(dev);
> -}
> -
> static int imx8m_ddrc_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -419,7 +414,7 @@ static int imx8m_ddrc_probe(struct platform_device *pdev)
> return ret;
> }
>
> - ret = dev_pm_opp_of_add_table(dev);
> + ret = devm_pm_opp_of_add_table(dev);
> if (ret < 0) {
> dev_err(dev, "failed to get OPP table\n");
> return ret;
> @@ -427,12 +422,11 @@ static int imx8m_ddrc_probe(struct platform_device
> *pdev)
>
> ret = imx8m_ddrc_check_opps(dev);
> if (ret < 0)
> - goto err;
> + return ret;
>
> priv->profile.polling_ms = 1000;
> priv->profile.target = imx8m_ddrc_target;
> priv->profile.get_dev_status = imx8m_ddrc_get_dev_status;
> - priv->profile.exit = imx8m_ddrc_exit;
> priv->profile.get_cur_freq = imx8m_ddrc_get_cur_freq;
> priv->profile.initial_freq = clk_get_rate(priv->dram_core);
>
> @@ -441,13 +435,8 @@ static int imx8m_ddrc_probe(struct platform_device *pdev)
> if (IS_ERR(priv->devfreq)) {
> ret = PTR_ERR(priv->devfreq);
> dev_err(dev, "failed to add devfreq device: %d\n", ret);
> - goto err;
> }
>
> - return 0;
> -
> -err:
> - dev_pm_opp_of_remove_table(dev);
> return ret;
devm_devfreq_add_device() doesn't return any integer value.
Even if devm_devfreq_add_device() returns the right devfreq instance,
the 'ret' value is not the return value of devm_devfreq_add_device().
On this patch, 'ret' value of 'return ret' is from imx8m_ddrc_check_opps().
Surely, it is well working with this modification. But, it is not code
for exception handling.
So, we need to remain the following codes:
return 0;
err:
return ret;
> }
>
> --
> 2.25.1
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/31] PM / devfreq: rk3399_dmc: convert to use devm_pm_opp_* API
Hi,
Do you make this patch on latest source?
When I apply this patch for test, it make the merge conflict error.
On Sun, Jan 3, 2021 at 12:57 PM Yangtao Li wrote:
>
> Use devm_pm_opp_* API to simplify code. Since devres release
> can guarantee the order, let's remove
> devm_devfreq_unregister_opp_notifier().
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/rk3399_dmc.c | 22 +++---
> 1 file changed, 3 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> index 2e912166a993..9b8ab8be29d1 100644
> --- a/drivers/devfreq/rk3399_dmc.c
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -432,7 +432,7 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> * We add a devfreq driver to our parent since it has a device tree
> node
> * with operating points.
> */
> - if (dev_pm_opp_of_add_table(dev)) {
> + if (devm_pm_opp_of_add_table(dev)) {
> dev_err(dev, "Invalid operating-points in device tree.\n");
> ret = -EINVAL;
> goto err_edev;
> @@ -448,7 +448,7 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> opp = devfreq_recommended_opp(dev, >rate, 0);
> if (IS_ERR(opp)) {
> ret = PTR_ERR(opp);
> - goto err_free_opp;
> + goto err_edev;
> }
>
> data->rate = dev_pm_opp_get_freq(opp);
> @@ -463,7 +463,7 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
>>ondemand_data);
> if (IS_ERR(data->devfreq)) {
> ret = PTR_ERR(data->devfreq);
> - goto err_free_opp;
> + goto err_edev;
> }
>
> devm_devfreq_register_opp_notifier(dev, data->devfreq);
> @@ -473,27 +473,12 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
>
> return 0;
>
> -err_free_opp:
> - dev_pm_opp_of_remove_table(>dev);
> err_edev:
> devfreq_event_disable_edev(data->edev);
>
> return ret;
> }
>
> -static int rk3399_dmcfreq_remove(struct platform_device *pdev)
> -{
> - struct rk3399_dmcfreq *dmcfreq = dev_get_drvdata(>dev);
> -
> - /*
> -* Before remove the opp table we need to unregister the opp notifier.
> -*/
> - devm_devfreq_unregister_opp_notifier(dmcfreq->dev, dmcfreq->devfreq);
> - dev_pm_opp_of_remove_table(dmcfreq->dev);
As the comment, we need to unregister the opp notifier before removing the OPP.
Do you guarantee this sequence on your patch?
> -
> - return 0;
> -}
> -
> static const struct of_device_id rk3399dmc_devfreq_of_match[] = {
> { .compatible = "rockchip,rk3399-dmc" },
> { },
> @@ -502,7 +487,6 @@ MODULE_DEVICE_TABLE(of, rk3399dmc_devfreq_of_match);
>
> static struct platform_driver rk3399_dmcfreq_driver = {
> .probe = rk3399_dmcfreq_probe,
> - .remove = rk3399_dmcfreq_remove,
> .driver = {
> .name = "rk3399-dmc-freq",
> .pm = _dmcfreq_pm,
> --
> 2.25.1
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 26/31] PM / devfreq: tegra30: convert to use devm_pm_opp_* API
Hi,
On Sun, Jan 3, 2021 at 12:57 PM Yangtao Li wrote:
>
> Use devm_pm_opp_* API to simplify code, and remove opp_table
> from tegra_devfreq.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/tegra30-devfreq.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 117cad7968ab..4984cb91e9ea 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -178,7 +178,6 @@ struct tegra_devfreq_soc_data {
>
> struct tegra_devfreq {
> struct devfreq *devfreq;
> - struct opp_table*opp_table;
>
> struct reset_control*reset;
> struct clk *clock;
> @@ -794,6 +793,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> struct tegra_devfreq_device *dev;
> struct tegra_devfreq *tegra;
> struct devfreq *devfreq;
> + struct opp_tabl *opp_table;
opp_tabl -> opp_table. It will make the build error. Please do build
test at least.
> unsigned int i;
> long rate;
> int err;
> @@ -841,25 +841,25 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> - tegra->opp_table = dev_pm_opp_set_supported_hw(>dev,
> - _version, 1);
> - err = PTR_ERR_OR_ZERO(tegra->opp_table);
> + opp_table = devm_pm_opp_set_supported_hw(>dev,
> +_version, 1);
> + err = PTR_ERR_OR_ZERO(opp_table);
> if (err) {
> dev_err(>dev, "Failed to set supported HW: %d\n", err);
> return err;
> }
>
> - err = dev_pm_opp_of_add_table(>dev);
> + err = devm_pm_opp_of_add_table(>dev);
> if (err) {
> dev_err(>dev, "Failed to add OPP table: %d\n", err);
> - goto put_hw;
> + return err;
> }
>
> err = clk_prepare_enable(tegra->clock);
> if (err) {
> dev_err(>dev,
> "Failed to prepare and enable ACTMON clock\n");
> - goto remove_table;
> + return err;
> }
>
> err = reset_control_reset(tegra->reset);
> @@ -917,10 +917,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> reset_control_reset(tegra->reset);
> disable_clk:
> clk_disable_unprepare(tegra->clock);
> -remove_table:
> - dev_pm_opp_of_remove_table(>dev);
> -put_hw:
> - dev_pm_opp_put_supported_hw(tegra->opp_table);
You might remove the 'devm_pm_opp_remove_all_dynamic(>dev)
under ' remove_opp' goto statement.
(snip)
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 10/10] PM / devfreq: tegra30: Separate configurations per-SoC generation
On 12/4/20 4:24 AM, Dmitry Osipenko wrote:
> Previously we were using count-weight of the T124 for T30 in order to
> get EMC clock rate that was reasonable for T30. In fact the count-weight
> should be x2 times smaller on T30, but then devfreq was producing a bit
> too low EMC clock rate for ISO memory clients, like display controller
> for example.
>
> Now both Tegra ACTMON and Tegra DRM display drivers support interconnect
> framework and display driver tells to ICC what a minimum memory bandwidth
> is needed, preventing FIFO underflows. Thus, now we can use a proper
> count-weight value for Tegra30 and MC_ALL device config needs a bit more
> aggressive boosting.
>
> Add a separate ACTMON driver configuration that is specific to Tegra30.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Acked-by: Chanwoo Choi
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 68 ---
> 1 file changed, 54 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 145ef91ae092..117cad7968ab 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -57,13 +57,6 @@
> #define ACTMON_BELOW_WMARK_WINDOW3
> #define ACTMON_BOOST_FREQ_STEP 16000
>
> -/*
> - * Activity counter is incremented every 256 memory transactions, and each
> - * transaction takes 4 EMC clocks for Tegra124; So the COUNT_WEIGHT is
> - * 4 * 256 = 1024.
> - */
> -#define ACTMON_COUNT_WEIGHT 0x400
> -
> /*
> * ACTMON_AVERAGE_WINDOW_LOG2: default value for @DEV_CTRL_K_VAL, which
> * translates to 2 ^ (K_VAL + 1). ex: 2 ^ (6 + 1) = 128
> @@ -111,7 +104,7 @@ enum tegra_actmon_device {
> MCCPU,
> };
>
> -static const struct tegra_devfreq_device_config actmon_device_configs[] = {
> +static const struct tegra_devfreq_device_config tegra124_device_configs[] = {
> {
> /* MCALL: All memory accesses (including from the CPUs) */
> .offset = 0x1c0,
> @@ -133,6 +126,28 @@ static const struct tegra_devfreq_device_config
> actmon_device_configs[] = {
> },
> };
>
> +static const struct tegra_devfreq_device_config tegra30_device_configs[] = {
> + {
> + /* MCALL: All memory accesses (including from the CPUs) */
> + .offset = 0x1c0,
> + .irq_mask = 1 << 26,
> + .boost_up_coeff = 200,
> + .boost_down_coeff = 50,
> + .boost_up_threshold = 20,
> + .boost_down_threshold = 10,
> + },
> + {
> + /* MCCPU: memory accesses from the CPUs */
> + .offset = 0x200,
> + .irq_mask = 1 << 25,
> + .boost_up_coeff = 800,
> + .boost_down_coeff = 40,
> + .boost_up_threshold = 27,
> + .boost_down_threshold = 10,
> + .avg_dependency_threshold = 16000, /* 16MHz in kHz units */
> + },
> +};
> +
> /**
> * struct tegra_devfreq_device - state specific to an ACTMON device
> *
> @@ -155,6 +170,12 @@ struct tegra_devfreq_device {
> unsigned long target_freq;
> };
>
> +struct tegra_devfreq_soc_data {
> + const struct tegra_devfreq_device_config *configs;
> + /* Weight value for count measurements */
> + unsigned int count_weight;
> +};
> +
> struct tegra_devfreq {
> struct devfreq *devfreq;
> struct opp_table*opp_table;
> @@ -171,11 +192,13 @@ struct tegra_devfreq {
> struct delayed_work cpufreq_update_work;
> struct notifier_block cpu_rate_change_nb;
>
> - struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
> + struct tegra_devfreq_device devices[2];
>
> unsigned intirq;
>
> boolstarted;
> +
> + const struct tegra_devfreq_soc_data *soc;
> };
>
> struct tegra_actmon_emc_ratio {
> @@ -488,7 +511,7 @@ static void tegra_actmon_configure_device(struct
> tegra_devfreq *tegra,
> tegra_devfreq_update_avg_wmark(tegra, dev);
> tegra_devfreq_update_wmark(tegra, dev);
>
> - device_writel(dev, ACTMON_COUNT_WEIGHT, ACTMON_DEV_COUNT_WEIGHT);
> + device_writel(dev, tegra->soc->count_weight, ACTMON_DEV_COUNT_WEIGHT);
> device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
>
> val |= ACTMON_DEV_CTRL_ENB_PERIODIC;
> @@ -779,6 +802,8 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> if (!tegra)
Re: [PATCH v11 09/10] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
On 12/4/20 4:24 AM, Dmitry Osipenko wrote:
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees and brings support
> for the interconnect framework to the driver. This is a mandatory change
> which needs to be done in order to implement interconnect-based memory
> DVFS, i.e. device-trees need to be updated. Now ACTMON issues a memory
> bandwidth requests using dev_pm_opp_set_bw() instead of driving EMC clock
> rate directly.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Acked-by: Chanwoo Choi
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 79 +++
> 1 file changed, 37 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 38cc0d014738..145ef91ae092 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -19,6 +19,8 @@
> #include
> #include
>
> +#include
> +
> #include "governor.h"
>
> #define ACTMON_GLB_STATUS0x0
> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
>
> struct tegra_devfreq {
> struct devfreq *devfreq;
> + struct opp_table*opp_table;
>
> struct reset_control*reset;
> struct clk *clock;
> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> *tegra)
> 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;
> + int ret;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> return PTR_ERR(opp);
> }
> - rate = dev_pm_opp_get_freq(opp);
> - dev_pm_opp_put(opp);
> -
> - err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
> - 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);
> + ret = dev_pm_opp_set_bw(dev, opp);
> + dev_pm_opp_put(opp);
>
> - return err;
> + return ret;
> }
>
> static int tegra_devfreq_get_dev_status(struct device *dev,
> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
> *dev,
> stat->private_data = tegra;
>
> /* The below are to be used by the other governors */
> - stat->current_frequency = cur_freq;
> + stat->current_frequency = cur_freq * KHZ;
>
> actmon_dev = >devices[MCALL];
>
> @@ -705,7 +693,12 @@ static int tegra_governor_get_target(struct devfreq
> *devfreq,
> target_freq = max(target_freq, dev->target_freq);
> }
>
> - *freq = target_freq;
> + /*
> + * tegra-devfreq driver operates with KHz units, while OPP table
> + * entries use Hz units. Hence we need to convert the units for the
> + * devfreq core.
> + */
> + *freq = target_freq * KHZ;
>
> return 0;
> }
> @@ -774,6 +767,7 @@ static struct devfreq_governor tegra_devfreq_governor = {
>
> static int tegra_devfreq_probe(struct platform_device *pdev)
> {
> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> struct tegra_devfreq_device *dev;
> struct tegra_devfreq *tegra;
> struct devfreq *devfreq;
> @@ -822,11 +816,25 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + tegra->opp_table = dev_pm_opp_set_supported_hw(>dev,
> +_version, 1);
> + err = PTR_ERR_OR_ZERO(tegra->opp_table);
> + if (err) {
> + dev_err(>dev, "Failed to set supported HW: %d\n", err);
> + return err;
> + }
> +
> + err = dev_pm_opp_of_add_table(>dev);
> + if (err) {
> + dev_err(>dev, "Failed to add OPP table: %d\n", err);
> + goto put_hw;
> + }
> +
> err = clk_prepare_enable(tegra->clock);
> if (err) {
> dev_err
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
On 11/30/20 5:36 PM, Krzysztof Kozlowski wrote: > On Mon, Nov 30, 2020 at 05:44:39PM +0900, Chanwoo Choi wrote: >> Hi Dmitry, >> >> The v5.10-rc6 was released from linus git tree. >> Generally, I will send the pull-quest about devfreq to linux-pm.git >> maintainer >> after releasing the v5.1-rc7 for the integration test on linux-pm.git. >> >> The icc patches in this patch have not yet merged. If these patches >> are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches >> for v5.12-rc1. > > None of the patches here are going to be merged to Linus' in the current > cycle. They will only go to the next so if there is dependency, > everything will be broken and non-bisectable. > > However no such dependencies or merging requirements were mention in the > cover letter. Thanks for reply. The devfreq patch depends on the icc changes. I'll apply the devfreq patches on next time (v5.12-rc1). Thanks. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs
Hi Dmitry, The v5.10-rc6 was released from linus git tree. Generally, I will send the pull-quest about devfreq to linux-pm.git maintainer after releasing the v5.1-rc7 for the integration test on linux-pm.git. The icc patches in this patch have not yet merged. If these patches are not merged before v5.10-rc7, Maybe, I'll apply the devfreq patches for v5.12-rc1. Best Regards, Chanwoo Choi On 11/23/20 9:27 AM, Dmitry Osipenko wrote: > This series brings initial support for memory interconnect to Tegra20, > Tegra30 and Tegra124 SoCs. > > For the starter only display controllers and devfreq devices are getting > interconnect API support, others could be supported later on. The display > controllers have the biggest demand for interconnect API right now because > dynamic memory frequency scaling can't be done safely without taking into > account bandwidth requirement from the displays. In particular this series > fixes distorted display output on T30 Ouya and T124 TK1 devices. > > Changelog: > > v10 - In a longer run it will be much nicer if we could support EMC > hardware versioning on Tegra20 and it's not late to support it now. > Hence I added these new patches: > > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > > - Removed error message from tegra30-devfreq driver about missing OPP > properties in a device-tree because EMC driver already prints that > message and it uses OPP API error code instead of checking DT directly, > which is a more correct way of doing that. > > v9: - Squashed "memory: tegra30-emc: Factor out clk initialization" into > patch "tegra30: Support interconnect framework". > Suggested by Krzysztof Kozlowski. > > - Improved Kconfig in the patch "memory: tegra124-emc: Make driver > modular" > by adding CONFIG_TEGRA124_CLK_EMC entry, which makes clk-driver changes > to look a bit more cleaner. Suggested by Krzysztof Kozlowski. > > - Dropped voltage regulator support from ICC and DT patches for now > because there is a new discussion about using a power domain abstraction > for controlling the regulator, which is likely to happen. > > - Replaced direct "operating-points-v2" property checking in EMC drivers > with checking of a returned error code from dev_pm_opp_of_add_table(). > Note that I haven't touched T20 EMC driver because it's very likely > that we'll replace that code with a common helper soon anyways. > Suggested by Viresh Kumar. > > - The T30 DT patches now include EMC OPP changes for Ouya board, which > is available now in linux-next. > > Dmitry Osipenko (19): > dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > memory: tegra20: Support hardware versioning and clean up OPP table > initialization > memory: tegra30: Support interconnect framework > memory: tegra124-emc: Make driver modular > memory: tegra124-emc: Continue probing if timings are missing in > device-tree > memory: tegra124: Support interconnect framework > drm/tegra: dc: Support memory bandwidth management > drm/tegra: dc: Extend debug stats with total number of events > PM / devfreq: tegra30: Support interconnect and OPPs from device-tree > PM / devfreq: tegra30: Separate configurations per-SoC generation > PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver > ARM: tegra: Correct EMC registers size in Tegra20 device-tree > ARM: tegra: Add interconnect properties to Tegra20 device-tree > ARM: tegra: Add interconnect properties to Tegra30 device-tree > ARM: tegra: Add interconnect properties to Tegra124 device-tree > ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC > device-tree > ARM: tegra: Add EMC OPP properties to Tegra20 device-trees > ARM: tegra: Add EMC OPP and ICC properties to Tegra30 EMC and ACTMON > device-tree nodes > ARM: tegra: Add EMC OPP and ICC properties to Tegra124 EMC and ACTMON > device-tree nodes > > .../memory-controllers/nvidia,tegra20-emc.txt | 6 + > MAINTAINERS | 1 - > arch/arm/boot/dts/tegra124-apalis-emc.dtsi| 8 + > .../arm/boot/dts/tegra124-jetson-tk1-emc.dtsi | 8 + > arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi | 10 + > .../arm/boot/dts/tegra124-nyan-blaze-emc.dtsi | 10 + > .../boot/dts/tegra124-peripherals-opp.dtsi| 419 ++ > arch/arm/boot/dts/tegra124.dtsi | 31 ++ > .../boot/dts/tegra20-acer-a500-picasso.dts| 5 + > arch/arm/boot/dts/
Re: [PATCH v10 11/19] PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver
On 11/23/20 9:27 AM, Dmitry Osipenko wrote:
> Remove tegra20-devfreq in order to replace it with a EMC_STAT based
> devfreq driver. Previously we were going to use MC_STAT based
> tegra20-devfreq driver because EMC_STAT wasn't working properly, but
> now that problem is resolved. This resolves complications imposed by
> the removed driver since it was depending on both EMC and MC drivers
> simultaneously.
>
> Acked-by: Chanwoo Choi
> Signed-off-by: Dmitry Osipenko
> ---
> MAINTAINERS | 1 -
> drivers/devfreq/Kconfig | 10 --
> drivers/devfreq/Makefile | 1 -
> drivers/devfreq/tegra20-devfreq.c | 210 --
> 4 files changed, 222 deletions(-)
> delete mode 100644 drivers/devfreq/tegra20-devfreq.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5f10105cac6f..56c560320f00 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11370,7 +11370,6 @@ L:linux...@vger.kernel.org
> L: linux-te...@vger.kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git
> S: Maintained
> -F: drivers/devfreq/tegra20-devfreq.c
> F: drivers/devfreq/tegra30-devfreq.c
>
> MEMORY MANAGEMENT
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 0ee36ae2fa79..00704efe6398 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -121,16 +121,6 @@ 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 ARCH_TEGRA_2x_SOC || COMPILE_TEST
> - depends on COMMON_CLK
> - select DEVFREQ_GOV_SIMPLE_ONDEMAND
> - 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 && HAVE_ARM_SMCCC) || \
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 3ca1ad0ecb97..a16333ea7034 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -13,7 +13,6 @@ obj-$(CONFIG_ARM_IMX_BUS_DEVFREQ) += imx-bus.o
> obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.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
> deleted file mode 100644
> index fd801534771d..
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ /dev/null
> @@ -1,210 +0,0 @@
> -// 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 *emc_clock;
> - 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->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:
> -
Re: [PATCH v10 09/19] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry, On 11/23/20 9:27 AM, Dmitry Osipenko wrote: > This patch moves ACTMON driver away from generating OPP table by itself, > transitioning it to use the table which comes from device-tree. This > change breaks compatibility with older device-trees and brings support > for the interconnect framework to the driver. This is a mandatory change > which needs to be done in order to implement interconnect-based memory > DVFS, i.e. device-trees need to be updated. Now ACTMON issues a memory > bandwidth requests using dev_pm_opp_set_bw() instead of driving EMC clock > rate directly. > > Tested-by: Peter Geis > Tested-by: Nicolas Chauvet > Acked-by: Chanwoo Choi > Signed-off-by: Dmitry Osipenko > --- > drivers/devfreq/tegra30-devfreq.c | 79 +++ > 1 file changed, 37 insertions(+), 42 deletions(-) > (snip) When the patches related to icc are merged, I'll merge patch9/10. Thanks for your work. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] Exynos: Simple QoS for exynos-bus using interconnect
: Add entry for Samsung interconnect drivers > PM / devfreq: exynos-bus: Add registration of interconnect child > device > drm: exynos: mixer: Add interconnect support > > .../devicetree/bindings/devfreq/exynos-bus.txt | 71 +++- > MAINTAINERS| 8 + > drivers/devfreq/exynos-bus.c | 17 ++ > drivers/gpu/drm/exynos/exynos_mixer.c | 146 ++- > drivers/interconnect/Kconfig | 1 + > drivers/interconnect/Makefile | 1 + > drivers/interconnect/samsung/Kconfig | 13 ++ > drivers/interconnect/samsung/Makefile | 4 + > drivers/interconnect/samsung/exynos.c | 199 > +++++++++ > 9 files changed, 450 insertions(+), 10 deletions(-) > create mode 100644 drivers/interconnect/samsung/Kconfig > create mode 100644 drivers/interconnect/samsung/Makefile > create mode 100644 drivers/interconnect/samsung/exynos.c > I checked that the icc patches were merged to icc.git. So, I applied patch1 and patch4 to devfreq.git. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] Exynos: Simple QoS for exynos-bus using interconnect
On 11/13/20 5:48 PM, Georgi Djakov wrote: > On 11/12/20 16:09, Sylwester Nawrocki wrote: >> >> This patchset adds interconnect API support for the Exynos SoC "samsung, >> exynos-bus" compatible devices, which already have their corresponding >> exynos-bus driver in the devfreq subsystem. Complementing the devfreq >> driver with an interconnect functionality allows to ensure the QoS >> requirements of devices accessing the system memory (e.g. video processing >> devices) are fulfilled and allows to avoid issues like the one discussed >> in thread [1]. >> >> This patch series adds implementation of the interconnect provider per each >> "samsung,exynos-bus" compatible DT node, with one interconnect node per >> provider. The interconnect code which was previously added as a part of >> the devfreq driver has been converted to a separate platform driver. >> In the devfreq a corresponding virtual child platform device is registered. >> Integration of devfreq and interconnect frameworks is achieved through >> the PM QoS API. >> >> A sample interconnect consumer for exynos-mixer is added in patch 5/5, >> it is currently added only for exynos4412 and allows to address the >> mixer DMA underrun error issues [1]. > > Good work Sylwester! Thank you and all the reviewers! What would be the merge > path for this patchset? Looks like there is no build dependency between > patches. > Should i take just patches 2,3 or also patch 1? Chanwoo? Hi Georgi, If you take the patch 2,3, I'll apply patch 1,4 to devfreq.git. Hi Sylwester, First of all, thanks for your work to finish it for a long time. I'm very happy about finishing this work. It is very necessary feature for the QoS. Once again, thank for your work. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 04/26] memory: tegra20-emc: Add devfreq support
y working governor.
> + */
> + emc->ondemand_data.upthreshold = 20;
> +
> + /*
> + * Reset statistic gathers state, select global bandwidth for the
> + * statistics collection mode and set clocks counter saturation
> + * limit to maximum.
> + */
> + writel_relaxed(0x, emc->regs + EMC_STAT_CONTROL);
> + writel_relaxed(0x, emc->regs + EMC_STAT_LLMC_CONTROL);
> + writel_relaxed(0x, emc->regs + EMC_STAT_PWR_CLOCK_LIMIT);
> +
> + devfreq = devm_devfreq_add_device(emc->dev, _emc_devfreq_profile,
> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
> + >ondemand_data);
> + if (IS_ERR(devfreq)) {
> + dev_err(emc->dev, "failed to initialize devfreq: %pe", devfreq);
> + return PTR_ERR(devfreq);
> + }
> +
> + return 0;
> +}
> +
> static int tegra_emc_probe(struct platform_device *pdev)
> {
> struct device_node *np;
> @@ -1058,6 +1147,7 @@ static int tegra_emc_probe(struct platform_device *pdev)
> tegra_emc_rate_requests_init(emc);
> tegra_emc_debugfs_init(emc);
> tegra_emc_interconnect_init(emc);
> + tegra_emc_devfreq_init(emc);
>
> /*
>* Don't allow the kernel module to be unloaded. Unloading adds some
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 36/47] memory: tegra20-emc: Add devfreq support
eshold should be
> + * set to a less than 30 in order to have a properly working governor.
> + */
> + emc->ondemand_data.upthreshold = 20;
> +
> + /*
> + * Reset statistic gathers state, select global bandwidth for the
> + * statistics collection mode and set clocks counter saturation
> + * limit to maximum.
> + */
> + writel_relaxed(0x, emc->regs + EMC_STAT_CONTROL);
> + writel_relaxed(0x, emc->regs + EMC_STAT_LLMC_CONTROL);
> + writel_relaxed(0x, emc->regs + EMC_STAT_PWR_CLOCK_LIMIT);
> +
> + emc->devfreq = devfreq_add_device(emc->dev, _emc_devfreq_profile,
> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
> + >ondemand_data);
Do you want to use 'devfreq_add_device' instead of
'devm_devfreq_add_device()'? If you have to use 'devfreq_add_device'
due to some reason, you need to call 'devfreq_remove_device' on exit.
> + if (IS_ERR(emc->devfreq)) {
> + err = PTR_ERR(emc->devfreq);
> + dev_err(emc->dev, "failed to initialize devfreq: %d", err);
> + return err;
> + }
> +
> + return 0;
> +}
> +
> static int tegra_emc_probe(struct platform_device *pdev)
> {
> struct device_node *np;
> @@ -1019,6 +1110,7 @@ static int tegra_emc_probe(struct platform_device *pdev)
> tegra_emc_rate_requests_init(emc);
> tegra_emc_debugfs_init(emc);
> tegra_emc_interconnect_init(emc);
> + tegra_emc_devfreq_init(emc);
>
> /*
>* Don't allow the kernel module to be unloaded. Unloading adds some
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 47/47] PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver
Hi Dmitry,
You need to update the MAINTAINERS file about tegra20-devfreq.c
11343 MEMORY FREQUENCY SCALING DRIVERS FOR NVIDIA TEGRA
11344 M: Dmitry Osipenko
11345 L: linux...@vger.kernel.org
11346 L: linux-te...@vger.kernel.org
11347 T: git
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git
11348 S: Maintained
11349 F: drivers/devfreq/tegra20-devfreq.c
11350 F: drivers/devfreq/tegra30-devfreq.c
Except of missing the updating of MAINTAINERS,
Acked-by: Chanwoo Choi
Thanks,
Chanwoo Choi
On 11/5/20 1:49 AM, Dmitry Osipenko wrote:
> Remove tegra20-devfreq in order to replace it with a EMC_STAT based
> devfreq driver. Previously we were going to use MC_STAT based
> tegra20-devfreq driver because EMC_STAT wasn't working properly, but
> now that problem is resolved. This resolves complications imposed by
> the removed driver since it was depending on both EMC and MC drivers
> simultaneously.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/Kconfig | 10 --
> drivers/devfreq/Makefile | 1 -
> drivers/devfreq/tegra20-devfreq.c | 210 --
> 3 files changed, 221 deletions(-)
> delete mode 100644 drivers/devfreq/tegra20-devfreq.c
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 0ee36ae2fa79..00704efe6398 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -121,16 +121,6 @@ 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 ARCH_TEGRA_2x_SOC || COMPILE_TEST
> - depends on COMMON_CLK
> - select DEVFREQ_GOV_SIMPLE_ONDEMAND
> - 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 && HAVE_ARM_SMCCC) || \
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 3ca1ad0ecb97..a16333ea7034 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -13,7 +13,6 @@ obj-$(CONFIG_ARM_IMX_BUS_DEVFREQ) += imx-bus.o
> obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.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
> deleted file mode 100644
> index fd801534771d..
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ /dev/null
> @@ -1,210 +0,0 @@
> -// 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 *emc_clock;
> - 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);
>
Re: [PATCH v7 46/47] PM / devfreq: tegra30: Separate configurations per-SoC generation
return -ENOMEM;
>
> + tegra->soc = of_device_get_match_data(>dev);
> +
> tegra->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(tegra->regs))
> return PTR_ERR(tegra->regs);
> @@ -866,9 +891,9 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> tegra->max_freq = rate / KHZ;
>
> - for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
> + for (i = 0; i < ARRAY_SIZE(tegra->devices); i++) {
> dev = tegra->devices + i;
> - dev->config = actmon_device_configs + i;
> + dev->config = tegra->soc->configs + i;
> dev->regs = tegra->regs + dev->config->offset;
> }
>
> @@ -933,9 +958,24 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct tegra_devfreq_soc_data tegra124_soc = {
> + .configs = tegra124_device_configs,
> +
> + /*
> + * Activity counter is incremented every 256 memory transactions,
> + * and each transaction takes 4 EMC clocks.
> + */
> + .count_weight = 4 * 256,
> +};
> +
> +static const struct tegra_devfreq_soc_data tegra30_soc = {
> + .configs = tegra30_device_configs,
> + .count_weight = 2 * 256,
> +};
> +
> static const struct of_device_id tegra_devfreq_of_match[] = {
> - { .compatible = "nvidia,tegra30-actmon" },
> - { .compatible = "nvidia,tegra124-actmon" },
> + { .compatible = "nvidia,tegra30-actmon", .data = _soc, },
> + { .compatible = "nvidia,tegra124-actmon", .data = _soc, },
> { },
> };
>
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 45/47] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
pp_table = dev_pm_opp_get_opp_table(>dev);
> + err = PTR_ERR_OR_ZERO(tegra->opp_table);
> + if (err) {
> + dev_err(>dev, "Failed to prepare OPP table: %d\n", err);
> + return err;
> + }
> +
> + opp_table = dev_pm_opp_set_supported_hw(>dev, _version, 1);
> + err = PTR_ERR_OR_ZERO(opp_table);
> + if (err) {
> + dev_err(>dev, "Failed to set supported HW: %d\n", err);
> + goto put_table;
> + }
> +
> + err = dev_pm_opp_of_add_table(>dev);
> + if (err) {
> + dev_err(>dev, "Failed to add OPP table: %d\n", err);
> + goto put_hw;
> + }
> +
> err = clk_prepare_enable(tegra->clock);
> if (err) {
> dev_err(>dev,
> "Failed to prepare and enable ACTMON clock\n");
> - return err;
> + goto remove_table;
> }
>
> err = reset_control_reset(tegra->reset);
> @@ -850,23 +872,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> dev->regs = tegra->regs + dev->config->offset;
> }
>
> - for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
> - rate = clk_round_rate(tegra->emc_clock, rate);
> -
> - if (rate < 0) {
> - dev_err(>dev,
> - "Failed to round clock rate: %ld\n", rate);
> - err = rate;
> - goto remove_opps;
> - }
> -
> - err = dev_pm_opp_add(>dev, rate / KHZ, 0);
> - if (err) {
> - dev_err(>dev, "Failed to add OPP: %d\n", err);
> - goto remove_opps;
> - }
> - }
> -
> platform_set_drvdata(pdev, tegra);
>
> tegra->clk_rate_change_nb.notifier_call = tegra_actmon_clk_notify_cb;
> @@ -882,7 +887,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> }
>
> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
> - tegra_devfreq_profile.initial_freq /= KHZ;
>
> devfreq = devfreq_add_device(>dev, _devfreq_profile,
>"tegra_actmon", NULL);
> @@ -902,6 +906,12 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> reset_control_reset(tegra->reset);
> disable_clk:
> clk_disable_unprepare(tegra->clock);
> +remove_table:
> + dev_pm_opp_of_remove_table(>dev);
> +put_hw:
> + dev_pm_opp_put_supported_hw(tegra->opp_table);
> +put_table:
> + dev_pm_opp_put_opp_table(tegra->opp_table);
>
> return err;
> }
> @@ -913,11 +923,13 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> devfreq_remove_device(tegra->devfreq);
> devfreq_remove_governor(_devfreq_governor);
>
> - dev_pm_opp_remove_all_dynamic(>dev);
> -
> reset_control_reset(tegra->reset);
> clk_disable_unprepare(tegra->clock);
>
> + dev_pm_opp_of_remove_table(>dev);
> + dev_pm_opp_put_supported_hw(tegra->opp_table);
> + dev_pm_opp_put_opp_table(tegra->opp_table);
> +
> return 0;
> }
>
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 0/7] Exynos: Simple QoS for exynos-bus using interconnect
17 ++ > drivers/gpu/drm/exynos/exynos_mixer.c | 146 ++- > drivers/interconnect/Kconfig | 1 + > drivers/interconnect/Makefile | 1 + > drivers/interconnect/samsung/Kconfig | 13 ++ > drivers/interconnect/samsung/Makefile | 4 + > drivers/interconnect/samsung/exynos.c | 199 > + > 10 files changed, 456 insertions(+), 10 deletions(-) > create mode 100644 drivers/interconnect/samsung/Kconfig > create mode 100644 drivers/interconnect/samsung/Makefile > create mode 100644 drivers/interconnect/samsung/exynos.c > I tested it. It is well working. Thanks. Tested-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 7/7] drm: exynos: mixer: Add interconnect support
if (!ctx) {
> DRM_DEV_ERROR(dev, "failed to alloc mixer context.\n");
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto err;
> }
>
> drv = of_device_get_match_data(dev);
>
> + INIT_WORK(>work, mixer_icc_request_fn);
> + mutex_init(>icc_lock);
> +
> ctx->pdev = pdev;
> ctx->dev = dev;
> ctx->mxr_ver = drv->version;
> + ctx->icc_path = path;
>
> if (drv->is_vp_enabled)
> __set_bit(MXR_BIT_VP_ENABLED, >flags);
> @@ -1247,17 +1368,26 @@ static int mixer_probe(struct platform_device *pdev)
> pm_runtime_enable(dev);
>
> ret = component_add(>dev, _component_ops);
> - if (ret)
> + if (ret) {
> pm_runtime_disable(dev);
> -
> + goto err;
> + }
> + return 0;
> +err:
> + icc_put(path);
> return ret;
> }
>
> static int mixer_remove(struct platform_device *pdev)
> {
> - pm_runtime_disable(>dev);
> + struct device *dev = >dev;
> + struct mixer_context *ctx = dev_get_drvdata(dev);
> +
> + pm_runtime_disable(dev);
> +
> + component_del(dev, _component_ops);
>
> - component_del(>dev, _component_ops);
> + icc_put(ctx->icc_path);
>
> return 0;
> }
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 5/7] ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
Hi Sylwester, On Wed, Nov 4, 2020 at 7:37 PM Sylwester Nawrocki wrote: > > This patch adds the following properties for Exynos4412 interconnect > bus nodes: > - interconnects: to declare connections between nodes in order to >guarantee PM QoS requirements between nodes, > - #interconnect-cells: required by the interconnect framework, > - samsung,data-clk-ratio: which allows to specify minimum data clock >frequency corresponding to requested bandwidth for each bus. > > Note that #interconnect-cells is always zero and node IDs are not > hardcoded anywhere. > > Signed-off-by: Artur Świgoń > Signed-off-by: Sylwester Nawrocki > --- > Changes for v8: > - none. > > Changes for v7: > - adjusted to the DT property changes: "interconnects" instead >of "samsung,interconnect-parent", "samsung,data-clk-ratio" >instead of "bus-width". > > Changes for v6: > - added bus-width property in bus_dmc node. > > Changes for v5: > - adjust to renamed exynos,interconnect-parent-node property, > - add properties in common exynos4412.dtsi file rather than >in Odroid specific odroid4412-odroid-common.dtsi. > --- > arch/arm/boot/dts/exynos4412.dtsi | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/boot/dts/exynos4412.dtsi > b/arch/arm/boot/dts/exynos4412.dtsi > index e76881d..4999e68 100644 > --- a/arch/arm/boot/dts/exynos4412.dtsi > +++ b/arch/arm/boot/dts/exynos4412.dtsi > @@ -383,6 +383,8 @@ > clocks = < CLK_DIV_DMC>; > clock-names = "bus"; > operating-points-v2 = <_dmc_opp_table>; > + samsung,data-clock-ratio = <4>; > + #interconnect-cells = <0>; > status = "disabled"; > }; > > @@ -452,6 +454,8 @@ > clocks = < CLK_DIV_GDL>; > clock-names = "bus"; > operating-points-v2 = <_leftbus_opp_table>; > + interconnects = <_dmc>; > + #interconnect-cells = <0>; > status = "disabled"; > }; > > @@ -468,6 +472,8 @@ > clocks = < CLK_ACLK160>; > clock-names = "bus"; > operating-points-v2 = <_display_opp_table>; > + interconnects = <_leftbus _dmc>; > + #interconnect-cells = <0>; > status = "disabled"; > }; > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 3/7] MAINTAINERS: Add entry for Samsung interconnect drivers
Hi Sylwester, On Wed, Nov 4, 2020 at 7:37 PM Sylwester Nawrocki wrote: > > Add maintainers entry for the Samsung interconnect drivers, this currently > includes Exynos SoC generic interconnect driver. > > Signed-off-by: Sylwester Nawrocki > --- > Changes since v7: > - new patch. > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e73636b..4bbafef 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9156,6 +9156,13 @@ F: include/dt-bindings/interconnect/ > F: include/linux/interconnect-provider.h > F: include/linux/interconnect.h > > +SAMSUNG INTERCONNECT DRIVERS > +M: Sylwester Nawrocki > +M: Artur Swigoń > +L: linux...@vger.kernel.org > +S: Supported > +F: drivers/interconnect/samsung > + > INVENSENSE ICM-426xx IMU DRIVER > M: Jean-Baptiste Maneyrol > L: linux-...@vger.kernel.org > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/7] interconnect: Add generic interconnect driver for Exynos SoCs
+
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = >dev;
> + platform_set_drvdata(pdev, priv);
> +
> + provider = >provider;
> +
> + provider->set = exynos_generic_icc_set;
> + provider->aggregate = icc_std_aggregate;
> + provider->xlate = exynos_generic_icc_xlate;
> + provider->dev = bus_dev;
> + provider->inter_set = true;
> + provider->data = priv;
> +
> + ret = icc_provider_add(provider);
> + if (ret < 0)
> + return ret;
> +
> + icc_node = icc_node_create(pdev->id);
> + if (IS_ERR(icc_node)) {
> + ret = PTR_ERR(icc_node);
> + goto err_prov_del;
> + }
> +
> + priv->node = icc_node;
> + icc_node->name = devm_kasprintf(>dev, GFP_KERNEL, "%pOFn",
> + bus_dev->of_node);
> + if (of_property_read_u32(bus_dev->of_node, "samsung,data-clock-ratio",
> +>bus_clk_ratio))
> + priv->bus_clk_ratio = EXYNOS_ICC_DEFAULT_BUS_CLK_RATIO;
> +
> + /*
> +* Register a PM QoS request for the parent (devfreq) device.
> +*/
> + ret = dev_pm_qos_add_request(bus_dev, >qos_req,
> +DEV_PM_QOS_MIN_FREQUENCY, 0);
> + if (ret < 0)
> + goto err_node_del;
> +
> + icc_node->data = priv;
> + icc_node_add(icc_node, provider);
> +
> + icc_parent_node = exynos_icc_get_parent(bus_dev->of_node);
> + if (IS_ERR(icc_parent_node)) {
> + ret = PTR_ERR(icc_parent_node);
> + goto err_pmqos_del;
> + }
> + if (icc_parent_node) {
> + ret = icc_link_create(icc_node, icc_parent_node->id);
> + if (ret < 0)
> + goto err_pmqos_del;
> + }
> +
> + return 0;
> +
> +err_pmqos_del:
> + dev_pm_qos_remove_request(>qos_req);
> +err_node_del:
> + icc_nodes_remove(provider);
> +err_prov_del:
> + icc_provider_del(provider);
> + return ret;
> +}
> +
> +static struct platform_driver exynos_generic_icc_driver = {
> + .driver = {
> + .name = "exynos-generic-icc",
> + .sync_state = icc_sync_state,
> + },
> + .probe = exynos_generic_icc_probe,
> + .remove = exynos_generic_icc_remove,
> +};
> +module_platform_driver(exynos_generic_icc_driver);
> +
> +MODULE_DESCRIPTION("Exynos generic interconnect driver");
> +MODULE_AUTHOR("Artur Świgoń ");
> +MODULE_AUTHOR("Sylwester Nawrocki ");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:exynos-generic-icc");
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/7] dt-bindings: devfreq: Add documentation for the interconnect properties
compatible = "samsung,exynos-bus";
> + clocks = < CLK_ACLK160>;
> + clock-names = "bus";
> + operating-points-v2 = <_display_opp_table>;
> + #interconnect-cells = <0>;
> + interconnects = <_leftbus _dmc>;
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + /* ... */
> + }
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + /* ... */
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + /* .. */
> + };
> +
> +{
> + compatible = "samsung,exynos4212-mixer";
> + interconnects = <_display _dmc>;
> + /* ... */
> + };
> + };
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Acked-by: Chanwoo Choi
Thanks for your work.
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
Hi Sylwester,
On Tue, Nov 3, 2020 at 8:32 PM Sylwester Nawrocki
wrote:
>
> On 03.11.2020 10:37, Chanwoo Choi wrote:
> > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> >> This patch adds a generic interconnect driver for Exynos SoCs in order
> >> to provide interconnect functionality for each "samsung,exynos-bus"
> >> compatible device.
> >>
> >> The SoC topology is a graph (or more specifically, a tree) and its
> >> edges are specified using the 'samsung,interconnect-parent' in the
> >
> > samsung,interconnect-parent -> interconnects?
>
> Yes, I will rephrase the whole commit message as it's a bit outdated now.
>
> I've changed the sentence to:
> "The SoC topology is a graph (or more specifically, a tree) and its
> edges are described by specifying in the 'interconnects' property
> the interconnect consumer path for each interconnect provider DT node."
>
> >> DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
> >> propagated to ensure that the parent is probed before its children.
> >>
> >> Each bus is now an interconnect provider and an interconnect node as
> >> well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
> >> registers itself as a node. Node IDs are not hardcoded but rather
> >> assigned dynamically at runtime. This approach allows for using this
> >> driver with various Exynos SoCs.
> >>
> >> Frequencies requested via the interconnect API for a given node are
> >> propagated to devfreq using dev_pm_qos_update_request(). Please note
> >> that it is not an error when CONFIG_INTERCONNECT is 'n', in which
> >> case all interconnect API functions are no-op.
> >>
> >> The bus-width DT property is to determine the interconnect data
> >> width and traslate requested bandwidth to clock frequency for each
> >> bus.
> >>
> >> Signed-off-by: Artur Świgoń
> >> Signed-off-by: Sylwester Nawrocki
>
> >> +++ b/drivers/interconnect/exynos/exynos.c
>
> >> +struct exynos_icc_priv {
> >> +struct device *dev;
> >> +
> >> +/* One interconnect node per provider */
> >> +struct icc_provider provider;
> >> +struct icc_node *node;
> >> +
> >> +struct dev_pm_qos_request qos_req;
> >> +u32 bus_clk_ratio;
> >> +};
> >> +
> >> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
> >> +{
> >> +struct of_phandle_args args;
> >> +struct icc_node_data *icc_node_data;
> >> +struct icc_node *icc_node;
> >> +int num, ret;
> >> +
> >> +num = of_count_phandle_with_args(np, "interconnects",
> >> + "#interconnect-cells");
> >> +if (num < 1)
> >> +return NULL; /* parent nodes are optional */
> >> +
> >> +/* Get the interconnect target node */
> >> +ret = of_parse_phandle_with_args(np, "interconnects",
> >> +"#interconnect-cells", 0, );
> >> +if (ret < 0)
> >> +return ERR_PTR(ret);
> >> +
> >> +icc_node_data = of_icc_get_from_provider();
> >> +of_node_put(args.np);
> >> +
> >> +if (IS_ERR(icc_node_data))
> >> +return ERR_CAST(icc_node_data);
> >> +
> >> +icc_node = icc_node_data->node;
> >> +kfree(icc_node_data);
> >> +
> >> +return icc_node;
> >> +}
> >
> > I have a question about exynos_icc_get_parent().
> > As I checked, this function returns the only one icc_node
> > as parent node. But, bus_display dt node in the exynos4412.dtsi
> > specifies the two interconnect node as following with bus_leftbus, bus_dmc,
> >
> > When I checked the return value of exynos_icc_get_parent()
> > during probing for bus_display device, exynos_icc_get_parent() function
> > only returns 'bus_leftbus' icc_node. Do you need to add two phandle
> > of icc node?
>
> Yes, as we use the interconnect consumer bindings we need to specify a path,
> i.e. a pair. When the provider node initializes it will
> link itself to that path. Currently the provider driver uses just the first
> phandle.
As I knew, the interconnect consumer bindings use the two phandles
in the interconnect core as you commented. But, in case of this,
even if add two phandles with interconnect consumding binding style,
th
Re: [PATCH v7 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Hi Sylwester, On Tue, Nov 3, 2020 at 9:32 PM Sylwester Nawrocki wrote: > > Hi Chanwoo, > > On 03.11.2020 11:45, Chanwoo Choi wrote: > > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote: > >> This patch adds registration of a child platform device for the exynos > >> interconnect driver. It is assumed that the interconnect provider will > >> only be needed when #interconnect-cells property is present in the bus > >> DT node, hence the child device will be created only when such a property > >> is present. > >> > >> Signed-off-by: Sylwester Nawrocki > > >> drivers/devfreq/exynos-bus.c | 17 + > > > We don't need to add 'select INTERCONNECT_EXYNOS' in Kconfig? > > I think by doing so we could run into some dependency issues. > > > Do you want to remain it as optional according to user? > Yes, I would prefer to keep it selectable through defconfig. > Currently it's only needed by one 32-bit ARM board. OK. -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Hi Sylwester,
On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> This patch adds registration of a child platform device for the exynos
> interconnect driver. It is assumed that the interconnect provider will
> only be needed when #interconnect-cells property is present in the bus
> DT node, hence the child device will be created only when such a property
> is present.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes for v7, v6:
> - none.
>
> Changes for v5:
> - new patch.
> ---
> drivers/devfreq/exynos-bus.c | 17 +
> 1 file changed, 17 insertions(+)
We don't need to add 'select INTERCONNECT_EXYNOS' in Kconfig?
Do you want to remain it as optional according to user?
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 1e684a4..ee300ee 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -24,6 +24,7 @@
>
> struct exynos_bus {
> struct device *dev;
> + struct platform_device *icc_pdev;
>
> struct devfreq *devfreq;
> struct devfreq_event_dev **edev;
> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
> if (ret < 0)
> dev_warn(dev, "failed to disable the devfreq-event devices\n");
>
> + platform_device_unregister(bus->icc_pdev);
> +
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> if (bus->opp_table) {
> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
> {
> struct exynos_bus *bus = dev_get_drvdata(dev);
>
> + platform_device_unregister(bus->icc_pdev);
> +
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> }
> @@ -432,6 +437,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err;
>
> + /* Create child platform device for the interconnect provider */
> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
> + bus->icc_pdev = platform_device_register_data(
> + dev, "exynos-generic-icc",
> + PLATFORM_DEVID_AUTO, NULL, 0);
> +
> + if (IS_ERR(bus->icc_pdev)) {
> + ret = PTR_ERR(bus->icc_pdev);
> + goto err;
> + }
> + }
> +
> max_state = bus->devfreq->profile->max_state;
> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Exynos: Simple QoS for exynos-bus using interconnect
Hi Sylwester, On 11/3/20 7:12 PM, Sylwester Nawrocki wrote: > Hi Chanwoo, Georgi > > On 03.11.2020 09:53, Chanwoo Choi wrote: >> On 11/3/20 5:29 PM, Georgi Djakov wrote: >>> On 11/3/20 09:54, Chanwoo Choi wrote: > >>>> When I tested this patchset on Odroid-U3, >>>> After setting 0 bps by interconnect[1][2], >>>> the frequency of devfreq devs sustain the high frequency >>>> according to the pm qos request. >>>> >>>> So, I try to find the cause of this situation. >>>> In result, it seems that interconnect exynos driver >>>> updates the pm qos request to devfreq device >>>> during the kernel booting. Do you know why the exynos >>>> interconnect driver request the pm qos during probe >>>> without the mixer request? >>> >>> That's probably because of the sync_state support, that was introduced >>> recently. The icc_sync_state callback needs to be added to the driver >>> (i just left a comment on that patch), and then check again if it works. >>> >>> The idea of the sync_state is that there could be multiple users of a >>> path and we must wait for all consumers to tell their bandwidth needs. >>> Otherwise the first consumer may lower the bandwidth or disable a path >>> needed for another consumer (driver), which has not probed yet. So we >>> maintain a floor bandwidth until everyone has probed. By default the floor >>> bandwidth is INT_MAX, but can be overridden by implementing the get_bw() >>> callback. > > Thanks for detailed explanation Georgi. > >> Thanks for guide. I tested it with your comment of patch2. >> It is well working without problem as I mentioned previously. >> >> I caught the reset operation of PM QoS requested from interconnect >> on kernel log. In result, after completed the kernel booting, >> there is no pm qos request if hdmi cable is not connected. > > Thanks for the bug report Chanwoo, it's related to the sync_state > feature as you guys already figured out. I had to reorder some code > in the interconnect driver probe() to avoid some issues, > i.e. to register PM QoS request before icc_node_add() call but > I forgot to check initial state of the bus frequencies. > > I thought the get_bw implementation might be needed but the default > behaviour seems fine, the PM QoS derived bus frequencies will be > clamped in the devfreq to valid OPP values. > > Chanwoo, in order to set the bandwidth to 0 we could also just blank > the display. Below are some of the commands I use for testing. > > # blank display (disable the mixer entirely) > echo 4 > /sys/devices/platform/exynos-drm/graphics/fb0/blank > > # unblank display > echo 0 > /sys/devices/platform/exynos-drm/graphics/fb0/blank > > # modetest with 2 planes (higher bandwidth test) > ./modetest -s 47:1920x1080 -P 45:1920x1080 -v > Thanks for the test guide. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/6] dt-bindings: devfreq: Add documentation for the interconnect properties
bus _dmc>;
About adding two icc_node, I queried you on patch2.
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + /* ... */
> + }
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + /* ... */
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + /* .. */
> + };
> +
> + {
> + compatible = "samsung,exynos4212-mixer";
> + interconnects = <_display _dmc>;
> + /* ... */
> + };
> + };
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
&& !IS_ERR(parent_node))
> + icc_link_destroy(node, parent_node);
> +
> + icc_nodes_remove(>provider);
> + icc_provider_del(>provider);
> +
> + return 0;
> +}
> +
> +static int exynos_generic_icc_probe(struct platform_device *pdev)
> +{
> + struct device *bus_dev = pdev->dev.parent;
> + struct exynos_icc_priv *priv;
> + struct icc_provider *provider;
> + struct icc_node *icc_node, *icc_parent_node;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = >dev;
> + platform_set_drvdata(pdev, priv);
> +
> + provider = >provider;
> +
> + provider->set = exynos_generic_icc_set;
> + provider->aggregate = icc_std_aggregate;
> + provider->xlate = exynos_generic_icc_xlate;
> + provider->dev = bus_dev;
> + provider->inter_set = true;
> + provider->data = priv;
> +
> + ret = icc_provider_add(provider);
> + if (ret < 0)
> + return ret;
> +
> + icc_node = icc_node_create(pdev->id);
> + if (IS_ERR(icc_node)) {
> + ret = PTR_ERR(icc_node);
> + goto err_prov_del;
> + }
> +
> + priv->node = icc_node;
> + icc_node->name = devm_kasprintf(>dev, GFP_KERNEL, "%pOFn",
> + bus_dev->of_node);
> + if (of_property_read_u32(bus_dev->of_node, "samsung,data-clock-ratio",
> + >bus_clk_ratio))
> + priv->bus_clk_ratio = EXYNOS_ICC_DEFAULT_BUS_CLK_RATIO;
> +
> + /*
> + * Register a PM QoS request for the parent (devfreq) device.
> + */
> + ret = dev_pm_qos_add_request(bus_dev, >qos_req,
> + DEV_PM_QOS_MIN_FREQUENCY, 0);
> + if (ret < 0)
> + goto err_node_del;
> +
> + icc_node->data = priv;
> + icc_node_add(icc_node, provider);
> +
> + icc_parent_node = exynos_icc_get_parent(bus_dev->of_node);
> + if (IS_ERR(icc_parent_node)) {
> + ret = PTR_ERR(icc_parent_node);
> + goto err_pmqos_del;
> + }
> + if (icc_parent_node) {
> + ret = icc_link_create(icc_node, icc_parent_node->id);
> + if (ret < 0)
> + goto err_pmqos_del;
> + }
> +
> + return 0;
> +
> +err_pmqos_del:
> + dev_pm_qos_remove_request(>qos_req);
> +err_node_del:
> + icc_nodes_remove(provider);
> +err_prov_del:
> + icc_provider_del(provider);
> + return ret;
> +}
> +
> +static struct platform_driver exynos_generic_icc_driver = {
> + .driver = {
> + .name = "exynos-generic-icc",
> + },
> + .probe = exynos_generic_icc_probe,
> + .remove = exynos_generic_icc_remove,
> +};
> +module_platform_driver(exynos_generic_icc_driver);
> +
> +MODULE_DESCRIPTION("Exynos generic interconnect driver");
> +MODULE_AUTHOR("Artur Świgoń ");
> +MODULE_AUTHOR("Sylwester Nawrocki ");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:exynos-generic-icc");
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Exynos: Simple QoS for exynos-bus using interconnect
Hi Georgi,
On 11/3/20 5:29 PM, Georgi Djakov wrote:
> Hi Chanwoo and Sylwester,
>
> On 11/3/20 09:54, Chanwoo Choi wrote:
>> Hi Sylwester,
>>
>> When I tested this patchset on Odroid-U3,
>> After setting 0 bps by interconnect[1][2],
>> the frequency of devfreq devs sustain the high frequency
>> according to the pm qos request.
>>
>> So, I try to find the cause of this situation.
>> In result, it seems that interconnect exynos driver
>> updates the pm qos request to devfreq device
>> during the kernel booting. Do you know why the exynos
>> interconnect driver request the pm qos during probe
>> without the mixer request?
>
> That's probably because of the sync_state support, that was introduced
> recently. The icc_sync_state callback needs to be added to the driver
> (i just left a comment on that patch), and then check again if it works.
>
> The idea of the sync_state is that there could be multiple users of a
> path and we must wait for all consumers to tell their bandwidth needs.
> Otherwise the first consumer may lower the bandwidth or disable a path
> needed for another consumer (driver), which has not probed yet. So we
> maintain a floor bandwidth until everyone has probed. By default the floor
> bandwidth is INT_MAX, but can be overridden by implementing the get_bw()
> callback.
Thanks for guide. I tested it with your comment of patch2.
It is well working without problem as I mentioned previously.
I caught the reset operation of PM QoS requested from interconnect
on kernel log. In result, after completed the kernel booting,
there is no pm qos request if hdmi cable is not connected.
[Test Result]
1. Set 622080 Bps with HDMI cable
root@localhost:~# cat /sys/kernel/debug/devfreq/devfreq_summary;
devparent_dev governor
timer polling_ms cur_freq_Hz min_freq_Hz max_freq_Hz
-- -- ---
-- --
soc:bus_dmcnull simple_ondemand
deferrable 504155524
soc:bus_acpsoc:bus_dmcpassive
null026700126700
soc:bus_c2csoc:bus_dmcpassive
null0414
soc:bus_leftbusnull simple_ondemand
deferrable 50212
soc:bus_rightbus soc:bus_leftbuspassive
null0212
soc:bus_displaysoc:bus_leftbuspassive
null02160002
soc:bus_fsys soc:bus_leftbuspassive
null013400113400
soc:bus_peri soc:bus_leftbuspassive
null01 50001
soc:bus_mfcsoc:bus_leftbuspassive
null0212
root@localhost:~# cat /sys/kernel/debug/interconnect/interconnect_graph;
digraph {
rankdir = LR
node [shape = record]
subgraph cluster_1 {
label = "soc:bus_dmc"
"2:bus_dmc" [label="2:bus_dmc
|avg_bw=622080kBps
|peak_bw=622080kBps"]
}
subgraph cluster_2 {
label = "soc:bus_leftbus"
"3:bus_leftbus" [label="3:bus_leftbus
|avg_bw=622080kBps
|peak_bw=622080kBps"]
}
subgraph cluster_3 {
label = "soc:bus_display"
"4:bus_display" [label="4:bus_display
|avg_bw=622080kBps
|peak_bw=622080kBps"]
}
"3:bus_leftbus" -> "2:bus_dmc"
"4:bus_display" -> "3:bus_leftbus"
}root@localhost:~# cat /sys/kernel/debug/interconnect/interconnect_summary;
node tag avg peak
bus_dmc 622080 622080
12c1.mixer 0 622080 622080
bus_leftbus 622080 622080
12c1.mixer 0 622080 622080
bus_display 622080 622080
12c1.mixer
Re: [PATCH v7 0/6] Exynos: Simple QoS for exynos-bus using interconnect
d interconnect frameworks is achieved through > the PM QoS API. > > A sample interconnect consumer for exynos-mixer is added in patches 5/6, > 6/6, it is currently added only for exynos4412 and allows to address the > mixer DMA underrun error issues [1]. > > Changes since v6: > - the interconnect consumer DT bindings are now used to describe dependencies >of the interconnects (samsung,exynos-bus nodes), > - bus-width property replaced with samsung,data-clk-ratio, > - adaptation to recent changes in the interconnect code >(of_icc_get_from_provider(), icc_node_add()). > > The series has been tested on Odroid U3 board. It is based on v5.10-rc1. > > -- > Regards, > Sylwester > > > Changes since v5: > - addition of "bus-width: DT property, which specifies data width >of the interconnect bus (patches 1...2/6), > - addition of synchronization of the interconnect bandwidth setting >with VSYNC (patch 6/6). > > Changes since v3 [4] (v4 skipped to align with patchset [1]), detailed > changes are listed in each patch: > - conversion to a separate interconnect (platform) driver, > - an update of the DT binding documenting new optional properties: >#interconnect-cells, samsung,interconnect-parent in "samsung,exynos-bus" >nodes, > - new DT properties added to the SoC, rather than to the board specific >files. > > Changes since v2 [5]: > - Use icc_std_aggregate(). > - Implement a different modification of apply_constraints() in >drivers/interconnect/core.c (patch 03). > - Use 'exynos,interconnect-parent-node' in the DT instead of >'devfreq'/'parent', depending on the bus. > - Rebase on DT patches that deprecate the 'devfreq' DT property. > - Improve error handling, including freeing generated IDs on failure. > - Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent(). > > Changes since v1 [6]: > - Rebase on coupled regulators patches. > - Use dev_pm_qos_*() API instead of overriding frequency in >exynos_bus_target(). > - Use IDR for node ID allocation. > - Reverse order of multiplication and division in >mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow. > > > References: > [1] https://patchwork.kernel.org/patch/10861757/ (original issue) > [2] > https://protect2.fireeye.com/v1/url?k=383efc40-67a5c559-383f770f-000babff3793-a505fcd0b7477e5e=1=ad8ffb9f-f90b-49a7-a3df-2ab066a8c4ee=https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-samsung-soc%2Fmsg70014.html > [3] > https://protect2.fireeye.com/v1/url?k=13f0c488-4c6bfd91-13f14fc7-000babff3793-98a59bf1c5c6f1fb=1=ad8ffb9f-f90b-49a7-a3df-2ab066a8c4ee=https%3A%2F%2Fwww.spinics.net%2Flists%2Farm-kernel%2Fmsg810722.html > [4] > https://lore.kernel.org/linux-pm/20191220115653.6487-1-a.swi...@samsung.com > [5] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) > [6] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC) > > > Artur Świgoń (1): > ARM: dts: exynos: Add interconnects to Exynos4412 mixer > > Sylwester Nawrocki (5): > dt-bindings: devfreq: Add documentation for the interconnect > properties > interconnect: Add generic interconnect driver for Exynos SoCs > PM / devfreq: exynos-bus: Add registration of interconnect child > device > ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes > drm: exynos: mixer: Add interconnect support > > .../devicetree/bindings/devfreq/exynos-bus.txt | 68 ++- > arch/arm/boot/dts/exynos4412.dtsi | 7 + > drivers/devfreq/exynos-bus.c | 17 ++ > drivers/gpu/drm/exynos/exynos_mixer.c | 146 ++- > drivers/interconnect/Kconfig | 1 + > drivers/interconnect/Makefile | 1 + > drivers/interconnect/exynos/Kconfig| 6 + > drivers/interconnect/exynos/Makefile | 4 + > drivers/interconnect/exynos/exynos.c | 198 > + > 9 files changed, 438 insertions(+), 10 deletions(-) > create mode 100644 drivers/interconnect/exynos/Kconfig > create mode 100644 drivers/interconnect/exynos/Makefile > create mode 100644 drivers/interconnect/exynos/exynos.c > > -- > 2.7.4 > > > -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 49/52] PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree
On 11/3/20 5:08 AM, Dmitry Osipenko wrote: > 01.11.2020 17:12, Dmitry Osipenko пишет: > ... >> We will probably move the Tegra20 EMC_STAT devfreq driver into the >> memory driver and remove the older IMC_STAT driver in v7, like it was >> suggested by Thierry Reding. This will be a much less invasive code change. >> >>> Also, if you want to get more responsiveness, you could use delayed timer >>> instead of deferrable timer by editing the devfreq_dev_profile structure. >> >> Thanks, I'll try the deferrable timer. > > I took a brief look at the delayed timer and I think the deferrable > timer should be more a preferred option because this devfreq drive is > more an assistance for the optimal bandwidth selection and it will be > more preferred to keep system idling whenever possible. > > My primary concern is the initial performance lag in a case of > multimedia applications. But this will be resolved by hooking up > performance voting to all drivers, once we will get around to it. OK. You can choice the type of timer on both probe and via sysfs file on the runtime. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Hi Sylwester,
On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> This patch adds registration of a child platform device for the exynos
> interconnect driver. It is assumed that the interconnect provider will
> only be needed when #interconnect-cells property is present in the bus
> DT node, hence the child device will be created only when such a property
> is present.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes for v7, v6:
> - none.
>
> Changes for v5:
> - new patch.
> ---
> drivers/devfreq/exynos-bus.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 1e684a4..ee300ee 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -24,6 +24,7 @@
>
> struct exynos_bus {
> struct device *dev;
> + struct platform_device *icc_pdev;
>
> struct devfreq *devfreq;
> struct devfreq_event_dev **edev;
> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
> if (ret < 0)
> dev_warn(dev, "failed to disable the devfreq-event devices\n");
>
> + platform_device_unregister(bus->icc_pdev);
> +
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> if (bus->opp_table) {
> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
> {
> struct exynos_bus *bus = dev_get_drvdata(dev);
>
> + platform_device_unregister(bus->icc_pdev);
> +
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> }
> @@ -432,6 +437,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err;
>
> + /* Create child platform device for the interconnect provider */
> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
> + bus->icc_pdev = platform_device_register_data(
> + dev, "exynos-generic-icc",
> + PLATFORM_DEVID_AUTO, NULL, 0);
> +
> + if (IS_ERR(bus->icc_pdev)) {
> + ret = PTR_ERR(bus->icc_pdev);
> + goto err;
> + }
> + }
> +
> max_state = bus->devfreq->profile->max_state;
> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
On Mon, Nov 2, 2020 at 12:49 AM Dmitry Osipenko wrote: > > 01.11.2020 18:44, Chanwoo Choi пишет: > >> OPP core will try to grab the clock reference for the table and it may > >> cause EPROBE_DEFER. Although, it shouldn't happen here because we have > >> devm_clk_get() before the get_opp_table(), hence seems the deferred > >> probe indeed shouldn't happen in this case. > > It is my missing point. If there, you're right. > > Could you provide the code point to check the clock reference on the OPP > > core? > > Please see it here: > > https://elixir.bootlin.com/linux/v5.10-rc1/source/drivers/opp/core.c#L1101 Thanks. It seems that if device tree node contains the any node, it is not EPROBE_DEFER because of just using "clk_get(dev, NULL)". The patch[1] used the 'dev_err_probe' for getting the "emc" clock. Do you need to check it more? [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-next=09d56d92ad25b58113f4ec677e9b1ac1e2c3072b -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry,
On Mon, Nov 2, 2020 at 12:24 AM Dmitry Osipenko wrote:
>
> 01.11.2020 17:44, Chanwoo Choi пишет:
> > Hi Dmitry,
> >
> > On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
> >>
> >> This patch moves ACTMON driver away from generating OPP table by itself,
> >> transitioning it to use the table which comes from device-tree. This
> >> change breaks compatibility with older device-trees in order to bring
> >> support for the interconnect framework to the driver. This is a mandatory
> >> change which needs to be done in order to implement interconnect-based
> >> memory DVFS. Users of legacy device-trees will get a message telling that
> >> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> >> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
> >>
> >> Tested-by: Peter Geis
> >> Tested-by: Nicolas Chauvet
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> drivers/devfreq/tegra30-devfreq.c | 91 ---
> >> 1 file changed, 48 insertions(+), 43 deletions(-)
> >>
> >> diff --git a/drivers/devfreq/tegra30-devfreq.c
> >> b/drivers/devfreq/tegra30-devfreq.c
> >> index 3f732ab53573..1b0b91a71886 100644
> >> --- a/drivers/devfreq/tegra30-devfreq.c
> >> +++ b/drivers/devfreq/tegra30-devfreq.c
> >> @@ -19,6 +19,8 @@
> >> #include
> >> #include
> >>
> >> +#include
> >> +
> >
> > This patch touches the OPP. Is it related to this change?
>
> Yes, this is needed for the dev_pm_opp_set_supported_hw().
OK.
>
> >> #include "governor.h"
> >>
> >> #define ACTMON_GLB_STATUS 0x0
> >> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
> >>
> >> struct tegra_devfreq {
> >> struct devfreq *devfreq;
> >> + struct opp_table*opp_table;
> >>
> >> struct reset_control*reset;
> >> struct clk *clock;
> >> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> >> *tegra)
> >> 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;
> >> + int ret;
> >>
> >> opp = devfreq_recommended_opp(dev, freq, flags);
> >> if (IS_ERR(opp)) {
> >> - dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> >> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
> >
> > You used the 'Failed to' format in almost every error case.
> > Don't need to change it.
> > (snip)
>
> Good catch, thanks.
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry,
On Mon, Nov 2, 2020 at 12:23 AM Dmitry Osipenko wrote:
>
> 01.11.2020 17:39, Chanwoo Choi пишет:
> > Hi Dmitry,
> >
> > On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
> >>
> >> This patch moves ACTMON driver away from generating OPP table by itself,
> >> transitioning it to use the table which comes from device-tree. This
> >> change breaks compatibility with older device-trees in order to bring
> >> support for the interconnect framework to the driver. This is a mandatory
> >> change which needs to be done in order to implement interconnect-based
> >> memory DVFS. Users of legacy device-trees will get a message telling that
> >> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> >> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
> >>
> >> Tested-by: Peter Geis
> >> Tested-by: Nicolas Chauvet
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> ...
> >> static int tegra_devfreq_get_dev_status(struct device *dev,
> >> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
> >> *dev,
> >> stat->private_data = tegra;
> >>
> >> /* The below are to be used by the other governors */
> >> - stat->current_frequency = cur_freq;
> >> + stat->current_frequency = cur_freq * KHZ;
> >
> > I can't find any change related to the frequency unit on this patch.
> > Do you fix the previous bug of the frequency unit?
>
> Previously, OPP entries that were generated by the driver used KHz
> units. Now, OPP entries are coming from a device-tree and they have Hz
> units. This driver operates with KHz internally, hence we need to
> convert the units now.
OK. Thanks.
>
> >>
> >> actmon_dev = >devices[MCALL];
> >>
> >> @@ -705,7 +693,7 @@ static int tegra_governor_get_target(struct devfreq
> >> *devfreq,
> >> target_freq = max(target_freq, dev->target_freq);
> >> }
> >>
> >> - *freq = target_freq;
> >> + *freq = target_freq * KHZ;
> >
> > ditto.
> >
> >>
> >> return 0;
> >> }
> >> @@ -773,13 +761,22 @@ static struct devfreq_governor
> >> tegra_devfreq_governor = {
> >>
> >> static int tegra_devfreq_probe(struct platform_device *pdev)
> >> {
> >> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> >> struct tegra_devfreq_device *dev;
> >> struct tegra_devfreq *tegra;
> >> + struct opp_table *opp_table;
> >> struct devfreq *devfreq;
> >> unsigned int i;
> >> long rate;
> >> int err;
> >>
> >> + /* legacy device-trees don't have OPP table and must be updated */
> >> + if (!device_property_present(>dev, "operating-points-v2")) {
> >> + dev_err(>dev, "OPP table not found, cannot
> >> continue\n");
> >> + dev_err(>dev, "please update your device tree\n");
> >> + return -ENODEV;
> >> + }
> >
> > As you mentioned, it breaks the old dtb. I have no objection to improving
> > the driver. Instead, you need confirmation from the Devicetree maintainer.
>
> Older DTBs will continue to work, but devfreq driver won't. We already
> did this for other Tegra drivers before (CPUFREQ driver for example) and
> Rob Herring confirmed that there is no problem here.
OK.
>
> > And,
> > I recommend that you use dev_pm_opp_of_get_opp_desc_node(>dev)
> > to check whether a device contains opp-table or not.
>
> I'm not sure what are the benefits, this will make code less
> expressive/readable and we will need to add extra of_node_put(), which
> device_property_present() handles for us.
>
> Could you please give the rationale?
IMO, 'operating-points-v2' word was defined on OPP core. I think that
the external user
of OPP better to use the public helper function instead of using the
interval definition
or value of OPP core directly. Basically, I prefer the provided helper
function if there.
But, it is not critical and doesn't affect the operation. If you want
to keep, it is ok.
>
> >> +
> >> tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
> >> if (!tegra)
> >> return -ENOMEM;
> >> @@ -821,11 +818,29 @@ static int tegra_devfreq_probe(struct
> >> platform_device
Re: [PATCH v6 52/52] PM / devfreq: tegra30: Separate configurations per-SoC generation
8,7 +511,7 @@ static void tegra_actmon_configure_device(struct
> tegra_devfreq *tegra,
> tegra_devfreq_update_avg_wmark(tegra, dev);
> tegra_devfreq_update_wmark(tegra, dev);
>
> - device_writel(dev, ACTMON_COUNT_WEIGHT, ACTMON_DEV_COUNT_WEIGHT);
> + device_writel(dev, tegra->soc->count_weight, ACTMON_DEV_COUNT_WEIGHT);
> device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
>
> val |= ACTMON_DEV_CTRL_ENB_PERIODIC;
> @@ -781,6 +804,8 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> if (!tegra)
> return -ENOMEM;
>
> + tegra->soc = of_device_get_match_data(>dev);
> +
> tegra->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(tegra->regs))
> return PTR_ERR(tegra->regs);
> @@ -858,9 +883,9 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> tegra->max_freq = rate / KHZ;
>
> - for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
> + for (i = 0; i < ARRAY_SIZE(tegra124_device_configs); i++) {
ditto. Use ARRARY_SIZE(soc->configs) instead of
ARRAY_SIZE(tegra124_device_configs).
> dev = tegra->devices + i;
> - dev->config = actmon_device_configs + i;
> + dev->config = tegra->soc->configs + i;
> dev->regs = tegra->regs + dev->config->offset;
> }
>
> @@ -925,9 +950,24 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct tegra_devfreq_soc_data tegra124_soc = {
> + .configs = tegra124_device_configs,
> +
> + /*
> +* Activity counter is incremented every 256 memory transactions,
> +* and each transaction takes 4 EMC clocks.
> +*/
> + .count_weight = 4 * 256,
> +};
> +
> +static const struct tegra_devfreq_soc_data tegra30_soc = {
> + .configs = tegra30_device_configs,
> + .count_weight = 2 * 256,
> +};
> +
> static const struct of_device_id tegra_devfreq_of_match[] = {
> - { .compatible = "nvidia,tegra30-actmon" },
> - { .compatible = "nvidia,tegra124-actmon" },
> + { .compatible = "nvidia,tegra30-actmon", .data = _soc, },
> + { .compatible = "nvidia,tegra124-actmon", .data = _soc, },
> { },
> };
>
> --
> 2.27.0
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry,
On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
>
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees in order to bring
> support for the interconnect framework to the driver. This is a mandatory
> change which needs to be done in order to implement interconnect-based
> memory DVFS. Users of legacy device-trees will get a message telling that
> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 91 ---
> 1 file changed, 48 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 3f732ab53573..1b0b91a71886 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -19,6 +19,8 @@
> #include
> #include
>
> +#include
> +
This patch touches the OPP. Is it related to this change?
> #include "governor.h"
>
> #define ACTMON_GLB_STATUS 0x0
> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
>
> struct tegra_devfreq {
> struct devfreq *devfreq;
> + struct opp_table*opp_table;
>
> struct reset_control*reset;
> struct clk *clock;
> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> *tegra)
> 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;
> + int ret;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> - dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
You used the 'Failed to' format in almost every error case.
Don't need to change it.
(snip)
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
at you use dev_pm_opp_of_get_opp_desc_node(>dev)
to check whether a device contains opp-table or not.
> +
> tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
> if (!tegra)
> return -ENOMEM;
> @@ -821,11 +818,29 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + tegra->opp_table = dev_pm_opp_get_opp_table(>dev);
> + if (IS_ERR(tegra->opp_table))
> + return dev_err_probe(>dev, PTR_ERR(tegra->opp_table),
> +"Failed to prepare OPP table\n");
As I knew, each device can contain the opp_table on devicetree.
It means that opp_table has not depended to another device driver.
Did you see this exception case with EPROBE_DEFER error?
> +
> + opp_table = dev_pm_opp_set_supported_hw(>dev, _version, 1);
> + err = PTR_ERR_OR_ZERO(opp_table);
> + if (err) {
> + dev_err(>dev, "Failed to set supported HW: %d\n", err);
> + goto put_table;
> + }
> +
> + err = dev_pm_opp_of_add_table(>dev);
> + if (err) {
> + dev_err(>dev, "Failed to add OPP table: %d\n", err);
> + goto put_hw;
> + }
> +
> err = clk_prepare_enable(tegra->clock);
> if (err) {
> dev_err(>dev,
> "Failed to prepare and enable ACTMON clock\n");
> - return err;
> + goto remove_table;
> }
>
> err = reset_control_reset(tegra->reset);
> @@ -849,23 +864,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> dev->regs = tegra->regs + dev->config->offset;
> }
>
> - for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
> - rate = clk_round_rate(tegra->emc_clock, rate);
> -
> - if (rate < 0) {
> - dev_err(>dev,
> - "Failed to round clock rate: %ld\n", rate);
> - err = rate;
> - goto remove_opps;
> - }
> -
> - err = dev_pm_opp_add(>dev, rate / KHZ, 0);
> - if (err) {
> - dev_err(>dev, "Failed to add OPP: %d\n", err);
> - goto remove_opps;
> - }
> - }
> -
> platform_set_drvdata(pdev, tegra);
>
> tegra->clk_rate_change_nb.notifier_call = tegra_actmon_clk_notify_cb;
> @@ -881,7 +879,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> }
>
> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
> - tegra_devfreq_profile.initial_freq /= KHZ;
>
> devfreq = devfreq_add_device(>dev, _devfreq_profile,
> "tegra_actmon", NULL);
> @@ -901,6 +898,12 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> reset_control_reset(tegra->reset);
> disable_clk:
> clk_disable_unprepare(tegra->clock);
> +remove_table:
> + dev_pm_opp_of_remove_table(>dev);
> +put_hw:
> + dev_pm_opp_put_supported_hw(tegra->opp_table);
> +put_table:
> + dev_pm_opp_put_opp_table(tegra->opp_table);
>
> return err;
> }
> @@ -912,11 +915,13 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> devfreq_remove_device(tegra->devfreq);
> devfreq_remove_governor(_devfreq_governor);
>
> - dev_pm_opp_remove_all_dynamic(>dev);
> -
> reset_control_reset(tegra->reset);
> clk_disable_unprepare(tegra->clock);
>
> + dev_pm_opp_of_remove_table(>dev);
> + dev_pm_opp_put_supported_hw(tegra->opp_table);
> + dev_pm_opp_put_opp_table(tegra->opp_table);
> +
> return 0;
> }
>
> --
> 2.27.0
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 49/52] PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree
Hi Dmitry,
This patch contains the three features as following:
1. Use interconnect interface for controlling the clock instead of
controlling it direclty
2. Use EMC_STAT instead of IMC_STAT
3. Change polling_interval and upthreshold for more fast responsiveness
I think you need to make the separate patches for each role.
But, if it is difficult or not proper to split out 1,2 roles, you can
make two patches for 1,2 and 3 roles.
Also, if you want to get more responsiveness, you could use delayed timer
instead of deferrable timer by editing the devfreq_dev_profile structure.
Regards,
Chanwoo Choi
On Mon, Oct 26, 2020 at 7:21 AM Dmitry Osipenko wrote:
>
> External (EMC) and Internal Memory Controllers (IMC) have a nearly
> identical statistics gathering module. This patch switches driver to use
> EMC_STAT instead of IMC_STAT and adds device-tree support which brings ICC
> support and makes driver to use bandwidth OPPs defined in device-tree.
>
> The previous tegra20-devfreq variant was depending on presence of both
> EMC and IMC drivers simultaneously because it wasn't apparent how to use
> EMC_STAT properly back in the day. Dependency on the IMC driver is gone
> after this patch.
>
> The older variant of the devfreq driver also isn't suitable anymore
> because EMC got support for interconnect framework and DVFS, hence
> tegra20-devfreq shouldn't drive the EMC clock directly, but use OPP
> API for issuing memory bandwidth requests.
>
> The polling interval is changed from 500ms to 30ms in order to improve
> responsiveness of the system in general and because EMC clock is now
> allowed to go lower than before since display driver supports ICC now
> as well.
>
> The parent EMC device is an MFD device now and tegra20-devfreq its
> sub-device. Devfreq driver uses SYSCON API for retrieving regmap of the
> EMC registers from the parent device.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/Kconfig | 1 +
> drivers/devfreq/tegra20-devfreq.c | 174 +-
> 2 files changed, 75 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 0ee36ae2fa79..1bd225e571df 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -126,6 +126,7 @@ config ARM_TEGRA20_DEVFREQ
> depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
> depends on COMMON_CLK
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select MFD_SYSCON
> help
> This adds the DEVFREQ driver for the Tegra20 family of SoCs.
> It reads Memory Controller counters and adjusts the operating
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index fd801534771d..0a36b085d32a 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -7,180 +7,148 @@
>
> #include
> #include
> -#include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
>
> -#include
> -
> #include "governor.h"
>
> -#define MC_STAT_CONTROL0x90
> -#define MC_STAT_EMC_CLOCK_LIMIT0xa0
> -#define MC_STAT_EMC_CLOCKS 0xa4
> -#define MC_STAT_EMC_CONTROL0xa8
> -#define MC_STAT_EMC_COUNT 0xb8
> +#define EMC_STAT_CONTROL 0x160
> +#define EMC_STAT_LLMC_CONTROL 0x178
> +#define EMC_STAT_PWR_CLOCK_LIMIT 0x198
> +#define EMC_STAT_PWR_CLOCKS0x19c
> +#define EMC_STAT_PWR_COUNT 0x1a0
>
> -#define EMC_GATHER_CLEAR (1 << 8)
> -#define EMC_GATHER_ENABLE (3 << 8)
> +#define EMC_PWR_GATHER_CLEAR (1 << 8)
> +#define EMC_PWR_GATHER_DISABLE (2 << 8)
> +#define EMC_PWR_GATHER_ENABLE (3 << 8)
>
> struct tegra_devfreq {
> + struct devfreq_simple_ondemand_data ondemand_data;
> + struct opp_table *opp_table;
> struct devfreq *devfreq;
> struct clk *emc_clock;
> - void __iomem *regs;
> + struct regmap *rmap;
> };
>
> 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;
> + int ret;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> - if (IS_ERR(opp
Re: [PATCH v6 48/52] PM / devfreq: tegra20: Relax Kconfig dependency
On 10/26/20 7:17 AM, Dmitry Osipenko wrote: > The Tegra EMC driver now could be compiled as a loadable kernel module. > Currently devfreq driver depends on the EMC/MC drivers in Kconfig, and > thus, devfreq is forced to be a kernel module if EMC is compiled as a > module. This build dependency could be relaxed since devfreq driver > checks MC/EMC presence on probe, allowing kernel configuration where > devfreq is a built-in driver and EMC driver is a loadable module. > This change puts Tegra20 devfreq Kconfig entry on a par with the Tegra30 > devfreq entry. > > Acked-by: Chanwoo Choi > 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 37dc40d1fcfb..0ee36ae2fa79 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -123,7 +123,7 @@ config ARM_TEGRA_DEVFREQ > > config ARM_TEGRA20_DEVFREQ > tristate "NVIDIA Tegra20 DEVFREQ Driver" > - depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST > + depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST > depends on COMMON_CLK > select DEVFREQ_GOV_SIMPLE_ONDEMAND > help > Applied it. -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 50/52] PM / devfreq: tegra30: Silence deferred probe error
On 10/26/20 7:17 AM, Dmitry Osipenko wrote:
> Tegra EMC driver was turned into a regular kernel driver, meaning that it
> could be compiled as a loadable kernel module now. Hence EMC clock isn't
> guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER.
> Let's silence the deferred probe error.
>
> Acked-by: Chanwoo Choi
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index f5e74c2ede85..3f732ab53573 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -801,10 +801,9 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> }
>
> tegra->emc_clock = devm_clk_get(>dev, "emc");
> - if (IS_ERR(tegra->emc_clock)) {
> - dev_err(>dev, "Failed to get emc clock\n");
> - return PTR_ERR(tegra->emc_clock);
> - }
> + if (IS_ERR(tegra->emc_clock))
> + return dev_err_probe(>dev, PTR_ERR(tegra->emc_clock),
> + "Failed to get emc clock\n");
>
> err = platform_get_irq(pdev, 0);
> if (err < 0)
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 47/52] PM / devfreq: tegra20: Silence deferred probe error
On 10/26/20 7:17 AM, Dmitry Osipenko wrote:
> Tegra EMC driver was turned into a regular kernel driver, meaning that it
> could be compiled as a loadable kernel module now. Hence EMC clock isn't
> guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER.
> Let's silence the deferred probe error.
>
> Acked-by: Chanwoo Choi
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index ff82bac9ee4e..fd801534771d 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -141,11 +141,9 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> /* EMC is a system-critical clock that is always enabled */
> tegra->emc_clock = devm_clk_get(>dev, "emc");
> - if (IS_ERR(tegra->emc_clock)) {
> - err = PTR_ERR(tegra->emc_clock);
> - dev_err(>dev, "failed to get emc clock: %d\n", err);
> - return err;
> - }
> + if (IS_ERR(tegra->emc_clock))
> + return dev_err_probe(>dev, PTR_ERR(tegra->emc_clock),
> + "failed to get emc clock\n");
>
> tegra->regs = mc->regs;
>
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] dt-bindings: Explicitly allow additional properties in common schemas
On 10/6/20 3:38 AM, Rob Herring wrote: > In order to add meta-schema checks for additional/unevaluatedProperties > being present, all schema need to make this explicit. As common/shared > schema are included by other schemas, they should always allow for > additionalProperties. > > Signed-off-by: Rob Herring > --- (snip) > Documentation/devicetree/bindings/extcon/wlf,arizona.yaml| 2 ++ (snip) For the extcon part, Acked-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 62/78] drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
Hi Maxime,
On 9/1/20 6:45 PM, Maxime Ripard wrote:
> Hi Chanwoo,
>
> On Tue, Sep 01, 2020 at 01:36:17PM +0900, Chanwoo Choi wrote:
>> On 7/9/20 2:42 AM, Maxime Ripard wrote:
>>> The HSM clock needs to be setup at around 101% of the pixel rate. This
>>> was done previously by setting the clock rate to 163.7MHz at probe time and
>>> only check in mode_valid whether the mode pixel clock was under the pixel
>>> clock +1% or not.
>>>
>>> However, with 4k we need to change that frequency to a higher frequency
>>> than 163.7MHz, and yet want to have the lowest clock as possible to have a
>>> decent power saving.
>>>
>>> Let's change that logic a bit by setting the clock rate of the HSM clock
>>> to the pixel rate at encoder_enable time. This would work for the
>>> BCM2711 that support 4k resolutions and has a clock that can provide it,
>>> but we still have to take care of a 4k panel plugged on a BCM283x SoCs
>>> that wouldn't be able to use those modes, so let's define the limit in
>>> the variant.
>>>
>>> Signed-off-by: Maxime Ripard
>>> ---
>>> drivers/gpu/drm/vc4/vc4_hdmi.c | 79 ---
>>> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +-
>>> 2 files changed, 41 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> index 17797b14cde4..9f30fab744f2 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> @@ -53,7 +53,6 @@
>>> #include "vc4_hdmi_regs.h"
>>> #include "vc4_regs.h"
>>>
>>> -#define HSM_CLOCK_FREQ 163682864
>>> #define CEC_CLOCK_FREQ 4
>>>
>>> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>> @@ -326,6 +325,7 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
>>> *encoder)
>>> HDMI_WRITE(HDMI_VID_CTL,
>>>HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>>
>>> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>>
>>> ret = pm_runtime_put(_hdmi->pdev->dev);
>>> @@ -423,6 +423,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
>>> *encoder)
>>> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
>>> struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
>>> bool debug_dump_regs = false;
>>> + unsigned long pixel_rate, hsm_rate;
>>> int ret;
>>>
>>> ret = pm_runtime_get_sync(_hdmi->pdev->dev);
>>> @@ -431,9 +432,8 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
>>> *encoder)
>>> return;
>>> }
>>>
>>> - ret = clk_set_rate(vc4_hdmi->pixel_clock,
>>> - mode->clock * 1000 *
>>> - ((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));
>>> + pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
>>> ? 2 : 1);
>>> + ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
>>> if (ret) {
>>> DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
>>> return;
>>> @@ -445,6 +445,36 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
>>> *encoder)
>>> return;
>>> }
>>>
>>> + /*
>>> +* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
>>> +* be faster than pixel clock, infinitesimally faster, tested in
>>> +* simulation. Otherwise, exact value is unimportant for HDMI
>>> +* operation." This conflicts with bcm2835's vc4 documentation, which
>>> +* states HSM's clock has to be at least 108% of the pixel clock.
>>> +*
>>> +* Real life tests reveal that vc4's firmware statement holds up, and
>>> +* users are able to use pixel clocks closer to HSM's, namely for
>>> +* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
>>> +* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
>>> +* 162MHz.
>>> +*
>>> +* Additionally, the AXI clock needs to be at least 25% of
>>> +* pixel clock, but HSM ends up being the limiting factor.
>>> +*/
>>> + hsm_rate = max_t(unsigned long, 12000, (pixel_rate /
Re: [PATCH v4 03/78] drm/vc4: hvs: Boost the core clock during modeset
On 9/1/20 8:21 PM, Chanwoo Choi wrote:
> Hi Maxime,
>
> On 7/9/20 2:41 AM, Maxime Ripard wrote:
>> In order to prevent timeouts and stalls in the pipeline, the core clock
>> needs to be maxed at 500MHz during a modeset on the BCM2711.
>>
>> Reviewed-by: Eric Anholt
>> Signed-off-by: Maxime Ripard
>> ---
>> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
>> drivers/gpu/drm/vc4/vc4_hvs.c | 9 +
>> drivers/gpu/drm/vc4/vc4_kms.c | 9 +
>> 3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
>> index e4cde1f9224b..6358f6ca8d56 100644
>> --- a/drivers/gpu/drm/vc4/vc4_drv.h
>> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
>> @@ -320,6 +320,8 @@ struct vc4_hvs {
>> void __iomem *regs;
>> u32 __iomem *dlist;
>>
>> +struct clk *core_clk;
>> +
>> /* Memory manager for CRTCs to allocate space in the display
>> * list. Units are dwords.
>> */
>> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
>> index 836d8799d79e..091fdf4908aa 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
>> @@ -19,6 +19,7 @@
>> * each CRTC.
>> */
>>
>> +#include
>> #include
>> #include
>>
>> @@ -540,6 +541,14 @@ static int vc4_hvs_bind(struct device *dev, struct
>> device *master, void *data)
>> hvs->regset.regs = hvs_regs;
>> hvs->regset.nregs = ARRAY_SIZE(hvs_regs);
>>
>> +if (hvs->hvs5) {
>> +hvs->core_clk = devm_clk_get(>dev, NULL);
>> +if (IS_ERR(hvs->core_clk)) {
>> +dev_err(>dev, "Couldn't get core clock\n");
>> +return PTR_ERR(hvs->core_clk);
>> +}
>> +}
>> +
>> if (!hvs->hvs5)
>> hvs->dlist = hvs->regs + SCALER_DLIST_START;
>> else
>> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
>> index 08318e69061b..210cc2408087 100644
>> --- a/drivers/gpu/drm/vc4/vc4_kms.c
>> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
>> @@ -11,6 +11,8 @@
>> * crtc, HDMI encoder).
>> */
>>
>> +#include
>> +
>> #include
>> #include
>> #include
>> @@ -149,6 +151,7 @@ vc4_atomic_complete_commit(struct drm_atomic_state
>> *state)
>> {
>> struct drm_device *dev = state->dev;
>> struct vc4_dev *vc4 = to_vc4_dev(dev);
>> +struct vc4_hvs *hvs = vc4->hvs;
>> struct vc4_crtc *vc4_crtc;
>> int i;
>>
>> @@ -160,6 +163,9 @@ vc4_atomic_complete_commit(struct drm_atomic_state
>> *state)
>> vc4_hvs_mask_underrun(dev, vc4_crtc->channel);
>> }
>>
>> +if (vc4->hvs->hvs5)
>> +clk_set_min_rate(hvs->core_clk, 5);
>> +
>> drm_atomic_helper_wait_for_fences(dev, state, false);
>>
>> drm_atomic_helper_wait_for_dependencies(state);
>> @@ -182,6 +188,9 @@ vc4_atomic_complete_commit(struct drm_atomic_state
>> *state)
>>
>> drm_atomic_helper_commit_cleanup_done(state);
>>
>> +if (vc4->hvs->hvs5)
>> +clk_set_min_rate(hvs->core_clk, 0);
>> +
>> drm_atomic_state_put(state);
>>
>> up(>async_modeset);
>>
>
> This patch doesn't control the enable/disable of core_clk.
> So, I think that it need to handle the clock as following:
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 4ef88c0b51ab..355d67fd8beb 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -588,6 +588,12 @@ static int vc4_hvs_bind(struct device *dev, struct
> device *master, void *data)
> dev_err(>dev, "Couldn't get core clock\n");
> return PTR_ERR(hvs->core_clk);
> }
> +
> + ret = clk_prepare_enable(hvs->core_clk);
> + if (ret) {
> + dev_err(>dev, "Couldn't enable core clock\n");
> + return ret;
> + }
> }
>
> if (!hvs->hvs5)
> @@ -681,6 +687,8 @@ static void vc4_hvs_unbind(struct device *dev, struct
> device *master,
> drm_mm_takedown(>hvs->dlist_mm);
> drm_mm_takedown(>hvs->lbm_mm);
>
> + clk_prepare_enable(vc4->hvs->core_clk);
I'm sorry. Change to clk_disable_unprepare(vc4->hvs->core_clk);
> +
> vc4->hvs = NULL;
> }
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 03/78] drm/vc4: hvs: Boost the core clock during modeset
Hi Maxime,
On 7/9/20 2:41 AM, Maxime Ripard wrote:
> In order to prevent timeouts and stalls in the pipeline, the core clock
> needs to be maxed at 500MHz during a modeset on the BCM2711.
>
> Reviewed-by: Eric Anholt
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
> drivers/gpu/drm/vc4/vc4_hvs.c | 9 +
> drivers/gpu/drm/vc4/vc4_kms.c | 9 +
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index e4cde1f9224b..6358f6ca8d56 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -320,6 +320,8 @@ struct vc4_hvs {
> void __iomem *regs;
> u32 __iomem *dlist;
>
> + struct clk *core_clk;
> +
> /* Memory manager for CRTCs to allocate space in the display
>* list. Units are dwords.
>*/
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 836d8799d79e..091fdf4908aa 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -19,6 +19,7 @@
> * each CRTC.
> */
>
> +#include
> #include
> #include
>
> @@ -540,6 +541,14 @@ static int vc4_hvs_bind(struct device *dev, struct
> device *master, void *data)
> hvs->regset.regs = hvs_regs;
> hvs->regset.nregs = ARRAY_SIZE(hvs_regs);
>
> + if (hvs->hvs5) {
> + hvs->core_clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(hvs->core_clk)) {
> + dev_err(>dev, "Couldn't get core clock\n");
> + return PTR_ERR(hvs->core_clk);
> + }
> + }
> +
> if (!hvs->hvs5)
> hvs->dlist = hvs->regs + SCALER_DLIST_START;
> else
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 08318e69061b..210cc2408087 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -11,6 +11,8 @@
> * crtc, HDMI encoder).
> */
>
> +#include
> +
> #include
> #include
> #include
> @@ -149,6 +151,7 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
> {
> struct drm_device *dev = state->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> + struct vc4_hvs *hvs = vc4->hvs;
> struct vc4_crtc *vc4_crtc;
> int i;
>
> @@ -160,6 +163,9 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
> vc4_hvs_mask_underrun(dev, vc4_crtc->channel);
> }
>
> + if (vc4->hvs->hvs5)
> + clk_set_min_rate(hvs->core_clk, 5);
> +
> drm_atomic_helper_wait_for_fences(dev, state, false);
>
> drm_atomic_helper_wait_for_dependencies(state);
> @@ -182,6 +188,9 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
>
> drm_atomic_helper_commit_cleanup_done(state);
>
> + if (vc4->hvs->hvs5)
> + clk_set_min_rate(hvs->core_clk, 0);
> +
> drm_atomic_state_put(state);
>
> up(>async_modeset);
>
This patch doesn't control the enable/disable of core_clk.
So, I think that it need to handle the clock as following:
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 4ef88c0b51ab..355d67fd8beb 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -588,6 +588,12 @@ static int vc4_hvs_bind(struct device *dev, struct device
*master, void *data)
dev_err(>dev, "Couldn't get core clock\n");
return PTR_ERR(hvs->core_clk);
}
+
+ ret = clk_prepare_enable(hvs->core_clk);
+ if (ret) {
+ dev_err(>dev, "Couldn't enable core clock\n");
+ return ret;
+ }
}
if (!hvs->hvs5)
@@ -681,6 +687,8 @@ static void vc4_hvs_unbind(struct device *dev, struct
device *master,
drm_mm_takedown(>hvs->dlist_mm);
drm_mm_takedown(>hvs->lbm_mm);
+ clk_prepare_enable(vc4->hvs->core_clk);
+
vc4->hvs = NULL;
}
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 62/78] drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
ll working because I think that
vc4_hdmi->hsm_clock was already enabled on other side.
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> @@ -559,23 +589,9 @@ static enum drm_mode_status
> vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> const struct drm_display_mode *mode)
> {
> - /*
> - * As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock must
> - * be faster than pixel clock, infinitesimally faster, tested in
> - * simulation. Otherwise, exact value is unimportant for HDMI
> - * operation." This conflicts with bcm2835's vc4 documentation, which
> - * states HSM's clock has to be at least 108% of the pixel clock.
> - *
> - * Real life tests reveal that vc4's firmware statement holds up, and
> - * users are able to use pixel clocks closer to HSM's, namely for
> - * 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> - * both clocks. Which, for RPi0-3 implies a maximum pixel clock of
> - * 162MHz.
> - *
> - * Additionally, the AXI clock needs to be at least 25% of
> - * pixel clock, but HSM ends up being the limiting factor.
> - */
> - if (mode->clock > HSM_CLOCK_FREQ / (1000 * 101 / 100))
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> +
> + if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
> return MODE_CLOCK_HIGH;
>
> return MODE_OK;
> @@ -1349,23 +1365,6 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> return -EPROBE_DEFER;
> }
>
> - /* This is the rate that is set by the firmware. The number
> - * needs to be a bit higher than the pixel clock rate
> - * (generally 148.5Mhz).
> - */
> - ret = clk_set_rate(vc4_hdmi->hsm_clock, HSM_CLOCK_FREQ);
> - if (ret) {
> - DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
> - goto err_put_i2c;
> - }
> -
> - ret = clk_prepare_enable(vc4_hdmi->hsm_clock);
> - if (ret) {
> - DRM_ERROR("Failed to turn on HDMI state machine clock: %d\n",
> - ret);
> - goto err_put_i2c;
> - }
> -
> /* Only use the GPIO HPD pin if present in the DT, otherwise
>* we'll use the HDMI core's register.
>*/
> @@ -1413,9 +1412,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> err_destroy_encoder:
> drm_encoder_cleanup(encoder);
> err_unprepare_hsm:
> - clk_disable_unprepare(vc4_hdmi->hsm_clock);
> pm_runtime_disable(dev);
> -err_put_i2c:
> put_device(_hdmi->ddc->dev);
>
> return ret;
> @@ -1454,7 +1451,6 @@ static void vc4_hdmi_unbind(struct device *dev, struct
> device *master,
> vc4_hdmi_connector_destroy(_hdmi->connector);
> drm_encoder_cleanup(_hdmi->encoder.base.base);
>
> - clk_disable_unprepare(vc4_hdmi->hsm_clock);
> pm_runtime_disable(dev);
>
> put_device(_hdmi->ddc->dev);
> @@ -1479,6 +1475,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> static const struct vc4_hdmi_variant bcm2835_variant = {
> .encoder_type = VC4_ENCODER_TYPE_HDMI0,
> .debugfs_name = "hdmi_regs",
> + .max_pixel_clock = 16200,
> .cec_available = true,
> .registers = vc4_hdmi_fields,
> .num_registers = ARRAY_SIZE(vc4_hdmi_fields),
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 3f07aebe89f1..342f6e0227a2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -36,6 +36,9 @@ struct vc4_hdmi_variant {
> /* Set to true when the CEC support is available */
> bool cec_available;
>
> + /* Maximum pixel clock supported by the controller (in Hz) */
> + unsigned long long max_pixel_clock;
> +
> /* List of the registers available on that variant */
> const struct vc4_hdmi_register *registers;
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 75/78] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
Hi Maxime,
On 7/9/20 2:42 AM, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109
> -
> 1 file changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> new file mode 100644
> index ..6091fe3d315b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -0,0 +1,109 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id:
> https://protect2.fireeye.com/url?k=556aeb05-08b8fda0-556b604a-0cc47a31bee8-c3a0ebd1d22c3183=1=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbrcm%2Cbcm2711-hdmi.yaml%23
> +$schema:
> https://protect2.fireeye.com/url?k=24fa660c-792870a9-24fbed43-0cc47a31bee8-0bf16f4fd60f0ab4=1=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Eric Anholt
> +
> +properties:
> + compatible:
> +enum:
> + - brcm,bcm2711-hdmi0
> + - brcm,bcm2711-hdmi1
> +
> + reg:
> +items:
> + - description: HDMI controller register range
> + - description: DVP register range
> + - description: HDMI PHY register range
> + - description: Rate Manager register range
> + - description: Packet RAM register range
> + - description: Metadata RAM register range
> + - description: CSC register range
> + - description: CEC register range
> + - description: HD register range
> +
> + reg-names:
> +items:
> + - const: hdmi
> + - const: dvp
> + - const: phy
> + - const: rm
> + - const: packet
> + - const: metadata
> + - const: csc
> + - const: cec
> + - const: hd
> +
> + clocks:
> +description: The HDMI state machine clock
I'm not sure the following description is correct.
But, this description doesn't contain the information of audio clock.
description: The HDMI state machine and audio clock
> +
> + clock-names:
> +const: hdmi
This patch is missing the following clock information for audio clock.
const: clk-108M
> +
> + ddc:
> +allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
> +description: >
> + Phandle of the I2C controller used for DDC EDID probing
> +
> + hpd-gpios:
> +description: >
> + The GPIO pin for the HDMI hotplug detect (if it doesn't appear
> + as an interrupt/status bit in the HDMI controller itself)
> +
> + dmas:
> +maxItems: 1
> +description: >
> + Should contain one entry pointing to the DMA channel used to
> + transfer audio data.
> +
> + dma-names:
> +const: audio-rx
> +
> + resets:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - resets
> + - ddc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi0: hdmi@7ef00700 {
> +compatible = "brcm,bcm2711-hdmi0";
> +reg = <0x7ef00700 0x300>,
> + <0x7ef00300 0x200>,
> + <0x7ef00f00 0x80>,
> + <0x7ef00f80 0x80>,
> + <0x7ef01b00 0x200>,
> + <0x7ef01f00 0x400>,
> + <0x7ef00200 0x80>,
> + <0x7ef04300 0x100>,
> + <0x7ef2 0x100>;
> +reg-names = "hdmi",
> +"dvp",
> +"phy",
> +"rm",
> + "packet",
> +"metadata",
> +"csc",
> +"cec",
> +"hd";
> +clocks = <_clocks 13>;
> +clock-names = "hdmi";
Also, this example doesn't include the instance of audio clock.
Need to edit them as following:
clock-names = "hdmi", "clk-108M";
clocks = <_clocks 13>, < 0>;
> +resets = < 0>;
> +ddc = <>;
> +};
> +
> +...
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/vc4: hdmi: Add pixel bvb clock control
Hi Hoegeun,
It looks good to me. But, just one comment.
On 9/1/20 1:07 PM, Hoegeun Kwon wrote:
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
>
> Signed-off-by: Hoegeun Kwon
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 95ec5eedea39..eb3192d1fd86 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -80,6 +80,7 @@
> # define VC4_HD_M_ENABLE BIT(0)
>
> #define CEC_CLOCK_FREQ 4
> +#define VC4_HSM_MID_CLOCK 149985000
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
> drm_encoder *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
> clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder)
> return;
> }
>
> + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
> + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
> + if (ret) {
> + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
Generally, enable the clock before using clk and then change the clock rate.
I think that you better to change the order between clk_prepare_enable and
clk_set_rate.
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->audio_clock);
> }
>
> + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> + DRM_ERROR("Failed to get pixel bvb clock\n");
> + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> + }
> +
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(vc4_hdmi->reset)) {
> DRM_ERROR("Failed to get HDMI reset line\n");
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0806c6d9f24e..63c6f8bddf1d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -147,6 +147,7 @@ struct vc4_hdmi {
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> struct clk *audio_clock;
> + struct clk *pixel_bvb_clock;
>
> struct reset_control *reset;
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline
> drivers/gpu/drm/vc4/vc4_kms.c | > 225 +- > drivers/gpu/drm/vc4/vc4_plane.c | > 222 +++--- > drivers/gpu/drm/vc4/vc4_regs.h | > 177 +++- > drivers/gpu/drm/vc4/vc4_txp.c | > 4 +- > 19 files changed, 3331 insertions(+), 1008 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml > create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.h > create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_phy.c > create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_regs.h > > base-commit: 5bdd2824d705fb8d339d6f96e464b907c9a1553d > I tested it for stress test with reboot command repetitively for verifying this patchset. It is well working. Tested-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 13/36] PM / devfreq: tegra30: Use MC timings for building OPP table
Hi,
On 8/15/20 1:47 AM, Dmitry Osipenko wrote:
> 14.08.2020 05:02, Chanwoo Choi пишет:
>> Hi Dmitry,
>>
>> I add the minor comment. Except of some comments, it looks good to me.
>
> Hello, Chanwoo! Thank you for the review!
>
> ...
>>> +struct tegra_devfreq_soc_data {
>>> + const char *mc_compatible;
>>> +};
>>> +
>>> +static const struct tegra_devfreq_soc_data tegra30_soc = {
>>> + .mc_compatible = "nvidia,tegra30-mc",
>>> +};
>>> +
>>> +static const struct tegra_devfreq_soc_data tegra124_soc = {
>>> + .mc_compatible = "nvidia,tegra124-mc",
>>> +};
> .
>>> + soc_data = of_device_get_match_data(>dev);
>>
>> I think that better to check whether 'soc_data' is not NULL.
>
> It's a quite common misconception among kernel developers that
> of_device_get_match_data() may "accidentally" return NULL, but it
> couldn't if every driver's of_match[] entry has a non-NULL .data field
> and because the OF-matching already happened at the driver's probe-time
> [1], which is the case of this driver.
>
> [1] https://elixir.bootlin.com/linux/v5.8/source/drivers/of/device.c#L189
>
> Hence the NULL-checking is unnecessary.
>
> When I first encountered the of_device_get_match_data(), I was also
> thinking that adding the NULL-checks is a good idea, but later on
> somebody pointed out to me (maybe Thierry) that it's unnecessary to do.
OK. Thanks.
>
>>> +
>>> + mc = tegra_get_memory_controller(soc_data->mc_compatible);
>>> + if (IS_ERR(mc))
>>> + return PTR_ERR(mc);
>>
>> You better to add error log.
>
> In practice we should get only -EPROBE_DEFER here ever. I'll consider
> adding the message in the next revision, at least just for consistency.
In order to handle -EPROBE_DEFER, recommend the using of dev_err_probe().
(snip)
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 13/36] PM / devfreq: tegra30: Use MC timings for building OPP table
t; ARRAY_SIZE(actmon_device_configs); i++) {
> dev = tegra->devices + i;
> dev->config = actmon_device_configs + i;
> dev->regs = tegra->regs + dev->config->offset;
> }
>
> - for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
> - rate = clk_round_rate(tegra->emc_clock, rate);
> -
> - if (rate < 0) {
> - dev_err(>dev,
> - "Failed to round clock rate: %ld\n", rate);
> - err = rate;
> - goto remove_opps;
> - }
> -
> - err = dev_pm_opp_add(>dev, rate / KHZ, 0);
> - if (err) {
> - dev_err(>dev, "Failed to add OPP: %d\n", err);
> - goto remove_opps;
> - }
> - }
> -
> platform_set_drvdata(pdev, tegra);
>
> tegra->clk_rate_change_nb.notifier_call = tegra_actmon_clk_notify_cb;
> @@ -921,8 +958,8 @@ 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" },
> + { .compatible = "nvidia,tegra30-actmon", .data = _soc, },
> + { .compatible = "nvidia,tegra124-actmon", .data = _soc, },
> { },
> };
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 12/36] PM / devfreq: tegra20: Use MC timings for building OPP table
Hi Dmitry,
On 8/14/20 9:05 AM, Dmitry Osipenko wrote:
> The clk_round_rate() won't be usable for building OPP table once
> interconnect support will be added to the EMC driver because that CLK API
> function limits the rounded rate based on the clk rate that is imposed by
> active clk-users, and thus, the rounding won't work as expected if
> interconnect will set the minimum EMC clock rate before devfreq driver is
> loaded. The struct tegra_mc contains memory timings which could be used by
> the devfreq driver for building up OPP table instead of rounding clock
> rate, this patch implements this idea.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index 6469dc69c5e0..a985f24098f5 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> {
> struct tegra_devfreq *tegra;
> struct tegra_mc *mc;
> - unsigned long max_rate;
> - unsigned long rate;
> + unsigned int i;
> int err;
>
> mc = tegra_get_memory_controller();
> @@ -135,6 +134,11 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + if (!mc->num_timings) {
> + dev_info(>dev, "memory controller has no timings\n");
> + return -ENODEV;
> + }
> +
> tegra = devm_kzalloc(>dev, sizeof(*tegra), GFP_KERNEL);
> if (!tegra)
> return -ENOMEM;
> @@ -151,12 +155,8 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> tegra->regs = mc->regs;
>
> - max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
> -
> - for (rate = 0; rate <= max_rate; rate++) {
> - rate = clk_round_rate(tegra->emc_clock, rate);
> -
> - err = dev_pm_opp_add(>dev, rate, 0);
> + for (i = 0; i < mc->num_timings; i++) {
> + err = dev_pm_opp_add(>dev, mc->timings[i].rate, 0);
> if (err) {
> dev_err(>dev, "failed to add opp: %d\n", err);
> goto remove_opps;
>
Ackded-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
Hi Sylwester, On 7/3/20 1:37 AM, Sylwester Nawrocki wrote: > Add documentation for new optional properties in the exynos bus nodes: > samsung,interconnect-parent, #interconnect-cells, bus-width. > These properties allow to specify the SoC interconnect structure which > then allows the interconnect consumer devices to request specific > bandwidth requirements. > > Signed-off-by: Artur Świgoń > Signed-off-by: Sylwester Nawrocki > --- > Changes for v6: > - added dts example of bus hierarchy definition and the interconnect >consumer, > - added new bus-width property. > > Changes for v5: > - exynos,interconnect-parent-node renamed to samsung,interconnect-parent > --- > .../devicetree/bindings/devfreq/exynos-bus.txt | 68 > +- > 1 file changed, 66 insertions(+), 2 deletions(-) Acked-by: Chanwoo Choi (snip) -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 16/37] PM / devfreq: tegra20: Adjust clocks conversion ratio and polling interval
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> The current conversion ratio results in a higher frequency than needed,
> that is not very actual now since the Display Controller driver got
> support for memory bandwidth management and hence memory frequency can
> go lower now without bad consequences. Since memory freq now goes to a
> lower rates, the responsiveness of interactive applications become worse
> due to a quite high polling interval value that is currently set to 500ms.
> Changing polling interval to 30ms results in a good responsiveness of the
> system.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index 249d0dc44f6c..7cdea4ba38f7 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -79,16 +79,12 @@ static int tegra_devfreq_get_dev_status(struct device
> *dev,
>
> /*
>* EMC_COUNT returns number of memory events, that number is lower
> - * than the number of clocks. Conversion ratio of 1/8 results in a
> - * bit higher bandwidth than actually needed, it is good enough for
> - * the time being because drivers don't support requesting minimum
> - * needed memory bandwidth yet.
> - *
> - * TODO: adjust the ratio value once relevant drivers will support
> - * memory bandwidth management.
> + * than the number of total EMC clocks over the sampling period.
> + * The clocks number is converted to maximum possible number of
> + * memory events using the ratio of 1/4.
>*/
> stat->busy_time = readl_relaxed(tegra->regs + MC_STAT_EMC_COUNT);
> - stat->total_time = readl_relaxed(tegra->regs + MC_STAT_EMC_CLOCKS) / 8;
> + stat->total_time = readl_relaxed(tegra->regs + MC_STAT_EMC_CLOCKS) / 4;
> stat->current_frequency = clk_get_rate(tegra->emc_clock);
>
> writel_relaxed(EMC_GATHER_CLEAR, tegra->regs + MC_STAT_CONTROL);
> @@ -98,7 +94,7 @@ static int tegra_devfreq_get_dev_status(struct device *dev,
> }
>
> static struct devfreq_dev_profile tegra_devfreq_profile = {
> - .polling_ms = 500,
> + .polling_ms = 30,
> .target = tegra_devfreq_target,
> .get_dev_status = tegra_devfreq_get_dev_status,
> };
>
Ackded-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/37] PM / devfreq: tegra20: Silence deferred probe error
Hi Dmitry,
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> Tegra EMC driver was turned into a regular kernel driver, it also could
> be compiled as a loadable kernel module now. Hence EMC clock isn't
Looks good to me. But, you better to add the commit information
about Tegra EMC driver with commit-id ("patch title") format
into patch descritpion.
> guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER and
> there is no good reason to spam KMSG with a error about missing EMC clock
> in this case, so let's silence the deferred probe error.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index ff82bac9ee4e..6469dc69c5e0 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -141,9 +141,11 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> /* EMC is a system-critical clock that is always enabled */
> tegra->emc_clock = devm_clk_get(>dev, "emc");
> - if (IS_ERR(tegra->emc_clock)) {
> - err = PTR_ERR(tegra->emc_clock);
> - dev_err(>dev, "failed to get emc clock: %d\n", err);
> + err = PTR_ERR_OR_ZERO(tegra->emc_clock);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(>dev, "failed to get emc clock: %d\n",
> + err);
> return err;
> }
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/37] PM / devfreq: tegra20: Silence deferred probe error
On 7/2/20 9:56 AM, Chanwoo Choi wrote:
> Hi Dmitry,
>
> On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
>> Tegra EMC driver was turned into a regular kernel driver, it also could
>> be compiled as a loadable kernel module now. Hence EMC clock isn't
>
> Looks good to me. But, you better to add the commit information
> about Tegra EMC driver with commit-id ("patch title") format
> into patch descritpion.
>
>> guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER and
>> there is no good reason to spam KMSG with a error about missing EMC clock
>> in this case, so let's silence the deferred probe error.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/devfreq/tegra20-devfreq.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/devfreq/tegra20-devfreq.c
>> b/drivers/devfreq/tegra20-devfreq.c
>> index ff82bac9ee4e..6469dc69c5e0 100644
>> --- a/drivers/devfreq/tegra20-devfreq.c
>> +++ b/drivers/devfreq/tegra20-devfreq.c
>> @@ -141,9 +141,11 @@ static int tegra_devfreq_probe(struct platform_device
>> *pdev)
>>
>> /* EMC is a system-critical clock that is always enabled */
>> tegra->emc_clock = devm_clk_get(>dev, "emc");
>> -if (IS_ERR(tegra->emc_clock)) {
>> -err = PTR_ERR(tegra->emc_clock);
>> -dev_err(>dev, "failed to get emc clock: %d\n", err);
>> +err = PTR_ERR_OR_ZERO(tegra->emc_clock);
>> +if (err) {
>> +if (err != -EPROBE_DEFER)
>> +dev_err(>dev, "failed to get emc clock: %d\n",
>> +err);
>> return err;
>> }
>>
>>
>
>
The Tegra EMC drive is included in this patchset.
So, don't need to mention the commit info.
Looks good to me.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/37] PM / devfreq: tegra30: Silence deferred probe error
On 7/2/20 10:20 AM, Dmitry Osipenko wrote:
> 02.07.2020 03:59, Chanwoo Choi пишет:
>> Hi,
>>
>> On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
>>> Tegra EMC driver was turned into a regular kernel driver, it also could
>>> be compiled as a loadable kernel module now. Hence EMC clock isn't
>>> guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER and
>>> there is no good reason to spam KMSG with a error about missing EMC clock
>>> in this case, so let's silence the deferred probe error.
>>>
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/devfreq/tegra30-devfreq.c | 9 ++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/tegra30-devfreq.c
>>> b/drivers/devfreq/tegra30-devfreq.c
>>> index e94a27804c20..423dd35c95b3 100644
>>> --- a/drivers/devfreq/tegra30-devfreq.c
>>> +++ b/drivers/devfreq/tegra30-devfreq.c
>>> @@ -801,9 +801,12 @@ static int tegra_devfreq_probe(struct platform_device
>>> *pdev)
>>> }
>>>
>>> tegra->emc_clock = devm_clk_get(>dev, "emc");
>>> - if (IS_ERR(tegra->emc_clock)) {
>>> - dev_err(>dev, "Failed to get emc clock\n");
>>> - return PTR_ERR(tegra->emc_clock);
>>> + err = PTR_ERR_OR_ZERO(tegra->emc_clock);
>>> + if (err) {
>>> + if (err != -EPROBE_DEFER)
>>> + dev_err(>dev, "Failed to get emc clock: %d\n",
>>> + err);
>>> + return err;
>>> }
>>>
>>> err = platform_get_irq(pdev, 0);
>>>
>>
>> As I commented on patch10, I recommend that you add the Tegra EMC driver
>> commit information into patch description and Looks good to me.
>>
>
> Hello, Chanwoo!
>
> This patch11 and patch10 are depending on the patches 4/5 (the Tegra EMC
> driver patches) of *this* series, hence there is no commit information.
> I'm expecting that this whole series will go via tegra tree once all the
> patches will be reviewed and collect all the necessary acks from you,
> ICC and CLK subsystem maintainers.
>
> Please feel free to give yours ack to the patches 10/11 if they are good
> to you :)
>
>
OK. Looks good to me
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/37] PM / devfreq: tegra30: Silence deferred probe error
Hi,
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> Tegra EMC driver was turned into a regular kernel driver, it also could
> be compiled as a loadable kernel module now. Hence EMC clock isn't
> guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER and
> there is no good reason to spam KMSG with a error about missing EMC clock
> in this case, so let's silence the deferred probe error.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index e94a27804c20..423dd35c95b3 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -801,9 +801,12 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> }
>
> tegra->emc_clock = devm_clk_get(>dev, "emc");
> - if (IS_ERR(tegra->emc_clock)) {
> - dev_err(>dev, "Failed to get emc clock\n");
> - return PTR_ERR(tegra->emc_clock);
> + err = PTR_ERR_OR_ZERO(tegra->emc_clock);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(>dev, "Failed to get emc clock: %d\n",
> + err);
> + return err;
> }
>
> err = platform_get_irq(pdev, 0);
>
As I commented on patch10, I recommend that you add the Tegra EMC driver
commit information into patch description and Looks good to me.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 15/37] PM / devfreq: tegra30: Add error messages to tegra_devfreq_target()
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> It's useful to now when something goes wrong instead of failing silently,
> so let's add error messages to tegra_devfreq_target() to prevent situation
> where it fails silently.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 13f93c6038ab..a03fb16c5c4c 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -641,12 +641,16 @@ static int tegra_devfreq_target(struct device *dev,
> unsigned long *freq,
> dev_pm_opp_put(opp);
>
> err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
> - if (err)
> + if (err) {
> + dev_err(dev, "Failed to set min rate: %d\n", err);
> return err;
> + }
>
> err = clk_set_rate(tegra->emc_clock, 0);
> - if (err)
> + if (err) {
> + dev_err(dev, "Failed to set rate: %d\n", err);
> goto restore_min_rate;
> + }
>
> return 0;
>
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 17/37] PM / devfreq: tegra20: Relax Kconfig dependency
On 6/9/20 10:13 PM, Dmitry Osipenko wrote: > The Tegra EMC driver now could be compiled as a loadable kernel module. > Currently devfreq driver depends on the EMC/MC drivers in Kconfig, and > thus, devfreq is forced to be a kernel module if EMC is compiled as a > module. This build dependency could be relaxed since devfreq driver > checks MC/EMC presence on probe, allowing kernel configuration where > devfreq is a built-in driver and EMC driver is a loadable module. > This change puts Tegra20 devfreq Kconfig entry on a par with the Tegra30 > devfreq entry. > > 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 37dc40d1fcfb..0ee36ae2fa79 100644 > --- a/drivers/devfreq/Kconfig > +++ b/drivers/devfreq/Kconfig > @@ -123,7 +123,7 @@ config ARM_TEGRA_DEVFREQ > > config ARM_TEGRA20_DEVFREQ > tristate "NVIDIA Tegra20 DEVFREQ Driver" > - depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST > + depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST > depends on COMMON_CLK > select DEVFREQ_GOV_SIMPLE_ONDEMAND > help > Acked-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 14/37] PM / devfreq: tegra20: Add error messages to tegra_devfreq_target()
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> It's useful to now when something goes wrong instead of failing silently,
> so let's add error messages to tegra_devfreq_target() to prevent situation
> where it fails silently.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index bf504ca4dea2..249d0dc44f6c 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -44,19 +44,25 @@ static int tegra_devfreq_target(struct device *dev,
> unsigned long *freq,
> int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> - if (IS_ERR(opp))
> + if (IS_ERR(opp)) {
> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
> return PTR_ERR(opp);
> + }
>
> rate = dev_pm_opp_get_freq(opp);
> dev_pm_opp_put(opp);
>
> err = clk_set_min_rate(tegra->emc_clock, rate);
> - if (err)
> + if (err) {
> + dev_err(dev, "failed to set min rate: %d\n", err);
> return err;
> + }
>
> err = clk_set_rate(tegra->emc_clock, 0);
> - if (err)
> + if (err) {
> + dev_err(dev, "failed to set rate: %d\n", err);
> goto restore_min_rate;
> + }
>
> return 0;
>
>
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 12/37] PM / devfreq: tegra20: Use MC timings for building OPP table
Hi Dmitry,
On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
> The clk_round_rate() won't be usable for building OPP table once
> interconnect support will be added to the EMC driver because that CLK API
> function limits the rounded rate based on the clk rate that is imposed by
> active clk-users, and thus, the rounding won't work as expected if
> interconnect will set the minimum EMC clock rate before devfreq driver is
> loaded. The struct tegra_mc contains memory timings which could be used by
> the devfreq driver for building up OPP table instead of rounding clock
> rate, this patch implements this idea.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra20-devfreq.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index 6469dc69c5e0..bf504ca4dea2 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> {
> struct tegra_devfreq *tegra;
> struct tegra_mc *mc;
> - unsigned long max_rate;
> - unsigned long rate;
> + unsigned int i;
> int err;
>
> mc = tegra_get_memory_controller();
> @@ -151,12 +150,17 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
>
> tegra->regs = mc->regs;
>
> - max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
> -
> - for (rate = 0; rate <= max_rate; rate++) {
> - rate = clk_round_rate(tegra->emc_clock, rate);
> + if (!mc->num_timings) {
Could you explain what is meaning of 'num_timing?
Also, why add the opp entry in case of mc->num_timings is zero?
> + err = dev_pm_opp_add(>dev,
> + clk_get_rate(tegra->emc_clock), 0);
> + if (err) {
> + dev_err(>dev, "failed to add OPP: %d\n", err);
> + return err;
> + }
> + }
>
> - err = dev_pm_opp_add(>dev, rate, 0);
> + for (i = 0; i < mc->num_timings; i++) {
> + err = dev_pm_opp_add(>dev, mc->timings[i].rate, 0);
> if (err) {
> dev_err(>dev, "failed to add opp: %d\n", err);
> goto remove_opps;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 12/37] PM / devfreq: tegra20: Use MC timings for building OPP table
On 7/2/20 2:07 PM, Dmitry Osipenko wrote:
> 02.07.2020 07:18, Chanwoo Choi пишет:
>> Hi Dmitry,
>>
>> On 6/9/20 10:13 PM, Dmitry Osipenko wrote:
>>> The clk_round_rate() won't be usable for building OPP table once
>>> interconnect support will be added to the EMC driver because that CLK API
>>> function limits the rounded rate based on the clk rate that is imposed by
>>> active clk-users, and thus, the rounding won't work as expected if
>>> interconnect will set the minimum EMC clock rate before devfreq driver is
>>> loaded. The struct tegra_mc contains memory timings which could be used by
>>> the devfreq driver for building up OPP table instead of rounding clock
>>> rate, this patch implements this idea.
>>>
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/devfreq/tegra20-devfreq.c | 18 +++---
>>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/tegra20-devfreq.c
>>> b/drivers/devfreq/tegra20-devfreq.c
>>> index 6469dc69c5e0..bf504ca4dea2 100644
>>> --- a/drivers/devfreq/tegra20-devfreq.c
>>> +++ b/drivers/devfreq/tegra20-devfreq.c
>>> @@ -123,8 +123,7 @@ static int tegra_devfreq_probe(struct platform_device
>>> *pdev)
>>> {
>>> struct tegra_devfreq *tegra;
>>> struct tegra_mc *mc;
>>> - unsigned long max_rate;
>>> - unsigned long rate;
>>> + unsigned int i;
>>> int err;
>>>
>>> mc = tegra_get_memory_controller();
>>> @@ -151,12 +150,17 @@ static int tegra_devfreq_probe(struct platform_device
>>> *pdev)
>>>
>>> tegra->regs = mc->regs;
>>>
>>> - max_rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
>>> -
>>> - for (rate = 0; rate <= max_rate; rate++) {
>>> - rate = clk_round_rate(tegra->emc_clock, rate);
>>> + if (!mc->num_timings) {
>>
>> Could you explain what is meaning of 'num_timing?
>
> The num_timings is the number of memory timings defined in a
> device-tree. One timing configuration per memory clock rate.
OK. I understand.
>
>> Also, why add the opp entry in case of mc->num_timings is zero?
>
> Timings may be not defined in some device-trees at all and in this case
> memory always running on a fixed clock rate.
You mean that 'timings' information is optional?
>
> The devfreq driver won't be practically useful if mc->num_timings is
> zero since memory frequency can't be changed, but anyways we'd want to
> load the devfreq driver in order to prevent confusion about why it's not
> loaded.
>
> For example, you may ask somebody to show contents of
> /sys/class/devfreq/tegra20-devfreq/trans_stat and the person says to you
> that this file doesn't exist, now you'll have to figure out what
> happened to the devfreq driver.
I understand why add OPP entry point when timing is not defined on DT.
But, actually, I think that you better to change 'timings' info is mandatory
instead of optional. Because the devfreq driver is for DVFS
and the driver supporting DVFS have to have the frequency information
like OPP.
Or,
If you want to keep 'timing' is optional on DT,
I recommend that you add one timing data to tegra mc driver
when DT doesn't include the any timing information
I think that is it more clear.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Hi Sylwester,
On 6/1/20 7:04 PM, Sylwester Nawrocki wrote:
> Cc: Rob, devicetree ML
>
> On 31.05.2020 01:57, Chanwoo Choi wrote:
>> On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
>> wrote:
>>>
>>> This patch adds registration of a child platform device for the exynos
>>> interconnect driver. It is assumed that the interconnect provider will
>>> only be needed when #interconnect-cells property is present in the bus
>>> DT node, hence the child device will be created only when such a property
>>> is present.
>>>
>>> Signed-off-by: Sylwester Nawrocki
>>>
>>> Changes for v5:
>>> - new patch.
>>> ---
>>> drivers/devfreq/exynos-bus.c | 17 +
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 8fa8eb5..856e37d 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -24,6 +24,7 @@
>>>
>>> struct exynos_bus {
>>> struct device *dev;
>>> + struct platform_device *icc_pdev;
>>>
>>> struct devfreq *devfreq;
>>> struct devfreq_event_dev **edev;
>>> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
>>> if (ret < 0)
>>> dev_warn(dev, "failed to disable the devfreq-event
>>> devices\n");
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> if (bus->opp_table) {
>>> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
>>> {
>>> struct exynos_bus *bus = dev_get_drvdata(dev);
>>>
>>> + platform_device_unregister(bus->icc_pdev);
>>> +
>>> dev_pm_opp_of_remove_table(dev);
>>> clk_disable_unprepare(bus->clk);
>>> }
>>> @@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device
>>> *pdev)
>>> if (ret < 0)
>>> goto err;
>>>
>>> + /* Create child platform device for the interconnect provider */
>>> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
>>> + bus->icc_pdev = platform_device_register_data(
>>> + dev, "exynos-generic-icc",
>>> + PLATFORM_DEVID_AUTO, NULL,
>>> 0);
>>> +
>>> + if (IS_ERR(bus->icc_pdev)) {
>>> + ret = PTR_ERR(bus->icc_pdev);
>>> + goto err;
>>> + }
>>> + }
>>> +
>>> max_state = bus->devfreq->profile->max_state;
>>> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
>>> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] /
>>> 1000);
>>> --
>>> 2.7.4
>>>
>>
>> It looks like very similar like the registering the interconnect
>> device of imx-bus.c
>> and I already reviewed and agreed this approach.
>>
>> Acked-by: Chanwoo Choi
>>
>> nitpick: IMHO, I think that 'exynos-icc' is proper and simple without
>> 'generic' word.
>> If we need to add new icc compatible int the future, we will add
>> 'exynos-icc' new compatible.
>> But, I'm not forcing it. just opinion. Anyway, I agree this approach.
>
> Thanks for review. I will change the name to exynos-icc in next version,
> as I commented at other patch, it is not part of any DT binding,
> it is just for device/driver matching between devfreq and interconnect.
Thanks. I have not any objection to use either 'exynos-generic-icc'
or 'exynos-icc'. It is just my opinion. And on next version,
please add linux-pm mailing list to Cc.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 6/6] drm: exynos: mixer: Add interconnect support
Hi Sylwester,
On 5/30/20 1:32 AM, Sylwester Nawrocki wrote:
> From: Marek Szyprowski
>
> This patch adds interconnect support to exynos-mixer. The mixer works
> the same as before when CONFIG_INTERCONNECT is 'n'.
>
> For proper operation of the video mixer block we need to ensure the
> interconnect busses like DMC or LEFTBUS provide enough bandwidth so
> as to avoid DMA buffer underruns in the mixer block. i.e we need to
> prevent those busses from operating in low perfomance OPPs when
> the mixer is running.
> In this patch the bus bandwidth request is done through the interconnect
> API, the bandiwidth value is calculated from selected DRM mode, i.e.
> video plane width, height, refresh rate and pixel format.
>
> Co-developed-by: Artur Świgoń
> Signed-off-by: Marek Szyprowski
> [s.nawrocki: renamed soc_path variable to icc_path, edited commit desc.]
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes for v5:
> - renamed soc_path variable to icc_path
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 73
> ---
> 1 file changed, 68 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 21b726b..bdae683 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -98,6 +99,7 @@ struct mixer_context {
> struct exynos_drm_crtc *crtc;
> struct exynos_drm_plane planes[MIXER_WIN_NR];
> unsigned long flags;
> + struct icc_path *icc_path;
>
> int irq;
> void __iomem*mixer_regs;
> @@ -934,6 +936,42 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
> *crtc)
> mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
> }
>
> +static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
> +{
> + struct drm_display_mode *mode = >base.state->adjusted_mode;
> + struct mixer_context *ctx = crtc->ctx;
> + unsigned long bw, bandwidth = 0;
> + u32 avg_bw, peak_bw;
> + int i, j, sub;
> +
> + if (!ctx->icc_path)
> + return;
> +
> + for (i = 0; i < MIXER_WIN_NR; i++) {
> + struct drm_plane *plane = >planes[i].base;
> + const struct drm_format_info *format;
> +
> + if (plane->state && plane->state->crtc && plane->state->fb) {
> + format = plane->state->fb->format;
> + bw = mode->hdisplay * mode->vdisplay *
> + drm_mode_vrefresh(mode);
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + bw /= 2;
> + for (j = 0; j < format->num_planes; j++) {
> + sub = j ? (format->vsub * format->hsub) : 1;
> + bandwidth += format->cpp[j] * bw / sub;
First of all, I agree this approach.
Could you please add more detailed comments for understadning
about this calculation? As you commented, it seems that
the final bandwidth contains the width/height/refresh rate
and pixel format. If you add one real example, it will be very helpful.
(snip)
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
registered.
> +*/
> + ret = dev_pm_qos_add_request(bus_dev, >qos_req,
> +DEV_PM_QOS_MIN_FREQUENCY, 0);
> + if (ret < 0)
> + goto err_link_destroy;
> +
> + return 0;
> +
> +err_link_destroy:
> + if (icc_parent_node)
> + icc_link_destroy(icc_node, icc_parent_node);
> +err_node_del:
> + icc_nodes_remove(provider);
> +err_prov_del:
> + icc_provider_del(provider);
> +
> + return ret;
> +}
> +
> +static struct platform_driver exynos_generic_icc_driver = {
> + .driver = {
> + .name = "exynos-generic-icc",
> + },
> + .probe = exynos_generic_icc_probe,
> + .remove = exynos_generic_icc_remove,
> +};
> +module_platform_driver(exynos_generic_icc_driver);
> +
> +MODULE_DESCRIPTION("Exynos generic interconnect driver");
> +MODULE_AUTHOR("Artur Świgoń ");
> +MODULE_AUTHOR("Sylwester Nawrocki ");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:exynos-generic-icc");
> --
> 2.7.4
>
Reviewed-by: Chanwoo Choi
As I commented, How about changing the compatible name 'exynos-icc'
without 'generic'?
The 'exynos-icc' doesn't have the any specific version of Exynos SoC,
it think that it already contain the 'generic' meaning for Exynos SoC.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 5/6] ARM: dts: exynos: Add interconnects to Exynos4412 mixer
Hi Sylwester, On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki wrote: > > From: Artur Świgoń > > This patch adds an 'interconnects' property to Exynos4412 DTS in order to > declare the interconnect path used by the mixer. Please note that the > 'interconnect-names' property is not needed when there is only one path in > 'interconnects', in which case calling of_icc_get() with a NULL name simply > returns the right path. > > Signed-off-by: Artur Świgoń > Reviewed-by: Chanwoo Choi > --- > Changes for v5: > - none. > --- > arch/arm/boot/dts/exynos4412.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/exynos4412.dtsi > b/arch/arm/boot/dts/exynos4412.dtsi > index a7496d3..eee86d2 100644 > --- a/arch/arm/boot/dts/exynos4412.dtsi > +++ b/arch/arm/boot/dts/exynos4412.dtsi > @@ -776,6 +776,7 @@ > clock-names = "mixer", "hdmi", "sclk_hdmi", "vp"; > clocks = < CLK_MIXER>, < CLK_HDMI>, > < CLK_SCLK_HDMI>, < CLK_VP>; > + interconnects = <_display _dmc>; I think it is really good and necessary in order to support the minimum bandwidth. Until now, I had to add the additional code to support for this same purpose into product code. Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 4/6] ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
Hi Sylwester, On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki wrote: > > This patch adds the following properties for Exynos4412 interconnect > bus nodes: > - samsung,interconnect-parent: to declare connections between >nodes in order to guarantee PM QoS requirements between nodes; > - #interconnect-cells: required by the interconnect framework. > > Note that #interconnect-cells is always zero and node IDs are not > hardcoded anywhere. > > Signed-off-by: Artur Świgoń > Signed-off-by: Sylwester Nawrocki > --- > Changes for v5: > - adjust to renamed exynos,interconnect-parent-node property, > - add properties in common exynos4412.dtsi file rather than >in Odroid specific odroid4412-odroid-common.dtsi. > --- > arch/arm/boot/dts/exynos4412.dtsi | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/boot/dts/exynos4412.dtsi > b/arch/arm/boot/dts/exynos4412.dtsi > index 4886894..a7496d3 100644 > --- a/arch/arm/boot/dts/exynos4412.dtsi > +++ b/arch/arm/boot/dts/exynos4412.dtsi > @@ -381,6 +381,7 @@ > clocks = < CLK_DIV_DMC>; > clock-names = "bus"; > operating-points-v2 = <_dmc_opp_table>; > + #interconnect-cells = <0>; > status = "disabled"; > }; > > @@ -450,6 +451,8 @@ > clocks = < CLK_DIV_GDL>; > clock-names = "bus"; > operating-points-v2 = <_leftbus_opp_table>; > + samsung,interconnect-parent = <_dmc>; > + #interconnect-cells = <0>; > status = "disabled"; > }; > > @@ -466,6 +469,8 @@ > clocks = < CLK_ACLK160>; > clock-names = "bus"; > operating-points-v2 = <_display_opp_table>; > + samsung,interconnect-parent = <_leftbus>; > + #interconnect-cells = <0>; > status = "disabled"; > }; > > -- > 2.7.4 > Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
Hi Sylwester,
On Sat, May 30, 2020 at 1:32 AM Sylwester Nawrocki
wrote:
>
> Add documentation for new optional properties in the exynos bus nodes:
> samsung,interconnect-parent, #interconnect-cells.
> These properties allow to specify the SoC interconnect structure which
> then allows the interconnect consumer devices to request specific
> bandwidth requirements.
>
> Signed-off-by: Artur Świgoń
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes for v5:
> - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
> ---
> Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index e71f752..e0d2daa 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -51,6 +51,11 @@ 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.
>
> +Optional properties for interconnect functionality (QoS frequency
> constraints):
> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
> + passive devices should point to same node as the exynos,parent-bus
> property.
> +- #interconnect-cells: should be 0
> +
> Detailed correlation between sub-blocks and power line according to Exynos
> SoC:
> - In case of Exynos3250, there are two power line as following:
> VDD_MIF |--- DMC
> @@ -185,8 +190,9 @@ Example1:
> --
>
> Example2 :
> - The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> - is listed below:
> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi is
> + listed below. An interconnect path "bus_lcd0 -- bus_leftbus --
> bus_dmc"
> + is defined for demonstration purposes.
>
> bus_dmc: bus_dmc {
> compatible = "samsung,exynos-bus";
> @@ -376,12 +382,15 @@ Example2 :
> _dmc {
> devfreq-events = <_dmc0_3>, <_dmc1_3>;
> vdd-supply = <_reg>; /* VDD_MIF */
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> _leftbus {
> devfreq-events = <_leftbus_3>, <_rightbus_3>;
> vdd-supply = <_reg>;
> + samsung,interconnect-parent = <_dmc>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> @@ -392,6 +401,8 @@ Example2 :
>
> _lcd0 {
> devfreq = <_leftbus>;
> + samsung,interconnect-parent = <_leftbus>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> --
> 2.7.4
>
If you add the usage example like the mixer device of patch5 to this
dt-binding document,
I think it is very beneficial and more helpful for user of
exynos-bus/exynos-generic-icc.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Hi Sylwester,
On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
wrote:
>
> This patch adds registration of a child platform device for the exynos
> interconnect driver. It is assumed that the interconnect provider will
> only be needed when #interconnect-cells property is present in the bus
> DT node, hence the child device will be created only when such a property
> is present.
>
> Signed-off-by: Sylwester Nawrocki
>
> Changes for v5:
> - new patch.
> ---
> drivers/devfreq/exynos-bus.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 8fa8eb5..856e37d 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -24,6 +24,7 @@
>
> struct exynos_bus {
> struct device *dev;
> + struct platform_device *icc_pdev;
>
> struct devfreq *devfreq;
> struct devfreq_event_dev **edev;
> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
> if (ret < 0)
> dev_warn(dev, "failed to disable the devfreq-event
> devices\n");
>
> + platform_device_unregister(bus->icc_pdev);
> +
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> if (bus->opp_table) {
> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
> {
> struct exynos_bus *bus = dev_get_drvdata(dev);
>
> + platform_device_unregister(bus->icc_pdev);
> +
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> }
> @@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err;
>
> + /* Create child platform device for the interconnect provider */
> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
> + bus->icc_pdev = platform_device_register_data(
> + dev, "exynos-generic-icc",
> + PLATFORM_DEVID_AUTO, NULL, 0);
> +
> + if (IS_ERR(bus->icc_pdev)) {
> + ret = PTR_ERR(bus->icc_pdev);
> + goto err;
> + }
> + }
> +
> max_state = bus->devfreq->profile->max_state;
> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
> --
> 2.7.4
>
It looks like very similar like the registering the interconnect
device of imx-bus.c
and I already reviewed and agreed this approach.
Acked-by: Chanwoo Choi
nitpick: IMHO, I think that 'exynos-icc' is proper and simple without
'generic' word.
If we need to add new icc compatible int the future, we will add
'exynos-icc' new compatible.
But, I'm not forcing it. just opinion. Anyway, I agree this approach.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 3/7] interconnect: Allow inter-provider pairs to be configured
Hi,
On Fri, Dec 20, 2019 at 9:03 PM Artur Świgoń wrote:
>
> In the exynos-bus devfreq driver every bus is probed separately and is
IMHO, the patch description should specify the more general cause
why have to be changed. Actually, almost people might not know
the 'exynos-bus'. So, firstly, you have to specify the general cause
why this patch is necessary without 'exynos-bus' word and then
add the real use-case with 'exynos-bus' example.
> assigned a separate interconnect provider. However, the interconnect
> framework does not call the '->set' callback for pairs of nodes which
> belong to different providers.
>
> This patch adds support for a new boolean 'inter_set' field in struct
> icc_provider. Setting it to 'true' enables calling '->set' for
> inter-provider node pairs. All existing users of the interconnect
> framework allocate this structure with kzalloc, and are therefore
> unaffected.
>
> Signed-off-by: Artur Świgoń
> ---
> drivers/interconnect/core.c | 11 +--
> include/linux/interconnect-provider.h | 2 ++
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 74c68898a350..a28bd0f8a497 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -259,23 +259,22 @@ static int aggregate_requests(struct icc_node *node)
> static int apply_constraints(struct icc_path *path)
> {
> struct icc_node *next, *prev = NULL;
> + struct icc_provider *p;
> int ret = -EINVAL;
> int i;
>
> for (i = 0; i < path->num_nodes; i++) {
> next = path->reqs[i].node;
> + p = next->provider;
>
> - /*
> -* Both endpoints should be valid master-slave pairs of the
> -* same interconnect provider that will be configured.
> -*/
> - if (!prev || next->provider != prev->provider) {
> + /* both endpoints should be valid master-slave pairs */
> + if (!prev || (p != prev->provider && !p->inter_set)) {
> prev = next;
> continue;
> }
>
> /* set the constraints */
> - ret = next->provider->set(prev, next);
> + ret = p->set(prev, next);
> if (ret)
> goto out;
>
> diff --git a/include/linux/interconnect-provider.h
> b/include/linux/interconnect-provider.h
> index cc965b8fab53..b6ae0ee686c5 100644
> --- a/include/linux/interconnect-provider.h
> +++ b/include/linux/interconnect-provider.h
> @@ -41,6 +41,7 @@ struct icc_node *of_icc_xlate_onecell(struct
> of_phandle_args *spec,
> * @xlate: provider-specific callback for mapping nodes from phandle
> arguments
> * @dev: the device this interconnect provider belongs to
> * @users: count of active users
> + * @inter_set: whether inter-provider pairs will be configured with @set
> * @data: pointer to private data
> */
> struct icc_provider {
> @@ -53,6 +54,7 @@ struct icc_provider {
> struct icc_node* (*xlate)(struct of_phandle_args *spec, void *data);
> struct device *dev;
> int users;
> + boolinter_set;
> void*data;
> };
>
> --
> 2.17.1
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 7/7] drm: exynos: mixer: Add interconnect support
mixer_probe(struct platform_device *pdev)
> ctx->pdev = pdev;
> ctx->dev = dev;
> ctx->mxr_ver = drv->version;
> + ctx->soc_path = path;
>
> if (drv->is_vp_enabled)
> __set_bit(MXR_BIT_VP_ENABLED, >flags);
> @@ -1242,17 +1291,29 @@ static int mixer_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, ctx);
>
> ret = component_add(>dev, _component_ops);
> - if (!ret)
> - pm_runtime_enable(dev);
> + if (ret < 0)
> + goto err;
> +
> + pm_runtime_enable(dev);
> +
> + return 0;
> +
> +err:
> + icc_put(path);
>
> return ret;
> }
>
> static int mixer_remove(struct platform_device *pdev)
> {
> - pm_runtime_disable(>dev);
> + struct device *dev = >dev;
> + struct mixer_context *ctx = dev_get_drvdata(dev);
> +
> + pm_runtime_disable(dev);
> +
> + component_del(dev, _component_ops);
>
> - component_del(>dev, _component_ops);
> + icc_put(ctx->soc_path);
>
> return 0;
> }
> --
> 2.17.1
>
Basically, I agree this patch about using ICC feature
to guarantee the minimum bandwidth. But, I don't have
the knowledge of exynos-mixer.c. So, just I reviewed
the part of ICC usage. After digging the exynos-mixer.c,
I'll reply the reviewed tag. Thanks.
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 6/7] arm: dts: exynos: Add interconnects to Exynos4412 mixer
Hi,
On Fri, Dec 20, 2019 at 9:02 PM Artur Świgoń wrote:
>
> This patch adds an 'interconnects' property to Exynos4412 DTS in order to
> declare the interconnect path used by the mixer. Please note that the
> 'interconnect-names' property is not needed when there is only one path in
> 'interconnects', in which case calling of_icc_get() with a NULL name simply
> returns the right path.
>
> Signed-off-by: Artur Świgoń
> ---
> arch/arm/boot/dts/exynos4412.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index 48868947373e..13a679a9a107 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -771,6 +771,7 @@
> clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
> clocks = < CLK_MIXER>, < CLK_HDMI>,
> < CLK_SCLK_HDMI>, < CLK_VP>;
> + interconnects = <_display _dmc>;
> };
>
> {
> --
> 2.17.1
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
Hi,
On Fri, Dec 20, 2019 at 9:02 PM Artur Świgoń wrote:
>
> This patch adds the following properties to the Exynos4412 DT:
> - exynos,interconnect-parent-node: to declare connections between
> nodes in order to guarantee PM QoS requirements between nodes;
> - #interconnect-cells: required by the interconnect framework.
>
> Note that #interconnect-cells is always zero and node IDs are not
> hardcoded anywhere.
>
> Signed-off-by: Artur Świgoń
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 4ce3d77a6704..d9d70eacfcaf 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -90,6 +90,7 @@
> _dmc {
> exynos,ppmu-device = <_dmc0_3>, <_dmc1_3>;
> vdd-supply = <_reg>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> @@ -106,6 +107,8 @@
> _leftbus {
> exynos,ppmu-device = <_leftbus_3>, <_rightbus_3>;
> vdd-supply = <_reg>;
> + exynos,interconnect-parent-node = <_dmc>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> @@ -116,6 +119,8 @@
>
> _display {
> exynos,parent-bus = <_leftbus>;
> + exynos,interconnect-parent-node = <_leftbus>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> --
> 2.17.1
>
Reviewed-by: Chanwoo Choi
I has not yet tested on target. I'll test it on next week
and then reply the test result.
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 0/7] PM / devfreq: Simple QoS for exynos-bus using interconnect
Hi Artur, I agree this approach. On next version, please update exynos-bus dt-binding document with example. On Fri, Dec 20, 2019 at 9:01 PM Artur Świgoń wrote: > > The following patchset adds interconnect[1][2] framework support to the > exynos-bus devfreq driver. Extending the devfreq driver with > interconnect functionality started as a response to the issue referenced > in [3]. The patches can be subdivided into three groups: > > (a) Tweaking the interconnect framework to support the exynos-bus use > case (patches 01--03/07). Exporting of_icc_get_from_provider() allows to > avoid hardcoding every single graph edge in the DT or driver source, and > relaxing the requirement on #interconnect-cells removes the need to > provide dummy node IDs in the DT. A new field in struct icc_provider is > used to explicitly allow configuring node pairs from two different > providers. > > (b) Implementing interconnect providers in the exynos-bus devfreq driver > and adding required DT properties for one selected platform, namely > Exynos4412 (patches 04--05/07). Due to the fact that this aims to be a > generic driver for various Exynos SoCs, node IDs are generated > dynamically (rather than hardcoded). > > (c) Implementing a sample interconnect consumer for exynos-mixer > targeted at solving the issue referenced in [3], again with DT > properties only for Exynos4412 (patches 06--07/07). > > Integration of devfreq and interconnect frameworks is achieved by using > the dev_pm_qos_*() API. When CONFIG_INTERCONNECT is 'n' (such as in > exynos_defconfig) all interconnect API functions are no-ops. > > This series depends on these three patches (merged into devfreq-next[6]): > * https://patchwork.kernel.org/patch/11279087/ > * https://patchwork.kernel.org/patch/11279093/ > * https://patchwork.kernel.org/patch/11293765/ > and on this series: > * https://patchwork.kernel.org/cover/11304545/ > (which does not apply cleanly on next-20191220, adding > --exclude=arch/arm/boot/dts/exynos5422-odroid-core.dtsi to 'git am' is a > quick workaround) > > --- > Changes since v2 [5]: > * Use icc_std_aggregate(). > * Implement a different modification of apply_constraints() in > drivers/interconnect/core.c (patch 03). > * Use 'exynos,interconnect-parent-node' in the DT instead of > 'devfreq'/'parent', depending on the bus. > * Rebase on DT patches that deprecate the 'devfreq' DT property. > * Improve error handling, including freeing generated IDs on failure. > * Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent(). > > --- > Changes since v1 [4]: > * Rebase on coupled regulators patches. > * Use dev_pm_qos_*() API instead of overriding frequency in > exynos_bus_target(). > * Use IDR for node ID allocation. > * Reverse order of multiplication and division in > mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow. > > --- > Artur Świgoń > Samsung R Institute Poland > Samsung Electronics > > --- > References: > [1] Documentation/interconnect/interconnect.rst > [2] Documentation/devicetree/bindings/interconnect/interconnect.txt > [3] https://patchwork.kernel.org/patch/10861757/ (original issue) > [4] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) > [5] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC) > [6] > https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-next > > Artur Świgoń (6): > interconnect: Export of_icc_get_from_provider() > interconnect: Relax requirement in of_icc_get_from_provider() > interconnect: Allow inter-provider pairs to be configured > arm: dts: exynos: Add interconnect bindings for Exynos4412 > devfreq: exynos-bus: Add interconnect functionality to exynos-bus > arm: dts: exynos: Add interconnects to Exynos4412 mixer > > Marek Szyprowski (1): > drm: exynos: mixer: Add interconnect support > > .../boot/dts/exynos4412-odroid-common.dtsi| 5 + > arch/arm/boot/dts/exynos4412.dtsi | 1 + > drivers/devfreq/exynos-bus.c | 144 ++ > drivers/gpu/drm/exynos/exynos_mixer.c | 71 - > drivers/interconnect/core.c | 16 +- > include/linux/interconnect-provider.h | 8 + > 6 files changed, 232 insertions(+), 13 deletions(-) > > -- > 2.17.1 > -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 5/7] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
On Sun, Dec 22, 2019 at 4:53 AM Chanwoo Choi wrote:
>
> Hi,
>
> On Fri, Dec 20, 2019 at 9:02 PM Artur Świgoń wrote:
> >
> > This patch adds interconnect functionality to the exynos-bus devfreq
> > driver.
> >
> > The SoC topology is a graph (or, more specifically, a tree) and its
> > edges are specified using the 'exynos,interconnect-parent-node' in the
> > DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
> > propagated to ensure that the parent is probed before its children.
> >
> > Each bus is now an interconnect provider and an interconnect node as well
> > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
> > itself as a node. Node IDs are not hardcoded but rather assigned at
> > runtime, in probing order (subject to the above-mentioned exception
> > regarding relative order). This approach allows for using this driver with
> > various Exynos SoCs.
> >
> > Frequencies requested via the interconnect API for a given node are
> > propagated to devfreq using dev_pm_qos_update_request(). Please note that
> > it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
> > interconnect API functions are no-op.
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > drivers/devfreq/exynos-bus.c | 144 +++
> > 1 file changed, 144 insertions(+)
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 9fdb188915e8..694a9581dcdb 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -14,14 +14,19 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > #define DEFAULT_SATURATION_RATIO 40
> >
> > +#define kbps_to_khz(x) ((x) / 8)
> > +
> > struct exynos_bus {
> > struct device *dev;
> >
> > @@ -35,6 +40,12 @@ struct exynos_bus {
> > struct opp_table *opp_table;
> > struct clk *clk;
> > unsigned int ratio;
> > +
> > + /* One provider per bus, one node per provider */
> > + struct icc_provider provider;
> > + struct icc_node *node;
> > +
> > + struct dev_pm_qos_request qos_req;
> > };
> >
> > /*
> > @@ -205,6 +216,39 @@ static void exynos_bus_passive_exit(struct device *dev)
> > clk_disable_unprepare(bus->clk);
> > }
> >
> > +static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
> > +{
> > + struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
> > + s32 src_freq = kbps_to_khz(src->avg_bw);
> > + s32 dst_freq = kbps_to_khz(dst->avg_bw);
> > + int ret;
> > +
> > + ret = dev_pm_qos_update_request(_bus->qos_req, src_freq);
> > + if (ret < 0) {
> > + dev_err(src_bus->dev, "failed to update PM QoS request");
>
> To catch the correct error point, better to add 'src node' to error message
> as following:
>
> dev_err(src_bus->dev, "failed to update PM QoS of %s\n",
>dev_name(src_bus->dev.parent))
>
> > + return ret;
> > + }
> > +
> > + ret = dev_pm_qos_update_request(_bus->qos_req, dst_freq);
> > + if (ret < 0) {
> > + dev_err(dst_bus->dev, "failed to update PM QoS request");
>
> ditto.
>
> dev_err(src_bus->dev, "failed to update PM QoS of %s\n",
>dev_name(dst_bus->dev.parent))
>
>
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct icc_node *exynos_bus_icc_xlate(struct of_phandle_args *spec,
> > +void *data)
> > +{
> > + struct exynos_bus *bus = data;
> > +
> > + if (spec->np != bus->dev->of_node)
> > + return ERR_PTR(-EINVAL);
> > +
> > + return bus->node;
> > +}
> > +
> > static int exynos_bus_parent_parse_of(struct device_node *np,
> > struct exynos_bus *bus)
> > {
> > @@ -419,6 +463,96 @@ static int exynos_bus_profile_init_passive(struct
> > exynos_bus *bus,
> > return 0;
> > }
> >
> >
Re: [RFC PATCH v3 5/7] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
arent-node' with '/* parent
nodes are optional */'.
And I add my opinion about this comment below.
And I expect that you will add the description and example for
'exynos,interconnect-parent-node' on exynos-bus dt-binding document.
> +
> + ret = of_parse_phandle_with_args(np,
> "exynos,interconnect-parent-node",
> + "#interconnect-cells", 0, );
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + of_node_put(args.np);
> +
> + return of_icc_get_from_provider();
> +}
> +
> +static int exynos_bus_icc_init(struct exynos_bus *bus)
> +{
> + static DEFINE_IDA(ida);
> +
> + struct device *dev = bus->dev;
> + struct icc_provider *provider = >provider;
> + struct icc_node *node, *parent_node;
> + int id, ret;
> +
> + /* Initialize the interconnect provider */
> + provider->set = exynos_bus_icc_set;
> + provider->aggregate = icc_std_aggregate;
> + provider->xlate = exynos_bus_icc_xlate;
> + provider->dev = dev;
> + provider->inter_set = true;
> + provider->data = bus;
> +
> + ret = icc_provider_add(provider);
> + if (ret < 0)
> + return ret;
> +
> + ret = id = ida_alloc(, GFP_KERNEL);
> + if (ret < 0)
> + goto err_id;
> +
> + node = icc_node_create(id);
> + if (IS_ERR(node)) {
> + ret = PTR_ERR(node);
> + goto err_node;
> + }
> +
> + bus->node = node;
> + node->name = dev->of_node->name;
> + node->data = bus;
> + icc_node_add(node, provider);
> +
Better to add the following comment. If you add following comment
before calling exynos_bus_icc_get_parent, don't need to add the
same comment into exynos_bus_icc.
/* If interconnect parent node is not existing, don't use
interconnect feature */
> + parent_node = exynos_bus_icc_get_parent(bus);
> + if (IS_ERR(parent_node)) {
> + ret = PTR_ERR(parent_node);
> + goto err_parent;
> + }
> +
> + if (parent_node) {
Better to change this if statement as following:
else if (parent_node)
> + ret = icc_link_create(node, parent_node->id);
> + if (ret < 0)
> + goto err_parent;
> + }
> +
> + ret = dev_pm_qos_add_request(bus->devfreq->dev.parent, >qos_req,
> + DEV_PM_QOS_MIN_FREQUENCY, 0);
Is it necessary if interconnect-parent-node is not existing?
> + if (ret < 0)
> + goto err_request;
> +
> + return 0;
> +
> +err_request:
> + if (parent_node)
> + icc_link_destroy(node, parent_node);
> +err_parent:
> + icc_node_del(node);
> + icc_node_destroy(id);
> +err_node:
> + ida_free(, id);
> +err_id:
> + icc_provider_del(provider);
> +
> + return ret;
> +}
> +
> static int exynos_bus_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -468,6 +602,16 @@ static int exynos_bus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err;
>
> + /*
> +* Initialize interconnect provider. A return value of -ENOTSUPP means
> +* that CONFIG_INTERCONNECT is disabled.
> +*/
> + ret = exynos_bus_icc_init(bus);
> + if (ret < 0 && ret != -ENOTSUPP) {
> + dev_err(dev, "failed to initialize the interconnect
> provider");
> + goto err;
> + }
> +
> max_state = bus->devfreq->profile->max_state;
> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
> --
> 2.17.1
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 2/7] interconnect: Relax requirement in of_icc_get_from_provider()
Hi, On Fri, Dec 20, 2019 at 9:03 PM Artur Świgoń wrote: > > This patch relaxes the condition in of_icc_get_from_provider() so that it > is no longer required to set #interconnect-cells = <1> in the DT. In case > of the devfreq driver for exynos-bus, #interconnect-cells is always zero. It doesn't contain why don't need to require it. If you add more detailed description, it is better to understand. > > Signed-off-by: Artur Świgoń > Acked-by: Krzysztof Kozlowski > --- > drivers/interconnect/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c > index e6035c199369..74c68898a350 100644 > --- a/drivers/interconnect/core.c > +++ b/drivers/interconnect/core.c > @@ -335,7 +335,7 @@ struct icc_node *of_icc_get_from_provider(struct > of_phandle_args *spec) > struct icc_node *node = ERR_PTR(-EPROBE_DEFER); > struct icc_provider *provider; > > - if (!spec || spec->args_count != 1) > + if (!spec) > return ERR_PTR(-EINVAL); > > mutex_lock(_lock); > -- > 2.17.1 > -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Hi,
If possible, I'd like to apply these patches to v5.6-rc1.
It is very useful feature to support the QoS for user device using memory bus.
2019년 12월 18일 (수) 오후 7:48, Artur Świgoń 님이 작성:
>
> On Wed, 2019-12-18 at 19:39 +0900, Chanwoo Choi wrote:
> > Hi,
> >
> > 2019년 12월 18일 (수) 오후 7:19, Artur Świgoń 님이 작성:
> > >
> > > Hi,
> > >
> > > Thank you for the review.
> > >
> > > On Mon, 2019-12-16 at 09:44 +0900, Chanwoo Choi wrote:
> > > > Hi,
> > > >
> > > > On 9/19/19 11:22 PM, Artur Świgoń wrote:
> > > > > From: Artur Świgoń
> > > > >
> > > > > This patch adds interconnect functionality to the exynos-bus devfreq
> > > > > driver.
> > > > >
> > > > > The SoC topology is a graph (or, more specifically, a tree) and most
> > > > > of
> > > > > its edges are taken from the devfreq parent-child hierarchy (cf.
> > > > > Documentation/devicetree/bindings/devfreq/exynos-bus.txt). Due to
> > > > > unspecified relative probing order, -EPROBE_DEFER may be propagated to
> > > > > guarantee that a child is probed before its parent.
> > > > >
> > > > > Each bus is now an interconnect provider and an interconnect node as
> > > > > well
> > > > > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
> > > > > registers
> > > > > itself as a node. Node IDs are not hardcoded but rather assigned at
> > > > > runtime, in probing order (subject to the above-mentioned exception
> > > > > regarding relative order). This approach allows for using this driver
> > > > > with
> > > > > various Exynos SoCs.
> > > > >
> > > > > Frequencies requested via the interconnect API for a given node are
> > > > > propagated to devfreq using dev_pm_qos_update_request(). Please note
> > > > > that
> > > > > it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
> > > > > interconnect API functions are no-op.
> > > > >
> > > > > Signed-off-by: Artur Świgoń
> > > > > ---
> > > > > drivers/devfreq/exynos-bus.c | 153
> > > > > +++
> > > > > 1 file changed, 153 insertions(+)
> > > > >
> > > > > diff --git a/drivers/devfreq/exynos-bus.c
> > > > > b/drivers/devfreq/exynos-bus.c
> > > > > index 8d44810cac69..e0232202720d 100644
> > > > > --- a/drivers/devfreq/exynos-bus.c
> > > > > +++ b/drivers/devfreq/exynos-bus.c
> > > > > @@ -14,14 +14,19 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > >
> > > > > #define DEFAULT_SATURATION_RATIO 40
> > > > >
> > > > > +#define icc_units_to_khz(x) ((x) / 8)
> > > >
> > > > icc_units_to_khz() -> kpbs_to_khz()
> > >
> > > OK
> > >
> > > > > +
> > > > > struct exynos_bus {
> > > > > struct device *dev;
> > > > >
> > > > > @@ -35,6 +40,12 @@ struct exynos_bus {
> > > > > struct opp_table *opp_table;
> > > > > struct clk *clk;
> > > > > unsigned int ratio;
> > > > > +
> > > > > + /* One provider per bus, one node per provider */
> > > > > + struct icc_provider provider;
> > > > > + struct icc_node *node;
> > > > > +
> > > > > + struct dev_pm_qos_request qos_req;
> > > > > };
> > > > >
> > > > > /*
> > > > > @@ -59,6 +70,13 @@ exynos_bus_ops_edev(enable_edev);
> > > > > exynos_bus_ops_edev(disable_edev);
> > > > > exynos_bus_ops_edev(set_event);
> > > > >
> > > > > +static int exynos_bus_next_id(void)
> > > > > +{
> > > > > + static DEFINE_IDA(exynos_bus_icc_ida);
> > > > > +
> > > > > + return ida_alloc(_bus_icc_ida, GFP_KERNEL);
> > > > > +}
>
Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Hi,
2019년 12월 18일 (수) 오후 7:19, Artur Świgoń 님이 작성:
>
> Hi,
>
> Thank you for the review.
>
> On Mon, 2019-12-16 at 09:44 +0900, Chanwoo Choi wrote:
> > Hi,
> >
> > On 9/19/19 11:22 PM, Artur Świgoń wrote:
> > > From: Artur Świgoń
> > >
> > > This patch adds interconnect functionality to the exynos-bus devfreq
> > > driver.
> > >
> > > The SoC topology is a graph (or, more specifically, a tree) and most of
> > > its edges are taken from the devfreq parent-child hierarchy (cf.
> > > Documentation/devicetree/bindings/devfreq/exynos-bus.txt). Due to
> > > unspecified relative probing order, -EPROBE_DEFER may be propagated to
> > > guarantee that a child is probed before its parent.
> > >
> > > Each bus is now an interconnect provider and an interconnect node as well
> > > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
> > > registers
> > > itself as a node. Node IDs are not hardcoded but rather assigned at
> > > runtime, in probing order (subject to the above-mentioned exception
> > > regarding relative order). This approach allows for using this driver with
> > > various Exynos SoCs.
> > >
> > > Frequencies requested via the interconnect API for a given node are
> > > propagated to devfreq using dev_pm_qos_update_request(). Please note that
> > > it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
> > > interconnect API functions are no-op.
> > >
> > > Signed-off-by: Artur Świgoń
> > > ---
> > > drivers/devfreq/exynos-bus.c | 153 +++
> > > 1 file changed, 153 insertions(+)
> > >
> > > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > > index 8d44810cac69..e0232202720d 100644
> > > --- a/drivers/devfreq/exynos-bus.c
> > > +++ b/drivers/devfreq/exynos-bus.c
> > > @@ -14,14 +14,19 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > #define DEFAULT_SATURATION_RATIO 40
> > >
> > > +#define icc_units_to_khz(x) ((x) / 8)
> >
> > icc_units_to_khz() -> kpbs_to_khz()
>
> OK
>
> > > +
> > > struct exynos_bus {
> > > struct device *dev;
> > >
> > > @@ -35,6 +40,12 @@ struct exynos_bus {
> > > struct opp_table *opp_table;
> > > struct clk *clk;
> > > unsigned int ratio;
> > > +
> > > + /* One provider per bus, one node per provider */
> > > + struct icc_provider provider;
> > > + struct icc_node *node;
> > > +
> > > + struct dev_pm_qos_request qos_req;
> > > };
> > >
> > > /*
> > > @@ -59,6 +70,13 @@ exynos_bus_ops_edev(enable_edev);
> > > exynos_bus_ops_edev(disable_edev);
> > > exynos_bus_ops_edev(set_event);
> > >
> > > +static int exynos_bus_next_id(void)
> > > +{
> > > + static DEFINE_IDA(exynos_bus_icc_ida);
> > > +
> > > + return ida_alloc(_bus_icc_ida, GFP_KERNEL);
> > > +}
> > > +
> > > static int exynos_bus_get_event(struct exynos_bus *bus,
> > > struct devfreq_event_data *edata)
> > > {
> > > @@ -171,6 +189,38 @@ static void exynos_bus_passive_exit(struct device
> > > *dev)
> > > clk_disable_unprepare(bus->clk);
> > > }
> > >
> > > +static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
> > > +{
> > > + struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
> > > + s32 src_freq = icc_units_to_khz(src->avg_bw);
> > > + s32 dst_freq = icc_units_to_khz(dst->avg_bw);
> > > +
> > > + dev_pm_qos_update_request(_bus->qos_req, src_freq);
> >
> > Have to check the return value.
> > If return error, show the waring with dev_warn.
>
> OK, I will change it to:
>
> ret = dev_pm_qos_update_request(_bus->qos_req, src_freq);
> if (ret < 0) {
> dev_warn(src_bus->dev, "failed to update PM QoS request");
> return ret;
If you return right after, better to use dev_err.
If you use dev_warn, just show the warning message without return.
> }
>
> > > + dev_pm_qos_update_request(_bus->qos_re
Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
Hi
2019년 12월 18일 (수) 오후 7:18, Artur Świgoń 님이 작성:
>
> Hi,
>
> On Mon, 2019-12-16 at 11:59 +0900, Chanwoo Choi wrote:
> > Hi,
> >
> > On 12/16/19 9:51 AM, Chanwoo Choi wrote:
> > > On 9/19/19 11:22 PM, Artur Świgoń wrote:
> > > > From: Artur Świgoń
> > > >
> > > > This patch adds two fields to the Exynos4412 DTS:
> > > > - parent: to declare connections between nodes that are not in a
> > > > parent-child relation in devfreq;
> > > > - #interconnect-cells: required by the interconnect framework.
> > > >
> > > > Please note that #interconnect-cells is always zero and node IDs are not
> > > > hardcoded anywhere. The above-mentioned parent-child relation in devfreq
> > > > means that there is a shared power line ('devfreq' property). The
> > > > 'parent'
> > > > property only signifies an interconnect connection.
> > > >
> > > > Signed-off-by: Artur Świgoń
> > > > ---
> > > > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
> > > > arch/arm/boot/dts/exynos4412.dtsi | 9 +
> > > > 2 files changed, 10 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > index ea55f377d17c..bdd61ae86103 100644
> > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > @@ -106,6 +106,7 @@
> > > > _leftbus {
> > > > devfreq-events = <_leftbus_3>, <_rightbus_3>;
> > > > vdd-supply = <_reg>;
> > > > + parent = <_dmc>;
> > >
> > > As I mentioned on other reply,
> > > I'm not sure to use the specific 'parent' property to make
> > > the connection between buses. If possible, you better to
> > > use the standard way like OF graph. Except for making
> > > the connection between buses by 'parent' property,
> > > looks good to me.
> >
> > I tried to think it continuously. I withdraw the my opinion
> > using OF graph. If you make the property name like the following
> > example, it is possible for exynos.
> > - exynos,interconnect-parent-node = <_dmc>; or other proper name.
> >
> > Regardless of existing 'devfreq' property, I think you better to
> > make the connection between buses for only interconnect as following
> > example: This make it possible user can draw the correct tree by tracking
> > the 'exynos,interconnect-parent-node' value.
>
> OK, for v3 I will add 'exynos,interconnect-parent-node' to bus_dmc,
> bus_leftbus and bus_display as you suggested below and change the code
> so that the 'devfreq' (or the upcoming 'exynos,parent-bus') property is
> not taken into account.
I'd like you to make the v3 based on my patches[1]
[1] https://lkml.org/lkml/2019/12/17/21
- [PATCH 0/9] PM / devfreq: Remove deprecated 'devfreq' and
'devfreq-events' properties
I uploaded the patches to devfreq-testing branch[2]
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing
>
> > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > index ea55f377d17c..53f87f46e161 100644
> > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > @@ -90,6 +90,7 @@
> > _dmc {
> > devfreq-events = <_dmc0_3>, <_dmc1_3>;
> > vdd-supply = <_reg>;
> > + #interconnect-cells = <0>;
> > status = "okay";
> > };
> >
> > @@ -106,6 +107,8 @@
> > _leftbus {
> > devfreq-events = <_leftbus_3>, <_rightbus_3>;
> > vdd-supply = <_reg>;
> > + exynos,interconnect-parent-node = <_dmc>;
> > + #interconnect-cells = <0>;
> > status = "okay";
> > };
> >
> > @@ -116,6 +119,8 @@
> >
> > _display {
> > devfreq = <_leftbus>;
> > + exynos,interconnect-parent-node = <_leftbus>;
> > + #interconnect-cells = <0>;
> > status = "okay";
> > };
> >
> >
> > >
> > >
> > > > status = "okay";
> > > > };
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> > > > b/arc
Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
On 9/19/19 11:22 PM, Artur Świgoń wrote:
> From: Artur Świgoń
>
> This patch adds two fields to the Exynos4412 DTS:
> - parent: to declare connections between nodes that are not in a
> parent-child relation in devfreq;
> - #interconnect-cells: required by the interconnect framework.
>
> Please note that #interconnect-cells is always zero and node IDs are not
> hardcoded anywhere. The above-mentioned parent-child relation in devfreq
> means that there is a shared power line ('devfreq' property). The 'parent'
> property only signifies an interconnect connection.
>
> Signed-off-by: Artur Świgoń
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
> arch/arm/boot/dts/exynos4412.dtsi | 9 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index ea55f377d17c..bdd61ae86103 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -106,6 +106,7 @@
> _leftbus {
> devfreq-events = <_leftbus_3>, <_rightbus_3>;
> vdd-supply = <_reg>;
> + parent = <_dmc>;
As I mentioned on other reply,
I'm not sure to use the specific 'parent' property to make
the connection between buses. If possible, you better to
use the standard way like OF graph. Except for making
the connection between buses by 'parent' property,
looks good to me.
> status = "okay";
> };
>
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index d20db2dfe8e2..a70a671acacd 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -390,6 +390,7 @@
> clocks = < CLK_DIV_DMC>;
> clock-names = "bus";
> operating-points-v2 = <_dmc_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -398,6 +399,7 @@
> clocks = < CLK_DIV_ACP>;
> clock-names = "bus";
> operating-points-v2 = <_acp_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -406,6 +408,7 @@
> clocks = < CLK_DIV_C2C>;
> clock-names = "bus";
> operating-points-v2 = <_dmc_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -459,6 +462,7 @@
> clocks = < CLK_DIV_GDL>;
> clock-names = "bus";
> operating-points-v2 = <_leftbus_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -467,6 +471,7 @@
> clocks = < CLK_DIV_GDR>;
> clock-names = "bus";
> operating-points-v2 = <_leftbus_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -475,6 +480,7 @@
> clocks = < CLK_ACLK160>;
> clock-names = "bus";
> operating-points-v2 = <_display_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -483,6 +489,7 @@
> clocks = < CLK_ACLK133>;
> clock-names = "bus";
> operating-points-v2 = <_fsys_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -491,6 +498,7 @@
> clocks = < CLK_ACLK100>;
> clock-names = "bus";
> operating-points-v2 = <_peri_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -499,6 +507,7 @@
> clocks = < CLK_SCLK_MFC>;
> clock-names = "bus";
> operating-points-v2 = <_leftbus_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
Hi,
On 9/19/19 11:22 PM, Artur Świgoń wrote:
> From: Artur Świgoń
>
> This patch adds two fields to the Exynos4412 DTS:
> - parent: to declare connections between nodes that are not in a
> parent-child relation in devfreq;
> - #interconnect-cells: required by the interconnect framework.
>
> Please note that #interconnect-cells is always zero and node IDs are not
> hardcoded anywhere. The above-mentioned parent-child relation in devfreq
> means that there is a shared power line ('devfreq' property). The 'parent'
> property only signifies an interconnect connection.
>
> Signed-off-by: Artur Świgoń
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
> arch/arm/boot/dts/exynos4412.dtsi | 9 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index ea55f377d17c..bdd61ae86103 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -106,6 +106,7 @@
> _leftbus {
> devfreq-events = <_leftbus_3>, <_rightbus_3>;
> vdd-supply = <_reg>;
> + parent = <_dmc>;
As I mentioned on other patch,
I'm not sure to use 'parent' property for this driver.
If possible, we better to use the standard way like OF graph
in order to make the tree between buses. Except for making
the connection between the buses with 'parent', looks good to me.
> status = "okay";
> };
>
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index d20db2dfe8e2..a70a671acacd 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -390,6 +390,7 @@
> clocks = < CLK_DIV_DMC>;
> clock-names = "bus";
> operating-points-v2 = <_dmc_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -398,6 +399,7 @@
> clocks = < CLK_DIV_ACP>;
> clock-names = "bus";
> operating-points-v2 = <_acp_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -406,6 +408,7 @@
> clocks = < CLK_DIV_C2C>;
> clock-names = "bus";
> operating-points-v2 = <_dmc_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -459,6 +462,7 @@
> clocks = < CLK_DIV_GDL>;
> clock-names = "bus";
> operating-points-v2 = <_leftbus_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -467,6 +471,7 @@
> clocks = < CLK_DIV_GDR>;
> clock-names = "bus";
> operating-points-v2 = <_leftbus_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -475,6 +480,7 @@
> clocks = < CLK_ACLK160>;
> clock-names = "bus";
> operating-points-v2 = <_display_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -483,6 +489,7 @@
> clocks = < CLK_ACLK133>;
> clock-names = "bus";
> operating-points-v2 = <_fsys_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -491,6 +498,7 @@
> clocks = < CLK_ACLK100>;
> clock-names = "bus";
> operating-points-v2 = <_peri_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
> @@ -499,6 +507,7 @@
> clocks = < CLK_SCLK_MFC>;
> clock-names = "bus";
> operating-points-v2 = <_leftbus_opp_table>;
> + #interconnect-cells = <0>;
> status = "disabled";
> };
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
Hi,
Please ignore second reply. It is my mistake
to send the duplicate message because of my company firewall issue.
Regards,
Chanwoo Choi
On 12/16/19 9:55 AM, Chanwoo Choi wrote:
> Hi,
>
> On 9/19/19 11:22 PM, Artur Świgoń wrote:
>> From: Artur Świgoń
>>
>> This patch adds two fields to the Exynos4412 DTS:
>> - parent: to declare connections between nodes that are not in a
>> parent-child relation in devfreq;
>> - #interconnect-cells: required by the interconnect framework.
>>
>> Please note that #interconnect-cells is always zero and node IDs are not
>> hardcoded anywhere. The above-mentioned parent-child relation in devfreq
>> means that there is a shared power line ('devfreq' property). The 'parent'
>> property only signifies an interconnect connection.
>>
>> Signed-off-by: Artur Świgoń
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 9 +
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index ea55f377d17c..bdd61ae86103 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -106,6 +106,7 @@
>> _leftbus {
>> devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> vdd-supply = <_reg>;
>> +parent = <_dmc>;
>
> As I mentioned on other patch,
> I'm not sure to use 'parent' property for this driver.
> If possible, we better to use the standard way like OF graph
> in order to make the tree between buses. Except for making
> the connection between the buses with 'parent', looks good to me.
>
>> status = "okay";
>> };
>>
>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
>> b/arch/arm/boot/dts/exynos4412.dtsi
>> index d20db2dfe8e2..a70a671acacd 100644
>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> @@ -390,6 +390,7 @@
>> clocks = < CLK_DIV_DMC>;
>> clock-names = "bus";
>> operating-points-v2 = <_dmc_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -398,6 +399,7 @@
>> clocks = < CLK_DIV_ACP>;
>> clock-names = "bus";
>> operating-points-v2 = <_acp_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -406,6 +408,7 @@
>> clocks = < CLK_DIV_C2C>;
>> clock-names = "bus";
>> operating-points-v2 = <_dmc_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -459,6 +462,7 @@
>> clocks = < CLK_DIV_GDL>;
>> clock-names = "bus";
>> operating-points-v2 = <_leftbus_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -467,6 +471,7 @@
>> clocks = < CLK_DIV_GDR>;
>> clock-names = "bus";
>> operating-points-v2 = <_leftbus_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -475,6 +480,7 @@
>> clocks = < CLK_ACLK160>;
>> clock-names = "bus";
>> operating-points-v2 = <_display_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -483,6 +489,7 @@
>> clocks = < CLK_ACLK133>;
>> clock-names = "bus";
>> operating-points-v2 = <_fsys_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -491,6 +498,7 @@
>> clocks = < CLK_ACLK100>;
>> clock-names = "bus";
>> operating-points-v2 = <_peri_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -499,6 +507,7 @@
>> clocks = < CLK_SCLK_MFC>;
>> clock-names = "bus";
>> operating-points-v2 = <_leftbus_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
Hi,
On 12/16/19 9:51 AM, Chanwoo Choi wrote:
> On 9/19/19 11:22 PM, Artur Świgoń wrote:
>> From: Artur Świgoń
>>
>> This patch adds two fields to the Exynos4412 DTS:
>> - parent: to declare connections between nodes that are not in a
>> parent-child relation in devfreq;
>> - #interconnect-cells: required by the interconnect framework.
>>
>> Please note that #interconnect-cells is always zero and node IDs are not
>> hardcoded anywhere. The above-mentioned parent-child relation in devfreq
>> means that there is a shared power line ('devfreq' property). The 'parent'
>> property only signifies an interconnect connection.
>>
>> Signed-off-by: Artur Świgoń
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 9 +
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index ea55f377d17c..bdd61ae86103 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -106,6 +106,7 @@
>> _leftbus {
>> devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> vdd-supply = <_reg>;
>> +parent = <_dmc>;
>
> As I mentioned on other reply,
> I'm not sure to use the specific 'parent' property to make
> the connection between buses. If possible, you better to
> use the standard way like OF graph. Except for making
> the connection between buses by 'parent' property,
> looks good to me.
I tried to think it continuously. I withdraw the my opinion
using OF graph. If you make the property name like the following
example, it is possible for exynos.
- exynos,interconnect-parent-node = <_dmc>; or other proper name.
Regardless of existing 'devfreq' property, I think you better to
make the connection between buses for only interconnect as following
example: This make it possible user can draw the correct tree by tracking
the 'exynos,interconnect-parent-node' value.
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ea55f377d17c..53f87f46e161 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -90,6 +90,7 @@
_dmc {
devfreq-events = <_dmc0_3>, <_dmc1_3>;
vdd-supply = <_reg>;
+ #interconnect-cells = <0>;
status = "okay";
};
@@ -106,6 +107,8 @@
_leftbus {
devfreq-events = <_leftbus_3>, <_rightbus_3>;
vdd-supply = <_reg>;
+ exynos,interconnect-parent-node = <_dmc>;
+ #interconnect-cells = <0>;
status = "okay";
};
@@ -116,6 +119,8 @@
_display {
devfreq = <_leftbus>;
+ exynos,interconnect-parent-node = <_leftbus>;
+ #interconnect-cells = <0>;
status = "okay";
};
>
>
>> status = "okay";
>> };
>>
>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
>> b/arch/arm/boot/dts/exynos4412.dtsi
>> index d20db2dfe8e2..a70a671acacd 100644
>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> @@ -390,6 +390,7 @@
>> clocks = < CLK_DIV_DMC>;
>> clock-names = "bus";
>> operating-points-v2 = <_dmc_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -398,6 +399,7 @@
>> clocks = < CLK_DIV_ACP>;
>> clock-names = "bus";
>> operating-points-v2 = <_acp_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -406,6 +408,7 @@
>> clocks = < CLK_DIV_C2C>;
>> clock-names = "bus";
>> operating-points-v2 = <_dmc_opp_table>;
>> +#interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -459,6 +462,7 @@
>> clocks = < CLK_DIV_GDL>;
>> clock-names = "bus";
>> operating-points-v2 = <_leftbus_opp_table>;
>> +#interconnect-cells = <0
Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
= dev_get_drvdata(parent_devfreq->dev.parent);
> + parent_node = parent_bus->node;
> + } else {
> + /* Look for parent in DT */
> + int num = of_count_phandle_with_args(np, "parent",
> + "#interconnect-cells");
> + if (num != 1)
> + goto out; /* 'parent' is optional */
> +
> + ret = of_parse_phandle_with_args(np, "parent",
> + "#interconnect-cells",
> + 0, );
Actually, I agree your approach. I think that it is very useful
and necessary to guarantee the PM QoS requirements between devices.
But,
As I already commented, I'm not sure that the "parent" property
is proper for only this driver. If possible, you better to get
the parent phandle through other way like OF graph.
If you suggest the standard way to make the tree between
the exynos-bus, I'll agree.
Also, for interconnect path, you have to add the connection
between 'bus_display' and 'bus_leftbus' regardless
of the existing 'devfreq' property.
- bus_display - bus_leftbus - bus_dmc
> + if (ret < 0)
> + goto out;
> +
> + of_node_put(args.np);
> +
> + parent_node = of_icc_get_from_provider();
> + if (IS_ERR(parent_node)) {
> + /* May be -EPROBE_DEFER */
> + ret = PTR_ERR(parent_node);
> + goto out;
> + }
> + }
> +
> + ret = icc_link_create(bus->node, parent_node->id);
> +
> +out:
> + return ret;
> +}
> +
> +static int exynos_bus_icc_init(struct exynos_bus *bus)
> +{
> + struct device *dev = bus->dev;
> + struct icc_provider *provider = >provider;
> + struct icc_node *node;
> + int id, ret;
> +
> + /* Initialize the interconnect provider */
> + provider->set = exynos_bus_icc_set;
> + provider->aggregate = exynos_bus_icc_aggregate;
> + provider->xlate = exynos_bus_icc_xlate;
> + provider->dev = dev;
> + provider->data = bus;
> +
> + ret = icc_provider_add(provider);
> + if (ret < 0)
> + goto out;
Return error without goto because there is no any requirement
to free the resource before.
> +
> + ret = id = exynos_bus_next_id();
> + if (ret < 0)
> + goto err_node;
> +
> + node = icc_node_create(id);
> + if (IS_ERR(node)) {
> + ret = PTR_ERR(node);
> + goto err_node;
> + }
> +
> + bus->node = node;
> + node->name = dev->of_node->name;
> + node->data = bus;
> + icc_node_add(node, provider);
> +
> + ret = exynos_bus_icc_connect(bus);
> + if (ret < 0)
> + goto err_connect;
> +
> + ret = dev_pm_qos_add_request(bus->devfreq->dev.parent, >qos_req,
Check whether this line is over 80 char.
> + DEV_PM_QOS_MIN_FREQUENCY, 0);
Check the return value.
> +
> +out:
Remove this goto due to not necessary.
> + return ret;
return 0;
> +
> +err_connect:
> + icc_node_del(node);
> + icc_node_destroy(id);
> +err_node:
> + icc_provider_del(provider);
> +
> + return ret;
> +}
> +
> static int exynos_bus_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -415,6 +560,14 @@ static int exynos_bus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err;
>
> + /*
> + * Initialize interconnect provider. A return value of -ENOTSUPP means
> + * that CONFIG_INTERCONNECT is disabled.
> + */
> + ret = exynos_bus_icc_init(bus);
> + if (ret < 0 && ret != -ENOTSUPP)
> + goto err;
Print error message.
dev_err(dev, "failed to initialize the interconnect provider");
> +
> max_state = bus->devfreq->profile->max_state;
> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 05/11] interconnect: Export of_icc_get_from_provider()
On 9/19/19 11:22 PM, Artur Świgoń wrote:
> From: Artur Świgoń
>
> This patch makes the above function public (for use in exynos-bus devfreq
> driver).
>
> Signed-off-by: Artur Świgoń
> Reviewed-by: Krzysztof Kozlowski
> ---
> drivers/interconnect/core.c | 3 ++-
> include/linux/interconnect-provider.h | 6 ++
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 7b971228df38..95850700e367 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -279,7 +279,7 @@ EXPORT_SYMBOL_GPL(of_icc_xlate_onecell);
> * Returns a valid pointer to struct icc_node on success or ERR_PTR()
> * on failure.
> */
> -static struct icc_node *of_icc_get_from_provider(struct of_phandle_args
> *spec)
> +struct icc_node *of_icc_get_from_provider(struct of_phandle_args *spec)
> {
> struct icc_node *node = ERR_PTR(-EPROBE_DEFER);
> struct icc_provider *provider;
> @@ -298,6 +298,7 @@ static struct icc_node *of_icc_get_from_provider(struct
> of_phandle_args *spec)
>
> return node;
> }
> +EXPORT_SYMBOL_GPL(of_icc_get_from_provider);
>
> /**
> * of_icc_get() - get a path handle from a DT node based on name
> diff --git a/include/linux/interconnect-provider.h
> b/include/linux/interconnect-provider.h
> index b16f9effa555..070e411564e1 100644
> --- a/include/linux/interconnect-provider.h
> +++ b/include/linux/interconnect-provider.h
> @@ -100,6 +100,7 @@ void icc_node_add(struct icc_node *node, struct
> icc_provider *provider);
> void icc_node_del(struct icc_node *node);
> int icc_provider_add(struct icc_provider *provider);
> int icc_provider_del(struct icc_provider *provider);
> +struct icc_node *of_icc_get_from_provider(struct of_phandle_args *spec);
>
> #else
>
> @@ -140,6 +141,11 @@ static inline int icc_provider_del(struct icc_provider
> *provider)
> return -ENOTSUPP;
> }
>
> +struct icc_node *of_icc_get_from_provider(struct of_phandle_args *spec)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> +
> #endif /* CONFIG_INTERCONNECT */
>
> #endif /* __LINUX_INTERCONNECT_PROVIDER_H */
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Hi Artur,
On 12/3/19 2:05 AM, Artur Świgoń wrote:
> Hi Chanwoo,
>
> On Wed, 2019-09-25 at 16:03 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> I need the time to dig the ICC framework
>> to understand them detailed. After that, I'll review this.
>
> Any updates on this topic?
I'm sorry for delaying the review of this topic related to icc.
The review and merge of devfreq pm-qos feature will be finished over soon.
Because this series depends on the devfreq pm-qos feature
I'll dig into ICC related patches for exynos and imx[1].
[1]
https://lore.kernel.org/linux-arm-kernel/008f2fa973b23fc716d678c5bd35a...@akkea.ca/T/
[PATCH RFC v6 0/9] interconnect: Add imx support via devfreq
>
> Regardless of the purpose of this RFC, I think patches 01-04
> are still beneficial to devfreq. I can rebase and post them
> as a separate series if you wish.
Yes. please split out patch1-4 from this series
and send them based on linux-next.git separately.
>
>> Basically, I agree this approach. But, I'm wondering
>> the existing binding method between 'bus_leftbus' and 'bus_dmc'.
>> From before, I thought that devfreq framework need to
>> enhance the binding method between parent devfreq device
>> and passive devfreq device instead of 'devfreq' property.
>>
>> On this patch, use the same binding way between
>> 'bus_leftbus' and 'bus_dmc' with 'parent' property
>> as following:
>>
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -106,6 +106,7 @@
>> _leftbus {
>> devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> vdd-supply = <_reg>;
>> +parent = <_dmc>;
>> status = "okay";
>> };
>>
>> I'm not sure about continuing to use this method for new feature.
>> If possible, hope to replace the existing binding style
>> with new method like of_graph. Actually, I don't know the correct method.
>>
>>
>> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
>>> From: Artur Świgoń
>>>
>>> This patch adds interconnect functionality to the exynos-bus devfreq
>>> driver.
>>>
>>> The SoC topology is a graph (or, more specifically, a tree) and most of
>>> its edges are taken from the devfreq parent-child hierarchy (cf.
>>> Documentation/devicetree/bindings/devfreq/exynos-bus.txt). Due to
>>> unspecified relative probing order, -EPROBE_DEFER may be propagated to
>>> guarantee that a child is probed before its parent.
>>>
>>> Each bus is now an interconnect provider and an interconnect node as well
>>> (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
>>> itself as a node. Node IDs are not hardcoded but rather assigned at
>>> runtime, in probing order (subject to the above-mentioned exception
>>> regarding relative order). This approach allows for using this driver with
>>> various Exynos SoCs.
>>>
>>> Frequencies requested via the interconnect API for a given node are
>>> propagated to devfreq using dev_pm_qos_update_request(). Please note that
>>> it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
>>> interconnect API functions are no-op.
>>>
>>> Signed-off-by: Artur Świgoń
>>> ---
>>> drivers/devfreq/exynos-bus.c | 153 +++
>>> 1 file changed, 153 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 8d44810cac69..e0232202720d 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -14,14 +14,19 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> #define DEFAULT_SATURATION_RATIO 40
>>>
>>> +#define icc_units_to_khz(x) ((x) / 8)
>>> +
>>> struct exynos_bus {
>>> struct device *dev;
>>>
>>> @@ -35,6 +40,12 @@ struct exynos_bus {
>>> struct opp_table *opp_table;
>>> struct clk *clk;
>>> unsigned int ratio;
>>> +
>>> + /* One provider per bus, one node per provider */
>>> + struct icc_provider provider;
>>> + struct icc_node *node;
>>> +
>>> + struct dev_pm_qos_request qos_req;
>>> };
>>>
>>> /*
>>> @@ -59,6 +70,13 @@ exynos_bus_ops_edev(enable_edev);
>>>
Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
n bus->node;
> +}
> +
> static int exynos_bus_parent_parse_of(struct device_node *np,
> struct exynos_bus *bus)
> {
> @@ -366,6 +416,101 @@ static int exynos_bus_profile_init_passive(struct
> exynos_bus *bus,
> return 0;
> }
>
> +static int exynos_bus_icc_connect(struct exynos_bus *bus)
> +{
> + struct device_node *np = bus->dev->of_node;
> + struct devfreq *parent_devfreq;
> + struct icc_node *parent_node = NULL;
> + struct of_phandle_args args;
> + int ret = 0;
> +
> + parent_devfreq = devfreq_get_devfreq_by_phandle(bus->dev, 0);
> + if (!IS_ERR(parent_devfreq)) {
> + struct exynos_bus *parent_bus;
> +
> + parent_bus = dev_get_drvdata(parent_devfreq->dev.parent);
> + parent_node = parent_bus->node;
> + } else {
> + /* Look for parent in DT */
> + int num = of_count_phandle_with_args(np, "parent",
> + "#interconnect-cells");
> + if (num != 1)
> + goto out; /* 'parent' is optional */
> +
> + ret = of_parse_phandle_with_args(np, "parent",
> + "#interconnect-cells",
> + 0, );
> + if (ret < 0)
> + goto out;
> +
> + of_node_put(args.np);
> +
> + parent_node = of_icc_get_from_provider();
> + if (IS_ERR(parent_node)) {
> + /* May be -EPROBE_DEFER */
> + ret = PTR_ERR(parent_node);
> + goto out;
> + }
> + }
> +
> + ret = icc_link_create(bus->node, parent_node->id);
> +
> +out:
> + return ret;
> +}
> +
> +static int exynos_bus_icc_init(struct exynos_bus *bus)
> +{
> + struct device *dev = bus->dev;
> + struct icc_provider *provider = >provider;
> + struct icc_node *node;
> + int id, ret;
> +
> + /* Initialize the interconnect provider */
> + provider->set = exynos_bus_icc_set;
> + provider->aggregate = exynos_bus_icc_aggregate;
> + provider->xlate = exynos_bus_icc_xlate;
> + provider->dev = dev;
> + provider->data = bus;
> +
> + ret = icc_provider_add(provider);
> + if (ret < 0)
> + goto out;
> +
> + ret = id = exynos_bus_next_id();
> + if (ret < 0)
> + goto err_node;
> +
> + node = icc_node_create(id);
> + if (IS_ERR(node)) {
> + ret = PTR_ERR(node);
> + goto err_node;
> + }
> +
> + bus->node = node;
> + node->name = dev->of_node->name;
> + node->data = bus;
> + icc_node_add(node, provider);
> +
> + ret = exynos_bus_icc_connect(bus);
> + if (ret < 0)
> + goto err_connect;
> +
> + ret = dev_pm_qos_add_request(bus->devfreq->dev.parent, >qos_req,
> + DEV_PM_QOS_MIN_FREQUENCY, 0);
> +
> +out:
> + return ret;
> +
> +err_connect:
> + icc_node_del(node);
> + icc_node_destroy(id);
> +err_node:
> + icc_provider_del(provider);
> +
> + return ret;
> +}
> +
> static int exynos_bus_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -415,6 +560,14 @@ static int exynos_bus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err;
>
> + /*
> + * Initialize interconnect provider. A return value of -ENOTSUPP means
> + * that CONFIG_INTERCONNECT is disabled.
> + */
> + ret = exynos_bus_icc_init(bus);
> + if (ret < 0 && ret != -ENOTSUPP)
> + goto err;
> +
> max_state = bus->devfreq->profile->max_state;
> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
Hi, On 19. 9. 25. 오후 3:37, Artur Świgoń wrote: > On Wed, 2019-09-25 at 15:12 +0900, Chanwoo Choi wrote: >> Hi, >> >> On 19. 9. 25. 오후 2:47, Artur Świgoń wrote: >>> Hi, >>> >>> On Fri, 2019-09-20 at 11:14 +0900, Chanwoo Choi wrote: >>>> Hi Artur, >>>> >>>> I tried to just build this patch on mainline kernel or linux-next. >>>> But, when I applied them, merge conflict happens. You didn't develop >>>> them on latest version. Please rebase them based on latest mainline kernel. >>> >>> I developed on top of next-20190918 on which I applied >>> https://patchwork.kernel.org/cover/11149497/ as I mentioned in the cover >>> letter. The dev_pm_qos patches and my RFC have just cleanly rebased >>> together on >>> top of next-20190920. Could you check if you have the dev_pm_qos patches >>> (v5, >>> the version number is missing in this one; link above) and if so, where >>> does the >>> conflict appear? >> >> I faced on the merge conflict of drivers/devfreq/exynos-bus.c. >> I think that It is not related to to dev_pm_qos patch. > > I think that it is actually related to the specific version of dev_pm_qos > (v5) that > I used because patch 08/08 of dev_pm_qos series modifies exynos_bus_probe() in > drivers/devfreq/exynos-bus.c (https://patchwork.kernel.org/patch/11149507/). > > I will rebase the next RFC (v3) on latest dev_pm_qos patches from Leonard and > the > latest Linux-next kernel. My mistake. I only checked the Leonard's latest patches(v8) which doesn't contain this patch. OK. I'll try again. Thanks. [1] https://patchwork.kernel.org/patch/11149507/ - PM / devfreq: Move opp notifier registration to core > >> Maybe, Kamil's patches[1] changed the many things of exynos-bus.c >> If your test branch doesn't contain following patches, >> you need to rebase your patches based on latest mainline kernel >> from Linus Torvald. >> [1] https://patchwork.kernel.org/cover/11083663/ >> - [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800 > > Yes, requiring Kamil's patches is one of the changes in this RFC (v2), since > they > are already merged. > >> Today, I tried to apply these patch again based on latest mainline kernel. >> The merge conflict happen still. >> >> - merge conflict log >> Applying: devfreq: exynos-bus: Extract exynos_bus_profile_init() >> error: patch failed: drivers/devfreq/exynos-bus.c:334 >> error: drivers/devfreq/exynos-bus.c: patch does not apply >> Patch failed at 0001 devfreq: exynos-bus: Extract exynos_bus_profile_init() >> >> >>> >>>> On 19. 9. 20. 오전 10:07, Chanwoo Choi wrote: >>>>> Hi Artur, >>>>> >>>>> On v1, I mentioned that we need to discuss how to change >>>>> the v2 for this. But, I have not received any reply from you on v1. >>>>> And, without your reply from v1, you just send v2. >>>>> >>>>> I think that it is not proper development sequence. >>>>> I have spent many times to review your patches >>>>> and also I'll review your patches. You have to take care >>>>> the reply of reviewer and and keep the basic rule >>>>> of mailing contribution for discussion. >>>>> >>>>> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote: >>>>>> The following patchset adds interconnect[1][2] framework support to the >>>>>> exynos-bus devfreq driver. Extending the devfreq driver with interconnect >>>>>> capabilities started as a response to the issue referenced in [3]. The >>>>>> patches can be subdivided into four logical groups: >>>>>> >>>>>> (a) Refactoring the existing devfreq driver in order to improve >>>>>> readability >>>>>> and accommodate for adding new code (patches 01--04/11). >>>>>> >>>>>> (b) Tweaking the interconnect framework to support the exynos-bus use >>>>>> case >>>>>> (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to >>>>>> avoid hardcoding every single graph edge in the DT or driver source, and >>>>>> relaxing the requirement contained in that function removes the need to >>>>>> provide dummy node IDs in the DT. Adjusting the logic in >>>>>> apply_constraints() (drivers/interconnect/core.c) accounts for the fact >>>>>> that every bus is a separate entity and therefore a separate interc
Re: [RFC PATCH v2 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
Hi,
On 19. 9. 25. 오후 2:44, Artur Świgoń wrote:
> Hi,
>
> On Fri, 2019-09-20 at 11:15 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> As I already replied on v1, patch1/2/3 clean-up code
>> for readability without any behavior changes.
>>
>> I think that you better to merge patch1/2/3 to one patch.
>
> Yes, when writing the cover letter I think I forgot to explain why I decided
> not
> to merge these patches. Basically, none of the diff algorithms available in
> git
> (I've got v2.17.1) is able to produce a readable patch with these changes
> combined together into a single patch (functions are intermixed together in
> the
> output, git thinks that 'exynos_bus_probe' is a new function).
After merged three patches, as you commented, looks like that 'exynos_bus_probe'
is new function. Your patch style(three patches) is better than one merged
patch.
Keep your original patches. Thanks.
>
> Please take a look at the diff at the bottom of this message to see how
> patches
> 01..03 look when combined. If such patch looks acceptable to you, I can merge.
>
>> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
>>> From: Artur Świgoń
>>>
>>> This patch adds a new static function, exynos_bus_profile_init(), extracted
>>> from exynos_bus_probe().
>>>
>>> Signed-off-by: Artur Świgoń
>>> ---
>>> drivers/devfreq/exynos-bus.c | 92 +---
>>> 1 file changed, 53 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 29f422469960..78f38b7fb596 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -287,12 +287,62 @@ static int exynos_bus_parse_of(struct device_node *np,
>>> return ret;
>>> }
>>>
>>> +static int exynos_bus_profile_init(struct exynos_bus *bus,
>>> + struct devfreq_dev_profile *profile)
>>> +{
>>> + struct device *dev = bus->dev;
>>> + struct devfreq_simple_ondemand_data *ondemand_data;
>>> + int ret;
>>> +
>>> + /* Initialize the struct profile and governor data for parent device */
>>> + profile->polling_ms = 50;
>>> + profile->target = exynos_bus_target;
>>> + profile->get_dev_status = exynos_bus_get_dev_status;
>>> + profile->exit = exynos_bus_exit;
>>> +
>>> + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
>>> + if (!ondemand_data) {
>>> + ret = -ENOMEM;
>>> + goto err;
>>> + }
>>> + ondemand_data->upthreshold = 40;
>>> + ondemand_data->downdifferential = 5;
>>> +
>>> + /* Add devfreq device to monitor and handle the exynos bus */
>>> + bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> + ondemand_data);
>>> + if (IS_ERR(bus->devfreq)) {
>>> + dev_err(dev, "failed to add devfreq device\n");
>>> + ret = PTR_ERR(bus->devfreq);
>>> + goto err;
>>> + }
>>> +
>>> + /*
>>> +* Enable devfreq-event to get raw data which is used to determine
>>> +* current bus load.
>>> +*/
>>> + ret = exynos_bus_enable_edev(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable devfreq-event devices\n");
>>> + goto err;
>>> + }
>>> +
>>> + ret = exynos_bus_set_event(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to set event to devfreq-event devices\n");
>>> + goto err;
>>> + }
>>> +
>>> +err:
>>> + return ret;
>>> +}
>>> +
>>> static int exynos_bus_probe(struct platform_device *pdev)
>>> {
>>> struct device *dev = >dev;
>>> struct device_node *np = dev->of_node, *node;
>>> struct devfreq_dev_profile *profile;
>>> - struct devfreq_simple_ondemand_data *ondemand_data;
>>> struct devfreq_passive_data *passive_data;
>>> struct devfreq *parent_devfreq;
>>> struct exynos_bus *bus;
>>> @@ -334,45 +384,9 @@ static int exynos_bus_probe(struct platform_device
>>> *pdev)
>>> if (passive)
>>> goto passive;
>>>
