Devicetree
 help / color / mirror / Atom feed
* [PATCH 2/5] drm: zte: move struct vou_inf into zx_vou driver
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
  To: dri-devel
  Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
	Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>

From: Shawn Guo <shawn.guo@linaro.org>

Although data in struct vou_inf is defined per output device, it doesn't
belong to the device itself but VOU control module.  All these data can
just be defined in VOU driver, and output device driver only needs to
invoke VOU driver function with device ID to enable/disable specific
output device.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 drivers/gpu/drm/zte/zx_hdmi.c | 12 ++----------
 drivers/gpu/drm/zte/zx_vou.c  | 31 ++++++++++++++++++++++++-------
 drivers/gpu/drm/zte/zx_vou.h  | 11 ++---------
 3 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index 6bf6c364811e..2f1e278ab50e 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -53,13 +53,6 @@ struct zx_hdmi {
 
 #define to_zx_hdmi(x) container_of(x, struct zx_hdmi, x)
 
-static const struct vou_inf vou_inf_hdmi = {
-	.id = VOU_HDMI,
-	.data_sel = VOU_YUV444,
-	.clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
-	.clocks_sel_bits = BIT(13) | BIT(2),
-};
-
 static inline u8 hdmi_readb(struct zx_hdmi *hdmi, u16 offset)
 {
 	return readl_relaxed(hdmi->mmio + offset * 4);
@@ -238,14 +231,14 @@ static void zx_hdmi_encoder_enable(struct drm_encoder *encoder)
 
 	zx_hdmi_hw_enable(hdmi);
 
-	vou_inf_enable(hdmi->inf, encoder->crtc);
+	vou_inf_enable(VOU_HDMI, encoder->crtc);
 }
 
 static void zx_hdmi_encoder_disable(struct drm_encoder *encoder)
 {
 	struct zx_hdmi *hdmi = to_zx_hdmi(encoder);
 
-	vou_inf_disable(hdmi->inf, encoder->crtc);
+	vou_inf_disable(VOU_HDMI, encoder->crtc);
 
 	zx_hdmi_hw_disable(hdmi);
 
@@ -523,7 +516,6 @@ static int zx_hdmi_bind(struct device *dev, struct device *master, void *data)
 
 	hdmi->dev = dev;
 	hdmi->drm = drm;
-	hdmi->inf = &vou_inf_hdmi;
 
 	dev_set_drvdata(dev, hdmi);
 
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 8c4f0e2885f3..c48704b4425a 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -158,6 +158,21 @@ struct zx_vou_hw {
 	struct zx_crtc *aux_crtc;
 };
 
+struct vou_inf {
+	enum vou_inf_id id;
+	enum vou_inf_data_sel data_sel;
+	u32 clocks_en_bits;
+	u32 clocks_sel_bits;
+};
+
+static struct vou_inf vou_infs[] = {
+	[VOU_HDMI] = {
+		.data_sel = VOU_YUV444,
+		.clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
+		.clocks_sel_bits = BIT(13) | BIT(2),
+	},
+};
+
 static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
 {
 	struct zx_crtc *zcrtc = to_zx_crtc(crtc);
@@ -165,20 +180,21 @@ static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
 	return zcrtc->vou;
 }
 
-void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc)
+void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc)
 {
 	struct zx_crtc *zcrtc = to_zx_crtc(crtc);
 	struct zx_vou_hw *vou = zcrtc->vou;
+	struct vou_inf *inf = &vou_infs[id];
 	bool is_main = zcrtc->chn_type == VOU_CHN_MAIN;
-	u32 data_sel_shift = inf->id << 1;
+	u32 data_sel_shift = id << 1;
 
 	/* Select data format */
 	zx_writel_mask(vou->vouctl + VOU_INF_DATA_SEL, 0x3 << data_sel_shift,
 		       inf->data_sel << data_sel_shift);
 
 	/* Select channel */
-	zx_writel_mask(vou->vouctl + VOU_INF_CH_SEL, 0x1 << inf->id,
-		       zcrtc->chn_type << inf->id);
+	zx_writel_mask(vou->vouctl + VOU_INF_CH_SEL, 0x1 << id,
+		       zcrtc->chn_type << id);
 
 	/* Select interface clocks */
 	zx_writel_mask(vou->vouctl + VOU_CLK_SEL, inf->clocks_sel_bits,
@@ -189,15 +205,16 @@ void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc)
 		       inf->clocks_en_bits);
 
 	/* Enable the device */
-	zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << inf->id, 1 << inf->id);
+	zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << id, 1 << id);
 }
 
-void vou_inf_disable(const struct vou_inf *inf, struct drm_crtc *crtc)
+void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc)
 {
 	struct zx_vou_hw *vou = crtc_to_vou(crtc);
+	struct vou_inf *inf = &vou_infs[id];
 
 	/* Disable the device */
-	zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << inf->id, 0);
+	zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << id, 0);
 
 	/* Disable interface clocks */
 	zx_writel_mask(vou->vouctl + VOU_CLK_EN, inf->clocks_en_bits, 0);
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index 4b4339be641b..a41a0ad49857 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -30,15 +30,8 @@ enum vou_inf_data_sel {
 	VOU_RGB_666	= 3,
 };
 
-struct vou_inf {
-	enum vou_inf_id id;
-	enum vou_inf_data_sel data_sel;
-	u32 clocks_en_bits;
-	u32 clocks_sel_bits;
-};
-
-void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc);
-void vou_inf_disable(const struct vou_inf *inf, struct drm_crtc *crtc);
+void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc);
+void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc);
 
 int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe);
 void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe);
-- 
1.9.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [PATCH 3/5] drm: zte: add function to configure vou_ctrl dividers
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
  To: dri-devel
  Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
	Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>

From: Shawn Guo <shawn.guo@linaro.org>

The clock control module (CRM) cannot always provide desired frequency
for all VOU output devices.  That's why VOU integrates a few dividers
to further divide the clocks from CRM.  Let's add an interface for
configuring these dividers.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 drivers/gpu/drm/zte/zx_vou.c      | 79 +++++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/zte/zx_vou.h      | 25 +++++++++++++
 drivers/gpu/drm/zte/zx_vou_regs.h | 16 ++++++++
 3 files changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index c48704b4425a..98f0f51f9748 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -72,6 +72,13 @@ struct zx_crtc_bits {
 	u32 sec_vactive_mask;
 	u32 interlace_select;
 	u32 pi_enable;
+	u32 div_vga_shift;
+	u32 div_pic_shift;
+	u32 div_tvenc_shift;
+	u32 div_hdmi_pnx_shift;
+	u32 div_hdmi_shift;
+	u32 div_inf_shift;
+	u32 div_layer_shift;
 };
 
 static const struct zx_crtc_bits main_crtc_bits = {
@@ -83,6 +90,13 @@ struct zx_crtc_bits {
 	.sec_vactive_mask = SEC_VACT_MAIN_MASK,
 	.interlace_select = MAIN_INTERLACE_SEL,
 	.pi_enable = MAIN_PI_EN,
+	.div_vga_shift = VGA_MAIN_DIV_SHIFT,
+	.div_pic_shift = PIC_MAIN_DIV_SHIFT,
+	.div_tvenc_shift = TVENC_MAIN_DIV_SHIFT,
+	.div_hdmi_pnx_shift = HDMI_MAIN_PNX_DIV_SHIFT,
+	.div_hdmi_shift = HDMI_MAIN_DIV_SHIFT,
+	.div_inf_shift = INF_MAIN_DIV_SHIFT,
+	.div_layer_shift = LAYER_MAIN_DIV_SHIFT,
 };
 
 static const struct zx_crtc_bits aux_crtc_bits = {
@@ -94,6 +108,13 @@ struct zx_crtc_bits {
 	.sec_vactive_mask = SEC_VACT_AUX_MASK,
 	.interlace_select = AUX_INTERLACE_SEL,
 	.pi_enable = AUX_PI_EN,
+	.div_vga_shift = VGA_AUX_DIV_SHIFT,
+	.div_pic_shift = PIC_AUX_DIV_SHIFT,
+	.div_tvenc_shift = TVENC_AUX_DIV_SHIFT,
+	.div_hdmi_pnx_shift = HDMI_AUX_PNX_DIV_SHIFT,
+	.div_hdmi_shift = HDMI_AUX_DIV_SHIFT,
+	.div_inf_shift = INF_AUX_DIV_SHIFT,
+	.div_layer_shift = LAYER_AUX_DIV_SHIFT,
 };
 
 struct zx_crtc {
@@ -220,6 +241,64 @@ void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc)
 	zx_writel_mask(vou->vouctl + VOU_CLK_EN, inf->clocks_en_bits, 0);
 }
 
+void zx_vou_config_dividers(struct drm_crtc *crtc,
+			    struct vou_div_config *configs, int num)
+{
+	struct zx_crtc *zcrtc = to_zx_crtc(crtc);
+	struct zx_vou_hw *vou = zcrtc->vou;
+	const struct zx_crtc_bits *bits = zcrtc->bits;
+	int i;
+
+	/* Clear update flag bit */
+	zx_writel_mask(vou->vouctl + VOU_DIV_PARA, DIV_PARA_UPDATE, 0);
+
+	for (i = 0; i < num; i++) {
+		struct vou_div_config *cfg = configs + i;
+		u32 reg, shift;
+
+		switch (cfg->id) {
+		case VOU_DIV_VGA:
+			reg = VOU_CLK_SEL;
+			shift = bits->div_vga_shift;
+			break;
+		case VOU_DIV_PIC:
+			reg = VOU_CLK_SEL;
+			shift = bits->div_pic_shift;
+			break;
+		case VOU_DIV_TVENC:
+			reg = VOU_DIV_PARA;
+			shift = bits->div_tvenc_shift;
+			break;
+		case VOU_DIV_HDMI_PNX:
+			reg = VOU_DIV_PARA;
+			shift = bits->div_hdmi_pnx_shift;
+			break;
+		case VOU_DIV_HDMI:
+			reg = VOU_DIV_PARA;
+			shift = bits->div_hdmi_shift;
+			break;
+		case VOU_DIV_INF:
+			reg = VOU_DIV_PARA;
+			shift = bits->div_inf_shift;
+			break;
+		case VOU_DIV_LAYER:
+			reg = VOU_DIV_PARA;
+			shift = bits->div_layer_shift;
+			break;
+		default:
+			continue;
+		}
+
+		/* Each divider occupies 3 bits */
+		zx_writel_mask(vou->vouctl + reg, 0x7 << shift,
+			       cfg->val << shift);
+	}
+
+	/* Set update flag bit to get dividers effected */
+	zx_writel_mask(vou->vouctl + VOU_DIV_PARA, DIV_PARA_UPDATE,
+		       DIV_PARA_UPDATE);
+}
+
 static inline void vou_chn_set_update(struct zx_crtc *zcrtc)
 {
 	zx_writel(zcrtc->chnreg + CHN_UPDATE, 1);
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index a41a0ad49857..0dae4faefac4 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -33,6 +33,31 @@ enum vou_inf_data_sel {
 void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc);
 void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc);
 
+enum vou_div_id {
+	VOU_DIV_VGA,
+	VOU_DIV_PIC,
+	VOU_DIV_TVENC,
+	VOU_DIV_HDMI_PNX,
+	VOU_DIV_HDMI,
+	VOU_DIV_INF,
+	VOU_DIV_LAYER,
+};
+
+enum vou_div_val {
+	VOU_DIV_1 = 0,
+	VOU_DIV_2 = 1,
+	VOU_DIV_4 = 3,
+	VOU_DIV_8 = 7,
+};
+
+struct vou_div_config {
+	enum vou_div_id id;
+	enum vou_div_val val;
+};
+
+void zx_vou_config_dividers(struct drm_crtc *crtc,
+			    struct vou_div_config *configs, int num);
+
 int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe);
 void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe);
 
diff --git a/drivers/gpu/drm/zte/zx_vou_regs.h b/drivers/gpu/drm/zte/zx_vou_regs.h
index e6ed844e068a..552772137cf0 100644
--- a/drivers/gpu/drm/zte/zx_vou_regs.h
+++ b/drivers/gpu/drm/zte/zx_vou_regs.h
@@ -176,11 +176,27 @@
 #define VOU_INF_DATA_SEL		0x08
 #define VOU_SOFT_RST			0x14
 #define VOU_CLK_SEL			0x18
+#define VGA_AUX_DIV_SHIFT		29
+#define VGA_MAIN_DIV_SHIFT		26
+#define PIC_MAIN_DIV_SHIFT		23
+#define PIC_AUX_DIV_SHIFT		20
 #define VOU_CLK_VL2_SEL			BIT(8)
 #define VOU_CLK_VL1_SEL			BIT(7)
 #define VOU_CLK_VL0_SEL			BIT(6)
 #define VOU_CLK_GL1_SEL			BIT(5)
 #define VOU_CLK_GL0_SEL			BIT(4)
+#define VOU_DIV_PARA			0x1c
+#define DIV_PARA_UPDATE			BIT(31)
+#define TVENC_AUX_DIV_SHIFT		28
+#define HDMI_AUX_PNX_DIV_SHIFT		25
+#define HDMI_MAIN_PNX_DIV_SHIFT		22
+#define HDMI_AUX_DIV_SHIFT		19
+#define HDMI_MAIN_DIV_SHIFT		16
+#define TVENC_MAIN_DIV_SHIFT		13
+#define INF_AUX_DIV_SHIFT		9
+#define INF_MAIN_DIV_SHIFT		6
+#define LAYER_AUX_DIV_SHIFT		3
+#define LAYER_MAIN_DIV_SHIFT		0
 #define VOU_CLK_REQEN			0x20
 #define VOU_CLK_EN			0x24
 
-- 
1.9.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [PATCH 4/5] dt: add bindings for ZTE tvenc device
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
  To: dri-devel
  Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
	Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>

From: Shawn Guo <shawn.guo@linaro.org>

It adds bindings doc for ZTE VOU TV Encoder device.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt
index 740e5bd2e4f7..9c356284232b 100644
--- a/Documentation/devicetree/bindings/display/zte,vou.txt
+++ b/Documentation/devicetree/bindings/display/zte,vou.txt
@@ -49,6 +49,15 @@ Required properties:
 	"osc_clk"
 	"xclk"
 
+* TV Encoder output device
+
+Required properties:
+ - compatible: should be "zte,zx296718-tvenc"
+ - reg: Physical base address and length of the TVENC device IO region
+ - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two
+   integer cells.  The first cell is the offset of SYSCTRL register used
+   to control TV Encoder DAC power, and the second cell is the bit mask.
+
 Example:
 
 vou: vou@1440000 {
@@ -81,4 +90,10 @@ vou: vou@1440000 {
 			 <&topcrm HDMI_XCLK>;
 		clock-names = "osc_cec", "osc_clk", "xclk";
 	};
+
+	tvenc: tvenc@2000 {
+		compatible = "zte,zx296718-tvenc";
+		reg = <0x2000 0x1000>;
+		zte,tvenc-power-control = <&sysctrl 0x170 0x10>;
+	};
 };
-- 
1.9.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [PATCH 5/5] drm: zte: add tvenc driver support
From: Shawn Guo @ 2017-01-19 16:25 UTC (permalink / raw)
  To: dri-devel
  Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
	Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>

From: Shawn Guo <shawn.guo@linaro.org>

It adds the TV Encoder driver to support video output in PAL and NTSC
format.  The driver uses syscon/regmap interface to configure register
bit sitting in SYSCTRL module for DAC power control.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 drivers/gpu/drm/zte/Makefile        |   1 +
 drivers/gpu/drm/zte/zx_drm_drv.c    |   1 +
 drivers/gpu/drm/zte/zx_drm_drv.h    |   1 +
 drivers/gpu/drm/zte/zx_tvenc.c      | 416 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/zte/zx_tvenc_regs.h |  31 +++
 drivers/gpu/drm/zte/zx_vou.c        |   5 +
 6 files changed, 455 insertions(+)
 create mode 100644 drivers/gpu/drm/zte/zx_tvenc.c
 create mode 100644 drivers/gpu/drm/zte/zx_tvenc_regs.h

diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
index 699180bfd57c..01352b56c418 100644
--- a/drivers/gpu/drm/zte/Makefile
+++ b/drivers/gpu/drm/zte/Makefile
@@ -2,6 +2,7 @@ zxdrm-y := \
 	zx_drm_drv.o \
 	zx_hdmi.o \
 	zx_plane.o \
+	zx_tvenc.o \
 	zx_vou.o
 
 obj-$(CONFIG_DRM_ZTE) += zxdrm.o
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 3e76f72c92ff..13081fed902d 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -247,6 +247,7 @@ static int zx_drm_remove(struct platform_device *pdev)
 static struct platform_driver *drivers[] = {
 	&zx_crtc_driver,
 	&zx_hdmi_driver,
+	&zx_tvenc_driver,
 	&zx_drm_platform_driver,
 };
 
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.h b/drivers/gpu/drm/zte/zx_drm_drv.h
index e65cd18a6cba..5ca035b079c7 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.h
+++ b/drivers/gpu/drm/zte/zx_drm_drv.h
@@ -13,6 +13,7 @@
 
 extern struct platform_driver zx_crtc_driver;
 extern struct platform_driver zx_hdmi_driver;
+extern struct platform_driver zx_tvenc_driver;
 
 static inline u32 zx_readl(void __iomem *reg)
 {
diff --git a/drivers/gpu/drm/zte/zx_tvenc.c b/drivers/gpu/drm/zte/zx_tvenc.c
new file mode 100644
index 000000000000..5a6cff1ff8a8
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_tvenc.c
@@ -0,0 +1,416 @@
+/*
+ * Copyright 2017 Linaro Ltd.
+ * Copyright 2017 ZTE Corporation.
+ *
+ * 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/clk.h>
+#include <linux/component.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drmP.h>
+
+#include "zx_drm_drv.h"
+#include "zx_tvenc_regs.h"
+#include "zx_vou.h"
+
+struct zx_tvenc_pwrctrl {
+	struct regmap *regmap;
+	u32 reg;
+	u32 mask;
+};
+
+struct zx_tvenc {
+	struct drm_connector connector;
+	struct drm_encoder encoder;
+	struct device *dev;
+	void __iomem *mmio;
+	const struct vou_inf *inf;
+	struct zx_tvenc_pwrctrl pwrctrl;
+};
+
+#define to_zx_tvenc(x) container_of(x, struct zx_tvenc, x)
+
+struct zx_tvenc_mode {
+	char *name;
+	u32 hdisplay;
+	u32 vdisplay;
+	u32 hfp;
+	u32 hbp;
+	u32 hsw;
+	u32 vfp;
+	u32 vbp;
+	u32 vsw;
+	u32 video_info;
+	u32 video_res;
+	u32 field1_param;
+	u32 field2_param;
+	u32 burst_line_odd1;
+	u32 burst_line_even1;
+	u32 burst_line_odd2;
+	u32 burst_line_even2;
+	u32 line_timing_param;
+	u32 weight_value;
+	u32 blank_black_level;
+	u32 burst_level;
+	u32 control_param;
+	u32 sub_carrier_phase1;
+	u32 phase_line_incr_cvbs;
+};
+
+static const struct zx_tvenc_mode tvenc_modes[] = {
+	{
+		.name = "PAL",
+		.hdisplay = 720,
+		.vdisplay = 576,
+		.hfp = 12,
+		.hbp = 130,
+		.hsw = 2,
+		.vfp = 2,
+		.vbp = 20,
+		.vsw = 2,
+		.video_info = 0x00040040,
+		.video_res = 0x05a9c760,
+		.field1_param = 0x0004d416,
+		.field2_param = 0x0009b94f,
+		.burst_line_odd1 = 0x0004d406,
+		.burst_line_even1 = 0x0009b53e,
+		.burst_line_odd2 = 0x0004d805,
+		.burst_line_even2 = 0x0009b93f,
+		.line_timing_param = 0x06a96fdf,
+		.weight_value = 0x00c188a0,
+		.blank_black_level = 0x0000fcfc,
+		.burst_level = 0x00001595,
+		.control_param = 0x00000001,
+		.sub_carrier_phase1 = 0x1504c566,
+		.phase_line_incr_cvbs = 0xc068db8c,
+	}, {
+		.name = "NTSC",
+		.hdisplay = 720,
+		.vdisplay = 480,
+		.hfp = 16,
+		.hbp = 120,
+		.hsw = 2,
+		.vfp = 3,
+		.vbp = 17,
+		.vsw = 2,
+		.video_info = 0x00040080,
+		.video_res = 0x05a8375a,
+		.field1_param = 0x00041817,
+		.field2_param = 0x0008351e,
+		.burst_line_odd1 = 0x00041006,
+		.burst_line_even1 = 0x0008290d,
+		.burst_line_odd2 = 0x00000000,
+		.burst_line_even2 = 0x00000000,
+		.line_timing_param = 0x06a8ef9e,
+		.weight_value = 0x00b68197,
+		.blank_black_level = 0x0000f0f0,
+		.burst_level = 0x0000009c,
+		.control_param = 0x00000001,
+		.sub_carrier_phase1 = 0x10f83e10,
+		.phase_line_incr_cvbs = 0x80000000,
+	},
+};
+
+static const struct zx_tvenc_mode *
+zx_tvenc_find_zmode(struct drm_display_mode *mode)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(tvenc_modes); i++) {
+		const struct zx_tvenc_mode *zmode = &tvenc_modes[i];
+
+		if (!strcmp(mode->name, zmode->name))
+			return zmode;
+	}
+
+	return NULL;
+}
+
+static void zx_tvenc_encoder_mode_set(struct drm_encoder *encoder,
+				      struct drm_display_mode *mode,
+				      struct drm_display_mode *adj_mode)
+{
+	struct zx_tvenc *tvenc = to_zx_tvenc(encoder);
+	const struct zx_tvenc_mode *zmode;
+	struct vou_div_config configs[] = {
+		{ VOU_DIV_INF,   VOU_DIV_4 },
+		{ VOU_DIV_TVENC, VOU_DIV_1 },
+		{ VOU_DIV_LAYER, VOU_DIV_2 },
+	};
+
+	zx_vou_config_dividers(encoder->crtc, configs, ARRAY_SIZE(configs));
+
+	zmode = zx_tvenc_find_zmode(mode);
+	if (!zmode) {
+		DRM_DEV_ERROR(tvenc->dev, "failed to find zmode\n");
+		return;
+	}
+
+	zx_writel(tvenc->mmio + VENC_VIDEO_INFO, zmode->video_info);
+	zx_writel(tvenc->mmio + VENC_VIDEO_RES, zmode->video_res);
+	zx_writel(tvenc->mmio + VENC_FIELD1_PARAM, zmode->field1_param);
+	zx_writel(tvenc->mmio + VENC_FIELD2_PARAM, zmode->field2_param);
+	zx_writel(tvenc->mmio + VENC_LINE_O_1, zmode->burst_line_odd1);
+	zx_writel(tvenc->mmio + VENC_LINE_E_1, zmode->burst_line_even1);
+	zx_writel(tvenc->mmio + VENC_LINE_O_2, zmode->burst_line_odd2);
+	zx_writel(tvenc->mmio + VENC_LINE_E_2, zmode->burst_line_even2);
+	zx_writel(tvenc->mmio + VENC_LINE_TIMING_PARAM,
+		  zmode->line_timing_param);
+	zx_writel(tvenc->mmio + VENC_WEIGHT_VALUE, zmode->weight_value);
+	zx_writel(tvenc->mmio + VENC_BLANK_BLACK_LEVEL,
+		  zmode->blank_black_level);
+	zx_writel(tvenc->mmio + VENC_BURST_LEVEL, zmode->burst_level);
+	zx_writel(tvenc->mmio + VENC_CONTROL_PARAM, zmode->control_param);
+	zx_writel(tvenc->mmio + VENC_SUB_CARRIER_PHASE1,
+		  zmode->sub_carrier_phase1);
+	zx_writel(tvenc->mmio + VENC_PHASE_LINE_INCR_CVBS,
+		  zmode->phase_line_incr_cvbs);
+}
+
+static void zx_tvenc_encoder_enable(struct drm_encoder *encoder)
+{
+	struct zx_tvenc *tvenc = to_zx_tvenc(encoder);
+	struct zx_tvenc_pwrctrl *pwrctrl = &tvenc->pwrctrl;
+
+	/* Set bit to power up TVENC DAC */
+	regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask,
+			   pwrctrl->mask);
+
+	vou_inf_enable(VOU_TV_ENC, encoder->crtc);
+
+	zx_writel(tvenc->mmio + VENC_ENABLE, 1);
+}
+
+static void zx_tvenc_encoder_disable(struct drm_encoder *encoder)
+{
+	struct zx_tvenc *tvenc = to_zx_tvenc(encoder);
+	struct zx_tvenc_pwrctrl *pwrctrl = &tvenc->pwrctrl;
+
+	zx_writel(tvenc->mmio + VENC_ENABLE, 0);
+
+	vou_inf_disable(VOU_TV_ENC, encoder->crtc);
+
+	/* Clear bit to power down TVENC DAC */
+	regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask, 0);
+}
+
+static const struct drm_encoder_helper_funcs zx_tvenc_encoder_helper_funcs = {
+	.enable	= zx_tvenc_encoder_enable,
+	.disable = zx_tvenc_encoder_disable,
+	.mode_set = zx_tvenc_encoder_mode_set,
+};
+
+static const struct drm_encoder_funcs zx_tvenc_encoder_funcs = {
+	.destroy = drm_encoder_cleanup,
+};
+
+static void zx_tvenc_mode_to_drm_mode(const struct zx_tvenc_mode *zmode,
+				      struct drm_display_mode *mode)
+{
+	strcpy(mode->name, zmode->name);
+
+	mode->type = DRM_MODE_TYPE_DRIVER;
+	mode->flags = DRM_MODE_FLAG_INTERLACE;
+	mode->flags |= DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC;
+
+	/*
+	 * The CRM cannot directly provide such a low rate, and we have to
+	 * ask a multiflied rate from CRM and use the divider in VOU to get
+	 * the disired one.
+	 */
+	mode->clock = 13500 * 4;
+
+	mode->hdisplay = zmode->hdisplay;
+	mode->hsync_start = mode->hdisplay + zmode->hfp;
+	mode->hsync_end = mode->hsync_start + zmode->hsw;
+	mode->htotal = mode->hsync_end + zmode->hbp;
+
+	mode->vdisplay = zmode->vdisplay;
+	mode->vsync_start = mode->vdisplay + zmode->vfp;
+	mode->vsync_end = mode->vsync_start + zmode->vsw;
+	mode->vtotal = mode->vsync_end + zmode->vbp;
+}
+
+static int zx_tvenc_connector_get_modes(struct drm_connector *connector)
+{
+	struct zx_tvenc *tvenc = to_zx_tvenc(connector);
+	struct device *dev = tvenc->dev;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(tvenc_modes); i++) {
+		struct drm_display_mode *mode;
+		const struct zx_tvenc_mode *zmode = &tvenc_modes[i];
+
+		mode = drm_mode_create(connector->dev);
+		if (!mode) {
+			DRM_DEV_ERROR(dev, "failed to create drm mode\n");
+			return 0;
+		}
+
+		zx_tvenc_mode_to_drm_mode(zmode, mode);
+		drm_mode_probed_add(connector, mode);
+	}
+
+	return i;
+}
+
+static enum drm_mode_status
+zx_tvenc_connector_mode_valid(struct drm_connector *connector,
+			      struct drm_display_mode *mode)
+{
+	return MODE_OK;
+}
+
+static struct drm_connector_helper_funcs zx_tvenc_connector_helper_funcs = {
+	.get_modes = zx_tvenc_connector_get_modes,
+	.mode_valid = zx_tvenc_connector_mode_valid,
+};
+
+static const struct drm_connector_funcs zx_tvenc_connector_funcs = {
+	.dpms = drm_atomic_helper_connector_dpms,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.destroy = drm_connector_cleanup,
+	.reset = drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int zx_tvenc_register(struct drm_device *drm, struct zx_tvenc *tvenc)
+{
+	struct drm_encoder *encoder = &tvenc->encoder;
+	struct drm_connector *connector = &tvenc->connector;
+
+	/*
+	 * The tvenc is designed to use aux channel, as there is a deflicker
+	 * block for the channel.
+	 */
+	encoder->possible_crtcs = BIT(1);
+
+	drm_encoder_init(drm, encoder, &zx_tvenc_encoder_funcs,
+			 DRM_MODE_ENCODER_TVDAC, NULL);
+	drm_encoder_helper_add(encoder, &zx_tvenc_encoder_helper_funcs);
+
+	connector->interlace_allowed = true;
+
+	drm_connector_init(drm, connector, &zx_tvenc_connector_funcs,
+			   DRM_MODE_CONNECTOR_Composite);
+	drm_connector_helper_add(connector, &zx_tvenc_connector_helper_funcs);
+
+	drm_mode_connector_attach_encoder(connector, encoder);
+
+	return 0;
+}
+
+static int zx_tvenc_pwrctrl_init(struct zx_tvenc *tvenc)
+{
+	struct zx_tvenc_pwrctrl *pwrctrl = &tvenc->pwrctrl;
+	struct device *dev = tvenc->dev;
+	struct of_phandle_args out_args;
+	struct regmap *regmap;
+	int ret;
+
+	ret = of_parse_phandle_with_fixed_args(dev->of_node,
+				"zte,tvenc-power-control", 2, 0, &out_args);
+	if (ret)
+		return ret;
+
+	regmap = syscon_node_to_regmap(out_args.np);
+	if (IS_ERR(regmap)) {
+		ret = PTR_ERR(regmap);
+		goto out;
+	}
+
+	pwrctrl->regmap = regmap;
+	pwrctrl->reg = out_args.args[0];
+	pwrctrl->mask = out_args.args[1];
+
+out:
+	of_node_put(out_args.np);
+	return ret;
+}
+
+static int zx_tvenc_bind(struct device *dev, struct device *master, void *data)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct drm_device *drm = data;
+	struct resource *res;
+	struct zx_tvenc *tvenc;
+	int ret;
+
+	tvenc = devm_kzalloc(dev, sizeof(*tvenc), GFP_KERNEL);
+	if (!tvenc)
+		return -ENOMEM;
+
+	tvenc->dev = dev;
+	dev_set_drvdata(dev, tvenc);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	tvenc->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(tvenc->mmio)) {
+		ret = PTR_ERR(tvenc->mmio);
+		DRM_DEV_ERROR(dev, "failed to remap tvenc region: %d\n", ret);
+		return ret;
+	}
+
+	ret = zx_tvenc_pwrctrl_init(tvenc);
+	if (ret) {
+		DRM_DEV_ERROR(dev, "failed to init power control: %d\n", ret);
+		return ret;
+	}
+
+	ret = zx_tvenc_register(drm, tvenc);
+	if (ret) {
+		DRM_DEV_ERROR(dev, "failed to register tvenc: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static void zx_tvenc_unbind(struct device *dev, struct device *master,
+			    void *data)
+{
+	struct zx_tvenc *tvenc = dev_get_drvdata(dev);
+
+	tvenc->connector.funcs->destroy(&tvenc->connector);
+	tvenc->encoder.funcs->destroy(&tvenc->encoder);
+}
+
+static const struct component_ops zx_tvenc_component_ops = {
+	.bind = zx_tvenc_bind,
+	.unbind = zx_tvenc_unbind,
+};
+
+static int zx_tvenc_probe(struct platform_device *pdev)
+{
+	return component_add(&pdev->dev, &zx_tvenc_component_ops);
+}
+
+static int zx_tvenc_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &zx_tvenc_component_ops);
+	return 0;
+}
+
+static const struct of_device_id zx_tvenc_of_match[] = {
+	{ .compatible = "zte,zx296718-tvenc", },
+	{ /* end */ },
+};
+MODULE_DEVICE_TABLE(of, zx_tvenc_of_match);
+
+struct platform_driver zx_tvenc_driver = {
+	.probe = zx_tvenc_probe,
+	.remove = zx_tvenc_remove,
+	.driver	= {
+		.name = "zx-tvenc",
+		.of_match_table	= zx_tvenc_of_match,
+	},
+};
diff --git a/drivers/gpu/drm/zte/zx_tvenc_regs.h b/drivers/gpu/drm/zte/zx_tvenc_regs.h
new file mode 100644
index 000000000000..bd91f5dcc1f3
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_tvenc_regs.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright 2017 Linaro Ltd.
+ * Copyright 2017 ZTE Corporation.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __ZX_TVENC_REGS_H__
+#define __ZX_TVENC_REGS_H__
+
+#define VENC_VIDEO_INFO			0x04
+#define VENC_VIDEO_RES			0x08
+#define VENC_FIELD1_PARAM		0x10
+#define VENC_FIELD2_PARAM		0x14
+#define VENC_LINE_O_1			0x18
+#define VENC_LINE_E_1			0x1c
+#define VENC_LINE_O_2			0x20
+#define VENC_LINE_E_2			0x24
+#define VENC_LINE_TIMING_PARAM		0x28
+#define VENC_WEIGHT_VALUE		0x2c
+#define VENC_BLANK_BLACK_LEVEL		0x30
+#define VENC_BURST_LEVEL		0x34
+#define VENC_CONTROL_PARAM		0x3c
+#define VENC_SUB_CARRIER_PHASE1		0x40
+#define VENC_PHASE_LINE_INCR_CVBS	0x48
+#define VENC_ENABLE			0xa8
+
+#endif /* __ZX_TVENC_REGS_H__ */
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 98f0f51f9748..61d4ff709d83 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -192,6 +192,11 @@ struct vou_inf {
 		.clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
 		.clocks_sel_bits = BIT(13) | BIT(2),
 	},
+	[VOU_TV_ENC] = {
+		.data_sel = VOU_YUV444,
+		.clocks_en_bits = BIT(15),
+		.clocks_sel_bits = BIT(11) | BIT(0),
+	},
 };
 
 static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
