[Bug 102204] GLideN64 very slow on oland/radeonsi

[bugzilla-daemon]

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

H4nN1baL  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |reizemb...@gmail.com
   |.org|

--- Comment #1 from H4nN1baL  ---
Created attachment 136888
  --> https://bugs.freedesktop.org/attachment.cgi?id=136888=edit
glxinfo

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

[PATCH] drm/msm/mdp5: fix semicolon.cocci warning

[Julia Lawall]

From: Fengguang Wu 

 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

v2: Fix driver name in subject line

url:
https://github.com/0day-ci/linux/commits/Laurent-Pinchart/Cargo-cult-cleanup-in-atomic-drivers/20180120-183018
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
:: branch date: 3 hours ago
:: commit date: 3 hours ago

 mdp5_kms.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -680,7 +680,7 @@ struct msm_kms *mdp5_kms_init(struct drm
} else {
dev_info(>dev,
 "no iommu, fallback to phys contig buffers for 
scanout\n");
-   aspace = NULL;;
+   aspace = NULL;
}

pm_runtime_put_sync(>dev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/msm/hdmi: fix semicolon.cocci warnings

[Julia Lawall]

From: Fengguang Wu 

 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Laurent Pinchart 
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

v2: Fix driver name in subject line

url:
https://github.com/0day-ci/linux/commits/Laurent-Pinchart/Cargo-cult-cleanup-in-atomic-drivers/20180120-183018
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
:: branch date: 3 hours ago
:: commit date: 3 hours ago

hdmi_hdcp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
@@ -769,7 +769,7 @@ static int msm_hdmi_hdcp_auth_part1_key_
if (rc) {
pr_err("%s: wait key and an ready failed\n", __func__);
return rc;
-   };
+   }

/* Read BCAPS and send to HDCP engine */
rc = msm_hdmi_hdcp_recv_bcaps(hdcp_ctrl);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: zte: fix device_node_continue.cocci warnings

[Julia Lawall]

From: Fengguang Wu 

 Device node iterators put the previous value of the index variable, so an
 explicit put causes a double put.

Generated by: scripts/coccinelle/iterators/device_node_continue.cocci

Fixes: 88e6e13dd66c ("drm: vc4: Use drm_atomic_helper_shutdown() to disable 
planes on removal")
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

v2: correct driver name in subject line

url:
https://github.com/0day-ci/linux/commits/Laurent-Pinchart/Cargo-cult-cleanup-in-atomic-drivers/20180120-183018
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
:: branch date: 3 hours ago
:: commit date: 3 hours ago

Please take the patch only if it's a positive warning. Thanks!

 zx_drm_drv.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -163,7 +163,6 @@ static int zx_drm_probe(struct platform_

for_each_available_child_of_node(parent, child) {
component_match_add(dev, , compare_of, child);
-   of_node_put(child);
}

return component_master_add_with_match(dev, _drm_master_ops, match);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #28 from Barto (mister.free...@laposte.net) ---
I made another test, by using a player like VLC and a video file ( 1080p, 60
FPS ) :

- with a video file 1080p@60 fps, GPU acceleration disabled ( XV output ) and
kernel 4.15rc8 : I can notice a slight degradation, but less visible than
firefox, it needs a trained eye in order to notice the performance issue,

- with a video file 1080p@60 fps, GPU acceleration enabled ( VDPAU ) and kernel
4.15rc8 : all is ok, perfect 60 FPS frame, 100% smooth playback

- with a video file 1080p@60 fps, GPU acceleration disabled ( XV output ) and
kernel 4.14.14: all is ok

the key here is the video resolution and framerate, things get difficult for my
CPU when we reach the resolution 1080p AND the framerate 60 fps, any weak/non
optimized algorithm in kernel ( or video driver ) will likely trigger slight
lags/frame drops,

if I use the "cheat mode" ( GPU acceleration with VDPAU ) then all is ok, no
lags when the video has a resolution 1080p/60 fps and when I use kernel
4.15rc8.

It would be interesting to create a benchmark ( a simple source code in C ) in
order to evaluate with precision ( with a number ) the performance level of
your algorithm related to drm/ttm, it will make easy the comparison between
kernel 4.14.14 ( old algorithm ) and kernel 4.15rc8

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

[PATCH] dt-bindings: display: stm32: add pixel clock mandatory property

[Philippe Cornu]

Add the DPI/RGB input pixel clock in mandatory properties
because it really offers a better preciseness for timing
computations.

Signed-off-by: Philippe Cornu 
---
Please apply "dt-bindings: display: stm32: correct clock-names
in dsi panel example" before this patch.

Changes in v3: remove the note regarding swapped clock names
  (now in a separate patch).
Changes in v2: put new clock in last position (Rob Herring)

 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
index 3eb1b48b47dd..942b7237ae87 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -29,6 +29,7 @@ Mandatory properties specific to STM32 DSI:
 - compatible: "st,stm32-dsi".
 - clock-names:
   - phy pll reference clock string name, must be "ref".
+  - DPI/RGB input pixel clock string name, must be "px_clk".
 - resets: see [5].
 - reset-names: see [5].
 
@@ -97,8 +98,9 @@ Example 2: DSI panel
#size-cells = <0>;
compatible = "st,stm32-dsi";
reg = <0x40016c00 0x800>;
-   clocks = < 1 CLK_F469_DSI>, <_hse>;
-   clock-names = "pclk", "ref";
+   clocks = < 1 CLK_F469_DSI>, <_hse>,
+< 1 CLK_LCD>;
+   clock-names = "pclk", "ref", "px_clk";
resets = < STM32F4_APB2_RESET(DSI)>;
reset-names = "apb";
 
-- 
2.15.1

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

Re: [PATCH] drm: vc4: fix semicolon.cocci warnings

[Eric Anholt]

Julia Lawall  writes:

> From: Fengguang Wu 
>
>  Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci

Looks like you've grabbed the wrong driver in the subject prefix for
these, might want to resend with those fixed to get the attention of the
various maintainers :)


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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #23 from Barto (mister.free...@laposte.net) ---
so here is the output of "cat /sys/kernel/debug/dri/0/ttm_dma_page_pool" when
no youtube video are played ( firefox is not running ), with kernel 4.15rc8 :


 pool  refills   pages freedinuse available name
   wc 1682 0 1344 5384 radeon :01:00.0
   wchuge 1130  451406 radeon :01:00.0
   cached   106272424533  5523 radeon :01:00.0
   cachedhuge61806 radeon :01:00.0

and now with firefox running, youtube video hd@60 fps in full screen mode (
output given by my bash script running in background ) :

 pool  refills   pages freedinuse available name
   wc 1682 0 2089 4639 radeon :01:00.0
   wchuge 3012 1204233 radeon :01:00.0
   cached   113562453693  5523 radeon :01:00.0
   cachedhuge72404 radeon :01:00.0


I made another expirement : using a different web-browser :

- If I use chromium 63.0.3239.132 ( a web browser based on chrome ) then there
is no bug, playback is 100% fluid, no lags, it's perfect,

- If I use opera 50.0 then there is a bug, like firefox 57, I get lags, the
only difference is that I get a vsync problem ( tearing ) 

so it seems that your commit breaks something on applications like web-browsers
if they use a precise technic for rendering streaming video ( related to memory
management ? ), 

chromium seems to be the only web-browser which is not affected by your commit

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

[Bug 98856] DIRT: Showdown broken graphics with Mesa built with -Ofast

[bugzilla-daemon]

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

--- Comment #9 from Gregor Münch  ---
Still the same with -Ofast.

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

Re: [PATCH v2] dt-bindings: display: stm32: add pixel clock mandatory property

[Philippe CORNU]

Hi Rob,

On 01/19/2018 11:43 PM, Rob Herring wrote:
> On Fri, Jan 12, 2018 at 04:30:34PM +0100, Philippe Cornu wrote:
>> Add the DPI/RGB input pixel clock in mandatory properties
>> because it really offers a better preciseness for timing
>> computations.
>> Note: Fix also the DSI panel example where "ref" & "pclk"
>> clocks were swapped.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>> Changes in v2: put new clock in last position (Rob Herring)
>>
>>   Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
>> b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
>> index 029252253ad4..942b7237ae87 100644
>> --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
>> +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
>> @@ -29,6 +29,7 @@ Mandatory properties specific to STM32 DSI:
>>   - compatible: "st,stm32-dsi".
>>   - clock-names:
>> - phy pll reference clock string name, must be "ref".
>> +  - DPI/RGB input pixel clock string name, must be "px_clk".
>>   - resets: see [5].
>>   - reset-names: see [5].
>>   
>> @@ -97,8 +98,9 @@ Example 2: DSI panel
>>  #size-cells = <0>;
>>  compatible = "st,stm32-dsi";
>>  reg = <0x40016c00 0x800>;
>> -clocks = < 1 CLK_F469_DSI>, <_hse>;
>> -clock-names = "ref", "pclk";
>> +clocks = < 1 CLK_F469_DSI>, <_hse>,
>> + < 1 CLK_LCD>;
>> +clock-names = "pclk", "ref", "px_clk";
> 
> You have the existing names reversed here.

And many thanks for your review.

Names are "reversed" as explained in the note in the commit message.

Well, maybe the note is not clear enough... So I have just sent 2 
separate patches that I hope will be better to understand.

Many thanks,
Philippe : )


> 
>>  resets = < STM32F4_APB2_RESET(DSI)>;
>>  reset-names = "apb";
>>   
>> -- 
>> 2.15.1
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v17 03/10] video: backlight: Add of_find_backlight helper in backlight.c

[Noralf Trønnes]

Den 19.01.2018 12.05, skrev Daniel Thompson:

On Fri, Jan 19, 2018 at 10:42:15AM +, Meghana Madhyastha wrote:

Add of_find_backlight, a helper function which is a generic version
of tinydrm_of_find_backlight that can be used by other drivers to avoid
repetition of code and simplify things.

Signed-off-by: Meghana Madhyastha 

Didn't I already ack this one?


Meghana,

You are supposed to pick up the r-b/acks you get and add them when you send
a new version. This way the reviewer knows which patches still need 
attention.


Here's a good overview of the acks/r-b's you've received:
https://patchwork.freedesktop.org/project/dri-devel/patches/?submitter=17149

Beware that r-b/ack to the cover letter doesn't show up in patchwork, like
Sean did on the last version putting his r-b on the whole series.
The same goes for someone putting an r-b in one of the patches stating that
it applies to whole series, patchwork thinks it only applies to this one 
patch.


Noralf.




---
changes in v17:
-rebase with drm-misc-next
-convert st7735r callers from tinydrm specific helpers
  to new generic backlight helpers
-remove select BACKLIGHT_LCD_SUPPORT
  and select BACKLIGHT_CLASS_DEVICE from
  tinydrm/Kconfig

  drivers/video/backlight/backlight.c | 43 +
  include/linux/backlight.h   | 19 
  2 files changed, 62 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 8049e7656..553bf5c48 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -580,6 +580,49 @@ struct backlight_device *of_find_backlight_by_node(struct 
device_node *node)
  EXPORT_SYMBOL(of_find_backlight_by_node);
  #endif
  
+/**

+ * of_find_backlight - Get backlight device
+ * @dev: Device
+ *
+ * This function looks for a property named 'backlight' on the DT node
+ * connected to @dev and looks up the backlight device.
+ *
+ * Call backlight_put() to drop the reference on the backlight device.
+ *
+ * Returns:
+ * A pointer to the backlight device if found.
+ * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight
+ * device is found.
+ * NULL if there's no backlight property.
+ */
+struct backlight_device *of_find_backlight(struct device *dev)
+{
+   struct backlight_device *bd = NULL;
+   struct device_node *np;
+
+   if (!dev)
+   return NULL;
+
+   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (np) {
+   bd = of_find_backlight_by_node(np);
+   of_node_put(np);
+   if (!bd)
+   return ERR_PTR(-EPROBE_DEFER);
+   /*
+* Note: gpio_backlight uses brightness as
+* power state during probe
+*/
+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;
+   }
+   }
+
+   return bd;
+}
+EXPORT_SYMBOL(of_find_backlight);
+
  static void __exit backlight_class_exit(void)
  {
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index ace825e2c..ddc9bade4 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -162,6 +162,16 @@ static inline int backlight_disable(struct 
backlight_device *bd)
return backlight_update_status(bd);
  }
  
+/**

+ * backlight_put - Drop backlight reference
+ * @bd: the backlight device to put
+ */
+static inline void backlight_put(struct backlight_device *bd)
+{
+   if (bd)
+   put_device(>dev);
+}
+
  extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
@@ -205,4 +215,13 @@ of_find_backlight_by_node(struct device_node *node)
  }
  #endif
  
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

+struct backlight_device *of_find_backlight(struct device *dev);
+#else
+static inline struct backlight_device *of_find_backlight(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
  #endif
--
2.11.0



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

[Bug 101484] [regression, bisected] Steam fails to render content, if mesa is compiled with -O2 -march=native (CPU with bmi instruction supported)

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Gregor Münch  ---
I tried again today and I was not able to reproduce this bug.
Im using gcc 7.2.1 20180116.

I close this bug now. If someone still have the same problems, please reopen!

-- 
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 1/2] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE

[Giulio Benetti]

Can't set dclk polarity on sun4i.

Handle both positive and negative dclk polarity,
according to bus_flags.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index f4284b5..6121210 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -173,6 +174,9 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon 
*tcon,
 static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
 const struct drm_display_mode *mode)
 {
+   struct drm_panel *panel = tcon->panel;
+   struct drm_connector *connector = panel->connector;
+   struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -226,8 +230,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
+   if(display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+   val |= SUN4I_TCON0_IO_POL_DCLK_PHASE(1);
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
-  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
+  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_DCLK_PHASE(3),
   val);
 
/* Map output pins to channel 0 */
-- 
2.7.4

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

[Bug 104602] Graphical artifacts in Civilization VI on RX Vega

[bugzilla-daemon]

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

--- Comment #3 from Jason Playne  ---
So I was able to get an API trace of the problem!

(I am rather happy to now be holding apitrace correctly!)

it does weigh in at 1.5GiB compressed but it does show all the badly rendered
triangles and how zooming in stops them

it is available here: https://jasonplayne.com/share/Civ6.trace.bz2

I hope this is helpful

-- 
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 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #21 from Christian König (christian.koe...@amd.com) ---
(In reply to Barto from comment #18)
>  pool  refills   pages freedinuse available name
>wc  801 0 2834  370 radeon
> :01:00.0
>wchuge 1079  430763 radeon
> :01:00.0
>cached10663 42097  5523 radeon
> :01:00.0
>cachedhuge61905 radeon
> :01:00.0
> 
> I will try to compile kernel 4.15rc8 with CONFIG_SWIOTLB disabled

Can you also give me those numbers before, while and after you played a video
on youtube? Especially what are the number of refills and pages freed before,
while and after you play the video?

It starts to look more like that this isn't an issue in the kernel, but rather
the userspace stack or application is constantly allocating and freeing memory.

Best approach would be to gather the "while you play the video" numbers from a
separate system over ssh, because when you put the firefox window into the
background it can change the results.

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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #19 from Barto (mister.free...@laposte.net) ---
(In reply to Christian König from comment #16)

> Huge pages are always disabled on your system. It would be interesting to
> see what happens when you try to enable them, not disable them.

I tried with kernel parameter "transparent_hugepage=always", the bug is still
here, and here is the output of ""cat /proc/meminfo", it seems that huge pages
are still not used by my system despite the kernel parameter :


MemTotal:8171844 kB
MemFree: 6052052 kB
MemAvailable:6938968 kB
Buffers:  179304 kB
Cached:   854248 kB
SwapCached:0 kB
Active:  1076432 kB
Inactive: 803524 kB
Active(anon): 676640 kB
Inactive(anon):   122984 kB
Active(file): 399792 kB
Inactive(file):   680540 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:   5242876 kB
SwapFree:5242876 kB
Dirty:  3016 kB
Writeback: 0 kB
AnonPages:828348 kB
Mapped:   447036 kB
Shmem:124128 kB
Slab:  82000 kB
SReclaimable:  53952 kB
SUnreclaim:28048 kB
KernelStack:6368 kB
PageTables:32316 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 9328796 kB
Committed_AS:2841448 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages:106496 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  205696 kB
DirectMap2M: 8181760 kB

but what means the line "AnonHugePages" ?

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

[PATCH v4 4/8] drm: Add DRM client cap for aspect-ratio

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

To enable aspect-ratio support in DRM, blindly exposing the
aspect-ratio information along with mode, can break things
in existing user-spaces which have no intention or support
to use this aspect-ratio information.

To avoid this, a new drm client cap is required to enable a
user-space to advertise if it supports modes with aspect-ratio.
Based on this cap value, the kernel will take a call on exposing
the aspect-ratio information in modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase

v4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio.
Also, tweaked the comment lines in the code for better understanding
and clarity, as recommended by Shashank Sharma.

Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_ioctl.c | 5 +
 include/drm/drm_file.h  | 8 
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index b1e96fb..cbcf2a2 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..c025301 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,14 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True, if client can handle picture aspect ratios, and has requested
+* to pass this information along with the mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..82907d4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will provide aspect ratio information in modes. 
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

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

Re: [PATCH v17 06/10] drm/tinydrm: Call devres version of of_find_backlight

[Noralf Trønnes]

Den 19.01.2018 11.46, skrev Meghana Madhyastha:

Call devm_of_find_backlight (the devres version) instead of
of_find_backlight.

Signed-off-by: Meghana Madhyastha 
---


I already put my r-b on this one in the previous version, but now also:

Tested-by: Noralf Trønnes 

I did also test with the backlight subsystem disabled.


changes in v17:
-convert st7735r callers from tinydrm specific helpers
  to new generic backlight helpers

  drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
  drivers/gpu/drm/tinydrm/st7735r.c  | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index a8aafce36..d8ed6e6f8 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -196,7 +196,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))
return PTR_ERR(mipi->regulator);
  
-	mipi->backlight = of_find_backlight(dev);

+   mipi->backlight = devm_of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
  
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c b/drivers/gpu/drm/tinydrm/st7735r.c

index 2e6b7b8ec..67d197ecf 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -164,7 +164,7 @@ static int st7735r_probe(struct spi_device *spi)
return PTR_ERR(dc);
}
  
-	mipi->backlight = of_find_backlight(dev);

+   mipi->backlight = devm_of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
  


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

[PATCH] dt-bindings: display: stm32: correct clock-names in dsi panel example

[Philippe Cornu]

In the dsi panel example, clock names in the "clock-names"
field have been swapped:
* "pclk" (peripheral clock) is < 1 CLK_F469_DSI> on stm32f4
* "ref" (dsi phy pll ref clock) is <_hse> on stm32f4

Signed-off-by: Philippe Cornu 
---
 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt 
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
index 029252253ad4..3eb1b48b47dd 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -98,7 +98,7 @@ Example 2: DSI panel
compatible = "st,stm32-dsi";
reg = <0x40016c00 0x800>;
clocks = < 1 CLK_F469_DSI>, <_hse>;
-   clock-names = "ref", "pclk";
+   clock-names = "pclk", "ref";
resets = < STM32F4_APB2_RESET(DSI)>;
reset-names = "apb";
 
-- 
2.15.1

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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #25 from Barto (mister.free...@laposte.net) ---
Someone has made a suggestion to me : go to "about:support" in firefox for
ckecking some options, I can read this :

HW_COMPOSITING  blocked by default: Acceleration blocked by platform

OPENGL_COMPOSITING  unavailable by default: Hardware compositing is
disabled

WEBRENDER   opt-in by default: WebRender is an opt-in feature
unavailable by runtime: Build doesn't include WebRender

and this guy told me to check if the property
"layers.acceleration.force-enabled" is set to true in firefox ( in
"about:config" section ),

I checked and it was set to false by default, so I set it to true and I
restarted firefox,

and now there is no lag in firefox for youtube video 1080p@60 fps with kernel
4.15rc8

but this advice seems to be a "cheat mode/workaround", it doesn't explain why
your commit triggers this problem with firefox 57 when
"layers.acceleration.force-enabled" option is disabled in firefox ( which is
the default value ),

with kernel 4.14.14 ( and when I revert your commit ) youtube video plays
without lags, even if "layers.acceleration.force-enabled" is disabled

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

Re: [RFC 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

[Martin Peres]

On 16/01/18 00:06, Lyude Paul wrote:
> This adds support for enabling automatic clockgating on nvidia GPUs for
> Kepler1, referred to as "CG" throughout the driver. This is one of two
> powersaving levels that Kepler1 supports.

Thanks a lot for all this work! It was long overdue and it is nice to
see the project finally getting to an end, after passing into so many hands!

> 
> This introduces two therm helpers for controlling basic clockgating:
>   nvkm_therm_clkgate_enable() - enables clockgating through
>   CG_CTRL, done after initializing the GPU fully
>   nvkm_therm_clkgate_fini() - prepares clockgating for suspend or
>   driver unload
> 
> As well, we add the nouveau kernel config parameter NvPmEnableGating,
> which can be set to the highest level of clockgating (in this case, we
> only have CG) the user desires to enable. Since we've only had limited
> testing on this thus far, we disable this by default.

I am not sure I understand the purpose of this level here. As far as I
understand, you only have per-engine control whether you want to enable
CG or not. What you call BLCG and SLCG levels just mean "don't use the
boot values, but rather use our values (taken from nvidia)".

Now, here comes the nasty part: NVIDIA only ever validated the boot
values (I guess they are extremely safe ones), and the optimised values
(the ones coming from your patch 2, 3, and 4 along with the level 3.

I think introducing a single parameter that controls both CG, PG, and
automatic reclocking would be safer. For CG and PG, it would be a
all-or-nothing (either boot values, or everything like nvidia).

> 
> A lot of this code was originally going to be based off of fermi;
> however it turns out that while Fermi's the first line of GPUs that
> introduced this kind of power saving, Fermi requires more fine tuned
> control of the CG_CTRL registers from the driver while reclocking that
> we don't entirely understand yet.
> 
> For the simple parts we will be sharing with Fermi for certain however,
> we at least add those into a new subdev/therm/gf100.h header.
> 
> Signed-off-by: Lyude Paul 
> ---
>  .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|  10 ++
>  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  17 +--
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |   1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  72 +--
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h  |  35 ++
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c  |   8 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c  | 135 
> +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h  |  56 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h   |  15 ++-
>  9 files changed, 328 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h
> 
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index b1ac47eb786e..a9204c09975b 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -46,6 +46,11 @@ enum nvkm_therm_attr_type {
>   NVKM_THERM_ATTR_THRS_SHUTDOWN_HYST = 17,
>  };
>  
> +enum nvkm_therm_clkgate_level {
> + NVKM_THERM_CLKGATE_NONE = 0,
> + NVKM_THERM_CLKGATE_CG, /* basic clockgating */
> +};
> +
>  struct nvkm_therm {
>   const struct nvkm_therm_func *func;
>   struct nvkm_subdev subdev;
> @@ -85,17 +90,22 @@ struct nvkm_therm {
>  
>   int (*attr_get)(struct nvkm_therm *, enum nvkm_therm_attr_type);
>   int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
> +
> + enum nvkm_therm_clkgate_level clkgate_level;
>  };
>  
>  int nvkm_therm_temp_get(struct nvkm_therm *);
>  int nvkm_therm_fan_sense(struct nvkm_therm *);
>  int nvkm_therm_cstate(struct nvkm_therm *, int, int);
> +void nvkm_therm_clkgate_enable(struct nvkm_therm *);
> +void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
>  
>  int nv40_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int nv50_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int g84_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> +int gk104_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gm200_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index 

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #17 from Christian König (christian.koe...@amd.com) ---
What is the content of /sys/kernel/debug/dri/0/ttm_dma_page_pool while you are
playing a youtube video?

And can you try to compile the kernel with CONFIG_SWIOTLB disabled?

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

Re: [PATCH v2] drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()

[Eric Anholt]

Boris Brezillon  writes:

> When saving BOs in the hang state we skip one entry of the
> kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL
> pointer dereference when, later in this function, we iterate over all
> BOs to check their ->madv state.
>
> Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and 
> rendering jobs")
> Cc: 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Get rid of prev_idx an replace it by k which is indepently incremented
>   every time a new object is added to kernel_state->bo[].
> - Add a WARN_ON_ONCE() when final value of k is inconsistent

Reviewed and pushed to drm-misc-fixes back on Thursday.  Thanks!


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

[Bug 104655] AMD R9 Fury + BenQ XL2546: Setting 240 Hz results in screen distortion

[bugzilla-daemon]

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

--- Comment #6 from omin...@autistici.org ---
Tested this with my on-board Intel graphics capabilities.

The issue does not occur. It seems to be isolated to AMD graphics.

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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #24 from Barto (mister.free...@laposte.net) ---
I forgot the third case, here is the output after a youtube video has been
played on firefox 57, I closed firefox and now here is the output :

# cat /sys/kernel/debug/dri/0/ttm_dma_page_pool
 pool  refills   pages freedinuse available name
   wc 1682 0 4016 2712 radeon :01:00.0
   wchuge 3403 1360804 radeon :01:00.0
   cached   131859526872  5604 radeon :01:00.0
   cachedhuge93204 radeon :01:00.0

the numbers seems stable

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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)

[bugzilla-daemon]

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

letha...@gmail.com changed:

   What|Removed |Added

Summary|No HDMI HBR audio on|No HDMI HBR audio on
   |Polaris (no TrueHD, no  |Polaris (no TrueHD, no
   |Atmos, no Neo:X, no HD  |Atmos, no Neo:X, no HD
   |Master audio) and static|Master audio)
   |noise in sound when LPCM|

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

Re: [PATCH v2 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Sergei Shtylyov]

Hello!

On 1/13/2018 2:14 AM, Laurent Pinchart wrote:

   Here's my (superficial) comments...


The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.

Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Select OF_FLATTREE
- Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
- Pass void begin and end pointers to rcar_du_of_get_overlay()
- Use of_get_parent() instead of accessing the parent pointer directly
- Find the LVDS endpoints nodes based on the LVDS node instead of the
   root of the overlay
- Update to the -lvds compatible string format
---
  drivers/gpu/drm/rcar-du/Kconfig |   2 +
  drivers/gpu/drm/rcar-du/Makefile|   3 +-
  drivers/gpu/drm/rcar-du/rcar_du_of.c| 451 
  drivers/gpu/drm/rcar-du/rcar_du_of.h|  16 +
  drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts |  82 +
  5 files changed, 553 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 5d0b4b7119af..3f83352a7313 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+   select OF_FLATTREE
+   select OF_OVERLAY
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
  
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile

index 0cf5c11030e8..8ed569a0f462 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -5,10 +5,11 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_group.o \
 rcar_du_kms.o \
 rcar_du_lvdscon.o \
+rcar_du_of.o \
 rcar_du_plane.o
  
  rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)	+= rcar_du_lvdsenc.o

-
+rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of_lvds.dtb.o
  rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)+= rcar_du_vsp.o
  
  obj-$(CONFIG_DRM_RCAR_DU)		+= rcar-du-drm.o

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..2bf91201fc93
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,451 @@

[...]

+static struct device_node __init *
+static int __init rcar_du_of_add_property(struct device_node *np,
+ const char *name, const void *value,
+ size_t length)
+{
+   struct property *prop;
+
+   prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+   if (!prop)
+   return -ENOMEM;
+
+   prop->name = kstrdup(name, GFP_KERNEL);
+   prop->value = kmemdup(value, length, GFP_KERNEL);
+   prop->length = length;
+
+   if (!prop->name || !prop->value) {
+   kfree(prop->name);
+   kfree(prop->value);
+   kfree(prop);
+   return -ENOMEM;
+   }
+
+   of_property_set_flag(prop, OF_DYNAMIC);
+
+   prop->next = np->properties;
+   np->properties = prop;
+
+   return 0;
+}
+
+/* Free properties allocated dynamically by rcar_du_of_add_property(). */
+static void __init rcar_du_of_free_properties(struct device_node *np)
+{
+   while (np->properties) {
+   struct property *prop = np->properties;
+
+   np->properties = prop->next;
+
+   if (OF_IS_DYNAMIC(prop)) {
+   kfree(prop->name);
+   kfree(prop->value);
+   kfree(prop);


   Perhaps these kfree() worth factoring out?


+   }
+   }
+}
+

[...]

+extern char __dtb_rcar_du_of_lvds_begin[];
+extern char __dtb_rcar_du_of_lvds_end[];
+
+static void __init rcar_du_of_lvds_patch_one(struct device_node *du,
+unsigned int port_id,
+const struct resource *res,
+const __be32 *reg,
+const struct of_phandle_args 
*clkspec,
+struct device_node *local,
+struct device_node *remote)
+{

[...]

+   /* Apply the overlay, this will resolve phandles. */
+   ovcs_id = 0;
+   ret = of_overlay_apply(overlay.np, 

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

[bugzilla-daemon]

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

--- Comment #26 from letha...@gmail.com ---
The UVD polaris firmware update from 18 of january 2018 solves my problem:
the LPCM & DTS sound is normal now.

Still missing are high bitrate codecs (dts-hd etc).

The RX cards can finally serve as HTPC cards!

-- 
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 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #18 from Barto (mister.free...@laposte.net) ---
here is the output of "cat /sys/kernel/debug/dri/0/ttm_dma_page_pool" with
kernel 4.15rc8 when I play a youtube video hd@60 fps in full screen mode :


 pool  refills   pages freedinuse available name
   wc  801 0 2834  370 radeon :01:00.0
   wchuge 1079  430763 radeon :01:00.0
   cached10663 42097  5523 radeon :01:00.0
   cachedhuge61905 radeon :01:00.0

I will try to compile kernel 4.15rc8 with CONFIG_SWIOTLB disabled

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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #20 from Christian König (christian.koe...@amd.com) ---
(In reply to Barto from comment #19)
> AnonHugePages:106496 kB
> ShmemHugePages:0 kB
...
> but what means the line "AnonHugePages" ?

Ah crap you are right, AnonHugePages are the anonymous huge pages. I was
looking at the wrong value.

So huge page support is indeed enabled on you CPU, and it doesn't seem to
matter if we enable or disable it.

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

Re: [PATCH v17 03/10] video: backlight: Add of_find_backlight helper in backlight.c

[Noralf Trønnes]

Den 19.01.2018 11.42, skrev Meghana Madhyastha:

Add of_find_backlight, a helper function which is a generic version
of tinydrm_of_find_backlight that can be used by other drivers to avoid
repetition of code and simplify things.

Signed-off-by: Meghana Madhyastha 
---


Reviewed-by: Noralf Trønnes 


changes in v17:
-rebase with drm-misc-next
-convert st7735r callers from tinydrm specific helpers
  to new generic backlight helpers
-remove select BACKLIGHT_LCD_SUPPORT
  and select BACKLIGHT_CLASS_DEVICE from
  tinydrm/Kconfig

  drivers/video/backlight/backlight.c | 43 +
  include/linux/backlight.h   | 19 
  2 files changed, 62 insertions(+)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 8049e7656..553bf5c48 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -580,6 +580,49 @@ struct backlight_device *of_find_backlight_by_node(struct 
device_node *node)
  EXPORT_SYMBOL(of_find_backlight_by_node);
  #endif
  
+/**

+ * of_find_backlight - Get backlight device
+ * @dev: Device
+ *
+ * This function looks for a property named 'backlight' on the DT node
+ * connected to @dev and looks up the backlight device.
+ *
+ * Call backlight_put() to drop the reference on the backlight device.
+ *
+ * Returns:
+ * A pointer to the backlight device if found.
+ * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight
+ * device is found.
+ * NULL if there's no backlight property.
+ */
+struct backlight_device *of_find_backlight(struct device *dev)
+{
+   struct backlight_device *bd = NULL;
+   struct device_node *np;
+
+   if (!dev)
+   return NULL;
+
+   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (np) {
+   bd = of_find_backlight_by_node(np);
+   of_node_put(np);
+   if (!bd)
+   return ERR_PTR(-EPROBE_DEFER);
+   /*
+* Note: gpio_backlight uses brightness as
+* power state during probe
+*/
+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;
+   }
+   }
+
+   return bd;
+}
+EXPORT_SYMBOL(of_find_backlight);
+
  static void __exit backlight_class_exit(void)
  {
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index ace825e2c..ddc9bade4 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -162,6 +162,16 @@ static inline int backlight_disable(struct 
backlight_device *bd)
return backlight_update_status(bd);
  }
  
+/**

+ * backlight_put - Drop backlight reference
+ * @bd: the backlight device to put
+ */
+static inline void backlight_put(struct backlight_device *bd)
+{
+   if (bd)
+   put_device(>dev);
+}
+
  extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
@@ -205,4 +215,13 @@ of_find_backlight_by_node(struct device_node *node)
  }
  #endif
  
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

+struct backlight_device *of_find_backlight(struct device *dev);
+#else
+static inline struct backlight_device *of_find_backlight(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
  #endif


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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #16 from Christian König (christian.koe...@amd.com) ---
(In reply to Barto from comment #15)
> Hello Christian,
> 
> I tried to disable "transparent huge page" with the kernel parameter
> "transparent_hugepage=never", but the bug is still here

Sounds like you misunderstood me:
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB

Huge pages are always disabled on your system. It would be interesting to see
what happens when you try to enable them, not disable them.

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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #26 from Christian König (christian.koe...@amd.com) ---
(In reply to Barto from comment #25)
> but this advice seems to be a "cheat mode/workaround", it doesn't explain
> why your commit triggers this problem with firefox 57 when
> "layers.acceleration.force-enabled" option is disabled in firefox ( which is
> the default value ),

Well, actually it explains perfectly what is going wrong here :)

My huge page patches makes memory accesses faster for the price of making
allocating memory more costly. E.g. by using 2M pages instead of 4K you improve
some hardware path by the factor of 512.

Now what I see when I look at your numbers is that user space allocated and
freed (13608−4514)*2M = 18.1GB of memory while playing youtube videos!.

This means that either the application or the driver stack is doing something
very very stupid. Instead of using buffers round robin they are allocating
them, using them once and then freeing them again.

As a band aid I will try to fix our algorithm when pages are freed again, but
in general the driver stack or application should be fixed to not do that.

Probably best if you open up a bug report on http://bugs.freedesktop.org/ so
that somebody can investigate what userspace is doing here.

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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #22 from Barto (mister.free...@laposte.net) ---
(In reply to Christian König from comment #21)

> Best approach would be to gather the "while you play the video" numbers from
> a separate system over ssh, because when you put the firefox window into the
> background it can change the results.

I have already use a special technic in order to be able to get the infos while
playing a video, I use a bash script with an "infinite while loop", which can
allow me to put in fullscreen mode the video while the script will generate the
log files :

#!/bin/bash

i="0"
j="0"

while [ $i -lt 4 ]
do
sleep 1
echo $j
cat /proc/meminfo > log_$j.txt
j=$[$j+1]
done

I tried to rebuild kernel 4.15rc8 with the option "CONFIG_SWIOTLB" disabled,
the bug is still here

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

Re: [PATCH v17 09/10] drm/panel: Use of_find_backlight helper

[Noralf Trønnes]

Den 19.01.2018 11.47, skrev Meghana Madhyastha:

Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.

Signed-off-by: Meghana Madhyastha 
---
changes in v17:
-remove put_device() to avoid double put
  as we are using the devm version

  drivers/gpu/drm/panel/panel-innolux-p079zca.c   | 23 ---
  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 25 -
  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 25 -
  3 files changed, 12 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 4c1b29eec..059f4af1a 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -230,37 +230,22 @@ static int innolux_panel_add(struct innolux_panel 
*innolux)
innolux->enable_gpio = NULL;
}
  
-	np = of_parse_phandle(dev->of_node, "backlight", 0);

-   if (np) {
-   innolux->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   innolux->backlight = devm_of_find_backlight(np);


There are several errors in these two last patches, like this one:

/home/pi/dim-build/workdirs/drm-misc/linux-linus/drivers/gpu/drm/panel/panel-innolux-p079zca.c: 
In function 'innolux_panel_add':
/home/pi/dim-build/workdirs/drm-misc/linux-linus/drivers/gpu/drm/panel/panel-innolux-p079zca.c:233:46: 
warning: passing argument 1 of 'devm_of_find_backlight' from 
incompatible pointer type

  innolux->backlight = devm_of_find_backlight(np);

Instead of tracking down the build dependencies to get this driver built,
you can instead use these defconfigs and all DRM drivers should be built:
https://cgit.freedesktop.org/drm/drm-tip/tree/?h=rerere-cache

But not all drivers are built on every architecture.

Noralf.

  
-		if (!innolux->backlight)

-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(innolux->backlight))
+   return PTR_ERR(innolux->backlight);
  
  	drm_panel_init(>base);

innolux->base.funcs = _panel_funcs;
innolux->base.dev = >link->dev;
  
-	err = drm_panel_add(>base);

-   if (err < 0)
-   goto put_backlight;
-
-   return 0;
-
-put_backlight:
-   put_device(>backlight->dev);
-
-   return err;
+   return drm_panel_add(>base);
  }
  
  static void innolux_panel_del(struct innolux_panel *innolux)

  {
if (innolux->base.dev)
drm_panel_remove(>base);
-
-   put_device(>backlight->dev);
  }
  
  static int innolux_panel_probe(struct mipi_dsi_device *dsi)

diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 072c0fc79..85279d224 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -327,30 +327,16 @@ static int sharp_panel_add(struct sharp_panel *sharp)
if (IS_ERR(sharp->supply))
return PTR_ERR(sharp->supply);
  
-	np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);

-   if (np) {
-   sharp->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   sharp->backlight = devm_of_find_backlight(np);
  
-		if (!sharp->backlight)

-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(sharp->backlight))
+   return PTR_ERR(sharp->backlight);
  
  	drm_panel_init(>base);

sharp->base.funcs = _panel_funcs;
sharp->base.dev = >link1->dev;
  
-	err = drm_panel_add(>base);

-   if (err < 0)
-   goto put_backlight;
-
-   return 0;
-
-put_backlight:
-   if (sharp->backlight)
-   put_device(>backlight->dev);
-
-   return err;
+   return drm_panel_add(>base);
  }
  
  static void sharp_panel_del(struct sharp_panel *sharp)

@@ -358,9 +344,6 @@ static void sharp_panel_del(struct sharp_panel *sharp)
if (sharp->base.dev)
drm_panel_remove(>base);
  
-	if (sharp->backlight)

-   put_device(>backlight->dev);
-
if (sharp->link2)
put_device(>link2->dev);
  }
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 8a5137963..b634ec887 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -271,39 +271,22 @@ static int sharp_nt_panel_add(struct sharp_nt_panel 
*sharp_nt)
gpiod_set_value(sharp_nt->reset_gpio, 0);
}
  
-	np = of_parse_phandle(dev->of_node, "backlight", 0);

-   if (np) {
-   sharp_nt->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   sharp_nt->backlight = devm_of_find_backlight(np);
  
-		if (!sharp_nt->backlight)

-   

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #27 from Barto (mister.free...@laposte.net) ---
(In reply to Christian König from comment #26)

> Now what I see when I look at your numbers is that user space allocated and
> freed (13608−4514)*2M = 18.1GB of memory while playing youtube videos!.
> 
> This means that either the application or the driver stack is doing
> something very very stupid. Instead of using buffers round robin they are
> allocating them, using them once and then freeing them again.
> 

I made a new test, in order to be sure that there is no mistake ( I disabled
the option ""layers.acceleration.force-enabled" in firefox,

before playing the video :

 pool  refills   pages freedinuse available name
   wc  697 0 1344 1444 radeon :01:00.0
   wchuge   269806 radeon :01:00.0
   cached 4166 15978  6806 radeon :01:00.0
   cachedhuge3 903 radeon :01:00.0
[root@ultima-dbr cesar]# 


while reading the video ( position 32 seconds ) :

 pool  refills   pages freedinuse available name
   wc  783 0 2089 1043 radeon :01:00.0
   wchuge  989  394736 radeon :01:00.0
   cached 8573 33737  5523 radeon :01:00.0
   cachedhuge51406 radeon :01:00.0

after reading 38 seconds of the video ( I click to "pause" in youtube at 38
seconds ) :

 pool  refills   pages freedinuse available name
   wc  783 0 2285  847 radeon :01:00.0
   wchuge 1153  460723 radeon :01:00.0
   cached 8675 34143  5525 radeon :01:00.0
   cachedhuge51406 radeon :01:00.0

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

Re: [RFC] Per file OOM badness

[Eric Anholt]

Michel Dänzer  writes:

> On 2018-01-19 11:02 AM, Michel Dänzer wrote:
>> On 2018-01-19 10:58 AM, Christian König wrote:
>>> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
 On 2018-01-19 09:39 AM, Christian König wrote:
> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>> OK, in that case I would propose a different approach. We already
>> have rss_stat. So why do not we simply add a new counter there
>> MM_KERNELPAGES and consider those in oom_badness? The rule would be
>> that such a memory is bound to the process life time. I guess we will
>> find more users for this later.
> I already tried that and the problem with that approach is that some
> buffers are not created by the application which actually uses them.
>
> For example X/Wayland is creating and handing out render buffers to
> application which want to use OpenGL.
>
> So the result is when you always account the application who created the
> buffer the OOM killer will certainly reap X/Wayland first. And that is
> exactly what we want to avoid here.
 FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland
 anymore. With DRI3 and Wayland, buffers are allocated by the clients and
 then shared with the X / Wayland server.
>>>
>>> Good point, when I initially looked at that problem DRI3 wasn't widely
>>> used yet.
>>>
 Also, in all cases, the amount of memory allocated for buffers shared
 between DRI/Wayland clients and the server should be relatively small
 compared to the amount of memory allocated for buffers used only locally
 in the client, particularly for clients which create significant memory
 pressure.
>>>
>>> That is unfortunately only partially true. When you have a single
>>> runaway application which tries to allocate everything it would indeed
>>> work as you described.
>>>
>>> But when I tested this a few years ago with X based desktop the
>>> applications which actually used most of the memory where Firefox and
>>> Thunderbird. Unfortunately they never got accounted for that.
>>>
>>> Now, on my current Wayland based desktop it actually doesn't look much
>>> better. Taking a look at radeon_gem_info/amdgpu_gem_info the majority of
>>> all memory was allocated either by gnome-shell or Xwayland.
>> 
>> My guess would be this is due to pixmaps, which allow X clients to cause
>> the X server to allocate essentially unlimited amounts of memory. It's a
>> separate issue, which would require a different solution than what we're
>> discussing in this thread. Maybe something that would allow the X server
>> to tell the kernel that some of the memory it allocates is for the
>> client process.
>
> Of course, such a mechanism could probably be abused to incorrectly
> blame other processes for one's own memory consumption...
>
>
> I'm not sure if the pixmap issue can be solved for the OOM killer. It's
> an X design issue which is fixed with Wayland. So it's probably better
> to ignore it for this discussion.
>
> Also, I really think the issue with DRM buffers being shared between
> processes isn't significant for the OOM killer compared to DRM buffers
> only used in the same process that allocates them. So I suggest focusing
> on the latter.

Agreed.  The 95% case is non-shared buffers, so just don't account for
them and we'll have a solution good enough that we probably never need
to handle the shared case.  On the DRM side, removing buffers from the
accounting once they get shared would be easy.


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

[Bug 198511] lags in youtube videos 1080p 60fps with radeon hd4650 and kernel 4.15rc8

[bugzilla-daemon]

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

--- Comment #15 from Barto (mister.free...@laposte.net) ---
Hello Christian,

I tried to disable "transparent huge page" with the kernel parameter
"transparent_hugepage=never", but the bug is still here

here is the output of "cat /proc/meminfo" when the kernel parameter
"transparent_hugepage=never" is used and when I see hd youtube video@60 fps in
fullscreen mode :

MemTotal:8171844 kB
MemFree: 6201872 kB
MemAvailable:7196352 kB
Buffers:  175860 kB
Cached:   828424 kB
SwapCached:0 kB
Active:   962712 kB
Inactive: 770948 kB
Active(anon): 572560 kB
Inactive(anon):   117736 kB
Active(file): 390152 kB
Inactive(file):   653212 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:   5242876 kB
SwapFree:5242876 kB
Dirty:  6592 kB
Writeback: 0 kB
AnonPages:729364 kB
Mapped:   446376 kB
Shmem:118880 kB
Slab:  80408 kB
SReclaimable:  52736 kB
SUnreclaim:27672 kB
KernelStack:5956 kB
PageTables:31036 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 9328796 kB
Committed_AS:2722200 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  201600 kB
DirectMap2M: 8185856 kB

the same experience but without the kernel parameter
"transparent_hugepage=never", the bug is still here :

MemTotal:8171844 kB
MemFree: 6068060 kB
MemAvailable:6948308 kB
Buffers:  181860 kB
Cached:   851652 kB
SwapCached:0 kB
Active:  1107604 kB
Inactive: 752108 kB
Active(anon): 663292 kB
Inactive(anon):   123784 kB
Active(file): 444312 kB
Inactive(file):   628324 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:   5242876 kB
SwapFree:5242876 kB
Dirty: 11148 kB
Writeback: 0 kB
AnonPages:814052 kB
Mapped:   457708 kB
Shmem:124920 kB
Slab:  84420 kB
SReclaimable:  56168 kB
SUnreclaim:28252 kB
KernelStack:5936 kB
PageTables:31100 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 9328796 kB
Committed_AS:2813580 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages:161792 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:  199552 kB
DirectMap2M: 8187904 kB

what it's sure is that the commit 648bc357471 "drm/ttm: add transparent huge
page support for DMA allocations v2" triggers the bug with my PC configuration,
when I want to see a youtube video 1080p@60fps in fullscreen mode, there is a
performance issue, the playback is not 100% fluid ( I can notice little lags in
travelling-type images )

some additionnal informations :

- I use plasma 5 ( kde ) as window manager, the vsync option is set to
"automatic" in plasma 5 options, "openGL 2.0 acceleration" option is used for
the compositor for plasma 5,

- mesa version : 17.3.2-2
$ glxinfo | grep "OpenGL version"   
OpenGL version string: 3.0 Mesa 17.3.2  

- the contain of /etc/X11/xorg.conf.d/20-radeon.conf :

Section "Device"
Identifier "Radeon"
Driver "modesetting"
Option "TearFree" "off"
Option "DRI" "3"
Option "AccelMethod" "glamor"
EndSection

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

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

[Gustavo A. R. Silva]

Quoting Felix Kuehling :


Looks good. This change is Reviewed-by: Felix Kuehling




Thanks Felix.
--
Gustavo





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

[PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Giulio Benetti]

On previous handling, if specified DRM_MODE_FLAG_N*SYNC,
it was ignored,
because only PHSYNC and PVSYNC were taken into account.
DRM_MODE_FLAG_P*SYNC and DRM_MODE_FLAG_N*SYNC are not exclusive.

If flags contains PVSYNC, it doesn't mean it is NVSYNC.
And it's true also the contrary.
Also, as I've checked with scope on A20,
if (flags & PVSYNC) then SUN4I_TCON0_IO_POL_VSYNC_POSITIVE
must be set, as name suggests.
It seems all display io polarities starts inverted if 0.

Signed-off-by: Giulio Benetti 

PVSYNC and PHSYNC only

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 6121210..e873a37 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -224,10 +224,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
 SUN4I_TCON0_BASIC3_H_SYNC(hsync));
 
/* Setup the polarity of the various signals */
-   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
 
-   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
if(display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
-- 
2.7.4

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