[2/2] Added leon3_dma_ops and LEON specific mmu_inval_dma_area

From: Kristoffer Glembo <kristoffer@gaisler.com>
Date: Mon, 23 Nov 2009 13:31:32 +0100

> We did yes. You said that mem_map is not offset at phys_base and then
> of
> course we don't need to add it in page_to_phys. Is mem_map not offset
> because typically sp_banks[].base_addr = 0? In our case we pass in one
> sp_banks entry which has base_addr = 0x40000000.

Looking at this code, I can't see how virt_to_page() works right
now at all :-)

mem_map[] is offset by pfn_base

This is why __va() and __pa() account for it.

Can you see if your machine boots with the patch at the end of this
email applied?  Others can feel free to test this too :-)

Really, if pfn_base/phys_base are non-zero, it's quite amazing how a
sparc32 machine could sucessfully boot with the code as-is.

Looking more deeply, I guess it could work if you use CONFIG_SLUB.

Or, you use CONFIG_SLAB and SLABs are never destroyed and SLAB
growing never fails (kmem_freepages() uses virt_to_page()).

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.

Anyways, testing of this change by anyone with sparc32 boxes would be
much appreciated.

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

Hi,

David Miller wrote:
> 
> Looking at this code, I can't see how virt_to_page() works right
> now at all :-)
> 
> mem_map[] is offset by pfn_base
> 
> This is why __va() and __pa() account for it.
> 
> Can you see if your machine boots with the patch at the end of this
> email applied?  Others can feel free to test this too :-)
> 
> Really, if pfn_base/phys_base are non-zero, it's quite amazing how a
> sparc32 machine could sucessfully boot with the code as-is.
> 
> Looking more deeply, I guess it could work if you use CONFIG_SLUB.
> 
> Or, you use CONFIG_SLAB and SLABs are never destroyed and SLAB
> growing never fails (kmem_freepages() uses virt_to_page()).
> 

I was using CONFIG_SLAB without noticing any problems.

But I'm a bit confused. Doesn't this patch generate the exact same code?
Now __pa will add in phys_base but pfn_to_page(__pa()>>PAGE_SHIFT)
will remove it by subtracting ARCH_PFN_OFFSET.


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


Thanks,
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: Tue, 12 Jan 2010 11:35:59 +0100

> I was using CONFIG_SLAB without noticing any problems.
> 
> But I'm a bit confused. Doesn't this patch generate the exact same code?
> Now __pa will add in phys_base but pfn_to_page(__pa()>>PAGE_SHIFT)
> will remove it by subtracting ARCH_PFN_OFFSET.
 ...
> For me it still fails if I'm not adding phys_base in page_to_phys.

Indeed.

Ok, let me think about this some more.

Thanks for testing and looking at this.
--
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