* [PATCH 1/3] arm: dts: imx6qdl: Fix "WARNING: please, no space before tabs"
From: Jagan Teki @ 2016-09-17 7:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Jagan Teki <jteki@openedev.com>
Fixed no space before tabs warnings in respetcive imx6qdl dtsi files.
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
---
arch/arm/boot/dts/imx6qdl-apf6dev.dtsi | 14 +++++++-------
arch/arm/boot/dts/imx6qdl-tx6.dtsi | 32 ++++++++++++++++----------------
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 4 ++--
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi b/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
index edbce22..5e7792d 100644
--- a/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
@@ -347,13 +347,13 @@
fsl,pins = <
MX6QDL_PAD_DI0_PIN4__GPIO4_IO20 0x100b1
MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x100b1
- MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x100b1
- MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x100b1
- MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x100b1
- MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x100b1
- MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x100b1
- MX6QDL_PAD_CSI0_PIXCLK__GPIO5_IO18 0x100b1
- MX6QDL_PAD_CSI0_VSYNC__GPIO5_IO21 0x100b1
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x100b1
+ MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x100b1
+ MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x100b1
+ MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x100b1
+ MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x100b1
+ MX6QDL_PAD_CSI0_PIXCLK__GPIO5_IO18 0x100b1
+ MX6QDL_PAD_CSI0_VSYNC__GPIO5_IO21 0x100b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
index ac9529f..2bf2e62 100644
--- a/arch/arm/boot/dts/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
@@ -429,8 +429,8 @@
pinctrl_edt_ft5x06: edt-ft5x06grp {
fsl,pins = <
MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0 /* Interrupt */
- MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x1b0b0 /* Reset */
- MX6QDL_PAD_EIM_A17__GPIO2_IO21 0x1b0b0 /* Wake */
+ MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x1b0b0 /* Reset */
+ MX6QDL_PAD_EIM_A17__GPIO2_IO21 0x1b0b0 /* Wake */
>;
};
@@ -481,21 +481,21 @@
pinctrl_gpmi_nand: gpminandgrp {
fsl,pins = <
- MX6QDL_PAD_NANDF_CLE__NAND_CLE 0x0b0b1
- MX6QDL_PAD_NANDF_ALE__NAND_ALE 0x0b0b1
- MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0x0b0b1
+ MX6QDL_PAD_NANDF_CLE__NAND_CLE 0x0b0b1
+ MX6QDL_PAD_NANDF_ALE__NAND_ALE 0x0b0b1
+ MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0x0b0b1
MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0x0b000
- MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0x0b0b1
- MX6QDL_PAD_SD4_CMD__NAND_RE_B 0x0b0b1
- MX6QDL_PAD_SD4_CLK__NAND_WE_B 0x0b0b1
- MX6QDL_PAD_NANDF_D0__NAND_DATA00 0x0b0b1
- MX6QDL_PAD_NANDF_D1__NAND_DATA01 0x0b0b1
- MX6QDL_PAD_NANDF_D2__NAND_DATA02 0x0b0b1
- MX6QDL_PAD_NANDF_D3__NAND_DATA03 0x0b0b1
- MX6QDL_PAD_NANDF_D4__NAND_DATA04 0x0b0b1
- MX6QDL_PAD_NANDF_D5__NAND_DATA05 0x0b0b1
- MX6QDL_PAD_NANDF_D6__NAND_DATA06 0x0b0b1
- MX6QDL_PAD_NANDF_D7__NAND_DATA07 0x0b0b1
+ MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0x0b0b1
+ MX6QDL_PAD_SD4_CMD__NAND_RE_B 0x0b0b1
+ MX6QDL_PAD_SD4_CLK__NAND_WE_B 0x0b0b1
+ MX6QDL_PAD_NANDF_D0__NAND_DATA00 0x0b0b1
+ MX6QDL_PAD_NANDF_D1__NAND_DATA01 0x0b0b1
+ MX6QDL_PAD_NANDF_D2__NAND_DATA02 0x0b0b1
+ MX6QDL_PAD_NANDF_D3__NAND_DATA03 0x0b0b1
+ MX6QDL_PAD_NANDF_D4__NAND_DATA04 0x0b0b1
+ MX6QDL_PAD_NANDF_D5__NAND_DATA05 0x0b0b1
+ MX6QDL_PAD_NANDF_D6__NAND_DATA06 0x0b0b1
+ MX6QDL_PAD_NANDF_D7__NAND_DATA07 0x0b0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index 2b9c2be..82dc5744 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -129,8 +129,8 @@
pinctrl_i2c1: i2c1grp {
fsl,pins = <
- MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
- MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-09-17 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC26C5.2060800@arm.com>
On Fri, Sep 16, 2016 at 10:37 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 16/09/16 17:57, Vijay Kilari wrote:
>> On Fri, Sep 16, 2016 at 8:06 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
>>>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>>>
>>>> VGICv3 CPU interface registers are accessed using
>>>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>>>> as 64-bit. The cpu MPIDR value is passed along with register id.
>>>> is used to identify the cpu for registers access.
>>>>
>>>> The version of VGIC v3 specification is define here
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>>>>
>>>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>>> ---
>>>> arch/arm64/include/uapi/asm/kvm.h | 3 +
>>>> arch/arm64/kvm/Makefile | 1 +
>>>> include/linux/irqchip/arm-gic-v3.h | 30 ++++
>>>> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 ++++
>>>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 18 +++
>>>> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 296 ++++++++++++++++++++++++++++++++++++
>>>> virt/kvm/arm/vgic/vgic.h | 10 ++
>>>> 7 files changed, 385 insertions(+)
>
> [...]
>
>>>> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>>>> new file mode 100644
>>>> index 0000000..8e4f403
>>>> --- /dev/null
>>>> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>>>> @@ -0,0 +1,296 @@
>>>> +#include <linux/irqchip/arm-gic-v3.h>
>>>> +#include <linux/kvm.h>
>>>> +#include <linux/kvm_host.h>
>>>> +#include <kvm/iodev.h>
>>>> +#include <kvm/arm_vgic.h>
>>>> +#include <asm/kvm_emulate.h>
>>>> +#include <asm/kvm_arm.h>
>>>> +#include <asm/kvm_mmu.h>
>>>> +
>>>> +#include "vgic.h"
>>>> +#include "vgic-mmio.h"
>>>> +#include "sys_regs.h"
>>>> +
>>>> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>>> + const struct sys_reg_desc *r)
>>>> +{
>>>> + struct vgic_vmcr vmcr;
>>>> + u64 val;
>>>> + u32 ich_vtr;
>>>> +
>>>> + vgic_get_vmcr(vcpu, &vmcr);
>>>> + if (p->is_write) {
>>>> + val = p->regval;
>>>> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
>>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
>>>> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
>>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
>>>> + ICC_CTLR_EL1_EOImode_SHIFT) << ICH_VMCR_EOIM_SHIFT;
>>>> + vgic_set_vmcr(vcpu, &vmcr);
>>>
>>> You've ignored my comments again: "What if userspace writes something
>>> that is incompatible with the current configuration? Wrong number of ID
>>> bits, or number of priorities?"
>>
>> IMO, In case of incompatibility,
>> If ID bits and PRI bits are less than HW supported, it is ok.
>
> Yes. But you also need to track of what the guest has programmed in
> order to be able to migrate it back to its original configuration.
You mean the vgic has to track/store the ID and PRI bits that guest
has programmed
and return the same when guest reads back instead of
returning HW supported value for ICC_CTLR_EL1 reg access?.
>
>> If ID bits and PRI bits are greater than HW supported, then warn would be good
>> enough. Please suggest the behaviour that you think it should be.
>
> No, it is an error, plain and simple. You cannot run in this condition.
>
[...]
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] tty: amba-pl011: uart_amba_port is not available with earlycon function
From: Shawn Guo @ 2016-09-17 6:14 UTC (permalink / raw)
To: linux-arm-kernel
Commit 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE
device") changes earlycon function pl011_putc() to use a pointer to
uart_amba_port. This causes a regression when earlycon is enabled,
because uart_amba_port is not available yet at earlycon time. Let's
revert the change on pl011_putc() to fix the regression.
The earlycon support for ZTE device can probably be added later by
declaring a new earlycon setup function with a vendor specific
compatible.
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Fixes: 0e125a5facf8 ("tty: amba-pl011: define flag register bits for ZTE device")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/tty/serial/amba-pl011.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 0b78b04e895e..2d9ffab16ffe 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2330,16 +2330,13 @@ static struct console amba_console = {
static void pl011_putc(struct uart_port *port, int c)
{
- struct uart_amba_port *uap =
- container_of(port, struct uart_amba_port, port);
-
while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
cpu_relax();
if (port->iotype == UPIO_MEM32)
writel(c, port->membase + UART01x_DR);
else
writeb(c, port->membase + UART01x_DR);
- while (readl(port->membase + UART01x_FR) & uap->vendor->fr_busy)
+ while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
cpu_relax();
}
--
1.9.1
^ permalink raw reply related
* [PATCH v3 1/3] tty: amba-pl011: define flag register bits for ZTE device
From: Shawn Guo @ 2016-09-17 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC27A9.3060307@codeaurora.org>
On Fri, Sep 16, 2016 at 12:11:05PM -0500, Timur Tabi wrote:
> Russell King - ARM Linux wrote:
> >Maybe what we should've done with ZTE is insisted that they implement
> >a complete new driver, rather than trying to shoe-horn it into PL011
> >even though it is in theory PL011.
>
> When I suggested that a year ago, I was shot down:
>
> http://www.spinics.net/lists/arm-kernel/msg455888.html
I still think that's a bad idea. ZTE is not the first one making such
small customization on PL011, and likely won't be the last one. We
don't want to clone PL011 driver every time there is a such vendor
hardware coming out, do we? Having PL011 driver being able to handle
different register layout is very helpful to handle such vendor
variants, IMHO.
I still appreciate rmk's insistence to handle ZTE device with PL011
driver, and the effort of adding a little "infrastructure" to handle
all such possible variants.
Shawn
^ permalink raw reply
* [PATCH v3 1/3] tty: amba-pl011: define flag register bits for ZTE device
From: Shawn Guo @ 2016-09-17 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b549cd51-a81f-b693-e3c2-9e3c598d3d9e@arm.com>
On Fri, Sep 16, 2016 at 03:23:57PM +0100, Sudeep Holla wrote:
> >@@ -2303,13 +2325,16 @@ static struct console amba_console = {
> >
> > static void pl011_putc(struct uart_port *port, int c)
> > {
> >+ struct uart_amba_port *uap =
> >+ container_of(port, struct uart_amba_port, port);
> >+
> > while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
> > cpu_relax();
> > if (port->iotype == UPIO_MEM32)
> > writel(c, port->membase + UART01x_DR);
> > else
> > writeb(c, port->membase + UART01x_DR);
> >- while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
> >+ while (readl(port->membase + UART01x_FR) & uap->vendor->fr_busy)
> > cpu_relax();
> > }
>
> The above hunk won't work for early console devices. The earlycon_device
> just has uart_port and is not uart_amba_port. I don't know how to fix
> this properly but I thought we could reuse private_data in uart_port for
> early_con devices. Something like below(incomplete for other vendors,
> works only for ARM)
Hi Sudeep,
Thanks much for the report. I think the best way to fix this is that we
revert the change for pl011_putc() function, and figure out a correct
approach adding earlycon support for ZTE hardware later.
I will send a patch to revert pl011_putc() changes shortly.
Thanks,
Shawn
^ permalink raw reply
* [PATCH v1 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight
From: maitysanchayan at gmail.com @ 2016-09-17 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474033134.3103.27.camel@toradex.com>
Hello Marcel,
On 16-09-16 13:38:54, Marcel Ziswiler wrote:
> On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> > Use enable-gpios property of PWM backlight driver for backlight
> > control. While at it also fix the use of brightness levels required
> > by EDT displays which require inverted PWM's.
>
> That part I am missing below. Did you forget to include it?
No, actually I missed fixing the commit message. Currently PWM polarity
inversion is not supported and while checking, I kept the brightness
levels as is currently but did not change the commit message.
Will send a v2 and fix this.
Regards,
Sanchayan.
>
> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> > ---
> > ?arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +++++++++
> > ?1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 8c67dd8..9100bde 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -49,7 +49,10 @@
> > ?
> > ? backlight: backlight {
> > ? compatible = "pwm-backlight";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_bl_on>;
> > ? pwms = <&pwm4 0 5000000>;
> > + enable-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
> > ? status = "disabled";
> > ? };
> > ?
> > @@ -614,6 +617,12 @@
> > ? >;
> > ? };
> > ?
> > + pinctrl_gpio_bl_on: gpioblon {
> > + fsl,pins = <
> > + MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
> > + >;
> > + };
> > +
> > ? pinctrl_gpio_keys: gpio1io04grp {
> > ? fsl,pins = <
> > ? /* Power button */
^ permalink raw reply
* [PATCH v2 3/6] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kishon Vijay Abraham I @ 2016-09-17 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2a8faxy72.fsf@baylibre.com>
Hi Kevin,
On Wednesday 14 September 2016 09:36 PM, Kevin Hilman wrote:
> Kishon,
>
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
>> This is a new driver for the USB PHY found in Meson8b and GXBB SoCs.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>> Tested-by: Kevin Hilman <khilman@baylibre.com>
>
> Will you be picking this up for v4.9?
It's already late for 4.9. Generally send pull request to Greg around -rc6.
This can go only in 4.10.
Thanks
Kishon
>
> Kevin
>
>> ---
>> drivers/phy/Kconfig | 11 ++
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-meson-usb2.c | 280 +++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 292 insertions(+)
>> create mode 100644 drivers/phy/phy-meson-usb2.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 19bff3a..6ad87ec 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -453,4 +453,15 @@ config PHY_NS2_PCIE
>> help
>> Enable this to support the Broadcom Northstar2 PCIe PHY.
>> If unsure, say N.
>> +
>> +config PHY_MESON_USB2
>> + tristate "Meson USB2 PHY driver"
>> + default ARCH_MESON
>> + depends on OF && (ARCH_MESON || COMPILE_TEST)
>> + select GENERIC_PHY
>> + help
>> + Enable this to support the Meson USB2 PHYs found in Meson8b
>> + and GXBB SoCs.
>> + If unsure, say N.
>> +
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 90ae198..dd507ac 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -56,3 +56,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
>> obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
>> obj-$(CONFIG_ARCH_TEGRA) += tegra/
>> obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
>> +obj-$(CONFIG_PHY_MESON_USB2) += phy-meson-usb2.o
>> diff --git a/drivers/phy/phy-meson-usb2.c b/drivers/phy/phy-meson-usb2.c
>> new file mode 100644
>> index 0000000..eece521
>> --- /dev/null
>> +++ b/drivers/phy/phy-meson-usb2.c
>> @@ -0,0 +1,280 @@
>> +/*
>> + * Meson USB2 PHY driver
>> + *
>> + * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/reset.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/usb/of.h>
>> +
>> +#define REG_CONFIG 0x00
>> + #define REG_CONFIG_CLK_EN BIT(0)
>> + #define REG_CONFIG_CLK_SEL_MASK GENMASK(3, 1)
>> + #define REG_CONFIG_CLK_DIV_MASK GENMASK(10, 4)
>> + #define REG_CONFIG_CLK_32k_ALTSEL BIT(15)
>> + #define REG_CONFIG_TEST_TRIG BIT(31)
>> +
>> +#define REG_CTRL 0x04
>> + #define REG_CTRL_SOFT_PRST BIT(0)
>> + #define REG_CTRL_SOFT_HRESET BIT(1)
>> + #define REG_CTRL_SS_SCALEDOWN_MODE_MASK GENMASK(3, 2)
>> + #define REG_CTRL_CLK_DET_RST BIT(4)
>> + #define REG_CTRL_INTR_SEL BIT(5)
>> + #define REG_CTRL_CLK_DETECTED BIT(8)
>> + #define REG_CTRL_SOF_SENT_RCVD_TGL BIT(9)
>> + #define REG_CTRL_SOF_TOGGLE_OUT BIT(10)
>> + #define REG_CTRL_POWER_ON_RESET BIT(15)
>> + #define REG_CTRL_SLEEPM BIT(16)
>> + #define REG_CTRL_TX_BITSTUFF_ENN_H BIT(17)
>> + #define REG_CTRL_TX_BITSTUFF_ENN BIT(18)
>> + #define REG_CTRL_COMMON_ON BIT(19)
>> + #define REG_CTRL_REF_CLK_SEL_MASK GENMASK(21, 20)
>> + #define REG_CTRL_REF_CLK_SEL_SHIFT 20
>> + #define REG_CTRL_FSEL_MASK GENMASK(24, 22)
>> + #define REG_CTRL_FSEL_SHIFT 22
>> + #define REG_CTRL_PORT_RESET BIT(25)
>> + #define REG_CTRL_THREAD_ID_MASK GENMASK(31, 26)
>> +
>> +#define REG_ENDP_INTR 0x08
>> +
>> +/* bits [31:26], [24:21] and [15:3] seem to be read-only */
>> +#define REG_ADP_BC 0x0c
>> + #define REG_ADP_BC_VBUS_VLD_EXT_SEL BIT(0)
>> + #define REG_ADP_BC_VBUS_VLD_EXT BIT(1)
>> + #define REG_ADP_BC_OTG_DISABLE BIT(2)
>> + #define REG_ADP_BC_ID_PULLUP BIT(3)
>> + #define REG_ADP_BC_DRV_VBUS BIT(4)
>> + #define REG_ADP_BC_ADP_PRB_EN BIT(5)
>> + #define REG_ADP_BC_ADP_DISCHARGE BIT(6)
>> + #define REG_ADP_BC_ADP_CHARGE BIT(7)
>> + #define REG_ADP_BC_SESS_END BIT(8)
>> + #define REG_ADP_BC_DEVICE_SESS_VLD BIT(9)
>> + #define REG_ADP_BC_B_VALID BIT(10)
>> + #define REG_ADP_BC_A_VALID BIT(11)
>> + #define REG_ADP_BC_ID_DIG BIT(12)
>> + #define REG_ADP_BC_VBUS_VALID BIT(13)
>> + #define REG_ADP_BC_ADP_PROBE BIT(14)
>> + #define REG_ADP_BC_ADP_SENSE BIT(15)
>> + #define REG_ADP_BC_ACA_ENABLE BIT(16)
>> + #define REG_ADP_BC_DCD_ENABLE BIT(17)
>> + #define REG_ADP_BC_VDAT_DET_EN_B BIT(18)
>> + #define REG_ADP_BC_VDAT_SRC_EN_B BIT(19)
>> + #define REG_ADP_BC_CHARGE_SEL BIT(20)
>> + #define REG_ADP_BC_CHARGE_DETECT BIT(21)
>> + #define REG_ADP_BC_ACA_PIN_RANGE_C BIT(22)
>> + #define REG_ADP_BC_ACA_PIN_RANGE_B BIT(23)
>> + #define REG_ADP_BC_ACA_PIN_RANGE_A BIT(24)
>> + #define REG_ADP_BC_ACA_PIN_GND BIT(25)
>> + #define REG_ADP_BC_ACA_PIN_FLOAT BIT(26)
>> +
>> +#define REG_DBG_UART 0x14
>> +
>> +#define REG_TEST 0x18
>> + #define REG_TEST_DATA_IN_MASK GENMASK(3, 0)
>> + #define REG_TEST_EN_MASK GENMASK(7, 4)
>> + #define REG_TEST_ADDR_MASK GENMASK(11, 8)
>> + #define REG_TEST_DATA_OUT_SEL BIT(12)
>> + #define REG_TEST_CLK BIT(13)
>> + #define REG_TEST_VA_TEST_EN_B_MASK GENMASK(15, 14)
>> + #define REG_TEST_DATA_OUT_MASK GENMASK(19, 16)
>> + #define REG_TEST_DISABLE_ID_PULLUP BIT(20)
>> +
>> +#define REG_TUNE 0x1c
>> + #define REG_TUNE_TX_RES_TUNE_MASK GENMASK(1, 0)
>> + #define REG_TUNE_TX_HSXV_TUNE_MASK GENMASK(3, 2)
>> + #define REG_TUNE_TX_VREF_TUNE_MASK GENMASK(7, 4)
>> + #define REG_TUNE_TX_RISE_TUNE_MASK GENMASK(9, 8)
>> + #define REG_TUNE_TX_PREEMP_PULSE_TUNE BIT(10)
>> + #define REG_TUNE_TX_PREEMP_AMP_TUNE_MASK GENMASK(12, 11)
>> + #define REG_TUNE_TX_FSLS_TUNE_MASK GENMASK(16, 13)
>> + #define REG_TUNE_SQRX_TUNE_MASK GENMASK(19, 17)
>> + #define REG_TUNE_OTG_TUNE GENMASK(22, 20)
>> + #define REG_TUNE_COMP_DIS_TUNE GENMASK(25, 23)
>> + #define REG_TUNE_HOST_DM_PULLDOWN BIT(26)
>> + #define REG_TUNE_HOST_DP_PULLDOWN BIT(27)
>> +
>> +#define RESET_COMPLETE_TIME 500
>> +#define ACA_ENABLE_COMPLETE_TIME 50
>> +
>> +struct phy_meson_usb2_priv {
>> + void __iomem *regs;
>> + enum usb_dr_mode dr_mode;
>> + struct clk *clk_usb_general;
>> + struct clk *clk_usb;
>> +};
>> +
>> +static u32 phy_meson_usb2_read(struct phy_meson_usb2_priv *phy_priv, u32 reg)
>> +{
>> + return readl(phy_priv->regs + reg);
>> +}
>> +
>> +static void phy_meson_usb2_mask_bits(struct phy_meson_usb2_priv *phy_priv,
>> + u32 reg, u32 mask, u32 value)
>> +{
>> + u32 data;
>> +
>> + data = phy_meson_usb2_read(phy_priv, reg);
>> + data &= ~mask;
>> + data |= (value & mask);
>> +
>> + writel(data, phy_priv->regs + reg);
>> +}
>> +
>> +static int phy_meson_usb2_power_on(struct phy *phy)
>> +{
>> + struct phy_meson_usb2_priv *priv = phy_get_drvdata(phy);
>> + int ret;
>> +
>> + ret = clk_prepare_enable(priv->clk_usb_general);
>> + if (ret) {
>> + dev_err(&phy->dev, "Failed to enable USB general clock\n");
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(priv->clk_usb);
>> + if (ret) {
>> + dev_err(&phy->dev, "Failed to enable USB DDR clock\n");
>> + return ret;
>> + }
>> +
>> + phy_meson_usb2_mask_bits(priv, REG_CONFIG, REG_CONFIG_CLK_32k_ALTSEL,
>> + REG_CONFIG_CLK_32k_ALTSEL);
>> +
>> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_REF_CLK_SEL_MASK,
>> + 0x2 << REG_CTRL_REF_CLK_SEL_SHIFT);
>> +
>> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_FSEL_MASK,
>> + 0x5 << REG_CTRL_FSEL_SHIFT);
>> +
>> + /* reset the PHY */
>> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_POWER_ON_RESET,
>> + REG_CTRL_POWER_ON_RESET);
>> + udelay(RESET_COMPLETE_TIME);
>> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_POWER_ON_RESET, 0);
>> + udelay(RESET_COMPLETE_TIME);
>> +
>> + phy_meson_usb2_mask_bits(priv, REG_CTRL, REG_CTRL_SOF_TOGGLE_OUT,
>> + REG_CTRL_SOF_TOGGLE_OUT);
>> +
>> + if (priv->dr_mode == USB_DR_MODE_HOST) {
>> + phy_meson_usb2_mask_bits(priv, REG_ADP_BC,
>> + REG_ADP_BC_ACA_ENABLE,
>> + REG_ADP_BC_ACA_ENABLE);
>> +
>> + udelay(ACA_ENABLE_COMPLETE_TIME);
>> +
>> + if (phy_meson_usb2_read(priv, REG_ADP_BC) &
>> + REG_ADP_BC_ACA_PIN_FLOAT) {
>> + dev_warn(&phy->dev, "USB ID detect failed!\n");
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int phy_meson_usb2_power_off(struct phy *phy)
>> +{
>> + struct phy_meson_usb2_priv *priv = phy_get_drvdata(phy);
>> +
>> + clk_disable_unprepare(priv->clk_usb);
>> + clk_disable_unprepare(priv->clk_usb_general);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct phy_ops phy_meson_usb2_ops = {
>> + .power_on = phy_meson_usb2_power_on,
>> + .power_off = phy_meson_usb2_power_off,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static int phy_meson_usb2_probe(struct platform_device *pdev)
>> +{
>> + struct phy_meson_usb2_priv *priv;
>> + struct resource *res;
>> + struct phy *phy;
>> + struct phy_provider *phy_provider;
>> + int ret;
>> +
>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + priv->regs = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(priv->regs))
>> + return PTR_ERR(priv->regs);
>> +
>> + priv->clk_usb_general = devm_clk_get(&pdev->dev, "usb_general");
>> + if (IS_ERR(priv->clk_usb_general))
>> + return PTR_ERR(priv->clk_usb_general);
>> +
>> + priv->clk_usb = devm_clk_get(&pdev->dev, "usb");
>> + if (IS_ERR(priv->clk_usb))
>> + return PTR_ERR(priv->clk_usb);
>> +
>> + priv->dr_mode = of_usb_get_dr_mode_by_phy(pdev->dev.of_node, -1);
>> + if (priv->dr_mode == USB_DR_MODE_UNKNOWN) {
>> + dev_err(&pdev->dev,
>> + "missing dual role configuration of the controller\n");
>> + return -EINVAL;
>> + }
>> +
>> + phy = devm_phy_create(&pdev->dev, NULL, &phy_meson_usb2_ops);
>> + if (IS_ERR(phy)) {
>> + dev_err(&pdev->dev, "failed to create PHY\n");
>> + return PTR_ERR(phy);
>> + }
>> +
>> + /*
>> + * No actual error check here because the hardware only has one reset
>> + * line for both PHYs. Using a shared reset is not possible because we
>> + * must call reset_control_reset to trigger the reset (which is not
>> + * allowed for shared resets in the reset framework).
>> + */
>> + ret = device_reset_optional(&pdev->dev);
>> + if (ret == -EPROBE_DEFER)
>> + return ret;
>> +
>> + phy_set_drvdata(phy, priv);
>> +
>> + phy_provider =
>> + devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
>> +
>> + return PTR_ERR_OR_ZERO(phy_provider);
>> +}
>> +
>> +static const struct of_device_id phy_meson_usb2_of_match[] = {
>> + { .compatible = "amlogic,meson8b-usb2-phy", },
>> + { .compatible = "amlogic,meson-gxbb-usb2-phy", },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, phy_meson_usb2_of_match);
>> +
>> +static struct platform_driver phy_meson_usb2_driver = {
>> + .probe = phy_meson_usb2_probe,
>> + .driver = {
>> + .name = "phy-meson-usb2",
>> + .of_match_table = phy_meson_usb2_of_match,
>> + },
>> +};
>> +module_platform_driver(phy_meson_usb2_driver);
>> +
>> +MODULE_AUTHOR("Martin Blumenstingl <martin.blumenstingl@googlemail.com>");
>> +MODULE_DESCRIPTION("Meson USB2 PHY driver");
>> +MODULE_LICENSE("GPL");
^ permalink raw reply
* [PATCH v7 0/5] mfd: tps65218: Clean ups
From: Keerthy @ 2016-09-17 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916173620.GB10189@sirena.org.uk>
On Friday 16 September 2016 11:06 PM, Mark Brown wrote:
> On Fri, Sep 16, 2016 at 09:51:38PM +0530, Keerthy wrote:
>> On Friday 16 September 2016 07:01 PM, Mark Brown wrote:
>>> On Fri, Sep 16, 2016 at 05:12:38PM +0530, Keerthy wrote:
>
>>>> Should i repost this series? I do not see this series in linux-next yet.
>
>>> Please don't send content free pings and please allow a reasonable time
>>> for review. People get busy, go on holiday, attend conferences and so
>
>> I should have been clearer.
>> The last Lee Jones conveyed that:
>
>> "I can't take this series yet, since it relies on a change which was
>> taken into Mark's Regulator tree"
>
>> https://lkml.org/lkml/2016/8/31/312
>
>> So wanted to check if i needed to re-base/repost this series again.
>> Sorry about the confusion i think that is because of $Subject goof up in the
>> 0th patch of the series.
>
> I'm afraid I've no real idea what this series is about or what patches
> it might depend on, sorry. If you're waiting for me to do something
> you'll need to tell me what it is but if it's a dependency that needs
> cross merging then reposting this series isn't going to be needed.
The series cleans up mainly the regulator driver and implements
the device tree parsing using the regulator framework. Removes
all the redundant compatibles for the individual regulators.
Adds platform_device_id table for the gpio and power button modules.
This has been reviewed extensively.
Looks like v7 no longer applies directly on the linux-next branch as it
conflicts with:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/dtor/input/+/722dc54628ca5cffd3b4581b523775aa422b55df
I will rebase and repost on the current linux-next and post v8.
>
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Peter Chen @ 2016-09-17 1:16 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.
>
> 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.
>
> soc {
> usb at 78d9000 {
> extcon = <&usb_id>, <&usb_id>;
Why you have two same extcon phandler? From my mind, one should id,
another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
vbus support, how you support vbus detection for
connection/disconnection with PC for your chipidea msm patch set?
> usb-controller; // needed?
Not needed. You only need to describe controller, mux ic, and hub
(if you need platform stuffs the driver needs to know).
Peter
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
>
> usb_output: endpoint at 0 { // USB D+/D-
> reg = <0>;
> remote-endpoint = <&usb_switch_input>;
> };
> };
> };
> };
> };
>
> usb2513 {
> compatible = "smsc,usb3503";
> reset-gpios = <&pm8916_gpios 3 GPIO_ACTIVE_LOW>;
> initial-mode = <1>;
> usb-hub; // indicate this is a hub
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
>
> usb_hub_input: endpoint at 0 { // USB{DP,DM}_UP
> reg = <0>;
> remote-endpoint = <&usb_switch_hub_ep>;
> };
>
> usb_hub_output1: endpoint at 1 { // USB{DP,DM}_DN1
> reg = <1>;
> remote-endpoint = <&usb_a2_connector>;
> };
>
> usb_hub_output2: endpoint at 2 { // USB{DP,DM}_DN2
> reg = <2>;
> remote-endpoint = <&usb_a1_connector>;
> };
>
> usb_hub_output3: endpoint at 3 { // USB{DP,DM}_DN3
> reg = <3>;
> // goes to expansion connector
> };
> };
> };
> };
>
> usb_id: usb-id {
> compatible = "linux,extcon-usb-gpio";
> id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
> pinctrl-names = "default";
> pinctrl-0 = <&usb_id_default>;
> };
>
> usb-switch {
> compatible = "toshiba,tc7usb40mu";
> switch-gpios = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
> extcon = <&usb_id>;
> pinctrl-names = "default";
> pinctrl-0 = <&usb_sw_sel_pm>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
>
> usb_switch_input: endpoint at 0 { // D+/D-
> reg = <0>;
> remote-endpoint = <&usb_output>;
> };
>
> usb_switch_device_ep: endpoint at 1 { // D1+/D1-
> reg = <1>;
> remote-endpoint = <&usb_ub_connector>;
> };
>
> usb_switch_hub_ep: endpoint at 2 { // D2+/D2-
> reg = <2>;
> remote-endpoint = <&usb_hub_input>;
> };
> };
> };
> };
>
> uB-connector {
> compatible = "usb-ub-connector";
> #address-cells = <1>;
> #size-cells = <0>;
> usb-connector;
> port at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> usb_ub_connector: endpoint at 0 {
> reg = <0>;
> remote-endpoint = <&usb_switch_device_ep>;
> };
> };
> };
>
> usb-A-connector1 {
> compatible = "usb-A-connector";
> #address-cells = <1>;
> #size-cells = <0>;
> usb-connector;
> port at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> usb_a1_connector: endpoint at 0 {
> reg = <0>;
> remote-endpoint = <&usb_hub_output2>;
> };
> };
> };
>
> usb-A-connector2 {
> compatible = "usb-A-connector";
> #address-cells = <1>;
> #size-cells = <0>;
> usb-connector;
> port at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> usb_a2_connector: endpoint at 0 {
> reg = <0>;
> remote-endpoint = <&usb_hub_output1>;
> };
> };
> };
> };
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Peter Chen @ 2016-09-17 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147398859894.4997.6486248242638696855@sboyd-linaro>
On Thu, Sep 15, 2016 at 06:16:38PM -0700, Stephen Boyd wrote:
>
> > For #3, it is not the
> > use case for this design. #3 is usually used for the single port which
> > needs to support switching role on the fly without disconnection.
> > So, you may only need to consider #2, you can't use extcon-usb-gpio.c
> > directly since you need to set one gpio to mux the dp/dm, Baolu Lu had
> > USB MUX patch set before which may satisfy your requirement. [1]
>
> Ok. Did the usb mux patches go anywhere? It seemed to get tangled up in
> DRD framework and I haven't been following along. I'll look into these
> patches more.
DRD framework is denied by Felipe due to only one user can be benefit
from it (chipidea OTG), I don't know the further status of USB MUX,
maybe you can ask for it.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam
From: Stephen Boyd @ 2016-09-17 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <32148db3-74b8-c81f-9688-b286d9516b9d@mm-sol.com>
On 09/07/2016 06:09 AM, Stanimir Varbanov wrote:
> Hi Iaroslav,
>
> On 08/30/2016 06:37 PM, Iaroslav Gridin wrote:
>> From: Voker57 <voker57@gmail.com>
>>
>> Add device tree definitions for Qualcomm Cryptography engine and its BAM
>> Signed-off-by: Iaroslav Gridin <voker57@gmail.com>
>> ---
>> arch/arm/boot/dts/qcom-msm8974.dtsi | 42 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> index 561d4d1..c0da739 100644
>> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
>> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
>> @@ -287,6 +287,48 @@
>> reg = <0xf9011000 0x1000>;
>> };
>>
>> + cryptobam: dma at fd444000 {
>> + compatible = "qcom,bam-v1.4.0";
>> + reg = <0xfd444000 0x15000>;
>> + interrupts = <0 236 0>;
> should be
>
> interrupts = <GIC_SPI 236 IRQ_NONE>;
Please don't use IRQ_NONE. This one looks to be IRQ_TYPE_EDGE_RISING if
I'm not mistaken.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Stephen Boyd @ 2016-09-17 0:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916151950.GA31804@rob-hp-laptop>
Quoting Rob Herring (2016-09-16 08:19:51)
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > The high-speed phy on qcom SoCs is controlled via the ULPI
> > viewport.
> >
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>
> > Cc: <devicetree@vger.kernel.org>
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > ---
> > .../devicetree/bindings/phy/qcom,usb-hs-phy.txt | 83 ++++++
> > drivers/phy/Kconfig | 8 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/phy-qcom-usb-hs.c | 289 +++++++++++++++++++++
> > 4 files changed, 381 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> > create mode 100644 drivers/phy/phy-qcom-usb-hs.c
> >
> > diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> > new file mode 100644
> > index 000000000000..d7eacd63d06b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
> > @@ -0,0 +1,83 @@
> > +Qualcomm's USB HS PHY
> > +
> > +PROPERTIES
> > +
> > +- compatible:
> > + Usage: required
> > + Value type: <string>
> > + Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the
> > + following:
> > +
> > + "qcom,usb-hs-phy-apq8064"
> > + "qcom,usb-hs-phy-msm8916"
> > + "qcom,usb-hs-phy-msm8974"
>
> This is fine, but things are usually named <soc>-<ipblock>.
>
> > +
> > +- #phy-cells:
> > + Usage: required
> > + Value type: <u32>
> > + Definition: Should contain 0
> > +
> > +- clocks:
> > + Usage: required
> > + Value type: <prop-encoded-array>
> > + Definition: Should contain clock specifier for the reference and sleep
> > + clocks
> > +
> > +- clock-names:
> > + Usage: required
> > + Value type: <stringlist>
> > + Definition: Should contain "ref" and "sleep" for the reference and sleep
> > + clocks respectively
> > +
> > +- resets:
> > + Usage: required
> > + Value type: <prop-encoded-array>
> > + Definition: Should contain the phy and POR resets
> > +
> > +- reset-names:
> > + Usage: required
> > + Value type: <stringlist>
> > + Definition: Should contain "phy" and "por" for the phy and POR resets
> > + respectively
> > +
> > +- v3p3-supply:
> > + Usage: required
> > + Value type: <phandle>
> > + Definition: Should contain a reference to the 3.3V supply
> > +
> > +- v1p8-supply:
> > + Usage: required
> > + Value type: <phandle>
> > + Definition: Should contain a reference to the 1.8V supply
> > +
> > +- extcon:
>
> I don't recommend using extcon binding. It needs some work to put it
> nicely.
:sadface:
>
> > + Usage: optional
> > + Value type: <prop-encoded-array>
> > + Definition: Should contain the vbus and ID extcons in the first and second
> > + cells respectively
> > +
> > +- qcom,init-seq:
> > + Usage: optional
> > + Value type: <u8 array>
> > + Definition: Should contain a sequence of ULPI register and address pairs to
> > + program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
> > + to Device Mode Eye Diagram test.
>
> We generally nak this type of property. For 1 register I don't care so
> much. For 100, that would be another story.
>
> Is this value per unit, per board, per SoC? Can you limit it to certain
> registers?
I'm told that this can be per board, depending on how it's wired from
the phy pins to the usb port. Typically it's the same though for the
boards I have, mostly because those boards are similar designs with
respect to how USB is wired. The set of registers is not that many, 4 or
5 at most. My understanding is these are tuning registers. Right now the
register part in the binding is the full register offset, and not an
offset from ULPI_EXT_VENDOR_SPECIFIC (0x80). I could change this to be
an offset from that area if you like so that this can't be abused to
write into standard ULPI registers (there really isn't any way to
enforce this in software though).
This is "borrowed" from another binding for this usb stuff that I'm
attempting to kill off, bindings/usb/msm-hsusb.txt. Just historical info
in case you're interested.
^ permalink raw reply
* [PATCH v7 1/2] clk: uniphier: add core support code for UniPhier clock driver
From: Stephen Boyd @ 2016-09-16 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474011604-12577-2-git-send-email-yamada.masahiro@socionext.com>
On 09/16, Masahiro Yamada wrote:
> This includes UniPhier clock driver code, except SoC-specific
> data arrays.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: zx: fix pointer case warnings
From: Stephen Boyd @ 2016-09-16 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915154618.3007024-1-arnd@arndb.de>
On 09/15, Arnd Bergmann wrote:
> The zx296718 clock driver has a creative way of assigning the register
> values for each clock, by initializing an __iomem pointer to an
> offset and then later adding the base (from ioremap) on top
> with a cast to u64. This fail on all 32-bit architectures during
> compile testing:
>
> drivers/clk/zte/clk-zx296718.c: In function 'top_clocks_init':
> drivers/clk/zte/clk-zx296718.c:554:35: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> zx296718_pll_clk[i].reg_base += (u64)reg_base;
> drivers/clk/zte/clk-zx296718.c:579:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> drivers/clk/zte/clk-zx296718.c:592:31: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
>
> It would be nice to avoid all the casts, but I decided to simply
> shut up the warnings by changing the type from u64 to uintptr_t,
> which does the right thing in practice.
Thanks. I usually push people to have descriptor structures that
they use to create these things at runtime but that isn't working
out so great all the time and we don't really have a precedent
for one way or the other. This will work for now.
Applied to clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3] clk: let clk_disable() return immediately if clk is NULL
From: Stephen Boyd @ 2016-09-16 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNARaV6Ga5G1GnYf9hywrr+YwOqqm-v1AzBpfXtM4u9ofBA@mail.gmail.com>
On 09/16, Masahiro Yamada wrote:
> Hi Stephen, Michael,
>
> 2016-08-26 0:27 GMT+09:00 Florian Fainelli <f.fainelli@gmail.com>:
> > On 08/24/2016 10:26 AM, Masahiro Yamada wrote:
> >> Many of clk_disable() implementations just return for NULL pointer,
> >> but this check is missing from some. Let's make it tree-wide
> >> consistent. It will allow clock consumers to call clk_disable()
> >> without NULL pointer check.
> >>
> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >> Acked-by: Greg Ungerer <gerg@uclinux.org>
> >> Acked-by: Wan Zongshun <mcuos.com@gmail.com>
> >> ---
> >>
> >> I came back after a long pause.
> >> You can see the discussion about the previous version:
> >> https://www.linux-mips.org/archives/linux-mips/2016-04/msg00063.html
> >>
> >>
> >> Changes in v3:
> >> - Return only when clk is NULL. Do not take care of error pointer.
> >>
> >> Changes in v2:
> >> - Rebase on Linux 4.6-rc1
> >>
> >> arch/arm/mach-mmp/clock.c | 3 +++
> >> arch/arm/mach-w90x900/clock.c | 3 +++
> >> arch/blackfin/mach-bf609/clock.c | 3 +++
> >> arch/m68k/coldfire/clk.c | 4 ++++
> >> arch/mips/bcm63xx/clk.c | 3 +++
> >
>
>
> Gentle ping...
>
>
> If you are not keen on this,
> shall I split it per-arch and send to each arch subsystem?
>
If we get acks from more arch maintainers we could take it
through clk tree, but we really don't maintain these other clk
implementations so it isn't very appropriate to take it through
clk tree anyway. Perhaps splitting it up per arch and sending it
that way and then Ccing akpm (aka the patch collector) would make
sure things get merged in a timely manner. Or Andrew could just
pick up this patch as is.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH -next] clk: zx296718: use builtin_platform_driver to simplify the code
From: Stephen Boyd @ 2016-09-16 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474031011-6700-1-git-send-email-weiyj.lk@gmail.com>
On 09/16, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Use the builtin_platform_driver() macro to make the code simpler.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] clk: sunxi-ng: sun6i-a31: Fix register offset for mipi-csi clk
From: Stephen Boyd @ 2016-09-16 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-4-wens@csie.org>
On 09/15, Chen-Yu Tsai wrote:
> The register offset for the mipi-csi clk is off by 4, a copy paste
> error from the mipi-dsi clk.
>
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/3] clk: sunxi-ng: sun6i-a31: Set CLK_SET_RATE_PARENT for display output clocks
From: Stephen Boyd @ 2016-09-16 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-2-wens@csie.org>
On 09/15, Chen-Yu Tsai wrote:
> The LCD controller and HDMI controller use the LCDx-CHy and HDMI clocks
> to generate their dot clocks. To be able to generate a full range of
> possible clock rates, the parent PLL clock rates should also be changed.
>
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 05/14] drivers: clk: st: Add clock propagation for audio clocks
From: Stephen Boyd @ 2016-09-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472473626-15398-6-git-send-email-gabriel.fernandez@st.com>
On 08/29, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch allows fine tuning of the quads FS for audio clocks
> accuracy.
>
> Signed-off-by: Olivier Bideau <olivier.bideau@st.com>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 04/14] drivers: clk: st: Add fs660c32 synthesizer algorithm
From: Stephen Boyd @ 2016-09-16 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472473626-15398-5-git-send-email-gabriel.fernandez@st.com>
On 08/29, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Use an algorithm instead of a table to compute clocks for fs660c32
> synthesizer.
> During a video playback we need to adjust audio & video frequencies.
> A table can't cover all HDMI resolutions and audio adjustment.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 02/14] drivers: clk: st: Simplify clock binding of STiH4xx platforms
From: Stephen Boyd @ 2016-09-16 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472473626-15398-3-git-send-email-gabriel.fernandez@st.com>
On 08/29, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch reworks the clock binding to avoid too much detail in DT.
> Now we have only compatible string per type of clock
> (remark from Rob https://lkml.org/lkml/2016/5/25/492)
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 01/14] drivers: clk: st: Remove stih415-416 clock support
From: Stephen Boyd @ 2016-09-16 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472473626-15398-2-git-send-email-gabriel.fernandez@st.com>
On 08/29, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> STiH415 and STiH416 platforms are no longer used.
> these platforms will be deprecated for the next kernel.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv2 3/3] clk: keystone: Add sci-clk driver support
From: Stephen Boyd @ 2016-09-16 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <827e0a46-3771-67a8-1414-0cbaf0e2548e@ti.com>
On 09/05, Tero Kristo wrote:
> On 03/09/16 02:32, Stephen Boyd wrote:
> >I still don't get it. We should be registering hw pointers in
> >probe and handing them out in the xlate function. Not register
> >hws in the xlate function and then handing them out as well. I
> >haven't reviewed anything else in this patch.
>
> Ok, let me try to explain the functionality.
>
> Probe time hw pointer registration is only needed for special clocks
> that require extra flags, like adding the spread spectrum flag.
> There is ever going to be only handful of these.
>
> Xlate checks out the sci_clk list, and picks up an existing hw clock
> if it is there. If not, it will create a new one. The reason this is
> done like this, the device IDs / clock IDs don't mean anything to
> the driver itself, the driver just passes these forward to the
> underlying SCI fwk. And, we don't have inherent knowledge of valid
> device / clock IDs either, the SCI fwk returns a failure if a
> specific clock ID is bad. The device / clock IDs are going to be
> different between different generations of SoC also, and in addition
> there can be holes in the ID ranges.
Ok. Thanks for the explanation.
I understand the desire to make this SoC agnostic and consumer/dt
driven. Constructor pattern and all. Unfortunately the OF clk
provider is a getter pattern; not a constructor pattern. I'm
seriously concerned about the locking here because we're in the
framework creating a clk and tying it into a consumer list which
could cause all sorts of problems if we want to reenter the
framework and register more clks. Recursion abounds and my head
explodes! The recursive clk prepare mutex is not something anyone
should be thrilled about keeping around.
So, just don't do this. Instead, register the clks during probe
that exist for the firmware. That list could be discoverable with
firmware calls, or known based on different compatible strings
from DT that have the soc name in it, or something else. Even
scanning the entire DT tree for
clocks = <&my_clk_node x y>
would be better, but probably hugely inefficient and outright
buggy with DT overlays so don't do it. If the firmware can't tell
us what clks are there, just have a table based on compatible
string and be done.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] cpufreq: ti: Use generic platdev driver
From: Rafael J. Wysocki @ 2016-09-16 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC6420.20706@ti.com>
On Friday, September 16, 2016 04:29:04 PM Dave Gerlach wrote:
> Hi,
> On 09/15/2016 01:25 AM, Viresh Kumar wrote:
> > On 14-09-16, 15:41, Dave Gerlach wrote:
> >> Now that the cpufreq-dt-platdev is used to create the cpufreq-dt platform
> >> device for all OMAP platforms and the platform code that did it
> >> before has been removed, add ti,am33xx and ti,dra7xx to the machine list
> >> in cpufreq-dt-platdev which had relied on the removed platform code to do
> >> this previously.
> >>
> >> Fixes: 7694ca6e1d6f ("cpufreq: omap: Use generic platdev driver")
> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> >
> > Any stable trees you want this to be added to ?
>
> I suppose it'll go for 4.7-stable as the change happened in v4.6.
The commit in the fixes tag went in during the 4.7 cycle, so the fix should
go into 4.7.y, but I'm not going to push it as urgent material for 4.8.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 7/7] ARM: dts: exynos: Use human-friendly symbols for interrupt properties in exynos5440
From: Krzysztof Kozlowski @ 2016-09-16 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474062122-22720-1-git-send-email-krzk@kernel.org>
Replace hard-coded values of type of GIC interrupt and its flags with
respective macros from header to increase code readability
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos5440.dtsi | 80 ++++++++++++++++++++-------------------
1 file changed, 41 insertions(+), 39 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 20f600225121..97c9f0e38526 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -10,6 +10,7 @@
*/
#include <dt-bindings/clock/exynos5440.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
/ {
@@ -42,7 +43,8 @@
<0x2E2000 0x1000>,
<0x2E4000 0x2000>,
<0x2E6000 0x2000>;
- interrupts = <1 9 0xf04>;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
cpus {
@@ -73,26 +75,26 @@
arm-pmu {
compatible = "arm,cortex-a15-pmu", "arm,cortex-a9-pmu";
- interrupts = <0 52 4>,
- <0 53 4>,
- <0 54 4>,
- <0 55 4>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
};
timer {
compatible = "arm,cortex-a15-timer",
"arm,armv7-timer";
- interrupts = <1 13 0xf08>,
- <1 14 0xf08>,
- <1 11 0xf08>,
- <1 10 0xf08>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
clock-frequency = <50000000>;
};
cpufreq at 160000 {
compatible = "samsung,exynos5440-cpufreq";
reg = <0x160000 0x1000>;
- interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
operating-points = <
/* KHz uV */
1500000 1100000
@@ -109,7 +111,7 @@
serial_0: serial@B0000 {
compatible = "samsung,exynos4210-uart";
reg = <0xB0000 0x1000>;
- interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_B_125>, <&clock CLK_B_125>;
clock-names = "uart", "clk_uart_baud0";
};
@@ -117,7 +119,7 @@
serial_1: serial at C0000 {
compatible = "samsung,exynos4210-uart";
reg = <0xC0000 0x1000>;
- interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_B_125>, <&clock CLK_B_125>;
clock-names = "uart", "clk_uart_baud0";
};
@@ -125,7 +127,7 @@
spi_0: spi at D0000 {
compatible = "samsung,exynos5440-spi";
reg = <0xD0000 0x100>;
- interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
samsung,spi-src-clk = <0>;
@@ -137,14 +139,14 @@
pin_ctrl: pinctrl at E0000 {
compatible = "samsung,exynos5440-pinctrl";
reg = <0xE0000 0x1000>;
- interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>,
- <0 38 IRQ_TYPE_LEVEL_HIGH>,
- <0 39 IRQ_TYPE_LEVEL_HIGH>,
- <0 40 IRQ_TYPE_LEVEL_HIGH>,
- <0 41 IRQ_TYPE_LEVEL_HIGH>,
- <0 42 IRQ_TYPE_LEVEL_HIGH>,
- <0 43 IRQ_TYPE_LEVEL_HIGH>,
- <0 44 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <2>;
#gpio-cells = <2>;
@@ -169,7 +171,7 @@
i2c at F0000 {
compatible = "samsung,exynos5440-i2c";
reg = <0xF0000 0x1000>;
- interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&clock CLK_B_125>;
@@ -179,7 +181,7 @@
i2c at 100000 {
compatible = "samsung,exynos5440-i2c";
reg = <0x100000 0x1000>;
- interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&clock CLK_B_125>;
@@ -189,7 +191,7 @@
watchdog at 110000 {
compatible = "samsung,s3c2410-wdt";
reg = <0x110000 0x1000>;
- interrupts = <0 1 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_B_125>;
clock-names = "watchdog";
};
@@ -198,7 +200,7 @@
compatible = "snps,dwmac-3.70a";
reg = <0x00230000 0x8000>;
interrupt-parent = <&gic>;
- interrupts = <0 31 4>;
+ interrupts = <GIC_SPI 31 4>;
interrupt-names = "macirq";
phy-mode = "sgmii";
clocks = <&clock CLK_GMAC0>;
@@ -216,8 +218,8 @@
rtc at 130000 {
compatible = "samsung,s3c6410-rtc";
reg = <0x130000 0x1000>;
- interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
- <0 16 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_B_125>;
clock-names = "rtc";
};
@@ -225,7 +227,7 @@
tmuctrl_0: tmuctrl at 160118 {
compatible = "samsung,exynos5440-tmu";
reg = <0x160118 0x230>, <0x160368 0x10>;
- interrupts = <0 58 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_B_125>;
clock-names = "tmu_apbif";
#include "exynos5440-tmu-sensor-conf.dtsi"
@@ -234,7 +236,7 @@
tmuctrl_1: tmuctrl at 16011C {
compatible = "samsung,exynos5440-tmu";
reg = <0x16011C 0x230>, <0x160368 0x10>;
- interrupts = <0 58 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_B_125>;
clock-names = "tmu_apbif";
#include "exynos5440-tmu-sensor-conf.dtsi"
@@ -243,7 +245,7 @@
tmuctrl_2: tmuctrl at 160120 {
compatible = "samsung,exynos5440-tmu";
reg = <0x160120 0x230>, <0x160368 0x10>;
- interrupts = <0 58 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_B_125>;
clock-names = "tmu_apbif";
#include "exynos5440-tmu-sensor-conf.dtsi"
@@ -267,7 +269,7 @@
sata at 210000 {
compatible = "snps,exynos5440-ahci";
reg = <0x210000 0x10000>;
- interrupts = <0 30 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_SATA>;
clock-names = "sata";
};
@@ -275,7 +277,7 @@
ohci at 220000 {
compatible = "samsung,exynos5440-ohci";
reg = <0x220000 0x1000>;
- interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_USB>;
clock-names = "usbhost";
};
@@ -283,7 +285,7 @@
ehci at 221000 {
compatible = "samsung,exynos5440-ehci";
reg = <0x221000 0x1000>;
- interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_USB>;
clock-names = "usbhost";
};
@@ -293,9 +295,9 @@
reg = <0x290000 0x1000
0x270000 0x1000
0x271000 0x40>;
- interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>,
- <0 21 IRQ_TYPE_LEVEL_HIGH>,
- <0 22 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_PR0_250_O>, <&clock CLK_PB0_250_O>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
@@ -316,9 +318,9 @@
reg = <0x2a0000 0x1000
0x272000 0x1000
0x271040 0x40>;
- interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>,
- <0 24 IRQ_TYPE_LEVEL_HIGH>,
- <0 25 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clock CLK_PR1_250_O>, <&clock CLK_PB0_250_O>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox