[Bug 100387] War Thunder game has visual errors, missing textures

[bugzilla-daemon]

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

--- Comment #18 from russianneuroman...@ya.ru ---
Issue is still reproducible in Mesa 17.2. With Mesa 17.3 I get GPU lockup at
War Thunder launch: bug 103900

-- 
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 103900] [SUMO][TURKS] Launching War Thunder make GPU stuck, and then system is hard lockup

[bugzilla-daemon]

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

--- Comment #1 from russianneuroman...@ya.ru ---
Created attachment 135708
  --> https://bugs.freedesktop.org/attachment.cgi?id=135708=edit
GPU lockup dmesg

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

[Bug 103900] [SUMO][TURKS] Launching War Thunder make GPU stuck, and then system is hard lockup

[bugzilla-daemon]

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

Bug ID: 103900
   Summary: [SUMO][TURKS] Launching War Thunder make GPU stuck,
and then system is hard lockup
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: russianneuroman...@ya.ru
QA Contact: dri-devel@lists.freedesktop.org

Hello!

Launching War Thunder make GPU stuck, and then system is hard lockup. This
issue is starting to happen after upgrade from Mesa 17.2.2 with libdrm 2.4.83
to 17.3.0rc4 with libdrm 2.4.85 (from Padoka Stable PPA
https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/pkppa ) on Kubuntu
17.10 x86_64. As soon as I rollback to Mesa 17.2.2 and libdrm 2.4.83, GPU
lockup is no longer reproducible, but then there is another issue: bug 100387

Issue is reproducible on both of iGPU and dGPU. Please look into attached log.

Hardware: 
Acer Aspire 7560G, AMD A8-3500M
AMD Radeon HD 6620G iGPU, AMD Radeon HD 6650M dGPU.

Software:
Kubuntu 17.10 x86_64, Linux 4.14.1.
radeon DDX and modesetting DDX was tested, no difference.

-- 
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 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

--- Comment #8 from Rene Barbosa  ---
vkr...@yahoo.com, 

Are you using TLP or something similar?

I ran some tests and found that's only happening when using TLP. Tried with
Ubuntu 17.10 and Fedora 27, same results.

Regards, 
Rene Barbosa

-- 
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 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

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

--- Comment #15 from higu...@gmx.net ---
no, the with the pcie_port_pm=force and 4.14.0, it still fails

-- 
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] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 22:22:06 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/stifb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 6ded5c198998..fe217a2f7d21 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct *sti, 
int bpp_pref)
int bpp, xres, yres;
 
fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
-   if (!fb) {
-   printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
+   if (!fb)
return -ENODEV;
-   }

info = >info;
 
-- 
2.15.0

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

[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi

[bugzilla-daemon]

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

Joonas Sarajärvi  changed:

   What|Removed |Added

 CC||m...@iki.fi

--- Comment #8 from Joonas Sarajärvi  ---
Just as an extra data point, this issue and the workaround from comment #5 seem
to apply also to X-Plane 11. Tested with a Radeon RX 560 on Fedora 27 with the
stock drivers. Currently this would be:

kernel 4.13.12-300
mesa 17.2.4-2

With the MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory ./X-Plane-x86_64
workaround, the simulator works ok.

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

On 24.11.2017 20:14, Ilia Mirkin wrote:


Do you have SWIOTLB disabled in your .config? Try enabling it to see
if that's the issue.

Looking at your bisect log, you might have incorrectly marked some
revisions. E.g. you had a compile failure, which while isn't "good",
it's also not "bad" -- good and bad are only in reference to the
specific issue you're seeing. In such cases you can run "git bisect
skip" which will mark the commit as "unknown" and pick a different one
to try.

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


Hi All,

Success!! I enabled SWIOTLB and the hardware 3D acceleration 
works again! Fantastic. Thank you very much! And thank you for the hint 
with "git bisect skip".


Cheers,
Christian

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

[PATCH 4/4] video: udlfb: Delete an unnecessary return statement in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 21:36:39 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected functions.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/udlfb.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 059883962698..c6bf7088f5f4 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -505,8 +505,6 @@ static void dlfb_compress_hline(
*command_buffer_ptr = cmd;
*pixel_start_ptr = pixel;
*device_address_ptr = dev_addr;
-
-   return;
 }
 
 /*
@@ -1768,8 +1766,6 @@ static void dlfb_usb_disconnect(struct usb_interface 
*interface)
kref_put(>kref, dlfb_free);
 
/* consider dlfb_data freed */
-
-   return;
 }
 
 static struct usb_driver dlfb_driver = {
-- 
2.15.0

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

[PATCH 3/4] video: udlfb: Improve a size determination in dlfb_alloc_urb_list()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 21:30:37 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/udlfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index cb2d59ca67a4..059883962698 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1867,7 +1867,7 @@ static int dlfb_alloc_urb_list(struct dlfb_data *dev, int 
count, size_t size)
INIT_LIST_HEAD(>urbs.list);
 
while (i < count) {
-   unode = kzalloc(sizeof(struct urb_node), GFP_KERNEL);
+   unode = kzalloc(sizeof(*unode), GFP_KERNEL);
if (!unode)
break;
unode->dev = dev;
-- 
2.15.0

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

[PATCH 2/4] video: udlfb: Return an error code only as a constant in dlfb_realloc_framebuffer()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 21:22:25 +0100

* Return an error code without storing it in an intermediate variable.

* Delete the label "error" and local variable "retval"
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/udlfb.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 77633c58bb9b..cb2d59ca67a4 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1159,7 +1159,6 @@ static struct fb_ops dlfb_ops = {
  */
 static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info 
*info)
 {
-   int retval = -ENOMEM;
int old_len = info->fix.smem_len;
int new_len;
unsigned char *old_fb = info->screen_base;
@@ -1176,7 +1175,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
 */
new_fb = vmalloc(new_len);
if (!new_fb)
-   goto error;
+   return -ENOMEM;
 
if (info->screen_base) {
memcpy(new_fb, old_fb, old_len);
@@ -1203,11 +1202,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
dev->backing_buffer = new_back;
}
}
-
-   retval = 0;
-
-error:
-   return retval;
+   return 0;
 }
 
 /*
-- 
2.15.0

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

Re: [PATCH 13/13] drm/tegra: kick out simplefb

[Thierry Reding]

On Fri, Nov 24, 2017 at 06:53:34PM +0100, Michał Mirosław wrote:
> Kick out firmware fb when loading tegra driver.
> 
> Signed-off-by: Michał Mirosław 
> ---
>  drivers/gpu/drm/tegra/drm.c | 4 
>  1 file changed, 4 insertions(+)

Cool. Can you provide some background on how you tested this? What is
your firmware FB? That'd be useful information to put in the commit
message. Also, nit: "tegra driver" -> "Tegra driver".

Thierry


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

[PATCH 1/4] video: udlfb: Delete an error message for a failed memory allocation in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 21:12:54 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/udlfb.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index d44f14242016..77633c58bb9b 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1175,10 +1175,8 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
 * Alloc system memory for virtual framebuffer
 */
new_fb = vmalloc(new_len);
-   if (!new_fb) {
-   pr_err("Virtual framebuffer alloc failed\n");
+   if (!new_fb)
goto error;
-   }
 
if (info->screen_base) {
memcpy(new_fb, old_fb, old_len);
@@ -1599,10 +1597,8 @@ static int dlfb_usb_probe(struct usb_interface 
*interface,
usbdev = interface_to_usbdev(interface);
 
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
-   if (dev == NULL) {
-   dev_err(>dev, "dlfb_usb_probe: failed alloc of dev 
struct\n");
+   if (!dev)
goto error;
-   }
 
kref_init(>kref); /* matching kref_put in usb .disconnect fn */
 
-- 
2.15.0

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

[PATCH 0/4] video-UDLFB: Adjustments for five function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 21:45:54 +0100

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete an error message for a failed memory allocation in two functions
  Return an error code only as a constant in dlfb_realloc_framebuffer()
  Improve a size determination in dlfb_alloc_urb_list()
  Delete an unnecessary return statement in two functions

 drivers/video/fbdev/udlfb.c | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

-- 
2.15.0

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

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #7 from denisgolo...@yandex.ru ---
See attached dmesg with debug. 
Tearing appeared after turning display on.

-- 
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 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #6 from denisgolo...@yandex.ru ---
Created attachment 135701
  --> https://bugs.freedesktop.org/attachment.cgi?id=135701=edit
dmesg + debug

-- 
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] video/fbdev/vt8500lcdfb: Delete an error message for a failed memory allocation in vt8500lcd_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 20:42:08 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/vt8500lcdfb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/vt8500lcdfb.c 
b/drivers/video/fbdev/vt8500lcdfb.c
index 1a1176bf0906..5c5cd2923041 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -289,10 +289,8 @@ static int vt8500lcd_probe(struct platform_device *pdev)
 
fbi = devm_kzalloc(>dev, sizeof(struct vt8500lcd_info)
+ sizeof(u32) * 16, GFP_KERNEL);
-   if (!fbi) {
-   dev_err(>dev, "Failed to initialize framebuffer 
device\n");
+   if (!fbi)
return -ENOMEM;
-   }
 
strcpy(fbi->fb.fix.id, "VT8500 LCD");
 
-- 
2.15.0

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

[PATCH] video/fbdev/wm8505fb: Delete an error message for a failed memory allocation in wm8505fb_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Fri, 24 Nov 2017 20:22:10 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/wm8505fb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
index 253ffe9baab2..8f0d5379861d 100644
--- a/drivers/video/fbdev/wm8505fb.c
+++ b/drivers/video/fbdev/wm8505fb.c
@@ -276,10 +276,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
 
fbi = devm_kzalloc(>dev, sizeof(struct wm8505fb_info) +
sizeof(u32) * 16, GFP_KERNEL);
-   if (!fbi) {
-   dev_err(>dev, "Failed to initialize framebuffer 
device\n");
+   if (!fbi)
return -ENOMEM;
-   }
 
strcpy(fbi->fb.fix.id, DRIVER_NAME);
 
-- 
2.15.0

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

[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #6 from Maximilian Böhm  ---
No, it will be merged with Linux 4.15 but you will still need an kernel
parameter:
https://www.phoronix.com/scan.php?page=news_item=AMDGPU-DC-Accepted
Until then, you have to compile yourself a patched kernel. For Arch-based
distros you can use the AUR linux-amd-staging-drm-next-git. Phoronix provides
pre-compiled packages for Ubuntu.

-- 
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: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Ilia Mirkin]

On Fri, Nov 24, 2017 at 2:08 PM, Christian Zigotzky
 wrote:
> On 24.11.2017 17:09, Michel Dänzer wrote:
>>
>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>>
>>> Hi All,
>>>
>>> I bisected today and the first bad commit is:
>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
>>> to populate/map in one call (v2)) [1]
>>
>> It can't really be that commit, since it just adds functions but doesn't
>> hook them up anywhere. Presumably it's commit
>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>> populate/dma map helper functions") instead, which makes the radeon
>> driver rely on ttm_populate_and_map_pages, which is just a stub
>> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
>> enabled.
>>
>> I can see two possible solutions:
>>
>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>> work without SWIOTLB / INTEL_IOMMU as well.
>>
>> 2. Make the drivers work without ttm_populate_and_map_pages and
>> ttm_unmap_and_unpopulate_pages again in that case.
>>
>>
>> Solution 1 would be preferable.
>>
>>
> Hello Michel,
>
> I tested the latest git version today. Unfortunately the problem with the
> hardware 3D acceleration still exist. How can I make
> ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work without
> SWIOTLB / INTEL_IOMMU?

Do you have SWIOTLB disabled in your .config? Try enabling it to see
if that's the issue.

Looking at your bisect log, you might have incorrectly marked some
revisions. E.g. you had a compile failure, which while isn't "good",
it's also not "bad" -- good and bad are only in reference to the
specific issue you're seeing. In such cases you can run "git bisect
skip" which will mark the commit as "unknown" and pick a different one
to try.

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

On 24.11.2017 20:08, Christian Zigotzky wrote:

On 24.11.2017 17:09, Michel Dänzer wrote:

On 2017-11-24 03:29 PM, Christian Zigotzky wrote:

Hi All,

I bisected today and the first bad commit is:
a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
to populate/map in one call (v2)) [1]

It can't really be that commit, since it just adds functions but doesn't
hook them up anywhere. Presumably it's commit
f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
populate/dma map helper functions") instead, which makes the radeon
driver rely on ttm_populate_and_map_pages, which is just a stub
returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
enabled.

I can see two possible solutions:

1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
    work without SWIOTLB / INTEL_IOMMU as well.

2. Make the drivers work without ttm_populate_and_map_pages and
    ttm_unmap_and_unpopulate_pages again in that case.


Solution 1 would be preferable.



Hello Michel,

I tested the latest git version today. Unfortunately the problem with 
the hardware 3D acceleration still exist. How can I make 
ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work 
without SWIOTLB / INTEL_IOMMU?


Thanks,
Christian


Just for info:

CONFIG_SWIOTLB is not set and CONFIG_PPC_PASEMI_IOMMU is enabled.

-- Christian

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

On 24.11.2017 17:09, Michel Dänzer wrote:

On 2017-11-24 03:29 PM, Christian Zigotzky wrote:

Hi All,

I bisected today and the first bad commit is:
a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
to populate/map in one call (v2)) [1]

It can't really be that commit, since it just adds functions but doesn't
hook them up anywhere. Presumably it's commit
f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
populate/dma map helper functions") instead, which makes the radeon
driver rely on ttm_populate_and_map_pages, which is just a stub
returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
enabled.

I can see two possible solutions:

1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
work without SWIOTLB / INTEL_IOMMU as well.

2. Make the drivers work without ttm_populate_and_map_pages and
ttm_unmap_and_unpopulate_pages again in that case.


Solution 1 would be preferable.



Hello Michel,

I tested the latest git version today. Unfortunately the problem with 
the hardware 3D acceleration still exist. How can I make 
ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages work 
without SWIOTLB / INTEL_IOMMU?


Thanks,
Christian

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

[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #5 from Michael Zapf  ---
I just got kernel 4.14, but I still don't have any audio output via HDMI. Is
that supposed to work by now?

-- 
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: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual

[Lucas Stach]

Am Freitag, den 24.11.2017, 16:49 + schrieb Alexey Brodkin:
[...]
> > Yes, a "core" in Vivante speak is a GPU with one DMA frontend. A
> > single
> > frontend can feed both 3D and 2D acceleration engines behind it. On
> > i.MX6 the 2D and 3D engine are on separate cores, but Marvell Dove
> > has
> > a combined 2D/3D core.
> 
> Hm, that sounds encouraging. The next question would be if Marvel
> Dove is
> supported in Etnaviv DDX? I guess it's called Armada so the answer if
> yes, right?

Yes, the Dove was the original platform for the Armada X.Org driver.
Combined 2D/3D cores are supported just fine by etnaviv.

> > > If we happen to not have 2D core if that's a no go for us for
> > > anything?
> > 
> > I don't know if the DDX works properly without 2D acceleration.
> > Weston
> > on the other hand only relies on the 3D accel core for doing
> > compositing, so even if you don't have a 2D engine you will be able
> > to
> > launch a modern Linux graphics stack.
> 
> That's really cool! I'm much more interested in Weston ATM, which is
> actually another separate question :)
> I tried to find some details on how to run Weston on Wandboard
> but seems like I was looking at wrong Google again... do you
> know any good manuals for doing that?

There really is no magic to it. Or better there is, but it's all hidden
in the Mesa implementation.

You need at least Mesa 17.2 and Weston 3.0 for etnaviv to work
properly. Other than that just set XDG_RUNTIME_DIR to something
sensible and launch Weston with "weston --tty=63", done.

> > 
> > The etnaviv DDX could also emulate 2D accel over the 3D core by
> > using
> > the X.Org glamor module, but no one has bothered to implement this
> > yet.
> 
> Ok we'll see if above case (combined cores) is applicable to us and
> then
> we'll see what to do.
> 
> > > In the meantime I'll try to figure out if we have 2D core or not.
> > 
> > You can find out what your GPU provides by looking at the feature
> > bits.
> > chipFeatures_PIPE_2D, chipFeatures_PIPE_3D and chipFeatures_PIPE_VG
> > is
> > what you are looking out for.
> 
> Does that info helps to decipher these bits?

Unfortunately we forgot to expose the major feature bits register in
debugfs. It's gpu->identity.features in the kernel driver, the
interesting bits in there are chipFeatures_PIPE_3D and
chipFeatures_PIPE_2D.

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

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Reject odd pipe source width with double wide/dual link

[Daniel Vetter]

On Thu, Nov 23, 2017 at 09:04:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay
> we must not adjust pipe_src_w to accommodate double wide/dual link.
> Instead just reject the mode outright.
> 
> This will allows us to rely on crtc_state->mode for plane clipping.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Ville Syrjälä 

Might be real good if we have some igt that injects all these kinds of
funny modes, just to check for bugs and stuff (i.e. not encoding any
expectations that any of them work). Or maybe we need a smart fuzzer for
the atomic ioctl for that.

Musings aside, on patches 1&2:

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d67c7c498b34..959d21157328 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6332,9 +6332,18 @@ static int intel_crtc_compute_config(struct intel_crtc 
> *crtc,
>* - LVDS dual channel mode
>* - Double wide pipe
>*/
> - if ((intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) &&
> -  intel_is_dual_link_lvds(dev)) || pipe_config->double_wide)
> - pipe_config->pipe_src_w &= ~1;
> + if (pipe_config->pipe_src_w & 1) {
> + if (pipe_config->double_wide) {
> + DRM_DEBUG_KMS("Odd pipe source width not supported with 
> double wide pipe\n");
> + return -EINVAL;
> + }
> +
> + if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_LVDS) &&
> + intel_is_dual_link_lvds(dev)) {
> + DRM_DEBUG_KMS("Odd pipe source width not supported with 
> dual link LVDS\n");
> + return -EINVAL;
> + }
> + }
>  
>   /* Cantiga+ cannot handle modes with a hsync front porch of 0.
>* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
> -- 
> 2.13.6
> 
> ___
> 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

Re: Regression in TTM driver w/Linus' master

[Christian König]

Am 24.11.2017 um 17:29 schrieb Tobias Klausmann:


On 11/24/17 4:35 PM, Christian König wrote:

Am 24.11.2017 um 16:17 schrieb Tobias Klausmann:


On 11/24/17 3:54 PM, Daniel Vetter wrote:

On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:

On 11/23/17 2:58 AM, Dave Airlie wrote:
On 23 November 2017 at 11:17, Laura Abbott  
wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute 
bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 
ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle 
iptable_raw

iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec 
irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm 
bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc 
drm soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 
8021q garp

mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul 
crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci 
virtio_ring virtio

ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 
1996), BIOS

1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() 
GS:923a7cc0()

knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc 
dd 44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 
b7 fe ff ff

<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: 
a7818222bba8

[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 




Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc 
huge
dma32 pages which triggers the oops. The bochs driver always 
requests

dma32 here.

I'll send a rough patch once I boot it.

Dave.


Hi Dave,

fyi only: It looks like this is not the only regression in this 
cycle with

ttm, novueau seems to suffer as well [1].

Adding ttm folks. Might be useful if we have an entry for ttm in
MAINTAINERS ...
-Daniel



A bit more of investigation for the nouveau regression: This only 
show when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are 
enable. Thanks Dave for pointing me to that!


Yeah, sorry for that. I 

Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Daniel Vetter]

On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
> 
> Cc: Laurent Pinchart 
> Cc: Daniel Vetter 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 

I guess the longer-term next step would be that we expose can_scale and
can_position (and maybe the scaling limits?) as read-only properties, as
hints to the compositor. And then move all the calls into the overall
helpers (i.e. drm_atomic_helper_check_planes).

But this here is real sweet already I think.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  7 +--
>  drivers/gpu/drm/arm/malidp_planes.c |  7 +--
>  drivers/gpu/drm/armada/armada_overlay.c |  6 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  drivers/gpu/drm/drm_plane_helper.c  | 11 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  6 --
>  drivers/gpu/drm/i915/intel_display.c| 12 
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  7 +--
>  drivers/gpu/drm/meson/meson_plane.c |  7 +--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
>  drivers/gpu/drm/nouveau/nv50_display.c  | 12 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 +--
>  drivers/gpu/drm/tegra/dc.c  |  7 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  7 +--
>  drivers/gpu/drm/zte/zx_plane.c  | 13 +
>  include/drm/drm_atomic_helper.h |  1 -
>  include/drm/drm_plane_helper.h  |  1 -
>  18 files changed, 22 insertions(+), 122 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index fa852fc1c9e6..93c503b754ba 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs 
> hdlcd_crtc_helper_funcs = {
>  static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
> - struct drm_rect clip = { 0 };
>   struct drm_crtc_state *crtc_state;
>   u32 src_h = state->src_h >> 16;
>  
> @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
> *plane,
>   return -EINVAL;
>   }
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - return drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + return drm_atomic_helper_check_plane_state(state, crtc_state,
>  DRM_PLANE_HELPER_NO_SCALING,
>  DRM_PLANE_HELPER_NO_SCALING,
>  false, true);
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 2f6d608d6eaf..e630c0218aaf 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane 
> *mp,
>   struct drm_crtc_state *crtc_state =
>   drm_atomic_get_existing_crtc_state(state->state, state->crtc);
>   struct malidp_crtc_state *mc;
> - struct drm_rect clip = { 0 };
>   u32 src_w, src_h;
>   int ret;
>  
>   if (!crtc_state)
>   return -EINVAL;
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> 0, INT_MAX, true, true);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index b411b608821a..564bd63a5f6a 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>   .x2 = crtc_x + crtc_w,
>   .y2 = crtc_y + crtc_h,
>   };
> - const struct drm_rect clip = {
> - .x2 = crtc->mode.hdisplay,
> - .y2 = crtc->mode.vdisplay,
> - };
>   uint32_t val, ctrl0;
>   unsigned idx = 0;
>   bool visible;
> @@ -124,7 +120,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>crtc_x, crtc_y, 

[Bug 103814] incorrect dust rendering in hl2 without sisched

[bugzilla-daemon]

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

Hleb Valoshka <375...@gmail.com> changed:

   What|Removed |Added

Summary|incorrect dust rendering in |incorrect dust rendering in
   |hl2ep1 without some |hl2 without sisched
   |R600_DEBUG options  |
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

--- Comment #2 from Hleb Valoshka <375...@gmail.com> ---
I've tested other HL2 titles (HL2, EP2, Lost Coast), they all have this issue.
But it can be workarounded by usage of sisched.

-- 
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: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual

[Lucas Stach]

Am Freitag, den 24.11.2017, 16:25 + schrieb Alexey Brodkin:
> Hi Lucas,
> 
> On Fri, 2017-11-24 at 17:11 +0100, Lucas Stach wrote:
> > Hi Alexey,
> > 
> > Am Freitag, den 24.11.2017, 16:02 + schrieb Alexey Brodkin:
> > > 
> > > Hello,
> > > 
> > > Being in the middle of bring-up of the new board with Vivante GPU (HSDK 
> > > namely,
> > > see 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_arch_arc_plat-2Dhsdk=Dw
> > > IDaQ=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL-
> > > bLY=ZJSI1u6GgsRHNIcONVFfIKvn1AWaB38GmtCN1dGB3w0=)
> > > I was looking at simple 3D test apps to see how Etnaviv works on the 
> > > hardware.
> > > 
> > > So far I was able to get kmscube working perfectly fine and the next item 
> > > I took
> > > was glxgears (for some reason I was under impression that's de facto 
> > > "Hello world" app
> > > in the GPU world). But apparently even with Xserver up and running 
> > > glxgears doesn't work.
> > > 
> > > Moreover I tried the same thing on Wandboard Quad but to no avail as well.
> > > That's what I saw:
> > > ->8-
> > > # glxgears
> > > Error: couldn't get an RGB, Double-buffered visual
> > > 
> > > # glxinfo
> > > name of display: :0
> > > Error: couldn't find RGB GLX visual or fbconfig 
> > > ->8-
> > > 
> > > Googling didn't help here unfortunately so maybe some pointers could be
> > > suggested here... like what do I do wrong and if glxgears is supposed to
> > > work on top of DRM GPU at all?
> > > 
> > > Thanks a lot in advance!
> > 
> > For 3D acceleration to work under X you need the etnaviv specific DDX
> > driver, which can be found here:
> > 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunstable-2Ddevel=DwIDaQ=DPL6_
> > X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=ZXa-564Jm43PXsqGXCf2US2DY7C0qIlCw6c56pL-
> > bLY=ZzK2fxA6_XlN6pGnf2Tpo6qKzzQh76ocWZ6IDR-WPtc=
> 
> Thanks for the pointer, still a couple of questions below...
> 
> > Don't let you get confused by the name, the armada driver implements
> > support for both armada drm and imx-drm and the etnaviv DDX. This
> > provides 2D acceleration on the Vivante 2D cores, as well a the DRI2/3
> > bit necessary to get a 3D context on X.
> 
> From Wandboard's .dts I see that 2D core is a separate node with separate
> set of registers mapped at a different location in memory, right?
> 
> Do you know if that's possible if the same one memory-mapped register set
> controls both 3D and 2D engine?

Yes, a "core" in Vivante speak is a GPU with one DMA frontend. A single
frontend can feed both 3D and 2D acceleration engines behind it. On
i.MX6 the 2D and 3D engine are on separate cores, but Marvell Dove has
a combined 2D/3D core.

> If we happen to not have 2D core if that's a no go for us for anything?

I don't know if the DDX works properly without 2D acceleration. Weston
on the other hand only relies on the 3D accel core for doing
compositing, so even if you don't have a 2D engine you will be able to
launch a modern Linux graphics stack.

The etnaviv DDX could also emulate 2D accel over the 3D core by using
the X.Org glamor module, but no one has bothered to implement this yet.

> 
> In the meantime I'll try to figure out if we have 2D core or not.

You can find out what your GPU provides by looking at the feature bits.
chipFeatures_PIPE_2D, chipFeatures_PIPE_3D and chipFeatures_PIPE_VG is
what you are looking out for.

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

Re: [PATCH v2] drm/atomic: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in error paths

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 08:38:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
> about. However error paths everyone cares about, so hiding thea error
> debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS
> for those instead.

Actually, one idea that came to my mind right now is that maybe we want
to keep using _ATOMIC with TEST_ONLY, and only use _KMS w/o TEST_ONLY?

> 
> v2: Rebase and handle a few new cases
> 
> Cc: Jani Nikula 
> Reviewed-by: Jani Nikula  #v1
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic.c| 64 -
>  drivers/gpu/drm/drm_atomic_helper.c | 70 
> ++---
>  2 files changed, 66 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 37445d50816a..594bdd5c33cb 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -572,8 +572,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>*/
>  
>   if (state->active && !state->enable) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
> -  crtc->base.id, crtc->name);
> + DRM_DEBUG_KMS("[CRTC:%d:%s] active without enabled\n",
> +   crtc->base.id, crtc->name);
>   return -EINVAL;
>   }
>  
> @@ -582,15 +582,15 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>* be able to trigger. */
>   if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
>   WARN_ON(state->enable && !state->mode_blob)) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
> -  crtc->base.id, crtc->name);
> + DRM_DEBUG_KMS("[CRTC:%d:%s] enabled without mode blob\n",
> +   crtc->base.id, crtc->name);
>   return -EINVAL;
>   }
>  
>   if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
>   WARN_ON(!state->enable && state->mode_blob)) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
> -  crtc->base.id, crtc->name);
> + DRM_DEBUG_KMS("[CRTC:%d:%s] disabled with mode blob\n",
> +   crtc->base.id, crtc->name);
>   return -EINVAL;
>   }
>  
> @@ -605,8 +605,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
>* pipe.
>*/
>   if (state->event && !state->active && !crtc->state->active) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
> -  crtc->base.id, crtc->name);
> + DRM_DEBUG_KMS("[CRTC:%d:%s] requesting event but off\n",
> +   crtc->base.id, crtc->name);
>   return -EINVAL;
>   }
>  
> @@ -861,10 +861,10 @@ static int drm_atomic_plane_check(struct drm_plane 
> *plane,
>  
>   /* either *both* CRTC and FB must be set, or neither */
>   if (WARN_ON(state->crtc && !state->fb)) {
> - DRM_DEBUG_ATOMIC("CRTC set but no FB\n");
> + DRM_DEBUG_KMS("CRTC set but no FB\n");
>   return -EINVAL;
>   } else if (WARN_ON(state->fb && !state->crtc)) {
> - DRM_DEBUG_ATOMIC("FB set but no CRTC\n");
> + DRM_DEBUG_KMS("FB set but no CRTC\n");
>   return -EINVAL;
>   }
>  
> @@ -874,7 +874,7 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
>  
>   /* Check whether this plane is usable on this CRTC */
>   if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
> - DRM_DEBUG_ATOMIC("Invalid crtc for plane\n");
> + DRM_DEBUG_KMS("Invalid crtc for plane\n");
>   return -EINVAL;
>   }
>  
> @@ -882,9 +882,9 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
>   ret = drm_plane_check_pixel_format(plane, state->fb->format->format);
>   if (ret) {
>   struct drm_format_name_buf format_name;
> - DRM_DEBUG_ATOMIC("Invalid pixel format %s\n",
> -  drm_get_format_name(state->fb->format->format,
> -  _name));
> + DRM_DEBUG_KMS("Invalid pixel format %s\n",
> +   drm_get_format_name(state->fb->format->format,
> +   _name));
>   return ret;
>   }
>  
> @@ -893,9 +893,9 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
>   state->crtc_x > INT_MAX - (int32_t) state->crtc_w ||
>   state->crtc_h > INT_MAX ||
>   state->crtc_y > INT_MAX - (int32_t) state->crtc_h) {
> - DRM_DEBUG_ATOMIC("Invalid CRTC coordinates 

[GIT PULL] mali-dp: fixes for drm-next

[Liviu Dudau]

Hi Dave,

This is the queue of patches I have for mali-dp tree. They have
been in linux-next for a few weeks without issues.

Please pull.

Many thanks,
Liviu


The following changes since commit c209101fc1c91a318422733a3721ff6a9ff7899f:

  Merge tag 'drm-misc-fixes-2017-11-20' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-24 11:33:29 
+1000)

are available in the Git repository at:

  git://linux-arm.org/linux-ld.git for-upstream/mali-dp

for you to fetch changes up to 54243016ae35a0912a680f884835237fd6176820:

  drm: mali-dp: Disable planes when their CRTC gets disabled. (2017-11-24 
15:43:52 +)


Cihangir Akturk (1):
  drm: mali-dp: switch to drm_*_get(), drm_*_put() helpers

Liviu Dudau (2):
  drm: mali-dp: Separate static internal data into a read-only structure.
  drm: mali-dp: Disable planes when their CRTC gets disabled.

Srishti Sharma (1):
  drm/arm: Replace instances of drm_dev_unref with drm_dev_put.

 drivers/gpu/drm/arm/malidp_crtc.c   | 16 +
 drivers/gpu/drm/arm/malidp_drv.c| 34 +--
 drivers/gpu/drm/arm/malidp_hw.c | 46 ++
 drivers/gpu/drm/arm/malidp_hw.h | 65 ++---
 drivers/gpu/drm/arm/malidp_planes.c | 21 ++--
 5 files changed, 99 insertions(+), 83 deletions(-)


-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: glxgears on Etnaviv: couldn't get an RGB, Double-buffered visual

[Lucas Stach]

Hi Alexey,

Am Freitag, den 24.11.2017, 16:02 + schrieb Alexey Brodkin:
> Hello,
> 
> Being in the middle of bring-up of the new board with Vivante GPU (HSDK 
> namely,
> see 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/plat-hsdk)
> I was looking at simple 3D test apps to see how Etnaviv works on the hardware.
> 
> So far I was able to get kmscube working perfectly fine and the next item I 
> took
> was glxgears (for some reason I was under impression that's de facto "Hello 
> world" app
> in the GPU world). But apparently even with Xserver up and running glxgears 
> doesn't work.
> 
> Moreover I tried the same thing on Wandboard Quad but to no avail as well.
> That's what I saw:
> ->8-
> # glxgears
> Error: couldn't get an RGB, Double-buffered visual
> 
> # glxinfo
> name of display: :0
> Error: couldn't find RGB GLX visual or fbconfig 
> ->8-
> 
> Googling didn't help here unfortunately so maybe some pointers could be
> suggested here... like what do I do wrong and if glxgears is supposed to
> work on top of DRM GPU at all?
> 
> Thanks a lot in advance!

For 3D acceleration to work under X you need the etnaviv specific DDX
driver, which can be found here:

http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unstable-devel

Don't let you get confused by the name, the armada driver implements
support for both armada drm and imx-drm and the etnaviv DDX. This
provides 2D acceleration on the Vivante 2D cores, as well a the DRI2/3
bit necessary to get a 3D context on X.

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Michel Dänzer]

On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
> Hi All,
> 
> I bisected today and the first bad commit is:
> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
> to populate/map in one call (v2)) [1]

It can't really be that commit, since it just adds functions but doesn't
hook them up anywhere. Presumably it's commit
f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
populate/dma map helper functions") instead, which makes the radeon
driver rely on ttm_populate_and_map_pages, which is just a stub
returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
enabled.

I can see two possible solutions:

1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
   work without SWIOTLB / INTEL_IOMMU as well.

2. Make the drivers work without ttm_populate_and_map_pages and
   ttm_unmap_and_unpopulate_pages again in that case.


Solution 1 would be preferable.


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

[GIT PULL] hdlcd: fixes for drm-next

[Liviu Dudau]

Hi Dave,

Cleaning up the backlog of patches that I have in my tree, they have
all been baking in linux-next for weeks. Minor fixes that could be
sent as late -rc but I'm not in any rush, so queueing them for v4.16 is
fine.

Many thanks,
Liviu


The following changes since commit c209101fc1c91a318422733a3721ff6a9ff7899f:

  Merge tag 'drm-misc-fixes-2017-11-20' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-24 11:33:29 
+1000)

are available in the Git repository at:

  git://linux-arm.org/linux-ld.git for-upstream/hdlcd

for you to fetch changes up to 7e2410d3b50f749fb0fa3844ae71da52717c48ee:

  drm/arm: Replace instances of drm_dev_unref with drm_dev_put. (2017-11-24 
14:15:29 +)


Liviu Dudau (1):
  drm: hdlcd: Update PM code to save/restore console.

Srishti Sharma (1):
  drm/arm: Replace instances of drm_dev_unref with drm_dev_put.

Vitor Massaru Iha (1):
  drm: Fix checkpatch issue: "WARNING: braces {} are not necessary for 
single statement blocks."

 drivers/gpu/drm/arm/hdlcd_crtc.c | 3 +--
 drivers/gpu/drm/arm/hdlcd_drv.c  | 9 ++---
 2 files changed, 7 insertions(+), 5 deletions(-)


-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer

[Sean Paul]

On Thu, Nov 23, 2017, 7:12 AM Jani Nikula  wrote:

> I'm juggling too many things, and drm-misc maintenance is one that I
> keep dropping on the floor. Admit reality and remove myself as
> maintainer. This still leaves us with a nice team of three who are
> actually doing the drm-misc work, while I focus on drm-intel.
>
> Cc: Daniel Vetter 
> Cc: Gustavo Padovan 
> Cc: Sean Paul 
> Cc: Dave Airlie 
> Signed-off-by: Jani Nikula 
>

:(

Relunctantly-Acked-By: Sean Paul 

---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9a9d3fdc55ef..fb8820458a7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4490,7 +4490,6 @@ F:include/linux/vga*
>
>  DRM DRIVERS AND MISC GPU PATCHES
>  M: Daniel Vetter 
> -M: Jani Nikula 
>  M: Gustavo Padovan 
>  M: Sean Paul 
>  W:
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
> --
> 2.11.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly

[Daniel Vetter]

On Fri, Nov 24, 2017 at 04:35:10PM +0100, Maarten Lankhorst wrote:
> Op 24-11-17 om 16:03 schreef Daniel Vetter:
> > On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote:
> >> This was implemented correctly only on the atomic ioctl before, but
> >> it should really be working on all 3 ioctl's involved, so ensure we
> >> always set crtc_id correctly with a testcase.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> > We seemt to completely lack these checks for the vblank ioctl and the
> > atomic ioctl too. Can you pls fill these gaps (probably best in kms_flip.c
> > and kms_atomic.c), too?
> Summary is a bit out of date, but I did add them in here. :)

Oh was blind.

> >> ---
> >>  tests/kms_vblank.c | 60 
> >> ++
> >>  1 file changed, 56 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
> >> index 47fd10fb9078..004f0e6104ee 100644
> >> --- a/tests/kms_vblank.c
> >> +++ b/tests/kms_vblank.c
> >> @@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void 
> >> (*testfunc)(data_t *, int, int))
> >>igt_display_t *display = >display;
> >>igt_output_t *output;
> >>enum pipe p;
> >> -  unsigned int valid_tests = 0;
> >>  
> >>for_each_pipe_with_valid_output(display, p, output) {
> >>igt_hang_t hang;
> >> @@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void 
> >> (*testfunc)(data_t *, int, int))
> >>  
> >>/* cleanup what prepare_crtc() has done */
> >>cleanup_crtc(data, fd, output);
> >> -  valid_tests++;
> >>}
> >> +}
> >> +
> >> +static void crtc_id_subtest(data_t *data, int fd)
> >> +{
> >> +  igt_display_t *display = >display;
> >> +  igt_output_t *output;
> >> +  enum pipe p;
> >> +
> >> +  for_each_pipe_with_valid_output(display, p, output) {
> >> +  struct drm_event_vblank buf;
> >> +  const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p);
> >> +  unsigned crtc_id, expected_crtc_id;
> >> +  uint64_t val;
> >> +  union drm_wait_vblank vbl;
> >> +
> >> +  crtc_id = display->pipes[p].crtc_id;
> >> +  if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, 
> >> ) == 0)
> >> +  expected_crtc_id = crtc_id;
> >> +  else
> >> +  expected_crtc_id = 0;
> >> +
> >> +  data->pipe = p;
> >> +  prepare_crtc(data, fd, output);
> >> +
> >> +  memset(, 0, sizeof(vbl));
> >> +  vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
> >> +  vbl.request.type |= pipe_id_flag;
> >> +  vbl.request.sequence = 1;
> >> +  igt_assert_eq(wait_vblank(fd, ), 0);
> >> +
> >> +  igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
> >> +  igt_assert_eq(buf.crtc_id, expected_crtc_id);
> >> +
> >> +  do_or_die(drmModePageFlip(fd, crtc_id,
> >> +data->primary_fb.fb_id,
> >> +DRM_MODE_PAGE_FLIP_EVENT, NULL));
> >> +
> >> +  igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
> >> +  igt_assert_eq(buf.crtc_id, expected_crtc_id);
> >> +
> >> +  if (display->is_atomic) {
> >> +  igt_plane_t *primary = igt_output_get_plane(output, 0);
> >> +
> >> +  igt_plane_set_fb(primary, >primary_fb);
> >> +  igt_display_commit_atomic(display, 
> >> DRM_MODE_PAGE_FLIP_EVENT, NULL);
> >>  
> >> -  igt_require_f(valid_tests,
> >> -"no valid crtc/connector combinations found\n");
> >> +  igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
> >> +  igt_assert_eq(buf.crtc_id, expected_crtc_id);
> >> +  }
> >> +
> >> +  cleanup_crtc(data, fd, output);
> >> +  return;
> >> +  }
> >>  }
> >>  
> >>  static void accuracy(data_t *data, int fd, int nchildren)
> >> @@ -307,8 +355,12 @@ igt_main
> >>fd = drm_open_driver(DRIVER_ANY);
> >>kmstest_set_vt_graphics_mode();
> >>igt_display_init(, fd);
> >> +  igt_display_require_output();
> >>}
> >>  
> >> +  igt_subtest("crtc-id")
> >> +  crtc_id_subtest(, fd);
> > Either I'm stupid, or this doesn't apply on top of latest igt master.
> >
> > Either way I think taking the expensive modesets out of individual tests
> > would be good, so that when we run entire binaries in CI, we'll benefit
> > from some good speedup. Which is the plan, now that machines are a bit
> > more stable ...
> This is my intention of speeding up IGT as well, tests that don't care can use
> the inherited pipe/connector. It will speed up testing a lot by preventing 
> even
> performing a modeset.
> 
> I also plan to add a function to read the current state through 
> igt_display_read_hw_state(),
> then find an active pipe/connector, or just the first combination if nothing 
> 

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #5 from denisgolo...@yandex.ru ---
(In reply to Michel Dänzer from comment #4)
> We need to find out why the kernel starts returning -EINVAL from the page
> flip and wait for vblank ioctls.
> 
> Can you try writing 255 to /sys/module/drm/parameters/debug before
> reproducing the problem, and attach the resulting dmesg output? (Note that
> writing non-0 to /sys/module/drm/parameters/debug will cause a lot of
> debugging output to be generated, so you'll want to write 0 to it again soon
> afterwards)

Got it. I'll attach dmesg as soon as I reproduce the issue.

> In case that doesn't reveal why -EINVAL is being returned, are you able to
> recompile the drm.ko / amdgpu.ko kernel modules with a patch applied?

Sure. Gentoo is there :)

-- 
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 i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly

[Maarten Lankhorst]

Op 24-11-17 om 16:03 schreef Daniel Vetter:
> On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote:
>> This was implemented correctly only on the atomic ioctl before, but
>> it should really be working on all 3 ioctl's involved, so ensure we
>> always set crtc_id correctly with a testcase.
>>
>> Signed-off-by: Maarten Lankhorst 
> We seemt to completely lack these checks for the vblank ioctl and the
> atomic ioctl too. Can you pls fill these gaps (probably best in kms_flip.c
> and kms_atomic.c), too?
Summary is a bit out of date, but I did add them in here. :)
>> ---
>>  tests/kms_vblank.c | 60 
>> ++
>>  1 file changed, 56 insertions(+), 4 deletions(-)
>>
>> diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
>> index 47fd10fb9078..004f0e6104ee 100644
>> --- a/tests/kms_vblank.c
>> +++ b/tests/kms_vblank.c
>> @@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void 
>> (*testfunc)(data_t *, int, int))
>>  igt_display_t *display = >display;
>>  igt_output_t *output;
>>  enum pipe p;
>> -unsigned int valid_tests = 0;
>>  
>>  for_each_pipe_with_valid_output(display, p, output) {
>>  igt_hang_t hang;
>> @@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void 
>> (*testfunc)(data_t *, int, int))
>>  
>>  /* cleanup what prepare_crtc() has done */
>>  cleanup_crtc(data, fd, output);
>> -valid_tests++;
>>  }
>> +}
>> +
>> +static void crtc_id_subtest(data_t *data, int fd)
>> +{
>> +igt_display_t *display = >display;
>> +igt_output_t *output;
>> +enum pipe p;
>> +
>> +for_each_pipe_with_valid_output(display, p, output) {
>> +struct drm_event_vblank buf;
>> +const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p);
>> +unsigned crtc_id, expected_crtc_id;
>> +uint64_t val;
>> +union drm_wait_vblank vbl;
>> +
>> +crtc_id = display->pipes[p].crtc_id;
>> +if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, 
>> ) == 0)
>> +expected_crtc_id = crtc_id;
>> +else
>> +expected_crtc_id = 0;
>> +
>> +data->pipe = p;
>> +prepare_crtc(data, fd, output);
>> +
>> +memset(, 0, sizeof(vbl));
>> +vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
>> +vbl.request.type |= pipe_id_flag;
>> +vbl.request.sequence = 1;
>> +igt_assert_eq(wait_vblank(fd, ), 0);
>> +
>> +igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
>> +igt_assert_eq(buf.crtc_id, expected_crtc_id);
>> +
>> +do_or_die(drmModePageFlip(fd, crtc_id,
>> +  data->primary_fb.fb_id,
>> +  DRM_MODE_PAGE_FLIP_EVENT, NULL));
>> +
>> +igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
>> +igt_assert_eq(buf.crtc_id, expected_crtc_id);
>> +
>> +if (display->is_atomic) {
>> +igt_plane_t *primary = igt_output_get_plane(output, 0);
>> +
>> +igt_plane_set_fb(primary, >primary_fb);
>> +igt_display_commit_atomic(display, 
>> DRM_MODE_PAGE_FLIP_EVENT, NULL);
>>  
>> -igt_require_f(valid_tests,
>> -  "no valid crtc/connector combinations found\n");
>> +igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
>> +igt_assert_eq(buf.crtc_id, expected_crtc_id);
>> +}
>> +
>> +cleanup_crtc(data, fd, output);
>> +return;
>> +}
>>  }
>>  
>>  static void accuracy(data_t *data, int fd, int nchildren)
>> @@ -307,8 +355,12 @@ igt_main
>>  fd = drm_open_driver(DRIVER_ANY);
>>  kmstest_set_vt_graphics_mode();
>>  igt_display_init(, fd);
>> +igt_display_require_output();
>>  }
>>  
>> +igt_subtest("crtc-id")
>> +crtc_id_subtest(, fd);
> Either I'm stupid, or this doesn't apply on top of latest igt master.
>
> Either way I think taking the expensive modesets out of individual tests
> would be good, so that when we run entire binaries in CI, we'll benefit
> from some good speedup. Which is the plan, now that machines are a bit
> more stable ...
This is my intention of speeding up IGT as well, tests that don't care can use
the inherited pipe/connector. It will speed up testing a lot by preventing even
performing a modeset.

I also plan to add a function to read the current state through 
igt_display_read_hw_state(),
then find an active pipe/connector, or just the first combination if nothing 
matches.
And after the end of the test keep it alive without disabling the crtc's, only 
removing framebuffers,
which no longer disables the crtc's on i915. :-)

~Maarten

Re: Regression in TTM driver w/Linus' master

[Christian König]

Am 24.11.2017 um 16:17 schrieb Tobias Klausmann:


On 11/24/17 3:54 PM, Daniel Vetter wrote:

On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:

On 11/23/17 2:58 AM, Dave Airlie wrote:

On 23 November 2017 at 11:17, Laura Abbott  wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute 
bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 
ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4

nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec 
irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm 
bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm 
soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 
8021q garp

mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul 
crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring 
virtio

ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 
1996), BIOS

1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 
44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 
fe ff ff

<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: 
a7818222bba8

[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 




Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc huge
dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.


Hi Dave,

fyi only: It looks like this is not the only regression in this 
cycle with

ttm, novueau seems to suffer as well [1].

Adding ttm folks. Might be useful if we have an entry for ttm in
MAINTAINERS ...
-Daniel



A bit more of investigation for the nouveau regression: This only show 
when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are enable. 
Thanks Dave for pointing me to that!


Yeah, sorry for that. I missed to handle the DMA32 case with transparent 
huge page support.


Dave already came up with a fix 

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #4 from Michel Dänzer  ---
We need to find out why the kernel starts returning -EINVAL from the page flip
and wait for vblank ioctls.

Can you try writing 255 to /sys/module/drm/parameters/debug before reproducing
the problem, and attach the resulting dmesg output? (Note that writing non-0 to
/sys/module/drm/parameters/debug will cause a lot of debugging output to be
generated, so you'll want to write 0 to it again soon afterwards)

In case that doesn't reveal why -EINVAL is being returned, are you able to
recompile the drm.ko / amdgpu.ko kernel modules with a patch applied?

-- 
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 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Liviu Dudau]

On Fri, Nov 24, 2017 at 04:08:28PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 24, 2017 at 11:59:45AM +, Liviu Dudau wrote:
> > On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > 
> > Hi Ville,
> > 
> > > 
> > > Move the plane clip rectangle handling into
> > > drm_atomic_helper_check_plane_state(). Drivers no longer
> > > have to worry about such mundane details.
> > 
> > This is quite an important patch and I dare say the essence of your
> > series, right? Yet very few people got Cc-ed on it (1 AFAICT) and it
> > touches quite a few drivers.
> 
> It has no functional changes, so forgetting to plaster it with Ccs
> doesn't seem all that dangerous. All the (potentially) functional
> changes were in the prep patches which had Ccs, as did the cover
> letter. And maintainers should read the ml anyway ;)

Maintainers don't maintain the functionality, they maintain the source
code. They fix conflicts and order patches. On that line, not Cc-ing
maintainers when you change the code of the drivers they maintain makes
their lives all more ... "entertaining".

And I would argue that the patch does introduce functional changes, as
it removes the clip rectangle from drm_atomic_helper_check_plane_state()'s
list of parameters. It does change all the users of it, too, I agree, but
not for people that have drivers not yet upstreamed (and they start to wonder
how one driver compiles and other fails when they were supposed to have the
same code inside :) )

Regards,
Liviu

> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes

[Ilia Mirkin]

On Fri, Nov 24, 2017 at 8:38 AM, Ville Syrjälä
 wrote:
> On Thu, Nov 23, 2017 at 03:14:46PM -0500, Ilia Mirkin wrote:
>> On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä
>>  wrote:
>> > On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
>> >> We need to shift the values up, otherwise we'd end up with a negative
>> >> shift. This works for up-to 16-bit components, which is fine for now.
>> >
>> > Shouldn't we actually replicate the high bits in the low bits?
>>
>> Not entirely sure what you're proposing...
>>
>> Ideally we wouldn't be lazy and pass e.g. 16-bit values to MAKE_RGBA
>> which would then shift down as necessary (and even there, you could
>> end up with off-by-1's maybe?). For e.g. 0xff, that should become
>> 0x3ff but with my code will become 0x3fc.
>
> Exactly the issue.
>
>> But for other values, it's
>> less clear what to do with the low bits. I figured it didn't really
>> matter.
>>
>> Do you have a concrete proposal?
>
> The usual thing would be just
>
> (value) * 0x3ff / 0xff
>
> or
>
> ((value) << 2) | ((value) >> 6)

The latter method is interesting, it slowly biases from rounding down
to rounding up as you go through the range. Clever. I guess I could
change my function to use

(value << 8) | value

and then use that to shift around. I'll send a v2.

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

Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Christian Zigotzky]

Hi All,

I bisected today and the first bad commit is: 
a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions 
to populate/map in one call (v2)) [1]


Please find attached the git bisect log.

Thanks,
Christian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4dec819c8bba6365eb893a4ca88db4dd1210110



On 22.11.2017 14:45, Ilia Mirkin wrote:


I thought I covered that...

"I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible."

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



git bisect start

git bisect good 894025f24bd028942da3e602b87d9f7223109b14 (Linux 4.15 alpha1 Mon 
Nov 13 21:14:07 2017 -0800)

git bisect bad e60e1ee60630cafef5e430c2ae364877e061d980

Output:

Bisecting: 2555 revisions left to test after this (roughly 12 steps)
[5bbcc0f595fadb4cac0eddc4401035ec0bd95b09] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next

git bisect good

Output:

Bisecting: 1277 revisions left to test after this (roughly 10 steps)
[9a45ddaaa674aa103cd74a0df9a3f9c2c8fb3124] drm/nouveau/mmu: implement page 
table cache

git bisect bad

Output:

Bisecting: 638 revisions left to test after this (roughly 9 steps)
[d6c0511300dcff19969844495ba293c4efb50b42] drm/i915/execlists: Distinguish the 
incomplete context notifies

git bisect bad

Output:

Bisecting: 373 revisions left to test after this (roughly 8 steps)
[ae7617f0ef1820be033eef93859a6bb6174a843f] drm/i915: Allow optimized platform 
checks

git bisect good

Output:

Bisecting: 186 revisions left to test after this (roughly 8 steps)
[6e2e216fadd80b4280783bb78e543593ebf2cb69] drm/amdgpu:use formal register to 
trigger hdp invalidate

git bisect bad

Output:

Bisecting: 93 revisions left to test after this (roughly 7 steps)
[b72cf4fca2bb786e20864b5e8755105aa9626fb4] drm/amdgpu: move taking mmap_sem 
into get_user_pages v2

git bisect bad

Output:

Bisecting: 46 revisions left to test after this (roughly 6 steps)
[c5927537dd5706b17affa8aeea28c7b19c8fbb42] drm/amd: Remove null check before 
kfree

git bisect bad

Output:

Bisecting: 22 revisions left to test after this (roughly 5 steps)
[e719d5169f75ead3c05329b4125afb67b4f33eba] drm/amd/include: Add 
hdmi_redriver_set to atomfirmware

git bisect good

Output:

Bisecting: 11 revisions left to test after this (roughly 4 steps)
[925d5d798f465671c6b8011e80c636da46ef1a16] drm/amdgpu/gfx8: apply dynamic cu 
mask to APUs as well

git bisect bad

Output:

Bisecting: 5 revisions left to test after this (roughly 3 steps)
[db95e2185523ee9d46a13ceee37bffe8442d2e1c] drm/amdgpu: Add debugfs file for 
VBIOS and version

git bisect bad

Output:

Bisecting: 2 revisions left to test after this (roughly 1 step)
[7405e0dad4c75b33976ddd997513635d7a0204b1] drm/amd/amdgpu: Use new TTM 
populate/map helper function

CC  drivers/gpu/drm/ttm/ttm_page_alloc.o
drivers/gpu/drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of 
‘ttm_populate_and_map_pages’
 int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
 ^~
In file included from drivers/gpu/drm/ttm/ttm_page_alloc.c:49:0:
./include/drm/ttm/ttm_page_alloc.h:120:19: note: previous definition of 
‘ttm_populate_and_map_pages’ was here
 static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
   ^~
drivers/gpu/drm/ttm/ttm_page_alloc.c:950:6: error: redefinition of 
‘ttm_unmap_and_unpopulate_pages’
 void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
  ^~
In file included from drivers/gpu/drm/ttm/ttm_page_alloc.c:49:0:
./include/drm/ttm/ttm_page_alloc.h:125:20: note: previous definition of 
‘ttm_unmap_and_unpopulate_pages’ was here
 static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct 
ttm_dma_tt *tt)

git bisect bad

Output:

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a4dec819c8bba6365eb893a4ca88db4dd1210110] drm/ttm: Add helper functions to 
populate/map in one call (v2)

git bisect bad

Output:

a4dec819c8bba6365eb893a4ca88db4dd1210110 is the first bad commit
commit a4dec819c8bba6365eb893a4ca88db4dd1210110
Author: Tom St Denis 
Date:   Fri Aug 18 10:04:57 2017 -0400

drm/ttm: Add helper functions to populate/map in one call (v2)

These functions replace a section of common code found
in radeon/amdgpu drivers (and possibly others) as part
of the ttm_tt_*populate() callbacks.

v2: squash in fix for sw iommu from Tom

Signed-off-by: Tom St Denis 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 

:04 04 

Re: [Intel-gfx] [PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer

[Daniel Vetter]

On Thu, Nov 23, 2017 at 02:13:08PM +0200, Jani Nikula wrote:
> I'm juggling too many things, and drm-misc maintenance is one that I
> keep dropping on the floor. Admit reality and remove myself as
> maintainer. This still leaves us with a nice team of three who are
> actually doing the drm-misc work, while I focus on drm-intel.

Thanks a lot for the work done!

> Cc: Daniel Vetter 
> Cc: Gustavo Padovan 
> Cc: Sean Paul 
> Cc: Dave Airlie 
> Signed-off-by: Jani Nikula 

Acked-by: Daniel Vetter 

Sean is getting stuffed with turkey and Gustova is on vacation, so will
probably take until next week for those acks to roll in.

Thanks, Daniel

> ---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9a9d3fdc55ef..fb8820458a7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4490,7 +4490,6 @@ F:  include/linux/vga*
>  
>  DRM DRIVERS AND MISC GPU PATCHES
>  M:   Daniel Vetter 
> -M:   Jani Nikula 
>  M:   Gustavo Padovan 
>  M:   Sean Paul 
>  W:   https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
> -- 
> 2.11.0
> 
> ___
> 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

Re: [PATCH i-g-t] tests/kms_vblank: Add test to ensure DRM_CAP_CRTC_IN_VBLANK_EVENT works correctly

[Daniel Vetter]

On Thu, Nov 23, 2017 at 01:26:14PM +0100, Maarten Lankhorst wrote:
> This was implemented correctly only on the atomic ioctl before, but
> it should really be working on all 3 ioctl's involved, so ensure we
> always set crtc_id correctly with a testcase.
> 
> Signed-off-by: Maarten Lankhorst 

We seemt to completely lack these checks for the vblank ioctl and the
atomic ioctl too. Can you pls fill these gaps (probably best in kms_flip.c
and kms_atomic.c), too?

> ---
>  tests/kms_vblank.c | 60 
> ++
>  1 file changed, 56 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
> index 47fd10fb9078..004f0e6104ee 100644
> --- a/tests/kms_vblank.c
> +++ b/tests/kms_vblank.c
> @@ -121,7 +121,6 @@ static void run_test(data_t *data, int fd, void 
> (*testfunc)(data_t *, int, int))
>   igt_display_t *display = >display;
>   igt_output_t *output;
>   enum pipe p;
> - unsigned int valid_tests = 0;
>  
>   for_each_pipe_with_valid_output(display, p, output) {
>   igt_hang_t hang;
> @@ -170,11 +169,60 @@ static void run_test(data_t *data, int fd, void 
> (*testfunc)(data_t *, int, int))
>  
>   /* cleanup what prepare_crtc() has done */
>   cleanup_crtc(data, fd, output);
> - valid_tests++;
>   }
> +}
> +
> +static void crtc_id_subtest(data_t *data, int fd)
> +{
> + igt_display_t *display = >display;
> + igt_output_t *output;
> + enum pipe p;
> +
> + for_each_pipe_with_valid_output(display, p, output) {
> + struct drm_event_vblank buf;
> + const uint32_t pipe_id_flag = kmstest_get_vbl_flag(p);
> + unsigned crtc_id, expected_crtc_id;
> + uint64_t val;
> + union drm_wait_vblank vbl;
> +
> + crtc_id = display->pipes[p].crtc_id;
> + if (drmGetCap(display->drm_fd, DRM_CAP_CRTC_IN_VBLANK_EVENT, 
> ) == 0)
> + expected_crtc_id = crtc_id;
> + else
> + expected_crtc_id = 0;
> +
> + data->pipe = p;
> + prepare_crtc(data, fd, output);
> +
> + memset(, 0, sizeof(vbl));
> + vbl.request.type = DRM_VBLANK_RELATIVE | DRM_VBLANK_EVENT;
> + vbl.request.type |= pipe_id_flag;
> + vbl.request.sequence = 1;
> + igt_assert_eq(wait_vblank(fd, ), 0);
> +
> + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
> + igt_assert_eq(buf.crtc_id, expected_crtc_id);
> +
> + do_or_die(drmModePageFlip(fd, crtc_id,
> +   data->primary_fb.fb_id,
> +   DRM_MODE_PAGE_FLIP_EVENT, NULL));
> +
> + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
> + igt_assert_eq(buf.crtc_id, expected_crtc_id);
> +
> + if (display->is_atomic) {
> + igt_plane_t *primary = igt_output_get_plane(output, 0);
> +
> + igt_plane_set_fb(primary, >primary_fb);
> + igt_display_commit_atomic(display, 
> DRM_MODE_PAGE_FLIP_EVENT, NULL);
>  
> - igt_require_f(valid_tests,
> -   "no valid crtc/connector combinations found\n");
> + igt_assert_eq(read(fd, , sizeof(buf)), sizeof(buf));
> + igt_assert_eq(buf.crtc_id, expected_crtc_id);
> + }
> +
> + cleanup_crtc(data, fd, output);
> + return;
> + }
>  }
>  
>  static void accuracy(data_t *data, int fd, int nchildren)
> @@ -307,8 +355,12 @@ igt_main
>   fd = drm_open_driver(DRIVER_ANY);
>   kmstest_set_vt_graphics_mode();
>   igt_display_init(, fd);
> + igt_display_require_output();
>   }
>  
> + igt_subtest("crtc-id")
> + crtc_id_subtest(, fd);

Either I'm stupid, or this doesn't apply on top of latest igt master.

Either way I think taking the expensive modesets out of individual tests
would be good, so that when we run entire binaries in CI, we'll benefit
from some good speedup. Which is the plan, now that machines are a bit
more stable ...
-Daniel
> +
>   for (f = funcs; f->name; f++) {
>   for (m = modes; m->name; m++) {
>   if (m->flags & ~f->valid)
> -- 
> 2.15.0
> 
> ___
> 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: Regression in TTM driver w/Linus' master

[Daniel Vetter]

On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:
> 
> On 11/23/17 2:58 AM, Dave Airlie wrote:
> > On 23 November 2017 at 11:17, Laura Abbott  wrote:
> > > Hi,
> > > 
> > > Fedora QA testing reported a panic when booting up VMs
> > > using qmeu vga drivers
> > > (https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)
> > > 
> > > [   30.108507] [ cut here ]
> > > [   30.108920] kernel BUG at ./include/linux/gfp.h:408!
> > > [   30.109356] invalid opcode:  [#1] SMP
> > > [   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
> > > nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> > > xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge
> > > ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
> > > ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 
> > > nf_defrag_ipv4
> > > nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
> > > iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
> > > snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass
> > > ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm
> > > joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm 
> > > soundcore
> > > parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q 
> > > garp
> > > mrp stp llc virtio_net
> > > [   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul
> > > crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio
> > > ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
> > > [   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
> > > 4.15.0-0.rc0.git6.1.fc28.x86_64 #1
> > > [   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > > 1.10.2-2.fc27 04/01/2014
> > > [   30.118866] task: 923a77e03380 task.stack: a78182228000
> > > [   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
> > > [   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
> > > [   30.120250] RAX: 0001 RBX: 014382c6 RCX:
> > > 0006
> > > [   30.120840] RDX:  RSI: 0009 RDI:
> > > 
> > > [   30.121443] RBP: 923a760d6000 R08:  R09:
> > > 0006
> > > [   30.122039] R10: 0040 R11: 0300 R12:
> > > 923a729273c0
> > > [   30.122629] R13:  R14:  R15:
> > > 923a7483d400
> > > [   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
> > > knlGS:
> > > [   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
> > > [   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
> > > 06f0
> > > [   30.124968] Call Trace:
> > > [   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
> > > [   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
> > > [   30.125964]  __do_fault+0x19/0x11e
> > > [   30.126255]  __handle_mm_fault+0xcd3/0x1260
> > > [   30.126609]  handle_mm_fault+0x14c/0x310
> > > [   30.126947]  __do_page_fault+0x28c/0x530
> > > [   30.127282]  do_page_fault+0x32/0x270
> > > [   30.127593]  async_page_fault+0x22/0x30
> > > [   30.127922] RIP: 0033:0x7fe48aae39a8
> > > [   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
> > > [   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
> > > 7fe457b73040
> > > [   30.129259] RDX: 0030 RSI:  RDI:
> > > 7fe457b73000
> > > [   30.129855] RBP: 0300 R08: 000c R09:
> > > 0001
> > > [   30.130457] R10: 0001 R11: 0246 R12:
> > > 55cd4c1041a0
> > > [   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
> > > 0400
> > > [   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f
> > > ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff
> > > <0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
> > > [   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: 
> > > a7818222bba8
> > > [   30.133836] ---[ end trace d4f1deb60784f40a ]---
> > > 
> > > This is based off of Linus' master branch at
> > > c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
> > > Configs are at
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0
> > > 
> > Looks like a TTM regression due to:
> > 
> > 0284f1ead87463bc17cf5e81a24fc65c052486f3
> > drm/ttm: add transparent huge page support for cached allocations v2
> > 
> > If the driver requests dma32 pages, we can end up trying to alloc huge
> > dma32 pages which triggers the oops. The bochs driver always requests
> > dma32 here.
> > 
> > I'll send a rough patch once I boot it.
> > 
> > Dave.
> 
> 
> Hi Dave,
> 
> fyi only: It looks like this is not the only regression in this cycle with
> 

Re: [PATCH] drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage

[Daniel Vetter]

On Thu, Nov 23, 2017 at 09:24:11AM +0100, Boris Brezillon wrote:
> On Wed, 22 Nov 2017 16:13:31 -0800
> Eric Anholt  wrote:
> 
> > Boris Brezillon  writes:
> > 
> > > On Wed, 22 Nov 2017 13:16:08 -0800
> > > Eric Anholt  wrote:
> > >  
> > >> Boris Brezillon  writes:
> > >>   
> > >> > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
> > >> > passed a refcount object that has its counter set to 0. In this driver,
> > >> > this is a valid use case since we want to increment ->usecnt only when
> > >> > the BO object starts to be used by real HW components and this is
> > >> > definitely not the case when the BO is created.
> > >> >
> > >> > Fix the problem by using refcount_inc_not_zero() instead of
> > >> > refcount_inc() and fallback to refcount_set(1) when
> > >> > refcount_inc_not_zero() returns false. Note that this 2-steps operation
> > >> > is not racy here because the whole section is protected by a mutex
> > >> > which guarantees that the counter does not change between the
> > >> > refcount_inc_not_zero() and refcount_set() calls.
> > >> 
> > >> If we're not following the model, and protecting the refcount by a
> > >> mutex, shouldn't we just be using addition and subtraction instead of
> > >> refcount's atomics?  
> > >
> > > Actually, this mutex is protecting the bo->madv value which has to be
> > > checked when the counter reaches 0 (when decrementing) or 1 (when
> > > incrementing). We just benefit from this protection here, but ideally
> > > it would be better to have an refcount_inc_allow_zero() as suggested by
> > > Daniel.  
> > 
> > Let me restate this to see if it makes sense: The refcount is always >=
> > 0, this is is the only path that increases the refcount from 0 to 1, and
> > it's (incidentally) protected by a mutex, so there's no race between the
> > attempted increase from nonzero and the set from nonzero to 1.
> 
> Yep.
> 
> > 
> > This seems fine to me as a bugfix.
> 
> The discussion is going on in the other thread, let's wait a bit
> before taking a decision.

Let's not block the bugfix on reaching perfection imo. I'd merge this as
the minimal fix, and then apply the pretty paint once we have a clear idea
for that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

[Daniel Vetter]

On Fri, Nov 24, 2017 at 09:28:59AM +0100, Heiko Stuebner wrote:
> Hi Daniel,
> 
> [somehow my email address seems to have gotten lost, so
> only saw this by chance on the list itself now.
> I've also re-added Sandy to the recipients]
> 
> Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter:
> > On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
> > > For personal reasons, Mark Yao will leave rockchip,
> > > can not continue maintain drm/rockchip, Sandy Huang
> > > will take over the drm/rockchip.
> > > 
> > > Cc: Sandy Huang 
> > > Cc: Heiko Stuebner 
> > > 
> > > Signed-off-by: Mark Yao 
> > 
> > Since rockchip is in drm-misc that means we need a new maintainer who also
> > has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be
> > the new maintainer we need to fix that.
> > 
> > Also, Heiko, are you interested in becoming co-maintainer? With commit
> > rights and all.
> 
> I always feel somewhat inadequate judging the fast-paced drm stuff, as in
> the past once I got my head wrapped around something, drm always
> somehow moved another mile already ;-) .
> 
> But somewhere I read that drm-pace for big changes is supposed to slow a
> bit now that atomic modesetting is done in a lot of places, so we could give
> co-maintainership for the Rockchip-drm a try - with Sandy wearing the
> actual hat for big changes though ;-) .

Yeah I think on the modeset side it calmed down a lot. We're still
fine-tuning the helper libraries as we're figuring out better ways to
write drivers. But right now I think a lot of the action is all in details
not relevant for many drivers.

If Sandy's ok with that too pls request an fd.o account for drm-misc and
set up the tooling per our quickstart guide:

https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html#quickstart

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

Re: [PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjälä]

On Fri, Nov 24, 2017 at 03:32:22PM +0100, Philipp Zabel wrote:
> On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> > 
> > No functional changes as the code already uses crtc_state->mode
> > to populate the clip, which is also what drm_mode_get_hv_timing()
> > uses.
> 
> I don't understand this explanation, drm_mode_get_hv_timing uses
> whichever mode is passed to it?

Hmm. I worded that badly it seems. The point is that we pass the user
mode everywhere else where we want to know the dimensions of the
crtc coordinate space.

> 
> > Once everyone agrees on this we can move the clip handling into
> > drm_atomic_helper_check_plane_state().
> 
> I can see that there are no functional changes though,
> 
> Acked-by: Philipp Zabel 
> 
> regards
> Philipp

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

Re: [PATCH 06/15] drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Philipp Zabel]

On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> 
> Note that this replaces crtc_state->adjusted_mode usage with
> crtc_state->mode. The latter is the correct choice since that's the
> mode the user provided and it matches the plane crtc coordinates
> the user also provided.

I am not aware of any adjustments that change hdisplay/vdisplay anyway,

Acked-by: Philipp Zabel 

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

Re: [PATCH 07/15] drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Philipp Zabel]

On Thu, 2017-11-23 at 21:04 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> 
> No functional changes as the code already uses crtc_state->mode
> to populate the clip, which is also what drm_mode_get_hv_timing()
> uses.

I don't understand this explanation, drm_mode_get_hv_timing uses
whichever mode is passed to it?

> Once everyone agrees on this we can move the clip handling into
> drm_atomic_helper_check_plane_state().

I can see that there are no functional changes though,

Acked-by: Philipp Zabel 

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

Re: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

[Fabio Estevam]

Hi Jan,

On Thu, Nov 23, 2017 at 1:18 PM, Türk, Jan  wrote:
> Hi Fabio,
>
> I've used git send-email and tested the patches by checkpatch.pl before 
> without any problems.
> So it might have been touched by the mail server, so can you send me your 
> checkpatch.pl log (directly)?

Take a look at your patch here: https://patchwork.kernel.org/patch/10072765/

Click in the "patch" link and download it. You will notice that all
tabs have been converted into spaces.

checkpatch will warn about it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Ville Syrjälä]

On Fri, Nov 24, 2017 at 11:59:45AM +, Liviu Dudau wrote:
> On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> 
> Hi Ville,
> 
> > 
> > Move the plane clip rectangle handling into
> > drm_atomic_helper_check_plane_state(). Drivers no longer
> > have to worry about such mundane details.
> 
> This is quite an important patch and I dare say the essence of your
> series, right? Yet very few people got Cc-ed on it (1 AFAICT) and it
> touches quite a few drivers.

It has no functional changes, so forgetting to plaster it with Ccs
doesn't seem all that dangerous. All the (potentially) functional
changes were in the prep patches which had Ccs, as did the cover
letter. And maintainers should read the ml anyway ;)

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

Re: [PATCH] drm/stm: ltdc: add clut mode support

[Philippe CORNU]

Hi Peter,

On 11/13/2017 11:40 AM, Philippe CORNU wrote:
> Hi Peter,
> 
> On 11/12/2017 01:31 PM, Peter Rosin wrote:
>> On 2017-11-10 17:12, Philippe CORNU wrote:
>>> Hi Peter,
>>>
>>> On 11/07/2017 05:34 PM, Peter Rosin wrote:
 On 2017-11-07 16:53, Philippe CORNU wrote:
> + Peter
>
> Hi Peter,
>
> CLUT support on STM32 has been removed thanks to your clean up patch

 Support is a bit strong for what I thought was a dead function, or
 are you saying that it used to work before my series? Really sorry
 if that is the case!
>>>
>>> As I wrote in the previous related thread
>>> (https://lists.freedesktop.org/archives/dri-devel/2017-June/145070.html), 
>>>
>>> STM32 chipsets supports 8-bit CLUT mode but this driver version does not
>>> support it "yet"...
>>>
>>> So, no worry regarding your clean up, I gave you an "acked-by" for 
>>> that : )
>>
>> Ok, good. Thanks for clearing that up!
>>

 Anyway, the function I removed seemed to indicate that the hardware
 could handle a separate clut for each layer, but your new version
 does not. Why is that?
>>>
>>> Yes I confirm the clut support is available for each layer... but I
>>> thought the gamma_lut was only at the crtc level, not at layer level...
>>> Maybe I am wrong.
>>> Moreover, small test applications I used play only with clut at crtc
>>> level...
>>>
>>> Anyway, could you please help me to "find" a per-layer clut
>>> implementation because when I read "crtc->state->gamma_lut->data" it
>>> looks like gamma_lut is per crtc, not per plane...? or maybe I have to
>>> add extra properties for that...
>>
>> I wasn't clear enough. Yes, there is to my knowledge only one clut,
>> not one per plane. What I noticed was that the function I removed
>> seemed to touch clut registers for multiple layers, but your new
>> function appears to only touch registers for one layer. So, I
>> wondered if the "one and only" clut needed to be copied to the
>> registers for the other layers, or if the old dead code was simply
>> confused. Clearer?
>>
> 
> The old code was a generic helper function (ie. for all layers) but used 
> only for the 1st layer. So, we could say that "old dead code was simply 
> confused" :-)
> 
> When I put back the clut support in this patch, I decided to update only 
> the 1st layer (because there is no API for handling it on other layers). 
> I also decided to not re-use the former generic helper function as the 
> update loop is pretty small.
> 
> This patch offers the clut mode feature for fbdev (only one plane in 
> fbdev) and for drm (single plane for many use cases, 2nd plane being 
> used mostly for video...)
> 
> If tomorrow the API offers clut support per plane, the update loop will 
> be moved to the plane update function, means the generic helper function 
> will not be require anymore too.

 From the explanations above, do you think the patch is "acceptable" or 
should I change it somehow?
What is your opinion?
Many thanks,
Philippe :-)

> 
> Many thanks
> Philippe :)
> 
>> Cheers.
>> Peter
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/15] drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Thierry Reding]

On Thu, Nov 23, 2017 at 09:04:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> 
> No functional changes as the code already uses crtc_state->mode
> to populate the clip, which is also what drm_mode_get_hv_timing()
> uses.
> 
> Once everyone agrees on this we can move the clip handling into
> drm_atomic_helper_check_plane_state().
> 
> Cc: Laurent Pinchart 
> Cc: Thierry Reding 
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/tegra/dc.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)

I assume you want to take this through drm-misc, so:

Acked-by: Thierry Reding 


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

Re: [PATCH 00/15] drm: More plane clipping polish

[Thierry Reding]

On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> This series first unifies all users of drm_atomic_helper_check_plane_state()
> to populate the clip rectangle with drm_mode_get_hv_timing(), and once
> everything is unified the clip rectangle handling is sucked into
> drm_atomic_helper_check_plane_state() away from driver code.
> 
> Entire series available here:
> git://github.com/vsyrjala/linux.git atomic_plane_helper_clip
> 
> Cc: Archit Taneja 
> Cc: Ben Skeggs 
> Cc: Brian Starkey 
> Cc: CK Hu 
> Cc: Daniel Vetter 
> Cc: freedr...@lists.freedesktop.org
> Cc: Laurent Pinchart 
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: Liviu Dudau 
> Cc: Mali DP Maintainers 
> Cc: Mark Yao 
> Cc: Neil Armstrong 
> Cc: Noralf Trønnes 
> Cc: nouv...@lists.freedesktop.org
> Cc: Philipp Zabel 
> Cc: Rob Clark 
> Cc: Shawn Guo 
> Cc: Sinclair Yeh 
> Cc: Thierry Reding 
> Cc: Thomas Hellstrom 
> Cc: VMware Graphics 
> 
> Ville Syrjälä (15):
>   drm/i915: Reject odd pipe source width with double wide/dual link
>   drm/i915: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane
> clip rectangle
>   drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle
>   drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/meson: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane
> clip rectangle
>   drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip
> rectangle
>   drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle
>   drm: Don't pass clip to drm_atomic_helper_check_plane_state()
> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  6 +-
>  drivers/gpu/drm/arm/malidp_planes.c |  5 +
>  drivers/gpu/drm/armada/armada_overlay.c |  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  drivers/gpu/drm/drm_plane_helper.c  | 11 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  5 -
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 
>  drivers/gpu/drm/i915/intel_display.c| 12 +++-
>  drivers/gpu/drm/i915/intel_drv.h|  1 -
>  drivers/gpu/drm/i915/intel_sprite.c |  8 ++--
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  6 +-
>  drivers/gpu/drm/meson/meson_plane.c |  6 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
>  drivers/gpu/drm/nouveau/nv50_display.c  |  8 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  8 +---
>  drivers/gpu/drm/tegra/dc.c  |  8 +---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  8 +---
>  drivers/gpu/drm/zte/zx_plane.c  | 15 +--
>  include/drm/drm_atomic_helper.h |  1 -
>  include/drm/drm_plane_helper.h  |  1 -
>  21 files changed, 35 insertions(+), 117 deletions(-)

The series:

Reviewed-by: Thierry Reding 


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

Re: [PATCH libdrm] tests: fix MAKE_RGBA macro for 10bpp modes

[Ville Syrjälä]

On Thu, Nov 23, 2017 at 03:14:46PM -0500, Ilia Mirkin wrote:
> On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä
>  wrote:
> > On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
> >> We need to shift the values up, otherwise we'd end up with a negative
> >> shift. This works for up-to 16-bit components, which is fine for now.
> >
> > Shouldn't we actually replicate the high bits in the low bits?
> 
> Not entirely sure what you're proposing...
> 
> Ideally we wouldn't be lazy and pass e.g. 16-bit values to MAKE_RGBA
> which would then shift down as necessary (and even there, you could
> end up with off-by-1's maybe?). For e.g. 0xff, that should become
> 0x3ff but with my code will become 0x3fc.

Exactly the issue.

> But for other values, it's
> less clear what to do with the low bits. I figured it didn't really
> matter.
> 
> Do you have a concrete proposal?

The usual thing would be just

(value) * 0x3ff / 0xff

or

((value) << 2) | ((value) >> 6)

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

Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Ville Syrjälä]

On Fri, Nov 24, 2017 at 02:26:09PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/17/2017 6:19 PM, Ville Syrjälä wrote:
> > On Fri, Nov 17, 2017 at 05:50:11PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/17/2017 5:05 PM, Ville Syrjälä wrote:
> >>> On Fri, Nov 17, 2017 at 08:49:49AM +0530, Sharma, Shashank wrote:
>  Regards
> 
>  Shashank
> 
> 
>  On 11/16/2017 9:53 PM, Ville Syrjälä wrote:
> > On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
> >>> cause us to not send out any VICs in the AVI infoframes. That commit
> >>> was since reverted, but if and when we add aspect ratio handing back
> >>> we need to be more careful.
> >>>
> >>> Let's handle this by considering the aspect ratio as a requirement
> >>> for cea mode matching only if the passed in mode actually has a
> >>> non-zero aspect ratio field. This will keep userspace that doesn't
> >>> provide an aspect ratio working as before by matching it to the
> >>> first otherwise equal cea mode. And once userspace starts to
> >>> provide the aspect ratio it will be considerd a hard requirement
> >>> for the match.
> >>>
> >>> Also change the hdmi mode matching to use drm_mode_match() for
> >>> consistency, but we don't match on aspect ratio there since the
> >>> spec doesn't list a specific aspect ratio for those modes.
> >>>
> >>> Cc: Shashank Sharma 
> >>> Cc: "Lin, Jia" 
> >>> Cc: Akashdeep Sharma 
> >>> Cc: Jim Bride 
> >>> Cc: Jose Abreu 
> >>> Cc: Daniel Vetter 
> >>> Cc: Emil Velikov 
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>  drivers/gpu/drm/drm_edid.c | 18 ++
> >>>  1 file changed, 14 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>> index 7220b8f9a7e8..00aa98f3e55d 100644
> >>> --- a/drivers/gpu/drm/drm_edid.c
> >>> +++ b/drivers/gpu/drm/drm_edid.c
> >>> @@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
> >>> drm_display_mode *mode)
> >>>  static u8 drm_match_cea_mode_clock_tolerance(const struct 
> >>> drm_display_mode *to_match,
> >>>unsigned int 
> >>> clock_tolerance)
> >>>  {
> >>> + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> >>> DRM_MODE_MATCH_FLAGS;
> >>>   u8 vic;
> >>>  
> >>>   if (!to_match->clock)
> >>>   return 0;
> >>>  
> >>> + if (to_match->picture_aspect_ratio)
> >>> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> >> This doesn't look right. This means we are expecting a CEA mode without
> >> a pic aspect ratio field,
> >> which is invalid.
> > No, it's perfectly valid. It's what we currently get from userspace.
>  Yep, but that's due to missing Aspect ratio handling in the DRM layer.
>  If that's fixed, as per the list of CEA modes,
>  each CEA VIC contains an aspect ratio, which is a part of its unique
>  identity.
> 
>  I guess once we have the aspect ratio handling in DRM layer, it
>  would/should look like this:
>  - EDID gives you all supported modes, including CEA modes with Aspect 
>  ratio
>  - Userspcae gets the mode information, with aspect ratio (for CEA modes)
>  If ( Userspace picks one of the CEA modes)
> - sends a modeset
> - we find a matching CEA VIC, found one from modedb
> - we load this VIC = nonzero information in AVI IF VIC field,
>  else
> - sends a modeset
> - we could not find a matching CEA VIC, as aspect ratio is 0
> - we make VIC field in AVI IF as 0
> >>> No. That would break current userspace.
> >> I guess I forgot to make it clear, that userspace will set the cap, only
> >> then we will provide aspect ratio information.
> >> So this should not break userspace, isn't it ?
>  This is important, as HDMI compliance test 7-27 inspects if the VIC
>  field in the AVI IF is accurate.
> >>> Complicance is secondary to not breaking things that work. Also I find
> >>> it hard to see what purpose there is in having a complicance test that
> >>> sets a CEA modes w/o aspect ratio and then expects the infoframe to have
> >>> VIC 0.
> >> Again, typically this is how these analyzers force 

Re: [REBASE 3/5] drm: Expose modes with aspect ratio, only if requested

[Ville Syrjälä]

On Fri, Nov 24, 2017 at 02:36:17PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/21/2017 10:41 PM, Ville Syrjälä wrote:
> > On Fri, Nov 17, 2017 at 03:00:30PM +0530, Shashank Sharma wrote:
> >> From: aknautiy 
> >>
> >> We parse the EDID and add all the modes in the connector's
> >> modelist. This adds CEA modes with aspect ratio information
> >> too, regadless of if user space requested this information or
> >> not.
> >>
> >> This patch prunes the modes with aspect-ratio information, from
> >> a connector's modelist, if the user-space has not set the aspect
> >> ratio DRM client cap.
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Shashank Sharma 
> >> Cc: Jose Abreu 
> >>
> >> Signed-off-by: aknautiy 
> >> ---
> >>   drivers/gpu/drm/drm_connector.c | 7 +++
> >>   1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_connector.c 
> >> b/drivers/gpu/drm/drm_connector.c
> >> index 704fc89..a246bb5 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -1285,6 +1285,13 @@ static bool drm_mode_expose_to_userspace(const 
> >> struct drm_display_mode *mode,
> >> */
> >>if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
> >>return false;
> >> +  /*
> >> +   * If user-space hasn't configured the driver to expose the modes
> >> +   * with aspect-ratio, don't expose them.
> >> +   */
> >> +  if (!file_priv->aspect_ratio_allowed &&
> >> +  mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE)
> >> +  return false;
> > I don't think we can just blindly drop the modes. We would have to
> > expose them with the aspect ratio cleared. That could lead to
> > duplicates, but I'm thinking that shouldn't be a real problem for
> > userspace. Having to filteri out the duplicates would certainly
> > complicate things a bit.
> Yes, Agree. Even I was thinking that the right way should be to:
> - add a drm_mode_equal_no_aspect function (like 
> drm_mode_equal_no_clock_no_stereo).

Or just drm_mode_match() with the right flags ;)

> - clear the aspect ratio information from the mode, when not asked for.
> - check the sorted connector->modes list for duplicates for this mode, 
> using above function.
>  - if mode exists, remove it from the list
>  - if not, keep it in the list

Hmm. Since the list should be sorted I guess this won't even have to
traverse the list mutliple times. We can just keep skipping modes as
long they match the last mode we've already decided to expose.

> 
> Sounds like a plan ?
> 
> - Shashank
> >>   
> >>return true;
> >>   }
> >> -- 
> >> 2.7.4

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

Re: [PATCH] staging: vboxvideo: adapt to new TTM interface

[Greg KH]

On Fri, Nov 24, 2017 at 01:53:16PM +0100, Christian König wrote:
> Am 24.11.2017 um 11:37 schrieb Greg KH:
> > On Fri, Nov 24, 2017 at 11:32:59AM +0100, Christian König wrote:
> > > Fixes interface changes done in the following commits:
> > > drm/ttm: add operation ctx to ttm_bo_validate v2
> > > drm/ttm: add context to driver move callback as well
> > Any hints on the git commit ids in Linus's tree?
> 
> Those haven't arrived in Linus tree yet.
> 
> > And does this mean the driver's build is now broken?
> 
> Yes, it broke the build. Sorry that was my fault, didn't had this staging
> driver activated in the config nor noticed that there is an user of ttm
> outside the drm directory.
> 
> > Should this go through the staging tree, or is it to go through the drm 
> > tree?
> 
> The DRM tree I think. We should probably squash this patch into the original
> change which broke the driver in the DRM tree.

That's fine with me, thanks for the patch:

Acked-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: vboxvideo: adapt to new TTM interface

[Christian König]

Am 24.11.2017 um 11:37 schrieb Greg KH:

On Fri, Nov 24, 2017 at 11:32:59AM +0100, Christian König wrote:

Fixes interface changes done in the following commits:
drm/ttm: add operation ctx to ttm_bo_validate v2
drm/ttm: add context to driver move callback as well

Any hints on the git commit ids in Linus's tree?


Those haven't arrived in Linus tree yet.


And does this mean the driver's build is now broken?


Yes, it broke the build. Sorry that was my fault, didn't had this 
staging driver activated in the config nor noticed that there is an user 
of ttm outside the drm directory.



Should this go through the staging tree, or is it to go through the drm tree?


The DRM tree I think. We should probably squash this patch into the 
original change which broke the driver in the DRM tree.


Regards,
Christian.



thanks,

greg k-h



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

Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Liviu Dudau]

On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
> 
> Cc: Laurent Pinchart 
> Cc: Daniel Vetter 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  7 +--
>  drivers/gpu/drm/arm/malidp_planes.c |  7 +--
>  drivers/gpu/drm/armada/armada_overlay.c |  6 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  drivers/gpu/drm/drm_plane_helper.c  | 11 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  6 --
>  drivers/gpu/drm/i915/intel_display.c| 12 
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  7 +--
>  drivers/gpu/drm/meson/meson_plane.c |  7 +--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
>  drivers/gpu/drm/nouveau/nv50_display.c  | 12 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 +--
>  drivers/gpu/drm/tegra/dc.c  |  7 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  7 +--
>  drivers/gpu/drm/zte/zx_plane.c  | 13 +
>  include/drm/drm_atomic_helper.h |  1 -
>  include/drm/drm_plane_helper.h  |  1 -
>  18 files changed, 22 insertions(+), 122 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index fa852fc1c9e6..93c503b754ba 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs 
> hdlcd_crtc_helper_funcs = {
>  static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
> - struct drm_rect clip = { 0 };
>   struct drm_crtc_state *crtc_state;
>   u32 src_h = state->src_h >> 16;
>  
> @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
> *plane,
>   return -EINVAL;
>   }
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - return drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + return drm_atomic_helper_check_plane_state(state, crtc_state,
>  DRM_PLANE_HELPER_NO_SCALING,
>  DRM_PLANE_HELPER_NO_SCALING,
>  false, true);
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 2f6d608d6eaf..e630c0218aaf 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane 
> *mp,
>   struct drm_crtc_state *crtc_state =
>   drm_atomic_get_existing_crtc_state(state->state, state->crtc);
>   struct malidp_crtc_state *mc;
> - struct drm_rect clip = { 0 };
>   u32 src_w, src_h;
>   int ret;
>  
>   if (!crtc_state)
>   return -EINVAL;
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> 0, INT_MAX, true, true);
>   if (ret)
>   return ret;

For the hdlcd and malidp changes above:

Acked-by: Liviu Dudau 

Best regards,
Liviu

> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index b411b608821a..564bd63a5f6a 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>   .x2 = crtc_x + crtc_w,
>   .y2 = crtc_y + crtc_h,
>   };
> - const struct drm_rect clip = {
> - .x2 = crtc->mode.hdisplay,
> - .y2 = crtc->mode.vdisplay,
> - };
>   uint32_t val, ctrl0;
>   unsigned idx = 0;
>   bool visible;
> @@ -124,7 +120,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>crtc_x, crtc_y, crtc_w, crtc_h,
>src_x, src_y, src_w, src_h);
>  
> - ret = drm_plane_helper_check_update(plane, crtc, fb, , , ,
> + ret = drm_plane_helper_check_update(plane, crtc, fb, , ,
> 

Re: [PATCH 15/15] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Liviu Dudau]

On Thu, Nov 23, 2017 at 09:05:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 

Hi Ville,

> 
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.

This is quite an important patch and I dare say the essence of your
series, right? Yet very few people got Cc-ed on it (1 AFAICT) and it
touches quite a few drivers.

May I respectfully suggest that you review your patch sending process?
You have Cc-ed me only on patches 3 and 4 and I could easy asssume that
those were all the changes you have made to the driver, which is
obviously not the case here.

I tend to err on the side of verbosity and include everyone touched by
a patch in a series into all the patches of that series. Is by no mean the
best approach, but is one way I avoid situations like this.

Best regards,
Liviu

> 
> Cc: Laurent Pinchart 
> Cc: Daniel Vetter 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  7 +--
>  drivers/gpu/drm/arm/malidp_planes.c |  7 +--
>  drivers/gpu/drm/armada/armada_overlay.c |  6 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  drivers/gpu/drm/drm_plane_helper.c  | 11 +++
>  drivers/gpu/drm/drm_simple_kms_helper.c |  6 --
>  drivers/gpu/drm/i915/intel_display.c| 12 
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  7 +--
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  7 +--
>  drivers/gpu/drm/meson/meson_plane.c |  7 +--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   | 14 ++
>  drivers/gpu/drm/nouveau/nv50_display.c  | 12 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 +--
>  drivers/gpu/drm/tegra/dc.c  |  7 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  7 +--
>  drivers/gpu/drm/zte/zx_plane.c  | 13 +
>  include/drm/drm_atomic_helper.h |  1 -
>  include/drm/drm_plane_helper.h  |  1 -
>  18 files changed, 22 insertions(+), 122 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index fa852fc1c9e6..93c503b754ba 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs 
> hdlcd_crtc_helper_funcs = {
>  static int hdlcd_plane_atomic_check(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
> - struct drm_rect clip = { 0 };
>   struct drm_crtc_state *crtc_state;
>   u32 src_h = state->src_h >> 16;
>  
> @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
> *plane,
>   return -EINVAL;
>   }
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - return drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + return drm_atomic_helper_check_plane_state(state, crtc_state,
>  DRM_PLANE_HELPER_NO_SCALING,
>  DRM_PLANE_HELPER_NO_SCALING,
>  false, true);
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 2f6d608d6eaf..e630c0218aaf 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane 
> *mp,
>   struct drm_crtc_state *crtc_state =
>   drm_atomic_get_existing_crtc_state(state->state, state->crtc);
>   struct malidp_crtc_state *mc;
> - struct drm_rect clip = { 0 };
>   u32 src_w, src_h;
>   int ret;
>  
>   if (!crtc_state)
>   return -EINVAL;
>  
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(_state->mode,
> -, );
> -
> - ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> 0, INT_MAX, true, true);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index b411b608821a..564bd63a5f6a 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -111,10 +111,6 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>   .x2 = crtc_x + crtc_w,
>   .y2 = crtc_y + crtc_h,
>   };
> - const struct drm_rect clip = {
> - .x2 = 

Re: [PATCH 04/15] drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Liviu Dudau]

On Thu, Nov 23, 2017 at 09:04:51PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> 
> Note that this replaces crtc_state->adjusted_mode usage with
> crtc_state->mode. The latter is the correct choice since that's the
> mode the user provided and it matches the plane crtc coordinates
> the user also provided.
> 
> Once everyone agrees on this we can move the clip handling into
> drm_atomic_helper_check_plane_state().
> 
> Cc: Laurent Pinchart 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Signed-off-by: Ville Syrjälä 

Acked-by: Liviu Dudau 

Please let me know if you need me to pull this patch into the mali-dp tree.

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/malidp_planes.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 72a07950167e..2f6d608d6eaf 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -148,8 +148,10 @@ static int malidp_se_check_scaling(struct malidp_plane 
> *mp,
>   if (!crtc_state)
>   return -EINVAL;
>  
> - clip.x2 = crtc_state->adjusted_mode.hdisplay;
> - clip.y2 = crtc_state->adjusted_mode.vdisplay;
> + if (crtc_state->enable)
> + drm_mode_get_hv_timing(_state->mode,
> +, );
> +
>   ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
> 0, INT_MAX, true, true);
>   if (ret)
> -- 
> 2.13.6
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/15] drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Liviu Dudau]

On Thu, Nov 23, 2017 at 09:04:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> 
> Note that this replaces crtc_state->adjusted_mode usage with
> crtc_state->mode. The latter is the correct choice since that's the
> mode the user provided and it matches the plane crtc coordinates
> the user also provided.
> 
> Once everyone agrees on this we can move the clip handling into
> drm_atomic_helper_check_plane_state().
> 
> Cc: Laurent Pinchart 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Signed-off-by: Ville Syrjälä 

Acked-by: Liviu Dudau 

Please let me know if you need me to pull this patch into the HDLCD tree.

Best regards,
Liviu

> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 63511a3bbf6c..fa852fc1c9e6 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -249,8 +249,9 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
> *plane,
>   return -EINVAL;
>   }
>  
> - clip.x2 = crtc_state->adjusted_mode.hdisplay;
> - clip.y2 = crtc_state->adjusted_mode.vdisplay;
> + if (crtc_state->enable)
> + drm_mode_get_hv_timing(_state->mode,
> +, );
>  
>   return drm_atomic_helper_check_plane_state(state, crtc_state, ,
>  DRM_PLANE_HELPER_NO_SCALING,
> -- 
> 2.13.6
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: vboxvideo: adapt to new TTM interface

[Greg KH]

On Fri, Nov 24, 2017 at 11:32:59AM +0100, Christian König wrote:
> Fixes interface changes done in the following commits:
> drm/ttm: add operation ctx to ttm_bo_validate v2
> drm/ttm: add context to driver move callback as well

Any hints on the git commit ids in Linus's tree?

And does this mean the driver's build is now broken?  Should this go
through the staging tree, or is it to go through the drm tree?

thanks,

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

Re: [PATCH] staging: vboxvideo: adapt to new TTM interface

[Christian König]

Am 24.11.2017 um 11:31 schrieb Greg KH:

On Fri, Nov 24, 2017 at 11:29:27AM +0100, Christian König wrote:

I missed this driver because it is in the staging area.

What does this changelog text mean???


Sorry for the confusion, the patch was originally part of a larger series.

Just send it out again with an updated commit message.




Signed-off-by: Christian König 
Reviewed-by: Hans de Goede 
---
  drivers/staging/vboxvideo/vbox_ttm.c | 17 ++---
  1 file changed, 6 insertions(+), 11 deletions(-)

Please provide something that makes sense when reading the changelog
text on its own.


Done, but please note that I'm not sure if the interface this breaks has 
already reached any of the relevant upstream repositories.


I just added you to the list of recipients because Hans suggested to do so.

Regards,
Christian.



thanks,

greg k-h



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

[PATCH] staging: vboxvideo: adapt to new TTM interface

[Christian König]

Fixes interface changes done in the following commits:
drm/ttm: add operation ctx to ttm_bo_validate v2
drm/ttm: add context to driver move callback as well

I missed this driver because it is in the staging area.

Signed-off-by: Christian König 
Reviewed-by: Hans de Goede 
---
 drivers/staging/vboxvideo/vbox_ttm.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
b/drivers/staging/vboxvideo/vbox_ttm.c
index 4eb410a2a1a8..231c89e0699c 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device 
*bdev,
 {
 }
 
-static int vbox_bo_move(struct ttm_buffer_object *bo,
-   bool evict, bool interruptible,
-   bool no_wait_gpu, struct ttm_mem_reg *new_mem)
-{
-   return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
-}
-
 static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
 {
ttm_tt_fini(tt);
@@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = {
.init_mem_type = vbox_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vbox_bo_evict_flags,
-   .move = vbox_bo_move,
.verify_access = vbox_bo_verify_access,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_free = _ttm_io_mem_free,
@@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
 
 int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (bo->pin_count) {
@@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 
*gpu_addr)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
 
@@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 
*gpu_addr)
 
 int vbox_bo_unpin(struct vbox_bo *bo)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (!bo->pin_count) {
@@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
 
@@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)
  */
 int vbox_bo_push_sysram(struct vbox_bo *bo)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (!bo->pin_count) {
@@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret) {
DRM_ERROR("pushing to VRAM failed\n");
return ret;
-- 
2.11.0

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

Re: [PATCH] staging: vboxvideo: adapt to new TTM interface

[Greg KH]

On Fri, Nov 24, 2017 at 11:29:27AM +0100, Christian König wrote:
> I missed this driver because it is in the staging area.

What does this changelog text mean???

> Signed-off-by: Christian König 
> Reviewed-by: Hans de Goede 
> ---
>  drivers/staging/vboxvideo/vbox_ttm.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)

Please provide something that makes sense when reading the changelog
text on its own.

thanks,

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

[PATCH] staging: vboxvideo: adapt to new TTM interface

[Christian König]

I missed this driver because it is in the staging area.

Signed-off-by: Christian König 
Reviewed-by: Hans de Goede 
---
 drivers/staging/vboxvideo/vbox_ttm.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
b/drivers/staging/vboxvideo/vbox_ttm.c
index 4eb410a2a1a8..231c89e0699c 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -183,13 +183,6 @@ static void vbox_ttm_io_mem_free(struct ttm_bo_device 
*bdev,
 {
 }
 
-static int vbox_bo_move(struct ttm_buffer_object *bo,
-   bool evict, bool interruptible,
-   bool no_wait_gpu, struct ttm_mem_reg *new_mem)
-{
-   return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
-}
-
 static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
 {
ttm_tt_fini(tt);
@@ -237,7 +230,6 @@ static struct ttm_bo_driver vbox_bo_driver = {
.init_mem_type = vbox_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vbox_bo_evict_flags,
-   .move = vbox_bo_move,
.verify_access = vbox_bo_verify_access,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_free = _ttm_io_mem_free,
@@ -374,6 +366,7 @@ static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
 
 int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (bo->pin_count) {
@@ -389,7 +382,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 
*gpu_addr)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
 
@@ -403,6 +396,7 @@ int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 
*gpu_addr)
 
 int vbox_bo_unpin(struct vbox_bo *bo)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (!bo->pin_count) {
@@ -416,7 +410,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret)
return ret;
 
@@ -430,6 +424,7 @@ int vbox_bo_unpin(struct vbox_bo *bo)
  */
 int vbox_bo_push_sysram(struct vbox_bo *bo)
 {
+   struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (!bo->pin_count) {
@@ -448,7 +443,7 @@ int vbox_bo_push_sysram(struct vbox_bo *bo)
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(>bo, >placement, false, false);
+   ret = ttm_bo_validate(>bo, >placement, );
if (ret) {
DRM_ERROR("pushing to VRAM failed\n");
return ret;
-- 
2.11.0

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

[Bug 103887] OpenCL segfault on RX550 (Lexa)

[bugzilla-daemon]

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

Bug ID: 103887
   Summary: OpenCL segfault on RX550 (Lexa)
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu-pro
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: luka.kari...@gmail.com

Hello. Support for RX550 (Lexa) seem to be missing for the amdgpu-pro driver
i did try amdgpu-pro from 17.10 - 17.40.
clinfo shows no devices aviabile and if i force an app to use the opencl lib
from amdgpupro the app segfaults...
Release notes from the drivers clearly states Lexa supports OpenCL with pro
drivers

-- 
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: [REBASE 3/5] drm: Expose modes with aspect ratio, only if requested

[Sharma, Shashank]

Regards

Shashank


On 11/21/2017 10:41 PM, Ville Syrjälä wrote:

On Fri, Nov 17, 2017 at 03:00:30PM +0530, Shashank Sharma wrote:

From: aknautiy 

We parse the EDID and add all the modes in the connector's
modelist. This adds CEA modes with aspect ratio information
too, regadless of if user space requested this information or
not.

This patch prunes the modes with aspect-ratio information, from
a connector's modelist, if the user-space has not set the aspect
ratio DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: aknautiy 
---
  drivers/gpu/drm/drm_connector.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc89..a246bb5 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1285,6 +1285,13 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE)
+   return false;

I don't think we can just blindly drop the modes. We would have to
expose them with the aspect ratio cleared. That could lead to
duplicates, but I'm thinking that shouldn't be a real problem for
userspace. Having to filteri out the duplicates would certainly
complicate things a bit.

Yes, Agree. Even I was thinking that the right way should be to:
- add a drm_mode_equal_no_aspect function (like 
drm_mode_equal_no_clock_no_stereo).

- clear the aspect ratio information from the mode, when not asked for.
- check the sorted connector->modes list for duplicates for this mode, 
using above function.

- if mode exists, remove it from the list
- if not, keep it in the list

Sounds like a plan ?

- Shashank
  
  	return true;

  }
--
2.7.4


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

[Bug 103850] "Quern" game crashes on start-up

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer  ---
The valgrind output for Quern shows writes to freed memory, because the game
makes libX11 calls using a display handle that it had already closed. That's a
bug in the game (or maybe in a library it links statically), which could
explain the crash.

I don't see any obvious issue in the valgrind output for Unturned either
though.

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

Re: [REBASE 2/5] drm: Handle aspect ratio in modeset paths

[Nautiyal, Ankit K]

Hi Ville,

Thanks for the suggestions. Please find my response inline


On 11/21/2017 10:41 PM, Ville Syrjälä wrote:

On Fri, Nov 17, 2017 at 03:00:29PM +0530, Shashank Sharma wrote:

From: Ankit Nautiyal 

If the user mode does not support aspect-ratio, and requests for
a modeset with aspect ratio flags, then the flag bits reprsenting
aspect ratio must be ignored.

Rejected, not ignored. Rejection should happen when converting
the umode to mode.

And filtering should happen in getcrtc and getblob. The way you're
currently doing things will corrupt the current state, which is
not good.


Agreed.
The filtering is being done in getcrtc but getblob was missing.
Will add the changes in getblob and send the new patch.

Regards,
Ankit

Similarly, if user space doesn't set the aspect ratio client cap,
while preparing a usermode, the aspect-ratio info must not be given
into it.

This patch:
1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
which is set only if the aspect-ratio is supported by the user.
2. discards the aspect-ratio info from the user mode while
preparing kernel mode structure, during modeset, if the
user does not support aspect ratio.
3. avoids setting the aspect-ratio info in user-mode, while
converting user-mode from the kernel-mode.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 
Signed-off-by: Ankit Nautiyal 
---
  drivers/gpu/drm/drm_atomic.c | 40 +---
  drivers/gpu/drm/drm_crtc.c   | 19 +++
  include/drm/drm_atomic.h |  2 ++
  3 files changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 37445d5..b9743af 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -338,18 +338,30 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
state->mode_blob = NULL;
  
  	if (mode) {

-   drm_mode_convert_to_umode(, mode);
+   /*
+* If the user has not asked for aspect ratio support,
+* take a copy of the 'mode' and set the aspect ratio as
+* None. This copy is used to prepare the user-mode with no
+* aspect-ratio info.
+*/
+   struct drm_display_mode ar_mode;
+   struct drm_atomic_state *atomic_state = state->state;
+
+   drm_mode_copy(_mode, mode);
+   if (atomic_state && !atomic_state->allow_aspect_ratio)
+   ar_mode.picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   drm_mode_convert_to_umode(, _mode);
state->mode_blob =
drm_property_create_blob(state->crtc->dev,
-sizeof(umode),
-);
+sizeof(umode),
+);
if (IS_ERR(state->mode_blob))
return PTR_ERR(state->mode_blob);
  
-		drm_mode_copy(>mode, mode);

+   drm_mode_copy(>mode, _mode);
state->enable = true;
DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
-mode->name, state);
+ar_mode.name, state);
} else {
memset(>mode, 0, sizeof(state->mode));
state->enable = false;
@@ -386,10 +398,23 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
  
  	if (blob) {

+   struct drm_mode_modeinfo *ar_umode;
+   struct drm_atomic_state *atomic_state;
+
+   /*
+* If the user-space does not ask for aspect-ratio
+* the aspect ratio bits in the drmModeModeinfo from user,
+* does not mean anything. Therefore these bits must be
+* discarded.
+*/
+   ar_umode = (struct drm_mode_modeinfo *) blob->data;
+   atomic_state = state->state;
+   if (atomic_state && !atomic_state->allow_aspect_ratio)
+   ar_umode->flags &= (~DRM_MODE_FLAG_PIC_AR_MASK);
if (blob->length != sizeof(struct drm_mode_modeinfo) ||
drm_mode_convert_umode(>mode,
-  (const struct drm_mode_modeinfo *)
-   blob->data))
+  (const struct drm_mode_modeinfo *)
+   ar_umode))
return -EINVAL;
  
  		state->mode_blob = drm_property_blob_get(blob);

@@ -2229,6 +2254,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
  
  	

Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 11/17/2017 6:19 PM, Ville Syrjälä wrote:

On Fri, Nov 17, 2017 at 05:50:11PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/17/2017 5:05 PM, Ville Syrjälä wrote:

On Fri, Nov 17, 2017 at 08:49:49AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/16/2017 9:53 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7220b8f9a7e8..00aa98f3e55d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
 	if (!to_match->clock)

return 0;
 
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;

This doesn't look right. This means we are expecting a CEA mode without
a pic aspect ratio field,
which is invalid.

No, it's perfectly valid. It's what we currently get from userspace.

Yep, but that's due to missing Aspect ratio handling in the DRM layer.
If that's fixed, as per the list of CEA modes,
each CEA VIC contains an aspect ratio, which is a part of its unique
identity.

I guess once we have the aspect ratio handling in DRM layer, it
would/should look like this:
- EDID gives you all supported modes, including CEA modes with Aspect ratio
- Userspcae gets the mode information, with aspect ratio (for CEA modes)
If ( Userspace picks one of the CEA modes)
   - sends a modeset
   - we find a matching CEA VIC, found one from modedb
   - we load this VIC = nonzero information in AVI IF VIC field,
else
   - sends a modeset
   - we could not find a matching CEA VIC, as aspect ratio is 0
   - we make VIC field in AVI IF as 0a

No. That would break current userspace.

I guess I forgot to make it clear, that userspace will set the cap, only
then we will provide aspect ratio information.
So this should not break userspace, isn't it ?

This is important, as HDMI compliance test 7-27 inspects if the VIC
field in the AVI IF is accurate.

Complicance is secondary to not breaking things that work. Also I find
it hard to see what purpose there is in having a complicance test that
sets a CEA modes w/o aspect ratio and then expects the infoframe to have
VIC 0.

Again, typically this is how these analyzers force modeset:
- They send EDID with only one mode, which is the test mode, with aspect
ratio.
- They expect that VIC to be present in AVI IF

- Shashank

Ankit is going to publish the aspect ratio patch
series again, with proper DRM cap and flags check. Would it be
ok if we have a look that handling first ?

This patch will be needed by that work. Otherwise we're going to stop
sending a VIC for CEA modes with current userspace.

I guess we should force userspaces to start bothering about aspect ratio
field, right now we
are doing this for Wayland based compositors, may be we should extend it
to X based too.

Yes, I've been saying that someone should look into extending the randr
protocol with the necessary bits. But that still doesn't allow us to
change the current behaviour as old userspace would anyway linger around
for a long time.

I think cap will cove this part

The cap is irrelevant to this discussion. It 

[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

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

--- Comment #42 from Michel Dänzer  ---
(In reply to Robert Liu from comment #41)
> Another issue found is when removing the adapter, the system goes to
> suspend.

That's not directly related to graphics drivers.

-- 
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 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/17/2017 5:08 PM, Ville Syrjälä wrote:

On Fri, Nov 17, 2017 at 08:53:54AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/16/2017 9:56 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
drivers/gpu/drm/drm_edid.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00aa98f3e55d..bafb3ee4ea97 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
{
+   enum hdmi_picture_aspect picture_aspect;
int err;

	if (!frame || !mode)

@@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);

This is slightly going in the loop.
- During the modeset the driver cant specify the aspect ratio
information, as DRM layer lacks this support.
- So we fill the VIC field, by comparing the mode with the
DRM_CEA_MODES[] list. This will pick the first mode
 available in the list (regardless of its aspect ratio), and fill the
VIC, as we don't consider aspect ratio while comparing timings.
- Again, now while sending the aspect ratio, we are picking up the VIC,
which may not be correct.

So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is
first in list, we will always pick 4:3 aspect ratio.

Yes. The user didn't care about the aspect ratio (or rather couldn't
specify one) so we just pick one. Which is exactly what we've been
doing ever since we started sending the VIC in the infoframe.

Correct, and we are hoping that this should be better (if not fixed)
with the aspect ratio support
patches + DRM cap. If the userspace doesn't set the cap, then anyways
there is no aspect ratio
field available, and VIC would be always 0, as this becomes a Non CEA mode.

Or do you think it would be a better idea to send some VIC instead of No
VIC, when userspace doesn't
set the DRM cap for aspect ratio ?

Yes. That's the current behaviour.

IIRC some crappy amplifiers etc. with HDMI passthrough don't even work
correctly unless VIC is specified. Hence we do want to send it whenever
possible.
Ok, in this case this make sense, and then I kindof agree with what this 
patch is trying to do.

Reviewed-by: Shashank Sharma 

- Shashank

- Shashank

+	/*

+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;



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

[PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

[Jan Tuerk]

Adding the label cpu0 allows the adjustment of cpu-parameters
by reference in overlaying dtsi files in the same way as it
is possible for imx6q devices.

Signed-off-by: Jan Tuerk 
---
 arch/arm/boot/dts/imx6dl.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 4d693a75ce98..623c12519b81 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -21,7 +21,7 @@
#address-cells = <1>;
#size-cells = <0>;

-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
--
2.11.0


emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___

Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

[Jan Tuerk]

This patch adds support for the emtrion GmbH emCON-MX6 modules.
They are available with imx.6 Solo, Dual-Lite, Dual and Quad
equipped with Memory from 512MB to 2GB (configured by U-Boot).

Our default developer-Kit ships with the Avari baseboard and the
EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).

The devicetree is split into the common part providing all module
components and the basic support for all SoC versions
(imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
Finally the support for the avari baseboard in the developer-kit
configuration is provided by the emcon-avari dts files.

Signed-off-by: Jan Tuerk 
---
 Documentation/devicetree/bindings/arm/emtrion.txt |  13 +
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/imx6dl-emcon-avari.dts  | 233 ++
 arch/arm/boot/dts/imx6dl-emcon.dtsi   |  37 +
 arch/arm/boot/dts/imx6q-emcon-avari.dts   | 233 ++
 arch/arm/boot/dts/imx6q-emcon.dtsi|  37 +
 arch/arm/boot/dts/imx6qdl-emcon.dtsi  | 849 ++
 7 files changed, 1404 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi

diff --git a/Documentation/devicetree/bindings/arm/emtrion.txt 
b/Documentation/devicetree/bindings/arm/emtrion.txt
new file mode 100644
index ..3ff6c6c2034d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/emtrion.txt
@@ -0,0 +1,13 @@
+Emtrion Devicetree Bindings
+===
+
+emCON Series:
+-
+
+Required root node properties
+   - compatible:
+   - "emtrion,emcon-mx6", "fsl,imx6q", "fsl,imx6dl"; : emCON-MX6 Generic 
SoM
+   - "emtrion,emcon-mx6", "fsl,imx6q"; : emCON-MX6D or 
emCON-MX6Q SoM
+   - "emtrion,emcon-mx6-avari", "fsl,imx6q";   : emCON-MX6D or 
emCON-MX6Q SoM on Avari Base
+   - "emtrion,emcon-mx6", "fsl,imx6dl";: emCON-MX6S or 
emCON-MX6DL SoM
+   - "emtrion,emcon-mx6-avari", "fsl,imx6dl";  : emCON-MX6S or 
emCON-MX6DL SoM on Avari Base
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..5ce643ece228 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -373,6 +373,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-colibri-eval-v3.dtb \
imx6dl-cubox-i.dtb \
imx6dl-dfi-fs700-m60.dtb \
+   imx6dl-emcon-avari.dtb \
imx6dl-gw51xx.dtb \
imx6dl-gw52xx.dtb \
imx6dl-gw53xx.dtb \
@@ -424,6 +425,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-dfi-fs700-m60.dtb \
imx6q-display5-tianma-tm070-1280x768.dtb \
imx6q-dmo-edmqmx6.dtb \
+   imx6q-emcon-avari.dtb \
imx6q-evi.dtb \
imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts 
b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
new file mode 100644
index ..f8ca63258eda
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
@@ -0,0 +1,233 @@
+/*
+ * Copyright (C) 2017 emtrion GmbH
+ * Author: Jan Tuerk  
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-emcon.dtsi"
+#include "imx6dl-emcon.dtsi" /*Include camera2 pinmux*/
+
+/ {
+   model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari";
+   compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl";
+
+   aliases {
+   mmc0 = 
+   mmc2 = 
+   mmc1 = 
+   mmc3 = 
+   };
+
+   chosen {
+   stdout-path = <>;
+   };
+
+   memory {
+   reg = <0x1000 0x4000>;
+   };
+
+   supplies {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   wallplug5p0: supply@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "WALL-PLUG";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   base3p3: supply@1 {
+   compatible = "regulator-fixed";
+   reg = <1>;
+   

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Rainer Fiebig]

Greg KH wrote:
> On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote:
>> Rainer Fiebig wrote:
>>> Maarten Lankhorst wrote:
 Op 20-11-17 om 09:51 schreef Rainer Fiebig:
> Jani Nikula wrote:
>> On Sun, 19 Nov 2017, Greg KH  wrote:
>>> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
 Greg KH wrote:
> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
 Greg KH wrote:
> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>> Hi!
>>
>> Hopefully the right addressee.
>>
>> Encountered two bad backports which cause screen-flicker.
>> dmesg shows:
>>
>> ...
>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO 
>> underrun
>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
>> underrun
>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
>> underrun
>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
>> underrun
>> ...
>>
>> CPU: Intel Core i3 (Clarkdale/Ironlake)
>>
>> The backports are:
>>
>> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 49de476..277a802 100644
>> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index a19ec06..3ce9ba3 100644
>>
>> After reversing them the flicker is gone, no more messages in 
>> dmesg. All
>> else OK so far.
> So which commit was the one that caused the problem?  I will be 
> glad to
> revert it.
>
> thanks,
>
> greg k-h
>
>
 I started by reverting the more complex one first ("index
 49de476..277a802100644"). But the kernel wouldn't compile then.
>>> What git commit id is that?  I don't see those ids in the 4.9-stable
>>> tree.
>>>
 So I also reverted "index a19ec06..3ce9ba3 100644". After that the
 kernel compiled just fine and the problems were gone (still are).
>>> Same here, what git commit id was this?
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>> OK, no mistake. IIRC, I took the patches (and the IDs) from the
>> changelog for patch-4.9.62. I've attached both, so you can check 
>> yourself.
>>
>> I've also applied a freshly downloaded patch-4.9.62 to a freshly
>> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
>> reverted the two patches but I'm confident that after having done so 
>> the
>> flicker will be gone. If not I'll let you know.
>>
>> As a good news: 4.14 is *not* affected. So to me it seems those two
>> patches are part of sort of a package and can not be backported 
>> alone.
>>
>> So long!
>> Rainer Fiebig
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 49de476..277a802 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -27,6 +27,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include "i915_drv.h"
>>  #include "intel_drv.h"
>>  #include "../../../platform/x86/intel_ips.h"
>> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
>> drm_i915_private *dev_priv,
>>   const struct intel_crtc *intel_crtc,
>>   int level,
>>   struct intel_crtc_state *cstate,
>> - struct intel_plane_state *pristate,
>> - struct intel_plane_state *sprstate,
>> - struct intel_plane_state *curstate,
>> + const struct intel_plane_state 
>> *pristate,
>> + const struct intel_plane_state 
>> *sprstate,
>> + const struct intel_plane_state 
>> *curstate,
>>   struct intel_wm_level *result)
>>  {
>>  uint16_t pri_latency = dev_priv->wm.pri_latency[level];
>> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
>> intel_crtc_state 

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Rainer Fiebig]

Rainer Fiebig wrote:
> Maarten Lankhorst wrote:
>> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
>>> Jani Nikula wrote:
 On Sun, 19 Nov 2017, Greg KH  wrote:
> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>>> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
 Greg KH wrote:
> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
 Hi!

 Hopefully the right addressee.

 Encountered two bad backports which cause screen-flicker.
 dmesg shows:

 ...
 [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
 [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
 underrun
 [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
 [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
 underrun
 ...

 CPU: Intel Core i3 (Clarkdale/Ironlake)

 The backports are:

 - diff --git a/drivers/gpu/drm/i915/intel_pm.c
 b/drivers/gpu/drm/i915/intel_pm.c
 index 49de476..277a802 100644
 - diff --git a/drivers/gpu/drm/i915/intel_drv.h
 b/drivers/gpu/drm/i915/intel_drv.h
 index a19ec06..3ce9ba3 100644

 After reversing them the flicker is gone, no more messages in 
 dmesg. All
 else OK so far.
>>> So which commit was the one that caused the problem?  I will be 
>>> glad to
>>> revert it.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>>
>> I started by reverting the more complex one first ("index
>> 49de476..277a802100644"). But the kernel wouldn't compile then.
> What git commit id is that?  I don't see those ids in the 4.9-stable
> tree.
>
>> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
>> kernel compiled just fine and the problems were gone (still are).
> Same here, what git commit id was this?
>
> thanks,
>
> greg k-h
>
 OK, no mistake. IIRC, I took the patches (and the IDs) from the
 changelog for patch-4.9.62. I've attached both, so you can check 
 yourself.

 I've also applied a freshly downloaded patch-4.9.62 to a freshly
 expanded 4.9 and re-compiled. The flicker is there. I haven't yet
 reverted the two patches but I'm confident that after having done so 
 the
 flicker will be gone. If not I'll let you know.

 As a good news: 4.14 is *not* affected. So to me it seems those two
 patches are part of sort of a package and can not be backported alone.

 So long!
 Rainer Fiebig
 diff --git a/drivers/gpu/drm/i915/intel_pm.c 
 b/drivers/gpu/drm/i915/intel_pm.c
 index 49de476..277a802 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -27,6 +27,7 @@
  
  #include 
  #include 
 +#include 
  #include "i915_drv.h"
  #include "intel_drv.h"
  #include "../../../platform/x86/intel_ips.h"
 @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
 drm_i915_private *dev_priv,
 const struct intel_crtc *intel_crtc,
 int level,
 struct intel_crtc_state *cstate,
 -   struct intel_plane_state *pristate,
 -   struct intel_plane_state *sprstate,
 -   struct intel_plane_state *curstate,
 +   const struct intel_plane_state 
 *pristate,
 +   const struct intel_plane_state 
 *sprstate,
 +   const struct intel_plane_state 
 *curstate,
 struct intel_wm_level *result)
  {
uint16_t pri_latency = dev_priv->wm.pri_latency[level];
 @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
 intel_crtc_state *cstate)
struct intel_pipe_wm *pipe_wm;
struct drm_device *dev = state->dev;
const struct drm_i915_private *dev_priv = to_i915(dev);
 -  struct intel_plane *intel_plane;
 -  struct intel_plane_state *pristate = NULL;
 -  struct intel_plane_state 

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Rainer Fiebig]

Greg KH wrote:
> On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote:
>> Rainer Fiebig wrote:
>>> Maarten Lankhorst wrote:
 Op 20-11-17 om 09:51 schreef Rainer Fiebig:
> Jani Nikula wrote:
>> On Sun, 19 Nov 2017, Greg KH  wrote:
>>> On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
 Greg KH wrote:
> On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
>> Greg KH wrote:
>>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
 Greg KH wrote:
> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>> Hi!
>>
>> Hopefully the right addressee.
>>
>> Encountered two bad backports which cause screen-flicker.
>> dmesg shows:
>>
>> ...
>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO 
>> underrun
>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
>> underrun
>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
>> underrun
>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
>> underrun
>> ...
>>
>> CPU: Intel Core i3 (Clarkdale/Ironlake)
>>
>> The backports are:
>>
>> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 49de476..277a802 100644
>> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index a19ec06..3ce9ba3 100644
>>
>> After reversing them the flicker is gone, no more messages in 
>> dmesg. All
>> else OK so far.
> So which commit was the one that caused the problem?  I will be 
> glad to
> revert it.
>
> thanks,
>
> greg k-h
>
>
 I started by reverting the more complex one first ("index
 49de476..277a802100644"). But the kernel wouldn't compile then.
>>> What git commit id is that?  I don't see those ids in the 4.9-stable
>>> tree.
>>>
 So I also reverted "index a19ec06..3ce9ba3 100644". After that the
 kernel compiled just fine and the problems were gone (still are).
>>> Same here, what git commit id was this?
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>> OK, no mistake. IIRC, I took the patches (and the IDs) from the
>> changelog for patch-4.9.62. I've attached both, so you can check 
>> yourself.
>>
>> I've also applied a freshly downloaded patch-4.9.62 to a freshly
>> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
>> reverted the two patches but I'm confident that after having done so 
>> the
>> flicker will be gone. If not I'll let you know.
>>
>> As a good news: 4.14 is *not* affected. So to me it seems those two
>> patches are part of sort of a package and can not be backported 
>> alone.
>>
>> So long!
>> Rainer Fiebig
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 49de476..277a802 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -27,6 +27,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include "i915_drv.h"
>>  #include "intel_drv.h"
>>  #include "../../../platform/x86/intel_ips.h"
>> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
>> drm_i915_private *dev_priv,
>>   const struct intel_crtc *intel_crtc,
>>   int level,
>>   struct intel_crtc_state *cstate,
>> - struct intel_plane_state *pristate,
>> - struct intel_plane_state *sprstate,
>> - struct intel_plane_state *curstate,
>> + const struct intel_plane_state 
>> *pristate,
>> + const struct intel_plane_state 
>> *sprstate,
>> + const struct intel_plane_state 
>> *curstate,
>>   struct intel_wm_level *result)
>>  {
>>  uint16_t pri_latency = dev_priv->wm.pri_latency[level];
>> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
>> intel_crtc_state 

AW: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

[Türk , Jan]

Hi Fabio,

I've used git send-email and tested the patches by checkpatch.pl before without 
any problems.
So it might have been touched by the mail server, so can you send me your 
checkpatch.pl log (directly)?

Regards,
Jan Tuerk



emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___

Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

[Andreas Färber]

Am 23.11.2017 um 13:55 schrieb Jan Tuerk:
> Adding the label cpu0 allows the adjustment of cpu-parameters
> by reference in overlaying dtsi files in the same way as it
> is possible for imx6q devices.
> 
> Signed-off-by: Jan Tuerk 
> ---
>  arch/arm/boot/dts/imx6dl.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Andreas Färber 

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm: bridge: synopsys/dw-hdmi: Enable cec clock

[Hans Verkuil]

On 11/24/2017 09:04 AM, Archit Taneja wrote:
> Hi,
> 
> On 11/20/2017 06:00 PM, Hans Verkuil wrote:
>> I didn't see this merged for 4.15, is it too late to include this?
>> All other changes needed to get CEC to work on rk3288 and rk3399 are all 
>> merged.
> 
> Sorry for the late reply. I was out last week.
> 
> Dave recently sent the second pull request for 4.15, so I think it would be 
> hard to get it
> in the merge window now. We could target it for the 4.15-rcs since it is 
> preventing the
> feature from working. Is it possible to rephrase the commit message a bit so 
> that it's clear
> that we need it for CEC to work?

While it is not my patch I would propose something like this:

"Support the "cec" optional clock. The documentation already mentions "cec"
optional clock and it is used by several boards, but currently the driver
doesn't enable it, thus preventing cec from working on those boards.

And even worse: a /dev/cecX device will appear for those boards, but it
won't be functioning without configuring this clock."

I hadn't realized that last sentence until I started thinking about it,
but this patch is really needed.

Regards,

Hans

> 
> Thanks,
> Archit
> 
>>
>> Regards,
>>
>>  Hans
>>
>> On 10/26/2017 08:19 PM, Pierre-Hugues Husson wrote:
>>> The documentation already mentions "cec" optional clock, but
>>> currently the driver doesn't enable it.
>>>
>>> Changes:
>>> v3:
>>> - Drop useless braces
>>>
>>> v2:
>>> - Separate ENOENT errors from others
>>> - Propagate other errors (especially -EPROBE_DEFER)
>>>
>>> Signed-off-by: Pierre-Hugues Husson 
>>> ---
>>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 +
>>>   1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index bf14214fa464..d82b9747a979 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -138,6 +138,7 @@ struct dw_hdmi {
>>> struct device *dev;
>>> struct clk *isfr_clk;
>>> struct clk *iahb_clk;
>>> +   struct clk *cec_clk;
>>> struct dw_hdmi_i2c *i2c;
>>>   
>>> struct hdmi_data_info hdmi_data;
>>> @@ -2382,6 +2383,26 @@ __dw_hdmi_probe(struct platform_device *pdev,
>>> goto err_isfr;
>>> }
>>>   
>>> +   hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");
>>> +   if (PTR_ERR(hdmi->cec_clk) == -ENOENT) {
>>> +   hdmi->cec_clk = NULL;
>>> +   } else if (IS_ERR(hdmi->cec_clk)) {
>>> +   ret = PTR_ERR(hdmi->cec_clk);
>>> +   if (ret != -EPROBE_DEFER)
>>> +   dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n",
>>> +   ret);
>>> +
>>> +   hdmi->cec_clk = NULL;
>>> +   goto err_iahb;
>>> +   } else {
>>> +   ret = clk_prepare_enable(hdmi->cec_clk);
>>> +   if (ret) {
>>> +   dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
>>> +   ret);
>>> +   goto err_iahb;
>>> +   }
>>> +   }
>>> +
>>> /* Product and revision IDs */
>>> hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
>>>   | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
>>> @@ -2518,6 +2539,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
>>> cec_notifier_put(hdmi->cec_notifier);
>>>   
>>> clk_disable_unprepare(hdmi->iahb_clk);
>>> +   if (hdmi->cec_clk)
>>> +   clk_disable_unprepare(hdmi->cec_clk);
>>>   err_isfr:
>>> clk_disable_unprepare(hdmi->isfr_clk);
>>>   err_res:
>>> @@ -2541,6 +2564,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
>>>   
>>> clk_disable_unprepare(hdmi->iahb_clk);
>>> clk_disable_unprepare(hdmi->isfr_clk);
>>> +   if (hdmi->cec_clk)
>>> +   clk_disable_unprepare(hdmi->cec_clk);
>>>   
>>> if (hdmi->i2c)
>>> i2c_del_adapter(>i2c->adap);
>>>
>>
> 

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

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 11/23/2017 03:11 AM, Christian König wrote:

Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:

On 11/22/2017 11:54 AM, Christian König wrote:

Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:

On 11/22/2017 05:09 AM, Christian König wrote:

Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:

On 11/21/2017 08:34 AM, Christian König wrote:

Hi Boris,

attached are two patches.

The first one is a trivial fix for the infinite loop issue, it now
correctly aborts the fixup when it can't find address space for the
root window.

The second is a workaround for your board. It simply checks if there
is exactly one Processor Function to apply this fix on.

Both are based on linus current master branch. Please test if they
fix
your issue.

Yes, they do fix it but that's because the feature is disabled.

Do you know what the actual problem was (on Xen)?

I still haven't understood what you actually did with Xen.

When you used PCI pass through with those devices then you have made a
major configuration error.

When the problem happened on dom0 then the explanation is most likely
that some PCI device ended up in the configured space, but the routing
was only setup correctly on one CPU socket.

The problem is that dom0 can be (and was in my case() booted with less
than full physical memory and so the "rest" of the host memory is not
necessarily reflected in iomem. Your patch then tried to configure that
memory for MMIO and the system hang.

And so my guess is that this patch will break dom0 on a single-socket
system as well.

Oh, thanks!

I've thought about that possibility before, but wasn't able to find a
system which actually does that.

May I ask why the rest of the memory isn't reported to the OS?
That memory doesn't belong to the OS (dom0), it is owned by the 
hypervisor.



Sounds like I can't trust Linux resource management and probably need
to read the DRAM config to figure things out after all.


My question is whether what you are trying to do should ever be done for
a guest at all (any guest, not necessarily Xen).


The issue is probably that I don't know enough about Xen: What exactly 
is dom0? My understanding was that dom0 is the hypervisor, but that 
seems to be incorrect.


The issue is that under no circumstances *EVER* a virtualized guest 
should have access to the PCI devices marked as "Processor Function" on 
AMD platforms. Otherwise it is trivial to break out of the virtualization.


When dom0 is something like the system domain with all hardware access 
then the approach seems legitimate, but then the hypervisor should 
report the stolen memory to the OS using the e820 table.


When the hypervisor doesn't do that and the Linux kernel isn't aware 
that there is memory at a given location mapping PCI space there will 
obviously crash the hypervisor.


Possible solutions as far as I can see are either disabling this feature 
when we detect that we are a Xen dom0, scanning the DRAM settings to 
update Linux resource handling or fixing Xen to report stolen memory to 
the dom0 OS as reserved.


Opinions?


You are right, these functions are not exposed to a regular guest.

I think for dom0 (which is a special Xen guest, with additional 
privileges) we may be able to add a reserved e820 region for host memory 
that is not assigned to dom0. Let me try it on Monday (I am out until then).


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

Re: [PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

[Andreas Färber]

Am 23.11.2017 um 13:55 schrieb Jan Tuerk:
> emtrion is a system integrator and manufacturer of embedded systems.
> 
> Website: https://www.emtrion.de
> 
> Signed-off-by: Jan Tuerk 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Andreas Färber 

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression in TTM driver w/Linus' master

[Tobias Klausmann]

On 11/23/17 2:58 AM, Dave Airlie wrote:

On 23 November 2017 at 11:17, Laura Abbott  wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp
mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff
<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0


Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc huge
dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.



Hi Dave,

fyi only: It looks like this is not the only regression in this cycle 
with ttm, novueau seems to suffer as well [1].


Greetings,

Tobias


[1]:


[  404.918139] [ cut here ]
[  404.918147] kernel BUG at mm/shmem.c:4334!
[  404.918152] invalid opcode:  [#2] PREEMPT SMP
[  404.918157] Modules linked in: rfcomm af_packet bnep uvcvideo 
videobuf2_vmalloc videobuf2_memops rtsx_usb_ms videobuf2_v4l2 memstick 
videodev videobuf2_core btusb btrtl btbcm arc4 msr snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 
nls_cp437 hid_multitouch vfat fat iTCO_wdt iTCO_vendor_support 
intel_rapl x86_pkg_temp_thermal intel_powerclamp ath10k_pci 

[PATCH 0/5] Add basic support for emtrion emCON-MX6 modules

[Jan Tuerk]

The following patch-series adds support for emtrion's emCON-MX6 modules
with all their dependencies. The focus is based on the emtion standard
developer-kit configuration. It includes a new vendor-prefix,
an new simple-panel type, a small modification of the imx6dl.dtsi,
as well as modifications of the common imx_v6_v8_defconfig.
And finally the board devicetrees themselves.


emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___

Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.

[Jan Tuerk]

All recent emtrion modules based on i.mx6 make use of the DA0963.
Therefore enable it with the following defaults:
- CONFIG_MFD_DA9063=y
- CONFIG_REGULATOR_DA9063=y
- CONFIG_DA9063_WATCHDOG=m
- CONFIG_RTC_DRV_DA9063=m
MFD and REGULATOR are built-in to have it at Kernel boot-time.
The WATCHDOG and RTC are optional and could be loaded from userspace.

Signed-off-by: Jan Tuerk 
---
 arch/arm/configs/imx_v6_v7_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index 0d4494922561..09cd8048b0c1 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -215,8 +215,10 @@ CONFIG_THERMAL_WRITABLE_TRIPS=y
 CONFIG_CPU_THERMAL=y
 CONFIG_IMX_THERMAL=y
 CONFIG_WATCHDOG=y
+CONFIG_DA9063_WATCHDOG=m
 CONFIG_IMX2_WDT=y
 CONFIG_MFD_DA9052_I2C=y
+CONFIG_MFD_DA9063=y
 CONFIG_MFD_MC13XXX_SPI=y
 CONFIG_MFD_MC13XXX_I2C=y
 CONFIG_MFD_STMPE=y
@@ -224,6 +226,7 @@ CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_ANATOP=y
 CONFIG_REGULATOR_DA9052=y
+CONFIG_REGULATOR_DA9063=y
 CONFIG_REGULATOR_GPIO=y
 CONFIG_REGULATOR_MC13783=y
 CONFIG_REGULATOR_MC13892=y
@@ -349,6 +352,7 @@ CONFIG_RTC_DRV_PCF8563=y
 CONFIG_RTC_DRV_M41T80=y
 CONFIG_RTC_DRV_MC13XXX=y
 CONFIG_RTC_DRV_MXC=y
+CONFIG_RTC_DRV_DA9063=m
 CONFIG_RTC_DRV_SNVS=y
 CONFIG_DMADEVICES=y
 CONFIG_FSL_EDMA=y
--
2.11.0


emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___

Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/8] drm/mediatek: mt2701: switch to mfd probing.

[Matthias Brugger]

On 11/23/2017 06:48 AM, CK Hu wrote:
> Hi, Matthias:
> 
> On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
>> With the mtk-mmsys MFD device in place, we switch the probing for
>> mt2701 from device-tree to mfd.
>>
>> Signed-off-by: Matthias Brugger 
>> ---
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 +---
>>  1 file changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
>> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> index dd249cf5121e..5a263aa3ab6e 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> @@ -21,6 +21,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -392,9 +393,10 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] 
>> = {
>>  
>>  static int mtk_drm_probe(struct platform_device *pdev)
>>  {
>> +struct mmsys_dev *mmsys_private;
>>  struct device *dev = >dev;
>>  struct mtk_drm_private *private;
>> -struct device_node *node;
>> +struct device_node *node, *parent_node;
>>  struct component_match *match = NULL;
>>  int ret;
>>  int i;
>> @@ -407,12 +409,23 @@ static int mtk_drm_probe(struct platform_device *pdev)
>>  INIT_WORK(>commit.work, mtk_atomic_work);
>>  private->data = of_device_get_match_data(dev);
>>  
>> -private->config_regs = syscon_node_to_regmap(dev->of_node);
>> -if (IS_ERR(private->config_regs))
>> -return PTR_ERR(private->config_regs);
>> +/* Check if called from mfd */
>> +if (!dev->of_node) {
>> +mmsys_private = dev_get_drvdata(pdev->dev.parent);
> 
> Why do you directly access parent's driver data? You just need the
> device node of mmsys, maybe you could refer to [1].
> 
> [1]
> https://elixir.free-electrons.com/linux/latest/source/drivers/reset/reset-berlin.c#L78
> 

The difference is, that the driver you mentioned gets probed via device tree
matching, while we get invoked here through the id_table. So there is no device
node (the if actually checkes for pdev->dev.of_node to identify exactly this 
case).

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

[PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

[Jan Tuerk]

The Emerging Display Technology ETM0700G0BDH6 is exactly
the same display as the ETM0700G0DH6, exept the pixelclock
polarity. Therefore re-use the ETM0700G0DH6 modes. It is
used by default on emtrion Avari based development kits.

Signed-off-by: Jan Tuerk 
---
 .../bindings/display/panel/edt,etm0700g0bdh6.txt  |  9 +
 drivers/gpu/drm/panel/panel-simple.c  | 15 +++
 2 files changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt 
b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
new file mode 100644
index ..099e30bfa17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
@@ -0,0 +1,9 @@
+Emerging Display Technology Corp. ETM0700G0BDH6 7.0" WVGA TFT LCD panel
+
+Required properties:
+   compatible: "edt,etm0700g0bdh6"
+
+This panel is exactly the same as ETM0700G0DH6 except the pixelclock polarity.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index b7c4709f7b34..42442034b53e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -886,6 +886,18 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
 };

+static const struct panel_desc edt_etm0700g0bdh6 = {
+   .modes = _etm0700g0dh6_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
 static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
.clock = 32260,
.hdisplay = 800,
@@ -2029,6 +2041,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,etm0700g0dh6",
.data = _etm0700g0dh6,
}, {
+   .compatible = "edt,etm0700g0bdh6",
+   .data = _etm0700g0bdh6,
+   }, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
}, {
--
2.11.0


emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___

Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

[Jan Tuerk]

emtrion is a system integrator and manufacturer of embedded systems.

Website: https://www.emtrion.de

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

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0994bdd82cd3..5215c5767260 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -102,6 +102,7 @@ eetieGalax_eMPIA Technology Inc
 elan   Elan Microelectronic Corp.
 embest Shenzhen Embest Technology Co., Ltd.
 emmicroEM Microelectronic
+emtrionemtrion GmbH
 energymicroSilicon Laboratories (formerly Energy Micro AS)
 engicamEngicam S.r.l.
 epcos  EPCOS AG
--
2.11.0


emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
___

Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/8] mfd: mtk-mmsys: Add mmsys driver

[Matthias Brugger]

On 11/23/2017 10:04 AM, CK Hu wrote:

>> +static const struct of_device_id of_match_mmsys[] = {
>> +{ .compatible = "mediatek,mt2701-mmsys",
> 
> Because this driver replace the original "mediatek,mt2701-mmsys" driver,
> could you modify the binding document of "mediatek,mt2701-mmsys" [1]?
> 
> [1]
> https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> 

Well we are actually no replacing the compatible but keeping it. But yes, the
documentation should be updated.

Apart right now we have the definition twice. The other location is here:
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt

Regards,
Matthias

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

Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

[Heiko Stuebner]

Hi Daniel,

[somehow my email address seems to have gotten lost, so
only saw this by chance on the list itself now.
I've also re-added Sandy to the recipients]

Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter:
> On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
> > For personal reasons, Mark Yao will leave rockchip,
> > can not continue maintain drm/rockchip, Sandy Huang
> > will take over the drm/rockchip.
> > 
> > Cc: Sandy Huang 
> > Cc: Heiko Stuebner 
> > 
> > Signed-off-by: Mark Yao 
> 
> Since rockchip is in drm-misc that means we need a new maintainer who also
> has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be
> the new maintainer we need to fix that.
> 
> Also, Heiko, are you interested in becoming co-maintainer? With commit
> rights and all.

I always feel somewhat inadequate judging the fast-paced drm stuff, as in
the past once I got my head wrapped around something, drm always
somehow moved another mile already ;-) .

But somewhere I read that drm-pace for big changes is supposed to slow a
bit now that atomic modesetting is done in a lot of places, so we could give
co-maintainership for the Rockchip-drm a try - with Sandy wearing the
actual hat for big changes though ;-) .


Heiko


> -Daniel
> 
> > ---
> >  MAINTAINERS | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0d77f22..31bf080 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4627,7 +4627,7 @@ F:
> > Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
> >  F: Documentation/devicetree/bindings/display/renesas,du.txt
> >  
> >  DRM DRIVERS FOR ROCKCHIP
> > -M: Mark Yao 
> > +M: Sandy Huang 
> >  L: dri-devel@lists.freedesktop.org
> >  S: Maintained
> >  F: drivers/gpu/drm/rockchip/
> 
> 


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

Re: [PATCH v3] drm: bridge: synopsys/dw-hdmi: Enable cec clock

[Archit Taneja]

Hi,

On 11/20/2017 06:00 PM, Hans Verkuil wrote:

I didn't see this merged for 4.15, is it too late to include this?
All other changes needed to get CEC to work on rk3288 and rk3399 are all merged.


Sorry for the late reply. I was out last week.

Dave recently sent the second pull request for 4.15, so I think it would be 
hard to get it
in the merge window now. We could target it for the 4.15-rcs since it is 
preventing the
feature from working. Is it possible to rephrase the commit message a bit so 
that it's clear
that we need it for CEC to work?

Thanks,
Archit



Regards,

Hans

On 10/26/2017 08:19 PM, Pierre-Hugues Husson wrote:

The documentation already mentions "cec" optional clock, but
currently the driver doesn't enable it.

Changes:
v3:
- Drop useless braces

v2:
- Separate ENOENT errors from others
- Propagate other errors (especially -EPROBE_DEFER)

Signed-off-by: Pierre-Hugues Husson 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..d82b9747a979 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -138,6 +138,7 @@ struct dw_hdmi {
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
+   struct clk *cec_clk;
struct dw_hdmi_i2c *i2c;
  
  	struct hdmi_data_info hdmi_data;

@@ -2382,6 +2383,26 @@ __dw_hdmi_probe(struct platform_device *pdev,
goto err_isfr;
}
  
+	hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");

+   if (PTR_ERR(hdmi->cec_clk) == -ENOENT) {
+   hdmi->cec_clk = NULL;
+   } else if (IS_ERR(hdmi->cec_clk)) {
+   ret = PTR_ERR(hdmi->cec_clk);
+   if (ret != -EPROBE_DEFER)
+   dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n",
+   ret);
+
+   hdmi->cec_clk = NULL;
+   goto err_iahb;
+   } else {
+   ret = clk_prepare_enable(hdmi->cec_clk);
+   if (ret) {
+   dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
+   ret);
+   goto err_iahb;
+   }
+   }
+
/* Product and revision IDs */
hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
  | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
@@ -2518,6 +2539,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
cec_notifier_put(hdmi->cec_notifier);
  
  	clk_disable_unprepare(hdmi->iahb_clk);

+   if (hdmi->cec_clk)
+   clk_disable_unprepare(hdmi->cec_clk);
  err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
  err_res:
@@ -2541,6 +2564,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
  
  	clk_disable_unprepare(hdmi->iahb_clk);

clk_disable_unprepare(hdmi->isfr_clk);
+   if (hdmi->cec_clk)
+   clk_disable_unprepare(hdmi->cec_clk);
  
  	if (hdmi->i2c)

i2c_del_adapter(>i2c->adap);





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