date:20170920

RE: [PATCH 1/4] drm/amd/powerplay: Cocci spatch "alloc_cast"

2017-09-20 Thread Deucher, Alexander

> -Original Message-
> From: Thomas Meyer [mailto:tho...@m3y3r.de]
> Sent: Thursday, September 21, 2017 2:34 AM
> To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH 1/4] drm/amd/powerplay: Cocci spatch "alloc_cast"
> 
> Remove casting the values returned by memory allocation functions like
> kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc."
> Found by coccinelle spatch "api/alloc/alloc_cast.cocci"
> 
> Signed-off-by: Thomas Meyer 
> ---
> 
> diff -u -p
> a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> @@ -291,7 +291,7 @@ static int get_mm_clock_voltage_table(
>   table_size = sizeof(uint32_t) +
> 
>   sizeof(phm_ppt_v1_mm_clock_voltage_dependency_record) *
>   mm_dependency_table->ucNumEntries;
> - mm_table = (phm_ppt_v1_mm_clock_voltage_dependency_table
> *)
> + mm_table =
>   kzalloc(table_size, GFP_KERNEL);

Please fix up the whitespace here and below.

Alex

> 
>   if (!mm_table)
> @@ -519,7 +519,7 @@ static int get_socclk_voltage_dependency
> 
>   sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
>   clk_dep_table->ucNumEntries;
> 
> - clk_table = (phm_ppt_v1_clock_voltage_dependency_table *)
> + clk_table =
>   kzalloc(table_size, GFP_KERNEL);
> 
>   if (!clk_table)
> @@ -554,7 +554,7 @@ static int get_mclk_voltage_dependency_t
> 
>   sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
>   mclk_dep_table->ucNumEntries;
> 
> - mclk_table = (phm_ppt_v1_clock_voltage_dependency_table *)
> + mclk_table =
>   kzalloc(table_size, GFP_KERNEL);
> 
>   if (!mclk_table)
> @@ -596,7 +596,7 @@ static int get_gfxclk_voltage_dependency
> 
>   sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
>   clk_dep_table->ucNumEntries;
> 
> - clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *)
> + clk_table =
>   kzalloc(table_size, GFP_KERNEL);
> 
>   if (!clk_table)
> @@ -663,7 +663,7 @@ static int get_pix_clk_voltage_dependenc
> 
>   sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
>   clk_dep_table->ucNumEntries;
> 
> - clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *)
> + clk_table =
>   kzalloc(table_size, GFP_KERNEL);
> 
>   if (!clk_table)
> @@ -728,7 +728,7 @@ static int get_dcefclk_voltage_dependenc
> 
>   sizeof(phm_ppt_v1_clock_voltage_dependency_record) *
>   num_entries;
> 
> - clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *)
> + clk_table =
>   kzalloc(table_size, GFP_KERNEL);
> 
>   if (!clk_table)
> @@ -772,7 +772,7 @@ static int get_pcie_table(struct pp_hwmg
>   sizeof(struct phm_ppt_v1_pcie_record) *
>   atom_pcie_table->ucNumEntries;
> 
> - pcie_table = (struct phm_ppt_v1_pcie_table *)
> + pcie_table =
>   kzalloc(table_size, GFP_KERNEL);
> 
>   if (!pcie_table)
> @@ -1026,7 +1026,7 @@ static int get_vddc_lookup_table(
>   table_size = sizeof(uint32_t) +
>   sizeof(phm_ppt_v1_voltage_lookup_record) *
> max_levels;
> 
> - table = (phm_ppt_v1_voltage_lookup_table *)
> + table =
>   kzalloc(table_size, GFP_KERNEL);
> 
>   if (NULL == table)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=99710

--- Comment #12 from Sandeep  ---
Well, to clarify, I have been using the AMDGPU driver for the past year, not
the Radeon driver. I've only faced this issue since the past 2 months, never
had the problem earlier - so I don't think the other bug applies. Also, the
devs say old firmware is the culprit there, but I run Arch Linux, and the
linux-firmware has whatever's present on 7th September of this year - so I
doubt the firmware is out of date.

I did test 4.10.6, but Left 4 Dead 2 crashed less than a second after loading a
level - this is weird, since I did run 4.10.x kernels without any problems.
Makes me think the problem lies elsewhere. 

Will see if I can figure out what's causing this.

-- 
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/rockchip: Fix uninitialized use of ret

2017-09-20 Thread Mark yao


On 2017年09月21日 08:13, Sean Paul wrote:

If there are no children for lvds, ret is used uninitialized. This patch
initializes ret and returns an error if the port has no children.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Cc: Mark Yao 
Cc: Heiko Stuebner 
Cc: Sandy Huang 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/rockchip/rockchip_lvds.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index c5fbe533796c..0ce6205d8d80 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -346,7 +346,7 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
struct drm_connector *connector;
struct device_node *remote = NULL;
struct device_node  *port, *endpoint;
-   int ret;
+   int ret = 0, child_count = 0;
const char *name;
u32 endpoint_id;
  
@@ -358,13 +358,18 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,

return -EINVAL;
}
for_each_child_of_node(port, endpoint) {
+   child_count++;
of_property_read_u32(endpoint, "reg", &endpoint_id);
ret = drm_of_find_panel_or_bridge(dev->of_node, 1, endpoint_id,
  &lvds->panel, &lvds->bridge);
if (!ret)
break;
}
-   if (ret) {
+   if (!child_count) {
+   DRM_DEV_ERROR(dev, "lvds port does not have any children\n");
+   ret  = -EINVAL;


Double space on "ret  =", except this, looks good for me.
Reviewed-by: Mark Yao 


+   goto err_put_port;
+   } else if (ret) {
DRM_DEV_ERROR(dev, "failed to find panel and bridge node\n");
ret  = -EPROBE_DEFER;
goto err_put_port;



--
Ｍark Yao

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

Re: [PATCH 7/7] drm/rockchip: Cocci spatch "vma_pages"

2017-09-20 Thread Mark yao


On 2017年09月21日 06:29, Thomas Meyer wrote:

Use vma_pages function on vma object instead of explicit computation.
Found by coccinelle spatch "api/vma_pages.cocci"

Signed-off-by: Thomas Meyer 
---

Looks good for me:
Acked-by: Mark Yao 



diff -u -p a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -220,7 +220,7 @@ static int rockchip_drm_gem_object_mmap_
  {
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
unsigned int i, count = obj->size >> PAGE_SHIFT;
-   unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+   unsigned long user_count = vma_pages(vma);
unsigned long uaddr = vma->vm_start;
unsigned long offset = vma->vm_pgoff;
unsigned long end = user_count + offset;

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip





--
Ｍark Yao


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

[PATCH] drm/rockchip: Fix uninitialized use of ret

2017-09-20 Thread Sean Paul

If there are no children for lvds, ret is used uninitialized. This patch
initializes ret and returns an error if the port has no children.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Cc: Mark Yao 
Cc: Heiko Stuebner 
Cc: Sandy Huang 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index c5fbe533796c..0ce6205d8d80 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -346,7 +346,7 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
struct drm_connector *connector;
struct device_node *remote = NULL;
struct device_node  *port, *endpoint;
-   int ret;
+   int ret = 0, child_count = 0;
const char *name;
u32 endpoint_id;
 
@@ -358,13 +358,18 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
return -EINVAL;
}
for_each_child_of_node(port, endpoint) {
+   child_count++;
of_property_read_u32(endpoint, "reg", &endpoint_id);
ret = drm_of_find_panel_or_bridge(dev->of_node, 1, endpoint_id,
  &lvds->panel, &lvds->bridge);
if (!ret)
break;
}
-   if (ret) {
+   if (!child_count) {
+   DRM_DEV_ERROR(dev, "lvds port does not have any children\n");
+   ret  = -EINVAL;
+   goto err_put_port;
+   } else if (ret) {
DRM_DEV_ERROR(dev, "failed to find panel and bridge node\n");
ret  = -EPROBE_DEFER;
goto err_put_port;
-- 
2.14.1.821.g8fa685d3b7-goog

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

Re: [PATCH libdrm] Android: move libraries to /vendor

2017-09-20 Thread Sean Paul

On Tue, Sep 19, 2017 at 04:59:59PM -0500, Rob Herring wrote:
> As part of Treble project in Android O, all the device specific files have
> to be located in a separate vendor partition. This is done by setting
> LOCAL_PROPRIETARY_MODULE (the name is misleading). This change will not
> break existing platforms without a vendor partition as it will just move
> files to /system/vendor.
> 
> Signed-off-by: Rob Herring 

Reviewed-by: Sean Paul 

> ---
>  Android.mk| 1 +
>  amdgpu/Android.mk | 3 ++-
>  data/Android.mk   | 3 ++-
>  etnaviv/Android.mk| 1 +
>  freedreno/Android.mk  | 1 +
>  intel/Android.mk  | 1 +
>  nouveau/Android.mk| 1 +
>  radeon/Android.mk | 1 +
>  tests/modetest/Android.mk | 1 +
>  tests/proptest/Android.mk | 1 +
>  10 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/Android.mk b/Android.mk
> index 292be2360263..8b2abba89ba1 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -49,6 +49,7 @@ include $(BUILD_STATIC_LIBRARY)
>  # Shared library for the device
>  include $(CLEAR_VARS)
>  LOCAL_MODULE := libdrm
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SRC_FILES := $(LIBDRM_FILES)
>  LOCAL_EXPORT_C_INCLUDE_DIRS := \
> diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
> index 88d376511730..3a897f01c1fa 100644
> --- a/amdgpu/Android.mk
> +++ b/amdgpu/Android.mk
> @@ -5,13 +5,14 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>  
>  LOCAL_MODULE := libdrm_amdgpu
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SHARED_LIBRARIES := libdrm
>  
>  LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
>  
>  LOCAL_CFLAGS := \
> - -DAMDGPU_ASIC_ID_TABLE=\"/system/etc/hwdata/amdgpu.ids\" \
> + -DAMDGPU_ASIC_ID_TABLE=\"/vendor/etc/hwdata/amdgpu.ids\" \
>   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(shell egrep -ci 
> '^[0-9a-f]{4},.*[0-9a-f]+,' $(LIBDRM_TOP)/data/amdgpu.ids)
>  
>  LOCAL_REQUIRED_MODULES := amdgpu.ids
> diff --git a/data/Android.mk b/data/Android.mk
> index 3c1fd7c62fb9..62013f0cb46b 100644
> --- a/data/Android.mk
> +++ b/data/Android.mk
> @@ -4,6 +4,7 @@ include $(CLEAR_VARS)
>  LOCAL_MODULE := amdgpu.ids
>  LOCAL_MODULE_TAGS := optional
>  LOCAL_MODULE_CLASS := ETC
> -LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/hwdata
> +LOCAL_PROPRIETARY_MODULE := true
> +LOCAL_MODULE_RELATIVE_PATH := hwdata
>  LOCAL_SRC_FILES := $(LOCAL_MODULE)
>  include $(BUILD_PREBUILT)
> diff --git a/etnaviv/Android.mk b/etnaviv/Android.mk
> index 390f9a98924d..9b32deb833a1 100644
> --- a/etnaviv/Android.mk
> +++ b/etnaviv/Android.mk
> @@ -5,6 +5,7 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>  
>  LOCAL_MODULE := libdrm_etnaviv
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SHARED_LIBRARIES := libdrm
>  
> diff --git a/freedreno/Android.mk b/freedreno/Android.mk
> index 2b582aeded74..c31101c9b99b 100644
> --- a/freedreno/Android.mk
> +++ b/freedreno/Android.mk
> @@ -5,6 +5,7 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>  
>  LOCAL_MODULE := libdrm_freedreno
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SHARED_LIBRARIES := libdrm
>  
> diff --git a/intel/Android.mk b/intel/Android.mk
> index 5407ff3ed208..457eafe199f2 100644
> --- a/intel/Android.mk
> +++ b/intel/Android.mk
> @@ -28,6 +28,7 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>  
>  LOCAL_MODULE := libdrm_intel
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
>  
> diff --git a/nouveau/Android.mk b/nouveau/Android.mk
> index b430af4fdd70..f58386fcb976 100644
> --- a/nouveau/Android.mk
> +++ b/nouveau/Android.mk
> @@ -5,6 +5,7 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>  
>  LOCAL_MODULE := libdrm_nouveau
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SHARED_LIBRARIES := libdrm
>  
> diff --git a/radeon/Android.mk b/radeon/Android.mk
> index 71040dab79b8..b770728e67c6 100644
> --- a/radeon/Android.mk
> +++ b/radeon/Android.mk
> @@ -5,6 +5,7 @@ include $(CLEAR_VARS)
>  include $(LOCAL_PATH)/Makefile.sources
>  
>  LOCAL_MODULE := libdrm_radeon
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SHARED_LIBRARIES := libdrm
>  
> diff --git a/tests/modetest/Android.mk b/tests/modetest/Android.mk
> index c1a71fd9702a..80c806afd765 100644
> --- a/tests/modetest/Android.mk
> +++ b/tests/modetest/Android.mk
> @@ -6,6 +6,7 @@ include $(LOCAL_PATH)/Makefile.sources
>  LOCAL_SRC_FILES := $(MODETEST_FILES)
>  
>  LOCAL_MODULE := modetest
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_STATIC_LIBRARIES := libdrm_util
> diff --git a/tests/proptest/Android.mk b/tests/proptest/Android.mk
> index 91a590fc9fca..b6e1f5ef1fb5 100644
> --- a/tests/proptest/Android.mk
> +++ b/tests/proptest/Android.mk
> @@ -6,6 +6,7 @@ include $(LOCAL_PATH)/Makefile.sources
>  LOCAL_SRC_FILES := $(PROPTEST_FILES)
>  
>  LOCAL_MODULE := proptest
> +LOCAL_PROPRIETARY_MODULE := true
>  
>  LOCAL_SHARED_LIBRARIES := libdrm
>  LOCAL_STATIC

Re: [PATCH] drm: Try to document legacy DPMS uapi a bit better

2017-09-20 Thread Sean Paul

On Wed, Sep 20, 2017 at 3:59 PM, Daniel Vetter  wrote:
> Due to inconsistency of how various legacy drivers implemented DPMS
> the DPMS uabi has a lot of quirks. Atomic standardizes this, but
> drivers using the DPMS support can't rely on that since legacy drivers
> still exist.
>
> Laurent asked for this.
>
> v2:
> Improve commit message and explain that DPMS doesn't really exist for
> the atomic ioctl (it's "ACTIVE" on the CRTC instead).
>
> Text polish from Eric's review.
>
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Eric Anholt 
> Reviewed-by: Eric Anholt 

v2 is much better, IMO, thanks.

I'd recommend waiting for Laurent's R-b, but fwiw,

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_connector.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index bb2e60f5feb6..d8ca526ca4ee 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -719,6 +719,29 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   * callback. For atomic drivers the remapping to the "ACTIVE" property is
>   * implemented in the DRM core.  This is the only standard connector
>   * property that userspace can change.
> + *
> + * Note that this property cannot be set through the MODE_ATOMIC ioctl,
> + * userspace must use "ACTIVE" on the CRTC instead.
> + *
> + * WARNING:
> + *
> + * For userspace also running on legacy drivers the "DPMS" semantics are 
> a
> + * lot more complicated. First, userspace cannot rely on the "DPMS" value
> + * returned by the GETCONNECTOR actually reflecting reality, because many
> + * drivers fail to update it. For atomic drivers this is taken care of in
> + * drm_atomic_helper_update_legacy_modeset_state().
> + *
> + * The second issue is that the DPMS state is only well-defined when the
> + * connector is connected to a CRTC. In atomic the DRM core enforces that
> + * "ACTIVE" is off in such a case, no such checks exists for "DPMS".
> + *
> + * Finally, when enabling an output using the legacy SETCONFIG ioctl then
> + * "DPMS" is forced to ON. But see above, that might not be reflected in
> + * the software value on legacy drivers.
> + *
> + * Summarizing: Only set "DPMS" when the connector is known to be 
> enabled,
> + * assume that a successful SETCONFIG call also sets "DPMS" to on, and
> + * never read back the value of "DPMS" because it can be incorrect.
>   * PATH:
>   * Connector path property to identify how this sink is physically
>   * connected. Used by DP MST. This should be set by calling
> --
> 2.9.5
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Try to document legacy DPMS uapi a bit better

2017-09-20 Thread Daniel Vetter

Due to inconsistency of how various legacy drivers implemented DPMS
the DPMS uabi has a lot of quirks. Atomic standardizes this, but
drivers using the DPMS support can't rely on that since legacy drivers
still exist.

Laurent asked for this.

v2:
Improve commit message and explain that DPMS doesn't really exist for
the atomic ioctl (it's "ACTIVE" on the CRTC instead).

Text polish from Eric's review.

Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Eric Anholt 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/drm_connector.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index bb2e60f5feb6..d8ca526ca4ee 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -719,6 +719,29 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  * callback. For atomic drivers the remapping to the "ACTIVE" property is
  * implemented in the DRM core.  This is the only standard connector
  * property that userspace can change.
+ *
+ * Note that this property cannot be set through the MODE_ATOMIC ioctl,
+ * userspace must use "ACTIVE" on the CRTC instead.
+ *
+ * WARNING:
+ *
+ * For userspace also running on legacy drivers the "DPMS" semantics are a
+ * lot more complicated. First, userspace cannot rely on the "DPMS" value
+ * returned by the GETCONNECTOR actually reflecting reality, because many
+ * drivers fail to update it. For atomic drivers this is taken care of in
+ * drm_atomic_helper_update_legacy_modeset_state().
+ *
+ * The second issue is that the DPMS state is only well-defined when the
+ * connector is connected to a CRTC. In atomic the DRM core enforces that
+ * "ACTIVE" is off in such a case, no such checks exists for "DPMS".
+ *
+ * Finally, when enabling an output using the legacy SETCONFIG ioctl then
+ * "DPMS" is forced to ON. But see above, that might not be reflected in
+ * the software value on legacy drivers.
+ *
+ * Summarizing: Only set "DPMS" when the connector is known to be enabled,
+ * assume that a successful SETCONFIG call also sets "DPMS" to on, and
+ * never read back the value of "DPMS" because it can be incorrect.
  * PATH:
  * Connector path property to identify how this sink is physically
  * connected. Used by DP MST. This should be set by calling
-- 
2.9.5

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

[PATCH 1/2] drm/vc4: Reject HDMI modes with too high of clocks.

2017-09-20 Thread Eric Anholt

Peter Robinson reported issues on Fedora with 4k monitors not having
their modes filtered down to 1920x1080 on Raspberry Pi.  Hopefully
this resolves that.

Cc: Peter Robinson 
Signed-off-by: Eric Anholt 
---

Note: This is an untested patch, since I'm away from hardware
currently.

 drivers/gpu/drm/vc4/vc4_hdmi.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index fa37a1c07cf6..65826a4f208e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -694,7 +694,22 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder 
*encoder)
}
 }
 
+static enum drm_mode_status
+vc5_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
+   const struct drm_display_mode *mode)
+{
+   /* HSM clock must be 108% of the pixel clock.  Additionally,
+* the AXI clock needs to be at least 25% of pixel clock, but
+* HSM ends up being the limiting factor.
+*/
+   if (mode->clock > HSM_CLOCK_FREQ / (1000 * 108 / 100))
+   return MODE_CLOCK_HIGH;
+
+   return MODE_OK;
+}
+
 static const struct drm_encoder_helper_funcs vc4_hdmi_encoder_helper_funcs = {
+   .mode_valid = vc5_hdmi_encoder_mode_valid,
.disable = vc4_hdmi_encoder_disable,
.enable = vc4_hdmi_encoder_enable,
 };
-- 
2.14.1

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

[PATCH 2/2] drm/vc4: Update kerneldoc about CEC and power management

2017-09-20 Thread Eric Anholt

Boris had added full power management, and then Hans partially removed
it to enable CEC, so update the docs about both.

Cc: Boris Brezillon 
Cc: Hans Verkuil 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 65826a4f208e..ce18384c6be3 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -33,13 +33,9 @@
  * interconnect) bus to the encoder side for insertion into the video
  * blank regions.
  *
- * The driver's HDMI encoder does not yet support power management.
- * The HDMI encoder's power domain and the HSM/pixel clocks are kept
- * continuously running, and only the HDMI logic and packet ram are
- * powered off/on at disable/enable time.
- *
- * The driver does not yet support CEC control, though the HDMI
- * encoder block has CEC support.
+ * Note that HDMI CEC requires that the HSM clock be running even when
+ * not scanning out, so that input can be processed.  The PHY is still
+ * powered down when not scanning out, though.
  */
 
 #include 
-- 
2.14.1

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

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

2017-09-20 Thread Zhenyu Wang

On 2017.09.19 19:35:23 -0700, Joe Perches wrote:
> On Wed, 2017-09-20 at 05:46 +0800, Zhenyu Wang wrote:
> > On 2017.09.19 16:55:34 +0100, Colin King wrote:
> > > From: Colin Ian King 
> > > 
> > > An earlier fix changed the return type from find_bb_size however the
> > > integer return is being assigned to a unsigned int so the -ve error
> > > check will never be detected. Make bb_size an int to fix this.
> > > 
> > > Detected by CoverityScan CID#1456886 ("Unsigned compared against 0")
> > > 
> > > Fixes: 1e3197d6ad73 ("drm/i915/gvt: Refine error handling for 
> > > perform_bb_shadow")
> > > Signed-off-by: Colin Ian King 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> > > b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > index 2c0ccbb817dc..f41cbf664b69 100644
> > > --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> > > @@ -1628,7 +1628,7 @@ static int perform_bb_shadow(struct 
> > > parser_exec_state *s)
> > >   struct intel_shadow_bb_entry *entry_obj;
> > >   struct intel_vgpu *vgpu = s->vgpu;
> > >   unsigned long gma = 0;
> > > - uint32_t bb_size;
> > > + int bb_size;
> > >   void *dst = NULL;
> > >   int ret = 0;
> > >  
> > 
> > Applied this, thanks!
> 
> Is it possible for bb_size to be both >= 2g and valid?

Never be possible in practise and if really that big I think something
is already insane indeed.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

Re: [PATCH] drm: Try to document legacy DPMS uapi a bit better

2017-09-20 Thread Eric Anholt

Daniel Vetter  writes:

> Laurent asked for this.
>
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_connector.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index ba9f36cef68c..b458eb488128 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -720,6 +720,25 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *   callback. For atomic drivers the remapping to the "ACTIVE" property is
>   *   implemented in the DRM core.  This is the only standard connector
>   *   property that userspace can change.
> + *
> + *   WARNING:
> + *
> + *   For userspace also running on legacy drivers the "DPMS" semantics are a
> + *   lot more complicated. First, userspace cannot rely on the "DPMS" value
> + *   returned by the GETCONNECTOR actually reflecting reality, because many
> + *   drivers fail to update it. For atomic drivers this is taken care of in
> + *   drm_atomic_helper_update_legacy_modeset_state().
> + *
> + *   The second issue is that the DPMS state is only relevant when the

s/relevant/defined/ maybe?

> + *   connector is connected to a CRTC. In atomic the DRM core enforces that
> + *   "ACTIVE" is off in such a case, no such checks exists for "DPMS".

Maybe another newline here?

> + *   Finally, when enabling an output using the legacy SETCONFIG ioctl then
> + *   "DPMS" is forced to ON. But see above, that might not be reflected in
> + *   the software value.

Maybe add " on legacy drivers"?

> + *
> + *   Summarizing: Only set "DPMS" when the connector is known to be enabled,
> + *   assume that a successful SETCONFIG call also set "DPMS" to on, and never

"also sets"

> + *   read back the value of "DPMS" because it can be incorrect.

With whatever set of my suggestions you like,

Reviewed-by: Eric Anholt 


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

Re: [PATCH 1/2] drm/dp: Add defines for latency in sink

2017-09-20 Thread Rodrigo Vivi

On Wed, Sep 20, 2017 at 02:32:34PM +, vathsala nagaraju wrote:
> Add defines for dpcd register 2009 (synchronization latency
> in sink).
> 
> Cc: Rodrigo Vivi 
> CC: Puthikorn Voravootivat 
> Signed-off-by: Vathsala Nagaraju 
> ---
>  include/drm/drm_dp_helper.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 11c39f1..846004e6 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -735,6 +735,9 @@
>  # define DP_PSR_SINK_INTERNAL_ERROR 7
>  # define DP_PSR_SINK_STATE_MASK 0x07
>  
> +#define DP_SINK_SYNCHRONIZATION_LATENCY  0x2009
> +# define DP_MAX_RESYNC_FRAME_CNT_MASK0xf

where did you get that?
eDP 1.4 teels 2009h is a debug register.

> +
>  #define DP_RECEIVER_ALPM_STATUS  0x200b  /* eDP 1.4 */
>  # define DP_ALPM_LOCK_TIMEOUT_ERROR  (1 << 0)
>  
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND RFC PATCH 3/7] clk: sunxi: Add CLK_SET_RATE_PARENT flag for H3 HDMI clock

2017-09-20 Thread Jernej Skrabec

When setting the HDMI clock of H3, the PLL_VIDEO clock needs to be set.

Add CLK_SET_RATE_PARENT flag for H3 HDMI clock.

Signed-off-by: Jernej Skrabec 
Signed-off-by: Icenowy Zheng 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 7a222ff1ad0a..36224ba93f9d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -474,7 +474,7 @@ static SUNXI_CCU_GATE(avs_clk,  "avs",  
"osc24M",
 
 static const char * const hdmi_parents[] = { "pll-video" };
 static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
-0x150, 0, 4, 24, 2, BIT(31), 0);
+0x150, 0, 4, 24, 2, BIT(31), 
CLK_SET_RATE_PARENT);
 
 static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
  0x154, BIT(31), 0);
