* [PATCH 01/22] dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
From: Maxime Ripard @ 2017-01-05 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-2-quentin.schulz@free-electrons.com>
On Mon, Jan 02, 2017 at 05:37:01PM +0100, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
>
> This adds the device tree binding documentation for the X-Powers AXP20X
> and AXP22X PMICs ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/cd9e296a/attachment.sig>
^ permalink raw reply
* [PATCH v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Rob Herring @ 2017-01-05 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A660958@XAP-PVEXMBX01.xlnx.xilinx.com>
On Wed, Jan 4, 2017 at 11:00 AM, Appana Durga Kedareswara Rao
<appana.durga.rao@xilinx.com> wrote:
> Hi Rob,
>
> Thanks for the review....
>
>> On Wed, Jan 04, 2017 at 07:05:53PM +0530, Kedareswara rao Appana wrote:
>> > When VDMA is configured for more than one frame in the h/w for example
>> > h/w is configured for n number of frames and user Submits n number of
>> > frames and triggered the DMA using issue_pending API.
>> > In the current driver flow we are submitting one frame at a time but
>> > we should submit all the n number of frames at one time as the h/w Is
>> > configured for n number of frames.
>>
>> Please fix run-on sentences, capitalization, and word wrapping.
>
> Sure will fix in the next version....
>
> [Snip]
> -- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
>> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
>> > @@ -66,6 +66,8 @@ Optional child node properties:
>> > Optional child node properties for VDMA:
>> > - xlnx,genlock-mode: Tells Genlock synchronization is
>> > enabled/disabled in hardware.
>> > +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
>> > + enabled/disabled in hardware.
>>
>> What's the default (when not present)? That should be the most common case.
>> Looks like the code treats this as bool, but that's not clear here. The name is not
>> clear what it is doing. Enabling or disabling the feature?
>
> Default value is zero...
> When this property is present it tells hardware is configured for frame store configuration.
So most people will not want "frame store configuration"?
> Will fix the explanation part in the next version like below.
> xlnx,fstore-config: Tells hardware is configured for frame store configuration.
> Is the above explanation clear???
No, I mean make it obvious from the name of the property:
xlnx,fstore-config-enable or xlnx,fstore-enable
And the description needs to say it is boolean.
Rob
^ permalink raw reply
* [PATCH 10/12] ARM: dts: socfpga: add base fpga region and fpga bridges
From: Alan Tull @ 2017-01-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANk1AXSbqohp73xHpp7e9-37d61ZB-dRAPAFc2eQGRYUnvB+0w@mail.gmail.com>
On Thu, Jan 5, 2017 at 10:28 AM, Alan Tull <atull@kernel.org> wrote:
> On Wed, Jan 4, 2017 at 6:21 PM, Dinh Nguyen <dinguyen@kernel.org> wrote:
>> From: Alan Tull <atull@opensource.altera.com>
>>
>> Add h2f and lwh2f bridges.
>> Add base FPGA Region to support DT overlays for FPGA programming.
>> Add l3regs.
>>
>> Signed-off-by: Alan Tull <atull@opensource.altera.com>
>> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
>> ---
>> arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
>> index de29172..dccc281 100644
>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> @@ -93,6 +93,16 @@
>> };
>> };
>>
>> + base_fpga_region {
>> + compatible = "fpga-region";
>> + fpga-mgr = <&fpgamgr0>;
>> + fpga-bridges = <&fpga_bridge0>, <&fpga_bridge1>;
>
> Hi Dinh,
>
> We want to get rid of the 'fpga-bridges' line.
>
>> +
>> + #address-cells = <0x1>;
>> + #size-cells = <0x1>;
>> + ranges = <0 0xff200000 0x100000>;
>
> Should get rid of the ranges line here too. The 'fpga-bridges' and
> 'ranges' line can be added in the overlay.
>
> Alan
>
>> + };
>> +
>> can0: can at ffc00000 {
>> compatible = "bosch,d_can";
>> reg = <0xffc00000 0x1000>;
>> @@ -513,6 +523,22 @@
>> };
>> };
>>
>> + fpga_bridge0: fpga_bridge at ff400000 {
>> + compatible = "altr,socfpga-lwhps2fpga-bridge";
>> + reg = <0xff400000 0x100000>;
>> + resets = <&rst LWHPS2FPGA_RESET>;
>> + reset-names = "lwhps2fpga";
The driver doesn't need 'reset-names' here or below for fpga_bridge1.
>> + clocks = <&l4_main_clk>;
>> + };
>> +
>> + fpga_bridge1: fpga_bridge at ff500000 {
>> + compatible = "altr,socfpga-hps2fpga-bridge";
>> + reg = <0xff500000 0x10000>;
>> + resets = <&rst HPS2FPGA_RESET>;
>> + reset-names = "hps2fpga";
>> + clocks = <&l4_main_clk>;
>> + };
>> +
>> fpgamgr0: fpgamgr at ff706000 {
>> compatible = "altr,socfpga-fpga-mgr";
>> reg = <0xff706000 0x1000
>> @@ -694,6 +720,11 @@
>> arm,prefetch-offset = <7>;
>> };
>>
>> + l3regs at 0xff800000 {
>> + compatible = "altr,l3regs", "syscon";
>> + reg = <0xff800000 0x1000>;
>> + };
>> +
>> mmc: dwmmc0 at ff704000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = <0xff704000 0x1000>;
>> --
>> 2.7.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager
From: Rob Herring @ 2017-01-05 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483614475-3442-3-git-send-email-anup.patel@broadcom.com>
On Thu, Jan 5, 2017 at 5:07 AM, Anup Patel <anup.patel@broadcom.com> wrote:
> This patch adds device tree bindings document for the FlexRM
> ring manager found on Broadcom iProc SoCs.
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> ---
> .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 10/12] ARM: dts: socfpga: add base fpga region and fpga bridges
From: Alan Tull @ 2017-01-05 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483575694-29599-11-git-send-email-dinguyen@kernel.org>
On Wed, Jan 4, 2017 at 6:21 PM, Dinh Nguyen <dinguyen@kernel.org> wrote:
> From: Alan Tull <atull@opensource.altera.com>
>
> Add h2f and lwh2f bridges.
> Add base FPGA Region to support DT overlays for FPGA programming.
> Add l3regs.
>
> Signed-off-by: Alan Tull <atull@opensource.altera.com>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index de29172..dccc281 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -93,6 +93,16 @@
> };
> };
>
> + base_fpga_region {
> + compatible = "fpga-region";
> + fpga-mgr = <&fpgamgr0>;
> + fpga-bridges = <&fpga_bridge0>, <&fpga_bridge1>;
Hi Dinh,
We want to get rid of the 'fpga-bridges' line.
> +
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0 0xff200000 0x100000>;
Should get rid of the ranges line here too. The 'fpga-bridges' and
'ranges' line can be added in the overlay.
Alan
> + };
> +
> can0: can at ffc00000 {
> compatible = "bosch,d_can";
> reg = <0xffc00000 0x1000>;
> @@ -513,6 +523,22 @@
> };
> };
>
> + fpga_bridge0: fpga_bridge at ff400000 {
> + compatible = "altr,socfpga-lwhps2fpga-bridge";
> + reg = <0xff400000 0x100000>;
> + resets = <&rst LWHPS2FPGA_RESET>;
> + reset-names = "lwhps2fpga";
> + clocks = <&l4_main_clk>;
> + };
> +
> + fpga_bridge1: fpga_bridge at ff500000 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + reg = <0xff500000 0x10000>;
> + resets = <&rst HPS2FPGA_RESET>;
> + reset-names = "hps2fpga";
> + clocks = <&l4_main_clk>;
> + };
> +
> fpgamgr0: fpgamgr at ff706000 {
> compatible = "altr,socfpga-fpga-mgr";
> reg = <0xff706000 0x1000
> @@ -694,6 +720,11 @@
> arm,prefetch-offset = <7>;
> };
>
> + l3regs at 0xff800000 {
> + compatible = "altr,l3regs", "syscon";
> + reg = <0xff800000 0x1000>;
> + };
> +
> mmc: dwmmc0 at ff704000 {
> compatible = "altr,socfpga-dw-mshc";
> reg = <0xff704000 0x1000>;
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] n900 device tree: cleanup
From: Tony Lindgren @ 2017-01-05 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612141328.27244@pali>
* Pali Roh?r <pali.rohar@gmail.com> [161214 04:28]:
> On Wednesday 07 December 2016 04:10:48 Sebastian Reichel wrote:
> > Hi Tony,
> >
> > It looks like this fell through the cracks. Apart from inconsistent
> > patch subject:
> >
> > Reviewed-By: Sebastian Reichel <sre@kernel.org>
>
> Fine for me too. Reviewed-By: Pali Roh?r <pali.rohar@gmail.com>
Fixing subject line to use "ARM: dts: n900: cleanup" and applying into
omap-for-v4.11/dt.
Tony
^ permalink raw reply
* [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: sean.wang at mediatek.com @ 2017-01-05 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483632384-8107-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds driver for IR controller on
Mediatek MT7623 SoC. Currently testing successfully
on NEC and SONY remote controller only but it should
work on others (lirc, rc-5 and rc-6).
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 319 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 330 insertions(+)
create mode 100644 linux-4.8.rc1_p0/drivers/media/rc/mtk-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 370e16e..626c500 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -389,4 +389,14 @@ config IR_SUNXI
To compile this driver as a module, choose M here: the module will
be called sunxi-ir.
+config IR_MTK
+ tristate "Mediatek IR remote control"
+ depends on RC_CORE
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say Y if you want to use Mediatek internal IR Controller
+
+ To compile this driver as a module, choose M here: the module will
+ be called mtk-cir.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..505908d 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
+obj-$(CONFIG_IR_MTK) += mtk-cir.o
diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
new file mode 100644
index 0000000..4fa4cab
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,319 @@
+/*
+ * Driver for Mediatek MT7623 IR Receiver Controller
+ *
+ * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program 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.
+ */
+
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/reset.h>
+#include <media/rc-core.h>
+
+#define MTK_IR_DEV "mtk-ir"
+
+/* Register to enable PWM and IR */
+#define MTK_CONFIG_HIGH_REG 0x0c
+/* Enable IR pulse width detection */
+#define MTK_PWM_EN BIT(13)
+/* Enable IR hardware function */
+#define MTK_IR_EN BIT(0)
+
+/* Register to setting sample period */
+#define MTK_CONFIG_LOW_REG 0x10
+/* Field to set sample period */
+#define CHK_PERIOD 0xC00
+#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
+#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
+
+/* Register to clear state of state machine */
+#define MTK_IRCLR_REG 0x20
+/* Bit to restart IR receiving */
+#define MTK_IRCLR BIT(0)
+
+/* Register containing pulse width data */
+#define MTK_CHKDATA_REG(i) (0x88 + 4 * i)
+
+/* Register to enable IR interrupt */
+#define MTK_IRINT_EN_REG 0xcc
+/* Bit to enable interrupt */
+#define MTK_IRINT_EN BIT(0)
+
+/* Register to ack IR interrupt */
+#define MTK_IRINT_CLR_REG 0xd0
+/* Bit to clear interrupt status */
+#define MTK_IRINT_CLR BIT(0)
+
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ 17
+/* Required frequency */
+#define MTK_IR_BASE_CLK 273000000
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK (MTK_IR_BASE_CLK / 4)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE (((1000000000ul / MTK_IR_CLK) * CHK_PERIOD))
+/* Indicate the end of IR data*/
+#define MTK_IR_END(v) (v == 0xff)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev: The device pointer
+ * @ir_lock: Make sure that synchronization between remove and ISR
+ * @rc: The rc instrance
+ * @base: The mapped register i/o base
+ * @irq: The IRQ that we are using
+ * @clk: The clock that we are using
+ * @map_name: The name for keymap lookup
+ */
+struct mtk_ir {
+ struct device *dev;
+ /*Protect concurrency between driver removal and ISR*/
+ spinlock_t ir_lock;
+ struct rc_dev *rc;
+ void __iomem *base;
+ int irq;
+ struct clk *clk;
+ const char *map_name;
+};
+
+static void mtk_w32_mask(struct mtk_ir *ir, u32 val, u32 mask, unsigned int reg)
+{
+ u32 tmp;
+
+ tmp = __raw_readl(ir->base + reg);
+ tmp = (tmp & ~mask) | val;
+ __raw_writel(tmp, ir->base + reg);
+}
+
+static void mtk_w32(struct mtk_ir *ir, u32 val, unsigned int reg)
+{
+ __raw_writel(val, ir->base + reg);
+}
+
+static u32 mtk_r32(struct mtk_ir *ir, unsigned int reg)
+{
+ return __raw_readl(ir->base + reg);
+}
+
+static inline void mtk_irq_disable(struct mtk_ir *ir, u32 mask)
+{
+ u32 val;
+
+ val = mtk_r32(ir, MTK_IRINT_EN_REG);
+ mtk_w32(ir, val & ~mask, MTK_IRINT_EN_REG);
+}
+
+static inline void mtk_irq_enable(struct mtk_ir *ir, u32 mask)
+{
+ u32 val;
+
+ val = mtk_r32(ir, MTK_IRINT_EN_REG);
+ mtk_w32(ir, val | mask, MTK_IRINT_EN_REG);
+}
+
+static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
+{
+ struct mtk_ir *ir = dev_id;
+ u8 wid = 0;
+ u32 i, j, val;
+ DEFINE_IR_RAW_EVENT(rawir);
+
+ spin_lock(&ir->ir_lock);
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ /* Reset decoder state machine */
+ ir_raw_event_reset(ir->rc);
+
+ /* First message must be pulse */
+ rawir.pulse = false;
+
+ /* Handle pulse and space until end of message */
+ for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
+ val = mtk_r32(ir, MTK_CHKDATA_REG(i));
+ dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
+
+ for (j = 0 ; j < 4 ; j++) {
+ wid = (val & (0xff << j * 8)) >> j * 8;
+ rawir.pulse = !rawir.pulse;
+ rawir.duration = wid * (MTK_IR_SAMPLE + 1);
+ ir_raw_event_store_with_filter(ir->rc, &rawir);
+
+ if (MTK_IR_END(wid))
+ goto end_msg;
+ }
+ }
+end_msg:
+ /* Restart the next receive */
+ mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
+
+ ir_raw_event_set_idle(ir->rc, true);
+ ir_raw_event_handle(ir->rc);
+
+ /* Clear interrupt status */
+ mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
+
+ /* Enable interrupt */
+ mtk_irq_enable(ir, MTK_IRINT_EN);
+
+ spin_unlock(&ir->ir_lock);
+
+ return IRQ_HANDLED;
+}
+
+static int mtk_ir_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *dn = dev->of_node;
+ struct resource *res;
+ struct mtk_ir *ir;
+ u32 val;
+ int ret = 0;
+
+ ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
+ if (!ir)
+ return -ENOMEM;
+
+ spin_lock_init(&ir->ir_lock);
+
+ ir->dev = dev;
+
+ if (!of_device_is_compatible(dn, "mediatek,mt7623-ir"))
+ return -ENODEV;
+
+ ir->clk = devm_clk_get(dev, "clk");
+ if (IS_ERR(ir->clk)) {
+ dev_err(dev, "failed to get a ir clock.\n");
+ return PTR_ERR(ir->clk);
+ }
+
+ if (clk_prepare_enable(ir->clk)) {
+ dev_err(dev, "try to enable ir_clk failed\n");
+ ret = -EINVAL;
+ goto exit_clkdisable_clk;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ir->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(ir->base)) {
+ dev_err(dev, "failed to map registers\n");
+ ret = PTR_ERR(ir->base);
+ goto exit_clkdisable_clk;
+ }
+
+ ir->rc = rc_allocate_device();
+ if (!ir->rc) {
+ dev_err(dev, "failed to allocate device\n");
+ ret = -ENOMEM;
+ goto exit_clkdisable_clk;
+ }
+
+ ir->rc->priv = ir;
+ ir->rc->input_name = MTK_IR_DEV;
+ ir->rc->input_phys = "mtk-ir/input0";
+ ir->rc->input_id.bustype = BUS_HOST;
+ ir->rc->input_id.vendor = 0x0001;
+ ir->rc->input_id.product = 0x0001;
+ ir->rc->input_id.version = 0x0001;
+ ir->map_name = of_get_property(dn, "linux,rc-map-name", NULL);
+ ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
+ ir->rc->dev.parent = dev;
+ ir->rc->driver_type = RC_DRIVER_IR_RAW;
+ ir->rc->driver_name = MTK_IR_DEV;
+ ir->rc->allowed_protocols = RC_BIT_ALL;
+ ir->rc->rx_resolution = MTK_IR_SAMPLE;
+
+ ret = rc_register_device(ir->rc);
+ if (ret) {
+ dev_err(dev, "failed to register rc device\n");
+ goto exit_free_dev;
+ }
+
+ platform_set_drvdata(pdev, ir);
+
+ ir->irq = platform_get_irq(pdev, 0);
+ if (ir->irq < 0) {
+ dev_err(dev, "no irq resource\n");
+ ret = ir->irq;
+ goto exit_free_dev;
+ }
+
+ ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
+ if (ret) {
+ dev_err(dev, "failed request irq\n");
+ goto exit_free_dev;
+ }
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
+ val |= MTK_PWM_EN | MTK_IR_EN;
+ mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
+
+ /* Setting sample period */
+ mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
+ MTK_CONFIG_LOW_REG);
+
+ mtk_irq_enable(ir, MTK_IRINT_EN);
+
+ dev_info(dev, "initialized MT7623 IR driver\n");
+ return 0;
+
+exit_free_dev:
+ rc_free_device(ir->rc);
+exit_clkdisable_clk:
+ clk_disable_unprepare(ir->clk);
+
+ return ret;
+}
+
+static int mtk_ir_remove(struct platform_device *pdev)
+{
+ unsigned long flags;
+
+ struct mtk_ir *ir = platform_get_drvdata(pdev);
+
+ spin_lock_irqsave(&ir->ir_lock, flags);
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ clk_disable_unprepare(ir->clk);
+
+ spin_unlock_irqrestore(&ir->ir_lock, flags);
+
+ rc_unregister_device(ir->rc);
+
+ return 0;
+}
+
+static const struct of_device_id mtk_ir_match[] = {
+ { .compatible = "mediatek,mt7623-ir" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mtk_ir_match);
+
+static struct platform_driver mtk_ir_driver = {
+ .probe = mtk_ir_probe,
+ .remove = mtk_ir_remove,
+ .driver = {
+ .name = MTK_IR_DEV,
+ .of_match_table = mtk_ir_match,
+ },
+};
+
+module_platform_driver(mtk_ir_driver);
+
+MODULE_DESCRIPTION("Mediatek MT7623 IR Receiver Controller Driver");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: sean.wang at mediatek.com @ 2017-01-05 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483632384-8107-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds documentation for devicetree bindings for
Mediatek IR controller.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
.../devicetree/bindings/media/mtk-cir.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
new file mode 100644
index 0000000..bbedd71
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,23 @@
+Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
+
+Required properties:
+- compatible : "mediatek,mt7623-ir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "clk" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+cir: cir at 0x10013000 {
+ compatible = "mediatek,mt7623-ir";
+ reg = <0 0x10013000 0 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_IRRX>;
+ clock-names = "clk";
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] media: rc: add support for IR receiver on MT7623 SoC
From: sean.wang at mediatek.com @ 2017-01-05 16:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
This patchset introduces Consumer IR (CIR) support for MT7623 SoC
or other similar SoC and implements raw mode for more compatibility
with different protocols. The driver simply reports the duration of
pulses and spaces to rc core logic to decode.
Sean Wang (2):
Documentation: devicetree: Add document bindings for mtk-cir
media: rc: add driver for IR remote receiver on MT7623 SoC
.../devicetree/bindings/media/mtk-cir.txt | 23 ++
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 319 +++++++++++++++++++++
4 files changed, 353 insertions(+)
create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
create mode 100644 linux-4.8.rc1_p0/drivers/media/rc/mtk-cir.c
--
1.9.1
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Mark Rutland @ 2017-01-05 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104143205.GG18193@arm.com>
On Wed, Jan 04, 2017 at 02:32:06PM +0000, Will Deacon wrote:
> On Wed, Jan 04, 2017 at 01:56:44PM +0000, Mark Rutland wrote:
> > On Tue, Jan 03, 2017 at 09:33:36AM +0000, Mark Rutland wrote:
> > > On Mon, Jan 02, 2017 at 09:15:29PM +0100, Linus Walleij wrote:
> > > > On Mon, Jan 2, 2017 at 4:00 PM, Russell King - ARM Linux
> > > > <linux@armlinux.org.uk> wrote:
> > > > > On Mon, Jan 02, 2017 at 03:34:32PM +0100, Linus Walleij wrote:
> > > > >> in the first line of arch_hw_breakpoint_init() in
> > > > >> arch/arm/kernel/hw_breakpoint.c
> > > > >>
> > > > >> I suspect that is not an accepable solution ...
> > > > >>
> > > > >> It hangs at PC is at write_wb_reg+0x20c/0x330
> > > > >> Which is c03101dc, and looks like this in objdump -d:
> > > > >>
> > > > >> c031020c: ee001eba mcr 14, 0, r1, cr0, cr10, {5}
> > > > >> c0310210: eaffffb3 b c03100e4 <write_wb_reg+0x114>
> > > > >
> > > > > ... and this is several instructions after the address you mention above.
> > > > > Presumably c03101dc is accessing a higher numbered register?
> > > >
> > > > Ah sorry. It looks like this:
> > > >
> > > > c03101dc: ee001ed0 mcr 14, 0, r1, cr0, cr0, {6}
> > > > c03101e0: eaffffbf b c03100e4 <write_wb_reg+0x114>
> > > > c03101e4: ee001ebf mcr 14, 0, r1, cr0, cr15, {5}
> > > > c03101e8: eaffffbd b c03100e4 <write_wb_reg+0x114>
> > > > c03101ec: ee001ebe mcr 14, 0, r1, cr0, cr14, {5}
> > > > c03101f0: eaffffbb b c03100e4 <write_wb_reg+0x114>
> > > > c03101f4: ee001ebd mcr 14, 0, r1, cr0, cr13, {5}
> > > > c03101f8: eaffffb9 b c03100e4 <write_wb_reg+0x114>
> > >
> > > FWIW, I was tracking an issue in this area before the holiday.
> > >
> > > It looked like DBGPRSR.SPD is set unexpectedly over the default idle
> > > path (i.e. WFI), causing the (otherwise valid) register accesses above
> > > to be handled as undefined.
> > >
> > > I haven't looked at the patch in detail, but I guess that it allows idle
> > > to occur between reset_ctrl_regs() and arch_hw_breakpoint_init().
> >
> > I've just reproduced this locally on my dragonboard APQ8060.
> >
> > It looks like the write_wb_reg() call that's exploding is from
> > get_max_wp_len(), which we call immediately after registering the
> > dbg_reset_online callback. Clearing DBGPRSR.SPD before the write_wb_reg() hides
> > the problem, so I suspect we're seeing the issue I mentioned above -- it just
> > so happens that we go idle in a new place.
>
> When you say "go idle", are we just executing a WFI,
>From my prior experiments, just executing a WFI as we happen to do in
the default cpu_v7_do_idle. I tried passing cpuidle.off=1, but that
didn't help. NOPing the WFI in cpu_v7_do_idle did mask the issue, from
what I recall.
> or is the power controller coming into play and we're actually
> powering down the non-debug logic?
As far as I can see, that isn't happening. We don't save/restore any
other CPU state in the default idle path, and the kernel is otherwise
happy.
> In the case of the latter, the PM notifier should clear SPD in
> reset_ctrl_regs, so this sounds like a hardware bug where the SPD bit is
> set unconditionally on WFI.
>
> In that case, this code has always been dodgy -- what happens if you try
> to use hardware breakpoints in GDB in the face of WFI-based idle?
The kernel blows up similiarly to Linus's original report when the
kernel tries to program the breakpoint registers.
I also believe this has always been dodgy.
> > The below hack allows boot to continue, but is not a real fix. I'm not
> > immediately sure what to do.
>
> If it's never worked, I suggest we blacklist the MIDR until somebody from
> Qualcomm can help us further.
I'll see about putting a patch together.
Thanks,
Mark.
>
> Will
^ permalink raw reply
* [PATCH] arm64: dts: msm8996: Add required memory carveouts
From: Bjorn Andersson @ 2017-01-05 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482357822-20823-1-git-send-email-andy.gross@linaro.org>
On Wed 21 Dec 14:03 PST 2016, Andy Gross wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> This patch adds required memory carveouts so that the kernel does not
> access memory that is in use or has been reserved for use by other remote
> processors.
>
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index cde4114..25e11dc 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -64,6 +64,16 @@
> reg = <0x0 0x86000000 0x0 0x200000>;
> no-map;
> };
> +
> + memory at 85800000 {
> + reg = <0x0 0x85800000 0x0 0x800000>;
> + no-map;
> + };
> +
> + memory at 86200000 {
> + reg = <0x0 0x86200000 0x0 0x2600000>;
> + no-map;
> + };
> };
>
> cpus {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Tony Lindgren @ 2017-01-05 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483627851-17996-2-git-send-email-t.remmet@phytec.de>
* Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> To improve NAND safety we updated the partition layout.
> Added barebox backup partition and removed kernel and oftree
> partition. They are kept in ubi now.
What about the users with earlier partition tables?
Please read about "flag day" changes, typically they are not
acceptable.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings
From: Maxime Ripard @ 2017-01-05 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58723369-50ad-1792-9be1-c277eb719044@arm.com>
On Wed, Jan 04, 2017 at 02:16:23AM +0000, Andr? Przywara wrote:
> So can I ask that we start taking this seriously and stop doing things
> which prevent Allwinner boards from being supported properly?
> Which would first involve dropping this very patch?
The driver still supports the old binding.
> Having done breakage in the past (with "allwinner,sun7i-a20-mmc", for
> instance) is no excuse for doing it again.
I'm not sure which breakage we introduced with a new compatible: the
old compatible is working just like it used to, and the new one is
working like we need it to.
> And especially I want to avoid this habit creeping into the arm64
> world (thinking about the H5 here, which may be impacted by this
> very patch, for instance).
And again, if you looked at the entire serie, you would have seen that
I took this into account.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/63b51c9d/attachment.sig>
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Lorenzo Pieralisi @ 2017-01-05 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7cd7bcfb-abae-2948-c3f8-230c0d9c9db6@arm.com>
On Thu, Jan 05, 2017 at 01:52:29PM +0000, Robin Murphy wrote:
[...]
> > Question: I had a look into this and instead of fiddling about with the
> > linker script entries in ACPI (ie IORT_ACPI_DECLARE - which I hope this
> > patchset would help remove entirely), I think that the only check we
> > need in IORT is, depending on what type of SMMU a given device is
> > connected to, to check if the respective SMMU driver is compiled in the
> > kernel and it will be probed, _eventually_.
> >
> > As Robin said, by the time a device is probed the respective SMMU
> > devices are already created and registered with IORT kernel code or
> > they will never be, so to understand if we should defer probing
> > SMMU device creation is _not_ really a problem in ACPI.
> >
> > To check if a SMMU driver is enabled, do we really need a linker
> > table ?
> >
> > Would not a check based on eg:
> >
> > /**
> > * @type: IOMMU IORT node type of the IOMMU a device is connected to
> > */
> > static bool iort_iommu_driver_enabled(u8 type)
> > {
> > switch (type) {
> > case ACPI_IORT_SMMU_V3:
> > return IS_ENABLED(CONFIG_ARM_SMMU_V3);
>
> IS_BUILTIN(...)
Yep right, it is currently equivalent but that does not mean it
will always be.
> > case ACPI_IORT_SMMU:
> > return IS_ENABLED(CONFIG_ARM_SMMU);
> > default:
> > pr_warn("Unknown IORT SMMU type\n");
>
> Might displaying the actual value be helfpul for debugging a broken IORT
> table?
Yes I will do.
> > return false;
> > }
> > }
> >
> > be sufficient (it is a bit gross, agreed, but it is to understand if
> > that's all we need) ? Is there anything I am missing ?
> >
> > Let me know, I will put together a patch for you I really do not
> > want to block your series for this trivial niggle.
>
> Other than that, though, I like it :) IORT has a small, strictly
> bounded, set of supported devices, so I really don't see the need to go
> overboard putting it on parity with DT when something this neat and
> simple will suffice.
Ok, patch coming, which will also allow Sricharan to get rid of the
IORT linker script infrastructure altogether (and more than that,
I can write the patches on top of Sricharan series that I managed
to rebase against v4.10-rc2).
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v2,9/9] irqchip/ls-scfg-msi: add MSI affinity support
From: Marc Zyngier @ 2017-01-05 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483603837-4629-9-git-send-email-Minghuan.Lian@nxp.com>
On 05/01/17 08:10, Minghuan Lian wrote:
> For LS1046a and LS1043a v1.1, the MSI controller has 4 MSIRs and 4
> CPUs. A GIC SPI interrupt of MSIR can be associated with a CPU.
> When changing MSI interrupt affinity, this MSI will be moved to the
> corresponding MSIR and MSI message data will be changed according to
> MSIR. when requesting a MSI, the bits of all 4 MSIR will be reserved.
> The parameter 'msi_affinity_flag' is provide to change this mode.
> "lsmsi=no-affinity" will disable affinity, all MSI can only be
> associated with CPU 0.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> ---
> v2-v1:
> - None
>
> drivers/irqchip/irq-ls-scfg-msi.c | 75 ++++++++++++++++++++++++++++++++++++---
> 1 file changed, 70 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-ls-scfg-msi.c b/drivers/irqchip/irq-ls-scfg-msi.c
> index dc19569..753fe39 100644
> --- a/drivers/irqchip/irq-ls-scfg-msi.c
> +++ b/drivers/irqchip/irq-ls-scfg-msi.c
> @@ -40,6 +40,7 @@ struct ls_scfg_msir {
> unsigned int gic_irq;
> unsigned int bit_start;
> unsigned int bit_end;
> + unsigned int srs; /* Shared interrupt register select */
> void __iomem *reg;
> };
>
> @@ -70,6 +71,19 @@ struct ls_scfg_msi {
> .chip = &ls_scfg_msi_irq_chip,
> };
>
> +static int msi_affinity_flag = 1;
> +
> +static int __init early_parse_ls_scfg_msi(char *p)
> +{
> + if (p && strncmp(p, "no-affinity", 11) == 0)
> + msi_affinity_flag = 0;
> + else
> + msi_affinity_flag = 1;
> +
> + return 0;
> +}
> +early_param("lsmsi", early_parse_ls_scfg_msi);
What is the point of this option? If feels like an unnecessary complexity.
> +
> static void ls_scfg_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
> {
> struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(data);
> @@ -77,12 +91,43 @@ static void ls_scfg_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
> msg->address_hi = upper_32_bits(msi_data->msiir_addr);
> msg->address_lo = lower_32_bits(msi_data->msiir_addr);
> msg->data = data->hwirq;
> +
> + if (msi_affinity_flag) {
> + u32 msir_index;
> +
> + msir_index = cpumask_first(data->common->affinity);
> + if (msir_index >= msi_data->msir_num)
> + msir_index = 0;
How can this happen?
> +
> + msg->data |= msir_index;
How do you guarantee that the low bits were clear? Please document the
way you encode your MSI payload.
> + }
> }
>
> static int ls_scfg_msi_set_affinity(struct irq_data *irq_data,
> const struct cpumask *mask, bool force)
> {
> - return -EINVAL;
> + struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(irq_data);
> + u32 cpu;
> +
> + if (!msi_affinity_flag)
> + return -EINVAL;
> +
> + if (!force)
> + cpu = cpumask_any_and(mask, cpu_online_mask);
> + else
> + cpu = cpumask_first(mask);
> +
> + if (cpu >= msi_data->msir_num)
> + return -EINVAL;
> +
> + if (msi_data->msir[cpu].gic_irq <= 0) {
> + pr_warn("cannot bind the irq to cpu%d\n", cpu);
Please don't. Returning an error is enough. If you really want to have
something, turn it into a proper debug message.
> + return -EINVAL;
> + }
> +
> + cpumask_copy(irq_data->common->affinity, mask);
> +
> + return IRQ_SET_MASK_OK;
> }
>
> static struct irq_chip ls_scfg_msi_parent_chip = {
> @@ -158,7 +203,7 @@ static void ls_scfg_msi_irq_handler(struct irq_desc *desc)
>
> for_each_set_bit_from(pos, &val, size) {
> hwirq = ((msir->bit_end - pos) << msi_data->cfg->ibs_shift) |
> - msir->index;
> + msir->srs;
> virq = irq_find_mapping(msi_data->parent, hwirq);
> if (virq)
> generic_handle_irq(virq);
> @@ -221,10 +266,19 @@ static int ls_scfg_msi_setup_hwirq(struct ls_scfg_msi *msi_data, int index)
> ls_scfg_msi_irq_handler,
> msir);
>
> + if (msi_affinity_flag) {
> + /* Associate MSIR interrupt to the cpu */
> + irq_set_affinity(msir->gic_irq, get_cpu_mask(index));
> + msir->srs = 0; /* This value is determined by the CPU */
> + } else
> + msir->srs = index;
> +
> /* Release the hwirqs corresponding to this MSIR */
> - for (i = 0; i < msi_data->cfg->msir_irqs; i++) {
> - hwirq = i << msi_data->cfg->ibs_shift | msir->index;
> - bitmap_clear(msi_data->used, hwirq, 1);
> + if (!msi_affinity_flag || msir->index == 0) {
> + for (i = 0; i < msi_data->cfg->msir_irqs; i++) {
> + hwirq = i << msi_data->cfg->ibs_shift | msir->index;
> + bitmap_clear(msi_data->used, hwirq, 1);
> + }
> }
>
> return 0;
> @@ -316,6 +370,17 @@ static int ls_scfg_msi_probe(struct platform_device *pdev)
> bitmap_set(msi_data->used, 0, msi_data->irqs_num);
>
> msi_data->msir_num = of_irq_count(pdev->dev.of_node);
> +
> + if (msi_affinity_flag) {
> + u32 cpu_num;
> +
> + cpu_num = num_possible_cpus();
> + if (msi_data->msir_num >= cpu_num)
> + msi_data->msir_num = cpu_num;
> + else
> + msi_affinity_flag = 0;
> + }
> +
> msi_data->msir = devm_kcalloc(&pdev->dev, msi_data->msir_num,
> sizeof(*msi_data->msir),
> GFP_KERNEL);
>
This is a very confusing patch. Please get rid of this useless option
and document how you encode the routing in the hwirq.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Linus Walleij @ 2017-01-05 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104135644.GA29212@leverpostej>
On Wed, Jan 4, 2017 at 2:56 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> I've just reproduced this locally on my dragonboard APQ8060.
Sweet!
> It looks like the write_wb_reg() call that's exploding is from
> get_max_wp_len(), which we call immediately after registering the
> dbg_reset_online callback. Clearing DBGPRSR.SPD before the write_wb_reg() hides
> the problem, so I suspect we're seeing the issue I mentioned above -- it just
> so happens that we go idle in a new place.
>
> The below hack allows boot to continue, but is not a real fix. I'm not
> immediately sure what to do.
Me neither. But Will's suggestion to simply blacklist this chip might be
best.
> Linus, I wasn't able to get ethernet working. Do I need anything on top
> of v4.10-rc2 && multi_v7_defconfig?
I haven't tried it with multi_v7 but I should probably try that and patch
up the defconfigs, those are probably the root of the problem.
I do this on top of qcom_defconfig:
scripts/config --file .config \
--enable QCOM_EBI2 \
--enable ETHERNET \
--enable NET_VENDOR_SMSC \
--enable SMSC911X
Maybe you are missing the EBI2 config?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2,7/9] irqchip/ls-scfg-msi: add LS1046a MSI support
From: Marc Zyngier @ 2017-01-05 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483603837-4629-7-git-send-email-Minghuan.Lian@nxp.com>
On 05/01/17 08:10, Minghuan Lian wrote:
> LS1046a includes 4 MSIRs, each MSIR is assigned a dedicate GIC
> SPI interrupt and provides 32 MSI interrupts. Compared to previous
> MSI, LS1046a's IBS(interrupt bit select) shift is changed to 2 and
> total MSI interrupt number is changed to 128.
>
> The patch adds structure 'ls_scfg_msir' to describe MSIR setting and
> 'ibs_shift' to store the different value between the SoCs.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> ---
> v2-v1:
> - MSI dts node change has been merged into the patch 6/9
>
> drivers/irqchip/irq-ls-scfg-msi.c | 161 +++++++++++++++++++++++++++++---------
> 1 file changed, 126 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/irqchip/irq-ls-scfg-msi.c b/drivers/irqchip/irq-ls-scfg-msi.c
> index cef67cc..67547bd 100644
> --- a/drivers/irqchip/irq-ls-scfg-msi.c
> +++ b/drivers/irqchip/irq-ls-scfg-msi.c
> @@ -17,13 +17,24 @@
> #include <linux/irq.h>
> #include <linux/irqchip/chained_irq.h>
> #include <linux/irqdomain.h>
> +#include <linux/of_irq.h>
> #include <linux/of_pci.h>
> #include <linux/of_platform.h>
> #include <linux/spinlock.h>
>
> -#define MSI_MAX_IRQS 32
> -#define MSI_IBS_SHIFT 3
> -#define MSIR 4
> +#define MSI_IRQS_PER_MSIR 32
> +#define MSI_MSIR_OFFSET 4
> +
> +struct ls_scfg_msi_cfg {
> + u32 ibs_shift; /* Shift of interrupt bit select */
> +};
> +
> +struct ls_scfg_msir {
> + struct ls_scfg_msi *msi_data;
> + unsigned int index;
> + unsigned int gic_irq;
> + void __iomem *reg;
> +};
>
> struct ls_scfg_msi {
> spinlock_t lock;
> @@ -32,8 +43,11 @@ struct ls_scfg_msi {
> struct irq_domain *msi_domain;
> void __iomem *regs;
> phys_addr_t msiir_addr;
> - int irq;
> - DECLARE_BITMAP(used, MSI_MAX_IRQS);
> + struct ls_scfg_msi_cfg *cfg;
> + u32 msir_num;
> + struct ls_scfg_msir *msir;
> + u32 irqs_num;
> + unsigned long *used;
> };
>
> static struct irq_chip ls_scfg_msi_irq_chip = {
> @@ -55,7 +69,7 @@ static void ls_scfg_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
>
> msg->address_hi = upper_32_bits(msi_data->msiir_addr);
> msg->address_lo = lower_32_bits(msi_data->msiir_addr);
> - msg->data = data->hwirq << MSI_IBS_SHIFT;
> + msg->data = data->hwirq;
> }
>
> static int ls_scfg_msi_set_affinity(struct irq_data *irq_data,
> @@ -81,8 +95,8 @@ static int ls_scfg_msi_domain_irq_alloc(struct irq_domain *domain,
> WARN_ON(nr_irqs != 1);
>
> spin_lock(&msi_data->lock);
> - pos = find_first_zero_bit(msi_data->used, MSI_MAX_IRQS);
> - if (pos < MSI_MAX_IRQS)
> + pos = find_first_zero_bit(msi_data->used, msi_data->irqs_num);
> + if (pos < msi_data->irqs_num)
> __set_bit(pos, msi_data->used);
> else
> err = -ENOSPC;
> @@ -106,7 +120,7 @@ static void ls_scfg_msi_domain_irq_free(struct irq_domain *domain,
> int pos;
>
> pos = d->hwirq;
> - if (pos < 0 || pos >= MSI_MAX_IRQS) {
> + if (pos < 0 || pos >= msi_data->irqs_num) {
> pr_err("failed to teardown msi. Invalid hwirq %d\n", pos);
> return;
> }
> @@ -123,15 +137,17 @@ static void ls_scfg_msi_domain_irq_free(struct irq_domain *domain,
>
> static void ls_scfg_msi_irq_handler(struct irq_desc *desc)
> {
> - struct ls_scfg_msi *msi_data = irq_desc_get_handler_data(desc);
> + struct ls_scfg_msir *msir = irq_desc_get_handler_data(desc);
> + struct ls_scfg_msi *msi_data = msir->msi_data;
> unsigned long val;
> - int pos, virq;
> + int pos, virq, hwirq;
>
> chained_irq_enter(irq_desc_get_chip(desc), desc);
>
> - val = ioread32be(msi_data->regs + MSIR);
> - for_each_set_bit(pos, &val, MSI_MAX_IRQS) {
> - virq = irq_find_mapping(msi_data->parent, (31 - pos));
> + val = ioread32be(msir->reg);
> + for_each_set_bit(pos, &val, MSI_IRQS_PER_MSIR) {
> + hwirq = ((31 - pos) << msi_data->cfg->ibs_shift) | msir->index;
> + virq = irq_find_mapping(msi_data->parent, hwirq);
> if (virq)
> generic_handle_irq(virq);
> }
> @@ -143,7 +159,7 @@ static int ls_scfg_msi_domains_init(struct ls_scfg_msi *msi_data)
> {
> /* Initialize MSI domain parent */
> msi_data->parent = irq_domain_add_linear(NULL,
> - MSI_MAX_IRQS,
> + msi_data->irqs_num,
> &ls_scfg_msi_domain_ops,
> msi_data);
> if (!msi_data->parent) {
> @@ -164,16 +180,83 @@ static int ls_scfg_msi_domains_init(struct ls_scfg_msi *msi_data)
> return 0;
> }
>
> +static int ls_scfg_msi_setup_hwirq(struct ls_scfg_msi *msi_data, int index)
> +{
> + struct ls_scfg_msir *msir;
> + int virq, i, hwirq;
> +
> + virq = platform_get_irq(msi_data->pdev, index);
> + if (virq <= 0)
> + return -ENODEV;
> +
> + msir = &msi_data->msir[index];
> + msir->index = index;
> + msir->msi_data = msi_data;
> + msir->gic_irq = virq;
> + msir->reg = msi_data->regs + MSI_MSIR_OFFSET + 4 * index;
> +
> + irq_set_chained_handler_and_data(msir->gic_irq,
> + ls_scfg_msi_irq_handler,
> + msir);
> +
> + /* Release the hwirqs corresponding to this MSIR */
> + for (i = 0; i < MSI_IRQS_PER_MSIR; i++) {
> + hwirq = i << msi_data->cfg->ibs_shift | msir->index;
> + bitmap_clear(msi_data->used, hwirq, 1);
> + }
> +
> + return 0;
> +}
> +
> +static int ls_scfg_msi_teardown_hwirq(struct ls_scfg_msir *msir)
> +{
> + struct ls_scfg_msi *msi_data = msir->msi_data;
> + int i, hwirq;
> +
> + if (msir->gic_irq > 0)
> + irq_set_chained_handler_and_data(msir->gic_irq, NULL, NULL);
> +
> + for (i = 0; i < MSI_IRQS_PER_MSIR; i++) {
> + hwirq = i << msi_data->cfg->ibs_shift | msir->index;
> + bitmap_set(msi_data->used, hwirq, 1);
> + }
> +
> + return 0;
> +}
> +
> +static struct ls_scfg_msi_cfg ls1021_msi_cfg = {
> + .ibs_shift = 3,
> +};
> +
> +static struct ls_scfg_msi_cfg ls1046_msi_cfg = {
> + .ibs_shift = 2,
> +};
> +
> +static const struct of_device_id ls_scfg_msi_id[] = {
> + { .compatible = "fsl,ls1021a-msi", .data = &ls1021_msi_cfg },
> + { .compatible = "fsl,ls1043a-msi", .data = &ls1021_msi_cfg },
> + { .compatible = "fsl,ls1046a-msi", .data = &ls1046_msi_cfg },
So after 3 patches adding compatibility between the fsl,1s10 and
fsl,ls10 names, you discard them? How does it work again with the old DTs?
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ls_scfg_msi_id);
> +
> static int ls_scfg_msi_probe(struct platform_device *pdev)
> {
> + const struct of_device_id *match;
> struct ls_scfg_msi *msi_data;
> struct resource *res;
> - int ret;
> + int i, ret;
> +
> + match = of_match_device(ls_scfg_msi_id, &pdev->dev);
> + if (!match)
> + return -ENODEV;
>
> msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL);
> if (!msi_data)
> return -ENOMEM;
>
> + msi_data->cfg = (struct ls_scfg_msi_cfg *) match->data;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> msi_data->regs = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(msi_data->regs)) {
> @@ -182,23 +265,37 @@ static int ls_scfg_msi_probe(struct platform_device *pdev)
> }
> msi_data->msiir_addr = res->start;
>
> - msi_data->irq = platform_get_irq(pdev, 0);
> - if (msi_data->irq <= 0) {
> - dev_err(&pdev->dev, "failed to get MSI irq\n");
> - return -ENODEV;
> - }
> -
> msi_data->pdev = pdev;
> spin_lock_init(&msi_data->lock);
>
> + msi_data->irqs_num = MSI_IRQS_PER_MSIR *
> + (1 << msi_data->cfg->ibs_shift);
> + msi_data->used = devm_kcalloc(&pdev->dev,
> + BITS_TO_LONGS(msi_data->irqs_num),
> + sizeof(*msi_data->used),
> + GFP_KERNEL);
> + if (!msi_data->used)
> + return -ENOMEM;
> + /*
> + * Reserve all the hwirqs
> + * The available hwirqs will be released in ls1_msi_setup_hwirq()
> + */
> + bitmap_set(msi_data->used, 0, msi_data->irqs_num);
> +
> + msi_data->msir_num = of_irq_count(pdev->dev.of_node);
> + msi_data->msir = devm_kcalloc(&pdev->dev, msi_data->msir_num,
> + sizeof(*msi_data->msir),
> + GFP_KERNEL);
> + if (!msi_data->msir)
> + return -ENOMEM;
> +
> + for (i = 0; i < msi_data->msir_num; i++)
> + ls_scfg_msi_setup_hwirq(msi_data, i);
> +
> ret = ls_scfg_msi_domains_init(msi_data);
> if (ret)
> return ret;
>
> - irq_set_chained_handler_and_data(msi_data->irq,
> - ls_scfg_msi_irq_handler,
> - msi_data);
> -
> platform_set_drvdata(pdev, msi_data);
>
> return 0;
> @@ -207,8 +304,10 @@ static int ls_scfg_msi_probe(struct platform_device *pdev)
> static int ls_scfg_msi_remove(struct platform_device *pdev)
> {
> struct ls_scfg_msi *msi_data = platform_get_drvdata(pdev);
> + int i;
>
> - irq_set_chained_handler_and_data(msi_data->irq, NULL, NULL);
> + for (i = 0; i < msi_data->msir_num; i++)
> + ls_scfg_msi_teardown_hwirq(&msi_data->msir[i]);
>
> irq_domain_remove(msi_data->msi_domain);
> irq_domain_remove(msi_data->parent);
> @@ -218,14 +317,6 @@ static int ls_scfg_msi_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct of_device_id ls_scfg_msi_id[] = {
> - { .compatible = "fsl,1s1021a-msi", }, /* a typo */
> - { .compatible = "fsl,1s1043a-msi", }, /* a typo */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
these entries definitely need to be restored.
Also, please make sure you have a cover letter at the beginning of the
series. I flag series to review by flagging the cover letter, and I
suspect many of us are doing something similar. Not doing so is likely
to leave your series unreviewed...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Lorenzo Pieralisi @ 2017-01-05 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb1a8149-7c46-39bc-f655-58ca6345f40a@linaro.org>
On Thu, Jan 05, 2017 at 08:45:37PM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 2017/1/5 3:18, Lorenzo Pieralisi wrote:
> >On Mon, Jan 02, 2017 at 09:31:36PM +0800, Hanjun Guo wrote:
> >>For devices connecting to ITS, it needs dev id to identify
> >>itself, and this dev id is represented in the IORT table in
> >>named componant node [1] for platform devices, so in this
> >>patch we will scan the IORT to retrieve device's dev id.
> >>
> >>Introduce iort_pmsi_get_dev_id() with pointer dev passed
> >>in for that purpose.
> >>
> >>[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
> >>
> >>Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>Tested-by: Sinan Kaya <okaya@codeaurora.org>
> >>Tested-by: Majun <majun258@huawei.com>
> >>Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> >>Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>Cc: Tomasz Nowicki <tn@semihalf.com>
> >>Cc: Thomas Gleixner <tglx@linutronix.de>
> >>---
> >> drivers/acpi/arm64/iort.c | 26 ++++++++++++++++++++++++++
> >> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
> >> include/linux/acpi_iort.h | 8 ++++++++
> >> 3 files changed, 37 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >>index 174e983..ab7bae7 100644
> >>--- a/drivers/acpi/arm64/iort.c
> >>+++ b/drivers/acpi/arm64/iort.c
> >>@@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> >> }
> >>
> >> /**
> >>+ * iort_pmsi_get_dev_id() - Get the device id for a device
> >>+ * @dev: The device for which the mapping is to be done.
> >>+ * @dev_id: The device ID found.
> >>+ *
> >>+ * Returns: 0 for successful find a dev id, errors otherwise
> >>+ */
> >>+int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> >>+{
> >>+ struct acpi_iort_node *node;
> >>+
> >>+ if (!iort_table)
> >>+ return -ENODEV;
> >>+
> >>+ node = iort_find_dev_node(dev);
> >>+ if (!node) {
> >>+ dev_err(dev, "can't find related IORT node\n");
> >>+ return -ENODEV;
> >>+ }
> >>+
> >>+ if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
> >
> >I disagree with this approach. For named components we know that
> >there are always two steps involved (second optional):
> >
> >(1) Retrieve the initial id (this may well provide the final mapping)
> >(2) Map the id (optional if (1) represents the map type we need)
> >
> >That's the reason why I kept iort_node_get_id() and iort_node_map_rid()
> >separated.
> >
> >Now, what we can do is to create an iort_node_map_id() function that is
> >PCI agnostic (ie rename rid to id :)), whose rid_in is either a PCI RID
> >or the outcome of a previous call to iort_node_get_id() for named
> >components, that's in my opinion cleaner.
>
> iort_node_map_rid() was designed for that purpose, and we can use it
> for platform device, the issue that we need to pass a req id
> unconditionally which is not needed for platform device, Tomasz
> proposed a similar solution to rework iort_node_map_rid(), and
> I think it makes sense.
>
> >
> >It would be even cleaner if you passed a type_mask (or write a
> >wrapper function for that) that is:
> >
> >(IORT_MSI_TYPE | IORT_IOMMU_TYPE)
>
> Sorry, I got little lost here, could you explain it in detail?
Yes sorry I was not clear. What I wanted to say is, for named
components, that do not have an intrinsic id, we have to call
iort_node_get_id() regardless of the type mask, we have to have
a way to get the "source/initial id", so basically the type_mask
is not important at all, it becomes important when it comes to
understanding what type of id the value returned from
iort_node_get_id() is.
So basically, passing:
#define IORT_TYPE_ANY (IORT_MSI_TYPE | IORT_IOMMU_TYPE)
as type_mask to iort_node_get_id() means "retrieve any kind of
initial id", that's what I wanted to say.
In iort_iommu_configure() iort_node_get_id() is a bit different because
we want only a type of id, ie a streamid, therefore the mask that we
pass in is IORT_IOMMU_TYPE.
> >and we just use the returned parent pointer to check if the mapping
> >providing the initial id correspond to the type we are looking for (eg
> >ITS) or we need to map the retrieved initial id any further, with
> >iort_node_map_id(), to get to the final identifier.
> >
> >Thoughts ?
>
> I think rework iort_node_map_rid() and not extend iort_node_get_id()
> is the right direction, could you explain a bit more then I can demo
> the code?
What you can do is create a wrapper, say iort_node_map_platform_id()
(whose signature is equivalent to iort_node_map_rid() minus rid_in)
that carries out the two steps outlined above.
To do that I suggest the following:
(1) I send a patch to "fix" iort_node_get_id() (ie index issue you
reported)
(2) We remove type_mask handling from iort_node_get_id()
(3) We create iort_node_map_platform_id() that (pseudo-code, I can
write the patch if it is clearer):
struct acpi_iort_node *iort_node_map_platform_id(u8 type_mask, int index,
...)
{
u32 id, id_out;
struct acpi_iort_node *parent = iort_node_get_id(&id, index);
if (!parent)
return NULL;
/* we should probably rename iort_node_map_rid() too */
if (!(IORT_TYPE_MASK(parent->type) & type_mask)
parent = iort_node_map_rid(parent, id, &id_out, type_mask);
return parent;
}
(4) we update current iort_node_get_id() users and move them over
to iort_node_map_platform_id()
Let me know if that's clear so that we can agree on a way forward.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH 3/3 v5] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Linus Walleij @ 2017-01-05 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105151336.18667-1-linus.walleij@linaro.org>
This adds the MPU-3050 gyroscope and the KXSD9 accelerometer to
the Qualcomm APQ8060 Dragonboard. The KXSD9 is mounted beyond the
MPU-3050 and appear as a subdevice beyond it. We set up the
required GPIO and interrupt lines to make the devices work.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v4->v5:
- No changes, just rebased on v4.10-rc1
ChangeLog v3->v4:
- Use interrupts-extended
- Add Bjorn's ACK.
ChangeLog v2->v3:
- Move the interrupt to the pm8058 alias to reflect the two patches
properly specifying the PMIC as interrupt parent.
ChangeLog v1->v2:
- Use the new I2C mux gate bindings from Peter Rosin (merged to
the I2C subsystem)
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 52 ++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index ea660ffa03ea..39d9e6ddefed 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -220,6 +220,14 @@
function = "ebi2";
};
};
+
+ /* Interrupt line for the KXSD9 accelerometer */
+ dragon_kxsd9_gpios: kxsd9 {
+ irq {
+ pins = "gpio57"; /* IRQ line */
+ bias-pull-up;
+ };
+ };
};
qcom,ssbi at 500000 {
@@ -272,6 +280,15 @@
power-source = <PM8058_GPIO_S3>;
};
};
+ dragon_mpu3050_gpios: mpu3050-gpios {
+ pinconf {
+ pins = "gpio17";
+ function = "normal";
+ input-enable;
+ bias-disable;
+ power-source = <PM8058_GPIO_S3>;
+ };
+ };
dragon_sdcc3_gpios: sdcc3-gpios {
pinconf {
pins = "gpio22";
@@ -389,6 +406,41 @@
vddd-supply = <&pm8058_lvs0>; // 1.8V
vdda-supply = <&pm8058_l14>; // 2.85V
};
+ mpu3050 at 68 {
+ compatible = "invensense,mpu3050";
+ reg = <0x68>;
+ /*
+ * GPIO17 has interrupt 208 on the
+ * PM8058, it is pulled high by a 10k
+ * resistor to VLOGIC so needs to be
+ * active low/falling edge.
+ */
+ interrupts-extended = <&pm8058 208 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_mpu3050_gpios>;
+ vlogic-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+
+ /*
+ * The MPU-3050 acts as a hub for the
+ * accelerometer.
+ */
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ kxsd9 at 18 {
+ compatible = "kionix,kxsd9";
+ reg = <0x18>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_kxsd9_gpios>;
+ iovdd-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+ };
+ };
+ };
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3 v5] ARM: dts: reference PM8058 as IRQ parent
From: Linus Walleij @ 2017-01-05 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105151336.18667-1-linus.walleij@linaro.org>
Some nodes are referencing the pm8058_gpio as IRQ parent, but
the HW IRQ offset they are supplying is actually that for the
parent to that controller: the PM8058 itself. Since that is the
proper parent, reference it directly.
We can switch this to the pm8058_gpio and the proper offset
once we have fixed the SSBI GPIO driver to properly deal with
the hierarchical IRQ domain and get proper local offset
translation.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v4->v5:
- No changes, just rebased on v4.10-rc1
ChangeLog v1->v2:
- Add Bjorn's ACK.
- Follow version numbering of the primary patch.
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 4a532ddab53a..ea660ffa03ea 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -369,8 +369,8 @@
ak8975 at 0c {
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
- /* GPIO33 has interrupt 224 on the PM8058 */
- interrupt-parent = <&pm8058_gpio>;
+ /* FIXME: GPIO33 has interrupt 224 on the PM8058 */
+ interrupt-parent = <&pm8058>;
interrupts = <224 IRQ_TYPE_EDGE_RISING>;
pinctrl-names = "default";
pinctrl-0 = <&dragon_ak8975_gpios>;
@@ -380,8 +380,8 @@
bmp085 at 77 {
compatible = "bosch,bmp085";
reg = <0x77>;
- /* GPIO16 has interrupt 207 on the PM8058 */
- interrupt-parent = <&pm8058_gpio>;
+ /* FIXME: GPIO16 has interrupt 207 on the PM8058 */
+ interrupt-parent = <&pm8058>;
interrupts = <207 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&tlmm 86 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3 v5] ARM: dts: rename MSM8660/APQ8060 pmicintc to pm8058
From: Linus Walleij @ 2017-01-05 15:13 UTC (permalink / raw)
To: linux-arm-kernel
The name "pmicintc" is ambiguous: there is a second power
management IC named PM8901 on these systems, and it is also
an interrupt controller. To make things clear, just name the
node alias "pm8058", this in unambigous and has all information
we need.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v4->v5:
- No changes, just rebased on v4.10-rc1
ChangeLog v1->v4:
- Add Bjorn's ACK.
- Follow version numbering of the primary patch.
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 2 +-
arch/arm/boot/dts/qcom-msm8660-surf.dts | 2 +-
arch/arm/boot/dts/qcom-msm8660.dtsi | 12 ++++++------
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 4b8872cc8bf9..4a532ddab53a 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -412,7 +412,7 @@
* The second interrupt is the PME interrupt
* for network wakeup, connected to the TLMM.
*/
- interrupts-extended = <&pmicintc 198 IRQ_TYPE_EDGE_FALLING>,
+ interrupts-extended = <&pm8058 198 IRQ_TYPE_EDGE_FALLING>,
<&tlmm 29 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
vdd33a-supply = <&dragon_veth>;
diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 23de764558ab..1adc04978a47 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -48,7 +48,7 @@
};
};
-&pmicintc {
+&pm8058 {
keypad at 148 {
linux,keymap = <
MATRIX_KEY(0, 0, KEY_FN_F1)
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi b/arch/arm/boot/dts/qcom-msm8660.dtsi
index 4d828f810746..91c9a62ae725 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -163,7 +163,7 @@
reg = <0x500000 0x1000>;
qcom,controller-type = "pmic-arbiter";
- pmicintc: pmic at 0 {
+ pm8058: pmic at 0 {
compatible = "qcom,pm8058";
interrupt-parent = <&tlmm>;
interrupts = <88 8>;
@@ -176,7 +176,7 @@
compatible = "qcom,pm8058-gpio",
"qcom,ssbi-gpio";
reg = <0x150>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <192 IRQ_TYPE_NONE>,
<193 IRQ_TYPE_NONE>,
<194 IRQ_TYPE_NONE>,
@@ -232,7 +232,7 @@
reg = <0x50>;
gpio-controller;
#gpio-cells = <2>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts =
<128 IRQ_TYPE_NONE>,
<129 IRQ_TYPE_NONE>,
@@ -251,7 +251,7 @@
pwrkey at 1c {
compatible = "qcom,pm8058-pwrkey";
reg = <0x1c>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <50 1>, <51 1>;
debounce = <15625>;
pull-up;
@@ -260,7 +260,7 @@
keypad at 148 {
compatible = "qcom,pm8058-keypad";
reg = <0x148>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <74 1>, <75 1>;
debounce = <15>;
scan-delay = <32>;
@@ -270,7 +270,7 @@
rtc at 1e8 {
compatible = "qcom,pm8058-rtc";
reg = <0x1e8>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <39 1>;
allow-set-time;
};
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Neil Armstrong @ 2017-01-05 15:02 UTC (permalink / raw)
To: linux-arm-kernel
The current hardware is not able to run with all cores enabled at a
cluster frequency superior at 1536MHz.
But the currently shipped u-boot for the platform still reports an OPP
table with possible DVFS frequency up to 2GHz, and will not change since
the off-tree linux tree supports limiting the OPPs with a kernel parameter.
A recent u-boot change reports the boot-time DVFS around 100MHz and
the default performance cpufreq governor sets the maximum frequency.
Previous version of u-boot reported to be already at the max OPP and
left the OPP as is.
Nevertheless, other governors like ondemand could setup the max frequency
and make the system crash.
This patch disables the DVFS clock and disables cpufreq.
Fixes: 70db166a2baa ("ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..5e63e3b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -137,6 +137,10 @@
};
};
+&scpi_dvfs {
+ status = "disabled";
+};
+
&uart_AO {
status = "okay";
pinctrl-0 = <&uart_ao_a_pins>;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v4 0/2] Add support for the ethernet switch on the ESPRESSObin
From: Andrew Lunn @ 2017-01-05 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tw9dbn2m.fsf@free-electrons.com>
On Thu, Jan 05, 2017 at 03:25:53PM +0100, Gregory CLEMENT wrote:
> Hi David,
>
> On mer., d?c. 21 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
>
> > This set of patches adds support for the Marvell ethernet switch 88E6341.
> > It also add the devicetree definition of this switch to the DT board.
>
> The forth version of this series had been sent while the net-next merge
> window was closed so I think it was missed.
Having done a bit more research, i'm pretty sure the second patch is
wrong. The 88E6341 is not compatible with the 6352, it is a different
family. It might be more like the 6390. So supporting it will need a
side-by-side comparison of the datasheet against the 6352 and the
6390, and the correct selection of the ops.
Andrew
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Sricharan @ 2017-01-05 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7cd7bcfb-abae-2948-c3f8-230c0d9c9db6@arm.com>
Hi,
[...]
>>>
>>> With the thinking of taking this series through, would it be fine if i
>>> cleanup the pci configure hanging outside and push it in to
>>> of/acpi_iommu configure respectively ? This time with all neeeded for
>>> ACPI added as well. Also on the last post of V4, Lorenzo commented
>>> that it worked for him, although still the of_match_node equivalent in
>>> ACPI has to be added. If i can get that, then i will add that as well
>>> to make this complete.
>>
>> Question: I had a look into this and instead of fiddling about with the
>> linker script entries in ACPI (ie IORT_ACPI_DECLARE - which I hope this
>> patchset would help remove entirely), I think that the only check we
>> need in IORT is, depending on what type of SMMU a given device is
>> connected to, to check if the respective SMMU driver is compiled in the
>> kernel and it will be probed, _eventually_.
>>
>> As Robin said, by the time a device is probed the respective SMMU
>> devices are already created and registered with IORT kernel code or
>> they will never be, so to understand if we should defer probing
>> SMMU device creation is _not_ really a problem in ACPI.
>>
>> To check if a SMMU driver is enabled, do we really need a linker
>> table ?
>>
>> Would not a check based on eg:
>>
>> /**
>> * @type: IOMMU IORT node type of the IOMMU a device is connected to
>> */
>> static bool iort_iommu_driver_enabled(u8 type)
>> {
>> switch (type) {
>> case ACPI_IORT_SMMU_V3:
>> return IS_ENABLED(CONFIG_ARM_SMMU_V3);
>
>IS_BUILTIN(...)
>
>> case ACPI_IORT_SMMU:
>> return IS_ENABLED(CONFIG_ARM_SMMU);
>> default:
>> pr_warn("Unknown IORT SMMU type\n");
>
>Might displaying the actual value be helfpul for debugging a broken IORT
>table?
>
>> return false;
>> }
>> }
>>
>> be sufficient (it is a bit gross, agreed, but it is to understand if
>> that's all we need) ? Is there anything I am missing ?
>>
>> Let me know, I will put together a patch for you I really do not
>> want to block your series for this trivial niggle.
>
>Other than that, though, I like it :) IORT has a small, strictly
>bounded, set of supported devices, so I really don't see the need to go
>overboard putting it on parity with DT when something this neat and
>simple will suffice.
>
Ok sure, looks correct for me as well in whole of the context here.
Regards,
Sricharan
^ permalink raw reply
* [PATCH 6/6] ARM: dts: am335x-wega: Update ethernet phy node
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483627851-17996-1-git-send-email-t.remmet@phytec.de>
Update ethernet phy1 node to use phy-handle now.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
---
arch/arm/boot/dts/am335x-wega.dtsi | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-wega.dtsi b/arch/arm/boot/dts/am335x-wega.dtsi
index e97fd6d..8ce5417 100644
--- a/arch/arm/boot/dts/am335x-wega.dtsi
+++ b/arch/arm/boot/dts/am335x-wega.dtsi
@@ -119,11 +119,17 @@
};
&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <1>;
+ phy-handle = <&phy1>;
phy-mode = "mii";
dual_emac_res_vlan = <2>;
};
+&davinci_mdio {
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ };
+};
+
&mac {
slaves = <2>;
pinctrl-names = "default";
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox