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

2017-11-29 Thread Michel Dänzer 
On 2017-11-27 01:20 PM, Christian König wrote:
> Am 27.11.2017 um 13:02 schrieb Michel Dänzer:
>> [SNIP]
>> I thought I did above...
>>
>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>> rely on ttm_populate_and_map_pages, which is implemented as:
>>
>> static inline int ttm_populate_and_map_pages(struct device *dev,
>> struct ttm_dma_tt *tt)
>> {
>> return -ENOMEM;
>> }
>>
>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>> Previously, the driver worked fine without either of those enabled.
> Ah! Sorry my fault. It looks like I incorrectly explained to Tom how to
> handle the config options.
> 
> Please take a look at the attached patch, it should fix the issue (going
> to send that one out separately once more).

[...]

>   * Output the state of pools to debugfs file
>   */
>  int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
>  
> -
>  #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
>  /**
>   * Initialize pool allocator.

I'd drop the removal of this line, but either way,

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-28 Thread Christian Zigotzky 

On 28 November 2017 at 10:40AM, Michel Dänzer wrote:

On 2017-11-28 06:43 AM, Christian Zigotzky wrote:

Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
enabled?

I doubt SWIOTLB provides any benefit for you.


Can you test if Christian's patch fixes the problem with SWIOTLB disabled?



Hi Michel,

Hardware 3D acceleration works with Christian's patch! I don't need to 
enable SWIOTLB anymore.


Thanks,
Christian

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

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

2017-11-28 Thread Michel Dänzer 
On 2017-11-28 06:43 AM, Christian Zigotzky wrote:
> Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB
> enabled?

I doubt SWIOTLB provides any benefit for you.


Can you test if Christian's patch fixes the problem with SWIOTLB disabled?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-27 Thread Christian Zigotzky 
Is it better to enable SWIOTLB? Are there any advantages with SWIOTLB enabled?

— Christian

Sent from my iPhone

> On 27. Nov 2017, at 15:53, Michel Dänzer  wrote:
> 
>> On 2017-11-27 01:17 PM, Tom St Denis wrote:
>>> On 27/11/17 07:02 AM, Michel Dänzer wrote:
 On 2017-11-27 12:50 PM, Christian König wrote:
> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
>> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>>> Hi All,
>>> 
>>> I bisected today and the first bad commit is:
>>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper
>>> functions
>>> to populate/map in one call (v2)) [1]
>> It can't really be that commit, since it just adds functions but
>> doesn't
>> hook them up anywhere. Presumably it's commit
>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>> populate/dma map helper functions") instead, which makes the radeon
>> driver rely on ttm_populate_and_map_pages, which is just a stub
>> returning -ENOMEM when neither CONFIG_SWIOTLB nor
>> CONFIG_INTEL_IOMMU is
>> enabled.
>> 
>> I can see two possible solutions:
>> 
>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>>  work without SWIOTLB / INTEL_IOMMU as well.
>> 
>> 2. Make the drivers work without ttm_populate_and_map_pages and
>>  ttm_unmap_and_unpopulate_pages again in that case.
>> 
>> 
>> Solution 1 would be preferable.
> Which solution do you want to go for?
 
 well, can somebody please explain to me why those patches actually
 result in problems?
>>> 
>>> I thought I did above...
>>> 
>>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>>> rely on ttm_populate_and_map_pages, which is implemented as:
>>> 
>>> static inline int ttm_populate_and_map_pages(struct device *dev,
>>> struct ttm_dma_tt *tt)
>>> {
>>> return -ENOMEM;
>>> }
>>> 
>>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>>> Previously, the driver worked fine without either of those enabled.
>>> 
>>> 
>> 
>> I think the issue is why would you have both disabled [...]
> Doesn't matter. The drivers worked with both disabled before, now they
> don't. That's a regression.
> 
> 
> -- 
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-27 Thread Michel Dänzer 
On 2017-11-27 01:17 PM, Tom St Denis wrote:
> On 27/11/17 07:02 AM, Michel Dänzer wrote:
>> On 2017-11-27 12:50 PM, Christian König wrote:
>>> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
 On 2017-11-24 05:09 PM, Michel Dänzer wrote:
> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
>> Hi All,
>>
>> I bisected today and the first bad commit is:
>> a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper
>> functions
>> to populate/map in one call (v2)) [1]
> It can't really be that commit, since it just adds functions but
> doesn't
> hook them up anywhere. Presumably it's commit
> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
> populate/dma map helper functions") instead, which makes the radeon
> driver rely on ttm_populate_and_map_pages, which is just a stub
> returning -ENOMEM when neither CONFIG_SWIOTLB nor
> CONFIG_INTEL_IOMMU is
> enabled.
>
> I can see two possible solutions:
>
> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>  work without SWIOTLB / INTEL_IOMMU as well.
>
> 2. Make the drivers work without ttm_populate_and_map_pages and
>  ttm_unmap_and_unpopulate_pages again in that case.
>
>
> Solution 1 would be preferable.
 Which solution do you want to go for?
>>>
>>> well, can somebody please explain to me why those patches actually
>>> result in problems?
>>
>> I thought I did above...
>>
>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>> rely on ttm_populate_and_map_pages, which is implemented as:
>>
>> static inline int ttm_populate_and_map_pages(struct device *dev,
>> struct ttm_dma_tt *tt)
>> {
>> return -ENOMEM;
>> }
>>
>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>> Previously, the driver worked fine without either of those enabled.
>>
>>
> 
> I think the issue is why would you have both disabled [...]
Doesn't matter. The drivers worked with both disabled before, now they
don't. That's a regression.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-27 Thread Christian König 

Am 27.11.2017 um 13:02 schrieb Michel Dänzer:

[SNIP]
I thought I did above...

Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
rely on ttm_populate_and_map_pages, which is implemented as:

static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
{
return -ENOMEM;
}

when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
Previously, the driver worked fine without either of those enabled.
Ah! Sorry my fault. It looks like I incorrectly explained to Tom how to 
handle the config options.


Please take a look at the attached patch, it should fix the issue (going 
to send that one out separately once more).


Regards,
Christian.



>From a53c4574a06ee5a46d8e5b8fb10623c76513fe5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= 
Date: Mon, 27 Nov 2017 13:12:35 +0100
Subject: [PATCH] drm/ttm: fix populate_and_map() functions once more
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts "drm/ttm: Fix configuration error around populate_and_map()
functions".

This fix has gone into the wrong direction. Those helpers should be
available even when neither CONFIG_INTEL_IOMMU nor CONFIG_SWIOTLB are
set.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  2 --
 include/drm/ttm/ttm_page_alloc.h | 32 ++--
 2 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 1543532b8740..c82d94cbbabc 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1096,7 +1096,6 @@ void ttm_pool_unpopulate(struct ttm_tt *ttm)
 }
 EXPORT_SYMBOL(ttm_pool_unpopulate);
 
-#if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
 {
 	unsigned i, j;
@@ -1167,7 +1166,6 @@ void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
 	ttm_pool_unpopulate(>ttm);
 }
 EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages);
-#endif
 
 int ttm_page_alloc_debugfs(struct seq_file *m, void *data)
 {
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 38a2b4770c35..593811362a91 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -59,11 +59,20 @@ int ttm_pool_populate(struct ttm_tt *ttm);
 void ttm_pool_unpopulate(struct ttm_tt *ttm);
 
 /**
+ * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
+ */
+int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
+ * Unpopulates and DMA unmaps pages as part of a
+ * ttm_dma_unpopulate() request */
+void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
+
+/**
  * Output the state of pools to debugfs file
  */
 int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
 
-
 #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
 /**
  * Initialize pool allocator.
@@ -83,17 +92,6 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data);
 int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
 void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
 
-
-/**
- * Populates and DMA maps pages to fullfil a ttm_dma_populate() request
- */
-int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt);
-
-/**
- * Unpopulates and DMA unmaps pages as part of a
- * ttm_dma_unpopulate() request */
-void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt);
-
 #else
 static inline int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
 	  unsigned max_pages)
@@ -116,16 +114,6 @@ static inline void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
   struct device *dev)
 {
 }
-
-static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
-	return -ENOMEM;
-}
-
-static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt)
-{
-}
-
 #endif
 
 #endif
-- 
2.11.0

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

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

2017-11-27 Thread Tom St Denis 

On 27/11/17 07:02 AM, Michel Dänzer wrote:

On 2017-11-27 12:50 PM, Christian König wrote:

Am 27.11.2017 um 12:02 schrieb Michel Dänzer:

On 2017-11-24 05:09 PM, Michel Dänzer wrote:

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

Hi All,

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

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

I can see two possible solutions:

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

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


Solution 1 would be preferable.

Which solution do you want to go for?


well, can somebody please explain to me why those patches actually
result in problems?


I thought I did above...

Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
rely on ttm_populate_and_map_pages, which is implemented as:

static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
{
return -ENOMEM;
}

when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
Previously, the driver worked fine without either of those enabled.




I think the issue is why would you have both disabled and we did run 
into a kbuild error when they weren't guarded (I don't remember exactly 
what though I'd have to go grep for it).


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

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

2017-11-27 Thread Michel Dänzer 
On 2017-11-27 12:50 PM, Christian König wrote:
> Am 27.11.2017 um 12:02 schrieb Michel Dänzer:
>> On 2017-11-24 05:09 PM, Michel Dänzer wrote:
>>> On 2017-11-24 03:29 PM, Christian Zigotzky wrote:
 Hi All,

 I bisected today and the first bad commit is:
 a4dec819c8bba6365eb893a4ca88db4dd1210110 (drm/ttm: Add helper functions
 to populate/map in one call (v2)) [1]
>>> It can't really be that commit, since it just adds functions but doesn't
>>> hook them up anywhere. Presumably it's commit
>>> f7871fd19389c5f64f625a4389675d0740f0dfe4 ("drm/radeon: use new TTM
>>> populate/dma map helper functions") instead, which makes the radeon
>>> driver rely on ttm_populate_and_map_pages, which is just a stub
>>> returning -ENOMEM when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is
>>> enabled.
>>>
>>> I can see two possible solutions:
>>>
>>> 1. Make ttm_populate_and_map_pages and ttm_unmap_and_unpopulate_pages
>>>     work without SWIOTLB / INTEL_IOMMU as well.
>>>
>>> 2. Make the drivers work without ttm_populate_and_map_pages and
>>>     ttm_unmap_and_unpopulate_pages again in that case.
>>>
>>>
>>> Solution 1 would be preferable.
>> Which solution do you want to go for?
> 
> well, can somebody please explain to me why those patches actually
> result in problems?

I thought I did above...

Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
rely on ttm_populate_and_map_pages, which is implemented as:

static inline int ttm_populate_and_map_pages(struct device *dev, struct 
ttm_dma_tt *tt)
{
return -ENOMEM;
}

when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
Previously, the driver worked fine without either of those enabled.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-27 Thread Christian König 

Hi Michel,

Am 27.11.2017 um 12:02 schrieb Michel Dänzer:

Hi Tom,

On 2017-11-24 05:09 PM, Michel Dänzer wrote:

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

Hi All,

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

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

I can see two possible solutions:

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

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


Solution 1 would be preferable.

Which solution do you want to go for?


well, can somebody please explain to me why those patches actually 
result in problems?


They should have only moved code around, not cause anything like this.

Apart from that I also prefer solution 1.

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

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

2017-11-27 Thread Michel Dänzer 

Hi Tom,

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

Which solution do you want to go for?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-24 Thread Christian Zigotzky 

On 24.11.2017 20:14, Ilia Mirkin wrote:


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

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

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


Hi All,

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


Cheers,
Christian

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

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

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

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

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

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

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

2017-11-24 Thread Christian Zigotzky 

On 24.11.2017 20:08, Christian Zigotzky wrote:

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

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

Hi All,

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

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

I can see two possible solutions:

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

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


Solution 1 would be preferable.



Hello Michel,

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


Thanks,
Christian


Just for info:

CONFIG_SWIOTLB is not set and CONFIG_PPC_PASEMI_IOMMU is enabled.

-- Christian

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

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

2017-11-24 Thread Christian Zigotzky 

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

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

Hi All,

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

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

I can see two possible solutions:

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

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


Solution 1 would be preferable.



Hello Michel,

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


Thanks,
Christian

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

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

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

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

I can see two possible solutions:

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

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


Solution 1 would be preferable.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-24 Thread Christian Zigotzky 

Hi All,

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


Please find attached the git bisect log.

Thanks,
Christian

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



On 22.11.2017 14:45, Ilia Mirkin wrote:


I thought I covered that...

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

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



git bisect start

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

git bisect bad e60e1ee60630cafef5e430c2ae364877e061d980

Output:

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

git bisect good

Output:

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

git bisect bad

Output:

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

git bisect bad

Output:

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

git bisect good

Output:

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

git bisect bad

Output:

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

git bisect bad

Output:

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

git bisect bad

Output:

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

git bisect good

Output:

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

git bisect bad

Output:

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

git bisect bad

Output:

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

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

git bisect bad

Output:

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

git bisect bad

Output:

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

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

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

v2: squash in fix for sw iommu from Tom

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

:04 04

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

2017-11-22 Thread Christian Zigotzky 

On 22 November 2017 at 2:45PM, Ilia Mirkin wrote:


I thought I covered that...

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

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


OK, I am bisecting 

Thanks,
Christian

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

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

2017-11-22 Thread Ilia Mirkin 
On Wed, Nov 22, 2017 at 8:40 AM, Christian Zigotzky
 wrote:
> On 22 November 2017 at 2:27PM, Ilia Mirkin wrote:
>>
>> On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
>>  wrote:
>>>
>>> Hi Alex,
>>>
>>> I reverted the following files in the first bad commit (first DRM
>>> updates)
>>
>> Is the merge commit really the first bad commit? i.e. both parents of
>> the merge are good, but the merge commit itself is bad? Or did you do
>> this manually and therefore didn't go into the merge parents? If so,
>> I'd recommend doing a proper bisect (search for "git bisect", there
>> are tons of guides). That will identify the commit that's actually
>> responsible.
>
> Hi ilia,
>
> I did it manually. If I revert the merge commit then the hardware 3D
> acceleration works. Is it possible to bisect in the merge commit directly?

I thought I covered that...

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

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

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

2017-11-22 Thread Christian Zigotzky 

On 22 November 2017 at 2:27PM, Ilia Mirkin wrote:

On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
 wrote:

Hi Alex,

I reverted the following files in the first bad commit (first DRM updates)

Is the merge commit really the first bad commit? i.e. both parents of
the merge are good, but the merge commit itself is bad? Or did you do
this manually and therefore didn't go into the merge parents? If so,
I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible.

Cheers,

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


Hi ilia,

I did it manually. If I revert the merge commit then the hardware 3D 
acceleration works. Is it possible to bisect in the merge commit directly?


Thanks,
Christian

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

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

2017-11-22 Thread Ilia Mirkin 
On Wed, Nov 22, 2017 at 8:20 AM, Christian Zigotzky
 wrote:
> Hi Alex,
>
> I reverted the following files in the first bad commit (first DRM updates)

Is the merge commit really the first bad commit? i.e. both parents of
the merge are good, but the merge commit itself is bad? Or did you do
this manually and therefore didn't go into the merge parents? If so,
I'd recommend doing a proper bisect (search for "git bisect", there
are tons of guides). That will identify the commit that's actually
responsible.

Cheers,

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

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

2017-11-22 Thread Christian Zigotzky 

Hi Alex,

I reverted the following files in the first bad commit (first DRM 
updates) [1].


-rw-r--r--    drivers/gpu/drm/radeon/Makefile    5
-rw-r--r--    drivers/gpu/drm/radeon/atombios_dp.c    46
-rw-r--r--    drivers/gpu/drm/radeon/ci_dpm.c    22
-rw-r--r--    drivers/gpu/drm/radeon/ci_dpm.h    1
-rw-r--r--    drivers/gpu/drm/radeon/ci_smc.c    21
-rw-r--r--    drivers/gpu/drm/radeon/cik.c    14
-rw-r--r--    drivers/gpu/drm/radeon/cikd.h    2
-rw-r--r--    drivers/gpu/drm/radeon/r100.c    2
-rw-r--r--    drivers/gpu/drm/radeon/r600_cs.c    2
-rw-r--r--    drivers/gpu/drm/radeon/r600_hdmi.c    2
-rw-r--r--    drivers/gpu/drm/radeon/radeon.h    3
-rw-r--r--    drivers/gpu/drm/radeon/radeon_connectors.c    16
-rw-r--r--    drivers/gpu/drm/radeon/radeon_drv.c    10
-rw-r--r--    drivers/gpu/drm/radeon/radeon_fb.c    4
-rw-r--r--    drivers/gpu/drm/radeon/radeon_kfd.c    870
-rw-r--r--    drivers/gpu/drm/radeon/radeon_kms.c    7
-rw-r--r--    drivers/gpu/drm/radeon/radeon_mode.h    4
-rw-r--r--    drivers/gpu/drm/radeon/radeon_trace.h    2
-rw-r--r--    drivers/gpu/drm/radeon/radeon_ttm.c

