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 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 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 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 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 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
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
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
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
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
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 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 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
- 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
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
Hi Stephen,
On Mon, Jul 16, 2012 at 9:03 AM, Stephen Rothwell wrote:
> Hi Ohad,
>
> Today's linux-next merge of the remoteproc tree got a conflict in
> drivers/remoteproc/remoteproc_core.c between commits e981f6d41acd
> ("remoteproc: fix print format warnings") and 30338cf09f82 ("remoteproc:
> fi
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 6:14 PM, Ohad Ben-Cohen wrote:
> On Mon, Jul 2, 2012 at 6:11 PM, Sjur BRENDELAND
> wrote:
>>> To simplify things, will the below work for you?
>>
>> Looks good, feel free to add my Acked-by
>
> Thanks! I'll queue it up for 3.6.
App
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-kerne
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
Hi Sjur,
On Fri, Jul 6, 2012 at 12:18 PM, Sjur BRENDELAND
wrote:
> The simple story is that when Host writes a bit indicated with TX-mask
> it generates an interrupt on the modem-side. And likewise when the
> modem writes a bit indicated with RX mask the Host will receive an
> interrupt.
Ok, tha
s/litle/little
Signed-off-by: Ohad Ben-Cohen <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index f0b3171..5465c63 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -116,7 +116,7 @@
n 1/11/08, David Miller <[EMAIL PROTECTED]> wrote:
> From: Ohad Ben-Cohen <[EMAIL PROTECTED]>
> Date: Mon, 7 Jan 2008 18:22:48 +0200 (IST)
>
> > In the (rare) event of simultaneous mutual wake up requests,
> > do send the chip an explicit wake-up ack. This is req
In the (rare) event of simultaneous mutual wake up requests,
do send the chip an explicit wake-up ack. This is required
for Texas Instruments's BRF6350 chip.
Signed-off-by: Ohad Ben-Cohen <[EMAIL PROTECTED]>
---
drivers/bluetooth/hci_ll.c | 23 ++-
1 files
201 - 235 of 235 matches
Mail list logo
