Re: [PULL] mxsfb fixes

2017-03-05 Thread Stefan Agner
Marek, Dave,

On 2017-02-26 04:43, Marek Vasut wrote:
> Here's one with a tag, updated on drm-next again :
> 
> The following changes since commit d458079eb403fe4db625af349329e312c976d743:
> 
>   drm/tinydrm: fix mipi-dbi warning. (2017-02-24 13:23:36 +1000)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git
> tags/mxsfb-fixes-20170226


With 4.11-rc1 i.MX 7 fails for me with:
OF: graph: no port node found in /soc/aips-bus@3040/lcdif@3073
Unable to handle kernel NULL pointer dereference at virtual address
0004

Afaik, this should be fixed with ("drm: mxsfb: Fix crash when provided
invalid DT bindings"), but the pull did not make it...

Can we get this into 4.11?

--
Stefan


> 
> for you to fetch changes up to d83574b9f0494d8bc4f00704483c6f1d3cd3ce30:
> 
>   drm: mxsfb: Implement drm_panel handling (2017-02-26 13:22:05 +0100)
> 
> 
> Fabio Estevam (2):
>   drm: mxsfb_crtc: Fix the framebuffer misplacement
>   drm: mxsfb: Implement drm_panel handling
> 
> Marek Vasut (1):
>   drm: mxsfb: Fix crash when provided invalid DT bindings
> 
> Stefan Agner (2):
>   drm: mxsfb: use bus_format to determine LCD bus width
>   drm: mxsfb: fix pixel clock polarity
> 
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 49
> +++--
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 
>  drivers/gpu/drm/mxsfb/mxsfb_out.c  |  4 
>  drivers/gpu/drm/mxsfb/mxsfb_regs.h |  1 +
>  4 files changed, 52 insertions(+), 6 deletions(-)
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 1/5] arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI node

2017-03-05 Thread Hoegeun Kwon

On 03/06/2017 01:49 PM, Andi Shyti wrote:

Hi Hoegeun,

On Mon, Mar 06, 2017 at 01:42:19PM +0900, Hoegeun Kwon wrote:

The OF graph is not needed because the panel is a child of dsi. Add
the burst and esc clock frequency properties to the parent (DSI node).

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 

you forgot to put me in Cc and add my

Reviewed-by: Andi Shyti 


Sorry Andi, I mistake... :(
Thanks for all your review.

Best Regards,
Hoegeun



Andi




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


[PATCH v4 0/5] Fix the parse_dt of exynos dsi and remove the OF graph

2017-03-05 Thread Hoegeun Kwon
Hi All,

The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel.

So the 1/5 patch parse the Pll, burst and esc clock frequency
properties in dsi_parse_dt and modified to create a bridge_node only
if there is an OF graph associated with dsi.

Also fixed the dts, which depend on the 1/5 patch. So removed the
ports node and move burst and esc clock frequency properties to the
parent (DSI node).

Changes for V4:
- Squashed patch 2, 3 and 4.
- Added Reviewed-by: Andrzej Hajda  on all patches.

Changes for V3:
- Split the patches considering the bisectability problem.

Changes for V2:
- Added the clear explanation for commit. (1/5 patch)
- Fixed it to the same subject as the actual work. (2/5 ~ 5/5 patches)

Best Regards,
Hoegeun

Hoegeun Kwon (5):
  arm64: dts: exynos: Add the burst and esc clock frequency properties
to DSI node
  arm: dts: Add the burst and esc clock frequency properties to DSI node
  drm/exynos: dsi: Fix the parse_dt function
  arm64: dts: exynos: Remove the OF graph from DSI node
  arm: dts: Remove the OF graph from DSI node

 arch/arm/boot/dts/exynos3250-rinato.dts| 23 ++--
 arch/arm/boot/dts/exynos4210-trats.dts | 23 ++--
 arch/arm/boot/dts/exynos4412-trats2.dts| 23 ++--
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 32 ++
 5 files changed, 16 insertions(+), 101 deletions(-)

-- 
1.9.1

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


[PATCH v4 2/5] arm: dts: Add the burst and esc clock frequency properties to DSI node

2017-03-05 Thread Hoegeun Kwon
The OF graph is not needed because the panel is a child of dsi. Add
the burst and esc clock frequency properties to the parent (DSI node).

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 2 ++
 arch/arm/boot/dts/exynos4210-trats.dts  | 2 ++
 arch/arm/boot/dts/exynos4412-trats2.dts | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 548413e..c9f191c 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -215,6 +215,8 @@
 &dsi_0 {
vddcore-supply = <&ldo6_reg>;
vddio-supply = <&ldo6_reg>;
+   samsung,burst-clock-frequency = <25000>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 0ca1b4d..1743ca8 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -197,6 +197,8 @@
 &dsi_0 {
vddcore-supply = <&vusb_reg>;
vddio-supply = <&vmipi_reg>;
+   samsung,burst-clock-frequency = <5>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 41ecd6d..82221a0 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -385,6 +385,8 @@
 &dsi_0 {
vddcore-supply = <&ldo8_reg>;
vddio-supply = <&ldo10_reg>;
+   samsung,burst-clock-frequency = <5>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-- 
1.9.1

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


[PATCH v4 3/5] drm/exynos: dsi: Fix the parse_dt function

2017-03-05 Thread Hoegeun Kwon
The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel. So this patch parse the Pll, burst and esc clock frequency
properties in dsi_parse_dt and modified to create a bridge_node only
if there is an OF graph associated with dsi.
So I think the ABI breakage is needed.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index f5c04d0..2d4e118 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1652,39 +1652,23 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
 
-   ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
-   if (!ep) {
-   dev_err(dev, "no output port with endpoint specified\n");
-   return -EINVAL;
-   }
-
-   ret = exynos_dsi_of_read_u32(ep, "samsung,burst-clock-frequency",
+   ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
 &dsi->burst_clk_rate);
if (ret < 0)
-   goto end;
+   return ret;
 
-   ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
+   ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
 &dsi->esc_clk_rate);
if (ret < 0)
-   goto end;
-
-   of_node_put(ep);
+   return ret;
 
ep = of_graph_get_next_endpoint(node, NULL);
-   if (!ep) {
-   ret = -EINVAL;
-   goto end;
-   }
-
-   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
-   if (!dsi->bridge_node) {
-   ret = -EINVAL;
-   goto end;
+   if (ep) {
+   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
}
-end:
-   of_node_put(ep);
 
-   return ret;
+   return 0;
 }
 
 static int exynos_dsi_bind(struct device *dev, struct device *master,
-- 
1.9.1

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


[PATCH v4 4/5] arm64: dts: exynos: Remove the OF graph from DSI node

2017-03-05 Thread Hoegeun Kwon
The OF graph is not needed because the panel is a child of dsi. Remove
the ports node in DSI node.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 14 --
 1 file changed, 14 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e31e20c..77ba238 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -303,20 +303,6 @@
samsung,pll-clock-frequency = <2400>;
pinctrl-names = "default";
pinctrl-0 = <&te_irq>;
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   samsung,burst-clock-frequency = <51200>;
-   samsung,esc-clock-frequency = <1600>;
-   };
-   };
-   };
 };
 
 &hdmi {
-- 
1.9.1

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


[PATCH v4 1/5] arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI node

2017-03-05 Thread Hoegeun Kwon
The OF graph is not needed because the panel is a child of dsi. Add
the burst and esc clock frequency properties to the parent (DSI node).

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 6ce93a3..e31e20c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -298,6 +298,8 @@
status = "okay";
vddcore-supply = <&ldo6_reg>;
vddio-supply = <&ldo7_reg>;
+   samsung,burst-clock-frequency = <51200>;
+   samsung,esc-clock-frequency = <1600>;
samsung,pll-clock-frequency = <2400>;
pinctrl-names = "default";
pinctrl-0 = <&te_irq>;
-- 
1.9.1

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


[PATCH v4 5/5] arm: dts: Remove the OF graph from DSI node

2017-03-05 Thread Hoegeun Kwon
The OF graph is not needed because the panel is a child of dsi. Remove
the ports node in DSI node, and port node in panel node.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 21 -
 arch/arm/boot/dts/exynos4210-trats.dts  | 21 -
 arch/arm/boot/dts/exynos4412-trats2.dts | 21 -
 3 files changed, 63 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index c9f191c..82e676a 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -220,21 +220,6 @@
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <&dsi_in>;
-   samsung,burst-clock-frequency = <25000>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
compatible = "samsung,s6e63j0x03";
reg = <0>;
@@ -264,12 +249,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <&dsi_out>;
-   };
-   };
};
 };
 
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 1743ca8..9452bed 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -202,21 +202,6 @@
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <&dsi_in>;
-   samsung,burst-clock-frequency = <5>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
reg = <0>;
compatible = "samsung,s6e8aa0";
@@ -244,12 +229,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <&dsi_out>;
-   };
-   };
};
 };
 
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 82221a0..86ce5e5 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -390,21 +390,6 @@
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <&dsi_in>;
-   samsung,burst-clock-frequency = <5>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
compatible = "samsung,s6e8aa0";
reg = <0>;
@@ -432,12 +417,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <&dsi_out>;
-   };
-   };
};
 };
 
-- 
1.9.1

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


[Bug 100058] amdgpu/dpm: NULL pointer dereference

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100058

--- Comment #3 from Michel Dänzer  ---
(In reply to Adam Wolk from comment #0)
> I noticed my external display constantly turning on and off unless a DRI app
> is active (ie. running DRI_PRIME=1 glxgears).

Which GPU is the external display connected to? If you're not sure, attach the
output of xrandr.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100071] [Regression] Tomb Raider: TressFX broken with recent LLVM

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100071

--- Comment #1 from Michel Dänzer  ---
Can you either bisect LLVM, or create an apitrace which reproduces the problem?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100068] LLVM ERROR: Cannot select: intrinsic %llvm.amdgcn.buffer.load.format

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100068

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #130081|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100069] Dirt: Showdown bad performance with enabled advanced lightning

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100069

--- Comment #2 from Edward O'Callaghan  ---
(In reply to Kenneth Graunke from comment #1)
> Assigning to the radeonsi driver until we know it's a general problem...

FYI Kenneth, I have access to a binary of this so could collect some data on
where time is getting spent, I just need to download the thing..

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 4/4] drm/rockchip: Implement CRC debugfs API

2017-03-05 Thread Mark yao

On 2017年03月03日 21:39, Tomeu Vizoso wrote:

Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.

This is only done if this CRTC is currently using the eDP connector.

v3: Remove superfluous check on rockchip_crtc_state->output_type

v6: Remove superfluous variable

Signed-off-by: Tomeu Vizoso 
---


looks good for me

Acked-by: Mark Yao 


  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 41 +
  1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 94d7b7327ff7..17ab16c4b922 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -,6 +1112,45 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
  }
  
+static struct drm_connector *vop_get_edp_connector(struct vop *vop)

+{
+   struct drm_crtc *crtc = &vop->crtc;
+   struct drm_connector *connector;
+
+   mutex_lock(&crtc->dev->mode_config.mutex);
+   drm_for_each_connector(connector, crtc->dev)
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   mutex_unlock(&crtc->dev->mode_config.mutex);
+   return connector;
+   }
+   mutex_unlock(&crtc->dev->mode_config.mutex);
+
+   return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+  const char *source_name, size_t *values_cnt)
+{
+   struct vop *vop = to_vop(crtc);
+   struct drm_connector *connector;
+   int ret;
+
+   connector = vop_get_edp_connector(vop);
+   if (!connector)
+   return -EINVAL;
+
+   *values_cnt = 3;
+
+   if (source_name && strcmp(source_name, "auto") == 0)
+   ret = analogix_dp_start_crc(connector);
+   else if (!source_name)
+   ret = analogix_dp_stop_crc(connector);
+   else
+   ret = -EINVAL;
+
+   return ret;
+}
+
  static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1120,6 +1160,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.atomic_destroy_state = vop_crtc_destroy_state,
.enable_vblank = vop_crtc_enable_vblank,
.disable_vblank = vop_crtc_disable_vblank,
+   .set_crc_source = vop_crtc_set_crc_source,
  };
  
  static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)



--
Mark Yao


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


Re: [PATCH v6 3/6] drm/edid: detect SCDC support in HF-VSDB

2017-03-05 Thread Jose Abreu
Hi Shashank,


On 03-03-2017 06:29, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
>   This structure will be used to save and indicate if sink
>   supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_hdmi_info, to
>   reflect scdc support and capabilities in connected HDMI 2.0 sink.
> - Checks the HF-VSDB block for presence of SCDC, and marks it
>   in scdc structure
> - If SCDC is present, checks if sink is capable of generating
>   SCDC read request, and marks it in scdc structure.
>
> V2: Addressed review comments
>  Thierry:
>  - Fix typos in commit message and make abbreviation consistent
>across the commit message.
>  - Change structure object name from hdmi_info -> hdmi
>  - Fix typos and abbreviations in description of structure drm_hdmi_info
>end the description with a full stop.
>  - Create a structure drm_scdc, and keep all information related to SCDC
>register set (supported, read request supported) etc in it.
>
> Ville:
>  - Change rr -> read_request
>  - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
>of HF-VSDB parsing can be kept in same function, in incremental
>patches.
>
> V3: Rebase.
> V4: Rebase.
> V5: Rebase.
> V6: Rebase.
>
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Thierry Reding 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/drm_edid.c  | 14 ++
>  include/drm/drm_connector.h | 33 +
>  2 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3e0aafa..d64b7bd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3817,6 +3817,18 @@ enum hdmi_quantization_range
>  }
>  EXPORT_SYMBOL(drm_default_rgb_quant_range);
>  
> +static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
> +  const u8 *hf_vsdb)
> +{
> + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> +
> + if (hf_vsdb[6] & 0x80) {
> + hdmi->scdc.supported = true;
> + if (hf_vsdb[6] & 0x40)
> + hdmi->scdc.read_request = true;
> + }
> +}
> +
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
>  const u8 *hdmi)
>  {
> @@ -3931,6 +3943,8 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>  
>   if (cea_db_is_hdmi_vsdb(db))
>   drm_parse_hdmi_vsdb_video(connector, db);
> + if (cea_db_is_hdmi_forum_vsdb(db))
> + drm_parse_hdmi_forum_vsdb(connector, db);
>   }
>  }
>  
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index fabb35a..bf9d6f5 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -87,6 +87,34 @@ enum subpixel_order {
>   SubPixelVerticalRGB,
>   SubPixelVerticalBGR,
>   SubPixelNone,
> +
> +};
> +
> +/*
> + * struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
> + *
> + * Provides SCDC register support and capabilities related information on a
> + * HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
> + */
> +struct drm_scdc {
> + /**
> +  * @supported: status control & data channel present.
> +  */
> + bool supported;
> + /**
> +  * @read_request: sink is capable of generating scdc read request.
> +  */
> + bool read_request;
> +};
> +
> +/**
> + * struct drm_hdmi_info - runtime information about the connected HDMI sink
> + *
> + * Describes if a given display supports advanced HDMI 2.0 features.
> + * This information is available in CEA-861-F extension blocks (like 
> HF-VSDB).
> + */
> +struct drm_hdmi_info {
> + struct drm_scdc scdc;
>  };
>  
>  /**
> @@ -204,6 +232,11 @@ struct drm_display_info {
>* @cea_rev: CEA revision of the HDMI sink.
>*/
>   u8 cea_rev;
> +
> + /**
> +  * @hdmi: advance features of a HDMI sink.
> +  */
> + struct drm_hdmi_info hdmi;
>  };
>  
>  int drm_display_info_set_bus_formats(struct drm_display_info *info,

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


[PATCHv2 02/10] drm: omapdrm: panel-dsi-cm: add regulator support

2017-03-05 Thread Sebastian Reichel
The N950's display requires two regulators.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 55 +++--
 1 file changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index ad1058fafe92..8d13123708ae 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -60,6 +61,9 @@ struct panel_drv_data {
int reset_gpio;
int ext_te_gpio;
 
+   struct regulator *vpnl;
+   struct regulator *vddi;
+
bool use_dsi_backlight;
 
struct omap_dsi_pin_config pin_config;
@@ -590,25 +594,43 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
.lp_clk_max = 1000,
};
 
+   if (ddata->vpnl) {
+   r = regulator_enable(ddata->vpnl);
+   if (r) {
+   dev_err(&ddata->pdev->dev,
+   "failed to enable VPNL: %d\n", r);
+   goto err0;
+   }
+   }
+
+   if (ddata->vddi) {
+   r = regulator_enable(ddata->vddi);
+   if (r) {
+   dev_err(&ddata->pdev->dev,
+   "failed to enable VDDI: %d\n", r);
+   goto err1;
+   }
+   }
+
if (ddata->pin_config.num_pins > 0) {
r = in->ops.dsi->configure_pins(in, &ddata->pin_config);
if (r) {
dev_err(&ddata->pdev->dev,
"failed to configure DSI pins\n");
-   goto err0;
+   goto err2;
}
}
 
r = in->ops.dsi->set_config(in, &dsi_config);
if (r) {
dev_err(&ddata->pdev->dev, "failed to configure DSI\n");
-   goto err0;
+   goto err2;
}
 
r = in->ops.dsi->enable(in);
if (r) {
dev_err(&ddata->pdev->dev, "failed to enable DSI\n");
-   goto err0;
+   goto err2;
}
 
dsicm_hw_reset(ddata);
@@ -666,6 +688,12 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
dsicm_hw_reset(ddata);
 
in->ops.dsi->disable(in, true, false);
+err2:
+   if (ddata->vddi)
+   regulator_disable(ddata->vddi);
+err1:
+   if (ddata->vpnl)
+   regulator_disable(ddata->vpnl);
 err0:
return r;
 }
@@ -689,6 +717,11 @@ static void dsicm_power_off(struct panel_drv_data *ddata)
 
in->ops.dsi->disable(in, true, false);
 
+   if (ddata->vddi)
+   regulator_disable(ddata->vddi);
+   if (ddata->vpnl)
+   regulator_disable(ddata->vpnl);
+
ddata->enabled = 0;
 }
 
@@ -1192,6 +1225,22 @@ static int dsicm_probe_of(struct platform_device *pdev)
return PTR_ERR(in);
}
 
+   ddata->vpnl = devm_regulator_get_optional(&pdev->dev, "vpnl");
+   if (IS_ERR(ddata->vpnl)) {
+   err = PTR_ERR(ddata->vpnl);
+   if (err == -EPROBE_DEFER)
+   return err;
+   ddata->vpnl = NULL;
+   }
+
+   ddata->vddi = devm_regulator_get_optional(&pdev->dev, "vddi");
+   if (IS_ERR(ddata->vddi)) {
+   err = PTR_ERR(ddata->vddi);
+   if (err == -EPROBE_DEFER)
+   return err;
+   ddata->vddi = NULL;
+   }
+
ddata->in = in;
 
/* TODO: ulps, backlight */
-- 
2.11.0

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


Re: [PATCH v2 2/2] drm: bridge: Move HPD handling to PHY operations

2017-03-05 Thread Jose Abreu
Hi Neil,


On 03-03-2017 09:07, Neil Armstrong wrote:
>
> The problem is that the HPD/RxSense is tied to this phy_mask and glued into 
> the
> dw-hdmi driver.
>
> The *real* solution would be to completely separate the HPD/RxSense irq 
> handling to
> a separate driver as a shared irq...
>
> If Jose is willing to give me some documentation and Freescale some boards, 
> I'll be
> happy to do it !
>
>

Hmm, why don't get rid of phy_mask totally and just return the
new mask in update_hpd() function? Or add a get_hpd_status()
callback. (I also think there are too many callbacks. For example
we could have: setup, set_status, clear and then just use
parameters when needed:
void setup(bool force, bool disabled, bool rxsense)
void set_status(bool enable, bool enable_ints)
void clear()

What do you think? I only checked quickly the code, don't know if
this is enough.

Best regards,
Jose Miguel Abreu

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


[Bug 100069] Dirt: Showdown bad performance with enabled advanced lightning

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100069

Kenneth Graunke  changed:

   What|Removed |Added

 QA Contact|intel-3d-bugs@lists.freedes |dri-devel@lists.freedesktop
   |ktop.org|.org
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|glsl-compiler   |Drivers/Gallium/radeonsi

--- Comment #1 from Kenneth Graunke  ---
Assigning to the radeonsi driver until we know it's a general problem...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

2017-03-05 Thread Jose Abreu
Hi Alexey,


On 03-03-2017 13:27, Alexey Brodkin wrote:
>
> So if I understood you correct here what I really need is just to get rid of 
> existing check,
> right? I.e. the following is to be in v2 respin:
> --->8---
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index ad9a95916f1f..86f1555914e8 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -129,20 +129,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
>   ~ARCPGU_CTRL_ENABLE_MASK);
>  }
>  
> -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> -struct drm_crtc_state *state)
> -{
> -   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> -   struct drm_display_mode *mode = &state->adjusted_mode;
> -   long rate, clk_rate = mode->clock * 1000;
> -
> -   rate = clk_round_rate(arcpgu->clk, clk_rate);
> -   if (rate != clk_rate)
> -   return -EINVAL;
> -
> -   return 0;
> -}
> -
>  static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
>   struct drm_crtc_state *state)
>  {
> @@ -165,7 +151,6 @@ static const struct drm_crtc_helper_funcs 
> arc_pgu_crtc_helper_funcs = {
> .disable= arc_pgu_crtc_disable,
> .prepare= arc_pgu_crtc_disable,
> .commit = arc_pgu_crtc_enable,
> -   .atomic_check   = arc_pgu_crtc_atomic_check,
> .atomic_begin   = arc_pgu_crtc_atomic_begin,
>  };
> --->8---

I don't think you can remove the check entirely as this will make
any mode be accepted, right?

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/arcpgu: Get rid of "encoder-slave" property

2017-03-05 Thread Alexey Brodkin
We used to use "encoder-slave" property in PGU's
Device Tree node to refer to the encoder, but since there's
a way to find it with some code smarts we get rid of
obviously extra complication in PGU node.

Again inspired by ARM's HDLCD code.

Signed-off-by: Alexey Brodkin 
Cc: Liviu Dudau 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Rob Herring 
---
 arch/arc/boot/dts/axs10x_mb.dtsi |  1 -
 drivers/gpu/drm/arc/arcpgu_drv.c | 23 +--
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 41cfb29b62c1..2fe030186b9d 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -287,7 +287,6 @@
pgu@17000 {
compatible = "snps,arcpgu";
reg = <0x17000 0x400>;
-   encoder-slave = <&adv7511>;
clocks = <&pguclk>;
clock-names = "pxlclk";
memory-region = <&frame_buffer>;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 5c82f52fba80..b1b2286bda95 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "arcpgu.h"
@@ -83,7 +84,7 @@ static int arcpgu_load(struct drm_device *drm)
 {
struct platform_device *pdev = to_platform_device(drm->dev);
struct arcpgu_drm_private *arcpgu;
-   struct device_node *encoder_node;
+   struct device_node *encoder, *port;
struct resource *res;
int ret;
 
@@ -118,14 +119,24 @@ static int arcpgu_load(struct drm_device *drm)
if (arc_pgu_setup_crtc(drm) < 0)
return -ENODEV;
 
-   /* find the encoder node and initialize it */
-   encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
-   if (encoder_node) {
-   ret = arcpgu_drm_hdmi_init(drm, encoder_node);
-   of_node_put(encoder_node);
+   /* There is only one output port inside each device, find it */
+   port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
+
+   if (port) {
+   if (of_device_is_available(port))
+   encoder = of_graph_get_remote_port_parent(port);
+   of_node_put(port);
+   }
+
+   if (encoder && of_device_is_available(encoder)) {
+   dev_info(drm->dev, "Found encoder node %s, proceeding with 
it\n",
+encoder->name);
+   ret = arcpgu_drm_hdmi_init(drm, encoder);
+   of_node_put(encoder);
if (ret < 0)
return ret;
} else {
+   dev_info(drm->dev, "No encoder node, assume simulation\n");
ret = arcpgu_drm_sim_init(drm, NULL);
if (ret < 0)
return ret;
-- 
2.7.4

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


[PATCH] drm: rcar-du: Make sure planes are created by VSP

2017-03-05 Thread Jacopo Mondi
On Gen3 platforms compositing planes are allocated  by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp initialization stub routine is
called. Return an error from that stub to fail explicitly, otherwise
accessing planes leads to invalid memory errors.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 510dcc9..f1d0f18 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -68,7 +68,7 @@ void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
 void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc);
 #else
-static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return 0; };
+static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp) { return -ENXIO; };
 static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
 static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
 static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
-- 
2.7.4

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


Re: [PATCH] drm: rcar-du: Make sure DRM planes are created by VSP1

2017-03-05 Thread jacopo mondi

HI Laurent,

On 03/03/2017 12:26, Laurent Pinchart wrote:

Hi Jacopo,

Thank you for the patch.

On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:

On Gen3 platforms compositing planes are allocated  by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp1 initialization stub routine is
called, leading to invalid memory accesses later on when un-initialized
planes are accessed.

Fail explicitly earlier if planes are not properly created.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index b5d3f16..7f56c09 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -616,6 +616,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
ret = rcar_du_vsp_init(vsp);
if (ret < 0)
return ret;
+
+   if (!vsp->planes)
+   return -EINVAL;


Given that this code is only called when the DU hardware requires the VSP to
operate, how about modifying the rcar_du_vsp_init() stub function to return -
ENXIO instead of 0 ? That way you won't need to add an additional check here.



Ok, I'll make sure it is only called there also.


Ideally we should require VSP through Kconfig as well. If you feel like
submitting a patch (and testing it with various combinations of module and
built-in) it would be appreciated.


That would be ideal.
Am I wrong or the condition that selects DRM_RCAR_VSP is (DRM_RCAR_DU && 
Gen3-platform)? Implying that on Gen2 DU can live without VSP enabled?


Thanks
   j





}
}




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


Re: [PATCH v3 1/4] gpu: ipu-v3: remove IRQ dance on DC channel disable

2017-03-05 Thread Dan MacDonald
I've finished doing the bulk of my house moving and have time to test
these patches now. I'm presuming they've not made it into 4.10(.1)
have they?