-- 
2.14.1

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

[RESEND RFC PATCH 7/7] ARM: sun8i: h3: Enable HDMI output on H3 boards

2017-09-20 Thread Jernej Skrabec

Enable HDMI output on all boards which include HDMI connector.

Signed-off-by: Jernej Skrabec 
---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 33 +
 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts   | 33 +
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts| 33 +
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts   | 33 +
 arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts| 33 +
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 33 +
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts  | 33 +
 7 files changed, 231 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index d756ff825116..52a0f954df1c 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -61,6 +61,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -103,6 +114,10 @@
};
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -126,6 +141,16 @@
status = "okay";
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
@@ -139,6 +164,10 @@
};
 };
 
+&mixer0 {
+   status = "okay";
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
@@ -212,6 +241,10 @@
status = "okay";
 };
 
+&tcon0 {
+   status = "okay";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts 
b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
index 546837ccd8af..8a4ec474f183 100644
--- a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
@@ -61,6 +61,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -100,6 +111,10 @@
};
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -115,12 +130,26 @@
status = "okay";
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
status = "okay";
 };
 
+&mixer0 {
+   status = "okay";
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
@@ -177,6 +206,10 @@
status = "okay";
 };
 
+&tcon0 {
+   status = "okay";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
index ec63d104b404..e6b551bb43e7 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
@@ -45,6 +45,21 @@
 / {
model = "FriendlyArm NanoPi M1";
compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
+
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+};
+
+&de {
+   status = "okay";
 };
 
 &ehci1 {
@@ -55,6 +70,20 @@
status = "okay";
 };
 
+&hdmi {
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
+&mixer0 {
+   status = "okay";
+};
+
 &ohci1 {
status = "okay";
 };
@@ -62,3 +91,7 @@
 &ohci2 {
status = "okay";
 };
+
+&tcon0 {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 17cdeae19c6f..586181c4ce8b 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -62,6 +62,17 @@
stdout-path = "serial0:115200n8";

[RESEND RFC PATCH 5/7] drm: sun4i: Add a glue for the DesignWare HDMI controller in H3

2017-09-20 Thread Jernej Skrabec

Allwinner H3 features DesignWare HDMI Transmitter paired with custom
PHY.

Add a glue driver for it.

For now, only video and CEC are supported. Audio will be supported at
a later time.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/Kconfig |   9 +
 drivers/gpu/drm/sun4i/Makefile|   1 +
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 500 ++
 3 files changed, 510 insertions(+)
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 06f05302ee75..589502ffe31a 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -40,6 +40,15 @@ config DRM_SUN4I_BACKEND
  do some alpha blending and feed graphics to TCON. If M is
  selected the module will be called sun4i-backend.
 
+config DRM_SUN8I_DW_HDMI
+   tristate "Support for Allwinner version of DesignWare HDMI"
+   depends on DRM_SUN4I
+   select DRM_DW_HDMI
+   help
+ Choose this option if you have an Allwinner SoC with the
+ DesignWare HDMI controller with custom HDMI PHY. If M is
+ selected the module will be called sun8i_dw_hdmi.
+
 config DRM_SUN8I_MIXER
tristate "Support for Allwinner Display Engine 2.0 Mixer"
default MACH_SUN8I
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 43c753cafc88..9c56173bf140 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_DRM_SUN4I)   += sun4i_tv.o
 obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
 obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
 obj-$(CONFIG_DRM_SUN8I_MIXER)  += sun8i-mixer.o
+obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i_dw_hdmi.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
new file mode 100644
index ..65db3e10e311
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -0,0 +1,500 @@
+/*
+ * Copyright (c) 2017, Jernej Skrabec 
+ *
+ * Based on hdmi_bsp_sun8iw7.c which is:
+ * Copyright (c) 2016 Allwinnertech Co., Ltd.
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun4i_crtc.h"
+#include "sun4i_tcon.h"
+
+#define SUN8I_HDMI_PHY_REG_POL 0x
+
+#define SUN8I_HDMI_PHY_REG_READ_EN 0x0010
+#define SUN8I_HDMI_PHY_REG_READ_EN_MAGIC   0x54524545
+
+#define SUN8I_HDMI_PHY_REG_UNSCRAMBLE  0x0014
+#define SUN8I_HDMI_PHY_REG_UNSCRAMBLE_MAGIC0x42494E47
+
+#define SUN8I_HDMI_PHY_REG_CTRL0x0020
+#define SUN8I_HDMI_PHY_REG_UNK10x0024
+#define SUN8I_HDMI_PHY_REG_UNK20x0028
+#define SUN8I_HDMI_PHY_REG_PLL 0x002c
+#define SUN8I_HDMI_PHY_REG_CLK 0x0030
+#define SUN8I_HDMI_PHY_REG_UNK30x0034
+
+#define SUN8I_HDMI_PHY_REG_STATUS  0x0038
+#define SUN8I_HDMI_PHY_REG_STATUS_READYBIT(7)
+#define SUN8I_HDMI_PHY_REG_STATUS_HPD  BIT(19)
+
+#define SUN8I_HDMI_PHY_REG_CEC 0x003c
+
+#define to_sun8i_dw_hdmi(x)container_of(x, struct sun8i_dw_hdmi, x)
+#define set_bits(p, v) writel(readl(p) | (v), p)
+
+struct sun8i_dw_hdmi {
+   struct clk *clk_ahb;
+   struct clk *clk_ddc;
+   struct clk *clk_sfr;
+   struct device *dev;
+   struct drm_encoder encoder;
+   void __iomem *phy_base;
+   struct dw_hdmi_plat_data plat_data;
+   struct reset_control *rst_ddc;
+   struct reset_control *rst_hdmi;
+};
+
+static u32 sun8i_dw_hdmi_get_divider(int clk_khz)
+{
+   /*
+* Due to missing documentation of HDMI PHY, we know correct
+* settings only for following four PHY dividers. Select one
+* based on pixel clock.
+*/
+   if (clk_khz <= 27000)
+   return 11;
+   else if (clk_khz <= 74250)
+   return 4;
+   else if (clk_khz <= 148500)
+   return 2;
+   else
+   return 1;
+}
+
+static void sun8i_dw_hdmi_encoder_disable(struct drm_encoder *encoder)
+{
+   struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
+   struct sun4i_tcon *tcon = crtc->tcon;
+
+   DRM_DEBUG_DRIVER("Disabling HDMI Output\n");
+
+   sun4i_tcon_channel_disable(tcon, 1);
+}
+
+static void sun8i_dw_hdmi_encoder_enable(struct drm_encoder *encoder)
+{
+   struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
+   struct sun4i_tcon *tcon = crtc->tcon;
+
+   DRM_DEBUG_DRIVER("Enabling HDMI Output\n");
+
+   sun4i_tcon_channel_enable(tcon, 1);
+}
+
+static void sun8i_dw_hdmi_encoder

[RESEND RFC PATCH 0/7] sun8i H3 HDMI glue driver for DW HDMI

2017-09-20 Thread Jernej Skrabec

[added media mailing list due to CEC question]

This patch series adds a HDMI glue driver for Allwinner H3 SoC. For now, only
video and CEC functionality is supported. Audio needs more tweaks.

Series is based on the H3 DE2 patch series available on mailing list:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/522697.html
(ignore patches marked with [NOT FOR REVIEW NOW] tag)

Patch 1 adds support for polling plug detection since custom PHY used here
doesn't support HPD interrupt.

Patch 2 enables overflow workaround for v1.32a. This HDMI controller exhibits
same issues as HDMI controller used in iMX6 SoCs.

Patch 3 adds CLK_SET_RATE_PARENT to hdmi clock.

Patch 4 adds dt bindings documentation.

Patch 5 adds actual H3 HDMI glue driver.

Patch 6 and 7 add HDMI node to DT and enable it where needed.

Allwinner used DW HDMI controller in a non standard way:
- register offsets obfuscation layer, which can fortunately be turned off
- register read lock, which has to be disabled by magic number
- custom PHY, which have to be initialized before DW HDMI controller
- non standard clocks
- no HPD interrupt

Because of that, I have two questions:
- Since HPD have to be polled, is it enough just to enable poll mode? I'm
  mainly concerned about invalidating CEC address here.
- PHY has to be initialized before DW HDMI controller to disable offset
  obfuscation and read lock among other things. This means that all clocks have
  to be enabled in glue driver. This poses a problem, since when using
  component model, dw-hdmi bridge uses drvdata for it's own private data and
  prevents glue layer to pass a pointer to unbind function, where clocks should
  be disabled. I noticed same issue in meson DW HDMI glue driver, where clocks
  are also not disabled when unbind callback is called. I noticed that when H3
  SoC is shutdown, HDMI output is still enabled and lastest image is shown on
  monitor until it is unplugged from power supply. Is there any simple solution
  to this?

Chen-Yu,
TL Lim was unable to obtain any answer from Allwinner about HDMI clocks. I think
it is safe to assume that divider in HDMI clock doesn't have any effect.

Branch based on linux-next from 1. September with integrated patches is
available here:
https://github.com/jernejsk/linux-1/tree/h3_hdmi_rfc

Some additonal info about H3 HDMI:
https://linux-sunxi.org/DWC_HDMI_Controller

Thanks to Jens Kuske, who figured out that it is actually DW HDMI controller
and mapped scrambled register offsets to original ones.

Icenowy Zheng (1):
  ARM: sun8i: h3: Add DesignWare HDMI controller node

Jernej Skrabec (6):
  drm: bridge: Enable polling hpd event in dw_hdmi
  drm: bridge: Enable workaround in dw_hdmi for v1.32a
  clk: sunxi: Add CLK_SET_RATE_PARENT flag for H3 HDMI clock
  dt-bindings: Document Allwinner DWC HDMI TX node
  drm: sun4i: Add a glue for the DesignWare HDMI controller in H3
  ARM: sun8i: h3: Enable HDMI output on H3 boards

 .../bindings/display/sunxi/sun4i-drm.txt   | 158 ++-
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  33 ++
 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts  |  33 ++
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts   |  33 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  33 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   |  33 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-one.dts|  33 ++
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts |  33 ++
 arch/arm/boot/dts/sun8i-h3.dtsi|   5 +
 arch/arm/boot/dts/sunxi-h3-h5.dtsi |  36 ++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c|   2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  14 +-
 drivers/gpu/drm/sun4i/Kconfig  |   9 +
 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c  | 500 +
 15 files changed, 950 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c

-- 
2.14.1

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

[RESEND RFC PATCH 1/7] drm: bridge: Enable polling hpd event in dw_hdmi

2017-09-20 Thread Jernej Skrabec

Some custom phys don't support hpd interrupts. Add support for polling
such events.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..09cb5a3e4c71 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1954,7 +1954,11 @@ static int dw_hdmi_bridge_attach(struct drm_bridge 
*bridge)
struct drm_connector *connector = &hdmi->connector;
 
connector->interlace_allowed = 1;
-   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   if (hdmi->phy.ops->setup_hpd)
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   else
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+   DRM_CONNECTOR_POLL_DISCONNECT;
 
drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
 
-- 
2.14.1

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

[RESEND PATCH 1/2] drm/armada: Replace drm_gem_object_reference/unreference() with _get/put()

2017-09-20 Thread Haneen Mohammed

This patch replace instances of drm_gem_object_reference/unreference with
*_get/put() suffixes, because get/put is shorter and consistent with the
kernel use of *_get/put() suffixes.
This was done with the following Coccinelle script:

@r1@
expression e;
@@

(
-drm_gem_object_reference(e);
+drm_gem_object_get(e);
|
-drm_gem_object_unreference(e);
+drm_gem_object_put(e);
|
-drm_gem_object_unreference_unlocked(e);
+drm_gem_object_put_unlocked(e);
)

Signed-off-by: Haneen Mohammed 
---
 drivers/gpu/drm/armada/armada_crtc.c  |  8 
 drivers/gpu/drm/armada/armada_fb.c|  8 
 drivers/gpu/drm/armada/armada_fbdev.c |  6 +++---
 drivers/gpu/drm/armada/armada_gem.c   | 14 +++---
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 2a4d163..381dfa1 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -947,13 +947,13 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc 
*crtc,
 
/* Must be a kernel-mapped object */
if (!obj->addr) {
-   drm_gem_object_unreference_unlocked(&obj->obj);
+   drm_gem_object_put_unlocked(&obj->obj);
return -EINVAL;
}
 
if (obj->obj.size < w * h * 4) {
DRM_ERROR("buffer is too small\n");
-   drm_gem_object_unreference_unlocked(&obj->obj);
+   drm_gem_object_put_unlocked(&obj->obj);
return -ENOMEM;
}
}
@@ -961,7 +961,7 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc *crtc,
if (dcrtc->cursor_obj) {
dcrtc->cursor_obj->update = NULL;
dcrtc->cursor_obj->update_data = NULL;
-   drm_gem_object_unreference_unlocked(&dcrtc->cursor_obj->obj);
+   drm_gem_object_put_unlocked(&dcrtc->cursor_obj->obj);
}
dcrtc->cursor_obj = obj;
dcrtc->cursor_w = w;
@@ -997,7 +997,7 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
struct armada_private *priv = crtc->dev->dev_private;
 
if (dcrtc->cursor_obj)
-   drm_gem_object_unreference_unlocked(&dcrtc->cursor_obj->obj);
+   drm_gem_object_put_unlocked(&dcrtc->cursor_obj->obj);
 
priv->dcrtc[dcrtc->num] = NULL;
drm_crtc_cleanup(&dcrtc->crtc);
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index 92e6b08..51839c1 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -18,7 +18,7 @@ static void armada_fb_destroy(struct drm_framebuffer *fb)
struct armada_framebuffer *dfb = drm_fb_to_armada_fb(fb);
 
drm_framebuffer_cleanup(&dfb->fb);
-   drm_gem_object_unreference_unlocked(&dfb->obj->obj);
+   drm_gem_object_put_unlocked(&dfb->obj->obj);
kfree(dfb);
 }
 
@@ -95,7 +95,7 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
drm_device *dev,
 * the above call, but the caller will drop their reference
 * to it.  Hence we need to take our own reference.
 */
-   drm_gem_object_reference(&obj->obj);
+   drm_gem_object_get(&obj->obj);
 
return dfb;
 }
@@ -144,12 +144,12 @@ static struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
goto err;
}
 
-   drm_gem_object_unreference_unlocked(&obj->obj);
+   drm_gem_object_put_unlocked(&obj->obj);
 
return &dfb->fb;
 
  err_unref:
-   drm_gem_object_unreference_unlocked(&obj->obj);
+   drm_gem_object_put_unlocked(&obj->obj);
  err:
DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 29c7d04..cf6bad1 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -52,13 +52,13 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
 
ret = armada_gem_linear_back(dev, obj);
if (ret) {
-   drm_gem_object_unreference_unlocked(&obj->obj);
+   drm_gem_object_put_unlocked(&obj->obj);
return ret;
}
 
ptr = armada_gem_map_object(dev, obj);
if (!ptr) {
-   drm_gem_object_unreference_unlocked(&obj->obj);
+   drm_gem_object_put_unlocked(&obj->obj);
return -ENOMEM;
}
 
@@ -68,7 +68,7 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
 * A reference is now held by the framebuffer object if
 * successful, otherwise this drops the ref for the error path.
 */
-   drm_gem_object_unreference_unlocked(&obj->obj);
+   drm_gem_object_put_unlocked(&obj->obj);
 
if (IS_ERR(dfb))
return PTR_ERR(dfb);
diff --git a/drivers/gp

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

2017-09-20 Thread John Keeping

On Tue, Sep 19, 2017 at 01:27:40PM -0700, Sean Paul wrote:
> On Tue, Sep 19, 2017 at 11:19:01AM -0700, Brian Norris wrote:
> > Hi Sean,
> > 
> > On Tue, Sep 19, 2017 at 11:00:25AM -0700, Sean Paul wrote:
> > > On Mon, Sep 18, 2017 at 05:05:33PM +0800, Nickey Yang wrote:
> > > > This patch correct Feedback divider setting:
> > > > 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> > > > 2、Due to the use of a "by 2 pre-scaler," the range of the
> > > > feedback multiplication Feedback divider is limited to even
> > > > division numbers, and Feedback divider must be greater than
> > > > 12, less than 1000.
> > > > 3、Make the previously configured Feedback divider(LSB)
> > > > factors effective
> > > > 
> > > > Signed-off-by: Nickey Yang 
> > > > ---
> > > >  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> > > > ++
> > > >  1 file changed, 54 insertions(+), 29 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > > > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > > index 9a20b9d..52698b7 100644
> > > > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > > > @@ -228,7 +228,7 @@
> > > >  #define LOW_PROGRAM_EN 0
> > > >  #define HIGH_PROGRAM_ENBIT(7)
> > > >  #define LOOP_DIV_LOW_SEL(val)  (((val) - 1) & 0x1f)
> > > > -#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
> > > > +#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0xf)
> > > >  #define PLL_LOOP_DIV_ENBIT(5)
> > > >  #define PLL_INPUT_DIV_EN   BIT(4)
> > > >  
> > > > @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi 
> > > > *dsi)
> > > > dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
> > > > dw_mipi_dsi_phy_write(dsi, 0x18, 
> > > > LOOP_DIV_LOW_SEL(dsi->feedback_div) |
> > > >  LOW_PROGRAM_EN);
> > > > +   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | 
> > > > PLL_INPUT_DIV_EN);
> > > 
> > > You do the same write 2 lines down. Are both needed? It would be nice if 
> > > the
> > > register names were also defined, so this is easier to read.
> > 
> > If I'm reading correctly, I think this is what Nickey meant by:
> > 
> > "3、Make the previously configured Feedback divider(LSB)
> > factors effective"
> > 
> > . My reading of the databook is that this step finalizes the previous
> > two writes (to test code 0x17 and 0x18).
> > 
> > Given this was buggy (?) previously, it does seem like having some extra
> > language to document this could help. Register names (or "test codes",
> > per the docs?) could help, but additionally, maybe a few more comments.
> > 
> 
> Ah, yeah, thanks for the explanation. It's not clear that this latches the 
> values above. I think register names and comments would be immensely helpful.

According to the databook, 0x19 controls whether the loop/input dividers
are derived from the hsfreqrange configuration or use the values in 0x17
and 0x18.  I can't see why writing the same value to this register
multiple times is necessary.

> > > > dw_mipi_dsi_phy_write(dsi, 0x18, 
> > > > LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
> > > >  HIGH_PROGRAM_EN);
> > > > dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | 
> > > > PLL_INPUT_DIV_EN);
> > 
> > [...]
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND RFC PATCH 6/7] ARM: sun8i: h3: Add DesignWare HDMI controller node

2017-09-20 Thread Jernej Skrabec

From: Icenowy Zheng 

The H3 SoC has a DesignWare HDMI controller with some Allwinner-specific
glue and custom PHY.

Since H3 and H5 have same HDMI controller, add related device node in
shared dtsi file.

Signed-off-by: Icenowy Zheng 
Signed-off-by: Jernej Skrabec 
---
 arch/arm/boot/dts/sun8i-h3.dtsi|  5 +
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 36 
 2 files changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75ad7b65a7fc..b01f5ac60059 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -197,6 +197,11 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+   tcon0_out_hdmi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<&hdmi_in_tcon0>;
+   };
};
};
};
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index d38282b9e5d4..28f4df82300e 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -592,6 +592,42 @@
interrupts = ;
};
 
+   hdmi: hdmi@1ee {
+   compatible = "allwinner,sun8i-h3-dw-hdmi";
+   reg = <0x01ee 0x1>,
+ <0x01ef 0x1>;
+   reg-io-width = <1>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
+<&ccu CLK_HDMI_DDC>;
+   clock-names = "iahb", "isfr", "ddc";
+   resets = <&ccu RST_BUS_HDMI0>, <&ccu RST_BUS_HDMI1>;
+   reset-names = "hdmi", "ddc";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<&tcon0_out_hdmi>;
+   };
+   };
+
+   hdmi_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
rtc: rtc@01f0 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f0 0x54>;
-- 
2.14.1

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

[RESEND RFC PATCH 4/7] dt-bindings: Document Allwinner DWC HDMI TX node

2017-09-20 Thread Jernej Skrabec

Add documentation about Allwinner DWC HDMI TX node, found in H3 SoC.

Signed-off-by: Jernej Skrabec 
---
 .../bindings/display/sunxi/sun4i-drm.txt   | 158 -
 1 file changed, 157 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 92512953943e..cb6aee5c486f 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -60,6 +60,40 @@ Required properties:
 first port should be the input endpoint. The second should be the
 output, usually to an HDMI connector.
 
+DWC HDMI TX Encoder
+-
+
+The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
+
+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: value must be one of:
+* "allwinner,sun8i-h3-dw-hdmi"
+  - reg: two pairs of base address and size of memory-mapped region, first
+for controller and second for PHY
+registers.
+  - reg-io-width: See dw_hdmi.txt. Shall be 1.
+  - interrupts: HDMI interrupt number
+  - clocks: phandles to the clocks feeding the HDMI encoder
+* iahb: the HDMI interface clock
+* isfr: the HDMI module clock
+* ddc: the HDMI ddc clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset controllers driving the encoder
+* hdmi: the reset line for the HDMI
+* ddc: the reset line for the DDC
+  - reset-names: the reset names mentioned above
+
+  - ports: A ports node with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The
+first port should be the input endpoint. The second should be the
+output, usually to an HDMI connector.
+
 TV Encoder
 --
 
@@ -255,7 +289,7 @@ Required properties:
   - allwinner,pipelines: list of phandle to the display engine
 frontends (DE 1.0) or mixers (DE 2.0) available.
 
-Example:
+Example 1:
 
 panel: panel {
compatible = "olimex,lcd-olinuxino-43-ts";
@@ -455,3 +489,125 @@ display-engine {
compatible = "allwinner,sun5i-a13-display-engine";
allwinner,pipelines = <&fe0>;
 };
+
+Example 2:
+
+connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+};
+
+de: display-engine {
+   compatible = "allwinner,sun8i-h3-display-engine";
+   allwinner,pipelines = <&mixer0>;
+};
+
+hdmi: hdmi@1ee {
+   compatible = "allwinner,h3-dw-hdmi";
+   reg = <0x01ee 0x1>,
+ <0x01ef 0x1>;
+   reg-io-width = <1>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
+<&ccu CLK_HDMI_DDC>;
+   clock-names = "iahb", "isfr", "ddc";
+   resets = <&ccu RST_BUS_HDMI0>, <&ccu RST_BUS_HDMI1>;
+   reset-names = "hdmi", "ddc";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&tcon0_out_hdmi>;
+   };
+   };
+
+   hdmi_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+   };
+   };
+};
+
+mixer0: mixer@110 {
+   compatible = "allwinner,sun8i-h3-de2-mixer0";
+   reg = <0x0110 0x10>;
+   clocks = <&display_clocks CLK_BUS_MIXER0>,
+<&display_clocks CLK_MIXER0>;
+   clock-names = "bus",
+ "mod";
+   resets = <&display_clocks RST_MIXER0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&tcon0_in_mixer0>;
+   };
+   };
+   };
+};
+
+tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun8i-h3-tcon";
+   reg = <0x01

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

2017-09-20 Thread hl




On Wednesday, September 20, 2017 06:08 PM, John Keeping wrote:

On Tue, Sep 19, 2017 at 01:27:40PM -0700, Sean Paul wrote:

On Tue, Sep 19, 2017 at 11:19:01AM -0700, Brian Norris wrote:

