Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Christian König]

Am 22.02.2018 um 03:05 schrieb Alex Deucher:

On Wed, Feb 21, 2018 at 6:41 PM, Ben Crocker  wrote:

In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.

Can we make this ppc only?  40 bit DMA works fine on x86.


Yeah and at least when the dma_coherent allocator path is used it should 
work fine on PPC as well.


So that is not really a driver bug, but a platform bug and we should 
think about reverting or at least disabling those two patches instead.


Christian.



Alex


Signed-off-by: Ben Crocker 
---
  drivers/gpu/drm/radeon/radeon_device.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ffc10cadcf34..02538903830d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device *rdev,
 if (rdev->flags & RADEON_IS_AGP)
 rdev->need_dma32 = true;
 if ((rdev->flags & RADEON_IS_PCI) &&
-   (rdev->family <= CHIP_RS740))
+   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
+   rdev->need_dma32 = true;
+   if ((rdev->flags & RADEON_IS_PCIE) &&
+   (rdev->family == CHIP_CEDAR))
 rdev->need_dma32 = true;

 dma_bits = rdev->need_dma32 ? 32 : 40;
--
2.13.6

___
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


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

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Alex Deucher]

On Wed, Feb 21, 2018 at 6:41 PM, Ben Crocker  wrote:
> In radeon_device_init, set the need_dma32 flag for Cedar chips
> (e.g. FirePro 2270).  This fixes, or at least works around, a bug
> on PowerPC exposed by last year's commits
>
> 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
>
> and
>
> 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
>
> which enabled the 64-bit DMA iommu bypass.
>
> This caused the device to freeze, in some cases unrecoverably, and is
> the subject of several bug reports internal to Red Hat.

Can we make this ppc only?  40 bit DMA works fine on x86.

Alex

>
> Signed-off-by: Ben Crocker 
> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index ffc10cadcf34..02538903830d 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device *rdev,
> if (rdev->flags & RADEON_IS_AGP)
> rdev->need_dma32 = true;
> if ((rdev->flags & RADEON_IS_PCI) &&
> -   (rdev->family <= CHIP_RS740))
> +   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
> +   rdev->need_dma32 = true;
> +   if ((rdev->flags & RADEON_IS_PCIE) &&
> +   (rdev->family == CHIP_CEDAR))
> rdev->need_dma32 = true;
>
> dma_bits = rdev->need_dma32 ? 32 : 40;
> --
> 2.13.6
>
> ___
> 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

[PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Ben Crocker]

In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.

Signed-off-by: Ben Crocker 
---
 drivers/gpu/drm/radeon/radeon_device.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ffc10cadcf34..02538903830d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device *rdev,
if (rdev->flags & RADEON_IS_AGP)
rdev->need_dma32 = true;
if ((rdev->flags & RADEON_IS_PCI) &&
-   (rdev->family <= CHIP_RS740))
+   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
+   rdev->need_dma32 = true;
+   if ((rdev->flags & RADEON_IS_PCIE) &&
+   (rdev->family == CHIP_CEDAR))
rdev->need_dma32 = true;
 
dma_bits = rdev->need_dma32 ? 32 : 40;
-- 
2.13.6

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

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

[Emil Velikov]

On 20 February 2018 at 13:12, Peter Zijlstra  wrote:
> On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote:
>> amdgpu needs to verify if userspace sends us valid addresses and the simplest
>> way of doing this is to check if the buffer object is locked with the ticket
>> of the current submission.
>>
>> Clean up the access to the ww_mutex internals by providing a function
>> for this and extend the check to the thread owning the underlying mutex.
>
>> Signed-off-by: Christian König 
>
> Much thanks for Cc'ing the relevant maintainers :/
>
Doubt it's intentional. The get-maintainer script seems confused and
lists no maintainers?

$ ./scripts/get_maintainer.pl include/linux/ww_mutex.h
linux-ker...@vger.kernel.org (open list)

While the normal mutex header works fine.

$ ./scripts/get_maintainer.pl include/linux/mutex.h
Peter Zijlstra  (maintainer:LOCKING PRIMITIVES)
Ingo Molnar  (maintainer:LOCKING PRIMITIVES)
linux-ker...@vger.kernel.org (open list:LOCKING PRIMITIVES)

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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Felix Kuehling]

On 2018-02-21 07:43 AM, Christian König wrote:
>> The failed VCE resume (-22) seems to be caused by
>>
>>         if (rdev->vce.vcpu_bo == NULL)
>>                 return -EINVAL;
>>
>> in radeon_vce.c line 226.
>
> Yeah, you don't seem to have the VCE firmware installed. But as long
> as you don't want to do any advanced video encoding with the hardware
> we can simply ignore that for now.
>
>> Any idea where to look from there?
>
> Unfortunately not the slightest.
>
> What's a bit suspicious is that the CPU addresses for the fence
> locations look odd:
>> [   11.350779] radeon 0001:01:00.0: fence driver on ring 0 use gpu
>> addr 0x8c00 and cpu addr 0x7408d6c9
>> [   11.360274] radeon 0001:01:00.0: fence driver on ring 1 use gpu
>> addr 0x8c04 and cpu addr 0x13c11aeb
>> [   11.369770] radeon 0001:01:00.0: fence driver on ring 2 use gpu
>> addr 0x8c08 and cpu addr 0xd4ddd131
>> [   11.379267] radeon 0001:01:00.0: fence driver on ring 3 use gpu
>> addr 0x8c0c and cpu addr 0x263a4d29
>> [   11.388763] radeon 0001:01:00.0: fence driver on ring 4 use gpu
>> addr 0x8c10 and cpu addr 0x6ceb1503
>> [   11.399277] radeon 0001:01:00.0: fence driver on ring 5 use gpu
>> addr 0x00075a18 and cpu addr 0x8935a463
> But could as well be that we don't correctly print them.

Starting in 4.15 printk("%p") doesn't print real pointers but a hash of
the address. I think that's part of the spectre/meltdown changes to make
it harder to guess the kernel mode address space layout. See
Documentation/core-api/printk-formats.rst for more details. And this commit:
> ad67b74 printk: hash addresses printed with %p

Regards,
  Felix

>
> Apart from that I don't have any good idea any more why that shouldn't
> work.
>
> Sorry,
> Christian.
>
> Am 21.02.2018 um 13:13 schrieb Bas Vermeulen:
>> I got a 4.15.0 up and running on the board; it needs pci=noaer, but
>> boots up and sees the E8860 apart from that.
>>
>> The relevant dmesg output:
>>
>> [   10.888426] [drm] radeon kernel modesetting enabled.
>> [   10.892170] radeon 0001:01:00.0: runtime IRQ mapping not provided
>> by arch
>> [   10.892407] [drm] initializing kernel modesetting (VERDE
>> 0x1002:0x6822 0x1002:0x031E 0x00).
>> [   11.138410] ATOM BIOS: E268
>> [   11.139916] [drm] GPU not posted. posting now...
>> [   11.168970] radeon 0001:01:00.0: VRAM: 2048M 0x -
>> 0x7FFF (2048M used)
>> [   11.176546] radeon 0001:01:00.0: GTT: 2048M 0x8000 -
>> 0x
>> [   11.182909] [drm] Detected VRAM RAM=2048M, BAR=256M
>> [   11.186488] [drm] RAM width 128bits DDR
>> [   11.189121] [TTM] Zone  kernel: Available graphics memory: 1978102
>> kiB
>> [   11.194350] [TTM] Initializing pool allocator
>> [   11.197407] [TTM] Initializing DMA pool allocator
>> [   11.200858] [drm] radeon: 2048M of VRAM memory ready
>> [   11.204527] [drm] radeon: 2048M of GTT memory ready.
>> [   11.208211] [drm] Loading verde Microcode
>> [   11.225907] [drm] Internal thermal controller with fan control
>> [   11.230575] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
>> [   11.247750] [drm] radeon: dpm initialized
>> [   11.268255] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
>> [   11.273152] [drm] GART: num cpu pages 524288, num gpu pages 524288
>> [   11.281061] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
>> [   11.286060] [drm] PCIE gen 3 link speeds already enabled
>> [   11.342009] [drm] PCIE GART of 2048M enabled (table at
>> 0x001D6000).
>> [   11.347883] radeon 0001:01:00.0: WB enabled
>> [   11.350779] radeon 0001:01:00.0: fence driver on ring 0 use gpu
>> addr 0x8c00 and cpu addr 0x7408d6c9
>> [   11.360274] radeon 0001:01:00.0: fence driver on ring 1 use gpu
>> addr 0x8c04 and cpu addr 0x13c11aeb
>> [   11.369770] radeon 0001:01:00.0: fence driver on ring 2 use gpu
>> addr 0x8c08 and cpu addr 0xd4ddd131
>> [   11.379267] radeon 0001:01:00.0: fence driver on ring 3 use gpu
>> addr 0x8c0c and cpu addr 0x263a4d29
>> [   11.388763] radeon 0001:01:00.0: fence driver on ring 4 use gpu
>> addr 0x8c10 and cpu addr 0x6ceb1503
>> [   11.399277] radeon 0001:01:00.0: fence driver on ring 5 use gpu
>> addr 0x00075a18 and cpu addr 0x8935a463
>> [   11.419084] radeon 0001:01:00.0: failed VCE resume (-22).
>> [   11.423181] [drm] Supports vblank timestamp caching Rev 2
>> (21.10.2013).
>> [   11.428502] [drm] Driver supports precise vblank timestamp query.
>> [   11.433301] radeon 0001:01:00.0: radeon: MSI limited to 32-bit
>> [   11.437896] radeon 0001:01:00.0: radeon: using MSI.
>> [   11.441499] [drm] radeon: irq initialized.
>> [   12.127423] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0
>> test failed (scratch(0x850C)=0xCAFEDEAD)
>> [   12.135788] radeon 0001:01:00.0: disabling GPU 

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Alex Deucher]

On Wed, Feb 21, 2018 at 7:43 AM, Christian König
 wrote:
>> The failed VCE resume (-22) seems to be caused by
>>
>> if (rdev->vce.vcpu_bo == NULL)
>> return -EINVAL;
>>
>> in radeon_vce.c line 226.
>
>
> Yeah, you don't seem to have the VCE firmware installed. But as long as you
> don't want to do any advanced video encoding with the hardware we can simply
> ignore that for now.
>
>> Any idea where to look from there?
>
>
> Unfortunately not the slightest.
>
> What's a bit suspicious is that the CPU addresses for the fence locations
> look odd:
>>
>> [   11.350779] radeon 0001:01:00.0: fence driver on ring 0 use gpu addr
>> 0x8c00 and cpu addr 0x7408d6c9
>> [   11.360274] radeon 0001:01:00.0: fence driver on ring 1 use gpu addr
>> 0x8c04 and cpu addr 0x13c11aeb
>> [   11.369770] radeon 0001:01:00.0: fence driver on ring 2 use gpu addr
>> 0x8c08 and cpu addr 0xd4ddd131
>> [   11.379267] radeon 0001:01:00.0: fence driver on ring 3 use gpu addr
>> 0x8c0c and cpu addr 0x263a4d29
>> [   11.388763] radeon 0001:01:00.0: fence driver on ring 4 use gpu addr
>> 0x8c10 and cpu addr 0x6ceb1503
>> [   11.399277] radeon 0001:01:00.0: fence driver on ring 5 use gpu addr
>> 0x00075a18 and cpu addr 0x8935a463
>
> But could as well be that we don't correctly print them.
>
> Apart from that I don't have any good idea any more why that shouldn't work.

Does your platform properly handle DMA masks?  Most radeon hw only
supports a 40 bit DMA mask.  If there are relevant bits in the upper
bits of the address, they will be lost when the hw tries to use the
address.  On at least some powerpc hw, I believe there is some memory
routing related info in the high bits.

Alex


>
> Sorry,
> Christian.
>
>
> Am 21.02.2018 um 13:13 schrieb Bas Vermeulen:
>>
>> I got a 4.15.0 up and running on the board; it needs pci=noaer, but boots
>> up and sees the E8860 apart from that.
>>
>> The relevant dmesg output:
>>
>> [   10.888426] [drm] radeon kernel modesetting enabled.
>> [   10.892170] radeon 0001:01:00.0: runtime IRQ mapping not provided by
>> arch
>> [   10.892407] [drm] initializing kernel modesetting (VERDE 0x1002:0x6822
>> 0x1002:0x031E 0x00).
>> [   11.138410] ATOM BIOS: E268
>> [   11.139916] [drm] GPU not posted. posting now...
>> [   11.168970] radeon 0001:01:00.0: VRAM: 2048M 0x -
>> 0x7FFF (2048M used)
>> [   11.176546] radeon 0001:01:00.0: GTT: 2048M 0x8000 -
>> 0x
>> [   11.182909] [drm] Detected VRAM RAM=2048M, BAR=256M
>> [   11.186488] [drm] RAM width 128bits DDR
>> [   11.189121] [TTM] Zone  kernel: Available graphics memory: 1978102 kiB
>> [   11.194350] [TTM] Initializing pool allocator
>> [   11.197407] [TTM] Initializing DMA pool allocator
>> [   11.200858] [drm] radeon: 2048M of VRAM memory ready
>> [   11.204527] [drm] radeon: 2048M of GTT memory ready.
>> [   11.208211] [drm] Loading verde Microcode
>> [   11.225907] [drm] Internal thermal controller with fan control
>> [   11.230575] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
>> [   11.247750] [drm] radeon: dpm initialized
>> [   11.268255] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
>> [   11.273152] [drm] GART: num cpu pages 524288, num gpu pages 524288
>> [   11.281061] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
>> [   11.286060] [drm] PCIE gen 3 link speeds already enabled
>> [   11.342009] [drm] PCIE GART of 2048M enabled (table at
>> 0x001D6000).
>> [   11.347883] radeon 0001:01:00.0: WB enabled
>> [   11.350779] radeon 0001:01:00.0: fence driver on ring 0 use gpu addr
>> 0x8c00 and cpu addr 0x7408d6c9
>> [   11.360274] radeon 0001:01:00.0: fence driver on ring 1 use gpu addr
>> 0x8c04 and cpu addr 0x13c11aeb
>> [   11.369770] radeon 0001:01:00.0: fence driver on ring 2 use gpu addr
>> 0x8c08 and cpu addr 0xd4ddd131
>> [   11.379267] radeon 0001:01:00.0: fence driver on ring 3 use gpu addr
>> 0x8c0c and cpu addr 0x263a4d29
>> [   11.388763] radeon 0001:01:00.0: fence driver on ring 4 use gpu addr
>> 0x8c10 and cpu addr 0x6ceb1503
>> [   11.399277] radeon 0001:01:00.0: fence driver on ring 5 use gpu addr
>> 0x00075a18 and cpu addr 0x8935a463
>> [   11.419084] radeon 0001:01:00.0: failed VCE resume (-22).
>> [   11.423181] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [   11.428502] [drm] Driver supports precise vblank timestamp query.
>> [   11.433301] radeon 0001:01:00.0: radeon: MSI limited to 32-bit
>> [   11.437896] radeon 0001:01:00.0: radeon: using MSI.
>> [   11.441499] [drm] radeon: irq initialized.
>> [   12.127423] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test
>> failed (scratch(0x850C)=0xCAFEDEAD)
>> [   12.135788] radeon 0001:01:00.0: 

Re: [PATCH] radeon: hide pointless #warning when compile testing

[Michel Dänzer]

On 2018-02-16 04:26 PM, Arnd Bergmann wrote:
> In randconfig testing, we sometimes get this warning:
> 
> drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
> drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable 
> CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to 
> write-combining [-Werror=cpp]
>  #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance 
> \
> 
> This is rather annoying since almost all other code produces no build-time
> output unless we have found a real bug. We already fixed this in the
> amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for
> compile testing") by adding a CONFIG_COMPILE_TEST check last year and
> agreed to do the same here, but both Michel and I then forgot about it
> until I came across the issue again now.
> 
> For stable kernels, as this is one of very few remaining randconfig
> warnings in 4.14.
> 
> Cc: sta...@vger.kernel.org
> Link: https://patchwork.kernel.org/patch/9550009/
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/radeon/radeon_object.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 093594976126..54c2b4fc5ead 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -238,9 +238,10 @@ int radeon_bo_create(struct radeon_device *rdev,
>* may be slow
>* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
>*/
> -
> +#ifndef CONFIG_COMPILE_TEST
>  #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance 
> \
>thanks to write-combining
> +#endif
>  
>   if (bo->flags & RADEON_GEM_GTT_WC)
>   DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for 
> "
> 

Merged on the internal amd-staging-drm-next branch, thanks!


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

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

[Maarten Lankhorst]

Op 21-02-18 om 00:56 schreef Daniel Vetter:
> On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:
>> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:
>>> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
 On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
>> OK, but neither case would in fact need the !ctx case right? That's just
>> there for completeness sake?
> Unfortunately not. TTM uses trylock to lock BOs which are about to be
> evicted to make room for all the BOs locked with a ctx.
>
> I need to be able to distinct between the BOs which are trylocked and 
> those
> which are locked with a ctx.
>
> Writing this I actually noticed the current version is buggy, cause even
> when we check the mutex owner we still need to make sure that the ctx in 
> the
> lock is NULL.
 Hurm... I can't remember why trylocks behave like that, and it seems
 rather unfortunate / inconsistent.
>>> Actually for me that is rather fortunate, cause I need to distinct between
>>> the locks acquired through trylock and lock.
>> I suppose that would always be possible using:
>> ww_mutex_trylock(.ctx=NULL), and it could be that there simply weren't
>> any immediate uses for a !NULL trylock and it was thus not implemented.
>>
>> But that is all very long ago..
> I think we simple never had a use-case for interleaving ww_mutex_lock(ctx)
> and ww_mutex_trylock(ctx). Nesting multiple trylocks in ctx-locks happens
> plenty, but not further:
>
> The common use-case for that is locking a bunch of buffers you need (for
> command submission or whatever), and then trylocking other buffers to make
> space for the buffers you need to move into VRAM. I guess if only
> trylocking buffers doesn't succeed in freeing up enough VRAM then we could
> go into blocking ww_mutex_locks which need the ctx (and which would need
> all the trylock-acquired buffers to be annotated with the ctx too). TTM
> currently tries to be far enough away from that corner case (using a
> defensive "never use more than 50% of all memory for gfx" approach) that
> it doesn't seem to need that.
>
> Once we get there it should indeed be simply to add a ctx parameter to
> ww_mutex_trylock to fix this case. The TTM side rework is definitely going
> to be the much bigger issue here ...
> -Daniel

Yes, I think fixing trylock to take a ctx parameter would be a better fix than 
ww_mutex_is_owned_by..

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

Re: iomem debugfs patches

[Christian König]

Am 21.02.2018 um 14:52 schrieb StDenis, Tom:

Hi Christian,

I've been running with the last two patches from the ttm changes (that included 
your iomem patch with my write method addition) for a while now.  Through 
piglit, various GL games, with both normal and restricted VRAM without ill 
effect.

Is there anything else that might be required before pushing them?


Well a Reviewed-by from somebody else except you and me. Maybe ping Alex?

Going to commit the single prerequisite patch now which I held back, 
that one had an rb from Roger IIRC.


Christian.



Thanks,
Tom
___
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

iomem debugfs patches

[StDenis, Tom]

Hi Christian,

I've been running with the last two patches from the ttm changes (that included 
your iomem patch with my write method addition) for a while now.  Through 
piglit, various GL games, with both normal and restricted VRAM without ill 
effect.

Is there anything else that might be required before pushing them?

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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Christian König]

The failed VCE resume (-22) seems to be caused by

        if (rdev->vce.vcpu_bo == NULL)
                return -EINVAL;

in radeon_vce.c line 226.


Yeah, you don't seem to have the VCE firmware installed. But as long as 
you don't want to do any advanced video encoding with the hardware we 
can simply ignore that for now.



Any idea where to look from there?


Unfortunately not the slightest.

What's a bit suspicious is that the CPU addresses for the fence 
locations look odd:
[   11.350779] radeon 0001:01:00.0: fence driver on ring 0 use gpu 
addr 0x8c00 and cpu addr 0x7408d6c9
[   11.360274] radeon 0001:01:00.0: fence driver on ring 1 use gpu 
addr 0x8c04 and cpu addr 0x13c11aeb
[   11.369770] radeon 0001:01:00.0: fence driver on ring 2 use gpu 
addr 0x8c08 and cpu addr 0xd4ddd131
[   11.379267] radeon 0001:01:00.0: fence driver on ring 3 use gpu 
addr 0x8c0c and cpu addr 0x263a4d29
[   11.388763] radeon 0001:01:00.0: fence driver on ring 4 use gpu 
addr 0x8c10 and cpu addr 0x6ceb1503
[   11.399277] radeon 0001:01:00.0: fence driver on ring 5 use gpu 
addr 0x00075a18 and cpu addr 0x8935a463

But could as well be that we don't correctly print them.

Apart from that I don't have any good idea any more why that shouldn't work.

Sorry,
Christian.

Am 21.02.2018 um 13:13 schrieb Bas Vermeulen:
I got a 4.15.0 up and running on the board; it needs pci=noaer, but 
boots up and sees the E8860 apart from that.


The relevant dmesg output:

[   10.888426] [drm] radeon kernel modesetting enabled.
[   10.892170] radeon 0001:01:00.0: runtime IRQ mapping not provided 
by arch
[   10.892407] [drm] initializing kernel modesetting (VERDE 
0x1002:0x6822 0x1002:0x031E 0x00).

[   11.138410] ATOM BIOS: E268
[   11.139916] [drm] GPU not posted. posting now...
[   11.168970] radeon 0001:01:00.0: VRAM: 2048M 0x - 
0x7FFF (2048M used)
[   11.176546] radeon 0001:01:00.0: GTT: 2048M 0x8000 - 
0x

[   11.182909] [drm] Detected VRAM RAM=2048M, BAR=256M
[   11.186488] [drm] RAM width 128bits DDR
[   11.189121] [TTM] Zone  kernel: Available graphics memory: 1978102 kiB
[   11.194350] [TTM] Initializing pool allocator
[   11.197407] [TTM] Initializing DMA pool allocator
[   11.200858] [drm] radeon: 2048M of VRAM memory ready
[   11.204527] [drm] radeon: 2048M of GTT memory ready.
[   11.208211] [drm] Loading verde Microcode
[   11.225907] [drm] Internal thermal controller with fan control
[   11.230575] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   11.247750] [drm] radeon: dpm initialized
[   11.268255] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
[   11.273152] [drm] GART: num cpu pages 524288, num gpu pages 524288
[   11.281061] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   11.286060] [drm] PCIE gen 3 link speeds already enabled
[   11.342009] [drm] PCIE GART of 2048M enabled (table at 
0x001D6000).

[   11.347883] radeon 0001:01:00.0: WB enabled
[   11.350779] radeon 0001:01:00.0: fence driver on ring 0 use gpu 
addr 0x8c00 and cpu addr 0x7408d6c9
[   11.360274] radeon 0001:01:00.0: fence driver on ring 1 use gpu 
addr 0x8c04 and cpu addr 0x13c11aeb
[   11.369770] radeon 0001:01:00.0: fence driver on ring 2 use gpu 
addr 0x8c08 and cpu addr 0xd4ddd131
[   11.379267] radeon 0001:01:00.0: fence driver on ring 3 use gpu 
addr 0x8c0c and cpu addr 0x263a4d29
[   11.388763] radeon 0001:01:00.0: fence driver on ring 4 use gpu 
addr 0x8c10 and cpu addr 0x6ceb1503
[   11.399277] radeon 0001:01:00.0: fence driver on ring 5 use gpu 
addr 0x00075a18 and cpu addr 0x8935a463

[   11.419084] radeon 0001:01:00.0: failed VCE resume (-22).
[   11.423181] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   11.428502] [drm] Driver supports precise vblank timestamp query.
[   11.433301] radeon 0001:01:00.0: radeon: MSI limited to 32-bit
[   11.437896] radeon 0001:01:00.0: radeon: using MSI.
[   11.441499] [drm] radeon: irq initialized.
[   12.127423] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 
test failed (scratch(0x850C)=0xCAFEDEAD)

