Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 4月, 2009 6 次提交
  3. 14 4月, 2009 1 次提交
  5. 06 4月, 2009 1 次提交
  7. 04 4月, 2009 1 次提交
    • T
      sh: sh7785lcr: Map whole PCI address space. · 68b42d1b
      由 Takashi Yoshii 提交于 
      PCI still doesn't work on sh7785lcr 29bit 256M map mode.

On SH7785, PCI -> SHwy address translation is not base+offset but
somewhat like base|offset (See HW Manual (rej09b0261) Fig. 13.11).
So, you can't export CS2,3,4,5 by 256M at CS2 (results CS0,1,2,3
exported, I guess).  There are two candidates.

a) 128M@CS2 + 128M@CS4
b) 512M@CS0

Attached patch is B. It maps 512M Byte at 0 independently of memory
size. It results CS0 to CS6 and perhaps some more being accessible
from PCI.

Tested on
7785lcr 29bit 128M map
7785lcr 29bit 256M map
(NOT tested on 32bit)
Signed-off-by: NTakashi YOSHII <yoshii.takashi@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      68b42d1b
  9. 10 3月, 2009 1 次提交
  11. 08 1月, 2009 2 次提交
  13. 22 12月, 2008 2 次提交
  15. 20 10月, 2008 1 次提交
  17. 29 7月, 2008 2 次提交
  19. 28 7月, 2008 4 次提交
  21. 28 6月, 2008 1 次提交
    • A
      PCI: remove unused arch pcibios_update_resource() functions · 0aea5313
      由 Adrian Bunk 提交于 
      Russell King did the following back in 2003:

<--  snip  -->

    [PCI] pci-9: Kill per-architecture pcibios_update_resource()

    Kill pcibios_update_resource(), replacing it with pci_update_resource().
    pci_update_resource() uses pcibios_resource_to_bus() to convert a
    resource to a device BAR - the transformation should be exactly the
    same as the transformation used for the PCI bridges.

    pci_update_resource "knows" about 64-bit BARs, but doesn't attempt to
    set the high 32-bits to anything non-zero - currently no architecture
    attempts to do something different.  If anyone cares, please fix; I'm
    going to reflect current behaviour for the time being.

    Ivan pointed out the following architectures need to examine their
    pcibios_update_resource() implementation - they should make sure that
    this new implementation does the right thing.  #warning's have been
    added where appropriate.

        ia64
        mips
        mips64

    This cset also includes a fix for the problem reported by AKPM where
    64-bit arch compilers complain about the resource mask being placed
    in a u32.

<--  snip  -->

This patch removes the unused pcibios_update_resource() functions the
kernel gained since, from FRV, m68k, mips & sh architectures.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Acked-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0aea5313
  23. 29 4月, 2008 1 次提交
  25. 21 4月, 2008 1 次提交
    • G
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      由 Greg Kroah-Hartman 提交于 
      We currently keep 2 lists of PCI devices in the system, one in the
driver core, and one all on its own.  This second list is sorted at boot
time, in "BIOS" order, to try to remain compatible with older kernels
(2.2 and earlier days).  There was also a "nosort" option to turn this
sorting off, to remain compatible with even older kernel versions, but
that just ends up being what we have been doing from 2.5 days...

Unfortunately, the second list of devices is not really ever used to 
determine the probing order of PCI devices or drivers[1].  That is done
using the driver core list instead.  This change happened back in the
early 2.5 days.

Relying on BIOS ording for the binding of drivers to specific device
names is problematic for many reasons, and userspace tools like udev
exist to properly name devices in a persistant manner if that is needed,
no reliance on the BIOS is needed.

Matt Domsch and others at Dell noticed this back in 2006, and added a
boot option to sort the PCI device lists (both of them) in a
breadth-first manner to help remain compatible with the 2.4 order, if
needed for any reason.  This option is not going away, as some systems
rely on them.

This patch removes the sorting of the internal PCI device list in "BIOS"
mode, as it's not needed at all anymore, and hasn't for many years.
I've also removed the PCI flags for this from some other arches that for
some reason defined them, but never used them.

This should not change the ordering of any drivers or device probing.

[1] The old-style pci_get_device and pci_find_device() still used this
sorting order, but there are very few drivers that use these functions,
as they are deprecated for use in this manner.  If for some reason, a
driver rely on the order and uses these functions, the breadth-first
boot option will resolve any problem.

Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
  27. 26 2月, 2008 1 次提交
  29. 14 2月, 2008 2 次提交
  31. 02 2月, 2008 1 次提交
  33. 28 1月, 2008 7 次提交
  35. 30 11月, 2007 2 次提交
  37. 07 11月, 2007 1 次提交
    • P
      sh: Kill off the remaining ST40 cruft. · f9669187
      由 Paul Mundt 提交于 
      The ST40 stuff in-tree hasn't built for some time, and hasn't been
updated for over 3 years. ST maintains their own out-of-tree changes
and rebases occasionally, and that's ultimately where all of the ST40
users go anyways.

In order for the ST40 code to be brought up to date most of the stuff
removed in this changeset would have to be rewritten anyways, so there's
very little benefit in keeping the remnants around either.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      f9669187
  39. 30 10月, 2007 1 次提交
  41. 17 10月, 2007 1 次提交