[radeon-alex:amd-staging-dkms-4.13 1197/2206] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3166:1-3: ERROR: test of a variable/field address

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   2b14e1f4fded74b9efeb990869076cebb06d27ee
commit: 3afede44859ca67e2f708fabd854bab152129fda [1197/2206] drm/amdkcl:[4.11] 
fix bug fail to remove debugfs when rmmod


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3166:1-3: ERROR: test of a 
>> variable/field address

vim +3166 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

  3160  
  3161  #if defined(BUILD_AS_DKMS) &&  LINUX_VERSION_CODE < KERNEL_VERSION(4, 
11, 0)
  3162  void amdgpu_debugfs_cleanup(struct drm_minor *minor)
  3163  {
  3164  struct drm_info_node *node, *tmp;
  3165  
> 3166  if (!>debugfs_root)
  3167  return 0;
  3168  
  3169  mutex_lock(>debugfs_lock);
  3170  list_for_each_entry_safe(node, tmp,
  3171  >debugfs_list, list) {
  3172  debugfs_remove(node->dent);
  3173  list_del(>list);
  3174  kfree(node);
  3175  }
  3176  mutex_unlock(>debugfs_lock);
  3177  
  3178  return 0;
  3179  }
  3180  #endif
  3181  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 10/10] drm/rockchip: dw_hdmi: Fix error handling path

[Mark yao]

On 2017年10月19日 11:48, Jeffy Chen wrote:

Add missing clk_disable_unprepare() in bind()'s error handling path and
unbind().

Also inline clk_prepare_enable() with bind().

Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
Signed-off-by: Jeffy Chen


Looks good for me
Acked-by: Mark Yao 

Mark


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

Re: [PATCH v6 07/10] drm/rockchip: inno_hdmi: Fix error handling path

[Mark yao]

On 2017年10月19日 11:48, Jeffy Chen wrote:

Add missing error handling in bind().

Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: Jeffy Chen


Looks good for me
Acked-by: Mark Yao 

Mark


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

Re: [PATCH v6 06/10] drm/rockchip: dw-mipi-dsi: Fix error handling path

[Mark yao]

On 2017年10月19日 11:48, Jeffy Chen wrote:

Add missing pm_runtime_disable() in bind()'s error handling path.

Also cleanup encoder & connector in unbind().

Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
Signed-off-by: Jeffy Chen


Looks good for me
Acked-by: Mark Yao 

Mark


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

Re: [PATCH v6 05/10] drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register()

[Mark yao]

On 2017年10月19日 11:48, Jeffy Chen wrote:

The rockchip_drm_psr_register() can fail, so add a sanity check for that.

Also reorder the calls in unbind() to match bind().

Signed-off-by: Jeffy Chen


Looks good for me
Acked-by: Mark Yao 

Mark


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

Re: [PATCH v6 02/10] drm/rockchip: analogix_dp: Remove unnecessary init code

[Mark yao]

On 2017年10月19日 11:48, Jeffy Chen wrote:

Remove unnecessary init code, since we would do it in the power_on()
callback.

Also move of parse code to probe().

Fixes: 9e32e16e9e98 ("drm: rockchip: dp: add rockchip platform dp driver")
Signed-off-by: Jeffy Chen 


Looks good for me
Acked-by: Mark Yao 


---

Changes in v6: None
Changes in v5: None

  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 27 ++---
  1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 4d3f6ad0abdd..8cae5ad926cd 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -269,7 +269,7 @@ static struct drm_encoder_funcs rockchip_dp_encoder_funcs = 
{
.destroy = rockchip_dp_drm_encoder_destroy,
  };
  
-static int rockchip_dp_init(struct rockchip_dp_device *dp)

+static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
  {
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
@@ -303,19 +303,6 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
return PTR_ERR(dp->rst);
}
  
-	ret = clk_prepare_enable(dp->pclk);

-   if (ret < 0) {
-   DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
-   return ret;
-   }
-
-   ret = rockchip_dp_pre_init(dp);
-   if (ret < 0) {
-   DRM_DEV_ERROR(dp->dev, "failed to pre init %d\n", ret);
-   clk_disable_unprepare(dp->pclk);
-   return ret;
-   }
-
return 0;
  }
  
@@ -361,10 +348,6 @@ static int rockchip_dp_bind(struct device *dev, struct device *master,

if (!dp_data)
return -ENODEV;
  
-	ret = rockchip_dp_init(dp);

-   if (ret < 0)
-   return ret;
-
dp->data = dp_data;
dp->drm_dev = drm_dev;
  
@@ -398,7 +381,6 @@ static void rockchip_dp_unbind(struct device *dev, struct device *master,

rockchip_drm_psr_unregister(>encoder);
  
  	analogix_dp_unbind(dev, master, data);

-   clk_disable_unprepare(dp->pclk);
  }
  
  static const struct component_ops rockchip_dp_component_ops = {

@@ -414,7 +396,7 @@ static int rockchip_dp_probe(struct platform_device *pdev)
int ret;
  
  	ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, , NULL);

-   if (ret)
+   if (ret < 0)
return ret;
  
  	dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);

@@ -422,9 +404,12 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return -ENOMEM;
  
  	dp->dev = dev;

-
dp->plat_data.panel = panel;
  
+	ret = rockchip_dp_of_probe(dp);

+   if (ret < 0)
+   return ret;
+
/*
 * We just use the drvdata until driver run into component
 * add function, and then we would set drvdata to null, so


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

Re: [PATCH v2] drm/rockchip: Use an enum to identify Rockchip VOPs

[Mark yao]

On 2017年10月20日 01:46, Kristian Høgsberg wrote:

On Wed, Oct 18, 2017 at 5:49 PM, Mark yao  wrote:

On 2017年10月19日 01:52, Brian Norris wrote:

Hi Kristian,

On Thu, Nov 03, 2016 at 12:46:48PM -0700, Kristian Högsberg wrote:

We used to call drm_of_encoder_active_endpoint_id() from
rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the
active encoder. However, the encoder isn't necessarily active at this
point or it may be connected to different crtc than what we're switching
to. Instead, look at the crtc from the drm_crtc_state.  This fixes wrong
colors when driving the eDP with the big VOP.  Further, we can identify
the type of VOP we're dealing with by just putting a VOP id enum in the
vop_data.


Unfortunately, vop iomux and vop data are not one-to-one correspondence.

Such as rk3288, vop big and vop little both use rk3288_vop data, if you use
vop data id will not be able
to distinguish between them.

What would you suggest then? We need this to be able to drive eDP from
the big VOP. We've been carrying this patch for quite a while and it
hasn't regressed neither rk3288 nor rk3399 boards.

Kristian


Mark


On way to test this is to use the modetest tool from libdrm:

$ modetest -M rockchip -s 32@28:2400x1600

which displays dark or black colors because we fail to look up the
endpoint and use default 0 (which is ROCKCHIP_OUT_MODE_P888) for big
VOP instead of RGB10 as required.


The display issue already be fixed, and your kernel seems old
See the patch: 
http://patchwork.freedesktop.org/patch/msgid/1495885416-22216-1-git-send-email-mark@rock-chips.com

Now eDP always set its outmode as ROCKCHIP_OUT_MODE_.

And on vop driver, force RGB10 to RGB888 if vop not support rgb10bit.
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:
/*
 * if vop is not support RGB10 output, need force RGB10 to RGB888.
 */
if (s->output_mode == ROCKCHIP_OUT_MODE_ &&
!(vop_data->feature & VOP_FEATURE_OUTPUT_RGB10))
s->output_mode = ROCKCHIP_OUT_MODE_P888;

Thanks.


For reference,

$ modetest -M rockchip -s 32@25:2400x1600

drives the eDP from little VOP and displays correctly.

Signed-off-by: Kristian H. Kristensen 
---
v2: Stripped chromeos annotations, fix compile errors for drivers I
didn't
compile when I first wrote the patch.

Do you plan to fix the errors Guenter pointed out and resend? This is
still causing conflicts between our ChromeOS kernel trees and upstream.

Also, please CC linux-rockchip on Rockchip-related patches. It's much
easier for me to find your work that way :)

Brian


drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 45
++---
   drivers/gpu/drm/rockchip/cdn-dp-core.c  | 19 +--
   drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 12 ---
   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 
   drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++
   drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  4 +++
   6 files changed, 56 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 558a3bc..9ae4a9c 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -196,14 +196,16 @@ static void rockchip_dp_drm_encoder_enable(struct
drm_encoder *encoder)
 int ret;
 u32 val;
   - ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
encoder);
-   if (ret < 0)
-   return;
-
-   if (ret)
+   switch (vop_get_crtc_vop_id(encoder->crtc)) {
+   case RK3399_VOP_LIT:
 val = dp->data->lcdsel_lit;
-   else
+   break;
+   case RK3399_VOP_BIG:
 val = dp->data->lcdsel_big;
+   break;
+   default:
+   return;
+   }
 dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
   @@ -231,34 +233,23 @@ rockchip_dp_drm_encoder_atomic_check(struct
drm_encoder *encoder,
   struct drm_connector_state
*conn_state)
   {
 struct rockchip_crtc_state *s =
to_rockchip_crtc_state(crtc_state);
-   struct rockchip_dp_device *dp = to_dp(encoder);
-   int ret;
   - /*
-* The hardware IC designed that VOP must output the RGB10 video
-* format to eDP contoller, and if eDP panel only support RGB8,
-* then eDP contoller should cut down the video data, not via VOP
-* contoller, that's why we need to hardcode the VOP output mode
-* to RGA10 here.
-*/
-
-   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
encoder);
-   if (ret < 0)
-   return 0;
-
-   switch (dp->data->chip_type) {
-   case RK3399_EDP:
+   switch (vop_get_crtc_vop_id(crtc_state->crtc)) {
+   case RK3399_VOP_LIT:
 /*
  * For RK3399, VOP Lit must 

[PATCH] drm/panel: rpi-touchscreen: propagate errors in rpi_touchscreen_i2c_read()

[Dan Carpenter]

There is one caller which checks whether rpi_touchscreen_i2c_read()
returns negative error codes.  Currently it can't because negative
error codes are truncated to u8, but that's easy to fix if we change the
type to int.

Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7" 
Touchscreen.")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 890fd6ff397c..d964d454e4ae 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -221,7 +221,7 @@ static struct rpi_touchscreen *panel_to_ts(struct drm_panel 
*panel)
return container_of(panel, struct rpi_touchscreen, base);
 }
 
-static u8 rpi_touchscreen_i2c_read(struct rpi_touchscreen *ts, u8 reg)
+static int rpi_touchscreen_i2c_read(struct rpi_touchscreen *ts, u8 reg)
 {
return i2c_smbus_read_byte_data(ts->i2c, reg);
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 13/15] drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Mark Yao 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 9 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 9 +
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 76d63de5921d..d85431400a0d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -207,13 +207,6 @@ static void rockchip_drm_unbind(struct device *dev)
drm_dev_unref(drm_dev);
 }
 
-static void rockchip_drm_lastclose(struct drm_device *dev)
-{
-   struct rockchip_drm_private *priv = dev->dev_private;
-
-   drm_fb_helper_restore_fbdev_mode_unlocked(>fbdev_helper);
-}
-
 static const struct file_operations rockchip_drm_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -228,7 +221,7 @@ static const struct file_operations 
rockchip_drm_driver_fops = {
 static struct drm_driver rockchip_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM |
  DRIVER_PRIME | DRIVER_ATOMIC,
-   .lastclose  = rockchip_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.gem_vm_ops = _gem_cma_vm_ops,
.gem_free_object_unlocked = rockchip_gem_free_object,
.dumb_create= rockchip_gem_dumb_create,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index cd2ace0c3caa..e266539e04e5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -167,20 +167,13 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(ret);
 }
 
-static void rockchip_drm_output_poll_changed(struct drm_device *dev)
-{
-   struct rockchip_drm_private *private = dev->dev_private;
-
-   drm_fb_helper_hotplug_event(>fbdev_helper);
-}
-
 static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers 
= {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
 };
 
 static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
.fb_create = rockchip_user_fb_create,
-   .output_poll_changed = rockchip_drm_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
-- 
2.14.2

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

[PATCH 11/15] drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Tomi Valkeinen 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 34 ++
 1 file changed, 2 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index cdf5b0601eba..96857c508ee0 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -46,14 +46,6 @@
  * devices
  */
 
-static void omap_fb_output_poll_changed(struct drm_device *dev)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   DBG("dev=%p", dev);
-   if (priv->fbdev)
-   drm_fb_helper_hotplug_event(priv->fbdev);
-}
-
 static void omap_atomic_wait_for_completion(struct drm_device *dev,
struct drm_atomic_state *old_state)
 {
@@ -132,7 +124,7 @@ static const struct drm_mode_config_helper_funcs 
omap_mode_config_helper_funcs =
 
 static const struct drm_mode_config_funcs omap_mode_config_funcs = {
.fb_create = omap_framebuffer_create,
-   .output_poll_changed = omap_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
@@ -467,28 +459,6 @@ static int dev_open(struct drm_device *dev, struct 
drm_file *file)
return 0;
 }
 
-/**
- * lastclose - clean up after all DRM clients have exited
- * @dev: DRM device
- *
- * Take care of cleaning up after all DRM clients have exited.  In the
- * mode setting case, we want to restore the kernel's initial mode (just
- * in case the last client left us in a bad state).
- */
-static void dev_lastclose(struct drm_device *dev)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   int ret;
-
-   DBG("lastclose: dev=%p", dev);
-
-   if (priv->fbdev) {
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-   if (ret)
-   DBG("failed to restore crtc mode");
-   }
-}
-
 static const struct vm_operations_struct omap_gem_vm_ops = {
.fault = omap_gem_fault,
.open = drm_gem_vm_open,
@@ -511,7 +481,7 @@ static struct drm_driver omap_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM  | DRIVER_PRIME |
DRIVER_ATOMIC | DRIVER_RENDER,
.open = dev_open,
-   .lastclose = dev_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
 #endif
-- 
2.14.2

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

[PATCH 12/15] drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() in its .lastclose function.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/radeon/radeon_display.c |  9 ++---
 drivers/gpu/drm/radeon/radeon_fb.c  | 22 --
 drivers/gpu/drm/radeon/radeon_kms.c |  5 ++---
 drivers/gpu/drm/radeon/radeon_mode.h|  3 ---
 4 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index ddfe91efa61e..dfda5e0ed166 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1362,15 +1363,9 @@ radeon_user_framebuffer_create(struct drm_device *dev,
return _fb->base;
 }
 
-static void radeon_output_poll_changed(struct drm_device *dev)
-{
-   struct radeon_device *rdev = dev->dev_private;
-   radeon_fb_output_poll_changed(rdev);
-}
-
 static const struct drm_mode_config_funcs radeon_mode_funcs = {
.fb_create = radeon_user_framebuffer_create,
-   .output_poll_changed = radeon_output_poll_changed
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static const struct drm_prop_enum_list radeon_tmds_pll_enum_list[] =
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index 2fcf805d3a16..8a582af52073 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -307,12 +307,6 @@ static int radeonfb_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void radeon_fb_output_poll_changed(struct radeon_device *rdev)
-{
-   if (rdev->mode_info.rfbdev)
-   drm_fb_helper_hotplug_event(>mode_info.rfbdev->helper);
-}
-
 static int radeon_fbdev_destroy(struct drm_device *dev, struct radeon_fbdev 
*rfbdev)
 {
struct radeon_framebuffer *rfb = >rfb;
@@ -423,19 +417,3 @@ void radeon_fb_remove_connector(struct radeon_device 
*rdev, struct drm_connector
if (rdev->mode_info.rfbdev)

drm_fb_helper_remove_one_connector(>mode_info.rfbdev->helper, connector);
 }
-
-void radeon_fbdev_restore_mode(struct radeon_device *rdev)
-{
-   struct radeon_fbdev *rfbdev = rdev->mode_info.rfbdev;
-   struct drm_fb_helper *fb_helper;
-   int ret;
-
-   if (!rfbdev)
-   return;
-
-   fb_helper = >helper;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-}
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index dfee8f7d94ae..e4c1bb8c21fa 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -26,6 +26,7 @@
  *  Jerome Glisse
  */
 #include 
+#include 
 #include "radeon.h"
 #include 
 #include "radeon_asic.h"
@@ -636,9 +637,7 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  */
 void radeon_driver_lastclose_kms(struct drm_device *dev)
 {
-   struct radeon_device *rdev = dev->dev_private;
-
-   radeon_fbdev_restore_mode(rdev);
+   drm_fb_helper_lastclose(dev);
vga_switcheroo_process_delayed_switch();
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index da44ac234f64..567156a7beae 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -988,9 +988,6 @@ int radeon_fbdev_init(struct radeon_device *rdev);
 void radeon_fbdev_fini(struct radeon_device *rdev);
 void radeon_fbdev_set_suspend(struct radeon_device *rdev, int state);
 bool radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo 
*robj);
-void radeon_fbdev_restore_mode(struct radeon_device *rdev);
-
-void radeon_fb_output_poll_changed(struct radeon_device *rdev);
 
 void radeon_crtc_handle_vblank(struct radeon_device *rdev, int crtc_id);
 
-- 
2.14.2

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

[PATCH 14/15] drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Thierry Reding 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tegra/drm.c | 13 ++---
 drivers/gpu/drm/tegra/drm.h |  4 
 drivers/gpu/drm/tegra/fb.c  | 14 --
 3 files changed, 2 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 597d563d636a..73bca7ac1271 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -120,7 +120,7 @@ static int tegra_atomic_commit(struct drm_device *drm,
 static const struct drm_mode_config_funcs tegra_drm_mode_funcs = {
.fb_create = tegra_fb_create,
 #ifdef CONFIG_DRM_FBDEV_EMULATION
-   .output_poll_changed = tegra_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 #endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = tegra_atomic_commit,
@@ -287,15 +287,6 @@ static void tegra_drm_context_free(struct 
tegra_drm_context *context)
kfree(context);
 }
 
-static void tegra_drm_lastclose(struct drm_device *drm)
-{
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   struct tegra_drm *tegra = drm->dev_private;
-
-   tegra_fbdev_restore_mode(tegra->fbdev);
-#endif
-}
-
 static struct host1x_bo *
 host1x_bo_lookup(struct drm_file *file, u32 handle)
 {
@@ -1100,7 +1091,7 @@ static struct drm_driver tegra_drm_driver = {
.unload = tegra_drm_unload,
.open = tegra_drm_open,
.postclose = tegra_drm_postclose,
-   .lastclose = tegra_drm_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = tegra_debugfs_init,
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 063f5d397526..55b6aff25b9b 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -290,10 +290,6 @@ int tegra_drm_fb_init(struct drm_device *drm);
 void tegra_drm_fb_exit(struct drm_device *drm);
 void tegra_drm_fb_suspend(struct drm_device *drm);
 void tegra_drm_fb_resume(struct drm_device *drm);
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
-void tegra_fb_output_poll_changed(struct drm_device *drm);
-#endif
 
 extern struct platform_driver tegra_dc_driver;
 extern struct platform_driver tegra_hdmi_driver;
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 80540c1c66dc..8dfe3c6c217e 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -361,20 +361,6 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
drm_fb_helper_fini(>base);
tegra_fbdev_free(fbdev);
 }
-
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev)
-{
-   if (fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(>base);
-}
-
-void tegra_fb_output_poll_changed(struct drm_device *drm)
-{
-   struct tegra_drm *tegra = drm->dev_private;
-
-   if (tegra->fbdev)
-   drm_fb_helper_hotplug_event(>fbdev->base);
-}
 #endif
 
 int tegra_drm_fb_prepare(struct drm_device *drm)
-- 
2.14.2

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

[PATCH 15/15] staging: vboxvideo: Use drm_fb_helper_lastclose()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.

Cc: Hans de Goede 
Signed-off-by: Noralf Trønnes 
---
 drivers/staging/vboxvideo/vbox_drv.c  |  2 +-
 drivers/staging/vboxvideo/vbox_drv.h  |  1 -
 drivers/staging/vboxvideo/vbox_main.c | 12 
 3 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_drv.c 
b/drivers/staging/vboxvideo/vbox_drv.c
index e18642e5027e..a4d8d7898e3d 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -229,7 +229,7 @@ static struct drm_driver driver = {
 
.load = vbox_driver_load,
.unload = vbox_driver_unload,
-   .lastclose = vbox_driver_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
.master_set = vbox_master_set,
.master_drop = vbox_master_drop,
 
diff --git a/drivers/staging/vboxvideo/vbox_drv.h 
b/drivers/staging/vboxvideo/vbox_drv.h
index 4b9302703b36..7273d7e9bc9b 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -128,7 +128,6 @@ struct vbox_private {
 
 int vbox_driver_load(struct drm_device *dev, unsigned long flags);
 void vbox_driver_unload(struct drm_device *dev);
-void vbox_driver_lastclose(struct drm_device *dev);
 
 struct vbox_gem_object;
 
diff --git a/drivers/staging/vboxvideo/vbox_main.c 
b/drivers/staging/vboxvideo/vbox_main.c
index 80bd039fa08e..c3d756620fd5 100644
--- a/drivers/staging/vboxvideo/vbox_main.c
+++ b/drivers/staging/vboxvideo/vbox_main.c
@@ -421,18 +421,6 @@ void vbox_driver_unload(struct drm_device *dev)
vbox_hw_fini(vbox);
 }
 
-/**
- * @note this is described in the DRM framework documentation.  AST does not
- * have it, but we get an oops on driver unload if it is not present.
- */
-void vbox_driver_lastclose(struct drm_device *dev)
-{
-   struct vbox_private *vbox = dev->dev_private;
-
-   if (vbox->fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(>fbdev->helper);
-}
-
 int vbox_gem_create(struct drm_device *dev,
u32 size, bool iskernel, struct drm_gem_object **obj)
 {
-- 
2.14.2

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

[PATCH 10/15] drm/nouveau: Use drm_fb_helper_output_poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_output_poll_changed() instead of
its own nouveau_fbcon_output_poll_changed().

Cc: Ben Skeggs 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 3 ++-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 8 
 drivers/gpu/drm/nouveau/nouveau_fbcon.h   | 2 --
 drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
 drivers/gpu/drm/nouveau/nv50_display.c| 2 +-
 5 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 2e7785f49e6d..009713404cc4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -292,7 +293,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
 
 static const struct drm_mode_config_funcs nouveau_mode_config_funcs = {
.fb_create = nouveau_user_framebuffer_create,
-   .output_poll_changed = nouveau_fbcon_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index f7707849bb53..60ca03c27ec4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -411,14 +411,6 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void
-nouveau_fbcon_output_poll_changed(struct drm_device *dev)
-{
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   if (drm->fbcon)
-   drm_fb_helper_hotplug_event(>fbcon->helper);
-}
-
 static int
 nouveau_fbcon_destroy(struct drm_device *dev, struct nouveau_fbdev *fbcon)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.h 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
index e2bca729721e..a6f192ea3fa6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.h
@@ -68,8 +68,6 @@ void nouveau_fbcon_set_suspend(struct drm_device *dev, int 
state);
 void nouveau_fbcon_accel_save_disable(struct drm_device *dev);
 void nouveau_fbcon_accel_restore(struct drm_device *dev);
 
-void nouveau_fbcon_output_poll_changed(struct drm_device *dev);
-
 extern int nouveau_nofbaccel;
 
 #endif /* __NV50_FBCON_H__ */
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 48393a4f6331..ac97c30c5bbd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_acpi.h"
@@ -60,7 +61,7 @@ static void
 nouveau_switcheroo_reprobe(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
-   nouveau_fbcon_output_poll_changed(dev);
+   drm_fb_helper_output_poll_changed(dev);
 }
 
 static bool
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 2dbf62a2ac41..5b3db08e50e4 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4308,7 +4308,7 @@ nv50_disp_atomic_state_alloc(struct drm_device *dev)
 static const struct drm_mode_config_funcs
 nv50_disp_func = {
.fb_create = nouveau_user_framebuffer_create,
-   .output_poll_changed = nouveau_fbcon_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = nv50_disp_atomic_check,
.atomic_commit = nv50_disp_atomic_commit,
.atomic_state_alloc = nv50_disp_atomic_state_alloc,
-- 
2.14.2

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

[PATCH 07/15] drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Patrik Jakobsson 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/gma500/framebuffer.c |  9 +
 drivers/gpu/drm/gma500/psb_drv.c | 15 +--
 2 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 2570c7f647a6..cb0a2ae916e0 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -576,13 +576,6 @@ static void psb_fbdev_fini(struct drm_device *dev)
dev_priv->fbdev = NULL;
 }
 
-static void psbfb_output_poll_changed(struct drm_device *dev)
-{
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_fbdev *fbdev = (struct psb_fbdev *)dev_priv->fbdev;
-   drm_fb_helper_hotplug_event(>psb_fb_helper);
-}
-
 /**
  * psb_user_framebuffer_create_handle - add hamdle to a framebuffer
  * @fb: framebuffer
@@ -623,7 +616,7 @@ static void psb_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 
 static const struct drm_mode_config_funcs psb_mode_funcs = {
.fb_create = psb_user_framebuffer_create,
-   .output_poll_changed = psbfb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static void psb_setup_outputs(struct drm_device *dev)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 37a3be71acd9..7ab4c532f1d4 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -107,19 +107,6 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
 static const struct drm_ioctl_desc psb_ioctls[] = {
 };
 
-static void psb_driver_lastclose(struct drm_device *dev)
-{
-   int ret;
-   struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_fbdev *fbdev = dev_priv->fbdev;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(>psb_fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-
-   return;
-}
-
 static int psb_do_init(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
@@ -479,7 +466,7 @@ static struct drm_driver driver = {
   DRIVER_MODESET | DRIVER_GEM,
.load = psb_driver_load,
.unload = psb_driver_unload,
-   .lastclose = psb_driver_lastclose,
+   .lastclose = drm_fb_helper_lastclose,
 
.num_ioctls = ARRAY_SIZE(psb_ioctls),
.irq_preinstall = psb_irq_preinstall,
-- 
2.14.2

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

[PATCH 03/15] drm/fb-helper: Add .last_close and .output_poll_changed helpers

[Noralf Trønnes]

This adds helpers for the drm_driver->last_close and the
drm_mode_config_funcs->output_poll_changed callbacks.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 28 
 include/drm/drm_fb_helper.h | 11 +++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c07b7af8de4c..5f32c11eb0d2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2633,6 +2633,34 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
 
+/**
+ * drm_fb_helper_lastclose - DRM driver lastclose helper for fbdev emulation
+ * @dev: DRM device
+ *
+ * This function can be used as the _driver->lastclose callback for drivers
+ * that only need to call drm_fb_helper_restore_fbdev_mode_unlocked().
+ */
+void drm_fb_helper_lastclose(struct drm_device *dev)
+{
+   drm_fb_helper_restore_fbdev_mode_unlocked(dev->drm_fb_helper_private);
+}
+EXPORT_SYMBOL(drm_fb_helper_lastclose);
+
+/**
+ * drm_fb_helper_output_poll_changed - DRM mode config \.output_poll_changed
+ * helper for fbdev emulation
+ * @dev: DRM device
+ *
+ * This function can be used as the
+ * _mode_config_funcs.output_poll_changed callback for drivers that only
+ * need to call drm_fb_helper_hotplug_event().
+ */
+void drm_fb_helper_output_poll_changed(struct drm_device *dev)
+{
+   drm_fb_helper_hotplug_event(dev->drm_fb_helper_private);
+}
+EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
+
 /* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT)
  * but the module doesn't depend on any fb console symbols.  At least
  * attempt to load fbcon to avoid leaving the system without a usable console.
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 33fe95927742..877e5b395c02 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -310,6 +310,9 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector 
*fb_helper_conn);
 int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
drm_connector *connector);
 int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
   struct drm_connector *connector);
+
+void drm_fb_helper_lastclose(struct drm_device *dev);
+void drm_fb_helper_output_poll_changed(struct drm_device *dev);
 #else
 static inline void drm_fb_helper_prepare(struct drm_device *dev,
struct drm_fb_helper *helper,
@@ -507,6 +510,14 @@ drm_fb_helper_remove_one_connector(struct drm_fb_helper 
*fb_helper,
return 0;
 }
 
+static inline void drm_fb_helper_lastclose(struct drm_device *dev)
+{
+}
+
+static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev)
+{
+}
+
 #endif
 
 static inline int
-- 
2.14.2

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

[PATCH 01/15] drm/fb-helper: Handle function NULL argument

[Noralf Trønnes]

Make functions tolerate that the drm_fb_helper argument is NULL.
This is useful for drivers that continue probing when fbdev emulation
fails and not having to do this check themselves.
Update docs for functions that already handles this.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 116d1f1337c7..954cdd48de92 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -150,6 +150,9 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper,
 {
int err;
 
+   if (!fb_helper)
+   return 0;
+
mutex_lock(_helper->lock);
err = __drm_fb_helper_add_one_connector(fb_helper, connector);
mutex_unlock(_helper->lock);
@@ -161,7 +164,7 @@ EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
 /**
  * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
  *emulation helper
- * @fb_helper: fbdev initialized with drm_fb_helper_init
+ * @fb_helper: fbdev initialized with drm_fb_helper_init, can be NULL
  *
  * This functions adds all the available connectors for use with the given
  * fb_helper. This is a separate step to allow drivers to freely assign
@@ -179,7 +182,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
struct drm_connector_list_iter conn_iter;
int i, ret = 0;
 
-   if (!drm_fbdev_emulation)
+   if (!drm_fbdev_emulation || !fb_helper)
return 0;
 
mutex_lock(_helper->lock);
@@ -245,6 +248,9 @@ int drm_fb_helper_remove_one_connector(struct drm_fb_helper 
*fb_helper,
 {
int err;
 
+   if (!fb_helper)
+   return 0;
+
mutex_lock(_helper->lock);
err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
mutex_unlock(_helper->lock);
@@ -484,7 +490,7 @@ static int restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
 
 /**
  * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
- * @fb_helper: fbcon to restore
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * This should be called from driver's drm _driver.lastclose callback
  * when implementing an fbcon on top of kms using this helper. This ensures 
that
@@ -498,7 +504,7 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
bool do_delayed;
int ret;
 
-   if (!drm_fbdev_emulation)
+   if (!drm_fbdev_emulation || !fb_helper)
return -ENODEV;
 
if (READ_ONCE(fb_helper->deferred_setup))
@@ -883,7 +889,7 @@ EXPORT_SYMBOL(drm_fb_helper_alloc_fbi);
 
 /**
  * drm_fb_helper_unregister_fbi - unregister fb_info framebuffer device
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * A wrapper around unregister_framebuffer, to release the fb_info
  * framebuffer device. This must be called before releasing all resources for
@@ -898,7 +904,7 @@ EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
 
 /**
  * drm_fb_helper_fini - finialize a  drm_fb_helper
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * This cleans up all remaining resources associated with @fb_helper. Must be
  * called after drm_fb_helper_unlink_fbi() was called.
@@ -937,7 +943,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
 
 /**
  * drm_fb_helper_unlink_fbi - wrapper around unlink_framebuffer
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  *
  * A wrapper around unlink_framebuffer implemented by fbdev core
  */
@@ -1138,7 +1144,7 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
 
 /**
  * drm_fb_helper_set_suspend - wrapper around fb_set_suspend
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  * @suspend: whether to suspend or resume
  *
  * A wrapper around fb_set_suspend implemented by fbdev core.
@@ -1155,7 +1161,7 @@ EXPORT_SYMBOL(drm_fb_helper_set_suspend);
 /**
  * drm_fb_helper_set_suspend_unlocked - wrapper around fb_set_suspend that also
  *  takes the console lock
- * @fb_helper: driver-allocated fbdev helper
+ * @fb_helper: driver-allocated fbdev helper, can be NULL
  * @suspend: whether to suspend or resume
  *
  * A wrapper around fb_set_suspend() that takes the console lock. If the lock
@@ -2568,7 +2574,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
 /**
  * drm_fb_helper_hotplug_event - respond to a hotplug notification by
  *   probing all the outputs attached to the fb
- * @fb_helper: the drm_fb_helper
+ * @fb_helper: driver-allocated fbdev helper, can be 

[PATCH 04/15] drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() in its .lastclose function.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  9 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  | 27 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  4 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|  4 
 4 files changed, 3 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 6ad243293a78..c41262865616 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void amdgpu_flip_callback(struct dma_fence *f, struct dma_fence_cb *cb)
 {
@@ -556,15 +557,9 @@ amdgpu_user_framebuffer_create(struct drm_device *dev,
return _fb->base;
 }
 
-static void amdgpu_output_poll_changed(struct drm_device *dev)
-{
-   struct amdgpu_device *adev = dev->dev_private;
-   amdgpu_fb_output_poll_changed(adev);
-}
-
 const struct drm_mode_config_funcs amdgpu_mode_funcs = {
.fb_create = amdgpu_user_framebuffer_create,
-   .output_poll_changed = amdgpu_output_poll_changed
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
 };
 
 static const struct drm_prop_enum_list amdgpu_underscan_enum_list[] =
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 562930b17a6d..e38bf856f48b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -288,12 +288,6 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
return ret;
 }
 
-void amdgpu_fb_output_poll_changed(struct amdgpu_device *adev)
-{
-   if (adev->mode_info.rfbdev)
-   drm_fb_helper_hotplug_event(>mode_info.rfbdev->helper);
-}
-
 static int amdgpu_fbdev_destroy(struct drm_device *dev, struct amdgpu_fbdev 
*rfbdev)
 {
struct amdgpu_framebuffer *rfb = >rfb;
@@ -397,24 +391,3 @@ bool amdgpu_fbdev_robj_is_fb(struct amdgpu_device *adev, 
struct amdgpu_bo *robj)
return true;
return false;
 }
-
-void amdgpu_fbdev_restore_mode(struct amdgpu_device *adev)
-{
-   struct amdgpu_fbdev *afbdev;
-   struct drm_fb_helper *fb_helper;
-   int ret;
-
-   if (!adev)
-   return;
-
-   afbdev = adev->mode_info.rfbdev;
-
-   if (!afbdev)
-   return;
-
-   fb_helper = >helper;
-
-   ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 4fd06f8d9768..db1e320be54a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -785,9 +785,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  */
 void amdgpu_driver_lastclose_kms(struct drm_device *dev)
 {
-   struct amdgpu_device *adev = dev->dev_private;
-
-   amdgpu_fbdev_restore_mode(adev);
+   drm_fb_helper_lastclose(dev);
vga_switcheroo_process_delayed_switch();
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 2af2678ddaf6..9e9cd0e1c558 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -570,10 +570,6 @@ void amdgpu_fbdev_fini(struct amdgpu_device *adev);
 void amdgpu_fbdev_set_suspend(struct amdgpu_device *adev, int state);
 int amdgpu_fbdev_total_size(struct amdgpu_device *adev);
 bool amdgpu_fbdev_robj_is_fb(struct amdgpu_device *adev, struct amdgpu_bo 
*robj);
-void amdgpu_fbdev_restore_mode(struct amdgpu_device *adev);
-
-void amdgpu_fb_output_poll_changed(struct amdgpu_device *adev);
-
 
 int amdgpu_align_pitch(struct amdgpu_device *adev, int width, int bpp, bool 
tiled);
 
-- 
2.14.2

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

[PATCH 08/15] drm/i915: Use drm_fb_helper_output_poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_drv.h | 5 -
 drivers/gpu/drm/i915/intel_fbdev.c   | 8 
 3 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f780f39e0758..b205e2c782bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14123,7 +14123,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)
 static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
.get_format_info = intel_get_format_info,
-   .output_poll_changed = intel_fbdev_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
.atomic_state_alloc = intel_atomic_state_alloc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 463ed152e6b1..dfcf5ba220e8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1607,7 +1607,6 @@ extern void intel_fbdev_initial_config_async(struct 
drm_device *dev);
 extern void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
 extern void intel_fbdev_fini(struct drm_i915_private *dev_priv);
 extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool 
synchronous);
-extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
 extern void intel_fbdev_restore_mode(struct drm_device *dev);
 #else
 static inline int intel_fbdev_init(struct drm_device *dev)
@@ -1631,10 +1630,6 @@ static inline void intel_fbdev_set_suspend(struct 
drm_device *dev, int state, bo
 {
 }
 
-static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
-{
-}
-
 static inline void intel_fbdev_restore_mode(struct drm_device *dev)
 {
 }
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index f2bb8116227c..35babbadfc5a 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -796,14 +796,6 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
state, bool synchronous
console_unlock();
 }
 
-void intel_fbdev_output_poll_changed(struct drm_device *dev)
-{
-   struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
-
-   if (ifbdev)
-   drm_fb_helper_hotplug_event(>helper);
-}
-
 void intel_fbdev_restore_mode(struct drm_device *dev)
 {
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
-- 
2.14.2

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

[PATCH 00/15] drm/fb-helper: Add .last_close and .output_poll_changed helpers

[Noralf Trønnes]

This patchset adds fbdev .last_close and .output_poll_changed helpers to
reduce fbdev emulation footprint in drivers.

I don't know which drivers have their own tree or not, so if you want me
to apply your patch to drm-misc, please let me know.

I will do a separate patchset for the cma helper drivers.

Noralf.

Noralf Trønnes (15):
  drm/fb-helper: Handle function NULL argument
  drm: Add drm_device->drm_fb_helper_private pointer
  drm/fb-helper: Add .last_close and .output_poll_changed helpers
  drm/amdgpu: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/gma500: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/i915: Use drm_fb_helper_output_poll_changed()
  drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/nouveau: Use drm_fb_helper_output_poll_changed()
  drm/omap: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/radeon: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/rockchip: Use drm_fb_helper_lastclose() and _poll_changed()
  drm/tegra: Use drm_fb_helper_lastclose() and _poll_changed()
  staging: vboxvideo: Use drm_fb_helper_lastclose()

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  9 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  | 27 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|  4 --
 drivers/gpu/drm/armada/armada_drm.h |  1 -
 drivers/gpu/drm/armada/armada_drv.c |  8 +---
 drivers/gpu/drm/armada/armada_fb.c  | 11 +
 drivers/gpu/drm/armada/armada_fbdev.c   |  8 
 drivers/gpu/drm/drm_fb_helper.c | 69 +++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  8 +---
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   | 18 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h   |  2 -
 drivers/gpu/drm/gma500/framebuffer.c|  9 +---
 drivers/gpu/drm/gma500/psb_drv.c| 15 +--
 drivers/gpu/drm/i915/intel_display.c|  2 +-
 drivers/gpu/drm/i915/intel_drv.h|  5 ---
 drivers/gpu/drm/i915/intel_fbdev.c  |  8 
 drivers/gpu/drm/msm/msm_drv.c   | 18 +---
 drivers/gpu/drm/nouveau/nouveau_display.c   |  3 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |  8 
 drivers/gpu/drm/nouveau/nouveau_fbcon.h |  2 -
 drivers/gpu/drm/nouveau/nouveau_vga.c   |  3 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c  | 34 +-
 drivers/gpu/drm/radeon/radeon_display.c |  9 +---
 drivers/gpu/drm/radeon/radeon_fb.c  | 22 -
 drivers/gpu/drm/radeon/radeon_kms.c |  5 +--
 drivers/gpu/drm/radeon/radeon_mode.h|  3 --
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  9 +---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  9 +---
 drivers/gpu/drm/tegra/drm.c | 13 +-
 drivers/gpu/drm/tegra/drm.h |  4 --
 drivers/gpu/drm/tegra/fb.c  | 14 --
 drivers/staging/vboxvideo/vbox_drv.c|  2 +-
 drivers/staging/vboxvideo/vbox_drv.h|  1 -
 drivers/staging/vboxvideo/vbox_main.c   | 12 -
 include/drm/drm_device.h|  9 
 include/drm/drm_fb_helper.h | 11 +
 39 files changed, 106 insertions(+), 297 deletions(-)

-- 
2.14.2

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

[PATCH 09/15] drm/msm: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Rob Clark 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/msm/msm_drv.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 606df7bea97b..1bddbbc6fd3e 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -34,16 +34,9 @@
 #define MSM_VERSION_MINOR  2
 #define MSM_VERSION_PATCHLEVEL 0
 
-static void msm_fb_output_poll_changed(struct drm_device *dev)
-{
-   struct msm_drm_private *priv = dev->dev_private;
-   if (priv->fbdev)
-   drm_fb_helper_hotplug_event(priv->fbdev);
-}
-
 static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = msm_framebuffer_create,
-   .output_poll_changed = msm_fb_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = msm_atomic_check,
.atomic_commit = msm_atomic_commit,
.atomic_state_alloc = msm_atomic_state_alloc,
@@ -545,13 +538,6 @@ static void msm_postclose(struct drm_device *dev, struct 
drm_file *file)
kfree(ctx);
 }
 
-static void msm_lastclose(struct drm_device *dev)
-{
-   struct msm_drm_private *priv = dev->dev_private;
-   if (priv->fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-}
-
 static irqreturn_t msm_irq(int irq, void *arg)
 {
struct drm_device *dev = arg;
@@ -825,7 +811,7 @@ static struct drm_driver msm_driver = {
DRIVER_MODESET,
.open   = msm_open,
.postclose   = msm_postclose,
-   .lastclose  = msm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.irq_handler= msm_irq,
.irq_preinstall = msm_irq_preinstall,
.irq_postinstall= msm_irq_postinstall,
-- 
2.14.2

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

[PATCH 05/15] drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Russell King 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/armada/armada_drm.h   |  1 -
 drivers/gpu/drm/armada/armada_drv.c   |  8 ++--
 drivers/gpu/drm/armada/armada_fb.c| 11 +--
 drivers/gpu/drm/armada/armada_fbdev.c |  8 
 4 files changed, 3 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index b064879ecdbd..cc4c557c9f66 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -84,7 +84,6 @@ void armada_drm_queue_unref_work(struct drm_device *,
 extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;
 
 int armada_fbdev_init(struct drm_device *);
-void armada_fbdev_lastclose(struct drm_device *);
 void armada_fbdev_fini(struct drm_device *);
 
 int armada_overlay_plane_create(struct drm_device *, unsigned long);
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index e857b88a9799..4b11b6b52f1d 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "armada_crtc.h"
 #include "armada_drm.h"
@@ -54,15 +55,10 @@ static struct drm_ioctl_desc armada_ioctls[] = {
DRM_IOCTL_DEF_DRV(ARMADA_GEM_PWRITE, armada_gem_pwrite_ioctl, 0),
 };
 
-static void armada_drm_lastclose(struct drm_device *dev)
-{
-   armada_fbdev_lastclose(dev);
-}
-
 DEFINE_DRM_GEM_FOPS(armada_drm_fops);
 
 static struct drm_driver armada_drm_driver = {
-   .lastclose  = armada_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.gem_free_object_unlocked = armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index a38d5a0892a9..ac92bce07ecd 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -154,16 +154,7 @@ static struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
return ERR_PTR(ret);
 }
 
-static void armada_output_poll_changed(struct drm_device *dev)
-{
-   struct armada_private *priv = dev->dev_private;
-   struct drm_fb_helper *fbh = priv->fbdev;
-
-   if (fbh)
-   drm_fb_helper_hotplug_event(fbh);
-}
-
 const struct drm_mode_config_funcs armada_drm_mode_config_funcs = {
.fb_create  = armada_fb_create,
-   .output_poll_changed= armada_output_poll_changed,
+   .output_poll_changed= drm_fb_helper_output_poll_changed,
 };
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index a2ce83f84800..2a59db0994b2 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -159,14 +159,6 @@ int armada_fbdev_init(struct drm_device *dev)
return ret;
 }
 
-void armada_fbdev_lastclose(struct drm_device *dev)
-{
-   struct armada_private *priv = dev->dev_private;
-
-   if (priv->fbdev)
-   drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
-}
-
 void armada_fbdev_fini(struct drm_device *dev)
 {
struct armada_private *priv = dev->dev_private;
-- 
2.14.2

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

[PATCH 06/15] drm/exynos: Use drm_fb_helper_lastclose() and _poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
It can also use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  8 ++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 18 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h |  2 --
 4 files changed, 3 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e651a58c18cf..70f4895ac49c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -89,11 +90,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
struct drm_file *file)
file->driver_priv = NULL;
 }
 
-static void exynos_drm_lastclose(struct drm_device *dev)
-{
-   exynos_drm_fbdev_restore_mode(dev);
-}
-
 static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
.fault = exynos_drm_gem_fault,
.open = drm_gem_vm_open,
@@ -140,7 +136,7 @@ static struct drm_driver exynos_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME
  | DRIVER_ATOMIC | DRIVER_RENDER,
.open   = exynos_drm_open,
-   .lastclose  = exynos_drm_lastclose,
+   .lastclose  = drm_fb_helper_lastclose,
.postclose  = exynos_drm_postclose,
.gem_free_object_unlocked = exynos_drm_gem_free_object,
.gem_vm_ops = _drm_gem_vm_ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 8208df56a88f..0faaf829f5bf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -205,7 +205,7 @@ static struct drm_mode_config_helper_funcs 
exynos_drm_mode_config_helpers = {
 
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
-   .output_poll_changed = exynos_drm_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = exynos_atomic_check,
.atomic_commit = drm_atomic_helper_commit,
 };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index dfb66ecf417b..132dd52d0ac7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -270,24 +270,6 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
private->fb_helper = NULL;
 }
 
-void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
-{
-   struct exynos_drm_private *private = dev->dev_private;
-
-   if (!private || !private->fb_helper)
-   return;
-
-   drm_fb_helper_restore_fbdev_mode_unlocked(private->fb_helper);
-}
-
-void exynos_drm_output_poll_changed(struct drm_device *dev)
-{
-   struct exynos_drm_private *private = dev->dev_private;
-   struct drm_fb_helper *fb_helper = private->fb_helper;
-
-   drm_fb_helper_hotplug_event(fb_helper);
-}
-
 void exynos_drm_fbdev_suspend(struct drm_device *dev)
 {
struct exynos_drm_private *private = dev->dev_private;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
index 645d1bb7f665..b33847223a85 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
@@ -19,8 +19,6 @@
 
 int exynos_drm_fbdev_init(struct drm_device *dev);
 void exynos_drm_fbdev_fini(struct drm_device *dev);
-void exynos_drm_fbdev_restore_mode(struct drm_device *dev);
-void exynos_drm_output_poll_changed(struct drm_device *dev);
 void exynos_drm_fbdev_suspend(struct drm_device *drm);
 void exynos_drm_fbdev_resume(struct drm_device *drm);
 
-- 
2.14.2

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

[PATCH 02/15] drm: Add drm_device->drm_fb_helper_private pointer

[Noralf Trønnes]

drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
struct drm_device. This makes it possible to add callback helpers for
.last_close and .output_poll_changed further reducing fbdev emulation
footprint in drivers. The pointer is set by drm_fb_helper_init() and
cleared by drm_fb_helper_fini().

Signed-off-by: Noralf Trønnes 
---

This patch was initially part of the patchset: drm/tinydrm: Use vmalloc BO
Changes since previous version:
- Change member name: fbdev -> drm_fb_helper_private
- Expand docs
- Set and clear pointer in drm_fb_helper_init/fini()

 drivers/gpu/drm/drm_fb_helper.c | 13 +++--
 include/drm/drm_device.h|  9 +
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 954cdd48de92..c07b7af8de4c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -799,8 +799,10 @@ int drm_fb_helper_init(struct drm_device *dev,
struct drm_mode_config *config = >mode_config;
int i;
 
-   if (!drm_fbdev_emulation)
+   if (!drm_fbdev_emulation) {
+   dev->drm_fb_helper_private = fb_helper;
return 0;
+   }
 
if (!max_conn_count)
return -EINVAL;
@@ -835,6 +837,8 @@ int drm_fb_helper_init(struct drm_device *dev,
i++;
}
 
+   dev->drm_fb_helper_private = fb_helper;
+
return 0;
 out_free:
drm_fb_helper_crtc_free(fb_helper);
@@ -913,7 +917,12 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
 {
struct fb_info *info;
 
-   if (!drm_fbdev_emulation || !fb_helper)
+   if (!fb_helper)
+   return;
+
+   fb_helper->dev->drm_fb_helper_private = NULL;
+
+   if (!drm_fbdev_emulation)
return;
 
cancel_work_sync(_helper->resume_work);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index e21af87a2f3c..6b26262658ae 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -17,6 +17,7 @@ struct drm_vblank_crtc;
 struct drm_sg_mem;
 struct drm_local_map;
 struct drm_vma_offset_manager;
+struct drm_fb_helper;
 
 struct inode;
 
@@ -185,6 +186,14 @@ struct drm_device {
struct drm_vma_offset_manager *vma_offset_manager;
/*@} */
int switch_power_state;
+
+   /**
+* @drm_fb_helper_private:
+*
+* Pointer to the fbdev emulation structure.
+* Set by drm_fb_helper_init() and cleared by drm_fb_helper_fini().
+*/
+   struct drm_fb_helper *drm_fb_helper_private;
 };
 
 #endif
-- 
2.14.2

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

[Bug 197327] New: radeon 0000:01:00.0: failed VCE resume (-110).

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=197327

Bug ID: 197327
   Summary: radeon :01:00.0: failed VCE resume (-110).
   Product: Drivers
   Version: 2.5
Kernel Version: 4.13.8
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: mad_...@bk.ru
Regression: No

Created attachment 260297
  --> https://bugzilla.kernel.org/attachment.cgi?id=260297=edit
dmesg log

Have some trouble on my laptop with Radeon HD 8550G + Radeon HD 8750M

I have error message radeon :01:00.0: failed VCE resume (-110) in boot
time, and i think my discrette card Radeon HD 8750M possibly not work (3D with
DRI_PRIME=1 gives a worse or the same FPS than without it)

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

Re: [PATCH v4] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl

[Eric Anholt]

Boris Brezillon  writes:

> This ioctl will allow us to purge inactive userspace buffers when the
> system is running out of contiguous memory.
>
> For now, the purge logic is rather dumb in that it does not try to
> release only the amount of BO needed to meet the last CMA alloc request
> but instead purges all objects placed in the purgeable pool as soon as
> we experience a CMA allocation failure.
>
> Note that the in-kernel BO cache is always purged before the purgeable
> cache because those objects are known to be unused while objects marked
> as purgeable by a userspace application/library might have to be
> restored when they are marked back as unpurgeable, which can be
> expensive.
>
> Signed-off-by: Boris Brezillon 

I got an ack from Dave on the ioctl struct, so I think we're good to
go.  Reviewed and pushed.  Thanks!


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

[PATCH] drm/msm/mdp5: restore cursor state when enabling crtc

[Rob Clark]

Since we enabled runtime PM, we cannot count on cursor registers to
retain their values.  This can result in situations where we think the
cursor is enabled when we enable the CRTC but it is trying to scan out
null (and the rest of cursor position/size is lost), resulting in faults
and generally angering the hw when coming out of DPMS with a cursor
enabled.

stable backport note: reverting 774e39ee3572 is also a suitable fix

Fixes: 774e39ee3572 drm/msm/mdp5: Set up runtime PM for MDSS
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 100 +--
 1 file changed, 68 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 6aa3a688d9a4..db5c460ba593 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -61,12 +61,15 @@ struct mdp5_crtc {
 
/* current cursor being scanned out: */
struct drm_gem_object *scanout_bo;
+   uint64_t iova;
uint32_t width, height;
uint32_t x, y;
} cursor;
 };
 #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
 
+static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc);
+
 static struct mdp5_kms *get_kms(struct drm_crtc *crtc)
 {
struct msm_drm_private *priv = crtc->dev->dev_private;
@@ -449,6 +452,21 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
 
pm_runtime_get_sync(dev);
 
+   /* Restore cursor state, as it might have been lost with suspend: */
+   if (mdp5_crtc->cursor.iova) {
+   unsigned long flags;
+
+   spin_lock_irqsave(_crtc->cursor.lock, flags);
+   mdp5_crtc_restore_cursor(crtc);
+   spin_unlock_irqrestore(_crtc->cursor.lock, flags);
+
+   mdp5_ctl_set_cursor(mdp5_cstate->ctl,
+   _cstate->pipeline, 0, true);
+   } else {
+   mdp5_ctl_set_cursor(mdp5_cstate->ctl,
+   _cstate->pipeline, 0, false);
+   }
+
/* Restore vblank irq handling after power is enabled */
drm_crtc_vblank_on(crtc);
 
@@ -729,6 +747,50 @@ static void get_roi(struct drm_crtc *crtc, uint32_t 
*roi_w, uint32_t *roi_h)
mdp5_crtc->cursor.y);
 }
 
+static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
+{
+   struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
+   struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
+   struct mdp5_kms *mdp5_kms = get_kms(crtc);
+   const enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
+   uint32_t blendcfg, stride;
+   uint32_t x, y, width, height;
+   uint32_t roi_w, roi_h;
+   int lm;
+
+   assert_spin_locked(_crtc->cursor.lock);
+
+   lm = mdp5_cstate->pipeline.mixer->lm;
+
+   x = mdp5_crtc->cursor.x;
+   y = mdp5_crtc->cursor.y;
+   width = mdp5_crtc->cursor.width;
+   height = mdp5_crtc->cursor.height;
+
+   stride = width * drm_format_plane_cpp(DRM_FORMAT_ARGB, 0);
+
+   get_roi(crtc, _w, _h);
+
+   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
+   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
+   MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
+   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_IMG_SIZE(lm),
+   MDP5_LM_CURSOR_IMG_SIZE_SRC_H(height) |
+   MDP5_LM_CURSOR_IMG_SIZE_SRC_W(width));
+   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_SIZE(lm),
+   MDP5_LM_CURSOR_SIZE_ROI_H(roi_h) |
+   MDP5_LM_CURSOR_SIZE_ROI_W(roi_w));
+   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_START_XY(lm),
+   MDP5_LM_CURSOR_START_XY_Y_START(y) |
+   MDP5_LM_CURSOR_START_XY_X_START(x));
+   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_BASE_ADDR(lm),
+   mdp5_crtc->cursor.iova);
+
+   blendcfg = MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_EN;
+   blendcfg |= MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_ALPHA_SEL(cur_alpha);
+   mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_BLEND_CONFIG(lm), blendcfg);
+}
+
 static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
struct drm_file *file, uint32_t handle,
uint32_t width, uint32_t height)
@@ -741,13 +803,9 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
struct platform_device *pdev = mdp5_kms->pdev;
struct msm_kms *kms = _kms->base.base;
struct drm_gem_object *cursor_bo, *old_bo = NULL;
-   uint32_t blendcfg, stride;
-   uint64_t cursor_addr;
struct mdp5_ctl *ctl;
-   int ret, lm;
-   enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
+   int ret;
uint32_t flush_mask = mdp_ctl_flush_mask_cursor(0);
-   uint32_t roi_w, roi_h;
bool cursor_enable = true;

[pull] ttm and amdgpu drm-next-4.15

[Alex Deucher]

Hi Dave,

Last set of features for 4.15.  Highlights:
- Add a bo flag to allow buffers to opt out of implicit sync
- Add ctx priority setting interface
- Lots more powerplay cleanups
- Start to plumb through vram lost infrastructure for gpu reset
- ttm support for huge pages
- misc cleanups and bug fixes

The following changes since commit bb7a9c8d712f37385a706a594d6edf6e6d2669d0:

  Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-10-09 11:00:16 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.15

for you to fetch changes up to 96687ec0bb478088cb6941a7dca3bb6808a19313:

  drm/amd/powerplay: Place the constant on the right side of the test 
(2017-10-19 15:27:23 -0400)


Alex Deucher (2):
  drm/amdgpu: bump version for new AMDGPU_SCHED ioctl
  drm/amdgpu: bump version for vram lost counter query (v2)

Andres Rodriguez (11):
  drm/amdgpu: add helper to convert a ttm bo to amdgpu_bo
  drm/amdgpu: introduce AMDGPU_GEM_CREATE_EXPLICIT_SYNC v2
  drm/amdgpu: add parameter to allocate high priority contexts v11
  drm/amdgpu: add framework for HW specific priority settings v9
  drm/amdgpu: implement ring set_priority for gfx_v8 compute v9
  drm/amdgpu: make amdgpu_to_sched_priority detect invalid parameters
  drm/amd/sched: allow clients to edit an entity's rq v2
  drm/amdgpu: introduce AMDGPU_CTX_PRIORITY_UNSET
  drm/amdgpu: add plumbing for ctx priority changes v2
  drm/amdgpu: add interface for editing a foreign process's priority v3
  drm/amdgpu: rename context priority levels

Andrey Grodzovsky (3):
  drm/amdgpu: Refactor amdgpu_cs_ib_vm_chunk and amdgpu_cs_ib_fill.
  drm/amdgpu: Move old fence waiting before reservation lock is aquired v2
  drm/amdgpu: Fix extra call to amdgpu_ctx_put.

Christian König (18):
  drm/ttm: allocate/free multiple pages in a single call
  drm/ttm: DMA map/unmap consecutive pages as a whole v2
  drm/amdgpu: add VM support for huge pages v2
  drm/ttm: don't use compound pages for now
  drm/ttm: add transparent huge page support for cached allocations v2
  drm/ttm: move more logic into ttm_page_pool_get_pages
  drm/ttm: add transparent huge page support for wc or uc allocations v2
  drm/amdgpu: partial revert VRAM lost handling v2
  drm/amdgpu: keep copy of VRAM lost counter in job
  drm/amdgpu: move the VRAM lost counter per context
  drm/amdgpu: set -ECANCELED when dropping jobs
  drm/amdgpu: add VRAM lost query
  drm/amd/sched: fix job tear down order v2
  drm/amdgpu: minor CS optimization
  drm/ttm: fix the fix for huge compound pages
  drm/amdgpu: reserve root PD while releasing it
  drm/amdgpu: linear validate first then bind to GART
  drm/amdgpu: allow GTT overcommit during bind

Colin Ian King (1):
  drm/amdgpu: make function uvd_v6_0_enc_get_destroy_msg static

Georgiana Chelu (3):
  drm/amd/powerplay: Don't cast kzalloc() return value
  drm/amd/powerplay: Remove useless variable
  drm/amd/powerplay: Place the constant on the right side of the test

Harish Kasiviswanathan (2):
  drm/amdgpu: Refactor amdgpu_move_blit
  drm/amdgpu: Add amdgpu_find_mm_node()

Horace Chen (2):
  drm/amdgpu: Reserve shared memory on VRAM for SR-IOV
  drm/amdgpu: SR-IOV data exchange between PF

Jérémy Lefaure (1):
  drm/amdgpu: use ARRAY_SIZE

Ken Wang (1):
  drm/amdgpu: correct reference clock value on vega10

Monk Liu (3):
  drm/amdgpu:reduce wb to 512 slot
  drm/amdgpu:fix duplicated setting job's vram_lost
  drm/amdgpu:don't check soft_reset for sriov

Rex Zhu (14):
  drm/amd/pp: export new smu messages for vega10
  drm/amd/pp: add new function point in hwmgr.
  drm/amd/pp: implement function notify_cac_buffer_info on Vega
  drm/amd/pp: implement function notify_cac_buffer_info on VI
  drm/amd/pp: move common function to smu7_smumgr.c
  drm/amdgpu: refine code delete duplicated error handling
  drm/amd/pp: rename ci_smc.c to ci_smumgr.c
  drm/amd/pp: remove fiji_smc/smumgr split.
  drm/amd/pp: remove iceland_smc/smumgr split.
  drm/amd/pp: remove tonga_smc/smumgr split.
  drm/amd/pp: remove polaris10_smc/smumgr split.
  drm/amdgpu: fix regresstion on SR-IOV gpu reset failed
  drm/amd/pp: thermal control not enabled on vega10.
  drm/amd/pp: Fix overflow when setup decf/pix/disp dpm table.

Satyajit Sahu (1):
  drm/amd/powerplay: get the temperature on CZ

Tom St Denis (8):
  drm/ttm: Fix unused variables with huge page support
  drm/amd/powerplay: Tidy up cz_start_dpm()
  drm/amd/powerplay: Tidy up cz_dpm_powerdown_uvd()
  drm/amd/powerplay: Tidy up cz_dpm_powerup_uvd()
  drm/amd/powerplay: Tidy up cz_dpm_update_uvd_dpm()
  drm/amd/powerplay: Tidy up 

[Bug 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]

[bugzilla-daemon]

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

--- Comment #3 from Vedran Miletić  ---
Not sure if it's a regression, but I can check older kernels if you want me to.

-- 
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 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]

[bugzilla-daemon]

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

--- Comment #2 from Vedran Miletić  ---
Created attachment 134926
  --> https://bugs.freedesktop.org/attachment.cgi?id=134926=edit
dmesg

-- 
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 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

Daniel Vetter  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org
  Component|DRM/AMDgpu  |Drivers/DRI/i965
Version|unspecified |git
Product|DRI |Mesa
 QA Contact||intel-3d-bugs@lists.freedes
   ||ktop.org

-- 
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: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync

[Manasi Navare]

On Wed, Oct 18, 2017 at 09:28:01PM +0200, Daniel Vetter wrote:
> On Wed, Oct 18, 2017 at 6:59 PM, Michel Dänzer  wrote:
> > On 18/10/17 12:15 PM, Nicolai Hähnle wrote:
> >> On 18.10.2017 10:10, Daniel Vetter wrote:
> >>> On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote:
>  On 17.10.2017 19:16, Daniel Vetter wrote:
> > On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer 
> > wrote:
> >> On 17/10/17 05:04 PM, Daniel Vetter wrote:
> >>> On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
>  On 17/10/17 02:22 PM, Daniel Vetter wrote:
> > On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
> >> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
> >
> >>> Common sense suggests that there need to be two side to
> >>> FreeSync / VESA
> >>> Adaptive Sync support:
> >>>
> >>> 1. Query the display capabilities. This means querying minimum
> >>> / maximum
> >>> refresh duration, plus possibly a query for when the
> >>> earliest/latest
> >>> timing of the *next* refresh.
> >>>
> >>> 2. Signal desired present time. This means passing a target
> >>> timer value
> >>> instead of a target vblank count, e.g. something like this for
> >>> the KMS
> >>> interface:
> >>>
> >>> int drmModePageFlipTarget64(int fd, uint32_t crtc_id,
> >>> uint32_t fb_id,
> >>> uint32_t flags, void *user_data,
> >>> uint64_t target);
> >>>
> >>> + a flag to indicate whether target is the vblank count or
> >>> the
> >>> CLOCK_MONOTONIC (?) time in ns.
> >>
> >> drmModePageFlip(Target) is part of the pre-atomic KMS API, but
> >> adapative
> >> sync should probably only be supported via the atomic API,
> >> presumably
> >> via output properties.
> >
> > +1
> >
> > At least now that DC is on track to land properly, and you want
> > to do this
> > for DC-only anyway there's no reason to pimp the legacy interfaces
> > further. And atomic is soo much easier to extend.
> >
> > The big question imo is where we need to put the flag on the kms
> > side,
> > since freesync is not just about presenting earlier, but also about
> > presenting later. But for backwards compat we can't stretch the
> > refresh
> > rate by default for everyone, or clients that rely on high
> > precision
> > timestamps and regular refresh will get a bad surprise.
> 
>  The idea described above is that adaptive sync would be used for
>  flips
>  with a target timestamp. Apps which don't want to use adaptive sync
>  wouldn't set a target timestamp.
> 
> 
> > I think a boolean enable_freesync property is probably what we
> > want, which
> > enables freesync for as long as it's set.
> 
>  The question then becomes under what circumstances the property
>  is (not)
>  set. Not sure offhand this will actually solve any problem, or
>  just push
>  it somewhere else.
> >>>
> >>> I thought that's what the driconf switch is for, with a policy of
> >>> "please
> >>> schedule asap" instead of a specific timestamp.
> >>
> >> The driconf switch is just for the user's intention to use adaptive
> >> sync
> >> when possible. A property as you suggest cannot be set by the client
> >> directly, because it can't know when adaptive sync can actually be
> >> used
> >> (only when its window is fullscreen and using page flipping). So the
> >> property would have to be set by the X server/driver / Wayland
> >> compositor / ... instead. The question is whether such a property is
> >> actually needed, or whether the kernel could just enable adaptive sync
> >> when there's a flip with a target timestamp, and disable it when
> >> there's
> >> a flip without a target timestamp, or something like that.
> >
> > If your adaptive sync also supports extending the vblank beyond the
> > nominal limit, then you can't do that with a per-flip flag. Because
> > absent of a userspace requesting adaptive sync you must flip at the
> > nominal vrefresh rate. So if your userspace is a tad bit late with the
> > frame and would like to extend the frame to avoid missing a frame
> > entirely it'll be too late by the time the vblank actually gets
> > submitted. That's a bit a variation of what Ville brought up about
> > what we're going to do when the timestamp was missed by the time all
> > the depending fences signalled.
> 
>  These are very 

Re: [PATCH v2 3/3] drm/amd/powerplay: Place the constant on the right side of the test

[Alex Deucher]

On Tue, Oct 17, 2017 at 4:22 PM, Georgiana Chelu
 wrote:
> Move the constant on the right side of the comparison in order to
> make the code easier to read.
>
> Issue found by checkpatch script:
> * WARNING: Comparisons should place the constant on the right side of
> the test
>
> Signed-off-by: Georgiana Chelu 

Applied the series.  Thanks you!

Alex

> ---
>
> Changes in v2:
> * adjusted the subject prefix of the patches
>
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> index 769ac11a9215..f14c7611fad3 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
> @@ -1021,7 +1021,7 @@ static int get_vddc_lookup_table(
>
> table = kzalloc(table_size, GFP_KERNEL);
>
> -   if (NULL == table)
> +   if (table == NULL)
> return -ENOMEM;
>
> table->count = vddc_lookup_pp_tables->ucNumEntries;
> @@ -1130,12 +1130,12 @@ int vega10_pp_tables_initialize(struct pp_hwmgr 
> *hwmgr)
>
> hwmgr->pptable = kzalloc(sizeof(struct phm_ppt_v2_information), 
> GFP_KERNEL);
>
> -   PP_ASSERT_WITH_CODE((NULL != hwmgr->pptable),
> +   PP_ASSERT_WITH_CODE((hwmgr->pptable != NULL),
> "Failed to allocate hwmgr->pptable!", return 
> -ENOMEM);
>
> powerplay_table = get_powerplay_table(hwmgr);
>
> -   PP_ASSERT_WITH_CODE((NULL != powerplay_table),
> +   PP_ASSERT_WITH_CODE((powerplay_table != NULL),
> "Missing PowerPlay Table!", return -1);
>
> result = check_powerplay_tables(hwmgr, powerplay_table);
> @@ -1229,7 +1229,7 @@ int vega10_get_number_of_powerplay_table_entries(struct 
> pp_hwmgr *hwmgr)
> const ATOM_Vega10_State_Array *state_arrays;
> const ATOM_Vega10_POWERPLAYTABLE *pp_table = 
> get_powerplay_table(hwmgr);
>
> -   PP_ASSERT_WITH_CODE((NULL != pp_table),
> +   PP_ASSERT_WITH_CODE((pp_table != NULL),
> "Missing PowerPlay Table!", return -1);
> PP_ASSERT_WITH_CODE((pp_table->sHeader.format_revision >=
> ATOM_Vega10_TABLE_REVISION_VEGA10),
> --
> 2.11.0
>
> ___
> 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 v2] drm/rockchip: Use an enum to identify Rockchip VOPs

[Kristian Høgsberg]

On Wed, Oct 18, 2017 at 5:49 PM, Mark yao  wrote:
> On 2017年10月19日 01:52, Brian Norris wrote:
>>
>> Hi Kristian,
>>
>> On Thu, Nov 03, 2016 at 12:46:48PM -0700, Kristian Högsberg wrote:
>>>
>>> We used to call drm_of_encoder_active_endpoint_id() from
>>> rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the
>>> active encoder. However, the encoder isn't necessarily active at this
>>> point or it may be connected to different crtc than what we're switching
>>> to. Instead, look at the crtc from the drm_crtc_state.  This fixes wrong
>>> colors when driving the eDP with the big VOP.  Further, we can identify
>>> the type of VOP we're dealing with by just putting a VOP id enum in the
>>> vop_data.
>
>
> Unfortunately, vop iomux and vop data are not one-to-one correspondence.
>
> Such as rk3288, vop big and vop little both use rk3288_vop data, if you use
> vop data id will not be able
> to distinguish between them.

What would you suggest then? We need this to be able to drive eDP from
the big VOP. We've been carrying this patch for quite a while and it
hasn't regressed neither rk3288 nor rk3399 boards.

Kristian

> Mark
>>>
>>>
>>> On way to test this is to use the modetest tool from libdrm:
>>>
>>>$ modetest -M rockchip -s 32@28:2400x1600
>>>
>>> which displays dark or black colors because we fail to look up the
>>> endpoint and use default 0 (which is ROCKCHIP_OUT_MODE_P888) for big
>>> VOP instead of RGB10 as required.
>>>
>>> For reference,
>>>
>>>$ modetest -M rockchip -s 32@25:2400x1600
>>>
>>> drives the eDP from little VOP and displays correctly.
>>>
>>> Signed-off-by: Kristian H. Kristensen 
>>> ---
>>> v2: Stripped chromeos annotations, fix compile errors for drivers I
>>> didn't
>>> compile when I first wrote the patch.
>>
>> Do you plan to fix the errors Guenter pointed out and resend? This is
>> still causing conflicts between our ChromeOS kernel trees and upstream.
>>
>> Also, please CC linux-rockchip on Rockchip-related patches. It's much
>> easier for me to find your work that way :)
>>
>> Brian
>>
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 45
>>> ++---
>>>   drivers/gpu/drm/rockchip/cdn-dp-core.c  | 19 +--
>>>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 12 ---
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 
>>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++
>>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  4 +++
>>>   6 files changed, 56 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 558a3bc..9ae4a9c 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -196,14 +196,16 @@ static void rockchip_dp_drm_encoder_enable(struct
>>> drm_encoder *encoder)
>>> int ret;
>>> u32 val;
>>>   - ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
>>> encoder);
>>> -   if (ret < 0)
>>> -   return;
>>> -
>>> -   if (ret)
>>> +   switch (vop_get_crtc_vop_id(encoder->crtc)) {
>>> +   case RK3399_VOP_LIT:
>>> val = dp->data->lcdsel_lit;
>>> -   else
>>> +   break;
>>> +   case RK3399_VOP_BIG:
>>> val = dp->data->lcdsel_big;
>>> +   break;
>>> +   default:
>>> +   return;
>>> +   }
>>> dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
>>>   @@ -231,34 +233,23 @@ rockchip_dp_drm_encoder_atomic_check(struct
>>> drm_encoder *encoder,
>>>   struct drm_connector_state
>>> *conn_state)
>>>   {
>>> struct rockchip_crtc_state *s =
>>> to_rockchip_crtc_state(crtc_state);
>>> -   struct rockchip_dp_device *dp = to_dp(encoder);
>>> -   int ret;
>>>   - /*
>>> -* The hardware IC designed that VOP must output the RGB10 video
>>> -* format to eDP contoller, and if eDP panel only support RGB8,
>>> -* then eDP contoller should cut down the video data, not via VOP
>>> -* contoller, that's why we need to hardcode the VOP output mode
>>> -* to RGA10 here.
>>> -*/
>>> -
>>> -   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
>>> encoder);
>>> -   if (ret < 0)
>>> -   return 0;
>>> -
>>> -   switch (dp->data->chip_type) {
>>> -   case RK3399_EDP:
>>> +   switch (vop_get_crtc_vop_id(crtc_state->crtc)) {
>>> +   case RK3399_VOP_LIT:
>>> /*
>>>  * For RK3399, VOP Lit must code the out mode to RGB888,
>>>  * VOP Big must code the out mode to RGB10.
>>>  */
>>> -   if (ret)
>>> -   s->output_mode = ROCKCHIP_OUT_MODE_P888;
>>> -   else
>>> -   

[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

Lyude Paul  changed:

   What|Removed |Added

 Attachment #134890|0   |1
is obsolete||
 Attachment #134897|0   |1
is obsolete||

--- Comment #59 from Lyude Paul  ---
Created attachment 134923
  --> https://bugs.freedesktop.org/attachment.cgi?id=134923=edit
Mesa i965 patch to fix corruption issues

So it looks like that this patch for mesa from Daniel actually fixes the issue.
A very important note here: make -sure- whatever you are using as the
compositor (X, gnome-shell on wayland, etc.) is also using the version of mesa
with this patch as well because otherwise this will not fix your problem.

I did this myself by building and installing mesa into a prefix
(/home/lyudess/prefixes/mesa) and running:

ldconfig -v /home/lyudess/prefixes/mesa/lib

You should see all of the GL libraries get directed to your mesa prefix. After
that just reboot and try. You might be able to skip the reboot, but I did it
just to be safe :)

-- 
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: HDMI Aspect Ratio

[Ville Syrjälä]

On Thu, Oct 19, 2017 at 01:08:05PM -0400, Alex Deucher wrote:
> On Thu, Oct 19, 2017 at 12:32 PM, Rob Clark  wrote:
> > On Wed, Oct 18, 2017 at 4:06 PM, Lloyd Atkinson  
> > wrote:
> >> Hi folks,
> >>
> >> We're looking at 4K HDMI mode support, and noticed aspect ratio support
> >> is in flux.
> >>
> >> Aspect ratio parsing was added to the mode:
> >> https://patchwork.kernel.org/patch/9271401/
> >>
> >> But later reverted:
> >> https://patchwork.kernel.org/patch/9410765/
> >>
> >> We're finding that since aspect ratio information isn't supported, modes
> >> conflict, and the userspace isn't able to see the full list of modes.
> >>
> >> Similarly, there's a case where two modes differ only by aspect_ratio
> >> and vrefresh. In drm_edid.c, within drm_display_mode_from_vic_index,
> >> newmode->vrefresh is forcibly being cleared to 0. Since refresh rate is
> >> forced to 0, and aspect ratio isn’t considered in general, the modes
> >> collide and we can’t advertise one of the modes.
> >>
> >> https://github.com/torvalds/linux/blob/v4.14-rc4/drivers/gpu/drm/drm_edid.c#L3153
> >>
> >> Have there been any follow-up discussions on this topic?
> >>
> >> What is the reason to clear the vrefresh within
> >> drm_display_mode_from_vic_index?
> >
> > +Ville who might remember the history..
> >
> > I don't remember if we found a userspace app that was broken, or if
> > reverting was an "abundance of caution" thing (which is equally valid,
> > it is basically impossible to track down and test "all of
> > userspace"..)
> >
> 
> Wasn't there an issue with SNA?

Exposing the aspect ratio flags broke sna, at least.

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

Re: HDMI Aspect Ratio

[Alex Deucher]

On Thu, Oct 19, 2017 at 12:32 PM, Rob Clark  wrote:
> On Wed, Oct 18, 2017 at 4:06 PM, Lloyd Atkinson  
> wrote:
>> Hi folks,
>>
>> We're looking at 4K HDMI mode support, and noticed aspect ratio support
>> is in flux.
>>
>> Aspect ratio parsing was added to the mode:
>> https://patchwork.kernel.org/patch/9271401/
>>
>> But later reverted:
>> https://patchwork.kernel.org/patch/9410765/
>>
>> We're finding that since aspect ratio information isn't supported, modes
>> conflict, and the userspace isn't able to see the full list of modes.
>>
>> Similarly, there's a case where two modes differ only by aspect_ratio
>> and vrefresh. In drm_edid.c, within drm_display_mode_from_vic_index,
>> newmode->vrefresh is forcibly being cleared to 0. Since refresh rate is
>> forced to 0, and aspect ratio isn’t considered in general, the modes
>> collide and we can’t advertise one of the modes.
>>
>> https://github.com/torvalds/linux/blob/v4.14-rc4/drivers/gpu/drm/drm_edid.c#L3153
>>
>> Have there been any follow-up discussions on this topic?
>>
>> What is the reason to clear the vrefresh within
>> drm_display_mode_from_vic_index?
>
> +Ville who might remember the history..
>
> I don't remember if we found a userspace app that was broken, or if
> reverting was an "abundance of caution" thing (which is equally valid,
> it is basically impossible to track down and test "all of
> userspace"..)
>

Wasn't there an issue with SNA?

Alex

> Adding a cap to let userspace opt-in to the new behaviour seems like a
> sensible approach, and one that we've used before.>
> BR,
> -R
>
>> Thanks,
>> Lloyd Atkinson
>>
>> --
>> QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
>> of Code Aurora Forum, hosted by The Linux Foundation
>> ___
>> 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: HDMI Aspect Ratio

[Ville Syrjälä]

On Thu, Oct 19, 2017 at 12:32:53PM -0400, Rob Clark wrote:
> On Wed, Oct 18, 2017 at 4:06 PM, Lloyd Atkinson  
> wrote:
> > Hi folks,
> >
> > We're looking at 4K HDMI mode support, and noticed aspect ratio support
> > is in flux.
> >
> > Aspect ratio parsing was added to the mode:
> > https://patchwork.kernel.org/patch/9271401/
> >
> > But later reverted:
> > https://patchwork.kernel.org/patch/9410765/
> >
> > We're finding that since aspect ratio information isn't supported, modes
> > conflict, and the userspace isn't able to see the full list of modes.
> >
> > Similarly, there's a case where two modes differ only by aspect_ratio
> > and vrefresh. In drm_edid.c, within drm_display_mode_from_vic_index,
> > newmode->vrefresh is forcibly being cleared to 0. Since refresh rate is
> > forced to 0, and aspect ratio isn’t considered in general, the modes
> > collide and we can’t advertise one of the modes.
> >
> > https://github.com/torvalds/linux/blob/v4.14-rc4/drivers/gpu/drm/drm_edid.c#L3153
> >
> > Have there been any follow-up discussions on this topic?
> >
> > What is the reason to clear the vrefresh within
> > drm_display_mode_from_vic_index?
> 
> +Ville who might remember the history..
> 
> I don't remember if we found a userspace app that was broken, or if
> reverting was an "abundance of caution" thing (which is equally valid,
> it is basically impossible to track down and test "all of
> userspace"..)

IIRC it was just me being paranoid because we used to have 0 there, and
I was worried something might get confused if it comes in pre-populated.

I don't think this should have any user space impact because the probe
helper will anyway populate it with drm_mode_vrefresh() before we
expose the mode to anyone. So the only time when you might even see the
zero is if you manually duplicate a cea/vic mode for some reason.

So I guess we could just remove the zeroing and see what happens. Or
we might even do something like WARN_ON(vrefresh != drm_mode_vrefresh())
to make sure we've correctly populate the cea/hdmi mode lists.

Note that we really shouldn't be using vrefresh for anything real.
It's there just for informational purposes and you really shouldn't
use it for anything important. drm_mode_equal() & co. ignore it
correctly.

If you have a need to know the actual refresh rate for something
important then 1 Hz accurace seem very much insufficient. We never
use vrefresh for anything in i915 code for instance and instead we
compute things based on the actual timings as needed.

Also I think it's rather unfortunate that the user visible mode even
has vrefresh. It has zero benefits and looks like we have no sanity
checking to make sure the user provided mode vrefresh even agrees
with the rest of the timings. We should probably just set
'mode->vrefresh = drm_mode_vrefres()' in drm_mode_convert_umode() to
make sure it's consistent from the start. Not sure we dare start
rejecting user modes on account of inconsistent vrefresh. That might
really break some userspace applications.

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

Re: HDMI Aspect Ratio

[Rob Clark]

On Wed, Oct 18, 2017 at 4:06 PM, Lloyd Atkinson  wrote:
> Hi folks,
>
> We're looking at 4K HDMI mode support, and noticed aspect ratio support
> is in flux.
>
> Aspect ratio parsing was added to the mode:
> https://patchwork.kernel.org/patch/9271401/
>
> But later reverted:
> https://patchwork.kernel.org/patch/9410765/
>
> We're finding that since aspect ratio information isn't supported, modes
> conflict, and the userspace isn't able to see the full list of modes.
>
> Similarly, there's a case where two modes differ only by aspect_ratio
> and vrefresh. In drm_edid.c, within drm_display_mode_from_vic_index,
> newmode->vrefresh is forcibly being cleared to 0. Since refresh rate is
> forced to 0, and aspect ratio isn’t considered in general, the modes
> collide and we can’t advertise one of the modes.
>
> https://github.com/torvalds/linux/blob/v4.14-rc4/drivers/gpu/drm/drm_edid.c#L3153
>
> Have there been any follow-up discussions on this topic?
>
> What is the reason to clear the vrefresh within
> drm_display_mode_from_vic_index?

+Ville who might remember the history..

I don't remember if we found a userspace app that was broken, or if
reverting was an "abundance of caution" thing (which is equally valid,
it is basically impossible to track down and test "all of
userspace"..)

Adding a cap to let userspace opt-in to the new behaviour seems like a
sensible approach, and one that we've used before.

BR,
-R

> Thanks,
> Lloyd Atkinson
>
> --
> QUALCOMM Canada, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> ___
> 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 1/3] drm: add connector info/property for non-std displays

[Keith Packard]

Daniel Stone  writes:

> Why not add a client cap which hides 'non-standard' displays
> completely from non-aware clients? That way you can keep the connected
> status as is, and clients either never see the HMD or will be able to
> check the property.

Most clients are display servers, and it looks like we're settling on
using the display server as the way to enumerate all of the displays (as
direct enumeration through DRM non-master FDs involve rather drastic
permissions changes in the kernel).

This means that display servers are going to have to change to both see
these displays while keeping them from being part of the desktop. So,
while I guess it might be useful to hide HMD from existing display
servers with a bit like this, I don't think there's any particular
long-term benefit?

> Either way, I'm still not convinced doing this in the kernel makes any
> sense.

fbdev. We want to keep the HMD dark until there's something 'real' to
show on it.

If you accept that fbdev needs to know this, then there's no way to
avoid maintaining a database in the kernel. Maybe what we need is some
way to load additional database entries into the kernel at boot time
from a file in the initrd? And if you want a user-space database too,
then maybe the kernel data should be generated from that and dumped into
the initrd? One version of the truth is hard enough to deal with; I'd
hate to have two.

> We need the shared EDID library anyway in order to deal with the quirk
> tables replicated between the kernel/Xorg currently, so that's going
> to happen pretty soon regardless of whether or not the kernel gets its
> own database.

Yeah, we'll presumably need this support in the Vulkan KHR_display
extension too, so sharing EDID support up in user space between all of
these entities seems like a great idea.

-- 
-keith


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

[Bug 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer

[bugzilla-daemon]

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

--- Comment #8 from Luc  ---
I did some further analysis in our code, and found that some textures follow
another path (not using the Fence/Sync).
In this path it can indeed be that the same texture id is re-used and uploaded
in the texture upload thread, which of course can happen while the rendering
thread performs the glFlush.

-- 
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 libdrm] modetest: Allow full testing of primary planes

[Ville Syrjälä]

On Mon, Oct 16, 2017 at 08:10:56PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Allow the user to override the default configuration set by setcrtc
> for the primary plane. On some hardware primary planes can be freely
> positioned/sized, and it'd be nice if we can actually test that feature.
> 
> Signed-off-by: Ville Syrjälä 

No one objected, so I went ahead and pushed this.

> ---
>  tests/modetest/modetest.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index b8891ff5e2e8..eca8cde68123 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -1005,7 +1005,8 @@ static int set_plane(struct device *dev, struct 
> plane_arg *p)
>   if (!format_support(ovr, p->fourcc))
>   continue;
>  
> - if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id) {
> + if ((ovr->possible_crtcs & (1 << pipe)) &&
> + (ovr->crtc_id == 0 || ovr->crtc_id == p->crtc_id)) {
>   plane_id = ovr->plane_id;
>   break;
>   }
> -- 
> 2.13.6

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

Re: DRM Client capability for aspect ratio

[Daniel Stone]

Hi Ankit,

On 17 October 2017 at 12:08, Nautiyal, Ankit K
 wrote:
> On Similar lines, I was able to add the new DRM_CLIENT_CAP_ASPECT_RATIO. I
> also added a member 'aspect_ratio_required' in drm_file structure,

Quick bikeshed suggestion: aspect_ratio_supported. ;)

> Now what I want to do is
>
> 1. Setting the aspect-ratio flag-bits (19-22) in drmModeModeInfo only if
> the client advertises that it requires the aspect-ratio.
>
> So I need to have this information (that client requires aspect ratio)
> available in the function:
>
> drm_mode_convert_to_umode( ) : Where the flag bits are actually set

This would be called in, e.g., drmModeGetCrtc.

> 2. Similarly in case of modeset request from the client, we would want
> to parse the aspect ratio bits from the requested  drmModeModeInfo only if
> the client requires aspect ratio.
>
> This will require change in the function:
>
> drm_mode_convert_umode()  : Where the flag bits of  drm_mode_mode_info are
> read by the drm layer to determine the aspect ratio and set in
> drm_display_mode)

As in drmModeSetCrtc, or when doing an atomic modeset, pulling the
mode from the blob identified by MODE_ID.

> The problem is that, both these functions have drm_mode_mode_info and
> drm_display_mode as the only arguments, but our flag aspect_ratio_required
> is in file_priv (struct drm_file).
>
> To do this there are two ways I can think of:
>
> 1. Change the drm_mode_convert_umode() to include aspect_ratio_required
> flag.
>
> Before calling this function, the file_priv->aspect_ratio_required
> will be checked and the flag will be set accordingly.
>
> 2. While getting the drmClientCap from client, instead of storing this
> information in file-priv, store this info in some other structure.

I think you could just pass the file_priv directly; it seems a bit more clear.

One case I think you're missing though, is where a client discovers an
existing MODE_ID blob (via the atomic property), then gets the blob
contents to parse. In this case, we might pass the client unsupported
flags. I don't have a really good suggestion for fixing this, apart
from duplicating the blob content and returning a different result to
userspace ... !

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

Re: [PATCH 1/3] drm: add connector info/property for non-std displays

[Daniel Stone]

Hi,

On 16 October 2017 at 06:29, Dave Airlie  wrote:
> This adds the infrastructure needed to quirk displays
> using edid and to mark them a non-standard.
>
> A non-standard display is one which doesn't work like
> a normal rectangular monitor or requires some transformation
> of the output by the rendering process to make sense.
>
> This is meant to cover head mounted devices like HTC Vive.

Why not add a client cap which hides 'non-standard' displays
completely from non-aware clients? That way you can keep the connected
status as is, and clients either never see the HMD or will be able to
check the property.

Either way, I'm still not convinced doing this in the kernel makes any
sense. Seems like we'll need to keep doing it forever for every HMD
once we start now. Why not drop the in-kernel database, and go with a
userspace-side table: we already _have_ udev's hwdb, there's already a
decent enough sketch of an EDID database we could share between
Mutter/Weston/Xorg/..., and it's easier to deal with, distribute, and
hack. We need the shared EDID library anyway in order to deal with the
quirk tables replicated between the kernel/Xorg currently, so that's
going to happen pretty soon regardless of whether or not the kernel
gets its own database.

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

Re: [PATCH] drm/etnaviv: fix GPU vs sync point race

[Christian Gmeiner]

2017-10-19 15:10 GMT+02:00 Lucas Stach :
> If the FE is restarted before the sync point event is cleared, the GPU
> might trigger a completion IRQ for the next sync point before corrupting
> the state of the currently running worker.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 93a103eb1083..8ff5d01e776d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1484,22 +1484,18 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
> return ret;
>  }
>
> -static void etnaviv_process_sync_point(struct etnaviv_gpu *gpu,
> -   struct etnaviv_event *event)
> -{
> -   u32 addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
> -
> -   event->sync_point(gpu, event);
> -   etnaviv_gpu_start_fe(gpu, addr + 2, 2);
> -}
> -
>  static void sync_point_worker(struct work_struct *work)
>  {
> struct etnaviv_gpu *gpu = container_of(work, struct etnaviv_gpu,
>sync_point_work);
> +   struct etnaviv_event *event = >event[gpu->sync_point_event];
> +   u32 addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
>
> -   etnaviv_process_sync_point(gpu, >event[gpu->sync_point_event]);
> +   event->sync_point(gpu, event);
> event_free(gpu, gpu->sync_point_event);
> +
> +   /* restart FE last to avoid GPU and IRQ racing against this worker */
> +   etnaviv_gpu_start_fe(gpu, addr + 2, 2);
>  }
>
>  /*
> --
> 2.11.0
>


greets
--
Christian Gmeiner, MSc

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

Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

[Philipp Zabel]

Hi Laurent,

On Thu, 2017-10-19 at 16:39 +0300, Laurent Pinchart wrote:
> Hi Philipp,
> 
> On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote:
> > On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote:
> > > In theory the MMSYS device tree identifier is matches twice, by the clk
> > > driver and the DRM subsystem. But the kernel only matches the first
> > > driver for a device (clk) and discards the second one. This breaks
> > > graphics on mt8173 and most probably on mt2701 as well.
> > > 
> > > MMSYS in Mediatek SoCs has some registers to control clock gates (which is
> > > used in the clk driver) and some registers to enable the differnet blocks
> > > of the display subsystem. The kernel uses the binding to load the central
> > > comoponent of the distplay subsystem, which in place probes all the other
> > > components and enables the present ones in the MMSYS.
> > > 
> > > We found us with the problem, that we need to change and therefor break
> > > one
> > > of the two bindings, or the DRM one or the clock driver one.
> > > 
> > > Apart from that the DRM subysystem does access the MMSYS registers via
> > > relaxed reads/writes. But the it should to so via regmap, as the
> > > registers are shared.
> > > 
> > > Possible solutions:
> > > 1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a
> > > simple-mfd under the actual mmsys node. We change the clock driver to
> > > probe on this binding. This would make sense as the clock gate register
> > > live completly in the MMSYS configuration registers.
> > 
> > The reason why the drm driver matches against the mmsys node in the
> > first place is that we wanted to avoid 2).
> 
> Why did you want to avoid 2) ?

Because the "display-subsystem" node does not represent a real device,
it's just there to probe the driver that stitches all the DISP
components together.

> > Also, mmsys is not a pure clock controller, as it also contains the
> > display path configuration in its register space.
> 
> Which makes the mmsys related to display, but more in a syscon (combining 
> clocks and routing, and I assume other miscellaneous features that wouldn't 
> fit nicely in the other display-related IP cores) way than actually being 
> part 
> of the display subsystem. Or does mmsys only provide display-related features 
> ?

All devices in the 0x1400 - 0x14ff memory range are part of the
MMSYS system. That includes the MMSYS control or system configuration
block at 0x1400 - 0x14000fff as well as all the related MDP (media
data path) and DISP (display data path) blocks that follow. The DISP
blocks are purely display related, while the MDP blocks implement
implement mem2mem functions like scaling and conversion.

> > > 2) As the nodes of the DRM subsystem just need some of the registers of
> > > MMSYS we add a new binding mediatek,mt8173-dispsys which probes the
> > > central component of the DRM system. It has only a handle to mt8173-mmsys
> > > to access the registerspace via regmap functions.
> > > 
> > > In this patchset I implemented 2). Please take into account, that this is
> > > a RFC. I had no time to actually test the verison on real HW. Some of the
> > > register accesses should be done using regmap_update instead of
> > > regmap_read + regmap_write.
> > > 
> > > This RFC shall only show how solution 2) would look like. We can use it as
> > > discussion to see how we circumvent the actual situation.
> > 
> > Or we could leave the bindings untouched and create one platform device
> > from the other or even set up the clocks from the drm driver?
> 
> Does mmsys provide features (such as clocks) to non-display IP cores ?

The MMSYS control block provides clocks for the DISP (display data path)
and MDP (multimedia data path) blocks, as well as the routing between
them, but not to anything outside of the MMSYS system.

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

[PULL] drm-intel-next

[Jani Nikula]

Hi Dave, I hoped this was going to be the last pull, but there's some
pressure for another. I'll tag more this week, and we can see next week
if you'd be willing to still take it.

BR,
Jani.

drm-intel-next-2017-10-12:
Last batch of drm/i915 features for v4.15:

- transparent huge pages support (Matthew)
- uapi: I915_PARAM_HAS_SCHEDULER into a capability bitmask (Chris)
- execlists: preemption (Chris)
- scheduler: user defined priorities (Chris)
- execlists optimization (Michał)
- plenty of display fixes (Imre)
- has_ipc fix (Rodrigo)
- platform features definition refactoring (Rodrigo)
- legacy cursor update fix (Maarten)
- fix vblank waits for cursor updates (Maarten)
- reprogram dmc firmware on resume, dmc state fix (Imre)
- remove use_mmio_flip module parameter (Maarten)
- wa fixes (Oscar)
- huc/guc firmware refacoring (Sagar, Michal)
- push encoder specific code to encoder hooks (Jani)
- DP MST fixes (Dhinakaran)
- eDP power sequencing fixes (Manasi)
- selftest updates (Chris, Matthew)
- mmu notifier cpu hotplug deadlock fix (Daniel)
- more VBT parser refactoring (Jani)
- max pipe refactoring (Mika Kahola)
- rc6/rps refactoring and separation (Sagar)
- userptr lockdep fix (Chris)
- tracepoint fixes and defunct tracepoint removal (Chris)
- use rcu instead of abusing stop_machine (Daniel)
- plenty of other fixes all around (Everyone)

The following changes since commit e18063e88bd579c479a2b45820be6c4625f841c3:

  drm/i915: Update DRIVER_DATE to 20170929 (2017-09-29 13:50:38 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2017-10-12

for you to fetch changes up to fa9caf0b6e69703ff8a4d4da17897008ec2f2dd3:

  drm/i915: Update DRIVER_DATE to 20171012 (2017-10-12 21:05:11 +0300)


Last batch of drm/i915 features for v4.15:

- transparent huge pages support (Matthew)
- uapi: I915_PARAM_HAS_SCHEDULER into a capability bitmask (Chris)
- execlists: preemption (Chris)
- scheduler: user defined priorities (Chris)
- execlists optimization (Michał)
- plenty of display fixes (Imre)
- has_ipc fix (Rodrigo)
- platform features definition refactoring (Rodrigo)
- legacy cursor update fix (Maarten)
- fix vblank waits for cursor updates (Maarten)
- reprogram dmc firmware on resume, dmc state fix (Imre)
- remove use_mmio_flip module parameter (Maarten)
- wa fixes (Oscar)
- huc/guc firmware refacoring (Sagar, Michal)
- push encoder specific code to encoder hooks (Jani)
- DP MST fixes (Dhinakaran)
- eDP power sequencing fixes (Manasi)
- selftest updates (Chris, Matthew)
- mmu notifier cpu hotplug deadlock fix (Daniel)
- more VBT parser refactoring (Jani)
- max pipe refactoring (Mika Kahola)
- rc6/rps refactoring and separation (Sagar)
- userptr lockdep fix (Chris)
- tracepoint fixes and defunct tracepoint removal (Chris)
- use rcu instead of abusing stop_machine (Daniel)
- plenty of other fixes all around (Everyone)


Arnd Bergmann (2):
  drm/i915/selftests: fix check for intel IOMMU
  drm/i915: avoid potential uninitialized variable use

Chris Wilson (34):
  drm/i915/selftests: Replace wmb() with i915_gem_chipset_flush()
  drm/i915/execlists: Move request unwinding to a separate function
  drm/i915: Give the invalid priority a magic name
  drm/i915: Move MMCD_MISC_CTRL from context w/a to standard
  drm/i915: Remove WA_(SET|CLR)_BIT
  drm/i915: Fix some tracepoints to capture full 64b
  drm/i915: Remove defunct trace points
  drm/i915/execlists: Distinguish the incomplete context notifies
  drm/i915: Introduce a preempt context
  drm/i915/execlists: Move bdw GPGPU w/a to emit_bb
  drm/i915/execlists: Keep request->priority for its lifetime
  drm/i915: Expand I915_PARAM_HAS_SCHEDULER into a capability bitmask
  drm/i915/execlists: Preemption!
  drm/i915/scheduler: Support user-defined priorities
  drm/i915/selftests: Remember to create the fake preempt context
  drm/i915: Try harder to finish the idle-worker
  drm/i915: Silence compiler warning for hsw_power_well_enable()
  drm/i915: Order two completing nop_submit_request
  drm/i915/execlists: Add a comment for the extra MI_ARB_ENABLE
  drm/i915: Assert we do not try to expand VMA for hugepage inside GGTT
  drm/i915: Make i915_engine_info pretty printer to standalone
  drm/i915/selftests: Pretty print engine state when requests fail to start
  drm/i915: Hold forcewake for the duration of reset+restart
  drm/i915/selftests: Hold the rpm wakeref for the reset tests
  drm/i915: Provide an assert for when we expect forcewake to be held
  drm/i915: Pin fence for iomap
  drm/i915: Consolidate get_fence with pin_fence
  drm/i915: Track user GTT faulting per-vma
  drm/i915: Check PIN_NONFAULT overlaps in evict_for_node
  drm/i915: Try a minimal attempt to insert 

Re: [PATCHv4 4/4] drm/tegra: add cec-notifier support

[Thierry Reding]

On Thu, Oct 19, 2017 at 03:37:43PM +0200, Hans Verkuil wrote:
> On 10/19/17 15:30, Thierry Reding wrote:
> > On Thu, Oct 19, 2017 at 03:17:16PM +0200, Thierry Reding wrote:
> >> On Mon, Sep 11, 2017 at 02:29:52PM +0200, Hans Verkuil wrote:
> >>> From: Hans Verkuil 
> >>>
> >>> In order to support CEC the HDMI driver has to inform the CEC driver
> >>> whenever the physical address changes. So when the EDID is read the
> >>> CEC driver has to be informed and whenever the hotplug detect goes
> >>> away.
> >>>
> >>> This is done through the cec-notifier framework.
> >>>
> >>> The link between the HDMI driver and the CEC driver is done through
> >>> the hdmi_phandle in the tegra-cec node in the device tree.
> >>>
> >>> Signed-off-by: Hans Verkuil 
> >>> ---
> >>>  drivers/gpu/drm/tegra/Kconfig  | 1 +
> >>>  drivers/gpu/drm/tegra/drm.h| 3 +++
> >>>  drivers/gpu/drm/tegra/hdmi.c   | 9 +
> >>>  drivers/gpu/drm/tegra/output.c | 6 ++
> >>>  4 files changed, 19 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> >>> index 2db29d67193d..c882918c2024 100644
> >>> --- a/drivers/gpu/drm/tegra/Kconfig
> >>> +++ b/drivers/gpu/drm/tegra/Kconfig
> >>> @@ -8,6 +8,7 @@ config DRM_TEGRA
> >>>   select DRM_PANEL
> >>>   select TEGRA_HOST1X
> >>>   select IOMMU_IOVA if IOMMU_SUPPORT
> >>> + select CEC_CORE if CEC_NOTIFIER
> >>>   help
> >>> Choose this option if you have an NVIDIA Tegra SoC.
> >>>  
> >>> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> >>> index 6d6da01282f3..c0a18b60caf1 100644
> >>> --- a/drivers/gpu/drm/tegra/drm.h
> >>> +++ b/drivers/gpu/drm/tegra/drm.h
> >>> @@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
> >>>  struct clk *clk, unsigned long pclk,
> >>>  unsigned int div);
> >>>  
> >>> +struct cec_notifier;
> >>> +
> >>>  struct tegra_output {
> >>>   struct device_node *of_node;
> >>>   struct device *dev;
> >>> @@ -219,6 +221,7 @@ struct tegra_output {
> >>>   struct drm_panel *panel;
> >>>   struct i2c_adapter *ddc;
> >>>   const struct edid *edid;
> >>> + struct cec_notifier *notifier;
> >>>   unsigned int hpd_irq;
> >>>   int hpd_gpio;
> >>>   enum of_gpio_flags hpd_gpio_flags;
> >>> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> >>> index cda0491ed6bf..fbf14e1efd0e 100644
> >>> --- a/drivers/gpu/drm/tegra/hdmi.c
> >>> +++ b/drivers/gpu/drm/tegra/hdmi.c
> >>> @@ -21,6 +21,8 @@
> >>>  
> >>>  #include 
> >>>  
> >>> +#include 
> >>> +
> >>>  #include "hdmi.h"
> >>>  #include "drm.h"
> >>>  #include "dc.h"
> >>> @@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device 
> >>> *pdev)
> >>>   return PTR_ERR(hdmi->vdd);
> >>>   }
> >>>  
> >>> + hdmi->output.notifier = cec_notifier_get(>dev);
> >>> + if (hdmi->output.notifier == NULL)
> >>> + return -ENOMEM;
> >>> +
> >>>   hdmi->output.dev = >dev;
> >>>  
> >>>   err = tegra_output_probe(>output);
> >>> @@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device 
> >>> *pdev)
> >>>  
> >>>   tegra_output_remove(>output);
> >>>  
> >>> + if (hdmi->output.notifier)
> >>> + cec_notifier_put(hdmi->output.notifier);
> >>> +
> >>>   return 0;
> >>>  }
> >>>  
> >>> diff --git a/drivers/gpu/drm/tegra/output.c 
> >>> b/drivers/gpu/drm/tegra/output.c
> >>> index 595d1ec3e02e..57c052521a44 100644
> >>> --- a/drivers/gpu/drm/tegra/output.c
> >>> +++ b/drivers/gpu/drm/tegra/output.c
> >>> @@ -11,6 +11,8 @@
> >>>  #include 
> >>>  #include "drm.h"
> >>>  
> >>> +#include 
> >>> +
> >>>  int tegra_output_connector_get_modes(struct drm_connector *connector)
> >>>  {
> >>>   struct tegra_output *output = connector_to_output(connector);
> >>> @@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct 
> >>> drm_connector *connector)
> >>>   edid = drm_get_edid(connector, output->ddc);
> >>>  
> >>>   drm_mode_connector_update_edid_property(connector, edid);
> >>> + cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
> >>
> >> I had to guard this with:
> >>
> >>#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
> >>...
> >>#endif
> >>
> >> to enable this driver to be built without CEC_NOTIFIER enabled. I see
> >> that there are stubs defined if the above is false, but for some reason
> >> they don't seem to be there for me either.
> > 
> > Nevermind that. This was not actually failing. However, ...
> > 
> >>>  
> >>>   if (edid) {
> >>>   err = drm_add_edid_modes(connector, edid);
> >>> @@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
> >>> *connector, bool force)
> >>>   status = connector_status_connected;
> >>>   }
> >>>  
> >>> + if (status != connector_status_connected)
> >>> + cec_notifier_phys_addr_invalidate(output->notifier);
> > 
> > This doesn't seem to exist in 

Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

[Laurent Pinchart]

Hi Philipp,

On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote:
> On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote:
> > In theory the MMSYS device tree identifier is matches twice, by the clk
> > driver and the DRM subsystem. But the kernel only matches the first
> > driver for a device (clk) and discards the second one. This breaks
> > graphics on mt8173 and most probably on mt2701 as well.
> > 
> > MMSYS in Mediatek SoCs has some registers to control clock gates (which is
> > used in the clk driver) and some registers to enable the differnet blocks
> > of the display subsystem. The kernel uses the binding to load the central
> > comoponent of the distplay subsystem, which in place probes all the other
> > components and enables the present ones in the MMSYS.
> > 
> > We found us with the problem, that we need to change and therefor break
> > one
> > of the two bindings, or the DRM one or the clock driver one.
> > 
> > Apart from that the DRM subysystem does access the MMSYS registers via
> > relaxed reads/writes. But the it should to so via regmap, as the
> > registers are shared.
> > 
> > Possible solutions:
> > 1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a
> > simple-mfd under the actual mmsys node. We change the clock driver to
> > probe on this binding. This would make sense as the clock gate register
> > live completly in the MMSYS configuration registers.
> 
> The reason why the drm driver matches against the mmsys node in the
> first place is that we wanted to avoid 2).

Why did you want to avoid 2) ?

> Also, mmsys is not a pure clock controller, as it also contains the
> display path configuration in its register space.

Which makes the mmsys related to display, but more in a syscon (combining 
clocks and routing, and I assume other miscellaneous features that wouldn't 
fit nicely in the other display-related IP cores) way than actually being part 
of the display subsystem. Or does mmsys only provide display-related features 
?

> > 2) As the nodes of the DRM subsystem just need some of the registers of
> > MMSYS we add a new binding mediatek,mt8173-dispsys which probes the
> > central component of the DRM system. It has only a handle to mt8173-mmsys
> > to access the registerspace via regmap functions.
> > 
> > In this patchset I implemented 2). Please take into account, that this is
> > a RFC. I had no time to actually test the verison on real HW. Some of the
> > register accesses should be done using regmap_update instead of
> > regmap_read + regmap_write.
> > 
> > This RFC shall only show how solution 2) would look like. We can use it as
> > discussion to see how we circumvent the actual situation.
> 
> Or we could leave the bindings untouched and create one platform device
> from the other or even set up the clocks from the drm driver?

Does mmsys provide features (such as clocks) to non-display IP cores ?

-- 
Regards,

Laurent Pinchart

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

Re: [PATCHv4 4/4] drm/tegra: add cec-notifier support

[Hans Verkuil]

On 10/19/17 15:30, Thierry Reding wrote:
> On Thu, Oct 19, 2017 at 03:17:16PM +0200, Thierry Reding wrote:
>> On Mon, Sep 11, 2017 at 02:29:52PM +0200, Hans Verkuil wrote:
>>> From: Hans Verkuil 
>>>
>>> In order to support CEC the HDMI driver has to inform the CEC driver
>>> whenever the physical address changes. So when the EDID is read the
>>> CEC driver has to be informed and whenever the hotplug detect goes
>>> away.
>>>
>>> This is done through the cec-notifier framework.
>>>
>>> The link between the HDMI driver and the CEC driver is done through
>>> the hdmi_phandle in the tegra-cec node in the device tree.
>>>
>>> Signed-off-by: Hans Verkuil 
>>> ---
>>>  drivers/gpu/drm/tegra/Kconfig  | 1 +
>>>  drivers/gpu/drm/tegra/drm.h| 3 +++
>>>  drivers/gpu/drm/tegra/hdmi.c   | 9 +
>>>  drivers/gpu/drm/tegra/output.c | 6 ++
>>>  4 files changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
>>> index 2db29d67193d..c882918c2024 100644
>>> --- a/drivers/gpu/drm/tegra/Kconfig
>>> +++ b/drivers/gpu/drm/tegra/Kconfig
>>> @@ -8,6 +8,7 @@ config DRM_TEGRA
>>> select DRM_PANEL
>>> select TEGRA_HOST1X
>>> select IOMMU_IOVA if IOMMU_SUPPORT
>>> +   select CEC_CORE if CEC_NOTIFIER
>>> help
>>>   Choose this option if you have an NVIDIA Tegra SoC.
>>>  
>>> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
>>> index 6d6da01282f3..c0a18b60caf1 100644
>>> --- a/drivers/gpu/drm/tegra/drm.h
>>> +++ b/drivers/gpu/drm/tegra/drm.h
>>> @@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
>>>struct clk *clk, unsigned long pclk,
>>>unsigned int div);
>>>  
>>> +struct cec_notifier;
>>> +
>>>  struct tegra_output {
>>> struct device_node *of_node;
>>> struct device *dev;
>>> @@ -219,6 +221,7 @@ struct tegra_output {
>>> struct drm_panel *panel;
>>> struct i2c_adapter *ddc;
>>> const struct edid *edid;
>>> +   struct cec_notifier *notifier;
>>> unsigned int hpd_irq;
>>> int hpd_gpio;
>>> enum of_gpio_flags hpd_gpio_flags;
>>> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
>>> index cda0491ed6bf..fbf14e1efd0e 100644
>>> --- a/drivers/gpu/drm/tegra/hdmi.c
>>> +++ b/drivers/gpu/drm/tegra/hdmi.c
>>> @@ -21,6 +21,8 @@
>>>  
>>>  #include 
>>>  
>>> +#include 
>>> +
>>>  #include "hdmi.h"
>>>  #include "drm.h"
>>>  #include "dc.h"
>>> @@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device 
>>> *pdev)
>>> return PTR_ERR(hdmi->vdd);
>>> }
>>>  
>>> +   hdmi->output.notifier = cec_notifier_get(>dev);
>>> +   if (hdmi->output.notifier == NULL)
>>> +   return -ENOMEM;
>>> +
>>> hdmi->output.dev = >dev;
>>>  
>>> err = tegra_output_probe(>output);
>>> @@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device 
>>> *pdev)
>>>  
>>> tegra_output_remove(>output);
>>>  
>>> +   if (hdmi->output.notifier)
>>> +   cec_notifier_put(hdmi->output.notifier);
>>> +
>>> return 0;
>>>  }
>>>  
>>> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
>>> index 595d1ec3e02e..57c052521a44 100644
>>> --- a/drivers/gpu/drm/tegra/output.c
>>> +++ b/drivers/gpu/drm/tegra/output.c
>>> @@ -11,6 +11,8 @@
>>>  #include 
>>>  #include "drm.h"
>>>  
>>> +#include 
>>> +
>>>  int tegra_output_connector_get_modes(struct drm_connector *connector)
>>>  {
>>> struct tegra_output *output = connector_to_output(connector);
>>> @@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
>>> *connector)
>>> edid = drm_get_edid(connector, output->ddc);
>>>  
>>> drm_mode_connector_update_edid_property(connector, edid);
>>> +   cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
>>
>> I had to guard this with:
>>
>>  #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>>  ...
>>  #endif
>>
>> to enable this driver to be built without CEC_NOTIFIER enabled. I see
>> that there are stubs defined if the above is false, but for some reason
>> they don't seem to be there for me either.
> 
> Nevermind that. This was not actually failing. However, ...
> 
>>>  
>>> if (edid) {
>>> err = drm_add_edid_modes(connector, edid);
>>> @@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
>>> *connector, bool force)
>>> status = connector_status_connected;
>>> }
>>>  
>>> +   if (status != connector_status_connected)
>>> +   cec_notifier_phys_addr_invalidate(output->notifier);
> 
> This doesn't seem to exist in v4.14-rc1 which is the base for the
> drm/tegra tree for v4.15. I see this function will be introduced in
> v4.15 via the media tree.

Strange. This was released in the 4.13 kernel, so you should really have it.
It compiles fine for me, both with the drm tegra 

Re: [Spice-devel] [PATCH] drm/qxl: workaround broken qxl hw primary setting.

[Gerd Hoffmann]

On Thu, 2017-10-19 at 07:28 -0400, Frediano Ziglio wrote:

> > This tries to work out when the commit is likely just a pageflip
> > and avoid touching the primary surface, this might go wrong at
> > some point but I believe it's the same level as wrong as the old
> > code
> > base.
> > 
> > Signed-off-by: Dave Airlie 
> > ---
> >  drivers/gpu/drm/qxl/qxl_display.c | 21 +++--
> >  1 file changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> > b/drivers/gpu/drm/qxl/qxl_display.c
> > index afbf50d..3b702d1 100644
> > --- a/drivers/gpu/drm/qxl/qxl_display.c
> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
> > @@ -502,6 +502,7 @@ static void qxl_primary_atomic_update(struct
> > drm_plane
> > *plane,
> >     struct qxl_framebuffer *qfb_old;
> >     struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
> >     struct qxl_bo *bo_old;
> > +   bool update_primary = true;
> >     struct drm_clip_rect norect = {
> >     .x1 = 0,
> >     .y1 = 0,
> > @@ -519,15 +520,31 @@ static void qxl_primary_atomic_update(struct
> > drm_plane
> > *plane,
> >     if (bo == bo_old)
> >     return;
> >  
> > +   if (bo && bo_old &&
> > +   plane->state->crtc == old_state->crtc &&
> > +   plane->state->crtc_w == old_state->crtc_w &&
> > +   plane->state->crtc_h == old_state->crtc_h &&
> > +   plane->state->src_x == old_state->src_x &&
> > +   plane->state->src_y == old_state->src_y &&
> > +   plane->state->src_w == old_state->src_w &&
> > +   plane->state->src_h == old_state->src_h &&
> > +   plane->state->rotation == old_state->rotation &&
> > +   plane->state->zpos == old_state->zpos)
> > +   /* this is likely a pageflip */
> > +   update_primary = false;
> > +
> >     if (bo_old && bo_old->is_primary) {
> > -   qxl_io_destroy_primary(qdev);
> > +   if (update_primary)
> > +   qxl_io_destroy_primary(qdev);
> >     bo_old->is_primary = false;
> >     }
> >  
> >     if (!bo->is_primary) {
> > -   qxl_io_create_primary(qdev, 0, bo);
> > +   if (update_primary)
> > +   qxl_io_create_primary(qdev, 0, bo);
> >     bo->is_primary = true;
> 
> Here the primary is still the old object but you are setting the
> new.
> Looking around the old is unpinned and the new one pinned which
> is now wrong as QXL device suppose the memory pointer by the
> primary surface (after your patch bo_old object) remains
> available.

Yes.

So it is bug compatible with commit 058e9f5c82, as the commit message
claims ;)

> If we are not able to avoid the copy and we need to keep the old
> surface in place maybe instead of creating the new object as SURFACE
> we could just use for source for the Drawable for the DRAW_COPY
> operation.
> In this way when release is received the object can be unpinned being
> free to be moved.

https://lists.freedesktop.org/archives/dri-devel/2017-October/155541.ht
ml

cheers,
  Gerd

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

Re: [PATCHv4 4/4] drm/tegra: add cec-notifier support

[Thierry Reding]

On Thu, Oct 19, 2017 at 03:17:16PM +0200, Thierry Reding wrote:
> On Mon, Sep 11, 2017 at 02:29:52PM +0200, Hans Verkuil wrote:
> > From: Hans Verkuil 
> > 
> > In order to support CEC the HDMI driver has to inform the CEC driver
> > whenever the physical address changes. So when the EDID is read the
> > CEC driver has to be informed and whenever the hotplug detect goes
> > away.
> > 
> > This is done through the cec-notifier framework.
> > 
> > The link between the HDMI driver and the CEC driver is done through
> > the hdmi_phandle in the tegra-cec node in the device tree.
> > 
> > Signed-off-by: Hans Verkuil 
> > ---
> >  drivers/gpu/drm/tegra/Kconfig  | 1 +
> >  drivers/gpu/drm/tegra/drm.h| 3 +++
> >  drivers/gpu/drm/tegra/hdmi.c   | 9 +
> >  drivers/gpu/drm/tegra/output.c | 6 ++
> >  4 files changed, 19 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> > index 2db29d67193d..c882918c2024 100644
> > --- a/drivers/gpu/drm/tegra/Kconfig
> > +++ b/drivers/gpu/drm/tegra/Kconfig
> > @@ -8,6 +8,7 @@ config DRM_TEGRA
> > select DRM_PANEL
> > select TEGRA_HOST1X
> > select IOMMU_IOVA if IOMMU_SUPPORT
> > +   select CEC_CORE if CEC_NOTIFIER
> > help
> >   Choose this option if you have an NVIDIA Tegra SoC.
> >  
> > diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> > index 6d6da01282f3..c0a18b60caf1 100644
> > --- a/drivers/gpu/drm/tegra/drm.h
> > +++ b/drivers/gpu/drm/tegra/drm.h
> > @@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
> >struct clk *clk, unsigned long pclk,
> >unsigned int div);
> >  
> > +struct cec_notifier;
> > +
> >  struct tegra_output {
> > struct device_node *of_node;
> > struct device *dev;
> > @@ -219,6 +221,7 @@ struct tegra_output {
> > struct drm_panel *panel;
> > struct i2c_adapter *ddc;
> > const struct edid *edid;
> > +   struct cec_notifier *notifier;
> > unsigned int hpd_irq;
> > int hpd_gpio;
> > enum of_gpio_flags hpd_gpio_flags;
> > diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> > index cda0491ed6bf..fbf14e1efd0e 100644
> > --- a/drivers/gpu/drm/tegra/hdmi.c
> > +++ b/drivers/gpu/drm/tegra/hdmi.c
> > @@ -21,6 +21,8 @@
> >  
> >  #include 
> >  
> > +#include 
> > +
> >  #include "hdmi.h"
> >  #include "drm.h"
> >  #include "dc.h"
> > @@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device 
> > *pdev)
> > return PTR_ERR(hdmi->vdd);
> > }
> >  
> > +   hdmi->output.notifier = cec_notifier_get(>dev);
> > +   if (hdmi->output.notifier == NULL)
> > +   return -ENOMEM;
> > +
> > hdmi->output.dev = >dev;
> >  
> > err = tegra_output_probe(>output);
> > @@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device 
> > *pdev)
> >  
> > tegra_output_remove(>output);
> >  
> > +   if (hdmi->output.notifier)
> > +   cec_notifier_put(hdmi->output.notifier);
> > +
> > return 0;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> > index 595d1ec3e02e..57c052521a44 100644
> > --- a/drivers/gpu/drm/tegra/output.c
> > +++ b/drivers/gpu/drm/tegra/output.c
> > @@ -11,6 +11,8 @@
> >  #include 
> >  #include "drm.h"
> >  
> > +#include 
> > +
> >  int tegra_output_connector_get_modes(struct drm_connector *connector)
> >  {
> > struct tegra_output *output = connector_to_output(connector);
> > @@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
> > *connector)
> > edid = drm_get_edid(connector, output->ddc);
> >  
> > drm_mode_connector_update_edid_property(connector, edid);
> > +   cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
> 
> I had to guard this with:
> 
>   #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>   ...
>   #endif
> 
> to enable this driver to be built without CEC_NOTIFIER enabled. I see
> that there are stubs defined if the above is false, but for some reason
> they don't seem to be there for me either.

Nevermind that. This was not actually failing. However, ...

> >  
> > if (edid) {
> > err = drm_add_edid_modes(connector, edid);
> > @@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
> > *connector, bool force)
> > status = connector_status_connected;
> > }
> >  
> > +   if (status != connector_status_connected)
> > +   cec_notifier_phys_addr_invalidate(output->notifier);

This doesn't seem to exist in v4.14-rc1 which is the base for the
drm/tegra tree for v4.15. I see this function will be introduced in
v4.15 via the media tree.

How about if I replace this by:

cec_notifier_set_phys(output->notifier, CEC_PHYS_ADDR_INVALID);

for now and switch it over to the new function after v4.15-rc1? That way
we can 

Re: [PATCHv4 4/4] drm/tegra: add cec-notifier support

[Thierry Reding]

On Mon, Sep 11, 2017 at 02:29:52PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> In order to support CEC the HDMI driver has to inform the CEC driver
> whenever the physical address changes. So when the EDID is read the
> CEC driver has to be informed and whenever the hotplug detect goes
> away.
> 
> This is done through the cec-notifier framework.
> 
> The link between the HDMI driver and the CEC driver is done through
> the hdmi_phandle in the tegra-cec node in the device tree.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/tegra/Kconfig  | 1 +
>  drivers/gpu/drm/tegra/drm.h| 3 +++
>  drivers/gpu/drm/tegra/hdmi.c   | 9 +
>  drivers/gpu/drm/tegra/output.c | 6 ++
>  4 files changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 2db29d67193d..c882918c2024 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -8,6 +8,7 @@ config DRM_TEGRA
>   select DRM_PANEL
>   select TEGRA_HOST1X
>   select IOMMU_IOVA if IOMMU_SUPPORT
> + select CEC_CORE if CEC_NOTIFIER
>   help
> Choose this option if you have an NVIDIA Tegra SoC.
>  
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 6d6da01282f3..c0a18b60caf1 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
>  struct clk *clk, unsigned long pclk,
>  unsigned int div);
>  
> +struct cec_notifier;
> +
>  struct tegra_output {
>   struct device_node *of_node;
>   struct device *dev;
> @@ -219,6 +221,7 @@ struct tegra_output {
>   struct drm_panel *panel;
>   struct i2c_adapter *ddc;
>   const struct edid *edid;
> + struct cec_notifier *notifier;
>   unsigned int hpd_irq;
>   int hpd_gpio;
>   enum of_gpio_flags hpd_gpio_flags;
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> index cda0491ed6bf..fbf14e1efd0e 100644
> --- a/drivers/gpu/drm/tegra/hdmi.c
> +++ b/drivers/gpu/drm/tegra/hdmi.c
> @@ -21,6 +21,8 @@
>  
>  #include 
>  
> +#include 
> +
>  #include "hdmi.h"
>  #include "drm.h"
>  #include "dc.h"
> @@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(hdmi->vdd);
>   }
>  
> + hdmi->output.notifier = cec_notifier_get(>dev);
> + if (hdmi->output.notifier == NULL)
> + return -ENOMEM;
> +
>   hdmi->output.dev = >dev;
>  
>   err = tegra_output_probe(>output);
> @@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device 
> *pdev)
>  
>   tegra_output_remove(>output);
>  
> + if (hdmi->output.notifier)
> + cec_notifier_put(hdmi->output.notifier);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index 595d1ec3e02e..57c052521a44 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -11,6 +11,8 @@
>  #include 
>  #include "drm.h"
>  
> +#include 
> +
>  int tegra_output_connector_get_modes(struct drm_connector *connector)
>  {
>   struct tegra_output *output = connector_to_output(connector);
> @@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
> *connector)
>   edid = drm_get_edid(connector, output->ddc);
>  
>   drm_mode_connector_update_edid_property(connector, edid);
> + cec_notifier_set_phys_addr_from_edid(output->notifier, edid);

I had to guard this with:

#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
...
#endif

to enable this driver to be built without CEC_NOTIFIER enabled. I see
that there are stubs defined if the above is false, but for some reason
they don't seem to be there for me either.

>  
>   if (edid) {
>   err = drm_add_edid_modes(connector, edid);
> @@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
> *connector, bool force)
>   status = connector_status_connected;
>   }
>  
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(output->notifier);

Same here.

Thierry


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

[PATCH] drm/etnaviv: fix GPU vs sync point race

[Lucas Stach]

If the FE is restarted before the sync point event is cleared, the GPU
might trigger a completion IRQ for the next sync point before corrupting
the state of the currently running worker.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 93a103eb1083..8ff5d01e776d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1484,22 +1484,18 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
return ret;
 }
 
-static void etnaviv_process_sync_point(struct etnaviv_gpu *gpu,
-   struct etnaviv_event *event)
-{
-   u32 addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
-
-   event->sync_point(gpu, event);
-   etnaviv_gpu_start_fe(gpu, addr + 2, 2);
-}
-
 static void sync_point_worker(struct work_struct *work)
 {
struct etnaviv_gpu *gpu = container_of(work, struct etnaviv_gpu,
   sync_point_work);
+   struct etnaviv_event *event = >event[gpu->sync_point_event];
+   u32 addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
 
-   etnaviv_process_sync_point(gpu, >event[gpu->sync_point_event]);
+   event->sync_point(gpu, event);
event_free(gpu, gpu->sync_point_event);
+
+   /* restart FE last to avoid GPU and IRQ racing against this worker */
+   etnaviv_gpu_start_fe(gpu, addr + 2, 2);
 }
 
 /*
-- 
2.11.0

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

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

[Philipp Zabel]

On Thu, 2017-10-19 at 15:53 +0300, Laurent Pinchart wrote:
> Hi Matthias,
> 
> Thank you for the patch.
> 
> On Thursday, 19 October 2017 14:26:07 EEST Matthias Brugger wrote:
> > DRM subysystem and clock driver shared the same compatible mmsys.
> > This stopped does not work, as only the first driver for a compatible
> > gets probed. We change the comaptible to the new DRM identifier to fix
> > this.
> > 
> > Signed-off-by: Matthias Brugger 
> > ---
> >  .../devicetree/bindings/display/mediatek/mediatek,disp.txt  | 6 +++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > index 383183a89164..6db652463e64 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > @@ -27,6 +27,7 @@
> > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
> > 
> >  Required properties (all function blocks):
> >  - compatible: "mediatek,-disp-", one of
> > +   "mediatek,-dispsys"- central component for the DRM system
> > "mediatek,-disp-ovl"   - overlay (4 layers, blending, csc)
> > "mediatek,-disp-rdma"  - read DMA / line buffer
> > "mediatek,-disp-wdma"  - write DMA
> > @@ -71,6 +72,11 @@ mmsys: clock-controller@1400 {
> > #clock-cells = <1>;
> >  };
> > 
> > +dispsys: display-system {
> > +   compatible = "mediatek,mt2701-dispsys";
> > +   mediatek,mmsys = <>;
> > +}
> 
> So this node doesn't correspond to an IP core but is meant as a top-level 
> entry point for the operating system. This leads me to three questions.
> 
> 1. Is there any IP core in the Mediatek display subsystem that could be 
> considered (or at least used) as a top-level entry point ? That would be my 
> preferred solution as I'm not fond of DT nodes not describing hardware.

At least on MT8173 that node is MMSYS, which it is currently matching
against. The issue, if I understand correctly, is that the clocks
provided by this same region were previously created via CLK_OF_DECLARE,
and are now changed to a separate clock driver that matches to the same 
node.

> 2. If there's no such IP core, are all the display subsystem IP cores grouped 
> together in one MMIO register range ? If so we could move them as children of 
> this new display system node which, even if doesn't describe an IP core, 
> would 
> describe the way the display IP cores are grouped in the hardware, and would 
> thus be a hardware description.
> 
> 3. If the answer to the second question is also negative, shouldn't this 
> display system node reference all other display IP DT nodes (through direct 
> phandles and/or OF graph bindings) ?
> 
> >  ovl0: ovl@1400c000 {
> > compatible = "mediatek,mt8173-disp-ovl";
> > reg = <0 0x1400c000 0 0x1000>;
> 

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

Re: [PATCH v3 6/9] drm/exynos: fimc: Convert driver to IPP v2 core API

[Tobias Jakobi]

Marek Szyprowski wrote:
> This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
"DRM FIMC driver"

- Tobias


> 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   |   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 930 
> ++-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.h |  23 -
>  4 files changed, 282 insertions(+), 674 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 4bb9edb00601..33ef84be2d7f 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -99,7 +99,7 @@ config DRM_EXYNOS_IPP
>  
>  config DRM_EXYNOS_FIMC
>   bool "FIMC"
> - depends on BROKEN && MFD_SYSCON
> + select DRM_EXYNOS_IPP
>   help
> Choose this option if you want to use Exynos FIMC for DRM.
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 60ae6ae06eb2..4afeffa024f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -256,6 +256,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] 
> = {
>   DRV_PTR(g2d_driver, CONFIG_DRM_EXYNOS_G2D),
>   }, {
>   DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
> + DRM_COMPONENT_DRIVER | DRM_SHARED_DEVICE,
>   }, {
>   DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
>   DRM_COMPONENT_DRIVER
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 5b18b5c5fdf2..870f14b775b5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -12,6 +12,7 @@
>   *
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -24,8 +25,9 @@
>  #include 
>  #include "regs-fimc.h"
>  #include "exynos_drm_drv.h"
> +#include "exynos_drm_iommu.h"
>  #include "exynos_drm_ipp.h"
> -#include "exynos_drm_fimc.h"
> +
>  
>  /*
>   * FIMC stands for Fully Interactive Mobile Camera and
> @@ -33,23 +35,6 @@
>   * input DMA reads image data from the memory.
>   * output DMA writes image data to memory.
>   * FIMC supports image rotation and image effect functions.
> - *
> - * M2M operation : supports crop/scale/rotation/csc so on.
> - * Memory > FIMC H/W > Memory.
> - * Writeback operation : supports cloned screen with FIMD.
> - * FIMD > FIMC H/W > Memory.
> - * Output operation : supports direct display using local path.
> - * Memory > FIMC H/W > FIMD.
> - */
> -
> -/*
> - * 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 FIMC_MAX_DEVS4
> @@ -59,29 +44,15 @@
>  #define FIMC_BUF_STOP1
>  #define FIMC_BUF_START   2
>  #define FIMC_WIDTH_ITU_709   1280
> -#define FIMC_REFRESH_MAX 60
> -#define FIMC_REFRESH_MIN 12
> -#define FIMC_CROP_MAX8192
> -#define FIMC_CROP_MIN32
> -#define FIMC_SCALE_MAX   4224
> -#define FIMC_SCALE_MIN   32
> +#define FIMC_AUTOSUSPEND_DELAY   2000
>  
>  #define get_fimc_context(dev)
> platform_get_drvdata(to_platform_device(dev))
> -#define get_ctx_from_ippdrv(ippdrv)  container_of(ippdrv,\
> - struct fimc_context, ippdrv);
> -enum fimc_wb {
> - FIMC_WB_NONE,
> - FIMC_WB_A,
> - FIMC_WB_B,
> -};
>  
>  enum {
>   FIMC_CLK_LCLK,
>   FIMC_CLK_GATE,
>   FIMC_CLK_WB_A,
>   FIMC_CLK_WB_B,
> - FIMC_CLK_MUX,
> - FIMC_CLK_PARENT,
>   FIMC_CLKS_MAX
>  };
>  
> @@ -90,8 +61,6 @@ static const char * const fimc_clock_names[] = {
>   [FIMC_CLK_GATE]   = "fimc",
>   [FIMC_CLK_WB_A]   = "pxl_async0",
>   [FIMC_CLK_WB_B]   = "pxl_async1",
> - [FIMC_CLK_MUX]= "mux",
> - [FIMC_CLK_PARENT] = "parent",
>  };
>  
>  #define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL
> @@ -141,31 +110,29 @@ struct fimc_capability {
>  /*
>   * A structure of fimc context.
>   *
> - * @ippdrv: prepare initialization using ippdrv.
>   * @regs_res: register resources.
>   * @regs: memory mapped io registers.
>   * @lock: locking of operations.
>   * @clocks: fimc clocks.
> - * @clk_frequency: LCLK clock frequency.
> - * @sysreg: handle to SYSREG block regmap.
>   * @sc: scaler infomations.
>   * @pol: porarity of writeback.
>   * @id: fimc id.
>   * @irq: irq number.
> - * @suspended: qos operations.
>   */
>  struct fimc_context {
> - struct 

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

[Tobias Jakobi]

Hey Marek,


Marek Szyprowski wrote:
> This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
you probably mean "DRM gsc driver" here (or GSC, not sure about capitalisation).

- Tobias


> 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 
> Tested-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/Kconfig  |   3 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 995 
> ++--
>  drivers/gpu/drm/exynos/exynos_drm_gsc.h |  24 -
>  4 files changed, 315 insertions(+), 708 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 3ade2b0ad15d..cac0d84385d3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -260,6 +260,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] 
> = {
>   DRM_COMPONENT_DRIVER
>   }, {
>   DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
> + DRM_COMPONENT_DRIVER
>   }, {
>   _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..f99d4fea9df1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -12,18 +12,20 @@
>   *
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
>  #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 +33,10 @@
>   * 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_CLOCKS   8
>  #define GSC_MAX_SRC  4
>  #define GSC_MAX_DST  16
>  #define GSC_RESET_TIMEOUT50
> @@ -65,8 +51,6 @@
>  #define GSC_SC_DOWN_RATIO_4_8131072
>  #define GSC_SC_DOWN_RATIO_3_8174762
>  #define GSC_SC_DOWN_RATIO_2_8262144
> -#define GSC_REFRESH_MIN  12
> -#define GSC_REFRESH_MAX  60
>  #define GSC_CROP_MAX 8192
>  #define GSC_CROP_MIN 32
>  #define GSC_SCALE_MAX4224
> @@ -77,10 +61,9 @@
>  #define GSC_COEF_H_8T8
>  #define GSC_COEF_V_4T4
>  #define GSC_COEF_DEPTH   3
> +#define GSC_AUTOSUSPEND_DELAY2000
>  
>  #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 +107,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,12 +119,18 @@ 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 

Re: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

[Philipp Zabel]

On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote:
> In theory the MMSYS device tree identifier is matches twice, by the clk 
> driver 
> and the DRM subsystem. But the kernel only matches the first driver for a 
> device (clk) and discards the second one. This breaks graphics on mt8173 and 
> most probably on mt2701 as well.
> 
> MMSYS in Mediatek SoCs has some registers to control clock gates (which is 
> used in the clk driver) and some registers to enable the differnet blocks of 
> the display subsystem. The kernel uses the binding to load the central 
> comoponent of the distplay subsystem, which in place probes all the other 
> components and enables the present ones in the MMSYS.
> 
> We found us with the problem, that we need to change and therefor break one 
> of the two bindings, or the DRM one or the clock driver one.
> 
> Apart from that the DRM subysystem does access the MMSYS registers via 
> relaxed 
> reads/writes. But the it should to so via regmap, as the registers are shared.
> 
> Possible solutions:
> 1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a simple-mfd 
> under the actual mmsys node. We change the clock driver to probe on this 
> binding. This would make sense as the clock gate register live completly in 
> the MMSYS configuration registers.

The reason why the drm driver matches against the mmsys node in the
first place is that we wanted to avoid 2).
Also, mmsys is not a pure clock controller, as it also contains the
display path configuration in its register space.

> 2) As the nodes of the DRM subsystem just need some of the registers of MMSYS 
> we add a new binding mediatek,mt8173-dispsys which probes the central 
> component of the DRM system. It has only a handle to mt8173-mmsys to access 
> the registerspace via regmap functions.
> 
> In this patchset I implemented 2). Please take into account, that this is a 
> RFC. I had no time to actually test the verison on real HW. Some of the 
> register accesses should be done using regmap_update instead of 
> regmap_read + regmap_write.
> 
> This RFC shall only show how solution 2) would look like. We can use it as 
> discussion to see how we circumvent the actual situation.

Or we could leave the bindings untouched and create one platform device
from the other or even set up the clocks from the drm driver?

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

[PATCH v4] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl

[Boris Brezillon]

This ioctl will allow us to purge inactive userspace buffers when the
system is running out of contiguous memory.

For now, the purge logic is rather dumb in that it does not try to
release only the amount of BO needed to meet the last CMA alloc request
but instead purges all objects placed in the purgeable pool as soon as
we experience a CMA allocation failure.

Note that the in-kernel BO cache is always purged before the purgeable
cache because those objects are known to be unused while objects marked
as purgeable by a userspace application/library might have to be
restored when they are marked back as unpurgeable, which can be
expensive.

Signed-off-by: Boris Brezillon 
---
Hello,

Updates to libdrm, mesa and igt making use of this kernel feature can
be found on my github repos [1][2][3].

There's currently no debugfs hook to manually force a purge, but this
is being discussed and might be added later on.

Regards,

Boris

[1]https://github.com/bbrezillon/drm/tree/vc4/purgeable
[2]https://github.com/bbrezillon/mesa/tree/vc4/purgeable
[3]https://github.com/bbrezillon/igt/tree/vc4/purgeable

Changes in v4:
- Fix a race in the purge logic
- Move purgeable/purged dump in the locked section to avoid declaring
  intermediate variables
- use drm_gem_object_put_unlocked() instead of drm_gem_object_put()
  in the vc4_cl_lookup_bos() error path

Changes in v3:
- Use %zd formatters when printing size_t values
- rework detection of BOs that do not support the MADV ioctl
- replace DRM_ERROR by DRM_DEBUG in the ioctl path
- do not explicitly memzero purged BO mem
- check that pad is set to zero in the madv ioctl function

Changes in v2:
- Do not re-allocate BO's memory after when WILLNEED is asked after a purge
- Add purgeable/purged stats to debugfs and dumpstats
- Pad the drm_vc4_gem_madvise to make it 64-bit aligned
- Forbid madvise calls on internal BO objects (everything that is not
  meant to be exposed to userspace)
- Do not increment/decrement usecnt on internal BOs (they cannot be marked
  purgeable, so doing that is useless and error prone)
- Fix a few bugs related to usecnt refcounting
---
 drivers/gpu/drm/vc4/vc4_bo.c| 287 ++--
 drivers/gpu/drm/vc4/vc4_drv.c   |  10 +-
 drivers/gpu/drm/vc4/vc4_drv.h   |  30 +
 drivers/gpu/drm/vc4/vc4_gem.c   | 156 +-
 drivers/gpu/drm/vc4/vc4_plane.c |  20 +++
 include/uapi/drm/vc4_drm.h  |  19 +++
 6 files changed, 507 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 3afdbf4bc10b..01a53ba304f8 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -53,6 +53,17 @@ static void vc4_bo_stats_dump(struct vc4_dev *vc4)
 vc4->bo_labels[i].size_allocated / 1024,
 vc4->bo_labels[i].num_allocated);
}
+
+   mutex_lock(>purgeable.lock);
+   if (vc4->purgeable.num)
+   DRM_INFO("%30s: %6zdkb BOs (%d)\n", "userspace BO cache",
+vc4->purgeable.size / 1024, vc4->purgeable.num);
+
+   if (vc4->purgeable.purged_num)
+   DRM_INFO("%30s: %6zdkb BOs (%d)\n", "total purged BO",
+vc4->purgeable.purged_size / 1024,
+vc4->purgeable.purged_num);
+   mutex_unlock(>purgeable.lock);
 }
 
 #ifdef CONFIG_DEBUG_FS
