[FFmpeg-devel] [RFC/PATCH 0/8] ffmpeg: add tidsp hwaccel support to avcodec
Wed Sep 8 13:39:32 CEST 2010
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:
>> 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, 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
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:
> 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. dsp-link is dead;
>>  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
>> 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
> On the contrary, syslink is maintained and will be pushed upstream.
> How long a process that will be is impossible to predict of course.
>> 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.
More information about the ffmpeg-devel