Re: [RFC] V4L2 codecs in user space
Am 08.06.2015 um 12:04 schrieb Hans Verkuil: big_snip / Just curious: as we're talking about userland libraries, why not just using gstreamer ? --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 19:54 schrieb Robert Schwebel: By the way: i still have some your older patches (2012) in my tree, eg. some mediabus, camara, display timing stuff, etc ... not sure whether I really need them for my device. Should I post them to linux-media list for review? No. That's all old stuff and has developed quite a lot since then. We'll post new series here on the lists when they are ready for mainline. Great :) Do you have them on some public repo, so I can give 'em a try ? --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 13:59 schrieb Philipp Zabel: Where can I get the recent ones ? Could you push it to your public repo ? I've updated the tmp/imx-ipu-scaler branch. Thx. already integrated it into my tree - works fine :) By the way: i still have some your older patches (2012) in my tree, eg. some mediabus, camara, display timing stuff, etc ... not sure whether I really need them for my device. Should I post them to linux-media list for review ? Oh, and I also still have your famous DRM_IOCTL_MODE_MAP_DUMB hack (the Reluctantly-signed-off-by: one ;-), meanwhile rebased / adapted into 4.x. Do you have any idea, what the amd-gpu driver/library exactly does with the retrieved address ? Send it directly to the gpu ? That should be capture-io-mode=dmabuf for the decoder and output-io-mode=dmabuf-import for the converter element. h264parse doesn't provide and fbdevsink can't handle dmabufs, so the decoder's output-io-mode and the converter's capture-io-mode should be kept as mmio. I played around a little bit - this command line only takes 55% cpu: gst-launch-1.0 filesrc location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec output-io-mode=4 capture-io-mode=4 \! v4l2 video0convert capture-io-mode=4 output-io-mode=5 \! fbdevsink By the way: what's the exact difference between dmabuf and dmabuf-import ? By the way: do you have any idea whether the proprietary driver (or the gpus itself) might talk to ipu and vpu ? Not that I am aware of. Well, you perhaps can imagine - I dont trust these guys ... --mtx ps: greetings from Bene ... you won't guess where I met him last weekend ;-) -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 27.05.2015 um 20:42 schrieb Jean-Michel Hautbois: snip @Phillip, I've missed the previous mails (just subscribed here yesterday) ... Are these patches same as in your git branch tmp/imx-ipu-scaler ? I've got them running on 4.0.4 and currently trying on 4.1-rc* Yet another question: when using it w/ gst for video playback, can be directly pass buffers between VPU, IPU and FB (or let them directly write into shared buffers), so CPU doesn't need to act on each frame for each step in the decoding pipeline ? Playing an 800x400 mp4 still produces about 70..75%. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 12:44 schrieb Philipp Zabel: Hi, Are these patches same as in your git branch tmp/imx-ipu-scaler ? No, that is an older version. Where can I get the recent ones ? Could you push it to your public repo ? when using it w/ gst for video playback, can be directly pass buffers between VPU, IPU and FB (or let them directly write into shared buffers), so CPU doesn't need to act on each frame for each step in the decoding pipeline ? Check out the (capture/output-)io-mode parameters, that's what the dmabuf/dmabuf-import option pairs are for. Tried dmabuf, but load stays at the same (77..80% CPU, 1.2 loadavg). dmabuf-import doesnt run at all: root@KoMo:/usr/share/videos/komo gst-launch-1.0 filesrc location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec output-io-mode=5 \! v4l2video0convert capture-io-mode=5 output-io-mode=4 \! fbdevsink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: No downstream pool to import from. Additional debug info: gstv4l2object.c(3441): gst_v4l2_object_decide_allocation (): /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: When importing DMABUF or USERPTR, we need a pool to import from ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Perhaps not implemented yet in the old version of the patches ? By the way: do you have any idea whether the proprietary driver (or the gpus itself) might talk to ipu and vpu ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Media controller entity information property API
Am 28.05.2015 um 11:27 schrieb Mauro Carvalho Chehab: Hi folks, just subscribed to the list, so I might have missed something snip Constructing unique names that are human readable, stable, unique and fit to 31 characters reserved for the purpose is not thought to be possible: device bus string that would be in some cases enough to uniquely identify a device any be longer than that. On hot-pluggable busses e.g. a serial number is needed. Dont we have any chance of lifting that restriction ? From a userland PoV, I'd really like to see them via path names (and actually access them directly via their own files) The structure of the properties tree can be non-trivial. This RFC defines a text representation format of the tree to facilitate discussing and documenting the tree structure separately from its binary representation used in IOCTL calls. The terms are used elsewhere in the document. Does it have to be an IOTCTL ? IOCTL have the unpleasant side effect, that they're hard to transport via network filesystems (in the end, would need special protocol extensions for each single one - assuming we can *safely* detect, which IOCTL really was called) Instead I'd prefer some pure filesystem-based approach - like @Plan9 or sysfs. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: imx53 IPU support on 4.0.4
Am 20.05.2015 um 15:21 schrieb Fabio Estevam: Hi, (Haven't 4.1rc* yet, as it broke some other things for me.) What are the regressions you see? Trouble w/ emmc/sd suddenly being ro. Guess, something in with the corresponding APIs changed and I didn't rebase correctly. It's now several weeks ago (IIRC, on rc1) - I'm currently rebasing everything again to the recent master. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: imx53 IPU support on 4.0.4
Am 20.05.2015 um 22:55 schrieb Russell King - ARM Linux: Hi, The way kernel development works is that patches are sent to mailing lists for review. Kernel developers review the patches and provide comments back. The comments are discussed and actioned, and a new set of patches posted for further review. This cycle repeats. Okay. I just wanted to prevent too much traffic. But I'll use git-send-email, if you prefer. When everyone is happy, the patches can be applied, or pulled from a non-github git tree. (Kernel people generally don't like github.) Why so ? This is so that upstream kernel developers don't get too overloaded with work that really should be done by downstream folk (imagine if they had to rewrite every patch that came their way...) Of course. I wasn't aware of the separate linux-media maillist at that time. By the way: I've now moved to Phillip's recent ipuv3 patches, but still have lots of others (about 30) for my tqma53-based board, which might be generic enough for going into mainline someday (many of them by ptx folks). Should I post them to lkml or somewhere else ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
imx53 IPU support on 4.0.4
Hi folks, I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 (Haven't 4.1rc* yet, as it broke some other things for me.) cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How implement Secure Data Path ?
Am 08.05.2015 um 10:37 schrieb Daniel Vetter: dma-buf user handles are fds, which means anything allocated can be passed around nicely already. The question really is whether we'll have one ioctl on top of a special dev node or a syscall. I thought that in these cases where the dev node is only ever used to allocate the real thing, a syscall is the preferred way to go. I'd generally prefer a /dev node instead of syscall, as they can be dynamically allocated (loaded as module, etc), which in turn offers more finer control (eg. for containers, etc). One could easily replace the it with its own implementation (w/o patching the kernel directly and reboot it). Actually, I'm a bit unhappy with the syscall inflation, in fact I'm not even a big friend of ioctl's - I'd really prefer the Plan9 way :p I guess the same kind of logic as with GEM (except preferably without the DoS security holes) applies as to why its useful to have handles to the DMA buffers. We have handles (well file descriptors) to dma-bufs already, I'm a bit confused what you mean? Just curious (as I'm pretty new to this area): how to GEM objects and dma-bufs relate to each other ? Is it possible to directly exchange buffers between GPUs, VPUs, IPUs, FBs, etc ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
