[FFmpeg-devel] [RFC/PATCH 0/8] ffmpeg: add tidsp hwaccel support to avcodec

[Felipe Contreras]

2010/9/8 M?ns Rullg?rd <mans at mansr.com>:
> Felipe Contreras <felipe.contreras at gmail.com> writes:
>> 2010/9/8 M?ns Rullg?rd <mans at mansr.com>:
>>> Felipe Contreras <felipe.contreras at gmail.com> writes:
>>>
>>>> ?libavcodec/tidsp_mpeg4.c ? ? ?| ?157 ++++++
>>>
>>> I dislike the "tidsp" name. ?This patch is for one specific, and
>>> mostly obsolete, interface to the DSP. ?It is like calling MPEG4 ASP
>>> "the codec".
>>
>> As I pointed out in the mail:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/staging/tidspbridge
>>
>> The linux kernel driver is called tidspbridge, you might dislike that
>> name, but that's it's name, and it's the only real requirement from
>> this code. "bridge" denominates the communication MPU <-> DSP, so the
>> only logical name for the whole system is tidsp.
>
> To any rational person, the name "tidsp" signifies something related
> to TI DSPs in general, whereas dspbridge is but one of several methods
> of communicating with it.

Let me outline the whole system:

tidsp (user-space) -> tidspbridge (kernel-space) -> hw -> dsp-bridge
(DSP OS) -> dsp socket-node

In the releases that TI provides for OMAP[1], the binaries are
supposed to work *only* with tidspbridge. If you want to use dsp-link,
you need different binaries. So the whole system is tied.

And tidspbridge, is the *only* method to access the bridge that has
any chance of getting into linux upstream.

>> It is far from obsolete, in fact, it's the *only* interface TI (or
>> anyone) is pushing to merge into upstream, and it's the only that has
>> reached the "staging" status.
>
> Most people outside Nokia seem to be using dsplink

Who? I know at least Motorola and Google use dspbridge. In fact,
probably all mobile manufacturers do, because only dspbridge has
power-management features while dsp-link doesn't.

dsp-link was developed by the other side of TI; the one that is in
charge of Davinci platform, and is not interested in power
performance, which explains why there is no power-management support.

I know only of the Armstrong distribution that prefers dsplink, mostly
because of Koen I guess.

> which has been further abstracted to form syslink.

That's not true; it's completely independent. In fact, if anything,
it's based on tidspbridge as the same developers are involved, and
it's reusing code like iommu and mailbox, which dsp-link doesn't.

In fact, the architecture of syslink has many elements of what Hiroshi
Doyu (from Nokia, maintainer of dsp-gateway) pushed for TI get into
tidspbridge.

---
SysLink is an evolution of both the previous-generation IPC drivers -
DSPBridge and DSPLink. It provides a symmetric IPC interface on both
the host processor and remote/slave processors.
---

For more info:
http://www.omapzoom.org/wiki/Syslink_Project

> It is the only interface
> available on OMAP4 and Netra, where it is used for communication with
> all the various coprocessors, not only the DSP.

Yes, and the plan is to have it upstream too... along with
tidspbridge, and share as much code as possible.

>> You can read more in the dsp clarification page[1]. dsp-link is dead;
>> [1] http://elinux.org/BeagleBoard/DSP_Clarification
>
> Nice try, referencing a page you wrote.

Take a look at the authors: Mrchapp (TI), Omar rmz (TI, and maintainer
of tidspbridge), Nmenon (TI). And you can see on the discussion page
also Jkridner (TI, in charge of dsp-link).

>> TI will not be pushing it upstream or do any reviewing or cleaning up.
>
> TI plan to push syslink upstream.

Which is not related to dsp-link (any more, and probably less, than
tidspbridge).

>> So for all intends and purposes, tidspbridge is the only interface;
>
> In your world.

Do you want me to CC Jason Krider and Ohad Ben-Cohen to explain to you
that syslink is not related to dsp-link, and that dsp-link has no
plans to get into upstream at all?

>> the only one actively maintained, the only one with a shot getting
>> upstream,
>
> On the contrary, syslink is maintained and will be pushed upstream.
> How long a process that will be is impossible to predict of course.

Unrelated.

>> and the only one shipped on consumer products, current
>
> Except the consumer products shipping with dsplink, that is. ?There
> are many of those.

Unrelated. And there are no OMAP4 products yet.

>> and future.
>
> Do you have a crystal ball?

I work in Nokia.

[1] http://omapzoom.org/wiki/L23.i3.8_Release_Notes

-- 
Felipe Contreras