Hi,
On 2.01.2018 22:59, Adam Ford wrote:
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.
I doubt there are any useful codec nodes besides those for DSP/Bridge.
At least I am not aware of.
Not that those are impossible to be used via remoteproc, but somebody
should implement COFF image loader. Huge task, but I'll gladly help if
you take on it.
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?
remoteproc COFF loader. Also, last time I checked, there was no reset
driver implemented for DSP, but that should be trivial to implement.
see
https://github.com/pali/linux-n900/commits/v4.9-n900/drivers/staging/tidspbridge
for what was needed to have tidspbridge more or less working on modern
kernels.
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
Ivo
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
--
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
