linux-toradex.git/drivers/remoteproc, branch v3.4.2

remoteproc: fix off-by-one bug in __rproc_free_vrings

2012-05-13T20:15:42+00:00

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

simple_open: automatically convert to simple_open()

2012-04-05T22:25:50+00:00

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

remoteproc: cleanup resource table parsing paths

2012-03-06T17:14:44+00:00

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

remoteproc: remove the hardcoded vring alignment

2012-03-06T17:14:37+00:00

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

remoteproc/omap: remove the mbox_callback limitation

2012-03-06T17:14:23+00:00

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

remoteproc: remove the single rpmsg vdev limitation

2012-03-06T17:14:12+00:00

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

remoteproc: safer boot/shutdown order

2012-03-06T17:13:53+00:00

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

remoteproc: remoteproc_rpmsg -> remoteproc_virtio

2012-03-06T17:13:45+00:00

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

remoteproc: resource table overhaul

2012-03-06T17:13:39+00:00

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

remoteproc/omap: two Kconfig fixes

2012-02-28T17:09:16+00:00

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