* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Sean Wang @ 2018-05-08 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D474053D-6910-4B04-8B98-59B96FEB86BC@holtmann.org>
Hi, Marcel
On Tue, 2018-05-08 at 09:27 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>> +
> >>> +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 plen,
> >>> + const void *param)
> >>> +{
> >>> + struct mtk_bt_dev *btdev = hu->priv;
> >>> + struct hci_command_hdr *hhdr;
> >>> + struct hci_acl_hdr *ahdr;
> >>> + struct mtk_wmt_hdr *whdr;
> >>> + struct sk_buff *skb;
> >>> + int ret = 0;
> >>> +
> >>> + init_completion(&btdev->wmt_cmd);
> >>> +
> >>> + skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
> >>> + if (!skb)
> >>> + return -ENOMEM;
> >>> +
> >>> + /*
> >>> + * WMT data is carried in either ACL or HCI format with op code as
> >>> + * 0xfc6f and followed by a WMT header and its actual payload.
> >>> + */
> >>
> >> Please use net subsystem comment style.
> >>
> >>> + switch (opcode) {
> >>> + case MTK_WMT_PATCH_DWNLD:
> >>> + ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
> >>> + ahdr->handle = cpu_to_le16(0xfc6f);
> >>> + ahdr->dlen = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
> >>> + break;
> >>> + default:
> >>> + hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
> >>> + hhdr->opcode = cpu_to_le16(0xfc6f);
> >>> + hhdr->plen = plen + MTK_WMT_HDR_SIZE;
> >>> + break;
> >>> + }
> >>> +
> >>> + hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
> >>> + HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
> >>
> >> Why not move that into the switch statement above.
> >>
> >>> +
> >>> + /* Start to build a WMT header and its actual payload. */
> >>> + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
> >>> + whdr->dir = 1;
> >>> + whdr->op = opcode;
> >>> + whdr->dlen = cpu_to_le16(plen + 1);
> >>> + whdr->flag = flag;
> >>> + skb_put_data(skb, param, plen);
> >>> +
> >>> + mtk_enqueue(hu, skb);
> >>> + hci_uart_tx_wakeup(hu);
> >>> +
> >>> + /*
> >>> + * Waiting a WMT event response, while we must take care in case of
> >>> + * failures for the wait.
> >>> + */
> >>> + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
> >>> +
> >>> + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
> >>> +}
> >>
> >> All in all I am not convinced that this is super clean. I get that we need something special for having this in the ACL data packets, but for the standard HCI command I prefer that __hci_cmd_sync is used. I addition, it seems that patch download is the only special case and that happens before at the setup stage. So we could make things special for that. I need to understand this a bit better. Can I get a btmon -w trace.log file from the whole init procedure.
> >>
> >
> > While i was trying to rewrite the driver based on btuart.c. you posted
> > on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
> > hci command sending which I've done previously with mtk_wmt_cmd_sync.
> >
> > However, eventually, I got a cmd_timer timeout whose message printed
> > on console as "Bluetooth: hci0: command 0xfc6f tx timeout".
> >
> > The mtk soc specific cmd/event I posted below, I dumped directly in
> > driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.
> >
> > It appears to the event id is not standard and thus it cannot cancel the
> > cmd timer when the special hci event is being handled. This way can we
> > can still use __hci_cmd_sync api ?
> >
> > [ 4.896200] hci tx: 00000000: 01 6f fc 05 01 07 01 00 04
> > [ 4.904671] hci rx: 00000000: e4 05 02 07 01 00
> > 00
> > [ 4.912859] Bluetooth: hci0 event 0xe4
> >
> >
> > buildroot login: [ 6.914509] Bluetooth: hci0: command 0xfc6f tx
> > timeout
> > [ 6.919831] hci tx: 00000000: 01 6f fc 06 01 06 02 00 00
> > 01 .o........
> > [ 7.006631] hci rx: 00000000: e4 05 02 06 01 00
> > 00 .......
> > [ 7.014821] Bluetooth: hci0 event 0xe4
>
> can you just start btmon before loading the module / driver? It makes it a lot easier since it will actually decode the basics for us. If there is a bug within __hci_cmd_sync_ev, then we are going to fix it.
>
I'm happy to do with btmon. just the environment with buildroot the BT
running on seems there's a missing support for btmon. I can start to use
btmon once I change the environment to Debian.
> So all the MTK vendor commands respond with a vendor event? Or are there some that do the standard command status/complete handling?
>
yes, mtk controller after mt7622 (included), its MTK vendors command
(opcode 0xfc6f) always respond with a vendor event id 0xe4. And they
don't do any standard status/complete handling.
BTW, mtk controller before mt7622, such as mt7623, its MTK vendor
command always go with completely specific format, not with hci format.
> Regards
>
> Marcel
>
^ permalink raw reply
* [PATCH 4.14 42/43] irqchip/qcom: Fix check for spurious interrupts
From: Greg Kroah-Hartman @ 2018-05-08 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508074003.984433784@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
^ permalink raw reply
* [PATCH 4.16 48/52] irqchip/qcom: Fix check for spurious interrupts
From: Greg Kroah-Hartman @ 2018-05-08 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508073928.058320984@linuxfoundation.org>
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
^ permalink raw reply
* [PATCH v9 07/12] ARM: sunxi: Add initialization of CNTVOFF
From: Marc Zyngier @ 2018-05-08 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504190545.5114-8-mylene.josserand@bootlin.com>
On 04/05/18 20:05, Myl?ne Josserand wrote:
> Add the initialization of CNTVOFF for sun8i-a83t.
>
> For boot CPU, create a new machine that handles this
> function's call in an "init_early" callback. We need to initialize
> CNTVOFF before the arch timer's initialization otherwise, it will
> not be taken into account and fails to boot correctly.
> Because of that, this function can't be called in SMP's early_initcall
> function which is called after timer's init.
>
> For secondary CPUs, add this function into secondary_startup
> assembly entry.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v9 06/12] ARM: smp: Add initialization of CNTVOFF
From: Marc Zyngier @ 2018-05-08 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504190545.5114-7-mylene.josserand@bootlin.com>
On 04/05/18 20:05, Myl?ne Josserand wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value meaning that each CPU will have a
> different time, which isn't working very well.
>
> Add assembly code used for boot CPU and secondary CPU cores to make
> sure that the CNTVOFF register is initialized. Because this code can
> be used by different platforms, add this assembly file in ARM's common
> folder.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@bootlin.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PACTCH v5 1/2] ARM: dts: imx: Add basic dtsi file for imx6sll
From: Jacky Bai @ 2018-05-08 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502065513.GA3443@dragon>
> Subject: Re: [PACTCH v5 1/2] ARM: dts: imx: Add basic dtsi file for imx6sll
>
> On Fri, Apr 13, 2018 at 04:01:03PM +0800, Bai Ping wrote:
> > Add dtsi file for imx6sll.
> >
> > Signed-off-by: Bai Ping <ping.bai@nxp.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > change v3->v4
> > - update the license indentifier
> > - remove leading zeros of node
> > - move pin header to this patch
> > change v4->v5
> > - use generic name for device node
> > ---
> > arch/arm/boot/dts/imx6sll-pinfunc.h | 880
> ++++++++++++++++++++++++++++++++++++
> > arch/arm/boot/dts/imx6sll.dtsi | 802
> ++++++++++++++++++++++++++++++++
> > 2 files changed, 1682 insertions(+)
> > create mode 100644 arch/arm/boot/dts/imx6sll-pinfunc.h
> > create mode 100644 arch/arm/boot/dts/imx6sll.dtsi
>
> <snip>
>
> > +
> > + epit1: epit at 20d0000 {
> > + reg = <0x020d0000 0x4000>;
> > + interrupts = <GIC_SPI 56
> IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +
> > + epit2: epit at 20d4000 {
> > + reg = <0x020d4000 0x4000>;
> > + interrupts = <GIC_SPI 57
> IRQ_TYPE_LEVEL_HIGH>;
> > + };
>
> 'timer' for node name. If these devices are not used, I would even suggest
> to drop them.
>
ok, will drop these node.
> > +
> > + src: reset-controller at 20d8000 {
> > + compatible = "fsl,imx6sll-src";
> > + reg = <0x020d8000 0x4000>;
> > + interrupts = <GIC_SPI 91
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 96
> IRQ_TYPE_LEVEL_HIGH>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + gpc: interrupt-controller at 20dc000 {
> > + compatible = "fsl,imx6sll-gpc", "fsl,imx6q-
> gpc";
> > + reg = <0x020dc000 0x4000>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + interrupts = <GIC_SPI 89
> IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-parent = <&intc>;
> > + fsl,mf-mix-wakeup-irq = <0x7c00000 0x7d00
> 0x0 0x1400640>;
> > + };
> > +
> > + iomuxc: pinctrl at 20e0000 {
> > + compatible = "fsl,imx6sll-iomuxc";
> > + reg = <0x020e0000 0x4000>;
> > + };
> > +
> > + gpr: iomuxc-gpr at 20e4000 {
> > + compatible = "fsl,imx6sll-iomuxc-gpr",
> > + "fsl,imx6q-iomuxc-gpr", "syscon";
> > + reg = <0x020e4000 0x4000>;
> > + };
> > +
> > + csi: csi at 20e8000 {
> > + compatible = "fsl,imx6sll-csi", "fsl,imx6s-csi";
> > + reg = <0x020e8000 0x4000>;
> > + interrupts = <GIC_SPI 7
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_DUMMY>,
> > + <&clks IMX6SLL_CLK_CSI>,
> > + <&clks IMX6SLL_CLK_DUMMY>;
> > + clock-names = "disp-axi", "csi_mclk",
> "disp_dcic";
> > + status = "disabled";
> > + };
> > +
> > + sdma: dma-controller at 20ec000 {
> > + compatible = "fsl,imx6sll-sdma", "fsl,imx35-
> sdma";
> > + reg = <0x020ec000 0x4000>;
> > + interrupts = <GIC_SPI 2
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_SDMA>,
> > + <&clks IMX6SLL_CLK_SDMA>;
> > + clock-names = "ipg", "ahb";
> > + #dma-cells = <3>;
> > + iram = <&ocram>;
> > + fsl,sdma-ram-script-name =
> "imx/sdma/sdma-imx6q.bin";
> > + };
> > +
> > + lcdif: lcd-controller at 20f8000 {
> > + compatible = "fsl,imx6sll-lcdif", "fsl,imx28-
> lcdif";
> > + reg = <0x020f8000 0x4000>;
> > + interrupts = <GIC_SPI 39
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_LCDIF_PIX>,
> > + <&clks IMX6SLL_CLK_LCDIF_APB>,
> > + <&clks IMX6SLL_CLK_DUMMY>;
> > + clock-names = "pix", "axi", "disp_axi";
> > + status = "disabled";
> > + };
> > +
> > + dcp: dcp at 20fc000 {
> > + compatible = "fsl,imx6sl-dcp";
>
> Is the compatible supported/documented?
It is compatible with imx28, I will change this compatible to " fsl,imx28-dcp "
>
> > + reg = <0x020fc000 0x4000>;
> > + interrupts = <GIC_SPI 99
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 100
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 101
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_DCP>;
> > + clock-names = "dcp";
> > + };
> > + };
> > +
> > + aips2: aips-bus at 2100000 {
> > + compatible = "fsl,aips-bus", "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0x02100000 0x100000>;
> > + ranges;
> > +
> > + usbotg1: usb at 2184000 {
> > + compatible = "fsl,imx6sll-usb", "fsl,imx6ul-
> usb",
> > + "fsl,imx27-usb";
> > + reg = <0x02184000 0x200>;
> > + interrupts = <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USBOH3>;
> > + fsl,usbphy = <&usbphy1>;
> > + fsl,usbmisc = <&usbmisc 0>;
> > + fsl,anatop = <&anatop>;
> > + ahb-burst-config = <0x0>;
> > + tx-burst-size-dword = <0x10>;
> > + rx-burst-size-dword = <0x10>;
> > + status = "disabled";
> > + };
> > +
> > + usbotg2: usb at 2184200 {
> > + compatible = "fsl,imx6sll-usb", "fsl,imx6ul-
> usb",
> > + "fsl,imx27-usb";
> > + reg = <0x02184200 0x200>;
> > + interrupts = <GIC_SPI 42
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USBOH3>;
> > + fsl,usbphy = <&usbphy2>;
> > + fsl,usbmisc = <&usbmisc 1>;
> > + ahb-burst-config = <0x0>;
> > + tx-burst-size-dword = <0x10>;
> > + rx-burst-size-dword = <0x10>;
> > + status = "disabled";
> > + };
> > +
> > + usbmisc: usbmisc at 2184800 {
> > + #index-cells = <1>;
> > + compatible = "fsl,imx6sll-usbmisc",
> "fsl,imx6ul-usbmisc",
> > + "fsl,imx6q-usbmisc";
> > + reg = <0x02184800 0x200>;
> > + };
> > +
> > + usdhc1: mmc at 2190000 {
> > + compatible = "fsl,imx6sll-usdhc", "fsl,imx6sx-
> usdhc";
> > + reg = <0x02190000 0x4000>;
> > + interrupts = <GIC_SPI 22
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USDHC1>,
> > + <&clks IMX6SLL_CLK_USDHC1>,
> > + <&clks IMX6SLL_CLK_USDHC1>;
> > + clock-names = "ipg", "ahb", "per";
> > + bus-width = <4>;
> > + fsl,tuning-step = <2>;
> > + fsl,tuning-start-tap = <20>;
> > + status = "disabled";
> > + };
> > +
> > + usdhc2: mmc at 2194000 {
> > + compatible = "fsl,imx6sll-usdhc", "fsl,imx6sx-
> usdhc";
> > + reg = <0x02194000 0x4000>;
> > + interrupts = <GIC_SPI 23
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USDHC2>,
> > + <&clks IMX6SLL_CLK_USDHC2>,
> > + <&clks IMX6SLL_CLK_USDHC2>;
> > + clock-names = "ipg", "ahb", "per";
> > + bus-width = <4>;
> > + fsl,tuning-step = <2>;
> > + fsl,tuning-start-tap = <20>;
> > + status = "disabled";
> > + };
> > +
> > + usdhc3: mmc at 2198000 {
> > + compatible = "fsl,imx6sll-usdhc", "fsl,imx6sx-
> usdhc";
> > + reg = <0x02198000 0x4000>;
> > + interrupts = <GIC_SPI 24
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_USDHC3>,
> > + <&clks IMX6SLL_CLK_USDHC3>,
> > + <&clks IMX6SLL_CLK_USDHC3>;
> > + clock-names = "ipg", "ahb", "per";
> > + bus-width = <4>;
> > + fsl,tuning-step = <2>;
> > + fsl,tuning-start-tap = <20>;
> > + status = "disabled";
> > + };
> > +
> > + i2c1: i2c at 21a0000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fs,imx6sll-i2c", "fsl,imx21-i2c";
> > + reg = <0x021a0000 0x4000>;
> > + interrupts = <GIC_SPI 36
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_I2C1>;
> > + status = "disabled";
> > + };
> > +
> > + i2c2: i2c at 21a4000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx6sll-i2c", "fsl,imx21-i2c";
> > + reg = <0x021a4000 0x4000>;
> > + interrupts = <GIC_SPI 37
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_I2C2>;
> > + status = "disabled";
> > + };
> > +
> > + i2c3: i2c at 21a8000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx6sll-i2c", "fsl,imx21-i2c";
> > + reg = <0x021a8000 0x4000>;
> > + interrupts = <GIC_SPI 38
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_I2C3>;
> > + status = "disabled";
> > + };
> > +
> > + romcp at 21ac000 {
> > + compatible = "fsl,imx6sll-romcp", "syscon";
>
> The compatible "fsl,imx6sll-romcp" is undocumented. If the device is not
> used by upstream kernel, I would even suggest to drop it.
Ok, will drop it.
>
> > + reg = <0x021ac000 0x4000>;
> > + };
> > +
> > + mmdc: memory-controller at 21b0000 {
> > + compatible = "fsl,imx6sll-mmdc", "fsl,imx6q-
> mmdc";
> > + reg = <0x021b0000 0x4000>;
> > + };
> > +
> > + rngb: rngb at 21b4000 {
>
> Is the device used at all?
will drop it.
>
> > + reg = <0x021b4000 0x4000>;
> > + interrupts = <GIC_SPI 5
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX6SLL_CLK_DUMMY>;
> > + };
> > +
> > + ocotp: ocotp-ctrl at 21bc000 {
> > + compatible = "fsl,imx6sll-ocotp", "syscon";
> > + reg = <0x021bc000 0x4000>;
> > + clocks = <&clks IMX6SLL_CLK_OCOTP>;
> > + };
> > +
> > + snvs_gpr: snvs-gpr at 21c4000 {
> > + reg = <0x021c4000 0x10000>;
> > + };
>
> Ditto
>
> > +
> > + iomuxc_snvs: iomuxc-snvs at 21c8000 {
> > + reg = <0x021c8000 0x10000>;
> > + };
>
> Ditto
>
Ok. Will drop these two.
> Shawn
>
> > +
> > + audmux: audmux at 21d8000 {
> > + compatible = "fsl,imx6sll-audmux",
> "fsl,imx31-audmux";
> > + reg = <0x021d8000 0x4000>;
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial at 21f4000 {
> > + compatible = "fsl,imx6sll-uart", "fsl,imx6q-
> uart",
> > + "fsl,imx21-uart";
> > + reg = <0x021f4000 0x4000>;
> > + interrupts =<GIC_SPI 30
> IRQ_TYPE_LEVEL_HIGH>;
> > + dmas = <&sdma 33 4 0>, <&sdma 34 4 0>;
> > + dma-names = "rx", "tx";
> > + clocks = <&clks IMX6SLL_CLK_UART5_IPG>,
> > + <&clks
> IMX6SLL_CLK_UART5_SERIAL>;
> > + clock-names = "ipg", "per";
> > + status = "disabled";
> > + };
> > + };
> > + };
> > +};
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Daniel Vetter @ 2018-05-08 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7f79c109-6b0f-000e-569b-1f702e0006d3@axentia.se>
On Mon, May 07, 2018 at 04:24:43PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:59, Peter Rosin wrote:
> > On 2018-05-07 15:39, Daniel Vetter wrote:
> >> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >>> On 2018-05-03 11:06, Daniel Vetter wrote:
> >>>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >>>>> The more natural approach would perhaps be to add an drm_bridge_add,
> >>>>> but there are several other bridges that never call drm_bridge_add.
> >>>>> Just removing the drm_bridge_remove is the easier fix.
> >>>>>
> >>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
> >>>>
> >>>> This mess is much bigger. There's 2 pairs of bridge functions:
> >>>>
> >>>> - drm_bridge_attach/detach. Those are meant to be called by the overall
> >>>> drm driver to connect/disconnect a drm_bridge.
> >>>>
> >>>> - drm_bridge_add/remove. These are supposed to be called by the bridge
> >>>> driver itself to register/unregister itself. Maybe we should rename
> >>>> them, since the same issue happens with drm_panel, with the same
> >>>> confusion.
> >>>>
> >>>> I thought someone was working on a cleanup series to fix this mess, but I
> >>>> didn't find anything.
> >>>
> >>> Ok, I just spotted the imbalance and didn't really dig into what
> >>> actually happens in these error paths. Now that I have done so I
> >>> believe that the removed drm_bridge_remove calls causes NULL
> >>> dereferences if/when the error paths are triggered.
> >>>
> >>> So, I don't think this can wait for some bigger cleanup.
> >>>
> >>> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> >>> __list_del with NULL in both prev and next since the list member
> >>> is never initialized. prev and next are dereferenced by __list_del
> >>> and you have *boom*
> >>>
> >>> I recommend adding the tag
> >>>
> >>> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> >>>
> >>> so that stable picks this one up.
> >>
> >> I just wanted to correct your commit message text - the correct solution
> >> is definitely _not_ for sti here to call drm_bridge_add.
> >
> > Ah, I see what you mean. Do you want me to respin?
>
> Hold on, no I don't agree. sti_hda.c does create a bridge for it's own
> internal use. It does not drm_bridge_add it, because all that ever does
> is adding the bridge to the global lost of bridges. But since this is
> a bridge for internal use, there is little point in calling drm_bridge_add,
> the driver currently gains nothing by doing so.
>
> But, drm_bridge_add might be a good place to put common stuff for every
> bridge in the system, so it might be worthwhile to start requiring all
> bridges to be drm_bridge_add-ed. And IMHO, it would not be wrong to have
> the sti-hda driver call drm_bridge_add on the bridge it creates.
>
> Do you really think it is actively wrong to call drm_bridge_add for
> internal bridges such as this?
If we want to share bridge init code, then I think we need a
drm_bridge_init(). Not overload drm_bridge_add (which really should be
drm_bridge_register I think, but oh well, it's at least consistent with
drm_panel_add).
-Daniel
>
> Cheers,
> Peter
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added
From: Daniel Vetter @ 2018-05-08 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d378241f-7420-bbaf-c447-18cdfd4f9dd3@axentia.se>
On Mon, May 07, 2018 at 03:59:04PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:39, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >> On 2018-05-03 11:06, Daniel Vetter wrote:
> >>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> >>>> The more natural approach would perhaps be to add an drm_bridge_add,
> >>>> but there are several other bridges that never call drm_bridge_add.
> >>>> Just removing the drm_bridge_remove is the easier fix.
> >>>>
> >>>> Signed-off-by: Peter Rosin <peda@axentia.se>
> >>>
> >>> This mess is much bigger. There's 2 pairs of bridge functions:
> >>>
> >>> - drm_bridge_attach/detach. Those are meant to be called by the overall
> >>> drm driver to connect/disconnect a drm_bridge.
> >>>
> >>> - drm_bridge_add/remove. These are supposed to be called by the bridge
> >>> driver itself to register/unregister itself. Maybe we should rename
> >>> them, since the same issue happens with drm_panel, with the same
> >>> confusion.
> >>>
> >>> I thought someone was working on a cleanup series to fix this mess, but I
> >>> didn't find anything.
> >>
> >> Ok, I just spotted the imbalance and didn't really dig into what
> >> actually happens in these error paths. Now that I have done so I
> >> believe that the removed drm_bridge_remove calls causes NULL
> >> dereferences if/when the error paths are triggered.
> >>
> >> So, I don't think this can wait for some bigger cleanup.
> >>
> >> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> >> __list_del with NULL in both prev and next since the list member
> >> is never initialized. prev and next are dereferenced by __list_del
> >> and you have *boom*
> >>
> >> I recommend adding the tag
> >>
> >> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> >>
> >> so that stable picks this one up.
> >
> > I just wanted to correct your commit message text - the correct solution
> > is definitely _not_ for sti here to call drm_bridge_add.
>
> Ah, I see what you mean. Do you want me to respin?
>
> > It should call
> > drm_bridge_attach/detach only, as a pair.
>
> Alas, the attach/detach functions are generally not called from the same
> level. After the bridge has been attached to an encoder, it is detached
> in the generic code shutting down the encoder, i.e. the bridge consumer
> is not explicitly involved with bridge detaching.
>
> > I didn't check whether you instead have a _detach call missing or what's
> > going on here.
>
> So, even though there is no _detach call, it is still not "missing" as
> it is not supposed to be there...
Oh, TIL. Totally missed that we've improved this to be closer to dwim()
semantics. I think your patch is correct as-is and has my
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It'd be great to improve the kerneldoc for drm_bridge_attach though to
mention that bridges get auto-detached on encoder cleanup as don in
drm_encoder_cleanup(). Care to do that?
And on that note I've again realized that most drivers totally get this
wrong when they set their ->destroy callback to drm_encoder_cleanup
(similar for other kms objects), because that one does _not_ do the final
kfree. Oh well.
-Daniel
>
> Cheers,
> Peter
>
> > -Daniel
> >>
> >> Cheers,
> >> Peter
> >>
> >>> -Daniel
> >>>
> >>>> ---
> >>>> drivers/gpu/drm/sti/sti_hda.c | 1 -
> >>>> drivers/gpu/drm/sti/sti_hdmi.c | 1 -
> >>>> 2 files changed, 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> >>>> index 67bbdb49fffc..199db13f565c 100644
> >>>> --- a/drivers/gpu/drm/sti/sti_hda.c
> >>>> +++ b/drivers/gpu/drm/sti/sti_hda.c
> >>>> @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device *master, void *data)
> >>>> return 0;
> >>>>
> >>>> err_sysfs:
> >>>> - drm_bridge_remove(bridge);
> >>>> return -EINVAL;
> >>>> }
> >>>>
> >>>> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> >>>> index 58f431102512..932724784942 100644
> >>>> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> >>>> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> >>>> @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data)
> >>>> return 0;
> >>>>
> >>>> err_sysfs:
> >>>> - drm_bridge_remove(bridge);
> >>>> hdmi->drm_connector = NULL;
> >>>> return -EINVAL;
> >>>> }
> >>>> --
> >>>> 2.11.0
> >>>>
> >>>> _______________________________________________
> >>>> dri-devel mailing list
> >>>> dri-devel at lists.freedesktop.org
> >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>>
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] clk: imx6ull: use OSC clock during AXI rate change
From: Jacky Bai @ 2018-05-08 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56a409cf76a3eaa713cb4f0bbe1e39b6@agner.ch>
> Subject: Re: [PATCH] clk: imx6ull: use OSC clock during AXI rate change
>
> Hi Jacky,
>
> On 02.05.2018 09:38, Shawn Guo wrote:
> > Hi Jacky,
> >
> > Do you see this problem on i.MX6 ULL? What's your take on Stefan's fix?
>
> Any comment to this?
>
> It is 4.17.0-rc4 is out and i.MX 6ULL is still broken :-(
>
Hi Stefan,
I have tried two 6ULL board, I don't meet such issue. System can boot up successfully with commit 6f9575e55632 included.
Anyway, the change in this patch is ok for me. it is no harm to the BUS clock change flow.
Jacky
> --
> Stefan
>
> >
> > Shawn
> >
> > On Wed, Apr 18, 2018 at 02:49:08PM +0200, Stefan Agner wrote:
> >> On i.MX6 ULL using PLL3 seems to cause a freeze when setting the
> >> parent to IMX6UL_CLK_PLL3_USB_OTG. This only seems to appear since
> >> commit 6f9575e55632 ("clk: imx: Add CLK_IS_CRITICAL flag for busy
> >> divider and busy mux"), probably because the clock is now forced to
> >> be on.
> >>
> >> Fixes: 6f9575e55632("clk: imx: Add CLK_IS_CRITICAL flag for busy
> >> divider and busy mux")
> >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >> ---
> >> This addresses a regression ssen on v4.17-rc1 where the kernel boots
> >> during clock initialization, see also:
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> >>
> tchwork.kernel.org%2Fpatch%2F10295927%2F&data=02%7C01%7Cping.bai%
> 40nx
> >>
> p.com%7C023287ec65034c4db45f08d5b419effb%7C686ea1d3bc2b4c6fa92cd9
> 9c5c
> >>
> 301635%7C0%7C0%7C636612945852594725&sdata=U0ZGid9ZBey0FXfId2dhZb
> hVl8p
> >> CcjTiexG3JHYwCA4%3D&reserved=0
> >>
> >> drivers/clk/imx/clk-imx6ul.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/imx/clk-imx6ul.c
> >> b/drivers/clk/imx/clk-imx6ul.c index 114ecbb94ec5..12320118f8de
> >> 100644
> >> --- a/drivers/clk/imx/clk-imx6ul.c
> >> +++ b/drivers/clk/imx/clk-imx6ul.c
> >> @@ -464,7 +464,7 @@ static void __init imx6ul_clocks_init(struct
> device_node *ccm_node)
> >> clk_set_rate(clks[IMX6UL_CLK_AHB], 99000000);
> >>
> >> /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz
> */
> >> - clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL],
> clks[IMX6UL_CLK_PLL3_USB_OTG]);
> >> + clk_set_parent(clks[IMX6UL_CLK_PERIPH_CLK2_SEL],
> >> +clks[IMX6UL_CLK_OSC]);
> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH],
> clks[IMX6UL_CLK_PERIPH_CLK2]);
> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH_PRE],
> clks[IMX6UL_CLK_PLL2_BUS]);
> >> clk_set_parent(clks[IMX6UL_CLK_PERIPH],
> >> clks[IMX6UL_CLK_PERIPH_PRE]);
> >> --
> >> 2.17.0
> >>
^ permalink raw reply
* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Marcel Holtmann @ 2018-05-08 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525762084.14468.20.camel@mtkswgap22>
Hi Sean,
>>> +
>>> +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 plen,
>>> + const void *param)
>>> +{
>>> + struct mtk_bt_dev *btdev = hu->priv;
>>> + struct hci_command_hdr *hhdr;
>>> + struct hci_acl_hdr *ahdr;
>>> + struct mtk_wmt_hdr *whdr;
>>> + struct sk_buff *skb;
>>> + int ret = 0;
>>> +
>>> + init_completion(&btdev->wmt_cmd);
>>> +
>>> + skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
>>> + if (!skb)
>>> + return -ENOMEM;
>>> +
>>> + /*
>>> + * WMT data is carried in either ACL or HCI format with op code as
>>> + * 0xfc6f and followed by a WMT header and its actual payload.
>>> + */
>>
>> Please use net subsystem comment style.
>>
>>> + switch (opcode) {
>>> + case MTK_WMT_PATCH_DWNLD:
>>> + ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
>>> + ahdr->handle = cpu_to_le16(0xfc6f);
>>> + ahdr->dlen = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
>>> + break;
>>> + default:
>>> + hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
>>> + hhdr->opcode = cpu_to_le16(0xfc6f);
>>> + hhdr->plen = plen + MTK_WMT_HDR_SIZE;
>>> + break;
>>> + }
>>> +
>>> + hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
>>> + HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
>>
>> Why not move that into the switch statement above.
>>
>>> +
>>> + /* Start to build a WMT header and its actual payload. */
>>> + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
>>> + whdr->dir = 1;
>>> + whdr->op = opcode;
>>> + whdr->dlen = cpu_to_le16(plen + 1);
>>> + whdr->flag = flag;
>>> + skb_put_data(skb, param, plen);
>>> +
>>> + mtk_enqueue(hu, skb);
>>> + hci_uart_tx_wakeup(hu);
>>> +
>>> + /*
>>> + * Waiting a WMT event response, while we must take care in case of
>>> + * failures for the wait.
>>> + */
>>> + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
>>> +
>>> + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
>>> +}
>>
>> All in all I am not convinced that this is super clean. I get that we need something special for having this in the ACL data packets, but for the standard HCI command I prefer that __hci_cmd_sync is used. I addition, it seems that patch download is the only special case and that happens before at the setup stage. So we could make things special for that. I need to understand this a bit better. Can I get a btmon -w trace.log file from the whole init procedure.
>>
>
> While i was trying to rewrite the driver based on btuart.c. you posted
> on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
> hci command sending which I've done previously with mtk_wmt_cmd_sync.
>
> However, eventually, I got a cmd_timer timeout whose message printed
> on console as "Bluetooth: hci0: command 0xfc6f tx timeout".
>
> The mtk soc specific cmd/event I posted below, I dumped directly in
> driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.
>
> It appears to the event id is not standard and thus it cannot cancel the
> cmd timer when the special hci event is being handled. This way can we
> can still use __hci_cmd_sync api ?
>
> [ 4.896200] hci tx: 00000000: 01 6f fc 05 01 07 01 00 04
> [ 4.904671] hci rx: 00000000: e4 05 02 07 01 00
> 00
> [ 4.912859] Bluetooth: hci0 event 0xe4
>
>
> buildroot login: [ 6.914509] Bluetooth: hci0: command 0xfc6f tx
> timeout
> [ 6.919831] hci tx: 00000000: 01 6f fc 06 01 06 02 00 00
> 01 .o........
> [ 7.006631] hci rx: 00000000: e4 05 02 06 01 00
> 00 .......
> [ 7.014821] Bluetooth: hci0 event 0xe4
can you just start btmon before loading the module / driver? It makes it a lot easier since it will actually decode the basics for us. If there is a bug within __hci_cmd_sync_ev, then we are going to fix it.
So all the MTK vendor commands respond with a vendor event? Or are there some that do the standard command status/complete handling?
Regards
Marcel
^ permalink raw reply
* Patch "irqchip/qcom: Fix check for spurious interrupts" has been added to the 4.16-stable tree
From: gregkh at linuxfoundation.org @ 2018-05-08 7:23 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
irqchip/qcom: Fix check for spurious interrupts
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
irqchip-qcom-fix-check-for-spurious-interrupts.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 1bc2463cee92ef0e2034c813d5e511adeb58b5fd Mon Sep 17 00:00:00 2001
From: Agustin Vega-Frias <agustinv@codeaurora.org>
Date: Tue, 1 May 2018 10:14:50 -0400
Subject: irqchip/qcom: Fix check for spurious interrupts
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
Patches currently in stable-queue which might be from agustinv at codeaurora.org are
queue-4.16/irqchip-qcom-fix-check-for-spurious-interrupts.patch
^ permalink raw reply
* Patch "irqchip/qcom: Fix check for spurious interrupts" has been added to the 4.14-stable tree
From: gregkh at linuxfoundation.org @ 2018-05-08 7:22 UTC (permalink / raw)
To: linux-arm-kernel
This is a note to let you know that I've just added the patch titled
irqchip/qcom: Fix check for spurious interrupts
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
irqchip-qcom-fix-check-for-spurious-interrupts.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 1bc2463cee92ef0e2034c813d5e511adeb58b5fd Mon Sep 17 00:00:00 2001
From: Agustin Vega-Frias <agustinv@codeaurora.org>
Date: Tue, 1 May 2018 10:14:50 -0400
Subject: irqchip/qcom: Fix check for spurious interrupts
From: Agustin Vega-Frias <agustinv@codeaurora.org>
commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.
When the interrupts for a combiner span multiple registers it must be
checked if any interrupts have been asserted on each register before
checking for spurious interrupts.
Checking each register seperately leads to false positive warnings.
[ tglx: Massaged changelog ]
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: timur at codeaurora.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org
Link: https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agustinv at codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
- if (!status)
+ if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x %08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
Patches currently in stable-queue which might be from agustinv at codeaurora.org are
queue-4.14/irqchip-qcom-fix-check-for-spurious-interrupts.patch
^ permalink raw reply
* [PATCH] Kirin-PCIe: Add kirin pcie msi feature.
From: Yao Chen @ 2018-05-08 7:03 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds kirin pcie msi feature.
Signed-off-by: Yao Chen <chenyao11@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 ++
drivers/pci/dwc/pcie-kirin.c | 38 +++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ec3eb8e..4ef684f 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -872,6 +872,8 @@
0x0 0x02000000>;
num-lanes = <1>;
#interrupt-cells = <1>;
+ interrupts = <0 283 4>;
+ interrupts-names = "msi";
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x0 0 0 1
&gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
index d2970a0..2319c9c 100644
--- a/drivers/pci/dwc/pcie-kirin.c
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -426,9 +426,28 @@ static int kirin_pcie_establish_link(struct pcie_port *pp)
return 0;
}
+static irqreturn_t kirin_pcie_msi_irq_handler(int irq, void *arg)
+{
+ struct pcie_port *pp = arg;
+
+ return dw_handle_msi_irq(pp);
+}
+
+static void kirin_pcie_msi_init(struct pcie_port *pp)
+{
+ dw_pcie_msi_init(pp);
+}
+
+static void kirin_pcie_enable_interrupts(struct pcie_port *pp)
+{
+ if (IS_ENABLED(CONFIG_PCI_MSI))
+ kirin_pcie_msi_init(pp);
+}
+
static int kirin_pcie_host_init(struct pcie_port *pp)
{
kirin_pcie_establish_link(pp);
+ kirin_pcie_enable_interrupts(pp);
return 0;
}
@@ -448,6 +467,25 @@ static int kirin_pcie_host_init(struct pcie_port *pp)
static int __init kirin_add_pcie_port(struct dw_pcie *pci,
struct platform_device *pdev)
{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI_MSI)) {
+ pci->pp.msi_irq = platform_get_irq(pdev, 0);
+ if (!pci->pp.msi_irq) {
+ dev_err(&pdev->dev, "failed to get msi irq\n");
+ return -ENODEV;
+ }
+ ret = devm_request_irq(&pdev->dev, pci->pp.msi_irq,
+ kirin_pcie_msi_irq_handler,
+ IRQF_SHARED | IRQF_NO_THREAD,
+ "kirin_pcie_msi", &pci->pp);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request msi irq\n");
+ return ret;
+ }
+ }
+
+ pci->pp.root_bus_nr = -1;
pci->pp.ops = &kirin_pcie_host_ops;
return dw_pcie_host_init(&pci->pp);
--
1.9.1
^ permalink raw reply related
* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Sean Wang @ 2018-05-08 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <A7391E5D-2945-415B-8AB1-8DFBF2E65878@holtmann.org>
Hi, Marcel
On Tue, 2018-04-03 at 12:27 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
[ ... ]
> > +
> > +static int mtk_wmt_cmd_sync(struct hci_uart *hu, u8 opcode, u8 flag, u16 plen,
> > + const void *param)
> > +{
> > + struct mtk_bt_dev *btdev = hu->priv;
> > + struct hci_command_hdr *hhdr;
> > + struct hci_acl_hdr *ahdr;
> > + struct mtk_wmt_hdr *whdr;
> > + struct sk_buff *skb;
> > + int ret = 0;
> > +
> > + init_completion(&btdev->wmt_cmd);
> > +
> > + skb = bt_skb_alloc(plen + MTK_WMT_CMD_SIZE, GFP_KERNEL);
> > + if (!skb)
> > + return -ENOMEM;
> > +
> > + /*
> > + * WMT data is carried in either ACL or HCI format with op code as
> > + * 0xfc6f and followed by a WMT header and its actual payload.
> > + */
>
> Please use net subsystem comment style.
>
> > + switch (opcode) {
> > + case MTK_WMT_PATCH_DWNLD:
> > + ahdr = skb_put(skb, HCI_ACL_HDR_SIZE);
> > + ahdr->handle = cpu_to_le16(0xfc6f);
> > + ahdr->dlen = cpu_to_le16(plen + MTK_WMT_HDR_SIZE);
> > + break;
> > + default:
> > + hhdr = skb_put(skb, HCI_COMMAND_HDR_SIZE);
> > + hhdr->opcode = cpu_to_le16(0xfc6f);
> > + hhdr->plen = plen + MTK_WMT_HDR_SIZE;
> > + break;
> > + }
> > +
> > + hci_skb_pkt_type(skb) = opcode == MTK_WMT_PATCH_DWNLD ?
> > + HCI_ACLDATA_PKT : HCI_COMMAND_PKT;
>
> Why not move that into the switch statement above.
>
> > +
> > + /* Start to build a WMT header and its actual payload. */
> > + whdr = skb_put(skb, MTK_WMT_HDR_SIZE);
> > + whdr->dir = 1;
> > + whdr->op = opcode;
> > + whdr->dlen = cpu_to_le16(plen + 1);
> > + whdr->flag = flag;
> > + skb_put_data(skb, param, plen);
> > +
> > + mtk_enqueue(hu, skb);
> > + hci_uart_tx_wakeup(hu);
> > +
> > + /*
> > + * Waiting a WMT event response, while we must take care in case of
> > + * failures for the wait.
> > + */
> > + ret = wait_for_completion_interruptible_timeout(&btdev->wmt_cmd, HZ);
> > +
> > + return ret > 0 ? 0 : ret < 0 ? ret : -ETIMEDOUT;
> > +}
>
> All in all I am not convinced that this is super clean. I get that we need something special for having this in the ACL data packets, but for the standard HCI command I prefer that __hci_cmd_sync is used. I addition, it seems that patch download is the only special case and that happens before at the setup stage. So we could make things special for that. I need to understand this a bit better. Can I get a btmon -w trace.log file from the whole init procedure.
>
While i was trying to rewrite the driver based on btuart.c. you posted
on RFC, I used __hci_cmd_sync_ev to replace such kinds of SoC specific
hci command sending which I've done previously with mtk_wmt_cmd_sync.
However, eventually, I got a cmd_timer timeout whose message printed
on console as "Bluetooth: hci0: command 0xfc6f tx timeout".
The mtk soc specific cmd/event I posted below, I dumped directly in
driver, always uses cmd as opcode 0xfc6f, and its event id as 0xe4.
It appears to the event id is not standard and thus it cannot cancel the
cmd timer when the special hci event is being handled. This way can we
can still use __hci_cmd_sync api ?
[ 4.896200] hci tx: 00000000: 01 6f fc 05 01 07 01 00 04
[ 4.904671] hci rx: 00000000: e4 05 02 07 01 00
00
[ 4.912859] Bluetooth: hci0 event 0xe4
buildroot login: [ 6.914509] Bluetooth: hci0: command 0xfc6f tx
timeout
[ 6.919831] hci tx: 00000000: 01 6f fc 06 01 06 02 00 00
01 .o........
[ 7.006631] hci rx: 00000000: e4 05 02 06 01 00
00 .......
[ 7.014821] Bluetooth: hci0 event 0xe4
^ permalink raw reply
* [PATCH v3 2/3] platform: move the early platform device support to arch/sh
From: Geert Uytterhoeven @ 2018-05-08 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504132731.14574-3-brgl@bgdev.pl>
Hi Bartosz,
On Fri, May 4, 2018 at 3:27 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> SuperH is the only user of the current implementation of early platform
> device support. We want to introduce a more robust approach to early
> probing. As the first step - move all the current early platform code
> to arch/sh.
>
> In order not to export internal drivers/base functions to arch code for
> this temporary solution - copy the two needed routines for driver
> matching from drivers/base/platform.c to arch/sh/drivers/platform_early.c.
>
> Also: call early_platform_cleanup() from subsys_initcall() so that it's
> called after all early devices are probed.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> drivers/clocksource/sh_cmt.c | 7 +
> drivers/clocksource/sh_mtu2.c | 7 +
> drivers/clocksource/sh_tmu.c | 8 +
> drivers/tty/serial/sh-sci.c | 7 +-
> include/linux/platform_device.h | 64 +----
The parts used on contemporary ARM/ARM64 Renesas SoCs look fine to me, so
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v7 1/6] dt-bindings: define vendor prefix for Wi2Wi, Inc.
From: H. Nikolaus Schaller @ 2018-05-08 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507205455.GA28316@rob-hp-laptop>
HI Rob,
> Am 07.05.2018 um 22:54 schrieb Rob Herring <robh@kernel.org>:
>
> On Thu, May 03, 2018 at 11:35:46AM +0200, H. Nikolaus Schaller wrote:
>> Introduce vendor prefix for Wi2Wi, Inc. for W2SG0004 GPS module
>> and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell).
>>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>
> Applied this one so you don't have to keep sending it.
Thanks and BR,
Nikolaus
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Andrzej Hajda @ 2018-05-08 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507135341.GI12521@phenom.ffwll.local>
On 07.05.2018 15:53, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote:
>> On 04.05.2018 15:52, Peter Rosin wrote:
>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>> down along with the bridge. Thus, there will no longer linger any
>>> dangling pointers from the bridge consumer (the drm_device) to some
>>> non-existent bridge supplier.
>> I understand rationales behind this patch, but it is another step into
>> making drm_dev one big driver with subcomponents, where drm will work
>> only if every subcomponent is working/loaded. Do we need to go this way?
>> In case of many platforms such approach results in display turned on
>> very late on boot for example due to late initialization of some
>> regulator exposed by some i2c device, which is used by hdmi bridge. And
>> this hdmi bridge is just to provide alternative(rarely used) display
>> path, the main display path would work anyway.
>>
>> So the main question to drm maintainers is about evolution of bridges,
>> if drm_bridges should become mandatory components of drm device or they
>> could be added/removed dynamically?
> This is already the case. You currently cannot hotplug a drm_bridge,
> everything must be present.
Are you sure? DRM core is changing quite fast, so maybe I have missed
something, but AFAIK core calls bridge code only if full display
pipeline is created and connector is in connected state.
So adding and removing bridges from inactive pipelines should work if
coded properly.
> I don't think it makes sense to change that
> until we have physically hotpluggable drm_bridges in real hardware.
But kernel core already assumes that device drivers are hot-pluggable
:), even this patch is created to solve issues regarding driver hot
unplugging.
> I
> definitely don't want to refcount stuff to work around driver load
> bonghits on DT platforms, because refcounting is way too hard to get right
> :-)
I am not sure about bridges, but I have successfully (IMO) experimented
with hot (un)plugging panel driver, see panel-samsung-s6e8aa0.c driver
and exynos_drm_dsi.c, panel driver can be safely
plugged/unplugged/replugged without any refcounting (but with help of
mipi_dsi attach/detach callbacks, which are not available for
non-mipi-dsi drivers).
Regards
Andrzej
>
> Afaik there's out-of-tree patches to solve 99% of the driver load fun on
> DT platforms, but because it's not a 100% solution it's blocked since
> forever.
> -Daniel
>
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>> ---
>>> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
>>> include/drm/drm_bridge.h | 2 ++
>>> 2 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 78d186b6831b..0259f0a3ff27 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -26,6 +26,7 @@
>>> #include <linux/mutex.h>
>>>
>>> #include <drm/drm_bridge.h>
>>> +#include <drm/drm_device.h>
>>> #include <drm/drm_encoder.h>
>>>
>>> #include "drm_crtc_internal.h"
>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
>>> if (bridge->dev)
>>> return -EBUSY;
>>>
>>> + if (encoder->dev->dev != bridge->odev) {
>>> + bridge->link = device_link_add(encoder->dev->dev,
>>> + bridge->odev, 0);
>>> + if (!bridge->link) {
>>> + dev_err(bridge->odev, "failed to link bridge to %s\n",
>>> + dev_name(encoder->dev->dev));
>>> + return -EINVAL;
>>> + }
>>> + }
>>> +
>>> bridge->dev = encoder->dev;
>>> bridge->encoder = encoder;
>>>
>>> if (bridge->funcs->attach) {
>>> ret = bridge->funcs->attach(bridge);
>>> if (ret < 0) {
>>> + if (bridge->link)
>>> + device_link_del(bridge->link);
>>> + bridge->link = NULL;
>>> bridge->dev = NULL;
>>> bridge->encoder = NULL;
>>> return ret;
>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>> if (bridge->funcs->detach)
>>> bridge->funcs->detach(bridge);
>>>
>>> + if (bridge->link)
>>> + device_link_del(bridge->link);
>>> + bridge->link = NULL;
>>> +
>>> bridge->dev = NULL;
>>> }
>>>
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index b656e505d11e..804189c63a4c 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>> * @list: to keep track of all added bridges
>>> * @timings: the timing specification for the bridge, if any (may
>>> * be NULL)
>>> + * @link: drm consumer <-> bridge supplier
>>> * @funcs: control functions
>>> * @driver_private: pointer to the bridge driver's internal context
>>> */
>>> @@ -271,6 +272,7 @@ struct drm_bridge {
>>> struct drm_bridge *next;
>>> struct list_head list;
>>> const struct drm_bridge_timings *timings;
>>> + struct device_link *link;
>>>
>>> const struct drm_bridge_funcs *funcs;
>>> void *driver_private;
>>
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Add compatible string for FRWY-LS1012A
From: Bhaskar Upadhaya @ 2018-05-08 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525760999-6187-1-git-send-email-Bhaskar.Upadhaya@nxp.com>
Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
---
Documentation/devicetree/bindings/arm/fsl.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index cdb9dd7..0517440 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -147,6 +147,10 @@ LS1012A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
+LS1012A ARMv8 based FRWY Board
+Required root node properties:
+ - compatible = "fsl,frwy-ls1012a", "fsl,ls1012a";
+
LS1012A ARMv8 based FRDM Board
Required root node properties:
- compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: ls1012a: Add FRWY-LS1012A board support
From: Bhaskar Upadhaya @ 2018-05-08 6:29 UTC (permalink / raw)
To: linux-arm-kernel
FRWY-LS1012A is a different design from LS1012A-FRDM,
but has some common SoC features. Key feature on this
board is Micro SD, USB 3.0, DDR, UART.
Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts | 64 ++++++++++++++++++++++
2 files changed, 65 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 86e18ad..d116144 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frwy.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
new file mode 100644
index 0000000..f69086d
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
@@ -0,0 +1,64 @@
+/*
+ * Device Tree file for NXP LS1012A FRWY Board.
+ *
+ * Copyright 2018 NXP
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "fsl-ls1012a.dtsi"
+
+/ {
+ model = "LS1012A FRWY Board";
+ compatible = "fsl,frwy-ls1012a", "fsl,ls1012a";
+
+};
+
+&pcie {
+ status = "okay";
+};
+
+&duart0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 00/13] net: mvpp2: phylink conversion
From: David Miller @ 2018-05-08 3:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135643.23466-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 4 May 2018 15:56:30 +0200
> Also as the SFP cages on both DB boards can be considered as non-wired,
> the SFP code was reworked to really support when some pins of the SFP
> cage aren't described in the device tree. Also a warning was added when
> no Tx disable pin is available. (Patches 1-3).
I guess there is still discussion about whether fixed-link should be
used for this instead of SFP.
^ permalink raw reply
* [PATCH] ASoC: uniphier: add digital output volume for UniPhier sound system
From: Katsuhiro Suzuki @ 2018-05-08 3:16 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds controllers for digital volume of PCM output. Volume
effects simply linear, not dB scale as follows:
Gained PCM = Original * 0x4000 / Volume
The value range of volume is from 0x0001 to 0xffff. 0x0000 works as
mute. Initial value is 0x4000 (+0dB).
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
sound/soc/uniphier/aio-core.c | 58 ++++++++++++++
sound/soc/uniphier/aio-cpu.c | 140 ++++++++++++++++++++++++++++++++++
sound/soc/uniphier/aio-reg.h | 33 ++++++--
sound/soc/uniphier/aio.h | 7 ++
4 files changed, 233 insertions(+), 5 deletions(-)
diff --git a/sound/soc/uniphier/aio-core.c b/sound/soc/uniphier/aio-core.c
index e37b80921abb..638cb3fc5f7b 100644
--- a/sound/soc/uniphier/aio-core.c
+++ b/sound/soc/uniphier/aio-core.c
@@ -659,6 +659,64 @@ void aio_port_set_enable(struct uniphier_aio_sub *sub, int enable)
}
}
+/**
+ * aio_port_get_volume - get volume of AIO port block
+ * @sub: the AIO substream pointer
+ *
+ * Return: current volume, range is 0x0000 - 0xffff
+ */
+int aio_port_get_volume(struct uniphier_aio_sub *sub)
+{
+ struct regmap *r = sub->aio->chip->regmap;
+ u32 v;
+
+ regmap_read(r, OPORTMXTYVOLGAINSTATUS(sub->swm->oport.map, 0), &v);
+
+ return FIELD_GET(OPORTMXTYVOLGAINSTATUS_CUR_MASK, v);
+}
+
+/**
+ * aio_port_set_volume - set volume of AIO port block
+ * @sub: the AIO substream pointer
+ * @vol: target volume, range is 0x0000 - 0xffff.
+ *
+ * Change digital volume and perfome fade-out/fade-in effect for specified
+ * output slot of port. Gained PCM value can calculate as the following:
+ * Gained = Original * vol / 0x4000
+ */
+void aio_port_set_volume(struct uniphier_aio_sub *sub, int vol)
+{
+ struct regmap *r = sub->aio->chip->regmap;
+ int oport_map = sub->swm->oport.map;
+ int cur, diff, slope = 0, fs;
+
+ if (sub->swm->dir == PORT_DIR_INPUT)
+ return;
+
+ cur = aio_port_get_volume(sub);
+ diff = abs(vol - cur);
+ fs = params_rate(&sub->params);
+ if (fs)
+ slope = diff / AUD_VOL_FADE_TIME * 1000 / fs;
+ slope = max(1, slope);
+
+ regmap_update_bits(r, OPORTMXTYVOLPARA1(oport_map, 0),
+ OPORTMXTYVOLPARA1_SLOPEU_MASK, slope << 16);
+ regmap_update_bits(r, OPORTMXTYVOLPARA2(oport_map, 0),
+ OPORTMXTYVOLPARA2_TARGET_MASK, vol);
+
+ if (cur < vol)
+ regmap_update_bits(r, OPORTMXTYVOLPARA2(oport_map, 0),
+ OPORTMXTYVOLPARA2_FADE_MASK,
+ OPORTMXTYVOLPARA2_FADE_FADEIN);
+ else
+ regmap_update_bits(r, OPORTMXTYVOLPARA2(oport_map, 0),
+ OPORTMXTYVOLPARA2_FADE_MASK,
+ OPORTMXTYVOLPARA2_FADE_FADEOUT);
+
+ regmap_write(r, AOUTFADECTR0, BIT(oport_map));
+}
+
/**
* aio_if_set_param - set parameters of AIO DMA I/F block
* @sub: the AIO substream pointer
diff --git a/sound/soc/uniphier/aio-cpu.c b/sound/soc/uniphier/aio-cpu.c
index 00b6441bf195..80daec17be25 100644
--- a/sound/soc/uniphier/aio-cpu.c
+++ b/sound/soc/uniphier/aio-cpu.c
@@ -32,6 +32,35 @@ static bool is_valid_pll(struct uniphier_aio_chip *chip, int pll_id)
return chip->plls[pll_id].enable;
}
+/**
+ * find_volume - find volume supported HW port by HW port number
+ * @chip: the AIO chip pointer
+ * @oport_hw: HW port number, one of AUD_HW_XXXX
+ *
+ * Find AIO device from device list by HW port number. Volume feature is
+ * available only in Output and PCM ports, this limitation comes from HW
+ * specifications.
+ *
+ * Return: The pointer of AIO substream if successful, otherwise NULL on error.
+ */
+static struct uniphier_aio_sub *find_volume(struct uniphier_aio_chip *chip,
+ int oport_hw)
+{
+ int i;
+
+ for (i = 0; i < chip->num_aios; i++) {
+ struct uniphier_aio_sub *sub = &chip->aios[i].sub[0];
+
+ if (!sub->swm)
+ continue;
+
+ if (sub->swm->oport.hw == oport_hw)
+ return sub;
+ }
+
+ return NULL;
+}
+
static bool match_spec(const struct uniphier_aio_spec *spec,
const char *name, int dir)
{
@@ -287,6 +316,7 @@ static int uniphier_aio_hw_params(struct snd_pcm_substream *substream,
sub->setting = 1;
aio_port_reset(sub);
+ aio_port_set_volume(sub, sub->vol);
aio_src_reset(sub);
return 0;
@@ -373,6 +403,8 @@ int uniphier_aio_dai_probe(struct snd_soc_dai *dai)
sub->swm = &spec->swm;
sub->spec = spec;
+
+ sub->vol = AUD_VOL_INIT;
}
aio_iecout_set_enable(aio->chip, true);
@@ -449,8 +481,116 @@ int uniphier_aio_dai_resume(struct snd_soc_dai *dai)
}
EXPORT_SYMBOL_GPL(uniphier_aio_dai_resume);
+static int uniphier_aio_vol_info(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_info *uinfo)
+{
+ uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
+ uinfo->count = 1;
+ uinfo->value.integer.min = 0;
+ uinfo->value.integer.max = AUD_VOL_MAX;
+
+ return 0;
+}
+
+static int uniphier_aio_vol_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct uniphier_aio_chip *chip = snd_soc_component_get_drvdata(comp);
+ struct uniphier_aio_sub *sub;
+ int oport_hw = kcontrol->private_value;
+
+ sub = find_volume(chip, oport_hw);
+ if (!sub)
+ return 0;
+
+ ucontrol->value.integer.value[0] = sub->vol;
+
+ return 0;
+}
+
+static int uniphier_aio_vol_put(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct uniphier_aio_chip *chip = snd_soc_component_get_drvdata(comp);
+ struct uniphier_aio_sub *sub;
+ int oport_hw = kcontrol->private_value;
+
+ sub = find_volume(chip, oport_hw);
+ if (!sub)
+ return 0;
+
+ if (sub->vol == ucontrol->value.integer.value[0])
+ return 0;
+ sub->vol = ucontrol->value.integer.value[0];
+
+ aio_port_set_volume(sub, sub->vol);
+
+ return 0;
+}
+
+static const struct snd_kcontrol_new uniphier_aio_controls[] = {
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .name = "HPCMOUT1 Volume",
+ .info = uniphier_aio_vol_info,
+ .get = uniphier_aio_vol_get,
+ .put = uniphier_aio_vol_put,
+ .private_value = AUD_HW_HPCMOUT1,
+ },
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .name = "PCMOUT1 Volume",
+ .info = uniphier_aio_vol_info,
+ .get = uniphier_aio_vol_get,
+ .put = uniphier_aio_vol_put,
+ .private_value = AUD_HW_PCMOUT1,
+ },
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .name = "PCMOUT2 Volume",
+ .info = uniphier_aio_vol_info,
+ .get = uniphier_aio_vol_get,
+ .put = uniphier_aio_vol_put,
+ .private_value = AUD_HW_PCMOUT2,
+ },
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .name = "PCMOUT3 Volume",
+ .info = uniphier_aio_vol_info,
+ .get = uniphier_aio_vol_get,
+ .put = uniphier_aio_vol_put,
+ .private_value = AUD_HW_PCMOUT3,
+ },
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .name = "HIECOUT1 Volume",
+ .info = uniphier_aio_vol_info,
+ .get = uniphier_aio_vol_get,
+ .put = uniphier_aio_vol_put,
+ .private_value = AUD_HW_HIECOUT1,
+ },
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .access = SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .name = "IECOUT1 Volume",
+ .info = uniphier_aio_vol_info,
+ .get = uniphier_aio_vol_get,
+ .put = uniphier_aio_vol_put,
+ .private_value = AUD_HW_IECOUT1,
+ },
+};
+
static const struct snd_soc_component_driver uniphier_aio_component = {
.name = "uniphier-aio",
+ .controls = uniphier_aio_controls,
+ .num_controls = ARRAY_SIZE(uniphier_aio_controls),
};
int uniphier_aio_probe(struct platform_device *pdev)
diff --git a/sound/soc/uniphier/aio-reg.h b/sound/soc/uniphier/aio-reg.h
index 511ea3c01847..45fdc6ae358a 100644
--- a/sound/soc/uniphier/aio-reg.h
+++ b/sound/soc/uniphier/aio-reg.h
@@ -169,6 +169,7 @@
#define PBINMXPAUSECTR1(n) (0x20208 + 0x40 * (n))
/* AOUT */
+#define AOUTFADECTR0 0x40020
#define AOUTENCTR0 0x40040
#define AOUTENCTR1 0x40044
#define AOUTENCTR2 0x40048
@@ -179,6 +180,9 @@
#define AOUTSRCRSTCTR1 0x400c4
#define AOUTSRCRSTCTR2 0x400c8
+/* AOUT PCMOUT has 5 slots, slot0-3: D0-3, slot4: DMIX */
+#define OPORT_SLOT_MAX 5
+
/* AOUT(PCMOUTN) */
#define OPORTMXCTR1(n) (0x42000 + 0x400 * (n))
#define OPORTMXCTR1_I2SLRSEL_MASK (0x11 << 10)
@@ -359,11 +363,30 @@
#define OPORTMXMASK_XCKMSK_ON (0x0 << 0)
#define OPORTMXMASK_XCKMSK_OFF (0x7 << 0)
#define OPORTMXDEBUG(n) (0x420fc + 0x400 * (n))
-#define OPORTMXT0RSTCTR(n) (0x4211c + 0x400 * (n))
-#define OPORTMXT1RSTCTR(n) (0x4213c + 0x400 * (n))
-#define OPORTMXT2RSTCTR(n) (0x4215c + 0x400 * (n))
-#define OPORTMXT3RSTCTR(n) (0x4217c + 0x400 * (n))
-#define OPORTMXT4RSTCTR(n) (0x4219c + 0x400 * (n))
+#define OPORTMXTYVOLPARA1(n, m) (0x42100 + 0x400 * (n) + 0x20 * (m))
+#define OPORTMXTYVOLPARA1_SLOPEU_MASK GENMASK(31, 16)
+#define OPORTMXTYVOLPARA2(n, m) (0x42104 + 0x400 * (n) + 0x20 * (m))
+#define OPORTMXTYVOLPARA2_FADE_MASK GENMASK(17, 16)
+#define OPORTMXTYVOLPARA2_FADE_NOOP (0x0 << 16)
+#define OPORTMXTYVOLPARA2_FADE_FADEOUT (0x1 << 16)
+#define OPORTMXTYVOLPARA2_FADE_FADEIN (0x2 << 16)
+#define OPORTMXTYVOLPARA2_TARGET_MASK GENMASK(15, 0)
+#define OPORTMXTYVOLGAINSTATUS(n, m) (0x42108 + 0x400 * (n) + 0x20 * (m))
+#define OPORTMXTYVOLGAINSTATUS_CUR_MASK GENMASK(15, 0)
+#define OPORTMXTYSLOTCTR(n, m) (0x42114 + 0x400 * (n) + 0x20 * (m))
+#define OPORTMXTYSLOTCTR_SLOTSEL_MASK GENMASK(11, 8)
+#define OPORTMXTYSLOTCTR_SLOTSEL_SLOT0 (0x8 << 8)
+#define OPORTMXTYSLOTCTR_SLOTSEL_SLOT1 (0x9 << 8)
+#define OPORTMXTYSLOTCTR_SLOTSEL_SLOT2 (0xa << 8)
+#define OPORTMXTYSLOTCTR_SLOTSEL_SLOT3 (0xb << 8)
+#define OPORTMXTYSLOTCTR_SLOTSEL_SLOT4 (0xc << 8)
+#define OPORTMXT0SLOTCTR_MUTEOFF_MASK BIT(1)
+#define OPORTMXT0SLOTCTR_MUTEOFF_MUTE (0x0 << 1)
+#define OPORTMXT0SLOTCTR_MUTEOFF_UNMUTE (0x1 << 1)
+#define OPORTMXTYRSTCTR(n, m) (0x4211c + 0x400 * (n) + 0x20 * (m))
+#define OPORTMXT0RSTCTR_RST_MASK BIT(1)
+#define OPORTMXT0RSTCTR_RST_OFF (0x0 << 1)
+#define OPORTMXT0RSTCTR_RST_ON (0x1 << 1)
#define SBF_(frame, shift) (((frame) * 2 - 1) << shift)
diff --git a/sound/soc/uniphier/aio.h b/sound/soc/uniphier/aio.h
index 52670126084f..aa89c2f6fa24 100644
--- a/sound/soc/uniphier/aio.h
+++ b/sound/soc/uniphier/aio.h
@@ -130,6 +130,10 @@ enum IEC61937_PC {
#define AUD_PLLDIV_1_1 2
#define AUD_PLLDIV_2_3 3
+#define AUD_VOL_INIT 0x4000 /* +0dB */
+#define AUD_VOL_MAX 0xffff /* +6dB */
+#define AUD_VOL_FADE_TIME 20 /* 20ms */
+
#define AUD_RING_SIZE (128 * 1024)
#define AUD_MIN_FRAGMENT 4
@@ -231,6 +235,7 @@ struct uniphier_aio_sub {
/* For PCM audio */
struct snd_pcm_substream *substream;
struct snd_pcm_hw_params params;
+ int vol;
/* For compress audio */
struct snd_compr_stream *cstream;
@@ -323,6 +328,8 @@ int aio_port_set_clk(struct uniphier_aio_sub *sub);
int aio_port_set_param(struct uniphier_aio_sub *sub, int pass_through,
const struct snd_pcm_hw_params *params);
void aio_port_set_enable(struct uniphier_aio_sub *sub, int enable);
+int aio_port_get_volume(struct uniphier_aio_sub *sub);
+void aio_port_set_volume(struct uniphier_aio_sub *sub, int vol);
int aio_if_set_param(struct uniphier_aio_sub *sub, int pass_through);
int aio_oport_set_stream_type(struct uniphier_aio_sub *sub,
enum IEC61937_PC pc);
--
2.17.0
^ permalink raw reply related
* [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability
From: JeffyChen @ 2018-05-08 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AF10C10.1070003@rock-chips.com>
Hi Brian,
On 05/08/2018 10:31 AM, JeffyChen wrote:
> Hi Brian,
>
> On 05/08/2018 09:56 AM, Brian Norris wrote:
>> On Tue, May 08, 2018 at 09:36:24AM +0800, Jeffy Chen wrote:
>>> On 05/08/2018 06:15 AM, Brian Norris wrote:
>>>> On the other hand...this also implies there may be a race condition
>>>> there, where we might lose an interrupt if there is an edge between the
>>>> re-configuration of the polarity in rockchip_irq_demux() and the
>>>> clearing/handling of the interrupt (handle_edge_irq() ->
>>>> chip->irq_ack()). If we have an edge between there, then we might ack
>>>> it, but leave the polarity such that we aren't ready for the next
>>>> (inverted) edge.
>>>
>>> if let me guess, the unexpected irq we saw is the hardware trying to
>>> avoid
>>> losing irq? for example, we set a EDGE_RISING, and the hardware saw
>>> the gpio
>>> is already high, then though it might lost an irq, so fake one for safe?
>>
>> I won't pretend to know what the IC designers were doing, but I don't
>> think that would resolve the problem I'm talking about. The sequence is
>> something like:
>> 1. EDGE_BOTH IRQ occurs (e.g., low to high)
>> 2. reconfigure polarity in rockchip_irq_demux() (polarity=low)
>> 3. continue to handle_edge_irq()
>> 4. another HW edge occurs (e.g., high to low)
>> 5. handle_edge_irq() (from 3) acks (clears) IRQ (before a subsequent
>> rockchip_irq_demux() gets a chance to run and flip the polarity)
>> ...
>>
>> Now the polarity is still low, but the next trigger should be a
>> low-to-high edge.
>
> oops, i see the problem.
>
> so what if we do these:
> 1/ edge irq triggered
> 2/ read gpio level
> 3/ handle irq(ack irq)
> 4/ toggle edge mode(with a while gpio level check)
>
> if the gpio changed in 2/ -> 3/, the 4/ will trigger an irq when writing
> GPIO_INT_POLARITY(which is what we are trying to avoid in the set_type
> case)
>
> but this would not work if i'm wrong about how the HW fake an irq when
> changing POLARITY...
>
>
> or maybe we could just check the gpio status again after
> handle_edge_irq, and correct the polarity in this case
i saw the pinctrl-msm.c do this in the ack(),
and also at the end of set_type(), which might avoid another race in the
set_type()
>
>>
>>> i'll try to confirm it with IC guys.
>>
>> Brian
>>
>>
>>
>
^ permalink raw reply
* [PATCH v0 2/2] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-08 2:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525747704-8537-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin.
However, this pin, not being a normal gpio in the rockchip pinctrl,
is set by bit 1 of system register GRF_SOC_CON10. Therefore a new
gpio controller using gpio-syscon driver is defined in order to use
regulator-gpio.
If the signal voltage changes, the io domain needs to change
correspondingly.
To use this feature, the following options are required in kernel config:
- CONFIG_GPIO_SYSCON=y
- CONFIG_POWER_AVS=y
- CONFIG_ROCKCHIP_IODOMAIN=y
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 36 ++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..792cb04 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -14,6 +14,12 @@
stdout-path = "serial2:1500000n8";
};
+ gpio_syscon10: gpio-syscon10 {
+ compatible = "rockchip,rk3328-gpio-syscon10";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
gmac_clkin: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <125000000>;
@@ -41,6 +47,19 @@
vin-supply = <&vcc_io>;
};
+ vcc_sdio: sdmmcio-regulator {
+ compatible = "regulator-gpio";
+ gpios = <&gpio_syscon10 1 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1
+ 3300000 0x0>;
+ regulator-name = "vcc_sdio";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -208,6 +227,18 @@
};
};
+&io_domains {
+ status = "okay";
+
+ vccio1-supply = <&vcc_io>;
+ vccio2-supply = <&vcc18_emmc>;
+ vccio3-supply = <&vcc_sdio>;
+ vccio4-supply = <&vcc_18>;
+ vccio5-supply = <&vcc_io>;
+ vccio6-supply = <&vcc_io>;
+ pmuio-supply = <&vcc_io>;
+};
+
&pinctrl {
pmic {
pmic_int_l: pmic-int-l {
@@ -227,10 +258,15 @@
cap-mmc-highspeed;
cap-sd-highspeed;
disable-wp;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
max-frequency = <150000000>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vcc_sdio>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v0 0/2] Add sdmmc UHS support to ROC-RK3328-CC board
From: djw at t-chip.com.cn @ 2018-05-08 2:48 UTC (permalink / raw)
To: linux-arm-kernel
From: Levin Du <djw@t-chip.com.cn>
Hi all,
This is an attemp to add sdmmc UHS support to the ROC-RK3328-CC board.
It adds a new compatible `rockchip,rk3328-gpio-syscon10` to the gpio-syscon
driver, so that a new gpio controller named `gpio_syscon10` can be defined
and used in the regulator-gpio. This regulator controls the signal voltage of the
sdmmc. It is essential for UHS support which requires 1.8V signal voltage.
Levin Du (2):
gpio: syscon: Add gpio-syscon for rk3328
arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 36 ++++++++++++++++++++++++++
drivers/gpio/gpio-syscon.c | 32 +++++++++++++++++++++++
2 files changed, 68 insertions(+)
--
2.7.4
^ permalink raw reply
* [RESEND PATCH] pinctrl: rockchip: Disable interrupt when changing it's capability
From: JeffyChen @ 2018-05-08 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508015623.GA61455@rodete-desktop-imager.corp.google.com>
Hi Brian,
On 05/08/2018 09:56 AM, Brian Norris wrote:
> On Tue, May 08, 2018 at 09:36:24AM +0800, Jeffy Chen wrote:
>> On 05/08/2018 06:15 AM, Brian Norris wrote:
>>> On the other hand...this also implies there may be a race condition
>>> there, where we might lose an interrupt if there is an edge between the
>>> re-configuration of the polarity in rockchip_irq_demux() and the
>>> clearing/handling of the interrupt (handle_edge_irq() ->
>>> chip->irq_ack()). If we have an edge between there, then we might ack
>>> it, but leave the polarity such that we aren't ready for the next
>>> (inverted) edge.
>>
>> if let me guess, the unexpected irq we saw is the hardware trying to avoid
>> losing irq? for example, we set a EDGE_RISING, and the hardware saw the gpio
>> is already high, then though it might lost an irq, so fake one for safe?
>
> I won't pretend to know what the IC designers were doing, but I don't
> think that would resolve the problem I'm talking about. The sequence is
> something like:
> 1. EDGE_BOTH IRQ occurs (e.g., low to high)
> 2. reconfigure polarity in rockchip_irq_demux() (polarity=low)
> 3. continue to handle_edge_irq()
> 4. another HW edge occurs (e.g., high to low)
> 5. handle_edge_irq() (from 3) acks (clears) IRQ (before a subsequent
> rockchip_irq_demux() gets a chance to run and flip the polarity)
> ...
>
> Now the polarity is still low, but the next trigger should be a
> low-to-high edge.
oops, i see the problem.
so what if we do these:
1/ edge irq triggered
2/ read gpio level
3/ handle irq(ack irq)
4/ toggle edge mode(with a while gpio level check)
if the gpio changed in 2/ -> 3/, the 4/ will trigger an irq when writing
GPIO_INT_POLARITY(which is what we are trying to avoid in the set_type case)
but this would not work if i'm wrong about how the HW fake an irq when
changing POLARITY...
or maybe we could just check the gpio status again after
handle_edge_irq, and correct the polarity in this case
>
>> i'll try to confirm it with IC guys.
>
> Brian
>
>
>
^ 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