* [PATCH RESEND net-next v2 4/8] dt-bindings: net: dwmac-sun8i: Add binding for GMAC on Allwinner R40 SoC
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.
This patch adds the R40 specific bits to the dwmac-sun8i binding.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 1c0906a5c02b..cfe724398a12 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -7,6 +7,7 @@ Required properties:
- compatible: must be one of the following string:
"allwinner,sun8i-a83t-emac"
"allwinner,sun8i-h3-emac"
+ "allwinner,sun8i-r40-gmac"
"allwinner,sun8i-v3s-emac"
"allwinner,sun50i-a64-emac"
- reg: address and length of the register for the device.
@@ -25,8 +26,10 @@ Required properties:
Optional properties:
- allwinner,tx-delay-ps: TX clock delay chain value in ps.
Range is 0-700. Default is 0.
+ Unavailable for allwinner,sun8i-r40-gmac
- allwinner,rx-delay-ps: RX clock delay chain value in ps.
Range is 0-3100. Default is 0.
+ Range is 0-700 for allwinner,sun8i-r40-gmac
Both delay properties need to be a multiple of 100. They control the
clock delay for external RGMII PHY. They do not apply to the internal
PHY or external non-RGMII PHYs.
--
2.17.0
^ permalink raw reply related
* [PATCH RESEND net-next v2 5/8] net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
On the Allwinner R40, the "GMAC clock" register is located in the CCU
block, at a different register address than the other SoCs that have
it in the "system control" block.
This patch converts the use of regmap to regmap_field for mapping and
accessing the syscon register, so we can have the register address in
the variants data, and not in the actual register manipulation code.
This patch only converts regmap_read() and regmap_write() calls to
regmap_field_read() and regmap_field_write() calls. There are some
places where it might make sense to switch to regmap_field_update_bits(),
but this is not done here to keep the patch simple.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 42 ++++++++++++++-----
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a3fa65b1ca8e..bbc051474806 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -42,6 +42,7 @@
* This value is used for disabling properly EMAC
* and used as a good starting value in case of the
* boot process(uboot) leave some stuff.
+ * @syscon_field reg_field for the syscon's gmac register
* @soc_has_internal_phy: Does the MAC embed an internal PHY
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
@@ -49,6 +50,7 @@
*/
struct emac_variant {
u32 default_syscon_value;
+ const struct reg_field *syscon_field;
bool soc_has_internal_phy;
bool support_mii;
bool support_rmii;
@@ -71,13 +73,21 @@ struct sunxi_priv_data {
struct regulator *regulator;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
- struct regmap *regmap;
+ struct regmap_field *regmap_field;
bool internal_phy_powered;
void *mux_handle;
};
+/* EMAC clock register @ 0x30 in the "system control" address range */
+static const struct reg_field sun8i_syscon_reg_field = {
+ .reg = 0x30,
+ .lsb = 0,
+ .msb = 31,
+};
+
static const struct emac_variant emac_variant_h3 = {
.default_syscon_value = 0x58000,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = true,
.support_mii = true,
.support_rmii = true,
@@ -86,12 +96,14 @@ static const struct emac_variant emac_variant_h3 = {
static const struct emac_variant emac_variant_v3s = {
.default_syscon_value = 0x38000,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = true,
.support_mii = true
};
static const struct emac_variant emac_variant_a83t = {
.default_syscon_value = 0,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
.support_rgmii = true
@@ -99,6 +111,7 @@ static const struct emac_variant emac_variant_a83t = {
static const struct emac_variant emac_variant_a64 = {
.default_syscon_value = 0,
+ .syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
.support_rmii = true,
@@ -216,7 +229,6 @@ static const struct emac_variant emac_variant_a64 = {
#define SYSCON_ETCS_MII 0x0
#define SYSCON_ETCS_EXT_GMII 0x1
#define SYSCON_ETCS_INT_GMII 0x2
-#define SYSCON_EMAC_REG 0x30
/* sun8i_dwmac_dma_reset() - reset the EMAC
* Called from stmmac via stmmac_dma_ops->reset
@@ -745,7 +757,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
bool need_power_ephy = false;
if (current_child ^ desired_child) {
- regmap_read(gmac->regmap, SYSCON_EMAC_REG, ®);
+ regmap_field_read(gmac->regmap_field, ®);
switch (desired_child) {
case DWMAC_SUN8I_MDIO_MUX_INTERNAL_ID:
dev_info(priv->device, "Switch mux to internal PHY");
@@ -763,7 +775,7 @@ static int mdio_mux_syscon_switch_fn(int current_child, int desired_child,
desired_child);
return -EINVAL;
}
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, val);
+ regmap_field_write(gmac->regmap_field, val);
if (need_power_ephy) {
ret = sun8i_dwmac_power_internal_phy(priv);
if (ret)
@@ -801,7 +813,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
int ret;
u32 reg, val;
- regmap_read(gmac->regmap, SYSCON_EMAC_REG, &val);
+ regmap_field_read(gmac->regmap_field, &val);
reg = gmac->variant->default_syscon_value;
if (reg != val)
dev_warn(priv->device,
@@ -883,7 +895,7 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
return -EINVAL;
}
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+ regmap_field_write(gmac->regmap_field, reg);
return 0;
}
@@ -892,7 +904,7 @@ static void sun8i_dwmac_unset_syscon(struct sunxi_priv_data *gmac)
{
u32 reg = gmac->variant->default_syscon_value;
- regmap_write(gmac->regmap, SYSCON_EMAC_REG, reg);
+ regmap_field_write(gmac->regmap_field, reg);
}
static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
@@ -980,6 +992,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
int ret;
struct stmmac_priv *priv;
struct net_device *ndev;
+ struct regmap *regmap;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
if (ret)
@@ -1014,14 +1027,21 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
gmac->regulator = NULL;
}
- gmac->regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
- "syscon");
- if (IS_ERR(gmac->regmap)) {
- ret = PTR_ERR(gmac->regmap);
+ regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
return ret;
}
+ gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
+ *gmac->variant->syscon_field);
+ if (IS_ERR(gmac->regmap_field)) {
+ ret = PTR_ERR(gmac->regmap_field);
+ dev_err(dev, "Unable to map syscon register: %d\n", ret);
+ return ret;
+ }
+
plat_dat->interface = of_get_phy_mode(dev->of_node);
/* platform data specifying hardware features and callbacks.
--
2.17.0
^ permalink raw reply related
* [PATCH RESEND net-next v2 6/8] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from external device
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
address space. Using a standard syscon to access it provides no
coordination with the CCU driver for register access. Neither does
it prevent this and other drivers from accessing other, maybe critical,
clock control registers. On other SoCs, the register is in the "system
control" address space, which might also contain controls for mapping
SRAM to devices or the CPU. This hardware has the same issues.
Instead, for these types of setups, we let the device containing the
control register create a regmap tied to it. We can then get the device
from the existing syscon phandle, and retrieve the regmap with
dev_get_regmap().
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 50 ++++++++++++++++++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index bbc051474806..79e104a20e20 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -983,6 +983,34 @@ static struct mac_device_info *sun8i_dwmac_setup(void *ppriv)
return mac;
}
+static struct regmap *sun8i_dwmac_get_syscon_from_dev(struct device_node *node)
+{
+ struct device_node *syscon_node;
+ struct platform_device *syscon_pdev;
+ struct regmap *regmap = NULL;
+
+ syscon_node = of_parse_phandle(node, "syscon", 0);
+ if (!syscon_node)
+ return ERR_PTR(-ENODEV);
+
+ syscon_pdev = of_find_device_by_node(syscon_node);
+ if (!syscon_pdev) {
+ /* platform device might not be probed yet */
+ regmap = ERR_PTR(-EPROBE_DEFER);
+ goto out_put_node;
+ }
+
+ /* If no regmap is found then the other device driver is at fault */
+ regmap = dev_get_regmap(&syscon_pdev->dev, NULL);
+ if (!regmap)
+ regmap = ERR_PTR(-EINVAL);
+
+ platform_device_put(syscon_pdev);
+out_put_node:
+ of_node_put(syscon_node);
+ return regmap;
+}
+
static int sun8i_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -1027,7 +1055,27 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
gmac->regulator = NULL;
}
- regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "syscon");
+ /* The "GMAC clock control" register might be located in the
+ * CCU address range (on the R40), or the system control address
+ * range (on most other sun8i and later SoCs).
+ *
+ * The former controls most if not all clocks in the SoC. The
+ * latter has an SoC identification register, and on some SoCs,
+ * controls to map device specific SRAM to either the intended
+ * peripheral, or the CPU address space.
+ *
+ * In either case, there should be a coordinated and restricted
+ * method of accessing the register needed here. This is done by
+ * having the device export a custom regmap, instead of a generic
+ * syscon, which grants all access to all registers.
+ *
+ * To support old device trees, we fall back to using the syscon
+ * interface if possible.
+ */
+ regmap = sun8i_dwmac_get_syscon_from_dev(pdev->dev.of_node);
+ if (IS_ERR(regmap))
+ regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "syscon");
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
dev_err(&pdev->dev, "Unable to map syscon: %d\n", ret);
--
2.17.0
^ permalink raw reply related
* [PATCH RESEND net-next v2 7/8] net: stmmac: dwmac-sun8i: Support different ranges for TX/RX delay chains
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
On the R40 SoC, the RX delay chain only has a range of 0~7 (hundred
picoseconds), instead of 0~31. Also the TX delay chain is completely
absent.
This patch adds support for different ranges by adding per-compatible
maximum values in the variant data. A maximum of 0 indicates that the
delay chain is not supported or absent.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 +++++++++++++------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 79e104a20e20..4f5612a3c855 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -47,6 +47,12 @@
* @support_mii: Does the MAC handle MII
* @support_rmii: Does the MAC handle RMII
* @support_rgmii: Does the MAC handle RGMII
+ *
+ * @rx_delay_max: Maximum raw value for RX delay chain
+ * @tx_delay_max: Maximum raw value for TX delay chain
+ * These two also indicate the bitmask for
+ * the RX and TX delay chain registers. A
+ * value of zero indicates this is not supported.
*/
struct emac_variant {
u32 default_syscon_value;
@@ -55,6 +61,8 @@ struct emac_variant {
bool support_mii;
bool support_rmii;
bool support_rgmii;
+ u8 rx_delay_max;
+ u8 tx_delay_max;
};
/* struct sunxi_priv_data - hold all sunxi private data
@@ -91,7 +99,9 @@ static const struct emac_variant emac_variant_h3 = {
.soc_has_internal_phy = true,
.support_mii = true,
.support_rmii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
static const struct emac_variant emac_variant_v3s = {
@@ -106,7 +116,9 @@ static const struct emac_variant emac_variant_a83t = {
.syscon_field = &sun8i_syscon_reg_field,
.soc_has_internal_phy = false,
.support_mii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
static const struct emac_variant emac_variant_a64 = {
@@ -115,7 +127,9 @@ static const struct emac_variant emac_variant_a64 = {
.soc_has_internal_phy = false,
.support_mii = true,
.support_rmii = true,
- .support_rgmii = true
+ .support_rgmii = true,
+ .rx_delay_max = 31,
+ .tx_delay_max = 7,
};
#define EMAC_BASIC_CTL0 0x00
@@ -219,9 +233,7 @@ static const struct emac_variant emac_variant_a64 = {
#define SYSCON_RMII_EN BIT(13) /* 1: enable RMII (overrides EPIT) */
/* Generic system control EMAC_CLK bits */
-#define SYSCON_ETXDC_MASK GENMASK(2, 0)
#define SYSCON_ETXDC_SHIFT 10
-#define SYSCON_ERXDC_MASK GENMASK(4, 0)
#define SYSCON_ERXDC_SHIFT 5
/* EMAC PHY Interface Type */
#define SYSCON_EPIT BIT(2) /* 1: RGMII, 0: MII */
@@ -847,8 +859,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
}
val /= 100;
dev_dbg(priv->device, "set tx-delay to %x\n", val);
- if (val <= SYSCON_ETXDC_MASK) {
- reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
+ if (val <= gmac->variant->tx_delay_max) {
+ reg &= ~(gmac->variant->tx_delay_max <<
+ SYSCON_ETXDC_SHIFT);
reg |= (val << SYSCON_ETXDC_SHIFT);
} else {
dev_err(priv->device, "Invalid TX clock delay: %d\n",
@@ -864,8 +877,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
}
val /= 100;
dev_dbg(priv->device, "set rx-delay to %x\n", val);
- if (val <= SYSCON_ERXDC_MASK) {
- reg &= ~(SYSCON_ERXDC_MASK << SYSCON_ERXDC_SHIFT);
+ if (val <= gmac->variant->rx_delay_max) {
+ reg &= ~(gmac->variant->rx_delay_max <<
+ SYSCON_ERXDC_SHIFT);
reg |= (val << SYSCON_ERXDC_SHIFT);
} else {
dev_err(priv->device, "Invalid RX clock delay: %d\n",
--
2.17.0
^ permalink raw reply related
* [PATCH RESEND net-next v2 8/8] net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
From: Chen-Yu Tsai @ 2018-05-13 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513191425.9801-1-wens@csie.org>
The Allwinner R40 SoC has the EMAC controller supported by dwmac-sun8i.
It is named "GMAC", while EMAC refers to the 10/100 Mbps Ethernet
controller supported by sun4i-emac. The controller is the same, but
the R40 has the glue layer controls in the clock control unit (CCU),
with a reduced RX delay chain, and no TX delay chain.
This patch adds support for it using the framework laid out by previous
patches to map the differences.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4f5612a3c855..2f7f0915f071 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -93,6 +93,13 @@ static const struct reg_field sun8i_syscon_reg_field = {
.msb = 31,
};
+/* EMAC clock register @ 0x164 in the CCU address range */
+static const struct reg_field sun8i_ccu_reg_field = {
+ .reg = 0x164,
+ .lsb = 0,
+ .msb = 31,
+};
+
static const struct emac_variant emac_variant_h3 = {
.default_syscon_value = 0x58000,
.syscon_field = &sun8i_syscon_reg_field,
@@ -121,6 +128,14 @@ static const struct emac_variant emac_variant_a83t = {
.tx_delay_max = 7,
};
+static const struct emac_variant emac_variant_r40 = {
+ .default_syscon_value = 0,
+ .syscon_field = &sun8i_ccu_reg_field,
+ .support_mii = true,
+ .support_rgmii = true,
+ .rx_delay_max = 7,
+};
+
static const struct emac_variant emac_variant_a64 = {
.default_syscon_value = 0,
.syscon_field = &sun8i_syscon_reg_field,
@@ -1160,6 +1175,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
.data = &emac_variant_v3s },
{ .compatible = "allwinner,sun8i-a83t-emac",
.data = &emac_variant_a83t },
+ { .compatible = "allwinner,sun8i-r40-gmac",
+ .data = &emac_variant_r40 },
{ .compatible = "allwinner,sun50i-a64-emac",
.data = &emac_variant_a64 },
{ }
--
2.17.0
^ permalink raw reply related
* [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
From: Chen-Yu Tsai @ 2018-05-13 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502115437.zlu2rafrguufutvp@flea>
On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
>>
>>
>> ? 2018?5?2? GMT+08:00 ??5:53:21, Chen-Yu Tsai <wens@csie.org> ??:
>> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
>> ><maxime.ripard@bootlin.com> wrote:
>> >> Hi,
>> >>
>> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
>> >>> From: Icenowy Zheng <icenowy@aosc.io>
>> >>>
>> >>> Allwinner A64 has a SRAM controller, and in the device tree
>> >currently
>> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
>> >>> register. As SRAM controller driver can now export regmap for this
>> >>> register, replace the syscon node to the SRAM controller device
>> >node,
>> >>> and let EMAC driver to acquire its EMAC clock regmap.
>> >>>
>> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> >>> ---
>> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
>> >+++++++++++++++----
>> >>> 1 file changed, 19 insertions(+), 4 deletions(-)
>> >>>
>> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> index 1b2ef28c42bd..1c37659d9d41 100644
>> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >>> @@ -168,10 +168,25 @@
>> >>> #size-cells = <1>;
>> >>> ranges;
>> >>>
>> >>> - syscon: syscon at 1c00000 {
>> >>> - compatible =
>> >"allwinner,sun50i-a64-system-controller",
>> >>> - "syscon";
>> >>> + sram_controller: sram-controller at 1c00000 {
>> >>> + compatible =
>> >"allwinner,sun50i-a64-sram-controller";
>> >>
>> >> I don't think there's anything preventing us from keeping the
>> >> -system-controller compatible. It's what was in the DT before, and
>> >> it's how it's called in the datasheet.
>> >
>> >I actually meant to ask you about this. The -system-controller
>> >compatible matches the datasheet better. Maybe we should just
>> >switch to that one?
>>
>> No, if we do the switch the system-controller compatible,
>> the device will be probed on the same memory region with
>> a syscon on old DTs.
>
> The device hasn't magically changed either. Maybe we just need to add
> a check to make sure we don't have the syscon compatible in the SRAM
> driver probe so that the double driver issue doesn't happen?
The syscon interface (which is not even a full blown device driver)
only looks at the "syscon" compatible. Either way we're removing that
part from the device tree so things should be ok for new device trees.
As Maxime mentioned we can do a check for the syscon compatible and
either give a warning to the user asking them to update their device
tree, or not register our custom regmap, or not probe the SRAM driver.
Personally I prefer the first option. The system controller block is
probed before any syscon users, so we should be fine, given the dwmac
driver goes the custom regmap path first.
BTW, I still might end up changing the compatible. The manual uses
"system control", not "system controller", which I think makes sense,
since it is just a bunch of register files, kind of like the GRF
(General Register Files) block found in Rockchip SoCs [1], and not an
actual "controller".
ChenYu
[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/soc/rockchip/grf.txt
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513191425.9801-2-wens@csie.org>
On Mon, May 14, 2018 at 03:14:18AM +0800, Chen-Yu Tsai wrote:
> The clock delay chains found in the glue layer for dwmac-sun8i are only
> used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
> MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
> range of possible values for the delay chain.
>
> This patch reformats the delay chain section of the device tree binding
> to make it clear that the delay chains only apply to RGMII PHYs, and
> make it easier to add the R40-specific bits later.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> index 3d6d5fa0c4d5..e04ce75e24a3 100644
> --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> @@ -28,10 +28,13 @@ Required properties:
> - allwinner,sun8i-a83t-system-controller
>
> Optional properties:
> -- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
> -- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
> -Both delay properties need to be a multiple of 100. They control the delay for
> -external PHY.
> +- allwinner,tx-delay-ps: TX clock delay chain value in ps.
> + Range is 0-700. Default is 0.
> +- allwinner,rx-delay-ps: RX clock delay chain value in ps.
> + Range is 0-3100. Default is 0.
> +Both delay properties need to be a multiple of 100. They control the
> +clock delay for external RGMII PHY. They do not apply to the internal
> +PHY or external non-RGMII PHYs.
Hi Chen-Yu
Are these delays the MAC applies? Not the PHY. It would be good to
make it clear here these are MAC imposed delays.
Andrew
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-05-13 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513194919.GE12738@lunn.ch>
On Sun, May 13, 2018 at 12:49 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, May 14, 2018 at 03:14:18AM +0800, Chen-Yu Tsai wrote:
>> The clock delay chains found in the glue layer for dwmac-sun8i are only
>> used with RGMII PHYs. They are not intended for non-RGMII PHYs, such as
>> MII external PHYs or the internal PHY. Also, a recent SoC has a smaller
>> range of possible values for the delay chain.
>>
>> This patch reformats the delay chain section of the device tree binding
>> to make it clear that the delay chains only apply to RGMII PHYs, and
>> make it easier to add the R40-specific bits later.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>> ---
>> Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 11 +++++++----
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> index 3d6d5fa0c4d5..e04ce75e24a3 100644
>> --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
>> @@ -28,10 +28,13 @@ Required properties:
>> - allwinner,sun8i-a83t-system-controller
>>
>> Optional properties:
>> -- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
>> -- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
>> -Both delay properties need to be a multiple of 100. They control the delay for
>> -external PHY.
>> +- allwinner,tx-delay-ps: TX clock delay chain value in ps.
>> + Range is 0-700. Default is 0.
>> +- allwinner,rx-delay-ps: RX clock delay chain value in ps.
>> + Range is 0-3100. Default is 0.
>> +Both delay properties need to be a multiple of 100. They control the
>> +clock delay for external RGMII PHY. They do not apply to the internal
>> +PHY or external non-RGMII PHYs.
>
> Hi Chen-Yu
>
> Are these delays the MAC applies? Not the PHY. It would be good to
> make it clear here these are MAC imposed delays.
Yes these are applied on the MAC side. Being described in the device
tree bindings for the MAC, I thought this was implied to be the case?
Are there known exceptions?
Thanks
ChenYu
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66nqWnioS1pwfWFtMZFZSWvf4SwXr_ExnnGvYsK9RU_LA@mail.gmail.com>
> > Hi Chen-Yu
> >
> > Are these delays the MAC applies? Not the PHY. It would be good to
> > make it clear here these are MAC imposed delays.
>
> Yes these are applied on the MAC side. Being described in the device
> tree bindings for the MAC, I thought this was implied to be the case?
> Are there known exceptions?
There is frequent confusion with this. Most of the time, the PHY does
the delay, not the MAC, based on the phy-mode. So the MAC doing it is
an exception in itself.
Do you actually need these delays for the board you adding support
for? Does the PHY not support adding the needed delays? If you don't
need the delays, i would not even implement them.
Andrew
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Icenowy Zheng @ 2018-05-13 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513200529.GF12738@lunn.ch>
? 2018?5?14? GMT+08:00 ??4:05:29, Andrew Lunn <andrew@lunn.ch> ??:
>> > Hi Chen-Yu
>> >
>> > Are these delays the MAC applies? Not the PHY. It would be good to
>> > make it clear here these are MAC imposed delays.
>>
>> Yes these are applied on the MAC side. Being described in the device
>> tree bindings for the MAC, I thought this was implied to be the case?
>> Are there known exceptions?
>
>There is frequent confusion with this. Most of the time, the PHY does
>the delay, not the MAC, based on the phy-mode. So the MAC doing it is
>an exception in itself.
>
>Do you actually need these delays for the board you adding support
>for? Does the PHY not support adding the needed delays? If you don't
>need the delays, i would not even implement them.
They are needed if the rx/tx have not equal length.
For several boards if the delay is not present, the network
is unusable. (I have at least met this on Banana Pi M3, an
Allwinner A83T SBC w/ RTL8211E)
>
> Andrew
>
>_______________________________________________
>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 RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-05-13 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513200529.GF12738@lunn.ch>
On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > Hi Chen-Yu
>> >
>> > Are these delays the MAC applies? Not the PHY. It would be good to
>> > make it clear here these are MAC imposed delays.
>>
>> Yes these are applied on the MAC side. Being described in the device
>> tree bindings for the MAC, I thought this was implied to be the case?
>> Are there known exceptions?
>
> There is frequent confusion with this. Most of the time, the PHY does
> the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> an exception in itself.
>
> Do you actually need these delays for the board you adding support
> for? Does the PHY not support adding the needed delays? If you don't
> need the delays, i would not even implement them.
Yes this is already used on the Bananapi M3. This patch merely reformats
the description and adds a note saying this only applies to RGMII mode.
ChenYu
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <272E1914-029C-492C-B521-BC63D6A705D7@aosc.io>
On Mon, May 14, 2018 at 04:10:58AM +0800, Icenowy Zheng wrote:
>
>
> ? 2018?5?14? GMT+08:00 ??4:05:29, Andrew Lunn <andrew@lunn.ch> ??:
> >> > Hi Chen-Yu
> >> >
> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> > make it clear here these are MAC imposed delays.
> >>
> >> Yes these are applied on the MAC side. Being described in the device
> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> Are there known exceptions?
> >
> >There is frequent confusion with this. Most of the time, the PHY does
> >the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> >an exception in itself.
> >
> >Do you actually need these delays for the board you adding support
> >for? Does the PHY not support adding the needed delays? If you don't
> >need the delays, i would not even implement them.
>
> They are needed if the rx/tx have not equal length.
>
> For several boards if the delay is not present, the network
> is unusable. (I have at least met this on Banana Pi M3, an
> Allwinner A83T SBC w/ RTL8211E)
The RTL8211E does not appear to support adding delays, via
registers. You can do it with strapping resistors. The RTL8211F does
support delays via a register. So for the Banana Pi M3 it is
justified.
However, in general, i would recommend letting the PHY do it, if it
can.
Andrew
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Andrew Lunn @ 2018-05-13 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64ACc1tQRhy4LhnvCC7VJ3nVM-wMbgUgzviGMWKPFsSuQ@mail.gmail.com>
On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> > Hi Chen-Yu
> >> >
> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> > make it clear here these are MAC imposed delays.
> >>
> >> Yes these are applied on the MAC side. Being described in the device
> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> Are there known exceptions?
> >
> > There is frequent confusion with this. Most of the time, the PHY does
> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> > an exception in itself.
> >
> > Do you actually need these delays for the board you adding support
> > for? Does the PHY not support adding the needed delays? If you don't
> > need the delays, i would not even implement them.
>
> Yes this is already used on the Bananapi M3. This patch merely reformats
> the description and adds a note saying this only applies to RGMII mode.
Yes, the current code is needed for the Bananapi M3. But you have
another patch which extends the code to support a smaller range. Do
you have a board which actually needs this? If not, i would not add
that new code.
Andrew
^ permalink raw reply
* [PATCH v1 11/13] dt-bindings: power: add PX30 SoCs header for power-domain
From: Heiko Stübner @ 2018-05-13 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c9606f0-5c97-1a6e-a3c5-f6380c16fea4@rock-chips.com>
Hi,
Am Sonntag, 13. Mai 2018, 17:18:12 CEST schrieb Tao Huang:
> Hi Heiko:
>
> On 2018?05?12? 06:11, Heiko Stuebner wrote:
> > Here I have a naming question. When looking at the vendor kernel
> > it looks like the px30 is largely related to the rk3326.
> > (rk3326.dtsi includeing the px30.dtsi)
> >
> > What is the reason for basing the naming on the px30 this time? And could
> > we possibly keep to rkXXXX names for the basic things in the kernel, thus
> > keeping the pxXX as second name, like with the other px-variants before?
>
> PX30 and RK3326 are different chips. PX30 has more features. You can simply
> think that RK3326 is a subset of PX30. The RK3326 is more like a PX30
> derivative chip. This is not the same as the previous chips. So we use PX30
> instead of RK3326 for name, and the opening document is only for PX30, we
> think this is more convenient for developers.
ok, sounds reasonable :-) ... So we'll stay with the PX30.
Heiko
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Linus Walleij @ 2018-05-13 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <91dad272-e07d-2ab6-2afa-538294e9cefa@suse.de>
On Wed, May 9, 2018 at 11:44 AM, Alexander Graf <agraf@suse.de> wrote:
> On 05/07/2018 08:31 PM, Bjorn Andersson wrote:
>> Can you please name platform that has enough support for Alexander to
>> care about backwards and forwards compatibility but lacks a pinctrl
>> driver.
>
> ZynqMP is one example that immediately comes to my mind. I'm sure there are
> others too.
Why isn't that using drivers/pinctrl/pinctrl-zynq.c?
How is it so very different from (old) Zynq as it is already using
the same GPIO driver?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Andy Shevchenko @ 2018-05-13 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <662ce972-56a9-9daa-d332-faa08b89c05a@kapsi.fi>
On Sun, May 13, 2018 at 9:04 PM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
> On 05/13/2018 05:16 PM, Andy Shevchenko wrote:
>>
>> On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen <mperttunen@nvidia.com>
>> wrote:
>>>
>>> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
>>> multiplexing multiple "virtual UARTs" into a single hardware serial
>>> port. The TCU is the primary serial port on Tegra194 devices.
>>>
>>> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
>>> are part of Tegra HSP blocks that are already controlled by the Tegra
>>> HSP mailbox driver.
>>> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned
>>> int mctrl)
>>> +{
>>
>>
>>> + (void)port;
>>> + (void)mctrl;
>>
>>
>> Huh?
>
>
> The serial core calls these callbacks without checking if they are set. They
> don't make sense for this driver so they are stubbed out.
My question why do you need these ugly lines? I'm pretty sure no other
driver with stubs using such style.
>>> +}
>>> + if (written == 3) {
>>> + value |= 3 << 24;
>>> + value |= BIT(26);
>>> + mbox_send_message(tcu->tx, &value);
>>
>>
>>> + }
>>
>>
>> (1)
>>
>>> + }
>>> +
>>> + if (written) {
>>> + value |= written << 24;
>>> + value |= BIT(26);
>>> + mbox_send_message(tcu->tx, &value);
>>> + }
>>
>>
>> (2)
>>
>> These are code duplications.
>
>
> Indeed - the length of the duplicated code is so short, and the instances
> are so close to each other, that I don't find it necessary (or clearer) to
> have an extra function.
It makes sense. Consider to refactor other way w/o duplication then.
>>> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
>>> + struct ktermios *new,
>>> + struct ktermios *old)
>>> +{
>>> + (void)port;
>>> + (void)new;
>>> + (void)old;
>>> +}
>>
>>
>> Remove those unused stub contents.
>
>
> Sure. I had these here so that we don't get unused parameter warnings, but I
> can just as well remove the parameter names.
What warnings? How did you get them? We have them disabled as far as I
know even with W=1.
>
>>
>>> + return uart_set_options(&tegra_tcu_uart_port, cons,
>>> + 115200, 'n', 8, 'n');
>>
>>
>> Can't it be one line?
>
>
> It would be a total of 81 characters in length on one line, so no.
So, yes. 1 character doesn't prevent us make the readability better.
Please, put to one line.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 1/2] PCI: kirin: Add MSI support
From: Andy Shevchenko @ 2018-05-13 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526030149-23985-2-git-send-email-chenyao11@huawei.com>
On Fri, May 11, 2018 at 12:15 PM, Yao Chen <chenyao11@huawei.com> wrote:
> Add support for MSI.
> + int ret;
> +
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> + if (pci->pp.msi_irq < 0) {
> + dev_err(&pdev->dev, "failed to get MSI IRQ (%d)\n",
> + pci->pp.msi_irq);
> + return -ENODEV;
Why shadowing actual error code?
> + }
> + ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
> + kirin_pcie_msi_irq_handler,
> + IRQF_SHARED | IRQF_NO_THREAD,
> + "kirin_pcie_msi", &pci->pp);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to request MSI IRQ %d\n",
> + pci->pp.msi_irq);
> + return ret;
> + }
It would be easy to read and maintain if this would be a separate function.
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Adam Ford @ 2018-05-13 23:20 UTC (permalink / raw)
To: linux-arm-kernel
When using the board files the LCD works, but not with the DT.
This adds enables the original da850-evm to work with the same
LCD in device tree mode.
The EVM has a gpio for the regulator and a gpio enable. The LCD and
the vpif display pins are mutually exclusive, so if using the LCD,
do not load the vpif driver.
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
backlight which better matches the schematic. Updated the description to explain
that it cannot be used at the same time as the vpif driver.
V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 2e817da37fdb..3f1c8be07efe 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,50 @@
spi0 = &spi1;
};
+ backlight {
+ compatible = "gpio-backlight";
+ enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
+ };
+
+ panel {
+ compatible = "ti,tilcdc,panel";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ status = "okay";
+ enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* GP2[8] */
+
+ panel-info {
+ ac-bias = <255>;
+ ac-bias-intrpt = <0>;
+ dma-burst-sz = <16>;
+ bpp = <16>;
+ fdd = <0x80>;
+ sync-edge = <0>;
+ sync-ctrl = <1>;
+ raster-order = <0>;
+ fifo-th = <0>;
+ };
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: 480x272 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <3>;
+ hback-porch = <2>;
+ hsync-len = <42>;
+ vback-porch = <3>;
+ vfront-porch = <4>;
+ vsync-len = <11>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+ };
+ };
+
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -35,6 +79,16 @@
regulator-boot-on;
};
+ backlight_reg: backlight-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_backlight_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
+ regulator-always-on;
+ enable-active-high;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,name = "DA850/OMAP-L138 EVM";
@@ -109,6 +163,10 @@
status = "okay";
};
+&lcdc {
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
clock-frequency = <100000>;
--
2.17.0
^ permalink raw reply related
* [PATCH] ARM: dts: at91-sama5d2_xplained: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:22 UTC (permalink / raw)
To: linux-arm-kernel
GPIO_ACTIVE_LOW was being used to specify an interrupt, use
IRQ_TYPE_EDGE_RISING instead. This improves DT readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e4bbb7e..fcc85d7 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -232,7 +232,7 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_charger_chglev &pinctrl_charger_lbo &pinctrl_charger_irq>;
interrupt-parent = <&pioA>;
- interrupts = <PIN_PB13 GPIO_ACTIVE_LOW>;
+ interrupts = <PIN_PB13 IRQ_TYPE_EDGE_RISING>;
active-semi,chglev-gpios = <&pioA PIN_PA12 GPIO_ACTIVE_HIGH>;
active-semi,lbo-gpios = <&pioA PIN_PC8 GPIO_ACTIVE_LOW>;
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: vf-colibri-eval-v3.dtsi: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:24 UTC (permalink / raw)
To: linux-arm-kernel
GPIO_ACTIVE_LOW was being used to specify an interrupt, use
IRQ_TYPE_EDGE_RISING instead. This improves DT readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index d8b2972..e2da122 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -117,7 +117,7 @@
clocks = <&clk16m>;
spi-max-frequency = <10000000>;
interrupt-parent = <&gpio1>;
- interrupts = <11 GPIO_ACTIVE_LOW>;
+ interrupts = <11 IRQ_TYPE_EDGE_RISING>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx53-qsb: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:26 UTC (permalink / raw)
To: linux-arm-kernel
Replace magic number with the proper IRQ_TYPE specifier to improve DT
readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/imx53-qsb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index d3d662e..dca6c32 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -23,7 +23,7 @@
compatible = "dlg,da9053-aa", "dlg,da9052";
reg = <0x48>;
interrupt-parent = <&gpio7>;
- interrupts = <11 0x8>; /* low-level active IRQ at GPIO7_11 */
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>; /* low-level active IRQ at GPIO7_11 */
regulators {
buck1_reg: buck1 {
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx53-voipac-dmm-668: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:27 UTC (permalink / raw)
To: linux-arm-kernel
Replace magic number with the proper IRQ_TYPE specifier to improve DT
readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi b/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
index df8dafe..f83a8c6 100644
--- a/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
+++ b/arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
@@ -150,7 +150,7 @@
compatible = "dlg,da9053-aa", "dlg,da9052";
reg = <0x48>;
interrupt-parent = <&gpio7>;
- interrupts = <11 0x8>; /* low-level active IRQ at GPIO7_11 */
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>; /* low-level active IRQ at GPIO7_11 */
regulators {
buck1_reg: buck1 {
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx6qdl-phytec-pfla02: Use IRQ_TYPE specifier
From: Hernán Gonzalez @ 2018-05-13 23:28 UTC (permalink / raw)
To: linux-arm-kernel
Replace magic number with the proper IRQ_TYPE specifier to improve DT
readability.
Signed-off-by: Hern?n Gonzalez <hernan@vanguardiasur.com.ar>
---
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index c58f344..1b79ee7 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -115,7 +115,7 @@
compatible = "dlg,da9063";
reg = <0x58>;
interrupt-parent = <&gpio2>;
- interrupts = <9 0x8>; /* active-low GPIO2_9 */
+ interrupts = <9 IRQ_TYPE_LOW_LEVEL>; /* active-low GPIO2_9 */
regulators {
vddcore_reg: bcore1 {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Adam Ford @ 2018-05-14 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509172606.29387-1-david@lechnology.com>
On Wed, May 9, 2018 at 12:25 PM, David Lechner <david@lechnology.com> wrote:
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 3 patches fix some issues with the clock
> drivers that have already been accepted into the mainline kernel.
>
> Then, starting with "ARM: davinci: pass clock as parameter to
> davinci_timer_init()", we get the mach code ready for the switch by adding the
> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
> around the legacy clocks so that we can switch easily between the old and the
> new.
>
> "ARM: davinci: switch to common clock framework" actually flips the switch
> to start using the new clock drivers. Then the next 8 patches remove all
> of the old clock code.
>
> The final four patches add device tree clock support to the one SoC that
> supports it.
>
> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
> board file).
>
I am not sure if I did something wrong, but I attempted to build and I
wasn't able to boot the da850-evm.dtb your repo common-clk-v11,
however the legacy board file boot was OK.
make davinci_all_defconfig ARCH=arm
make zImage modules da850-evm.dtb ARCH=arm CROSS_COMPILE=arm-linux- -j8
3140416 bytes read in 1464 ms (2 MiB/s)
20353 bytes read in 15 ms (1.3 MiB/s)
## Flattened Device Tree blob at c0600000
Booting using the fdt blob at 0xc0600000
Loading Device Tree to c7e57000, end c7e5ef80 ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
(and hang)
If you have some suggestions, I am try them as I get time.
adam
>
> Changes:
>
> v10 changes (also see individual patches for details):
> - Reworked device tree bindings for DaVinci timer.
> - Dropped helper functions to conditionally call devm_* versions of functions
> - Fix some typos
> - Fix some rebasing issues introduced in v9
>
> v9 changes (also see individual patches for details):
> - Rebased on linux-davnci/master (f5e3203bb775)
> - Dropped drivers/clk patches that landed in v4.17
> - New drivers/clk patches for early boot special case
> - New patch for ti,davinci-timer device tree bindings
> - Updated mach/davinci patches to register clocks in early boot when needed
>
> v8 changes (also see individual patches for details):
> - Rebased on linux-davinci/master
> - Dropped use of __init and __initconst attributes in clk drivers
> - Add clkdev lookups for PLL SYSCLKs
> - Fix genpd clock reference counting issue
> - Fix PSC clock driver loading order issue
> - Fix typo in device tree and add more power-domains properties
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
> series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
> what they need to do to make this work, but I haven't figured out how to
> test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
> sent separately after this series has landed.)
>
>
> Dependencies:
>
> There are still some outstanding fixes to get everything working correctly.
> These are all just runtime dependencies and only needed for certain platforms.
>
> - "drm/tilcdc: Fix setting clock divider for omap-l138"[1]
> - "clk: davinci: pll-dm355: fix SYSCLKn parent names"[2]
> - "remoteproc/davinci: common clock framework related fixes"[3]
>
> [1]: https://patchwork.freedesktop.org/patch/210696/
> [2]: https://lkml.org/lkml/2018/5/9/626
> [3]: https://lkml.org/lkml/2018/5/2/201
>
> You can find a working branch with everything included (plus a few extras, like
> cpufreq-dt) in the "common-clk-v10" branch of https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for the uninitiated:
>
> I only have one device to test with, which is based on da850, so I will
> have to rely on others to do some testing here. Since we are dealing with
> clocks, if something isn't working, you most likely won't see output on
> the serial port. To figure out what is going on, you need to enable...
>
> CONFIG_DEBUG_LL=y
> CONFIG_EARLY_PRINTK=y
>
> and add "earlyprintk clk_ignore_unused" to the kernel command line options.
> You may need to select a different UART for this depending on your board. I
> think UART1 is the default in the kernel configuration.
>
> On da850 devices comment out the lines:
>
> /* pll1_sysclk2 is not affected by CPU scaling, so use it for async3 */
> parent = clk_hw_get_parent_by_index(&mux->hw, 1);
> if (parent)
> clk_set_parent(mux->hw.clk, parent->clk);
> else
> dev_warn(dev, "Failed to find async3 parent clock\n");
>
> in da8xx-cfgchip.c or, if using device tree, comment out the lines:
>
> assigned-clocks = <&async3_clk>;
> assigned-clock-parents = <&pll1_sysclk 2>;
>
> in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock
> source will change during boot and cause garbled output after a point.
>
>
> David Lechner (27):
> clk: davinci: pll: allow dev == NULL
> clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
> clk: davinci: psc: allow for dev == NULL
> ARM: davinci: pass clock as parameter to davinci_timer_init()
> ARM: davinci: da830: add new clock init using common clock framework
> ARM: davinci: da850: add new clock init using common clock framework
> ARM: davinci: dm355: add new clock init using common clock framework
> ARM: davinci: dm365: add new clock init using common clock framework
> ARM: davinci: dm644x: add new clock init using common clock framework
> ARM: davinci: dm646x: add new clock init using common clock framework
> ARM: davinci: da8xx: add new USB PHY clock init using common clock
> framework
> ARM: davinci: da8xx: add new sata_refclk init using common clock
> framework
> ARM: davinci: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci_all_defconfig: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci: switch to common clock framework
> ARM: davinci: da830: Remove legacy clock init
> ARM: davinci: da850: Remove legacy clock init
> ARM: davinci: dm355: Remove legacy clock init
> ARM: davinci: dm365: Remove legacy clock init
> ARM: davinci: dm644x: Remove legacy clock init
> ARM: davinci: dm646x: Remove legacy clock init
> ARM: davinci: da8xx: Remove legacy USB and SATA clock init
> ARM: davinci: remove legacy clocks
> dt-bindings: timer: new bindings for TI DaVinci timer
> ARM: davinci: add device tree support to timer
> ARM: davinci: da8xx-dt: switch to device tree clocks
> ARM: dts: da850: Add clocks
>
> .../bindings/timer/ti,davinci-timer.txt | 37 +
> arch/arm/Kconfig | 5 +-
> arch/arm/boot/dts/da850-enbw-cmc.dts | 4 +
> arch/arm/boot/dts/da850-evm.dts | 4 +
> arch/arm/boot/dts/da850-lcdk.dts | 9 +
> arch/arm/boot/dts/da850-lego-ev3.dts | 4 +
> arch/arm/boot/dts/da850.dtsi | 168 ++++
> arch/arm/configs/davinci_all_defconfig | 1 -
> arch/arm/mach-davinci/Kconfig | 13 +-
> arch/arm/mach-davinci/Makefile | 4 +-
> arch/arm/mach-davinci/board-da830-evm.c | 12 +-
> arch/arm/mach-davinci/board-da850-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-leopard.c | 2 +
> arch/arm/mach-davinci/board-dm365-evm.c | 2 +
> arch/arm/mach-davinci/board-dm644x-evm.c | 2 +
> arch/arm/mach-davinci/board-dm646x-evm.c | 2 +
> arch/arm/mach-davinci/board-mityomapl138.c | 2 +
> arch/arm/mach-davinci/board-neuros-osd2.c | 2 +
> arch/arm/mach-davinci/board-omapl138-hawk.c | 11 +-
> arch/arm/mach-davinci/board-sffsdr.c | 2 +
> arch/arm/mach-davinci/clock.c | 745 -----------------
> arch/arm/mach-davinci/clock.h | 76 --
> arch/arm/mach-davinci/common.c | 3 -
> arch/arm/mach-davinci/da830.c | 462 ++---------
> arch/arm/mach-davinci/da850.c | 778 +++---------------
> arch/arm/mach-davinci/da8xx-dt.c | 66 --
> arch/arm/mach-davinci/davinci.h | 8 +
> arch/arm/mach-davinci/devices-da8xx.c | 43 +-
> arch/arm/mach-davinci/devices.c | 1 -
> arch/arm/mach-davinci/dm355.c | 406 ++-------
> arch/arm/mach-davinci/dm365.c | 485 +----------
> arch/arm/mach-davinci/dm644x.c | 344 +-------
> arch/arm/mach-davinci/dm646x.c | 372 +--------
> arch/arm/mach-davinci/include/mach/clock.h | 3 -
> arch/arm/mach-davinci/include/mach/common.h | 11 +-
> arch/arm/mach-davinci/include/mach/da8xx.h | 6 +-
> arch/arm/mach-davinci/pm_domain.c | 5 +
> arch/arm/mach-davinci/psc.c | 137 ---
> arch/arm/mach-davinci/psc.h | 12 -
> arch/arm/mach-davinci/time.c | 39 +-
> arch/arm/mach-davinci/usb-da8xx.c | 242 +-----
> drivers/clk/davinci/pll-da830.c | 4 +-
> drivers/clk/davinci/pll-da850.c | 36 +-
> drivers/clk/davinci/pll-dm355.c | 8 +-
> drivers/clk/davinci/pll-dm365.c | 8 +-
> drivers/clk/davinci/pll-dm644x.c | 8 +-
> drivers/clk/davinci/pll-dm646x.c | 8 +-
> drivers/clk/davinci/pll.c | 110 +--
> drivers/clk/davinci/pll.h | 30 +-
> drivers/clk/davinci/psc-dm355.c | 2 +-
> drivers/clk/davinci/psc-dm365.c | 2 +-
> drivers/clk/davinci/psc-dm644x.c | 2 +-
> drivers/clk/davinci/psc-dm646x.c | 2 +-
> drivers/clk/davinci/psc.c | 27 +-
> include/linux/clk/davinci.h | 29 +
> 56 files changed, 860 insertions(+), 3950 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
> delete mode 100644 arch/arm/mach-davinci/clock.c
> delete mode 100644 arch/arm/mach-davinci/psc.c
> create mode 100644 include/linux/clk/davinci.h
>
> --
> 2.17.0
>
^ permalink raw reply
* reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
From: songxiaowei @ 2018-05-14 1:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi, Andy Shevchenko
Yao is on maternity leave, and I'll take over the job after discussing with her.
> -----????-----
> ???: Andy Shevchenko [mailto:andy.shevchenko at gmail.com]
> ????: 2018?5?14? 7:16
> ???: chenyao (F) <chenyao11@huawei.com>
> ??: songxiaowei <songxiaowei@hisilicon.com>; Wangbinghui
> <wangbinghui@hisilicon.com>; Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>;
> Bjorn Helgaas <bhelgaas@google.com>; xuwei (O) <xuwei5@huawei.com>;
> Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Catalin Marinas <catalin.marinas@arm.com>; Will Deacon
> <will.deacon@arm.com>; linux-pci at vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; linux-arm Mailing List
> <linux-arm-kernel@lists.infradead.org>; devicetree
> <devicetree@vger.kernel.org>; dimitrysh at google.com;
> guodong.xu at linaro.org; Suzhuangluan <suzhuangluan@hisilicon.com>; Kongfei
> <kongfei@hisilicon.com>
> ??: Re: [PATCH v3 1/2] PCI: kirin: Add MSI support
>
> On Fri, May 11, 2018 at 12:15 PM, Yao Chen <chenyao11@huawei.com> wrote:
> > Add support for MSI.
>
>
> > + int ret;
> > +
> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
>
> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> > + if (pci->pp.msi_irq < 0) {
> > + dev_err(&pdev->dev, "failed to get MSI IRQ
> (%d)\n",
> > + pci->pp.msi_irq);
>
> > + return -ENODEV;
>
> Why shadowing actual error code?
[songxiaowei] Sorry, I can't get your point about this, would you explain it for me.
>
> > + }
> > + ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
> > + kirin_pcie_msi_irq_handler,
> > + IRQF_SHARED |
> IRQF_NO_THREAD,
> > + "kirin_pcie_msi", &pci->pp);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to request MSI
> IRQ %d\n",
> > + pci->pp.msi_irq);
> > + return ret;
> > + }
>
> It would be easy to read and maintain if this would be a separate function.
[songxiaowei] Yes, a separate function will be better, and I'll fix it.
>
> > + }
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks a lot,
Best Regards,
Xiaowei Song
^ 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