On Tue, Feb 28, 2017 at 2:18 PM, Philipp Zabel  wrote:
> From: Lucas Stach 
>
> This has never worked properly, as the IRQ got retriggered immediately
> on unmask. Remove the IRQ wait dance, as it is apparently safe to disable
> the DC channel at any point in time.
>
> Signed-off-by: Lucas Stach 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/ipu-v3/ipu-dc.c | 61 
> +++--
>  1 file changed, 4 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
> index 659475c1e44ab..7a4b8362dda8f 100644
> --- a/drivers/gpu/ipu-v3/ipu-dc.c
> +++ b/drivers/gpu/ipu-v3/ipu-dc.c
> @@ -112,8 +112,6 @@ struct ipu_dc_priv {
> struct ipu_dc   channels[IPU_DC_NUM_CHANNELS];
> struct mutexmutex;
> struct completion   comp;
> -   int dc_irq;
> -   int dp_irq;
> int use_count;
>  };
>
> @@ -262,47 +260,13 @@ void ipu_dc_enable_channel(struct ipu_dc *dc)
>  }
>  EXPORT_SYMBOL_GPL(ipu_dc_enable_channel);
>
> -static irqreturn_t dc_irq_handler(int irq, void *dev_id)
> -{
> -   struct ipu_dc *dc = dev_id;
> -   u32 reg;
> -
> -   reg = readl(dc->base + DC_WR_CH_CONF);
> -   reg &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
> -   writel(reg, dc->base + DC_WR_CH_CONF);
> -
> -   /* The Freescale BSP kernel clears DIx_COUNTER_RELEASE here */
> -
> -   complete(&dc->priv->comp);
> -   return IRQ_HANDLED;
> -}
> -
>  void ipu_dc_disable_channel(struct ipu_dc *dc)
>  {
> -   struct ipu_dc_priv *priv = dc->priv;
> -   int irq;
> -   unsigned long ret;
> u32 val;
>
> -   /* TODO: Handle MEM_FG_SYNC differently from MEM_BG_SYNC */
> -   if (dc->chno == 1)
> -   irq = priv->dc_irq;
> -   else if (dc->chno == 5)
> -   irq = priv->dp_irq;
> -   else
> -   return;
> -
> -   init_completion(&priv->comp);
> -   enable_irq(irq);
> -   ret = wait_for_completion_timeout(&priv->comp, msecs_to_jiffies(50));
> -   disable_irq(irq);
> -   if (ret == 0) {
> -   dev_warn(priv->dev, "DC stop timeout after 50 ms\n");
> -
> -   val = readl(dc->base + DC_WR_CH_CONF);
> -   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
> -   writel(val, dc->base + DC_WR_CH_CONF);
> -   }
> +   val = readl(dc->base + DC_WR_CH_CONF);
> +   val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
> +   writel(val, dc->base + DC_WR_CH_CONF);
>  }
>  EXPORT_SYMBOL_GPL(ipu_dc_disable_channel);
>
> @@ -389,7 +353,7 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
> struct ipu_dc_priv *priv;
> static int channel_offsets[] = { 0, 0x1c, 0x38, 0x54, 0x58, 0x5c,
> 0x78, 0, 0x94, 0xb4};
> -   int i, ret;
> +   int i;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> @@ -410,23 +374,6 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
> priv->channels[i].base = priv->dc_reg + channel_offsets[i];
> }
>
> -   priv->dc_irq = ipu_map_irq(ipu, IPU_IRQ_DC_FC_1);
> -   if (!priv->dc_irq)
> -   return -EINVAL;
> -   ret = devm_request_irq(dev, priv->dc_irq, dc_irq_handler, 0, NULL,
> -  &priv->channels[1]);
> -   if (ret < 0)
> -   return ret;
> -   disable_irq(priv->dc_irq);
> -   priv->dp_irq = ipu_map_irq(ipu, IPU_IRQ_DP_SF_END);
> -   if (!priv->dp_irq)
> -   return -EINVAL;
> -   ret = devm_request_irq(dev, priv->dp_irq, dc_irq_handler, 0, NULL,
> -  &priv->channels[5]);
> -   if (ret < 0)
> -   return ret;
> -   disable_irq(priv->dp_irq);
> -
> writel(DC_WR_CH_CONF_WORD_SIZE_24 | DC_WR_CH_CONF_DISP_ID_PARALLEL(1) 
> |
> DC_WR_CH_CONF_PROG_DI_ID,
> priv->channels[1].base + DC_WR_CH_CONF);
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/3] v4l: vsp1: Extend VSP1 module API to allow DRM callbacks

2017-03-05 Thread Kieran Bingham
Hi Laurent,

On 05/03/17 21:58, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Sunday 05 Mar 2017 16:00:03 Kieran Bingham wrote:
>> To be able to perform page flips in DRM without flicker we need to be
>> able to notify the rcar-du module when the VSP has completed its
>> processing.
>>
>> We must not have bidirectional dependencies on the two components to
>> maintain support for loadable modules, thus we extend the API to allow
>> a callback to be registered within the VSP DRM interface.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_drm.c | 17 +
>>  drivers/media/platform/vsp1/vsp1_drm.h | 11 +++
>>  include/media/vsp1.h   | 13 +
>>  3 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
>> b/drivers/media/platform/vsp1/vsp1_drm.c index 4ee437c7ff0c..d93bf7d3a39e
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
>> @@ -37,6 +37,14 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
>>  vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
>>  }
>>
>> +static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
>> +{
>> +struct vsp1_drm *drm = to_vsp1_drm(pipe);
>> +
>> +if (drm->du_complete)
>> +drm->du_complete(drm->du_private);
>> +}
>> +
>>  /* 
>>   * DU Driver API
>>   */
>> @@ -96,6 +104,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct
>> vsp1_du_lif_config *cfg) }
>>
>>  pipe->num_inputs = 0;
>> +vsp1->drm->du_complete = NULL;
>>
>>  vsp1_dlm_reset(pipe->output->dlm);
>>  vsp1_device_put(vsp1);
>> @@ -200,6 +209,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct
>> vsp1_du_lif_config *cfg) if (ret < 0)
>>  return ret;
>>
>> +/*
>> + * Register a callback to allow us to notify the DRM framework of 
> frame
> 
> s/framework/driver/
> 
>> + * completion events.
>> + */
>> +vsp1->drm->du_complete = cfg->callback;
>> +vsp1->drm->du_private = cfg->callback_data;
>> +
>>  ret = media_pipeline_start(&pipe->output->entity.subdev.entity,
>>&pipe->pipe);
>>  if (ret < 0) {
>> @@ -607,6 +623,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
>>  pipe->lif = &vsp1->lif->entity;
>>  pipe->output = vsp1->wpf[0];
>>  pipe->output->pipe = pipe;
>> +pipe->frame_end = vsp1_du_pipeline_frame_end;
>>
>>  return 0;
>>  }
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
>> b/drivers/media/platform/vsp1/vsp1_drm.h index c8d2f88fc483..3de2095cb0ce
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.h
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.h
>> @@ -23,6 +23,8 @@
>>   * @num_inputs: number of active pipeline inputs at the beginning of an
>> update
>>   * @inputs: source crop rectangle, destination compose rectangle and
>> z-order
>>   *  position for every input
>> + * @du_complete: frame completion callback for the DU driver (optional)
>> + * @du_private: data to be passed to the du_complete callback
>>   */
>>  struct vsp1_drm {
>>  struct vsp1_pipeline pipe;
>> @@ -33,8 +35,17 @@ struct vsp1_drm {
>>  struct v4l2_rect compose;
>>  unsigned int zpos;
>>  } inputs[VSP1_MAX_RPF];
>> +
>> +/* Frame syncronisation */
> 
> s/syncronisation/synchronisation/
> 
>> +void (*du_complete)(void *);
>> +void *du_private;
>>  };
>>
>> +static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
>> +{
>> +return container_of(pipe, struct vsp1_drm, pipe);
>> +}
>> +
>>  int vsp1_drm_init(struct vsp1_device *vsp1);
>>  void vsp1_drm_cleanup(struct vsp1_device *vsp1);
>>  int vsp1_drm_create_links(struct vsp1_device *vsp1);
>> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
>> index bfc701f04f3f..d59d0adf560d 100644
>> --- a/include/media/vsp1.h
>> +++ b/include/media/vsp1.h
>> @@ -20,9 +20,22 @@ struct device;
>>
>>  int vsp1_du_init(struct device *dev);
>>
>> +/**
>> + * struct vsp1_du_lif_config - VSP LIF configuration
>> + * @width: output frame width
>> + * @height: output frame height
>> + * @callback: frame completion callback function (optional)
>> + * @callback_data: data to be passed to the frame completion callback
>> + *
>> + * When the optional callback is provided to the VSP1, the VSP1 must
>> guarantee
>> + * that one completion callback is performed after every
>> vsp1_du_atomic_flush()
> 
> This paragraph should be part of the @callback documentation. I would phrase 
> it as
> 
>  * @callback: frame completion callback function (optional). When a callback
>  *  is provided, the VSP driver guarantees that it will be called
>  *  once and only once for each vsp1_du_atomic_flush() call.
> 
> With this fixed,
> 
> Reviewed-by: Laurent Pinchart 
> 

Re: [PATCH v3 3/3] drm: rcar-du: Register a completion callback with VSP1

2017-03-05 Thread Sergei Shtylyov

Hello!

On 03/05/2017 07:00 PM, Kieran Bingham wrote:


Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 

[...]

 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..cbb6f54c99ef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,13 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"

+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;


   No need for explicit cast.


+
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = &crtc->crtc.state->adjusted_mode;

[...]

MBR, Sergei

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


Re: [PATCH v4 1/9] drm: bridge: dw-hdmi: Remove unused functions

2017-03-05 Thread Nickey.Yang

Hi Laurent,


在 2017年03月02日 06:39, Laurent Pinchart 写道:

Most of the hdmi_phy_test_*() functions are unused. Remove them.

Signed-off-by: Laurent Pinchart 


Tested-by: Nickey Yang 

Best regards,
Nickey Yang

---
  drivers/gpu/drm/bridge/dw-hdmi.c | 26 --
  1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 9a9ec27d9e28..ce7496399ccf 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -837,32 +837,6 @@ static inline void hdmi_phy_test_clear(struct dw_hdmi 
*hdmi,
  HDMI_PHY_TST0_TSTCLR_MASK, HDMI_PHY_TST0);
  }
  
-static inline void hdmi_phy_test_enable(struct dw_hdmi *hdmi,

-   unsigned char bit)
-{
-   hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTEN_OFFSET,
- HDMI_PHY_TST0_TSTEN_MASK, HDMI_PHY_TST0);
-}
-
-static inline void hdmi_phy_test_clock(struct dw_hdmi *hdmi,
-  unsigned char bit)
-{
-   hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTCLK_OFFSET,
- HDMI_PHY_TST0_TSTCLK_MASK, HDMI_PHY_TST0);
-}
-
-static inline void hdmi_phy_test_din(struct dw_hdmi *hdmi,
-unsigned char bit)
-{
-   hdmi_writeb(hdmi, bit, HDMI_PHY_TST1);
-}
-
-static inline void hdmi_phy_test_dout(struct dw_hdmi *hdmi,
- unsigned char bit)
-{
-   hdmi_writeb(hdmi, bit, HDMI_PHY_TST2);
-}
-
  static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
  {
u32 val;


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


[PATCHv2 07/10] drm: omapdrm: plane: update fifo size on atomic update

2017-03-05 Thread Sebastian Reichel
This is a workaround for a hardware bug occuring on OMAP3
with manually updated panels. Details about the HW bug are
unknown to me, but without this fix the panel refresh does
not work at all on Nokia N950.

Signed-off-By: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   |  2 ++
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  4 
 drivers/gpu/drm/omapdrm/omap_drv.h|  1 +
 drivers/gpu/drm/omapdrm/omap_plane.c  | 23 +++
 4 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index d956e6266368..97240e59b248 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -1321,6 +1321,7 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, 
u32 low, u32 high)
plane != OMAP_DSS_WB)
dispc_write_reg(DISPC_OVL_PRELOAD(plane), min(high, 0xfffu));
 }
+EXPORT_SYMBOL(dispc_ovl_set_fifo_threshold);
 
 void dispc_enable_fifomerge(bool enable)
 {
@@ -1379,6 +1380,7 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane 
plane,
*fifo_high = total_fifo_size - buf_unit;
}
 }
+EXPORT_SYMBOL(dispc_ovl_compute_fifo_thresholds);
 
 static void dispc_ovl_set_mflag(enum omap_plane plane, bool enable)
 {
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 5666ecbe4b80..65c3530a3b53 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -878,6 +878,10 @@ void dispc_ovl_set_channel_out(enum omap_plane plane,
enum omap_channel channel);
 int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool replication, const struct videomode *vm, bool mem_to_mem);
+void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
+   u32 *fifo_low, u32 *fifo_high, bool use_fifomerge,
+   bool manual_update);
+void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high);
 
 enum omap_dss_output_id dispc_mgr_get_supported_outputs(enum omap_channel 
channel);
 
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index ee8901dc0381..71b5c5e25ee4 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -146,6 +146,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
u32 possible_crtcs);
 void omap_plane_install_properties(struct drm_plane *plane,
struct drm_mode_object *obj);
+void omap_plane_update_fifo(struct drm_plane *plane);
 
 struct drm_encoder *omap_encoder_init(struct drm_device *dev,
struct omap_dss_device *dssdev);
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 386d90af70f7..8d290cfe8925 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -73,6 +73,28 @@ static void omap_plane_cleanup_fb(struct drm_plane *plane,
omap_framebuffer_unpin(old_state->fb);
 }
 
+void omap_plane_update_fifo(struct drm_plane *plane)
+{
+   struct omap_plane *omap_plane = to_omap_plane(plane);
+   struct drm_plane_state *state = plane->state;
+   struct drm_device *dev = plane->dev;
+   bool use_fifo_merge = false;
+   u32 fifo_low, fifo_high;
+   bool use_manual_update;
+
+   if (!dispc_ovl_enabled(omap_plane->id))
+   return;
+
+   use_manual_update = omap_crtc_is_manual_updated(state->crtc);
+
+   dispc_ovl_compute_fifo_thresholds(omap_plane->id, &fifo_low, &fifo_high,
+   use_fifo_merge, use_manual_update);
+
+   dev_dbg(dev->dev, "update fifo: %d %d", fifo_low, fifo_high);
+
+   dispc_ovl_set_fifo_threshold(omap_plane->id, fifo_low, fifo_high);
+}
+
 static void omap_plane_atomic_update(struct drm_plane *plane,
 struct drm_plane_state *old_state)
 {
@@ -137,6 +159,7 @@ static void omap_plane_atomic_update(struct drm_plane 
*plane,
}
 
dispc_ovl_enable(omap_plane->id, true);
+   omap_plane_update_fifo(plane);
 }
 
 static void omap_plane_atomic_disable(struct drm_plane *plane,
-- 
2.11.0

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


Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

2017-03-05 Thread Dan MacDonald
Hi Phillip

$ git fetch https://git.pengutronix.de/git/pza/linux.git
tags/v4.10-ipu-dp-plane-fix
fatal: Not a git repository (or any of the parent directories): .git


I get the same error for:

git fetch https://git.pengutronix.de/git/pza/linux.git
tags/v4.10-ipu-dp-plane-fix


Thanks

On Mon, Feb 27, 2017 at 1:13 PM, Philipp Zabel  wrote:
> Hi Dan,
>
> On Mon, 2017-02-27 at 11:43 +, Dan MacDonald wrote:
>> Hi Phillipp
>>
>> It sounds like you need me to test a new kernel build with these patches now?
>
> if you could find the time, that would be helpful.
>
>> I'm new round here so could you please give me the git commands to
>> check out your patches / tree as well as any kernel config options
>> I'll need to ensure are enabled for full imxdrm / SABRE Lite support.
>
> If you are willing to test on top of drm-next, try
>
> git fetch https://git.pengutronix.de/git/pza/linux.git imx-drm/next
> git checkout -b "test-branch" FETCH_HEAD
> make imx_v6_v7_defconfig
>
> I think the defconfig should include everything necessary for SABRE Lite
> in your git kernel repository. If you prefer testing on a release
> kernel, the patches are trivially rebased onto v4.10:
>
> git fetch https://git.pengutronix.de/git/pza/linux.git 
> tags/v4.10-ipu-dp-plane-fix
> git checkout -b "test-branch" FETCH_HEAD
> make imx_v6_v7_defconfig
>
>> I started moving house yesterday and that continues today and tomorrow
>> so the soonest I am going to be able to build and test a new kernel
>> will be Wednesday but Thursday or this upcoming weekend is more
>> likely.
>
> Ok, there's no hurry. Let me know if you have any problems.
>
> regards
> Philipp
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 3/3] drm: rcar-du: Register a completion callback with VSP1

2017-03-05 Thread Kieran Bingham
Hi Laurent,

On 03/03/17 02:17, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Wednesday 01 Mar 2017 13:12:56 Kieran Bingham wrote:
>> Updating the state in a running VSP1 requires two interrupts from the
>> VSP. Initially, the updated state will be committed - but only after the
>> VSP1 has completed processing it's current frame will the new state be
>> taken into account. As such, the committed state will only be 'completed'
>> after an extra frame completion interrupt.
>>
>> Track this delay, by passing the frame flip event through the VSP
>> module; It will be returned only when the frame has completed and can be
>> returned to the caller.
> 
> I'll check the interrupt sequence logic tomorrow, it's a bit too late now. 
> Please see below for additional comments.

No worries

> 
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 34 ++-
>>  3 files changed, 41 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 7391dd95c733..0a824633a012
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
>> @@ -328,7 +328,7 @@ static bool rcar_du_crtc_page_flip_pending(struct
>> rcar_du_crtc *rcrtc) bool pending;
>>
>>  spin_lock_irqsave(&dev->event_lock, flags);
>> -pending = rcrtc->event != NULL;
>> +pending = (rcrtc->event != NULL) || (rcrtc->pending != NULL);
>>  spin_unlock_irqrestore(&dev->event_lock, flags);
>>
>>  return pending;
>> @@ -578,6 +578,12 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
>> rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
>>
>>  if (status & DSSR_FRM) {
>> +
>> +if (rcrtc->pending) {
>> +trace_printk("VBlank loss due to VSP Overrun\n");
>> +return IRQ_HANDLED;
>> +}
>> +
>>  drm_crtc_handle_vblank(&rcrtc->crtc);
>>  rcar_du_crtc_finish_page_flip(rcrtc);
>>  ret = IRQ_HANDLED;
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index a7194812997e..8374a858446a
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> @@ -46,6 +46,7 @@ struct rcar_du_crtc {
>>  bool started;
>>
>>  struct drm_pending_vblank_event *event;
>> +struct drm_pending_vblank_event *pending;
>>  wait_queue_head_t flip_wait;
>>
>>  unsigned int outputs;
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 71e70e1e0881..408375aff1a0
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -28,6 +28,26 @@
>>  #include "rcar_du_kms.h"
>>  #include "rcar_du_vsp.h"
>>
>> +static void rcar_du_vsp_complete(void *private, void *data)
>> +{
>> +struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
>> +struct drm_device *dev = crtc->crtc.dev;
>> +struct drm_pending_vblank_event *event;
>> +bool match;
>> +unsigned long flags;
>> +
>> +spin_lock_irqsave(&dev->event_lock, flags);
>> +event = crtc->event;
>> +crtc->event = data;
>> +match = (crtc->event == crtc->pending);
>> +crtc->pending = NULL;
>> +spin_unlock_irqrestore(&dev->event_lock, flags);
>> +
>> +/* Safety checks */
>> +WARN(event, "Event lost by VSP completion callback\n");
>> +WARN(!match, "Stored pending event, does not match completion\n");
> 
> I understand you want to be safe, and I assume these have never been 
> triggered 
> in your tests. I'd rather replace them by a mechanism that doesn't require 
> passing the event to the VSP driver, and that wouldn't require adding a 
> pending field to the rcar_du_crtc structure. 

Ok - understandable, I started this way - but hit problems, which I think were
unrelated. Anyway, I switched to 'moving' the event so that I could be sure
rcar_du_crtc_finish_page_flip() couldn't have an event to send.

I can switch back to keeping it's 'ownership' in rcar-du.

> Wouldn't adding a WARN_ON(rcrtc-
>> event) in rcar_du_crtc_atomic_begin() in the if (crtc->state->event) block 
>> do 
> the job ?

Yes, that would :D - I put those in just to be sure things were going as
expected, and there weren't any code paths I hadn't considered. But I think they
are 'unreachable' warnings anyway (at least at the moment).



> Would this get in the way of your trace_printk() debugging in 
> rcar_du_crtc_irq() ? Could you implement the debugging in a separate patch 
> without requiring to pass the event to the VSP driver ?

Moving the event wasn't necessarily about trace_printk debugging, but perhaps it
was part of me debugging why I hadn't got things working correctly.

Moving the event out meant I w

[PATCHv2 00/10] Nokia N950 basic display support

2017-03-05 Thread Sebastian Reichel
Hi,

Some of you may remember, that I sent a series for the N950 display
some time ago. N950 has command mode DSI panel, so the main part of
the patchset takes care of adding manual display update support in
omapdrm.

The N950 also requires display rotation (the panel is mounted vertically
and bottom-up) and offset. The required bits will be sent separately.

The patchset is based on 2d62e0768d3c, which is the current commit
torvald's master branch points to. I tested the patches on N950
with kernel console (fbcon), Tomi's kmstest and Xorg from Debian sid.

Rough changelog, most of that work was done by Tony (thanks!)

 * lots of patches dropped for now
 * rebased to current omapdrm interface
 * added OMAP4 support
 * misc. cleanup

-- Sebastian

Sebastian Reichel (7):
  drm: omapdrm: panel-dsi-cm: add regulator support
  Revert "drm: omapdrm: Remove manual update display support"
  drm: omapdrm: crtc: save framedone callback from dss
  drm: omapdrm: crtc: detect manually updated displays
  drm: omapdrm: crtc: add support for manual updated displays
  drm: omapdrm: plane: update fifo size on atomic update
  ARM: dts: n950: add display support

Tony Lindgren (3):
  drm: omapdrm: panel-dsi-cm: Fix probe for device tree
  drm: omapdrm: crtc: handle framedone directly
  drm: omapdrm: crtc: get manual mode displays working

 arch/arm/boot/dts/omap3-n950.dts|  89 +
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 120 ++---
 drivers/gpu/drm/omapdrm/dss/dispc.c |   2 +
 drivers/gpu/drm/omapdrm/dss/omapdss.h   |   5 +
 drivers/gpu/drm/omapdrm/dss/output.c|   6 +
 drivers/gpu/drm/omapdrm/omap_connector.c|   7 +
 drivers/gpu/drm/omapdrm/omap_crtc.c | 165 ++--
 drivers/gpu/drm/omapdrm/omap_drv.h  |   8 ++
 drivers/gpu/drm/omapdrm/omap_fb.c   |  28 
 drivers/gpu/drm/omapdrm/omap_fbdev.c|  57 +++-
 drivers/gpu/drm/omapdrm/omap_irq.c  |   7 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|  23 
 12 files changed, 487 insertions(+), 30 deletions(-)

-- 
2.11.0

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


Re: [RFC PATCH 2/3] v4l: vsp1: extend VSP1 module API to allow DRM callback registration

2017-03-05 Thread Kieran Bingham
Hi Laurent,

On 03/03/17 02:11, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Wednesday 01 Mar 2017 13:12:55 Kieran Bingham wrote:
>> To be able to perform page flips in DRM without flicker we need to be
>> able to notify the rcar-du module when the VSP has completed its
>> processing.
>>
>> To synchronise the page flip events for userspace, we move the required
>> event through the VSP to track the data flow. When the frame is
>> completed, the event can be returned back to the originator through the
>> registered callback.
>>
>> We must not have bidirectional dependencies on the two components to
>> maintain support for loadable modules, thus we extend the API to allow
>> a callback to be registered within the VSP DRM interface.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  2 +-
>>  drivers/media/platform/vsp1/vsp1_drm.c | 42 +--
>>  drivers/media/platform/vsp1/vsp1_drm.h | 12 -
>>  include/media/vsp1.h   |  6 +++-
>>  4 files changed, 58 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index b5bfbe50bd87..71e70e1e0881
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -81,7 +81,7 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
>>
>>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
>>  {
>> -vsp1_du_atomic_flush(crtc->vsp->vsp);
>> +vsp1_du_atomic_flush(crtc->vsp->vsp, NULL);
>>  }
>>
>>  /* Keep the two tables in sync. */
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
>> b/drivers/media/platform/vsp1/vsp1_drm.c index 8e2aa3f8e52f..743cbce48d0c
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
 >> @@ -52,6 +52,40 @@ int vsp1_du_init(struct device *dev)
>>  EXPORT_SYMBOL_GPL(vsp1_du_init);
>>
>>  /**
>> + * vsp1_du_register_callback - Register VSP completion notifier callback
>> + *
>> + * Allow the DRM framework to register a callback with us to notify the end
>> of + * processing each frame. This allows synchronisation for page
>> flipping. + *
>> + * @dev: the VSP device
>> + * @callback: the callback function to notify the DU module
>> + * @private: private structure data to pass with the callback
>> + *
>> + */
>> +void vsp1_du_register_callback(struct device *dev,
>> +   void (*callback)(void *, void *),
>> +   void *private)
>> +{
>> +struct vsp1_device *vsp1 = dev_get_drvdata(dev);
>> +
>> +vsp1->drm->du_complete = callback;
>> +vsp1->drm->du_private = private;
>> +}
>> +EXPORT_SYMBOL_GPL(vsp1_du_register_callback);
> 
> As they're not supposed to change at runtime while the display is running, 
> how 
> about passing the callback and private data pointer to the 
> vsp1_du_setup_lif() 
> function ? Feel free to create a structure for all the parameters passed to 
> the function if you think we'll have too much (which would, as a side effect, 
> made updates to the API easier in the future as changes to the two subsystems 
> will be easier to decouple).

Sure, that's fine. I think a config structure makes sense here.

>> +static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
>> +{
>> +struct vsp1_drm *drm = to_vsp1_drm(pipe);
>> +
>> +if (drm->du_complete && drm->active_data)
>> +drm->du_complete(drm->du_private, drm->active_data);
>> +
>> +/* The pending frame is now active */
>> +drm->active_data = drm->pending_data;
>> +drm->pending_data = NULL;
>> +}
> 
> I would move this function to the "Interrupt Handling" section.

Ack.

>> +/**
>>   * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
>>   * @dev: the VSP device
>>   * @width: output frame width in pixels
>> @@ -99,7 +133,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
>> width, }
>>
>>  pipe->num_inputs = 0;
>> -
>> +pipe->frame_end = NULL;
> 
> You can drop this if ...
> 
>> +vsp1->drm->du_complete = NULL;
>>  vsp1_dlm_reset(pipe->output->dlm);
>>  vsp1_device_put(vsp1);
>>
>> @@ -196,6 +231,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
>> width, if (ret < 0)
>>  return ret;
>>
>> +pipe->frame_end = vsp1_du_pipeline_frame_end;
>> +

> 
> ... you move this to vsp1_drm_init().

Done.


> 
>>  ret = media_entity_pipeline_start(&pipe->output->entity.subdev.entity,
>>&pipe->pipe);
>>  if (ret < 0) {
>> @@ -420,7 +457,7 @@ static unsigned int rpf_zpos(struct vsp1_device *vsp1,
>> struct vsp1_rwpf *rpf) * vsp1_du_atomic_flush - Commit an atomic update
>>   * @dev: the VSP device
>>   */
>> -void vsp1_du_atomic_flush(struct device *dev)
>> +void vsp1_du_atomic_flush(struct device *dev, void *data)
>>  {
>>  struct vsp1_device *vsp1 =

[PATCH V3 0/4] megachips-stdpxxxx-ge-b850v3-fw

2017-03-05 Thread Peter Senna Tschudin
The video processing pipeline on the second output on the GE B850v3:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Each bridge has a dedicated flash containing firmware for supporting the
custom design. The result is that in this design neither the STDP4028
nor the STDP2690 behave as the stock bridges would. The compatible
strings include the suffix "-ge-b850v3-fw" to make it clear that the
driver is for the bridges with the firmware which is specific for the GE
B850v3.

The driver is powerless to control the video processing pipeline, as the
two bridges behaves as a single one. The driver is only needed for
telling the host about EDID / HPD, and for giving the host powers to ack
interrupts.

Changes from V2:
 - Added Acked-by: Rob Herring  on patch 1/4
 - Fixed the driver to allow it to be compiled as a module

Changes from V1:
 - Fix bindings documentation
 - Fix white space issues on the driver
 - Improved ge_b850v3_lvds_remove() to not rely on ge_b850v3_lvds_ptr->edid

Changes from V7(was GE B850v3 LVDS/DP++ Bridge):
 - New devicetree binding with one node per bridge, and two ports per bridge
 - Two i2c_devices, one per bridge
 - Removed uneeded mutexes
 - Moved documentation to bindings/display/bridge
 - Included test for EDID extension blocks
 - Renamed bridge pointer to ge_b850v3_lvds_ptr
 - Removed the call to drm_helper_hpd_irq_event()
 - Removed assignments to bridge.driver_private

Changes from V6:
 - Removed check for pixel clock as the bridge supports up to 330Mhz while the
   host is limited to 264 MHz in very specific conditions.
 - Added a second mutex to avoid concurrency issues while acking interrupts
   from threaded interrupt handlers.
 - Renamed the edid mutex to be more descriptive.
 - Added a .detach() function that disables the interrupts.
 - Adopted i2c_new_secondary_device() and updated the dts and documentation to
   match the new method.
 - Removed useless test to drm_bridge_add()
 - Did some refactoring around devm_request_threaded_irq()
 - Added a missing call to i2c_unregister_device() on the i2c_driver.remove()
   function.

Changes from V5:
 - Change to MAINTAINERS in a separate patch
 - Reworked interrupt handler initialization
 - Removed useless calls to: drm_connector_register(),
   drm_helper_hpd_irq_event(), and drm_bridge_enable()

Changes from V4:
 - Renamed the i2c_driver.name from "ge,b850v3-lvds-dp" to "b850v3-lvds-dp" to
   remove the comma from the driver name

Changes from V3:
 - Removed the patch that was configuring the mapping between IPUs and external
   displays on the dts file

Peter Senna Tschudin (4):
  dt-bindings: display: megachips-stdp-ge-b850v3-fw
  MAINTAINERS: Add entry for megachips-stdp-ge-b850v3-fw
  drm/bridge: Drivers for megachips-stdp-ge-b850v3-fw (LVDS-DP++)
  dts/imx6q-b850v3: Use megachips-stdp-ge-b850v3-fw bridges
(LVDS-DP++)

 .../bridge/megachips-stdp-ge-b850v3-fw.txt |  94 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|   8 +
 arch/arm/boot/dts/imx6q-b850v3.dts |  68 
 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   | 428 +
 7 files changed, 611 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt
 create mode 100644 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c

-- 
2.9.3

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


Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property

2017-03-05 Thread Alexey Brodkin
Hi Liviu,

On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> > 
> > -   /* find the encoder node and initialize it */
> > -   encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
> > -   if (encoder_node) {
> > -   ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > -   of_node_put(encoder_node);
> > +   /* There is only one output port inside each device, find it */
> > +   port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > +
> > +   if (port) {
> > +   if (of_device_is_available(port))
> > +   encoder = of_graph_get_remote_port_parent(port);
> > +   of_node_put(port);
> > +   }
> 
> You must've been looking at some old version. Current version in -next uses
> of_graph_get_remote_node() to replace all those lines you have added (see Rob
> Herring's series to introduce of_graph_get_remote_node() function)

Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to date :)
Still I made a check of linux-next and don't see any changes in
"drivers/gpu/drm/arm" compared to Linus' tree.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642
[2] 
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642

Could you please clarify which exact tree did you mean?

Anyways I just tried to rebase my patch on top of linux-next tree and now
video output is broken for me - I only see some garbage on top of the screen
so I'll need to investigate it first before moving forward with stuff you
proposed :)

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


[PATCH v3 0/3] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines

2017-03-05 Thread Kieran Bingham
The RCAR-DU utilises a running VSPD pipeline to perform processing for the
display pipeline. This presents the opportunity for some race conditions to
affect the quality of the display output.

To prevent reporting page flips early, we must track this timing through the
VSP1, and only allow the rcar-du object to report the page-flip completion
event after the VSP1 has processed.

This series ensures that tearing and flicker is prevented, without introducing 
the
performance impact mentioned in the previous series.

[PATCH 1/3] handles potential race conditions in vsp1_dlm_irq_frame_end() and
prevents signalling the frame end in this event.
[PATCH 2/3] extends the VSP1 to allow a callback to be registered giving the
VSP1 the ability to notify completion events.
[PATCH 3/3] utilises the callback extension to send page flips at the end of
VSP processing for Gen3 platforms.

These patches have been tested by introducing artificial delays in the commit
code paths and verifying that no visual tearing or flickering occurs.

Extensive testing around the race window has been performed by dynamically
adapting the artificial delay between 10, and 17 seconds in 100uS increments
for periods of 5 seconds on each delay test. These tests have successfully run
for 3 hours.

Manual start/stop testing has also been performed.

Kieran Bingham (3):
  v4l: vsp1: Postpone frame end handling in event of display list race
  v4l: vsp1: Extend VSP1 module API to allow DRM callbacks
  drm: rcar-du: Register a completion callback with VSP1

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  8 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  9 +
 drivers/media/platform/vsp1/vsp1_dl.c   | 19 +--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c  | 17 +
 drivers/media/platform/vsp1/vsp1_drm.h  | 11 +++
 drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
 include/media/vsp1.h| 13 +
 9 files changed, 87 insertions(+), 6 deletions(-)

base-commit: cdb5795cbc4ddbe5082c25c52ebc1d811ac3849e
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 0/7] Fix the parse_dt of exynos dsi and remove the OF graph

2017-03-05 Thread Krzysztof Kozlowski
On Fri, Mar 03, 2017 at 09:22:06AM +0900, Andi Shyti wrote:
> Hi Hoegeun,
> 
> > Hoegeun Kwon (7):
> >   arm64: dts: exynos: Add the burst and esc clock frequency properties
> > for exynos5433 dts
> >   arm: dts: Add the burst and esc clock frequency properties for
> > exynos3250 dts
> >   arm: dts: Add the burst and esc clock frequency properties for
> > exynos4412 dts
> >   arm: dts: Add the burst and esc clock frequency properties for
> > exynos4210 dts
> >   drm/exynos: dsi: Fix the parse_dt function
> >   arm64: dts: exynos: Remove the OF graph from DSI node
> >   arm: dts: Remove the OF graph from DSI node
> 
> for all of them:
> 
> Reviewed-by: Andi Shyti 

Andi,

Thanks for review. It is much welcomed.

I am trying not loose such review tags but it might happen because:
1. Patchwork does not store them,
2. Mail does not sit in inbox for long (inbox zero),
so if it is possible the most convenient for me is to reply with review
to each email.

> 
> although I would have squashed patch 2, 3 and 4, but no need to
> resend, unless someone else agrees.

Yes, these are small additions to the same arch so they could be
indeed squashed. I don't mind keeping them separated though.

Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 7/9] drm: bridge: dw-hdmi: Add support for custom PHY configuration

2017-03-05 Thread Jose Abreu
Hi Laurent,


On 02-03-2017 15:38, Laurent Pinchart wrote:
> Hi Jose,
>
> On Thursday 02 Mar 2017 14:50:02 Jose Abreu wrote:
>> On 02-03-2017 13:41, Laurent Pinchart wrote:
 Hmm, this is kind of confusing. Why do you need a phy_ops and
 then a separate configure_phy function? Can't we just use phy_ops
 always? If its external phy then it would need to implement all
 phy_ops functions.
>>> The phy_ops are indeed meant to support vendor PHYs. The .configure_phy()
>>> operation is meant to support Synopsys PHYs that don't comply with the
>>> HDMI TX MHL and 3D PHYs I2C register layout and thus need a different
>>> configure function, but can share the other operations with the HDMI TX
>>> MHL and 3D PHYs. Ideally I'd like to move that code to the dw-hdmi core,
>>> but at the moment I don't have enough information to decide whether the
>>> register layout corresponds to the standard Synopsys HDMI TX 2.0 PHY or
>>> if it has been modified by the vendor. Once we'll have a second SoC using
>>> the same PHY we should have more information to consolidate the code. Of
>>> course, if you can share the HDMI TX 2.0 PHY datasheet, I won't mind
>>> reworking the code now ;-)
>> Well, if I want to keep my job I can't share the datasheet, and I
>> do want to keep my job :)
> That's so selfish :-D
>
>> As far as I know this shouldn't change much. I already used (it
>> was like a year ago) the dw-hdmi driver in a HDMI TX 2.0 PHY.
> I really wonder what exactly has been integrated in the Renesas R-Car Gen3 
> SoC. The PHY is certainly reported as an HDMI TX 2.0 PHY, but the registers 
> seem different compared to the 2.0 PHY you've tested.
>
>> But I am not following your logic here, sorry: You are mentioning a
>> custom phy, right?
> Custom is probably a bad name. From what I've been told it's a standard 
> Synopsys PHY, but I can't rule out vendor-specific customizations.
>
>> If its custom then it should implement its own phy_ops. And I don't think
>> that phy logic should go into core, this should all be extracted because I
>> really believe it will make the code easier to read. Imagine this
>> organization:
>>
>> Folders/Files:
>> drm/bridge/dw-hdmi/dw-hdmi-core.c
>> drm/bridge/dw-hdmi/dw-hdmi-phy-synopsys.c
>> drm/bridge/dw-hdmi/dw-hdmi-phy-*renesas*.c
>> drm/bridge/dw-hdmi/dw-hdmi-phy-something.c
>> Structures:
>> dw_hdmi_pdata
>> dw_hdmi_phy_pdata
>> dw_hdmi_phy_ops
> That looks good to me.
>
>> As the phy is interacted using controller we would need to pass
>> some callbacks to the phy, but ultimately the phy would be a
>> platform driver which could have its own compatible string that
>> would be associated with controller (not sure exactly about this
>> because I only used this in non-dt).
> We already have glue code, having to provide separate glue and PHY drivers 
> seems a bit overkill to me. If we could get rid of glue code by adding a node 
> for the PHY in DT that would be nice, but if we have to keep the glue then we 
> can as well use platform data there.
>
>> This is just an idea though. I followed this logic in the RX side
>> and its very easy to add a new phy now, its a matter of creating
>> a new file, implement ops and associate it with controller. Of
>> course some phys will be very similar, for that we can use minor
>> tweaks via id detection.
>>
>> What do you think?
> It sounds neat overall, but I wonder whether it should really block this 
> series, or be added on top of it :-) I think we're already moving in the 
> right 
> direction here.
>

This series is definitely a good starting point and a good
improvement. We can think later about abstracting even more the
phy from the controller. I think this will be a major step and
will reflect better how the HW is modeled.

You can add my reviewed-by in all the patches in this series in
your next submission (or in the merge).

Also, if you do a next submission what do you think about moving
all the dw-hdmi files to a new folder called for example
'synopsys' or 'dw-hdmi'? Because we already have 5 files. I think
'synopsys' instead of 'dw-hdmi' would be better because in the
future we may add support for other protocols (for example
display port).

Side note: I think you missed in the cc Archit Taneja

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm: rcar-du: Make sure DRM planes are created by VSP1

2017-03-05 Thread Jacopo Mondi
On Gen3 platforms compositing planes are allocated  by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp1 initialization stub routine is
called, leading to invalid memory accesses later on when un-initialized
planes are accessed.

Fail explicitly earlier if planes are not properly created.

Signed-off-by: Jacopo Mondi 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b5d3f16..7f56c09 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -616,6 +616,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
ret = rcar_du_vsp_init(vsp);
if (ret < 0)
return ret;
+
+   if (!vsp->planes)
+   return -EINVAL;
}
}
 
-- 
2.7.4

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


Re: [PATCHv2 09/10] drm: omapdrm: crtc: get manual mode displays working

2017-03-05 Thread Tony Lindgren
* Sebastian Reichel  [170304 16:45]:
> From: Tony Lindgren 
> 
> With manual mode displays we need to flush the panel manually.
> 
> Let's add flushing so we get Tomi's fbtest, kmstest, kmstest --flip,
> and X and wayland working.
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -97,6 +97,11 @@ bool omap_crtc_is_manual_updated(struct drm_crtc *crtc)
>   return omap_crtc->manually_updated;
>  }
>  
> +static void omap_crtc_manual_needs_flush(struct drm_crtc *crtc)
> +{
> + omap_crtc_flush(crtc, 0, 0, 0, 0);
> +}
...

> @@ -554,6 +561,7 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
>   ret = drm_crtc_vblank_get(crtc);
>   WARN_ON(ret != 0);
>   }
> + omap_crtc_flush(&omap_crtc->base, 0, 0, 0, 0);

Just noticed that this should also just use omap_crtc_manual_needs_flush()
here if you care to update it.

Regards,

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


[PATCH v6 0/3] Add pixel format for 10 bits YUV video

2017-03-05 Thread Randy Li
Thanks to Clint's work, this version just correct some wrong info
in the comment.

I also offer a driver sample here, but it have been verified with
the 10 bits properly. I lacks of the userspace tool. And I am
not sure whether it is a properly way to support the pixel format
used in rockchip, although it is not common used pixel format,
but it could save lots of memory, it may be welcome by the
other vendor, also I think the 3GR serial from Intel would
use the same pixel format as the video IP comes from rockchip.

Randy Li (3):
  drm_fourcc: Add new P010, P016 video format
  v4l: Add 10/16-bits per channel YUV pixel formats
  drm/rockchip: Support 10 bits yuv format in vop

 Documentation/media/uapi/v4l/pixfmt-p010.rst  | 126 
 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
 Documentation/media/uapi/v4l/pixfmt-p016.rst  | 125 
 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
 Documentation/media/uapi/v4l/yuv-formats.rst  |   4 +
 drivers/gpu/drm/drm_fourcc.c  |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  34 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |   1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |   2 +
 include/uapi/drm/drm_fourcc.h |  32 ++
 include/uapi/linux/videodev2.h|   5 +
 12 files changed, 599 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst

-- 
2.7.4

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


[PATCH V3 2/4] MAINTAINERS: Add entry for megachips-stdpxxxx-ge-b850v3-fw

2017-03-05 Thread Peter Senna Tschudin
Add MAINTAINERS entry for the second video output of the GE B850v3:
   STDP4028-ge-b850v3-fw bridges (LVDS-DP)
   STDP2690-ge-b850v3-fw bridges (DP-DP++)

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
CC: David Airlie 
CC: Thierry Reding 
CC: Thierry Reding 
CC: Archit Taneja 
Signed-off-by: Peter Senna Tschudin 
---
Unchanged since V1

 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index bc12716..d8c841a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8127,6 +8127,14 @@ L:   linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/mediatek/mt7601u/
 
+MEGACHIPS STDP-GE-B850V3-FW LVDS/DP++ BRIDGES
+M: Peter Senna Tschudin 
+M: Martin Donnelly 
+M: Martyn Welch 
+S: Maintained
+F: drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+F: 
Documentation/devicetree/bindings/video/bridge/megachips-stdp-ge-b850v3-fw.txt
+
 MEGARAID SCSI/SAS DRIVERS
 M: Kashyap Desai 
 M: Sumit Saxena 
-- 
2.9.3

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


[PATCHv2 05/10] drm: omapdrm: crtc: detect manually updated displays

2017-03-05 Thread Sebastian Reichel
Signed-off-by: Sebastian Reichel 
[t...@atomide.com: rebased on event_lock changes]
---
 drivers/gpu/drm/omapdrm/dss/omapdss.h|  1 +
 drivers/gpu/drm/omapdrm/dss/output.c |  6 ++
 drivers/gpu/drm/omapdrm/omap_connector.c |  7 +++
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 29 +++--
 drivers/gpu/drm/omapdrm/omap_drv.h   |  2 ++
 5 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 5b3b961127bd..5666ecbe4b80 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -918,5 +918,6 @@ int dss_mgr_register_framedone_handler(enum omap_channel 
channel,
void (*handler)(void *), void *data);
 void dss_mgr_unregister_framedone_handler(enum omap_channel channel,
void (*handler)(void *), void *data);
+bool dss_lcd_mgr_config_get_stallmode(const struct dss_lcd_mgr_config *config);
 
 #endif /* __OMAP_DRM_DSS_H */
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
b/drivers/gpu/drm/omapdrm/dss/output.c
index a901af5a9bc3..08c730d1dada 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -214,6 +214,12 @@ void dss_mgr_set_lcd_config(enum omap_channel channel,
 }
 EXPORT_SYMBOL(dss_mgr_set_lcd_config);
 
+bool dss_lcd_mgr_config_get_stallmode(const struct dss_lcd_mgr_config *config)
+{
+   return config->stallmode;
+}
+EXPORT_SYMBOL(dss_lcd_mgr_config_get_stallmode);
+
 int dss_mgr_enable(enum omap_channel channel)
 {
return dss_mgr_ops->enable(channel);
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 7b2a9f680dce..b09d8989b789 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -35,6 +35,13 @@ struct omap_connector {
bool hdmi_mode;
 };
 
+bool omap_connector_get_manually_updated(struct drm_connector *connector)
+{
+   struct omap_connector *omap_connector = to_omap_connector(connector);
+
+   return !!(omap_connector->dssdev->caps & 
OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE);
+}
+
 bool omap_connector_get_hdmi_mode(struct drm_connector *connector)
 {
struct omap_connector *omap_connector = to_omap_connector(connector);
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 76a411fe957a..03351ca2ee41 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -35,6 +35,7 @@ struct omap_crtc {
enum omap_channel channel;
 
struct videomode vm;
+   bool manually_updated;
 
bool ignore_digit_sync_lost;
 
@@ -89,6 +90,12 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
  msecs_to_jiffies(250));
 }
 
+bool omap_crtc_is_manual_updated(struct drm_crtc *crtc)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   return omap_crtc->manually_updated;
+}
+
 /* 
-
  * DSS Manager Functions
  */
@@ -237,6 +244,9 @@ static void omap_crtc_dss_set_lcd_config(enum omap_channel 
channel,
 {
struct omap_crtc *omap_crtc = omap_crtcs[channel];
DBG("%s", omap_crtc->name);
+
+   omap_crtc->manually_updated = dss_lcd_mgr_config_get_stallmode(config);
+
dispc_mgr_set_lcd_config(omap_crtc->channel, config);
 }
 
@@ -355,10 +365,23 @@ static void omap_crtc_destroy(struct drm_crtc *crtc)
 static void omap_crtc_enable(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
+   struct drm_connector *connector;
int ret;
 
DBG("%s", omap_crtc->name);
 
+   /* manual updated display will not trigger vsync irq */
+   /* omap_crtc->manually_updated is not yet set */
+   drm_for_each_connector(connector, crtc->dev) {
+   if (connector->state->crtc != crtc)
+   continue;
+   if (!omap_connector_get_manually_updated(connector))
+   continue;
+   dev_dbg(dev->dev, "manually updated display detected!");
+   return;
+   }
+
spin_lock_irq(&crtc->dev->event_lock);
drm_crtc_vblank_on(crtc);
ret = drm_crtc_vblank_get(crtc);
@@ -440,8 +463,10 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
 
DBG("%s: GO", omap_crtc->name);
 
-   ret = drm_crtc_vblank_get(crtc);
-   WARN_ON(ret != 0);
+   if (!omap_crtc->manually_updated) {
+   ret = drm_crtc_vblank_get(crtc);
+   WARN_ON(ret != 0);
+   }
 
spin_lock_irq(&crtc->dev->event_lock);
dispc_mgr_go(omap_crtc->channel);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 5b1061586401..5a0106239be2 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/g

[PATCH v2 3/3] drm: rcar-du: Register a completion callback with VSP1

2017-03-05 Thread Kieran Bingham
Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 

---
v2:
 - Commit message completely re-worded for patch re-work.
 - drm_crtc_handle_vblank() re-instated in event of rcrtc->pending
 - removed passing of unnecessary 'data' through callbacks
 - perform page flips from the VSP completion handler
 - add locking around pending flags

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 10 +++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  2 ++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 29 +++-
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7391dd95c733..b7ff00bb45de 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -299,7 +299,7 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
  * Page Flip
  */
 
-static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
 {
struct drm_pending_vblank_event *event;
struct drm_device *dev = rcrtc->crtc.dev;
@@ -328,7 +328,7 @@ static bool rcar_du_crtc_page_flip_pending(struct 
rcar_du_crtc *rcrtc)
bool pending;
 
spin_lock_irqsave(&dev->event_lock, flags);
-   pending = rcrtc->event != NULL;
+   pending = (rcrtc->event != NULL) || (rcrtc->pending);
spin_unlock_irqrestore(&dev->event_lock, flags);
 
return pending;
@@ -579,6 +579,12 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 
if (status & DSSR_FRM) {
drm_crtc_handle_vblank(&rcrtc->crtc);
+
+   if (rcrtc->pending) {
+   trace_printk("VBlank loss due to VSP Overrun\n");
+   return IRQ_HANDLED;
+   }
+
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index a7194812997e..b73ec6de7af4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -47,6 +47,7 @@ struct rcar_du_crtc {
 
struct drm_pending_vblank_event *event;
wait_queue_head_t flip_wait;
+   bool pending;
 
unsigned int outputs;
 
@@ -71,5 +72,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
 
 void rcar_du_crtc_route_output(struct drm_crtc *crtc,
   enum rcar_du_output output);
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
 
 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..1fcd311badb1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,22 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
+   struct drm_device *dev = crtc->crtc.dev;
+   unsigned long flags;
+   bool pending;
+
+   spin_lock_irqsave(&dev->event_lock, flags);
+   pending = crtc->pending;
+   crtc->pending = false;
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+
+   if (pending)
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = &crtc->crtc.state->adjusted_mode;
@@ -35,6 +51,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
struct vsp1_du_lif_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
+   .callback = rcar_du_vsp_complete,
+   .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
@@ -85,6 +103,17 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
 
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
 {
+   struct drm_device *dev = crtc->crtc.dev;
+   unsigned long flags;
+   bool pending;
+
+   spin_lock_irqsave(&dev->event_lock, flags);
+   pending = crtc->pending;
+   crtc->pending = true;
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+
+   WARN_ON(pending);
+
vsp1_du_atomic_flush(crtc->vsp->vsp);
 }
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

2017-03-05 Thread Alexey Brodkin
Hi Daniel,

On Thu, 2017-03-02 at 20:54 +0100, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 08:27:54PM +0300, Alexey Brodkin wrote:
> > 
> > Since we cannot always generate exactly requested pixel clock
> > there's not much sense in checking requested_clock == clk_round_rate().
> > In that case for quite some modes we'll be getting -EINVAL and no video
> > output at all.
> > 
> > But given there's some tolerance to real pixel clock in TVs/monitors
> > we may still give it a try with the clock as close to requested one as
> > PLL on the board may generate. So we just do a fixup to what current
> > board may provide.
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: Jose Abreu 
> > ---
> >  drivers/gpu/drm/arc/arcpgu_crtc.c | 16 +++-
> >  1 file changed, 7 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index ad9a95916f1f..3f2823c1efc3 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -129,18 +129,16 @@ static void arc_pgu_crtc_disable(struct drm_crtc 
> > *crtc)
> >       ~ARCPGU_CTRL_ENABLE_MASK);
> >  }
> >  
> > -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> > -    struct drm_crtc_state *state)
> > +static bool arc_pgu_crtc_mode_fixup(struct drm_crtc *crtc,
> > +   const struct drm_display_mode *mode,
> > +   struct drm_display_mode *adjusted_mode)
> 
> This isn't required at all, see drm_crtc_state.adjusted_mode. Just update
> that and you're good - .mode_fixup is the backwards compatibility function
> for old kms drivers, atomic_check is strictly more powerful.

So if I understood you correct here what I really need is just to get rid of 
existing check,
right? I.e. the following is to be in v2 respin:
--->8---
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..86f1555914e8 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -129,20 +129,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
  ~ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
-struct drm_crtc_state *state)
-{
-   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
-   struct drm_display_mode *mode = &state->adjusted_mode;
-   long rate, clk_rate = mode->clock * 1000;
-
-   rate = clk_round_rate(arcpgu->clk, clk_rate);
-   if (rate != clk_rate)
-   return -EINVAL;
-
-   return 0;
-}
-
 static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
  struct drm_crtc_state *state)
 {
@@ -165,7 +151,6 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
.commit = arc_pgu_crtc_enable,
-   .atomic_check   = arc_pgu_crtc_atomic_check,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
--->8---

> Please also make sure the documentation properly explains this, and if
> not, please submit a patch to improve it.

You mean explains what? That .mode_fixup is not meant to be used in
new code?

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


[PATCH V3 4/4] dts/imx6q-b850v3: Use megachips-stdpxxxx-ge-b850v3-fw bridges (LVDS-DP++)

2017-03-05 Thread Peter Senna Tschudin
Configures the megachips-stdp-ge-b850v3-fw bridges on the GE
B850v3 dts file.

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Javier Martinez Canillas 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Signed-off-by: Peter Senna Tschudin 
---
Unchanged since V1.

 arch/arm/boot/dts/imx6q-b850v3.dts | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
b/arch/arm/boot/dts/imx6q-b850v3.dts
index b237429..3ec54da 100644
--- a/arch/arm/boot/dts/imx6q-b850v3.dts
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -72,6 +72,13 @@
fsl,data-mapping = "spwg";
fsl,data-width = <24>;
status = "okay";
+
+   port@4 {
+   reg = <4>;
+   lvds0_out: endpoint {
+   remote-endpoint = <&stdp4028_in>;
+   };
+   };
};
 };
 
@@ -146,3 +153,64 @@
 &usdhc2 {
status = "disabled";
 };
+
+&mux2_i2c2 {
+   status = "okay";
+   clock-frequency = <10>;
+
+   stdp4028@73 {
+   compatible = "megachips,stdp4028-ge-b850v3-fw";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0x73>;
+
+   interrupt-parent = <&gpio2>;
+   interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   stdp4028_in: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   stdp4028_out: endpoint {
+   remote-endpoint = <&stdp2690_in>;
+   };
+   };
+   };
+   };
+
+   stdp2690@72 {
+   compatible = "megachips,stdp2690-ge-b850v3-fw";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0x72>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   stdp2690_in: endpoint {
+   remote-endpoint = <&stdp4028_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   stdp2690_out: endpoint {
+   /* Connector for external display */
+   };
+   };
+   };
+   };
+};
-- 
2.9.3

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


[PATCH v3 2/3] v4l: vsp1: Extend VSP1 module API to allow DRM callbacks

2017-03-05 Thread Kieran Bingham
To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.

We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback to be registered within the VSP DRM interface.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 17 +
 drivers/media/platform/vsp1/vsp1_drm.h | 11 +++
 include/media/vsp1.h   | 13 +
 3 files changed, 41 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 4ee437c7ff0c..d93bf7d3a39e 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -37,6 +37,14 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
 }
 
+static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm *drm = to_vsp1_drm(pipe);
+
+   if (drm->du_complete)
+   drm->du_complete(drm->du_private);
+}
+
 /* 
-
  * DU Driver API
  */
@@ -96,6 +104,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
}
 
pipe->num_inputs = 0;
+   vsp1->drm->du_complete = NULL;
 
vsp1_dlm_reset(pipe->output->dlm);
vsp1_device_put(vsp1);
@@ -200,6 +209,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
if (ret < 0)
return ret;
 
+   /*
+* Register a callback to allow us to notify the DRM framework of frame
+* completion events.
+*/
+   vsp1->drm->du_complete = cfg->callback;
+   vsp1->drm->du_private = cfg->callback_data;
+
ret = media_pipeline_start(&pipe->output->entity.subdev.entity,
  &pipe->pipe);
if (ret < 0) {
@@ -607,6 +623,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->lif = &vsp1->lif->entity;
pipe->output = vsp1->wpf[0];
pipe->output->pipe = pipe;
+   pipe->frame_end = vsp1_du_pipeline_frame_end;
 
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index c8d2f88fc483..3de2095cb0ce 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -23,6 +23,8 @@
  * @num_inputs: number of active pipeline inputs at the beginning of an update
  * @inputs: source crop rectangle, destination compose rectangle and z-order
  * position for every input
+ * @du_complete: frame completion callback for the DU driver (optional)
+ * @du_private: data to be passed to the du_complete callback
  */
 struct vsp1_drm {
struct vsp1_pipeline pipe;
@@ -33,8 +35,17 @@ struct vsp1_drm {
struct v4l2_rect compose;
unsigned int zpos;
} inputs[VSP1_MAX_RPF];
+
+   /* Frame syncronisation */
+   void (*du_complete)(void *);
+   void *du_private;
 };
 
+static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
+{
+   return container_of(pipe, struct vsp1_drm, pipe);
+}
+
 int vsp1_drm_init(struct vsp1_device *vsp1);
 void vsp1_drm_cleanup(struct vsp1_device *vsp1);
 int vsp1_drm_create_links(struct vsp1_device *vsp1);
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index bfc701f04f3f..d59d0adf560d 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -20,9 +20,22 @@ struct device;
 
 int vsp1_du_init(struct device *dev);
 
+/**
+ * struct vsp1_du_lif_config - VSP LIF configuration
+ * @width: output frame width
+ * @height: output frame height
+ * @callback: frame completion callback function (optional)
+ * @callback_data: data to be passed to the frame completion callback
+ *
+ * When the optional callback is provided to the VSP1, the VSP1 must guarantee
+ * that one completion callback is performed after every vsp1_du_atomic_flush()
+ */
 struct vsp1_du_lif_config {
unsigned int width;
unsigned int height;
+
+   void (*callback)(void *);
+   void *callback_data;
 };
 
 int vsp1_du_setup_lif(struct device *dev, const struct vsp1_du_lif_config 
*cfg);
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH V3 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

2017-03-05 Thread Peter Senna Tschudin
The video processing pipeline on the second output on the GE B850v3:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Each bridge has a dedicated flash containing firmware for supporting the
custom design. The result is that in this design neither the STDP4028
nor the STDP2690 behave as the stock bridges would. The compatible
strings include the suffix "-ge-b850v3-fw" to make it clear that the
driver is for the bridges with the firmware which is specific for the GE
B850v3.

The driver is powerless to control the video processing pipeline, as the
two bridges behaves as a single one. The driver is only needed for
telling the host about EDID / HPD, and for giving the host powers to ack
interrupts.

This driver adds one i2c_device for each bridge, but only one
drm_bridge. This design allows the creation of a functional connector
that is capable of reading EDID from the STDP2690 while handling
interrupts on the STDP4028.

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Cc: David Airlie 
Cc: Thierry Reding 
Cc: Thierry Reding 
Cc: Archit Taneja 
Cc: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 
---
Changes from V2:
 - Fix the code to allow it be compiled as a module

Changes from V1:
 - Updated copyright year
 - Fixed blank line issues
 - Updated ge_b850v3_lvds_remove() to not rely on ge_b850v3_lvds_ptr->edid and
   added a comment to explain the test.
 - Fixed checkpatch strict warnings about continuation lines. In one case
   fixing the warning would cause the continuation line to be over 80 chars and
   that strict warning remains.

 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   | 428 +
 3 files changed, 440 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..4a937f1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.
 
+config DRM_MEGACHIPS_STDP_GE_B850V3_FW
+   tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridges of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver. You are likely to say N here.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..af0b7cc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
new file mode 100644
index 000..e53c243
--- /dev/null
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -0,0 +1,428 @@
+/*
+ * Driver for MegaChips STDP4028 with GE B850v3 firmware (LVDS-DP)
+ * Driver for MegaChips STDP2690 with GE B850v3 firmware (DP-DP++)
+
+ * Copyright (c) 2017, Collabora Ltd.
+ * Copyright (c) 2017, General Electric Company
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+
+ * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
+ * display bridge of the GE B850v3. There are two physical bridges on the video
+ * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The
+ * physical bridges are automatically configured by the input video signal, and
+ * the driver has no access to the video processing 

[PATCH v2 0/3] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines

2017-03-05 Thread Kieran Bingham
The RCAR-DU utilises a running VSPD pipeline to perform processing
for the display pipeline.

Changes to this pipeline are performed with an atomic flush operation which
updates the state in the VSPD. Due to the way the running pipeline is
operated, any flush operation has an implicit latency of one frame interval.

This comes about as the display list is committed, but not updated until the
next VSP1 interrupt. At this point the frame is being processed, but is not
complete until the following VSP1 frame end interrupt.

To prevent reporting page flips early, we must track this timing through the
VSP1, and only allow the rcar-du object to report the page-flip completion
event after the VSP1 has processed.

This series ensures that tearing and flicker is prevented, without introducing 
the
performance impact mentioned in the previous series.

[PATCH 1/3] extends the VSP1 to allow a callback to be registered giving the
VSP1 the ability to notify completion events
[PATCH 2/3] checks for race conditions in the commits of the display list, and
in such event postpones the sending of the completion event
[PATCH 3/3] Utilises the callback extension to send page flips at the end of
VSP processing.

These patches have been tested by introducing artificial delays in the commit
code paths and verifying that no visual tearing or flickering occurs.

Manual start/stop testing has also been performed

Kieran Bingham (3):
  v4l: vsp1: extend VSP1 module API to allow DRM callbacks
  v4l: vsp1: Postpone page flip in event of display list race
  drm: rcar-du: Register a completion callback with VSP1

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 10 +++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  2 ++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 29 ++-
 drivers/media/platform/vsp1/vsp1_dl.c   |  9 ++--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c  | 22 -
 drivers/media/platform/vsp1/vsp1_drm.h  | 10 +-
 drivers/media/platform/vsp1/vsp1_pipe.c |  6 -
 drivers/media/platform/vsp1/vsp1_pipe.h |  2 ++-
 include/media/vsp1.h|  3 +++-
 10 files changed, 89 insertions(+), 6 deletions(-)

base-commit: 55e78dfc82988a79773ccca67e121f9a88df81c2
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 4/6] drm/edid: detect SCDC support in HF-VSDB

2017-03-05 Thread Jose Abreu
Hi Shashank,


On 03-03-2017 06:29, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
>   This structure will be used to save and indicate if sink
>   supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_hdmi_info, to
>   reflect scdc support and capabilities in connected HDMI 2.0 sink.
> - Checks the HF-VSDB block for presence of SCDC, and marks it
>   in scdc structure
> - If SCDC is present, checks if sink is capable of generating
>   SCDC read request, and marks it in scdc structure.
>
> V2: Addressed review comments
>   Thierry:
>   - Fix typos in commit message and make abbreviation consistent
> across the commit message.
>   - Change structure object name from hdmi_info -> hdmi
>   - Fix typos and abbreviations in description of structure drm_hdmi_info
> end the description with a full stop.
>   - Create a structure drm_scdc, and keep all information related to SCDC
> register set (supported, read request supported) etc in it.
>
>   Ville:
>   - Change rr -> read_request
>   - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
> of HF-VSDB parsing can be kept in same function, in incremental
> patches.
>
> V3: Rebase.
> V4: Rebase.
> V5: Rebase.
> V6: Addressed review comments from Ville
>   - Add clock rate calculations for 1/10 and 1/40 ratios
>   - Remove leftovers from old patchset
>
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Thierry Reding 

Maybe drm_scdc_set_scrambling() and
drm_scdc_set_high_tmds_clock_ratio() should return int error code
instead of bool, but anyway:

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/drm_edid.c|  33 ++-
>  drivers/gpu/drm/drm_scdc_helper.c | 121 
> ++
>  include/drm/drm_connector.h   |  19 ++
>  include/drm/drm_edid.h|   1 -
>  include/drm/drm_scdc_helper.h |  27 +
>  5 files changed, 199 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d64b7bd..fad3d44 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -3820,13 +3821,43 @@ enum hdmi_quantization_range
>  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>const u8 *hf_vsdb)
>  {
> - struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> + struct drm_display_info *display = &connector->display_info;
> + struct drm_hdmi_info *hdmi = &display->hdmi;
>  
>   if (hf_vsdb[6] & 0x80) {
>   hdmi->scdc.supported = true;
>   if (hf_vsdb[6] & 0x40)
>   hdmi->scdc.read_request = true;
>   }
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
> +  * * SCDC support available (let's check)
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + /* max clock is 5000 KHz times block value */
> + u32 max_tmds_clock = hf_vsdb[5] * 5000;
> + struct drm_scdc *scdc = &hdmi->scdc;
> +
> + if (max_tmds_clock > 34) {
> + display->max_tmds_clock = max_tmds_clock;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> + }
> +
> + if (scdc->supported) {
> + scdc->scrambling.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + scdc->scrambling.low_rates = true;
> + }
> + }
>  }
>  
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
> b/drivers/gpu/drm/drm_scdc_helper.c
> index c2dd33f..3cd96a9 100644
> --- a/drivers/gpu/drm/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -22,8 +22,10 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
> +#include 
>  
>  /**
>   * DOC: scdc helpers
> @@ -121,3 +123,122 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
> offset,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_scdc_write);
> +
> +/**
> + * drm_scdc_check_scrambling_status - what is status of scrambling?
> + * @adapter: I2C adapter for DDC channel
> + *
> + * Reads the scrambler status over SCDC, and checks the
> + * scrambling status.
> + *
> + * Returns:
> + * True if the scrambling is enabled, false otherwise.
> + */
> +
> +bool drm_scdc_get_scrambling_status(struct i2c_adapter *

[PATCHv2 03/10] Revert "drm: omapdrm: Remove manual update display support"

2017-03-05 Thread Sebastian Reichel
This reverts commit 5a35876e2830511cb8110667fc426c6a6165a593.

Revert the removal of manual update display support in
preparation for DSI command mode panels.

Signed-off-By: Sebastian Reichel 
[t...@atomide.com: left out unused omap_framebuffer_dirty]
Signed-off-by: Tony Lindgren 
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 12 +++
 drivers/gpu/drm/omapdrm/omap_drv.h   |  4 +++
 drivers/gpu/drm/omapdrm/omap_fb.c| 28 
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 57 +---
 4 files changed, 97 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index f90e2d22c5ec..7b2a9f680dce 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -205,6 +205,18 @@ static const struct drm_connector_helper_funcs 
omap_connector_helper_funcs = {
.mode_valid = omap_connector_mode_valid,
 };
 
+/* flush an area of the framebuffer (in case of manual update display that
+ * is not automatically flushed)
+ */
+void omap_connector_flush(struct drm_connector *connector,
+   int x, int y, int w, int h)
+{
+   struct omap_connector *omap_connector = to_omap_connector(connector);
+
+   /* TODO: enable when supported in dss */
+   VERB("%s: %d,%d, %dx%d", omap_connector->dssdev->name, x, y, w, h);
+}
+
 /* initialize connector */
 struct drm_connector *omap_connector_init(struct drm_device *dev,
int connector_type, struct omap_dss_device *dssdev,
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 65977982f15f..5b1061586401 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -155,6 +155,8 @@ struct drm_connector *omap_connector_init(struct drm_device 
*dev,
 struct drm_encoder *omap_connector_attached_encoder(
struct drm_connector *connector);
 bool omap_connector_get_hdmi_mode(struct drm_connector *connector);
+void omap_connector_flush(struct drm_connector *connector,
+   int x, int y, int w, int h);
 
 uint32_t omap_framebuffer_get_formats(uint32_t *pixel_formats,
uint32_t max_formats, enum omap_color_mode supported_modes);
@@ -169,6 +171,8 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
 struct drm_connector *omap_framebuffer_get_next_connector(
struct drm_framebuffer *fb, struct drm_connector *from);
 bool omap_framebuffer_supports_rotation(struct drm_framebuffer *fb);
+void omap_framebuffer_flush(struct drm_framebuffer *fb,
+   int x, int y, int w, int h);
 
 void omap_gem_init(struct drm_device *dev);
 void omap_gem_deinit(struct drm_device *dev);
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 29dc677dd4d3..b6ae28fe3257 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -333,6 +333,34 @@ struct drm_connector *omap_framebuffer_get_next_connector(
return NULL;
 }
 
+/* flush an area of the framebuffer (in case of manual update display that
+ * is not automatically flushed)
+ */
+void omap_framebuffer_flush(struct drm_framebuffer *fb,
+   int x, int y, int w, int h)
+{
+   struct drm_connector *connector = NULL;
+
+   VERB("flush: %d,%d %dx%d, fb=%p", x, y, w, h, fb);
+
+   /* FIXME: This is racy - no protection against modeset config changes. 
*/
+   while ((connector = omap_framebuffer_get_next_connector(fb, 
connector))) {
+   /* only consider connectors that are part of a chain */
+   if (connector->encoder && connector->encoder->crtc) {
+   /* TODO: maybe this should propagate thru the crtc who
+* could do the coordinate translation..
+*/
+   struct drm_crtc *crtc = connector->encoder->crtc;
+   int cx = max(0, x - crtc->x);
+   int cy = max(0, y - crtc->y);
+   int cw = w + (x - crtc->x) - cx;
+   int ch = h + (y - crtc->y) - cy;
+
+   omap_connector_flush(connector, cx, cy, cw, ch);
+   }
+   }
+}
+
 #ifdef CONFIG_DEBUG_FS
 void omap_framebuffer_describe(struct drm_framebuffer *fb, struct seq_file *m)
 {
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 942c4d483008..6c52a9fa4a37 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -42,8 +42,42 @@ struct omap_fbdev {
struct work_struct work;
 };
 
+static void omap_fbdev_flush(struct fb_info *fbi, int x, int y, int w, int h);
 static struct drm_fb_helper *get_fb(struct fb_info *fbi);
 
+static ssize_t omap_fbdev_write(struct fb_info *fbi, const char __user *buf,
+   size_t count, loff_t *ppos)
+{
+   ssize_t res;
+
+   res

[PATCHv2 08/10] drm: omapdrm: crtc: handle framedone directly

2017-03-05 Thread Sebastian Reichel
From: Tony Lindgren 

We can handle framedone interrupt directly simlar to commit
e0519af75d6e ("drm: omapdrm: Handle CRTC error IRQs directly").

By default we just print a warning on framedone and do nothing.
Any manually refreshed displays can register a callback.

Signed-off-by: Tony Lindgren 
[Drop REVISIT comment for omap3, patch works on N950]
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 25 +
 drivers/gpu/drm/omapdrm/omap_drv.h  |  1 +
 drivers/gpu/drm/omapdrm/omap_irq.c  |  7 ++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 432ad6023f27..4601533215d6 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -349,6 +349,31 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
 }
 
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   if (!omap_crtc->framedone_handler) {
+   dev_warn(omap_crtc->base.dev->dev, "no framedone handler?\n");
+
+   return;
+   }
+
+   omap_crtc->framedone_handler(omap_crtc->framedone_handler_data);
+
+   spin_lock(&crtc->dev->event_lock);
+   /* Send the vblank event if one has been requested. */
+   if (omap_crtc->event) {
+   drm_crtc_send_vblank_event(crtc, omap_crtc->event);
+   omap_crtc->event = NULL;
+   }
+   omap_crtc->pending = false;
+   spin_unlock(&crtc->dev->event_lock);
+
+   /* Wake up omap_atomic_complete. */
+   wake_up(&omap_crtc->pending_wait);
+}
+
 void omap_crtc_flush(struct drm_crtc *crtc,
int x, int y, int w, int h)
 {
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 71b5c5e25ee4..9586551960e9 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -138,6 +138,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id);
 int omap_crtc_wait_pending(struct drm_crtc *crtc);
 void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus);
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus);
 void omap_crtc_vblank_irq(struct drm_crtc *crtc);
 bool omap_crtc_is_manual_updated(struct drm_crtc *crtc);
 
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 9adfa7c99695..fb39601721f6 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -215,6 +215,9 @@ static irqreturn_t omap_irq_handler(int irq, void *arg)
 
if (irqstatus & dispc_mgr_get_sync_lost_irq(channel))
omap_crtc_error_irq(crtc, irqstatus);
+
+   if (irqstatus & dispc_mgr_get_framedone_irq(channel))
+   omap_crtc_framedone_irq(crtc, irqstatus);
}
 
omap_irq_ocp_error_handler(irqstatus);
@@ -264,8 +267,10 @@ int omap_drm_irq_install(struct drm_device *dev)
priv->irq_mask |= omap_underflow_irqs[i];
}
 
-   for (i = 0; i < num_mgrs; ++i)
+   for (i = 0; i < num_mgrs; ++i) {
priv->irq_mask |= dispc_mgr_get_sync_lost_irq(i);
+   priv->irq_mask |= dispc_mgr_get_framedone_irq(i);
+   }
 
dispc_runtime_get();
dispc_clear_irqstatus(0x);
-- 
2.11.0

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


[PATCHv2 06/10] drm: omapdrm: crtc: add support for manual updated displays

2017-03-05 Thread Sebastian Reichel
Signed-off-by: Sebastian Reichel 
[t...@atomide.com: rebased and fixed up to work with droid 4]
Signed-off-by: Tony Lindgren 
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 12 --
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 65 
 drivers/gpu/drm/omapdrm/omap_drv.h   |  2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c|  2 +-
 4 files changed, 67 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index b09d8989b789..5ab672cac0b2 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -212,18 +212,6 @@ static const struct drm_connector_helper_funcs 
omap_connector_helper_funcs = {
.mode_valid = omap_connector_mode_valid,
 };
 
-/* flush an area of the framebuffer (in case of manual update display that
- * is not automatically flushed)
- */
-void omap_connector_flush(struct drm_connector *connector,
-   int x, int y, int w, int h)
-{
-   struct omap_connector *omap_connector = to_omap_connector(connector);
-
-   /* TODO: enable when supported in dss */
-   VERB("%s: %d,%d, %dx%d", omap_connector->dssdev->name, x, y, w, h);
-}
-
 /* initialize connector */
 struct drm_connector *omap_connector_init(struct drm_device *dev,
int connector_type, struct omap_dss_device *dssdev,
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 03351ca2ee41..432ad6023f27 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -43,6 +43,7 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+   struct delayed_work update_work;
 
void (*framedone_handler)(void *);
void *framedone_handler_data;
@@ -138,6 +139,7 @@ static void omap_crtc_dss_disconnect(enum omap_channel 
channel,
 
 static void omap_crtc_dss_start_update(enum omap_channel channel)
 {
+   dispc_mgr_enable(channel, true);
 }
 
 /* Called only from the encoder enable/disable and suspend/resume handlers. */
@@ -347,6 +349,60 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
 }
 
+void omap_crtc_flush(struct drm_crtc *crtc,
+   int x, int y, int w, int h)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   if (!omap_crtc->manually_updated)
+   return;
+
+   if (!delayed_work_pending(&omap_crtc->update_work))
+   schedule_delayed_work(&omap_crtc->update_work, 0);
+}
+
+static void omap_crtc_manual_display_update(struct work_struct *data)
+{
+   struct omap_crtc *omap_crtc = container_of(data, struct omap_crtc,
+   update_work.work);
+   struct drm_crtc *crtc = &omap_crtc->base;
+   struct omap_dss_device *dssdev = omap_crtc_output[omap_crtc->channel];
+   struct omap_dss_driver *dssdrv;
+   int ret;
+
+   if (!dssdev || !dssdev->dst) {
+   dev_err_once(omap_crtc->base.dev->dev, "missing dssdev!\n");
+   return;
+   }
+
+   dssdev = dssdev->dst;
+   dssdrv = dssdev->driver;
+
+   if (!dssdrv)
+   return;
+
+   if (!dssdrv || !dssdrv->update)
+   return;
+
+   /*
+* REVISIT: Testing and setting omap_crtc->pending here will cause all
+* kind of warnings at least on droid 4. Maybe we should be testing
+* something else here instead of omap_crtc->pending?
+*/
+
+   if (dssdrv->sync)
+   dssdrv->sync(dssdev);
+
+   ret = dssdrv->update(dssdev, 0, 0,
+dssdev->panel.vm.vactive, 
dssdev->panel.vm.hactive);
+   if (ret < 0) {
+   spin_lock_irq(&crtc->dev->event_lock);
+   omap_crtc->pending = false;
+   spin_unlock_irq(&crtc->dev->event_lock);
+   wake_up(&omap_crtc->pending_wait);
+   }
+}
+
 /* 
-
  * CRTC Functions
  */
@@ -395,9 +451,15 @@ static void omap_crtc_enable(struct drm_crtc *crtc)
 static void omap_crtc_disable(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
 
DBG("%s", omap_crtc->name);
 
+   cancel_delayed_work(&omap_crtc->update_work);
+
+   if (!omap_crtc_wait_pending(crtc))
+   dev_warn(dev->dev, "manual display update did not finish!");
+
drm_crtc_vblank_off(crtc);
 }
 
@@ -469,6 +531,7 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
}
 
spin_lock_irq(&crtc->dev->event_lock);
+   dispc_mgr_enable(omap_crtc->channel, true);
dispc_mgr_go(omap_crtc->channel);
 
WARN_ON(omap_crtc->pending);
@@ -597,6 +660,8 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
om

[PATCHv2 10/10] ARM: dts: n950: add display support

2017-03-05 Thread Sebastian Reichel
Add basic panel support for the Nokia N950. It must be tweaked a
little bit later, since the panel was built into the device
upside-down. Also the first 5 and the last 5 pixels are covered
by plastic.

Signed-off-By: Sebastian Reichel 
---
 arch/arm/boot/dts/omap3-n950.dts | 89 
 1 file changed, 89 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index 646601a3ebd8..1aa4251b39d7 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -51,6 +51,26 @@
};
 };
 
