Skip to content

GitLab

Switch branch/tag
  1. 18 Jan, 2013 1 commit
    • Jon Mason's avatar
      PCI-Express Non-Transparent Bridge Support · fce8a7bb
      Jon Mason authored 
      
A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
connecting 2 systems, providing electrical isolation between the two subsystems.
A non-transparent bridge is functionally similar to a transparent bridge except
that both sides of the bridge have their own independent address domains.  The
host on one side of the bridge will not have the visibility of the complete
memory or I/O space on the other side of the bridge.  To communicate across the
non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
the local system.  Writes to these apertures are mirrored to memory on the
remote system.  Communications can also occur through the use of doorbell
registers that initiate interrupts to the alternate domain, and scratch-pad
registers accessible from both sides.

The NTB device driver is needed to configure these memory windows, doorbell, and
scratch-pad registers as well as use them in such a way as they can be turned
into a viable communication channel to the remote system.  ntb_hw.[ch]
determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
the underlying hardware to provide access and a common interface to the doorbell
registers, scratch pads, and memory windows.  These hardware interfaces are
exported so that other, non-mainlined kernel drivers can access these.
ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
communication channel(s) and provide a reliable way of transferring data from
one side to the other, which it then exports so that "client" drivers can access
them.  These client drivers are used to provide a standard kernel interface
(i.e., Ethernet device) to NTB, such that Linux can transfer data from one
system to the other in a standard way.
Signed-off-by: default avatarJon Mason <jon.mason@intel.com>
Reviewed-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fce8a7bb
  3. 05 Jan, 2013 18 commits
  5. 28 Dec, 2012 1 commit
  7. 18 Dec, 2012 5 commits
  9. 17 Dec, 2012 1 commit
    • Tony Lindgren's avatar
      MAINTAINERS: Add an entry for omap related .dts files · 50f29fbd
      Tony Lindgren authored 
      
All your omap .dts files are belong to us.

Benoît has been doing a good job picking up most of the
omap .dts files so far. Let's make sure we both get
cc:ed for the related patches.

The .dts patches need to be queued by us as separate
patches from drivers and other code changes to avoid
pointless merge conflists like we saw with v3.8
networking changes.

Cc: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      50f29fbd
  11. 16 Dec, 2012 1 commit
  13. 12 Dec, 2012 1 commit
    • Ralf Baechle's avatar
      MIPS: Cavium: Add EDAC support. · f65aad41
      Ralf Baechle authored 
      
Drivers for EDAC on Cavium.  Supported subsystems are:

 o CPU primary caches.  These are parity protected only, so only error
   reporting.
 o Second level cache - ECC protected, provides SECDED.
 o Memory: ECC / SECDEC if used with suitable DRAM modules.  The driver will
   will only initialize if ECC is enabled on a system so is safe to run on
   non-ECC memory.
 o PCI: Parity error reporting

Since it is very hard to test this sort of code the implementation is very
conservative and uses polling where possible for now.
Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
Reviewed-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      f65aad41
  15. 11 Dec, 2012 2 commits
  17. 06 Dec, 2012 4 commits
  19. 03 Dec, 2012 1 commit
  21. 30 Nov, 2012 2 commits
  23. 29 Nov, 2012 1 commit
  25. 28 Nov, 2012 1 commit
  27. 27 Nov, 2012 1 commit