27 Jul, 2012
1 commit
-
Pull remoteproc update from Ohad Ben-Cohen:
- custom binary format support from Sjur Brændeland
- groundwork for recovery and runtime pm support
- some cleanups and API simplificationsFix up conflicts in drivers/remoteproc/remoteproc_core.c due to clashes
with earlier cleanups by Sjur Brændeland (with part of the cleanups
moved into the new remoteproc_elf_loader.c file).* tag 'remoteproc-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc:
MAINTAINERS: add remoteproc's git
remoteproc: Support custom firmware handlers
remoteproc: Move Elf related functions to separate file
remoteproc: Add function rproc_get_boot_addr
remoteproc: Pass struct fw to load_segments and find_rsc_table.
remoteproc: adopt the driver core's alloc/add/del/put naming
remoteproc: remove the get_by_name/put API
remoteproc: support non-iommu carveout assignment
remoteproc: simplify unregister/free interfaces
remoteproc: remove the now-redundant kref
remoteproc: maintain a generic child device for each rproc
remoteproc: allocate vrings on demand, free when not needed
15 Jul, 2012
4 commits
-
Firmware handling is made customizable.
This is done by creating a separate ops structure for the
firmware functions that depends on a particular firmware
format (such as ELF). The ELF functions are default used
unless the HW driver explicitly injects another firmware
handler by updating rproc->fw_ops.
The function rproc_da_to_va() is exported, as custom
firmware handlers may need to use this function.Signed-off-by: Sjur Brændeland
[ohad: namespace fixes, whitespace fixes, style fixes]
Signed-off-by: Ohad Ben-Cohen -
Prepare for introduction of custom firmware loaders by
moving all ELF related handling into a separate file.The functions: rproc_find_rsc_table(), rproc_fw_sanity_check(),
rproc_find_rsc_table() and rproc_get_boot_addr() are moved
to the new file remoteproc_elf_loader.c. The function
rproc_da_to_va() is made non-static and is declared in
remoteproc_internal.hNo functional changes are introduced in this patch.
Signed-off-by: Sjur Brændeland
[ohad: rebase, fix kerneldoc, put prototypes in remoteproc_internal.h]
Signed-off-by: Ohad Ben-Cohen -
Prepare for introduction of custom firmware loaders by
moving the function operating on ELF data-structures into
separate functions. Move lookup of the boot_addr in the
ELF binary to the function rproc_get_boot_addr().Signed-off-by: Sjur Brændeland
[rproc_get_boot_addr's kerneldoc: add missing @rproc line]
[rproc_get_boot_addr's kerneldoc: minor style changes]
Signed-off-by: Ohad Ben-Cohen -
Prepare for introduction of custom firmware loaders by changing
the functions rproc_find_rcs_table() and rproc_load_segments()
to use struct firmware as parameter.When the custom loader framework is introduced all calls into
the firmware specific function must use struct firmware as
parameter.Signed-off-by: Sjur Brændeland
Signed-off-by: Ohad Ben-Cohen
06 Jul, 2012
6 commits
-
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 .
Cc: Russell King
Cc: Fernando Guzman Lugo
Cc: Sjur Brændeland
Reviewed-by: Linus Walleij
Acked-by: Stephen Boyd
Signed-off-by: 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
Cc: Loic Pallardy
Cc: Ludovic BARRE
Cc: Michal Simek
Cc: Fernando Guzman Lugo
Cc: Suman Anna
Cc: Mark Grosen
Acked-by: Stephen Boyd
Signed-off-by: Ohad Ben-Cohen -
Publish carveout addresses on non-iommu setups too.
Reported-and-acked-by: Sjur Brændeland
Signed-off-by: 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
Signed-off-by: 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
Cc: Fernando Guzman Lugo
Signed-off-by: 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 for suggesting and
discussing these ideas in one of the remoteproc review threads and
to Fernando Guzman Lugo for trying them out
with the (upcoming) runtime PM support for remoteproc.Cc: Fernando Guzman Lugo
Reviewed-by: Stephen Boyd
Signed-off-by: Ohad Ben-Cohen
04 Jul, 2012
3 commits
-
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: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen -
Remoteproc requires user space firmware loading support, so
let's select FW_LOADER explicitly to avoid painful misconfigurations
(which only show up in runtime).Cc: stable
Reported-by: Mark Grosen
Signed-off-by: Ohad Ben-Cohen -
OMAP_REMOTEPROC selects REMOTEPROC and RPMSG, both of which depend
on EXPERIMENTAL, so let's have OMAP_REMOTEPROC depend on EXPERIMENTAL
too, in order to avoid the below randconfig warnings.warning: (OMAP_REMOTEPROC) selects REMOTEPROC which has unmet direct dependencies (EXPERIMENTAL)
warning: (OMAP_REMOTEPROC) selects RPMSG which has unmet direct dependencies (EXPERIMENTAL)Cc: stable
Reported-by: Tony Lindgren
Signed-off-by: Ohad Ben-Cohen
17 Jun, 2012
1 commit
-
For some reason one of the dev_err invocations is using a wrong
device so fix that.Signed-off-by: Ohad Ben-Cohen
Cc: stable@vger.kernel.org
10 Jun, 2012
2 commits
-
If rproc_find_rsc_table() fails, rproc_fw_boot() must set
return-value before jumping to clean_up label. Otherwise no
error value is returned.Signed-off-by: Sjur Brændeland
Signed-off-by: Ohad Ben-Cohen
Cc: stable@vger.kernel.org -
Fix compile warnings from GCC 4.6.1 when printing values of type size_t.
drivers/remoteproc/remoteproc_core.c:251:6:
warning: format ‘%x’ expects argument of type ‘unsigned int’,
but argument 4 has type ‘size_t’ [-Wformat]
drivers/remoteproc/remoteproc_core.c:938:9:
warning: format ‘%u’ expects argument of type ‘unsigned int’,
but argument 4 has type ‘size_t’ [-Wformat]
drivers/remoteproc/remoteproc_core.c:1023:2:
warning: format ‘%d’ expects argument of type ‘int’,
but argument 4 has type ‘size_t’ [-Wformat]Signed-off-by: Sjur Brændeland
Signed-off-by: Ohad Ben-Cohen
Cc: stable@vger.kernel.org
30 May, 2012
1 commit
-
Pull IOMMU updates from Joerg Roedel:
"Not much stuff this time. The only change to the IOMMU core code is
the addition of a handle to the fault handling code. A few updates to
the AMD IOMMU driver to work around new errata. The other patches are
mostly fixes and enhancements to the existing ARM IOMMU drivers and
documentation updates.A new IOMMU driver for the Exynos platform was also underway but got
merged via the Samsung tree and is not part of this tree."* tag 'iommu-updates-v3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
Documentation: kernel-parameters.txt Add amd_iommu_dump
iommu/core: pass a user-provided token to fault handlers
iommu/tegra: gart: Fix register offset correctly
iommu: OMAP: device detach on domain destroy
iommu: tegra/gart: Add device tree support
iommu: tegra/gart: use correct gart_device
iommu/tegra: smmu: Print device name correctly
iommu/amd: Add workaround for event log erratum
iommu/amd: Check for the right TLP prefix bit
dma-debug: release free_entries_lock before saving stack trace
23 May, 2012
2 commits
-
Pull trivial updates from Jiri Kosina:
"As usual, it's mostly typo fixes, redundant code elimination and some
documentation updates."* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (57 commits)
edac, mips: don't change code that has been removed in edac/mips tree
xtensa: Change mail addresses of Hannes Weiner and Oskar Schirmer
lib: Change mail address of Oskar Schirmer
net: Change mail address of Oskar Schirmer
arm/m68k: Change mail address of Sebastian Hess
i2c: Change mail address of Oskar Schirmer
net: Fix tcp_build_and_update_options comment in struct tcp_sock
atomic64_32.h: fix parameter naming mismatch
Kconfig: replace "--- help ---" with "---help---"
c2port: fix bogus Kconfig "default no"
edac: Fix spelling errors.
qla1280: Remove redundant NULL check before release_firmware() call
remoteproc: remove redundant NULL check before release_firmware()
qla2xxx: Remove redundant NULL check before release_firmware() call.
aic94xx: Get rid of redundant NULL check before release_firmware() call
tehuti: delete redundant NULL check before release_firmware()
qlogic: get rid of a redundant test for NULL before call to release_firmware()
bna: remove redundant NULL test before release_firmware()
tg3: remove redundant NULL test before release_firmware() call
typhoon: get rid of redundant conditional before all to release_firmware()
... -
Sometimes a single IOMMU user may have to deal with several
different IOMMU devices (e.g. remoteproc).When an IOMMU fault happens, such users have to regain their
context in order to deal with the fault.Users can't use the private fields of neither the iommu_domain nor
the IOMMU device, because those are already used by the IOMMU core
and low level driver (respectively).This patch just simply allows users to pass a private token (most
notably their own context pointer) to iommu_set_fault_handler(),
and then makes sure it is provided back to the users whenever
an IOMMU fault happens.The patch also adopts remoteproc to the new fault handling
interface, but the real functionality using this (recovery of
remote processors) will only be added later in a subsequent patch
set.Cc: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Joerg Roedel
14 May, 2012
1 commit
-
Fix a nasty off-by-one bug in __rproc_free_vrings which
resulted in a memory leak and (for some platforms) failures
to reload the remote processor.Signed-off-by: Subramaniam Chanderashekarapuram
[ohad@wizery.com: reword commit log, stick with the for loop]
Signed-off-by: Ohad Ben-Cohen
30 Apr, 2012
1 commit
-
release_firmware deals gracefully with NULL pointers, so checking
first is redundant.Signed-off-by: Jesper Juhl
Signed-off-by: Jiri Kosina
06 Apr, 2012
1 commit
-
Many users of debugfs copy the implementation of default_open() when
they want to support a custom read/write function op. This leads to a
proliferation of the default_open() implementation across the entire
tree.Now that the common implementation has been consolidated into libfs we
can replace all the users of this function with simple_open().This replacement was done with the following semantic patch:
@ open @
identifier open_f != simple_open;
identifier i, f;
@@
-int open_f(struct inode *i, struct file *f)
-{
(
-if (i->i_private)
-f->private_data = i->i_private;
|
-f->private_data = i->i_private;
)
-return 0;
-}@ has_open depends on open @
identifier fops;
identifier open.open_f;
@@
struct file_operations fops = {
...
-.open = open_f,
+.open = simple_open,
...
};[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Stephen Boyd
Cc: Greg Kroah-Hartman
Cc: Al Viro
Cc: Julia Lawall
Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Mar, 2012
7 commits
-
rproc_handle_resources() looks for the resource table and then
invokes a resource handler function which it took as a parameter.This works, but it's a bit unintuitive to follow.
Instead of passing around function pointers, this patch changes
rproc_handle_resource() to just find and return the resource table,
and then the calling sites of rproc_handle_resource() invoke their
resource handlers directly.Signed-off-by: Ohad Ben-Cohen
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren -
Remove the hardcoded vring alignment of 4096 bytes,
and instead utilize tha vring alignment as specified in
the resource table.This is needed for remote processors that have rigid
memory requirement, and which have found the alignment of
4096 bytes to be excessively big.Signed-off-by: Ohad Ben-Cohen
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren -
Now that remoteproc supports any number of virtio devices,
the previous sanity check in omap_rproc_mbox_callback
doesn't make sense anymore.Remove that so we can start supporting multiple vdevs.
Signed-off-by: Ohad Ben-Cohen
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren -
Now that the resource table supports publishing a virtio device
in a single resource entry, firmware images can start supporting
more than a single vdev.This patch removes the single vdev limitation of the remoteproc
framework so multi-vdev firmwares can be leveraged: VDEV resource
entries are parsed when the rproc is registered, and as a result
their vrings are set up and the virtio devices are registered
(and they go away when the rproc goes away).Moreover, we no longer only support VIRTIO_ID_RPMSG vdevs; any
virtio device type goes now. As a result, there's no more any
rpmsg-specific APIs or code in remoteproc: it all becomes generic
virtio handling.Signed-off-by: Ohad Ben-Cohen
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren -
Boot the remote processor only after setting up the virtqueues,
and shut it down before deleting them.Remote processors should obey virtio status changes, and
therefore not manipulate/trigger the virtqueues while the virtio
driver isn't ready, but it's just safer not to rely on that
(plus a vq access might already be inflight while a vdev
status is changed).We also don't have yet status change notifications, but that's
a temporary limitation.Signed-off-by: Ohad Ben-Cohen
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren -
At this point remoteproc can only register a single VIRTIO_ID_RPMSG virtio
device.This limitation is going away soon: remoteproc is getting support for
registering any number of virtio devices and of any type (as
published by the firmware of the remote processor).Rename remoteproc_rpmsg.c to remoteproc_virtio.c in preparation of
this generalization work.Signed-off-by: Ohad Ben-Cohen
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren -
The resource table is an array of 'struct fw_resource' members, where
each resource entry is expressed as a single member of that array.This approach got us this far, but it has a few drawbacks:
1. Different resource entries end up overloading the same members of 'struct
fw_resource' with different meanings. The resulting code is error prone
and hard to read and maintain.2. It's impossible to extend 'struct fw_resource' without breaking the
existing firmware images (and we already want to: we can't introduce the
new virito device resource entry with the current scheme).3. It doesn't scale: 'struct fw_resource' must be as big as the largest
resource entry type. As a result, smaller resource entries end up
utilizing only small part of it.This is fixed by defining a dedicated structure for every resource type,
and then converting the resource table to a list of type-value members.
Instead of a rigid array of homogeneous structs, the resource table
is turned into a collection of heterogeneous structures.This way:
1. Resource entries consume exactly the amount of bytes they need.
2. It's easy to extend: just create a new resource entry structure, and assign
it a new type.
3. The code is easier to read and maintain: the structures' members names are
meaningful.While we're at it, this patch has several other resource table changes:
1. The resource table gains a simple header which contains the
number of entries in the table and their offsets within the table. This
makes the parsing code simpler and easier to read.
2. A version member is added to the resource table. Should we change the
format again, we'll bump up this version to prevent breakage with
existing firmware images.
3. The VRING and VIRTIO_DEV resource entries are combined to a single
VDEV entry. This paves the way to supporting multiple VDEV entries.
4. Since we don't really support 64-bit rprocs yet, convert two stray u64
members to u32.Signed-off-by: Ohad Ben-Cohen
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant Likely
Cc: Rusty Russell
Cc: Mark Grosen
Cc: John Williams
Cc: Michal Simek
Cc: Loic PALLARDY
Cc: Ludovic BARRE
Cc: Omar Ramirez Luna
Cc: Guzman Lugo Fernando
Cc: Anna Suman
Cc: Clark Rob
Cc: Stephen Boyd
Cc: Saravana Kannan
Cc: David Brown
Cc: Kieran Bingham
Cc: Tony Lindgren
29 Feb, 2012
2 commits
-
1. Depend on OMAP_IOMMU instead of selecting it, to fix an unmet
direct dependency of it (and its imminent build error)
2. Set default to 'no' (achieved implicitly by dropping the 'default'
line)Reported-by: Russell King
Signed-off-by: Ohad Ben-Cohen
Cc: Grant Likely
Cc: Arnd Bergmann
Cc: Mark Grosen
Cc: Suman Anna
Cc: Fernando Guzman Lugo
Cc: Rob Clark
Cc: Ludovic BARRE
Cc: Loic PALLARDY
Cc: Omar Ramirez Luna
Cc: Russell King -
Make sure we're parsing a 32bit image, since we only support
the ELF32 binary format at this point.This should prevent unexpected behavior with non 32bit binaries.
Signed-off-by: Ohad Ben-Cohen
Cc: Grant Likely
Cc: Arnd Bergmann
Cc: Mark Grosen
Cc: Suman Anna
Cc: Fernando Guzman Lugo
Cc: Rob Clark
Cc: Ludovic BARRE
Cc: Loic PALLARDY
Cc: Omar Ramirez Luna
23 Feb, 2012
4 commits
-
A lookup table would be easier to extend, and the resulting
code is a bit cleaner.Reported-by: Grant Likely
Signed-off-by: Ohad Ben-Cohen -
At this point we don't support remote processors that have
a different endianess than the host.Look out for these unsupported scenarios, and bail out if
encountered.Reported-by: Grant Likely
Signed-off-by: Ohad Ben-Cohen
Cc: Mark Grosen
Acked-by: Grant Likely -
When creating a virtqueue for rpmsg, tell virtio we're not interested
in "weak" smp barriers, since we're talking to a real device.On ARM, this means using a DSB instead of a DMB, which is needed
for platforms that kick the remote processor using some kind of
a mailbox device mapped to Device memory (otherwise the kick can
jump ahead and wake the remote processor before it has observed
the changes to the vrings).Signed-off-by: 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: Ohad Ben-Cohen
Cc: Stephen Boyd
Cc: Rob Clark
Cc: Mark Grosen
Cc: Ludovic BARRE
09 Feb, 2012
4 commits
-
Add a dedicated Kconfig menu for the remoteproc drivers, so they
don't show up in the main driver menu.Signed-off-by: Ohad Ben-Cohen
-
Make sure firmware isn't truncated before accessing its data.
Reported-by: Stephen Boyd
Signed-off-by: Ohad Ben-Cohen -
Ditch some boilerplate code by employing the module_platform_driver
helper.Signed-off-by: Ohad Ben-Cohen
-
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: Mark Grosen
Signed-off-by: Ohad Ben-Cohen
