Proposal for RandR version 1.6, Leases and EDID-based output grabs

["Keith Packard"]

As a part of the DRM leasing work, we need a way to have the X server
create a lease and pass it back to an X client. Here's a proposal for
the RandR specification changes necessary for that. The basic plan is
pretty simple:

 1. Expose the ability to create a lease for a set of CRTCs and
OUTPUTs. The X server will have to pick a suitable encoder as that's
not visible via RandR.

 2. Provide a way to hide some monitors from other clients using EDID
manufacturer ids and product codes. Outputs with EDID properties
matching the grab will report 'disconnected' to all clients other
than the grabbing client. This way, the desktop environment never
knows that an HMD has been plugged in, so there's no transient
flicker of desktop being presented to it.

I wanted to make it possible for the X server to set the mode on the
leased outputs, but I'm not sure how -- I don't want to display the X
screen on them, and there's no other frame buffer I can name over the
wire. For now, that means the leasing client will need to set a mode
itself. If that fails, it can go whack the X configuration over RandR
and try again, which is all the X server would do anyways.

Comments are welcome; I'll go try to write the code in the next few
days; it all looks pretty easy at this point.

diff --git a/randrproto.txt b/randrproto.txt
index 74b7c36..8dded63 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -1,6 +1,6 @@
   The X Resize, Rotate and Reflect Extension
-Version 1.5.0
-  2015-03-14
+Version 1.6.0
+  2017-04-01
 
  Jim Gettys
   jim.get...@hp.com
@@ -9,9 +9,7 @@
Hewlett Packard Company
 
 Keith Packard
-   keith.pack...@intel.com
-Open Source Technology Center
-  Intel Corporation
+ kei...@keithp.com
 
 1. Introduction
 
@@ -186,6 +184,24 @@ consider as single viewable areas.
 Xinerama's information now comes from the Monitors instead of directly
 from the CRTCs. The Monitor marked as Primary will be listed first.
 
+1.6. Introduction to version 1.6 of the extension
+
+Version 1.6 adds resource leasing.
+
+ • A 'Lease' is a collection of crtcs and outputs which are made
+   available to a client for direct access via kernel KMS and DRM
+   APIs. This is done by passing a suitable file descriptor back to
+   the client which has access to those resources. While leased, those
+   resources aren't used by the X server.
+
+Version 1.6 adds EDID-based output 'grabbing'.
+
+ • An 'Output Grab' matches a set of EDID Manufacturer ID and product
+   codes. For outputs with matching EDID values, the connected status
+   of the output is only visible to the grabbing client. Other clients
+   will see the output as disconnected. Attempts to configure the
+   grabbed output by other clients will fail.
+
 1.99 Acknowledgments
 
 Our thanks to the contributors to the design found on the xpert mailing
@@ -273,6 +289,10 @@ Mode
 Provider
A value for a PROVIDER argument does not name a defined PROVIDER.
 
+OutputGrab
+   A value for an OUTPUTGRAB argument does not name a defined
+   OUTPUTGRAB
+
  ❧❧❧
 
 5. Protocol Types
@@ -419,6 +439,23 @@ MONITORINFO { name: ATOM
 
  ❧❧❧
 
+5.7. Protocol Types added in version 1.6 of the extension
+
+OUTPUTGRAB { XID }
+
+EDIDMATCH { id: CARD16
+code-min: CARD16
+code-max: CARD16 }
+
+   These values come from the EDID specification. 'id' is the
+   Manufacturer ID value which is bytes 8 and 9 in the EDID
+   packet, stored in big endian order (MSB first). 'code-min' and
+   'code-max' define a closed-interval of Manufacturer product
+   codes, which is byte 10 and 11 of the EDID packet, stored in
+   little endian order (LSB first).
+
+ ❧❧❧
+
 6. Extension Initialization
 
 The name of this extension is "RANDR".
@@ -1666,6 +1703,67 @@ dynamic changes in the display environment.
window of the screen.
 
  ❧❧❧
+
+7.6. Extension Requests added in version 1.6 of the extension.
+
+┌───
+RRCreateLease
+   window : WINDOW
+   crtcs: LISTofCRTC
+   outputs: LISTofOUTPUT
+ ▶
+   nfd: CARD8
+   lease: FD
+└───
+   Errors: Window, Access, Value, CRTC, Output
+
+   Creates a new Lease for the specified crtcs and outputs from
+   the screen defined by 'window'. Returns a KMS/DRM file
+   descriptor which can control the leased objects directly
+   through the kernel. While leased, all resources will appear to
+   be 'useless' to clients other than the leasing client as
+   follows:
+
+   • Crtcs are reported 

Re: DVI output on i.MX51 EVP board not working?

[Fabio Estevam]

Hi Wladimir,

On Fri, Mar 31, 2017 at 2:36 AM, Wladimir J. van der Laan
 wrote:

> - Went as far back as kernel v4.0, even to v3.12 or so (commit 493a863, "ARM:
>   dts: imx51-babbage: Make DVI and WVGA panel functional"). No difference. So 
> nothing to
>   bisect, unfortunately.

It was a long time I worked on this commit and it worked well for me
on an old DVI monitor.

I will try to locate such monitor in the office next week and try it again.

Regards,

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

[PATCH 1/9] drm: bridge: analogix: Detach panel when unbinding analogix dp

[Jeffy Chen]

The panel is attached when binding analogix dp.

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e7cd105..a3db290 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1443,6 +1443,8 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
DRM_ERROR("failed to turnoff the panel\n");
+   if (drm_panel_detach(dp->plat_data->panel))
+   DRM_ERROR("failed to detach the panel\n");
}
 
pm_runtime_disable(dev);
-- 
2.1.4


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

[PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

[Keith Packard]

Attempts to modify un-leased objects are rejected with an error.
Information returned about unleased objects is modified to make them
appear unusable and/or disconnected.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_atomic.c  |  3 +++
 drivers/gpu/drm/drm_auth.c|  2 +-
 drivers/gpu/drm/drm_color_mgmt.c  |  3 +++
 drivers/gpu/drm/drm_connector.c   | 52 ++-
 drivers/gpu/drm/drm_crtc.c| 15 ---
 drivers/gpu/drm/drm_encoder.c | 18 +++---
 drivers/gpu/drm/drm_mode_object.c |  3 +++
 drivers/gpu/drm/drm_plane.c   | 36 +++
 include/drm/drm_lease.h   |  4 +++
 include/drm/drm_mode_object.h |  1 +
 10 files changed, 108 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index fdfb1ec17e66..a3cb95f7f1c1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2134,6 +2134,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
goto out;
}
 
+   if ((ret = drm_lease_check(file_priv->master, obj->id)) < 0)
+   goto out;
+
if (!obj->properties) {
drm_mode_object_unreference(obj);
ret = -ENOENT;
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1db4f63860d1..44c99d12f4c1 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -303,7 +303,7 @@ void drm_master_release(struct drm_file *file_priv)
  */
 bool drm_is_current_master(struct drm_file *fpriv)
 {
-   return fpriv->is_master && fpriv->master == fpriv->minor->dev->master;
+   return fpriv->is_master && drm_lease_owner(fpriv->master) == 
fpriv->minor->dev->master;
 }
 EXPORT_SYMBOL(drm_is_current_master);
 
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 6543ebde501a..f8d7a499cf95 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -206,6 +206,9 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
goto out;
}
 
+   if ((ret = drm_lease_check(file_priv->master, crtc->base.id)) < 0)
+   goto out;
+
if (crtc->funcs->gamma_set == NULL) {
ret = -ENOSYS;
goto out;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7a7019ac9388..a95db57dd966 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1079,6 +1079,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_mode_modeinfo u_mode;
struct drm_mode_modeinfo __user *mode_ptr;
uint32_t __user *encoder_ptr;
+   bool leased;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -1093,9 +1094,16 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
goto out_unlock;
}
 
-   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
-   if (connector->encoder_ids[i] != 0)
-   encoders_count++;
+   leased = drm_lease_check(file_priv->master, connector->base.id) == 0;
+
+   DRM_DEBUG_LEASE("connector %d leased %s\n", connector->base.id, leased 
? "true" : "false");
+
+   if (leased) {
+   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
+   if (connector->encoder_ids[i] != 0 &&
+   drm_lease_check(file_priv->master, 
connector->encoder_ids[i]) == 0)
+   encoders_count++;
+   }
 
if (out_resp->count_modes == 0) {
connector->funcs->fill_modes(connector,
@@ -1104,21 +1112,29 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
}
 
/* delayed so we get modes regardless of pre-fill_modes state */
-   list_for_each_entry(mode, >modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
-   mode_count++;
+   if (leased)
+   list_for_each_entry(mode, >modes, head)
+   if (drm_mode_expose_to_userspace(mode, file_priv))
+   mode_count++;
 
out_resp->connector_id = connector->base.id;
out_resp->connector_type = connector->connector_type;
out_resp->connector_type_id = connector->connector_type_id;
-   out_resp->mm_width = connector->display_info.width_mm;
-   out_resp->mm_height = connector->display_info.height_mm;
-   out_resp->subpixel = connector->display_info.subpixel_order;
-   out_resp->connection = connector->status;
+   if (leased) {
+   out_resp->mm_width = connector->display_info.width_mm;
+   out_resp->mm_height = connector->display_info.height_mm;
+   out_resp->subpixel = connector->display_info.subpixel_order;
+   

[PATCH 4/9] drm/rockchip: cdn-dp: Don't try to release firmware when not loaded

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index fd79a70..a97f3f4 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1052,6 +1052,7 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->connected = false;
dp->active = false;
dp->active_port = -1;
+   dp->fw_loaded = false;
 
INIT_WORK(>event_work, cdn_dp_pd_event_work);
 
@@ -1132,7 +1133,8 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
connector->funcs->destroy(connector);
 
pm_runtime_disable(dev);
-   release_firmware(dp->fw);
+   if (dp->fw_loaded)
+   release_firmware(dp->fw);
kfree(dp->edid);
dp->edid = NULL;
 }
-- 
2.1.4


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

[PATCH v2 8/9] drm/rockchip: gem: Don't alloc/free gem buf before drm dev registered

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..2bf8024 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_device *drm = obj->dev;
struct rockchip_drm_private *private = drm->dev_private;
 
+   if (!drm->registered)
+   return -ENODEV;
+
if (private->domain)
return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
else
@@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct 
rockchip_gem_object *rk_obj)
 
 static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
 {
+   struct drm_device *drm = rk_obj->base.dev;
+
+   if (!drm->registered)
+   return;
+
if (rk_obj->pages)
rockchip_gem_free_iommu(rk_obj);
else
-- 
2.1.4


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

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote:
> Comments are welcome. I'd like to get this in for the 4.12 kernel as
> this is a missing piece needed to integrate CEC drivers.

First two patches seem fine, and work with dw-hdmi.

I'll hold dw-hdmi off until after 4.11 - I currently have this stuff
merged against 4.10, and there's some conflicts with 4.11.

I also wanted to say that tda998x/tda9950 works, and send you those
patches, but while trying to test them this afternoon in a tree with
some of the DRM code that was merged during the last merge window on
a v4.10 based tree (which I need because of etnaviv), the kernel
oopses in DRM for god-knows-why.  If/when I get this sorted (don't
know when) I'll send that stuff as a follow-up to your series.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/9] drm: rockchip: Fix rockchip drm unbind crash error

[Jeffy Chen]

Verified on rk3399 chromebook kevin:
1/ stop ui && pkill -9 frecon
2/ unbind/bind drm


Jeffy Chen (9):
  drm: bridge: analogix: Detach panel when unbinding analogix dp
  drm: bridge: analogix: Unregister dp aux when unbinding
  drm: bridge: analogix: Destroy connector when unbinding
  drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
  drm/rockchip: vop: Enable pm domain when resetting vop
  drm/rockchip: Reoder unload sequence
  drm/rockchip: Force disable all crtc when unload
  drm/rockchip: gem: Don't alloc/free gem buf before drm dev registered
  drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 10 ---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  7 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  8 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 31 +++---
 5 files changed, 44 insertions(+), 16 deletions(-)

-- 
2.1.4


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

[PATCH v2 5/9] drm/rockchip: vop: Enable pm domain when resetting vop

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 31 +++--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..1d85319 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1365,6 +1365,12 @@ static int vop_initial(struct vop *vop)
return ret;
}
 
+   ret = pm_runtime_get_sync(vop->dev);
+   if (ret < 0) {
+   dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+   goto err_put_pm_runtime;
+   }
+
/* Enable both the hclk and aclk to setup the vop */
ret = clk_prepare_enable(vop->hclk);
if (ret < 0) {
@@ -1422,6 +1428,8 @@ static int vop_initial(struct vop *vop)
 
vop->is_enabled = false;
 
+   pm_runtime_put_sync(vop->dev);
+
return 0;
 
 err_disable_aclk:
@@ -1430,6 +1438,8 @@ static int vop_initial(struct vop *vop)
clk_disable_unprepare(vop->hclk);
 err_unprepare_dclk:
clk_unprepare(vop->dclk);
+err_put_pm_runtime:
+   pm_runtime_put_sync(vop->dev);
return ret;
 }
 
@@ -1530,12 +1540,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
if (!vop->regsbak)
return -ENOMEM;
 
-   ret = vop_initial(vop);
-   if (ret < 0) {
-   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
-   return ret;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "cannot find irq for vop\n");
@@ -1556,15 +1560,22 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
/* IRQ is initially disabled; it gets enabled in power_on */
disable_irq(vop->irq);
 
+   pm_runtime_enable(>dev);
+
+   ret = vop_initial(vop);
+   if (ret < 0) {
+   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
+   goto err_disable_pm_runtime;
+   }
+
ret = vop_create_crtc(vop);
if (ret)
-   goto err_enable_irq;
-
-   pm_runtime_enable(>dev);
+   goto err_disable_pm_runtime;
 
return 0;
 
-err_enable_irq:
+err_disable_pm_runtime:
+   pm_runtime_disable(>dev);
enable_irq(vop->irq); /* To balance out the disable_irq above */
return ret;
 }
-- 
2.1.4


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

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

[Dan MacDonald]

Thanks Russell!

I think the patch has applied OK - I've just started the build so it
could be a while yet. 12 hours maybe? Its building support for every
arm7 thing under the sun because I'm too lazy (sensible?) to try
hacking it down to size.

Adding the patch to the Arch rc kernel PKGBUILD was as simple as
adding the name of the patch to the source() section, adding a
corresponding 'SKIP' to the end of the md5sums() section and then
adding:

 git apply ../sabre-lite.patch

to the prepare() section of the PKGBUILD. I copied the patch into the
same dir as the PKGBUILD and then ran:

$ makepkg

In the same dir as the kernel PKGBUILD and patches.

Results at last! :D

On Fri, Mar 31, 2017 at 3:15 PM, Russell King - ARM Linux
 wrote:
> On Fri, Mar 31, 2017 at 02:36:31PM +0100, Dan MacDonald wrote:
>> Hi all
>>
>> Up until now I've only ever used the most basic features of git, so
>> I've had to do some research into how to best/cleanly extract
>> Phillipps patches so that I can include his changes into an Arch
>> kernel PKGBUILD.
>>
>> I think the following should work:
>>
>> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> cd linux
>> git fetch https://git.pengutronix.de/git/pza/linux.git
>> tags/v4.10-ipu-dp-plane-fix
>> git checkout FETCH_HEAD
>> git whatchanged -p origin/master..FETCH_HEAD > sabre-lite.patch
>
> I don't think that will work, because it'll output the changes as
> individual patches in reverse order (newest first) which will be
> no good when trying to feed it into patch or git apply.
>
> I think what you instead want is:
>
>   git diff origin/master...FETCH_HEAD > sabre-lite.patch
>
> which will be the changes that are in FETCH_HEAD that aren't in
> origin/master as a single patch.
>
>> I should then be able to include that patch in a 4.11-rc4 PKGBUILD -
>> I'll give it a go this weekend and see if it applies and builds OK but
>> please let me know if anyone sees any flaws in this procedure.
>
> Thanks - one of the issues is that not everyone knows the details of
> distribution package build systems (each distro seems to have their
> own unique way of building and packaging stuff.)
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/9] drm/rockchip: Force disable all crtc when unload

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a5d83cb..5dbf011 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -246,6 +246,7 @@ static void rockchip_drm_unbind(struct device *dev)
rockchip_drm_fbdev_fini(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
 
+   drm_crtc_force_disable_all(drm_dev);
drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
drm_mode_config_cleanup(drm_dev);
-- 
2.1.4


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

Re: [PATCH 1/6] virtio: wrap find_vqs

[Bjorn Andersson]

On Wed 29 Mar 13:48 PDT 2017, Michael S. Tsirkin wrote:

> We are going to add more parameters to find_vqs, let's wrap the call so
> we don't need to tweak all drivers every time.
> 
> Signed-off-by: Michael S. Tsirkin 

Acked-by: Bjorn Andersson 

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

[PATCH 4/4] drm: Add four ioctls for managing drm mode object leases

[Keith Packard]

drm_mode_create_lease

Creates a lease for a list of drm mode objects, returning an
fd for the new drm_master and a 64-bit identifier for the lessee

drm_mode_list_lesees

List the identifiers of the lessees from a particular lessor

drm_mode_get_lease

List the leased objects for a particular lessee

drm_mode_change_lease

Adjust the terms of a lease, adding or removing resources or
switching from masking to non-masking.

This should suffice to at least create, query and manage available
leases.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_ioctl.c |   4 +
 drivers/gpu/drm/drm_lease.c | 309 
 include/drm/drm_lease.h |  12 ++
 include/uapi/drm/drm.h  |   4 +
 include/uapi/drm/drm_mode.h |  78 +++
 5 files changed, 407 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index fed22c2b98b6..0f9e3c0fe2ac 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -636,6 +636,10 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATEPROPBLOB, drm_mode_createblob_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROYPROPBLOB, 
drm_mode_destroyblob_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl, 
DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl, 
DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, 
DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CHANGE_LEASE, drm_mode_change_lease_ioctl, 
DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 782005c7706d..39131860bcd3 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -483,3 +483,312 @@ void drm_lease_destroy(struct drm_master *master)
 
DRM_DEBUG_LEASE("drm_lease_destroy done %d\n", master->lessee_id);
 }
+
+/**
+ * drm_mode_create_lease_ioctl - create a new lease
+ * @dev: the drm device
+ * @data: pointer to struct drm_mode_create_lease
+ * @file_priv: the file being manipulated
+ *
+ * The master associated with the specified file will have a lease
+ * created containing the objects specified in the ioctl structure.
+ * A file descriptor will be allocated for that and returned to the
+ * application.
+ */
+int drm_mode_create_lease_ioctl(struct drm_device *dev,
+   void *data, struct drm_file *lessor_priv)
+{
+   struct drm_mode_create_lease *cl = data;
+   size_t object_count;
+   size_t o;
+   int ret = 0;
+   struct idr leases;
+   struct drm_master *lessor = lessor_priv->master;
+   struct drm_master *lessee = NULL;
+   struct file *lessee_file = NULL;
+   struct file *lessor_file = lessor_priv->filp;
+   struct drm_file *lessee_priv;
+   int fd = -1;
+
+   object_count = cl->object_count;
+   idr_init();
+
+   fd = get_unused_fd_flags(cl->flags & (O_CLOEXEC | O_NONBLOCK));
+
+   DRM_DEBUG_LEASE("Creating new lease\n");
+
+   /* Lookup the mode objects and add their IDs to the lease request */
+   for (o = 0; o < object_count; o++) {
+   __u32 object_id;
+
+   if (copy_from_user(_id,
+  u64_to_user_ptr(cl->object_ids) + o * sizeof 
(__u32),
+  sizeof (__u32))) {
+   ret = -EFAULT;
+   goto bail;
+   }
+   DRM_DEBUG_LEASE("Adding object %d to lease\n", object_id);
+
+   ret = idr_alloc(, (void *) 1, object_id, object_id + 1, 
GFP_KERNEL);
+   if (ret < 0) {
+   DRM_DEBUG_LEASE("Object %d cannot be inserted into 
leases (%d)\n",
+   object_id, ret);
+   goto bail;
+   }
+   }
+
+   mutex_lock(>master_mutex);
+
+   DRM_DEBUG_LEASE("Creating lease\n");
+   lessee = drm_lease_create(lessor, cl->mask_lease != 0, );
+
+   if (IS_ERR(lessee)) {
+   ret = PTR_ERR(lessee);
+   lessee = NULL;
+   mutex_unlock(>master_mutex);
+   goto bail;
+   }
+
+   /* Clone the lessor file to create a new file for us */
+   DRM_DEBUG_LEASE("Allocating lease file\n");
+   path_get(_file->f_path);
+   lessee_file = alloc_file(_file->f_path,
+lessor_file->f_mode,
+

Re: [Intel-gfx] [PATCH v5 4/5] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Thu, 2017-03-30 at 12:36 +0200, Maarten Lankhorst wrote:
> Op 30-03-17 om 10:42 schreef Dhinakaran Pandiyan:
> > From: "Pandiyan, Dhinakaran" 
> >
> > Having an ->atomic_release callback is useful to release shared resources
> > that get allocated in compute_config(). This function is expected to be
> > called in the atomic_check() phase before new resources are acquired.
> >
> > v4: Document that the function is conditionally called and before
> > other atomic_checks() (Daniel)
> > v3: Use the new 'for_each_oldnew_connector_in_state()' macro.
> > v2: Moved the caller hunk to this patch (Daniel)
> >
> > Cc: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Archit Taneja 
> > Cc: Chris Wilson 
> > Cc: Harry Wentland 
> > Reviewed-by: Maarten Lankhorst 
> > Reviewed-by: Daniel Vetter 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 19 +++
> >  include/drm/drm_modeset_helper_vtables.h | 16 
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index d14094d..9d07669 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -586,6 +586,25 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > }
> > }
> >  
> > +   for_each_oldnew_connector_in_state(state, connector, 
> > old_connector_state, new_connector_state, i) {
> > +   const struct drm_connector_helper_funcs *conn_funcs;
> > +   struct drm_crtc_state *crtc_state;
> > +
> > +   conn_funcs = connector->helper_private;
> > +   if (!conn_funcs->atomic_release)
> > +   continue;
> > +
> > +   if (!old_connector_state->crtc)
> > +   continue;
> > +
> > +   crtc_state = drm_atomic_get_existing_crtc_state(state, 
> > old_connector_state->crtc);
> > +
> > +   if (crtc_state->connectors_changed ||
> > +   crtc_state->mode_changed ||
> > +   (crtc_state->active_changed && !crtc_state->active))
> > +   conn_funcs->atomic_release(connector, 
> > new_connector_state);
> > +   }
> > +
> > return mode_fixup(state);
> >  }
> Oops, I'm just looking at patch 5 again..
> 
> atomic_release should return an int to allow error propogation. There's no 
> good reason why it shouldn't.
> This would allow handling errors in patch 5 more gracefully.

Makes sense, will change that. This made me think about how
intel_dp_mst_atomic_release() handles an invalid mst_port reference
i.e., in case the port is gone. I'll fix both and send a new version.

-DK


> >  EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 091c422..84e80aa 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -836,6 +836,22 @@ struct drm_connector_helper_funcs {
> >  */
> > struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
> > *connector,
> >struct drm_connector_state 
> > *connector_state);
> > +
> > +   /**
> > +* @atomic_release:
> > +*
> > +* This function is conditionally called to release shared resources
> > +* when the attached CRTC's mode changes or it's connectors change or
> > +* becomes inactive. It is called before the corresponding
> > +* _crtc_helper_funcs.atomic_check or
> > +* _crtc_helper_funcs.mode_fixup hooks are called.
> > +*
> > +* NOTE:
> > +*
> > +* This function is called in the check phase of an atomic update.
> > +*/
> > +   void (*atomic_release)(struct drm_connector *connector,
> > +  struct drm_connector_state *connector_state);
> >  };
> >  
> >  /**
> 
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 2/4] drm: Add drm_object lease infrastructure

[Keith Packard]

This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.

An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns' them. This sits at the top of a
tree of drm_masters.

A 'lessee' is a drm_master which is leasing objects from some other
drm_master. Each lessee holds the set of objects which it is leasing
from the lessor.

A 'lessor' is a drm_master which is leasing objects to another
drm_master.

The set of objects any drm_master 'controls' is limited to the set of
objects it leases (for lessees) or all objects (for owners),
optionally minus the set of objects it has leased to other
drm_masters.

Objects not controlled by a drm_master cannot be modified through the
various state manipulating ioctls, and any state reported back to user
space will be edited to make them appear idle and/or unusable. For
instance, connectors always report 'disconnected', while encoders
report no possible crtcs or clones.

The full list of lessees leasing objects from an owner (either
directly, or indirectly through another lessee), can be searched from
an idr in the drm_master of the owner.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/drm_auth.c  |  22 +-
 drivers/gpu/drm/drm_lease.c | 485 
 include/drm/drmP.h  |   1 +
 include/drm/drm_auth.h  |  28 +++
 include/drm/drm_lease.h |  51 +
 6 files changed, 588 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_lease.c
 create mode 100644 include/drm/drm_lease.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index b9ae4280de9d..c2c6d61d30cf 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,8 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
-   drm_dumb_buffers.o drm_mode_config.o
+   drm_dumb_buffers.o drm_mode_config.o \
+   drm_lease.o
 
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 6b143514a566..1db4f63860d1 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -31,6 +31,7 @@
 #include 
 #include "drm_internal.h"
 #include "drm_legacy.h"
+#include 
 
 /**
  * DOC: master and authentication
@@ -93,7 +94,7 @@ int drm_authmagic(struct drm_device *dev, void *data,
return file ? 0 : -EINVAL;
 }
 
-static struct drm_master *drm_master_create(struct drm_device *dev)
+struct drm_master *drm_master_create(struct drm_device *dev)
 {
struct drm_master *master;
 
@@ -107,6 +108,14 @@ static struct drm_master *drm_master_create(struct 
drm_device *dev)
idr_init(>magic_map);
master->dev = dev;
 
+   /* initialize the tree of output resource lessees */
+   master->lessor = NULL;
+   master->lessee_id = 0;
+   INIT_LIST_HEAD(>lessees);
+   INIT_LIST_HEAD(>lessee_list);
+   idr_init(>leases);
+   idr_init(>lessee_idr);
+
return master;
 }
 
@@ -189,6 +198,12 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
goto out_unlock;
}
 
+   if (file_priv->master->lessor != NULL) {
+   DRM_DEBUG_LEASE("Attempt to set lessee %d as master\n", 
file_priv->master->lessee_id);
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
ret = drm_set_master(dev, file_priv, false);
 out_unlock:
mutex_unlock(>master_mutex);
@@ -310,12 +325,17 @@ static void drm_master_destroy(struct kref *kref)
struct drm_master *master = container_of(kref, struct drm_master, 
refcount);
struct drm_device *dev = master->dev;
 
+   drm_lease_destroy(master);
+
if (dev->driver->master_destroy)
dev->driver->master_destroy(dev, master);
 
drm_legacy_master_rmmaps(dev, master);
 
idr_destroy(>magic_map);
+
+   idr_destroy(>lessee_idr);
+
kfree(master->unique);
kfree(master);
 }
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
new file mode 100644
index ..782005c7706d
--- /dev/null
+++ b/drivers/gpu/drm/drm_lease.c
@@ -0,0 +1,485 @@
+/*
+ * Copyright © 2017 Keith Packard 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 12:41:30PM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> > > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > > > Hi Russell,
> > > > > 
> > > > > You were Cc-ed in a patch from March 8th that did all this:
> > > > > 
> > > > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > > > 
> > > > I'm aware of that (you may notice that this was threaded to that patch.)
> > > > 
> > > > > I have not received any response from you, so I have already pushed 
> > > > > the
> > > > > patch in my public repo:
> > > > > 
> > > > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > > > 
> > > > > It has been included into linux-next for at least a couple of weeks 
> > > > > now.
> > > > 
> > > > I've not had a chance to test any of this, but I believe that your
> > > > patch does not fully address the issue, due to bits missing from
> > > > the validation path.
> > > 
> > > Care to point out which bits were missing from my patch that are in yours?
> > 
> > The visible check?
> 
> A plane's ->atomic_check() hook can be called with TEST_ONLY to figure out 
> from
> userspace if the given configuration is a valid one that can be accepted by
> the hardware. There should be no error if the plane will not be visible, as we
> are not programming anything yet.
> 
> I would also argue that the test that you remove and replace with 
> state->visible
> is important. We can't do *any* scaling, while with your patch we could accept
> src_w != crtc_w as long as it is visible. Hardware is not capable of handling 
> that.

That's what the "DRM_PLANE_HELPER_NO_SCALING" arguments to
drm_plane_helper_check_state() are doing:

drm_plane_helper_check_state()
drm_rect_calc_hscale()

if (hscale < min_hscale || hscale > max_hscale)
return -ERANGE;

drm_rect_calc_vscale()

if (vscale < min_vscale || vscale > max_vscale)
return -ERANGE;

where DRM_PLANE_HELPER_NO_SCALING is 1.0 in 16:16 format.  So, this
ensures that the scaling factor is 1.0, returning -ERANGE if it isn't.

If this lets through a scaled source, then there's a bug that needs
fixing in the helper.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

DRM Display driver for Intel FPGA Video and Image Processing Suite

[Ong, Hean Loong]

Hi,

I would like to upstream the attached Intel FPGA Video and Image
Processing Suite. The attached patch supports the Intel Arria10 devkit
and its variants. The purpose of the patch is to enable the FPGA driven
display designed from the Intel Quartus FPGA design suite.

The driver is required as part of the Intel Arria10 devkit reference
design. The driver was tested on:
- The Open Embedded Angstrom Distro. 
- The matchbox-terminal and window-manager was used for functional
testing

Current the intention of the driver is meant to validate the FPGA
designs on the Arria10 devkit for Display Port connecter. We have not
verified its performance of or stability in 3D acceleration or other
non Intel FPGA hardware

BR

Hean LoongFrom 0de293e3646a1780ed603cf8e1f2a19d9aebbe83 Mon Sep 17 00:00:00 2001
From: Ong, Hean Loong 
Date: Thu, 30 Mar 2017 18:02:22 +0800
Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite Frame Buffer II driver

Signed-off-by: Ong, Hean Loong 
---
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/ivip/Kconfig  |   22 
 drivers/gpu/drm/ivip/Makefile |9 ++
 drivers/gpu/drm/ivip/intel_vip_conn.c |  145 ++
 drivers/gpu/drm/ivip/intel_vip_core.c |  215 +
 drivers/gpu/drm/ivip/intel_vip_crtc.c |  161 
 drivers/gpu/drm/ivip/intel_vip_drv.h  |   55 +
 drivers/gpu/drm/ivip/intel_vip_of.c   |  146 ++
 9 files changed, 756 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/ivip/Kconfig
 create mode 100644 drivers/gpu/drm/ivip/Makefile
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_crtc.c
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
 create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ebfe840..c487507 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -167,6 +167,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
 
 source "drivers/gpu/drm/i915/Kconfig"
 
+source "drivers/gpu/drm/ivip/Kconfig"
+
 config DRM_VGEM
 	tristate "Virtual GEM provider"
 	depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index b9ae428..945cf53 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
 obj-$(CONFIG_DRM_MGA)	+= mga/
 obj-$(CONFIG_DRM_I810)	+= i810/
 obj-$(CONFIG_DRM_I915)	+= i915/
+obj-$(CONFIG_DRM_IVIP)	+= ivip/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
 obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..ddf3cb5
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,22 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+Choose this option if you have a Intel FPGA Arria 10 system
+and above with a Display Port IP. This does not support legacy
+Intel FPGA Cyclone V display port. Currently only single frame
+buffer is supported. Note that ACPI and X_86 architecture is yet
+to be supported.
+
+config DRM_IVIP_OF
+tristate "Intel FGPA Video and Image Processing Open Firmware Systems"
+depends on DRM_IVIP && OF
+help
+Choose this option if the Intel FPGA system is using Open
+Firmware systems (Arria 10). If M is selected the module would
+be called ivip.
+
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..7be1e99
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver.  This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP_OF) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+intel_vip_conn.o intel_vip_crtc.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..89ab587
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,145 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.

[PATCH v2 2/9] drm: bridge: analogix: Unregister dp aux when unbinding

[Jeffy Chen]

The dp aux is registered when binding analogix dp.

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a3db290..ec47fc2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1447,6 +1447,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
DRM_ERROR("failed to detach the panel\n");
}
 
+   drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
2.1.4


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

[PATCH 3/9] drm: bridge: analogix: Destroy connector when unbinding

[Jeffy Chen]

Normally we do this in drm_mode_config_cleanup. But analogix dp's
connector is allocated when binding, and would be freed after unbind.

So we need to destroy it when unbinding, to avoid further access.

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ec47fc2..084ee8f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1439,6 +1439,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
analogix_dp_bridge_disable(dp->bridge);
+   dp->connector.funcs->destroy(>connector);
 
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
-- 
2.1.4


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

Vulkan WSI+VK_KHR_display for KMS/DRM?

["Keith Packard"]

Krh hacked up kmscube into vkcube which can run vulkan directly on kms,
but that doesn't use any of the WSI apis and VK_KHR_display
extension. Is anyone thinking that might be a good idea to do, or should
we just keep on hacking things like vkcube does?

-- 
-keith


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

[PATCH 9/9] drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding

[Jeffy Chen]

In current sound framework, there's no way to unbind dai link after
unregister codec.

So don't unregister the codec when unbinding for now.

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a97f3f4..1deab9f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1091,8 +1091,6 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
goto err_free_connector;
}
 
-   cdn_dp_audio_codec_init(dp, dev);
-
for (i = 0; i < dp->ports; i++) {
port = dp->port[i];
 
@@ -1127,7 +1125,6 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
struct drm_connector *connector = >connector;
 
cancel_work_sync(>event_work);
-   platform_device_unregister(dp->audio_pdev);
cdn_dp_encoder_disable(encoder);
encoder->funcs->destroy(encoder);
connector->funcs->destroy(connector);
@@ -1220,6 +1217,8 @@ static int cdn_dp_probe(struct platform_device *pdev)
mutex_init(>lock);
dev_set_drvdata(dev, dp);
 
+   cdn_dp_audio_codec_init(dp, dev);
+
return component_add(dev, _dp_component_ops);
 }
 
@@ -1227,6 +1226,7 @@ static int cdn_dp_remove(struct platform_device *pdev)
 {
struct cdn_dp_device *dp = platform_get_drvdata(pdev);
 
+   platform_device_unregister(dp->audio_pdev);
cdn_dp_suspend(dp->dev);
component_del(>dev, _dp_component_ops);
 
-- 
2.1.4


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

Re: [PATCHv6 01/10] media: add CEC notifier support

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote:
> +struct cec_notifier *cec_notifier_get(struct device *dev)
> +{
> + struct cec_notifier *n;
> +
> + mutex_lock(_notifiers_lock);
> + list_for_each_entry(n, _notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(_notifiers_lock);
> + kref_get(>kref);

Isn't this racy?  What stops one thread trying to get the notifier
while another thread puts the notifier?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 7/9] drm/rockchip: Force disable all crtc when unload

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a5d83cb..5dbf011 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -246,6 +246,7 @@ static void rockchip_drm_unbind(struct device *dev)
rockchip_drm_fbdev_fini(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
 
+   drm_crtc_force_disable_all(drm_dev);
drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
drm_mode_config_cleanup(drm_dev);
-- 
2.1.4


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

[PATCH 5/9] drm/rockchip: vop: Enable pm domain when resetting vop

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 31 +++--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 76c79ac..1d85319 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1365,6 +1365,12 @@ static int vop_initial(struct vop *vop)
return ret;
}
 
+   ret = pm_runtime_get_sync(vop->dev);
+   if (ret < 0) {
+   dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+   goto err_put_pm_runtime;
+   }
+
/* Enable both the hclk and aclk to setup the vop */
ret = clk_prepare_enable(vop->hclk);
if (ret < 0) {
@@ -1422,6 +1428,8 @@ static int vop_initial(struct vop *vop)
 
vop->is_enabled = false;
 
+   pm_runtime_put_sync(vop->dev);
+
return 0;
 
 err_disable_aclk:
@@ -1430,6 +1438,8 @@ static int vop_initial(struct vop *vop)
clk_disable_unprepare(vop->hclk);
 err_unprepare_dclk:
clk_unprepare(vop->dclk);
+err_put_pm_runtime:
+   pm_runtime_put_sync(vop->dev);
return ret;
 }
 
@@ -1530,12 +1540,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
if (!vop->regsbak)
return -ENOMEM;
 
-   ret = vop_initial(vop);
-   if (ret < 0) {
-   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
-   return ret;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "cannot find irq for vop\n");
@@ -1556,15 +1560,22 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
/* IRQ is initially disabled; it gets enabled in power_on */
disable_irq(vop->irq);
 
+   pm_runtime_enable(>dev);
+
+   ret = vop_initial(vop);
+   if (ret < 0) {
+   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
+   goto err_disable_pm_runtime;
+   }
+
ret = vop_create_crtc(vop);
if (ret)
-   goto err_enable_irq;
-
-   pm_runtime_enable(>dev);
+   goto err_disable_pm_runtime;
 
return 0;
 
-err_enable_irq:
+err_disable_pm_runtime:
+   pm_runtime_disable(>dev);
enable_irq(vop->irq); /* To balance out the disable_irq above */
return ret;
 }
-- 
2.1.4


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

Re: Heavy artifacts during hw accelerated playback of wmv files

[Jan Burgmeier]

Hi,

the error only occurs with wmv, h264 works.

I created a bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=100510

Regards,
Jan

On Fri, 2017-03-31 at 09:13 +0200, Christian König wrote:
> Hi Jan,
> 
> very interesting. Sounds like we somehow mess up the buffer placement
> so 
> that it won't work any more with UVD.
> 
> But this only happens with WMV files? Not with H264 or anything else?
> 
> Anyway please open up a bug report on https://bugs.freedesktop.org/.
> 
> Thanks,
> Christian.
> 
> Am 30.03.2017 um 14:16 schrieb Jan Burgmeier:
> > Hi,
> > 
> > with versions newer than libdrm-2.4.66 I have heavy artifacts
> > during hw
> > accelerated playback of wmv files vaapi/vdpau tested with
> > gstreamer-
> > 0.10 and ffmpeg based mpv.
> > 
> > Bisect result:
> > db138b9ba12a0de5d6140832c0679c2418e3e7e0 is the first bad commit
> > commit db138b9ba12a0de5d6140832c0679c2418e3e7e0
> > Author: Michel Dänzer 
> > Date:   Thu Jan 21 18:08:49 2016 +0900
> > 
> >  radeon: Pass radeon_bo_open flags to the
> > DRM_RADEON_GEM_CREATE   
> > ioctl
> >  
> >  Not doing so makes it impossible for radeon_bo_open callers to
> > set
> > any
> >  RADEON_GEM_* flags for the newly created BO.
> >  
> >  Reviewed-by: Alex Deucher 
> > 
> > If I revert this commit on the current master branch the artefacts
> > are
> > gone.
> > 
> > System environment:
> > -- chipset: AMD GX-217GA SOC with Radeon(tm) HD Graphics
> > -- system architecture: 32-bit
> > -- xserver: 1.19.1
> > -- mesa: 13.0.3, 13.0.6, 17.0.2
> > -- libdrm: 2.4.74
> > -- kernel: 4.4.11
> > -- Linux distribution: eLux
> > -- Machine or mobo model: HP t620 dual core thin client
> > 
> > Regards,
> > Jan Burgmeier
> > ___
> > 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/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> > > Hi Russell,
> > > 
> > > You were Cc-ed in a patch from March 8th that did all this:
> > > 
> > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html
> > 
> > I'm aware of that (you may notice that this was threaded to that patch.)
> > 
> > > I have not received any response from you, so I have already pushed the
> > > patch in my public repo:
> > > 
> > > git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> > > 
> > > It has been included into linux-next for at least a couple of weeks now.
> > 
> > I've not had a chance to test any of this, but I believe that your
> > patch does not fully address the issue, due to bits missing from
> > the validation path.
> 
> Care to point out which bits were missing from my patch that are in yours?

The visible check?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Dan MacDonald]

No such luck.

The patch I used (against 4.11-rc4) is attached.

The error was:

SHIPPED arch/arm/boot/compressed/bswapsdi2.S
  AS  arch/arm/boot/compressed/bswapsdi2.o
  LD  arch/arm/boot/compressed/vmlinux
  OBJCOPY arch/arm/boot/zImage
  Kernel: arch/arm/boot/zImage is ready
  Building modules, stage 2.
  MODPOST 3341 modules
ERROR: "ipu_plane_disable_deferred" [drivers/gpu/drm/imx/imxdrm.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:91: __modpost] Error 1
make: *** [Makefile:1200: modules] Error 2
==> ERROR: A failure occurred in build().
Aborting...


On Sat, Apr 1, 2017 at 1:26 AM, Dan MacDonald  wrote:
> Thanks Russell!
>
> I think the patch has applied OK - I've just started the build so it
> could be a while yet. 12 hours maybe? Its building support for every
> arm7 thing under the sun because I'm too lazy (sensible?) to try
> hacking it down to size.
>
> Adding the patch to the Arch rc kernel PKGBUILD was as simple as
> adding the name of the patch to the source() section, adding a
> corresponding 'SKIP' to the end of the md5sums() section and then
> adding:
>
>  git apply ../sabre-lite.patch
>
> to the prepare() section of the PKGBUILD. I copied the patch into the
> same dir as the PKGBUILD and then ran:
>
> $ makepkg
>
> In the same dir as the kernel PKGBUILD and patches.
>
> Results at last! :D
>
> On Fri, Mar 31, 2017 at 3:15 PM, Russell King - ARM Linux
>  wrote:
>> On Fri, Mar 31, 2017 at 02:36:31PM +0100, Dan MacDonald wrote:
>>> Hi all
>>>
>>> Up until now I've only ever used the most basic features of git, so
>>> I've had to do some research into how to best/cleanly extract
>>> Phillipps patches so that I can include his changes into an Arch
>>> kernel PKGBUILD.
>>>
>>> I think the following should work:
>>>
>>> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>> cd linux
>>> git fetch https://git.pengutronix.de/git/pza/linux.git
>>> tags/v4.10-ipu-dp-plane-fix
>>> git checkout FETCH_HEAD
>>> git whatchanged -p origin/master..FETCH_HEAD > sabre-lite.patch
>>
>> I don't think that will work, because it'll output the changes as
>> individual patches in reverse order (newest first) which will be
>> no good when trying to feed it into patch or git apply.
>>
>> I think what you instead want is:
>>
>>   git diff origin/master...FETCH_HEAD > sabre-lite.patch
>>
>> which will be the changes that are in FETCH_HEAD that aren't in
>> origin/master as a single patch.
>>
>>> I should then be able to include that patch in a 4.11-rc4 PKGBUILD -
>>> I'll give it a go this weekend and see if it applies and builds OK but
>>> please let me know if anyone sees any flaws in this procedure.
>>
>> Thanks - one of the issues is that not everyone knows the details of
>> distribution package build systems (each distro seems to have their
>> own unique way of building and packaging stuff.)
>>
>> --
>> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
>> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
>> according to speedtest.net.
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
index 33404295b447..b07499214c72 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "imx-drm.h"
+#include "ipuv3-plane.h"
 
 #define MAX_CRTC	4
 
@@ -160,6 +161,9 @@ static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
 static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
 {
 	struct drm_device *dev = state->dev;
+	struct drm_plane *plane;
+	struct drm_plane_state *plane_state;
+	int i;
 
 	drm_atomic_helper_commit_modeset_disables(dev, state);
 
@@ -169,10 +173,13 @@ static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
 
 	drm_atomic_helper_commit_modeset_enables(dev, state);
 
-	drm_atomic_helper_commit_hw_done(state);
-
 	drm_atomic_helper_wait_for_vblanks(dev, state);
 
+	for_each_plane_in_state(state, plane, plane_state, i)
+		ipu_plane_disable_deferred(plane);
+
+	drm_atomic_helper_commit_hw_done(state);
+
 	drm_atomic_helper_cleanup_planes(dev, state);
 }
 
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 6be515a9fb69..0f15f11f26e0 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -60,6 +60,26 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
 	ipu_di_enable(ipu_crtc->di);
 }
 
+static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc,
+struct drm_crtc_state *old_crtc_state)
+{
+	bool disable_partial = false;
+	bool disable_full = false;
+	struct drm_plane *plane;
+
+	drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
+		if (plane == _crtc->plane[0]->base)
+			disable_full = true;
+		if (_crtc->plane[1] && plane == _crtc->plane[1]->base)
+			disable_partial = true;
+	}
+
+	if (disable_partial)
+		ipu_plane_disable(ipu_crtc->plane[1], 

[PATCH v2 0/9] drm: rockchip: Fix rockchip drm unbind crash error

[Jeffy Chen]

Verified on rk3399 chromebook kevin:
1/ stop ui && pkill -9 frecon
2/ unbind/bind drm

Changes in v2:
Fix some commit messages.

Jeffy Chen (9):
  drm: bridge: analogix: Detach panel when unbinding analogix dp
  drm: bridge: analogix: Unregister dp aux when unbinding
  drm: bridge: analogix: Destroy connector when unbinding
  drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
  drm/rockchip: vop: Enable pm domain when resetting vop
  drm/rockchip: Reoder unload sequence
  drm/rockchip: Force disable all crtc when unload
  drm/rockchip: gem: Don't alloc/free gem buf before drm dev registered
  drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 10 ---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  7 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  8 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 31 +++---
 5 files changed, 44 insertions(+), 16 deletions(-)

-- 
2.1.4


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

[PATCH v2 3/9] drm: bridge: analogix: Destroy connector when unbinding

[Jeffy Chen]

Normally we do this in drm_mode_config_cleanup. But analogix dp's
connector is allocated in bind, and freed after unbind. So we need
to destroy it in unbind to avoid further access.

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ec47fc2..084ee8f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1439,6 +1439,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
analogix_dp_bridge_disable(dp->bridge);
+   dp->connector.funcs->destroy(>connector);
 
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
-- 
2.1.4


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

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote:
> The calculation of the framebuffer's start address was wrongly using
> the CRTC's x and y position rather than the one of the source
> framebuffer. To fix that we need to update the plane_check code to
> call drm_plane_helper_check_state() to clip the src and dst coordinates.
> While there so some minor cleanup of redundant freeing of
> devm_alloc-ated memory.

The following series is what I came up with, although I've had no time
to test it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/arm: hdlcd: check for rotation

[Russell King]

hdlcd does not support rotation - check for it and reject plane updates
that try to rotate a plane.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index cf70184fd028..171acc842368 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -215,6 +215,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
*plane,
if (!crtc)
return 0;
 
+   /* We do not support rotation */
+   if (state->rotation != DRM_ROTATE_0)
+   return -EINVAL;
+
crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
if (!crtc_state->enable)
return -EINVAL;
-- 
2.7.4

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

[PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King]

The hdlcd crtc is unable to place planes in arbitary positions and sizes
within the active area.  Use drm_plane_helper_check_state() to validate
the requested state.

Suggested-by: Daniel Vetter 
Signed-off-by: Russell King 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 7d4e5aa77195..ba68fa2b5701 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -205,13 +206,30 @@ static const struct drm_crtc_helper_funcs 
hdlcd_crtc_helper_funcs = {
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
 {
-   u32 src_w, src_h;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   struct drm_rect clip = { 0 };
+   int ret;
+
+   crtc = state->crtc;
+   if (!crtc)
+   return 0;
 
-   src_w = state->src_w >> 16;
-   src_h = state->src_h >> 16;
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+   if (!crtc_state->enable)
+   return -EINVAL;
+
+   clip.x2 = crtc_state->adjusted_mode.hdisplay;
+   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+
+   ret = drm_plane_helper_check_state(state, ,
+  DRM_PLANE_HELPER_NO_SCALING,
+  DRM_PLANE_HELPER_NO_SCALING,
+  false, true);
+   if (ret)
+   return ret;
 
-   /* we can't do any scaling of the plane source */
-   if ((src_w != state->crtc_w) || (src_h != state->crtc_h))
+   if (!state->visible)
return -EINVAL;
 
return 0;
-- 
2.7.4

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

[PATCH 2/9] drm: bridge: analogix: Unregister dp aux when unbinding

[Jeffy Chen]

The dp aux is registered when binding analogix dp.

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a3db290..ec47fc2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1447,6 +1447,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
DRM_ERROR("failed to detach the panel\n");
}
 
+   drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
2.1.4


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

[PATCH 0/4] drm: Add mode resource leasing

[Keith Packard]

Here's a first cut of the proposed mode resource leasing code. What
this does is allow an application to create a new drm_master which
"leases" resources from an existing drm_master. This new drm_master
can do whatever it likes with the resources it was granted, including
setting modes, performing page_flip operations etc.

This can be used to run multiple compositors on the same GPU, each
driving its own set of outputs. Examples of this include multi-user
setups and virtual reality environments.

Because setting modes can consume 'hidden' resources within the GPU,
it isn't entirely clear that letting multiple processes perform mode
setting is a good idea or not. A process doing the usual
test/render/commit sequence may find that the commit fails because
some other process consumed necessary resources after the test was
invoked. Daniel Vetter suggested that perhaps some kind of locking
mechanism across this sequence might help, but that can lead to
problems when a process fails to unlock. If someone wants to come up
with a reasonable scheme here, that'd be great.

For now, I'll be working on the assumption that the lease holder will
not set any modes, which will avoid the problematic case described above.

The series is broken into four patches in an attempt to make review a
bit easier.

The trickiest bit of the code was in creating the new drm_master,
which involved allocating a new file and fd and getting those
initialized with the right reference counts on all of the related data
structures. It "seems" to work, but it would be nice if someone with
more experience in that part of the kernel could take a look at
it. That's in the fourth patch.

The third patch hooks the lease checks into the other ioctls; that
could use some review to make sure I didn't miss any needed checks.

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

[PATCH v2 1/9] drm: bridge: analogix: Detach panel when unbinding analogix dp

[Jeffy Chen]

The panel is attached when binding analogix dp.

Signed-off-by: Jeffy Chen 
---

Changes in v2:
Fix some commit messages.

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e7cd105..a3db290 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1443,6 +1443,8 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
DRM_ERROR("failed to turnoff the panel\n");
+   if (drm_panel_detach(dp->plat_data->panel))
+   DRM_ERROR("failed to detach the panel\n");
}
 
pm_runtime_disable(dev);
-- 
2.1.4


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

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 03:39:20PM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote:
> > Comments are welcome. I'd like to get this in for the 4.12 kernel as
> > this is a missing piece needed to integrate CEC drivers.
> 
> First two patches seem fine, and work with dw-hdmi.
> 
> I'll hold dw-hdmi off until after 4.11 - I currently have this stuff
> merged against 4.10, and there's some conflicts with 4.11.
> 
> I also wanted to say that tda998x/tda9950 works, and send you those
> patches, but while trying to test them this afternoon in a tree with
> some of the DRM code that was merged during the last merge window on
> a v4.10 based tree (which I need because of etnaviv), the kernel
> oopses in DRM for god-knows-why.  If/when I get this sorted (don't
> know when) I'll send that stuff as a follow-up to your series.

... and that's looking impossible - the next problem after that seems
to be that the rootfs drive for the box has failed, so I've currently
no way to test tda998x stuff until I get a new drive, filesystem and
so forth rebuilt.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm: Add new LEASE debug level

[Keith Packard]

Separate out lease debugging from the core.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_drv.c | 3 ++-
 include/drm/drmP.h| 4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 6594b4088f11..d4a3612655e3 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -57,7 +57,8 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
 "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
 "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
-"\t\tBit 5 (0x20) will enable VBL messages (vblank code)");
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
+"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)");
 module_param_named(debug, drm_debug, int, 0600);
 
 static DEFINE_SPINLOCK(drm_minor_lock);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9c4ee144b5f6..304a22c87999 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -137,6 +137,7 @@ struct dma_buf_attachment;
 #define DRM_UT_ATOMIC  0x10
 #define DRM_UT_VBL 0x20
 #define DRM_UT_STATE   0x40
+#define DRM_UT_LEASE   0x80
 
 /***/
 /** \name DRM template customization defaults */
@@ -251,6 +252,9 @@ struct dma_buf_attachment;
 #define DRM_DEBUG_VBL(fmt, ...)\
drm_printk(KERN_DEBUG, DRM_UT_VBL, fmt, ##__VA_ARGS__)
 
+#define DRM_DEBUG_LEASE(fmt, ...)  \
+   drm_printk(KERN_DEBUG, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+
 #define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, level, fmt, args...)\
 ({ \
static DEFINE_RATELIMIT_STATE(_rs,  \
-- 
2.11.0

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

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote:
> On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote:
> > > The calculation of the framebuffer's start address was wrongly using
> > > the CRTC's x and y position rather than the one of the source
> > > framebuffer. To fix that we need to update the plane_check code to
> > > call drm_plane_helper_check_state() to clip the src and dst coordinates.
> > > While there so some minor cleanup of redundant freeing of
> > > devm_alloc-ated memory.
> > 
> > The following series is what I came up with, although I've had no time
> > to test it.
> 
> I'm afraid I'm going to NAK this series. It would've been nicer for you to
> comment on the v2 patch that I have sent rather than going around and coming
> back with effectively the same thing but split into 2 patches. I'm having
> trouble applying your series to the v4.11-rc4 (specially 2/3). Also 3/3 is
> superfluous, as we don't expose the DRM_ROTATE property to userspace.

Rather than throwing accusations, let's look at what happened.

I reported the bug on 18th November 2016 - I quote:

   Something I also noticed is this:

scanout_start = gem->paddr + plane->state->fb->offsets[0] +
plane->state->crtc_y * plane->state->fb->pitches[0] +
plane->state->crtc_x * bpp / 8;

   Surely this should be using src_[xy] (which are the position in the
   source - iow, memory, and not crtc_[xy] which is the position on the
   CRTC displayed window.  To put it another way, the src_* define the
   region of the source material that is mapped onto a rectangular area
   on the display defined by crtc_*.

This got ignored, and on 21st November, I came up with an initial patch
to solve it at the time, but we were busy discussing the base address
issue.

I sent a reminder on 20th February about it, and we discussed it, and I
said at the time I did not have time to test your patch.  Ville commented
on your patch, which confused me a little, but having worked it out, I
reworked the patch from 21st November to fix that, creating this patch
series.

I did not post it, because I hadn't tested it (since the Juno requires
a long-winded way to update the kernel), so I never got around to
testing this.  So, this series pre-dates your v2 patch by a good few
weeks.

You posted your v2 patch on March 8th, and I've not had a chance to
test that, nor have I had a chance to test my own three patch series.

Today, I noticed that I still had the three patch series, so I thought
I ought to get it out in the wild.

Now, due to the amount of patches I carry:

$ git lg origin.. | wc -l
491

I work against Linus' tree _only_, so all patches I post are based on
Linus' kernel, and not random other git trees.  I do not randomly fetch
other git trees to base patches on them, because that would cause me
insane merging issues so that I can test half the stuff I'm carrying.

Now, it's true that they're not against -rc, but are currently against
4.10 - it seems that I missed rebasing _this_ particular branch to
4.11-rc yet, although most of my other branches are.

What was I so busy with when you posted your patch on the 8th March?
Oh yes, that was the week _after_ the merge window closed, and was the
week I was doing the mass rebase of about 500 patches.

Sorry I didn't get around to testing your patch, and sorry for eventually
getting around to posting my patches.  Obviously, I should just fuck off
and do something else.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv6 01/10] media: add CEC notifier support

[Russell King - ARM Linux]

On Sat, Apr 01, 2017 at 11:22:03AM +0200, Hans Verkuil wrote:
> On 31/03/17 22:46, Russell King - ARM Linux wrote:
> > On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote:
> >> +struct cec_notifier *cec_notifier_get(struct device *dev)
> >> +{
> >> +  struct cec_notifier *n;
> >> +
> >> +  mutex_lock(_notifiers_lock);
> >> +  list_for_each_entry(n, _notifiers, head) {
> >> +  if (n->dev == dev) {
> >> +  mutex_unlock(_notifiers_lock);
> >> +  kref_get(>kref);
> > 
> > Isn't this racy?  What stops one thread trying to get the notifier
> > while another thread puts the notifier?
> > 
> 
> Both get and put take the global cec_notifiers_lock mutex.

No, that doesn't help:

Thread 0Thread 1
mutex_lock()
list_for_each_entry()
if()
mutex_unlock()
mutex_lock()
kref_put()
list_del()
kfree()
mutex_unlock()
kref_get()

So, it's possible that kref_get() can be called on kfree'd memory.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/arm: hdlcd: fix plane base address calculation

[Russell King]

The plane base address needs to be calculated using the source
coordinates to position the source correctly - it's possible to have
a larger source buffer than the CRTC size, and have several CRTCs
reading from different parts of the buffer.

In such a case, the pitch may be larger, and we will use the source
position to select an area of the buffer to scan out.

In order for this to work correctly, we need to also fix the atomic
check to do a fuller validation of the new state.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index ba68fa2b5701..cf70184fd028 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -240,21 +240,19 @@ static void hdlcd_plane_atomic_update(struct drm_plane 
*plane,
 {
struct hdlcd_drm_private *hdlcd;
struct drm_gem_cma_object *gem;
-   u32 src_w, src_h, dest_w, dest_h;
+   u32 src_x, src_y, dest_h;
dma_addr_t scanout_start;
 
if (!plane->state->fb)
return;
 
-   src_w = plane->state->src_w >> 16;
-   src_h = plane->state->src_h >> 16;
-   dest_w = plane->state->crtc_w;
-   dest_h = plane->state->crtc_h;
gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
+   src_x = plane->state->src_x >> 16;
+   src_y = plane->state->src_y >> 16;
+   dest_h = plane->state->crtc_h;
scanout_start = gem->paddr + plane->state->fb->offsets[0] +
-   plane->state->crtc_y * plane->state->fb->pitches[0] +
-   plane->state->crtc_x *
-   drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
+   src_y * plane->state->fb->pitches[0] +
+   src_x * drm_format_plane_cpp(plane->state->fb->pixel_format, 0);
 
hdlcd = plane->dev->dev_private;
hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, 
plane->state->fb->pitches[0]);
-- 
2.7.4

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

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

[Dan MacDonald]

Hi all

Up until now I've only ever used the most basic features of git, so
I've had to do some research into how to best/cleanly extract
Phillipps patches so that I can include his changes into an Arch
kernel PKGBUILD.

I think the following should work:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
git fetch https://git.pengutronix.de/git/pza/linux.git
tags/v4.10-ipu-dp-plane-fix
git checkout FETCH_HEAD
git whatchanged -p origin/master..FETCH_HEAD > sabre-lite.patch

I should then be able to include that patch in a 4.11-rc4 PKGBUILD -
I'll give it a go this weekend and see if it applies and builds OK but
please let me know if anyone sees any flaws in this procedure.

Thanks


On Wed, Mar 22, 2017 at 10:28 PM, Dan MacDonald  wrote:
> Hi Philipp
>
> I moved house again on Sunday - that is the second time in two months.
> I won't bore you with the details but it means I've not had much time
> to myself recently and why I've not been able to test this patch.
>
> As I was saying previously, the only way I can reliably test this is
> to do it 'the Arch way' by creating a new kernel package with your
> patch rolled in. Doing it that way means I can't directly use your git
> repo in the PKGBUILD but instead we need to create a patch that can be
> applied against
> https://www.kernel.org/pub/linux/kernel/v4.x/testing/linux-4.11-rc3.tar.xz
> which is what is downloaded and patched by the armv7-rc PKGBUILD as
> feched from:
>
> git clone https://github.com/archlinuxarm/PKGBUILDs.git
>
> See the PKGBUILD under core/linux-armv7-rc. There is a short guide on
> how Arch/ABS expects its patches to be formatted here:
>
> https://wiki.archlinux.org/index.php/Patching_in_ABS
>
> I'm surprised I'm the only Arch user on this list - I thought someone
> else would already have a dev kernel PKGBUILD for me but apparently
> not?
>
> If you really don't have time to create a patch against the latest rc
> tarball I can give it a go but I can see me making a royal mess of it!
> :)
>
> Thanks
>
> On Mon, Mar 13, 2017 at 11:11 AM, Philipp Zabel  
> wrote:
>> Hi Dan,
>>
>> On Fri, 2017-03-10 at 11:11 +, Dan MacDonald wrote:
>>> Should your patches work fine under 4.11-rc1 Phillipp or do I need to
>>> test againt the very latest git? I realise that would be preferred.
>>
>> The patches from the v4.10-ipu-dp-plane-fix-2 tag should work under
>> v4.11-rc1, they are applied on top of v4.11-rc1 in the imx-drm/next
>> branch.
>>
>> regards
>> Philipp
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 9/9] drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding

[Jeffy Chen]

In current sound framework, there's no way to unbind dai link after
unregister codec.

So move unregister codec to driver remove for now.

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a97f3f4..1deab9f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1091,8 +1091,6 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
goto err_free_connector;
}
 
-   cdn_dp_audio_codec_init(dp, dev);
-
for (i = 0; i < dp->ports; i++) {
port = dp->port[i];
 
@@ -1127,7 +1125,6 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
struct drm_connector *connector = >connector;
 
cancel_work_sync(>event_work);
-   platform_device_unregister(dp->audio_pdev);
cdn_dp_encoder_disable(encoder);
encoder->funcs->destroy(encoder);
connector->funcs->destroy(connector);
@@ -1220,6 +1217,8 @@ static int cdn_dp_probe(struct platform_device *pdev)
mutex_init(>lock);
dev_set_drvdata(dev, dp);
 
+   cdn_dp_audio_codec_init(dp, dev);
+
return component_add(dev, _dp_component_ops);
 }
 
@@ -1227,6 +1226,7 @@ static int cdn_dp_remove(struct platform_device *pdev)
 {
struct cdn_dp_device *dp = platform_get_drvdata(pdev);
 
+   platform_device_unregister(dp->audio_pdev);
cdn_dp_suspend(dp->dev);
component_del(>dev, _dp_component_ops);
 
-- 
2.1.4


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

[PATCH] dma-buf: align debugfs output

[Russell King]

Align the heading with the values output from debugfs.

Signed-off-by: Russell King 
---
 drivers/dma-buf/dma-buf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ebaf1923ad6b..f72aaacbe023 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1072,7 +1072,8 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
return ret;
 
seq_puts(s, "\nDma-buf Objects:\n");
-   seq_puts(s, "size\tflags\tmode\tcount\texp_name\n");
+   seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\n",
+  "size", "flags", "mode", "count");
 
list_for_each_entry(buf_obj, _list.head, list_node) {
ret = mutex_lock_interruptible(_obj->lock);
-- 
2.7.4

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

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote:
> Hi Russell,
> 
> You were Cc-ed in a patch from March 8th that did all this:
> 
> https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html

I'm aware of that (you may notice that this was threaded to that patch.)

> I have not received any response from you, so I have already pushed the
> patch in my public repo:
> 
> git://linux-arm.org/linux-ld.git for-upstream/hdlcd
> 
> It has been included into linux-next for at least a couple of weeks now.

I've not had a chance to test any of this, but I believe that your
patch does not fully address the issue, due to bits missing from
the validation path.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/9] drm/rockchip: gem: Don't alloc/free gem buf before drm dev registered

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

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

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..19679b2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_device *drm = obj->dev;
struct rockchip_drm_private *private = drm->dev_private;
 
+   if (!drm->registered)
+   return;
+
if (private->domain)
return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
else
@@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct 
rockchip_gem_object *rk_obj)
 
 static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
 {
+   struct drm_device *drm = rk_obj->base.dev;
+
+   if (!drm->registered)
+   return;
+
if (rk_obj->pages)
rockchip_gem_free_iommu(rk_obj);
else
-- 
2.1.4


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

[PATCH 6/9] drm/rockchip: Reoder unload sequence

[Jeffy Chen]

We should don't cleanup iommu before cleanup other resources.
Reorder unload sequence, follow exynos drm.

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index b360e62..a5d83cb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -244,11 +244,13 @@ static void rockchip_drm_unbind(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
 
rockchip_drm_fbdev_fini(drm_dev);
-   drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
+
+   drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
-   rockchip_iommu_cleanup(drm_dev);
drm_mode_config_cleanup(drm_dev);
+   rockchip_iommu_cleanup(drm_dev);
+
drm_dev->dev_private = NULL;
drm_dev_unregister(drm_dev);
drm_dev_unref(drm_dev);
-- 
2.1.4


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

[PATCH v2 4/9] drm/rockchip: cdn-dp: Don't try to release firmware when not loaded

[Jeffy Chen]

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index fd79a70..a97f3f4 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1052,6 +1052,7 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->connected = false;
dp->active = false;
dp->active_port = -1;
+   dp->fw_loaded = false;
 
INIT_WORK(>event_work, cdn_dp_pd_event_work);
 
@@ -1132,7 +1133,8 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
connector->funcs->destroy(connector);
 
pm_runtime_disable(dev);
-   release_firmware(dp->fw);
+   if (dp->fw_loaded)
+   release_firmware(dp->fw);
kfree(dp->edid);
dp->edid = NULL;
 }
-- 
2.1.4


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

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

[Russell King - ARM Linux]

On Fri, Mar 31, 2017 at 02:36:31PM +0100, Dan MacDonald wrote:
> Hi all
> 
> Up until now I've only ever used the most basic features of git, so
> I've had to do some research into how to best/cleanly extract
> Phillipps patches so that I can include his changes into an Arch
> kernel PKGBUILD.
> 
> I think the following should work:
> 
> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> cd linux
> git fetch https://git.pengutronix.de/git/pza/linux.git
> tags/v4.10-ipu-dp-plane-fix
> git checkout FETCH_HEAD
> git whatchanged -p origin/master..FETCH_HEAD > sabre-lite.patch

I don't think that will work, because it'll output the changes as
individual patches in reverse order (newest first) which will be
no good when trying to feed it into patch or git apply.

I think what you instead want is:

  git diff origin/master...FETCH_HEAD > sabre-lite.patch

which will be the changes that are in FETCH_HEAD that aren't in
origin/master as a single patch.

> I should then be able to include that patch in a 4.11-rc4 PKGBUILD -
> I'll give it a go this weekend and see if it applies and builds OK but
> please let me know if anyone sees any flaws in this procedure.

Thanks - one of the issues is that not everyone knows the details of
distribution package build systems (each distro seems to have their
own unique way of building and packaging stuff.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/9] drm/rockchip: Reoder unload sequence

[Jeffy Chen]

We should not cleanup iommu before cleanup other resources.

Reorder unload sequence, follow exynos drm.

Signed-off-by: Jeffy Chen 
---

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index b360e62..a5d83cb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -244,11 +244,13 @@ static void rockchip_drm_unbind(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
 
rockchip_drm_fbdev_fini(drm_dev);
-   drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
+
+   drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
-   rockchip_iommu_cleanup(drm_dev);
drm_mode_config_cleanup(drm_dev);
+   rockchip_iommu_cleanup(drm_dev);
+
drm_dev->dev_private = NULL;
drm_dev_unregister(drm_dev);
drm_dev_unref(drm_dev);
-- 
2.1.4


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

Re: [PATCH] drm/i915: fix build error without CONFIG_BACKLIGHT_CLASS_DEVICE

[Tobias Regnery]

On 30.03.17, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Tobias Regnery  wrote:
> > With CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=n we see the following
> > link error in the i915 driver:
> >
> > drivers/built-in.o: In function 'intel_backlight_device_register':
> > (.text+0x2a921d): undefined reference to 'backlight_device_register'
> >
> > Fix this by removing the condition on ACPI from the appropriate select
> > statement.
> 
> The right fix for the build problem is to add empty stub functions for
> BACKLIGHT_CLASS_DEVICE=n in include/linux/backlight.h. I'm frankly
> surprised nobody's done that yet.

Thanks for the advice, I will try to come up with a patch.

--
Tobias

> 
> It's another question whether we should support and select backlight for
> ACPI=n, and yet another question whether we should support ACPI=n.
> 
> Also, selecting BACKLIGHT_CLASS_DEVICE is fundamentally broken, but
> people aren't interested [1].
> 
> 
> BR,
> Jani.
> 
> [1] 
> http://mid.mail-archive.com/1413580403-16225-1-git-send-email-jani.nikula@intel.com
> 
> >
> > Signed-off-by: Tobias Regnery 
> > ---
> >  drivers/gpu/drm/i915/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> > index a5cd5dacf055..532df4bb9283 100644
> > --- a/drivers/gpu/drm/i915/Kconfig
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -15,7 +15,7 @@ config DRM_I915
> > # i915 depends on ACPI_VIDEO when ACPI is enabled
> > # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> > select BACKLIGHT_LCD_SUPPORT if ACPI
> > -   select BACKLIGHT_CLASS_DEVICE if ACPI
> > +   select BACKLIGHT_CLASS_DEVICE
> > select INPUT if ACPI
> > select ACPI_VIDEO if ACPI
> > select ACPI_BUTTON if ACPI
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] virtio: wrap find_vqs

[Jason Wang]

On 2017年03月30日 22:32, Michael S. Tsirkin wrote:

On Thu, Mar 30, 2017 at 02:00:08PM +0800, Jason Wang wrote:


On 2017年03月30日 04:48, Michael S. Tsirkin wrote:

We are going to add more parameters to find_vqs, let's wrap the call so
we don't need to tweak all drivers every time.

Signed-off-by: Michael S. Tsirkin
---

A quick glance and it looks ok, but what the benefit of this series, is it
required by other changes?

Thanks

Yes - to avoid touching all devices when doing the rest of
the patchset.


Maybe I'm not clear. I mean the benefit of this series not this single 
patch. I guess it may be used by you proposal that avoid reset when set 
XDP? If yes, do we really want to drop some packets after XDP is set?


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

[RFC] drm: atomic-rmfb semantics

[Rob Clark]

We possibly missed the boat on redefining rmfb semantics for atomic
userspace to something more sane, unless perhaps the few existing atomic
userspaces (CrOS?) could confirm that this change won't cause problems
(in which case we could just call this a bug-fix, drop the cap, and
delete some code?).

The old semantics of rmfb shutting down the display is kind of pointless
in an atomic world, and it is more awkward for userspace that creates
and destroys the fb every frame, since they need to defer the rmfb.
Since we have better ways for userspace to shut down the display pipe
and the legacy behaviour of rmfb is awkward, provide a way for atomic
userspace to simply make rmfb an unref.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_framebuffer.c | 2 +-
 drivers/gpu/drm/drm_ioctl.c   | 9 +
 include/drm/drm_file.h| 8 
 include/uapi/drm/drm.h| 7 +++
 4 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index e4909ae..c5127dd0 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -383,7 +383,7 @@ int drm_mode_rmfb(struct drm_device *dev,
 * so run this in a separate stack as there's no way to correctly
 * handle this after the fb is already removed from the lookup table.
 */
-   if (drm_framebuffer_read_refcount(fb) > 1) {
+   if (drm_framebuffer_read_refcount(fb) > 1 && !file_priv->atomic_rmfb) {
struct drm_mode_rmfb_work arg;
 
INIT_WORK_ONSTACK(, drm_mode_rmfb_work_fn);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index a7c61c2..b42348f 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -318,6 +318,15 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ATOMIC_RMFB:
+   if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+   return -EINVAL;
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->atomic = req->value;
+   file_priv->universal_planes = req->value;
+   file_priv->atomic_rmfb = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 5dd27ae..2a41c29 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -181,6 +181,14 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @atomic_rmfb:
+*
+* True if client wants new semantics for rmfb, ie. simply dropping
+* refcnt without tearing down the display.
+*/
+   unsigned atomic_rmfb:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b2c5284..4063cc8 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -678,6 +678,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ATOMIC_RMFB
+ *
+ * If set to 1, the DRM core will not shutdown display pipe on rmfb ioctl.
+ */
+#define DRM_CLIENT_CAP_ATOMIC_RMFB 4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.9.3

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

Re: [PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Rob Clark]

On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
 wrote:
> From: "Kristian H. Kristensen" 
>
> This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning
> information about the modifiers that will work with each format.

So, just to toss out a completely different idea..

What if instead of a new ioctl, we had a read-only blob property
(which encoded the info basically the same way, plus the fourcc's)?

If we do writeback via some sort of OUT_FB_ID property on plane/crtc,
we will need the same sort of format information so userspace knows
what output formats (and modifiers) are supported.  So re-using the
same blob property layout (and userspace parsing) seems useful.

BR,
-R

> Signed-off-by: Kristian H. Kristensen 
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
>  drivers/gpu/drm/armada/armada_crtc.c|  1 +
>  drivers/gpu/drm/armada/armada_overlay.c |  1 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 ++-
>  drivers/gpu/drm/drm_ioctl.c |  2 +-
>  drivers/gpu/drm/drm_modeset_helper.c|  1 +
>  drivers/gpu/drm/drm_plane.c | 40 
> +++--
>  drivers/gpu/drm/drm_simple_kms_helper.c |  5 
>  drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
>  drivers/gpu/drm/i915/intel_display.c|  5 +++-
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  4 +--
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
>  drivers/gpu/drm/nouveau/nv50_display.c  |  5 ++--
>  drivers/gpu/drm/omapdrm/omap_plane.c|  3 +-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 +--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
>  drivers/gpu/drm/sti/sti_cursor.c|  1 +
>  drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
>  drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
>  drivers/gpu/drm/tegra/dc.c  | 12 
>  drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
>  include/drm/drm_plane.h |  7 -
>  include/drm/drm_simple_kms_helper.h |  2 ++
>  include/uapi/drm/drm.h  |  1 +
>  include/uapi/drm/drm_mode.h | 27 +
>  27 files changed, 116 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 20ebfb4..6062578 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -283,6 +283,7 @@ static struct drm_plane *hdlcd_plane_init(struct 
> drm_device *drm)
>
> ret = drm_universal_plane_init(drm, plane, 0xff, _plane_funcs,
>formats, ARRAY_SIZE(formats),
> +  NULL, 0,
>DRM_PLANE_TYPE_PRIMARY, NULL);
> if (ret) {
> devm_kfree(drm->dev, plane);
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index e62ee44..e1a6170 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -1250,6 +1250,7 @@ static int armada_drm_crtc_create(struct drm_device 
> *drm, struct device *dev,
>_primary_plane_funcs,
>armada_primary_formats,
>ARRAY_SIZE(armada_primary_formats),
> +  NULL, 0,
>DRM_PLANE_TYPE_PRIMARY, NULL);
> if (ret) {
> kfree(primary);
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index 34cb73d..32fb8f3 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -458,6 +458,7 @@ int armada_overlay_plane_create(struct drm_device *dev, 
> unsigned long crtcs)
>_ovl_plane_funcs,
>armada_ovl_formats,
>ARRAY_SIZE(armada_ovl_formats),
> +  NULL, 0,
>DRM_PLANE_TYPE_OVERLAY, NULL);
> if (ret) {
> kfree(dplane);
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index bd2791c..ac9e4db 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -1038,7 +1038,9 @@ atmel_hlcdc_plane_create(struct drm_device *dev,
> ret = drm_universal_plane_init(dev, >base, 0,
>_plane_funcs,
> 

[Bug 97861] [amdgpu SI] purple line is visible on left side of the screen connected by HDMI

[bugzilla-daemon]

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

--- Comment #9 from jerry.fl...@gmail.com ---
Created attachment 130634
  --> https://bugs.freedesktop.org/attachment.cgi?id=130634=edit
dmesg | grep amdpro

-- 
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 97861] [amdgpu SI] purple line is visible on left side of the screen connected by HDMI

[bugzilla-daemon]

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

jerry.fl...@gmail.com changed:

   What|Removed |Added

 CC||jerry.fl...@gmail.com

--- Comment #8 from jerry.fl...@gmail.com ---
Same issue.  Running 3 monitor set up. 1 monitor HDMI, one monitor HDMI cable
plugged into a DP adapter and one DVI.  Two using the HDMI out have the purple
line, DVI is fine.

-- 
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 100400] Game Valhalla Hills crash on startup

[bugzilla-daemon]

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

--- Comment #9 from beham.christop...@gmx.at ---
Created attachment 130633
  --> https://bugs.freedesktop.org/attachment.cgi?id=130633=edit
valgrind output with less missing debug info

Because I saw there is very much missing debug info in the first valgrind file
I recompiled the affected libs with debug symbols.

The new valgrind file was generated with this line:

ST_DEBUG=tgsi MESA_DEBUG=1 LIBGL_DEBUG=verbose valgrind --leak-check=full
--show-leak-kinds=all --track-origins=yes --error-limit=no
./ValhallaHills-Linux-Shipping

-- 
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: [PATCHv6 01/10] media: add CEC notifier support

[Hans Verkuil]

On 01/04/17 11:39, Russell King - ARM Linux wrote:
> On Sat, Apr 01, 2017 at 11:22:03AM +0200, Hans Verkuil wrote:
>> On 31/03/17 22:46, Russell King - ARM Linux wrote:
>>> On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote:
 +struct cec_notifier *cec_notifier_get(struct device *dev)
 +{
 +  struct cec_notifier *n;
 +
 +  mutex_lock(_notifiers_lock);
 +  list_for_each_entry(n, _notifiers, head) {
 +  if (n->dev == dev) {
 +  mutex_unlock(_notifiers_lock);
 +  kref_get(>kref);
>>>
>>> Isn't this racy?  What stops one thread trying to get the notifier
>>> while another thread puts the notifier?
>>>
>>
>> Both get and put take the global cec_notifiers_lock mutex.
> 
> No, that doesn't help:
> 
> Thread 0  Thread 1
> mutex_lock()
> list_for_each_entry()
> if()
> mutex_unlock()
>   mutex_lock()
>   kref_put()
>   list_del()
>   kfree()
>   mutex_unlock()
> kref_get()
> 
> So, it's possible that kref_get() can be called on kfree'd memory.
> 

Sorry, you're right. I completely read over the fact that
mutex_unlock(_notifiers_lock) comes too early.

The mutex_unlock now comes after the kref_get. Thanks for reporting this!

Regards,

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

Re: [PATCHv6 01/10] media: add CEC notifier support

[Hans Verkuil]

On 31/03/17 22:46, Russell King - ARM Linux wrote:
> On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote:
>> +struct cec_notifier *cec_notifier_get(struct device *dev)
>> +{
>> +struct cec_notifier *n;
>> +
>> +mutex_lock(_notifiers_lock);
>> +list_for_each_entry(n, _notifiers, head) {
>> +if (n->dev == dev) {
>> +mutex_unlock(_notifiers_lock);
>> +kref_get(>kref);
> 
> Isn't this racy?  What stops one thread trying to get the notifier
> while another thread puts the notifier?
> 

Both get and put take the global cec_notifiers_lock mutex.

Regards,

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

Re: [bug report] drm/amdgpu/gfx6: clean up cu configuration

[Flora Cui]

Hi Dan Carpenter,

Thank you for the info. This commit is just a clean up to keep align
with gfx7/8.

On Fri, Mar 31, 2017 at 06:13:25PM +0300, Dan Carpenter wrote:
> Hello Flora Cui,
> 
> The patch 375d6f7057a9: "drm/amdgpu/gfx6: clean up cu configuration"
> from Feb 7, 2017, leads to the following static checker warning:
> 
>   drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3737 gfx_v6_0_get_cu_info()
>   warn: potential off by one cu_info->bitmap[4]
> 
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
>   3715  static void gfx_v6_0_get_cu_info(struct amdgpu_device *adev)
>   3716  {
>   3717  int i, j, k, counter, active_cu_number = 0;
>   3718  u32 mask, bitmap, ao_bitmap, ao_cu_mask = 0;
>   3719  struct amdgpu_cu_info *cu_info = >gfx.cu_info;
>   3720  unsigned disable_masks[4 * 2];
>   3721  
>   3722  memset(cu_info, 0, sizeof(*cu_info));
>   3723  
>   3724  amdgpu_gfx_parse_disable_cu(disable_masks, 4, 2);
>   3725  
>   3726  mutex_lock(>grbm_idx_mutex);
>   3727  for (i = 0; i < adev->gfx.config.max_shader_engines; i++) {
>   3728  for (j = 0; j < adev->gfx.config.max_sh_per_se; j++) {
>   3729  mask = 1;
>   3730  ao_bitmap = 0;
>   3731  counter = 0;
>   3732  gfx_v6_0_select_se_sh(adev, i, j, 0x);
>   3733  if (i < 4 && j < 2)
> 
> If i == 4
> 
>   3734  gfx_v6_0_set_user_cu_inactive_bitmap(
>   3735  adev, disable_masks[i * 2 + 
> j]);
>   3736  bitmap = gfx_v6_0_get_cu_enabled(adev);
>   3737  cu_info->bitmap[i][j] = bitmap;
> 
> then we are beyond the end of this array.  Also, why was this patch even
> applied when it has no commit message?  It's totally not clear to me
> what the patch is trying to do or why it exists...
adev->gfx.config.max_shader_engines is set in gfx_v6_0_gpu_init() and
it must be < 4 so we'll never be beyond the end of the array.

Regards,
Flora Cui
>   3738  
>   3739  for (k = 0; k < 16; k++) {
>   3740  if (bitmap & mask) {
>   3741  if (counter < 2)
>   3742  ao_bitmap |= mask;
>   3743  counter ++;
>   3744  }
>   3745  mask <<= 1;
>   3746  }
>   3747  active_cu_number += counter;
>   3748  ao_cu_mask |= (ao_bitmap << (i * 16 + j * 8));
>   3749  }
>   3750  }
>   3751  
>   3752  gfx_v6_0_select_se_sh(adev, 0x, 0x, 
> 0x);
>   3753  mutex_unlock(>grbm_idx_mutex);
>   3754  
>   3755  cu_info->number = active_cu_number;
>   3756  cu_info->ao_cu_mask = ao_cu_mask;
>   3757  }
> 
> regards,
> dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel