* [PATCH v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: airlied, khilman, carlo
Cc: Neil Armstrong, dri-devel, linux-amlogic, linux-arm-kernel,
linux-kernel, victor.wan, jerry.cao, Xing.Xu, devicetree,
laurent.pinchart, daniel
In-Reply-To: <1480520625-13269-1-git-send-email-narmstrong@baylibre.com>
Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +++++++++++++++++++
.../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
8 files changed, 91 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..a27f881 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -356,5 +356,24 @@
status = "disabled";
};
};
+
+ vpu: vpu@d0100000 {
+ compatible = "amlogic,meson-gx-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port@0 {
+ reg = <0>;
+
+ cvbs_vdac_out: endpoint {
+ };
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 9696820..390f7db 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -142,6 +142,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -229,3 +240,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..44bdebf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -125,6 +125,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -234,3 +245,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index ac5ad3b..5353a20 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -506,3 +506,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index e99101a..7bd0538 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -117,6 +117,17 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -203,3 +214,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 9f89b99..5c7a8fa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -299,3 +299,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index d320727..5b99749 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -90,6 +90,17 @@
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -167,3 +178,7 @@
max-speed = <1000>;
};
};
+
+&cvbs_vdac_out {
+ remote-endpoint = <&cvbs_connector_in>;
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index c1974bb..eb2f0c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -112,3 +112,7 @@
};
};
};
+
+&vpu {
+ compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 15:43 UTC (permalink / raw)
To: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, daniel-/w4YWyX8dFk
In-Reply-To: <1480520625-13269-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../bindings/display/meson/meson-drm.txt | 101 +++++++++++++++++++++
1 file changed, 101 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..e52869a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
@@ -0,0 +1,101 @@
+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 Encoders |<---|-----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 Post Processing
+--------------------------
+
+The Video Post Processing is in charge of 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 first port should be connected to a CVBS connector endpoint if available.
+
+Example:
+
+tv: connector {
+ compatible = "composite-video-connector";
+ label = "cvbs";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+};
+
+vpu: vpu@d0100000 {
+ compatible = "amlogic,meson-gxbb-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port@0 {
+ cvbs_vdac_out: endpoint {
+ reg = <0>;
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+};
--
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] of: base: Export symbol of __of_find_all_nodes()
From: Laxman Dewangan @ 2016-11-30 15:47 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <581C1D7E.6030608-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Friday 04 November 2016 11:02 AM, Laxman Dewangan wrote:
>
> On Thursday 03 November 2016 07:46 PM, Rob Herring wrote:
>> On Thu, Nov 3, 2016 at 12:24 AM, Laxman Dewangan
>> <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>> On Thursday 03 November 2016 09:09 AM, Rob Herring wrote:
>>>> On Fri, Oct 28, 2016 at 6:28 AM, Laxman Dewangan
>>>> <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>> wrote:
>>>>> The function __of_find_all_nodes() is used in the public header
>>>>> linux/of.h and if any driver developed using this API then
>>>>> it reports error as unknown symbol if compiled as module.
>>>>>
>>>>> Export this APIs using EXPORT_SYMBOL() so that it can be used
>>>>> from driver compiled as module.
>>>> What driver needs this? This isn't really a function I'd expect
>>>> drivers to
>>>> use.
>>>>
>>> I am using the for loop for each node using the macro
>>> for_each_of_allnodes_from() which is define as
>>>
>>> #define for_each_of_allnodes_from(from, dn) \
>>> for (dn = __of_find_all_nodes(from); dn; dn =
>>> __of_find_all_nodes(dn))
>>>
>>> and this is using the above APIs.
>> And then what driver is using this define?
> We are developing the utils/testcase on OF interface echo system. In
> one of the testcase, we want to limit the node and property name
> length to 32 (max) as per ePAPR specs. This is needed to reuse the DT
> in multi-OS environment and so want to maintain ePAPR compliance here.
>
> We are using the above macro for iterating over each node.
>
>
Hi Rob,
Any comment or suggestion?
Thanks,
Laxman
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Thomas Petazzoni @ 2016-11-30 15:49 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin
In-Reply-To: <20161130140017.26307-2-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello,
On Wed, 30 Nov 2016 15:00:14 +0100, Romain Perier wrote:
> #ifdef CONFIG_I2C_PXA_SLAVE
> dev_info(&i2c->adap.dev, "Enabling slave mode\n");
> @@ -1234,6 +1238,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
> i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
> i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
> i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
> + i2c->fm_mask = pxa_reg_layout[i2c_type].fm ? pxa_reg_layout[i2c_type].fm : ICR_FM;
> + i2c->hs_mask = pxa_reg_layout[i2c_type].hs ? pxa_reg_layout[i2c_type].hs : ICR_HS;
These lines are too long according to checkpatch. What about using what
Wolfram originally suggested, i.e:
i2c->fm_mask = pxa_reg_layout[i2c_type].fm ?: ICR_FM;
which does exactly the same, but fits within 80 characters ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:56 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Xing.Xu, victor.wan, khilman, linux-kernel, dri-devel,
jerry.cao, carlo, linux-amlogic, linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
> 1 file changed, 101 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..e52869a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
> @@ -0,0 +1,101 @@
> +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 Post Processing
> +--------------------------
> +
> +The Video Post Processing is in charge of 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 first port should be connected to a CVBS connector endpoint if
> available.
This is a bit vague, I propose clarifying it with a description similar to the
one in the renesas,du.txt bindings.
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph
bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
Port 0 Port1 Port2 Port3
-----------------------------------------------------------------------------
R8A7779 (H1) DPAD 0 DPAD 1 - -
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
R8A7791 (M2-W) DPAD LVDS 0 - -
R8A7792 (V2H) DPAD 0 DPAD 1 - -
R8A7793 (M2-N) DPAD LVDS 0 - -
R8A7794 (E2) DPAD 0 DPAD 1 - -
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
R8A7796 (M3-W) DPAD HDMI LVDS -
(You should obviously replace the table with Amlogic data)
It doesn't matter if the current driver implementation only supports CVBS, the
DT bindings can already document the other ports.
> +
> +Example:
> +
> +tv: connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
I'd remove the label here, as it doesn't bring any additional information.
Unless the board you're using has a label for the connector, in case that
label should be used.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + port {
> + tv_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> +};
> +
> +vpu: vpu@d0100000 {
> + compatible = "amlogic,meson-gxbb-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port@0 {
> + cvbs_vdac_out: endpoint {
> + reg = <0>;
> + remote-endpoint = <&tv_connector_in>;
> + };
> + };
> +};
--
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 v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Laurent Pinchart @ 2016-11-30 15:58 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Xing.Xu, victor.wan, khilman, linux-kernel, dri-devel,
jerry.cao, carlo, linux-amlogic, linux-arm-kernel
In-Reply-To: <1480520625-13269-4-git-send-email-narmstrong@baylibre.com>
Hi Neil,
On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
I forgot to mention that the file should not be named meson-drm.txt as DRM is
a Linux-specific concept. You can name it meson.txt, but a better option would
be amlogic,meson.txt. By the way does it really need a subdirectory ?
> 1 file changed, 101 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/meson/meson-drm.txt
--
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 v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <2734274.BAOZxRirYz@avalon>
Hi Laurent,
On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>
> I forgot to mention that the file should not be named meson-drm.txt as DRM is
> a Linux-specific concept. You can name it meson.txt, but a better option would
> be amlogic,meson.txt. By the way does it really need a subdirectory ?
I took example of the sun4i layout the naming, and no it does not need a subdirector..
I will move it to amlogic,meson.txt, seems far better.
Thanks,
Neil
>> 1 file changed, 101 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>
--
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 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Laurent Pinchart @ 2016-11-30 16:02 UTC (permalink / raw)
To: Neil Armstrong
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <1480520625-13269-3-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Neil,
Thank you for the patch.
On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
> boards.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
> 8 files changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -356,5 +356,24 @@
> status = "disabled";
> };
> };
> +
> + vpu: vpu@d0100000 {
> + compatible = "amlogic,meson-gx-vpu";
> + reg = <0x0 0xd0100000 0x0 0x100000>,
> + <0x0 0xc883c000 0x0 0x1000>,
> + <0x0 0xc8838000 0x0 0x1000>;
> + reg-names = "vpu", "hhi", "dmc";
> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CVBS VDAC output port */
> + port@0 {
> + reg = <0>;
> +
> + cvbs_vdac_out: endpoint {
> + };
Endpoints require a remote-endpoint property. You should move the endpoint to
board DT files.
> + };
> + };
> };
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
> 9696820..390f7db 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -142,6 +142,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
Unless the board has a label for the connector (either on the board, on the
casing or in the user manual) I'd leave this out. Same comment for the other
boards.
Apart from that,
Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -229,3 +240,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
> 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -125,6 +125,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -234,3 +245,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -506,3 +506,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
> e99101a..7bd0538 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> @@ -117,6 +117,17 @@
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> &uart_AO {
> @@ -203,3 +214,7 @@
> clocks = <&clkc CLKID_FCLK_DIV4>;
> clock-names = "clkin0";
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -299,3 +299,7 @@
> <&clkc CLKID_FCLK_DIV2>;
> clock-names = "core", "clkin0", "clkin1";
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
> d320727..5b99749 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -90,6 +90,17 @@
> compatible = "mmc-pwrseq-emmc";
> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> };
> +
> + cvbs-connector {
> + compatible = "composite-video-connector";
> + label = "cvbs";
> +
> + port {
> + cvbs_connector_in: endpoint {
> + remote-endpoint = <&cvbs_vdac_out>;
> + };
> + };
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -167,3 +178,7 @@
> max-speed = <1000>;
> };
> };
> +
> +&cvbs_vdac_out {
> + remote-endpoint = <&cvbs_connector_in>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
> @@ -112,3 +112,7 @@
> };
> };
> };
> +
> +&vpu {
> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
> +};
--
Regards,
Laurent Pinchart
--
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 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <13104644.f9boR54smD@avalon>
Hi Laurent,
On 11/30/2016 04:56 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>> 1 file changed, 101 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..e52869a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>> @@ -0,0 +1,101 @@
[...]
>> +
>> +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 first port should be connected to a CVBS connector endpoint if
>> available.
>
> This is a bit vague, I propose clarifying it with a description similar to the
> one in the renesas,du.txt bindings.
>
> Required nodes:
>
> The connections to the VPU output video ports are modeled using the OF graph
> bindings specified in Documentation/devicetree/bindings/graph.txt.
>
> The following table lists for each supported model the port number
> corresponding to each DU output.
>
> Port 0 Port1 Port2 Port3
> -----------------------------------------------------------------------------
> R8A7779 (H1) DPAD 0 DPAD 1 - -
> R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
> R8A7791 (M2-W) DPAD LVDS 0 - -
> R8A7792 (V2H) DPAD 0 DPAD 1 - -
> R8A7793 (M2-N) DPAD LVDS 0 - -
> R8A7794 (E2) DPAD 0 DPAD 1 - -
> R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
> R8A7796 (M3-W) DPAD HDMI LVDS -
>
> (You should obviously replace the table with Amlogic data)
>
> It doesn't matter if the current driver implementation only supports CVBS, the
> DT bindings can already document the other ports.
>
Ok, it's a pretty table ! Will integrate this.
>> +
>> +Example:
>> +
>> +tv: connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> I'd remove the label here, as it doesn't bring any additional information.
> Unless the board you're using has a label for the connector, in case that
> label should be used.
Indeed, I already removed it in the dts.
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>
[...]
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 v2 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-30 16:07 UTC (permalink / raw)
To: Laurent Pinchart
Cc: airlied-cv59FeDIM0c, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <10006210.eA8q2ZWXP0@avalon>
On 11/30/2016 05:02 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Wednesday 30 Nov 2016 16:43:43 Neil Armstrong wrote:
>> Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
>> boards.
>>
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 ++++++++++++++++
>> .../arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 15 +++++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
>> 8 files changed, 91 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi index fc033c0..a27f881 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -356,5 +356,24 @@
>> status = "disabled";
>> };
>> };
>> +
>> + vpu: vpu@d0100000 {
>> + compatible = "amlogic,meson-gx-vpu";
>> + reg = <0x0 0xd0100000 0x0 0x100000>,
>> + <0x0 0xc883c000 0x0 0x1000>,
>> + <0x0 0xc8838000 0x0 0x1000>;
>> + reg-names = "vpu", "hhi", "dmc";
>> + interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + /* CVBS VDAC output port */
>> + port@0 {
>> + reg = <0>;
>> +
>> + cvbs_vdac_out: endpoint {
>> + };
>
> Endpoints require a remote-endpoint property. You should move the endpoint to
> board DT files.
OK, I was wondering, it looked dirty to me.
>
>> + };
>> + };
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts index
>> 9696820..390f7db 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> @@ -142,6 +142,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>
> Unless the board has a label for the connector (either on the board, on the
> casing or in the user manual) I'd leave this out. Same comment for the other
> boards.
OK,
Thanks,
Neil
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -229,3 +240,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi index 203be28..44bdebf
>> 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -125,6 +125,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -234,3 +245,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index ac5ad3b..5353a20 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
>> @@ -506,3 +506,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts index
>> e99101a..7bd0538 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> @@ -117,6 +117,17 @@
>> clocks = <&wifi32k>;
>> clock-names = "ext_clock";
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> &uart_AO {
>> @@ -203,3 +214,7 @@
>> clocks = <&clkc CLKID_FCLK_DIV4>;
>> clock-names = "clkin0";
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi index 9f89b99..5c7a8fa 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
>> @@ -299,3 +299,7 @@
>> <&clkc CLKID_FCLK_DIV2>;
>> clock-names = "core", "clkin0", "clkin1";
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts index
>> d320727..5b99749 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> @@ -90,6 +90,17 @@
>> compatible = "mmc-pwrseq-emmc";
>> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
>> };
>> +
>> + cvbs-connector {
>> + compatible = "composite-video-connector";
>> + label = "cvbs";
>> +
>> + port {
>> + cvbs_connector_in: endpoint {
>> + remote-endpoint = <&cvbs_vdac_out>;
>> + };
>> + };
>> + };
>> };
>>
>> /* This UART is brought out to the DB9 connector */
>> @@ -167,3 +178,7 @@
>> max-speed = <1000>;
>> };
>> };
>> +
>> +&cvbs_vdac_out {
>> + remote-endpoint = <&cvbs_connector_in>;
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi index c1974bb..eb2f0c3 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
>> @@ -112,3 +112,7 @@
>> };
>> };
>> };
>> +
>> +&vpu {
>> + compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
>> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
From: Mark Brown @ 2016-11-30 16:14 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: devicetree, linux-arm-msm, dri-devel
In-Reply-To: <1557992.zAjuUn6zCK@avalon>
[-- Attachment #1.1: Type: text/plain, Size: 1006 bytes --]
On Tue, Nov 29, 2016 at 09:37:31PM +0200, Laurent Pinchart wrote:
> On Tuesday 29 Nov 2016 11:01:25 Mark Brown wrote:
> > Please note that if you're going to CC me into a graphics thread there's
> > a good chance I will miss it, I get copied on quite a lot of graphics
> > related mail that's not really relevant so I often skip it. Changing
> > the subject line would help with that.
> I try to add a (CC'ing xxx) at the beginning of the e-mail to draw attention
> when a question is targetted at a particular person. If that's not enough I
> can change the subject, but might forget to do so from time to time. Or you
> could whitelist me, unless I'm already blacklisted ;-)
That helps if I open the mail (especially with large e-mails, I do
sometimes get bored looking for something relevant) but I also filter
just on subject lines - once you've been involved with a thread about a
topic people often seem to end up copying you for anything even vaguely
related unfortunately.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 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 v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-11-30 16:18 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, linux-arm-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits
In-Reply-To: <e5c36597-d917-0555-89cd-35f68087c1c5@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 188 bytes --]
> What do you prefer everything in one commit or two seperated commit ? (one
> including the new fields for fm_mask and another one to add support for
> a3700-i2c).
One commit is fine!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Kevin Hilman @ 2016-11-30 16:21 UTC (permalink / raw)
To: Neil Armstrong
Cc: Laurent Pinchart, airlied-cv59FeDIM0c,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <2e1b16c6-eec5-8cf3-5795-d6de02f36570-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> Hi Laurent,
> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>> Hi Neil,
>>
>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> ---
>>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>>
>> I forgot to mention that the file should not be named meson-drm.txt as DRM is
>> a Linux-specific concept. You can name it meson.txt, but a better option would
>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>
> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>
> I will move it to amlogic,meson.txt, seems far better.
>
To me, amlogic,meson is redundant. Probably should be amlogic,vpu.txt?
Kevin
--
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 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-30 16:22 UTC (permalink / raw)
To: Kevin Hilman
Cc: Laurent Pinchart, airlied-cv59FeDIM0c,
carlo-KA+7E9HrN00dnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
victor.wan-LpR1jeaWuhtBDgjK7y7TUQ,
jerry.cao-LpR1jeaWuhtBDgjK7y7TUQ, Xing.Xu-LpR1jeaWuhtBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <m21sxtkkg1.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 11/30/2016 05:21 PM, Kevin Hilman wrote:
> Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
>
>> Hi Laurent,
>> On 11/30/2016 04:58 PM, Laurent Pinchart wrote:
>>> Hi Neil,
>>>
>>> On Wednesday 30 Nov 2016 16:43:44 Neil Armstrong wrote:
>>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>> .../bindings/display/meson/meson-drm.txt | 101 ++++++++++++++++++
>>>
>>> I forgot to mention that the file should not be named meson-drm.txt as DRM is
>>> a Linux-specific concept. You can name it meson.txt, but a better option would
>>> be amlogic,meson.txt. By the way does it really need a subdirectory ?
>>
>> I took example of the sun4i layout the naming, and no it does not need a subdirector..
>>
>> I will move it to amlogic,meson.txt, seems far better.
>>
>
> To me, amlogic,meson is redundant. Probably should be amlogic,vpu.txt?
>
> Kevin
>
Yes, seems more coherent.
Thanks,
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 v3 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-11-30 16:23 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: Wolfram Sang, Patrice Chotard, Maxime Coquelin, Rob Herring,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, alexandre.torgue-qxv4g6HH51o
In-Reply-To: <CAOAejn0BZNH82kY_7UR1EjV7M1G+9jGihGb4-uCs9=XiPHUYxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
Hi,
> I was too busy in another project but now I am ready to complete the
> upstream of the STM32F4 I2C driver.
Nice.
> >> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
> >> +{
> >> + u32 clk_rate, cr2, freq;
> >> +
> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
> >> + cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
> >> +
> >> + clk_rate = clk_get_rate(i2c_dev->clk);
> >> + freq = clk_rate / MHZ_TO_HZ;
> >> +
> >> + if (freq > STM32F4_I2C_MAX_FREQ)
> >> + freq = STM32F4_I2C_MAX_FREQ;
> >> + if (freq < STM32F4_I2C_MIN_FREQ)
> >> + freq = STM32F4_I2C_MIN_FREQ;
> >
> > clamp() to enforce the range?
> Sorry but what do you mean by "clamp()" ?
The kernel has a clamp() function which would fit this purpose, I think.
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: juno: Correct PCI IO window
From: Sudeep Holla @ 2016-11-30 16:29 UTC (permalink / raw)
To: Jeremy Linton, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Sudeep Holla, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
liviu.dudau-5wv7dgnIgG8, lorenzo.pieralisi-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8
In-Reply-To: <1480452310-29286-1-git-send-email-jeremy.linton-5wv7dgnIgG8@public.gmane.org>
Hi Jeremy,
On 29/11/16 20:45, Jeremy Linton wrote:
> The PCIe root complex on Juno translates the MMIO mapped
> at 0x5f800000 to the PIO address range starting at 0
> (which is common because PIO addresses are generally < 64k).
> Correct the DT to reflect this.
>
I have another DT fix that I have asked ARM-SoC guys to pick up directly
from the list. If that doesn't happen, I will send PR including both.
If that happens then we need to send this to them to be picked directly.
At this point I want to wait for couple of days to avoid confusion.
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-11-30 17:07 UTC (permalink / raw)
To: Wolfram Sang
Cc: Wolfram Sang, Patrice Chotard, Maxime Coquelin, Rob Herring,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, alexandre.torgue-qxv4g6HH51o
In-Reply-To: <20161130162353.GC1441@katana>
Hi,
2016-11-30 17:23 GMT+01:00 Wolfram Sang <wsa-dev-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>:
> Hi,
>
>> I was too busy in another project but now I am ready to complete the
>> upstream of the STM32F4 I2C driver.
>
> Nice.
>
>> >> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
>> >> +{
>> >> + u32 clk_rate, cr2, freq;
>> >> +
>> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
>> >> + cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
>> >> +
>> >> + clk_rate = clk_get_rate(i2c_dev->clk);
>> >> + freq = clk_rate / MHZ_TO_HZ;
>> >> +
>> >> + if (freq > STM32F4_I2C_MAX_FREQ)
>> >> + freq = STM32F4_I2C_MAX_FREQ;
>> >> + if (freq < STM32F4_I2C_MIN_FREQ)
>> >> + freq = STM32F4_I2C_MIN_FREQ;
>> >
>> > clamp() to enforce the range?
>> Sorry but what do you mean by "clamp()" ?
>
> The kernel has a clamp() function which would fit this purpose, I think.
Ok I got it. I will fix it in the V4.
Thanks
>
> Regards,
>
> Wolfram
>
--
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: Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Icenowy Zheng @ 2016-11-30 17:24 UTC (permalink / raw)
To: moinejf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Laurent Pinchart
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Dave Airlie, Maxime Ripard, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161130102757.9eec1f7f3377d0f4787e3829-GANU6spQydw@public.gmane.org>
30.11.2016, 17:28, "Jean-Francois Moine" <moinejf@free.fr>:
> On Wed, 30 Nov 2016 10:20:21 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
>> > Well, I don't see what this connector can be.
>> > May you give me a DT example?
>>
>> Sure.
>>
>> arch/arm/boot/dts/r8a7791-koelsch.dts
>>
>> /* HDMI encoder */
>>
>> hdmi@39 {
>> compatible = "adi,adv7511w";
>> reg = <0x39>;
>> interrupt-parent = <&gpio3>;
>> interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
>>
>> adi,input-depth = <8>;
>> adi,input-colorspace = "rgb";
>> adi,input-clock = "1x";
>> adi,input-style = <1>;
>> adi,input-justification = "evenly";
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@0 {
>> reg = <0>;
>> adv7511_in: endpoint {
>> remote-endpoint = <&du_out_rgb>;
>> };
>> };
>>
>> port@1 {
>> reg = <1>;
>> adv7511_out: endpoint {
>> remote-endpoint = <&hdmi_con>;
>> };
>> };
>> };
>> };
>>
>> /* HDMI connector */
>>
>> hdmi-out {
>> compatible = "hdmi-connector";
>> type = "a";
>>
>> port {
>> hdmi_con: endpoint {
>> remote-endpoint = <&adv7511_out>;
>> };
>> };
>> };
>
> Hi Laurent,
>
> Sorry for I don't see the interest:
> - it is obvious that the HDMI connector is a 'hdmi-connector'!
Yes, it means the wire between the HDMI pins on the SoC and the connector ;-)
> - the physical connector type may be changed on any board by a soldering
> iron or a connector to connector cable.
I can always alter the devices on a board ;-)
But I should also alter the dt after altering the board.
> - what does the software do with the connector type?
> - why not to put the connector information in the HDMI device?
>
> And, if I follow you, the graph of ports could also be used to describe
> the way the various parts of the SoCs are powered, to describe the pin
> connections, to describe the USB connectors, to describe the board
> internal hubs and bridges...
>
> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 1/6] net: ethernet: ti: netcp: add support of cpts
From: Grygorii Strashko @ 2016-11-30 17:31 UTC (permalink / raw)
To: Richard Cochran
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Murali Karicheri, Wingman Kwok
In-Reply-To: <20161130094441.GB28680-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 11/30/2016 03:44 AM, Richard Cochran wrote:
> On Mon, Nov 28, 2016 at 05:04:23PM -0600, Grygorii Strashko wrote:
>> @@ -678,6 +744,9 @@ struct gbe_priv {
>> int num_et_stats;
>> /* Lock for updating the hwstats */
>> spinlock_t hw_stats_lock;
>> +
>> + int cpts_registered;
>
> The usage of this counter is racy.
>
>> + struct cpts *cpts;
>> };
>
> This ++ and -- business ...
>
>> +static void gbe_register_cpts(struct gbe_priv *gbe_dev)
>> +{
>> + if (!gbe_dev->cpts)
>> + return;
>> +
>> + if (gbe_dev->cpts_registered > 0)
>> + goto done;
>> +
>> + if (cpts_register(gbe_dev->cpts)) {
>> + dev_err(gbe_dev->dev, "error registering cpts device\n");
>> + return;
>> + }
>> +
>> +done:
>> + ++gbe_dev->cpts_registered;
>> +}
>> +
>> +static void gbe_unregister_cpts(struct gbe_priv *gbe_dev)
>> +{
>> + if (!gbe_dev->cpts || (gbe_dev->cpts_registered <= 0))
>> + return;
>> +
>> + if (--gbe_dev->cpts_registered)
>> + return;
>> +
>> + cpts_unregister(gbe_dev->cpts);
>> +}
>
> is invoked from your open() and close() methods, but those methods
> are not serialized among multiple ports.
>
ok. Seems my assumption that ndo_open/ndo_close serialized by rtnl_lock is incorrect. Right?
net_device_ops.ndo_open ->
netcp_ndo_open
gbe_open
gbe_register_cpts
--
regards,
-grygorii
--
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: Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Icenowy Zheng @ 2016-11-30 17:33 UTC (permalink / raw)
To: moinejf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Laurent Pinchart
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Dave Airlie, Maxime Ripard, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161130114415.2280151e2965280733a629e5-GANU6spQydw@public.gmane.org>
30.11.2016, 18:44, "Jean-Francois Moine" <moinejf-GANU6spQydw@public.gmane.org>:
> On Wed, 30 Nov 2016 11:52:25 +0200
> Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
>
>> Hi Jean-François,
>>
>> On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
>> > On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
>> > >> Well, I don't see what this connector can be.
>> > >> May you give me a DT example?
>> > >
>> > > Sure.
>> > >
>> > > arch/arm/boot/dts/r8a7791-koelsch.dts
>> > >
>> > > /* HDMI encoder */
>
> [snip]
>> > > /* HDMI connector */
>> > >
>> > > hdmi-out {
>> > > compatible = "hdmi-connector";
>> > > type = "a";
>> > >
>> > > port {
>> > > hdmi_con: endpoint {
>> > > remote-endpoint = <&adv7511_out>;
>> > > };
>> > > };
>> > > };
>
> [snip]
>> > - what does the software do with the connector type?
>>
>> That's up to the software to decide, the DT bindings should describe the
>> hardware in the most accurate and usable way for the OS as possible. One of my
>> longer term goals is to add connector drivers to handle DDC and HPD when
>> they're not handled by the encoder (they are in the above example).
>>
>> If the DDC was connected to a general-purpose I2C bus of the SoC, and the HPD
>> to a GPIO, we would have
>>
>> hdmi-out {
>> compatible = "hdmi-connector";
>> type = "a";
>> /* I2C bus and GPIO references are made up for the example */
>> ddc-i2c-bus = <&i2c4>;
>> hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>>
>> port {
>> hdmi_con: endpoint {
>> remote-endpoint = <&adv7511_out>;
>> };
>> };
>> };
>>
>> and both HPD and EDID reading should be handled by the connector driver.
>
> [snip]
>
> Hi Laurent,
>
> OK. I understand. This connector complexity should be added in all DTs,
> and the same code would be used.
>
> Actually, for component binding, I use drm_of_component_probe():
>
> - from the DRM master, loop on the "ports" phandle array and bind the
> CRTCs,
>
> - for each CRTC, loop on the first remote port level and bind the
> encoders/connectors
>
> Now, this should be:
>
> - from the DRM master, loop on the first remote ports level and bind
> the CRTCs,
>
> - for each CRTC, loop on the second remote port level and bind the
> encoders (and bridges?),
>
> - for each encoder, loop on the third remote port level and bind the
> connectors.
>
> Then, it would be nice to have a generic function for doing this job.
>
> Otherwise, from your description:
>
>> hdmi-out {
>> compatible = "hdmi-connector";
>> type = "a";
>> /* I2C bus and GPIO references are made up for the example */
>> ddc-i2c-bus = <&i2c4>;
>> hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>
> the "hdmi-connector" is a big piece of software. It must handle a lot
> of more and more exotic connectors.
> So, I hope that you have written a "simple-hdmi-connector" which does
> nothing but setting the connector type.
> Where is it?
I suddenly thought about something...
If a DVI connector instead of a HDMI connector is soldered, how should such a
device tree be written?
How about solder a HDMI-to-VGA bridge on the board? (Maybe there should be
"dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge" drivers?)
>
> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 2/6] net: ethernet: ti: cpts: add support for ext rftclk selection
From: Grygorii Strashko @ 2016-11-30 17:35 UTC (permalink / raw)
To: Richard Cochran
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Murali Karicheri, Wingman Kwok
In-Reply-To: <20161130095632.GC28680-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 11/30/2016 03:56 AM, Richard Cochran wrote:
> On Mon, Nov 28, 2016 at 05:04:24PM -0600, Grygorii Strashko wrote:
>> Some CPTS instances, which can be found on KeyStone 2 1/10G Ethernet
>> Switch Subsystems, can control an external multiplexer that selects
>> one of up to 32 clocks for time sync reference (RFTCLK). This feature
>> can be configured through CPTS_RFTCLK_SEL register (offset: x08).
>>
>> Hence, introduce optional DT cpts_rftclk_sel poperty wich, if present,
>> will specify CPTS reference clock. The cpts_rftclk_sel should be
>> omitted in DT if HW doesn't support this feature. The external fixed
>> rate clocks can be defined in board files as "fixed-clock".
>
> Can't you implement this using the clock tree, rather than an ad-hoc
> DT property?
>
I've thought about this, but decided to move forward with this impl
which is pretty simple. I will try.
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: atull @ 2016-11-30 17:45 UTC (permalink / raw)
To: Joshua Clayton
Cc: Mark Rutland, Moritz Fischer, devicetree, Russell King,
linux-kernel, Rob Herring, linux-arm-kernel
In-Reply-To: <e193572d7746e6f6b8666da7ac0f54031fed5214.1480467185.git.stillcompiling@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Clayton,
I just have a few minor one line changes below. Only one
is operational, I should have caught that earlier.
> cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
> interface on Altera Cyclone FPGAS.
>
> This is one of the simpler ways to set up an FPGA at runtime.
> The signal interface is close to unidirectional spi with lsb first.
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/cyclone-ps-spi.c | 176 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 184 insertions(+)
> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index cd84934..2462707 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,13 @@ config FPGA
>
> if FPGA
>
> +config FPGA_MGR_CYCLONE_PS_SPI
> + tristate "Altera Cyclone FPGA Passive Serial over SPI"
> + depends on SPI
> + help
> + FPGA manager driver support for Altera Cyclone using the
> + passive serial interface over SPI
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6..8f93930 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -6,5 +6,6 @@
> obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
> new file mode 100644
> index 0000000..57a520d
> --- /dev/null
> +++ b/drivers/fpga/cyclone-ps-spi.c
> @@ -0,0 +1,176 @@
> +/**
> + * Copyright (c) 2015 United Western Technologies, Corporation
> + *
> + * Joshua Clayton <stillcompiling@gmail.com>
> + *
> + * Manage Altera fpga firmware that is loaded over spi.
> + * Firmware must be in binary "rbf" format.
> + * Works on Cyclone V. Should work on cyclone series.
> + * May work on other Altera fpgas.
> + *
> + */
> +
> +#include <linux/bitrev.h>
> +#include <linux/delay.h>
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/spi/spi.h>
> +#include <linux/sizes.h>
> +
> +#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
> +#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
> +#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
> +
> +struct cyclonespi_conf {
> + struct gpio_desc *config;
> + struct gpio_desc *status;
> + struct spi_device *spi;
> +};
> +
> +static const struct of_device_id of_ef_match[] = {
> + { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, of_ef_match);
> +
> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
> +{
> + return mgr->state;
> +}
This function gets called once to initialize mgr->state in
fpga_mgr_register(). So it should at least return the state the FPGA
is at then. If it is unknown, it can just return
FPGA_MGR_STATE_UNKNOWN.
> +
> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
Minor, but please fix the indentation of 'const' to match that of
'struct' above. checkpatch.pl is probably issuing warnings
about that.
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + int i;
> +
> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> + return -EINVAL;
> + }
> +
> + gpiod_set_value(conf->config, 0);
> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
> + if (gpiod_get_value(conf->status) == 1) {
> + dev_err(&mgr->dev, "Status pin should be low.\n");
> + return -EIO;
> + }
> +
> + gpiod_set_value(conf->config, 1);
> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
> + if (gpiod_get_value(conf->status))
> + return 0;
> + }
> +
> + dev_err(&mgr->dev, "Status pin not ready.\n");
> + return -EIO;
> +}
> +
> +static void rev_buf(void *buf, size_t len)
> +{
> + u32 *fw32 = (u32 *)buf;
> + const u32 *fw_end = (u32 *)(buf + len);
> +
> + /* set buffer to lsb first */
> + while (fw32 < fw_end) {
> + *fw32 = bitrev8x4(*fw32);
> + fw32++;
> + }
> +}
> +
> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
Please fix alignment here also.
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + const char *fw_data = buf;
> + const char *fw_data_end = fw_data + count;
> +
> + while (fw_data < fw_data_end) {
> + int ret;
> + size_t stride = min(fw_data_end - fw_data, SZ_4K);
> +
> + rev_buf((void *)fw_data, stride);
> + ret = spi_write(conf->spi, fw_data, stride);
> + if (ret) {
> + dev_err(&mgr->dev, "spi error in firmware write: %d\n",
> + ret);
> + return ret;
> + }
> + fw_data += stride;
> + }
> +
> + return 0;
> +}
> +
> +static int cyclonespi_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> +
> + if (gpiod_get_value(conf->status) == 0) {
> + dev_err(&mgr->dev, "Error during configuration.\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops cyclonespi_ops = {
> + .state = cyclonespi_state,
> + .write_init = cyclonespi_write_init,
> + .write = cyclonespi_write,
> + .write_complete = cyclonespi_write_complete,
> +};
> +
> +static int cyclonespi_probe(struct spi_device *spi)
> +{
> + struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
> + GFP_KERNEL);
> +
> + if (!conf)
> + return -ENOMEM;
> +
> + conf->spi = spi;
> + conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_LOW);
> + if (IS_ERR(conf->config)) {
> + dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
> + PTR_ERR(conf->config));
> + return PTR_ERR(conf->config);
> + }
> +
> + conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
> + if (IS_ERR(conf->status)) {
> + dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
> + PTR_ERR(conf->status));
> + return PTR_ERR(conf->status);
> + }
> +
> + return fpga_mgr_register(&spi->dev,
> + "Altera Cyclone PS SPI FPGA Manager",
> + &cyclonespi_ops, conf);
> +}
> +
> +static int cyclonespi_remove(struct spi_device *spi)
> +{
> + fpga_mgr_unregister(&spi->dev);
> +
> + return 0;
> +}
> +
> +static struct spi_driver cyclonespi_driver = {
> + .driver = {
> + .name = "cyclone-ps-spi",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(of_ef_match),
> + },
> + .probe = cyclonespi_probe,
> + .remove = cyclonespi_remove,
> +};
> +
> +module_spi_driver(cyclonespi_driver)
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
> +MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
> --
> 2.9.3
>
>
Thanks,
Alan
^ permalink raw reply
* [PATCH] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Laurent Pinchart @ 2016-11-30 17:58 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren,
Benoît Cousson
The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
connected to port 2 of the OMAP EHCI controller. The board however has
no EEPROM to store the ethernet MAC address, which is programmed by the
boot loader.
To allow Linux to use the same MAC address as the boot loader (or for
that matter any fixed MAC address), we need a node in the device tree
for the ethernet controller that the boot loader can update at runtime
with a local-mac-address property. Add it, along with an alias for the
ethernet controller to let the boot loader locate it easily.
Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 85e297ed0ea1..75ac56cdf954 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -27,6 +27,7 @@
aliases {
display0 = &dvi0;
display1 = &tv0;
+ ethernet = ðernet;
};
leds {
@@ -348,6 +349,21 @@
&usbhsehci {
phys = <0 &hsusb2_phy>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb2@2 {
+ compatible = "usb424,9514";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb424,ec00";
+ reg = <1>;
+ };
+ };
};
&vaux2 {
--
Regards,
Laurent Pinchart
--
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 v3 0/3] Altera Cyclone Passive Serial SPI FPGA Manager
From: atull @ 2016-11-30 18:01 UTC (permalink / raw)
To: Joshua Clayton
Cc: Moritz Fischer, Rob Herring, Mark Rutland, Russell King,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.1480467185.git.stillcompiling@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Joshua,
The DT bindings will need Rob Herring's ack. The bitrev.h
changes will need Russell King's ack.
I've made some comments on patch 3/3 but it looks good to me
besides that.
Once we have those other acks, please submit your v4 including fixes
for my comments and whatever else comes up. I'm hoping it will be
minor and with that done, v4 can go in.
When you send in v4, please also cc our new mailing list that Moritz
made: linux-fpga@vger.kernel.org
Alan
> This series adds an FPGA manager for Altera cyclone FPGAs
> that can program them using an spi port and a couple of gpios, using
> Alteras passive serial protocol.
>
> Changes from v2:
>
> - Merged patch 3 and 4 as suggested in review by Moritz Fischer
> - Changed FPGA_MIN_DELAY from 250 to 50 ms is the time advertized by
> Altera. This now works, as we don't assume it is done
>
> Changes from v1:
> - Changed the name from cyclone-spi-fpga-mgr to cyclone-ps-spi-fpga-mgr
> This name change was requested by Alan Tull, to be specific about which
> programming method is being employed on the fpga.
> - Changed the name of the reset-gpio to config-gpio to closer match the
> way the pins are described in the Altera manual
> - Moved MODULE_LICENCE, _AUTHOR, and _DESCRIPTION to the bottom
>
> - Added a bitrev8x4() function to the bitrev headers and implemented ARM
> const, runtime, and ARM specific faster versions (This may end up
> needing to be a standalone patch)
>
> - Moved the bitswapping into cyclonespi_write(), as requested.
> This falls short of my desired generic lsb first spi support, but is a step
> in that direction.
>
> - Fixed whitespace problems introduced during refactoring
>
> - Replaced magic number for initial delay with a descriptive macro
> - Poll the fpga to see when it is ready rather than a fixed 1 ms sleep
>
> Joshua Clayton (3):
> lib: add bitrev8x4()
> doc: dt: add cyclone-spi binding document
> fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
>
> .../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 23 +++
> arch/arm/include/asm/bitrev.h | 5 +
> drivers/fpga/Kconfig | 7 +
> drivers/fpga/Makefile | 1 +
> drivers/fpga/cyclone-ps-spi.c | 176 +++++++++++++++++++++
> include/linux/bitrev.h | 26 +++
> 6 files changed, 238 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>
> --
> 2.9.3
>
>
^ permalink raw reply
* Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Jernej Skrabec @ 2016-11-30 18:04 UTC (permalink / raw)
To: linux-sunxi
Cc: jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w, moinejf-GANU6spQydw,
airlied-cv59FeDIM0c, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
In-Reply-To: <3152670.pRMCOA29o4@avalon>
[-- Attachment #1.1: Type: text/plain, Size: 4453 bytes --]
Hi Laurent,
Dne sreda, 30. november 2016 09.08.22 UTC+1 je oseba Laurent Pinchart
napisala:
>
> Hi Jernej,
>
> On Tuesday 29 Nov 2016 15:24:25 Jernej Skrabec wrote:
> > Dne torek, 29. november 2016 23.56.31 UTC+1 je oseba Laurent Pinchart
> > napisala:
> > > On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote:
> > >> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxime Ripard
> > > napisala:
> > >>> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> > >>>> This patchset series adds HDMI video support to the Allwinner
> > >>>> sun8i SoCs which include the display engine 2 (DE2).
> > >>>> The driver contains the code for the A83T and H3 SoCs, and
> > >>>> some H3 boards, but it could be used/extended for other SoCs
> > >>>> (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> > >>>
> > >>> Honestly, I'm getting a bit worried by the fact that you ignore
> > >>> reviews.
> > >>>
> > >>> On the important reviews that you got that are to be seen as major
> > >>> issues that block the inclusion, we have:
> > >>> - The fact that the HDMI driver is actually just a designware IP,
> > >>> and while you should use the driver that already exists, you
> just
> > >>> duplicated all that code.
> > >>
> > >> That might be hard thing to do. A83T fits perfectly, but H3 and newer
> > >> SoCs do not. They are using completely different HDMI phy. Decoupling
> > >> controller and phy code means rewritting a good portion of the code,
> > >> unless some tricks are applied, like calling phy function pointers,
> if
> > >> they are defined.
> > >
> > > Same HDMI TX but different HDMI TX PHY ? Kieran is working on
> decoupling
> > > the PHY configuration code for a Renesas SoC, that might be of
> interest to
> > > you.
> >
> > Exactly. I'm developing only U-Boot driver, but Jean-Francois will
> probably
> > have more interest in this.
>
> We'll post patches as soon as they're ready.
>
Great. Is datasheet public? I'm curious if HDMI PHY is by any chance
similar.
>
> By the way, do you know if the H3 and newer SoCs use a different PHY from
> Synopsys, or a custom PHY developed by Allwinner ?
>
>
Unfortunatelly, noone managed to identify PHY and Alliwinner never released
a
bit of information about HDMI. Does config2_id code 0xFE (PHY type) tell you
anything?
> > >> Register addresses also differ, but that can be easily solved by
> using
> > >> undocumented magic value to restore them.
> > >
> > > I love that :-)
> >
> > Is it allowed to use magic number which was found in binary blob? I'm
> new in
> > all this.
>
> I don't really see a problem with that, we have many drivers in the kernel
> that have been developed through reverse-engineering. You should not
> include
> large pieces of code that have been obtained through decompilation of a
> proprietary binary blob as those could be protected by copyright, but
> writing
> to undocumented registers based on information found through usage of a
> binary
> driver isn't a problem. (Please remember that I'm not a lawyer though)
>
> > >>> - The fact that you ignored Rob (v6) and I (v5) comment on using
> OF
> > >>> graph to model the connection between the display engine and the
> > >>> TCON. Something that Laurent also pointed out in this version.
> > >>>
> > >>> - The fact that you ignored that you needed an HDMI connector node
> > >>> as a child of the HDMI controller. This has been reported by Rob
> > >>> (v6) and yet again in this version by Laurent.
> > >>>
> > >>> - And finally the fact that we can't have several display engine
> in
> > >>> parallel, if needs be. This has happened in the past already on
> > >>> Allwinner SoCs, so it's definitely something we should consider
> in
> > >>> the DT bindings, since we can't break them.
> > >>>
> > >>> Until those are fixed, I cannot see how this driver can be merged,
> > >>> unfortunately.
>
Best regards,
Jernej Škrabec
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #1.2: Type: text/html, Size: 5701 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