1. 07 9月, 2005 1 次提交
  2. 05 9月, 2005 2 次提交
  3. 11 7月, 2005 1 次提交
  4. 04 7月, 2005 1 次提交
  5. 27 6月, 2005 3 次提交
  6. 26 6月, 2005 1 次提交
  7. 25 6月, 2005 3 次提交
  8. 21 6月, 2005 1 次提交
    • L
      [PATCH] ARM: 2701/1: free up ixp2000 timer 4 for the watchdog · e4fe1981
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      The IXP2000 has four timers, but if we're on an A-step IXP2800, timer
      2 and 3 don't work.  We need two timers for timekeeping (one for the
      timer interrupt and one for tracking missed jiffies), so on early
      IXP2800s we have no other choice but to use timer 1 and 4 for that,
      but on all other IXP2000s we'd rather leave timer 4 free since that's
      the only timer we can use for the watchdog.
      So, on buggy IXP2000s (i.e. the A-step IXP2800) we use timer 4 for
      tracking missed jiffies, and on all all non-buggy IXP2000s (i.e.
      everything but the A-step IXP2800) we use timer 2.
      On a pre-production IXP2800, this patch should print these messages
      on boot:
      	Enabling IXP2800 erratum #25 workaround
      	Unable to use IXP2000 watchdog due to IXP2800 erratum #25
      On any non-buggy IXP2800 (as well as on IXP2400s) you shouldn't see
      anything at all, and the watchdog should be usable again.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e4fe1981
  9. 30 4月, 2005 4 次提交
    • L
      [PATCH] ARM: 2660/2: fix ixdp2800 boot and pci init · 53e173f6
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      The IXDP2800 is an evalution platform for the IXP2800 processor that
      has two IXP2800s connected to the same PCI bus.  This is problematic
      as both CPUs will try to configure the PCI bus as they boot linux.
      Contrary to on the other IXP2000 platforms, the boot loader on the
      IXDP2800 doesn't configure the PCI bus properly, so we do want the
      linux instance on one of the CPUs to do that.
      Making one of the CPUs ignore the PCI bus (and thus act like a pure
      PCI slave device) is not an option because there is a 82559 NIC on
      the PCI bus for each of the CPUs.
      The chosen solution is to have the master CPU configure the PCI bus
      while the slave is kept in a quiescent state, and then to have the
      slave CPU scan the PCI bus (without assigning resources) while the
      master is kept in a quiescent state.  After this ritual, the master
      deletes the slave NIC from its PCI device list, the slave deletes
      the master NIC from its device list, and (almost) all is well.
      There's still one little problem: each of the CPUs has a 1G SDRAM
      BAR, but the IXP2000 only has 512M of outbound PCI memory window.
      We solve this by hand-assigning the master and slave SDRAM BARs to
      a location outside each of the IXP's outbound PCI windows, and by
      having the rest of the BARs autoconfigured in the outbound PCI
      windows, in the range [e0000000..ffffffff], so that there is a 1:1
      pci:phys mapping between them.
      Even with this patch, a number of issues still remain -- just imagine
      what happens if one of the CPUs is rebooted, by watchdog or by hand,
      but the other one isn't.  But those issues are not easily fixable
      given the strange PCI layout of this board and the behavior of the
      boot loader shipped with the platform.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      53e173f6
    • L
      [PATCH] ARM: 2659/1: do not assign PCI I/O address zero on IXP2000 · 458a83fa
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      Assigning the address zero to a PCI device BAR causes some part of the
      PCI subsystem to believe that resource allocation for that BAR failed
      due to resource conflicts, which will make attempts to enable the
      device fail.  Work around this by assigning I/O addresses starting
      from 00010000.
      While we're at it, make the PCI I/O resource end at 0001ffff, since we
      only have 64k of outbound I/O window on the IXP2000, and we don't do
      bank switching.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      458a83fa
    • L
      [PATCH] ARM: 2658/1: start ixp2000 pci memory resource at 0xe0000000 · ae36bf58
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      On the IXDP2800, the bootloader does an awful job of configuring
      the PCI bus, so we make linux reconfigure everything.  Having a 1:1
      pci:phys address mapping generally simplifies everything, so try to
      allocate PCI addresses from the [e0000000..ffffffff] range, which is
      the physical address range of the outbound PCI window on the IXP2000.
      This does not affect any of the other IXP2000 platforms since they
      all use their bootloader's PCI resource assignment.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ae36bf58
    • L
      [PATCH] ARM: 2657/1: export ixp2000_pci_config_addr · 8443b165
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      Export ixp2000_pci_config_addr, to be used by the IXDP2800 platform
      setup code to coordinate booting the master and slave NPU.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8443b165
  10. 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