Skip to content

GitLab

Switch branch/tag
  1. 15 May, 2014 1 commit
    • Pawel Moll's avatar
      mfd: vexpress: Define the device as MFD cells · 974cc7b9
      Pawel Moll authored 
      
This patch - finally, after over 6 months! :-( - addresses
Samuel's request to split the vexpress-sysreg driver into
smaller portions and define the device in a form of MFD
cells:

* LEDs code has been completely removed and replaced with
  "gpio-leds" nodes in the tree (referencing dedicated
  GPIO subnodes in sysreg - bindings documentation updated);
  this also better fits the reality as some variants of the
  motherboard don't have all the LEDs populated

* syscfg bridge code has been extracted into a separate
  driver (placed in drivers/misc for no better place)

* all the ID & MISC registers are defined as sysconf
  making them available for other drivers should they need
  to use them (and also to the user via /sys/kernel/debug/regmap
  which can be helpful in platform debugging)
Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      974cc7b9
  3. 28 Feb, 2014 1 commit
  5. 19 Dec, 2013 1 commit
  7. 17 Oct, 2013 1 commit
  9. 26 Sep, 2013 1 commit
  11. 30 Apr, 2013 1 commit
    • Philipp Zabel's avatar
      misc: generic on-chip SRAM allocation driver · 4984c6f5
      Philipp Zabel authored 
      
This driver requests and remaps a memory region as configured in the
device tree.  It serves memory from this region via the genalloc API.  It
optionally enables the SRAM clock.

Other drivers can retrieve the genalloc pool from a phandle pointing to
this drivers' device node in the device tree.

The allocation granularity is hard-coded to 32 bytes for now, to make the
SRAM driver useful for the 6502 remoteproc driver.  There is overhead for
bigger SRAMs, where only a much coarser allocation granularity is needed:
At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap
to track allocations.

[akpm@linux-foundation.org: fix Kconfig text, make sram_init static]
Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: default avatarShawn Guo <shawn.guo@linaro.org>
Acked-by: default avatarGrant Likely <grant.likely@secretlab.ca>
Tested-by: default avatarMichal Simek <monstr@monstr.eu>
Cc: Dong Aisheng <dong.aisheng@linaro.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Huang Shijie <shijie8@gmail.com>
Cc: Javier Martin <javier.martin@vista-silicon.com>
Cc: Matt Porter <mporter@ti.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4984c6f5
  13. 25 Mar, 2013 1 commit
  15. 15 Mar, 2013 1 commit
  17. 17 Jan, 2013 1 commit
  19. 09 Jan, 2013 1 commit
  21. 20 Sep, 2012 1 commit
  23. 11 Jul, 2012 1 commit
  25. 09 May, 2012 1 commit
  27. 01 May, 2012 1 commit
  29. 18 Apr, 2012 1 commit
  31. 08 Jan, 2012 1 commit
  33. 23 Sep, 2011 1 commit
  35. 26 Jul, 2011 1 commit
  37. 01 Jul, 2011 1 commit
  39. 19 May, 2011 1 commit
    • Ira Snyder's avatar
      misc: Add CARMA DATA-FPGA Access Driver · c186f0e1
      Ira Snyder authored 
      
This driver allows userspace to access the data processing FPGAs on the
OVRO CARMA board. It has two modes of operation:

1) random access

This allows users to poke any DATA-FPGA registers by using mmap to map
the address region directly into their memory map.

2) correlation dumping

When correlating, the DATA-FPGA's have special requirements for getting
the data out of their memory before the next correlation. This nominally
happens at 64Hz (every 15.625ms). If the data is not dumped before the
next correlation, data is lost.

The data dumping driver handles buffering up to 1 second worth of
correlation data from the FPGAs. This lowers the realtime scheduling
requirements for the userspace process reading the device.
Signed-off-by: default avatarIra W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c186f0e1
  41. 13 May, 2011 1 commit
    • J Freyensee's avatar
      Intel PTI implementaiton of MIPI 1149.7. · 0b61d2ac
      J Freyensee authored 
      
The PTI (Parallel Trace Interface) driver directs
trace data routed from various parts in the system out
through an Intel Penwell PTI port and out of the mobile
device for analysis with a debugging tool (Lauterbach or Fido).
Though n_tracesink and n_tracerouter line discipline drivers
are used to extract modem tracing data to the PTI driver
and other parts of an Intel mobile solution, the PTI driver
can be used independent of n_tracesink and n_tracerouter.

You should select this driver if the target kernel is meant for
an Intel Atom (non-netbook) mobile device containing a MIPI
P1149.7 standard implementation.
Signed-off-by: default avatarJ Freyensee <james_p_freyensee@linux.intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0b61d2ac
  43. 23 Mar, 2011 1 commit
  45. 21 Mar, 2011 1 commit
  47. 28 Oct, 2010 1 commit
  49. 26 Oct, 2010 4 commits
  51. 22 Oct, 2010 1 commit
    • Masayuki Ohtak's avatar
      add Packet hub driver for Topcliff Platform controller hub · cf4ece53
      Masayuki Ohtak authored 
      
Packet hub driver of Topcliff PCH

Topcliff PCH is the platform controller hub that is going to be used in
Intel's upcoming general embedded platform. All IO peripherals in
Topcliff PCH are actually devices sitting on AMBA bus. Packet hub is
a special converter device in Topcliff PCH that translate AMBA transactions
to PCI Express transactions and vice versa. Thus packet hub helps present
all IO peripherals in Topcliff PCH as PCIE devices to IA system.
Topcliff PCH has MAC address and Option ROM data.
These data are in SROM which is connected to PCIE bus.
Packet hub driver of Topcliff PCH can access MAC address and Option ROM data in
SROM via sysfs interface.
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      cf4ece53
  53. 06 Oct, 2010 1 commit
  55. 23 Sep, 2010 1 commit
  57. 10 Aug, 2010 3 commits
  59. 26 Jul, 2010 1 commit
  61. 25 May, 2010 1 commit
  63. 24 Apr, 2010 1 commit
    • Dmitry Torokhov's avatar
      VMware Balloon driver · 453dc659
      Dmitry Torokhov authored 
      
This is a standalone version of VMware Balloon driver.  Ballooning is a
technique that allows hypervisor dynamically limit the amount of memory
available to the guest (with guest cooperation).  In the overcommit
scenario, when hypervisor set detects that it needs to shuffle some
memory, it instructs the driver to allocate certain number of pages, and
the underlying memory gets returned to the hypervisor.  Later hypervisor
may return memory to the guest by reattaching memory to the pageframes and
instructing the driver to "deflate" balloon.

We are submitting a standalone driver because KVM maintainer (Avi Kivity)
expressed opinion (rightly) that our transport does not fit well into
virtqueue paradigm and thus it does not make much sense to integrate with
virtio.

There were also some concerns whether current ballooning technique is the
right thing.  If there appears a better framework to achieve this we are
prepared to evaluate and switch to using it, but in the meantime we'd like
to get this driver upstream.

We want to get the driver accepted in distributions so that users do not
have to deal with an out-of-tree module and many distributions have
"upstream first" requirement.

The driver has been shipping for a number of years and users running on
VMware platform will have it installed as part of VMware Tools even if it
will not come from a distribution, thus there should not be additional
risk in pulling the driver into mainline.  The driver will only activate
if host is VMware so everyone else should not be affected at all.
Signed-off-by: default avatarDmitry Torokhov <dtor@vmware.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      453dc659
  65. 07 Apr, 2010 1 commit
  67. 13 Mar, 2010 1 commit
  69. 15 Dec, 2009 1 commit

Powered by Integricloud