Re: OMAP remote proc bindings seem incomplete for OMAP3 and OMAP4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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).

> 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.
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.

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.

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



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux