[PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-fixes-2017-02-09:
Last-minute vc4 fix for 4.10.

Cheers, Daniel


The following changes since commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c:

  Linux 4.10-rc7 (2017-02-05 15:10:58 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-02-09

for you to fetch changes up to 49d29a077af8d2ee3b291ccd8d053541bebe09d7:

  drm: vc4: adapt to new behaviour of drm_crtc.c (2017-02-08 14:19:23 -0800)


Last-minute vc4 fix for 4.10.


Andrzej Pietrasiewicz (1):
  drm: vc4: adapt to new behaviour of drm_crtc.c

 drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [PATCH v2 2/5] arm64: dts: exynos: Remove the OF graph from DSI node for exynos5433 dts

[Andrzej Hajda]

On 09.02.2017 02:26, Hoegeun Kwon wrote:
> The OF graph is not needed because the panel is a child of dsi. So
> Remove the ports node and move burst and esc clock frequency
> properties to the parent (DSI node).
>
> Signed-off-by: Hoegeun Kwon 

For the whole patchset:
Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 6ce93a3..77ba238 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -298,23 +298,11 @@
>   status = "okay";
>   vddcore-supply = <_reg>;
>   vddio-supply = <_reg>;
> + samsung,burst-clock-frequency = <51200>;
> + samsung,esc-clock-frequency = <1600>;
>   samsung,pll-clock-frequency = <2400>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_irq>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@1 {
> - reg = <1>;
> -
> - dsi_out: endpoint {
> - samsung,burst-clock-frequency = <51200>;
> - samsung,esc-clock-frequency = <1600>;
> - };
> - };
> - };
>  };
>  
>   {


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

Re: [PATCH v2 1/5] drm/exynos: dsi: Fix the parse_dt function

[Andrzej Hajda]

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

Nice diffstat, more importantly it fixes bad design of early days of
of_graph.

Reviewed-by: Andrzej Hajda 

One comment below.

> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 
>  1 file changed, 8 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index e07cb1f..214d486 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1652,39 +1652,23 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>   if (ret < 0)
>   return ret;
>  
> - ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
> - if (!ep) {
> - dev_err(dev, "no output port with endpoint specified\n");
> - return -EINVAL;
> - }
> -
> - ret = exynos_dsi_of_read_u32(ep, "samsung,burst-clock-frequency",
> + ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
>>burst_clk_rate);
>   if (ret < 0)
> - goto end;
> + return ret;
>  
> - ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
> + ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
>>esc_clk_rate);
>   if (ret < 0)
> - goto end;
> -
> - of_node_put(ep);
> + return ret;
>  
>   ep = of_graph_get_next_endpoint(node, NULL);
> - if (!ep) {
> - ret = -EINVAL;
> - goto end;
> - }
> -
> - dsi->bridge_node = of_graph_get_remote_port_parent(ep);
> - if (!dsi->bridge_node) {
> - ret = -EINVAL;
> - goto end;
> + if (ep) {
> + dsi->bridge_node = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);

It looks like there is no of_node_put on dsi->bridge_node, but this is
for another patch.

Regards
Andrzej

>   }
> -end:
> - of_node_put(ep);
>  
> - return ret;
> + return 0;
>  }
>  
>  static int exynos_dsi_bind(struct device *dev, struct device *master,


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

[Bug 99718] RX480 - MCLK stuck at 300

[bugzilla-daemon]

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

Bug ID: 99718
   Summary: RX480 - MCLK stuck at 300
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: b74...@gmail.com

Created attachment 129417
  --> https://bugs.freedesktop.org/attachment.cgi?id=129417=edit
DMESG

I,

I just found out that the MCLK was stuck at 300Mhz on my Polaris10 card. I got
the card last week, I don't really know if it's new. I have git version of
linux, mesa, libdrm.

I can force the power to high and get the proper 2000Mhz and when I set it back
to auto, it go back down to 300Mhz, halving my EVE-Online fps by about 200%.

The SCLK is normal, It move according to load on auto and move according to
crappy cooling on high.

I got some error in the dmesg too, can be related, or no.., I attach them.

-- 
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 99484] Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly

[bugzilla-daemon]

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

--- Comment #2 from Timothy Arceri  ---
You can see the issue in the progress bar on the main loading screen:

https://drive.google.com/open?id=0B-f68fD4PtpBZmx0M2VPUU1oRms

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

Re: [PATCH] drm/amdgpu: shut up #warning for compile testing

[Alex Deucher]

On Fri, Feb 3, 2017 at 5:15 AM, Michel Dänzer  wrote:
> On 02/02/17 06:36 PM, Christian König wrote:
>> Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
>>> [SNIP]
>>> OTOH the people running the kernel aren't always the same people
>>> building it, so the downside is that this would potentially delay
>>> getting X86_PAT enabled.
>>
>> And exactly for this reason I would rather like to keep the warning.
>
> Right, so let's take the patch as is:
>
> Reviewed-by: Michel Dänzer 
>

Applied.  thanks!

Alex

>
> Arnd, can you make the corresponding patch for radeon as well? Otherwise
> I can probably do it next week.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> 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 05/11] drm/msm: get an iova from the address space instead of an id

[Archit Taneja]

On 02/06/2017 11:09 PM, Jordan Crouse wrote:

In the future we won't have a fixed set of addresses spaces.
Instead of going through the effort of assigning a ID for each
address space just use the address space itself as a token for
getting / putting an iova.

This forces a few changes in the gem object however: instead
of using a simple index into a list of domains, we need to
maintain a list of them. Luckily the list will be pretty small;
even with dynamic address spaces we wouldn't ever see more than
two or three.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |   8 +-
 drivers/gpu/drm/msm/adreno/a5xx_power.c   |   5 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |   6 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c|  15 +++-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c  |   8 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  18 ++---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h   |   3 -
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  13 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c  |   5 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  11 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |   4 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  13 ++--
 drivers/gpu/drm/msm/msm_drv.c |  14 
 drivers/gpu/drm/msm/msm_drv.h |  25 +++---
 drivers/gpu/drm/msm/msm_fb.c  |  15 ++--
 drivers/gpu/drm/msm/msm_fbdev.c   |  10 ++-
 drivers/gpu/drm/msm/msm_gem.c | 124 +-
 drivers/gpu/drm/msm/msm_gem.h |   4 +-
 drivers/gpu/drm/msm/msm_gem_submit.c  |   4 +-
 drivers/gpu/drm/msm/msm_gpu.c |   8 +-
 drivers/gpu/drm/msm/msm_gpu.h |   1 -
 drivers/gpu/drm/msm/msm_kms.h |   3 +
 22 files changed, 184 insertions(+), 133 deletions(-)






diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index e8f41eb..0b5b839 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -20,6 +20,7 @@
 #include "drm_crtc.h"
 #include "drm_fb_helper.h"
 #include "msm_gem.h"
+#include "msm_kms.h"

 extern int msm_gem_mmap_obj(struct drm_gem_object *obj,
struct vm_area_struct *vma);
@@ -78,6 +79,7 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
 {
struct msm_fbdev *fbdev = to_msm_fbdev(helper);
struct drm_device *dev = helper->dev;
+   struct msm_drm_private *priv = dev->dev_private;
struct drm_framebuffer *fb = NULL;
struct fb_info *fbi = NULL;
struct drm_mode_fb_cmd2 mode_cmd = {0};
@@ -129,7 +131,13 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
 * in panic (ie. lock-safe, etc) we could avoid pinning the
 * buffer now:
 */
-   ret = msm_gem_get_iova_locked(fbdev->bo, 0, );
+
+   if (!priv->kms) {
+   ret = -ENODEV;
+   goto fail_unlock;
+   }


This check isn't needed. As of now, we don't create a fbdev device if we don't
have kms initialized.

Otherwise,

Reviewed-by: Archit Taneja 

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: avoid kernel segfault in vce when gpu fails to resume

[Alex Deucher]

On Tue, Feb 7, 2017 at 5:51 AM, Christian König  wrote:
> Am 06.02.2017 um 21:13 schrieb j.gli...@gmail.com:
>>
>> From: Jérôme Glisse 
>>
>> When GPU fails to resume we can not trust that value we write to GPU
>> memory will post and we might get garbage (more like 0x on
>> x86) when reading them back. This trigger out of range memory access
>> in the kernel inside the vce resume code path.
>>
>> This patch use canonical value to compute offset instead of reading
>> back value from GPU memory.
>>
>> Signed-off-by: Jérôme Glisse 

Applied.  Thanks!

Alex

>
>
> Good point, path is Reviewed-by: Christian König .
>
> Regards,
> Christian.
>
>> ---
>>   drivers/gpu/drm/radeon/vce_v1_0.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/vce_v1_0.c
>> b/drivers/gpu/drm/radeon/vce_v1_0.c
>> index a01efe3..f541a4b 100644
>> --- a/drivers/gpu/drm/radeon/vce_v1_0.c
>> +++ b/drivers/gpu/drm/radeon/vce_v1_0.c
>> @@ -196,7 +196,7 @@ int vce_v1_0_load_fw(struct radeon_device *rdev,
>> uint32_t *data)
>> memset([5], 0, 44);
>> memcpy([16], [1], rdev->vce_fw->size - sizeof(*sign));
>>   - data += le32_to_cpu(data[4]) / 4;
>> +   data += (le32_to_cpu(sign->len) + 64) / 4;
>> data[0] = sign->val[i].sigval[0];
>> data[1] = sign->val[i].sigval[1];
>> data[2] = sign->val[i].sigval[2];
>
>
>
> ___
> 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] drm/radeon: remove some dead code

[Alex Deucher]

On Tue, Feb 7, 2017 at 8:16 AM, Dan Carpenter  wrote:
> If "rdev->bios" is NULL then we don't need to free it.
>
> Signed-off-by: Dan Carpenter 

applied.  thanks!

>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c 
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 00cfb5d2875f..04c0ed41374f 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -638,10 +638,8 @@ static bool radeon_acpi_vfct_bios(struct radeon_device 
> *rdev)
>  vhdr->ImageLength,
>  GFP_KERNEL);
>
> -   if (!rdev->bios) {
> -   kfree(rdev->bios);
> +   if (!rdev->bios)
> return false;
> -   }
> return true;
> }
> }
> ___
> 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] drm/amdgpu/virt: fix double kfree on bo_va

[Alex Deucher]

On Fri, Feb 3, 2017 at 3:23 PM, Colin King  wrote:
> From: Colin Ian King 
>
> bo_va is being kfree'd twice, once in the call to amdgpu_vm_bo_rmv
> and then a short while later. Fix this double free by removing
> the 2nd kfree.
>
> Detected by CoverityScan, CID#1399524 ("Double Free")
>
> Signed-off-by: Colin Ian King 

Applied.  thanks!

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 3fd951c..dcfb7df 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -83,7 +83,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, 
> struct amdgpu_vm *vm)
> DRM_ERROR("failed to do bo_map on static CSA, err=%d\n", r);
> amdgpu_vm_bo_rmv(adev, bo_va);
> ttm_eu_backoff_reservation(, );
> -   kfree(bo_va);
> return r;
> }
>
> --
> 2.10.2
>
> ___
> 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: [Intel-gfx] [patch v2] drm/i915/gvt/kvmgt: remove some dead code

[Zhenyu Wang]

On 2017.02.08 14:49:22 +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 17:53 +0300, Dan Carpenter wrote:
> > "caps.buf" is always NULL here and "caps.size" is always zero.  The code
> > is a no-op and can be removed.
> > 
> > Signed-off-by: Dan Carpenter 
> 
> Reviewed-by: Joonas Lahtinen 
> 
> I assume Zhenyu will merge this through their tree.
> 

yeah, already put in queue. Thanks!

-- 
Open Source Technology Center, Intel ltd.

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


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

[PATCH] drm/vc4: Fulfill user BO creation requests from the kernel BO cache.

[Eric Anholt]

The from_cache flag was actually "the BO is invisible to userspace",
so we can repurpose to just zero out a cached BO and return it to
userspace.

Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by
-1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that
appeared to be other system noise)

Note that there's an intel-gpu-tools test to check for the proper
zeroing behavior here, which we continue to pass.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 3f6704cf6608..5ec14f25625d 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -208,21 +208,22 @@ struct drm_gem_object *vc4_create_object(struct 
drm_device *dev, size_t size)
 }
 
 struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t unaligned_size,
-bool from_cache)
+bool allow_unzeroed)
 {
size_t size = roundup(unaligned_size, PAGE_SIZE);
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_gem_cma_object *cma_obj;
+   struct vc4_bo *bo;
 
if (size == 0)
return ERR_PTR(-EINVAL);
 
/* First, try to get a vc4_bo from the kernel BO cache. */
-   if (from_cache) {
-   struct vc4_bo *bo = vc4_bo_get_from_cache(dev, size);
-
-   if (bo)
-   return bo;
+   bo = vc4_bo_get_from_cache(dev, size);
+   if (bo) {
+   if (!allow_unzeroed)
+   memset(bo->base.vaddr, 0, bo->base.base.size);
+   return bo;
}
 
cma_obj = drm_gem_cma_create(dev, size);
-- 
2.11.0

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

Re: [PATCH 11/11] drm/msm: Implement preemption for A5XX targets

[Stephen Boyd]

On 02/08/2017 03:00 PM, Jordan Crouse wrote:
> On Wed, Feb 08, 2017 at 12:30:08PM -0800, Stephen Boyd wrote:
>
>> const struct msm_ringbuffer?
> msm_ringbuffer is actively being modified, so we would have to cast it - can't
> tell if there would be a compiler advantage or not.
>

I just meant for this function. It keeps us from modifying ring in the
function.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v2 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu

[Heiko Stübner]

Am Dienstag, 7. Februar 2017, 16:35:35 CET schrieb Mark Yao:
> Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
> enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
> ready to landed, this series just rebase them to lastest drm-next.
> 
> And fix some bugs for drm/rockchip drm_mm
> 
> [0]: http://www.spinics.net/lists/arm-kernel/msg513781.html
> [1]: https://patchwork.kernel.org/patch/9196367
> [2]: https://patchwork.kernel.org/patch/9196369

I've managed to get some output on my rk3399-gru with this series ;-)
and rk3288 also kept on working, so

On rk3288 and rk3399
Tested-by: Heiko Stuebner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv4 8/9] stih-cec: add HPD notifier support

[Rob Herring]

On Mon, Feb 06, 2017 at 11:29:50AM +0100, Hans Verkuil wrote:
> From: Benjamin Gaignard 
> 
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
> 
> Update the bindings documentation the new hdmi phandle.
> 
> Signed-off-by: Benjamin Gaignard 
> Signed-off-by: Hans Verkuil 
> CC: devicet...@vger.kernel.org
> ---
>  .../devicetree/bindings/media/stih-cec.txt |  2 ++
>  drivers/media/platform/Kconfig | 10 +++
>  drivers/media/platform/Makefile|  1 +
>  .../st-cec => media/platform/sti/cec}/Makefile |  0
>  .../st-cec => media/platform/sti/cec}/stih-cec.c   | 31 
> +++---
>  drivers/staging/media/Kconfig  |  2 --
>  drivers/staging/media/Makefile |  1 -
>  drivers/staging/media/st-cec/Kconfig   |  8 --
>  drivers/staging/media/st-cec/TODO  |  7 -
>  9 files changed, 41 insertions(+), 21 deletions(-)
>  rename drivers/{staging/media/st-cec => media/platform/sti/cec}/Makefile 
> (100%)
>  rename drivers/{staging/media/st-cec => media/platform/sti/cec}/stih-cec.c 
> (93%)
>  delete mode 100644 drivers/staging/media/st-cec/Kconfig
>  delete mode 100644 drivers/staging/media/st-cec/TODO
> 
> diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt 
> b/Documentation/devicetree/bindings/media/stih-cec.txt
> index 71c4b2f4bcef..7d82121d148a 100644
> --- a/Documentation/devicetree/bindings/media/stih-cec.txt
> +++ b/Documentation/devicetree/bindings/media/stih-cec.txt
> @@ -9,6 +9,7 @@ Required properties:
>   - pinctrl-names: Contains only one value - "default"
>   - pinctrl-0: Specifies the pin control groups used for CEC hardware.
>   - resets: Reference to a reset controller
> + - st,hdmi-handle: Phandle to the HMDI controller

2 cases in this series. Just drop the vendor prefix on both.

s/HMDI/HDMI/

>  
>  Example for STIH407:
>  
> @@ -22,4 +23,5 @@ sti-cec@094a087c {
>   pinctrl-names = "default";
>   pinctrl-0 = <_cec0_default>;
>   resets = < STIH407_LPM_SOFTRESET>;
> + st,hdmi-handle = <>;
>  };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

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

cosiek...@o2.pl changed:

   What|Removed |Added

Summary|Electronic Super Joy|Electronic Super Joy
   |graphic artefacts   |graphic artefacts
   |(regression)|(regression,bisected)

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

Re: [PATCH 11/11] drm/msm: Implement preemption for A5XX targets

[Jordan Crouse]

