Linux kernel with rpmsg and possibility for compiling powervr drivers
mertsas at cisco.com
Mon Mar 19 07:14:16 UTC 2012
On 03/17/12 01:13, Andy Green wrote:
> On 03/17/2012 04:14 AM, Somebody in the thread at some point said:
>> On Fri, Mar 16, 2012 at 10:58 AM, Martin Ertsas (mertsas)
>> <mertsas at cisco.com> wrote:
>>> Sent from Samsung Mobile
>>> Andy Green <andy.green at 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.
>>>> 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
> 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.
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?
More information about the linaro-dev