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) >> <mert...@cisco.com> wrote: >>> >>> >>> >>> >>> Sent from Samsung Mobile >>> >>> Andy Green <andy.gr...@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;a=shortlog;h=refs/heads/tilt-android-tracking >>>> >>>> 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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
