* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Arnd Bergmann @ 2016-09-23 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15d69a29-6997-6af8-f121-ff253388626c@arm.com>
On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
> On 23/09/16 15:01, Stuart Yoder wrote:
> Otherwise you can
> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
> need to trap and translate subsequent SMC calls for e.g. PSCI).
>
> > If there is such a requirement, it's something begging for standardization.
> > Doesn't make sense for multiple divergent approaches for switching from
> > aarch64/EL2 to aarch32/EL2.
>
> Perhaps - I did briefly look into how hard it would be to write a proper
> SMC service handler to do this (since ATF does have a framework for such
> things), but concluded it would be more than 10 minutes' work and just
> cheated instead. It's certainly something which could be raised with the
> firmware folks.
If we end up allowing all arm64 platforms to be enabled in arch/arm,
we could perhaps create a generic implementation that does both of
those things, i.e.
- Take the arm32 kernel Image or zImage file, wrap it inside of a binary
that implements the arm64 boot protocol.
- When that starts up, try to use the new PSCI call to jump into
the arm32 kernel
- If PSCI failed and we are running in EL2, implement the shim
and start the arm32 kernel in EL1 mode
Arnd
^ permalink raw reply
* [PATCH v6 2/4] arm64: dts: Add timer erratum property for LS2080A and LS1043A
From: Marc Zyngier @ 2016-09-23 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-2-git-send-email-oss@buserror.net>
With a commit message along the lines of:
Both the LS1043A and LS2080A platforms are affected by the Freescale
A008585 erratum. Advertise it in their respective device trees.
On 22/09/16 09:35, Scott Wood wrote:
> Signed-off-by: Scott Wood <oss@buserror.net>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index e669fbd..952531d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -123,6 +123,7 @@
> <1 14 0x1>, /* Physical Non-Secure PPI */
> <1 11 0x1>, /* Virtual PPI */
> <1 10 0x1>; /* Hypervisor PPI */
> + fsl,erratum-a008585;
> };
>
> pmu {
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 21023a3..9d3ac19 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -195,6 +195,7 @@
> <1 14 0x8>, /* Physical Non-Secure PPI, active-low */
> <1 11 0x8>, /* Virtual PPI, active-low */
> <1 10 0x8>; /* Hypervisor PPI, active-low */
> + fsl,erratum-a008585;
> };
>
> pmu {
>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6] KVM: arm/arm64: Route vtimer events to user space
From: Paolo Bonzini @ 2016-09-23 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923124048.GI9101@cbox>
On 23/09/2016 14:40, Christoffer Dall wrote:
> On Fri, Sep 23, 2016 at 02:11:41PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 23/09/2016 13:07, Alexander Graf wrote:
>>> + timer_ret = kvm_timer_sync_hwstate(vcpu);
>>>
>>> kvm_vgic_sync_hwstate(vcpu);
>>>
>>> preempt_enable();
>>>
>>> ret = handle_exit(vcpu, run, ret);
>>> +
>>> + if ((ret == 1) && timer_ret) {
>>> + /*
>>> + * We have to exit straight away to ensure that we only
>>> + * ever notify user space once about a level change
>>> + */
>>
>> Is this really a requirement? It complicates the logic noticeably.
>>
>
> If we skip this, then we have to somehow remember that the sync may have
> updated the line level when we reach the flush state (and didn't exit),
> and I would like maintaining that state even less than doing this check.
>
> What we could do is to compare the timer->irq.level with the kvm_run
> state outside of the run loop (on the way to userspace) and update the
> kvm_run state if there's a discrepancy. That way, we can maintain the
> 'timer->irq.level != kvm_run' means, we have to exit, and whenever we
> are exiting, we are reporting the most recent state to user space
> anyway.
>
> Would that work?
It seems clearer at least.
> (By the way, the check should be via a call into the arch timer code,
> kvm_timer_update_user_state() or something like that).
Makes sense.
Paolo
> Also, the comment above is confusing, because that's not why this check
> is here, the check is here so that we don't loose track of the timer
> output level change if there's no exit to userspace.
>
> Thanks,
> -Christoffer
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v6 1/4] arm64: arch_timer: Add device tree binding for A-008585 erratum
From: Marc Zyngier @ 2016-09-23 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-1-git-send-email-oss@buserror.net>
On 22/09/16 09:35, Scott Wood wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward. So, describe it
> in the device tree.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 07/11] pci: controller: designware: Add EP mode support
From: Rob Herring @ 2016-09-23 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473829927-20466-8-git-send-email-kishon@ti.com>
On Wed, Sep 14, 2016 at 10:42:03AM +0530, Kishon Vijay Abraham I wrote:
> Add endpoint mode support to designware driver. This uses the
> EP Core layer introduced recently to add endpoint mode support.
> *Any* function driver can now use this designware device
> to achieve the EP functionality.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> .../devicetree/bindings/pci/designware-pcie.txt | 26 ++-
> drivers/pci/controller/Kconfig | 5 +
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-designware-ep.c | 228 ++++++++++++++++++++
> drivers/pci/controller/pcie-designware.c | 30 +++
> drivers/pci/controller/pcie-designware.h | 45 ++++
> 6 files changed, 324 insertions(+), 11 deletions(-)
> create mode 100644 drivers/pci/controller/pcie-designware-ep.c
>
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index 6c5322c..bb0b789 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -6,23 +6,27 @@ Required properties:
> - reg-names: Must be "config" for the PCIe configuration space.
> (The old way of getting the configuration address space from "ranges"
> is deprecated and should be avoided.)
> -- #address-cells: set to <3>
> -- #size-cells: set to <2>
> -- device_type: set to "pci"
> -- ranges: ranges for the PCI memory and I/O regions
> -- #interrupt-cells: set to <1>
> -- interrupt-map-mask and interrupt-map: standard PCI properties
> - to define the mapping of the PCIe interface to interrupt
> +- #address-cells (only for host mode): set to <3>
> +- #size-cells (only for host mode): set to <2>
> +- device_type (only for host mode): set to "pci"
> +- ranges (only for host mode): ranges for the PCI memory and I/O regions
> +- num-ib-windows (only for EP mode): number of inbound address translation
> + windows
> +- num-ob-windows (only for EP mode): number of outbound address translation
> + windows
> +- #interrupt-cells (only for host mode): set to <1>
> +- interrupt-map-mask and interrupt-map (only for host mode): standard PCI
> + properties to define the mapping of the PCIe interface to interrupt
It may be clearer to just document EP mode in a separate section even if
there's some duplication of properties. Other standard PCI binding
properties probably also don't apply.
Rob
^ permalink raw reply
* [PATCH v6 4/4] arm/arm64: arch_timer: Use archdata to indicate vdso suitability
From: Marc Zyngier @ 2016-09-23 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-4-git-send-email-oss@buserror.net>
On 22/09/16 09:35, Scott Wood wrote:
> Instead of comparing the name to a magic string, use archdata to
> explicitly communicate whether the arch timer is suitable for
> direct vdso access.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/clocksource.h | 8 ++++++++
> arch/arm/kernel/vdso.c | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/clocksource.h | 8 ++++++++
> arch/arm64/kernel/vdso.c | 2 +-
> drivers/clocksource/arm_arch_timer.c | 11 +++--------
> 7 files changed, 23 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm/include/asm/clocksource.h
> create mode 100644 arch/arm64/include/asm/clocksource.h
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Rob Herring @ 2016-09-23 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147384330268.13546.17843140335600627152@sboyd-linaro>
On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> Quoting Stephen Boyd (2016-09-13 18:42:46)
> > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > board to mux the D+/D- lines from the SoC between a micro usb
> > "device" port and a USB hub for "host" roles. Upon a role switch,
> > we need to change this mux to forward the D+/D- lines to either
> > the port or the hub. Therefore, introduce a driver for this
> > device that intercepts extcon USB_HOST events and logically
> > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > attached. When the cable goes away, it will logically deassert
> > the gpio and mux the "device" lines.
> >
> > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> >
> > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > Cc: <devicetree@vger.kernel.org>
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > ---
> >
> > Should I make the extcon part optional? I could see a case where there are two
> > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > software may want to mux between them at runtime. If we mandate an extcon,
> > that won't be possible to support. Perhaps it would be better to have
> > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > endpoints would be useful too) so that when the controller wants to mux over
> > a port it can do so.
I've mentioned my opinion on extcon before. The first clue that it needs
work is a Linux subsystem name is used for the binding.
> Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> haven't written any code around it, but the idea is to allow the binding
> to specify how the mux is connected to upstream and downstream D+/D-
> lines. This way, we can do some dt parsing of the endpoints and their
> parent nodes to figure out if the mux needs to be set high or low to use
> a device connector or a usb hub based on if the id cable is present.
> Maybe I'm over thinking things though and we could just have a DT
> property for that.
I think the connector nodes are on the right track, but of-graph doesn't
work here because we already have a way to describe USB buses in DT.
Following that, would something like this work for you? The vbus-supply
and id-gpios are just examples and may not always be there like if the
hub controls each port's vbus directly.
usb-controller at 1234 {
usb-switch at 0 {
compatible = "toshiba,tc7usb40mu";
hub at 0 {
compatible = "some-hub";
port at 0 {
compatible = "usb-A-connector"
vbus-supply = ...;
};
port at 1 {
compatible = "usb-A-connector"
vbus-supply = ...;
};
};
connector at 1 {
compatible = "usb-ub-connector";
vbus-supply = ...;
id-gpios = <>;
};
};
};
Rob
^ permalink raw reply
* [PATCH v6 4/4] arm/arm64: arch_timer: Use archdata to indicate vdso suitability
From: Russell King - ARM Linux @ 2016-09-23 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-4-git-send-email-oss@buserror.net>
It helps to add the appropriate people to your email if you want to get
a change into the kernel. Will has had to point this message out to me.
On Thu, Sep 22, 2016 at 03:35:18AM -0500, Scott Wood wrote:
> Instead of comparing the name to a magic string, use archdata to
> explicitly communicate whether the arch timer is suitable for
> direct vdso access.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/clocksource.h | 8 ++++++++
> arch/arm/kernel/vdso.c | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/clocksource.h | 8 ++++++++
> arch/arm64/kernel/vdso.c | 2 +-
> drivers/clocksource/arm_arch_timer.c | 11 +++--------
> 7 files changed, 23 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm/include/asm/clocksource.h
> create mode 100644 arch/arm64/include/asm/clocksource.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a9c4e48..b2113c2 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1,6 +1,7 @@
> config ARM
> bool
> default y
> + select ARCH_CLOCKSOURCE_DATA
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> diff --git a/arch/arm/include/asm/clocksource.h b/arch/arm/include/asm/clocksource.h
> new file mode 100644
> index 0000000..0b350a7
> --- /dev/null
> +++ b/arch/arm/include/asm/clocksource.h
> @@ -0,0 +1,8 @@
> +#ifndef _ASM_CLOCKSOURCE_H
> +#define _ASM_CLOCKSOURCE_H
> +
> +struct arch_clocksource_data {
> + bool vdso_direct; /* Usable for direct VDSO access? */
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 994e971..a0affd1 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
> if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
> return false;
>
> - if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
> + if (!tk->tkr_mono.clock->archdata.vdso_direct)
> return false;
>
> return true;
For the ARM bits:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
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 2/2] net: qcom/emac: initial ACPI support
From: Timur Tabi @ 2016-09-23 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474640854-1698-1-git-send-email-timur@codeaurora.org>
Add support for reading addresses, interrupts, and _DSD properties
from ACPI tables, just like with device tree. The HID for the
EMAC device itself is QCOM8070. The internal PHY is represented
by a child node with a HID of QCOM8071.
The EMAC also has some complex clock initialization requirements
that are not represented by this patch. This will be addressed
in a future patch.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 39 +++++++++++---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 72 ++++++++++++++++++-------
drivers/net/ethernet/qualcomm/emac/emac.c | 60 ++++++++++++++++++++-
3 files changed, 143 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index c412ba9..7c7c3bb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -19,6 +19,7 @@
#include <linux/of_mdio.h>
#include <linux/phy.h>
#include <linux/iopoll.h>
+#include <linux/acpi.h>
#include "emac.h"
#include "emac-mac.h"
#include "emac-phy.h"
@@ -163,11 +164,10 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
return ret;
}
-/* Configure the MDIO bus and connect the external PHY */
+/* Read phy configuration and initialize it */
int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
- struct device_node *phy_np;
struct mii_bus *mii_bus;
int ret;
@@ -183,14 +183,37 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
mii_bus->parent = &pdev->dev;
mii_bus->priv = adpt;
- ret = of_mdiobus_register(mii_bus, np);
- if (ret) {
- dev_err(&pdev->dev, "could not register mdio bus\n");
- return ret;
+ if (has_acpi_companion(&pdev->dev)) {
+ u32 phy_addr;
+
+ ret = mdiobus_register(mii_bus);
+ if (ret) {
+ dev_err(&pdev->dev, "could not register mdio bus\n");
+ return ret;
+ }
+ ret = device_property_read_u32(&pdev->dev, "phy-channel",
+ &phy_addr);
+ if (ret)
+ /* If we can't read a valid phy address, then assume
+ * that there is only one phy on this mdio bus.
+ */
+ adpt->phydev = phy_find_first(mii_bus);
+ else
+ adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
+
+ } else {
+ struct device_node *phy_np;
+
+ ret = of_mdiobus_register(mii_bus, np);
+ if (ret) {
+ dev_err(&pdev->dev, "could not register mdio bus\n");
+ return ret;
+ }
+
+ phy_np = of_parse_phandle(np, "phy-handle", 0);
+ adpt->phydev = of_phy_find_device(phy_np);
}
- phy_np = of_parse_phandle(np, "phy-handle", 0);
- adpt->phydev = of_phy_find_device(phy_np);
if (!adpt->phydev) {
dev_err(&pdev->dev, "could not find external phy\n");
mdiobus_unregister(mii_bus);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 2a095fb..8b3e6c3 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -14,6 +14,7 @@
*/
#include <linux/iopoll.h>
+#include <linux/acpi.h>
#include <linux/of_device.h>
#include "emac.h"
#include "emac-mac.h"
@@ -662,6 +663,24 @@ void emac_sgmii_reset(struct emac_adapter *adpt)
clk_set_rate(adpt->clk[EMAC_CLK_HIGH_SPEED], 125000000);
}
+static int emac_sgmii_acpi_match(struct device *dev, void *data)
+{
+ static const struct acpi_device_id match_table[] = {
+ {
+ .id = "QCOM8071",
+ .driver_data = (kernel_ulong_t)emac_sgmii_init_v2,
+ },
+ {}
+ };
+ const struct acpi_device_id *id = acpi_match_device(match_table, dev);
+ emac_sgmii_initialize *initialize = data;
+
+ if (id)
+ *initialize = (emac_sgmii_initialize)id->driver_data;
+
+ return !!id;
+}
+
static const struct of_device_id emac_sgmii_dt_match[] = {
{
.compatible = "qcom,fsm9900-emac-sgmii",
@@ -679,30 +698,45 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
struct platform_device *sgmii_pdev = NULL;
struct emac_phy *phy = &adpt->phy;
struct resource *res;
- const struct of_device_id *match;
- struct device_node *np;
int ret;
- np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
- if (!np) {
- dev_err(&pdev->dev, "missing internal-phy property\n");
- return -ENODEV;
- }
+ if (has_acpi_companion(&pdev->dev)) {
+ struct device *dev;
- sgmii_pdev = of_find_device_by_node(np);
- if (!sgmii_pdev) {
- dev_err(&pdev->dev, "invalid internal-phy property\n");
- return -ENODEV;
- }
+ dev = device_find_child(&pdev->dev, &phy->initialize,
+ emac_sgmii_acpi_match);
- match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
- if (!match) {
- dev_err(&pdev->dev, "unrecognized internal phy node\n");
- ret = -ENODEV;
- goto error_put_device;
- }
+ if (!dev) {
+ dev_err(&pdev->dev, "cannot find internal phy node\n");
+ return -ENODEV;
+ }
- phy->initialize = (emac_sgmii_initialize)match->data;
+ sgmii_pdev = to_platform_device(dev);
+ } else {
+ const struct of_device_id *match;
+ struct device_node *np;
+
+ np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
+ if (!np) {
+ dev_err(&pdev->dev, "missing internal-phy property\n");
+ return -ENODEV;
+ }
+
+ sgmii_pdev = of_find_device_by_node(np);
+ if (!sgmii_pdev) {
+ dev_err(&pdev->dev, "invalid internal-phy property\n");
+ return -ENODEV;
+ }
+
+ match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
+ if (!match) {
+ dev_err(&pdev->dev, "unrecognized internal phy node\n");
+ ret = -ENODEV;
+ goto error_put_device;
+ }
+
+ phy->initialize = (emac_sgmii_initialize)match->data;
+ }
/* Base address is the first address */
res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 429b4cb..4cde237 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -22,6 +22,7 @@
#include <linux/of_device.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
+#include <linux/acpi.h>
#include "emac.h"
#include "emac-mac.h"
#include "emac-phy.h"
@@ -570,6 +571,49 @@ static int emac_probe_resources(struct platform_device *pdev,
return 0;
}
+/* Get the resources */
+static int emac_probe_acpi_resources(struct platform_device *pdev,
+ struct emac_adapter *adpt)
+{
+ struct net_device *netdev = adpt->netdev;
+ struct resource *res;
+ char maddr[ETH_ALEN];
+ int ret = 0;
+
+ /* get mac address */
+
+ ret = device_property_read_u8_array(&pdev->dev, "mac-address",
+ maddr, ETH_ALEN);
+ if (ret)
+ eth_hw_addr_random(netdev);
+ else
+ ether_addr_copy(netdev->dev_addr, maddr);
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "error: missing irq resource (error=%i)\n", ret);
+ return ret;
+ }
+ adpt->irq.irq = ret;
+
+ /* get base register addresses */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ adpt->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(adpt->base))
+ return PTR_ERR(adpt->base);
+
+ /* get CSR register addresses */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ adpt->csr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(adpt->csr))
+ return PTR_ERR(adpt->csr);
+
+ netdev->base_addr = (unsigned long)adpt->base;
+
+ return 0;
+}
+
static const struct of_device_id emac_dt_match[] = {
{
.compatible = "qcom,fsm9900-emac",
@@ -577,6 +621,16 @@ static const struct of_device_id emac_dt_match[] = {
{}
};
+#if IS_ENABLED(CONFIG_ACPI)
+static const struct acpi_device_id emac_acpi_match[] = {
+ {
+ .id = "QCOM8070",
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, emac_acpi_match);
+#endif
+
static int emac_probe(struct platform_device *pdev)
{
struct net_device *netdev;
@@ -620,7 +674,10 @@ static int emac_probe(struct platform_device *pdev)
adpt->irq.mask = RX_PKT_INT0 | IMR_NORMAL_MASK;
- ret = emac_probe_resources(pdev, adpt);
+ if (has_acpi_companion(&pdev->dev))
+ ret = emac_probe_acpi_resources(pdev, adpt);
+ else
+ ret = emac_probe_resources(pdev, adpt);
if (ret)
goto err_undo_netdev;
@@ -736,6 +793,7 @@ static struct platform_driver emac_platform_driver = {
.driver = {
.name = "qcom-emac",
.of_match_table = emac_dt_match,
+ .acpi_match_table = ACPI_PTR(emac_acpi_match),
},
};
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 1/2] net: qcom/emac: do not use devm on internal phy pdev
From: Timur Tabi @ 2016-09-23 14:27 UTC (permalink / raw)
To: linux-arm-kernel
The platform_device returned by of_find_device_by_node() is not
automatically released when the driver unprobes. Therefore,
managed calls like devm_ioremap_resource() should not be used.
Instead, we manually allocate the resources and then free them
on driver release.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 42 +++++++++++++++++++------
drivers/net/ethernet/qualcomm/emac/emac.c | 4 +++
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 9a9a963..2a095fb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -681,6 +681,7 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
struct resource *res;
const struct of_device_id *match;
struct device_node *np;
+ int ret;
np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
if (!np) {
@@ -697,26 +698,49 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
if (!match) {
dev_err(&pdev->dev, "unrecognized internal phy node\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto error_put_device;
}
phy->initialize = (emac_sgmii_initialize)match->data;
/* Base address is the first address */
res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 0);
- phy->base = devm_ioremap_resource(&sgmii_pdev->dev, res);
- if (IS_ERR(phy->base))
- return PTR_ERR(phy->base);
+ phy->base = ioremap(res->start, resource_size(res));
+ if (IS_ERR(phy->base)) {
+ ret = PTR_ERR(phy->base);
+ goto error_put_device;
+ }
/* v2 SGMII has a per-lane digital digital, so parse it if it exists */
res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 1);
if (res) {
- phy->digital = devm_ioremap_resource(&sgmii_pdev->dev, res);
- if (IS_ERR(phy->base))
- return PTR_ERR(phy->base);
-
+ phy->digital = ioremap(res->start, resource_size(res));
+ if (IS_ERR(phy->digital)) {
+ ret = PTR_ERR(phy->digital);
+ goto error_unmap_base;
+ }
}
- return phy->initialize(adpt);
+ ret = phy->initialize(adpt);
+ if (ret)
+ goto error;
+
+ /* We've remapped the addresses, so we don't need the device any
+ * more. of_find_device_by_node() says we should release it.
+ */
+ put_device(&sgmii_pdev->dev);
+
+ return 0;
+
+error:
+ if (phy->digital)
+ iounmap(phy->digital);
+error_unmap_base:
+ iounmap(phy->base);
+error_put_device:
+ put_device(&sgmii_pdev->dev);
+
+ return ret;
}
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index e47d387..429b4cb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -723,6 +723,10 @@ static int emac_remove(struct platform_device *pdev)
mdiobus_unregister(adpt->mii_bus);
free_netdev(netdev);
+ if (adpt->phy.digital)
+ iounmap(adpt->phy.digital);
+ iounmap(adpt->phy.base);
+
return 0;
}
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Tony Lindgren @ 2016-09-23 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b8a49cd-ca7b-4580-58ba-3e05d933853e@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 03:20]:
> On 09/23/16 10:20, Peter Ujfalusi wrote:
> > On 09/22/16 21:07, Tony Lindgren wrote:
> >> Hi,
> >>
> >> Looks like commit 7a17e47f6403 ("mfd: twl6040: The chip does not
> >> support bulk access") breaks at least omap4-duovero.
> >
> > That's odd. I see no such errors on omap4 PandaBoard-ES nor on omap5 uEVM.
> > The IRQ status is one register so even in bulk access it is one read. So the
> > use_single_rw should have no effect on the access.
> >
> > The only time when regmap would try to use bulk access to twl6040 is when we
> > execute regcache_sync() on it after resuming the chip and this would fail at
> > the first time when it tries to restore more than one consecutive registers.
> >
> > I just tested things on next-20160915 and I see no errors at all.
>
> Retested on next-20160923 and I see no issue on Panda-ES or omap5-uevm.
>
> My guess is that you receive an interrupt from twl6040 while the chip is
> powered down, the regmap is set to cache only. But this has nothing to do with
> the bulk or non bulk access... Looking at the commit logs and git blame I see
> no recent change in the driver(s) for twl6040 which changed the way it loads
> and/or powers up/down.
OK yeah this is another one caused by "softirq: fix tasklet_kill() and
its users".
Thanks,
Tony
^ permalink raw reply
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Tony Lindgren @ 2016-09-23 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <139a8c7b-8cfe-fa21-634a-4551511f0cea@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 00:21]:
> On 09/22/16 21:07, Tony Lindgren wrote:
> > Hi,
> >
> > Looks like commit 7a17e47f6403 ("mfd: twl6040: The chip does not
> > support bulk access") breaks at least omap4-duovero.
>
> That's odd. I see no such errors on omap4 PandaBoard-ES nor on omap5 uEVM.
> The IRQ status is one register so even in bulk access it is one read. So the
> use_single_rw should have no effect on the access.
Oh it's just one register.
> The only time when regmap would try to use bulk access to twl6040 is when we
> execute regcache_sync() on it after resuming the chip and this would fail at
> the first time when it tries to restore more than one consecutive registers.
>
> I just tested things on next-20160915 and I see no errors at all.
OK interesting.
> > I now get tons of errors:
> >
> > Skipping twl internal clock init and using bootloader value (unknown osc rate)
> > twl 0-0048: PIH (irq 332) nested IRQs
> > of_get_named_gpiod_flags: parsed 'ti,audpwron-gpio' property of node '/ocp/i2c at 48070000/t
> > wl at 4b[0]' - status (0)
> > omap_i2c 48070000.i2c: bus 0 rev0.10 at 400 kHz
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> >
> > It seems the regmap irqs don't work with use_single_rw?
So obviously that's a wrong conclusion then.
> > Also seems that twl6040 does support bulk access as things have been
> > working earlier?
>
> Things kind of worked as we had single register reads and writes, but when I
> tried to power down/up the twl6040 the regcache_sync() would fail to restore
> the registers at the first place when we had two or more registers to update
> in bulk mode. In that case regmap gives an error, but I have not been checking
> the return of the regcache_sync() so the chip comes up, but not all settings
> were restored.
>
> > Anyways, can you please revert?
>
> Please don't.
>
> On which linux-next version you are seeing this?
This was with next-20160922. But testing it again this is just another
regression caused by "softirq: fix tasklet_kill() and its users", so adding
Santosh to Cc.
So no need to revert $subject patch.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Robin Murphy @ 2016-09-23 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB26384246128D6043B93E6E9F8DC80@VI1PR0401MB2638.eurprd04.prod.outlook.com>
On 23/09/16 15:01, Stuart Yoder wrote:
>
>
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>> Sent: Friday, September 23, 2016 8:19 AM
>> To: Stuart Yoder <stuart.yoder@nxp.com>; Alison Wang <b18965@freescale.com>; shawnguo at kernel.org;
>> kernel at pengutronix.de; Fabio Estevam Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-
>> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Leo Li
>> <leoyang.li@nxp.com>
>> Cc: Jason Jin <jason.jin@nxp.com>
>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>
>> On 23/09/16 14:13, Stuart Yoder wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>>>> Sent: Friday, September 23, 2016 7:17 AM
>>>> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
>>>> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
>>>> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>>>> <leoyang.li@nxp.com>
>>>> Cc: Jason Jin <jason.jin@nxp.com>
>>>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>>>
>>>> Hi Alison,
>>>>
>>>> On 23/09/16 03:19, Alison Wang wrote:
>>>>> The ARMv8 architecture supports:
>>>>> 1. 64-bit execution state, AArch64.
>>>>> 2. 32-bit execution state, AArch32, that is compatible with previous
>>>>> versions of the ARM architecture.
>>>>>
>>>>> LayerScape platforms are compliant with ARMv8 architecture. This patch
>>>>> is to support running 32-bit Linux kernel for LayerScape platforms.
>>>>>
>>>>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>>>>>
>>>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>>>> ---
>>>>> arch/arm/Kconfig | 9 +++++++++
>>>>> arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
>>>>> arch/arm/mach-imx/Makefile | 4 +++-
>>>>> arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>>>>> 4 files changed, 49 insertions(+), 1 deletion(-)
>>>>> create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>>>>>
>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>>> index f0c8068..e8d470e 100644
>>>>> --- a/arch/arm/Kconfig
>>>>> +++ b/arch/arm/Kconfig
>>>>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>>>>> default 3 if ARM_LPAE
>>>>> default 2
>>>>>
>>>>> +config ARCH_AARCH32_ES_SUPPORT
>>>>> + def_bool n
>>>>> + help
>>>>> + The ARMv8 architecture supports 64-bit execution state, AArch64
>>>>> + and 32-bit execution state, AArch32, that is compatible with
>>>>> + previous versions of the ARM architecture.
>>>>> +
>>>>> + Enable AArch32 execution state support for ARMv8 architecture.
>>>>
>>>> What's this supposed to do, exactly? I've been running 32-bit kernels on
>>>> my Juno with very little issue (beyond a couple of DT tweaks, and some
>>>> firmware hacks with a corresponding bit of A64 assembly tacked on the
>>>> front of the zImage to switch into AArch32 state).
>>>
>>> Which arch/arm/mach-* platform are you using for Juno?
>>
>> I don't even know! :) I just start with a multi_v7_defconfig plus a few
>> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
>> combination of mach-vexpress and mach-virt.
>
> Thanks. A question about the switch into aarch32 state... our assumption
> was that the kernel starts at EL2. In this proof of concept we're doing the
> switch to aarch32/EL2 in firmware. And what I'm being told is that the
> firmware aarch64 EL2 code cannot switch to aarch32 EL2 without some
> assistance from EL3 firmware. This is leading us to invent a new
> SMC call to do this.
>
> Did you face this?
Yes, the only way to enter in Hyp is to have the firmware twiddle
SCR_EL3.RW (I simply stuck a disgusting hack directly in ATF's exception
handler, which my dodgy 64-bit header then calls). Otherwise you can
always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
need to trap and translate subsequent SMC calls for e.g. PSCI).
> If there is such a requirement, it's something begging for standardization.
> Doesn't make sense for multiple divergent approaches for switching from
> aarch64/EL2 to aarch32/EL2.
Perhaps - I did briefly look into how hard it would be to write a proper
SMC service handler to do this (since ATF does have a framework for such
things), but concluded it would be more than 10 minutes' work and just
cheated instead. It's certainly something which could be raised with the
firmware folks.
Robin.
>
> Thanks,
> Stuart
>
^ permalink raw reply
* [GIT PULL] few minor fixes for omap dts files for v4.9 merge window
From: Arnd Bergmann @ 2016-09-23 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921224907.l2nxg5ynw3rxztlm@atomide.com>
On Wednesday, September 21, 2016 3:49:08 PM CEST Tony Lindgren wrote:
> Few fixes for omap dts files for v4.9 merge window. Let's also add
> the tilcdc quirks:
>
> - Fix typo with recent beagleboard-x15 changes for mmc2_pins_default
>
> - Add am335x blue-and-red-wiring quirk as specified in the binding in
> Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt. Also
> fix up the whitespace formatting for am335x-evmsk.
>
> - Fix for recent igepv5 power button for GPIO_ACTIVE_LOW. Also fix
> up the whitespace formatting for the button
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Nicolas Ferre @ 2016-09-23 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c90099af-2537-cc41-2775-dd2ca41dc070@atmel.com>
Le 16/09/2016 ? 10:36, Nicolas Ferre a ?crit :
> Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
>> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
>> atmel_usba_udc fails with:
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
>> ecm_do_notify+0x188/0x1a0
>> Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
>> Hardware name: Atmel SAMA5
>> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
>> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
>> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
>> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
>> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
>> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
>> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
>> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
>> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
>> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
>> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
>> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
>> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
>> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
>> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
>> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
>> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
>> ---[ end trace e7cf9dcebf4815a6 ]---
>>
>> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
>> Reported-by: Richard Genoud <richard.genoud@gmail.com>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Felipe, Greg,
> It is clearly a regression and material for 4.8-fixes. But I do know
> that we are very late in the process :-(
> Please do what you can to make it progress before 4.8-final but I'm
> truly aware of the challenge.
Any chance that we can have it (aka ping)?
Bye,
> Thanks to Richard for finding this and Alexandre for the quick correction.
>
> Bye,
>
>> ---
>> drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> index bb1f6c8f0f01..45bc997d0711 100644
>> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> @@ -1978,7 +1978,7 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
>> dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
>> goto err;
>> }
>> - ep->ep.name = name;
>> + ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
>>
>> ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
>> ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
>>
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support
From: Steffen Trumtrar @ 2016-09-23 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160712193645.9098-7-atull@opensource.altera.com>
Hi!
Alan Tull writes:
> Supports Altera SOCFPGA bridges:
> * fpga2sdram
> * fpga2hps
> * hps2fpga
> * lwhps2fpga
>
> Allows enabling/disabling the bridges through the FPGA
> Bridge Framework API functions.
>
> The fpga2sdram driver only supports enabling and disabling
> of the ports that been configured early on. This is due to
> a hardware limitation where the read, write, and command
> ports on the fpga2sdram bridge can only be reconfigured
> while there are no transactions to the sdram, i.e. when
> running out of OCRAM before the kernel boots.
>
> Device tree property 'init-val' configures the driver to
> enable or disable the bridge during probe. If the property
> does not exist, the driver will leave the bridge in its
> current state.
>
> Signed-off-by: Alan Tull <atull@opensource.altera.com>
> Signed-off-by: Matthew Gerlach <mgerlach@altera.com>
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
(...)
> +static inline int _alt_fpga2sdram_enable_set(struct alt_fpga2sdram_data *priv,
> + bool enable)
> +{
> + return regmap_update_bits(priv->sdrctl, ALT_SDR_CTL_FPGAPORTRST_OFST,
> + priv->mask, enable ? priv->mask : 0);
> +}
(...)
> + /* Get f2s bridge configuration saved in handoff register */
> + regmap_read(sysmgr, SYSMGR_ISWGRP_HANDOFF3, &priv->mask);
> +
Could you maybe add some documentation about this implicit information
shared between a bootloader and this driver?
I understand why you do this, but there must be a better way than
depending on something some bootloader wrote in some undocumented
register, no?
The documentation just says:
"These registers are used to store handoff infomation between the
preloader and the OS. These 8 registers can be used to store any
information. The contents of these registers have no impact on the
state of the HPS hardware"
If it is already agreed upon, that a bridge-enable property is okay,
why not add a port-enable property, too?
Regards,
Steffen Trumtrar
--
Pengutronix e.K. | Steffen Trumtrar |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Linus Walleij @ 2016-09-23 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mviy92qw.fsf@eliezer.anholt.net>
On Fri, Sep 23, 2016 at 3:15 PM, Eric Anholt <eric@anholt.net> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>> Maybe it should be named GPIO_RPI_FXL6408 ?
>>
>> (No strong opinion.)
>
> See DT binding comment -- I think since this driver has no dependency on
> being to the 6408 on the pi3, we shouldn't needlessly bind it to the
> FXL6408. (the help comment was just context for why you would want the
> driver today).
OK
>>> +static int rpi_gpio_dir_in(struct gpio_chip *gc, unsigned off)
>>> +{
>>> + /* We don't have direction control. */
>>> + return -EINVAL;
>>> +}
>>> +
>>> +static int rpi_gpio_dir_out(struct gpio_chip *gc, unsigned off, int val)
>>> +{
>>> + /* We don't have direction control. */
>>> + return -EINVAL;
>>> +}
>>
>> IMO this should return OK if you try to set it to the direction
>> that the line is hardwired for in that case, not just fail everything.
>>
>> If you return errors here, any generic driver that tries to
>> set the line as input or output will fail and then require a
>> second workaround in that driver if it is used on rpi etc etc.
>>
>> Try to return zero if the consumer asks for the direction that
>> the line is set to.
>>
>> Also implement .get_direction(). Doing so will show how to
>> do the above two calls in the right way.
>
> I was worried about the lack of direction support. The firmware
> interface doesn't give me anything for direction, and a get or set
> of the value doesn't try to set direction.
>
> I can try to bother them to give me support for that, but if they
> cooperate on that it means that users will only get HDMI detection once
> they update firmware.
>
> The alternative to new firmware interface would be to provide a bunch of
> DT saying which of these should be in/out at boot time and refuse to
> change them after that. That seems like a mess, though.
It has to be resolved one way or another I'm afraid.
Do you have an API in place to ask for the firmware version?
RPI_FIRMWARE_GET_FIRMWARE_REVISION seems to
exist at least?
In that case try to make some compromise, e.g. if lines 0 and 1
are output and the rest input in a certain firmware version:
struct rpi_gpio {
(...)
u8 dirs;
};
if (fw_version <= a)
rpi->dirs = 0x03;
else if (fw_version > a && fw_version <= b)
rpi->dirs = 0x07;
else
/* Ask firmware */
Then in e.g.
static int rpi_gpio_dir_in(struct gpio_chip *gc, unsigned off)
{
struct rpi_gpio *rpi = gpiochip_get_data(gc);
if (!(rpi->dirs & BIT(off)))
return 0;
return -EINVAL;
}
I think this should be managed by code in the driver like this
and not by any DT properties. I suspect also the ngpio number
is better to determine from looking at the fw version number.
>> Use devm_gpiochip_add_data() and pass NULL as data
>> so you can still use the devm* function.
>
> Oh, nice.
I forgot this: with devm_gpiochip_add_data() pass struct rpi_gpio *
as data then you can just:
static void rpi_gpio_set(struct gpio_chip *gc, unsigned off, int val)
{
- struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
+ struct rpi_gpio *rpi = gpiochip_get_data(gc);
Applies everywhere.
>>> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
>>> index 3fb357193f09..671ccd00aea2 100644
>>> --- a/include/soc/bcm2835/raspberrypi-firmware.h
>>> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
>>> @@ -73,11 +73,13 @@ enum rpi_firmware_property_tag {
>>> RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
>>> RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
>>> RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
>>> + RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
>>> RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
>>> RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
>>> RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
>>> RPI_FIRMWARE_SET_TURBO = 0x00038009,
>>> RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
>>> + RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
>>
>> Can you please merge this orthogonally into the rpi tree to ARM SoC?
>
> This driver would appear in the rpi downstream tree once we settle the
> driver here. Or are you asking me to delay this series until I can get
> them to pull just a patch extending the set of packets?
Sorry I am not familiar with your development model. I don't know
about any RPI downstream tree... What I mean is that the patch to
include/soc/bcm2835/raspberrypi-firmware.h should be merged by
whoever is maintaining that file, it is not a GPIO file.
If I get an ACK from the maintainer I can take it into the GPIO
tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it
From: Tomeu Vizoso @ 2016-09-23 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474639600-30090-1-git-send-email-tomeu.vizoso@collabora.com>
There's no point in enabling PSR when the panel doesn't support it.
This also avoids a problem when PSR gets enabled when a CRTC is being
disabled, because sometimes in that situation the DSP_HOLD_VALID_INTR
interrupt on which we wait will never arrive. This was observed on
RK3288 with a panel without PSR (veyron-jaq Chromebook).
It's very easy to reproduce by running the kms_rmfb test in IGT a few
times.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Yakir Yang <ykk@rock-chips.com>
Cc: Archit Taneja <architt@codeaurora.org>
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e83be157cc2a..8548e8271639 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -85,6 +85,9 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
struct rockchip_dp_device *dp = to_dp(encoder);
unsigned long flags;
+ if (!analogix_dp_psr_supported(dp->dev))
+ return;
+
dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
spin_lock_irqsave(&dp->psr_lock, flags);
--
2.7.4
^ permalink raw reply related
* [1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Olliver Schinagl @ 2016-09-23 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2LwWShNEUmNNbuH_4GY90gSpVmrxbC+oLK4p51cxUe2g@mail.gmail.com>
Hey Jonathan,
On 23-09-16 16:02, Jonathan Liu wrote:
> On 26 August 2016 at 03:50, <oliver@schinagl.nl> wrote:
>> When we inform the PWM block to stop toggeling the output, we may end up
>> in a state where the output is not what we would expect (e.g. not the
>> low-pulse) but whatever the output was at when the clock got disabled.
>>
>> To counter this we have to wait for maximally the time of one whole
>> period to ensure the pwm hardware was able to finish. Since we already
>> told the PWM hardware to disable it self, it will not continue toggling
>> but merly finish its current pulse.
>>
>> If a whole period is considered to much, it may be contemplated to use a
>> half period + a little bit to ensure we get passed the transition.
>>
>> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
>> ---
>> drivers/pwm/pwm-sun4i.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
>> index 03a99a5..5e97c8a 100644
>> --- a/drivers/pwm/pwm-sun4i.c
>> +++ b/drivers/pwm/pwm-sun4i.c
>> @@ -8,6 +8,7 @@
>>
>> #include <linux/bitops.h>
>> #include <linux/clk.h>
>> +#include <linux/delay.h>
>> #include <linux/err.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
>> spin_lock(&sun4i_pwm->ctrl_lock);
>> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>> val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
>> + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
>> + spin_unlock(&sun4i_pwm->ctrl_lock);
>> +
>> + /* Allow for the PWM hardware to finish its last toggle. The pulse
>> + * may have just started and thus we should wait a full period.
>> + */
>> + ndelay(pwm_get_period(pwm));
>> +
>> + spin_lock(&sun4i_pwm->ctrl_lock);
>> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>> val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
>> sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
>> spin_unlock(&sun4i_pwm->ctrl_lock);
> I had some issues where setting the brightness for pwm-backlight to 0
> was not turning off the backlight sometimes.
> This patch fixes the issue for me. Thanks.
You are welcome, but there's some work still being done in this regard,
or rather, i have to find time to grab a scope and properly check the
output. So expect the proper fix to be coming to a kernel near you soon :)
Meanwhile, it seems to still confirm that this is needed. Thanks on that.
Olliver
>
> Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Lorenzo Pieralisi @ 2016-09-23 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923130907.4187-1-lorenzo.pieralisi@arm.com>
On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
> Current vexpress smp init code detects whether to override the
> default smp ops with MCPM smp ops by matching the "cci-400"
> compatible string, in that MCPM requires control over CCI ports
> to manage low-power states entry/exit.
>
> The "cci-400" compatible string check is a necessary but not
> sufficient condition for MCPM to work, because the cci-400
> can be made visible to the kernel, but firmware can nonetheless
> disable non-secure CCI ports control, while still allowing PMU
> access; if booted in non-secure world, the kernel would still
> blindly override smp operations with MCPM operations, resulting
> in kernel faults when the CCI ports programming interface is
> accessed from non-secure world.
>
> This means that the "cci-400" compatible string check would
> result in a false positive in systems that eg boot in HYP mode,
> where CCI ports non-secure access is explicitly not allowed,
> and it is reported in the respective device tree nodes with
> CCI ports marked as disabled.
>
> Refactor the smp operations initialization to make sure that
> the kernel is actually allowed to take control over CCI ports
> (by enabling MCPM smp operations) before overriding default
> vexpress smp operations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index 8b8d072..6cfd782 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -26,17 +26,34 @@
> bool __init vexpress_smp_init_ops(void)
> {
> #ifdef CONFIG_MCPM
> + int cpu;
> + struct device_node *cpu_node, *cci_node;
> +
> /*
> - * The best way to detect a multi-cluster configuration at the moment
> - * is to look for the presence of a CCI in the system.
> + * The best way to detect a multi-cluster configuration
> + * is to detect if the kernel can take over CCI ports
> + * control. Loop over possible CPUs and check if CCI
> + * port control is available.
> * Override the default vexpress_smp_ops if so.
> */
> - struct device_node *node;
> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
> - if (node && of_device_is_available(node)) {
> - mcpm_smp_set_ops();
> - return true;
> + for_each_possible_cpu(cpu) {
> + bool available;
> +
> + cpu_node = of_get_cpu_node(cpu, NULL);
> + if (WARN(!cpu_node, "Missing cpu device node!"))
> + return false;
> +
> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
> + available = cci_node && of_device_is_available(cci_node);
> + of_node_put(cci_node);
> + of_node_put(cpu_node);
> +
> + if (!available)
> + return false;
> }
> +
> + mcpm_smp_set_ops();
> + return true;
> #endif
> return false;
For the records, while moving the code around I missed I was ending
up with this idiotic double return, I have already reworked the patch
and will squash changes in the final version if we agree on the bulk of
the code.
Lorenzo
^ permalink raw reply
* [1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Jonathan Liu @ 2016-09-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472147411-30424-2-git-send-email-oliver@schinagl.nl>
On 26 August 2016 at 03:50, <oliver@schinagl.nl> wrote:
> When we inform the PWM block to stop toggeling the output, we may end up
> in a state where the output is not what we would expect (e.g. not the
> low-pulse) but whatever the output was at when the clock got disabled.
>
> To counter this we have to wait for maximally the time of one whole
> period to ensure the pwm hardware was able to finish. Since we already
> told the PWM hardware to disable it self, it will not continue toggling
> but merly finish its current pulse.
>
> If a whole period is considered to much, it may be contemplated to use a
> half period + a little bit to ensure we get passed the transition.
>
> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
> ---
> drivers/pwm/pwm-sun4i.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..5e97c8a 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -8,6 +8,7 @@
>
> #include <linux/bitops.h>
> #include <linux/clk.h>
> +#include <linux/delay.h>
> #include <linux/err.h>
> #include <linux/io.h>
> #include <linux/module.h>
> @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> spin_lock(&sun4i_pwm->ctrl_lock);
> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> + spin_unlock(&sun4i_pwm->ctrl_lock);
> +
> + /* Allow for the PWM hardware to finish its last toggle. The pulse
> + * may have just started and thus we should wait a full period.
> + */
> + ndelay(pwm_get_period(pwm));
> +
> + spin_lock(&sun4i_pwm->ctrl_lock);
> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> spin_unlock(&sun4i_pwm->ctrl_lock);
I had some issues where setting the brightness for pwm-backlight to 0
was not turning off the backlight sometimes.
This patch fixes the issue for me. Thanks.
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Stuart Yoder @ 2016-09-23 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6697a9c-013b-9880-e52f-8de2f0a5b7ae@arm.com>
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Friday, September 23, 2016 8:19 AM
> To: Stuart Yoder <stuart.yoder@nxp.com>; Alison Wang <b18965@freescale.com>; shawnguo at kernel.org;
> kernel at pengutronix.de; Fabio Estevam Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Jason Jin <jason.jin@nxp.com>
> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>
> On 23/09/16 14:13, Stuart Yoder wrote:
> >
> >
> >> -----Original Message-----
> >> From: Robin Murphy [mailto:robin.murphy at arm.com]
> >> Sent: Friday, September 23, 2016 7:17 AM
> >> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> >> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
> >> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
> >> <leoyang.li@nxp.com>
> >> Cc: Jason Jin <jason.jin@nxp.com>
> >> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
> >>
> >> Hi Alison,
> >>
> >> On 23/09/16 03:19, Alison Wang wrote:
> >>> The ARMv8 architecture supports:
> >>> 1. 64-bit execution state, AArch64.
> >>> 2. 32-bit execution state, AArch32, that is compatible with previous
> >>> versions of the ARM architecture.
> >>>
> >>> LayerScape platforms are compliant with ARMv8 architecture. This patch
> >>> is to support running 32-bit Linux kernel for LayerScape platforms.
> >>>
> >>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
> >>>
> >>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> >>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> >>> ---
> >>> arch/arm/Kconfig | 9 +++++++++
> >>> arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
> >>> arch/arm/mach-imx/Makefile | 4 +++-
> >>> arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
> >>> 4 files changed, 49 insertions(+), 1 deletion(-)
> >>> create mode 100644 arch/arm/mach-imx/mach-layerscape.c
> >>>
> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>> index f0c8068..e8d470e 100644
> >>> --- a/arch/arm/Kconfig
> >>> +++ b/arch/arm/Kconfig
> >>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
> >>> default 3 if ARM_LPAE
> >>> default 2
> >>>
> >>> +config ARCH_AARCH32_ES_SUPPORT
> >>> + def_bool n
> >>> + help
> >>> + The ARMv8 architecture supports 64-bit execution state, AArch64
> >>> + and 32-bit execution state, AArch32, that is compatible with
> >>> + previous versions of the ARM architecture.
> >>> +
> >>> + Enable AArch32 execution state support for ARMv8 architecture.
> >>
> >> What's this supposed to do, exactly? I've been running 32-bit kernels on
> >> my Juno with very little issue (beyond a couple of DT tweaks, and some
> >> firmware hacks with a corresponding bit of A64 assembly tacked on the
> >> front of the zImage to switch into AArch32 state).
> >
> > Which arch/arm/mach-* platform are you using for Juno?
>
> I don't even know! :) I just start with a multi_v7_defconfig plus a few
> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
> combination of mach-vexpress and mach-virt.
Thanks. A question about the switch into aarch32 state... our assumption
was that the kernel starts at EL2. In this proof of concept we're doing the
switch to aarch32/EL2 in firmware. And what I'm being told is that the
firmware aarch64 EL2 code cannot switch to aarch32 EL2 without some
assistance from EL3 firmware. This is leading us to invent a new
SMC call to do this.
Did you face this?
If there is such a requirement, it's something begging for standardization.
Doesn't make sense for multiple divergent approaches for switching from
aarch64/EL2 to aarch32/EL2.
Thanks,
Stuart
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Linus Walleij @ 2016-09-23 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ponu931e.fsf@eliezer.anholt.net>
On Fri, Sep 23, 2016 at 3:08 PM, Eric Anholt <eric@anholt.net> wrote:
> Sort of related: I also worry that we have races with the firmware for
> the platform GPIO bits, since both ARM and firmware are doing RMWs (or,
> even worse, maybe just Ws?) of the registers controlled by the pinctrl
> driver. Hopefully I can get the firmware to pass control of devices
> like this over to Linux, with firmware making requests to us, but I
> don't know if that will happen and we may need to access other GPIOs
> using this interface :(
For the race with firmware I have no good solutions, it's just one of
those things I guess :(
When two kernel drivers compete about registers, say for example
one driver needs to RMW bits 0-5 and another driver needs to
RMW bits 7-11, the right solution is usually to use syscon
and then regmap-mmio will deal with the concurrency as part
of regmap_update_bits() etc.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/3] musb: sunxi: Remove custom babble handling
From: Bin Liu @ 2016-09-23 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db52a0d4-74f1-4f47-eb67-bcfbd66f174f@redhat.com>
On Fri, Sep 23, 2016 at 04:42:26PM +0300, Hans de Goede wrote:
> Hi,
>
> On 09/22/2016 05:30 PM, Bin Liu wrote:
> >Hi,
> >
> >On Thu, Sep 22, 2016 at 05:03:39PM +0300, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 09/22/2016 04:54 PM, Bin Liu wrote:
> >>>Hi,
> >>>
> >>>On Thu, Sep 22, 2016 at 02:19:00PM +0300, Hans de Goede wrote:
> >>>>The musb-core now a days always treats babble errors in host mode
> >>>
> >>>I don't think this statement is accurate. You might want to change it to
> >>>"The musb core already handles babble interrupt" or something else.
> >>
> >>It is accurate if you look in the history at drivers/usb/musb
> >>commits around 15-03-10 you will see 2 relevant commits:
> >>
> >>https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/musb?id=b4dc38fd45b63e3da2bc98db5d283a15a637a2fa
> >>
> >>"usb: musb: core: simplify musb_recover_work()"
> >>
> >>This commits introduces calling musb_root_disconnect(musb)
> >>on babble errors, that was not happening before which is why
> >
> >That is true, but calling musb_root_disconnect() is just one step of the
> >recovery in musb core, not all.
> >
> >The statement of "treats babble errors in host mode as disconnects"
> >implies all the babble handling is just disconnect, which is not
> >accurate.
>
> Ok, I'll send out a v3 with an improved commit msg.
Thanks.
If Kishon gives his Acked-by, I will take all the 3 patches. Or
I can just take the 2 musb patches into my tree.
Regards,
-Bin.
^ permalink raw reply
* [PATCH v3 2/2] ARM64: dts: meson-gxbb: add MMC support
From: Rob Herring @ 2016-09-23 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914004314.682-3-khilman@baylibre.com>
On Tue, Sep 13, 2016 at 05:43:14PM -0700, Kevin Hilman wrote:
> Add binding and basic support for the SD/eMMC controller on Amlogic
> S905/GXBB devices.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> .../devicetree/bindings/mmc/amlogic,meson-gxbb.txt | 29 ++++++++
> .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 87 ++++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 78 +++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 37 ++++++++-
> 4 files changed, 230 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
Some nits below, otherwise:
Acked-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
> new file mode 100644
> index 000000000000..39cbe528b7de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
> @@ -0,0 +1,29 @@
> +Amlogic SD / eMMC controller for S905/GXBB family SoCs
> +
> +The MMC 5.1 compliant host controller on Amlogic provides the
> +interface for SD, eMMC and SDIO devices.
> +
> +This file documents the properties in addition to those available in
> +the MMC core bindings, documented by mmc.txt.
> +
> +Required properties:
> +- compatible : contains "amlogic,meson-gxbb-mmc"
> +- clocks : A list of phandle + clock-specifier pairs for the clocks listed in clock-names.
> +- clock-names: Should contain the following:
> + "core" - Main peripheral bus clock
> + "clkin0" - Parent clock of internal mux
> + "clkin1" - Other parent clock of internal mux
> + The driver has an interal mux clock which switches between clkin0 and clkin1 depending on the
> + clock rate requested by the MMC core.
> +
> +Example:
> +
> + sd_emmc_a: mmc at 70000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x70000 0x0 0x2000>;
> + interrupts = < GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_A>, <&xtal>, <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + pinctrl-0 = <&emmc_pins>;
> + };
> +
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 90a84c514d3d..2a9303e7fab8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -73,6 +73,56 @@
> default-state = "off";
> };
> };
> +
> + tflash_vdd: regulator-tflash_vdd {
Use '-' not '_' in node names.
> + /*
> + * signal name from schematics: TFLASH_VDD_EN
> + */
> + compatible = "regulator-fixed";
> +
> + regulator-name = "TFLASH_VDD";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&gpio_ao GPIOAO_12 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + tf_io: gpio-regulator-tf_io {
ditto
> + compatible = "regulator-gpio";
> +
> + regulator-name = "TF_IO";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + /*
> + * signal name from schematics: TF_3V3N_1V8_EN
> + */
> + gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
> + gpios-states = <0>;
> +
> + states = <3300000 0
> + 1800000 1>;
> + };
> +
> + vcc1v8: regulator-vcc1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + vcc3v3: regulator-vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> };
>
> &uart_AO {
> @@ -87,3 +137,40 @@
> pinctrl-names = "default";
> };
>
> +/* SD */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <100000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> +
> + vmmc-supply = <&tflash_vdd>;
> + vqmmc-supply = <&tf_io>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <8>;
> + cap-sd-highspeed;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vcc3v3>;
> + vqmmc-supply = <&vcc1v8>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index f4f30f674b4c..77c4d5eb48a2 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -57,6 +57,47 @@
> device_type = "memory";
> reg = <0x0 0x0 0x0 0x40000000>;
> };
> +
> + vddio_card: gpio-regulator {
> + compatible = "regulator-gpio";
> +
> + regulator-name = "VDDIO_CARD";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
> + gpios-states = <1>;
> +
> + /* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
> + states = <1800000 0
> + 3300000 1>;
> + };
> +
> + vddio_boot: regulator-vddio_boot {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_BOOT";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + vddao_3v3: regulator-vddao_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + vcc_3v3: regulator-vcc_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -72,3 +113,40 @@
> pinctrl-names = "default";
> };
>
> +/* SD card */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <100000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_card>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <8>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vddio_boot>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index e502c24b0ac7..3723007146ac 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -45,6 +45,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/gpio/meson-gxbb-gpio.h>
> #include <dt-bindings/reset/amlogic,meson-gxbb-reset.h>
> +#include <dt-bindings/clock/gxbb-clkc.h>
>
> / {
> compatible = "amlogic,meson-gxbb";
> @@ -246,7 +247,8 @@
> mux {
> groups = "emmc_nand_d07",
> "emmc_cmd",
> - "emmc_clk";
> + "emmc_clk",
> + "emmc_ds";
> function = "emmc";
> };
> };
> @@ -329,6 +331,39 @@
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xd0000000 0x0 0x200000>;
> +
> + sd_emmc_a: mmc at 70000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x70000 0x0 0x2000>;
> + interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_A>,
> + <&xtal>,
> + <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + status = "disabled";
> + };
> +
> + sd_emmc_b: mmc at 72000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x72000 0x0 0x2000>;
> + interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_B>,
> + <&xtal>,
> + <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + status = "disabled";
> + };
> +
> + sd_emmc_c: mmc at 74000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x74000 0x0 0x2000>;
> + interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_C>,
> + <&xtal>,
> + <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + status = "disabled";
> + };
> };
>
> ethmac: ethernet at c9410000 {
> --
> 2.9.3
>
^ 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