linux.git/include/asm-ia64/io.h, branch master

[IA64] Move include/asm-ia64 to arch/ia64/include/asm

2008-08-01T17:21:21+00:00

After moving the the include files there were a few clean-ups:

1) Some files used #include , changed to 

2) Some comments alerted maintainers to look at various header files to
make matching updates if certain code were to be changed. Updated these
comments to use the new include paths.

3) Some header files mentioned their own names in initial comments. Just
deleted these self references.

Signed-off-by: Tony Luck

dmi: clean-up dmi helper declarations

2008-05-01T15:04:01+00:00

The declaration of dmi helper functions is a bit messy and inconsistent at the
moment:

* On ia64 they are declared in .
* On x86-64 they are declared in .
* On i386 they are declared both in  and .

Fix the header files so that the dmi helper functions are consistently
defined in .

Signed-off-by: Jean Delvare 
Cc: Matt Domsch 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Remove dma_cache_(wback|inv|wback_inv) functions

2007-10-17T15:42:57+00:00

dma_cache_(wback|inv|wback_inv) were the earliest attempt on a generalized
cache managment API for I/O purposes.  Originally it was basically the raw
MIPS low level cache API exported to the entire world.  The API has
suffered from a lack of documentation, was not very widely used unlike it's
more modern brothers and can easily be replaced by dma_cache_sync.  So
remove it rsp.  turn the surviving bits back into an arch private API, as
discussed on linux-arch.

Signed-off-by: Ralf Baechle 
Acked-by: Paul Mundt 
Acked-by: Paul Mackerras 
Acked-by: David S. Miller 
Acked-by: Kyle McMartin 
Acked-by: Haavard Skinnemoen 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[IA64] make ioremap avoid unsupported attributes

2007-03-30T16:37:41+00:00

Example memory map (from HP sx1000 with VGA enabled):
    0x00000 - 0x9FFFF supports only WB (cacheable) access
    0xA0000 - 0xBFFFF supports only UC (uncacheable) access
    0xC0000 - 0xFFFFF supports only WB (cacheable) access

pci_read_rom() indirectly uses ioremap(0xC0000) to read the shadow VGA option
ROM.  ioremap() used to default to a 16MB or 64MB UC kernel identity mapping,
which would cause an MCA when reading 0xC0000 since only WB is supported there.

X uses reads the option ROM to initialize devices.  A smaller test case is:
  # echo 1 > /sys/bus/pci/devices/0000:aa:03.0/rom
  # cp /sys/bus/pci/devices/0000:aa:03.0/rom x

To avoid this, we can use the same ioremap_page_range() strategy that most
architectures use for all ioremaps.  These page table mappings come out of the
vmalloc area.  On ia64, these are in region 5 (0xA... addresses) and typically
use 16KB or 64KB mappings instead of 16MB or 64MB mappings.  The smaller
mappings give more flexibility to use the correct attributes.

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Tony Luck

Altix: Add initial ACPI IO support

2006-12-01T22:36:57+00:00

First phase in introducing ACPI support to SN.
In this phase, when running with an ACPI capable PROM,
the DSDT will define the root busses and all SN nodes
(SGIHUB, SGITIO). An ACPI bus driver will be registered
for the node devices, with the acpi_pci_root_driver being
used for the root busses. An ACPI vendor descriptor is
now used to pass platform specific information for both
nodes and busses, eliminating the need for the current
SAL calls. Also, with ACPI support, SN fixup code is no longer
needed to initiate the PCI bus scans, as the acpi_pci_root_driver
does that.

However, to maintain backward compatibility with non-ACPI capable
PROMs, none of the current 'fixup' code can been deleted, though
much restructuring has been done. For example, the bulk of the code
in io_common.c is relocated code that is now common regardless
of what PROM is running, while io_acpi_init.c and io_init.c contain
routines specific to an ACPI or non ACPI capable PROM respectively.

A new pci bus fixup platform vector has been created to provide
a hook for invoking platform specific bus fixup from pcibios_fixup_bus().

The size of io_space[] has been increased to support systems with
large IO configurations.


Signed-off-by: John Keller 
Signed-off-by: Greg Kroah-Hartman

[IA64] move ioremap/ioremap_nocache under KERNEL

2006-10-17T21:49:15+00:00

I noticed these are declared extern outside of __KERNEL__, but surely
they wouldn't be available to userland since they're defined in
ioremap.c.  Am I missing something here?

If I'm right about this, then there's probably a good deal of other
stuff in io.h that could move inside __KERNEL__, but at least this is
a start.

Signed-off-by: Aron Griffis 
Signed-off-by: Tony Luck

[PATCH] make valid_mmap_phys_addr_range() take a pfn

2006-07-10T20:24:25+00:00

Newer ARMs have a 40 bit physical address space, but mapping physical
memory above 4G needs a special page table format which we (currently?) do
not use for userspace mappings, so what happens instead is that mapping an
address >= 4G will happily discard the upper bits and wrap.

There is a valid_mmap_phys_addr_range() arch hook where we could check for
>= 4G addresses and deny the mapping, but this hook takes an unsigned long
address:

	static inline int valid_mmap_phys_addr_range(unsigned long addr, size_t size);

And drivers/char/mem.c:mmap_mem() calls it like this:

	static int mmap_mem(struct file * file, struct vm_area_struct * vma)
	{
		size_t size = vma->vm_end - vma->vm_start;

		if (!valid_mmap_phys_addr_range(vma->vm_pgoff << PAGE_SHIFT, size))

So that's not much help either.

This patch makes the hook take a pfn instead of a phys address.

Signed-off-by: Lennert Buytenhek 
Cc: Bjorn Helgaas 
Cc: "Luck, Tony" 
Cc: Russell King 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[IA64] rework memory attribute aliasing

2006-05-08T23:32:05+00:00

This closes a couple holes in our attribute aliasing avoidance scheme:

  - The current kernel fails mmaps of some /dev/mem MMIO regions because
    they don't appear in the EFI memory map.  This keeps X from working
    on the Intel Tiger box.

  - The current kernel allows UC mmap of the 0-1MB region of
    /sys/.../legacy_mem even when the chipset doesn't support UC
    access.  This causes an MCA when starting X on HP rx7620 and rx8620
    boxes in the default configuration.

There's more detail in the Documentation/ia64/aliasing.txt file this
adds, but the general idea is that if a region might be covered by
a granule-sized kernel identity mapping, any access via /dev/mem or
mmap must use the same attribute as the identity mapping.

Otherwise, we fall back to using an attribute that is supported
according to the EFI memory map, or to using UC if the EFI memory
map doesn't mention the region.

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Tony Luck

[PATCH] ia64: ioremap: check EFI for valid memory attributes

2006-03-26T16:56:54+00:00

Check the EFI memory map so we can use the correct memory attributes for
ioremap().  Previously, we always used uncacheable access, which blows up on
some machines for regular system memory.

Signed-off-by: Bjorn Helgaas 
Cc: Matt Domsch 
Cc: "Tolentino, Matthew E" 
Cc: "Brown, Len" 
Cc: Andi Kleen 
Acked-by: "Luck, Tony" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] EFI, /dev/mem: simplify efi_mem_attribute_range()