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

Måns Rullgård mans
Wed Sep 8 14:17:15 CEST 2010

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

Yes, so?

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

How can you be so sure of that?  You do not control what is accepted
upstream.  Tony does.

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

Every user of Codec Engine.

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

Regardless of which features one or the other may have or lack, both
systems exist.  Pretending your favourite is the only one is

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

It would help your credibility if you at least took care to get the
names right.  The distribution to which I assume you refer has nothing
to do with astronauts or jazz music.

>> which has been further abstracted to form syslink.
> That's not true; it's completely independent.

For future reference, call this statement #1.

> 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.
Note the contradiction with statement #1 above.

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

A while ago you insisted that nothing but dspbridge would ever make it
upstream.  Which way is it?

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

You created the page, and most of the changes were made by you.  This
means you may not use this page to back up your claims in a discussion.

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

Feel free.

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

So syslink is largely based on parts of dspbridge, yet is 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. 

Unrelated to what?  Your claim was that only dspbridge is used in
shipping products.  Counterexamples to this claim cannot be simply
dismissed as unrelated.

> And there are no OMAP4 products yet.

I am certain there will be some within a year.

>>> and future.
>> Do you have a crystal ball?
> I work in Nokia.

Does Nokia have a corporate crystal ball?  Does Nokia decide what
everybody else is allowed to do?

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list