-- 
1.9.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* Re: Initializing MAC address at run-time
From: Uwe Kleine-König @ 2017-01-19 16:26 UTC (permalink / raw)
  To: Mason
  Cc: Mark Rutland, DT, Arnd Bergmann, Kevin Hilman, netdev,
	Thibaud Cornic, Linux ARM
In-Reply-To: <79fef293-74ec-dece-1941-747cd55f1ca2@free.fr>

Hello,

On Thu, Jan 19, 2017 at 04:31:56PM +0100, Mason wrote:
> Do you agree that such boot loader would execute code that is roughly
> identical to the one posted for illustration purposes?
>   1. find the MAC address to use for eth0
>   2. find the eth0 node in the DT
>   3. insert the right prop in the eth0 node

yes.
 
> In which case, it seems a waste to add the DT library to the boot
> loader, when the operation can be done in Linux, which requires the
> DT library anyway. (Additionally, adding DT support to some custom
> legacy boot loader might be a complex task.)

With this reasoning you can discuss away the bootloader. Linux relies on
a bootloader for a reason. It's there to initialize RAM and some further
things that Linux might not be able to and provide a machine description
to Linux (either in form of a dtb or an ATAG list) such that Linux
doesn't need to fiddle with machine specific stuff in early init code.

> >  c) Adapt the dtb before it is written to the boot medium.
> 
> This is not applicable, as the DTB is not written to the board.

Ah, then adapt the dtb before it is put into the tftp folder.

> >  d) Let the bootloader configure the device and teach the driver to pick
> >     up the mac from the device's address space.
> 
> I'm not sure what you call "the device" ?

The network device. IIRC the fec driver checks if there is something
configured in the two registers configuring the MAC before falling back
to a random MAC.

> >  e) Accept that the mac address is random during development, and make
> >     Userspace configure the MAC address, which is early enough for
> >     production use.
> 
> During development, some devs configure the DHCP server to provide
> a specific uImage and/or rootfs to their board, based on the MAC
> address. This scheme would fall apart with a random MAC.
> 
> > Not sure d) is considered ok today, but some drivers have this feature.
> > I'd say b) is the best choice.
> 
> In my mind, doing it early in Linux is similar in spirit to doing it
> at the boot loader stage, in that it's neatly separated from the rest
> of the setup.

Sure you can do this. But it won't be accepted mainline for sure.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver
From: Rob Herring @ 2017-01-19 16:29 UTC (permalink / raw)
  To: Yannick Fertre
  Cc: Alexandre TORGUE, Thierry Reding, David Airlie, Maxime Coquelin,
	Russell King, Mark Rutland, Arnd Bergmann, Philippe Cornu,
	Mickael Reulier, Gabriel FERNANDEZ, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484573344-11609-2-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>

On Mon, Jan 16, 2017 at 02:28:58PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>

Changelog?

> ---
>  .../devicetree/bindings/display/st,ltdc.txt        | 57 ++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt b/Documentation/devicetree/bindings/display/st,ltdc.txt
> new file mode 100644
> index 0000000..20e89da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> @@ -0,0 +1,57 @@
> +* STMicroelectronics STM32 lcd-tft display controller
> +
> +- st-display-subsystem: Master device for DRM sub-components
> +  This device must be the parent of all the sub-components and is responsible
> +  of bind them.
> +  Required properties:
> +  - compatible: "st,display-subsystem"
> +  - ranges: to allow probing of subdevices

You have a single sub device. There is no need for this node.


> +- ltdc_host: lcd-tft display controller host
> +  must be a sub-node of st-display-subsystem
> +  Required properties:
> +  - compatible: "st,ltdc"

Too generic. Needs to be SoC specific.

> +  - reg: Physical base address of the IP registers and length of memory mapped region.
> +  - clocks: from common clock binding: handle hardware IP needed clocks, the
> +    number of clocks may depend of the SoC type.

No. You must be explicit on how many clocks and their order.

> +    See ../clocks/clock-bindings.txt for details.
> +  - clock-names: names of the clocks listed in clocks property in the same
> +    order.
> +  - resets: resets to be used by the device

ditto.

> +    See ../reset/reset.txt for details.
> +  - reset-names: names of the resets listed in resets property in the same
> +    order.

You are missing this in the example. However, for a single entry, -names 
is pointless.

> +  Required nodes:
> +    - Video port for RGB output.
> +
> +Example:
> +
> +/ {
> +	...
> +	soc {
> +	...
> +		st-display-subsystem {
> +			compatible = "st,display-subsystem";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			ranges;
> +			dma-ranges;
> +
> +			ltdc_host: stm32-ltdc@40016800 {
> +				compatible = "st,ltdc";
> +				reg = <0x40016800 0x200>;
> +				interrupts = <88>, <89>;
> +				resets = <&rcc 314>;
> +				clocks = <&rcc 1 8>;
> +				clock-names = "clk-lcd";

The 'clk-' part is redundant.

> +				status = "disabled";
> +
> +				port {
> +					ltdc_out_rgb: endpoint {
> +					};
> +				};
> +			};
> +		};
> +	...
> +	};
> +};
> -- 
> 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

* Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver
From: Rob Herring @ 2017-01-19 16:31 UTC (permalink / raw)
  To: Yannick FERTRE
  Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre TORGUE,
	Arnd Bergmann, Russell King, dri-devel@lists.freedesktop.org,
	Philippe CORNU, Laurent Pinchart, Maxime Coquelin,
	Mickael REULIER, Gabriel FERNANDEZ,
	linux-arm-kernel@lists.infradead.org, kernel@stlinux.com
In-Reply-To: <dfb3192a-d5b6-029e-b8cb-65a628a0c30b@st.com>

On Thu, Jan 19, 2017 at 04:16:01PM +0000, Yannick FERTRE wrote:
> On 01/16/2017 09:30 PM, Laurent Pinchart wrote:
> > Hi Yannick,
> >
> > Thank you for the patch.
> >
> > On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
> >> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> >> ---
> >>  .../devicetree/bindings/display/st,ltdc.txt        | 57 ++++++++++++++++++
> >>  1 file changed, 57 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt
> >> b/Documentation/devicetree/bindings/display/st,ltdc.txt new file mode
> >> 100644
> >> index 0000000..20e89da
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> >> @@ -0,0 +1,57 @@
> >> +* STMicroelectronics STM32 lcd-tft display controller
> >> +
> >> +- st-display-subsystem: Master device for DRM sub-components
> >> +  This device must be the parent of all the sub-components and is
> >> responsible
> >> +  of bind them.
> >
> > Why do you need this ? At a quick glance the ltdc node should be enough.
> Hi Laurent,
> To prepare next device upstream of dsi, we need a master node 
> "st-display-subsystem" and a sub node "st,ltdc". It's the same kind of 
> node than st,stih4xx.

No, you don't. That's what OF graph is for. The DRM driver binds to the 
LCD controller node and walks the graph to find the DSI node and then 
the panel.

Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH v1 3/7] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
From: Rob Herring @ 2017-01-19 16:32 UTC (permalink / raw)
  To: Yannick Fertre
  Cc: Mark Rutland, devicetree, Alexandre TORGUE, Arnd Bergmann,
	Russell King, dri-devel, Philippe Cornu, Maxime Coquelin,
	Mickael Reulier, Gabriel FERNANDEZ, linux-arm-kernel, kernel
In-Reply-To: <1484573344-11609-4-git-send-email-yannick.fertre@st.com>

On Mon, Jan 16, 2017 at 02:29:00PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> ---
>  .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt         | 7 +++++++
>  1 file changed, 7 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> new file mode 100644
> index 0000000..f59e3c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> @@ -0,0 +1,7 @@
> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "ampire,am-480272h3tmqw-t01h"

No GPIOs or power supply?

> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> -- 
> 1.9.1
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* [PATCH 3/3] PCI: imx6: Add code to support i.MX7D
From: Andrey Smirnov @ 2017-01-19 16:36 UTC (permalink / raw)
  To: linux-pci
  Cc: Mark Rutland, devicetree, Richard Zhu, Andrey Smirnov, Shawn Guo,
	linux-kernel, Rob Herring, Bjorn Helgaas, Lee Jones, yurovsky,
	Fabio Estevam, linux-arm-kernel, Lucas Stach
In-Reply-To: <20170119163631.10668-1-andrew.smirnov@gmail.com>

Add various bits of code needed to support i.MX7D variant of the IP.

Cc: yurovsky@gmail.com
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 .../devicetree/bindings/pci/fsl,imx6q-pcie.txt     |   6 +-
 drivers/pci/host/pci-imx6.c                        | 188 ++++++++++++++++++---
 include/linux/mfd/syscon/imx7-gpc.h                |  18 ++
 include/linux/mfd/syscon/imx7-iomuxc-gpr.h         |   4 +
 include/linux/mfd/syscon/imx7-src.h                |  18 ++
 5 files changed, 208 insertions(+), 26 deletions(-)
 create mode 100644 include/linux/mfd/syscon/imx7-gpc.h
 create mode 100644 include/linux/mfd/syscon/imx7-src.h

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index 83aeb1f..20b9382 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
 and thus inherits all the common properties defined in designware-pcie.txt.
 
 Required properties:
-- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
+- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie",
+  	      "fsl,imx6qp-pcie", "fsl,imx7d-pcie"
 - reg: base address and length of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
@@ -34,6 +35,9 @@ Additional required properties for imx6sx-pcie:
 - clock names: Must include the following additional entries:
 	- "pcie_inbound_axi"
 
+Additional required properties for imx7d-pcie:
+- pcie-phy-supply: Should specify the regulator supplying PCIe PHY
+
 Example:
 
 	pcie@0x01000000 {
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 574f026..f29148e 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -17,6 +17,9 @@
 #include <linux/kernel.h>
 #include <linux/mfd/syscon.h>
 #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
+#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
+#include <linux/mfd/syscon/imx7-src.h>
+#include <linux/mfd/syscon/imx7-gpc.h>
 #include <linux/module.h>
 #include <linux/of_gpio.h>
 #include <linux/of_device.h>
@@ -27,6 +30,7 @@
 #include <linux/signal.h>
 #include <linux/types.h>
 #include <linux/interrupt.h>
+#include <linux/regulator/consumer.h>
 
 #include "pcie-designware.h"
 
@@ -36,6 +40,7 @@ enum imx6_pcie_variants {
 	IMX6Q,
 	IMX6SX,
 	IMX6QP,
+	IMX7D,
 };
 
 struct imx6_pcie {
@@ -47,6 +52,8 @@ struct imx6_pcie {
 	struct clk		*pcie_inbound_axi;
 	struct clk		*pcie;
 	struct regmap		*iomuxc_gpr;
+	struct regmap		*src;
+	struct regmap		*gpc;
 	enum imx6_pcie_variants variant;
 	u32			tx_deemph_gen1;
 	u32			tx_deemph_gen2_3p5db;
@@ -54,8 +61,14 @@ struct imx6_pcie {
 	u32			tx_swing_full;
 	u32			tx_swing_low;
 	int			link_gen;
+	struct regulator	*pcie_phy_regulator;
 };
 
+/* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
+#define PHY_PLL_LOCK_WAIT_MAX_RETRIES	2000
+#define PHY_PLL_LOCK_WAIT_USLEEP_MIN	50
+#define PHY_PLL_LOCK_WAIT_USLEEP_MAX	200
+
 /* PCIe Root Complex registers (memory-mapped) */
 #define PCIE_RC_LCR				0x7c
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1	0x1
@@ -251,6 +264,16 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
 	u32 val, gpr1, gpr12;
 
 	switch (imx6_pcie->variant) {
+	case IMX7D:
+		regmap_update_bits(imx6_pcie->src,
+				   SRC_PCIEPHY_RCR,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST);
+		regmap_update_bits(imx6_pcie->src,
+				   SRC_PCIEPHY_RCR,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN);
+		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -333,11 +356,33 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
 				   IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
 		break;
+	case IMX7D:
+		break;
 	}
 
 	return ret;
 }
 
+static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
+{
+	u32 val;
+	unsigned int retries;
+	struct pcie_port *pp = &imx6_pcie->pp;
+	struct device *dev = pp->dev;
+
+	for (retries = 0; retries < PHY_PLL_LOCK_WAIT_MAX_RETRIES; retries++) {
+		regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR22, &val);
+
+		if (val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED)
+			return;
+
+		usleep_range(PHY_PLL_LOCK_WAIT_USLEEP_MIN,
+			     PHY_PLL_LOCK_WAIT_USLEEP_MAX);
+	}
+
+	dev_err(dev, "PCIe PLL lock timeout\n");
+}
+
 static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 {
 	struct pcie_port *pp = &imx6_pcie->pp;
@@ -381,6 +426,21 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 	}
 
 	switch (imx6_pcie->variant) {
+	case IMX7D:
+		/* wait for more than 10us to release phy g_rst and btnrst */
+		udelay(10);
+		regmap_update_bits(imx6_pcie->src,
+				   SRC_PCIEPHY_RCR,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN, 0);
+		regmap_update_bits(imx6_pcie->src,
+				   SRC_PCIEPHY_RCR,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST, 0);
+		regmap_update_bits(imx6_pcie->src,
+				   SRC_PCIEPHY_RCR,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN, 0);
+
+		imx7d_pcie_wait_for_phy_pll_lock(imx6_pcie);
+		break;
 	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5,
 				   IMX6SX_GPR5_PCIE_BTNRST_RESET, 0);
@@ -407,35 +467,80 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
 
 static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-	if (imx6_pcie->variant == IMX6SX)
+	switch (imx6_pcie->variant) {
+	case IMX7D: {
+		int ret;
+		unsigned int reg, mapping;
+		struct pcie_port *pp = &imx6_pcie->pp;
+		struct device *dev = pp->dev;
+
+		regulator_set_voltage(imx6_pcie->pcie_phy_regulator,
+				      1000000, 1000000);
+		ret = regulator_enable(imx6_pcie->pcie_phy_regulator);
+		if (ret) {
+			dev_err(dev, "failed to enable pcie regulator.\n");
+			return;
+		}
+
+		/*
+		 * Now that PHY regulator is enabled, do sofware
+		 * power-up request by mapping PHY in A7 domain and
+		 * setting power-up request bit
+		 */
+		regmap_read(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, &mapping);
+		regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING,
+			     mapping | IMX7D_PCIE_PHY_A7_DOMAIN);
+
+		regmap_update_bits(imx6_pcie->gpc, GPC_PU_PGC_SW_PUP_REQ,
+				   IMX7D_PCIE_PHY_SW_PUP_REQ,
+				   IMX7D_PCIE_PHY_SW_PUP_REQ);
+		/*
+		 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+		 * for PUP_REQ bit to be cleared
+		 */
+		while (!regmap_read(imx6_pcie->gpc,
+				    GPC_PU_PGC_SW_PUP_REQ, &reg) &&
+		       reg & IMX7D_PCIE_PHY_SW_PUP_REQ)
+			;
+		regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, mapping);
+
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
+		break;
+	}
+	case IMX6SX:
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 				   IMX6SX_GPR12_PCIE_RX_EQ_MASK,
 				   IMX6SX_GPR12_PCIE_RX_EQ_2);
+		/* FALLTHROUGH */
+	default:
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-			IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
+		/* configure constant input signal to the pcie ctrl and phy */
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+				   IMX6Q_GPR8_TX_DEEMPH_GEN1,
+				   imx6_pcie->tx_deemph_gen1 << 0);
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+				   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+				   imx6_pcie->tx_deemph_gen2_3p5db << 6);
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+				   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+				   imx6_pcie->tx_deemph_gen2_6db << 12);
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+				   IMX6Q_GPR8_TX_SWING_FULL,
+				   imx6_pcie->tx_swing_full << 18);
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+				   IMX6Q_GPR8_TX_SWING_LOW,
+				   imx6_pcie->tx_swing_low << 25);
+		break;
+	}
 
-	/* configure constant input signal to the pcie ctrl and phy */
 	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 			IMX6Q_GPR12_DEVICE_TYPE, PCI_EXP_TYPE_ROOT_PORT << 12);
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-			IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-			   IMX6Q_GPR8_TX_DEEMPH_GEN1,
-			   imx6_pcie->tx_deemph_gen1 << 0);
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-			   IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
-			   imx6_pcie->tx_deemph_gen2_3p5db << 6);
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-			   IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
-			   imx6_pcie->tx_deemph_gen2_6db << 12);
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-			   IMX6Q_GPR8_TX_SWING_FULL,
-			   imx6_pcie->tx_swing_full << 18);
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
-			   IMX6Q_GPR8_TX_SWING_LOW,
-			   imx6_pcie->tx_swing_low << 25);
 }
 
 static int imx6_pcie_wait_for_link(struct imx6_pcie *imx6_pcie)
@@ -498,8 +603,14 @@ static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
 	dw_pcie_writel_rc(pp, PCIE_RC_LCR, tmp);
 
 	/* Start LTSSM. */
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-			IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
+	if (imx6_pcie->variant == IMX7D)
+		regmap_update_bits(imx6_pcie->src,
+				   SRC_PCIEPHY_RCR,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN,
+				   IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN);
+	else
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
 
 	ret = imx6_pcie_wait_for_link(imx6_pcie);
 	if (ret) {
@@ -677,13 +788,39 @@ static int __init imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->pcie);
 	}
 
-	if (imx6_pcie->variant == IMX6SX) {
+	switch (imx6_pcie->variant) {
+	case IMX6SX:
 		imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
 							   "pcie_inbound_axi");
 		if (IS_ERR(imx6_pcie->pcie_inbound_axi)) {
 			dev_err(dev, "pcie_inbound_axi clock missing or invalid\n");
 			return PTR_ERR(imx6_pcie->pcie_inbound_axi);
 		}
+		break;
+	case IMX7D:
+		imx6_pcie->src =
+			syscon_regmap_lookup_by_compatible("fsl,imx7d-src");
+		if (IS_ERR(imx6_pcie->src)) {
+			dev_err(dev, "imx7d pcie phy src missing or invalid\n");
+			return PTR_ERR(imx6_pcie->src);
+		}
+
+		imx6_pcie->gpc =
+			syscon_regmap_lookup_by_compatible("fsl,imx7d-gpc");
+		if (IS_ERR(imx6_pcie->gpc)) {
+			dev_err(dev, "unable to find gpc registers\n");
+			return PTR_ERR(imx6_pcie->gpc);
+		}
+
+		imx6_pcie->pcie_phy_regulator = devm_regulator_get(pp->dev,
+								   "pcie-phy");
+		if (IS_ERR(imx6_pcie->pcie_phy_regulator)) {
+			dev_err(dev, "imx7d pcie phy src missing or invalid\n");
+			return PTR_ERR(imx6_pcie->pcie_phy_regulator);
+		}
+		break;
+	default:
+		break;
 	}
 
 	/* Grab GPR config register range */
@@ -741,6 +878,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx6q-pcie",  .data = (void *)IMX6Q,  },
 	{ .compatible = "fsl,imx6sx-pcie", .data = (void *)IMX6SX, },
 	{ .compatible = "fsl,imx6qp-pcie", .data = (void *)IMX6QP, },
+	{ .compatible = "fsl,imx7d-pcie",  .data = (void *)IMX7D,  },
 	{},
 };
 
diff --git a/include/linux/mfd/syscon/imx7-gpc.h b/include/linux/mfd/syscon/imx7-gpc.h
new file mode 100644
index 0000000..38e1c9a9
--- /dev/null
+++ b/include/linux/mfd/syscon/imx7-gpc.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2017 Impinj
+ *
+ * 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.
+ */
+
+#ifndef __LINUX_IMX7_GPC_H
+#define __LINUX_IMX7_GPC_H
+
+#define GPC_PGC_CPU_MAPPING	0xec
+#define GPC_PU_PGC_SW_PUP_REQ	0xf8
+
+#define IMX7D_PCIE_PHY_A7_DOMAIN	BIT(3)
+#define IMX7D_PCIE_PHY_SW_PUP_REQ	BIT(1)
+
+#endif
diff --git a/include/linux/mfd/syscon/imx7-iomuxc-gpr.h b/include/linux/mfd/syscon/imx7-iomuxc-gpr.h
index 4585d61..abbd524 100644
--- a/include/linux/mfd/syscon/imx7-iomuxc-gpr.h
+++ b/include/linux/mfd/syscon/imx7-iomuxc-gpr.h
@@ -44,4 +44,8 @@
 
 #define IMX7D_GPR5_CSI_MUX_CONTROL_MIPI		(0x1 << 4)
 
+#define IMX7D_GPR12_PCIE_PHY_REFCLK_SEL		BIT(5)
+
+#define IMX7D_GPR22_PCIE_PHY_PLL_LOCKED		BIT(31)
+
 #endif /* __LINUX_IMX7_IOMUXC_GPR_H */
diff --git a/include/linux/mfd/syscon/imx7-src.h b/include/linux/mfd/syscon/imx7-src.h
new file mode 100644
index 0000000..fdc4806
--- /dev/null
+++ b/include/linux/mfd/syscon/imx7-src.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2017 Impinj
+ *
+ * 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.
+ */
+
+#ifndef __LINUX_IMX7_SRC_H
+#define __LINUX_IMX7_SRC_H
+
+#define SRC_PCIEPHY_RCR		0x2c
+
+#define IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST	BIT(1)
+#define IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN	BIT(2)
+#define IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN	BIT(6)
+
+#endif /* __LINUX_IMX7_IOMUXC_GPR_H */
-- 
2.9.3

^ permalink raw reply related

* Re: [PATCH v2 2/3] dt-bindings: mtd: add a common label property to all mtd devices
From: Rob Herring @ 2017-01-19 16:42 UTC (permalink / raw)
  To: Cédric Le Goater
  Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
	Marek Vasut, linux-mtd, Cyrille Pitchen, Brian Norris,
	David Woodhouse
In-Reply-To: <1484578600-25994-1-git-send-email-clg@kaod.org>

On Mon, Jan 16, 2017 at 03:56:40PM +0100, Cédric Le Goater wrote:
> This can be used to easily identify a specific chip on a system with
> multiple chips.
> 
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
>  Documentation/devicetree/bindings/mtd/common.txt | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/common.txt

Acked-by: Rob Herring <robh@kernel.org>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH v13 2/5] tee: generic TEE subsystem
From: Jens Wiklander @ 2017-01-19 16:45 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: valentin.manea, devicetree, javier, emmanuel.michel,
	Greg Kroah-Hartman, Mark Rutland, Will Deacon, linux-kernel,
	Wei Xu, Nishanth Menon, Jason Gunthorpe, Rob Herring, broonie,
	Al Viro, Andrew F. Davis, Olof Johansson, Andrew Morton,
	jean-michel.delorme, Michal Simek, linux-arm-kernel