Hi Sean,

On Tue, Sep 19, 2017 at 11:00:25AM -0700, Sean Paul wrote:

On Mon, Sep 18, 2017 at 05:05:33PM +0800, Nickey Yang wrote:

This patch correct Feedback divider setting:
1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
2、Due to the use of a "by 2 pre-scaler," the range of the
feedback multiplication Feedback divider is limited to even
division numbers, and Feedback divider must be greater than
12, less than 1000.
3、Make the previously configured Feedback divider(LSB)
factors effective

Signed-off-by: Nickey Yang 
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 ++
  1 file changed, 54 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9a20b9d..52698b7 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -228,7 +228,7 @@
  #define LOW_PROGRAM_EN0
  #define HIGH_PROGRAM_EN   BIT(7)
  #define LOOP_DIV_LOW_SEL(val) (((val) - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0xf)
  #define PLL_LOOP_DIV_EN   BIT(5)
  #define PLL_INPUT_DIV_EN  BIT(4)
  
@@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)

dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
 LOW_PROGRAM_EN);
+   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);

You do the same write 2 lines down. Are both needed? It would be nice if the
register names were also defined, so this is easier to read.

If I'm reading correctly, I think this is what Nickey meant by:

"3、Make the previously configured Feedback divider(LSB)
factors effective"

. My reading of the databook is that this step finalizes the previous
two writes (to test code 0x17 and 0x18).

Given this was buggy (?) previously, it does seem like having some extra
language to document this could help. Register names (or "test codes",
per the docs?) could help, but additionally, maybe a few more comments.


Ah, yeah, thanks for the explanation. It's not clear that this latches the
values above. I think register names and comments would be immensely helpful.

According to the databook, 0x19 controls whether the loop/input dividers
are derived from the hsfreqrange configuration or use the values in 0x17
and 0x18.  I can't see why writing the same value to this register
multiple times is necessary.
According to databook, set 0x19 to 0x30 make the previously configured 
N(0x17) and M(0x18)
factors effective, 0x18 need to be setted by twice, since we need to set 
0x18 LSB and MSB separately,
As we test, after set 0x18 LSB, if we do not set 0x19 immediately to 
make the configrued effective,
when we set 0x18 MSB, the 0x18 LSB value will gone, and we will get 
wrong pll frequency. Anyway,

I think should add some comment here to clear that.



dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
 HIGH_PROGRAM_EN);
dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);

[...]

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



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

[RESEND RFC PATCH 2/7] drm: bridge: Enable workaround in dw_hdmi for v1.32a

2017-09-20 Thread Jernej Skrabec

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.

Allwinner never released any kind of dw hdmi or errata documentation,
so it is not clear how many iterations need to be executed. One
iteration seems to be enough.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 09cb5a3e4c71..72969240a9d4 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1631,9 +1631,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 * then write one of the FC registers several times.
 *
 * The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
 */
 
switch (hdmi->version) {
@@ -1641,6 +1642,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+   case 0x132a:
count = 1;
break;
default:
-- 
2.14.1

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

[PATCH 0/2] Handle / Release memory obtained by kasprintf

2017-09-20 Thread Arvind Yadav

Arvind Yadav (2):
  [PATCH 1/2] drm: tegra: dc: Handle return value of kasprintf
  [PATCH 2/2] drm: Release memory obtained by kasprintf

 drivers/gpu/drm/drm_crtc.c | 1 +
 drivers/gpu/drm/tegra/dc.c | 2 ++
 2 files changed, 3 insertions(+)

-- 
1.9.1

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

[RESEND PATCH 0/2] drm/armada: Replace _reference/unreference() with _get/put()

2017-09-20 Thread Haneen Mohammed

This patchset replace instances of *_reference/unreference() with *_get/put(),
because get/put is shorter and consistent with the kernel use of *_get/put 
suffixes.

Haneen Mohammed (2):
  drm/armada: Replace drm_gem_object_reference/unreference() with
_get/put()
  drm/armada: Replace drm_framebuffer_reference/unreference() with
_get/put()

 drivers/gpu/drm/armada/armada_crtc.c| 22 +++---
 drivers/gpu/drm/armada/armada_drv.c |  2 +-
 drivers/gpu/drm/armada/armada_fb.c  |  8 
 drivers/gpu/drm/armada/armada_fbdev.c   |  6 +++---
 drivers/gpu/drm/armada/armada_gem.c | 14 +++---
 drivers/gpu/drm/armada/armada_overlay.c |  4 ++--
 6 files changed, 28 insertions(+), 28 deletions(-)

-- 
2.7.4

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

[RFC PATCH v5 5/6] i2c: rcar: skip DMA if buffer is not safe

2017-09-20 Thread Wolfram Sang

This HW is prone to races, so it needs to setup new messages in irq
context. That means we can't alloc bounce buffers if a message buffer is
not DMA safe. So, in that case, simply fall back to PIO.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-rcar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 15d764afec3b29..8a2ae3e6c561c4 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -359,7 +359,7 @@ static void rcar_i2c_dma(struct rcar_i2c_priv *priv)
int len;
 
/* Do not use DMA if it's not available or for messages < 8 bytes */
-   if (IS_ERR(chan) || msg->len < 8)
+   if (IS_ERR(chan) || msg->len < 8 || !(msg->flags & I2C_M_DMA_SAFE))
return;
 
if (read) {
-- 
2.11.0

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

[RFC PATCH v5 0/6] i2c: document DMA handling and add helpers for it

2017-09-20 Thread Wolfram Sang

So, after revisiting old mail threads, taking part in a similar discussion on
the USB list, and implementing a not-convincing solution before, here is what I
cooked up to document and ease DMA handling for I2C within Linux. Please have a
look at the documentation introduced in patch 3 for details. And to make it
clear again: The stuff below is opt-in. If host drivers are not updated, they
will continue to work like before.

While the previous versions tried to magically apply bounce buffers when
needed, it became clear that detecting DMA safe buffers is too fragile. This
approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The
outcome so far is very convincing IMO. The core additions are simple and easy
to understand (makes me even think of inlining them again?). The driver changes
for the Renesas IP cores became easier to understand, too. While only a tad for
the i2c-sh_mobile driver, the situation became a LOT better for the i2c-rcar
driver. No more DMA disabling for the whole transfer in case of unsafe buffers,
we are back to per-msg handling. And the code fix is now an easy to understand
one line change. Yay!

Of course, we must now whitelist DMA safe buffers. An example for I2C_RDWR case
is in this series. It makes the i2ctransfer utility have DMA_SAFE buffers,
which is nice for testing as i2cdump will (currently) not use DMA_SAFE buffers.
My plan is to add two new calls: i2c_master_{send|receive}_dma_safe which can
be used if DMA_SAFE buffers are provided. So, drivers can simply switch to
them. Also, the buffers used within i2c_smbus_xfer_emulated() need to be
converted to be DMA_SAFE which will cover a huge bunch of use cases. The rest
is then updating drivers which can be done when needed.

As these conversions are not done yet, this patch series has RFC status. But I
already would like to get opinions on this approach, so I'll cc mailing lists
of the heavier I2C users. Please let me know what you think.

All patches have been tested with a Renesas Salvator-X board (r8a7796/M3-W).

The branch can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
renesas/topic/i2c-core-dma-rfc-v5

And big kudos to Renesas Electronics for funding this work, thank you very much!

Regards,

   Wolfram

Changes since v4:
* rebased to v4.14-rc1
* (hopefully) improved the docs to be more clear
* added basic RST syntax to the docs

This is mainly an update to agree on the docs. Missing code is still missing
and will be added in v6.

Changes since v3:
* completely redesigned


Wolfram Sang (6):
  i2c: add a message flag for DMA safe buffers
  i2c: add helpers to ease DMA handling
  i2c: add docs to clarify DMA handling
  i2c: sh_mobile: use helper to decide if DMA is useful
  i2c: rcar: skip DMA if buffer is not safe
  i2c: dev: mark RDWR buffers as DMA_SAFE

 Documentation/i2c/DMA-considerations | 58 
 drivers/i2c/busses/i2c-rcar.c|  2 +-
 drivers/i2c/busses/i2c-sh_mobile.c   |  8 +++--
 drivers/i2c/i2c-core-base.c  | 45 
 drivers/i2c/i2c-dev.c|  2 ++
 include/linux/i2c.h  |  3 ++
 include/uapi/linux/i2c.h |  3 ++
 7 files changed, 118 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/i2c/DMA-considerations

-- 
2.11.0

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

[RFC PATCH v5 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

2017-09-20 Thread Wolfram Sang

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/i2c-dev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 6f638bbc922db4..bbc7aadb4c899d 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -280,6 +280,8 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client 
*client,
res = PTR_ERR(rdwr_pa[i].buf);
break;
}
+   /* memdup_user allocates with GFP_KERNEL, so DMA is ok */
+   rdwr_pa[i].flags |= I2C_M_DMA_SAFE;
 
/*
 * If the message length is received from the slave (similar
-- 
2.11.0

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

[RFC PATCH v5 4/6] i2c: sh_mobile: use helper to decide if DMA is useful

2017-09-20 Thread Wolfram Sang

This ensures that we fall back to PIO if the message length is too small
for DMA being useful. Otherwise, we use DMA. A bounce buffer might be
applied by the helper if the original message buffer is not DMA safe.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-sh_mobile.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-sh_mobile.c 
b/drivers/i2c/busses/i2c-sh_mobile.c
index 6f2aaeb7c4fa15..b76399d8a3abd3 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -145,6 +145,7 @@ struct sh_mobile_i2c_data {
struct dma_chan *dma_rx;
struct scatterlist sg;
enum dma_data_direction dma_direction;
+   u8 *dma_buf;
 };
 
 struct sh_mobile_dt_config {
@@ -548,6 +549,8 @@ static void sh_mobile_i2c_dma_callback(void *data)
pd->pos = pd->msg->len;
pd->stop_after_dma = true;
 
+   i2c_release_dma_safe_msg_buf(pd->msg, pd->dma_buf);
+
iic_set_clr(pd, ICIC, 0, ICIC_TDMAE | ICIC_RDMAE);
 }
 
@@ -608,7 +611,7 @@ static void sh_mobile_i2c_xfer_dma(struct 
sh_mobile_i2c_data *pd)
if (IS_ERR(chan))
return;
 
-   dma_addr = dma_map_single(chan->device->dev, pd->msg->buf, 
pd->msg->len, dir);
+   dma_addr = dma_map_single(chan->device->dev, pd->dma_buf, pd->msg->len, 
dir);
if (dma_mapping_error(chan->device->dev, dma_addr)) {
dev_dbg(pd->dev, "dma map failed, using PIO\n");
return;
@@ -665,7 +668,8 @@ static int start_ch(struct sh_mobile_i2c_data *pd, struct 
i2c_msg *usr_msg,
pd->pos = -1;
pd->sr = 0;
 
-   if (pd->msg->len > 8)
+   pd->dma_buf = i2c_get_dma_safe_msg_buf(pd->msg, 8);
+   if (pd->dma_buf)
sh_mobile_i2c_xfer_dma(pd);
 
/* Enable all interrupts to begin with */
-- 
2.11.0

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

[RFC PATCH v5 1/6] i2c: add a message flag for DMA safe buffers

2017-09-20 Thread Wolfram Sang

I2C has no requirement that the buffer of a message needs to be DMA
safe. In case it is, it can now be flagged, so drivers wishing to
do DMA can use the buffer directly.

Signed-off-by: Wolfram Sang 
---
 include/uapi/linux/i2c.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
index 009e27bb9abe19..1c683cb319e4b7 100644
--- a/include/uapi/linux/i2c.h
+++ b/include/uapi/linux/i2c.h
@@ -71,6 +71,9 @@ struct i2c_msg {
 #define I2C_M_RD   0x0001  /* read data, from slave to master */
/* I2C_M_RD is guaranteed to be 0x0001! 
*/
 #define I2C_M_TEN  0x0010  /* this is a ten bit chip address */
+#define I2C_M_DMA_SAFE 0x0200  /* the buffer of this message is DMA 
safe */
+   /* makes only sense in kernelspace */
+   /* userspace buffers are copied anyway 
*/
 #define I2C_M_RECV_LEN 0x0400  /* length will be first received byte */
 #define I2C_M_NO_RD_ACK0x0800  /* if 
I2C_FUNC_PROTOCOL_MANGLING */
 #define I2C_M_IGNORE_NAK   0x1000  /* if I2C_FUNC_PROTOCOL_MANGLING */
-- 
2.11.0

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

[PATCH 2/2] drm: Release memory obtained by kasprintf

2017-09-20 Thread Arvind Yadav

Free memory region, if drm_crtc_init_with_planes is not successful.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/drm_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5af25ce..cd4e628 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -328,6 +328,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
ret = drm_crtc_crc_init(crtc);
if (ret) {
drm_mode_object_unregister(dev, &crtc->base);
+   kfree(crtc->name);
return ret;
}
 
-- 
1.9.1

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

[RFC PATCH v5 3/6] i2c: add docs to clarify DMA handling

2017-09-20 Thread Wolfram Sang

Signed-off-by: Wolfram Sang 
---
 Documentation/i2c/DMA-considerations | 58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/i2c/DMA-considerations

diff --git a/Documentation/i2c/DMA-considerations 
b/Documentation/i2c/DMA-considerations
new file mode 100644
index 00..5a63355c6a9b6f
--- /dev/null
+++ b/Documentation/i2c/DMA-considerations
@@ -0,0 +1,58 @@
+=
+Linux I2C and DMA
+=
+
+Given that I2C is a low-speed bus where largely small messages are transferred,
+it is not considered a prime user of DMA access. At this time of writing, only
+10% of I2C bus master drivers have DMA support implemented. And the vast
+majority of transactions are so small that setting up DMA for it will likely
+add more overhead than a plain PIO transfer.
+
+Therefore, it is *not* mandatory that the buffer of an I2C message is DMA safe.
+It does not seem reasonable to apply additional burdens when the feature is so
+rarely used. However, it is recommended to use a DMA-safe buffer if your
+message size is likely applicable for DMA. Most drivers have this threshold
+around 8 bytes (as of today, this is mostly an educated guess, however). For
+any message of 16 byte or larger, it is probably a really good idea. Please
+note that other subsystems you use might add requirements. E.g., if your
+I2C bus master driver is using USB as a bridge, then you need to have DMA
+safe buffers always, because USB requires it.
+
+For clients, if you use a DMA safe buffer in i2c_msg, set the I2C_M_DMA_SAFE
+flag with it. Then, the I2C core and drivers know they can safely operate DMA
+on it. Note that using this flag is optional. I2C host drivers which are not
+updated to use this flag will work like before. And like before, they risk
+using an unsafe DMA buffer. To improve this situation, using I2C_M_DMA_SAFE in
+more and more clients and host drivers is the planned way forward. Note also
+that setting this flag makes only sense in kernel space. User space data is
+copied into kernel space anyhow. The I2C core makes sure the destination
+buffers in kernel space are always DMA capable.
+
+FIXME: Need to implement i2c_master_{send|receive}_dma and proper buffers for 
i2c_smbus_xfer_emulated.
+
+Drivers wishing to implement safe DMA can use helper functions from the I2C
+core. One gives you a DMA-safe buffer for a given i2c_msg as long as a certain
+threshold is met::
+
+   dma_buf = i2c_get_dma_safe_msg_buf(msg, threshold_in_byte);
+
+If a buffer is returned, it is either msg->buf for the I2C_M_DMA_SAFE case or a
+bounce buffer. But you don't need to care about that detail, just use the
+returned buffer. If NULL is returned, the threshold was not met or a bounce
+buffer could not be allocated. Fall back to PIO in that case.
+
+In any case, a buffer obtained from above needs to be released. It ensures data
+is copied back to the message and a potentially used bounce buffer is freed::
+
+   i2c_release_dma_safe_msg_buf(msg, dma_buf);
+
+The bounce buffer handling from the core is generic and simple. It will always
+allocate a new bounce buffer. If you want a more sophisticated handling (e.g.
+reusing pre-allocated buffers), you are free to implement your own.
+
+Please also check the in-kernel documentation for details. The i2c-sh_mobile
+driver can be used as a reference example how to use the above helpers.
+
+Final note: If you plan to use DMA with I2C (or with anything else, actually)
+make sure you have CONFIG_DMA_API_DEBUG enabled during development. It can help
+you find various issues which can be complex to debug otherwise.
-- 
2.11.0

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

[RFC PATCH v5 2/6] i2c: add helpers to ease DMA handling

2017-09-20 Thread Wolfram Sang

One helper checks if DMA is suitable and optionally creates a bounce
buffer, if not. The other function returns the bounce buffer and makes
sure the data is properly copied back to the message.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/i2c-core-base.c | 45 +
 include/linux/i2c.h |  3 +++
 2 files changed, 48 insertions(+)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 56e46581b84bdb..925a22794d3ced 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -2241,6 +2241,51 @@ void i2c_put_adapter(struct i2c_adapter *adap)
 }
 EXPORT_SYMBOL(i2c_put_adapter);
 
+/**
+ * i2c_get_dma_safe_msg_buf() - get a DMA safe buffer for the given i2c_msg
+ * @msg: the message to be checked
+ * @threshold: the amount of byte from which using DMA makes sense
+ *
+ * Return: NULL if a DMA safe buffer was not obtained. Use msg->buf with PIO.
+ *
+ *Or a valid pointer to be used with DMA. Note that it can either be
+ *msg->buf or a bounce buffer. After use, release it by calling
+ *i2c_release_dma_safe_msg_buf().
+ *
+ * This function must only be called from process context!
+ */
+u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold)
+{
+   if (msg->len < threshold)
+   return NULL;
+
+   if (msg->flags & I2C_M_DMA_SAFE)
+   return msg->buf;
+
+   if (msg->flags & I2C_M_RD)
+   return kzalloc(msg->len, GFP_KERNEL);
+   else
+   return kmemdup(msg->buf, msg->len, GFP_KERNEL);
+}
+EXPORT_SYMBOL_GPL(i2c_get_dma_safe_msg_buf);
+
+/**
+ * i2c_release_dma_safe_msg_buf - release DMA safe buffer and sync with i2c_msg
+ * @msg: the message to be synced with
+ * @buf: the buffer obtained from i2c_get_dma_safe_msg_buf(). May be NULL.
+ */
+void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf)
+{
+   if (!buf || buf == msg->buf)
+   return;
+
+   if (msg->flags & I2C_M_RD)
+   memcpy(msg->buf, buf, msg->len);
+
+   kfree(buf);
+}
+EXPORT_SYMBOL_GPL(i2c_release_dma_safe_msg_buf);
+
 MODULE_AUTHOR("Simon G. Vogl ");
 MODULE_DESCRIPTION("I2C-Bus main module");
 MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index d501d3956f13f0..1e99342f180f45 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -767,6 +767,9 @@ static inline u8 i2c_8bit_addr_from_msg(const struct 
i2c_msg *msg)
return (msg->addr << 1) | (msg->flags & I2C_M_RD ? 1 : 0);
 }
 
+u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold);
+void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf);
+
 int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short 
addr);
 /**
  * module_i2c_driver() - Helper macro for registering a modular I2C driver
-- 
2.11.0

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

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

2017-09-20 Thread John Keeping

On Wed, Sep 20, 2017 at 07:08:11PM +0800, hl wrote:
> 
> 
> On Wednesday, September 20, 2017 06:08 PM, John Keeping wrote:
> > On Tue, Sep 19, 2017 at 01:27:40PM -0700, Sean Paul wrote:
> >> On Tue, Sep 19, 2017 at 11:19:01AM -0700, Brian Norris wrote:
> >>> Hi Sean,
> >>>
> >>> On Tue, Sep 19, 2017 at 11:00:25AM -0700, Sean Paul wrote:
>  On Mon, Sep 18, 2017 at 05:05:33PM +0800, Nickey Yang wrote:
> > This patch correct Feedback divider setting:
> > 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> > 2、Due to the use of a "by 2 pre-scaler," the range of the
> > feedback multiplication Feedback divider is limited to even
> > division numbers, and Feedback divider must be greater than
> > 12, less than 1000.
> > 3、Make the previously configured Feedback divider(LSB)
> > factors effective
> >
> > Signed-off-by: Nickey Yang 
> > ---
> >   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> > ++
> >   1 file changed, 54 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index 9a20b9d..52698b7 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -228,7 +228,7 @@
> >   #define LOW_PROGRAM_EN0
> >   #define HIGH_PROGRAM_EN   BIT(7)
> >   #define LOOP_DIV_LOW_SEL(val) (((val) - 1) & 0x1f)
> > -#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
> > +#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0xf)
> >   #define PLL_LOOP_DIV_EN   BIT(5)
> >   #define PLL_INPUT_DIV_EN  BIT(4)
> >   
> > @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi 
> > *dsi)
> > dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
> > dw_mipi_dsi_phy_write(dsi, 0x18, 
> > LOOP_DIV_LOW_SEL(dsi->feedback_div) |
> >  LOW_PROGRAM_EN);
> > +   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | 
> > PLL_INPUT_DIV_EN);
>  You do the same write 2 lines down. Are both needed? It would be nice if 
>  the
>  register names were also defined, so this is easier to read.
> >>> If I'm reading correctly, I think this is what Nickey meant by:
> >>>
> >>> "3、Make the previously configured Feedback divider(LSB)
> >>> factors effective"
> >>>
> >>> . My reading of the databook is that this step finalizes the previous
> >>> two writes (to test code 0x17 and 0x18).
> >>>
> >>> Given this was buggy (?) previously, it does seem like having some extra
> >>> language to document this could help. Register names (or "test codes",
> >>> per the docs?) could help, but additionally, maybe a few more comments.
> >>>
> >> Ah, yeah, thanks for the explanation. It's not clear that this latches the
> >> values above. I think register names and comments would be immensely 
> >> helpful.
> > According to the databook, 0x19 controls whether the loop/input dividers
> > are derived from the hsfreqrange configuration or use the values in 0x17
> > and 0x18.  I can't see why writing the same value to this register
> > multiple times is necessary.
> According to databook, set 0x19 to 0x30 make the previously configured 
> N(0x17) and M(0x18)
> factors effective, 0x18 need to be setted by twice, since we need to set 
> 0x18 LSB and MSB separately,
> As we test, after set 0x18 LSB, if we do not set 0x19 immediately to 
> make the configrued effective,
> when we set 0x18 MSB, the 0x18 LSB value will gone, and we will get 
> wrong pll frequency. Anyway,
> I think should add some comment here to clear that.

That's surprising, the examples in sections 6.2.1 and 6.2.2 of the
databook I have both show the high and low parts of 0x18 being written
before 0x19 is set.

When reading 0x18 are you setting bit 7 in TESTDIN correctly in order to
select the correct bits of the feedback divider?

> >
> > dw_mipi_dsi_phy_write(dsi, 0x18, 
> > LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
> >  HIGH_PROGRAM_EN);
> > dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | 
> > PLL_INPUT_DIV_EN);
> >>> [...]
> > ___
> > Linux-rockchip mailing list
> > linux-rockc...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND PATCH 2/2] drm/armada: Replace drm_framebuffer_reference/unreference() with _get/put()

2017-09-20 Thread Haneen Mohammed

This patch replace instances of drm_framebuffer_reference/unreference with
*_get/put() suffixes, because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
This was done with the following Coccinelle script:

@r1@
expression e;
@@

(
-drm_framebuffer_reference(e);
+drm_framebuffer_get(e);
|
-drm_framebuffer_unreference(e);
+drm_framebuffer_put(e);
)

Signed-off-by: Haneen Mohammed 
---
 drivers/gpu/drm/armada/armada_crtc.c| 14 +++---
 drivers/gpu/drm/armada/armada_drv.c |  2 +-
 drivers/gpu/drm/armada/armada_overlay.c |  4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 381dfa1..2e065fa 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -298,7 +298,7 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc 
*dcrtc,
 
if (force) {
/* Display is disabled, so just drop the old fb */
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
return;
}
 
@@ -321,7 +321,7 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc 
*dcrtc,
 * the best.  The worst that will happen is the buffer gets
 * reused before it has finished being displayed.
 */
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
 }
 
 static void armada_drm_vblank_off(struct armada_crtc *dcrtc)
@@ -577,7 +577,7 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
unsigned i;
bool interlaced;
 
-   drm_framebuffer_reference(crtc->primary->fb);
+   drm_framebuffer_get(crtc->primary->fb);
 
interlaced = !!(adj->flags & DRM_MODE_FLAG_INTERLACE);
 
@@ -718,7 +718,7 @@ static int armada_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
   MAX_SCHEDULE_TIMEOUT);
 
