parisc: fix LMMIO mismatch between PAT length and MASK register

From: Thomas Bogendoerfer <[email protected]>

The LMMIO length reported by PAT and the length given by the LBA MASK register are not consistent. This leads e.g. to a non-working ATI FireGL card with the radeon DRM driver since the memory can't be mapped.

Fix this by correctly adjusting the resource sizes.

Signed-off-by Helge Deller <[email protected]>

drivers/parisc/lba_pci.c +3 -0

index 1f05913..7dc0e40 100644
@@ -994,6 +994,15 @@ lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
                case PAT_LMMIO:
                        /* used to fix up pre-initialized MEM BARs */
                        if (!lba_dev->hba.lmmio_space.flags) {
+                               unsigned long lba_len;
+                               lba_len = ~READ_REG32(lba_dev->hba.base_addr
+                                               + LBA_LMMIO_MASK);

Quoted 25 lines

From: Thomas Bogendoerfer <[email protected]>

The LMMIO length reported by PAT and the length given by the LBA MASK register are not consistent. This leads e.g. to a non-working ATI FireGL card with the radeon DRM driver since the memory can't be mapped.

Fix this by correctly adjusting the resource sizes.

Signed-off-by Helge Deller <[email protected]>

drivers/parisc/lba_pci.c +7 -0

index 1f05913..7dc0e40 100644
@@ -994,6 +994,15 @@ lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
                case PAT_LMMIO:
                        /* used to fix up pre-initialized MEM BARs */
                        if (!lba_dev->hba.lmmio_space.flags) {
+                               unsigned long lba_len;
+                               lba_len = ~READ_REG32(lba_dev->hba.base_addr
+                                               + LBA_LMMIO_MASK);
+                               if ((p->end - p->start) != lba_len) {
+                                       pr_warn("PCI%02x LMMIO mismatch between PAT length (0x%lx) and MASK register (0x%lx), fixing.\n",
+                                         (int)lba_dev->hba.bus_num.start,
+                                               p->end - p->start, lba_len);

drivers/parisc/lba_pci.c lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)

Quoted 6 lines

drivers/parisc/lba_pci.c +2 -1

+                                       p->end = p->start + lba_len;
+                               }
                                sprintf(lba_dev->hba.lmmio_name,
                                                "PCI%02x LMMIO",
                                                (int)lba_dev->hba.bus_num.start);
--

With these two patches, does kernel modesetting (and X11?) work?

PS: Does someone has a C800 with 0x77 serial ports? In that case some small patch to the serial driver is needed to get it detected....

I did not tested X11 yet (still need to fully install the C8000 with our unstable) - but Thomas mentioned once that this is needed for X11.

I did not tested X11 yet (still need to fully install the C8000 with our unstable) - but Thomas mentioned once that this is needed for X11.

I'm using a c8000 with firegl x3. I approve that console works, although in an unaccelerated mode. However xorg isn't:
http://pastebin.com/Y1h2BVHB
The system is latest unstable. The xorg is of 1:7.7+3 version.

It would be useful if you could test if the current case , "mm->context == mfsp(3)" case works.
You would have to move return
and disable non current block.

Suggest you hack arch/parisc/kernel/cache.c to
disable this optimization

The panic on SMP kernel changed to another one:
http://pastebin.com/SfUfd0Un

Quoted 2 lines · Alex Ivanov

The panic on SMP kernel changed to another one:
http://pastebin.com/SfUfd0Un

This is just a guess but I don't think page is valid if the pfn is not valid. You might try this untested change.

flush_cache_mm might have same problem (i.e., we may need to check whether the pfn for the pte is valid).

Quoted 5 lines · John David Anglin

Quoted 2 lines · Alex Ivanov

=9A=9AThe panic on SMP kernel changed to another one:
=9A=9Ahttp://pastebin.com/SfUfd0Un

=9A=9AThis is just a guess but I don't think page is valid =9A=9Aif the pfn is not valid. =9AYou might try this untested change=

Quoted 3 lines

=9A=9Aflush_cache_mm might have same problem (i.e., we may need to =9A=9Acheck whether the pfn for the pte is valid).

=9AThis version compiles and boots on rp3440.

=9ADave
=9A--
=9AJohn David Anglin [email protected]

Sorry for not CC'ing to the list.

10.07.2013, 03:35, "John David Anglin" <[email protected]>:

Quoted 11 lines · John David Anglin

Quoted 8 lines · Alex Ivanov

Quoted 2 lines

The panic on SMP kernel changed to another one:
http://pastebin.com/SfUfd0Un

This is just a guess but I don't think page is valid if the pfn is not valid. You might try this untested change.

flush_cache_mm might have same problem (i.e., we may need to check whether the pfn for the pte is valid).

This version compiles and boots on rp3440.

Quoted 3 lines

Dave
--
John David Anglin [email protected]

Dave,

Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <[email protected]> wro=

Quoted 2 lines

=9AThank you so much! Your guess looks to be right. After applying o=

Quoted 1 line

=9Apatch there was no more KP and X just worked.

Nice! Does DRI work?

Quoted 6 lines · Alex Ivanov

11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 5 lines · Alex Ivanov

Quoted 3 lines

Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

Quoted 6 lines

Quoted 1 line

Nice! Does DRI work?

Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log.
As for DRI, i'm experiencing
"ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

FWIW, I'm seeing the same failure on my FireGL X1:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)

[drm] radeon: irq initialized.
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000060001000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:80:00.0: failed initializing CP (-22).
radeon 0000:80:00.0: Disabling GPU acceleration
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized
[drm] radeon: cp finalized

I haven't tested X11 yet.

Quoted 3 lines

Can't figure out why, the ring vaddr (0x0000000060001000) is within the limits of dma32. But the ring test fails. And i'm afraid that just adding a buffer bounces in places will not help.

Helge

adding linux parisc mailing list...:

Quoted 3 lines · Helge Deller

Quoted 2 lines · Alex Ivanov

=9A11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 1 line

=9AOn Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <[email protected]=

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

=9A=9AThank you so much! Your guess looks to be right. After appl=

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

Quoted 1 line

=9A=9Apatch there was no more KP and X just worked.

=9ANice! Does DRI work?

=9ANot on my side. Plus i can't visually jump over 8bit depth, alth=

Quoted 3 lines

Quoted 3 lines

=9Astates 24bit in it's log.
=9AAs for DRI, i'm experiencing
=9A"ring test failed (scratch(0x15E4)=3D0xCAFEDEAD)" with a firegl =

Quoted 2 lines

=9AFWIW, I'm seeing the same failure on my FireGL X1:
=9A80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] n=

Quoted 5 lines

=9A[drm] radeon: irq initialized.
=9A[drm] Loading R300 Microcode
=9A[drm] radeon: ring at 0x0000000060001000 =9A[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x=

Quoted 4 lines

=9A[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). =9Aradeon 0000:80:00.0: failed initializing CP (-22). =9Aradeon 0000:80:00.0: Disabling GPU acceleration =9A[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting dow=

Quoted 2 lines

=9A[drm] radeon: cp finalized
=9A[drm] radeon: cp finalized

11.07.2013, 23:48, "Helge Deller" <[email protected]>:

Quoted 33 lines

adding linux parisc mailing list...:

Quoted 29 lines · Helge Deller

Quoted 6 lines · Alex Ivanov

11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 5 lines

Quoted 3 lines · Alex Ivanov

Thank you so much! Your guess looks to be right. After
applying of your
patch there was no more KP and X just worked.

Quoted 6 lines

Quoted 1 line

Nice! Does DRI work?

Not on my side. Plus i can't visually jump over 8bit depth,
although Xorg
states 24bit in it's log.
As for DRI, i'm experiencing
"ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

FWIW, I'm seeing the same failure on my FireGL X1:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD]
nee ATI Radeon R300 NG [FireGL X1] (rev 80)

[drm] radeon: irq initialized.
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000060001000 [drm:r100_ring_test] *ERROR* radeon: ring test failed
(scratch(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). radeon 0000:80:00.0: failed initializing CP (-22). radeon 0000:80:00.0: Disabling GPU acceleration [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting
down CP.
[drm] radeon: cp finalized
[drm] radeon: cp finalized

I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives?

I wonder if there is a endian issue in the microcode load.

11.07.2013, 23:48, "Helge Deller" <[email protected]>:

Quoted 33 lines

adding linux parisc mailing list...:

Quoted 29 lines · Helge Deller

Quoted 6 lines · Alex Ivanov

11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 5 lines

Quoted 3 lines · Alex Ivanov

Thank you so much! Your guess looks to be right. After
applying of your
patch there was no more KP and X just worked.

Quoted 6 lines

Quoted 1 line

Nice! Does DRI work?

Not on my side. Plus i can't visually jump over 8bit depth,
although Xorg
states 24bit in it's log.
As for DRI, i'm experiencing
"ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

FWIW, I'm seeing the same failure on my FireGL X1:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD]
nee ATI Radeon R300 NG [FireGL X1] (rev 80)

[drm] radeon: irq initialized.
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000060001000 [drm:r100_ring_test] *ERROR* radeon: ring test failed
(scratch(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). radeon 0000:80:00.0: failed initializing CP (-22). radeon 0000:80:00.0: Disabling GPU acceleration [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting
down CP.
[drm] radeon: cp finalized
[drm] radeon: cp finalized

 adding linux parisc mailing list...:

Quoted 23 lines · Helge Deller

Quoted 9 lines · Alex Ivanov

  11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 4 lines · Alex Ivanov

Quoted 2 lines

   Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

  Nice! Does DRI work?

  Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log.
  As for DRI, i'm experiencing
  "ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

  FWIW, I'm seeing the same failure on my FireGL X1:
  80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)

  [drm] radeon: irq initialized.
  [drm] Loading R300 Microcode
  [drm] radeon: ring at 0x0000000060001000
  [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
  radeon 0000:80:00.0: failed initializing CP (-22).
  radeon 0000:80:00.0: Disabling GPU acceleration
  [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized
  [drm] radeon: cp finalized

Folks,

We (people at linux-parisc @ vger.kernel.org mail list) are trying to make native video options of the latest PA-RISC servers and workstations (these are ATIs, most of which are based on R100/R300/R420 chips) work correctly on this platform (big endian pa-risc).

However, we hadn't much success. DRM fails every time with "ring test failed" for both AGP & PCI.

Maybe you would give us some suggestions that we could check?

Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html

Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
"parisc AGP GART code writes IOMMU entries in the wrong byte order and
doesn't add the coherency information SBA code adds"
"our PCI BAR setup doesn't really work very well together with the Radeon
DRM address setup. DRM will generate addresses, which are even outside of the connected LBA"

Things planned for a check:
"The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture."

"The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee
that data written by the CPU to memory is actually in a readable state before the Graphics Controller receives an
update to its copy of the Write Pointer. In an effort to alleviate this problem, we"ve introduced a mechanism into the
Graphics Controller that will delay the actual write to the Write Pointer for some programmable amount of time, in
order to give the chipset time to flush its internal write buffers to memory.
There are two register fields that control this mechanism:
PRE_WRITE_TIMER and PRE_WRITE_LIMIT.

In the radeon DRM codebase I didn't found anyone using/setting those registers. Maybe PA-RISC has some problem here?..."

Thanks.

-------- Пересылаемое сообщение -------- 04.08.2013, 15:06, "Alex Ivanov" <[email protected]>:

11.07.2013, 23:48, "Helge Deller" <[email protected]>:

Quoted 26 lines

adding linux parisc mailing list...:

Quoted 23 lines · Helge Deller

Quoted 9 lines · Alex Ivanov

11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 4 lines · Alex Ivanov

Quoted 2 lines

Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

Nice! Does DRI work?

Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log.
As for DRI, i'm experiencing
"ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

FWIW, I'm seeing the same failure on my FireGL X1:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)

[drm] radeon: irq initialized.
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000060001000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:80:00.0: failed initializing CP (-22).
radeon 0000:80:00.0: Disabling GPU acceleration
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized
[drm] radeon: cp finalized

I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives? Should we forward this to dri-devel mail list?
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-------- Завершение пересылаемого сообщения --------
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 26 lines

Folks,

We (people at linux-parisc @ vger.kernel.org mail list) are trying to make native video options of the latest PA-RISC servers and workstations (these are ATIs, most of which are based on R100/R300/R420 chips) work correctly on this platform (big endian pa-risc).

However, we hadn't much success. DRM fails every time with "ring test failed" for both AGP & PCI.

Maybe you would give us some suggestions that we could check?

Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html

Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
"parisc AGP GART code writes IOMMU entries in the wrong byte order and doesn't add the coherency information SBA code adds"
"our PCI BAR setup doesn't really work very well together with the Radeon DRM address setup. DRM will generate addresses, which are even outside of the connected LBA"

Quoted 4 lines

Things planned for a check:
"The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture."

I don't think that will any difference. radeon kms works fine on other big endian platforms such as powerpc.

Quoted 15 lines

"The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee
that data written by the CPU to memory is actually in a readable state before the Graphics Controller receives an
update to its copy of the Write Pointer. In an effort to alleviate this problem, we"ve introduced a mechanism into the
Graphics Controller that will delay the actual write to the Write Pointer for some programmable amount of time, in
order to give the chipset time to flush its internal write buffers to memory.
There are two register fields that control this mechanism:
PRE_WRITE_TIMER and PRE_WRITE_LIMIT.

Quoted 2 lines

In the radeon DRM codebase I didn't found anyone using/setting those registers. Maybe PA-RISC has some problem here?..."

I doubt it. If you are using AGP, I'd suggest disabling it and first try to get things working using the on chip gart rather than AGP. Load radeon with agpmode=-1.

The on chip gart always uses cache
snooped pci transactions and the driver assumes pci is cache coherent. On AGP/PCI chips, the on-chip gart mechanism stores the gart table in system ram. On PCIE asics, the gart table is stored in vram. The

gart page table maps system pages to a contiguous aperture in the GPU's address space. The ring lives in gart memory. The GPU sees a contiguous buffer and the gart mechanism handles the access to the backing pages via the page table. I'd suggest verifying that the entries written to the gart page table are valid and then the information written to the ring buffer is valid before updating the ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what causes the CP to start fetching data from the ring.

Alex

Quoted 46 lines

Thanks.

-------- Пересылаемое сообщение -------- 04.08.2013, 15:06, "Alex Ivanov" <[email protected]>:

11.07.2013, 23:48, "Helge Deller" <[email protected]>:

Quoted 26 lines

adding linux parisc mailing list...:

Quoted 23 lines · Helge Deller

Quoted 9 lines · Alex Ivanov

11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 4 lines · Alex Ivanov

Quoted 2 lines

Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

Nice! Does DRI work?

Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log.
As for DRI, i'm experiencing
"ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

FWIW, I'm seeing the same failure on my FireGL X1:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)

[drm] radeon: irq initialized.
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000060001000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:80:00.0: failed initializing CP (-22).
radeon 0000:80:00.0: Disabling GPU acceleration
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized
[drm] radeon: cp finalized

I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives? Should we forward this to dri-devel mail list?
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-------- Завершение пересылаемого сообщения --------
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Alex,

09.09.2013, в 21:43, Alex Deucher <[email protected]> написал(а):

Quoted 27 lines · Alex Ivanov

Quoted 26 lines

Folks,

We (people at linux-parisc @ vger.kernel.org mail list) are trying to make native video options of the latest PA-RISC servers and workstations (these are ATIs, most of which are based on R100/R300/R420 chips) work correctly on this platform (big endian pa-risc).

However, we hadn't much success. DRM fails every time with "ring test failed" for both AGP & PCI.

Maybe you would give us some suggestions that we could check?

Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html

Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
"parisc AGP GART code writes IOMMU entries in the wrong byte order and doesn't add the coherency information SBA code adds"
"our PCI BAR setup doesn't really work very well together with the Radeon DRM address setup. DRM will generate addresses, which are even outside of the connected LBA"

Quoted 7 lines

Quoted 4 lines

Things planned for a check:
"The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture."

I don't think that will any difference. radeon kms works fine on other big endian platforms such as powerpc.

Good! I'll opt it out then.

Quoted 15 lines

Quoted 15 lines

"The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee
that data written by the CPU to memory is actually in a readable state before the Graphics Controller receives an
update to its copy of the Write Pointer. In an effort to alleviate this problem, we"ve introduced a mechanism into the
Graphics Controller that will delay the actual write to the Write Pointer for some programmable amount of time, in
order to give the chipset time to flush its internal write buffers to memory.
There are two register fields that control this mechanism:
PRE_WRITE_TIMER and PRE_WRITE_LIMIT.

Quoted 6 lines

Quoted 2 lines

In the radeon DRM codebase I didn't found anyone using/setting those registers. Maybe PA-RISC has some problem here?..."

I doubt it. If you are using AGP, I'd suggest disabling it and first try to get things working using the on chip gart rather than AGP. Load radeon with agpmode=-1.

Already tried this without any luck. Anyway, a radeon driver fallbacks to the PCI mode in our case, so does it really matter?

In addition, people with PCI cards experiencing the same issue...

Quoted 4 lines

The on chip gart always uses cache
snooped pci transactions and the driver assumes pci is cache coherent. On AGP/PCI chips, the on-chip gart mechanism stores the gart table in system ram. On PCIE asics, the gart table is stored in vram. The

Quoted 8 lines

gart page table maps system pages to a contiguous aperture in the GPU's address space. The ring lives in gart memory. The GPU sees a contiguous buffer and the gart mechanism handles the access to the backing pages via the page table. I'd suggest verifying that the entries written to the gart page table are valid and then the information written to the ring buffer is valid before updating the ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what causes the CP to start fetching data from the ring.

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

radeon_device.c 2013-09-10 09:12:17.000000000 +0000 renamed from radeon_device.c.orig 2013-09-10 08:55:05.000000000 +0000 +6 -9

@@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
 {
        if (rdev->dummy_page.page)
                return 0;
-       rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
-       if (rdev->dummy_page.page == NULL)
+       rdev->dummy_page.page = dma_alloc_coherent(&rdev->pdev->dev, PAGE_SIZE,
+               &rdev->dummy_page.addr, GFP_DMA32|GFP_KERNEL);
+       if (!rdev->dummy_page.page)
                return -ENOMEM;
-       rdev->dummy_page.addr = pci_map_page(rdev->pdev, rdev->dummy_page.page,
-                                       0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
        if (pci_dma_mapping_error(rdev->pdev, rdev->dummy_page.addr)) {
                dev_err(&rdev->pdev->dev, "Failed to DMA MAP the dummy page\n");
-               __free_page(rdev->dummy_page.page);
-               rdev->dummy_page.page = NULL;
+               radeon_dummy_page_fini(rdev);
                return -ENOMEM;
        }
        return 0;

@@ -698,9 +696,8 @@ void radeon_dummy_page_fini(struct radeo
 {
        if (rdev->dummy_page.page == NULL)
                return;
-       pci_unmap_page(rdev->pdev, rdev->dummy_page.addr,
-                       PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
-       __free_page(rdev->dummy_page.page);
+       dma_free_coherent(&rdev->pdev->dev, PAGE_SIZE,
+               rdev->dummy_page.page, rdev->dummy_page.addr);
        rdev->dummy_page.page = NULL;
 }
 

Quoted 38 lines

Alex

Quoted 35 lines

Thanks.

-------- Пересылаемое сообщение -------- 04.08.2013, 15:06, "Alex Ivanov" <[email protected]>:

11.07.2013, 23:48, "Helge Deller" <[email protected]>:

Quoted 26 lines

adding linux parisc mailing list...:

Quoted 23 lines · Helge Deller

Quoted 9 lines · Alex Ivanov

11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 4 lines · Alex Ivanov

Quoted 2 lines

Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

Nice! Does DRI work?

Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log.
As for DRI, i'm experiencing
"ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

FWIW, I'm seeing the same failure on my FireGL X1:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)

[drm] radeon: irq initialized.
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000060001000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:80:00.0: failed initializing CP (-22).
radeon 0000:80:00.0: Disabling GPU acceleration
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized
[drm] radeon: cp finalized

Quoted 11 lines

Quoted 11 lines

I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives? Should we forward this to dri-devel mail list?
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-------- Завершение пересылаемого сообщения --------
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 36 lines · Alex Ivanov

Alex,

09.09.2013, в 21:43, Alex Deucher <[email protected]> написал(а):

Quoted 32 lines · Alex Ivanov

Quoted 30 lines

Folks,

We (people at linux-parisc @ vger.kernel.org mail list) are trying to make native video options of the latest PA-RISC servers and workstations (these are ATIs, most of which are based on R100/R300/R420 chips) work correctly on this platform (big endian pa-risc).

However, we hadn't much success. DRM fails every time with "ring test failed" for both AGP & PCI.

Maybe you would give us some suggestions that we could check?

Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html

Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
"parisc AGP GART code writes IOMMU entries in the wrong byte order and doesn't add the coherency information SBA code adds"
"our PCI BAR setup doesn't really work very well together with the Radeon DRM address setup. DRM will generate addresses, which are even outside of the connected LBA"

Things planned for a check:
"The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture."

Quoted 4 lines

Quoted 2 lines

I don't think that will any difference. radeon kms works fine on other big endian platforms such as powerpc.

Good! I'll opt it out then.

Alex,

09.09.2013, в 21:43, Alex Deucher <[email protected]> написал(а):

Quoted 27 lines · Alex Ivanov

Quoted 26 lines

Folks,

We (people at linux-parisc @ vger.kernel.org mail list) are trying to make native video options of the latest PA-RISC servers and workstations (these are ATIs, most of which are based on R100/R300/R420 chips) work correctly on this platform (big endian pa-risc).

However, we hadn't much success. DRM fails every time with "ring test failed" for both AGP & PCI.

Maybe you would give us some suggestions that we could check?

Topic started here:
http://www.spinics.net/lists/linux-parisc/msg04908.html
And continued there:
http://www.spinics.net/lists/linux-parisc/msg04995.html
http://www.spinics.net/lists/linux-parisc/msg05006.html

Problems we've already resolved without any signs of progress:
- Checked the successful microcode load
"parisc AGP GART code writes IOMMU entries in the wrong byte order and doesn't add the coherency information SBA code adds"
"our PCI BAR setup doesn't really work very well together with the Radeon DRM address setup. DRM will generate addresses, which are even outside of the connected LBA"

Quoted 7 lines

Quoted 4 lines

Things planned for a check:
"The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture."

I don't think that will any difference. radeon kms works fine on other big endian platforms such as powerpc.

Good! I'll opt it out then.

Quoted 15 lines

Quoted 15 lines

"The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee
that data written by the CPU to memory is actually in a readable state before the Graphics Controller receives an
update to its copy of the Write Pointer. In an effort to alleviate this problem, we"ve introduced a mechanism into the
Graphics Controller that will delay the actual write to the Write Pointer for some programmable amount of time, in
order to give the chipset time to flush its internal write buffers to memory.
There are two register fields that control this mechanism:
PRE_WRITE_TIMER and PRE_WRITE_LIMIT.

Quoted 6 lines

Quoted 2 lines

In the radeon DRM codebase I didn't found anyone using/setting those registers. Maybe PA-RISC has some problem here?..."

I doubt it. If you are using AGP, I'd suggest disabling it and first try to get things working using the on chip gart rather than AGP. Load radeon with agpmode=-1.

Already tried this without any luck. Anyway, a radeon driver fallbacks to the PCI mode in our case, so does it really matter?

In addition, people with PCI cards experiencing the same issue...

Quoted 4 lines

The on chip gart always uses cache
snooped pci transactions and the driver assumes pci is cache coherent. On AGP/PCI chips, the on-chip gart mechanism stores the gart table in system ram. On PCIE asics, the gart table is stored in vram. The

Quoted 8 lines

gart page table maps system pages to a contiguous aperture in the GPU's address space. The ring lives in gart memory. The GPU sees a contiguous buffer and the gart mechanism handles the access to the backing pages via the page table. I'd suggest verifying that the entries written to the gart page table are valid and then the information written to the ring buffer is valid before updating the ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what causes the CP to start fetching data from the ring.

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

radeon_device.c renamed from radeon_device.c.orig +6 -9

@@ -673,15 +673,13 @@ int radeon_dummy_page_init(struct radeon
 {
 	if (rdev->dummy_page.page)
 		return 0;
-	rdev->dummy_page.page = alloc_page(GFP_DMA32 | GFP_KERNEL | __GFP_ZERO);
-	if (rdev->dummy_page.page == NULL)
+	rdev->dummy_page.page = dma_alloc_coherent(&rdev->pdev->dev, PAGE_SIZE,
+		&rdev->dummy_page.addr, GFP_DMA32|GFP_KERNEL);
+	if (!rdev->dummy_page.page)
 		return -ENOMEM;
-	rdev->dummy_page.addr = pci_map_page(rdev->pdev, rdev->dummy_page.page,
-					0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
 	if (pci_dma_mapping_error(rdev->pdev, rdev->dummy_page.addr)) {
 		dev_err(&rdev->pdev->dev, "Failed to DMA MAP the dummy page\n");
-		__free_page(rdev->dummy_page.page);
-		rdev->dummy_page.page = NULL;
+		radeon_dummy_page_fini(rdev);
 		return -ENOMEM;
 	}
 	return 0;

@@ -698,9 +696,8 @@ void radeon_dummy_page_fini(struct radeo
 {
 	if (rdev->dummy_page.page == NULL)
 		return;
-	pci_unmap_page(rdev->pdev, rdev->dummy_page.addr,
-			PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
-	__free_page(rdev->dummy_page.page);
+	dma_free_coherent(&rdev->pdev->dev, PAGE_SIZE,
+		rdev->dummy_page.page, rdev->dummy_page.addr);
 	rdev->dummy_page.page = NULL;
 }
 

Quoted 49 lines

Alex

Quoted 46 lines

Thanks.

-------- Пересылаемое сообщение -------- 04.08.2013, 15:06, "Alex Ivanov" <[email protected]>:

11.07.2013, 23:48, "Helge Deller" <[email protected]>:

Quoted 26 lines

adding linux parisc mailing list...:

Quoted 23 lines · Helge Deller

Quoted 9 lines · Alex Ivanov

11.07.2013, 01:14, "Matt Turner" <[email protected]>:

Quoted 4 lines · Alex Ivanov

Quoted 2 lines

Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked.

Nice! Does DRI work?

Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log.
As for DRI, i'm experiencing
"ring test failed (scratch(0x15E4)=0xCAFEDEAD)" with a firegl x3.

FWIW, I'm seeing the same failure on my FireGL X1:
80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80)

[drm] radeon: irq initialized.
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000060001000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:80:00.0: failed initializing CP (-22).
radeon 0000:80:00.0: Disabling GPU acceleration
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized
[drm] radeon: cp finalized

I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives? Should we forward this to dri-devel mail list?
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-------- Завершение пересылаемого сообщения --------
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

=EF=D4: Konrad Rzeszutek Wilk <[email protected]> =F4=C5=CD=C1: =EF=D4=D7=C5=D4: drm/radeon: "ring test failed" on PA-R=

=E4=C1=D4=C1: 10 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:25:29 GMT+04:=

=EB=CF=CD=D5: Alex Ivanov <[email protected]> =EB=CF=D0=C9=D1: Alex Deucher <[email protected]>, Maling list - =

=20

Quoted 3 lines · Alex Ivanov

=20
Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

=20
Is this platform enabling the SWIOTLB layer? The reason I am asking i=

b/c if you do indeed enable it you end up using the TTM DMA pool which allocates pages using the dma_alloc_coherent - which means that all of the pages that come out of TTM are already 'DMA' mapped. =20
And that means the radeon_gart_bind and all its friends=20 use the DMA addresses that have been constructed by SWIOTLB IOMMU. =20
Perhaps the PA-RISC IOMMU creates the DMA addresses differently? =20
When the card gets programmed, you do end up using ttm_agp_bind right=

I am wondering if something like this:
=20
https://lkml.org/lkml/2010/12/6/512
=20
is needed to pass in the right DMA address?

What I'm still wondering is whether radeon DRM really works on 64bit big endian boxes.
Is it running on any big endian boxes ?

Is there any prove, that someone has it running ?

Mates, let's continue with this issue at [email protected].=

Here's where we stopped:

--[start]--

Quoted 2 lines

=9A=EF=D4: Konrad Rzeszutek Wilk <[email protected]> =9A=F4=C5=CD=C1: =EF=D4=D7=C5=D4: drm/radeon: "ring test failed" on =

Quoted 1 line

=9A=E4=C1=D4=C1: 10 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:25:29 GMT=

Quoted 2 lines

=9A=EB=CF=CD=D5: Alex Ivanov <[email protected]> =9A=EB=CF=D0=C9=D1: Alex Deucher <[email protected]>, Maling lis=

Quoted 3 lines

Quoted 1 line · Alex Ivanov

=9AThanks! I'll try. Meanwhile i've tried a switch from page_alloc(=

Quoted 1 line

Quoted 1 line

=9Adma_alloc_coherent() in radeon_dummy_page_*(), which didn't help=

Quoted 1 line

=9AIs this platform enabling the SWIOTLB layer? The reason I am aski=

Quoted 2 lines

=9Ab/c if you do indeed enable it you end up using the TTM DMA pool =9Awhich allocates pages using the dma_alloc_coherent - which means =

Quoted 4 lines

=9Aall of the pages that come out of TTM are already 'DMA' mapped.

=9AAnd that means the radeon_gart_bind and all its friends =9Ause the DMA addresses that have been constructed by SWIOTLB IOMMU=

Quoted 4 lines

=9APerhaps the PA-RISC IOMMU creates the DMA addresses differently?

=9AWhen the card gets programmed, you do end up using ttm_agp_bind r=

Quoted 5 lines

=9AI am wondering if something like this:

=9Ahttps://lkml.org/lkml/2010/12/6/512

=9Ais needed to pass in the right DMA address?

--[end]--

Thomas,

Quoted 1 line

=9AWhat I'm still wondering is whether radeon DRM really works on 64=

Quoted 2 lines

=9Abig endian boxes.
=9AIs it running on any big endian boxes ?

It's running ok at least on 32-bit big-endian PowerPCs and on 64-bit big-endian PowerPC G5 machines.

Quoted 1 line

=9AIs there any prove, that someone has it running ?

Here they are:
https://groups.google.com/d/msg/linux.kernel/BnAMrzyO2wg/W-R5UVh_VLIJ
And here's an excerpt from this one:
http://lists.freedesktop.org/archives/dri-devel/2013-September/045029=

"I don't think that will any difference. =9Aradeon kms works fine on other big endian platforms such as powerpc."
--
To unsubscribe from this list: send the line "unsubscribe linux-paris=

the body of a message to [email protected]
More majordomo info at =9Ahttp://vger.kernel.org/majordomo-info.html

The dummy page isn't really going to help much. That page is just used as a safety placeholder for gart entries that aren't mapped on the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of the backing pages for the gart.

You may want to look there.

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

Is this platform enabling the SWIOTLB layer?

The reason I am asking is
b/c if you do indeed enable it you end up using the TTM DMA pool which allocates pages using the dma_alloc_coherent - which means that all of the pages that come out of TTM are already 'DMA' mapped.

And that means the radeon_gart_bind and all its friends use the DMA addresses that have been constructed by SWIOTLB IOMMU.

Perhaps the PA-RISC IOMMU creates the DMA addresses differently?

When the card gets programmed, you do end up using ttm_agp_bind right? I am wondering if something like this:

https://lkml.org/lkml/2010/12/6/512

is needed to pass in the right DMA address?

Alex,

10.09.2013, в 16:37, Alex Deucher <[email protected]> написал(а):

Quoted 6 lines

The dummy page isn't really going to help much. That page is just used as a safety placeholder for gart entries that aren't mapped on the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of the backing pages for the gart.

You may want to look there.

Ah, sorry. Indeed. Though, my idea with:

Quoted 2 lines · Alex Ivanov

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

doesn't make a sense at TTM part as well.

Konrad,

10.09.2013, 17:25, "Konrad Rzeszutek Wilk" <[email protected]>:

Quoted 2 lines

Is this platform enabling the SWIOTLB layer?

Doesn't look like.

Quoted 13 lines

The reason I am asking is
b/c if you do indeed enable it you end up using the TTM DMA pool which allocates pages using the dma_alloc_coherent - which means that all of the pages that come out of TTM are already 'DMA' mapped.

And that means the radeon_gart_bind and all its friends use the DMA addresses that have been constructed by SWIOTLB IOMMU.

Perhaps the PA-RISC IOMMU creates the DMA addresses differently?

When the card gets programmed, you do end up using ttm_agp_bind right? I am wondering if something like this:

Quoted 3 lines

https://lkml.org/lkml/2010/12/6/512

is needed to pass in the right DMA address?

No idea how to modify ttm_agp_bind() this way, though doesn't matter if swiotlb isn't used anyway?

Quoted 11 lines

Alex,

10.09.2013, в 16:37, Alex Deucher <[email protected]> написал(а):

Quoted 6 lines

The dummy page isn't really going to help much. That page is just used as a safety placeholder for gart entries that aren't mapped on the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of the backing pages for the gart.

You may want to look there.

Quoted 8 lines

Ah, sorry. Indeed. Though, my idea with:

Quoted 2 lines · Alex Ivanov

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

doesn't make a sense at TTM part as well.

After the driver is loaded, you can dump some info from debugfs:
r100_rbbm_info
r100_cp_ring_info
r100_cp_csq_fifo
Which will dump a bunch of registers and internal fifos so we can see that the chip actually processed.

Alex

17.09.2013, в 18:24, Alex Deucher <[email protected]> написал(а):

Quoted 21 lines · Alex Ivanov

Quoted 11 lines

Alex,

10.09.2013, в 16:37, Alex Deucher <[email protected]> написал(а):

Quoted 6 lines

The dummy page isn't really going to help much. That page is just used as a safety placeholder for gart entries that aren't mapped on the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of the backing pages for the gart.

You may want to look there.

Quoted 8 lines

Ah, sorry. Indeed. Though, my idea with:

Quoted 2 lines · Alex Ivanov

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

doesn't make a sense at TTM part as well.

Quoted 8 lines

After the driver is loaded, you can dump some info from debugfs:
r100_rbbm_info
r100_cp_ring_info
r100_cp_csq_fifo
Which will dump a bunch of registers and internal fifos so we can see that the chip actually processed.

Alex

Reading of r100_cp_ring_info leads to a KP:

r100_debugfs_cp_ring_info():
count = (rdp + ring->ring_size - wdp) & ring->ptr_mask; i = (rdp + j) & ring->ptr_mask;

       for (j = 0; j <= count; j++) {
               i = (rdp + j) & ring->ptr_mask;
		--> Here at first iteration <--
		--> count = 262080, i = 0 <--
               seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
       }

Reading of radeon_ring_gfx (which i've additionally tried to read) throws an MCE:

radeon_debugfs_ring_info():
count = (ring->ring_size / 4) - ring->ring_free_dw; i = (ring->rptr + ring->ptr_mask + 1 - 32) & ring->ptr_mask;

       for (j = 0; j <= (count + 32); j++) {
		--> Here at first iteration <--
		--> count = 64, i = 262112 <--
               seq_printf(m, "r[%5d]=0x%08x\n", i, ring->ring[i]);
               i = (i + 1) & ring->ptr_mask;
       }

I'm attaching debug outputs on kernel built with these loops commented. <drm_parisc_debug.tgz>_______________________________________________ dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

17.09.2013, в 18:24, Alex Deucher <[email protected]> написал(а):

Quoted 21 lines · Alex Ivanov

Quoted 11 lines

Alex,

10.09.2013, в 16:37, Alex Deucher <[email protected]> написал(а):

Quoted 6 lines

The dummy page isn't really going to help much. That page is just used as a safety placeholder for gart entries that aren't mapped on the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of the backing pages for the gart.

You may want to look there.

Quoted 8 lines

Ah, sorry. Indeed. Though, my idea with:

Quoted 2 lines · Alex Ivanov

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

doesn't make a sense at TTM part as well.

Quoted 8 lines

After the driver is loaded, you can dump some info from debugfs:
r100_rbbm_info
r100_cp_ring_info
r100_cp_csq_fifo
Which will dump a bunch of registers and internal fifos so we can see that the chip actually processed.

Alex

Reading of r100_cp_ring_info leads to a KP:

r100_debugfs_cp_ring_info():
count = (rdp + ring->ring_size - wdp) & ring->ptr_mask; i = (rdp + j) & ring->ptr_mask;

        for (j = 0; j <= count; j++) {
                i = (rdp + j) & ring->ptr_mask;
                --> Here at first iteration <--
                --> count = 262080, i = 0 <--
                seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
        }

Reading of radeon_ring_gfx (which i've additionally tried to read) throws an MCE:

radeon_debugfs_ring_info():
count = (ring->ring_size / 4) - ring->ring_free_dw; i = (ring->rptr + ring->ptr_mask + 1 - 32) & ring->ptr_mask;

        for (j = 0; j <= (count + 32); j++) {
                --> Here at first iteration <--
                --> i = 262112, j = 0 <--
                seq_printf(m, "r[%5d]=0x%08x\n", i, ring->ring[i]);
                i = (i + 1) & ring->ptr_mask;
        }

I'm attaching debug outputs on kernel built with these loops commented.

Quoted 52 lines

17.09.2013, в 18:24, Alex Deucher <[email protected]> написал(а):

Quoted 21 lines · Alex Ivanov

Quoted 11 lines

Alex,

10.09.2013, в 16:37, Alex Deucher <[email protected]> написал(а):

Quoted 6 lines

The dummy page isn't really going to help much. That page is just used as a safety placeholder for gart entries that aren't mapped on the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of the backing pages for the gart.

You may want to look there.

Quoted 8 lines

Ah, sorry. Indeed. Though, my idea with:

Quoted 2 lines · Alex Ivanov

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

doesn't make a sense at TTM part as well.

Quoted 8 lines

After the driver is loaded, you can dump some info from debugfs:
r100_rbbm_info
r100_cp_ring_info
r100_cp_csq_fifo
Which will dump a bunch of registers and internal fifos so we can see that the chip actually processed.

Alex

Reading of r100_cp_ring_info leads to a KP:

r100_debugfs_cp_ring_info():
count = (rdp + ring->ring_size - wdp) & ring->ptr_mask; i = (rdp + j) & ring->ptr_mask;

       for (j = 0; j <= count; j++) {
               i = (rdp + j) & ring->ptr_mask;
               --> Here at first iteration <--
               --> count = 262080, i = 0 <--
               seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
       }

Reading of radeon_ring_gfx (which i've additionally tried to read) throws an MCE:

radeon_debugfs_ring_info():
count = (ring->ring_size / 4) - ring->ring_free_dw; i = (ring->rptr + ring->ptr_mask + 1 - 32) & ring->ptr_mask;

Quoted 8 lines

       for (j = 0; j <= (count + 32); j++) {
               --> Here at first iteration <--
               --> i = 262112, j = 0 <--
               seq_printf(m, "r[%5d]=0x%08x\n", i, ring->ring[i]);
               i = (i + 1) & ring->ptr_mask;
       }

I'm attaching debug outputs on kernel built with these loops commented.

The register writes seems to be going through the register backbone correctly:

[0x00B] 0x15E0=0x00000000
[0x00C] 0x15E4=0xCAFEDEAD
[0x00D] 0x4274=0x0000000F
[0x00E] 0x42C8=0x00000007
[0x00F] 0x4018=0x0000001D
[0x010] 0x170C=0x80000000
[0x011] 0x3428=0x00020100
[0x012] 0x15E4=0xCAFEDEAD

You can see the 0xCAFEDEAD written to the scratch register via MMIO from the ring_test(). The CP fifo however seems to be full of garbage. The CP is busy though, so it seems to be functional. I guess it's just fetching garbage rather than commands.

Does doing a posted write when writing to the ring buffer help?

drivers/gpu/drm/radeon/radeon_ring.c +0 -0

index a890756..b4f04d2 100644
@@ -324,12 +324,14 @@ static int radeon_debugfs_ring_init(struct

radeon_device *rdev, struct radeon_ri
*/
void radeon_ring_write(struct radeon_ring *ring, uint32_t v) {
+ u32 tmp;
#if DRM_DEBUG_CODE
if (ring->count_dw <= 0) {
DRM_ERROR("radeon: writing more dwords to the ring

than expected!\n");
       }
#endif
       ring->ring[ring->wptr++] = v;
+       tmp = ring->ring[ring->wptr - 1];
       ring->wptr &= ring->ptr_mask;
       ring->count_dw--;
       ring->ring_free_dw--;

21.09.2013, в 1:27, Alex Deucher <[email protected]> написал(а):

Quoted 77 lines · Alex Ivanov

Quoted 52 lines

17.09.2013, в 18:24, Alex Deucher <[email protected]> написал(а):

Quoted 21 lines · Alex Ivanov

Quoted 11 lines

Alex,

10.09.2013, в 16:37, Alex Deucher <[email protected]> написал(а):

Quoted 6 lines

The dummy page isn't really going to help much. That page is just used as a safety placeholder for gart entries that aren't mapped on the GPU. TTM (drivers/gpu/drm/ttm) actually does the allocation of the backing pages for the gart.

You may want to look there.

Quoted 8 lines

Ah, sorry. Indeed. Though, my idea with:

Quoted 2 lines · Alex Ivanov

Thanks! I'll try. Meanwhile i've tried a switch from page_alloc() to dma_alloc_coherent() in radeon_dummy_page_*(), which didn't help :(

doesn't make a sense at TTM part as well.

Quoted 8 lines

After the driver is loaded, you can dump some info from debugfs:
r100_rbbm_info
r100_cp_ring_info
r100_cp_csq_fifo
Which will dump a bunch of registers and internal fifos so we can see that the chip actually processed.

Alex

Reading of r100_cp_ring_info leads to a KP:

r100_debugfs_cp_ring_info():
count = (rdp + ring->ring_size - wdp) & ring->ptr_mask; i = (rdp + j) & ring->ptr_mask;

       for (j = 0; j <= count; j++) {
               i = (rdp + j) & ring->ptr_mask;
               --> Here at first iteration <--
               --> count = 262080, i = 0 <--
               seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
       }

Reading of radeon_ring_gfx (which i've additionally tried to read) throws an MCE:

radeon_debugfs_ring_info():
count = (ring->ring_size / 4) - ring->ring_free_dw; i = (ring->rptr + ring->ptr_mask + 1 - 32) & ring->ptr_mask;

Quoted 8 lines

       for (j = 0; j <= (count + 32); j++) {
               --> Here at first iteration <--
               --> i = 262112, j = 0 <--
               seq_printf(m, "r[%5d]=0x%08x\n", i, ring->ring[i]);
               i = (i + 1) & ring->ptr_mask;
       }

I'm attaching debug outputs on kernel built with these loops commented.

The register writes seems to be going through the register backbone correctly:

[0x00B] 0x15E0=0x00000000
[0x00C] 0x15E4=0xCAFEDEAD
[0x00D] 0x4274=0x0000000F
[0x00E] 0x42C8=0x00000007
[0x00F] 0x4018=0x0000001D
[0x010] 0x170C=0x80000000
[0x011] 0x3428=0x00020100
[0x012] 0x15E4=0xCAFEDEAD

You can see the 0xCAFEDEAD written to the scratch register via MMIO from the ring_test(). The CP fifo however seems to be full of garbage. The CP is busy though, so it seems to be functional. I guess it's just fetching garbage rather than commands.

Quoted 2 lines

Does doing a posted write when writing to the ring buffer help?

Unfortunately, no.

Quoted 20 lines

drivers/gpu/drm/radeon/radeon_ring.c +0 -0

index a890756..b4f04d2 100644
@@ -324,12 +324,14 @@ static int radeon_debugfs_ring_init(struct

radeon_device *rdev, struct radeon_ri
*/
void radeon_ring_write(struct radeon_ring *ring, uint32_t v) {
+ u32 tmp;
#if DRM_DEBUG_CODE
if (ring->count_dw <= 0) {
DRM_ERROR("radeon: writing more dwords to the ring

than expected!\n");
       }
#endif
       ring->ring[ring->wptr++] = v;

+ tmp = ring->ring[ring->wptr - 1];

Quoted 3 lines

       ring->wptr &= ring->ptr_mask;
       ring->count_dw--;
       ring->ring_free_dw--;

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 17 lines

 21.09.2013, в 1:27, Alex Deucher <[email protected]> написал(а):

Quoted 15 lines

 The register writes seems to be going through the register backbone correctly:

 [0x00B] 0x15E0=0x00000000
 [0x00C] 0x15E4=0xCAFEDEAD
 [0x00D] 0x4274=0x0000000F
 [0x00E] 0x42C8=0x00000007
 [0x00F] 0x4018=0x0000001D
 [0x010] 0x170C=0x80000000
 [0x011] 0x3428=0x00020100
 [0x012] 0x15E4=0xCAFEDEAD

 You can see the 0xCAFEDEAD written to the scratch register via MMIO from the ring_test(). The CP fifo however seems to be full of garbage. The CP is busy though, so it seems to be functional.  I guess it's just fetching garbage rather than commands.

If it is fetching garbage, that would imply the DMA (or bus addresses) that are programmed in the GART are bogus. If you dump them and try to figure out if bus adress -> physical address -> virtual address == virtual address -> bus address that could help. And perhaps seeing what the virtual address has - and or poisoning it with known data?

Or perhaps the the card has picked up an incorrect page table? Meaning the (bus) address given to it is not the correct one?

If you dump them and try
to figure out if bus adress -> physical address -> virtual address == virtual address -> bus address that could help

Or perhaps the the card has picked up an incorrect page table? Meaning the (bus) address given to it is not the correct one?

24.09.2013, 00:11, "Konrad Rzeszutek Wilk" <[email protected]>:

Quoted 19 lines · Alex Ivanov

Quoted 17 lines

 21.09.2013, в 1:27, Alex Deucher <[email protected]> написал(а):

Quoted 15 lines

 The register writes seems to be going through the register backbone correctly:

 [0x00B] 0x15E0=0x00000000
 [0x00C] 0x15E4=0xCAFEDEAD
 [0x00D] 0x4274=0x0000000F
 [0x00E] 0x42C8=0x00000007
 [0x00F] 0x4018=0x0000001D
 [0x010] 0x170C=0x80000000
 [0x011] 0x3428=0x00020100
 [0x012] 0x15E4=0xCAFEDEAD

 You can see the 0xCAFEDEAD written to the scratch register via MMIO from the ring_test(). The CP fifo however seems to be full of garbage. The CP is busy though, so it seems to be functional.  I guess it's just fetching garbage rather than commands.

Quoted 9 lines

If it is fetching garbage, that would imply the DMA (or bus addresses) that are programmed in the GART are bogus. If you dump them and try to figure out if bus adress -> physical address -> virtual address == virtual address -> bus address that could help. And perhaps seeing what the virtual address has - and or poisoning it with known data?

Or perhaps the the card has picked up an incorrect page table? Meaning the (bus) address given to it is not the correct one?

Konrad,

Let's see. Please notice that i'm not PA-RISC or general linux kernel developer, just the user, so i may do things completely wrong. I was hoping that PA-RISC smarties will join me here, but they seem to be busy with other duties. Even port's mail list activity is low during last weeks.

Quoted 4 lines

If you dump them and try
to figure out if bus adress -> physical address -> virtual address == virtual address -> bus address that could help

With following

radeon/radeon_ttm.c:

radeon_ttm_tt_populate():
...

for (i = 0; i < ttm->num_pages; i++) {
                gtt->ttm.dma_address[i] = pci_map_page(rdev->pdev, ttm->pages[i],
                                                       0, PAGE_SIZE,
                                                       PCI_DMA_BIDIRECTIONAL);

                void *va = bus_to_virt(gtt->ttm.dma_address[i]);
                if ((phys_addr_t) va != virt_to_bus(va)) {

                     DRM_INFO("MISMATCH: %p != %p\n", va, (void *) virt_to_bus(va));
                     /*DRM_INFO("CONTENTS: %x\n", *((uint32_t *)va));*/ // Leads to a Kernel Fault

                     ...
                }

I'm getting the output:

[drm] MISMATCH: 0000000080280000 != 0000000040280000

Quoted 30 lines · Alex Ivanov

24.09.2013, 00:11, "Konrad Rzeszutek Wilk" <[email protected]>:

Quoted 19 lines · Alex Ivanov

Quoted 17 lines

21.09.2013, в 1:27, Alex Deucher <[email protected]> написал(а):

Quoted 15 lines

The register writes seems to be going through the register backbone correctly:

[0x00B] 0x15E0=0x00000000
[0x00C] 0x15E4=0xCAFEDEAD
[0x00D] 0x4274=0x0000000F
[0x00E] 0x42C8=0x00000007
[0x00F] 0x4018=0x0000001D
[0x010] 0x170C=0x80000000
[0x011] 0x3428=0x00020100
[0x012] 0x15E4=0xCAFEDEAD

You can see the 0xCAFEDEAD written to the scratch register via MMIO from the ring_test(). The CP fifo however seems to be full of garbage. The CP is busy though, so it seems to be functional. I guess it's just fetching garbage rather than commands.

Quoted 9 lines

If it is fetching garbage, that would imply the DMA (or bus addresses) that are programmed in the GART are bogus. If you dump them and try to figure out if bus adress -> physical address -> virtual address == virtual address -> bus address that could help. And perhaps seeing what the virtual address has - and or poisoning it with known data?

Or perhaps the the card has picked up an incorrect page table? Meaning the (bus) address given to it is not the correct one?

Quoted 7 lines

Konrad,

Let's see. Please notice that i'm not PA-RISC or general linux kernel developer, just the user, so i may do things completely wrong. I was hoping that PA-RISC smarties will join me here, but they seem to be busy with other duties. Even port's mail list activity is low during last weeks.

I took a look at the arch/parisc/kernel/pci-dma.c and I see that is mostly a flat platform. That is bus addresses == physical addresses. Unless it is an pclx or pclx2 CPU type (huh?) - if its it that then any calls to dma_alloc_coherent will map memory out of a pool. In essence it will look like a SWIOTLB bounce buffer.

But interestingly enough there is a lot of 'flush_kernel_dcache_range' call for every DMA operation. And I think the you need to do dma_sync_for_cpu call in the radeon_test_writeback for it to use the flush_kernel_dcache_range. I don't know what the flush_kernel_dcache_range does thought so I could be wrong.

That means you can ignore the little code below I wrote and see about doing something like this:

drivers/gpu/drm/radeon/radeon_cp.c +0 -0

index 3cae2bb..9e5923d 100644

But that is probably a shot in the dark. I have no clue what the flush_.. is doing.

[edit: And then I noticed sba_iommu.c, which is a complete IOMMU driver where bus and physical addresses are different. sigh. What type of machine is this? Does it have the IOMMU in it?]

Quoted 11 lines

Quoted 4 lines

If you dump them and try
to figure out if bus adress -> physical address -> virtual address == virtual address -> bus address that could help

With following

radeon/radeon_ttm.c:

radeon_ttm_tt_populate():
...

Quoted 7 lines

for (i = 0; i < ttm->num_pages; i++) {
                gtt->ttm.dma_address[i] = pci_map_page(rdev->pdev, ttm->pages[i],
                                                       0, PAGE_SIZE,
                                                       PCI_DMA_BIDIRECTIONAL);

                void *va = bus_to_virt(gtt->ttm.dma_address[i]);
                if ((phys_addr_t) va != virt_to_bus(va)) {

You are missing a translation here (you were comparing the virtual address to the bus address). I was thinking something along this:

                unsigned int pfn = page_to_pfn(ttm->pages[i]);
                dma_addr_t bus =  gtt->ttm.dma_address[i];
                void *va_bus, *va, *va_pfn;

                if ((pfn << PAGE_SHIFT) != bus)
                        printk("Bus 0x%lx != PFN 0x%lx, bus, pfn << PAGE_SHIFT); /* OK, that means
                        bus addresses are different */

                va_bus = bus_to_virt(gtt->ttm.dma_address[i]);
                va_pfn = __va(pfn << PAGE_SHIFT);

                if (!virt_addr_valid(va_bus))
                        printk("va_bus (0x%lx) not good!\n", va_bus);
                if (!virt_addr_valid(va_pfn))
                        printk("va_pfn (0x%lx) not good!\n", va_pfn);

                /* We got VA for both bus -> va, and pfn -> va. Should be the
                   same if bus and physical addresses are on the same namespace. */
                if (va_bus != va_pfn)
                        printk("va bus:%lx != va pfn: %lx\n", va_bus, va_pfn);

                /* Now that we have bus -> pa -> va (va_bus) try to go va_bus -> bus address.
                   The bus address should be the same */
                if (gtt->tmm.dma_address[i] != virt_to_bus(va_bus))
                        printk("bus->pa->va:%lx != bus->pa->va->ba: %lx\n", gtt->tmm.dma_address[i],virt_to_bus(va_bus));

Quoted 2 lines

                     DRM_INFO("MISMATCH: %p != %p\n", va, (void *) virt_to_bus(va));
                     /*DRM_INFO("CONTENTS: %x\n", *((uint32_t *)va));*/ // Leads to a Kernel Fault

That is odd. I would have thought it would be usuable.

Quoted 6 lines

                     ...
                }

I'm getting the output:

[drm] MISMATCH: 0000000080280000 != 0000000040280000

In theory that means the bus address that is programmed in (gtt->dma_address[i]) is 0000000040280000 (which is what virt_to_bus(va) should have resolved itself to).

Tha you can't get access to 'va' (0000000080280000) is odd. One way to try to access it is to do:

        va = __va(page_to_pfn(ttm->pages[i]) << PAGE_SHIFT);
        DRM_INFO("CONTENTS: %x\n", *((uint32_t)va));

As that would get it via the page -> va.
_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

You'd want to add the add the flush to r100_ring_test() in r100.c. radeon_cp.c is for the old UMS support.

I took a look at the arch/parisc/kernel/pci-dma.c and I see that is mostly a flat platform. That is bus addresses == physical addresses. Unless it is an pclx or pclx2 CPU type (huh?) - if its it that then any calls to dma_alloc_coherent will map memory out of a pool. In essence it will look like a SWIOTLB bounce buffer.

But interestingly enough there is a lot of 'flush_kernel_dcache_range' call for every DMA operation. And I think the you need to do dma_sync_for_cpu call in the radeon_test_writeback for it to use the flush_kernel_dcache_range. I don't know what the flush_kernel_dcache_range does thought so I could be wrong.

That means you can ignore the little code below I wrote and see about doing something like this:

drivers/gpu/drm/radeon/radeon_cp.c +1 -0

index 3cae2bb..9e5923d 100644
@@ -876,6 +876,7 @@ static void radeon_test_writeback(drm_radeon_private_t * dev_priv)
 
          RADEON_WRITE(RADEON_SCRATCH_REG1, 0xdeadbeef);
 
+ flush_kernel_dcache_range(dev_priv->ring_rptr, PAGE_SIZE);
          for (tmp = 0; tmp < dev_priv->usec_timeout; tmp++) {
                  u32 val;
 

But that is probably a shot in the dark. I have no clue what the flush_.. is doing.

[edit: And then I noticed sba_iommu.c, which is a complete IOMMU driver where bus and physical addresses are different. sigh. What type of machine is this? Does it have the IOMMU in it?]

Quoted 2 lines

                 void *va = bus_to_virt(gtt->ttm.dma_address[i]); if ((phys_addr_t) va != virt_to_bus(va)) {

You are missing a translation here (you were comparing the virtual address to the bus address). I was thinking something along this:

                unsigned int pfn = page_to_pfn(ttm->pages[i]); dma_addr_t bus =  gtt->ttm.dma_address[i]; void *va_bus, *va, *va_pfn;

                if ((pfn << PAGE_SHIFT) != bus)
                        printk("Bus 0x%lx != PFN 0x%lx, bus, pfn << PAGE_SHIFT); /* OK, that means bus addresses are different */

                va_bus = bus_to_virt(gtt->ttm.dma_address[i]); va_pfn = __va(pfn << PAGE_SHIFT);

                if (!virt_addr_valid(va_bus)) printk("va_bus (0x%lx) not good!\n", va_bus); if (!virt_addr_valid(va_pfn)) printk("va_pfn (0x%lx) not good!\n", va_pfn);

                /* We got VA for both bus -> va, and pfn -> va. Should be the same if bus and physical addresses are on the same namespace. */ if (va_bus != va_pfn)
                        printk("va bus:%lx != va pfn: %lx\n", va_bus, va_pfn);

                /* Now that we have bus -> pa -> va (va_bus) try to go va_bus -> bus address.
                   The bus address should be the same */
                if (gtt->tmm.dma_address[i] != virt_to_bus(va_bus))
                        printk("bus->pa->va:%lx != bus->pa->va->ba: %lx\n", gtt->tmm.dma_address[i],virt_to_bus(va_bus));

Quoted 2 lines

                      DRM_INFO("MISMATCH: %p != %p\n", va, (void *) virt_to_bus(va)); /*DRM_INFO("CONTENTS: %x\n", *((uint32_t *)va));*/ // Leads to a Kernel Fault

That is odd. I would have thought it would be usuable.

Quoted 3 lines

                      ...
                 }

Quoted 3 lines

 I'm getting the output:

 [drm] MISMATCH: 0000000080280000 != 0000000040280000

In theory that means the bus address that is programmed in (gtt->dma_address[i]) is 0000000040280000 (which is what virt_to_bus(va) should have resolved itself to).

Tha you can't get access to 'va' (0000000080280000) is odd. One way to try to access it is to do:

        va = __va(page_to_pfn(ttm->pages[i]) << PAGE_SHIFT); DRM_INFO("CONTENTS: %x\n", *((uint32_t)va));

As that would get it via the page -> va.

 25.09.2013, 21:28, "Konrad Rzeszutek Wilk" <[email protected]>:

Quoted 5 lines

  I took a look at the arch/parisc/kernel/pci-dma.c and I see that is mostly a flat platform. That is bus addresses == physical addresses. Unless it is an pclx or pclx2 CPU type (huh?) - if its it that then any calls to dma_alloc_coherent will map memory out of a pool. In essence it will look like a SWIOTLB bounce buffer.

 arch/parisc/kernel/pci-dma.c:
 ** PARISC 1.1 Dynamic DMA mapping support.
 ** This implementation is for PA-RISC platforms that do not support ** I/O TLBs (aka DMA address translation hardware).

 That's very old. PA-RISC 2.0 came into the game circa 1996. PA-RISC 1.1 is 32-bit only and i even not sure whether these machines had PCI bus.

 Only old boxes (PA7200 CPU and lower) cannot use dma_alloc_coherent() (and forced to do syncs iirc). That's not our case.
 And PA-RISC configs have 'Discontiguous Memory' choosen.

Quoted 5 lines

  But interestingly enough there is a lot of 'flush_kernel_dcache_range' call for every DMA operation.
 And I think the you need to do
  dma_sync_for_cpu call in the radeon_test_writeback for it to use the flush_kernel_dcache_range.

Quoted 2 lines

 I don't know what the
  flush_kernel_dcache_range does thought so I could be wrong.

 D-cache is a CPU cache (if they meant it). Seems to be L1-level. There is an I-cache at same level.

Quoted 2 lines

  You are missing a translation here (you were comparing the virtual address to the bus address). I was thinking something along this:

 Yes, this confused me. I've translated your suggestion literally :\

Quoted 25 lines

                  unsigned int pfn = page_to_pfn(ttm->pages[i]); dma_addr_t bus =  gtt->ttm.dma_address[i]; void *va_bus, *va, *va_pfn;

                  if ((pfn << PAGE_SHIFT) != bus)
                          printk("Bus 0x%lx != PFN 0x%lx, bus, pfn << PAGE_SHIFT); /* OK, that means bus addresses are different */

                  va_bus = bus_to_virt(gtt->ttm.dma_address[i]); va_pfn = __va(pfn << PAGE_SHIFT);

                  if (!virt_addr_valid(va_bus)) printk("va_bus (0x%lx) not good!\n", va_bus); if (!virt_addr_valid(va_pfn)) printk("va_pfn (0x%lx) not good!\n", va_pfn);

                  /* We got VA for both bus -> va, and pfn -> va. Should be the same if bus and physical addresses are on the same namespace. */ if (va_bus != va_pfn)
                          printk("va bus:%lx != va pfn: %lx\n", va_bus, va_pfn);

                  /* Now that we have bus -> pa -> va (va_bus) try to go va_bus -> bus address.
                     The bus address should be the same */
                  if (gtt->tmm.dma_address[i] != virt_to_bus(va_bus))
                          printk("bus->pa->va:%lx != bus->pa->va->ba: %lx\n", gtt->tmm.dma_address[i],virt_to_bus(va_bus));

Quoted 6 lines

Quoted 2 lines

                        DRM_INFO("MISMATCH: %p != %p\n", va, (void *) virt_to_bus(va)); /*DRM_INFO("CONTENTS: %x\n", *((uint32_t *)va));*/ // Leads to a Kernel Fault

  That is odd. I would have thought it would be usuable.

Quoted 3 lines

                        ...
                   }

Quoted 5 lines

Quoted 3 lines

   I'm getting the output:

   [drm] MISMATCH: 0000000080280000 != 0000000040280000

  In theory that means the bus address that is programmed in (gtt->dma_address[i]) is 0000000040280000 (which is what virt_to_bus(va) should have resolved itself to).

 Should resolved properly. I had a sane check of virt_to_bus(va) == gtt->ttm.dma_address[i]

Quoted 7 lines

  Tha you can't get access to 'va' (0000000080280000) is odd. One way to try to access it is to do:

          va = __va(page_to_pfn(ttm->pages[i]) << PAGE_SHIFT); DRM_INFO("CONTENTS: %x\n", *((uint32_t)va));

  As that would get it via the page -> va.

 _______________________________________________
 dri-devel mailing list
 [email protected]
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

Things planned for a check:
"The drivers/video/aty uses
an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture."

From: Thomas Bogendoerfer <[email protected]>

The LMMIO length reported by PAT and the length given by the LBA MASK register are not consistent. This leads e.g. to a non-working ATI FireGL card with the radeon DRM driver since the memory can't be mapped.

Fix this by correctly adjusting the resource sizes.

Signed-off-by Helge Deller <[email protected]>

From: Thomas Bogendoerfer <[email protected]>

The LMMIO length reported by PAT and the length given by the LBA MASK register are not consistent. This leads e.g. to a non-working ATI FireGL card with the radeon DRM driver since the memory can't be mapped.

Fix this by correctly adjusting the resource sizes.

Signed-off-by Helge Deller <[email protected]>