ate a 'recovery' debugfs entry
Juan Gutierrez (1):
remoteproc/omap: set bootaddr support
Ohad Ben-Cohen (1):
remoteproc: select VIRTIO to avoid build breakage
Sjur Brændeland (3):
remoteproc: Add dependency to HAS_DMA
remtoteproc: maintain max notifyid
remoteproc
Hi Fernando,
On Thu, Aug 30, 2012 at 9:26 PM, Fernando Guzman Lugo
wrote:
> These set of patches make possible the remoteproc recover after a crash.
> This is a hard recovery, that means the remoteproc is reset and it will
> start from the beginning. When a crash happen all the virtio devices are
Hi Linus,
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
tags/rpmsg-3.6-fix
for you to fetch changes up to eeb0074f36
Hi Linus,
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.6-fix
for you to fetch changes up to
Hi Fernando,
On Thu, Aug 30, 2012 at 3:24 AM, Fernando Guzman Lugo
wrote:
> dma_alloc/free_coherent APIs requires the platform specific remoteproc
> device as the device parameter. We are passing vdev->dev.parent to the
> dma_free_coherent function which is the generic rproc device and it is
> wr
Hi Juan,
On Wed, Aug 15, 2012 at 6:25 PM, Juan Gutierrez wrote:
> Some remote processors (like Omap4's DSP) need to explicitly
> set a boot address from which they start executing code when
> taken out of reset.
>
> Support for this has been added to remoteproc code through
> a set_bootaddr funct
- custom binary format support from Sjur Brændeland
- groundwork for recovery and runtime pm support
- some cleanups and API simplifications
------------
Ohad Ben-Cohen (8):
remoteproc: allocate vrings on demand, free when not needed
Hi Linus,
The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c:
Linux 3.5-rc7 (2012-07-14 15:40:28 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
tags/single-rpmsg-3.5-fix
for you to fetch changes up to 963
+ Paul
On Tue, Jul 17, 2012 at 1:11 PM, Joerg Roedel wrote:
> On Fri, Jun 15, 2012 at 08:55:58PM -0500, Omar Ramirez Luna wrote:
>> Omar Ramirez Luna (6):
>> ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
>> ARM: OMAP3: hwmod data: add mmu data for iva and isp
>> ARM: OM
Hi Federico,
On Fri, Jul 13, 2012 at 9:00 PM, Ohad Ben-Cohen wrote:
> I agree. I'll take it, but will change the commit log to make it
> omaprpc-agnostic.
Here's what I'm going to apply:
commit 913552b8c7a0f06cc1bff27f8e9953bffe6a1817
Author: Federico Fuga
Date: Mon
On Thu, Jul 5, 2012 at 5:50 AM, Stephen Boyd wrote:
> On 7/4/2012 6:36 AM, Ohad Ben-Cohen wrote:
>> 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 regis
On Tue, Jul 3, 2012 at 9:11 PM, Stephen Boyd wrote:
> On 07/02/12 13:10, Ohad Ben-Cohen wrote:
>> 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 use
On Mon, Jul 2, 2012 at 11:52 AM, Ohad Ben-Cohen wrote:
> From 0fbf3004c1a52ae4c0554366409a2bfe401801ef Mon Sep 17 00:00:00 2001
> From: Ohad Ben-Cohen
> Date: Mon, 2 Jul 2012 11:41:16 +0300
> Subject: [PATCH] remoteproc: simplify unregister/free interfaces
>
> Simplify t
On Sat, May 26, 2012 at 10:36 AM, Ohad Ben-Cohen wrote:
> 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, an
On Thu, Jul 5, 2012 at 11:35 PM, Stephen Boyd wrote:
> Ok then. Please add
>
> Reviewed-by: Stephen Boyd
Added, and applied patch. thanks!
> It would be nice if you got an ack from Greg or Kay on the device_type
> usage too.
I agree, I'd just hate bothering them on this now. Probably a topic
f
On Sun, May 20, 2012 at 3:00 PM, Ohad Ben-Cohen wrote:
> 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 invoke
Hi Federico,
On Wed, Jul 11, 2012 at 10:14 AM, Federico Fuga wrote:
> it triggers a BUG() in drivers/base/driver.c line 169
Thanks for sharing this; it definitely makes sense now.
> The subsys_initcall indeed solve this issue
I agree. I'll take it, but will change the commit log to make it
oma
Hi Federico,
On Tue, Jul 10, 2012 at 7:43 PM, Federico Fuga wrote:
> omaprpc is out of the official mainline code, it's inside the official
> ti/omap branch/project.
Ok, thanks for the explanation. In general, we don't change the
mainline kernel to solve issues with out-of-tree code.
> I guess
Hi Federico,
On Tue, Jul 10, 2012 at 7:07 PM, Federico Fuga wrote:
> omaprpc depends on the rpmsg bus.
Sorry for the ignorance, but what's omaprpc ? :)
I guess it's some out-of-tree module (which I've never seen) so I'm
not sure we want change mainline code to fix issues with it.
If your code
nando Guzman Lugo.
Ohad Ben-Cohen (2):
rpmsg: avoid premature deallocation of endpoints
rpmsg: make sure inflight messages don't invoke just-removed callbacks
drivers/rpmsg/virtio_rpmsg_
.
Ohad Ben-Cohen (2):
remoteproc/omap: fix randconfig unmet direct dependencies
remoteproc: fix missing CONFIG_FW_LOADER configurations
drivers/remoteproc/Kconfig | 2 ++
1 file changed, 2 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-oma
Hi Linus,
The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:
Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.5-fixes
for you to fetch changes up t
Cc: Russell King
Cc: Stephen Boyd
Cc: Fernando Guzman Lugo
Cc: Sjur Brændeland
Signed-off-by: Ohad Ben-Cohen
---
Documentation/remoteproc.txt | 18 +-
drivers/remoteproc/omap_remoteproc.c | 8
drivers/remoteproc/remoteproc_core.c | 32 --
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
---
drivers/remoteproc/Kconfig |1 +
1 file chang
y
Cc: Ludovic BARRE
Cc: Michal Simek
Cc: Fernando Guzman Lugo
Cc: Suman Anna
Cc: Mark Grosen
Signed-off-by: Ohad Ben-Cohen
---
Documentation/remoteproc.txt | 20 --
drivers/remoteproc/remoteproc_core.c | 126 ---
2 files changed, 146 deletions(-)
On Mon, Jul 2, 2012 at 10:06 PM, Stephen Boyd wrote:
> Great! It looks like device_type doesn't have any list iteration support
> though. Is that requirement gone?
Pretty much, yeah. I'll soon post a separate patch which removes the
get_by_name functionality (together with its related klist).
>
On Mon, Jul 2, 2012 at 6:15 PM, Sjur BRENDELAND
wrote:
>> Sjur, Ludovic, Loic - what remoteproc API are you using today?
>>
>> We'd like to get rid of the existing get/put interface and instead
>> have everyone use the boot/shutdown one, just like rpmsg is doing
>> today.
>>
>> Are you ok with thi
+ Sjur, Ludovic, Loic
On Tue, Jun 5, 2012 at 1:57 PM, Ohad Ben-Cohen wrote:
> On Tue, Jun 5, 2012 at 12:23 AM, Stephen Boyd wrote:
>> I thought we wanted to allow both calls to proceed in parallel? If we
>> don't care about that
>
> Yeah, I don't think we do.
>
On Mon, Jul 2, 2012 at 11:59 AM, Russell King - ARM Linux
wrote:
> On Mon, Jul 02, 2012 at 11:52:27AM +0300, Ohad Ben-Cohen wrote:
>> Simplify the unregister/free interfaces, and make them easier
>> to understand and use, by moving to a symmetric and consistent
>>
On Tue, Jun 5, 2012 at 12:22 AM, Stephen Boyd wrote:
> On 05/30/12 05:38, Ohad Ben-Cohen wrote:
>> On Wed, May 30, 2012 at 11:42 AM, Stephen Boyd wrote:
>>>> - /* the rproc will only be released after its refcount drops to zero
>>>> */
>>>> -
h has unmet direct dependencies
(EXPERIMENTAL)
Reported-by: Tony Lindgren
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index ff6f55c..726804e 100644
--- a/drivers/remot
e the rpmsg driver was just removed, and its
callback function isn't available anymore.
This is achieved by introducing a callback mutex, which must be taken
before the callback is invoked, and, obviously, before it is removed.
Reported-by: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
--
deallocate
epts once they have been added to the endpoints idr.
Reported-by: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 36 ++--
include/linux/rpmsg.h| 3 +++
2 files changed, 37 insertions(+), 2 deletions
On Wed, May 30, 2012 at 3:16 PM, Ohad Ben-Cohen wrote:
> In this case, I was more wondering between using a class to a device type.
>
>> I recall seeing a thread where
>> someone said classes were on the way out and shouldn't be used but I
>> can't find it anymor
.
Ohad Ben-Cohen (1):
remoteproc/omap: fix dev_err typo
Sjur Brændeland (2):
remoteproc: fix print format warnings
remoteproc: fix missing fault indication in error-path
drivers/remoteproc/omap_remoteproc.c | 2 +-
drivers/remoteproc
On Wed, Jun 6, 2012 at 6:25 AM, Stephen Boyd wrote:
> What if I don't want to boot the device at kernel start-up? Do I have to
> make it a module then?
Currently, yeah.
But we can change stuff if needed.
We took that design decision because it was simple and we didn't have
any reason not to do
On Tue, Jun 5, 2012 at 12:23 AM, Stephen Boyd wrote:
> I thought we wanted to allow both calls to proceed in parallel? If we
> don't care about that
Yeah, I don't think we do.
> then "announcing" it once the firmware is found the first time sounds correct.
I agree. Though this patch may be moot
On Tue, Jun 5, 2012 at 12:22 AM, Stephen Boyd wrote:
> Option 1 is nicer and it also follows the model other subsystems have
> put forth such as the input subsystem.
Sounds good, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...
On Wed, May 30, 2012 at 11:42 AM, Stephen Boyd wrote:
> I was hoping we could use class_for_each_device() and
> class_find_device() to replace all this code. Then we wouldn't need all
> this klist stuff that the class is taking care of already.
Awesome! This really is worth a shot.
>> +/**
>> +
Hi Stephen,
As always - thanks for your review!
On Wed, May 30, 2012 at 11:36 AM, Stephen Boyd wrote:
> It looks like remoteproc0, remoteproc1, etc. is what's used.
Thanks, I'll update the commit log.
> One complaint I've gotten is that the error messages are essentially
> useless now. I belie
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
---
drivers/remoteproc/r
out
with the (upcoming) runtime PM support for remoteproc.
Cc: Stephen Boyd
Cc: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/omap_remoteproc.c| 17 +++--
drivers/remoteproc/remoteproc_core.c| 125 ---
drivers/remoteproc/remo
Hi Stephen,
On Thu, May 24, 2012 at 12:15 PM, Stephen Boyd wrote:
> The request_firmware timeout is defaulted to 60 seconds but not
> necessarily 60 if the user has changed the timeout in sysfs.
..
> Why does this need to be a timeout at all? Presumably
> request_firmware_nowait() in rproc_regist
Hi Ludovic,
On Tue, May 22, 2012 at 3:51 PM, frq09524 wrote:
> In my previous patch, to find the correct subdevice that match with physical
> memory, I used pa member of rproc_mem_entry.
I'm not sure we want to find these subdevices using the physical
memory of the expected region.
Doing so me
loading is completed.
Reported-and-tested-by: Sjur Brandeland
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/remoteproc_core.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
ind
Hi Ludovic,
On Tue, May 22, 2012 at 12:14 PM, frq09524 wrote:
> Ohad, for alignment I can take the latest branch of kernel.org (remoteproc)
> branch for-next?
Sure, it's pretty much updated sans a few simple changes.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe lin
For some reason one of the dev_err invocations is using a wrong
device so fix that.
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/omap_remoteproc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc
Hi Michal,
On Tue, May 22, 2012 at 8:51 AM, Michal Simek wrote:
> Simple enabling RSC_VDEV in rproc_handle_rsc doesn't work.
Sure - you'll need to actually plug the vrings allocation code there,
too (i.e. this requires some coding, it's not a 1-liner).
> BTW: I am using kernel modules and there
ppens.
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
---
drivers/iommu/iommu.c|
Hi Michal,
On Mon, May 21, 2012 at 4:02 PM, Michal Simek wrote:
> I have looked at it and tested on latest and greatest and the problem is
> still there.
Ok, I see why this is happening.
We're now allocating the vrings' DMA in ->find_vqs() just before we
boot the remote processor, and we releas
Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/remoteproc_core.c | 109 +++---
drivers/remoteproc/remoteproc_internal.h |2 +
drivers/remoteproc/remoteproc_virtio.c | 13 +++-
3 files changed, 67 insertions(+), 57 deletions(-)
diff --gi
Hi Michal,
On Sat, Mar 17, 2012 at 8:39 AM, Ohad Ben-Cohen wrote:
> IOW: you can probably just wait a bit until this patch is ready and
> take it into your tree. It will most likely bring back the behavior you
> need :)
Does something like the attached help ?
Thanks,
Ohad.
0001-r
: OMAP: enable mailbox irq per instance
ARM: OMAP4: fix irq and clock name for dsp-iommu
Ohad Ben-Cohen (1):
ARM: OMAP4: hwspinlocks_init() should be static
arch/arm/mach-omap2/hwspinlock.c |2 +-
arch/arm/mach-omap2/mailbox.c|2 --
arch/arm/mach-omap2/omap-iommu.c |6
Hi Linus,
Please pull a tiny but quite important remoteproc fix for 3.4.
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remotep
loop]
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/remoteproc_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index ee15c68..e756a0d 100644
--- a/drivers/remoteproc/remoteproc_core.c
Sparse found out that hwspinlocks_init() wasn't marked static,
and it should've been.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/hwspinlock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hw
er's notifier callback.
>
> Signed-off-by: Juan Gutierrez
Acked-by: Ohad Ben-Cohen
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 10, 2012 at 5:19 AM, Juan Gutierrez wrote:
> @@ -338,13 +341,13 @@ struct omap_mbox *omap_mbox_get(const char *name,
> struct notifier_block *nb)
> if (!mbox)
> return ERR_PTR(-ENOENT);
>
> + if (nb)
> + blocking_notifier_chain_register(&mbox-
x clock names and align
> with hwmod names"
>
> - Renamed INT_44XX_DSP_MMU to OMAP44XX_IRQ_TESLA_MMU.
> Naming convention adopted since: commit e927f8d "omap4: Add
> auto-generated irq and dma headers"
>
> - dsp-iommu is enabled by default.
>
> Signed-off
Hi Juan,
On Tue, May 8, 2012 at 1:09 AM, Gutierrez, Juan wrote:
> Startup it is now only used to enable pm runtime of the whole mbox module.
Btw I really doubt we need to do that in a machine-specific handler,
or whether we really need this startup/shutdown abstraction at all.
But that's not rel
Hi Juan,
On Mon, May 7, 2012 at 5:38 PM, Gutierrez, Juan wrote:
>> > @@ -40,6 +41,7 @@ struct omap_rproc_pdata {
>> > const struct rproc_ops *ops;
>> > int (*device_enable) (struct platform_device *pdev);
>> > int (*device_shutdown) (struct platform_device *pdev);
>> > +
Hi Juan,
On Sat, Apr 14, 2012 at 2:39 AM, Juan Gutierrez wrote:
> The machine-specific omap2_mbox_startup is called only once
> to initialize the whole mbox module. Enabling mbox irq at
> startup is only enabling the irq of the very first mailbox
> instance created.
>
> The enable_irq function sh
Hi Juan,
On Sat, Apr 14, 2012 at 2:39 AM, Juan Gutierrez wrote:
> Irq and clock names were wrong for dsp iommu configuration
> for omap4.
Looks good.
> Renamed tesla_ick to dsp_fck.
If you're resubmitting the series, please indicate here why this
change is needed (specifically let's mention co
Hi Juan,
Thanks for the patches ! it's exciting to see that support for OMAP's
DSP is (relatively) easily achieved now. I hope your work can be a
good basis for an OMAP3 port, too.
Overall the patches look good, I have only some minor comments inline.
And - sorry for the late response. I've just
Hi Michal,
On Fri, Mar 16, 2012 at 4:57 PM, Michal Simek wrote:
> In previous version I had carverout first which means that code was copyied
> to physical address 0x0 and then vrigns were allocated. Current code
> allocate vring first and then RTOS is not able to run from zero address.
In gener
On Sat, Mar 10, 2012 at 9:20 PM, Russell King - ARM Linux
wrote:
> Why isn't this copied to the stable folk?
By mistake. But I asked Greg to take it earlier today:
http://lkml.org/lkml/2012/3/10/70
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message
On Sat, Mar 10, 2012 at 8:08 PM, Russell King - ARM Linux
wrote:
> Seems to be that the OMAP mailbox stuff is buggered:
Can you please recheck with the following commit (already in mainline):
commit 134d12fae0bb8f3d60dc7440a9e1950bb5427167
Author: Ohad Ben-Cohen
Date: Sun Mar 4 12:01:11 2
rning when dma_addr_t is 64-bit
Ohad Ben-Cohen (12):
remoteproc: make sure we're parsing a 32bit firmware
remoteproc/omap: two Kconfig fixes
rpmsg: fix name service endpoint leak
rpmsg: validate incoming message length before propagating
rpmsg: fix published buffer
On Tue, Mar 6, 2012 at 7:01 PM, Arnd Bergmann wrote:
> Ohad has sent a series of patches for review and there were no comments
> on those. The fix was part of it as far as I remember. I'm still waiting
> for a pull request from Ohad.
Yes, sorry for not sending the pull yet. I should have sent thi
Cleanup: don't build mach-omap2/hwspinlock.c if the OMAP hwspinlock
driver isn't configured.
This will both shorten build time and avoid registering a device
which isn't needed.
Signed-off-by: Ohad Ben-Cohen
---
Tony, it's probably better if you take it, to minimize omap mer
For some weird (freudian?) reason, commit 435792d "ARM: OMAP: make
iommu subsys_initcall to fix builtin omap3isp" unintentionally changed
the mailbox's initcall instead of the iommu's.
Fix that.
Reported-by: Fernando Guzman Lugo
Signed-off-by: Ohad Ben-Cohen
Cc: Laurent
Hi Laurent,
On Thu, Mar 1, 2012 at 6:37 PM, Laurent Pinchart
wrote:
> I'll try that then. How expensive is the iommu_attach_device() (and detach)
> operation in terms of CPU time ?
omap_iommu_attach() basically enables the iommu clock and configures
that IP block.
I suspect it's negligible but
cific 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:
n 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:
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
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:
(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
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
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
Brown
Cc: Kieran Bingham
Cc: Tony Lindgren
Ohad Ben-Cohen (7):
remoteproc: resource table overhaul
remoteproc: remoteproc_rpmsg -> remoteproc_virtio
remoteproc: safer boot/shutdown order
remoteproc: remove the single rpmsg vdev limitation
remoteproc/omap: remove the mbox_callback li
When an inbound message arrives, validate its reported length before
propagating it, otherwise buggy (or malicious) remote processors might
trick us into accessing memory which we really shouldn't.
Signed-off-by: Ohad Ben-Cohen
Cc: Grant Likely
Cc: Arnd Bergmann
Cc: Mark Grosen
Cc: Suman
After processing an incoming message, always publish the real size
of its containing buffer when putting it back on the available rx ring.
Using any different value might erroneously limit the remote processor
(leading it to think the buffer is smaller than it really is).
Signed-off-by: Ohad Ben
ngs to the rpmsg bus,
and is never bound with a specific rpdev.
Reported-by: Omar Ramirez Luna
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 Ra
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 Likel
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 Lug
Five trivial remoteproc/rpmsg fixes.
One was reported by Russell (the Kconfig fixes) and one by Omar (the endpoint
leak).
Ohad Ben-Cohen (5):
remoteproc: make sure we're parsing a 32bit firmware
remoteproc/omap: two Kconfig fixes
rpmsg: fix name service endpoint leak
rpmsg: val
Five remoteproc/rpmsg fixes.
One was reported by Russell (the Kconfig fixes) and one by Omar (the endpoint
leak).
Ohad Ben-Cohen (5):
remoteproc: make sure we're parsing a 32bit firmware
remoteproc/omap: two Kconfig fixes
rpmsg: fix name service endpoint leak
rpmsg: validate inc
On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann wrote:
> I think 'depends' would be better here, because selecting IOMMU_SUPPORT
> has other side-effects that a user might not want. It's just as likely
> that someone wants to disable IOMMU_SUPPORT and needs to find OMAP_REMOTEPROC
> as wanting to
On Tue, Feb 28, 2012 at 11:02 AM, Russell King - ARM Linux
wrote:
> 1. It selects OMAP_IOMMU which may not have its dependencies satisfied.
I'll select IOMMU_SUPPORT too (I prefer selecting here rather than
depending, because users may have hard time realizing they need to
enable omap's iommu fir
Hi Laurent,
On Mon, Feb 27, 2012 at 12:47 AM, Laurent Pinchart
wrote:
> I'm asking about the probe deferral mechanism. The omap3-isp driver will still
> call iommu_attach_device() in its probe function. What will happen then ? Will
> it return an error ? On what basis will it do so ?
Yes, iommu_
Hi Laurent,
On Sun, Feb 26, 2012 at 7:34 PM, Laurent Pinchart
wrote:
> On Sunday 26 February 2012 12:14:14 Ohad Ben-Cohen wrote:
>> omap3isp depends on omap's iommu and will fail to probe if
>> initialized before it (which always happen if they are builtin).
>
On Fri, Feb 24, 2012 at 3:16 PM, Joerg Roedel wrote:
> Applied both and added stable-tag to the second patch. I'll send the
> pull-request when you guys also send me the correct fix for the
> outstanding initialization order issue on OMAP.
It's out, thanks!
--
To unsubscribe from this list: send
ned-off-by: Ohad Ben-Cohen
Cc: stable
Cc: Tony Lindgren
Cc: Hiroshi Doyu
Cc: Joerg Roedel
---
arch/arm/mach-omap2/mailbox.c |3 ++-
drivers/iommu/omap-iommu.c|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailb
On Thu, Feb 23, 2012 at 11:18 AM, Bedia, Vaibhav wrote:
> Instead of adding more #ifs can they be completely removed please?
Care to propose something specific (which is viable for the -rc cycle) ?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body
On Thu, Feb 23, 2012 at 6:11 PM, Joerg Roedel wrote:
> I guess these patches are 3.3 material?
Yes.
> How about tagging them for stable too?
Good point. But it's only relevant for this 2nd patch (the NULL
pointer dereference fix), as the first one is a 3.3 regression. Let me
know if you want me
On Thu, Feb 23, 2012 at 4:31 PM, Arnd Bergmann wrote:
> I've looked at the code again now and pulled it into the arm-soc
> tree as the next/rpmsg branch, queued for submission to Linus in
> the 3.4 merge window. There won't be any conflicts in linux-next
> because the commits are identical, so it
-omap2/mailbox.c:354: error: for each function it appears in.)
Which happens on CONFIG_ARCH_OMAP2 && !CONFIG_SOC_OMAP2420, due to
missing omap2_mboxes declaration.
In addition, make sure we declare the right mailbox instances for 2430.
Reported-by: Russell King
Signed-off-by: Ohad Ben-
On Thu, Feb 23, 2012 at 12:56 AM, Tony Lindgren wrote:
> Care to post an updated patch for me to apply into fixes?
Coming right up!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
On Wed, Feb 22, 2012 at 10:12 PM, Russell King - ARM Linux
wrote:
> +#ifdef CONFIG_ARCH_OMAP2
> +struct omap_mbox *omap2_mboxes[] = {
> + &mbox_dsp_info,
> +#ifdef CONFIG_SOC_OMAP2420
> + &mbox_iva_info,
> +#endif
> + NULL
> +};
> #endif
Beautiful. Thanks!
--
To unsubscribe fro
On Wed, Feb 22, 2012 at 7:58 PM, Tony Lindgren wrote:
> 2430 is like omap3 for the mailbox.
Gotcha, thanks.
This one below isn't pretty, but it should satisfy all build
permutations and still be correct hw-wise.
If it looks good to you I'll submit it properly.
diff --git a/arch/arm/mach-omap2/
101 - 200 of 824 matches
Mail list logo
