On Tue 9 April 2013 11:57:51 Michal Lazo wrote: > Amlogic provide only 2.6.34 driver > can I expect big performance loss ? Why do so many companies stick to ancient kernels? I can never understand that. You have three options: 1) update their driver to a recent kernel 2) create a v4l2 driver for 2.6.34. But in that case you can't use the videobuf2 framework which appeared in a later kernel and which greatly simplifies the work of writing a v4l2 driver. 3) it's possible to backport the whole of drivers/media to a 2.6.34 kernel. It will generate a huge patch (>30 MB), but you will have a modern V4L2 kernel environment. Note that none of this matters for performance. I would pick either option 1 or 3. Instructions on how to do option 3 are: 1) Clone this git repo: http://git.linuxtv.org/hverkuil/cisco_build.git 2) Switch to the cobalt-mainline branch. 3) Edit patch-kernel.sh and modify the 'target', 'orig_source' and 'source' paths. 4) Run patch-kernel.sh The resulting media.patch file should apply cleanly to your source kernel. Note that the source kernel should be your vendor supplied kernel without any of your own patches that you might normally apply on top of it. Regards, Hans > > On Tue, Apr 9, 2013 at 11:09 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > On Tue 9 April 2013 10:52:41 Michal Lazo wrote: > >> As we have all source codes > >> what do you advice ? > > > > Write your own driver. Good templates to look at are drivers/media/pci/sta2x11 > > and drivers/media/platform/blackfin. > > > > The first is functionality-wise probably closer to what you need, but it's a pci > > driver, so the blackfin platform driver can be used to look at the platform part. > > > > Pick as recent a kernel as you can, but 3.6 at minimum since it has the useful > > vb2 helper functions that the sta2x11 driver also uses. > > > > Regards, > > > > Hans > > > >> > >> > >> On Tue, Apr 9, 2013 at 10:38 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > >> > On Tue 9 April 2013 09:58:33 Michal Lazo wrote: > >> >> I want to make API that will provide hw video decoder on Amlogic SOC > >> >> it is ARM cortex 9 > >> >> > >> >> with some proprietary video decoder > >> >> > >> >> amlogic provide me with working example that generate output frames in > >> >> amlvideo driver. > >> >> It is v4l2 driver > >> >> and it did memcpy to mmap userspace memory > >> >> > >> >> buffer_y_start=ioremap(cs0.addr,cs0.width*cs0.height); > >> >> for(i=0;i<buf->vb.height;i++) { > >> >> memcpy(vbuf + pos_dst, buffer_y_start+pos_src, buf->vb.width*3); > >> >> pos_dst+=buf->vb.width*3; > >> >> pos_src+= cs0.width; > >> >> } > >> >> > >> >> I did it with one memcpy with same cpu load > >> >> > >> >> https://github.com/Pivosgroup/buildroot-linux-kernel/blob/master/drivers/media/video/amlvideo/amlvideo.c#L218 > >> >> > >> >> top get me 50% cpu load on this driver for 25fps PAL > >> >> > >> >> it is really too much > >> >> > >> >> and funny is that vivi driver(amlvideo is completely base on vivi) get > >> >> me same cpu load > >> > > >> > Well, yes, because it is the memcpy that gives you all the load. > >> > Of course, in a well-written driver the amlvideo buffers would be available > >> > to userspace directly using mmap() and no memcpy would be needed. > >> > > >> > Basically amlogic gave you a crappy driver. > >> > > >> > Regards, > >> > > >> > Hans > >> > > >> >> > >> >> it looks like memcpy isn't cached or something but I don't know how to > >> >> identify problem > >> >> Any idea how to identify this problem. > >> >> > >> >> On Mon, Apr 8, 2013 at 2:46 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > >> >> > On Mon April 8 2013 14:42:32 Michal Lazo wrote: > >> >> >> Hi > >> >> >> 720x576 RGB 25, 30 fps and it take > >> >> >> > >> >> >> 25% cpu load on raspberry pi(ARM 700Mhz linux 3.6.11) or 8% on x86(AMD > >> >> >> 2GHz linux 3.2.0-39) > >> >> >> > >> >> >> it is simply too much > >> >> > > >> >> > No, that's what I would expect. Note that vivi was substantially improved recently > >> >> > when it comes to the image generation. That will be in the upcoming 3.9 kernel. > >> >> > > >> >> > This should reduce CPU load by quite a bit if memory serves. > >> >> > > >> >> > Regards, > >> >> > > >> >> > Hans > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Mon, Apr 8, 2013 at 9:42 AM, Peter Senna Tschudin > >> >> >> <peter.senna@xxxxxxxxx> wrote: > >> >> >> > Dear Michal, > >> >> >> > > >> >> >> > The CPU intensive part of the vivi driver is the image generation. > >> >> >> > This is not an issue for real drivers. > >> >> >> > > >> >> >> > Regards, > >> >> >> > > >> >> >> > Peter > >> >> >> > > >> >> >> > On Sun, Apr 7, 2013 at 9:32 PM, Michal Lazo <michal.lazo@xxxxxxxxxxx> wrote: > >> >> >> >> Hi > >> >> >> >> V4L2 driver vivi > >> >> >> >> generate 25% cpu load on raspberry pi(linux 3.6.11) or 8% on x86(linux 3.2.0-39) > >> >> >> >> > >> >> >> >> player > >> >> >> >> GST_DEBUG="*:3,v4l2src:3,v4l2:3" gst-launch-0.10 v4l2src > >> >> >> >> device="/dev/video0" norm=255 ! video/x-raw-rgb, width=720, > >> >> >> >> height=576, framerate=30000/1001 ! fakesink sync=false > >> >> >> >> > >> >> >> >> Anybody can answer me why? > >> >> >> >> And how can I do it better ? > >> >> >> >> > >> >> >> >> I use vivi as base example for my driver > >> >> >> >> -- > >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-media" in > >> >> >> >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > Peter > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> >> > >> > >> > >> > >> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
