> From: Grant Likely
> Sent: Monday, June 27, 2011 3:24 PM
> > Our AMPs (remote processors) have a variety of boot mechanisms that vary
> > across the different SoCs (yes, TI likes HW diversity). In some cases, the
> > boot address is more like an entry point and that comes from the firmware,
> >
On Mon, Jun 27, 2011 at 5:29 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 27, 2011 at 02:49:58PM -0600, Grant Likely wrote:
>> > +struct {
>> > + char magic[4] = { 'R', 'P', 'R', 'C' };
>> > + u32 version;
>> > + u32 header_len;
>> > + char header[...] = { header_len bytes
On Mon, Jun 27, 2011 at 02:49:58PM -0600, Grant Likely wrote:
> > +struct {
> > + char magic[4] = { 'R', 'P', 'R', 'C' };
> > + u32 version;
> > + u32 header_len;
> > + char header[...] = { header_len bytes of unformatted, textual header
> > };
> > + struct section {
> > +
On Mon, Jun 27, 2011 at 09:52:30PM +, Grosen, Mark wrote:
> > From: Grant Likely
> > Sent: Monday, June 27, 2011 1:50 PM
>
> Grant, thanks for the feedback. I'll try to answer one of your
> questions below and leave the rest for Ohad.
>
> Mark
>
> > > +Every remoteproc implementation must p
On Tue, Jun 21, 2011 at 10:18:33AM +0300, Ohad Ben-Cohen wrote:
> Add a virtio-based IPC bus, which enables kernel users to communicate
> with remote processors over shared memory using a simple messaging
> protocol.
>
> Assign a local address for every local endpoint that is created,
> and bind i
> From: Grant Likely
> Sent: Monday, June 27, 2011 1:50 PM
Grant, thanks for the feedback. I'll try to answer one of your
questions below and leave the rest for Ohad.
Mark
> > +Every remoteproc implementation must provide these handlers:
> > +
> > +struct rproc_ops {
> > + int (*start)(struct
> From: Ohad Ben-Cohen
> Sent: Saturday, June 25, 2011 6:12 PM
>
> Hi Stephen,
>
> On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd wrote:
> > Instead of devising a new firmware format, we decided
> > to just stick with elf and parse the headers in the kernel because we
> > needed them for authent
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 Tue, Jun 21, 2011 at 10:18:27AM +0300, Ohad Ben-Cohen wrote:
> Some systems have slave heterogeneous remote processor devices,
> that are usually used to offload cpu-intensive computations
> (e.g. multimedia codec tasks).
>
> Booting a remote processor typically involves:
> - Loading a firmware
> From: Nori, Sekhar
> Sent: Friday, June 24, 2011 8:44 AM
>
> Hi Mark,
Sekhar, thanks for your feedback and ideas. Comments below.
Mark
> Since procedure to set the boot address varies across DaVinci
> platforms, you could have a callback populated in platform data
> which will be implemented
> From: Sergei Shtylyov
> Sent: Friday, June 24, 2011 8:14 AM
>
> Grosen, Mark wrote:
>
> >> It should work on DA830 as well,
>
> So please make it dependent on ARCH_DAVINCI_DA8XX.
>
> >> but not on real DaVinci, so the name is misleading...
>
> > Yes, we debated calling it da8xx, but
On Monday 27 June 2011, Nori, Sekhar wrote:
> On Sat, Jun 25, 2011 at 23:18:19, Arnd Bergmann wrote:
> > On Friday 24 June 2011, Nori, Sekhar wrote:
> > Please make sure the patches apply on top of 2.6.39 and resubmit
> > them, separating out the first cleanup patch from the others.
>
> Is it 2.6.
Hi Arnd,
On Sat, Jun 25, 2011 at 23:18:19, Arnd Bergmann wrote:
> On Friday 24 June 2011, Nori, Sekhar wrote:
> > This series of 4 patches added SATA support on DaVinci
> > DA850 platform. This was ready for last merge window,
> > but was not queued because of the negative diffstat
> > rule.
> >
Hello.
On 24-06-2011 22:51, Constantine Shulyupin wrote:
Enable USB on TI DM365
On DM365 EVM board, you should have said.
Do not duplicate the summary in the description. Also, more details here
wouldn't hurt...
Signed-off-by: Constantine Shulyupin
[...]
diff --git a/arch/arm/ma
On 06/21/2011 12:18 AM, Ohad Ben-Cohen wrote:
> * Rpmsg: a virtio-based messaging bus that allows kernel drivers to
> communicate with remote processors available on the system. In turn,
> drivers could then expose appropriate user space interfaces, if needed
> (tasks running on remote processors o
On Friday 24 June 2011 20:51:31 Constantine Shulyupin wrote:
Hi,
> -void davinci_setup_usb(unsigned mA, unsigned potpgt_ms);
> +int davinci_setup_usb(unsigned mA, unsigned potpgt_ms);
>
> #endif /* ifndef __ASM_ARCH_USB_H */
> diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davi
On Sat, Jun 25, 2011 at 6:11 PM, Ohad Ben-Cohen wrote:
> Hi Stephen,
>
> On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd wrote:
>> This sounds a lot like SMD (shared memory driver) on MSM. The main
>> difference I see is that SMD uses the platform bus instead of the virtio
>> bus and it has its ow
17 matches
Mail list logo