+&omap3_pmx_core {
+   dsi_pins: pinmux_dsi_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dx0 - data0+ */
+   OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dy0 - data0- */
+   OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dx1 - clk+   */
+   OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dy1 - clk-   */
+   OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dx2 - data1+ */
+   OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dy2 - data1- */
+   >;
+   };
+
+   display_pins: pinmux_display_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x20ca, PIN_INPUT | MUX_MODE4) /* 
gpio 62 - display te */
+   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE4) /* 
gpio 87 - display reset */
+   >;
+   };
+};
+
 &i2c2 {
smia_1: camera@10 {
compatible = "nokia,smia";
@@ -185,3 +205,72 @@
st,max-limit-y = <32>;
st,max-limit-z = <32>;
 };
+
+&dss {
+   status = "ok";
+
+   vdda_video-supply = <&vdac>;
+};
+
+&dsi {
+   status = "ok";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&dsi_pins>;
+
+   vdd-supply = <&vpll2>;
+
+   port {
+   dsi_out_ep: endpoint {
+   remote-endpoint = <&lcd0_in>;
+   lanes = <2 3 0 1 4 5>;
+   };
+   };
+
+   lcd0: display {
+   compatible = "nokia,himalaya", "panel-dsi-cm";
+   label = "lcd0";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&display_pins>;
+
+   vpnl-supply = <&vmmc2>;
+   vddi-supply = <&vio>;
+
+   reset-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */
+   te-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;/* 62 */
+
+   has-dsi-backlight;
+
+   /* panel is upside-down, 480x464 pixels */
+   /* top and bottom 5 lines are not visible */
+   /* physical dimensions: 48960µm x 88128µm */
+   panel-timing {
+   clock-frequency = <0>;  /* Calculated by dsi */
+
+   hback-porch = <2>;
+   hactive = <480>;
+   hfront-porch = <0>;
+   hsync-len = <2>;
+
+   vback-porch = <1>;
+   vactive = <864>;
+   vfront-porch = <0>;
+   vsync-len = <1>;
+
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <1>;
+   pixelclk-active = <1>;
+
+   /* TODO: rotate panel by 180° */
+   /* TODO: add 5 pixel y-offset and limit vactive to 854 
*/
+   };
+
+   port {
+   lcd0_in: endpoint {
+   remote-endpoint = <&dsi_out_ep>;
+   };
+   };
+   };
+};
-- 
2.11.0

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


[PATCHv2 09/10] drm: omapdrm: crtc: get manual mode displays working

2017-03-05 Thread Sebastian Reichel
From: Tony Lindgren 

With manual mode displays we need to flush the panel manually.

Let's add flushing so we get Tomi's fbtest, kmstest, kmstest --flip,
and X and wayland working.

Signed-off-by: Tony Lindgren 
[On Nokia N950]
Tested-By: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 4601533215d6..e07b0a0be4bf 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -97,6 +97,11 @@ bool omap_crtc_is_manual_updated(struct drm_crtc *crtc)
return omap_crtc->manually_updated;
 }
 
+static void omap_crtc_manual_needs_flush(struct drm_crtc *crtc)
+{
+   omap_crtc_flush(crtc, 0, 0, 0, 0);
+}
+
 /* 
-
  * DSS Manager Functions
  */
@@ -139,7 +144,11 @@ static void omap_crtc_dss_disconnect(enum omap_channel 
channel,
 
 static void omap_crtc_dss_start_update(enum omap_channel channel)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct drm_crtc *crtc = &omap_crtc->base;
+
dispc_mgr_enable(channel, true);
+   omap_crtc_manual_needs_flush(crtc);
 }
 
 /* Called only from the encoder enable/disable and suspend/resume handlers. */
@@ -155,11 +164,12 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
if (WARN_ON(omap_crtc->enabled == enable))
return;
 
-   if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
-   dispc_mgr_enable(channel, enable);
-   omap_crtc->enabled = enable;
+   dispc_mgr_enable(channel, enable);
+   omap_crtc->enabled = enable;
+   omap_crtc_manual_needs_flush(crtc);
+
+   if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI)
return;
-   }
 
if (omap_crtc->channel == OMAP_DSS_CHANNEL_DIGIT) {
/*
@@ -190,9 +200,6 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
wait = omap_irq_wait_init(dev, vsync_irq, 2);
}
 
-   dispc_mgr_enable(channel, enable);
-   omap_crtc->enabled = enable;
-
ret = omap_irq_wait(dev, wait, msecs_to_jiffies(100));
if (ret) {
dev_err(dev->dev, "%s: timeout waiting for %s\n",
@@ -554,6 +561,7 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
ret = drm_crtc_vblank_get(crtc);
WARN_ON(ret != 0);
}
+   omap_crtc_flush(&omap_crtc->base, 0, 0, 0, 0);
 
spin_lock_irq(&crtc->dev->event_lock);
dispc_mgr_enable(omap_crtc->channel, true);
-- 
2.11.0

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


Re: [RFC PATCH 1/3] v4l: vsp1: Register pipe with output WPF

2017-03-05 Thread Kieran Bingham
Hi Laurent,

Thanks for the review,

On 03/03/17 01:57, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Wednesday 01 Mar 2017 13:12:54 Kieran Bingham wrote:
>> The DRM object does not register the pipe with the WPF object. This is
>> used internally throughout the driver as a means of accessing the pipe.
>> As such this breaks operations which require access to the pipe from WPF
>> interrupts.
>>
>> Register the pipe inside the WPF object after it has been declared as
>> the output.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_drm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
>> b/drivers/media/platform/vsp1/vsp1_drm.c index cd209dccff1b..8e2aa3f8e52f
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_drm.c
>> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
>> @@ -596,6 +596,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
>>  pipe->bru = &vsp1->bru->entity;
>>  pipe->lif = &vsp1->lif->entity;
>>  pipe->output = vsp1->wpf[0];
>> +pipe->output->pipe = pipe;
> 
> The vsp1_irq_handler() function calls vsp1_pipeline_frame_end() with wpf-
>> pipe, which is currently NULL. With this patch the function will get a non-
> NULL pipeline and will thus proceed to calling vsp1_dlm_irq_frame_end():
> 
> void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
> {
>   if (pipe == NULL)
>   return;
> 
>   vsp1_dlm_irq_frame_end(pipe->output->dlm);
> 
>   if (pipe->frame_end)
>   pipe->frame_end(pipe);
> 
>   pipe->sequence++;
> }
> 
> pipe->frame_end is NULL, pipe->sequence doesn't matter, but we now end up 
> calling vsp1_dlm_irq_frame_end(). This is a major change regarding display 
> list processing, yet it seems to have no effect at all.

I was a bit surprised at this bit. I had expected vsp1_dlm_irq_frame_end() to be
more critical, but ultimately - it's only job is to handle a race condition on
DL commits which we (presumably) don't hit. At least we don't hit in our testing
more than $(DL_QTY) times, or I believe the display would have hung.

In fact we would have panic'd on a NULL dereference with pipe->dl:
pipe->dl = vsp1_dl_list_get(pipe->output->dlm);

where I don't see any checks on pipe->dl != NULL in the current code paths.

> The following commit is to blame for skipping the call to 
> vsp1_dlm_irq_frame_end().
> 
> commit ff7e97c94d9f7f370fe3ce2a72e85361ca22a605
> Author: Laurent Pinchart 
> Date:   Tue Jan 19 19:16:36 2016 -0200
> 
> [media] v4l: vsp1: Store pipeline pointer in rwpf
> 
> I've added a few debug print statements to vsp1_dlm_irq_frame_end(), and it 
> looks like we only hit the if (dlm->queued) test or none of them at all. It 
> looks like we've been lucky that nothing broke.
> 
> Restoring the previous behaviour should be safe, but it would be worth it 
> inspecting the code very carefully to make sure the logic is still correct. 
> I'll do it tomorrow if you don't beat me to it.

As far as I can tell it still seems correct. If we had ever hit this race, I
believe we would have leaked the DL, (which is quite a limited resource to us),
which if anything just raises the importance of this fix.

> 
> In any case, how about adding a
> 
> Fixes: ff7e97c94d9f ("[media] v4l: vsp1: Store pipeline pointer in rwpf")

Absolutely.

This seems worthy of a stable backport...? (though not critical)

The breakage was introduced in 4.6...

Should I add a CC: sta...@kernel.org #4.6+

> line ?
> 
>>  return 0;
>>  }
> 

-- 
Regards

Kieran Bingham
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/3] v4l: vsp1: Postpone page flip in event of display list race

2017-03-05 Thread Kieran Bingham
If we try to commit the display list while an update is pending, we have
missed our opportunity. The display list manager will hold the commit
until the next interrupt.

In this event, we inform the vsp1 completion callback handler so that
the du will not perform a page flip out of turn.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c   |  9 +++--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c  |  4 +++-
 drivers/media/platform/vsp1/vsp1_pipe.c |  6 +-
 drivers/media/platform/vsp1/vsp1_pipe.h |  2 ++
 5 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index ad545aff4e35..f8e8c90f22bc 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -557,9 +557,10 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager 
*dlm)
spin_unlock(&dlm->lock);
 }
 
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
struct vsp1_device *vsp1 = dlm->vsp1;
+   int ret = 0;
 
spin_lock(&dlm->lock);
 
@@ -578,8 +579,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 * before interrupt processing. The hardware hasn't taken the update
 * into account yet, we'll thus skip one frame and retry.
 */
-   if (vsp1_read(vsp1, VI6_DL_BODY_SIZE) & VI6_DL_BODY_SIZE_UPD)
+   if (vsp1_read(vsp1, VI6_DL_BODY_SIZE) & VI6_DL_BODY_SIZE_UPD) {
+   ret = -EBUSY;
goto done;
+   }
 
/* The device starts processing the queued display list right after the
 * frame end interrupt. The display list thus becomes active.
@@ -606,6 +609,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 
 done:
spin_unlock(&dlm->lock);
+
+   return ret;
 }
 
 /* Hardware Setup */
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index 7131aa3c5978..c772a1d92513 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
+int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
 
 struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
 void vsp1_dl_list_put(struct vsp1_dl_list *dl);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 85e5ebca82a5..6f2dd42ca01b 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -40,10 +40,12 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe)
 {
struct vsp1_drm *drm = to_vsp1_drm(pipe);
 
-   if (drm->du_complete && drm->du_pending) {
+   if (drm->du_complete && drm->du_pending && !pipe->dl_postponed) {
drm->du_complete(drm->du_private);
drm->du_pending = false;
}
+
+   pipe->dl_postponed = false;
 }
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 280ba0804699..3c5aae8767dd 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -297,10 +297,14 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
 
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
+   int ret;
+
if (pipe == NULL)
return;
 
-   vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   ret = vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   if (ret)
+   pipe->dl_postponed = true;
 
if (pipe->frame_end)
pipe->frame_end(pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index ac4ad261..65cc8fb76662 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -77,6 +77,7 @@ enum vsp1_pipeline_state {
  * @uds_input: entity at the input of the UDS, if the UDS is present
  * @entities: list of entities in the pipeline
  * @dl: display list associated with the pipeline
+ * @dl_postponed: identifies if the dl commit was caught by a race condition
  * @div_size: The maximum allowed partition size for the pipeline
  * @partitions: The number of partitions used to process one frame
  * @current_partition: The partition number currently being configured
@@ -107,6 +108,7 @@ struct vsp1_pipeline {
struct list_head entities;
 
struct vsp1_dl_list *dl;
+   bool dl_postponed;
 
unsigned int div_size;
unsigned int partitions;
-- 

[PATCH V3 1/4] dt-bindings: display: megachips-stdpxxxx-ge-b850v3-fw

2017-03-05 Thread Peter Senna Tschudin
Devicetree binding documentation for the second video output
of the GE B850v3:
   STDP4028-ge-b850v3-fw bridges (LVDS-DP)
   STDP2690-ge-b850v3-fw bridges (DP-DP++)

Added entry for MegaChips at:
 Documentation/devicetree/bindings/vendor-prefixes.txt

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Javier Martinez Canillas 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Acked-by: Rob Herring 
Signed-off-by: Peter Senna Tschudin 
---
Changes from V3:
 Added Acked-by: Rob Herring 

Changes from V1:
 - New subject
 - Moved binding documentation from bindings/video/ to bindings/display/bridge/
 - Reworded to describe hardware instead of the driver
 - Reformated the bindings to have one set of required properties per device
 - Updated reg description
 - Defined number of ports and what they are for

 .../bridge/megachips-stdp-ge-b850v3-fw.txt | 94 ++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 2 files changed, 95 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt
 
b/Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt
new file mode 100644
index 000..7baa658
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt
@@ -0,0 +1,94 @@
+Drivers for the second video output of the GE B850v3:
+   STDP4028-ge-b850v3-fw bridges (LVDS-DP)
+   STDP2690-ge-b850v3-fw bridges (DP-DP++)
+
+The video processing pipeline on the second output on the GE B850v3:
+
+   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
+
+Each bridge has a dedicated flash containing firmware for supporting the custom
+design. The result is that, in this design, neither the STDP4028 nor the
+STDP2690 behave as the stock bridges would. The compatible strings include the
+suffix "-ge-b850v3-fw" to make it clear that the driver is for the bridges with
+the firmware specific for the GE B850v3.
+
+The hardware do not provide control over the video processing pipeline, as the
+two bridges behaves as a single one. The only interfaces exposed by the
+hardware are EDID, HPD, and interrupts.
+
+stdp4028-ge-b850v3-fw required properties:
+  - compatible : "megachips,stdp4028-ge-b850v3-fw"
+  - reg : I2C bus address
+  - interrupt-parent : phandle of the interrupt controller that services
+interrupts to the device
+  - interrupts : one interrupt should be described here, as in
+<0 IRQ_TYPE_LEVEL_HIGH>
+  - ports : One input port(reg = <0>) and one output port(reg = <1>)
+
+stdp2690-ge-b850v3-fw required properties:
+compatible : "megachips,stdp2690-ge-b850v3-fw"
+  - reg : I2C bus address
+  - ports : One input port(reg = <0>) and one output port(reg = <1>)
+
+Example:
+
+&mux2_i2c2 {
+   status = "okay";
+   clock-frequency = <10>;
+
+   stdp4028@73 {
+   compatible = "megachips,stdp4028-ge-b850v3-fw";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0x73>;
+
+   interrupt-parent = <&gpio2>;
+   interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   stdp4028_in: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   stdp4028_out: endpoint {
+   remote-endpoint = <&stdp2690_in>;
+   };
+   };
+   };
+   };
+
+   stdp2690@72 {
+   compatible = "megachips,stdp2690-ge-b850v3-fw";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0x72>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   stdp2690_in: endpoint {
+   remote-endpoint = <&stdp4028_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   stdp2690_out: endpoint {
+   /* Connector for external display */
+   };
+   };
+   };
+   };
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-pref

[PATCH v3 1/3] v4l: vsp1: Postpone frame end handling in event of display list race

2017-03-05 Thread Kieran Bingham
If we try to commit the display list while an update is pending, we have
missed our opportunity. The display list manager will hold the commit
until the next interrupt.

In this event, we skip the pipeline completion callback handler so that
the pipeline will not mistakenly report frame completion to the user.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c   | 19 +--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index b9e5027778ff..f449ca689554 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -562,9 +562,19 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager 
*dlm)
spin_unlock(&dlm->lock);
 }
 
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+/**
+ * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
+ * @dlm: the display list manager
+ *
+ * Return true if the previous display list has completed at frame end, or 
false
+ * if it has been delayed by one frame because the display list commit raced
+ * with the frame end interrupt. The function always returns true in header 
mode
+ * as display list processing is then not continuous and races never occur.
+ */
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
struct vsp1_device *vsp1 = dlm->vsp1;
+   bool completed = false;
 
spin_lock(&dlm->lock);
 
@@ -576,8 +586,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 * perform any operation as there can't be any new display list queued
 * in that case.
 */
-   if (dlm->mode == VSP1_DL_MODE_HEADER)
+   if (dlm->mode == VSP1_DL_MODE_HEADER) {
+   completed = true;
goto done;
+   }
 
/*
 * The UPD bit set indicates that the commit operation raced with the
@@ -597,6 +609,7 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
if (dlm->queued) {
dlm->active = dlm->queued;
dlm->queued = NULL;
+   completed = true;
}
 
/*
@@ -619,6 +632,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 
 done:
spin_unlock(&dlm->lock);
+
+   return completed;
 }
 
 /* Hardware Setup */
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index 7131aa3c5978..6ec1380a10af 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
 
 struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
 void vsp1_dl_list_put(struct vsp1_dl_list *dl);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 35364f594e19..d15327701ad8 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -304,10 +304,21 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
 
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
+   bool completed;
+
if (pipe == NULL)
return;
 
-   vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   completed = vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   if (!completed) {
+   /*
+* If the DL commit raced with the frame end interrupt, the
+* commit ends up being postponed by one frame. Return
+* immediately without calling the pipeline's frame end handler
+* or incrementing the sequence number.
+*/
+   return;
+   }
 
if (pipe->frame_end)
pipe->frame_end(pipe);
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCHv2 04/10] drm: omapdrm: crtc: save framedone callback from dss

2017-03-05 Thread Sebastian Reichel
Save the framedone callback supplied by dss for later
usage.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index b68c70eb395f..76a411fe957a 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -42,6 +42,9 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+
+   void (*framedone_handler)(void *);
+   void *framedone_handler_data;
 };
 
 /* 
-
@@ -241,6 +244,17 @@ static int omap_crtc_dss_register_framedone(
enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   if (omap_crtc->framedone_handler)
+   return -EBUSY;
+
+   dev_dbg(dev->dev, "register framedone %s", omap_crtc->name);
+
+   omap_crtc->framedone_handler = handler;
+   omap_crtc->framedone_handler_data = data;
+
return 0;
 }
 
@@ -248,6 +262,16 @@ static void omap_crtc_dss_unregister_framedone(
enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   dev_dbg(dev->dev, "unregister framedone %s", omap_crtc->name);
+
+   WARN_ON(omap_crtc->framedone_handler != handler);
+   WARN_ON(omap_crtc->framedone_handler_data != data);
+
+   omap_crtc->framedone_handler = NULL;
+   omap_crtc->framedone_handler_data = NULL;
 }
 
 static const struct dss_mgr_ops mgr_ops = {
-- 
2.11.0

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


[PATCH v3 3/3] drm: rcar-du: Register a completion callback with VSP1

2017-03-05 Thread Kieran Bingham
Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  9 +
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 2aceb84fc15d..c1812e20 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -299,7 +299,7 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
  * Page Flip
  */
 
