Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 1月, 2016 1 次提交
  3. 26 11月, 2015 1 次提交
    • S
      remoteproc: fix memory leak of remoteproc ida cache layers · f42f79af
      由 Suman Anna 提交于 
      The remoteproc core uses a static ida named rproc_dev_index for
assigning an automatic index number to a registered remoteproc.
The ida core may allocate some internal idr cache layers and ida
bitmap upon any ida allocation, and all these layers are truely
freed only upon the ida destruction. The rproc_dev_index ida is
not destroyed at present, leading to a memory leak when using the
remoteproc core as a module and atleast one rproc device is
registered and unregistered.

Fix this by invoking ida_destroy() in the remoteproc core module
exit.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      f42f79af
  5. 18 6月, 2015 1 次提交
  7. 17 6月, 2015 2 次提交
    • S
      remoteproc: add a rproc ops for performing address translation · a01f7cd6
      由 Suman Anna 提交于 
      The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts allocated within the
core.

A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
processing if the platform implementation cannot provide the translation.
This will allow any remoteproc implementations to translate addresses for
dedicated memories like internal memories.

While at this, also update the rproc_da_to_va() documentation since it
is an exported function.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      a01f7cd6
    • D
      remoteproc: introduce rproc_get_by_phandle API · fec47d86
      由 Dave Gerlach 提交于 
      Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.

This patch uses the code removed by commit 40e575b1 ("remoteproc:
remove the get_by_name/put API") for the ref counting but is modified
to use a simple list and locking mechanism and has rproc_get_by_name
replaced with an rproc_get_by_phandle API.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
[fix order of Signed-off-by tags]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      fec47d86
  9. 02 5月, 2015 1 次提交
    • S
      remoteproc: fix various checkpatch warnings · 172e6ab1
      由 Suman Anna 提交于 
      Fix all the checkpatch warnings in the core remoteproc
code. The fixes cover the following warnings:
  1. WARNING: void function return statements are not generally useful
  2. WARNING: Possible unnecessary 'out of memory' message
  3. WARNING: line over 80 characters
  4. WARNING: braces {} are not necessary for single statement blocks
  5. WARNING: Unnecessary space before function pointer arguments
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      172e6ab1
  11. 12 3月, 2015 1 次提交
    • S
      remoteproc: add IOMMU hardware capability flag · 315491e5
      由 Suman Anna 提交于 
      The remoteproc framework currently relies on iommu_present() on
the bus the device is on, to perform MMU management. However, this
logic doesn't scale for multi-arch, especially for processors that
do not have an IOMMU. Replace this logic instead by using a h/w
capability flag for the presence of IOMMU in the rproc structure.

This issue is seen on OMAP platforms when trying to add a remoteproc
driver for a small Cortex M3 called the WkupM3 used for suspend /
resume management on TI AM335/AM437x SoCs. This processor does not
have an MMU. Same is the case with another processor subsystem
PRU-ICSS on AM335/AM437x. All these are platform devices, and the
current iommu_present check will not scale for the same kernel image
to support OMAP4/OMAP5 and AM335/AM437x.

The existing platform implementation drivers - OMAP remoteproc, STE
Modem remoteproc and DA8xx remoteproc, are updated as well to properly
configure the newly added rproc field.

Cc: Robert Tivy <rtivy@ti.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSuman Anna <s-anna@ti.com>
[small change in the commit title and in a single comment]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      315491e5
  13. 01 7月, 2013 2 次提交
  15. 30 6月, 2013 1 次提交
  17. 24 4月, 2013 1 次提交
  19. 07 4月, 2013 5 次提交
  21. 05 4月, 2013 3 次提交
  23. 28 2月, 2013 2 次提交
  25. 02 10月, 2012 2 次提交
    • E
      remoteproc: Fix use of format specifyer · d09f53a7
      由 Emil Goode 提交于 
      The dma_addr_t type can be either u32 or u64 depending on
the configuration. We should use a format specifyer for the
larger type and explicitly cast to it.

Sparse warnings:
drivers/remoteproc/remoteproc_core.c:234:2: warning:
	format ‘%x’ expects argument of type ‘unsigned int’,
	but argument 6 has type ‘dma_addr_t’ [-Wformat]

drivers/remoteproc/remoteproc_core.c:596:2: warning:
	format ‘%x’ expects argument of type ‘unsigned int’,
	but argument 5 has type ‘dma_addr_t’ [-Wformat]

drivers/remoteproc/remoteproc_core.c:634:3:
	warning: format ‘%x’ expects argument of type ‘unsigned int’,
	but argument 5 has type ‘dma_addr_t’ [-Wformat]
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
[fix commit log typos]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      d09f53a7
    • D
      remoteproc: fix a potential NULL-dereference on cleanup · 7168d914
      由 Dan Carpenter 提交于 
      We only need to allocate mapping if there is an IOMMU domain.

Otherwise, when the mappings are released, the assumption that
an IOMMU domain is there will crash and burn.

CC: stable@vger.kernel.org
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
[ohad: revise commit log]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      7168d914
  27. 19 9月, 2012 1 次提交
  29. 18 9月, 2012 3 次提交
    • F
      remoteproc: create a 'recovery' debugfs entry · 2e37abb8
      由 Fernando Guzman Lugo 提交于 
      Add a 'recovery' debugfs entry to dynamically disable/enable recovery
at runtime. This is useful when one is trying to debug an rproc crash;
without it, a recovery will immediately take place, making it harder
to debug the crash.

Contributions from Subramaniam Chanderashekarapuram.

Examples:

- disabling recovery:
$ echo disabled > <debugfs>/remoteproc/remoteproc0/recovery

- in case you want to recover a crash, but keep recovery disabled
  (useful in debugging sessions when you expect additional crashes
   you want to debug):
$ echo recover > <debugfs>/remoteproc/remoteproc0/recovery

- enabling recovery:
$ echo enabled > <debugfs>/remoteproc/remoteproc0/recovery
Signed-off-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
[ohad: some white space, commentary and commit log changes]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      2e37abb8
    • F
      remoteproc: add actual recovery implementation · 70b85ef8
      由 Fernando Guzman Lugo 提交于 
      Add rproc_trigger_recovery() which takes care of the recovery itself,
by removing, and re-adding, all of the remoteproc's virtio devices.

This resets all virtio users of the remote processor, during which
the remote processor is powered off and on again.
Signed-off-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
[ohad: introduce rproc_add_virtio_devices to avoid 1.copying code 2.anomaly]
[ohad: some white space, naming and commit log changes]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      70b85ef8
    • F
      remoteproc: add rproc_report_crash function to notify rproc crashes · 8afd519c
      由 Fernando Guzman Lugo 提交于 
      Allow low-level remoteproc drivers to report rproc crashes by exporting
a new rproc_report_crash() function (invoking this from non-rproc drivers
is probably wrong, and should be carefully scrutinized if ever needed).

rproc_report_crash() can be called from any context; it offloads the
tasks of handling the crash to a separate thread.

Handling the crash from a separate thread is helpful because:
- Ability to call invoke rproc_report_crash() from atomic context, due to
  the fact that many crashes trigger an interrupt, so this function can be
  called directly from ISR context.
- Avoiding deadlocks which could happen if rproc_report_crash() is called
  from a function which indirectly holds the rproc lock.

Handling the crash might involve:
- Remoteproc register dump
- Remoteproc stack dump
- Remoteproc core dump
- Saving Remoteproc traces so they can be read after the crash
- Reseting the remoteproc in order to make it functional again (hard recovery)

Right now, we only print the crash type which was detected, and only the
mmufault type is supported. Remoteproc low-level drivers can add more types
when needed.
Signed-off-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
[ohad: some commentary, white space and commit log changes]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      8afd519c
  31. 15 7月, 2012 4 次提交
  33. 06 7月, 2012 6 次提交
    • O
      remoteproc: adopt the driver core's alloc/add/del/put naming · 160e7c84
      由 Ohad Ben-Cohen 提交于 
      To make remoteproc's API more intuitive for developers, we adopt
the driver core's naming, i.e. alloc -> add -> del -> put. We'll also
add register/unregister when their first user shows up.

Otherwise - there's no functional change here.

Suggested by Russell King <linux@arm.linux.org.uk>.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      160e7c84
    • O
      remoteproc: remove the get_by_name/put API · 40e575b1
      由 Ohad Ben-Cohen 提交于 
      Remove rproc_get_by_name() and rproc_put(), and the associated
remoteproc infrastructure that supports it (i.e. klist and friends),
because:

1. No one uses them
2. Using them is highly discouraged, and any potential user
   will be deeply scrutinized and encouraged to move.

If a user, that absolutely can't live with the direct boot/shutdown
model, does show up one day, then bringing this functionality back
is going to be trivial.

At this point though, keeping this functionality around is way too
much of a maintenance burden.

Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
Cc: Loic Pallardy <loic.pallardy@stericsson.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Mark Grosen <mgrosen@ti.com>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      40e575b1
    • O
      remoteproc: support non-iommu carveout assignment · 0e49b72c
      由 Ohad Ben-Cohen 提交于 
      Publish carveout addresses on non-iommu setups too.
Reported-and-acked-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      0e49b72c
    • O
      remoteproc: simplify unregister/free interfaces · c6b5a276
      由 Ohad Ben-Cohen 提交于 
      Simplify the unregister/free interfaces, and make them easier
to understand and use, by moving to a symmetric and consistent
alloc() -> register() -> unregister() -> free() flow.

To create and register an rproc instance, one needed to invoke
rproc_alloc() followed by rproc_register().

To unregister and free an rproc instance, one now needs to invoke
rproc_unregister() followed by rproc_free().

Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      c6b5a276
    • O
      remoteproc: remove the now-redundant kref · 7183a2a7
      由 Ohad Ben-Cohen 提交于 
      Now that every rproc instance contains a device, we don't need a
kref anymore to maintain the refcount of the rproc instances:
that's what device are good with!

This patch removes the now-redundant kref, and switches to
{get, put}_device instead of kref_{get, put}.

We also don't need the kref's release function anymore, and instead,
we just utilize the class's release handler (which is now responsible
for all memory de-allocations).

Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      7183a2a7
    • O
      remoteproc: maintain a generic child device for each rproc · b5ab5e24
      由 Ohad Ben-Cohen 提交于 
      For each registered rproc, maintain a generic remoteproc device whose
parent is the low level platform-specific device (commonly a pdev, but
it may certainly be any other type of device too).

With this in hand, the resulting device hierarchy might then look like:

omap-rproc.0
 |
 - remoteproc0  <---- new !
    |
    - virtio0
    |
    - virtio1
       |
       - rpmsg0
       |
       - rpmsg1
       |
       - rpmsg2

Where:
- omap-rproc.0 is the low level device that's bound to the
  driver which invokes rproc_register()
- remoteproc0 is the result of this patch, and will be added by the
  remoteproc framework when rproc_register() is invoked
- virtio0 and virtio1 are vdevs that are registered by remoteproc
  when it realizes that they are supported by the firmware
  of the physical remote processor represented by omap-rproc.0
- rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
  channels, and are registerd by the rpmsg bus when it gets notified
  about their existence

Technically, this patch:
- changes 'struct rproc' to contain this generic remoteproc.x device
- creates a new "remoteproc" type, to which this new generic remoteproc.x
  device belong to.
- adds a super simple enumeration method for the indices of the
  remoteproc.x devices
- updates all dev_* messaging to use the generic remoteproc.x device
  instead of the low level platform-specific device
- updates all dma_* allocations to use the parent of remoteproc.x (where
  the platform-specific memory pools, most commonly CMA, are to be found)

Adding this generic device has several merits:
- we can now add remoteproc runtime PM support simply by hooking onto the
  new "remoteproc" type
- all remoteproc log messages will now carry a common name prefix
  instead of having a platform-specific one
- having a device as part of the rproc struct makes it possible to simplify
  refcounting (see subsequent patch)

Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
with the (upcoming) runtime PM support for remoteproc.

Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      b5ab5e24
  35. 04 7月, 2012 1 次提交
    • O
      remoteproc: allocate vrings on demand, free when not needed · 6db20ea8
      由 Ohad Ben-Cohen 提交于 
      Dynamically allocate the vrings' DMA when the remote processor
is about to be powered on (i.e. when ->find_vqs() is invoked),
and release them as soon as it is powered off (i.e. when ->del_vqs()
is invoked).

The obvious and immediate benefit is better memory utilization, since
memory for the vrings is now only allocated when the relevant remote
processor is used.

Additionally, this approach also makes recovery of a (crashing)
remote processor easier: one just needs to remove the relevant
vdevs, and the entire vrings cleanup takes place automagically.
Tested-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      6db20ea8
  37. 10 6月, 2012 2 次提交