On 03/17/12 01:13, Andy Green wrote:
On 03/17/2012 04:14 AM, Somebody in the thread at some point said:
Mertsas,
On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas) mertsas@cisco.com wrote:
Sent from Samsung Mobile
Andy Green andy.green@linaro.org wrote: On 03/16/2012 10:46 PM, Somebody in the thread at some point said:
If you look at tilt-android-tracking, there is a complete 1.8 SGX (usable on ICS) on fairly recent basis which includes its own rpmsg stack as part of the SGX port. The matching userlands are available via google AOSP.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=short...
We also have what's currently only working on
I was a bit unclear. Sorry. First, we are thinking of using Linux for this task instead of Android. We want rpmsg support to get access to the m3 devices for h264 encoding and decoding. with pvr I basically meant a dss which can be used to compile rsalvetis pvr omap 4 kernel module.
Bit unclear is an understatement in this case ^^ rpmsg is a complete red herring then.
1.7 SGX as currently used in Ubuntu does not use rpmsg. All the currently available mm decode solutions for Ubuntu don't use it yet either, they use its predecessor "syslink".
If you check out tilt-3.1 branch from our repo that has working syslink
- tiler pieces needed by the mm decode pieces in Ubuntu and will build
against SGX dkms.
I seemed to have missed some conversation here. Just wanted to check if you still have trouble getting a kernel with rpmsg and pvr? I am not aware of the pvr part of things but for the rpmsg stuff, like Andy mentioned the one tilt has is a different from the up-streamed one. You will get a lot more features in the tilt version of it. The flip side being, it is dependent on ion. Can you elaborate what you are trying to achieve with rpmsg? You definitely need tiler driver support too to get h264 decoder working. Personally, I think , you are better off moving to rpmsg, as you can expect more support in future on this. I might not be aware of all the minute details but could help you out on the rpmsg part.
Agreed rpmsg has deprecated syslink going on, and medium or long term planning will need to be around that.
However for Ubuntu, there's not quite yet anything rpmsg-based that's workable to give him mm decode (it seems to be that he's interested in) that will provide userland pieces he can have as a normal mortal as well.
Rob Clark is working on something that should bear fruit soon, Nice guys will provide matching Ubuntu pieces and TILT will integrate it into our tracking.
Until then tilt-3.1 + Ubuntu packages already there seems the best choice to getting something known to work end-end quickly. Since it integrates to gstreamer already when he upgrades to rpmsg-based solution (userland too) it should hopefully be transparent.
-Andy
The reason we want rpmsg is to get h264 endcoding and decoding using gstreamer elements. I'm not sure if gst-ducati works with syslink as well? Andy is right that it is mm decode/encode I am interested in.
So if I have understood you right: For the time being, I should use tilt-3.1 with syslink and gst-ducati (or some other gst element?) to get mm h264 encoding/decoding working on the omap. And when rpmsg is in a stable upstream/tilt kernel, I can switch to that and still use gst-ducati?
- Martin