[FFmpeg-devel] [RFC/PATCH 0/8] ffmpeg: add tidsp hwaccel support to avcodec
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:
>>> 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.
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
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
> 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:
>> 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. 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).
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
>>> 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.
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 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?
mans at mansr.com
More information about the ffmpeg-devel