In-Reply-To: <5825882.vZRDMrBMkW@wuerfel>

Hi Arnd,

This is the old v13 patch set you're commenting, but it doesn't matter
it's essentially identical to v14 in this patch.

On Wed, Jan 18, 2017 at 09:19:25PM +0100, Arnd Bergmann wrote:
> On Friday, November 18, 2016 3:51:37 PM CET Jens Wiklander wrote:
> > Initial patch for generic TEE subsystem.
> > This subsystem provides:
> > * Registration/un-registration of TEE drivers.
> > * Shared memory between normal world and secure world.
> > * Ioctl interface for interaction with user space.
> > * Sysfs implementation_id of TEE driver
> > 
> > A TEE (Trusted Execution Environment) driver is a driver that interfaces
> > with a trusted OS running in some secure environment, for example,
> > TrustZone on ARM cpus, or a separate secure co-processor etc.
> > 
> > The TEE subsystem can serve a TEE driver for a Global Platform compliant
> > TEE, but it's not limited to only Global Platform TEEs.
> > 
> > This patch builds on other similar implementations trying to solve
> > the same problem:
> > * "optee_linuxdriver" by among others
> >   Jean-michel DELORME<jean-michel.delorme@st.com> and
> >   Emmanuel MICHEL <emmanuel.michel@st.com>
> > * "Generic TrustZone Driver" by Javier González <javier@javigon.com>
> 
> Can you give an example for a system that would contain more than one
> TEE? I see that you support dynamic registration, and it's clear that
> there can be more than one type of TEE, but why would one have more
> than one at a time, and why not more than 32?

I know that ST has systems where there's one TEE in TrustZone and
another TEE on a separate secure co-processor. If you have several TEEs
it's probably because they have different capabilities (performance
versus level of security). Just going beyond two or three different
levels of security with different TEEs sounds a bit extreme, so a
maximum of 32 or 16 should be fairly safe. If it turns out I'm wrong in
this assumption it's not that hard to correct it.

> 
> > +static int tee_ioctl_invoke(struct tee_context *ctx,
> > +			    struct tee_ioctl_buf_data __user *ubuf)
> > +{
> > +	int rc;
> > +	size_t n;
> > +	struct tee_ioctl_buf_data buf;
> > +	struct tee_ioctl_invoke_arg __user *uarg;
> > +	struct tee_ioctl_invoke_arg arg;
> > +	struct tee_ioctl_param __user *uparams = NULL;
> > +	struct tee_param *params = NULL;
> > +
> > +	if (!ctx->teedev->desc->ops->invoke_func)
> > +		return -EINVAL;
> > +
> > +	if (copy_from_user(&buf, ubuf, sizeof(buf)))
> > +		return -EFAULT;
> > +
> > +	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
> > +	    buf.buf_len < sizeof(struct tee_ioctl_invoke_arg))
> > +		return -EINVAL;
> > +
> > +	uarg = (struct tee_ioctl_invoke_arg __user *)(unsigned long)buf.buf_ptr;
> 
> u64_to_user_ptr()

Thanks, that's convenient.

> 
> > +	if (copy_from_user(&arg, uarg, sizeof(arg)))
> > +		return -EFAULT;
> > +
> > +	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
> > +		return -EINVAL;
> > +
> > +	if (arg.num_params) {
> > +		params = kcalloc(arg.num_params, sizeof(struct tee_param),
> > +				 GFP_KERNEL);
> > +		if (!params)
> > +			return -ENOMEM;
> 
> It would be good to have an upper bound on the number of parameters
> to limit the size of the memory allocation here.

This is already limited due to:

The test with: buf.buf_len > TEE_MAX_ARG_SIZE

And then another test that the number of parameters matches the buffer size
with: sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len

> 
> > +int tee_device_register(struct tee_device *teedev)
> > +{
> > +	int rc;
> > +
> > +	/*
> > +	 * If the teedev already is registered, don't do it again. It's
> > +	 * obviously an error to try to register twice, but if we return
> > +	 * an error we'll force the driver to remove the teedev.
> > +	 */
> > +	if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
> > +		dev_err(&teedev->dev, "attempt to register twice\n");
> > +		return 0;
> > +	}
> 
> I don't understand what you are protecting against here.
> How would we get to this function twice for the same device?
> 
> Could you change the caller so it doesn't happen?

Yes the caller can be changed, I'll return an error instead (and remove
the comment).

> 
> > +/**
> > + * struct tee_ioctl_param - parameter
> > + * @attr: attributes
> > + * @memref: a memory reference
> > + * @value: a value
> > + *
> > + * @attr & TEE_PARAM_ATTR_TYPE_MASK indicates if memref or value is used in
> > + * the union. TEE_PARAM_ATTR_TYPE_VALUE_* indicates value and
> > + * TEE_PARAM_ATTR_TYPE_MEMREF_* indicates memref. TEE_PARAM_ATTR_TYPE_NONE
> > + * indicates that none of the members are used.
> > + */
> > +struct tee_ioctl_param {
> > +	__u64 attr;
> > +	union {
> > +		struct tee_ioctl_param_memref memref;
> > +		struct tee_ioctl_param_value value;
> > +	} u;
> > +};
> > +
> > +#define TEE_IOCTL_UUID_LEN		16
> > +
> 
> Having a union in an ioctl argument seems odd. Have you considered
> using two different ioctl command numbers depending on the type?

struct tee_ioctl_param is used as an array and some parameters can be
memrefs while other are values.

> 
> > +/**
> > + * struct tee_iocl_supp_send_arg - Send a response to a received request
> > + * @ret:	[out] return value
> > + * @num_params	[in] number of parameters following this struct
> > + */
> > +struct tee_iocl_supp_send_arg {
> > +	__u32 ret;
> > +	__u32 num_params;
> > +	/*
> > +	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
> > +	 * which follows requires 8 byte alignment.
> > +	 *
> > +	 * Commented out element used to visualize the layout dynamic part
> > +	 * of the struct. This field is not available at all if
> > +	 * num_params == 0.
> > +	 *
> > +	 * struct tee_ioctl_param params[num_params];
> > +	 */
> > +} __aligned(8);
> 
> I'd make that 
> 
> 	struct tee_ioctl_param params[0];
> 
> as wel here, as I also commented in patch 3 that has a similar structure.

I'm concerned that this may cause warnings when compiling for user space
depending on compiler and options. Am I too cautious here?
 
Thanks,
Jens

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 3/3] PCI: imx6: Add code to support i.MX7D
From: Lucas Stach @ 2017-01-19 16:52 UTC (permalink / raw)
  To: Andrey Smirnov
  Cc: linux-pci, yurovsky, Richard Zhu, Bjorn Helgaas, Fabio Estevam,
	Shawn Guo, Rob Herring, Mark Rutland, Lee Jones, linux-arm-kernel,
	devicetree, linux-kernel
In-Reply-To: <20170119163631.10668-4-andrew.smirnov@gmail.com>

Am Donnerstag, den 19.01.2017, 08:36 -0800 schrieb Andrey Smirnov:
> Add various bits of code needed to support i.MX7D variant of the IP.
> 
> Cc: yurovsky@gmail.com
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
>  .../devicetree/bindings/pci/fsl,imx6q-pcie.txt     |   6 +-
>  drivers/pci/host/pci-imx6.c                        | 188 ++++++++++++++++++---
>  include/linux/mfd/syscon/imx7-gpc.h                |  18 ++
>  include/linux/mfd/syscon/imx7-iomuxc-gpr.h         |   4 +
>  include/linux/mfd/syscon/imx7-src.h                |  18 ++
>  5 files changed, 208 insertions(+), 26 deletions(-)
>  create mode 100644 include/linux/mfd/syscon/imx7-gpc.h
>  create mode 100644 include/linux/mfd/syscon/imx7-src.h
> 
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index 83aeb1f..20b9382 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>  and thus inherits all the common properties defined in designware-pcie.txt.
>  
>  Required properties:
> -- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
> +- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie",
> +  	      "fsl,imx6qp-pcie", "fsl,imx7d-pcie"
>  - reg: base address and length of the PCIe controller
>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>    entry for each entry in the interrupt-names property.
> @@ -34,6 +35,9 @@ Additional required properties for imx6sx-pcie:
>  - clock names: Must include the following additional entries:
>  	- "pcie_inbound_axi"
>  
> +Additional required properties for imx7d-pcie:
> +- pcie-phy-supply: Should specify the regulator supplying PCIe PHY
> +
This isn't a PHY regulator, but a regulator powering the GPC domain
where the PHY is located. This should not be handled in the PCIe driver.
See the previous discussion with i.MX6SX, that is in the same boat.

[...]
>  static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
>  {
> -	if (imx6_pcie->variant == IMX6SX)
> +	switch (imx6_pcie->variant) {
> +	case IMX7D: {
> +		int ret;
> +		unsigned int reg, mapping;
> +		struct pcie_port *pp = &imx6_pcie->pp;
> +		struct device *dev = pp->dev;
> +
> +		regulator_set_voltage(imx6_pcie->pcie_phy_regulator,
> +				      1000000, 1000000);
> +		ret = regulator_enable(imx6_pcie->pcie_phy_regulator);
> +		if (ret) {
> +			dev_err(dev, "failed to enable pcie regulator.\n");
> +			return;
> +		}
> +
> +		/*
> +		 * Now that PHY regulator is enabled, do sofware
> +		 * power-up request by mapping PHY in A7 domain and
> +		 * setting power-up request bit
> +		 */
> +		regmap_read(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, &mapping);
> +		regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING,
> +			     mapping | IMX7D_PCIE_PHY_A7_DOMAIN);
> +
> +		regmap_update_bits(imx6_pcie->gpc, GPC_PU_PGC_SW_PUP_REQ,
> +				   IMX7D_PCIE_PHY_SW_PUP_REQ,
> +				   IMX7D_PCIE_PHY_SW_PUP_REQ);
> +		/*
> +		 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
> +		 * for PUP_REQ bit to be cleared
> +		 */
> +		while (!regmap_read(imx6_pcie->gpc,
> +				    GPC_PU_PGC_SW_PUP_REQ, &reg) &&
> +		       reg & IMX7D_PCIE_PHY_SW_PUP_REQ)
> +			;
> +		regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, mapping);

I won't allow code touching the GPC registers to sneak into the PCIe
driver. I know this is the downstream solution, but this really needs a
proper GPC power domain driver, instead of this hack.

Regards,
Lucas

^ permalink raw reply

* [RESENT PATCH] ARM: bcm2835: Add devicetree for the Raspberry Pi 3, for arm (32)
From: Gerd Hoffmann @ 2017-01-19 17:04 UTC (permalink / raw)
  To: linux-rpi-kernel
  Cc: Gerd Hoffmann, Rob Herring, Mark Rutland, Russell King,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	moderated list:ARM PORT, open list

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 arch/arm/boot/dts/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..82a760d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -70,7 +70,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
 	bcm2835-rpi-b-plus.dtb \
 	bcm2835-rpi-a-plus.dtb \
 	bcm2836-rpi-2-b.dtb \
-	bcm2835-rpi-zero.dtb
+	bcm2835-rpi-zero.dtb \
+	../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += \
 	bcm4708-asus-rt-ac56u.dtb \
 	bcm4708-asus-rt-ac68u.dtb \
-- 
1.8.3.1

^ permalink raw reply related

* Re: [PATCH 0/2] ARM: DTS: Fix broken GICv2 register maps
From: Tony Lindgren @ 2017-01-19 17:08 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Mark Rutland, Heiko Stuebner, Magnus Damm, Russell King,
	Krzysztof Kozlowski, Javier Martinez Canillas, Chen-Yu Tsai, arm,
	Tsahee Zidenberg, devicetree, Jason Cooper, Arnd Bergmann,
	Simon Horman, Santosh Shilimkar, Matthias Brugger,
	Benoît Cousson, Thomas Gleixner, linux-arm-kernel,
	Antoine Tenart, linux-kernel, Rob Herring, Kukjin Kim,
	Sascha Hauer
In-Reply-To: <16613dbe-08b9-98d8-c747-a977e78601b1@arm.com>

* Marc Zyngier <marc.zyngier@arm.com> [170118 05:09]:
> On 18/01/17 12:34, Arnd Bergmann wrote:
> > On Wednesday, January 18, 2017 10:53:29 AM CET Marc Zyngier wrote:
> >> For a GICv2 (which happens to be virtualization capable), the
> >> architecture mandates the following regions:
> >>
> >> 	     GICD: 4kB
> >> 	     GICC: 8kB
> >> 	     GICH: 8kB
> >> 	     GICV: 8kB
> >>
> >> Unfortunately, I made a mistake in one of the examples contained in
> >> the DT binding document, and everyone duplicated that same mistake all
> >> over the map.
> >>
> >> This small series fixes the DT binding, and hopefully updates all the
> >> offending DTs to be compliant with the architecture.
> >>
> > 
> > Looks good to me, can you send this as a pull request to arm@kernel.org
> > once you have collected a reasonable number of Acks?
> 
> Sure, will do.
> 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>

Here's yet another ack to paste for both patches:

Acked-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply

* Re: [PATCH 4/5] dt: add bindings for ZTE tvenc device
From: Lucas Stach @ 2017-01-19 17:11 UTC (permalink / raw)
  To: Shawn Guo
  Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, dri-devel,
	Rob Herring, Jun Nie
In-Reply-To: <1484843100-16284-5-git-send-email-shawnguo@kernel.org>

Am Freitag, den 20.01.2017, 00:24 +0800 schrieb Shawn Guo:
> From: Shawn Guo <shawn.guo@linaro.org>
> 
> It adds bindings doc for ZTE VOU TV Encoder device.
> 
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
>  Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt
> index 740e5bd2e4f7..9c356284232b 100644
> --- a/Documentation/devicetree/bindings/display/zte,vou.txt
> +++ b/Documentation/devicetree/bindings/display/zte,vou.txt
> @@ -49,6 +49,15 @@ Required properties:
>  	"osc_clk"
>  	"xclk"
>  
> +* TV Encoder output device
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-tvenc"
> + - reg: Physical base address and length of the TVENC device IO region
> + - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two
> +   integer cells.  The first cell is the offset of SYSCTRL register used
> +   to control TV Encoder DAC power, and the second cell is the bit mask.

I don't know much about this platform, but shouldn't this be handled
with a proper power domain driver, rather than bashing bits directly?

Regards,
Lucas

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH linux v3 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC
From: Rob Herring @ 2017-01-19 17:12 UTC (permalink / raw)
  To: eajames.ibm
  Cc: linux, devicetree, linux-kernel, linux-hwmon, linux-doc, jdelvare,
	corbet, mark.rutland, wsa, andrew, joel, benh, Edward A. James
In-Reply-To: <1484601219-30196-6-git-send-email-eajames.ibm@gmail.com>

On Mon, Jan 16, 2017 at 03:13:38PM -0600, eajames.ibm@gmail.com wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
> 
> Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
> well as probe the entire driver from the I2C bus. I2C is the communication
> method between the BMC and the P8 OCC.
> 
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
>  Documentation/devicetree/bindings/hwmon/occ.txt |  13 +++

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/hwmon/occ/Kconfig                       |  14 ++++
>  drivers/hwmon/occ/Makefile                      |   1 +
>  drivers/hwmon/occ/p8_occ_i2c.c                  | 104 ++++++++++++++++++++++++
>  4 files changed, 132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
>  create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c

^ permalink raw reply

* Re: [PATCH V2 3/4] arm64: dts: Enable SDHCI for Nexus 5X (msm8992)
From: Rob Herring @ 2017-01-19 17:21 UTC (permalink / raw)
  To: Jeremy McNicoll
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-soc-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA,
	andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
	arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
	riteshh-sgV2jX0FEOL9JmXXK+q4OQ, git-LJ92rlH3Dns,
	ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
	jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <1484614729-26751-4-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Mon, Jan 16, 2017 at 04:58:48PM -0800, Jeremy McNicoll wrote:
> Add Nexus 5X (msm8992) SDHCI support, including initial regulator
> entries to support enabling the main SDHCI/MMC.
> 
> The RPM is common between 8992 & 8994 simply reflect reality with
> a shared DT entry.
> 
> The msm8994 RPM regulator talks over SMD to the APPS processor.
> 
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> 
> Dropped RobH's ACK explicitly after addressing all feedback.
> The reason is that msm8994-smd-rpm.dtsi was created to allow
> for sharing between 8992 & 8994 as the RPM is common between
> the two. 
> 
>  .../bindings/regulator/qcom,smd-rpm-regulator.txt  |  40 +++
>  .../boot/dts/qcom/msm8992-bullhead-rev-101.dts     |   2 +
>  arch/arm64/boot/dts/qcom/msm8992-pins.dtsi         |  82 ++++++
>  arch/arm64/boot/dts/qcom/msm8992.dtsi              | 153 ++++++++++++
>  arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi      | 276 +++++++++++++++++++++

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  drivers/regulator/qcom_smd-regulator.c             |  49 ++++
>  6 files changed, 602 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi
--
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 4/4] dts: doc: rename rpm_requests to respect DT naming conventions
From: Rob Herring @ 2017-01-19 17:22 UTC (permalink / raw)
  To: Jeremy McNicoll
  Cc: linux-arm-msm, linux-soc, devicetree, linux-mmc, andy.gross,
	sboyd, arnd, bjorn.andersson, riteshh, git, ulf.hansson, jszhang
In-Reply-To: <1484614729-26751-5-git-send-email-jeremymc@redhat.com>

On Mon, Jan 16, 2017 at 04:58:49PM -0800, Jeremy McNicoll wrote:
> Node names cannot have an underscore '_' in the name.
> Simply rename 'rpm_request' nodes to 'rpm-request'.
> 
> Signed-off-by: Jeremy McNicoll <jeremymc@redhat.com>
> ---
>  Documentation/devicetree/bindings/clock/qcom,rpmcc.txt              | 2 +-
>  .../devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt        | 2 +-
>  Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt         | 6 +++---
>  Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt             | 2 +-
>  arch/arm/boot/dts/qcom-apq8074-dragonboard.dts                      | 2 +-
>  arch/arm/boot/dts/qcom-apq8084.dtsi                                 | 2 +-
>  arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts            | 2 +-
>  arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts               | 2 +-
>  arch/arm/boot/dts/qcom-msm8974.dtsi                                 | 2 +-
>  arch/arm64/boot/dts/qcom/msm8916.dtsi                               | 2 +-
>  arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi                       | 2 +-
>  11 files changed, 13 insertions(+), 13 deletions(-)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v3 1/3] dt: bindings: add documentation for zx2967 family reset controller
From: Rob Herring @ 2017-01-19 17:27 UTC (permalink / raw)
  To: Baoyou Xie
  Cc: jun.nie-QSEj5FYQhm4dnm+yROfE0A, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
	mark.rutland-5wv7dgnIgG8,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
	xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
	chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
	wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1484623377-16208-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On Tue, Jan 17, 2017 at 11:22:55AM +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family
> reset controller.
> 
> Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>  .../devicetree/bindings/reset/zte,zx2967-reset.txt   | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Rob Herring @ 2017-01-19 17:36 UTC (permalink / raw)
  To: Raviteja Garimella
  Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484640308-25976-5-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>

On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
> This patch adds device tree bindings documentation for Synopsys
> USB device controller platform driver.

Bindings describe h/w, not drivers.
> 
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
>  .../devicetree/bindings/usb/snps,dw-ahb-udc.txt    | 27 ++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> new file mode 100644
> index 0000000..0c18327
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> @@ -0,0 +1,27 @@
> +Synopsys USB Device controller.
> +
> +The device node is used for Synopsys Designware Cores AHB
> +Subsystem Device Controller (UDC).
> +
> +This device node is used by UDCs integrated it Broadcom's
> +Northstar2 and Cygnus SoC's.

You need compatible strings for these in addition.

> +
> +Required properties:
> + - compatible: should be "snps,dw-ahb-udc"

This is a different IP than DWC2?

> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> + - extcon: phandle to the extcon device. This is optional and
> +   not required for those that don't require extcon support.
> +   Extcon support will be required if the UDC is connected to
> +   a Dual Role Device Phy that supports both Host and Device
> +   mode based on the external cable.

Drop this. It should be a part of the phy. Also, I don't care to see new 
users of extcon binding because it needs redoing.
--
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 12/14] ARM: dts: da850: add the SATA node
From: Sergei Shtylyov @ 2017-01-19 17:45 UTC (permalink / raw)
  To: Bartosz Golaszewski, Kevin Hilman, Sekhar Nori, Patrick Titiano,
	Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
	Russell King, David Lechner
  Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484832588-18413-13-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

On 01/19/2017 04:29 PM, Bartosz Golaszewski wrote:

