Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
“716c61c87556234570827b1d287f20691271a0b6”上不存在“git@gitcode.net:openeuler/kernel.git”
切换分支/标签
  1. 17 10月, 2013 1 次提交
  3. 30 4月, 2013 1 次提交
    • P
      misc: generic on-chip SRAM allocation driver · 4984c6f5
      由 Philipp Zabel 提交于 
      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: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Tested-by: NMichal 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4984c6f5
  5. 26 3月, 2013 1 次提交
  7. 16 3月, 2013 1 次提交
  9. 18 1月, 2013 1 次提交
  11. 09 1月, 2013 1 次提交
  13. 20 9月, 2012 1 次提交
  15. 12 7月, 2012 1 次提交
  17. 10 5月, 2012 1 次提交
  19. 02 5月, 2012 1 次提交
  21. 19 4月, 2012 1 次提交
  23. 09 1月, 2012 1 次提交
  25. 24 9月, 2011 1 次提交
  27. 26 7月, 2011 1 次提交
  29. 02 7月, 2011 1 次提交
  31. 19 5月, 2011 1 次提交
    • I
      misc: Add CARMA DATA-FPGA Access Driver · c186f0e1
      由 Ira Snyder 提交于 
      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: NIra W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c186f0e1
  33. 14 5月, 2011 1 次提交
    • J
      Intel PTI implementaiton of MIPI 1149.7. · 0b61d2ac
      由 J Freyensee 提交于 
      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: NJ Freyensee <james_p_freyensee@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0b61d2ac
  35. 23 3月, 2011 1 次提交
  37. 22 3月, 2011 1 次提交
  39. 29 10月, 2010 1 次提交
  41. 27 10月, 2010 4 次提交
  43. 23 10月, 2010 1 次提交
    • M
      add Packet hub driver for Topcliff Platform controller hub · cf4ece53
      由 Masayuki Ohtak 提交于 
      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: NGreg Kroah-Hartman <gregkh@suse.de>
      cf4ece53
  45. 06 10月, 2010 1 次提交
  47. 23 9月, 2010 1 次提交
  49. 10 8月, 2010 3 次提交
  51. 26 7月, 2010 1 次提交
  53. 25 5月, 2010 1 次提交
  55. 25 4月, 2010 1 次提交
    • D
      VMware Balloon driver · 453dc659
      由 Dmitry Torokhov 提交于 
      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: NDmitry 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      453dc659
  57. 07 4月, 2010 1 次提交
  59. 14 3月, 2010 1 次提交
  61. 16 12月, 2009 3 次提交
  63. 07 12月, 2009 1 次提交
  65. 20 10月, 2009 1 次提交