cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jun 18 04:00:17 CEST 2015 git branch: test git hash: e42c8c6eb456f8978de417ea349eef676ef4385c gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1-rc1-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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 v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 14 June 2015 at 02:44, David Härdeman wrote: > One idea that I've had in the back of my head for a long time is to use the > "flags" member of "struct rc_keymap_entry" in the new EVIOC[GS]KEYCODE_V2 > ioctl variant (see http://www.spinics.net/lists/linux-media/msg88452.html). > > If a RC_POWERON flag was defined, it could be used for that purpose... > Ooh, that approach would indeed provide a cleaner api for setting the wakeup scancode. I like the idea though I haven't really had the chance to try it out. > ... >> >> I'm sorry that the encoding functionality clashes with your intentions >> of improving the rc-core. I guess Mauro likes encoders more than >> improving rc-core fundamentals :) >> Kidding aside the fact that this series got merged might suggest that >> you and Mauro don't necessarily share the same views about the future >> and possible api breaks of rc-core. > > > If you've followed the development of rc-core during the last few years it > should be pretty clear that Mauro has little to no long-term plan, > understanding of the current issues or willingness to fix them. I wouldn't > read too much into the fact that the code was merged. > >> Tell you what, I'll agree to reverting the series. In exchange I would >> hope that you and Mauro mutually agree and let me know on: >> - What are the issues that need to be fixed in the encoding series >> prefarably with how to fix them (e.g. module load order ambiquity, >> whether a new api is needed, or switching to a more limited >> functionality is desired like you suggested then so be it etc.) >> - When is a good chance to re-submit the series (e.g. after >> ioctl/scancode/whatever api break is done or some pending series is >> merged or some other core refactoring work is finished etc.) >> >> Deal? > > > Maurowake up? I hope you're not planning to push the current code > upstream??? > Yeah, I'm also inclined to target for a longer term solution with this so the current patches can be reverted. I think I now also have enough information to go and respin the patches to utilize the new EVIOCSKEYCODE_V2 if and when that gets included in the rc-core. -- Antti -- 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: solo6x10: all interrupts for all cards handled by CPU0, no balancing - why?
On Fri, 30 Jan 2015 00:29:13 +0200 Andrey Utkin wrote: > The host was rebooted and got back online. > Without irqbalance daemon, all solo6x10 interrupts are still on CPU0. > See https://gist.github.com/krieger-od/d1686243c67fbe3e14a5 > Any ideas are strongly appreciated. > My understanding was that balancing happened by package, not by core, but my knowledge might be outdated... -- 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 PATCH 2/3] make struct vb2_queue to common and apply the changes related with that.
Em Mon, 08 Jun 2015 22:35:34 +0900 Junghak Sung escreveu: > Abstract the v4l2-specific members of the struct vb2_queue, > and concrete it in the side of user. > For example, the struct vb2_v4l2_buffer can be abstracted by using > struct vb2_buffer, and concrete it by using container_of() in a device driver. > > Signed-off-by: Junghak Sung > --- > drivers/media/dvb-frontends/rtl2832_sdr.c | 13 +- > drivers/media/pci/cx23885/cx23885-417.c| 23 +- > drivers/media/pci/cx23885/cx23885-dvb.c| 24 +- > drivers/media/pci/cx23885/cx23885-vbi.c| 27 +- > drivers/media/pci/cx23885/cx23885-video.c | 27 +- > drivers/media/pci/cx25821/cx25821-video.c | 28 +- > drivers/media/pci/cx88/cx88-blackbird.c| 25 +- > drivers/media/pci/cx88/cx88-dvb.c | 25 +- > drivers/media/pci/cx88/cx88-vbi.c | 27 +- > drivers/media/pci/cx88/cx88-video.c| 27 +- > drivers/media/pci/saa7134/saa7134-empress.c|2 +- > drivers/media/pci/saa7134/saa7134-ts.c | 26 +- > drivers/media/pci/saa7134/saa7134-vbi.c| 22 +- > drivers/media/pci/saa7134/saa7134-video.c | 11 +- > drivers/media/pci/saa7134/saa7134.h|2 +- > drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 15 +- > drivers/media/pci/solo6x10/solo6x10-v4l2.c | 11 +- > drivers/media/pci/sta2x11/sta2x11_vip.c| 32 +- > drivers/media/pci/tw68/tw68-video.c| 28 +- > drivers/media/platform/am437x/am437x-vpfe.c| 21 +- > drivers/media/platform/blackfin/bfin_capture.c | 32 +- > drivers/media/platform/coda/coda-common.c | 30 +- > drivers/media/platform/davinci/vpbe_display.c | 19 +- > drivers/media/platform/davinci/vpif_capture.c | 10 +- > drivers/media/platform/davinci/vpif_display.c | 10 +- > drivers/media/platform/exynos-gsc/gsc-m2m.c| 20 +- > drivers/media/platform/exynos4-is/fimc-capture.c | 25 +- > drivers/media/platform/exynos4-is/fimc-isp-video.c | 29 +- > drivers/media/platform/exynos4-is/fimc-lite.c | 25 +- > drivers/media/platform/exynos4-is/fimc-m2m.c | 18 +- > drivers/media/platform/m2m-deinterlace.c | 24 +- > drivers/media/platform/marvell-ccic/mcam-core.c| 28 +- > drivers/media/platform/mx2_emmaprp.c | 24 +- > drivers/media/platform/omap3isp/ispvideo.c | 18 +- > drivers/media/platform/s3c-camif/camif-capture.c | 21 +- > drivers/media/platform/s5p-g2d/g2d.c | 18 +- > drivers/media/platform/s5p-jpeg/jpeg-core.c| 30 +- > drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 42 +- > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 57 +- > drivers/media/platform/s5p-tv/mixer_video.c|9 +- > drivers/media/platform/sh_veu.c| 25 +- > drivers/media/platform/soc_camera/atmel-isi.c | 34 +- > drivers/media/platform/soc_camera/mx2_camera.c | 37 +- > drivers/media/platform/soc_camera/mx3_camera.c | 36 +- > drivers/media/platform/soc_camera/rcar_vin.c | 16 +- > .../platform/soc_camera/sh_mobile_ceu_camera.c | 49 +- > drivers/media/platform/ti-vpe/vpe.c| 32 +- > drivers/media/platform/vim2m.c | 32 +- > drivers/media/platform/vivid/vivid-sdr-cap.c | 20 +- > drivers/media/platform/vivid/vivid-vbi-cap.c | 22 +- > drivers/media/platform/vivid/vivid-vbi-out.c | 22 +- > drivers/media/platform/vivid/vivid-vid-cap.c | 34 +- > drivers/media/platform/vivid/vivid-vid-out.c | 27 +- > drivers/media/usb/airspy/airspy.c |9 +- > drivers/media/usb/au0828/au0828-vbi.c | 25 +- > drivers/media/usb/au0828/au0828-video.c| 25 +- > drivers/media/usb/em28xx/em28xx-vbi.c | 23 +- > drivers/media/usb/em28xx/em28xx-video.c| 28 +- > drivers/media/usb/go7007/go7007-v4l2.c | 25 +- > drivers/media/usb/hackrf/hackrf.c |9 +- > drivers/media/usb/msi2500/msi2500.c|9 +- > drivers/media/usb/pwc/pwc-if.c | 30 +- > drivers/media/usb/s2255/s2255drv.c | 18 +- > drivers/media/usb/stk1160/stk1160-v4l.c| 13 +- > drivers/media/usb/usbtv/usbtv-video.c |9 +- > drivers/media/usb/uvc/uvc_queue.c | 40 +- > drivers/media/v4l2-core/Makefile |2 +- > drivers/media/v4l2-core/v4l2-mem2mem.c |6 +- > drivers/media/v4l2-core/videobuf2-core.c | 3488 > +--- > drivers/media/v4l2-core/videobuf2-v4l2.c | 615 ++-- > include/media/videobuf2-core.h | 249 +- > include/media/videobuf2-dma-contig.h |4 +- > include/media/
[PATCH] staging: media: lirc: fix coding style error
Fix code indentation error by replacing tab in place of spaces. Signed-off-by: Sunil Shahu --- drivers/staging/media/lirc/lirc_sasem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/lirc/lirc_sasem.c b/drivers/staging/media/lirc/lirc_sasem.c index 8ebee96..12aae72 100644 --- a/drivers/staging/media/lirc/lirc_sasem.c +++ b/drivers/staging/media/lirc/lirc_sasem.c @@ -185,7 +185,7 @@ static void deregister_from_lirc(struct sasem_context *context) __func__, retval); else dev_info(&context->dev->dev, -"Deregistered Sasem driver (minor:%d)\n", minor); + "Deregistered Sasem driver (minor:%d)\n", minor); } -- 1.9.1 -- 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 PATCH 1/3] modify the vb2_buffer structure for common video buffer and make struct vb2_v4l2_buffer
Em Mon, 08 Jun 2015 22:35:33 +0900
Junghak Sung escreveu:
> Make the struct vb2_buffer to common buffer by removing v4l2-specific members.
> And common video buffer is embedded into v4l2-specific video buffer like:
> struct vb2_v4l2_buffer {
> struct vb2_buffervb2;
> struct v4l2_bufferv4l2_buf;
> struct v4l2_planev4l2_planes[VIDEO_MAX_PLANES];
> };
> This changes require the modifications of all device drivers that use this
> structure.
Thanks for the patch!
In general, it looks fine. Just a few comments. See below.
Regards,
Mauro
>
> Signed-off-by: Junghak Sung
> ---
> Documentation/video4linux/v4l2-pci-skeleton.c | 12 +-
> drivers/media/dvb-frontends/rtl2832_sdr.c | 10 +-
> drivers/media/pci/cx23885/cx23885-417.c| 12 +-
> drivers/media/pci/cx23885/cx23885-dvb.c| 12 +-
> drivers/media/pci/cx23885/cx23885-vbi.c| 12 +-
> drivers/media/pci/cx23885/cx23885-video.c | 12 +-
> drivers/media/pci/cx23885/cx23885.h|2 +-
> drivers/media/pci/cx25821/cx25821-video.c | 12 +-
> drivers/media/pci/cx25821/cx25821.h|2 +-
> drivers/media/pci/cx88/cx88-blackbird.c| 14 +-
> drivers/media/pci/cx88/cx88-dvb.c | 14 +-
> drivers/media/pci/cx88/cx88-vbi.c | 12 +-
> drivers/media/pci/cx88/cx88-video.c| 12 +-
> drivers/media/pci/cx88/cx88.h |2 +-
> drivers/media/pci/saa7134/saa7134-empress.c|2 +-
> drivers/media/pci/saa7134/saa7134-ts.c | 10 +-
> drivers/media/pci/saa7134/saa7134-vbi.c| 12 +-
> drivers/media/pci/saa7134/saa7134-video.c | 18 +-
> drivers/media/pci/saa7134/saa7134.h|8 +-
> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 14 +-
> drivers/media/pci/solo6x10/solo6x10-v4l2.c |6 +-
> drivers/media/pci/solo6x10/solo6x10.h |4 +-
> drivers/media/pci/sta2x11/sta2x11_vip.c| 20 +-
> drivers/media/pci/tw68/tw68-video.c| 12 +-
> drivers/media/pci/tw68/tw68.h |2 +-
> drivers/media/platform/am437x/am437x-vpfe.c| 16 +-
> drivers/media/platform/am437x/am437x-vpfe.h|2 +-
> drivers/media/platform/blackfin/bfin_capture.c | 20 +-
> drivers/media/platform/coda/coda-bit.c | 20 +-
> drivers/media/platform/coda/coda-common.c | 24 +-
> drivers/media/platform/coda/coda-jpeg.c|2 +-
> drivers/media/platform/coda/coda.h |6 +-
> drivers/media/platform/davinci/vpbe_display.c |8 +-
> drivers/media/platform/davinci/vpif_capture.c | 16 +-
> drivers/media/platform/davinci/vpif_capture.h |2 +-
> drivers/media/platform/davinci/vpif_display.c | 18 +-
> drivers/media/platform/davinci/vpif_display.h |6 +-
> drivers/media/platform/exynos-gsc/gsc-core.c |2 +-
> drivers/media/platform/exynos-gsc/gsc-core.h |6 +-
> drivers/media/platform/exynos-gsc/gsc-m2m.c| 16 +-
> drivers/media/platform/exynos4-is/fimc-capture.c | 12 +-
> drivers/media/platform/exynos4-is/fimc-core.c |4 +-
> drivers/media/platform/exynos4-is/fimc-core.h |6 +-
> drivers/media/platform/exynos4-is/fimc-is.h|2 +-
> drivers/media/platform/exynos4-is/fimc-isp-video.c | 14 +-
> drivers/media/platform/exynos4-is/fimc-isp-video.h |2 +-
> drivers/media/platform/exynos4-is/fimc-isp.h |4 +-
> drivers/media/platform/exynos4-is/fimc-lite.c | 10 +-
> drivers/media/platform/exynos4-is/fimc-lite.h |4 +-
> drivers/media/platform/exynos4-is/fimc-m2m.c | 16 +-
> drivers/media/platform/m2m-deinterlace.c | 16 +-
> drivers/media/platform/marvell-ccic/mcam-core.c| 24 +-
> drivers/media/platform/marvell-ccic/mcam-core.h|2 +-
> drivers/media/platform/mx2_emmaprp.c | 16 +-
> drivers/media/platform/omap3isp/ispvideo.c |8 +-
> drivers/media/platform/omap3isp/ispvideo.h |4 +-
> drivers/media/platform/s3c-camif/camif-capture.c | 12 +-
> drivers/media/platform/s3c-camif/camif-core.c |2 +-
> drivers/media/platform/s3c-camif/camif-core.h |4 +-
> drivers/media/platform/s5p-g2d/g2d.c | 16 +-
> drivers/media/platform/s5p-jpeg/jpeg-core.c| 30 +-
> drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +-
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +-
> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 10 +-
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 18 +-
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c|2 +-
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|2 +-
> drivers/media/platform/s5p-tv/mixer.h |4 +-
> drivers/media/platform/s5p-tv/mixer_
[PATCH 1/2] create SMAF module
Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred allocation (i.e. allocate memory when only really needed)
Allocation modules (smaf-alloctor.h):
SMAF could manage with multiple allocation modules at same time.
To select the good one SMAF call match() to be sure that a module
can allocate memory for a given list of devices. It is to the module
to check if the devices are compatible or not with it allocation
method.
Securing module (smaf-secure.h):
The way of how securing memory it is done is platform specific.
Secure module is responsible of grant/revoke memory access.
Signed-off-by: Benjamin Gaignard
---
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 5 +
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-core.c | 674 +
include/linux/smaf-allocator.h | 43 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 48 +++
8 files changed, 836 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..2421fcb 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -182,4 +182,6 @@ source "drivers/thunderbolt/Kconfig"
source "drivers/android/Kconfig"
+source "drivers/smaf/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 46d2554..0cca66e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
obj-$(CONFIG_ANDROID) += android/
+obj-$(CONFIG_SMAF) += smaf/
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
new file mode 100644
index 000..d36651a
--- /dev/null
+++ b/drivers/smaf/Kconfig
@@ -0,0 +1,5 @@
+config SMAF
+ tristate "Secure Memory Allocation Framework"
+ depends on DMA_SHARED_BUFFER
+ help
+ Choose this option to enable Secure Memory Allocation Framework
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
new file mode 100644
index 000..40cd882
--- /dev/null
+++ b/drivers/smaf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SMAF) += smaf-core.o
diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
new file mode 100644
index 000..b1e787e
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,674 @@
+/*
+ * smaf.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct smaf_handle {
+ struct dma_buf *dmabuf;
+ struct smaf_allocator *allocator;
+ struct dma_buf *db_alloc;
+ size_t length;
+ unsigned int flags;
+ int fd;
+ bool is_secure;
+ void *secure_ctx;
+};
+
+/**
+ * struct smaf_device - smaf device node private data
+ * @misc_dev: the misc device
+ * @head: list of allocator
+ * @lock: list and secure pointer mutex
+ * @secure:pointer to secure functions helpers
+ */
+struct smaf_device {
+ struct miscdevice misc_dev;
+ struct list_head head;
+ /* list and secure pointer lock*/
+ struct mutex lock;
+ struct smaf_secure *secure;
+};
+
+static struct smaf_device smaf_dev;
+
+/**
+ * smaf_allow_cpu_access return true if CPU can access to memory
+ * if their is no secure module associated to SMAF assume that CPU can get
+ * access to the memory.
+ */
+static bool smaf_allow_cpu_access(struct smaf_handle *handle,
+ unsigned long flags)
+{
+ if (!handle->is_secure)
+ return true;
+
+ if (!smaf_dev.secure)
+ return true;
+
+ if (!smaf_dev.secure->allow_cpu_access)
+ return true;
+
+ return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, flags);
+}
+
+static int smaf_grant_access(struct smaf_handle *handle, struct device *dev,
+dma_addr_t addr, size_t size,
+enum dma_data_direction dir)
+{
+ if (!handle->is_secure)
+ return 0;
+
+ if (!smaf_dev.secure)
+ return -EINVAL;
+
+ if (!smaf_dev.secure->grant_access)
+ return -EINVAL;
+
+ return smaf_dev.secure->grant_access(handle->secure_ctx,
+
[PATCH 2/2] SMAF: add CMA allocator
SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.
match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).
For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to be compatible with ARM 64bits architecture
Signed-off-by: Benjamin Gaignard
---
drivers/smaf/Kconfig| 6 ++
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-cma.c | 198
3 files changed, 205 insertions(+)
create mode 100644 drivers/smaf/smaf-cma.c
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index d36651a..058ec4c 100644
--- a/drivers/smaf/Kconfig
+++ b/drivers/smaf/Kconfig
@@ -3,3 +3,9 @@ config SMAF
depends on DMA_SHARED_BUFFER
help
Choose this option to enable Secure Memory Allocation Framework
+
+config SMAF_CMA
+ tristate "SMAF CMA allocator"
+ depends on SMAF && HAVE_DMA_ATTRS
+ help
+ Choose this option to enable CMA allocation within SMAF
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 40cd882..05bab01 100644
--- a/drivers/smaf/Makefile
+++ b/drivers/smaf/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SMAF) += smaf-core.o
+obj-$(CONFIG_SMAF_CMA) += smaf-cma.o
diff --git a/drivers/smaf/smaf-cma.c b/drivers/smaf/smaf-cma.c
new file mode 100644
index 000..b3ebd57
--- /dev/null
+++ b/drivers/smaf/smaf-cma.c
@@ -0,0 +1,198 @@
+/*
+ * smaf-cma.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+
+struct smaf_cma_buffer_info {
+ struct device *dev;
+ size_t size;
+ void *vaddr;
+ dma_addr_t paddr;
+};
+
+/**
+ * find_matching_device - iterate over the attached devices to find one
+ * with coherent_dma_mask correctly set to DMA_BIT_MASK(32).
+ * Matching device (if any) will be used to aim CMA area.
+ */
+static struct device *find_matching_device(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach_obj;
+
+ list_for_each_entry(attach_obj, &dmabuf->attachments, node) {
+ if (attach_obj->dev->coherent_dma_mask == DMA_BIT_MASK(32))
+ return attach_obj->dev;
+ }
+
+ return NULL;
+}
+
+/**
+ * smaf_cma_match - return true if at least one device has been found
+ */
+static bool smaf_cma_match(struct dma_buf *dmabuf)
+{
+ return !!find_matching_device(dmabuf);
+}
+
+static void smaf_cma_release(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ dma_free_attrs(info->dev, info->size, info->vaddr, info->paddr, &attrs);
+
+ kfree(info);
+}
+
+static struct sg_table *smaf_cma_map(struct dma_buf_attachment *attachment,
+enum dma_data_direction direction)
+{
+ struct smaf_cma_buffer_info *info = attachment->dmabuf->priv;
+ struct sg_table *sgt;
+ int ret;
+
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return NULL;
+
+ ret = dma_get_sgtable(info->dev, sgt, info->vaddr,
+ info->paddr, info->size);
+ if (ret < 0)
+ goto out;
+
+ sg_dma_address(sgt->sgl) = info->paddr;
+ return sgt;
+
+out:
+ kfree(sgt);
+ return NULL;
+}
+
+static void smaf_cma_unmap(struct dma_buf_attachment *attachment,
+ struct sg_table *sgt,
+ enum dma_data_direction direction)
+{
+ /* do nothing */
+}
+
+static int smaf_cma_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+ int ret;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ if (info->size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ ret = dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
+info->size, &attrs);
+
+ return ret;
+}
+
+static void *smaf_cma_vmap(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return info->vaddr;
+}
+
+static void *smaf_kmap_atomic(struct dma_buf *dmabuf, unsigned long offset)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return (void *)info->paddr + offset;
+}
+
+static struct dma_buf_ops smaf_cma_ops = {
+ .map_dma_buf = smaf_cma_map,
+ .unmap_dma_buf = smaf_cma_unmap,
+ .mmap = smaf_cma_mmap,
+ .release = smaf_cma_release,
+ .kmap_atomic = smaf_kmap_atomic,
+ .kmap = smaf_kmap_atomic,
+ .vmap = smaf_cma_vmap,
+};
+
+static struct dma_buf *smaf_cma_allocate(struct
[PATCH 0/2] RFC: Secure Memory Allocation Framework
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c| 198
drivers/smaf/smaf-core.c | 674 +
include/linux/smaf-allocator.h | 43 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 48 +++
9 files changed, 1041 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
--
1.9.1
--
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 PATCH 1/3] modify the vb2_buffer structure for common video buffer and make struct vb2_v4l2_buffer
Em Fri, 12 Jun 2015 12:09:00 +0200
Hans Verkuil escreveu:
> On 06/12/2015 11:58 AM, Hans Verkuil wrote:
> > Hi Junghak,
> >
> > On 06/08/2015 03:35 PM, Junghak Sung wrote:
> >> Make the struct vb2_buffer to common buffer by removing v4l2-specific
> >> members.
> >> And common video buffer is embedded into v4l2-specific video buffer like:
> >> struct vb2_v4l2_buffer {
> >> struct vb2_buffervb2;
> >> struct v4l2_bufferv4l2_buf;
> >> struct v4l2_planev4l2_planes[VIDEO_MAX_PLANES];
> >> };
> >> This changes require the modifications of all device drivers that use this
> >> structure.
> >
> > It's next to impossible to review just large diffs, but it is unavoidable
> > for
> > changes like this I guess.
> >
> > I do recommend that you do a 'git grep videobuf2-core' to make sure all
> > usages
> > of that have been replaced with videobuf2-v4l2. I think I saw videobuf2-core
> > mentioned in a comment, but it is hard to be sure.
> >
> > It would also be easier to review if the renaming of core.[ch] to v4l2.[ch]
> > was
> > done in a separate patch. If it is relatively easy to split it up like that,
> > then I would appreciate it, but if it takes a lot of time, then leave it as
> > is.
> >
> > Anyway, assuming that 'git grep videobuf2-core' doesn't find anything:
> >
> > Acked-by: Hans Verkuil
>
> Sorry, I'm retracting that Acked-by: I tried to apply it and I saw it was
> against
> an old kernel version, not against the media_tree master branch.
Well, no matter on what version this patch is produced, it would very
likely cause merge conflicts. The best here would be if you add a
small shell/perl script at the body of the patch that would be doing
the renaming thing at the drivers. This way, the maintainer can run the
script when merging it. That would warrant that this would be changed
everywhere and noting was left behind.
> Also, I thought videobuf2-core.[ch] was renamed to videobuf2-v4l2.[ch], but
> that's
> not the case. I think that would make much more sense. Later patches can
> split up
> videobuf2-v4l2.c/h into a videobuf2-core and -v4l2 part.
> >> copy drivers/media/v4l2-core/{videobuf2-core.c => videobuf2-v4l2.c} (89%)
> >> copy include/media/{videobuf2-core.h => videobuf2-v4l2.h} (94%)
Actually, it is being copied, with is almost the same.
I agree that this series could be better split into:
1) a patch that would be just doing:
mv drivers/media/v4l2-core/videobuf2-core.c
drivers/media/v4l2-core/videobuf2-v4l2.c
mv include/media/videobuf2-core.h include/media/videobuf2-v4l2.h
And changing the includes and Makefile bits to use the new header.
2) this patch (with the script used to produce it);
3) patches that would be gradually moving the common functions from
videobuf2-v4l2.c into videobuf2-core.c.
Regards,
Mauro
--
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: em28xx problem with 3.10-4.0
Em Wed, 17 Jun 2015 08:32:26 +0200 "Gabor Z. Papp" escreveu: > * Mauro Carvalho Chehab : > > | Nothing. You just ran out of continuous memory. This driver > | requires long chunks of continuous memory for USB data transfer. > > And there is no way to preset some mem? > Or do something to get the driver work again? > I don't think I'm using too much memory. > > $ free > total used free sharedbuffers cached > Mem: 2073656 6256961447960 0 21072 231096 > -/+ buffers/cache: 3735281700128 > Swap: 1004056 01004056 >From your error logs, it failed to allocate the 3rd buffer (of a total of 5 buffers) with a continuous block of 165.120 bytes on the DMA range. In order words, your system needs to have at least 5 non-fragmented buffers with 256KB each, on a memory region where the CPU can do DMA (e. g. outside the high memory area). I'm not a memory management specialist, but I guess you could try to change some sysctl parameters or use a different memory allocator in order to avoid memory fragmentation. If you're a C programmer, an option would be to change the driver's code to optimize it for low memory usage, for example, to reduce the buffer size and increasing the number of buffers (at the cost of requiring more CPU and/or reducing the maximum size of the image). Another alternative would be to reserve the memory at the time the driver gets loaded. Regards, Mauro -- 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
[PATCH 1/2] media: atmel-isi: setup the ISI_CFG2 register directly
In the function configure_geometry(), we will setup the ISI CFG2
according to the sensor output format.
It make no sense to just read back the CFG2 register and just set part
of it.
So just set up this register directly makes things simpler.
Currently only support YUV format from camera sensor.
Signed-off-by: Josh Wu
---
drivers/media/platform/soc_camera/atmel-isi.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 9070172..8bc40ca 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -105,24 +105,25 @@ static u32 isi_readl(struct atmel_isi *isi, u32 reg)
static int configure_geometry(struct atmel_isi *isi, u32 width,
u32 height, u32 code)
{
- u32 cfg2, cr;
+ u32 cfg2;
+ /* According to sensor's output format to set cfg2 */
switch (code) {
/* YUV, including grey */
case MEDIA_BUS_FMT_Y8_1X8:
- cr = ISI_CFG2_GRAYSCALE;
+ cfg2 = ISI_CFG2_GRAYSCALE;
break;
case MEDIA_BUS_FMT_VYUY8_2X8:
- cr = ISI_CFG2_YCC_SWAP_MODE_3;
+ cfg2 = ISI_CFG2_YCC_SWAP_MODE_3;
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
- cr = ISI_CFG2_YCC_SWAP_MODE_2;
+ cfg2 = ISI_CFG2_YCC_SWAP_MODE_2;
break;
case MEDIA_BUS_FMT_YVYU8_2X8:
- cr = ISI_CFG2_YCC_SWAP_MODE_1;
+ cfg2 = ISI_CFG2_YCC_SWAP_MODE_1;
break;
case MEDIA_BUS_FMT_YUYV8_2X8:
- cr = ISI_CFG2_YCC_SWAP_DEFAULT;
+ cfg2 = ISI_CFG2_YCC_SWAP_DEFAULT;
break;
/* RGB, TODO */
default:
@@ -130,17 +131,10 @@ static int configure_geometry(struct atmel_isi *isi, u32
width,
}
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
-
- cfg2 = isi_readl(isi, ISI_CFG2);
- /* Set YCC swap mode */
- cfg2 &= ~ISI_CFG2_YCC_SWAP_MODE_MASK;
- cfg2 |= cr;
/* Set width */
- cfg2 &= ~(ISI_CFG2_IM_HSIZE_MASK);
cfg2 |= ((width - 1) << ISI_CFG2_IM_HSIZE_OFFSET) &
ISI_CFG2_IM_HSIZE_MASK;
/* Set height */
- cfg2 &= ~(ISI_CFG2_IM_VSIZE_MASK);
cfg2 |= ((height - 1) << ISI_CFG2_IM_VSIZE_OFFSET)
& ISI_CFG2_IM_VSIZE_MASK;
isi_writel(isi, ISI_CFG2, cfg2);
--
1.9.1
--
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
[PATCH 2/2] media: atmel-isi: move configure_geometry() to start_streaming()
As in set_fmt() function we only need to know which format is been set,
we don't need to access the ISI hardware in this moment.
So move the configure_geometry(), which access the ISI hardware, to
start_streaming() will make code more consistent and simpler.
Signed-off-by: Josh Wu
---
drivers/media/platform/soc_camera/atmel-isi.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 8bc40ca..b01086d 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -390,6 +390,11 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
/* Disable all interrupts */
isi_writel(isi, ISI_INTDIS, (u32)~0UL);
+ ret = configure_geometry(isi, icd->user_width, icd->user_height,
+ icd->current_fmt->code);
+ if (ret < 0)
+ return ret;
+
spin_lock_irq(&isi->lock);
/* Clear any pending interrupt */
isi_readl(isi, ISI_STATUS);
@@ -477,8 +482,6 @@ static int isi_camera_init_videobuf(struct vb2_queue *q,
static int isi_camera_set_fmt(struct soc_camera_device *icd,
struct v4l2_format *f)
{
- struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
- struct atmel_isi *isi = ici->priv;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
const struct soc_camera_format_xlate *xlate;
struct v4l2_pix_format *pix = &f->fmt.pix;
@@ -511,16 +514,6 @@ static int isi_camera_set_fmt(struct soc_camera_device
*icd,
if (mf->code != xlate->code)
return -EINVAL;
- /* Enable PM and peripheral clock before operate isi registers */
- pm_runtime_get_sync(ici->v4l2_dev.dev);
-
- ret = configure_geometry(isi, pix->width, pix->height, xlate->code);
-
- pm_runtime_put(ici->v4l2_dev.dev);
-
- if (ret < 0)
- return ret;
-
pix->width = mf->width;
pix->height = mf->height;
pix->field = mf->field;
--
1.9.1
--
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
[PATCH] media: atmel-isi: increase timeout to disable/enable isi
If ISI is working on a 1024x768 or higher resolution, it needs longer time to disable ISI. So this patch will increase timeout to 500ms. Signed-off-by: Josh Wu --- drivers/media/platform/soc_camera/atmel-isi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/atmel-isi.c b/drivers/media/platform/soc_camera/atmel-isi.c index 1482af2..354b7db 100644 --- a/drivers/media/platform/soc_camera/atmel-isi.c +++ b/drivers/media/platform/soc_camera/atmel-isi.c @@ -219,7 +219,7 @@ static int atmel_isi_wait_status(struct atmel_isi *isi, int wait_reset) } timeout = wait_for_completion_timeout(&isi->complete, - msecs_to_jiffies(100)); + msecs_to_jiffies(500)); if (timeout == 0) return -ETIMEDOUT; -- 1.9.1 -- 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