@@ -75,6 +86,17 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
}
mutex_unlock(>bo_lock);
 
+   mutex_lock(>purgeable.lock);
+   if (vc4->purgeable.num)
+   seq_printf(m, "%30s: %6dkb BOs (%d)\n", "userspace BO cache",
+  vc4->purgeable.size / 1024, vc4->purgeable.num);
+
+   if (vc4->purgeable.purged_num)
+   seq_printf(m, "%30s: %6dkb BOs (%d)\n", "total purged BO",
+  vc4->purgeable.purged_size / 1024,
+  vc4->purgeable.purged_num);
+   mutex_unlock(>purgeable.lock);
+
return 0;
 }
 #endif
@@ -247,6 +269,109 @@ static void vc4_bo_cache_purge(struct drm_device *dev)
mutex_unlock(>bo_lock);
 }
 
+void vc4_bo_add_to_purgeable_pool(struct vc4_bo *bo)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
+
+   mutex_lock(>purgeable.lock);
+   list_add_tail(>size_head, >purgeable.list);
+   vc4->purgeable.num++;
+   vc4->purgeable.size += bo->base.base.size;
+   mutex_unlock(>purgeable.lock);
+}
+
+static void vc4_bo_remove_from_purgeable_pool_locked(struct vc4_bo *bo)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
+
+   /* list_del_init() is used here because the caller might release
+* the purgeable lock in order to acquire the madv one and update the
+* madv status.
+* During this short period of time a user might decide to mark
+* the BO as unpurgeable, and if bo->madv is set to
+* 

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

[Laurent Pinchart]

Hi Matthias,

Thank you for the patch.

On Thursday, 19 October 2017 14:26:07 EEST Matthias Brugger wrote:
> DRM subysystem and clock driver shared the same compatible mmsys.
> This stopped does not work, as only the first driver for a compatible
> gets probed. We change the comaptible to the new DRM identifier to fix
> this.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,disp.txt  | 6 +++
>  1 file changed, 6 insertions(+)
> 
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index 383183a89164..6db652463e64 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -27,6 +27,7 @@
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
> 
>  Required properties (all function blocks):
>  - compatible: "mediatek,-disp-", one of
> + "mediatek,-dispsys"- central component for the DRM system
>   "mediatek,-disp-ovl"   - overlay (4 layers, blending, csc)
>   "mediatek,-disp-rdma"  - read DMA / line buffer
>   "mediatek,-disp-wdma"  - write DMA
> @@ -71,6 +72,11 @@ mmsys: clock-controller@1400 {
>   #clock-cells = <1>;
>  };
> 
> +dispsys: display-system {
> + compatible = "mediatek,mt2701-dispsys";
> + mediatek,mmsys = <>;
> +}

So this node doesn't correspond to an IP core but is meant as a top-level 
entry point for the operating system. This leads me to three questions.

1. Is there any IP core in the Mediatek display subsystem that could be 
considered (or at least used) as a top-level entry point ? That would be my 
preferred solution as I'm not fond of DT nodes not describing hardware.

2. If there's no such IP core, are all the display subsystem IP cores grouped 
together in one MMIO register range ? If so we could move them as children of 
this new display system node which, even if doesn't describe an IP core, would 
describe the way the display IP cores are grouped in the hardware, and would 
thus be a hardware description.

3. If the answer to the second question is also negative, shouldn't this 
display system node reference all other display IP DT nodes (through direct 
phandles and/or OF graph bindings) ?

>  ovl0: ovl@1400c000 {
>   compatible = "mediatek,mt8173-disp-ovl";
>   reg = <0 0x1400c000 0 0x1000>;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 1/6] gpu: host1x: Enable Tegra186 syncpoint protection

[Thierry Reding]

On Thu, Sep 28, 2017 at 03:50:39PM +0300, Mikko Perttunen wrote:
> Since Tegra186 the Host1x hardware allows syncpoints to be assigned to
> specific channels, preventing any other channels from incrementing
> them.
> 
> Enable this feature where available and assign syncpoints to channels
> when submitting a job. Syncpoints are currently never unassigned from
> channels since that would require extra work and is unnecessary with
> the current channel allocation model.
> 
> Signed-off-by: Mikko Perttunen 
> ---
>  drivers/gpu/host1x/dev.h   | 15 +
>  drivers/gpu/host1x/hw/channel_hw.c |  3 +++
>  drivers/gpu/host1x/hw/syncpt_hw.c  | 46 
> ++
>  drivers/gpu/host1x/syncpt.c|  8 +++
>  4 files changed, 72 insertions(+)

Applied all of these, thanks.

Thierry


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

Re: [RFC resend 3/4] arm64: dts: mt8173: Fix drm subsystem

[Philipp Zabel]

On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote:
> DRM subysystem and clock driver shared the same compatible mmsys.
> This stopped does not work, as only the first driver for a compatible
> gets probed. We change the comaptible to the new DRM identifier to fix
> this.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index b99a27372965..89db0a3f5950 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -803,6 +803,11 @@
>   #clock-cells = <1>;
>   };
>  
> + dispsys: display-system {
> + compatible = "mediatek,mt2701-dispsys";

Same comment as for patch 1, I'd prefer the node to be called
"display-
subsystem" instead.

With that changed,
Acked-by: Philipp Zabel 

> + mediatek,mmsys = <>;
> + }
> +
>   mdp_rdma0: rdma@14001000 {
>   compatible = "mediatek,mt8173-mdp-rdma",
>"mediatek,mt8173-mdp";

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

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

[Philipp Zabel]

Hi Matthias,

On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote:
> DRM subysystem and clock driver shared the same compatible mmsys.
> This stopped does not work, as only the first driver for a compatible
> gets probed. We change the comaptible to the new DRM identifier to fix
> this.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,disp.txt  | 6 
> ++
>  1 file changed, 6 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index 383183a89164..6db652463e64 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -27,6 +27,7 @@ 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
>  
>  Required properties (all function blocks):
>  - compatible: "mediatek,-disp-", one of
> + "mediatek,-dispsys"- central component for the DRM system
>   "mediatek,-disp-ovl"   - overlay (4 layers, blending, csc)
>   "mediatek,-disp-rdma"  - read DMA / line buffer
>   "mediatek,-disp-wdma"  - write DMA
> @@ -71,6 +72,11 @@ mmsys: clock-controller@1400 {
>   #clock-cells = <1>;
>  };
>  
> +dispsys: display-system {

Could we call this node display-subsystem for consistency with i.MX and
Rockchip device trees?

With that change,
Acked-by: Philipp Zabel 

> + compatible = "mediatek,mt2701-dispsys";
> + mediatek,mmsys = <>;
> +}
> +
>  ovl0: ovl@1400c000 {
>   compatible = "mediatek,mt8173-disp-ovl";
>   reg = <0 0x1400c000 0 0x1000>;

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

Re: [PATCH] drm: Hold idr_mutex for _drm_lease_revoke

[Chris Wilson]

Quoting Chris Wilson (2017-10-19 11:53:44)
> _drm_lease_revoke() requires it callers to hold the idr_mutex, but its
> only caller did not. Every device release would then trigger:
> 
>  WARNING: CPU: 7 PID: 4169 at drivers/gpu/drm/drm_lease.c:313 
> _drm_lease_revoke+0x12c/0x140
>  Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_generic i915 
> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
> snd_hda_intel ghash_clmulni_intel snd_hda_codec r8169 snd_hwdep mii 
> snd_hda_core snd_pcm mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint 
> pinctrl_intel
>  CPU: 7 PID: 4169 Comm: pm_backlight Tainted: G U  W   
> 4.14.0-rc5-CI-CI_DRM_3262+ #1
>  Hardware name: TOSHIBA SATELLITE P50-C/06F4, 
> BIOS 1.40 03/29/2016
>  task: 8801f5a2a880 task.stack: c97e4000
>  RIP: 0010:_drm_lease_revoke+0x12c/0x140
>  RSP: 0018:c97e7da8 EFLAGS: 00010246
>  RAX:  RBX: 8801decdafd8 RCX: 0001
>  RDX:  RSI:  RDI: 88026afc05d0
>  RBP: c97e7dd0 R08: 8801f5a2b168 R09: 
>  R10: c97e7dd0 R11: 0001 R12: 88026afc
>  R13: 8802730609f8 R14: 8802730609f8 R15: dead0100
>  FS:  7f9848442a40() GS:880281dc() knlGS:
>  CS:  0010 DS:  ES:  CR0: 80050033
>  CR2: 7f9459c9ff80 CR3: 0001df36e003 CR4: 003606e0
>  DR0:  DR1:  DR2: 
>  DR3:  DR6: fffe0ff0 DR7: 0400
>  Call Trace:
>   drm_master_release+0xa5/0x120
>   drm_release+0x345/0x3c0
>   __fput+0xb9/0x200
>   fput+0xe/0x10
>   task_work_run+0x89/0xc0
>   exit_to_usermode_loop+0x83/0x90
>   syscall_return_slowpath+0xd0/0x110
>   entry_SYSCALL_64_fastpath+0xaf/0xb1
>  RIP: 0033:0x7f984691b730
>  RSP: 002b:7fffdf0092e8 EFLAGS: 0246 ORIG_RAX: 0003
>  RAX:  RBX: 7fffdf0093a0 RCX: 7f984691b730
>  RDX: 7fffdf0092d0 RSI: 40086409 RDI: 0003
>  RBP:  R08: 557b2a88c7c0 R09: 0001
>  R10: 0069 R11: 0246 R12: 
>  R13: 0002 R14: 0001 R15: 557b2a88c4e0
>  Code: 00 00 49 81 ec f8 00 00 00 e9 20 ff ff ff 48 8b 47 08 be ff ff ff ff 
> 48 8d b8 d0 05 00 00 e8 cc 07 ad ff 85 c0 0f 85 f9 fe ff ff <0f> ff e9 f2 fe 
> ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 0f

Insufficient, as we now get

[  214.187528] INFO: trying to register non-static key.
[  214.192480] the code is fine but needs lockdep annotation.
[  214.197942] turning off the locking correctness validator.
[  214.203407] CPU: 1 PID: 3139 Comm: gem_ringfill Tainted: G U  
4.14.0-rc5-CI-Trybot_1284+ #1
[  214.212768] Hardware name: Dell Inc. OptiPlex 755 /0PU052, 
BIOS A08 02/19/2008
[  214.221347] Call Trace:
[  214.223785]  dump_stack+0x68/0x9f
[  214.227087]  register_lock_class+0x3fd/0x580
[  214.231339]  ? __lock_acquire+0x4ab/0x1b00
[  214.235419]  ? __lock_acquire+0x4ab/0x1b00
[  214.239499]  __lock_acquire+0xa4/0x1b00
[  214.243320]  ? drm_lease_revoke+0x29/0x160
[  214.247401]  ? __this_cpu_preempt_check+0x13/0x20
[  214.252087]  ? trace_hardirqs_on_caller+0xe3/0x1b0
[  214.256857]  lock_acquire+0xb0/0x200
[  214.260416]  ? lock_acquire+0xb0/0x200
[  214.264148]  ? drm_lease_revoke+0x29/0x160
[  214.268229]  __mutex_lock+0x86/0x9b0
[  214.271787]  ? drm_lease_revoke+0x29/0x160
[  214.275867]  ? drm_lease_revoke+0x29/0x160
[  214.279947]  ? __mutex_lock+0x437/0x9b0
[  214.283767]  ? __call_rcu.constprop.51+0x122/0x260
[  214.288538]  ? drm_master_release+0x33/0x120
[  214.292789]  ? __this_cpu_preempt_check+0x13/0x20
[  214.297475]  ? trace_hardirqs_on_caller+0xe3/0x1b0
[  214.302245]  ? trace_hardirqs_on+0xd/0x10
[  214.306239]  mutex_lock_nested+0x1b/0x20
[  214.310145]  ? mutex_lock_nested+0x1b/0x20
[  214.314226]  drm_lease_revoke+0x29/0x160
[  214.318132]  drm_master_release+0xa5/0x120
[  214.322212]  drm_release+0x345/0x3c0
[  214.325772]  __fput+0xb9/0x200
[  214.328811]  fput+0xe/0x10
[  214.331853]  task_work_run+0x89/0xc0
[  214.335413]  exit_to_usermode_loop+0x83/0x90
[  214.339664]  syscall_return_slowpath+0xd0/0x110
[  214.344177]  entry_SYSCALL_64_fastpath+0xaf/0xb1
[  214.348776] RIP: 0033:0x7f5239e75730
[  214.352334] RSP: 002b:7fff06432538 EFLAGS: 0246 ORIG_RAX: 
0003
[  214.359876] RAX:  RBX: 0cbe RCX: 7f5239e75730
[  214.366986] RDX: 7fff06432510 RSI: 40086442 RDI: 0005
[  214.374094] RBP: 0003 R08:  R09: 
[  214.381204] R10: 0008 R11: 0246 R12: 0cbe
[  214.388312] R13: 0005 R14: 0001 R15: 

i.e. not every drm device has mode_config. Something like
diff 

[PATCH resend v3 3/3] drm/i915: Call uncore_suspend before platform suspend handlers

[Hans de Goede]

Quoting Ville: "the forcewake timer might still be active until the uncore
suspend, and having active forcewakes while we've already told the GT wake
stuff to stop acting normally doesn't seem quite right to me."

Reported-by: Ville Syrjälä 
Suggested-by: Imre Deak 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Add Imre's Reviewed-by
---
 drivers/gpu/drm/i915/i915_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 34191028bbad..0871eb801bde 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2523,6 +2523,8 @@ static int intel_runtime_suspend(struct device *kdev)
 
intel_runtime_pm_disable_interrupts(dev_priv);
 
+   intel_uncore_suspend(dev_priv);
+
ret = 0;
if (IS_GEN9_LP(dev_priv)) {
bxt_display_core_uninit(dev_priv);
@@ -2535,6 +2537,8 @@ static int intel_runtime_suspend(struct device *kdev)
 
if (ret) {
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
+   intel_uncore_runtime_resume(dev_priv);
+
intel_runtime_pm_enable_interrupts(dev_priv);
 
enable_rpm_wakeref_asserts(dev_priv);
@@ -2542,8 +2546,6 @@ static int intel_runtime_suspend(struct device *kdev)
return ret;
}
 
-   intel_uncore_suspend(dev_priv);
-
enable_rpm_wakeref_asserts(dev_priv);
WARN_ON_ONCE(atomic_read(_priv->runtime_pm.wakeref_count));
 
-- 
2.14.2

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

[PATCH v5 2/2] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

[Hans de Goede]

intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.

Normally this is taken care of by the i915_pmic_bus_access_notifier()
which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other
driver tries to access the PMIC bus, so that later forcewake gets are
no-ops (for the duration of the bus access).

But intel_uncore_forcewake_reset gets called in 3 cases:
1) Before registering the pmic_bus_access_notifier
2) After unregistering the pmic_bus_access_notifier
3) To reset forcewake state on a GPU reset

In all 3 cases the i915_pmic_bus_access_notifier() protection is
insufficient.

This commit fixes this race by calling iosf_mbi_punit_acquire() before
calling intel_uncore_forcewake_reset(). In the case where it is called
directly after unregistering the pmic_bus_access_notifier, we need to
hold the punit-lock over both calls to avoid a race where
intel_uncore_fw_release_timer() may execute between the 2 calls.

Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Keep punit acquired / locked over the unregister + forcewake_reset
 call combo to avoid a race hitting between the 2 calls
-This requires modifying iosf_mbi_unregister_pmic_bus_access_notifier
 to not take the lock itself, since we are the only users this is done
 in this same commit

Changes in v4:
-Fix missing rename in doc-comment
-Add and use iosf_mbi_assert_punit_acquired() helper
-Add missing acquire surrounding intel_uncore_forcewake_reset() inside
 intel_uncore_check_forcewake_domains()
-Add Imre's Reviewed-by

Changes in v5:
-Separate out arch/x86 iosf_mbi changes into a separate patch
---
 drivers/gpu/drm/i915/intel_uncore.c   | 17 +
 drivers/gpu/drm/i915/selftests/intel_uncore.c |  3 +++
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8c2ce81f01c2..0da81faf3981 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -229,6 +229,7 @@ intel_uncore_fw_release_timer(struct hrtimer *timer)
return HRTIMER_NORESTART;
 }
 
+/* Note callers must have acquired the PUNIT->PMIC bus, before calling this. */
 static void intel_uncore_forcewake_reset(struct drm_i915_private *dev_priv,
 bool restore)
 {
@@ -237,6 +238,8 @@ static void intel_uncore_forcewake_reset(struct 
drm_i915_private *dev_priv,
int retry_count = 100;
enum forcewake_domains fw, active_domains;
 
+   iosf_mbi_assert_punit_acquired();
+
/* Hold uncore.lock across reset to prevent any register access
 * with forcewake not set correctly. Wait until all pending
 * timers are run before holding.
@@ -416,14 +419,18 @@ static void __intel_uncore_early_sanitize(struct 
drm_i915_private *dev_priv,
   GT_FIFO_CTL_RC6_POLICY_STALL);
}
 
+   iosf_mbi_punit_acquire();
intel_uncore_forcewake_reset(dev_priv, restore_forcewake);
+   iosf_mbi_punit_release();
 }
 
 void intel_uncore_suspend(struct drm_i915_private *dev_priv)
 {
-   iosf_mbi_unregister_pmic_bus_access_notifier(
+   iosf_mbi_punit_acquire();
+   iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
_priv->uncore.pmic_bus_access_nb);
intel_uncore_forcewake_reset(dev_priv, false);
+   iosf_mbi_punit_release();
 }
 
 void intel_uncore_resume_early(struct drm_i915_private *dev_priv)
@@ -1315,12 +1322,14 @@ void intel_uncore_init(struct drm_i915_private 
*dev_priv)
 
 void intel_uncore_fini(struct drm_i915_private *dev_priv)
 {
-   iosf_mbi_unregister_pmic_bus_access_notifier(
-   _priv->uncore.pmic_bus_access_nb);
-
/* Paranoia: make sure we have disabled everything before we exit. */
intel_uncore_sanitize(dev_priv);
+
+   iosf_mbi_punit_acquire();
+   iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   _priv->uncore.pmic_bus_access_nb);
intel_uncore_forcewake_reset(dev_priv, false);
+   iosf_mbi_punit_release();
 }
 
 static const struct reg_whitelist {
diff --git a/drivers/gpu/drm/i915/selftests/intel_uncore.c 
b/drivers/gpu/drm/i915/selftests/intel_uncore.c
index 3cac22eb47ce..733d87fe7737 100644
--- a/drivers/gpu/drm/i915/selftests/intel_uncore.c
+++ b/drivers/gpu/drm/i915/selftests/intel_uncore.c
@@ -148,7 +148,10 @@ static int intel_uncore_check_forcewake_domains(struct 
drm_i915_private *dev_pri
for_each_set_bit(offset, valid, FW_RANGE) {
i915_reg_t reg = { offset };
 
+   iosf_mbi_punit_acquire();
intel_uncore_forcewake_reset(dev_priv, false);
+   

[PATCH resend v3 0/3] drm/i915: Misc. PMIC bus access notifier fixes

[Hans de Goede]

Hi All,

Here is a resend of the first 3 of the 4 patches in my Misc. PMIC bus
access notifier fixes series. I'm leaving out the 4th patch this time,
because that includes some changes to the iosf_mbi code under arch/x86
and that has been blocking this series from getting upstream sofar.

I will send out a new version of the 4th patch with the iosf_mbi changes
split out seperately.

Regards,

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

[PATCH v5 1/2] x86 / i915 iosf_mbi / PMIC bus access fixes

[Hans de Goede]

Hi All,

Here is a split-up version of my "drm/i915: Acquire PUNIT->PMIC bus for
intel_uncore_forcewake_reset()" patch, this time with the
arch/x86/platform/intel/iosf_mbi.c split out into a separate patch.

Since the iosf_mbi changes are fairly isolated, ideally this entire
series would go upstream through the drm tree. X86 maintainers, can
we have an ack for that from one of you please ?

Regards,

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

[RFC resend 3/4] arm64: dts: mt8173: Fix drm subsystem

[Matthias Brugger]

DRM subysystem and clock driver shared the same compatible mmsys.
This stopped does not work, as only the first driver for a compatible
gets probed. We change the comaptible to the new DRM identifier to fix
this.

Signed-off-by: Matthias Brugger 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index b99a27372965..89db0a3f5950 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -803,6 +803,11 @@
#clock-cells = <1>;
};
 
+   dispsys: display-system {
+   compatible = "mediatek,mt2701-dispsys";
+   mediatek,mmsys = <>;
+   }
+
mdp_rdma0: rdma@14001000 {
compatible = "mediatek,mt8173-mdp-rdma",
 "mediatek,mt8173-mdp";
-- 
2.14.2

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

[RFC resend 4/4] arm: dts: mt2701: Fix drm subsystem

[Matthias Brugger]

DRM subysystem and clock driver shared the same compatible mmsys.
This stopped does not work, as only the first driver for a compatible
gets probed. We change the comaptible to the new DRM identifier to fix
this.

Signed-off-by: Matthias Brugger 
---
 arch/arm/boot/dts/mt2701.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index afe12e5b51f9..1168ad69bb4e 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -530,6 +530,11 @@
#clock-cells = <1>;
};
 
+   dispsys: display-system {
+   compatible = "mediatek,mt2701-dispsys";
+   mediatek,mmsys = <>;
+   }
+
larb0: larb@1401 {
compatible = "mediatek,mt2701-smi-larb";
reg = <0 0x1401 0 0x1000>;
-- 
2.14.2

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

[RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

[Matthias Brugger]

DRM subysystem and clock driver shared the same compatible mmsys.
This stopped does not work, as only the first driver for a compatible
gets probed. We change the comaptible to the new DRM identifier to fix
this.

Signed-off-by: Matthias Brugger 
---
 .../devicetree/bindings/display/mediatek/mediatek,disp.txt  | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 383183a89164..6db652463e64 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -27,6 +27,7 @@ 
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
 
 Required properties (all function blocks):
 - compatible: "mediatek,-disp-", one of
+   "mediatek,-dispsys"- central component for the DRM system
"mediatek,-disp-ovl"   - overlay (4 layers, blending, csc)
"mediatek,-disp-rdma"  - read DMA / line buffer
"mediatek,-disp-wdma"  - write DMA
@@ -71,6 +72,11 @@ mmsys: clock-controller@1400 {
#clock-cells = <1>;
 };
 
+dispsys: display-system {
+   compatible = "mediatek,mt2701-dispsys";
+   mediatek,mmsys = <>;
+}
+
 ovl0: ovl@1400c000 {
compatible = "mediatek,mt8173-disp-ovl";
reg = <0 0x1400c000 0 0x1000>;
-- 
2.14.2

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

[RFC resend 2/4] drm/mediatek: Add new compatible to probe multimedia subsystem.

[Matthias Brugger]

The mmsys block is an independent block that probes the
clock driver. The multimedia subsystem therefore does not get
probed. We add a new compatible for the multimedia subsystem.

We pass the mmsys registers via syscon and access them using regmap
instead of relaxed read/write.

Signed-off-by: Matthias Brugger 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 30 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 17 ++---
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  2 +-
 5 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 658b8dd45b83..4c65873b4867 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -33,7 +33,7 @@
  * @enabled: records whether crtc_enable succeeded
  * @planes: array of 4 drm_plane structures, one for each overlay plane
  * @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @config_regs: regmap mapped mmsys configuration register space
  * @mutex: handle to one of the ten disp_mutex streams
  * @ddp_comp_nr: number of components in ddp_comp
  * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -48,7 +48,7 @@ struct mtk_drm_crtc {
struct drm_planeplanes[OVL_LAYER_NR];
boolpending_planes;
 
-   void __iomem*config_regs;
+   struct regmap   *config_regs;
struct mtk_disp_mutex   *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..1227d6db07da 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -185,16 +185,16 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
cur,
return value;
 }
 
-static void mtk_ddp_sout_sel(void __iomem *config_regs,
+static void mtk_ddp_sout_sel(struct regmap *config_regs,
 enum mtk_ddp_comp_id cur,
 enum mtk_ddp_comp_id next)
 {
if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
-   writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
-  config_regs + DISP_REG_CONFIG_OUT_SEL);
+   regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
+   BLS_TO_DSI_RDMA1_TO_DPI1);
 }
 
-void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
+void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
  enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next)
 {
@@ -202,20 +202,22 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
 
value = mtk_ddp_mout_en(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
+   regmap_read(config_regs, addr, );
+   reg |= value;
+   regmap_write(config_regs, addr, reg);
}
 
mtk_ddp_sout_sel(config_regs, cur, next);
 
value = mtk_ddp_sel_in(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
+   regmap_read(config_regs, addr, );
+   reg |= value;
+   regmap_write(config_regs, addr, reg);
}
 }
 
-void mtk_ddp_remove_comp_from_path(void __iomem *config_regs,
+void mtk_ddp_remove_comp_from_path(struct regmap *config_regs,
   enum mtk_ddp_comp_id cur,
   enum mtk_ddp_comp_id next)
 {
@@ -223,14 +225,16 @@ void mtk_ddp_remove_comp_from_path(void __iomem 
*config_regs,
 
value = mtk_ddp_mout_en(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
+   regmap_read(config_regs, addr, );
+   reg &= ~value;
+   regmap_write(config_regs, addr, reg);
}
 
value = mtk_ddp_sel_in(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
+   regmap_read(config_regs, addr, );
+   reg &= ~value;
+   regmap_write(config_regs, addr, reg);
}
 }
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
index f9a799168077..32e12f33b76a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
+++ 

[PATCH resend v3 2/3] drm/i915: Re-register PMIC bus access notifier on runtime resume

[Hans de Goede]

intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.

intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.

Cc: sta...@vger.kernel.org
Reported-by: Imre Deak 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Add Imre's Reviewed-by
---
 drivers/gpu/drm/i915/i915_drv.c | 2 ++
 drivers/gpu/drm/i915/intel_uncore.c | 6 ++
 drivers/gpu/drm/i915/intel_uncore.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3db5851756f0..34191028bbad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2618,6 +2618,8 @@ static int intel_runtime_resume(struct device *kdev)
ret = vlv_resume_prepare(dev_priv, true);
}
 
+   intel_uncore_runtime_resume(dev_priv);
+
/*
 * No point of rolling back things in case of an error, as the best
 * we can do is to hope that things will still work (and disable RPM).
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index cb48c8b92aa3..8c2ce81f01c2 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -434,6 +434,12 @@ void intel_uncore_resume_early(struct drm_i915_private 
*dev_priv)
i915_check_and_clear_faults(dev_priv);
 }
 
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv)
+{
+   iosf_mbi_register_pmic_bus_access_notifier(
+   _priv->uncore.pmic_bus_access_nb);
+}
+
 void intel_uncore_sanitize(struct drm_i915_private *dev_priv)
 {
i915_modparams.enable_rc6 =
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index 582771251b57..9ce079b5dd0d 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -134,6 +134,7 @@ bool intel_uncore_arm_unclaimed_mmio_detection(struct 
drm_i915_private *dev_priv
 void intel_uncore_fini(struct drm_i915_private *dev_priv);
 void intel_uncore_suspend(struct drm_i915_private *dev_priv);
 void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv);
 
 u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
 void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
-- 
2.14.2

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

[PATCH resend v3 1/3] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

[Hans de Goede]

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:

intel_runtime_pm_put does:

   atomic_dec(_priv->pm.wakeref_count);

   pm_runtime_mark_last_busy(kdev);
   pm_runtime_put_autosuspend(kdev);

And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).

This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.

Cc: sta...@vger.kernel.org
Reported-by: FKr 
Signed-off-by: Hans de Goede 
Reviewed-by: Imre Deak 
---
Changes in v2:
-Rebase on current (July 6th 2017) drm-next

Changes in v3:
-Reword comment explaining why disabling the wakeref asserts is
 ok and necessary
-Add Imre's Reviewed-by
---
 drivers/gpu/drm/i915/intel_uncore.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 20e3c65c0999..cb48c8b92aa3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1240,8 +1240,15 @@ static int i915_pmic_bus_access_notifier(struct 
notifier_block *nb,
 * bus, which will be busy after this notification, leading to:
 * "render: timed out waiting for forcewake ack request."
 * errors.
+*
+* The notifier is unregistered during intel_runtime_suspend(),
+* so it's ok to access the HW here without holding a RPM
+* wake reference -> disable wakeref asserts for the time of
+* the access.
 */
+   disable_rpm_wakeref_asserts(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+   enable_rpm_wakeref_asserts(dev_priv);
break;
case MBI_PMIC_BUS_ACCESS_END:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
-- 
2.14.2

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

Re: [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding

[Ryder Lee]

Hi Matthias,

Should I base on your changes and resend this patch series
https://patchwork.kernel.org/patch/9980061/ ?

I add a similar node - display_components, but your approach is better
than mine.

Thanks.

On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote:
> DRM subysystem and clock driver shared the same compatible mmsys.
> This stopped does not work, as only the first driver for a compatible
> gets probed. We change the comaptible to the new DRM identifier to fix
> this.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,disp.txt  | 6 
> ++
>  1 file changed, 6 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index 383183a89164..6db652463e64 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -27,6 +27,7 @@ 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
>  
>  Required properties (all function blocks):
>  - compatible: "mediatek,-disp-", one of
> + "mediatek,-dispsys"- central component for the DRM system
>   "mediatek,-disp-ovl"   - overlay (4 layers, blending, csc)
>   "mediatek,-disp-rdma"  - read DMA / line buffer
>   "mediatek,-disp-wdma"  - write DMA
> @@ -71,6 +72,11 @@ mmsys: clock-controller@1400 {
>   #clock-cells = <1>;
>  };
>  
> +dispsys: display-system {
> + compatible = "mediatek,mt2701-dispsys";
> + mediatek,mmsys = <>;
> +}
> +
>  ovl0: ovl@1400c000 {
>   compatible = "mediatek,mt8173-disp-ovl";
>   reg = <0 0x1400c000 0 0x1000>;


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

[RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem

[Matthias Brugger]

In theory the MMSYS device tree identifier is matches twice, by the clk driver 
and the DRM subsystem. But the kernel only matches the first driver for a 
device (clk) and discards the second one. This breaks graphics on mt8173 and 
most probably on mt2701 as well.

MMSYS in Mediatek SoCs has some registers to control clock gates (which is 
used in the clk driver) and some registers to enable the differnet blocks of 
the display subsystem. The kernel uses the binding to load the central 
comoponent of the distplay subsystem, which in place probes all the other 
components and enables the present ones in the MMSYS.

We found us with the problem, that we need to change and therefor break one 
of the two bindings, or the DRM one or the clock driver one.

Apart from that the DRM subysystem does access the MMSYS registers via relaxed 
reads/writes. But the it should to so via regmap, as the registers are shared.

Possible solutions:
1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a simple-mfd 
under the actual mmsys node. We change the clock driver to probe on this 
binding. This would make sense as the clock gate register live completly in 
the MMSYS configuration registers.

2) As the nodes of the DRM subsystem just need some of the registers of MMSYS 
we add a new binding mediatek,mt8173-dispsys which probes the central 
component of the DRM system. It has only a handle to mt8173-mmsys to access 
the registerspace via regmap functions.

In this patchset I implemented 2). Please take into account, that this is a 
RFC. I had no time to actually test the verison on real HW. Some of the 
register accesses should be done using regmap_update instead of 
regmap_read + regmap_write.

This RFC shall only show how solution 2) would look like. We can use it as 
discussion to see how we circumvent the actual situation.

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

[PATCH v5 1/2] x86/platform/intel/iosf_mbi: Add unlocked PMIC bus access notifier unregister

[Hans de Goede]

For race free unregistration drivers may need to acquire PMIC bus access
through iosf_mbi_punit_acquire() and then (un)register the notifier without
dropping the lock.

This commit adds an unlocked variant of
iosf_mbi_unregister_pmic_bus_access_notifier for this use case.

Signed-off-by: Hans de Goede 
---
 arch/x86/include/asm/iosf_mbi.h| 25 +
 arch/x86/platform/intel/iosf_mbi.c | 19 +--
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index c313cac36f56..eb959cd77994 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -145,6 +145,18 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb);
  */
 int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb);
 
+/**
+ * iosf_mbi_unregister_pmic_bus_access_notifier_unlocked - Unregister PMIC bus
+ * notifier, unlocked
+ *
+ * Like iosf_mbi_unregister_pmic_bus_access_notifier(), but for use when the
+ * caller has already called iosf_mbi_punit_acquire() itself.
+ *
+ * @nb: notifier_block to unregister
+ */
+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb);
+
 /**
  * iosf_mbi_call_pmic_bus_access_notifier_chain - Call PMIC bus notifier chain
  *
@@ -153,6 +165,11 @@ int iosf_mbi_unregister_pmic_bus_access_notifier(struct 
notifier_block *nb);
  */
 int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v);
 
+/**
+ * iosf_mbi_assert_punit_acquired - Assert that the P-Unit has been acquired.
+ */
+void iosf_mbi_assert_punit_acquired(void);
+
 #else /* CONFIG_IOSF_MBI is not enabled */
 static inline
 bool iosf_mbi_available(void)
@@ -196,12 +213,20 @@ int iosf_mbi_unregister_pmic_bus_access_notifier(struct 
notifier_block *nb)
return 0;
 }
 
