io_block_mapping in PPC64?

[Tzachi Perelstein]

Hi Ben,
Thanks for your reply. 
I don't know why you say that the io_block_mapping shouldn't be used.
We traditionally use this function during platform setup to map all
memory mapped devices, registers, secondary memories, etc. The function
interface allows you to provide both physical and virtual addresses and
their associated attributes, so giving the same physical and virtual
mapping is very convenience. Anyway, your suggestion __ioremap is good
enough. I've used _ioremap_explicit after ioremap to set cache coherency
attributes, but I'll change it to one __ioremap call.

I'm not going to refer your comment about Marvell on the mailing list,
but it's coming soon - FYEO.

Regards,
Tzachi

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh at kernel.crashing.org]
> Sent: Monday, May 16, 2005 1:55 AM
> To: Tzachi Perelstein
> Cc: linuxppc64-dev at ozlabs.org
> Subject: Re: io_block_mapping in PPC64?
> 
> On Mon, 2005-05-16 at 08:49 +1000, Benjamin Herrenschmidt wrote:
> > On Sun, 2005-05-15 at 16:08 +0300, Tzachi Perelstein wrote:
> > > Hi all,
> > >
> > > I develop Linux (PPC64, 2.6.9) for the new Marvell 64470
evaluation
> > > board with the IBM-970FX. Inside the Marvell system controller
there
> is
> > > a 2Mbit internal SRAM for applications that required fast memory
> access
> > > (traditionally for network driver descriptors).
> > > In the (32bit) PPC arch there is an io_block_mapping function that
can
> > > be used to map the internal SRAM with configurable (e.g. cache
> > > coherence) attributes. Is there any way to it in PPC64 arch? I
didn't
> > > find any reference for it. Any help will be appriciated.
> >
> > io_block_mapping() isn't really an interface I would recomment for
> > anybody to use... What about __ioremap() instead ?
> >
> > I also notice that Marvell didn't both submitting any patch for
> > supporting their board, I suppose they are happy with just providing
> > customers with their hacks and no attempt to have them validated &
> > merged upstream ...
> 
> Hrm... just noticed your @marvell.com address, so forget my previous
> comment. I would still recommend that any patch your come up with for
> supporting this board be submited on this list before it hits
customers.
> 
> I'm trying hard to avoid ppc64 becoming the mess ppc32 has get...
> 
> Ben.
>