* [PATCH 1/3][v2] dt-bindings: Add compatible for LS2088A QDS and RDB boards
From: Abhimanyu Saini @ 2016-11-28 9:37 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini, Priyanka Jain, Ashish Kumar
In-Reply-To: <1480325824-14649-1-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/arm/fsl.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index d6ee9c6..75ad8c5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -179,3 +179,14 @@ LS2080A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";
+LS2088A SoC
+Required root node properties:
+ - compatible = "fsl,ls2088a";
+
+LS2088A ARMv8 based QDS Board
+Required root node properties:
+ - compatible = "fsl,ls2088a-qds", "fsl,ls2088a";
+
+LS2088A ARMv8 based RDB Board
+Required root node properties:
+ - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/3][v2] Add QorIQ LS2088A platform support
From: Abhimanyu Saini @ 2016-11-28 9:37 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: scott.wood-3arQi8VN3Tc, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Abhimanyu Saini
This patchset adds support for the QorIQ LS2088A SoC.
LS2088A SoC is similar to LS2080A SoC with a few differences
like it has A72 cores.
This patchset
- reorganize LS2088A DTS/DTSI for code reuseability
- adds LS2088A device dtsi and dts files.
Abhimanyu Saini (3):
dt-bindings: Add compatible for LS2088A QDS and RDB boards
arm64: freescale: ls2080a: Split devicetree for code resuability
arm64: Add DTS support for FSL's LS2088A SoC
Changes for v2:
- reorganize LS2088A device tree to use common
nodes from LS2080A device trees.
- Both LS2080A and LS2088A have same hardware
controllers, so separate dt-binding patches for
pcie, gpio, dspi, qspi are not required.
Documentation/devicetree/bindings/arm/fsl.txt | 11 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts | 196 ++++++
.../boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts | 152 +++++
.../boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi | 727 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 154 +----
arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 110 +---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 706 +-------------------
arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts | 65 ++
arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts | 65 ++
arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 162 +++++
11 files changed, 1405 insertions(+), 945 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
--
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] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-28 9:32 UTC (permalink / raw)
To: Russell King - ARM Linux, Stephen Boyd, Rob Herring, Linux-ALSA,
Linux-DT, Michael Turquette, Linux-Kernel, Mark Brown,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
This patch adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
v2 -> v3
- implement in clk-devres.c, and reused existing devm_clk_release()
drivers/clk/clk-devres.c | 21 +++++++++++++++++++++
include/linux/clk.h | 7 +++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index 8f57154..2449b25 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -53,3 +53,24 @@ void devm_clk_put(struct device *dev, struct clk *clk)
WARN_ON(ret);
}
EXPORT_SYMBOL(devm_clk_put);
+
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ struct clk **ptr, *clk;
+
+ ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ clk = of_clk_get(np, index);
+ if (!IS_ERR(clk)) {
+ *ptr = clk;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return clk;
+}
+EXPORT_SYMBOL(devm_of_clk_get);
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 123c027..1b713db 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -506,6 +506,8 @@ static inline void clk_disable_unprepare(struct clk *clk)
#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index);
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
#else
@@ -513,6 +515,11 @@ static inline struct clk *of_clk_get(struct device_node *np, int index)
{
return ERR_PTR(-ENOENT);
}
+static inline struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ return ERR_PTR(-ENOENT);
+}
static inline struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V4 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Jon Hunter @ 2016-11-28 9:31 UTC (permalink / raw)
To: Laxman Dewangan, Thierry Reding
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q, gnurou-Re5JQEeQqe8AvxtiuMwx3w,
joe-6d6DIl74uiNBDgjK7y7TUQ,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <583878A1.7090207-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 25/11/16 17:45, Laxman Dewangan wrote:
>
> On Friday 25 November 2016 10:56 PM, Jon Hunter wrote:
>> On 25/11/16 09:57, Thierry Reding wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Thu, Nov 24, 2016 at 02:08:54PM +0530, Laxman Dewangan wrote:
>> ...
>>
>>>> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
>>>> b/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
>>>> new file mode 100644
>>>> index 0000000..aab02d0
>>>> --- /dev/null
>>>> +++ b/drivers/pinctrl/tegra/pinctrl-tegra-io-pad.c
>>>> @@ -0,0 +1,530 @@
>>>> +/*
>>>> + * pinctrl-tegra-io-pad: IO PAD driver for configuration of IO rail
>>>> and deep
>>>> + * Power Down mode via pinctrl framework.
>>>> + *
>>>> + * Copyright (C) 2016 NVIDIA CORPORATION. All rights reserved.
>>>> + *
>>>> + * Author: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + */
>>>> +
>>>> +#include <linux/delay.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/pinctrl/pinctrl.h>
>>>> +#include <linux/pinctrl/pinconf-generic.h>
>>>> +#include <linux/pinctrl/pinconf.h>
>>>> +#include <linux/pinctrl/pinmux.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/regulator/consumer.h>
>>>> +#include <soc/tegra/pmc.h>
>>> Have you considered moving this code into the PMC driver? It seems a
>>> little over the top to go through all of the platform device creation
>>> and driver registration dance only to call into a public API later on.
>> I would prefer moving this under driver/soc/tegra as well (even if it is
>> not in the same source file) so we don't need all this public APIs.
>>
>
> Do we really gain anything here by moving driver to drivers/soc/tegra?
Only avoid adding these public APIs. By using the pinctrl framework, it
would be nice to avoid having to still have public APIs that someone
could use directly.
> The folder drivers/pinctrl/tegra is dedicated folder for Tegra specific.
> We should keep the related driver in given subsystem until this is
> really hard to do it.
> Even if we organise and move this driver to the driver/soc/tegra, we
> will need only 3-4 APIs from the public pmc header to the private header.
> I think calling the tegra specific headers/APIs from tegra specific
> driver should be fine here.
Its OK, but I still prefer not having them at all.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH V4 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Jon Hunter @ 2016-11-28 9:26 UTC (permalink / raw)
To: Laxman Dewangan, Thierry Reding
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q, gnurou-Re5JQEeQqe8AvxtiuMwx3w,
joe-6d6DIl74uiNBDgjK7y7TUQ,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <583879A8.7020401-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 25/11/16 17:49, Laxman Dewangan wrote:
>
> On Friday 25 November 2016 10:59 PM, Jon Hunter wrote:
>> On 25/11/16 12:04, Laxman Dewangan wrote:
>>> Thanks Thierry for review.
>>>
>>> On Friday 25 November 2016 03:27 PM, Thierry Reding wrote:
>>>> * PGP Signed by an unknown key
>>>>
>>>> On Thu, Nov 24, 2016 at 02:08:54PM +0530, Laxman Dewangan wrote:
>>>>> + NVIDIA Tegra124/210 SoC has IO pads which supports
>>>>> multi-voltage
>>>>> + level of interfacing and deep power down mode of IO pads. The
>>>>> + voltage of IO pads are SW configurable based on IO rail of that
>>>>> + pads on T210. This driver provides the interface to change
>>>>> IO pad
>>>>> + voltage and power state via pincontrol interface.
>>>> This has a lot of chip-specific text. Will all of that have to be
>>>> updated if support for new chips is added?
>>> Then saying that Tegra124 and later..
>>> Hoping, people know our chip releasing sequence as numbering are not in
>>> sequence.
>>>
>>>>> +#include <linux/regulator/consumer.h>
>>>>> +#include <soc/tegra/pmc.h>
>>>> Have you considered moving this code into the PMC driver? It seems a
>>>> little over the top to go through all of the platform device creation
>>>> and driver registration dance only to call into a public API later on.
>>> Yes, we had discussion on this and suggestion came to use the pinctrl
>>> framework.
>>> If we do in the pmc driver then we will need lots of DT processing for
>>> getting information from DT which we can directly get from the pinctrl
>>> core framework.
>>> Also client driver may need to have the control dynamically and get the
>>> IO pads from DT. So implementing all in pmc will be huge duplication
>>> over already existing framework.
>> I don't follow. We already did something similar for the Tegra DPAUX
>> driver [0].
>>
>> Cheers
>> Jon
>>
>> [0]
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/tegra/dpaux.c?id=0751bb5c44fe1aa9494ce259d974c3d249b73a84
>>
>
> In the above dpaux driver, you used the pinctrl framework and its core
> functionality for the device tree interfacing and client interfacing.
>
> The same thing I am saying here, we should not avoid the pinctrl
> framework. The client driver will use the pinctrl framework for the IO
> pad configurations, not direct PMC APIs.
Exactly, so why are you saying that by moving the code into the PMC
driver this will "need lots of DT processing for getting information
from DT"? By moving the code, we are not suggesting we don't use the
pinctrl framework, we are just suggesting we move the code. That's all.
Jon
--
nvpublic
^ permalink raw reply
* Re: [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-28 9:23 UTC (permalink / raw)
To: Laurent Pinchart, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ, victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3721857.XEGXu9B51N@avalon>
Hi Laurent,
On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 134 +++++++++++++++++
>> 1 file changed, 134 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
>> mode 100644
>> index 0000000..89c1b5f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> @@ -0,0 +1,134 @@
>> +Amlogic Meson Display Controller
>> +================================
>> +
>> +The Amlogic Meson Display controller is composed of several components
>> +that are going to be documented below:
>> +
>> +DMC|---------------VPU (Video Processing Unit)------------|------HHI------|
>> + | vd1 _______ _____________ _____________ | |
>> +D |-------| |----| | | | | HDMI PLL |
>> +D | vd2 | VIU | | Video Post | | Video Encs |<---|-----VCLK |
>> +R |-------| |----| Processing | | | | |
>> + | osd2 | | | |---| Enci ------|----|-----VDAC------|
>> +R |-------| CSC |----| Scalers | | Encp ------|----|----HDMI-TX----|
>> +A | osd1 | | | Blenders | | Encl-------|----|---------------|
>> +M |-------|______|----|____________| |____________| | |
>> +___|______________________________________________________|_______________|
>> +
>> +
>> +VIU: Video Input Unit
>> +---------------------
>> +
>> +The Video Input Unit is in charge of the pixel scanout from the DDR memory.
>> +It fetches the frames addresses, stride and parameters from the "Canvas"
>> memory.
>> +This part is also in charge of the CSC (Colorspace Conversion).
>> +It can handle 2 OSD Planes and 2 Video Planes.
>> +
>> +VPP: Video Processing Unit
>
> Do you mean "Video Post Processing" ? In your diagram above Video Processing
> Unit is abbreviated VPU and covers the VIU, VPP and encoders.
Exact, I meant VPP here.
>
>> +--------------------------
>> +
>> +The Video Processing Unit is in charge if the scaling and blending of the
>> +various planes into a single pixel stream.
>> +There is a special "pre-blending" used by the video planes with a dedicated
>> +scaler and a "post-blending" to merge with the OSD Planes.
>> +The OSD planes also have a dedicated scaler for one of the OSD.
>> +
>> +VENC: Video Encoders
>> +--------------------
>> +
>> +The VENC is composed of the multiple pixel encoders :
>> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
>> + - ENCP : Progressive Video Encoder for HDMI
>> + - ENCL : LCD LVDS Encoder
>> +The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and
>> clock
>> +tree and provides the scanout clock to the VPP and VIU.
>> +The ENCI is connected to a single VDAC for Composite Output.
>> +The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
>> +
>> +Device Tree Bindings:
>> +---------------------
>> +
>> +VPU: Video Processing Unit
>> +--------------------------
>> +
>> +Required properties:
>> + - compatible: value should be different for each SoC family as :
>> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
>> + - GXM (S912) : "amlogic,meson-gxm-vpu"
>> + followed by the common "amlogic,meson-gx-vpu"
>> + - reg: base address and size of he following memory-mapped regions :
>> + - vpu
>> + - hhi
>> + - dmc
>> + - reg-names: should contain the names of the previous memory regions
>> + - interrupts: should contain the VENC Vsync interrupt number
>> +
>> +- ports: A ports node with endpoint definitions as defined in
>> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
>> + second port should be the output endpoints for VENC connectors.
>> +
>> +VENC CBVS Output
>> +----------------------
>> +
>> +The VENC can output Composite/CVBS output via a decicated VDAC.
>> +
>> +Required properties:
>> + - compatible: value must be one of:
>> + - compatible: value should be different for each SoC family as :
>
> One of those two lines is redundant.
Will fix.
>
>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
>> + followed by the common "amlogic,meson-gx-venc-cvbs"
>> +
>
> No registers ? Are the encoders registers part of the VPU register space,
> intertwined in a way that they can't be specified separately here ?
Exact, all the video registers on the Amlogic SoC are part of a long history of fixup/enhance from very old SoCs, it's
quite hard to distinguish a Venc registers array since they are mixed with the multiple encoders registers...
The only separate registers are the VDAC and HDMI PHY, I may move them to these separate nodes since they are part of the HHI register space.
It is a problem if I move them in the next release ? Next release will certainly have HDMI support, and will have these refactorings.
>
>> +- ports: A ports node with endpoint definitions as defined in
>> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
>> + first port should be the input endpoints, connected ot the VPU node.
>> +
>> +Example:
>> +
>> +venc_cvbs: venc-cvbs {
>> + compatible = "amlogic,meson-gxbb-venc-cvbs";
>> + status = "okay";
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + enc_cvbs_in: port@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + venc_cvbs_in_vpu: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint = <&vpu_out_venc_cvbs>;
>> + };
>> + };
>> + };
>> +};
>> +
>> +vpu: vpu@d0100000 {
>> + compatible = "amlogic,meson-gxbb-vpu";
>> + reg = <0x0 0xd0100000 0x0 0x100000>,
>> + <0x0 0xc883c000 0x0 0x1000>,
>> + <0x0 0xc8838000 0x0 0x1000>;
>> + reg-names = "base", "hhi", "dmc";
>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + vpu_out: port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + vpu_out_venc_cvbs: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint = <&venc_cvbs_in_vpu>;
>> + };
>> + };
>> + };
>> +};
>
Thanks for the review !
Neil
--
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 V4 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Laxman Dewangan @ 2016-11-28 9:22 UTC (permalink / raw)
To: Jon Hunter, Thierry Reding
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q, gnurou-Re5JQEeQqe8AvxtiuMwx3w,
joe-6d6DIl74uiNBDgjK7y7TUQ,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4d255a3e-0816-498c-a280-6d29ca880e13-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Monday 28 November 2016 02:56 PM, Jon Hunter wrote:
> On 25/11/16 17:49, Laxman Dewangan wrote:
>>
>> In the above dpaux driver, you used the pinctrl framework and its core
>> functionality for the device tree interfacing and client interfacing.
>>
>> The same thing I am saying here, we should not avoid the pinctrl
>> framework. The client driver will use the pinctrl framework for the IO
>> pad configurations, not direct PMC APIs.
> Exactly, so why are you saying that by moving the code into the PMC
> driver this will "need lots of DT processing for getting information
> from DT"? By moving the code, we are not suggesting we don't use the
> pinctrl framework, we are just suggesting we move the code. That's all.
>
>
OK, got it. My understanding from suggestion was that to implement
everything without using the pinctrl framework.
I dont see much issue to just move this to drivers/soc/tegra folder
I hope rest of stuff will be same, registering it as subdev of the pmc
and this io pad driver will be the platform driver.
^ permalink raw reply
* Re: [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-28 9:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Boyd, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
In-Reply-To: <20161128091456.GR14217-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Hi Russell
> > Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
> > This patch adds it. This is based on devm_clk_get()
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Please put this in drivers/clk/clk-devres.c, where you'll find that
> we have devm_clk_release() which is identical to your
> devm_of_clk_release(). It'll also not need the dummy definition of
> devm_of_clk_get().
OK, will do
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] clkdev: add devm_of_clk_get()
From: Russell King - ARM Linux @ 2016-11-28 9:14 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Stephen Boyd, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <8737icayac.wl%kuninori.morimoto.gx@renesas.com>
On Mon, Nov 28, 2016 at 06:56:52AM +0000, Kuninori Morimoto wrote:
> Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
> This patch adds it. This is based on devm_clk_get()
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Please put this in drivers/clk/clk-devres.c, where you'll find that
we have devm_clk_release() which is identical to your
devm_of_clk_release(). It'll also not need the dummy definition of
devm_of_clk_get().
Thanks.
> ---
> v1 -> v2
>
> - update git log
>
> drivers/clk/clkdev.c | 26 ++++++++++++++++++++++++++
> include/linux/clk.h | 7 +++++++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 89cc700..93a613b 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -55,6 +55,32 @@ struct clk *of_clk_get(struct device_node *np, int index)
> }
> EXPORT_SYMBOL(of_clk_get);
>
> +static void devm_of_clk_release(struct device *dev, void *res)
> +{
> + clk_put(*(struct clk **)res);
> +}
> +
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
> +{
> + struct clk **ptr, *clk;
> +
> + ptr = devres_alloc(devm_of_clk_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + clk = of_clk_get(np, index);
> + if (!IS_ERR(clk)) {
> + *ptr = clk;
> + devres_add(dev, ptr);
> + } else {
> + devres_free(ptr);
> + }
> +
> + return clk;
> +}
> +EXPORT_SYMBOL(devm_of_clk_get);
> +
> static struct clk *__of_clk_get_by_name(struct device_node *np,
> const char *dev_id,
> const char *name)
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index a89ba4e..33cd540 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -502,6 +502,8 @@ struct of_phandle_args;
>
> #if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
> struct clk *of_clk_get(struct device_node *np, int index);
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index);
> struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
> struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
> #else
> @@ -509,6 +511,11 @@ static inline struct clk *of_clk_get(struct device_node *np, int index)
> {
> return ERR_PTR(-ENOENT);
> }
> +static inline struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
> +{
> + return ERR_PTR(-ENOENT);
> +}
> static inline struct clk *of_clk_get_by_name(struct device_node *np,
> const char *name)
> {
> --
> 1.9.1
>
--
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: [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-28 8:33 UTC (permalink / raw)
To: dri-devel
Cc: devicetree, Xing.Xu, victor.wan, Neil Armstrong, khilman,
linux-kernel, linux-amlogic, carlo, jerry.cao, linux-arm-kernel
In-Reply-To: <1480089791-12517-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 134 +++++++++++++++++
> 1 file changed, 134 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
> diff --git a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new file
> mode 100644
> index 0000000..89c1b5f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> @@ -0,0 +1,134 @@
> +Amlogic Meson Display Controller
> +================================
> +
> +The Amlogic Meson Display controller is composed of several components
> +that are going to be documented below:
> +
> +DMC|---------------VPU (Video Processing Unit)------------|------HHI------|
> + | vd1 _______ _____________ _____________ | |
> +D |-------| |----| | | | | HDMI PLL |
> +D | vd2 | VIU | | Video Post | | Video Encs |<---|-----VCLK |
> +R |-------| |----| Processing | | | | |
> + | osd2 | | | |---| Enci ------|----|-----VDAC------|
> +R |-------| CSC |----| Scalers | | Encp ------|----|----HDMI-TX----|
> +A | osd1 | | | Blenders | | Encl-------|----|---------------|
> +M |-------|______|----|____________| |____________| | |
> +___|______________________________________________________|_______________|
> +
> +
> +VIU: Video Input Unit
> +---------------------
> +
> +The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> +It fetches the frames addresses, stride and parameters from the "Canvas"
> memory.
> +This part is also in charge of the CSC (Colorspace Conversion).
> +It can handle 2 OSD Planes and 2 Video Planes.
> +
> +VPP: Video Processing Unit
Do you mean "Video Post Processing" ? In your diagram above Video Processing
Unit is abbreviated VPU and covers the VIU, VPP and encoders.
> +--------------------------
> +
> +The Video Processing Unit is in charge if the scaling and blending of the
> +various planes into a single pixel stream.
> +There is a special "pre-blending" used by the video planes with a dedicated
> +scaler and a "post-blending" to merge with the OSD Planes.
> +The OSD planes also have a dedicated scaler for one of the OSD.
> +
> +VENC: Video Encoders
> +--------------------
> +
> +The VENC is composed of the multiple pixel encoders :
> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> + - ENCP : Progressive Video Encoder for HDMI
> + - ENCL : LCD LVDS Encoder
> +The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and
> clock
> +tree and provides the scanout clock to the VPP and VIU.
> +The ENCI is connected to a single VDAC for Composite Output.
> +The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
> +
> +Device Tree Bindings:
> +---------------------
> +
> +VPU: Video Processing Unit
> +--------------------------
> +
> +Required properties:
> + - compatible: value should be different for each SoC family as :
> + - GXBB (S905) : "amlogic,meson-gxbb-vpu"
> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
> + - GXM (S912) : "amlogic,meson-gxm-vpu"
> + followed by the common "amlogic,meson-gx-vpu"
> + - reg: base address and size of he following memory-mapped regions :
> + - vpu
> + - hhi
> + - dmc
> + - reg-names: should contain the names of the previous memory regions
> + - interrupts: should contain the VENC Vsync interrupt number
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> + second port should be the output endpoints for VENC connectors.
> +
> +VENC CBVS Output
> +----------------------
> +
> +The VENC can output Composite/CVBS output via a decicated VDAC.
> +
> +Required properties:
> + - compatible: value must be one of:
> + - compatible: value should be different for each SoC family as :
One of those two lines is redundant.
> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
> + followed by the common "amlogic,meson-gx-venc-cvbs"
> +
No registers ? Are the encoders registers part of the VPU register space,
intertwined in a way that they can't be specified separately here ?
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> + first port should be the input endpoints, connected ot the VPU node.
> +
> +Example:
> +
> +venc_cvbs: venc-cvbs {
> + compatible = "amlogic,meson-gxbb-venc-cvbs";
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + enc_cvbs_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + venc_cvbs_in_vpu: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vpu_out_venc_cvbs>;
> + };
> + };
> + };
> +};
> +
> +vpu: vpu@d0100000 {
> + compatible = "amlogic,meson-gxbb-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "base", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vpu_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vpu_out_venc_cvbs: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&venc_cvbs_in_vpu>;
> + };
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Uwe Kleine-König @ 2016-11-28 8:09 UTC (permalink / raw)
To: Andrew Lunn, Rob Herring, Frank Rowand
Cc: Andreas Färber, netdev, linux-arm-kernel, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel, devicetree
In-Reply-To: <20161127231009.GA17704@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
Hello Andrew,
On Mon, Nov 28, 2016 at 12:10:09AM +0100, Andrew Lunn wrote:
> > Try to see it from my perspective: I see that some vf610 device I don't
> > have (found via `git grep marvell,mv88e6` or so) uses
> > "marvell,mv88e6085". I then assume it has that device on board. How
> > would I know it doesn't? Same for the other boards you mention.
> >
> > Unfortunately some of your replies are slightly cryptic. Had you simply
> > replied 'please just use "marvell,mv88e6085" instead', it would've been
> > much more clear what you want. (Same for extending the subject instead
> > of just pointing to some FAQ.)
>
> By reading the FAQ you have learnt more than me saying put the correct
> tree in the subject line. By asking you to explain why you need a
> compatible string, i'm trying to make you think, look at the code and
> understand it. In the future, you might think and understand the code
> before posting a patch, and then we all save time.
I agree to Andreas though, that it makes an school teacher impression.
Something like:
Please fix the subject. Check the FAQ for the details, which btw
is worth a read completely.
is IMHO better in this regard and once you found the problem there you
don't need to ask back if it's that what was meant.
> > So are you okay with patch 1/2 documenting the compatible? Then we could
> > drop 2/2 and use "marvell,mv88e6176", "marvell,mv88e6085" instead of
> > just the latter. Or would you rather drop both and keep the actual chip
> > a comment?
>
> A comment only please.
I still wonder (and didn't get an answer back when I asked about this)
why a comment is preferred here. For other devices I know it's usual and
requested by the maintainers to use:
compatible = "exact name", "earlyer device to match driver";
. This is more robust, documents the situation more formally and makes
it better greppable. The price to pay is only a few bytes in the dtb
which IMO is ok.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Sekhar Nori @ 2016-11-28 7:58 UTC (permalink / raw)
To: Tomi Valkeinen, Bartosz Golaszewski, Kevin Hilman,
Michael Turquette, Rob Herring, Frank Rowand, Mark Rutland,
Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
David Airlie, Laurent Pinchart
In-Reply-To: <953743fb-54f9-fa6f-bfdd-43d92271864f-l0cyMroinI0@public.gmane.org>
On Monday 28 November 2016 01:12 PM, Tomi Valkeinen wrote:
> On 28/11/16 07:24, Sekhar Nori wrote:
>> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
>>> It has been determined that the maximum resolution supported correctly
>>> by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput
>>> constraints we must filter out higher modes.
>>>
>>> Specify the max-bandwidth property for the display node for
>>> da850-based boards.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> ---
>>> arch/arm/boot/dts/da850.dtsi | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 8e30d9b..9b7c444 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -452,6 +452,7 @@
>>> compatible = "ti,da850-tilcdc";
>>> reg = <0x213000 0x1000>;
>>> interrupts = <52>;
>>> + max-bandwidth = <28800000>;
>>
>> If this is effectively the max pixel clock that the device supports,
>> then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns).
>
> There's a separate property for max-pixelclock. This one is maximum
> pixels per second (which does sound almost the same), but the doc says
> it's about the particular memory interface + LCDC combination.
DA850 supports both mDDR and DDR2, at slightly different speeds. So
memory bandwidth limitation is also board specific. This should probably
move to board file.
But I would like to know why using max-pixelclock is not good enough.
Have experiments shown that LCDC on DA850 LCDK underflows even if pixel
clock is below the datasheet recommendation?
Thanks,
Sekhar
--
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] dt-bindings: add MYIR Tech hardware vendor prefix
From: Vladimir Zapolskiy @ 2016-11-28 7:56 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
MYIR Tech Limited offers a range of ARM powered development boards and SoMs,
for details reference a list on http://elinux.org/Development_Platforms#ARM
or company's website http://myirtech.com
Signed-off-by: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 8a82bfe..3db548a 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -182,6 +182,7 @@ mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
mundoreader Mundo Reader S.L.
murata Murata Manufacturing Co., Ltd.
mxicy Macronix International Co., Ltd.
+myir MYIR Tech Limited
national National Semiconductor
nec NEC LCD Technologies, Ltd.
neonode Neonode Inc.
--
2.10.2
--
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] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Tomi Valkeinen @ 2016-11-28 7:42 UTC (permalink / raw)
To: Sekhar Nori, Bartosz Golaszewski, Kevin Hilman, Michael Turquette,
Rob Herring, Frank Rowand, Mark Rutland, Peter Ujfalusi,
Russell King
Cc: linux-devicetree, LKML, linux-drm, Jyri Sarha, arm-soc,
Laurent Pinchart
In-Reply-To: <8829c208-0674-43c0-8449-ef764071583f@ti.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1422 bytes --]
On 28/11/16 07:24, Sekhar Nori wrote:
> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
>> It has been determined that the maximum resolution supported correctly
>> by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput
>> constraints we must filter out higher modes.
>>
>> Specify the max-bandwidth property for the display node for
>> da850-based boards.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 8e30d9b..9b7c444 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -452,6 +452,7 @@
>> compatible = "ti,da850-tilcdc";
>> reg = <0x213000 0x1000>;
>> interrupts = <52>;
>> + max-bandwidth = <28800000>;
>
> If this is effectively the max pixel clock that the device supports,
> then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns).
There's a separate property for max-pixelclock. This one is maximum
pixels per second (which does sound almost the same), but the doc says
it's about the particular memory interface + LCDC combination.
But this 'max-bandwidth' does sound quite odd, as the it really should
be bytes, not pixels... Bad bindings again, which we just have to use.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 00/12] Initial Tegra186 support
From: Thierry Reding @ 2016-11-28 7:33 UTC (permalink / raw)
To: Pavel Machek
Cc: Sivaram Nair, devicetree-u79uwXL29TY76Z2rM5mHXA,
Peter De Schrijver, Timo Alho, Joseph Lo,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161126133927.GE20568-5NIqAleC692hcjWhqY66xCZi+YwRKgec@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
On Sat, Nov 26, 2016 at 02:39:27PM +0100, Pavel Machek wrote:
> Hi!
>
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > Hi everyone,
> >
> > This is a set of patches to add initial support for Tegra186. It is
> > based on Joseph's patches but I rewrote some of the drivers to be a
> > little easier to comprehend and maintain (hopefully). I've also
> > included clock and reset drivers as a proof of concept.
>
> Is there any phone/tablet on the market with this chipset?
I'm not aware of any. The chip is primarily targetted at automotive
use-cases and probably not suited for phones or tablets.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-28 6:56 UTC (permalink / raw)
To: Stephen Boyd, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Russell King, Linux-Kernel, Mark Brown,
linux-clk, Linux-ARM
Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
This patch adds it. This is based on devm_clk_get()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2
- update git log
drivers/clk/clkdev.c | 26 ++++++++++++++++++++++++++
include/linux/clk.h | 7 +++++++
2 files changed, 33 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 89cc700..93a613b 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -55,6 +55,32 @@ struct clk *of_clk_get(struct device_node *np, int index)
}
EXPORT_SYMBOL(of_clk_get);
+static void devm_of_clk_release(struct device *dev, void *res)
+{
+ clk_put(*(struct clk **)res);
+}
+
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ struct clk **ptr, *clk;
+
+ ptr = devres_alloc(devm_of_clk_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ clk = of_clk_get(np, index);
+ if (!IS_ERR(clk)) {
+ *ptr = clk;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return clk;
+}
+EXPORT_SYMBOL(devm_of_clk_get);
+
static struct clk *__of_clk_get_by_name(struct device_node *np,
const char *dev_id,
const char *name)
diff --git a/include/linux/clk.h b/include/linux/clk.h
index a89ba4e..33cd540 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -502,6 +502,8 @@ struct of_phandle_args;
#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index);
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
#else
@@ -509,6 +511,11 @@ static inline struct clk *of_clk_get(struct device_node *np, int index)
{
return ERR_PTR(-ENOENT);
}
+static inline struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ return ERR_PTR(-ENOENT);
+}
static inline struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
{
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Kevin Hilman @ 2016-11-28 6:16 UTC (permalink / raw)
To: Sekhar Nori
Cc: Mark Rutland, linux-devicetree, David Lechner, Tomi Valkeinen,
Michael Turquette, Russell King, linux-drm, LKML, Peter Ujfalusi,
Bartosz Golaszewski, Rob Herring, Jyri Sarha, Frank Rowand,
arm-soc, Laurent Pinchart
In-Reply-To: <20fbc946-d56c-31a3-4ae7-cf61df96a3c3@ti.com>
On Wed, Nov 23, 2016 at 9:03 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Thursday 24 November 2016 04:18 AM, David Lechner wrote:
>> On 11/23/2016 04:32 PM, Kevin Hilman wrote:
>>> David Lechner <david@lechnology.com> writes:
>>>
>>>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>>>>> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>>>>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>>>>
>>>>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>>>>> controller drivers to da850.dtsi.
>>>>>>>
>>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>>>> ---
>>>>>>> v1 -> v2:
>>>>>>> - moved the priority controller node above the cfgchip node
>>>>>>> - renamed added nodes to better reflect their purpose
>>>>>>>
>>>>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>>>>> 1 file changed, 8 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>>> index 1bb1f6d..412eec6 100644
>>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>>> @@ -210,6 +210,10 @@
>>>>>>> };
>>>>>>>
>>>>>>> };
>>>>>>> + prictrl: priority-controller@14110 {
>>>>>>> + compatible = "ti,da850-mstpri";
>>>>>>> + reg = <0x14110 0x0c>;
>>>>>>
>>>>>>
>>>>>> I think we should add status = "disabled"; here and let boards opt in.
>>>>>>
>>>>>>> + };
>>>>>>> cfgchip: chip-controller@1417c {
>>>>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>>>>> "simple-mfd";
>>>>>>> reg = <0x1417c 0x14>;
>>>>>>> @@ -451,4 +455,8 @@
>>>>>>> 1 0 0x68000000 0x00008000>;
>>>>>>> status = "disabled";
>>>>>>> };
>>>>>>> + memctrl: memory-controller@b0000000 {
>>>>>>> + compatible = "ti,da850-ddr-controller";
>>>>>>> + reg = <0xb0000000 0xe8>;
>>>>>>
>>>>>>
>>>>>> same here. status = "disabled";
>>>>>>
>>>>>>> + };
>>>>>>> };
>>>>>>>
>>>>>
>>>>> Hi David,
>>>>>
>>>>> I did that initially[1][2] and it was rejected by Kevin[3] and
>>>>> Laurent[4].
>>>>>
>>>>> FYI this patch has already been queued by Sekhar.
>>>>
>>>> Thanks. I did not see those threads.
>>>>
>>>> FYI to maintainers, having these enabled by default causes error
>>>> messages in the kernel log for other boards that are not supported by
>>>> the drivers.
>>>
>>> Then the driver is too noisy and should be cleaned up.
>>>
>>>> Since there is only one board that is supported and soon
>>>> to be 2 that are not, I would rather have this disabled by default to
>>>> avoid the error messages.
>>>
>>> IMO, what exactly are the error messages? Sounds like the driver is
>>> being too verbose, and calling things errors that are not really errors.
>>
>> It is just one line per driver.
>>
>> dev_err(dev, "no master priorities defined for this board\n");
>>
>> and
>>
>> dev_err(dev, "no settings defined for this board\n");
>>
>>
>> Since "ti,da850-lcdk" is the only board supported in these drivers, all
>> other boards will see these error messages.
>
> Thats pretty bad. Sorry about that. The original justification for
> keeping them enabled all the time was that they are in-SoC modules with
> no external dependencies (like IO lines or voltage rails) so they can be
> enabled on all boards that use DA850. While that remains true, the
> configuration itself is board specific.
>
> I think the error messages are still useful, so instead of silencing
> them, I think we should go back to keeping these nodes disabled by
> default and enabling only on boards which have support for it in the driver.
I don't have a strong preference for the enabled/disabled by default,
but I think the error messages are not error messages. It seems
perfectly reasonable for boards to accept the reset (or bootloader)
configuration of these registers, and not consider that an error.
Kevin
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* RE: BALANCE PAYMENT
From: coral-Yvmzju5463hBWQWeTLFoew @ 2016-11-28 6:03 UTC (permalink / raw)
Dear Sir/s,
Please see attached.
Thanks and regards,
Accounts Department
Al Omraniya Trading Co. LLC
P.O. Box: 10757, Al Khabaisi Area,
Deira 2, Dubai, U.A.E.
Tel: +971 4 268 2730 / Fax: +971 4 268 4117
--
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: BALANCE PAYMENT
From: coral-Yvmzju5463hBWQWeTLFoew @ 2016-11-28 6:03 UTC (permalink / raw)
Dear Sir/s,
Please see attached.
Thanks and regards,
Accounts Department
Al Omraniya Trading Co. LLC
P.O. Box: 10757, Al Khabaisi Area,
Deira 2, Dubai, U.A.E.
Tel: +971 4 268 2730 / Fax: +971 4 268 4117
--
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] ARM: dts: da850: enable the memctrl and mstpri nodes per board
From: Sekhar Nori @ 2016-11-28 5:30 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart, Robin Murphy,
Sudeep Holla
In-Reply-To: <1479979884-9624-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Thursday 24 November 2016 03:01 PM, Bartosz Golaszewski wrote:
> Currently the memory controller and master priorities drivers are
> enabled in da850.dtsi. For boards for which there are no settings
> defined, this makes these drivers emit error messages.
>
> Disable the nodes in da850.dtsi and only enable them for da850-lcdk -
> the only board that currently needs them.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Applied to v4.10/dt
Thanks,
Sekhar
--
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] ARM: dts: da850-lcdk: Add ethernet0 alias to DT
From: Sekhar Nori @ 2016-11-28 5:26 UTC (permalink / raw)
To: Fabien Parent, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: khilman-rdvid1DuHRBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8
In-Reply-To: <20161124143545.12817-1-fparent-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Thursday 24 November 2016 08:05 PM, Fabien Parent wrote:
> In order to avoid Linux generating a random mac address on every boot,
> add an ethernet0 alias that will allow u-boot to patch the dtb with
> the MAC address programmed into the EEPROM.
>
> Signed-off-by: Fabien Parent <fparent-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Applied to v4.10/dt. Thanks!
Regards,
Sekhar
--
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] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Sekhar Nori @ 2016-11-28 5:24 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart
In-Reply-To: <1480088245-8368-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
> It has been determined that the maximum resolution supported correctly
> by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput
> constraints we must filter out higher modes.
>
> Specify the max-bandwidth property for the display node for
> da850-based boards.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/da850.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 8e30d9b..9b7c444 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -452,6 +452,7 @@
> compatible = "ti,da850-tilcdc";
> reg = <0x213000 0x1000>;
> interrupts = <52>;
> + max-bandwidth = <28800000>;
If this is effectively the max pixel clock that the device supports,
then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns).
Thanks,
Sekhar
--
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 2/2] input: touchscreen: sample averaging for imx6ul_tsc
From: Dmitry Torokhov @ 2016-11-28 4:46 UTC (permalink / raw)
To: Fabio Estevam
Cc: Guy Shapiro, Fabio Estevam, Mark Rutland,
devicetree@vger.kernel.org, Haibo Chen, robh+dt@kernel.org,
linux-input, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAOMZO5CCtLdH9_5vGXfqg1rAizngVc_EWaoE+JfcfTrMmJT4xA@mail.gmail.com>
On Sun, Nov 27, 2016 at 10:39:10AM -0200, Fabio Estevam wrote:
> On Sun, Nov 27, 2016 at 5:44 AM, Guy Shapiro <guy.shapiro@mobi-wize.com> wrote:
> > The i.MX6UL internal touchscreen controller contains an option to
> > average upon samples. This feature reduces noise from the produced
> > touch locations.
> >
> > This patch adds sample averaging support to the imx6ul_tsc device
> > driver.
> >
> > Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Folded the binding patch into this one and applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 14/14] ASoC: add simple-graph-scu-card support
From: kbuild test robot @ 2016-11-28 4:36 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: kbuild-all-JC7UmRfGjtg, Rob Herring, Mark Brown, Linux-ALSA,
Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87zikkuxps.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3566 bytes --]
Hi Kuninori,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc7]
[cannot apply to glikely/devicetree/next asoc/for-next next-20161125]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-OF-graph-base-simple-card/20161128-111639
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/soc/generic/simple-graph-scu-card.c: In function 'asoc_simple_card_dai_link_of':
>> sound/soc/generic/simple-graph-scu-card.c:167:3: error: implicit declaration of function 'snd_soc_of_parse_audio_prefix_from_node' [-Werror=implicit-function-declaration]
snd_soc_of_parse_audio_prefix_from_node(&priv->snd_card,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/generic/simple-graph-scu-card.c: In function 'asoc_simple_card_parse_of':
>> sound/soc/generic/simple-graph-scu-card.c:214:8: error: implicit declaration of function 'snd_soc_of_parse_audio_routing_from_node' [-Werror=implicit-function-declaration]
ret = snd_soc_of_parse_audio_routing_from_node(&priv->snd_card,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/snd_soc_of_parse_audio_prefix_from_node +167 sound/soc/generic/simple-graph-scu-card.c
161 ret = asoc_simple_card_set_dailink_name(dev, dai_link,
162 "be.%s",
163 dai_link->codec_dai_name);
164 if (ret < 0)
165 return ret;
166
> 167 snd_soc_of_parse_audio_prefix_from_node(&priv->snd_card,
168 port->parent,
169 &priv->codec_conf,
170 dai_link->codec_of_node,
171 PREFIX "prefix");
172 }
173
174 ret = snd_soc_of_parse_tdm_slot(ep,
175 &dai_props->tx_slot_mask,
176 &dai_props->rx_slot_mask,
177 &dai_props->slots,
178 &dai_props->slot_width);
179 if (ret)
180 return ret;
181
182 ret = asoc_simple_card_canonicalize_dailink(dai_link);
183 if (ret < 0)
184 return ret;
185
186 dai_link->dai_fmt = daifmt;
187 dai_link->dpcm_playback = 1;
188 dai_link->dpcm_capture = 1;
189 dai_link->ops = &asoc_simple_card_ops;
190 dai_link->init = asoc_simple_card_dai_init;
191
192 dev_dbg(dev, "\t%s / %04x / %d\n",
193 dai_link->name,
194 dai_link->dai_fmt,
195 dai_props->sysclk);
196
197 return 0;
198 }
199
200 static int asoc_simple_card_parse_of(struct device_node *node,
201 struct simple_card_data *priv)
202 {
203 struct device *dev = simple_priv_to_dev(priv);
204 struct device *cpu_dev = dev->parent;
205 struct device_node *ports = of_graph_get_top_port(cpu_dev);
206 struct snd_soc_card *card = &priv->snd_card;
207 struct device_node *port, *cpu_ep, *r_cpu_ep, *codec_ep;
208 unsigned int daifmt = 0;
209 int i, ret, done;
210
211 if (!node)
212 return -EINVAL;
213
> 214 ret = snd_soc_of_parse_audio_routing_from_node(&priv->snd_card,
215 ports, PREFIX "routing");
216 if (ret)
217 return ret;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 12/14] ASoC: add simple-graph-card support
From: kbuild test robot @ 2016-11-28 4:19 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: kbuild-all-JC7UmRfGjtg, Rob Herring, Mark Brown, Linux-ALSA,
Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <8737icwcbd.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]
Hi Kuninori,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc7]
[cannot apply to glikely/devicetree/next asoc/for-next next-20161125]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-OF-graph-base-simple-card/20161128-111639
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/soc/generic/simple-graph-card.c: In function 'asoc_simple_card_parse_of':
>> sound/soc/generic/simple-graph-card.c:331:10: error: implicit declaration of function 'snd_soc_of_parse_audio_simple_widgets_from_node' [-Werror=implicit-function-declaration]
ret = snd_soc_of_parse_audio_simple_widgets_from_node(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/soc/generic/simple-graph-card.c:340:10: error: implicit declaration of function 'snd_soc_of_parse_audio_routing_from_node' [-Werror=implicit-function-declaration]
ret = snd_soc_of_parse_audio_routing_from_node(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/snd_soc_of_parse_audio_simple_widgets_from_node +331 sound/soc/generic/simple-graph-card.c
325 for_each_of_port(node, port) {
326 if (!of_graph_port_type_is_sound(port))
327 continue;
328
329 /* The off-codec widgets */
330 if (of_property_read_bool(port, PREFIX "widgets")) {
> 331 ret = snd_soc_of_parse_audio_simple_widgets_from_node(
332 &priv->snd_card,
333 port, PREFIX "widgets");
334 if (ret)
335 return ret;
336 }
337
338 /* DAPM routes */
339 if (of_property_read_bool(port, PREFIX "routing")) {
> 340 ret = snd_soc_of_parse_audio_routing_from_node(
341 &priv->snd_card,
342 port, PREFIX "routing");
343 if (ret)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56831 bytes --]
^ 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