| Age | Commit message (Collapse) | Author |
|---|
|
Having received another series of whitespace patches I decided to do this
once and for all rather than dealing with this kind of patches trickling
in forever.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.
This change removes the use of __devinit, __devexit_p, __devinitdata,
and __devexit from these drivers.
Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Tell the PCI core about host bridge address translation so it can take
care of bus-to-resource conversion for us.
Here's the wrinkle on Cobalt: we can't generate normal I/O port addresses
on PCI because the GT-64111 doesn't do any address translation, so we have
this:
CPU I/O port addresses [io 0x0000-0xffffff]
PCI bus I/O port addresses [io 0x10000000-0x10ffffff]
Legacy-mode IDE controllers start out with the legacy bus addresses, e.g.,
0x1f0, assigned by pci_setup_device(). These are outside the range of
addresses GT-64111 can generate on PCI, but pcibios_fixup_device_resources()
converted them to CPU addresses anyway by adding io_offset. Therefore, we
had to pre-adjust them in cobalt_legacy_ide_fixup().
With io_offset = 0xf0000000, we had this:
res->start = 0x1f0 initialized in pci_setup_device()
res->start = 0x100001f0 -= io_offset in cobalt_legacy_ide_fixup()
res->start = 0x1f0 += io_offset in pcibios_fixup_device_resources()
The difference after this patch is that the generic pci_bus_to_resource()
only adds the offset if the bus address is inside a host bridge window.
Since 0x1f0 is not a valid bus address and is not inside any windows, it is
unaffected, so we now have this:
region->start = 0x1f0 initialized in pci_setup_device()
res->start = 0x1f0 no offset by pci_bus_to_resource()
That means we can remove both pcibios_fixup_device_resources() and
cobalt_legacy_ide_fixup().
I would *rather* set the host bridge offset to zero (which corresponds
to what the GT-64111 actually does), and have both CPU and PCI addresses
of [io 0x10000000-0x10ffffff]. However, that would require changes to
generic code that assumes legacy I/O addresses, such as pic1_io_resource
([io 0x0020-0x00021]), and we'd have to keep a Cobalt IDE fixup.
Of course, none of this changes the fact that references to I/O port
0x1f0 actually go to port 0x100001f0, not 0x1f0, on the Cobalt PCI bus.
Fortunately the VT82C586 IDE controller only decodes the low 24 address
bits, so it does work.
CC: Ralf Baechle <ralf@linux-mips.org>
CC: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
|
The GT-64111 PCI host bridge has no address translation mechanism, so
it can't generate legacy port accesses. This quirk fixes legacy device
port resources to contain the bus addresses actually generated by the
GT-64111.
I think this is the approach Ben Herrenschmidt suggested long ago:
http://marc.info/?l=linux-kernel&m=119733290624544&w=2
This allows us to remove the IORESOURCE_PCI_FIXED hack from
pcibios_fixup_device_resources(), which converts bus addresses to CPU
addresses. IORESOURCE_PCI_FIXED denotes resources that can't be moved;
it has nothing to do with converting bus to CPU addresses.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Yoichi Yuasa <yuasa@linux-mips.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-mips@linux-mips.org
Tested-by: Yoichi Yuasa <yuasa@linux-mips.org>
Patchwork: http://patchwork.linux-mips.org/patch/998/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
RAQ1 uses the same interrupt routing as Qube2.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
These PCI definitions are only used in arch/mips/pci/fixup-cobalt.c.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Instead of all drivers reading pci config space to get the revision
ID, they can now use the pci_device->revision member.
This exposes some issues where drivers where reading a word or a dword
for the revision number, and adding useless error-handling around the
read. Some drivers even just read it for no purpose of all.
In devices where the revision ID is being copied over and used in what
appears to be the equivalent of hotpath, I have left the copy code
and the cached copy as not to influence the driver's performance.
Compile tested with make all{yes,mod}config on x86_64 and i386.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This is to break the code of people who think they are supposed to scribble
into the pci device structure - it's off limits.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
This patch has reworked cobalt_board_id.
The cobalt_board_id is read from PCI config register.
It should be in PCI routine.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
This patch has rewritten GALILEO_INL/GALILEO_OUTL using GT_READ/GT_WRITE.
This patch tested on Cobalt Qube2.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