-static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
 {
struct drm_pending_vblank_event *event;
struct drm_device *dev = rcrtc->crtc.dev;
@@ -571,6 +571,7 @@ static const struct drm_crtc_funcs crtc_funcs = {
 static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 {
struct rcar_du_crtc *rcrtc = arg;
+   struct rcar_du_device *rcdu = rcrtc->group->dev;
irqreturn_t ret = IRQ_NONE;
u32 status;
 
@@ -579,7 +580,10 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 
if (status & DSSR_FRM) {
drm_crtc_handle_vblank(&rcrtc->crtc);
-   rcar_du_crtc_finish_page_flip(rcrtc);
+
+   if (rcdu->info->gen < 3)
+   rcar_du_crtc_finish_page_flip(rcrtc);
+
ret = IRQ_HANDLED;
}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index a7194812997e..ebdbff9d8e59 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -71,5 +71,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
 
 void rcar_du_crtc_route_output(struct drm_crtc *crtc,
   enum rcar_du_output output);
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
 
 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..cbb6f54c99ef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,13 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
+
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = &crtc->crtc.state->adjusted_mode;
@@ -35,6 +42,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
struct vsp1_du_lif_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
+   .callback = rcar_du_vsp_complete,
+   .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCHv2 01/10] drm: omapdrm: panel-dsi-cm: Fix probe for device tree

2017-03-05 Thread Sebastian Reichel
From: Tony Lindgren 

Things are a bit whacked right now for panel-dsi-cm:

1. We're missing call to of_get_display_timing() and
   videomode_from_timing()

2. We need to call dsicm_probe_of() after we initialize the
   default values to not overwrite device tree configured
   values

3. We need to implement minimal get_timings() and check_timings()
   for the panel to work

With these changes we get panel-dsi-cm to probe with device tree
configuraion. Note that the dsicm_check_timings adapted from an
earlier patch by Sebastian Reichel .

Signed-off-by: Tony Lindgren 
Tested-By: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 65 -
 1 file changed, 52 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index ac5800c72cb4..ad1058fafe92 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -25,6 +25,7 @@
 #include 
 
 #include 
+#include 
 
 #include "../dss/omapdss.h"
 
@@ -379,13 +380,6 @@ static const struct backlight_ops dsicm_bl_ops = {
.update_status  = dsicm_bl_update_status,
 };
 
-static void dsicm_get_resolution(struct omap_dss_device *dssdev,
-   u16 *xres, u16 *yres)
-{
-   *xres = dssdev->panel.vm.hactive;
-   *yres = dssdev->panel.vm.vactive;
-}
-
 static ssize_t dsicm_num_errors_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
@@ -1106,6 +1100,36 @@ static void dsicm_ulps_work(struct work_struct *work)
mutex_unlock(&ddata->lock);
 }
 
+static void dsicm_get_timings(struct omap_dss_device *dssdev,
+ struct videomode *vm)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+   *vm = ddata->vm;
+}
+
+static int dsicm_check_timings(struct omap_dss_device *dssdev,
+  struct videomode *vm)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+   int ret = 0;
+
+   if (vm->hactive != ddata->vm.hactive)
+   ret = -EINVAL;
+
+   if (vm->vactive != ddata->vm.vactive)
+   ret = -EINVAL;
+
+   if (ret) {
+   dev_warn(dssdev->dev, "wrong resolution: %d x %d",
+vm->hactive, vm->vactive);
+   dev_warn(dssdev->dev, "panel resolution: %d x %d",
+ddata->vm.hactive, ddata->vm.vactive);
+   }
+
+   return ret;
+}
+
 static struct omap_dss_driver dsicm_ops = {
.connect= dsicm_connect,
.disconnect = dsicm_disconnect,
@@ -1116,7 +1140,10 @@ static struct omap_dss_driver dsicm_ops = {
.update = dsicm_update,
.sync   = dsicm_sync,
 
-   .get_resolution = dsicm_get_resolution,
+   .get_timings= dsicm_get_timings,
+   .check_timings  = dsicm_check_timings,
+
+   .get_resolution = omapdss_default_get_resolution,
.get_recommended_bpp = omapdss_default_get_recommended_bpp,
 
.enable_te  = dsicm_enable_te,
@@ -1130,7 +1157,8 @@ static int dsicm_probe_of(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *in;
-   int gpio;
+   struct display_timing timing;
+   int gpio, err;
 
gpio = of_get_named_gpio(node, "reset-gpios", 0);
if (!gpio_is_valid(gpio)) {
@@ -1147,6 +1175,17 @@ static int dsicm_probe_of(struct platform_device *pdev)
return gpio;
}
 
+   err = of_get_display_timing(node, "panel-timing", &timing);
+   if (!err) {
+   videomode_from_timing(&timing, &ddata->vm);
+   if (!ddata->vm.pixelclock)
+   ddata->vm.pixelclock =
+   ddata->vm.hactive * ddata->vm.vactive * 60;
+   } else {
+   dev_warn(&pdev->dev,
+"failed to get video timing, using defaults\n");
+   }
+
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(&pdev->dev, "failed to find video source\n");
@@ -1181,14 +1220,14 @@ static int dsicm_probe(struct platform_device *pdev)
if (!pdev->dev.of_node)
return -ENODEV;
 
-   r = dsicm_probe_of(pdev);
-   if (r)
-   return r;
-
ddata->vm.hactive = 864;
ddata->vm.vactive = 480;
ddata->vm.pixelclock = 864 * 480 * 60;
 
+   r = dsicm_probe_of(pdev);
+   if (r)
+   return r;
+
dssdev = &ddata->dssdev;
dssdev->dev = dev;
dssdev->driver = &dsicm_ops;
-- 
2.11.0

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


Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data

2017-03-05 Thread Jose Abreu
Hi Neil,


On 03-03-2017 11:31, Neil Armstrong wrote:
>
> Sure, but I was struggling about finding an equivalence.
>
> How should I replace these ?
>
> DW_HDMI_ENC_FMT_RGB
> DW_HDMI_ENC_FMT_YCBCR444
> DW_HDMI_ENC_FMT_YCBCR422_16BITS
> DW_HDMI_ENC_FMT_YCBCR422_8BITS
> DW_HDMI_ENC_FMT_XVYCC444
>
> I do not have the strict information about the bus format, what is RGB in 
> 8bit per pixel ?
> Are the 3 samples transmitted separately ?
> What should be the RGB colorspace ?
> Should we use the "Packed" formats, LVDS or a new buf format ?
>
> Jose, what are the *exact* bus formats supported ?

Well, the controller supports everything that is in the HDMI spec
(1.4 and 2.0), the implementation is the one that limits the
supported formats. There is also a CSC but it does not convert
from anything to everything :)

I think you can safely add every MBUS code that is compatible
with HDMI. Namely:
-24/30/36/48-bit RGB 4:4:4
-24/30/36/48-bit YCbCr 4:4:4
-16/20/24-bit YCbCr 4:2:2
-24/30/36/48-bit YCbCr 4:2:0

And then let the glue drivers decide which they support in input
and what they want in output (the output is a little tricky
because it will depend in EDID, this should be handled by
userspace + drm core and not the drivers so let it fixed to RGB,
just in case).

>
> Same for DW_HDMI_ENC_FMT_YCBCR* stuff, are they packed ?

Hmm, this depends on the implementation. The controller always
receives 48bits of data per pixel, its the implementation that is
responsible to correctly align that data.

>
> I understand the YCBCR444/XVYCC444 needs a color space information instead.
>
> Could we use the following list ?
>
> Bus Format| Colorspace| Encoding
> ---
> MEDIA_BUS_FMT_RGB888_1X24 | V4L2_COLORSPACE_SRGB  | V4L2_XFER_FUNC_SRGB
> MEDIA_BUS_FMT_RGB101010_1X30  | V4L2_COLORSPACE_SRGB  | V4L2_XFER_FUNC_SRGB
> MEDIA_BUS_FMT_RGB121212_1X36  | V4L2_COLORSPACE_SRGB  | V4L2_XFER_FUNC_SRGB
> MEDIA_BUS_FMT_VUY8_1X24   | V4L2_XFER_FUNC_709| 
> V4L2_YCBCR_ENC_709
> MEDIA_BUS_FMT_YUV10_1X30  | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_709
> MEDIA_BUS_FMT_YUV10_1X32  | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_709
> MEDIA_BUS_FMT_YUV10_1X32  | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_709
> MEDIA_BUS_FMT_YUV10_1X32  | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_XV709

I think the HDMI spec dictates the default colorspace+encoding
for each bus format, not sure though, Laurent?

Best regards,
Jose Miguel Abreu

>
> But all of these is complex, and I'm not sure how we should handle SDTV modes 
> here,
> and without knowing the exact inputs types supported by the IP, this needs to 
> be
> confirmed.
>
> Meanwhile, all this can be fixed later, at least this patch moves the
> definition out of the C file and uses better names for these custom enums.
>

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


[PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats

2017-03-05 Thread Randy Li
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format.

Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
The V4L2_PIX_FMT_P010CM is a compat variant of the V4L2_PIX_FMT_P010,
which uses the unused 6 bits to store the next pixel. And with
the alignment requirement of the hardware, it usually would be
some extra space left at the end of a stride.

Signed-off-by: Randy Li 
---
 Documentation/media/uapi/v4l/pixfmt-p010.rst  | 126 
 Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135 ++
 Documentation/media/uapi/v4l/pixfmt-p016.rst  | 125 
 Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
 Documentation/media/uapi/v4l/yuv-formats.rst  |   4 +
 include/uapi/linux/videodev2.h|   5 +
 6 files changed, 529 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst 
b/Documentation/media/uapi/v4l/pixfmt-p010.rst
new file mode 100644
index 000..59ed118
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
@@ -0,0 +1,126 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010:
+
+**
+V4L2_PIX_FMT_P010 ('P010')
+**
+
+
+V4L2_PIX_FMT_P010
+Formats with ½ horizontal and vertical chroma resolution. One luminance and
+one chrominance plane with alternating
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
+
+
+Description
+===
+
+It is a two-plane versions of the YUV 4:2:0 format. The three
+components are separated into two sub-images or planes. The Y plane is
+first. The Y plane has 16 bits per pixel, but only 10 bits are used with the
+rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane
+immediately follows the Y plane in memory. The CbCr
+plane is the same width, in bytes, as the Y plane (and of the image),
+but is half as tall in pixels. Each CbCr pair belongs to four pixels.
+For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
+Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
+If the Y plane has pad bytes after each row, then the CbCr plane has as
+many pad bytes after its rows.
+
+**Byte Order.**
+Each cell is two bytes.
+
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - start + 0:
+  - Y'\ :sub:`00`
+  - Y'\ :sub:`01`
+  - Y'\ :sub:`02`
+  - Y'\ :sub:`03`
+* - start + 4:
+  - Y'\ :sub:`10`
+  - Y'\ :sub:`11`
+  - Y'\ :sub:`12`
+  - Y'\ :sub:`13`
+* - start + 8:
+  - Y'\ :sub:`20`
+  - Y'\ :sub:`21`
+  - Y'\ :sub:`22`
+  - Y'\ :sub:`23`
+* - start + 12:
+  - Y'\ :sub:`30`
+  - Y'\ :sub:`31`
+  - Y'\ :sub:`32`
+  - Y'\ :sub:`33`
+* - start + 16:
+  - Cb\ :sub:`00`
+  - Cr\ :sub:`00`
+  - Cb\ :sub:`01`
+  - Cr\ :sub:`01`
+* - start + 20:
+  - Cb\ :sub:`10`
+  - Cr\ :sub:`10`
+  - Cb\ :sub:`11`
+  - Cr\ :sub:`11`
+
+
+**Color Sample Location..**
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* -
+  - 0
+  -
+  - 1
+  - 2
+  -
+  - 3
+* - 0
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 1
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+* - 2
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 3
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst 
b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
new file mode 100644
index 000..6697d15
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-p010m.rst
@@ -0,0 +1,135 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-P010M:
+
+***
+V4L2_PIX_FMT_P010M ('PM10')
+***
+
+
+V4L2_PIX_FMT_P010M
+Variation of ``V4L2_PIX_FMT_P010`` with planes non contiguous in memory.
+
+
+Description
+===
+
+This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
+three components are separated into two sub-images or planes.
+``V4L2_PIX_FMT_P010M`` differs from ``V4L2_PIX_FMT_P010`` in that the
+two planes are non-contiguous in memory, i.e. the chroma plane do not
+necessarily immediately follows the luma plane. The luminance data
+occupies the first plane.

[PATCH] dt-bindings: drm: rcar-du: Document optional reset properties

2017-03-05 Thread Geert Uytterhoeven
Document the optional properties for describing module resets, to
support resetting display channels and LVDS encoders on R-Car Gen2 and
Gen3.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/display/renesas,du.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index 1a02f099a0ff0a3a..7873d53764a297c2 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -36,6 +36,16 @@ Required Properties:
   When supplied they must be named "dclkin.x" with "x" being the input
   clock numerical index.
 
+Optional properties:
+  - resets: A list of phandles + reset-specifier pairs, one for each entry in
+the reset-names property.
+  - reset-names: Names of the resets. This property is model-dependent.
+- R8A779[0123456] use one reset for a group of one or more successive
+  channels, and one reset per LVDS encoder (if available). The resets
+  must be named "du.x" with "x" being the numerical index of the lowest
+  channel in the group. The LVDS resets must be named "lvds.x" with "x"
+  being the LVDS encoder numerical index.
+
 Required nodes:
 
 The connections to the DU output video ports are modeled using the OF graph
-- 
2.7.4

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


[PATCH v6 3/3] drm/rockchip: Support 10 bits yuv format in vop

2017-03-05 Thread Randy Li
The rockchip use a special pixel format for those yuv pixel
format with 10 bits color depth.

Signed-off-by: Randy Li 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  2 ++
 include/uapi/drm/drm_fourcc.h   | 11 ++
 5 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index c9ccdf8..250fd29 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -230,6 +230,7 @@ void rockchip_drm_mode_config_init(struct drm_device *dev)
 */
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
+   dev->mode_config.allow_fb_modifiers = true;
 
dev->mode_config.funcs = &rockchip_drm_mode_config_funcs;
dev->mode_config.helper_private = &rockchip_mode_config_helpers;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..45da270 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -232,6 +232,7 @@ static enum vop_data_format vop_convert_format(uint32_t 
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_P010:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
return VOP_FMT_YUV422SP;
@@ -249,12 +250,28 @@ static bool is_yuv_support(uint32_t format)
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
+   case DRM_FORMAT_P010:
return true;
default:
return false;
}
 }
 
+static bool is_support_fb(struct drm_framebuffer *fb)
+{
+   switch (fb->format->format) {
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV24:
+   return true;
+   case DRM_FORMAT_P010:
+   if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+   return true;
+   default:
+   return false;
+   }
+
+}
 static bool is_alpha_support(uint32_t format)
 {
switch (format) {
@@ -680,7 +697,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
 * Src.x1 can be odd when do clip, but yuv plane start point
 * need align with 2 pixel.
 */
-   if (is_yuv_support(fb->format->format) && ((state->src.x1 >> 16) % 2))
+   if (is_support_fb(fb) && ((state->src.x1 >> 16) % 2))
return -EINVAL;
 
return 0;
@@ -723,6 +740,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
dma_addr_t dma_addr;
uint32_t val;
bool rb_swap;
+   bool is_10_bits = false;
int format;
 
/*
@@ -739,6 +757,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
return;
}
 
+   if (fb->modifier == DRM_FORMAT_MOD_ROCKCHIP_10BITS)
+   is_10_bits = true;
+
obj = rockchip_fb_get_gem_obj(fb, 0);
rk_obj = to_rockchip_obj(obj);
 
@@ -753,7 +774,10 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
 
-   offset = (src->x1 >> 16) * fb->format->cpp[0];
+   if (is_10_bits)
+   offset = (src->x1 >> 16) * 10 / 8;
+   else
+   offset = (src->x1 >> 16) * fb->format->cpp[0];
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
 
@@ -764,6 +788,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
VOP_WIN_SET(vop, win, format, format);
VOP_WIN_SET(vop, win, yrgb_vir, fb->pitches[0] >> 2);
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
+   VOP_WIN_SET(vop, win, fmt_10, is_10_bits);
if (is_yuv_support(fb->format->format)) {
int hsub = 
drm_format_horz_chroma_subsampling(fb->format->format);
int vsub = 
drm_format_vert_chroma_subsampling(fb->format->format);
@@ -772,7 +797,10 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
uv_obj = rockchip_fb_get_gem_obj(fb, 1);
rk_uv_obj = to_rockchip_obj(uv_obj);
 
-   offset = (src->x1 >> 16) * bpp / hsub;
+   if (is_10_bits)
+   offset = (src->x1 >> 16) * 10 / 8 / hsub;
+   else
+   offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
 
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/g

Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data

2017-03-05 Thread Jose Abreu
Hi Neil,


On 03-03-2017 16:42, Neil Armstrong wrote:
>
> Sure, I was meaning the *input* format the controller receives from the
> pixel encoder, I'm quite sure the format is strict.
>

Hmm, not quite following you here. As far as the controller goes
it supports the formats I mentioned:
-8/10/12/16 bits RGB 4:4:4
-8/10/12/16 bits YCbCr 4:4:4
-8/10/12 bits YCbCr 4:2:2
-8/10/12/16 bits YCbCr 4:2:0

As for the CSC it supports RGB 4:4:4 to/from YCbCr 4:4:4 or 4:2:2
in every defined color depth.

So, everything except 4:2:0 (I had to check documentation, I
though that CSC supported less formats).

Of course this is all limited by the implementation that HW team
decides to choose.

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

2017-03-05 Thread Randy Li
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format.

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
per channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.

Cc: Daniel Stone 
Cc: Ville Syrjälä 

Signed-off-by: Randy Li 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_fourcc.c  |  3 +++
 include/uapi/drm/drm_fourcc.h | 21 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
 
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@ extern "C" {
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
 
 /*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
-- 
2.7.4

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


Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

2017-03-05 Thread Alexey Brodkin
Hi Jose,

On Fri, 2017-03-03 at 18:05 +, Jose Abreu wrote:
> Hi Alexey,
> 
> 
> On 03-03-2017 13:27, Alexey Brodkin wrote:
> > 
> > 
> > So if I understood you correct here what I really need is just to get rid 
> > of existing check,
> > right? I.e. the following is to be in v2 respin:
> > --->8---
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index ad9a95916f1f..86f1555914e8 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -129,20 +129,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
> >   ~ARCPGU_CTRL_ENABLE_MASK);
> >  }
> >  
> > -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> > -struct drm_crtc_state *state)
> > -{
> > -   struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> > -   struct drm_display_mode *mode = &state->adjusted_mode;
> > -   long rate, clk_rate = mode->clock * 1000;
> > -
> > -   rate = clk_round_rate(arcpgu->clk, clk_rate);
> > -   if (rate != clk_rate)
> > -   return -EINVAL;
> > -
> > -   return 0;
> > -}
> > -
> >  static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
> >   struct drm_crtc_state *state)
> >  {
> > @@ -165,7 +151,6 @@ static const struct drm_crtc_helper_funcs 
> > arc_pgu_crtc_helper_funcs = {
> > .disable= arc_pgu_crtc_disable,
> > .prepare= arc_pgu_crtc_disable,
> > .commit = arc_pgu_crtc_enable,
> > -   .atomic_check   = arc_pgu_crtc_atomic_check,
> > .atomic_begin   = arc_pgu_crtc_atomic_begin,
> >  };
> > --->8---
> 
> I don't think you can remove the check entirely as this will make
> any mode be accepted, right?

Correct. Otherwise we'll get some modes and devices that
don't work.

Remember our saga with 74.25 vs 74.40 MHz?

With our PLLs on AXS and HSDK boards we may generate 74.25 MHz clock
which satisfy some monitors especially those who pass correct EDID to the host.
But what if EDID is either corrupted or doesn't exist (that's my case with
some industrial monitor as well as with old DVI monitor)?

In that case Linux kernel attempts to calculate all the values including pixel 
clock
but then instead of 74.25 we'll get 74.40 and equipment that used to work is no 
longer useful.

So strictly speaking existing check makes perfect sense. But it reduces
compatibility with not very good monitors.

Probably better solution to the problem is just to throw away [my] faulty HW and
buy equipment that conforms to standards (not really sure if EDID is a hard
requirement for DVI/HDMI displays or this is just an option).

BTW I'm wondering if there're any guidelines on what could be pixel clock
deviation from the requested one?

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


Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-05 Thread Michal Hocko
On Thu 02-03-17 13:44:32, Laura Abbott wrote:
> Hi,
> 
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
> moved out of staging.
> 
> This includes the following:
> - Some general clean up and removal of features that never got a lot of use
>   as far as I can tell.
> - Fixing up the caching. This is the series I proposed back in December[2]
>   but never heard any feedback on. It will certainly break existing
>   applications that rely on the implicit caching. I'd rather make an effort
>   to move to a model that isn't going directly against the establishement
>   though.
> - Fixing up the platform support. The devicetree approach was never well
>   recieved by DT maintainers. The proposal here is to think of Ion less as
>   specifying requirements and more of a framework for exposing memory to
>   userspace.
> - CMA allocations now happen without the need of a dummy device structure.
>   This fixes a bunch of the reasons why I attempted to add devicetree
>   support before.
> 
> I've had problems getting feedback in the past so if I don't hear any major
> objections I'm going to send out with the RFC dropped to be picked up.
> The only reason there isn't a patch to come out of staging is to discuss any
> other changes to the ABI people might want. Once this comes out of staging,
> I really don't want to mess with the ABI.

Could you recapitulate concerns preventing the code being merged
normally rather than through the staging tree and how they were
addressed?
-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: display: rk3288-mipi-dsi: add reset property

2017-03-05 Thread Brian Norris
On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote:
> This reset is required in order to fully reset the internal state of the
> MIPI controller.
> 
> Signed-off-by: John Keeping 
> ---
> On Thu, 2 Mar 2017 13:56:46 -0800, Brian Norris wrote:
> > On Fri, Feb 24, 2017 at 12:55:06PM +, John Keeping wrote:
> > > + /*
> > > +  * Note that the reset was not defined in the initial device tree, so
> > > +  * we have to be prepared for it not being found.
> > > +  */
> > > + apb_rst = devm_reset_control_get(dev, "apb");  
> > 
> > Did this reset ever get documented in the device tree bindings? I
> > couldn't find it. Perhaps a follow-up patch is in order?
> 
> Here's a patch to do that.

FWIW:

Reviewed-by: Brian Norris 

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


Re: [PATCH] drm: bridge: dw-hdmi: Move the driver to a separate directory.

2017-03-05 Thread Jose Abreu
Hi Laurent,


On 03-03-2017 16:50, Laurent Pinchart wrote:
> The driver is already made of 5 separate source files. Move it to a
> newly created directory named synopsys where more Synopsys bridge
> drivers can be added later (for the DisplayPort controller for
> instance).
>
> Suggested-by: Jose Abreu 
> Signed-off-by: Laurent Pinchart 

Thanks a lot!

There are typo errors (which were there before, I just noticed
them now), please see bellow.

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  drivers/gpu/drm/bridge/Kconfig |  2 ++
>  drivers/gpu/drm/bridge/Makefile|  4 +---
>  drivers/gpu/drm/bridge/synopsys/Kconfig| 23 
> ++
>  drivers/gpu/drm/bridge/synopsys/Makefile   |  5 +
>  .../drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c  |  0
>  .../gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h  |  0
>  .../drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c  |  0
>  drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c|  0
>  drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h|  0
>  9 files changed, 31 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/synopsys/Kconfig
>  create mode 100644 drivers/gpu/drm/bridge/synopsys/Makefile
>  rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-ahb-audio.c (100%)
>  rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-audio.h (100%)
>  rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi-i2s-audio.c (100%)
>  rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.c (100%)
>  rename drivers/gpu/drm/bridge/{ => synopsys}/dw-hdmi.h (100%)
>
> Hi Jose,
>
> Here's the patch you've requested, to be applied on top of the
> "[PATCH v4 0/9] drm: bridge: dw-hdmi: Refactor PHY support" series.
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index eb8688ec6f18..68ceba083ca1 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -101,4 +101,6 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
>  
>  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>  
> +source "drivers/gpu/drm/bridge/synopsys/Kconfig"
> +
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 2e83a7855399..103f82e63102 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,9 +2,6 @@ ccflags-y := -Iinclude/drm
>  
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> -obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> -obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> -obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> @@ -13,3 +10,4 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>  obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
> b/drivers/gpu/drm/bridge/synopsys/Kconfig
> new file mode 100644
> index ..4d260755f010
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
> @@ -0,0 +1,23 @@
> +config DRM_DW_HDMI
> + tristate
> + select DRM_KMS_HELPER
> +
> +config DRM_DW_HDMI_AHB_AUDIO
> + tristate "Synopsis Designware AHB Audio interface"

"Synopsis" -> "Synopsys"

> + depends on DRM_DW_HDMI && SND
> + select SND_PCM
> + select SND_PCM_ELD
> + select SND_PCM_IEC958
> + help
> +   Support the AHB Audio interface which is part of the Synopsis

"Synopsis" -> "Synopsys"
> +   Designware HDMI block.  This is used in conjunction with
> +   the i.MX6 HDMI driver.
> +
> +config DRM_DW_HDMI_I2S_AUDIO
> + tristate "Synopsis Designware I2S Audio interface"

"Synopsis" -> "Synopsys"

> + depends on SND_SOC
> + depends on DRM_DW_HDMI
> + select SND_SOC_HDMI_CODEC
> + help
> +   Support the I2S Audio interface which is part of the Synopsis

"Synopsis" -> "Synopsys"

> +   Designware HDMI block.
> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
> b/drivers/gpu/drm/bridge/synopsys/Makefile
> new file mode 100644
> index ..17aa7a65b57e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
> @@ -0,0 +1,5 @@
> +#ccflags-y := -Iinclude/drm
> +
> +obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> +obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> +obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> similarity index 100%
> rename from drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c
> rename to drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi-audio.h 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-a

[PATCH 2/2] drm/panel: simple: Add support for Winstar WF35LTIACD

2017-03-05 Thread Richard Genoud
This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
LCD panel, which can be supported by the simple panel driver.

Signed-off-by: Richard Genoud 
---
 .../bindings/display/panel/winstar,wf35ltiacd  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 28 ++
 2 files changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd

diff --git a/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd 
b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
new file mode 100644
index ..68408adf239f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
@@ -0,0 +1,7 @@
+Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
+
+Required properties:
+- compatible: should be "winstar,wf35ltiacd"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79de8c8..5d45664c6c0e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1713,6 +1713,31 @@ static const struct panel_desc urt_umsh_8596md_parallel 
= {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };
 
+static const struct drm_display_mode winstar_wf35ltiacd_mode = {
+   .clock = 6410,
+   .hdisplay = 320,
+   .hsync_start = 320 + 20,
+   .hsync_end = 320 + 20 + 30,
+   .htotal = 320 + 20 + 30 + 38,
+   .vdisplay = 240,
+   .vsync_start = 240 + 4,
+   .vsync_end = 240 + 4 + 3,
+   .vtotal = 240 + 4 + 3 + 15,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc winstar_wf35ltiacd = {
+   .modes = &winstar_wf35ltiacd_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 70,
+   .height = 53,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1892,6 +1917,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "urt,umsh-8596md-20t",
.data = &urt_umsh_8596md_parallel,
}, {
+   .compatible = "winstar,wf35ltiacd",
+   .data = &winstar_wf35ltiacd,
+   }, {
/* sentinel */
}
 };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] devicetree: add vendor prefix for Winstar Display Corp.

2017-03-05 Thread Richard Genoud
Winstar Display Corp. is specialized in LCD displays for embedded
products.
cf: http://www.winstar.com.tw

Signed-off-by: Richard Genoud 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e7f5d1..56df3afd625a 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -322,6 +322,7 @@ voipac  Voipac Technologies s.r.o.
 wd Western Digital Corp.
 wexler Wexler
 winbond Winbond Electronics corp.
+winstarWinstar Display Corp.
 wlfWolfson Microelectronics
 wm Wondermedia Technologies, Inc.
 x-powers   X-Powers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCHv2 04/10] drm: omapdrm: crtc: save framedone callback from dss

2017-03-05 Thread Tony Lindgren
* Sebastian Reichel  [170304 16:45]:
> Save the framedone callback supplied by dss for later
> usage.
> 
> Signed-off-by: Sebastian Reichel 

Tested-by: Tony Lindgren 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCHv2 02/10] drm: omapdrm: panel-dsi-cm: add regulator support

2017-03-05 Thread Tony Lindgren
* Sebastian Reichel  [170304 16:45]:
> The N950's display requires two regulators.

Also needed for droid 4:

Tested-by: Tony Lindgren 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/3] v4l: vsp1: extend VSP1 module API to allow DRM callbacks

2017-03-05 Thread Kieran Bingham
To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.

We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback to be registered within the VSP DRM interface.

Signed-off-by: Kieran Bingham 

---
v2:
 - vsp1_du_setup_lif() uses config structure to set callbacks
 - vsp1_du_pipeline_frame_end() moved to interrupt section
 - vsp1_du_pipeline_frame_end registered in vsp1_drm_init()
   meaning of any NULL values
 - removed unnecessary 'private data' variables

 drivers/media/platform/vsp1/vsp1_drm.c | 20 
 drivers/media/platform/vsp1/vsp1_drm.h | 10 ++
 include/media/vsp1.h   |  3 +++
 3 files changed, 33 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 7dce55043379..85e5ebca82a5 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -36,6 +36,16 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
 }
 
+static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm *drm = to_vsp1_drm(pipe);
+
+   if (drm->du_complete && drm->du_pending) {
+   drm->du_complete(drm->du_private);
+   drm->du_pending = false;
+   }
+}
+
 /* 
-
  * DU Driver API
  */
@@ -95,6 +105,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
}
 
pipe->num_inputs = 0;
+   vsp1->drm->du_complete = NULL;
 
vsp1_dlm_reset(pipe->output->dlm);
vsp1_device_put(vsp1);
@@ -196,6 +207,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
if (ret < 0)
return ret;
 
+   /*
+* Register a callback to allow us to notify the DRM framework of frame
+* completion events.
+*/
+   vsp1->drm->du_complete = cfg->callback;
+   vsp1->drm->du_private = cfg->callback_data;
+
ret = media_pipeline_start(&pipe->output->entity.subdev.entity,
  &pipe->pipe);
if (ret < 0) {
@@ -504,6 +522,7 @@ void vsp1_du_atomic_flush(struct device *dev)
 
vsp1_dl_list_commit(pipe->dl);
pipe->dl = NULL;
+   vsp1->drm->du_pending = true;
 
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
@@ -597,6 +616,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->lif = &vsp1->lif->entity;
pipe->output = vsp1->wpf[0];
pipe->output->pipe = pipe;
+   pipe->frame_end = vsp1_du_pipeline_frame_end;
 
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 9e28ab9254ba..3a53e9a60c73 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -33,8 +33,18 @@ struct vsp1_drm {
struct v4l2_rect compose;
unsigned int zpos;
} inputs[VSP1_MAX_RPF];
+
+   /* Frame syncronisation */
+   void (*du_complete)(void *);
+   void *du_private;
+   bool du_pending;
 };
 
+static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
+{
+   return container_of(pipe, struct vsp1_drm, pipe);
+}
+
 int vsp1_drm_init(struct vsp1_device *vsp1);
 void vsp1_drm_cleanup(struct vsp1_device *vsp1);
 int vsp1_drm_create_links(struct vsp1_device *vsp1);
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index bfc701f04f3f..f6629f19f209 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -23,6 +23,9 @@ int vsp1_du_init(struct device *dev);
 struct vsp1_du_lif_config {
unsigned int width;
unsigned int height;
+
+   void (*callback)(void *);
+   void *callback_data;
 };
 
 int vsp1_du_setup_lif(struct device *dev, const struct vsp1_du_lif_config 
*cfg);
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH V2 1/4] dt-bindings: display: megachips-stdpxxxx-ge-b850v3-fw

2017-03-05 Thread Rob Herring
On Tue, Feb 28, 2017 at 03:28:10PM +0100, Peter Senna Tschudin wrote:
> Devicetree binding documentation for the second video output
> of the GE B850v3:
>STDP4028-ge-b850v3-fw bridges (LVDS-DP)
>STDP2690-ge-b850v3-fw bridges (DP-DP++)
> 
> Added entry for MegaChips at:
>  Documentation/devicetree/bindings/vendor-prefixes.txt
> 
> Cc: Laurent Pinchart 
> Cc: Martyn Welch 
> Cc: Martin Donnelly 
> Cc: Javier Martinez Canillas 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Changes from V1:
>  - New subject
>  - Moved binding documentation from bindings/video/ to 
> bindings/display/bridge/
>  - Reworded to describe hardware instead of the driver
>  - Reformated the bindings to have one set of required properties per device
>  - Updated reg description
>  - Defined number of ports and what they are for
> 
>  .../bridge/megachips-stdp-ge-b850v3-fw.txt | 94 
> ++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  2 files changed, 95 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/megachips-stdp-ge-b850v3-fw.txt

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table

2017-03-05 Thread Hillf Danton

On March 03, 2017 5:45 AM Laura Abbott wrote: 
> 
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> + struct sg_table *new_table;
> + int ret, i;
> + struct scatterlist *sg, *new_sg;
> +
> + new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
> + if (!new_table)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
> + if (ret) {
> + kfree(table);

Free new table?

> + return ERR_PTR(-ENOMEM);
> + }
> +
> + new_sg = new_table->sgl;
> + for_each_sg(table->sgl, sg, table->nents, i) {
> + memcpy(new_sg, sg, sizeof(*sg));
> + sg->dma_address = 0;
> + new_sg = sg_next(new_sg);
> + }
> +

Do we need a helper, sg_copy_table(dst_table, src_table)?

> + return new_table;
> +}
> +

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


[PATCH] drm/arcpgu: Opt in debugfs

2017-03-05 Thread Alexey Brodkin
This change adopts debugfs usage for outputting useful data.
As of today we print:
 * Mode and real HW clock values
 * Standard FB info

Code is heavily borrowed from ARM's HDLCD thus adding Liviu in Cc.

Signed-off-by: Alexey Brodkin 
Cc: Liviu Dudau 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jose Abreu 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 8d8344ed655e..5c82f52fba80 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -161,6 +161,32 @@ static int arcpgu_unload(struct drm_device *drm)
return 0;
 }
 
+#ifdef CONFIG_DEBUG_FS
+static int arcpgu_show_pxlclock(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *drm = node->minor->dev;
+   struct arcpgu_drm_private *arcpgu = drm->dev_private;
+   unsigned long clkrate = clk_get_rate(arcpgu->clk);
+   unsigned long mode_clock = arcpgu->crtc.mode.crtc_clock * 1000;
+
+   seq_printf(m, "hw  : %lu\n", clkrate);
+   seq_printf(m, "mode: %lu\n", mode_clock);
+   return 0;
+}
+
+static struct drm_info_list arcpgu_debugfs_list[] = {
+   { "clocks", arcpgu_show_pxlclock, 0 },
+   { "fb", drm_fb_cma_debugfs_show, 0 },
+};
+
+static int arcpgu_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(arcpgu_debugfs_list,
+   ARRAY_SIZE(arcpgu_debugfs_list), minor->debugfs_root, minor);
+}
+#endif
+
 static struct drm_driver arcpgu_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
   DRIVER_ATOMIC,