/* Take a reference to the new fb as we're using it */
-   drm_framebuffer_reference(crtc->primary->fb);
+   drm_framebuffer_get(crtc->primary->fb);
 
/* Update the base in the CRTC */
armada_drm_crtc_update_regs(dcrtc, regs);
@@ -742,7 +742,7 @@ void armada_drm_crtc_plane_disable(struct armada_crtc 
*dcrtc,
 * primary plane.
 */
if (plane->fb)
-   drm_framebuffer_unreference(plane->fb);
+   drm_framebuffer_put(plane->fb);
 
/* Power down the Y/U/V FIFOs */
sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
@@ -1045,12 +1045,12 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
 * Ensure that we hold a reference on the new framebuffer.
 * This has to match the behaviour in mode_set.
 */
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
 
ret = armada_drm_crtc_queue_frame_work(dcrtc, work);
if (ret) {
/* Undo our reference above */
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
kfree(work);
return ret;
}
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 0b3227c..c993bcc 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -26,7 +26,7 @@ static void armada_drm_unref_work(struct work_struct *work)
struct drm_framebuffer *fb;
 
while (kfifo_get(&priv->fb_unref, &fb))
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
 }
 
 /* Must be called with dev->event_lock held */
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index edc4491..b411b60 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -177,7 +177,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 * Take a reference on the new framebuffer - we want to
 * hold on to it while the hardware is displaying it.
 */
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
 
if (plane->fb)
armada_ovl_retire_fb(dplane, plane->fb);
@@ -278,7 +278,7 @@ static int armada_ovl_plane_disable(struct drm_plane *plane,
 
fb = xchg(&dplane->old_fb, NULL);
if (fb)
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
 
return 0;
 }
-- 
2.7.4

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

Re: linux-next: Tree for Sep 19 (drivers/gpu/drm/i915/i915_gem.c)

2017-09-20 Thread Randy Dunlap

On 09/18/17 21:15, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20170918:
> 
> Linus' tree still had its build failure for which I reverted a commit.
> 
> The drm-intel tree gained conflicts against Linus' tree.
> 

on x86_64:

In file included from ../drivers/gpu/drm/i915/i915_gem.c:5342:0:
../drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 
'mock_gem_device':
../drivers/gpu/drm/i915/selftests/mock_gem_device.c:150:20: error: 'struct 
dev_archdata' has no member named 'iommu'
  pdev->dev.archdata.iommu = (void *)-1;
^

when IOMMU_SUPPORT, INTEL_IOMMU, and AMD_IOMMU are not enabled.

struct dev_archdata {
#if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU)
void *iommu; /* hook for IOMMU specific extension */
#endif
};



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

Re: [PATCH 1/2] drm: armada: Remove custom .dumb_destroy() handler

2017-09-20 Thread Russell King - ARM Linux

On Wed, Sep 20, 2017 at 08:38:59PM +0200, Daniel Vetter wrote:
> On Fri, Sep 15, 2017 at 09:17:53PM +0300, Laurent Pinchart wrote:
> > Hi Noralf,
> > 
> > On Friday, 15 September 2017 20:49:26 EEST Noralf Trønnes wrote:
> > > Den 15.09.2017 04.27, skrev Laurent Pinchart:
> > > > The custom implementation just calls drm_gem_handle_delete(), which is
> > > > identical to the default implementation used when the operation handler
> > > > isn't set. Remove it.
> > > > 
> > > > Signed-off-by: Laurent Pinchart
> > > > 
> > > > ---
> > > 
> > > This is done already:
> > > drm/armada: Use .dumb_map_offset and .dumb_destroy defaults
> > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=4ee73624e0d0fd647ede3b1
> > > 7187ba98f2aa9421c
> > > 
> > > It stalled for some time awaiting the outcome of this:
> > > drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
> > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=90378e58919285637aa0f06
> > > 3c04ba0c6449d98b1
> > 
> > Oops, sorry about that.
> > 
> > Should we push the former as it doesn't depend on the latter ?
> 
> Needs acks and r-bs ... hint, hint :-)

Yea, I also need to get my own patch stack out that moves more of this
code closer to atomic modeset.  I'm not doing very much at the moment
as I'm suffering with a lurgy that's made me very tired and thus
error-prone.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: tegra: dc: Handle return value of kasprintf

2017-09-20 Thread Arvind Yadav

kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/tegra/dc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 4df3911..f3214a1 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1695,6 +1695,8 @@ static int tegra_dc_debugfs_init(struct tegra_dc *dc, 
struct drm_minor *minor)
int err;
 
name = kasprintf(GFP_KERNEL, "dc.%d", dc->pipe);
+   if (!name)
+   return -ENOMEM;
dc->debugfs = debugfs_create_dir(name, minor->debugfs_root);
kfree(name);
 
-- 
1.9.1

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

Re: [PATCH 1/2] drm: armada: Remove custom .dumb_destroy() handler

2017-09-20 Thread Noralf Trønnes



Den 20.09.2017 21.40, skrev Noralf Trønnes:


Den 20.09.2017 20.38, skrev Daniel Vetter:

On Fri, Sep 15, 2017 at 09:17:53PM +0300, Laurent Pinchart wrote:

Hi Noralf,

On Friday, 15 September 2017 20:49:26 EEST Noralf Trønnes wrote:

Den 15.09.2017 04.27, skrev Laurent Pinchart:
The custom implementation just calls drm_gem_handle_delete(), 
which is
identical to the default implementation used when the operation 
handler

isn't set. Remove it.

Signed-off-by: Laurent Pinchart

---

This is done already:
drm/armada: Use .dumb_map_offset and .dumb_destroy defaults
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=4ee73624e0d0fd647ede3b1 


7187ba98f2aa9421c

It stalled for some time awaiting the outcome of this:
drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=90378e58919285637aa0f06 


3c04ba0c6449d98b1

Oops, sorry about that.

Should we push the former as it doesn't depend on the latter ?


Sorry, I missed this. But what's the former and latter here?



Oh, now I think I see. I thought former/latter referred to this patchset,
but maybe it refers to the 2 patches I mentioned. I see that I don't
say it explicitly, but they are both applied to drm-misc as implied by
the url's.

Armada came in late compared to the other drivers in the patchset,
since it rejected dma-bufs. So it wasn't clear if it could use both
defaults or just one.


Noralf.


Needs acks and r-bs ... hint, hint :-)
-Daniel


drivers/gpu/drm/armada/armada_drv.c | 1 -
   drivers/gpu/drm/armada/armada_gem.c | 6 --
   drivers/gpu/drm/armada/armada_gem.h | 2 --
   3 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c index 
0b3227c039d7..8a37b9a66dbc

100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -71,7 +71,6 @@ static struct drm_driver armada_drm_driver = {

   .gem_prime_import    = armada_gem_prime_import,
   .dumb_create    = armada_gem_dumb_create,
   .dumb_map_offset    = armada_gem_dumb_map_offset,

-    .dumb_destroy    = armada_gem_dumb_destroy,

   .gem_vm_ops    = &armada_gem_vm_ops,
   .major    = 1,
   .minor    = 0,

diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c index 
a76ca21d063b..9d69132bbeda

100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -300,12 +300,6 @@ int armada_gem_dumb_map_offset(struct 
drm_file *file,

struct drm_device *dev,>
   return ret;
      }

-int armada_gem_dumb_destroy(struct drm_file *file, struct drm_device
*dev,
-    uint32_t handle)
-{
-    return drm_gem_handle_delete(file, handle);
-}
-

   /* Private driver gem ioctls */
   int armada_gem_create_ioctl(struct drm_device *dev, void *data,
      struct drm_file *file)

diff --git a/drivers/gpu/drm/armada/armada_gem.h
b/drivers/gpu/drm/armada/armada_gem.h index 
6e524e0676bb..78d5690b699b

100644
--- a/drivers/gpu/drm/armada/armada_gem.h
+++ b/drivers/gpu/drm/armada/armada_gem.h
@@ -37,8 +37,6 @@ int armada_gem_dumb_create(struct drm_file *, 
struct

drm_device *,>
   struct drm_mode_create_dumb *);
      int armada_gem_dumb_map_offset(struct drm_file *, struct 
drm_device *,

      uint32_t, uint64_t *);

-int armada_gem_dumb_destroy(struct drm_file *, struct drm_device *,
-    uint32_t);

   struct dma_buf *armada_gem_prime_export(struct drm_device *dev,
      struct drm_gem_object *obj, int flags);
      struct drm_gem_object *armada_gem_prime_import(struct 
drm_device *,


--
Regards,

Laurent Pinchart

___
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



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

Re: [PATCH 3/3] dt-bindings: Add KINGDISPLAY KD097D04 panel bindings

2017-09-20 Thread Rob Herring

On Mon, Sep 18, 2017 at 04:43:50PM +0800, Nickey Yang wrote:
> The KINGDISPLAY KD097D04 is a 9.7" panel with a 1536x2048
> resolution and connected to DSI using 8 lanes.
> 
> Signed-off-by: Nickey Yang 
> ---
>  .../display/panel/kingdisplay,kd097d04.txt | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/kingdisplay,kd097d04.txt

Acked-by: Rob Herring 

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

Re: [PATCH 1/5] dt-bindings: Explicitely mark Exynos HDMI DDC node as deprecated

2017-09-20 Thread Rob Herring

On Fri, Sep 15, 2017 at 11:11:19AM +0200, Marek Szyprowski wrote:
> Commit 2b7681326dc2 ("drm/exynos: hdmi: remove the i2c drivers and use")
> merged to v3.15 kernel added a required 'ddc' property to Exynos HDMI
> device tree bindings, which should point to i2c bus used for handling DDC
> (mainly reading display's EDID information). Since that commit
> separate node with "samsung,exynos4210-hdmiddc" compatible is no longer
> needed, so mark it finally as deprecated.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #67 from Lukas Jirkovsky  ---
I can confirm that it works fine here after applying the hack, too.

Anyway, I'm with Shmerl here. In my opinion a user process should never be able
to make system unusable no matter what kind of stupid stuff it does. I'm fine
with the application crashing or behaving incorrectly - it's that applications
fault after all. Just don't take the system with it.

Also, great work, thank you!

-- 
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 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=60879

David Verelst  changed:

   What|Removed |Added

 CC||david.vere...@gmail.com

--- Comment #169 from David Verelst  ---
Created attachment 134388
  --> https://bugs.freedesktop.org/attachment.cgi?id=134388&action=edit
dmesg radeon kernel 4.12.13

Not sure if it helps, but here's another dmesg output from radeon + kernel
4.12.13. What does work though is the fallback to llvmpipe, and I end up with a
working system + graphics.

-- 
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 1/2] drm: armada: Remove custom .dumb_destroy() handler

2017-09-20 Thread Noralf Trønnes



Den 20.09.2017 20.38, skrev Daniel Vetter:

On Fri, Sep 15, 2017 at 09:17:53PM +0300, Laurent Pinchart wrote:

Hi Noralf,

On Friday, 15 September 2017 20:49:26 EEST Noralf Trønnes wrote:

Den 15.09.2017 04.27, skrev Laurent Pinchart:

The custom implementation just calls drm_gem_handle_delete(), which is
identical to the default implementation used when the operation handler
isn't set. Remove it.

Signed-off-by: Laurent Pinchart

---

This is done already:
drm/armada: Use .dumb_map_offset and .dumb_destroy defaults
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=4ee73624e0d0fd647ede3b1
7187ba98f2aa9421c

It stalled for some time awaiting the outcome of this:
drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=90378e58919285637aa0f06
3c04ba0c6449d98b1

Oops, sorry about that.

Should we push the former as it doesn't depend on the latter ?


Sorry, I missed this. But what's the former and latter here?

Noralf.


Needs acks and r-bs ... hint, hint :-)
-Daniel


   drivers/gpu/drm/armada/armada_drv.c | 1 -
   drivers/gpu/drm/armada/armada_gem.c | 6 --
   drivers/gpu/drm/armada/armada_gem.h | 2 --
   3 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c index 0b3227c039d7..8a37b9a66dbc
100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -71,7 +71,6 @@ static struct drm_driver armada_drm_driver = {

.gem_prime_import   = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
.dumb_map_offset= armada_gem_dumb_map_offset,

-   .dumb_destroy   = armada_gem_dumb_destroy,

.gem_vm_ops = &armada_gem_vm_ops,
.major  = 1,
.minor  = 0,

diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c index a76ca21d063b..9d69132bbeda
100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -300,12 +300,6 @@ int armada_gem_dumb_map_offset(struct drm_file *file,
struct drm_device *dev,>
return ret;
   
   }


-int armada_gem_dumb_destroy(struct drm_file *file, struct drm_device
*dev,
-   uint32_t handle)
-{
-   return drm_gem_handle_delete(file, handle);
-}
-

   /* Private driver gem ioctls */
   int armada_gem_create_ioctl(struct drm_device *dev, void *data,
   
   	struct drm_file *file)


diff --git a/drivers/gpu/drm/armada/armada_gem.h
b/drivers/gpu/drm/armada/armada_gem.h index 6e524e0676bb..78d5690b699b
100644
--- a/drivers/gpu/drm/armada/armada_gem.h
+++ b/drivers/gpu/drm/armada/armada_gem.h
@@ -37,8 +37,6 @@ int armada_gem_dumb_create(struct drm_file *, struct
drm_device *,>
struct drm_mode_create_dumb *);
   
   int armada_gem_dumb_map_offset(struct drm_file *, struct drm_device *,
   
   	uint32_t, uint64_t *);


-int armada_gem_dumb_destroy(struct drm_file *, struct drm_device *,
-   uint32_t);

   struct dma_buf *armada_gem_prime_export(struct drm_device *dev,
   
   	struct drm_gem_object *obj, int flags);
   
   struct drm_gem_object *armada_gem_prime_import(struct drm_device *,


--
Regards,

Laurent Pinchart

___
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 2/3] drm/panel: add Kingdisplay kd097d04 panel driver

2017-09-20 Thread Sean Paul

On Mon, Sep 18, 2017 at 04:40:01PM +0800, Nickey Yang wrote:
> Support Kingdisplay kd097d04 9.7" 1536x2048 TFT LCD panel,
> it is a MIPI DSI panel.
> 
> Signed-off-by: Nickey Yang 

Hi Nickey,
This patch doesn't apply cleanly to drm-misc-next and the encoding is set to 'y'
instead of 'UTF-8'.

> ---
>  drivers/gpu/drm/panel/Kconfig  |  11 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c | 485 
> +
>  3 files changed, 497 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d84a031..8b1f0bd 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -50,6 +50,17 @@ config DRM_PANEL_JDI_LT070ME05000
> The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
> 24 bit per pixel.
>  
> +config DRM_PANEL_KINGDISPLAY_KD097D04
> + tristate "Kingdisplay kd097d04 panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for Kingdisplay kd097d04
> +   TFT-LCD modules. The panel has a 1536x2048 resolution and uses
> +   24 bit RGB per pixel. It provides a MIPI DSI interface to
> +   the host and has a built-in LED backlight.
> +
>  config DRM_PANEL_SAMSUNG_LD9040
>   tristate "Samsung LD9040 RGB/SPI panel"
>   depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 9f6610d..2548931 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -2,6 +2,7 @@ obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
> +obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
>  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
> panel-panasonic-vvx10f034n00.o
>  obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
> diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c 
> b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
> new file mode 100644
> index 000..359cd34
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
> @@ -0,0 +1,485 @@
> +/*
> + * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * 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 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct kingdisplay_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *link;
> +
> + struct backlight_device *backlight;
> + struct regulator *supply;
> + struct gpio_desc *enable_gpio;
> +
> + bool prepared;
> + bool enabled;

I really wish we didn't need to keep track of prepared/enabled here. Is this
just to protect the regulator refcount from unbalanced unprepare/prepare or
enabled/disable calls?

The reason I don't like it is it pretty much guarantees we won't be able to
recover from error paths since prepared/enabled are only flipped at the end of
the various hooks.

> +};
> +
> +struct kingdisplay_pannel_cmd {

s/pannel/panel/

> + char cmd;
> + char data;
> +};
> +
> +static const struct kingdisplay_pannel_cmd init_code[] = {

It doesn't look like these are standard DCS operations? Are these documented
anywhere? It would be great if you could #define some of these registers/values
such that they're useful for people without access to the datasheet (like
myself).

> + /* voltage setting */
> + { 0xB0, 0x00 },
> + { 0xB2, 0x02 },
> + { 0xB3, 0x11 },
> + { 0xB4, 0x00 },
> + { 0xB6, 0x80 },
> + /* VCOM disable */
> + { 0xB8, 0x80 },
> + { 0xBA, 0x43 },
> + /* VCOM setting */
> + { 0xBB, 0x53 },
> + /* VSP setting */
> + { 0xBC, 0x0A },
> + /* VSN setting */
> + { 0xBD, 0x4A },
> + /* VGH setting */
> + { 0xBE, 0x2F },
> + /* VGL setting */
> + { 0xBF, 0x1A },
> + { 0xF0, 0x39 },
> + { 0xF1, 0x21 },
> + /* Gamma setting */
> + { 0xB0, 0x02 },
> + { 0xC0, 0x00 },
> + { 0xC1, 0x01 },
> + { 0xC2, 0x0B },
> + { 0xC3, 0x15 },
> + { 0xC4, 0x22 },
> + { 0xC5, 0x11 },
> + { 0xC6, 0x15 },
> + { 0xC7, 0x19 },
> + { 0xC8, 0x1A },
> + { 0xC9, 0x16 },
> + { 0xCA, 0x18 },
> + { 0xCB, 0x13 },
> + { 0xCC, 0x18 },
> + { 0xCD, 0x13 },
> +

Re: [RESEND PATCH 2/2] drm/armada: Replace drm_framebuffer_reference/unreference() with _get/put()

2017-09-20 Thread Sean Paul

On Wed, Sep 20, 2017 at 11:57 AM, Haneen Mohammed
 wrote:
> This patch replace instances of drm_framebuffer_reference/unreference with
> *_get/put() suffixes, because get/put is shorter and consistent with the
> kernel use of *_get/put suffixes.
> This was done with the following Coccinelle script:
>
> @r1@
> expression e;
> @@
>
> (
> -drm_framebuffer_reference(e);
> +drm_framebuffer_get(e);
> |
> -drm_framebuffer_unreference(e);
> +drm_framebuffer_put(e);
> )
>
> Signed-off-by: Haneen Mohammed 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/armada/armada_crtc.c| 14 +++---
>  drivers/gpu/drm/armada/armada_drv.c |  2 +-
>  drivers/gpu/drm/armada/armada_overlay.c |  4 ++--
>  3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 381dfa1..2e065fa 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -298,7 +298,7 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc 
> *dcrtc,
>
> if (force) {
> /* Display is disabled, so just drop the old fb */
> -   drm_framebuffer_unreference(fb);
> +   drm_framebuffer_put(fb);
> return;
> }
>
> @@ -321,7 +321,7 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc 
> *dcrtc,
>  * the best.  The worst that will happen is the buffer gets
>  * reused before it has finished being displayed.
>  */
> -   drm_framebuffer_unreference(fb);
> +   drm_framebuffer_put(fb);
>  }
>
>  static void armada_drm_vblank_off(struct armada_crtc *dcrtc)
> @@ -577,7 +577,7 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
> unsigned i;
> bool interlaced;
>
> -   drm_framebuffer_reference(crtc->primary->fb);
> +   drm_framebuffer_get(crtc->primary->fb);
>
> interlaced = !!(adj->flags & DRM_MODE_FLAG_INTERLACE);
>
> @@ -718,7 +718,7 @@ static int armada_drm_crtc_mode_set_base(struct drm_crtc 
> *crtc, int x, int y,
>MAX_SCHEDULE_TIMEOUT);
>
> /* Take a reference to the new fb as we're using it */
> -   drm_framebuffer_reference(crtc->primary->fb);
> +   drm_framebuffer_get(crtc->primary->fb);
>
> /* Update the base in the CRTC */
> armada_drm_crtc_update_regs(dcrtc, regs);
> @@ -742,7 +742,7 @@ void armada_drm_crtc_plane_disable(struct armada_crtc 
> *dcrtc,
>  * primary plane.
>  */
> if (plane->fb)
> -   drm_framebuffer_unreference(plane->fb);
> +   drm_framebuffer_put(plane->fb);
>
> /* Power down the Y/U/V FIFOs */
> sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
> @@ -1045,12 +1045,12 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
> *crtc,
>  * Ensure that we hold a reference on the new framebuffer.
>  * This has to match the behaviour in mode_set.
>  */
> -   drm_framebuffer_reference(fb);
> +   drm_framebuffer_get(fb);
>
> ret = armada_drm_crtc_queue_frame_work(dcrtc, work);
> if (ret) {
> /* Undo our reference above */
> -   drm_framebuffer_unreference(fb);
> +   drm_framebuffer_put(fb);
> kfree(work);
> return ret;
> }
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 0b3227c..c993bcc 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -26,7 +26,7 @@ static void armada_drm_unref_work(struct work_struct *work)
> struct drm_framebuffer *fb;
>
> while (kfifo_get(&priv->fb_unref, &fb))
> -   drm_framebuffer_unreference(fb);
> +   drm_framebuffer_put(fb);
>  }
>
>  /* Must be called with dev->event_lock held */
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index edc4491..b411b60 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -177,7 +177,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>  * Take a reference on the new framebuffer - we want to
>  * hold on to it while the hardware is displaying it.
>  */
> -   drm_framebuffer_reference(fb);
> +   drm_framebuffer_get(fb);
>
> if (plane->fb)
> armada_ovl_retire_fb(dplane, plane->fb);
> @@ -278,7 +278,7 @@ static int armada_ovl_plane_disable(struct drm_plane 
> *plane,
>
> fb = xchg(&dplane->old_fb, NULL);
> if (fb)
> -   drm_framebuffer_unreference(fb);
> +   drm_framebuffer_put(fb);
>
> return 0;
>  }
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:

Re: [RESEND PATCH 1/2] drm/armada: Replace drm_gem_object_reference/unreference() with _get/put()

2017-09-20 Thread Sean Paul

On Wed, Sep 20, 2017 at 11:54 AM, Haneen Mohammed
 wrote:
> This patch replace instances of drm_gem_object_reference/unreference with
> *_get/put() suffixes, because get/put is shorter and consistent with the
> kernel use of *_get/put() suffixes.
> This was done with the following Coccinelle script:
>
> @r1@
> expression e;
> @@
>
> (
> -drm_gem_object_reference(e);
> +drm_gem_object_get(e);
> |
> -drm_gem_object_unreference(e);
> +drm_gem_object_put(e);
> |
> -drm_gem_object_unreference_unlocked(e);
> +drm_gem_object_put_unlocked(e);
> )
>
> Signed-off-by: Haneen Mohammed 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/armada/armada_crtc.c  |  8 
>  drivers/gpu/drm/armada/armada_fb.c|  8 
>  drivers/gpu/drm/armada/armada_fbdev.c |  6 +++---
>  drivers/gpu/drm/armada/armada_gem.c   | 14 +++---
>  4 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 2a4d163..381dfa1 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -947,13 +947,13 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc 
> *crtc,
>
> /* Must be a kernel-mapped object */
> if (!obj->addr) {
> -   drm_gem_object_unreference_unlocked(&obj->obj);
> +   drm_gem_object_put_unlocked(&obj->obj);
> return -EINVAL;
> }
>
> if (obj->obj.size < w * h * 4) {
> DRM_ERROR("buffer is too small\n");
> -   drm_gem_object_unreference_unlocked(&obj->obj);
> +   drm_gem_object_put_unlocked(&obj->obj);
> return -ENOMEM;
> }
> }
> @@ -961,7 +961,7 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc 
> *crtc,
> if (dcrtc->cursor_obj) {
> dcrtc->cursor_obj->update = NULL;
> dcrtc->cursor_obj->update_data = NULL;
> -   drm_gem_object_unreference_unlocked(&dcrtc->cursor_obj->obj);
> +   drm_gem_object_put_unlocked(&dcrtc->cursor_obj->obj);
> }
> dcrtc->cursor_obj = obj;
> dcrtc->cursor_w = w;
> @@ -997,7 +997,7 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
> struct armada_private *priv = crtc->dev->dev_private;
>
> if (dcrtc->cursor_obj)
> -   drm_gem_object_unreference_unlocked(&dcrtc->cursor_obj->obj);
> +   drm_gem_object_put_unlocked(&dcrtc->cursor_obj->obj);
>
> priv->dcrtc[dcrtc->num] = NULL;
> drm_crtc_cleanup(&dcrtc->crtc);
> diff --git a/drivers/gpu/drm/armada/armada_fb.c 
> b/drivers/gpu/drm/armada/armada_fb.c
> index 92e6b08..51839c1 100644
> --- a/drivers/gpu/drm/armada/armada_fb.c
> +++ b/drivers/gpu/drm/armada/armada_fb.c
> @@ -18,7 +18,7 @@ static void armada_fb_destroy(struct drm_framebuffer *fb)
> struct armada_framebuffer *dfb = drm_fb_to_armada_fb(fb);
>
> drm_framebuffer_cleanup(&dfb->fb);
> -   drm_gem_object_unreference_unlocked(&dfb->obj->obj);
> +   drm_gem_object_put_unlocked(&dfb->obj->obj);
> kfree(dfb);
>  }
>
> @@ -95,7 +95,7 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
> drm_device *dev,
>  * the above call, but the caller will drop their reference
>  * to it.  Hence we need to take our own reference.
>  */
> -   drm_gem_object_reference(&obj->obj);
> +   drm_gem_object_get(&obj->obj);
>
> return dfb;
>  }
> @@ -144,12 +144,12 @@ static struct drm_framebuffer *armada_fb_create(struct 
> drm_device *dev,
> goto err;
> }
>
> -   drm_gem_object_unreference_unlocked(&obj->obj);
> +   drm_gem_object_put_unlocked(&obj->obj);
>
> return &dfb->fb;
>
>   err_unref:
> -   drm_gem_object_unreference_unlocked(&obj->obj);
> +   drm_gem_object_put_unlocked(&obj->obj);
>   err:
> DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 29c7d04..cf6bad1 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -52,13 +52,13 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
>
> ret = armada_gem_linear_back(dev, obj);
> if (ret) {
> -   drm_gem_object_unreference_unlocked(&obj->obj);
> +   drm_gem_object_put_unlocked(&obj->obj);
> return ret;
> }
>
> ptr = armada_gem_map_object(dev, obj);
> if (!ptr) {
> -   drm_gem_object_unreference_unlocked(&obj->obj);
> +   drm_gem_object_put_unlocked(&obj->obj);
> return -ENOMEM;
> }
>
> @@ -68,7 +68,7 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
>  * A referen