After that I compiled the latest git kernel again. Unfortunately I don't 
have hardware 3D acceleration. That means the bug isn't in these files 
above but it is somewhere in the first DRM updates [1].


I need really your help because I don't have any experiences with this 
source code. I will try to revert more files.


Thanks,
Christian


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



On 21 November 2017 at 05:38AM, Alex Deucher wrote:


If you look at the code, radeon_bo_create() is failing with -ENOMEM in
radeon_wb_init().  If you look at radeon_bo_create(), it can fail for
the following reasons:
1. kzalloc fails
2. drm_gem_object_init fails
3. ttm_bo_init fails

I'd start by looking into what's changed in those areas.

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



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

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

2017-11-21 Thread Christian Zigotzky 

Alex,

Thanks for your fast reply. I have looked in the first bad commit 
e60e1ee60630cafef5e430c2ae364877e061d980 (Merge tag 'drm-for-v4.15') [1].
I have found a lot of kzalloc changes. I am sorry, I don't have any 
experiences with this code. I only know that my Radeon HD6870 doesn't 
have hardware 3D acceleration anymore.


Maybe I could revert the drm_gem_object_init and ttm_bo_init changes but 
the kzalloc changes are too much. I think I need help to solve this issue.


Thanks,
Christian


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



On 21 November 2017 at 05:38AM, Alex Deucher wrote:


If you look at the code, radeon_bo_create() is failing with -ENOMEM in
radeon_wb_init().  If you look at radeon_bo_create(), it can fail for
the following reasons:
1. kzalloc fails
2. drm_gem_object_init fails
3. ttm_bo_init fails

I'd start by looking into what's changed in those areas.

Alex


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



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

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

2017-11-20 Thread Alex Deucher 
On Mon, Nov 20, 2017 at 1:08 PM, Christian Zigotzky
 wrote:
> Hi All,
>
> I tested the latest Git kernel version [1] on my Varisys Nemo board with a
> 64-bit dual-core PWRficient PA6T-1682M PowerPC CPU (A-EON AmigaOne X1000)
> [2] today. Unfortunately hardware 3D acceleration doesn't work anymore. It
> works without any problems with the kernel 4.14.0 [3].
>
> Error messages:
>
> dmesg | grep -i radeon
>
> [0.720715] [drm] radeon kernel modesetting enabled.
> [0.720832] radeon :01:00.0: runtime IRQ mapping not provided by arch
> [0.894456] radeon :01:00.0: VRAM: 1024M 0x -
> 0x3FFF (1024M used)
> [0.894468] radeon :01:00.0: GTT: 1024M 0x4000 -
> 0x7FFF
> [0.894617] [drm] radeon: 1024M of VRAM memory ready
> [0.894624] [drm] radeon: 1024M of GTT memory ready.
> [0.899823] [drm] radeon: dpm initialized
> [0.933524] radeon :01:00.0: (-12) create WB bo failed
> [0.933532] radeon :01:00.0: disabling GPU acceleration
> [0.938686] [drm] Radeon Display Connectors
> [1.447790] radeon :01:00.0: fb0: radeondrmfb frame buffer device
> [1.448338] [drm] Initialized radeon 2.50.0 20080528 for :01:00.0 on
> minor 0
> [   39.299034] radeon_dp_aux_transfer_native: 158 callbacks suppressed
> [   70.924054] radeon_dp_aux_transfer_native: 158 callbacks suppressed
> [  683.732444] radeon_dp_aux_transfer_native: 410 callbacks suppressed
> [ 1049.062659] radeon_dp_aux_transfer_native: 74 callbacks suppressed
>
> Problem:
>
> [ 0.933524] radeon :01:00.0: (-12) create WB bo failed
> [ 0.933532] radeon :01:00.0: disabling GPU acceleration

If you look at the code, radeon_bo_create() is failing with -ENOMEM in
radeon_wb_init().  If you look at radeon_bo_create(), it can fail for
the following reasons:
1. kzalloc fails
2. drm_gem_object_init fails
3. ttm_bo_init fails

I'd start by looking into what's changed in those areas.

Alex

>
> I was able to revert the first DRM updates [4]. This solved the problem with
> the hardware 3D acceleration on my Varisys Nemo board. That means the bug is
> somewhere in the first DRM updates [4].
>
> Please find attached the DRM revert log.
>
> Cheers,
> Christian
>
>
> [1] http://www.xenosoft.de/vmlinux-4.15-alpha3-AmigaOne_X1000_X5000.tar.gz
> [2] https://en.wikipedia.org/wiki/AmigaOne_X1000
> [3] http://www.xenosoft.de/vmlinux-4.14-AmigaOne_X1000_X5000.tar.gz
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2017-11-20 Thread Christian Zigotzky 

Hi All,

I tested the latest Git kernel version [1] on my Varisys Nemo board with 
a 64-bit dual-core PWRficient PA6T-1682M PowerPC CPU (A-EON AmigaOne 
X1000) [2] today. Unfortunately hardware 3D acceleration doesn't work 
anymore. It works without any problems with the kernel 4.14.0 [3].


Error messages:

dmesg | grep -i radeon

[    0.720715] [drm] radeon kernel modesetting enabled.
[    0.720832] radeon :01:00.0: runtime IRQ mapping not provided by arch
[    0.894456] radeon :01:00.0: VRAM: 1024M 0x - 
0x3FFF (1024M used)
[    0.894468] radeon :01:00.0: GTT: 1024M 0x4000 - 
0x7FFF

[    0.894617] [drm] radeon: 1024M of VRAM memory ready
[    0.894624] [drm] radeon: 1024M of GTT memory ready.
[    0.899823] [drm] radeon: dpm initialized
[    0.933524] radeon :01:00.0: (-12) create WB bo failed
[    0.933532] radeon :01:00.0: disabling GPU acceleration
[    0.938686] [drm] Radeon Display Connectors
[    1.447790] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[    1.448338] [drm] Initialized radeon 2.50.0 20080528 for :01:00.0 
on minor 0

[   39.299034] radeon_dp_aux_transfer_native: 158 callbacks suppressed
[   70.924054] radeon_dp_aux_transfer_native: 158 callbacks suppressed
[  683.732444] radeon_dp_aux_transfer_native: 410 callbacks suppressed
[ 1049.062659] radeon_dp_aux_transfer_native: 74 callbacks suppressed

Problem:

[ 0.933524] radeon :01:00.0: (-12) create WB bo failed
[ 0.933532] radeon :01:00.0: disabling GPU acceleration

I was able to revert the first DRM updates [4]. This solved the problem 
with the hardware 3D acceleration on my Varisys Nemo board. That means 
the bug is somewhere in the first DRM updates [4].


Please find attached the DRM revert log.

Cheers,
Christian


[1] http://www.xenosoft.de/vmlinux-4.15-alpha3-AmigaOne_X1000_X5000.tar.gz
[2] https://en.wikipedia.org/wiki/AmigaOne_X1000
[3] http://www.xenosoft.de/vmlinux-4.14-AmigaOne_X1000_X5000.tar.gz
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e60e1ee60630cafef5e430c2ae364877e061d980




git revert e60e1ee60630cafef5e430c2ae364877e061d980 -m 1

Output:

[master c0fd66d] Revert "Merge tag 'drm-for-v4.15' of 
git://people.freedesktop.org/~airlied/linux"
 Committer: christian 
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:

git config --global --edit

After doing this, you may fix the identity used for this commit with:

git commit --amend --reset-author

1039 files changed, 49563 insertions(+), 69996 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
delete mode 100644 Documentation/devicetree/bindings/display/faraday,tve200.txt
delete mode 100644 
Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
delete mode 100644 
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
delete mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
delete mode 100644 
Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.txt
delete mode 100644 
Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
delete mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
delete mode 100644 Documentation/gpu/tve200.rst
delete mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
rewrite drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.c (81%)
rewrite drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h (62%)
delete mode 100644 drivers/gpu/drm/amd/include/linux/chash.h
delete mode 100644 drivers/gpu/drm/amd/lib/Kconfig
delete mode 100644 drivers/gpu/drm/amd/lib/Makefile
delete mode 100644 drivers/gpu/drm/amd/lib/chash.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/Makefile
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventactionchains.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventactionchains.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventinit.c
rename drivers/gpu/drm/amd/{amdgpu/amdgpu_sched.h => 
powerplay/eventmgr/eventinit.h} (73%)
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventmanagement.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventmanagement.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventsubchains.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventsubchains.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.c
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.h
create mode 100644 drivers/gpu/drm/amd/powerplay/eventmgr/psm.c
rename