> Add the SATA node to the da850 device tree.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  arch/arm/boot/dts/da850.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 104155d..e9bf30e 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -403,6 +403,12 @@
>  			phy-names = "usb-phy";
>  			status = "disabled";
>  		};
> +		sata: ahci@218000 {

    No, according to devicetree.org the node name should be "sata@218000" and 
the label can be whatever you want.

[...]

MBR, Sergei

--
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 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
From: Chris Paterson @ 2017-01-19 17:46 UTC (permalink / raw)
  To: Ramesh Shanmugasundaram, Laurent Pinchart, Hans Verkuil
  Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland,
	Mauro Carvalho Chehab, Sakari Ailus, Antti Palosaari,
	Geert Uytterhoeven, Linux Media Mailing List,
	devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <HK2PR06MB0545BF36C3DD2D4D1B951C3FC3670@HK2PR06MB0545.apcprd06.prod.outlook.com>

Hello Hans,

Do you have any further feedback on this?

Thanks, Chris


> From: Ramesh Shanmugasundaram
> Sent: 10 January 2017 09:31
> Hi Laurent,
> 
> > > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram
> wrote:
> > > >>>> Add binding documentation for Renesas R-Car Digital Radio
> > > >>>> Interface
> > > >>>> (DRIF) controller.
> > > >>>>
> > > >>>> Signed-off-by: Ramesh Shanmugasundaram
> > > >>>> <ramesh.shanmugasundaram@bp.renesas.com> ---
> > > >>>>
> > > >>>>  .../devicetree/bindings/media/renesas,drif.txt     | 202
> > +++++++++++++
> > > >>>>  1 file changed, 202 insertions(+)  create mode 100644
> > > >>>>
> > > >>>> Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>>
> > > >>>> diff --git
> > > >>>> a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new
> > > >>>> file mode 100644 index 0000000..1f3feaf
> > > >>>> --- /dev/null
> > > >>>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > > >>>>
> > > >>>> +Optional properties of an internal channel when:
> > > >>>> +     - It is the only enabled channel of the bond (or)
> > > >>>> +     - If it acts as primary among enabled bonds
> > > >>>> +--------------------------------------------------------
> > > >>>> +- renesas,syncmd       : sync mode
> > > >>>> +                      0 (Frame start sync pulse mode. 1-bit
> > > >>>> +width
> > > >>>> pulse
> > > >>>> +                         indicates start of a frame)
> > > >>>> +                      1 (L/R sync or I2S mode) (default)
> > > >>>> +- renesas,lsb-first    : empty property indicates lsb bit is
> > received
> > > >>>> first.
> > > >>>> +                      When not defined msb bit is received
> > > >>>> +first
> > > >>>> +(default)
> > > >>>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1
> > > >>>> +for
> > > >>>> low/high
> > >
> > > Shouldn't this be 'renesas,sync-active' instead of syncac-active?
> > >
> > > I'm not sure if syncac is intended or if it is a typo.
> > >
> > > >>>> +                      respectively. The default is 1 (active high)
> > > >>>> +- renesas,dtdl         : delay between sync signal and start of
> > > >>>> reception.
> > > >>>> +                      The possible values are represented in
> > > >>>> + 0.5
> > clock
> > > >>>> +                      cycle units and the range is 0 to 4. The
> > default
> > > >>>> +                      value is 2 (i.e.) 1 clock cycle delay.
> > > >>>> +- renesas,syncdl       : delay between end of reception and sync
> > > >>>> signal edge.
> > > >>>> +                      The possible values are represented in
> > > >>>> + 0.5
> > clock
> > > >>>> +                      cycle units and the range is 0 to 4 & 6.
> > > >>>> + The
> > > >>>> default
> > > >>>> +                      value is 0 (i.e.) no delay.
> > > >>>
> > > >>> Most of these properties are pretty similar to the video bus
> > > >>> properties defined at the endpoint level in
> > > >>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
> > > >>> believe it would make sense to use OF graph and try to
> > > >>> standardize these properties similarly.
> > >
> > > Other than sync-active, is there really anything else that is similar?
> > > And even the sync-active isn't a good fit since here there is only
> > > one sync signal instead of two for video (h and vsync).
> >
> > That's why I said similar, not identical :-) My point is that, if we
> > consider that we could connect multiple sources to the DRIF, using OF
> > graph would make sense, and the above properties should then be
> > defined per endpoint.
> 
> Thanks for the clarifications. I have some questions.
> 
> - Assuming two devices are interfaced with DRIF and they are represented
> using two endpoints, the control signal related properties of DRIF might still
> need to be same for both endpoints? For e.g. syncac-active cannot be
> different in both endpoints?
> 
> - I suppose "lsb-first", "dtdl" & "syncdl" may be defined per endpoint.
> However, h/w manual says same register values needs to be programmed
> for both the internal channels of a channel. Same with "syncmd" property.
> 
> We could still define them as per endpoint property with a note that they
> need to be same. But I am not sure if that is what you intended?
> 
>  If we define them per endpoint we should then also try
> > standardize the ones that are not really Renesas-specific (that's at
> > least syncac-active).
> 
> OK. I will call it "sync-active".
> 
>  For the syncmd and lsb-first properties, it could also
> > make sense to query them from the connected subdev at runtime, as
> > they're similar in purpose to formats and media bus configuration
> > (struct v4l2_mbus_config).
> 
> May I know in bit more detail about what you had in mind? Please correct me
> if my understanding is wrong here but when I looked at the code
> 
> 1) mbus_config is part of subdev_video_ops only. I assume we don't want to
> support this as part of tuner subdev. The next closest is pad_ops with "struct
> v4l2_mbus_framefmt" but it is fully video specific config unless I come up
> with new MEDIA_BUS_FMT_xxxx in media-bus-format.h and use the code
> field? For e.g.
> 
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_BE       0x7001
> #define MEDIA_BUS_FMT_SDR_I2S_PADHI_LE       0x7002
> 
> 2) The framework does not seem to mandate pad ops for all subdev. As the
> tuner can be any third party subdev, is it fair to assume that these properties
> can be queried from subdev?
> 
> 3) Assuming pad ops is not available on the subdev shouldn't we still need a
> way to define these properties on DRIF DT?
> 
> >
> > I'm not an SDR expert, so I'd like to have your opinion on this.
> >
> > > >> Note that the last two properties match the those in
> > > >> Documentation/devicetree/bindings/spi/sh-msiof.txt.
> > > >> We may want to use one DRIF channel as a plain SPI slave with the
> > > >> (modified) MSIOF driver in the future.
> > > >
> > > > Should I leave it as it is or modify these as in video-interfaces.txt?
> > > > Shall we conclude on this please?
> >
> 
> Thanks,
> Ramesh

^ permalink raw reply

* Re: [PATCH v2 0/5] Reset Controller Nodes for TI Keystone platforms
From: santosh.shilimkar @ 2017-01-19 17:46 UTC (permalink / raw)
  To: Suman Anna, Santosh Shilimkar
  Cc: devicetree, Russell King, linux-kernel, Rob Herring,
	Philipp Zabel, Andrew Davis, linux-arm-kernel
In-Reply-To: <e5b84f7c-fb55-25f2-8079-47b4a7ecde1a@oracle.com>

On 1/11/17 6:28 PM, santosh.shilimkar@oracle.com wrote:
> On 1/11/17 5:48 PM, Suman Anna wrote:
>> Hi Santosh,
>>
>> This is a slightly updated patch series for the reset controller nodes
>> for
>> TI Keystone2 SoCs. The only change is to rename the reset controller
>> nodes
>> from "psc-reset-controller" to just "reset-controller" following Rob
>> Herring's
>> comment on the Documentation update patch [1]. There are no changes to
>> the first
>> 2 patches. I have already posted a v2 for the Documentation update as
>> well.
>> Please pick this up instead of the v1 series [2].
>>
> I haven't picked up V1 so no worries. Even V2 I won't apply for another
> week to give some more time if there are any more comments on the
> bindings.
>
> Thanks for following up.

Series applied !!

^ permalink raw reply

* Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: santosh.shilimkar @ 2017-01-19 17:51 UTC (permalink / raw)
  To: Dave Gerlach, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
	Rob Herring
  Cc: Nishanth Menon, devicetree, linux-pm, Lokesh Vutla, Keerthy,
	Santosh Shilimkar, linux-kernel, Tero Kristo, Russell King,
	Sudeep Holla, linux-arm-kernel
In-Reply-To: <bf9286b1-379d-1cc8-4eae-d268540dd2a6@ti.com>

On 1/4/17 2:06 PM, Dave Gerlach wrote:
> Santosh,
> On 01/04/2017 03:54 PM, Santosh Shilimkar wrote:
>> On 1/4/2017 12:55 PM, Dave Gerlach wrote:
>>> Hi,
>>> This is v3 of the series to add support for TI-SCI Generic PM Domains.
>>> Previous versions can be found here:
>>>
>>> v2: https://www.spinics.net/lists/kernel/msg2364612.html
>>> v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
>>>
>>> This version is rebased on v4.10-rc2 but is the same as v2 with the
>>> exception of patch 2 in which the devicetree binding documentation
>>> needed to be updated to show the k2g_pds node should be a child of
>>> the pmmc node. Apart from that, the acks provided by Ulf were added
>>> to patches 1 and 3.
>>>
>>> Now that the TI-SCI series has been merged [1] this series will be ready
>>> to go in with an ack on the DT binding. Rob had raised some questions on
>>> the necessity ti,sci-id property but I believe these were properly
>>> addressed during the discussion of v2 so hopefully an ack is in order
>>> now.
>>>
>> How do you plan to merge this series with below patch ?
>>
>>>   PM / Domains: Add generic data pointer to genpd data struct
>> I think this one goes via Rafael's tree. If you want me to merge this
>> along with other patches then will need his ack.
>>
>> Other way is to get that merged first via Rafael's tree and then
>> the remainder series.
>
> I'd be happy with it going in through your tree with an ack to avoid any
> delay but I'd say it's Rafael's call as it is a patch to the genpd core,
> even though at this point I am the only user.
>
Am going to send pull request over weekend, so if you would like
me take the series via arm-soc tree, please get Rafaels, ack and
let me know.

Regards,
Santosh

^ permalink raw reply

* Re: [PATCH v3] mtd: spi-nor: add dt support for Everspin MRAMs
From: Rob Herring @ 2017-01-19 17:54 UTC (permalink / raw)
  To: Cyrille Pitchen
  Cc: Marek Vasut, Mark Rutland, devicetree@vger.kernel.org,
	Rafał Miłecki, Masahiko Iwamoto,
	linux-mtd@lists.infradead.org, Sascha Hauer,
	Uwe Kleine-König, Geert Uytterhoeven, Jagan Teki
In-Reply-To: <82a0b0f7-a94b-70b5-1a5e-e5c04943a684@atmel.com>

On Tue, Jan 17, 2017 at 02:57:22PM +0100, Cyrille Pitchen wrote:
> Le 17/01/2017 à 14:16, Rafał Miłecki a écrit :
> > On 17 January 2017 at 12:03, Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> >> The MR25 family doesn't support JEDEC, so they need explicit mentioning
> >> in the list of supported spi IDs. This makes it possible to add these
> >> using for example:
> >>
> >>         compatible = "everspin,mr25h40";
> > 
> > (...)
> > 
> >> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> index 2c91c03e7eb0..3e920ec5c4d3 100644
> >> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> >> @@ -14,6 +14,8 @@ Required properties:
> >>                   at25df641
> >>                   at26df081a
> >>                   mr25h256
> >> +                 mr25h10
> >> +                 mr25h40
> >>                   mx25l4005a
> >>                   mx25l1606e
> >>                   mx25l6405d
> > 
> > Uh, this is getting a never-ending-story...
> > If these chipsets don't support JEDEC, should we keep them in jedec,spi-nor.txt?
> > 
> 
> Maybe not but I think the new compatible strings should be documented
> somewhere. Currently jedec,spi-nor.txt already documents all the
> "m25p*-nonjedec" memories. So maybe just renaming the jedec,spi-nor.txt
> file into spi-nor.txt or mtd,spi-nor.txt could be a solution. Otherwise, we
> can let it as is. I have no idea of what would be the best solution.

As I read the description, the non-jedec chips don't support READ ID, 
but I would assume they otherwise follow the JEDEC spec(s)?

> To be honest, I don't always fully understand the DT policy/philosophy and
> its requirements. I just thought when a new property or a new value is
> introduced it has to be documented.
> Generally speaking, when DT is involved in some series of patches, it often
> generates many discussions about the proper way to do thinks and about
> choosing the best between many technically functional solutions.

Doesn't that apply to any code review? Sounds like the kernel process to 
me. If the DT review is more stringent, then I'll take that as a 
complement.

> If you think jedec,spi-nor.txt is not suited to document the new value for
> the compatible string, why not, I perfectly understand your point.
> 
> I don't mind choosing another way. I just want to be sure that, if not all,
> most of people agree on that solution and if possible, it is compliant with
> DT policy so everybody is happy and works together.
> That's why I involve DT people, even if it's a small detail, so they can
> advise us.
> 
> Anyway, at some point we have to take a decision to carry on thinks.
> So actually, I would like to avoid a never-ending story :)

I don't know what's the right answer here with regards to renaming or 
spliting things. In either case, that's a separate issue from this 
patch.

Rob

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox