* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 14:17 UTC (permalink / raw)
To: Guochun Mao
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Matthias Brugger,
Russell King, linux-mtd, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <1484291609-20195-3-git-send-email-guochun.mao@mediatek.com>
On Fri, 13 Jan 2017 15:13:29 +0800
Guochun Mao <guochun.mao@mediatek.com> wrote:
> Add Mediatek nor flash node.
>
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
> 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";
Why define both here? Is "mediatek,mt8173-nor" really providing a
subset of the features supported by "mediatek,mt2701-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>;
^ permalink raw reply
* Re: [PATCH v2 18/18] insert build break
From: Christopher Bostic @ 2017-01-13 14:22 UTC (permalink / raw)
To: Greg KH
Cc: Rob Herring, Mark Rutland, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
Michael Turquette, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
Open List OF Flattened dev tree bindings,
Moderated list: ARM PORT, Joel Stanley, Jeremy Kerr,
Linux open list, Andrew Jeffery, Alistair Popple,
Benjamin Herrenschmidt, Chris Bostic
In-Reply-To: <20170113071545.GB12441-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Fri, Jan 13, 2017 at 1:15 AM, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> 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?
Yes, had an error when sending out... Will correct this when I send
out version 3 today.
Sorry for the confusion.
-Chris
>
> 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] net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types
From: Murali Karicheri @ 2017-01-13 14:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, f.fainelli, netdev, devicetree,
linux-kernel, nsekhar
Currently dp83867 driver returns error if phy interface type
PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
Fix this by checking also the interface type if a particular delay
value is missing in the phy dt bindings. Also update the DT document
accordingly.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
- I had sent this earlier and some how it didn't get through and
I haven't seen any comment for this. So sending this again.
- Applies to master.
Documentation/devicetree/bindings/net/ti,dp83867.txt | 6 ++++--
drivers/net/phy/dp83867.c | 8 ++++++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 85bf945..afe9630 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -3,9 +3,11 @@
Required properties:
- reg - The ID number for the phy, usually a small integer
- ti,rx-internal-delay - RGMII Receive Clock Delay - see dt-bindings/net/ti-dp83867.h
- for applicable values
+ for applicable values. Required only if interface type is
+ PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_RXID
- ti,tx-internal-delay - RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h
- for applicable values
+ for applicable values. Required only if interface type is
+ PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index e84ae08..ca1b462 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -132,12 +132,16 @@ static int dp83867_of_init(struct phy_device *phydev)
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
- if (ret)
+ if (ret &&
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID))
return ret;
ret = of_property_read_u32(of_node, "ti,tx-internal-delay",
&dp83867->tx_id_delay);
- if (ret)
+ if (ret &&
+ (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID))
return ret;
return of_property_read_u32(of_node, "ti,fifo-depth",
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 00/10] ARM: da850-lcdk: add SATA support
From: Sekhar Nori @ 2017-01-13 14:32 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King, David Lechner
Cc: linux-ide, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
On Friday 13 January 2017 06:07 PM, Bartosz Golaszewski wrote:
> This series contains all the changes necessary to make SATA work on
> the da850-lcdk board.
>
> The first patch adds a clock lookup entry required for the ahci core
> to retrieve a functional clock.
>
> The second enables relevant config options for all davinci boards.
>
> The third adds device tree bindings for the ahci_da850 driver.
>
> The fourth adds a workaround for a SATA controller instability we
> detected after increasing the PLL0 frequency for proper LCD
> controller support.
>
> Patches 5 through 7 extend the ahci_da850 driver - add DT support,
> un-hardcode the clock multiplier value and add a workaround for
> a quirk present on the da850 SATA controller.
>
> Patches 8-10 add the device tree changes required to probe the driver.
>
> I'm posting the series as a whole to give all reviewers the full
> picture and visibility of the changes required, if needed I can resend
> the patches separately.
I just tested this series on my LCDK board using a Western Digital SATA
HDD and it works great with some basic read / write tests. Thanks!
For the non-platform patches which I wont be queuing:
Tested-by: Sekhar Nori <nsekhar@ti.com>
I will take a look at the series closely next week.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH 1/3] arm: dts: mt2701: Sort DT nodes by register address
From: Matthias Brugger @ 2017-01-13 14:38 UTC (permalink / raw)
To: James Liao, Rob Herring, Russell King
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <1482904006-44232-2-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On 28/12/16 06:46, James Liao wrote:
> This patch rearrange MT2701 DT nodes to keep them in ascending order.
>
> Signed-off-by: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 7eab6f4..73f4b7c 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -96,24 +96,6 @@
> <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> - pio: pinctrl@10005000 {
> - compatible = "mediatek,mt2701-pinctrl";
> - reg = <0 0x1000b000 0 0x1000>;
> - mediatek,pctl-regmap = <&syscfg_pctl_a>;
> - pins-are-numbered;
> - gpio-controller;
> - #gpio-cells = <2>;
> - interrupt-controller;
> - #interrupt-cells = <2>;
> - interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> - };
Applied the whole series. I fixed the unit address of pio to 1000b000
and it's order in the file.
Please check v4.10-next/dts32
Thanks,
Mathias
> -
> - syscfg_pctl_a: syscfg@10005000 {
> - compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
> - reg = <0 0x10005000 0 0x1000>;
> - };
> -
> topckgen: syscon@10000000 {
> compatible = "mediatek,mt2701-topckgen", "syscon";
> reg = <0 0x10000000 0 0x1000>;
> @@ -134,6 +116,24 @@
> #reset-cells = <1>;
> };
>
> + pio: pinctrl@10005000 {
> + compatible = "mediatek,mt2701-pinctrl";
> + reg = <0 0x1000b000 0 0x1000>;
> + mediatek,pctl-regmap = <&syscfg_pctl_a>;
> + pins-are-numbered;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + syscfg_pctl_a: syscfg@10005000 {
> + compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
> + reg = <0 0x10005000 0 0x1000>;
> + };
> +
> watchdog: watchdog@10007000 {
> compatible = "mediatek,mt2701-wdt",
> "mediatek,mt6589-wdt";
>
--
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 RFC v2 0/4] SolidRun Hummingboard 2 support
From: Russell King - ARM Linux @ 2017-01-13 14:44 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo, Jon Nettleton
Cc: Mark Rutland, devicetree, Rob Herring, linux-arm-kernel
These patches add support for SolidRun's Hummingboard 2 to mainline.
The first is the official SolidRun DTS file supplied by Jon, the
remainder are cleanups to it for mainline.
These can be found in my HB2 branch.
Version 2 updated by Jon from comments received on previous posting.
The series can be found at:
git://git.armlinux.org.uk/~rmk/linux-arm.git hb2
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-hummingboard2.dts | 52 +++
arch/arm/boot/dts/imx6q-hummingboard2.dts | 60 +++
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 555 +++++++++++++++++++++++++++
4 files changed, 669 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard2.dts
create mode 100644 arch/arm/boot/dts/imx6q-hummingboard2.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Chris Brandt @ 2017-01-13 14:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdUz6nb-STMQK39hDqwHRt4R5t+Lndj150Lkg7prN=HQZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2483 bytes --]
Hi Geert,
On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> This is strange. There are two SDHI channels, but the STBCR12
> documentation (all versions up to rev. 3.00) says the register has MSTP
> bits for four SD host interfaces?
>
> Can you please enlighten me? Thanks!
If you look in the rev 3.00 manual for RZ/A1H, in section
"50.3.2 Card Detect/Write Protect", it says:
* Power-Down mode at Card removal
SD Host Interface module is halted by the MSTP123 bit to MSTP120 bit in Standby Control Register 12
(STBCR12). If these bits of each channel in STBCR12 are set to 10, low power consumption is achieved at Card
removal. See section 55, Power-Down Modes
So, there are 2 clock sources for each SDHI channel, and the setting
Options are:
SD Host Interface 0 Module Stop
00: SD Host Interface 0 Module runs.
01: Setting prohibited.
10: Only card detect block in SD Host Interface 0 Module runs.
11: Clock supply to SD Host Interface 0 Module is halted
Previously I've been running with '00' because I was turning EVERYTHING on
in u-boot.
Yesterday, I tested with just '10' and things seem to work OK
for me.
Since the sh_mobile_sdhi/tmio driver only allows for 1 clock per channel,
'10' is my only choice for the DT.
However, looking at a previous BSP for RZ/A1, the driver
arch/arm/mach-shmobile/clock-r7s72100.c had this:
static struct clk mstp_clks[MSTP_NR] = {
[MSTP123] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 3, 0), /* SDHI00 */
[MSTP122] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 2,
CLK_ENABLE_ON_INIT), /* SDHI01 */
[MSTP121] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 1, 0), /* SDHI10 */
[MSTP120] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 0,
CLK_ENABLE_ON_INIT), /* SDHI11 */
But...that would make me think on boot it would be set to '01' (setting prohibited).
I'm going to try and find if "setting prohibited" really just means:
"you can set it this way...but nothing is really going to work unless you
enable the other clock".
If that is the case, is there a DT equivalent to "CLK_ENABLE_ON_INIT" that
I can do for MSTP120(SDHI11) and MSTP120(SDHI01) so they are both cleared
on boot???
Thanks,
Chris
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* [PATCH RFC v2 1/4] ARM: dts: imx6qdl: add HummingBoard2 boards
From: Russell King @ 2017-01-13 14:45 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo, Jon Nettleton
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland
In-Reply-To: <20170113144449.GQ14217-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
From: Jon Nettleton <jon-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
This adds support for the Hummingboard Gate and Edge devices from
SolidRun.
Signed-off-by: Jon Nettleton <jon-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
Signed-off-by: Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-hummingboard2.dts | 52 +++
arch/arm/boot/dts/imx6q-hummingboard2.dts | 60 +++
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 543 +++++++++++++++++++++++++++
4 files changed, 657 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard2.dts
create mode 100644 arch/arm/boot/dts/imx6q-hummingboard2.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250f0bb6..09227cc15199 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw552x.dtb \
imx6dl-gw553x.dtb \
imx6dl-hummingboard.dtb \
+ imx6dl-hummingboard2.dtb \
imx6dl-icore.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
@@ -390,6 +391,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-gw553x.dtb \
imx6q-h100.dtb \
imx6q-hummingboard.dtb \
+ imx6q-hummingboard2.dtb \
imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-hummingboard2.dts b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
new file mode 100644
index 000000000000..990b5050de5b
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-hummingboard2.dts
@@ -0,0 +1,52 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ * Based on work by Russell King
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Solo/DualLite";
+ compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-hummingboard2.dts b/arch/arm/boot/dts/imx6q-hummingboard2.dts
new file mode 100644
index 000000000000..f5eec9163bb8
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-hummingboard2.dts
@@ -0,0 +1,60 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ * Based on work by Russell King
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-hummingboard2.dtsi"
+
+/ {
+ model = "SolidRun HummingBoard2 Dual/Quad";
+ compatible = "solidrun,hummingboard2/q", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+ fsl,transmit-level-mV = <1104>;
+ fsl,transmit-boost-mdB = <0>;
+ fsl,transmit-atten-16ths = <9>;
+ fsl,no-spread-spectrum;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
new file mode 100644
index 000000000000..11b63f6f2b89
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -0,0 +1,543 @@
+/*
+ * Device Tree file for SolidRun HummingBoard2
+ * Copyright (C) 2015 Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include "imx6qdl-microsom.dtsi"
+#include "imx6qdl-microsom-ar8035.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ ir_recv: ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio7 9 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_gpio7_9>;
+ linux,rc-map-name = "rc-rc6-mce";
+ };
+
+ usdhc2_pwrseq: usdhc2-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_usbh1_vbus: regulator-usb-h1-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 0 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbotg_vbus: regulator-usb-otg-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 22 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbh2_vbus: regulator-usb-h2-vbus {
+ compatible = "regulator-gpio";
+ enable-active-high;
+ enable-gpio = <&gpio2 13 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbh2_vbus>;
+ regulator-name = "usb_h2_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ };
+
+ reg_usbh3_vbus: regulator-usb-h3-vbus {
+ compatible = "regulator-gpio";
+ enable-active-high;
+ enable-gpio = <&gpio7 10 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbh3_vbus>;
+ regulator-name = "usb_h3_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ };
+
+ sound-sgtl5000 {
+ audio-codec = <&sgtl5000>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HP_OUT";
+ compatible = "fsl,imx-audio-sgtl5000";
+ model = "On-board Codec";
+ mux-ext-port = <5>;
+ mux-int-port = <1>;
+ ssi-controller = <&ssi1>;
+ };
+};
+
+&audmux {
+ status = "okay";
+};
+
+&ecspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_ecspi2>;
+ cs-gpios = <&gpio2 26 0>;
+ status = "okay";
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_hdmi>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_i2c1>;
+ status = "okay";
+
+ pcf8523: rtc@68 {
+ compatible = "nxp,pcf8523";
+ reg = <0x68>;
+ nxp,12p5_pf;
+ };
+
+ sgtl5000: codec@0a {
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ compatible = "fsl,sgtl5000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_sgtl5000>;
+ reg = <0x0a>;
+ VDDA-supply = <®_3p3v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_i2c3>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ hummingboard2 {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /*
+ * 36 pin headers GPIO description. The pins
+ * numbering as following -
+ *
+ * 3.2v 5v 74 75
+ * 73 72 71 70
+ * 69 68 67 66
+ *
+ * 77 78 79 76
+ * 65 64 61 60
+ * 53 52 51 50
+ * 49 48 166 132
+ * 95 94 90 91
+ * GND 54 24 204
+ *
+ * The GPIO numbers can be extracted using
+ * signal name from below.
+ * Example -
+ * MX6QDL_PAD_EIM_DA10__GPIO3_IO10 is
+ * GPIO(3,10) which is (3-1)*32+10 = gpio 74
+ *
+ * i.e. The mapping of GPIO(X,Y) to Linux gpio
+ * number is : gpio number = (X-1) * 32 + Y
+ */
+ /* DI1_PIN15 */
+ MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x400130b1
+ /* DI1_PIN02 */
+ MX6QDL_PAD_EIM_DA11__GPIO3_IO11 0x400130b1
+ /* DISP1_DATA00 */
+ MX6QDL_PAD_EIM_DA9__GPIO3_IO09 0x400130b1
+ /* DISP1_DATA01 */
+ MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x400130b1
+ /* DISP1_DATA02 */
+ MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x400130b1
+ /* DISP1_DATA03 */
+ MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x400130b1
+ /* DISP1_DATA04 */
+ MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x400130b1
+ /* DISP1_DATA05 */
+ MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0x400130b1
+ /* DISP1_DATA06 */
+ MX6QDL_PAD_EIM_DA3__GPIO3_IO03 0x400130b1
+ /* DISP1_DATA07 */
+ MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x400130b1
+ /* DI1_D0_CS */
+ MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x400130b1
+ /* DI1_D1_CS */
+ MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x400130b1
+ /* DI1_PIN01 */
+ MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x400130b1
+ /* DI1_PIN03 */
+ MX6QDL_PAD_EIM_DA12__GPIO3_IO12 0x400130b1
+ /* DISP1_DATA08 */
+ MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x400130b1
+ /* DISP1_DATA09 */
+ MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0x400130b1
+ /* DISP1_DATA10 */
+ MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x400130b1
+ /* DISP1_DATA11 */
+ MX6QDL_PAD_EIM_EB0__GPIO2_IO28 0x400130b1
+ /* DISP1_DATA12 */
+ MX6QDL_PAD_EIM_A17__GPIO2_IO21 0x400130b1
+ /* DISP1_DATA13 */
+ MX6QDL_PAD_EIM_A18__GPIO2_IO20 0x400130b1
+ /* DISP1_DATA14 */
+ MX6QDL_PAD_EIM_A19__GPIO2_IO19 0x400130b1
+ /* DISP1_DATA15 */
+ MX6QDL_PAD_EIM_A20__GPIO2_IO18 0x400130b1
+ /* DISP1_DATA16 */
+ MX6QDL_PAD_EIM_A21__GPIO2_IO17 0x400130b1
+ /* DISP1_DATA17 */
+ MX6QDL_PAD_EIM_A22__GPIO2_IO16 0x400130b1
+ /* DISP1_DATA18 */
+ MX6QDL_PAD_EIM_A23__GPIO6_IO06 0x400130b1
+ /* DISP1_DATA19 */
+ MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x400130b1
+ /* DISP1_DATA20 */
+ MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x400130b1
+ /* DISP1_DATA21 */
+ MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x400130b1
+ /* DISP1_DATA22 */
+ MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x400130b1
+ /* DISP1_DATA23 */
+ MX6QDL_PAD_EIM_D27__GPIO3_IO27 0x400130b1
+ /* DI1_DISP_CLK */
+ MX6QDL_PAD_EIM_A16__GPIO2_IO22 0x400130b1
+ /* SPDIF_IN */
+ MX6QDL_PAD_ENET_RX_ER__GPIO1_IO24 0x400130b1
+ /* SPDIF_OUT */
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x400130b1
+
+ /* MikroBUS GPIO pin number 10 */
+ MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x400130b1
+ >;
+ };
+
+ pinctrl_hummingboard2_ecspi2: hummingboard2-ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1 /* CS */
+ >;
+ };
+
+ pinctrl_hummingboard2_gpio7_9: hummingboard2-gpio7_9 {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CMD__GPIO7_IO09 0x80000000
+ >;
+ };
+
+ pinctrl_hummingboard2_hdmi: hummingboard2-hdmi {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_hummingboard2_i2c1: hummingboard2-i2c1 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_hummingboard2_i2c2: hummingboard2-i2c2 {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_hummingboard2_i2c3: hummingboard2-i2c3 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_hummingboard2_mipi: hummingboard2_mipi {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x4001b8b1
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x4001b8b1
+ MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
+ >;
+ };
+
+ pinctrl_hummingboard2_pcie_reset: hummingboard2-pcie-reset {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT3__GPIO2_IO11 0x1b0b1
+ >;
+ };
+
+ pinctrl_hummingboard2_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_hummingboard2_sgtl5000: hummingboard2-sgtl5000 {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
+ MX6QDL_PAD_KEY_COL0__AUD5_TXC 0x130b0
+ MX6QDL_PAD_KEY_ROW0__AUD5_TXD 0x110b0
+ MX6QDL_PAD_KEY_COL1__AUD5_TXFS 0x130b0
+ MX6QDL_PAD_GPIO_5__CCM_CLKO1 0x130b0
+ >;
+ };
+
+ pinctrl_hummingboard2_usbh1_vbus: hummingboard2-usbh1-vbus {
+ fsl,pins = <MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usbh2_vbus: hummingboard2-usbh2-vbus {
+ fsl,pins = <MX6QDL_PAD_SD4_DAT5__GPIO2_IO13 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usbh3_vbus: hummingboard2-usbh3-vbus {
+ fsl,pins = <MX6QDL_PAD_SD4_CLK__GPIO7_IO10 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usbotg_id: hummingboard2-usbotg-id {
+ /*
+ * Similar to pinctrl_usbotg_2, but we want it
+ * pulled down for a fixed host connection.
+ */
+ fsl,pins = <MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059>;
+ };
+
+ pinctrl_hummingboard2_usbotg_vbus: hummingboard2-usbotg-vbus {
+ fsl,pins = <MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0>;
+ };
+
+ pinctrl_hummingboard2_usdhc2_aux: hummingboard2-usdhc2-aux {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x13071
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b071
+ MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x1b0b0
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc2: hummingboard2-usdhc2 {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc2_100mhz: hummingboard2-usdhc2-100mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130b9
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc2_200mhz: hummingboard2-usdhc2-200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170f9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100f9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x130f9
+ >;
+ };
+
+ pinctrl_hummingboard2_usdhc3: hummingboard2-usdhc3 {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
+ >;
+ };
+
+ pinctrl_hummingboard2_uart3: hummingboard2-uart3 {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D25__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D24__UART3_RX_DATA 0x40013000
+ >;
+ };
+ };
+};
+
+&ldb {
+ status = "disabled";
+
+ lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <18>;
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_pcie_reset>;
+ reset-gpio = <&gpio2 11 0>;
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_pwm1>;
+ status = "okay";
+};
+
+&pwm3 {
+ status = "disabled";
+};
+
+&pwm4 {
+ status = "disabled";
+};
+
+&ssi1 {
+ status = "okay";
+};
+
+&usbh1 {
+ disable-over-current;
+ vbus-supply = <®_usbh1_vbus>;
+ status = "okay";
+};
+
+&usbotg {
+ disable-over-current;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_usbotg_id>;
+ vbus-supply = <®_usbotg_vbus>;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <
+ &pinctrl_hummingboard2_usdhc2_aux
+ &pinctrl_hummingboard2_usdhc2
+ >;
+ pinctrl-1 = <
+ &pinctrl_hummingboard2_usdhc2_aux
+ &pinctrl_hummingboard2_usdhc2_100mhz
+ >;
+ pinctrl-2 = <
+ &pinctrl_hummingboard2_usdhc2_aux
+ &pinctrl_hummingboard2_usdhc2_200mhz
+ >;
+ mmc-pwrseq = <&usdhc2_pwrseq>;
+ cd-gpios = <&gpio1 4 0>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &pinctrl_hummingboard2_usdhc3
+ >;
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_3p3v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_uart3>;
+ status = "okay";
+};
--
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 RFC v2 2/4] ARM: dts: imx6*-hummingboard2: fix SD card detect
From: Russell King @ 2017-01-13 14:45 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo, Jon Nettleton
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland
In-Reply-To: <20170113144449.GQ14217-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Fix the SD card detect signal, which was missing the polarity
specification, and the pull-up necessary for proper signalling.
Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 11b63f6f2b89..734487edf200 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -393,7 +393,7 @@
pinctrl_hummingboard2_usdhc2_aux: hummingboard2-usdhc2-aux {
fsl,pins = <
- MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x13071
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1f071
MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b071
MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x1b0b0
>;
@@ -520,7 +520,7 @@
&pinctrl_hummingboard2_usdhc2_200mhz
>;
mmc-pwrseq = <&usdhc2_pwrseq>;
- cd-gpios = <&gpio1 4 0>;
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
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 RFC v2 3/4] ARM: dts: imx6*-hummingboard2: use proper gpio flags definitions
From: Russell King @ 2017-01-13 14:45 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo, Jon Nettleton
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland
In-Reply-To: <20170113144449.GQ14217-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Use proper gpio flag definitions for GPIOs rather than using opaque
uninformative numbers.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 734487edf200..88aaed26dd77 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -50,7 +50,7 @@
ir_recv: ir-receiver {
compatible = "gpio-ir-receiver";
- gpios = <&gpio7 9 1>;
+ gpios = <&gpio7 9 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_gpio7_9>;
linux,rc-map-name = "rc-rc6-mce";
@@ -80,7 +80,7 @@
reg_usbh1_vbus: regulator-usb-h1-vbus {
compatible = "regulator-fixed";
enable-active-high;
- gpio = <&gpio1 0 0>;
+ gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh1_vbus>;
regulator-name = "usb_h1_vbus";
@@ -91,7 +91,7 @@
reg_usbotg_vbus: regulator-usb-otg-vbus {
compatible = "regulator-fixed";
enable-active-high;
- gpio = <&gpio3 22 0>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbotg_vbus>;
regulator-name = "usb_otg_vbus";
@@ -102,7 +102,7 @@
reg_usbh2_vbus: regulator-usb-h2-vbus {
compatible = "regulator-gpio";
enable-active-high;
- enable-gpio = <&gpio2 13 0>;
+ enable-gpio = <&gpio2 13 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh2_vbus>;
regulator-name = "usb_h2_vbus";
@@ -114,7 +114,7 @@
reg_usbh3_vbus: regulator-usb-h3-vbus {
compatible = "regulator-gpio";
enable-active-high;
- enable-gpio = <&gpio7 10 0>;
+ enable-gpio = <&gpio7 10 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_usbh3_vbus>;
regulator-name = "usb_h3_vbus";
--
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 RFC v2 4/4] ARM: dts: imx6*-hummingboard2: convert to more conventional vmmc-supply
From: Russell King @ 2017-01-13 14:45 UTC (permalink / raw)
To: Fabio Estevam, Sascha Hauer, Shawn Guo, Jon Nettleton
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland
In-Reply-To: <20170113144449.GQ14217-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 88aaed26dd77..f19d30b34ac4 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -56,11 +56,6 @@
linux,rc-map-name = "rc-rc6-mce";
};
- usdhc2_pwrseq: usdhc2-pwrseq {
- compatible = "mmc-pwrseq-simple";
- reset-gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
- };
-
reg_3p3v: regulator-3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
@@ -123,6 +118,18 @@
regulator-boot-on;
};
+ reg_usdhc2_vmmc: reg-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ gpio = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard2_vmmc>;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "usdhc2_vmmc";
+ startup-delay-us = <1000>;
+ };
+
sound-sgtl5000 {
audio-codec = <&sgtl5000>;
audio-routing =
@@ -393,7 +400,6 @@
pinctrl_hummingboard2_usdhc2_aux: hummingboard2-usdhc2-aux {
fsl,pins = <
- MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1f071
MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b071
MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x1b0b0
>;
@@ -432,6 +438,12 @@
>;
};
+ pinctrl_hummingboard2_vmmc: hummingboard2-vmmc {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1f071
+ >;
+ };
+
pinctrl_hummingboard2_usdhc3: hummingboard2-usdhc3 {
fsl,pins = <
MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
@@ -519,7 +531,7 @@
&pinctrl_hummingboard2_usdhc2_aux
&pinctrl_hummingboard2_usdhc2_200mhz
>;
- mmc-pwrseq = <&usdhc2_pwrseq>;
+ vmmc-supply = <®_usdhc2_vmmc>;
cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
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
* RE: [PATCH 3/3] ARM: dts: rskrza1: add ostm DT support
From: Chris Brandt @ 2017-01-13 14:50 UTC (permalink / raw)
To: Geert Uytterhoeven, Sergei Shtylyov
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Thomas Gleixner, Geert Uytterhoeven,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <CAMuHMdWNd=TqqWAv3NhEF5R8JRQ362EJ3LirHpqBLgQK3w30oA@mail.gmail.com>
Hi Geert and Sergei,
On Friday, January 13, 2017, Geert Uytterhoeven wrote:
> On Thu, Jan 12, 2017 at 8:01 PM, Chris Brandt <chris.brandt@renesas.com>
> wrote:
> > --- a/arch/arm/boot/dts/r7s72100.dtsi
> > +++ b/arch/arm/boot/dts/r7s72100.dtsi
> > @@ -513,7 +513,8 @@
> > interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING
> > GIC_SPI 103 IRQ_TYPE_EDGE_RISING>;
> >
> > - clocks = <&mstp5_clks R7S72100_CLK_OSTM0>, <&mstp5_clks
> R7S72100_CLK_OSTM1>;
> > + clocks = <&mstp5_clks R7S72100_CLK_OSTM0>,
> > + <&mstp5_clks R7S72100_CLK_OSTM1>;
>
> I think this change should be folded into "[PATCH 2/3] ARM: dts: r7s72100:
> add ostm to device tree" ;-)
Oops, I think I got things a little screwed up when git rebasing and
reordering and such.
Thanks for the review!
Chris
^ permalink raw reply
* Re: [PATCH v4 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
From: Matthias Brugger @ 2017-01-13 14:54 UTC (permalink / raw)
To: Honghui Zhang
Cc: joro-zLv9SwRftAIdnm+yROfE0A, treding-DDmLM1+adcrQT0dZR+AlfA,
mark.rutland-5wv7dgnIgG8, robh-DgEjT+Ai2ygdnm+yROfE0A,
robin.murphy-5wv7dgnIgG8, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, pebolle-IWqWACnzNjzz+pZb47iToQ,
kendrick.hsu-NuS5LvNUpcJWk0Htik3J/w, arnd-r2nGTMty4D4,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, tfiga-hpIqsD4AKlfQT0dZR+AlfA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, djkurtz-hpIqsD4AKlfQT0dZR+AlfA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
eddie.huang-NuS5LvNUpcJWk0Htik3J/w,
youlin.pei-NuS5LvNUpcJWk0Htik3J/w, erin.lo-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <577A1794.5040509-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/07/16 10:00, Matthias Brugger wrote:
>
>
> On 04/07/16 03:32, Honghui Zhang wrote:
>> On Sun, 2016-07-03 at 21:12 +0200, Matthias Brugger wrote:
>>>
>>> On 07/03/2016 08:24 AM, Matthias Brugger wrote:
>>>>
>>>>
>>>> On 06/08/2016 11:51 AM, honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
>>>>> From: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>
>>>>> Add the dtsi node of iommu and smi for mt2701.
>>>>>
>>>>> Signed-off-by: Honghui Zhang <honghui.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>> arch/arm/boot/dts/mt2701.dtsi | 51
>>>>> +++++++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 51 insertions(+)
>>>>>
>>>>
>>>> Applied,
>>>
>>> Please resend the patch including the infracfg and mmsys node.
>>>
>>
>> Hi, Matthias,
>>
>> Please hold this one.
>> This one is based on CCF "arm: dts: mt2701: Add clock controller device
>> nodes"[1] and power domain patch "Mediatek MT2701 SCPSYS power domain
>> support v7"[2],
>> But these two patchset are still being reviewed now.
>>
>> Do you think it's better that I send this one later after ccf and power
>> domain patch got merged? I will send this patch later if it's OK with
>> you.
>>
>
> Sounds good.
Applied now to v4.10-next/dts32
Thanks.
>
> Thanks a lot,
> Matthias
>
>> Thanks.
>> [1] https://patchwork.kernel.org/patch/9109081
>> [2]
>> http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005429.html
>>
>>> Regards,
>>> Matthias
>>>
>>>>
>>>> Thanks.
>>>>
>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>> index 42d5a37..363de0d 100644
>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>> @@ -16,6 +16,7 @@
>>>>> #include <dt-bindings/power/mt2701-power.h>
>>>>> #include <dt-bindings/interrupt-controller/irq.h>
>>>>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +#include <dt-bindings/memory/mt2701-larb-port.h>
>>>>> #include "skeleton64.dtsi"
>>>>> #include "mt2701-pinfunc.h"
>>>>>
>>>>> @@ -160,6 +161,16 @@
>>>>> clock-names = "system-clk", "rtc-clk";
>>>>> };
>>>>>
>>>>> + smi_common: smi@1000c000 {
>>>>> + compatible = "mediatek,mt2701-smi-common";
>>>>> + reg = <0 0x1000c000 0 0x1000>;
>>>>> + clocks = <&infracfg CLK_INFRA_SMI>,
>>>>> + <&mmsys CLK_MM_SMI_COMMON>,
>>>>> + <&infracfg CLK_INFRA_SMI>;
>>>>> + clock-names = "apb", "smi", "async";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
>>>>> + };
>>>>> +
>>>>> sysirq: interrupt-controller@10200100 {
>>>>> compatible = "mediatek,mt2701-sysirq",
>>>>> "mediatek,mt6577-sysirq";
>>>>> @@ -169,6 +180,16 @@
>>>>> reg = <0 0x10200100 0 0x1c>;
>>>>> };
>>>>>
>>>>> + iommu: mmsys_iommu@10205000 {
>>>>> + compatible = "mediatek,mt2701-m4u";
>>>>> + reg = <0 0x10205000 0 0x1000>;
>>>>> + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>;
>>>>> + clocks = <&infracfg CLK_INFRA_M4U>;
>>>>> + clock-names = "bclk";
>>>>> + mediatek,larbs = <&larb0 &larb1 &larb2>;
>>>>> + #iommu-cells = <1>;
>>>>> + };
>>>>> +
>>>>> apmixedsys: syscon@10209000 {
>>>>> compatible = "mediatek,mt2701-apmixedsys", "syscon";
>>>>> reg = <0 0x10209000 0 0x1000>;
>>>>> @@ -234,6 +255,16 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + larb0: larb@14010000 {
>>>>> + compatible = "mediatek,mt2701-smi-larb";
>>>>> + reg = <0 0x14010000 0 0x1000>;
>>>>> + mediatek,smi = <&smi_common>;
>>>>> + clocks = <&mmsys CLK_MM_SMI_LARB0>,
>>>>> + <&mmsys CLK_MM_SMI_LARB0>;
>>>>> + clock-names = "apb", "smi";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
>>>>> + };
>>>>> +
>>>>> imgsys: syscon@15000000 {
>>>>> compatible = "mediatek,mt2701-imgsys", "syscon";
>>>>> reg = <0 0x15000000 0 0x1000>;
>>>>> @@ -241,6 +272,16 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + larb2: larb@15001000 {
>>>>> + compatible = "mediatek,mt2701-smi-larb";
>>>>> + reg = <0 0x15001000 0 0x1000>;
>>>>> + mediatek,smi = <&smi_common>;
>>>>> + clocks = <&imgsys CLK_IMG_SMI_COMM>,
>>>>> + <&imgsys CLK_IMG_SMI_COMM>;
>>>>> + clock-names = "apb", "smi";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
>>>>> + };
>>>>> +
>>>>> vdecsys: syscon@16000000 {
>>>>> compatible = "mediatek,mt2701-vdecsys", "syscon";
>>>>> reg = <0 0x16000000 0 0x1000>;
>>>>> @@ -248,6 +289,16 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + larb1: larb@16010000 {
>>>>> + compatible = "mediatek,mt2701-smi-larb";
>>>>> + reg = <0 0x16010000 0 0x1000>;
>>>>> + mediatek,smi = <&smi_common>;
>>>>> + clocks = <&vdecsys CLK_VDEC_CKGEN>,
>>>>> + <&vdecsys CLK_VDEC_LARB>;
>>>>> + clock-names = "apb", "smi";
>>>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
>>>>> + };
>>>>> +
>>>>> hifsys: syscon@1a000000 {
>>>>> compatible = "mediatek,mt2701-hifsys", "syscon";
>>>>> reg = <0 0x1a000000 0 0x1000>;
>>>>>
>>
>>
--
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 v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-13 15:02 UTC (permalink / raw)
To: Eddie Huang
Cc: Hans Verkuil, Rick Chang, devicetree, Laurent Pinchart,
Minghsiu Tsai, srv_heupstream, James Liao, linux-kernel,
Rob Herring, Hans Verkuil, linux-mediatek, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media
In-Reply-To: <1484011718.10361.7.camel@mtksdaap41>
Hi James,
On 10/01/17 02:28, Eddie Huang wrote:
> Hi Matthias,
>
> On Mon, 2017-01-09 at 19:45 +0100, Matthias Brugger wrote:
>>
>> On 09/01/17 12:29, Hans Verkuil wrote:
>>> Hi Rick,
>>>
>>> On 01/06/2017 03:34 AM, Rick Chang wrote:
>>>> Hi Hans,
>>>>
>>>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
>>>> any idea about this patch series? Should we wait for [2] or we could merge
>>>> the source code and dt-binding first?
>>>
>>> Looking at [2] I noticed that the last comment was July 4th. What is the reason
>>> it hasn't been merged yet?
>>>
>>> If I know [2] will be merged for 4.11, then I am fine with merging this media
>>> patch series. The dependency of this patch on [2] is something Mauro can handle.
>>>
>>> If [2] is not merged for 4.11, then I think it is better to wait until it is
>>> merged.
>>>
>>
>> I can't take [2] because there is no scpsys in the dts present. It seems
>> that it got never posted.
>>
>> Rick can you please follow-up with James and provide a patch which adds
>> a scpsys node to the mt2701.dtsi?
>>
>
> James sent three MT2701 dts patches [1] two weeks ago, these three
> patches include scpsys node. Please take a reference. And We will send
> new MT2701 ionmmu/smi dtsi node patch base on [1] later, thus you can
> accept and merge to 4.11.
>
Thanks for the clarification. I pulled all this patches into
v4.10-next/dts32
Hans will you take v9 of this patch set?
Then I'll take the dts patch.
Regards,
Matthias
> [1]
> https://patchwork.kernel.org/patch/9489991/
> https://patchwork.kernel.org/patch/9489985/
> https://patchwork.kernel.org/patch/9489989/
>
> Thanks,
> Eddie
>
>
^ permalink raw reply
* Re: [PATCH v2 2/6] arm: dts: mt2701: Add iommu/smi device node
From: Matthias Brugger @ 2017-01-13 15:05 UTC (permalink / raw)
To: Erin Lo
Cc: srv_heupstream, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, Honghui Zhang
In-Reply-To: <1484296978-18572-3-git-send-email-erin.lo@mediatek.com>
Hi Erin,
I just took the patch from Honghui he send in june.
Please see my comment inline.
On 13/01/17 09:42, Erin Lo wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> Add the device node of iommu and smi for MT2701.
>
> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index eb4c6fd..87be52c 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -17,6 +17,7 @@
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/reset/mt2701-resets.h>
> +#include <dt-bindings/memory/mt2701-larb-port.h>
> #include "skeleton64.dtsi"
> #include "mt2701-pinfunc.h"
>
> @@ -161,6 +162,16 @@
> clock-names = "system-clk", "rtc-clk";
> };
>
> + smi_common: smi@1000c000 {
> + compatible = "mediatek,mt2701-smi-common";
> + reg = <0 0x1000c000 0 0x1000>;
> + clocks = <&infracfg CLK_INFRA_SMI>,
> + <&mmsys CLK_MM_SMI_COMMON>,
> + <&infracfg CLK_INFRA_SMI>;
> + clock-names = "apb", "smi", "async";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> + };
> +
> sysirq: interrupt-controller@10200100 {
> compatible = "mediatek,mt2701-sysirq",
> "mediatek,mt6577-sysirq";
> @@ -170,6 +181,16 @@
> reg = <0 0x10200100 0 0x1c>;
> };
>
> + iommu: mmsys_iommu@10205000 {
> + compatible = "mediatek,mt2701-m4u";
> + reg = <0 0x10205000 0 0x1000>;
> + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_M4U>;
> + clock-names = "bclk";
> + mediatek,larbs = <&larb0 &larb1 &larb2>;
> + #iommu-cells = <1>;
> + };
> +
> apmixedsys: syscon@10209000 {
> compatible = "mediatek,mt2701-apmixedsys", "syscon";
> reg = <0 0x10209000 0 0x1000>;
> @@ -272,18 +293,51 @@
> #clock-cells = <1>;
> };
>
> + larb0: larb@14010000 {
> + compatible = "mediatek,mt2701-smi-larb";
> + reg = <0 0x14010000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + mediatek,larbidx = <0>;
Did I miss something? 'mediatek,larbidx' does not sound familiar to me.
Regards,
Matthias
> + clocks = <&mmsys CLK_MM_SMI_LARB0>,
> + <&mmsys CLK_MM_SMI_LARB0>;
> + clock-names = "apb", "smi";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
> + };
> +
> imgsys: syscon@15000000 {
> compatible = "mediatek,mt2701-imgsys", "syscon";
> reg = <0 0x15000000 0 0x1000>;
> #clock-cells = <1>;
> };
>
> + larb2: larb@15001000 {
> + compatible = "mediatek,mt2701-smi-larb";
> + reg = <0 0x15001000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + mediatek,larbidx = <2>;
> + clocks = <&imgsys CLK_IMG_SMI_COMM>,
> + <&imgsys CLK_IMG_SMI_COMM>;
> + clock-names = "apb", "smi";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> + };
> +
> vdecsys: syscon@16000000 {
> compatible = "mediatek,mt2701-vdecsys", "syscon";
> reg = <0 0x16000000 0 0x1000>;
> #clock-cells = <1>;
> };
>
> + larb1: larb@16010000 {
> + compatible = "mediatek,mt2701-smi-larb";
> + reg = <0 0x16010000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + mediatek,larbidx = <1>;
> + clocks = <&vdecsys CLK_VDEC_CKGEN>,
> + <&vdecsys CLK_VDEC_LARB>;
> + clock-names = "apb", "smi";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
> + };
> +
> hifsys: syscon@1a000000 {
> compatible = "mediatek,mt2701-hifsys", "syscon";
> reg = <0 0x1a000000 0 0x1000>;
>
^ permalink raw reply
* [PATCH v3 0/2] mmc: host: s3cmci: add device tree support
From: Sergio Prado @ 2017-01-13 15:05 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ben-linux-elnMNo+KYs3YtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sergio Prado
This series adds support for configuring Samsung's S3C24XX MMC/SD/SDIO
controller via device tree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Changes since v2:
- struct "s3cmci_drv_data" and flag "is2440" renamed
- copying the whole driver data struct instead of only its member so
it will be easier to extend the information in the future
- using mmc_of_parse() to read "cd-gpios" and "wp-gpios" properties
from device tree
Changes since v1:
- pinctrl description removed from DT binding
- unit and label on DT binding renamed to mmc
Sergio Prado (2):
dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
mmc: host: s3cmci: allow probing from device tree
.../devicetree/bindings/mmc/samsung,s3cmci.txt | 34 +++
drivers/mmc/host/s3cmci.c | 298 +++++++++++----------
drivers/mmc/host/s3cmci.h | 3 +-
3 files changed, 192 insertions(+), 143 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
--
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
* [PATCH v3 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
From: Sergio Prado @ 2017-01-13 15:05 UTC (permalink / raw)
To: ulf.hansson, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, ben-linux, linux-arm-kernel
Cc: Sergio Prado
In-Reply-To: <1484319953-6479-1-git-send-email-sergio.prado@e-labworks.com>
Adds the device tree bindings description for Samsung S3C24XX
MMC/SD/SDIO controller, used as a connectivity interface with external
MMC, SD and SDIO storage mediums.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
.../devicetree/bindings/mmc/samsung,s3cmci.txt | 34 ++++++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
new file mode 100644
index 000000000000..d09dbf4b3824
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
@@ -0,0 +1,34 @@
+* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
+
+Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
+with external MMC, SD and SDIO storage mediums.
+
+This file documents differences between the core mmc properties described by
+mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
+implementation.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
+ - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
+ - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
+- clocks: Should reference the controller clock
+- clock-names: Should contain "sdi"
+
+Example:
+ mmc0: mmc@5a000000 {
+ compatible = "samsung,s3c2440-sdi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdi_pins>;
+ reg = <0x5a000000 0x100000>;
+ interrupts = <0 0 21 3>;
+ clocks = <&clocks PCLK_SDI>;
+ clock-names = "sdi";
+ bus-width = <4>;
+ cd-gpios = <&gpg 8 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gph 8 GPIO_ACTIVE_LOW>;
+ };
+
+ Note: This example shows both SoC specific and board specific properties
+ in a single device node. The properties can be actually be separated
+ into SoC specific node and board specific node.
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/2] mmc: host: s3cmci: allow probing from device tree
From: Sergio Prado @ 2017-01-13 15:05 UTC (permalink / raw)
To: ulf.hansson, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, ben-linux, linux-arm-kernel
Cc: Sergio Prado
In-Reply-To: <1484319953-6479-1-git-send-email-sergio.prado@e-labworks.com>
Allows configuring Samsung S3C24XX MMC/SD/SDIO controller using a device
tree.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
drivers/mmc/host/s3cmci.c | 298 ++++++++++++++++++++++++----------------------
drivers/mmc/host/s3cmci.h | 3 +-
2 files changed, 158 insertions(+), 143 deletions(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 932a4b1fed33..55535b65e0b3 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -23,6 +23,10 @@
#include <linux/gpio.h>
#include <linux/irq.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/mmc/slot-gpio.h>
#include <plat/gpio-cfg.h>
#include <mach/dma.h>
@@ -127,6 +131,22 @@ enum dbg_channels {
dbg_conf = (1 << 8),
};
+struct s3cmci_variant_data {
+ int s3c2440_compatible;
+};
+
+static const struct s3cmci_variant_data s3c2410_s3cmci_variant_data = {
+ .s3c2440_compatible = 0,
+};
+
+static const struct s3cmci_variant_data s3c2412_s3cmci_variant_data = {
+ .s3c2440_compatible = 1,
+};
+
+static const struct s3cmci_variant_data s3c2440_s3cmci_variant_data = {
+ .s3c2440_compatible = 1,
+};
+
static const int dbgmap_err = dbg_fail;
static const int dbgmap_info = dbg_info | dbg_conf;
static const int dbgmap_debug = dbg_err | dbg_debug;
@@ -730,7 +750,7 @@ static irqreturn_t s3cmci_irq(int irq, void *dev_id)
goto clear_status_bits;
/* Check for FIFO failure */
- if (host->is2440) {
+ if (host->variant->s3c2440_compatible) {
if (mci_fsta & S3C2440_SDIFSTA_FIFOFAIL) {
dbg(host, dbg_err, "FIFO failure\n");
host->mrq->data->error = -EILSEQ;
@@ -806,21 +826,6 @@ static irqreturn_t s3cmci_irq(int irq, void *dev_id)
}
-/*
- * ISR for the CardDetect Pin
-*/
-
-static irqreturn_t s3cmci_irq_cd(int irq, void *dev_id)
-{
- struct s3cmci_host *host = (struct s3cmci_host *)dev_id;
-
- dbg(host, dbg_irq, "card detect\n");
-
- mmc_detect_change(host->mmc, msecs_to_jiffies(500));
-
- return IRQ_HANDLED;
-}
-
static void s3cmci_dma_done_callback(void *arg)
{
struct s3cmci_host *host = arg;
@@ -912,7 +917,7 @@ static void finalize_request(struct s3cmci_host *host)
if (s3cmci_host_usedma(host))
dmaengine_terminate_all(host->dma);
- if (host->is2440) {
+ if (host->variant->s3c2440_compatible) {
/* Clear failure register and reset fifo. */
writel(S3C2440_SDIFSTA_FIFORESET |
S3C2440_SDIFSTA_FIFOFAIL,
@@ -1025,7 +1030,7 @@ static int s3cmci_setup_data(struct s3cmci_host *host, struct mmc_data *data)
dcon |= S3C2410_SDIDCON_XFER_RXSTART;
}
- if (host->is2440) {
+ if (host->variant->s3c2440_compatible) {
dcon |= S3C2440_SDIDCON_DS_WORD;
dcon |= S3C2440_SDIDCON_DATSTART;
}
@@ -1044,7 +1049,7 @@ static int s3cmci_setup_data(struct s3cmci_host *host, struct mmc_data *data)
/* write TIMER register */
- if (host->is2440) {
+ if (host->variant->s3c2440_compatible) {
writel(0x007FFFFF, host->base + S3C2410_SDITIMER);
} else {
writel(0x0000FFFF, host->base + S3C2410_SDITIMER);
@@ -1176,19 +1181,6 @@ static void s3cmci_send_request(struct mmc_host *mmc)
s3cmci_enable_irq(host, true);
}
-static int s3cmci_card_present(struct mmc_host *mmc)
-{
- struct s3cmci_host *host = mmc_priv(mmc);
- struct s3c24xx_mci_pdata *pdata = host->pdata;
- int ret;
-
- if (pdata->no_detect)
- return -ENOSYS;
-
- ret = gpio_get_value(pdata->gpio_detect) ? 0 : 1;
- return ret ^ pdata->detect_invert;
-}
-
static void s3cmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct s3cmci_host *host = mmc_priv(mmc);
@@ -1197,7 +1189,7 @@ static void s3cmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
host->cmd_is_stop = 0;
host->mrq = mrq;
- if (s3cmci_card_present(mmc) == 0) {
+ if (mmc_gpio_get_cd(mmc) == 0) {
dbg(host, dbg_err, "%s: no medium present\n", __func__);
host->mrq->cmd->error = -ENOMEDIUM;
mmc_request_done(mmc, mrq);
@@ -1241,22 +1233,24 @@ static void s3cmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_ON:
case MMC_POWER_UP:
/* Configure GPE5...GPE10 pins in SD mode */
- s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
- S3C_GPIO_PULL_NONE);
+ if (!host->pdev->dev.of_node)
+ s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
+ S3C_GPIO_PULL_NONE);
if (host->pdata->set_power)
host->pdata->set_power(ios->power_mode, ios->vdd);
- if (!host->is2440)
+ if (!host->variant->s3c2440_compatible)
mci_con |= S3C2410_SDICON_FIFORESET;
break;
case MMC_POWER_OFF:
default:
- gpio_direction_output(S3C2410_GPE(5), 0);
+ if (!host->pdev->dev.of_node)
+ gpio_direction_output(S3C2410_GPE(5), 0);
- if (host->is2440)
+ if (host->variant->s3c2440_compatible)
mci_con |= S3C2440_SDICON_SDRESET;
if (host->pdata->set_power)
@@ -1294,21 +1288,6 @@ static void s3cmci_reset(struct s3cmci_host *host)
writel(con, host->base + S3C2410_SDICON);
}
-static int s3cmci_get_ro(struct mmc_host *mmc)
-{
- struct s3cmci_host *host = mmc_priv(mmc);
- struct s3c24xx_mci_pdata *pdata = host->pdata;
- int ret;
-
- if (pdata->no_wprotect)
- return 0;
-
- ret = gpio_get_value(pdata->gpio_wprotect) ? 1 : 0;
- ret ^= pdata->wprotect_invert;
-
- return ret;
-}
-
static void s3cmci_enable_sdio_irq(struct mmc_host *mmc, int enable)
{
struct s3cmci_host *host = mmc_priv(mmc);
@@ -1352,8 +1331,8 @@ static void s3cmci_enable_sdio_irq(struct mmc_host *mmc, int enable)
static struct mmc_host_ops s3cmci_ops = {
.request = s3cmci_request,
.set_ios = s3cmci_set_ios,
- .get_ro = s3cmci_get_ro,
- .get_cd = s3cmci_card_present,
+ .get_ro = mmc_gpio_get_ro,
+ .get_cd = mmc_gpio_get_cd,
.enable_sdio_irq = s3cmci_enable_sdio_irq,
};
@@ -1429,7 +1408,7 @@ static int s3cmci_state_show(struct seq_file *seq, void *v)
seq_printf(seq, "Register base = 0x%08x\n", (u32)host->base);
seq_printf(seq, "Clock rate = %ld\n", host->clk_rate);
seq_printf(seq, "Prescale = %d\n", host->prescaler);
- seq_printf(seq, "is2440 = %d\n", host->is2440);
+ seq_printf(seq, "S3C2440 compatible = %d\n", host->variant->s3c2440_compatible);
seq_printf(seq, "IRQ = %d\n", host->irq);
seq_printf(seq, "IRQ enabled = %d\n", host->irq_enabled);
seq_printf(seq, "IRQ disabled = %d\n", host->irq_disabled);
@@ -1544,21 +1523,15 @@ static inline void s3cmci_debugfs_remove(struct s3cmci_host *host) { }
#endif /* CONFIG_DEBUG_FS */
-static int s3cmci_probe(struct platform_device *pdev)
+static int s3cmci_probe_pdata(struct s3cmci_host *host)
{
- struct s3cmci_host *host;
- struct mmc_host *mmc;
- int ret;
- int is2440;
- int i;
+ struct platform_device *pdev = host->pdev;
+ struct mmc_host *mmc = host->mmc;
+ struct s3c24xx_mci_pdata *pdata;
+ int i, ret;
- is2440 = platform_get_device_id(pdev)->driver_data;
-
- mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
- if (!mmc) {
- ret = -ENOMEM;
- goto probe_out;
- }
+ host->variant = (const struct s3cmci_variant_data *)
+ platform_get_device_id(pdev)->driver_data;
for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++) {
ret = gpio_request(i, dev_name(&pdev->dev));
@@ -1568,25 +1541,103 @@ static int s3cmci_probe(struct platform_device *pdev)
for (i--; i >= S3C2410_GPE(5); i--)
gpio_free(i);
- goto probe_free_host;
+ return ret;
}
}
+ if (!pdev->dev.platform_data)
+ pdev->dev.platform_data = &s3cmci_def_pdata;
+
+ pdata = pdev->dev.platform_data;
+
+ if (pdata->no_wprotect)
+ mmc->caps2 |= MMC_CAP2_NO_WRITE_PROTECT;
+
+ if (pdata->no_detect)
+ mmc->caps |= MMC_CAP_NEEDS_POLL;
+
+ if (pdata->wprotect_invert);
+ mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
+
+ if (pdata->detect_invert)
+ mmc->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+
+ if (gpio_is_valid(pdata->gpio_detect)) {
+ ret = mmc_gpio_request_cd(mmc, pdata->gpio_detect, 0);
+ if (ret) {
+ dev_err(&pdev->dev, "error requesting GPIO for CD %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ if (gpio_is_valid(pdata->gpio_wprotect)) {
+ ret = mmc_gpio_request_ro(mmc, pdata->gpio_wprotect);
+ if (ret) {
+ dev_err(&pdev->dev, "error requesting GPIO for WP %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int s3cmci_probe_dt(struct s3cmci_host *host)
+{
+ struct platform_device *pdev = host->pdev;
+ struct s3c24xx_mci_pdata *pdata;
+ struct mmc_host *mmc = host->mmc;
+ int ret;
+
+ host->variant = of_device_get_match_data(&pdev->dev);
+ if (!host->variant)
+ return -ENODEV;
+
+ ret = mmc_of_parse(mmc);
+ if (ret)
+ return ret;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+
+static int s3cmci_probe(struct platform_device *pdev)
+{
+ struct s3cmci_host *host;
+ struct mmc_host *mmc;
+ int ret;
+ int i;
+
+ mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
+ if (!mmc) {
+ ret = -ENOMEM;
+ goto probe_out;
+ }
+
host = mmc_priv(mmc);
host->mmc = mmc;
host->pdev = pdev;
- host->is2440 = is2440;
+
+ if (pdev->dev.of_node)
+ ret = s3cmci_probe_dt(host);
+ else
+ ret = s3cmci_probe_pdata(host);
+
+ if (ret)
+ goto probe_free_host;
host->pdata = pdev->dev.platform_data;
- if (!host->pdata) {
- pdev->dev.platform_data = &s3cmci_def_pdata;
- host->pdata = &s3cmci_def_pdata;
- }
spin_lock_init(&host->complete_lock);
tasklet_init(&host->pio_tasklet, pio_tasklet, (unsigned long) host);
- if (is2440) {
+ if (host->variant->s3c2440_compatible) {
host->sdiimsk = S3C2440_SDIIMSK;
host->sdidata = S3C2440_SDIDATA;
host->clk_div = 1;
@@ -1644,43 +1695,6 @@ static int s3cmci_probe(struct platform_device *pdev)
disable_irq(host->irq);
host->irq_state = false;
- if (!host->pdata->no_detect) {
- ret = gpio_request(host->pdata->gpio_detect, "s3cmci detect");
- if (ret) {
- dev_err(&pdev->dev, "failed to get detect gpio\n");
- goto probe_free_irq;
- }
-
- host->irq_cd = gpio_to_irq(host->pdata->gpio_detect);
-
- if (host->irq_cd >= 0) {
- if (request_irq(host->irq_cd, s3cmci_irq_cd,
- IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
- DRIVER_NAME, host)) {
- dev_err(&pdev->dev,
- "can't get card detect irq.\n");
- ret = -ENOENT;
- goto probe_free_gpio_cd;
- }
- } else {
- dev_warn(&pdev->dev,
- "host detect has no irq available\n");
- gpio_direction_input(host->pdata->gpio_detect);
- }
- } else
- host->irq_cd = -1;
-
- if (!host->pdata->no_wprotect) {
- ret = gpio_request(host->pdata->gpio_wprotect, "s3cmci wp");
- if (ret) {
- dev_err(&pdev->dev, "failed to get writeprotect\n");
- goto probe_free_irq_cd;
- }
-
- gpio_direction_input(host->pdata->gpio_wprotect);
- }
-
/* Depending on the dma state, get a DMA channel to use. */
if (s3cmci_host_usedma(host)) {
@@ -1688,7 +1702,7 @@ static int s3cmci_probe(struct platform_device *pdev)
ret = PTR_ERR_OR_ZERO(host->dma);
if (ret) {
dev_err(&pdev->dev, "cannot get DMA channel.\n");
- goto probe_free_gpio_wp;
+ goto probe_free_irq;
}
}
@@ -1730,7 +1744,7 @@ static int s3cmci_probe(struct platform_device *pdev)
dbg(host, dbg_debug,
"probe: mode:%s mapped mci_base:%p irq:%u irq_cd:%u dma:%p.\n",
- (host->is2440?"2440":""),
+ (host->variant->s3c2440_compatible?"2440":""),
host->base, host->irq, host->irq_cd, host->dma);
ret = s3cmci_cpufreq_register(host);
@@ -1767,18 +1781,6 @@ static int s3cmci_probe(struct platform_device *pdev)
if (s3cmci_host_usedma(host))
dma_release_channel(host->dma);
- probe_free_gpio_wp:
- if (!host->pdata->no_wprotect)
- gpio_free(host->pdata->gpio_wprotect);
-
- probe_free_gpio_cd:
- if (!host->pdata->no_detect)
- gpio_free(host->pdata->gpio_detect);
-
- probe_free_irq_cd:
- if (host->irq_cd >= 0)
- free_irq(host->irq_cd, host);
-
probe_free_irq:
free_irq(host->irq, host);
@@ -1789,8 +1791,9 @@ static int s3cmci_probe(struct platform_device *pdev)
release_mem_region(host->mem->start, resource_size(host->mem));
probe_free_gpio:
- for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
- gpio_free(i);
+ if (!pdev->dev.of_node)
+ for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
+ gpio_free(i);
probe_free_host:
mmc_free_host(mmc);
@@ -1817,7 +1820,6 @@ static int s3cmci_remove(struct platform_device *pdev)
{
struct mmc_host *mmc = platform_get_drvdata(pdev);
struct s3cmci_host *host = mmc_priv(mmc);
- struct s3c24xx_mci_pdata *pd = host->pdata;
int i;
s3cmci_shutdown(pdev);
@@ -1831,15 +1833,9 @@ static int s3cmci_remove(struct platform_device *pdev)
free_irq(host->irq, host);
- if (!pd->no_wprotect)
- gpio_free(pd->gpio_wprotect);
-
- if (!pd->no_detect)
- gpio_free(pd->gpio_detect);
-
- for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
- gpio_free(i);
-
+ if (!pdev->dev.of_node)
+ for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
+ gpio_free(i);
iounmap(host->base);
release_mem_region(host->mem->start, resource_size(host->mem));
@@ -1848,16 +1844,33 @@ static int s3cmci_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id s3cmci_dt_match[] = {
+ {
+ .compatible = "samsung,s3c2410-sdi",
+ .data = &s3c2410_s3cmci_variant_data,
+ },
+ {
+ .compatible = "samsung,s3c2412-sdi",
+ .data = &s3c2412_s3cmci_variant_data,
+ },
+ {
+ .compatible = "samsung,s3c2440-sdi",
+ .data = &s3c2440_s3cmci_variant_data,
+ },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
+
static const struct platform_device_id s3cmci_driver_ids[] = {
{
.name = "s3c2410-sdi",
- .driver_data = 0,
+ .driver_data = (kernel_ulong_t) &s3c2410_s3cmci_variant_data,
}, {
.name = "s3c2412-sdi",
- .driver_data = 1,
+ .driver_data = (kernel_ulong_t) &s3c2412_s3cmci_variant_data,
}, {
.name = "s3c2440-sdi",
- .driver_data = 1,
+ .driver_data = (kernel_ulong_t) &s3c2440_s3cmci_variant_data,
},
{ }
};
@@ -1867,6 +1880,7 @@ static int s3cmci_remove(struct platform_device *pdev)
static struct platform_driver s3cmci_driver = {
.driver = {
.name = "s3c-sdi",
+ .of_match_table = s3cmci_dt_match,
},
.id_table = s3cmci_driver_ids,
.probe = s3cmci_probe,
diff --git a/drivers/mmc/host/s3cmci.h b/drivers/mmc/host/s3cmci.h
index 30c2c0dd1bc8..e9fe48915a2e 100644
--- a/drivers/mmc/host/s3cmci.h
+++ b/drivers/mmc/host/s3cmci.h
@@ -33,7 +33,8 @@ struct s3cmci_host {
unsigned long real_rate;
u8 prescaler;
- int is2440;
+ const struct s3cmci_variant_data *variant;
+
unsigned sdiimsk;
unsigned sdidata;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] clk: ux500: Add device tree bindings for ABx500 clocks
From: Linus Walleij @ 2017-01-13 15:08 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, devicetree, Linus Walleij, Ulf Hansson
This adds device tree bindings for the ABx500 clocks on the
ST-Ericsson platforms.
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/clock/stericsson,abx500.txt | 13 +++++++++++++
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/stericsson,abx500.txt
diff --git a/Documentation/devicetree/bindings/clock/stericsson,abx500.txt b/Documentation/devicetree/bindings/clock/stericsson,abx500.txt
new file mode 100644
index 000000000000..8764d80e3412
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/stericsson,abx500.txt
@@ -0,0 +1,13 @@
+Clock bindings for ST-Ericsson ABx500 clocks
+
+Required properties :
+- compatible : shall contain the following:
+ "stericsson,ab8500-clk"
+- #clock-cells should be <1>
+
+Example:
+
+ab8500_clock: ab8500-clock {
+ compatible = "stericsson,ab8500-clk";
+ #clock-cells = <1>;
+};
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Geert Uytterhoeven @ 2017-01-13 15:10 UTC (permalink / raw)
To: Chris Brandt
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <PS1PR06MB116243F531726538252C2BAE8A780-l4vAwRX7WilTTnd0MlXEO20DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Chris,
On Fri, Jan 13, 2017 at 3:44 PM, Chris Brandt <Chris.Brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
>> This is strange. There are two SDHI channels, but the STBCR12
>> documentation (all versions up to rev. 3.00) says the register has MSTP
>> bits for four SD host interfaces?
>>
>> Can you please enlighten me? Thanks!
>
> If you look in the rev 3.00 manual for RZ/A1H, in section
> "50.3.2 Card Detect/Write Protect", it says:
>
> * Power-Down mode at Card removal
> SD Host Interface module is halted by the MSTP123 bit to MSTP120 bit in Standby Control Register 12
> (STBCR12). If these bits of each channel in STBCR12 are set to 10, low power consumption is achieved at Card
> removal. See section 55, Power-Down Modes
>
>
> So, there are 2 clock sources for each SDHI channel, and the setting
> Options are:
> SD Host Interface 0 Module Stop
> 00: SD Host Interface 0 Module runs.
> 01: Setting prohibited.
> 10: Only card detect block in SD Host Interface 0 Module runs.
> 11: Clock supply to SD Host Interface 0 Module is halted
So typically you want to use 10 when idle, and 00 when active.
> Previously I've been running with '00' because I was turning EVERYTHING on
> in u-boot.
> Yesterday, I tested with just '10' and things seem to work OK
> for me.
>
> Since the sh_mobile_sdhi/tmio driver only allows for 1 clock per channel,
> '10' is my only choice for the DT.
>
> However, looking at a previous BSP for RZ/A1, the driver
> arch/arm/mach-shmobile/clock-r7s72100.c had this:
>
>
> static struct clk mstp_clks[MSTP_NR] = {
> [MSTP123] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 3, 0), /* SDHI00 */
> [MSTP122] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 2,
> CLK_ENABLE_ON_INIT), /* SDHI01 */
> [MSTP121] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 1, 0), /* SDHI10 */
> [MSTP120] = SH_CLK_MSTP8(&peripheral1_clk, STBCR12, 0,
> CLK_ENABLE_ON_INIT), /* SDHI11 */
>
>
> But...that would make me think on boot it would be set to '01' (setting prohibited).
Yeah, running with enabled SDHI core and disabled card detect sounds silly.
> I'm going to try and find if "setting prohibited" really just means:
> "you can set it this way...but nothing is really going to work unless you
> enable the other clock".
>
> If that is the case, is there a DT equivalent to "CLK_ENABLE_ON_INIT" that
> I can do for MSTP120(SDHI11) and MSTP120(SDHI01) so they are both cleared
> on boot???
No there isn't. That's another reason why a full-fledged clock driver with
tables in C is a better idea than trying to describe all clocks in DT.
The new CPG/MSSR based driver (renesas-cpg-mssr.c) supports "critical
module clocks" through CLK_ENABLE_HAND_OFF. Unfortunately that flag hasn't
made it upstream, so I really should convert the driver to use the new
CLK_IS_CRITICAL instead...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v1 2/2] arm: dts: mt2701: add nor flash node
From: Matthias Brugger @ 2017-01-13 15:12 UTC (permalink / raw)
To: Boris Brezillon, Guochun Mao
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Russell King,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170113151747.6bc85245@bbrezillon>
On 13/01/17 15:17, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 15:13:29 +0800
> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>
>> 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";
>
> Why define both here? Is "mediatek,mt8173-nor" really providing a
> subset of the features supported by "mediatek,mt2701-nor"?
>
I think even if the ip block is the same, we should provide both
bindings, just in case in the future we find out that mt2701 has some
hidden bug, feature or bug-feature. This way even if we update the
driver, we stay compatible with older device tree blobs in the wild.
We can drop the mt2701-nor in the bindings definition if you want.
Regards,
Matthias
>> + 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>;
>
--
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 v3 16/24] media: Add i.MX media core driver
From: Philipp Zabel @ 2017-01-13 15:20 UTC (permalink / raw)
To: Steve Longerbeam
Cc: robh+dt, mark.rutland, shawnguo, kernel, fabio.estevam, linux,
mchehab, hverkuil, nick, markus.heiser, laurent.pinchart+renesas,
bparrot, geert, arnd, sudipm.mukherjee, minghsiu.tsai,
tiffany.lin, jean-christophe.trotin, horms+renesas,
niklas.soderlund+renesas, robert.jarzmik, songjun.wu,
andrew-ct.chen, gregkh, devicetree, linux-kernel,
linux-arm-kernel, linux-media, devel, Steve Longerbeam
In-Reply-To: <1483755102-24785-17-git-send-email-steve_longerbeam@mentor.com>
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> Documentation/media/v4l-drivers/imx.rst | 443 ++++++++++
> drivers/staging/media/Kconfig | 2 +
> drivers/staging/media/Makefile | 1 +
> drivers/staging/media/imx/Kconfig | 8 +
> drivers/staging/media/imx/Makefile | 6 +
> drivers/staging/media/imx/TODO | 22 +
> drivers/staging/media/imx/imx-media-common.c | 981 ++++++++++++++++++++++
> drivers/staging/media/imx/imx-media-dev.c | 486 +++++++++++
> drivers/staging/media/imx/imx-media-fim.c | 471 +++++++++++
> drivers/staging/media/imx/imx-media-internal-sd.c | 457 ++++++++++
> drivers/staging/media/imx/imx-media-of.c | 289 +++++++
> drivers/staging/media/imx/imx-media.h | 310 +++++++
> include/media/imx.h | 15 +
> include/uapi/linux/v4l2-controls.h | 4 +
> 14 files changed, 3495 insertions(+)
> create mode 100644 Documentation/media/v4l-drivers/imx.rst
> create mode 100644 drivers/staging/media/imx/Kconfig
> create mode 100644 drivers/staging/media/imx/Makefile
> create mode 100644 drivers/staging/media/imx/TODO
> create mode 100644 drivers/staging/media/imx/imx-media-common.c
> create mode 100644 drivers/staging/media/imx/imx-media-dev.c
> create mode 100644 drivers/staging/media/imx/imx-media-fim.c
> create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
> create mode 100644 drivers/staging/media/imx/imx-media-of.c
> create mode 100644 drivers/staging/media/imx/imx-media.h
> create mode 100644 include/media/imx.h
>
> diff --git a/Documentation/media/v4l-drivers/imx.rst b/Documentation/media/v4l-drivers/imx.rst
> new file mode 100644
> index 0000000..87b37b5
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/imx.rst
> @@ -0,0 +1,443 @@
> +i.MX Video Capture Driver
> +=========================
> +
> +Introduction
> +------------
> +
> +The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
> +handles the flow of image frames to and from capture devices and
> +display devices.
> +
> +For image capture, the IPU contains the following internal subunits:
> +
> +- Image DMA Controller (IDMAC)
> +- Camera Serial Interface (CSI)
> +- Image Converter (IC)
> +- Sensor Multi-FIFO Controller (SMFC)
> +- Image Rotator (IRT)
> +- Video De-Interlace Controller (VDIC)
Nitpick: Video De-Interlacing or Combining Block (VDIC)
> +
> +The IDMAC is the DMA controller for transfer of image frames to and from
> +memory. Various dedicated DMA channels exist for both video capture and
> +display paths.
> +
> +The CSI is the frontend capture unit that interfaces directly with
> +capture sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
> +
> +The IC handles color-space conversion, resizing, and rotation
> +operations.
And horizontal flipping.
> There are three independent "tasks" within the IC that can
> +carry out conversions concurrently: pre-processing encoding,
> +pre-processing preview, and post-processing.
s/preview/viewfinder/ seems to be the commonly used name.
This paragraph could mention that a single hardware unit is used
transparently time multiplexed by the three tasks at different
granularity for the downsizing, main processing, and rotation sections.
The downscale unit switches between tasks at 8-pixel burst granularity,
the main processing unit at line granularity. The rotation units switch
only at frame granularity.
> +The SMFC is composed of four independent channels that each can transfer
> +captured frames from sensors directly to memory concurrently.
> +
> +The IRT carries out 90 and 270 degree image rotation operations.
... on 8x8 pixel blocks, supported by the IDMAC which handles block
transfers, block reordering, and vertical flipping.
> +The VDIC handles the conversion of interlaced video to progressive, with
> +support for different motion compensation modes (low, medium, and high
> +motion). The deinterlaced output frames from the VDIC can be sent to the
> +IC pre-process preview task for further conversions.
> +
> +In addition to the IPU internal subunits, there are also two units
> +outside the IPU that are also involved in video capture on i.MX:
> +
> +- MIPI CSI-2 Receiver for camera sensors with the MIPI CSI-2 bus
> + interface. This is a Synopsys DesignWare core.
> +- A video multiplexer for selecting among multiple sensor inputs to
> + send to a CSI.
Two of them, actually.
> +For more info, refer to the latest versions of the i.MX5/6 reference
> +manuals listed under References.
> +
> +
> +Features
> +--------
> +
> +Some of the features of this driver include:
> +
> +- Many different pipelines can be configured via media controller API,
> + that correspond to the hardware video capture pipelines supported in
> + the i.MX.
> +
> +- Supports parallel, BT.565, and MIPI CSI-2 interfaces.
> +
> +- Up to four concurrent sensor acquisitions, by configuring each
> + sensor's pipeline using independent entities. This is currently
> + demonstrated with the SabreSD and SabreLite reference boards with
> + independent OV5642 and MIPI CSI-2 OV5640 sensor modules.
> +
> +- Scaling, color-space conversion, and image rotation via IC task
> + subdevs.
> +
> +- Many pixel formats supported (RGB, packed and planar YUV, partial
> + planar YUV).
> +
> +- The IC pre-process preview subdev supports motion compensated
> + de-interlacing using the VDIC, with three motion compensation modes:
> + low, medium, and high motion. The mode is specified with a custom
> + control. Pipelines are defined that allow sending frames to the
> + preview subdev directly from the CSI or from the SMFC.
> +
> +- Includes a Frame Interval Monitor (FIM) that can correct vertical sync
> + problems with the ADV718x video decoders. See below for a description
> + of the FIM.
Could this also be used to calculate more precise capture timestamps?
> +Capture Pipelines
> +-----------------
> +
> +The following describe the various use-cases supported by the pipelines.
> +
> +The links shown do not include the frontend sensor, video mux, or mipi
> +csi-2 receiver links. This depends on the type of sensor interface
> +(parallel or mipi csi-2). So in all cases, these pipelines begin with:
> +
> +sensor -> ipu_csi_mux -> ipu_csi -> ...
> +
> +for parallel sensors, or:
> +
> +sensor -> imx-mipi-csi2 -> (ipu_csi_mux) -> ipu_csi -> ...
> +
> +for mipi csi-2 sensors. The imx-mipi-csi2 receiver may need to route
> +to the video mux (ipu_csi_mux) before sending to the CSI, depending
> +on the mipi csi-2 virtual channel, hence ipu_csi_mux is shown in
> +parenthesis.
> +
> +Unprocessed Video Capture:
> +--------------------------
> +
> +Send frames directly from sensor to camera interface, with no
> +conversions:
> +
> +-> ipu_smfc -> camif
I'd call this capture interface, this is not just for cameras. Or maybe
idmac if you want to mirror hardware names?
> +Note the ipu_smfc can do pixel reordering within the same colorspace.
That isn't a feature of the SMFC, but of the IDMAC (FCW & FCR).
> +For example, its sink pad can take UYVY2X8, but its source pad can
> +output YUYV2X8.
I don't think this is correct. Re-reading "37.4.3.7 Packing to memory"
in the CSI chapter, for 8-bit per component data, the internal format
between CSI, SMFC, and IDMAC is always some 32-bit RGBx/YUVx variant
(or "bayer/generic data"). In either case, the internal format does not
change along the way.
> +IC Direct Conversions:
> +----------------------
> +
> +This pipeline uses the preprocess encode entity to route frames directly
> +from the CSI to the IC (bypassing the SMFC), to carry out scaling up to
> +1024x1024 resolution, CSC, and image rotation:
> +
> +-> ipu_ic_prpenc -> camif
> +
> +This can be a useful capture pipeline for heavily loaded memory bus
> +traffic environments, since it has minimal IDMAC channel usage.
Note that if rotation is enabled, transfers between IC processing and
rotation still have to go through memory once.
> +Post-Processing Conversions:
> +----------------------------
> +
> +This pipeline routes frames from the SMFC to the post-processing
> +entity.
No, frames written by the CSI -> SMFC -> IDMAC path are read back into
the post-processing entity.
> In addition to CSC and rotation, this entity supports tiling
> +which allows scaled output beyond the 1024x1024 limitation of the IC
> +(up to 4096x4096 scaling output is supported):
> +
> +-> ipu_smfc -> ipu_ic_pp -> camif
> +
> +Motion Compensated De-interlace:
> +--------------------------------
> +
> +This pipeline routes frames from the SMFC to the preprocess preview
> +entity to support motion-compensated de-interlacing using the VDIC,
> +scaling up to 1024x1024, and CSC:
> +
> +-> ipu_smfc -> ipu_ic_prpvf -> camif
Same as above.
> +This pipeline also carries out the same conversions as above, but routes
> +frames directly from the CSI to the IC preprocess preview entity for
> +minimal memory bandwidth usage (note: this pipeline only works in
> +"high motion" mode):
> +
> +-> ipu_ic_prpvf -> camif
> +
> +This pipeline takes the motion-compensated de-interlaced frames and
> +sends them to the post-processor, to support motion-compensated
> +de-interlacing, scaling up to 4096x4096, CSC, and rotation:
> +
> +-> (ipu_smfc) -> ipu_ic_prpvf -> ipu_ic_pp -> camif
> +
> +
> +Usage Notes
> +-----------
[...]
> +SabreLite with OV5642 and OV5640
> +--------------------------------
> +
> +This platform requires the OmniVision OV5642 module with a parallel
> +camera interface, and the OV5640 module with a MIPI CSI-2
> +interface. Both modules are available from Boundary Devices:
> +
> +https://boundarydevices.com/products/nit6x_5mp
> +https://boundarydevices.com/product/nit6x_5mp_mipi
> +
> +Note that if only one camera module is available, the other sensor
> +node can be disabled in the device tree.
> +
> +The OV5642 module is connected to the parallel bus input on the i.MX
> +internal video mux to IPU1 CSI0. It's i2c bus connects to i2c bus 2.
> +
> +The MIPI CSI-2 OV5640 module is connected to the i.MX internal MIPI CSI-2
> +receiver, and the four virtual channel outputs from the receiver are
> +routed as follows: vc0 to the IPU1 CSI0 mux, vc1 directly to IPU1 CSI1,
> +vc2 directly to IPU2 CSI0, and vc3 to the IPU2 CSI1 mux. The OV5640 is
> +also connected to i2c bus 2 on the SabreLite, therefore the OV5642 and
> +OV5640 must not share the same i2c slave address.
> +
> +The following basic example configures unprocessed video capture
> +pipelines for both sensors. The OV5642 is routed to camif0
> +(usually /dev/video0), and the OV5640 (transmitting on mipi csi-2
> +virtual channel 1) is routed to camif1 (usually /dev/video1). Both
> +sensors are configured to output 640x480, UYVY (not shown: all pad
> +field types should be set to "NONE"):
> +
> +.. code-block:: none
> +
> + # Setup links for OV5642
> + media-ctl -l '"ov5642 1-0042":0 -> "ipu1_csi0_mux":1[1]'
> + media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
> + media-ctl -l '"ipu1_csi0":1 -> "ipu1_smfc0":0[1]'
> + media-ctl -l '"ipu1_smfc0":1 -> "camif0":0[1]'
> + media-ctl -l '"camif0":1 -> "camif0 devnode":0[1]'
> + # Setup links for OV5640
> + media-ctl -l '"ov5640_mipi 1-0040":0 -> "imx-mipi-csi2":0[1]'
> + media-ctl -l '"imx-mipi-csi2":2 -> "ipu1_csi1":0[1]'
> + media-ctl -l '"ipu1_csi1":1 -> "ipu1_smfc1":0[1]'
> + media-ctl -l '"ipu1_smfc1":1 -> "camif1":0[1]'
> + media-ctl -l '"camif1":1 -> "camif1 devnode":0[1]'
> + # Configure pads for OV5642 pipeline
> + media-ctl -V "\"ov5642 1-0042\":0 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0_mux\":1 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0_mux\":2 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0\":0 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_csi0\":1 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_smfc0\":0 [fmt:YUYV2X8/640x480]"
> + media-ctl -V "\"ipu1_smfc0\":1 [fmt:UYVY2X8/640x480]"
I think the smfc entities should be dropped.
> + media-ctl -V "\"camif0\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"camif0\":1 [fmt:UYVY2X8/640x480]"
> + # Configure pads for OV5640 pipeline
> + media-ctl -V "\"ov5640_mipi 1-0040\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"imx-mipi-csi2\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"imx-mipi-csi2\":2 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"ipu1_csi1\":0 [fmt:UYVY2X8/640x480]"
> + media-ctl -V "\"ipu1_csi1\":1 [fmt:UYVY2X8/640x480]"
[...]
> + media-ctl -V "\"camif1\":0 [fmt:UYVY2X8/640x480]"
I agree this looks very intuitive, but technically correct for the
csi1:1 and camif1:0 pads would be a 32-bit YUV format.
(MEDIA_BUS_FMT_YUV8_1X32_PADLO doesn't exist yet).
I think it would be better to use the correct format as that will allow
to chose the regular vs. companded packings in the future for formats
with more than 8 bits per component.
> + media-ctl -V "\"camif1\":1 [fmt:UYVY2X8/640x480]"
>+
> +Streaming can then begin independently on device nodes /dev/video0
> +and /dev/video1.
> +
> +SabreAuto with ADV7180 decoder
> +------------------------------
> +
> +On the SabreAuto, an on-board ADV7180 SD decoder is connected to the
> +parallel bus input on the internal video mux to IPU1 CSI0.
> +
> +The following example configures a pipeline to capture from the ADV7180
> +video decoder, assuming NTSC 720x480 input signals, with Motion
> +Compensated de-interlacing (not shown: all pad field types should be set
> +as indicated). $outputfmt can be any format supported by the
> +ipu1_ic_prpvf entity at its output pad:
> +
> +.. code-block:: none
> +
> + # Setup links
> + media-ctl -l '"adv7180 3-0021":0 -> "ipu1_csi0_mux":1[1]'
> + media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
> + media-ctl -l '"ipu1_csi0":1 -> "ipu1_smfc0":0[1]'
> + media-ctl -l '"ipu1_smfc0":1 -> "ipu1_ic_prpvf":0[1]'
> + media-ctl -l '"ipu1_ic_prpvf":1 -> "camif0":0[1]'
> + media-ctl -l '"camif0":1 -> "camif0 devnode":0[1]'
> + # Configure pads
> + # pad field types for below pads must be an interlaced type
> + # such as "ALTERNATE"
I think alternate should only extend as far as the CSI, since the CSI
can only capture NTSC/PAL fields in a fixed order.
> + media-ctl -V "\"adv7180 3-0021\":0 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_csi0_mux\":1 [fmt:UYVY2X8/720x480]"
>From here the interlaced field type should be sequential in the correct
order depending on NTSC/PAL.
> + media-ctl -V "\"ipu1_csi0_mux\":2 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_csi0\":0 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_csi0\":1 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_smfc0\":0 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_smfc0\":1 [fmt:UYVY2X8/720x480]"
> + media-ctl -V "\"ipu1_ic_prpvf\":0 [fmt:UYVY2X8/720x480]"
> + # pad field types for below pads must be "NONE"
> + media-ctl -V "\"ipu1_ic_prpvf\":1 [fmt:$outputfmt]"
> + media-ctl -V "\"camif0\":0 [fmt:$outputfmt]"
> + media-ctl -V "\"camif0\":1 [fmt:$outputfmt]"
> +
> +Streaming can then begin on /dev/video0.
> +
> +This platform accepts Composite Video analog inputs to the ADV7180 on
> +Ain1 (connector J42) and Ain3 (connector J43).
> +
> +To switch to Ain1:
> +
> +.. code-block:: none
> +
> + # v4l2-ctl -i0
> +
> +To switch to Ain3:
> +
> +.. code-block:: none
> +
> + # v4l2-ctl -i1
> +
> +
> +Frame Interval Monitor
> +----------------------
> +
> +The adv718x decoders can occasionally send corrupt fields during
> +NTSC/PAL signal re-sync (too little or too many video lines). When
> +this happens, the IPU triggers a mechanism to re-establish vertical
> +sync by adding 1 dummy line every frame, which causes a rolling effect
> +from image to image, and can last a long time before a stable image is
> +recovered. Or sometimes the mechanism doesn't work at all, causing a
> +permanent split image (one frame contains lines from two consecutive
> +captured images).
Is it only SabreAuto on which the FIM mechanism can be used due to the
pad routing?
[...]
> +/*
> + * DMA buffer ring handling
> + */
> +struct imx_media_dma_buf_ring {
> + struct imx_media_dev *imxmd;
> +
> + /* the ring */
> + struct imx_media_dma_buf buf[IMX_MEDIA_MAX_RING_BUFS];
> + /* the scratch buffer for underruns */
> + struct imx_media_dma_buf scratch;
> +
> + /* buffer generator */
> + struct media_entity *src;
> + /* buffer receiver */
> + struct media_entity *sink;
> +
> + spinlock_t lock;
> +
> + int num_bufs;
> + unsigned long last_seq;
> +};
I don't think this belongs in the capture driver at all.
Memory-to-memory transfers should be handled at the videobuf2 level.
[...]
> +static struct imx_media_dma_buf *
> +__dma_buf_queue(struct imx_media_dma_buf_ring *ring, int index)
> +{
> + struct imx_media_dma_buf *buf;
> +
> + if (index >= ring->num_bufs)
> + return ERR_PTR(-EINVAL);
> +
> + buf = &ring->buf[index];
> + if (WARN_ON(buf->state != IMX_MEDIA_BUF_STATUS_PREPARED))
> + return ERR_PTR(-EINVAL);
> +
> + buf->state = IMX_MEDIA_BUF_STATUS_QUEUED;
> + buf->seq = ring->last_seq++;
> +
> + return buf;
> +}
Is this a whole software buffer queue implementation? I thought the
whole point of putting the custom mem2mem framework into the capture
driver was to use the hardware FSU channel linking?
> +int imx_media_dma_buf_queue(struct imx_media_dma_buf_ring *ring, int index)
> +{
> + struct imx_media_dma_buf *buf;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ring->lock, flags);
> + buf = __dma_buf_queue(ring, index);
> + spin_unlock_irqrestore(&ring->lock, flags);
> +
> + if (IS_ERR(buf))
> + return PTR_ERR(buf);
> +
> + dev_dbg(ring->imxmd->dev, "buf%d [%s -> %s] queued\n",
> + index, ring->src->name, ring->sink->name);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(imx_media_dma_buf_queue);
> +
> +int imx_media_dma_buf_queue_from_vb(struct imx_media_dma_buf_ring *ring,
> + struct vb2_buffer *vb)
> +{
> + struct imx_media_dma_buf *buf;
> + unsigned long flags;
> + dma_addr_t phys;
> + void *virt;
> +
> + if (vb->index >= ring->num_bufs)
> + return -EINVAL;
> +
> + virt = vb2_plane_vaddr(vb, 0);
> + phys = vb2_dma_contig_plane_dma_addr(vb, 0);
> +
> + spin_lock_irqsave(&ring->lock, flags);
> + buf = __dma_buf_queue(ring, vb->index);
> + if (IS_ERR(buf))
> + goto err_unlock;
> +
> + buf->virt = virt;
> + buf->phys = phys;
> + buf->vb = vb;
> + spin_unlock_irqrestore(&ring->lock, flags);
> +
> + dev_dbg(ring->imxmd->dev, "buf%d [%s -> %s] queued from vb\n",
> + buf->index, ring->src->name, ring->sink->name);
> +
> + return 0;
> +err_unlock:
> + spin_unlock_irqrestore(&ring->lock, flags);
> + return PTR_ERR(buf);
> +}
> +EXPORT_SYMBOL_GPL(imx_media_dma_buf_queue_from_vb);
> +
> +void imx_media_dma_buf_done(struct imx_media_dma_buf *buf,
> + enum imx_media_dma_buf_status status)
> +{
> + struct imx_media_dma_buf_ring *ring = buf->ring;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ring->lock, flags);
> + WARN_ON(buf->state != IMX_MEDIA_BUF_STATUS_ACTIVE);
> + buf->state = buf->status = status;
> + spin_unlock_irqrestore(&ring->lock, flags);
> +
> + if (buf == &ring->scratch)
> + dev_dbg(ring->imxmd->dev, "buf-scratch [%s -> %s] done\n",
> + ring->src->name, ring->sink->name);
> + else
> + dev_dbg(ring->imxmd->dev, "buf%d [%s -> %s] done\n",
> + buf->index, ring->src->name, ring->sink->name);
> +
> + /* if the sink is a subdev, inform it that new buffers are available */
> + if (is_media_entity_v4l2_subdev(ring->sink)) {
> + struct v4l2_subdev *sd =
> + media_entity_to_v4l2_subdev(ring->sink);
> + v4l2_subdev_call(sd, core, ioctl, IMX_MEDIA_NEW_DMA_BUF, NULL);
What is the purpose of this if the sink should be triggered by the FSU?
[...]
> +/*
> + * The subdevs have to be powered on/off, and streaming
> + * enabled/disabled, in a specific sequence.
> + */
> +static const u32 stream_on_seq[] = {
> + IMX_MEDIA_GRP_ID_IC_PP,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_SENSOR,
> + IMX_MEDIA_GRP_ID_CSI2,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_CSI,
> +};
> +
> +static const u32 stream_off_seq[] = {
> + IMX_MEDIA_GRP_ID_IC_PP,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_CSI,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_CSI2,
> + IMX_MEDIA_GRP_ID_SENSOR,
> +};
> +
> +#define NUM_STREAM_ENTITIES ARRAY_SIZE(stream_on_seq)
> +
> +static const u32 power_on_seq[] = {
> + IMX_MEDIA_GRP_ID_CSI2,
> + IMX_MEDIA_GRP_ID_SENSOR,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_CSI,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PP,
> +};
> +
> +static const u32 power_off_seq[] = {
> + IMX_MEDIA_GRP_ID_IC_PP,
> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> + IMX_MEDIA_GRP_ID_SMFC,
> + IMX_MEDIA_GRP_ID_CSI,
> + IMX_MEDIA_GRP_ID_VIDMUX,
> + IMX_MEDIA_GRP_ID_SENSOR,
> + IMX_MEDIA_GRP_ID_CSI2,
> +};
This seems somewhat arbitrary. Why is a power sequence needed?
[...]
> +/*
> + * Turn current pipeline power on/off starting from start_entity.
> + * Must be called with mdev->graph_mutex held.
> + */
> +int imx_media_pipeline_set_power(struct imx_media_dev *imxmd,
> + struct media_entity_graph *graph,
> + struct media_entity *start_entity, bool on)
> +{
> + struct media_entity *entity;
> + struct v4l2_subdev *sd;
> + int i, ret = 0;
> + u32 id;
> +
> + for (i = 0; i < NUM_POWER_ENTITIES; i++) {
> + id = on ? power_on_seq[i] : power_off_seq[i];
> + entity = find_pipeline_entity(imxmd, graph, start_entity, id);
> + if (!entity)
> + continue;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_subdev_call(sd, core, s_power, on);
> + if (ret && ret != -ENOIOCTLCMD)
> + break;
> + }
> +
> + return (ret && ret != -ENOIOCTLCMD) ? ret : 0;
> +}
> +EXPORT_SYMBOL_GPL(imx_media_pipeline_set_power);
This should really be handled by v4l2_pipeline_pm_use.
> +/*
> + * Inherit the v4l2 controls from all entities in a pipeline
> + * to the given video device.
> + * Must be called with mdev->graph_mutex held.
> + */
> +int imx_media_inherit_controls(struct imx_media_dev *imxmd,
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + struct media_entity_graph graph;
> + struct media_entity *entity;
> + struct v4l2_subdev *sd;
> + int ret;
> +
> + ret = media_entity_graph_walk_init(&graph, &imxmd->md);
> + if (ret)
> + return ret;
> +
> + media_entity_graph_walk_start(&graph, start_entity);
> +
> + while ((entity = media_entity_graph_walk_next(&graph))) {
> + if (is_media_entity_v4l2_video_device(entity))
> + continue;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + dev_dbg(imxmd->dev, "%s: adding controls from %s\n",
> + __func__, sd->name);
> +
> + ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
> + sd->ctrl_handler,
> + NULL);
> + if (ret)
> + break;
> + }
> +
> + media_entity_graph_walk_cleanup(&graph);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(imx_media_inherit_controls);
> +
> +MODULE_DESCRIPTION("i.MX5/6 v4l2 media controller driver");
> +MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
> new file mode 100644
> index 0000000..357654d
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-dev.c
This file is full of code that should live in the v4l2 core.
[...]
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-internal-sd.c
[...]
> +int imx_media_add_internal_subdevs(struct imx_media_dev *imxmd,
> + struct imx_media_subdev *csi[4])
> +{
> + int ret;
> +
> + /* there must be at least one CSI in first IPU */
Why?
> + if (!(csi[0] || csi[1]))
> + return -EINVAL;
> +
> + ret = add_ipu_internal_subdevs(imxmd, csi[0], csi[1], 0);
> + if (ret)
> + return ret;
> +
> + if (csi[2] || csi[3])
> + ret = add_ipu_internal_subdevs(imxmd, csi[2], csi[3], 1);
> +
> + return ret;
> +}
> diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c
> new file mode 100644
> index 0000000..a939c34
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-of.c
> @@ -0,0 +1,289 @@
> +/*
> + * Media driver for Freescale i.MX5/6 SOC
> + *
> + * Open Firmware parsing.
> + *
> + * Copyright (c) 2016 Mentor Graphics Inc.
> + *
> + * 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.
> + */
> +#include <linux/of_platform.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <video/imx-ipu-v3.h>
> +#include "imx-media.h"
> +
> +static int of_add_pad_link(struct imx_media_dev *imxmd,
> + struct imx_media_pad *pad,
> + struct device_node *local_sd_node,
> + struct device_node *remote_sd_node,
> + int local_pad, int remote_pad)
> +{
> + dev_dbg(imxmd->dev, "%s: adding %s:%d -> %s:%d\n", __func__,
> + local_sd_node->name, local_pad,
> + remote_sd_node->name, remote_pad);
> +
> + return imx_media_add_pad_link(imxmd, pad, remote_sd_node, NULL,
> + local_pad, remote_pad);
> +}
> +
> +/* parse inputs property from a sensor node */
> +static void of_parse_sensor_inputs(struct imx_media_dev *imxmd,
> + struct imx_media_subdev *sensor,
> + struct device_node *sensor_np)
> +{
> + struct imx_media_sensor_input *sinput = &sensor->input;
> + int ret, i;
> +
> + for (i = 0; i < IMX_MEDIA_MAX_SENSOR_INPUTS; i++) {
> + const char *input_name;
> + u32 val;
> +
> + ret = of_property_read_u32_index(sensor_np, "inputs", i, &val);
> + if (ret)
> + break;
> +
> + sinput->value[i] = val;
> +
> + ret = of_property_read_string_index(sensor_np, "input-names",
> + i, &input_name);
> + /*
> + * if input-names not provided, they will be set using
> + * the subdev name once the sensor is known during
> + * async bind
> + */
> + if (!ret)
> + strncpy(sinput->name[i], input_name,
> + sizeof(sinput->name[i]));
> + }
> +
> + sinput->num = i;
> +
> + /* if no inputs provided just assume a single input */
> + if (sinput->num == 0)
> + sinput->num = 1;
> +}
This should be parsed by the sensor driver, not imx-media.
> +static void of_parse_sensor(struct imx_media_dev *imxmd,
> + struct imx_media_subdev *sensor,
> + struct device_node *sensor_np)
> +{
> + struct device_node *endpoint;
> +
> + of_parse_sensor_inputs(imxmd, sensor, sensor_np);
> +
> + endpoint = of_graph_get_next_endpoint(sensor_np, NULL);
> + if (endpoint) {
> + v4l2_of_parse_endpoint(endpoint, &sensor->sensor_ep);
> + of_node_put(endpoint);
> + }
> +}
> +
> +static int of_get_port_count(const struct device_node *np)
> +{
> + struct device_node *child;
> + int num = 0;
> +
> + /* if this node is itself a port, return 1 */
> + if (of_node_cmp(np->name, "port") == 0)
> + return 1;
> +
> + for_each_child_of_node(np, child)
> + if (of_node_cmp(child->name, "port") == 0)
> + num++;
> +
> + return num;
> +}
If this is extended to handle the ports subnode properly, it could be
moved into drivers/of/base.c.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 15:21 UTC (permalink / raw)
To: Matthias Brugger
Cc: Guochun Mao, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <d7b866ad-5b2f-62d3-3aa3-6fa42803d625@gmail.com>
On Fri, 13 Jan 2017 16:12:20 +0100
Matthias Brugger <matthias.bgg@gmail.com> wrote:
> On 13/01/17 15:17, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 15:13:29 +0800
> > Guochun Mao <guochun.mao@mediatek.com> wrote:
> >
> >> Add Mediatek nor flash node.
> >>
> >> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> >> ---
> >> 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";
> >
> > Why define both here? Is "mediatek,mt8173-nor" really providing a
> > subset of the features supported by "mediatek,mt2701-nor"?
> >
>
> I think even if the ip block is the same, we should provide both
> bindings, just in case in the future we find out that mt2701 has some
> hidden bug, feature or bug-feature. This way even if we update the
> driver, we stay compatible with older device tree blobs in the wild.
I'm fine with this approach, but in this case, defining both is wrong.
>
> We can drop the mt2701-nor in the bindings definition if you want.
Yes, please.
>
> Regards,
> Matthias
>
> >> + 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>;
> >
^ permalink raw reply
* Re: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Linus Walleij @ 2017-01-13 15:22 UTC (permalink / raw)
To: Jacky Bai
Cc: Shawn Guo, Michael Turquette, Stephen Boyd, Rob Herring,
Mark Rutland, Sascha Hauer, Fabio Estevam, Daniel Lezcano,
Thomas Gleixner, Philipp Zabel, linux-clk,
devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, jacky.baip@gmail.com
In-Reply-To: <AM3PR04MB530A88C5C0E7C6AD2C59B9E87790@AM3PR04MB530.eurprd04.prod.outlook.com>
On Thu, Jan 12, 2017 at 3:57 AM, Jacky Bai <ping.bai@nxp.com> wrote:
> Another thing is that we can use a pins-tool program developed by NXP to
> generate the pinctrl configuration code that can be used directly in dts. This
> tiny program can avoid pin function conflict. As on i.MX, there are so may pins,
> each pin can be used for up 8 function. Configuring the pins is a time-consuming
> work. This tools is very useful for customer to generate the dts code.
I understand, but every silicon vendor has such a tool, all are different,
proprietary and unfriendly to programmers and open source developers, who
need to understand how the hardware is working without magic tools
and secret data sheets to fix bugs.
For the people working with maintaining the code it is paramount that
DTS files are self-descriptive.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: core: Fix regression caused by delayed work for hogs
From: Linus Walleij @ 2017-01-13 15:26 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP, Gary Bisson
In-Reply-To: <20170111221334.26194-1-tony@atomide.com>
On Wed, Jan 11, 2017 at 11:13 PM, Tony Lindgren <tony@atomide.com> wrote:
> Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
> regression at least with sh-pfc that is also a GPIO controller as
> noted by Geert Uytterhoeven <geert@linux-m68k.org>.
>
> As the original pinctrl_register() has issues calling pin controller
> driver functions early before the controller has finished registering,
> we can't just revert commit df61b366af26. That would break the drivers
> using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
>
> So let's fix the issue with the following steps as a single patch:
>
> 1. Revert the late_init parts of commit df61b366af26.
>
> The late_init clearly won't work and we have to just give up
> on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
> GENERIC_PINMUX_FUNCTIONS.
>
> 2. Split pinctrl_register() into two parts
>
> By splitting pinctrl_register() into pinctrl_init_controller()
> and pinctrl_create_and_start() we have better control over when
> it's safe to call pinctrl_create().
>
> 3. Introduce a new pinctrl_register_and_init() function
>
> As suggested by Linus Walleij <linus.walleij@linaro.org>, we
> can just introduce a new function for the controllers that need
> pinctrl_create() called later.
>
> 4. Convert the four known problem cases to use new function
>
> Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
> to use the new function to fix the issues. The rest of the drivers
> can be converted later. Let's also update Documentation/pinctrl.txt
> accordingly because of the known issues with pinctrl_register().
>
> Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Gary Bisson <gary.bisson@boundarydevices.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
OK patch applied.
Yours,
Linus Walleij
^ 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