Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
On 09.07.19 10:41, Jerry-ch Chen wrote:
Hi,
> diff --git a/drivers/media/platform/mtk-isp/fd/mtk_fd.h
> b/drivers/media/platform/mtk-isp/fd/mtk_fd.h
> new file mode 100644
> index 000..28b
> --- /dev/null
> +++ b/drivers/media/platform/mtk-isp/fd/mtk_fd.h
> @@ -0,0 +1,157 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +//
> +// Copyright (c) 2018 MediaTek Inc.
> +
> +#ifndef __MTK_FD_HW_H__
> +#define __MTK_FD_HW_H__
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MTK_FD_OUTPUT_MIN_WIDTH 26U
> +#define MTK_FD_OUTPUT_MIN_HEIGHT 26U
> +#define MTK_FD_OUTPUT_MAX_WIDTH 640U
> +#define MTK_FD_OUTPUT_MAX_HEIGHT 480U
> +
> +/* Control the user defined image widths and heights
> + * to be scaled and performed face detection in FD HW.
> + * MTK FD support up to 14 user defined image sizes to perform face
> detection.
> + */
> +#define V4L2_CID_MTK_FD_SCALE_IMG_WIDTH
> (V4L2_CID_USER_MTK_FD_BASE + 1)
> +#define V4L2_CID_MTK_FD_SCALE_IMG_HEIGHT (V4L2_CID_USER_MTK_FD_BASE + 2)
I've got a *really* bad feeling about introducing chip specific
uapi stuff. (by the way: uapi stuff belongs into include/uapi/...)
Maybe you could tell us what that's *really* about, so we can find some
standard / chip-independent api for these things. That's one of the
major point of the kernel: hardware abstraction.
> +#define ENABLE_FD0x111
> +#define FD_HW_ENABLE 0x4
> +#define FD_INT_EN0x15c
> +#define FD_INT 0x168
> +#define FD_RESULT0x178
> +#define FD_IRQ_MASK 0x001
> +
> +#define RS_MAX_BUF_SIZE 2288788
> +#define FD_MAX_SPEEDUP 7
> +#define FD_MAX_POSE_VAL 0xfff
> +#define FD_DEF_POSE_VAL 0x3ff
> +#define MAX_FD_SEL_NUM 1026
If that file is supposed to be included by anything beyond the driver
itself, we need proper prefixing. (same for anything else in here)
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h
> index 3dcfc61..eae876e 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -192,6 +192,10 @@ enum v4l2_colorfx {
> * We reserve 16 controls for this driver. */
> #define V4L2_CID_USER_IMX_BASE (V4L2_CID_USER_BASE +
> 0x10b0)
>
> +/* The base for the mediatek FD driver controls */
> +/* We reserve 16 controls for this driver. */
> +#define V4L2_CID_USER_MTK_FD_BASE(V4L2_CID_USER_BASE + 0x10d0)
Why only the base, but not the actual IDs in uapi ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Re: [RFC] SW connection between DVB Transport Stream demuxer and I2C-based frontend
On 08.07.19 17:03, Marc Gonzalez wrote: > One problem is that since the internal bus is "created" (declared?) at > run-time, > it doesn't seem possible to define it (or its client) in DT. Maybe declare it nested inside the si2168 device ? The driver then needs a piece of glue code for triggering device probing on that bus. (so, it really needs to provide a full blown i2c driver ?) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [RFC] SW connection between DVB Transport Stream demuxer and I2C-based frontend
On 08.07.19 13:08, Marc Gonzalez wrote: > The tuner (si2157) is not on the i2c5 bus, instead it is on a private > i2c bus *behind* si2168, which routes requests to the proper client. Should the si2168 make up it's own i2c controller ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [RFC] V4L2 codecs in user space
Am 08.06.2015 um 12:04 schrieb Hans Verkuil: 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: 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
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: [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 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: [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: @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
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
