Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-24 Thread Ohad Ben-Cohen
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 patches so we don't break
bisectibility.

Thanks,
Ohad.
--
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


Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-21 Thread Omar Ramirez Luna
Hi Loic/Ohad,

On Fri, Dec 21, 2012 at 2:52 AM, Loic PALLARDY  wrote:
>
>
> On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote:
>> 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.
>>
>> I'm not sure multiplatform is the culprit; OMAP's remoteproc driver
>> heavily depends on this mailbox code, and obviously breaks with this
>> patch-set if only for the the naming changes. We'll need this patch
>> set to update omap's remoteproc as well so at least we don't break
>> bisectibility, though running a sanity test before merging would be
>> even nicer (Loic I can help if you don't have a panda board).
>
> Hi Ohad,
> Yes tidspbridge and remoteproc must be adapted.
> This new mailbox fw has been tested on TI environment by Omar, who did
> adaptation at least for tidspbridge.
>
> Omar, do you have patch series ready for TI adaptations to new mailbox
> framework?
> Else I can do it, but I won't be able to test it (no panda board)

Yes, I made the changes, for tidspbridge and remoteproc, I will submit
both for review, based on this series.

Cheers,

Omar
--
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


Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-21 Thread Loic PALLARDY


On 12/21/2012 08:31 AM, Ohad Ben-Cohen wrote:
> 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.
>
> I'm not sure multiplatform is the culprit; OMAP's remoteproc driver
> heavily depends on this mailbox code, and obviously breaks with this
> patch-set if only for the the naming changes. We'll need this patch
> set to update omap's remoteproc as well so at least we don't break
> bisectibility, though running a sanity test before merging would be
> even nicer (Loic I can help if you don't have a panda board).

Hi Ohad,
Yes tidspbridge and remoteproc must be adapted.
This new mailbox fw has been tested on TI environment by Omar, who did 
adaptation at least for tidspbridge.

Omar, do you have patch series ready for TI adaptations to new mailbox 
framework?
Else I can do it, but I won't be able to test it (no panda board)

Regards,
Loic
>
> BTW - grep shows that tidspbridge is using the mailbox code too, but
> it's in staging and I'm not sure it gets much love. Nevertheless, as
> long as it's there we should at least update it with the new API as
> well.
>
> Thanks,
> Ohad.--
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


Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-20 Thread Ohad Ben-Cohen
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.

I'm not sure multiplatform is the culprit; OMAP's remoteproc driver
heavily depends on this mailbox code, and obviously breaks with this
patch-set if only for the the naming changes. We'll need this patch
set to update omap's remoteproc as well so at least we don't break
bisectibility, though running a sanity test before merging would be
even nicer (Loic I can help if you don't have a panda board).

BTW - grep shows that tidspbridge is using the mailbox code too, but
it's in staging and I'm not sure it gets much love. Nevertheless, as
long as it's there we should at least update it with the new API as
well.

Thanks,
Ohad.
--
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


Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-20 Thread Tony Lindgren
* Olof Johansson  [121220 11:22]:
> On Thu, Dec 20, 2012 at 10:28 AM, Tony Lindgren  wrote:
> > * Linus Walleij  [121220 10:19]:
> >> On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
> >>  wrote:
> >>
> >> > OMAP and ST-Ericsson platforms are both using mailbox to communicate
> >> > with some coprocessors.
> >> > Based on OMAP existing mailbox framework, this series proposes a
> >> > generic framework, living under drivers/mailbox.
> >>
> >> I like this patch series so you have my Acked-by.
> >>
> >> Since it's a new subsystem and affects a few ARM architectures can
> >> we merge this into the ARM SoC tree once we have consensus,
> >> so we get some rotation in linux-next that way?
> >
> > Yes good idea.
> >
> >> Olof/Arnd?
> >
> > I suggest we set up an immutable branch against
> > v3.8-rc1 when it's out with only these patches in it.
> > Then we can all merge it in as needed. Maybe Arnd or
> > Olof can set up the branch?
> 
> I haven't reviewed the patches yet, but this flow sounds reasonable to me.

OK cool.
 
> > FYI, looks like I need to merge in this branch too to
> > avoid build errors with remoteproc enabled once I flip
> > on the multiplatform support for omap2+.
> 
> 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.

Yes I'll update the omap multiplat fixups patch I posted yesterday.
I noticed it only after running make randconfig for a while.

Regards,

Tony
--
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


Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-20 Thread Olof Johansson
On Thu, Dec 20, 2012 at 10:28 AM, Tony Lindgren  wrote:
> * Linus Walleij  [121220 10:19]:
>> On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
>>  wrote:
>>
>> > OMAP and ST-Ericsson platforms are both using mailbox to communicate
>> > with some coprocessors.
>> > Based on OMAP existing mailbox framework, this series proposes a
>> > generic framework, living under drivers/mailbox.
>>
>> I like this patch series so you have my Acked-by.
>>
>> Since it's a new subsystem and affects a few ARM architectures can
>> we merge this into the ARM SoC tree once we have consensus,
>> so we get some rotation in linux-next that way?
>
> Yes good idea.
>
>> Olof/Arnd?
>
> I suggest we set up an immutable branch against
> v3.8-rc1 when it's out with only these patches in it.
> Then we can all merge it in as needed. Maybe Arnd or
> Olof can set up the branch?

I haven't reviewed the patches yet, but this flow sounds reasonable to me.

> FYI, looks like I need to merge in this branch too to
> avoid build errors with remoteproc enabled once I flip
> on the multiplatform support for omap2+.

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.


-Olof
--
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


Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-20 Thread Tony Lindgren
* Linus Walleij  [121220 10:19]:
> On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
>  wrote:
> 
> > OMAP and ST-Ericsson platforms are both using mailbox to communicate
> > with some coprocessors.
> > Based on OMAP existing mailbox framework, this series proposes a
> > generic framework, living under drivers/mailbox.
> 
> I like this patch series so you have my Acked-by.
> 
> Since it's a new subsystem and affects a few ARM architectures can
> we merge this into the ARM SoC tree once we have consensus,
> so we get some rotation in linux-next that way?

Yes good idea.
 
> Olof/Arnd?

I suggest we set up an immutable branch against
v3.8-rc1 when it's out with only these patches in it.
Then we can all merge it in as needed. Maybe Arnd or
Olof can set up the branch?

FYI, looks like I need to merge in this branch too to
avoid build errors with remoteproc enabled once I flip
on the multiplatform support for omap2+.

Regards,

Tony
--
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


Re: [PATCH 0/9] drivers: mailbox: framework creation

2012-12-20 Thread Linus Walleij
On Tue, Dec 18, 2012 at 2:10 PM, Loic Pallardy
 wrote:

> OMAP and ST-Ericsson platforms are both using mailbox to communicate
> with some coprocessors.
> Based on OMAP existing mailbox framework, this series proposes a
> generic framework, living under drivers/mailbox.

I like this patch series so you have my Acked-by.

Since it's a new subsystem and affects a few ARM architectures can
we merge this into the ARM SoC tree once we have consensus,
so we get some rotation in linux-next that way?

Olof/Arnd?

Yours,
Linus Walleij
--
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