Paul,
On 08/20/2013 06:39 PM, Paul Walmsley wrote:
> Hi
>
> a few comments
>
> On Wed, 14 Aug 2013, Suman Anna wrote:
>
>> The remoteproc infrastructure is currently tied closely with the
>> virtio/rpmsg framework, and the boot requires that there are virtio
>> devices present in the resource t
Hi
a few comments
On Wed, 14 Aug 2013, Suman Anna wrote:
> The remoteproc infrastructure is currently tied closely with the
> virtio/rpmsg framework, and the boot requires that there are virtio
> devices present in the resource table from the firmware image.
Using static channels is something t
On Wed, Aug 14, 2013 at 10:27 AM, Suman Anna wrote:
> Kevin, Santosh, Dave, Russ,
>
> On 08/13/2013 02:11 PM, Kevin Hilman wrote:
>> Russ Dill writes:
>>
>> ARM world is also moving towards that by standardizing some of these
>> through (read PSCI) and thats the way to go in general.
Kevin, Santosh, Dave, Russ,
On 08/13/2013 02:11 PM, Kevin Hilman wrote:
> Russ Dill writes:
>
> ARM world is also moving towards that by standardizing some of these
> through (read PSCI) and thats the way to go in general.
Agreed, but I'm not sure (yet) about enforcing PSCI on
Russ Dill writes:
ARM world is also moving towards that by standardizing some of these
through (read PSCI) and thats the way to go in general.
>>>
>>> Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms
>>> that don't support it natively. Are you saying that the AM3
On Tuesday 13 August 2013 02:30 PM, Russ Dill wrote:
ARM world is also moving towards that by standardizing some of these
through (read PSCI) and thats the way to go in general.
>>>
>>> Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms
>>> that don't support it nativ
>>> ARM world is also moving towards that by standardizing some of these
>>> through (read PSCI) and thats the way to go in general.
>>
>> Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms
>> that don't support it natively. Are you saying that the AM33xx firmware
>> should be
On Tuesday 13 August 2013 12:19 PM, Kevin Hilman wrote:
> + Ohad
>
> Santosh Shilimkar writes:
>
>> On Tuesday 13 August 2013 10:29 AM, Kevin Hilman wrote:
>>> Dave Gerlach writes:
>>>
On 08/12/2013 02:17 PM, Kevin Hilman wrote:
> Dave Gerlach writes:
>
>> On 08/09/2013 12:11
+ Ohad
Santosh Shilimkar writes:
> On Tuesday 13 August 2013 10:29 AM, Kevin Hilman wrote:
>> Dave Gerlach writes:
>>
>>> On 08/12/2013 02:17 PM, Kevin Hilman wrote:
Dave Gerlach writes:
> On 08/09/2013 12:11 AM, Tony Lindgren wrote:
>> * Dave Gerlach [130808 09:23]:
>>
On Tuesday 13 August 2013 10:29 AM, Kevin Hilman wrote:
> Dave Gerlach writes:
>
>> On 08/12/2013 02:17 PM, Kevin Hilman wrote:
>>> Dave Gerlach writes:
>>>
On 08/09/2013 12:11 AM, Tony Lindgren wrote:
> * Dave Gerlach [130808 09:23]:
>> On 08/08/2013 08:44 AM, Santosh Shilimkar wr
Dave Gerlach writes:
> On 08/12/2013 02:17 PM, Kevin Hilman wrote:
>> Dave Gerlach writes:
>>
>>> On 08/09/2013 12:11 AM, Tony Lindgren wrote:
* Dave Gerlach [130808 09:23]:
> On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
>> Lets address the above better. I don't see a need of 8
On 08/12/2013 02:17 PM, Kevin Hilman wrote:
Dave Gerlach writes:
On 08/09/2013 12:11 AM, Tony Lindgren wrote:
* Dave Gerlach [130808 09:23]:
On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
Lets address the above better. I don't see a need of 8 functions
exported doing one or 2 register wr
Dave Gerlach writes:
> On 08/09/2013 12:11 AM, Tony Lindgren wrote:
>> * Dave Gerlach [130808 09:23]:
>>> On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
Lets address the above better. I don't see a need of 8 functions
exported doing one or 2 register writes.
Look M3 based h
* Dave Gerlach [130809 14:02]:
>
> Ok I will go ahead and pull the control module code that handles IPC
> into the wkup_m3 driver. The wkup_m3.c file is still present in
> mach-omap2 as the right location for it wasn't decided in the last
> RFC. Any thoughts on a good location for it?
Well maybe
On 08/09/2013 12:11 AM, Tony Lindgren wrote:
* Dave Gerlach [130808 09:23]:
On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
Lets address the above better. I don't see a need of 8 functions
exported doing one or 2 register writes.
Look M3 based handling is going to be there on future SOCs
as
* Dave Gerlach [130808 09:23]:
> On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
> >Lets address the above better. I don't see a need of 8 functions
> >exported doing one or 2 register writes.
> >
> >Look M3 based handling is going to be there on future SOCs
> >as well and this kind of handling o
On 08/08/2013 08:44 AM, Santosh Shilimkar wrote:
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
From: Vaibhav Bedia
Interacting with WKUP-M3 requires some more control
module register writes. Add the register offsets and
APIs to write to these.
Signed-off-by: Vaibhav Bedia
Signed-of
On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> Interacting with WKUP-M3 requires some more control
> module register writes. Add the register offsets and
> APIs to write to these.
>
> Signed-off-by: Vaibhav Bedia
> Signed-off-by: Dave Gerlach
> ---
> arch/ar
On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach wrote:
> From: Vaibhav Bedia
>
> Interacting with WKUP-M3 requires some more control
> module register writes. Add the register offsets and
> APIs to write to these.
>
> Signed-off-by: Vaibhav Bedia
> Signed-off-by: Dave Gerlach
Reviewed-by: Russ D
From: Vaibhav Bedia
Interacting with WKUP-M3 requires some more control
module register writes. Add the register offsets and
APIs to write to these.
Signed-off-by: Vaibhav Bedia
Signed-off-by: Dave Gerlach
---
arch/arm/mach-omap2/control.c | 57 +
arc
20 matches
Mail list logo