+static inline int
+iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(struct notifier_block 
*nb)
+{
+   return 0;
+}
+
 static inline
 int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v)
 {
return 0;
 }
 
+static inline void iosf_mbi_assert_punit_acquired(void) {}
+
 #endif /* CONFIG_IOSF_MBI */
 
 #endif /* IOSF_MBI_SYMS_H */
diff --git a/arch/x86/platform/intel/iosf_mbi.c 
b/arch/x86/platform/intel/iosf_mbi.c
index a952ac199741..6f37a2137a79 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -218,14 +218,23 @@ int iosf_mbi_register_pmic_bus_access_notifier(struct 
notifier_block *nb)
 }
 EXPORT_SYMBOL(iosf_mbi_register_pmic_bus_access_notifier);
 
+int iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
+   struct notifier_block *nb)
+{
+   iosf_mbi_assert_punit_acquired();
+
+   return blocking_notifier_chain_unregister(
+   _mbi_pmic_bus_access_notifier, nb);
+}
+EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier_unlocked);
+
 int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
 {
int ret;
 
/* Wait for the bus to go inactive before unregistering */
mutex_lock(_mbi_punit_mutex);
-   ret = blocking_notifier_chain_unregister(
-   _mbi_pmic_bus_access_notifier, nb);
+   ret = iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(nb);
mutex_unlock(_mbi_punit_mutex);
 
return ret;
@@ -239,6 +248,12 @@ int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned 
long val, void *v)
 }
 EXPORT_SYMBOL(iosf_mbi_call_pmic_bus_access_notifier_chain);
 
