On Tue, Jan 2, 2018 at 2:17 PM, Suman Anna <s-anna@xxxxxx> wrote:
> Hi Adam,
>
> On 12/27/2017 08:04 AM, Adam Ford wrote:
>> I am struggling trying to get the DSP on an OMAP3630/3730 running. I
>> am looking at the remote proc functions and comparing omap, keystone
>> and davinci's implementation, and it appears as if we need to set
>> aside some shared memory as part of the DSP container which the omap3
>> device tree is currently missing.
>
> What stack are you trying to run on the DSPs (DSP/Bridge or SysLink)?
> DSP/Bridge driver was removed from mainline as it was not being
> maintained, and SysLink support was completely out of tree.
I am open to whatever is the path of least resistance. I was hoping
to use the TI IPC tools which appear to use remoteproc, but I'll take
whatever I can get.
>
> Keystone remoteproc driver was added with DT support to begin with, and
> I have recently extended the DT support to Davinci remoteproc driver.
> The OMAP remoteproc driver was originally written for OMAP4 and beyond
> for non-DT devices, and it still lacks the DT support on mainline
> (blocked on various DT conversion dependencies - most of them are in and
> it's currently blocked on the hwmod cleanup).
That makes sense. I assumed this was being either orphaned or
abandoned which is why I e-mailed. I was hoping
>
>> Adding these to the device tree looks like it's only part of it. When
>> I look at the davinci and keystone remote proc drivers, they are also
>> looking for specific 'compatible' DSP's. The omap3.dtsi file
>> references the ti,omap3-c64, but I can't find any references to it, so
>> it seems like there quite a bit missing to make remote proc work with
>> the OMAP3.
>
> Yes, these compatibles were originally added as part of a PM support in
> core mach-omap2 layers but without the necessary backing drivers
> (remoteproc or otherwise) in commit 476b679a5d785 ("arm/dts: OMAP3+: Add
> mpu, dsp and iva nodes"). Technically, the current compatible is
> incorrect for OMAP4, as the OMAP4 DSP is not the same as the OMAP3 DSP.
Can the OMAP4 or L-138 DSP stuff be adapted to the OMAP35/36.37? I
know they are all technically different, but I don't know how
different they are.
> Do note that the PM init code was removed as part of the legacy non-DT
> code cleanup in cb6675d6a868 ("ARM: OMAP2+: Remove legacy PM init").
>
>>
>> Might someone (like Anna or someone from TI) have a code stub or a
>> starting point that I might be able to use to try and finish the job
>> of getting the DSP working with a modern kernel?
>
> I have the DT support on downstream TI kernels for OMAP4+ SoCs, and it
> is easy to extend that to OMAP3 but it will depend on what stack you are
> planning to use on the DSP-side. Most recent reference I have is
> http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=shortlog;h=refs/heads/rpmsg-ti-linux-4.9.y.
> I will be porting to 4.14 within the next 30 days and should be
> available on the same tree.
Once the device tree side is complete, what would be required to make
a simple 'hello world' demo to show the DSP is communicating?
>
> Do note that the rpmsg transport was never added to the OMAP3 DSP so
> extending OMAP remoteproc driver with virtio rpmsg support will require
> some work on the DSP-side s/w. Also, DSP/Bridge stack was never ported
> to use the OMAP remoteproc driver either. But if it is only the DT
> portions that you are looking for, the above tree should have the
> necessary stuff for you to get started.
We sell System-On-Modules based on the OMAP35, DM37 and L-138. At
this point, any DSP functionality is better than nothing. We have
customers who want to buy SOM's but are questioning the age and
support since much of the DSP and 3D acceleration support seems to
have stopped on the TI side. Any support you can provide is greatly
appreciated.
adam
>
> regards
> Suman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
