* Re: [PATCH] ARM: dts: OMAP5 / DRA7: indicate that SATA port 0 is available.
From: Jean-Jacques Hiblot @ 2017-01-13 7:59 UTC (permalink / raw)
To: Tony Lindgren; +Cc: bcousson, linux-omap, devicetree, rogerq, stable
In-Reply-To: <20170112223627.GQ2630@atomide.com>
On 12/01/2017 23:36, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170112 14:31]:
>> * Jean-Jacques Hiblot <jjhiblot@ti.com> [170109 04:23]:
>>> AHCI provides the register PORTS_IMPL to let the software know which port
>>> is supported. The register must be initialized by the bootloader. However
>>> in some cases u-boot doesn't properly initialize this value (if it is not
>>> compiled with SATA support for example or if the SATA initialization fails).
>>> The DTS entry "ports-implemented" can be used to override the value in
>>> PORTS_IMPL.
>>> Adding this entry in the dts allows us no to worry about what is done by
>>> the bootloader.
>> Adding into omap-for-v4.11/dt thanks.
> Actually not applying just yet as I just noticed you tagged this for stable.
>
> Care to describe what breaks and on which devices without this patch?
Hi tony,
Without this patch the SATA will not work in the following two cases:
* if there has been a failure to initialize SATA in u-boot.
* if ahci_platform module has been removed and re-inserted. The reason
is that the content of PORTS_IMPL is lost after the module is removed. I
suspect that it's because the controller is reset by the hwmod.
Jean-Jacques
>
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC
From: sean.wang @ 2017-01-13 7:35 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
In-Reply-To: <1484292939-9454-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds driver for IR controller on MT7623 SoC.
and should also work on similar Mediatek 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>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/media/rc/Kconfig | 11 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 329 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 341 insertions(+)
create mode 100644 drivers/media/rc/mtk-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..9228479 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -235,6 +235,17 @@ config IR_MESON
To compile this driver as a module, choose M here: the
module will be called meson-ir.
+config IR_MTK
+ tristate "Mediatek IR remote receiver"
+ depends on RC_CORE
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say Y if you want to use the IR remote receiver available
+ on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-cir.
+
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..a78570b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
obj-$(CONFIG_IR_SERIAL) += serial_ir.o
+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..fbe7fd9
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,329 @@
+/*
+ * Driver for Mediatek 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 KBUILD_MODNAME
+
+/* 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 DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
+ MTK_IR_CLK_PERIOD)
+#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))
+#define MTK_WIDTH_MASK (GENMASK(7, 0))
+
+/* 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)
+
+/* Maximum count of samples */
+#define MTK_MAX_SAMPLES 0xff
+/* Indicate the end of IR message */
+#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ 17
+/* Source clock frequency */
+#define MTK_IR_BASE_CLK 273000000
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
+/* Period for MTK_IR_CLK in ns*/
+#define MTK_IR_CLK_PERIOD DIV_ROUND_CLOSEST(1000000000ul, \
+ MTK_IR_CLK_FREQ)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE (MTK_IR_CLK_PERIOD * 0xc00)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev: The device pointer
+ * @rc: The rc instrance
+ * @irq: The IRQ that we are using
+ * @base: The mapped register i/o base
+ * @clk: The clock that we are using
+ */
+struct mtk_ir {
+ struct device *dev;
+ struct rc_dev *rc;
+ void __iomem *base;
+ int irq;
+ struct clk *clk;
+};
+
+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);
+
+ /* Reset decoder state machine explicitly is required
+ * because 1) the longest duration for space MTK IR hardware
+ * could record is not safely long. e.g 12ms if rx resolution
+ * is 46us by default. There is still the risk to satisfying
+ * every decoder to reset themselves through long enough
+ * trailing spaces and 2) the IRQ handler guarantees that
+ * start of IR message is always contained in and starting
+ * from register MTK_CHKDATA_REG(0).
+ */
+ ir_raw_event_reset(ir->rc);
+
+ /* First message must be pulse */
+ rawir.pulse = false;
+
+ /* Handle all pulse and space IR controller captures */
+ 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 & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
+ rawir.pulse = !rawir.pulse;
+ rawir.duration = wid * (MTK_IR_SAMPLE + 1);
+ ir_raw_event_store_with_filter(ir->rc, &rawir);
+ }
+ }
+
+ /* The maximum number of edges the IR controller can
+ * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
+ * is over the limit, the last incomplete IR message would
+ * be appended trailing space and still would be sent into
+ * ir-rc-raw to decode. That helps it is possible that it
+ * has enough information to decode a scancode even if the
+ * trailing end of the message is missing.
+ */
+ if (!MTK_IR_END(wid, rawir.pulse)) {
+ rawir.pulse = false;
+ rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
+ ir_raw_event_store_with_filter(ir->rc, &rawir);
+ }
+
+ ir_raw_event_handle(ir->rc);
+
+ /* Restart controller for the next receive that would
+ * clear up all CHKDATA registers
+ */
+ mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
+
+ /* Clear interrupt status */
+ mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
+
+ 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;
+ const char *map_name;
+
+ ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
+ if (!ir)
+ return -ENOMEM;
+
+ ir->dev = dev;
+
+ if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
+ 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);
+ }
+
+ 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");
+ return PTR_ERR(ir->base);
+ }
+
+ ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
+ if (!ir->rc) {
+ dev_err(dev, "failed to allocate device\n");
+ return -ENOMEM;
+ }
+
+ ir->rc->priv = ir;
+ ir->rc->input_name = MTK_IR_DEV;
+ ir->rc->input_phys = MTK_IR_DEV "/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;
+ map_name = of_get_property(dn, "linux,rc-map-name", NULL);
+ ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
+ ir->rc->dev.parent = dev;
+ ir->rc->driver_name = MTK_IR_DEV;
+ ir->rc->allowed_protocols = RC_BIT_ALL;
+ ir->rc->rx_resolution = MTK_IR_SAMPLE;
+ ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
+
+ ret = devm_rc_register_device(dev, ir->rc);
+ if (ret) {
+ dev_err(dev, "failed to register rc device\n");
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, ir);
+
+ ir->irq = platform_get_irq(pdev, 0);
+ if (ir->irq < 0) {
+ dev_err(dev, "no irq resource\n");
+ return -ENODEV;
+ }
+
+ /* Enable interrupt after proper hardware
+ * setup and IRQ handler registration
+ */
+ if (clk_prepare_enable(ir->clk)) {
+ dev_err(dev, "try to enable ir_clk failed\n");
+ ret = -EINVAL;
+ goto exit_clkdisable_clk;
+ }
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ 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_clkdisable_clk;
+ }
+
+ /* Enable IR and PWM */
+ 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, sample period = %luus\n",
+ DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
+
+ return 0;
+
+exit_clkdisable_clk:
+ clk_disable_unprepare(ir->clk);
+
+ return ret;
+}
+
+static int mtk_ir_remove(struct platform_device *pdev)
+{
+ struct mtk_ir *ir = platform_get_drvdata(pdev);
+
+ /* Avoid contention between remove handler and
+ * IRQ handler so that disabling IR interrupt and
+ * waiting for pending IRQ handler to complete
+ */
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+ synchronize_irq(ir->irq);
+
+ clk_disable_unprepare(ir->clk);
+
+ return 0;
+}
+
+static const struct of_device_id mtk_ir_match[] = {
+ { .compatible = "mediatek,mt7623-cir" },
+ {},
+};
+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 IR Receiver Controller Driver");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: sean.wang @ 2017-01-13 7:35 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
In-Reply-To: <1484292939-9454-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds documentation for devicetree bindings for
consumer Mediatek IR controller.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
.../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 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..2be2005
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,24 @@
+Device-Tree bindings for Mediatek consumer IR controller
+found in Mediatek SoC family
+
+Required properties:
+- compatible : "mediatek,mt7623-cir"
+- 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 : see rc.txt file in the same directory.
+
+Example:
+
+cir: cir@10013000 {
+ compatible = "mediatek,mt7623-cir";
+ 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 v3 1/3] Documentation: devicetree: move shared property used by rc into a common place
From: sean.wang @ 2017-01-13 7:35 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
In-Reply-To: <1484292939-9454-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Most IR drivers uses the same label to identify the
scancdoe/key table they used by multiple bindings and lack
explanation well. So move the shared property into a common
place and give better explanation.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
.../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +-
.../devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
Documentation/devicetree/bindings/media/rc.txt | 116 +++++++++++++++++++++
.../devicetree/bindings/media/sunxi-ir.txt | 2 +-
4 files changed, 120 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/rc.txt
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
index 56e726e..58261fb 100644
--- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -5,7 +5,8 @@ Required properties:
- gpios: specifies GPIO used for IR signal reception.
Optional properties:
- - linux,rc-map-name: Linux specific remote control map name.
+ - linux,rc-map-name: see rc.txt file in the same
+ directory.
Example node:
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
index 54e1bed..13ebc0f 100644
--- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -10,7 +10,7 @@ Required properties:
- clocks: clock phandle and specifier pair.
Optional properties:
- - linux,rc-map-name : Remote control map name.
+ - linux,rc-map-name: see rc.txt file in the same directory.
- hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files.
Provide correct clocks instead.
diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt
new file mode 100644
index 0000000..0d16d14
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rc.txt
@@ -0,0 +1,116 @@
+The following properties are common to the infrared remote controllers:
+
+- linux,rc-map-name: string, specifies the scancode/key mapping table
+ defined in-kernel for the remote controller. Support values are:
+ * "rc-adstech-dvb-t-pci"
+ * "rc-alink-dtu-m"
+ * "rc-anysee"
+ * "rc-apac-viewcomp"
+ * "rc-asus-pc39"
+ * "rc-asus-ps3-100"
+ * "rc-ati-tv-wonder-hd-600"
+ * "rc-ati-x10"
+ * "rc-avermedia-a16d"
+ * "rc-avermedia-cardbus"
+ * "rc-avermedia-dvbt"
+ * "rc-avermedia-m135a"
+ * "rc-avermedia-m733a-rm-k6"
+ * "rc-avermedia-rm-ks"
+ * "rc-avermedia"
+ * "rc-avertv-303"
+ * "rc-azurewave-ad-tu700"
+ * "rc-behold-columbus"
+ * "rc-behold"
+ * "rc-budget-ci-old"
+ * "rc-cec"
+ * "rc-cinergy-1400"
+ * "rc-cinergy"
+ * "rc-delock-61959"
+ * "rc-dib0700-nec"
+ * "rc-dib0700-rc5"
+ * "rc-digitalnow-tinytwin"
+ * "rc-digittrade"
+ * "rc-dm1105-nec"
+ * "rc-dntv-live-dvbt-pro"
+ * "rc-dntv-live-dvb-t"
+ * "rc-dtt200u"
+ * "rc-dvbsky"
+ * "rc-empty"
+ * "rc-em-terratec"
+ * "rc-encore-enltv2"
+ * "rc-encore-enltv-fm53"
+ * "rc-encore-enltv"
+ * "rc-evga-indtube"
+ * "rc-eztv"
+ * "rc-flydvb"
+ * "rc-flyvideo"
+ * "rc-fusionhdtv-mce"
+ * "rc-gadmei-rm008z"
+ * "rc-genius-tvgo-a11mce"
+ * "rc-gotview7135"
+ * "rc-hauppauge"
+ * "rc-imon-mce"
+ * "rc-imon-pad"
+ * "rc-iodata-bctv7e"
+ * "rc-it913x-v1"
+ * "rc-it913x-v2"
+ * "rc-kaiomy"
+ * "rc-kworld-315u"
+ * "rc-kworld-pc150u"
+ * "rc-kworld-plus-tv-analog"
+ * "rc-leadtek-y04g0051"
+ * "rc-lirc"
+ * "rc-lme2510"
+ * "rc-manli"
+ * "rc-medion-x10"
+ * "rc-medion-x10-digitainer"
+ * "rc-medion-x10-or2x"
+ * "rc-msi-digivox-ii"
+ * "rc-msi-digivox-iii"
+ * "rc-msi-tvanywhere-plus"
+ * "rc-msi-tvanywhere"
+ * "rc-nebula"
+ * "rc-nec-terratec-cinergy-xs"
+ * "rc-norwood"
+ * "rc-npgtech"
+ * "rc-pctv-sedna"
+ * "rc-pinnacle-color"
+ * "rc-pinnacle-grey"
+ * "rc-pinnacle-pctv-hd"
+ * "rc-pixelview-new"
+ * "rc-pixelview"
+ * "rc-pixelview-002t"
+ * "rc-pixelview-mk12"
+ * "rc-powercolor-real-angel"
+ * "rc-proteus-2309"
+ * "rc-purpletv"
+ * "rc-pv951"
+ * "rc-hauppauge"
+ * "rc-rc5-tv"
+ * "rc-rc6-mce"
+ * "rc-real-audio-220-32-keys"
+ * "rc-reddo"
+ * "rc-snapstream-firefly"
+ * "rc-streamzap"
+ * "rc-tbs-nec"
+ * "rc-technisat-ts35"
+ * "rc-technisat-usb2"
+ * "rc-terratec-cinergy-c-pci"
+ * "rc-terratec-cinergy-s2-hd"
+ * "rc-terratec-cinergy-xs"
+ * "rc-terratec-slim"
+ * "rc-terratec-slim-2"
+ * "rc-tevii-nec"
+ * "rc-tivo"
+ * "rc-total-media-in-hand"
+ * "rc-total-media-in-hand-02"
+ * "rc-trekstor"
+ * "rc-tt-1500"
+ * "rc-twinhan-dtv-cab-ci"
+ * "rc-twinhan1027"
+ * "rc-videomate-k100"
+ * "rc-videomate-s350"
+ * "rc-videomate-tv-pvr"
+ * "rc-winfast"
+ * "rc-winfast-usbii-deluxe"
+ * "rc-su3000"
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 1811a06..302a0b1 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -9,7 +9,7 @@ Required properties:
- reg : should contain IO map address for IR.
Optional properties:
-- linux,rc-map-name : Remote control map name.
+- linux,rc-map-name: see rc.txt file in the same directory.
- resets : phandle + reset specifier pair
Example:
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/3] media: rc: add support for IR receiver on MT7623 SoC
From: sean.wang @ 2017-01-13 7:35 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 on MT7623 SoC
that also works on other similar SoCs 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.
Changes since v1:
- change compatible string from "mediatek,mt7623-ir" into
"mediatek,mt7623-cir"
- use KBUILD_MODNAME to provide consistent device name used in driver.
- remove unused fields in struct mtk_ir.
- use synchronize_irq to give protection between IRQ handler and
remove handler.
- use devm_rc_allocate_device based on Andi Shyti's work.
- simplify error handling patch with devm_rc_register_device and devm_rc_allocate_device.
- remove unused spinlock.
- add comments about hardware limitation and related workarounds.
- enhance the caculation of sampling period for easiler assigned specific
value.
- refine git description.
- fix IR message handling between IR hardware and rc-core.
Changes since v2:
- remove extra rc_unregister_device to avoid double frees issue
since rc_unregister_device was used.
- enhance comments description
- remove redundant mtk irq disable/enable pair inside the IRQ handler
- move keymap table property document into a common place
Sean Wang (3):
Documentation: devicetree: move shared property used by rc into a
common place
Documentation: devicetree: Add document bindings for mtk-cir
media: rc: add driver for IR remote receiver on MT7623 SoC
.../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +-
.../devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
.../devicetree/bindings/media/mtk-cir.txt | 23 ++
Documentation/devicetree/bindings/media/rc.txt | 116 ++++++++
.../devicetree/bindings/media/sunxi-ir.txt | 2 +-
drivers/media/rc/Kconfig | 11 +
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 330 +++++++++++++++++++++
8 files changed, 485 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
create mode 100644 Documentation/devicetree/bindings/media/rc.txt
create mode 100644 drivers/media/rc/mtk-cir.c
--
1.9.1
^ permalink raw reply
* Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-13 7:26 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, Russell King, linux-i2c,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <CAOAejn1HAU5spQeXmYPH4XH0L5bGuoFgguozwMp=uLKcXDEPEw@mail.gmail.com>
Hello,
On Thu, Jan 12, 2017 at 10:28:20PM +0100, M'boumba Cedric Madianga wrote:
> Please see below a quote from datasheet that clearly described how to handle
> For 2-byte reception:
> ● Wait until ADDR = 1 (SCL stretched low until the ADDR flag is cleared)
> ● Set ACK low, set POS high
> ● Clear ADDR flag
> ● Wait until BTF = 1 (Data 1 in DR, Data2 in shift register, SCL
> stretched low until a data1 is read)
> ● Set STOP high
> ● Read data 1 and 2
The problem is that you only know that you have a 2 byte transfer after
you read the first byte (and it's a 1). (But note that this is
irrelevant for the patch as the driver doesn't claim to support this
kind of transfer.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v4 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Greg KH @ 2017-01-13 7:22 UTC (permalink / raw)
To: Serge Semin
Cc: srinivas.kandagatla, andrew, robh+dt, mark.rutland, Sergey.Semin,
linux-kernel, devicetree
In-Reply-To: <20170112225417.GA21220@mobilestation>
On Fri, Jan 13, 2017 at 01:54:17AM +0300, Serge Semin wrote:
> On Wed, Jan 11, 2017 at 09:21:19AM +0100, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > + /* Return failure if root directory doesn't exist */
> > > + if (!csr_dbgdir) {
> > > + dev_dbg(dev, "No Debugfs root directory");
> > > + return -EINVAL;
> > > + }
> >
> > If debugfs is not enabled, don't error out, just keep going, it should
> > never stop kernel code from running properly.
> >
> > Also, this test isn't really doing what you think it is doing...
> >
>
> I see, it must be replaced with IS_ERR_OR_NULL() test.
No! That's a pain, when the debugfs interface was created its goal was
to make it _easy_ to use, not hard. IS_ERR_OR_NULL() is hard, and
messy, don't do that.
> But I don't think,
> it would be good to get rid of dev_dbg() completely here. In case if
> debugging is enabled, user would understand why csr-node isn't created within
> DebugFS directory. I don't see the reasoning why one shouldn't know a source
> of possible problems.
> (See the next comment as continue of the discussion)
Why would a user care about debugfs?
> > > + /* Create Debugfs directory for CSR file */
> > > + snprintf(fname, CSRNAME_LEN, "%d-%04hx", cli->adapter->nr, cli->addr);
> > > + pdev->csr_dir = debugfs_create_dir(fname, csr_dbgdir);
> > > + if (IS_ERR_OR_NULL(pdev->csr_dir)) {
> > > + dev_err(dev, "Failed to create CSR node directory");
> > > + return -EINVAL;
> >
> > Again, don't do this, you really don't care if debugfs worked or not.
> >
>
> Actually the driver doesn't stop the kernel code from running, if it finds out
> any problem with DebugFS CSR-node creation. The function just logs the error
> and return error status. Take a look the place the method is called:
> 1489 /* Create debugfs files */
> 1490 (void)idt_create_dbgfs_files(pdev);
> The initialization code doesn't check the return value at all, so the driver
> will proceed with further code.
> Why did I make the function with return value? Because it's a good style to
> always return a status of function code execution if it may fail, but only
> caller will decide whether to check the return value or not.
There is only one type of error that a debugfs call can return, and that
is if debugfs is not enabled in the build. That's it, you don't need to
care about any of that.
> Regarding the error printing. In case if the code gets to this check, one can
> be sure the DebugFS works properly, so in case if the driver failed to create
> the corresponding sub-directory or node, it is really error to have any failure
> at this point, and a user should be notified. But still the driver won't stop
> functioning, since the caller doesn't check the return value.
>
> Hopefully you'll understand my point.
Please understand mine, debugfs is supposed to be easy to use, you are
not testing things properly here, and when you are, it doesn't matter.
Just call the functions, save the return results if you need to (for
dentries and the like), and move on. No error handling needed AT ALL!
Yes, it feels "odd" for kernel code, but remember, this is only for
debugging. Your code should not have any different codepaths for if the
debugging logic worked or not. It doesn't care at all. So please, make
it simple.
> > > + dev_dbg(dev, "Debugfs-files created");
> >
> > You do know about ftrace, right? Please remove all of these
> > "trace-like" debugging lines, they aren't needed for anyone.
> >
>
> Ok, I'll remove all these prints, even though I do find these prints being
> handy to have initialization process printed on debugging stage.
Then use ftrace, that is what it is there for, don't roll your own
driver-specific-functionality please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Shawn Lin @ 2017-01-13 7:16 UTC (permalink / raw)
To: Matt Ranostay, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw, tony-4v6yS6AI5VpBDgjK7y7TUQ,
Ulf Hansson
In-Reply-To: <20170113052937.12538-3-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
On 2017/1/13 13:29, Matt Ranostay wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
>
> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> ---
> drivers/mmc/core/Kconfig | 10 ++++
> drivers/mmc/core/Makefile | 1 +
> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 128 insertions(+)
> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index cdfa8520a4b1..fc1ecdaaa9ca 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
> This driver can also be built as a module. If so, the module
> will be called pwrseq_emmc.
>
> +config PWRSEQ_SD8787
> + tristate "HW reset support for SD8787 BT + Wifi module"
> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
> + help
> + This selects hardware reset support for the SD8787 BT + Wifi
> + module. By default this option is set to n.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pwrseq_sd8787.
> +
I don't like this way, as we have a chance to list lots
configure options here. wifi A,B,C,D...Z, all of them need a
new section here if needed?
Instead, could you just extent pwrseq_simple.c and add you
.compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
> config PWRSEQ_SIMPLE
> tristate "Simple HW reset support for MMC"
> default y
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index b2a257dc644f..0f81464fa824 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
> quirks.o slot-gpio.o
> mmc_core-$(CONFIG_OF) += pwrseq.o
> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
> diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
> new file mode 100644
> index 000000000000..f4080fe6439e
> --- /dev/null
> +++ b/drivers/mmc/core/pwrseq_sd8787.c
> @@ -0,0 +1,117 @@
> +/*
> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
> + *
> + * Copyright (C) 2016 Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> + *
> + * Based on the original work pwrseq_simple.c
> + * Copyright (C) 2014 Linaro Ltd
> + * Author: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> + *
> + * 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/delay.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +
> +#include <linux/mmc/host.h>
> +
> +#include "pwrseq.h"
> +
> +struct mmc_pwrseq_sd8787 {
> + struct mmc_pwrseq pwrseq;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *pwrdn_gpio;
> +};
> +
> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
> +
> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
> +
> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
> +
> + msleep(300);
> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
> +}
> +
> +static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
> +
> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
> +}
> +
> +static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
> + .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
> + .power_off = mmc_pwrseq_sd8787_power_off,
> +};
> +
> +static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
> + { .compatible = "mmc-pwrseq-sd8787",},
> + {/* sentinel */},
> +};
> +MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
> +
> +static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq;
> + struct device *dev = &pdev->dev;
> +
> + pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
> + if (!pwrseq)
> + return -ENOMEM;
> +
> + pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
> + if (IS_ERR(pwrseq->pwrdn_gpio))
> + return PTR_ERR(pwrseq->pwrdn_gpio);
> +
> + pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(pwrseq->reset_gpio))
> + return PTR_ERR(pwrseq->reset_gpio);
> +
> + pwrseq->pwrseq.dev = dev;
> + pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
> + pwrseq->pwrseq.owner = THIS_MODULE;
> + platform_set_drvdata(pdev, pwrseq);
> +
> + return mmc_pwrseq_register(&pwrseq->pwrseq);
> +}
> +
> +static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
> +
> + mmc_pwrseq_unregister(&pwrseq->pwrseq);
> +
> + return 0;
> +}
> +
> +static struct platform_driver mmc_pwrseq_sd8787_driver = {
> + .probe = mmc_pwrseq_sd8787_probe,
> + .remove = mmc_pwrseq_sd8787_remove,
> + .driver = {
> + .name = "pwrseq_sd8787",
> + .of_match_table = mmc_pwrseq_sd8787_of_match,
> + },
> +};
> +
> +module_platform_driver(mmc_pwrseq_sd8787_driver);
> +MODULE_LICENSE("GPL v2");
>
--
Best Regards
Shawn Lin
--
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 18/18] insert build break
From: Greg KH @ 2017-01-13 7:15 UTC (permalink / raw)
To: christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, jk-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, Chris Bostic
In-Reply-To: <1484260655-80477-1-git-send-email-christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jan 12, 2017 at 04:37:35PM -0600, christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> From: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
I can not accept patches that have no changelog text, and this one is
very odd:
> ---
> drivers/fsi/fsi-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index 28b82d1..db09836 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -42,6 +42,7 @@
>
> static DEFINE_IDA(master_ida);
>
> +
Huh?
Did something go wrong with your scripts?
greg k-h
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Guochun Mao @ 2017-01-13 7:13 UTC (permalink / raw)
To: David Woodhouse, Brian Norris
Cc: Mark Rutland, Boris Brezillon, Guochun Mao,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
Russell King, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Marek Vasut,
Rob Herring, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Matthias Brugger, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Cyrille Pitchen,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484291609-20195-1-git-send-email-guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Add Mediatek nor flash node.
Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
2 files changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..85e5ae8 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,31 @@
};
};
+&nor_flash {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nor_pins_default>;
+ status = "okay";
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ };
+};
+
+&pio {
+ nor_pins_default: nor {
+ pins1 {
+ pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
+ <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
+ <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
+ <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
+ <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
+ <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
+ drive-strength = <MTK_DRIVE_4mA>;
+ bias-pull-up;
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..1eefce4 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,18 @@
status = "disabled";
};
+ nor_flash: spi@11014000 {
+ compatible = "mediatek,mt2701-nor",
+ "mediatek,mt8173-nor";
+ reg = <0 0x11014000 0 0xe0>;
+ clocks = <&pericfg CLK_PERI_FLASH>,
+ <&topckgen CLK_TOP_FLASH_SEL>;
+ clock-names = "spi", "sf";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v1 1/2] Documentation: mtk-quadspi: update DT bindings
From: Guochun Mao @ 2017-01-13 7:13 UTC (permalink / raw)
To: David Woodhouse, Brian Norris
Cc: Mark Rutland, Boris Brezillon, Guochun Mao, devicetree,
Richard Weinberger, Russell King, linux-kernel, Marek Vasut,
Rob Herring, linux-mtd, Matthias Brugger, linux-mediatek,
Cyrille Pitchen, linux-arm-kernel
In-Reply-To: <1484291609-20195-1-git-send-email-guochun.mao@mediatek.com>
Add "mediatek,mt2701-nor" for nor flash node's compatible.
Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
.../devicetree/bindings/mtd/mtk-quadspi.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
index fb314f0..f83d31d 100644
--- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
@@ -1,7 +1,9 @@
* Serial NOR flash controller for MTK MT81xx (and similar)
Required properties:
-- compatible: should be "mediatek,mt8173-nor";
+- compatible: should contain:
+ "mediatek,mt2701-nor" for MT2701,
+ "mediatek,mt8173-nor" for MT8173.
- reg: physical base address and length of the controller's register
- clocks: the phandle of the clocks needed by the nor controller
- clock-names: the names of the clocks
--
1.7.9.5
^ permalink raw reply related
* [PATCH v1 0/2] add nor flash node for mt2701
From: Guochun Mao @ 2017-01-13 7:13 UTC (permalink / raw)
To: David Woodhouse, Brian Norris
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Russell King, linux-kernel, Marek Vasut, Rob Herring, linux-mtd,
Matthias Brugger, linux-mediatek, Cyrille Pitchen,
linux-arm-kernel
This patch series based on v4.10-rc2, include MT2701 spinor node and bindings.
Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html
Guochun Mao (2):
Documentation: mtk-quadspi: update DT bindings
arm: dts: mt2701: add nor flash node
.../devicetree/bindings/mtd/mtk-quadspi.txt | 4 +++-
arch/arm/boot/dts/mt2701-evb.dts | 25 ++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 12 +++++++++++
3 files changed, 40 insertions(+), 1 deletion(-)
--
1.8.1.1.dirty
^ permalink raw reply
* RE: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Appana Durga Kedareswara Rao @ 2017-01-13 6:33 UTC (permalink / raw)
To: Vinod Koul
Cc: mark.rutland@arm.com, moritz.fischer@ettus.com,
devicetree@vger.kernel.org, michal.simek@xilinx.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, Soren Brinkmann,
luis@debethencourt.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, Jose.Abreu@synopsys.com,
linux-arm-kernel@lists.infradead.org,
laurent.pinchart@ideasonboard.com
In-Reply-To: <20170113062225.GR3573@localhost>
Hi Vinod,
Thanks for the review...
[Snip]
> > > Btw how and when does DMA stop, assuming it is circular it never
> > > would, isn't there a valid/stop flag associated with a descriptor
> > > which tells DMA engine what to do next
> >
> > There are two registers that controls the DMA transfers.
> > Current descriptor and tail descriptor register.
> > When current descriptor reaches tail descriptor dma engine will pause.
> >
> > When reprogramming the tail descriptor the DMA engine will starts fetching
> descriptors again.
> >
> > But with the existing driver flow if we reprogram the tail descriptor
> > The tail descriptor next descriptor field is pointing to an invalid
> > location Causing data corruption...
>
> So the solution is..?
This patch.
I mean if we have a set of descriptors in chain (in circular manner last descriptor points to first descriptor)
It always points to valid descriptors.
Will update the patch commit description in the next version...
>
> > > Btw there is something wrong with your MUA perhaps line are
> > > titlecased for no reason. This is typically behavious of non linux
> > > tool which may not be great tool for this work.
> >
> > Thanks for pointing it out.
> > I usually replies from outlook from a windows machine.
> > Will check with others in my team how they configured their mail client.
>
> Yeah that isnt right tool for the job. See Documentation/process/email-
> clients.rst
>
> FWIW, I use mutt, vim as editor with exchange servers, seems to work well for
> me now.
Thanks for pointing it out will go through it.
Will install mutt in my Linux machine will start replying from that
Regards,
Kedar.
>
> --
> ~Vinod
^ permalink raw reply
* Re: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Vinod Koul @ 2017-01-13 6:22 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
dan.j.williams@intel.com, michal.simek@xilinx.com,
Soren Brinkmann, moritz.fischer@ettus.com,
laurent.pinchart@ideasonboard.com, luis@debethencourt.com,
Jose.Abreu@synopsys.com, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A6666CF@XAP-PVEXMBX01.xlnx.xilinx.com>
On Fri, Jan 13, 2017 at 06:00:44AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
>
> [Snip]
> > >
> > > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > > > descriptors back to back on the S2MM(recv) side with the current
> > > > > driver flow the last buffer descriptor next bd points to a invalid
> > > > > location resulting the invalid data or errors in the DMA engine.
> > > >
> > > > Can you rephrase this, it a bit hard to understand.
> > >
> > > When DMA is receiving packets h/w expects the descriptors Should be in
> > > the form of a ring (I mean h/w buffer descriptor Next descriptor field
> > > should always point to valid address So that when DMA engine go and
> > > fetch that next descriptor it always Sees a valid address).
> > >
> > >
> > > But with the current driver implementation when user queues Multiple
> > > descriptors the last descriptor next descriptor field Pointing to an
> > > invalid location causing data corruption or Errors from the DMA h/w
> > > engine...
> > >
> > > To avoid this issue creating a Buffer descriptor Chain during Channel
> > > allocation and using those buffer descriptors for processing User
> > > requested data.
> >
> > Is it not doable to to modify the next pointer to point to subsequent transaction.
> > IOW you are modifying tail descriptor to point to subsequent descriptor.
> >
> > Btw how and when does DMA stop, assuming it is circular it never would, isn't
> > there a valid/stop flag associated with a descriptor which tells DMA engine what
> > to do next
>
> There are two registers that controls the DMA transfers.
> Current descriptor and tail descriptor register.
> When current descriptor reaches tail descriptor dma engine will pause.
>
> When reprogramming the tail descriptor the DMA engine will starts fetching descriptors again.
>
> But with the existing driver flow if we reprogram the tail descriptor
> The tail descriptor next descriptor field is pointing to an invalid location
> Causing data corruption...
So the solution is..?
> > Btw there is something wrong with your MUA perhaps line are titlecased for no
> > reason. This is typically behavious of non linux tool which may not be great tool
> > for this work.
>
> Thanks for pointing it out.
> I usually replies from outlook from a windows machine.
> Will check with others in my team how they configured their mail client.
Yeah that isnt right tool for the job. See
Documentation/process/email-clients.rst
FWIW, I use mutt, vim as editor with exchange servers, seems to work well
for me now.
--
~Vinod
^ permalink raw reply
* Re: [PATCH 4/5] Input: mpr121 - use matrix keypad helper API
From: Dmitry Torokhov @ 2017-01-13 6:18 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484156549-26585-5-git-send-email-akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Akinobu,
On Thu, Jan 12, 2017 at 02:42:28AM +0900, Akinobu Mita wrote:
> Convert to use matrix_kaypad_build_keymap() helper.
>
> This is preparation for adding device tree support. This change enables
> to share code between legacy platform data probe and device tree probe.
I feel that matrix keymap is overkill here. We have standardish
linus,keycodes property for non-matrix keys/buttons; I think it should
be used here as well. For example of parsing see atmel_captouch_probe().
Also, I do not see anyone in mainline actually using mpr121 platform
data and the driver was merged in 2011. Therefore let's use generic
device properties to fetch keymap and other parameters and get rid of
platform data. If there are legacy (non-DT) boards they can define
property sets in their board-specific code.
Also, could you make a patch removing #ifdef CONFIG_PM_SLEEP and mark
suspend/resume handlers as __maybe_unused instead?
Thanks!
>
> Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/input/keyboard/Kconfig | 1 +
> drivers/input/keyboard/mpr121_touchkey.c | 64 +++++++++++++++++++++-----------
> 2 files changed, 43 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index cbd75cf..b436e71 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -407,6 +407,7 @@ config KEYBOARD_MCS
> config KEYBOARD_MPR121
> tristate "Freescale MPR121 Touchkey"
> depends on I2C
> + select INPUT_MATRIXKMAP
> help
> Say Y here if you have Freescale MPR121 touchkey controller
> chip in your system.
> diff --git a/drivers/input/keyboard/mpr121_touchkey.c b/drivers/input/keyboard/mpr121_touchkey.c
> index c809f70..7e85512 100644
> --- a/drivers/input/keyboard/mpr121_touchkey.c
> +++ b/drivers/input/keyboard/mpr121_touchkey.c
> @@ -20,6 +20,7 @@
> #include <linux/bitops.h>
> #include <linux/interrupt.h>
> #include <linux/i2c/mpr121_touchkey.h>
> +#include <linux/input/matrix_keypad.h>
>
> /* Register definitions */
> #define ELE_TOUCH_STATUS_0_ADDR 0x0
> @@ -61,7 +62,6 @@ struct mpr121_touchkey {
> struct input_dev *input_dev;
> unsigned int statusbits;
> unsigned int keycount;
> - u16 keycodes[MPR121_MAX_KEY_COUNT];
> };
>
> struct mpr121_init_register {
> @@ -88,6 +88,7 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
> struct input_dev *input = mpr121->input_dev;
> unsigned int bit_changed;
> unsigned int key_num;
> + const unsigned short *keycode = input->keycode;
> int reg;
>
> reg = i2c_smbus_read_byte_data(client, ELE_TOUCH_STATUS_1_ADDR);
> @@ -114,7 +115,7 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
> continue;
>
> pressed = reg & (1 << key_num);
> - key_val = mpr121->keycodes[key_num];
> + key_val = keycode[key_num];
>
> input_event(input, EV_MSC, MSC_SCAN, key_num);
> input_report_key(input, key_val, pressed);
> @@ -196,23 +197,46 @@ static int mpr_touchkey_probe(struct i2c_client *client,
> {
> const struct mpr121_platform_data *pdata =
> dev_get_platdata(&client->dev);
> + struct device *dev = &client->dev;
> + unsigned int keymap_size;
> + struct matrix_keymap_data *keymap_data;
> struct mpr121_touchkey *mpr121;
> struct input_dev *input_dev;
> int error;
> int i;
>
> - if (!pdata) {
> - dev_err(&client->dev, "no platform data defined\n");
> - return -EINVAL;
> - }
> + if (pdata) {
> + uint32_t *keymap;
>
> - if (!pdata->keymap || !pdata->keymap_size) {
> - dev_err(&client->dev, "missing keymap data\n");
> - return -EINVAL;
> - }
> + if (!pdata->keymap || !pdata->keymap_size) {
> + dev_err(dev, "missing keymap data\n");
> + return -EINVAL;
> + }
> +
> + if (pdata->keymap_size > MPR121_MAX_KEY_COUNT) {
> + dev_err(dev, "too many keys defined\n");
> + return -EINVAL;
> + }
> +
> + keymap_size = pdata->keymap_size;
> +
> + keymap = devm_kcalloc(dev, keymap_size,
> + sizeof(keymap_data->keymap[0]), GFP_KERNEL);
> + if (!keymap)
> + return -ENOMEM;
>
> - if (pdata->keymap_size > MPR121_MAX_KEY_COUNT) {
> - dev_err(&client->dev, "too many keys defined\n");
> + for (i = 0; i < keymap_size; i++)
> + keymap[i] = KEY(0, i, pdata->keymap[i]);
> +
> + keymap_data = devm_kzalloc(dev, sizeof(*keymap_data),
> + GFP_KERNEL);
> + if (!keymap_data)
> + return -ENOMEM;
> +
> + keymap_data->keymap_size = keymap_size;
> + keymap_data->keymap = keymap;
> + } else {
> + dev_err(&client->dev, "no platform data defined\n");
> return -EINVAL;
> }
>
> @@ -232,22 +256,18 @@ static int mpr_touchkey_probe(struct i2c_client *client,
>
> mpr121->client = client;
> mpr121->input_dev = input_dev;
> - mpr121->keycount = pdata->keymap_size;
> + mpr121->keycount = keymap_size;
>
> input_dev->name = "Freescale MPR121 Touchkey";
> input_dev->id.bustype = BUS_I2C;
> input_dev->dev.parent = &client->dev;
> - input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
> + input_dev->evbit[0] = BIT_MASK(EV_REP);
> input_set_capability(input_dev, EV_MSC, MSC_SCAN);
>
> - input_dev->keycode = mpr121->keycodes;
> - input_dev->keycodesize = sizeof(mpr121->keycodes[0]);
> - input_dev->keycodemax = mpr121->keycount;
> -
> - for (i = 0; i < pdata->keymap_size; i++) {
> - input_set_capability(input_dev, EV_KEY, pdata->keymap[i]);
> - mpr121->keycodes[i] = pdata->keymap[i];
> - }
> + error = matrix_keypad_build_keymap(keymap_data, NULL, 1, keymap_size,
> + NULL, input_dev);
> + if (error)
> + return error;
>
> error = mpr121_phys_init(pdata, mpr121, client);
> if (error) {
> --
> 2.7.4
>
--
Dmitry
--
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 3/5] Input: mpr121 - handle multiple bits change of status register
From: Dmitry Torokhov @ 2017-01-13 6:09 UTC (permalink / raw)
To: Akinobu Mita; +Cc: linux-input, devicetree
In-Reply-To: <1484156549-26585-4-git-send-email-akinobu.mita@gmail.com>
On Thu, Jan 12, 2017 at 02:42:27AM +0900, Akinobu Mita wrote:
> This driver reports input events on their interrupts which are triggered
> by the sensor's status register changes. But only single bit change is
> reported in the interrupt handler. So if there are multiple bits are
> changed at almost the same time, other press or release events are ignored.
>
> This fixes it by detecting all changed bits in the status register.
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> ---
> drivers/input/keyboard/mpr121_touchkey.c | 26 +++++++++++++++++---------
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/input/keyboard/mpr121_touchkey.c b/drivers/input/keyboard/mpr121_touchkey.c
> index a2c5305..c809f70 100644
> --- a/drivers/input/keyboard/mpr121_touchkey.c
> +++ b/drivers/input/keyboard/mpr121_touchkey.c
> @@ -86,7 +86,8 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
> struct mpr121_touchkey *mpr121 = dev_id;
> struct i2c_client *client = mpr121->client;
> struct input_dev *input = mpr121->input_dev;
> - unsigned int key_num, key_val, pressed;
> + unsigned int bit_changed;
> + unsigned int key_num;
> int reg;
>
> reg = i2c_smbus_read_byte_data(client, ELE_TOUCH_STATUS_1_ADDR);
> @@ -104,18 +105,25 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
>
> reg &= TOUCH_STATUS_MASK;
> /* use old press bit to figure out which bit changed */
> - key_num = ffs(reg ^ mpr121->statusbits) - 1;
> - pressed = reg & (1 << key_num);
> + bit_changed = reg ^ mpr121->statusbits;
> mpr121->statusbits = reg;
> + for (key_num = 0; key_num < mpr121->keycount; key_num++) {
> + unsigned int key_val, pressed;
maybe change bit_changed to long and use for_each_set_bit()?
>
> - key_val = mpr121->keycodes[key_num];
> + if (!(bit_changed & (1 << key_num)))
> + continue;
>
> - input_event(input, EV_MSC, MSC_SCAN, key_num);
> - input_report_key(input, key_val, pressed);
> - input_sync(input);
> + pressed = reg & (1 << key_num);
> + key_val = mpr121->keycodes[key_num];
> +
> + input_event(input, EV_MSC, MSC_SCAN, key_num);
> + input_report_key(input, key_val, pressed);
> +
> + dev_dbg(&client->dev, "key %d %d %s\n", key_num, key_val,
> + pressed ? "pressed" : "released");
>
> - dev_dbg(&client->dev, "key %d %d %s\n", key_num, key_val,
> - pressed ? "pressed" : "released");
> + }
> + input_sync(input);
>
> out:
> return IRQ_HANDLED;
> --
> 2.7.4
>
Thanks.
--
Dmitry
^ permalink raw reply
* RE: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Appana Durga Kedareswara Rao @ 2017-01-13 6:00 UTC (permalink / raw)
To: Vinod Koul
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
Soren Brinkmann,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
luis-HiykPkW1eAzzDCI4PIEvbQC/G2K4zDHf@public.gmane.org,
Jose.Abreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170113053627.GQ3573@localhost>
Hi Vinod,
Thanks for the review...
[Snip]
> >
> > > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > > descriptors back to back on the S2MM(recv) side with the current
> > > > driver flow the last buffer descriptor next bd points to a invalid
> > > > location resulting the invalid data or errors in the DMA engine.
> > >
> > > Can you rephrase this, it a bit hard to understand.
> >
> > When DMA is receiving packets h/w expects the descriptors Should be in
> > the form of a ring (I mean h/w buffer descriptor Next descriptor field
> > should always point to valid address So that when DMA engine go and
> > fetch that next descriptor it always Sees a valid address).
> >
> >
> > But with the current driver implementation when user queues Multiple
> > descriptors the last descriptor next descriptor field Pointing to an
> > invalid location causing data corruption or Errors from the DMA h/w
> > engine...
> >
> > To avoid this issue creating a Buffer descriptor Chain during Channel
> > allocation and using those buffer descriptors for processing User
> > requested data.
>
> Is it not doable to to modify the next pointer to point to subsequent transaction.
> IOW you are modifying tail descriptor to point to subsequent descriptor.
>
> Btw how and when does DMA stop, assuming it is circular it never would, isn't
> there a valid/stop flag associated with a descriptor which tells DMA engine what
> to do next
There are two registers that controls the DMA transfers.
Current descriptor and tail descriptor register.
When current descriptor reaches tail descriptor dma engine will pause.
When reprogramming the tail descriptor the DMA engine will starts fetching descriptors again.
But with the existing driver flow if we reprogram the tail descriptor
The tail descriptor next descriptor field is pointing to an invalid location
Causing data corruption...
>
>
> Btw there is something wrong with your MUA perhaps line are titlecased for no
> reason. This is typically behavious of non linux tool which may not be great tool
> for this work.
Thanks for pointing it out.
I usually replies from outlook from a windows machine.
Will check with others in my team how they configured their mail client.
>
> >
> > Please let me know if the above explanation is not clear will explain in detail....
> >
> > >
> > > >
> > > > This patch fixes this issue by creating a BD Chain during
> > >
> > > whats a BD?
> >
> > Buffer descriptor.
>
> Thats nowhere mentioned..
Yep sorry I should have been mentioned it...
Regards,
Kedar.
--
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
* arm64: dts: mt8173: add node for thermal calibration
From: Dawei Chien @ 2017-01-13 5:52 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Punit Agrawal,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Pawel Moll, Ian Campbell,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Dawei Chien,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sascha Hauer,
Kumar Gala, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
From: "dawei.chien-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org" <dawei.chien-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Add this for supporting thermal calibration by e-fuse data.
Signed-off-by: Dawei Chien <dawei.chien-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..adfac1e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -401,6 +401,11 @@
efuse: efuse@10206000 {
compatible = "mediatek,mt8173-efuse";
reg = <0 0x10206000 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ thermal_calibration: calib@528 {
+ reg = <0x528 0xc>;
+ };
};
apmixedsys: clock-controller@10209000 {
@@ -574,6 +579,8 @@
resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
mediatek,auxadc = <&auxadc>;
mediatek,apmixedsys = <&apmixedsys>;
+ nvmem-cells = <&thermal_calibration>;
+ nvmem-cell-names = "calibration-data";
};
nor_flash: spi@1100d000 {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario
From: Vinod Koul @ 2017-01-13 5:36 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
dan.j.williams@intel.com, michal.simek@xilinx.com,
Soren Brinkmann, moritz.fischer@ettus.com,
laurent.pinchart@ideasonboard.com, luis@debethencourt.com,
Jose.Abreu@synopsys.com, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A6662F1@XAP-PVEXMBX01.xlnx.xilinx.com>
On Thu, Jan 12, 2017 at 02:19:49PM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
>
> > On Sat, Jan 07, 2017 at 12:15:30PM +0530, Kedareswara rao Appana wrote:
> > > When driver is handling AXI DMA SoftIP When user submits multiple
> > > descriptors back to back on the S2MM(recv) side with the current
> > > driver flow the last buffer descriptor next bd points to a invalid
> > > location resulting the invalid data or errors in the DMA engine.
> >
> > Can you rephrase this, it a bit hard to understand.
>
> When DMA is receiving packets h/w expects the descriptors
> Should be in the form of a ring (I mean h/w buffer descriptor
> Next descriptor field should always point to valid address
> So that when DMA engine go and fetch that next descriptor it always
> Sees a valid address).
>
>
> But with the current driver implementation when user queues
> Multiple descriptors the last descriptor next descriptor field
> Pointing to an invalid location causing data corruption or
> Errors from the DMA h/w engine...
>
> To avoid this issue creating a Buffer descriptor Chain during
> Channel allocation and using those buffer descriptors for processing
> User requested data.
Is it not doable to to modify the next pointer to point to subsequent
transaction. IOW you are modifying tail descriptor to point to subsequent
descriptor.
Btw how and when does DMA stop, assuming it is circular it never would,
isn't there a valid/stop flag associated with a descriptor which tells DMA
engine what to do next
Btw there is something wrong with your MUA perhaps line are titlecased for
no reason. This is typically behavious of non linux tool which may not be
great tool for this work.
>
> Please let me know if the above explanation is not clear will explain in detail....
>
> >
> > >
> > > This patch fixes this issue by creating a BD Chain during
> >
> > whats a BD?
>
> Buffer descriptor.
Thats nowhere mentioned..
>
> >
> > > channel allocation itself and use those BD's.
> > >
> > > Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> > > ---
> > >
> > > drivers/dma/xilinx/xilinx_dma.c | 133
> > > +++++++++++++++++++++++++---------------
> > > 1 file changed, 83 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/dma/xilinx/xilinx_dma.c
> > > b/drivers/dma/xilinx/xilinx_dma.c index 0e9c02e..af2159d 100644
> > > --- a/drivers/dma/xilinx/xilinx_dma.c
> > > +++ b/drivers/dma/xilinx/xilinx_dma.c
> > > @@ -163,6 +163,7 @@
> > > #define XILINX_DMA_BD_SOP BIT(27)
> > > #define XILINX_DMA_BD_EOP BIT(26)
> > > #define XILINX_DMA_COALESCE_MAX 255
> > > +#define XILINX_DMA_NUM_DESCS 255
> >
> > why 255?
>
> It is not an h/w limitation
> Allocating 255 descriptors (Each descriptor is capable of sending 7MB data)
> So roughly using allocated descriptors DMA engine can transfer 1GB data
> And in the driver we are reusing the allocated descriptors when they are free.
>
> Regards,
> Kedar.
--
~Vinod
^ permalink raw reply
* RE: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 5:32 UTC (permalink / raw)
To: Vinod Koul
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
Soren Brinkmann,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
luis-HiykPkW1eAzzDCI4PIEvbQC/G2K4zDHf@public.gmane.org,
Jose.Abreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170113052939.GP3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > Hi Vinod,
> >
> > Thanks for the review...
> > >
> > > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > > Add channel idle state to ensure that dma descriptor is not
> > > > submitted when VDMA engine is in progress.
> > >
> > > any reason why you want to make your own varible and not use the HW
> > > to query as done earlier. It is not clear to me why that is removed
> > > from description
> >
> > We need to poll for a bit in the status register to know the dma state.
> > We are currently doing that in the driver hot path To avoid this using
> > own variables.
>
> It would be worthwhile to document these, down the line people may not
> remeber the motivation
Sure will add comments during the variable initialization
In the driver...
Regards,
Kedar.
>
>
> --
> ~Vinod
--
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 v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Vinod Koul @ 2017-01-13 5:29 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: mark.rutland@arm.com, moritz.fischer@ettus.com,
devicetree@vger.kernel.org, michal.simek@xilinx.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, Soren Brinkmann,
luis@debethencourt.com, dmaengine@vger.kernel.org,
dan.j.williams@intel.com, Jose.Abreu@synopsys.com,
linux-arm-kernel@lists.infradead.org,
laurent.pinchart@ideasonboard.com
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A666658@XAP-PVEXMBX01.xlnx.xilinx.com>
On Fri, Jan 13, 2017 at 04:28:11AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review...
> >
> > On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > > Add channel idle state to ensure that dma descriptor is not
> > > submitted when VDMA engine is in progress.
> >
> > any reason why you want to make your own varible and not use the HW to
> > query
> > as done earlier. It is not clear to me why that is removed from description
>
> We need to poll for a bit in the status register to know the dma state.
> We are currently doing that in the driver hot path
> To avoid this using own variables.
It would be worthwhile to document these, down the line people may not
remeber the motivation
--
~Vinod
^ permalink raw reply
* [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree
Cc: tony, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052937.12538-1-matt@ranostay.consulting>
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
drivers/mmc/core/Kconfig | 10 ++++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+)
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index 000000000000..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson <ulf.hansson@linaro.org>
+ *
+ * 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/delay.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+
+#include <linux/mmc/host.h>
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+ { .compatible = "mmc-pwrseq-sd8787",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq;
+ struct device *dev = &pdev->dev;
+
+ pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+ return PTR_ERR(pwrseq->pwrdn_gpio);
+
+ pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->reset_gpio))
+ return PTR_ERR(pwrseq->reset_gpio);
+
+ pwrseq->pwrseq.dev = dev;
+ pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
+ pwrseq->pwrseq.owner = THIS_MODULE;
+ platform_set_drvdata(pdev, pwrseq);
+
+ return mmc_pwrseq_register(&pwrseq->pwrseq);
+}
+
+static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
+
+ mmc_pwrseq_unregister(&pwrseq->pwrseq);
+
+ return 0;
+}
+
+static struct platform_driver mmc_pwrseq_sd8787_driver = {
+ .probe = mmc_pwrseq_sd8787_probe,
+ .remove = mmc_pwrseq_sd8787_remove,
+ .driver = {
+ .name = "pwrseq_sd8787",
+ .of_match_table = mmc_pwrseq_sd8787_of_match,
+ },
+};
+
+module_platform_driver(mmc_pwrseq_sd8787_driver);
+MODULE_LICENSE("GPL v2");
--
2.10.2
^ permalink raw reply related
* [PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, Matt Ranostay
In-Reply-To: <20170113052937.12538-1-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
---
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++++++++++++++
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index 000000000000..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
This node provides properties for controlling the Marvell SDIO/PCIE wireless device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+ for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
^ permalink raw reply related
* [PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Changes from v2:
* fix rookie mistake missing the main source file and docs
Matt Ranostay (2):
devicetree: document new marvell-8xxx and pwrseq-sd8787 options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-8xxx.txt | 7 +-
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
5 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
--
2.10.2
^ permalink raw reply
* [PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Changes from v2:
* fix rookie mistake missing the main source file and docs
Matt Ranostay (2):
devicetree: document new marvell-8xxx and pwrseq-sd8787 options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-8xxx.txt | 7 +-
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
5 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
--
2.10.2
^ 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