* [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
clock parents. It is compatible to other HDMI PHYs, like that found in
R40.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index d84df6d808c2..6fb45c7a9ac8 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -101,6 +101,7 @@ DWC HDMI PHY
Required properties:
- compatible: value must be one of:
+ * allwinner,sun50i-a64-hdmi-phy
* allwinner,sun8i-a83t-hdmi-phy
* allwinner,sun8i-h3-hdmi-phy
- reg: base address and size of memory-mapped region
@@ -111,8 +112,9 @@ Required properties:
- resets: phandle to the reset controller driving the PHY
- reset-names: must be "phy"
-H3 HDMI PHY requires additional clock:
+H3 and A64 HDMI PHY require additional clocks:
- pll-0: parent of phy clock
+ - pll-1: second possible phy clock parent (A64 only)
TV Encoder
----------
--
2.17.1
^ permalink raw reply related
* [PATCH v2 19/27] drm/sun4i: Enable DW HDMI PHY clock
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
Current DW HDMI PHY code never prepares and enables PHY clock after it is
created. It's just used as it is. This may work in some cases, but it's
clearly wrong. Fix it by adding proper calls to enable/disable PHY
clock.
Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 5a52fc489a9d..966688f04741 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -477,13 +477,15 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll0;
}
+
+ clk_prepare_enable(phy->clk_phy);
}
phy->rst_phy = of_reset_control_get_shared(node, "phy");
if (IS_ERR(phy->rst_phy)) {
dev_err(dev, "Could not get phy reset control\n");
ret = PTR_ERR(phy->rst_phy);
- goto err_put_clk_pll0;
+ goto err_disable_clk_phy;
}
ret = reset_control_deassert(phy->rst_phy);
@@ -514,6 +516,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_assert(phy->rst_phy);
err_put_rst_phy:
reset_control_put(phy->rst_phy);
+err_disable_clk_phy:
+ clk_disable_unprepare(phy->clk_phy);
err_put_clk_pll0:
if (phy->variant->has_phy_clk)
clk_put(phy->clk_pll0);
@@ -531,6 +535,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
clk_disable_unprepare(phy->clk_mod);
clk_disable_unprepare(phy->clk_bus);
+ clk_disable_unprepare(phy->clk_phy);
reset_control_assert(phy->rst_phy);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
DW HDMI PHY driver and PHY clock driver share same registers. Make sure
that DW HDMI PHY setup code doesn't change any clock related bits and
set them to 0 during initialization.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 79154f0f674a..3ba71aff92fc 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -98,7 +98,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
-#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 966688f04741..cd07ceb71601 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi *hdmi,
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
- regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
+ /*
+ * NOTE: We have to be careful not to overwrite PHY parent
+ * clock selection bit and clock divider.
+ */
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ pll_cfg1_init);
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
(u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
pll_cfg2_init);
@@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct sun8i_hdmi_phy *phy)
SUN8I_HDMI_PHY_ANA_CFG3_SCLEN |
SUN8I_HDMI_PHY_ANA_CFG3_SDAEN);
+ /* reset PLL clock configuration */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0);
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0);
+
/* set HW control of CEC pins */
regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 21/27] drm/sun4i: DW HDMI PHY: Add support for second PLL
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
Some DW HDMI PHYs, like those found in A64 and R40 SoCs, can select
between two clock parents.
Add code which reads second PLL from DT.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 ++
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 20 +++++++++++++++-----
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 3ba71aff92fc..46a3aa6a53a9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -147,6 +147,7 @@ struct sun8i_hdmi_phy;
struct sun8i_hdmi_phy_variant {
bool has_phy_clk;
+ bool has_second_pll;
void (*phy_init)(struct sun8i_hdmi_phy *phy);
void (*phy_disable)(struct dw_hdmi *hdmi,
struct sun8i_hdmi_phy *phy);
@@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
struct clk *clk_mod;
struct clk *clk_phy;
struct clk *clk_pll0;
+ struct clk *clk_pll1;
unsigned int rcal;
struct regmap *regs;
struct reset_control *rst_phy;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index cd07ceb71601..f50072ae054a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -482,10 +482,19 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
goto err_put_clk_mod;
}
+ if (phy->variant->has_second_pll) {
+ phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
+ if (IS_ERR(phy->clk_pll1)) {
+ dev_err(dev, "Could not get pll-1 clock\n");
+ ret = PTR_ERR(phy->clk_pll1);
+ goto err_put_clk_pll0;
+ }
+ }
+
ret = sun8i_phy_clk_create(phy, dev);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
- goto err_put_clk_pll0;
+ goto err_put_clk_pll1;
}
clk_prepare_enable(phy->clk_phy);
@@ -528,9 +537,10 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_put(phy->rst_phy);
err_disable_clk_phy:
clk_disable_unprepare(phy->clk_phy);
+err_put_clk_pll1:
+ clk_put(phy->clk_pll1);
err_put_clk_pll0:
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
err_put_clk_mod:
clk_put(phy->clk_mod);
err_put_clk_bus:
@@ -551,8 +561,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
reset_control_put(phy->rst_phy);
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll1);
clk_put(phy->clk_mod);
clk_put(phy->clk_bus);
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2 22/27] drm/sun4i: Add support for second clock parent to DW HDMI PHY clk driver
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
Expand HDMI PHY clock driver to support second clock parent.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 4 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 ++++++++++++++++------
3 files changed, 73 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 46a3aa6a53a9..aadbe0a10b0c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -99,6 +99,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
@@ -190,6 +191,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent);
#endif /* _SUN8I_DW_HDMI_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index f50072ae054a..e1b7196d4587 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -491,7 +491,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
}
}
- ret = sun8i_phy_clk_create(phy, dev);
+ ret = sun8i_phy_clk_create(phy, dev,
+ phy->variant->has_second_pll);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll1;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
index faea449812f8..a4d31fe3abff 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
@@ -22,35 +22,45 @@ static int sun8i_phy_clk_determine_rate(struct clk_hw *hw,
{
unsigned long rate = req->rate;
unsigned long best_rate = 0;
+ struct clk_hw *best_parent = NULL;
struct clk_hw *parent;
int best_div = 1;
- int i;
+ int i, p;
- parent = clk_hw_get_parent(hw);
-
- for (i = 1; i <= 16; i++) {
- unsigned long ideal = rate * i;
- unsigned long rounded;
-
- rounded = clk_hw_round_rate(parent, ideal);
+ for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
+ parent = clk_hw_get_parent_by_index(hw, p);
+ if (!parent)
+ continue;
- if (rounded == ideal) {
- best_rate = rounded;
- best_div = i;
- break;
+ for (i = 1; i <= 16; i++) {
+ unsigned long ideal = rate * i;
+ unsigned long rounded;
+
+ rounded = clk_hw_round_rate(parent, ideal);
+
+ if (rounded == ideal) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ break;
+ }
+
+ if (!best_rate ||
+ abs(rate - rounded / i) <
+ abs(rate - best_rate / best_div)) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ }
}
- if (!best_rate ||
- abs(rate - rounded / i) <
- abs(rate - best_rate / best_div)) {
- best_rate = rounded;
- best_div = i;
- }
+ if (best_rate / best_div == rate)
+ break;
}
req->rate = best_rate / best_div;
req->best_parent_rate = best_rate;
- req->best_parent_hw = parent;
+ req->best_parent_hw = best_parent;
return 0;
}
@@ -95,22 +105,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw *hw, unsigned long rate,
return 0;
}
+static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+ u32 reg;
+
+ regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
+ reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
+
+ return reg;
+}
+
+static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+
+ if (index > 1)
+ return -EINVAL;
+
+ regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
+
+ return 0;
+}
+
static const struct clk_ops sun8i_phy_clk_ops = {
.determine_rate = sun8i_phy_clk_determine_rate,
.recalc_rate = sun8i_phy_clk_recalc_rate,
.set_rate = sun8i_phy_clk_set_rate,
+
+ .get_parent = sun8i_phy_clk_get_parent,
+ .set_parent = sun8i_phy_clk_set_parent,
};
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent)
{
struct clk_init_data init;
struct sun8i_phy_clk *priv;
- const char *parents[1];
+ const char *parents[2];
parents[0] = __clk_get_name(phy->clk_pll0);
if (!parents[0])
return -ENODEV;
+ if (second_parent) {
+ parents[1] = __clk_get_name(phy->clk_pll1);
+ if (!parents[1])
+ return -ENODEV;
+ }
+
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -118,7 +164,7 @@ int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
init.name = "hdmi-phy-clk";
init.ops = &sun8i_phy_clk_ops;
init.parent_names = parents;
- init.num_parents = 1;
+ init.num_parents = second_parent ? 2 : 1;
init.flags = CLK_SET_RATE_PARENT;
priv->phy = phy;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 23/27] drm/sun4i: Add support for A64 HDMI PHY
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
PHY is the same as in H3, except it can switch between two clock
parents.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index e1b7196d4587..457f0a121684 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -396,6 +396,14 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config = {
.name = "phy"
};
+static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
+ .has_phy_clk = true,
+ .has_second_pll = true,
+ .phy_init = &sun8i_hdmi_phy_init_h3,
+ .phy_disable = &sun8i_hdmi_phy_disable_h3,
+ .phy_config = &sun8i_hdmi_phy_config_h3,
+};
+
static const struct sun8i_hdmi_phy_variant sun8i_a83t_hdmi_phy = {
.phy_init = &sun8i_hdmi_phy_init_a83t,
.phy_disable = &sun8i_hdmi_phy_disable_a83t,
@@ -410,6 +418,10 @@ static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
};
static const struct of_device_id sun8i_hdmi_phy_of_table[] = {
+ {
+ .compatible = "allwinner,sun50i-a64-hdmi-phy",
+ .data = &sun50i_a64_hdmi_phy,
+ },
{
.compatible = "allwinner,sun8i-a83t-hdmi-phy",
.data = &sun8i_a83t_hdmi_phy,
--
2.17.1
^ permalink raw reply related
* [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
Function is useful when drm_of_find_possible_crtcs() can't be used and
custom parsing is needed. This can happen for example when there is a
node with multiple muxes between crtc and encoder.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/drm_of.c | 4 ++--
include/drm/drm_of.h | 8 ++++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 1fe122461298..2e9cea3287b2 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
* Given a port OF node, return the possible mask of the corresponding
* CRTC within a device's list of CRTCs. Returns zero if not found.
*/
-static uint32_t drm_crtc_port_mask(struct drm_device *dev,
- struct device_node *port)
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
{
unsigned int index = 0;
struct drm_crtc *tmp;
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index b93c239afb60..a61fd77e46ba 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -17,6 +17,8 @@ struct drm_bridge;
struct device_node;
#ifdef CONFIG_OF
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port);
uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port);
void drm_of_component_match_add(struct device *master,
@@ -34,6 +36,12 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
struct drm_panel **panel,
struct drm_bridge **bridge);
#else
+static inline uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
+{
+ return 0;
+}
+
static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port)
{
--
2.17.1
^ permalink raw reply related
* [PATCH v2 25/27] drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
drm_of_find_possible_crtcs() doesn't work when DW HDMI encoder is
connected to TCON (crtc) through mux in TCON TOP.
In that case TCON TOP HDMI mux input port has to be manually traversed
and checked if it matches any known crtc.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 46 ++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 9f40a44b456b..d443886e055b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -12,6 +12,7 @@
#include <drm/drm_crtc_helper.h>
#include "sun8i_dw_hdmi.h"
+#include "sun8i_tcon_top.h"
static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
@@ -41,6 +42,48 @@ sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
+static bool sun8i_dw_hdmi_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
+static u32 sun8i_dw_hdmi_find_possible_crtcs(struct drm_device *drm,
+ struct device_node *node)
+{
+ struct device_node *port, *ep, *remote, *remote_port;
+ u32 crtcs = 0;
+
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return 0;
+
+ ep = of_get_next_available_child(port, NULL);
+ if (!ep)
+ return 0;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ return 0;
+
+ if (sun8i_dw_hdmi_node_is_tcon_top(remote)) {
+ port = of_graph_get_port_by_id(remote, 4);
+ if (!port)
+ return 0;
+
+ for_each_child_of_node(port, ep) {
+ remote_port = of_graph_get_remote_port(ep);
+ if (remote_port) {
+ crtcs |= drm_crtc_port_mask(drm, remote_port);
+ of_node_put(remote_port);
+ }
+ }
+ } else {
+ crtcs = drm_of_find_possible_crtcs(drm, node);
+ }
+
+ return crtcs;
+}
+
static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -63,7 +106,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
- encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ encoder->possible_crtcs =
+ sun8i_dw_hdmi_find_possible_crtcs(drm, dev->of_node);
/*
* If we failed to find the CRTC(s) which this encoder is
* supposed to be connected to, it's because the CRTC has
--
2.17.1
^ permalink raw reply related
* [PATCH v2 26/27] ARM: dts: sun8i: r40: Add HDMI pipeline
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
Add all entries needed for HDMI to function properly.
Since R40 has highly configurable pipeline, both mixers and both TCON
TVs are added. Board specific DT should then connect them together
trough TCON TOP muxers to best fit the purpose of the board.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 257 +++++++++++++++++++++++++++++++
1 file changed, 257 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..17171c82457e 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -42,8 +42,11 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/clock/sun8i-r40-ccu.h>
+#include <dt-bindings/clock/sun8i-tcon-top.h>
#include <dt-bindings/reset/sun8i-r40-ccu.h>
+#include <dt-bindings/reset/sun8i-de2.h>
/ {
#address-cells = <1>;
@@ -99,12 +102,76 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-r40-display-engine",
+ "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ display_clocks: clock at 1000000 {
+ compatible = "allwinner,sun8i-r40-de2-clk",
+ "allwinner,sun8i-h3-de2-clk";
+ reg = <0x01000000 0x100000>;
+ clocks = <&ccu CLK_DE>,
+ <&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer at 1100000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-0";
+ reg = <0x01100000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+ <&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port at 1 {
+ reg = <1>;
+ mixer0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ mixer1: mixer at 1200000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-1";
+ reg = <0x01200000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+ <&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port at 1 {
+ reg = <1>;
+ mixer1_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer1_in_mixer1>;
+ };
+ };
+ };
+ };
+
nmi_intc: interrupt-controller at 1c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
@@ -451,6 +518,151 @@
#size-cells = <0>;
};
+ tcon_top: tcon-top at 1c70000 {
+ compatible = "allwinner,sun8i-r40-tcon-top";
+ reg = <0x01c70000 0x1000>;
+ clocks = <&ccu CLK_BUS_TCON_TOP>;
+ clock-names = "bus";
+ resets = <&ccu RST_BUS_TCON_TOP>;
+ reset-names = "rst";
+ #clock-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_top_mixer0_in: port at 0 {
+ reg = <0>;
+
+ tcon_top_mixer0_in_mixer0: endpoint {
+ remote-endpoint = <&mixer0_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon_top_mixer0_out_tcon_lcd0: endpoint at 0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer0_out_tcon_lcd1: endpoint at 1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv0: endpoint at 2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv1: endpoint at 3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_mixer1_in: port at 2 {
+ reg = <2>;
+
+ tcon_top_mixer1_in_mixer1: endpoint {
+ remote-endpoint = <&mixer1_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer1_out: port at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ tcon_top_mixer1_out_tcon_lcd0: endpoint at 0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer1_out_tcon_lcd1: endpoint at 1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv0: endpoint at 2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv1: endpoint at 3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_hdmi_in: port at 4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ tcon_top_hdmi_in_tcon_tv0: endpoint at 0 {
+ reg = <0>;
+ };
+
+ tcon_top_hdmi_in_tcon_tv1: endpoint at 1 {
+ reg = <1>;
+ };
+ };
+
+ tcon_top_hdmi_out: port at 5 {
+ reg = <5>;
+
+ tcon_top_hdmi_out_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in_tcon_top>;
+ };
+ };
+ };
+ };
+
+ tcon_tv0: lcd-controller at 1c73000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c73000 0x1000>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV0>, <&ccu CLK_TCON_TV0>,
+ <&tcon_top 1>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV0>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv0_in: port at 0 {
+ reg = <0>;
+ };
+
+ tcon_tv0_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ tcon_tv1: lcd-controller at 1c74000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c74000 0x1000>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV1>, <&ccu CLK_TCON_TV1>,
+ <&tcon_top 2>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv1_in: port at 0 {
+ reg = <0>;
+ };
+
+ tcon_tv1_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
gic: interrupt-controller at 1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
@@ -461,6 +673,51 @@
#interrupt-cells = <3>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+
+ hdmi: hdmi at 1ee0000 {
+ compatible = "allwinner,sun8i-r40-dw-hdmi",
+ "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee0000 0x10000>;
+ reg-io-width = <1>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HDMI0>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port at 0 {
+ reg = <0>;
+
+ hdmi_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi_phy: hdmi-phy at 1ef0000 {
+ compatible = "allwinner,sun8i-r40-hdmi-phy",
+ "allwinner,sun50i-a64-hdmi-phy";
+ reg = <0x01ef0000 0x10000>;
+ clocks = <&ccu CLK_BUS_HDMI1>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu 7>, <&ccu 16>;
+ clock-names = "bus", "mod", "pll-0", "pll-1";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
};
timer {
--
2.17.1
^ permalink raw reply related
* [PATCH v2 27/27] ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-1-jernej.skrabec@siol.net>
Since HDMI can be considered as main output, most capable mixer is
connected to it (mixer0).
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..0ebc2f9a980e 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -93,6 +104,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -101,6 +116,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c0 {
status = "okay";
@@ -195,6 +220,26 @@
status = "okay";
};
+&tcon_top_hdmi_in_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_out_tcon_top>;
+};
+
+&tcon_top_mixer0_out_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_in_tcon_top>;
+};
+
+&tcon_tv0_in {
+ tcon_tv0_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_out_tcon_tv0>;
+ };
+};
+
+&tcon_tv0_out {
+ tcon_tv0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_in_tcon_tv0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
From: Rob Herring @ 2018-06-12 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527620084-94864-2-git-send-email-vishal.sagar@xilinx.com>
On Wed, May 30, 2018 at 12:24:43AM +0530, Vishal Sagar wrote:
> Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
>
> The Xilinx MIPI CSI-2 Rx Subsystem consists of a DPHY, CSI-2 Rx, an
> optional I2C controller and an optional Video Format Bridge (VFB). The
> active lanes can be configured at run time if enabled in the IP. The
> DPHY register interface may also be enabled.
>
> Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> ---
> .../bindings/media/xilinx/xlnx,csi2rxss.txt | 117 +++++++++++++++++++++
> 1 file changed, 117 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt
>
> diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt
> new file mode 100644
> index 0000000..31ed721
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.txt
> @@ -0,0 +1,117 @@
> +
> +Xilinx MIPI CSI2 Receiver Subsystem Device Tree Bindings
> +--------------------------------------------------------
> +
> +The Xilinx MIPI CSI2 Receiver Subsystem is used to capture MIPI CSI2 traffic
> +from compliant camera sensors and send the output as AXI4 Stream video data
> +for image processing.
> +
> +The subsystem consists of a MIPI DPHY in slave mode which captures the
> +data packets. This is passed along the MIPI CSI2 Rx IP which extracts the
> +packet data. This data is taken in by the Video Format Bridge (VFB),
> +if selected, and converted into AXI4 Stream video data at selected
> +pixels per clock as per AXI4-Stream Video IP and System Design UG934.
> +
> +For more details, please refer to PG232 MIPI CSI-2 Receiver Subsystem.
> +https://www.xilinx.com/support/documentation/ip_documentation/mipi_csi2_rx_subsystem/v3_0/pg232-mipi-csi2-rx.pdf
> +
> +Required properties:
> +
> +- compatible: Must contain "xlnx,mipi-csi2-rx-subsystem-2.0" or
> + "xlnx,mipi-csi2-rx-subsystem-3.0"
> +
> +- reg: Physical base address and length of the registers set for the device.
> +
> +- interrupt-parent: specifies the phandle to the parent interrupt controller
> +
> +- interrupts: Property with a value describing the interrupt number.
> +
> +- xlnx,max-lanes: Maximum active lanes in the design.
There's already a property defined in video-interfaces.txt to limit
lanes.
> +
> +- xlnx,vc: Virtual Channel, specifies virtual channel number to be filtered.
> + If this is 4 then all virtual channels are allowed.
> +
> +- xlnx,csi-pxl-format: This denotes the CSI Data type selected in hw design.
> + Packets other than this data type (except for RAW8 and User defined data
> + types) will be filtered out. Possible values are RAW6, RAW7, RAW8, RAW10,
> + RAW12, RAW14, RGB444, RGB555, RGB565, RGB666, RGB888 and YUV4228bit.
This should be standard property.
> +
> +- xlnx,axis-tdata-width: AXI Stream width, This denotes the AXI Stream width.
> + It depends on Data type chosen, Video Format Bridge enabled/disabled and
> + pixels per clock. If VFB is disabled then its value is either 0x20 (32 bit)
> + or 0x40(64 bit) width.
> +
> +- xlnx,video-format, xlnx,video-width: Video format and width, as defined in
> + video.txt.
This doc needs to define what are valid values.
Why do you need this on both ports? Can there be a conversion in this
block? At least for the MIPI CSI interface part, this should be a common
property. Not sure offhand if we have defined one. We have for parallel
interfaces.
And 'width' doesn't seem like the right term for what this is defined to
be.
> +
> +- port: Video port, using the DT bindings defined in ../video-interfaces.txt.
port is not a property. It goes in its own section. And port properties
should be under it.
> + The CSI 2 Rx Subsystem has a two ports, one input port for connecting to
> + camera sensor and other is output port.
Need be specific port #0 is ?? and port #1 is ??.
> +
> +- data-lanes: The number of data lanes through which CSI2 Rx Subsystem is
> + connected to the camera sensor as per video-interfaces.txt
Why do you need both this and max-lanes?
> +
> +Optional properties:
> +
> +- xlnx,en-active-lanes: Enable Active lanes configuration in Protocol
> + Configuration Register.
> +
> +- xlnx,dphy-present: This is equivalent to whether DPHY register interface is
> + enabled or not.
> +
> +- xlnx,iic-present: This shows whether subsystem's IIC is present or not. This
> + affects the base address of the DPHY.
Perhaps you should break up reg into ranges for each submodule (or make
the DPHY a separate node and use the phy binding.
> +
> +- xlnx,vfb: Video Format Bridge, Denotes if Video Format Bridge is selected
> + so that output is as per AXI stream documented in UG934.
> +
> +- xlnx,ppc: Pixels per clock, Number of pixels to be transferred per pixel
> + clock. This is valid only if xlnx,vfb property is present.
> +
> +Example:
> +
> + csiss_1: csiss at a0020000 {
> + compatible = "xlnx,mipi-csi2-rx-subsystem-3.0";
> + reg = <0x0 0xa0020000 0x0 0x20000>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 95 4>;
> +
> + xlnx,max-lanes = <0x4>;
> + xlnx,en-active-lanes;
> + xlnx,dphy-present;
> + xlnx,iic-present;
> + xlnx,vc = <0x4>;
> + xlnx,csi-pxl-format = "RAW8";
> + xlnx,vfb;
> + xlnx,ppc = <0x4>;
> + xlnx,axis-tdata-width = <0x20>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + xlnx,video-format = <XVIP_VF_YUV_422>;
> + xlnx,video-width = <8>;
> + csiss_out: endpoint {
> + remote-endpoint = <&vcap_csiss_in>;
> + };
> + };
> + port at 1 {
> + reg = <1>;
> +
> + xlnx,video-format = <XVIP_VF_YUV_422>;
> + xlnx,video-width = <8>;
> +
> + csiss_in: endpoint {
> + data-lanes = <1 2 3 4>;
> + /* MIPI CSI2 Camera handle */
> + remote-endpoint = <&vs2016_out>;
> + };
> +
> + };
> +
> + };
> + };
> --
> 2.7.4
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/5] Fix Cygnus, NS2, Stingray interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
This patch series fixes incorrect interrupt types for I2C and PCIe in DT
for Broadcom Cygnus, NS2, and Stingray SoCs
This patch series is based off v4.17 and is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: cygnus-ns2-dt-irq-type-fix-v1
Ray Jui (5):
ARM: dts: cygnus: Fix I2C controller interrupt type
ARM: dts: cygnus: Fix PCIe controller interrupt type
ARM64: dts: ns2: Fix I2C controller interrupt type
ARM64: dts: ns2: Fix PCIe controller interrupt type
ARM64: dts: Stingray: Fix I2C controller interrupt type
arch/arm/boot/dts/bcm-cygnus.dtsi | 24 +++++++++++-----------
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 8 ++++----
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 ++--
3 files changed, 18 insertions(+), 18 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
Cygnus SoC
Fixes: b51c05a331ff ("ARM: dts: add I2C device nodes for Broadcom Cygnus")
Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi bus")
Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 9fe4f5a..835a6f7 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -216,7 +216,7 @@
reg = <0x18008000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
@@ -245,7 +245,7 @@
reg = <0x1800b000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
--
2.1.4
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: cygnus: Fix PCIe controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix PCIe controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
Cygnus SoC
Fixes: cd590b50a936 ("ARM: dts: enable PCIe support for Cygnus")
Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi
bus")
Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
Fixes: f6b889358a82 ("ARM: dts: Enable MSI support for Broadcom Cygnus")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 835a6f7..2c4df2d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -256,7 +256,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <0>;
@@ -278,10 +278,10 @@
compatible = "brcm,iproc-msi";
msi-controller;
interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>,
- <GIC_SPI 97 IRQ_TYPE_NONE>,
- <GIC_SPI 98 IRQ_TYPE_NONE>,
- <GIC_SPI 99 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
};
};
@@ -291,7 +291,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <1>;
@@ -313,10 +313,10 @@
compatible = "brcm,iproc-msi";
msi-controller;
interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 102 IRQ_TYPE_NONE>,
- <GIC_SPI 103 IRQ_TYPE_NONE>,
- <GIC_SPI 104 IRQ_TYPE_NONE>,
- <GIC_SPI 105 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
};
};
--
2.1.4
^ permalink raw reply related
* [PATCH 3/5] ARM64: dts: ns2: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for
Broadcom NS2 SoC
Fixes: 7ac674e8df7a ("arm64: dts: Add I2C nodes for NS2")
Fixes: 63a913c157f5 ("arm64: dts: move ns2 into northstar2 directory")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 4a2a6af..c0e4896 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -566,7 +566,7 @@
reg = <0x66080000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 394 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 394 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
@@ -594,7 +594,7 @@
reg = <0x660b0000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 395 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
--
2.1.4
^ permalink raw reply related
* [PATCH 4/5] ARM64: dts: ns2: Fix PCIe controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix PCIe controller interrupt to use IRQ_TYPE_LEVEL_HIGH for
Broadcom NS2 SoC
Fixes: fd5e5dd56a2f ("arm64: dts: Add PCIe0 and PCIe4 DT nodes for NS2")
Fixes: 63a913c157f5 ("arm64: dts: move ns2 into northstar2 directory")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index c0e4896..4057197 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -118,7 +118,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 281 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 281 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <0>;
@@ -149,7 +149,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 305 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <4>;
--
2.1.4
^ permalink raw reply related
* [PATCH 5/5] ARM64: dts: Stingray: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for
Broadcom Stingray SoC
Fixes: 1256ea18875d ("arm64: dts: Add I2C DT nodes for Stingray SoC")
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..b203152 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -409,7 +409,7 @@
reg = <0x000b0000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 177 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
@@ -453,7 +453,7 @@
reg = <0x000e0000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 178 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
status = "disabled";
};
--
2.1.4
^ permalink raw reply related
* [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 (RFC)
NOTE:
* As per ARM recommendations[2], and discussions in list[1] ARM
Cortex-A9/12/17 do not need additional steps in u-boot to enable the
OS level workarounds.
* This itself is'nt a complete solution and is based on recommendation
This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on
linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag).
* I think it is necessary on older SoCs without firmware support
(such as older OMAPs and AM*) to have kernel support mirroring what we do in
u-boot to support additional cores AND/OR low power states where contexts are
lost (assuming ACR states are'nt saved). just my 2 cents.
Few of the tests (with linux next-20180612):
AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15)
OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15)
OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8)
AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8)
Nishanth Menon (4):
ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
CVE-2017-5715
ARM: Introduce ability to enable invalidate of BTB with ICIALLU on
Cortex-A15 for CVE-2017-5715
ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of
BTB) to facilitate CVE_2017-5715 WA in OS
ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for
CVE-2017-5715
arch/arm/Kconfig | 9 +++++++++
arch/arm/cpu/armv7/start.S | 15 +++++++++++++--
arch/arm/mach-omap2/Kconfig | 3 +++
3 files changed, 25 insertions(+), 2 deletions(-)
[1] https://marc.info/?t=151639906500002&r=1&w=2
[2] https://developer.arm.com/support/security-update
[3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in:
https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2
[4]
https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
https://www.op-tee.org/security-advisories/
https://www.linaro.org/blog/meltdown-spectre/
--
2.15.1
^ permalink raw reply
* [PATCH 1/4] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/Kconfig | 5 +++++
arch/arm/cpu/armv7/start.S | 7 +++++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dde422bc5d53..9e32d5b43cb0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -108,6 +108,8 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_621766
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
+# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+
config ARM_ERRATA_430973
bool
@@ -177,6 +179,9 @@ config ARM_ERRATA_852423
config ARM_ERRATA_855873
bool
+config ARM_CORTEX_A8_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index c996525f861e..3beaf5a93d81 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -252,12 +252,15 @@ skip_errata_801819:
pop {r1-r5} @ Restore the cpu info - fall through
#endif
-#ifdef CONFIG_ARM_ERRATA_430973
+#if defined(CONFIG_ARM_ERRATA_430973) || defined (CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
+#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+ orr r0, r0, #(0x1 << 6) @ Set IBE bit always to enable OS WA
+#else
cmp r2, #0x21 @ Only on < r2p1
orrlt r0, r0, #(0x1 << 6) @ Set IBE bit
-
+#endif
push {r1-r5} @ Save the cpu info registers
bl v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
--
2.15.1
^ permalink raw reply related
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
be done unconditionally for Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
right locations.
c) This workaround applies to only the boot processor. It is important
to apply workaround as necessary (context-save-restore) around low
power context loss OR additional processors as necessary in either
firmware support OR elsewhere in OS.
[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/Kconfig | 4 ++++
arch/arm/cpu/armv7/start.S | 8 ++++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9e32d5b43cb0..98f58fd27696 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -109,6 +109,7 @@ config SYS_ARM_MPU
# CONFIG_ARM_ERRATA_798870
# CONFIG_ARM_ERRATA_801819
# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
config ARM_ERRATA_430973
bool
@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
config ARM_CORTEX_A8_CVE_2017_5715
bool
+config ARM_CORTEX_A15_CVE_2017_5715
+ bool
+
config CPU_ARM720T
bool
select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 3beaf5a93d81..81edec01bf32 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -241,6 +241,14 @@ skip_errata_798870:
skip_errata_801819:
#endif
+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
+ push {r1-r5} @ Save the cpu info registers
+ bl v7_arch_cp15_set_acr
+ pop {r1-r5} @ Restore the cpu info - fall through
+#endif
+
#ifdef CONFIG_ARM_ERRATA_454179
mrc p15, 0, r0, c1, c0, 1 @ Read ACR
--
2.15.1
^ permalink raw reply related
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
function to setup the bits, we are able to override the settings.
Without this enabled, Linux kernel reports:
CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
With this enabled, Linux kernel reports:
CPU0: Spectre v2: using ICIALLU workaround
NOTE: This by itself does not enable the workaround for CPU1 (on
OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 3bb1ecb58de0..77820cc8d1e4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -53,6 +53,7 @@ config OMAP54XX
bool "OMAP54XX SoC"
select ARM_ERRATA_798870
select SYS_THUMB_BUILD
+ select ARM_CORTEX_A15_CVE_2017_5715
imply NAND_OMAP_ELM
imply NAND_OMAP_GPMC
imply SPL_DISPLAY_PRINT
--
2.15.1
^ permalink raw reply related
* [PATCH 4/4] ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for CVE-2017-5715
From: Nishanth Menon @ 2018-06-12 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
Enable CVE-2017-5715 option to set the IBE bit. This enables kernel
workarounds necessary for the said CVE.
With this enabled, Linux reports:
CPU0: Spectre v2: using BPIALL workaround
This workaround may need to be re-applied in OS environment around low
power transition resume states where context of ACR would be lost (off-mode
etc).
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 77820cc8d1e4..f4babc8d2600 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -10,6 +10,7 @@ config OMAP34XX
select ARM_ERRATA_454179
select ARM_ERRATA_621766
select ARM_ERRATA_725233
+ select ARM_CORTEX_A8_CVE_2017_5715
select USE_TINY_PRINTF
imply NAND_OMAP_GPMC
imply SPL_EXT_SUPPORT
@@ -116,6 +117,7 @@ config AM43XX
config AM33XX
bool "AM33XX SoC"
select SPECIFY_CONSOLE_INDEX
+ select ARM_CORTEX_A8_CVE_2017_5715
imply NAND_OMAP_ELM
imply NAND_OMAP_GPMC
imply SPL_NAND_AM33XX_BCH
--
2.15.1
^ permalink raw reply related
* [RFC V2 3/3] perf: qcom: Add Falkor CPU PMU IMPLEMENTATION DEFINED event support
From: Agustin Vega-Frias @ 2018-06-12 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612144055.m2h26n64spfm6k6o@lakrids.cambridge.arm.com>
Hi Mark,
On 2018-06-12 10:40, Mark Rutland wrote:
> Hi,
>
> On Thu, Jun 07, 2018 at 09:56:48AM -0400, Agustin Vega-Frias wrote:
>> Selection of these events can be envisioned as indexing them from
>> a 3D matrix:
>> - the first index selects a Region Event Selection Register
>> (PMRESRx_EL0)
>> - the second index selects a group from which only one event at a time
>> can be selected
>> - the third index selects the event
>>
>> The event is encoded into perf_event_attr.config as 0xPRCCG, where:
>> P [config:16 ] = prefix (flag that indicates a matrix-based
>> event)
>> R [config:12-15] = register (specifies the PMRESRx_EL0 instance)
>> G [config:0-3 ] = group (specifies the event group)
>> CC [config:4-11 ] = code (specifies the event)
>>
>> Events with the P flag set to zero are treated as common PMUv3 events
>> and are directly programmed into PMXEVTYPERx_EL0.
>>
>> The first two indexes are set combining the RESR and group number with
>> a base number and writing it into the architected PMXEVTYPER_EL0
>> register.
>> The third index is set by writing the code into the bits corresponding
>> with the group into the appropriate IMPLEMENTATION DEFINED PMRESRx_EL0
>> register.
>
> When are the IMP DEF registers accessible at EL0? Are those goverend by
> the same controls as the architected registers?
No, there is a separate IMP DEF register to control access.
>
> [...]
>
>> +/*
>> + * Qualcomm Technologies CPU PMU IMPLEMENTATION DEFINED extensions
>> support
>> + *
>> + * Current extensions supported:
>> + *
>> + * - Matrix-based microarchitectural events support
>> + *
>> + * Selection of these events can be envisioned as indexing them
>> from
>> + * a 3D matrix:
>> + * - the first index selects a Region Event Selection Register
>> (PMRESRx_EL0)
>> + * - the second index selects a group from which only one event at
>> a time
>> + * can be selected
>> + * - the third index selects the event
>> + *
>> + * The event is encoded into perf_event_attr.config as 0xPRCCG,
>> where:
>> + * P [config:16 ] = prefix (flag that indicates a
>> matrix-based event)
>> + * R [config:12-15] = register (specifies the PMRESRx_EL0
>> instance)
>> + * G [config:0-3 ] = group (specifies the event group)
>> + * CC [config:4-11 ] = code (specifies the event)
>> + *
>> + * Events with the P flag set to zero are treated as common PMUv3
>> events
>> + * and are directly programmed into PMXEVTYPERx_EL0.
>
> When PMUv3 is given a raw event code, the config fields should be the
> PMU event number, and this conflicts with RESERVED encodings.
>
> I'd rather we used a separate field for the QC extension events. e.g.
> turn config1 into a flags field, and move the P flag there.
>
> We *should* add code to sanity check those fields are zero in the PMUv3
> driver, even though it's a potential ABI break to start now.
I should have stated clearly that in this case the event code is
directly
programmed into PMXEVTYPERx_EL0.evtCount, not by this code, but by the
PMUv3
code, which will do the masking and ensure reserved bits are not
touched.
IOW, that case is no different from the raw event or a common event
case.
I would prefer to keep the flag in config because it allows the use of
raw code encodings to access these events more easily, and given that
the flag is never propagated to any register I believe it is safe.
>
>> + *
>> + * The first two indexes are set combining the RESR and group
>> number with
>> + * a base number and writing it into the architected PMXEVTYPER_EL0
>> register.
>> + * The third index is set by writing the code into the bits
>> corresponding
>> + * with the group into the appropriate IMPLEMENTATION DEFINED
>> PMRESRx_EL0
>> + * register.
>> + */
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/perf/arm_pmu.h>
>
> You'll also need:
>
> #include <linux/bitops.h>
> #include <linux/device.h>
> #include <linux/perf_event.h>
> #include <linux/printk.h>
> #include <linux/types.h>
>
> #include <asm/barrier.h>
> #include <asm/sysreg.h>
>
Will do.
>> +
>> +#define pmresr0_el0 sys_reg(3, 5, 11, 3, 0)
>> +#define pmresr1_el0 sys_reg(3, 5, 11, 3, 2)
>> +#define pmresr2_el0 sys_reg(3, 5, 11, 3, 4)
>> +#define pmxevcntcr_el0 sys_reg(3, 5, 11, 0, 3)
>> +
>> +#define QC_EVT_PFX_SHIFT 16
>> +#define QC_EVT_REG_SHIFT 12
>> +#define QC_EVT_CODE_SHIFT 4
>> +#define QC_EVT_GRP_SHIFT 0
>> +#define QC_EVT_PFX_MASK GENMASK(QC_EVT_PFX_SHIFT,
>> QC_EVT_PFX_SHIFT)
>> +#define QC_EVT_REG_MASK GENMASK(QC_EVT_REG_SHIFT + 3,
>> QC_EVT_REG_SHIFT)
>> +#define QC_EVT_CODE_MASK GENMASK(QC_EVT_CODE_SHIFT + 7,
>> QC_EVT_CODE_SHIFT)
>> +#define QC_EVT_GRP_MASK GENMASK(QC_EVT_GRP_SHIFT + 3,
>> QC_EVT_GRP_SHIFT)
>> +#define QC_EVT_PRG_MASK (QC_EVT_PFX_MASK | QC_EVT_REG_MASK |
>> QC_EVT_GRP_MASK)
>> +#define QC_EVT_PRG(event) ((event) & QC_EVT_PRG_MASK)
>> +#define QC_EVT_REG(event) (((event) & QC_EVT_REG_MASK) >>
>> QC_EVT_REG_SHIFT)
>> +#define QC_EVT_CODE(event) (((event) & QC_EVT_CODE_MASK) >>
>> QC_EVT_CODE_SHIFT)
>> +#define QC_EVT_GROUP(event) (((event) & QC_EVT_GRP_MASK) >>
>> QC_EVT_GRP_SHIFT)
>> +
>> +#define QC_MAX_GROUP 7
>> +#define QC_MAX_RESR 2
>> +#define QC_BITS_PER_GROUP 8
>> +#define QC_RESR_ENABLE BIT_ULL(63)
>> +#define QC_RESR_EVT_BASE 0xd8
>> +
>> +static struct arm_pmu *def_ops;
>> +
>> +static inline void falkor_write_pmresr(u64 reg, u64 val)
>> +{
>> + if (reg == 0)
>> + write_sysreg_s(val, pmresr0_el0);
>> + else if (reg == 1)
>> + write_sysreg_s(val, pmresr1_el0);
>> + else
>> + write_sysreg_s(val, pmresr2_el0);
>> +}
>> +
>> +static inline u64 falkor_read_pmresr(u64 reg)
>> +{
>> + return (reg == 0 ? read_sysreg_s(pmresr0_el0) :
>> + reg == 1 ? read_sysreg_s(pmresr1_el0) :
>> + read_sysreg_s(pmresr2_el0));
>> +}
>
> Please use switch statements for both of these.
Will do.
>
>> +
>> +static void falkor_set_resr(u64 reg, u64 group, u64 code)
>> +{
>> + u64 shift = group * QC_BITS_PER_GROUP;
>> + u64 mask = GENMASK(shift + QC_BITS_PER_GROUP - 1, shift);
>> + u64 val;
>> +
>> + val = falkor_read_pmresr(reg) & ~mask;
>> + val |= (code << shift);
>> + val |= QC_RESR_ENABLE;
>> + falkor_write_pmresr(reg, val);
>> +}
>> +
>> +static void falkor_clear_resr(u64 reg, u64 group)
>> +{
>> + u32 shift = group * QC_BITS_PER_GROUP;
>> + u64 mask = GENMASK(shift + QC_BITS_PER_GROUP - 1, shift);
>> + u64 val = falkor_read_pmresr(reg) & ~mask;
>> +
>> + falkor_write_pmresr(reg, val == QC_RESR_ENABLE ? 0 : val);
>> +}
>> +
>> +/*
>> + * Check if e1 and e2 conflict with each other
>> + *
>> + * e1 is a matrix-based microarchitectural event we are checking
>> against e2.
>> + * A conflict exists if the events use the same reg, group, and a
>> different
>> + * code. Events with the same code are allowed because they could be
>> using
>> + * different filters (e.g. one to count user space and the other to
>> count
>> + * kernel space events).
>> + */
>
> What problem occurs when there's a conflict?
No real problem at the hardware level since only one event can be
selected
at a time from a group, but if this is not detected and dealt with the
user
will receive incorrect information.
Selection is done through the PMRESRx_EL0 registers, these are 64bit
registers
with an enable bit (63) one 7-bit field for group 7 (62-56) event
selection, and
seven 8-bit fields for group 6 to group 0 event selection. So it is
physically
impossible to select two events.
>
> Does the filter matter at all? When happens if I open two identical
> events, both counting the same reg, group, and code, with the same
> filter?
That is possible and allowed, similar to counting the same common event
in two configurable counters. Only problem is wasting a counter
resource.
>
>> +static inline int events_conflict(struct perf_event *e1, struct
>> perf_event *e2)
>> +{
>> + if ((e1 != e2) &&
>> + (e1->pmu == e2->pmu) &&
>> + (QC_EVT_PRG(e1->attr.config) == QC_EVT_PRG(e2->attr.config)) &&
>> + (QC_EVT_CODE(e1->attr.config) != QC_EVT_CODE(e2->attr.config)))
>> {
>> + pr_debug_ratelimited(
>> + "Group exclusion: conflicting events %llx %llx\n",
>> + e1->attr.config,
>> + e2->attr.config);
>> + return 1;
>> + }
>> + return 0;
>> +}
>
> This would be easier to read as a series of tests:
>
> static inline bool events_conflict(struct perf_event *new,
> struct perf_event *other)
> {
> /* own group leader */
> if (new == other)
> return false;
>
> /* software events can't conflict */
> if (is_sw_event(other))
> return false;
>
> /* No conflict if using different reg or group */
> if (QC_EVT_PRG(new->attr.config) != QC_EVT_PRG(other->attr.config))
> return false;
>
> /* Same reg and group is fine so long as code matches */
> if (QC_EVT_CODE(new->attr.config) == QC_EVT_PRG(other->attr.config)
> return false;
>
>
> pr_debug_ratelimited("Group exclusion: conflicting events %llx
> %llx\n",
> new->attr.config, other->attr.config);
>
> return true;
>
> }
Will rework.
>
>> +
>> +/*
>> + * Check if the given event is valid for the PMU and if so return the
>> value
>> + * that can be used in PMXEVTYPER_EL0 to select the event
>> + */
>> +static int falkor_map_event(struct perf_event *event)
>> +{
>> + u64 reg = QC_EVT_REG(event->attr.config);
>> + u64 group = QC_EVT_GROUP(event->attr.config);
>> + struct perf_event *leader;
>> + struct perf_event *sibling;
>> +
>> + if (!(event->attr.config & QC_EVT_PFX_MASK))
>> + /* Common PMUv3 event, forward to the original op */
>> + return def_ops->map_event(event);
>
> The QC event codes should only be used when either:
>
> * event->attr.type is PERF_TYPE_RAW, or:
>
> * event->pmu.type is this PMU's dynamic type
>
> ... otherwise this will accept events meant for other PMUs, and/or
> override conflicting events in other type namespaces (e.g.
> PERF_EVENT_TYPE_HW, PERF_EVENT_TYPE_CACHE).
>
Will add a check.
>> +
>> + /* Is it a valid matrix event? */
>> + if ((group > QC_MAX_GROUP) || (reg > QC_MAX_RESR))
>> + return -ENOENT;
>> +
>> + /* If part of an event group, check if the event can be put in it */
>> +
>> + leader = event->group_leader;
>> + if (events_conflict(event, leader))
>> + return -ENOENT;
>> +
>> + for_each_sibling_event(sibling, leader)
>> + if (events_conflict(event, sibling))
>> + return -ENOENT;
>> +
>> + return QC_RESR_EVT_BASE + reg*8 + group;
>
> Nit: spacing around binary operators please.
>
>> +}
>> +
>> +/*
>> + * Find a slot for the event on the current CPU
>> + */
>> +static int falkor_get_event_idx(struct pmu_hw_events *cpuc, struct
>> perf_event *event)
>> +{
>> + int idx;
>> +
>> + if (!!(event->attr.config & QC_EVT_PFX_MASK))
>
> The '!!' isn't required.
>
>> + /* Matrix event, check for conflicts with existing events */
>> + for_each_set_bit(idx, cpuc->used_mask, ARMPMU_MAX_HWEVENTS)
>> + if (cpuc->events[idx] &&
>> + events_conflict(event, cpuc->events[idx]))
>> + return -ENOENT;
>> +
>> + /* Let the original op handle the rest */
>> + idx = def_ops->get_event_idx(cpuc, event);
>
> Same comments as for falkor_map_event().
>
>> +
>> + /*
>> + * This is called for actually allocating the events, but also with
>> + * a dummy pmu_hw_events when validating groups, for that case we
>> + * need to ensure that cpuc->events[idx] is NULL so we don't use
>> + * an uninitialized pointer. Conflicts for matrix events in groups
>> + * are checked during event mapping anyway (see falkor_event_map).
>> + */
>> + cpuc->events[idx] = NULL;
>> +
>> + return idx;
>> +}
>> +
>> +/*
>> + * Reset the PMU
>> + */
>> +static void falkor_reset(void *info)
>> +{
>> + struct arm_pmu *pmu = (struct arm_pmu *)info;
>> + u32 i, ctrs = pmu->num_events;
>> +
>> + /* PMRESRx_EL0 regs are unknown at reset, except for the EN field */
>> + for (i = 0; i <= QC_MAX_RESR; i++)
>> + falkor_write_pmresr(i, 0);
>> +
>> + /* PMXEVCNTCRx_EL0 regs are unknown at reset */
>> + for (i = 0; i <= ctrs; i++) {
>> + write_sysreg(i, pmselr_el0);
>> + isb();
>> + write_sysreg_s(0, pmxevcntcr_el0);
>> + }
>> +
>> + /* Let the original op handle the rest */
>> + def_ops->reset(info);
>> +}
>> +
>> +/*
>> + * Enable the given event
>> + */
>> +static void falkor_enable(struct perf_event *event)
>> +{
>> + if (!!(event->attr.config & QC_EVT_PFX_MASK)) {
>
> The '!!' isn't required.
>
>> + /* Matrix event, program the appropriate PMRESRx_EL0 */
>> + struct arm_pmu *pmu = to_arm_pmu(event->pmu);
>> + struct pmu_hw_events *events = this_cpu_ptr(pmu->hw_events);
>> + u64 reg = QC_EVT_REG(event->attr.config);
>> + u64 code = QC_EVT_CODE(event->attr.config);
>> + u64 group = QC_EVT_GROUP(event->attr.config);
>> + unsigned long flags;
>> +
>> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
>> + falkor_set_resr(reg, group, code);
>> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>
> Why is the spinlock required?
>
> AFACIT this should only ever be called in contexts where IRQs are
> disabled already.
>
falkor_set_resr is a read-modify-write operation. The PMUv3 code uses
the spinlock to protect the counter selection too
(armv8pmu_enable_event).
I believe this is to deal with event rotation which can potentially
be active when we are creating new events.
>> + }
>> +
>> + /* Let the original op handle the rest */
>> + def_ops->enable(event);
>> +}
>> +
>> +/*
>> + * Disable the given event
>> + */
>> +static void falkor_disable(struct perf_event *event)
>> +{
>> + /* Use the original op to disable the counter and interrupt */
>> + def_ops->enable(event);
>> +
>> + if (!!(event->attr.config & QC_EVT_PFX_MASK)) {
>> + /* Matrix event, de-program the appropriate PMRESRx_EL0 */
>> + struct arm_pmu *pmu = to_arm_pmu(event->pmu);
>> + struct pmu_hw_events *events = this_cpu_ptr(pmu->hw_events);
>> + u64 reg = QC_EVT_REG(event->attr.config);
>> + u64 group = QC_EVT_GROUP(event->attr.config);
>> + unsigned long flags;
>> +
>> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
>> + falkor_clear_resr(reg, group);
>> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>> + }
>> +}
>
> Same comments as with falkor_enable().
>
>> +
>> +PMU_FORMAT_ATTR(event, "config:0-15");
>> +PMU_FORMAT_ATTR(prefix, "config:16");
>> +PMU_FORMAT_ATTR(reg, "config:12-15");
>> +PMU_FORMAT_ATTR(code, "config:4-11");
>> +PMU_FORMAT_ATTR(group, "config:0-3");
>
> What sort of events are available? Do you plan to add anything to the
> userspace event database in tools/perf/pmu-events/ ?
>
Yes, we are still doing some internal work to see what we can put in
the driver or as JSON events.
>> +
>> +static struct attribute *falkor_pmu_formats[] = {
>> + &format_attr_event.attr,
>> + &format_attr_prefix.attr,
>> + &format_attr_reg.attr,
>> + &format_attr_code.attr,
>> + &format_attr_group.attr,
>> + NULL,
>> +};
>> +
>> +static struct attribute_group falkor_pmu_format_attr_group = {
>> + .name = "format",
>> + .attrs = falkor_pmu_formats,
>> +};
>> +
>> +static int qcom_falkor_pmu_init(struct arm_pmu *pmu, struct device
>> *dev)
>> +{
>> + /* Save base arm_pmu so we can invoke its ops when appropriate */
>> + def_ops = devm_kmemdup(dev, pmu, sizeof(*def_ops), GFP_KERNEL);
>> + if (!def_ops) {
>> + pr_warn("Failed to allocate arm_pmu for QCOM extensions");
>> + return -ENODEV;
>> + }
>> +
>> + pmu->name = "qcom_pmuv3";
>
> All the other CPU PMUs on an ARM ACPI system will have an index suffix,
> e.g. "armv8_pmuv3_0". I can see why we might want to change the name to
> indicate the QC extensions, but I think we should keep the existing
> pattern, with a '_0' suffix here.
This overrides the name before the suffix is added, so the PMU name will
be
qcom_pmuv3_0 for Centriq 2400 which has only Falkor CPUs.
>
>> +
>> + /* Override the necessary ops */
>> + pmu->map_event = falkor_map_event;
>> + pmu->get_event_idx = falkor_get_event_idx;
>> + pmu->reset = falkor_reset;
>> + pmu->enable = falkor_enable;
>> + pmu->disable = falkor_disable;
>
> I'm somewhat concerned by hooking into the existing PMU code at this
> level, but I don't currently have a better suggestion.
>
IMO this is no different from other PMUs implemented on top of the
arm_pmu
framework. The difference is of course that I'm calling back into the
base
PMUv3 ops, but the alternative would be to duplicate, which is what we
want
to avoid.
Thanks for the detailed feedback, I'll try to submit V3 before week's
end.
Let me know if you have any concerns about my replies above.
Thanks,
Agust?n
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Rob Herring @ 2018-06-12 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527858967-16047-7-git-send-email-suzuki.poulose@arm.com>
On Fri, Jun 01, 2018 at 02:16:05PM +0100, Suzuki K Poulose wrote:
> The coresight drivers relied on default bindings for graph
> in DT, while reusing the "reg" field of the "ports" to indicate
> the actual hardware port number for the connections. However,
> with the rules getting stricter w.r.t to the address mismatch
> with the label, it is no longer possible to use the port address
> field for the hardware port number. Hence, we add an explicit
> property to denote the hardware port number, "coresight,hwid"
> which must be specified for each "endpoint".
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> .../devicetree/bindings/arm/coresight.txt | 26 +++++++++---
> drivers/hwtracing/coresight/of_coresight.c | 46 ++++++++++++++++------
> 2 files changed, 54 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index bd36e40..385581a 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -104,7 +104,11 @@ properties to uniquely identify the connection details.
> "slave-mode"
>
> * Hardware Port number at the component:
> - - The hardware port number is assumed to be the address of the "port" component.
> + - (Obsolete) The hardware port number is assumed to be the address of the "port" component.
> + - Each "endpoint" must define the hardware port of the local end of the
> + connection using the following property:
> + "coresight,hwid" - 32bit integer, hardware port number at the local end.
"coresight" is not a vendor and properties are in the form
[<vendor>,]<prop-name>.
> +
>
>
> Example:
> @@ -120,6 +124,7 @@ Example:
> etb_in_port: endpoint at 0 {
There shouldn't be a unit address here because there is no reg property.
> slave-mode;
> remote-endpoint = <&replicator_out_port0>;
> + coresight,hwid = <0>;
It doesn't make sense for these to be in the endpoint. If you had
multiple endpoints, then you would have to duplicate it. "ports" are
a single data stream. "endpoints" are connections to that stream. So if
you have a muxed (input) or fanout/1-to-many (output) connection, then
you have multiple endpoints.
The same applied to the slave-mode property, but that ship has sailed.
No reason to continue that though.
> };
> };
> };
> @@ -134,6 +139,7 @@ Example:
> tpiu_in_port: endpoint at 0 {
> slave-mode;
> remote-endpoint = <&replicator_out_port1>;
> + coresight,hwid = <0>;
> };
> };
> };
> @@ -154,6 +160,7 @@ Example:
> reg = <0>;
> replicator_out_port0: endpoint {
> remote-endpoint = <&etb_in_port>;
> + coresight,hwid = <0>;
> };
> };
>
> @@ -161,15 +168,17 @@ Example:
> reg = <1>;
> replicator_out_port1: endpoint {
> remote-endpoint = <&tpiu_in_port>;
> + coresight,hwid = <1>;
> };
> };
>
> /* replicator input port */
> port at 2 {
> - reg = <0>;
> + reg = <1>;
This will still get flagged as an error. reg must be 2 here.
Rob
^ permalink raw reply
* [PATCH 1/3] dt-bindings: pinctrl: Add gpio interrupt bindings for Actions S900 SoC
From: Rob Herring @ 2018-06-12 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602165415.30956-2-manivannan.sadhasivam@linaro.org>
On Sat, Jun 02, 2018 at 10:24:13PM +0530, Manivannan Sadhasivam wrote:
> Add gpio interrupt bindings for Actions Semi S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/pinctrl/actions,s900-pinctrl.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
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