[PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Helge Deller]

From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>

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 <deller@gmx.de>

diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
index 1f05913..7dc0e40 100644
--- a/drivers/parisc/lba_pci.c
+++ b/drivers/parisc/lba_pci.c
@@ -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);
+					p->end = p->start + lba_len;
+				}
 				sprintf(lba_dev->hba.lmmio_name,
 						"PCI%02x LMMIO",
 						(int)lba_dev->hba.bus_num.start);

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Matt Turner]

On Fri, Jun 14, 2013 at 12:11 AM, Helge Deller <deller@gmx.de> wrote:
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
>
> 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 <deller@gmx.de>
>
> diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
> index 1f05913..7dc0e40 100644
> --- a/drivers/parisc/lba_pci.c
> +++ b/drivers/parisc/lba_pci.c
> @@ -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);
> +                                       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?

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Helge Deller]

* Matt Turner <mattst88@gmail.com>:
> On Fri, Jun 14, 2013 at 12:11 AM, Helge Deller <deller@gmx.de> wrote:
> > From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> >
> > 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 <deller@gmx.de>
> >
> > diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
> > index 1f05913..7dc0e40 100644
> > --- a/drivers/parisc/lba_pci.c
> > +++ b/drivers/parisc/lba_pci.c
> > @@ -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);
> > +                                       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?

Yes, C8000 with ATI FireGL works then for me with framebuffer, SMP, serial port...everything I tested so far.

Important: *Disable* RADEON Framebuffer driver, and enable Radeon DRM driver instead!

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.

BTW, I'll prepare a new installation CD for all machines soon...hopefully until end of
next week and hopefully when kernel 3.10 is released.

If you want to test, pull from git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
a)  my "for-3.10" branch, then
b)  my "important-for-3.10" branch (two fixed on which I wait for James)...

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....

Helge

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Helge Deller]

* Helge Deller <deller@gmx.de>:
> 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 meant C8000 of course...

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Thomas Bogendoerfer]

On Fri, Jun 14, 2013 at 09:38:27AM +0200, Helge Deller wrote:
> 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.

the pci mmap thing is a must for X11 to even get the card detected. This
patch is needed for the FireGL X3 cards with 256MB video memory.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Alex Ivanov]

Helge Deller <deller <at> gmx.de> writes:

> 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've built from test-3.10 branch of your repo:
Linux version 3.10.0-rc6-64bit-c3000+ (root@parisc) 
(gcc version 4.6.4 (GCC) ) #4 SMP PREEMPT Mon Jul 8 23:16:48 
MSK 2013

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.

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[John David Anglin]

On 7/9/2013 1:34 AM, Alex Ivanov wrote:
> 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.
Suggest you hack arch/parisc/kernel/cache.c to disable this
optimization:

         /* Flushing the whole cache on each cpu takes forever on
            rp3440, etc.  So, avoid it if the mm isn't too big.  */
         if (mm_total_size(mm) < parisc_cache_flush_threshold) {

It is probably the get_ptep call in the non current case that's failing
with firegl x3.  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.

Dave

-- 
John David Anglin    dave.anglin@bell.net

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Alex Ivanov]

John David Anglin <dave.anglin <at> bell.net> writes:

> 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.

Done. The system seems to work as usual. Should i do 
some specific checks?

> 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
Same was before with an UP kernel. The only thing
i've changed since is moving to the latest toolchains.
Can't reproduce the previous panic case, so can't
comment on your proposed solution.

P.S.: The hw is not faulty, works ok under hpux.

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On 7/9/2013 3:45 PM, Alex Ivanov wrote:
> 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).

Dave

-- 
John David Anglin    dave.anglin@bell.net


[-- Attachment #2: cache.c.d.txt --]
[-- Type: text/plain, Size: 702 bytes --]

diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 65fb4cb..8f60123 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -74,10 +74,13 @@ EXPORT_SYMBOL(flush_cache_all_local);
 void
 update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t *ptep)
 {
-	struct page *page = pte_page(*ptep);
+	struct page *page;
 
-	if (pfn_valid(page_to_pfn(page)) && page_mapping(page) &&
-	    test_bit(PG_dcache_dirty, &page->flags)) {
+	if (!pfn_valid(*ptep))
+		return;
+
+	page = pte_page(*ptep);
+	if (page_mapping(page) && test_bit(PG_dcache_dirty, &page->flags)) {
 
 		flush_kernel_dcache_page(page);
 		clear_bit(PG_dcache_dirty, &page->flags);

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On 9-Jul-13, at 4:59 PM, John David Anglin wrote:

> On 7/9/2013 3:45 PM, Alex Ivanov wrote:
>> 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.

Dave
--
John David Anglin	dave.anglin@bell.net



[-- Attachment #2: cache.c.d.txt --]
[-- Type: text/plain, Size: 1078 bytes --]

diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 65fb4cb..b07720f 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -74,10 +74,13 @@ EXPORT_SYMBOL(flush_cache_all_local);
 void
 update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t *ptep)
 {
-	struct page *page = pte_page(*ptep);
+	struct page *page;
 
-	if (pfn_valid(page_to_pfn(page)) && page_mapping(page) &&
-	    test_bit(PG_dcache_dirty, &page->flags)) {
+	if (!pfn_valid(pte_pfn(*ptep)))
+		return;
+
+	page = pte_page(*ptep);
+	if (page_mapping(page) && test_bit(PG_dcache_dirty, &page->flags)) {
 
 		flush_kernel_dcache_page(page);
 		clear_bit(PG_dcache_dirty, &page->flags);
@@ -519,8 +522,9 @@ void flush_cache_mm(struct mm_struct *mm)
 					pte_t *ptep = get_ptep(pgd, addr);
 					if (ptep != NULL) {
 						pte_t pte = *ptep;
-						__flush_cache_page(vma, addr,
-						  page_to_phys(pte_page(pte)));
+						if (pfn_valid(pte_pfn(pte)))
+							__flush_cache_page(vma, addr,
+						  		page_to_phys(pte_page(pte)));
 					}
 				}
 			}

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Alex Ivanov]

Sorry for not CC'ing to the list.

10.07.2013, 03:35, "John David Anglin" <dave.anglin@bell.net>:

> =9AOn 9-Jul-13, at 4:59 PM, John David Anglin wrote:
>> =9A=9AOn 7/9/2013 3:45 PM, Alex Ivanov wrote:
>>> =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=
=2E
>>
>> =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 dave.anglin@bell.net

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[John David Anglin]

On 7/10/2013 4:19 PM, Alex Ivanov wrote:
> Sorry for not CC'ing to the list.
>
> 10.07.2013, 03:35, "John David Anglin" <dave.anglin@bell.net>:
>
>>   On 9-Jul-13, at 4:59 PM, John David Anglin wrote:
>>>    On 7/9/2013 3:45 PM, Alex Ivanov wrote:
>>>>    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.
>>
>>   Dave
>>   --
>>   John David Anglin dave.anglin@bell.net
> 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.
I have been studying this issue a bit more.  It looks to me as if it 
would be better to call
vm_normal_page to get the page.  It returns NULL when we a have special 
mapping that
doesn't want to be associated with a struct page.  See comment in 
mm/memory.c.

I'll send a patch when I get a chance to test this approach.

Dave

-- 
John David Anglin    dave.anglin@bell.net

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Matt Turner]

On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> 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?

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Alex Ivanov]

11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
> On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wro=
te:
>
>> =9AThank you so much! Your guess looks to be right. After applying o=
f your
>> =9Apatch 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 Xo=
rg=20
states 24bit in it's log.
As for DRI, i'm experiencing=20
"ring test failed (scratch(0x15E4)=3D0xCAFEDEAD)" with a firegl x3.

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 addi=
ng a=20
buffer bounces in places will not help.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Helge Deller]

adding linux parisc mailing list...:

On 07/11/2013 09:46 PM, Helge Deller wrote:
> On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>> 11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>> On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>
>>>>  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 haven't tested X11 yet.
> 
>> 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
> 

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Alex Ivanov]

11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:
> adding linux parisc mailing list...:
>
> On 07/11/2013 09:46 PM, Helge Deller wrote:
>
>> =9AOn 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>> =9A11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>>> =9AOn Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.t=
k> wrote:
>>>>> =9A=9AThank you so much! Your guess looks to be right. After appl=
ying of your
>>>>> =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=
ough Xorg
>>> =9Astates 24bit in it's log.
>>> =9AAs for DRI, i'm experiencing
>>> =9A"ring test failed (scratch(0x15E4)=3D0xCAFEDEAD)" with a firegl =
x3.
>> =9AFWIW, I'm seeing the same failure on my FireGL X1:
>> =9A80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] n=
ee ATI Radeon R300 NG [FireGL X1] (rev 80)
>>
>> =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=
15E4)=3D0xCAFEDEAD)
>> =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=
n CP.
>> =9A[drm] radeon: cp finalized
>> =9A[drm] radeon: cp finalized

I still have no clue why this happens. Broken SBA IOMMU / DRM code? Mis=
sing 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[John David Anglin]

On 4-Aug-13, at 7:00 AM, Alex Ivanov wrote:

> 11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:
>> adding linux parisc mailing list...:
>>
>> On 07/11/2013 09:46 PM, Helge Deller wrote:
>>
>>>  On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>>  11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>>>>  On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov  
>>>>> <gnidorah@p0n4ik.tk> wrote:
>>>>>>   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?

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

Dave
--
John David Anglin	dave.anglin@bell.net

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Matt Turner]

On Sun, Aug 4, 2013 at 8:44 AM, John David Anglin <dave.anglin@bell.net> wrote:
> I wonder if there is a endian issue in the microcode load.

It should work on PowerPC (big-endian).

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[John David Anglin]

On 4-Aug-13, at 7:00 AM, Alex Ivanov wrote:

> 11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:
>> adding linux parisc mailing list...:
>>
>> On 07/11/2013 09:46 PM, Helge Deller wrote:
>>
>>>  On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>>  11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>>>>  On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov  
>>>>> <gnidorah@p0n4ik.tk> wrote:
>>>>>>   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

Have you tried agpmode=-1 to force PCI mode.  It seems like this was a  
problem at one time on ubuntu:
http://phoronix.com/forums/showthread.php?17615-Testing-radeon-KMS-on-Ubuntu

Dave
--
John David Anglin	dave.anglin@bell.net

drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

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" <gnidorah@p0n4ik.tk>:

11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:

>  adding linux parisc mailing list...:
>
>  On 07/11/2013 09:46 PM, Helge Deller wrote:
>>   On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>   11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>>>   On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>>>    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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-------- Завершение пересылаемого сообщения --------
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Deucher]

On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> 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."

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

>
> "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?..."

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

>
> Thanks.
>
> -------- Пересылаемое сообщение  --------
> 04.08.2013, 15:06, "Alex Ivanov" <gnidorah@p0n4ik.tk>:
>
> 11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:
>
>>  adding linux parisc mailing list...:
>>
>>  On 07/11/2013 09:46 PM, Helge Deller wrote:
>>>   On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>>   11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>>>>   On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>>>>    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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> -------- Завершение пересылаемого сообщения --------
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

Alex,

09.09.2013, в 21:43, Alex Deucher <alexdeucher@gmail.com> написал(а):

> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>> 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."
> 
> 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.

> 
>> 
>> "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?..."
> 
> 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...

> 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.

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.orig	2013-09-10 08:55:05.000000000 +0000
+++ radeon_device.c	2013-09-10 09:12:17.000000000 +0000
@@ -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;
 }

> 
> Alex
> 
>> 
>> Thanks.
>> 
>> -------- Пересылаемое сообщение  --------
>> 04.08.2013, 15:06, "Alex Ivanov" <gnidorah@p0n4ik.tk>:
>> 
>> 11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:
>> 
>>> adding linux parisc mailing list...:
>>> 
>>> On 07/11/2013 09:46 PM, Helge Deller wrote:
>>>>  On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>>>  11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>>>>>  On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>>>>>   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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> -------- Завершение пересылаемого сообщения --------
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Deucher]

On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> Alex,
>
> 09.09.2013, в 21:43, Alex Deucher <alexdeucher@gmail.com> написал(а):
>
>> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>> 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."
>>
>> 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.
>
>>
>>>
>>> "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?..."
>>
>> 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...
>
>> 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.
>
> 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 :(
>

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.

Alex

> --- radeon_device.c.orig        2013-09-10 08:55:05.000000000 +0000
> +++ radeon_device.c     2013-09-10 09:12:17.000000000 +0000
> @@ -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;
>  }
>
>>
>> Alex
>>
>>>
>>> Thanks.
>>>
>>> -------- Пересылаемое сообщение  --------
>>> 04.08.2013, 15:06, "Alex Ivanov" <gnidorah@p0n4ik.tk>:
>>>
>>> 11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:
>>>
>>>> adding linux parisc mailing list...:
>>>>
>>>> On 07/11/2013 09:46 PM, Helge Deller wrote:
>>>>>  On 07/10/2013 11:29 PM, Alex Ivanov wrote:
>>>>>>  11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
>>>>>>>  On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>>>>>>   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 majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> -------- Завершение пересылаемого сообщения --------
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Hans Verkuil]

On 09/10/2013 02:37 PM, Alex Deucher wrote:
> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>> Alex,
>>
>> 09.09.2013, в 21:43, Alex Deucher <alexdeucher@gmail.com> написал(а):
>>
>>> On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>> 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."
>>>
>>> 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.

Actually, I am experiencing exactly the same problem on a Sam460ex ppc
system, at least as of 3.9 (the last time I tried it).

Very rarely the ringtest would pass, but then it would fail somewhere else.
I never could figure it out since as far as I could tell all the addresses
and logic was correct. It wasn't important enough for me to work more on it,
but I'd be happy to test code. I'm travelling for the next week and a half,
so I can't do anything right now.

One bug I found when working on drm/kms support for the ppc was that in
struct ttm_bus_placement the base address type was wrong: it should be
phys_addr_t, not unsigned long. The PPC460 is in 32-bit mode but physical
addresses are >32 bits.

The patch below fixes that. I always wanted to post this fix, but never got
around to it...

Regards,

	Hans

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 arch/powerpc/sysdev/ppc4xx_msi.c       |    6 +++---
 drivers/gpu/drm/radeon/radeon_device.c |    2 +-
 include/drm/ttm/ttm_bo_api.h           |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 49b0659..fa33568 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1066,7 +1066,7 @@ int radeon_device_init(struct radeon_device *rdev,
 	if (rdev->rmmio == NULL) {
 		return -ENOMEM;
 	}
-	DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)rdev->rmmio_base);
+	DRM_INFO("register mmio base: 0x%llx\n", (uint64_t)rdev->rmmio_base);
 	DRM_INFO("register mmio size: %u\n", (unsigned)rdev->rmmio_size);
 
 	/* io port mapping */
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 3cb5d84..fcdb208 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -81,7 +81,7 @@ struct ttm_placement {
  */
 struct ttm_bus_placement {
 	void		*addr;
-	unsigned long	base;
+	phys_addr_t	base;
 	unsigned long	size;
 	unsigned long	offset;
 	bool		is_iomem;
-- 
1.7.10.4


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Konrad Rzeszutek Wilk]

On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote:
> Alex,
> 
> 09.09.2013, в 21:43, Alex Deucher <alexdeucher@gmail.com> написал(а):
> 
> > On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> >> 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."
> > 
> > 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.
> 
> > 
> >> 
> >> "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?..."
> > 
> > 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...
> 
> > 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.
> 
> 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?

> 
> --- radeon_device.c.orig	2013-09-10 08:55:05.000000000 +0000
> +++ radeon_device.c	2013-09-10 09:12:17.000000000 +0000
> @@ -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;
>  }
> 
> > 
> > Alex
> > 
> >> 
> >> Thanks.
> >> 
> >> -------- Пересылаемое сообщение  --------
> >> 04.08.2013, 15:06, "Alex Ivanov" <gnidorah@p0n4ik.tk>:
> >> 
> >> 11.07.2013, 23:48, "Helge Deller" <deller@gmx.de>:
> >> 
> >>> adding linux parisc mailing list...:
> >>> 
> >>> On 07/11/2013 09:46 PM, Helge Deller wrote:
> >>>>  On 07/10/2013 11:29 PM, Alex Ivanov wrote:
> >>>>>  11.07.2013, 01:14, "Matt Turner" <mattst88@gmail.com>:
> >>>>>>  On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> >>>>>>>   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 majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> -------- Завершение пересылаемого сообщения --------
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Fwd: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

Mates, let's continue with this issue at dri-devel@lists.freedesktop.or=
g
Here's where we stopped:

--[start]--

> =EF=D4: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> =F4=C5=CD=C1: =EF=D4=D7=C5=D4: drm/radeon: "ring test failed" on PA-R=
ISC Linux
> =E4=C1=D4=C1: 10 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:25:29 GMT+04:=
00
> =EB=CF=CD=D5: Alex Ivanov <gnidorah@p0n4ik.tk>
> =EB=CF=D0=C9=D1: Alex Deucher <alexdeucher@gmail.com>, Maling list - =
DRI developers <dri-devel@lists.freedesktop.org>
>=20
> On Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote:
>>=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=
s
> 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?

--[end]--

Thomas,

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

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

> Is 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.h=
tml
"I don't think that will any difference.  radeon kms works fine on
other big endian platforms such as powerpc."--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

This hand't been indexed, so i'll resending. Sorry for the noise...

11.09.2013, 15:11, "Alex Ivanov" <gnidorah@p0n4ik.tk>:
> Mates, let's continue with this issue at dri-devel@lists.freedesktop.=
org
> Here's where we stopped:
>
> --[start]--
>
>> =9A=EF=D4: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> =9A=F4=C5=CD=C1: =EF=D4=D7=C5=D4: drm/radeon: "ring test failed" on =
PA-RISC Linux
>> =9A=E4=C1=D4=C1: 10 =D3=C5=CE=D4=D1=C2=D2=D1 2013 =C7., 17:25:29 GMT=
+04:00
>> =9A=EB=CF=CD=D5: Alex Ivanov <gnidorah@p0n4ik.tk>
>> =9A=EB=CF=D0=C9=D1: Alex Deucher <alexdeucher@gmail.com>, Maling lis=
t - DRI developers <dri-devel@lists.freedesktop.org>
>>
>> =9AOn Tue, Sep 10, 2013 at 01:20:57PM +0400, Alex Ivanov wrote:
>>> =9AThanks! I'll try. Meanwhile i've tried a switch from page_alloc(=
) to
>>> =9Adma_alloc_coherent() in radeon_dummy_page_*(), which didn't help=
 :(
>> =9AIs this platform enabling the SWIOTLB layer? The reason I am aski=
ng is
>> =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 =
that
>> =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=
=2E
>>
>> =9APerhaps the PA-RISC IOMMU creates the DMA addresses differently?
>>
>> =9AWhen the card gets programmed, you do end up using ttm_agp_bind r=
ight?
>> =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,
>
>> =9AWhat I'm still wondering is whether radeon DRM really works on 64=
bit
>> =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.
>
>> =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=
=2Ehtml
> "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=
c" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =9Ahttp://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

Alex,

10.09.2013, в 16:37, Alex Deucher <alexdeucher@gmail.com> написал(а):

> 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:

On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:

> 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" <konrad.wilk@oracle.com>:
>
> Is this platform enabling the SWIOTLB layer? 

Doesn't look like. 

> 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?

No idea how to modify ttm_agp_bind() this way, though doesn't matter if
swiotlb isn't used anyway?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Deucher]

On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> Alex,
>
> 10.09.2013, в 16:37, Alex Deucher <alexdeucher@gmail.com> написал(а):
>
>> 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:
>
> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>
>> 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

>
> Konrad,
>
> 10.09.2013, 17:25, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>:
>>
>> Is this platform enabling the SWIOTLB layer?
>
> Doesn't look like.
>
>> 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?
>
> No idea how to modify ttm_agp_bind() this way, though doesn't matter if
> swiotlb isn't used anyway?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

17.09.2013, в 18:24, Alex Deucher <alexdeucher@gmail.com> написал(а):

> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>> Alex,
>> 
>> 10.09.2013, в 16:37, Alex Deucher <alexdeucher@gmail.com> написал(а):
>> 
>>> 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:
>> 
>> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>> 
>>> 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

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.

[-- Attachment #2: drm_parisc_debug.tgz --]
[-- Type: application/octet-stream, Size: 7044 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

17.09.2013, в 23:33, Alex Ivanov <gnidorah@p0n4ik.tk> написал(а):

> 17.09.2013, в 18:24, Alex Deucher <alexdeucher@gmail.com> написал(а):
> 
>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>> Alex,
>>> 
>>> 10.09.2013, в 16:37, Alex Deucher <alexdeucher@gmail.com> написал(а):
>>> 
>>>> 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:
>>> 
>>> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>> 
>>>> 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
> 
> 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
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

The ring->ring is NULL...
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Deucher]

On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> 17.09.2013, в 18:24, Alex Deucher <alexdeucher@gmail.com> написал(а):
>
>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>> Alex,
>>>
>>> 10.09.2013, в 16:37, Alex Deucher <alexdeucher@gmail.com> написал(а):
>>>
>>>> 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:
>>>
>>> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>
>>>> 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
>
> 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.

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?

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index a890756..b4f04d2 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -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--;
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

21.09.2013, в 1:27, Alex Deucher <alexdeucher@gmail.com> написал(а):

> On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>> 17.09.2013, в 18:24, Alex Deucher <alexdeucher@gmail.com> написал(а):
>> 
>>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>> Alex,
>>>> 
>>>> 10.09.2013, в 16:37, Alex Deucher <alexdeucher@gmail.com> написал(а):
>>>> 
>>>>> 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:
>>>> 
>>>> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>>>> 
>>>>> 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
>> 
>> 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.
> 
> 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?

Unfortunately, no.

> 
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index a890756..b4f04d2 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -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--;

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Konrad Rzeszutek Wilk]

On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
> 21.09.2013, в 1:27, Alex Deucher <alexdeucher@gmail.com> написал(а):
> 
> > On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> >> 17.09.2013, в 18:24, Alex Deucher <alexdeucher@gmail.com> написал(а):
> >> 
> >>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> >>>> Alex,
> >>>> 
> >>>> 10.09.2013, в 16:37, Alex Deucher <alexdeucher@gmail.com> написал(а):
> >>>> 
> >>>>> 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:
> >>>> 
> >>>> On Tue, Sep 10, 2013 at 5:20 AM, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
> >>>> 
> >>>>> 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
> >> 
> >> 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.
> > 
> > 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?

> > 
> > Does doing a posted write when writing to the ring buffer help?
> 
> Unfortunately, no.
> 
> > 
> > diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> > b/drivers/gpu/drm/radeon/radeon_ring.c
> > index a890756..b4f04d2 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ring.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> > @@ -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--;
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

24.09.2013, 00:11, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>:
> On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
>
>>  21.09.2013, в 1:27, Alex Deucher <alexdeucher@gmail.com> написал(а):
>>>  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?
>

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.

> 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
[drm] MISMATCH: 0000000080281000 != 0000000040281000
...

How can i check the same for an AGP mode?

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

I'll see.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Konrad Rzeszutek Wilk]

On Wed, Sep 25, 2013 at 08:29:07PM +0400, Alex Ivanov wrote:
> 24.09.2013, 00:11, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>:
> > On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
> >
> >>  21.09.2013, в 1:27, Alex Deucher <alexdeucher@gmail.com> написал(а):
> >>>  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?
> >
> 
> 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:


diff --git a/drivers/gpu/drm/radeon/radeon_cp.c b/drivers/gpu/drm/radeon/radeon_cp.c
index 3cae2bb..9e5923d 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -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?] 
> 
> > 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)) {

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));
		
>                      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.

>                      ...
>                 }
> 
> 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
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Deucher]

On Wed, Sep 25, 2013 at 1:28 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Wed, Sep 25, 2013 at 08:29:07PM +0400, Alex Ivanov wrote:
>> 24.09.2013, 00:11, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>:
>> > On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
>> >
>> >>  21.09.2013, в 1:27, Alex Deucher <alexdeucher@gmail.com> написал(а):
>> >>>  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?
>> >
>>
>> 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:
>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c b/drivers/gpu/drm/radeon/radeon_cp.c
> index 3cae2bb..9e5923d 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -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;
>


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.

Alex


> 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?]
>>
>> > 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)) {
>
> 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));
>
>>                      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.
>
>>                      ...
>>                 }
>>
>> 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
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

Alex,

> 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.

Right!

Konrad,
Thanks for the code! I'll try asap.

25.09.2013, 21:28, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>:
> 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.

>
> 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.

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

>
> That means you can ignore the little code below I wrote and
> see about doing something like this:
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c b/drivers/gpu/drm/radeon/radeon_cp.c
> index 3cae2bb..9e5923d 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -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?]

That's our case.
Yes, recent IA64 and PA-RISC machines have SBA IOMMU device. PCI I/O
seem to go through it. There is a note for my chipset in sba_iommu.c:

/* We are just "encouraging" 32-bit DMA masks here since we can
 * never allow IOMMU bypass unless we add special support for ZX1.
 */

And it indeed right. When i've tried to bypass hw IOMMU like in ia64
code it lead to the faults from drivers which do the DMA (like Fusion MPT SCSI
driver).

>>                  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:

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

>
>                 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));
>
>>                       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.
>
>>                       ...
>>                  }
>>
>>  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]

> 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
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Alex Ivanov]

Let's go futher.

25.09.2013, 22:58, "Alex Ivanov" <gnidorah@p0n4ik.tk>:

>  25.09.2013, 21:28, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>:
>>   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.
>>   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 was correct regarding syncs.
In our case (SBA IOMMU) dma_sync* calls are no-ops:

sba_iommu.c:
static struct hppa_dma_ops sba_ops = {
...
     .dma_sync_single_for_cpu =      NULL,
        .dma_sync_single_for_device =   NULL,
         .dma_sync_sg_for_cpu =          NULL,
        .dma_sync_sg_for_device =       NULL,
}

dma-mapping.h:
 dma_cache_sync(struct device *dev, void *vaddr, size_t size,
               enum dma_data_direction direction)
 {
        if(hppa_dma_ops->dma_sync_single_for_cpu)
                flush_kernel_dcache_range((unsigned long)vaddr, size);
 }

So i'll skip doing the flush_kernel_dcache_range().

>>  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.
>>   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 :\
>>                   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));

Ok, slightly modified:

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

	BUG_ON(!pfn_valid(pfn));
	//BUG_ON(!page_mapping(page)); // Leads to a kernel BUG

/* Avoid floodage */
if (i % 100 == 0) {
	if ((pfn << PAGE_SHIFT) != bus)
		printk("Bus 0x%lx != PFN 0x%lx\n", bus, pfn << PAGE_SHIFT); /*
		OK, that means bus addresses are different */

	va_bus = bus_to_virt(bus);
	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 (bus != virt_to_bus(va_bus))
		printk("bus->pa->va: %lx != bus->pa->va->ba: %lx\n", bus,virt_to_bus(va_bus));
}

Output:
Bus 0x40280000 != PFN 0x3e92d000
va_bus (0x80280000) not good!
va bus: 80280000 != va pfn: 7e92d000
Bus 0x40281000 != PFN 0x3e930000
va_bus (0x80281000) not good!
va bus: 80281000 != va pfn: 7e930000
...

va_bus is invalid. That's the reason i was getting a KF trying to read data behind it.

>>>                         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.
>>>                         ...
>>>                    }
>>>
>>>    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]
>>   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.

This way i get CONTENTS: 0

>  _______________________________________________
>  dri-devel mailing list
>  dri-devel@lists.freedesktop.org
>  http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon: "ring test failed" on PA-RISC Linux

[Michel Dänzer]

On Mon, 2013-09-09 at 20:44 +0400, Alex Ivanov wrote:
> 
> 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 radeon driver works on PPC, so this can't really be your problem
FWIW.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Thomas Bogendoerfer]

On Fri, Jun 14, 2013 at 09:11:42AM +0200, Helge Deller wrote:
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> 
> 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 <deller@gmx.de>

add my Acked-By or Signed-off-by, whatever you like.

BTW. thanks for cleaning up the patches.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH] parisc: fix LMMIO mismatch between PAT length and MASK register

[Helge Deller]

* Helge Deller <deller@gmx.de>:
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> 
> 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 <deller@gmx.de>

This is an updated/cleaner approach to this problem.
Still I want some more testing on it with various machines.

Basically we now extend the LMMIO range up to 256MB above the initial
start of the region if the value of the MASK register seems to allow it.

Signed-off-by: Helge Deller <deller@gmx.de>

diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
index 1f05913..acc3fe8 100644
--- a/drivers/parisc/lba_pci.c
+++ b/drivers/parisc/lba_pci.c
@@ -613,6 +613,46 @@ truncate_pat_collision(struct resource *root, struct resource *new)
 	return 0;	/* truncation successful */
 }
 
+/*
+ * extend_lmmio_len: extend lmmio range to maximum length
+ */
+static unsigned long
+extend_lmmio_len(unsigned long start, unsigned long end, unsigned long lba_len)
+{
+	struct resource *tmp;
+
+	pr_debug("LMMIO mismatch: PAT length = 0x%lx, MASK register = 0x%lx\n",
+		end - start, lba_len);
+
+	lba_len = min(lba_len+1, 256UL*1024*1024); /* limit to 256 MB */
+
+	pr_info("LBA: lmmio_space [0x%lx-0x%lx] - original\n", start, end);
+
+	end += lba_len;
+	if (end < start) /* fix overflow */
+		end = -1ULL;
+
+	pr_debug("LBA: lmmio_space [0x%lx-0x%lx] - current\n", start, end);
+
+	/* first overlap */
+	for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+		pr_debug("LBA: testing %pR\n", tmp);
+		if (tmp->start == start)
+			continue; /* ignore ourself */
+		if (tmp->end < start)
+			continue;
+		if (tmp->start > end)
+			continue;
+		if (end >= tmp->start)
+			end = tmp->start - 1;
+	}
+
+	pr_info("LBA: lmmio_space [0x%lx-0x%lx] - new\n", start, end);
+
+	/* return new end */
+	return end;
+}
+
 #else
 #define truncate_pat_collision(r,n)  (0)
 #endif
@@ -994,6 +1034,14 @@ 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)
+					p->end = extend_lmmio_len(p->start,
+						p->end, lba_len);
+
 				sprintf(lba_dev->hba.lmmio_name,
 						"PCI%02x LMMIO",
 						(int)lba_dev->hba.bus_num.start);