[   12.135788] radeon 0001:01:00.0: disabling GPU acceleration
[   12.320848] [drm] Radeon Display Connectors
[   12.323733] [drm] Connector 0:
[   12.325476] [drm]   DP-1
[   12.326711] [drm]   HPD1
[   12.327935] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 
0x653c 0x653c

[   12.334035] [drm]   Encoders:
[   12.335691] [drm]     DFP1: INTERNAL_UNIPHY1
[   12.338662] [drm] Connector 1:
[   12.340405] [drm]   DP-2
[   12.341625] [drm]   HPD4
[   12.342857] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 
0x656c 0x656c

[   12.348957] [drm]   Encoders:
[   12.350622] [drm]     DFP2: INTERNAL_UNIPHY1
[   12.353583] [drm] Connector 2:
[   12.355335] 

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Bas Vermeulen]

I got a 4.15.0 up and running on the board; it needs pci=noaer, but boots
up and sees the E8860 apart from that.

The relevant dmesg output:

[   10.888426] [drm] radeon kernel modesetting enabled.
[   10.892170] radeon 0001:01:00.0: runtime IRQ mapping not provided by arch
[   10.892407] [drm] initializing kernel modesetting (VERDE 0x1002:0x6822
0x1002:0x031E 0x00).
[   11.138410] ATOM BIOS: E268
[   11.139916] [drm] GPU not posted. posting now...
[   11.168970] radeon 0001:01:00.0: VRAM: 2048M 0x -
0x7FFF (2048M used)
[   11.176546] radeon 0001:01:00.0: GTT: 2048M 0x8000 -
0x
[   11.182909] [drm] Detected VRAM RAM=2048M, BAR=256M
[   11.186488] [drm] RAM width 128bits DDR
[   11.189121] [TTM] Zone  kernel: Available graphics memory: 1978102 kiB
[   11.194350] [TTM] Initializing pool allocator
[   11.197407] [TTM] Initializing DMA pool allocator
[   11.200858] [drm] radeon: 2048M of VRAM memory ready
[   11.204527] [drm] radeon: 2048M of GTT memory ready.
[   11.208211] [drm] Loading verde Microcode
[   11.225907] [drm] Internal thermal controller with fan control
[   11.230575] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   11.247750] [drm] radeon: dpm initialized
[   11.268255] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
[   11.273152] [drm] GART: num cpu pages 524288, num gpu pages 524288
[   11.281061] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   11.286060] [drm] PCIE gen 3 link speeds already enabled
[   11.342009] [drm] PCIE GART of 2048M enabled (table at
0x001D6000).
[   11.347883] radeon 0001:01:00.0: WB enabled
[   11.350779] radeon 0001:01:00.0: fence driver on ring 0 use gpu addr
0x8c00 and cpu addr 0x7408d6c9
[   11.360274] radeon 0001:01:00.0: fence driver on ring 1 use gpu addr
0x8c04 and cpu addr 0x13c11aeb
[   11.369770] radeon 0001:01:00.0: fence driver on ring 2 use gpu addr
0x8c08 and cpu addr 0xd4ddd131
[   11.379267] radeon 0001:01:00.0: fence driver on ring 3 use gpu addr
0x8c0c and cpu addr 0x263a4d29
[   11.388763] radeon 0001:01:00.0: fence driver on ring 4 use gpu addr
0x8c10 and cpu addr 0x6ceb1503
[   11.399277] radeon 0001:01:00.0: fence driver on ring 5 use gpu addr
0x00075a18 and cpu addr 0x8935a463
[   11.419084] radeon 0001:01:00.0: failed VCE resume (-22).
[   11.423181] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   11.428502] [drm] Driver supports precise vblank timestamp query.
[   11.433301] radeon 0001:01:00.0: radeon: MSI limited to 32-bit
[   11.437896] radeon 0001:01:00.0: radeon: using MSI.
[   11.441499] [drm] radeon: irq initialized.
[   12.127423] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test
failed (scratch(0x850C)=0xCAFEDEAD)
[   12.135788] radeon 0001:01:00.0: disabling GPU acceleration
[   12.320848] [drm] Radeon Display Connectors
[   12.323733] [drm] Connector 0:
[   12.325476] [drm]   DP-1
[   12.326711] [drm]   HPD1
[   12.327935] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538
0x653c 0x653c
[   12.334035] [drm]   Encoders:
[   12.335691] [drm] DFP1: INTERNAL_UNIPHY1
[   12.338662] [drm] Connector 1:
[   12.340405] [drm]   DP-2
[   12.341625] [drm]   HPD4
[   12.342857] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568
0x656c 0x656c
[   12.348957] [drm]   Encoders:
[   12.350622] [drm] DFP2: INTERNAL_UNIPHY1
[   12.353583] [drm] Connector 2:
[   12.355335] [drm]   DP-3
[   12.356557] [drm]   HPD5
[   12.357788] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548
0x654c 0x654c
[   12.363888] [drm]   Encoders:
[   12.365543] [drm] DFP3: INTERNAL_UNIPHY2
[   12.368514] [drm] Connector 3:
[   12.370267] [drm]   DP-4
[   12.371487] [drm]   HPD6
[   12.372709] [drm]   DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578
0x657c 0x657c
[   12.378808] [drm]   Encoders:
[   12.380464] [drm] DFP4: INTERNAL_UNIPHY2
[   12.508848] [drm] Cannot find any crtc or sizes
[   12.512716] [drm] Initialized radeon 2.50.0 20080528 for 0001:01:00.0 on
minor 0
[   13.636810] [drm] Cannot find any crtc or sizes

The failed VCE resume (-22) seems to be caused by

if (rdev->vce.vcpu_bo == NULL)
return -EINVAL;

in radeon_vce.c line 226. Any idea where to look from there?

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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Christian König]

Am 21.02.2018 um 12:01 schrieb Bas Vermeulen:
On Wed, Feb 21, 2018 at 11:43 AM, Christian König 
> wrote:


Am 21.02.2018 um 11:38 schrieb Bas Vermeulen:

On Wed, Feb 21, 2018 at 10:31 AM, Michel Dänzer
> wrote:

On 2018-02-21 10:18 AM, Bas Vermeulen wrote:
> On Wed, Feb 21, 2018 at 10:06 AM, Michel Dänzer

> >> wrote:
>
>     > My question is, what do I need to do to correctly
initialize the E8860
>     > board on my powerpc machine?
>
>     Start by sharing the dmesg output, and maybe also the
kernel build
>     configuration file.
>
>
> Both are attached (gzipped because of size).

It might be related to this:

[   10.482772] radeon: No coherent DMA available.


I updated my device-tree to add incoming pcie ranges, and that
removes this error:

[   10.161044] [drm] radeon kernel modesetting enabled.
[   10.165168] [drm] initializing kernel modesetting (VERDE
0x1002:0x6822 0x1002:0x031E).
[   10.171799] radeon: No coherent DMA available.


Well that reads like the problem is still there and yes when you
don't have coherent DMA possibility that would explain why it
doesn't work.

Can you provide us with a dump of /proc/iomem as well?


Sure:

- : System RAM


Mhm, ok all system memory is below 4GB. So at least in theory it should 
work even without coherent DMA.


No idea what goes wrong here,
Christian.


c2000-c2fff : /pcie@ffe25
  c2000-c2fff : PCI Bus 0001:01
    c2100-c210f : 0001:01:00.0
    c2110-c211f : 0001:01:00.0
c4000-c7fff : /pcie@ffe27
  c4000-c7fff : PCI Bus 0002:01
    c4100-c4103 : 0002:01:00.0
    c4104-c4105 : 0002:01:00.0
    c4106-c41063fff : 0002:01:00.1
    c6000-c6fff : 0002:01:00.0
fe800-fefff : fe800.nor
ffe008000-ffe008fff : mpc85xx_mc_err
ffe100100-ffe10017f : dma
ffe100180-ffe1001ff : dma
ffe100200-ffe10027f : dma
ffe100280-ffe1002ff : dma
ffe100400-ffe10047f : dma
ffe100480-ffe1004ff : dma
ffe100500-ffe10057f : dma
ffe100580-ffe1005ff : dma
ffe101100-ffe10117f : dma
ffe101180-ffe1011ff : dma
ffe101200-ffe10127f : dma
ffe101280-ffe1012ff : dma
ffe101400-ffe10147f : dma
ffe101480-ffe1014ff : dma
ffe101500-ffe10157f : dma
ffe101580-ffe1015ff : dma
ffe102100-ffe10217f : dma
ffe102180-ffe1021ff : dma
ffe102200-ffe10227f : dma
ffe102280-ffe1022ff : dma
ffe102400-ffe10247f : dma
ffe102480-ffe1024ff : dma
ffe102500-ffe10257f : dma
ffe102580-ffe1025ff : dma
ffe11-ffe110fff : /soc@ffe00/spi@11
ffe114000-ffe114fff : mmc0
ffe11c500-ffe11c507 : serial
ffe11c600-ffe11c607 : serial
ffe11d500-ffe11d507 : serial
ffe11d600-ffe11d607 : serial
ffe21-ffe210fff : /soc@ffe00/usb@21
  ffe21-ffe210fff : /soc@ffe00/usb@21
ffe211000-ffe211fff : /soc@ffe00/usb@211000
  ffe211000-ffe211fff : /soc@ffe00/usb@211000
ffe240e00-ffe24 : mpc85xx_pci_err
ffe250e00-ffe25 : mpc85xx_pci_err
ffe270e00-ffe27 : mpc85xx_pci_err
ffe40-ffe4f : fman
  ffe40-ffe45 : fman-muram
  ffe482000-ffe482fff : fman-port-hc
  ffe483000-ffe483fff : fman-port-hc
  ffe484000-ffe484fff : fman-port-hc
  ffe485000-ffe485fff : fman-port-hc
  ffe486000-ffe486fff : fman-port-hc
  ffe487000-ffe487fff : fman-port-hc
  ffe488000-ffe488fff : fman-port-hc
  ffe489000-ffe489fff : fman-port-hc
  ffe48a000-ffe48afff : fman-port-hc
  ffe48b000-ffe48bfff : fman-port-hc
  ffe48c000-ffe48cfff : fman-port-hc
  ffe48d000-ffe48dfff : fman-port-hc
  ffe49-ffe490fff : fman-port-hc
  ffe491000-ffe491fff : fman-port-hc
  ffe4a8000-ffe4a8fff : fman-port-hc
  ffe4a9000-ffe4a9fff : fman-port-hc
  ffe4aa000-ffe4aafff : fman-port-hc
  ffe4ab000-ffe4abfff : fman-port-hc
  ffe4ac000-ffe4acfff : fman-port-hc
  ffe4ad000-ffe4adfff : fman-port-hc
  ffe4b-ffe4b0fff : fman-port-hc
  ffe4b1000-ffe4b1fff : fman-port-hc
  ffe4dc000-ffe4dcfff : fman-vsp
  ffe4e-ffe4e0fff : mac
  ffe4e2000-ffe4e2fff : mac
  ffe4e4000-ffe4e4fff : mac
  ffe4e6000-ffe4e6fff : mac
  ffe4f-ffe4f0fff : mac
  ffe4f2000-ffe4f2fff : mac
  ffe4fe000-ffe4fefff : fman-rtc

Bas Vermeulen


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

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

[Christian König]

Am 21.02.2018 um 11:54 schrieb Maarten Lankhorst:

Op 21-02-18 om 00:56 schreef Daniel Vetter:

On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:

On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:

Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:

On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:

OK, but neither case would in fact need the !ctx case right? That's just
there for completeness sake?

Unfortunately not. TTM uses trylock to lock BOs which are about to be
evicted to make room for all the BOs locked with a ctx.

I need to be able to distinct between the BOs which are trylocked and those
which are locked with a ctx.

Writing this I actually noticed the current version is buggy, cause even
when we check the mutex owner we still need to make sure that the ctx in the
lock is NULL.

Hurm... I can't remember why trylocks behave like that, and it seems
rather unfortunate / inconsistent.

Actually for me that is rather fortunate, cause I need to distinct between
the locks acquired through trylock and lock.

I suppose that would always be possible using:
ww_mutex_trylock(.ctx=NULL), and it could be that there simply weren't
any immediate uses for a !NULL trylock and it was thus not implemented.

But that is all very long ago..

I think we simple never had a use-case for interleaving ww_mutex_lock(ctx)
and ww_mutex_trylock(ctx). Nesting multiple trylocks in ctx-locks happens
plenty, but not further:

The common use-case for that is locking a bunch of buffers you need (for
command submission or whatever), and then trylocking other buffers to make
space for the buffers you need to move into VRAM. I guess if only
trylocking buffers doesn't succeed in freeing up enough VRAM then we could
go into blocking ww_mutex_locks which need the ctx (and which would need
all the trylock-acquired buffers to be annotated with the ctx too). TTM
currently tries to be far enough away from that corner case (using a
defensive "never use more than 50% of all memory for gfx" approach) that
it doesn't seem to need that.

Once we get there it should indeed be simply to add a ctx parameter to
ww_mutex_trylock to fix this case. The TTM side rework is definitely going
to be the much bigger issue here ...
-Daniel

Yes, I think fixing trylock to take a ctx parameter would be a better fix than 
ww_mutex_is_owned_by..


Yeah, but as I noted now multiple times that won't work.

See I need to distinct between the BOs acquired with and without a 
context. Otherwise the whole approach doesn't make much sense.


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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Christian König]

Am 21.02.2018 um 11:38 schrieb Bas Vermeulen:
On Wed, Feb 21, 2018 at 10:31 AM, Michel Dänzer > wrote:


On 2018-02-21 10:18 AM, Bas Vermeulen wrote:
> On Wed, Feb 21, 2018 at 10:06 AM, Michel Dänzer

> >> wrote:
>
>     > My question is, what do I need to do to correctly
initialize the E8860
>     > board on my powerpc machine?
>
>     Start by sharing the dmesg output, and maybe also the kernel
build
>     configuration file.
>
>
> Both are attached (gzipped because of size).

It might be related to this:

[   10.482772] radeon: No coherent DMA available.


I updated my device-tree to add incoming pcie ranges, and that removes 
this error:


[   10.161044] [drm] radeon kernel modesetting enabled.
[   10.165168] [drm] initializing kernel modesetting (VERDE 
0x1002:0x6822 0x1002:0x031E).

[   10.171799] radeon: No coherent DMA available.


Well that reads like the problem is still there and yes when you don't 
have coherent DMA possibility that would explain why it doesn't work.


Can you provide us with a dump of /proc/iomem as well?

Thanks,
Christian.


[   10.171831] [drm] register mmio base: 0x4100
[   10.171832] [drm] register mmio size: 262144
[   10.411061] ATOM BIOS: E268
[   10.412569] [drm] GPU not posted. posting now...
[   10.441831] radeon 0002:01:00.0: VRAM: 2048M 0x - 
0x7FFF (2048M used)
[   10.449408] radeon 0002:01:00.0: GTT: 1024M 0x8000 - 
0xBFFF

[   10.455771] [drm] Detected VRAM RAM=2048M, BAR=256M
[   10.459349] [drm] RAM width 128bits DDR
[   10.462455] [TTM] Zone  kernel: Available graphics memory: 1978634 kiB
[   10.467688] [TTM] Initializing pool allocator
[   10.470755] [TTM] Initializing DMA pool allocator
[   10.474194] [drm] radeon: 2048M of VRAM memory ready
[   10.477859] [drm] radeon: 1024M of GTT memory ready.
[   10.481549] [drm] Loading verde Microcode
[   10.500383] [drm] Internal thermal controller with fan control
[   10.505048] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   10.522317] [drm] radeon: dpm initialized
[   10.539675] [drm] GART: num cpu pages 262144, num gpu pages 262144
[   10.546129] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   10.551121] [drm] PCIE gen 3 link speeds already enabled
[   10.581276] [drm] PCIE GART of 1024M enabled (table at 
0x00277000).

[   10.587142] radeon 0002:01:00.0: WB enabled
[   10.590019] radeon 0002:01:00.0: fence driver on ring 0 use gpu 
addr 0x8c00 and cpu addr 0xc000ed15bc00
[   10.599515] radeon 0002:01:00.0: fence driver on ring 1 use gpu 
addr 0x8c04 and cpu addr 0xc000ed15bc04
[   10.609008] radeon 0002:01:00.0: fence driver on ring 2 use gpu 
addr 0x8c08 and cpu addr 0xc000ed15bc08
[   10.618499] radeon 0002:01:00.0: fence driver on ring 3 use gpu 
addr 0x8c0c and cpu addr 0xc000ed15bc0c
[   10.627992] radeon 0002:01:00.0: fence driver on ring 4 use gpu 
addr 0x8c10 and cpu addr 0xc000ed15bc10
[   10.639273] radeon 0002:01:00.0: fence driver on ring 5 use gpu 
addr 0x00075a18 and cpu addr 0x880088db5a18

[   10.648762] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   10.654078] [drm] Driver supports precise vblank timestamp query.
[   10.658873] radeon 0002:01:00.0: radeon: MSI limited to 32-bit
[   10.663455] radeon 0002:01:00.0: radeon: using MSI.
[   10.667069] [drm] radeon: irq initialized.
[   11.353989] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 
test failed (scratch(0x850C)=0xCAFEDEAD)

[   11.362354] radeon 0002:01:00.0: disabling GPU acceleration
[   11.543395] [drm] Radeon Display Connectors
[   11.546272] [drm] Connector 0:
[   11.548027] [drm]   DP-1
[   11.549248] [drm]   HPD1
[   11.550471] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 
0x653c 0x653c

[   11.556569] [drm]   Encoders:
[   11.558224] [drm]     DFP1: INTERNAL_UNIPHY1
[   11.561192] [drm] Connector 1:
[   11.562941] [drm]   DP-2
[   11.564162] [drm]   HPD4
[   11.565384] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 
0x656c 0x656c

[   11.571480] [drm]   Encoders:
[   11.573136] [drm]     DFP2: INTERNAL_UNIPHY1
[   11.576103] [drm] Connector 2:
[   11.577846] [drm]   DP-3
[   11.579074] [drm]   HPD5
[   11.580297] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 
0x654c 0x654c

[   11.586393] [drm]   Encoders:
[   11.588057] [drm]     DFP3: INTERNAL_UNIPHY2
[   11.591023] [drm] Connector 3:
[   11.592767] [drm]   DP-4
[   11.593987] [drm]   HPD6
[   11.595216] [drm]   DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578 
0x657c 0x657c

[   11.601313] [drm]   Encoders:
[   11.602978] [drm]     DFP4: INTERNAL_UNIPHY2
[   11.692728] radeon 0002:01:00.0: No connectors reported connected 
with modes

[   

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Bas Vermeulen]

On Wed, Feb 21, 2018 at 10:31 AM, Michel Dänzer  wrote:

> On 2018-02-21 10:18 AM, Bas Vermeulen wrote:
> > On Wed, Feb 21, 2018 at 10:06 AM, Michel Dänzer  > > wrote:
> >
> > > My question is, what do I need to do to correctly initialize the
> E8860
> > > board on my powerpc machine?
> >
> > Start by sharing the dmesg output, and maybe also the kernel build
> > configuration file.
> >
> >
> > Both are attached (gzipped because of size).
>
> It might be related to this:
>
> [   10.482772] radeon: No coherent DMA available.
>
>
I updated my device-tree to add incoming pcie ranges, and that removes this
error:

[   10.161044] [drm] radeon kernel modesetting enabled.
[   10.165168] [drm] initializing kernel modesetting (VERDE 0x1002:0x6822
0x1002:0x031E).
[   10.171799] radeon: No coherent DMA available.
[   10.171831] [drm] register mmio base: 0x4100
[   10.171832] [drm] register mmio size: 262144
[   10.411061] ATOM BIOS: E268
[   10.412569] [drm] GPU not posted. posting now...
[   10.441831] radeon 0002:01:00.0: VRAM: 2048M 0x -
0x7FFF (2048M used)
[   10.449408] radeon 0002:01:00.0: GTT: 1024M 0x8000 -
0xBFFF
[   10.455771] [drm] Detected VRAM RAM=2048M, BAR=256M
[   10.459349] [drm] RAM width 128bits DDR
[   10.462455] [TTM] Zone  kernel: Available graphics memory: 1978634 kiB
[   10.467688] [TTM] Initializing pool allocator
[   10.470755] [TTM] Initializing DMA pool allocator
[   10.474194] [drm] radeon: 2048M of VRAM memory ready
[   10.477859] [drm] radeon: 1024M of GTT memory ready.
[   10.481549] [drm] Loading verde Microcode
[   10.500383] [drm] Internal thermal controller with fan control
[   10.505048] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   10.522317] [drm] radeon: dpm initialized
[   10.539675] [drm] GART: num cpu pages 262144, num gpu pages 262144
[   10.546129] [drm] probing gen 2 caps for device 1957:830 = 73f443/e
[   10.551121] [drm] PCIE gen 3 link speeds already enabled
[   10.581276] [drm] PCIE GART of 1024M enabled (table at
0x00277000).
[   10.587142] radeon 0002:01:00.0: WB enabled
[   10.590019] radeon 0002:01:00.0: fence driver on ring 0 use gpu addr
0x8c00 and cpu addr 0xc000ed15bc00
[   10.599515] radeon 0002:01:00.0: fence driver on ring 1 use gpu addr
0x8c04 and cpu addr 0xc000ed15bc04
[   10.609008] radeon 0002:01:00.0: fence driver on ring 2 use gpu addr
0x8c08 and cpu addr 0xc000ed15bc08
[   10.618499] radeon 0002:01:00.0: fence driver on ring 3 use gpu addr
0x8c0c and cpu addr 0xc000ed15bc0c
[   10.627992] radeon 0002:01:00.0: fence driver on ring 4 use gpu addr
0x8c10 and cpu addr 0xc000ed15bc10
[   10.639273] radeon 0002:01:00.0: fence driver on ring 5 use gpu addr
0x00075a18 and cpu addr 0x880088db5a18
[   10.648762] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   10.654078] [drm] Driver supports precise vblank timestamp query.
[   10.658873] radeon 0002:01:00.0: radeon: MSI limited to 32-bit
[   10.663455] radeon 0002:01:00.0: radeon: using MSI.
[   10.667069] [drm] radeon: irq initialized.
[   11.353989] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test
failed (scratch(0x850C)=0xCAFEDEAD)
[   11.362354] radeon 0002:01:00.0: disabling GPU acceleration
[   11.543395] [drm] Radeon Display Connectors
[   11.546272] [drm] Connector 0:
[   11.548027] [drm]   DP-1
[   11.549248] [drm]   HPD1
[   11.550471] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538
0x653c 0x653c
[   11.556569] [drm]   Encoders:
[   11.558224] [drm] DFP1: INTERNAL_UNIPHY1
[   11.561192] [drm] Connector 1:
[   11.562941] [drm]   DP-2
[   11.564162] [drm]   HPD4
[   11.565384] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568
0x656c 0x656c
[   11.571480] [drm]   Encoders:
[   11.573136] [drm] DFP2: INTERNAL_UNIPHY1
[   11.576103] [drm] Connector 2:
[   11.577846] [drm]   DP-3
[   11.579074] [drm]   HPD5
[   11.580297] [drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548
0x654c 0x654c
[   11.586393] [drm]   Encoders:
[   11.588057] [drm] DFP3: INTERNAL_UNIPHY2
[   11.591023] [drm] Connector 3:
[   11.592767] [drm]   DP-4
[   11.593987] [drm]   HPD6
[   11.595216] [drm]   DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578
0x657c 0x657c
[   11.601313] [drm]   Encoders:
[   11.602978] [drm] DFP4: INTERNAL_UNIPHY2
[   11.692728] radeon 0002:01:00.0: No connectors reported connected with
modes
[   11.698480] [drm] Cannot find any crtc or sizes - going 1024x768
[   11.708402] [drm] fb mappable at 0xC60478000
[   11.711369] [drm] vram apper at 0xC6000
[   11.714242] [drm] size 3145728
[   11.715993] [drm] fb depth is 24
[   11.717910] [drm]pitch is 4096
[   11.720091] radeon 0002:01:00.0: fb0: radeondrmfb frame buffer device
[   11.725236] radeon 0002:01:00.0: registered panic notifier
[   11.742619] 

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Bas Vermeulen]

On Wed, Feb 21, 2018 at 10:36 AM, Michel Dänzer  wrote:

> On 2018-02-21 09:49 AM, Bas Vermeulen wrote:
> > Hi,
> >
> > I am unsure if this is the right place to ask, but it seems relevant.
> >
> > I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
> > board (T2080RDB from NXP).
>
> BTW, looks like the CPU runs in big endian mode
> (CONFIG_CPU_BIG_ENDIAN=y), doesn't it? If so, be warned that this is
> just the tip of the iceberg. The Mesa radeonsi driver doesn't work on
> big endian hosts yet, fixing that would involve a lot of work and pain.
> And without that, you won't be able to actually use any hardware
> acceleration.
>

Understood. At the moment I want to understand what I am doing wrong in
regards to the kernel part,
I'll cross the userspace bridge when I get there. The end-goal is a
completely different (real-time) OS,
and understanding how things work will help in any case.

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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Bas Vermeulen]

On Wed, Feb 21, 2018 at 10:31 AM, Christian König 
wrote:

> Am 21.02.2018 um 10:23 schrieb Bas Vermeulen:
>
> On Wed, Feb 21, 2018 at 10:14 AM, Christian König <
> ckoenig.leichtzumer...@gmail.com> wrote:
>
>> Am 21.02.2018 um 10:06 schrieb Michel Dänzer:
>>
>>> On 2018-02-21 09:49 AM, Bas Vermeulen wrote:
>>>
 Hi,

 I am unsure if this is the right place to ask, but it seems relevant.

>>>
>> Well this list is certainly the right place to ask :)
>
>
> That's what I was hoping for :)
>
>
>>
>> I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
 board (T2080RDB from NXP).
 The T2080RDB does not use a BIOS, and uses u-boot to bootstrap Linux.

 I have the E8860 connected to a PCIe x4 slot with an adapter. The kernel
 is a 4.1, with DRM included in the kernel and the radeon as a module.
 The radeon driver detects the card, notices the BIOS hasn't posted and
 starts things up.
 After that, the ring tests get run, and fails on the ring 0 test,
 disabling acceleration. The graphics card is (or seems to be) working
 apart from that, the driver starts up and sees the connectors on the
 board.

 When I compare dmesg on an x86 machine and the PPC machine, I see that
 the x86 machine loads a lot more firmware from the kernel (probably the
 acceleration parts?).

>>> FWIW, that's probably just a subsequent symptom due to the ring test
>>> failure.
>>>
>>
>> Could be, but IIRC we load all the firmware first then initialize things
>> and then do the ring tests when we try to start the rings.
>>
>> BTW: What driver are you using? radeon or amdgpu?
>
>
> This is a south-island or sea-island chip, so using radeon.
>
>
> Well SI is also supported by amdgpu, I would give that a try as well.
>

Didn't know that,


> And BTW please try a more recent kernel as well, 4.1 is rather old.
>

Somewhat easier said than done; it's an NXP board, and they only supply 4.1
at the moment.
I'll see if I can upgrade to 4.15.x.


>
>
>
>
>>
>> My question is, what do I need to do to correctly initialize the E8860
 board on my powerpc machine?

>>> Start by sharing the dmesg output, and maybe also the kernel build
>>> configuration file.
>>>
>>
>> Maybe also open a bug report to attach the dmesg, see
>> bugs.freedesktop.org.
>>
>
> Sure. What project does the radeon driver fall under? I couldn't find the
> right category under Mesa, not sure what
> to file it under.
>
>
> Product DRI and then select DRM/Radeon as component.
>

Gotcha.

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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Michel Dänzer]

On 2018-02-21 09:49 AM, Bas Vermeulen wrote:
> Hi,
> 
> I am unsure if this is the right place to ask, but it seems relevant.
> 
> I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
> board (T2080RDB from NXP).

BTW, looks like the CPU runs in big endian mode
(CONFIG_CPU_BIG_ENDIAN=y), doesn't it? If so, be warned that this is
just the tip of the iceberg. The Mesa radeonsi driver doesn't work on
big endian hosts yet, fixing that would involve a lot of work and pain.
And without that, you won't be able to actually use any hardware
acceleration.


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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Christian König]

Am 21.02.2018 um 10:23 schrieb Bas Vermeulen:
On Wed, Feb 21, 2018 at 10:14 AM, Christian König 
> wrote:


Am 21.02.2018 um 10:06 schrieb Michel Dänzer:

On 2018-02-21 09:49 AM, Bas Vermeulen wrote:

Hi,

I am unsure if this is the right place to ask, but it
seems relevant.


Well this list is certainly the right place to ask :)


That's what I was hoping for :)


I am trying to use an AMD E8860 (SI) board connected to an
E6500 PowerPC
board (T2080RDB from NXP).
The T2080RDB does not use a BIOS, and uses u-boot to
bootstrap Linux.

I have the E8860 connected to a PCIe x4 slot with an
adapter. The kernel
is a 4.1, with DRM included in the kernel and the radeon
as a module.
The radeon driver detects the card, notices the BIOS
hasn't posted and
starts things up.
After that, the ring tests get run, and fails on the ring
0 test,
disabling acceleration. The graphics card is (or seems to
be) working
apart from that, the driver starts up and sees the
connectors on the board.

When I compare dmesg on an x86 machine and the PPC
machine, I see that
the x86 machine loads a lot more firmware from the kernel
(probably the
acceleration parts?).

FWIW, that's probably just a subsequent symptom due to the
ring test
failure.


Could be, but IIRC we load all the firmware first then initialize
things and then do the ring tests when we try to start the rings.

BTW: What driver are you using? radeon or amdgpu?


This is a south-island or sea-island chip, so using radeon.


Well SI is also supported by amdgpu, I would give that a try as well.

And BTW please try a more recent kernel as well, 4.1 is rather old.



My question is, what do I need to do to correctly
initialize the E8860
board on my powerpc machine?

Start by sharing the dmesg output, and maybe also the kernel build
configuration file.


Maybe also open a bug report to attach the dmesg, see
bugs.freedesktop.org .


Sure. What project does the radeon driver fall under? I couldn't find 
the right category under Mesa, not sure what

to file it under.


Product DRI and then select DRM/Radeon as component.

Christian.



Bas Vermeulen


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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Michel Dänzer]

On 2018-02-21 10:18 AM, Bas Vermeulen wrote:
> On Wed, Feb 21, 2018 at 10:06 AM, Michel Dänzer  > wrote:
> 
> > My question is, what do I need to do to correctly initialize the E8860
> > board on my powerpc machine?
> 
> Start by sharing the dmesg output, and maybe also the kernel build
> configuration file.
> 
>  
> Both are attached (gzipped because of size).

It might be related to this:

[   10.482772] radeon: No coherent DMA available.


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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Bas Vermeulen]

On Wed, Feb 21, 2018 at 10:14 AM, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:

> Am 21.02.2018 um 10:06 schrieb Michel Dänzer:
>
>> On 2018-02-21 09:49 AM, Bas Vermeulen wrote:
>>
>>> Hi,
>>>
>>> I am unsure if this is the right place to ask, but it seems relevant.
>>>
>>
> Well this list is certainly the right place to ask :)


That's what I was hoping for :)


>
> I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
>>> board (T2080RDB from NXP).
>>> The T2080RDB does not use a BIOS, and uses u-boot to bootstrap Linux.
>>>
>>> I have the E8860 connected to a PCIe x4 slot with an adapter. The kernel
>>> is a 4.1, with DRM included in the kernel and the radeon as a module.
>>> The radeon driver detects the card, notices the BIOS hasn't posted and
>>> starts things up.
>>> After that, the ring tests get run, and fails on the ring 0 test,
>>> disabling acceleration. The graphics card is (or seems to be) working
>>> apart from that, the driver starts up and sees the connectors on the
>>> board.
>>>
>>> When I compare dmesg on an x86 machine and the PPC machine, I see that
>>> the x86 machine loads a lot more firmware from the kernel (probably the
>>> acceleration parts?).
>>>
>> FWIW, that's probably just a subsequent symptom due to the ring test
>> failure.
>>
>
> Could be, but IIRC we load all the firmware first then initialize things
> and then do the ring tests when we try to start the rings.
>
> BTW: What driver are you using? radeon or amdgpu?


This is a south-island or sea-island chip, so using radeon.


>
> My question is, what do I need to do to correctly initialize the E8860
>>> board on my powerpc machine?
>>>
>> Start by sharing the dmesg output, and maybe also the kernel build
>> configuration file.
>>
>
> Maybe also open a bug report to attach the dmesg, see bugs.freedesktop.org
> .
>

Sure. What project does the radeon driver fall under? I couldn't find the
right category under Mesa, not sure what
to file it under.

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

[PATCH] locking/ww_mutex: add ww_mutex_is_owned_by function v5

[Christian König]

amdgpu needs to verify if userspace sends us valid addresses and the simplest
way of doing this is to check if the buffer object is locked with the ticket
of the current submission.

Clean up the access to the ww_mutex internals by providing a function
for this and extend the check to the thread owning the underlying mutex.

v2: split amdgpu changes into separate patch as suggested by Alex
v3: change logic as suggested by Daniel
v4: fix test in case ctx is NULL
v5: fix stupid typo and improve kerneldoc

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
---
 include/linux/ww_mutex.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 39fda195bf78..6355de00239d 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -358,4 +358,24 @@ static inline bool ww_mutex_is_locked(struct ww_mutex 
*lock)
return mutex_is_locked(>base);
 }
 
+/**
+ * ww_mutex_is_owned_by - is the w/w mutex locked by this task in that context
+ * @lock: the mutex to be queried
+ * @ctx: the w/w acquire context to test
+ *
+ * If @ctx is not NULL test if the mutex is owned by this context.
+ * If @ctx is NULL test if the mutex is owned by the current thread and not
+ * locked in any context, i.e. acquired using either ww_mutex_trylock() or
+ * ww_mutex_lock() without supplying a _acquire_ctx.
+ */
+static inline bool ww_mutex_is_owned_by(struct ww_mutex *lock,
+   struct ww_acquire_ctx *ctx)
+{
+   if (ctx)
+   return likely(READ_ONCE(lock->ctx) == ctx);
+
+   return likely(__mutex_owner(>base) == current) &&
+   likely(READ_ONCE(lock->ctx) == NULL);
+}
+
 #endif
-- 
2.14.1

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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Bas Vermeulen]

On Wed, Feb 21, 2018 at 10:06 AM, Michel Dänzer  wrote:

> On 2018-02-21 09:49 AM, Bas Vermeulen wrote:
> > Hi,
> >
> > I am unsure if this is the right place to ask, but it seems relevant.
> >
> > I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
> > board (T2080RDB from NXP).
> > The T2080RDB does not use a BIOS, and uses u-boot to bootstrap Linux.
> >
> > I have the E8860 connected to a PCIe x4 slot with an adapter. The kernel
> > is a 4.1, with DRM included in the kernel and the radeon as a module.
> > The radeon driver detects the card, notices the BIOS hasn't posted and
> > starts things up.
> > After that, the ring tests get run, and fails on the ring 0 test,
> > disabling acceleration. The graphics card is (or seems to be) working
> > apart from that, the driver starts up and sees the connectors on the
> board.
> >
> > When I compare dmesg on an x86 machine and the PPC machine, I see that
> > the x86 machine loads a lot more firmware from the kernel (probably the
> > acceleration parts?).
>
> FWIW, that's probably just a subsequent symptom due to the ring test
> failure.
>

Gotcha.


> > My question is, what do I need to do to correctly initialize the E8860
> > board on my powerpc machine?
>
> Start by sharing the dmesg output, and maybe also the kernel build
> configuration file.
>

Both are attached (gzipped because of size).

The card gets initialized of a sorts, and there are no PCIE errors (using a
slightly different
setup for the PCIe controllers in my device-tree for the board results in
PCIe errors being thrown).

Bas Vermeulen


defconfig.e8860.gz
Description: GNU Zip compressed data


dmesg.e8860.gz
Description: GNU Zip compressed data
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Christian König]

Am 21.02.2018 um 10:06 schrieb Michel Dänzer:

On 2018-02-21 09:49 AM, Bas Vermeulen wrote:

Hi,

I am unsure if this is the right place to ask, but it seems relevant.


Well this list is certainly the right place to ask :)


I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
board (T2080RDB from NXP).
The T2080RDB does not use a BIOS, and uses u-boot to bootstrap Linux.

I have the E8860 connected to a PCIe x4 slot with an adapter. The kernel
is a 4.1, with DRM included in the kernel and the radeon as a module.
The radeon driver detects the card, notices the BIOS hasn't posted and
starts things up.
After that, the ring tests get run, and fails on the ring 0 test,
disabling acceleration. The graphics card is (or seems to be) working
apart from that, the driver starts up and sees the connectors on the board.

When I compare dmesg on an x86 machine and the PPC machine, I see that
the x86 machine loads a lot more firmware from the kernel (probably the
acceleration parts?).

FWIW, that's probably just a subsequent symptom due to the ring test
failure.


Could be, but IIRC we load all the firmware first then initialize things 
and then do the ring tests when we try to start the rings.


BTW: What driver are you using? radeon or amdgpu?


My question is, what do I need to do to correctly initialize the E8860
board on my powerpc machine?

Start by sharing the dmesg output, and maybe also the kernel build
configuration file.


Maybe also open a bug report to attach the dmesg, see bugs.freedesktop.org.

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

Re: AMD E8860 on PowerPC with u-boot (T2080)

[Michel Dänzer]

On 2018-02-21 09:49 AM, Bas Vermeulen wrote:
> Hi,
> 
> I am unsure if this is the right place to ask, but it seems relevant.
> 
> I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
> board (T2080RDB from NXP).
> The T2080RDB does not use a BIOS, and uses u-boot to bootstrap Linux.
> 
> I have the E8860 connected to a PCIe x4 slot with an adapter. The kernel
> is a 4.1, with DRM included in the kernel and the radeon as a module.
> The radeon driver detects the card, notices the BIOS hasn't posted and
> starts things up.
> After that, the ring tests get run, and fails on the ring 0 test,
> disabling acceleration. The graphics card is (or seems to be) working
> apart from that, the driver starts up and sees the connectors on the board.
> 
> When I compare dmesg on an x86 machine and the PPC machine, I see that
> the x86 machine loads a lot more firmware from the kernel (probably the
> acceleration parts?).

FWIW, that's probably just a subsequent symptom due to the ring test
failure.


> My question is, what do I need to do to correctly initialize the E8860
> board on my powerpc machine?

Start by sharing the dmesg output, and maybe also the kernel build
configuration file.


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

AMD E8860 on PowerPC with u-boot (T2080)

[Bas Vermeulen]

Hi,

I am unsure if this is the right place to ask, but it seems relevant.

I am trying to use an AMD E8860 (SI) board connected to an E6500 PowerPC
board (T2080RDB from NXP).
The T2080RDB does not use a BIOS, and uses u-boot to bootstrap Linux.

I have the E8860 connected to a PCIe x4 slot with an adapter. The kernel is
a 4.1, with DRM included in the kernel and the radeon as a module. The
radeon driver detects the card, notices the BIOS hasn't posted and starts
things up.
After that, the ring tests get run, and fails on the ring 0 test, disabling
acceleration. The graphics card is (or seems to be) working apart from
that, the driver starts up and sees the connectors on the board.

When I compare dmesg on an x86 machine and the PPC machine, I see that the
x86 machine loads a lot more firmware from the kernel (probably the
acceleration parts?).

My question is, what do I need to do to correctly initialize the E8860
board on my powerpc machine?
Is there some documentation you can point me to, or someone to ask?

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