anding comment or issue that might show up.
Joerg, can you please take it (or at least its first four patches) ?
We have Tony's ack for the mach-omap2 parts.
Tested-by: Ohad Ben-Cohen
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
riv.
----
Ohad Ben-Cohen (1):
remoteproc: fix error path of ->find_vqs
drivers/remoteproc/remoteproc_virtio.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
ace
>> adoption patch, 15fc611 "remoteproc: convert to idr_alloc()".
>>
>> Signed-off-by: Suman Anna
>> Cc: Tejun Heo
>> Cc: Ohad Ben-Cohen
>
> Acked-by: Tejun Heo
Thanks Suman, applied to fixes.
--
To unsubscribe from this list: send the
Hi Sjur,
On Sun, Feb 10, 2013 at 1:39 PM, wrote:
> From: Dmitry Tarnyagin
>
> Fixes coherent memory leakage, caused by non-deallocated
> firmware image chunk.
I'll just slightly edit the subject + commit log to indicate this fix
is STE-specific.
> Signed-off-by: Dmitry Tarnyagin
Can I add y
On Tue, Mar 19, 2013 at 2:40 PM, Sjur BRENDELAND
wrote:
> Sure, you can add my:
> Signed-off-by: Sjur Brændeland
Thanks. I'm also cc'ing stable
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, Feb 21, 2013 at 7:15 PM, wrote:
> From: Sjur Brændeland
>
> Remove the vdev entry from the list before freeing it,
> otherwise the rproc->vdevs list get corrupted.
>
> Signed-off-by: Sjur Brændeland
Cc'ing stable here too and slightly modifying subject+commit log.
Thanks!
--
To unsubs
On Thu, Feb 21, 2013 at 7:15 PM, wrote:
> +static struct resource_table *
> +rproc_elf_find_rsc_table(struct rproc *rproc, const struct firmware *fw,
> + int *tablesz)
Applying with a minor style change, thanks!
--
To unsubscribe from this li
On Thu, Feb 21, 2013 at 7:15 PM, wrote:
> From: Sjur Brændeland
>
> Combine the almost identical functions rproc_handle_virtio_rsc
> and rproc_handle_boot_rsc.
>
> Signed-off-by: Sjur Brændeland
Cool patch :)
BTW I'm almost done. Doing very small changes here and there and
briefly testing the
On Thu, Feb 21, 2013 at 7:15 PM, wrote:
>
> From: Sjur Brændeland
>
> This patch-set adds support for shared resource table between
> Linux kernel and remote devices.
> - dynamically-allocated address of the vrings can be communicated
> - vdev statuses can be communicated
> - virtio config space
Hi Li,
On Thu, Feb 28, 2013 at 10:02 AM, Li Fei wrote:
>
> Even in failed case of pm_runtime_get_sync, the usage_count
> is incremented. In order to keep the usage_count with correct
> value and runtime power management to behave correctly, call
> pm_runtime_put(_sync) in such case.
Is it better
Hi Sjur,
On Fri, Apr 5, 2013 at 9:15 AM, Sjur Brændeland wrote:
> Any chance that you could review this in time for 3.10 merge window?
Sure, I'm getting to this early next week. Monday at the latest.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, Mar 29, 2013 at 12:34 AM, Robert Tivy wrote:
> rproc_alloc_vring() was modified to call idr_alloc() instead of
> idr_get_new(), but the return value was still handled as before.
>
> Signed-off-by: Robert Tivy
Thanks Rob. This was submitted by Suman some time ago and was applied.
I'll be
On Fri, Apr 5, 2013 at 4:20 PM, Li Fei wrote:
> Even in failed case of pm_runtime_get_sync, the usage_count
> is incremented. In order to keep the usage_count with correct
> value and runtime power management to behave correctly, call
> pm_runtime_put(_sync) in such case.
>
> In __hwspin_lock_requ
On Thu, Feb 21, 2013 at 9:36 PM, Sjur Brændeland wrote:
> OK, We did carefully consider using the normal vrings, but concluded it was
> not doable. I'll try to give you some of the background that I can
> recall from top of my head.
> (I can dig out more if you're still not convinced :)
>
> The mo
Hi,
On Wed, Feb 27, 2013 at 7:44 AM, Tzu-Jung Lee wrote:
> I'm wondering is the support for being called in interrupt is on going?
Not that I know of.
> If I'd like to help on this, any suggestion or cautions should be take care
> of?
If you want this to be merged upstream, please describe yo
Hi Sjur,
On Tue, Feb 12, 2013 at 1:49 PM, wrote:
> From: Sjur Brændeland
>
> Add functions for creating, deleting and kicking host-side virtio rings.
>
> The host ring is not integrated with virtiqueues and cannot be managed
> through virtio-config.
Is that an inherent design/issue of vringh o
On Thu, Feb 21, 2013 at 1:01 AM, Sjur Brændeland
wrote:
> [Sjur:]
>>> How do you see the in-kernel API for this? I would like to see
>>> something similar to my previous patches, where we extend
>>> the virtqueue API. E.g. something like this:
>>> struct virtqueue *vring_new_virtqueueh(...)...
>
>
On Thu, Feb 21, 2013 at 8:37 AM, Rusty Russell wrote:
> Hmm... I clearly jumped the gun, assuming consensus was already reached.
> I have put these patches *back* into pending-rebases, and they will not
> be merged this merge window.
Thanks.
What do you think about creating some virtio-level wra
Hi Sjur,
On Thu, Feb 21, 2013 at 7:28 PM, Sjur Brændeland wrote:
> The motivation for using vringh was to avoid copying buffers
> when sending data from the modem to the host.
I may be missing something here, but why do you need vringh for that?
With rpmsg (which uses two regular vrings) both e
Hi Sjur,
On Mon, Sep 3, 2012 at 4:48 PM, wrote:
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index d5c2dbf..00e1674 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -215,6 +215,9 @@ int rproc_
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
On Tue, Oct 2, 2012 at 1:16 AM, Randy Dunlap wrote:
> This build still fails on linux-next of 20121001 when
> VIRTIO is not enabled.
I meant to send this to 3.6-rc, but now that 3.6 is out, I've pushed
it on remoteproc's for-next branch and will send it to 3.7.
It will show up on linux-next the
On Fri, Sep 28, 2012 at 5:35 PM, Emil Goode wrote:
> The dma_addr_t type can be eigher u32 or u64 depending on
> the configuration. We should use a format specifyer for the
> larges type and explicitly cast to it.
>
> Sparse warnings:
> drivers/remoteproc/remoteproc_core.c:234:2: warning:
>
On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu wrote:
> Hi Ohad,
>
> FYI, kernel build failed on
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
> for-next
> head: bec109a430e8c67bae1743f7e71898283234a77f
> commit: ec4d02d9180f407c41f8310a13b34e473c671fbb [6/9] remot
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
On Thu, Sep 20, 2012 at 7:32 PM, wrote:
> From: Sjur Brændeland
>
> Add support for the STE modem shared memory driver.
> This driver hooks into the remoteproc framework
> in order to manage configuration and the virtio
> devices.
>
> This driver adds custom firmware handlers, because
> STE mode
Hi Sjur,
On Sat, Sep 22, 2012 at 2:38 PM, Sjur Brændeland wrote:
>> It might be safer though to invoke ->setup() in probe/remove, instead
>> of in start/stop (just like you essentially did before).
>>
>> This way we don't assume that stop is always called before remove (as
>> assumption that migh
On Sat, Sep 22, 2012 at 4:33 PM, Sjur Brændeland wrote:
It might be safer though to invoke ->setup() in probe/remove, instead
of in start/stop (just like you essentially did before).
This way we don't assume that stop is always called before remove (as
assumption that migh
With the lists this time
On Wed, Jul 10, 2013 at 6:17 PM, Ohad Ben-Cohen wrote:
> The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d:
>
> Linux 3.10-rc7 (2013-06-22 09:47:31 -1000)
>
> are available in the git repository at:
>
> git://git.ker
Hi Arjun,
On Fri, Aug 30, 2013 at 9:20 PM, Arjun Gopalan wrote:
>
> Hi Ohad/Brian,
>
> I have been working on rpmsg and I need to be able to create static rpmsg
> channels. Channel information needs to be specified by other drivers and for
> this, the drivers need access to struct rpmsg_channel
On Mon, Sep 9, 2013 at 2:57 PM, Thierry Reding wrote:
> If I understand correctly, the way that the services should be announced
> is via RSC_VDEV entries in the resource table?
Yes.
> Looking at the remoteproc core and ELF loader, it seems like the way to
> pass in the resource table is either
On Mon, Sep 10, 2012 at 7:52 AM, Wei Yongjun wrote:
>
> From: Wei Yongjun
>
> The dereference should be moved below the NULL test.
>
> spatch with a semantic match is used to found this.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun
Applied, thanks.
--
To unsubscribe from this l
Hi Sjur,
On Tue, Aug 14, 2012 at 8:06 PM, Sjur BRENDELAND
wrote:
> One way for the device to figure out the translation between
> host-physical and device-address is to peek into some CarveOut
> resource entry and compute this translation. Because a CarveOut
> resource entry contains both the hos
Hi Sjur,
On Mon, Sep 10, 2012 at 4:07 PM, Sjur BRENDELAND
wrote:
> But the vring descriptor table will still contain the host's physical address
> for the
> buffers, right?
> So how can the device then find the device-address of these buffers if we
> don't
> use an IOMMU and have no address tra
ko] undefined!
> ERROR: "vring_transport_features" [drivers/remoteproc/remoteproc.ko]
> undefined!
Thanks, Fengguang, I've pushed this patch to fix this:
commit ed26d190a3e7718a6b8a4f844e963b408f54ce32
Author: Ohad Ben-Cohen
Date: Sat Oct 6 11:35:57 2012 +0200
remotep
Hi Sjur,
On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen wrote:
> On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu wrote:
>> Hi Ohad,
>>
>> FYI, kernel build failed on
>>
>> tree: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/re
Hi Sjur,
On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND
wrote:
> Sorry for not responding sooner, but I thought this issue was solved with
> your patch "remoteproc: fix (again) the virtio-related build breakage"
> (https://lkml.org/lkml/2012/10/6/85).
>
> I'm not sure I understand why you woul
On Tue, Oct 9, 2012 at 3:28 PM, Dan Carpenter wrote:
> Unless there is a good reason why
That's what I'm asking. Is there an inherent coupling with some
platform/architecture ? E.g., OMAP remote processors only go with
OMAP chips.
--
To unsubscribe from this list: send the line "unsubscribe linux
On Tue, Oct 9, 2012 at 4:26 PM, Dan Carpenter wrote:
> If it already compiles fine on x86 then there is no advantage to
> disabling it.
Not really; that's really a hardware question and not a software one.
There are hardware devices that can go with any platform/architecture,
e.g., WLAN chips. O
On Tue, Dec 4, 2012 at 1:06 PM, Joerg Roedel wrote:
> On Tue, Dec 04, 2012 at 03:42:03PM +1100, Stephen Rothwell wrote:
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> arch/arm/mach-omap2/clock44xx_data.c between commit 298ea44f211d ("ARM:
>> OMAP4: hwmod data: ipu and dsp to
On Fri, Oct 19, 2012 at 3:45 PM, Sjur Brændeland wrote:
> Has anyone started looking into any of the open issues mentioned above?
No - feel free to take a stab at it.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
Hello Fengguang,
On Sat, Oct 6, 2012 at 11:57 AM, Ohad Ben-Cohen wrote:
> On Sat, Oct 6, 2012 at 10:07 AM, Fengguang Wu wrote:
>> ERROR: "vring_del_virtqueue" [drivers/remoteproc/remoteproc.ko] undefined!
>> ERROR: "register_virtio_device" [drivers/remoteproc
Hi Sjur,
On Thu, Dec 6, 2012 at 9:45 PM, Sjur Brændeland wrote:
> I just posted a RFC patch-set on this to linux-kernel@vger.kernel.org.
> Review comments is welcomed :-)
Great, will take a look, thanks a lot!
> I have run into one issue with the dynamically allocated notifyids. When
> allocati
Hi Omar,
On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna wrote:
> Use runtime PM functionality interfaced with hwmod enable/idle
> functions, to replace direct clock operations and sysconfig
> handling.
>
> Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
> possible operation
Eliminate an erroneous invocation of rproc_shutdown inside
the error path of rproc_virtio_find_vqs.
Reported-by: Ido Yariv
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/remoteproc_virtio.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers
On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren wrote:
> We need to move the iommu code to live under drivers
> for arm common zImage support.
For the iommu changes in the entire series:
Acked-by: Ohad Ben-Cohen
Joerg, it might relieve some pain if this will go through Tony's tree,
a
On Wed, Dec 19, 2012 at 4:51 PM, Chuansheng Liu
wrote:
>
> The runtime_get_sync() is called during sdio_bus_probe(), then the device
> will be kept in active runtime state
Unless, of course, the driver powered it down.
>, so not neccessary to call
> runtime_get_sync/put_noidle() again in sdio_bu
Hi Loic,
On Tue, Dec 18, 2012 at 3:10 PM, Loic Pallardy
wrote:
> In order to create a generic mailbox framework, functions
> and structures should be renamed in mailbox.
This patch should also update omap_remoteproc.c so the build doesn't
break (and if you have a panda board around it might be n
On Thu, Dec 20, 2012 at 9:19 PM, Olof Johansson wrote:
> While we can make the branch stable, would it make sense to make
> remoteproc for omap depend on !multiplatform during the transition, to
> reduce dependencies a little? Either way works, but it'd be nice to
> keep them independent if we can
Hi Sjur,
On Fri, Dec 21, 2012 at 3:50 PM, Sjur BRENDELAND
wrote:
> Yes, but I think this will work if we allocate resources first,
> and then in the next step register the virtio devices.
> All the resources for all the vdevs will be allocated first
> and then rproc_boot will be called.
This sou
Hi Omar,
On Fri, Dec 21, 2012 at 9:33 PM, Omar Ramirez Luna
wrote:
> Yes, I made the changes, for tidspbridge and remoteproc, I will submit
> both for review, based on this series.
Great, thanks.
Please note that when we do eventually merge this, we need your
updates to be squashed into Loic's
Hi Omar,
On Thu, Nov 15, 2012 at 6:53 PM, Omar Ramirez Luna wrote:
> On 14 November 2012 03:54, Ohad Ben-Cohen wrote:
>> Most of the above questions imply this patch not only converts the
>> iommu to runtime PM, but may carry additional changes that may imply
>> previous
Hi Liu,
On Fri, Nov 16, 2012 at 2:54 PM, Chuansheng Liu
wrote:
> So when calling pm_runtime_set_active(), it will hit the strlen(devname==0)
> which trigger the panic.
Can you please point to the exact line of code that triggers this panic ?
> Here before calling pm_runtime_set_active(), set th
On Mon, Nov 19, 2012 at 7:57 AM, Liu, Chuansheng
wrote:
> Rechecked these codes, the trace event runtime_pm_status is added newly, this
> is different with vanilla
> Linux.
Not sure I'm following - can you point out which tree are you working with ?
> So I still think that calling pm_runtime_se
On Mon, Nov 19, 2012 at 10:01 AM, Liu, Chuansheng
wrote:
>> > Rechecked these codes, the trace event runtime_pm_status is added newly,
>> this is different with vanilla
>> > Linux.
>>
>> Not sure I'm following - can you point out which tree are you working with ?
> Sorry, it is added internally fo
On Tue, Apr 16, 2013 at 8:25 PM, Suman Anna wrote:
> remoteproc configuration selects VIRTIO, but VIRTIO is now
> subordinate to VIRTUALIZATION. VIRTUALIZATION has to be
> selected as well to honor the kconfig menu hierarchy and fix
> the dependency warnings.
Thanks Suman. Is this stable material
On Thu, Apr 18, 2013 at 6:51 PM, Anna, Suman wrote:
>>
>> On Tue, Apr 16, 2013 at 8:25 PM, Suman Anna wrote:
>> > remoteproc configuration selects VIRTIO, but VIRTIO is now subordinate
>> > to VIRTUALIZATION. VIRTUALIZATION has to be selected as well to honor
>> > the kconfig menu hierarchy and f
On Tue, Apr 16, 2013 at 8:25 PM, Suman Anna wrote:
> rpmsg configuration selects VIRTIO, but VIRTIO is now
> subordinate to VIRTUALIZATION. RPMSG is currently selected
> by OMAP_REMOTEPROC, and the dependency warning is not seen
> with the fix in remoteproc config, but the kconfig menu
> hierarchy
On Sun, Jun 16, 2013 at 7:42 AM, Rusty Russell wrote:
>
> We've already tested that it's an error.
>
> Cc: Ohad Ben-Cohen
> Cc: Robert Tivy
> Signed-off-by: Rusty Russell
Acked-by: Ohad Ben-Cohen
Thanks Rusty, feel free to take it via your tree together with the
On Sat, Jun 1, 2013 at 12:16 AM, Suman Anna wrote:
> This patch fixes a sparse warning in the omap remoteproc code
> when OMAP_REMOTEPROC is disabled.
>
> include/linux/platform_data/remoteproc-omap.h:76:13: warning: symbol
> 'omap_rproc_reserve_cma' was not declared. Should it be static?
>
> Sig
On Sat, Jun 1, 2013 at 12:39 PM, Thomas Meyer wrote:
>
> Signed-off-by: Thomas Meyer
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.htm
On Thu, May 9, 2013 at 5:02 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -EINVAL in the rproc_find_loaded_rsc_table() error handling
> case instead of 0, as done elsewhere in this function.
>
> Introduced by commit a2b950ac7b1e6442919ee9e79c4963e134698869
> (remoteproc: perserve r
Hi Suman,
On Sat, Jun 1, 2013 at 12:16 AM, Suman Anna wrote:
> This patch fixes all the existing checkpatch errors and warnings
> in the remoteproc source files.
>
> Signed-off-by: Suman Anna
I'm applying the last three fixes, but ignoring the first two (having
lines that slightly exceed 80 cha
On Sat, Jun 1, 2013 at 12:16 AM, Suman Anna wrote:
> It is not preferable to have the allocated pages for carveout
> memories freed before they are unmapped. The code that deals
> with the cleanup of carveout memories is therefore moved after
> the corresponding mapping entries were cleaned up.
>
On Mon, Mar 25, 2013 at 12:11 PM, Rusty Russell wrote:
> Wei Yongjun writes:
>> From: Wei Yongjun
>>
>> Fix to return a negative error code from the error handling
>> case instead of 0, as returned elsewhere in this function.
>>
>> Signed-off-by: Wei Yongjun
>
> Thanks, I've taken this for the
+ Grant
On Thu, Aug 1, 2013 at 5:10 PM, Kumar Gala wrote:
>> On Jul 29, 2013, at 4:40 PM, Stephen Boyd wrote:
>>> On 07/29, Kumar Gala wrote:
> diff --git a/Documentation/devicetree/bindings/arm/msm/tcsr-mutex.txt
> b/Documentation/devicetree/bindings/arm/msm/tcsr-mutex.txt
> new fil
On Mon, Aug 12, 2013 at 8:24 PM, Kumar Gala wrote:
> So I think I'd ask you to recommend a name, should we just us 'hwspinlock'.
> The general view from ePAPR and dts is the node name should be a bit more
> generic (like ethernet or pci). So what would you suggest?
How about 'hwlock' ?
This
Hi,
On Tue, Mar 5, 2013 at 9:20 PM, Paul Bolle wrote:
> Fix obvious typo introduced in commit
> e121aefa7d9f10eee5cf26ed47129237a05d940b ("remoteproc: fix missing
> CONFIG_FW_LOADER configurations").
Robert Tivy (cc'ed) already submitted a patch to this (it's part of a
bigger series Robert is no
Hi Li,
On Thu, Feb 28, 2013 at 9:44 AM, Li Fei wrote:
> Even in failed case of pm_runtime_get_sync, the usage_count
> is incremented. In order to keep the usage_count with correct
> value and runtime power management to behave correctly, call
> pm_runtime_put(_sync) in such case.
As with the rem
Signed-off-by Liu Chuansheng
> Signed-off-by: Li Fei
Acked-by: Ohad Ben-Cohen
BTW, Li, could you please move to _noidle in those other places where
your previous patch was already applied? I think we have at least the
12xx driver (cc'ing Luca).
Thanks!
Ohad.
--
To unsubscribe fro
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-3.9-fixes
for you to fetch changes up to c7426bce5
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.9-fix
for you to fetch changes up to c10b90d85a5
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.10
for you to fetch changes up to 8ae053d62e88c4
.
Ohad Ben-Cohen (1):
MAINTAINERS: add rpmsg entry
Robert Tivy (1):
rpmsg: process _all_ pending messages in rpmsg_recv_done
Suman Anna (1):
rpmsg: fix kconfig dependencies for VIRTIO
MAINTAINERS | 8 +++
drivers/rpmsg/Kconfig
l, from Vincent Stehlé.
- Fix Kconfig VIRTUALIZATION dependency, from Suman Anna
(a non-critical fix which arrived late during the rc cycle).
--------
Ohad Ben-Cohen (1):
remoteproc: perserve resource table data
Robert Tivy (2):
remo
Hi Stephen,
Could you please add:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
to linux-next to include new stuff coming from Rob?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
Hi Stephen,
On Tue, Apr 16, 2013 at 3:07 AM, Stephen Rothwell wrote:
> On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen wrote:
>> Could you please add:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
>>
>> to linux-next to include ne
Hi Tzu-Jung Lee,
On Mon, Aug 6, 2012 at 10:24 AM, Tzu-Jung Lee wrote:
> Previously, the remoteproc mandates an actual ELF firmware in order to
> parse the resource table and boot the remoteproc.
>
> An fw loader abstraction was added in v3.61-rc1 to make the ELF as a
> "default" handler, and allo
Hi Roy,
On Mon, Aug 6, 2012 at 7:43 PM, Tzu-Jung Lee wrote:
> That's what I'm trying to do, and it has two things needs to be address.
>
> 1) Make the firmware loading step "optional" in the booting process.
>
> 2) Allow the remoteproc use an customized handler to get the resource
> table.
Hi Sjur,
On Thu, Sep 13, 2012 at 9:03 PM, wrote:
> From: Sjur Brændeland
>
> Remoteproc relies on HAS_DMA, add this dependency in Kconfig.
>
> Signed-off-by: Sjur Brændeland
Applied to remoteproc-next, thanks.
Btw:
> ---
> cc: linux-kernel@vger.kernel.org
> cc: Rusty Russell
These should
Hi Sjur,
On Thu, Sep 13, 2012 at 9:03 PM, wrote:
> From: Sjur Brændeland
>
> Some of the rproc drivers needs to know the range
> of the notification IDs used for notifying the device.
> Export a variable in struct rproc holding the
> largest allocated notification id.
>
> Signed-off-by: Sjur Br
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 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 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
On Tue, Sep 18, 2012 at 9:32 PM, wrote:
> From: Sjur Brændeland
>
> Some of the rproc drivers needs to know the range
> of the notification IDs used for notifying the device.
> Export a variable in struct rproc holding the
> largest allocated notification id.
>
> Signed-off-by: Sjur Brændeland
Hi Sjur,
On Tue, Sep 18, 2012 at 9:29 PM, wrote:
> From: Sjur Brændeland
>
> Add support for the STE modem shared memory driver.
> This driver hooks into the remoteproc framework
> in order to manage configuration and the virtio
> devices.
>
> This driver adds custom firmware handlers, because
Hi Sjur,
On Wed, Sep 19, 2012 at 1:08 PM, Sjur BRENDELAND
wrote:
>> > include/linux/modem_shm/ste_modem.h | 71 ++
>>
>> Why did you decide to create a separate folder for this header ? if
>> it's STE specific, maybe use an 'ste' prefix for it too ?
>
> There has been some attempt to upstr
Hi Sjur,
On Wed, Sep 19, 2012 at 7:39 PM, wrote:
> From: Sjur Brændeland
>
> Add support for the STE modem shared memory driver.
> This driver hooks into the remoteproc framework
> in order to manage configuration and the virtio
> devices.
>
> This driver adds custom firmware handlers, because
Hi Sjur,
On Wed, Aug 8, 2012 at 7:55 PM, Sjur Brændeland wrote:
> I realize that we have the same issue with the virtio rings.
> Are there any way we can assign the device address of the virtio rings
> to the resource table in shared memory?
It's a gap we have today, but it should definitely be
Hi Sjur,
On Thu, Aug 9, 2012 at 11:35 PM, Sjur Brændeland wrote:
> Any thoughts on how to go about to fix this?
The general direction I have in mind is to put the resource table in
its final location while we do the first pass of fw parsing.
This will solve all sort of open issues we have (or g
On Fri, Aug 10, 2012 at 6:30 PM, Ohad Ben-Cohen wrote:
> This will solve all sort of open issues we have (or going to have soon):
>
> 1. dynamically-allocated address of the vrings can be communicated
> 2. vdev statuses can be communicated
> 3. virtio config space will fi
- 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 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
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
>>
>> drivers/remoteproc/omap_remoteproc.c:31:26: fatal error: plat/mailbox.h: No
>> such file or directory
>>
>> Signed-off-by: Arnd Bergmann
>
> Acked-by: Tony Lindgren
Acked-by: Ohad Ben-Cohen
Feel free to take this via your tree - thanks.
--
To unsubscrib
On Thu, Oct 11, 2012 at 8:49 PM, Sjur BRENDELAND
wrote:
> This driver is intended for NovaThor SoC and for a configuration with
> LLI as the shared memory interface between the host and modem.
> When using LLI as the shared memory interface the modem could be used
> with any platform/architecture
on `rproc_remove_virtio_dev':
> (.text+0x2f9e9f): undefined reference to `unregister_virtio_device'
Thanks, Randy, I'm applying this:
commit 8676079c6d31605268a7903a09fdf616e2ef5551
Author: Ohad Ben-Cohen
Date: Sun Sep 30 10:25:34 2012 +0200
remoteproc: select VIRTIO to
On Tue, Sep 25, 2012 at 9:01 AM, Dan Carpenter wrote:
> We only need to allocate mapping if there is an rproc domain.
>
> Signed-off-by: Dan Carpenter
> ---
> Static checker stuff. Handle with appropriate caution.
Applied, thanks.
I'm just changing the subject, because this actually fixes a sn
On Tue, Sep 25, 2012 at 9:02 AM, Dan Carpenter wrote:
> snprintf() returns the number of characters which would have been
> printed if there were enough space. For example, on the first print if
> we fill up the 28 character string then it would return a number more
> than 30. Use scnprintf() in
On Tue, Sep 25, 2012 at 9:05 AM, Dan Carpenter wrote:
> copy_from_user() returns the number of bytes remaining to be copied, but
> we want to return an error code here.
>
> Signed-off-by: Dan Carpenter
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
1 - 100 of 235 matches
Mail list logo