+void iosf_mbi_assert_punit_acquired(void)
+{
+   WARN_ON(!mutex_is_locked(_mbi_punit_mutex));
+}
+EXPORT_SYMBOL(iosf_mbi_assert_punit_acquired);
+
 #ifdef CONFIG_IOSF_MBI_DEBUG
 static u32 dbg_mdr;
 static u32 dbg_mcr;
-- 
2.14.2

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

Re: [PATCH v3 0/6] Miscellaneous improvements to Host1x and TegraDRM

[Thierry Reding]

On Thu, Sep 28, 2017 at 03:50:38PM +0300, Mikko Perttunen wrote:
> New in v3:
> - Renamed *syncpt_assign_channel to *syncpt_assign_to_channel
> - Disassembler ignores opcodes not supported on the particular
>   chip
> - Further cleanup in u64_to_user_ptr patch
> 
> New in v2:
> - Changes in syncpoint protection and u64_to_user_ptr patches.
>   See the patches for notes.
> - Added patch to support more opcodes in the debug dump
>   disassembly.
> - Added patch to fix an incorrect comment.
> 
> Thanks,
> Mikko
> 
> Patch v1 notes:
> 
> Hi all,
> 
> here are some new features and improvements.
> 
> Patch 1 enables syncpoint protection which prevents channels from
> touching syncpoints not belonging to them on Tegra186.
> 
> Patch 2 enables the gather filter which prevents userspace command
> buffers from using CDMA commands usually reserved for the kernel.
> A test is available at git://github.com/cyndis/host1x_test, branch
> gather-filter.
> 
> Patch 3 greatly improves formatting of debug dumps spewed by host1x
> in case of job timeouts. They are now actually readable by humans
> without use of additional scripts.
> 
> Patch 4 is a simple aesthetical fix to the TegraDRM submit path.
> 
> Everything was tested on TX1 and TX2 and should be applied on the
> previously posted Tegra186 support series.
> 
> Cheers,
> Mikko
> 
> 
> Mikko Perttunen (6):
>   gpu: host1x: Enable Tegra186 syncpoint protection
>   gpu: host1x: Enable gather filter
>   gpu: host1x: Improve debug disassembly formatting
>   gpu: host1x: Disassemble more instructions
>   gpu: host1x: Fix incorrect comment for channel_request
>   drm/tegra: Use u64_to_user_ptr helper
> 
>  drivers/gpu/drm/tegra/drm.c |  29 
>  drivers/gpu/host1x/channel.c|   3 +-
>  drivers/gpu/host1x/debug.c  |  14 +++-
>  drivers/gpu/host1x/debug.h  |  14 ++--
>  drivers/gpu/host1x/dev.h|  15 
>  drivers/gpu/host1x/hw/channel_hw.c  |  25 +++
>  drivers/gpu/host1x/hw/debug_hw.c| 103 
> ++--
>  drivers/gpu/host1x/hw/debug_hw_1x01.c   |  10 +--
>  drivers/gpu/host1x/hw/debug_hw_1x06.c   |  12 ++--
>  drivers/gpu/host1x/hw/hw_host1x04_channel.h |  12 
>  drivers/gpu/host1x/hw/hw_host1x05_channel.h |  12 
>  drivers/gpu/host1x/hw/syncpt_hw.c   |  46 +
>  drivers/gpu/host1x/syncpt.c |   8 +++
>  13 files changed, 252 insertions(+), 51 deletions(-)

Applied, thanks.

Thierry


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

Re: [PATCH v2 5/6] gpu: host1x: Add Tegra186 support

[Thierry Reding]

On Tue, Sep 05, 2017 at 11:43:05AM +0300, Mikko Perttunen wrote:
> Add support for the implementation of Host1x present on the Tegra186.
> The register space has been shuffled around a little bit, requiring
> addition of some chip-specific code sections. Tegra186 also adds
> several new features, most importantly the hypervisor, but those are
> not yet supported with this commit.
> 
> Signed-off-by: Mikko Perttunen 
> Reviewed-by: Dmitry Osipenko 
> Tested-by: Dmitry Osipenko 
> ---
>  drivers/gpu/host1x/Makefile|   3 +-
>  drivers/gpu/host1x/dev.c   |  60 +++-
>  drivers/gpu/host1x/dev.h   |   4 +
>  drivers/gpu/host1x/hw/cdma_hw.c|  49 ---
>  drivers/gpu/host1x/hw/debug_hw.c   | 137 +--
>  drivers/gpu/host1x/hw/debug_hw_1x01.c  | 154 +
>  drivers/gpu/host1x/hw/debug_hw_1x06.c  | 133 ++
>  drivers/gpu/host1x/hw/host1x01.c   |   2 +
>  drivers/gpu/host1x/hw/host1x02.c   |   2 +
>  drivers/gpu/host1x/hw/host1x04.c   |   2 +
>  drivers/gpu/host1x/hw/host1x05.c   |   2 +
>  drivers/gpu/host1x/hw/host1x06.c   |  44 ++
>  drivers/gpu/host1x/hw/host1x06.h   |  26 
>  drivers/gpu/host1x/hw/host1x06_hardware.h  | 142 +++
>  drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h |  32 +
>  drivers/gpu/host1x/hw/hw_host1x06_uclass.h | 181 
> +
>  drivers/gpu/host1x/hw/hw_host1x06_vm.h |  47 +++
>  drivers/gpu/host1x/hw/intr_hw.c|  29 ++--
>  18 files changed, 880 insertions(+), 169 deletions(-)
>  create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x01.c
>  create mode 100644 drivers/gpu/host1x/hw/debug_hw_1x06.c
>  create mode 100644 drivers/gpu/host1x/hw/host1x06.c
>  create mode 100644 drivers/gpu/host1x/hw/host1x06.h
>  create mode 100644 drivers/gpu/host1x/hw/host1x06_hardware.h
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_hypervisor.h
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_uclass.h
>  create mode 100644 drivers/gpu/host1x/hw/hw_host1x06_vm.h

Applied, thanks.

Thierry


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

Re: [PATCH v2 6/6] drm/tegra: Add Tegra186 support for VIC

[Thierry Reding]

On Tue, Sep 05, 2017 at 11:43:06AM +0300, Mikko Perttunen wrote:
> Add Tegra186 support for VIC - no changes are required except for new
> firmware and compatibility string.
> 
> Signed-off-by: Mikko Perttunen 
> ---
>  drivers/gpu/drm/tegra/drm.c |  1 +
>  drivers/gpu/drm/tegra/vic.c | 10 ++
>  2 files changed, 11 insertions(+)

Applied, thanks.

Thierry


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

Re: [PATCH v2 4/6] dt-bindings: host1x: Add Tegra186 information

[Thierry Reding]

On Tue, Sep 05, 2017 at 11:43:04AM +0300, Mikko Perttunen wrote:
> Add the Tegra186-specific hypervisor-related register range
> properties.
> 
> Signed-off-by: Mikko Perttunen 
> ---
> v2:
> - Dropped incorrect note about cells properties.
> 
>  .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt   | 4 
> 
>  1 file changed, 4 insertions(+)

Applied, thanks.

Thierry


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

Re: [Spice-devel] [PATCH] drm/qxl: workaround broken qxl hw primary setting.

[Frediano Ziglio]

> 
> From: Dave Airlie 
> 
> QXL hw can't change primary surfaces easily, the server sends a msg
> and the client flickers a lo when it does. The old pre-atomic
> page flip code endeavoured to workaround this with a copy operation.
> 
> This worked by another accident of how the qxl virtual gpu is designed,
> it does lazy operation evaluation on the host, so this operation
> wouldn't generally trash the memory, and result in correct display.
> 
> This tries to work out when the commit is likely just a pageflip
> and avoid touching the primary surface, this might go wrong at
> some point but I believe it's the same level as wrong as the old code
> base.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index afbf50d..3b702d1 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -502,6 +502,7 @@ static void qxl_primary_atomic_update(struct drm_plane
> *plane,
>   struct qxl_framebuffer *qfb_old;
>   struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
>   struct qxl_bo *bo_old;
> + bool update_primary = true;
>   struct drm_clip_rect norect = {
>   .x1 = 0,
>   .y1 = 0,
> @@ -519,15 +520,31 @@ static void qxl_primary_atomic_update(struct drm_plane
> *plane,
>   if (bo == bo_old)
>   return;
>  
> + if (bo && bo_old &&
> + plane->state->crtc == old_state->crtc &&
> + plane->state->crtc_w == old_state->crtc_w &&
> + plane->state->crtc_h == old_state->crtc_h &&
> + plane->state->src_x == old_state->src_x &&
> + plane->state->src_y == old_state->src_y &&
> + plane->state->src_w == old_state->src_w &&
> + plane->state->src_h == old_state->src_h &&
> + plane->state->rotation == old_state->rotation &&
> + plane->state->zpos == old_state->zpos)
> + /* this is likely a pageflip */
> + update_primary = false;
> +
>   if (bo_old && bo_old->is_primary) {
> - qxl_io_destroy_primary(qdev);
> + if (update_primary)
> + qxl_io_destroy_primary(qdev);
>   bo_old->is_primary = false;
>   }
>  
>   if (!bo->is_primary) {
> - qxl_io_create_primary(qdev, 0, bo);
> + if (update_primary)
> + qxl_io_create_primary(qdev, 0, bo);
>   bo->is_primary = true;

Here the primary is still the old object but you are setting the
new.
Looking around the old is unpinned and the new one pinned which
is now wrong as QXL device suppose the memory pointer by the
primary surface (after your patch bo_old object) remains
available.

>   }
> +
>   qxl_draw_dirty_fb(qdev, qfb, bo, 0, 0, , 1, 1);

I had a look at this function. It send a DRAW_COPY operation
passing the bo object as a Drawable. However does nothing to
keep the object allocated. The Drawable and its buffer (so
bo object) should be available to QXL and not touched (changed)
till a release is received.

>  }
>  

If we are not able to avoid the copy and we need to keep the old
surface in place maybe instead of creating the new object as SURFACE
we could just use for source for the Drawable for the DRAW_COPY operation.
In this way when release is received the object can be unpinned being
free to be moved.

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

[PATCH] drm: Hold idr_mutex for _drm_lease_revoke

[Chris Wilson]

_drm_lease_revoke() requires it callers to hold the idr_mutex, but its
only caller did not. Every device release would then trigger:

 WARNING: CPU: 7 PID: 4169 at drivers/gpu/drm/drm_lease.c:313 
_drm_lease_revoke+0x12c/0x140
 Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_generic i915 
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul 
snd_hda_intel ghash_clmulni_intel snd_hda_codec r8169 snd_hwdep mii 
snd_hda_core snd_pcm mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint 
pinctrl_intel
 CPU: 7 PID: 4169 Comm: pm_backlight Tainted: G U  W   
4.14.0-rc5-CI-CI_DRM_3262+ #1
 Hardware name: TOSHIBA SATELLITE P50-C/06F4, BIOS 
1.40 03/29/2016
 task: 8801f5a2a880 task.stack: c97e4000
 RIP: 0010:_drm_lease_revoke+0x12c/0x140
 RSP: 0018:c97e7da8 EFLAGS: 00010246
 RAX:  RBX: 8801decdafd8 RCX: 0001
 RDX:  RSI:  RDI: 88026afc05d0
 RBP: c97e7dd0 R08: 8801f5a2b168 R09: 
 R10: c97e7dd0 R11: 0001 R12: 88026afc
 R13: 8802730609f8 R14: 8802730609f8 R15: dead0100
 FS:  7f9848442a40() GS:880281dc() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 7f9459c9ff80 CR3: 0001df36e003 CR4: 003606e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: fffe0ff0 DR7: 0400
 Call Trace:
  drm_master_release+0xa5/0x120
  drm_release+0x345/0x3c0
  __fput+0xb9/0x200
  fput+0xe/0x10
  task_work_run+0x89/0xc0
  exit_to_usermode_loop+0x83/0x90
  syscall_return_slowpath+0xd0/0x110
  entry_SYSCALL_64_fastpath+0xaf/0xb1
 RIP: 0033:0x7f984691b730
 RSP: 002b:7fffdf0092e8 EFLAGS: 0246 ORIG_RAX: 0003
 RAX:  RBX: 7fffdf0093a0 RCX: 7f984691b730
 RDX: 7fffdf0092d0 RSI: 40086409 RDI: 0003
 RBP:  R08: 557b2a88c7c0 R09: 0001
 R10: 0069 R11: 0246 R12: 
 R13: 0002 R14: 0001 R15: 557b2a88c4e0
 Code: 00 00 49 81 ec f8 00 00 00 e9 20 ff ff ff 48 8b 47 08 be ff ff ff ff 48 
8d b8 d0 05 00 00 e8 cc 07 ad ff 85 c0 0f 85 f9 fe ff ff <0f> ff e9 f2 fe ff ff 
90 90 90 90 90 90 90 90 90 90 90 90 90 0f

Fixes: 801d74c2fe00 ("drm: Add drm_object lease infrastructure [v5]")
Signed-off-by: Chris Wilson 
Cc: Keith Packard 
Cc: Sean Paul 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/drm_auth.c  |  2 +-
 drivers/gpu/drm/drm_lease.c | 19 +--
 include/drm/drm_lease.h |  2 +-
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index bab26b477738..4c14b2cbc733 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -289,7 +289,7 @@ void drm_master_release(struct drm_file *file_priv)
/* Revoke any leases held by this or lessees, but only if
 * this is the "real" master
 */
-   _drm_lease_revoke(master);
+   drm_lease_revoke(master);
}
 
/* drop the master reference held by the file priv */
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 52c8fa29e6cc..387a6cb4bbe0 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -299,12 +299,7 @@ void drm_lease_destroy(struct drm_master *master)
DRM_DEBUG_LEASE("drm_lease_destroy done %d\n", master->lessee_id);
 }
 
-/**
- * _drm_lease_revoke - revoke access to all leased objects (idr_mutex held)
- * @top: the master losing its lease
- */
-
-void _drm_lease_revoke(struct drm_master *top)
+static void __drm_lease_revoke(struct drm_master *top)
 {
int object;
void *entry;
@@ -340,3 +335,15 @@ void _drm_lease_revoke(struct drm_master *top)
}
}
 }
+
+/**
+ * drm_lease_revoke - revoke access to all leased objects (idr_mutex held)
+ * @top: the master losing its lease
+ */
+
+void drm_lease_revoke(struct drm_master *top)
+{
+   mutex_lock(>dev->mode_config.idr_mutex);
+   __drm_lease_revoke(top);
+   mutex_unlock(>dev->mode_config.idr_mutex);
+}
diff --git a/include/drm/drm_lease.h b/include/drm/drm_lease.h
index 0981631b9aed..6149e56ddbf3 100644
--- a/include/drm/drm_lease.h
+++ b/include/drm/drm_lease.h
@@ -27,7 +27,7 @@ bool drm_lease_held(struct drm_file *file_priv, int id);
 
 bool _drm_lease_held(struct drm_file *file_priv, int id);
 
-void _drm_lease_revoke(struct drm_master *master);
+void drm_lease_revoke(struct drm_master *master);
 
 uint32_t drm_lease_filter_crtcs(struct drm_file *file_priv, uint32_t crtcs);
 
-- 
2.15.0.rc1

___

Re: [PATCH v2 2/6] arm64: tegra: Add host1x on Tegra186

[Thierry Reding]

On Tue, Sep 05, 2017 at 11:43:02AM +0300, Mikko Perttunen wrote:
> Add the node for Host1x on the Tegra186, without any subdevices
> for now.
> 
> Signed-off-by: Mikko Perttunen 
> ---
> v2:
> - Changed address-cells and size-cells to 1 and fixed the ranges
>   property correspondingly.
> 
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi | 18 ++
>  1 file changed, 18 insertions(+)

Applied, thanks.

Thierry


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

Re: [PATCH v2 3/6] arm64: tegra: Add VIC on Tegra186

[Thierry Reding]

On Tue, Sep 05, 2017 at 11:43:03AM +0300, Mikko Perttunen wrote:
> Add a node for the Video Image Compositor on the Tegra186.
> 
> Signed-off-by: Mikko Perttunen 
> ---
> v2:
> - Fixed reg property in accordance with changed parent cells.
> 
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi | 12 
>  1 file changed, 12 insertions(+)

Applied, thanks.

Thierry


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

Re: [PATCH v2 1/6] arm64: tegra: Add #power-domain-cells for BPMP

[Thierry Reding]

On Tue, Sep 05, 2017 at 11:43:01AM +0300, Mikko Perttunen wrote:
> Add #power-domain-cells for the BPMP node on Tegra186 so that the power
> domain provider may be used.
> 
> Signed-off-by: Mikko Perttunen 
> ---
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

Thierry


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

[Bug 101732] TURKS GPU - radeon 0000:01:00.0: failed to get a new IB (-35)

[bugzilla-daemon]

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

Fede  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Fede  ---
I don't have this laptop anymore. It might have been a motherboard issue as the
laptop stopped booting not long after this issue.

-- 
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: [PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

[Thierry Reding]

On Thu, Oct 19, 2017 at 11:36:14AM +0200, Hans Verkuil wrote:
> On 10/19/17 11:20, Thierry Reding wrote:
> > On Mon, Sep 11, 2017 at 02:29:48PM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> This patch series adds support for the Tegra CEC functionality.
> >>
> >> This v4 has been rebased to the latest 4.14 pre-rc1 mainline.
> >>
> >> Please review! Other than for the bindings that are now Acked I have not
> >> received any feedback.
> >>
> >> The first patch documents the CEC bindings, the second adds support
> >> for this to tegra124.dtsi and enables it for the Jetson TK1.
> >>
> >> The third patch adds the CEC driver itself and the final patch adds
> >> the cec notifier support to the drm/tegra driver in order to notify
> >> the CEC driver whenever the physical address changes.
> >>
> >> I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
> >> other Tegra SoCs, but I can only test this with my Jetson TK1 board.
> >>
> >> The dt-bindings and the tegra-cec driver would go in through the media
> >> subsystem, the drm/tegra part through the drm subsystem and the dts
> >> changes through (I guess) the linux-tegra developers. Luckily they are
> >> all independent of one another.
> >>
> >> To test this you need the CEC utilities from 
> >> git://linuxtv.org/v4l-utils.git.
> >>
> >> To build this:
> >>
> >> git clone git://linuxtv.org/v4l-utils.git
> >> cd v4l-utils
> >> ./bootstrap.sh; ./configure
> >> make
> >> sudo make install # optional, you really only need utils/cec*
> >>
> >> To test:
> >>
> >> cec-ctl --playback # configure as playback device
> >> cec-ctl -S # detect all connected CEC devices
> > 
> > I finally got around to test this. Unfortunately I wasn't able to
> > properly show connected CEC devices, but I think that may just be
> > because the monitor I was testing against doesn't support CEC. I
> > will have to check against a different device eventually to check
> > that it properly enumerates, though I suspect you've already done
> > quite extensive testing yourself.
> 
> Yes, you need a TV with CEC. Most (all?) PC monitors do not support this.
> I never understood why not.
> 
> So just to confirm: you've merged this driver for 4.15?

I've applied the drm/tegra bits to drm/tegra/for-next and pulled the ARM
DT changes into the Tegra tree for v4.15. I think we had agreed that you
would take the DT bindings and CEC driver through your tree?

Thierry


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

Re: [PATCHv4 4/4] drm/tegra: add cec-notifier support

[Thierry Reding]

On Mon, Sep 11, 2017 at 02:29:52PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> In order to support CEC the HDMI driver has to inform the CEC driver
> whenever the physical address changes. So when the EDID is read the
> CEC driver has to be informed and whenever the hotplug detect goes
> away.
> 
> This is done through the cec-notifier framework.
> 
> The link between the HDMI driver and the CEC driver is done through
> the hdmi_phandle in the tegra-cec node in the device tree.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/tegra/Kconfig  | 1 +
>  drivers/gpu/drm/tegra/drm.h| 3 +++
>  drivers/gpu/drm/tegra/hdmi.c   | 9 +
>  drivers/gpu/drm/tegra/output.c | 6 ++
>  4 files changed, 19 insertions(+)

I've applied this to drm/tegra/for-next.

Thanks,
Thierry


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

Re: [PATCHv4 3/4] tegra-cec: add Tegra HDMI CEC driver

[Thierry Reding]

On Mon, Sep 11, 2017 at 02:29:51PM +0200, Hans Verkuil wrote:
[...]
> diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c 
> b/drivers/media/platform/tegra-cec/tegra_cec.c
[...]
> +static int tegra_cec_probe(struct platform_device *pdev)
> +{
> + struct platform_device *hdmi_dev;
> + struct device_node *np;
> + struct tegra_cec *cec;
> + struct resource *res;
> + int ret = 0;
> +
> + np = of_parse_phandle(pdev->dev.of_node, "hdmi-phandle", 0);
> +
> + if (!np) {
> + dev_err(>dev, "Failed to find hdmi node in device 
> tree\n");
> + return -ENODEV;
> + }
> + hdmi_dev = of_find_device_by_node(np);
> + if (hdmi_dev == NULL)
> + return -EPROBE_DEFER;

This seems a little awkward. Why exactly do we need to defer probe here?
It seems to me like cec_notifier_get() should be able to deal with HDMI
appearing at a later point.

> +
> + cec = devm_kzalloc(>dev, sizeof(struct tegra_cec), GFP_KERNEL);
> +
> + if (!cec)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + if (!res) {
> + dev_err(>dev,
> + "Unable to allocate resources for device\n");
> + ret = -EBUSY;
> + goto cec_error;
> + }
> +
> + if (!devm_request_mem_region(>dev, res->start, resource_size(res),
> + pdev->name)) {
> + dev_err(>dev,
> + "Unable to request mem region for device\n");
> + ret = -EBUSY;
> + goto cec_error;
> + }
> +
> + cec->tegra_cec_irq = platform_get_irq(pdev, 0);
> +
> + if (cec->tegra_cec_irq <= 0) {
> + ret = -EBUSY;
> + goto cec_error;
> + }
> +
> + cec->cec_base = devm_ioremap_nocache(>dev, res->start,
> + resource_size(res));
> +
> + if (!cec->cec_base) {
> + dev_err(>dev, "Unable to grab IOs for device\n");
> + ret = -EBUSY;
> + goto cec_error;
> + }
> +
> + cec->clk = devm_clk_get(>dev, "cec");
> +
> + if (IS_ERR_OR_NULL(cec->clk)) {
> + dev_err(>dev, "Can't get clock for CEC\n");
> + ret = -ENOENT;
> + goto clk_error;
> + }
> +
> + clk_prepare_enable(cec->clk);
> +
> + /* set context info. */
> + cec->dev = >dev;
> +
> + platform_set_drvdata(pdev, cec);
> +
> + ret = devm_request_threaded_irq(>dev, cec->tegra_cec_irq,
> + tegra_cec_irq_handler, tegra_cec_irq_thread_handler,
> + 0, "cec_irq", >dev);
> +
> + if (ret) {
> + dev_err(>dev,
> + "Unable to request interrupt for device\n");
> + goto cec_error;
> + }
> +
> + cec->notifier = cec_notifier_get(_dev->dev);
> + if (!cec->notifier) {
> + ret = -ENOMEM;
> + goto cec_error;
> + }

Ah... I see why we need the HDMI device right away. This seems a little
brittle to me, for two reasons: what if the HDMI controller goes away?
Will we be hanging on to a stale device? I mean, the device doesn't
necessarily have to go away, but what's the effect on CEC if the driver
unbinds from the HDMI controller?

Secondly, this creates a circular dependency. It seems to me like it'd
actually be simpler if the CEC controller was a "service provider" that
HDMI could use and "request/release" as appropriate.

In that case, the DT would look somewhat like this:

hdmi@... {
cec = <>;
};

cec: cec@... {
...
};

And then the HDMI driver could do something like:

cec = cec_get(>dev);
/* register notifier, ... */

That way the dependency becomes unidirectional and it seems to me like
that would allow interactions between HDMI and CEC would become simpler
overall.

Anyway, this is something that could always be changed after the fact
(except maybe for some bits needed for backwards-compatibility with old
device trees), and this seems to work well enough as it is, so:

Acked-by: Thierry Reding 


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

Re: [PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

[Hans Verkuil]

On 10/19/17 11:20, Thierry Reding wrote:
> On Mon, Sep 11, 2017 at 02:29:48PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch series adds support for the Tegra CEC functionality.
>>
>> This v4 has been rebased to the latest 4.14 pre-rc1 mainline.
>>
>> Please review! Other than for the bindings that are now Acked I have not
>> received any feedback.
>>
>> The first patch documents the CEC bindings, the second adds support
>> for this to tegra124.dtsi and enables it for the Jetson TK1.
>>
>> The third patch adds the CEC driver itself and the final patch adds
>> the cec notifier support to the drm/tegra driver in order to notify
>> the CEC driver whenever the physical address changes.
>>
>> I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
>> other Tegra SoCs, but I can only test this with my Jetson TK1 board.
>>
>> The dt-bindings and the tegra-cec driver would go in through the media
>> subsystem, the drm/tegra part through the drm subsystem and the dts
>> changes through (I guess) the linux-tegra developers. Luckily they are
>> all independent of one another.
>>
>> To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.
>>
>> To build this:
>>
>> git clone git://linuxtv.org/v4l-utils.git
>> cd v4l-utils
>> ./bootstrap.sh; ./configure
>> make
>> sudo make install # optional, you really only need utils/cec*
>>
>> To test:
>>
>> cec-ctl --playback # configure as playback device
>> cec-ctl -S # detect all connected CEC devices
> 
> I finally got around to test this. Unfortunately I wasn't able to
> properly show connected CEC devices, but I think that may just be
> because the monitor I was testing against doesn't support CEC. I
> will have to check against a different device eventually to check
> that it properly enumerates, though I suspect you've already done
> quite extensive testing yourself.

Yes, you need a TV with CEC. Most (all?) PC monitors do not support this.
I never understood why not.

So just to confirm: you've merged this driver for 4.15?

Regards,

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

Re: [linux-next:master 520/6567] warning: (DRM_STM && ..) selects DRM_PANEL_BRIDGE which has unmet direct dependencies (HAS_IOMEM && ..)

[Linus Walleij]

Paging in Arnd on this one, as he builds a lot of next kernels
and randconfigs.

On Wed, Oct 18, 2017 at 12:55 PM, kbuild test robot
 wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
> master
> head:   a7dd40274d75326ca868479c62090b1198a357ad
> commit: 001485d5255cb17e99aa9e3712e43865b92d6adc [520/6567] drm/pl111: 
> Replace custom connector with panel bridge
> config: x86_64-randconfig-ws0-10181652 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> git checkout 001485d5255cb17e99aa9e3712e43865b92d6adc
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
> warning: (DRM_STM && DRM_VC4 && DRM_PL111 && DRM_TVE200 && DRM_LVDS_ENCODER 
> && DRM_DW_MIPI_DSI)
> selects DRM_PANEL_BRIDGE which has unmet direct dependencies (HAS_IOMEM && 
> DRM_BRIDGE && DRM_KMS_HELPER)

I have a real hard time deciphering this Kconfig problem.

Can someone help?

What I see it that DTM_STM, DRM_VC4, DRM_PL111, DRM_TVE200 and
DRM_DW_MIPI_DSI all select DRM_PANEL_BRIDGE and
DRM_KMS_HELPER.

DRM_LVDS_ENCODER select DRM_PANEL_BRIDGE

So they seem to select what they need.

HAS_IOMEM must be the real culprit, and it is not set in the .config
attached.

So is the real problem that the bot is compiling a config without
HAS_IOMEM and we should put a depends on HAS_IOMEM
somewhere?

This HAS_IOMEM business keep annoying me, UML has this
problem a lot since it doesn't have iomem for sure, but this
randconfig wants to build an x86_64 without iomem and is not
pestering us about it.

Is building for x86_64 without iomem really a problem we should
be addressing?

I think there are tons of problems in the kernel related to the
depends on HAS_IOMEM being missing, we can go fixing that
forever I think.

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

Re: [PATCHv4 2/4] ARM: tegra: add CEC support to tegra124.dtsi

[Thierry Reding]

On Mon, Sep 11, 2017 at 02:29:50PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the
> Jetson TK1.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 
>  arch/arm/boot/dts/tegra124.dtsi   | 12 +++-
>  2 files changed, 15 insertions(+), 1 deletion(-)

I prefer SoC and board changes to be split into separate patches. I've
done that with this patch while applying.

Thanks,
Thierry


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

Re: [PATCHv4 1/4] dt-bindings: document the tegra CEC bindings

[Thierry Reding]

On Mon, Sep 11, 2017 at 02:29:49PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This documents the binding for the Tegra CEC module.
> 
> Signed-off-by: Hans Verkuil 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/media/tegra-cec.txt| 27 
> ++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt 
> b/Documentation/devicetree/bindings/media/tegra-cec.txt
> new file mode 100644
> index ..c503f06f3b84
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/tegra-cec.txt
> @@ -0,0 +1,27 @@
> +* Tegra HDMI CEC hardware
> +
> +The HDMI CEC module is present in Tegra SoCs and its purpose is to
> +handle communication between HDMI connected devices over the CEC bus.
> +
> +Required properties:
> +  - compatible : value should be one of the following:
> + "nvidia,tegra114-cec"
> + "nvidia,tegra124-cec"
> + "nvidia,tegra210-cec"
> +  - reg : Physical base address of the IP registers and length of memory
> +   mapped region.
> +  - interrupts : HDMI CEC interrupt number to the CPU.
> +  - clocks : from common clock binding: handle to HDMI CEC clock.
> +  - clock-names : from common clock binding: must contain "cec",
> +   corresponding to the entry in the clocks property.
> +  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.

I don't understand the need for the -phandle suffix. I would've probably
just gone with "hdmi", or "hdmi-controller". But I see that this is
already pretty standardized, so...

Acked-by: Thierry Reding 


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

Re: [PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

[Thierry Reding]

On Mon, Sep 11, 2017 at 02:29:48PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series adds support for the Tegra CEC functionality.
> 
> This v4 has been rebased to the latest 4.14 pre-rc1 mainline.
> 
> Please review! Other than for the bindings that are now Acked I have not
> received any feedback.
> 
> The first patch documents the CEC bindings, the second adds support
> for this to tegra124.dtsi and enables it for the Jetson TK1.
> 
> The third patch adds the CEC driver itself and the final patch adds
> the cec notifier support to the drm/tegra driver in order to notify
> the CEC driver whenever the physical address changes.
> 
> I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
> other Tegra SoCs, but I can only test this with my Jetson TK1 board.
> 
> The dt-bindings and the tegra-cec driver would go in through the media
> subsystem, the drm/tegra part through the drm subsystem and the dts
> changes through (I guess) the linux-tegra developers. Luckily they are
> all independent of one another.
> 
> To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.
> 
> To build this:
> 
> git clone git://linuxtv.org/v4l-utils.git
> cd v4l-utils
> ./bootstrap.sh; ./configure
> make
> sudo make install # optional, you really only need utils/cec*
> 
> To test:
> 
> cec-ctl --playback # configure as playback device
> cec-ctl -S # detect all connected CEC devices

I finally got around to test this. Unfortunately I wasn't able to
properly show connected CEC devices, but I think that may just be
because the monitor I was testing against doesn't support CEC. I
will have to check against a different device eventually to check
that it properly enumerates, though I suspect you've already done
quite extensive testing yourself.

Thanks for doing this!

Thierry


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

[Bug 103317] Tearing in WQHD, but not in FHD

[bugzilla-daemon]

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

--- Comment #4 from Michel Dänzer  ---
(In reply to Torsten Kessler from comment #3)
> As suggested I turned EnablePageFlip off:
[...]
> But this doesn't avoid the problem.

Please attach the corresponding Xorg log file.


> As before, everything works fine when I switch to FHD or radeonsi.

You cannot "switch to radeonsi", I assume you mean when you use the radeon
kernel driver instead of amdgpu. The Mesa radeonsi driver is used in both
cases.

You might want to try a kernel built from the amd-staging-drm-next branch of
https://cgit.freedesktop.org/~agd5f/linux/ with CONFIG_DRM_AMD_DC=y at build
time and amdgpu.dc=1 at runtime, to see if that works better.

-- 
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 103317] Tearing in WQHD, but not in FHD

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

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

[PATCH] drm/etnaviv: add sensitive state for occlusion query address

[Christian Gmeiner]

Add GL.OCCLUSION_QUERY_ADDR (0x03824): address where GPU stores
the occlusion query result.

Signed-off-by: Christian Gmeiner 
---
 drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c 
b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
index 6e3bbcf24160..68e6d3772ad8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
@@ -78,6 +78,7 @@ static const struct {
ST(0x17c0, 8),
ST(0x17e0, 8),
ST(0x2400, 14 * 16),
+   ST(0x3824, 1),
ST(0x10800, 32 * 16),
ST(0x14600, 16),
ST(0x14800, 8 * 8),
-- 
2.13.6

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

[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU

[bugzilla-daemon]

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

--- Comment #58 from Michel Dänzer  ---
(In reply to Daniel Vetter from comment #55)
> So parts of the reasons I've reassigned to amdgpu is that apparently someone
> also seen these corruptions when everything is rendered on amdgpu, and i915
> only displays.

We'd need more information about how exactly that test was performed (i.e.
details about how exactly "everything is rendered on amdgpu, and i915 only
displays") and what the corruption looks like in that case.

-- 
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 v2] drm: panel: simple: add Toshiba LT089AC19000

[Thierry Reding]

On Thu, Oct 19, 2017 at 10:27:19AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 19.10.2017, 10:17 +0200 schrieb Thierry Reding:
> > On Wed, Oct 18, 2017 at 07:22:40PM +0200, Lucas Stach wrote:
> > > Only exposes a single mode and not a complete display timing, as
> > > the datasheet is rather vague about the minimum/maximum values.
> > > 
> > > > > Signed-off-by: Lucas Stach 
> > > > > Acked-by: Rob Herring 
> > > ---
> > > v2:
> > > - fix display size in documentation
> > > - add bus flags
> > > ---
> > >  .../display/panel/toshiba,lt089ac29000.txt |  8 +++
> > >  drivers/gpu/drm/panel/panel-simple.c   | 27 
> > > ++
> > >  2 files changed, 35 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
> > 
> > Separate patches are preferred for bindings and driver.
> 
> This is news to me. At least in simple-panel land, I've always only
> split out additions of new vendor prefixes and kept the bindings
> together with the driver.
> 
> I'll change that in the future if you prefer otherwise.

I don't mind too much either way, but I've seen Rob say he prefers
separate patches. I guess ultimately that makes it easier to move the DT
bindings outside of the kernel tree, but maybe there are other reasons,
too.

Rob, care to educate us?

Thierry


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