Re: [RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

2017-09-20 Thread Wolfram Sang


> In order to avoid that, and to place them into a box using monotonic fonts,
> I usually add "::" at the preceding line, e. g.:

Just in time: I added the '::' and will resubmit the new version in a
minute.

Thanks for the pointers!



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

Re: [PULL] drm-misc-next

2017-09-20 Thread Daniel Vetter

On Wed, Sep 20, 2017 at 07:33:35PM +0200, Daniel Vetter wrote:
>  include/uapi/drm/drm_mode.h|   4 +-

In case you wonder why Daniel didn't say anything about uapi changes: It's
a comment/documentation fix :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: armada: Remove custom .dumb_destroy() handler

2017-09-20 Thread Daniel Vetter

On Fri, Sep 15, 2017 at 09:17:53PM +0300, Laurent Pinchart wrote:
> Hi Noralf,
> 
> On Friday, 15 September 2017 20:49:26 EEST Noralf Trønnes wrote:
> > Den 15.09.2017 04.27, skrev Laurent Pinchart:
> > > The custom implementation just calls drm_gem_handle_delete(), which is
> > > identical to the default implementation used when the operation handler
> > > isn't set. Remove it.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > > ---
> > 
> > This is done already:
> > drm/armada: Use .dumb_map_offset and .dumb_destroy defaults
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=4ee73624e0d0fd647ede3b1
> > 7187ba98f2aa9421c
> > 
> > It stalled for some time awaiting the outcome of this:
> > drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=90378e58919285637aa0f06
> > 3c04ba0c6449d98b1
> 
> Oops, sorry about that.
> 
> Should we push the former as it doesn't depend on the latter ?

Needs acks and r-bs ... hint, hint :-)
-Daniel

> 
> > >   drivers/gpu/drm/armada/armada_drv.c | 1 -
> > >   drivers/gpu/drm/armada/armada_gem.c | 6 --
> > >   drivers/gpu/drm/armada/armada_gem.h | 2 --
> > >   3 files changed, 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/armada/armada_drv.c
> > > b/drivers/gpu/drm/armada/armada_drv.c index 0b3227c039d7..8a37b9a66dbc
> > > 100644
> > > --- a/drivers/gpu/drm/armada/armada_drv.c
> > > +++ b/drivers/gpu/drm/armada/armada_drv.c
> > > @@ -71,7 +71,6 @@ static struct drm_driver armada_drm_driver = {
> > > 
> > >   .gem_prime_import   = armada_gem_prime_import,
> > >   .dumb_create= armada_gem_dumb_create,
> > >   .dumb_map_offset= armada_gem_dumb_map_offset,
> > > 
> > > - .dumb_destroy   = armada_gem_dumb_destroy,
> > > 
> > >   .gem_vm_ops = &armada_gem_vm_ops,
> > >   .major  = 1,
> > >   .minor  = 0,
> > > 
> > > diff --git a/drivers/gpu/drm/armada/armada_gem.c
> > > b/drivers/gpu/drm/armada/armada_gem.c index a76ca21d063b..9d69132bbeda
> > > 100644
> > > --- a/drivers/gpu/drm/armada/armada_gem.c
> > > +++ b/drivers/gpu/drm/armada/armada_gem.c
> > > @@ -300,12 +300,6 @@ int armada_gem_dumb_map_offset(struct drm_file *file,
> > > struct drm_device *dev,> 
> > >   return ret;
> > >   
> > >   }
> > > 
> > > -int armada_gem_dumb_destroy(struct drm_file *file, struct drm_device
> > > *dev,
> > > - uint32_t handle)
> > > -{
> > > - return drm_gem_handle_delete(file, handle);
> > > -}
> > > -
> > > 
> > >   /* Private driver gem ioctls */
> > >   int armada_gem_create_ioctl(struct drm_device *dev, void *data,
> > >   
> > >   struct drm_file *file)
> > > 
> > > diff --git a/drivers/gpu/drm/armada/armada_gem.h
> > > b/drivers/gpu/drm/armada/armada_gem.h index 6e524e0676bb..78d5690b699b
> > > 100644
> > > --- a/drivers/gpu/drm/armada/armada_gem.h
> > > +++ b/drivers/gpu/drm/armada/armada_gem.h
> > > @@ -37,8 +37,6 @@ int armada_gem_dumb_create(struct drm_file *, struct
> > > drm_device *,> 
> > >   struct drm_mode_create_dumb *);
> > >   
> > >   int armada_gem_dumb_map_offset(struct drm_file *, struct drm_device *,
> > >   
> > >   uint32_t, uint64_t *);
> > > 
> > > -int armada_gem_dumb_destroy(struct drm_file *, struct drm_device *,
> > > - uint32_t);
> > > 
> > >   struct dma_buf *armada_gem_prime_export(struct drm_device *dev,
> > >   
> > >   struct drm_gem_object *obj, int flags);
> > >   
> > >   struct drm_gem_object *armada_gem_prime_import(struct drm_device *,
> 
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: remove redundant variable hw_check

2017-09-20 Thread Daniel Vetter

On Thu, Sep 14, 2017 at 08:28:37PM +0100, Chris Wilson wrote:
> Quoting Colin King (2017-09-14 17:21:54)
> > From: Colin Ian King 
> > 
> > hw_check is being assigned and updated but is no longer being read,
> > hence it is redundant and can be removed.
> > 
> > Detected by clang scan-build:
> > "warning: Value stored to 'hw_check' during its initialization
> > is never read"
> > 
> > Fixes: f6d1973db2d2 ("drm/i915: Move modeset state verifier calls")
> > Signed-off-by: Colin Ian King 
> Reviewed-by: Chris Wilson 

Applied, thanks for patch&review.
-Daniel

> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index f17275519484..ac261eaa5ba5 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12359,7 +12359,6 @@ static void intel_atomic_commit_tail(struct 
> > drm_atomic_state *state)
> > struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > struct drm_crtc *crtc;
> > struct intel_crtc_state *intel_cstate;
> > -   bool hw_check = intel_state->modeset;
> > u64 put_domains[I915_MAX_PIPES] = {};
> > unsigned crtc_vblank_mask = 0;
> > int i;
> > @@ -12376,7 +12375,6 @@ static void intel_atomic_commit_tail(struct 
> > drm_atomic_state *state)
> >  
> > if (needs_modeset(new_crtc_state) ||
> > to_intel_crtc_state(new_crtc_state)->update_pipe) {
> > -   hw_check = true;
> >  
> > put_domains[to_intel_crtc(crtc)->pipe] =
> > modeset_get_crtc_power_domains(crtc,
> > -- 
> > 2.14.1
> > 
> > ___
> > 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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

2017-09-20 Thread Daniel Vetter

On Tue, Sep 12, 2017 at 06:54:45PM +0100, Emil Velikov wrote:
> On 12 September 2017 at 18:47, Colin Ian King  
> wrote:
> > On 12/09/17 18:42, Thomas Hellstrom wrote:
> >> Hi, Colin,
> >>
> >> On 09/12/2017 07:35 PM, Colin King wrote:
> >>> From: Colin Ian King 
> >>>
> >>> mmap'ing the device multiple times will spam the kernel log with the
> >>> DRM_ERROR message about illegal mmap'ing the old fifo space.
> >> How are you hitting this? Multiple mappings should be fine as long as
> >> mapping offsets are correct,
> >> so hitting this message should indicate that the user-space app is doing
> >> something seriously wrong, and
> >> having it present in the log should probably help more than it hurts.
> >>
> >> /Thomas
> >
> > Good question.  I hit similar issues with the drm qxl driver when
> > running some kernel regression tests with stress-ng [1]. I realize this
> > is an artificial test scenario so it is definitely not a typical
> > use-case, however, sync the illegal mmapping will return -EINVAL the
> > application will pick up that this is an error without the need of
> > spotting it in the kernel log. And a user space application can perform
> > many millions of these invalid mmaps causing kernel log spamming.
> >
> FWIW I'm the one to "blame" here - pointing Colin to drop the message.
> 
> Two reasons come to mind:
>  - there is a unwritten rule that roughly says "user input should not
> cause kernel log spam"
>  - out of all the DRM drivers only QXL and VMWGFX print a message,
> with a patch addressing the former

Maybe we should make this a written rule by patching
Documentation/drivers/gpu? Would definitely make sense as part of this
patch series.

Thanks, Daniel
> 
> HTH
> Emil
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/gem-fb-helper: Cleanup docs

2017-09-20 Thread Daniel Vetter

On Fri, Sep 15, 2017 at 12:45:14AM +0300, Laurent Pinchart wrote:
> Hi Noralf,
> 
> On Wednesday, 13 September 2017 16:41:49 EEST Noralf Trønnes wrote:
> > Den 13.09.2017 04.44, skrev Laurent Pinchart:
> > > On Monday, 11 September 2017 19:37:44 EEST Noralf Trønnes wrote:
> > >> Make the docs read a little better.
> > >> 
> > >> Cc: Laurent Pinchart 
> > >> Signed-off-by: Noralf Trønnes 
> > >> Reviewed-by: Daniel Vetter 
> > >> ---
> > >> 
> > >> Changes:
> > >> Addressed Daniel's comments.
> > >> 
> > >> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 25 +--
> > >> 
> > >> 1 file changed, 14 insertions(+), 11 deletions(-)
> > >> 
> > >> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > >> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index d54a083..e2ca002
> > >> 100644
> > >> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > >> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> 
> [snip]
> 
> > >>  /**
> > >>   * drm_gem_fb_create_handle - Create handle for GEM backed framebuffer
> > >> - * @fb: DRM framebuffer
> > >> - * @file: drm file
> > >> + * @fb: framebuffer
> > >> + * @file: DRM file
> > > 
> > > I wonder why framebuffer doesn't need a DRM while file does :-)
> > 
> > Yes this is haphazard.
> > I think my problem is that I haven't been able to pick up a consistent
> > "signal" from the DRM subsystem when it comes to how documentation
> > should be written. Code patterns are fairly consistent and looks much
> > the same including variable names, but documentation is more or less
> > all over the place.
> 
> That doesn't surprise me too much, as documentation in DRM is pretty recent, 
> and we never agreed to a documentation style.
> 
> > So I guess I need to come to grips with this, since this isn't the last
> > time I have to write documentation. I have to make myself some rules
> > that I can look at next time when all of this is forgotten.
> 
> Or, as the first person to address this problem, you could set your own rules 
> that everybody else should then follow :-)

Better is to actually switch all cases over. Which yes is a lot more work,
but otherwise it won't converge. Since at least me personally I tend to
just copy the patterns from the same file ...

> > Should description entries be Capitalized?
> > My gut feeling is that most DRM docs don't do that, but when humans
> > write for humans we do capatalize the start of sentences. So I guess
> > that's the natural thing to do.
> > 
> > Should DRM objects start with DRM in the argument doc entries?
> > 'DRM device' is a given since the kernel has many types of devices, but
> > should we write 'DRM framebuffer' or 'Framebuffer'?
> 
> I would only mention DRM when the description could otherwise be 
> misinterpreted, as in DRM device.
> 
> > How descriptive should the descriptions be?
> > Let's take this example:
> > 
> > /**
> >   * drm_gem_fb_prepare_fb() - Prepare gem framebuffer
> >   * @plane: Which plane
> >   * @state: Plane state the fence will be attached to
> >   *
> >   * This can be used as the &drm_plane_helper_funcs.prepare_fb hook.
> >   *
> >   * This function checks if the plane FB has an dma-buf attached, extracts
> >   * the exclusive fence and attaches it to plane state for the atomic helper
> >   * to wait on.
> > 
> > Both the @state description and the body says that the fence will be
> > attached to the plane state. Would it be better to just say:
> > 
> >   * @state: Plane state
> > 
> > Another way to ask this is:
> > Should the documentation be terse or should it be repeating itself?
> > 
> > Then we have (copied from the cma library):
> > 
> >   * @plane: Which plane
> > 
> > Which is probably short for: The plane which we are operating/acting on.
> > 
> > More possibilities:
> > 
> >   * @plane: DRM plane
> >   * @plane: Plane
> >   * @plane: The plane for which a framebuffer is prepared for scanout
> > 
> > The text for the last one is also available when clicking on the
> > &drm_plane_helper_funcs.prepare_fb link, so it's repeating something
> > that is one click away.
> 
> Writing kerneldoc just for the sake of it is mostly pointless. We should 
> write 
> documentation to make it as useful and easy to consume as possible. Keeping 
> that in mind,
> 
>  * @plane: Plane
> 
> isn't very useful. It's clear from the function argument name (and type) that 
> it is a pointer to a plane. I would thus advocate for more detailed parameter 
> descriptions.

There's unfortunately a certain amount of boilerplate in some of the
argument docs. It happens, and as long as the main text explains it all,
I think it's ok to have terse doc like this. If we put nothing, kernel-doc
will complain (and those warnings are kinda nice to spot outdated docs).

Thanks, Daniel

> > I always get comments on my documentation, so it's clearly something I
> > need to find a way to improve.
> 
> I don't think it's specific to your documentation. You're doing a great job, 
> for which I'm personally grateful

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=102358

--- Comment #26 from har...@gmx.de ---
Created attachment 134383
  --> https://bugs.freedesktop.org/attachment.cgi?id=134383&action=edit
lprotection in action, longer debug log

adapted debug log (longer test), showing current protection at work ...

No freezes and no other visible issues currently.

-- 
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] dma-fence: fix dma_fence_get_rcu_safe

2017-09-20 Thread Daniel Vetter

On Mon, Sep 11, 2017 at 01:06:32PM +0200, Christian König wrote:
> Am 11.09.2017 um 12:01 schrieb Chris Wilson:
> > [SNIP]
> > > Yeah, but that is illegal with a fence objects.
> > >
> > > When anybody allocates fences this way it breaks at least
> > > reservation_object_get_fences_rcu(),
> > > reservation_object_wait_timeout_rcu() and
> > > reservation_object_test_signaled_single().
> > Many, many months ago I sent patches to fix them all.
>
> Found those after a bit a searching. Yeah, those patches where proposed more
> than a year ago, but never pushed upstream.
>
> Not sure if we really should go this way. dma_fence objects are shared
> between drivers and since we can't judge if it's the correct fence based on
> a criteria in the object (only the read counter which is outside) all
> drivers need to be correct for this.
>
> I would rather go the way and change dma_fence_release() to wrap
> fence->ops->release into call_rcu() to keep the whole RCU handling outside
> of the individual drivers.

Hm, I entirely dropped the ball on this, I kinda assumed that we managed
to get some agreement on this between i915 and dma_fence. Adding a pile
more people.

Joonas, Tvrtko, I guess we need to fix this one way or the other.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: rcar-du: Don't set connector DPMS property

2017-09-20 Thread Daniel Vetter

On Fri, Sep 15, 2017 at 08:23:19PM +0300, Laurent Pinchart wrote:
> Gentle review ping.

Reviewed-by: Daniel Vetter  on both.

Please push to drm-misc or wherever.

Thanks, Daniel

> 
> On Tuesday, 15 August 2017 16:05:45 EEST Laurent Pinchart wrote:
> > Since commit 4a97a3da420b ("drm: Don't update property values for atomic
> > drivers") atomic drivers must not update property values as properties
> > are read from the state instead. To catch remaining users, the
> > drm_object_property_set_value() function now throws a warning when
> > called by atomic drivers on non-immutable properties, and we hit that
> > warning when creating connectors.
> > 
> > The easy fix is to just remove the drm_object_property_set_value() as it
> > is used here to set the initial value of the connector's DPMS property
> > to OFF. The DPMS property applies on top of the connector's state crtc
> > pointer (initialized to NULL) that is the main connector on/off control,
> > and should thus default to ON.
> > 
> > Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 4 
> >  1 file changed, 4 deletions(-)
> > 
> > This patch fixes a regression in drm-next and should be merged in v4.14-rc1.
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c index
> > b373ad48ef5f..e96f2df0c305 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
> > @@ -79,10 +79,6 @@ int rcar_du_lvds_connector_init(struct rcar_du_device
> > *rcdu,
> > 
> > drm_connector_helper_add(connector, &connector_helper_funcs);
> > 
> > -   connector->dpms = DRM_MODE_DPMS_OFF;
> > -   drm_object_property_set_value(&connector->base,
> > -   rcdu->ddev->mode_config.dpms_property, DRM_MODE_DPMS_OFF);
> > -
> > ret = drm_mode_connector_attach_encoder(connector, encoder);
> > if (ret < 0)
> > return ret;
> 
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH v3 0/4] drm/agpsupport: Code cleanup

2017-09-20 Thread Sean Paul

On Thu, Sep 14, 2017 at 01:36:17PM +0530, Meghana Madhyastha wrote:
> Removes checkpath.pl errors and warnings.
> 
> Changes in v3:
>  -Change commit title prefix from drm to drm/agpsupport
>  -Split the commit "Move EXPORT_SYMBOL so that it immediately follows its
>  function" into two commits. Removing the extra blank line is 
>  now a separate commit.
>  -Included merging conditionals in "Remove assignment in if condition"
>  in the commit message
> 
> Meghana Madhyastha (4):
>   drm/agpsupport: Replace "foo * bar" with "foo *bar"
>   drm/agpsupport: Remove assignment in if condition
>   drm/agpsupport: Move EXPORT_SYMBOL so that it immediately follows its
> function
>   drm/agpsupport: Remove extra blank line

Hi Meghana,
Thanks for your patches! I've applied them to drm-misc-next.

Apologies it took a bit longer than it should have to apply them, I've been
traveling the past two weeks.

Sean

> 
>  drivers/gpu/drm/drm_agpsupport.c | 45 
> 
>  1 file changed, 23 insertions(+), 22 deletions(-)
> 
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/cover.1505376068.git.meghana.madhyastha%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-next

2017-09-20 Thread Daniel Vetter

Hi Dave,

I heard you're nicely sleep-deprived again, so perfect time to send you a
pull request. First pile of drm-misc for 4.15, busy as usual (but still
well less than half the patch activity drm-intel.git has seen in the same
time).

drm-misc-next-2017-09-20:
UAPI Changes:

Cross-subsystem Changes:

Core Changes:
- DP SDP defines (Ville)
- polish for scdc helpers (Thierry Reding)
- fix lifetimes for connector/plane state across crtc changes (Maarten
  Lankhorst).
- sparse fixes (Ville+Thierry)
- make legacy kms ioctls all interruptible (Maarten)
- push edid override into the edid helpers (out of probe helpers)
  (Jani)
- DP ESI defines for link status (DK)

Driver Changes:
- drm-panel is now in drm-misc!
- minor panel-simple cleanups/refactoring by various folks
- drm_bridge_add cleanup (Inki Dea)
- constify a few i2c_device_id structs (Arvind Yadav)
- More patches from Noralf's fb/gem helper cleanup
- bridge/synopsis: reset fix (Philippe Cornu)
- fix tracepoint include handling in drivers (Thierry)
- rockchip: lvds support (Sandy Huang)
- move sun4i into drm-misc fold (Maxime Ripard)
- sun4i: refactor driver load + support TCON backend/layer muxing
  (Chen-Yu Tsai)
- pl111: support more pl11x variants (Linus Walleij)
- bridge/adv7511: robustify probing/edid handling (Lars-Petersen
  Clausen)

New hw support:
- S6E63J0X03 panel (Hoegeun Kwon)
- OTM8009A panel (Philippe CORNU)
- Seiko 43WVF1G panel (Marco Franchi)
- tve200 driver (Linus Walleij)

Plus assorted of tiny patches all over, including our first outreachy
patches from applicants for the winter round!

Cheers, Daniel


The following changes since commit 0e8841ec7ee5b1ffe416c3be7743985b1896ec00:

  Merge airlied/drm-next into drm-misc-next (2017-08-18 10:52:44 -0400)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-09-20

for you to fetch changes up to ac6c35a4d8c77083525044a192cb1a8711381e94:

  drm: add backwards compatibility support for drm_kms_helper.edid_firmware 
(2017-09-19 18:11:45 +0300)


UAPI Changes:

Cross-subsystem Changes:

Core Changes:
- DP SDP defines (Ville)
- polish for scdc helpers (Thierry Reding)
- fix lifetimes for connector/plane state across crtc changes (Maarten
  Lankhorst).
- sparse fixes (Ville+Thierry)
- make legacy kms ioctls all interruptible (Maarten)
- push edid override into the edid helpers (out of probe helpers)
  (Jani)
- DP ESI defines for link status (DK)

Driver Changes:
- drm-panel is now in drm-misc!
- minor panel-simple cleanups/refactoring by various folks
- drm_bridge_add cleanup (Inki Dea)
- constify a few i2c_device_id structs (Arvind Yadav)
- More patches from Noralf's fb/gem helper cleanup
- bridge/synopsis: reset fix (Philippe Cornu)
- fix tracepoint include handling in drivers (Thierry)
- rockchip: lvds support (Sandy Huang)
- move sun4i into drm-misc fold (Maxime Ripard)
- sun4i: refactor driver load + support TCON backend/layer muxing
  (Chen-Yu Tsai)
- pl111: support more pl11x variants (Linus Walleij)
- bridge/adv7511: robustify probing/edid handling (Lars-Petersen
  Clausen)

New hw support:
- S6E63J0X03 panel (Hoegeun Kwon)
- OTM8009A panel (Philippe CORNU)
- Seiko 43WVF1G panel (Marco Franchi)
- tve200 driver (Linus Walleij)

Plus assorted of tiny patches all over, including our first outreachy
patches from applicants for the winter round!


Arnd Bergmann (2):
  drm: gma500: fix logic error
  drm/stm: fix warning about multiplication in condition

Arvind Yadav (3):
  drm: i2c: ch7006: constify i2c_device_id
  drm: i2c: sil164: constify i2c_device_id
  drm: i2c: tda998x: constify i2c_device_id

Chen-Yu Tsai (7):
  drm/sun4i: tcon: Unconditionally reset the TCON
  drm/sun4i: add components in breadth first traversal order
  drm/sun4i: tcon: Check for multiple paths between TCONs and backends
  drm/sun4i: tcon: get TCON ID and matching engine with remote endpoint ID
  drm/sun4i: tcon: Simplify sun4i_tcon_find_engine_traverse for one input
  drm/sun4i: tcon: Support backend input mux
  drm/sun4i: call drm_vblank_init with correct number of crtcs

Chris Wilson (1):
  drm: Release driver tracking before making the object available again

Colin Ian King (1):
  drm/vc4: clean up error handling on devm_kzalloc failure

Daniel Vetter (2):
  drm/doc: Document ioctl errno value patterns
  drm/doc: Update todo.rst

Dhinakaran Pandiyan (2):
  drm/dp/mst: Sideband message transaction to power up/down nodes
  drm/dp: DPCD register defines for link status within ESI field

Dominik Behr (1):
  dma-buf/sw_sync: force signal all unsignaled fences on dying timeline

Fabio Estevam (2):
  drm/panel: simple: Skip error message on deferred probe
  drm/panel: simple: Remove unneeded gpiod NULL check

Gabriel Krisman Bertazi (1):
  drm: Fi

Re: [RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

2017-09-20 Thread Wolfram Sang

Hi Mauro,

> > +Linux I2C and DMA
> > +-
> 
> I would use, instead:
> 
> =
> Linux I2C and DMA
> =
> 
> As this is the way we're starting document titles, after converted to
> ReST. So, better to have it already using the right format, as one day

I did this.

> There are also a couple of things here that Sphinx would complain.

The only complaint I got was

WARNING: document isn't included in any toctree

which makes sense because I renamed it only temporarily to *.rst

> So, it could be worth to rename it to *.rst, while you're writing
> it, and see what:
>   make htmldocs
> will complain and how it will look in html.

So, no complaints from Sphinx and the HTML output looks good IMO. Was
there anything specific you had in mind when saying that Sphinx would
complain?

Regards,

   Wolfram



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

[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92248

--- Comment #41 from Hector Velazquez 
 ---
This test still fail on GLK QA

igt@kms_plane_scaling


Output

. . .
 DEBUG 
(kms_plane_scaling:1423) igt-core-INFO: IGT-Version: 1.19-gda197b5 (x86_64)
(Linux: 4.14.0-rc1-drm-tip-ww38-commit-ab2e3a0+ x86_64)
(kms_plane_scaling:1423) igt-core-DEBUG: Test requirement passed:
!igt_run_in_simulation()
(kms_plane_scaling:1423) drmtest-DEBUG: Test requirement passed: !(fd<0)
(kms_plane_scaling:1423) igt-debugfs-DEBUG: Opening debugfs directory
'/sys/kernel/debug/dri/0'
(kms_plane_scaling:1423) igt-debugfs-DEBUG: Opening debugfs directory
'/sys/kernel/debug/dri/0'
(kms_plane_scaling:1423) igt-kms-DEBUG: display: init {
(kms_plane_scaling:1423) igt-kms-DEBUG: Setting Broadcast RGB mode on connector
76 to 1
(kms_plane_scaling:1423) igt-kms-DEBUG: Setting Broadcast RGB mode on connector
84 to 1
(kms_plane_scaling:1423) igt-kms-DEBUG: Setting Broadcast RGB mode on connector
88 to 1
(kms_plane_scaling:1423) igt-kms-DEBUG: Setting Broadcast RGB mode on connector
91 to 1
(kms_plane_scaling:1423) igt-kms-DEBUG: display: }
(kms_plane_scaling:1423) DEBUG: Test requirement passed: d->num_scalers
(kms_plane_scaling:1423) igt-kms-DEBUG: display: eDP-1: set_pipe(A)
(kms_plane_scaling:1423) igt-kms-DEBUG: Setting Broadcast RGB mode on connector
76 to 1
(kms_plane_scaling:1423) igt-kms-DEBUG: display: eDP-1: Selecting pipe A
(kms_plane_scaling:1423) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=1920,
height=1080, format=0x34325258, tiling=0x101, size=0)
(kms_plane_scaling:1423) drmtest-DEBUG: Test requirement passed:
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_plane_scaling:1423) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=1,
pitch=7680)
(kms_plane_scaling:1423) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=1920,
height=1080, format=0x34325258, tiling=0x101, size=0)
(kms_plane_scaling:1423) drmtest-DEBUG: Test requirement passed:
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_plane_scaling:1423) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=2,
pitch=7680)
(kms_plane_scaling:1423) igt-kms-DEBUG: display: eDP-1: set_pipe(A)
(kms_plane_scaling:1423) igt-kms-DEBUG: Setting Broadcast RGB mode on connector
76 to 1
(kms_plane_scaling:1423) igt-kms-DEBUG: display: eDP-1: Selecting pipe A
(kms_plane_scaling:1423) igt-debugfs-DEBUG: Opening debugfs directory
'/sys/kernel/debug/dri/0'
(kms_plane_scaling:1423) igt-debugfs-DEBUG: Using generic frame CRC ABI
(kms_plane_scaling:1423) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=1920,
height=1080, format=0x34325258, tiling=0x101, size=0)
(kms_plane_scaling:1423) drmtest-DEBUG: Test requirement passed:
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_plane_scaling:1423) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=3,
pitch=7680)
(kms_plane_scaling:1423) igt-kms-DEBUG: Test requirement passed: plane_idx >= 0
&& plane_idx < pipe->n_planes
(kms_plane_scaling:1423) igt-kms-DEBUG: display: A.0: plane_set_fb(144)
(kms_plane_scaling:1423) igt-kms-DEBUG: display: A.1: plane_set_fb(144)
(kms_plane_scaling:1423) igt-kms-DEBUG: display: commit {
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane A.0, fb 144, src
= (0, 0) 1920x1080 dst = (0, 0) 1920x1080
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane A.1, fb 144, src
= (0, 0) 1920x1080 dst = (0, 0) 1920x1080
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe A, plane 2,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe A, plane 3,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe A, plane 4,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe B, plane 0,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe B, plane 1,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe B, plane 2,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe B, plane 3,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe B, plane 4,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe C, plane 0,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe C, plane 1,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe C, plane 2,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe C, plane 3,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: SetPlane pipe C, plane 4,
disabling
(kms_plane_scaling:1423) igt-kms-DEBUG: display: }
(kms_plane_scaling:1423) igt-kms-DEBUG: display: A.2: plane_set_fb(92)
(kms_plane_scaling:1423) igt-kms-DEBUG: display: A.2: fb_set_position(100,100)
(kms_plane_scaling:1423) igt-kms-DEBUG: display: A.2: fb_set_size(1720x880)
(kms_plane_scaling:1423) igt-kms-DEBUG:

[Bug 102885] regression - 17.2 sparkle grid in shadows

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=102885

--- Comment #5 from Thomas J. Moore  ---
I'm not sure I trust dropbox entirely (it's a bit invasive), but I went ahead
and created an account to upload the trace file:

https://www.dropbox.com/s/uo6kllmpr1b5jrt/satinav.trace?dl=0

This is from Chains of Satinav.  The sparkle grid appears in the large cursor
in the middle of the screen when it's hovering over the ship's window. 
Normally it is grayish with a wave pattern over it, but when broken, it's just
a sparkle grid.  Please let me know if/when you're downloaded it, so I know it
worked, and I can delete it.

Note that I got a trace from KOTOR as well, but it is not usably replayable,
unlike this one.

-- 
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 102905] [R600] Miscompilation of TGSI to VLIW causes artifacts in Gallium Nine with Crysis2 bump mapping

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=102905

Bug ID: 102905
   Summary: [R600] Miscompilation of TGSI to VLIW causes artifacts
in Gallium Nine with Crysis2 bump mapping
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: i...@yahoo.com
QA Contact: dri-devel@lists.freedesktop.org

In short, the miscompilation happens at "cmp" instruction where the destination
register is also one of the source registers.

I suspect that the problem is caused by breaking "cmp" on two operands that are
executed in different VLIW, thus the result of the first one changes the
outcome of the second. Using a temporal register in "cmp" workarounds the
issue.

The bug is NOT related to Shader Backend. Artifacts are still visible with
"R600_DEBUG=nosb".

A D3D9 apitrace could be obtained from the ixit Nine ftp.
The bug is also tracked at https://github.com/iXit/Mesa-3D/issues/288 .

My hardware is Radeon HD5670 (Evergreen, Redwood).
Not reproducible on Radeon SI.

Bellow are D3D9 Pixel Shader, TGSI and R600 VLIW assembly:
--
445252 @1 IDirect3DDevice9::CreatePixelShader(this = 0xf1e0a290, pFunction = "
//
// Generated by Microsoft (R) D3DX9 Shader Compiler
//
// Parameters:
//
//   sampler2D BlendMapSampler;
//   sampler2D BumpMap2Sampler;
//   float4 MatSpecColor;
//   float3 __0BlendFactor__1BlendMaskTiling__2BlendFalloff__3;
//   sampler2D bumpMapSampler;
//   sampler2D normalsSampler2D;
//
//
// Registers:
//
//   Name   Reg   Size
//   -- - 
//   MatSpecColor   c13  1
//   __0BlendFactor__1BlendMaskTiling__2BlendFalloff__3 c20  1
//   bumpMapSampler s1   1
//   normalsSampler2D   s2   1
//   BumpMap2Samplers3   1
//   BlendMapSamplers4   1
//

ps_3_0
def c0, 2, -1, 1, 0.5
def c1, 0.00392156886, 0, 0, 0
dcl_texcoord_centroid v0.x
dcl_texcoord1 v1.xy
dcl_texcoord2_pp v2
dcl_texcoord3_pp v3.xyz
dcl_texcoord4 v4.xyz
dcl_2d s1
dcl_2d s2
dcl_2d s3
dcl_2d s4
mov r0.x, c1.x
mul_pp oC1.w, r0.x, c13.w
texld_pp r0, v4, s4
mul_pp r0.x, r0.x, v4.z
pow_sat_pp r1.x, r0.x, c20.z
texld_pp r0, v1, s1
mad_pp r0.xy, r0, c0.x, c0.y
dp2add_sat_pp r0.w, r0, -r0, c0.z
rsq_pp r0.w, r0.w
rcp_pp r0.z, r0.w
texld_pp r2, v1, s3
mad_pp r1.yz, r2.xxyw, c0.x, c0.y
dp2add_sat_pp r0.w, r1.yzzw, -r1.yzzw, c0.z
rsq_pp r0.w, r0.w
rcp_pp r1.w, r0.w
lrp_pp r2.xyz, r1.x, r1.yzww, r0
mul_pp r0.xyz, r2.y, v3
mad_pp r0.xyz, r2.x, v2, r0
mov_pp r1.xyz, v2
mul_pp r2.xyw, r1.zxzy, v3.yzzx
mad_pp r1.xyz, r1.yzxw, v3.zxyw, -r2.xyww
mul_pp r1.xyz, r1, v2.w
mad_pp r0.xyz, r2.z, r1, r0
mad_pp r0.xyz, r0, c0.w, c0.w
mad_pp r0.xyz, r0, c0.x, c0.y
nrm_pp r1.xyz, r0
max_pp r0.x, r1_abs.x, r1_abs.y
max_pp r2.x, r1_abs.z, r0.x
add r0.xy, r1_abs.zyzw, -r2.x
rcp r0.z, r2.x
cmp_pp r0.yw, r0.y, r1_abs.xxzz, r1_abs.xyzz
cmp_pp r0.xy, r0.x, r1_abs, r0.ywzw//<= this one
mul_pp r1.xyz, r1, r0.z
add r0.z, -r0.y, r0.x
cmp r0.xy, r0.z, r0, r0.yxzw
rcp r1.w, r0.x
mul r0.z, r0.y, r1.w
mov r0.w, c1.y
texldl r0, r0.xzww, s2
mul_pp r0.xyz, r1, r0.w
mad_pp oC1.xyz, r0, c0.w, c0.w
mov_pp oC0, v0.x

// approximately 49 instruction slots used (5 texture, 44 arithmetic)
", ppShader = [0xbca9a080]) = D3D_OK
--

Making the following change in the above code:
---
-cmp_pp r0.xy, r0.x, r1_abs, r0.ywzw//<= this one
+mov r8, r0
+cmp_pp r0.xy, r8.x, r1_abs, r0.ywzw
---
workarounds the issue.
Alternative workaround is using different destination register, it just needs
more changes in the follow up instructions.

With NINE_DEBUG=ps R600_DEBUG=ps the buggy shader looks like this:
--
FRAG
PROPERTY FS_COORD_ORIGIN UPPER_LEFT
PROPERTY MUL_ZERO_WINS 1
DCL IN[0], GENERIC[0], PERSPECTIVE, CENTROID
DCL IN[1], GENERIC[1], PERSPECTIVE
DCL IN[2], GENERIC[2], PERSPECTIVE
DCL IN[3], GENERIC[3], PERSPECTIVE
DCL IN[4], GENERIC[4], PERSPECTIVE
DCL OUT[0], COLOR[1]
DCL OUT[1], COLOR
DCL SAMP[1]
DCL SAMP[2]
DCL SAMP[3]
DCL SAMP[4]
DCL CONST[0..20]
DCL TEMP[0..1]
DCL TEMP[2], LOCAL
DCL TEMP[3]
IMM[0] FLT32 {2.,-1., 1., 0.5000}
IMM[1] FLT32 {0.0039, 0.,
340282346638528859811704183484516925440.0

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #66 from Shmerl  ---
(In reply to Samuel Pitoiset from comment #64)
> 
> The attached patches should workaround both issues (TW3 and Superposition),
> but wine has to be fixed here.
> 
> Please, let the bug open until it's really fixed.

While Wine does something incorrect here, shouldn't amdgpu/radeonsi still
handle such kind of issues more gracefully? I.e. while Wine should be fixed, I
think Mesa shouldn't cause a system freeze when that happens. Can your patch
approach be generally useful for Mesa to make it more resilient, or some other
solution would be needed?

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #65 from Shmerl  ---
(In reply to Samuel Pitoiset from comment #61)
> Created attachment 134356 [details] [review]
> updated special varying hack
> 
> What about this updated patch? (the previous has to be reverted).

Great! I can confirm, this patch helps both full staging, and regular + minimal
patches Wine. Thanks! I'll point Wine developers to this.

-- 
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 2/2] drm/i915/psr: Set frames before SU entry for psr2

2017-09-20 Thread Vivi, Rodrigo



> On Sep 20, 2017, at 7:33 AM, Nagaraju, Vathsala  
> wrote:
> 
> Set frames before SU entry value for max resync frame count of
> dpcd register 2009, bit field 0:3.
> 
> Cc: Rodrigo Vivi 
> CC: Puthikorn Voravootivat 
> Signed-off-by: Vathsala Nagaraju 
> ---
> drivers/gpu/drm/i915/intel_psr.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index acb5094..04b253f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -327,6 +327,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> */
>uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>uint32_t val;
> +uint8_t sink_latency;
> 
>val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> 
> @@ -334,8 +335,15 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> * mesh at all with our frontbuffer tracking. And the hw alone isn't
> * good enough. */
>val |= EDP_PSR2_ENABLE |
> -EDP_SU_TRACK_ENABLE |
> -EDP_FRAMES_BEFORE_SU_ENTRY;

Please also remove the definition of this su_entry since it was not following 
the new standards anyway...
Probably good to replace with function macro style for better use below...

> +EDP_SU_TRACK_ENABLE;
> +
> +if (drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_SYNCHRONIZATION_LATENCY,
> +&sink_latency)) {
> +sink_latency = sink_latency & DP_MAX_RESYNC_FRAME_CNT_MASK;
> +val |= (sink_latency + 1) << EDP_PSR2_FRAME_BEFORE_SU_SHIFT;

... so you could use
val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency +1);


> +} else {
> +val |= EDP_FRAMES_BEFORE_SU_ENTRY;
> +}
> 
>if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>val |= EDP_PSR2_TP2_TIME_2500;
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102885] regression - 17.2 sparkle grid in shadows

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=102885

--- Comment #4 from Thomas J. Moore  ---
I said I wouldn't, but I went ahead and did a git-bisect:

878bd981bf7aac1466ba3278796f200fa329e2af is the first bad commit

If I have an opportunity later today, I may upload the trace file somewhere.

-- 
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: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Set frames before SU entry for psr2

2017-09-20 Thread Ville Syrjälä

On Wed, Sep 20, 2017 at 08:02:35PM +0530, vathsala nagaraju wrote:
> Set frames before SU entry value for max resync frame count of
> dpcd register 2009, bit field 0:3.
> 
> Cc: Rodrigo Vivi 
> CC: Puthikorn Voravootivat 
> Signed-off-by: Vathsala Nagaraju 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index acb5094..04b253f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -327,6 +327,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>*/
>   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>   uint32_t val;
> + uint8_t sink_latency;
>  
>   val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
> @@ -334,8 +335,15 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
>   val |= EDP_PSR2_ENABLE |
> - EDP_SU_TRACK_ENABLE |
> - EDP_FRAMES_BEFORE_SU_ENTRY;
> + EDP_SU_TRACK_ENABLE;
> +
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_SYNCHRONIZATION_LATENCY,
> + &sink_latency)) {

== 1

> + sink_latency = sink_latency & DP_MAX_RESYNC_FRAME_CNT_MASK;
> + val |= (sink_latency + 1) << EDP_PSR2_FRAME_BEFORE_SU_SHIFT;
> + } else {
> + val |= EDP_FRAMES_BEFORE_SU_ENTRY;
> + }
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/i915/psr: Set frames before SU entry for psr2

2017-09-20 Thread vathsala nagaraju

Set frames before SU entry value for max resync frame count of
dpcd register 2009, bit field 0:3.

Cc: Rodrigo Vivi 
CC: Puthikorn Voravootivat 
Signed-off-by: Vathsala Nagaraju 
---
 drivers/gpu/drm/i915/intel_psr.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index acb5094..04b253f 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -327,6 +327,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 */
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
uint32_t val;
+   uint8_t sink_latency;
 
val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
 
@@ -334,8 +335,15 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
val |= EDP_PSR2_ENABLE |
-   EDP_SU_TRACK_ENABLE |
-   EDP_FRAMES_BEFORE_SU_ENTRY;
+   EDP_SU_TRACK_ENABLE;
+
+   if (drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_SYNCHRONIZATION_LATENCY,
+   &sink_latency)) {
+   sink_latency = sink_latency & DP_MAX_RESYNC_FRAME_CNT_MASK;
+   val |= (sink_latency + 1) << EDP_PSR2_FRAME_BEFORE_SU_SHIFT;
+   } else {
+   val |= EDP_FRAMES_BEFORE_SU_ENTRY;
+   }
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
-- 
1.9.1

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

[PATCH 1/2] drm/dp: Add defines for latency in sink

2017-09-20 Thread vathsala nagaraju

Add defines for dpcd register 2009 (synchronization latency
in sink).

Cc: Rodrigo Vivi 
CC: Puthikorn Voravootivat 
Signed-off-by: Vathsala Nagaraju 
---
 include/drm/drm_dp_helper.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 11c39f1..846004e6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -735,6 +735,9 @@
 # define DP_PSR_SINK_INTERNAL_ERROR 7
 # define DP_PSR_SINK_STATE_MASK 0x07
 
+#define DP_SINK_SYNCHRONIZATION_LATENCY0x2009
+# define DP_MAX_RESYNC_FRAME_CNT_MASK  0xf
+
 #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
 # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
 
-- 
1.9.1

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

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

2017-09-20 Thread Boris Brezillon

On Wed, 20 Sep 2017 15:42:50 +0300
Tomi Valkeinen  wrote:

> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 20/09/17 15:32, Boris Brezillon wrote:
> > On Wed, 20 Sep 2017 14:55:02 +0300
> > Tomi Valkeinen  wrote:
> >   
> >> Hi Boris,
> >>
> >>
> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> >>
> >> On 31/08/17 18:55, Boris Brezillon wrote:  
> >>> Add a driver for Cadence DPI -> DSI bridge.
> >>>
> >>> This driver only support a subset of Cadence DSI bridge capabilities.
> >>>
> >>> Here is a non-exhaustive list of missing features:
> >>>  * burst mode
> >>>  * dynamic configuration of the DPHY based on the
> >>>  * support for additional input interfaces (SDI input)
> >>>
> >>> Signed-off-by: Boris Brezillon 
> >>> ---
> >>> Changes in v3:
> >>> - replace magic values by real timing calculation. The DPHY PLL clock
> >>>   is still hardcoded since we don't have a working DPHY block yet, and
> >>>   this is the piece of HW we need to dynamically configure the PLL
> >>>   rate based on the display refresh rate and the resolution.
> >>> - parse DSI devices represented with the OF-graph. This is needed to
> >>>   support DSI devices controlled through an external bus like I2C or
> >>>   SPI.
> >>> - use the DRM panel-bridge infrastructure to simplify the DRM panel
> >>>   logic
> >>>
> >>> Changes in v2:
> >>> - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
> >>> - return the correct error when devm_clk_get(sysclk) fails
> >>> - add missing depends on OF and select DRM_PANEL in the Kconfig entry
> >>> ---
> >>>  drivers/gpu/drm/bridge/Kconfig|9 +
> >>>  drivers/gpu/drm/bridge/Makefile   |1 +
> >>>  drivers/gpu/drm/bridge/cdns-dsi.c | 1090 
> >>> +
> >>>  3 files changed, 1100 insertions(+)
> >>>  create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c
> >>
> >> We need some power management. At the moment the clocks are kept always
> >> enabled. Those need to be turned off when the IP is not used.  
> > 
> > I can try to move the clk_prepare_enable/disable_unprepare() calls in
> > the bridge->enable/disable() hooks, but I'm not sure the DSI regs
> > content is kept when I disable dsi_p_clk.  
> 
> Yes, context restore has to be handled.
> 
> I'm not sure how different it would be but you could use runtime PM, and
> its resume and suspend callbacks. Then you'd get delayed power-down for
> free, which would prevent suspend, for example, when the bridge is
> disabled, reconfigured and enabled again right away.

As you might already know I'm testing on an emulated system, and I'm
not sure everything is behaving as it will in the final design (once
integrated in a real SoC). I can add support for advanced PM mechanism
but I probably won't be able to test it, so I'd recommend doing the PM
related changes in a follow-up patch (AFAICT, none of the design
choices made in this driver prevent PM optimizations, so it should be
pretty easy to add this afterward).

> 
> >>> +static irqreturn_t cdns_dsi_interrupt(int irq, void *data)
> >>> +{
> >>> + struct cdns_dsi *dsi = data;
> >>> + irqreturn_t ret = IRQ_NONE;
> >>> + u32 flag, ctl;
> >>> +
> >>> + flag = readl(dsi->regs + DIRECT_CMD_STS_FLAG);
> >>> + if (flag) {
> >>> + ctl = readl(dsi->regs + DIRECT_CMD_STS_CTL);
> >>> + ctl &= ~flag;
> >>> + writel(ctl, dsi->regs + DIRECT_CMD_STS_CTL);
> >>
> >> I presume it's the enable/disable bit in STS_CTL that prevents the
> >> interrupt from triggering again, instead of the status flag?  
> > 
> > Yep.
> >   
> >> Just making
> >> sure, because I think on some IPs the status flag has been the one that
> >> triggers the interrupt.
> >>  
> >>> + complete(&dsi->direct_cmd_comp);
> >>> + ret = IRQ_HANDLED;
> >>> + }
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static ssize_t cdns_dsi_transfer(struct mipi_dsi_host *host,
> >>> +  const struct mipi_dsi_msg *msg)
> >>> +{
> >>> + struct cdns_dsi *dsi = to_cdns_dsi(host);
> >>> + u32 cmd, sts, val, wait = WRITE_COMPLETED, ctl = 0;
> >>> + struct mipi_dsi_packet packet;
> >>> + int ret, i, tx_len, rx_len;
> >>> +
> >>> + ret = mipi_dsi_create_packet(&packet, msg);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + tx_len = msg->tx_buf ? msg->tx_len : 0;
> >>> + rx_len = msg->rx_buf ? msg->rx_len : 0;
> >>> +
> >>> + /* For read operations, the maximum TX len is 2. */
> >>
> >> Hmm, why is that?  
> > 
> > I don't know, that's what is stated in the spec.
> > Excerpt from the CMD_SIZE field description:
> > 
> > "
> > For read operations, any value
> > written which is larger than 2
> > bytes will be ignored and the
> > command payload will be truncated
> > to 2 bytes.
> > "  
> 
> Hmm ok... In other part ("Direct command usage") it says that

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

2017-09-20 Thread Tomi Valkeinen


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 20/09/17 15:32, Boris Brezillon wrote:
> On Wed, 20 Sep 2017 14:55:02 +0300
> Tomi Valkeinen  wrote:
> 
>> Hi Boris,
>>
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
>> On 31/08/17 18:55, Boris Brezillon wrote:
>>> Add a driver for Cadence DPI -> DSI bridge.
>>>
>>> This driver only support a subset of Cadence DSI bridge capabilities.
>>>
>>> Here is a non-exhaustive list of missing features:
>>>  * burst mode
>>>  * dynamic configuration of the DPHY based on the
>>>  * support for additional input interfaces (SDI input)
>>>
>>> Signed-off-by: Boris Brezillon 
>>> ---
>>> Changes in v3:
>>> - replace magic values by real timing calculation. The DPHY PLL clock
>>>   is still hardcoded since we don't have a working DPHY block yet, and
>>>   this is the piece of HW we need to dynamically configure the PLL
>>>   rate based on the display refresh rate and the resolution.
>>> - parse DSI devices represented with the OF-graph. This is needed to
>>>   support DSI devices controlled through an external bus like I2C or
>>>   SPI.
>>> - use the DRM panel-bridge infrastructure to simplify the DRM panel
>>>   logic
>>>
>>> Changes in v2:
>>> - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
>>> - return the correct error when devm_clk_get(sysclk) fails
>>> - add missing depends on OF and select DRM_PANEL in the Kconfig entry
>>> ---
>>>  drivers/gpu/drm/bridge/Kconfig|9 +
>>>  drivers/gpu/drm/bridge/Makefile   |1 +
>>>  drivers/gpu/drm/bridge/cdns-dsi.c | 1090 
>>> +
>>>  3 files changed, 1100 insertions(+)
>>>  create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c  
>>
>> We need some power management. At the moment the clocks are kept always
>> enabled. Those need to be turned off when the IP is not used.
> 
> I can try to move the clk_prepare_enable/disable_unprepare() calls in
> the bridge->enable/disable() hooks, but I'm not sure the DSI regs
> content is kept when I disable dsi_p_clk.

Yes, context restore has to be handled.

I'm not sure how different it would be but you could use runtime PM, and
its resume and suspend callbacks. Then you'd get delayed power-down for
free, which would prevent suspend, for example, when the bridge is
disabled, reconfigured and enabled again right away.

>>> +static irqreturn_t cdns_dsi_interrupt(int irq, void *data)
>>> +{
>>> +   struct cdns_dsi *dsi = data;
>>> +   irqreturn_t ret = IRQ_NONE;
>>> +   u32 flag, ctl;
>>> +
>>> +   flag = readl(dsi->regs + DIRECT_CMD_STS_FLAG);
>>> +   if (flag) {
>>> +   ctl = readl(dsi->regs + DIRECT_CMD_STS_CTL);
>>> +   ctl &= ~flag;
>>> +   writel(ctl, dsi->regs + DIRECT_CMD_STS_CTL);  
>>
>> I presume it's the enable/disable bit in STS_CTL that prevents the
>> interrupt from triggering again, instead of the status flag?
> 
> Yep.
> 
>> Just making
>> sure, because I think on some IPs the status flag has been the one that
>> triggers the interrupt.
>>
>>> +   complete(&dsi->direct_cmd_comp);
>>> +   ret = IRQ_HANDLED;
>>> +   }
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +static ssize_t cdns_dsi_transfer(struct mipi_dsi_host *host,
>>> +const struct mipi_dsi_msg *msg)
>>> +{
>>> +   struct cdns_dsi *dsi = to_cdns_dsi(host);
>>> +   u32 cmd, sts, val, wait = WRITE_COMPLETED, ctl = 0;
>>> +   struct mipi_dsi_packet packet;
>>> +   int ret, i, tx_len, rx_len;
>>> +
>>> +   ret = mipi_dsi_create_packet(&packet, msg);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   tx_len = msg->tx_buf ? msg->tx_len : 0;
>>> +   rx_len = msg->rx_buf ? msg->rx_len : 0;
>>> +
>>> +   /* For read operations, the maximum TX len is 2. */  
>>
>> Hmm, why is that?
> 
> I don't know, that's what is stated in the spec.
> Excerpt from the CMD_SIZE field description:
> 
> "
> For read operations, any value
> written which is larger than 2
> bytes will be ignored and the
> command payload will be truncated
> to 2 bytes.
> "

Hmm ok... In other part ("Direct command usage") it says that for short
packets the max is 2, but for long packets max is the fifo size.

>>> +   if (rx_len && tx_len > 2)
>>> +   return -ENOTSUPP;
>>> +
>>> +   /* TX len is limited by the CMD FIFO depth. */
>>> +   if (tx_len > dsi->direct_cmd_fifo_depth)
>>> +   return -ENOTSUPP;
>>> +
>>> +   /* RX len is limited by the RX FIFO depth. */
>>> +   if (rx_len > dsi->rx_fifo_depth)
>>> +   return -ENOTSUPP;
>>> +
>>> +   cmd = CMD_SIZE(tx_len) | CMD_VCHAN_ID(msg->channel) |
>>> + CMD_DATATYPE(msg->type);
>>> +
>>> +   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
>>> +   cmd |= CMD_LP_EN;
>>> +
>>> +   if (mipi_dsi_packet_format_is_long(msg->type))
>>> +   cmd |= CMD_LONG;
>>> +
>>> +   if (rx_le

[PULL] drm-intel-fixes v2

2017-09-20 Thread Rodrigo Vivi

Hi Dave,

I'm sorry for the previous version generated on wrong base.

I believe this one looks sane now.

drm/i915 fixes for 4.14-rc1

Couple fixes for stable:

- Fix MIPI panels on BXT.
- Fix PCI BARs information on GVT.

Plus other fixes:

- Fix minimal brightness for BXT, GLK, CFL and CNL.
- Fix compilation warning: unused in_vbl
- Fix error handling in intel_framebuffer_init
The following changes since commit 134dd2e616b9cd8300c08cd1b38987ded74f662f:

  Merge tag 'drm-amdkfd-next-2017-09-02' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes (2017-09-18 16:29:47 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-09-20

for you to fetch changes up to 99df13b6ea811a63eeacb278d05a5b914ce28073:

  drm/i915: Remove unused 'in_vbl' from i915_get_crtc_scanoutpos() (2017-09-18 
15:22:37 -0700)


drm/i915 fixes for 4.14-rc1

Couple fixes for stable:

- Fix MIPI panels on BXT.
- Fix PCI BARs information on GVT.

Plus other fixes:

- Fix minimal brightness for BXT, GLK, CFL and CNL.
- Fix compilation warning: unused in_vbl
- Fix error handling in intel_framebuffer_init


Changbin Du (1):
  drm/i915/gvt: Fix incorrect PCI BARs reporting

Chris Wilson (1):
  drm/i915: Remove unused 'in_vbl' from i915_get_crtc_scanoutpos()

Christophe JAILLET (1):
  drm/i915: Fix an error handling in 'intel_framebuffer_init()'

Lee, Shawn C (2):
  drm/i915/bxt: set min brightness from VBT
  drm/i915/cnp: set min brightness from VBT

Uma Shankar (1):
  Revert "drm/i915/bxt: Disable device ready before shutdown command"

 drivers/gpu/drm/i915/gvt/cfg_space.c | 113 +++
 drivers/gpu/drm/i915/i915_irq.c  |   3 -
 drivers/gpu/drm/i915/intel_display.c |   2 +-
 drivers/gpu/drm/i915/intel_dsi.c |  11 
 drivers/gpu/drm/i915/intel_panel.c   |   4 ++
 5 files changed, 53 insertions(+), 80 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

2017-09-20 Thread Boris Brezillon

On Wed, 20 Sep 2017 14:55:02 +0300
Tomi Valkeinen  wrote:

> Hi Boris,
> 
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 31/08/17 18:55, Boris Brezillon wrote:
> > Add a driver for Cadence DPI -> DSI bridge.
> > 
> > This driver only support a subset of Cadence DSI bridge capabilities.
> > 
> > Here is a non-exhaustive list of missing features:
> >  * burst mode
> >  * dynamic configuration of the DPHY based on the
> >  * support for additional input interfaces (SDI input)
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Changes in v3:
> > - replace magic values by real timing calculation. The DPHY PLL clock
> >   is still hardcoded since we don't have a working DPHY block yet, and
> >   this is the piece of HW we need to dynamically configure the PLL
> >   rate based on the display refresh rate and the resolution.
> > - parse DSI devices represented with the OF-graph. This is needed to
> >   support DSI devices controlled through an external bus like I2C or
> >   SPI.
> > - use the DRM panel-bridge infrastructure to simplify the DRM panel
> >   logic
> > 
> > Changes in v2:
> > - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
> > - return the correct error when devm_clk_get(sysclk) fails
> > - add missing depends on OF and select DRM_PANEL in the Kconfig entry
> > ---
> >  drivers/gpu/drm/bridge/Kconfig|9 +
> >  drivers/gpu/drm/bridge/Makefile   |1 +
> >  drivers/gpu/drm/bridge/cdns-dsi.c | 1090 
> > +
> >  3 files changed, 1100 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c  
> 
> We need some power management. At the moment the clocks are kept always
> enabled. Those need to be turned off when the IP is not used.

I can try to move the clk_prepare_enable/disable_unprepare() calls in
the bridge->enable/disable() hooks, but I'm not sure the DSI regs
content is kept when I disable dsi_p_clk.

> 
> > +static irqreturn_t cdns_dsi_interrupt(int irq, void *data)
> > +{
> > +   struct cdns_dsi *dsi = data;
> > +   irqreturn_t ret = IRQ_NONE;
> > +   u32 flag, ctl;
> > +
> > +   flag = readl(dsi->regs + DIRECT_CMD_STS_FLAG);
> > +   if (flag) {
> > +   ctl = readl(dsi->regs + DIRECT_CMD_STS_CTL);
> > +   ctl &= ~flag;
> > +   writel(ctl, dsi->regs + DIRECT_CMD_STS_CTL);  
> 
> I presume it's the enable/disable bit in STS_CTL that prevents the
> interrupt from triggering again, instead of the status flag?

Yep.

> Just making
> sure, because I think on some IPs the status flag has been the one that
> triggers the interrupt.
> 
> > +   complete(&dsi->direct_cmd_comp);
> > +   ret = IRQ_HANDLED;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> > +static ssize_t cdns_dsi_transfer(struct mipi_dsi_host *host,
> > +const struct mipi_dsi_msg *msg)
> > +{
> > +   struct cdns_dsi *dsi = to_cdns_dsi(host);
> > +   u32 cmd, sts, val, wait = WRITE_COMPLETED, ctl = 0;
> > +   struct mipi_dsi_packet packet;
> > +   int ret, i, tx_len, rx_len;
> > +
> > +   ret = mipi_dsi_create_packet(&packet, msg);
> > +   if (ret)
> > +   return ret;
> > +
> > +   tx_len = msg->tx_buf ? msg->tx_len : 0;
> > +   rx_len = msg->rx_buf ? msg->rx_len : 0;
> > +
> > +   /* For read operations, the maximum TX len is 2. */  
> 
> Hmm, why is that?

I don't know, that's what is stated in the spec.
Excerpt from the CMD_SIZE field description:

"
For read operations, any value
written which is larger than 2
bytes will be ignored and the
command payload will be truncated
to 2 bytes.
"

> 
> > +   if (rx_len && tx_len > 2)
> > +   return -ENOTSUPP;
> > +
> > +   /* TX len is limited by the CMD FIFO depth. */
> > +   if (tx_len > dsi->direct_cmd_fifo_depth)
> > +   return -ENOTSUPP;
> > +
> > +   /* RX len is limited by the RX FIFO depth. */
> > +   if (rx_len > dsi->rx_fifo_depth)
> > +   return -ENOTSUPP;
> > +
> > +   cmd = CMD_SIZE(tx_len) | CMD_VCHAN_ID(msg->channel) |
> > + CMD_DATATYPE(msg->type);
> > +
> > +   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> > +   cmd |= CMD_LP_EN;
> > +
> > +   if (mipi_dsi_packet_format_is_long(msg->type))
> > +   cmd |= CMD_LONG;
> > +
> > +   if (rx_len) {
> > +   cmd |= READ_CMD;
> > +   wait = READ_COMPLETED_WITH_ERR | READ_COMPLETED;
> > +   ctl = READ_EN | BTA_EN;
> > +   } else if (msg->flags & MIPI_DSI_MSG_REQ_ACK) {
> > +   cmd |= BTA_REQ;
> > +   wait = ACK_WITH_ERR_RCVD | ACK_RCVD;
> > +   ctl = BTA_EN;
> > +   }  
> 
> It's been a while since I worked with DSI, but... Shouldn't there be a
> check somewhere that the packet(s) can fit into the blanking intervals?

Hm, I'm not sure. DSI commands are usually sent when the encoder/bridge
is not transmitting video, so in this case we don't have any constraint
on the packet length. Also, it seems othe

Re: [PATCH] qxl: fix framebuffer unpinning

2017-09-20 Thread Gerd Hoffmann

  Hi,

> > "removing the device"?  qxl can't be hotplugged ...
> > Or do you mean "rmmod qxl"?
> 
> rmmod qxl

rmmod: ERROR: Module qxl is in use.

How do you do that?  CONFIG_FBCON=n?

cheers,
  Gerd

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

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

2017-09-20 Thread Boris Brezillon

On Tue, 19 Sep 2017 17:25:29 +0300
Tomi Valkeinen  wrote:

> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 19/09/17 16:48, Boris Brezillon wrote:
> > On Tue, 19 Sep 2017 16:38:31 +0300
> > Tomi Valkeinen  wrote:
> >   
> >> 
> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> >>
> >> On 19/09/17 16:25, Boris Brezillon wrote:  
> >>> On Tue, 19 Sep 2017 15:59:20 +0300
> >>> Tomi Valkeinen  wrote:
> >>> 
>  Hi Boris,
> 
> 
>  Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
>  Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
>  On 31/08/17 18:55, Boris Brezillon wrote:
> > Add a driver for Cadence DPI -> DSI bridge.
> >
> > This driver only support a subset of Cadence DSI bridge capabilities.
> >
> > Here is a non-exhaustive list of missing features:
> >  * burst mode
> >  * dynamic configuration of the DPHY based on the
> >  * support for additional input interfaces (SDI input)
> >
> > Signed-off-by: Boris Brezillon  
> >  
> 
>  
> 
> > +   dsi->pclk = devm_clk_get(&pdev->dev, "pclk");
> > +   if (IS_ERR(dsi->pclk))
> > +   return PTR_ERR(dsi->pclk);  
> 
>  What's the purpose of pclk? Isn't that normally dealt with the normal
>  modesetting, enabled with the video stream? How could it even be enabled
>  here, without anyone setting the rate?
> >>>
> >>> It's the peripheral clock, not the pixel clock, and AFAIU it has to be
> >>> enabled before accessing DSI registers.
> >>
> >> Is that the dsi_p_clk? I can't find "peripheral clock" in the specs.  
> > 
> > Yep, it is dsi_p_clk (the APB clock).
> >   
> >>
> >> I think calling it "pclk" in a display driver is very confusing, as
> >> pclk, at least for me, always means pixel clock =).  
> > 
> > I can rename it if you prefer. What name would you like to see?
> > abp_clk? periph_clk? Something else?  
> 
> Is there something wrong with dsi_p_clk? If possible, it's nice if the
> terms in SW match to the HW docs. In the minimum, the DT doc should give
> the mapping from SW to HW terms, at the moment it just says "pclk".

I'll switch to dsi_p_clk and dsi_sys_clk.

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

Re: [PATCH 3/3] drm/panel: Add Ilitek ILI9322 driver

2017-09-20 Thread Linus Walleij

On Sun, Aug 13, 2017 at 1:44 PM, Linus Walleij  wrote:

> This adds support for the Ilitek ILI9322 QVGA (320x240)
> TFT panel driver.
>
> This panel driver supports serial or parallel RGB or
> YUV input and also ITU-T BT.656 input streams.
>
> The controller is combined with a physical panel and
> configured through the device tree.
>
> Signed-off-by: Linus Walleij 
Any opinion on this panel driver?

As background, I also found that similar hardware is handled by
backlight drivers:
drivers/video/backlight/ili9320.c
drivers/video/backlight/ili922x.c

For example in ili922x_display_init() in the last file, the stuff
we handle with properly documented DT properties is instead
handled with hard-coded magic numbers.

Overall backlight is a real bad fit for this hardware, since,
yeah you got it, it's not just about backlight, much more about
panel driving in general.

I guess the platforms using these "backlight" drivers should
be augmented to use this driver or a sibling of it, and its
DT bindings if/when their respective target systems get
migrated to DT.

Since Ben worked on the old drivers I toss him in for
review so I can get some kind of opinion on this.
Ben: tell me if you want me to resend the whole set.

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

Re: [PATCH 2/3] drm/panel: Add DT bindings for Ilitek ILI9322

2017-09-20 Thread Linus Walleij

On Sat, Sep 2, 2017 at 11:17 PM, Linus Walleij  wrote:
> On Thu, Aug 17, 2017 at 10:44 PM, Rob Herring  wrote:
>> On Sun, Aug 13, 2017 at 01:44:47PM +0200, Linus Walleij wrote:
>
>>> This adds device tree bindings for the Ilitek ILI9322
>>> 320x240 TFT panel driver.
>>>
>>> Cc: devicet...@vger.kernel.org
>>> Signed-off-by: Linus Walleij 
> (...)
>>> +Optional properties:
>>> +  - width-mm: physical panel width [mm]
>>> +  - height-mm: physical panel height [mm]
>>> +  - vcc-supply: core voltage supply, see regulator/regulator.txt
>>> +  - iovcc-supply: voltage supply for the interface input/output signals,
>>> +see regulator/regulator.txt
>>> +  - vci-supply: voltage supply for analog parts, see 
>>> regulator/regulator.txt
>>> +  - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
>>> +  - ilitek,vreg1out-microvolt: the output in microvolts for the VREGOUT1
>>> +regulator used to drive the physical display. Valid ranges are 3600 
>>> thru
>>> +6000 in 100 microvolt increments. If not specified, hardware defaults 
>>> will
>>> +be used (4.5V).
>>> +  - ilitek,vcom-amplitude-percent: the percentage of VREGOUT1 used for the
>>> +peak-to-peak amplitude of the communcation signals to the physical 
>>> display.
>>> +Valid ranges are 70 thru 132 percent in increments if two percent. Odd
>>> +percentages will be truncated. If not specified, hardware defaults 
>>> will be
>>> +used (114%).
>>> +  - ilitek,vcom-high-percent: the percentage of VREGOUT1 used for the peak
>>> +voltage on the communications link. Valid ranges are 37 thru 100 
>>> percent.
>>> +If not specified, hardware defaults will be used (91%).
>>> +  - ilitek,gamma-correction-neg: a set of 8 nybbles describing negative
>>> +gamma correction for voltages V1 thru V8. Valid range 0..15
>>> +  - ilitek,gamma-correction-pos: a set of 8 nybbles describing positive
>>> +gamma correction for voltages V1 thru V8. Valid range 0..15
>>> +These adjust what grayscale voltage will be output for input data V1 = 
>>> 0,
>>> +V2 = 16, V3 = 48, V4 = 96, V5 = 160, V6 = 208, V7 = 240 and V8 = 255.
>>> +The curve is shaped like this:
>>> +
>>> +^
>>> +|V8
>>> +|   V7
>>> +|  V6
>>> +|   V5
>>> +|V4
>>> +|V3
>>> +| V2
>>> +| V1
>>> ++--->
>>> +  0   16 48  96 160208  240  255
>>> +
>>> +The negative and postive gamma values adjust the V1 thru V8 up/down
>>> +according to the datasheet specifications. This is a property of the
>>> +physical display connected to the display controller and may vary.
>>> +If defined, both arrays must be supplied in full. If the properties
>>> +are not supplied, hardware defaults will be used.
>>
>> Normally, we the physical panel is described which would imply all these
>> settings. Are there lots of panels with this controller that would
>> justify all these settings?
>
> The datasheet for the ili9322 just says it "drives panels" essentially.
> Googling around gives at hand that it is used pretty frequently in
> Shenzhen China for adapting different off-the-shelf panels to
> different inputs.
>
> I can't really answer how many of these products that run one or
> another OS using device tree to describe the configuration. It feels more
> like I'm paving the road for others to travel.
>
> Probably other Ilitek panel adapters will need something similar.
>
>>> +  - ilitek,entry-mode: the panel can be connected to various input streams
>>> +and four of them can be selected by electronic straps on the display.
>>> +However it is possible to select another mode or override the
>>> +electronic default with this property. Valid values:
>>> +0: 8 bit serial RGB through
>>> +1: 8 bit serial RGB aligned
>>> +2: 8 bit serial RGB dummy 320x240
>>> +3: 8 bit serial RGB dummy 360x240
>>> +4: disabled
>>> +5: 24 bit parallel RGB through
>>> +6: 24 bit parallel RGB aligned
>>> +7: 24 bit YUV 640Y 320CbCr
>>> +8: 24 bit YUV 720Y 360CbCr
>>> +9: disabled
>>> +10: 8 bit ITU-R BT.656 720Y 360CbCr
>>> +11: 8 bit ITU-R BT.656 640Y 320CbCr
>>
>> To some extent, we have some standard bindings to describe this.
>
> I don't find any. Maybe I'm looking in the wrong places :(
>
> These are closest associated with the DRM "media bus formats"
> in Linux include/uapi/linux/media-bus-format.h
> such as:
>
> #define MEDIA_BUS_FMT_RGB444_1X12   0x1016
> #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE   0x1001
> #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE   0x1002
> #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE   0x1003
> #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE   0x1004
> #defi

Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

2017-09-20 Thread Tomi Valkeinen

Hi Boris,


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 31/08/17 18:55, Boris Brezillon wrote:
> Add a driver for Cadence DPI -> DSI bridge.
> 
> This driver only support a subset of Cadence DSI bridge capabilities.
> 
> Here is a non-exhaustive list of missing features:
>  * burst mode
>  * dynamic configuration of the DPHY based on the
>  * support for additional input interfaces (SDI input)
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v3:
> - replace magic values by real timing calculation. The DPHY PLL clock
>   is still hardcoded since we don't have a working DPHY block yet, and
>   this is the piece of HW we need to dynamically configure the PLL
>   rate based on the display refresh rate and the resolution.
> - parse DSI devices represented with the OF-graph. This is needed to
>   support DSI devices controlled through an external bus like I2C or
>   SPI.
> - use the DRM panel-bridge infrastructure to simplify the DRM panel
>   logic
> 
> Changes in v2:
> - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
> - return the correct error when devm_clk_get(sysclk) fails
> - add missing depends on OF and select DRM_PANEL in the Kconfig entry
> ---
>  drivers/gpu/drm/bridge/Kconfig|9 +
>  drivers/gpu/drm/bridge/Makefile   |1 +
>  drivers/gpu/drm/bridge/cdns-dsi.c | 1090 
> +
>  3 files changed, 1100 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

We need some power management. At the moment the clocks are kept always
enabled. Those need to be turned off when the IP is not used.

> +static irqreturn_t cdns_dsi_interrupt(int irq, void *data)
> +{
> + struct cdns_dsi *dsi = data;
> + irqreturn_t ret = IRQ_NONE;
> + u32 flag, ctl;
> +
> + flag = readl(dsi->regs + DIRECT_CMD_STS_FLAG);
> + if (flag) {
> + ctl = readl(dsi->regs + DIRECT_CMD_STS_CTL);
> + ctl &= ~flag;
> + writel(ctl, dsi->regs + DIRECT_CMD_STS_CTL);

I presume it's the enable/disable bit in STS_CTL that prevents the
interrupt from triggering again, instead of the status flag? Just making
sure, because I think on some IPs the status flag has been the one that
triggers the interrupt.

> + complete(&dsi->direct_cmd_comp);
> + ret = IRQ_HANDLED;
> + }
> +
> + return ret;
> +}
> +
> +static ssize_t cdns_dsi_transfer(struct mipi_dsi_host *host,
> +  const struct mipi_dsi_msg *msg)
> +{
> + struct cdns_dsi *dsi = to_cdns_dsi(host);
> + u32 cmd, sts, val, wait = WRITE_COMPLETED, ctl = 0;
> + struct mipi_dsi_packet packet;
> + int ret, i, tx_len, rx_len;
> +
> + ret = mipi_dsi_create_packet(&packet, msg);
> + if (ret)
> + return ret;
> +
> + tx_len = msg->tx_buf ? msg->tx_len : 0;
> + rx_len = msg->rx_buf ? msg->rx_len : 0;
> +
> + /* For read operations, the maximum TX len is 2. */

Hmm, why is that?

> + if (rx_len && tx_len > 2)
> + return -ENOTSUPP;
> +
> + /* TX len is limited by the CMD FIFO depth. */
> + if (tx_len > dsi->direct_cmd_fifo_depth)
> + return -ENOTSUPP;
> +
> + /* RX len is limited by the RX FIFO depth. */
> + if (rx_len > dsi->rx_fifo_depth)
> + return -ENOTSUPP;
> +
> + cmd = CMD_SIZE(tx_len) | CMD_VCHAN_ID(msg->channel) |
> +   CMD_DATATYPE(msg->type);
> +
> + if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> + cmd |= CMD_LP_EN;
> +
> + if (mipi_dsi_packet_format_is_long(msg->type))
> + cmd |= CMD_LONG;
> +
> + if (rx_len) {
> + cmd |= READ_CMD;
> + wait = READ_COMPLETED_WITH_ERR | READ_COMPLETED;
> + ctl = READ_EN | BTA_EN;
> + } else if (msg->flags & MIPI_DSI_MSG_REQ_ACK) {
> + cmd |= BTA_REQ;
> + wait = ACK_WITH_ERR_RCVD | ACK_RCVD;
> + ctl = BTA_EN;
> + }

It's been a while since I worked with DSI, but... Shouldn't there be a
check somewhere that the packet(s) can fit into the blanking intervals?

 Tomi

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

[ANN] edid-decode on freedesktop.org has been updated to the latest CTA-861 spec

2017-09-20 Thread Hans Verkuil

For anyone interested in decoding an EDID:

The edid-decode utility available from 
git://anongit.freedesktop.org/xorg/app/edid-decode
has been updated to include the latest CTA-861-G standard. Also many bug fixes 
were
applied and the utility does a much better job at checking the EDID for 
inconsistencies
and errors.

I did most of this work about a year ago for Cisco, then was sitting on them 
until I
finally found the time to upstream the patches. Everything has now been merged, 
so
I hope it will prove useful to others as well.

Regards,

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

Re: [PATCH 5/7] arm64: dts: rockchip: rk3399: Correct MIPI DPHY PLL clock

2017-09-20 Thread Heiko Stübner

Am Montag, 18. September 2017, 17:05:37 CEST schrieb Nickey Yang:
> clk_24m --> Gate11[14] --> clk_mipidphy_ref --> Gate21[0] --> clk_dphy_pll
> 
> Signed-off-by: Nickey Yang 

applied as fix for 4.14 after polishing the commit message a bit


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

Re: [PATCH 2/6] drm/exynos: ipp: Add IPP v2 framework

2017-09-20 Thread Marek Szyprowski


Hi Tobias,

Thanks for testing!

On 2017-09-15 19:18, Tobias Jakobi wrote:

Hello Marek,

Marek Szyprowski wrote:

This patch adds Exynos IPP v2 subsystem and userspace API.

New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback connectors and additional DRM planes with
scaling features.

V2 IPP userspace API is not compatible with old IPP ioctls. This is a
significant change, but the old IPP subsystem in mainline Linux kernel was
partially disfunctional anyway and not used in any open-source project.

V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.

The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
   processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
   formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
   selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
   provided structures (source and destination buffers, operation rectangle,
   transformation, etc).

The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.

Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.

Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.

Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +
  drivers/gpu/drm/exynos/Makefile |   1 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 893 
  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 188 +++
  include/uapi/drm/exynos_drm.h   | 227 
  6 files changed, 1321 insertions(+)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 88cff0e039b6..2e097a81df12 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
  
+config DRM_EXYNOS_IPP

+   bool
+
  config DRM_EXYNOS_FIMC
bool "FIMC"
depends on BROKEN && MFD_SYSCON
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 09bb002c9555..f663490e949d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,6 +17,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7f19054ebce3..645046c5943a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -26,6 +26,7 @@
  #include "exynos_drm_fb.h"
  #include "exynos_drm_gem.h"
  #include "exynos_drm_plane.h"
+#include "exynos_drm_ipp.h"
  #include "exynos_drm_vidi.h"
  #include "exynos_drm_g2d.h"
  #include "exynos_drm_iommu.h"
@@ -114,6 +115,14 @@ static void exynos_drm_lastclose(struct drm_device *dev)
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES, 
exynos_drm_ipp_get_res_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_LIMITS, 
exynos_drm_ipp_get_limits_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IP

[GIT PULL] exynos-drm-fixes

2017-09-20 Thread Inki Dae

Hi Dave,

   Just several regression fixups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 134dd2e616b9cd8300c08cd1b38987ded74f662f:

  Merge tag 'drm-amdkfd-next-2017-09-02' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes (2017-09-18 16:29:47 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v4.14-rc1

for you to fetch changes up to 04fc52fb222d35e1f7a0d5d85b19a676ea1e10e8:

  drm/exynos/hdmi: Fix unsafe list iteration (2017-09-20 12:05:23 +0900)


- fix suspend/resume issues.
- fix memory corruption detected by kasan.
- fix build error on x86.


Arnd Bergmann (1):
  drm: exynos: include linux/irq.h

Maciej Purski (1):
  drm/exynos/hdmi: Fix unsafe list iteration

Marek Szyprowski (2):
  drm/exynos: Fix locking in the suspend/resume paths
  drm/exynos: Fix suspend/resume support

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 36 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 14 ---
 6 files changed, 55 insertions(+), 27 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/6] drm/exynos: ipp: Add IPP v2 framework

2017-09-20 Thread Hoegeun Kwon


Hi Marek,

Tested-by: Hoegeun Kwon 

Best regards,
Hoegeun



On 09/12/2017 05:08 PM, Marek Szyprowski wrote:

This patch adds Exynos IPP v2 subsystem and userspace API.

New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback connectors and additional DRM planes with
scaling features.

V2 IPP userspace API is not compatible with old IPP ioctls. This is a
significant change, but the old IPP subsystem in mainline Linux kernel was
partially disfunctional anyway and not used in any open-source project.

V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.

The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
   processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
   formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
   selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
   provided structures (source and destination buffers, operation rectangle,
   transformation, etc).

The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.

Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.

Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.

Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +
  drivers/gpu/drm/exynos/Makefile |   1 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 893 
  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 188 +++
  include/uapi/drm/exynos_drm.h   | 227 
  6 files changed, 1321 insertions(+)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 88cff0e039b6..2e097a81df12 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
  
+config DRM_EXYNOS_IPP

+   bool
+
  config DRM_EXYNOS_FIMC
bool "FIMC"
depends on BROKEN && MFD_SYSCON
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 09bb002c9555..f663490e949d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,6 +17,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7f19054ebce3..645046c5943a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -26,6 +26,7 @@
  #include "exynos_drm_fb.h"
  #include "exynos_drm_gem.h"
  #include "exynos_drm_plane.h"
+#include "exynos_drm_ipp.h"
  #include "exynos_drm_vidi.h"
  #include "exynos_drm_g2d.h"
  #include "exynos_drm_iommu.h"
@@ -114,6 +115,14 @@ static void exynos_drm_lastclose(struct drm_device *dev)
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES, 
exynos_drm_ipp_get_res_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_LIMITS, 
exynos_drm_ipp_get_limits_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CO

Re: [PATCH 1/6] drm/exynos: ipp: Remove Exynos DRM IPP subsystem

2017-09-20 Thread Hoegeun Kwon


Hi Marek,

Tested-by: Hoegeun Kwon 

Best regards,
Hoegeun


On 09/12/2017 05:08 PM, Marek Szyprowski wrote:

Exynos IPP will be rewritten, so remove current IPP core code and mark
existing drivers as BROKEN.

Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/exynos/Kconfig  |   11 +-
  drivers/gpu/drm/exynos/Makefile |1 -
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   12 -
  drivers/gpu/drm/exynos/exynos_drm_drv.h |2 -
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1806 ---
  drivers/gpu/drm/exynos/exynos_drm_ipp.h |  252 -
  include/uapi/drm/exynos_drm.h   |  192 +---
  7 files changed, 4 insertions(+), 2272 deletions(-)
  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 305dc3d4ff77..88cff0e039b6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,26 +94,21 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
  
-config DRM_EXYNOS_IPP

-   bool "Image Post Processor"
-   help
- Choose this option if you want to use IPP feature for DRM.
-
  config DRM_EXYNOS_FIMC
bool "FIMC"
-   depends on DRM_EXYNOS_IPP && MFD_SYSCON
+   depends on BROKEN && MFD_SYSCON
help
  Choose this option if you want to use Exynos FIMC for DRM.
  
  config DRM_EXYNOS_ROTATOR

bool "Rotator"
-   depends on DRM_EXYNOS_IPP
+   depends on BROKEN
help
  Choose this option if you want to use Exynos Rotator for DRM.
  
  config DRM_EXYNOS_GSC

bool "GScaler"
-   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
  Choose this option if you want to use Exynos GSC for DRM.
  
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile

index f663490e949d..09bb002c9555 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,7 +17,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b1f7299600f0..7f19054ebce3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -28,7 +28,6 @@
  #include "exynos_drm_plane.h"
  #include "exynos_drm_vidi.h"
  #include "exynos_drm_g2d.h"
-#include "exynos_drm_ipp.h"
  #include "exynos_drm_iommu.h"
  
  #define DRIVER_NAME	"exynos"

@@ -115,14 +114,6 @@ static void exynos_drm_lastclose(struct drm_device *dev)
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY, exynos_drm_ipp_get_property,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY, exynos_drm_ipp_set_property,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF, exynos_drm_ipp_queue_buf,
-   DRM_AUTH | DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL, exynos_drm_ipp_cmd_ctrl,
-   DRM_AUTH | DRM_RENDER_ALLOW),
  };
  
  static const struct file_operations exynos_drm_driver_fops = {

@@ -272,9 +263,6 @@ struct exynos_drm_driver_info {
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
}, {
-   DRV_PTR(ipp_driver, CONFIG_DRM_EXYNOS_IPP),
-   DRM_VIRTUAL_DEVICE
-   }, {
&exynos_drm_platform_driver,
DRM_VIRTUAL_DEVICE
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cf131c2aa23e..21f4271c012a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -185,7 +185,6 @@ struct exynos_drm_g2d_private {
  
  struct drm_exynos_file_private {

struct exynos_drm_g2d_private   *g2d_priv;
-   struct device   *ipp_dev;
  };
  
  /*

@@ -292,6 +291,5 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
drm_atomic_state *state,
  extern struct platform_driver fimc_driver;
  extern struct platform_driver rotator_driver;
  extern struct platform_driver gsc_driver;
-extern struct platform

Re: [PATCH 4/6] drm/exynos: gsc: Convert driver to IPP v2 core API

2017-09-20 Thread Hoegeun Kwon


Hi Marek,

Tested-by: Hoegeun Kwon 

Best regards,
Hoegeun



On 09/12/2017 05:08 PM, Marek Szyprowski wrote:

This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.

Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 +
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 853 
  drivers/gpu/drm/exynos/exynos_drm_gsc.h |  24 -
  4 files changed, 198 insertions(+), 683 deletions(-)
  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index c10c9ca0d8b4..4bb9edb00601 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -111,7 +111,8 @@ config DRM_EXYNOS_ROTATOR
  
  config DRM_EXYNOS_GSC

bool "GScaler"
-   depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   depends on ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+   select DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos GSC for DRM.
  
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c

index 277e444b0be6..27242af103ea 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -272,6 +272,7 @@ struct exynos_drm_driver_info {
DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
+   DRM_COMPONENT_DRIVER
}, {
&exynos_drm_platform_driver,
DRM_VIRTUAL_DEVICE
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b17ac1..1293441a4212 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -12,6 +12,7 @@
   *
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -22,8 +23,8 @@
  #include 
  #include "regs-gsc.h"
  #include "exynos_drm_drv.h"
+#include "exynos_drm_iommu.h"
  #include "exynos_drm_ipp.h"
-#include "exynos_drm_gsc.h"
  
  /*

   * GSC stands for General SCaler and
@@ -31,26 +32,9 @@
   * input DMA reads image data from the memory.
   * output DMA writes image data to memory.
   * GSC supports image rotation and image effect functions.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > GSC H/W > Memory.
- * Writeback operation : supports cloned screen with FIMD.
- * FIMD > GSC H/W > Memory.
- * Output operation : supports direct display using local path.
- * Memory > GSC H/W > FIMD, Mixer.
   */
  
-/*

- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. added check_prepare api for right register.
- * 5. need to add supported list in prop_list.
- * 6. check prescaler/scaler optimization.
- */
  
-#define GSC_MAX_DEVS	4

  #define GSC_MAX_SRC   4
  #define GSC_MAX_DST   16
  #define GSC_RESET_TIMEOUT 50
@@ -65,8 +49,6 @@
  #define GSC_SC_DOWN_RATIO_4_8 131072
  #define GSC_SC_DOWN_RATIO_3_8 174762
  #define GSC_SC_DOWN_RATIO_2_8 262144
-#define GSC_REFRESH_MIN12
-#define GSC_REFRESH_MAX60
  #define GSC_CROP_MAX  8192
  #define GSC_CROP_MIN  32
  #define GSC_SCALE_MAX 4224
@@ -79,8 +61,6 @@
  #define GSC_COEF_DEPTH3
  
  #define get_gsc_context(dev)	platform_get_drvdata(to_platform_device(dev))

-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
-   struct gsc_context, ippdrv);
  #define gsc_read(offset)  readl(ctx->regs + (offset))
  #define gsc_write(cfg, offset)writel(cfg, ctx->regs + (offset))
  
@@ -124,7 +104,6 @@ struct gsc_capability {

  /*
   * A structure of gsc context.
   *
- * @ippdrv: prepare initialization using ippdrv.
   * @regs_res: register resources.
   * @regs: memory mapped io registers.
   * @sysreg: handle to SYSREG block regmap.
@@ -137,11 +116,14 @@ struct gsc_capability {
   * @suspended: qos operations.
   */
  struct gsc_context {
-   struct exynos_drm_ippdrvippdrv;
+   struct exynos_drm_ipp ipp;
+   struct drm_device *drm_dev;
+   struct device   *dev;
+   struct exynos_drm_ipp_task  *task;
+
struct resource *regs_res;
void __iomem*regs;
struct regmap   *sysreg;
-   struct mutexlock;
struct clk  *gsc_clk;
struct gsc_scaler   sc;
int id;
@@ -438,25 +420,6 @@ static int gsc_sw_reset(struct gsc_context *ctx)
return 0;
  }
  
-static void gsc_set_gscblk_fimd_wb(struct gsc_context *ctx, bool enable)

-{
-   unsigned int gscblk_cfg;
-
-   if (!ctx->sysreg)
-   return;
-
-   regmap_read(ctx->sysreg, SYS

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #64 from Samuel Pitoiset  ---
See the attached trace from
https://bugs.freedesktop.org/show_bug.cgi?id=102797, it reproduces the same
issue.

So, basically the issue is that wine fails to set the transform feedback
varyings in some situations, this explains why the following message is
reported "fixme:d3d_shader:shader_glsl_generate_transform_feedback_varyings
Unsupported component range 2-2.". Then, the GPU will hang later on because it
will read garbage from a TFB buffer.

About TW3, I think that game uses TFB in some scenarios, I don't know why and
when, maybe it's based on some occlusion queries or some time constraints?
Either way, this might explain why TFB is not used when tracing with apitrace
or when using "GALLIUM_DDEBUG=800" which will flush and wait 800ms after every
draw call.

The attached patches should workaround both issues (TW3 and Superposition), but
wine has to be fixed here.

Please, let the bug open until it's really fixed.

-- 
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 102797] Running unigine superposition benchmark in wine freezes the system

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=102797

Samuel Pitoiset  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Samuel Pitoiset  ---
[..] then Mesa reports the following errors:

Mesa: User error: GL_INVALID_OPERATION in glBeginTransformFeedback(no varyings
to record)
358502: message: major api error 4: GL_INVALID_OPERATION in
glBeginTransformFeedback(no varyings to record)

and the GPU hangs.

If you try the "special varying hack" patch from #101731 it fixes the issue.

*** This bug has been marked as a duplicate of bug 101731 ***

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

Samuel Pitoiset  changed:

   What|Removed |Added

 CC||dark.shad...@web.de

--- Comment #63 from Samuel Pitoiset  ---
*** Bug 102797 has been marked as a duplicate of this bug. ***

-- 
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 102797] Running unigine superposition benchmark in wine freezes the system

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=102797

--- Comment #1 from Samuel Pitoiset  ---
Very interesting stuff! It's similar to the TW3 issue
(https://bugs.freedesktop.org/show_bug.cgi?id=101731).

Basically, Wine doesn't correctly set the transform feedback varyings (ie.
count is 0 in glTransformFeedbackVaryings), then MEsa

-- 
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

[PATCH v3 1/2] staging: ion: simplify ioctl args checking function

2017-09-20 Thread Benjamin Gaignard

Make arguments checking more easy to read.

Signed-off-by: Benjamin Gaignard 
---
 drivers/staging/android/ion/ion-ioctl.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index d9f8b14..e26b786 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -27,19 +27,18 @@ union ion_ioctl_arg {
 
 static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
 {
-   int ret = 0;
-
switch (cmd) {
case ION_IOC_HEAP_QUERY:
-   ret = arg->query.reserved0 != 0;
-   ret |= arg->query.reserved1 != 0;
-   ret |= arg->query.reserved2 != 0;
+   if (arg->query.reserved0 ||
+   arg->query.reserved1 ||
+   arg->query.reserved2 )
+   return -EINVAL;
break;
default:
break;
}
 
-   return ret ? -EINVAL : 0;
+   return 0;
 }
 
 /* fix up the cases where the ioctl direction bits are incorrect */
-- 
2.7.4

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

[PATCH v3 0/2] staging: ion: get one device per heap

2017-09-20 Thread Benjamin Gaignard

version 3:
- change ion_device_add_heap prototype to return a possible error

version 2:
- simplify ioctl check like propose by Dan
- make sure that we don't register more than ION_DEV_MAX heaps

Until now all ion heaps are addressing using the same device "/dev/ion".
This way of working doesn't allow to give access rights (for example with
SElinux rules) per heap.
This series propose to have one device "/dev/ionX" per heap.
Query heaps informations will be possible on each device node but allocation
request will only be possible if heap_mask_id match with device minor number.

That really change ion ABI because:
- device name change
- allocation must be done on the correct device/heap.
- device major number will not be the same and that could impact init scripts.

Even if splitting ion device in multiple node was one of the item of the
de-staging TODO list this must be agreed by a larger audience because it is
(again) an ion ABI bing bang. Hopefully that could be discussed at next XDC
to get a decission on this particular point.

Benjamin Gaignard (2):
  staging: ion: simplify ioctl args checking function
  staging: ion: create one device entry per heap

 drivers/staging/android/TODO|  1 -
 drivers/staging/android/ion/ion-ioctl.c | 20 +---
 drivers/staging/android/ion/ion.c   | 27 ---
 drivers/staging/android/ion/ion.h   | 12 
 4 files changed, 41 insertions(+), 19 deletions(-)

-- 
2.7.4

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

[PATCH v3 2/2] staging: ion: create one device entry per heap

2017-09-20 Thread Benjamin Gaignard

Instead a getting one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.

Allocation requests will be only allowed if the mask_id
match with device minor.
Query request could be done on any of the devices.
Deivce node major will also change and that may impact init scripts.

Signed-off-by: Benjamin Gaignard 
---
version 3:
- change ion_device_add_heap prototype to return a possible error

version 2:
- simplify ioctl check like propose by Dan
- make sure that we don't register more than ION_DEV_MAX heaps

 drivers/staging/android/TODO|  1 -
 drivers/staging/android/ion/ion-ioctl.c | 11 +--
 drivers/staging/android/ion/ion.c   | 27 ---
 drivers/staging/android/ion/ion.h   | 12 
 4 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 5f14247..d770ffa 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -9,7 +9,6 @@ TODO:
 ion/
  - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
involve putting appropriate bindings in a memory node for Ion to find.
- - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
  - Better test framework (integration with VGEM was suggested)
 
 Please send patches to Greg Kroah-Hartman  and Cc:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index e26b786..c8c906c 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -25,8 +25,11 @@ union ion_ioctl_arg {
struct ion_heap_query query;
 };
 
-static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
+static int validate_ioctl_arg(struct file *filp,
+ unsigned int cmd, union ion_ioctl_arg *arg)
 {
+   int mask = 1 << iminor(filp->f_inode);
+
switch (cmd) {
case ION_IOC_HEAP_QUERY:
if (arg->query.reserved0 ||
@@ -34,6 +37,10 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
arg->query.reserved2 )
return -EINVAL;
break;
+   case ION_IOC_ALLOC:
+   if (!(arg->allocation.heap_id_mask & mask))
+   return -EINVAL;
+   break;
default:
break;
}
@@ -69,7 +76,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd)))
return -EFAULT;
 
-   ret = validate_ioctl_arg(cmd, &data);
+   ret = validate_ioctl_arg(filp, cmd, &data);
if (WARN_ON_ONCE(ret))
return ret;
 
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 93e2c90..cc2d381 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,8 @@
 
 #include "ion.h"
 
+#define ION_DEV_MAX 32
+
 static struct ion_device *internal_dev;
 static int heap_id;
 
@@ -537,15 +539,28 @@ static int debug_shrink_get(void *data, u64 *val)
 DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
 
-void ion_device_add_heap(struct ion_heap *heap)
+int ion_device_add_heap(struct ion_heap *heap)
 {
struct dentry *debug_file;
struct ion_device *dev = internal_dev;
+   int ret;
 
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
   __func__);
 
+   if (heap_id >= ION_DEV_MAX)
+   return -EBUSY;
+
+   heap->ddev.devt = MKDEV(MAJOR(dev->devt), heap_id);
+   dev_set_name(&heap->ddev, "ion%d", heap_id);
+   device_initialize(&heap->ddev);
+   cdev_init(&heap->chrdev, &ion_fops);
+   heap->chrdev.owner = THIS_MODULE;
+   ret = cdev_device_add(&heap->chrdev, &heap->ddev);
+   if (ret < 0)
+   return ret;
+
spin_lock_init(&heap->free_lock);
heap->free_list_size = 0;
 
@@ -583,6 +598,8 @@ void ion_device_add_heap(struct ion_heap *heap)
 
dev->heap_cnt++;
up_write(&dev->lock);
+
+   return 0;
 }
 EXPORT_SYMBOL(ion_device_add_heap);
 
@@ -595,13 +612,9 @@ static int ion_device_create(void)
if (!idev)
return -ENOMEM;
 
-   idev->dev.minor = MISC_DYNAMIC_MINOR;
-   idev->dev.name = "ion";
-   idev->dev.fops = &ion_fops;
-   idev->dev.parent = NULL;
-   ret = misc_register(&idev->dev);
+   ret = alloc_chrdev_region(&idev->devt, 0, ION_DEV_MAX, "ion");
if (ret) {
-   pr_err("ion: failed to register misc device.\n");
+   pr_err("ion: unable to allocate major\n");
kf

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #62 from Shmerl  ---
I'll give a try. May be game settings affect what's going on too. For the
reference, I set all to max, except hairworks off. Ambient occlusion: HBAO+.

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #61 from Samuel Pitoiset  ---
Created attachment 134356
  --> https://bugs.freedesktop.org/attachment.cgi?id=134356&action=edit
updated special varying hack

What about this updated patch? (the previous has to be reverted).

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #60 from Samuel Pitoiset  ---
Yeah, I built against the same commit and I'm able to reproduce the link-time
error.

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #59 from Shmerl  ---
Actually, looks like 2.17 is the last one, so their official build should be
just that. It's based on commit bb16263fe1974851f495435fef9a3d57fa2d4aa9

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #58 from Shmerl  ---
I suppose I can also build Wine from that commit and apply all staging patches
including past 2.17.

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #57 from Shmerl  ---
Here is the run with Wine staging 2.17 (MESA_DEBUG set):

ATTENTION: default value of option mesa_glthread overridden by environment.
*** The Witcher 3 SPECIAL HACK ENABLED ***
Mesa: User error: GL_INVALID_OPERATION in glGetUniformLocation(program not
linked)
Mesa: 244 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glUseProgram(program 662 not linked)
Mesa: 1 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glBeginTransformFeedback(no varyings
to record)
Aborted! TFB varyings not correctly set!
source->Id = 250
AL lib: (EE) alc_cleanup: 2 devices not closed

It looks slightly different than before.

-- 
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 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

2017-09-20 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101731

--- Comment #56 from Shmerl  ---
(In reply to Samuel Pitoiset from comment #55)
> Okay, the hack doesn't work for you, Mesa fails to link because the varying
> name is not the same.
> 
> What version of wine are you using? FWIW, I'm building my local copy from
> bb16263fe1974851f495435fef9a3d57fa2d4aa9 with all wine-staging patches
> applied on top of that commit.

Ah, I'm not using full staging, but regular Wine (relatively recent master
build) with minimal patchsets required to run the game (as described here:
https://appdb.winehq.org/objectManager.php?sClass=version&iId=34698#notes ).

Let me try it with full staging 2.17.

-- 
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 >

1 - 100 of 105 matches

Mail list logo