io_block_mapping in PPC64?

[Tzachi Perelstein]

See my comments bellow [Tzachi]. 


 
> On Mon, 2005-05-16 at 10:26 +0300, Tzachi Perelstein wrote:
> > 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.
> 
> Which every is good for you, but is this sram cache coherent ? If it's
> not, just use normal ioremap.

[Tzachi]: Yes it is cache coherence. I'll use __ioremap.

 
> As for why io_block_mapping() is considered bad nowadays is that in
> general, hard coding a virtual address is a bad thing. For example,
it's
> the abuse of io_block_mapping() that is forcing us to still default to
> only 2Gb of TASK_SIZE instead of 3Gb in ppc32. We decided on purpose
> against providing such an interface on ppc64, you have to "do the
right
> thing" and request a mapping with {_,__}ioremap like anything else.
> There are special cases that do allow explicit mappings in the ppc64
> kernel (ioremap_explicit) but these are _absolutely_ reserved for use
by
> the PCI subsystem for the mapping of the PCI "IO" space of bridges.
Your
> bridge should provide proper "ranges" properties in the OF device tree
> and thus you shouldn't have to call these yourself, just use the
common
> pci_process_OF_bridge_ranges().

[Tzachi]: Thanks clarifying it, I agree.

> 
> > I'm not going to refer your comment about Marvell on the mailing
list,
> > but it's coming soon - FYEO.
> 
> Ok, thanks. One thing I want to make sure of is that you are _not_
> trying to do something without a device-tree. We decided to make the
> presence of an OF-like device-tree mandatory for the ppc64
architecture.
> If you don't have an Open Firmware implementation nor a bootloader
> capable of providing an OF-like interface (like PIBS), you should at
> least have a bootloader providing a simple (static) device-tree via
the
> flattened format which is currently use between prom_init.c and the
rest
> of the kernel and with kexec. This should at least contain a /model
> property for identifying your platform, a /memory node with the
physical
> memory layout, and eventually additional informations about your PCI
> host bridge and other non-PCI devices

[Tzachi]: I do not use device-tree. Our Linux is loaded by U-Boot which
first time supports the IBM-970FX and first time executed in 64-bit
mode. There is no real need for such complex structures when loaded by
U-Boot. If you want ppc64 architecture to be spread to embedded systems
too you should avoid such restrictions. 

> Regards,
> Ben.
> 
>