[PATCH v2] drm/dp: DPCD register defines for link status within ESI field

[Dhinakaran Pandiyan]

Link status is available in the ESI field on devices with DPCD r1.2 or
higher. DP spec also says "An MST upstream device shall use this field
instead of the Link/Sink Device Status field registers, starting from DPCD
Address 00200h."

v2: Prefixed DP_ (Jani)
Rewrote commment to stay within 80 cols.
Cc: Jani Nikula 
Reviewed-by: Jani Nikula 
Signed-off-by: Dhinakaran Pandiyan 
---
 include/drm/drm_dp_helper.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 2c412a15cfa1..11c39f15f1b3 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -738,6 +738,11 @@
 #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
 # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
 
+#define DP_LANE0_1_STATUS_ESI  0x200c /* status same as 0x202 
*/
+#define DP_LANE2_3_STATUS_ESI  0x200d /* status same as 0x203 
*/
+#define DP_LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* status same as 0x204 
*/
+#define DP_SINK_STATUS_ESI 0x200f /* status same as 0x205 
*/
+
 #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
 # define DP_GTC_CAP(1 << 0)  /* DP 1.3 */
 # define DP_SST_SPLIT_SDP_CAP  (1 << 1)  /* DP 1.4 */
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/dp: DPCD register defines for link

[Pandiyan, Dhinakaran]

On Thu, 2017-09-14 at 09:00 +0300, Jani Nikula wrote:
> On Wed, 13 Sep 2017, Dhinakaran Pandiyan  
> wrote:
> > Link status is available in the ESI field on devices with DPCD r1.2 or
> > higher. DP spec also says "An MST upstream device shall use this field
> > instead of the Link/Sink Device Status field registers, starting from DPCD
> > Address 00200h."
> >
> > Cc: Jani Nikula 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  include/drm/drm_dp_helper.h | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 2c412a15cfa1..0bf15525cdd0 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -738,6 +738,11 @@
> >  #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
> >  # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
> >  
> > +#define LANE0_1_STATUS_ESI  0x200c /* Same as status in 
> > 0x202 */
> > +#define LANE2_3_STATUS_ESI  0x200d /* Same as status in 
> > 0x203 */
> > +#define LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* Same as status in 
> > 0x204 */
> > +#define SINK_STATUS_ESI 0x200f /* Same as status in 
> > 0x205 */
> 
> With the macro names prefixed with DP_,
> 

I must be blind to have not seen that. Thanks!

> Reviewed-by: Jani Nikula 
> 
> 
> > +
> >  #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
> >  # define DP_GTC_CAP(1 << 0)  /* DP 
> > 1.3 */
> >  # define DP_SST_SPLIT_SDP_CAP  (1 << 1)  /* DP 
> > 1.4 */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH v2 3/3] drm: Remove assignment in if condition

[Jani Nikula]

On Wed, 13 Sep 2017, Julia Lawall  wrote:
> On Wed, 13 Sep 2017, Meghana Madhyastha wrote:
>
>> Move the assignment so that it happens before the if
>> condition. This results in syntax which is easier to read.
>
> It would be nice to mention the merged conditionals in the log message.

Either way,

Reviewed-by: Jani Nikula 

>
> julia
>
>> Found by checkpath.pl
>>
>> Signed-off-by: Meghana Madhyastha 
>> ---
>>  drivers/gpu/drm/drm_agpsupport.c | 31 ++-
>>  1 file changed, 18 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
>> b/drivers/gpu/drm/drm_agpsupport.c
>> index 993e486..737f028 100644
>> --- a/drivers/gpu/drm/drm_agpsupport.c
>> +++ b/drivers/gpu/drm/drm_agpsupport.c
>> @@ -100,7 +100,8 @@ int drm_agp_acquire(struct drm_device *dev)
>>  return -ENODEV;
>>  if (dev->agp->acquired)
>>  return -EBUSY;
>> -if (!(dev->agp->bridge = agp_backend_acquire(dev->pdev)))
>> +dev->agp->bridge = agp_backend_acquire(dev->pdev);
>> +if (!dev->agp->bridge)
>>  return -ENODEV;
>>  dev->agp->acquired = 1;
>>  return 0;
>> @@ -200,12 +201,14 @@ int drm_agp_alloc(struct drm_device *dev, struct 
>> drm_agp_buffer *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = kzalloc(sizeof(*entry), GFP_KERNEL)))
>> +entry = kzalloc(sizeof(*entry), GFP_KERNEL);
>> +if (!entry)
>>  return -ENOMEM;
>>
>>  pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
>>  type = (u32) request->type;
>> -if (!(memory = agp_allocate_memory(dev->agp->bridge, pages, type))) {
>> +memory = agp_allocate_memory(dev->agp->bridge, pages, type);
>> +if (!memory) {
>>  kfree(entry);
>>  return -ENOMEM;
>>  }
>> @@ -272,9 +275,8 @@ int drm_agp_unbind(struct drm_device *dev, struct 
>> drm_agp_binding *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
>> -return -EINVAL;
>> -if (!entry->bound)
>> +entry = drm_agp_lookup_entry(dev, request->handle);
>> +if (!entry || !entry->bound)
>>  return -EINVAL;
>>  ret = drm_unbind_agp(entry->memory);
>>  if (ret == 0)
>> @@ -313,12 +315,12 @@ int drm_agp_bind(struct drm_device *dev, struct 
>> drm_agp_binding *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
>> -return -EINVAL;
>> -if (entry->bound)
>> +entry = drm_agp_lookup_entry(dev, request->handle);
>> +if (!entry || entry->bound)
>>  return -EINVAL;
>>  page = (request->offset + PAGE_SIZE - 1) / PAGE_SIZE;
>> -if ((retcode = drm_bind_agp(entry->memory, page)))
>> +retcode = drm_bind_agp(entry->memory, page);
>> +if (retcode)
>>  return retcode;
>>  entry->bound = dev->agp->base + (page << PAGE_SHIFT);
>>  DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
>> @@ -356,7 +358,8 @@ int drm_agp_free(struct drm_device *dev, struct 
>> drm_agp_buffer *request)
>>
>>  if (!dev->agp || !dev->agp->acquired)
>>  return -EINVAL;
>> -if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
>> +entry = drm_agp_lookup_entry(dev, request->handle);
>> +if (!entry)
>>  return -EINVAL;
>>  if (entry->bound)
>>  drm_unbind_agp(entry->memory);
>> @@ -394,11 +397,13 @@ struct drm_agp_head *drm_agp_init(struct drm_device 
>> *dev)
>>  {
>>  struct drm_agp_head *head = NULL;
>>
>> -if (!(head = kzalloc(sizeof(*head), GFP_KERNEL)))
>> +head = kzalloc(sizeof(*head), GFP_KERNEL);
>> +if (!head)
>>  return NULL;
>>  head->bridge = agp_find_bridge(dev->pdev);
>>  if (!head->bridge) {
>> -if (!(head->bridge = agp_backend_acquire(dev->pdev))) {
>> +head->bridge = agp_backend_acquire(dev->pdev);
>> +if (!head->bridge) {
>>  kfree(head);
>>  return NULL;
>>  }
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/20170913161531.GA3239%40meghana-HP-Pavilion-Notebook.
>> For more options, visit https://groups.google.com/d/optout.
>>

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: DPCD register defines for link status within ESI field

[Jani Nikula]

On Wed, 13 Sep 2017, Dhinakaran Pandiyan  wrote:
> Link status is available in the ESI field on devices with DPCD r1.2 or
> higher. DP spec also says "An MST upstream device shall use this field
> instead of the Link/Sink Device Status field registers, starting from DPCD
> Address 00200h."
>
> Cc: Jani Nikula 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  include/drm/drm_dp_helper.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 2c412a15cfa1..0bf15525cdd0 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -738,6 +738,11 @@
>  #define DP_RECEIVER_ALPM_STATUS  0x200b  /* eDP 1.4 */
>  # define DP_ALPM_LOCK_TIMEOUT_ERROR  (1 << 0)
>  
> +#define LANE0_1_STATUS_ESI  0x200c /* Same as status in 
> 0x202 */
> +#define LANE2_3_STATUS_ESI  0x200d /* Same as status in 
> 0x203 */
> +#define LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* Same as status in 
> 0x204 */
> +#define SINK_STATUS_ESI 0x200f /* Same as status in 
> 0x205 */

With the macro names prefixed with DP_,

Reviewed-by: Jani Nikula 


> +
>  #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
>  # define DP_GTC_CAP  (1 << 0)  /* DP 1.3 */
>  # define DP_SST_SPLIT_SDP_CAP(1 << 1)  /* DP 
> 1.4 */

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102552] Null dereference due to not checking return value of util_format_description

[bugzilla-daemon]

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

Pauk Denis  changed:

   What|Removed |Added

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

--- Comment #9 from Pauk Denis  ---
Fixed in
https://cgit.freedesktop.org/mesa/mesa/commit/?id=74d2456491fbd96eb3fb99cf8dd3595b223c2065

-- 
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 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #173 from Thomas DEBESSE  ---
(In reply to Jon Doane from comment #172)
> Unless something has changed with how the dpm state is handled, I don't
> expect that to make the system completely stable. They're more stable than
> balanced but, it's not stable enough to prevent a crash.

Hmm, until now the discussion only talked about level (low, auto, high) and not
state (battery, balanced, performance), it was suspected "auto" level being
faulty, but no one yet suspected "balanced" state being faulty. It's currently
assumed any state is working but one level is not (auto). Perhaps that's a
wrong assumption by the way. Have you specifically experienced an issue due to
the "balanced" state and not due to the "auto" level that is commonly used with
it?

> The only method that I've had luck with while retaining clock scaling is
> this:
> echo 234567 > /sys/class/drm/card0/device/pp_dpm_sclk
> 
> This disables the 300Mhz clock step which seems to work however

Oh yes I forgot this trick because on my end using "low" or "high" level is
enough so I never had to mess with that. By the way when I'm on "low" level I'm
running at 300MHz and it runs nicely for weeks (i.e. until I reboot for
something unrelated like a kernel upgrade).

> One way or another, I have ways around the problem but, these are hacks that
> would be considered intolerable solutions by a regular user.

Sure, but if no one is going to fix that, it would be better to have these
hacks applied by default and not expecting the user to do them by hand. Since
more than two years now, running a LiveCD to install Linux on a system having
an R9 390X leads to a crash while installing… A by-default hack would be better
than nothing if no one is going to fix it.

I still don't understand why it's so hard for AMD employees to get their hand
on AMD hardware to work on a fix, and we know the faulty models (0x67B0,
0x67B1) and many commercial names were listed.

Their AMDGPU-PRO driver looks to not be affected by the bug, so they have a fix
somewhere. Why this fix can't make it's way to the open driver?

-- 
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 3/3] drm/rockchip: vop: Add more RGB output interface type

[Sandy Huang]

This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:

Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

Signed-off-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e..59a01c3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -209,6 +209,8 @@ struct vop_data {
 #define ROCKCHIP_OUT_MODE_P888 0
 #define ROCKCHIP_OUT_MODE_P666 1
 #define ROCKCHIP_OUT_MODE_P565 2
+#define ROCKCHIP_OUT_MODE_S888 8
+#define ROCKCHIP_OUT_MODE_S888_DUMMY   12
 /* for use special outface */
 #define ROCKCHIP_OUT_MODE_ 15
 
-- 
2.7.4


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

[PATCH 2/3] drm/rockchip: Add support for Rockchip Soc RGB output interface

[Sandy Huang]

Like rockchip rv1108 crtc can directly output parallel and serial
RGB data to panel or conversion chip, so we add this driver to
probe encoder and connector.

Signed-off-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c | 327 
 5 files changed, 340 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0c31f0a..ff1c781 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
@@ -65,4 +66,12 @@ config ROCKCHIP_LVDS
  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
  support LVDS, rgb, dual LVDS output mode. say Y to enable its
  driver.
+
+config ROCKCHIP_RGB
+   bool "Rockchip RGB support"
+   help
+ Choose this option to enable support for Rockchip RGB output.
+ Like Rockchip rv1108 SoC CRTC can directly output parallel and
+ serial RGB format to panel or connect to a conversion chip.
+ say Y to enable its driver.
 endif
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a881d2c..f32a17f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 082c251..36e602a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -449,6 +449,8 @@ static int __init rockchip_drm_init(void)
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver,
+   CONFIG_ROCKCHIP_RGB);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
CONFIG_ROCKCHIP_DW_HDMI);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc..6b0ec7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver;
 extern struct platform_driver inno_hdmi_driver;
 extern struct platform_driver rockchip_dp_driver;
 extern struct platform_driver rockchip_lvds_driver;
+extern struct platform_driver rockchip_rgb_driver;
 extern struct platform_driver vop_platform_driver;
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c 
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
new file mode 100644
index 000..0f0e6b464
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_rgb(c) container_of(c, struct rockchip_rgb, connector)
+#define encoder_to_rgb(c) container_of(c, struct rockchip_rgb, encoder)
+
+struct rockchip_rgb {
+   struct device *dev;
+   struct drm_device *drm_dev;
+   struct drm_panel *panel;
+   struct drm_bridge *bridge;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+   struct dev_pin_info *pins;
+   int output_mode;
+};
+
+static inline int name_to_

[PATCH 1/3] dt-bindings: Add document for rockchip RGB output interface

[Sandy Huang]

This path add support rv1108 rgb output interface driver.

Signed-off-by: Sandy Huang 
---
 .../bindings/display/rockchip/rockchip-rgb.txt | 80 ++
 1 file changed, 80 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..4164512
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,80 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+   - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+Required nodes:
+- rockchip,rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy"
+   - p888: output r8-g8-b8 at each dclk cycle for per-pixel
+   - p666: output r6-g6-b6 at each dclk cycle for per-pixel
+   - p565: output r5-g6-b5 at each dclk cycle for per-pixel
+   - s888: output r8-g8-b8 in three dclk cycle for per-pixel
+   - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
+
+The rgb has two video ports described by:
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+   compatible = "auo,b101ean01";
+   enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+
+   ports {
+   panel_in_rgb: endpoint {
+   remote-endpoint = <&rgb_out_panel>;
+   };
+   };
+};
+
+For Rockchip RV1108:
+
+   rgb: rgb {
+   compatible = "rockchip,rv1108-rgb";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <&lcdc_ctl>;
+   rockchip,rgb-mode = "p888";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_in_vop: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vop_out_rgb>;
+   };
+   };
+
+   rgb_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   rgb_out_panel: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&panel_in_rgb>;
+   };
+   };
+   };
+   };
-- 
2.7.4


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

[PATCH 0/3] Add support rockchip RGB output interface

[Sandy Huang]

This patches add support some rockchip Soc like rv1108, the VOP can directly
output parallel and serial RGB data to panel or to conversion chip. So we add
this driver to probe encoder and connector to support this case.

Sandy Huang (3):
  dt-bindings: Add document for rockchip RGB output interface
  drm/rockchip: Add support for Rockchip Soc RGB output interface
  drm/rockchip: vop: Add more RGB output interface type

 .../bindings/display/rockchip/rockchip-rgb.txt |  80 +
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
 drivers/gpu/drm/rockchip/rockchip_rgb.c| 327 +
 7 files changed, 422 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c

-- 
2.7.4


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

[Bug 102694] Astrokill Beta: LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP* instruction uses the constant bus more than once

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||jrch2...@gmail.com

--- Comment #3 from Michel Dänzer  ---
*** Bug 102714 has been marked as a duplicate of this bug. ***

-- 
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 102714] Kodi 17.1 broken in TAHITI

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Michel Dänzer  ---


*** This bug has been marked as a duplicate of bug 102694 ***

-- 
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 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[zhoucm1]

On 2017年09月14日 10:07, zhoucm1 wrote:



On 2017年09月14日 09:52, Dave Airlie wrote:
On 14 September 2017 at 00:16, Christian König 
 wrote:

Am 13.09.2017 um 16:06 schrieb Marek Olšák:

On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing)
 wrote:
For android using mesa instance, egl draw will dequeue an android 
buffer,
after egl draw, the buffer will back to android bufffer queue, but 
need
append a syncfile fd. If getting syncfile fd for every egl draw 
always

needs
several syncobj ioctls, the io overhead isn't small. But if we 
directly

return syncfile when egl draw CS,  isn't it better?

You have a good point. I'd be OK with either approach, or even with
having both options in the kernel.


I don't have a strong opinion for the CS IOCTL either. If it saves 
us an

extra IOCTL when we directly return a syncfile fd then why not?

But we really shouldn't use syncfile for the VA IOCTL. That's 
nothing we
want to share with other processes and the returned fence or 
sequence needs

to be lightweight.

Ideally I would say it should be a sequence number, so that you can say
max(seq1, seq2) and always have the latest.

The next best approach I think would be to use syncobj, cause it is 
simply

rather easily to implement.
I'd go with not returning fd's by default, it's a bad use of a 
limited resource,
creating fd's should happen on giving the object to another process 
or API.


However having an optional chunk or flag to say this ioctl will 
return an
android sync fd if asked is fine with me, if is usually returns a 
syncobj.

OK, that means we return fd only when UMD ask, right?
I will send V2.
But think a bit more, if not by default, that isn't meaningful, we can 
continue to use seq_no base fence and Marek's syncfile fd approach.


Regards,
David Zhou



Thanks all.
David Zhou


Dave.




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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[zhoucm1]

On 2017年09月14日 10:33, Dave Airlie wrote:

But think a bit more, if not by default, that isn't meaningful, we can
continue to use seq_no base fence and Marek's syncfile fd approach.


At least for radv I've no interest in every CS ioctl returning an fd
that I have to
close.

OK, let's pend it now. It doesn't matter.

Regards,
David Zhou


Dave.


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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Dave Airlie]

>
> But think a bit more, if not by default, that isn't meaningful, we can
> continue to use seq_no base fence and Marek's syncfile fd approach.
>

At least for radv I've no interest in every CS ioctl returning an fd
that I have to
close.

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[zhoucm1]

On 2017年09月14日 09:52, Dave Airlie wrote:

On 14 September 2017 at 00:16, Christian König  wrote:

Am 13.09.2017 um 16:06 schrieb Marek Olšák:

On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing)
 wrote:

For android using mesa instance, egl draw will dequeue an android buffer,
after egl draw, the buffer will back to android bufffer queue, but need
append a syncfile fd. If getting syncfile fd for every egl draw always
needs
several syncobj ioctls, the io overhead isn't small. But if we directly
return syncfile when egl draw CS,  isn't it better?

You have a good point. I'd be OK with either approach, or even with
having both options in the kernel.


I don't have a strong opinion for the CS IOCTL either. If it saves us an
extra IOCTL when we directly return a syncfile fd then why not?

But we really shouldn't use syncfile for the VA IOCTL. That's nothing we
want to share with other processes and the returned fence or sequence needs
to be lightweight.

Ideally I would say it should be a sequence number, so that you can say
max(seq1, seq2) and always have the latest.

The next best approach I think would be to use syncobj, cause it is simply
rather easily to implement.

I'd go with not returning fd's by default, it's a bad use of a limited resource,
creating fd's should happen on giving the object to another process or API.

However having an optional chunk or flag to say this ioctl will return an
android sync fd if asked is fine with me, if is usually returns a syncobj.

OK, that means we return fd only when UMD ask, right?
I will send V2.


Thanks all.
David Zhou


Dave.


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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Dave Airlie]

On 14 September 2017 at 00:16, Christian König  wrote:
> Am 13.09.2017 um 16:06 schrieb Marek Olšák:
>>
>> On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing)
>>  wrote:
>>>
>>> For android using mesa instance, egl draw will dequeue an android buffer,
>>> after egl draw, the buffer will back to android bufffer queue, but need
>>> append a syncfile fd. If getting syncfile fd for every egl draw always
>>> needs
>>> several syncobj ioctls, the io overhead isn't small. But if we directly
>>> return syncfile when egl draw CS,  isn't it better?
>>
>> You have a good point. I'd be OK with either approach, or even with
>> having both options in the kernel.
>
>
> I don't have a strong opinion for the CS IOCTL either. If it saves us an
> extra IOCTL when we directly return a syncfile fd then why not?
>
> But we really shouldn't use syncfile for the VA IOCTL. That's nothing we
> want to share with other processes and the returned fence or sequence needs
> to be lightweight.
>
> Ideally I would say it should be a sequence number, so that you can say
> max(seq1, seq2) and always have the latest.
>
> The next best approach I think would be to use syncobj, cause it is simply
> rather easily to implement.

I'd go with not returning fd's by default, it's a bad use of a limited resource,
creating fd's should happen on giving the object to another process or API.

However having an optional chunk or flag to say this ioctl will return an
android sync fd if asked is fine with me, if is usually returns a syncobj.

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

[PATCH] drm/dp: DPCD register defines for link status within ESI field

[Dhinakaran Pandiyan]

Link status is available in the ESI field on devices with DPCD r1.2 or
higher. DP spec also says "An MST upstream device shall use this field
instead of the Link/Sink Device Status field registers, starting from DPCD
Address 00200h."

Cc: Jani Nikula 
Signed-off-by: Dhinakaran Pandiyan 
---
 include/drm/drm_dp_helper.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 2c412a15cfa1..0bf15525cdd0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -738,6 +738,11 @@
 #define DP_RECEIVER_ALPM_STATUS0x200b  /* eDP 1.4 */
 # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0)
 
+#define LANE0_1_STATUS_ESI  0x200c /* Same as status in 0x202 
*/
+#define LANE2_3_STATUS_ESI  0x200d /* Same as status in 0x203 
*/
+#define LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* Same as status in 0x204 
*/
+#define SINK_STATUS_ESI 0x200f /* Same as status in 0x205 
*/
+
 #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
 # define DP_GTC_CAP(1 << 0)  /* DP 1.3 */
 # define DP_SST_SPLIT_SDP_CAP  (1 << 1)  /* DP 1.4 */
-- 
2.11.0

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

Re: [PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

[Hoegeun Kwon]

On 09/13/2017 09:13 PM, Sylwester Nawrocki wrote:

On 09/13/2017 01:41 PM, Hoegeun Kwon wrote:
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, 
void *priv)

  .num_clocks = 1,
  };
  +static struct gsc_driverdata gsc_v_5250_drvdata = {
+.variant = {
+[0] = &gsc_v_5250_variant,
+[1] = &gsc_v_5250_variant,
+[2] = &gsc_v_5250_variant,
+[3] = &gsc_v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = &gsc_v_5420_variant,
+[1] = &gsc_v_5420_variant,
+},
+.num_entities = 4,


Shouldn't num_enities be 2 here? You don't need to resend, I can
amend that when applying.




Yes, num_enities is 2.
Sorry I made a mistake.

Thanks Sylwester.

Best regards,
Hoegeun


+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+


--
Regards,
Sylwester




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

[Bug 102714] Kodi 17.1 broken in TAHITI

[bugzilla-daemon]

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

--- Comment #2 from Rafael Castillo  ---
false alarm LLVM is broken not mesa

last good LLVM is 312776

you can close this if needed

TYVM and sorry

-- 
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 102714] Kodi 17.1 broken in TAHITI

[bugzilla-daemon]

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

--- Comment #1 from Rafael Castillo  ---
Also broken using radeon 

%VGPR11 = V_MADMK_F32 %SGPR3, 1077936128, %VGPR17, %EXEC
LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP*
instruction uses the constant bus more than once
%VGPR10 = V_MADMK_F32 %SGPR2, 1077936128, %VGPR14, %EXEC
LLVM failed to compile shader


OpenGL renderer string: AMD TAHITI (DRM 2.50.0 / 4.13.0-mainline, LLVM 6.0.0)

-- 
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 102714] Kodi 17.1 broken in TAHITI

[bugzilla-daemon]

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

Bug ID: 102714
   Summary: Kodi 17.1 broken in TAHITI
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jrch2...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Hi, Guys

I just realized kodi 17.1 is broken on mesa git when you enable Advanced
Shaders and try to set on videos any option like bicubic or lanczos

OS:
ArchLinux latest updates

Kernels tested:
amd-staging-4.12
linux-mainline-4.13

Driver:
AMDGPU

My GLXINFO:
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD Radeon HD 7900 Series (TAHITI / DRM 3.18.0 / 4.13.0-mainline,
LLVM 6.0.0) (0x679a)
Version: 17.3.0
Accelerated: yes
Video memory: 2952MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon HD 7900 Series (TAHITI / DRM 3.18.0 /
4.13.0-mainline, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.0-devel
(git-74d2456491)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.3.0-devel (git-74d2456491)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.3.0-devel
(git-74d2456491)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10


Fail OUTPUT:

LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP*
instruction uses the constant bus more than once
%VGPR11 = V_MADMK_F32 %SGPR3, 1077936128, %VGPR17, %EXEC
LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP*
instruction uses the constant bus more than once
%VGPR10 = V_MADMK_F32 %SGPR2, 1077936128, %VGPR14, %EXEC
LLVM failed to compile shader


Tyvm, for your hard work

-- 
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 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #172 from Jon Doane  ---
(In reply to Thomas DEBESSE from comment #171)
> > This sounds a lot like what I've been doing manually which sounds nice.
> > Thanks for the input. I honestly would like a solution that doesn't cause my
> > machine to draw an additional 90 watts at idle though.
> 
> Unlike the kernel patch above, that systemd service is setting the GPU to
> "low battery" by default, which is the most energy saving profile. The
> provided `dpm query` tool allows you to change that at any time. That's what
> I'm doing: at init, my GPU is set to "low battery" profile, and when I need
> to do some heavy time, I do that:
> 
> dpm-query set all high performance
> 
> And then once the heavy task is done, I do that to save energy again:
> 
> dpm-query set all low battery
> 
> With the default config for the service, you just have to add your own user
> to the "video" group to have the right to change the profile as user.
> 
> So, even if the patch above get merged one day, this service and tool is
> still useful, it's an easy way to change the default profile, whatever the
> default is.
> 
> Notice that the kernel patch above only set the level to "high", but keep
> the state to "balanced", so it's still adaptative. What "high balanced" does
> is setting the shader and memory frequencies to the max, which is drawing
> more power than default, but you will notice the fan are still idling and
> stopped if you do nothing because it's still saving a lot of energy. If you
> set "high performance" the fan will almost instantaneously start because
> there is no saving anymore. So "high balanced" is less energy saving that
> "auto balanced", but is still saving a lot of energy because it does not
> have to cold the chip while doing nothing (meaning the chip does nothing
> strong enough to get hot).

Unless something has changed with how the dpm state is handled, I don't expect
that to make the system completely stable. They're more stable than balanced
but, it's not stable enough to prevent a crash. I tried by starting off with:
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level

The only method that I've had luck with while retaining clock scaling is this:
echo 234567 > /sys/class/drm/card0/device/pp_dpm_sclk

This disables the 300Mhz clock step which seems to work however, I've observed
that doing this also forced memory clocks to full tilt instead of idle so, I'm
uncertain if the memory clock or core clock is responsible.

Something I've observed is that if my machine crashes and I use the reset
button to restart it, that when X loads and if I don't force clocks up, it
always crashes and that part of the old image that was on the screen when it
initially crashed gets displayed, albeit rather garbled but, enough to identify
it which makes me think that it's related to the memory clock or how GPU memory
is managed.

One way or another, I have ways around the problem but, these are hacks that
would be considered intolerable solutions by a regular user.

-- 
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 101747] Steam-Game Turmoil, Segfault on start

[bugzilla-daemon]

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

--- Comment #1 from famo  ---
Still crashes with Mesa 17.1.5


Graphics:  Card: Advanced Micro Devices [AMD/ATI] Fiji [Radeon R9 FURY / NANO
Series]
   Display Server: x11 (X.Org 1.19.3) driver: amdgpu Resolution:
2560x1440@143.86hz
   OpenGL: renderer: Gallium 0.4 on AMD FIJI (DRM 3.15.0 /
4.12.4-1-CHAKRA, LLVM 4.0.1)
   version: 4.5 Mesa 17.1.5

-- 
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: [Outreachy kernel] [PATCH v2 2/3] drm: Replace "foo * bar" with "foo *bar"

[Sean Paul]

On Wed, Sep 13, 2017 at 12:14 PM, Meghana Madhyastha
 wrote:
> This replaces all instances of foo * bar with foo *bar
> in drm_agpsupport.c. This is so that it adheres to
> standard C syntax for pointers.
>
> Signed-off-by: Meghana Madhyastha 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_agpsupport.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index 928248e..993e486 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -94,7 +94,7 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
>   * Verifies the AGP device hasn't been acquired before and calls
>   * \c agp_backend_acquire.
>   */
> -int drm_agp_acquire(struct drm_device * dev)
> +int drm_agp_acquire(struct drm_device *dev)
>  {
> if (!dev->agp)
> return -ENODEV;
> @@ -133,7 +133,7 @@ int drm_agp_acquire_ioctl(struct drm_device *dev, void 
> *data,
>   *
>   * Verifies the AGP device has been acquired and calls \c 
> agp_backend_release.
>   */
> -int drm_agp_release(struct drm_device * dev)
> +int drm_agp_release(struct drm_device *dev)
>  {
> if (!dev->agp || !dev->agp->acquired)
> return -EINVAL;
> @@ -159,7 +159,7 @@ int drm_agp_release_ioctl(struct drm_device *dev, void 
> *data,
>   * Verifies the AGP device has been acquired but not enabled, and calls
>   * \c agp_enable.
>   */
> -int drm_agp_enable(struct drm_device * dev, struct drm_agp_mode mode)
> +int drm_agp_enable(struct drm_device *dev, struct drm_agp_mode mode)
>  {
> if (!dev->agp || !dev->agp->acquired)
> return -EINVAL;
> @@ -241,8 +241,8 @@ int drm_agp_alloc_ioctl(struct drm_device *dev, void 
> *data,
>   *
>   * Walks through drm_agp_head::memory until finding a matching handle.
>   */
> -static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device * dev,
> -  unsigned long handle)
> +static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device *dev,
> +   unsigned long handle)
>  {
> struct drm_agp_mem *entry;
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170913161420.GA3221%40meghana-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH v2 1/3] drm: Move EXPORT_SYMBOL so that it immediately follows its function

[Sean Paul]

On Wed, Sep 13, 2017 at 4:16 PM, Julia Lawall  wrote:
>
>
> On Wed, 13 Sep 2017, Meghana Madhyastha wrote:
>
>> EXPORT_SYMBOL(foo) should immediately follow its function/variable.
>> This coding style is preferred.
>> Found by checkpath.pl.
>>
>> Signed-off-by: Meghana Madhyastha 

With Julia's suggestion resolved:

Reviewed-by: Sean Paul 

>> ---
>>  drivers/gpu/drm/drm_agpsupport.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
>> b/drivers/gpu/drm/drm_agpsupport.c
>> index c899534..928248e 100644
>> --- a/drivers/gpu/drm/drm_agpsupport.c
>> +++ b/drivers/gpu/drm/drm_agpsupport.c
>> @@ -70,7 +70,6 @@ int drm_agp_info(struct drm_device *dev, struct 
>> drm_agp_info *info)
>>
>>   return 0;
>>  }
>> -
>>  EXPORT_SYMBOL(drm_agp_info);
>>
>>  int drm_agp_info_ioctl(struct drm_device *dev, void *data,
>> @@ -106,7 +105,6 @@ int drm_agp_acquire(struct drm_device * dev)
>>   dev->agp->acquired = 1;
>>   return 0;
>>  }
>> -
>>  EXPORT_SYMBOL(drm_agp_acquire);
>>
>>  /**
>> @@ -171,7 +169,6 @@ int drm_agp_enable(struct drm_device * dev, struct 
>> drm_agp_mode mode)
>>   dev->agp->enabled = 1;
>>   return 0;
>>  }
>> -
>>  EXPORT_SYMBOL(drm_agp_enable);
>>
>>  int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
>> @@ -373,7 +370,6 @@ int drm_agp_free(struct drm_device *dev, struct 
>> drm_agp_buffer *request)
>>  EXPORT_SYMBOL(drm_agp_free);
>>
>>
>> -
>
> I still don't think this change belongs in this patch.  I ran checkpatch
> on this file, and I only get warnings about the first three
> EXPORT_SYMBOLs.  There is no warning related to EXPORT_SYMBOL after line
> 175.
>
> julia
>
>>  int drm_agp_free_ioctl(struct drm_device *dev, void *data,
>>  struct drm_file *file_priv)
>>  {
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/20170913161340.GA3204%40meghana-HP-Pavilion-Notebook.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/alpine.DEB.2.20.1709132214330.2920%40hadrien.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH v2 0/3] drm: Code cleanup

[Sean Paul]

On Wed, Sep 13, 2017 at 12:12 PM, Meghana Madhyastha
 wrote:
> These patches fix the checkpath warnings and errors
> in drm_agpsupport.c
>
> changes in v2:
>  -Changed the commit subject prefix to follow the style used in drm.
>  -Combine multiple redundant if conditions to a single condition in
>   patch 3.
>
> Meghana Madhyastha (3):
>   drm: Move EXPORT_SYMBOL so that it immediately follows its function
>   drm: Replace "foo * bar" with "foo *bar"
>   drm: Remove assignment in if condition

Hi Meghana,
Thank you for your submissions!

Would you mind prefixing the subjects with drm/agpsupport instead of
just drm? I know the git log shows mostly drm:, but I think that's
more because the only time this file is touched is during subsystem
wide refactors/cleanups. While this may seem like a small nit,
narrowing down the affected file(s) in the subject really helps when
glancing at the log.

Sean



>
>  drivers/gpu/drm/drm_agpsupport.c | 45 
> 
>  1 file changed, 23 insertions(+), 22 deletions(-)
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170913161235.GA3155%40meghana-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 638/1021] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1031:18: error: 'drm_atomic_helper_crtc_set_property' undeclared here (not in a function)

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   43dd6fde5df450938568885249b836eb376e2ad6
commit: 13caa908431faa8016f21d3bca700adf0b8382c5 [638/1021] drm/amd/display: 
fix drm_edid.h inclusion
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 13caa908431faa8016f21d3bca700adf0b8382c5
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: the radeon-alex/amd-staging-drm-next HEAD 
43dd6fde5df450938568885249b836eb376e2ad6 builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:29:
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c: In 
function 'fill_rects_from_plane_state':
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:279:11: 
error: 'DRM_ROTATE_0' undeclared (first use in this function)
 case BIT(DRM_ROTATE_0):
  ^
   include/linux/bitops.h:6:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:279:11: 
note: each undeclared identifier is reported only once for each function it 
appears in
 case BIT(DRM_ROTATE_0):
  ^
   include/linux/bitops.h:6:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:282:11: 
error: 'DRM_ROTATE_90' undeclared (first use in this function)
 case BIT(DRM_ROTATE_90):
  ^
   include/linux/bitops.h:6:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:285:11: 
error: 'DRM_ROTATE_180' undeclared (first use in this function)
 case BIT(DRM_ROTATE_180):
  ^
   include/linux/bitops.h:6:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:288:11: 
error: 'DRM_ROTATE_270' undeclared (first use in this function)
 case BIT(DRM_ROTATE_270):
  ^
   include/linux/bitops.h:6:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c: At top 
level:
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1031:18: 
>> error: 'drm_atomic_helper_crtc_set_property' undeclared here (not in a 
>> function)
 .set_property = drm_atomic_helper_crtc_set_property,
 ^~~
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1304:10: 
>> error: 'drm_atomic_helper_connector_dpms' undeclared here (not in a function)
 .dpms = drm_atomic_helper_connector_dpms,
 ^~~~
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1308:18: 
>> error: 'drm_atomic_helper_connector_set_property' undeclared here (not in a 
>> function)
 .set_property = drm_atomic_helper_connector_set_property,
 ^~~~
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1558:18: 
>> error: 'drm_atomic_helper_plane_set_property' undeclared here (not in a 
>> function)
 .set_property = drm_atomic_helper_plane_set_property,
 ^~~~
   drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c: In 
function 'amdgpu_dm_plane_init':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:1721:5: 
>> error: incompatible type for argument 7 of 'drm_universal_plane_init'
aplane->base.type, NULL);
^~
   In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:69,
from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c:29:
   include/drm/drm_plane.h:548:5: note: expected 'const uint64_t * {aka const 
long long unsigned int *}' but argument is of type 'enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
 

Re: [Outreachy kernel] [PATCH v2 3/3] drm: Remove assignment in if condition

[Julia Lawall]

On Wed, 13 Sep 2017, Meghana Madhyastha wrote:

> Move the assignment so that it happens before the if
> condition. This results in syntax which is easier to read.

It would be nice to mention the merged conditionals in the log message.

julia

> Found by checkpath.pl
>
> Signed-off-by: Meghana Madhyastha 
> ---
>  drivers/gpu/drm/drm_agpsupport.c | 31 ++-
>  1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index 993e486..737f028 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -100,7 +100,8 @@ int drm_agp_acquire(struct drm_device *dev)
>   return -ENODEV;
>   if (dev->agp->acquired)
>   return -EBUSY;
> - if (!(dev->agp->bridge = agp_backend_acquire(dev->pdev)))
> + dev->agp->bridge = agp_backend_acquire(dev->pdev);
> + if (!dev->agp->bridge)
>   return -ENODEV;
>   dev->agp->acquired = 1;
>   return 0;
> @@ -200,12 +201,14 @@ int drm_agp_alloc(struct drm_device *dev, struct 
> drm_agp_buffer *request)
>
>   if (!dev->agp || !dev->agp->acquired)
>   return -EINVAL;
> - if (!(entry = kzalloc(sizeof(*entry), GFP_KERNEL)))
> + entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> + if (!entry)
>   return -ENOMEM;
>
>   pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
>   type = (u32) request->type;
> - if (!(memory = agp_allocate_memory(dev->agp->bridge, pages, type))) {
> + memory = agp_allocate_memory(dev->agp->bridge, pages, type);
> + if (!memory) {
>   kfree(entry);
>   return -ENOMEM;
>   }
> @@ -272,9 +275,8 @@ int drm_agp_unbind(struct drm_device *dev, struct 
> drm_agp_binding *request)
>
>   if (!dev->agp || !dev->agp->acquired)
>   return -EINVAL;
> - if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
> - return -EINVAL;
> - if (!entry->bound)
> + entry = drm_agp_lookup_entry(dev, request->handle);
> + if (!entry || !entry->bound)
>   return -EINVAL;
>   ret = drm_unbind_agp(entry->memory);
>   if (ret == 0)
> @@ -313,12 +315,12 @@ int drm_agp_bind(struct drm_device *dev, struct 
> drm_agp_binding *request)
>
>   if (!dev->agp || !dev->agp->acquired)
>   return -EINVAL;
> - if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
> - return -EINVAL;
> - if (entry->bound)
> + entry = drm_agp_lookup_entry(dev, request->handle);
> + if (!entry || entry->bound)
>   return -EINVAL;
>   page = (request->offset + PAGE_SIZE - 1) / PAGE_SIZE;
> - if ((retcode = drm_bind_agp(entry->memory, page)))
> + retcode = drm_bind_agp(entry->memory, page);
> + if (retcode)
>   return retcode;
>   entry->bound = dev->agp->base + (page << PAGE_SHIFT);
>   DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
> @@ -356,7 +358,8 @@ int drm_agp_free(struct drm_device *dev, struct 
> drm_agp_buffer *request)
>
>   if (!dev->agp || !dev->agp->acquired)
>   return -EINVAL;
> - if (!(entry = drm_agp_lookup_entry(dev, request->handle)))
> + entry = drm_agp_lookup_entry(dev, request->handle);
> + if (!entry)
>   return -EINVAL;
>   if (entry->bound)
>   drm_unbind_agp(entry->memory);
> @@ -394,11 +397,13 @@ struct drm_agp_head *drm_agp_init(struct drm_device 
> *dev)
>  {
>   struct drm_agp_head *head = NULL;
>
> - if (!(head = kzalloc(sizeof(*head), GFP_KERNEL)))
> + head = kzalloc(sizeof(*head), GFP_KERNEL);
> + if (!head)
>   return NULL;
>   head->bridge = agp_find_bridge(dev->pdev);
>   if (!head->bridge) {
> - if (!(head->bridge = agp_backend_acquire(dev->pdev))) {
> + head->bridge = agp_backend_acquire(dev->pdev);
> + if (!head->bridge) {
>   kfree(head);
>   return NULL;
>   }
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170913161531.GA3239%40meghana-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH v2 2/3] drm: Replace "foo * bar" with "foo *bar"

[Julia Lawall]

On Wed, 13 Sep 2017, Meghana Madhyastha wrote:

> This replaces all instances of foo * bar with foo *bar
> in drm_agpsupport.c. This is so that it adheres to
> standard C syntax for pointers.
>
> Signed-off-by: Meghana Madhyastha 

Acked-by: Julia Lawall 

> ---
>  drivers/gpu/drm/drm_agpsupport.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index 928248e..993e486 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -94,7 +94,7 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
>   * Verifies the AGP device hasn't been acquired before and calls
>   * \c agp_backend_acquire.
>   */
> -int drm_agp_acquire(struct drm_device * dev)
> +int drm_agp_acquire(struct drm_device *dev)
>  {
>   if (!dev->agp)
>   return -ENODEV;
> @@ -133,7 +133,7 @@ int drm_agp_acquire_ioctl(struct drm_device *dev, void 
> *data,
>   *
>   * Verifies the AGP device has been acquired and calls \c 
> agp_backend_release.
>   */
> -int drm_agp_release(struct drm_device * dev)
> +int drm_agp_release(struct drm_device *dev)
>  {
>   if (!dev->agp || !dev->agp->acquired)
>   return -EINVAL;
> @@ -159,7 +159,7 @@ int drm_agp_release_ioctl(struct drm_device *dev, void 
> *data,
>   * Verifies the AGP device has been acquired but not enabled, and calls
>   * \c agp_enable.
>   */
> -int drm_agp_enable(struct drm_device * dev, struct drm_agp_mode mode)
> +int drm_agp_enable(struct drm_device *dev, struct drm_agp_mode mode)
>  {
>   if (!dev->agp || !dev->agp->acquired)
>   return -EINVAL;
> @@ -241,8 +241,8 @@ int drm_agp_alloc_ioctl(struct drm_device *dev, void 
> *data,
>   *
>   * Walks through drm_agp_head::memory until finding a matching handle.
>   */
> -static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device * dev,
> -unsigned long handle)
> +static struct drm_agp_mem *drm_agp_lookup_entry(struct drm_device *dev,
> + unsigned long handle)
>  {
>   struct drm_agp_mem *entry;
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170913161420.GA3221%40meghana-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH v2 1/3] drm: Move EXPORT_SYMBOL so that it immediately follows its function

[Julia Lawall]

On Wed, 13 Sep 2017, Meghana Madhyastha wrote:

> EXPORT_SYMBOL(foo) should immediately follow its function/variable.
> This coding style is preferred.
> Found by checkpath.pl.
>
> Signed-off-by: Meghana Madhyastha 
> ---
>  drivers/gpu/drm/drm_agpsupport.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index c899534..928248e 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -70,7 +70,6 @@ int drm_agp_info(struct drm_device *dev, struct 
> drm_agp_info *info)
>
>   return 0;
>  }
> -
>  EXPORT_SYMBOL(drm_agp_info);
>
>  int drm_agp_info_ioctl(struct drm_device *dev, void *data,
> @@ -106,7 +105,6 @@ int drm_agp_acquire(struct drm_device * dev)
>   dev->agp->acquired = 1;
>   return 0;
>  }
> -
>  EXPORT_SYMBOL(drm_agp_acquire);
>
>  /**
> @@ -171,7 +169,6 @@ int drm_agp_enable(struct drm_device * dev, struct 
> drm_agp_mode mode)
>   dev->agp->enabled = 1;
>   return 0;
>  }
> -
>  EXPORT_SYMBOL(drm_agp_enable);
>
>  int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
> @@ -373,7 +370,6 @@ int drm_agp_free(struct drm_device *dev, struct 
> drm_agp_buffer *request)
>  EXPORT_SYMBOL(drm_agp_free);
>
>
> -

I still don't think this change belongs in this patch.  I ran checkpatch
on this file, and I only get warnings about the first three
EXPORT_SYMBOLs.  There is no warning related to EXPORT_SYMBOL after line
175.

julia

>  int drm_agp_free_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file_priv)
>  {
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170913161340.GA3204%40meghana-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drivers:gpu:Use ARRAY_SIZE() for the size calculation of the array.

[Alex Deucher]

On Wed, Sep 13, 2017 at 4:01 AM, Allen Pais  wrote:
> Signed-off-by: Allen Pais 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c 
> b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
> index 4395a4f..0487936 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
> @@ -274,7 +274,7 @@ static const struct pctl_data pctl0_data[] = {
> {0x135, 0x12a810},
> {0x149, 0x7a82c}
>  };
> -#define PCTL0_DATA_LEN (sizeof(pctl0_data)/sizeof(pctl0_data[0]))
> +#define PCTL0_DATA_LEN (ARRAY_SIZE(pctl0_data))
>
>  #define PCTL0_RENG_EXEC_END_PTR 0x151
>  #define PCTL0_STCTRL_REG_SAVE_RANGE0_BASE  0xa640
> @@ -310,7 +310,7 @@ static const struct pctl_data pctl1_data[] = {
> {0x1f0, 0x5000a7f6},
> {0x1f1, 0x5000a7e4}
>  };
> -#define PCTL1_DATA_LEN (sizeof(pctl1_data)/sizeof(pctl1_data[0]))
> +#define PCTL1_DATA_LEN (ARRAY_SIZE(pctl1_data))
>
>  #define PCTL1_RENG_EXEC_END_PTR 0x1f1
>  #define PCTL1_STCTRL_REG_SAVE_RANGE0_BASE  0xa000
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102517] System hang/freeze Helium Rain

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
Can you attach your glxinfo, please?

-- 
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 0/6 v4] Add ASoC support for AMD Stoney APUs

[Alex Deucher]

On Wed, Sep 13, 2017 at 2:12 PM, Mark Brown  wrote:
> On Wed, Sep 13, 2017 at 01:57:49PM -0400, Alex Deucher wrote:
>
>> I just need acks from audio on the remaining patches that touch audio
>> (1, 5, 6), and then I can send a pull request.
>
> No, send me a pull request for the dependencies so we can do a cross
> merge.  I want to make sure that when this gets reviewed it actually
> gets merged.

I'm not quite sure what you mean by the cross merge.  There are no
dependencies outside this patch set.  The only patches that touch drm
are patches 1 and 2.  Patch 1 touches both audio and drm, patch 2 just
touches drm.  Do you want me to send you a pull request for patches 1
and 2 and then would you'd send Dave a pull request for the audio side
(patches 3-6)?

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

Re: [PATCH 0/6 v4] Add ASoC support for AMD Stoney APUs

[Mark Brown]

On Wed, Sep 13, 2017 at 01:57:49PM -0400, Alex Deucher wrote:

> I just need acks from audio on the remaining patches that touch audio
> (1, 5, 6), and then I can send a pull request.

No, send me a pull request for the dependencies so we can do a cross
merge.  I want to make sure that when this gets reviewed it actually
gets merged.


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

[Bug 102709] War Thunder crashes after logging in to the game. (GL_INVALID_ENUM)

[bugzilla-daemon]

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

Bug ID: 102709
   Summary: War Thunder crashes after logging in to the game.
(GL_INVALID_ENUM)
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: balalic.en...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 134200
  --> https://bugs.freedesktop.org/attachment.cgi?id=134200&action=edit
GlxInfo

On my Radeon HD6950, War Thunder crashes after logging in to the game,

if using LIBGL_DEBUG=verbose and MESA_DEBUG=1 when starting the game, it spams
the following in the console:

Mesa: User error: GL_INVALID_ENUM in glTexStorage2D(internalformat =
GL_COMPRESSED_RGBA_S3TC_DXT5_EXT)
Mesa: User error: GL_INVALID_ENUM in glCompressedTexSubImage2D(format)

and a couple of the messages are a bit different:

Mesa: User error: GL_INVALID_ENUM in glTexStorage2D(internalformat =
GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT)
Mesa: User error: GL_INVALID_ENUM in glCompressedTexSubImage2D(format)


Using Fedora Rawhide, Mesa 17.3.0-devel, LLVM 6.0.0, packages from che COPR
repo.

-- 
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 0/6 v4] Add ASoC support for AMD Stoney APUs

[Alex Deucher]

This patch set updates the AMD GPU and Audio CoProcessor (ACP)
audio drivers and the designware i2s driver for Stoney (ST).
ST is an APU similar to Carrizo (CZ) which already has ACP audio
support.  The i2s controller and ACP audio DMA engine are part of
the GPU and both need updating so I would like to upstream the
whole patch set via one tree if possible.

The entire patch set can be viewed here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=stoney_acp3

I just need acks from audio on the remaining patches that touch audio
(1, 5, 6), and then I can send a pull request.

Thanks!

Alex

v2:
- Patch 1 is already applied to the audio tree, just including it for
  completeness since it's required for this patch set and it's not yet
  in the drm tree.
- New patch to share asic types between gpu and audio drivers
- ACPI ID changed for rt5650 machine driver
- Integrate feedback on other patches

v3:
- resend remaining patches that have not been applied yet

v4:
- Integrate feedback from v3
- Add Mark's acks from v3
- Integrate a machine driver fix from Dylan Reid

Akshu Agrawal (2):
  drm/amdgpu Moving amdgpu asic types to a separate file
  ASoC: AMD: Add machine driver for cz rt5650

Vijendar Mukunda (4):
  drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data
  ASoC: AMD: disabling memory gating in stoney platform
  ASoC: AMD: DMA driver changes for Stoney Platform
  ASoC: AMD: Audio buffer related changes for Stoney

 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c  |   2 +
 drivers/gpu/drm/amd/include/amd_shared.h |  29 +---
 include/drm/amd_asic_type.h  |  52 +++
 sound/soc/amd/Kconfig|   7 +
 sound/soc/amd/Makefile   |   2 +
 sound/soc/amd/acp-pcm-dma.c  | 253 ---
 sound/soc/amd/acp-rt5645.c   | 199 
 sound/soc/amd/acp.h  |   9 ++
 8 files changed, 471 insertions(+), 82 deletions(-)
 create mode 100644 include/drm/amd_asic_type.h
 create mode 100644 sound/soc/amd/acp-rt5645.c

-- 
2.5.5

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

[PATCH 2/6 v2] drm/amdgpu Moving amdgpu asic types to a separate file

[Alex Deucher]

From: Akshu Agrawal 

Amdgpu asic types will be required for other drivers too.
Hence, its better to keep it in a separate include file.

Reviewed-by: Alex Deucher 
Signed-off-by: Akshu Agrawal 
Signed-off-by: Alex Deucher 
---

v1: New patch to share asic_type definitions between GPU and audio driver.
v2: add R-b, resend

 drivers/gpu/drm/amd/include/amd_shared.h | 29 ++
 include/drm/amd_asic_type.h  | 52 
 2 files changed, 54 insertions(+), 27 deletions(-)
 create mode 100644 include/drm/amd_asic_type.h

diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index 70e8c20..3a49fbd 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -23,34 +23,9 @@
 #ifndef __AMD_SHARED_H__
 #define __AMD_SHARED_H__
 
-#define AMD_MAX_USEC_TIMEOUT   20  /* 200 ms */
+#include 
 
-/*
- * Supported ASIC types
- */
-enum amd_asic_type {
-   CHIP_TAHITI = 0,
-   CHIP_PITCAIRN,
-   CHIP_VERDE,
-   CHIP_OLAND,
-   CHIP_HAINAN,
-   CHIP_BONAIRE,
-   CHIP_KAVERI,
-   CHIP_KABINI,
-   CHIP_HAWAII,
-   CHIP_MULLINS,
-   CHIP_TOPAZ,
-   CHIP_TONGA,
-   CHIP_FIJI,
-   CHIP_CARRIZO,
-   CHIP_STONEY,
-   CHIP_POLARIS10,
-   CHIP_POLARIS11,
-   CHIP_POLARIS12,
-   CHIP_VEGA10,
-   CHIP_RAVEN,
-   CHIP_LAST,
-};
+#define AMD_MAX_USEC_TIMEOUT   20  /* 200 ms */
 
 /*
  * Chip flags
diff --git a/include/drm/amd_asic_type.h b/include/drm/amd_asic_type.h
new file mode 100644
index 000..599028f
--- /dev/null
+++ b/include/drm/amd_asic_type.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __AMD_ASIC_TYPE_H__
+#define __AMD_ASIC_TYPE_H__
+/*
+ * Supported ASIC types
+ */
+enum amd_asic_type {
+   CHIP_TAHITI = 0,
+   CHIP_PITCAIRN,
+   CHIP_VERDE,
+   CHIP_OLAND,
+   CHIP_HAINAN,
+   CHIP_BONAIRE,
+   CHIP_KAVERI,
+   CHIP_KABINI,
+   CHIP_HAWAII,
+   CHIP_MULLINS,
+   CHIP_TOPAZ,
+   CHIP_TONGA,
+   CHIP_FIJI,
+   CHIP_CARRIZO,
+   CHIP_STONEY,
+   CHIP_POLARIS10,
+   CHIP_POLARIS11,
+   CHIP_POLARIS12,
+   CHIP_VEGA10,
+   CHIP_RAVEN,
+   CHIP_LAST,
+};
+
+#endif /*__AMD_ASIC_TYPE_H__ */
-- 
2.5.5

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

[PATCH 3/6 v4] ASoC: AMD: disabling memory gating in stoney platform

[Alex Deucher]

From: Vijendar Mukunda 

For Stoney platform, Memory gating is disabled.i.e SRAM Banks
won't be turned off. By Default, SRAM Bank state set to ON.
Added condition checks to skip SRAM Bank state set logic for
Stoney platform.

Acked-by: Mark Brown 
Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
---

v2: Added comments in code and removed locally defined macros
for STONEY and Carrizo.
v3: add R-b, resend
v4: add Mark's Ack

 sound/soc/amd/acp-pcm-dma.c | 79 +++--
 1 file changed, 55 insertions(+), 24 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index dcbf997..f00b6b9 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -20,7 +20,7 @@
 #include 
 
 #include 
-
+#include 
 #include "acp.h"
 
 #define PLAYBACK_MIN_NUM_PERIODS2
@@ -419,7 +419,7 @@ static void acp_set_sram_bank_state(void __iomem *acp_mmio, 
u16 bank,
 }
 
 /* Initialize and bring ACP hardware to default state. */
-static int acp_init(void __iomem *acp_mmio)
+static int acp_init(void __iomem *acp_mmio, u32 asic_type)
 {
u16 bank;
u32 val, count, sram_pte_offset;
@@ -493,9 +493,14 @@ static int acp_init(void __iomem *acp_mmio)
/* When ACP_TILE_P1 is turned on, all SRAM banks get turned on.
* Now, turn off all of them. This can't be done in 'poweron' of
* ACP pm domain, as this requires ACP to be initialized.
+   * For Stoney, Memory gating is disabled,i.e SRAM Banks
+   * won't be turned off. The default state for SRAM banks is ON.
+   * Setting SRAM bank state code skipped for STONEY platform.
*/
-   for (bank = 1; bank < 48; bank++)
-   acp_set_sram_bank_state(acp_mmio, bank, false);
+   if (asic_type != CHIP_STONEY) {
+   for (bank = 1; bank < 48; bank++)
+   acp_set_sram_bank_state(acp_mmio, bank, false);
+   }
 
return 0;
 }
@@ -646,14 +651,22 @@ static int acp_dma_open(struct snd_pcm_substream 
*substream)
 
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
intr_data->play_stream = substream;
-   for (bank = 1; bank <= 4; bank++)
-   acp_set_sram_bank_state(intr_data->acp_mmio, bank,
-   true);
+   /* For Stoney, Memory gating is disabled,i.e SRAM Banks
+* won't be turned off. The default state for SRAM banks is ON.
+* Setting SRAM bank state code skipped for STONEY platform.
+*/
+   if (intr_data->asic_type != CHIP_STONEY) {
+   for (bank = 1; bank <= 4; bank++)
+   acp_set_sram_bank_state(intr_data->acp_mmio,
+   bank, true);
+   }
} else {
intr_data->capture_stream = substream;
-   for (bank = 5; bank <= 8; bank++)
-   acp_set_sram_bank_state(intr_data->acp_mmio, bank,
-   true);
+   if (intr_data->asic_type != CHIP_STONEY) {
+   for (bank = 5; bank <= 8; bank++)
+   acp_set_sram_bank_state(intr_data->acp_mmio,
+   bank, true);
+   }
}
 
return 0;
@@ -869,14 +882,23 @@ static int acp_dma_close(struct snd_pcm_substream 
*substream)
 
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
adata->play_stream = NULL;
-   for (bank = 1; bank <= 4; bank++)
-   acp_set_sram_bank_state(adata->acp_mmio, bank,
-   false);
-   } else {
+   /* For Stoney, Memory gating is disabled,i.e SRAM Banks
+* won't be turned off. The default state for SRAM banks is ON.
+* Setting SRAM bank state code skipped for STONEY platform.
+* added condition checks for Carrizo platform only
+*/
+   if (adata->asic_type != CHIP_STONEY) {
+   for (bank = 1; bank <= 4; bank++)
+   acp_set_sram_bank_state(adata->acp_mmio, bank,
+   false);
+   }
+   } else  {
adata->capture_stream = NULL;
-   for (bank = 5; bank <= 8; bank++)
-   acp_set_sram_bank_state(adata->acp_mmio, bank,
-   false);
+   if (adata->asic_type != CHIP_STONEY) {
+   for (bank = 5; bank <= 8; bank++)
+   acp_set_sram_bank_state(adata->acp_mmio, bank,
+false);
+   }
}
 
/* Disable ACP irq, when the current stream 

[PATCH 1/6 v3] drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data

[Alex Deucher]

From: Vijendar Mukunda 

asic_type information is passed to ACP DMA Driver as platform data.

Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
---

v2: Removed asic_type local variable and directly passing asic_type
instance to ACP DMA driver as platform data.
v3: Add R-b, resend.

drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 2 ++
 sound/soc/amd/acp-pcm-dma.c | 8 ++--
 sound/soc/amd/acp.h | 7 +++
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index a52795d..ebca223 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -371,6 +371,8 @@ static int acp_hw_init(void *handle)
adev->acp.acp_cell[0].name = "acp_audio_dma";
adev->acp.acp_cell[0].num_resources = 4;
adev->acp.acp_cell[0].resources = &adev->acp.acp_res[0];
+   adev->acp.acp_cell[0].platform_data = &adev->asic_type;
+   adev->acp.acp_cell[0].pdata_size = sizeof(adev->asic_type);
 
adev->acp.acp_cell[1].name = "designware-i2s";
adev->acp.acp_cell[1].num_resources = 1;
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 08b1399..dcbf997 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -73,12 +73,6 @@ static const struct snd_pcm_hardware 
acp_pcm_hardware_capture = {
.periods_max = CAPTURE_MAX_NUM_PERIODS,
 };
 
-struct audio_drv_data {
-   struct snd_pcm_substream *play_stream;
-   struct snd_pcm_substream *capture_stream;
-   void __iomem *acp_mmio;
-};
-
 static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg)
 {
return readl(acp_mmio + (reg * 4));
@@ -916,6 +910,7 @@ static int acp_audio_probe(struct platform_device *pdev)
int status;
struct audio_drv_data *audio_drv_data;
struct resource *res;
+   const u32 *pdata = pdev->dev.platform_data;
 
audio_drv_data = devm_kzalloc(&pdev->dev, sizeof(struct audio_drv_data),
GFP_KERNEL);
@@ -932,6 +927,7 @@ static int acp_audio_probe(struct platform_device *pdev)
 
audio_drv_data->play_stream = NULL;
audio_drv_data->capture_stream = NULL;
+   audio_drv_data->asic_type =  *pdata;
 
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 330832e..28cf914 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -84,6 +84,13 @@ struct audio_substream_data {
void __iomem *acp_mmio;
 };
 
+struct audio_drv_data {
+   struct snd_pcm_substream *play_stream;
+   struct snd_pcm_substream *capture_stream;
+   void __iomem *acp_mmio;
+   u32 asic_type;
+};
+
 enum {
ACP_TILE_P1 = 0,
ACP_TILE_P2,
-- 
2.5.5

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

[PATCH 6/6 v4] ASoC: AMD: Add machine driver for cz rt5650

[Alex Deucher]

From: Akshu Agrawal 

The driver is used for AMD board using rt5650 codec.

Reviewed-by: Alex Deucher 
Signed-off-by: Akshu Agrawal 
Signed-off-by: Alex Deucher 
Signed-off-by: Dylan Reid 
---

v2: Change ACPI ID to AMDI1002
v3: add R-b, resend
v4: Fix audio jack issue (Dylan Reid)
Fix Kconfig
Use devm_snd_soc_register_card
Add MODULE_DEVICE_TABLE

 sound/soc/amd/Kconfig  |   7 ++
 sound/soc/amd/Makefile |   2 +
 sound/soc/amd/acp-rt5645.c | 199 +
 3 files changed, 208 insertions(+)
 create mode 100644 sound/soc/amd/acp-rt5645.c

diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
index 78187eb..d583840 100644
--- a/sound/soc/amd/Kconfig
+++ b/sound/soc/amd/Kconfig
@@ -2,3 +2,10 @@ config SND_SOC_AMD_ACP
tristate "AMD Audio Coprocessor support"
help
 This option enables ACP DMA support on AMD platform.
+
+config SND_SOC_AMD_CZ_RT5645_MACH
+   tristate "AMD CZ support for RT5645"
+   select SND_SOC_RT5645
+   depends on SND_SOC_AMD_ACP && I2C
+   help
+This option enables machine driver for rt5645.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index 1a66ec0..eed64ff 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,3 +1,5 @@
 snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
 obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-rt5645.c b/sound/soc/amd/acp-rt5645.c
new file mode 100644
index 000..941aed6
--- /dev/null
+++ b/sound/soc/amd/acp-rt5645.c
@@ -0,0 +1,199 @@
+/*
+ * Machine driver for AMD ACP Audio engine using Realtek RT5645 codec
+ *
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * This file is modified from rt288 machine driver
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../codecs/rt5645.h"
+
+#define CZ_PLAT_CLK 2400
+
+static struct snd_soc_jack cz_jack;
+
+static int cz_aif1_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   int ret = 0;
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *codec_dai = rtd->codec_dai;
+
+   ret = snd_soc_dai_set_pll(codec_dai, 0, RT5645_PLL1_S_MCLK,
+ CZ_PLAT_CLK, params_rate(params) * 512);
+   if (ret < 0) {
+   dev_err(rtd->dev, "can't set codec pll: %d\n", ret);
+   return ret;
+   }
+
+   ret = snd_soc_dai_set_sysclk(codec_dai, RT5645_SCLK_S_PLL1,
+   params_rate(params) * 512, SND_SOC_CLOCK_OUT);
+   if (ret < 0) {
+   dev_err(rtd->dev, "can't set codec sysclk: %d\n", ret);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int cz_init(struct snd_soc_pcm_runtime *rtd)
+{
+   int ret;
+   struct snd_soc_card *card;
+   struct snd_soc_codec *codec;
+
+   codec = rtd->codec;
+   card = rtd->card;
+
+   ret = snd_soc_card_jack_new(card, "Headset Jack",
+   SND_JACK_HEADPHONE | SND_JACK_MICROPHONE |
+   SND_JACK_BTN_0 | SND_JACK_BTN_1 |
+   SND_JACK_BTN_2 | SND_JACK_BTN_3,
+   &cz_jack, NULL, 0);
+   if (ret) {
+   dev_err(card->dev, "HP jack creation failed %d\n", ret);
+   return ret;
+   }
+
+   rt5645_set_jack_detect(codec, &cz_jack, &cz_jack, &cz_jack);
+
+   return 0;
+}
+
+static struct snd_soc_ops cz_aif1_ops = {
+   .hw_params = cz_aif1_hw_params,
+};
+
+static struct snd_soc_dai_link cz_dai_rt5650[] = {
+   {
+   .name = "amd-rt5645-play",

[PATCH 5/6 v4] ASoC: AMD: Audio buffer related changes for Stoney

[Alex Deucher]

From: Vijendar Mukunda 

Stoney uses 16kb SRAM memory for playback and 16Kb
for capture.Modified Max buffer size to have the
correct mapping between System Memory and SRAM.

Added snd_pcm_hardware structures for playback
and capture for Stoney.

Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
---

v2: Added switch cases for asic type.
v3: add R-b, resend
v4: use switch case for buffer allocation
Modify period size macros for Stoney
Whitespace fixes

 sound/soc/amd/acp-pcm-dma.c | 83 ++---
 1 file changed, 78 insertions(+), 5 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index f16e0b8..73b58ee 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -35,6 +35,11 @@
 #define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define MIN_BUFFER MAX_BUFFER
 
+#define ST_PLAYBACK_MAX_PERIOD_SIZE 8192
+#define ST_CAPTURE_MAX_PERIOD_SIZE  ST_PLAYBACK_MAX_PERIOD_SIZE
+#define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
+#define ST_MIN_BUFFER ST_MAX_BUFFER
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -73,6 +78,44 @@ static const struct snd_pcm_hardware 
acp_pcm_hardware_capture = {
.periods_max = CAPTURE_MAX_NUM_PERIODS,
 };
 
+static const struct snd_pcm_hardware acp_st_pcm_hardware_playback = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+   .channels_min = 1,
+   .channels_max = 8,
+   .rates = SNDRV_PCM_RATE_8000_96000,
+   .rate_min = 8000,
+   .rate_max = 96000,
+   .buffer_bytes_max = ST_MAX_BUFFER,
+   .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
+   .period_bytes_max = ST_PLAYBACK_MAX_PERIOD_SIZE,
+   .periods_min = PLAYBACK_MIN_NUM_PERIODS,
+   .periods_max = PLAYBACK_MAX_NUM_PERIODS,
+};
+
+static const struct snd_pcm_hardware acp_st_pcm_hardware_capture = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+   .channels_min = 1,
+   .channels_max = 2,
+   .rates = SNDRV_PCM_RATE_8000_48000,
+   .rate_min = 8000,
+   .rate_max = 48000,
+   .buffer_bytes_max = ST_MAX_BUFFER,
+   .period_bytes_min = CAPTURE_MIN_PERIOD_SIZE,
+   .period_bytes_max = ST_CAPTURE_MAX_PERIOD_SIZE,
+   .periods_min = CAPTURE_MIN_NUM_PERIODS,
+   .periods_max = CAPTURE_MAX_NUM_PERIODS,
+};
+
 static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg)
 {
return readl(acp_mmio + (reg * 4));
@@ -664,10 +707,23 @@ static int acp_dma_open(struct snd_pcm_substream 
*substream)
if (adata == NULL)
return -ENOMEM;
 
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
-   runtime->hw = acp_pcm_hardware_playback;
-   else
-   runtime->hw = acp_pcm_hardware_capture;
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   switch (intr_data->asic_type) {
+   case CHIP_STONEY:
+   runtime->hw = acp_st_pcm_hardware_playback;
+   break;
+   default:
+   runtime->hw = acp_pcm_hardware_playback;
+   }
+   } else {
+   switch (intr_data->asic_type) {
+   case CHIP_STONEY:
+   runtime->hw = acp_st_pcm_hardware_capture;
+   break;
+   default:
+   runtime->hw = acp_pcm_hardware_capture;
+   }
+   }
 
ret = snd_pcm_hw_constraint_integer(runtime,
SNDRV_PCM_HW_PARAM_PERIODS);
@@ -905,10 +961,27 @@ static int acp_dma_trigger(struct snd_pcm_substream 
*substream, int cmd)
 
 static int acp_dma_new(struct snd_soc_pcm_runtime *rtd)
 {
-   return snd_pcm_lib_preallocate_pages_for_all(rtd->pcm,
+   int ret;
+   struct audio_drv_data *adata = dev_get_drvdata(rtd->platform->dev);
+
+   switch (adata->asic_type) {
+   case CHIP_STONEY:
+   ret = snd_pcm_lib_preallocate_pages_for_all(rtd->pcm,
+   SNDRV_DMA_TYPE_DEV,
+   NULL, ST_MIN_BUFFER,
+   

[PATCH 4/6 v3] ASoC: AMD: DMA driver changes for Stoney Platform

[Alex Deucher]

From: Vijendar Mukunda 

Added DMA driver changes for Stoney platform.
Below are the key differences between Stoney and CZ

In Stoney, Memory Gating is disabled.SRAM Banks won't
be turned off.No Of SRAM Banks reduced to 6.
DAGB Garlic Interface used and 16 bit resolution is supported.
SRAM bank 1 & SRAM bank 2 will be used for playback scenario.
SRAM Bank 3 & SRAM Bank 4 will be used for Capture scenario.

Acked-by: Mark Brown 
Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
---

v2: Added switch cases for asic type.
v3: Add R-b, resend
v4: Add Mark's Ack

 sound/soc/amd/acp-pcm-dma.c | 87 +
 sound/soc/amd/acp.h |  2 ++
 2 files changed, 67 insertions(+), 22 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index f00b6b9..f16e0b8 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -137,8 +137,8 @@ static void config_dma_descriptor_in_sram(void __iomem 
*acp_mmio,
  * system memory <-> ACP SRAM
  */
 static void set_acp_sysmem_dma_descriptors(void __iomem *acp_mmio,
-  u32 size, int direction,
-  u32 pte_offset)
+   u32 size, int direction,
+   u32 pte_offset, u32 asic_type)
 {
u16 i;
u16 dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
@@ -152,20 +152,42 @@ static void set_acp_sysmem_dma_descriptors(void __iomem 
*acp_mmio,
(size / 2) - (i * (size/2));
dmadscr[i].src = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS
+ (pte_offset * SZ_4K) + (i * (size/2));
-   dmadscr[i].xfer_val |=
-   (ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM << 16) |
-   (size / 2);
+   switch (asic_type) {
+   case CHIP_STONEY:
+   dmadscr[i].xfer_val |=
+   (ACP_DMA_ATTRIBUTES_DAGB_GARLIC_TO_SHAREDMEM  
<< 16) |
+   (size / 2);
+   break;
+   default:
+   dmadscr[i].xfer_val |=
+   (ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM  << 
16) |
+   (size / 2);
+   }
} else {
dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14 + i;
-   dmadscr[i].src = ACP_SHARED_RAM_BANK_5_ADDRESS +
-   (i * (size/2));
-   dmadscr[i].dest = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS
-   + (pte_offset * SZ_4K) +
-   (i * (size/2));
-   dmadscr[i].xfer_val |=
-   BIT(22) |
-   (ACP_DMA_ATTRIBUTES_SHAREDMEM_TO_DAGB_ONION << 16) |
-   (size / 2);
+   switch (asic_type) {
+   case CHIP_STONEY:
+   dmadscr[i].src = ACP_SHARED_RAM_BANK_3_ADDRESS +
+   (i * (size/2));
+   dmadscr[i].dest =
+   ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS +
+   (pte_offset * SZ_4K) + (i * (size/2));
+   dmadscr[i].xfer_val |=
+   BIT(22) |
+   (ACP_DMA_ATTRIBUTES_SHARED_MEM_TO_DAGB_GARLIC 
<< 16) |
+   (size / 2);
+   break;
+   default:
+   dmadscr[i].src = ACP_SHARED_RAM_BANK_5_ADDRESS +
+   (i * (size/2));
+   dmadscr[i].dest =
+   ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS +
+   (pte_offset * SZ_4K) + (i * (size/2));
+   dmadscr[i].xfer_val |=
+   BIT(22) |
+   (ACP_DMA_ATTRIBUTES_SHAREDMEM_TO_DAGB_ONION << 
16) |
+   (size / 2);
+   }
}
config_dma_descriptor_in_sram(acp_mmio, dma_dscr_idx,
&dmadscr[i]);
@@ -186,7 +208,8 @@ static void set_acp_sysmem_dma_descriptors(void __iomem 
*acp_mmio,
  * ACP SRAM <-> I2S
  */
 static void set_acp_to_i2s_dma_descriptors(void __iomem *acp_mmio,
-  u32 size, int direction)
+   u32 size, int direction,
+   u32 asic_type)
 {
 
u16 i;
@@ -207,8 +230,17 @@ static vo

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

[David Miller]

From: Allen Pais 
Date: Wed, 13 Sep 2017 13:02:15 +0530

> Signed-off-by: Allen Pais 

This is quite pointless as the caller doesn't do anything with
the value, it just tests whether a negative value is returned
or not.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102655] [CI][HSW] igt@gem_flink_race@flink_close - Failed assertion: obj_count == 0

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

 CC||marta.lofst...@intel.com

--- Comment #3 from Chris Wilson  ---
*** Bug 102696 has been marked as a duplicate of this bug. ***

-- 
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 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

[Noralf Trønnes]

Den 13.09.2017 07.09, skrev Laurent Pinchart:

Hi Noralf,

Thank you for the patches.

On Monday, 11 September 2017 17:31:54 EEST Noralf Trønnes wrote:

Hi,

I want to start out by saying that this patchset is low priority for me
and if no one has interest or time to review this, that is just fine. I
was in the flow and just typed it out.

This patchset adds a way for fbdev emulation code to create a
framebuffer that is backed by a dumb buffer. drm_fb_helper gets a
drm_file to hang the objects on, drm_framebuffer_create_dumb() creates
the framebuffer and drm_fb_helper_fini() destroys it.
I have verified that all cma drivers supports dumb buffers, so
converting the library should be fine for all.

Stupid question, what does this give us ? The series makes the call stack more
complex (up to a point where I'm getting trouble just following it), what's
the advantage that offsets that ?


The short answer is that it avoids the need for special fbdev
_with_funcs() functions in libraries like cma for framebuffers with the
dirty callback set.

I'm suprised that you think this more complex, I find it more coherent
when fbdev userspace is doing things more like DRM userspace, like
hanging the objects on a drm_file and cleaning up the objects when done.

The longer and more diffuse answer is that it's annoying me that many
drivers carry the burden of fbdev emulation just to get a console!
And an in-kernel drm console, as David Herrmann described it a year ago,
would allocate a framebuffer using something like what I have done here.
But maybe it's better to do this the other way around: first get the
drm console and then let fbdev use the same mechanisms. Or maybe at that
point, just forget about fbdev and not spend any more time on it :-)

Sidenote:
Do you if any DRM drivers is capable of showing kernel oops'es on the
console?


With the exception of vmwgfx that does weird things I won't even try to
understand, all drivers seem to use the drm_file object passed to the
.dumb_create() operation just to register the GEM object handle. I wonder
whether a better solution to use .dumb_create() for framebuffer emulation
wouldn't be to move the GEM object handle registration from the .dumb_create()
implementation to its caller in the core.


Can you elaborate what you mean by this?

Noralf.


A patch by David Herrmann from a year ago made this easy. It was the
last piece in his work to make it possible to create a drm_file for
in-kernel use, but it never got merged.

I've cc'ed intel-gfx since that will give CI runs of the core patches if
I understood Daniel right.

Noralf.

David Herrmann (1):
   drm: provide management functions for drm_file

Noralf Trønnes (7):
   drm/framebuffer: Add drm_framebuffer_create_dumb()
   drm/auth: Export drm_dropmaster_ioctl()
   drm/fb-helper: Allocate a drm_file
   drm/fb-cma-helper: Use drm_framebuffer_create_dumb()
   drm/fb-cma-helper: Drop unnecessary fbdev buffer offset
   drm/tinydrm: Use drm_fbdev_cma_init()
   drm/fb-cma-helper: Remove drm_fbdev_cma_init_with_funcs()

  drivers/gpu/drm/drm_auth.c  |   1 +
  drivers/gpu/drm/drm_fb_cma_helper.c | 111 ++
  drivers/gpu/drm/drm_fb_helper.c |  22 +-
  drivers/gpu/drm/drm_file.c  | 323 +++--
  drivers/gpu/drm/drm_framebuffer.c   |  61 ++
  drivers/gpu/drm/drm_internal.h  |   2 -
  drivers/gpu/drm/tinydrm/core/tinydrm-core.c |   5 +-
  include/drm/drm_auth.h  |   2 +
  include/drm/drm_fb_helper.h |   9 +
  include/drm/drm_file.h  |   2 +
  include/drm/drm_framebuffer.h   |   4 +
  11 files changed, 305 insertions(+), 237 deletions(-)


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

Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation

[Joe Perches]

On Wed, 2017-09-13 at 13:02 +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais 

I think the changelog for this series of conversions
should show that you've validated the change by
inspecting the return call chain at each modified line.

Also, it seems you've cc'd the same mailing lists for
all of the patches modified by this series.

It would be better to individually address each patch
in the series only cc'ing the appropriate maintainers
and mailing lists.

A cover letter would be good too.

> ---
>  arch/powerpc/platforms/cell/spider-pci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/cell/spider-pci.c 
> b/arch/powerpc/platforms/cell/spider-pci.c
> index d1e61e2..82aa3f7 100644
> --- a/arch/powerpc/platforms/cell/spider-pci.c
> +++ b/arch/powerpc/platforms/cell/spider-pci.c
> @@ -106,7 +106,7 @@ static int __init spiderpci_pci_setup_chip(struct 
> pci_controller *phb,
>   dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
>   if (!dummy_page_va) {
>   pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
> - return -1;
> + return -ENOMEM;
>   }
>  
>   dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
> @@ -137,7 +137,7 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void 
> *data)
>   if (!priv) {
>   pr_err("SPIDERPCI-IOWA:"
>  "Can't allocate struct spiderpci_iowa_private");
> - return -1;
> + return -ENOMEM;
>   }
>  
>   if (of_address_to_resource(np, 0, &r)) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4 21/23] drm/etnaviv: need to disable clock gating when doing profiling

[Christian Gmeiner]

Hi Lucas

2017-09-13 13:05 GMT+02:00 Lucas Stach :
> Am Dienstag, den 12.09.2017, 17:11 +0200 schrieb Christian Gmeiner:
>> As done by Vivante kernel driver.
>
> You need to move the VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS from
> etnaviv_gpu_update_clock to the GPU init path. Otherwise a thermal
> throttling request may disable the debug registers again, while the
> profiled commandstream is in flight on the GPU.
>

Will be fixed in next version.

> Regards,
> Lucas
>
>> Signed-off-by: Christian Gmeiner 
>> Reviewed-by: Lucas Stach 
>> ---
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index 842b6642dcd6..04acc3a64c3c 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -1341,6 +1341,13 @@ static void sync_point_perfmon_sample(struct 
>> etnaviv_gpu *gpu,
>>  static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
>>   struct etnaviv_event *event)
>>  {
>> + u32 val;
>> +
>> + /* disable clock gating */
>> + val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
>> + val &= ~VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
>> + gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
>> +
>>   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
>>  }
>>
>> @@ -1349,6 +1356,7 @@ static void sync_point_perfmon_sample_post(struct 
>> etnaviv_gpu *gpu,
>>  {
>>   const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
>>   unsigned int i;
>> + u32 val;
>>
>>   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
>>
>> @@ -1357,6 +1365,11 @@ static void sync_point_perfmon_sample_post(struct 
>> etnaviv_gpu *gpu,
>>
>>   *pmr->bo_vma = pmr->sequence;
>>   }
>> +
>> + /* enable clock gating */
>> + val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
>> + val |= VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
>> + gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
>>  }
>>
>>
>
>

greets
--
Christian Gmeiner, MSc

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

Re: [PATCH V4 12/23] drm/etnaviv: use 'sync points' for performance monitor requests

[Christian Gmeiner]

Hi Lucas


2017-09-13 13:03 GMT+02:00 Lucas Stach :
> Am Dienstag, den 12.09.2017, 17:11 +0200 schrieb Christian Gmeiner:
>> With 'sync points' we can sample the reqeustes perform signals
>> before and/or after the submited command buffer.
>>
>> Changes v2 -> v3:
>> - fixed indentation and init nr_events to 1
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 102 
>> +++---
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h |   1 +
>>  2 files changed, 83 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index b65d7b9d247a..842b6642dcd6 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -1324,12 +1324,48 @@ void etnaviv_gpu_pm_put(struct etnaviv_gpu *gpu)
>>   pm_runtime_put_autosuspend(gpu->dev);
>>  }
>>
>> +static void sync_point_perfmon_sample(struct etnaviv_gpu *gpu,
>> + struct etnaviv_event *event, unsigned int flags)
>> +{
>> + const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
>> + unsigned int i;
>> +
>> + for (i = 0; i < cmdbuf->nr_pmrs; i++) {
>> + const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
>> +
>> + if (pmr->flags == flags)
>> + etnaviv_perfmon_process(gpu, pmr);
>> + }
>> +}
>> +
>> +static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
>> + struct etnaviv_event *event)
>> +{
>> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
>> +}
>> +
>> +static void sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
>> + struct etnaviv_event *event)
>> +{
>> + const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
>> + unsigned int i;
>> +
>> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
>> +
>> + for (i = 0; i < cmdbuf->nr_pmrs; i++) {
>> + const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
>> +
>> + *pmr->bo_vma = pmr->sequence;
>> + }
>> +}
>> +
>> +
>>  /* add bo's to gpu's ring, and kick gpu: */
>>  int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>>   struct etnaviv_gem_submit *submit, struct etnaviv_cmdbuf *cmdbuf)
>>  {
>>   struct dma_fence *fence;
>> - unsigned int event, i;
>> + unsigned int i, nr_events = 1, event[3];
>>   int ret;
>>
>>   ret = etnaviv_gpu_pm_get_sync(gpu);
>> @@ -1345,9 +1381,19 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>>*
>>*/
>>
>> - ret = event_alloc(gpu, 1, &event);
>> + /*
>> +  * if there are performance monitor requests we need to have
>> +  * - a sync point to re-configure gpu and process ETNA_PM_PROCESS_PRE
>> +  *   requests.
>> +  * - a sync point to re-configure gpu, process ETNA_PM_PROCESS_POST 
>> requests
>> +  *   and update the sequence number for userspace.
>> +  */
>> + if (cmdbuf->nr_pmrs)
>> + nr_events = 3;
>> +
>> + ret = event_alloc(gpu, nr_events, event);
>>   if (ret) {
>> - DRM_ERROR("no free event\n");
>> + DRM_ERROR("no free events\n");
>>   goto out_pm_put;
>>   }
>>
>> @@ -1355,12 +1401,14 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>>
>>   fence = etnaviv_gpu_fence_alloc(gpu);
>>   if (!fence) {
>> - event_free(gpu, event);
>> + for (i = 0; i < nr_events; i++)
>> + event_free(gpu, event[i]);
>> +
>>   ret = -ENOMEM;
>>   goto out_unlock;
>>   }
>>
>> - gpu->event[event].fence = fence;
>> + gpu->event[event[0]].fence = fence;
>>   submit->fence = dma_fence_get(fence);
>>   gpu->active_fence = submit->fence->seqno;
>>
>> @@ -1370,7 +1418,19 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>>   gpu->lastctx = cmdbuf->ctx;
>>   }
>>
>> - etnaviv_buffer_queue(gpu, event, cmdbuf);
>> + if (cmdbuf->nr_pmrs) {
>> + gpu->event[event[1]].sync_point = 
>> &sync_point_perfmon_sample_pre;
>> + gpu->event[event[1]].cmdbuf = cmdbuf;
>> + etnaviv_sync_point_queue(gpu, event[1]);
>> + }
>> +
>> + etnaviv_buffer_queue(gpu, event[0], cmdbuf);
>> +
>> + if (cmdbuf->nr_pmrs) {
>> + gpu->event[event[2]].sync_point = 
>> &sync_point_perfmon_sample_post;
>> + gpu->event[event[2]].cmdbuf = cmdbuf;
>> + etnaviv_sync_point_queue(gpu, event[2]);
>> + }
>>
>>   cmdbuf->fence = fence;
>>   list_add_tail(&cmdbuf->node, &gpu->active_cmd_list);
>> @@ -1475,20 +1535,22 @@ static irqreturn_t irq_handler(int irq, void *data)
>>   }
>>
>>   fence = gpu->event[event].fence;
>> - gpu->event[event].fence = NULL;
>> - dma_fence_signal(fence);
>> -
>> - /*
>> -  * Events can be processed out of order.  Eg,
>> 

Re: [PATCH 00/23] drm/etnaviv: support performance counters

[Christian Gmeiner]

Hi Lucas

2017-09-13 13:01 GMT+02:00 Lucas Stach :
> Am Dienstag, den 12.09.2017, 17:11 +0200 schrieb Christian Gmeiner:
>> In a perfect world we would be able to read GPU registers of interest
>> via the command stream with a 'read-register' command/package. For perf
>> counters it is a must to read them synchronized with the GPU to put the
>> values in relation to a draw command. As Vivante GPUs do not provide this
>> functionality we need to emulate it in software.
>>
>>
>> We need to support three different kind of perf register types:
>>
>> 1) normal register
>>   This is the easierst case where we can simply read the register and we
>>   are done.
>>
>> 2) debug register
>>   We need to configure the mux register and then read the debug register 
>> value.
>>
>> 3) pipeline register
>>   We need to 'iterate' over all pixel pipes and sum up the values. The 
>> 'iteration'
>>   is done by select the pipe of interest via 
>> HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE.
>>   There is also need to configure the mux register.
>>
>>
>> Allowing the userspace to do it all by its own feels quite error prone and 
>> not
>> future-proof. Thats why the kernel exports all performance domains and their
>> signals to the userspace via two new ioctls. So the kernel knows all 
>> performance
>> counters and how to sample them.
>>
>> At the moment all performacne domains and signals get exported to all gpu 
>> pipe types,
>> but that can be changed in follow-up patches.
>
> Okay, after testing the V4 patches I'm convinced that we need this
> filter _before_ any of this can go in.
>

Will integrate this in the next version of this series.

> At least on GC3000 profiling the PE counters wastes the GPU bad enough
> that not even our regular GPU recovery mechanism is able to get it back
> to life. This is a trivial DOS vector, which we simply can't allow in
> the kernel driver. For this to go in, we need some way to only export
> the counters, which are _tested_ to be safe on the hardware.
>

I have tested all exported counters on a GC2000 with glxgears - one
perf counter for each glxgears
run. I have not seen any GPU hangs or similar. Will redo this 'testing
procedure on a GC3000.

Thanks for review :)

greets
--
Christian Gmeiner, MSc

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Christian König]

Am 13.09.2017 um 16:06 schrieb Marek Olšák:

On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing)
 wrote:

For android using mesa instance, egl draw will dequeue an android buffer,
after egl draw, the buffer will back to android bufffer queue, but need
append a syncfile fd. If getting syncfile fd for every egl draw always needs
several syncobj ioctls, the io overhead isn't small. But if we directly
return syncfile when egl draw CS,  isn't it better?

You have a good point. I'd be OK with either approach, or even with
having both options in the kernel.


I don't have a strong opinion for the CS IOCTL either. If it saves us an 
extra IOCTL when we directly return a syncfile fd then why not?


But we really shouldn't use syncfile for the VA IOCTL. That's nothing we 
want to share with other processes and the returned fence or sequence 
needs to be lightweight.


Ideally I would say it should be a sequence number, so that you can say 
max(seq1, seq2) and always have the latest.


The next best approach I think would be to use syncobj, cause it is 
simply rather easily to implement.


Christian.



Marek



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

[PATCH libdrm v3] etnaviv: prevent deadlock in error path

[Philipp Zabel]

If drmPrimeFDToHandle fails in etna_bo_from_dmabuf, the function must
not return with the table_lock mutex held. Unlock the mutex in the error
path.

Based on ceb70a6b1015 ("freedreno: prevent deadlock in error path").

Signed-off-by: Philipp Zabel 
Reviewed-by: Eric Engestrom 
---
v3: fix the commit message to correspond to the code in v2/v3
---
 etnaviv/etnaviv_bo.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/etnaviv/etnaviv_bo.c b/etnaviv/etnaviv_bo.c
index 4fe877f1..78b9cd27 100644
--- a/etnaviv/etnaviv_bo.c
+++ b/etnaviv/etnaviv_bo.c
@@ -206,10 +206,15 @@ struct etna_bo *etna_bo_from_dmabuf(struct etna_device 
*dev, int fd)
int ret, size;
uint32_t handle;
 
+   /* take the lock before calling drmPrimeFDToHandle to avoid
+* racing against etna_bo_del, which might invalidate the
+* returned handle.
+*/
pthread_mutex_lock(&table_lock);
 
ret = drmPrimeFDToHandle(dev->fd, fd, &handle);
if (ret) {
+   pthread_mutex_unlock(&table_lock);
return NULL;
}
 
-- 
2.11.0

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Marek Olšák]

On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing)
 wrote:
> For android using mesa instance, egl draw will dequeue an android buffer,
> after egl draw, the buffer will back to android bufffer queue, but need
> append a syncfile fd. If getting syncfile fd for every egl draw always needs
> several syncobj ioctls, the io overhead isn't small. But if we directly
> return syncfile when egl draw CS,  isn't it better?

You have a good point. I'd be OK with either approach, or even with
having both options in the kernel.

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Ville Syrjälä]

On Wed, Sep 13, 2017 at 01:55:34PM +0200, Maarten Lankhorst wrote:
> Op 13-09-17 om 13:48 schreef Ville Syrjälä:
> > On Wed, Sep 13, 2017 at 12:46:47PM +0200, Maarten Lankhorst wrote:
> >> Op 13-09-17 om 12:37 schreef Ville Syrjälä:
> >>> On Wed, Sep 13, 2017 at 09:32:40AM +0200, Maarten Lankhorst wrote:
>  Op 12-09-17 om 22:11 schreef Pandiyan, Dhinakaran:
> > On Tue, 2017-09-12 at 19:08 +, Pandiyan, Dhinakaran wrote:
> >> On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> >>> On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
>  On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message 
> > trasactions to
> > set power states for downstream sinks. Apart from giving us the 
> > ability
> > to set power state for individual sinks, this fixes the below test 
> > for
> > me
> >
> > $ xrandr --display :0 --output DP-2-2-8 --off
> > $ xrandr --display :0 --output DP-2-2-1 --off
> > $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> > $ xrandr --display :0 --output DP-2-2-1 --auto
> >
> > Cc: Ville Syrjälä 
> > Cc: Lyude 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c| 6 --
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
> >  2 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 1da3bb2cc4b4..8aebacc0aa31 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> >  
> > intel_ddi_init_dp_buf_reg(encoder);
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > +   if (!link_mst)
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > intel_dp_start_link_train(intel_dp);
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
> > intel_encoder *intel_encoder,
> > if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >  
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > +   if (old_crtc_state && old_conn_state)
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>  I would make that
>  !intel_crtc_has_type(DP_MST)
> 
> > old_crtc_state, which intel_crtc_has_type() needs, is NULL for MST and
> > the reason Maarten provided in his commit is
> >
> > " We also shouldn't pass crtc_state, because in that case the
> >   disabling sequence may potentially be different depending on
> >   which crtc is disabled last. Nice way to introduce bugs.
> > "
> > I am not 100% sure I understand the concern. But since that change was
> > intentional I guess we can use the NULL values, like I've done, to
> > identify the mst sinks. I am open to ideas.
>  I think checking for NULL crtc_state is enough, in case we ever decide 
>  to pass the real connector state.
>  For clarity, I would add something like bool is_dsp_mst = !crtc_state; 
>  /* When enabling the link for MST, this connector is never bound to a 
>  crtc */.
> >>> The NULL state is rather ugly IMO. With a comment I might be able to
> >>> stomach it. However, after another look I see that we already pass the
> >>> crtc state to ddi_pre_enable() from the MST code, so even just from a
> >>> symmetry POV it would make sense to pass it to ddi_post_disable as well.
> >>>
> >> It doesn't make sense to pass crtc_state, there's no guarantee that the 
> >> crtc_state
> >> from the same crtc is passed into first MST enable, and last MST disable.
> > Doesn't really matter. If they don't match sufficiently we've already
> > messed up somewhere.
> >
> > Ideally we should have some kind of separate state for the DP link, but
> > since we don't atm we just abuse the crtc state to contain the link
> > parameters.
> 
> Could we stuff it in the real DP's connector state, and then make sure we add 
> the master connector state?

Not sure we want a disabled connector to affect the entire thing. I was
thinking that maybe we want some kind of encoder state thing. Not really
sure.

At some point I did have the idea that maybe we could stick the main MST
connector into the state, and actually use that to turn on the link,
leaving

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Zhou, David(ChunMing)]

For android using mesa instance, egl draw will dequeue an android buffer, after 
egl draw, the buffer will back to android bufffer queue, but need append a 
syncfile fd. If getting syncfile fd for every egl draw always needs several 
syncobj ioctls, the io overhead isn't small. But if we directly return syncfile 
when egl draw CS,  isn't it better?


发自坚果 Pro

Christian K鰊ig  于 2017年9月13日 下午9:04写道：

syncfile indeed be a good way to pass fence for user space, which already is 
proved in Android and is upstreamed.
Not really. syncfile needs a file descriptor for each handle it generates, 
that's quite a show stopper if you want to use it in general.

Android syncfile are meant to be used for inter process sharing, but as command 
submission sequence number they are not such a good fit.

Mareks approach looks really good to me and we should follow that direction 
further.

Regards,
Christian.

Am 13.09.2017 um 14:25 schrieb Zhou, David(ChunMing):
Yes, to be comptibility, I kept both seq_no and syncfile fd in the patch set, 
you can take a look, which really is simpler and effective way.

syncfile indeed be a good way to pass fence for user space, which already is 
proved in Android and is upstreamed.

Regards,
David Zhou


发自坚果 Pro

Marek Ol?醟  于 2017年9月13日 下午8:06写道：

On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing)
 wrote:
> Could you describe how difficult to directly use CS syncfile fd in Mesa
> compared with concerting CS seq to syncfile fd via several syncobj ioctls?

It just simplifies things. Mesa primarily uses seq_no-based fences and
will continue to use them. We can't remove the seq_no fence code
because we have to keep Mesa compatible with older kernels.

The only possibilities are:
- Mesa gets both seq_no and sync_file from CS.
- Mesa only gets seq_no from CS.

I decided to take the simpler option. I don't know if there is a perf
difference between CS returning a sync_file and using a separate
ioctl, but it's probably insignificant since we already call 3 ioctls
per IB submission (BO list create+destroy, submit).

Marek

>
> Regards,
> David Zhou
>
> 发自坚果 Pro
>
> Marek Ol?醟  于 2017年9月13日 下午6:11写道：
>
> On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 
>  wrote:
>> Hi Marek,
>>
>> You're doing same things with me, see my "introduce syncfile as fence
>> reuturn" patch set, which makes things more simple, we just need to
>> directly
>> return syncfile fd to UMD when CS, then the fence UMD get will be always
>> syncfile fd, UMD don't need to construct ip_type/ip_instance/ctx_id/ring
>> any
>> more, which also can pass to dependency and syncobj as well.
>
> For simpler Mesa code, Mesa won't get a sync file from the CS ioctl.
>
> Marek



___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


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

Re: [PATCH v2 1/2] drm/gem-fb-helper: Cleanup docs

[Noralf Trønnes]

Hi Laurent,


Den 13.09.2017 04.44, skrev Laurent Pinchart:

Hi Noralf,

Thank you for the patch.

On Monday, 11 September 2017 19:37:44 EEST Noralf Trønnes wrote:

Make the docs read a little better.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---

Changes:
Addressed Daniel's comments.

  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index d54a083..e2ca002
100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -27,18 +27,21 @@
   * DOC: overview
   *
   * This library provides helpers for drivers that don't subclass
- * &drm_framebuffer and and use &drm_gem_object for their backing storage.
+ * &drm_framebuffer and use &drm_gem_object for their backing storage.
   *
   * Drivers without additional needs to validate framebuffers can simply use
- * drm_gem_fb_create() and everything is wired up automatically. But all -
* parts can be used individually.
+ * drm_gem_fb_create() and everything is wired up automatically. Other
drivers + * can use all parts independently.
   */

  /**
   * drm_gem_fb_get_obj() - Get GEM object for framebuffer
- * @fb: The framebuffer
+ * @fb: framebuffer
   * @plane: Which plane

Nitpicking, you should capitalize all entries or none.


   *
+ * No additional reference is taken beyond the one that the &drm_frambuffer
+ * already holds.
+ *
   * Returns the GEM object for given framebuffer.
   */
  struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb,
@@ -82,7 +85,7 @@ drm_gem_fb_alloc(struct drm_device *dev,

  /**
   * drm_gem_fb_destroy - Free GEM backed framebuffer
- * @fb: DRM framebuffer
+ * @fb: framebuffer
   *
   * Frees a GEM backed framebuffer with its backing buffer(s) and the
structure
* itself. Drivers can use this as their &drm_framebuffer_funcs->destroy
@@ -102,8 +105,8 @@
EXPORT_SYMBOL(drm_gem_fb_destroy);

  /**
   * drm_gem_fb_create_handle - Create handle for GEM backed framebuffer
- * @fb: DRM framebuffer
- * @file: drm file
+ * @fb: framebuffer
+ * @file: DRM file

I wonder why framebuffer doesn't need a DRM while file does :-)


Yes this is haphazard.
I think my problem is that I haven't been able to pick up a consistent
"signal" from the DRM subsystem when it comes to how documentation
should be written. Code patterns are fairly consistent and looks much
the same including variable names, but documentation is more or less
all over the place.

So I guess I need to come to grips with this, since this isn't the last
time I have to write documentation. I have to make myself some rules
that I can look at next time when all of this is forgotten.

Should description entries be Capitalized?
My gut feeling is that most DRM docs don't do that, but when humans
write for humans we do capatalize the start of sentences. So I guess
that's the natural thing to do.

Should DRM objects start with DRM in the argument doc entries?
'DRM device' is a given since the kernel has many types of devices, but
should we write 'DRM framebuffer' or 'Framebuffer'?

How descriptive should the descriptions be?
Let's take this example:

/**
 * drm_gem_fb_prepare_fb() - Prepare gem framebuffer
 * @plane: Which plane
 * @state: Plane state the fence will be attached to
 *
 * This can be used as the &drm_plane_helper_funcs.prepare_fb hook.
 *
 * This function checks if the plane FB has an dma-buf attached, extracts
 * the exclusive fence and attaches it to plane state for the atomic helper
 * to wait on.

Both the @state description and the body says that the fence will be
attached to the plane state. Would it be better to just say:
 * @state: Plane state

Another way to ask this is:
Should the documentation be terse or should it be repeating itself?

Then we have (copied from the cma library):
 * @plane: Which plane

Which is probably short for: The plane which we are operating/acting on.

More possibilities:
 * @plane: DRM plane
 * @plane: Plane
 * @plane: The plane for which a framebuffer is prepared for scanout

The text for the last one is also available when clicking on the
&drm_plane_helper_funcs.prepare_fb link, so it's repeating something
that is one click away.

I always get comments on my documentation, so it's clearly something I
need to find a way to improve.

Noralf.


   * @handle: handle created
   *
   * Drivers can use this as their &drm_framebuffer_funcs->create_handle
@@ -124,7 +127,7 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
   *  &drm_mode_config_funcs.fb_create
   *  callback
   * @dev: DRM device
- * @file: drm file for the ioctl call
+ * @file: DRM file for the ioctl call
   * @mode_cmd: metadata from the userspace fb creation request
   * @funcs: vtable to be used for the new framebuffer object
   *
@@ -194,7 +1

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

[bugzilla-daemon]

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

--- Comment #8 from Justin Mitzel  ---
Sure, could you link me directly to the one you wanted me to try?

-- 
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 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

--- Comment #6 from Takashi Iwai (ti...@suse.de) ---
(In reply to Takashi Iwai from comment #5)
> Isn't the plymouth hang the dup of bug 102338?

Erm, I meant the fdo bugzilla 102338,
  https://bugs.freedesktop.org/show_bug.cgi?id=102338

-- 
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 2/2] etnaviv: fix gem object list corruption

[Lucas Stach]

All manipulations of the gem_object list need to be protected by
the list mutex, as GEM objects can be created and freed in parallel.
This fixes a kernel memory corruption.

CC: sta...@vger.kernel.org
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 9a3bea738330..87b95eeedd9e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -551,12 +551,15 @@ static const struct etnaviv_gem_ops etnaviv_gem_shmem_ops 
= {
 void etnaviv_gem_free_object(struct drm_gem_object *obj)
 {
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
+   struct etnaviv_drm_private *priv = obj->dev->dev_private;
struct etnaviv_vram_mapping *mapping, *tmp;
 
/* object should not be active */
WARN_ON(is_active(etnaviv_obj));
 
+   mutex_lock(&priv->gem_lock);
list_del(&etnaviv_obj->gem_node);
+   mutex_unlock(&priv->gem_lock);
 
list_for_each_entry_safe(mapping, tmp, &etnaviv_obj->vram_list,
 obj_node) {
-- 
2.11.0

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

[PATCH 1/2] etnaviv: fix submit error path

[Lucas Stach]

If the gpu submit fails, bail out to avoid accessing a potentially
unititalized fence.

CC: sta...@vger.kernel.org #4.12+
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 6463fc2c736f..b95362186f9c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -445,8 +445,10 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
cmdbuf->user_size = ALIGN(args->stream_size, 8);
 
ret = etnaviv_gpu_submit(gpu, submit, cmdbuf);
-   if (ret == 0)
-   cmdbuf = NULL;
+   if (ret)
+   goto out;
+
+   cmdbuf = NULL;
 
if (args->flags & ETNA_SUBMIT_FENCE_FD_OUT) {
/*
-- 
2.11.0

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Christian König]

syncfile indeed be a good way to pass fence for user space, which already is 
proved in Android and is upstreamed.
Not really. syncfile needs a file descriptor for each handle it 
generates, that's quite a show stopper if you want to use it in general.


Android syncfile are meant to be used for inter process sharing, but as 
command submission sequence number they are not such a good fit.


Mareks approach looks really good to me and we should follow that 
direction further.


Regards,
Christian.

Am 13.09.2017 um 14:25 schrieb Zhou, David(ChunMing):

Yes, to be comptibility, I kept both seq_no and syncfile fd in the patch set, 
you can take a look, which really is simpler and effective way.

syncfile indeed be a good way to pass fence for user space, which already is 
proved in Android and is upstreamed.

Regards,
David Zhou

发自坚果 Pro

Marek Ol?醟  于 2017年9月13日 下午8:06写道：

On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing)
 wrote:
> Could you describe how difficult to directly use CS syncfile fd in Mesa
> compared with concerting CS seq to syncfile fd via several syncobj 
ioctls?


It just simplifies things. Mesa primarily uses seq_no-based fences and
will continue to use them. We can't remove the seq_no fence code
because we have to keep Mesa compatible with older kernels.

The only possibilities are:
- Mesa gets both seq_no and sync_file from CS.
- Mesa only gets seq_no from CS.

I decided to take the simpler option. I don't know if there is a perf
difference between CS returning a sync_file and using a separate
ioctl, but it's probably insignificant since we already call 3 ioctls
per IB submission (BO list create+destroy, submit).

Marek

>
> Regards,
> David Zhou
>
> 发自坚果 Pro
>
> Marek Ol?醟  于 2017年9月13日 下午6:11写道：
>
> On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1  wrote:
>> Hi Marek,
>>
>> You're doing same things with me, see my "introduce syncfile as fence
>> reuturn" patch set, which makes things more simple, we just need to
>> directly
>> return syncfile fd to UMD when CS, then the fence UMD get will be 
always
>> syncfile fd, UMD don't need to construct 
ip_type/ip_instance/ctx_id/ring

>> any
>> more, which also can pass to dependency and syncobj as well.
>
> For simpler Mesa code, Mesa won't get a sync file from the CS ioctl.
>
> Marek


___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

[Bug 102694] Astrokill Beta: LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP* instruction uses the constant bus more than once

[bugzilla-daemon]

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

--- Comment #2 from Christoph Haag  ---
llvm-svn 312776 is okay, llvm-svn 312959 is broken.

-- 
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 102694] Astrokill Beta: LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP* instruction uses the constant bus more than once

[bugzilla-daemon]

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

--- Comment #1 from Christoph Haag  ---
Many applications are affected. CS:GO, Unigine Heaven, Unigine Valles, but not
Unigine Sanctuary.

So it's probably not something obscure but something recently introduced.

-- 
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 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

Takashi Iwai (ti...@suse.de) changed:

   What|Removed |Added

 CC||ti...@suse.de

--- Comment #5 from Takashi Iwai (ti...@suse.de) ---
Isn't the plymouth hang the dup of bug 102338?
If so, it's BUG_ON() in ttm_bo_kmap() for non-empty bo->swap list.

BTW, with the patch in comment 2 applied, qemu itself crashes on my machine,
not the VM :-<

id 0, group 0, virt start 0, virt end , generation 0, delta 0
id 1, group 1, virt start 7fec9680, virt end 7fec9a7fe000, generation 0,
delta 7fec9680
id 2, group 1, virt start 7fec9240, virt end 7fec9640, generation 0,
delta 7fec9240
((null):6072): Spice-Warning **: red_memslots.c:69:validate_virt: virtual
address out of range
virt=0x7fec96b07018+0xff00 slot_id=1 group_id=1
slot=0x7fec9680-0x7fec9a7fe000 delta=0x7fec9680
((null):6072): Spice-ERROR **: red_parse_qxl.c:334:red_get_clip_rects:
assertion `num_rects * sizeof(QXLRect) == size' failed
Thread 24 (Thread 0x7fec8189c700 (LWP 6097)):


-- 
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 05/10] drivers:net: return -ENOMEM on allocation failure.

[Andrew Lunn]

On Wed, Sep 13, 2017 at 01:02:14PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais 

Hi Allen

Although correct, if you look higher up the call chain, this appears
to be not so useful.

rlb_initialize() is only called by bond_alb_initialize(), and it
propagates the -1. That is only called by bond_open() with:

if (bond_alb_initialize(bond, (BOND_MODE(bond) == BOND_MODE_ALB)))
return -ENOMEM;

So you might want to also modify this code, to return the return
value, rather than use the hard coded ENOMEM.

Since you code is OK as far as it goes:

Reviewed-by: Andrew Lunn 

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Zhou, David(ChunMing)]

Yes, to be comptibility, I kept both seq_no and syncfile fd in the patch set, 
you can take a look, which really is simpler and effective way.

syncfile indeed be a good way to pass fence for user space, which already is 
proved in Android and is upstreamed.

Regards,
David Zhou


发自坚果 Pro

Marek Ol?醟  于 2017年9月13日 下午8:06写道：

On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing)
 wrote:
> Could you describe how difficult to directly use CS syncfile fd in Mesa
> compared with concerting CS seq to syncfile fd via several syncobj ioctls?

It just simplifies things. Mesa primarily uses seq_no-based fences and
will continue to use them. We can't remove the seq_no fence code
because we have to keep Mesa compatible with older kernels.

The only possibilities are:
- Mesa gets both seq_no and sync_file from CS.
- Mesa only gets seq_no from CS.

I decided to take the simpler option. I don't know if there is a perf
difference between CS returning a sync_file and using a separate
ioctl, but it's probably insignificant since we already call 3 ioctls
per IB submission (BO list create+destroy, submit).

Marek

>
> Regards,
> David Zhou
>
> 发自坚果 Pro
>
> Marek Ol?醟  于 2017年9月13日 下午6:11写道：
>
> On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1  wrote:
>> Hi Marek,
>>
>> You're doing same things with me, see my "introduce syncfile as fence
>> reuturn" patch set, which makes things more simple, we just need to
>> directly
>> return syncfile fd to UMD when CS, then the fence UMD get will be always
>> syncfile fd, UMD don't need to construct ip_type/ip_instance/ctx_id/ring
>> any
>> more, which also can pass to dependency and syncobj as well.
>
> For simpler Mesa code, Mesa won't get a sync file from the CS ioctl.
>
> Marek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/4] Exynos-gsc: Support the hardware rotation limits

[Sylwester Nawrocki]

On 09/13/2017 01:41 PM, Hoegeun Kwon wrote:

Hoegeun Kwon (4):
   [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
 version
   ARM: dts: exynos: Add clean name of compatible.
   drm/exynos/gsc: Add hardware rotation limits
   [media] exynos-gsc: Add hardware rotation limits


Thanks Hoegeung, I have applied patches 1 nad 4 from this series.

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

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

[Andrew Lunn]

On Wed, Sep 13, 2017 at 01:02:15PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais 
> ---
>  drivers/net/ethernet/sun/cassini.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/sun/cassini.c 
> b/drivers/net/ethernet/sun/cassini.c
> index 382993c..fc0ea3a 100644
> --- a/drivers/net/ethernet/sun/cassini.c
> +++ b/drivers/net/ethernet/sun/cassini.c
> @@ -3984,7 +3984,7 @@ static inline int cas_alloc_rx_desc(struct cas *cp, int 
> ring)
>   size = RX_DESC_RINGN_SIZE(ring);
>   for (i = 0; i < size; i++) {
>   if ((page[i] = cas_page_alloc(cp, GFP_KERNEL)) == NULL)
> - return -1;
> + return -ENOMEM;
>   }
>   return 0;
>  }

static int cas_alloc_rxds(struct cas *cp)
{
int i;

for (i = 0; i < N_RX_DESC_RINGS; i++) {
if (cas_alloc_rx_desc(cp, i) < 0) {
cas_free_rxds(cp);
return -1;
}
}
return 0;
}

Again, your change is correct, but in the end the value is not used.
And if you fix it at the cas_alloc_rxds level, you also need a fix at
the next level up:

err = -ENOMEM;
if (cas_tx_tiny_alloc(cp) < 0)
goto err_unlock;

/* alloc rx descriptors */
if (cas_alloc_rxds(cp) < 0)
goto err_tx_tiny;

again, the return value is discarded.

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

Re: [PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

[Sylwester Nawrocki]

On 09/13/2017 01:41 PM, Hoegeun Kwon wrote:

@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.num_clocks = 1,
  };
  
+static struct gsc_driverdata gsc_v_5250_drvdata = {

+   .variant = {
+   [0] = &gsc_v_5250_variant,
+   [1] = &gsc_v_5250_variant,
+   [2] = &gsc_v_5250_variant,
+   [3] = &gsc_v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = &gsc_v_5420_variant,
+   [1] = &gsc_v_5420_variant,
+   },
+   .num_entities = 4,


Shouldn't num_enities be 2 here? You don't need to resend, I can
amend that when applying.


+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+


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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Marek Olšák]

On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing)
 wrote:
> Could you describe how difficult to directly use CS syncfile fd in Mesa
> compared with concerting CS seq to syncfile fd via several syncobj ioctls?

It just simplifies things. Mesa primarily uses seq_no-based fences and
will continue to use them. We can't remove the seq_no fence code
because we have to keep Mesa compatible with older kernels.

The only possibilities are:
- Mesa gets both seq_no and sync_file from CS.
- Mesa only gets seq_no from CS.

I decided to take the simpler option. I don't know if there is a perf
difference between CS returning a sync_file and using a separate
ioctl, but it's probably insignificant since we already call 3 ioctls
per IB submission (BO list create+destroy, submit).

Marek

>
> Regards,
> David Zhou
>
> 发自坚果 Pro
>
> Marek Ol?醟  于 2017年9月13日 下午6:11写道：
>
> On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1  wrote:
>> Hi Marek,
>>
>> You're doing same things with me, see my "introduce syncfile as fence
>> reuturn" patch set, which makes things more simple, we just need to
>> directly
>> return syncfile fd to UMD when CS, then the fence UMD get will be always
>> syncfile fd, UMD don't need to construct ip_type/ip_instance/ctx_id/ring
>> any
>> more, which also can pass to dependency and syncobj as well.
>
> For simpler Mesa code, Mesa won't get a sync file from the CS ioctl.
>
> Marek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Maarten Lankhorst]

Op 13-09-17 om 13:48 schreef Ville Syrjälä:
> On Wed, Sep 13, 2017 at 12:46:47PM +0200, Maarten Lankhorst wrote:
>> Op 13-09-17 om 12:37 schreef Ville Syrjälä:
>>> On Wed, Sep 13, 2017 at 09:32:40AM +0200, Maarten Lankhorst wrote:
 Op 12-09-17 om 22:11 schreef Pandiyan, Dhinakaran:
> On Tue, 2017-09-12 at 19:08 +, Pandiyan, Dhinakaran wrote:
>> On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
>>> On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
 On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions 
> to
> set power states for downstream sinks. Apart from giving us the 
> ability
> to set power state for individual sinks, this fixes the below test for
> me
>
> $ xrandr --display :0 --output DP-2-2-8 --off
> $ xrandr --display :0 --output DP-2-2-1 --off
> $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> $ xrandr --display :0 --output DP-2-2-1 --auto
>
> Cc: Ville Syrjälä 
> Cc: Lyude 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
>  2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1da3bb2cc4b4..8aebacc0aa31 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_prepare_dp_ddi_buffers(encoder);
>  
>   intel_ddi_init_dp_buf_reg(encoder);
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> + if (!link_mst)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_start_link_train(intel_dp);
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
> @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
> intel_encoder *intel_encoder,
>   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + if (old_crtc_state && old_conn_state)
> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
 I would make that
 !intel_crtc_has_type(DP_MST)

> old_crtc_state, which intel_crtc_has_type() needs, is NULL for MST and
> the reason Maarten provided in his commit is
>
> " We also shouldn't pass crtc_state, because in that case the
>   disabling sequence may potentially be different depending on
>   which crtc is disabled last. Nice way to introduce bugs.
> "
> I am not 100% sure I understand the concern. But since that change was
> intentional I guess we can use the NULL values, like I've done, to
> identify the mst sinks. I am open to ideas.
 I think checking for NULL crtc_state is enough, in case we ever decide to 
 pass the real connector state.
 For clarity, I would add something like bool is_dsp_mst = !crtc_state; /* 
 When enabling the link for MST, this connector is never bound to a crtc */.
>>> The NULL state is rather ugly IMO. With a comment I might be able to
>>> stomach it. However, after another look I see that we already pass the
>>> crtc state to ddi_pre_enable() from the MST code, so even just from a
>>> symmetry POV it would make sense to pass it to ddi_post_disable as well.
>>>
>> It doesn't make sense to pass crtc_state, there's no guarantee that the 
>> crtc_state
>> from the same crtc is passed into first MST enable, and last MST disable.
> Doesn't really matter. If they don't match sufficiently we've already
> messed up somewhere.
>
> Ideally we should have some kind of separate state for the DP link, but
> since we don't atm we just abuse the crtc state to contain the link
> parameters.

Could we stuff it in the real DP's connector state, and then make sure we add 
the master connector state?

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

[Bug 196771] [AMDGPU] Scrambled video output during boot on WQHD monitor

[bugzilla-daemon]

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

--- Comment #7 from Rokas Kupstys (rokups+kernel-b...@zoho.com) ---
amd-staging kernel appears to be working. Since archlinux linux-amd-staging-git
package which i used in test is broken i could only get to errors about missing
modules and to emergency shell. Text is properly rendered on boot, although
resolution appears to be 1920x1080 or similar.

-- 
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: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Ville Syrjälä]

On Wed, Sep 13, 2017 at 12:46:47PM +0200, Maarten Lankhorst wrote:
> Op 13-09-17 om 12:37 schreef Ville Syrjälä:
> > On Wed, Sep 13, 2017 at 09:32:40AM +0200, Maarten Lankhorst wrote:
> >> Op 12-09-17 om 22:11 schreef Pandiyan, Dhinakaran:
> >>>
> >>> On Tue, 2017-09-12 at 19:08 +, Pandiyan, Dhinakaran wrote:
>  On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> >> On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> >>> Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions 
> >>> to
> >>> set power states for downstream sinks. Apart from giving us the 
> >>> ability
> >>> to set power state for individual sinks, this fixes the below test for
> >>> me
> >>>
> >>> $ xrandr --display :0 --output DP-2-2-8 --off
> >>> $ xrandr --display :0 --output DP-2-2-1 --off
> >>> $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> >>> $ xrandr --display :0 --output DP-2-2-1 --auto
> >>>
> >>> Cc: Ville Syrjälä 
> >>> Cc: Lyude 
> >>> Signed-off-by: Dhinakaran Pandiyan 
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
> >>>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
> >>>  2 files changed, 8 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >>> b/drivers/gpu/drm/i915/intel_ddi.c
> >>> index 1da3bb2cc4b4..8aebacc0aa31 100644
> >>> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >>> @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> >>> intel_encoder *encoder,
> >>>   intel_prepare_dp_ddi_buffers(encoder);
> >>>  
> >>>   intel_ddi_init_dp_buf_reg(encoder);
> >>> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> >>> + if (!link_mst)
> >>> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> >>>   intel_dp_start_link_train(intel_dp);
> >>>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> >>>   intel_dp_stop_link_train(intel_dp);
> >>> @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
> >>> intel_encoder *intel_encoder,
> >>>   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> >>>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >>>  
> >>> - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >>> + if (old_crtc_state && old_conn_state)
> >>> + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >> I would make that
> >> !intel_crtc_has_type(DP_MST)
> >>
> >>> old_crtc_state, which intel_crtc_has_type() needs, is NULL for MST and
> >>> the reason Maarten provided in his commit is
> >>>
> >>> " We also shouldn't pass crtc_state, because in that case the
> >>>   disabling sequence may potentially be different depending on
> >>>   which crtc is disabled last. Nice way to introduce bugs.
> >>> "
> >>> I am not 100% sure I understand the concern. But since that change was
> >>> intentional I guess we can use the NULL values, like I've done, to
> >>> identify the mst sinks. I am open to ideas.
> >> I think checking for NULL crtc_state is enough, in case we ever decide to 
> >> pass the real connector state.
> >> For clarity, I would add something like bool is_dsp_mst = !crtc_state; /* 
> >> When enabling the link for MST, this connector is never bound to a crtc */.
> > The NULL state is rather ugly IMO. With a comment I might be able to
> > stomach it. However, after another look I see that we already pass the
> > crtc state to ddi_pre_enable() from the MST code, so even just from a
> > symmetry POV it would make sense to pass it to ddi_post_disable as well.
> >
> It doesn't make sense to pass crtc_state, there's no guarantee that the 
> crtc_state
> from the same crtc is passed into first MST enable, and last MST disable.

Doesn't really matter. If they don't match sufficiently we've already
messed up somewhere.

Ideally we should have some kind of separate state for the DP link, but
since we don't atm we just abuse the crtc state to contain the link
parameters.

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

[PATCH v4 0/4] Exynos-gsc: Support the hardware rotation limits

[Hoegeun Kwon]

Hello all,

Frist, thanks Krzysztof, Robin and Sylwester.

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V4:
- Fixed the most specific compatible come first in device tree.
- Kept compatible("samsung,exynos5-gsc") in ther driver.
- Added mark compatible("samsung,exynos5-gsc") as deprecated.
- Added print dmesg if your driver uses compatible("samsung, exynos5-gsc").
- Removed the patch 5, 6 of ver3.

Changes for V3:
- Fixed of_match_node() to of_device_get_match_data() in drm gsc driver.
- Added hardware rotation limits for gsc driver of v4l2.
- Added the remove unnecessary compatible for DT document and Exynos dts.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (4):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits
  [media] exynos-gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   9 +-
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 104 -
 drivers/media/platform/exynos-gsc/gsc-core.c   | 127 -
 include/uapi/drm/exynos_drm.h  |   2 +
 6 files changed, 211 insertions(+), 43 deletions(-)

-- 
1.9.1

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

[PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits

[Hoegeun Kwon]

The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon 
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 127 +--
 1 file changed, 122 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..173a238 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -958,6 +958,51 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_rot_en_h= 2016,
 };
 
+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2047,
+   .real_rot_en_h  = 2047,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
 static struct gsc_pix_min gsc_v_100_min = {
.org_w  = 64,
.org_h  = 32,
@@ -992,6 +1037,45 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
 };
 
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= &gsc_v_5250_max,
+   .pix_min= &gsc_v_100_min,
+   .pix_align  = &gsc_v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= &gsc_v_5420_max,
+   .pix_min= &gsc_v_100_min,
+   .pix_align  = &gsc_v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= &gsc_v_5433_max,
+   .pix_min= &gsc_v_100_min,
+   .pix_align  = &gsc_v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
 static struct gsc_driverdata gsc_v_100_drvdata = {
.variant = {
[0] = &gsc_v_100_variant,
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.num_clocks = 1,
 };
 
+static struct gsc_driverdata gsc_v_5250_drvdata = {
+   .variant = {
+   [0] = &gsc_v_5250_variant,
+   [1] = &gsc_v_5250_variant,
+   [2] = &gsc_v_5250_variant,
+   [3] = &gsc_v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = &gsc_v_5420_variant,
+   [1] = &gsc_v_5420_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
 static struct gsc_driverdata gsc_5433_drvdata = {
.variant = {
-   [0] = &gsc_v_100_variant,
-   [1] = &gsc_v_100_variant,
-   [2] = &gsc_v_100_variant,
+   [0] = &gsc_v_5433_variant,
+   [1

[PATCH v4 3/4] drm/exynos/gsc: Add hardware rotation limits

[Hoegeun Kwon]

The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 104 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 77 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..66a19d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -150,6 +151,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1411,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = &property->config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1443,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1450,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1481,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-   (

[PATCH v4 1/4] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

[Hoegeun Kwon]

Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon 
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..0d4fdae 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,8 +3,11 @@
 G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
 
 Required properties:
-- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
- 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+- compatible: should be one of
+ "samsung,exynos5250-gsc"
+ "samsung,exynos5420-gsc"
+ "samsung,exynos5433-gsc"
+ "samsung,exynos5-gsc" (deprecated)
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
@@ -15,7 +18,7 @@ Optional properties:
 Example:
 
 gsc_0:  gsc@0x13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = <0 85 0>;
 };
-- 
1.9.1

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

[PATCH v4 2/4] ARM: dts: exynos: Add clean name of compatible.

[Hoegeun Kwon]

Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..d0d0460 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <&pd_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <&pd_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <&pd_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5250-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <&pd_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..6166730 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = <&clock CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5420-gsc", 
"samsung,exynos5-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = <&clock CLK_GSCL1>;
-- 
1.9.1

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Zhou, David(ChunMing)]

Could you describe how difficult to directly use CS syncfile fd in Mesa 
compared with concerting CS seq to syncfile fd via several syncobj ioctls?

Regards,
David Zhou


发自坚果 Pro

Marek Ol?醟  于 2017年9月13日 下午6:11写道：

On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1  wrote:
> Hi Marek,
>
> You're doing same things with me, see my "introduce syncfile as fence
> reuturn" patch set, which makes things more simple, we just need to directly
> return syncfile fd to UMD when CS, then the fence UMD get will be always
> syncfile fd, UMD don't need to construct ip_type/ip_instance/ctx_id/ring any
> more, which also can pass to dependency and syncobj as well.

For simpler Mesa code, Mesa won't get a sync file from the CS ioctl.

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

Re: [PATCH 0/6] Exynos DRM: rewrite IPP subsystem and userspace API

[Tobias Jakobi]

Hey Marek,

first of all thanks for keeping this series alive. Looks pretty good so far.

I have started to rewrite my IPP userspace API in libdrm and when this is done,
I'm going to adapt my mpv video backend to it.

With best wishes,
Tobias



Marek Szyprowski wrote:
> Dear all,
> 
> This patchset performs complete rewrite of Exynos DRM IPP subsystem and
> its userspace API.
> 
> Why such rewrite is needed? Exynos DRM IPP API is over-engineered in
> general, but not really extensible on the other side. It is also buggy,
> with significant design flaws:
> - Userspace API covers memory-2-memory picture operations together with
>   CRTC writeback and duplicating features, which belongs to video plane.
> - Lack of support of the all required image formats (for example NV12
>   Samsung-tiled cannot be used due to lack of pixel format modifier
>   support).
> - Userspace API designed only to mimic hardware behaviour, not easy to
>   understand.
> - Lack of proper input validation in the core, drivers also didn't do that
>   correctly, so it was possible to set incorrect parameters and easil
>   trigger IOMMU fault or memory trash.
> - Drivers were partially disfunctional or supported only a subset of modes.
> 
> Due to the above limitations and issues the Exynos DRM IPP API was not
> used by any of the open-source projects. I assume that it is safe to remove
> this broken API without any damage to open-source community. All remaining
> users (mainly Tizen project related) will be updated to the new version.
> 
> This patchset changes Exynos DRM IPP subsystem to something useful. The
> userspace API is much simpler, state-less and easy to understand. Also
> the code of the core and driver is significantly smaller and easier to
> understand.
> 
> Patches were tested on Exynos4412 based Odroid U3 and Exynos5422
> Odroid XU3 boards, on top of Linux next-20170911 kernel.
> 
> Best regards
> Marek Szyprowski
> Samsung R&D Institute Poland
> 
> 
> My previous works in this area:
> 
> "[RFC v2 0/2] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/dri-devel/msg140669.html
> - removed usage of DRM objects and properties - replaced them with simple
>   list of parameters with predefined IDs
> 
> "[RFC 0/4] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/linux-samsung-soc/msg59323.html
> - moved this feature from DRM core to Exynos DRM driver
> - changed name from framebuffer processor to picture processor
> - simplified code to cover only things needed by Exynos drivers
> - implemented simple fifo task scheduler
> - cleaned up rotator driver conversion (removed IPP remainings)
> 
> "[RFC 0/2] New feature: Framebuffer processors"
> https://www.spinics.net/lists/linux-samsung-soc/msg54810.html
> - generic approach implemented in DRM core, rejected
> 
> 
> Patch summary:
> 
> Marek Szyprowski (6):
>   drm/exynos: ipp: Remove Exynos DRM IPP subsystem
>   drm/exynos: ipp: Add IPP v2 framework
>   drm/exynos: rotator: Convert driver to IPP v2 core API
>   drm/exynos: gsc: Convert driver to IPP v2 core API
>   drm/exynos: Add generic support for devices shared with V4L2 subsystem
>   drm/exynos: fimc: Convert driver to IPP v2 core API
> 
>  drivers/gpu/drm/exynos/Kconfig  |   12 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   33 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  893 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimc.h|   23 -
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |  853 +++---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.h |   24 -
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2239 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.h |  352 ++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  735 ++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.h |   19 -
>  include/uapi/drm/exynos_drm.h   |  315 ++--
>  12 files changed, 1627 insertions(+), 3875 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h
> 

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

Re: [PATCH V4 21/23] drm/etnaviv: need to disable clock gating when doing profiling

[Lucas Stach]

Am Dienstag, den 12.09.2017, 17:11 +0200 schrieb Christian Gmeiner:
> As done by Vivante kernel driver.

You need to move the VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS from
etnaviv_gpu_update_clock to the GPU init path. Otherwise a thermal
throttling request may disable the debug registers again, while the
profiled commandstream is in flight on the GPU.

Regards,
Lucas

> Signed-off-by: Christian Gmeiner 
> Reviewed-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 842b6642dcd6..04acc3a64c3c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1341,6 +1341,13 @@ static void sync_point_perfmon_sample(struct 
> etnaviv_gpu *gpu,
>  static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
>   struct etnaviv_event *event)
>  {
> + u32 val;
> +
> + /* disable clock gating */
> + val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
> + val &= ~VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
> + gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
> +
>   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
>  }
>  
> @@ -1349,6 +1356,7 @@ static void sync_point_perfmon_sample_post(struct 
> etnaviv_gpu *gpu,
>  {
>   const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
>   unsigned int i;
> + u32 val;
>  
>   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
>  
> @@ -1357,6 +1365,11 @@ static void sync_point_perfmon_sample_post(struct 
> etnaviv_gpu *gpu,
>  
>   *pmr->bo_vma = pmr->sequence;
>   }
> +
> + /* enable clock gating */
> + val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
> + val |= VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
> + gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
>  }
>  
> 


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

Re: [PATCH V4 12/23] drm/etnaviv: use 'sync points' for performance monitor requests

[Lucas Stach]

Am Dienstag, den 12.09.2017, 17:11 +0200 schrieb Christian Gmeiner:
> With 'sync points' we can sample the reqeustes perform signals
> before and/or after the submited command buffer.
> 
> Changes v2 -> v3:
> - fixed indentation and init nr_events to 1
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 102 
> +++---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h |   1 +
>  2 files changed, 83 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index b65d7b9d247a..842b6642dcd6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1324,12 +1324,48 @@ void etnaviv_gpu_pm_put(struct etnaviv_gpu *gpu)
>   pm_runtime_put_autosuspend(gpu->dev);
>  }
>  
> +static void sync_point_perfmon_sample(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event, unsigned int flags)
> +{
> + const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
> + unsigned int i;
> +
> + for (i = 0; i < cmdbuf->nr_pmrs; i++) {
> + const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
> +
> + if (pmr->flags == flags)
> + etnaviv_perfmon_process(gpu, pmr);
> + }
> +}
> +
> +static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
> +}
> +
> +static void sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + const struct etnaviv_cmdbuf *cmdbuf = event->cmdbuf;
> + unsigned int i;
> +
> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
> +
> + for (i = 0; i < cmdbuf->nr_pmrs; i++) {
> + const struct etnaviv_perfmon_request *pmr = cmdbuf->pmrs + i;
> +
> + *pmr->bo_vma = pmr->sequence;
> + }
> +}
> +
> +
>  /* add bo's to gpu's ring, and kick gpu: */
>  int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   struct etnaviv_gem_submit *submit, struct etnaviv_cmdbuf *cmdbuf)
>  {
>   struct dma_fence *fence;
> - unsigned int event, i;
> + unsigned int i, nr_events = 1, event[3];
>   int ret;
>  
>   ret = etnaviv_gpu_pm_get_sync(gpu);
> @@ -1345,9 +1381,19 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>*
>*/
>  
> - ret = event_alloc(gpu, 1, &event);
> + /*
> +  * if there are performance monitor requests we need to have
> +  * - a sync point to re-configure gpu and process ETNA_PM_PROCESS_PRE
> +  *   requests.
> +  * - a sync point to re-configure gpu, process ETNA_PM_PROCESS_POST 
> requests
> +  *   and update the sequence number for userspace.
> +  */
> + if (cmdbuf->nr_pmrs)
> + nr_events = 3;
> +
> + ret = event_alloc(gpu, nr_events, event);
>   if (ret) {
> - DRM_ERROR("no free event\n");
> + DRM_ERROR("no free events\n");
>   goto out_pm_put;
>   }
>  
> @@ -1355,12 +1401,14 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>  
>   fence = etnaviv_gpu_fence_alloc(gpu);
>   if (!fence) {
> - event_free(gpu, event);
> + for (i = 0; i < nr_events; i++)
> + event_free(gpu, event[i]);
> +
>   ret = -ENOMEM;
>   goto out_unlock;
>   }
>  
> - gpu->event[event].fence = fence;
> + gpu->event[event[0]].fence = fence;
>   submit->fence = dma_fence_get(fence);
>   gpu->active_fence = submit->fence->seqno;
>  
> @@ -1370,7 +1418,19 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   gpu->lastctx = cmdbuf->ctx;
>   }
>  
> - etnaviv_buffer_queue(gpu, event, cmdbuf);
> + if (cmdbuf->nr_pmrs) {
> + gpu->event[event[1]].sync_point = 
> &sync_point_perfmon_sample_pre;
> + gpu->event[event[1]].cmdbuf = cmdbuf;
> + etnaviv_sync_point_queue(gpu, event[1]);
> + }
> +
> + etnaviv_buffer_queue(gpu, event[0], cmdbuf);
> +
> + if (cmdbuf->nr_pmrs) {
> + gpu->event[event[2]].sync_point = 
> &sync_point_perfmon_sample_post;
> + gpu->event[event[2]].cmdbuf = cmdbuf;
> + etnaviv_sync_point_queue(gpu, event[2]);
> + }
>  
>   cmdbuf->fence = fence;
>   list_add_tail(&cmdbuf->node, &gpu->active_cmd_list);
> @@ -1475,20 +1535,22 @@ static irqreturn_t irq_handler(int irq, void *data)
>   }
>  
>   fence = gpu->event[event].fence;
> - gpu->event[event].fence = NULL;
> - dma_fence_signal(fence);
> -
> - /*
> -  * Events can be processed out of order.  Eg,
> -  * - allocate and queue event 0
> -  * - allocate event 1
> -  * - event 0 completes, we process it
> -   

Re: [PATCH 00/23] drm/etnaviv: support performance counters

[Lucas Stach]

Am Dienstag, den 12.09.2017, 17:11 +0200 schrieb Christian Gmeiner:
> In a perfect world we would be able to read GPU registers of interest
> via the command stream with a 'read-register' command/package. For perf
> counters it is a must to read them synchronized with the GPU to put the
> values in relation to a draw command. As Vivante GPUs do not provide this
> functionality we need to emulate it in software.
> 
> 
> We need to support three different kind of perf register types:
> 
> 1) normal register
>   This is the easierst case where we can simply read the register and we
>   are done.
> 
> 2) debug register
>   We need to configure the mux register and then read the debug register 
> value.
> 
> 3) pipeline register
>   We need to 'iterate' over all pixel pipes and sum up the values. The 
> 'iteration'
>   is done by select the pipe of interest via 
> HI_CLOCK_CONTROL_DEBUG_PIXEL_PIPE.
>   There is also need to configure the mux register.
> 
> 
> Allowing the userspace to do it all by its own feels quite error prone and not
> future-proof. Thats why the kernel exports all performance domains and their
> signals to the userspace via two new ioctls. So the kernel knows all 
> performance
> counters and how to sample them.
> 
> At the moment all performacne domains and signals get exported to all gpu 
> pipe types,
> but that can be changed in follow-up patches.

Okay, after testing the V4 patches I'm convinced that we need this
filter _before_ any of this can go in.

At least on GC3000 profiling the PE counters wastes the GPU bad enough
that not even our regular GPU recovery mechanism is able to get it back
to life. This is a trivial DOS vector, which we simply can't allow in
the kernel driver. For this to go in, we need some way to only export
the counters, which are _tested_ to be safe on the hardware.

Regards,
Lucas

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

Re: [PATCHv3 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Ville Syrjälä]

On Wed, Sep 13, 2017 at 10:51:02AM +0200, Hans Verkuil wrote:
> On 09/12/2017 07:39 PM, Ville Syrjälä wrote:
> > On Mon, Sep 11, 2017 at 01:25:45PM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> >> feature that is part of the DisplayPort 1.3 standard.
> >>
> >> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> >> chip that has this capability actually hook up the CEC pin, so
> >> even though a CEC device is created, it may not actually work.
> >>
> >> Signed-off-by: Hans Verkuil 
> >> Tested-by: Carlos Santa 
> >> ---
> >>  drivers/gpu/drm/Kconfig  |  10 ++
> >>  drivers/gpu/drm/Makefile |   1 +
> >>  drivers/gpu/drm/drm_dp_cec.c | 301 
> >> +++
> >>  include/drm/drm_dp_helper.h  |  24 
> >>  4 files changed, 336 insertions(+)
> >>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
> >>
> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index 83cb2a88c204..1f2708df5c4e 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
> >>  default case is N. Details and instructions how to build your own
> >>  EDID data are given in Documentation/EDID/HOWTO.txt.
> >>  
> >> +config DRM_DP_CEC
> >> +  bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> >> +  select CEC_CORE
> >> +  help
> >> +Choose this option if you want to enable HDMI CEC support for
> >> +DisplayPort/USB-C to HDMI adapters.
> >> +
> >> +Note: not all adapters support this feature, and even for those
> >> +that do support this they often do not hook up the CEC pin.
> >> +
> >>  config DRM_TTM
> >>tristate
> >>depends on DRM && MMU
> >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> >> index 24a066e1841c..c6552c62049e 100644
> >> --- a/drivers/gpu/drm/Makefile
> >> +++ b/drivers/gpu/drm/Makefile
> >> @@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
> >> drm_edid_load.o
> >>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> >>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> >>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> >> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
> >>  
> >>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> >>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
> >> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> >> new file mode 100644
> >> index ..b831bb72c932
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/drm_dp_cec.c
> >> @@ -0,0 +1,301 @@
> >> +/*
> >> + * DisplayPort CEC-Tunneling-over-AUX support
> >> + *
> >> + * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
> >> reserved.
> >> + *
> >> + * This program is free software; you may redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; version 2 of the License.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> >> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> >> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> >> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> >> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> >> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> >> + * SOFTWARE.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +/*
> >> + * Unfortunately it turns out that we have a chicken-and-egg situation
> >> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> >> + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> >> + * Parade PS176), but they do not wire up the CEC pin, thus making CEC
> >> + * useless.
> >> + *
> >> + * Sadly there is no way for this driver to know this. What happens is
> >> + * that a /dev/cecX device is created that is isolated and unable to see
> >> + * any of the other CEC devices. Quite literally the CEC wire is cut
> >> + * (or in this case, never connected in the first place).
> >> + *
> >> + * I suspect that the reason so few adapters support this is that this
> >> + * tunneling protocol was never supported by any OS. So there was no
> >> + * easy way of testing it, and no incentive to correctly wire up the
> >> + * CEC pin.
> >> + *
> >> + * Hopefully by creating this driver it will be easier for vendors to
> >> + * finally fix their adapters and test the CEC functionality.
> >> + *
> >> + * I keep a list of known working adapters here:
> >> + *
> >> + * https://hverkuil.home.xs4all.nl/cec-status.txt
> >> + *
> >> + * Please mail me (hverk...@xs4all.nl) if you find an adapter tha

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Maarten Lankhorst]

Op 13-09-17 om 12:37 schreef Ville Syrjälä:
> On Wed, Sep 13, 2017 at 09:32:40AM +0200, Maarten Lankhorst wrote:
>> Op 12-09-17 om 22:11 schreef Pandiyan, Dhinakaran:
>>>
>>> On Tue, 2017-09-12 at 19:08 +, Pandiyan, Dhinakaran wrote:
 On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
>> On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
>>> Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
>>> set power states for downstream sinks. Apart from giving us the ability
>>> to set power state for individual sinks, this fixes the below test for
>>> me
>>>
>>> $ xrandr --display :0 --output DP-2-2-8 --off
>>> $ xrandr --display :0 --output DP-2-2-1 --off
>>> $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
>>> $ xrandr --display :0 --output DP-2-2-1 --auto
>>>
>>> Cc: Ville Syrjälä 
>>> Cc: Lyude 
>>> Signed-off-by: Dhinakaran Pandiyan 
>>> ---
>>>  drivers/gpu/drm/i915/intel_ddi.c| 6 --
>>>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
>>>  2 files changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>>> b/drivers/gpu/drm/i915/intel_ddi.c
>>> index 1da3bb2cc4b4..8aebacc0aa31 100644
>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>>> @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
>>> intel_encoder *encoder,
>>> intel_prepare_dp_ddi_buffers(encoder);
>>>  
>>> intel_ddi_init_dp_buf_reg(encoder);
>>> -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>>> +   if (!link_mst)
>>> +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>>> intel_dp_start_link_train(intel_dp);
>>> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>>> intel_dp_stop_link_train(intel_dp);
>>> @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
>>> intel_encoder *intel_encoder,
>>> if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
>>> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>>>  
>>> -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>>> +   if (old_crtc_state && old_conn_state)
>>> +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>> I would make that
>> !intel_crtc_has_type(DP_MST)
>>
>>> old_crtc_state, which intel_crtc_has_type() needs, is NULL for MST and
>>> the reason Maarten provided in his commit is
>>>
>>> " We also shouldn't pass crtc_state, because in that case the
>>>   disabling sequence may potentially be different depending on
>>>   which crtc is disabled last. Nice way to introduce bugs.
>>> "
>>> I am not 100% sure I understand the concern. But since that change was
>>> intentional I guess we can use the NULL values, like I've done, to
>>> identify the mst sinks. I am open to ideas.
>> I think checking for NULL crtc_state is enough, in case we ever decide to 
>> pass the real connector state.
>> For clarity, I would add something like bool is_dsp_mst = !crtc_state; /* 
>> When enabling the link for MST, this connector is never bound to a crtc */.
> The NULL state is rather ugly IMO. With a comment I might be able to
> stomach it. However, after another look I see that we already pass the
> crtc state to ddi_pre_enable() from the MST code, so even just from a
> symmetry POV it would make sense to pass it to ddi_post_disable as well.
>
It doesn't make sense to pass crtc_state, there's no guarantee that the 
crtc_state
from the same crtc is passed into first MST enable, and last MST disable.
To be sure we don't rely on it NULL was passed in, which is the only valid 
thing here.

~Maarten

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Ville Syrjälä]

On Wed, Sep 13, 2017 at 09:32:40AM +0200, Maarten Lankhorst wrote:
> Op 12-09-17 om 22:11 schreef Pandiyan, Dhinakaran:
> >
> >
> > On Tue, 2017-09-12 at 19:08 +, Pandiyan, Dhinakaran wrote:
> >> On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> >>> On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
>  On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> > Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> > set power states for downstream sinks. Apart from giving us the ability
> > to set power state for individual sinks, this fixes the below test for
> > me
> >
> > $ xrandr --display :0 --output DP-2-2-8 --off
> > $ xrandr --display :0 --output DP-2-2-1 --off
> > $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> > $ xrandr --display :0 --output DP-2-2-1 --auto
> >
> > Cc: Ville Syrjälä 
> > Cc: Lyude 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c| 6 --
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 8 
> >  2 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 1da3bb2cc4b4..8aebacc0aa31 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> >  
> > intel_ddi_init_dp_buf_reg(encoder);
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > +   if (!link_mst)
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > intel_dp_start_link_train(intel_dp);
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct 
> > intel_encoder *intel_encoder,
> > if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >  
> > -   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> > +   if (old_crtc_state && old_conn_state)
> > +   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>  I would make that
>  !intel_crtc_has_type(DP_MST)
> 
> > old_crtc_state, which intel_crtc_has_type() needs, is NULL for MST and
> > the reason Maarten provided in his commit is
> >
> > " We also shouldn't pass crtc_state, because in that case the
> >   disabling sequence may potentially be different depending on
> >   which crtc is disabled last. Nice way to introduce bugs.
> > "
> > I am not 100% sure I understand the concern. But since that change was
> > intentional I guess we can use the NULL values, like I've done, to
> > identify the mst sinks. I am open to ideas.
> I think checking for NULL crtc_state is enough, in case we ever decide to 
> pass the real connector state.
> For clarity, I would add something like bool is_dsp_mst = !crtc_state; /* 
> When enabling the link for MST, this connector is never bound to a crtc */.

The NULL state is rather ugly IMO. With a comment I might be able to
stomach it. However, after another look I see that we already pass the
crtc state to ddi_pre_enable() from the MST code, so even just from a
symmetry POV it would make sense to pass it to ddi_post_disable as well.

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

[Bug 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

--- Comment #4 from Gerd Hoffmann (kra...@redhat.com) ---
Retested 4.13 + comment #2 patch.

plymouth (aka graphical boot) hangs the machine indeed.

when disabling rhgb gdm comes up just fine though, in both wayland and xorg
mode.
so apparently we have two issues here, and the patch fixes only one of them.

The plymouth hang appears to be pretty serious, the whole machine appears to be
toast.  I can't login over network to see what is going on, so it's not only
the display which is f*cked up.  Nothing written to the logs either.  When
enabling the serial console to see the logs plymouth skips the splash screen
though, so the issue doesn't trigger any more.  Hmm, I'm running out of ideas
...

-- 
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 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[zhoucm1]

On 2017年09月13日 16:07, Christian König wrote:

Am 13.09.2017 um 09:39 schrieb zhoucm1:



On 2017年09月13日 15:09, Christian König wrote:
syncfile is the older implementation, sync_obj is the replacement 
for it.


Are you sure sync_obj is a replacement for syncfile? Anyone can 
clarify it?


sync_obj is mainly for semaphore usage, we can see sync_obj docs from 
Dave in drm_syncobj.c:

"/**
 * DOC: Overview
 *
 * DRM synchronisation objects (syncobj) are a persistent objects,
 * that contain an optional fence. The fence can be updated with a new
 * fence, or be NULL.
 *
 * syncobj's can be export to fd's and back, these fd's are opaque and
 * have no other use case, except passing the syncobj between processes.
 *
 * Their primary use-case is to implement Vulkan fences and semaphores.
 *
 * syncobj have a kref reference count, but also have an optional file.
 * The file is only created once the syncobj is exported.
 * The file takes a reference on the kref.
 */
"



Correct, but you can convert from sync_obj into syncfile and back 
using a standard DRM IOCTL. So when we support sync_obj we also 
support syncfile.




I don't think we should implement syncfile in the CS any more, 
sync_obj is already done and can be converted to/from syncfiles.


Mareks IOCTL should cover the case when we need to create a syncfile 
or syncobj from a fence sequence number.


I know his convertion can do that things, but returning syncfile fd 
directly is a really simple method.


Well we can use sync_obj for this as well, it doesn't make so much 
difference.


Point is we shouldn't return a syncfile for VM operations because that 
will always use an fd which isn't very desirable.
Have you seen Android fence fd? they are all syncfile fd, when Marek 
enables EGL_ANDROID_native_fence_sync, they will also be syncfile fd 
used by Android.


Regards,
David Zhou



Regards,
Christian.



Regards,
David Zhou


Regards,
Christian.

Am 13.09.2017 um 09:03 schrieb zhoucm1:
I really very surprise that you prefer to expand sync_obj to get 
syncfile fd!!!


Why not directly generate syncfile fd and use it? Which one is 
simple is so obvious.


Regards,
David Zhou
On 2017年09月13日 14:57, Christian König wrote:

Hi guys,

Mareks IOCTL proposal looks really good to me.

Please note that we already have sync_obj support for the CS IOCTL 
in the 4.13 branch and this work is based on top of that.



UMD don't need to construct ip_type/ip_instance/ctx_id/ring
Well the UMD does want to construct 
ip_type/ip_instance/ctx_id/ring and use for the simple reason that 
it allows more flexibility than sync_obj/sync_file.


Thinking more about this I'm pretty sure we want to do something 
similar for VM map/unmap operations as well.


Regards,
Christian.

Am 13.09.2017 um 05:03 schrieb zhoucm1:

Hi Marek,

You're doing same things with me, see my "introduce syncfile as 
fence reuturn" patch set, which makes things more simple, we just 
need to directly return syncfile fd to UMD when CS, then the 
fence UMD get will be always syncfile fd, UMD don't need to 
construct ip_type/ip_instance/ctx_id/ring any more, which also 
can pass to dependency and syncobj as well.


Regards,
David Zhou
On 2017年09月13日 04:42, Marek Olšák wrote:

From: Marek Olšák 

for being able to convert an amdgpu fence into one of the handles.
Mesa will use this.

Signed-off-by: Marek Olšák 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 61 
+

  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
  include/uapi/drm/amdgpu_drm.h   | 16 +
  5 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

index b5c8b90..c15fa93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1308,6 +1308,8 @@ int amdgpu_gem_va_ioctl(struct drm_device 
*dev, void *data,

  int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
  int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct 
drm_file *filp);
+int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, 
void *data,

+struct drm_file *filp);
  int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp);
  int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void 
*data,

  struct drm_file *filp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

index 7cb8a59..6dd719c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
   *Jerome Glisse 
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1311,6 +1312,66 @@ static struct dma_fence 
*amdgpu_cs_get_fence(struct amdgpu_device *adev,

  return fence;
  }
  +int amdgpu_cs_fence_to_handle_ioctl(struct drm_

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Marek Olšák]

On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1  wrote:
> Hi Marek,
>
> You're doing same things with me, see my "introduce syncfile as fence
> reuturn" patch set, which makes things more simple, we just need to directly
> return syncfile fd to UMD when CS, then the fence UMD get will be always
> syncfile fd, UMD don't need to construct ip_type/ip_instance/ctx_id/ring any
> more, which also can pass to dependency and syncobj as well.

For simpler Mesa code, Mesa won't get a sync file from the CS ioctl.

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

Re: [PATCH] drm/ttm: fix memory leak while individualizing BOs

[Liu, Monk]

verified work,


Reviewed-by: Monk Liu 


From: amd-gfx  on behalf of Christian 
König 
Sent: Wednesday, September 13, 2017 4:47:34 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH] drm/ttm: fix memory leak while individualizing BOs

From: Christian König 

We need to free the reservation object before we take the BO
from the delayed delete list.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bee77d3..d79607a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -557,6 +557,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
 }

 ttm_bo_del_from_lru(bo);
+   if (!list_empty(&bo->ddestroy) && (bo->resv != &bo->ttm_resv))
+   reservation_object_fini(&bo->ttm_resv);
 list_del_init(&bo->ddestroy);
 kref_put(&bo->list_kref, ttm_bo_ref_bug);

--
2.7.4

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

Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

[Hoegeun Kwon]

On 09/13/2017 06:11 PM, Sylwester Nawrocki wrote:

Hi Hoegeun,

On 09/13/2017 04:33 AM, Hoegeun Kwon wrote:

@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq,
void *priv)
  static const struct of_device_id exynos_gsc_match[] = {
{
-.compatible = "samsung,exynos5-gsc",
-.data = &gsc_v_100_drvdata,

Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
data, so that it can work with "samsung,exynos5-gsc" compatible in DT
on both exynos5250 and exynos5420 SoCs?


Thank you for your question.

Exynos 5250 and 5420 have different hardware rotation limits.
Exynos 5250 is '.real_rot_en_w/h = 2016' and 5420 is '.real_rot_en_w/h =
2048'.

So my opinion they must have different compatible.

I think there is some misunderstanding, mu suggestion was to keep the
"samsung,exynos5-gsc" compatible entry in addition to the new introduced
ones: "samsung,exynos5250-gsc" and "samsung,exynos5420-gsc". That's in
order to make your changes possibly backward compatible, in theory
the updated driver should still work without changes in dts.



Thank you again for your explanation.

Yes, I understood.
I will keep "samsung,exynos5-gsc" compatible,
and add Exynos 5250/5420/5433 compatible.

Best regards,
Hoegeun

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

Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

[Sylwester Nawrocki]

Hi Hoegeun,

On 09/13/2017 04:33 AM, Hoegeun Kwon wrote:
>>> @@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq,
>>> void *priv)
>>>  static const struct of_device_id exynos_gsc_match[] = {
>>>{
>>> -.compatible = "samsung,exynos5-gsc",
>>> -.data = &gsc_v_100_drvdata,
>> Can you keep the "samsung,exynos5-gsc" entry with the gsc_v_5250_variant
>> data, so that it can work with "samsung,exynos5-gsc" compatible in DT
>> on both exynos5250 and exynos5420 SoCs?
>>
> Thank you for your question.
> 
> Exynos 5250 and 5420 have different hardware rotation limits.
> Exynos 5250 is '.real_rot_en_w/h = 2016' and 5420 is '.real_rot_en_w/h =
> 2048'.
> 
> So my opinion they must have different compatible.

I think there is some misunderstanding, mu suggestion was to keep the 
"samsung,exynos5-gsc" compatible entry in addition to the new introduced 
ones: "samsung,exynos5250-gsc" and "samsung,exynos5420-gsc". That's in
order to make your changes possibly backward compatible, in theory 
the updated driver should still work without changes in dts.

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

Re: [PATCHv3 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Hans Verkuil]

On 09/12/2017 07:39 PM, Ville Syrjälä wrote:
> On Mon, Sep 11, 2017 at 01:25:45PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This adds support for the DisplayPort CEC-Tunneling-over-AUX
>> feature that is part of the DisplayPort 1.3 standard.
>>
>> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
>> chip that has this capability actually hook up the CEC pin, so
>> even though a CEC device is created, it may not actually work.
>>
>> Signed-off-by: Hans Verkuil 
>> Tested-by: Carlos Santa 
>> ---
>>  drivers/gpu/drm/Kconfig  |  10 ++
>>  drivers/gpu/drm/Makefile |   1 +
>>  drivers/gpu/drm/drm_dp_cec.c | 301 
>> +++
>>  include/drm/drm_dp_helper.h  |  24 
>>  4 files changed, 336 insertions(+)
>>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 83cb2a88c204..1f2708df5c4e 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
>>default case is N. Details and instructions how to build your own
>>EDID data are given in Documentation/EDID/HOWTO.txt.
>>  
>> +config DRM_DP_CEC
>> +bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
>> +select CEC_CORE
>> +help
>> +  Choose this option if you want to enable HDMI CEC support for
>> +  DisplayPort/USB-C to HDMI adapters.
>> +
>> +  Note: not all adapters support this feature, and even for those
>> +  that do support this they often do not hook up the CEC pin.
>> +
>>  config DRM_TTM
>>  tristate
>>  depends on DRM && MMU
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 24a066e1841c..c6552c62049e 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
>> drm_edid_load.o
>>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
>> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
>>  
>>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
>> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
>> new file mode 100644
>> index ..b831bb72c932
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_dp_cec.c
>> @@ -0,0 +1,301 @@
>> +/*
>> + * DisplayPort CEC-Tunneling-over-AUX support
>> + *
>> + * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
>> reserved.
>> + *
>> + * This program is free software; you may redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; version 2 of the License.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
>> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
>> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
>> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
>> + * SOFTWARE.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/*
>> + * Unfortunately it turns out that we have a chicken-and-egg situation
>> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
>> + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
>> + * Parade PS176), but they do not wire up the CEC pin, thus making CEC
>> + * useless.
>> + *
>> + * Sadly there is no way for this driver to know this. What happens is
>> + * that a /dev/cecX device is created that is isolated and unable to see
>> + * any of the other CEC devices. Quite literally the CEC wire is cut
>> + * (or in this case, never connected in the first place).
>> + *
>> + * I suspect that the reason so few adapters support this is that this
>> + * tunneling protocol was never supported by any OS. So there was no
>> + * easy way of testing it, and no incentive to correctly wire up the
>> + * CEC pin.
>> + *
>> + * Hopefully by creating this driver it will be easier for vendors to
>> + * finally fix their adapters and test the CEC functionality.
>> + *
>> + * I keep a list of known working adapters here:
>> + *
>> + * https://hverkuil.home.xs4all.nl/cec-status.txt
>> + *
>> + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
>> + * and is not yet listed there.
>> + */
>> +
>> +/**
>> + * DOC: dp cec helpers
>> + *
>> + * These functions take care of supporting the CEC-Tunneling-over-AUX
>> + * feature of DisplayPort-to-HDMI adapters.
>> + */
>> +
>> +static int drm_dp_cec_adap_e

[PATCH] drm/ttm: fix memory leak while individualizing BOs

[Christian König]

From: Christian König 

We need to free the reservation object before we take the BO
from the delayed delete list.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bee77d3..d79607a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -557,6 +557,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
}
 
ttm_bo_del_from_lru(bo);
+   if (!list_empty(&bo->ddestroy) && (bo->resv != &bo->ttm_resv))
+   reservation_object_fini(&bo->ttm_resv);
list_del_init(&bo->ddestroy);
kref_put(&bo->list_kref, ttm_bo_ref_bug);
 
-- 
2.7.4

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

[Bug 196771] [AMDGPU] Scrambled video output during boot on WQHD monitor

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer (mic...@daenzer.net) ---
Any chance you can try an amd-staging kernel with DC enabled, to see if it
happens with that as well?

-- 
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: [PATCHv4 3/5] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

On 09/12/2017 04:43 PM, Rob Herring wrote:
> On Thu, Aug 31, 2017 at 01:01:54PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Document the bindings for the cec-gpio module for hardware where the
>> CEC line and optionally the HPD line are connected to GPIO lines.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  .../devicetree/bindings/media/cec-gpio.txt | 22 
>> ++
>>  1 file changed, 22 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
>> b/Documentation/devicetree/bindings/media/cec-gpio.txt
>> new file mode 100644
>> index ..db20a7452dbd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
>> @@ -0,0 +1,22 @@
>> +* HDMI CEC GPIO driver
>> +
>> +The HDMI CEC GPIO module supports CEC implementations where the CEC line
>> +is hooked up to a pull-up GPIO line and - optionally - the HPD line is
>> +hooked up to another GPIO line.
>> +
>> +Required properties:
>> +  - compatible: value must be "cec-gpio"
>> +  - cec-gpio: gpio that the CEC line is connected to
> 
> cec-gpios

Will change.

> 
>> +
>> +Optional property:
>> +  - hpd-gpio: gpio that the HPD line is connected to
> 
> hpd-gpios

Will change.

> 
> However, HPD is already part of the HDMI connector binding. Having it in 
> 2 places would be wrong.

No. This is not an HDMI receiver/transmitter. There are two use-cases for this
driver:

1) For HDMI receivers/transmitters that connect the CEC pin of an HDMI connector
   to a GPIO pin. In that case the HPD goes to the HDMI transmitter/receiver and
   not to this driver. As you say, that would not make any sense.

   But currently no such devices are in the kernel (I know they exist, though).
   Once such a driver would appear in the kernel then these bindings need to be
   extended with an hdmi-phandle.

2) This driver is used for debugging CEC like this:

https://hverkuil.home.xs4all.nl/rpi3-cec.jpg

   Here the CEC pin of an HDMI breakout connector is hooked up to a Raspberry Pi
   GPIO pin and the RPi monitors it. It's a cheap but very effective CEC 
analyzer.
   In this use-case it is very helpful to also monitor the HPD pin since some
   displays do weird things with the HPD and knowing the state of the HPD helps
   a lot when debugging CEC problems. It's optional and it only monitors the 
pin.

   Actually, there does not have to be an HDMI connector involved at all: you 
can
   make two cec-gpio instances and just connect the two GPIO pins together in
   order to emulate two CEC adapters and play with that.

> 
> I think we should have either:
> 
> hdmi-connector {
>   compatible = 'hdmi-connector-a";
>   hpd-gpios = <...>;
>   cec-gpios = <...>;
>   ports {
>   // port to HDMI controller
>   ...
>   };
> };
> 
> Or:
> 
> hdmi-connector {
> compatible = 'hdmi-connector-a";
> hpd-gpios = <...>;
> cec = <&cec>;
> ... 
> };
> 
> cec: cec-gpio {
>   compatible = "cec-gpio";
>   cec-gpios = <...>;
> };
> 
> My preference is probably the former. The latter just helps create a 
> device to bind to a driver, but DT is not the only way to create 
> devices. Then again, if you have a phandle to real CEC controllers in 
> the HDMI connector node, it may make sense to do the same thing with 
> cec-gpio. 
> 
>> +
>> +Example for the Raspberry Pi 3 where the CEC line is connected to
>> +pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
>> +connected to pin 11 aka BCM17:
>> +
>> +cec-gpio@7 {
> 
> unit address is not valid. Build your dts's with W=2.

I'll do that.

> 
>> +   compatible = "cec-gpio";
>> +   cec-gpio = <&gpio 7 GPIO_OPEN_DRAIN>;
>> +   hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
>> +};
>> -- 
>> 2.14.1

Regards,

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[zhoucm1]

On 2017年09月13日 15:09, Christian König wrote:

syncfile is the older implementation, sync_obj is the replacement for it.


Are you sure sync_obj is a replacement for syncfile? Anyone can clarify it?

sync_obj is mainly for semaphore usage, we can see sync_obj docs from 
Dave in drm_syncobj.c:

"/**
 * DOC: Overview
 *
 * DRM synchronisation objects (syncobj) are a persistent objects,
 * that contain an optional fence. The fence can be updated with a new
 * fence, or be NULL.
 *
 * syncobj's can be export to fd's and back, these fd's are opaque and
 * have no other use case, except passing the syncobj between processes.
 *
 * Their primary use-case is to implement Vulkan fences and semaphores.
 *
 * syncobj have a kref reference count, but also have an optional file.
 * The file is only created once the syncobj is exported.
 * The file takes a reference on the kref.
 */
"



I don't think we should implement syncfile in the CS any more, 
sync_obj is already done and can be converted to/from syncfiles.


Mareks IOCTL should cover the case when we need to create a syncfile 
or syncobj from a fence sequence number.


I know his convertion can do that things, but returning syncfile fd 
directly is a really simple method.


Regards,
David Zhou


Regards,
Christian.

Am 13.09.2017 um 09:03 schrieb zhoucm1:
I really very surprise that you prefer to expand sync_obj to get 
syncfile fd!!!


Why not directly generate syncfile fd and use it? Which one is simple 
is so obvious.


Regards,
David Zhou
On 2017年09月13日 14:57, Christian König wrote:

Hi guys,

Mareks IOCTL proposal looks really good to me.

Please note that we already have sync_obj support for the CS IOCTL 
in the 4.13 branch and this work is based on top of that.



UMD don't need to construct ip_type/ip_instance/ctx_id/ring
Well the UMD does want to construct ip_type/ip_instance/ctx_id/ring 
and use for the simple reason that it allows more flexibility than 
sync_obj/sync_file.


Thinking more about this I'm pretty sure we want to do something 
similar for VM map/unmap operations as well.


Regards,
Christian.

Am 13.09.2017 um 05:03 schrieb zhoucm1:

Hi Marek,

You're doing same things with me, see my "introduce syncfile as 
fence reuturn" patch set, which makes things more simple, we just 
need to directly return syncfile fd to UMD when CS, then the fence 
UMD get will be always syncfile fd, UMD don't need to construct 
ip_type/ip_instance/ctx_id/ring any more, which also can pass to 
dependency and syncobj as well.


Regards,
David Zhou
On 2017年09月13日 04:42, Marek Olšák wrote:

From: Marek Olšák 

for being able to convert an amdgpu fence into one of the handles.
Mesa will use this.

Signed-off-by: Marek Olšák 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 61 
+

  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
  include/uapi/drm/amdgpu_drm.h   | 16 +
  5 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

index b5c8b90..c15fa93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1308,6 +1308,8 @@ int amdgpu_gem_va_ioctl(struct drm_device 
*dev, void *data,

  int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
  int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct 
drm_file *filp);
+int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void 
*data,

+struct drm_file *filp);
  int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp);

  int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

index 7cb8a59..6dd719c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
   *Jerome Glisse 
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1311,6 +1312,66 @@ static struct dma_fence 
*amdgpu_cs_get_fence(struct amdgpu_device *adev,

  return fence;
  }
  +int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, 
void *data,

+struct drm_file *filp)
+{
+struct amdgpu_device *adev = dev->dev_private;
+struct amdgpu_fpriv *fpriv = filp->driver_priv;
+union drm_amdgpu_fence_to_handle *info = data;
+struct dma_fence *fence;
+struct drm_syncobj *syncobj;
+struct sync_file *sync_file;
+int fd, r;
+
+if (amdgpu_kms_vram_lost(adev, fpriv))
+return -ENODEV;
+
+fence = amdgpu_cs_get_fence(adev, filp, &info->in.fence);
+if (IS_ERR(fence))
+return PTR_ERR(fence);
+
+switch (info->in.what) {
+case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ:
+r = drm_syncobj_create(&syncobj

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

[Christian König]

Am 13.09.2017 um 09:39 schrieb zhoucm1:



On 2017年09月13日 15:09, Christian König wrote:
syncfile is the older implementation, sync_obj is the replacement for 
it.


Are you sure sync_obj is a replacement for syncfile? Anyone can 
clarify it?


sync_obj is mainly for semaphore usage, we can see sync_obj docs from 
Dave in drm_syncobj.c:

"/**
 * DOC: Overview
 *
 * DRM synchronisation objects (syncobj) are a persistent objects,
 * that contain an optional fence. The fence can be updated with a new
 * fence, or be NULL.
 *
 * syncobj's can be export to fd's and back, these fd's are opaque and
 * have no other use case, except passing the syncobj between processes.
 *
 * Their primary use-case is to implement Vulkan fences and semaphores.
 *
 * syncobj have a kref reference count, but also have an optional file.
 * The file is only created once the syncobj is exported.
 * The file takes a reference on the kref.
 */
"



Correct, but you can convert from sync_obj into syncfile and back using 
a standard DRM IOCTL. So when we support sync_obj we also support syncfile.




I don't think we should implement syncfile in the CS any more, 
sync_obj is already done and can be converted to/from syncfiles.


Mareks IOCTL should cover the case when we need to create a syncfile 
or syncobj from a fence sequence number.


I know his convertion can do that things, but returning syncfile fd 
directly is a really simple method.


Well we can use sync_obj for this as well, it doesn't make so much 
difference.


Point is we shouldn't return a syncfile for VM operations because that 
will always use an fd which isn't very desirable.


Regards,
Christian.



Regards,
David Zhou


Regards,
Christian.

Am 13.09.2017 um 09:03 schrieb zhoucm1:
I really very surprise that you prefer to expand sync_obj to get 
syncfile fd!!!


Why not directly generate syncfile fd and use it? Which one is 
simple is so obvious.


Regards,
David Zhou
On 2017年09月13日 14:57, Christian König wrote:

Hi guys,

Mareks IOCTL proposal looks really good to me.

Please note that we already have sync_obj support for the CS IOCTL 
in the 4.13 branch and this work is based on top of that.



UMD don't need to construct ip_type/ip_instance/ctx_id/ring
Well the UMD does want to construct ip_type/ip_instance/ctx_id/ring 
and use for the simple reason that it allows more flexibility than 
sync_obj/sync_file.


Thinking more about this I'm pretty sure we want to do something 
similar for VM map/unmap operations as well.


Regards,
Christian.

Am 13.09.2017 um 05:03 schrieb zhoucm1:

Hi Marek,

You're doing same things with me, see my "introduce syncfile as 
fence reuturn" patch set, which makes things more simple, we just 
need to directly return syncfile fd to UMD when CS, then the fence 
UMD get will be always syncfile fd, UMD don't need to construct 
ip_type/ip_instance/ctx_id/ring any more, which also can pass to 
dependency and syncobj as well.


Regards,
David Zhou
On 2017年09月13日 04:42, Marek Olšák wrote:

From: Marek Olšák 

for being able to convert an amdgpu fence into one of the handles.
Mesa will use this.

Signed-off-by: Marek Olšák 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 61 
+

  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
  include/uapi/drm/amdgpu_drm.h   | 16 +
  5 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h

index b5c8b90..c15fa93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1308,6 +1308,8 @@ int amdgpu_gem_va_ioctl(struct drm_device 
*dev, void *data,

  int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
  int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct 
drm_file *filp);
+int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void 
*data,

+struct drm_file *filp);
  int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp);
  int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void 
*data,

  struct drm_file *filp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

index 7cb8a59..6dd719c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
   *Jerome Glisse 
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1311,6 +1312,66 @@ static struct dma_fence 
*amdgpu_cs_get_fence(struct amdgpu_device *adev,

  return fence;
  }
  +int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, 
void *data,

+struct drm_file *filp)
+{
+struct amdgpu_device *adev = dev->dev_private;
+struct amdgpu_fpriv *fpriv = filp->driver_priv;
+union drm_amdgpu_fence_to_handle *info = data

Re: [PATCH v2 1/6] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting, v2.

[Maarten Lankhorst]

Op 12-09-17 om 15:56 schreef Emil Velikov:
> On 12 September 2017 at 14:37, Maarten Lankhorst
>  wrote:
>> When we want to make drm_atomic_commit interruptible, there are a lot of
>> places that call the lock function, which we don't have control over.
>>
>> Rather than trying to convert every single one, it's easier to toggle
>> interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is
>> called with DRM_MODESET_ACQUIRE_INTERRUPTIBLE, then we will perform
>> interruptible waits in drm_modeset_lock and drm_modeset_backoff.
>>
>> Changes since v1:
>> - Fix locking example in drm_modeset_lock.c to be compatible
>>   with interruptible waiting (xexaxo) and make it default.
>>   Uninterruptible waiting shouldn't happen except in corner cases,
>>   but the example will still apply if the flag is removed.
>> - Add drm_modeset_lock_single_interruptible() to documentation.
>> - Fix dead link to removed drm_modeset_lock_interruptible() in
>>   drm_modeset_lock().
>>
>> Signed-off-by: Maarten Lankhorst 
>> Reviewed-by: Daniel Vetter  #v1
>> Cc: Emil Velikov 
> Thanks for the documentation updates/fixes Maarten. FWIW the series is
> Reviewed-by: Emil Velikov 
>
> -Emil

Thanks, applied. :)

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

[Bug 102695] drm-next-4.15-wip screen freeze and warning at drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1027 amdgpu_bo_gpu_offset+0x8e/0xa0

[bugzilla-daemon]

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

Bug ID: 102695
   Summary: drm-next-4.15-wip screen freeze and warning at
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1027
amdgpu_bo_gpu_offset+0x8e/0xa0
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: haa...@frickel.club

Created attachment 134193
  --> https://bugs.freedesktop.org/attachment.cgi?id=134193&action=edit
full dmesg

RX 480, mesa git, llvm-svn 312959.

Currently with 27d48238f551177c01badd504f060b010b4b3ae2 but that has been
happening since at least the update from last week too, but probably longer.
It's happening very randomly, sometimes it takes many hours, sometimes only
few.

No idea yet what triggers it, possibly something in firefox (nightly), so
that's just for tracking it.

Symptoms are the screen freezing and this message appears in dmesg

Sep 13 09:35:01 c-l kernel: [ cut here ]
Sep 13 09:35:01 c-l kernel: WARNING: CPU: 4 PID: 630 at
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1027 amdgpu_bo_gpu_offset+0x8e/0xa0
[amdgpu]
Sep 13 09:35:01 c-l kernel: Modules linked in: cmac rfcomm bnep
cpufreq_ondemand msr nls_iso8859_1 nls_cp437 vfat fat btusb uvcvideo btrtl
btbcm btintel videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 bluetoo
Sep 13 09:35:01 c-l kernel:  tpm_tis tpm_tis_core pcspkr k10temp i2c_piix4
shpchp wmi tpm 8250_dw button acpi_cpufreq sch_fq_codel hwmon_vid fuse nfsd
auth_rpcgss oid_registry nfs_acl lockd grace sunrpc sg ip_t
Sep 13 09:35:01 c-l kernel: CPU: 4 PID: 630 Comm: amdgpu_cs:0 Not tainted
4.13.0-rc5-g27d48238f551 #29
Sep 13 09:35:01 c-l kernel: Hardware name: System manufacturer System Product
Name/PRIME B350-PLUS, BIOS 0806 07/12/2017
Sep 13 09:35:01 c-l kernel: task: 8807f9b69e00 task.stack: c900088f4000
Sep 13 09:35:01 c-l kernel: RIP: 0010:amdgpu_bo_gpu_offset+0x8e/0xa0 [amdgpu]
Sep 13 09:35:01 c-l kernel: RSP: 0018:c900088f7890 EFLAGS: 00010246
Sep 13 09:35:01 c-l kernel: RAX:  RBX: 8807f7d6c800 RCX:
00100040
Sep 13 09:35:01 c-l kernel: RDX: 0040 RSI: 00f5fffe RDI:
8807f7d6c800
Sep 13 09:35:01 c-l kernel: RBP: c900088f7898 R08: 8807e6a02800 R09:
c900088f78f8
Sep 13 09:35:01 c-l kernel: R10:  R11: c900088f7900 R12:
8807f7d6d800
Sep 13 09:35:01 c-l kernel: R13: 0020 R14: 00100020 R15:
c900088f79e8
Sep 13 09:35:01 c-l kernel: FS:  7f680ea7b700()
GS:88081ed0() knlGS:
Sep 13 09:35:01 c-l kernel: CS:  0010 DS:  ES:  CR0: 80050033
Sep 13 09:35:01 c-l kernel: CR2: 7f67e4d91000 CR3: 0007f9125000 CR4:
003406e0
Sep 13 09:35:01 c-l kernel: Call Trace:
Sep 13 09:35:01 c-l kernel:  amdgpu_vm_update_ptes+0x1ca/0x350 [amdgpu]
Sep 13 09:35:01 c-l kernel:  ? amdgpu_vm_do_set_ptes+0x100/0x100 [amdgpu]
Sep 13 09:35:01 c-l kernel:  ? amdgpu_vm_do_set_ptes+0x100/0x100 [amdgpu]
Sep 13 09:35:01 c-l kernel:  amdgpu_vm_frag_ptes+0x10a/0x130 [amdgpu]
Sep 13 09:35:01 c-l kernel:  amdgpu_vm_bo_update_mapping+0x335/0x3e0 [amdgpu]
Sep 13 09:35:01 c-l kernel:  ? amdgpu_vm_do_set_ptes+0x100/0x100 [amdgpu]
Sep 13 09:35:01 c-l kernel:  amdgpu_vm_bo_update+0x2ad/0x530 [amdgpu]
Sep 13 09:35:01 c-l kernel:  amdgpu_vm_handle_moved+0x7d/0xb0 [amdgpu]
Sep 13 09:35:01 c-l kernel:  amdgpu_cs_ioctl+0x1af3/0x1b80 [amdgpu]
Sep 13 09:35:01 c-l kernel:  ? amdgpu_cs_find_mapping+0xd0/0xd0 [amdgpu]
Sep 13 09:35:01 c-l kernel:  drm_ioctl_kernel+0x5d/0xb0 [drm]
Sep 13 09:35:01 c-l kernel:  drm_ioctl+0x32a/0x400 [drm]
Sep 13 09:35:01 c-l kernel:  ? amdgpu_cs_find_mapping+0xd0/0xd0 [amdgpu]
Sep 13 09:35:01 c-l kernel:  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
Sep 13 09:35:01 c-l kernel:  do_vfs_ioctl+0xa5/0x600
Sep 13 09:35:01 c-l kernel:  ? __fget+0x6e/0x90
Sep 13 09:35:01 c-l kernel:  SyS_ioctl+0x79/0x90
Sep 13 09:35:01 c-l kernel:  entry_SYSCALL_64_fastpath+0x1a/0xa5
Sep 13 09:35:01 c-l kernel: RIP: 0033:0x7f681b76d0c7
Sep 13 09:35:01 c-l kernel: RSP: 002b:7f680ea7ab18 EFLAGS: 0246
ORIG_RAX: 0010
Sep 13 09:35:01 c-l kernel: RAX: ffda RBX: 00242b43a3b8 RCX:
7f681b76d0c7
Sep 13 09:35:01 c-l kernel: RDX: 7f680ea7ab90 RSI: c0186444 RDI:
0018
Sep 13 09:35:01 c-l kernel: RBP: 0024294b4b48 R08: 7f680ea7ac20 R09:
7f680ea7ab60
Sep 13 09:35:01 c-l kernel: R10: 7f680ea7ac20 R11: 0246 R12:
0002
Sep 13 09:35:01 c-l kernel: R13: 0001 R14: 0001 R15:
0008
Sep 13 09:35:01 c-l kernel: Code: 00 00 20 75 e9 0f ff 48 8b 83 08 02 00 00 5b
5d c3 48 8b bf f8 00 00 00 e8 e0 cb ff ff 84 c0 75 02 0f ff 8b 83 b4 00 00 00
eb 8e <0f> ff eb 8a 0f ff eb b6