* [PATCH v2 09/15] PM / devfreq: rk3399_dmc: Support new disable-freq properties
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
Implement the newly-defined properties to allow disabling certain
power-saving-at-idle features at higher frequencies.
This is a rewritten version of work by Lin Huang <hl@rock-chips.com>.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
(no changes since v1)
drivers/devfreq/rk3399_dmc.c | 51 +++++++++++++++++++++++++++++++++---
1 file changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index c4efbc15cbb1..fc740c1f6747 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -55,6 +55,12 @@ struct rk3399_dmcfreq {
unsigned int ddr3_odt_dis_freq;
unsigned int lpddr3_odt_dis_freq;
unsigned int lpddr4_odt_dis_freq;
+
+ unsigned int pd_idle_dis_freq;
+ unsigned int sr_idle_dis_freq;
+ unsigned int sr_mc_gate_idle_dis_freq;
+ unsigned int srpd_lite_idle_dis_freq;
+ unsigned int standby_idle_dis_freq;
};
static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
@@ -81,8 +87,25 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
mutex_lock(&dmcfreq->lock);
if (dmcfreq->regmap_pmu) {
+ unsigned int odt_pd_arg0 = dmcfreq->odt_pd_arg0;
+ unsigned int odt_pd_arg1 = dmcfreq->odt_pd_arg1;
unsigned int odt_pd_arg2 = 0;
+ if (target_rate >= dmcfreq->sr_idle_dis_freq)
+ odt_pd_arg0 &= ~RK3399_SET_ODT_PD_0_SR_IDLE;
+
+ if (target_rate >= dmcfreq->sr_mc_gate_idle_dis_freq)
+ odt_pd_arg0 &= ~RK3399_SET_ODT_PD_0_SR_MC_GATE_IDLE;
+
+ if (target_rate >= dmcfreq->standby_idle_dis_freq)
+ odt_pd_arg0 &= ~RK3399_SET_ODT_PD_0_STANDBY_IDLE;
+
+ if (target_rate >= dmcfreq->pd_idle_dis_freq)
+ odt_pd_arg1 &= ~RK3399_SET_ODT_PD_1_PD_IDLE;
+
+ if (target_rate >= dmcfreq->srpd_lite_idle_dis_freq)
+ odt_pd_arg1 &= ~RK3399_SET_ODT_PD_1_SRPD_LITE_IDLE;
+
if (target_rate >= dmcfreq->odt_dis_freq)
odt_pd_arg2 |= RK3399_SET_ODT_PD_2_ODT_ENABLE;
@@ -91,10 +114,9 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
* (power-down) timings and to enable or disable the
* ODT (on-die termination) resistors.
*/
- arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
- dmcfreq->odt_pd_arg1,
- ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
- odt_pd_arg2, 0, 0, 0, &res);
+ arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, odt_pd_arg0, odt_pd_arg1,
+ ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD, odt_pd_arg2,
+ 0, 0, 0, &res);
}
/*
@@ -230,6 +252,16 @@ static int rk3399_dmcfreq_of_props(struct rk3399_dmcfreq *data,
{
int ret = 0;
+ /*
+ * These are all optional, and serve as minimum bounds. Give them large
+ * (i.e., never "disabled") values if the DT doesn't specify one.
+ */
+ data->pd_idle_dis_freq =
+ data->sr_idle_dis_freq =
+ data->sr_mc_gate_idle_dis_freq =
+ data->srpd_lite_idle_dis_freq =
+ data->standby_idle_dis_freq = UINT_MAX;
+
ret |= of_property_read_u32(np, "rockchip,pd_idle",
&data->pd_idle);
ret |= of_property_read_u32(np, "rockchip,sr_idle",
@@ -247,6 +279,17 @@ static int rk3399_dmcfreq_of_props(struct rk3399_dmcfreq *data,
ret |= of_property_read_u32(np, "rockchip,lpddr4_odt_dis_freq",
&data->lpddr4_odt_dis_freq);
+ ret |= of_property_read_u32(np, "rockchip,pd-idle-dis-freq-hz",
+ &data->pd_idle_dis_freq);
+ ret |= of_property_read_u32(np, "rockchip,sr-idle-dis-freq-hz",
+ &data->sr_idle_dis_freq);
+ ret |= of_property_read_u32(np, "rockchip,sr-mc-gate-idle-dis-freq-hz",
+ &data->sr_mc_gate_idle_dis_freq);
+ ret |= of_property_read_u32(np, "rockchip,srpd-lite-idle-dis-freq-hz",
+ &data->srpd_lite_idle_dis_freq);
+ ret |= of_property_read_u32(np, "rockchip,standby-idle-dis-freq-hz",
+ &data->standby_idle_dis_freq);
+
return ret;
}
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 08/15] PM / devfreq: rk3399_dmc: Use bitfield macro definitions for ODT_PD
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
We're going to add new usages, and it's cleaner to work with macros
instead of comments and magic numbers.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
(no changes since v1)
drivers/devfreq/rk3399_dmc.c | 43 ++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 8f447217303f..c4efbc15cbb1 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -5,6 +5,7 @@
*/
#include <linux/arm-smccc.h>
+#include <linux/bitfield.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/devfreq.h>
@@ -23,6 +24,15 @@
#include <soc/rockchip/rk3399_grf.h>
#include <soc/rockchip/rockchip_sip.h>
+#define RK3399_SET_ODT_PD_0_SR_IDLE GENMASK(7, 0)
+#define RK3399_SET_ODT_PD_0_SR_MC_GATE_IDLE GENMASK(15, 8)
+#define RK3399_SET_ODT_PD_0_STANDBY_IDLE GENMASK(31, 16)
+
+#define RK3399_SET_ODT_PD_1_PD_IDLE GENMASK(11, 0)
+#define RK3399_SET_ODT_PD_1_SRPD_LITE_IDLE GENMASK(27, 16)
+
+#define RK3399_SET_ODT_PD_2_ODT_ENABLE BIT(0)
+
struct rk3399_dmcfreq {
struct device *dev;
struct devfreq *devfreq;
@@ -55,7 +65,6 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
unsigned long old_clk_rate = dmcfreq->rate;
unsigned long target_volt, target_rate;
struct arm_smccc_res res;
- bool odt_enable = false;
int err;
opp = devfreq_recommended_opp(dev, freq, flags);
@@ -72,8 +81,10 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
mutex_lock(&dmcfreq->lock);
if (dmcfreq->regmap_pmu) {
+ unsigned int odt_pd_arg2 = 0;
+
if (target_rate >= dmcfreq->odt_dis_freq)
- odt_enable = true;
+ odt_pd_arg2 |= RK3399_SET_ODT_PD_2_ODT_ENABLE;
/*
* This makes a SMC call to the TF-A to set the DDR PD
@@ -83,7 +94,7 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
dmcfreq->odt_pd_arg1,
ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
- odt_enable, 0, 0, 0, &res);
+ odt_pd_arg2, 0, 0, 0, &res);
}
/*
@@ -316,23 +327,17 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
/*
* In TF-A there is a platform SIP call to set the PD (power-down)
* timings and to enable or disable the ODT (on-die termination).
- * This call needs three arguments as follows:
- *
- * arg0:
- * bit[0-7] : sr_idle
- * bit[8-15] : sr_mc_gate_idle
- * bit[16-31] : standby idle
- * arg1:
- * bit[0-11] : pd_idle
- * bit[16-27] : srpd_lite_idle
- * arg2:
- * bit[0] : odt enable
*/
- data->odt_pd_arg0 = (data->sr_idle & 0xff) |
- ((data->sr_mc_gate_idle & 0xff) << 8) |
- ((data->standby_idle & 0xffff) << 16);
- data->odt_pd_arg1 = (data->pd_idle & 0xfff) |
- ((data->srpd_lite_idle & 0xfff) << 16);
+ data->odt_pd_arg0 =
+ FIELD_PREP(RK3399_SET_ODT_PD_0_SR_IDLE, data->sr_idle) |
+ FIELD_PREP(RK3399_SET_ODT_PD_0_SR_MC_GATE_IDLE,
+ data->sr_mc_gate_idle) |
+ FIELD_PREP(RK3399_SET_ODT_PD_0_STANDBY_IDLE,
+ data->standby_idle);
+ data->odt_pd_arg1 =
+ FIELD_PREP(RK3399_SET_ODT_PD_1_PD_IDLE, data->pd_idle) |
+ FIELD_PREP(RK3399_SET_ODT_PD_1_SRPD_LITE_IDLE,
+ data->srpd_lite_idle);
/*
* We add a devfreq driver to our parent since it has a device tree node
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 07/15] PM / devfreq: rk3399_dmc: Drop excess timing properties
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
All of these properties are initialized by ARM Trusted Firmware, and
have been since the early days of this chip. It's redundant (and
possibly wrong) to do this here now. What's more, there seems to be some
confusion about the units and some of the definitions of this timing
struct: the DT docs say MHz for many of these, but downstream users were
in Hz (and therefore, the ATF interface was Hz). Also, the in-driver
usage for some of these (e.g., for comparing to target frequency) were
in Hz too. So doubly wrong.
We can avoid thinking about who got the right units by dropping the
unnecessary code and properties. They are marked deprecated in the
binding schema.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
(no changes since v1)
drivers/devfreq/rk3399_dmc.c | 144 +++++++----------------------------
1 file changed, 29 insertions(+), 115 deletions(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index e982862f6ac2..8f447217303f 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -23,38 +23,6 @@
#include <soc/rockchip/rk3399_grf.h>
#include <soc/rockchip/rockchip_sip.h>
-struct dram_timing {
- unsigned int ddr3_speed_bin;
- unsigned int pd_idle;
- unsigned int sr_idle;
- unsigned int sr_mc_gate_idle;
- unsigned int srpd_lite_idle;
- unsigned int standby_idle;
- unsigned int auto_pd_dis_freq;
- unsigned int dram_dll_dis_freq;
- unsigned int phy_dll_dis_freq;
- unsigned int ddr3_odt_dis_freq;
- unsigned int ddr3_drv;
- unsigned int ddr3_odt;
- unsigned int phy_ddr3_ca_drv;
- unsigned int phy_ddr3_dq_drv;
- unsigned int phy_ddr3_odt;
- unsigned int lpddr3_odt_dis_freq;
- unsigned int lpddr3_drv;
- unsigned int lpddr3_odt;
- unsigned int phy_lpddr3_ca_drv;
- unsigned int phy_lpddr3_dq_drv;
- unsigned int phy_lpddr3_odt;
- unsigned int lpddr4_odt_dis_freq;
- unsigned int lpddr4_drv;
- unsigned int lpddr4_dq_odt;
- unsigned int lpddr4_ca_odt;
- unsigned int phy_lpddr4_ca_drv;
- unsigned int phy_lpddr4_ck_cs_drv;
- unsigned int phy_lpddr4_dq_drv;
- unsigned int phy_lpddr4_odt;
-};
-
struct rk3399_dmcfreq {
struct device *dev;
struct devfreq *devfreq;
@@ -62,13 +30,21 @@ struct rk3399_dmcfreq {
struct clk *dmc_clk;
struct devfreq_event_dev *edev;
struct mutex lock;
- struct dram_timing timing;
struct regulator *vdd_center;
struct regmap *regmap_pmu;
unsigned long rate, target_rate;
unsigned long volt, target_volt;
unsigned int odt_dis_freq;
int odt_pd_arg0, odt_pd_arg1;
+
+ unsigned int pd_idle;
+ unsigned int sr_idle;
+ unsigned int sr_mc_gate_idle;
+ unsigned int srpd_lite_idle;
+ unsigned int standby_idle;
+ unsigned int ddr3_odt_dis_freq;
+ unsigned int lpddr3_odt_dis_freq;
+ unsigned int lpddr4_odt_dis_freq;
};
static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
@@ -238,69 +214,27 @@ static __maybe_unused int rk3399_dmcfreq_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(rk3399_dmcfreq_pm, rk3399_dmcfreq_suspend,
rk3399_dmcfreq_resume);
-static int of_get_ddr_timings(struct dram_timing *timing,
- struct device_node *np)
+static int rk3399_dmcfreq_of_props(struct rk3399_dmcfreq *data,
+ struct device_node *np)
{
int ret = 0;
- ret = of_property_read_u32(np, "rockchip,ddr3_speed_bin",
- &timing->ddr3_speed_bin);
ret |= of_property_read_u32(np, "rockchip,pd_idle",
- &timing->pd_idle);
+ &data->pd_idle);
ret |= of_property_read_u32(np, "rockchip,sr_idle",
- &timing->sr_idle);
+ &data->sr_idle);
ret |= of_property_read_u32(np, "rockchip,sr_mc_gate_idle",
- &timing->sr_mc_gate_idle);
+ &data->sr_mc_gate_idle);
ret |= of_property_read_u32(np, "rockchip,srpd_lite_idle",
- &timing->srpd_lite_idle);
+ &data->srpd_lite_idle);
ret |= of_property_read_u32(np, "rockchip,standby_idle",
- &timing->standby_idle);
- ret |= of_property_read_u32(np, "rockchip,auto_pd_dis_freq",
- &timing->auto_pd_dis_freq);
- ret |= of_property_read_u32(np, "rockchip,dram_dll_dis_freq",
- &timing->dram_dll_dis_freq);
- ret |= of_property_read_u32(np, "rockchip,phy_dll_dis_freq",
- &timing->phy_dll_dis_freq);
+ &data->standby_idle);
ret |= of_property_read_u32(np, "rockchip,ddr3_odt_dis_freq",
- &timing->ddr3_odt_dis_freq);
- ret |= of_property_read_u32(np, "rockchip,ddr3_drv",
- &timing->ddr3_drv);
- ret |= of_property_read_u32(np, "rockchip,ddr3_odt",
- &timing->ddr3_odt);
- ret |= of_property_read_u32(np, "rockchip,phy_ddr3_ca_drv",
- &timing->phy_ddr3_ca_drv);
- ret |= of_property_read_u32(np, "rockchip,phy_ddr3_dq_drv",
- &timing->phy_ddr3_dq_drv);
- ret |= of_property_read_u32(np, "rockchip,phy_ddr3_odt",
- &timing->phy_ddr3_odt);
+ &data->ddr3_odt_dis_freq);
ret |= of_property_read_u32(np, "rockchip,lpddr3_odt_dis_freq",
- &timing->lpddr3_odt_dis_freq);
- ret |= of_property_read_u32(np, "rockchip,lpddr3_drv",
- &timing->lpddr3_drv);
- ret |= of_property_read_u32(np, "rockchip,lpddr3_odt",
- &timing->lpddr3_odt);
- ret |= of_property_read_u32(np, "rockchip,phy_lpddr3_ca_drv",
- &timing->phy_lpddr3_ca_drv);
- ret |= of_property_read_u32(np, "rockchip,phy_lpddr3_dq_drv",
- &timing->phy_lpddr3_dq_drv);
- ret |= of_property_read_u32(np, "rockchip,phy_lpddr3_odt",
- &timing->phy_lpddr3_odt);
+ &data->lpddr3_odt_dis_freq);
ret |= of_property_read_u32(np, "rockchip,lpddr4_odt_dis_freq",
- &timing->lpddr4_odt_dis_freq);
- ret |= of_property_read_u32(np, "rockchip,lpddr4_drv",
- &timing->lpddr4_drv);
- ret |= of_property_read_u32(np, "rockchip,lpddr4_dq_odt",
- &timing->lpddr4_dq_odt);
- ret |= of_property_read_u32(np, "rockchip,lpddr4_ca_odt",
- &timing->lpddr4_ca_odt);
- ret |= of_property_read_u32(np, "rockchip,phy_lpddr4_ca_drv",
- &timing->phy_lpddr4_ca_drv);
- ret |= of_property_read_u32(np, "rockchip,phy_lpddr4_ck_cs_drv",
- &timing->phy_lpddr4_ck_cs_drv);
- ret |= of_property_read_u32(np, "rockchip,phy_lpddr4_dq_drv",
- &timing->phy_lpddr4_dq_drv);
- ret |= of_property_read_u32(np, "rockchip,phy_lpddr4_odt",
- &timing->phy_lpddr4_odt);
+ &data->lpddr4_odt_dis_freq);
return ret;
}
@@ -311,8 +245,7 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *np = pdev->dev.of_node, *node;
struct rk3399_dmcfreq *data;
- int ret, index, size;
- uint32_t *timing;
+ int ret;
struct dev_pm_opp *opp;
u32 ddr_type;
u32 val;
@@ -343,26 +276,7 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
return ret;
}
- /*
- * Get dram timing and pass it to arm trust firmware,
- * the dram driver in arm trust firmware will get these
- * timing and to do dram initial.
- */
- if (!of_get_ddr_timings(&data->timing, np)) {
- timing = &data->timing.ddr3_speed_bin;
- size = sizeof(struct dram_timing) / 4;
- for (index = 0; index < size; index++) {
- arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, *timing++, index,
- ROCKCHIP_SIP_CONFIG_DRAM_SET_PARAM,
- 0, 0, 0, 0, &res);
- if (res.a0) {
- dev_err(dev, "Failed to set dram param: %ld\n",
- res.a0);
- ret = -EINVAL;
- goto err_edev;
- }
- }
- }
+ rk3399_dmcfreq_of_props(data, np);
node = of_parse_phandle(np, "rockchip,pmu", 0);
if (!node)
@@ -381,13 +295,13 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
switch (ddr_type) {
case RK3399_PMUGRF_DDRTYPE_DDR3:
- data->odt_dis_freq = data->timing.ddr3_odt_dis_freq;
+ data->odt_dis_freq = data->ddr3_odt_dis_freq;
break;
case RK3399_PMUGRF_DDRTYPE_LPDDR3:
- data->odt_dis_freq = data->timing.lpddr3_odt_dis_freq;
+ data->odt_dis_freq = data->lpddr3_odt_dis_freq;
break;
case RK3399_PMUGRF_DDRTYPE_LPDDR4:
- data->odt_dis_freq = data->timing.lpddr4_odt_dis_freq;
+ data->odt_dis_freq = data->lpddr4_odt_dis_freq;
break;
default:
ret = -EINVAL;
@@ -414,11 +328,11 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
* arg2:
* bit[0] : odt enable
*/
- data->odt_pd_arg0 = (data->timing.sr_idle & 0xff) |
- ((data->timing.sr_mc_gate_idle & 0xff) << 8) |
- ((data->timing.standby_idle & 0xffff) << 16);
- data->odt_pd_arg1 = (data->timing.pd_idle & 0xfff) |
- ((data->timing.srpd_lite_idle & 0xfff) << 16);
+ data->odt_pd_arg0 = (data->sr_idle & 0xff) |
+ ((data->sr_mc_gate_idle & 0xff) << 8) |
+ ((data->standby_idle & 0xffff) << 16);
+ data->odt_pd_arg1 = (data->pd_idle & 0xfff) |
+ ((data->srpd_lite_idle & 0xfff) << 16);
/*
* We add a devfreq driver to our parent since it has a device tree node
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 06/15] PM / devfreq: rk3399_dmc: Drop undocumented ondemand DT props
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
These properties are:
* undocumented
* directly representing software properties, not hardware properties
* unused (no in-tree users, yet; this IP block has so far only been used
in downstream kernels)
Let's just stick the values that downstream users have been using
directly in the driver and call it a day.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
(no changes since v1)
drivers/devfreq/rk3399_dmc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 293857ebfd75..e982862f6ac2 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -430,10 +430,8 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
goto err_edev;
}
- of_property_read_u32(np, "upthreshold",
- &data->ondemand_data.upthreshold);
- of_property_read_u32(np, "downdifferential",
- &data->ondemand_data.downdifferential);
+ data->ondemand_data.upthreshold = 25;
+ data->ondemand_data.downdifferential = 15;
data->rate = clk_get_rate(data->dmc_clk);
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 05/15] dt-bindings: devfreq: rk3399_dmc: Add more disable-freq properties
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
DDR DVFS tuning has found that several power-saving features don't have
good tradeoffs at higher frequencies -- at higher frequencies, we'll see
glitches or other errors. Provide tuning controls so these can be
disabled at higher OPPs, and left active only at the lower ones.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Changes in v2:
- hyphens, not underscores
- *-hz units, and drop the types definition
.../bindings/devfreq/rk3399_dmc.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
index 8786b7fa9b28..afa058c52c0b 100644
--- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
@@ -299,6 +299,38 @@ properties:
self-refresh mode. The controller, pi, PHY and DRAM clock will be gated
if bus is idle for standby_idle nanoseconds.
+ rockchip,pd-idle-dis-freq-hz:
+ description:
+ Defines the power-down idle disable frequency in Hz. When the DDR
+ frequency is greater than pd-idle-dis-freq, power-down idle is disabled.
+ See also rockchip,pd-idle-ns.
+
+ rockchip,sr-idle-dis-freq-hz:
+ description:
+ Defines the self-refresh idle disable frequency in Hz. When the DDR
+ frequency is greater than sr-idle-dis-freq, self-refresh idle is
+ disabled. See also rockchip,sr-idle-ns.
+
+ rockchip,sr-mc-gate-idle-dis-freq-hz:
+ description:
+ Defines the self-refresh and memory-controller clock gating disable
+ frequency in Hz. When the DDR frequency is greater than
+ sr-mc-gate-idle-dis-freq, the clock will not be gated when idle. See also
+ rockchip,sr-mc-gate-idle-ns.
+
+ rockchip,srpd-lite-idle-dis-freq-hz:
+ description:
+ Defines the self-refresh power down idle disable frequency in Hz. When
+ the DDR frequency is greater than srpd-lite-idle-dis-freq, memory will
+ not be placed into self-refresh power down mode when idle. See also
+ rockchip,srpd-lite-idle-ns.
+
+ rockchip,standby-idle-dis-freq-hz:
+ description:
+ Defines the standby idle disable frequency in Hz. When the DDR frequency
+ is greater than standby-idle-dis-freq, standby idle is disabled. See also
+ rockchip,standby-idle-ns.
+
required:
- compatible
- devfreq-events
@@ -330,4 +362,9 @@ examples:
rockchip,ddr3_odt_dis_freq = <333000000>;
rockchip,lpddr3_odt_dis_freq = <333000000>;
rockchip,lpddr4_odt_dis_freq = <333000000>;
+ rockchip,pd-idle-dis-freq-hz = <1000000000>;
+ rockchip,sr-idle-dis-freq-hz = <1000000000>;
+ rockchip,sr-mc-gate-idle-dis-freq-hz = <1000000000>;
+ rockchip,srpd-lite-idle-dis-freq-hz = <0>;
+ rockchip,standby-idle-dis-freq-hz = <928000000>;
};
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 03/15] dt-bindings: devfreq: rk3399_dmc: Fix Hz units
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
The driver and all downstream device trees [1] are using Hz units, but
the document claims MHz. DRAM frequency for these systems can't possibly
exceed 2^32-1 Hz, so the choice of unit doesn't really matter than much.
Rather than add unnecessary risk in getting the units wrong, let's just
go with the unofficial convention and make the docs match reality.
A sub-1MHz frequency is extremely unlikely, so include a minimum in the
schema, to help catch anybody who might have believed this was MHz.
[1] And notably, also those trying to upstream them:
https://lore.kernel.org/lkml/20210308233858.24741-3-daniel.lezcano@linaro.org/
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
(no changes since v1)
.../bindings/devfreq/rk3399_dmc.yaml | 24 +++++++++----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
index fd62a8cd62d5..8bb778df92ae 100644
--- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
@@ -116,11 +116,11 @@ properties:
rockchip,ddr3_odt_dis_freq:
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1000000 # In case anyone thought this was MHz.
description:
When the DRAM type is DDR3, this parameter defines the ODT disable
- frequency in MHz (Mega Hz). When the DDR frequency is less then
- ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both
- disabled.
+ frequency in Hz. When the DDR frequency is less then ddr3_odt_dis_freq,
+ the ODT on the DRAM side and controller side are both disabled.
rockchip,ddr3_drv:
deprecated: true
@@ -160,11 +160,11 @@ properties:
rockchip,lpddr3_odt_dis_freq:
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1000000 # In case anyone thought this was MHz.
description:
When the DRAM type is LPDDR3, this parameter defines then ODT disable
- frequency in MHz (Mega Hz). When DDR frequency is less then
- ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both
- disabled.
+ frequency in Hz. When DDR frequency is less then ddr3_odt_dis_freq, the
+ ODT on the DRAM side and controller side are both disabled.
rockchip,lpddr3_drv:
deprecated: true
@@ -204,11 +204,11 @@ properties:
rockchip,lpddr4_odt_dis_freq:
$ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1000000 # In case anyone thought this was MHz.
description:
When the DRAM type is LPDDR4, this parameter defines the ODT disable
- frequency in MHz (Mega Hz). When the DDR frequency is less then
- ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both
- disabled.
+ frequency in Hz. When the DDR frequency is less then ddr3_odt_dis_freq,
+ the ODT on the DRAM side and controller side are both disabled.
rockchip,lpddr4_drv:
deprecated: true
@@ -287,7 +287,7 @@ examples:
rockchip,sr_mc_gate_idle = <0x3>;
rockchip,srpd_lite_idle = <0x4>;
rockchip,standby_idle = <0x2000>;
- rockchip,ddr3_odt_dis_freq = <333>;
- rockchip,lpddr3_odt_dis_freq = <333>;
- rockchip,lpddr4_odt_dis_freq = <333>;
+ rockchip,ddr3_odt_dis_freq = <333000000>;
+ rockchip,lpddr3_odt_dis_freq = <333000000>;
+ rockchip,lpddr4_odt_dis_freq = <333000000>;
};
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 04/15] dt-bindings: devfreq: rk3399_dmc: Specify idle params in nanoseconds
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
It's inefficient to use the same number of cycles for all OPPs, since
lower frequencies make for longer idle times. Let's specify the idle
time instead, so software can pick the optimal number of cycles on its
own.
NB: these bindings aren't used anywhere yet.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Changes in v2:
- New patch
.../bindings/devfreq/rk3399_dmc.yaml | 50 +++++++++++++++++--
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
index 8bb778df92ae..8786b7fa9b28 100644
--- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
@@ -55,42 +55,52 @@ properties:
being used.
rockchip,pd_idle:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
Configure the PD_IDLE value. Defines the power-down idle period in which
memories are placed into power-down mode if bus is idle for PD_IDLE DFI
clock cycles.
+ See also rockchip,pd-idle-ns.
rockchip,sr_idle:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
Configure the SR_IDLE value. Defines the self-refresh idle period in
which memories are placed into self-refresh mode if bus is idle for
SR_IDLE * 1024 DFI clock cycles (DFI clocks freq is half of DRAM clock).
Default value is "0".
+ See also rockchip,sr-idle-ns.
rockchip,sr_mc_gate_idle:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the memory self-refresh and controller clock gating idle period.
Memories are placed into self-refresh mode and memory controller clock
arg gating started if bus is idle for sr_mc_gate_idle*1024 DFI clock
cycles.
+ See also rockchip,sr-mc-gate-idle-ns.
rockchip,srpd_lite_idle:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the self-refresh power down idle period in which memories are
placed into self-refresh power down mode if bus is idle for
srpd_lite_idle * 1024 DFI clock cycles. This parameter is for LPDDR4
only.
+ See also rockchip,srpd-lite-idle-ns.
rockchip,standby_idle:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the standby idle period in which memories are placed into
self-refresh mode. The controller, pi, PHY and DRAM clock will be gated
if bus is idle for standby_idle * DFI clock cycles.
+ See also rockchip,standby-idle-ns.
rockchip,dram_dll_dis_freq:
deprecated: true
@@ -259,6 +269,36 @@ properties:
When the DRAM type is LPDDR4, this parameter defines the PHY side ODT
strength. Default value is 60.
+ rockchip,pd-idle-ns:
+ description:
+ Configure the PD_IDLE value in nanoseconds. Defines the power-down idle
+ period in which memories are placed into power-down mode if bus is idle
+ for PD_IDLE nanoseconds.
+
+ rockchip,sr-idle-ns:
+ description:
+ Configure the SR_IDLE value in nanoseconds. Defines the self-refresh idle
+ period in which memories are placed into self-refresh mode if bus is idle
+ for SR_IDLE nanoseconds. Default value is "0".
+
+ rockchip,sr-mc-gate-idle-ns:
+ description:
+ Defines the memory self-refresh and controller clock gating idle period in nanoseconds.
+ Memories are placed into self-refresh mode and memory controller clock
+ arg gating started if bus is idle for sr_mc_gate_idle nanoseconds.
+
+ rockchip,srpd-lite-idle-ns:
+ description:
+ Defines the self-refresh power down idle period in which memories are
+ placed into self-refresh power down mode if bus is idle for
+ srpd_lite_idle nanoseonds. This parameter is for LPDDR4 only.
+
+ rockchip,standby-idle-ns:
+ description:
+ Defines the standby idle period in which memories are placed into
+ self-refresh mode. The controller, pi, PHY and DRAM clock will be gated
+ if bus is idle for standby_idle nanoseconds.
+
required:
- compatible
- devfreq-events
@@ -282,11 +322,11 @@ examples:
clock-names = "dmc_clk";
operating-points-v2 = <&dmc_opp_table>;
center-supply = <&ppvar_centerlogic>;
- rockchip,pd_idle = <0x40>;
- rockchip,sr_idle = <0x2>;
- rockchip,sr_mc_gate_idle = <0x3>;
- rockchip,srpd_lite_idle = <0x4>;
- rockchip,standby_idle = <0x2000>;
+ rockchip,pd-idle-ns = <160>;
+ rockchip,sr-idle-ns = <10240>;
+ rockchip,sr-mc-gate-idle-ns = <40960>;
+ rockchip,srpd-lite-idle-ns = <61440>;
+ rockchip,standby-idle-ns = <81920>;
rockchip,ddr3_odt_dis_freq = <333000000>;
rockchip,lpddr3_odt_dis_freq = <333000000>;
rockchip,lpddr4_odt_dis_freq = <333000000>;
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 01/15] dt-bindings: devfreq: rk3399_dmc: Convert to YAML
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
I want to add, deprecate, and bugfix some properties, as well as add the
first users. This is easier with a proper schema.
The transformation is mostly straightforward, plus a few notable tweaks:
* Renamed rockchip,dram_speed_bin to rockchip,ddr3_speed_bin. The
driver code and the example matched, but the description was
different. I went with the implementation.
* Drop upthreshold and downdifferential properties from the example.
These were undocumented (so, wouldn't pass validation), but were
representing software properties (governor tweaks). I drop them from
the driver in subsequent patches.
* Rename clock from pclk_ddr_mon to dmc_clk. The driver, DT example,
and all downstream users matched -- the binding definition was the
exception. Anyway, "dmc_clk" is a more appropriately generic name.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Changes in v2:
* rename to 'memory-controller' in example
* place 'required' after properties
* drop superluous free-form references and repetitions of other
bindings
* fix for yamllint
.../bindings/devfreq/rk3399_dmc.txt | 212 -------------
.../bindings/devfreq/rk3399_dmc.yaml | 293 ++++++++++++++++++
2 files changed, 293 insertions(+), 212 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
deleted file mode 100644
index 58fc8a6cebc7..000000000000
--- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
+++ /dev/null
@@ -1,212 +0,0 @@
-* Rockchip rk3399 DMC (Dynamic Memory Controller) device
-
-Required properties:
-- compatible: Must be "rockchip,rk3399-dmc".
-- devfreq-events: Node to get DDR loading, Refer to
- Documentation/devicetree/bindings/devfreq/event/
- rockchip-dfi.txt
-- clocks: Phandles for clock specified in "clock-names" property
-- clock-names : The name of clock used by the DFI, must be
- "pclk_ddr_mon";
-- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
- for details.
-- center-supply: DMC supply node.
-- status: Marks the node enabled/disabled.
-- rockchip,pmu: Phandle to the syscon managing the "PMU general register
- files".
-
-Optional properties:
-- interrupts: The CPU interrupt number. The interrupt specifier
- format depends on the interrupt controller.
- It should be a DCF interrupt. When DDR DVFS finishes
- a DCF interrupt is triggered.
-- rockchip,pmu: Phandle to the syscon managing the "PMU general register
- files".
-
-Following properties relate to DDR timing:
-
-- rockchip,dram_speed_bin : Value reference include/dt-bindings/clock/rk3399-ddr.h,
- it selects the DDR3 cl-trp-trcd type. It must be
- set according to "Speed Bin" in DDR3 datasheet,
- DO NOT use a smaller "Speed Bin" than specified
- for the DDR3 being used.
-
-- rockchip,pd_idle : Configure the PD_IDLE value. Defines the
- power-down idle period in which memories are
- placed into power-down mode if bus is idle
- for PD_IDLE DFI clock cycles.
-
-- rockchip,sr_idle : Configure the SR_IDLE value. Defines the
- self-refresh idle period in which memories are
- placed into self-refresh mode if bus is idle
- for SR_IDLE * 1024 DFI clock cycles (DFI
- clocks freq is half of DRAM clock), default
- value is "0".
-
-- rockchip,sr_mc_gate_idle : Defines the memory self-refresh and controller
- clock gating idle period. Memories are placed
- into self-refresh mode and memory controller
- clock arg gating started if bus is idle for
- sr_mc_gate_idle*1024 DFI clock cycles.
-
-- rockchip,srpd_lite_idle : Defines the self-refresh power down idle
- period in which memories are placed into
- self-refresh power down mode if bus is idle
- for srpd_lite_idle * 1024 DFI clock cycles.
- This parameter is for LPDDR4 only.
-
-- rockchip,standby_idle : Defines the standby idle period in which
- memories are placed into self-refresh mode.
- The controller, pi, PHY and DRAM clock will
- be gated if bus is idle for standby_idle * DFI
- clock cycles.
-
-- rockchip,dram_dll_dis_freq : Defines the DDR3 DLL bypass frequency in MHz.
- When DDR frequency is less than DRAM_DLL_DISB_FREQ,
- DDR3 DLL will be bypassed. Note: if DLL was bypassed,
- the odt will also stop working.
-
-- rockchip,phy_dll_dis_freq : Defines the PHY dll bypass frequency in
- MHz (Mega Hz). When DDR frequency is less than
- DRAM_DLL_DISB_FREQ, PHY DLL will be bypassed.
- Note: PHY DLL and PHY ODT are independent.
-
-- rockchip,ddr3_odt_dis_freq : When the DRAM type is DDR3, this parameter defines
- the ODT disable frequency in MHz (Mega Hz).
- when the DDR frequency is less then ddr3_odt_dis_freq,
- the ODT on the DRAM side and controller side are
- both disabled.
-
-- rockchip,ddr3_drv : When the DRAM type is DDR3, this parameter defines
- the DRAM side driver strength in ohms. Default
- value is 40.
-
-- rockchip,ddr3_odt : When the DRAM type is DDR3, this parameter defines
- the DRAM side ODT strength in ohms. Default value
- is 120.
-
-- rockchip,phy_ddr3_ca_drv : When the DRAM type is DDR3, this parameter defines
- the phy side CA line (incluing command line,
- address line and clock line) driver strength.
- Default value is 40.
-
-- rockchip,phy_ddr3_dq_drv : When the DRAM type is DDR3, this parameter defines
- the PHY side DQ line (including DQS/DQ/DM line)
- driver strength. Default value is 40.
-
-- rockchip,phy_ddr3_odt : When the DRAM type is DDR3, this parameter defines
- the PHY side ODT strength. Default value is 240.
-
-- rockchip,lpddr3_odt_dis_freq : When the DRAM type is LPDDR3, this parameter defines
- then ODT disable frequency in MHz (Mega Hz).
- When DDR frequency is less then ddr3_odt_dis_freq,
- the ODT on the DRAM side and controller side are
- both disabled.
-
-- rockchip,lpddr3_drv : When the DRAM type is LPDDR3, this parameter defines
- the DRAM side driver strength in ohms. Default
- value is 34.
-
-- rockchip,lpddr3_odt : When the DRAM type is LPDDR3, this parameter defines
- the DRAM side ODT strength in ohms. Default value
- is 240.
-
-- rockchip,phy_lpddr3_ca_drv : When the DRAM type is LPDDR3, this parameter defines
- the PHY side CA line (including command line,
- address line and clock line) driver strength.
- Default value is 40.
-
-- rockchip,phy_lpddr3_dq_drv : When the DRAM type is LPDDR3, this parameter defines
- the PHY side DQ line (including DQS/DQ/DM line)
- driver strength. Default value is 40.
-
-- rockchip,phy_lpddr3_odt : When dram type is LPDDR3, this parameter define
- the phy side odt strength, default value is 240.
-
-- rockchip,lpddr4_odt_dis_freq : When the DRAM type is LPDDR4, this parameter
- defines the ODT disable frequency in
- MHz (Mega Hz). When the DDR frequency is less then
- ddr3_odt_dis_freq, the ODT on the DRAM side and
- controller side are both disabled.
-
-- rockchip,lpddr4_drv : When the DRAM type is LPDDR4, this parameter defines
- the DRAM side driver strength in ohms. Default
- value is 60.
-
-- rockchip,lpddr4_dq_odt : When the DRAM type is LPDDR4, this parameter defines
- the DRAM side ODT on DQS/DQ line strength in ohms.
- Default value is 40.
-
-- rockchip,lpddr4_ca_odt : When the DRAM type is LPDDR4, this parameter defines
- the DRAM side ODT on CA line strength in ohms.
- Default value is 40.
-
-- rockchip,phy_lpddr4_ca_drv : When the DRAM type is LPDDR4, this parameter defines
- the PHY side CA line (including command address
- line) driver strength. Default value is 40.
-
-- rockchip,phy_lpddr4_ck_cs_drv : When the DRAM type is LPDDR4, this parameter defines
- the PHY side clock line and CS line driver
- strength. Default value is 80.
-
-- rockchip,phy_lpddr4_dq_drv : When the DRAM type is LPDDR4, this parameter defines
- the PHY side DQ line (including DQS/DQ/DM line)
- driver strength. Default value is 80.
-
-- rockchip,phy_lpddr4_odt : When the DRAM type is LPDDR4, this parameter defines
- the PHY side ODT strength. Default value is 60.
-
-Example:
- dmc_opp_table: dmc_opp_table {
- compatible = "operating-points-v2";
-
- opp00 {
- opp-hz = /bits/ 64 <300000000>;
- opp-microvolt = <900000>;
- };
- opp01 {
- opp-hz = /bits/ 64 <666000000>;
- opp-microvolt = <900000>;
- };
- };
-
- dmc: dmc {
- compatible = "rockchip,rk3399-dmc";
- devfreq-events = <&dfi>;
- interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cru SCLK_DDRC>;
- clock-names = "dmc_clk";
- operating-points-v2 = <&dmc_opp_table>;
- center-supply = <&ppvar_centerlogic>;
- upthreshold = <15>;
- downdifferential = <10>;
- rockchip,ddr3_speed_bin = <21>;
- rockchip,pd_idle = <0x40>;
- rockchip,sr_idle = <0x2>;
- rockchip,sr_mc_gate_idle = <0x3>;
- rockchip,srpd_lite_idle = <0x4>;
- rockchip,standby_idle = <0x2000>;
- rockchip,dram_dll_dis_freq = <300>;
- rockchip,phy_dll_dis_freq = <125>;
- rockchip,auto_pd_dis_freq = <666>;
- rockchip,ddr3_odt_dis_freq = <333>;
- rockchip,ddr3_drv = <40>;
- rockchip,ddr3_odt = <120>;
- rockchip,phy_ddr3_ca_drv = <40>;
- rockchip,phy_ddr3_dq_drv = <40>;
- rockchip,phy_ddr3_odt = <240>;
- rockchip,lpddr3_odt_dis_freq = <333>;
- rockchip,lpddr3_drv = <34>;
- rockchip,lpddr3_odt = <240>;
- rockchip,phy_lpddr3_ca_drv = <40>;
- rockchip,phy_lpddr3_dq_drv = <40>;
- rockchip,phy_lpddr3_odt = <240>;
- rockchip,lpddr4_odt_dis_freq = <333>;
- rockchip,lpddr4_drv = <60>;
- rockchip,lpddr4_dq_odt = <40>;
- rockchip,lpddr4_ca_odt = <40>;
- rockchip,phy_lpddr4_ca_drv = <40>;
- rockchip,phy_lpddr4_ck_cs_drv = <80>;
- rockchip,phy_lpddr4_dq_drv = <80>;
- rockchip,phy_lpddr4_odt = <60>;
- };
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
new file mode 100644
index 000000000000..467a7b5b374b
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
@@ -0,0 +1,293 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# %YAML 1.2
+---
+$id: http://devicetree.org/schemas/devfreq/rk3399_dmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip rk3399 DMC (Dynamic Memory Controller) device
+
+maintainers:
+ - Brian Norris <briannorris@chromium.org>
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk3399-dmc
+
+ devfreq-events:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ description:
+ Node to get DDR loading. Refer to
+ Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt.
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: dmc_clk
+
+ operating-points-v2: true
+
+ center-supply:
+ description:
+ DMC regulator supply.
+
+ rockchip,pmu:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the syscon managing the "PMU general register files".
+
+ interrupts:
+ maxItems: 1
+ description:
+ The CPU interrupt number. It should be a DCF interrupt. When DDR DVFS
+ finishes, a DCF interrupt is triggered.
+
+ rockchip,ddr3_speed_bin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ For values, reference include/dt-bindings/clock/rk3399-ddr.h. Selects the
+ DDR3 cl-trp-trcd type. It must be set according to "Speed Bin" in DDR3
+ datasheet; DO NOT use a smaller "Speed Bin" than specified for the DDR3
+ being used.
+
+ rockchip,pd_idle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Configure the PD_IDLE value. Defines the power-down idle period in which
+ memories are placed into power-down mode if bus is idle for PD_IDLE DFI
+ clock cycles.
+
+ rockchip,sr_idle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Configure the SR_IDLE value. Defines the self-refresh idle period in
+ which memories are placed into self-refresh mode if bus is idle for
+ SR_IDLE * 1024 DFI clock cycles (DFI clocks freq is half of DRAM clock).
+ Default value is "0".
+
+ rockchip,sr_mc_gate_idle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines the memory self-refresh and controller clock gating idle period.
+ Memories are placed into self-refresh mode and memory controller clock
+ arg gating started if bus is idle for sr_mc_gate_idle*1024 DFI clock
+ cycles.
+
+ rockchip,srpd_lite_idle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines the self-refresh power down idle period in which memories are
+ placed into self-refresh power down mode if bus is idle for
+ srpd_lite_idle * 1024 DFI clock cycles. This parameter is for LPDDR4
+ only.
+
+ rockchip,standby_idle:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines the standby idle period in which memories are placed into
+ self-refresh mode. The controller, pi, PHY and DRAM clock will be gated
+ if bus is idle for standby_idle * DFI clock cycles.
+
+ rockchip,dram_dll_dis_freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Defines the DDR3 DLL bypass frequency in MHz. When DDR frequency is less
+ than DRAM_DLL_DISB_FREQ, DDR3 DLL will be bypassed.
+ Note: if DLL was bypassed, the odt will also stop working.
+
+ rockchip,phy_dll_dis_freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Defines the PHY dll bypass frequency in MHz (Mega Hz). When DDR frequency
+ is less than DRAM_DLL_DISB_FREQ, PHY DLL will be bypassed.
+ Note: PHY DLL and PHY ODT are independent.
+
+ rockchip,auto_pd_dis_freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Defines the auto PD disable frequency in MHz.
+
+ rockchip,ddr3_odt_dis_freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is DDR3, this parameter defines the ODT disable
+ frequency in MHz (Mega Hz). When the DDR frequency is less then
+ ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both
+ disabled.
+
+ rockchip,ddr3_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is DDR3, this parameter defines the DRAM side drive
+ strength in ohms. Default value is 40.
+
+ rockchip,ddr3_odt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is DDR3, this parameter defines the DRAM side ODT
+ strength in ohms. Default value is 120.
+
+ rockchip,phy_ddr3_ca_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is DDR3, this parameter defines the phy side CA line
+ (incluing command line, address line and clock line) drive strength.
+ Default value is 40.
+
+ rockchip,phy_ddr3_dq_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is DDR3, this parameter defines the PHY side DQ line
+ (including DQS/DQ/DM line) drive strength. Default value is 40.
+
+ rockchip,phy_ddr3_odt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is DDR3, this parameter defines the PHY side ODT
+ strength. Default value is 240.
+
+ rockchip,lpddr3_odt_dis_freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR3, this parameter defines then ODT disable
+ frequency in MHz (Mega Hz). When DDR frequency is less then
+ ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both
+ disabled.
+
+ rockchip,lpddr3_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR3, this parameter defines the DRAM side drive
+ strength in ohms. Default value is 34.
+
+ rockchip,lpddr3_odt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR3, this parameter defines the DRAM side ODT
+ strength in ohms. Default value is 240.
+
+ rockchip,phy_lpddr3_ca_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR3, this parameter defines the PHY side CA line
+ (including command line, address line and clock line) drive strength.
+ Default value is 40.
+
+ rockchip,phy_lpddr3_dq_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR3, this parameter defines the PHY side DQ line
+ (including DQS/DQ/DM line) drive strength. Default value is 40.
+
+ rockchip,phy_lpddr3_odt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When dram type is LPDDR3, this parameter define the phy side odt
+ strength, default value is 240.
+
+ rockchip,lpddr4_odt_dis_freq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the ODT disable
+ frequency in MHz (Mega Hz). When the DDR frequency is less then
+ ddr3_odt_dis_freq, the ODT on the DRAM side and controller side are both
+ disabled.
+
+ rockchip,lpddr4_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the DRAM side drive
+ strength in ohms. Default value is 60.
+
+ rockchip,lpddr4_dq_odt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on
+ DQS/DQ line strength in ohms. Default value is 40.
+
+ rockchip,lpddr4_ca_odt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on
+ CA line strength in ohms. Default value is 40.
+
+ rockchip,phy_lpddr4_ca_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the PHY side CA line
+ (including command address line) drive strength. Default value is 40.
+
+ rockchip,phy_lpddr4_ck_cs_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the PHY side clock
+ line and CS line drive strength. Default value is 80.
+
+ rockchip,phy_lpddr4_dq_drv:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the PHY side DQ line
+ (including DQS/DQ/DM line) drive strength. Default value is 80.
+
+ rockchip,phy_lpddr4_odt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ When the DRAM type is LPDDR4, this parameter defines the PHY side ODT
+ strength. Default value is 60.
+
+required:
+ - compatible
+ - devfreq-events
+ - clocks
+ - clock-names
+ - operating-points-v2
+ - center-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/rk3399-cru.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ memory-controller {
+ compatible = "rockchip,rk3399-dmc";
+ devfreq-events = <&dfi>;
+ rockchip,pmu = <&pmu>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_DDRC>;
+ clock-names = "dmc_clk";
+ operating-points-v2 = <&dmc_opp_table>;
+ center-supply = <&ppvar_centerlogic>;
+ rockchip,ddr3_speed_bin = <21>;
+ rockchip,pd_idle = <0x40>;
+ rockchip,sr_idle = <0x2>;
+ rockchip,sr_mc_gate_idle = <0x3>;
+ rockchip,srpd_lite_idle = <0x4>;
+ rockchip,standby_idle = <0x2000>;
+ rockchip,dram_dll_dis_freq = <300>;
+ rockchip,phy_dll_dis_freq = <125>;
+ rockchip,auto_pd_dis_freq = <666>;
+ rockchip,ddr3_odt_dis_freq = <333>;
+ rockchip,ddr3_drv = <40>;
+ rockchip,ddr3_odt = <120>;
+ rockchip,phy_ddr3_ca_drv = <40>;
+ rockchip,phy_ddr3_dq_drv = <40>;
+ rockchip,phy_ddr3_odt = <240>;
+ rockchip,lpddr3_odt_dis_freq = <333>;
+ rockchip,lpddr3_drv = <34>;
+ rockchip,lpddr3_odt = <240>;
+ rockchip,phy_lpddr3_ca_drv = <40>;
+ rockchip,phy_lpddr3_dq_drv = <40>;
+ rockchip,phy_lpddr3_odt = <240>;
+ rockchip,lpddr4_odt_dis_freq = <333>;
+ rockchip,lpddr4_drv = <60>;
+ rockchip,lpddr4_dq_odt = <40>;
+ rockchip,lpddr4_ca_odt = <40>;
+ rockchip,phy_lpddr4_ca_drv = <40>;
+ rockchip,phy_lpddr4_ck_cs_drv = <80>;
+ rockchip,phy_lpddr4_dq_drv = <80>;
+ rockchip,phy_lpddr4_odt = <60>;
+ };
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 02/15] dt-bindings: devfreq: rk3399_dmc: Deprecate unused/redundant properties
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
In-Reply-To: <20220127230727.3369358-1-briannorris@chromium.org>
These DRAM configuration properties are all handled in ARM Trusted
Firmware (and have been since the early days of this SoC), and there are
no in-tree users of the DMC binding yet. It's better to just defer to
firmware instead of maintaining this large list of properties.
There's also some confusion about units: many of these are specified in
MHz, but the downstream users and driver code are treating them as Hz, I
believe. Rather than straighten all that out, I just drop them.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
(no changes since v1)
.../bindings/devfreq/rk3399_dmc.yaml | 42 +++++++++----------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
index 467a7b5b374b..fd62a8cd62d5 100644
--- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
@@ -46,6 +46,7 @@ properties:
finishes, a DCF interrupt is triggered.
rockchip,ddr3_speed_bin:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
For values, reference include/dt-bindings/clock/rk3399-ddr.h. Selects the
@@ -92,6 +93,7 @@ properties:
if bus is idle for standby_idle * DFI clock cycles.
rockchip,dram_dll_dis_freq:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Defines the DDR3 DLL bypass frequency in MHz. When DDR frequency is less
@@ -99,6 +101,7 @@ properties:
Note: if DLL was bypassed, the odt will also stop working.
rockchip,phy_dll_dis_freq:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Defines the PHY dll bypass frequency in MHz (Mega Hz). When DDR frequency
@@ -106,6 +109,7 @@ properties:
Note: PHY DLL and PHY ODT are independent.
rockchip,auto_pd_dis_freq:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the auto PD disable frequency in MHz.
@@ -119,18 +123,21 @@ properties:
disabled.
rockchip,ddr3_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is DDR3, this parameter defines the DRAM side drive
strength in ohms. Default value is 40.
rockchip,ddr3_odt:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is DDR3, this parameter defines the DRAM side ODT
strength in ohms. Default value is 120.
rockchip,phy_ddr3_ca_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is DDR3, this parameter defines the phy side CA line
@@ -138,12 +145,14 @@ properties:
Default value is 40.
rockchip,phy_ddr3_dq_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is DDR3, this parameter defines the PHY side DQ line
(including DQS/DQ/DM line) drive strength. Default value is 40.
rockchip,phy_ddr3_odt:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is DDR3, this parameter defines the PHY side ODT
@@ -158,18 +167,21 @@ properties:
disabled.
rockchip,lpddr3_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR3, this parameter defines the DRAM side drive
strength in ohms. Default value is 34.
rockchip,lpddr3_odt:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR3, this parameter defines the DRAM side ODT
strength in ohms. Default value is 240.
rockchip,phy_lpddr3_ca_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR3, this parameter defines the PHY side CA line
@@ -177,12 +189,14 @@ properties:
Default value is 40.
rockchip,phy_lpddr3_dq_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR3, this parameter defines the PHY side DQ line
(including DQS/DQ/DM line) drive strength. Default value is 40.
rockchip,phy_lpddr3_odt:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When dram type is LPDDR3, this parameter define the phy side odt
@@ -197,42 +211,49 @@ properties:
disabled.
rockchip,lpddr4_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR4, this parameter defines the DRAM side drive
strength in ohms. Default value is 60.
rockchip,lpddr4_dq_odt:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on
DQS/DQ line strength in ohms. Default value is 40.
rockchip,lpddr4_ca_odt:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR4, this parameter defines the DRAM side ODT on
CA line strength in ohms. Default value is 40.
rockchip,phy_lpddr4_ca_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR4, this parameter defines the PHY side CA line
(including command address line) drive strength. Default value is 40.
rockchip,phy_lpddr4_ck_cs_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR4, this parameter defines the PHY side clock
line and CS line drive strength. Default value is 80.
rockchip,phy_lpddr4_dq_drv:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR4, this parameter defines the PHY side DQ line
(including DQS/DQ/DM line) drive strength. Default value is 80.
rockchip,phy_lpddr4_odt:
+ deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
description:
When the DRAM type is LPDDR4, this parameter defines the PHY side ODT
@@ -261,33 +282,12 @@ examples:
clock-names = "dmc_clk";
operating-points-v2 = <&dmc_opp_table>;
center-supply = <&ppvar_centerlogic>;
- rockchip,ddr3_speed_bin = <21>;
rockchip,pd_idle = <0x40>;
rockchip,sr_idle = <0x2>;
rockchip,sr_mc_gate_idle = <0x3>;
rockchip,srpd_lite_idle = <0x4>;
rockchip,standby_idle = <0x2000>;
- rockchip,dram_dll_dis_freq = <300>;
- rockchip,phy_dll_dis_freq = <125>;
- rockchip,auto_pd_dis_freq = <666>;
rockchip,ddr3_odt_dis_freq = <333>;
- rockchip,ddr3_drv = <40>;
- rockchip,ddr3_odt = <120>;
- rockchip,phy_ddr3_ca_drv = <40>;
- rockchip,phy_ddr3_dq_drv = <40>;
- rockchip,phy_ddr3_odt = <240>;
rockchip,lpddr3_odt_dis_freq = <333>;
- rockchip,lpddr3_drv = <34>;
- rockchip,lpddr3_odt = <240>;
- rockchip,phy_lpddr3_ca_drv = <40>;
- rockchip,phy_lpddr3_dq_drv = <40>;
- rockchip,phy_lpddr3_odt = <240>;
rockchip,lpddr4_odt_dis_freq = <333>;
- rockchip,lpddr4_drv = <60>;
- rockchip,lpddr4_dq_odt = <40>;
- rockchip,lpddr4_ca_odt = <40>;
- rockchip,phy_lpddr4_ca_drv = <40>;
- rockchip,phy_lpddr4_ck_cs_drv = <80>;
- rockchip,phy_lpddr4_dq_drv = <80>;
- rockchip,phy_lpddr4_odt = <60>;
};
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 00/15] rk3399: Clean up and enable DDR DVFS
From: Brian Norris @ 2022-01-27 23:07 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring
Cc: linux-kernel, linux-rockchip, Lin Huang, linux-arm-kernel,
Derek Basehore, devicetree, linux-pm, Heiko Stuebner,
Brian Norris
This series covers 2 primary tasks:
1) Resubmit prior work:
[RESEND PATCH v5 3/4] arm64: dts: rockchip: Enable dmc and dfi nodes on gru.
https://lore.kernel.org/lkml/20210308233858.24741-2-daniel.lezcano@linaro.org/
[RESEND PATCH v5 2/4] arm64: dts: rk3399: Add dfi and dmc nodes.
https://lore.kernel.org/lkml/20210308233858.24741-3-daniel.lezcano@linaro.org/
This series was partially merged a while back, but the remaining 2
patches were blocked mostly on stylistic grounds (alpha/numerical
ordering).
2) Integrate many updates, bugfixes, and clarifications that were done
by Rockchip and Google engineers when first launching this platform.
Many of these were not integrated in the earlier series (e.g., the OPPs
changed before production; earlier patchsets used pre-production
numbers).
Along the way, it seemed worthwhile to convert the binding docs to a
schema. Among other reasons, it actually helped catch several errors and
omissions in translation between downstream device trees and the version
that actually landed upstream.
See the patches for further details.
Regards,
Brian
Changes in v2:
- Fix yamllint issues
- Adapt to various review comments (use of *-hz, hyphens, node naming)
- Add a few new bugfixes
- Add some new properties (ported from downstream kernels) required for
stability
- Convert more properties from "cycles" to "nanoseconds"
Brian Norris (13):
dt-bindings: devfreq: rk3399_dmc: Convert to YAML
dt-bindings: devfreq: rk3399_dmc: Deprecate unused/redundant
properties
dt-bindings: devfreq: rk3399_dmc: Fix Hz units
dt-bindings: devfreq: rk3399_dmc: Specify idle params in nanoseconds
dt-bindings: devfreq: rk3399_dmc: Add more disable-freq properties
PM / devfreq: rk3399_dmc: Drop undocumented ondemand DT props
PM / devfreq: rk3399_dmc: Drop excess timing properties
PM / devfreq: rk3399_dmc: Use bitfield macro definitions for ODT_PD
PM / devfreq: rk3399_dmc: Support new disable-freq properties
PM / devfreq: rk3399_dmc: Support new *-ns properties
PM / devfreq: rk3399_dmc: Disable edev on remove()
PM / devfreq: rk3399_dmc: Use devm_pm_opp_of_add_table()
PM / devfreq: rk3399_dmc: Avoid static (reused) profile
Lin Huang (2):
arm64: dts: rk3399: Add dfi and dmc nodes
arm64: dts: rockchip: Enable dmc and dfi nodes on gru
.../bindings/devfreq/rk3399_dmc.txt | 212 ----------
.../bindings/devfreq/rk3399_dmc.yaml | 370 ++++++++++++++++++
.../dts/rockchip/rk3399-gru-chromebook.dtsi | 7 +
.../boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 12 +
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 28 ++
.../boot/dts/rockchip/rk3399-op1-opp.dtsi | 25 ++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 19 +
drivers/devfreq/rk3399_dmc.c | 299 +++++++-------
8 files changed, 595 insertions(+), 377 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.yaml
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8m{m,n}_venice*: add gpio-line-names
From: Tim Harvey @ 2022-01-27 22:49 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Device Tree Mailing List, open list,
Linux ARM Mailing List
In-Reply-To: <20220126090739.GH4686@dragon>
On Wed, Jan 26, 2022 at 1:07 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Tue, Dec 14, 2021 at 04:18:12PM -0800, Tim Harvey wrote:
> > Add gpio-line-names for the various GPIO's used on Gateworks Venice
> > boards. Note that these GPIO's are typically 'configured' in Boot
> > Firmware via gpio-hog therefore we only configure line names to keep the
> > boot firmware configuration from changing on kernel init.
> >
> > Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>
> It doesn't apply to my imx/dt64 branch. Could you rebase?
>
Shawn,
Sure, I'll try to submit another version within a couple of days.
Did you happen to see 'arm64: dts: imx8mm-venice*: add PCIe support'
[1]? It seems to have been archived for some reason and it may have to
be rebased after I re-post this one unless you can take that now.
Best Regards,
Tim
[1] - https://patchwork.kernel.org/project/linux-arm-kernel/patch/20211216164149.13333-1-tharvey@gateworks.com/
^ permalink raw reply
* Re: [PATCH net-next 4/7] net: lan966x: Implement SIOCSHWTSTAMP and SIOCGHWTSTAMP
From: Richard Cochran @ 2022-01-27 21:55 UTC (permalink / raw)
To: Horatiu Vultur
Cc: netdev, devicetree, linux-kernel, davem, kuba, robh+dt,
UNGLinuxDriver, linux, f.fainelli, vivien.didelot,
vladimir.oltean, andrew
In-Reply-To: <20220127102333.987195-5-horatiu.vultur@microchip.com>
On Thu, Jan 27, 2022 at 11:23:30AM +0100, Horatiu Vultur wrote:
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c b/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c
> index 69d8f43e2b1b..9ff4d3fca5a1 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c
> @@ -35,6 +35,90 @@ static u64 lan966x_ptp_get_nominal_value(void)
> return res;
> }
>
> +int lan966x_ptp_hwtstamp_set(struct lan966x_port *port, struct ifreq *ifr)
> +{
> + struct lan966x *lan966x = port->lan966x;
> + bool l2 = false, l4 = false;
> + struct hwtstamp_config cfg;
> + struct lan966x_phc *phc;
> +
> + /* For now don't allow to run ptp on ports that are part of a bridge,
> + * because in case of transparent clock the HW will still forward the
> + * frames, so there would be duplicate frames
> + */
> + if (lan966x->bridge_mask & BIT(port->chip_port))
> + return -EINVAL;
> +
> + if (copy_from_user(&cfg, ifr->ifr_data, sizeof(cfg)))
> + return -EFAULT;
> +
> + switch (cfg.tx_type) {
> + case HWTSTAMP_TX_ON:
> + port->ptp_cmd = IFH_REW_OP_TWO_STEP_PTP;
> + break;
> + case HWTSTAMP_TX_ONESTEP_SYNC:
> + port->ptp_cmd = IFH_REW_OP_ONE_STEP_PTP;
> + break;
> + case HWTSTAMP_TX_OFF:
> + port->ptp_cmd = IFH_REW_OP_NOOP;
> + break;
> + default:
> + return -ERANGE;
> + }
> +
> + mutex_lock(&lan966x->ptp_lock);
No need to lock stack variables. Move locking down to ...
> + switch (cfg.rx_filter) {
> + case HWTSTAMP_FILTER_NONE:
> + break;
> + case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
> + l4 = true;
> + break;
> + case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
> + l2 = true;
> + break;
> + case HWTSTAMP_FILTER_PTP_V2_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
> + l2 = true;
> + l4 = true;
> + break;
> + default:
> + mutex_unlock(&lan966x->ptp_lock);
> + return -ERANGE;
> + }
> +
> + if (l2 && l4)
> + cfg.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
> + else if (l2)
> + cfg.rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT;
> + else if (l4)
> + cfg.rx_filter = HWTSTAMP_FILTER_PTP_V2_L4_EVENT;
> + else
> + cfg.rx_filter = HWTSTAMP_FILTER_NONE;
> +
> + /* Commit back the result & save it */
... here
> + phc = &lan966x->phc[LAN966X_PHC_PORT];
> + memcpy(&phc->hwtstamp_config, &cfg, sizeof(cfg));
> + mutex_unlock(&lan966x->ptp_lock);
> +
> + return copy_to_user(ifr->ifr_data, &cfg, sizeof(cfg)) ? -EFAULT : 0;
> +}
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v8 3/3] usb: dwc3: xilinx: Add ULPI PHY reset handling
From: Robert Hancock @ 2022-01-27 21:45 UTC (permalink / raw)
To: sean.anderson@seco.com, linux-usb@vger.kernel.org
Cc: manish.narani@xilinx.com, michal.simek@xilinx.com,
piyush.mehta@xilinx.com, gregkh@linuxfoundation.org,
balbi@kernel.org, robh+dt@kernel.org, devicetree@vger.kernel.org
In-Reply-To: <a0505ff0-093b-eb67-98b0-b2c93a2771ab@seco.com>
On Thu, 2022-01-27 at 15:10 -0500, Sean Anderson wrote:
> Hi Rob,
>
> On 1/26/22 6:40 PM, Robert Hancock wrote:
> > Hook up an optional GPIO-based reset for the connected USB ULPI PHY
> > device. This is typically already done by the first-stage boot loader,
> > however it can be more robust to ensure this reset is done prior to
> > loading the driver in Linux.
> >
> > Based on a patch "usb: dwc3: xilinx: Add gpio-reset support" in the
> > Xilinx kernel tree by Piyush Mehta <piyush.mehta@xilinx.com>.
> >
> > Signed-off-by: Robert Hancock <robert.hancock@calian.com>
> > ---
> > drivers/usb/dwc3/dwc3-xilinx.c | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-
> > xilinx.c
> > index a6f3a9b38789..1ee6011ada44 100644
> > --- a/drivers/usb/dwc3/dwc3-xilinx.c
> > +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> > @@ -11,6 +11,7 @@
> > #include <linux/slab.h>
> > #include <linux/clk.h>
> > #include <linux/of.h>
> > +#include <linux/gpio/consumer.h>
> > #include <linux/platform_device.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/of_platform.h>
> > @@ -101,6 +102,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx
> > *priv_data)
> > struct phy *usb3_phy;
> > int ret = 0;
> > u32 reg;
> > + struct gpio_desc *reset_gpio;
> >
> > usb3_phy = devm_phy_optional_get(dev, "usb3-phy");
> > if (IS_ERR(usb3_phy)) {
> > @@ -110,6 +112,14 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx
> > *priv_data)
> > goto err;
> > }
> >
> > + reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(reset_gpio)) {
> > + ret = PTR_ERR(reset_gpio);
> > + dev_err_probe(dev, ret,
> > + "Failed to get reset gpio\n");
> > + goto err;
> > + }
> > +
> > /*
> > * The following core resets are not required unless a USB3 PHY
> > * is used, and the subsequent register settings are not required
> > @@ -201,6 +211,15 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx
> > *priv_data)
> > }
> >
> > skip_usb3_phy:
> > + /* ulpi reset via gpio-modepin or gpio-framework driver */
> > + if (reset_gpio) {
> > + /* Toggle ulpi to reset the phy. */
> > + gpiod_set_value(reset_gpio, 0);
> > + usleep_range(5000, 10000); /* delay */
> > + gpiod_set_value(reset_gpio, 1);
> > + usleep_range(5000, 10000); /* delay */
> > + }
> > +
> > /*
> > * This routes the USB DMA traffic to go through FPD path instead
> > * of reaching DDR directly. This traffic routing is needed to
> >
>
> Do we need to have this in dwc3? Why not just use the usb-nop-xceiv driver
> (aka usb_phy_generic)?
I hadn't noticed that option. Just tried it out and it seems like it does
what's needed. So patches 2 and 3 can be dispensed with. Patch 1 is still
needed however, I may resubmit that as a standalone patch..
>
> --Sean
--
Robert Hancock
Senior Hardware Designer, Calian Advanced Technologies
www.calian.com
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: Jacek Anaszewski @ 2022-01-27 21:24 UTC (permalink / raw)
To: sven, linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, robh+dt, thierry.reding, u.kleine-koenig,
lee.jones, post
In-Reply-To: <20220126104844.246068-2-sven@svenschwermer.de>
Hi Sven,
On 1/26/22 11:48 AM, sven@svenschwermer.de wrote:
> From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
>
> This allows to group multiple PWM-connected monochrome LEDs into
> multicolor LEDs, e.g. RGB LEDs.
>
> Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> ---
[...]
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/leds/common.h>
> +
> + rgb-led {
> + compatible = "pwm-leds-multicolor";
> +
> + multi-led {
> + color = <LED_COLOR_ID_RGB>;
> + function = LED_FUNCTION_INDICATOR;
> + max-brightness = <65535>;
It doesn't make much sense to have such a big resolution of global
multi color brightness. 255 will be sufficient.
> + led-red {
> + pwms = <&pwm1 0 1000000>;
> + color = <LED_COLOR_ID_RED>;
> + };
> +
> + led-green {
> + pwms = <&pwm2 0 1000000>;
> + color = <LED_COLOR_ID_GREEN>;
> + };
> +
> + led-blue {
> + pwms = <&pwm3 0 1000000>;
> + color = <LED_COLOR_ID_BLUE>;
> + };
> + };
> + };
> +
> +...
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1
From: Stephen Boyd @ 2022-01-27 21:16 UTC (permalink / raw)
To: Bjorn Andersson, Doug Anderson, Viresh Kumar
Cc: Konrad Dybcio, kgodara, Matthias Kaehlcke, Sibi Sankar,
Prasad Malisetty, quic_rjendra, Andy Gross, Rob Herring,
devicetree, linux-arm-msm, LKML
In-Reply-To: <YfC5i2jR5N+pmHoZ@ripper>
Quoting Bjorn Andersson (2022-01-25 19:01:31)
> On Tue 25 Jan 15:46 PST 2022, Doug Anderson wrote:
>
> > Hi,
> >
> > On Tue, Jan 25, 2022 at 2:58 PM Stephen Boyd <swboyd@chromium.org> wrote:
> > >
> > > Quoting Douglas Anderson (2022-01-25 14:44:22)
> > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> > > > new file mode 100644
> > > > index 000000000000..f95273052da0
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> > > > @@ -0,0 +1,313 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > +/*
> > > > + * Google Herobrine board device tree source
> > > > + *
> > > > + * Copyright 2022 Google LLC.
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +#include "sc7280-herobrine.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "Google Herobrine (rev1+)";
> > > > + compatible = "google,herobrine", "qcom,sc7280";
> > >
> > > Can we stop adding "qcom,sc7280" to the board compatible string? It
> > > looks out of place. It's the compatible for the SoC and should really be
> > > the compatible for the /soc node.
> >
> > I don't have any objections, but I feel like this is the type of thing
> > I'd like Bjorn to have the final say on. What say you, Bjorn?
> >
>
> One practical case I can think of right away, where this matters is in
> cpufreq-dt-plat.c where we blocklist qcom,sc7280.
>
> I don't know if we rely on this in any other places, but I'm not keen on
> seeing a bunch of board-specific compatibles sprinkled throughout the
> implementation - it's annoying enough having to add each platform to
> these drivers.
Looking at sc7180, grep only shows cpufreq-dt-plat.c
$ git grep qcom,sc7180\" -- drivers
drivers/cpufreq/cpufreq-dt-platdev.c: { .compatible = "qcom,sc7180", },
Simplest solution would be to look at / and /soc for a compatible
string.
$ git grep -W 'soc[^:]*{' -- arch/arm*/boot/dts/ | grep compatible |
grep -v "simple-bus"
doesn't show many hits. The first hit is "ti,omap-infra" which is
actually inside an soc node, but even then I don't see anything that
matches the cpufreq-dt-plat.c lists.
----8<-----
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index ca1d103ec449..32bfe453f8b4 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -179,25 +179,29 @@ static bool __init cpu0_node_has_opp_v2_prop(void)
static int __init cpufreq_dt_platdev_init(void)
{
struct device_node *np = of_find_node_by_path("/");
+ struct device_node *soc_np = of_find_node_by_path("/soc");
const struct of_device_id *match;
const void *data = NULL;
- if (!np)
+ if (!np && !soc_np)
return -ENODEV;
match = of_match_node(allowlist, np);
- if (match) {
+ if (match || (match = of_match_node(allowlist, soc_np))) {
data = match->data;
goto create_pdev;
}
- if (cpu0_node_has_opp_v2_prop() && !of_match_node(blocklist, np))
+ if (cpu0_node_has_opp_v2_prop() && !of_match_node(blocklist, np) &&
+ !of_match_node(blocklist, soc_np))
goto create_pdev;
+ of_node_put(soc_np);
of_node_put(np);
return -ENODEV;
create_pdev:
+ of_node_put(soc_np);
of_node_put(np);
return PTR_ERR_OR_ZERO(platform_device_register_data(NULL, "cpufreq-dt",
-1, data,
^ permalink raw reply related
* Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics
From: Luca Weiss @ 2022-01-27 20:51 UTC (permalink / raw)
To: Petr Vorel, linux-arm-msm, Rob Herring, Krzysztof Kozlowski
Cc: Shawn Guo, Oleksij Rempel, Sam Ravnborg, Linus Walleij,
Daniel Palmer, Max Merchel, Hao Fang, devicetree, linux-kernel,
Jean THOMAS
In-Reply-To: <c69d1daf-45c8-3ac5-a0b0-bb853593c54e@canonical.com>
Hi all,
On Donnerstag, 27. Jänner 2022 08:45:33 CET Krzysztof Kozlowski wrote:
> On 27/01/2022 01:20, Petr Vorel wrote:
> > Hi all,
> >
> >>> Hi Krzysztof,
> >>>
> >>> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
> >>>> On 12/09/2021 01:27, Luca Weiss wrote:
> >>>>> LG Electronics is a part of the LG Corporation and produces, amongst
> >>>>> other things, consumer electronics such as phones and smartwatches.
> >>>>
> >>>> Hi,
> >>>>
> >>>> Thanks for the patches.
> >>>>
> >>>> I think "lge" it's the same prefix as "lg". There is no sense in having
> >>>> multiple vendor prefixes just because company splits inside business
> >>>> units or subsidiaries. The same as with other conglomerates, e.g.
> >>>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
> >>>> vendors... Not mentioning that company organisation is not always
> >>>> disclosed and can change.
> >>>
> >>> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the
> >>> other LG device tree I am aware of so I've picked lge instead of lg.
> >>> Also worth noting that Google uses "LGE" in the Android device tree[1]
> >>> or in the model name in the LG G Watch R kernel sources ("LGE APQ
> >>> 8026v2 LENOK rev-1.0")
> >>
> >> [1] Does not point to kernel tree. Downstream user could be a good
> >> argument to switch to lge, but then I would expect correcting other "lg"
> >> devices which are in fact made by LGE.
> >>
> >>> I don't have a strong opinion either way so I'm fine with either.
> >>>
> >>> If we decide to go with "lg" do we want to change the Nexus 5 devicetree
> >>> (hammerhead) also, that one has the lge name in at least compatible and
> >>> filename (I don't know how much of a breaking change that would be
> >>> considered as).
> >>
> >> We would have to add a new one and mark the old compatible as deprecated.
> >
> > Have we sorted this lg- vs. lge- ?
> >
> > There are both:
> > arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> > vs
> > arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
>
> Probably renaming/unifying/correcting prefix in existing compatibles is
> not worth the effort. This would make a mess and affect other DTS users.
If wanted I can send a patch renaming the Nexus 5 to just LG, this would
adjust both compatible in the file (which shouldn't really affect anything) and
the filename (which probably will affect various scripts and whatnot used by
existing users of the dtb).
Is this something that can be done in mainline or should we rather just let it
be? I'm not sure what the policies there are.
Regards
Luca
> Most of existing usages of "lg" prefix are panels which are coming from
> another subsidiary of LG - LG Display. We all use there "lg" prefix, not
> "lgd".
> Plus mention before Bullhead mobile phone which is coming from LG
> Electronics.
>
> If we use generalized "lg" prefix for one subsidiary (LG Display), then
> let's do the same for another subsidiary - LG Electronics. Plus entire
> branding of LG Electronics products is LG: the website, the logo,
> advertisements. Everywhere except legal footer.
>
> I vote for using "lg" for both subsidiaries: LG Display and LG Electronics.
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] drm/panel: Add MIPI DBI compatible SPI driver
From: Noralf Trønnes @ 2022-01-27 20:26 UTC (permalink / raw)
To: Sam Ravnborg
Cc: robh+dt, thierry.reding, maxime, dave.stevenson, david,
devicetree, dri-devel
In-Reply-To: <YfL5ptT3Kw1ohC/1@ravnborg.org>
Den 27.01.2022 20.59, skrev Sam Ravnborg:
> Hi Noralf,
>
> On Tue, Jan 25, 2022 at 06:57:00PM +0100, Noralf Trønnes wrote:
>> Add a driver that will work with most MIPI DBI compatible SPI panels.
>> This avoids adding a driver for every new MIPI DBI compatible controller
>> that is to be used by Linux. The 'compatible' Device Tree property with
>> a '.bin' suffix will be used to load a firmware file that contains the
>> controller configuration.
>
> Loading a configuration from a firmware file is very
> elegant - I like.
> This will be very useful in a million cases with a lot of small panels!
>
Yes I really hope we can find a way to get this accepted.
>> +
>> + /*
>> + * Optional MIPI commands to execute when the display pipeline is enabled.
>> + * This can be used to configure the display controller.
>> + *
>> + * The commands are stored in a byte array with the format:
>> + * command, num_parameters, [ parameter, ...], command, ...
>> + *
>> + * Some commands require a pause before the next command can be received.
>> + * Inserting a delay in the command sequence is done by using the NOP command with one
>> + * parameter: delay in miliseconds (the No Operation command is part of the MIPI Display
>> + * Command Set where it has no parameters).
>> + *
>> + * Example:
>> + * command 0x11
>> + * sleep 120ms
>> + * command 0xb1 parameters 0x01, 0x2c, 0x2d
>> + * command 0x29
>> + *
>> + * Byte sequence:
>> + * 0x11 0x00
>> + * 0x00 0x01 0x78
>> + * 0xb1 0x03 0x01 0x2c 0x2d
>> + * 0x29 0x00
>> + */
> Using a binary file that is unreadable when it is first created is less
> elegant.
> I am sure you have considered a txt file - and I know parsing a txt file
> in prone for more errros than parsing a binary file.
>
>
> But if the text file looked like:
> "
> # The is a comment
> cmd 0x11 0x00
>
> # We need to sleep
> sleepms 120
>
> # Do something more
> cmd 0xb1 0x03 0x01 0x2c 0x2d
> cmd 0x29 0x00
> "
>
> The file is easier to comment (document) and easier to read and
> modify.
> The suffix could be ".panel" to tell this is something specific for
> a panel.
> Using lib/parser could make the code somewhat simple but I did not try
> to code it myself.
>
> The code you included below for the binary file is very simple,
> but you shift the burden to the people who have to create binary files.
> And people using obscure displays are not always so good at this stuff.
>
Parsing text files in the kernel sounds very scary, not something that I
would like to try.
I will make a script that generates and parses the binary representation
(which is big endian so it's somewhat readable with xxd or the like).
There's a wiki link in the MAINTAINERS entry that will have info about
the format including the script. It will also serve as a place to share
config snippets/script incantations for displays.
I will make the script when the file format is decided upon. Here's the
hack I currently use:
https://gist.github.com/notro/3ca61c48e7dcc4a0ef34dbadbc30bfa5
Noralf.
^ permalink raw reply
* Re: [PATCH v21 3/4] PCI: microchip: Add host driver for Microchip PCIe controller
From: Bjorn Helgaas @ 2022-01-27 20:20 UTC (permalink / raw)
To: daire.mcnamara
Cc: lorenzo.pieralisi, bhelgaas, robh, linux-pci, robh+dt, devicetree,
david.abdurachmanov, cyril.jean, Marc Zyngier
In-Reply-To: <20210125162934.5335-4-daire.mcnamara@microchip.com>
[+cc Marc]
On Mon, Jan 25, 2021 at 04:29:33PM +0000, daire.mcnamara@microchip.com wrote:
> From: Daire McNamara <daire.mcnamara@microchip.com>
>
> Add support for the Microchip PolarFire PCIe controller when
> configured in host (Root Complex) mode.
> +static void mc_handle_msi(struct irq_desc *desc)
> +{
> + struct mc_port *port = irq_desc_get_handler_data(desc);
> + struct device *dev = port->dev;
> + struct mc_msi *msi = &port->msi;
> + void __iomem *bridge_base_addr = port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
> + unsigned long status;
> + u32 bit;
> + u32 virq;
> +
> + status = readl_relaxed(bridge_base_addr + ISTATUS_LOCAL);
> + if (status & PM_MSI_INT_MSI_MASK) {
> + status = readl_relaxed(bridge_base_addr + ISTATUS_MSI);
> + for_each_set_bit(bit, &status, msi->num_vectors) {
> + virq = irq_find_mapping(msi->dev_domain, bit);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err_ratelimited(dev, "bad MSI IRQ %d\n", bit);
> + }
> + }
> +}
> +
> +static void mc_msi_bottom_irq_ack(struct irq_data *data)
> +{
> + struct mc_port *port = irq_data_get_irq_chip_data(data);
> + void __iomem *bridge_base_addr = port->axi_base_addr + MC_PCIE_BRIDGE_ADDR;
> + u32 bitpos = data->hwirq;
> + unsigned long status;
> +
> + writel_relaxed(BIT(bitpos), bridge_base_addr + ISTATUS_MSI);
> + status = readl_relaxed(bridge_base_addr + ISTATUS_MSI);
> + if (!status)
> + writel_relaxed(BIT(PM_MSI_INT_MSI_SHIFT), bridge_base_addr + ISTATUS_LOCAL);
This looks like it might be racy. What happens if we read 0 from
ISTATUS_MSI, but a new MSI is latched before we write ISTATUS_LOCAL?
Will mc_handle_msi() be called? If so, will PM_MSI_INT_MSI_MASK be
set in the value it reads from ISTATUS_LOCAL?
Current code at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pcie-microchip-host.c?id=v5.17-rc1#n406
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels
From: Rob Herring @ 2022-01-27 20:18 UTC (permalink / raw)
To: Maxime Ripard
Cc: Noralf Trønnes, Thierry Reding, Sam Ravnborg, Dave Stevenson,
David Lechner, devicetree, dri-devel
In-Reply-To: <20220127093624.6gozbr6gl4ft66fz@houat>
On Thu, Jan 27, 2022 at 3:36 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> Hi Rob,
>
> On Mon, Jan 24, 2022 at 10:42:37AM -0600, Rob Herring wrote:
> > On Mon, Jan 24, 2022 at 10:28 AM Noralf Trønnes <noralf@tronnes.org> wrote:
> > >
> > >
> > >
> > > Den 24.01.2022 17.08, skrev Rob Herring:
> > > > On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes <noralf@tronnes.org> wrote:
> > > >>
> > > >> Add binding for MIPI DBI compatible SPI panels.
> > > >
> > > > I'm sure we already have MIPI DBI panels. What's this for?
> > > >
> > >
> > > It aims to use one driver to cover all MIPI DBI panels where the
> > > controller setup is loaded from userspace in a firmware file.
> >
> > What's the solution when the user wants a splash screen in the
> > bootloader and also wants multiple panels supported?
> >
> > Also, 1 driver doesn't dictate 1 compatible. A one to many
> > relationship is fine and makes the decision entirely the OS's.
> >
> > > The cover
> > > letter points to the discussion where Maxime proposed this:
> > >
> > > https://lore.kernel.org/dri-devel/20211129093946.xhp22mvdut3m67sc@houat/
> >
> > The proposal there is:
> >
> > > compatible = "panel-spi";
> > > model = "panel-from-random-place-42";
> >
> > The same thing can be accomplished with this:
> >
> > compatible = "panel-from-random-place-42", "panel-spi";
> >
> > What's the advantage of hijacking 'model'?
>
> So, the main issue is that a panel is essentially two things: a
> controller and the actual panel.
>
> The controller has an initialization sequence of its own, and part of it
> is parameters to match the panel.
>
> So you can have identical controllers that won't have the same
> initialization sequence because they don't have the same panel.
>
> I was assuming that a compatible would be more about the controller, so
> we needed something else, thus "model"
We already have cases like that which have "foo,some-panel", "bar,a-ctrlr-ic".
Rob
^ permalink raw reply
* Respuesta FOESCO
From: Foesco @ 2022-01-27 20:06 UTC (permalink / raw)
To: devicetree
Buenos días
Adjuntamos en PDF el listado de Cursos Bonificables E-learning disponibles para la convocatoria FEBRERO 2022.
Todos los cursos impartidos son 100% Bonificables con cargo al Crédito de Formación 2022 y van dirigidos a empleados, no autónomos.
Para poder consultar a FUNDAE vuestro crédito de formación disponible se ha de cumplimentar y firmar el documento adjunto CONTRATO DE ENCOMIENDA y mandarlo a esta misma dirección de correo electrónico.
INSTRUCCIONES DE SOLICITUD:
Se han de cumplimentar únicamente los siguientes datos de la FICHA DE INSCRIPCIÓN adjunta (1 impreso por curso) y se ha de mandar escaneado o en fotografía a esta misma dirección de correo electrónico.
- Curso a realizar
- Nombre completo y DNI del alumno
- Número de afiliación a la Seguridad Social del alumno (Dato indicado en las nóminas)
- Teléfono y e-mail del alumno
- Nombre y CIF de la empresa
- Dirección de la empresa
- Teléfono y e-mail de la empresa
- Teléfono y e-mail del gestor de la empresa
- Cta. Cotización a la seguridad social de la empresa (Dato indicado en las nóminas)
- Año de creación de la empresa
- Nombre completo y DNI de un representante legal de la empresa
- Firma del representante legal de la empresa.
- Sello de la empresa.
- Firma del alumno.
Según el Real Decreto 18/2021 referente a los ERTES, necesitaremos además vuestra respuesta a las siguientes cuestiones:
- Número de empleados en activo en la empresa:
- Número de empleados en situación de ERTE en la empresa:
- Indique si su empresa ha renovado ERTE a partir del 1 de noviembre de 2021 hasta el 28 de febrero 2022:
Quedamos a la espera de vuestra respuesta.
Un cordial saludo.
Departamento de Formación Bonificable
FOESCO Formación Estatal Continua.
Empresa inscrita en el Registro de empresas de Formación.
www.foesco.com
e-mail: cursos@foesco.net
Tel: 910 323 794
(Horario de 9h a 15h y de 17h a 20h de Lunes a Viernes)
FOESCO ofrece formación a empresas y trabajadores en activo a través de cursos bonificados por la Fundación Estatal para la Formación en el Empleo (antiguo FORCEM) que gestiona las acciones formativas de FORMACIÓN CONTINUA para trabajadores y se rige por la ley 30/2015 de 9 de Septiembre.
Antes de imprimir este e-mail piense bien si es necesario hacerlo. La información transmitida en este mensaje está dirigida solamente a las personas o entidades que figuran en el encabezamiento y contiene información confidencial, por lo que, si usted lo recibiera por error, por favor destrúyalo sin copiarlo, usarlo ni distribuirlo, comunicándolo inmediatamente al emisor del mensaje. De conformidad con lo dispuesto en el Reglamento Europeo del 2016/679, del 27 de Abril de 2016, FOESCO le informa que los datos por usted suministrados serán tratados con las medidas de seguridad conformes a la normativa vigente que se requiere. Dichos datos serán empleados con fines de gestión. Para el ejercicio de sus derechos de transparencia, información, acceso, rectificación, supresión o derecho al olvido, limitación del tratamiento , portabilidad de datos y oposición de sus datos de carácter personal deberá dirigirse a la dirección del Responsable del tratamiento a C/ LAGUNA DEL MARQUESADO Nº10, 28021, MADRID, "PULSANDO AQUI" <mailto:bajas@foesco.com?Subject=BAJA%20CORREOS> y "ENVIAR".
^ permalink raw reply
* Re: [PATCH v8 3/3] usb: dwc3: xilinx: Add ULPI PHY reset handling
From: Sean Anderson @ 2022-01-27 20:10 UTC (permalink / raw)
To: Robert Hancock, linux-usb
Cc: balbi, gregkh, michal.simek, manish.narani, robh+dt, devicetree,
piyush.mehta
In-Reply-To: <20220126234017.3619108-4-robert.hancock@calian.com>
Hi Rob,
On 1/26/22 6:40 PM, Robert Hancock wrote:
> Hook up an optional GPIO-based reset for the connected USB ULPI PHY
> device. This is typically already done by the first-stage boot loader,
> however it can be more robust to ensure this reset is done prior to
> loading the driver in Linux.
>
> Based on a patch "usb: dwc3: xilinx: Add gpio-reset support" in the
> Xilinx kernel tree by Piyush Mehta <piyush.mehta@xilinx.com>.
>
> Signed-off-by: Robert Hancock <robert.hancock@calian.com>
> ---
> drivers/usb/dwc3/dwc3-xilinx.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> index a6f3a9b38789..1ee6011ada44 100644
> --- a/drivers/usb/dwc3/dwc3-xilinx.c
> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> @@ -11,6 +11,7 @@
> #include <linux/slab.h>
> #include <linux/clk.h>
> #include <linux/of.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/platform_device.h>
> #include <linux/dma-mapping.h>
> #include <linux/of_platform.h>
> @@ -101,6 +102,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
> struct phy *usb3_phy;
> int ret = 0;
> u32 reg;
> + struct gpio_desc *reset_gpio;
>
> usb3_phy = devm_phy_optional_get(dev, "usb3-phy");
> if (IS_ERR(usb3_phy)) {
> @@ -110,6 +112,14 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
> goto err;
> }
>
> + reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(reset_gpio)) {
> + ret = PTR_ERR(reset_gpio);
> + dev_err_probe(dev, ret,
> + "Failed to get reset gpio\n");
> + goto err;
> + }
> +
> /*
> * The following core resets are not required unless a USB3 PHY
> * is used, and the subsequent register settings are not required
> @@ -201,6 +211,15 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
> }
>
> skip_usb3_phy:
> + /* ulpi reset via gpio-modepin or gpio-framework driver */
> + if (reset_gpio) {
> + /* Toggle ulpi to reset the phy. */
> + gpiod_set_value(reset_gpio, 0);
> + usleep_range(5000, 10000); /* delay */
> + gpiod_set_value(reset_gpio, 1);
> + usleep_range(5000, 10000); /* delay */
> + }
> +
> /*
> * This routes the USB DMA traffic to go through FPD path instead
> * of reaching DDR directly. This traffic routing is needed to
>
Do we need to have this in dwc3? Why not just use the usb-nop-xceiv driver (aka usb_phy_generic)?
--Sean
^ permalink raw reply
* Re: [PATCH v2 3/3] drm/panel: Add MIPI DBI compatible SPI driver
From: Noralf Trønnes @ 2022-01-27 20:08 UTC (permalink / raw)
To: David Lechner, robh+dt, thierry.reding
Cc: sam, maxime, dave.stevenson, devicetree, dri-devel
In-Reply-To: <2ee03a80-fddb-e28c-1c29-cd88759ed849@lechnology.com>
Den 27.01.2022 18.19, skrev David Lechner:
> On 1/25/22 11:57 AM, Noralf Trønnes wrote:
>> Add a driver that will work with most MIPI DBI compatible SPI panels.
>> This avoids adding a driver for every new MIPI DBI compatible controller
>> that is to be used by Linux. The 'compatible' Device Tree property with
>> a '.bin' suffix will be used to load a firmware file that contains the
>> controller configuration.
>>
>> Example (driver will load sainsmart18.bin):
>>
>> display@0 {
>> compatible = "sainsmart18", "panel-mipi-dbi-spi";
>> reg = <0>;
>> reset-gpios = <&gpio 25 0>;
>> dc-gpios = <&gpio 24 0>;
>> };
>>
>
> ...
>
>> +static int panel_mipi_dbi_spi_probe(struct spi_device *spi)
>> +{
>> + struct device *dev = &spi->dev;
>> + struct drm_display_mode mode;
>> + struct mipi_dbi_dev *dbidev;
>> + const struct firmware *fw;
>> + const char *compatible;
>> + struct drm_device *drm;
>> + struct property *prop;
>> + bool fw_found = false;
>> + struct mipi_dbi *dbi;
>> + struct gpio_desc *dc;
>> + char fw_name[40];
>> + int ret;
>> +
>> + dbidev = devm_drm_dev_alloc(dev, &panel_mipi_dbi_driver, struct
>> mipi_dbi_dev, drm);
>> + if (IS_ERR(dbidev))
>> + return PTR_ERR(dbidev);
>> +
>> + dbi = &dbidev->dbi;
>> + drm = &dbidev->drm;
>> +
>> + of_property_for_each_string(dev->of_node, "compatible", prop,
>> compatible) {
>> + snprintf(fw_name, sizeof(fw_name), "%s.bin", compatible);
>> +
>> + ret = firmware_request_nowarn(&fw, fw_name, dev);
>> + if (ret) {
>> + drm_dbg(drm, "No config file found for compatible: '%s'
>> (error=%d)\n",
>> + compatible, ret);
>> + continue;
>> + }
>> +
>
> Should we add a directory prefix to the firmware file name to avoid the
> possibility of
> file name clashes with unrelated firmwares?
I did consider this but I think it very unlikely that there would be a
collision between the name of display/panel and some other firmware file
which usually have the product name/model in the filename. And in the
unlikelihood that there is a collision it's possible to choose another
name for the compatible.
Noralf.
^ permalink raw reply
* [PATCH v3 7/7] arm64: dts: ipq6018: Use reference clock to set dwc3 period
From: Sean Anderson @ 2022-01-27 20:06 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb
Cc: Robert Hancock, Baruch Siach, Felipe Balbi, Thinh Nguyen,
linux-kernel, Balaji Prakash J, Sean Anderson, Andy Gross,
Bjorn Andersson, Rob Herring, devicetree, linux-arm-msm
In-Reply-To: <20220127200636.1456175-1-sean.anderson@seco.com>
Instead of manually setting snps,ref-clock-period-ns, we can let the
driver calculate it automatically from the "ref" clock. I haven't
reviewed this board's schematics, so please let me know if this is the
wrong 24MHz clock to use.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
(no changes since v1)
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 66ec5615651d..a614b9f73e2c 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -743,12 +743,13 @@ dwc_0: usb@8A00000 {
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
phys = <&qusb_phy_0>, <&usb0_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
+ clocks = <&xo>;
+ clock-names = "ref";
tx-fifo-resize;
snps,is-utmi-l1-suspend;
snps,hird-threshold = /bits/ 8 <0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_u3_susphy_quirk;
- snps,ref-clock-period-ns = <0x32>;
dr_mode = "host";
};
};
--
2.25.1
^ permalink raw reply related
* [PATCH v3 6/7] arm64: dts: zynqmp: Move USB clocks to dwc3 node
From: Sean Anderson @ 2022-01-27 20:06 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb
Cc: Robert Hancock, Baruch Siach, Felipe Balbi, Thinh Nguyen,
linux-kernel, Balaji Prakash J, Sean Anderson, Michal Simek,
Rob Herring, devicetree, linux-arm-kernel
In-Reply-To: <20220127200636.1456175-1-sean.anderson@seco.com>
These clocks are not used by the dwc3-xilinx driver except to
enable/disable them. Move them to the dwc3 node so its driver can use
them to configure the reference clock period.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Robert Hancock <robert.hancock@calian.com>
Tested-by: Robert Hancock <robert.hancock@calian.com>
---
(no changes since v1)
arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 4 ++--
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
index 1e0b1bca7c94..8493dd7d5f1f 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
@@ -223,11 +223,11 @@ &uart1 {
clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
};
-&usb0 {
+&dwc3_0 {
clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
};
-&usb1 {
+&dwc3_1 {
clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
};
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 74e66443e4ce..ba68fb8529ee 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -811,7 +811,6 @@ usb0: usb@ff9d0000 {
status = "disabled";
compatible = "xlnx,zynqmp-dwc3";
reg = <0x0 0xff9d0000 0x0 0x100>;
- clock-names = "bus_clk", "ref_clk";
power-domains = <&zynqmp_firmware PD_USB_0>;
resets = <&zynqmp_reset ZYNQMP_RESET_USB0_CORERESET>,
<&zynqmp_reset ZYNQMP_RESET_USB0_HIBERRESET>,
@@ -825,6 +824,7 @@ dwc3_0: usb@fe200000 {
interrupt-parent = <&gic>;
interrupt-names = "dwc_usb3", "otg";
interrupts = <0 65 4>, <0 69 4>;
+ clock-names = "bus_early", "ref";
#stream-id-cells = <1>;
iommus = <&smmu 0x860>;
snps,quirk-frame-length-adjustment = <0x20>;
@@ -838,7 +838,6 @@ usb1: usb@ff9e0000 {
status = "disabled";
compatible = "xlnx,zynqmp-dwc3";
reg = <0x0 0xff9e0000 0x0 0x100>;
- clock-names = "bus_clk", "ref_clk";
power-domains = <&zynqmp_firmware PD_USB_1>;
resets = <&zynqmp_reset ZYNQMP_RESET_USB1_CORERESET>,
<&zynqmp_reset ZYNQMP_RESET_USB1_HIBERRESET>,
@@ -852,6 +851,7 @@ dwc3_1: usb@fe300000 {
interrupt-parent = <&gic>;
interrupt-names = "dwc_usb3", "otg";
interrupts = <0 70 4>, <0 74 4>;
+ clock-names = "bus_early", "ref";
#stream-id-cells = <1>;
iommus = <&smmu 0x861>;
snps,quirk-frame-length-adjustment = <0x20>;
--
2.25.1
^ permalink raw reply related
* [PATCH v3 1/7] dt-bindings: usb: dwc3: Deprecate snps,ref-clock-period-ns
From: Sean Anderson @ 2022-01-27 20:06 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb
Cc: Robert Hancock, Baruch Siach, Felipe Balbi, Thinh Nguyen,
linux-kernel, Balaji Prakash J, Sean Anderson, Rob Herring,
devicetree
In-Reply-To: <20220127200636.1456175-1-sean.anderson@seco.com>
This property is redundant because we can determine the correct value for
REFCLKPER based on the "ref" clock. Deprecate it, and encourage users to
provide a clock instead. This also restricts the minimum and maximum to the
values documented in the register reference [1].
[1] https://www.xilinx.com/html_docs/registers/ug1087/usb3_xhci___guctl.html
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---
(no changes since v1)
Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index d29ffcd27472..4f2b0913ad9f 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -263,8 +263,11 @@ properties:
Value for REFCLKPER field of GUCTL register for reference clock period in
nanoseconds, when the hardware set default does not match the actual
clock.
- minimum: 1
- maximum: 0x3ff
+
+ This binding is deprecated. Instead, provide an appropriate reference clock.
+ minimum: 8
+ maximum: 62
+ deprecated: true
snps,rx-thr-num-pkt-prd:
description:
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox