[2/2] Added leon3_dma_ops and LEON specific mmu_inval_dma_area

From: Kristoffer Glembo <kristoffer@gaisler.com>
Date: Tue, 12 Jan 2010 11:35:59 +0100

> David Miller wrote:
>> And I'm guessing that's why using virt_to_page() in the DMA mapping
>> implementation failed for you Kristoffer, it would be the only common
>> path it would be used on sparc32.
>> 
> 
> For me it still fails if I'm not adding phys_base in page_to_phys.

So I did research and this code is the way it is because
of LEON (this commit is from "linux-2.6-history.git") :-)

commit a44032987aaa82d48927b87a0193c7805ec9aade
Author: Keith M. Wesolowski <wesolows@foobazco.org>
Date:   Sat Mar 20 22:43:40 2004 -0800

    [SPARC32]: Support memory starting at physical address other than 0
    
    From: Stefan Holst <mail@s-holst.de>
    
    Allow physical memory to start at almost arbitrary addresses.  LEON
    needs it, so do SPARCstation 10/20 without slot 0 populated.  Although
    Sun do not support this configuration, at least some such systems can
    boot with this patch.
    
    Physical memory starting at or above 0xF4000000 is not supported.

This commit missed updating page_to_phys() appropriately, so
you were right all along I think.

So let's take baby steps, please confirm that you agree with me that
the following patch is correct and that it works on your machine.

If it works I want to reinstate the virt_to_page() change I posted
the other day as well, simply so that we consistently use the
asm-generic/memory-model.h interfaces instead of assuming FLATMEM
memory model all over our headers.

But I am truly mystified how anything works with non-zero phys_base
with this being wrong.  Fundamental operations like
{srmmu,sun4c}_mk_pte() use this.

LEON uses this via SRMMU, so how does it work properly? :-)

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Miller wrote:
> So I did research and this code is the way it is because
> of LEON (this commit is from "linux-2.6-history.git") :-)


Back then I was attending grad school and was blissfully unaware. :-)


> 
> So let's take baby steps, please confirm that you agree with me that
> the following patch is correct and that it works on your machine.


It works fine for me!


> If it works I want to reinstate the virt_to_page() change I posted
> the other day as well, simply so that we consistently use the
> asm-generic/memory-model.h interfaces instead of assuming FLATMEM
> memory model all over our headers.


Yes this change works as well.

> 
> But I am truly mystified how anything works with non-zero phys_base
> with this being wrong.  Fundamental operations like
> {srmmu,sun4c}_mk_pte() use this.
> 
> LEON uses this via SRMMU, so how does it work properly? :-)


Hmm, srmmu_mk_pte() uses page_to_pfn() which accounts for pfn_base?

The only use of page_to_phys below arch/sparc that I find is in pci32_map_page
which is where I got into trouble. :-)

Thanks for looking into this!

Best regards,
Kristoffer
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Kristoffer Glembo <kristoffer@gaisler.com>
Date: Thu, 14 Jan 2010 12:05:34 +0100

> It works fine for me!
 ...
> Yes this change works as well.

Thanks for testing.

> Hmm, srmmu_mk_pte() uses page_to_pfn() which accounts for pfn_base?

My eyes aren't working, I confused page_to_pfn() with page_to_phys().

Great, now it is all clear.

I'll add the fix to sparc-2.6, thanks again.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html