@@ -187,6 +213,9 @@ static struct drm_driver arcpgu_drm_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
+#ifdef CONFIG_DEBUG_FS
+   .debugfs_init = arcpgu_debugfs_init,
+#endif
 };
 
 static int arcpgu_probe(struct platform_device *pdev)
-- 
2.7.4

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


Re: [PATCHv2 05/10] drm: omapdrm: crtc: detect manually updated displays

2017-03-05 Thread Tony Lindgren
* Sebastian Reichel  [170304 16:45]:
> Signed-off-by: Sebastian Reichel 
> [t...@atomide.com: rebased on event_lock changes]

So for this feel free to add:

Tested-by: Tony Lindgren 
Signed-off-by: Tony Lindgren 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 8/9] drm: rcar-du: Add DPLL support

2017-03-05 Thread Laurent Pinchart
From: Koji Matsuoka 

The implementation hardcodes a workaround for the H3 ES1.x SoC
regardless of the SoC revision, as the workaround can be safely applied
on all devices in the Gen3 family without any side effect.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Ulrich Hecht 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 81 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_regs.h | 23 ++
 4 files changed, 105 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7391dd95c733..4ed6f2340af0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -106,9 +106,62 @@ static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
  * Hardware Setup
  */
 
+struct dpll_info {
+   unsigned int output;
+   unsigned int fdpll;
+   unsigned int n;
+   unsigned int m;
+};
+
+static void rcar_du_dpll_divider(struct rcar_du_crtc *rcrtc,
+struct dpll_info *dpll,
+unsigned long input,
+unsigned long target)
+{
+   unsigned long best_diff = (unsigned long)-1;
+   unsigned long diff;
+   unsigned int fdpll;
+   unsigned int m;
+   unsigned int n;
+
+   for (n = 39; n < 120; n++) {
+   for (m = 0; m < 4; m++) {
+   for (fdpll = 1; fdpll < 32; fdpll++) {
+   unsigned long output;
+
+   /* 1/2 (FRQSEL=1) for duty rate 50% */
+   output = input * (n + 1) / (m + 1)
+  / (fdpll + 1) / 2;
+
+   if (output >= 4)
+   continue;
+
+   diff = abs((long)output - (long)target);
+   if (best_diff > diff) {
+   best_diff = diff;
+   dpll->n = n;
+   dpll->m = m;
+   dpll->fdpll = fdpll;
+   dpll->output = output;
+   }
+
+   if (diff == 0)
+   goto done;
+   }
+   }
+   }
+
+done:
+   dev_dbg(rcrtc->group->dev->dev,
+   "output:%u, fdpll:%u, n:%u, m:%u, diff:%lu\n",
+dpll->output, dpll->fdpll, dpll->n, dpll->m,
+best_diff);
+}
+
 static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)
 {
const struct drm_display_mode *mode = &rcrtc->crtc.state->adjusted_mode;
+   struct rcar_du_device *rcdu = rcrtc->group->dev;
unsigned long mode_clock = mode->clock * 1000;
unsigned long clk;
u32 value;
@@ -124,12 +177,18 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
escr = div | ESCR_DCLKSEL_CLKS;
 
if (rcrtc->extclock) {
+   struct dpll_info dpll = { 0 };
unsigned long extclk;
unsigned long extrate;
unsigned long rate;
u32 extdiv;
 
extclk = clk_get_rate(rcrtc->extclock);
+   if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
+   rcar_du_dpll_divider(rcrtc, &dpll, extclk, mode_clock);
+   extclk = dpll.output;
+   }
+
extdiv = DIV_ROUND_CLOSEST(extclk, mode_clock);
extdiv = clamp(extdiv, 1U, 64U) - 1;
 
@@ -140,7 +199,27 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
abs((long)rate - (long)mode_clock)) {
dev_dbg(rcrtc->group->dev->dev,
"crtc%u: using external clock\n", rcrtc->index);
-   escr = extdiv | ESCR_DCLKSEL_DCLKIN;
+
+   if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
+   u32 dpllcr = DPLLCR_CODE | DPLLCR_CLKE
+  | DPLLCR_FDPLL(dpll.fdpll)
+  | DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
+  | DPLLCR_STBY;
+
+   if (rcrtc->index == 1)
+   dpllcr |= DPLLCR_PLCS1
+  |  DPLLCR_INCS_DOTCLKIN1;
+   else
+   dpllcr |= DPLLCR_PLCS0
+  |  DPLLCR_INCS_DOTCLKIN0;
+
+   rcar_du_group_write(rcrtc->group, DPLLCR,
+  

[PATCH v3 9/9] drm: rcar-du: Add HDMI outputs to R8A7795 device description

2017-03-05 Thread Laurent Pinchart
From: Koji Matsuoka 

Update the device description with the two available HDMI outputs.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  4 +++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 12 ++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index a7194812997e..15871fae7445 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -1,7 +1,7 @@
 /*
  * rcar_du_crtc.h  --  R-Car Display Unit CRTCs
  *
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2015 Renesas Electronics Corporation
  *
  * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  *
@@ -61,6 +61,8 @@ enum rcar_du_output {
RCAR_DU_OUTPUT_DPAD1,
RCAR_DU_OUTPUT_LVDS0,
RCAR_DU_OUTPUT_LVDS1,
+   RCAR_DU_OUTPUT_HDMI0,
+   RCAR_DU_OUTPUT_HDMI1,
RCAR_DU_OUTPUT_TCON,
RCAR_DU_OUTPUT_MAX,
 };
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 3d789e68ec13..846971fdc196 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -149,13 +149,21 @@ static const struct rcar_du_device_info 
rcar_du_r8a7795_info = {
  | RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 4,
.routes = {
-   /* R8A7795 has one RGB output, one LVDS output and two
-* (currently unsupported) HDMI outputs.
+   /* R8A7795 has one RGB output, two HDMI outputs and one
+* LVDS output.
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(3),
.port = 0,
},
+   [RCAR_DU_OUTPUT_HDMI0] = {
+   .possible_crtcs = BIT(1),
+   .port = 1,
+   },
+   [RCAR_DU_OUTPUT_HDMI1] = {
+   .possible_crtcs = BIT(2),
+   .port = 2,
+   },
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs = BIT(0),
.port = 3,
-- 
Regards,

Laurent Pinchart

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


[PATCH v3 3/9] drm: rcar-du: Replace manual bridge implementation with DRM bridge

2017-03-05 Thread Laurent Pinchart
The rcar-du driver contains a manual implementation of HDMI and VGA
bridges. Use DRM bridges to replace it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig   |   6 --
 drivers/gpu/drm/rcar-du/Makefile  |   5 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 104 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   2 -
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 134 --
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h |  35 
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  |  82 --
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h  |  23 -
 8 files changed, 60 insertions(+), 331 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 2bab449add76..06121eeba9e5 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,12 +11,6 @@ config DRM_RCAR_DU
  Choose this option if you have an R-Car chipset.
  If M is selected the module will be called rcar-du-drm.
 
-config DRM_RCAR_HDMI
-   bool "R-Car DU HDMI Encoder Support"
-   depends on DRM_RCAR_DU
-   help
- Enable support for external HDMI encoders.
-
 config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index d3b44651061a..a492e6858691 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,10 +4,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_group.o \
 rcar_du_kms.o \
 rcar_du_lvdscon.o \
-rcar_du_plane.o \
-rcar_du_vgacon.o
-
-rcar-du-drm-$(CONFIG_DRM_RCAR_HDMI)+= rcar_du_hdmienc.o
+rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 3a3c9374794e..92a0405c2fb2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -20,11 +20,9 @@
 
 #include "rcar_du_drv.h"
 #include "rcar_du_encoder.h"
-#include "rcar_du_hdmienc.h"
 #include "rcar_du_kms.h"
 #include "rcar_du_lvdscon.h"
 #include "rcar_du_lvdsenc.h"
-#include "rcar_du_vgacon.h"
 
 /* 
-
  * Encoder
@@ -63,29 +61,35 @@ static int rcar_du_encoder_atomic_check(struct drm_encoder 
*encoder,
struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
const struct drm_display_mode *mode = &crtc_state->mode;
-   const struct drm_display_mode *panel_mode;
struct drm_connector *connector = conn_state->connector;
struct drm_device *dev = encoder->dev;
 
-   /* DAC encoders have currently no restriction on the mode. */
-   if (encoder->encoder_type == DRM_MODE_ENCODER_DAC)
-   return 0;
+   /*
+* Only panel-related encoder types require validation here, everything
+* else is handled by the bridge drivers.
+*/
+   if (encoder->encoder_type == DRM_MODE_ENCODER_LVDS) {
+   const struct drm_display_mode *panel_mode;
 
-   if (list_empty(&connector->modes)) {
-   dev_dbg(dev->dev, "encoder: empty modes list\n");
-   return -EINVAL;
-   }
+   if (list_empty(&connector->modes)) {
+   dev_dbg(dev->dev, "encoder: empty modes list\n");
+   return -EINVAL;
+   }
 
-   panel_mode = list_first_entry(&connector->modes,
- struct drm_display_mode, head);
+   panel_mode = list_first_entry(&connector->modes,
+ struct drm_display_mode, head);
 
-   /* We're not allowed to modify the resolution. */
-   if (mode->hdisplay != panel_mode->hdisplay ||
-   mode->vdisplay != panel_mode->vdisplay)
-   return -EINVAL;
+   /* We're not allowed to modify the resolution. */
+   if (mode->hdisplay != panel_mode->hdisplay ||
+   mode->vdisplay != panel_mode->vdisplay)
+   return -EINVAL;
 
-   /* The flat panel mode is fixed, just copy it to the adjusted mode. */
-   drm_mode_copy(adjusted_mode, panel_mode);
+   /*
+* The flat panel mode is fixed, just copy it to the adjusted
+* mode.
+*/
+   drm_mode_copy(adjusted_mode, panel_mode);
+   }
 
if (renc->lvds)

[PATCH v3 4/9] drm: rcar-du: Hardcode encoders types to DRM_MODE_ENCODER_NONE

2017-03-05 Thread Laurent Pinchart
Unlike the connector type, the encoder type is unused by userspace. As
it is equally unused in the driver, except in a single location where
the connector type can be used instead, hardcode it to
DRM_MODE_ENCODER_NONE. This allow removing all code that tries to
determine (unsuccessfully in case a bridge is used) the encoder type.

Signed-off-by: Laurent Pinchart 
---
Changes since v3:

- New patch, replaces "drm: rcar-du: Initialize encoder's type based on
  the bridge's type"
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 15 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |  2 --
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 30 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  9 
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 37 ++-
 5 files changed, 11 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index eb905e6b5f4c..327adb7a25c4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -44,12 +44,10 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
[RCAR_DU_OUTPUT_DPAD1] = {
.possible_crtcs = BIT(1) | BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 1,
},
},
@@ -68,17 +66,14 @@ static const struct rcar_du_device_info 
rcar_du_r8a7790_info = {
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(2) | BIT(1) | BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs = BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_LVDS,
.port = 1,
},
[RCAR_DU_OUTPUT_LVDS1] = {
.possible_crtcs = BIT(2) | BIT(1),
-   .encoder_type = DRM_MODE_ENCODER_LVDS,
.port = 2,
},
},
@@ -97,12 +92,10 @@ static const struct rcar_du_device_info 
rcar_du_r8a7791_info = {
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(1) | BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs = BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_LVDS,
.port = 1,
},
},
@@ -118,12 +111,10 @@ static const struct rcar_du_device_info 
rcar_du_r8a7792_info = {
/* R8A7792 has two RGB outputs. */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
[RCAR_DU_OUTPUT_DPAD1] = {
.possible_crtcs = BIT(1),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 1,
},
},
@@ -141,12 +132,10 @@ static const struct rcar_du_device_info 
rcar_du_r8a7794_info = {
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
[RCAR_DU_OUTPUT_DPAD1] = {
.possible_crtcs = BIT(1),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 1,
},
},
@@ -165,12 +154,10 @@ static const struct rcar_du_device_info 
rcar_du_r8a7795_info = {
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(3),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs = BIT(0),
-   .encoder_type = DRM_MODE_ENCODER_LVDS,
.port = 3,
},
},
@@ -189,12 +176,10 @@ static const struct rcar_du_device_info 
rcar_du_r8a7796_info = {
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(2),
-   .encoder_type = DRM_MODE_ENCODER_NONE,
.port = 0,
},
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs =

[PATCH v3 7/9] drm: rcar-du: Skip disabled outputs

2017-03-05 Thread Laurent Pinchart
When a DT node connected to a DU output is disabled no bridge will ever
be instantiated for it. Skip the output in that case.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index f38fc2f3f93d..f4125c8ca902 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -302,6 +302,13 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
return -ENODEV;
}
 
+   if (!of_device_is_available(entity)) {
+   dev_dbg(rcdu->dev,
+   "connected entity %s is disabled, skipping\n",
+   entity->full_name);
+   return -ENODEV;
+   }
+
entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
 
for_each_endpoint_of_node(entity, ep_node) {
-- 
Regards,

Laurent Pinchart

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


[PATCH v3 1/9] drm: rcar-du: Use the DRM panel API

2017-03-05 Thread Laurent Pinchart
Instead of parsing the panel device tree node manually, use the panel
API to delegate panel handling to a panel driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig   |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 22 ++
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  3 ++
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 68 +++
 4 files changed, 50 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 4c2fd056dd6d..2bab449add76 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -20,6 +20,7 @@ config DRM_RCAR_HDMI
 config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
+   select DRM_PANEL
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 3974d9495f37..31f878ad099d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rcar_du_drv.h"
 #include "rcar_du_encoder.h"
@@ -33,6 +34,11 @@ static void rcar_du_encoder_disable(struct drm_encoder 
*encoder)
 {
struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
 
+   if (renc->connector && renc->connector->panel) {
+   drm_panel_disable(renc->connector->panel);
+   drm_panel_unprepare(renc->connector->panel);
+   }
+
if (renc->lvds)
rcar_du_lvdsenc_enable(renc->lvds, encoder->crtc, false);
 }
@@ -43,6 +49,11 @@ static void rcar_du_encoder_enable(struct drm_encoder 
*encoder)
 
if (renc->lvds)
rcar_du_lvdsenc_enable(renc->lvds, encoder->crtc, true);
+
+   if (renc->connector && renc->connector->panel) {
+   drm_panel_prepare(renc->connector->panel);
+   drm_panel_enable(renc->connector->panel);
+   }
 }
 
 static int rcar_du_encoder_atomic_check(struct drm_encoder *encoder,
@@ -89,6 +100,17 @@ static void rcar_du_encoder_mode_set(struct drm_encoder 
*encoder,
struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
 
rcar_du_crtc_route_output(crtc_state->crtc, renc->output);
+
+   if (!renc->lvds) {
+   /*
+* The DU driver creates connectors only for the outputs of the
+* internal LVDS encoders.
+*/
+   renc->connector = NULL;
+   return;
+   }
+
+   renc->connector = to_rcar_connector(conn_state->connector);
 }
 
 static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index a050a3699857..b79b2f075a74 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 
+struct drm_panel;
 struct rcar_du_device;
 struct rcar_du_hdmienc;
 struct rcar_du_lvdsenc;
@@ -32,6 +33,7 @@ enum rcar_du_encoder_type {
 struct rcar_du_encoder {
struct drm_encoder base;
enum rcar_du_output output;
+   struct rcar_du_connector *connector;
struct rcar_du_hdmienc *hdmi;
struct rcar_du_lvdsenc *lvds;
 };
@@ -44,6 +46,7 @@ struct rcar_du_encoder {
 struct rcar_du_connector {
struct drm_connector connector;
struct rcar_du_encoder *encoder;
+   struct drm_panel *panel;
 };
 
 #define to_rcar_connector(c) \
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
index 3bcfd161c53f..ee91481131ad 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -25,47 +26,30 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_lvdscon.h"
 
-struct rcar_du_lvds_connector {
-   struct rcar_du_connector connector;
-
-   struct {
-   unsigned int width_mm;  /* Panel width in mm */
-   unsigned int height_mm; /* Panel height in mm */
-   struct videomode mode;
-   } panel;
-};
-
-#define to_rcar_lvds_connector(c) \
-   container_of(c, struct rcar_du_lvds_connector, connector.connector)
-
 static int rcar_du_lvds_connector_get_modes(struct drm_connector *connector)
 {
-   struct rcar_du_lvds_connector *lvdscon =
-   to_rcar_lvds_connector(connector);
-   struct drm_display_mode *mode;
-
-   mode = drm_mode_create(connector->dev);
-   if (mode == NULL)
-   return 0;
+   struct rcar_du_connector *rcon = to_rcar_connector(connector);
 
-   mode->type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER;
-
-   drm_display_mode_from_videomode(&lvdscon->panel.mode, mode);
-
-   

[PATCH v3 6/9] drm: rcar-du: Add Gen3 HDMI encoder support

2017-03-05 Thread Laurent Pinchart
From: Koji Matsuoka 

The R-Car Gen3 SoCs include on-chip DesignWare HDMI encoders. Support
them with a platform driver to provide platform glue data to the dw-hdmi
driver.

The driver is a complete rewrite of code coming from the Renesas BSP,
save for the values in the PHY parameters table.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Ulrich Hecht 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Kieran Bingham 
---
Changes since v2:

- Replaced the dependency on DRM_RCAR_DU with DRM and made the symbol
  tristate.
---
 drivers/gpu/drm/rcar-du/Kconfig|   7 +++
 drivers/gpu/drm/rcar-du/Makefile   |   1 +
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 100 +
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 06121eeba9e5..8a50dab19e5c 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,6 +11,13 @@ config DRM_RCAR_DU
  Choose this option if you have an R-Car chipset.
  If M is selected the module will be called rcar-du-drm.
 
+config DRM_RCAR_DW_HDMI
+   tristate "R-Car DU Gen3 HDMI Encoder Support"
+   depends on DRM && OF
+   select DRM_DW_HDMI
+   help
+ Enable support for R-Car Gen3 internal HDMI encoder.
+
 config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index a492e6858691..2131e722de3b 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -11,3 +11,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)   += rcar_du_lvdsenc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
+obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c 
b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
new file mode 100644
index ..7539626b8ebd
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -0,0 +1,100 @@
+/*
+ * R-Car Gen3 HDMI PHY
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include 
+
+#define RCAR_HDMI_PHY_OPMODE_PLLCFG0x06/* Mode of operation and PLL 
dividers */
+#define RCAR_HDMI_PHY_PLLCURRGMPCTRL   0x10/* PLL current and Gmp 
(conductance) */
+#define RCAR_HDMI_PHY_PLLDIVCTRL   0x11/* PLL dividers */
+
+struct rcar_hdmi_phy_params {
+   unsigned long mpixelclock;
+   u16 opmode_div; /* Mode of operation and PLL dividers */
+   u16 curr_gmp;   /* PLL current and Gmp (conductance) */
+   u16 div;/* PLL dividers */
+};
+
+static const struct rcar_hdmi_phy_params rcar_hdmi_phy_params[] = {
+   { 3550,  0x0003, 0x0344, 0x0328 },
+   { 4490,  0x0003, 0x0285, 0x0128 },
+   { 7100,  0x0002, 0x1184, 0x0314 },
+   { 9000,  0x0002, 0x1144, 0x0114 },
+   { 14025, 0x0001, 0x20c4, 0x030a },
+   { 18275, 0x0001, 0x2084, 0x010a },
+   { 28125, 0x, 0x0084, 0x0305 },
+   { 29700, 0x, 0x0084, 0x0105 },
+   { ~0UL,  0x, 0x, 0x },
+};
+
+static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
+  const struct dw_hdmi_plat_data *pdata,
+  unsigned long mpixelclock)
+{
+   const struct rcar_hdmi_phy_params *params = rcar_hdmi_phy_params;
+
+   for (; params && params->mpixelclock != ~0UL; ++params) {
+   if (mpixelclock <= params->mpixelclock)
+   break;
+   }
+
+   if (params->mpixelclock == ~0UL)
+   return -EINVAL;
+
+   dw_hdmi_phy_i2c_write(hdmi, params->opmode_div,
+ RCAR_HDMI_PHY_OPMODE_PLLCFG);
+   dw_hdmi_phy_i2c_write(hdmi, params->curr_gmp,
+ RCAR_HDMI_PHY_PLLCURRGMPCTRL);
+   dw_hdmi_phy_i2c_write(hdmi, params->div, RCAR_HDMI_PHY_PLLDIVCTRL);
+
+   return 0;
+}
+
+static const struct dw_hdmi_plat_data rcar_dw_hdmi_plat_data = {
+   .configure_phy  = rcar_hdmi_phy_configure,
+};
+
+static int rcar_dw_hdmi_probe(struct platform_device *pdev)
+{
+   return dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
+}
+
+static int rcar_dw_hdmi_remove(struct platform_device *pdev)
+{
+   dw_hdmi_remove(pdev);
+
+   return 0;
+}
+
+static const struct of_device_id rcar_dw_hdmi_of_table[] = {
+   { .compatible = "renesas,rcar-gen3-hdmi" },
+   { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, rcar_dw_hdmi_

[PATCH v3 0/9] R-Car Gen3 HDMI output support

2017-03-05 Thread Laurent Pinchart
Hello,

This patch series implements support for the HDMI output on Renesas R-Car Gen3
SoCs, and more specifically on the R-Car H3.

Compared to the previous version, I've left out all the dw-hdmi patches that
have been updated separately and are on their way to being merged. I've also
left out the DT integration patches that will be submitted separately. I have
on the other hand included patches 1/9 to 4/9 that were an implicit dependency
of the previous version.

The patches are based on a merge of the following branches and tags from
git://linuxtv.org/pinchartl/media.git

- DWC HDMI Driver: drm-next-dw-hdmi-v5.1-20170306
- DRM LVDS Encoder Driver: drm-next-lvds-encoder-v4-20170302
- DRM LVDS Panel Driver: drm/next/lvds-panel
- R-Car DU Driver: drm/next/du

I plan to send a pull request for theses patches and the dependencies that
won't be merged through drm-misc in the next few days.

Koji Matsuoka (3):
  drm: rcar-du: Add Gen3 HDMI encoder support
  drm: rcar-du: Add DPLL support
  drm: rcar-du: Add HDMI outputs to R8A7795 device description

Laurent Pinchart (6):
  drm: rcar-du: Use the DRM panel API
  drm: rcar-du: Add support for LVDS mode selection
  drm: rcar-du: Replace manual bridge implementation with DRM bridge
  drm: rcar-du: Hardcode encoders types to DRM_MODE_ENCODER_NONE
  dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings
  drm: rcar-du: Skip disabled outputs

 .../bindings/display/bridge/renesas,dw-hdmi.txt|  75 +
 MAINTAINERS|   1 +
 drivers/gpu/drm/rcar-du/Kconfig|  10 +-
 drivers/gpu/drm/rcar-du/Makefile   |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  81 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  28 ++--
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 179 +
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c  | 134 ---
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h  |  35 
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  44 ++---
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  68 +++-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  |  11 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  |  13 ++
 drivers/gpu/drm/rcar-du/rcar_du_regs.h |  23 +++
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c   |  82 --
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h   |  23 ---
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 100 
 20 files changed, 475 insertions(+), 459 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c

-- 
Regards,

Laurent Pinchart

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


[PATCH v3 2/9] drm: rcar-du: Add support for LVDS mode selection

2017-03-05 Thread Laurent Pinchart
Retrieve the LVDS mode from the panel and configure the LVDS encoder
accordingly. LVDS mode selection is static as LVDS panels can't be
hot-plugged on any of the device supported by the driver. Support for
dynamic mode selection can be implemented in the future when needed.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Rebased on top of the DRM_BUS_FLAG_DATA_MIRROR rename.
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 27 +++
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 +--
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 13 +
 3 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 31f878ad099d..3a3c9374794e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -98,6 +98,8 @@ static void rcar_du_encoder_mode_set(struct drm_encoder 
*encoder,
 struct drm_connector_state *conn_state)
 {
struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
+   struct drm_display_info *info = &conn_state->connector->display_info;
+   enum rcar_lvds_mode mode;
 
rcar_du_crtc_route_output(crtc_state->crtc, renc->output);
 
@@ -111,6 +113,31 @@ static void rcar_du_encoder_mode_set(struct drm_encoder 
*encoder,
}
 
renc->connector = to_rcar_connector(conn_state->connector);
+
+   if (!info->num_bus_formats || !info->bus_formats) {
+   dev_err(encoder->dev->dev, "no LVDS bus format reported\n");
+   return;
+   }
+
+   switch (info->bus_formats[0]) {
+   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+   case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
+   mode = RCAR_LVDS_MODE_JEIDA;
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
+   mode = RCAR_LVDS_MODE_VESA;
+   break;
+   default:
+   dev_err(encoder->dev->dev,
+   "unsupported LVDS bus format 0x%04x\n",
+   info->bus_formats[0]);
+   return;
+   }
+
+   if (info->bus_flags & DRM_BUS_FLAG_DATA_LSB_TO_MSB)
+   mode |= RCAR_LVDS_MODE_MIRROR;
+
+   rcar_du_lvdsenc_set_mode(renc->lvds, mode);
 }
 
 static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index e3a4985f6f3f..1661f6201210 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -31,6 +31,7 @@ struct rcar_du_lvdsenc {
bool enabled;
 
enum rcar_lvds_input input;
+   enum rcar_lvds_mode mode;
 };
 
 static void rcar_lvds_write(struct rcar_du_lvdsenc *lvds, u32 reg, u32 data)
@@ -61,7 +62,7 @@ static void rcar_du_lvdsenc_start_gen2(struct rcar_du_lvdsenc 
*lvds,
/* Select the input, hardcode mode 0, enable LVDS operation and turn
 * bias circuitry on.
 */
-   lvdcr0 = LVDCR0_BEN | LVDCR0_LVEN;
+   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
if (rcrtc->index == 2)
lvdcr0 |= LVDCR0_DUSEL;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
@@ -114,7 +115,7 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,
 * Turn the PLL on, set it to LVDS normal mode, wait for the startup
 * delay and turn the output on.
 */
-   lvdcr0 = LVDCR0_PLLON;
+   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
 
lvdcr0 |= LVDCR0_PWD;
@@ -211,6 +212,12 @@ void rcar_du_lvdsenc_atomic_check(struct rcar_du_lvdsenc 
*lvds,
mode->clock = clamp(mode->clock, 25175, 148500);
 }
 
+void rcar_du_lvdsenc_set_mode(struct rcar_du_lvdsenc *lvds,
+ enum rcar_lvds_mode mode)
+{
+   lvds->mode = mode;
+}
+
 static int rcar_du_lvdsenc_get_resources(struct rcar_du_lvdsenc *lvds,
 struct platform_device *pdev)
 {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
index dfdba746edf4..7218ac89333e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
@@ -26,8 +26,17 @@ enum rcar_lvds_input {
RCAR_LVDS_INPUT_DU2,
 };
 
+/* Keep in sync with the LVDCR0.LVMD hardware register values. */
+enum rcar_lvds_mode {
+   RCAR_LVDS_MODE_JEIDA = 0,
+   RCAR_LVDS_MODE_MIRROR = 1,
+   RCAR_LVDS_MODE_VESA = 4,
+};
+
 #if IS_ENABLED(CONFIG_DRM_RCAR_LVDS)
 int rcar_du_lvdsenc_init(struct rcar_du_device *rcdu);
+void rcar_du_lvdsenc_set_mode(struct rcar_du_lvdsenc *lvds,
+ enum rcar_lvds_mode mode);
 int rcar_du_lvdsenc_enable(struct rcar_du_lvdsenc *lvds,
   struct drm_crtc *crtc, bool enable);
 void 

[PATCH v3 5/9] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings

2017-03-05 Thread Laurent Pinchart
The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
corresponding device tree bindings based on the DWC HDMI TX bindings
model.

Signed-off-by: Laurent Pinchart 
Acked-by: Rob Herring 
---
 .../bindings/display/bridge/renesas,dw-hdmi.txt| 75 ++
 MAINTAINERS|  1 +
 2 files changed, 76 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
new file mode 100644
index ..f6b3f36d422b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
@@ -0,0 +1,75 @@
+Renesas Gen3 DWC HDMI TX Encoder
+
+
+The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+with a companion PHY IP.
+
+These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
+Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
+following device-specific properties.
+
+
+Required properties:
+
+- compatible : Shall contain one or more of
+  - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
+  - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX
+
+When compatible with generic versions, nodes must list the SoC-specific
+version corresponding to the platform first, followed by the
+family-specific version.
+
+- reg: See dw_hdmi.txt.
+- interrupts: HDMI interrupt number
+- clocks: See dw_hdmi.txt.
+- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
+- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
+  corresponding to the video input of the controller and one port numbered 1
+  corresponding to its HDMI output. Each port shall have a single endpoint.
+
+Optional properties:
+
+- power-domains: Shall reference the power domain that contains the DWC HDMI,
+  if any.
+
+
+Example:
+
+   hdmi0: hdmi0@fead {
+   compatible = "renesas,r8a7795-dw-hdmi";
+   reg = <0 0xfead 0 0x1>;
+   interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
+   clock-names = "iahb", "isfr";
+   power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   dw_hdmi0_in: endpoint {
+   remote-endpoint = <&du_out_hdmi0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   rcar_dw_hdmi0_out: endpoint {
+   remote-endpoint = <&hdmi0_con>;
+   };
+   };
+   };
+   };
+
+   hdmi0-out {
+   compatible = "hdmi-connector";
+   label = "HDMI0 OUT";
+   type = "a";
+
+   port {
+   hdmi0_con: endpoint {
+   remote-endpoint = <&rcar_dw_hdmi0_out>;
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 6ba488e6c958..40d704105957 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4382,6 +4382,7 @@ S:Supported
 F: drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
+F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVER FOR QXL VIRTUAL GPU
-- 
Regards,

Laurent Pinchart

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


[PATCH v5.1 06/10] drm: bridge: dw-hdmi: Create PHY operations

2017-03-05 Thread Laurent Pinchart
The HDMI TX controller support different PHYs whose programming
interface can vary significantly, especially with vendor PHYs that are
not provided by Synopsys. To support them, create a PHY operation
structure that can be provided by the platform glue layer. The existing
PHY handling code (limited to Synopsys PHY support) is refactored into a
set of default PHY operations that are used automatically when the
platform glue doesn't provide its own operations.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 95 
 include/drm/bridge/dw_hdmi.h | 18 +++-
 2 files changed, 82 insertions(+), 31 deletions(-)

Changes since v5:

- Undo changes from v5.1 04/10 and 05/10

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index c25eac8ba47b..cb2703862be2 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -141,8 +141,12 @@ struct dw_hdmi {
u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
 
-   const struct dw_hdmi_phy_data *phy;
-   bool phy_enabled;
+   struct {
+   const struct dw_hdmi_phy_ops *ops;
+   const char *name;
+   void *data;
+   bool enabled;
+   } phy;
 
struct drm_display_mode previous_mode;
 
@@ -831,6 +835,10 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
  HDMI_VP_CONF);
 }
 
+/* 
-
+ * Synopsys PHY Handling
+ */
+
 static inline void hdmi_phy_test_clear(struct dw_hdmi *hdmi,
   unsigned char bit)
 {
@@ -917,7 +925,7 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 
 static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
 {
-   const struct dw_hdmi_phy_data *phy = hdmi->phy;
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
unsigned int i;
u16 val;
 
@@ -951,7 +959,7 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
 
 static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 {
-   const struct dw_hdmi_phy_data *phy = hdmi->phy;
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
unsigned int i;
u8 val;
 
@@ -987,6 +995,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
@@ -1019,7 +1028,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
dw_hdmi_phy_power_off(hdmi);
 
/* Leave low power consumption mode by asserting SVSRET. */
-   if (hdmi->phy->has_svsret)
+   if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
 
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
@@ -1057,7 +1066,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
return dw_hdmi_phy_power_on(hdmi);
 }
 
-static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
+static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
+   struct drm_display_mode *mode)
 {
int i, ret;
 
@@ -1071,10 +1081,31 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
return ret;
}
 
-   hdmi->phy_enabled = true;
return 0;
 }
 
+static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
+{
+   dw_hdmi_phy_power_off(hdmi);
+}
+
+static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data)
+{
+   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
+   connector_status_connected : connector_status_disconnected;
+}
+
+static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
+   .init = dw_hdmi_phy_init,
+   .disable = dw_hdmi_phy_disable,
+   .read_hpd = dw_hdmi_phy_read_hpd,
+};
+
+/* 
-
+ * HDMI TX Setup
+ */
+
 static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
 {
u8 de;
@@ -1289,16 +1320,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
 }
 
-static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
-{
-   if (!hdmi->phy_enabled)
-   return;
-
-   dw_hdmi_phy_power_off(hdmi);
-
-   hdmi->phy_enabled = false;
-}
-
 /* HDMI Initialization Step B.4 */
 static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
 {
@@ -1431,9 +1452,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
hdmi_av_composer(hdmi, mode);
 
/* HDMI Initial

[PATCH v5.1 05/10] drm: bridge: dw-hdmi: Fix the PHY power up sequence

2017-03-05 Thread Laurent Pinchart
When powering the PHY up we need to wait for the PLL to lock. This is
done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
(interrupt-based wait could be implemented as well but is likely
overkill). The bit is asserted when the PLL locks, but the current code
incorrectly waits for the bit to be deasserted. Fix it, and while at it,
replace the udelay() with a sleep as the code never runs in
non-sleepable context.

To be consistent with the power down implementation move the poll loop
to the power off function.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 65 +++-
 1 file changed, 37 insertions(+), 28 deletions(-)

Changes since v5:

- Fix compilation breakage due to reordering of the patches compared to v4

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 3a1cd4c7ac64..c25eac8ba47b 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -949,9 +949,44 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
dw_hdmi_phy_gen2_pddq(hdmi, 1);
 }
 
+static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
+{
+   const struct dw_hdmi_phy_data *phy = hdmi->phy;
+   unsigned int i;
+   u8 val;
+
+   if (phy->gen == 1) {
+   dw_hdmi_phy_enable_powerdown(hdmi, false);
+
+   /* Toggle TMDS enable. */
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_tmds(hdmi, 1);
+   return 0;
+   }
+
+   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+   dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+   /* Wait for PHY PLL lock */
+   for (i = 0; i < 5; ++i) {
+   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
+   if (val)
+   break;
+
+   usleep_range(1000, 2000);
+   }
+
+   if (!val) {
+   dev_err(hdmi->dev, "PHY PLL failed to lock\n");
+   return -ETIMEDOUT;
+   }
+
+   dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
+   return 0;
+}
+
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
-   u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
@@ -1019,33 +1054,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
   HDMI_3D_TX_PHY_CKCALCTRL);
 
-   dw_hdmi_phy_enable_powerdown(hdmi, false);
-
-   /* toggle TMDS enable */
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 1);
-
-   /* gen2 tx power on */
-   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
-   dw_hdmi_phy_gen2_pddq(hdmi, 0);
-
-   /* Wait for PHY PLL lock */
-   msec = 5;
-   do {
-   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-   if (!val)
-   break;
-
-   if (msec == 0) {
-   dev_err(hdmi->dev, "PHY PLL not locked\n");
-   return -ETIMEDOUT;
-   }
-
-   udelay(1000);
-   msec--;
-   } while (1);
-
-   return 0;
+   return dw_hdmi_phy_power_on(hdmi);
 }
 
 static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
-- 
Regards,

Laurent Pinchart

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


[PATCH v5.1 04/10] drm: bridge: dw-hdmi: Fix the PHY power down sequence

2017-03-05 Thread Laurent Pinchart
The PHY requires us to wait for the PHY to switch to low power mode
after deasserting TXPWRON and before asserting PDDQ in the power down
sequence, otherwise power down will fail.

The PHY power down can be monitored though the TX_READY bit, available
through I2C in the PHY registers, or the TX_PHY_LOCK bit, available
through the HDMI TX registers. As the two are equivalent, let's pick the
easier solution of polling the TX_PHY_LOCK bit.

The power down code is currently duplicated in multiple places. To avoid
spreading multiple calls to a TX_PHY_LOCK poll function, we have to
refactor the power down code and group it all in a single function.

Tests showed that one poll iteration was enough for TX_PHY_LOCK to
become low, without requiring any additional delay. Retrying the read
five times with a 1ms to 2ms delay between each attempt should thus be
more than enough.

Signed-off-by: Laurent Pinchart 
Tested-by: Neil Armstrong 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 52 +---
 1 file changed, 43 insertions(+), 9 deletions(-)

Changes since v5:

- Fix compilation breakage due to reordering of the patches compared to v4

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index d863b3393aee..3a1cd4c7ac64 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -116,6 +116,7 @@ struct dw_hdmi_i2c {
 struct dw_hdmi_phy_data {
enum dw_hdmi_phy_type type;
const char *name;
+   unsigned int gen;
bool has_svsret;
 };
 
@@ -914,6 +915,40 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }
 
+static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
+{
+   const struct dw_hdmi_phy_data *phy = hdmi->phy;
+   unsigned int i;
+   u16 val;
+
+   if (phy->gen == 1) {
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_powerdown(hdmi, true);
+   return;
+   }
+
+   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+
+   /*
+* Wait for TX_PHY_LOCK to be deasserted to indicate that the PHY went
+* to low power mode.
+*/
+   for (i = 0; i < 5; ++i) {
+   val = hdmi_readb(hdmi, HDMI_PHY_STAT0);
+   if (!(val & HDMI_PHY_TX_PHY_LOCK))
+   break;
+
+   usleep_range(1000, 2000);
+   }
+
+   if (val & HDMI_PHY_TX_PHY_LOCK)
+   dev_warn(hdmi->dev, "PHY failed to power down\n");
+   else
+   dev_dbg(hdmi->dev, "PHY powered down in %u iterations\n", i);
+
+   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+}
+
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
u8 val, msec;
@@ -946,11 +981,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
return -EINVAL;
}
 
