On Wed, Jun 29, 2011 at 9:04 AM, Ohad Ben-Cohen wrote:
> On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
> wrote:
>> Very little for me to comment on here. However, something I just
>> noticed. Why is it necessary to pass in THIS_MODULE to the
>> rproc_register function? Having a reference to t
On Tue, Jun 28, 2011 at 12:00 AM, Grant Likely
wrote:
> Very little for me to comment on here. However, something I just
> noticed. Why is it necessary to pass in THIS_MODULE to the
> rproc_register function? Having a reference to the pdev gives you the
> pointer to the driver, which has the TH
On Tue, Jun 21, 2011 at 10:18:28AM +0300, Ohad Ben-Cohen wrote:
> From: Guzman Lugo, Fernando
>
> Add remoteproc implementation for OMAP4, so we can load the M3 and DSP
> remote processors.
>
> Based on code by Hari Kanigeri
>
> While this code is functional, and works on OMAP4 & its M3's,
> i
On Wed, Jun 22, 2011 at 1:05 PM, Will Newton wrote:
> On Tue, Jun 21, 2011 at 8:18 AM, Ohad Ben-Cohen wrote:
>
>> +/* bootaddr isn't needed for the dual M3's */
>> +static inline int omap_rproc_start(struct rproc *rproc, u64 bootaddr)
>
>> +static inline int omap_rproc_stop(struct rproc *rproc)
>
On Tue, Jun 21, 2011 at 8:18 AM, Ohad Ben-Cohen wrote:
> +/* bootaddr isn't needed for the dual M3's */
> +static inline int omap_rproc_start(struct rproc *rproc, u64 bootaddr)
> +static inline int omap_rproc_stop(struct rproc *rproc)
These two functions don't need to be inline as far as I can
From: Guzman Lugo, Fernando
Add remoteproc implementation for OMAP4, so we can load the M3 and DSP
remote processors.
Based on code by Hari Kanigeri
While this code is functional, and works on OMAP4 & its M3's,
it is still preliminary and going to substantially change:
1. Splitting physically
