* [PATCH v11 2/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2017-01-07 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483596119-27508-3-git-send-email-peter.chen@nxp.com>
On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices. The pwrseq
> librares always need to allocate extra instance for compatible
> string match.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover other controls in
> future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> For new power sequence library, it can add its compatible string
> to pwrseq_of_match_table, then the pwrseq core will match it with
> DT's, and choose this library at runtime.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> MAINTAINERS | 9 +
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/pwrseq/Kconfig | 20 ++
> drivers/power/pwrseq/Makefile | 2 +
> drivers/power/pwrseq/core.c | 335 ++++++++++++++++++++++++++++++++++
> drivers/power/pwrseq/pwrseq_generic.c | 224 +++++++++++++++++++++++
> include/linux/power/pwrseq.h | 81 ++++++++
> 8 files changed, 673 insertions(+)
> create mode 100644 drivers/power/pwrseq/Kconfig
> create mode 100644 drivers/power/pwrseq/Makefile
> create mode 100644 drivers/power/pwrseq/core.c
> create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> create mode 100644 include/linux/power/pwrseq.h
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested on Odroid U3 (reset sequence for LAN9730):
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v11 3/8] binding-doc: usb: usb-device: add optional properties for power sequence
From: Krzysztof Kozlowski @ 2017-01-07 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483596119-27508-4-git-send-email-peter.chen@nxp.com>
On Thu, Jan 05, 2017 at 02:01:54PM +0800, Peter Chen wrote:
> Add optional properties for power sequence.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/usb/usb-device.txt | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v11 4/8] usb: core: add power sequence handling for USB devices
From: Krzysztof Kozlowski @ 2017-01-07 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483596119-27508-5-git-send-email-peter.chen@nxp.com>
On Thu, Jan 05, 2017 at 02:01:55PM +0800, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
>
> In this patch, it calls power sequence library APIs to finish
> the power sequence events. It will do power on sequence at hub's
> probe for all devices under this hub (includes root hub).
> At hub_disconnect, it will do power off sequence which is at powered
> on list.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
> Reviewed-by: Vaibhav Hiremath <hvaibhav.linux@gmail.com>
> ---
> drivers/usb/Kconfig | 1 +
> drivers/usb/core/hub.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
> drivers/usb/core/hub.h | 1 +
> 3 files changed, 46 insertions(+), 4 deletions(-)
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested on Odroid U3 (reset sequence for LAN9730):
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
From: Krzysztof Kozlowski @ 2017-01-07 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107085203.4431-5-krzk@kernel.org>
Odroid U3 needs a power sequence for lan9730, if it was enabled by
bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device
is present on Odroid U3).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v1 (v1 -> v1.1):
1. Enable also usb3503 driver.
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index b01a43851294..8cc73e084b25 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -443,6 +443,7 @@ CONFIG_POWER_RESET_RMOBILE=y
CONFIG_POWER_RESET_ST=y
CONFIG_POWER_AVS=y
CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_PWRSEQ_GENERIC=y
CONFIG_SENSORS_IIO_HWMON=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_LM95245=y
@@ -686,6 +687,7 @@ CONFIG_USB_DWC2=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_HSIC_USB3503=m
CONFIG_AB8500_USB=y
CONFIG_KEYSTONE_USB_PHY=y
CONFIG_OMAP_USB3=y
--
2.9.3
^ permalink raw reply related
* [PATCHv2 net-next 15/16] net: mvpp2: add support for an additional clock needed for PPv2.2
From: Russell King - ARM Linux @ 2017-01-07 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-16-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:31PM +0100, Thomas Petazzoni wrote:
> The PPv2.2 variant of the network controller needs an additional
> clock, the "MG clock" in order for the IP block to operate
> properly. This commit adds support for this additional clock to the
> driver, reworking as needed the error handling path.
There's more clocks that are required.
Firstly, what I'm finding is that the MDIO block in the CP110 does not
work at all (locks the system up if accessed) if these clocks are not
enabled:
cpm_syscon0 1 9, cpm_syscon0 1 6, cpm_syscon0 1 5
The XMDIO block requires the same clocks to be functional. Since the
MDIO and XMDIO blocks are actually part of the ethernet controller,
it's not that surprising.
We can't rely on the ethernet controller having been probed, because
the 8k has two sets of MDIO buses - one set per CP110. It's entirely
possible that people will put all their PHYs for both CP110 instances
on one set of MDIO buses (eg, the master). Indeed, this is exactly
what SolidRun have done, and hence how I found the problem.
So, it looks to me like DT doesn't actually describe the hardware here -
especially when looking at the reg properties, they overlap with each
other.
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 25 +++++++++++++++++++++----
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 20e9429..194de00 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -702,6 +702,7 @@ struct mvpp2 {
> /* Common clocks */
> struct clk *pp_clk;
> struct clk *gop_clk;
> + struct clk *mg_clk;
>
> /* List of pointers to port structures */
> struct mvpp2_port **port_list;
> @@ -6899,6 +6900,18 @@ static int mvpp2_probe(struct platform_device *pdev)
> if (err < 0)
> goto err_pp_clk;
>
> + if (priv->hw_version == MVPP22) {
> + priv->mg_clk = devm_clk_get(&pdev->dev, "mg_clk");
> + if (IS_ERR(priv->mg_clk)) {
> + err = PTR_ERR(priv->mg_clk);
> + goto err_gop_clk;
> + }
> +
> + err = clk_prepare_enable(priv->mg_clk);
> + if (err < 0)
> + goto err_gop_clk;
> + }
> +
> /* Get system's tclk rate */
> priv->tclk = clk_get_rate(priv->pp_clk);
>
> @@ -6906,14 +6919,14 @@ static int mvpp2_probe(struct platform_device *pdev)
> err = mvpp2_init(pdev, priv);
> if (err < 0) {
> dev_err(&pdev->dev, "failed to initialize controller\n");
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> port_count = of_get_available_child_count(dn);
> if (port_count == 0) {
> dev_err(&pdev->dev, "no ports enabled\n");
> err = -ENODEV;
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> priv->port_list = devm_kcalloc(&pdev->dev, port_count,
> @@ -6921,19 +6934,22 @@ static int mvpp2_probe(struct platform_device *pdev)
> GFP_KERNEL);
> if (!priv->port_list) {
> err = -ENOMEM;
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> /* Initialize ports */
> for_each_available_child_of_node(dn, port_node) {
> err = mvpp2_port_probe(pdev, port_node, priv);
> if (err < 0)
> - goto err_gop_clk;
> + goto err_mg_clk;
> }
>
> platform_set_drvdata(pdev, priv);
> return 0;
>
> +err_mg_clk:
> + if (priv->hw_version == MVPP22)
> + clk_disable_unprepare(priv->mg_clk);
> err_gop_clk:
> clk_disable_unprepare(priv->gop_clk);
> err_pp_clk:
> @@ -6969,6 +6985,7 @@ static int mvpp2_remove(struct platform_device *pdev)
> aggr_txq->descs_phys);
> }
>
> + clk_disable_unprepare(priv->mg_clk);
> clk_disable_unprepare(priv->pp_clk);
> clk_disable_unprepare(priv->gop_clk);
>
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv2 net-next 01/16] dt-bindings: net: update Marvell PPv2 binding for PPv2.2 support
From: Russell King - ARM Linux @ 2017-01-07 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-2-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:17PM +0100, Thomas Petazzoni wrote:
> @@ -31,7 +43,7 @@ Optional properties (port):
> then fixed link is assumed, and the 'fixed-link' property is
> mandatory.
Not directly related to this patch, but this context is wrong. The
PP2 driver _requires_ a PHY. It doesn't support fixed-link in its
current form. I think the DT binding describes an expectation of
a future driver.
The side effect is that if trying to use a fixed-link on any port,
the ethernet driver fails to probe.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-12-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> @@ -6511,7 +6515,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,
> dev_err(&pdev->dev, "failed to init port %d\n", id);
> goto err_free_stats;
> }
> - mvpp2_port_power_up(port);
> +
> + if (priv->hw_version == MVPP21)
> + mvpp21_port_power_up(port);
This has the side effect that nothing clears the port reset bit in the
GMAC, which means there's no hope of the interface working - with the
reset bit set, the port is well and truely held in "link down" state.
In any case, the GMAC part is much the same as mvneta, and I think
that code should be shared rather than writing new versions of it.
There are some subtle differences between neta, pp2.1 and pp2.2, but
it's entirely doable (I have an implementation here as I wasn't going
to duplicate this code for my phylink conversion.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943592-12556-12-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> +#define MVPP22_SMI_MISC_CFG_REG 0x2a204
> +#define MVPP22_SMI_POLLING_EN BIT(10)
> +
...
> + if (priv->hw_version == MVPP21) {
> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + } else {
> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + val &= ~MVPP22_SMI_POLLING_EN;
> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + }
The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
register set, although the mvmdio driver does not access this register.
Shouldn't this be taken care of by the mvmdio driver?
Also, a point that I've noticed while reviewing this is the mvmdio
driver also accesses these registers:
#define MVMDIO_ERR_INT_CAUSE 0x007C
#define MVMDIO_ERR_INT_MASK 0x0080
in addition to the un-named register at offset 0. The driver writes
to these registers unconditionally when unbinding:
writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
However, the various bindings for the driver have:
arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-370-xp.dtsi- reg = <0x72004 0x4>;
arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
arch/arm/boot/dts/dove.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/dove.dtsi- #address-cells = <1>;
arch/arm/boot/dts/dove.dtsi- #size-cells = <0>;
arch/arm/boot/dts/dove.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/orion5x.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/orion5x.dtsi- #address-cells = <1>;
arch/arm/boot/dts/orion5x.dtsi- #size-cells = <0>;
arch/arm/boot/dts/orion5x.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/kirkwood.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/kirkwood.dtsi- #address-cells = <1>;
arch/arm/boot/dts/kirkwood.dtsi- #size-cells = <0>;
arch/arm/boot/dts/kirkwood.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;
So, for many of these, we're accessing registers outside of the given
binding, which sounds incorrect. I guess that write should be
conditional upon an interrupt being present.
The binding document says:
- reg: address and length of the SMI register
which is clearly wrong for those cases where the interrupt is used.
I also notice that the binding for CP110 uses a register size of 0x10
(even in your tree) - but I guess this should be 4.
I'm starting to wonder whether the orion-mdio driver really is a
separate chunk of hardware that warrants a separate description in
DT from the ethernet controller - it appears in all cases to be
embedded with an ethernet controller, sharing its register space
and at least some of the ethernet controllers clocks. That says
to me that it isn't an independent functional unit of hardware.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH RFC 0/4] Fix orion-mdio resource/interrupt issues indentified while reviewing mvpp2
From: Russell King - ARM Linux @ 2017-01-07 11:26 UTC (permalink / raw)
To: linux-arm-kernel
This patch series fixes some issues identified while reviewing the
mvpp2 driver changes recently posted by Thomas. I've left the clock
issue, and the question over whether this should be separate out of
this series, concentrating on the resource size / interrupt issue.
This series updates the binding to reflect reality, and ensures that
the driver will not try to access registers outside its binding. It
also ensures that it doesn't leave the interrupt enabled in hardware
on probe failure.
.../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
drivers/net/ethernet/marvell/mvmdio.c | 11 ++++++++++-
2 files changed, 25 insertions(+), 3 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH RFC 1/4] net: mvmdio: disable interrupts in driver failure path
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107112656.GL14217@n2100.armlinux.org.uk>
When the mvmdio driver has an interrupt, it enables the "done" interrupt
after requesting its interrupt handler. However, probe failure results
in the interrupt being left enabled. Disable it on the failure path.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvmdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index a0d1b084ecec..7aea0beca56e 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -251,6 +251,8 @@ static int orion_mdio_probe(struct platform_device *pdev)
return 0;
out_mdio:
+ if (dev->err_interrupt > 0)
+ writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
if (!IS_ERR(dev->clk))
clk_disable_unprepare(dev->clk);
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 2/4] net: mvmdio: fix interrupt disable in remove path
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107112656.GL14217@n2100.armlinux.org.uk>
The pre-existing write to disable interrupts on the remove path happens
whether we have an interrupt or not. While this may seem to be a good
idea, this driver is re-used in many different implementations, some
where the binding only specifies four bytes of register space. This
access causes us to access registers outside of the binding.
Make it conditional on the interrupt being present, which is the same
condition used when enabling the interrupt in the first place.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvmdio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 7aea0beca56e..6ea5caddca62 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -263,7 +263,8 @@ static int orion_mdio_remove(struct platform_device *pdev)
struct mii_bus *bus = platform_get_drvdata(pdev);
struct orion_mdio_dev *dev = bus->priv;
- writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
+ if (dev->err_interrupt > 0)
+ writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
mdiobus_unregister(bus);
if (!IS_ERR(dev->clk))
clk_disable_unprepare(dev->clk);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 3/4] dt-bindings: correct marvell orion MDIO binding document
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107112656.GL14217@n2100.armlinux.org.uk>
Correct the Marvell Orion MDIO binding document to properly reflect the
cases where an interrupt is present. Augment the examples to show this.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
.../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 9417e54c26c0..ca733ff68ab9 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -7,7 +7,10 @@ interface.
Required properties:
- compatible: "marvell,orion-mdio"
-- reg: address and length of the SMI register
+- reg: address and length of the MDIO registers. When an interrupt is
+ not present, the length is the size of the SMI register (4 bytes)
+ otherwise it must be 0x84 bytes to cover the interrupt control
+ registers.
Optional properties:
- interrupts: interrupt line number for the SMI error/done interrupt
@@ -17,7 +20,7 @@ The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
PHY address on the MDIO bus.
-Example at the SoC level:
+Example at the SoC level without an interrupt property:
mdio {
#address-cells = <1>;
@@ -26,6 +29,16 @@ mdio {
reg = <0xd0072004 0x4>;
};
+Example with an interrupt property:
+
+mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0xd0072004 0x84>;
+ interrupts = <30>;
+};
+
And at the board level:
mdio {
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 4/4] net: mvmdio: disable interrupt if resource size is too small
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107112656.GL14217@n2100.armlinux.org.uk>
Disable the MDIO interrupt, falling back to polled mode, if the resource
size does not allow us to access the interrupt registers. All current
DT bindings use a size of 0x84, which allows access, but verifying it is
good practice.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvmdio.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 6ea5caddca62..614dfde657fe 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -221,6 +221,12 @@ static int orion_mdio_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk);
dev->err_interrupt = platform_get_irq(pdev, 0);
+ if (dev->err_interrupt > 0 &&
+ resource_size(r) < MVMDIO_ERR_INT_MASK + 4) {
+ dev_err(&pdev->dev,
+ "disabling interrupt, resource size is too small\n");
+ dev->err_interrupt = 0;
+ }
if (dev->err_interrupt > 0) {
ret = devm_request_irq(&pdev->dev, dev->err_interrupt,
orion_mdio_err_irq,
--
2.7.4
^ permalink raw reply related
* [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Marcin Wojtas @ 2017-01-07 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107110351.GK14217@n2100.armlinux.org.uk>
Hi Russel,
2017-01-07 12:03 GMT+01:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
>> +#define MVPP22_SMI_MISC_CFG_REG 0x2a204
>> +#define MVPP22_SMI_POLLING_EN BIT(10)
>> +
> ...
>> + if (priv->hw_version == MVPP21) {
>> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
>> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + } else {
>> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + val &= ~MVPP22_SMI_POLLING_EN;
>> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + }
>
> The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
> register set, although the mvmdio driver does not access this register.
> Shouldn't this be taken care of by the mvmdio driver?
>
> Also, a point that I've noticed while reviewing this is the mvmdio
> driver also accesses these registers:
>
> #define MVMDIO_ERR_INT_CAUSE 0x007C
> #define MVMDIO_ERR_INT_MASK 0x0080
>
> in addition to the un-named register at offset 0. The driver writes
> to these registers unconditionally when unbinding:
>
> writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
>
> However, the various bindings for the driver have:
>
> arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-370-xp.dtsi- reg = <0x72004 0x4>;
> arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
> arch/arm/boot/dts/dove.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/dove.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/dove.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/dove.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/orion5x.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/orion5x.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/orion5x.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/orion5x.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/kirkwood.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/kirkwood.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/kirkwood.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/kirkwood.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;
>
> So, for many of these, we're accessing registers outside of the given
> binding, which sounds incorrect. I guess that write should be
> conditional upon an interrupt being present.
>
> The binding document says:
>
> - reg: address and length of the SMI register
>
> which is clearly wrong for those cases where the interrupt is used.
>
> I also notice that the binding for CP110 uses a register size of 0x10
> (even in your tree) - but I guess this should be 4.
>
> I'm starting to wonder whether the orion-mdio driver really is a
> separate chunk of hardware that warrants a separate description in
> DT from the ethernet controller - it appears in all cases to be
> embedded with an ethernet controller, sharing its register space
> and at least some of the ethernet controllers clocks. That says
> to me that it isn't an independent functional unit of hardware.
>
In fact there is common SMI bus, but each port has its own register
set to control it (it's true at least for Neta and PP2). There is also
an option to use HW polling - every 1s hardware checks PHY over SMI
and updates MAC registers of each port independently. I was able to
use those successfully in other implementations.
However we are supposed to use libphy in Linux and I'm afraid we have
to use single instance that controls single SMI bus - I think current
implementation is a compromise between HW and libphy demands.
Best regards,
Marcin
^ permalink raw reply
* [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Andi Shyti @ 2017-01-07 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH1QtbieMxQzoPvxsP_3tSYBSuXe+wtq0uUs03mhcLFdXg@mail.gmail.com>
Hi Chanwoo,
> >>> + touchkey at 20 {
> >>> + compatible = "samsung,tm2-touchkey";
> >>> + reg = <0x20>;
> >>> + interrupt-parent = <&gpa3>;
> >>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> >>> + vcc-supply = <&ldo32_reg>;
> >>> + vdd-supply = <&ldo33_reg>;
> >>> + };
> >>> +};
> >>> +
> >>> &ldo31_reg {
> >>> regulator-name = "TSP_VDD_1.85V_AP";
> >>> regulator-min-microvolt = <1850000>;
>
> I repiled the touchkey driver against compatible name.
> Usually, when developing the device driver, we use the specific h/w name
> but in this patch, the touckey dt node uses the h/w board name instead of
> original touckhey name.
this should be a device specifically done for the tm2 and we are
not sure who is the manufacturer of the device. In order to not
assign the device to the wrong manufacturer, we preferred calling
it Samsung as it is in a Samsung device.
Andi
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Xing Zheng @ 2017-01-07 13:05 UTC (permalink / raw)
To: linux-arm-kernel
The structure rockchip_clk_provider needs to refer the GRF regmap
in somewhere, if the CRU node has not "rockchip,grf" property,
calling syscon_regmap_lookup_by_phandle will return an invaild GRF
regmap, and the MUXGRF type clock will be not supported.
Therefore, we need to add them.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 92b731f..7790634 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1090,6 +1090,7 @@
pmucru: pmu-clock-controller at ff750000 {
compatible = "rockchip,rk3399-pmucru";
reg = <0x0 0xff750000 0x0 0x1000>;
+ rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks = <&pmucru PLL_PPLL>;
@@ -1099,6 +1100,7 @@
cru: clock-controller at ff760000 {
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff760000 0x0 0x1000>;
+ rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks =
--
2.7.4
^ permalink raw reply related
* imx: RS-485 problems during TX, maybe DMA related
From: Clemens Gruber @ 2017-01-07 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CywajwZEL8K2ATfS80WzqY69YVX+3S7hq9_HmNdNAwaw@mail.gmail.com>
Hi Fabio,
On Fri, Jan 06, 2017 at 10:31:16PM -0200, Fabio Estevam wrote:
> Yes, I have tried like this:
>
> &uart4 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart4>;
> uart-has-rtscts;
> status = "okay";
> };
>
> pinctrl_uart4: uart4grp {
> fsl,pins = <
> MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
> MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
> MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B 0x1b0b1
> >;
> };
I also mux RTS_B even though it is unused, not sure if it this makes a
difference to also add MX6QDL_PAD_CSI0_DAT17_UART4_RTS_B in your case?
It should work like this, I don't think using an extra GPIO is
necessary.
>
> So I was never able to observe the DE pin toggling correctly.
But did you set SER_RS485_RX_DURING_TX in your flags? This is counter
intuitive, but I observed that it would not work otherwise.
> Maybe you could share your userspace application with me offline?
I am using a patched version of the busybox stty utility, I posted the
patch here, feel free to use it:
https://gist.github.com/clemensg/29bd68b3cfd719bd01002a2acde9662c
I use stty -F /dev/ttymxc4 clocal cread -hupcl -ixon -opost rs485
-rs485rtsonsend rs485rtsaftersend rs485rxduringtx
But for you it is probably rs485rtsonsend and -rs485rtsaftersend?
Regards,
Clemens
^ permalink raw reply
* [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKeQ=fj2cKPyJ2NqCaAv55cOyWodujKwj3-v5iCrDYNcmA@mail.gmail.com>
On Sat, Jan 07, 2017 at 01:12:35PM +0100, Marcin Wojtas wrote:
> In fact there is common SMI bus, but each port has its own register
> set to control it (it's true at least for Neta and PP2). There is also
> an option to use HW polling - every 1s hardware checks PHY over SMI
> and updates MAC registers of each port independently. I was able to
> use those successfully in other implementations.
>
> However we are supposed to use libphy in Linux and I'm afraid we have
> to use single instance that controls single SMI bus - I think current
> implementation is a compromise between HW and libphy demands.
One of the "DT rules" is that DT only describes the hardware in an
implementation independent way. It should not describe a particular
implementation's view of the hardware.
"libphy demands" sounds very much like an implementation dictating
the DT description, which sounds to me very wrong and against the
goals and purposes of DT.
Anyway, I don't think it's too bad - a possible solution here would
be to have the existing MDIO driver as a library, which can be
instantiated by the Neta and PP2 drivers. This could be done in
DT (taking dove as an example) as:
eth: ethernet-ctrl at 72000 {
compatible = "marvell,orion-eth";
reg = <0x72000 0x4000>;
ranges = <0 0x72000 0 0x4000>;
...
mdio: mdio at 4 {
compatible = "marvell,orion-mdio";
reg = <4>;
...
... phys ...
};
};
I don't think that would require that big a change - and it could be
done in a way that compatibility with the existing DT descriptions is
maintained very cheaply.
Now, I'm not suggesting that mdio at 4 should be created by a platform
device via marking ethernet-ctrl at 72000 with "simple-bus", but it's
something that should be created by the ethernet driver if present.
The compatible string is there so we can identify that this is a
mdio node, and which type of mdio it is (the Armada 8k has this type
and a separate clause-45 xmdio implementation, and we need to
distinguish those.)
What that means is that we no longer have to worry about clocks and
overlapping register regions and the like, and can deal with the
ethernet driver wanting to access the SMI registers as well.
We would need the ethernet driver to be capable of instantiation even
with no ports enabled, so cases where the MDIO interface is used with
other ethernet controllers continues to be supportable (eg, the
Armada 8040 case where the slave CP110 ethernet controller is used
with PHYs connected to the master CP110 ethernet controller's MDIO
buses - which afaik aren't shared between the two CP110 dies.)
However, I'd like to see libphy become more flexible and support
hardware polled mode of operation, since libphy provides a nice
library of functions for accessing various phy features (like setting
the advertisment, EEE modes, flow control, etc.) Even with hardware
polling, we should still describe the PHY in DT, because PHY is part
of the hardware description, and we need to know where it is in order
to program these phy features.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 0/2] ARM: davinvi: da850 add ohci DT nodes
From: Sekhar Nori @ 2017-01-07 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106094054.27767-1-ahaslam@baylibre.com>
On Friday 06 January 2017 03:10 PM, Axel Haslam wrote:
> This adds the DT node for the ohci controller and
> enables it for the omapl138-lckd platform.
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* imx: RS-485 problems during TX, maybe DMA related
From: Fabio Estevam @ 2017-01-07 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107134557.GA12299@archie.localdomain>
Hi Clemens,
On Sat, Jan 7, 2017 at 11:45 AM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:
> It should work like this, I don't think using an extra GPIO is
> necessary.
The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
If I pass 'fsl,dte-mode' then I can see this pin toggling. (rx, tx
would not work as expected).
In the default dce mode I can see UART4_CTS_B pin toggling when I
monitor CSI0_DAT17 pin and configure it as:
MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B
,but unfortunately this pin does not go to the TXEN pin of the RS485
transceiver.
So this means that with the hardware I have access to my only
alternative is to set MX6QDL_PAD_CSI0_DAT16__GPIO6_IO02.
>> So I was never able to observe the DE pin toggling correctly.
>
> But did you set SER_RS485_RX_DURING_TX in your flags? This is counter
> intuitive, but I observed that it would not work otherwise.
Yes, I have also tried when I read your email, but did not help on my case.
Thanks,
Fabio Estevam
^ permalink raw reply
* [PATCH v4 0/2] make kurobox-pro be able to shutdown after device-tree migration
From: Roger Shimizu @ 2017-01-07 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227070611.14852-1-rogershimizu@gmail.com>
Dear Kernel Maintainers,
Kurobox-Pro (and variants) need more commands sending to UART1 to shutdown.
So here I make this patch series to let current qnap-poweroff implementation
be able to handle such case.
Here I give 3 patches, for 3 different kernel subsystems respectivelay:
- Patch 1/3: System reset/shutdown driver
- Patch 2/3: Open firmware and flattened device tree bindings
- Patch 3/3: ARM/Marvell Dove/MV78xx0/Orion SOC support
Ryan Tandy, the issue reporter, and I have already tested those changes on
Linkstation/KuroBoxPro devices, and confirmed it's working well.
Merry Xmax and look forward to your feedback!
Changes:
v0 => v1:
- Update 0003 to split kuroboxpro related code into kuroboxpro-common.c
v1 => v2:
- Split off linkstation/kuroboxpro related code to linkstation-reset.c
Because linkstation before kuroboxpro also need this driver to power
off properly. It's more proper to call it linkstation driver.
v2 => v3:
- Split off devicetree bindings doc into a separate patch.
- Add device-tree patch to make Linkstation LS-GL and KuroBox Pro to
use the newly created linkstation-reset driver.
- Remove the unused one-byte command sending case in linkstation-reset
driver.
v3 => v4:
- Reduce the global singleton variables by moving to structure, which makes
the driver easy to support reboot function in the future. Thanks to
Florian Fainelli.
- Simplify the power_off function registration. Thanks to Florian Fainelli.
- Drop DT binding doc.
Cheers,
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Roger Shimizu (2):
power: reset: add linkstation-reset driver
ARM: DT: add power-off support to linkstation lsgl and kuroboxpro
arch/arm/boot/dts/orion5x-kuroboxpro.dts | 8 +
arch/arm/boot/dts/orion5x-linkstation-lsgl.dts | 10 +
arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 4 +
arch/arm/boot/dts/orion5x-linkstation.dtsi | 4 -
drivers/power/reset/Kconfig | 10 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/linkstation-reset.c | 270 +++++++++++++++++++++++
7 files changed, 303 insertions(+), 4 deletions(-)
create mode 100644 drivers/power/reset/linkstation-reset.c
--
2.11.0
^ permalink raw reply
* [PATCH v4 1/2] power: reset: add linkstation-reset driver
From: Roger Shimizu @ 2017-01-07 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107150451.17912-1-rogershimizu@gmail.com>
Buffalo Linkstation / KuroBox and their variants need magic command
sending to UART1 to power-off.
Power driver linkstation-reset implements the magic command and I/O
routine, which come from files listed below:
- arch/arm/mach-orion5x/kurobox_pro-setup.c
- arch/arm/mach-orion5x/terastation_pro2-setup.c
To: Sebastian Reichel <sre@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Martin Michlmayr <tbm@cyrius.com>
Cc: Sylver Bruneau <sylver.bruneau@googlemail.com>
Cc: Herbert Valerio Riedel <hvr@gnu.org>
Cc: Ryan Tandy <ryan@nardis.ca>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-pm at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Reported-by: Ryan Tandy <ryan@nardis.ca>
Tested-by: Ryan Tandy <ryan@nardis.ca>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
---
drivers/power/reset/Kconfig | 10 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/linkstation-reset.c | 270 ++++++++++++++++++++++++++++++++
3 files changed, 281 insertions(+)
create mode 100644 drivers/power/reset/linkstation-reset.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index c74c3f67b8da..77c44cad7ece 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -98,6 +98,16 @@ config POWER_RESET_IMX
say N here or disable in dts to make sure pm_power_off never be
overwrote wrongly by this driver.
+config POWER_RESET_LINKSTATION
+ bool "Buffalo Linkstation and its variants reset driver"
+ depends on OF_GPIO && PLAT_ORION
+ help
+ This driver supports power off Buffalo Linkstation / KuroBox Pro
+ NAS and their variants by sending commands to the micro-controller
+ which controls the main power.
+
+ Say Y if you have a Buffalo Linkstation / KuroBox Pro NAS.
+
config POWER_RESET_MSM
bool "Qualcomm MSM power-off driver"
depends on ARCH_QCOM
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 1be307c7fc25..692ba6417cfb 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
+obj-$(CONFIG_POWER_RESET_LINKSTATION) += linkstation-reset.o
obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
diff --git a/drivers/power/reset/linkstation-reset.c b/drivers/power/reset/linkstation-reset.c
new file mode 100644
index 000000000000..c191b7671076
--- /dev/null
+++ b/drivers/power/reset/linkstation-reset.c
@@ -0,0 +1,270 @@
+/*
+ * Buffalo Linkstation power reset driver.
+ * It may also be used on following devices:
+ * - KuroBox Pro
+ * - Buffalo Linkstation Pro (LS-GL)
+ * - Buffalo Terastation Pro II/Live
+ * - Buffalo Linkstation Duo (LS-WTGL)
+ * - Buffalo Linkstation Mini (LS-WSGL)
+ *
+ * Copyright (C) 2016 Roger Shimizu <rogershimizu@gmail.com>
+ *
+ * Based on the code from:
+ *
+ * Copyright (C) 2012 Andrew Lunn <andrew@lunn.ch>
+ * Copyright (C) 2009 Martin Michlmayr <tbm@cyrius.com>
+ * Copyright (C) 2008 Byron Bradley <byron.bbradley@gmail.com>
+ * Copyright (C) 2008 Sylver Bruneau <sylver.bruneau@googlemail.com>
+ * Copyright (C) 2007 Herbert Valerio Riedel <hvr@gnu.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/serial_reg.h>
+#include <linux/kallsyms.h>
+#include <linux/of.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+
+#define UART1_REG(x) ((UART_##x) << 2)
+#define MICON_CMD_SIZE 4
+
+/* 4-byte magic hello command to UART1-attached microcontroller */
+static const unsigned char linkstation_micon_magic[] = {
+ 0x1b,
+ 0x00,
+ 0x07,
+ 0x00
+};
+
+/* for each row, first byte is the size of command */
+static const unsigned char linkstation_power_off_cmd[][MICON_CMD_SIZE] = {
+ { 3, 0x01, 0x35, 0x00},
+ { 2, 0x00, 0x0c},
+ { 2, 0x00, 0x06},
+ {}
+};
+
+struct reset_cfg {
+ u32 baud;
+ const unsigned char *magic;
+ const unsigned char (*cmd)[MICON_CMD_SIZE];
+};
+
+struct device_cfg {
+ const struct device *dev;
+ void __iomem *base;
+ unsigned long tclk;
+ const struct reset_cfg *cfg;
+};
+
+static const struct reset_cfg linkstation_power_off_cfg = {
+ .baud = 38400,
+ .magic = linkstation_micon_magic,
+ .cmd = linkstation_power_off_cmd,
+};
+
+static const struct of_device_id linkstation_reset_of_match_table[] = {
+ { .compatible = "linkstation,power-off",
+ .data = &linkstation_power_off_cfg,
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, linkstation_reset_of_match_table);
+
+static int uart1_micon_read(const struct device_cfg *dev, unsigned char *buf, int count)
+{
+ int i;
+ int timeout;
+
+ for (i = 0; i < count; i++) {
+ timeout = 10;
+
+ while (!(readl(dev->base + UART1_REG(LSR)) & UART_LSR_DR)) {
+ if (--timeout == 0)
+ break;
+ udelay(1000);
+ }
+
+ if (timeout == 0)
+ break;
+ buf[i] = readl(dev->base + UART1_REG(RX));
+ }
+
+ /* return read bytes */
+ return i;
+}
+
+static int uart1_micon_write(const struct device_cfg *dev, const unsigned char *buf, int count)
+{
+ int i = 0;
+
+ while (count--) {
+ while (!(readl(dev->base + UART1_REG(LSR)) & UART_LSR_THRE))
+ barrier();
+ writel(buf[i++], dev->base + UART1_REG(TX));
+ }
+
+ return 0;
+}
+
+int uart1_micon_send(const struct device_cfg *dev, const unsigned char *data, int count)
+{
+ int i;
+ unsigned char checksum = 0;
+ unsigned char recv_buf[40];
+ unsigned char send_buf[40];
+ unsigned char correct_ack[3];
+ int retry = 2;
+
+ /* Generate checksum */
+ for (i = 0; i < count; i++)
+ checksum -= data[i];
+
+ do {
+ /* Send data */
+ uart1_micon_write(dev, data, count);
+
+ /* send checksum */
+ uart1_micon_write(dev, &checksum, 1);
+
+ if (uart1_micon_read(dev, recv_buf, sizeof(recv_buf)) <= 3) {
+ dev_err(dev->dev, ">%s: receive failed.\n", __func__);
+
+ /* send preamble to clear the receive buffer */
+ memset(&send_buf, 0xff, sizeof(send_buf));
+ uart1_micon_write(dev, send_buf, sizeof(send_buf));
+
+ /* make dummy reads */
+ mdelay(100);
+ uart1_micon_read(dev, recv_buf, sizeof(recv_buf));
+ } else {
+ /* Generate expected ack */
+ correct_ack[0] = 0x01;
+ correct_ack[1] = data[1];
+ correct_ack[2] = 0x00;
+
+ /* checksum Check */
+ if ((recv_buf[0] + recv_buf[1] + recv_buf[2] +
+ recv_buf[3]) & 0xFF) {
+ dev_err(dev->dev, ">%s: Checksum Error : "
+ "Received data[%02x, %02x, %02x, %02x]"
+ "\n", __func__, recv_buf[0],
+ recv_buf[1], recv_buf[2], recv_buf[3]);
+ } else {
+ /* Check Received Data */
+ if (correct_ack[0] == recv_buf[0] &&
+ correct_ack[1] == recv_buf[1] &&
+ correct_ack[2] == recv_buf[2]) {
+ /* Interval for next command */
+ mdelay(10);
+
+ /* Receive ACK */
+ return 0;
+ }
+ }
+ /* Received NAK or illegal Data */
+ dev_err(dev->dev, ">%s: Error : NAK or Illegal Data "
+ "Received\n", __func__);
+ }
+ } while (retry--);
+
+ /* Interval for next command */
+ mdelay(10);
+
+ return -1;
+}
+
+static struct device_cfg reset;
+
+static void linkstation_reset(void)
+{
+ const unsigned divisor = ((reset.tclk + (8 * reset.cfg->baud)) / (16 * reset.cfg->baud));
+ int i;
+
+ pr_err("%s: triggering power-off...\n", __func__);
+
+ /* hijack UART1 and reset into sane state */
+ writel(0x83, reset.base + UART1_REG(LCR));
+ writel(divisor & 0xff, reset.base + UART1_REG(DLL));
+ writel((divisor >> 8) & 0xff, reset.base + UART1_REG(DLM));
+ writel(reset.cfg->magic[0], reset.base + UART1_REG(LCR));
+ writel(reset.cfg->magic[1], reset.base + UART1_REG(IER));
+ writel(reset.cfg->magic[2], reset.base + UART1_REG(FCR));
+ writel(reset.cfg->magic[3], reset.base + UART1_REG(MCR));
+
+ /* send the power-off command to PIC */
+ for(i = 0; reset.cfg->cmd[i][0] > 0; i ++) {
+ /* [0] is size of the command; command starts from [1] */
+ uart1_micon_send(&reset, &(reset.cfg->cmd[i][1]), reset.cfg->cmd[i][0]);
+ }
+}
+
+static int linkstation_reset_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct resource *res;
+ struct clk *clk;
+
+ const struct of_device_id *match =
+ of_match_node(linkstation_reset_of_match_table, np);
+ reset.cfg = match->data;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Missing resource");
+ return -EINVAL;
+ }
+
+ reset.dev = &pdev->dev;
+ reset.base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (!reset.base) {
+ dev_err(reset.dev, "Unable to map resource");
+ return -EINVAL;
+ }
+
+ /* We need to know tclk in order to calculate the UART divisor */
+ clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(reset.dev, "Clk missing");
+ return PTR_ERR(clk);
+ }
+
+ reset.tclk = clk_get_rate(clk);
+
+ /* Check that nothing else has already setup a handler */
+ if (!pm_power_off) {
+ pm_power_off = linkstation_reset;
+ }
+
+ return 0;
+}
+
+static int linkstation_reset_remove(struct platform_device *pdev)
+{
+ if (pm_power_off == linkstation_reset)
+ pm_power_off = NULL;
+ return 0;
+}
+
+static struct platform_driver linkstation_reset_driver = {
+ .probe = linkstation_reset_probe,
+ .remove = linkstation_reset_remove,
+ .driver = {
+ .name = "linkstation_reset",
+ .of_match_table = of_match_ptr(linkstation_reset_of_match_table),
+ },
+};
+
+module_platform_driver(linkstation_reset_driver);
+
+MODULE_AUTHOR("Roger Shimizu <rogershimizu@gmail.com>");
+MODULE_DESCRIPTION("Linkstation Reset driver");
+MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [PATCH v4 2/2] ARM: DT: add power-off support to linkstation lsgl and kuroboxpro
From: Roger Shimizu @ 2017-01-07 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170107150451.17912-1-rogershimizu@gmail.com>
A few models of Linkstation / KuroBox has micro-controller which
controls the power (as well as FAN, but not related here), while
others not. So remove the restart-poweroff driver in linkstation
common dtsi file, and specify the proper power driver in dts
of each device.
Devices need micro-controler to power-off:
- Linkstation LS-GL
- KuroBox Pro
Device continues using original restart-poweroff driver:
- Linkstation LS-WTGL
To: Jason Cooper <jason@lakedaemon.net>
To: Andrew Lunn <andrew@lunn.ch>
To: Gregory Clement <gregory.clement@free-electrons.com>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Ryan Tandy <ryan@nardis.ca>
Cc: linux-pm at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Reported-by: Ryan Tandy <ryan@nardis.ca>
Tested-by: Ryan Tandy <ryan@nardis.ca>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
---
arch/arm/boot/dts/orion5x-kuroboxpro.dts | 8 ++++++++
arch/arm/boot/dts/orion5x-linkstation-lsgl.dts | 10 ++++++++++
arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 4 ++++
arch/arm/boot/dts/orion5x-linkstation.dtsi | 4 ----
4 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/orion5x-kuroboxpro.dts b/arch/arm/boot/dts/orion5x-kuroboxpro.dts
index 1a672b098d0b..aba38d802bda 100644
--- a/arch/arm/boot/dts/orion5x-kuroboxpro.dts
+++ b/arch/arm/boot/dts/orion5x-kuroboxpro.dts
@@ -60,6 +60,14 @@
<MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
<MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>,
<MBUS_ID(0x01, 0x1e) 0 0xfc000000 0x1000000>;
+
+ internal-regs {
+ power_off {
+ compatible = "linkstation,power-off";
+ reg = <0x12100 0x100>;
+ clocks = <&core_clk 0>;
+ };
+ };
};
memory { /* 128 MB */
diff --git a/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
index 51dc734cd5b9..370fc17a6dd9 100644
--- a/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
+++ b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
@@ -56,6 +56,16 @@
model = "Buffalo Linkstation Pro/Live";
compatible = "buffalo,lsgl", "marvell,orion5x-88f5182", "marvell,orion5x";
+ soc {
+ internal-regs {
+ power_off {
+ compatible = "linkstation,power-off";
+ reg = <0x12100 0x100>;
+ clocks = <&core_clk 0>;
+ };
+ };
+ };
+
memory { /* 128 MB */
device_type = "memory";
reg = <0x00000000 0x8000000>;
diff --git a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
index 0eead400f427..571a71f5b7ad 100644
--- a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
+++ b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
@@ -59,6 +59,10 @@
reg = <0x00000000 0x4000000>;
};
+ restart_poweroff {
+ compatible = "restart-poweroff";
+ };
+
gpio_keys {
power-on-switch {
gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm/boot/dts/orion5x-linkstation.dtsi b/arch/arm/boot/dts/orion5x-linkstation.dtsi
index ed456ab35fd8..40770a8d4b36 100644
--- a/arch/arm/boot/dts/orion5x-linkstation.dtsi
+++ b/arch/arm/boot/dts/orion5x-linkstation.dtsi
@@ -57,10 +57,6 @@
<MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>;
};
- restart_poweroff {
- compatible = "restart-poweroff";
- };
-
regulators {
compatible = "simple-bus";
#address-cells = <1>;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] crypto: picoxcell - Cleanups removing non-DT code
From: Jamie Iles @ 2017-01-07 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483376819-26726-1-git-send-email-javier@osg.samsung.com>
Hi Javier,
On Mon, Jan 02, 2017 at 02:06:56PM -0300, Javier Martinez Canillas wrote:
> Hello,
>
> This small series contains a couple of cleanups that removes some driver's code
> that isn't needed due the driver being for a DT-only platform.
>
> The changes were suggested by Arnd Bergmann as a response to a previous patch:
> https://lkml.org/lkml/2017/1/2/342
>
> Patch #1 allows the driver to be built when the COMPILE_TEST option is enabled.
> Patch #2 removes the platform ID table since isn't needed for DT-only drivers.
> Patch #3 removes a wrapper function that's also not needed if driver is DT-only.
>
> Best regards,
>
>
> Javier Martinez Canillas (3):
> crypto: picoxcell - Allow driver to build COMPILE_TEST is enabled
> crypto: picoxcell - Remove platform device ID table
> crypto: picoxcell - Remove spacc_is_compatible() wrapper function
>
> drivers/crypto/Kconfig | 2 +-
> drivers/crypto/picoxcell_crypto.c | 28 +++-------------------------
> 2 files changed, 4 insertions(+), 26 deletions(-)
Acked-by: Jamie Iles <jamie@jamieiles.com>
Thanks,
Jamie
^ permalink raw reply
* imx: RS-485 problems during TX, maybe DMA related
From: Clemens Gruber @ 2017-01-07 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5ALSQj3C6Yn-avMZdzTvtWCZPQ5+pNdzYi03G-GZB_t+w@mail.gmail.com>
Hi Fabio,
On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
Ah, the input select is limited in that way, I see.
You wrote that you tried rts-gpios.
What about setting cts-gpios to gpio6 2 in the DT?
Or can you remux RX and TX to be switched to work in dte mode?
Regards,
Clemens
^ 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