io_block_mapping in PPC64?

[Benjamin Herrenschmidt]

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.

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


> 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

Regards,
Ben.