[FFmpeg-devel] [RFC/PATCH 0/8] ffmpeg: add tidsp hwaccel support to avcodec
Wed Sep 8 15:51:54 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:
>>>>> 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
>> Yes, so?
> So tidspbridge is the only way to access that particular DSP system.
Yes, dspbridge is the only way to access a dspbridge based system. It
is useless if you want to access any other system running on a TI DSP.
>>> 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.
> First of all, the acceptance of tidspbridge is out of Tony's hands as
> it's not in linux-omap's tree, but it's in 'staging' so it's up to
> Greg now.
Whatever, you don't control Greg's actions either.
> And second, dsp-link is not on staging, not even on linux-omap, or
> linux-davinci, it's nowhere near the scope of any linux maintainer as
> there have never been any set of patches submitted for review on any
> subsystem. And Jason Kridner told me there are no plans of ever doing
I must assume he said there were no plans to push *dsplink* upstream,
not that would never, ever be any plans to push anything other than
dspbridge. You are claiming the latter, which is preposterous.
>>>>> 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.
> Who? Motorola? HTC? Samsung? Nobody in the mobile market would touch
> Codec Engine, mainly because of the lack of power management in
> You said "most people" outside Nokia, I wonder who that is.
All those who do not make phones.
>>> 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
> Well, it's the only one in linux.
The only one apart from the other ones, those you choose to ignore.
> But let run a though experiment. Let's assume someone submits a patch
> to get CodecEngine into FFmpeg, would such code for a dead-end API,
> proprietary, not present widespread consumer devices, nor intended to
> ever get into linux upstream be accepted? And if so, which name would
> you give it? My suggestion would be tice. So, there, no conflict with
That is irrelevant. Calling something specific (dspbridge) by a
generic name (tidsp) is over-reaching and confusing.
> However, that's not happening, and might never happen. Why not worry
> about the naming "conflict" when (if it ever) happens?
By giving it a generic name now, there is _already_ a conflict with
every future system.
>>> 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.
> s/Armstrong/?ngstr?m/ that doesn't change the argument.
You are correct, it doesn't turn what you said into much of an argument.
>>>> 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.
> No, you said syslink was abstracted from dsp-link, which is not true.
I am merely repeating what TI employees have told me. They were
probably not the ones who did the actual work, so they could of course
have been wrong. Then again, neither are you.
> The text above doesn't say what was "abstracted" from what, just that
> syslink is the next generation of IPC drivers.
Yes, the next generation after dsplink and dspbridge.
>>> 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?
> Nothing dsp-*.
What difference does the precise name make? It was renamed to syslink
since it is now capable of communicating with other devices than the
DSP. The functionality regarding the DSP remains much the same.
>>> 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.
> I am not backing up any claims, I merely suggested you *could* take a
> look at that page. You can decide to only look at what other people
> wrote, or you can ignore that text and only read the discussion, or
> you could just follow the reference links, which where not written by
> Or you could just not read it and look for the information yourself,
> and you could participate in the wiki by correcting any mistakes you
> might find in your independent research (which you wouldn't find).
I am sure you would find a way to dismiss anything I might find.
There is thus no point in me wasting my time searching.
>>>>> 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?
> syslink is unrelated to this discussion, as it wasn't "abstracted"
> from dsp-link.
Regardless of its origins, syslink exists and is going to replace
dspbridge as we know it today. You previously claimed that dspbridge
is the only DSP interface which will ever exist.
>>>>> 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.
> I said *consumer* products; e.g. mobile phones.
Consumers use many products other than phones.
> Feel free to list some of those consumer products that use dsp-link,
Anything with a Davinci chip.
>>> And there are no OMAP4 products yet.
>> I am certain there will be some within a year.
> Yes, perhaps, but that's not what you said before;
All I said about OMAP4 was that syslink was replacing
dsplink/dspbridge there. I said nothing about timetables for product
>>>>> 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?
> If Nokia releases one product with dsp-bridge, that counts as a future
> consumer product. I didn't meant to say that there would be no
> dsp-link consumer products in the future, but as a matter of fact if
> there has never been any before, I fail to see why would there be any
> later on.
Are you seriously suggesting that *nobody* has ever used
dsplink/codecengine? If that were true, why would TI keep working on
> But anyway, lets assume there are products using dsp-link... that
> doesn't change the fact that only tidspbridge has been requested for
> inclusion in FFmpeg.
To date and as far as you know.
> What is the problem with tidsp if it doesn't conflict with the plans
> of anybody else? There would be no tidsp-link, if anything it would be
> tice. And even if for some reason somebody in the future managed to
> get something working without CodecEngine (not sure if it's possible),
> the name tidsp-link wouldn't conflict, *THEN* we might decide to
> change the name of tidsp.
> What's the point of discussing about this now?
To keep names accurate and avoid future conflicts of course.
mans at mansr.com
More information about the ffmpeg-devel