* [PATCH net 1/2] dt-bindings: net: mediatek: add condition to property mediatek,pctl
From: David Miller @ 2017-12-26 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e366efc29985d3292c8a1afb1389b5eac57c9037.1513762066.git.sean.wang@mediatek.com>
From: <sean.wang@mediatek.com>
Date: Wed, 20 Dec 2017 17:47:05 +0800
> From: Sean Wang <sean.wang@mediatek.com>
>
> The property "mediatek,pctl" is only required for SoCs such as MT2701 and
> MT7623, so adding a few words for stating the condition.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Applied to net-next.
^ permalink raw reply
* [PATCH net 2/2] net: mediatek: remove superfluous pin setup for MT7622 SoC
From: David Miller @ 2017-12-26 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3bd43a5337df719e791bc9902135a0916a951ff.1513762066.git.sean.wang@mediatek.com>
From: <sean.wang@mediatek.com>
Date: Wed, 20 Dec 2017 17:47:06 +0800
> From: Sean Wang <sean.wang@mediatek.com>
>
> Remove superfluous pin setup to get out of accessing invalid I/O pin
> registers because the way for pin configuring tends to be different from
> various SoCs and thus it should be better being managed and controlled by
> the pinctrl driver which MT7622 already can support.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Applied to net-next.
^ permalink raw reply
* [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series
From: Rob Herring @ 2017-12-26 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222105642.GD18255@piout.net>
On Fri, Dec 22, 2017 at 4:56 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> + Philippe
>
> On 22/12/2017 at 11:43:33 +0100, Andreas F?rber wrote:
>> >> I'll change it for v3 of this patch however it will end up like this:
>> >> //SPDX-License...
>> >
>> > That should be /* SPDX-License */, // is for c files.
>>
>> Got any reference for that? Since we're using the C preprocessor before
>> feeding them to dtc, we can use the same // style for both, builds fine.
>>
>> Only for my private DT overlay files that I use directly with dtc I
>> couldn't adopt that style.
We are well past the point of being able to build most dts files with just dtc.
> The doc states:
>
> If a specific tool cannot handle the standard comment style, then the
> appropriate comment mechanism which the tool accepts shall be used. This
> is the reason for having the "/\* \*/" style comment in C header
> files.
>
> I interpreted that as dtc doesn't handle // comments, use /**/
It's been so long, I'd forgotten that. Perhaps we should fix dtc to
handle // comments.
>
> But I agree it also states:
> .dts{i}: // SPDX-License-Identifier: <SPDX License Expression>
Or we could still change this. The guidelines aren't merged yet.
Rob
^ permalink raw reply
* [PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Rob Herring @ 2017-12-26 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95F51F4B902CAC40AF459205F6322F01B7FDFECC3D@BMK019S01.emtrion.local>
On Fri, Dec 22, 2017 at 4:43 AM, T?rk, Jan <Jan.Tuerk@emtrion.de> wrote:
>> Von: Rob Herring [mailto:robh at kernel.org]
>> Gesendet: Freitag, 22. Dezember 2017 00:00
>> Betreff: Re: [PATCH v2 1/5] drm/panel: Add support for the EDT
>> ETM0700G0BDH6
>>
>> On Wed, Dec 20, 2017 at 02:47:01PM +0100, jan.tuerk at emtrion.com wrote:
>> > From: Jan Tuerk <jan.tuerk@emtrion.com>
>> >
>> > The Emerging Display Technology ETM0700G0BDH6 is exactly the same
>> > display as the ETM0700G0DH6, exept the pixelclock polarity. Therefore
>> > re-use the ETM0700G0DH6 modes. It is used by default on emtrion Avari
>> > based development kits.
>>
>> As I asked on v1, why not document the panels together in a single doc?
>
> As denoted in the cover letter:
I generally don't read cover letters...
>>The documentation for the EDT display is kept as an extra file currently,
>>as it is done by the most displays in the documentation. Also a new
>>new Variant of the EDT already arrived. So merging their documentations
>>should be discussed separately.
You mean a 3rd variant?
> I think it will be even a little tricky to find a matching filename for both versions,
> as the recent ones adding an extra character in the description. Are you expecting sth.
> like edt,etm0700series.txt?
Yeah, or edt,etm0700g0.txt.
Rob
^ permalink raw reply
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Rob Herring @ 2017-12-26 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <864b6cfd-d3eb-d876-82e2-ebc79c5a6956@codeaurora.org>
On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R <sricharan@codeaurora.org> wrote:
> Hi Rob,
>
> On 12/21/2017 2:48 AM, Rob Herring wrote:
>> On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
>>> Hi Viresh,
>>>
>>> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
>>>> On 19-12-17, 21:25, Sricharan R wrote:
>>>>> + cpu at 0 {
>>>>> + compatible = "qcom,krait";
>>>>> + enable-method = "qcom,kpss-acc-v1";
>>>>> + device_type = "cpu";
>>>>> + reg = <0>;
>>>>> + qcom,acc = <&acc0>;
>>>>> + qcom,saw = <&saw0>;
>>>>> + clocks = <&kraitcc 0>;
>>>>> + clock-names = "cpu";
>>>>> + cpu-supply = <&smb208_s2a>;
>>>>> + operating-points-v2 = <&cpu_opp_table>;
>>>>> + };
>>>>> +
>>>>> + qcom,pvs {
>>>>> + qcom,pvs-format-a;
>>>>> + };
>>>>
>>>> Not sure what Rob is going to say on that :)
>>>>
>>>
>>> Yes. Would be good to know the best way.
>>
>> Seems like this should be a property of an efuse node either implied by
>> the compatible or a separate property. What determines format A vs. B?
>>
>
> Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc.
> So this property (details like bitfields and register offsets that it represents)
> can be put soc specific and nvmem apis can be used to read
> the registers. Does something like below look ok ?
>
> qcom,pvs {
> compatible = "qcom,pvs-ipq8064";
> nvmem-cells = <&pvs_efuse>;
> }
Why do you need this node? It doesn't look like it corresponds to a
h/w block. It looks like you are just creating it to instantiate a
driver.
> qfprom: qfprom at 700000 {
> compatible = "qcom,qfprom";
Either this or...
> reg = <0x00700000 0x1000>;
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> pvs_efuse: pvs {
a compatible here should be specific enough so the OS can know what
the bits are.
> reg = <0xc0 0x8>;
> };
> };
^ permalink raw reply
* [PATCH 10/11 v2] ARM: s3c24xx/s3c64xx: constify gpio_led
From: Krzysztof Kozlowski @ 2017-12-26 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <adb77ba31b66d391a49a12434dfe7811e8a8ba0f.1514267721.git.arvind.yadav.cs@gmail.com>
On Tue, Dec 26, 2017 at 7:37 AM, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Please write one-sentence long, easy to understand message describing
the change.
Best regards,
Krzysztof
> ---
> changes in v2:
> The GPIO LED driver can be built as a module, it can
> be loaded after the init sections have gone away.
> So removed '__initconst'.
>
> arch/arm/mach-s3c24xx/mach-h1940.c | 2 +-
> arch/arm/mach-s3c24xx/mach-rx1950.c | 2 +-
> arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
> arch/arm/mach-s3c64xx/mach-smartq5.c | 2 +-
> arch/arm/mach-s3c64xx/mach-smartq7.c | 2 +-
> arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c b/arch/arm/mach-s3c24xx/mach-h1940.c
> index 7ed7861..6a3e0e6 100644
> --- a/arch/arm/mach-s3c24xx/mach-h1940.c
> +++ b/arch/arm/mach-s3c24xx/mach-h1940.c
> @@ -413,7 +413,7 @@ int h1940_led_blink_set(struct gpio_desc *desc, int state,
> }
> EXPORT_SYMBOL(h1940_led_blink_set);
>
> -static struct gpio_led h1940_leds_desc[] = {
> +static const struct gpio_led h1940_leds_desc[] = {
> {
> .name = "Green",
> .default_trigger = "main-battery-full",
> diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
> index e86ad6a..97bb6a5 100644
> --- a/arch/arm/mach-s3c24xx/mach-rx1950.c
> +++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
> @@ -295,7 +295,7 @@ static int rx1950_led_blink_set(struct gpio_desc *desc, int state,
> return 0;
> }
>
> -static struct gpio_led rx1950_leds_desc[] = {
> +static const struct gpio_led rx1950_leds_desc[] = {
> {
> .name = "Green",
> .default_trigger = "main-battery-full",
> diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
> index 59b5531..f8d644f 100644
> --- a/arch/arm/mach-s3c64xx/mach-hmt.c
> +++ b/arch/arm/mach-s3c64xx/mach-hmt.c
> @@ -207,7 +207,7 @@ static struct s3c2410_platform_nand hmt_nand_info = {
> .ecc_mode = NAND_ECC_SOFT,
> };
>
> -static struct gpio_led hmt_leds[] = {
> +static const struct gpio_led hmt_leds[] = {
> { /* left function keys */
> .name = "left:blue",
> .gpio = S3C64XX_GPO(12),
> diff --git a/arch/arm/mach-s3c64xx/mach-smartq5.c b/arch/arm/mach-s3c64xx/mach-smartq5.c
> index 0972b6c..5a7cd8f 100644
> --- a/arch/arm/mach-s3c64xx/mach-smartq5.c
> +++ b/arch/arm/mach-s3c64xx/mach-smartq5.c
> @@ -35,7 +35,7 @@
> #include "common.h"
> #include "mach-smartq.h"
>
> -static struct gpio_led smartq5_leds[] = {
> +static const struct gpio_led smartq5_leds[] = {
> {
> .name = "smartq5:green",
> .active_low = 1,
> diff --git a/arch/arm/mach-s3c64xx/mach-smartq7.c b/arch/arm/mach-s3c64xx/mach-smartq7.c
> index 51ac1c6..9de9fc2 100644
> --- a/arch/arm/mach-s3c64xx/mach-smartq7.c
> +++ b/arch/arm/mach-s3c64xx/mach-smartq7.c
> @@ -35,7 +35,7 @@
> #include "common.h"
> #include "mach-smartq.h"
>
> -static struct gpio_led smartq7_leds[] = {
> +static const struct gpio_led smartq7_leds[] = {
> {
> .name = "smartq7:red",
> .active_low = 1,
> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-s3c64xx/mach-smdk6410.c
> index 92ec8c3..be9d98f 100644
> --- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
> @@ -497,7 +497,7 @@ static struct wm8350_platform_data __initdata smdk6410_wm8350_pdata = {
> #endif
>
> #ifdef CONFIG_SMDK6410_WM1192_EV1
> -static struct gpio_led wm1192_pmic_leds[] = {
> +static const struct gpio_led wm1192_pmic_leds[] = {
> {
> .name = "PMIC:red:power",
> .gpio = GPIO_BOARD_START + 3,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-hummingboard2: Remove leading zero in unit address
From: Fabio Estevam @ 2017-12-26 17:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Remove the leading zero from unit address to fix the following build
warning with W=1:
arch/arm/boot/dts/imx6dl-hummingboard2.dtb: Warning (unit_address_format): Node /soc/aips-bus at 2100000/i2c at 21a0000/codec at 0a unit name should not have leading 0s
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
index 117c4da..dffbc92 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi
@@ -188,7 +188,7 @@
reg = <0x68>;
};
- sgtl5000: codec at 0a {
+ sgtl5000: codec at a {
clocks = <&clks IMX6QDL_CLK_CKO>;
compatible = "fsl,sgtl5000";
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v7 2/2] net: ethernet: socionext: add AVE ethernet driver
From: David Miller @ 2017-12-26 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513854776-4149-3-git-send-email-hayashi.kunihiko@socionext.com>
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date: Thu, 21 Dec 2017 20:12:56 +0900
> + writel(AVE_TXDC_ADDR_START
> + | (((priv->tx.ndesc * priv->desc_size) << 16) & AVE_TXDC_SIZE),
> + priv->base + AVE_TXDC);
...
> + writel(AVE_RXDC0_ADDR_START
> + | (((priv->rx.ndesc * priv->desc_size) << 16) & AVE_RXDC0_SIZE),
> + priv->base + AVE_RXDC0);
...
> + cmdsts = AVE_STS_OWN | AVE_STS_1ST | AVE_STS_LAST
> + | (skb->len & AVE_STS_PKTLEN_TX_MASK);
Please do not begin lines with operators, instead put them at the end
of the previous line, f.e.:
cmdsts = AVE_STS_OWN | AVE_STS_1ST | AVE_STS_LAST |
(skb->len & AVE_STS_PKTLEN_TX_MASK);
Thank you.
^ permalink raw reply
* [PATCH] ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
From: Fabio Estevam @ 2017-12-26 18:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Commit 915fbe59cbf2fe6 ("ARM: dts: imx: Add missing #phy-cells to
usb-nop-xceiv") missed to update imx51-zii-rdu1.dts probably due to a
merge timing issue, so add #phy-cells here too.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index 70fdcdd..5306b78 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -271,6 +271,7 @@
clock-names = "main_clk";
reset-gpios = <&gpio4 8 GPIO_ACTIVE_LOW>;
vcc-supply = <&vusb_reg>;
+ #phy-cells = <0>;
};
usbh2phy: usbphy2 {
@@ -281,6 +282,7 @@
clock-names = "main_clk";
reset-gpios = <&gpio4 7 GPIO_ACTIVE_LOW>;
vcc-supply = <&vusb_reg>;
+ #phy-cells = <0>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx: Add memory node unit name
From: Fabio Estevam @ 2017-12-26 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM4PwSVzVn3=wWpFohw2q23Oiwp1FimCkdHPq=BfG-QzuuPtfQ@mail.gmail.com>
Hi Rob,
On Thu, Dec 21, 2017 at 12:26 PM, Marco Franchi <marcofrk@gmail.com> wrote:
> Hi Lothar,
>
> 2017-12-21 6:07 GMT-02:00 Lothar Wa?mann <LW@karo-electronics.de>:
>> Hi,
>>
>> On Wed, 6 Dec 2017 13:59:49 -0200 Marco Franchi wrote:
>>> Fix the following warnings from dtc by adding the unit name to memory
>>> nodes:
>>>
>>> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>>>
>>> Converted using the following command:
>>>
>>> perl -p0777i -e 's/memory \{\n\t\treg = \<0x+([0-9a-f])/memory\@$1$\0000000 \{\n\t\treg = <0x$1/m' `find ./arch/arm/boot/dts -name "imx*"`
>>>
>>> The files below were manually fixed:
>>> -imx1-ads.dts
>>> -imx1-apf9328.dts
>>>
>> The imx*.dtsi files all have this:
>> | memory { device_type = "memory"; reg = <0 0>; };
>> Thus you will end up with a 'memory' node with a reg = <0 0> entry and
>> an additional 'memory at ...' node with the correct 'reg' values.
>
> You are right. The .dtb files were composed by two different memory nodes.
> Do you have some recommendation to take off this specific warning?
Currently the only dtc warnings we have with imx_v6_v7_defconfig are:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name
What is the recommended way to fix these warnings?
Thanks
^ permalink raw reply
* [PATCH] pinctrl: samsung: Add SPDX license identifiers
From: Krzysztof Kozlowski @ 2017-12-26 18:09 UTC (permalink / raw)
To: linux-arm-kernel
Replace GPL license statements with SPDX GPL-2.0+ license identifiers.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/pinctrl/samsung/Kconfig | 1 +
drivers/pinctrl/samsung/pinctrl-exynos-arm.c | 33 ++++++++++-------------
drivers/pinctrl/samsung/pinctrl-exynos-arm64.c | 33 ++++++++++-------------
drivers/pinctrl/samsung/pinctrl-exynos.c | 33 ++++++++++-------------
drivers/pinctrl/samsung/pinctrl-exynos.h | 6 +----
drivers/pinctrl/samsung/pinctrl-exynos5440.c | 21 ++++++---------
drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 23 +++++++---------
drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 27 ++++++++-----------
drivers/pinctrl/samsung/pinctrl-samsung.c | 37 +++++++++++---------------
drivers/pinctrl/samsung/pinctrl-samsung.h | 6 +----
10 files changed, 89 insertions(+), 131 deletions(-)
diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
index ecfb90059eeb..11b5eeb14c4a 100644
--- a/drivers/pinctrl/samsung/Kconfig
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
#
# Samsung Pin control drivers
#
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
index 071084d3ee9c..c32399faff57 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm.c
@@ -1,22 +1,17 @@
-/*
- * Exynos specific support for Samsung pinctrl/gpiolib driver with eint support.
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- * Copyright (c) 2012 Linaro Ltd
- * http://www.linaro.org
- *
- * Author: Thomas Abraham <thomas.ab@samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This file contains the Samsung Exynos specific information required by the
- * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
- * external gpio and wakeup interrupt support.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Exynos specific support for Samsung pinctrl/gpiolib driver with eint support.
+//
+// Copyright (c) 2012 Samsung Electronics Co., Ltd.
+// http://www.samsung.com
+// Copyright (c) 2012 Linaro Ltd
+// http://www.linaro.org
+//
+// Author: Thomas Abraham <thomas.ab@samsung.com>
+//
+// This file contains the Samsung Exynos specific information required by the
+// the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+// external gpio and wakeup interrupt support.
#include <linux/device.h>
#include <linux/of_address.h>
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index 08e9fdb58fd2..fc8f7833bec0 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -1,22 +1,17 @@
-/*
- * Exynos ARMv8 specific support for Samsung pinctrl/gpiolib driver
- * with eint support.
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- * Copyright (c) 2012 Linaro Ltd
- * http://www.linaro.org
- * Copyright (c) 2017 Krzysztof Kozlowski <krzk@kernel.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This file contains the Samsung Exynos specific information required by the
- * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
- * external gpio and wakeup interrupt support.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Exynos ARMv8 specific support for Samsung pinctrl/gpiolib driver
+// with eint support.
+//
+// Copyright (c) 2012 Samsung Electronics Co., Ltd.
+// http://www.samsung.com
+// Copyright (c) 2012 Linaro Ltd
+// http://www.linaro.org
+// Copyright (c) 2017 Krzysztof Kozlowski <krzk@kernel.org>
+//
+// This file contains the Samsung Exynos specific information required by the
+// the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+// external gpio and wakeup interrupt support.
#include <linux/slab.h>
#include <linux/soc/samsung/exynos-regs-pmu.h>
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index c8d0de7ea160..0a625a64ff5d 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1,22 +1,17 @@
-/*
- * Exynos specific support for Samsung pinctrl/gpiolib driver with eint support.
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- * Copyright (c) 2012 Linaro Ltd
- * http://www.linaro.org
- *
- * Author: Thomas Abraham <thomas.ab@samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This file contains the Samsung Exynos specific information required by the
- * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
- * external gpio and wakeup interrupt support.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Exynos specific support for Samsung pinctrl/gpiolib driver with eint support.
+//
+// Copyright (c) 2012 Samsung Electronics Co., Ltd.
+// http://www.samsung.com
+// Copyright (c) 2012 Linaro Ltd
+// http://www.linaro.org
+//
+// Author: Thomas Abraham <thomas.ab@samsung.com>
+//
+// This file contains the Samsung Exynos specific information required by the
+// the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+// external gpio and wakeup interrupt support.
#include <linux/device.h>
#include <linux/interrupt.h>
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.h b/drivers/pinctrl/samsung/pinctrl-exynos.h
index 7639b926c5c1..abd43aa7eb0d 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.h
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
/*
* Exynos specific definitions for Samsung pinctrl and gpiolib driver.
*
@@ -10,11 +11,6 @@
* pinctrl/gpiolib interface drivers.
*
* Author: Thomas Abraham <thomas.ab@samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
*/
#ifndef __PINCTRL_SAMSUNG_EXYNOS_H
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
index 32a3a9fd65c4..3d8d5e812839 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
@@ -1,16 +1,11 @@
-/*
- * pin-controller/pin-mux/pin-config/gpio-driver for Samsung's EXYNOS5440 SoC.
- *
- * Author: Thomas Abraham <thomas.ab@samsung.com>
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// pin-controller/pin-mux/pin-config/gpio-driver for Samsung's EXYNOS5440 SoC.
+//
+// Author: Thomas Abraham <thomas.ab@samsung.com>
+//
+// Copyright (c) 2012 Samsung Electronics Co., Ltd.
+// http://www.samsung.com
#include <linux/init.h>
#include <linux/platform_device.h>
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index edf27264b603..10187cb0e9b9 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -1,17 +1,12 @@
-/*
- * S3C24XX specific support for Samsung pinctrl/gpiolib driver.
- *
- * Copyright (c) 2013 Heiko Stuebner <heiko@sntech.de>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This file contains the SamsungS3C24XX specific information required by the
- * Samsung pinctrl/gpiolib driver. It also includes the implementation of
- * external gpio and wakeup interrupt support.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// S3C24XX specific support for Samsung pinctrl/gpiolib driver.
+//
+// Copyright (c) 2013 Heiko Stuebner <heiko@sntech.de>
+//
+// This file contains the SamsungS3C24XX specific information required by the
+// Samsung pinctrl/gpiolib driver. It also includes the implementation of
+// external gpio and wakeup interrupt support.
#include <linux/init.h>
#include <linux/device.h>
diff --git a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
index e63663b32907..679628ac4b31 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c64xx.c
@@ -1,19 +1,14 @@
-/*
- * S3C64xx specific support for pinctrl-samsung driver.
- *
- * Copyright (c) 2013 Tomasz Figa <tomasz.figa@gmail.com>
- *
- * Based on pinctrl-exynos.c, please see the file for original copyrights.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This file contains the Samsung S3C64xx specific information required by the
- * the Samsung pinctrl/gpiolib driver. It also includes the implementation of
- * external gpio and wakeup interrupt support.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// S3C64xx specific support for pinctrl-samsung driver.
+//
+// Copyright (c) 2013 Tomasz Figa <tomasz.figa@gmail.com>
+//
+// Based on pinctrl-exynos.c, please see the file for original copyrights.
+//
+// This file contains the Samsung S3C64xx specific information required by the
+// the Samsung pinctrl/gpiolib driver. It also includes the implementation of
+// external gpio and wakeup interrupt support.
#include <linux/init.h>
#include <linux/device.h>
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index e04f7fe0a65d..da58e4554137 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1,24 +1,19 @@
-/*
- * pin-controller/pin-mux/pin-config/gpio-driver for Samsung's SoC's.
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- * Copyright (c) 2012 Linaro Ltd
- * http://www.linaro.org
- *
- * Author: Thomas Abraham <thomas.ab@samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This driver implements the Samsung pinctrl driver. It supports setting up of
- * pinmux and pinconf configurations. The gpiolib interface is also included.
- * External interrupt (gpio and wakeup) support are not included in this driver
- * but provides extensions to which platform specific implementation of the gpio
- * and wakeup interrupts can be hooked to.
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// pin-controller/pin-mux/pin-config/gpio-driver for Samsung's SoC's.
+//
+// Copyright (c) 2012 Samsung Electronics Co., Ltd.
+// http://www.samsung.com
+// Copyright (c) 2012 Linaro Ltd
+// http://www.linaro.org
+//
+// Author: Thomas Abraham <thomas.ab@samsung.com>
+//
+// This driver implements the Samsung pinctrl driver. It supports setting up of
+// pinmux and pinconf configurations. The gpiolib interface is also included.
+// External interrupt (gpio and wakeup) support are not included in this driver
+// but provides extensions to which platform specific implementation of the gpio
+// and wakeup interrupts can be hooked to.
#include <linux/init.h>
#include <linux/platform_device.h>
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 9af07af6cad6..e204f609823b 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
/*
* pin-controller/pin-mux/pin-config/gpio-driver for Samsung's SoC's.
*
@@ -7,11 +8,6 @@
* http://www.linaro.org
*
* Author: Thomas Abraham <thomas.ab@samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
*/
#ifndef __PINCTRL_SAMSUNG_H
--
2.7.4
^ permalink raw reply related
* [PATCH 10/11 v2] ARM: s3c24xx/s3c64xx: constify gpio_led
From: arvindY @ 2017-12-26 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPdz+SZVxJ2y_aWdZsCjujhPAqMa3O-bqenOnk-iygow_w@mail.gmail.com>
Hi,
On Tuesday 26 December 2017 11:12 PM, Krzysztof Kozlowski wrote:
> On Tue, Dec 26, 2017 at 7:37 AM, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Please write one-sentence long, easy to understand message describing
> the change.
>
> Best regards,
> Krzysztof
Thanks for review comment. I will add.
>
>> ---
>> changes in v2:
>> The GPIO LED driver can be built as a module, it can
>> be loaded after the init sections have gone away.
>> So removed '__initconst'.
>>
>> arch/arm/mach-s3c24xx/mach-h1940.c | 2 +-
>> arch/arm/mach-s3c24xx/mach-rx1950.c | 2 +-
>> arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
>> arch/arm/mach-s3c64xx/mach-smartq5.c | 2 +-
>> arch/arm/mach-s3c64xx/mach-smartq7.c | 2 +-
>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
>> 6 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c b/arch/arm/mach-s3c24xx/mach-h1940.c
>> index 7ed7861..6a3e0e6 100644
>> --- a/arch/arm/mach-s3c24xx/mach-h1940.c
>> +++ b/arch/arm/mach-s3c24xx/mach-h1940.c
>> @@ -413,7 +413,7 @@ int h1940_led_blink_set(struct gpio_desc *desc, int state,
>> }
>> EXPORT_SYMBOL(h1940_led_blink_set);
>>
>> -static struct gpio_led h1940_leds_desc[] = {
>> +static const struct gpio_led h1940_leds_desc[] = {
>> {
>> .name = "Green",
>> .default_trigger = "main-battery-full",
>> diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
>> index e86ad6a..97bb6a5 100644
>> --- a/arch/arm/mach-s3c24xx/mach-rx1950.c
>> +++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
>> @@ -295,7 +295,7 @@ static int rx1950_led_blink_set(struct gpio_desc *desc, int state,
>> return 0;
>> }
>>
>> -static struct gpio_led rx1950_leds_desc[] = {
>> +static const struct gpio_led rx1950_leds_desc[] = {
>> {
>> .name = "Green",
>> .default_trigger = "main-battery-full",
>> diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
>> index 59b5531..f8d644f 100644
>> --- a/arch/arm/mach-s3c64xx/mach-hmt.c
>> +++ b/arch/arm/mach-s3c64xx/mach-hmt.c
>> @@ -207,7 +207,7 @@ static struct s3c2410_platform_nand hmt_nand_info = {
>> .ecc_mode = NAND_ECC_SOFT,
>> };
>>
>> -static struct gpio_led hmt_leds[] = {
>> +static const struct gpio_led hmt_leds[] = {
>> { /* left function keys */
>> .name = "left:blue",
>> .gpio = S3C64XX_GPO(12),
>> diff --git a/arch/arm/mach-s3c64xx/mach-smartq5.c b/arch/arm/mach-s3c64xx/mach-smartq5.c
>> index 0972b6c..5a7cd8f 100644
>> --- a/arch/arm/mach-s3c64xx/mach-smartq5.c
>> +++ b/arch/arm/mach-s3c64xx/mach-smartq5.c
>> @@ -35,7 +35,7 @@
>> #include "common.h"
>> #include "mach-smartq.h"
>>
>> -static struct gpio_led smartq5_leds[] = {
>> +static const struct gpio_led smartq5_leds[] = {
>> {
>> .name = "smartq5:green",
>> .active_low = 1,
>> diff --git a/arch/arm/mach-s3c64xx/mach-smartq7.c b/arch/arm/mach-s3c64xx/mach-smartq7.c
>> index 51ac1c6..9de9fc2 100644
>> --- a/arch/arm/mach-s3c64xx/mach-smartq7.c
>> +++ b/arch/arm/mach-s3c64xx/mach-smartq7.c
>> @@ -35,7 +35,7 @@
>> #include "common.h"
>> #include "mach-smartq.h"
>>
>> -static struct gpio_led smartq7_leds[] = {
>> +static const struct gpio_led smartq7_leds[] = {
>> {
>> .name = "smartq7:red",
>> .active_low = 1,
>> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-s3c64xx/mach-smdk6410.c
>> index 92ec8c3..be9d98f 100644
>> --- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
>> +++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
>> @@ -497,7 +497,7 @@ static struct wm8350_platform_data __initdata smdk6410_wm8350_pdata = {
>> #endif
>>
>> #ifdef CONFIG_SMDK6410_WM1192_EV1
>> -static struct gpio_led wm1192_pmic_leds[] = {
>> +static const struct gpio_led wm1192_pmic_leds[] = {
>> {
>> .name = "PMIC:red:power",
>> .gpio = GPIO_BOARD_START + 3,
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH v3 01/11] dt-bindings: fix the binding of Allwinner DE2 CCU of A83T and H3
From: Rob Herring @ 2017-12-26 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222122243.25735-2-icenowy@aosc.io>
On Fri, Dec 22, 2017 at 6:22 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The DE2 CCU is different on A83T and H3 -- the parent of the clocks on
> A83T is PLL_DE but on H3 it's the DE module clock. This is not noticed
> when I develop the DE2 CCU driver.
>
> Fix the binding by using different compatibles for A83T and H3, adding
> notes for the PLL_DE usage on A83T, and change the binding example's
> compatible from A83T to H3 (as it specifies the DE module clock).
>
> Fixes: ed74f8a8a679 ("dt-bindings: add binding for the Allwinner DE2 CCU")
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Documentation/devicetree/bindings/clock/sun8i-de2.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Please add acks when posting new versions.
Rob
^ permalink raw reply
* [arm:phy 15/66] drivers/net/dsa/mv88e6xxx/global2.h:449: multiple definition of `mv88e6xxx_g2_scratch_gpio_set_ext_smi'
From: kbuild test robot @ 2017-12-26 19:39 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git phy
head: 73c2c610e10e5b83922c0be529c000a9506d0630
commit: 4520555b93f27772482e7e0ae714641633c8bf16 [15/66] net: dsa: mv88e6xxx: Enable external MDIO bus
config: x86_64-randconfig-s1-12270141 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 4520555b93f27772482e7e0ae714641633c8bf16
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/dsa/mv88e6xxx/serdes.o: In function `mv88e6xxx_g2_scratch_gpio_set_ext_smi':
>> drivers/net/dsa/mv88e6xxx/global2.h:449: multiple definition of `mv88e6xxx_g2_scratch_gpio_set_ext_smi'
drivers/net/dsa/mv88e6xxx/chip.o:drivers/net/dsa/mv88e6xxx/global2.h:449: first defined here
vim +449 drivers/net/dsa/mv88e6xxx/global2.h
446
447 int mv88e6xxx_g2_scratch_gpio_set_ext_smi(struct mv88e6xxx_chip *chip,
448 bool external)
> 449 {
450 return -EOPNOTSUPP;
451 }
452
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30903 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171227/a0d57286/attachment-0001.gz>
^ permalink raw reply
* [PATCH] ARM: dts: imx7s: Avoid using label in unit address and reg
From: Fabio Estevam @ 2017-12-26 19:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
As recommended by Rob Herring [1] labels should not be used in unit address
and reg, so use its real value directly instead.
[1] https://www.spinics.net/lists/devicetree/msg206567.html
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx7s.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 2ceb37d..9aa2bb9 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -600,9 +600,9 @@
#address-cells = <1>;
#size-cells = <0>;
- pgc_pcie_phy: pgc-power-domain at IMX7_POWER_DOMAIN_PCIE_PHY {
+ pgc_pcie_phy: pgc-power-domain at 1 {
#power-domain-cells = <0>;
- reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
+ reg = <1>;
power-supply = <®_1p0d>;
};
};
--
2.7.4
^ permalink raw reply related
* [arm:csi-v6 5/15] drivers/media/i2c/imx219.c:1190:37: sparse: cast to restricted __be16
From: kbuild test robot @ 2017-12-26 20:09 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git csi-v6
head: ed3a8e14cfa42d5bb506326186c2092cc69d2899
commit: d63078ff2c761da0b393889c2f909fd379c1fa5b [5/15] media: i2c: imx219 camera driver
reproduce:
# apt-get install sparse
git checkout d63078ff2c761da0b393889c2f909fd379c1fa5b
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
vim +1190 drivers/media/i2c/imx219.c
1086
1087 /*
1088 * The line length in conjunction with the VT clock determines the
1089 * start of transmission of each line on the CSI bus.
1090 *
1091 * The frame length in conjunction with the line length and VT clock
1092 * determines the start of transmission of each frame on the CSI bus.
1093 *
1094 * Note: these two parameters have nothing to do with the pixel array
1095 * addressing parameters.
1096 */
1097 static void imx219_update_frame_size(struct imx219_private *priv)
1098 {
1099 unsigned long vt_pixclk = imx219_get_vt_pixclk(priv);
1100 unsigned long op_sysclk;
1101 unsigned int div, lane_line_bits;
1102 unsigned int line_clk, line_length, line_blank;
1103 unsigned int min_frame_length, frame_length, frame_blank;
1104
1105 /* see comments above, this is definitely wrong */
1106 unsigned int width = be16_to_cpu(priv->params.x_output_size);
1107 unsigned int height = be16_to_cpu(priv->params.y_output_size);
1108
1109 dev_info(priv->root.sd.dev, "%s() for %ux%u %ubpp fi=%u/%u:\n", __func__,
1110 width, height, priv->bits_per_pixel,
1111 priv->frame_interval.numerator,
1112 priv->frame_interval.denominator);
1113
1114 /*
1115 * This works for calculating a working line length, but is
1116 * less than ideal, as we always run the VT block at maximum,
1117 * and wind the output block up to maximum for large widths.
1118 */
1119 lane_line_bits = imx219_calc_lane_line_bits(priv);
1120
1121 line_clk = 2 * vt_pixclk / priv->min_line_length_pck;
1122
1123 dev_info(priv->root.sd.dev, "VT: pixclk=%luHz line=%uHz\n",
1124 vt_pixclk, line_clk);
1125
1126 /* Calculate the required output sysclk */
1127 op_sysclk = line_clk * lane_line_bits;
1128
1129 /*
1130 * Try to find a sysclk divisor that gives us the highest PLL
1131 * speed - otherwise errors seem to occur at the CSI2 receiver:
1132 * i.MX6 CS2 error 2/1 registers = 0x00000120/0x11000113
1133 * - header ecc contains 2 errors
1134 * - crc error on vc0
1135 * - incorrect frame sequence on vc0
1136 * - error matching frame start with frame end on vc0
1137 * - sot sync failed on lane 1
1138 * - sot sync failed on lane 0
1139 * - sot error on lane 1
1140 * - header error detected and corrected on vc0
1141 * Note: docs say 432MHz as the PLL low bound, hardware says 400MHz,
1142 * experimentation with my imx219 is stable at 464MHz but not 456MHz.
1143 */
1144 for (div = priv->pll[PLL_OP].clk[CLK_SYS].max_div;
1145 div > priv->pll[PLL_OP].clk[CLK_SYS].min_div; div--)
1146 if (op_sysclk * div <= priv->pll[PLL_OP].clk[CLK_SYS].max_freq)
1147 break;
1148
1149 priv->op_sys_div = div;
1150 op_sysclk *= div;
1151
1152 dev_info(priv->root.sd.dev, "OP: sysclk=%luHz/%u for %u bits/line/lane\n",
1153 op_sysclk, div, lane_line_bits);
1154
1155 priv->op_mpy = clamp_val(DIV_ROUND_UP(op_sysclk,
1156 priv->pll_ip_freq),
1157 priv->pll[PLL_OP].min_mpy,
1158 priv->pll[PLL_OP].max_mpy);
1159
1160 /* Now calculate the real output sysclk */
1161 op_sysclk = priv->pll_ip_freq * priv->op_mpy / div;
1162
1163 /* ... and the resulting line clock for the output */
1164 line_clk = op_sysclk / lane_line_bits;
1165
1166 dev_info(priv->root.sd.dev, "OP: real sysclk %luHz line %uHz\n",
1167 op_sysclk, line_clk);
1168
1169 /* ... and the final line length */
1170 line_length = clamp_val(DIV_ROUND_UP(2 * vt_pixclk, line_clk),
1171 priv->min_line_length_pck,
1172 priv->max_line_length_pck);
1173
1174 priv->params.line_length = cpu_to_be16(line_length);
1175
1176 /* ... and the final line rate */
1177 line_clk = 2 * vt_pixclk / line_length;
1178
1179 /*
1180 * Calculate the frame length required to give the requested
1181 * frame interval.
1182 */
1183 min_frame_length = imx219_calc_total_lines(priv);
1184 frame_length = div_u64((u64)line_clk * priv->frame_interval.numerator,
1185 priv->frame_interval.denominator);
1186
1187 frame_length = clamp_val(frame_length, min_frame_length,
1188 priv->max_frame_lines);
1189
> 1190 priv->params.frame_length = be16_to_cpu(frame_length);
1191
1192 dev_info(priv->root.sd.dev, "VT: line length %u frame length %u line %uHz\n",
1193 line_length, frame_length, line_clk);
1194
1195
1196
1197 /* See comments above, this is definitely wrong. */
1198 line_blank = line_length - width;
1199 frame_blank = frame_length - height;
1200
1201 v4l2_ctrl_s_ctrl_int64(priv->pixel.ctrls[CTRL_P_PIXEL_RATE],
1202 2 * vt_pixclk);
1203
1204 v4l2_ctrl_modify_range(priv->pixel.ctrls[CTRL_P_HBLANK],
1205 max_t(s32, priv->min_line_length_pck - width,
1206 priv->min_line_blank_pck),
1207 priv->max_line_length_pck - width, 1,
1208 line_blank);
1209 v4l2_ctrl_s_ctrl(priv->pixel.ctrls[CTRL_P_HBLANK], line_blank);
1210
1211 v4l2_ctrl_modify_range(priv->pixel.ctrls[CTRL_P_VBLANK],
1212 max_t(s32, priv->min_frame_lines - height,
1213 priv->min_frame_blank_lines),
1214 priv->max_frame_lines - height, 1, frame_blank);
1215 v4l2_ctrl_s_ctrl(priv->pixel.ctrls[CTRL_P_VBLANK], frame_blank);
1216
1217 imx219_set_exposure_limits(priv);
1218 }
1219
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RESEND][PATCH 1/4] of: platform: populate /firmware/ node from of_platform_default_populate_init()
From: Bjorn Andersson @ 2017-12-26 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1506595562-10592-2-git-send-email-sudeep.holla@arm.com>
On Thu, Sep 28, 2017 at 3:45 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Since "/firmware" does not have its own "compatible" property as it's
> just collection of nodes representing firmware interface, it's sub-nodes
> are not populated during system initialization.
>
> Currently different firmware drivers search the /firmware/ node and
> populate the sub-node devices selectively. Instead we can populate
> the /firmware/ node during init to avoid more drivers continuing to
> populate the devices selectively.
>
> To generalize the solution this patch populates the /firmware/ node
> explicitly from of_platform_default_populate_init().
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh@kernel.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
Andy, as you picked patch 2/4 into your v4.16 -next branch we no
longer probe the qcom_scm device, causing various breakage. Can you
please pick this patch as well (it has Rob's ack).
Regards,
Bjorn
> drivers/of/platform.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index ac15d0e3d27d..3a213a6aee89 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -515,6 +515,10 @@ static int __init of_platform_default_populate_init(void)
> of_platform_device_create(node, NULL, NULL);
> }
>
> + node = of_find_node_by_path("/firmware");
> + if (node)
> + of_platform_populate(node, NULL, NULL, NULL);
> +
> /* Populate everything else. */
> of_platform_default_populate(NULL, NULL, NULL);
>
> --
> 2.7.4
>
^ permalink raw reply
* [linux-sunxi] [PATCH v4 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Rob Herring @ 2017-12-26 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222100008.nmmzwhtmputizn7d@plaes.org>
On Fri, Dec 22, 2017 at 10:00:08AM +0000, Priit Laes wrote:
> On Fri, Dec 22, 2017 at 05:41:29PM +0800, Yong Deng wrote:
> > Add binding documentation for Allwinner V3s CSI.
> >
> > Signed-off-by: Yong Deng <yong.deng@magewell.com>
> > ---
> > .../devicetree/bindings/media/sun6i-csi.txt | 51 ++++++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > new file mode 100644
> > index 0000000..b5bfe3f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > @@ -0,0 +1,51 @@
> > +Allwinner V3s Camera Sensor Interface
> > +------------------------------
>
> Not sure whether syntax for these files is proper reStructuredText/Markdown,
> but the underline-ish style expects the title and underline having same length.
The binding files are not rst/md format, but still the comment is just
good style.
Rob
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Rob Herring @ 2017-12-26 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513935689-35415-1-git-send-email-yong.deng@magewell.com>
On Fri, Dec 22, 2017 at 05:41:29PM +0800, Yong Deng wrote:
> Add binding documentation for Allwinner V3s CSI.
>
> Signed-off-by: Yong Deng <yong.deng@magewell.com>
> ---
> .../devicetree/bindings/media/sun6i-csi.txt | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> new file mode 100644
> index 0000000..b5bfe3f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> @@ -0,0 +1,51 @@
> +Allwinner V3s Camera Sensor Interface
> +------------------------------
> +
> +Required properties:
> + - compatible: value must be "allwinner,sun8i-v3s-csi"
> + - reg: base address and size of the memory-mapped region.
> + - interrupts: interrupt associated to this IP
> + - clocks: phandles to the clocks feeding the CSI
> + * bus: the CSI interface clock
> + * mod: the CSI module clock
> + * ram: the CSI DRAM clock
> + - clock-names: the clock names mentioned above
> + - resets: phandles to the reset line driving the CSI
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + Currently, the driver only support the parallel interface. So, a single port
> + node with one endpoint and parallel bus is supported.
What the driver supports is not relevant. Please document what the h/w
has.
> +
> +Example:
> +
> + csi1: csi at 1cb4000 {
> + compatible = "allwinner,sun8i-v3s-csi";
> + reg = <0x01cb4000 0x1000>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_CSI>,
> + <&ccu CLK_CSI1_SCLK>,
> + <&ccu CLK_DRAM_CSI>;
> + clock-names = "bus", "mod", "ram";
> + resets = <&ccu RST_BUS_CSI>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
These are not needed with a single endpoint.
> +
> + /* Parallel bus endpoint */
> + csi1_ep: endpoint {
> + remote-endpoint = <&adv7611_ep>;
> + bus-width = <16>;
> + data-shift = <0>;
> +
> + /* If hsync-active/vsync-active are missing,
> + embedded BT.656 sync is used */
> + hsync-active = <0>; /* Active low */
> + vsync-active = <0>; /* Active low */
> + data-active = <1>; /* Active high */
> + pclk-sample = <1>; /* Rising */
> + };
> + };
> + };
> +
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH 1/1] power: reset: remove unused imx-snvs-poweroff driver
From: Rob Herring @ 2017-12-26 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513938539-20873-1-git-send-email-aisheng.dong@nxp.com>
On Fri, Dec 22, 2017 at 06:28:59PM +0800, Dong Aisheng wrote:
> There's no user of it in kernel now and it basically functions the same
> as the generic syscon-poweroff.c to which we have already switched.
> So let's remove it.
>
> Cc: Robin Gong <yibin.gong@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> .../bindings/power/reset/imx-snvs-poweroff.txt | 23 --------
Acked-by: Rob Herring <robh@kernel.org>
> drivers/power/reset/Kconfig | 9 ---
> drivers/power/reset/Makefile | 1 -
> drivers/power/reset/imx-snvs-poweroff.c | 66 ----------------------
> 4 files changed, 99 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/power/reset/imx-snvs-poweroff.txt
> delete mode 100644 drivers/power/reset/imx-snvs-poweroff.c
^ permalink raw reply
* [PATCH] dt: psci: Update DT bindings to support hierarchical PSCI states
From: Rob Herring @ 2017-12-26 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513953127-3321-1-git-send-email-ulf.hansson@linaro.org>
On Fri, Dec 22, 2017 at 03:32:07PM +0100, Ulf Hansson wrote:
> From: Lina Iyer <lina.iyer@linaro.org>
>
> Update DT bindings to represent hierarchical CPU and CPU domain idle states
> for PSCI. Also update the PSCI examples to clearly show how flattened and
> hierarchical idle states can be represented in DT.
>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>
> For your information, I have picked up the work from Lina Iyer around the so
> called CPU cluster idling series [1,2] and I working on new versions. However,
> I decided to post the updates to the PSCI DT bindings first, as they will be
> needed to be agreed upon before further changes can be done to the PSCI firmware
> driver.
>
> Note, these bindings have been discussed over and over again, at LKML, but
> especially also at various Linux conferences, like LPC and Linaro Connect. We
> finally came to a conclusion and the changes we agreed upon, should be reflected
> in this update.
>
> Of course, it's a while ago since the latest discussions, but hopefully people
> don't have too hard time to remember.
Vaguely...
>
> Kind regards
> Uffe
>
> [1]
> https://www.spinics.net/lists/arm-kernel/msg566200.html
>
> [2]
> https://lwn.net/Articles/716300/
>
> ---
> Documentation/devicetree/bindings/arm/psci.txt | 152 +++++++++++++++++++++++++
> 1 file changed, 152 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
> index a2c4f1d..5a8f11b 100644
> --- a/Documentation/devicetree/bindings/arm/psci.txt
> +++ b/Documentation/devicetree/bindings/arm/psci.txt
> @@ -105,7 +105,159 @@ Case 3: PSCI v0.2 and PSCI v0.1.
> ...
> };
>
> +PSCI v1.0 onwards, supports OS-Initiated mode for powering off CPUs and CPU
> +clusters from the firmware. For such topologies the PSCI firmware driver acts
> +as pseudo-controller, which may be specified in the psci DT node. The
> +definitions of the CPU and the CPU cluster topology, must conform to the domain
> +idle state specification [3]. The domain idle states themselves, must be
> +compatible with the defined 'domain-idle-state' binding [1], and also need to
> +specify the arm,psci-suspend-param property for each idle state.
> +
> +DT allows representing CPU and CPU cluster idle states in two different ways -
> +
> +The flattened model as given in Example 1, lists CPU's idle states followed by
> +the domain idle state that the CPUs may choose. This is the general practice
> +followed in PSCI firmwares that support Platform Coordinated mode. Note that
> +the idle states are all compatible with "arm,idle-state".
> +
> +Example 2 represents the hierarchical model of CPU and domain idle states.
> +CPUs define their domain provider in their DT node. The domain controls the
> +power to the CPU and possibly other h/w blocks that would be powered off when
> +the CPU is powered off. The CPU's idle states may therefore be considered as
> +the domain's idle states and have the compatible "arm,idle-state". Such domains
> +may be embedded within another domain that represents common h/w blocks between
> +these CPUs viz. the cluster. The idle states of the cluster would be
> +represented as the domain's idle states. In order to use OS-Initiated mode of
> +PSCI in the firmware, the hierarchical representation must be used.
> +
> +Example 1: Flattened representation of CPU and domain idle states
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
> + <&CLUSTER_PWR_DWN>;
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + reg = <0x100>;
> + enable-method = "psci";
> + cpu-idle-states = <&CPU_PWRDN>, <&CLUSTER_RET>,
> + <&CLUSTER_PWR_DWN>;
> + };
> +
> + idle-states {
> + CPU_PWRDN: cpu_power_down{
Use '-' rather than '_'. dtc has more warnings since last time...
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x000001>;
> + entry-latency-us = <10>;
> + exit-latency-us = <10>;
> + min-residency-us = <100>;
> + };
> +
> + CLUSTER_RET: domain_ret {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000010>;
> + entry-latency-us = <500>;
> + exit-latency-us = <500>;
> + min-residency-us = <2000>;
> + };
> +
> + CLUSTER_PWR_DWN: domain_off {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x1000030>;
> + entry-latency-us = <2000>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6000>;
> + };
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> +Example 2: Hierarchical representation of CPU and domain idle states
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + CPU0: cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0>;
> + enable-method = "psci";
> + power-domains = <&CPU_PD0>;
> + };
> +
> + CPU1: cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a57", "arm,armv8";
> + reg = <0x100>;
> + enable-method = "psci";
> + power-domains = <&CPU_PD1>;
> + };
> +
> + idle-states {
> + CPU_PWRDN: cpu_power_down{
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x000001>;
> + entry-latency-us = <10>;
> + exit-latency-us = <10>;
> + min-residency-us = <100>;
> + };
> +
> + CLUSTER_RET: domain_ret {
> + compatible = "domain-idle-state";
> + arm,psci-suspend-param = <0x1000010>;
> + entry-latency-us = <500>;
> + exit-latency-us = <500>;
> + min-residency-us = <2000>;
> + };
> +
> + CLUSTER_PWR_DWN: domain_off {
> + compatible = "domain-idle-state";
> + arm,psci-suspend-param = <0x1000030>;
> + entry-latency-us = <2000>;
> + exit-latency-us = <2000>;
> + min-residency-us = <6000>;
> + };
> + };
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> +
> + CPU_PD0: cpu-pd at 0 {
A unit address without reg property is now a warning.
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CPU_PWRDN>;
> + power-domains = <&CLUSTER_PD>;
> + };
> +
> + CPU_PD1: cpu-pd at 1 {
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CPU_PWRDN>;
> + power-domains = <&CLUSTER_PD>;
Could this node be a child of CLUSTER_PD rather than having a phandle?
Doesn't matter so much here, but when you have 3 levels?
> + };
These 2 nodes are identical, so why do you need both?
> +
> + CLUSTER_PD: cluster-pd at 0 {
> + #power-domain-cells = <0>;
> + domain-idle-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
> + };
> + };
> +
> [1] Kernel documentation - ARM idle states bindings
> Documentation/devicetree/bindings/arm/idle-states.txt
> [2] Power State Coordination Interface (PSCI) specification
> http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
> +[3]. PM Domains description
> + Documentation/devicetree/bindings/power/power_domain.txt
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 03/14] dt-bindings: iio: add binding support for iio trigger provider/consumer
From: Rob Herring @ 2017-12-26 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513955241-10985-4-git-send-email-eugen.hristev@microchip.com>
On Fri, Dec 22, 2017 at 05:07:10PM +0200, Eugen Hristev wrote:
> Add bindings for producer/consumer for iio triggers.
>
> Similar with iio channels, the iio triggers can be connected between drivers:
> one driver will be a producer by registering iio triggers, and another driver
> will connect as a consumer.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> .../devicetree/bindings/iio/iio-bindings.txt | 52 +++++++++++++++++++++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> index 68d6f8c..d861f0df 100644
> --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
> +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
> @@ -11,6 +11,10 @@ value of a #io-channel-cells property in the IIO provider node.
>
> [1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
>
> +Moreover, the provider can have a set of triggers that can be attached to
> +from the consumer drivers.
> +
> +
> ==IIO providers==
>
> Required properties:
> @@ -18,6 +22,11 @@ Required properties:
> with a single IIO output and 1 for nodes with multiple
> IIO outputs.
>
> +Optional properties:
> +#io-trigger-cells: Number of cells for the IIO trigger specifier. Typically 0
> + for nodes with a single IIO trigger and 1 for nodes with
> + multiple IIO triggers.
> +
> Example for a simple configuration with no trigger:
>
> adc: voltage-sensor at 35 {
> @@ -26,7 +35,7 @@ Example for a simple configuration with no trigger:
> #io-channel-cells = <1>;
> };
>
> -Example for a configuration with trigger:
> +Example for a configuration with channels provided by trigger:
>
> adc at 35 {
> compatible = "some-vendor,some-adc";
> @@ -42,6 +51,17 @@ Example for a configuration with trigger:
> };
> };
>
> +Example for a configuration for a trigger provider:
> +
> + adc: sensor-with-trigger at 35 {
> + compatible = "some-vendor,some-adc";
> + reg = <0x35>;
> + #io-channel-cells = <1>;
> + #io-trigger-cells = <1>;
> + /* other properties */
> + };
> +
> +
> ==IIO consumers==
>
> Required properties:
> @@ -61,16 +81,38 @@ io-channel-ranges:
> IIO channels from this node. Useful for bus nodes to provide
> and IIO channel to their children.
>
> +io-triggers: List of phandle and IIO specifier pairs, one pair
> + for each trigger input to the device. Note: if the
> + IIO trigger provider specifies '0' for #io-trigger-cells,
> + then only the phandle portion of the pair will appear.
> +
> +io-trigger-names:
> + List of IIO trigger input name strings sorted in the same
> + order as the io-triggers property. Consumers drivers
> + will use io-trigger-names to match IIO trigger input names
> + with IIO specifiers.
> +
> +io-trigger-ranges:
> + Empty property indicating that child nodes can inherit named
> + IIO triggers from this node. Useful for bus nodes to provide
> + IIO triggers to their children.
I think it would be better to be explicit in the child nodes. What's the
use you had in mind?
Rob
^ permalink raw reply
* [PATCH 13/14] input: touchscreen: sama5d2_rts: SAMA5D2 Resistive touchscreen driver
From: Rob Herring @ 2017-12-26 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513955241-10985-14-git-send-email-eugen.hristev@microchip.com>
On Fri, Dec 22, 2017 at 05:07:20PM +0200, Eugen Hristev wrote:
> This is the implementation of the Microchip SAMA5D2 SOC resistive
> touchscreen driver.
> The driver registers an input device and connects to the give IIO device
> from devicetree. It requires an IIO trigger (acting as a consumer) and
> three IIO channels : one for X position, one for Y position and one
> for pressure.
> It the reports the values to the input subsystem.
>
> Some parts of this driver are based on the initial original work by
> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
This doesn't appear to have anything specific to SAMA5D2 SoC, but is
rather just a generic ADC (IIO based) resistive touchscreen driver.
Perhaps the binding can also be just an "adc-resistive-touchscreen".
Rob
^ permalink raw reply
* [PATCHv3 RESEND 1/3] Documentation: dt: memory: ti-emif: add edac support under emif
From: Rob Herring @ 2017-12-26 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513959834-27901-1-git-send-email-t-kristo@ti.com>
On Fri, Dec 22, 2017 at 06:23:54PM +0200, Tero Kristo wrote:
> Certain revisions of the TI EMIF IP contain ECC support in them. Reflect
> this in the DT binding.
"dt-bindings: edac: ..." is the preferred subject prefix.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> ---
> Just resending this patch, missed adding devicetree list on this previously
> and it got lost.
>
> .../devicetree/bindings/memory-controllers/ti/emif.txt | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> index 0db6047..f56a347 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
> @@ -3,12 +3,16 @@
> EMIF - External Memory Interface - is an SDRAM controller used in
> TI SoCs. EMIF supports, based on the IP revision, one or more of
> DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
> -of the EMIF IP and memory parts attached to it.
> +of the EMIF IP and memory parts attached to it. Certain revisions
> +of the EMIF IP controller also contain optional ECC support, which
> +corrects one bit errors and detects two bit errors.
>
> Required properties:
> - compatible : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
> is the IP revision of the specific EMIF instance.
> For am437x should be ti,emif-am4372.
> + For dra7xx should be ti,emif-dra7xx.
> + For k2x family, should be ti,emif-keystone.
>
> - phy-type : <u32> indicating the DDR phy type. Following are the
> allowed values
> @@ -42,6 +46,10 @@ Optional properties:
> - hw-caps-temp-alert : Have this property if the controller
> has capability for generating SDRAM temperature alerts
>
> +- interrupts : A list of interrupt specifiers for memory
> + controller interrupts, if available. Required for EMIF instances
> + that support ECC.
Be explicit as to which compatibles have an interrupt. Is it really
optional for for those controllers? The interrupt is in the h/w whether
you use ECC or not.
> +
> Example:
>
> emif1: emif at 0x4c000000 {
> @@ -54,3 +62,9 @@ emif1: emif at 0x4c000000 {
> hw-caps-ll-interface;
> hw-caps-temp-alert;
> };
> +
> +emif1: emif at 4c000000 {
> + compatible = "ti,emif-dra7";
> + reg = <0x4c000000 0x200>;
> + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
> +};
> --
> 1.9.1
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCHv3 RESEND 1/3] Documentation: dt: memory: ti-emif: add edac support under emif
From: Rob Herring @ 2017-12-26 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226224819.6uekbnbd5tllaxb5@rob-hp-laptop>
On Tue, Dec 26, 2017 at 4:48 PM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Dec 22, 2017 at 06:23:54PM +0200, Tero Kristo wrote:
>> Certain revisions of the TI EMIF IP contain ECC support in them. Reflect
>> this in the DT binding.
>
> "dt-bindings: edac: ..." is the preferred subject prefix.
Err, I mean "dt-bindings: memory-controllers: ..."
Rob
^ 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