1. 27 9月, 2006 1 次提交
    • A
      [MIPS] Fix for pci config_access on alchemy au1x000 · 32136568
      Alexander Bigga 提交于
      I've encountered a serious problem with PCI config space access on Au1x000
      platforms with recent 2.6.x-kernel. With 2.4.31 the same hardware works fine.
      So I was looking for the differences:
      
      Symptoms:
      - no PCI-device is seen on bootup though two or three cards are present
      - lspci output is empty
      - OR: lspci shows 20 times the same device
      (- OR: in some slot-configurations it worked anyhow)
      
      System(s):
      1. platform with Au1500 and three PCI-devices (actually a mycable XXS1500
          with backplane for three PCI-devices)
      2. platform with Au1550 and two PCI-devices (custom board)
      
      Debugging:
      I digged down to the config_access() of the au1xxx-processors in
      arch/mips/pci/ops-au1000.c and switched on DEBUG.
      
      The code of config_access() seems to be almost the same as of the
      2.4.x-kernel. But the "pci_cfg_vm->addr" returned by get_vm_area(0x2000, 0)
      once on booting is different. That's of course not forbidden. But the
      alignment seems to be wrong. In my case, I received:
      
      2.4.31: pci_cfg_vm->addr = c0000000
      2.6.18-rc5: pci_cfg_vm->addr = c0101000
      
      To make it short: With 2.6.x it fails on the first config-access with:
      "PCI ERR detected: status 83a00356".
      
      Fixup:
      My fix is now, to use the VM_IOREMAP-flag in the get_vm_area call. This flag
      seems to be introduced in mm/vmalloc.c a long time ago (in 2.6.7-bk13, I
      found in gitweb).
      Now, the returned address is pci_cfg_vm->addr = c0104000 and everything works
      fine.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      32136568
  2. 01 7月, 2006 1 次提交
  3. 30 10月, 2005 2 次提交
  4. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4