Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 2月, 2012 2 次提交
    • O
      rpmsg: depend on EXPERIMENTAL · 4ba60295
      由 Ohad Ben-Cohen 提交于 
      There isn't any binary change in sight or evidence of any stability
issue, but as we just begin to get traction we can't rule them out
completely.

To be on the safe side, let's mark rpmsg as EXPERIMENTAL, and remove
it later on after we have several happy users.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Rob Clark <rob@ti.com>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      4ba60295
    • O
      remoteproc: depend on EXPERIMENTAL · 489d129a
      由 Ohad Ben-Cohen 提交于 
      Remoteproc is still under development and as it gets traction we
definitely expect to do some changes in the binary format (most probably
only in the resource table, e.g. the upcoming move to TLV-based entries).

Active testing and use of remoteproc is most welcome, but we don't want
users to expect backward binary compatibility with the preliminary
images we have today.

Therefore mark remoteproc as EXPERIMENTAL, and explicitly inform the user
about this when a new remote processor is registered.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Rob Clark <rob@ti.com>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      489d129a
  3. 09 2月, 2012 13 次提交
    • O
      rpmsg: add Kconfig menu · f8289eda
      由 Ohad Ben-Cohen 提交于 
      Add a dedicated Kconfig menu for the rpmsg drivers, so they
don't show up in the main driver menu.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      f8289eda
    • O
      remoteproc: add Kconfig menu · 650d6561
      由 Ohad Ben-Cohen 提交于 
      Add a dedicated Kconfig menu for the remoteproc drivers, so they
don't show up in the main driver menu.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      650d6561
    • O
      remoteproc: look for truncated firmware images · 9bc91231
      由 Ohad Ben-Cohen 提交于 
      Make sure firmware isn't truncated before accessing its data.
Reported-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      9bc91231
    • O
      remoteproc/omap: utilize module_platform_driver · 63d667bf
      由 Ohad Ben-Cohen 提交于 
      Ditch some boilerplate code by employing the module_platform_driver
helper.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      63d667bf
    • O
      remoteproc: remove unused resource type · 2fd51811
      由 Ohad Ben-Cohen 提交于 
      RSC_VIRTIO_CFG isn't being used, so remove it.

Originally it was introduced to overcome a resource table limitation
that prevented describing a virtio device in a single resource table
entry.

The plan though is to describe resource table entries in a TLV fashion,
where each entry will consume the amount of space it requires,
so the original limitation is anyway temporary.
Reported-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      2fd51811
    • M
      remoteproc: avoid registering a virtio device if not supported · 7d2d3956
      由 Mark Grosen 提交于 
      Let remoteproc know when the firmware doesn't support any virtio
functionality, so registering a virtio device can be avoided.

This is needed for remote processors that doesn't require any
virtio-based communications, but are still controlled via remoteproc.

[ohad@wizery.com: write commit log]
Signed-off-by: NMark Grosen <mgrosen@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      7d2d3956
    • M
      remoteproc: do not require an iommu · 0798e1da
      由 Mark Grosen 提交于 
      Not all remote processors employ an IOMMU, so do not error out
on !iommu_present().

Note: we currently still use iommu_present() to tell whether we need
to configure an IOMMU or not. That works for simple cases, but will
easily fail with more complicated ones (e.g. where an IOMMU exists,
but not all remote processors use it). When those use cases show up,
we will solve them by introducing something like remoteproc hw
capabilities.

[ohad@wizery.com: write commit log]
Signed-off-by: NMark Grosen <mgrosen@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      0798e1da
    • O
      samples/rpmsg: add an rpmsg driver sample · 779b96d2
      由 Ohad Ben-Cohen 提交于 
      Add an rpmsg driver sample, which demonstrates how to communicate with
an AMP-configured remote processor over the rpmsg bus.

Note how once probed, the driver can immediately start sending messages
using the rpmsg_send() API, without having to worry about creating endpoints
or allocating rpmsg addresses: all that work is done by the rpmsg bus,
and the required information is already embedded in the rpmsg channel
that the driver is probed with.

In this sample, the driver simply sends a "Hello World!" message to the remote
processor repeatedly.

Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
      779b96d2
    • O
      rpmsg: add virtio-based remote processor messaging bus · bcabbcca
      由 Ohad Ben-Cohen 提交于 
      Add a virtio-based inter-processor communication bus, which enables
kernel drivers to communicate with entities, running on remote
processors, over shared memory using a simple messaging protocol.

Every pair of AMP processors share two vrings, which are used to send
and receive the messages over shared memory.

The header of every message sent on the rpmsg bus contains src and dst
addresses, which make it possible to multiplex several rpmsg channels on
the same vring.

Every rpmsg channel is a device on this bus. When a channel is added,
and an appropriate rpmsg driver is found and probed, it is also assigned
a local rpmsg address, which is then bound to the driver's callback.

When inbound messages carry the local address of a bound driver,
its callback is invoked by the bus.

This patch provides a kernel interface only; user space interfaces
will be later exposed by kernel users of this rpmsg bus.

Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au> (virtio_ids.h)
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
      bcabbcca
    • O
      remoteproc/omap: add a remoteproc driver for OMAP4 · 34ed5a33
      由 Ohad Ben-Cohen 提交于 
      Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and
and DSP subsystems.

Use the omap_device_* API to control the hardware state, and utilize
the OMAP mailbox to interrupt the remote processor when a new message
is pending (the mailbox payload is used to tell it which virtqueue was
the message placed in).

Conversely, when an inbound mailbox message arrives, tell the remoteproc
core which virtqueue is triggered.

Later we will also use the mailbox payload to signal omap-specific
events like remote crashes (which will be used to trigger remoteproc
recovery) and power management transitions. At that point we will also
extend the remoteproc core to support this.

Based on (but now quite far from) work done by Fernando Guzman Lugo
<fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>.

Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
      34ed5a33
    • O
      remoteproc: create rpmsg virtio device · ac8954a4
      由 Ohad Ben-Cohen 提交于 
      Create an rpmsg virtio device to allow message-based communication
with the remote processor (but only if supported by its firmware).

There are several advantages to provide this functionality at
the remoteproc-level:
- to support it, platforms only have to provide their own ->kick()
  handler; no need to duplicate the rest of the code.
- the virtio device is created only when the remote processor is
  registered and ready to go. No need to depend on initcall magic.
  moreover, we only add the virtio device if the firmware really
  supports it, and only after we know the supported virtio device features.
- correct device model hierarchy can be set, and that is useful
  for natural power management and DMA API behavior.
- when the remote processor crashes (or removed) we only need
  to remove the virtio device, and the driver core will take care of
  the rest. No need to implement any out-of-bound notifiers.
- we can now easily bind the virtio device to its rproc handle, and
  this way we don't need any name-based remoteproc ->get() API.

Currently we only support creating a single rpmsg virtio device per
remote processor, but later this is going to be extended to support
creating numerous virtio devices of other types too (block, net,
console...).

Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
      ac8954a4
    • O
      remoteproc: add debugfs entries · 6391a706
      由 Ohad Ben-Cohen 提交于 
      Expose several remote processor properties (name, state, trace buffer)
that are helpful for debugging.

This part is extracted to a separate patch just to keep the review load
down.

Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
      6391a706
    • O
      remoteproc: add framework for controlling remote processors · 400e64df
      由 Ohad Ben-Cohen 提交于 
      Modern SoCs typically employ a central symmetric multiprocessing (SMP)
application processor running Linux, with several other asymmetric
multiprocessing (AMP) heterogeneous processors running different instances
of operating system, whether Linux or any other flavor of real-time OS.

Booting a remote processor in an AMP configuration typically involves:
- Loading a firmware which contains the OS image
- Allocating and providing it required system resources (e.g. memory)
- Programming an IOMMU (when relevant)
- Powering on the device

This patch introduces a generic framework that allows drivers to do
that. In the future, this framework will also include runtime power
management and error recovery.

Based on (but now quite far from) work done by Fernando Guzman Lugo
<fernando.lugo@ti.com>.

ELF loader was written by Mark Grosen <mgrosen@ti.com>, based on
msm's Peripheral Image Loader (PIL) by Stephen Boyd <sboyd@codeaurora.org>.

Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
      400e64df
  5. 20 1月, 2012 10 次提交
  7. 19 1月, 2012 15 次提交