date:20160926

Re: [PATCH 0/3] drm/amdgpu: implement raster configuration

2016-09-26 Thread Marek Olšák

On Mon, Sep 26, 2016 at 10:42 PM, Deucher, Alexander
 wrote:
>> -Original Message-
>> From: Marek Olšák [mailto:mar...@gmail.com]
>> Sent: Monday, September 26, 2016 4:39 PM
>> To: Huang, Ray
>> Cc: amd-gfx mailing list; Deucher, Alexander; Wang, Ken; Huan, Alvin
>> Subject: Re: [PATCH 0/3] drm/amdgpu: implement raster configuration
>>
>> The series is missing a DRM version bump, so Mesa can't really use it
>> even if it wanted.
>>
>
> We bumped it already this cycle for several other things, but I can add a 
> specific bump for this as well if that is preferred.

Oh, that's not necessary. One bump per cycle is OK.

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

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

2016-09-26 Thread Grazvydas Ignotas

On Mon, Sep 26, 2016 at 8:29 PM, Lukas Wunner  wrote:
> On Sun, Sep 25, 2016 at 11:34:48PM +0300, Grazvydas Ignotas wrote:
>> Some code called by drm_crtc_force_disable_all() wants to wait for all
>> fences, so only do fence teardown after CRTCs are disabled.
>
> Ugh, how embarrassing, that was added by me.
>
> Do you have a BUG splat (e.g. soft lockup) for this?  I'd be curious to
> see exactly where things explode, would also be good to have that in
> the commit message.

It can be seen here, the first one:
https://bugs.freedesktop.org/attachment.cgi?id=126769
I'm not sure it's that useful to have the full BUG dump with all the
registers, pointers and stuff in the commit message, like some people
like to have, most of that is only relevant for my specific build.

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

[PATCH] drm/amdgpu: add version bump for raster config programming

2016-09-26 Thread Alex Deucher

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 2be20b4..28c6ea8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -57,9 +57,10 @@
  * - 3.5.0 - Add support for new UVD_NO_OP register.
  * - 3.6.0 - kmd involves use CONTEXT_CONTROL in ring buffer.
  * - 3.7.0 - Add support for VCE clock list packet
+ * - 3.8.0 - Add support raster config init in the kernel
  */
 #define KMS_DRIVER_MAJOR   3
-#define KMS_DRIVER_MINOR   7
+#define KMS_DRIVER_MINOR   8
 #define KMS_DRIVER_PATCHLEVEL  0
 
 int amdgpu_vram_limit = 0;
-- 
2.5.5

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

RE: [PATCH 0/3] drm/amdgpu: implement raster configuration

2016-09-26 Thread Deucher, Alexander

> -Original Message-
> From: Marek Olšák [mailto:mar...@gmail.com]
> Sent: Monday, September 26, 2016 4:39 PM
> To: Huang, Ray
> Cc: amd-gfx mailing list; Deucher, Alexander; Wang, Ken; Huan, Alvin
> Subject: Re: [PATCH 0/3] drm/amdgpu: implement raster configuration
> 
> The series is missing a DRM version bump, so Mesa can't really use it
> even if it wanted.
> 

We bumped it already this cycle for several other things, but I can add a 
specific bump for this as well if that is preferred.

Alex

> Marek
> 
> On Sun, Sep 18, 2016 at 4:36 AM, Huang Rui  wrote:
> > Hi all,
> >
> > This patch set is to introduce the raster configuration for all gfx
> > generations.
> >
> > Thanks,
> > Rui
> >
> > Huang Rui (3):
> >   drm/amdgpu: implement raster configuration for gfx v6
> >   drm/amdgpu: implement raster configuration for gfx v7
> >   drm/amdgpu: implement raster configuration for gfx v8
> >
> >  drivers/gpu/drm/amd/amdgpu/cikd.h |  36 ++
> >  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 133
> +++-
> >  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 160
> +++-
> >  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 168
> +-
> >  drivers/gpu/drm/amd/amdgpu/vid.h  |  37 ++
> >  drivers/gpu/drm/amd/include/asic_reg/si/sid.h |  35 ++
> >  6 files changed, 566 insertions(+), 3 deletions(-)
> >
> > --
> > 2.7.4
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 0/3] drm/amdgpu: implement raster configuration

2016-09-26 Thread Marek Olšák

The series is missing a DRM version bump, so Mesa can't really use it
even if it wanted.

Marek

On Sun, Sep 18, 2016 at 4:36 AM, Huang Rui  wrote:
> Hi all,
>
> This patch set is to introduce the raster configuration for all gfx
> generations.
>
> Thanks,
> Rui
>
> Huang Rui (3):
>   drm/amdgpu: implement raster configuration for gfx v6
>   drm/amdgpu: implement raster configuration for gfx v7
>   drm/amdgpu: implement raster configuration for gfx v8
>
>  drivers/gpu/drm/amd/amdgpu/cikd.h |  36 ++
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 133 +++-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 160 +++-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 168 
> +-
>  drivers/gpu/drm/amd/amdgpu/vid.h  |  37 ++
>  drivers/gpu/drm/amd/include/asic_reg/si/sid.h |  35 ++
>  6 files changed, 566 insertions(+), 3 deletions(-)
>
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: add the interface of waiting multiple fences (v3)

2016-09-26 Thread Dave Airlie

On 13 September 2016 at 04:48, Deucher, Alexander
 wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Christian König
>> Sent: Monday, September 12, 2016 2:46 PM
>> To: Bas Nieuwenhuizen; Alex Deucher
>> Cc: Zhang, Jerry; amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu: add the interface of waiting multiple
>> fences (v3)
>>
>> Yeah, we added that later on.
>>
>> Looks like Alex (or somebody else) squashed the original and follow up
>> patch for libdrm together, but forgot to do so for the kernel side.
>>
>> Just wait a moment, if Alex can't find that of hand I'm going to take a
>> look through the branches tomorrow.
>
> I found it.  Looks like the commit message got messed up.  I'll fix it up and 
> send it out shortly.
>

Is this also missing an interface version bump so we know we can use it?

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

Re: [PATCH] drm/amdgpu/i2c: add const where appropriate

2016-09-26 Thread Alex Deucher

On Sun, Sep 25, 2016 at 4:34 PM, Grazvydas Ignotas  wrote:
> Signed-off-by: Grazvydas Ignotas 
> ---

Applied this whole set of patches.  Thanks!

Alex

>  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 14 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h | 14 +++---
>  2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> index c93a92a..34bab61 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c
> @@ -158,8 +158,8 @@ static const struct i2c_algorithm 
> amdgpu_atombios_i2c_algo = {
>  };
>
>  struct amdgpu_i2c_chan *amdgpu_i2c_create(struct drm_device *dev,
> -   struct amdgpu_i2c_bus_rec *rec,
> -   const char *name)
> + const struct amdgpu_i2c_bus_rec 
> *rec,
> + const char *name)
>  {
> struct amdgpu_i2c_chan *i2c;
> int ret;
> @@ -249,8 +249,8 @@ void amdgpu_i2c_fini(struct amdgpu_device *adev)
>
>  /* Add additional buses */
>  void amdgpu_i2c_add(struct amdgpu_device *adev,
> -struct amdgpu_i2c_bus_rec *rec,
> -const char *name)
> +   const struct amdgpu_i2c_bus_rec *rec,
> +   const char *name)
>  {
> struct drm_device *dev = adev->ddev;
> int i;
> @@ -266,7 +266,7 @@ void amdgpu_i2c_add(struct amdgpu_device *adev,
>  /* looks up bus based on id */
>  struct amdgpu_i2c_chan *
>  amdgpu_i2c_lookup(struct amdgpu_device *adev,
> -  struct amdgpu_i2c_bus_rec *i2c_bus)
> + const struct amdgpu_i2c_bus_rec *i2c_bus)
>  {
> int i;
>
> @@ -336,7 +336,7 @@ static void amdgpu_i2c_put_byte(struct amdgpu_i2c_chan 
> *i2c_bus,
>
>  /* ddc router switching */
>  void
> -amdgpu_i2c_router_select_ddc_port(struct amdgpu_connector *amdgpu_connector)
> +amdgpu_i2c_router_select_ddc_port(const struct amdgpu_connector 
> *amdgpu_connector)
>  {
> u8 val;
>
> @@ -365,7 +365,7 @@ amdgpu_i2c_router_select_ddc_port(struct amdgpu_connector 
> *amdgpu_connector)
>
>  /* clock/data router switching */
>  void
> -amdgpu_i2c_router_select_cd_port(struct amdgpu_connector *amdgpu_connector)
> +amdgpu_i2c_router_select_cd_port(const struct amdgpu_connector 
> *amdgpu_connector)
>  {
> u8 val;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> index d81e19b..63c2ff7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.h
> @@ -25,20 +25,20 @@
>  #define __AMDGPU_I2C_H__
>
>  struct amdgpu_i2c_chan *amdgpu_i2c_create(struct drm_device *dev,
> -   struct amdgpu_i2c_bus_rec *rec,
> -   const char *name);
> + const struct amdgpu_i2c_bus_rec 
> *rec,
> + const char *name);
>  void amdgpu_i2c_destroy(struct amdgpu_i2c_chan *i2c);
>  void amdgpu_i2c_init(struct amdgpu_device *adev);
>  void amdgpu_i2c_fini(struct amdgpu_device *adev);
>  void amdgpu_i2c_add(struct amdgpu_device *adev,
> -struct amdgpu_i2c_bus_rec *rec,
> -const char *name);
> +   const struct amdgpu_i2c_bus_rec *rec,
> +   const char *name);
>  struct amdgpu_i2c_chan *
>  amdgpu_i2c_lookup(struct amdgpu_device *adev,
> -  struct amdgpu_i2c_bus_rec *i2c_bus);
> + const struct amdgpu_i2c_bus_rec *i2c_bus);
>  void
> -amdgpu_i2c_router_select_ddc_port(struct amdgpu_connector *amdgpu_connector);
> +amdgpu_i2c_router_select_ddc_port(const struct amdgpu_connector *connector);
>  void
> -amdgpu_i2c_router_select_cd_port(struct amdgpu_connector *amdgpu_connector);
> +amdgpu_i2c_router_select_cd_port(const struct amdgpu_connector *connector);
>
>  #endif
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu/vce: take all rings into account for idle checks

2016-09-26 Thread Alex Deucher

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 121bd6e..3b03558 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -305,9 +305,12 @@ static void amdgpu_vce_idle_work_handler(struct 
work_struct *work)
 {
struct amdgpu_device *adev =
container_of(work, struct amdgpu_device, vce.idle_work.work);
+   unsigned i, count = 0;
 
-   if ((amdgpu_fence_count_emitted(&adev->vce.ring[0]) == 0) &&
-   (amdgpu_fence_count_emitted(&adev->vce.ring[1]) == 0)) {
+   for (i = 0; i < adev->vce.num_rings; i++)
+   count += amdgpu_fence_count_emitted(&adev->vce.ring[i]);
+
+   if (count == 0) {
if (adev->pm.dpm_enabled) {
amdgpu_dpm_enable_vce(adev, false);
} else {
-- 
2.5.5

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

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

2016-09-26 Thread Lukas Wunner

On Sun, Sep 25, 2016 at 11:34:48PM +0300, Grazvydas Ignotas wrote:
> Some code called by drm_crtc_force_disable_all() wants to wait for all
> fences, so only do fence teardown after CRTCs are disabled.
> 
> Signed-off-by: Grazvydas Ignotas 

Fixes: 84b89bdcedf8 ("drm/amdgpu: Turn off CRTCs on driver unload")
Cc: sta...@vger.kernel.org # v4.8+

Alex, would it be possible to get this fix into 4.8 this week?

Thanks!

Lukas

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 99a15ca..1a1bc79 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1822,11 +1822,11 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>  
>   DRM_INFO("amdgpu: finishing device.\n");
>   adev->shutdown = true;
> + drm_crtc_force_disable_all(adev->ddev);
>   /* evict vram memory */
>   amdgpu_bo_evict_vram(adev);
>   amdgpu_ib_pool_fini(adev);
>   amdgpu_fence_driver_fini(adev);
> - drm_crtc_force_disable_all(adev->ddev);
>   amdgpu_fbdev_fini(adev);
>   r = amdgpu_fini(adev);
>   kfree(adev->ip_block_status);
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

2016-09-26 Thread Lukas Wunner

On Sun, Sep 25, 2016 at 11:34:48PM +0300, Grazvydas Ignotas wrote:
> Some code called by drm_crtc_force_disable_all() wants to wait for all
> fences, so only do fence teardown after CRTCs are disabled.

Ugh, how embarrassing, that was added by me.

Do you have a BUG splat (e.g. soft lockup) for this?  I'd be curious to
see exactly where things explode, would also be good to have that in
the commit message.

Thanks!

Lukas

> 
> Signed-off-by: Grazvydas Ignotas 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 99a15ca..1a1bc79 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1822,11 +1822,11 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>  
>   DRM_INFO("amdgpu: finishing device.\n");
>   adev->shutdown = true;
> + drm_crtc_force_disable_all(adev->ddev);
>   /* evict vram memory */
>   amdgpu_bo_evict_vram(adev);
>   amdgpu_ib_pool_fini(adev);
>   amdgpu_fence_driver_fini(adev);
> - drm_crtc_force_disable_all(adev->ddev);
>   amdgpu_fbdev_fini(adev);
>   r = amdgpu_fini(adev);
>   kfree(adev->ip_block_status);
> -- 
> 2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: improve VM PTE trace points

2016-09-26 Thread Alex Deucher

On Mon, Sep 26, 2016 at 7:47 AM, Christian König
 wrote:
> From: Christian König 
>
> Use a separate one for the copy operation and
> log all the interesting parameters.
>
> Signed-off-by: Christian König 

Series is:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 10 ++
>  2 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> index 0d8d65e..067e5e6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> @@ -247,7 +247,7 @@ DEFINE_EVENT(amdgpu_vm_mapping, amdgpu_vm_bo_mapping,
> TP_ARGS(mapping)
>  );
>
> -TRACE_EVENT(amdgpu_vm_set_page,
> +TRACE_EVENT(amdgpu_vm_set_ptes,
> TP_PROTO(uint64_t pe, uint64_t addr, unsigned count,
>  uint32_t incr, uint32_t flags),
> TP_ARGS(pe, addr, count, incr, flags),
> @@ -271,6 +271,24 @@ TRACE_EVENT(amdgpu_vm_set_page,
>   __entry->flags, __entry->count)
>  );
>
> +TRACE_EVENT(amdgpu_vm_copy_ptes,
> +   TP_PROTO(uint64_t pe, uint64_t src, unsigned count),
> +   TP_ARGS(pe, src, count),
> +   TP_STRUCT__entry(
> +__field(u64, pe)
> +__field(u64, src)
> +__field(u32, count)
> +),
> +
> +   TP_fast_assign(
> +  __entry->pe = pe;
> +  __entry->src = src;
> +  __entry->count = count;
> +  ),
> +   TP_printk("pe=%010Lx, src=%010Lx, count=%u",
> + __entry->pe, __entry->src, __entry->count)
> +);
> +
>  TRACE_EVENT(amdgpu_vm_flush,
> TP_PROTO(uint64_t pd_addr, unsigned ring, unsigned id),
> TP_ARGS(pd_addr, ring, id),
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index da31189..bc4b22c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -487,7 +487,7 @@ static void amdgpu_vm_do_set_ptes(struct 
> amdgpu_pte_update_params *params,
>   unsigned count, uint32_t incr,
>   uint32_t flags)
>  {
> -   trace_amdgpu_vm_set_page(pe, addr, count, incr, flags);
> +   trace_amdgpu_vm_set_ptes(pe, addr, count, incr, flags);
>
> if (count < 3) {
> amdgpu_vm_write_pte(params->adev, params->ib, pe,
> @@ -516,10 +516,12 @@ static void amdgpu_vm_do_copy_ptes(struct 
> amdgpu_pte_update_params *params,
>unsigned count, uint32_t incr,
>uint32_t flags)
>  {
> -   trace_amdgpu_vm_set_page(pe, addr, count, incr, flags);
> +   uint64_t src = (params->src + (addr >> 12) * 8);
>
> -   amdgpu_vm_copy_pte(params->adev, params->ib, pe,
> -  (params->src + (addr >> 12) * 8), count);
> +
> +   trace_amdgpu_vm_copy_ptes(pe, src, count);
> +
> +   amdgpu_vm_copy_pte(params->adev, params->ib, pe, src, count);
>  }
>
>  /**
> --
> 2.5.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: bind GTT on demand

2016-09-26 Thread Andy Furniss

With current drm-next-4.9-wip plus  drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping


testdma is now working OK for my R9285 - just did 35k tests while 
simultaneously running valley/heaven, plus messing with 
powerplay/cpufreq and all is

good, no lock, no vm faults.


Andy Furniss wrote:

Christian König wrote:

Am 22.09.2016 um 23:54 schrieb Andy Furniss:

Marek Olšák wrote:

This breaks Tonga such that it hangs. Reproducible quickly with:

R600_DEBUG=testdma glxgears

It's a randomized test that runs forever. It should hang within 2
seconds.


So what is the status of this now?


The status is that I'm hammering my head on the desk for two weeks now
what the heck is going wrong here.


Oh, OK, I was just checking no one thought it was fixed really.



What I've found so far is that a VM update command doesn't have the
result it should have, but I absolutely don't understand what happens
here.

The good news is that it's 100% reproducible and I already found and
fixed two bugs.

If you have any idea or more testing results what is going wrong here
please let me know.


I guess, you already did it anyway or it doesn't help, but

R600_DEBUG=testdma,check_vm glxgears

Does catch a vmfault and output to ddebug_dumps.
It initially saves me from locking, though I will lock on repeated runs.



If we can't fix this before the 4.9 release we are just going to revert
the patch causing this.

Regards,
Christian.



R600_DEBUG=testdma glxgears isn't a test I've run on my r9285 tonga
until I, by luck, saw this.

On agddf 4.9-wip at post time it did hang/reboot after 2 seconds.

On every update since it's still hung though now it takes longer.

Todays update tested both on head and reset on to the drm-next tag
still hang.

Going back over older 4.9-wips it's one built on 26th August that is
the first not to hang.



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








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

Re: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

2016-09-26 Thread Daniel Vetter

On Mon, Sep 26, 2016 at 09:48:37AM +0900, Michel Dänzer wrote:
> On 23/09/16 09:09 PM, Daniel Vetter wrote:
> > On Fri, Sep 23, 2016 at 07:00:25PM +0900, Michel Dänzer wrote:
> >> On 22/09/16 10:22 PM, Christian König wrote:
> >>> Am 22.09.2016 um 15:05 schrieb Daniel Vetter:
>  
>  But the current approach in amdgpu_sync.c of declaring a fence as
>  exclusive after the fact (if owners don't match) just isn't how
>  reservation_object works. You can of course change that, but that
>  means you must change all drivers implementing support for implicit
>  fencing of dma-buf. Fixing amdgpu will be easier ;-)
> >>>
> >>> Well as far as I can see there is no way I can fix amdgpu in this case.
> >>>
> >>> The handling clearly needs to be changed on the receiving side of the
> >>> reservation objects if I don't completely want to disable concurrent
> >>> access to BOs in amdgpu.
> >>
> >> Anyway, we need a solution for this between radeon and amdgpu, and I
> >> don't think a solution which involves those drivers using reservation
> >> object semantics between them which are different from all other drivers
> >> is a good idea.
> > 
> > Afaik there's also amd+intel machines out there,
> 
> Sure, what I meant was that even if we didn't care about those (which we
> do), we'd still need a solution between our own drivers.
> 
> 
> > so really the only option is to either fix amdgpu to correctly set
> > exclusive fences on shared buffers (with the help of userspace hints).
> > Or change all the existing drivers.
> 
> I got some fresh perspective on the problem while taking a walk, and I'm
> now fairly convinced that neither amdgpu userspace nor other drivers
> need to be modified:
> 
> It occurred to me that all the information we need is already there in
> the exclusive and shared fences set by amdgpu. We just need to use it
> differently to match the expectations of other drivers.
> 
> We should be able to set some sort of "pseudo" fence as the exclusive
> fence of the reservation object. When we are asked by another driver to
> wait for this fence to signal, we take the current "real" exclusive
> fence (which we can keep track of e.g. in our BO struct) and shared
> fences, and wait for all of those to signal; then we mark the "pseudo"
> exclusive fence as signalled.
> 
> Am I missing anything which would prevent this from working?

One thing to make sure is that you don't change the (real, private stored)
fences you're waiting on over the lifetime of the public exclusive fence.
That might lead to some hilarity wrt potentially creating fence depency
loops. But I think as long as you guarantee that the private internal
fences are always amdgpu ones, and never anything imported from a
different driver even that should be fine. Not because this would break
the loops, but since amgpud has a hangcheck it can still gurantee that the
fence eventually fires even if there is a loop.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

2016-09-26 Thread Deucher, Alexander

Wait, nevermind.  It would be good to add a comment that addr needs to be reset 
to 0 in this case since it's used below in the amdgpu_vm_frag_ptes().

The patch is:
Reviewed-by: Alex Deucher 

From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Deucher, Alexander
Sent: Monday, September 26, 2016 11:17 AM
To: 'Christian König'; StDenis, Tom; Cui, Flora
Cc: Huang, Ray; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping

Maybe it would be cleaner to just pass 0 to amdgpu_vm_frag_ptes() or remove the 
parameter altogether.

Alex

From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian König
Sent: Monday, September 26, 2016 11:12 AM
To: StDenis, Tom; Cui, Flora
Cc: Huang, Ray; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping

The function called is either amdgpu_vm_do_set_ptes() or 
amdgpu_vm_do_copy_ptes().

But that is actually rather unrelated to the local handling of addr in the 
function changed.

The point here is we have handled the address offset by giving it to 
amdgpu_vm_map_gart() and so we shouldn't add the address again.

Regards,
Christian.

Am 26.09.2016 um 15:46 schrieb StDenis, Tom:

I'm reading through the amdgpu_vm.c to try and see if the patch is correct but 
I'm not that familiar with the VM side of things.  It seems to boil down to 
calling params->func() with a new dst value of NULL but that's where I'm 
stopped at the moment since I don't know what func() is.  Nothing up to that 
point looks overtly wrong (like trying to use that address as a source for a 
read/write).



Tom


From: amd-gfx 

 on behalf of Christian König 

Sent: Monday, September 26, 2016 09:29
To: Cui, Flora
Cc: Huang, Ray; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping

Yeah, that wouldn't really help but just make the problem more unlikely
to happen once more.

Anyway Tom St confirmed that the patch seems to work for the open stack.

Anybody brave enough to throw an rb on this so that I can commit it?

Thanks,
Christian.

Am 26.09.2016 um 11:16 schrieb Flora Cui:
> please ignore this patch. it actually revert the gtt mgr changes.
>
> On Mon, Sep 26, 2016 at 03:19:01PM +0800, Flora Cui wrote:
>> On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote:
>>> From: Christian König 
>>> 
>>>
>>> Otherwise we will look at the wrong place in the IB when GART
>>> mappings are split into smaller updates.
>>>
>>> Signed-off-by: Christian König 
>>> 
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index 2bb78dc..da31189 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -1017,6 +1017,7 @@ static int amdgpu_vm_bo_update_mapping(struct 
>>> amdgpu_device *adev,
>>>  AMDGPU_GPU_PAGE_SIZE);
>>>  pte[i] |= flags;
>>>  }
>>> +   addr = 0;
>>>  }
>>>
>>>  r = amdgpu_sync_fence(adev, &job->sync, exclusive);
>>> --
>>> 2.5.0
>>>
>>>
>> IMHO this could fix the vmfault issue.
>>
>> 8<---
>>  From cc7b5618665defd88e2adcd6f735562ecd784298 Mon Sep 17 00:00:00 2001
>> From: Flora Cui 
>> Date: Mon, 26 Sep 2016 15:14:02 +0800
>> Subject: [PATCH] drm/amdgpu: add ttm_bind in amdgpu_vm_bo_update()
>>
>> Change-Id: If73d5b06e9188e40250ccdfd1a2a659ed1ef52a6
>> Signed-off-by: Flora Cui 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 2bb78dc..7f17127 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1166,6 +1166,8 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
>>   ttm = container_of(bo_va->bo->tbo.ttm, struct
>>  ttm_dma_tt, ttm);
>>   pages_addr = ttm->dma_address;
>> +amdgpu_ttm_bind(&bo_va->bo->tbo, mem);
>> +addr = (u64)mem->start << PAGE_SHIFT;
>>   break;
>>
>>   case TTM_PL_VRAM:
>> --
>> 2.7.4
>>
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info

RE: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

2016-09-26 Thread Deucher, Alexander

Maybe it would be cleaner to just pass 0 to amdgpu_vm_frag_ptes() or remove the 
parameter altogether.

Alex

From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian König
Sent: Monday, September 26, 2016 11:12 AM
To: StDenis, Tom; Cui, Flora
Cc: Huang, Ray; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping

The function called is either amdgpu_vm_do_set_ptes() or 
amdgpu_vm_do_copy_ptes().

But that is actually rather unrelated to the local handling of addr in the 
function changed.

The point here is we have handled the address offset by giving it to 
amdgpu_vm_map_gart() and so we shouldn't add the address again.

Regards,
Christian.

Am 26.09.2016 um 15:46 schrieb StDenis, Tom:

I'm reading through the amdgpu_vm.c to try and see if the patch is correct but 
I'm not that familiar with the VM side of things.  It seems to boil down to 
calling params->func() with a new dst value of NULL but that's where I'm 
stopped at the moment since I don't know what func() is.  Nothing up to that 
point looks overtly wrong (like trying to use that address as a source for a 
read/write).



Tom


From: amd-gfx 

 on behalf of Christian König 

Sent: Monday, September 26, 2016 09:29
To: Cui, Flora
Cc: Huang, Ray; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping

Yeah, that wouldn't really help but just make the problem more unlikely
to happen once more.

Anyway Tom St confirmed that the patch seems to work for the open stack.

Anybody brave enough to throw an rb on this so that I can commit it?

Thanks,
Christian.

Am 26.09.2016 um 11:16 schrieb Flora Cui:
> please ignore this patch. it actually revert the gtt mgr changes.
>
> On Mon, Sep 26, 2016 at 03:19:01PM +0800, Flora Cui wrote:
>> On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote:
>>> From: Christian König 
>>> 
>>>
>>> Otherwise we will look at the wrong place in the IB when GART
>>> mappings are split into smaller updates.
>>>
>>> Signed-off-by: Christian König 
>>> 
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index 2bb78dc..da31189 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -1017,6 +1017,7 @@ static int amdgpu_vm_bo_update_mapping(struct 
>>> amdgpu_device *adev,
>>>  AMDGPU_GPU_PAGE_SIZE);
>>>  pte[i] |= flags;
>>>  }
>>> +   addr = 0;
>>>  }
>>>
>>>  r = amdgpu_sync_fence(adev, &job->sync, exclusive);
>>> --
>>> 2.5.0
>>>
>>>
>> IMHO this could fix the vmfault issue.
>>
>> 8<---
>>  From cc7b5618665defd88e2adcd6f735562ecd784298 Mon Sep 17 00:00:00 2001
>> From: Flora Cui 
>> Date: Mon, 26 Sep 2016 15:14:02 +0800
>> Subject: [PATCH] drm/amdgpu: add ttm_bind in amdgpu_vm_bo_update()
>>
>> Change-Id: If73d5b06e9188e40250ccdfd1a2a659ed1ef52a6
>> Signed-off-by: Flora Cui 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 2bb78dc..7f17127 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1166,6 +1166,8 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
>>   ttm = container_of(bo_va->bo->tbo.ttm, struct
>>  ttm_dma_tt, ttm);
>>   pages_addr = ttm->dma_address;
>> +amdgpu_ttm_bind(&bo_va->bo->tbo, mem);
>> +addr = (u64)mem->start << PAGE_SHIFT;
>>   break;
>>
>>   case TTM_PL_VRAM:
>> --
>> 2.7.4
>>
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives. Using amd-gfx: To post a message to all the list members, send email 
...



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


___
amd-gfx mailing list
amd-gfx@

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

2016-09-26 Thread Christian König

The function called is either amdgpu_vm_do_set_ptes() or 
amdgpu_vm_do_copy_ptes().


But that is actually rather unrelated to the local handling of addr in 
the function changed.


The point here is we have handled the address offset by giving it to 
amdgpu_vm_map_gart() and so we shouldn't add the address again.


Regards,
Christian.

Am 26.09.2016 um 15:46 schrieb StDenis, Tom:


I'm reading through the amdgpu_vm.c to try and see if the patch is 
correct but I'm not that familiar with the VM side of things.  It 
seems to boil down to calling params->func() with a new dst value of 
NULL but that's where I'm stopped at the moment since I don't know 
what func() is.  Nothing up to that point looks overtly wrong (like 
trying to use that address as a source for a read/write).



Tom



*From:* amd-gfx  on behalf of 
Christian König 

*Sent:* Monday, September 26, 2016 09:29
*To:* Cui, Flora
*Cc:* Huang, Ray; amd-gfx@lists.freedesktop.org
*Subject:* Re: [PATCH] drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping

Yeah, that wouldn't really help but just make the problem more unlikely
to happen once more.

Anyway Tom St confirmed that the patch seems to work for the open stack.

Anybody brave enough to throw an rb on this so that I can commit it?

Thanks,
Christian.

Am 26.09.2016 um 11:16 schrieb Flora Cui:
> please ignore this patch. it actually revert the gtt mgr changes.
>
> On Mon, Sep 26, 2016 at 03:19:01PM +0800, Flora Cui wrote:
>> On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote:
>>> From: Christian König 
>>>
>>> Otherwise we will look at the wrong place in the IB when GART
>>> mappings are split into smaller updates.
>>>
>>> Signed-off-by: Christian König 
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

>>> index 2bb78dc..da31189 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -1017,6 +1017,7 @@ static int 
amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,

>>>AMDGPU_GPU_PAGE_SIZE);
>>>  pte[i] |= flags;
>>>  }
>>> +   addr = 0;
>>>  }
>>>
>>>  r = amdgpu_sync_fence(adev, &job->sync, exclusive);
>>> --
>>> 2.5.0
>>>
>>>
>> IMHO this could fix the vmfault issue.
>>
>> 8<---
>>  From cc7b5618665defd88e2adcd6f735562ecd784298 Mon Sep 17 00:00:00 2001
>> From: Flora Cui 
>> Date: Mon, 26 Sep 2016 15:14:02 +0800
>> Subject: [PATCH] drm/amdgpu: add ttm_bind in amdgpu_vm_bo_update()
>>
>> Change-Id: If73d5b06e9188e40250ccdfd1a2a659ed1ef52a6
>> Signed-off-by: Flora Cui 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

>> index 2bb78dc..7f17127 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1166,6 +1166,8 @@ int amdgpu_vm_bo_update(struct amdgpu_device 
*adev,

>>   ttm = container_of(bo_va->bo->tbo.ttm, struct
>> ttm_dma_tt, ttm);
>>   pages_addr = ttm->dma_address;
>> + amdgpu_ttm_bind(&bo_va->bo->tbo, mem);
>> +addr = (u64)mem->start << PAGE_SHIFT;
>>   break;
>>
>>   case TTM_PL_VRAM:
>> --
>> 2.7.4
>>
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx 

amd-gfx Info Page - lists.freedesktop.org 


lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives. Using amd-gfx: To post a message to all the list members, 
send email ...




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


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



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

Re: [amdgpu][CIK] drm-next-4.9-wip - piglit test - max-texture-size - GPU deadlock

2016-09-26 Thread Marek Olšák

Hi,

You can try this patch:
  drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

Marek

On Fri, Sep 23, 2016 at 12:37 AM, Shawn Starr  wrote:
> When I try to run piglit, I get a GPU deadlock running max-texture-size,
>
> Test: spec/!opengl 1.1/max-texture-size
>
> I will begin bisecting kernel driver, but if anyone has some tips on likely
> commits I can test further.
>
> Thanks,
> Shawn
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

2016-09-26 Thread StDenis, Tom

I'm reading through the amdgpu_vm.c to try and see if the patch is correct but 
I'm not that familiar with the VM side of things.  It seems to boil down to 
calling params->func() with a new dst value of NULL but that's where I'm 
stopped at the moment since I don't know what func() is.  Nothing up to that 
point looks overtly wrong (like trying to use that address as a source for a 
read/write).


Tom


From: amd-gfx  on behalf of Christian 
König 
Sent: Monday, September 26, 2016 09:29
To: Cui, Flora
Cc: Huang, Ray; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix addr handling in 
amdgpu_vm_bo_update_mapping

Yeah, that wouldn't really help but just make the problem more unlikely
to happen once more.

Anyway Tom St confirmed that the patch seems to work for the open stack.

Anybody brave enough to throw an rb on this so that I can commit it?

Thanks,
Christian.

Am 26.09.2016 um 11:16 schrieb Flora Cui:
> please ignore this patch. it actually revert the gtt mgr changes.
>
> On Mon, Sep 26, 2016 at 03:19:01PM +0800, Flora Cui wrote:
>> On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote:
>>> From: Christian König 
>>>
>>> Otherwise we will look at the wrong place in the IB when GART
>>> mappings are split into smaller updates.
>>>
>>> Signed-off-by: Christian König 
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index 2bb78dc..da31189 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -1017,6 +1017,7 @@ static int amdgpu_vm_bo_update_mapping(struct 
>>> amdgpu_device *adev,
>>>  AMDGPU_GPU_PAGE_SIZE);
>>>  pte[i] |= flags;
>>>  }
>>> +   addr = 0;
>>>  }
>>>
>>>  r = amdgpu_sync_fence(adev, &job->sync, exclusive);
>>> --
>>> 2.5.0
>>>
>>>
>> IMHO this could fix the vmfault issue.
>>
>> 8<---
>>  From cc7b5618665defd88e2adcd6f735562ecd784298 Mon Sep 17 00:00:00 2001
>> From: Flora Cui 
>> Date: Mon, 26 Sep 2016 15:14:02 +0800
>> Subject: [PATCH] drm/amdgpu: add ttm_bind in amdgpu_vm_bo_update()
>>
>> Change-Id: If73d5b06e9188e40250ccdfd1a2a659ed1ef52a6
>> Signed-off-by: Flora Cui 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 2bb78dc..7f17127 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1166,6 +1166,8 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
>>   ttm = container_of(bo_va->bo->tbo.ttm, struct
>>  ttm_dma_tt, ttm);
>>   pages_addr = ttm->dma_address;
>> +amdgpu_ttm_bind(&bo_va->bo->tbo, mem);
>> +addr = (u64)mem->start << PAGE_SHIFT;
>>   break;
>>
>>   case TTM_PL_VRAM:
>> --
>> 2.7.4
>>
>>
>> ___
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
lists.freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives. Using amd-gfx: To post a message to all the list members, send email 
...



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


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

RE: [PATCH] drm/amdgpu: bypass vce clock if vce is idle on Fiji.

2016-09-26 Thread Deucher, Alexander

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Saturday, September 24, 2016 4:39 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH] drm/amdgpu: bypass vce clock if vce is idle on Fiji.
> 
> Change-Id: I74bdf39af332eb369e87c989b344f3e06cbfc714
> Signed-off-by: Rex Zhu 

Is there any reason not to do this for all asics?

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> index a6b4e27..43b26eb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vce_v3_0.c
> @@ -716,7 +716,8 @@ static int vce_v3_0_set_clockgating_state(void
> *handle,
>   int i;
> 
>   if ((adev->asic_type == CHIP_POLARIS10) ||
> - (adev->asic_type == CHIP_TONGA))
> + (adev->asic_type == CHIP_TONGA) ||
> +(adev->asic_type == CHIP_FIJI))
>   vce_v3_0_set_bypass_mode(adev, enable);
> 
>   if (!(adev->cg_flags & AMD_CG_SUPPORT_VCE_MGCG))
> --
> 1.9.1
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Bonair support Kernel compiling instructions

2016-09-26 Thread Christian König


Am 26.09.2016 um 02:52 schrieb Michel Dänzer:

On 26/09/16 02:55 AM, Striker Leggette wrote:

I am running a Lenovo Y700 with an R7 Carrizo APU and an R9 Bonaire GPU
on Fedora 24.  At the moment, the latest Fedora Kernel supports amdgpu
for the Carrizo, and many things run very well on this.  However, if I
run an application on the Bonaire using radeon, I get even less FPS in
those same application.

Which applications are those, and how many FPS do you get in each case?



I would like to know if there are compiling instructions for Vanilla
Kernels to enable amdgpu support for the Bonaire at this time.

As I said to you on IRC before, don't expect amdgpu to magically make
anything significantly faster.



I agree completely with Michel here, but to answer you original question 
you need to set the appropriate options while compiling your kernel.


Just disable CONFIG_DRM_RADEON and enable CONFIG_DRM_AMDGPU_CIK.

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

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

2016-09-26 Thread Christian König

Yeah, that wouldn't really help but just make the problem more unlikely 
to happen once more.


Anyway Tom St confirmed that the patch seems to work for the open stack.

Anybody brave enough to throw an rb on this so that I can commit it?

Thanks,
Christian.

Am 26.09.2016 um 11:16 schrieb Flora Cui:

please ignore this patch. it actually revert the gtt mgr changes.

On Mon, Sep 26, 2016 at 03:19:01PM +0800, Flora Cui wrote:

On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote:

From: Christian König 

Otherwise we will look at the wrong place in the IB when GART
mappings are split into smaller updates.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 2bb78dc..da31189 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1017,6 +1017,7 @@ static int amdgpu_vm_bo_update_mapping(struct 
amdgpu_device *adev,
AMDGPU_GPU_PAGE_SIZE);
pte[i] |= flags;
}
+   addr = 0;
}
  
  	r = amdgpu_sync_fence(adev, &job->sync, exclusive);

--
2.5.0



IMHO this could fix the vmfault issue.

8<---
 From cc7b5618665defd88e2adcd6f735562ecd784298 Mon Sep 17 00:00:00 2001
From: Flora Cui 
Date: Mon, 26 Sep 2016 15:14:02 +0800
Subject: [PATCH] drm/amdgpu: add ttm_bind in amdgpu_vm_bo_update()

Change-Id: If73d5b06e9188e40250ccdfd1a2a659ed1ef52a6
Signed-off-by: Flora Cui 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 2bb78dc..7f17127 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1166,6 +1166,8 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
ttm = container_of(bo_va->bo->tbo.ttm, struct
   ttm_dma_tt, ttm);
pages_addr = ttm->dma_address;
+   amdgpu_ttm_bind(&bo_va->bo->tbo, mem);
+   addr = (u64)mem->start << PAGE_SHIFT;
break;
  
  		case TTM_PL_VRAM:

--
2.7.4


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

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



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

[PATCH 2/2] drm/amdgpu: improve VM PTE trace points

2016-09-26 Thread Christian König

From: Christian König 

Use a separate one for the copy operation and
log all the interesting parameters.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 10 ++
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 0d8d65e..067e5e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -247,7 +247,7 @@ DEFINE_EVENT(amdgpu_vm_mapping, amdgpu_vm_bo_mapping,
TP_ARGS(mapping)
 );
 
-TRACE_EVENT(amdgpu_vm_set_page,
+TRACE_EVENT(amdgpu_vm_set_ptes,
TP_PROTO(uint64_t pe, uint64_t addr, unsigned count,
 uint32_t incr, uint32_t flags),
TP_ARGS(pe, addr, count, incr, flags),
@@ -271,6 +271,24 @@ TRACE_EVENT(amdgpu_vm_set_page,
  __entry->flags, __entry->count)
 );
 
+TRACE_EVENT(amdgpu_vm_copy_ptes,
+   TP_PROTO(uint64_t pe, uint64_t src, unsigned count),
+   TP_ARGS(pe, src, count),
+   TP_STRUCT__entry(
+__field(u64, pe)
+__field(u64, src)
+__field(u32, count)
+),
+
+   TP_fast_assign(
+  __entry->pe = pe;
+  __entry->src = src;
+  __entry->count = count;
+  ),
+   TP_printk("pe=%010Lx, src=%010Lx, count=%u",
+ __entry->pe, __entry->src, __entry->count)
+);
+
 TRACE_EVENT(amdgpu_vm_flush,
TP_PROTO(uint64_t pd_addr, unsigned ring, unsigned id),
TP_ARGS(pd_addr, ring, id),
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index da31189..bc4b22c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -487,7 +487,7 @@ static void amdgpu_vm_do_set_ptes(struct 
amdgpu_pte_update_params *params,
  unsigned count, uint32_t incr,
  uint32_t flags)
 {
-   trace_amdgpu_vm_set_page(pe, addr, count, incr, flags);
+   trace_amdgpu_vm_set_ptes(pe, addr, count, incr, flags);
 
if (count < 3) {
amdgpu_vm_write_pte(params->adev, params->ib, pe,
@@ -516,10 +516,12 @@ static void amdgpu_vm_do_copy_ptes(struct 
amdgpu_pte_update_params *params,
   unsigned count, uint32_t incr,
   uint32_t flags)
 {
-   trace_amdgpu_vm_set_page(pe, addr, count, incr, flags);
+   uint64_t src = (params->src + (addr >> 12) * 8);
 
-   amdgpu_vm_copy_pte(params->adev, params->ib, pe,
-  (params->src + (addr >> 12) * 8), count);
+
+   trace_amdgpu_vm_copy_ptes(pe, src, count);
+
+   amdgpu_vm_copy_pte(params->adev, params->ib, pe, src, count);
 }
 
 /**
-- 
2.5.0

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

[PATCH 1/2] drm/amdgpu: fix GART_DEBUGFS define

2016-09-26 Thread Christian König

From: Christian König 

Obviously missed during the rename.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 0feea34..21a1242 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -238,7 +238,7 @@ void amdgpu_gart_unbind(struct amdgpu_device *adev, 
uint64_t offset,
t = offset / AMDGPU_GPU_PAGE_SIZE;
p = t / (PAGE_SIZE / AMDGPU_GPU_PAGE_SIZE);
for (i = 0; i < pages; i++, p++) {
-#ifdef CONFIG_AMDGPU_GART_DEBUGFS
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
adev->gart.pages[p] = NULL;
 #endif
page_base = adev->dummy_page.addr;
@@ -286,7 +286,7 @@ int amdgpu_gart_bind(struct amdgpu_device *adev, uint64_t 
offset,
p = t / (PAGE_SIZE / AMDGPU_GPU_PAGE_SIZE);
 
for (i = 0; i < pages; i++, p++) {
-#ifdef CONFIG_AMDGPU_GART_DEBUGFS
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
adev->gart.pages[p] = pagelist[i];
 #endif
if (adev->gart.ptr) {
@@ -331,7 +331,7 @@ int amdgpu_gart_init(struct amdgpu_device *adev)
DRM_INFO("GART: num cpu pages %u, num gpu pages %u\n",
 adev->gart.num_cpu_pages, adev->gart.num_gpu_pages);
 
-#ifdef CONFIG_AMDGPU_GART_DEBUGFS
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
/* Allocate pages table */
adev->gart.pages = vzalloc(sizeof(void *) * adev->gart.num_cpu_pages);
if (adev->gart.pages == NULL) {
@@ -357,7 +357,7 @@ void amdgpu_gart_fini(struct amdgpu_device *adev)
amdgpu_gart_unbind(adev, 0, adev->gart.num_cpu_pages);
}
adev->gart.ready = false;
-#ifdef CONFIG_AMDGPU_GART_DEBUGFS
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
vfree(adev->gart.pages);
adev->gart.pages = NULL;
 #endif
-- 
2.5.0

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

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

2016-09-26 Thread Flora Cui

please ignore this patch. it actually revert the gtt mgr changes.

On Mon, Sep 26, 2016 at 03:19:01PM +0800, Flora Cui wrote:
> On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote:
> > From: Christian König 
> > 
> > Otherwise we will look at the wrong place in the IB when GART
> > mappings are split into smaller updates.
> > 
> > Signed-off-by: Christian König 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > index 2bb78dc..da31189 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> > @@ -1017,6 +1017,7 @@ static int amdgpu_vm_bo_update_mapping(struct 
> > amdgpu_device *adev,
> > AMDGPU_GPU_PAGE_SIZE);
> > pte[i] |= flags;
> > }
> > +   addr = 0;
> > }
> >  
> > r = amdgpu_sync_fence(adev, &job->sync, exclusive);
> > -- 
> > 2.5.0
> > 
> >
> 
> IMHO this could fix the vmfault issue.
> 
> 8<---
> From cc7b5618665defd88e2adcd6f735562ecd784298 Mon Sep 17 00:00:00 2001
> From: Flora Cui 
> Date: Mon, 26 Sep 2016 15:14:02 +0800
> Subject: [PATCH] drm/amdgpu: add ttm_bind in amdgpu_vm_bo_update()
> 
> Change-Id: If73d5b06e9188e40250ccdfd1a2a659ed1ef52a6
> Signed-off-by: Flora Cui 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 2bb78dc..7f17127 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1166,6 +1166,8 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
>   ttm = container_of(bo_va->bo->tbo.ttm, struct
>  ttm_dma_tt, ttm);
>   pages_addr = ttm->dma_address;
> + amdgpu_ttm_bind(&bo_va->bo->tbo, mem);
> + addr = (u64)mem->start << PAGE_SHIFT;
>   break;
>  
>   case TTM_PL_VRAM:
> -- 
> 2.7.4
> 
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

2016-09-26 Thread Flora Cui

On Sun, Sep 25, 2016 at 11:55:13AM +0200, Christian König wrote:
> From: Christian König 
> 
> Otherwise we will look at the wrong place in the IB when GART
> mappings are split into smaller updates.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 2bb78dc..da31189 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1017,6 +1017,7 @@ static int amdgpu_vm_bo_update_mapping(struct 
> amdgpu_device *adev,
>   AMDGPU_GPU_PAGE_SIZE);
>   pte[i] |= flags;
>   }
> + addr = 0;
>   }
>  
>   r = amdgpu_sync_fence(adev, &job->sync, exclusive);
> -- 
> 2.5.0
> 
>

IMHO this could fix the vmfault issue.

8<---
From cc7b5618665defd88e2adcd6f735562ecd784298 Mon Sep 17 00:00:00 2001
From: Flora Cui 
Date: Mon, 26 Sep 2016 15:14:02 +0800
Subject: [PATCH] drm/amdgpu: add ttm_bind in amdgpu_vm_bo_update()

Change-Id: If73d5b06e9188e40250ccdfd1a2a659ed1ef52a6
Signed-off-by: Flora Cui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 2bb78dc..7f17127 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1166,6 +1166,8 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev,
ttm = container_of(bo_va->bo->tbo.ttm, struct
   ttm_dma_tt, ttm);
pages_addr = ttm->dma_address;
+   amdgpu_ttm_bind(&bo_va->bo->tbo, mem);
+   addr = (u64)mem->start << PAGE_SHIFT;
break;
 
case TTM_PL_VRAM:
-- 
2.7.4


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

Re: [PATCH 0/3] drm/amdgpu: implement raster configuration

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

[PATCH] drm/amdgpu: add version bump for raster config programming

RE: [PATCH 0/3] drm/amdgpu: implement raster configuration

Re: [PATCH 0/3] drm/amdgpu: implement raster configuration

Re: [PATCH] drm/amdgpu: add the interface of waiting multiple fences (v3)

Re: [PATCH] drm/amdgpu/i2c: add const where appropriate

[PATCH] drm/amdgpu/vce: take all rings into account for idle checks

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

Re: [PATCH] drm/amdgpu: disable CRTCs before teardown

Re: [PATCH 2/2] drm/amdgpu: improve VM PTE trace points

Re: [PATCH 2/2] drm/amdgpu: bind GTT on demand

Re: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

RE: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

RE: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

Re: [amdgpu][CIK] drm-next-4.9-wip - piglit test - max-texture-size - GPU deadlock

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

RE: [PATCH] drm/amdgpu: bypass vce clock if vce is idle on Fiji.

Re: Bonair support Kernel compiling instructions

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

[PATCH 2/2] drm/amdgpu: improve VM PTE trace points

[PATCH 1/2] drm/amdgpu: fix GART_DEBUGFS define

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

Re: [PATCH] drm/amdgpu: fix addr handling in amdgpu_vm_bo_update_mapping

25 matches

Site Navigation

Mail list logo

Footer information