The fact that a phone was *announced* at CES (reference?) with it,
doesn't mean it's production ready, just that one company is betting
on it being stable by release time. And also, products are released
with code that is not really production ready.
It is true that TI is working on the linux-omap-pm branch, but they
disagree on the pm architecture, that's why they have a fork at omapzoom.org. The dsp-bridge at omapzoom is maintained by TI, while
the one in linux-omap is maintained by Ameya (previously Hiroshi):
Well, generally a patch with that impact on a driver has to go through
lots of testing to be merged , it just doesn't magically appear or
work... or do they? if so, let me know because lots of cleanup is need
at: https://www.omapzoom.org/gf/project/omapbridge/tracker/
The fact that a phone was *announced* at CES (reference?) with it,
doesn't mean it's production ready, just that one company is betting
on it being stable by release time. And also, products are released
with code that is not really production ready.
and betting to be some phone killer too but nowadays all want the
same thing
It is true that TI is working on the linux-omap-pm branch, but they
disagree on the pm architecture, that's why they have a fork at
omapzoom.org. The dsp-bridge at omapzoom is maintained by TI, while
the one in linux-omap is maintained by Ameya (previously Hiroshi):
Well, generally a patch with that impact on a driver has to go through
lots of testing to be merged , it just doesn't magically appear or
work... or do they? if so, let me know because lots of cleanup is need
at: https://www.omapzoom.org/gf/project/omapbridge/tracker/
Sorry? There are different kinds of cleanup patches. If the cleanup is
good it should not alter functionality, but mistakes happen, that's
why testing is needed. Some cleanup patches have a higher risk of
introducing bugs.
Thanks for the cleanup patches, but let's say things as they are;
critical bugfixes are coming in all the time, this one for example is
definitely not a cleanup, or I least I noticed an impressive
improvement in stability with it: http://marc.info/?l=linux-omap&m=124028261217376&w=2
The fact that a phone was *announced* at CES (reference?) with it,
doesn't mean it's production ready, just that one company is betting
on it being stable by release time. And also, products are released
with code that is not really production ready.
and betting to be some phone killer too but nowadays all want the
same thing
If course, but until it's not released you cannot say much about the
stability of it's software.
It is true that TI is working on the linux-omap-pm branch, but they
disagree on the pm architecture, that's why they have a fork at
omapzoom.org. The dsp-bridge at omapzoom is maintained by TI, while
the one in linux-omap is maintained by Ameya (previously Hiroshi):
You mean it wasn't on Tony's tree? I believe Tony has expressed no
interest on maintaining the tidspbridge branch, so it's maintained on
Ameya's repo at gitorious.
This is my /lib/dsp:
baseimage.dof
dctn_dyn.dll64P
mpeg4aacdec_sn.dll64P
mp4vdec_sn.dll64P
postprocessor.dll64P
vpp_sn.dll64P
ringio.dll64P
usn.dll64P
All the content in /lib/dsp/ were generated by running
"./tiopenmax-0.3.5/TI-OMX-Sample-Firmware-0.3-Linux-x86-Install" on
vmware
linux.
I have one another problem. What difference between tiopenmax-0.3
and
libomxil-ti;
I did not compile the tiopenmax-0.3; Only ran
"TI-OMX-Sample-Firmware-0.3-Linux-x86-Install"
in it to generate the dof file and dll64P file (/lib/dsp/*)
Hi,Felipe:
I am reseaching how to enalbe dsp on BeagleBoard; But I have
problem with dsp-bridge way;
I follow [1] and [2];
But at last,i run the command [3];I get the errors of the gst-
omapfb; The errror message is as below:
but nowadays all want the