On Wed, Feb 08, 2017 at 12:30:08PM -0800, Stephen Boyd wrote:
> On 02/06/2017 09:39 AM, Jordan Crouse wrote:
> > diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c 
> > b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> > new file mode 100644
> > index 000..348ead7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> > @@ -0,0 +1,367 @@
> >
> > +/*
> > + * Try to transition the preemption state from old to new. Return
> > + * true on success or false if the original state wasn't 'old'
> > + */
> > +static inline bool try_preempt_state(struct a5xx_gpu *a5xx_gpu,
> > +   enum preempt_state old, enum preempt_state new)
> > +{
> > +   enum preempt_state cur = atomic_cmpxchg(_gpu->preempt_state,
> > +   old, new);
> > +
> > +   return (cur == old);
> > +}
> > +
> > +/*
> > + * Force the preemption state to the specified state.  This is used in 
> > cases
> > + * where the current state is known and won't change
> > + */
> > +static inline void set_preempt_state(struct a5xx_gpu *gpu,
> > +   enum preempt_state new)
> > +{
> > +   /* atomic_set() doesn't automatically do barriers, so one before.. */
> > +   smp_wmb();
> > +   atomic_set(>preempt_state, new);
> > +   /* ... and one after*/
> > +   smp_wmb();
> 
> Should these smp_wmb()s be replaced with smp_mb__before_atomic() and
> smp_mb__after_atomic()? The latter is stronger (mb() instead of wmb())
> but otherwise that's typically what is used with atomics. Also, it would
> be nice if the comments described what we're synchronizing with.

Yep - _before/_after atomic are more correct to use here. We are synchronizing
with other cores that are trying to check the state machine in try_preempt_state
and in the interrupt handler.  I'll clarify that.

> 
> > +
> > +static void a5xx_preempt_worker(struct work_struct *work)
> > +{
> > +   struct a5xx_gpu *a5xx_gpu =
> > +   container_of(work, struct a5xx_gpu, preempt_work);
> > +   struct msm_gpu *gpu = _gpu->base.base;
> > +   struct drm_device *dev = gpu->dev;
> > +   struct msm_drm_private *priv = dev->dev_private;
> > +
> > +   if (atomic_read(_gpu->preempt_state) == PREEMPT_COMPLETE) {
> > +   uint32_t status = gpu_read(gpu,
> > +   REG_A5XX_CP_CONTEXT_SWITCH_CNTL);
> 
> Why does this worker check the status again? The irq may fire but the
> hardware is still indicating "pending"? And why do we fork off this code
> to a workqueue? Can't we do this stuff in the irq handler or timer
> handler and drop this worker?

That is a great point - I don't actually know if we need the helper here - I
don't believe we need a mutex for anything at this point - the hang recovery
will need one, but that gets scheduled anyway so the worker is unneeded.

> > +
> > +   if (status == 0) {
> > +   del_timer(_gpu->preempt_timer);
> > +   a5xx_gpu->cur_ring = a5xx_gpu->next_ring;
> > +   a5xx_gpu->next_ring = NULL;
> > +
> > +   update_wptr(gpu, a5xx_gpu->cur_ring);
> > +
> > +   set_preempt_state(a5xx_gpu, PREEMPT_NONE);
> > +   return;
> > +   }
> > +
> > +   dev_err(dev->dev, "%s: Preemption failed to complete\n",
> > +   gpu->name);
> > +   } else if (atomic_read(_gpu->preempt_state) == PREEMPT_FAULTED)
> > +   dev_err(dev->dev, "%s: preemption timed out\n", gpu->name);
> > +   else
> > +   return;
> > +
> > +   /* Trigger recovery */
> > +   queue_work(priv->wq, >recover_work);
> > +}
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > index f5118ad..4fcccd4 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > @@ -334,6 +334,11 @@ static inline void adreno_gpu_write64(struct 
> > adreno_gpu *gpu,
> > adreno_gpu_write(gpu, hi, upper_32_bits(data));
> >  }
> >  
> > +static inline uint32_t get_wptr(struct msm_ringbuffer *ring)
> 
> const struct msm_ringbuffer?

msm_ringbuffer is actively being modified, so we would have to cast it - can't
tell if there would be a compiler advantage or not.

Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: vc4: adapt to new behaviour of drm_crtc.c

[Eric Anholt]

Andrzej Pietrasiewicz  writes:

> Hi Eric,
>
> W dniu 08.02.2017 o 01:33, Eric Anholt pisze:
>> Andrzej Pietrasiewicz  writes:
>>
>
> 
>
>>
>> Thanks for the detailed explanation!
>>
>> I think the cursor's possible_crtcs is getting set in vc4_crtc.c (since
>> we don't pass the cursor into drm_crtc_init_with_planes()).
>
> You are right. Shall I submit a v2 patch with a corrected commit message?

I've gone ahead and updated the commit message and pushed to -fixes, so
we can hopefully make it in the next PR.  Thanks!


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

[PATCH] drm/vc4: Drop debug print at boot with DPI enabled.

[Eric Anholt]

Unlike the other encoders in the driver, I've also dropped the debug
dump function.  There's only really one register to this device, and
we have the debugfs reg entry still.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dpi.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index 1e1f6b8184d0..3f360cf6cf5a 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -144,17 +144,6 @@ static const struct {
DPI_REG(DPI_ID),
 };
 
-static void vc4_dpi_dump_regs(struct vc4_dpi *dpi)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(dpi_regs); i++) {
-   DRM_INFO("0x%04x (%s): 0x%08x\n",
-dpi_regs[i].reg, dpi_regs[i].name,
-DPI_READ(dpi_regs[i].reg));
-   }
-}
-
 #ifdef CONFIG_DEBUG_FS
 int vc4_dpi_debugfs_regs(struct seq_file *m, void *unused)
 {
@@ -416,8 +405,6 @@ static int vc4_dpi_bind(struct device *dev, struct device 
*master, void *data)
if (IS_ERR(dpi->regs))
return PTR_ERR(dpi->regs);
 
-   vc4_dpi_dump_regs(dpi);
-
if (DPI_READ(DPI_ID) != DPI_ID_VALUE) {
dev_err(dev, "Port returned 0x%08x for ID instead of 0x%08x\n",
DPI_READ(DPI_ID), DPI_ID_VALUE);
-- 
2.11.0

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

Re: [PATCH 11/11] drm/msm: Implement preemption for A5XX targets

[Stephen Boyd]

On 02/06/2017 09:39 AM, Jordan Crouse wrote:
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> new file mode 100644
> index 000..348ead7
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> @@ -0,0 +1,367 @@
>
> +/*
> + * Try to transition the preemption state from old to new. Return
> + * true on success or false if the original state wasn't 'old'
> + */
> +static inline bool try_preempt_state(struct a5xx_gpu *a5xx_gpu,
> + enum preempt_state old, enum preempt_state new)
> +{
> + enum preempt_state cur = atomic_cmpxchg(_gpu->preempt_state,
> + old, new);
> +
> + return (cur == old);
> +}
> +
> +/*
> + * Force the preemption state to the specified state.  This is used in cases
> + * where the current state is known and won't change
> + */
> +static inline void set_preempt_state(struct a5xx_gpu *gpu,
> + enum preempt_state new)
> +{
> + /* atomic_set() doesn't automatically do barriers, so one before.. */
> + smp_wmb();
> + atomic_set(>preempt_state, new);
> + /* ... and one after*/
> + smp_wmb();

Should these smp_wmb()s be replaced with smp_mb__before_atomic() and
smp_mb__after_atomic()? The latter is stronger (mb() instead of wmb())
but otherwise that's typically what is used with atomics. Also, it would
be nice if the comments described what we're synchronizing with.


> +
> +static void a5xx_preempt_worker(struct work_struct *work)
> +{
> + struct a5xx_gpu *a5xx_gpu =
> + container_of(work, struct a5xx_gpu, preempt_work);
> + struct msm_gpu *gpu = _gpu->base.base;
> + struct drm_device *dev = gpu->dev;
> + struct msm_drm_private *priv = dev->dev_private;
> +
> + if (atomic_read(_gpu->preempt_state) == PREEMPT_COMPLETE) {
> + uint32_t status = gpu_read(gpu,
> + REG_A5XX_CP_CONTEXT_SWITCH_CNTL);

Why does this worker check the status again? The irq may fire but the
hardware is still indicating "pending"? And why do we fork off this code
to a workqueue? Can't we do this stuff in the irq handler or timer
handler and drop this worker?

> +
> + if (status == 0) {
> + del_timer(_gpu->preempt_timer);
> + a5xx_gpu->cur_ring = a5xx_gpu->next_ring;
> + a5xx_gpu->next_ring = NULL;
> +
> + update_wptr(gpu, a5xx_gpu->cur_ring);
> +
> + set_preempt_state(a5xx_gpu, PREEMPT_NONE);
> + return;
> + }
> +
> + dev_err(dev->dev, "%s: Preemption failed to complete\n",
> + gpu->name);
> + } else if (atomic_read(_gpu->preempt_state) == PREEMPT_FAULTED)
> + dev_err(dev->dev, "%s: preemption timed out\n", gpu->name);
> + else
> + return;
> +
> + /* Trigger recovery */
> + queue_work(priv->wq, >recover_work);
> +}
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index f5118ad..4fcccd4 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -334,6 +334,11 @@ static inline void adreno_gpu_write64(struct adreno_gpu 
> *gpu,
>   adreno_gpu_write(gpu, hi, upper_32_bits(data));
>  }
>  
> +static inline uint32_t get_wptr(struct msm_ringbuffer *ring)

const struct msm_ringbuffer?

> +{
> + return ring->cur - ring->start;
> +}
> +
>  /*
>   * Given a register and a count, return a value to program into
>   * REG_CP_PROTECT_REG(n) - this will block both reads and writes for _len
>
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code

[Eric Anholt]

Shawn Guo  writes:

> From: Shawn Guo 
>
> Core code already makes drm_driver.get_vblank_counter hook optional by
> letting drm_vblank_no_hw_counter be the default implementation for the
> function hook.  So the drm_vblank_no_hw_counter assignment in the driver
> code becomes redundant and can be removed now.

Thanks.  Missing this hook was actually a problem in vc4 for a while, so
it's nice to have sensible defaults.  For vc4:

Acked-by: Eric Anholt 


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

Re: [PATCH v3 22/23] drm: vc4: use vblank hooks in struct drm_crtc_funcs

[Eric Anholt]

Shawn Guo  writes:

> From: Shawn Guo 
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.

Thanks for doing this cleanup!

Reviewed-by: Eric Anholt 


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

Re: [PATCH 6/6] drm: Introduce drm_property_blob_{get,put}()

[Sean Paul]

On Wed, Feb 08, 2017 at 07:24:08PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> For consistency with other reference counting APIs in the kernel, add
> drm_property_blob_get() and drm_property_blob_put() to reference count
> DRM blob properties.
> 
> Compatibility aliases are added to keep existing code working. To help
> speed up the transition, all the instances of the old functions in the
> DRM core are already replaced in this commit.
> 
> A semantic patch is provided that can be used to convert all drivers to
> the new helpers.
> 

Reviewed-by: Sean Paul 

> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_atomic.c | 16 ++---
>  drivers/gpu/drm/drm_atomic_helper.c  | 18 +++---
>  drivers/gpu/drm/drm_mode_config.c|  2 +-
>  drivers/gpu/drm/drm_property.c   | 40 
> 
>  include/drm/drm_property.h   | 35 
>  scripts/coccinelle/api/drm-get-put.cocci | 10 
>  6 files changed, 78 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 740650b450c5..ff5f1756a7ff 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -322,7 +322,7 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
> *state,
>   if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
>   return 0;
>  
> - drm_property_unreference_blob(state->mode_blob);
> + drm_property_blob_put(state->mode_blob);
>   state->mode_blob = NULL;
>  
>   if (mode) {
> @@ -368,7 +368,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>   if (blob == state->mode_blob)
>   return 0;
>  
> - drm_property_unreference_blob(state->mode_blob);
> + drm_property_blob_put(state->mode_blob);
>   state->mode_blob = NULL;
>  
>   memset(>mode, 0, sizeof(state->mode));
> @@ -380,7 +380,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>   blob->data))
>   return -EINVAL;
>  
> - state->mode_blob = drm_property_reference_blob(blob);
> + state->mode_blob = drm_property_blob_get(blob);
>   state->enable = true;
>   DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
>state->mode.name, state);
> @@ -413,9 +413,9 @@ drm_atomic_replace_property_blob(struct drm_property_blob 
> **blob,
>   if (old_blob == new_blob)
>   return;
>  
> - drm_property_unreference_blob(old_blob);
> + drm_property_blob_put(old_blob);
>   if (new_blob)
> - drm_property_reference_blob(new_blob);
> + drm_property_blob_get(new_blob);
>   *blob = new_blob;
>   *replaced = true;
>  
> @@ -437,13 +437,13 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_crtc *crtc,
>   return -EINVAL;
>  
>   if (expected_size > 0 && expected_size != new_blob->length) {
> - drm_property_unreference_blob(new_blob);
> + drm_property_blob_put(new_blob);
>   return -EINVAL;
>   }
>   }
>  
>   drm_atomic_replace_property_blob(blob, new_blob, replaced);
> - drm_property_unreference_blob(new_blob);
> + drm_property_blob_put(new_blob);
>  
>   return 0;
>  }
> @@ -478,7 +478,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   struct drm_property_blob *mode =
>   drm_property_lookup_blob(dev, val);
>   ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> - drm_property_unreference_blob(mode);
> + drm_property_blob_put(mode);
>   return ret;
>   } else if (property == config->degamma_lut_property) {
>   ret = drm_atomic_replace_property_blob_from_id(crtc,
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4dcd64ca34c8..863f302b5bf9 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3042,13 +3042,13 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> drm_crtc *crtc,
>   memcpy(state, crtc->state, sizeof(*state));
>  
>   if (state->mode_blob)
> - drm_property_reference_blob(state->mode_blob);
> + drm_property_blob_get(state->mode_blob);
>   if (state->degamma_lut)
> - drm_property_reference_blob(state->degamma_lut);
> + drm_property_blob_get(state->degamma_lut);
>   if (state->ctm)
> - drm_property_reference_blob(state->ctm);
> + drm_property_blob_get(state->ctm);
>   if (state->gamma_lut)
> - drm_property_reference_blob(state->gamma_lut);
> + 

Re: [PATCH 5/6] drm: Introduce drm_gem_object_{get,put}()

[Sean Paul]

On Wed, Feb 08, 2017 at 07:24:07PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> For consistency with other reference counting APIs in the kernel, add
> drm_gem_object_get() and drm_gem_object_put(), as well as an unlocked
> variant of the latter, to reference count GEM buffer objects.
> 
> Compatibility aliases are added to keep existing code working. To help
> speed up the transition, all the instances of the old functions in the
> DRM core are already replaced in this commit.
> 
> The existing semantic patch for the DRM subsystem-wide conversion is
> extended to account for these new helpers.
> 

Reviewed-by: Sean Paul 

> Signed-off-by: Thierry Reding 
> ---
>  Documentation/gpu/drm-mm.rst | 14 +++---
>  drivers/gpu/drm/drm_fb_cma_helper.c  | 16 +++
>  drivers/gpu/drm/drm_gem.c| 44 +-
>  drivers/gpu/drm/drm_gem_cma_helper.c | 10 ++--
>  drivers/gpu/drm/drm_prime.c  | 10 ++--
>  include/drm/drm_gem.h| 80 
> +---
>  scripts/coccinelle/api/drm-get-put.cocci | 20 
>  7 files changed, 130 insertions(+), 64 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index f5760b140f13..fd35998acefc 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -183,14 +183,12 @@ GEM Objects Lifetime
>  
>  
>  All GEM objects are reference-counted by the GEM core. References can be
> -acquired and release by :c:func:`calling
> -drm_gem_object_reference()` and
> -:c:func:`drm_gem_object_unreference()` respectively. The caller
> -must hold the :c:type:`struct drm_device `
> -struct_mutex lock when calling
> -:c:func:`drm_gem_object_reference()`. As a convenience, GEM
> -provides :c:func:`drm_gem_object_unreference_unlocked()`
> -functions that can be called without holding the lock.
> +acquired and release by :c:func:`calling drm_gem_object_get()` and
> +:c:func:`drm_gem_object_put()` respectively. The caller must hold the
> +:c:type:`struct drm_device ` struct_mutex lock when calling
> +:c:func:`drm_gem_object_get()`. As a convenience, GEM provides
> +:c:func:`drm_gem_object_put_unlocked()` functions that can be called without
> +holding the lock.
>  
>  When the last reference to a GEM object is released the GEM core calls
>  the :c:type:`struct drm_driver ` gem_free_object
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 596fabf18c3e..eccc07d20925 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -102,7 +102,7 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb)
>  
>   for (i = 0; i < 4; i++) {
>   if (fb_cma->obj[i])
> - 
> drm_gem_object_unreference_unlocked(_cma->obj[i]->base);
> + drm_gem_object_put_unlocked(_cma->obj[i]->base);
>   }
>  
>   drm_framebuffer_cleanup(fb);
> @@ -190,7 +190,7 @@ struct drm_framebuffer 
> *drm_fb_cma_create_with_funcs(struct drm_device *dev,
>   if (!obj) {
>   dev_err(dev->dev, "Failed to lookup GEM object\n");
>   ret = -ENXIO;
> - goto err_gem_object_unreference;
> + goto err_gem_object_put;
>   }
>  
>   min_size = (height - 1) * mode_cmd->pitches[i]
> @@ -198,9 +198,9 @@ struct drm_framebuffer 
> *drm_fb_cma_create_with_funcs(struct drm_device *dev,
>+ mode_cmd->offsets[i];
>  
>   if (obj->size < min_size) {
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
>   ret = -EINVAL;
> - goto err_gem_object_unreference;
> + goto err_gem_object_put;
>   }
>   objs[i] = to_drm_gem_cma_obj(obj);
>   }
> @@ -208,14 +208,14 @@ struct drm_framebuffer 
> *drm_fb_cma_create_with_funcs(struct drm_device *dev,
>   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
>   if (IS_ERR(fb_cma)) {
>   ret = PTR_ERR(fb_cma);
> - goto err_gem_object_unreference;
> + goto err_gem_object_put;
>   }
>  
>   return _cma->fb;
>  
> -err_gem_object_unreference:
> +err_gem_object_put:
>   for (i--; i >= 0; i--)
> - drm_gem_object_unreference_unlocked([i]->base);
> + drm_gem_object_put_unlocked([i]->base);
>   return ERR_PTR(ret);
>  }
>  EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
> @@ -477,7 +477,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
>  err_fb_info_destroy:
>   drm_fb_helper_release_fbi(helper);
>  err_gem_free_object:
> - drm_gem_object_unreference_unlocked(>base);
> + drm_gem_object_put_unlocked(>base);
>   return ret;
>  }
>  

Re: [PATCH 4/6] drm: Introduce drm_framebuffer_{get,put}()

[Sean Paul]

On Wed, Feb 08, 2017 at 07:24:06PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> For consistency with other reference counting APIs in the kernel, add
> drm_framebuffer_get() and drm_framebuffer_put() to reference count DRM
> framebuffers.
> 
> Compatibility aliases are added to keep existing code working. To help
> speed up the transition, all the instances of the old functions in the
> DRM core are already replaced in this commit.
> 
> The existing semantic patch for the DRM subsystem-wide conversion is
> extended to account for these new helpers.
> 

Reviewed-by: Sean Paul 

> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_atomic.c |  6 ++--
>  drivers/gpu/drm/drm_atomic_helper.c  |  4 +--
>  drivers/gpu/drm/drm_crtc.c   |  8 +++---
>  drivers/gpu/drm/drm_framebuffer.c| 34 +++---
>  drivers/gpu/drm/drm_plane.c  | 12 
>  include/drm/drm_framebuffer.h| 49 
> 
>  scripts/coccinelle/api/drm-get-put.cocci | 10 +++
>  7 files changed, 79 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 82bad40b2f3e..740650b450c5 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -733,7 +733,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, val);
>   drm_atomic_set_fb_for_plane(state, fb);
>   if (fb)
> - drm_framebuffer_unreference(fb);
> + drm_framebuffer_put(fb);
>   } else if (property == config->prop_in_fence_fd) {
>   if (state->fence)
>   return -EINVAL;
> @@ -1837,12 +1837,12 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
>   if (ret == 0) {
>   struct drm_framebuffer *new_fb = plane->state->fb;
>   if (new_fb)
> - drm_framebuffer_reference(new_fb);
> + drm_framebuffer_get(new_fb);
>   plane->fb = new_fb;
>   plane->crtc = plane->state->crtc;
>  
>   if (plane->old_fb)
> - drm_framebuffer_unreference(plane->old_fb);
> + drm_framebuffer_put(plane->old_fb);
>   }
>   plane->old_fb = NULL;
>   }
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9f2c28ddf948..4dcd64ca34c8 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3151,7 +3151,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
> drm_plane *plane,
>   memcpy(state, plane->state, sizeof(*state));
>  
>   if (state->fb)
> - drm_framebuffer_reference(state->fb);
> + drm_framebuffer_get(state->fb);
>  
>   state->fence = NULL;
>  }
> @@ -3191,7 +3191,7 @@ EXPORT_SYMBOL(drm_atomic_helper_plane_duplicate_state);
>  void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
>  {
>   if (state->fb)
> - drm_framebuffer_unreference(state->fb);
> + drm_framebuffer_put(state->fb);
>  
>   if (state->fence)
>   dma_fence_put(state->fence);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9594c623799b..e2974d3c92e7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -471,9 +471,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
>  
>   drm_for_each_crtc(tmp, crtc->dev) {
>   if (tmp->primary->fb)
> - drm_framebuffer_reference(tmp->primary->fb);
> + drm_framebuffer_get(tmp->primary->fb);
>   if (tmp->primary->old_fb)
> - drm_framebuffer_unreference(tmp->primary->old_fb);
> + drm_framebuffer_put(tmp->primary->old_fb);
>   tmp->primary->old_fb = NULL;
>   }
>  
> @@ -567,7 +567,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>   }
>   fb = crtc->primary->fb;
>   /* Make refcounting symmetric with the lookup path. */
> - drm_framebuffer_reference(fb);
> + drm_framebuffer_get(fb);
>   } else {
>   fb = drm_framebuffer_lookup(dev, crtc_req->fb_id);
>   if (!fb) {
> @@ -680,7 +680,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>  
>  out:
>   if (fb)
> - drm_framebuffer_unreference(fb);
> + drm_framebuffer_put(fb);
>  
>   if (connector_set) {
>   for (i = 0; i < crtc_req->count_connectors; i++) {
> diff --git 

Re: [PATCH 3/6] drm: Introduce drm_connector_{get,put}()

[Sean Paul]

On Wed, Feb 08, 2017 at 07:24:05PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> For consistency with other reference counting APIs in the kernel, add
> drm_connector_get() and drm_connector_put() functions to reference count
> connectors.
> 
> Compatibility aliases are added to keep existing code working. To help
> speed up the transition, all the instances of the old functions in the
> DRM core are already replaced in this commit.
> 
> The existing semantic patch for mode object reference count conversion
> is extended for these new helpers.
> 

drivers/gpu/drm/*

Reviewed-by: Sean Paul 

> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_atomic.c |  8 +++
>  drivers/gpu/drm/drm_atomic_helper.c  |  4 ++--
>  drivers/gpu/drm/drm_connector.c  | 10 
>  drivers/gpu/drm/drm_crtc.c   |  2 +-
>  drivers/gpu/drm/drm_crtc_helper.c|  6 ++---
>  drivers/gpu/drm/drm_fb_helper.c  | 12 +-
>  drivers/gpu/drm/drm_mode_config.c|  2 +-
>  include/drm/drm_connector.h  | 41 
> +---
>  scripts/coccinelle/api/drm-get-put.cocci | 10 
>  9 files changed, 65 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2bb0a759e8ec..82bad40b2f3e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -150,7 +150,7 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>  
> state->connectors[i].state);
>   state->connectors[i].ptr = NULL;
>   state->connectors[i].state = NULL;
> - drm_connector_unreference(connector);
> + drm_connector_put(connector);
>   }
>  
>   for (i = 0; i < config->num_crtc; i++) {
> @@ -1026,7 +1026,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
>   if (!connector_state)
>   return ERR_PTR(-ENOMEM);
>  
> - drm_connector_reference(connector);
> + drm_connector_get(connector);
>   state->connectors[index].state = connector_state;
>   state->connectors[index].ptr = connector;
>   connector_state->state = state;
> @@ -1357,7 +1357,7 @@ drm_atomic_set_crtc_for_connector(struct 
> drm_connector_state *conn_state,
>   crtc_state->connector_mask &=
>   ~(1 << drm_connector_index(conn_state->connector));
>  
> - drm_connector_unreference(conn_state->connector);
> + drm_connector_put(conn_state->connector);
>   conn_state->crtc = NULL;
>   }
>  
> @@ -1369,7 +1369,7 @@ drm_atomic_set_crtc_for_connector(struct 
> drm_connector_state *conn_state,
>   crtc_state->connector_mask |=
>   1 << drm_connector_index(conn_state->connector);
>  
> - drm_connector_reference(conn_state->connector);
> + drm_connector_get(conn_state->connector);
>   conn_state->crtc = crtc;
>  
>   DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d:%s]\n",
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9a08445a7a7a..9f2c28ddf948 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3272,7 +3272,7 @@ __drm_atomic_helper_connector_duplicate_state(struct 
> drm_connector *connector,
>  {
>   memcpy(state, connector->state, sizeof(*state));
>   if (state->crtc)
> - drm_connector_reference(connector);
> + drm_connector_get(connector);
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
>  
> @@ -3398,7 +3398,7 @@ void
>  __drm_atomic_helper_connector_destroy_state(struct drm_connector_state 
> *state)
>  {
>   if (state->crtc)
> - drm_connector_unreference(state->connector);
> + drm_connector_put(state->connector);
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 0616062b055a..0dc0e5b33f8a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -35,8 +35,8 @@
>   * als fixed panels or anything else that can display pixels in some form. As
>   * opposed to all other KMS objects representing hardware (like CRTC, 
> encoder or
>   * plane abstractions) connectors can be hotplugged and unplugged at runtime.
> - * Hence they are reference-counted using drm_connector_reference() and
> - * drm_connector_unreference().
> + * Hence they are reference-counted using drm_connector_get() and
> + * drm_connector_put().
>   *
>   * KMS driver must create, initialize, register and attach at a 
>   * drm_connector for each such sink. The instance is created as other KMS
> @@ -545,7 +545,7 @@ 

Re: [PATCH 2/6] drm: Introduce drm_mode_object_{get,put}()

[Sean Paul]

On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> For consistency with other reference counting APIs in the kernel, add
> drm_mode_object_get() and drm_mode_object_put() to reference count DRM
> mode objects.
> 
> Compatibility aliases are added to keep existing code working. To help
> speed up the transition, all the instances of the old functions in the
> DRM core are already replaced in this commit.
> 

drm code looks good and is 

Reviewed-by: Sean Paul 

> A semantic patch is provided that can be used to convert all drivers to
> the new helpers.

I'm not convinced we need to commit the cocci patch. I think including it in
your cover letter and then following up with a follow on series to actually make
the change is sufficient (See: ickle's s/fence/dma_fence/ series).

Sean

> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_atomic.c | 14 +--
>  drivers/gpu/drm/drm_mode_object.c| 26 ++--
>  drivers/gpu/drm/drm_property.c   |  6 ++---
>  include/drm/drm_mode_object.h| 36 ++-
>  scripts/coccinelle/api/drm-get-put.cocci | 42 
> 
>  5 files changed, 95 insertions(+), 29 deletions(-)
>  create mode 100644 scripts/coccinelle/api/drm-get-put.cocci
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a5673107db26..2bb0a759e8ec 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2122,13 +2122,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   }
>  
>   if (!obj->properties) {
> - drm_mode_object_unreference(obj);
> + drm_mode_object_put(obj);
>   ret = -ENOENT;
>   goto out;
>   }
>  
>   if (get_user(count_props, count_props_ptr + copied_objs)) {
> - drm_mode_object_unreference(obj);
> + drm_mode_object_put(obj);
>   ret = -EFAULT;
>   goto out;
>   }
> @@ -2141,14 +2141,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   struct drm_property *prop;
>  
>   if (get_user(prop_id, props_ptr + copied_props)) {
> - drm_mode_object_unreference(obj);
> + drm_mode_object_put(obj);
>   ret = -EFAULT;
>   goto out;
>   }
>  
>   prop = drm_mode_obj_find_prop_id(obj, prop_id);
>   if (!prop) {
> - drm_mode_object_unreference(obj);
> + drm_mode_object_put(obj);
>   ret = -ENOENT;
>   goto out;
>   }
> @@ -2156,14 +2156,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   if (copy_from_user(_value,
>  prop_values_ptr + copied_props,
>  sizeof(prop_value))) {
> - drm_mode_object_unreference(obj);
> + drm_mode_object_put(obj);
>   ret = -EFAULT;
>   goto out;
>   }
>  
>   ret = atomic_set_prop(state, obj, prop, prop_value);
>   if (ret) {
> - drm_mode_object_unreference(obj);
> + drm_mode_object_put(obj);
>   goto out;
>   }
>  
> @@ -2176,7 +2176,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   plane_mask |= (1 << drm_plane_index(plane));
>   plane->old_fb = plane->fb;
>   }
> - drm_mode_object_unreference(obj);
> + drm_mode_object_put(obj);
>   }
>  
>   ret = prepare_crtc_signaling(dev, state, arg, file_priv, _state,
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index 3b405dbf1b8d..da9a9adbcc98 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -133,7 +133,7 @@ struct drm_mode_object *__drm_mode_object_find(struct 
> drm_device *dev,
>   *
>   * This function is used to look up a modeset object. It will acquire a
>   * reference for reference counted objects. This reference must be dropped 
> again
> - * by callind drm_mode_object_unreference().
> + * by callind drm_mode_object_put().
>   */
>  struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
>   uint32_t id, uint32_t type)
> @@ -146,38 +146,38 @@ struct drm_mode_object *drm_mode_object_find(struct 
> drm_device 

Re: [PATCH 1/6] drm: Rename drm_mode_object_get()

[Sean Paul]

On Wed, Feb 08, 2017 at 07:24:03PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Subsequent patches will introduce reference counting APIs that are more
> consistent with similar APIs throughout the Linux kernel. These APIs use
> the _get() and _put() suffixes and will collide with this existing
> function.
> 
> Rename the function to drm_mode_object_add() which is a slightly more
> accurate description of what it does. Also the kerneldoc for this
> function gives an indication that it's badly named because it doesn't
> actually acquire a reference to anything.
> 

Reviewed-by: Sean Paul 

> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_connector.c |  6 +++---
>  drivers/gpu/drm/drm_crtc.c  |  2 +-
>  drivers/gpu/drm/drm_crtc_internal.h | 12 +---
>  drivers/gpu/drm/drm_encoder.c   |  2 +-
>  drivers/gpu/drm/drm_framebuffer.c   |  4 ++--
>  drivers/gpu/drm/drm_mode_object.c   | 18 +++---
>  drivers/gpu/drm/drm_modes.c |  2 +-
>  drivers/gpu/drm/drm_plane.c |  2 +-
>  drivers/gpu/drm/drm_property.c  |  6 +++---
>  9 files changed, 24 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 45464c8b797d..0616062b055a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -189,9 +189,9 @@ int drm_connector_init(struct drm_device *dev,
>   struct ida *connector_ida =
>   _connector_enum_list[connector_type].ida;
>  
> - ret = drm_mode_object_get_reg(dev, >base,
> -   DRM_MODE_OBJECT_CONNECTOR,
> -   false, drm_connector_free);
> + ret = __drm_mode_object_add(dev, >base,
> + DRM_MODE_OBJECT_CONNECTOR,
> + false, drm_connector_free);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6915f897bd8e..e2284539f82c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -282,7 +282,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   spin_lock_init(>commit_lock);
>  
>   drm_modeset_lock_init(>mutex);
> - ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_CRTC);
> + ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_CRTC);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 955c5690bf64..43bbf48ee129 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -98,15 +98,13 @@ int drm_mode_destroyblob_ioctl(struct drm_device *dev,
>  void *data, struct drm_file *file_priv);
>  
>  /* drm_mode_object.c */
> -int drm_mode_object_get_reg(struct drm_device *dev,
> - struct drm_mode_object *obj,
> - uint32_t obj_type,
> - bool register_obj,
> - void (*obj_free_cb)(struct kref *kref));
> +int __drm_mode_object_add(struct drm_device *dev, struct drm_mode_object 
> *obj,
> +   uint32_t obj_type, bool register_obj,
> +   void (*obj_free_cb)(struct kref *kref));
> +int drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj,
> + uint32_t obj_type);
>  void drm_mode_object_register(struct drm_device *dev,
> struct drm_mode_object *obj);
> -int drm_mode_object_get(struct drm_device *dev,
> - struct drm_mode_object *obj, uint32_t obj_type);
>  struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev,
>  uint32_t id, uint32_t type);
>  void drm_mode_object_unregister(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 129450713bb7..634ae0244ea9 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -110,7 +110,7 @@ int drm_encoder_init(struct drm_device *dev,
>  {
>   int ret;
>  
> - ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_ENCODER);
> + ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_ENCODER);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 28a0108a1ab8..11daa24692aa 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -638,8 +638,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
> drm_framebuffer *fb,
>  
>   fb->funcs = funcs;
>  
> - ret = drm_mode_object_get_reg(dev, >base, DRM_MODE_OBJECT_FB,
> -   false, drm_framebuffer_free);
> +

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #72 from Marek Olšák  ---
If the game does any reads or read-modify-write on the mapped buffer memory and
doesn't use the GL_MAP_READ_BIT, it's a bug in the game.

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #71 from Marek Olšák  ---
The current heuristic in Mesa is that if a buffer is not mapped for read, Mesa
doesn't enable CPU caches for the mapping. It's usually an optimal solution for
write-only buffer uploads.

Enabling CPU caches for mapped buffers adds a lot of inefficiencies, so it
should be avoided.

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

Re: [PATCH v3 00/23] Add vblank hooks to struct drm_crtc_funcs

[Daniel Vetter]

On Wed, Feb 08, 2017 at 08:10:04PM +0200, Laurent Pinchart wrote:
> Hi Tomi,
> 
> On Wednesday 08 Feb 2017 13:30:51 Tomi Valkeinen wrote:
> > On 07/02/17 11:16, Shawn Guo wrote:
> > > From: Shawn Guo 
> > > 
> > > The vblank is mostly CRTC specific and implemented as part of CRTC
> > > driver.  The first patch adds 3 vblank core<->driver hooks into struct
> > > drm_crtc_funcs, and plug them into core by adding wrapper functions for
> > > vblank handling code.  We effectively make the .get_vblank_counter hook
> > > optional by providing drm_vblank_no_hw_counter() as the default fallback
> > > in the wrapper function.
> > > 
> > > Patch #2 and #3 unexport function drm_vblank_no_hw_counter() by cleaning
> > > up its use, since it's already the default implememention for
> > > .get_vblank_counter hook anyway.
> > > 
> > > The rest of the series is trying to do a massive conversion to the new
> > > hooks for DRIVER_MODESET drivers.  But it only handles low-hanging
> > > fruit, and leaves out the ones that need a bit surgery, like gma500,
> > > i915, msm etc.  Most of conversion get done by simply moving code and
> > > making functions static, but imx and rockchip are great examples showing
> > > how driver code can be cleaned up with these new hooks.
> > > 
> > > The series is generated against branch drm-next.
> > 
> > Thanks for the series. I've attached a patch for omapdrm, in case you're
> > sending v4 and want to include it in the series.
> 
> You can add my
> 
> Reviewed-by: Laurent Pinchart 

To simplify the flow a bit I've pushed this into drm-misc-next, with
Tomi's ack.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/6] drm: Introduce drm_gem_object_{get,put}()

[Thierry Reding]

From: Thierry Reding 

For consistency with other reference counting APIs in the kernel, add
drm_gem_object_get() and drm_gem_object_put(), as well as an unlocked
variant of the latter, to reference count GEM buffer objects.

Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.

The existing semantic patch for the DRM subsystem-wide conversion is
extended to account for these new helpers.

Signed-off-by: Thierry Reding 
---
 Documentation/gpu/drm-mm.rst | 14 +++---
 drivers/gpu/drm/drm_fb_cma_helper.c  | 16 +++
 drivers/gpu/drm/drm_gem.c| 44 +-
 drivers/gpu/drm/drm_gem_cma_helper.c | 10 ++--
 drivers/gpu/drm/drm_prime.c  | 10 ++--
 include/drm/drm_gem.h| 80 +---
 scripts/coccinelle/api/drm-get-put.cocci | 20 
 7 files changed, 130 insertions(+), 64 deletions(-)

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index f5760b140f13..fd35998acefc 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -183,14 +183,12 @@ GEM Objects Lifetime
 
 
 All GEM objects are reference-counted by the GEM core. References can be
-acquired and release by :c:func:`calling
-drm_gem_object_reference()` and
-:c:func:`drm_gem_object_unreference()` respectively. The caller
-must hold the :c:type:`struct drm_device `
-struct_mutex lock when calling
-:c:func:`drm_gem_object_reference()`. As a convenience, GEM
-provides :c:func:`drm_gem_object_unreference_unlocked()`
-functions that can be called without holding the lock.
+acquired and release by :c:func:`calling drm_gem_object_get()` and
+:c:func:`drm_gem_object_put()` respectively. The caller must hold the
+:c:type:`struct drm_device ` struct_mutex lock when calling
+:c:func:`drm_gem_object_get()`. As a convenience, GEM provides
+:c:func:`drm_gem_object_put_unlocked()` functions that can be called without
+holding the lock.
 
 When the last reference to a GEM object is released the GEM core calls
 the :c:type:`struct drm_driver ` gem_free_object
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 596fabf18c3e..eccc07d20925 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -102,7 +102,7 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb)
 
for (i = 0; i < 4; i++) {
if (fb_cma->obj[i])
-   
drm_gem_object_unreference_unlocked(_cma->obj[i]->base);
+   drm_gem_object_put_unlocked(_cma->obj[i]->base);
}
 
drm_framebuffer_cleanup(fb);
@@ -190,7 +190,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct 
drm_device *dev,
if (!obj) {
dev_err(dev->dev, "Failed to lookup GEM object\n");
ret = -ENXIO;
-   goto err_gem_object_unreference;
+   goto err_gem_object_put;
}
 
min_size = (height - 1) * mode_cmd->pitches[i]
@@ -198,9 +198,9 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct 
drm_device *dev,
 + mode_cmd->offsets[i];
 
if (obj->size < min_size) {
-   drm_gem_object_unreference_unlocked(obj);
+   drm_gem_object_put_unlocked(obj);
ret = -EINVAL;
-   goto err_gem_object_unreference;
+   goto err_gem_object_put;
}
objs[i] = to_drm_gem_cma_obj(obj);
}
@@ -208,14 +208,14 @@ struct drm_framebuffer 
*drm_fb_cma_create_with_funcs(struct drm_device *dev,
fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
if (IS_ERR(fb_cma)) {
ret = PTR_ERR(fb_cma);
-   goto err_gem_object_unreference;
+   goto err_gem_object_put;
}
 
return _cma->fb;
 
-err_gem_object_unreference:
+err_gem_object_put:
for (i--; i >= 0; i--)
-   drm_gem_object_unreference_unlocked([i]->base);
+   drm_gem_object_put_unlocked([i]->base);
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
@@ -477,7 +477,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
 err_fb_info_destroy:
drm_fb_helper_release_fbi(helper);
 err_gem_free_object:
-   drm_gem_object_unreference_unlocked(>base);
+   drm_gem_object_put_unlocked(>base);
return ret;
 }
 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bc93de308673..b1e28c944637 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -218,7 +218,7 @@ static void drm_gem_object_exported_dma_buf_free(struct 
drm_gem_object *obj)
 

[PATCH 6/6] drm: Introduce drm_property_blob_{get,put}()

[Thierry Reding]

From: Thierry Reding 

For consistency with other reference counting APIs in the kernel, add
drm_property_blob_get() and drm_property_blob_put() to reference count
DRM blob properties.

Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.

A semantic patch is provided that can be used to convert all drivers to
the new helpers.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_atomic.c | 16 ++---
 drivers/gpu/drm/drm_atomic_helper.c  | 18 +++---
 drivers/gpu/drm/drm_mode_config.c|  2 +-
 drivers/gpu/drm/drm_property.c   | 40 
 include/drm/drm_property.h   | 35 
 scripts/coccinelle/api/drm-get-put.cocci | 10 
 6 files changed, 78 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 740650b450c5..ff5f1756a7ff 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -322,7 +322,7 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
if (mode && memcmp(>mode, mode, sizeof(*mode)) == 0)
return 0;
 
-   drm_property_unreference_blob(state->mode_blob);
+   drm_property_blob_put(state->mode_blob);
state->mode_blob = NULL;
 
if (mode) {
@@ -368,7 +368,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state 
*state,
if (blob == state->mode_blob)
return 0;
 
-   drm_property_unreference_blob(state->mode_blob);
+   drm_property_blob_put(state->mode_blob);
state->mode_blob = NULL;
 
memset(>mode, 0, sizeof(state->mode));
@@ -380,7 +380,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state 
*state,
blob->data))
return -EINVAL;
 
-   state->mode_blob = drm_property_reference_blob(blob);
+   state->mode_blob = drm_property_blob_get(blob);
state->enable = true;
DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
 state->mode.name, state);
@@ -413,9 +413,9 @@ drm_atomic_replace_property_blob(struct drm_property_blob 
**blob,
if (old_blob == new_blob)
return;
 
-   drm_property_unreference_blob(old_blob);
+   drm_property_blob_put(old_blob);
if (new_blob)
-   drm_property_reference_blob(new_blob);
+   drm_property_blob_get(new_blob);
*blob = new_blob;
*replaced = true;
 
@@ -437,13 +437,13 @@ drm_atomic_replace_property_blob_from_id(struct drm_crtc 
*crtc,
return -EINVAL;
 
if (expected_size > 0 && expected_size != new_blob->length) {
-   drm_property_unreference_blob(new_blob);
+   drm_property_blob_put(new_blob);
return -EINVAL;
}
}
 
drm_atomic_replace_property_blob(blob, new_blob, replaced);
-   drm_property_unreference_blob(new_blob);
+   drm_property_blob_put(new_blob);
 
return 0;
 }
@@ -478,7 +478,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
-   drm_property_unreference_blob(mode);
+   drm_property_blob_put(mode);
return ret;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(crtc,
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 4dcd64ca34c8..863f302b5bf9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3042,13 +3042,13 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,
memcpy(state, crtc->state, sizeof(*state));
 
if (state->mode_blob)
-   drm_property_reference_blob(state->mode_blob);
+   drm_property_blob_get(state->mode_blob);
if (state->degamma_lut)
-   drm_property_reference_blob(state->degamma_lut);
+   drm_property_blob_get(state->degamma_lut);
if (state->ctm)
-   drm_property_reference_blob(state->ctm);
+   drm_property_blob_get(state->ctm);
if (state->gamma_lut)
-   drm_property_reference_blob(state->gamma_lut);
+   drm_property_blob_get(state->gamma_lut);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -3092,10 +3092,10 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
  */
 void 

[PATCH 3/6] drm: Introduce drm_connector_{get,put}()

[Thierry Reding]

From: Thierry Reding 

For consistency with other reference counting APIs in the kernel, add
drm_connector_get() and drm_connector_put() functions to reference count
connectors.

Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.

The existing semantic patch for mode object reference count conversion
is extended for these new helpers.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_atomic.c |  8 +++
 drivers/gpu/drm/drm_atomic_helper.c  |  4 ++--
 drivers/gpu/drm/drm_connector.c  | 10 
 drivers/gpu/drm/drm_crtc.c   |  2 +-
 drivers/gpu/drm/drm_crtc_helper.c|  6 ++---
 drivers/gpu/drm/drm_fb_helper.c  | 12 +-
 drivers/gpu/drm/drm_mode_config.c|  2 +-
 include/drm/drm_connector.h  | 41 +---
 scripts/coccinelle/api/drm-get-put.cocci | 10 
 9 files changed, 65 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2bb0a759e8ec..82bad40b2f3e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -150,7 +150,7 @@ void drm_atomic_state_default_clear(struct drm_atomic_state 
*state)
   
state->connectors[i].state);
state->connectors[i].ptr = NULL;
state->connectors[i].state = NULL;
-   drm_connector_unreference(connector);
+   drm_connector_put(connector);
}
 
for (i = 0; i < config->num_crtc; i++) {
@@ -1026,7 +1026,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,
if (!connector_state)
return ERR_PTR(-ENOMEM);
 
-   drm_connector_reference(connector);
+   drm_connector_get(connector);
state->connectors[index].state = connector_state;
state->connectors[index].ptr = connector;
connector_state->state = state;
@@ -1357,7 +1357,7 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
crtc_state->connector_mask &=
~(1 << drm_connector_index(conn_state->connector));
 
-   drm_connector_unreference(conn_state->connector);
+   drm_connector_put(conn_state->connector);
conn_state->crtc = NULL;
}
 
@@ -1369,7 +1369,7 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
crtc_state->connector_mask |=
1 << drm_connector_index(conn_state->connector);
 
-   drm_connector_reference(conn_state->connector);
+   drm_connector_get(conn_state->connector);
conn_state->crtc = crtc;
 
DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9a08445a7a7a..9f2c28ddf948 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3272,7 +3272,7 @@ __drm_atomic_helper_connector_duplicate_state(struct 
drm_connector *connector,
 {
memcpy(state, connector->state, sizeof(*state));
if (state->crtc)
-   drm_connector_reference(connector);
+   drm_connector_get(connector);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
 
@@ -3398,7 +3398,7 @@ void
 __drm_atomic_helper_connector_destroy_state(struct drm_connector_state *state)
 {
if (state->crtc)
-   drm_connector_unreference(state->connector);
+   drm_connector_put(state->connector);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 0616062b055a..0dc0e5b33f8a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -35,8 +35,8 @@
  * als fixed panels or anything else that can display pixels in some form. As
  * opposed to all other KMS objects representing hardware (like CRTC, encoder 
or
  * plane abstractions) connectors can be hotplugged and unplugged at runtime.
- * Hence they are reference-counted using drm_connector_reference() and
- * drm_connector_unreference().
+ * Hence they are reference-counted using drm_connector_get() and
+ * drm_connector_put().
  *
  * KMS driver must create, initialize, register and attach at a 
  * drm_connector for each such sink. The instance is created as other KMS
@@ -545,7 +545,7 @@ drm_connector_list_iter_next(struct drm_connector_list_iter 
*iter)
spin_unlock_irqrestore(>connector_list_lock, flags);
 
if (old_conn)
-   drm_connector_unreference(old_conn);
+   drm_connector_put(old_conn);
 
return iter->conn;
 }
@@ -564,7 +564,7 @@ void 

[PATCH 1/6] drm: Rename drm_mode_object_get()

[Thierry Reding]

From: Thierry Reding 

Subsequent patches will introduce reference counting APIs that are more
consistent with similar APIs throughout the Linux kernel. These APIs use
the _get() and _put() suffixes and will collide with this existing
function.

Rename the function to drm_mode_object_add() which is a slightly more
accurate description of what it does. Also the kerneldoc for this
function gives an indication that it's badly named because it doesn't
actually acquire a reference to anything.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_connector.c |  6 +++---
 drivers/gpu/drm/drm_crtc.c  |  2 +-
 drivers/gpu/drm/drm_crtc_internal.h | 12 +---
 drivers/gpu/drm/drm_encoder.c   |  2 +-
 drivers/gpu/drm/drm_framebuffer.c   |  4 ++--
 drivers/gpu/drm/drm_mode_object.c   | 18 +++---
 drivers/gpu/drm/drm_modes.c |  2 +-
 drivers/gpu/drm/drm_plane.c |  2 +-
 drivers/gpu/drm/drm_property.c  |  6 +++---
 9 files changed, 24 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 45464c8b797d..0616062b055a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -189,9 +189,9 @@ int drm_connector_init(struct drm_device *dev,
struct ida *connector_ida =
_connector_enum_list[connector_type].ida;
 
-   ret = drm_mode_object_get_reg(dev, >base,
- DRM_MODE_OBJECT_CONNECTOR,
- false, drm_connector_free);
+   ret = __drm_mode_object_add(dev, >base,
+   DRM_MODE_OBJECT_CONNECTOR,
+   false, drm_connector_free);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6915f897bd8e..e2284539f82c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -282,7 +282,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
spin_lock_init(>commit_lock);
 
drm_modeset_lock_init(>mutex);
-   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_CRTC);
+   ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_CRTC);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 955c5690bf64..43bbf48ee129 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -98,15 +98,13 @@ int drm_mode_destroyblob_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 
 /* drm_mode_object.c */
-int drm_mode_object_get_reg(struct drm_device *dev,
-   struct drm_mode_object *obj,
-   uint32_t obj_type,
-   bool register_obj,
-   void (*obj_free_cb)(struct kref *kref));
+int __drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj,
+ uint32_t obj_type, bool register_obj,
+ void (*obj_free_cb)(struct kref *kref));
+int drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj,
+   uint32_t obj_type);
 void drm_mode_object_register(struct drm_device *dev,
  struct drm_mode_object *obj);
-int drm_mode_object_get(struct drm_device *dev,
-   struct drm_mode_object *obj, uint32_t obj_type);
 struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev,
   uint32_t id, uint32_t type);
 void drm_mode_object_unregister(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 129450713bb7..634ae0244ea9 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -110,7 +110,7 @@ int drm_encoder_init(struct drm_device *dev,
 {
int ret;
 
-   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_ENCODER);
+   ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_ENCODER);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 28a0108a1ab8..11daa24692aa 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -638,8 +638,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
drm_framebuffer *fb,
 
fb->funcs = funcs;
 
-   ret = drm_mode_object_get_reg(dev, >base, DRM_MODE_OBJECT_FB,
- false, drm_framebuffer_free);
+   ret = __drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_FB,
+   false, drm_framebuffer_free);
if (ret)
goto out;
 
diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c

[PATCH 0/6] drm: Introduce consistent reference counting APIs

[Thierry Reding]

From: Thierry Reding 

This series introduces DRM reference counting APIs that are consistent
with other reference counting APIs in the kernel. They are also much
shorter. Compatibility aliases are added to keep existing code working
and will stay in place until all users of the old APIs are gone.

All occurrences of the old APIs in the core are already replaced by
this series, and a semantic patch is provided that allows drivers to
be converted automatically. I plan on generating patches against the
drivers once the new functions have been merged and send them out to
their respective maintainers.

Oh, and this fixes one of the items in our recently added TODO list.

Thanks,
Thierry

Thierry Reding (6):
  drm: Rename drm_mode_object_get()
  drm: Introduce drm_mode_object_{get,put}()
  drm: Introduce drm_connector_{get,put}()
  drm: Introduce drm_framebuffer_{get,put}()
  drm: Introduce drm_gem_object_{get,put}()
  drm: Introduce drm_property_blob_{get,put}()

 Documentation/gpu/drm-mm.rst | 14 +++--
 drivers/gpu/drm/drm_atomic.c | 44 +++
 drivers/gpu/drm/drm_atomic_helper.c  | 26 -
 drivers/gpu/drm/drm_connector.c  | 16 +++---
 drivers/gpu/drm/drm_crtc.c   | 12 ++---
 drivers/gpu/drm/drm_crtc_helper.c|  6 +--
 drivers/gpu/drm/drm_crtc_internal.h  | 12 ++---
 drivers/gpu/drm/drm_encoder.c|  2 +-
 drivers/gpu/drm/drm_fb_cma_helper.c  | 16 +++---
 drivers/gpu/drm/drm_fb_helper.c  | 12 ++---
 drivers/gpu/drm/drm_framebuffer.c| 38 ++---
 drivers/gpu/drm/drm_gem.c| 44 +++
 drivers/gpu/drm/drm_gem_cma_helper.c | 10 ++--
 drivers/gpu/drm/drm_mode_config.c|  4 +-
 drivers/gpu/drm/drm_mode_object.c| 44 +++
 drivers/gpu/drm/drm_modes.c  |  2 +-
 drivers/gpu/drm/drm_plane.c  | 14 ++---
 drivers/gpu/drm/drm_prime.c  | 10 ++--
 drivers/gpu/drm/drm_property.c   | 52 +-
 include/drm/drm_connector.h  | 41 +++---
 include/drm/drm_framebuffer.h| 49 -
 include/drm/drm_gem.h| 80 +--
 include/drm/drm_mode_object.h| 36 ++---
 include/drm/drm_property.h   | 35 ++--
 scripts/coccinelle/api/drm-get-put.cocci | 92 
 25 files changed, 471 insertions(+), 240 deletions(-)
 create mode 100644 scripts/coccinelle/api/drm-get-put.cocci

-- 
2.11.1

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

[PATCH 2/6] drm: Introduce drm_mode_object_{get,put}()

[Thierry Reding]

From: Thierry Reding 

For consistency with other reference counting APIs in the kernel, add
drm_mode_object_get() and drm_mode_object_put() to reference count DRM
mode objects.

Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.

A semantic patch is provided that can be used to convert all drivers to
the new helpers.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_atomic.c | 14 +--
 drivers/gpu/drm/drm_mode_object.c| 26 ++--
 drivers/gpu/drm/drm_property.c   |  6 ++---
 include/drm/drm_mode_object.h| 36 ++-
 scripts/coccinelle/api/drm-get-put.cocci | 42 
 5 files changed, 95 insertions(+), 29 deletions(-)
 create mode 100644 scripts/coccinelle/api/drm-get-put.cocci

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a5673107db26..2bb0a759e8ec 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2122,13 +2122,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
}
 
if (!obj->properties) {
-   drm_mode_object_unreference(obj);
+   drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
}
 
if (get_user(count_props, count_props_ptr + copied_objs)) {
-   drm_mode_object_unreference(obj);
+   drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
@@ -2141,14 +2141,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_property *prop;
 
if (get_user(prop_id, props_ptr + copied_props)) {
-   drm_mode_object_unreference(obj);
+   drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
 
prop = drm_mode_obj_find_prop_id(obj, prop_id);
if (!prop) {
-   drm_mode_object_unreference(obj);
+   drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
}
@@ -2156,14 +2156,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
if (copy_from_user(_value,
   prop_values_ptr + copied_props,
   sizeof(prop_value))) {
-   drm_mode_object_unreference(obj);
+   drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
 
ret = atomic_set_prop(state, obj, prop, prop_value);
if (ret) {
-   drm_mode_object_unreference(obj);
+   drm_mode_object_put(obj);
goto out;
}
 
@@ -2176,7 +2176,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
}
-   drm_mode_object_unreference(obj);
+   drm_mode_object_put(obj);
}
 
ret = prepare_crtc_signaling(dev, state, arg, file_priv, _state,
diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index 3b405dbf1b8d..da9a9adbcc98 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -133,7 +133,7 @@ struct drm_mode_object *__drm_mode_object_find(struct 
drm_device *dev,
  *
  * This function is used to look up a modeset object. It will acquire a
  * reference for reference counted objects. This reference must be dropped 
again
- * by callind drm_mode_object_unreference().
+ * by callind drm_mode_object_put().
  */
 struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
uint32_t id, uint32_t type)
@@ -146,38 +146,38 @@ struct drm_mode_object *drm_mode_object_find(struct 
drm_device *dev,
 EXPORT_SYMBOL(drm_mode_object_find);
 
 /**
- * drm_mode_object_unreference - decr the object refcnt
- * @obj: mode_object
+ * drm_mode_object_put - release a mode object reference
+ * @obj: DRM mode object
  *
  * This function decrements the object's refcount if it is a refcounted modeset
  * object. It is a no-op on any other object. This is used to drop references
- * acquired with drm_mode_object_reference().
+ * acquired with drm_mode_object_get().
  */
-void 

[PATCH 4/6] drm: Introduce drm_framebuffer_{get,put}()

[Thierry Reding]

From: Thierry Reding 

For consistency with other reference counting APIs in the kernel, add
drm_framebuffer_get() and drm_framebuffer_put() to reference count DRM
framebuffers.

Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.

The existing semantic patch for the DRM subsystem-wide conversion is
extended to account for these new helpers.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_atomic.c |  6 ++--
 drivers/gpu/drm/drm_atomic_helper.c  |  4 +--
 drivers/gpu/drm/drm_crtc.c   |  8 +++---
 drivers/gpu/drm/drm_framebuffer.c| 34 +++---
 drivers/gpu/drm/drm_plane.c  | 12 
 include/drm/drm_framebuffer.h| 49 
 scripts/coccinelle/api/drm-get-put.cocci | 10 +++
 7 files changed, 79 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 82bad40b2f3e..740650b450c5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -733,7 +733,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, val);
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
} else if (property == config->prop_in_fence_fd) {
if (state->fence)
return -EINVAL;
@@ -1837,12 +1837,12 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
if (ret == 0) {
struct drm_framebuffer *new_fb = plane->state->fb;
if (new_fb)
-   drm_framebuffer_reference(new_fb);
+   drm_framebuffer_get(new_fb);
plane->fb = new_fb;
plane->crtc = plane->state->crtc;
 
if (plane->old_fb)
-   drm_framebuffer_unreference(plane->old_fb);
+   drm_framebuffer_put(plane->old_fb);
}
plane->old_fb = NULL;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9f2c28ddf948..4dcd64ca34c8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3151,7 +3151,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
memcpy(state, plane->state, sizeof(*state));
 
if (state->fb)
-   drm_framebuffer_reference(state->fb);
+   drm_framebuffer_get(state->fb);
 
state->fence = NULL;
 }
@@ -3191,7 +3191,7 @@ EXPORT_SYMBOL(drm_atomic_helper_plane_duplicate_state);
 void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
 {
if (state->fb)
-   drm_framebuffer_unreference(state->fb);
+   drm_framebuffer_put(state->fb);
 
if (state->fence)
dma_fence_put(state->fence);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9594c623799b..e2974d3c92e7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -471,9 +471,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
 
drm_for_each_crtc(tmp, crtc->dev) {
if (tmp->primary->fb)
-   drm_framebuffer_reference(tmp->primary->fb);
+   drm_framebuffer_get(tmp->primary->fb);
if (tmp->primary->old_fb)
-   drm_framebuffer_unreference(tmp->primary->old_fb);
+   drm_framebuffer_put(tmp->primary->old_fb);
tmp->primary->old_fb = NULL;
}
 
@@ -567,7 +567,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
fb = crtc->primary->fb;
/* Make refcounting symmetric with the lookup path. */
-   drm_framebuffer_reference(fb);
+   drm_framebuffer_get(fb);
} else {
fb = drm_framebuffer_lookup(dev, crtc_req->fb_id);
if (!fb) {
@@ -680,7 +680,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
 
 out:
if (fb)
-   drm_framebuffer_unreference(fb);
+   drm_framebuffer_put(fb);
 
if (connector_set) {
for (i = 0; i < crtc_req->count_connectors; i++) {
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 11daa24692aa..5e8e1d06866a 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -52,13 +52,13 @@
  * metadata fields.
  *
  * The 

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #70 from Captain Crutches  ---
So, at the risk of sounding ignorant, does that mean the bug actually belongs
to Psyonix because they're just doing it inefficiently, or is there still
something that can be done on the Mesa side?

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #69 from Marek Olšák  ---
Actually, the only way to get cached RAM is to map a buffer with
GL_MAP_READ_BIT. There is no other way.

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

Re: [PATCH v2] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Wednesday 08 Feb 2017 16:08:06 Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, NV12 color format appears to work Ok with
> all decimation factors.
> 
> When decimating horizontally by more that 4 the dss is not able to
> fetch the data in burst mode. When this happens it is hard to tell if
> there enough bandwidth. Despite what theory says this appears to be
> true also for 16-bit color formats.
> 
> Signed-off-by: Jyri Sarha 

Acked-by: Laurent Pinchart 

> ---
> Chnages since first version:
> - "color_mode_to_bpp(color_mode) > 8" -> "color_mode != OMAP_DSS_COLOR_NV12"
> - commit message and comment updated too
> - improve error print
> 
>  drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5554b72..d956e626 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long
> pclk, unsigned long lclk, return -EINVAL;
>   }
> 
> + if (*decim_x > 4 && color_mode != OMAP_DSS_COLOR_NV12) {
> + /*
> +  * Let's disable all scaling that requires horizontal
> +  * decimation with higher factor than 4, until we have
> +  * better estimates of what we can and can not
> +  * do. However, NV12 color format appears to work Ok
> +  * with all decimation factors.
> +  *
> +  * When decimating horizontally by more that 4 the dss
> +  * is not able to fetch the data in burst mode. When
> +  * this happens it is hard to tell if there enough
> +  * bandwidth. Despite what theory says this appears to
> +  * be true also for 16-bit color formats.
> +  */
> + DSSERR("Not enough bandwidth, too much downscaling (x-
decimation factor
> %d > 4)", *decim_x); +
> + return -EINVAL;
> + }
> +
>   *core_clk = dispc.feat->calc_core_clk(pclk, in_width, in_height,
>   out_width, out_height, mem_to_mem);
>   return 0;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v3 00/23] Add vblank hooks to struct drm_crtc_funcs

[Laurent Pinchart]

Hi Tomi,

On Wednesday 08 Feb 2017 13:30:51 Tomi Valkeinen wrote:
> On 07/02/17 11:16, Shawn Guo wrote:
> > From: Shawn Guo 
> > 
> > The vblank is mostly CRTC specific and implemented as part of CRTC
> > driver.  The first patch adds 3 vblank core<->driver hooks into struct
> > drm_crtc_funcs, and plug them into core by adding wrapper functions for
> > vblank handling code.  We effectively make the .get_vblank_counter hook
> > optional by providing drm_vblank_no_hw_counter() as the default fallback
> > in the wrapper function.
> > 
> > Patch #2 and #3 unexport function drm_vblank_no_hw_counter() by cleaning
> > up its use, since it's already the default implememention for
> > .get_vblank_counter hook anyway.
> > 
> > The rest of the series is trying to do a massive conversion to the new
> > hooks for DRIVER_MODESET drivers.  But it only handles low-hanging
> > fruit, and leaves out the ones that need a bit surgery, like gma500,
> > i915, msm etc.  Most of conversion get done by simply moving code and
> > making functions static, but imx and rockchip are great examples showing
> > how driver code can be cleaned up with these new hooks.
> > 
> > The series is generated against branch drm-next.
> 
> Thanks for the series. I've attached a patch for omapdrm, in case you're
> sending v4 and want to include it in the series.

You can add my

Reviewed-by: Laurent Pinchart 

to the patch.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Laurent Pinchart]

Hi Tomi,

On Wednesday 08 Feb 2017 15:51:08 Tomi Valkeinen wrote:
> On 07/02/17 16:41, Jyri Sarha wrote:
> > Let's disable all scaling that requires horizontal decimation with
> > higher factor than 4, until we have better estimates of what we can
> > and can not do. However, 1 byte per pixel color format appear to work
> > Ok with all decimation factors.
> > 
> > When decimating horizontally by more that 4 the dss is not able to
> > fetch the data in burst mode. When this happens it is hard to tell if
> > there enough bandwidth. Despite what theory says this appears to be
> > true also for 16-bit color formats.
> > 
> > Signed-off-by: Jyri Sarha 
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> > b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5554b72..61daef6 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> > @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned
> > long pclk, unsigned long lclk,> 
> > return -EINVAL;
> > 
> > }
> > 
> > +   if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) {
> > +   /*
> > + Let's disable all scaling that requires horizontal
> > + decimation with higher factor than 4, until we have
> > + better estimates of what we can and can not
> > + do. However, 1 byte per pixel color format appear to
> > + work Ok with all decimation factors.
> > +
> > + When decimating horizontally by more that 4 the dss
> > + is not able to fetch the data in burst mode. When
> > + this happens it is hard to tell if there enough
> > + bandwidth. Despite what theory says this appears to
> > + be true also for 16-bit color formats.
> > +   */
> > +   DSSERR("Not enough bandwidth (x-decimation factor %d > 4)",
> > +   *decim_x);
> 
> I think the error message could be improved. A normal user could hit
> this when setting up a plane, and I'm quite sure the above doesn't give
> any clue to the user what the issue is (too much downscaling).

Shouldn't the message be turned into a debug message ? Otherwise you'll give a 
way for users to flood the kernel log, which is never good.

-- 
Regards,

Laurent Pinchart

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

[Bug 99552] Make Advanced Simulation Library (ASL) OpenCL GPU support work on Clover and RadeonSI

[bugzilla-daemon]

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

--- Comment #2 from Vedran Miletić  ---
(In reply to Vedran Miletić from comment #1)
>   Start  7: testPrivateVar
>  7/10 Test  #7: testPrivateVar ...***Exception: Other  3.22
> sec

Adding native_rsqrt fixes this, patch will appear here:
http://lists.llvm.org/pipermail/libclc-dev/2017-February/

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

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

[Jose Abreu]

Hi,



On 07-02-2017 16:36, Thierry Reding wrote:
> On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 2/7/2017 4:31 PM, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>>
>>> On 06-02-2017 13:59, Shashank Sharma wrote:
 This patch does following:
 - Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
 - Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
 - Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
 - If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.

 V2: Addressed review comments
 Thierry:
 - Fix typos in commit message and make abbreviation consistent
across the commit message.
 - Change structure object name from hdmi_info -> hdmi
 - Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
 - Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.

 Ville:
 - Change rr -> read_request
 - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.

 Reviewed-by: Thierry Reding 
 Signed-off-by: Shashank Sharma 
 ---
   drivers/gpu/drm/drm_edid.c  | 14 ++
   include/drm/drm_connector.h | 33 +
   2 files changed, 47 insertions(+)

 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 96d3e47..a487b80 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
   }
   EXPORT_SYMBOL(drm_default_rgb_quant_range);
 +static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 +   const u8 *hf_vsdb)
 +{
 +  struct drm_hdmi_info *hdmi = >display_info.hdmi;
 +
 +  if (hf_vsdb[6] & 0x80) {
>>> BIT(7) ?
>> Yes, SCDC_present bit is bit 7, byte 6 in HF-VSDB. Am I missing something ?
 +  hdmi->scdc.supported = true;
 +  if (hf_vsdb[6] & 0x40)
>>> BIT(6) ?
>> Yes, RR_Capable bit is bit 6, byte 6 in HF-VSDB.
> I think what Jose was trying to say is that you should be using BIT(7)
> instead of 0x80 and BIT(6) instead of 0x40. That said, I think either is
> fine, but perhaps another idea would be to define macros for these. I
> know that most (all?) of the EDID parsing code uses literals, so this is
> consistent with existing code. Also usually code will be like:
>
>   if (hf_vsdb[X] & 0xYZ)
>   foo_supported = true;
>
> So the meaning of the bit is easy to read from the context. I think
> literals are fine in this case.
>
> Thierry

Thats exactly what I meant :) I think with BIT(x) the code is
easier to read (my hex skills are not very good :)). Anyway, if
the remaining code uses literals then maybe its better to keep
consistency.

Best regards,
Jose Miguel Abreu

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

Re: [PATCH] drm/doc: Add TODO list

[Thierry Reding]

On Tue, Feb 07, 2017 at 08:01:37PM +0100, Daniel Vetter wrote:
> On Tue, Feb 07, 2017 at 06:51:13PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > This commit adds a TODO list to the GPU driver developer's guide. The
> > content was taken from the DRMJanitors page on the X.Org wiki:
> > 
> > https://www.x.org/wiki/DRMJanitors/
> > 
> > The goal is to track a list of refactorings that would be nice to see
> > merged eventually. Sometimes these would be encountered during patch
> > review on the mailing list, and at other times one can come across
> > these while working in a specific area of code.
> > 
> > Signed-off-by: Thierry Reding 
> 
> Sean also acked this on irc, merged to drm-misc-next. I'll update the wiki
> with the link. And I assume you'll follow up with a patch, cc: Noralf,
> with the tinydrm cleanups once that landed?

Yes, will do.

Thanks,
Thierry


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

Re: [PATCH v2] drm/mxsfb: fix pixel clock polarity

[Marek Vasut]

On 02/08/2017 08:19 AM, Daniel Vetter wrote:
> On Wed, Feb 8, 2017 at 6:19 AM, Stefan Agner  wrote:
>> On 2016-12-14 13:25, Marek Vasut wrote:
>>> On 12/14/2016 09:48 PM, Stefan Agner wrote:
 The DRM subsystem specifies the pixel clock polarity from a
 controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
 the controller drives the data on pixel clocks falling edge.
 That is the controllers DOTCLK_POL=0 (Default is data launched
 at negative edge).

 Also change the data enable logic to be high active by default
 and only change if explicitly requested via bus_flags. With
 that defaults are:
 - Data enable: high active
 - Pixel clock polarity: controller drives data on negative edge

 Signed-off-by: Stefan Agner 
>>>
>>> Acked-by: Marek Vasut 
>>>
>>
>> This seems not have made into drm-next yet. Not sure what the plan is
>> here, who will pick this up? There is also another fix on ML for the
>> same driver ("drm: mxsfb: Fix crash when provided invalid DT bindings").
> 
> By default, driver maintainers are expected to pick up driver patches.
> Exception is trivial patches by newcomers, to get them on board fast
> (and avoid frustration when a maintainer isn't around). drm-misc and
> Dave by default don't pick up anything.

Aha, OK.

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

[PATCH v2] drm/imx: imx-tve: Do not set the regulator voltage

[Fabio Estevam]

Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:

63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22

When the 'dac-supply' is not passed in the device tree a dummy regulator is
used and setting its voltage is not allowed.

To fix this issue, do not set the dac-supply voltage inside the driver
and let its voltage be specified in the device tree.

Print a warning if the the 'dac-supply' voltage has a value different
from 2.75V.

Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by 
regulator_set_voltage()")
Cc:  # 4.8+
Suggested-by: Lucas Stach 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Fix the warning message. When a 'dac-supply' node is not passed we cannot
print the regulator_get_voltage() value.

 drivers/gpu/drm/imx/imx-tve.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 8f8aa4a..4826bb7 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -98,6 +98,8 @@
 /* TVE_TST_MODE_REG */
 #define TVE_TVDAC_TEST_MODE_MASK   (0x7 << 0)
 
+#define IMX_TVE_DAC_VOLTAGE275
+
 enum {
TVE_MODE_TVOUT,
TVE_MODE_VGA,
@@ -616,9 +618,8 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
 
tve->dac_reg = devm_regulator_get(dev, "dac");
if (!IS_ERR(tve->dac_reg)) {
-   ret = regulator_set_voltage(tve->dac_reg, 275, 275);
-   if (ret)
-   return ret;
+   if (regulator_get_voltage(tve->dac_reg) != IMX_TVE_DAC_VOLTAGE)
+   dev_warn(dev, "dac voltage is not %d uV\n", 
IMX_TVE_DAC_VOLTAGE);
ret = regulator_enable(tve->dac_reg);
if (ret)
return ret;
-- 
2.7.4

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

Re: [PATCH v2 1/6] drm: Add SCDC helpers

[Jose Abreu]

Hi Shashank,



On 07-02-2017 16:09, Sharma, Shashank wrote:
> Thanks for the review Jose, my comments inline.
>
>
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:24 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> Sorry for the late review.
>>
>>
>> On 06-02-2017 13:59, Shashank Sharma wrote:
>>> From: Thierry Reding 
>>>
>>> SCDC is a mechanism defined in the HDMI 2.0 specification
>>> that allows
>>> the source and sink devices to communicate.
>>>
>>> This commit introduces helpers to access the SCDC and
>>> provides the
>>> symbolic names for the various registers defined in the
>>> specification.
>>>
>>> Signed-off-by: Thierry Reding 
>>> Signed-off-by: Shashank Sharma 
>>> ---
>>>   Documentation/gpu/drm-kms-helpers.rst |  12 
>>>   drivers/gpu/drm/Makefile  |   3 +-
>>>   drivers/gpu/drm/drm_scdc_helper.c | 111
>>> 
>>>   include/drm/drm_scdc_helper.h | 132
>>> ++
>>>   4 files changed, 257 insertions(+), 1 deletion(-)
>>>   create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
>>>   create mode 100644 include/drm/drm_scdc_helper.h
>>>
>>> diff --git a/Documentation/gpu/drm-kms-helpers.rst
>>> b/Documentation/gpu/drm-kms-helpers.rst
>>> index 03040aa..7592756 100644
>>> --- a/Documentation/gpu/drm-kms-helpers.rst
>>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>>> @@ -217,6 +217,18 @@ EDID Helper Functions Reference
>>>   .. kernel-doc:: drivers/gpu/drm/drm_edid.c
>>>  :export:
>>>   +SCDC Helper Functions Reference
>>> +===
>>> +
>>> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
>>> +   :doc: scdc helpers
>>> +
>>> +.. kernel-doc:: include/drm/drm_scdc_helper.h
>>> +   :internal:
>>> +
>>> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
>>> +   :export:
>>> +
>>>   Rectangle Utilities Reference
>>>   =
>>>   diff --git a/drivers/gpu/drm/Makefile
>>> b/drivers/gpu/drm/Makefile
>>> index 92de399..ad91cd9 100644
>>> --- a/drivers/gpu/drm/Makefile
>>> +++ b/drivers/gpu/drm/Makefile
>>> @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o
>>> drm_debugfs_crc.o
>>>   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
>>> drm_probe_helper.o \
>>>   drm_plane_helper.o drm_dp_mst_topology.o
>>> drm_atomic_helper.o \
>>>   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
>>> -drm_simple_kms_helper.o drm_modeset_helper.o
>>> +drm_simple_kms_helper.o drm_modeset_helper.o \
>>> +drm_scdc_helper.o
>>> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) +=
>>> drm_edid_load.o
>>>   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) +=
>>> drm_fb_helper.o
>>> diff --git a/drivers/gpu/drm/drm_scdc_helper.c
>>> b/drivers/gpu/drm/drm_scdc_helper.c
>>> new file mode 100644
>>> index 000..fe0e121
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/drm_scdc_helper.c
>>> @@ -0,0 +1,111 @@
>>> +/*
>>> + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
>>> + *
>>> + * Permission is hereby granted, free of charge, to any
>>> person obtaining a
>>> + * copy of this software and associated documentation files
>>> (the "Software"),
>>> + * to deal in the Software without restriction, including
>>> without limitation
>>> + * the rights to use, copy, modify, merge, publish,
>>> distribute, sub license,
>>> + * and/or sell copies of the Software, and to permit persons
>>> to whom the
>>> + * Software is furnished to do so, subject to the following
>>> conditions:
>>> + *
>>> + * The above copyright notice and this permission notice
>>> (including the
>>> + * next paragraph) shall be included in all copies or
>>> substantial portions
>>> + * of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
>>> KIND, EXPRESS OR
>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>> MERCHANTABILITY,
>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN
>>> NO EVENT SHALL
>>> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
>>> DAMAGES OR OTHER
>>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>>> OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
>>> USE OR OTHER
>>> + * DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +/**
>>> + * DOC: scdc helpers
>>> + *
>>> + * Status and Control Data Channel (SCDC) is a mechanism
>>> introduced by the
>>> + * HDMI 2.0 specification. It is a point-to-point protocol
>>> that allows the
>>> + * HDMI source and HDMI sink to exchange data. The same I2C
>>> interface that
>>> + * is used to access EDID serves as the transport mechanism
>>> for SCDC.
>>> + */
>>> +
>>> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
>>> +
>>> +/**
>>> + * drm_scdc_read - read a block of data from SCDC
>>> + * @adapter: I2C controller
>>> + * @offset: start offset of block to read
>>> + * @buffer: return location for the 

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

[Jose Abreu]

Hi Jani,



On 07-02-2017 15:09, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu  wrote:
>> Hi Jani,
>>
>>
>> On 07-02-2017 13:35, Jani Nikula wrote:
>>> On Tue, 07 Feb 2017, Jose Abreu  wrote:
> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
> +{
> + u8 status;
> + int ret;
> +
> + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
> + if (ret < 0) {
> + DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
> + return false;
> + }
> +
> + return status & SCDC_SCRAMBLING_STATUS;
 "return (status & SCDC_SCRAMBLING_STATUS) > 0;" ?
>>> What's the point in that?
>>>
>>> BR,
>>> Jani.
>>>
>>>
>> Sorry, I didn't see the SCDC_SCRAMBLING_STATUS is BIT(0). Anyway,
>> my intention was to return either 1 or 0 or else the value of the
>> "and" would be returned. I think in x86 the bool is char, what
>> could happen if SCDC_SCRAMBLING_STATUS was BIT(>7)? Does the cast
>> work as expected?
> The implicit type conversion works just fine.

Hmm, are you sure? I'm reading this thread:
http://yarchive.net/comp/linux/bool.html (see Linus last answer).

(This is just for curiosity anyway).

Best regards,
Jose Miguel Abreu

>
> BR,
> Jani.
>
>> Best regards,
>> Jose Miguel Abreu
>>

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

Re: [PATCH] drm: vc4: adapt to new behaviour of drm_crtc.c

[Andrzej Pietrasiewicz]

Hi Eric,

W dniu 08.02.2017 o 01:33, Eric Anholt pisze:

Andrzej Pietrasiewicz  writes:







Thanks for the detailed explanation!

I think the cursor's possible_crtcs is getting set in vc4_crtc.c (since
we don't pass the cursor into drm_crtc_init_with_planes()).


You are right. Shall I submit a v2 patch with a corrected commit message?

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

Re: [PATCH v2 1/6] drm: Add SCDC helpers

[Jose Abreu]

Hi Shashank,


On 08-02-2017 12:59, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/8/2017 4:57 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>>
>> On 07-02-2017 16:09, Sharma, Shashank wrote:
>>> Thanks for the review Jose, my comments inline.
>>>
>>>
>>> Regards
>>>
>>> Shashank
>>>
>>>
>>> On 2/7/2017 4:24 PM, Jose Abreu wrote:
 Hi Shashank,


 Sorry for the late review.


 On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding 
>
> SCDC is a mechanism defined in the HDMI 2.0 specification
> that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and
> provides the
> symbolic names for the various registers defined in the
> specification.
>
> Signed-off-by: Thierry Reding 
> Signed-off-by: Shashank Sharma 
> ---
>Documentation/gpu/drm-kms-helpers.rst |  12 
>drivers/gpu/drm/Makefile  |   3 +-
>drivers/gpu/drm/drm_scdc_helper.c | 111
> 
>include/drm/drm_scdc_helper.h | 132
> ++
>4 files changed, 257 insertions(+), 1 deletion(-)
>create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
>create mode 100644 include/drm/drm_scdc_helper.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 03040aa..7592756 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -217,6 +217,18 @@ EDID Helper Functions Reference
>.. kernel-doc:: drivers/gpu/drm/drm_edid.c
>   :export:
>+SCDC Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> +   :doc: scdc helpers
> +
> +.. kernel-doc:: include/drm/drm_scdc_helper.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> +   :export:
> +
>Rectangle Utilities Reference
>=
>diff --git a/drivers/gpu/drm/Makefile
> b/drivers/gpu/drm/Makefile
> index 92de399..ad91cd9 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o
> drm_debugfs_crc.o
>drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> drm_probe_helper.o \
>drm_plane_helper.o drm_dp_mst_topology.o
> drm_atomic_helper.o \
>drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> -drm_simple_kms_helper.o drm_modeset_helper.o
> +drm_simple_kms_helper.o drm_modeset_helper.o \
> +drm_scdc_helper.o
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) +=
> drm_edid_load.o
>drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) +=
> drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c
> b/drivers/gpu/drm/drm_scdc_helper.c
> new file mode 100644
> index 000..fe0e121
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2015 NVIDIA Corporation. All rights
> reserved.
> + *
> + * Permission is hereby granted, free of charge, to any
> person obtaining a
> + * copy of this software and associated documentation files
> (the "Software"),
> + * to deal in the Software without restriction, including
> without limitation
> + * the rights to use, copy, modify, merge, publish,
> distribute, sub license,
> + * and/or sell copies of the Software, and to permit persons
> to whom the
> + * Software is furnished to do so, subject to the following
> conditions:
> + *
> + * The above copyright notice and this permission notice
> (including the
> + * next paragraph) shall be included in all copies or
> substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN
> NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include 
> +
> +#include 
> +
> +/**
> + * DOC: scdc helpers
> + *
> + * Status and Control Data Channel (SCDC) is a mechanism
> introduced by the
> + * HDMI 2.0 specification. It is a point-to-point protocol

Help...

[Sgt Swanson Dennis]

Dear Sir/Madam,

I am Sgt Swanson Dennis, I have a good business proposal for you.
There are no risks involved and it is easy. Please reply for briefs
and procedures.

Best regards,

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

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

[Jose Abreu]

Hi Shashank,



On 07-02-2017 16:19, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:44 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>>
>> On 06-02-2017 13:59, Shashank Sharma wrote:
>>> HDMI 2.0 spec mandates scrambling for modes with pixel clock
>>> higher
>>> than 340 MHz. This patch adds few new functions in drm layer for
>>> core drivers to enable/disable scrambling.
>>>
>>> This patch adds:
>>> - A function to detect scrambling support parsing HF-VSDB
>>> - A function to check scrambling status runtime using SCDC read.
>>> - Two functions to enable/disable scrambling using SCDC
>>> read/write.
>>> - Few new bools to reflect scrambling support and status.
>>>
>>> V2: Addressed review comments from Thierry, Ville and Dhinakaran
>>> Thierry:
>>> - Mhz -> MHz in comments and commit message.
>>> - i2c -> I2C in comments.
>>> - Fix the function documentations, keep in sync with
>>> drm_scdc_helper.c
>>> - drm_connector -> DRM connector.
>>> - Create structure for SCDC, and save scrambling status
>>> inside that,
>>>in a sub-structure.
>>> - Call this sub-structure scrambling instead of scr_info.
>>> - low_rates -> low_clocks in scrambling status structure.
>>> - Store the return value of I2C read/write and print the
>>> error code
>>>  in case of failure.
>>>
>>> Thierry and Ville:
>>> - Move the scrambling enable/disable/query functions in
>>>drm_scdc_helper.c file.
>>> - Add drm_SCDC prefix for the functions.
>>> - Optimize the return statement from function
>>>drm_SCDC_check_scrambling_status.
>>>
>>> Ville:
>>> - Dont overwrite saved max TMDS clock value in display_info,
>>>if max tmds clock from HF-VSDB is not > 340 MHz.
>>> - drm_detect_hdmi_scrambling -> drm_parse_hdmi_forum_vsdb.
>>> - Remove dynamic tracking of SCDC status from DRM layer,
>>> force bool.
>>> - Program clock ratio bit also, while enabling scrambling.
>>>
>>> Dhinakaran:
>>>   - Add a comment about *5000 while extracting max clock
>>> supported.
>>>
>>> Signed-off-by: Shashank Sharma 
>>> ---
>>>   drivers/gpu/drm/drm_edid.c|  33 -
>>>   drivers/gpu/drm/drm_scdc_helper.c | 100
>>> ++
>>>   include/drm/drm_connector.h   |  19 
>>>   include/drm/drm_edid.h|   6 ++-
>>>   include/drm/drm_scdc_helper.h |  20 
>>>   5 files changed, 176 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c
>>> b/drivers/gpu/drm/drm_edid.c
>>> index a487b80..dc85eb9 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -37,6 +37,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>> #define version_greater(edid, maj, min) \
>>>   (((edid)->version > (maj)) || \
>>> @@ -3805,13 +3806,43 @@ enum hdmi_quantization_range
>>>   static void drm_parse_hdmi_forum_vsdb(struct drm_connector
>>> *connector,
>>>const u8 *hf_vsdb)
>>>   {
>>> -struct drm_hdmi_info *hdmi = >display_info.hdmi;
>>> +struct drm_display_info *display =
>>> >display_info;
>>> +struct drm_hdmi_info *hdmi = >hdmi;
>>> if (hf_vsdb[6] & 0x80) {
>>>   hdmi->scdc.supported = true;
>>>   if (hf_vsdb[6] & 0x40)
>>>   hdmi->scdc.read_request = true;
>>>   }
>>> +
>>> +/*
>>> + * All HDMI 2.0 monitors must support scrambling at
>>> rates > 340 MHz.
>>> + * And as per the spec, three factors confirm this:
>>> + * * Availability of a HF-VSDB block in EDID (check)
>>> + * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's
>>> check)
>>> + * * SCDC support available (let's check)
>>> + * Lets check it out.
>>> + */
>>> +
>>> +if (hf_vsdb[5]) {
>>> +/* max clock is 5000 KHz times block value */
>>> +u32 max_tmds_clock = hf_vsdb[5] * 5000;
>>> +struct drm_scdc *scdc = >scdc;
>>> +
>>> +if (max_tmds_clock > 34) {
>>> +display->max_tmds_clock = max_tmds_clock;
>>> +DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
>>> +display->max_tmds_clock);
>>> +}
>>> +
>>> +if (scdc->supported) {
>>> +scdc->scrambling.supported = true;
>>> +
>>> +/* Few sinks support scrambling for cloks < 340M */
>>> +if ((hf_vsdb[6] & 0x8))
>> BIT(3) ?
> Yes, bit 3 is LTE_340Mcsc_scramble, indicating that the sink
> support scrambling at rates below 340Mhz too, isn't it ?
>>
>>> +scdc->scrambling.low_rates = true;
>>> +}
>>> +}
>>>   }
>>> static void drm_parse_hdmi_deep_color_info(struct
>>> drm_connector *connector,
>>> diff --git a/drivers/gpu/drm/drm_scdc_helper.c
>>> b/drivers/gpu/drm/drm_scdc_helper.c
>>> index fe0e121..311f62e 100644
>>> --- a/drivers/gpu/drm/drm_scdc_helper.c
>>> +++ b/drivers/gpu/drm/drm_scdc_helper.c
>>> @@ -22,8 +22,10 @@
>>>*/
>>> #include 
>>> +#include 
>>> #include 
>>> +#include 
>>> 

Re: [PATCH 2/5] arm64: dts: exynos: Move the clock-frequency property

[Krzysztof Kozlowski]

On Wed, Feb 8, 2017 at 12:09 PM, Hoegeun Kwon  wrote:
> On 02/08/2017 04:32 PM, Krzysztof Kozlowski wrote:
>>
>> On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon 
>> wrote:

 "Remove the ports node abd move burst and esc clock frequency properties
 to the parent (DSI node)."

 The information which is missing is the answer for WHY? Why are you
 doing this?
>>>
>>>
>>> The current mipi-dsi must have at least one OF graph.
>>> However, for example, dsi and panel are parent-child relationships,
>>> so OF graph is not needed, and fimd and dsi are not connected to the OF
>>> graph.
>>> In this case, an error occurred in dsi_parse in the code before patch
>>> (1/5).
>>
>> The error occurred in case of DSI + FIMD? I do not get it whether you
>> are removing the something which is not needed or fixing something.
>>
>>> So I modified dsi_parse_dt.
>>>
 Does the patch depends on 1/5?
>>>
>>>
>>> Yes, it is.
>>> The 2/5 to 5/5 patches depend on the 1/5 patch.
>>
>> So that's a break of DT ABI for no clear (yet) reasons. Please mention
>> this in 1/5 patch and explain what is really fixed.
>
>
> I would like to post the s6e63j0x03 panel driver for exynos3250.
> However, as Rob Herring noted, dsi + panel is a parental relationship,
> so OF grpah is not needed.
> Therefore, the current dsi_parse_dt function will throw an error,
> because there is no linked OF graph for case such as fimd + dsi + panel.
> I think that the OF graph of dsi should be deleted even if it is not
> the purpose of the s6e63j0x03 panel driver.
>
> So the 1/5 patch parse the Pll, burst and esc clock frequency properties
> in dsi_parse_dt and modified to create a bridge_node only if there is
> an OF graph associated with dsi.
>

Thanks, now it makes sense. Such clear explanation should be part of
commit 1/5 as a proof that ABI breakage is needed.

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

Re: [PATCH 2/5] arm64: dts: exynos: Move the clock-frequency property

[Krzysztof Kozlowski]

On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon  wrote:
>
>>
>> "Remove the ports node abd move burst and esc clock frequency properties
>> to the parent (DSI node)."
>>
>> The information which is missing is the answer for WHY? Why are you
>> doing this?
>
>
> The current mipi-dsi must have at least one OF graph.
> However, for example, dsi and panel are parent-child relationships,
> so OF graph is not needed, and fimd and dsi are not connected to the OF
> graph.
> In this case, an error occurred in dsi_parse in the code before patch (1/5).

The error occurred in case of DSI + FIMD? I do not get it whether you
are removing the something which is not needed or fixing something.

> So I modified dsi_parse_dt.
>
>>
>> Does the patch depends on 1/5?
>
>
> Yes, it is.
> The 2/5 to 5/5 patches depend on the 1/5 patch.

So that's a break of DT ABI for no clear (yet) reasons. Please mention
this in 1/5 patch and explain what is really fixed.

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

Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node

[Liviu Dudau]

Hi Rob,

On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote:
> Convert drivers to use the new of_graph_get_remote_node() helper
> instead of parsing the endpoint node and then getting the remote device
> node. Now drivers can just specify the device node and which
> port/endpoint and get back the connected remote device node. The details
> of the graph binding are nicely abstracted into the core OF graph code.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 22 ++---
>  drivers/gpu/drm/arm/malidp_drv.c| 29 ++-

For the HDLCD and Mali DP part you can also add:

Tested-by: Liviu Dudau 

Best regards,
Liviu

>  drivers/gpu/drm/bridge/adv7511/adv7533.c| 12 +
>  drivers/gpu/drm/bridge/dumb-vga-dac.c   | 15 ++
>  drivers/gpu/drm/bridge/ti-tfp410.c  | 15 ++
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 27 +-
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 26 ++
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 30 +--
>  drivers/gpu/drm/mediatek/mtk_dpi.c  | 12 ++---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++
>  drivers/gpu/drm/meson/meson_drv.c   | 12 ++---
>  drivers/gpu/drm/meson/meson_venc_cvbs.c | 19 ++-
>  drivers/gpu/drm/msm/dsi/dsi_host.c  |  3 +-
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +--
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 11 +
>  drivers/gpu/drm/tilcdc/tilcdc_external.c| 66 
> +++--
>  drivers/gpu/drm/vc4/vc4_dpi.c   | 15 ++
>  20 files changed, 64 insertions(+), 351 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e5f4f4a6546d..0f70f5fe9970 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -430,29 +430,13 @@ static int compare_dev(struct device *dev, void *data)
>  
>  static int hdlcd_probe(struct platform_device *pdev)
>  {
> - struct device_node *port, *ep;
> + struct device_node *port;
>   struct component_match *match = NULL;
>  
> - if (!pdev->dev.of_node)
> - return -ENODEV;
> -
>   /* there is only one output port inside each device, find it */
> - ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> - if (!ep)
> - return -ENODEV;
> -
> - if (!of_device_is_available(ep)) {
> - of_node_put(ep);
> + port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0);
> + if (!port)
>   return -ENODEV;
> - }
> -
> - /* add the remote encoder port as component */
> - port = of_graph_get_remote_port_parent(ep);
> - of_node_put(ep);
> - if (!port || !of_device_is_available(port)) {
> - of_node_put(port);
> - return -EAGAIN;
> - }
>  
>   drm_of_component_match_add(>dev, , compare_dev, port);
>   of_node_put(port);
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 32f746e31379..bfa04be7f5de 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -262,7 +262,6 @@ static int malidp_bind(struct device *dev)
>  {
>   struct resource *res;
>   struct drm_device *drm;
> - struct device_node *ep;
>   struct malidp_drm *malidp;
>   struct malidp_hw_device *hwdev;
>   struct platform_device *pdev = to_platform_device(dev);
> @@ -360,12 +359,7 @@ static int malidp_bind(struct device *dev)
>   goto init_fail;
>  
>   /* Set the CRTC's port so that the encoder component can find it */
> - ep = of_graph_get_next_endpoint(dev->of_node, NULL);
> - if (!ep) {
> - ret = -EINVAL;
> - goto port_fail;
> - }
> - malidp->crtc.port = of_get_next_parent(ep);
> + malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0);
>  
>   ret = component_bind_all(dev, drm);
>   if (ret) {
> @@ -418,9 +412,7 @@ static int malidp_bind(struct device *dev)
>  irq_init_fail:
>   component_unbind_all(dev, drm);
>  bind_fail:
> - of_node_put(malidp->crtc.port);
>   malidp->crtc.port = NULL;
> -port_fail:
>   malidp_fini(drm);
>  init_fail:
>   drm->dev_private = NULL;
> @@ -478,29 +470,16 @@ static int malidp_compare_dev(struct device *dev, void 
> *data)
>  
>  static int malidp_platform_probe(struct platform_device *pdev)
>  {
> - 

Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement

[Marek Vasut]

On 02/08/2017 08:17 AM, Daniel Vetter wrote:
> On Tue, Feb 7, 2017 at 11:31 PM, Marek Vasut  wrote:
>> On 02/07/2017 11:15 PM, Daniel Vetter wrote:
>>> On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote:
 On 02/02/2017 10:26 PM, Fabio Estevam wrote:
> From: Fabio Estevam 
>
> Currently the framebuffer content is displayed with incorrect offsets
> in both the vertical and horizontal directions.
>
> The fbdev version of the driver does not show this problem. Breno Lima
> dumped the eLCDIF controller registers on both the drm and fbdev drivers
> and noticed that the VDCTRL3 register is configured incorrectly in the
> drm driver.
>
> The fbdev driver calculates the vertical and horizontal wait counts
> of the VDCTRL3 register by doing: back porch + sync length.
>
> Looking at the horizontal and vertical timing diagram from
> include/drm/drm_modes.h this value corresponds to:
>
> crtc_[hv]total - crtc_[hv]sync_start
>
> So fix the VDCTRL3 register setting accordingly so that the eLCDIF
> controller can properly show the framebuffer content in the correct
> position.
>
> Reported-by: Breno Lima 
> Signed-off-by: Fabio Estevam 

 Tested-by: Marek Vasut 
>>>
>>> You're listed as maintainer in MAINTAINERS, replying with tested-by is
>>> super confusing. Did you pick this up and will do a pull request?
>>
>> No
>>
>>> Do you expect someone else to pick this up?
>>
>> The last patches for mxsfb were picked by you, but if you expect me to
>> pick the mxsfb patches through my own tree and then submit PR, I can do
>> that.
> 
> I apply trivial patches as a welcoming gesture for new folks, but
> that's generally about it. Anyway, if you expect drm-misc maintainers
> to pick up stuff then you need to tell us, otherwise the patch will be
> lost. But then if you want mxsfb maintained in drm-misc I'd say better
> to get commit rights and join the club :-) Just ping on #dri-devel on
> freenode.

Ha, I see. I'll ping you on dri-devel shortly.

> -Daniel
> 


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

Re: [PATCH 2/5] arm64: dts: exynos: Move the clock-frequency property

[Hoegeun Kwon]

On 02/08/2017 04:32 PM, Krzysztof Kozlowski wrote:

On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon  wrote:

"Remove the ports node abd move burst and esc clock frequency properties
to the parent (DSI node)."

The information which is missing is the answer for WHY? Why are you
doing this?


The current mipi-dsi must have at least one OF graph.
However, for example, dsi and panel are parent-child relationships,
so OF graph is not needed, and fimd and dsi are not connected to the OF
graph.
In this case, an error occurred in dsi_parse in the code before patch (1/5).

The error occurred in case of DSI + FIMD? I do not get it whether you
are removing the something which is not needed or fixing something.


So I modified dsi_parse_dt.


Does the patch depends on 1/5?


Yes, it is.
The 2/5 to 5/5 patches depend on the 1/5 patch.

So that's a break of DT ABI for no clear (yet) reasons. Please mention
this in 1/5 patch and explain what is really fixed.


I would like to post the s6e63j0x03 panel driver for exynos3250.
However, as Rob Herring noted, dsi + panel is a parental relationship,
so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi + panel.
I think that the OF graph of dsi should be deleted even if it is not
the purpose of the s6e63j0x03 panel driver.

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

Best Regards,
Hoegeun



Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




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

Re: [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Maxime Ripard]

Hi Rob,

On Mon, Feb 06, 2017 at 11:32:01AM -0600, Rob Herring wrote:
> On Mon, Feb 06, 2017 at 11:03:01AM +0100, Maxime Ripard wrote:
> > Hi Rob,
> > 
> > On Fri, Feb 03, 2017 at 09:36:34PM -0600, Rob Herring wrote:
> > > Similar to the previous commit, convert drivers open coding OF graph
> > > parsing to use drm_of_find_panel_or_bridge instead.
> > > 
> > > This changes some error messages to debug messages (in the graph core).
> > > Graph connections are often "no connects" depending on the particular
> > > board, so we want to avoid spurious messages. Plus the kernel is not a
> > > DT validator.
> > > 
> > > Signed-off-by: Rob Herring 
> > > ---
> > 
> > [..]
> > 
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> > > b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> > > index f5e86fe7750e..4720725b0fb0 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> > > @@ -15,6 +15,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  
> > >  #include "sun4i_drv.h"
> > > @@ -217,12 +218,10 @@ int sun4i_rgb_init(struct drm_device *drm)
> > >   rgb->drv = drv;
> > >   encoder = >encoder;
> > >  
> > > - tcon->panel = sun4i_tcon_find_panel(tcon->dev->of_node);
> > > - encoder->bridge = sun4i_tcon_find_bridge(tcon->dev->of_node);
> > > - if (IS_ERR(tcon->panel) && IS_ERR(encoder->bridge)) {
> > > - dev_info(drm->dev, "No panel or bridge found... RGB output 
> > > disabled\n");
> > > - return 0;
> > > - }
> > > + ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
> > > +   >panel, >bridge);
> > > + if (ret)
> > > + return ret;
> > 
> > It used to ignore the error if it couldn't find the bridge. This will
> > break the probe.
> 
> Well, I got it half right. :) The probe does that, but this needs to 
> too.
> 
> > >  
> > >   drm_encoder_helper_add(>encoder,
> > >  _rgb_enc_helper_funcs);
> > > @@ -239,7 +238,7 @@ int sun4i_rgb_init(struct drm_device *drm)
> > >   /* The RGB encoder can only work with the TCON channel 0 */
> > >   rgb->encoder.possible_crtcs = BIT(0);
> > >  
> > > - if (!IS_ERR(tcon->panel)) {
> > > + if (tcon->panel) {
> > >   drm_connector_helper_add(>connector,
> > >_rgb_con_helper_funcs);
> > >   ret = drm_connector_init(drm, >connector,
> > > @@ -260,7 +259,7 @@ int sun4i_rgb_init(struct drm_device *drm)
> > >   }
> > >   }
> > >  
> > > - if (!IS_ERR(encoder->bridge)) {
> > > + if (encoder->bridge) {
> > >   encoder->bridge->encoder = >encoder;
> > >  
> > >   ret = drm_bridge_attach(drm, encoder->bridge);
> > > @@ -268,8 +267,6 @@ int sun4i_rgb_init(struct drm_device *drm)
> > >   dev_err(drm->dev, "Couldn't attach our bridge\n");
> > >   goto err_cleanup_connector;
> > >   }
> > > - } else {
> > > - encoder->bridge = NULL;
> > >   }
> > >  
> > >   return 0;
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > index ea2906f87cb9..2e4e365cecf9 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > @@ -15,13 +15,12 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > -#include 
> > > +#include 
> > >  
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > -#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -405,74 +404,6 @@ static int sun4i_tcon_init_regmap(struct device *dev,
> > >   return 0;
> > >  }
> > >  
> > > -struct drm_panel *sun4i_tcon_find_panel(struct device_node *node)
> > > -{
> > > - struct device_node *port, *remote, *child;
> > > - struct device_node *end_node = NULL;
> > > -
> > > - /* Inputs are listed first, then outputs */
> > > - port = of_graph_get_port_by_id(node, 1);
> > > -
> > > - /*
> > > -  * Our first output is the RGB interface where the panel will
> > > -  * be connected.
> > > -  */
> > > - for_each_child_of_node(port, child) {
> > > - u32 reg;
> > > -
> > > - of_property_read_u32(child, "reg", );
> > > - if (reg == 0)
> > > - end_node = child;
> > > - }
> > > -
> > > - if (!end_node) {
> > > - DRM_DEBUG_DRIVER("Missing panel endpoint\n");
> > > - return ERR_PTR(-ENODEV);
> > > - }
> > > -
> > > - remote = of_graph_get_remote_port_parent(end_node);
> > > - if (!remote) {
> > > - DRM_DEBUG_DRIVER("Unable to parse remote node\n");
> > > - return ERR_PTR(-EINVAL);
> > > - }
> > > -
> > > - return of_drm_find_panel(remote) ?: ERR_PTR(-EPROBE_DEFER);
> > 
> > And the panel is only one of our endpoints, which is optional, while
> > other endpoints are mandatory. This means that we might very well have
> > an endpoint that is not a panel or a bridge. In this case, I think
> > your function will return an error and will be treated as such, 

RE: drm/edid: Don't print an error if the checksum of a CEA block is wrong

[Tahvanainen, Jari]

I applied this change on the couple-days old drm-tip, and was not able to get 
any "EDID checksum is invalid" messages with it on my SKL. Without this patch I 
could generate the ERROR quite easily by switching the outputs and displays 
manually.
I don't know if this hides something that it should not but it seem to work for 
the problem related the noise on Patchwork CI execution caused by these EDID 
checksum is invalid messages.

Tested-by: Jari Tahvanainen 

-Original Message-
From: Tomeu Vizoso [mailto:tomeu.viz...@collabora.com] 
Sent: Thursday, December 8, 2016 3:12 PM
To: linux-ker...@vger.kernel.org
Cc: Tomeu Vizoso ; Tomi Sarvela 
; intel-...@lists.freedesktop.org; David Airlie 
; dri-devel@lists.freedesktop.org; Daniel Vetter 

Subject: drm/edid: Don't print an error if the checksum of a CEA block is wrong

It's common to share screens within CI labs, and it's also common for KVM 
switches to alter the contents of the CEA block but leave the checksum outdated.

So in this case, print a debug message instead of an error.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Cc: Chris Wilson 
Cc: Tomi Sarvela 
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Tomeu Vizoso 
---
 drivers/gpu/drm/drm_edid.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 
6798c3ad9d53..db79bc949216 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1128,16 +1128,19 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid,
 
csum = drm_edid_block_checksum(raw_edid);
if (csum) {
-   if (print_bad_edid) {
-   DRM_ERROR("EDID checksum is invalid, remainder is 
%d\n", csum);
-   }
-
if (edid_corrupt)
*edid_corrupt = true;
 
/* allow CEA to slide through, switches mangle this */
-   if (raw_edid[0] != 0x02)
+   if (raw_edid[0] == CEA_EXT) {
+   DRM_DEBUG("EDID checksum is invalid, remainder is 
%d\n", csum);
+   DRM_DEBUG("Assuming a KVM switch modified the CEA block 
but left the original checksum\n");
+   } else {
+   if (print_bad_edid)
+   DRM_ERROR("EDID checksum is invalid, remainder 
is %d\n", csum);
+
goto bad;
+   }
}
 
/* per-block-type checks */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

[Ayaka]

從我的 iPad 傳送

> Mauro Carvalho Chehab  於 2017年2月3日 下午10:04 寫道：
> 
> Em Thu, 5 Jan 2017 20:27:17 +0200
> Sakari Ailus  escreveu:
> 
>> Hi Randy,
>> 
>>> On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
>>> 
>>> 
 On 01/05/2017 06:30 PM, Sakari Ailus wrote:  
 Hi Randy,
 
 Thanks for the update.
 
> On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:  
> The formats added by this patch are:
>V4L2_PIX_FMT_P010
>V4L2_PIX_FMT_P010M
>V4L2_PIX_FMT_P016
>V4L2_PIX_FMT_P016M
> Currently, none of driver uses those format, but some video device
> has been confirmed with could as those format for video output.
> The Rockchip's new decoder has supported those 10 bits format for
> profile_10 HEVC/AVC video.
> 
> Signed-off-by: Randy Li 
> 
> v4l2
> ---
> Documentation/media/uapi/v4l/pixfmt-p010.rst  |  86 
> Documentation/media/uapi/v4l/pixfmt-p010m.rst |  94 ++
> Documentation/media/uapi/v4l/pixfmt-p016.rst  | 126 
> 
> Documentation/media/uapi/v4l/pixfmt-p016m.rst | 136 
> ++  
 You need to include the formats in pixfmt.rst in order to compile the
 documentation.
 
 $ make htmldocs
 
 And you'll find it in Documentation/output/media/uapi/v4l/v4l2.html .
 
 In Debian you'll need to install sphinx-common and python3-sphinx-rtd-theme
 .  
>>> OK, I would fix them in new version.
>>> The view of byte order for P010 serial is left empty, it is a little hard
>>> for me to use flat-table to draw them. Is there possible to use something
>>> like latex to do this job?  
>> 
>> Hmm. Not as far as I know. We recently switched from DocBook mostly due to
>> ReST being more simple to use AFAIU. I think LaTeX output could be produced
>> ReST, that might not be very helpful here though.
> 
> No, you can't use LaTeX, as it won't be properly displayed on all output
> formats. There are a few options to define tables in ReST, but we prefer
> using flat-table because the other formats are harder to maintain at the
> V4L2 uAPI documentation.
> 
> Just one note about this series: it won't be merged upstream until
> someone adds a driver needing those pixel formats.
> 
I made a mistake, the pixel format I want is not P010, I would post a new patch 
for that.
> Regards,
> Mauro
> 
> 
> Thanks,
> Mauro

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

Re: [PATCH 2/5] arm64: dts: exynos: Move the clock-frequency property

[Hoegeun Kwon]

Hi krzysztof,



On 02/08/2017 05:13 AM, Krzysztof Kozlowski wrote:

Hi,

I think the subject is not really matching the real work. You are rather
removing the OF graph from DSI node.

On Mon, Feb 06, 2017 at 11:19:41AM +0900, Hoegeun Kwon wrote:

The OF graph is not needed because the panel is a child of dsi. So
removed the ports and moved burst, esc clock-frequency property to the
top.

Keep the commit style and tense - imperative mode (see
submitting-patches.rstsubmitting-patches.rst), so last sentence could
look like:


Hi Krzysztof,

Thanks for your review.
I will write a clear subject on the next version.



"Remove the ports node abd move burst and esc clock frequency properties
to the parent (DSI node)."

The information which is missing is the answer for WHY? Why are you
doing this?


The current mipi-dsi must have at least one OF graph.
However, for example, dsi and panel are parent-child relationships,
so OF graph is not needed, and fimd and dsi are not connected to the OF 
graph.

In this case, an error occurred in dsi_parse in the code before patch (1/5).
So I modified dsi_parse_dt.



Does the patch depends on 1/5?


Yes, it is.
The 2/5 to 5/5 patches depend on the 1/5 patch.

Best regards,
Hoegeun



Best regards,
Krzysztof


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

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 6ce93a3..77ba238 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -298,23 +298,11 @@
status = "okay";
vddcore-supply = <_reg>;
vddio-supply = <_reg>;
+   samsung,burst-clock-frequency = <51200>;
+   samsung,esc-clock-frequency = <1600>;
samsung,pll-clock-frequency = <2400>;
pinctrl-names = "default";
pinctrl-0 = <_irq>;
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   samsung,burst-clock-frequency = <51200>;
-   samsung,esc-clock-frequency = <1600>;
-   };
-   };
-   };
  };
  
   {

--
1.9.1






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

[PATCH] drm/imx: imx-tve: Do not set the regulator voltage

[Fabio Estevam]

Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:

63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22

When the 'dac-supply' is not passed in the device tree a dummy regulator is
used and setting its voltage is not allowed.

To fix this issue, do not set the dac-supply voltage inside the driver
and let its voltage be specified in the device tree.

Print a warning if the the 'dac-supply' voltage has a value different
from 2.75V.

Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by 
regulator_set_voltage()")
Cc:  # 4.8+
Suggested-by: Lucas Stach 
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/imx/imx-tve.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 8f8aa4a..f20a3e0 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -98,6 +98,8 @@
 /* TVE_TST_MODE_REG */
 #define TVE_TVDAC_TEST_MODE_MASK   (0x7 << 0)
 
+#define IMX_TVE_DAC_VOLTAGE275
+
 enum {
TVE_MODE_TVOUT,
TVE_MODE_VGA,
@@ -616,9 +618,9 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
 
tve->dac_reg = devm_regulator_get(dev, "dac");
if (!IS_ERR(tve->dac_reg)) {
-   ret = regulator_set_voltage(tve->dac_reg, 275, 275);
-   if (ret)
-   return ret;
+   if (regulator_get_voltage(tve->dac_reg) != IMX_TVE_DAC_VOLTAGE)
+   dev_warn(dev, "dac voltage is %d uV instead of %d uV\n",
+ret, IMX_TVE_DAC_VOLTAGE);
ret = regulator_enable(tve->dac_reg);
if (ret)
return ret;
-- 
2.7.4

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

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Martin Peres]

On 06/02/17 17:50, Martin Peres wrote:

On 03/02/17 10:04, Daniel Vetter wrote:

On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:

On 01/02/17 22:05, Manasi Navare wrote:

On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:

Jani Nikula  writes:


On Tue, 31 Jan 2017, Eric Anholt  wrote:

Martin Peres  writes:


Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending
connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.

When available, we should use the link-status information to reset
the wanted mode.

Signed-off-by: Martin Peres 

If I understand this right, there are two failure modes being
handled:

1) A mode that won't actually work because the link isn't good
enough.

2) A mode that should work, but link parameters were too
optimistic and
if we just ask the kernel to set the mode again it'll use more
conservative parameters that work.

This patch seems good for 2).  For 1), the drmmode_set_mode_major is
going to set our old mode back.  Won't the modeset then fail to link
train again, and bring us back into this loop?  The only escape
that I
see would be some other userspace responding to the advertised
mode list
changing, and then asking X to modeset to something new.

To avoid that failure busy loop, should we re-fetching modes at this
point, and only re-setting if our mode still exists?

Disclaimer: I don't know anything about the internals of the
modesetting
driver.

Perhaps we can identify the two cases now, but I'd put this more
generally: if the link status has gone bad, it's an indicator to
userspace that the circumstances may have changed, and userspace
should
query the kernel for the list of available modes again. It should no
longer trust information obtained prior to getting the bad link
status,
including the current mode.

But specifically, I think you're right, and AFAICT asking for the
list
of modes again is the only way for the userspace to distinguish
between
the two cases. I don't think there's a shortcut for deciding the
current
mode is still valid.

To avoid the busy-loop problem, I think I'd like this patch to
re-query
the kernel to ask about the current mode list, and only try to re-set
the mode if our mode is still there.

If the mode isn't there, then it's up to the DE to take action in
response to the notification of new modes.  If you don't have a DE to
take appropriate action, you're kind of out of luck.

As far as the ABI goes, this seems fine to me.  The only concern I had
about ABI was having to walk all the connectors on every uevent to see
if any had gone bad -- couldn't we have a flag of some sort about what
the uevent indicates?  But uevents should be super rare, so I'd say
the
kernel could go ahead with the current plan.

Yes I agree. The kernel sets the link status BAD as soona s link
training fails
but does not prune the modes until a new modelist is requested by
the userspace.
So this patch should re query the mode list as soon as it sees the
link status
BAD in order for the kernel to validate the modes again based on new
link
paarmeters and send a new mode list back.

Seems like a bad behaviour from the kernel, isn't it? It should return
immediatly
if the mode is gonna be pruned :s

The mode list pruning isn't relevant for modeesets, the kernel doesn't
validate requested modes against that. The mode list is purely for
userspace's information. Which means updating it only when userspace asks
for it is fine.


Hmm, ok. Fair enough!


I also thought some more about the loop when we're stuck on BAD, and I
think it shouldn't happen: When the link goes BAD we update the link
parameter values to the new limits, and the kernel will reject any mode
that won't fit anymore. Of course you might be unlucky, and the new link
limits are also not working, but eventually you're stuck at the "you're
link is broken, sry" stage, where the kernel rejects everything :-)

So I think the busy-loop has strictly a limited amount of time until it
runs out of steam.


OK, I have given it more thoughts and discussed with Ville and Chris IRL or
on IRC.

My current proposal is based on the idea that the kernel should reject a
mode
it knows it cannot set. This is already largely tested in real life: Try
setting 4K@60Hz on an HDMI 1.x monitor, it should immediately fail on
prepare(). For this proposal to work, we would need to put in the ABI
that a
driver that sets the link-status to BAD should also make sure that whatever
the userspace does, no infinite loop should be created (by changing the
maximum link characteristics before setting the link-status property).

Re-probing the list of modes and 

Re: [PATCH v6 0/6] Rockchip dw-mipi-dsi driver

[Sean Paul]

On Wed, Feb 08, 2017 at 10:25:16AM +0800, Chris Zhong wrote:
> Hi all
> 
> This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of
> RK3399 is almost the same as RK3288, except a little bit of difference
> in phy clock controlling and port id selection register. These patches
> add RK3399 support and the power domain support.
> 
> And these patches base on John Keeping's v3 patches[0], it fixes many bugs,
> they have been tested on rk3288 evb board.
> 

Hi Chris,
The set looks good with the exception of 4/6, since we don't have any bounds
checking in vop yet. 

Once the bounds checking is in place and John's set is merged, this set can be
pulled into -misc.

Thanks,

Sean


> [0]:
> [01/24] https://patchwork.kernel.org/patch/9544089
> [02/24] https://patchwork.kernel.org/patch/9544061
> [03/24] https://patchwork.kernel.org/patch/9544065
> [04/24] https://patchwork.kernel.org/patch/9544077
> [05/24] https://patchwork.kernel.org/patch/9544033
> [06/24] https://patchwork.kernel.org/patch/9544037
> [07/24] https://patchwork.kernel.org/patch/9544029
> [08/24] https://patchwork.kernel.org/patch/9544031
> [09/24] https://patchwork.kernel.org/patch/9544083
> [10/24] https://patchwork.kernel.org/patch/9544063
> [11/24] https://patchwork.kernel.org/patch/9544085
> [12/24] https://patchwork.kernel.org/patch/9544093
> [13/24] https://patchwork.kernel.org/patch/9544081
> [14/24] https://patchwork.kernel.org/patch/9544057
> [15/24] https://patchwork.kernel.org/patch/9544079
> [16/24] https://patchwork.kernel.org/patch/9544035
> [17/24] https://patchwork.kernel.org/patch/9544105
> [18/24] https://patchwork.kernel.org/patch/9544059
> [21/24] https://patchwork.kernel.org/patch/9544009
> [22/24] https://patchwork.kernel.org/patch/9544049
> [23/24] https://patchwork.kernel.org/patch/9544055
> [24/24] https://patchwork.kernel.org/patch/9544109
> 
> 
> Changes in v6:
> - no need check phy_cfg_clk before enable/disable
> 
> Changes in v5:
> - check the error of phy_cfg_clk in dw_mipi_dsi_bind
> 
> Changes in v4:
> - remove the unrelated change
> 
> Changes in v3:
> - base on John Keeping's patch series
> 
> Chris Zhong (6):
>   dt-bindings: add rk3399 support for dw-mipi-rockchip
>   drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
>   drm/rockchip/dsi: dw-mipi: correct the coding style
>   drm/rockchip/dsi: remove mode_valid function
>   dt-bindings: add power domain node for dw-mipi-rockchip
>   drm/rockchip/dsi: add dw-mipi power domain support
> 
>  .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   7 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 156 
> -
>  2 files changed, 98 insertions(+), 65 deletions(-)
> 
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v6 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi

[Sean Paul]

On Wed, Feb 08, 2017 at 10:25:18AM +0800, Chris Zhong wrote:
> The vopb/vopl switch register of RK3399 mipi is different from RK3288,
> the default setting for mipi dsi mode is different too, so add a
> of_device_id structure to distinguish them, and make sure set the
> correct mode before mipi phy init.
> 

Reviewed-by: Sean Paul 

> Signed-off-by: Chris Zhong 
> Signed-off-by: Mark Yao 
> 
> ---
> 
> Changes in v6:
> - no need check phy_cfg_clk before enable/disable
> 
> Changes in v5:
> - check the error of phy_cfg_clk in dw_mipi_dsi_bind
> 
> Changes in v4:
> - remove the unrelated change
> 
> Changes in v3:
> - base on John Keeping's patch series
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 72 
> +-
>  1 file changed, 62 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 3f24333..8f60b89 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -29,9 +29,17 @@
>  
>  #define DRIVER_NAME"dw-mipi-dsi"
>  
> -#define GRF_SOC_CON60x025c
> -#define DSI0_SEL_VOP_LIT(1 << 6)
> -#define DSI1_SEL_VOP_LIT(1 << 9)
> +#define RK3288_GRF_SOC_CON6  0x025c
> +#define RK3288_DSI0_SEL_VOP_LIT  BIT(6)
> +#define RK3288_DSI1_SEL_VOP_LIT  BIT(9)
> +
> +#define RK3399_GRF_SOC_CON19 0x6250
> +#define RK3399_DSI0_SEL_VOP_LIT  BIT(0)
> +#define RK3399_DSI1_SEL_VOP_LIT  BIT(4)
> +
> +/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
> +#define RK3399_GRF_SOC_CON22 0x6258
> +#define RK3399_GRF_DSI_MODE  0x
>  
>  #define DSI_VERSION  0x00
>  #define DSI_PWR_UP   0x04
> @@ -265,6 +273,11 @@ enum {
>  };
>  
>  struct dw_mipi_dsi_plat_data {
> + u32 dsi0_en_bit;
> + u32 dsi1_en_bit;
> + u32 grf_switch_reg;
> + u32 grf_dsi0_mode;
> + u32 grf_dsi0_mode_reg;
>   unsigned int max_data_lanes;
>   enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
>  struct drm_display_mode *mode);
> @@ -281,6 +294,7 @@ struct dw_mipi_dsi {
>  
>   struct clk *pllref_clk;
>   struct clk *pclk;
> + struct clk *phy_cfg_clk;
>  
>   unsigned int lane_mbps; /* per lane */
>   u32 channel;
> @@ -425,6 +439,12 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
>   dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
>  
> + ret = clk_prepare_enable(dsi->phy_cfg_clk);
> + if (ret) {
> + dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
> + return ret;
> + }
> +
>   dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
>VCO_RANGE_CON_SEL(vco) |
>VCO_IN_CAP_CON_LOW |
> @@ -481,17 +501,18 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
>   if (ret < 0) {
>   dev_err(dsi->dev, "failed to wait for phy lock state\n");
> - return ret;
> + goto phy_init_end;
>   }
>  
>   ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
>val, val & STOP_STATE_CLK_LANE, 1000,
>PHY_STATUS_TIMEOUT_US);
> - if (ret < 0) {
> + if (ret < 0)
>   dev_err(dsi->dev,
>   "failed to wait for phy clk lane stop state\n");
> - return ret;
> - }
> +
> +phy_init_end:
> + clk_disable_unprepare(dsi->phy_cfg_clk);
>  
>   return ret;
>  }
> @@ -960,6 +981,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>  {
>   struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
>   struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> + const struct dw_mipi_dsi_plat_data *pdata = dsi->pdata;
>   int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
>   u32 val;
>   int ret;
> @@ -985,6 +1007,10 @@ static void dw_mipi_dsi_encoder_enable(struct 
> drm_encoder *encoder)
>   dw_mipi_dsi_dphy_interface_config(dsi);
>   dw_mipi_dsi_clear_err(dsi);
>  
> + if (pdata->grf_dsi0_mode_reg)
> + regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
> +  pdata->grf_dsi0_mode);
> +
>   dw_mipi_dsi_phy_init(dsi);
>   dw_mipi_dsi_wait_for_two_frames(mode);
>  
> @@ -998,11 +1024,11 @@ static void dw_mipi_dsi_encoder_enable(struct 
> drm_encoder *encoder)
>   clk_disable_unprepare(dsi->pclk);
>  
>   if (mux)
> - val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
> + val = 

[Bug 99552] Make Advanced Simulation Library (ASL) OpenCL GPU support work on Clover and RadeonSI

[bugzilla-daemon]

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

--- Comment #1 from Vedran Miletić  ---
How to test:

$ mkdir build; cd build
$ cmake -DWITH_TESTS=ON ..
$ make -j
$ make test

Right now, Mesa/LLVM latest git pulled half an hour ago I get:

Running tests...
Test project /users/miletivn/workspace/ASL/build
  Start  1: testABDFormat
 1/10 Test  #1: testABDFormat    Passed0.07 sec
  Start  2: testVectorOfElements
 2/10 Test  #2: testVectorOfElements .   Passed5.27 sec
  Start  3: testMatrixOfElements
 3/10 Test  #3: testMatrixOfElements .   Passed7.89 sec
  Start  4: testKernel
 4/10 Test  #4: testKernel ...***Exception: Other 13.94 sec
  Start  5: testOperators
 5/10 Test  #5: testOperators    Passed7.88 sec
  Start  6: testKernelMerger
 6/10 Test  #6: testKernelMerger .   Passed2.65 sec
  Start  7: testPrivateVar
 7/10 Test  #7: testPrivateVar ...***Exception: Other  3.22 sec
  Start  8: testASLData
 8/10 Test  #8: testASLData ..   Passed   13.72 sec
  Start  9: testDistanceFunction
 9/10 Test  #9: testDistanceFunction .   Passed   42.43 sec
  Start 10: testReductionFunction
10/10 Test #10: testReductionFunction    Passed   29.24 sec

80% tests passed, 2 tests failed out of 10

Label Time Summary:
DoublePrecision=  85.62 sec (3 tests)
Performance=   3.22 sec (1 test)

Total Test time (real) = 126.34 sec

The following tests FAILED:
  4 - testKernel (OTHER_FAULT)
  7 - testPrivateVar (OTHER_FAULT)
Errors while running CTest
Makefile:61: recipe for target 'test' failed
make: *** [test] Error 8

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

Re: [PATCH v3 00/23] Add vblank hooks to struct drm_crtc_funcs

[Sean Paul]

On Tue, Feb 07, 2017 at 05:16:12PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> The vblank is mostly CRTC specific and implemented as part of CRTC
> driver.  The first patch adds 3 vblank core<->driver hooks into struct
> drm_crtc_funcs, and plug them into core by adding wrapper functions for
> vblank handling code.  We effectively make the .get_vblank_counter hook
> optional by providing drm_vblank_no_hw_counter() as the default fallback
> in the wrapper function.
> 
> Patch #2 and #3 unexport function drm_vblank_no_hw_counter() by cleaning
> up its use, since it's already the default implememention for
> .get_vblank_counter hook anyway.
> 
> The rest of the series is trying to do a massive conversion to the new
> hooks for DRIVER_MODESET drivers.  But it only handles low-hanging
> fruit, and leaves out the ones that need a bit surgery, like gma500,
> i915, msm etc.  Most of conversion get done by simply moving code and
> making functions static, but imx and rockchip are great examples showing
> how driver code can be cleaned up with these new hooks.
> 

Hi Shawn,
Thanks for the cleanup, it looks great! Let's soak this on the list until next
week, if there are no objections from driver maintainers, I'll merge it to
-misc.

Sean


> The series is generated against branch drm-next.
> 
> Changes for v3:
>  - Let drm_vblank_no_hw_counter() be the last fallback for
>.get_vblank_counter() hook.
>  - Improve the kernel-doc for .get_vblank_counter() hook.
>  - Convert more DRIVER_MODESET drivers to new hooks.
> 
> Changes for v2:
>  - Wrap around core vblank handling code to save
>drm_crtc_enable[disable]_vblank() helpers
>  - Add .get_vblank_counter to struct drm_crtc_funcs
>  - Add some comments to link between two sets of hooks
>  - Add one hdlcd driver patch for example
> 
> Shawn Guo (23):
>   drm: add vblank hooks to struct drm_crtc_funcs
>   drm: remove drm_vblank_no_hw_counter assignment from driver code
>   drm: unexport function drm_vblank_no_hw_counter()
>   drm: hdlcd: use vblank hooks in struct drm_crtc_funcs
>   drm: malidp: use vblank hooks in struct drm_crtc_funcs
>   drm: armada: use vblank hooks in struct drm_crtc_funcs
>   drm: atmel: use vblank hooks in struct drm_crtc_funcs
>   drm: exynos: use vblank hooks in struct drm_crtc_funcs
>   drm: fsl-dcu: use vblank hooks in struct drm_crtc_funcs
>   drm: hibmc: use vblank hooks in struct drm_crtc_funcs
>   drm: kirin: use vblank hooks in struct drm_crtc_funcs
>   drm: imx: remove struct imx_drm_crtc and imx_drm_crtc_helper_funcs
>   drm: mediatek: use vblank hooks in struct drm_crtc_funcs
>   drm: meson: use vblank hooks in struct drm_crtc_funcs
>   drm: qxl: use vblank hooks in struct drm_crtc_funcs
>   drm: rcar-du: use vblank hooks in struct drm_crtc_funcs
>   drm: rockchip: remove struct rockchip_crtc_funcs
>   drm: shmobile: use vblank hooks in struct drm_crtc_funcs
>   drm: sun4i: use vblank hooks in struct drm_crtc_funcs
>   drm: tegra: use vblank hooks in struct drm_crtc_funcs
>   drm: tilcdc: use vblank hooks in struct drm_crtc_funcs
>   drm: vc4: use vblank hooks in struct drm_crtc_funcs
>   drm: zte: use vblank hooks in struct drm_crtc_funcs
> 
>  drivers/gpu/drm/arc/arcpgu_drv.c|   1 -
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  20 +
>  drivers/gpu/drm/arm/hdlcd_drv.c |  21 -
>  drivers/gpu/drm/arm/malidp_crtc.c   |  21 +
>  drivers/gpu/drm/arm/malidp_drv.c|  22 -
>  drivers/gpu/drm/armada/armada_crtc.c|  56 -
>  drivers/gpu/drm/armada/armada_crtc.h|   2 -
>  drivers/gpu/drm/armada/armada_drv.c |  17 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  21 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  22 -
>  drivers/gpu/drm/drm_irq.c   |  81 +--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c|  40 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h|   2 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   4 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |   8 --
>  drivers/gpu/drm/exynos/exynos_hdmi.c|   7 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  |  26 ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  26 --
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  20 +
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |  23 --
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  11 +--
>  drivers/gpu/drm/i915/i915_irq.c |   1 -
>  drivers/gpu/drm/imx/imx-drm-core.c  | 102 
> 
>  drivers/gpu/drm/imx/imx-drm.h   |  13 ---
>  drivers/gpu/drm/imx/ipuv3-crtc.c|  58 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   8 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |   2 -
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   4 -
>  

Re: [PATCH v3 10/23] drm: hibmc: use vblank hooks in struct drm_crtc_funcs

[Sean Paul]

On Tue, Feb 07, 2017 at 05:16:22PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
> 

Reviewed-by: Sean Paul 

> Signed-off-by: Shawn Guo 
> Cc: Xinliang Liu 
> ---
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 20 
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 22 --
>  2 files changed, 20 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> index c655883d3613..59542bddc980 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> @@ -423,6 +423,24 @@ static void hibmc_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   spin_unlock_irqrestore(>dev->event_lock, flags);
>  }
>  
> +static int hibmc_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct hibmc_drm_private *priv = crtc->dev->dev_private;
> +
> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
> +priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> +
> + return 0;
> +}
> +
> +static void hibmc_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct hibmc_drm_private *priv = crtc->dev->dev_private;
> +
> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
> +priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> +}
> +
>  static const struct drm_crtc_funcs hibmc_crtc_funcs = {
>   .page_flip = drm_atomic_helper_page_flip,
>   .set_config = drm_atomic_helper_set_config,
> @@ -430,6 +448,8 @@ static void hibmc_crtc_atomic_flush(struct drm_crtc *crtc,
>   .reset = drm_atomic_helper_crtc_reset,
>   .atomic_duplicate_state =  drm_atomic_helper_crtc_duplicate_state,
>   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> + .enable_vblank = hibmc_crtc_enable_vblank,
> + .disable_vblank = hibmc_crtc_disable_vblank,
>  };
>  
>  static const struct drm_crtc_helper_funcs hibmc_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 8cac70454b57..2ffdbf9801bd 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -37,26 +37,6 @@
>   .llseek = no_llseek,
>  };
>  
> -static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
> -{
> - struct hibmc_drm_private *priv =
> - (struct hibmc_drm_private *)dev->dev_private;
> -
> - writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
> -priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> -
> - return 0;
> -}
> -
> -static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
> -{
> - struct hibmc_drm_private *priv =
> - (struct hibmc_drm_private *)dev->dev_private;
> -
> - writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
> -priv->mmio + HIBMC_RAW_INTERRUPT_EN);
> -}
> -
>  irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>  {
>   struct drm_device *dev = (struct drm_device *)arg;
> @@ -84,8 +64,6 @@ irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>   .desc   = "hibmc drm driver",
>   .major  = 1,
>   .minor  = 0,
> - .enable_vblank  = hibmc_enable_vblank,
> - .disable_vblank = hibmc_disable_vblank,
>   .gem_free_object_unlocked = hibmc_gem_free_object,
>   .dumb_create= hibmc_dumb_create,
>   .dumb_map_offset= hibmc_dumb_mmap_offset,
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

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

[bugzilla-daemon]

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

--- Comment #5 from garththei...@hotmail.com ---
I am able to recreate this on Wine-git using modes default and nine.
Additionally this is also a problem in Crossover with Performance Enhanced
Graphics enabled.

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

[PATCH] drm-misc: quickstart paragraph

[Daniel Vetter]

I'm typing this too often on irc.

Acked-by: Sean Paul 
Signed-off-by: Daniel Vetter 
---
 drm-misc.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/drm-misc.rst b/drm-misc.rst
index 5c1bef57e3b7..73882dc55be6 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -20,6 +20,14 @@ reality, it is your assumed responsibility to update the 
rules.
 The workflow is heavily based upon the one used to maintain the Intel drm
 driver, see `drm-intel `_:
 
+Getting Started
+===
+
+First you need a `freedesktop.org account with the drm-misc group permission
+`_. Then you need to setup 
the
+branches and tooling, see the `getting started with dim `_
+guide.
+
 Branches
 
 
-- 
2.11.0

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

[PATCH v2] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Jyri Sarha]

Let's disable all scaling that requires horizontal decimation with
higher factor than 4, until we have better estimates of what we can
and can not do. However, NV12 color format appears to work Ok with
all decimation factors.

When decimating horizontally by more that 4 the dss is not able to
fetch the data in burst mode. When this happens it is hard to tell if
there enough bandwidth. Despite what theory says this appears to be
true also for 16-bit color formats.

Signed-off-by: Jyri Sarha 
---
Chnages since first version:
- "color_mode_to_bpp(color_mode) > 8" -> "color_mode != OMAP_DSS_COLOR_NV12"
  - commit message and comment updated too
- improve error print

 drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 5554b72..d956e626 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long 
pclk, unsigned long lclk,
return -EINVAL;
}
 
+   if (*decim_x > 4 && color_mode != OMAP_DSS_COLOR_NV12) {
+   /*
+* Let's disable all scaling that requires horizontal
+* decimation with higher factor than 4, until we have
+* better estimates of what we can and can not
+* do. However, NV12 color format appears to work Ok
+* with all decimation factors.
+*
+* When decimating horizontally by more that 4 the dss
+* is not able to fetch the data in burst mode. When
+* this happens it is hard to tell if there enough
+* bandwidth. Despite what theory says this appears to
+* be true also for 16-bit color formats.
+*/
+   DSSERR("Not enough bandwidth, too much downscaling 
(x-decimation factor %d > 4)", *decim_x);
+
+   return -EINVAL;
+   }
+
*core_clk = dispc.feat->calc_core_clk(pclk, in_width, in_height,
out_width, out_height, mem_to_mem);
return 0;
-- 
1.9.1

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

Re: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Tomi Valkeinen]

On 07/02/17 16:41, Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, 1 byte per pixel color format appear to work
> Ok with all decimation factors.
> 
> When decimating horizontally by more that 4 the dss is not able to
> fetch the data in burst mode. When this happens it is hard to tell if
> there enough bandwidth. Despite what theory says this appears to be
> true also for 16-bit color formats.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 5554b72..61daef6 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long 
> pclk, unsigned long lclk,
>   return -EINVAL;
>   }
>  
> + if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) {
> + /*
> +   Let's disable all scaling that requires horizontal
> +   decimation with higher factor than 4, until we have
> +   better estimates of what we can and can not
> +   do. However, 1 byte per pixel color format appear to
> +   work Ok with all decimation factors.
> +
> +   When decimating horizontally by more that 4 the dss
> +   is not able to fetch the data in burst mode. When
> +   this happens it is hard to tell if there enough
> +   bandwidth. Despite what theory says this appears to
> +   be true also for 16-bit color formats.
> + */
> + DSSERR("Not enough bandwidth (x-decimation factor %d > 4)",
> + *decim_x);

I think the error message could be improved. A normal user could hit
this when setting up a plane, and I'm quite sure the above doesn't give
any clue to the user what the issue is (too much downscaling).

 Tomi



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

Re: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Jyri Sarha]

On 02/08/17 13:25, Laurent Pinchart wrote:
> Hi Jyri,
> 
> Thank you for the patch.
> 
> On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
>> Let's disable all scaling that requires horizontal decimation with
>> higher factor than 4, until we have better estimates of what we can
>> and can not do. However, 1 byte per pixel color format appear to work
>> Ok with all decimation factors.
>>
>> When decimating horizontally by more that 4 the dss is not able to
>> fetch the data in burst mode. When this happens it is hard to tell if
>> there enough bandwidth. Despite what theory says this appears to be
>> true also for 16-bit color formats.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5554b72..61daef6 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
>> @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long
>> pclk, unsigned long lclk, return -EINVAL;
>>  }
>>
>> +if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) {
>> +/*
>> +  Let's disable all scaling that requires horizontal
>> +  decimation with higher factor than 4, until we have
>> +  better estimates of what we can and can not
>> +  do. However, 1 byte per pixel color format appear to
>> +  work Ok with all decimation factors.
>> +
>> +  When decimating horizontally by more that 4 the dss
>> +  is not able to fetch the data in burst mode. When
>> +  this happens it is hard to tell if there enough
>> +  bandwidth. Despite what theory says this appears to
>> +  be true also for 16-bit color formats.
>> +*/
>> +DSSERR("Not enough bandwidth (x-decimation factor %d > 4)",
>> +*decim_x);
>> +return -EINVAL;
> 
> This needs to be validated during the atomic check phase to avoid failures at 
> commit time that are much harder to handle properly.
> 

Sure, but I can not fix everything in one step. This is a first simple
quantitative test that is supposed to tell if scaling can be done
without synclost errors. Next step is to make dispc to not look to HW
for current clock settings, and then finally make all relevant check
callbacks (or some flag in the config callbacks) in dispc.

Anyway, there will be a v2 of this patch that tests color_mode !=
OMAP_DSS_COLOR_NV12 instead of color_mode_to_bpp(color_mode) > 8. The
NV12 appears to be the only color format that works reliably with
current implementation.

Best regards,
Jyri

>> +}
>> +
>>  *core_clk = dispc.feat->calc_core_clk(pclk, in_width, in_height,
>>  out_width, out_height, mem_to_mem);
>>  return 0;
> 

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

Re: [Intel-gfx] drm/edid: Don't print an error if the checksum of a CEA block is wrong

[Daniel Vetter]

On Wed, Feb 08, 2017 at 01:19:23PM +, Tahvanainen, Jari wrote:
> I applied this change on the couple-days old drm-tip, and was not able to get 
> any "EDID checksum is invalid" messages with it on my SKL. Without this patch 
> I could generate the ERROR quite easily by switching the outputs and displays 
> manually.
> I don't know if this hides something that it should not but it seem to work 
> for the problem related the noise on Patchwork CI execution caused by these 
> EDID checksum is invalid messages.
> 
> Tested-by: Jari Tahvanainen 
> 
> -Original Message-
> From: Tomeu Vizoso [mailto:tomeu.viz...@collabora.com] 
> Sent: Thursday, December 8, 2016 3:12 PM
> To: linux-ker...@vger.kernel.org
> Cc: Tomeu Vizoso ; Tomi Sarvela 
> ; intel-...@lists.freedesktop.org; David Airlie 
> ; dri-devel@lists.freedesktop.org; Daniel Vetter 
> 
> Subject: drm/edid: Don't print an error if the checksum of a CEA block is 
> wrong
> 
> It's common to share screens within CI labs, and it's also common for KVM 
> switches to alter the contents of the CEA block but leave the checksum 
> outdated.
> 
> So in this case, print a debug message instead of an error.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
> Cc: Chris Wilson 
> Cc: Tomi Sarvela 
> Cc: intel-...@lists.freedesktop.org
> Signed-off-by: Tomeu Vizoso 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_edid.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 
> 6798c3ad9d53..db79bc949216 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1128,16 +1128,19 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, 
> bool print_bad_edid,
>  
>   csum = drm_edid_block_checksum(raw_edid);
>   if (csum) {
> - if (print_bad_edid) {
> - DRM_ERROR("EDID checksum is invalid, remainder is 
> %d\n", csum);
> - }
> -
>   if (edid_corrupt)
>   *edid_corrupt = true;
>  
>   /* allow CEA to slide through, switches mangle this */
> - if (raw_edid[0] != 0x02)
> + if (raw_edid[0] == CEA_EXT) {
> + DRM_DEBUG("EDID checksum is invalid, remainder is 
> %d\n", csum);
> + DRM_DEBUG("Assuming a KVM switch modified the CEA block 
> but left the original checksum\n");
> + } else {
> + if (print_bad_edid)
> + DRM_ERROR("EDID checksum is invalid, remainder 
> is %d\n", csum);
> +
>   goto bad;
> + }
>   }
>  
>   /* per-block-type checks */
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

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

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #4 from Mike Lothian  ---
Which graphics mode are you using? Default, CMST or Gallium Nine?

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

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

[Sharma, Shashank]

Regards

Shashank


On 2/8/2017 5:06 PM, Jose Abreu wrote:

Hi,



On 07-02-2017 16:36, Thierry Reding wrote:

On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 2/7/2017 4:31 PM, Jose Abreu wrote:

Hi Shashank,



On 06-02-2017 13:59, Shashank Sharma wrote:

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.

Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.

Reviewed-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c  | 14 ++
   include/drm/drm_connector.h | 33 +
   2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96d3e47..a487b80 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
   }
   EXPORT_SYMBOL(drm_default_rgb_quant_range);
+static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
+const u8 *hf_vsdb)
+{
+   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+   if (hf_vsdb[6] & 0x80) {

BIT(7) ?

Yes, SCDC_present bit is bit 7, byte 6 in HF-VSDB. Am I missing something ?

+   hdmi->scdc.supported = true;
+   if (hf_vsdb[6] & 0x40)

BIT(6) ?

Yes, RR_Capable bit is bit 6, byte 6 in HF-VSDB.

I think what Jose was trying to say is that you should be using BIT(7)
instead of 0x80 and BIT(6) instead of 0x40. That said, I think either is
fine, but perhaps another idea would be to define macros for these. I
know that most (all?) of the EDID parsing code uses literals, so this is
consistent with existing code. Also usually code will be like:

if (hf_vsdb[X] & 0xYZ)
foo_supported = true;

So the meaning of the bit is easy to read from the context. I think
literals are fine in this case.

Thierry

Thats exactly what I meant :) I think with BIT(x) the code is
easier to read (my hex skills are not very good :)). Anyway, if
the remaining code uses literals then maybe its better to keep
consistency.

Thanks, then we will keep this code, as it is.
- Shashank

Best regards,
Jose Miguel Abreu



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

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

[Sharma, Shashank]

Regards

Shashank


On 2/8/2017 5:01 PM, Jose Abreu wrote:

Hi Shashank,



On 07-02-2017 16:19, Sharma, Shashank wrote:

Regards

Shashank


On 2/7/2017 4:44 PM, Jose Abreu wrote:

Hi Shashank,



On 06-02-2017 13:59, Shashank Sharma wrote:

HDMI 2.0 spec mandates scrambling for modes with pixel clock
higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.

This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC
read/write.
- Few new bools to reflect scrambling support and status.

V2: Addressed review comments from Thierry, Ville and Dhinakaran
Thierry:
- Mhz -> MHz in comments and commit message.
- i2c -> I2C in comments.
- Fix the function documentations, keep in sync with
drm_scdc_helper.c
- drm_connector -> DRM connector.
- Create structure for SCDC, and save scrambling status
inside that,
in a sub-structure.
- Call this sub-structure scrambling instead of scr_info.
- low_rates -> low_clocks in scrambling status structure.
- Store the return value of I2C read/write and print the
error code
  in case of failure.

Thierry and Ville:
- Move the scrambling enable/disable/query functions in
drm_scdc_helper.c file.
- Add drm_SCDC prefix for the functions.
- Optimize the return statement from function
drm_SCDC_check_scrambling_status.

Ville:
- Dont overwrite saved max TMDS clock value in display_info,
if max tmds clock from HF-VSDB is not > 340 MHz.
- drm_detect_hdmi_scrambling -> drm_parse_hdmi_forum_vsdb.
- Remove dynamic tracking of SCDC status from DRM layer,
force bool.
- Program clock ratio bit also, while enabling scrambling.

Dhinakaran:
   - Add a comment about *5000 while extracting max clock
supported.

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c|  33 -
   drivers/gpu/drm/drm_scdc_helper.c | 100
++
   include/drm/drm_connector.h   |  19 
   include/drm/drm_edid.h|   6 ++-
   include/drm/drm_scdc_helper.h |  20 
   5 files changed, 176 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c
b/drivers/gpu/drm/drm_edid.c
index a487b80..dc85eb9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
   #include 
   #include 
   #include 
+#include 
 #define version_greater(edid, maj, min) \
   (((edid)->version > (maj)) || \
@@ -3805,13 +3806,43 @@ enum hdmi_quantization_range
   static void drm_parse_hdmi_forum_vsdb(struct drm_connector
*connector,
const u8 *hf_vsdb)
   {
-struct drm_hdmi_info *hdmi = >display_info.hdmi;
+struct drm_display_info *display =
>display_info;
+struct drm_hdmi_info *hdmi = >hdmi;
 if (hf_vsdb[6] & 0x80) {
   hdmi->scdc.supported = true;
   if (hf_vsdb[6] & 0x40)
   hdmi->scdc.read_request = true;
   }
+
+/*
+ * All HDMI 2.0 monitors must support scrambling at
rates > 340 MHz.
+ * And as per the spec, three factors confirm this:
+ * * Availability of a HF-VSDB block in EDID (check)
+ * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's
check)
+ * * SCDC support available (let's check)
+ * Lets check it out.
+ */
+
+if (hf_vsdb[5]) {
+/* max clock is 5000 KHz times block value */
+u32 max_tmds_clock = hf_vsdb[5] * 5000;
+struct drm_scdc *scdc = >scdc;
+
+if (max_tmds_clock > 34) {
+display->max_tmds_clock = max_tmds_clock;
+DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+display->max_tmds_clock);
+}
+
+if (scdc->supported) {
+scdc->scrambling.supported = true;
+
+/* Few sinks support scrambling for cloks < 340M */
+if ((hf_vsdb[6] & 0x8))

BIT(3) ?

Yes, bit 3 is LTE_340Mcsc_scramble, indicating that the sink
support scrambling at rates below 340Mhz too, isn't it ?

+scdc->scrambling.low_rates = true;
+}
+}
   }
 static void drm_parse_hdmi_deep_color_info(struct
drm_connector *connector,
diff --git a/drivers/gpu/drm/drm_scdc_helper.c
b/drivers/gpu/drm/drm_scdc_helper.c
index fe0e121..311f62e 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
*/
 #include 
+#include 
 #include 
+#include 
 /**
* DOC: scdc helpers
@@ -109,3 +111,101 @@ ssize_t drm_scdc_write(struct
i2c_adapter *adapter, u8 offset,
   return err;
   }
   EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of
scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambling status.
+ *
+ * Returns:
+ * True if the scrambling is enabled, false 

Re: [PATCH v2 1/6] drm: Add SCDC helpers

[Sharma, Shashank]

Regards

Shashank


On 2/8/2017 4:57 PM, Jose Abreu wrote:

Hi Shashank,



On 07-02-2017 16:09, Sharma, Shashank wrote:

Thanks for the review Jose, my comments inline.


Regards

Shashank


On 2/7/2017 4:24 PM, Jose Abreu wrote:

Hi Shashank,


Sorry for the late review.


On 06-02-2017 13:59, Shashank Sharma wrote:

From: Thierry Reding 

SCDC is a mechanism defined in the HDMI 2.0 specification
that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and
provides the
symbolic names for the various registers defined in the
specification.

Signed-off-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
---
   Documentation/gpu/drm-kms-helpers.rst |  12 
   drivers/gpu/drm/Makefile  |   3 +-
   drivers/gpu/drm/drm_scdc_helper.c | 111

   include/drm/drm_scdc_helper.h | 132
++
   4 files changed, 257 insertions(+), 1 deletion(-)
   create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
   create mode 100644 include/drm/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
   .. kernel-doc:: drivers/gpu/drm/drm_edid.c
  :export:
   +SCDC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :export:
+
   Rectangle Utilities Reference
   =
   diff --git a/drivers/gpu/drm/Makefile
b/drivers/gpu/drm/Makefile
index 92de399..ad91cd9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o
drm_debugfs_crc.o
   drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
drm_probe_helper.o \
   drm_plane_helper.o drm_dp_mst_topology.o
drm_atomic_helper.o \
   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
-drm_simple_kms_helper.o drm_modeset_helper.o
+drm_simple_kms_helper.o drm_modeset_helper.o \
+drm_scdc_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) +=
drm_edid_load.o
   drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) +=
drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..fe0e121
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any
person obtaining a
+ * copy of this software and associated documentation files
(the "Software"),
+ * to deal in the Software without restriction, including
without limitation
+ * the rights to use, copy, modify, merge, publish,
distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons
to whom the
+ * Software is furnished to do so, subject to the following
conditions:
+ *
+ * The above copyright notice and this permission notice
(including the
+ * next paragraph) shall be included in all copies or
substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN
NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+#include 
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism
introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol
that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C
interface that
+ * is used to access EDID serves as the transport mechanism
for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * The number of bytes read from SCDC or a negative error
code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8
offset, void *buffer,
+  size_t size)
+{
+struct i2c_msg msgs[2] = {
+{
+.addr = SCDC_I2C_SLAVE_ADDRESS,
+.flags = 0,
+.len = 1,

.len = 

Re: [Intel-gfx] [patch v2] drm/i915/gvt/kvmgt: remove some dead code

[Joonas Lahtinen]

On ti, 2017-02-07 at 17:53 +0300, Dan Carpenter wrote:
> "caps.buf" is always NULL here and "caps.size" is always zero.  The code
> is a no-op and can be removed.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Joonas Lahtinen 

I assume Zhenyu will merge this through their tree.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #68 from Marek Olšák  ---
The long hangs are spent in an upload/decompression thread the game uses. The
thread doesn't use any GL calls.

My theory that's now confirmed was that the game maps buffers in VRAM and does
read-modify-write on that memory in that thread. We know that direct VRAM
access is uncached and super slow if it's not a series of sequential writes
that is write-combined on the CPU, which is like a write-only cache. Games
typically upload data using a sequential copy/fill, which is why we had not
seen this issue before.

If the game used the MAP READ flag, the driver would return a mapping in RAM
with caching enabled. You'll also get that if you set the CLIENT STORAGE bit in
glBufferStorage.

For completeness, you can also get a mapping in RAM that's uncached. The CPU
and GPU performance is somewhere between the VRAM and cached RAM. We use it for
streaming because the GPU has faster access to RAM uncached by the CPU.

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

Re: [PATCH v2 4/6] drm: scrambling support in drm layer

[Jani Nikula]

On Wed, 08 Feb 2017, Jose Abreu  wrote:
> Hi Jani,
>
>
>
> On 07-02-2017 15:09, Jani Nikula wrote:
>> On Tue, 07 Feb 2017, Jose Abreu  wrote:
>>> Hi Jani,
>>>
>>>
>>> On 07-02-2017 13:35, Jani Nikula wrote:
 On Tue, 07 Feb 2017, Jose Abreu  wrote:
>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>> +{
>> +u8 status;
>> +int ret;
>> +
>> +ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
>> +if (ret < 0) {
>> +DRM_ERROR("Failed to read scrambling status, error 
>> %d\n", ret);
>> +return false;
>> +}
>> +
>> +return status & SCDC_SCRAMBLING_STATUS;
> "return (status & SCDC_SCRAMBLING_STATUS) > 0;" ?
 What's the point in that?

 BR,
 Jani.


>>> Sorry, I didn't see the SCDC_SCRAMBLING_STATUS is BIT(0). Anyway,
>>> my intention was to return either 1 or 0 or else the value of the
>>> "and" would be returned. I think in x86 the bool is char, what
>>> could happen if SCDC_SCRAMBLING_STATUS was BIT(>7)? Does the cast
>>> work as expected?
>> The implicit type conversion works just fine.
>
> Hmm, are you sure? I'm reading this thread:
> http://yarchive.net/comp/linux/bool.html (see Linus last answer).

I think you're confusing ABI with what C guarantees. I don't think that
thread has any relevance here.

BR,
Jani.


>
> (This is just for curiosity anyway).
>
> Best regards,
> Jose Miguel Abreu
>
>>
>> BR,
>> Jani.
>>
>>> Best regards,
>>> Jose Miguel Abreu
>>>
>

-- 
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 v3 09/23] drm: fsl-dcu: use vblank hooks in struct drm_crtc_funcs

[Daniel Vetter]

On Tue, Feb 07, 2017 at 09:01:22PM -0800, Stefan Agner wrote:
> On 2017-02-07 01:16, Shawn Guo wrote:
> > From: Shawn Guo 
> > 
> > The vblank hooks in struct drm_driver are deprecated and only meant for
> > legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> > in struct drm_crtc_funcs should be used instead.
> > 
> > Signed-off-by: Shawn Guo 
> > Cc: Stefan Agner 
> 
> Acked-by: Stefan Agner 

Merged up to this one to drm-misc for 4.12, I'll give the others some more
time for maintainer acks.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 26 ++
> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 25 -
> >  2 files changed, 26 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> > index deb57435cc89..cc4e944a1d3c 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> > @@ -137,6 +137,30 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct
> > drm_crtc *crtc)
> > .mode_set_nofb = fsl_dcu_drm_crtc_mode_set_nofb,
> >  };
> >  
> > +static int fsl_dcu_drm_crtc_enable_vblank(struct drm_crtc *crtc)
> > +{
> > +   struct drm_device *dev = crtc->dev;
> > +   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > +   unsigned int value;
> > +
> > +   regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
> > +   value &= ~DCU_INT_MASK_VBLANK;
> > +   regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> > +
> > +   return 0;
> > +}
> > +
> > +static void fsl_dcu_drm_crtc_disable_vblank(struct drm_crtc *crtc)
> > +{
> > +   struct drm_device *dev = crtc->dev;
> > +   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > +   unsigned int value;
> > +
> > +   regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
> > +   value |= DCU_INT_MASK_VBLANK;
> > +   regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> > +}
> > +
> >  static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs = {
> > .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> > @@ -144,6 +168,8 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct
> > drm_crtc *crtc)
> > .page_flip = drm_atomic_helper_page_flip,
> > .reset = drm_atomic_helper_crtc_reset,
> > .set_config = drm_atomic_helper_set_config,
> > +   .enable_vblank = fsl_dcu_drm_crtc_enable_vblank,
> > +   .disable_vblank = fsl_dcu_drm_crtc_disable_vblank,
> >  };
> >  
> >  int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device *fsl_dev)
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > index b59b816a1d7d..b5391c124c64 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > @@ -154,29 +154,6 @@ static irqreturn_t fsl_dcu_drm_irq(int irq, void *arg)
> > return IRQ_HANDLED;
> >  }
> >  
> > -static int fsl_dcu_drm_enable_vblank(struct drm_device *dev, unsigned int 
> > pipe)
> > -{
> > -   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > -   unsigned int value;
> > -
> > -   regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
> > -   value &= ~DCU_INT_MASK_VBLANK;
> > -   regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> > -
> > -   return 0;
> > -}
> > -
> > -static void fsl_dcu_drm_disable_vblank(struct drm_device *dev,
> > -  unsigned int pipe)
> > -{
> > -   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > -   unsigned int value;
> > -
> > -   regmap_read(fsl_dev->regmap, DCU_INT_MASK, );
> > -   value |= DCU_INT_MASK_VBLANK;
> > -   regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> > -}
> > -
> >  static void fsl_dcu_drm_lastclose(struct drm_device *dev)
> >  {
> > struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > @@ -203,8 +180,6 @@ static void fsl_dcu_drm_lastclose(struct drm_device 
> > *dev)
> > .load   = fsl_dcu_load,
> > .unload = fsl_dcu_unload,
> > .irq_handler= fsl_dcu_drm_irq,
> > -   .enable_vblank  = fsl_dcu_drm_enable_vblank,
> > -   .disable_vblank = fsl_dcu_drm_disable_vblank,
> > .gem_free_object_unlocked = drm_gem_cma_free_object,
> > .gem_vm_ops = _gem_cma_vm_ops,
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,

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

Re: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Tomi Valkeinen]

On 08/02/17 13:25, Laurent Pinchart wrote:
> Hi Jyri,
> 
> Thank you for the patch.
> 
> On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
>> Let's disable all scaling that requires horizontal decimation with
>> higher factor than 4, until we have better estimates of what we can
>> and can not do. However, 1 byte per pixel color format appear to work
>> Ok with all decimation factors.
>>
>> When decimating horizontally by more that 4 the dss is not able to
>> fetch the data in burst mode. When this happens it is hard to tell if
>> there enough bandwidth. Despite what theory says this appears to be
>> true also for 16-bit color formats.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5554b72..61daef6 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
>> @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long
>> pclk, unsigned long lclk, return -EINVAL;
>>  }
>>
>> +if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) {
>> +/*
>> +  Let's disable all scaling that requires horizontal
>> +  decimation with higher factor than 4, until we have
>> +  better estimates of what we can and can not
>> +  do. However, 1 byte per pixel color format appear to
>> +  work Ok with all decimation factors.
>> +
>> +  When decimating horizontally by more that 4 the dss
>> +  is not able to fetch the data in burst mode. When
>> +  this happens it is hard to tell if there enough
>> +  bandwidth. Despite what theory says this appears to
>> +  be true also for 16-bit color formats.
>> +*/
>> +DSSERR("Not enough bandwidth (x-decimation factor %d > 4)",
>> +*decim_x);
>> +return -EINVAL;
> 
> This needs to be validated during the atomic check phase to avoid failures at 
> commit time that are much harder to handle properly.

I agree, but that requires rewriting half of the dispc driver... This
and the few earlier ones from Jyri are quick fixes to major issues we've
found.

 Tomi



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

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

[Fabio Estevam]

On Wed, Feb 8, 2017 at 7:52 AM, Philipp Zabel  wrote:

> Good point, I suppose what the driver should really do is warn if the
> voltage not set correctly?

Yes, I can do as suggested. Will prepare a patch. Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/23] Add vblank hooks to struct drm_crtc_funcs

[Tomi Valkeinen]

Hi,

On 07/02/17 11:16, Shawn Guo wrote:
> From: Shawn Guo 
> 
> The vblank is mostly CRTC specific and implemented as part of CRTC
> driver.  The first patch adds 3 vblank core<->driver hooks into struct
> drm_crtc_funcs, and plug them into core by adding wrapper functions for
> vblank handling code.  We effectively make the .get_vblank_counter hook
> optional by providing drm_vblank_no_hw_counter() as the default fallback
> in the wrapper function.
> 
> Patch #2 and #3 unexport function drm_vblank_no_hw_counter() by cleaning
> up its use, since it's already the default implememention for
> .get_vblank_counter hook anyway.
> 
> The rest of the series is trying to do a massive conversion to the new
> hooks for DRIVER_MODESET drivers.  But it only handles low-hanging
> fruit, and leaves out the ones that need a bit surgery, like gma500,
> i915, msm etc.  Most of conversion get done by simply moving code and
> making functions static, but imx and rockchip are great examples showing
> how driver code can be cleaned up with these new hooks.
> 
> The series is generated against branch drm-next.

Thanks for the series. I've attached a patch for omapdrm, in case you're
sending v4 and want to include it in the series.

 Tomi
From b03a468fdaf2b329a940f3980871c27bd8d0caa6 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Wed, 8 Feb 2017 13:26:00 +0200
Subject: [PATCH] drm/omap: use vblank hooks in struct drm_crtc_funcs

The vblank hooks in struct drm_driver are deprecated and only meant for
legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
in struct drm_crtc_funcs should be used instead.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c |  2 ++
 drivers/gpu/drm/omapdrm/omap_drv.c  |  2 --
 drivers/gpu/drm/omapdrm/omap_drv.h  |  4 ++--
 drivers/gpu/drm/omapdrm/omap_irq.c  | 18 ++
 4 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c
index b68c70eb395f..2fe735c269fc 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -495,6 +495,8 @@ static const struct drm_crtc_funcs omap_crtc_funcs = {
 	.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 	.atomic_set_property = omap_crtc_atomic_set_property,
 	.atomic_get_property = omap_crtc_atomic_get_property,
+	.enable_vblank = omap_irq_enable_vblank,
+	.disable_vblank = omap_irq_disable_vblank,
 };
 
 static const struct drm_crtc_helper_funcs omap_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c
index a6d05e82db10..92d2f87fed5f 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -727,8 +727,6 @@ static struct drm_driver omap_drm_driver = {
 		DRIVER_ATOMIC,
 	.open = dev_open,
 	.lastclose = dev_lastclose,
-	.enable_vblank = omap_irq_enable_vblank,
-	.disable_vblank = omap_irq_disable_vblank,
 #ifdef CONFIG_DEBUG_FS
 	.debugfs_init = omap_debugfs_init,
 	.debugfs_cleanup = omap_debugfs_cleanup,
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h b/drivers/gpu/drm/omapdrm/omap_drv.h
index b20377efd01b..3c13dc451ab4 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -113,8 +113,8 @@ void omap_gem_describe_objects(struct list_head *list, struct seq_file *m);
 int omap_gem_resume(struct device *dev);
 #endif
 
-int omap_irq_enable_vblank(struct drm_device *dev, unsigned int pipe);
-void omap_irq_disable_vblank(struct drm_device *dev, unsigned int pipe);
+int omap_irq_enable_vblank(struct drm_crtc *crtc);
+void omap_irq_disable_vblank(struct drm_crtc *crtc);
 void omap_drm_irq_uninstall(struct drm_device *dev);
 int omap_drm_irq_install(struct drm_device *dev);
 
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c b/drivers/gpu/drm/omapdrm/omap_irq.c
index 9adfa7c99695..59f21add6f19 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -101,16 +101,17 @@ int omap_irq_wait(struct drm_device *dev, struct omap_irq_wait *wait,
  * Zero on success, appropriate errno if the given @crtc's vblank
  * interrupt cannot be enabled.
  */
-int omap_irq_enable_vblank(struct drm_device *dev, unsigned int pipe)
+int omap_irq_enable_vblank(struct drm_crtc *crtc)
 {
+	struct drm_device *dev = crtc->dev;
 	struct omap_drm_private *priv = dev->dev_private;
-	struct drm_crtc *crtc = priv->crtcs[pipe];
 	unsigned long flags;
+	enum omap_channel channel = omap_crtc_channel(crtc);
 
-	DBG("dev=%p, crtc=%u", dev, pipe);
+	DBG("dev=%p, crtc=%u", dev, channel);
 
 	spin_lock_irqsave(>wait_lock, flags);
-	priv->irq_mask |= dispc_mgr_get_vsync_irq(omap_crtc_channel(crtc));
+	priv->irq_mask |= dispc_mgr_get_vsync_irq(channel);
 	omap_irq_update(dev);
 	spin_unlock_irqrestore(>wait_lock, flags);
 
@@ -126,16 +127,17 @@ int omap_irq_enable_vblank(struct drm_device *dev, unsigned 

Re: [PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, 1 byte per pixel color format appear to work
> Ok with all decimation factors.
> 
> When decimating horizontally by more that 4 the dss is not able to
> fetch the data in burst mode. When this happens it is hard to tell if
> there enough bandwidth. Despite what theory says this appears to be
> true also for 16-bit color formats.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 5554b72..61daef6 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long
> pclk, unsigned long lclk, return -EINVAL;
>   }
> 
> + if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) {
> + /*
> +   Let's disable all scaling that requires horizontal
> +   decimation with higher factor than 4, until we have
> +   better estimates of what we can and can not
> +   do. However, 1 byte per pixel color format appear to
> +   work Ok with all decimation factors.
> +
> +   When decimating horizontally by more that 4 the dss
> +   is not able to fetch the data in burst mode. When
> +   this happens it is hard to tell if there enough
> +   bandwidth. Despite what theory says this appears to
> +   be true also for 16-bit color formats.
> + */
> + DSSERR("Not enough bandwidth (x-decimation factor %d > 4)",
> + *decim_x);
> + return -EINVAL;

This needs to be validated during the atomic check phase to avoid failures at 
commit time that are much harder to handle properly.

> + }
> +
>   *core_clk = dispc.feat->calc_core_clk(pclk, in_width, in_height,
>   out_width, out_height, mem_to_mem);
>   return 0;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

[Philipp Zabel]

On Tue, 2017-02-07 at 14:52 -0200, Fabio Estevam wrote:
> Hi Philipp,
> 
> On Tue, Feb 7, 2017 at 2:45 PM, Philipp Zabel  wrote:
> 
> > I've applied this to the fixes branch, since the current device trees
> > don't have the regulator set.
> 
> I have sent a patch providing the dac-supply regulator for imx53-qsb:
> https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next=042f6d98261d8edc225237acaeb627aeadbf54ad

Thanks, I've commented there.

regards
Philipp

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

Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

[Philipp Zabel]

On Tue, 2017-02-07 at 18:09 +0100, Lucas Stach wrote:
> Am Dienstag, den 07.02.2017, 17:45 +0100 schrieb Philipp Zabel:
> > On Fri, 2017-02-03 at 10:52 -0200, Fabio Estevam wrote:
> > > Hi Philipp,
> > > 
> > > On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam  wrote:
> > > > From: Fabio Estevam 
> > > >
> > > > Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> > > > regulator_set_voltage()") exposes the following probe issue:
> > > >
> > > > 63ff.tve supply dac not found, using dummy regulator
> > > > imx-drm display-subsystem: failed to bind 63ff.tve (ops 
> > > > imx_tve_ops): -22
> > > >
> > > > When the 'dac' regulator is not passed in the device tree,
> > > > devm_regulator_get() will return NULL and when regulator_set_voltage()
> > > > is called it returns an error.
> > > >
> > > > Fix the issue by making the 'dac' regulator optional.
> > > >
> > > > Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by 
> > > > regulator_set_voltage()")
> > > > Cc:  # 4.8+
> > > > Signed-off-by: Fabio Estevam 
> > > 
> > > Any comments, please?
> > 
> > I've applied this to the fixes branch, since the current device trees
> > don't have the regulator set.
> > 
> > Is this really optional, though? It would be better to add the correct
> > dac-supply to the device trees.
> > 
> Why does the driver attempt to set the voltage? I guess the voltage is
> fixed, even if it is hooked up to a configurable regulator.

Good point, I suppose what the driver should really do is warn if the
voltage not set correctly?

> Shouldn't we just remove the set_voltage call from the driver and make
> sure the correct voltage is supplied by board level DT constraints?

I think so, yes.

regards
Philipp

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

Re: [patch] drm/atomic: fix an error code in mode_fixup()

[Daniel Vetter]

On Wed, Feb 08, 2017 at 02:46:01AM +0300, Dan Carpenter wrote:
> Having "ret" be a bool type works for everything except
> ret = funcs->atomic_check().  The other functions all return zero on
> error but ->atomic_check() returns negative error codes.  We want to
> propagate the error code but instead we return 1.
> 
> I found this bug with static analysis and I don't know if it affects
> run time.
> 
> Fixes: 4cd4df8080a3 ("drm/atomic: Add ->atomic_check() to encoder helpers")
> Signed-off-by: Dan Carpenter 

Applied to drm-misc for 4.11, thanks.
-Daniel

> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9a08445a7a7a..01d936b7be43 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -369,7 +369,7 @@ mode_fixup(struct drm_atomic_state *state)
>   struct drm_connector *connector;
>   struct drm_connector_state *conn_state;
>   int i;
> - bool ret;
> + int ret;
>  
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>   if (!crtc_state->mode_changed &&
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [bug report] drm: zte: add overlay plane support

[Shawn Guo]

Hi Dan,

Thanks for the report.

On Wed, Feb 08, 2017 at 09:39:51AM +0300, Dan Carpenter wrote:
> Hello Shawn Guo,
> 
> The patch 4e986d3705df: "drm: zte: add overlay plane support" from
> Nov 16, 2016, leads to the following static checker warning:
> 
>   drivers/gpu/drm/zte/zx_plane.c:170 zx_vl_rsz_setup()
>   warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'

I will send a follow-up patch to fix it by changing 'fmt' to type 'int'.

> 
> drivers/gpu/drm/zte/zx_plane.c
>156  static void zx_vl_rsz_setup(struct zx_plane *zplane, uint32_t format,
>157  u32 src_w, u32 src_h, u32 dst_w, u32 
> dst_h)
>158  {
>159  void __iomem *rsz = zplane->rsz;
>160  u32 src_chroma_w = src_w;
>161  u32 src_chroma_h = src_h;
>162  u32 fmt;
> ^^^
>163  
>164  /* Set up source and destination resolution */
>165  zx_writel(rsz + RSZ_SRC_CFG, RSZ_VER(src_h - 1) | 
> RSZ_HOR(src_w - 1));
>166  zx_writel(rsz + RSZ_DEST_CFG, RSZ_VER(dst_h - 1) | 
> RSZ_HOR(dst_w - 1));
>167  
>168  /* Configure data format for VL RSZ */
>169  fmt = zx_vl_rsz_get_fmt(format);
> ^^^
> If fmt is -EINVAL then don't we just want to return anyway?

The zx_vl_rsz_setup() is being called by atomic update function, which
can not fail anyway.  So we give it a best effort by going through the
hardware update procedure but skip invalid format.

Shawn

> 
>170  if (fmt >= 0)
>171  zx_writel_mask(rsz + RSZ_VL_CTRL_CFG, 
> RSZ_VL_FMT_MASK, fmt);
>172  
>173  /* Calculate Chroma height and width */
>174  if (fmt == RSZ_VL_FMT_YCBCR420) {
>175  src_chroma_w = src_w >> 1;
>176  src_chroma_h = src_h >> 1;
>177  } else if (fmt == RSZ_VL_FMT_YCBCR422) {
>178  src_chroma_w = src_w >> 1;
>179  }
>180  
>181  /* Set up Luma and Chroma step registers */
>182  zx_writel(rsz + RSZ_VL_LUMA_HOR, rsz_step_value(src_w, 
> dst_w));
>183  zx_writel(rsz + RSZ_VL_LUMA_VER, rsz_step_value(src_h, 
> dst_h));
>184  zx_writel(rsz + RSZ_VL_CHROMA_HOR, 
> rsz_step_value(src_chroma_w, dst_w));
>185  zx_writel(rsz + RSZ_VL_CHROMA_VER, 
> rsz_step_value(src_chroma_h, dst_h));
>186  
>187  zx_vl_rsz_set_update(zplane);
>188  }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel