Hi,
On Tue, Mar 5, 2013 at 9:20 PM, Paul Bolle pebo...@tiscali.nl 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
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
Hi,
On Wed, Feb 27, 2013 at 7:44 AM, Tzu-Jung Lee royle...@gmail.com 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,
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
On Thu, Feb 21, 2013 at 9:36 PM, Sjur Brændeland sjurb...@gmail.com 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
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
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
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 1:01 AM, Sjur Brændeland
sjur.brandel...@stericsson.com 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
On Thu, Feb 21, 2013 at 8:37 AM, Rusty Russell ru...@rustcorp.com.au 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
Hi Sjur,
On Thu, Feb 21, 2013 at 7:28 PM, Sjur Brændeland sjurb...@gmail.com 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
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
Hi Sjur,
On Tue, Feb 12, 2013 at 1:49 PM, sjur.brandel...@stericsson.com wrote:
From: Sjur Brændeland sjur.brandel...@stericsson.com
Add functions for creating, deleting and kicking host-side virtio rings.
The host ring is not integrated with virtiqueues and cannot be managed
through
; 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 unsubscribe from this list: se
: No
such file or directory
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Ohad Ben-Cohen o...@wizery.com
Feel free to take this via your tree - thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
bj passed is not
> null.
>
> Signed-off-by: Cong Ding
Acked-by: Ohad Ben-Cohen
--
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.html
Please read th
passed is not
null.
Signed-off-by: Cong Ding ding...@gmail.com
Acked-by: Ohad Ben-Cohen o...@wizery.com
--
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.html
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 Fri, Dec 21, 2012 at 9:33 PM, Omar Ramirez Luna
omar.rami...@copitl.com 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
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
Hi Sjur,
On Fri, Dec 21, 2012 at 3:50 PM, Sjur BRENDELAND
sjur.brandel...@stericsson.com 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
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
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
Hi Loic,
On Tue, Dec 18, 2012 at 3:10 PM, Loic Pallardy
loic.pallardy-...@stericsson.com 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
On Thu, Dec 20, 2012 at 9:19 PM, Olof Johansson o...@lixom.net 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
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
On Wed, Dec 19, 2012 at 4:51 PM, Chuansheng Liu
chuansheng@intel.com 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
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
>
Hi Sjur,
On Thu, Dec 6, 2012 at 9:45 PM, Sjur Brændeland sjurb...@gmail.com 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.
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 Tue, Dec 4, 2012 at 1:06 PM, Joerg Roedel j...@8bytes.org 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
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 b
.
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 of a message to majord
g 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" in
the
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 o...@wizery.com
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
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
On Mon, Nov 19, 2012 at 10:01 AM, Liu, Chuansheng
chuansheng@intel.com 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
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
On Mon, Nov 19, 2012 at 7:57 AM, Liu, Chuansheng
chuansheng@intel.com 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
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
Hi Liu,
On Fri, Nov 16, 2012 at 2:54 PM, Chuansheng Liu
chuansheng@intel.com 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
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
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
Eliminate an erroneous invocation of rproc_shutdown inside
the error path of rproc_virtio_find_vqs.
Reported-by: Ido Yariv i...@wizery.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/remoteproc/remoteproc_virtio.c | 18 --
1 file changed, 12 insertions(+), 6
Hi Omar,
On Thu, Nov 15, 2012 at 6:53 PM, Omar Ramirez Luna omar.l...@linaro.org wrote:
On 14 November 2012 03:54, Ohad Ben-Cohen o...@wizery.com 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
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
Hi Omar,
On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna omar.l...@linaro.org 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
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'
On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren t...@atomide.com 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 o...@wizery.com
Joerg, it might relieve some pain if this will go
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
Hello Fengguang,
On Sat, Oct 6, 2012 at 11:57 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Sat, Oct 6, 2012 at 10:07 AM, Fengguang Wu fengguang...@intel.com wrote:
ERROR: vring_del_virtqueue [drivers/remoteproc/remoteproc.ko] undefined!
ERROR: register_virtio_device [drivers/remoteproc
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
On Fri, Oct 19, 2012 at 3:45 PM, Sjur Brændeland sjurb...@gmail.com 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
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 Thu, Oct 11, 2012 at 8:49 PM, Sjur BRENDELAND
sjur.brandel...@stericsson.com 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
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.
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
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
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 2, 2012 at 10:24 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu fengguang...@intel.com wrote:
Hi Ohad,
FYI, kernel build failed on
tree: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
for-next
head
Hi Sjur,
On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND
sjur.brandel...@stericsson.com 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
On Tue, Oct 9, 2012 at 3:28 PM, Dan Carpenter dan.carpen...@oracle.com 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
On Tue, Oct 9, 2012 at 4:26 PM, Dan Carpenter dan.carpen...@oracle.com 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
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
remoteproc:
, I've pushed this patch to fix this:
commit ed26d190a3e7718a6b8a4f844e963b408f54ce32
Author: Ohad Ben-Cohen o...@wizery.com
Date: Sat Oct 6 11:35:57 2012 +0200
remoteproc: fix (again) the virtio-related build breakage
Another virtio dependency was overlooked, so add it to fix
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: Add STE modem
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: Add STE modem
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]
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 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 Tue, Oct 2, 2012 at 1:16 AM, Randy Dunlap rdun...@xenotime.net 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 Fri, Sep 28, 2012 at 5:35 PM, Emil Goode emilgo...@gmail.com 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:
On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu fengguang...@intel.com 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:
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"
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()
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
): 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 avoid build breakage
drivers/built-in.o: In function `rproc
to `unregister_virtio_device'
Thanks, Randy, I'm applying this:
commit 8676079c6d31605268a7903a09fdf616e2ef5551
Author: Ohad Ben-Cohen o...@wizery.com
Date: Sun Sep 30 10:25:34 2012 +0200
remoteproc: select VIRTIO to avoid build breakage
drivers/built-in.o: In function `rproc_virtio_finalize_features
On Tue, Sep 25, 2012 at 9:01 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
We only need to allocate mapping if there is an rproc domain.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Static checker stuff. Handle with appropriate caution.
Applied, thanks.
I'm just changing
On Tue, Sep 25, 2012 at 9:02 AM, Dan Carpenter dan.carpen...@oracle.com 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
On Tue, Sep 25, 2012 at 9:05 AM, Dan Carpenter dan.carpen...@oracle.com 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 dan.carpen...@oracle.com
Applied, thanks.
--
To unsubscribe from this
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
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
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
Hi Sjur,
On Sat, Sep 22, 2012 at 2:38 PM, Sjur Brændeland sjurb...@gmail.com 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
On Sat, Sep 22, 2012 at 4:33 PM, Sjur Brændeland sjurb...@gmail.com 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 might
On Thu, Sep 20, 2012 at 7:32 PM, sjur.brandel...@stericsson.com wrote:
From: Sjur Brændeland sjur.brandel...@stericsson.com
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
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, Sep 19, 2012 at 7:39 PM, sjur.brandel...@stericsson.com wrote:
From: Sjur Brændeland sjur.brandel...@stericsson.com
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.
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
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 Tue, Sep 18, 2012 at 9:29 PM, sjur.brandel...@stericsson.com wrote:
From: Sjur Brændeland sjur.brandel...@stericsson.com
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.
Hi Sjur,
On Wed, Sep 19, 2012 at 1:08 PM, Sjur BRENDELAND
sjur.brandel...@stericsson.com 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
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 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
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
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/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
Hi Fernando,
On Thu, Aug 30, 2012 at 9:26 PM, Fernando Guzman Lugo
fernando.l...@ti.com 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
301 - 400 of 465 matches
Mail list logo
