1. 20 8月, 2009 1 次提交
  2. 28 4月, 2009 1 次提交
  3. 11 3月, 2009 2 次提交
  4. 23 2月, 2009 1 次提交
  5. 23 12月, 2008 2 次提交
  6. 22 7月, 2008 3 次提交
  7. 24 4月, 2008 1 次提交
  8. 06 2月, 2008 1 次提交
  9. 28 12月, 2007 1 次提交
  10. 11 10月, 2007 1 次提交
    • D
      Device tree aware EMAC driver · 1d3bb996
      David Gibson 提交于
      Based on BenH's earlier work, this is a new version of the EMAC driver
      for the built-in ethernet found on PowerPC 4xx embedded CPUs.  The
      same ASIC is also found in the Axon bridge chip.  This new version is
      designed to work in the arch/powerpc tree, using the device tree to
      probe the device, rather than the old and ugly arch/ppc OCP layer.
      
      This driver is designed to sit alongside the old driver (that lies in
      drivers/net/ibm_emac and this one in drivers/net/ibm_newemac).  The
      old driver is left in place to support arch/ppc until arch/ppc itself
      reaches its final demise (not too long now, with luck).
      
      This driver still has a number of things that could do with cleaning
      up, but I think they can be fixed up after merging.  Specifically:
      	- Should be adjusted to properly use the dma mapping API.
      Axon needs this.
      	- Probe logic needs reworking, in conjuction with the general
      probing code for of_platform devices.  The dependencies here between
      EMAC, MAL, ZMII etc. make this complicated.  At present, it usually
      works, because we initialize and register the sub-drivers before the
      EMAC driver itself, and (being in driver code) runs after the devices
      themselves have been instantiated from the device tree.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      1d3bb996
  11. 21 7月, 2007 1 次提交
  12. 09 5月, 2007 1 次提交
  13. 13 4月, 2007 1 次提交
  14. 22 3月, 2007 1 次提交
  15. 25 10月, 2006 2 次提交
  16. 05 10月, 2006 1 次提交
    • B
      [POWERPC] spufs: cell spu problem state mapping updates · 27d5bf2a
      Benjamin Herrenschmidt 提交于
      This patch adds a new "psmap" file to spufs that allows mmap of all of
      the problem state mapping of SPEs. It is compatible with 64k pages. In
      addition, it removes mmap ability of individual files when using 64k
      pages, with the exception of signal1 and signal2 which will both map the
      entire 64k page holding both registers. It also removes
      CONFIG_SPUFS_MMAP as there is no point in not building mmap support in
      spufs.
      
      It goes along a separate patch to libspe implementing usage of that new
      file to access problem state registers.
      
      Another patch will follow up to fix races opened up by accessing
      the 'runcntl' register directly, which is made possible with this
      patch.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      27d5bf2a
  17. 28 6月, 2006 1 次提交
  18. 21 6月, 2006 2 次提交
  19. 02 5月, 2006 1 次提交
  20. 27 3月, 2006 1 次提交
    • M
      [PATCH] spufs: enable SPE problem state MMIO access. · 6df10a82
      Mark Nutter 提交于
      This patch is layered on top of CONFIG_SPARSEMEM
      and is patterned after direct mapping of LS.
      
      This patch allows mmap() of the following regions:
      "mfc", which represents the area from [0x3000 - 0x3fff];
      "cntl", which represents the area from [0x4000 - 0x4fff];
      "signal1" which begins at offset 0x14000; "signal2" which
      begins at offset 0x1c000.
      
      The signal1 & signal2 files may be mmap()'d by regular user
      processes.  The cntl and mfc file, on the other hand, may
      only be accessed if the owning process has CAP_SYS_RAWIO,
      because they have the potential to confuse the kernel
      with regard to parallel access to the same files with
      regular file operations: the kernel always holds a spinlock
      when accessing registers in these areas to serialize them,
      which can not be guaranteed with user mmaps,
      Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6df10a82
  21. 09 1月, 2006 1 次提交