Skip to content
  1. Sep 09, 2005
  3. Sep 08, 2005
    • Ben Dooks's avatar
      [ARM] 2891/1: S3C2410 - update s3c2410_defconfig for 2.6.13 · 0dffefbf
      Ben Dooks authored 
      

Patch from Ben Dooks

Updated the s3c2410_defconfig for the 2.6.13-git8
kernel release, as well as adding the Anubis
board to the list of boards built.

Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      0dffefbf
    • Tony Lindgren's avatar
      [ARM] 2890/1: OMAP 1/4: Update omap1 specific files, take 2 · 7c38cf02
      Tony Lindgren authored 
      

Patch from Tony Lindgren

This patch syncs the mainline kernel with linux-omap tree.
The highlights of the patch are:
- Convert more drivers to register resources in board-*.c to take
  advantage of the driver model by David Brownell and Ladislav Michl
- Use set_irq_type() for GPIO interrupts instead of
  omap_set_gpio_edge_ctrl() by David Brownell
- Add minimal support for handling optional add-on boards, such as
  OSK Mistral board with LCD and keypad, by David Brownell
- Minimal support for loading functions to SRAM by Tony Lindgren
- Wake up from serial port by muxing RX lines temporarily into GPIO
  interrupts by Tony Lindgren
- 32KHz sched_clock by Tony Lindgren and Juha Yrjola

Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7c38cf02
    • David S. Miller's avatar
      [PATCH] Make sparc64 use setup-res.c · 085ae41f
      David S. Miller authored 
      

There were three changes necessary in order to allow
sparc64 to use setup-res.c:

1) Sparc64 roots the PCI I/O and MEM address space using
   parent resources contained in the PCI controller structure.
   I'm actually surprised no other platforms do this, especially
   ones like Alpha and PPC{,64}.  These resources get linked into the
   iomem/ioport tree when PCI controllers are probed.

   So the hierarchy looks like this:

   iomem --|
	   PCI controller 1 MEM space --|
				        device 1
					device 2
					etc.
	   PCI controller 2 MEM space --|
				        ...
   ioport --|
            PCI controller 1 IO space --|
					...
            PCI controller 2 IO space --|
					...

   You get the idea.  The drivers/pci/setup-res.c code allocates
   using plain iomem_space and ioport_space as the root, so that
   wouldn't work with the above setup.

   So I added a pcibios_select_root() that is used to handle this.
   It uses the PCI controller struct's io_space and mem_space on
   sparc64, and io{port,mem}_resource on every other platform to
   keep current behavior.

2) quirk_io_region() is buggy.  It takes in raw BUS view addresses
   and tries to use them as a PCI resource.

   pci_claim_resource() expects the resource to be fully formed when
   it gets called.  The sparc64 implementation would do the translation
   but that's absolutely wrong, because if the same resource gets
   released then re-claimed we'll adjust things twice.

   So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource()
   conversion before passing it on to pci_claim_resource().

3) I was mistakedly __init'ing the function methods the PCI controller
   drivers provide on sparc64 to implement some parts of these
   routines.  This was, of course, easy to fix.

So we end up with the following, and that nasty SPARC64 makefile
ifdef in drivers/pci/Makefile is finally zapped.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      085ae41f
    • John W. Linville's avatar
      [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it · 064b53db
      John W. Linville authored 
      

Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
(including BARs) when transitioning from D3hot->D0.  This leaves such
a device in an inaccessible state.  The patch below causes the BARs
to be restored when enabling such a device, so that its driver will
be able to access it.

The patch also adds pci_restore_bars as a new global symbol, and adds a
correpsonding EXPORT_SYMBOL_GPL for that.

Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
(re)boot.  Most drivers call pci_enable_device very early, so devices
left in D3hot that lose configuration during the D3hot->D0 transition
will be inaccessible to their drivers.

Drivers could be modified to account for this, but it would
be difficult to know which drivers need modification.  This is
especially true since often many devices are covered by the same
driver.  It likely would be necessary to replicate code across dozens
of drivers.

The patch below should trigger only when transitioning from D3hot->D0
(or at boot), and only for devices that have the "no soft reset" bit
cleared in the PM control register.  I believe it is safe to include
this patch as part of the PCI infrastructure.

The cleanest implementation of pci_restore_bars was to call
pci_update_resource.  Unfortunately, that does not currently exist
for the sparc64 architecture.  The patch below includes a null
implemenation of pci_update_resource for sparc64.

Some have expressed interest in making general use of the the
pci_restore_bars function, so that has been exported to GPL licensed
modules.

Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      064b53db
    • Michael S. Tsirkin's avatar
      [PATCH] arch/386/pci: remap_pfn_range -> io_remap_pfn_range · 346d3882
      Michael S. Tsirkin authored 
      

Convert i386/pci to use io_remap_pfn_range instead of remap_pfn_range.
This is good for Xen which reuses i386/pci/i386.c for domain 0 code.

Signed-off-by: default avatarMichael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      346d3882
    • Andrew Morton's avatar
      [PATCH] PCI: fix up pretty-names removal patch · 8fdc23ee
      Andrew Morton authored 
      

Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8fdc23ee
    • Adrian Bunk's avatar
      [PATCH] PCI: remove CONFIG_PCI_NAMES · 982245f0
      Adrian Bunk authored 
      

This patch removes CONFIG_PCI_NAMES.

Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      982245f0
    • David S. Miller's avatar
      [SPARC64]: Inline membar()'s again. · 4d803fcd
      David S. Miller authored 
      

Since GCC has to emit a call and a delay slot to the
out-of-line "membar" routines in arch/sparc64/lib/mb.S
it is much better to just do the necessary predicted
branch inline instead as:

	ba,pt	%xcc, 1f
	 membar	#whatever
1:

instead of the current:

	call	membar_foo
	 dslot

because this way GCC is not required to allocate a stack
frame if the function can be a leaf function.

This also makes this bug fix easier to backport to 2.4.x

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4d803fcd
    • Jack Steiner's avatar
      [IA64] Increase max physical address for SN platforms · 9b17e7e7
      Jack Steiner authored 
      

Increase the value for the maximum physical address on SN systems.

Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      9b17e7e7
    • Dean Nelson's avatar
      [IA64] ensure XPC and XPNET are loaded on sn2 platforms only · 408865ce
      Dean Nelson authored 
      

These are SN2 only drivers.  They should have platform checks to prevent
them from doing evil stuff in GENERIC kernels.

Signed-off-by: default avatarMartin Hicks <mort@sgi.com>
Acked-by: default avatarDean Nelson <dcn@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      408865ce
    • Martin Hicks's avatar
      [IA64] defconfig: turn off QLOGIC_FC · 087f9026
      Martin Hicks authored 
      

Turn off the QLOGIC_FC driver.  Supposedly qla2xxx should support
these devices.  Do any ia64 machines have one of these devices as
the boot device?

Signed-off-by: default avatarMartin Hicks <mort@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      087f9026
    • Russell King's avatar
      [SERIAL] Use an enum for serial8250 platform device IDs · 6df29deb
      Russell King authored 
      

Rather than hard-coding the platform device IDs, enumerate them.
We don't particularly care about the actual ID we get, just as
long as they're unique.

Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      6df29deb