* [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: sean.wang @ 2017-01-05 16:06 UTC (permalink / raw)
To: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg
Cc: andi.shyti, hverkuil, sean, ivo.g.dimitrov.75, linux-media,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
keyhaede, Sean Wang
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 @ 2017-01-05 16:06 UTC (permalink / raw)
To: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg
Cc: andi.shyti, hverkuil, sean, ivo.g.dimitrov.75, linux-media,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
keyhaede, Sean Wang
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@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 @ 2017-01-05 16:06 UTC (permalink / raw)
To: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg
Cc: devicetree, ivo.g.dimitrov.75, keyhaede, sean, Sean Wang,
linux-kernel, andi.shyti, hverkuil, linux-mediatek,
linux-arm-kernel, linux-media
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
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-05 15:49 UTC (permalink / raw)
To: Rob Clark
Cc: Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm,
Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
In-Reply-To: <CAF6AEGsUdZALAQTozmxPV8Os=3pG7ay=1Oqtctx99FV9_4SX7Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote:
> On Thu, Jan 5, 2017 at 6:55 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> >> TODO maybe we want two options, one to enable stalling, and 2nd to punt
> >> handling to wq? I haven't needed to use mm APIs from fault handler yet
> >> (although it is something that I think we'll want some day). Perhaps
> >> stalling support is limited to just letting driver dump some extra
> >> debugging information otherwise. Threaded handling probably only useful
> >> with stalling, but inverse may not always be true.
> >
> > I'd actually like to see this stuck on a worker thread, because I think
> > that's more generally useful and I don't want to have a situation where
> > sometimes the IOMMU fault notifier is run in IRQ context and sometimes it's
> > not.
>
> So I was talking a bit w/ Jordan on IRC yesterday.. and we also have
> the GPU's hw hang-detect to contend with. So I *suspect* that when we
> get to the point of using this to do things like page in things from
> swap and resume the faulting transaction, we probably want to get
> called immediately from the IRQ handler so we can disable the hw
> hang-detect.
Well, if you want to use an SMMU for paging, then the GPU driver would
need to request that explicitly when allocating its DMA buffers, to that
would be the time to either delay or disable the hang detection.
> I'm not sure if the better solution then would be to have two fault
> callbacks, one immediately from the IRQ and a later one from wq. Or
> let the driver handle the wq business and give it a way to tell the
> IOMMU when to resume.
>
> I kinda think we should punt on the worker thread for now until we are
> ready to resume faulting transactions, because I guess a strong chance
> that whatever way we do it now will be wrong ;-)
I guess what I'm after is for you to change the interrupt handlers to be
threaded, like they are for SMMUv3. I *think* you can do that with a NULL
thread_fn for now, and just call report_iommu_fault from the handler.
The return value of that could, in theory, be used to queued the paging
request and wake the paging thread in future.
> > I wonder if this should also be predicated on the compatible string, so
> > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> > the compatible string isn't specific enough to identify an implementation
> > with the required SS behaviour? On the other hand, it feels pretty
> > redundant and a single "stalling works" property is all we need.
>
> We could also drop the property and key the behavior on specific
> compat strings I guess. Having both seems a bit odd. Anyways, I'll
> defer to DT folks about what the cleaner approach is.
As Robin pointed out, we do need to be able to distinguish the integration
of the device from the device itself. For example, MMU-9000 might be capable
of stalling, but if it's bolted to a PCI RC, it's not safe to do so.
Will
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Tony Lindgren @ 2017-01-05 15:36 UTC (permalink / raw)
To: Teresa Remmet
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, Rob Herring, Mark Rutland
In-Reply-To: <1483627851-17996-2-git-send-email-t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
* Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> [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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings
From: Maxime Ripard @ 2017-01-05 15:35 UTC (permalink / raw)
To: André Przywara
Cc: Chen-Yu Tsai, devicetree, Linus Walleij, linux-kernel,
linux-gpio@vger.kernel.org, linux-arm-kernel
In-Reply-To: <58723369-50ad-1792-9be1-c277eb719044@arm.com>
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2,9/9] irqchip/ls-scfg-msi: add MSI affinity support
From: Marc Zyngier @ 2017-01-05 15:33 UTC (permalink / raw)
To: Minghuan Lian, linux-arm-kernel, linux-kernel, devicetree
Cc: Rob Herring, Jason Cooper, Roy Zang, Stuart Yoder, Yang-Leo Li,
Scott Wood, Mingkai Hu
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
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Robin Murphy @ 2017-01-05 15:32 UTC (permalink / raw)
To: Will Deacon, Mark Rutland
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
Jordan Crouse, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170105144742.GK679-5wv7dgnIgG8@public.gmane.org>
On 05/01/17 14:47, Will Deacon wrote:
> On Thu, Jan 05, 2017 at 02:07:31PM +0000, Mark Rutland wrote:
>> On Thu, Jan 05, 2017 at 02:00:05PM +0000, Will Deacon wrote:
>>> On Thu, Jan 05, 2017 at 12:08:57PM +0000, Mark Rutland wrote:
>>>> On Thu, Jan 05, 2017 at 11:55:29AM +0000, Will Deacon wrote:
>>>>> On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
>>>>>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>>>>> index ef465b0..5f405a6 100644
>>>>>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>>>>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>>>>> @@ -68,6 +68,9 @@ conditions.
>>>>>> aliases of secure registers have to be used during
>>>>>> SMMU configuration.
>>>>>>
>>>>>> +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
>>>>>> + and resume after fault is handled
>>>>
>>>> The wording here seems to describe a policy rather than a property.
>>>>
>>>> Can you elaborate on when/why this is required/preferred/valid?
>>>
>>> It's not a policy, it's a hardware capability. There are some non-probeable
>>> reasons why stalling mode is unsafe or unusable:
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474530.html
>>
>> Ok. My point was that the wording above is an imperative -- it tells
>> the kernel to enable stall mode, not if/why it is safe to do so (i.e. it
>> is a policy, not a property).
>>
>> It sounds like that's just a wording issue. Something like
>> "arm,stalling-is-usable" (along with a descrition of when that
>> can/should be in the DT) would be vastly better.
>
> Why does it need a vendor prefix? I'm not down on the convention there.
> "stalling-safe" or "stalling-supported" are alternative strings.
>
>>>>>> static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>>>>>> @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>>>>>
>>>>>> /* SCTLR */
>>>>>> reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
>>>>>> + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
>>>>>> + reg |= SCTLR_CFCFG;
>>>>>
>>>>> I wonder if this should also be predicated on the compatible string, so
>>>>> that the "arm,smmu-enable-stall" property is ignored (with a warning) if
>>>>> the compatible string isn't specific enough to identify an implementation
>>>>> with the required SS behaviour? On the other hand, it feels pretty
>>>>> redundant and a single "stalling works" property is all we need.
>>>>
>>>> Can you elaborate on what "stalling works" entails? Is that just the SS
>>>> bit behaviour? are there integration or endpoint-specific things that we
>>>> need to care about?
>>>
>>> See above. The "stalling works" property (arm,smmu-enable-stall) would
>>> indicate that both the implementation *and* the integration are such
>>> that stalling is usable for demand paging. I suspect there are endpoints
>>> that can't deal with stalls (e.g. they might timeout and signal a RAS
>>> event), but in that case their respective device drivers should ensure
>>> that any DMA buffers are pinned and/or register a fault handler to
>>> request termination of the faulting transaction.
>>
>> Ok. It would be good to elaborate on what "stalling is useable" means in
>> the property description. i.e. what specificallty the implementation and
>> integration need to ensure.
>
> We can describe some of those guarantees in the property description, but
> it's difficult to enumerate them exhaustively. For example, you wouldn't
> want stalling to lead to data corruption, denial of service, or for the
> thing to catch fire, but having those as explicit requirements is a bit
> daft. It's also impossible to check that you thought of everything.
>
> Aside from renaming the option, I'm really after an opinion on whether
> it's better to have one property or combine it with the compatible
> string, because I can see benefits of both and don't much care either
> way.
The SMMU implementation side of the decision (i.e. independence of IRQ
assertion vs. SS) seems like exactly the sort of stuff the compatible
string already has covered. The integration side I'm less confident can
be described this way at all - the "this device definitely won't go
wrong if stalled for an indefinite length of time" is inherently a
per-master thing, so a single property on the SMMU implying that for
every device connected to it seems a bit optimistic, and breaks down as
soon as you have one device in the system for which that isn't true (a
PCI root complex, say), even if that guy's traffic never crosses paths
with whichever few devices you actually care about using stalls with.
I think this needs to be some kind of "arm,smmu-stall-safe" property
placed on individual master device nodes (mad idea: or even an extra
cell of flags in the IOMMU specifier) to encapsulate both that the given
device itself is OK with being stalled, and that it's integrated in such
a way that its stalled transactions cannot disrupt any *other* device
(e.g. it has a TBU all to itself). Then upon initialising a context bank
on a suitable SMMU implementation, we set CFCFG based on whatever device
is being attached to the corresponding domain, and refuse any subsequent
attempts to attach a non-stallable device to a stalling domain (and
possibly even vice-versa).
Robin.
>
> Will
> _______________________________________________
> iommu mailing list
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
^ permalink raw reply
* Re: [PATCH] [linux-next] bus:qcom : Fix typo in qcom,ebi2.txt
From: Linus Walleij @ 2017-01-05 15:31 UTC (permalink / raw)
To: Masanari Iida, Rob Herring
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20170105144307.21871-1-standby24x7@gmail.com>
n Thu, Jan 5, 2017 at 3:43 PM, Masanari Iida <standby24x7@gmail.com> wrote:
> This patch fix 2 spelling typos found in qcom,ebi2.txt
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Rob can you apply this fix to the devicetree git tree?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Rob Clark @ 2017-01-05 15:27 UTC (permalink / raw)
To: Will Deacon
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-arm-msm, Sricharan R, Jordan Crouse, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170105115528.GG679-5wv7dgnIgG8@public.gmane.org>
On Thu, Jan 5, 2017 at 6:55 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
>> TODO maybe we want two options, one to enable stalling, and 2nd to punt
>> handling to wq? I haven't needed to use mm APIs from fault handler yet
>> (although it is something that I think we'll want some day). Perhaps
>> stalling support is limited to just letting driver dump some extra
>> debugging information otherwise. Threaded handling probably only useful
>> with stalling, but inverse may not always be true.
>
> I'd actually like to see this stuck on a worker thread, because I think
> that's more generally useful and I don't want to have a situation where
> sometimes the IOMMU fault notifier is run in IRQ context and sometimes it's
> not.
So I was talking a bit w/ Jordan on IRC yesterday.. and we also have
the GPU's hw hang-detect to contend with. So I *suspect* that when we
get to the point of using this to do things like page in things from
swap and resume the faulting transaction, we probably want to get
called immediately from the IRQ handler so we can disable the hw
hang-detect.
I'm not sure if the better solution then would be to have two fault
callbacks, one immediately from the IRQ and a later one from wq. Or
let the driver handle the wq business and give it a way to tell the
IOMMU when to resume.
I kinda think we should punt on the worker thread for now until we are
ready to resume faulting transactions, because I guess a strong chance
that whatever way we do it now will be wrong ;-)
>>
>> Signed-off-by: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> .../devicetree/bindings/iommu/arm,smmu.txt | 3 ++
>> drivers/iommu/arm-smmu.c | 42 ++++++++++++++++++----
>> 2 files changed, 39 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index ef465b0..5f405a6 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -68,6 +68,9 @@ conditions.
>> aliases of secure registers have to be used during
>> SMMU configuration.
>>
>> +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
>> + and resume after fault is handled
>> +
>> ** Deprecated properties:
>>
>> - mmu-masters (deprecated in favour of the generic "iommus" binding) :
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index d505432..a71cb8f 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -350,6 +350,7 @@ struct arm_smmu_device {
>> u32 features;
>>
>> #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
>> +#define ARM_SMMU_OPT_ENABLE_STALL (1 << 1)
>> u32 options;
>> enum arm_smmu_arch_version version;
>> enum arm_smmu_implementation model;
>> @@ -425,6 +426,7 @@ static bool using_legacy_binding, using_generic_binding;
>>
>> static struct arm_smmu_option_prop arm_smmu_options[] = {
>> { ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
>> + { ARM_SMMU_OPT_ENABLE_STALL, "arm,smmu-enable-stall" },
>> { 0, NULL},
>> };
>>
>> @@ -676,7 +678,8 @@ static struct iommu_gather_ops arm_smmu_gather_ops = {
>>
>> static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
>> {
>> - u32 fsr, fsynr;
>> + int flags, ret;
>> + u32 fsr, fsynr, resume;
>> unsigned long iova;
>> struct iommu_domain *domain = dev;
>> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> @@ -690,15 +693,40 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
>> if (!(fsr & FSR_FAULT))
>> return IRQ_NONE;
>>
>> + if (fsr & FSR_IGN)
>> + dev_err_ratelimited(smmu->dev,
>> + "Unexpected context fault (fsr 0x%x)\n",
>> + fsr);
>> +
>> fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
>> - iova = readq_relaxed(cb_base + ARM_SMMU_CB_FAR);
>> + flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
>>
>> - dev_err_ratelimited(smmu->dev,
>> - "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cb=%d\n",
>> - fsr, iova, fsynr, cfg->cbndx);
>> + iova = readq_relaxed(cb_base + ARM_SMMU_CB_FAR);
>> + if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
>> + ret = IRQ_HANDLED;
>> + resume = RESUME_RETRY;
>> + } else {
>> + dev_err_ratelimited(smmu->dev,
>> + "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
>> + iova, fsynr, cfg->cbndx);
>> + ret = IRQ_NONE;
>> + resume = RESUME_TERMINATE;
>> + }
>>
>> + /* Clear the faulting FSR */
>> writel(fsr, cb_base + ARM_SMMU_CB_FSR);
>> - return IRQ_HANDLED;
>> +
>> + /* Retry or terminate any stalled transactions */
>> + if (fsr & FSR_SS) {
>> + /* Should we care about ending up w/ a stalled transaction
>> + * when we didn't ask for it? I guess for now best to call
>> + * attention to it and resume anyways.
>> + */
>> + WARN_ON(!(smmu->options & ARM_SMMU_OPT_ENABLE_STALL));
>
> I don't think we need to care about this. If we're getting stall faults
> with CFCFG clear, then something has gone drastically wrong in the hardware
> and we'll probably see "Unhandled context fault" anyway.
ok, I can drop the WARN_ON()
>> + writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
>> + }
>> +
>> + return ret;
>> }
>>
>> static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>> @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>
>> /* SCTLR */
>> reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
>> + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
>> + reg |= SCTLR_CFCFG;
>
> I wonder if this should also be predicated on the compatible string, so
> that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> the compatible string isn't specific enough to identify an implementation
> with the required SS behaviour? On the other hand, it feels pretty
> redundant and a single "stalling works" property is all we need.
We could also drop the property and key the behavior on specific
compat strings I guess. Having both seems a bit odd. Anyways, I'll
defer to DT folks about what the cleaner approach is.
BR,
-R
> I added the devicetree folks to CC for an opinion..
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] ARM64: dts: exynos5433-tm2: enable HDMI/TV path
From: Andrzej Hajda @ 2017-01-05 15:25 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree
In-Reply-To: <1483629943-31183-1-git-send-email-a.hajda@samsung.com>
TV path consist of following interconnected components:
- DECON_TV - display controller,
- HDMI - video signal converter RGB / HDMI,
- MHL - video signal converter HDMI / MHL,
- DDC - i2c slave device for EDID reading (on hsi2c_11 bus).
The same path/configuration is used by TM2E board and is
automatically applied thanks to dts file inclusion.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 71 +++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 060adbf..0a87670 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -236,6 +236,22 @@
};
};
+&decon_tv {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tv_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_tv>;
+ };
+ };
+ };
+};
+
&dsi {
status = "okay";
vddcore-supply = <&ldo6_reg>;
@@ -294,6 +310,33 @@
};
};
+&hdmi {
+ hpd-gpio = <&gpa3 0 0>;
+ status = "okay";
+ vdd-supply = <&ldo6_reg>;
+ vdd_osc-supply = <&ldo7_reg>;
+ vdd_pll-supply = <&ldo6_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ hdmi_to_tv: endpoint {
+ remote-endpoint = <&tv_to_hdmi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ hdmi_to_mhl: endpoint {
+ remote-endpoint = <&mhl_to_hdmi>;
+ };
+ };
+ };
+};
+
&hsi2c_0 {
status = "okay";
clock-frequency = <2500000>;
@@ -708,6 +751,30 @@
};
};
+&hsi2c_7 {
+ status = "okay";
+
+ sii8620@39 {
+ reg = <0x39>;
+ compatible = "sil,sii8620";
+ cvcc10-supply = <&ldo36_reg>;
+ iovcc18-supply = <&ldo34_reg>;
+ interrupt-parent = <&gpf0>;
+ interrupts = <2 0>;
+ reset-gpios = <&gpv7 0 GPIO_ACTIVE_LOW>;
+ clocks = <&pmu_system_controller 0>;
+ clock-names = "xtal";
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&xxti>;
+
+ port {
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+ };
+};
+
&hsi2c_8 {
status = "okay";
@@ -751,6 +818,10 @@
};
};
+&hsi2c_11 {
+ status = "okay";
+};
+
&i2s0 {
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM64: dts: exynos5433: add HDMI node
From: Andrzej Hajda @ 2017-01-05 15:25 UTC (permalink / raw)
To: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483629943-31183-1-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
HDMI converts RGB/I80 signal from DECON_TV to HDMI/TMDS video stream.
Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index b47951b..cf45446 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -843,6 +843,36 @@
iommu-names = "m0", "m1";
};
+ hdmi: hdmi@13970000 {
+ compatible = "samsung,exynos5433-hdmi";
+ reg = <0x13970000 0x70000>;
+ interrupts = <0 208 0>;
+ clocks = <&cmu_disp CLK_PCLK_HDMI>,
+ <&cmu_disp CLK_PCLK_HDMIPHY>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO>,
+ <&cmu_disp CLK_PHYCLK_HDMI_PIXEL>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY>,
+ <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_TMDS_CLKO_USER>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY>,
+ <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_PIXEL_CLKO_USER>,
+ <&xxti>, <&cmu_disp CLK_SCLK_HDMI_SPDIF>;
+ clock-names = "hdmi_pclk", "hdmi_i_pclk",
+ "i_tmds_clk", "i_pixel_clk",
+ "tmds_clko", "tmds_clko_user",
+ "pixel_clko", "pixel_clko_user",
+ "oscclk", "i_spdif_clk";
+ phy = <&hdmiphy>;
+ ddc = <&hsi2c_11>;
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,sysreg-phandle = <&syscon_disp>;
+ power-domains = <&pd_disp>;
+ status = "disabled";
+ };
+
+ hdmiphy: hdmiphy@13af0000 {
+ reg = <0x13af0000 0x80>;
+ };
+
syscon_disp: syscon@13b80000 {
compatible = "syscon";
reg = <0x13b80000 0x1010>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/3] ARM64: dts: exynos5433: add DECON_TV node
From: Andrzej Hajda @ 2017-01-05 15:25 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree
In-Reply-To: <CGME20170105152604eucas1p25340c974fa7f375905c958e2bff6d96f@eucas1p2.samsung.com>
DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
or 2nd DSI path.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 44 ++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 8cbfd1d..b47951b 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -821,6 +821,28 @@
};
};
+ decon_tv: decon@13880000 {
+ compatible = "samsung,exynos5433-decon-tv";
+ reg = <0x13880000 0x20B8>;
+ clocks = <&cmu_disp CLK_PCLK_DECON_TV>,
+ <&cmu_disp CLK_ACLK_DECON_TV>,
+ <&cmu_disp CLK_ACLK_SMMU_TV0X>,
+ <&cmu_disp CLK_ACLK_XIU_TV0X>,
+ <&cmu_disp CLK_PCLK_SMMU_TV0X>,
+ <&cmu_disp CLK_SCLK_DECON_TV_VCLK>,
+ <&cmu_disp CLK_SCLK_DECON_TV_ECLK>;
+ clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
+ "aclk_xiu_decon0x", "pclk_smmu_decon0x",
+ "sclk_decon_vclk", "sclk_decon_eclk";
+ samsung,disp-sysreg = <&syscon_disp>;
+ interrupt-names = "fifo", "vsync", "lcd_sys";
+ interrupts = <0 210 0>, <0 211 0>, <0 212 0>;
+ power-domains = <&pd_disp>;
+ status = "disabled";
+ iommus = <&sysmmu_tv0x>, <&sysmmu_tv1x>;
+ iommu-names = "m0", "m1";
+ };
+
syscon_disp: syscon@13b80000 {
compatible = "syscon";
reg = <0x13b80000 0x1010>;
@@ -926,6 +948,28 @@
power-domains = <&pd_disp>;
};
+ sysmmu_tv0x: sysmmu@0x13a20000 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x13a20000 0x1000>;
+ interrupts = <0 214 0>;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_disp CLK_PCLK_SMMU_TV0X>,
+ <&cmu_disp CLK_ACLK_SMMU_TV0X>;
+ #iommu-cells = <0>;
+ power-domains = <&pd_disp>;
+ };
+
+ sysmmu_tv1x: sysmmu@0x13a30000 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x13a30000 0x1000>;
+ interrupts = <0 216 0>;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_disp CLK_PCLK_SMMU_TV1X>,
+ <&cmu_disp CLK_ACLK_SMMU_TV1X>;
+ #iommu-cells = <0>;
+ power-domains = <&pd_disp>;
+ };
+
sysmmu_gscl0: sysmmu@0x13C80000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13C80000 0x1000>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2,7/9] irqchip/ls-scfg-msi: add LS1046a MSI support
From: Marc Zyngier @ 2017-01-05 15:19 UTC (permalink / raw)
To: Minghuan Lian, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Jason Cooper, Roy Zang, Mingkai Hu, Stuart Yoder,
Yang-Leo Li, Scott Wood
In-Reply-To: <1483603837-4629-7-git-send-email-Minghuan.Lian-3arQi8VN3Tc@public.gmane.org>
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-3arQi8VN3Tc@public.gmane.org>
> ---
> 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...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Neil Armstrong @ 2017-01-05 15:02 UTC (permalink / raw)
To: khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
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-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [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: Gregory CLEMENT
Cc: Mark Rutland, devicetree, Florian Fainelli, Romain Perier,
Jason Cooper, Pawel Moll, Vivien Didelot, netdev, Ian Campbell,
Nadav Haklai, Rob Herring, Kumar Gala, David Miller,
Thomas Petazzoni, linux-arm-kernel, Sebastian Hesselbarth
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 6/6] ARM: dts: am335x-wega: Update ethernet phy node
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Benoît Cousson
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@1 {
+ reg = <1>;
+ };
+};
+
&mac {
slaves = <2>;
pinctrl-names = "default";
--
1.9.1
^ permalink raw reply related
* [PATCH 5/6] ARM: dts: am335x-phycore-som: Update ethernet phy node
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Benoît Cousson
In-Reply-To: <1483627851-17996-1-git-send-email-t.remmet@phytec.de>
Update ethernet phy0 node to use phy-handle now.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index 08d1134..de91275 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -78,7 +78,7 @@
};
&cpsw_emac0 {
- phy_id = <&davinci_mdio>, <0>;
+ phy-handle = <&phy0>;
phy-mode = "rmii";
dual_emac_res_vlan = <1>;
};
@@ -87,6 +87,10 @@
pinctrl-names = "default";
pinctrl-0 = <&mdio_pins>;
status = "okay";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
};
&mac {
--
1.9.1
^ permalink raw reply related
* [PATCH 4/6] ARM: dts: am335x-wega: Set USB0 mode to otg
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland
In-Reply-To: <1483627851-17996-1-git-send-email-t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
Set USB0 to otg mode (default) and not fix to peripheral.
As it can be used in host mode also.
Signed-off-by: Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
---
arch/arm/boot/dts/am335x-wega.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-wega.dtsi b/arch/arm/boot/dts/am335x-wega.dtsi
index 02c6736..e97fd6d 100644
--- a/arch/arm/boot/dts/am335x-wega.dtsi
+++ b/arch/arm/boot/dts/am335x-wega.dtsi
@@ -206,7 +206,6 @@
};
&usb0 {
- dr_mode = "peripheral";
status = "okay";
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/6] ARM: dts: am335x-phycore-som: Add i2c temp sensor
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Benoît Cousson
In-Reply-To: <1483627851-17996-1-git-send-email-t.remmet@phytec.de>
Include the i2c temperature sensor which is optionaly mounted
on the phyCORE-AM335x-R2 module.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index 8060ce5..08d1134 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -120,6 +120,12 @@
reg = <0x2d>;
};
+ i2c_tmp102: temp@4b {
+ compatible = "ti,tmp102";
+ reg = <0x4b>;
+ status = "disabled";
+ };
+
i2c_eeprom: eeprom@52 {
compatible = "atmel,24c32";
pagesize = <32>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: am335x-phycore-som: Update compatible string for spi nor
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Benoît Cousson
In-Reply-To: <1483627851-17996-1-git-send-email-t.remmet@phytec.de>
As we may have different SPI NOR flashes with 8MB populated on
phyCORE-AM335x SOM, set the "jedec,spi-nor" SPI Flash compatible string.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index ef3fe5a..8060ce5 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -339,7 +339,7 @@
status = "okay";
serial_flash: m25p80@0 {
- compatible = "m25p80";
+ compatible = "jedec,spi-nor";
spi-max-frequency = <48000000>;
reg = <0x0>;
m25p,fast-read;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland
In-Reply-To: <1483627851-17996-1-git-send-email-t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
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.
Signed-off-by: Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
---
arch/arm/boot/dts/am335x-phycore-som.dtsi | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index 75e24ad..ef3fe5a 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -222,21 +222,19 @@
label = "barebox";
reg = <0x80000 0x80000>;
};
+
partition@5 {
- label = "bareboxenv";
- reg = <0x100000 0x40000>;
+ label = "barebox_backup";
+ reg = <0x100000 0x80000>;
};
+
partition@6 {
- label = "oftree";
- reg = <0x140000 0x40000>;
+ label = "bareboxenv";
+ reg = <0x180000 0x40000>;
};
partition@7 {
- label = "kernel";
- reg = <0x180000 0x800000>;
- };
- partition@8 {
label = "root";
- reg = <0x980000 0x0>;
+ reg = <0x1C0000 0x0>;
};
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/6] ARM: dts: phyBOARD-WEGA-AM335x updates
From: Teresa Remmet @ 2017-01-05 14:50 UTC (permalink / raw)
To: linux-omap, devicetree, linux-arm-kernel
Cc: Tony Lindgren, Mark Rutland, Rob Herring, Benoît Cousson
Set of small patches to update the device tree of the
phyCORE-AM335x SOM and phyBOARD-WEGA-AM335x.
Teresa Remmet (6):
ARM: dts: am335x-phycore-som: Update NAND partition table
ARM: dts: am335x-phycore-som: Update compatible string for spi nor
ARM: dts: am335x-phycore-som: Add i2c temp sensor
ARM: dts: am335x-wega: Set USB0 mode to otg
ARM: dts: am335x-phycore-som: Update ethernet phy node
ARM: dts: am335x-wega: Update ethernet phy node
arch/arm/boot/dts/am335x-phycore-som.dtsi | 30 +++++++++++++++++++-----------
arch/arm/boot/dts/am335x-wega.dtsi | 9 +++++++--
2 files changed, 26 insertions(+), 13 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v7 0/8] Add PWM and IIO timer drivers for STM32
From: Lee Jones @ 2017-01-05 14:49 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: robh+dt, mark.rutland, alexandre.torgue, devicetree, linux-kernel,
thierry.reding, linux-pwm, jic23, knaack.h, lars, pmeerw,
linux-iio, linux-arm-kernel, fabrice.gasnier, gerald.baeza,
arnaud.pouliquen, linus.walleij, linaro-kernel, Benjamin Gaignard
In-Reply-To: <1483608344-9012-1-git-send-email-benjamin.gaignard@st.com>
On Thu, 05 Jan 2017, Benjamin Gaignard wrote:
> version 7:
> - rebase on v4.10-rc2
> - remove iio_device code from driver and keep only the trigger part
>
> version 6:
> - rename stm32-gptimer in stm32-timers.
> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
> - modify "st,breakinput" parameter in pwm part.
> - split DT patch in 2
>
> version 5:
> - fix comments done on version 4
> - rebased on kernel 4.9-rc8
> - change nodes names and re-order then by addresses
>
> version 4:
> - fix comments done on version 3
> - don't use interrupts anymore in IIO timer
> - detect hardware capabilities at probe time to simplify binding
>
> version 3:
> - no change on mfd and pwm divers patches
> - add cross reference between bindings
> - change compatible to "st,stm32-timer-trigger"
> - fix attributes access rights
> - use string instead of int for master_mode and slave_mode
> - document device attributes in sysfs-bus-iio-timer-stm32
> - update DT with the new compatible
>
> version 2:
> - keep only one compatible per driver
> - use DT parameters to describe hardware block configuration:
> - pwm channels, complementary output, counter size, break input
> - triggers accepted and create by IIO timers
> - change DT to limite use of reference to the node
> - interrupt is now in IIO timer driver
> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
>
> The following patches enable PWM and IIO Timer features for STM32 platforms.
>
> Those two features are mixed into the registers of the same hardware block
> (named general purpose timer) which lead to introduce a multifunctions driver
> on the top of them to be able to share the registers.
>
> In STM32f4 14 instances of timer hardware block exist, even if they all have
> the same register mapping they could have a different number of pwm channels
> and/or different triggers capabilities. We use various parameters in DT to
> describe the differences between hardware blocks
>
> The MFD (stm32-timers.c) takes care of clock and register mapping
> by using regmap. stm32_timers structure is provided to its sub-node to
> share those information.
>
> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
> have up to 4 channels, sometime with complementary outputs or 32 bits counter
> instead of 16 bits. Some hardware blocks may also have a break input function
> which allows to stop pwm depending of a level, defined in devicetree, on an
> external pin.
>
> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
> of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
>
> The matrix of possible connections between blocks is quite complex so we use
> trigger names and is_stm32_iio_timer_trigger() function to be sure that
> triggers are valid and configure the IPs.
>
> At run time IIO timer hardware blocks can configure (through "master_mode"
> IIO device attribute) which internal signal (counter enable, reset,
> comparison block, etc...) is used to generate the trigger.
>
> Benjamin Gaignard (8):
> MFD: add bindings for STM32 Timers driver
> MFD: add STM32 Timers driver
> PWM: add pwm-stm32 DT bindings
> PWM: add PWM driver for STM32 plaftorm
> IIO: add bindings for STM32 timer trigger driver
> IIO: add STM32 timer trigger driver
> ARM: dts: stm32: add Timers driver for stm32f429 MCU
> ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
Any reason why you've dropped all your Acks?
I don't really want to review it again if little is different.
How much MFD related code has changed since the last review?
> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 +++
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++
> arch/arm/boot/dts/stm32f429.dtsi | 275 +++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
> drivers/iio/Kconfig | 1 -
> drivers/iio/trigger/Kconfig | 10 +
> drivers/iio/trigger/Makefile | 1 +
> drivers/iio/trigger/stm32-timer-trigger.c | 340 ++++++++++++++++
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 2 +
> drivers/mfd/stm32-timers.c | 80 ++++
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-stm32.c | 434 +++++++++++++++++++++
> include/linux/iio/timer/stm32-timer-trigger.h | 62 +++
> include/linux/mfd/stm32-timers.h | 71 ++++
> 18 files changed, 1455 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c
> create mode 100644 drivers/mfd/stm32-timers.c
> create mode 100644 drivers/pwm/pwm-stm32.c
> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
> create mode 100644 include/linux/mfd/stm32-timers.h
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-05 14:47 UTC (permalink / raw)
To: Mark Rutland
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <20170105140720.GA25868@leverpostej>
On Thu, Jan 05, 2017 at 02:07:31PM +0000, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 02:00:05PM +0000, Will Deacon wrote:
> > On Thu, Jan 05, 2017 at 12:08:57PM +0000, Mark Rutland wrote:
> > > On Thu, Jan 05, 2017 at 11:55:29AM +0000, Will Deacon wrote:
> > > > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > > index ef465b0..5f405a6 100644
> > > > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > > > > @@ -68,6 +68,9 @@ conditions.
> > > > > aliases of secure registers have to be used during
> > > > > SMMU configuration.
> > > > >
> > > > > +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
> > > > > + and resume after fault is handled
> > >
> > > The wording here seems to describe a policy rather than a property.
> > >
> > > Can you elaborate on when/why this is required/preferred/valid?
> >
> > It's not a policy, it's a hardware capability. There are some non-probeable
> > reasons why stalling mode is unsafe or unusable:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/474530.html
>
> Ok. My point was that the wording above is an imperative -- it tells
> the kernel to enable stall mode, not if/why it is safe to do so (i.e. it
> is a policy, not a property).
>
> It sounds like that's just a wording issue. Something like
> "arm,stalling-is-usable" (along with a descrition of when that
> can/should be in the DT) would be vastly better.
Why does it need a vendor prefix? I'm not down on the convention there.
"stalling-safe" or "stalling-supported" are alternative strings.
> > > > > static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> > > > > @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> > > > >
> > > > > /* SCTLR */
> > > > > reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
> > > > > + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
> > > > > + reg |= SCTLR_CFCFG;
> > > >
> > > > I wonder if this should also be predicated on the compatible string, so
> > > > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> > > > the compatible string isn't specific enough to identify an implementation
> > > > with the required SS behaviour? On the other hand, it feels pretty
> > > > redundant and a single "stalling works" property is all we need.
> > >
> > > Can you elaborate on what "stalling works" entails? Is that just the SS
> > > bit behaviour? are there integration or endpoint-specific things that we
> > > need to care about?
> >
> > See above. The "stalling works" property (arm,smmu-enable-stall) would
> > indicate that both the implementation *and* the integration are such
> > that stalling is usable for demand paging. I suspect there are endpoints
> > that can't deal with stalls (e.g. they might timeout and signal a RAS
> > event), but in that case their respective device drivers should ensure
> > that any DMA buffers are pinned and/or register a fault handler to
> > request termination of the faulting transaction.
>
> Ok. It would be good to elaborate on what "stalling is useable" means in
> the property description. i.e. what specificallty the implementation and
> integration need to ensure.
We can describe some of those guarantees in the property description, but
it's difficult to enumerate them exhaustively. For example, you wouldn't
want stalling to lead to data corruption, denial of service, or for the
thing to catch fire, but having those as explicit requirements is a bit
daft. It's also impossible to check that you thought of everything.
Aside from renaming the option, I'm really after an opinion on whether
it's better to have one property or combine it with the compatible
string, because I can see benefits of both and don't much care either
way.
Will
^ 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