-   /* gen2 tx power off */
-   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
-
-   /* gen2 pddq */
-   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+   dw_hdmi_phy_power_off(hdmi);
 
/* Leave low power consumption mode by asserting SVSRET. */
if (hdmi->phy->has_svsret)
@@ -1025,8 +1056,6 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
for (i = 0; i < 2; i++) {
dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
dw_hdmi_phy_sel_interface_control(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_powerdown(hdmi, true);
 
ret = hdmi_phy_configure(hdmi);
if (ret)
@@ -1256,8 +1285,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
if (!hdmi->phy_enabled)
return;
 
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_powerdown(hdmi, true);
+   dw_hdmi_phy_power_off(hdmi);
 
hdmi->phy_enabled = false;
 }
@@ -1827,23 +1855,29 @@ static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
{
.type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
.name = "DWC HDMI TX PHY",
+   .gen = 1,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
.name = "DWC MHL PHY + HEAC PHY",
+   .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY,
.name = "DWC MHL PHY",
+   .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
.name = "DWC HDMI 3D TX PHY + HEAC PHY",
+   .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
.name = "DWC HDMI 3D TX PHY",
+   .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
.name = "DWC HDMI 2.0 TX PHY",
+   .gen = 2,
.has_svsret = true,
}
 };
-- 
Regards,

Laurent Pinchart


[regression] Re: 4.11-rc0, thinkpad x220: GPU hang

2017-03-05 Thread Pavel Machek
Hi!

> > mplayer stopped working after a while. Dmesg says:
> > 
> > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at

Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
try? Bisect will be slow and nasty :-(.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

2017-03-05 Thread Stefan Lengfeld
Hi Maxime,

On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote:
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
> 
> Signed-off-by: Maxime Ripard 
> Tested-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 68 ++-
>  include/drm/drm_fb_helper.h | 12 +-
>  2 files changed, 79 insertions(+), 1 deletion(-)

I have tested the current HEAD of drm-misc-next. It includes this patch
and the patch ("drm/fb-helper: Add multi buffer support for cma fbdev").
On my i.MX6 board with HDMI output both patches work as advertised.
Multi-buffering with ioctls FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY is
possible.

Kind Regards
Stefan Lengfeld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 3/3] drm: rcar-du: Register a completion callback with VSP1

2017-03-05 Thread Laurent Pinchart
Hi Kieran,

Thank you for the patch.

On Sunday 05 Mar 2017 16:00:04 Kieran Bingham wrote:
> Currently we process page flip events on every display interrupt,
> however this does not take into consideration the processing time needed
> by the VSP1 utilised in the pipeline.
> 
> Register a callback with the VSP driver to obtain completion events, and
> track them so that we only perform page flips when the full display
> pipeline has completed for the frame.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  9 +
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 2aceb84fc15d..c1812e20
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -299,7 +299,7 @@ static void rcar_du_crtc_update_planes(struct
> rcar_du_crtc *rcrtc) * Page Flip
>   */
> 
> -static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
> +void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
>  {
>   struct drm_pending_vblank_event *event;
>   struct drm_device *dev = rcrtc->crtc.dev;
> @@ -571,6 +571,7 @@ static const struct drm_crtc_funcs crtc_funcs = {
>  static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
>  {
>   struct rcar_du_crtc *rcrtc = arg;
> + struct rcar_du_device *rcdu = rcrtc->group->dev;
>   irqreturn_t ret = IRQ_NONE;
>   u32 status;
> 
> @@ -579,7 +580,10 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
> 
>   if (status & DSSR_FRM) {
>   drm_crtc_handle_vblank(&rcrtc->crtc);
> - rcar_du_crtc_finish_page_flip(rcrtc);
> +
> + if (rcdu->info->gen < 3)
> + rcar_du_crtc_finish_page_flip(rcrtc);
> +
>   ret = IRQ_HANDLED;
>   }
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h index a7194812997e..ebdbff9d8e59
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -71,5 +71,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
> 
>  void rcar_du_crtc_route_output(struct drm_crtc *crtc,
>  enum rcar_du_output output);
> +void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
> 
>  #endif /* __RCAR_DU_CRTC_H__ */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index b0ff304ce3dc..cbb6f54c99ef
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -28,6 +28,13 @@
>  #include "rcar_du_kms.h"
>  #include "rcar_du_vsp.h"
> 
> +static void rcar_du_vsp_complete(void *private)
> +{
> + struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;

I'll remove the cast when applying, as pointed out by Sergei.

Reviewed-by: Laurent Pinchart 

> +
> + rcar_du_crtc_finish_page_flip(crtc);
> +}
> +
>  void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>  {
>   const struct drm_display_mode *mode = &crtc->crtc.state-
>adjusted_mode;
> @@ -35,6 +42,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>   struct vsp1_du_lif_config cfg = {
>   .width = mode->hdisplay,
>   .height = mode->vdisplay,
> + .callback = rcar_du_vsp_complete,
> + .callback_data = crtc,
>   };
>   struct rcar_du_plane_state state = {
>   .state = {

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH v3 1/3] v4l: vsp1: Postpone frame end handling in event of display list race

2017-03-05 Thread Laurent Pinchart
Hi Kieran,

Thank you for the patch.

On Sunday 05 Mar 2017 16:00:02 Kieran Bingham wrote:
> If we try to commit the display list while an update is pending, we have
> missed our opportunity. The display list manager will hold the commit
> until the next interrupt.
> 
> In this event, we skip the pipeline completion callback handler so that
> the pipeline will not mistakenly report frame completion to the user.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/vsp1/vsp1_dl.c   | 19 +--
>  drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
>  drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
>  3 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index b9e5027778ff..f449ca689554
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -562,9 +562,19 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager
> *dlm) spin_unlock(&dlm->lock);
>  }
> 
> -void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> +/**
> + * vsp1_dlm_irq_frame_end - Display list handler for the frame end
> interrupt + * @dlm: the display list manager
> + *
> + * Return true if the previous display list has completed at frame end, or
> false + * if it has been delayed by one frame because the display list
> commit raced + * with the frame end interrupt. The function always returns
> true in header mode + * as display list processing is then not continuous
> and races never occur. + */
> +bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
>  {
>   struct vsp1_device *vsp1 = dlm->vsp1;
> + bool completed = false;
> 
>   spin_lock(&dlm->lock);
> 
> @@ -576,8 +586,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager
> *dlm) * perform any operation as there can't be any new display list queued
> * in that case.
>*/
> - if (dlm->mode == VSP1_DL_MODE_HEADER)
> + if (dlm->mode == VSP1_DL_MODE_HEADER) {
> + completed = true;
>   goto done;
> + }
> 
>   /*
>* The UPD bit set indicates that the commit operation raced with the
> @@ -597,6 +609,7 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> if (dlm->queued) {
>   dlm->active = dlm->queued;
>   dlm->queued = NULL;
> + completed = true;
>   }
> 
>   /*
> @@ -619,6 +632,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> 
>  done:
>   spin_unlock(&dlm->lock);
> +
> + return completed;
>  }
> 
>  /* Hardware Setup */
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
> b/drivers/media/platform/vsp1/vsp1_dl.h index 7131aa3c5978..6ec1380a10af
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.h
> +++ b/drivers/media/platform/vsp1/vsp1_dl.h
> @@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device
> *vsp1, void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
>  void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
>  void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
> -void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
> +bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
> 
>  struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
>  void vsp1_dl_list_put(struct vsp1_dl_list *dl);
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
> b/drivers/media/platform/vsp1/vsp1_pipe.c index 35364f594e19..d15327701ad8
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> @@ -304,10 +304,21 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
> 
>  void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
>  {
> + bool completed;
> +
>   if (pipe == NULL)
>   return;
> 
> - vsp1_dlm_irq_frame_end(pipe->output->dlm);
> + completed = vsp1_dlm_irq_frame_end(pipe->output->dlm);
> + if (!completed) {
> + /*
> +  * If the DL commit raced with the frame end interrupt, the
> +  * commit ends up being postponed by one frame. Return
> +  * immediately without calling the pipeline's frame end 
handler
> +  * or incrementing the sequence number.
> +  */
> + return;
> + }
> 
>   if (pipe->frame_end)
>   pipe->frame_end(pipe);

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH v3 2/3] v4l: vsp1: Extend VSP1 module API to allow DRM callbacks

2017-03-05 Thread Laurent Pinchart
Hi Kieran,

Thank you for the patch.

On Sunday 05 Mar 2017 16:00:03 Kieran Bingham wrote:
> To be able to perform page flips in DRM without flicker we need to be
> able to notify the rcar-du module when the VSP has completed its
> processing.
> 
> We must not have bidirectional dependencies on the two components to
> maintain support for loadable modules, thus we extend the API to allow
> a callback to be registered within the VSP DRM interface.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 17 +
>  drivers/media/platform/vsp1/vsp1_drm.h | 11 +++
>  include/media/vsp1.h   | 13 +
>  3 files changed, 41 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c index 4ee437c7ff0c..d93bf7d3a39e
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -37,6 +37,14 @@ void vsp1_drm_display_start(struct vsp1_device *vsp1)
>   vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
>  }
> 
> +static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
> +{
> + struct vsp1_drm *drm = to_vsp1_drm(pipe);
> +
> + if (drm->du_complete)
> + drm->du_complete(drm->du_private);
> +}
> +
>  /* 
>   * DU Driver API
>   */
> @@ -96,6 +104,7 @@ int vsp1_du_setup_lif(struct device *dev, const struct
> vsp1_du_lif_config *cfg) }
> 
>   pipe->num_inputs = 0;
> + vsp1->drm->du_complete = NULL;
> 
>   vsp1_dlm_reset(pipe->output->dlm);
>   vsp1_device_put(vsp1);
> @@ -200,6 +209,13 @@ int vsp1_du_setup_lif(struct device *dev, const struct
> vsp1_du_lif_config *cfg) if (ret < 0)
>   return ret;
> 
> + /*
> +  * Register a callback to allow us to notify the DRM framework of 
frame

s/framework/driver/

> +  * completion events.
> +  */
> + vsp1->drm->du_complete = cfg->callback;
> + vsp1->drm->du_private = cfg->callback_data;
> +
>   ret = media_pipeline_start(&pipe->output->entity.subdev.entity,
> &pipe->pipe);
>   if (ret < 0) {
> @@ -607,6 +623,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
>   pipe->lif = &vsp1->lif->entity;
>   pipe->output = vsp1->wpf[0];
>   pipe->output->pipe = pipe;
> + pipe->frame_end = vsp1_du_pipeline_frame_end;
> 
>   return 0;
>  }
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
> b/drivers/media/platform/vsp1/vsp1_drm.h index c8d2f88fc483..3de2095cb0ce
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.h
> +++ b/drivers/media/platform/vsp1/vsp1_drm.h
> @@ -23,6 +23,8 @@
>   * @num_inputs: number of active pipeline inputs at the beginning of an
> update
>   * @inputs: source crop rectangle, destination compose rectangle and
> z-order
>   *   position for every input
> + * @du_complete: frame completion callback for the DU driver (optional)
> + * @du_private: data to be passed to the du_complete callback
>   */
>  struct vsp1_drm {
>   struct vsp1_pipeline pipe;
> @@ -33,8 +35,17 @@ struct vsp1_drm {
>   struct v4l2_rect compose;
>   unsigned int zpos;
>   } inputs[VSP1_MAX_RPF];
> +
> + /* Frame syncronisation */

s/syncronisation/synchronisation/

> + void (*du_complete)(void *);
> + void *du_private;
>  };
> 
> +static inline struct vsp1_drm *to_vsp1_drm(struct vsp1_pipeline *pipe)
> +{
> + return container_of(pipe, struct vsp1_drm, pipe);
> +}
> +
>  int vsp1_drm_init(struct vsp1_device *vsp1);
>  void vsp1_drm_cleanup(struct vsp1_device *vsp1);
>  int vsp1_drm_create_links(struct vsp1_device *vsp1);
> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> index bfc701f04f3f..d59d0adf560d 100644
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -20,9 +20,22 @@ struct device;
> 
>  int vsp1_du_init(struct device *dev);
> 
> +/**
> + * struct vsp1_du_lif_config - VSP LIF configuration
> + * @width: output frame width
> + * @height: output frame height
> + * @callback: frame completion callback function (optional)
> + * @callback_data: data to be passed to the frame completion callback
> + *
> + * When the optional callback is provided to the VSP1, the VSP1 must
> guarantee
> + * that one completion callback is performed after every
> vsp1_du_atomic_flush()

This paragraph should be part of the @callback documentation. I would phrase 
it as

 * @callback: frame completion callback function (optional). When a callback
 *is provided, the VSP driver guarantees that it will be called
 *once and only once for each vsp1_du_atomic_flush() call.

With this fixed,

Reviewed-by: Laurent Pinchart 

If you're fine with the above changes there's no need to resubmit, I'll fix 
when applying the patch.

> + */
>  struct vsp1_du_lif_config {
>   unsigned int width;
>

[Bug 100068] LLVM ERROR: Cannot select: intrinsic %llvm.amdgcn.buffer.load.format

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100068

--- Comment #2 from Wojciech Pyczak  ---
Created attachment 130081
  --> https://bugs.freedesktop.org/attachment.cgi?id=130081&action=edit
Unigine Heaven output

Looks like it's not all, glxgears works fine though.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100071] [Regression] Tomb Raider: TressFX broken with recent LLVM

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100071

Bug ID: 100071
   Summary: [Regression] Tomb Raider: TressFX broken with recent
LLVM
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gr.mue...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 130080
  --> https://bugs.freedesktop.org/attachment.cgi?id=130080&action=edit
Lara's broken hair...

This weeks LLVM update somehow broke the rendering of TressFX in Tomb Raider.
Radeon HD 7970, Mesa Git

I use precompiled packages from arch repo.

For me last working: lib32-llvm-libs-svn-5.0.0svn_r296294
First time error appeared in: lib32-llvm-libs-svn-5.0.0svn_r296961

No other packages in between, sorry.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=97988

--- Comment #29 from Kai  ---
Ping.

@nha: is there any progress on this? Or more specifically the LLVM change
D26348?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100068] LLVM ERROR: Cannot select: intrinsic %llvm.amdgcn.buffer.load.format

2017-03-05 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100068

Dave Airlie  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Dave Airlie  ---
Fixed thanks for testing/patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >