* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Marc Zyngier @ 2016-09-17 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6ucEH3w58Rhb8Urk0V5kRcqtUdwDYDtSLXrkas-Jatv=A@mail.gmail.com>
On Sat, 17 Sep 2016 11:58:48 +0530
Vijay Kilari <vijay.kilari@gmail.com> wrote:
> 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 you have two hosts (A and B), A having 5 bits of priority and B
having 7 bits, you should be able to migrate from A to B, and then from
B to A. Which means you have to preserve what the guest knows to be its
configuration, even if you run on a more capable system. Otherwise,
you're a bit stuck.
You probably won't be able to hide the discrepancy from inside the
guest though (the guest will be able to observe the change), but this
is better than nothing.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [RFT] arm64 dts: exynos: Fix invalid GIC interrupt flags in exynos7
From: Alim Akhtar @ 2016-09-17 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474056073-8071-1-git-send-email-krzk@kernel.org>
Hi Krzysztof,
On 09/17/2016 01:31 AM, Krzysztof Kozlowski wrote:
> Interrupt of type IRQ_TYPE_NONE is not allowed for GIC interrupts and
> generates an error:
> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x68)
>
> The GIC requires shared interrupts to be edge rising or level high.
> Platform declares support for both. Choose level high everywhere.
>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reported-by: Alban Browaeys <alban.browaeys@gmail.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
This patch does resolve the error reported in commit.
Have booted on exynos7 board, things looks fine (have not done a
extensive testing though).
With the _Typo_ fixed as pointed by you, feel free to add
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
On another note, please cc me if case you want to check/verify something
on exynos7 platform. I almost missed this patch.
Thanks.
> arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 20 +++++--
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 69 +++++++++++++------------
> 2 files changed, 51 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
> index f77ddaf21d04..983c63ba38c8 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
> @@ -20,8 +20,14 @@
> interrupt-controller;
> interrupt-parent = <&gic>;
> #interrupt-cells = <2>;
> - interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> - <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>;
> + interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
> + <0 1 IRQ_TYPE_LEVEL_HIGH>,
> + <0 2 IRQ_TYPE_LEVEL_HIGH>,
> + <0 3 IRQ_TYPE_LEVEL_HIGH>,
> + <0 4 IRQ_TYPE_LEVEL_HIGH>,
> + <0 5 IRQ_TYPE_LEVEL_HIGH>,
> + <0 6 IRQ_TYPE_LEVEL_HIGH>,
> + <0 7 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> gpa1: gpa1 {
> @@ -31,8 +37,14 @@
> interrupt-controller;
> interrupt-parent = <&gic>;
> #interrupt-cells = <2>;
> - interrupts = <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> - <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
> + interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
> + <0 9 IRQ_TYPE_LEVEL_HIGH>
> + <0 10 IRQ_TYPE_LEVEL_HIGH>,
> + <0 11 IRQ_TYPE_LEVEL_HIGH>,
> + <0 12 IRQ_TYPE_LEVEL_HIGH>,
> + <0 13 IRQ_TYPE_LEVEL_HIGH>,
> + <0 14 IRQ_TYPE_LEVEL_HIGH>,
> + <0 15 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> gpa2: gpa2 {
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 6328a66ed97e..0a80dabfbe95 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -106,7 +106,7 @@
> pdma0: pdma at 10E10000 {
> compatible = "arm,pl330", "arm,primecell";
> reg = <0x10E10000 0x1000>;
> - interrupts = <0 225 0>;
> + interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_fsys0 ACLK_PDMA0>;
> clock-names = "apb_pclk";
> #dma-cells = <1>;
> @@ -117,7 +117,7 @@
> pdma1: pdma at 10EB0000 {
> compatible = "arm,pl330", "arm,primecell";
> reg = <0x10EB0000 0x1000>;
> - interrupts = <0 226 0>;
> + interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_fsys0 ACLK_PDMA1>;
> clock-names = "apb_pclk";
> #dma-cells = <1>;
> @@ -220,7 +220,7 @@
> serial_0: serial at 13630000 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x13630000 0x100>;
> - interrupts = <0 440 0>;
> + interrupts = <0 440 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_peric0 PCLK_UART0>,
> <&clock_peric0 SCLK_UART0>;
> clock-names = "uart", "clk_uart_baud0";
> @@ -230,7 +230,7 @@
> serial_1: serial at 14c20000 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x14c20000 0x100>;
> - interrupts = <0 456 0>;
> + interrupts = <0 456 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_peric1 PCLK_UART1>,
> <&clock_peric1 SCLK_UART1>;
> clock-names = "uart", "clk_uart_baud0";
> @@ -240,7 +240,7 @@
> serial_2: serial at 14c30000 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x14c30000 0x100>;
> - interrupts = <0 457 0>;
> + interrupts = <0 457 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_peric1 PCLK_UART2>,
> <&clock_peric1 SCLK_UART2>;
> clock-names = "uart", "clk_uart_baud0";
> @@ -250,7 +250,7 @@
> serial_3: serial at 14c40000 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x14c40000 0x100>;
> - interrupts = <0 458 0>;
> + interrupts = <0 458 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_peric1 PCLK_UART3>,
> <&clock_peric1 SCLK_UART3>;
> clock-names = "uart", "clk_uart_baud0";
> @@ -264,62 +264,62 @@
> wakeup-interrupt-controller {
> compatible = "samsung,exynos7-wakeup-eint";
> interrupt-parent = <&gic>;
> - interrupts = <0 16 0>;
> + interrupts = <0 16 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> pinctrl_bus0: pinctrl at 13470000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x13470000 0x1000>;
> - interrupts = <0 383 0>;
> + interrupts = <0 383 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> pinctrl_nfc: pinctrl at 14cd0000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x14cd0000 0x1000>;
> - interrupts = <0 473 0>;
> + interrupts = <0 473 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> pinctrl_touch: pinctrl at 14ce0000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x14ce0000 0x1000>;
> - interrupts = <0 474 0>;
> + interrupts = <0 474 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> pinctrl_ff: pinctrl at 14c90000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x14c90000 0x1000>;
> - interrupts = <0 475 0>;
> + interrupts = <0 475 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> pinctrl_ese: pinctrl at 14ca0000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x14ca0000 0x1000>;
> - interrupts = <0 476 0>;
> + interrupts = <0 476 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> pinctrl_fsys0: pinctrl at 10e60000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x10e60000 0x1000>;
> - interrupts = <0 221 0>;
> + interrupts = <0 221 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> pinctrl_fsys1: pinctrl at 15690000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x15690000 0x1000>;
> - interrupts = <0 203 0>;
> + interrupts = <0 203 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> pinctrl_bus1: pinctrl at 14870000 {
> compatible = "samsung,exynos7-pinctrl";
> reg = <0x14870000 0x1000>;
> - interrupts = <0 384 0>;
> + interrupts = <0 384 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> hsi2c_0: hsi2c at 13640000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x13640000 0x1000>;
> - interrupts = <0 441 0>;
> + interrupts = <0 441 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -332,7 +332,7 @@
> hsi2c_1: hsi2c at 13650000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x13650000 0x1000>;
> - interrupts = <0 442 0>;
> + interrupts = <0 442 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -345,7 +345,7 @@
> hsi2c_2: hsi2c at 14e60000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x14e60000 0x1000>;
> - interrupts = <0 459 0>;
> + interrupts = <0 459 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -358,7 +358,7 @@
> hsi2c_3: hsi2c at 14e70000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x14e70000 0x1000>;
> - interrupts = <0 460 0>;
> + interrupts = <0 460 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -371,7 +371,7 @@
> hsi2c_4: hsi2c at 13660000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x13660000 0x1000>;
> - interrupts = <0 443 0>;
> + interrupts = <0 443 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -384,7 +384,7 @@
> hsi2c_5: hsi2c at 13670000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x13670000 0x1000>;
> - interrupts = <0 444 0>;
> + interrupts = <0 444 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -397,7 +397,7 @@
> hsi2c_6: hsi2c at 14e00000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x14e00000 0x1000>;
> - interrupts = <0 461 0>;
> + interrupts = <0 461 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -410,7 +410,7 @@
> hsi2c_7: hsi2c at 13e10000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x13e10000 0x1000>;
> - interrupts = <0 462 0>;
> + interrupts = <0 462 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -423,7 +423,7 @@
> hsi2c_8: hsi2c at 14e20000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x14e20000 0x1000>;
> - interrupts = <0 463 0>;
> + interrupts = <0 463 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -436,7 +436,7 @@
> hsi2c_9: hsi2c at 13680000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x13680000 0x1000>;
> - interrupts = <0 445 0>;
> + interrupts = <0 445 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -449,7 +449,7 @@
> hsi2c_10: hsi2c at 13690000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x13690000 0x1000>;
> - interrupts = <0 446 0>;
> + interrupts = <0 446 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -462,7 +462,7 @@
> hsi2c_11: hsi2c at 136a0000 {
> compatible = "samsung,exynos7-hsi2c";
> reg = <0x136a0000 0x1000>;
> - interrupts = <0 447 0>;
> + interrupts = <0 447 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -499,7 +499,8 @@
> rtc: rtc at 10590000 {
> compatible = "samsung,s3c6410-rtc";
> reg = <0x10590000 0x100>;
> - interrupts = <0 355 0>, <0 356 0>;
> + interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>,
> + <0 356 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_ccore PCLK_RTC>;
> clock-names = "rtc";
> status = "disabled";
> @@ -508,7 +509,7 @@
> watchdog: watchdog at 101d0000 {
> compatible = "samsung,exynos7-wdt";
> reg = <0x101d0000 0x100>;
> - interrupts = <0 110 0>;
> + interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_peris PCLK_WDT>;
> clock-names = "watchdog";
> samsung,syscon-phandle = <&pmu_system_controller>;
> @@ -517,7 +518,7 @@
>
> mmc_0: mmc at 15740000 {
> compatible = "samsung,exynos7-dw-mshc-smu";
> - interrupts = <0 201 0>;
> + interrupts = <0 201 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x15740000 0x2000>;
> @@ -530,7 +531,7 @@
>
> mmc_1: mmc at 15750000 {
> compatible = "samsung,exynos7-dw-mshc";
> - interrupts = <0 202 0>;
> + interrupts = <0 202 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x15750000 0x2000>;
> @@ -543,7 +544,7 @@
>
> mmc_2: mmc at 15560000 {
> compatible = "samsung,exynos7-dw-mshc-smu";
> - interrupts = <0 216 0>;
> + interrupts = <0 216 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x15560000 0x2000>;
> @@ -557,7 +558,7 @@
> adc: adc at 13620000 {
> compatible = "samsung,exynos7-adc";
> reg = <0x13620000 0x100>;
> - interrupts = <0 448 0>;
> + interrupts = <0 448 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_peric0 PCLK_ADCIF>;
> clock-names = "adc";
> #io-channel-cells = <1>;
> @@ -577,7 +578,7 @@
> tmuctrl_0: tmu at 10060000 {
> compatible = "samsung,exynos7-tmu";
> reg = <0x10060000 0x200>;
> - interrupts = <0 108 0>;
> + interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clock_peris PCLK_TMU>,
> <&clock_peris SCLK_TMU>;
> clock-names = "tmu_apbif", "tmu_sclk";
>
^ permalink raw reply
* [PATCH] musb: Export musb_root_disconnect for use in modules
From: Greg Kroah-Hartman @ 2016-09-17 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9e474920-2ebd-8d38-7c7b-d8e894dc2568@redhat.com>
On Sat, Sep 17, 2016 at 12:12:04PM +0200, Hans de Goede wrote:
> Hi,
>
> On 16-09-16 17:56, Greg Kroah-Hartman wrote:
> > On Fri, Sep 16, 2016 at 04:53:17PM +0100, Mark Brown wrote:
> > > On Fri, Sep 16, 2016 at 05:47:01PM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Sep 16, 2016 at 04:59:36PM +0200, Hans de Goede wrote:
> > >
> > > > > +EXPORT_SYMBOL_GPL(musb_root_disconnect);
> > >
> > > > Does this fix a build error somehow? Who reported it?
> > >
> > > Yes, the sunxi driver uses this symbol and the build bots reported it
> > > yesterday.
> >
> > then all of that should have been in this patch :(
> >
> > So much for me trying to be subtle...
>
> Sorry, you're right, I'll add a Fixes tag, and I'll mention
> this fixes a buildbot reported error too.
>
> I'll do a v2 with this right away.
>
> For the next time, is there any official format to
> mention the buildbot report or some such ?
like normal:
"Reported-by: ...."
^ permalink raw reply
* [PATCH] musb: Export musb_root_disconnect for use in modules
From: Hans de Goede @ 2016-09-17 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916155608.GA31257@kroah.com>
Hi,
On 16-09-16 17:56, Greg Kroah-Hartman wrote:
> On Fri, Sep 16, 2016 at 04:53:17PM +0100, Mark Brown wrote:
>> On Fri, Sep 16, 2016 at 05:47:01PM +0200, Greg Kroah-Hartman wrote:
>>> On Fri, Sep 16, 2016 at 04:59:36PM +0200, Hans de Goede wrote:
>>
>>>> +EXPORT_SYMBOL_GPL(musb_root_disconnect);
>>
>>> Does this fix a build error somehow? Who reported it?
>>
>> Yes, the sunxi driver uses this symbol and the build bots reported it
>> yesterday.
>
> then all of that should have been in this patch :(
>
> So much for me trying to be subtle...
Sorry, you're right, I'll add a Fixes tag, and I'll mention
this fixes a buildbot reported error too.
I'll do a v2 with this right away.
For the next time, is there any official format to
mention the buildbot report or some such ?
Regards,
Hans
^ permalink raw reply
* [PATCH v2] musb: Export musb_root_disconnect for use in modules
From: Hans de Goede @ 2016-09-17 10:08 UTC (permalink / raw)
To: linux-arm-kernel
Export musb_root_disconnect for use in modules, so that musb glue
code build as module can use it.
This fixes the buildbot errors for -next in arm64-allmodconfig
and arm-allmodconfig.
Fixes: 7cba17ec9adc8cf ("musb: sunxi: Add support for platform_set_mode")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Add Fixes tag and buildbot reference to the commit msg
---
drivers/usb/musb/musb_virthub.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index fe08e77..61b5f1c 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -245,6 +245,7 @@ void musb_root_disconnect(struct musb *musb)
usb_otg_state_string(musb->xceiv->otg->state));
}
}
+EXPORT_SYMBOL_GPL(musb_root_disconnect);
/*---------------------------------------------------------------------*/
--
2.9.3
^ permalink raw reply related
* [PATCH 2/5] mmc: bcm2835-sdhost: Add new driver for the internal SD controller.
From: Ulf Hansson @ 2016-09-17 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877falaq1q.fsf@eliezer.anholt.net>
On 9 September 2016 at 20:25, Eric Anholt <eric@anholt.net> wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
>> On Mi, 2016-08-31 at 14:58 +0200, Ulf Hansson wrote:
>>> On 22 June 2016 at 13:42, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>> > From: Eric Anholt <eric@anholt.net>
>>> >
>>> > The 2835 has two SD controllers: The Arasan SDHCI controller that we
>>> > currently use, and a custom SD controller. The custom one runs faster
>>> >
>>> > The code was originally written by Phil Elwell in the downstream
>>> > Rasbperry Pi tree, and I did a major cleanup on it (+319, -707 lines
>>> > out of the original 2055) for inclusion.
>>> >
>>> > Signed-off-by: Eric Anholt <eric@anholt.net>
>>>
>>> Apologize for the delay!
>>
>> No problem, I was on summer vacation anyway ...
>>
>>> Could you start by providing some more information about the driver
>>> and the controller in change in the change log please.
>>
>> Eric? I don't know much more than what the commit message above says.
>>
>> Beside the speedup mentioned above driving the sdcard with the custom sd
>> controller allows to use the sdhci (handled by sdhci-iproc) to be used
>> for the wifi on the rpi3.
>
> Maybe just add that we need both controllers in order to do both wifi
> and SD card? I don't know exactly what Ulf wants to see here.
Some toplevel description of the controller. Like what speed modes it
supports, can it do SD/SDIO/eMMC and so forth.
>
>>> > +static void bcm2835_sdhost_set_power(struct bcm2835_host *host, bool on)
>>> > +{
>>> > + bcm2835_sdhost_write(host, on ? 1 : 0, SDVDD);
>>>
>>> What exactly does this power on/off?
>>
>> Dunno. Eric?
>
> Note: I don't know much about SD, so I'm just trying to play oracle for
> you all here.
>
> VDD bit 0 (POWER_ON) starts the power-on setup cycle by the sdhost once
> power is already supplied to the card by some other means. In the
> SDHOST docs they assume you're going to use GPIO to control SD card
> power, but for Raspberry Pi they just have the SD Card's VDD always on.
> It's unclear to me what's controlling power to the Pi3 wifi/BT's SD
> client, but I don't have specs to it.
Very useful information, could we fold something like this in as
comment in the code!?
>
> Note that after you've set POWER_ON to 0, you can also set bit 1
> (CLOCK_OFF) to 1 to turn off the clock to the power-on FSM.
Ditto.
>
>>> > + /* Need to send CMD12 if -
>>> > + * a) open-ended multiblock transfer (no CMD23)
>>> > + * b) error in multiblock transfer
>>> > + */
>>> > + if (host->mrq->stop && (data->error || !host->use_sbc)) {
>>> > + if (bcm2835_sdhost_send_command(host, host->mrq->stop)) {
>>> > + /* No busy, so poll for completion */
>>> > + if (!host->use_busy)
>>>
>>> This looks a bit weird. Can you explain why this is needed?
>>
>> Eric, any clue? Some hardware bug workaround?
>> Have a pointer to hardware specs?
>
> Would no-CMD23 transfers mean that data->blocks was 0 to mean
> indefinite? That's the only mention of CMD12 in the spec -- when you've
> set HBLC to 0, you need to CMD12 or CMD52 when you're done with the
> transfer.
Perhaps you are right, although the comments above is weird.
The driver should check if it's a request with R1B response, as to
find out when to care about busy detection. I have feeling that there
might be some odd things going on in this driver related to this. I
could be wrong through.
I advised Gerd to have a look how MMC_CAP_WAIT_WHILE_BUSY is working,
so perhaps Gerd can figure this out when he understands that part
better!?
>
>>> > +static void bcm2835_sdhost_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>> > +{
>>>
>>> I don't find any place where you control power to the card here. Don't
>>> you need to do that?
>>
>> Eric?
>
> It looks like the card is always powered. Do you mean something else by
> power (like bringing up the FSM)? Is there something else needed in
> set_ios()?
As you told me above, you are using an external regulator to power the
card (VDD). And it seems like in this particular case this is always
powered on.
Still, my recommendation is to model this as a regulator, as it would
prevent you from hard-coding the so called mmc->ocr_mask_avail.
Instead that mask can be fetched by checking the supported voltage
levels from the regulators.
Please have a look at mmc_regulator_get_supply() and
mmc_regulator_set_ocr(), those helpers are really convenient to use.
You should be using the "vmmc" regulator for this purpose.
Kind regards
Uffe
^ permalink raw reply
* [PATCH v3 1/3] tty: amba-pl011: define flag register bits for ZTE device
From: Russell King - ARM Linux @ 2016-09-17 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917053753.GG7398@tiger>
On Sat, Sep 17, 2016 at 01:37:53PM +0800, Shawn Guo wrote:
> 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.
Well, it's turning out that handling ZTE in PL011 is turning into a
bad idea as well - we keep getting these breakages each time we try.
I think ZTE is sufficiently different from PL011 with the different
register layout _and_ the different bits, _and_ the pain that this
is causing, that it should have been a separate driver.
The only way I can think of dealing with the console issue is to
replicate the console code, once for the PL011 variant and then
again for the ZTE variant. We can't _both_ give them the same names
_and_ register them together - we either have to give them different
names, which makes it confusing because one name won't match the
userspace name for the UART, or we need the driver to detect the
port type early. That's made much more difficult because ZTE didn't
bother with the ID registers, unlike every other vendor.
Serial drivers are not that complex anymore, compared to how they
were back before serial_core happened, so having it as a separate
driver isn't that big a deal.
--
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 3/3] arm: dts: imx6qdl-wandboard-revb: Fix "ERROR: trailing whitespace"
From: Jagan Teki @ 2016-09-17 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474098926-5236-1-git-send-email-jagan@amarulasolutions.com>
From: Jagan Teki <jteki@openedev.com>
Fixed error in trailing whitespace in wandboard-rev1 dtsi.
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
---
arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi
index ef7fa62..a320891 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi
@@ -28,7 +28,7 @@
MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x80000000 /* RGMII_nRST */
MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x80000000 /* BT_ON */
MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x80000000 /* BT_WAKE */
- MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x80000000 /* BT_HOST_WAKE */
+ MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x80000000 /* BT_HOST_WAKE */
>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"
From: Jagan Teki @ 2016-09-17 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474098926-5236-1-git-send-email-jagan@amarulasolutions.com>
From: Jagan Teki <jteki@openedev.com>
Fixed code indent tabs in respetcive imx6qdl dtsi files.
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
---
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 6 +++---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 6 +++---
8 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index a7100f9..54aca3a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -153,9 +153,9 @@
&clks {
assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
- <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
- <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
};
&ecspi3 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 8953eba..88e5cb3 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -154,9 +154,9 @@
&clks {
assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
- <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
- <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
};
&fec {
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 6ac41c7..1753ab7 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -144,9 +144,9 @@
&clks {
assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
- <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
- <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
};
&fec {
diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
index 805e236..ee83161 100644
--- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
@@ -291,7 +291,7 @@
MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
>;
- };
+ };
pinctrl_wdog: wdoggrp {
fsl,pins = <
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index e0280cac2..e9801a2 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -427,10 +427,10 @@
};
&usdhc3 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usdhc3
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3
&pinctrl_usdhc3_cdwp>;
cd-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
- status = "disabled";
+ status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index e000e6f..8006467 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -283,7 +283,7 @@
VD-supply = <®_audio>;
VLS-supply = <®_audio>;
VLC-supply = <®_audio>;
- };
+ };
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 8e9e0d9..55ef535 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -129,8 +129,8 @@
pinctrl-0 = <&pinctrl_gpio_leds>;
red {
- gpios = <&gpio1 2 0>;
- default-state = "on";
+ gpios = <&gpio1 2 0>;
+ default-state = "on";
};
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b13b0b2..1bbd36f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -204,9 +204,9 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &gpc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &gpc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &gpc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &gpc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+ <0 0 0 2 &gpc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gpc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gpc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_PCIE_AXI>,
<&clks IMX6QDL_CLK_LVDS1_GATE>,
<&clks IMX6QDL_CLK_PCIE_REF_125M>;
--
2.7.4
^ permalink raw reply related
* [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
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