Re: video: USB webcam fails since kernel 3.2
On Tue, 9 Oct 2012 15:54:46 -0700 Jonathan Nieder jrnie...@gmail.com wrote: Hi, In June, Martin-Éric Racine wrote: Since recent kernels, this ASUS W5F's built-in webcam fails to be detected. Gstreamer-based applications (Cheese, gstreamer-properties) immediately crash whenever trying to access the video device. [...] video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] In July, Martin-Éric Racine wrote: As far as I can tell, yes, the modules in Jean-François' tarball work as-is to fix the problem. [...] [ 11.834852] gspca_main: v2.15.18 registered [ 11.844262] gspca_main: vc032x-2.15.18 probing 0ac8:0321 [ 11.844682] gspca_vc032x: vc0321 check sensor header 2c [ 11.850304] gspca_vc032x: Sensor ID 3130 (0) [ 11.850309] gspca_vc032x: Find Sensor PO3130NC [ 11.851809] gspca_main: video0 created Backport would be needed against 3.2.21 as this is what Debian will (probably) release with. Sorry to have lost track of this. Do you know what patch fixed it? Does 3.5.y from experimental work? Curious, Jonathan Hi Jonathan, I tried to prepare a patch set for the vc032x, but testing with Martin-Éric stopped mid-july, so I have nothing to propose yet. I'm waiting for some other vc0321+po3130nc owner and continue the tests... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
On Wed October 10 2012 03:05:30 Mauro Carvalho Chehab wrote: Em Mon, 8 Oct 2012 15:03:36 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sun October 7 2012 13:13:36 Sylwester Nawrocki wrote: On 10/07/2012 03:19 AM, Michael West wrote: This patch changes versions.txt and disables VIDEO_M5MOLS which fixed the build for my 3.2 kernel but looking at the logs it looks like this is not the way to fix it as it's not just a 3.6+ problem as it does not build on 3.6 as well... So probably best to find why it doesn't build on the current kernel first. To fix the build on kernels 3.6+ linux/sizes.h just needs to be inclcuded in m5mols.h. This is what my patch from previous message in this thread does. But this will break again on kernel versions _3.5 and lower_ where linux/sizes.h doesn't exist. I thought originally it could have been simply replaced there with asm/sizes.h, but not all architectures have it $ git grep #define SZ_1M v2.6.32 v2.6.32:arch/arm/include/asm/sizes.h:#define SZ_1M 0x0010 v2.6.32:arch/sh/include/asm/sizes.h:#define SZ_1M 0x0010 $ git grep #define SZ_1M v3.6-rc5 v3.6-rc5:drivers/base/dma-contiguous.c:#define SZ_1M (1 20) v3.6-rc5:include/linux/sizes.h:#define SZ_1M 0x0010 Let's just use the below patch to solve this build break, this way there is no need to touch anything at media_build. From 11adc6956f3fe87c897aa6add08f8437422969a8 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki sylvester.nawro...@gmail.com Date: Sun, 7 Oct 2012 13:04:37 +0200 Subject: [PATCH] m5mols: Replace SZ_1M with explicit value SZ_1M macro definition was introduced in commit ab7ef22419927 [media] m5mols: Implement .get_frame_desc subdev callback but required linux/sizes.h header was not included. To prevent build errors with older kernels where linux/sizes.h doesn't exist use explicit value rather than SZ_1M. Reported-by: Jan Hoogenraad jan-conceptro...@hoogenraad.net Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Acked-by: Hans Verkuil hans.verk...@cisco.com Note: until this patch is merged I am disabling this driver in media_build since right now it doesn't compile at all. Please notify me when this is fixed in media_tree.git so that I can enable it again. Regards, Hans --- drivers/media/i2c/m5mols/m5mols.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/i2c/m5mols/m5mols.h b/drivers/media/i2c/m5mols/m5mols.h index 4ab8b37..30654f5 100644 --- a/drivers/media/i2c/m5mols/m5mols.h +++ b/drivers/media/i2c/m5mols/m5mols.h @@ -24,7 +24,7 @@ * determined by CAPP_JPEG_SIZE_MAX register. */ #define M5MOLS_JPEG_TAGS_SIZE0x2 -#define M5MOLS_MAIN_JPEG_SIZE_MAX(5 * SZ_1M) +#define M5MOLS_MAIN_JPEG_SIZE_MAX(5 * 1024 * 1024) Nah! Please don't do that! we shouldn't be patching a driver upstream just because it broke media_build. Also, fixing it there is as simple as adding something similar to this at compat.h: #ifndef SZ_1M #define SZ_1m (1024 * 1024) #endif Actually, I prefer 1024 * 1024 over SZ_1M. The alternative patch is this: http://www.mail-archive.com/linux-media@vger.kernel.org/msg53424.html Note that the arm architecture will pull in linux/sizes.h, but the x86 arch doesn't, so this driver won't compile with x86. It's a real driver bug that has nothing to do with media_build. So you need to merge one of these two patches to fix this problem. I prefer the first, but the second is fine too. Regards, Hans extern int m5mols_debug; --- v4l/versions.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/v4l/versions.txt b/v4l/versions.txt index 328651e..349695c 100644 --- a/v4l/versions.txt +++ b/v4l/versions.txt @@ -4,6 +4,8 @@ [3.6.0] # needs devm_clk_get, clk_enable, clk_disable VIDEO_CODA +# broken add reason here +VIDEO_M5MOLS This was supposed to be under [3.5.0]. [3.4.0] # needs devm_regulator_bulk_get -- 1.7.9.5 -- 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 -- 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: video: USB webcam fails since kernel 3.2
Jean-Francois Moine wrote: I tried to prepare a patch set for the vc032x, That's good to hear. Does that you mean you have a rough patchset available, even if it doesn't work perfectly yet? I'd be happy to see some patches e.g. with [PATCH/WIP] in the subject line so there is something for people listening in to experiment with. Alternatively if they are not ready for testing or comments but should go somewhere public in a less noisy way, if you send patches as attachments to the bug log at 677533-qu...@bugs.debian.org then they won't be forgotten. Thanks, Jonathan -- 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: video: USB webcam fails since kernel 3.2
2012/10/10 Jean-Francois Moine moin...@free.fr: On Tue, 9 Oct 2012 15:54:46 -0700 Jonathan Nieder jrnie...@gmail.com wrote: Hi, In June, Martin-Éric Racine wrote: Since recent kernels, this ASUS W5F's built-in webcam fails to be detected. Gstreamer-based applications (Cheese, gstreamer-properties) immediately crash whenever trying to access the video device. [...] video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] In July, Martin-Éric Racine wrote: As far as I can tell, yes, the modules in Jean-François' tarball work as-is to fix the problem. [...] [ 11.834852] gspca_main: v2.15.18 registered [ 11.844262] gspca_main: vc032x-2.15.18 probing 0ac8:0321 [ 11.844682] gspca_vc032x: vc0321 check sensor header 2c [ 11.850304] gspca_vc032x: Sensor ID 3130 (0) [ 11.850309] gspca_vc032x: Find Sensor PO3130NC [ 11.851809] gspca_main: video0 created Backport would be needed against 3.2.21 as this is what Debian will (probably) release with. Sorry to have lost track of this. Do you know what patch fixed it? Does 3.5.y from experimental work? Curious, Jonathan Hi Jonathan, I tried to prepare a patch set for the vc032x, but testing with Martin-Éric stopped mid-july, so I have nothing to propose yet. I'm waiting for some other vc0321+po3130nc owner and continue the tests... We kept on going back and forth between two versions of the same file, none of which produced the result expected by Jean-Francois. I'd venture that the change that fixed it involves an entirely different file, but he seemed to expect otherwise. Martin-Éric -- 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] [media] coda: Do not use __cancel_delayed_work()
On 10 October 2012 05:43, Tejun Heo t...@kernel.org wrote: On Wed, Oct 10, 2012 at 12:33:29AM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com commit 136b5721d (workqueue: deprecate __cancel_delayed_work()) made __cancel_delayed_work deprecated. Use cancel_delayed_work instead and get rid of the following warning: drivers/media/platform/coda.c:1543: warning: '__cancel_delayed_work' is deprecated (declared at include/linux/workqueue.h:437) Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Tejun Heo t...@kernel.org Thanks! -- tejun Thanks Fabio. Acked-by: Javier Martin javier.mar...@vista-silicon.com -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- 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: V4L/DVB (13678): Add support for yet another DvbWorld, TeVii and Prof USB devices
Hello Igor M. Liplianin,
The patch 141cc35e2d29: V4L/DVB (13678): Add support for yet another
DvbWorld, TeVii and Prof USB devices from Nov 27, 2009, leads to the
following Sparse warning:
drivers/media/usb/dvb-usb/dw2102.c:288:36: error: bad constant
expression
CHECK drivers/media/usb/dvb-usb/dw2102.c
drivers/media/usb/dvb-usb/dw2102.c:288:36: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:305:44: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:315:44: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:381:53: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:410:52: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:443:36: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:461:44: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:543:47: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:570:52: error: bad constant expression
drivers/media/usb/dvb-usb/dw2102.c:582:52: error: bad constant expression
CC [M] drivers/media/usb/dvb-usb/dw2102.o
284 switch (num) {
285 case 2: {
286 /* read */
287 /* first write first register number */
288 u8 ibuf[msg[1].len + 2], obuf[3];
^^
The kernel has an 8k stack so the worry is that len could larger than
that.
289 obuf[0] = msg[0].addr 1;
290 obuf[1] = msg[0].len;
291 obuf[2] = msg[0].buf[0];
292 dw210x_op_rw(d-udev, 0xc2, 0, 0,
293 obuf, msg[0].len + 2, DW210X_WRITE_MSG);
294 /* second read registers */
295 dw210x_op_rw(d-udev, 0xc3, 0xd1 , 0,
296 ibuf, msg[1].len + 2, DW210X_READ_MSG);
297 memcpy(msg[1].buf, ibuf + 2, msg[1].len);
298
299 break;
300 }
regards,
dan carpenter
--
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 04/14] media: add V4L2 DT binding documentation
Hi Guennadi, On Mon, Oct 08, 2012 at 09:58:58AM +0200, Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Sascha Hauer wrote: On Fri, Oct 05, 2012 at 05:41:00PM +0200, Guennadi Liakhovetski wrote: Hi Sascha Maybe the example would be clearer if you split it up in two, one simple case with the csi2_1 - imx074_1 and a more advanced with the link in between. With no link between two ports no connection is possible, so, only examples with links make sense. I should have said with the renesas,sh-mobile-ceu in between. So simple example: csi2_1 -l- imx074_1 advanced: csi2_2 -l- ceu -l- ov772x No, CEU is the DMA engine with some image processing, so, it's always present. The CSI-2 is just a MIPI CSI-2 interface, that in the above case is used with the CEU too. So, it's like ,-l- ov772x / ceu0 \ `-l- csi2 -l- imx074 It took me some time until I figured out that these are two separate camera/sensor pairs. Somehow I was looking for a multiplexer between them. Maybe I can add more comments to the file, perhaps, add an ASCII-art chart. That would be good. Is the above good enough? :) Yes, thanks. We thought and disucssed about this devicetree binding quite much the last days. Finally I understood it and I must say that I like it. I think more prosa to explain the general concept would be good in the binding doc. Mark, when do we get the same for aSoC? ;) Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 04/14] media: add V4L2 DT binding documentation
On Wed, Oct 10, 2012 at 10:40:06AM +0200, Sascha Hauer wrote: Mark, when do we get the same for aSoC? ;) Well, I'm unlikely to work on it as I don't have any systems which can boot with device tree. The big, big problem you've got doing this is lots of dynamic changes at runtime and in general complicated systems. It's trivial to describe the physical links but they don't provide anything like enough information to use things. Quite frankly I'm not sure device tree is a useful investment of time for advanced audio systems anyway, it's really not solving any problems people actually have. -- 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
AW: omap3-isp-live does not allocate big enough buffers?
Hi Laurent, Thank you for your fast answer. Laurent Pinchart wrote on 2012-10-08: The OMAP3 ISP resizer can't scale down 1944 pixels (the native sensor height) to exactly 480 pixels as that would exceed the resizer limits. You will thus have to crop the sensor image slightly. Cropping is supported by libomap3isp and by the snapshot application but not by the live application. Ideally the live application or the libomap3isp library should realize that the ISP limits are exceeded and configure cropping on the sensor accordingly. As an interim solution you could add manual crop support to the live application using the snapshot application crop support code as an example. I have seen, that the resizer only supports downscaling by 0.25, so with all the cropping, 1944 lines will come down to 482 which is too big for my framebuffer. If I apply some cropping in the omap3_isp_viewfinder_setup function, the output will work as expected. Now I'm going to crop on the sensor (or better on the first entity that supports cropping, as in your code) if the ratio sensor input - viewfinder output exceeds 0.25. Are you interested in a patch for this? Regards, Florian -- 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 04/14] media: add V4L2 DT binding documentation
On Wed, Oct 10, 2012 at 05:51:27PM +0900, Mark Brown wrote: On Wed, Oct 10, 2012 at 10:40:06AM +0200, Sascha Hauer wrote: Mark, when do we get the same for aSoC? ;) Well, I'm unlikely to work on it as I don't have any systems which can boot with device tree. If it's only that I'm sure we could spare a i.MX53 LOCO ;) The big, big problem you've got doing this is lots of dynamic changes at runtime and in general complicated systems. It's trivial to describe the physical links but they don't provide anything like enough information to use things. Quite frankly I'm not sure device tree is a useful investment of time for advanced audio systems anyway, it's really not solving any problems people actually have. Right now the i.MX audmux binding is only enough to say which ports should be connected, but not which format should be used. Just today we had the problem where a codec has two DAIs and wanted to add the information on which port our SSI unit is connected to the devicetree. So I think it's worthwile to do, but that would be a big big task... Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
On 10/10/2012 08:27 AM, Hans Verkuil wrote: diff --git a/drivers/media/i2c/m5mols/m5mols.h b/drivers/media/i2c/m5mols/m5mols.h index 4ab8b37..30654f5 100644 --- a/drivers/media/i2c/m5mols/m5mols.h +++ b/drivers/media/i2c/m5mols/m5mols.h @@ -24,7 +24,7 @@ * determined by CAPP_JPEG_SIZE_MAX register. */ #define M5MOLS_JPEG_TAGS_SIZE 0x2 -#define M5MOLS_MAIN_JPEG_SIZE_MAX (5 * SZ_1M) +#define M5MOLS_MAIN_JPEG_SIZE_MAX (5 * 1024 * 1024) Nah! Please don't do that! we shouldn't be patching a driver upstream just because it broke media_build. Also, fixing it there is as simple as adding something similar to this at compat.h: #ifndef SZ_1M #define SZ_1m (1024 * 1024) #endif Actually, I prefer 1024 * 1024 over SZ_1M. The alternative patch is this: http://www.mail-archive.com/linux-media@vger.kernel.org/msg53424.html Note that the arm architecture will pull in linux/sizes.h, but the x86 arch doesn't, so this driver won't compile with x86. It's a real driver bug that has nothing to do with media_build. So you need to merge one of these two patches to fix this problem. I prefer the first, but the second is fine too. Yes, there is a bug in a driver now, even though the driver compiles on ARM, where linux/sizes.h is included indirectly, it won't build on other architectures where it's not the case. I'm not sure which patch is better, but one of them needs to be applied. Otherwise we're going to see bug reports from people building kernel 3.6+ with allyesconfig, etc.. -- Regards, Sylwester -- 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
Em Wed, 10 Oct 2012 08:27:26 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Wed October 10 2012 03:05:30 Mauro Carvalho Chehab wrote: Em Mon, 8 Oct 2012 15:03:36 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sun October 7 2012 13:13:36 Sylwester Nawrocki wrote: On 10/07/2012 03:19 AM, Michael West wrote: This patch changes versions.txt and disables VIDEO_M5MOLS which fixed the build for my 3.2 kernel but looking at the logs it looks like this is not the way to fix it as it's not just a 3.6+ problem as it does not build on 3.6 as well... So probably best to find why it doesn't build on the current kernel first. To fix the build on kernels 3.6+ linux/sizes.h just needs to be inclcuded in m5mols.h. This is what my patch from previous message in this thread does. But this will break again on kernel versions _3.5 and lower_ where linux/sizes.h doesn't exist. I thought originally it could have been simply replaced there with asm/sizes.h, but not all architectures have it $ git grep #define SZ_1M v2.6.32 v2.6.32:arch/arm/include/asm/sizes.h:#define SZ_1M 0x0010 v2.6.32:arch/sh/include/asm/sizes.h:#define SZ_1M 0x0010 $ git grep #define SZ_1M v3.6-rc5 v3.6-rc5:drivers/base/dma-contiguous.c:#define SZ_1M (1 20) v3.6-rc5:include/linux/sizes.h:#define SZ_1M 0x0010 Let's just use the below patch to solve this build break, this way there is no need to touch anything at media_build. From 11adc6956f3fe87c897aa6add08f8437422969a8 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki sylvester.nawro...@gmail.com Date: Sun, 7 Oct 2012 13:04:37 +0200 Subject: [PATCH] m5mols: Replace SZ_1M with explicit value SZ_1M macro definition was introduced in commit ab7ef22419927 [media] m5mols: Implement .get_frame_desc subdev callback but required linux/sizes.h header was not included. To prevent build errors with older kernels where linux/sizes.h doesn't exist use explicit value rather than SZ_1M. Reported-by: Jan Hoogenraad jan-conceptro...@hoogenraad.net Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Acked-by: Hans Verkuil hans.verk...@cisco.com Note: until this patch is merged I am disabling this driver in media_build since right now it doesn't compile at all. Please notify me when this is fixed in media_tree.git so that I can enable it again. Regards, Hans --- drivers/media/i2c/m5mols/m5mols.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/i2c/m5mols/m5mols.h b/drivers/media/i2c/m5mols/m5mols.h index 4ab8b37..30654f5 100644 --- a/drivers/media/i2c/m5mols/m5mols.h +++ b/drivers/media/i2c/m5mols/m5mols.h @@ -24,7 +24,7 @@ * determined by CAPP_JPEG_SIZE_MAX register. */ #define M5MOLS_JPEG_TAGS_SIZE 0x2 -#define M5MOLS_MAIN_JPEG_SIZE_MAX (5 * SZ_1M) +#define M5MOLS_MAIN_JPEG_SIZE_MAX (5 * 1024 * 1024) Nah! Please don't do that! we shouldn't be patching a driver upstream just because it broke media_build. Also, fixing it there is as simple as adding something similar to this at compat.h: #ifndef SZ_1M #define SZ_1m (1024 * 1024) #endif Actually, I prefer 1024 * 1024 over SZ_1M. I also think that this obfuscates the code, but the right place to discuss it is not here; it is with whomever is proposing those defines, and the ones that acked with it: $ git log include/linux/sizes.h commit dccd2304cc907c4b4d2920eeb24b055320fe942e Author: Alessandro Rubini rub...@gnudd.com Date: Sun Jun 24 12:46:05 2012 +0100 ARM: 7430/1: sizes.h: move from asm-generic to linux/sizes.h sizes.h is used throughout the AMBA code and drivers, so the header should be available to everyone in order to driver AMBA/PrimeCell peripherals behind a PCI bridge where the host can be any platform (I'm doing it under x86). At this step asm-generic/sizes.h includes linux/sizes.h, to allow a grace period for both in-tree and out-of-tree drivers. Signed-off-by: Alessandro Rubini rub...@gnudd.com Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com Acked-by: Linus Walleij linus.wall...@linaro.org Cc: Alan Cox a...@linux.intel.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Provided that this is now officially part of the Kernel internal ABI, we should not nack or revert changes on codes that would be using it. The alternative patch is this: http://www.mail-archive.com/linux-media@vger.kernel.org/msg53424.html If this patch makes sense upstream (e. g. if is there any scenario where linux/sizes.h is not implicitly included), then applying it would actually be a fix, and such patch
Re: [PATCH 04/14] media: add V4L2 DT binding documentation
On Wed, Oct 10, 2012 at 11:21:15AM +0200, Sascha Hauer wrote: On Wed, Oct 10, 2012 at 05:51:27PM +0900, Mark Brown wrote: Well, I'm unlikely to work on it as I don't have any systems which can boot with device tree. If it's only that I'm sure we could spare a i.MX53 LOCO ;) Well, something with Wolfson hardware would be helpful. The big, big problem you've got doing this is lots of dynamic changes at runtime and in general complicated systems. It's trivial to describe the physical links but they don't provide anything like enough information to use things. Quite frankly I'm not sure device tree is a useful investment of time for advanced audio systems anyway, it's really not solving any problems people actually have. Right now the i.MX audmux binding is only enough to say which ports should be connected, but not which format should be used. Just today Why should that be in DT? For most things it's either fixed by the hardware or makes no odds. we had the problem where a codec has two DAIs and wanted to add the information on which port our SSI unit is connected to the devicetree. There's nothing stopping you doing that right now, the existing DT So I think it's worthwile to do, but that would be a big big task... For simple devices there's already stuff there and it's not hard to add new machine bindings, it's trying to cover the general case that's far too much effort. -- 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
On Wed 10 October 2012 12:39:39 Mauro Carvalho Chehab wrote: Em Wed, 10 Oct 2012 08:27:26 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Wed October 10 2012 03:05:30 Mauro Carvalho Chehab wrote: Em Mon, 8 Oct 2012 15:03:36 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sun October 7 2012 13:13:36 Sylwester Nawrocki wrote: On 10/07/2012 03:19 AM, Michael West wrote: This patch changes versions.txt and disables VIDEO_M5MOLS which fixed the build for my 3.2 kernel but looking at the logs it looks like this is not the way to fix it as it's not just a 3.6+ problem as it does not build on 3.6 as well... So probably best to find why it doesn't build on the current kernel first. To fix the build on kernels 3.6+ linux/sizes.h just needs to be inclcuded in m5mols.h. This is what my patch from previous message in this thread does. But this will break again on kernel versions _3.5 and lower_ where linux/sizes.h doesn't exist. I thought originally it could have been simply replaced there with asm/sizes.h, but not all architectures have it $ git grep #define SZ_1M v2.6.32 v2.6.32:arch/arm/include/asm/sizes.h:#define SZ_1M 0x0010 v2.6.32:arch/sh/include/asm/sizes.h:#define SZ_1M 0x0010 $ git grep #define SZ_1M v3.6-rc5 v3.6-rc5:drivers/base/dma-contiguous.c:#define SZ_1M (1 20) v3.6-rc5:include/linux/sizes.h:#define SZ_1M 0x0010 Let's just use the below patch to solve this build break, this way there is no need to touch anything at media_build. From 11adc6956f3fe87c897aa6add08f8437422969a8 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki sylvester.nawro...@gmail.com Date: Sun, 7 Oct 2012 13:04:37 +0200 Subject: [PATCH] m5mols: Replace SZ_1M with explicit value SZ_1M macro definition was introduced in commit ab7ef22419927 [media] m5mols: Implement .get_frame_desc subdev callback but required linux/sizes.h header was not included. To prevent build errors with older kernels where linux/sizes.h doesn't exist use explicit value rather than SZ_1M. Reported-by: Jan Hoogenraad jan-conceptro...@hoogenraad.net Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Acked-by: Hans Verkuil hans.verk...@cisco.com Note: until this patch is merged I am disabling this driver in media_build since right now it doesn't compile at all. Please notify me when this is fixed in media_tree.git so that I can enable it again. Regards, Hans --- drivers/media/i2c/m5mols/m5mols.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/i2c/m5mols/m5mols.h b/drivers/media/i2c/m5mols/m5mols.h index 4ab8b37..30654f5 100644 --- a/drivers/media/i2c/m5mols/m5mols.h +++ b/drivers/media/i2c/m5mols/m5mols.h @@ -24,7 +24,7 @@ * determined by CAPP_JPEG_SIZE_MAX register. */ #define M5MOLS_JPEG_TAGS_SIZE0x2 -#define M5MOLS_MAIN_JPEG_SIZE_MAX(5 * SZ_1M) +#define M5MOLS_MAIN_JPEG_SIZE_MAX(5 * 1024 * 1024) Nah! Please don't do that! we shouldn't be patching a driver upstream just because it broke media_build. Also, fixing it there is as simple as adding something similar to this at compat.h: #ifndef SZ_1M #define SZ_1m (1024 * 1024) #endif Actually, I prefer 1024 * 1024 over SZ_1M. I also think that this obfuscates the code, but the right place to discuss it is not here; it is with whomever is proposing those defines, and the ones that acked with it: $ git log include/linux/sizes.h commit dccd2304cc907c4b4d2920eeb24b055320fe942e Author: Alessandro Rubini rub...@gnudd.com Date: Sun Jun 24 12:46:05 2012 +0100 ARM: 7430/1: sizes.h: move from asm-generic to linux/sizes.h sizes.h is used throughout the AMBA code and drivers, so the header should be available to everyone in order to driver AMBA/PrimeCell peripherals behind a PCI bridge where the host can be any platform (I'm doing it under x86). At this step asm-generic/sizes.h includes linux/sizes.h, to allow a grace period for both in-tree and out-of-tree drivers. Signed-off-by: Alessandro Rubini rub...@gnudd.com Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com Acked-by: Linus Walleij linus.wall...@linaro.org Cc: Alan Cox a...@linux.intel.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Provided that this is now officially part of the Kernel internal ABI, we should not nack or revert changes on codes that would be using it. The alternative patch is this:
Re: [PATCHv9 00/25] Integration of videobuf2 with DMABUF
Hi, Em Tue, 02 Oct 2012 16:27:11 +0200 Tomasz Stanislawski t.stanisl...@samsung.com escreveu: Hello everyone, This patchset adds support for DMABUF [2] importing and exporting to V4L2 stack. v9: - rebase on 3.6 - change type for fs to __s32 - add support for vb2_ioctl_expbuf - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING', it will be posted as a separate patch - fix typos and style in Documentation (from Hans Verkuil) - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig - use data_offset and length while queueing DMABUF - return the most recently used fd at VIDIOC_DQBUF - use (buffer-type, index, plane) tuple instead of mem_offset to identify a for exporting (from Hans Verkuil) - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart) - add testing alignment of vaddr and size while verifying userptr against DMA capabilities (from Laurent Pinchart) - substitute VM_DONTDUMP with VM_RESERVED - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart) For now, NACK. See below. I spent 4 days trying to setup an environment that would allow testing DMABUF with video4linux without success (long story, see below). Also, Laurent tried the same without any luck, and it seems that it even corrupted his test machine. Basically Samsung generously donated me two boards that it could be used on this test (Origen and SMDK310). None of them actually worked with the upstream kernel: patches are needed to avoid OOPSes on Origen; both Origen/SMDK310 defconfigs are completely broken, and drivers don't even boot if someone tries to use the Kernel's defconfigs. Even after spending _days_ trying to figure out the needed .config options (as the config files are not easily available), both boards have... issues: - lack of any display output driver at SMDK310; - lack of any network driver at Origen: it seems that none of the available network options on Origen was upstreamed: no Bluetooth, no OTG, no Wifi. The only test I was able to do (yesterday, late night), the DMABUF caused an OOPS at the Origen board. So, for sure it is not ready for upstream. It is now, too late for 3.7. I might consider it to 3.8, if something can be done to fix the existing issues, and setup a proper setup, using the upstream Kernel. 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: Media_build broken by [PATCH RFC v3 5/5] m5mols: Implement .get_frame_desc subdev callback
Em Wed, 10 Oct 2012 12:52:48 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Wed 10 October 2012 12:39:39 Mauro Carvalho Chehab wrote: Em Wed, 10 Oct 2012 08:27:26 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Wed October 10 2012 03:05:30 Mauro Carvalho Chehab wrote: Em Mon, 8 Oct 2012 15:03:36 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Sun October 7 2012 13:13:36 Sylwester Nawrocki wrote: On 10/07/2012 03:19 AM, Michael West wrote: This patch changes versions.txt and disables VIDEO_M5MOLS which fixed the build for my 3.2 kernel but looking at the logs it looks like this is not the way to fix it as it's not just a 3.6+ problem as it does not build on 3.6 as well... So probably best to find why it doesn't build on the current kernel first. To fix the build on kernels 3.6+ linux/sizes.h just needs to be inclcuded in m5mols.h. This is what my patch from previous message in this thread does. But this will break again on kernel versions _3.5 and lower_ where linux/sizes.h doesn't exist. I thought originally it could have been simply replaced there with asm/sizes.h, but not all architectures have it $ git grep #define SZ_1M v2.6.32 v2.6.32:arch/arm/include/asm/sizes.h:#define SZ_1M 0x0010 v2.6.32:arch/sh/include/asm/sizes.h:#define SZ_1M 0x0010 $ git grep #define SZ_1M v3.6-rc5 v3.6-rc5:drivers/base/dma-contiguous.c:#define SZ_1M (1 20) v3.6-rc5:include/linux/sizes.h:#define SZ_1M 0x0010 Let's just use the below patch to solve this build break, this way there is no need to touch anything at media_build. From 11adc6956f3fe87c897aa6add08f8437422969a8 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki sylvester.nawro...@gmail.com Date: Sun, 7 Oct 2012 13:04:37 +0200 Subject: [PATCH] m5mols: Replace SZ_1M with explicit value SZ_1M macro definition was introduced in commit ab7ef22419927 [media] m5mols: Implement .get_frame_desc subdev callback but required linux/sizes.h header was not included. To prevent build errors with older kernels where linux/sizes.h doesn't exist use explicit value rather than SZ_1M. Reported-by: Jan Hoogenraad jan-conceptro...@hoogenraad.net Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com Acked-by: Hans Verkuil hans.verk...@cisco.com Note: until this patch is merged I am disabling this driver in media_build since right now it doesn't compile at all. Please notify me when this is fixed in media_tree.git so that I can enable it again. Regards, Hans --- drivers/media/i2c/m5mols/m5mols.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/i2c/m5mols/m5mols.h b/drivers/media/i2c/m5mols/m5mols.h index 4ab8b37..30654f5 100644 --- a/drivers/media/i2c/m5mols/m5mols.h +++ b/drivers/media/i2c/m5mols/m5mols.h @@ -24,7 +24,7 @@ * determined by CAPP_JPEG_SIZE_MAX register. */ #define M5MOLS_JPEG_TAGS_SIZE 0x2 -#define M5MOLS_MAIN_JPEG_SIZE_MAX (5 * SZ_1M) +#define M5MOLS_MAIN_JPEG_SIZE_MAX (5 * 1024 * 1024) Nah! Please don't do that! we shouldn't be patching a driver upstream just because it broke media_build. Also, fixing it there is as simple as adding something similar to this at compat.h: #ifndef SZ_1M #define SZ_1m (1024 * 1024) #endif Actually, I prefer 1024 * 1024 over SZ_1M. I also think that this obfuscates the code, but the right place to discuss it is not here; it is with whomever is proposing those defines, and the ones that acked with it: $ git log include/linux/sizes.h commit dccd2304cc907c4b4d2920eeb24b055320fe942e Author: Alessandro Rubini rub...@gnudd.com Date: Sun Jun 24 12:46:05 2012 +0100 ARM: 7430/1: sizes.h: move from asm-generic to linux/sizes.h sizes.h is used throughout the AMBA code and drivers, so the header should be available to everyone in order to driver AMBA/PrimeCell peripherals behind a PCI bridge where the host can be any platform (I'm doing it under x86). At this step asm-generic/sizes.h includes linux/sizes.h, to allow a grace period for both in-tree and out-of-tree drivers. Signed-off-by: Alessandro Rubini rub...@gnudd.com Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com Acked-by: Linus Walleij linus.wall...@linaro.org Cc: Alan Cox a...@linux.intel.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Provided that this is
Re: [Linaro-mm-sig] [PATCHv9 00/25] Integration of videobuf2 with DMABUF
On 10/10/12, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi, Em Tue, 02 Oct 2012 16:27:11 +0200 Tomasz Stanislawski t.stanisl...@samsung.com escreveu: Hello everyone, This patchset adds support for DMABUF [2] importing and exporting to V4L2 stack. v9: - rebase on 3.6 - change type for fs to __s32 - add support for vb2_ioctl_expbuf - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING', it will be posted as a separate patch - fix typos and style in Documentation (from Hans Verkuil) - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig - use data_offset and length while queueing DMABUF - return the most recently used fd at VIDIOC_DQBUF - use (buffer-type, index, plane) tuple instead of mem_offset to identify a for exporting (from Hans Verkuil) - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart) - add testing alignment of vaddr and size while verifying userptr against DMA capabilities (from Laurent Pinchart) - substitute VM_DONTDUMP with VM_RESERVED - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart) For now, NACK. See below. Sad news! It's failed to merge by very poor samsung board support at mainline. CC arm samsung mailing list. Thank you, Kyungmin Park I spent 4 days trying to setup an environment that would allow testing DMABUF with video4linux without success (long story, see below). Also, Laurent tried the same without any luck, and it seems that it even corrupted his test machine. Basically Samsung generously donated me two boards that it could be used on this test (Origen and SMDK310). None of them actually worked with the upstream kernel: patches are needed to avoid OOPSes on Origen; both Origen/SMDK310 defconfigs are completely broken, and drivers don't even boot if someone tries to use the Kernel's defconfigs. Even after spending _days_ trying to figure out the needed .config options (as the config files are not easily available), both boards have... issues: - lack of any display output driver at SMDK310; - lack of any network driver at Origen: it seems that none of the available network options on Origen was upstreamed: no Bluetooth, no OTG, no Wifi. The only test I was able to do (yesterday, late night), the DMABUF caused an OOPS at the Origen board. So, for sure it is not ready for upstream. It is now, too late for 3.7. I might consider it to 3.8, if something can be done to fix the existing issues, and setup a proper setup, using the upstream Kernel. Regards, Mauro ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- 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: [GIT PULL] Disintegrate UAPI for media
Mauro Carvalho Chehab mche...@infradead.org wrote: Hmm... last year, it was decided that we would be putting the DVB av7110-only API files on a separate place, as the API there conflicts with V4L/alsa APIs and are used only by one upstream driver (there were two drivers using them, at that time). As you might notice, av7110 hardware is really old, not manufactured anymore since maybe 10 years ago, and it is an unmaintained driver. Some developers complained, arguing that moving it to a separate file would be breaking the compilation on existing tools (they're basically concerned with it due to out-of-tree drivers - mostly propietary ones, that use this API). As long as they're relying on the -I flags provided by the build tree, that oughtn't to be a problem. If they're doing their own -I flags, they'll need to add -I include/uapi too (_after_ -I include). Now that we're moving everything, it does make sense to do that, moving dvb/(audio|osd|video).h to someplace else (maybe linux/dvb/av7110.h or linux/dvb/legacy/*.h). Do you want me to do anything? I should be able to incorporate a patch prior to the disintegration of linux/dvb/ if you have one. David -- 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 05/14] media: add a V4L2 OF parser
Hi Guennadi, On Monday 08 October 2012 14:23:25 Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Hans Verkuil wrote: [snip] I think the soc_camera patches should be left out for now. I suspect that by adding core support for async i2c handling first, Ok, let's think, what this meacs - async I2C in media / V4L2 core. The main reason for our probing order problem is the master clock, typically supplied from the camera bridge to I2C subdevices, which we only want to start when necessary, i.e. when accessing the subdevice. And the subdevice driver needs that clock running during its .probe() to be able to access and verify or configure the hardware. Our current solution is to not register I2C subdevices from the platform data, as is usual for all I2C devices, but from the bridge driver and only after it has switched on the master clock. After the subdevice driver has completed its probing we switch the clock back off until the subdevice has to be activated, e.g. for video capture. Also important - when we want to unregister the bridge driver we just also unregister the I2C device. Now, to reverse the whole thing and to allow I2C devices be registered as usual - via platform data or OF, first of all we have to teach I2C subdevice drivers to recognise the too early situation and request deferred probing in such a case. Then it will be reprobed after each new successful probe or unregister on the system. After the bridge driver has successfully probed the subdevice driver will be re-probed and at that time it should succeed. Now, there is a problem here too: who should switch on and off the master clock? If we do it from the bridge driver, we could install an I2C bus-notifier, _before_ the subdevice driver is probed, i.e. upon the BUS_NOTIFY_BIND_DRIVER event we could turn on the clock. If subdevice probing was successful, we can then wait for the BUS_NOTIFY_BOUND_DRIVER event to switch the clock back off. BUT - if the subdevice fails probing? How do we find out about that and turn the clock back off? There is no notification event for that... Possible solutions: 1. timer - ugly and unreliable. 2. add a probing failed notifier event to the device core - would this be accepted? 3. let the subdevice turn the master clock on and off for the duration of probing. My vote goes for (3). Ideally this should be done using the generic clock framework. But can we really expect all drivers and platforms to switch to it quickly enough? If not, we need a V4L2-specific callback from subdevice drivers to bridge drivers to turn the clock on and off. That's what I've done temporarily in this patch series for soc-camera. I vote for (3) as well, using the generic clock framework. You're right that we need an interim solution, as not all platforms will switch quickly enough. I'm fine with that interim solution being a bit hackish, as long as we push new drivers towards the right solution. Suppose we decide to do the same for V4L2 centrally - add call-backs. Then we can think what else we need to add to V4L2 to support asynchronous subdevice driver probing. 1. We'll have to create these V4L2 clock start and stop functions, that, supplied (in case of I2C) with client address and adapter number will find the correct v4l2_device instance and call its callbacks. 2. The I2C notifier. I'm not sure, whether this one should be common. Of common tasks we have to refcount the I2C adapter and register the subdevice. Then we'd have to call the bridge driver's callback. Is it worth it doing this centrally or rather allow individual drivers to do that themselves? What about going through board code for platforms that don't support the generic clock framework yet ? That's what the OMAP3 ISP driver does. DT support would then require the generic clock framework. Also, ideally OF-compatible (I2C) drivers should run with no platform data, but soc-camera is using I2C device platform data intensively. To avoid modifying the soc-camera core and all drivers, I also trigger on the BUS_NOTIFY_BIND_DRIVER event and assign a reference to the dynamically created platform data to the I2C device. Would we also want to do this for all V4L2 bridge drivers? We could call this a prepare callback or something similar... If that's going to be an interim solution only I'm fine with keeping it in soc-camera. 3. Bridge driver unregistering. Here we have to put the subdevice driver back into the deferred-probe state... Ugliness alert: I'm doing this by unregistering and re-registering the I2C device... For that I also have to create a copy of devices I2C board-info data. Lovely, ain't it? This I'd be happy to move to the V4L2 core;-) That's the ugly part. As soon as the I2C device starts using resources provided by the bridge, those resources can't disappear behind the scene. Reference counting must ensure that the bridge driver doesn't get removed. And that's
Re: [PATCH 05/14] media: add a V4L2 OF parser
Hi Hans, On Monday 08 October 2012 16:53:55 Hans Verkuil wrote: On Mon October 8 2012 16:30:53 Guennadi Liakhovetski wrote: On Mon, 8 Oct 2012, Hans Verkuil wrote: On Mon October 8 2012 14:23:25 Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Hans Verkuil wrote: [snip] I think the soc_camera patches should be left out for now. I suspect that by adding core support for async i2c handling first, Ok, let's think, what this meacs - async I2C in media / V4L2 core. The main reason for our probing order problem is the master clock, typically supplied from the camera bridge to I2C subdevices, which we only want to start when necessary, i.e. when accessing the subdevice. And the subdevice driver needs that clock running during its .probe() to be able to access and verify or configure the hardware. Our current solution is to not register I2C subdevices from the platform data, as is usual for all I2C devices, but from the bridge driver and only after it has switched on the master clock. After the subdevice driver has completed its probing we switch the clock back off until the subdevice has to be activated, e.g. for video capture. Also important - when we want to unregister the bridge driver we just also unregister the I2C device. Now, to reverse the whole thing and to allow I2C devices be registered as usual - via platform data or OF, first of all we have to teach I2C subdevice drivers to recognise the too early situation and request deferred probing in such a case. Then it will be reprobed after each new successful probe or unregister on the system. After the bridge driver has successfully probed the subdevice driver will be re-probed and at that time it should succeed. Now, there is a problem here too: who should switch on and off the master clock? If we do it from the bridge driver, we could install an I2C bus- notifier, _before_ the subdevice driver is probed, i.e. upon the BUS_NOTIFY_BIND_DRIVER event we could turn on the clock. If subdevice probing was successful, we can then wait for the BUS_NOTIFY_BOUND_DRIVER event to switch the clock back off. BUT - if the subdevice fails probing? How do we find out about that and turn the clock back off? There is no notification event for that... Possible solutions: 1. timer - ugly and unreliable. 2. add a probing failed notifier event to the device core - would this be accepted? 3. let the subdevice turn the master clock on and off for the duration of probing. My vote goes for (3). Ideally this should be done using the generic clock framework. But can we really expect all drivers and platforms to switch to it quickly enough? If not, we need a V4L2-specific callback from subdevice drivers to bridge drivers to turn the clock on and off. That's what I've done temporarily in this patch series for soc- camera. Suppose we decide to do the same for V4L2 centrally - add call-backs. Then we can think what else we need to add to V4L2 to support asynchronous subdevice driver probing. I wonder, don't we have the necessary code already? V4L2 subdev drivers can have internal_ops with register/unregister ops. These are called by v4l2_device_register_subdev. This happens during the bridge driver's probe. Suppose the subdev's probe does not actually access the i2c device, but instead defers that to the register callback? The bridge driver will turn on the clock before calling v4l2_device_register_subdev to ensure that the register callback can access the i2c registers. The register callback will do any initialization and can return an error. In case of an error the i2c client is automatically unregistered as well. Yes, if v4l2_i2c_new_subdev_board() is used. This has been discussed several times before and always what I didn't like in this is, that I2C device probe() in this case succeeds without even trying to access the hardware. And think about DT. In this case we don't instantiate the I2C device, OF code does it for us. What do you do then? If you let probe() succeed, then you will have to somehow remember the subdevice to later match it against bridges... Yes, but you need that information anyway. The bridge still needs to call v4l2_device_register_subdev so it needs to know which subdevs are loaded. And can't it get that from DT as well? That information will definitely come from the DT, but the bridge won't instantiate the I2C devices. They will be instantiated asynchronously by the I2C bus master driver when parsing the DT. The bridge will then need to be notified or I2C devices registration and finish its initialization when all needed I2C (or SPI, ...) devices will be available. That should in my opinion be handled by the V4L2 core : the bridge would pass a list of
Re: [PATCH 05/14] media: add a V4L2 OF parser
Hi Guennadi, On Monday 08 October 2012 17:15:53 Guennadi Liakhovetski wrote: On Mon, 8 Oct 2012, Hans Verkuil wrote: On Mon October 8 2012 16:30:53 Guennadi Liakhovetski wrote: On Mon, 8 Oct 2012, Hans Verkuil wrote: On Mon October 8 2012 14:23:25 Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Hans Verkuil wrote: [snip] I think the soc_camera patches should be left out for now. I suspect that by adding core support for async i2c handling first, Ok, let's think, what this meacs - async I2C in media / V4L2 core. The main reason for our probing order problem is the master clock, typically supplied from the camera bridge to I2C subdevices, which we only want to start when necessary, i.e. when accessing the subdevice. And the subdevice driver needs that clock running during its .probe() to be able to access and verify or configure the hardware. Our current solution is to not register I2C subdevices from the platform data, as is usual for all I2C devices, but from the bridge driver and only after it has switched on the master clock. After the subdevice driver has completed its probing we switch the clock back off until the subdevice has to be activated, e.g. for video capture. Also important - when we want to unregister the bridge driver we just also unregister the I2C device. Now, to reverse the whole thing and to allow I2C devices be registered as usual - via platform data or OF, first of all we have to teach I2C subdevice drivers to recognise the too early situation and request deferred probing in such a case. Then it will be reprobed after each new successful probe or unregister on the system. After the bridge driver has successfully probed the subdevice driver will be re-probed and at that time it should succeed. Now, there is a problem here too: who should switch on and off the master clock? If we do it from the bridge driver, we could install an I2C bus-notifier, _before_ the subdevice driver is probed, i.e. upon the BUS_NOTIFY_BIND_DRIVER event we could turn on the clock. If subdevice probing was successful, we can then wait for the BUS_NOTIFY_BOUND_DRIVER event to switch the clock back off. BUT - if the subdevice fails probing? How do we find out about that and turn the clock back off? There is no notification event for that... Possible solutions: 1. timer - ugly and unreliable. 2. add a probing failed notifier event to the device core - would this be accepted? 3. let the subdevice turn the master clock on and off for the duration of probing. My vote goes for (3). Ideally this should be done using the generic clock framework. But can we really expect all drivers and platforms to switch to it quickly enough? If not, we need a V4L2-specific callback from subdevice drivers to bridge drivers to turn the clock on and off. That's what I've done temporarily in this patch series for soc-camera. Suppose we decide to do the same for V4L2 centrally - add call-backs. Then we can think what else we need to add to V4L2 to support asynchronous subdevice driver probing. I wonder, don't we have the necessary code already? V4L2 subdev drivers can have internal_ops with register/unregister ops. These are called by v4l2_device_register_subdev. This happens during the bridge driver's probe. Suppose the subdev's probe does not actually access the i2c device, but instead defers that to the register callback? The bridge driver will turn on the clock before calling v4l2_device_register_subdev to ensure that the register callback can access the i2c registers. The register callback will do any initialization and can return an error. In case of an error the i2c client is automatically unregistered as well. Yes, if v4l2_i2c_new_subdev_board() is used. This has been discussed several times before and always what I didn't like in this is, that I2C device probe() in this case succeeds without even trying to access the hardware. And think about DT. In this case we don't instantiate the I2C device, OF code does it for us. What do you do then? If you let probe() succeed, then you will have to somehow remember the subdevice to later match it against bridges... Yes, but you need that information anyway. The bridge still needs to call v4l2_device_register_subdev so it needs to know which subdevs are loaded. But how do you get the subdev pointer? With the notifier I get it from i2c_get_clientdata(client) and what do you do without it? How do you get to the client? And can't it get that from DT as well? No, I don't think there is a way to get a device pointer from a DT node. But we'll need a way. The bridge driver will get sensor
Re: [PATCH 05/14] media: add a V4L2 OF parser
Hi Hans, On Monday 08 October 2012 17:41:43 Hans Verkuil wrote: On Mon October 8 2012 17:15:53 Guennadi Liakhovetski wrote: On Mon, 8 Oct 2012, Hans Verkuil wrote: On Mon October 8 2012 16:30:53 Guennadi Liakhovetski wrote: On Mon, 8 Oct 2012, Hans Verkuil wrote: [snip] I wonder, don't we have the necessary code already? V4L2 subdev drivers can have internal_ops with register/unregister ops. These are called by v4l2_device_register_subdev. This happens during the bridge driver's probe. Suppose the subdev's probe does not actually access the i2c device, but instead defers that to the register callback? The bridge driver will turn on the clock before calling v4l2_device_register_subdev to ensure that the register callback can access the i2c registers. The register callback will do any initialization and can return an error. In case of an error the i2c client is automatically unregistered as well. Yes, if v4l2_i2c_new_subdev_board() is used. This has been discussed several times before and always what I didn't like in this is, that I2C device probe() in this case succeeds without even trying to access the hardware. And think about DT. In this case we don't instantiate the I2C device, OF code does it for us. What do you do then? If you let probe() succeed, then you will have to somehow remember the subdevice to later match it against bridges... Yes, but you need that information anyway. The bridge still needs to call v4l2_device_register_subdev so it needs to know which subdevs are loaded. But how do you get the subdev pointer? With the notifier I get it from i2c_get_clientdata(client) and what do you do without it? How do you get to the client? And can't it get that from DT as well? No, I don't think there is a way to get a device pointer from a DT node. Not a device pointer, but the i2c bus and i2c address. With that information you can get the i2c_client, and with that you can get the subdev pointer. That could work as well, but it might be easier to keep a mapping from the DT node to struct device or struct v4l2_subdev instead. I have no strong opinion on this at the moment. If there is no way to get that information from the proposed V4L2 DT, then it needs to be modified since a bridge driver really needs to know which subdevs it has to register with the v4l2_device struct. That information is also board specific so it should be part of the DT. In my view you cannot do a proper initialization unless you have both the bridge driver and all subdev drivers loaded and instantiated. They need one another. So I am perfectly fine with letting the probe function do next to nothing and postponing that until register() is called. I2C and actual probing to check if it's the right device is a bad idea in general since you have no idea what a hardware access to an unknown i2c device will do. There are still some corner cases where that is needed, but I do not think that that is an issue here. It would simplify things a lot IMHO. Also note that the register() op will work with any device, not just i2c. That may be a useful property as well. And what if the subdevice device is not yet instantiated by OF by the time your bridge driver probes? That is where you still need to have a bus notifier mechanism. You have to be able to wait until all dependent drivers are loaded/instantiated, or alternatively you have to be able to load them explicitly. But this should be relatively easy to implement in a generic manner. I still think this sucks (excuse my language), but I see no way around it as long as there is no explicit probe order one can rely on. -- Regards, Laurent Pinchart -- 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: Using omap3-isp-live example application on beagleboard with DVI
Hi John, 2012/9/6 John Weber rjohnwe...@gmail.com: Hello, My goal is to better understand how to write an application that makes use of the omap3isp and media controller frameworks and v4l2. I'm attempting to make use of Laurent's omap3-isp-live example application as a starting point and play with the AEC/WB capability. My problem is that when I start the live application, the display turns blue (it seems when the chromakey fill is done), but no video appears on the display. I do think that I'm getting good (or at least statistics) from the ISP because I can change the view in front of the camera (by putting my hand in front of the lens) and the gain settings change. root@beagleboard:~# live Device /dev/video6 opened: OMAP3 ISP resizer output (media). viewfinder configured for 2011 1024x768 AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30 Device /dev/video7 opened: omap_vout (). 3 buffers requested. Buffer 0 mapped at address 0x40279000. Buffer 1 mapped at address 0x40402000. Buffer 2 mapped at address 0x4059e000. 3 buffers requested. Buffer 0 valid. Buffer 1 valid. Buffer 2 valid. AE: factor 3.1250 exposure 2000 sensor gain 12 AE: factor 1.6018 exposure 2000 sensor gain 19 AE: factor 1.1346 exposure 2000 sensor gain 21 AE: factor 1.0446 exposure 2000 sensor gain 21 AE: factor 1.0448 exposure 2000 sensor gain 21 AE: factor 1.0444 exposure 2000 sensor gain 21 AE: factor 1.0443 exposure 2000 sensor gain 21 AE: factor 1.0445 exposure 2000 sensor gain 21 AE: factor 1.0438 exposure 2000 sensor gain 21 AE: factor 1.0448 exposure 2000 sensor gain 21 AE: factor 1.0461 exposure 2000 sensor gain 21 AE: factor 1.0897 exposure 2000 sensor gain 22 AE: factor 2.6543 exposure 2000 sensor gain 58 Me obstructing the camera FOV using my hand causes the factor and gain to rise AE: factor 1.2345 exposure 2000 sensor gain 71 AE: factor 1.1631 exposure 2000 sensor gain 82 AE: factor 0.9797 exposure 2000 sensor gain 80 AE: factor 0.9709 exposure 2000 sensor gain 77 frame rate: 6.597745 fps AE: factor 0.9633 exposure 2000 sensor gain 74 AE: factor 0.6130 exposure 2000 sensor gain 45 AE: factor 0.9271 exposure 2000 sensor gain 41 AE: factor 1.0130 exposure 2000 sensor gain 41 AE: factor 1.0504 exposure 2000 sensor gain 43 AE: factor 1.0411 exposure 2000 sensor gain 44 AE: factor 1.0271 exposure 2000 sensor gain 45 AE: factor 1.0602 exposure 2000 sensor gain 47 AE: factor 1.1278 exposure 2000 sensor gain 53 AE: factor 1.1870 exposure 2000 sensor gain 62 AE: factor 1.1074 exposure 2000 sensor gain 68 AE: factor 1.0716 exposure 2000 sensor gain 72 AE: factor 0.4074 exposure 2000 sensor gain 29 AE: factor 0.8033 exposure 2000 sensor gain 23 AE: factor 0.9741 exposure 2000 sensor gain 22 AE: factor 1.0115 exposure 2000 sensor gain 22 I did have to change the omap_vout driver slightly to increase the buffer size. I was getting errors in the application attempted to allocate USERPTR buffers for 1024x768 frames: root@beagleboard:~# live Device /dev/video6 opened: OMAP3 ISP resizer output (media). viewfinder configured for 2011 1024x768 AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30 Device /dev/video7 opened: omap_vout (). 3 buffers requested. Buffer 0 mapped at address 0x40302000. Buffer 1 mapped at address 0x404df000. Buffer 2 mapped at address 0x4066e000. 3 buffers requested. Buffer 0 too small (1572864 bytes required, 1474560 bytes available.) So, I changed drivers/media/video/omap/omap_voutdef.h to increase the buffer size slightly. /* Max Resolution supported by the driver */ #define VID_MAX_WIDTH 1280/* Largest width */ #define VID_MAX_HEIGHT 768 /* Largest height */ -- Was 720 I'm pretty sure that wasn't the only way to solve the problem, but it did allow the live application to run without errors. I am using a patched variant of the current Angstrom mainline (3.2.16) with the MT9P031 sensor and a DVI display on Beagleboard-xM and am able to run the following commands and see a live video stream on the display. I suspect that this indicates that hardware setup works: media-ctl -v -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -v -f 'mt9p031 2-0048:0 [SGRBG12 1024x768], OMAP3 ISP CCDC:2 [SGRBG10 1024x768], OMAP3 ISP preview:1 [UYVY 10006x760], OMAP3 ISP resizer:1 [UYVY 1024x768]' yavta -f UYVY -s 1024x768 -n 8 --skip 3 --capture=1000 --stdout /dev/video6 | mplayer - -demuxer rawvideo -rawvideo w=1024:h=768:format=uyvy -vo fbdev Thanks for any tips or assistance! I've exactly the same problem. Before try to debug the problem I would like to know if you solved the
Re: [PATCH 05/14] media: add a V4L2 OF parser
Hi Hans, On Tuesday 09 October 2012 13:00:24 Hans Verkuil wrote: On Tue 9 October 2012 12:34:48 Sylwester Nawrocki wrote: On 10/08/2012 11:40 AM, Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Sylwester Nawrocki wrote: I would really like to see more than one user until we add any core code. No that it couldn't be changed afterwards, but it would be nice to ensure the concepts are right and proven in real life. Unfortunately I don't have any more systems on which I could easily enough try this. I've got a beagleboard with a camera, but I don't think I'm a particularly good candidate for implementing DT support for OMAP3 camera drivers;-) Apart from that I've only got soc-camera based systems, of which none are _really_ DT-ready... At best I could try an i.MX31 based board, but that doesn't have a very well developed .dts and that would be soc-camera too anyway. I certainly wouldn't expect you would do all the job. I mean it would be good to possibly have some other developers adding device tree support based on that new bindings and new infrastructure related to them. As I mentioned in another e-mail, I plan to work on DT support for the OMAP3 ISP, but I first need generic clock framework support for OMAP3. There have been recently some progress in device tree support for Exynos SoCs, including common clock framework support and we hope to add FDT support to the Samsung SoC camera devices during this kernel cycle, based on the newly designed media bindings. This is going to be a second attempt, after our initial RFC from May [1]. It would still be SoC specific implementation, but not soc-camera based. I wasn't a big fan of this asynchronous sub-devices probing, but it now seems to be a most complete solution to me. I think it just need to be done right at the v4l2-core so individual drivers don't get complicated too much. After investigating this some more I think I agree with that. There are some things where we should probably ask for advice from the i2c subsystem devs, I'm thinking of putting the driver back into the deferred-probe state in particular. We might actually not need that, it might be easier to handle the circular dependency problem from the other end. We could add a way (ioctl, sysfs, ...) to force a V4L2 bridge driver to release its subdevs. Once done, the subdev driver could be unloaded and/or the subdev device unregistered, which would release the resources used by the subdev, such as clocks. The bridge driver could then be unregistered. Creating v4l2-core support for this is crucial as it is quite complex and without core support this is going to be a nightmare for drivers. -- Regards, Laurent Pinchart -- 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: [PATCHv9 00/25] Integration of videobuf2 with DMABUF
Hi Mauro, On Wednesday 10 October 2012 07:54:18 Mauro Carvalho Chehab wrote: Em Tue, 02 Oct 2012 16:27:11 +0200 Tomasz Stanislawski escreveu: Hello everyone, This patchset adds support for DMABUF [2] importing and exporting to V4L2 stack. v9: - rebase on 3.6 - change type for fs to __s32 - add support for vb2_ioctl_expbuf - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING', it will be posted as a separate patch - fix typos and style in Documentation (from Hans Verkuil) - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig - use data_offset and length while queueing DMABUF - return the most recently used fd at VIDIOC_DQBUF - use (buffer-type, index, plane) tuple instead of mem_offset to identify a for exporting (from Hans Verkuil) - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart) - add testing alignment of vaddr and size while verifying userptr against DMA capabilities (from Laurent Pinchart) - substitute VM_DONTDUMP with VM_RESERVED - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart) For now, NACK. See below. I spent 4 days trying to setup an environment that would allow testing DMABUF with video4linux without success (long story, see below). Also, Laurent tried the same without any luck, and it seems that it even corrupted his test machine. To be exact, the i915 driver crashed, not due to DMABUF but because it lacks support for YUV frame buffer on the CRTC (YUV is only supported in extra planes) and failed to properly reject the set mode ioctl. My test machine is doing fine :-) I'll modify the test application to create a YUV plane and will let you know about the result. Basically Samsung generously donated me two boards that it could be used on this test (Origen and SMDK310). None of them actually worked with the upstream kernel: patches are needed to avoid OOPSes on Origen; both Origen/SMDK310 defconfigs are completely broken, and drivers don't even boot if someone tries to use the Kernel's defconfigs. Even after spending _days_ trying to figure out the needed .config options (as the config files are not easily available), both boards have... issues: - lack of any display output driver at SMDK310; - lack of any network driver at Origen: it seems that none of the available network options on Origen was upstreamed: no Bluetooth, no OTG, no Wifi. The only test I was able to do (yesterday, late night), the DMABUF caused an OOPS at the Origen board. So, for sure it is not ready for upstream. It is now, too late for 3.7. I might consider it to 3.8, if something can be done to fix the existing issues, and setup a proper setup, using the upstream Kernel. -- Regards, Laurent Pinchart -- 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 3/5] m920x_parse.pl: use string comparison operators
---
contrib/m920x/m920x_parse.pl | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/contrib/m920x/m920x_parse.pl b/contrib/m920x/m920x_parse.pl
index 135ed5a..9093e16 100755
--- a/contrib/m920x/m920x_parse.pl
+++ b/contrib/m920x/m920x_parse.pl
@@ -64,7 +64,7 @@ sub check {
@cmp = split(/ /, $cmd);
for ($i = 0; $i scalar(@cmp); $i++) {
#print check $bytes[$i] vs $cmp[$i]\n;
- if ($cmp[$i] == -1) {
+ if ($cmp[$i] eq -1) {
next;
}
@@ -102,7 +102,7 @@ sub get_line {
}
@cmp = split(/ /, $cmd);
for ($i = 0; $i scalar(@cmp); $i++) {
- if ($cmp[$i] == -1) {
+ if ($cmp[$i] eq -1) {
next;
}
@@ -117,10 +117,10 @@ sub get_line {
sub us_get_write {
#print $line\n;
- if($input == us $line =~ m/\s+([a-fA-F0-9 ]+)/) {
+ if($input eq us $line =~ m/\s+([a-fA-F0-9 ]+)/) {
return split(/ /, $1);
}
- if($input == um) {
+ if($input eq um) {
if($line =~ m/\S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ =
([a-fA-F0-9 ]+)/) {
#print read match $line\n;
return expand_string_long(split(/ /, $1));
@@ -130,10 +130,10 @@ sub us_get_write {
sub get_read {
#print $line\n;
- if($input == us $line =~ m/ ([a-fA-F0-9 ]+)/) {
+ if($input eq us $line =~ m/ ([a-fA-F0-9 ]+)/) {
return split(/ /, $1);
}
- if($input == um) {
+ if($input eq um) {
while($line = STDIN) {
if($line =~ m/\S+ \S+ \S+ \S+ \S+ \S+ = ([a-fA-F0-9
]+)/) {
return expand_string_long(split(/ /, $1));
@@ -161,11 +161,11 @@ getopts(m:i:, \%opt ) or usage();
$mode = $opt{m};
$input = $opt{i};
-if ($input != um $input != us $input != sp) {
+if ($input ne um $input ne us $input ne sp) {
usage();
}
-if ($mode != fw $mode != i2c) {
+if ($mode ne fw $mode ne i2c) {
usage();
}
@@ -207,9 +207,9 @@ while(@bytes = get_line(-1)) {
$master_line = $. - 1;
- if ($bytes[0] == 40 $bytes[1] == 23) {
+ if ($bytes[0] eq 40 $bytes[1] eq 23) {
- if ($bytes[4] == 80 || $bytes[4] == 00) {
+ if ($bytes[4] eq 80 || $bytes[4] eq 00) {
my $multibyte = 0;
my $addr;
@@ -225,16 +225,16 @@ while(@bytes = get_line(-1)) {
@bytes = get_line(40 23);
$reg = $bytes[2];
- if ($bytes[4] == 80) {
+ if ($bytes[4] eq 80) {
$multibyte = 1;
} else {
@bytes = get_line(40 23);
}
- #if ($bytes[4] != 40) {
+ #if ($bytes[4] ne 40) {
# print (missing 40);
#}
- if ($bytes[4] == 80) {
+ if ($bytes[4] eq 80) {
if ($multibyte == 0) {
$raddr = sprintf(%02x, hex($addr) |
0x1);
@@ -245,7 +245,7 @@ while(@bytes = get_line(-1)) {
} else {
print $reg = ;
@bytes = get_line(c0 23);
- while ($bytes[4] == 21) {
+ while ($bytes[4] eq 21) {
check(c0 23 00 00 21 00 -1
-1, @bytes);
@bytes = get_read();
@@ -265,7 +265,7 @@ while(@bytes = get_line(-1)) {
check(40 23 -1 00 4|00 00 00 00, @bytes);
print reg $reg = $bytes[2];
- while ($bytes[4] != 40) {
+ while ($bytes[4] ne 40) {
@bytes = get_line(40 23);
check(40 23 -1 00 4|00 00 00 00,
@bytes);
print $bytes[2];
--
1.7.10.4
--
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/5] contrib: add some scripts to extract m920x firmwares from USB dumps
From: Aapo Tahkola a...@rasterburn.org
Signed-off-by: Aapo Tahkola a...@rasterburn.org
---
contrib/m920x/m920x_parse.pl | 277
contrib/m920x/m920x_sp_firmware.pl | 115 +++
2 files changed, 392 insertions(+)
create mode 100755 contrib/m920x/m920x_parse.pl
create mode 100755 contrib/m920x/m920x_sp_firmware.pl
diff --git a/contrib/m920x/m920x_parse.pl b/contrib/m920x/m920x_parse.pl
new file mode 100755
index 000..135ed5a
--- /dev/null
+++ b/contrib/m920x/m920x_parse.pl
@@ -0,0 +1,277 @@
+#!/usr/bin/perl
+#
+# This ULi M920x specific script processes usbsnoop log files (as well as
those which have been parsed by mrec's parser.pl utility).
+# Taken from http://www.linuxtv.org/wiki/index.php/ULi_M920x_parse
+
+use Getopt::Std;
+
+sub expand_string {
+ my @arr = ();
+ my ($str) = @_;
+
+ if (length($str) == 8) {
+ push(@arr, substr($str, 0, 2));
+ push(@arr, substr($str, 2, 2));
+ push(@arr, substr($str, 4, 2));
+ push(@arr, substr($str, 6, 2));
+ }elsif(length($str) == 4) {
+ push(@arr, substr($str, 0, 2));
+ push(@arr, substr($str, 2, 2));
+ }elsif(length($str) == 2) {
+ push(@arr, $str);
+ }elsif(length($str) == 1) {
+ return;
+ }
+ return @arr;
+}
+
+sub expand_string_long {
+ my @bytes = ();
+ my (@str) = @_;
+
+ foreach(@str) {
+ #@arr = expand_string($_);
+ #foreach(@arr){
+ # push(@bytes, $_);
+ #}
+ @bytes = ( @bytes, expand_string($_) );
+ }
+
+ return @bytes;
+}
+
+sub print_array_bytes {
+ my (@str) = @_;
+
+ foreach(expand_string_long(@str)){
+ print $_ ;
+ }
+}
+
+sub print_bytes {
+ my ($str) = @_;
+
+ print_array_bytes(split(/ /, $str));
+}
+
+sub check {
+ my ($cmd, @bytes) = @_;
+ my @cmp;
+ my $i;
+ #print cmd $cmd\n;
+ my $fail = 0;
+
+ @cmp = split(/ /, $cmd);
+ for ($i = 0; $i scalar(@cmp); $i++) {
+ #print check $bytes[$i] vs $cmp[$i]\n;
+ if ($cmp[$i] == -1) {
+ next;
+ }
+
+ if (not($bytes[$i] =~ m/$cmp[$i]/)) {
+ $fail = 1;
+ print ($bytes[$i]!=$cmp[$i], $i);
+ }
+ }
+ if ($fail) {
+ print \n;
+ print_array_bytes(@bytes);
+ print \n$cmd\n;
+ }
+}
+
+sub get_line {
+ my ($cmd) = @_; # xxx: could be more flexible
+ my @ret;
+ my @cmp;
+ my $i;
+
+ again:
+ while($line = STDIN) {
+ #001295: OUT: 02 ms 135775 ms 40 23 c0 00 80 00 00 00
+ if($input eq us $line =~ m/\S+: \S+: \S+ ms \S+ ms
([a-fA-F0-9 ]+)/) {
+ @ret = split(/ /, $1); $foo = $1;
+ @ret[2,3,4,5,6,7] = @ret[3,2,5,4,7,6];
+ last;
+ }
+
+ if($input eq um $line =~ m/\S+ \S+ \S+ \S+ s ([a-fA-F0-9
]+)/) {
+ @ret = expand_string_long(split(/ /, $1)); $foo = $1;
+ last;
+ }
+ }
+ @cmp = split(/ /, $cmd);
+ for ($i = 0; $i scalar(@cmp); $i++) {
+ if ($cmp[$i] == -1) {
+ next;
+ }
+
+ if (not($cmp[$i] eq $ret[$i])) {
+ #print fail\n;
+ goto again;
+ }
+ }
+
+ return @ret;
+}
+
+sub us_get_write {
+ #print $line\n;
+ if($input == us $line =~ m/\s+([a-fA-F0-9 ]+)/) {
+ return split(/ /, $1);
+ }
+ if($input == um) {
+ if($line =~ m/\S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ \S+ =
([a-fA-F0-9 ]+)/) {
+ #print read match $line\n;
+ return expand_string_long(split(/ /, $1));
+ }
+ }
+}
+
+sub get_read {
+ #print $line\n;
+ if($input == us $line =~ m/ ([a-fA-F0-9 ]+)/) {
+ return split(/ /, $1);
+ }
+ if($input == um) {
+ while($line = STDIN) {
+ if($line =~ m/\S+ \S+ \S+ \S+ \S+ \S+ = ([a-fA-F0-9
]+)/) {
+ return expand_string_long(split(/ /, $1));
+ }
+
+ }
+ }
+}
+
+sub usage {
+ print STDERR EOF;
+
+ -i um (usbmon)
+ us (usb snoop)
+ sp (snoopy pro)
+
+ -m fw (extract firmware)
+ i2c (show i2c traffic)
+EOF
+exit;
+}
+
+getopts(m:i:, \%opt ) or usage();
+
+$mode = $opt{m};
+$input = $opt{i};
+
+if ($input != um $input != us $input != sp) {
+ usage();
+}
+
+if ($mode != fw $mode != i2c) {
+ usage();
+}
+
+if ($mode eq
[PATCH 5/5] m920x_parse.pl: add support for consuming the output of parse-sniffusb2.pl
---
contrib/m920x/m920x_parse.pl | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/contrib/m920x/m920x_parse.pl b/contrib/m920x/m920x_parse.pl
index b315400..b309250 100755
--- a/contrib/m920x/m920x_parse.pl
+++ b/contrib/m920x/m920x_parse.pl
@@ -103,6 +103,13 @@ sub get_line {
last;
}
+ #40 23 c0 00 80 00 00 00
+ if($input eq us2 $line =~ m/([a-fA-F0-9 ]+)/) {
+ @ret = split(/ /, $1); $foo = $1;
+ @ret[2,3,4,5,6,7] = @ret[3,2,5,4,7,6];
+ last;
+ }
+
if($input eq um $line =~ m/\S+ \S+ \S+ \S+ s ([a-fA-F0-9
]+)/) {
@ret = expand_string_long(split(/ /, $1)); $foo = $1;
last;
@@ -125,7 +132,7 @@ sub get_line {
sub us_get_write {
#print $line\n;
- if($input eq us $line =~ m/\s+([a-fA-F0-9 ]+)/) {
+ if(($input eq us || $input eq us2) $line =~ m/\s+([a-fA-F0-9
]+)/) {
return split(/ /, $1);
}
if($input eq um) {
@@ -138,7 +145,7 @@ sub us_get_write {
sub get_read {
#print $line\n;
- if($input eq us $line =~ m/ ([a-fA-F0-9 ]+)/) {
+ if(($input eq us || $input eq us2) $line =~ m/\s+([a-fA-F0-9
]+)/) {
return split(/ /, $1);
}
if($input eq um) {
@@ -156,6 +163,7 @@ sub usage {
-i um (usbmon)
us (usb snoop)
+ us2 (usb snoop as produced by parse-sniffusb2.pl)
sp (snoopy pro)
-m fw (extract firmware)
@@ -169,7 +177,7 @@ getopts(m:i:, \%opt ) or usage();
$mode = $opt{m};
$input = $opt{i};
-if ($input ne um $input ne us $input ne sp) {
+if ($input ne um $input ne us $input ne us2 $input ne sp) {
usage();
}
--
1.7.10.4
--
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 0/5] v4l-utils: add some scripts from the wiki.
Hi, I recently used some scripts I found on the linuxtv.org wiki to extract a firmware for a m920x device from USB dumps made with UsbSniff2.0 on WIndows XP. I thought these scripts may be collected in v4l-utils where it is easier to change them. The first two patches add the scripts as they are now on the wiki, I am sending them on behalf of the original author even if I was not able to contact him, I hope this is OK. The subsequent changes are little fixes to make m920x_parse.pl work for me. Regards, Antonio Aapo Tahkola (2): contrib: add some scripts to extract m920x firmwares from USB dumps contrib: add a script to convert usbmon captures to usbsnoop Antonio Ospite (3): m920x_parse.pl: use string comparison operators m920x_parse.pl: fix strict and warnings checks m920x_parse.pl: add support for consuming the output of parse-sniffusb2.pl contrib/m920x/m920x_parse.pl | 295 contrib/m920x/m920x_sp_firmware.pl | 115 ++ contrib/usbmon2usbsnoop.pl | 53 +++ 3 files changed, 463 insertions(+) create mode 100755 contrib/m920x/m920x_parse.pl create mode 100755 contrib/m920x/m920x_sp_firmware.pl create mode 100755 contrib/usbmon2usbsnoop.pl -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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/5] contrib: add a script to convert usbmon captures to usbsnoop
From: Aapo Tahkola a...@rasterburn.org
This makes it possible to reuse tools written for usbsnoop with captures
done using a virtual machine and usbmon.
Signed-off-by: Aapo Tahkola a...@rasterburn.org
---
contrib/usbmon2usbsnoop.pl | 53
1 file changed, 53 insertions(+)
create mode 100755 contrib/usbmon2usbsnoop.pl
diff --git a/contrib/usbmon2usbsnoop.pl b/contrib/usbmon2usbsnoop.pl
new file mode 100755
index 000..c656687
--- /dev/null
+++ b/contrib/usbmon2usbsnoop.pl
@@ -0,0 +1,53 @@
+#!/usr/bin/perl
+#
+# This perl script converts output from usbmon to a format (usbsnoop's log
format) that is compatible with usbreplay.
+# Taken from http://www.linuxtv.org/wiki/index.php/Usbmon2usbsnoop
+
+sub print_bytes{
+ my($str) = @_;
+
+ @str_1 = split(/ /, $str);
+
+ foreach(@str_1){
+ if (length($_) == 8) {
+ print substr($_, 0, 2) . . substr($_, 2, 2) . .
substr($_, 4, 2) . . substr($_, 6, 2);
+ }elsif(length($_) == 4) {
+ print substr($_, 2, 2) . . substr($_, 0, 2);
+ }elsif(length($_) == 2) {
+ print $_;
+ }elsif(length($_) == 1) {
+ next;
+ }
+ print ;
+ }
+}
+
+
+$i = 0;
+while($line = STDIN) {
+ $i++;
+
+ if($line =~ m/\S+ \S+ \S+ \S+ \S+ (.+) \S+ /) {
+ printf %06d: OUT: %06d ms %06d ms , $i, 1, $i;
+ print_bytes($1);
+ print ;
+ $line = STDIN;
+ $i++;
+ if($line =~ m/\S+ \S+ \S+ \S+ [a-fA-F0-9 ]+ = ([a-fA-F0-9 ]+)/)
{
+ print_bytes($1);
+ #print \n;
+ #print $1\n;
+ }
+ print \n;
+ }elsif($line =~ m/\S+ \S+ \S+ \S+ ([a-fA-F0-9 ]+) [a-fA-F0-9]+ =
([a-fA-F0-9 ]+)/) {
+ printf %06d: OUT: %06d ms %06d ms , $i, 1, $i;
+ print_bytes($1);
+ print ;
+ print_bytes($2);
+ print \n;
+ }elsif($line =~ m/\S+ \S+ \S+ \S+ s (.+)/) {
+ printf %06d: OUT: %06d ms %06d ms , $i, 1, $i;
+ print_bytes($1);
+ print \n;
+ }
+}
--
1.7.10.4
--
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 4/5] m920x_parse.pl: fix strict and warnings checks
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
contrib/m920x/m920x_parse.pl | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/contrib/m920x/m920x_parse.pl b/contrib/m920x/m920x_parse.pl
index 9093e16..b315400 100755
--- a/contrib/m920x/m920x_parse.pl
+++ b/contrib/m920x/m920x_parse.pl
@@ -3,8 +3,15 @@
# This ULi M920x specific script processes usbsnoop log files (as well as
those which have been parsed by mrec's parser.pl utility).
# Taken from http://www.linuxtv.org/wiki/index.php/ULi_M920x_parse
+use strict;
+use warnings;
use Getopt::Std;
+my $line;
+my $mode;
+my $input;
+my %opt;
+
sub expand_string {
my @arr = ();
my ($str) = @_;
@@ -85,6 +92,7 @@ sub get_line {
my @ret;
my @cmp;
my $i;
+ my $foo;
again:
while($line = STDIN) {
@@ -169,32 +177,34 @@ if ($mode ne fw $mode ne i2c) {
usage();
}
+my @bytes;
+
if ($mode eq fw) {
- open(out, fw) || die Can't open fw;
+ open(OUT, , fw) || die Can't open fw;
while(@bytes = get_line()) {
if(scalar(@bytes) = 1) {
last;
}
- $len = hex($bytes[6] . $bytes[7]);
+ my $len = hex($bytes[6] . $bytes[7]);
if ($len 32) {
next;
}
- @fw_bytes = us_get_write();
+ my @fw_bytes = us_get_write();
if ($len != scalar(@fw_bytes)) {
#note: usbmon will not log bulk writes longer than 32
bytes by default
print bulk size doesn't match! Check usbmon.\n;
print $len . != . scalar(@fw_bytes) . \n;
exit(0);
}
- print out pack(v, hex($bytes[2] . $bytes[3]));
- print out pack(v, hex($bytes[4] . $bytes[5]));
- print out pack(v, scalar(@fw_bytes));
+ print OUT pack(v, hex($bytes[2] . $bytes[3]));
+ print OUT pack(v, hex($bytes[4] . $bytes[5]));
+ print OUT pack(v, scalar(@fw_bytes));
foreach(@fw_bytes) {
- print out pack(C, hex($_));
+ print OUT pack(C, hex($_));
}
}
exit(1);
@@ -205,7 +215,7 @@ while(@bytes = get_line(-1)) {
last;
}
- $master_line = $. - 1;
+ my $master_line = $. - 1;
if ($bytes[0] eq 40 $bytes[1] eq 23) {
@@ -224,7 +234,7 @@ while(@bytes = get_line(-1)) {
@bytes = get_line(40 23);
- $reg = $bytes[2];
+ my $reg = $bytes[2];
if ($bytes[4] eq 80) {
$multibyte = 1;
} else {
@@ -236,7 +246,7 @@ while(@bytes = get_line(-1)) {
if ($bytes[4] eq 80) {
if ($multibyte == 0) {
- $raddr = sprintf(%02x, hex($addr) |
0x1);
+ my $raddr = sprintf(%02x, hex($addr)
| 0x1);
check(40 23 $raddr 00 80 00 00 00,
@bytes);
--
1.7.10.4
--
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 05/14] media: add a V4L2 OF parser
Em Wed, 10 Oct 2012 14:54 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Also, ideally OF-compatible (I2C) drivers should run with no platform data, but soc-camera is using I2C device platform data intensively. To avoid modifying the soc-camera core and all drivers, I also trigger on the BUS_NOTIFY_BIND_DRIVER event and assign a reference to the dynamically created platform data to the I2C device. Would we also want to do this for all V4L2 bridge drivers? We could call this a prepare callback or something similar... If that's going to be an interim solution only I'm fine with keeping it in soc-camera. I'm far from being an OF expert, but why do we need to export I2C devices to DT/OF? On my understanding, it is the bridge code that should be responsible for detecting, binding and initializing the proper I2C devices. On several cases, it is impossible or it would cause lots of ugly hacks if we ever try to move away from platform data stuff, as only the bridge driver knows what initialization is needed for an specific I2C driver. To make things more complex, it is expected that most I2C drivers to be arch independent, and they should be allowed to be used by a personal computer or by an embedded device. Let me give 2 such examples: - ir-i2c-kbd driver supports lots of IR devices. Platform_data is needed to specify what hardware will actually be used, and what should be the default Remote Controller keymap; - Sensor drivers like ov2940 is needed by soc_camera and by other webcam drivers like em28xx. The setup for em28xx should be completely different than the one for soc_camera: the initial registers init sequence is different for both. As several registers there aren't properly documented, there's no easy way to parametrize the configuration. So, for me, we should not expose the I2C devices directly on OF; it should, instead, see just the bridge, and let the bridge to map the needed I2C devices using the needed platform_data. -- 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: [PATCHv9 19/25] v4l: vb2: add buffer exporting via dmabuf
On 10/06/2012 02:22 PM, Hans Verkuil wrote:
On Tue October 2 2012 16:27:30 Tomasz Stanislawski wrote:
This patch adds extension to videobuf2-core. It allow to export a mmap buffer
as a file descriptor.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-core.c | 82
++
include/media/videobuf2-core.h |4 ++
2 files changed, 86 insertions(+)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 05da3b4..a97815b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
snip
@@ -2455,6 +2528,15 @@ int vb2_ioctl_streamoff(struct file *file, void
*priv, enum v4l2_buf_type i)
}
EXPORT_SYMBOL_GPL(vb2_ioctl_streamoff);
+int vb2_ioctl_expbuf(struct file *file, void *priv, struct
v4l2_exportbuffer *p)
+{
+struct video_device *vdev = video_devdata(file);
+
+/* No need to call vb2_queue_is_busy(), anyone can export buffers. */
Hi Hans,
After thinking about this some more I'm not so sure we should allow this.
Exporting a buffer also means that the memory can't be freed as long as the
exported filehandle remains open.
You are completely right.
But the problem is much more complex ... see below.
That means that it is possible to make a malicious application that exports
the buffers and never frees them, which can cause havoc.
What kind of havoc do you mean? Resource leakage?
I think that only
the filehandle that called REQBUFS/CREATE_BUFS should be allowed to export
buffers.
Notice that you should allow to call mmap() only for the file handles that
called
REQBUFS/CREATE_BUFS. The mmap() creates a vma that holds a reference to a
buffer.
As long as the mapping exists, the buffers cannot be freed and REQBUFS(count=0)
returns -EBUSY.
According to V4L2 spec all the nodes share the same context, therefore
one process can call REQBUFS, and the other can call QUERYBUF and mmap().
Therefore if EXPBUF has to check vb2_queue_is_busy() then vb2_fop_mmap()
should do the same check too.
IMO, it is very difficult to develop a useful multi-client API that
would protect V4L2 from creating non-freeable buffers by a rogue applications.
I think that the requirements below:
- the buffers should be sharable between processes by mmap(), or DMABUF
exporting
- the REQBUFS(count=0) should release the buffers
are contradictory and cannot be *reliably* satisfied at the same time.
Notice that REQBUFS(count=0) that unexpectedly return -EBUSY is not
a reliable solution. The application cannot do anything fix the problem
after receiving -EBUSY.
Anyway, I will apply the check for vb2_queue_is_busy() in v2b_ioctl_expbuf().
Regards,
Tomasz Stanislawski
What do you think?
Regards,
Hans
+return vb2_expbuf(vdev-queue, p);
+}
+EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf);
+
/* v4l2_file_operations helpers */
int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma)
--
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 0/5] v4l-utils: add some scripts from the wiki.
On 10/10/2012 04:39 PM, Antonio Ospite wrote: Hi, I recently used some scripts I found on the linuxtv.org wiki to extract a firmware for a m920x device from USB dumps made with UsbSniff2.0 on WIndows XP. I thought these scripts may be collected in v4l-utils where it is easier to change them. The first two patches add the scripts as they are now on the wiki, I am sending them on behalf of the original author even if I was not able to contact him, I hope this is OK. I am almost 100% it is not OK to sign those to Kernel behalf of Aapo. Maybe it is possible to keep Aapo as a author, but sign with yourself. The subsequent changes are little fixes to make m920x_parse.pl work for me. Regards, Antonio Aapo Tahkola (2): contrib: add some scripts to extract m920x firmwares from USB dumps contrib: add a script to convert usbmon captures to usbsnoop Antonio Ospite (3): m920x_parse.pl: use string comparison operators m920x_parse.pl: fix strict and warnings checks m920x_parse.pl: add support for consuming the output of parse-sniffusb2.pl contrib/m920x/m920x_parse.pl | 295 contrib/m920x/m920x_sp_firmware.pl | 115 ++ contrib/usbmon2usbsnoop.pl | 53 +++ 3 files changed, 463 insertions(+) create mode 100755 contrib/m920x/m920x_parse.pl create mode 100755 contrib/m920x/m920x_sp_firmware.pl create mode 100755 contrib/usbmon2usbsnoop.pl regards Antti -- http://palosaari.fi/ -- 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 05/14] media: add a V4L2 OF parser
Hi Mauro, On Wednesday 10 October 2012 10:45:22 Mauro Carvalho Chehab wrote: Em Wed, 10 Oct 2012 14:54 +0200 Laurent Pinchart escreveu: Also, ideally OF-compatible (I2C) drivers should run with no platform data, but soc-camera is using I2C device platform data intensively. To avoid modifying the soc-camera core and all drivers, I also trigger on the BUS_NOTIFY_BIND_DRIVER event and assign a reference to the dynamically created platform data to the I2C device. Would we also want to do this for all V4L2 bridge drivers? We could call this a prepare callback or something similar... If that's going to be an interim solution only I'm fine with keeping it in soc-camera. I'm far from being an OF expert, but why do we need to export I2C devices to DT/OF? On my understanding, it is the bridge code that should be responsible for detecting, binding and initializing the proper I2C devices. On several cases, it is impossible or it would cause lots of ugly hacks if we ever try to move away from platform data stuff, as only the bridge driver knows what initialization is needed for an specific I2C driver. In a nutshell, a DT-based platform doesn't have any board code (except in rare cases, but let's not get into that), and thus doesn't pass any platform data structure to drivers. However, drivers receive a DT node, which contains a hierarchical description of the hardware, and parse those to extract information necessary to configure the device. One very important point to keep in mind here is that the DT is not Linux- specific. DT bindings are designed to be portable, and thus must only contain hardware descriptions, without any OS-specific information or policy information. For instance information such as the maximum video buffers size is not allowed in the DT. The DT is used both to provide platform data to drivers and to instantiate devices. I2C device DT nodes are stored as children of the I2C bus master DT node, and are automatically instantiated by the I2C bus master. This is a significant change compared to our current situation where the V4L2 bridge driver receives an array of I2C board information structures and instatiates the devices itself. Most of the DT support work will go in supporting that new instantiation mechanism. The bridge driver doesn't control instantiation of the I2C devices anymore, but need to bind with them at runtime. To make things more complex, it is expected that most I2C drivers to be arch independent, and they should be allowed to be used by a personal computer or by an embedded device. Agreed. That's why platform data structures won't go away anytime soon, a PCI bridge driver for hardware that contain I2C devices will still instantiate the I2C devices itself. We don't plan to or even want to get rid of that mechanism, as there are perfectly valid use cases. However, for DT-based embedded platforms, we need to support a new instantiation mechanism. Let me give 2 such examples: - ir-i2c-kbd driver supports lots of IR devices. Platform_data is needed to specify what hardware will actually be used, and what should be the default Remote Controller keymap; That driver isn't used on embedded platforms so it doesn't need to be changed now. - Sensor drivers like ov2940 is needed by soc_camera and by other webcam drivers like em28xx. The setup for em28xx should be completely different than the one for soc_camera: the initial registers init sequence is different for both. As several registers there aren't properly documented, there's no easy way to parametrize the configuration. Such drivers will need to support both DT-based platform data and structure- based platform data. They will likely parse the DT node and fill a platform data structure, to avoid duplicating initialization code. Please note that the new subdevs instantiation mechanism needed for DT will need to handle any instantiation order, as we can't guarantee the I2C device and bridge device instantiation order with DT. It should thus then support the current instantiation order we use for PCI and USB platforms. So, for me, we should not expose the I2C devices directly on OF; it should, instead, see just the bridge, and let the bridge to map the needed I2C devices using the needed platform_data. We can't do that, there will be no platform data anymore with DT-based platforms. As a summary, platform data structures won't go away, I2C drivers that need to work both on DT-based and non-DT-based platforms will need to support both the DT and platform data structures to get platform data. PCI and USB bridges will still instantiate their I2C devices, and binding between the I2C devices and the bridge can either be handled with two different instantiation mechanisms (the new one for DT platforms, with runtime bindings, and the existing one for non-DT platforms, with binding at instantiation time) or move to a single runtime
[PATCHv10 00/26] Integration of videobuf2 with DMABUF
Hello everyone,
This patchset adds support for DMABUF [2] importing and exporting to V4L2
stack.
v10:
- rebase on media-next 3.7
- typos and style fixes in Documentation (from Hans Verkuil)
- fix compilation error with __fill_vb2_buffer
- fix uninitialized data_offset for single-planar queue
- support for DMABUF importing in S5P-FIMC mem-to-mem interface
- update layout of v4l2_exportbuffer structure
- update ioctl flags in v4l2_ioctls for VIDIOC_EXPBUF
- support for DMABUF exporting in m2m framework
- allow exporting for file handles that calle REQBUBS/CREATE_BUF
- simplify handling of get_device in vb2_dc_alloc
- reduce pr_err to pr_debug while checking alignment of userptr
- check size of userptr buffer against zero
- align size to PAGE_SIZE at allocation of dma-contig buffer
v9:
- rebase on 3.6
- change type for fs to __s32
- add support for vb2_ioctl_expbuf
- remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
it will be posted as a separate patch
- fix typos and style in Documentation (from Hans Verkuil)
- only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
- use data_offset and length while queueing DMABUF
- return the most recently used fd at VIDIOC_DQBUF
- use (buffer-type, index, plane) tuple instead of mem_offset
to identify a for exporting (from Hans Verkuil)
- support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
- add testing alignment of vaddr and size while verifying userptr
against DMA capabilities (from Laurent Pinchart)
- substitute VM_DONTDUMP with VM_RESERVED
- simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
v8:
- rebased on 3.6-rc1
- merged importer and exporter patchsets
- fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs
- fixed typos/style in documentation
- significant reduction of warnings from checkpatch.pl
- fixed STREAMOFF issues reported by Dima Zavin [4] by adding
__vb2_dqbuf helper to vb2-core
- DC fails if userptr is not correctly aligned
- add support for DMA attributes in DC
- add support for buffers with no kernel mapping
- add reference counting on device from allocator context
- dummy support for mmap
- use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and
vb2_dc_get_base_sgt helper
v7:
- support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c
- cosmetic fixes to the documentation
- added importing for vmalloc because vmap support in dmabuf for 3.5
was pull-requested
- support for dmabuf importing for VIVI
- resurrect allocation of dma-contig context
- remove reference of alloc_ctx in dma-contig buffer
- use sg_alloc_table_from_pages
- fix DMA scatterlist calls to use orig_nents instead of nents
- fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents)
v6:
- fixed missing entry in v4l2_memory_names
- fixed a bug occuring after get_user_pages failure
- fixed a bug caused by using invalid vma for get_user_pages
- prepare/finish no longer call dma_sync for dmabuf buffers
v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages_to_sgt basing on Laurent's hints
- changed pin/unpin words to lock/unlock in Doc
v4:
- rebased on mainline 3.4-rc2
- included missing importing support for s5p-fimc and s5p-tv
- added patch for changing map/unmap for importers
- fixes to Documentation part
- coding style fixes
- pairing {map/unmap}_dmabuf in vb2-core
- fixing variable types and semantic of arguments in videobufb2-dma-contig.c
v3:
- rebased on mainline 3.4-rc1
- split 'code refactor' patch to multiple smaller patches
- squashed fixes to Sumit's patches
- patchset is no longer dependant on 'DMA mapping redesign'
- separated path for handling IO and non-IO mappings
- add documentation for DMABUF importing to V4L
- removed all DMABUF exporter related code
- removed usage of dma_get_pages extension
v2:
- extended VIDIOC_EXPBUF argument from integer memoffset to struct
v4l2_exportbuffer
- added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows
to work with existing implementation of DMABUF prime in DRM
- all dma-contig code refactoring patches were squashed
- bugfixes
v1: List of changes since [1].
- support for DMA api extension dma_get_pages, the function is used to retrieve
pages used to create DMA mapping.
- small fixes/code cleanup to videobuf2
- added prepare and finish callbacks to vb2 allocators, it is used keep
consistency between dma-cpu acess to the memory (by Marek Szyprowski)
- support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from
[3].
- support for dma-buf exporting in vb2-dma-contig allocator
- support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
originated from [3]
- changed handling for userptr buffers (by Marek Szyprowski, Andrzej
Pietrasiewicz)
- let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)
[1]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
[2] https://lkml.org/lkml/2011/12/26/29
[3]
[PATCHv10 01/26] v4l: Add DMABUF as a memory type
From: Sumit Semwal sumit.sem...@ti.com
Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 18 ++
drivers/media/v4l2-core/v4l2-ioctl.c |1 +
include/linux/videodev2.h |7 +++
3 files changed, 26 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 83ffb64..cc5998b 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -297,6 +297,7 @@ struct v4l2_plane32 {
union {
__u32 mem_offset;
compat_long_t userptr;
+ __s32 fd;
} m;
__u32 data_offset;
__u32 reserved[11];
@@ -318,6 +319,7 @@ struct v4l2_buffer32 {
__u32 offset;
compat_long_t userptr;
compat_caddr_t planes;
+ __s32 fd;
} m;
__u32 length;
__u32 reserved2;
@@ -341,6 +343,9 @@ static int get_v4l2_plane32(struct v4l2_plane *up, struct
v4l2_plane32 *up32,
up_pln = compat_ptr(p);
if (put_user((unsigned long)up_pln, up-m.userptr))
return -EFAULT;
+ } else if (memory == V4L2_MEMORY_DMABUF) {
+ if (copy_in_user(up-m.fd, up32-m.fd, sizeof(int)))
+ return -EFAULT;
} else {
if (copy_in_user(up-m.mem_offset, up32-m.mem_offset,
sizeof(__u32)))
@@ -364,6 +369,11 @@ static int put_v4l2_plane32(struct v4l2_plane *up, struct
v4l2_plane32 *up32,
if (copy_in_user(up32-m.mem_offset, up-m.mem_offset,
sizeof(__u32)))
return -EFAULT;
+ /* For DMABUF, driver might've set up the fd, so copy it back. */
+ if (memory == V4L2_MEMORY_DMABUF)
+ if (copy_in_user(up32-m.fd, up-m.fd,
+ sizeof(int)))
+ return -EFAULT;
return 0;
}
@@ -446,6 +456,10 @@ static int get_v4l2_buffer32(struct v4l2_buffer *kp,
struct v4l2_buffer32 __user
if (get_user(kp-m.offset, up-m.offset))
return -EFAULT;
break;
+ case V4L2_MEMORY_DMABUF:
+ if (get_user(kp-m.fd, up-m.fd))
+ return -EFAULT;
+ break;
}
}
@@ -510,6 +524,10 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp,
struct v4l2_buffer32 __user
if (put_user(kp-m.offset, up-m.offset))
return -EFAULT;
break;
+ case V4L2_MEMORY_DMABUF:
+ if (put_user(kp-m.fd, up-m.fd))
+ return -EFAULT;
+ break;
}
}
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 8f388ff..530a67e 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -155,6 +155,7 @@ static const char *v4l2_memory_names[] = {
[V4L2_MEMORY_MMAP]= mmap,
[V4L2_MEMORY_USERPTR] = userptr,
[V4L2_MEMORY_OVERLAY] = overlay,
+ [V4L2_MEMORY_DMABUF] = dmabuf,
};
#define prt_names(a, arr) (((unsigned)(a)) ARRAY_SIZE(arr) ? arr[a] :
unknown)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 873adbe..07bc5d6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -188,6 +188,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR = 2,
V4L2_MEMORY_OVERLAY = 3,
+ V4L2_MEMORY_DMABUF = 4,
};
/* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -604,6 +605,8 @@ struct v4l2_requestbuffers {
* should be passed to mmap() called on the video node)
* @userptr: when memory is V4L2_MEMORY_USERPTR, a userspace pointer
* pointing to this plane
+ * @fd:when memory is V4L2_MEMORY_DMABUF, a userspace
file
+ * descriptor associated with this plane
* @data_offset: offset in the plane to the start of data; usually 0,
* unless there is a header in
[PATCHv10 02/26] Documentation: media: description of DMABUF importing in V4L2
This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: linux-...@vger.kernel.org
---
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 181 +++-
.../DocBook/media/v4l/vidioc-create-bufs.xml | 16 +-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 17 ++
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 ++---
5 files changed, 235 insertions(+), 30 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/compat.xml
b/Documentation/DocBook/media/v4l/compat.xml
index 4fdf6b5..50eb630 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2586,6 +2586,10 @@ ioctls./para
paraVendor and device specific media bus pixel formats.
xref linkend=v4l2-mbus-vendor-spec-fmts /./para
/listitem
+listitem
+ paraImporting DMABUF file descriptors as a new IO method described
+ in xref linkend=dmabuf /./para
+/listitem
/itemizedlist
/section
diff --git a/Documentation/DocBook/media/v4l/io.xml
b/Documentation/DocBook/media/v4l/io.xml
index b5d1cbd..0abb5cb 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By
default
outgoing queue. When the constantO_NONBLOCK/constant flag was
given to the func-open; function, constantVIDIOC_DQBUF/constant
returns immediately with an EAGAIN; when no buffer is available. The
-func-select; or func-poll; function are always available./para
+func-select; or func-poll; functions are always available./para
paraTo start and stop capturing or output applications call the
VIDIOC-STREAMON; and VIDIOC-STREAMOFF; ioctl. Note
@@ -472,6 +472,162 @@ rest should be evident./para
/footnote/para
/section
+ section id=dmabuf
+titleStreaming I/O (DMA buffer importing)/title
+
+note
+ titleExperimental/title
+ paraThis is an link linkend=experimental experimental /link
+ interface and may change in the future./para
+/note
+
+paraThe DMABUF framework provides a generic method for sharing buffers
+between multiple devices. Device drivers that support DMABUF can export a DMA
+buffer to userspace as a file descriptor (known as the exporter role), import a
+DMA buffer from userspace using a file descriptor previously exported for a
+different or the same device (known as the importer role), or both. This
+section describes the DMABUF importer role API in V4L2./para
+
+paraInput and output devices support the streaming I/O method when the
+constantV4L2_CAP_STREAMING/constant flag in the
+structfieldcapabilities/structfield field of v4l2-capability; returned by
+the VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
+DMABUF file descriptors is supported is determined by calling the
+VIDIOC-REQBUFS; ioctl with the memory type set to
+constantV4L2_MEMORY_DMABUF/constant./para
+
+paraThis I/O method is dedicated to sharing DMA buffers between different
+devices, which may be V4L devices or other video-related devices (e.g. DRM).
+Buffers (planes) are allocated by a driver on behalf of an application. Next,
+these buffers are exported to the application as file descriptors using an API
+which is specific for an allocator driver. Only such file descriptor are
+exchanged. The descriptors and meta-information are passed in v4l2-buffer; (or
+in v4l2-plane; in the multi-planar API case). The driver must be switched
+into DMABUF I/O mode by calling the VIDIOC-REQBUFS; with the desired buffer
+type./para
+
+example
+ titleInitiating streaming I/O with DMABUF file descriptors/title
+
+ programlisting
+v4l2-requestbuffers; reqbuf;
+
+memset(amp;reqbuf, 0, sizeof (reqbuf));
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+reqbuf.memory = V4L2_MEMORY_DMABUF;
+reqbuf.count = 1;
+
+if (ioctl(fd, VIDIOC-REQBUFS;, amp;reqbuf) == -1) {
+ if (errno == EINVAL)
+ printf(Video capturing or DMABUF streaming is not
supported\n);
+ else
+ perror(VIDIOC_REQBUFS);
+
+ exit(EXIT_FAILURE);
+}
+ /programlisting
+/example
+
+paraThe buffer (plane) file descriptor is passed on the fly with the
+VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be
+associated with a different DMABUF descriptor. Although buffers are commonly
+cycled, applications can pass a different DMABUF descriptor at each
+constantVIDIOC_QBUF/constant call./para
+
+example
+ titleQueueing DMABUF using single plane API/title
+
+ programlisting
+int buffer_queue(int v4lfd, int index, int dmafd)
+{
+ v4l2-buffer; buf;
+
+ memset(amp;buf, 0, sizeof buf);
+ buf.type =
[PATCHv10 03/26] v4l: vb2: add support for shared buffer (dma_buf)
From: Sumit Semwal sumit.sem...@ti.com
This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A sample allocator of
dma-buf shared buffer is given at [1]]
[1]: Rob Clark's DRM:
https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/Kconfig |1 +
drivers/media/v4l2-core/videobuf2-core.c | 206 +-
include/media/videobuf2-core.h | 27
3 files changed, 231 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 0c54e19..2e787cc 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -59,6 +59,7 @@ config VIDEOBUF_DVB
# Used by drivers that need Videobuf2 modules
config VIDEOBUF2_CORE
+ select DMA_SHARED_BUFFER
tristate
config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 432df11..a51dad6 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -109,6 +109,36 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
}
/**
+ * __vb2_plane_dmabuf_put() - release memory associated with
+ * a DMABUF shared plane
+ */
+static void __vb2_plane_dmabuf_put(struct vb2_queue *q, struct vb2_plane *p)
+{
+ if (!p-mem_priv)
+ return;
+
+ if (p-dbuf_mapped)
+ call_memop(q, unmap_dmabuf, p-mem_priv);
+
+ call_memop(q, detach_dmabuf, p-mem_priv);
+ dma_buf_put(p-dbuf);
+ memset(p, 0, sizeof(*p));
+}
+
+/**
+ * __vb2_buf_dmabuf_put() - release memory associated with
+ * a DMABUF shared buffer
+ */
+static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
+{
+ struct vb2_queue *q = vb-vb2_queue;
+ unsigned int plane;
+
+ for (plane = 0; plane vb-num_planes; ++plane)
+ __vb2_plane_dmabuf_put(q, vb-planes[plane]);
+}
+
+/**
* __setup_offsets() - setup unique offsets (cookies) for every plane in
* every buffer on the queue
*/
@@ -230,6 +260,8 @@ static void __vb2_free_mem(struct vb2_queue *q, unsigned
int buffers)
/* Free MMAP buffers or release USERPTR buffers */
if (q-memory == V4L2_MEMORY_MMAP)
__vb2_buf_mem_free(vb);
+ else if (q-memory == V4L2_MEMORY_DMABUF)
+ __vb2_buf_dmabuf_put(vb);
else
__vb2_buf_userptr_put(vb);
}
@@ -362,6 +394,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
b-m.offset = vb-v4l2_planes[0].m.mem_offset;
else if (q-memory == V4L2_MEMORY_USERPTR)
b-m.userptr = vb-v4l2_planes[0].m.userptr;
+ else if (q-memory == V4L2_MEMORY_DMABUF)
+ b-m.fd = vb-v4l2_planes[0].m.fd;
}
/*
@@ -454,13 +488,28 @@ static int __verify_mmap_ops(struct vb2_queue *q)
}
/**
+ * __verify_dmabuf_ops() - verify that all memory operations required for
+ * DMABUF queue type have been provided
+ */
+static int __verify_dmabuf_ops(struct vb2_queue *q)
+{
+ if (!(q-io_modes VB2_DMABUF) || !q-mem_ops-attach_dmabuf ||
+ !q-mem_ops-detach_dmabuf || !q-mem_ops-map_dmabuf ||
+ !q-mem_ops-unmap_dmabuf)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
* __verify_memory_type() - Check whether the memory type and buffer type
* passed to a buffer operation are compatible with the queue.
*/
static int __verify_memory_type(struct vb2_queue *q,
enum v4l2_memory memory, enum v4l2_buf_type type)
{
- if (memory != V4L2_MEMORY_MMAP memory != V4L2_MEMORY_USERPTR) {
+ if (memory != V4L2_MEMORY_MMAP memory != V4L2_MEMORY_USERPTR
+ memory != V4L2_MEMORY_DMABUF) {
dprintk(1, reqbufs: unsupported memory type\n);
return -EINVAL;
}
@@ -484,6 +533,11 @@ static int __verify_memory_type(struct vb2_queue *q,
return -EINVAL;
}
+ if (memory == V4L2_MEMORY_DMABUF __verify_dmabuf_ops(q)) {
+ dprintk(1, reqbufs: DMABUF for current setup unsupported\n);
+ return -EINVAL;
+ }
+
/*
* Place the busy tests at the end: -EBUSY can be ignored when
* create_bufs is called with count == 0, but count == 0 should still
[PATCHv10 04/26] v4l: vb: remove warnings about MEMORY_DMABUF
From: Sumit Semwal sumit.sem...@ti.com Adding DMABUF memory type causes videobuf to complain about not using it in some switch cases. This patch removes these warnings. Signed-off-by: Sumit Semwal sumit.sem...@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf-core.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/v4l2-core/videobuf-core.c b/drivers/media/v4l2-core/videobuf-core.c index bf7a326..5449e8a 100644 --- a/drivers/media/v4l2-core/videobuf-core.c +++ b/drivers/media/v4l2-core/videobuf-core.c @@ -335,6 +335,9 @@ static void videobuf_status(struct videobuf_queue *q, struct v4l2_buffer *b, case V4L2_MEMORY_OVERLAY: b-m.offset = vb-boff; break; + case V4L2_MEMORY_DMABUF: + /* DMABUF is not handled in videobuf framework */ + break; } b-flags= 0; @@ -405,6 +408,7 @@ int __videobuf_mmap_setup(struct videobuf_queue *q, break; case V4L2_MEMORY_USERPTR: case V4L2_MEMORY_OVERLAY: + case V4L2_MEMORY_DMABUF: /* nothing */ break; } -- 1.7.9.5 -- 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
[PATCHv10 05/26] v4l: vb2-dma-contig: shorten vb2_dma_contig prefix to vb2_dc
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 36
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 4b71326..a05784f 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -32,9 +32,9 @@ struct vb2_dc_buf {
struct vb2_vmarea_handler handler;
};
-static void vb2_dma_contig_put(void *buf_priv);
+static void vb2_dc_put(void *buf_priv);
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
+static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
@@ -56,7 +56,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned
long size)
buf-size = size;
buf-handler.refcount = buf-refcount;
- buf-handler.put = vb2_dma_contig_put;
+ buf-handler.put = vb2_dc_put;
buf-handler.arg = buf;
atomic_inc(buf-refcount);
@@ -64,7 +64,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned
long size)
return buf;
}
-static void vb2_dma_contig_put(void *buf_priv)
+static void vb2_dc_put(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -75,14 +75,14 @@ static void vb2_dma_contig_put(void *buf_priv)
}
}
-static void *vb2_dma_contig_cookie(void *buf_priv)
+static void *vb2_dc_cookie(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
return buf-dma_addr;
}
-static void *vb2_dma_contig_vaddr(void *buf_priv)
+static void *vb2_dc_vaddr(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
if (!buf)
@@ -91,14 +91,14 @@ static void *vb2_dma_contig_vaddr(void *buf_priv)
return buf-vaddr;
}
-static unsigned int vb2_dma_contig_num_users(void *buf_priv)
+static unsigned int vb2_dc_num_users(void *buf_priv)
{
struct vb2_dc_buf *buf = buf_priv;
return atomic_read(buf-refcount);
}
-static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
+static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -111,7 +111,7 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct
vm_area_struct *vma)
vb2_common_vm_ops, buf-handler);
}
-static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
+static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
{
struct vb2_dc_buf *buf;
@@ -138,7 +138,7 @@ static void *vb2_dma_contig_get_userptr(void *alloc_ctx,
unsigned long vaddr,
return buf;
}
-static void vb2_dma_contig_put_userptr(void *mem_priv)
+static void vb2_dc_put_userptr(void *mem_priv)
{
struct vb2_dc_buf *buf = mem_priv;
@@ -150,14 +150,14 @@ static void vb2_dma_contig_put_userptr(void *mem_priv)
}
const struct vb2_mem_ops vb2_dma_contig_memops = {
- .alloc = vb2_dma_contig_alloc,
- .put= vb2_dma_contig_put,
- .cookie = vb2_dma_contig_cookie,
- .vaddr = vb2_dma_contig_vaddr,
- .mmap = vb2_dma_contig_mmap,
- .get_userptr= vb2_dma_contig_get_userptr,
- .put_userptr= vb2_dma_contig_put_userptr,
- .num_users = vb2_dma_contig_num_users,
+ .alloc = vb2_dc_alloc,
+ .put= vb2_dc_put,
+ .cookie = vb2_dc_cookie,
+ .vaddr = vb2_dc_vaddr,
+ .mmap = vb2_dc_mmap,
+ .get_userptr= vb2_dc_get_userptr,
+ .put_userptr= vb2_dc_put_userptr,
+ .num_users = vb2_dc_num_users,
};
EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
--
1.7.9.5
--
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
[PATCHv10 06/26] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
This patch removes a reference to alloc_ctx from an instance of a DMA
contiguous buffer. It helps to avoid a risk of a dangling pointer if the
context is released while the buffer is still valid. Moreover it removes one
dereference step while accessing a device structure.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index a05784f..20c95da 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -23,7 +23,7 @@ struct vb2_dc_conf {
};
struct vb2_dc_buf {
- struct vb2_dc_conf *conf;
+ struct device *dev;
void*vaddr;
dma_addr_t dma_addr;
unsigned long size;
@@ -37,22 +37,21 @@ static void vb2_dc_put(void *buf_priv);
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct vb2_dc_conf *conf = alloc_ctx;
+ struct device *dev = conf-dev;
struct vb2_dc_buf *buf;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-dma_addr,
- GFP_KERNEL);
+ buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
if (!buf-vaddr) {
- dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n,
- size);
+ dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
- buf-conf = conf;
+ buf-dev = dev;
buf-size = size;
buf-handler.refcount = buf-refcount;
@@ -69,7 +68,7 @@ static void vb2_dc_put(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
if (atomic_dec_and_test(buf-refcount)) {
- dma_free_coherent(buf-conf-dev, buf-size, buf-vaddr,
+ dma_free_coherent(buf-dev, buf-size, buf-vaddr,
buf-dma_addr);
kfree(buf);
}
--
1.7.9.5
--
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
[PATCHv10 07/26] v4l: vb2-dma-contig: reorder functions
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
Group functions by buffer type.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 92 ++--
1 file changed, 54 insertions(+), 38 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 20c95da..daac2b2 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -25,14 +25,56 @@ struct vb2_dc_conf {
struct vb2_dc_buf {
struct device *dev;
void*vaddr;
- dma_addr_t dma_addr;
unsigned long size;
- struct vm_area_struct *vma;
- atomic_trefcount;
+ dma_addr_t dma_addr;
+
+ /* MMAP related */
struct vb2_vmarea_handler handler;
+ atomic_trefcount;
+
+ /* USERPTR related */
+ struct vm_area_struct *vma;
};
-static void vb2_dc_put(void *buf_priv);
+/*/
+/* callbacks for all buffers */
+/*/
+
+static void *vb2_dc_cookie(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ return buf-dma_addr;
+}
+
+static void *vb2_dc_vaddr(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ return buf-vaddr;
+}
+
+static unsigned int vb2_dc_num_users(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ return atomic_read(buf-refcount);
+}
+
+/*/
+/*callbacks for MMAP buffers */
+/*/
+
+static void vb2_dc_put(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+
+ if (!atomic_dec_and_test(buf-refcount))
+ return;
+
+ dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
+ kfree(buf);
+}
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
@@ -63,40 +105,6 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
size)
return buf;
}
-static void vb2_dc_put(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- if (atomic_dec_and_test(buf-refcount)) {
- dma_free_coherent(buf-dev, buf-size, buf-vaddr,
- buf-dma_addr);
- kfree(buf);
- }
-}
-
-static void *vb2_dc_cookie(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return buf-dma_addr;
-}
-
-static void *vb2_dc_vaddr(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
- if (!buf)
- return NULL;
-
- return buf-vaddr;
-}
-
-static unsigned int vb2_dc_num_users(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return atomic_read(buf-refcount);
-}
-
static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
@@ -110,6 +118,10 @@ static int vb2_dc_mmap(void *buf_priv, struct
vm_area_struct *vma)
vb2_common_vm_ops, buf-handler);
}
+/*/
+/* callbacks for USERPTR buffers */
+/*/
+
static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
{
@@ -148,6 +160,10 @@ static void vb2_dc_put_userptr(void *mem_priv)
kfree(buf);
}
+/*/
+/* DMA CONTIG exported functions */
+/*/
+
const struct vb2_mem_ops vb2_dma_contig_memops = {
.alloc = vb2_dc_alloc,
.put= vb2_dc_put,
--
1.7.9.5
--
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
[PATCHv10 08/26] v4l: vb2-dma-contig: add support for scatterlist in userptr mode
This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.
This patch contains some of the code kindly provided by Marek Szyprowski
m.szyprow...@samsung.com and Kamil Debski k.deb...@samsung.com and Andrzej
Pietrasiewicz andrze...@samsung.com. Kind thanks for bug reports from Laurent
Pinchart laurent.pinch...@ideasonboard.com and Seung-Woo Kim
sw0312@samsung.com.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 226 ++--
1 file changed, 210 insertions(+), 16 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index daac2b2..8486e06 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -11,6 +11,8 @@
*/
#include linux/module.h
+#include linux/scatterlist.h
+#include linux/sched.h
#include linux/slab.h
#include linux/dma-mapping.h
@@ -27,6 +29,8 @@ struct vb2_dc_buf {
void*vaddr;
unsigned long size;
dma_addr_t dma_addr;
+ enum dma_data_direction dma_dir;
+ struct sg_table *dma_sgt;
/* MMAP related */
struct vb2_vmarea_handler handler;
@@ -37,6 +41,44 @@ struct vb2_dc_buf {
};
/*/
+/*scatterlist table functions*/
+/*/
+
+
+static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
+ void (*cb)(struct page *pg))
+{
+ struct scatterlist *s;
+ unsigned int i;
+
+ for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
+ struct page *page = sg_page(s);
+ unsigned int n_pages = PAGE_ALIGN(s-offset + s-length)
+PAGE_SHIFT;
+ unsigned int j;
+
+ for (j = 0; j n_pages; ++j, ++page)
+ cb(page);
+ }
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+ struct scatterlist *s;
+ dma_addr_t expected = sg_dma_address(sgt-sgl);
+ unsigned int i;
+ unsigned long size = 0;
+
+ for_each_sg(sgt-sgl, s, sgt-nents, i) {
+ if (sg_dma_address(s) != expected)
+ break;
+ expected = sg_dma_address(s) + sg_dma_len(s);
+ size += sg_dma_len(s);
+ }
+ return size;
+}
+
+/*/
/* callbacks for all buffers */
/*/
@@ -122,42 +164,194 @@ static int vb2_dc_mmap(void *buf_priv, struct
vm_area_struct *vma)
/* callbacks for USERPTR buffers */
/*/
+static inline int vma_is_io(struct vm_area_struct *vma)
+{
+ return !!(vma-vm_flags (VM_IO | VM_PFNMAP));
+}
+
+static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
+ int n_pages, struct vm_area_struct *vma, int write)
+{
+ if (vma_is_io(vma)) {
+ unsigned int i;
+
+ for (i = 0; i n_pages; ++i, start += PAGE_SIZE) {
+ unsigned long pfn;
+ int ret = follow_pfn(vma, start, pfn);
+
+ if (ret) {
+ pr_err(no page for address %lu\n, start);
+ return ret;
+ }
+ pages[i] = pfn_to_page(pfn);
+ }
+ } else {
+ int n;
+
+ n = get_user_pages(current, current-mm, start PAGE_MASK,
+ n_pages, write, 1, pages, NULL);
+ /* negative error means that no page was pinned */
+ n = max(n, 0);
+ if (n != n_pages) {
+ pr_err(got only %d of %d user pages\n, n, n_pages);
+ while (n)
+ put_page(pages[--n]);
+ return -EFAULT;
+ }
+ }
+
+ return 0;
+}
+
+static void vb2_dc_put_dirty_page(struct page *page)
+{
+ set_page_dirty_lock(page);
+ put_page(page);
+}
+
+static void vb2_dc_put_userptr(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ struct sg_table *sgt = buf-dma_sgt;
+
+ dma_unmap_sg(buf-dev, sgt-sgl, sgt-orig_nents, buf-dma_dir);
+ if (!vma_is_io(buf-vma))
+ vb2_dc_sgt_foreach_page(sgt, vb2_dc_put_dirty_page);
+
+ sg_free_table(sgt);
+ kfree(sgt);
+ vb2_put_vma(buf-vma);
+ kfree(buf);
+}
+
static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
[PATCHv10 09/26] v4l: vb2: add prepare/finish callbacks to allocators
From: Marek Szyprowski m.szyprow...@samsung.com
This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c | 11 +++
include/media/videobuf2-core.h |7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index a51dad6..613dea1 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -844,6 +844,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
{
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+ unsigned int plane;
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -854,6 +855,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
dprintk(4, Done processing on buffer %d, state: %d\n,
vb-v4l2_buf.index, vb-state);
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, finish, vb-planes[plane].mem_priv);
+
/* Add the buffer to the done buffers list */
spin_lock_irqsave(q-done_lock, flags);
vb-state = state;
@@ -1136,9 +1141,15 @@ err:
static void __enqueue_in_driver(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb-vb2_queue;
+ unsigned int plane;
vb-state = VB2_BUF_STATE_ACTIVE;
atomic_inc(q-queued_count);
+
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, prepare, vb-planes[plane].mem_priv);
+
q-ops-buf_queue(vb);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 689ae4a..24b9c90 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -56,6 +56,10 @@ struct vb2_fileio_data;
* dmabuf
* @unmap_dmabuf: releases access control to the dmabuf - allocator is notified
* that this driver is done using the dmabuf for now
+ * @prepare: called every time the buffer is passed from userspace to the
+ * driver, useful for cache synchronisation, optional
+ * @finish:called every time the buffer is passed back from the driver
+ * to the userspace, also optional
* @vaddr: return a kernel virtual address to a given memory buffer
* associated with the passed private structure or NULL if no
* such mapping exists
@@ -82,6 +86,9 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
+ void(*prepare)(void *buf_priv);
+ void(*finish)(void *buf_priv);
+
void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
unsigned long size, int write);
void(*detach_dmabuf)(void *buf_priv);
--
1.7.9.5
--
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 0/5] v4l-utils: add some scripts from the wiki.
On Wed, 10 Oct 2012 17:22:53 +0300 Antti Palosaari cr...@iki.fi wrote: On 10/10/2012 04:39 PM, Antonio Ospite wrote: Hi, I recently used some scripts I found on the linuxtv.org wiki to extract a firmware for a m920x device from USB dumps made with UsbSniff2.0 on WIndows XP. I thought these scripts may be collected in v4l-utils where it is easier to change them. The first two patches add the scripts as they are now on the wiki, I am sending them on behalf of the original author even if I was not able to contact him, I hope this is OK. I am almost 100% it is not OK to sign those to Kernel behalf of Aapo. Maybe it is possible to keep Aapo as a author, but sign with yourself. I can do that of course, I'll wait some days to see if anyone else has an opinion on that. BTW if anyone here has the new Appo Tahkola's email address I will ask him directly too. Thanks, Antonio P.S. removed Aapo and CityK from CC as I get Delivery error messages on both addresses. -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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
[PATCHv10 10/26] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
From: Marek Szyprowski m.szyprow...@samsung.com
Add prepare/finish callbacks to vb2-dma-contig allocator.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 8486e06..494a824 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -103,6 +103,28 @@ static unsigned int vb2_dc_num_users(void *buf_priv)
return atomic_read(buf-refcount);
}
+static void vb2_dc_prepare(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ struct sg_table *sgt = buf-dma_sgt;
+
+ if (!sgt)
+ return;
+
+ dma_sync_sg_for_device(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
+static void vb2_dc_finish(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ struct sg_table *sgt = buf-dma_sgt;
+
+ if (!sgt)
+ return;
+
+ dma_sync_sg_for_cpu(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
/*/
/*callbacks for MMAP buffers */
/*/
@@ -366,6 +388,8 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
.mmap = vb2_dc_mmap,
.get_userptr= vb2_dc_get_userptr,
.put_userptr= vb2_dc_put_userptr,
+ .prepare= vb2_dc_prepare,
+ .finish = vb2_dc_finish,
.num_users = vb2_dc_num_users,
};
EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
--
1.7.9.5
--
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
[PATCHv10 11/26] v4l: vb2-dma-contig: add support for dma_buf importing
From: Sumit Semwal sumit.sem...@ti.com
This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
[author of the original patch]
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[integration with refactored dma-contig allocator]
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/v4l2-core/Kconfig|1 +
drivers/media/v4l2-core/videobuf2-dma-contig.c | 120 +++-
2 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 2e787cc..e30583b 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -69,6 +69,7 @@ config VIDEOBUF2_DMA_CONTIG
tristate
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+ select DMA_SHARED_BUFFER
config VIDEOBUF2_VMALLOC
tristate
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 494a824..a5804cf 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include linux/dma-buf.h
#include linux/module.h
#include linux/scatterlist.h
#include linux/sched.h
@@ -38,6 +39,9 @@ struct vb2_dc_buf {
/* USERPTR related */
struct vm_area_struct *vma;
+
+ /* DMABUF related */
+ struct dma_buf_attachment *db_attach;
};
/*/
@@ -108,7 +112,8 @@ static void vb2_dc_prepare(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf-dma_sgt;
- if (!sgt)
+ /* DMABUF exporter will flush the cache for us */
+ if (!sgt || buf-db_attach)
return;
dma_sync_sg_for_device(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
@@ -119,7 +124,8 @@ static void vb2_dc_finish(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf-dma_sgt;
- if (!sgt)
+ /* DMABUF exporter will flush the cache for us */
+ if (!sgt || buf-db_attach)
return;
dma_sync_sg_for_cpu(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
@@ -377,6 +383,112 @@ fail_buf:
}
/*/
+/* callbacks for DMABUF buffers*/
+/*/
+
+static int vb2_dc_map_dmabuf(void *mem_priv)
+{
+ struct vb2_dc_buf *buf = mem_priv;
+ struct sg_table *sgt;
+ unsigned long contig_size;
+
+ if (WARN_ON(!buf-db_attach)) {
+ pr_err(trying to pin a non attached buffer\n);
+ return -EINVAL;
+ }
+
+ if (WARN_ON(buf-dma_sgt)) {
+ pr_err(dmabuf buffer is already pinned\n);
+ return 0;
+ }
+
+ /* get the associated scatterlist for this buffer */
+ sgt = dma_buf_map_attachment(buf-db_attach, buf-dma_dir);
+ if (IS_ERR_OR_NULL(sgt)) {
+ pr_err(Error getting dmabuf scatterlist\n);
+ return -EINVAL;
+ }
+
+ /* checking if dmabuf is big enough to store contiguous chunk */
+ contig_size = vb2_dc_get_contiguous_size(sgt);
+ if (contig_size buf-size) {
+ pr_err(contiguous chunk is too small %lu/%lu b\n,
+ contig_size, buf-size);
+ dma_buf_unmap_attachment(buf-db_attach, sgt, buf-dma_dir);
+ return -EFAULT;
+ }
+
+ buf-dma_addr = sg_dma_address(sgt-sgl);
+ buf-dma_sgt = sgt;
+
+ return 0;
+}
+
+static void vb2_dc_unmap_dmabuf(void *mem_priv)
+{
+ struct vb2_dc_buf *buf = mem_priv;
+ struct sg_table *sgt = buf-dma_sgt;
+
+ if (WARN_ON(!buf-db_attach)) {
+ pr_err(trying to unpin a not attached buffer\n);
+ return;
+ }
+
+ if (WARN_ON(!sgt)) {
+ pr_err(dmabuf buffer is already unpinned\n);
+ return;
+ }
+
+ dma_buf_unmap_attachment(buf-db_attach, sgt, buf-dma_dir);
+
+ buf-dma_addr = 0;
+ buf-dma_sgt = NULL;
+}
+
+static void vb2_dc_detach_dmabuf(void *mem_priv)
+{
+ struct vb2_dc_buf *buf = mem_priv;
+
+ /* if vb2 works correctly you should never detach mapped buffer */
+ if (WARN_ON(buf-dma_addr))
+ vb2_dc_unmap_dmabuf(buf);
+
+ /* detach this attachment */
+ dma_buf_detach(buf-db_attach-dmabuf, buf-db_attach);
+ kfree(buf);
+}
+
+static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
+ unsigned long size, int write)
+{
+ struct vb2_dc_conf *conf = alloc_ctx;
+ struct vb2_dc_buf
[PATCHv10 12/26] v4l: vb2-vmalloc: add support for dmabuf importing
This patch adds support for importing DMABUF files for
vmalloc allocator in Videobuf2.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/Kconfig |1 +
drivers/media/v4l2-core/videobuf2-vmalloc.c | 56 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index e30583b..65875c3 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -75,6 +75,7 @@ config VIDEOBUF2_VMALLOC
tristate
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+ select DMA_SHARED_BUFFER
config VIDEOBUF2_DMA_SG
tristate
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 94efa04..a47fd4f 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -30,6 +30,7 @@ struct vb2_vmalloc_buf {
unsigned intn_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
+ struct dma_buf *dbuf;
};
static void vb2_vmalloc_put(void *buf_priv);
@@ -207,11 +208,66 @@ static int vb2_vmalloc_mmap(void *buf_priv, struct
vm_area_struct *vma)
return 0;
}
+/*/
+/* callbacks for DMABUF buffers*/
+/*/
+
+static int vb2_vmalloc_map_dmabuf(void *mem_priv)
+{
+ struct vb2_vmalloc_buf *buf = mem_priv;
+
+ buf-vaddr = dma_buf_vmap(buf-dbuf);
+
+ return buf-vaddr ? 0 : -EFAULT;
+}
+
+static void vb2_vmalloc_unmap_dmabuf(void *mem_priv)
+{
+ struct vb2_vmalloc_buf *buf = mem_priv;
+
+ dma_buf_vunmap(buf-dbuf, buf-vaddr);
+ buf-vaddr = NULL;
+}
+
+static void vb2_vmalloc_detach_dmabuf(void *mem_priv)
+{
+ struct vb2_vmalloc_buf *buf = mem_priv;
+
+ if (buf-vaddr)
+ dma_buf_vunmap(buf-dbuf, buf-vaddr);
+
+ kfree(buf);
+}
+
+static void *vb2_vmalloc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
+ unsigned long size, int write)
+{
+ struct vb2_vmalloc_buf *buf;
+
+ if (dbuf-size size)
+ return ERR_PTR(-EFAULT);
+
+ buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+
+ buf-dbuf = dbuf;
+ buf-write = write;
+ buf-size = size;
+
+ return buf;
+}
+
+
const struct vb2_mem_ops vb2_vmalloc_memops = {
.alloc = vb2_vmalloc_alloc,
.put= vb2_vmalloc_put,
.get_userptr= vb2_vmalloc_get_userptr,
.put_userptr= vb2_vmalloc_put_userptr,
+ .map_dmabuf = vb2_vmalloc_map_dmabuf,
+ .unmap_dmabuf = vb2_vmalloc_unmap_dmabuf,
+ .attach_dmabuf = vb2_vmalloc_attach_dmabuf,
+ .detach_dmabuf = vb2_vmalloc_detach_dmabuf,
.vaddr = vb2_vmalloc_vaddr,
.mmap = vb2_vmalloc_mmap,
.num_users = vb2_vmalloc_num_users,
--
1.7.9.5
--
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
[PATCHv10 13/26] v4l: vivi: support for dmabuf importing
This patch enhances VIVI driver with a support for importing a buffer from DMABUF file descriptors. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/platform/vivi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c index b366b05..9e077bb 100644 --- a/drivers/media/platform/vivi.c +++ b/drivers/media/platform/vivi.c @@ -1308,7 +1308,7 @@ static int __init vivi_create_instance(int inst) /* initialize queue */ q = dev-vb_vidq; q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE; - q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_READ; + q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ; q-drv_priv = dev; q-buf_struct_size = sizeof(struct vivi_buffer); q-ops = vivi_video_qops; -- 1.7.9.5 -- 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
[PATCHv10 15/26] v4l: s5p-fimc: support for dmabuf importing
This patch enhances s5p-fimc with support for DMABUF importing via V4L2_MEMORY_DMABUF memory type. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/platform/s5p-fimc/fimc-capture.c |2 +- drivers/media/platform/s5p-fimc/fimc-m2m.c |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c b/drivers/media/platform/s5p-fimc/fimc-capture.c index 367efd1..246bb32 100644 --- a/drivers/media/platform/s5p-fimc/fimc-capture.c +++ b/drivers/media/platform/s5p-fimc/fimc-capture.c @@ -1730,7 +1730,7 @@ static int fimc_register_capture_device(struct fimc_dev *fimc, q = fimc-vid_cap.vbq; memset(q, 0, sizeof(*q)); q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; - q-io_modes = VB2_MMAP | VB2_USERPTR; + q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; q-drv_priv = fimc-vid_cap.ctx; q-ops = fimc_capture_qops; q-mem_ops = vb2_dma_contig_memops; diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c b/drivers/media/platform/s5p-fimc/fimc-m2m.c index 4500e44..17067a7 100644 --- a/drivers/media/platform/s5p-fimc/fimc-m2m.c +++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c @@ -622,7 +622,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, int ret; src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE; - src_vq-io_modes = VB2_MMAP | VB2_USERPTR; + src_vq-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; src_vq-drv_priv = ctx; src_vq-ops = fimc_qops; src_vq-mem_ops = vb2_dma_contig_memops; @@ -633,7 +633,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, return ret; dst_vq-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; - dst_vq-io_modes = VB2_MMAP | VB2_USERPTR; + dst_vq-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF; dst_vq-drv_priv = ctx; dst_vq-ops = fimc_qops; dst_vq-mem_ops = vb2_dma_contig_memops; -- 1.7.9.5 -- 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 05/14] media: add a V4L2 OF parser
Em Wed, 10 Oct 2012 16:48 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Hi Mauro, On Wednesday 10 October 2012 10:45:22 Mauro Carvalho Chehab wrote: Em Wed, 10 Oct 2012 14:54 +0200 Laurent Pinchart escreveu: Also, ideally OF-compatible (I2C) drivers should run with no platform data, but soc-camera is using I2C device platform data intensively. To avoid modifying the soc-camera core and all drivers, I also trigger on the BUS_NOTIFY_BIND_DRIVER event and assign a reference to the dynamically created platform data to the I2C device. Would we also want to do this for all V4L2 bridge drivers? We could call this a prepare callback or something similar... If that's going to be an interim solution only I'm fine with keeping it in soc-camera. I'm far from being an OF expert, but why do we need to export I2C devices to DT/OF? On my understanding, it is the bridge code that should be responsible for detecting, binding and initializing the proper I2C devices. On several cases, it is impossible or it would cause lots of ugly hacks if we ever try to move away from platform data stuff, as only the bridge driver knows what initialization is needed for an specific I2C driver. In a nutshell, a DT-based platform doesn't have any board code (except in rare cases, but let's not get into that), and thus doesn't pass any platform data structure to drivers. However, drivers receive a DT node, which contains a hierarchical description of the hardware, and parse those to extract information necessary to configure the device. One very important point to keep in mind here is that the DT is not Linux- specific. DT bindings are designed to be portable, and thus must only contain hardware descriptions, without any OS-specific information or policy information. For instance information such as the maximum video buffers size is not allowed in the DT. The DT is used both to provide platform data to drivers and to instantiate devices. I2C device DT nodes are stored as children of the I2C bus master DT node, and are automatically instantiated by the I2C bus master. This is a significant change compared to our current situation where the V4L2 bridge driver receives an array of I2C board information structures and instatiates the devices itself. Most of the DT support work will go in supporting that new instantiation mechanism. The bridge driver doesn't control instantiation of the I2C devices anymore, but need to bind with them at runtime. To make things more complex, it is expected that most I2C drivers to be arch independent, and they should be allowed to be used by a personal computer or by an embedded device. Agreed. That's why platform data structures won't go away anytime soon, a PCI bridge driver for hardware that contain I2C devices will still instantiate the I2C devices itself. We don't plan to or even want to get rid of that mechanism, as there are perfectly valid use cases. However, for DT-based embedded platforms, we need to support a new instantiation mechanism. Let me give 2 such examples: - ir-i2c-kbd driver supports lots of IR devices. Platform_data is needed to specify what hardware will actually be used, and what should be the default Remote Controller keymap; That driver isn't used on embedded platforms so it doesn't need to be changed now. - Sensor drivers like ov2940 is needed by soc_camera and by other webcam drivers like em28xx. The setup for em28xx should be completely different than the one for soc_camera: the initial registers init sequence is different for both. As several registers there aren't properly documented, there's no easy way to parametrize the configuration. Such drivers will need to support both DT-based platform data and structure- based platform data. They will likely parse the DT node and fill a platform data structure, to avoid duplicating initialization code. Please note that the new subdevs instantiation mechanism needed for DT will need to handle any instantiation order, as we can't guarantee the I2C device and bridge device instantiation order with DT. It should thus then support the current instantiation order we use for PCI and USB platforms. So, for me, we should not expose the I2C devices directly on OF; it should, instead, see just the bridge, and let the bridge to map the needed I2C devices using the needed platform_data. We can't do that, there will be no platform data anymore with DT-based platforms. As a summary, platform data structures won't go away, I2C drivers that need to work both on DT-based and non-DT-based platforms will need to support both the DT and platform data structures to get platform data. PCI and USB bridges will still instantiate their I2C devices, and binding between the I2C devices and the bridge can either be handled with two
[PATCHv10 16/26] v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call
From: Marek Szyprowski m.szyprow...@samsung.com
Let mmap method to use dma_mmap_coherent call. Moreover, this patch removes
vb2_mmap_pfn_range from videobuf2 helpers as it was suggested by Laurent
Pinchart. The function is no longer used in vb2 code.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 28 +++--
drivers/media/v4l2-core/videobuf2-memops.c | 40
include/media/videobuf2-memops.h |5 ---
3 files changed, 26 insertions(+), 47 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index a5804cf..0e065ce 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -178,14 +178,38 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
size)
static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
+ int ret;
if (!buf) {
printk(KERN_ERR No buffer to map\n);
return -EINVAL;
}
- return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
- vb2_common_vm_ops, buf-handler);
+ /*
+* dma_mmap_* uses vm_pgoff as in-buffer offset, but we want to
+* map whole buffer
+*/
+ vma-vm_pgoff = 0;
+
+ ret = dma_mmap_coherent(buf-dev, vma, buf-vaddr,
+ buf-dma_addr, buf-size);
+
+ if (ret) {
+ pr_err(Remapping memory failed, error: %d\n, ret);
+ return ret;
+ }
+
+ vma-vm_flags |= VM_DONTEXPAND | VM_RESERVED;
+ vma-vm_private_data= buf-handler;
+ vma-vm_ops = vb2_common_vm_ops;
+
+ vma-vm_ops-open(vma);
+
+ pr_debug(%s: mapped dma addr 0x%08lx at 0x%08lx, size %ld\n,
+ __func__, (unsigned long)buf-dma_addr, vma-vm_start,
+ buf-size);
+
+ return 0;
}
/*/
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 504cd4c..81c1ad8 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -137,46 +137,6 @@ int vb2_get_contig_userptr(unsigned long vaddr, unsigned
long size,
EXPORT_SYMBOL_GPL(vb2_get_contig_userptr);
/**
- * vb2_mmap_pfn_range() - map physical pages to userspace
- * @vma: virtual memory region for the mapping
- * @paddr: starting physical address of the memory to be mapped
- * @size: size of the memory to be mapped
- * @vm_ops:vm operations to be assigned to the created area
- * @priv: private data to be associated with the area
- *
- * Returns 0 on success.
- */
-int vb2_mmap_pfn_range(struct vm_area_struct *vma, unsigned long paddr,
- unsigned long size,
- const struct vm_operations_struct *vm_ops,
- void *priv)
-{
- int ret;
-
- size = min_t(unsigned long, vma-vm_end - vma-vm_start, size);
-
- vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
- ret = remap_pfn_range(vma, vma-vm_start, paddr PAGE_SHIFT,
- size, vma-vm_page_prot);
- if (ret) {
- printk(KERN_ERR Remapping memory failed, error: %d\n, ret);
- return ret;
- }
-
- vma-vm_flags |= VM_DONTEXPAND | VM_RESERVED;
- vma-vm_private_data= priv;
- vma-vm_ops = vm_ops;
-
- vma-vm_ops-open(vma);
-
- pr_debug(%s: mapped paddr 0x%08lx at 0x%08lx, size %ld\n,
- __func__, paddr, vma-vm_start, size);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(vb2_mmap_pfn_range);
-
-/**
* vb2_common_vm_open() - increase refcount of the vma
* @vma: virtual memory region for the mapping
*
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index 84e1f6c..f05444c 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -33,11 +33,6 @@ extern const struct vm_operations_struct vb2_common_vm_ops;
int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
struct vm_area_struct **res_vma, dma_addr_t *res_pa);
-int vb2_mmap_pfn_range(struct vm_area_struct *vma, unsigned long paddr,
- unsigned long size,
- const struct vm_operations_struct *vm_ops,
- void *priv);
-
struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma);
void vb2_put_vma(struct vm_area_struct *vma);
--
1.7.9.5
--
To unsubscribe from
Re: AW: omap3-isp-live does not allocate big enough buffers?
Hi Florian, On Wednesday 10 October 2012 09:19:37 Florian Neuhaus wrote: Laurent Pinchart wrote on 2012-10-08: The OMAP3 ISP resizer can't scale down 1944 pixels (the native sensor height) to exactly 480 pixels as that would exceed the resizer limits. You will thus have to crop the sensor image slightly. Cropping is supported by libomap3isp and by the snapshot application but not by the live application. Ideally the live application or the libomap3isp library should realize that the ISP limits are exceeded and configure cropping on the sensor accordingly. As an interim solution you could add manual crop support to the live application using the snapshot application crop support code as an example. I have seen, that the resizer only supports downscaling by 0.25, so with all the cropping, 1944 lines will come down to 482 which is too big for my framebuffer. If I apply some cropping in the omap3_isp_viewfinder_setup function, the output will work as expected. Now I'm going to crop on the sensor (or better on the first entity that supports cropping, as in your code) if the ratio sensor input - viewfinder output exceeds 0.25. Are you interested in a patch for this? Sure. I wonder if it wouldn't make more sense to crop on the resizer though, what do you think ? -- Regards, Laurent Pinchart -- 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
[PATCHv10 17/26] Documentation: media: description of DMABUF exporting in V4L2
This patch adds description and usage examples for exporting DMABUF file descriptor in V4L2. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: linux-...@vger.kernel.org --- Documentation/DocBook/media/v4l/compat.xml|3 + Documentation/DocBook/media/v4l/io.xml|3 + Documentation/DocBook/media/v4l/v4l2.xml |1 + Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 212 + 4 files changed, 219 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 50eb630..3dd9e78 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2590,6 +2590,9 @@ ioctls./para paraImporting DMABUF file descriptors as a new IO method described in xref linkend=dmabuf /./para /listitem +listitem + paraExporting DMABUF files using VIDIOC-EXPBUF; ioctl./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 0abb5cb..81d0ed4 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -488,6 +488,9 @@ DMA buffer from userspace using a file descriptor previously exported for a different or the same device (known as the importer role), or both. This section describes the DMABUF importer role API in V4L2./para +paraRefer to link linked=vidioc-expbuf DMABUF exporting /link for +details about exporting V4L2 buffers as DMABUF file descriptors./para + paraInput and output devices support the streaming I/O method when the constantV4L2_CAP_STREAMING/constant flag in the structfieldcapabilities/structfield field of v4l2-capability; returned by diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 10ccde9..4d110b1 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -543,6 +543,7 @@ and discussions on the V4L mailing list./revremark sub-enuminput; sub-enumoutput; sub-enumstd; +sub-expbuf; sub-g-audio; sub-g-audioout; sub-g-crop; diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml new file mode 100644 index 000..72dfbd2 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml @@ -0,0 +1,212 @@ +refentry id=vidioc-expbuf + + refmeta +refentrytitleioctl VIDIOC_EXPBUF/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_EXPBUF/refname +refpurposeExport a buffer as a DMABUF file descriptor./refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_exportbuffer *parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_EXPBUF/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +note + titleExperimental/title + paraThis is an link linkend=experimental experimental /link + interface and may change in the future./para +/note + +paraThis ioctl is an extension to the link linkend=mmapmemory +mapping/link I/O method, therefore it is available only for +constantV4L2_MEMORY_MMAP/constant buffers. It can be used to export a +buffer as a DMABUF file at any time after buffers have been allocated with the +VIDIOC-REQBUFS; ioctl./para + +para To export a buffer, applications fill v4l2-exportbuffer;. The +structfield type /structfield field is set to the same buffer type as was +previously used with v4l2-requestbuffers;structfield type /structfield. +Applications must also set the structfield index /structfield field. Valid +index numbers range from zero to the number of buffers allocated with +VIDIOC-REQBUFS; (v4l2-requestbuffers;structfield count /structfield) +minus one. For the multi-planar API, applications set the structfield plane +/structfield field to the index of the plane to be exported. Valid planes +range from zero to the maximal number of valid planes for the currently active +format. For the single-planar API, applications must set
[PATCHv10 18/26] v4l: add buffer exporting via dmabuf
This patch adds extension to V4L2 api. It allow to export a mmap buffer as file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
mmap and return a file descriptor on success.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c |1 +
drivers/media/v4l2-core/v4l2-dev.c|1 +
drivers/media/v4l2-core/v4l2-ioctl.c | 10 +
include/linux/videodev2.h | 28 +
include/media/v4l2-ioctl.h|2 ++
5 files changed, 42 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index cc5998b..7157af3 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -1018,6 +1018,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+ case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index a2df842..98dcad9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -571,6 +571,7 @@ static void determine_valid_ioctls(struct video_device
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
+ SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
SET_VALID_IOCTL(ops, VIDIOC_STREAMON, vidioc_streamon);
SET_VALID_IOCTL(ops, VIDIOC_STREAMOFF, vidioc_streamoff);
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 530a67e..aa6e7c7 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -454,6 +454,15 @@ static void v4l_print_buffer(const void *arg, bool
write_only)
tc-type, tc-flags, tc-frames, *(__u32
*)tc-userbits);
}
+static void v4l_print_exportbuffer(const void *arg, bool write_only)
+{
+ const struct v4l2_exportbuffer *p = arg;
+
+ pr_cont(fd=%d, type=%s, index=%u, plane=%u, flags=0x%08x\n,
+ p-fd, prt_names(p-type, v4l2_type_names),
+ p-index, p-plane, p-flags);
+}
+
static void v4l_print_create_buffers(const void *arg, bool write_only)
{
const struct v4l2_create_buffers *p = arg;
@@ -1961,6 +1970,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_STD(VIDIOC_S_FBUF, vidioc_s_fbuf, v4l_print_framebuffer,
INFO_FL_PRIO),
IOCTL_INFO_FNC(VIDIOC_OVERLAY, v4l_overlay, v4l_print_u32,
INFO_FL_PRIO),
IOCTL_INFO_FNC(VIDIOC_QBUF, v4l_qbuf, v4l_print_buffer, INFO_FL_QUEUE),
+ IOCTL_INFO_STD(VIDIOC_EXPBUF, vidioc_expbuf, v4l_print_exportbuffer,
INFO_FL_QUEUE | INFO_FL_CLEAR(v4l2_exportbuffer, flags)),
IOCTL_INFO_FNC(VIDIOC_DQBUF, v4l_dqbuf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_FNC(VIDIOC_STREAMON, v4l_streamon, v4l_print_buftype,
INFO_FL_PRIO | INFO_FL_QUEUE),
IOCTL_INFO_FNC(VIDIOC_STREAMOFF, v4l_streamoff, v4l_print_buftype,
INFO_FL_PRIO | INFO_FL_QUEUE),
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 07bc5d6..19765df 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -696,6 +696,33 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor
+ *
+ * @index: id number of the buffer
+ * @type: enum v4l2_buf_type; buffer type (type == *_MPLANE for
+ * multiplanar buffers);
+ * @plane: index of the plane to be exported, 0 for single plane queues
+ * @flags: flags for newly created file, currently only O_CLOEXEC is
+ * supported, refer to manual of open syscall for more details
+ * @fd:file descriptor associated with DMABUF (set by driver)
+ *
+ * Contains data used for exporting a video buffer as DMABUF file descriptor.
+ * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
+ * (identical to the cookie used to mmap() the buffer to userspace). All
+ * reserved fields must be set to zero. The field reserved0 is expected to
+ * become a structure 'type' allowing an alternative layout of the structure
+ * content. Therefore this field should not be used for any other extensions.
+ */
+struct v4l2_exportbuffer {
+ __u32 type; /* enum v4l2_buf_type */
+ __u32 index;
+ __u32 plane;
+ __u32 flags;
[PATCHv10 19/26] v4l: vb2: add buffer exporting via dmabuf
This patch adds extension to videobuf2-core. It allow to export a mmap buffer
as a file descriptor.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 13 +
drivers/media/v4l2-core/videobuf2-core.c | 83 ++
include/media/v4l2-mem2mem.h |3 ++
include/media/videobuf2-core.h |4 ++
4 files changed, 103 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 3ac8358..9aa7cc7 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -369,6 +369,19 @@ int v4l2_m2m_dqbuf(struct file *file, struct v4l2_m2m_ctx
*m2m_ctx,
EXPORT_SYMBOL_GPL(v4l2_m2m_dqbuf);
/**
+ * v4l2_m2m_expbuf() - export a source or destination buffer, depending on
+ * the type
+ */
+int v4l2_m2m_expbuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
+ struct v4l2_exportbuffer *eb)
+{
+ struct vb2_queue *vq;
+
+ vq = v4l2_m2m_get_vq(m2m_ctx, eb-type);
+ return vb2_expbuf(vq, eb);
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_expbuf);
+/**
* v4l2_m2m_streamon() - turn on streaming for a video queue
*/
int v4l2_m2m_streamon(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 613dea1..9f81be2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1751,6 +1751,79 @@ static int __find_plane_by_offset(struct vb2_queue *q,
unsigned long off,
}
/**
+ * vb2_expbuf() - Export a buffer as a file descriptor
+ * @q: videobuf2 queue
+ * @eb:export buffer structure passed from userspace to
vidioc_expbuf
+ * handler in driver
+ *
+ * The return values from this function are intended to be directly returned
+ * from vidioc_expbuf handler in driver.
+ */
+int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb)
+{
+ struct vb2_buffer *vb = NULL;
+ struct vb2_plane *vb_plane;
+ int ret;
+ struct dma_buf *dbuf;
+
+ if (q-memory != V4L2_MEMORY_MMAP) {
+ dprintk(1, Queue is not currently set up for mmap\n);
+ return -EINVAL;
+ }
+
+ if (!q-mem_ops-get_dmabuf) {
+ dprintk(1, Queue does not support DMA buffer exporting\n);
+ return -EINVAL;
+ }
+
+ if (eb-flags ~O_CLOEXEC) {
+ dprintk(1, Queue does support only O_CLOEXEC flag\n);
+ return -EINVAL;
+ }
+
+ if (eb-type != q-type) {
+ dprintk(1, qbuf: invalid buffer type\n);
+ return -EINVAL;
+ }
+
+ if (eb-index = q-num_buffers) {
+ dprintk(1, buffer index out of range\n);
+ return -EINVAL;
+ }
+
+ vb = q-bufs[eb-index];
+
+ if (eb-plane = vb-num_planes) {
+ dprintk(1, buffer plane out of range\n);
+ return -EINVAL;
+ }
+
+ vb_plane = vb-planes[eb-plane];
+
+ dbuf = call_memop(q, get_dmabuf, vb_plane-mem_priv);
+ if (IS_ERR_OR_NULL(dbuf)) {
+ dprintk(1, Failed to export buffer %d, plane %d\n,
+ eb-index, eb-plane);
+ return -EINVAL;
+ }
+
+ ret = dma_buf_fd(dbuf, eb-flags);
+ if (ret 0) {
+ dprintk(3, buffer %d, plane %d failed to export (%d)\n,
+ eb-index, eb-plane, ret);
+ dma_buf_put(dbuf);
+ return ret;
+ }
+
+ dprintk(3, buffer %d, plane %d exported as %d descriptor\n,
+ eb-index, eb-plane, ret);
+ eb-fd = ret;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_expbuf);
+
+/**
* vb2_mmap() - map video buffers into application address space
* @q: videobuf2 queue
* @vma: vma passed to the mmap file operation handler in the driver
@@ -2456,6 +2529,16 @@ int vb2_ioctl_streamoff(struct file *file, void *priv,
enum v4l2_buf_type i)
}
EXPORT_SYMBOL_GPL(vb2_ioctl_streamoff);
+int vb2_ioctl_expbuf(struct file *file, void *priv, struct v4l2_exportbuffer
*p)
+{
+ struct video_device *vdev = video_devdata(file);
+
+ if (vb2_queue_is_busy(vdev, file))
+ return -EBUSY;
+ return vb2_expbuf(vdev-queue, p);
+}
+EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf);
+
/* v4l2_file_operations helpers */
int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma)
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 131cc4a..7e82d2b 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -111,6 +111,9 @@ int v4l2_m2m_qbuf(struct file *file, struct v4l2_m2m_ctx
*m2m_ctx,
int
[PATCHv10 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting
This patch adds support for exporting a dma-contig buffer using
DMABUF interface.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 200
1 file changed, 200 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 0e065ce..b138b5c 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -36,6 +36,7 @@ struct vb2_dc_buf {
/* MMAP related */
struct vb2_vmarea_handler handler;
atomic_trefcount;
+ struct sg_table *sgt_base;
/* USERPTR related */
struct vm_area_struct *vma;
@@ -142,6 +143,10 @@ static void vb2_dc_put(void *buf_priv)
if (!atomic_dec_and_test(buf-refcount))
return;
+ if (buf-sgt_base) {
+ sg_free_table(buf-sgt_base);
+ kfree(buf-sgt_base);
+ }
dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
kfree(buf);
}
@@ -213,6 +218,200 @@ static int vb2_dc_mmap(void *buf_priv, struct
vm_area_struct *vma)
}
/*/
+/* DMABUF ops for exporters */
+/*/
+
+struct vb2_dc_attachment {
+ struct sg_table sgt;
+ enum dma_data_direction dir;
+};
+
+static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device *dev,
+ struct dma_buf_attachment *dbuf_attach)
+{
+ struct vb2_dc_attachment *attach;
+ unsigned int i;
+ struct scatterlist *rd, *wr;
+ struct sg_table *sgt;
+ struct vb2_dc_buf *buf = dbuf-priv;
+ int ret;
+
+ attach = kzalloc(sizeof(*attach), GFP_KERNEL);
+ if (!attach)
+ return -ENOMEM;
+
+ sgt = attach-sgt;
+ /* Copy the buf-base_sgt scatter list to the attachment, as we can't
+* map the same scatter list to multiple attachments at the same time.
+*/
+ ret = sg_alloc_table(sgt, buf-sgt_base-orig_nents, GFP_KERNEL);
+ if (ret) {
+ kfree(attach);
+ return -ENOMEM;
+ }
+
+ rd = buf-sgt_base-sgl;
+ wr = sgt-sgl;
+ for (i = 0; i sgt-orig_nents; ++i) {
+ sg_set_page(wr, sg_page(rd), rd-length, rd-offset);
+ rd = sg_next(rd);
+ wr = sg_next(wr);
+ }
+
+ attach-dir = DMA_NONE;
+ dbuf_attach-priv = attach;
+
+ return 0;
+}
+
+static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
+ struct dma_buf_attachment *db_attach)
+{
+ struct vb2_dc_attachment *attach = db_attach-priv;
+ struct sg_table *sgt;
+
+ if (!attach)
+ return;
+
+ sgt = attach-sgt;
+
+ /* release the scatterlist cache */
+ if (attach-dir != DMA_NONE)
+ dma_unmap_sg(db_attach-dev, sgt-sgl, sgt-orig_nents,
+ attach-dir);
+ sg_free_table(sgt);
+ kfree(attach);
+ db_attach-priv = NULL;
+}
+
+static struct sg_table *vb2_dc_dmabuf_ops_map(
+ struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
+{
+ struct vb2_dc_attachment *attach = db_attach-priv;
+ /* stealing dmabuf mutex to serialize map/unmap operations */
+ struct mutex *lock = db_attach-dmabuf-lock;
+ struct sg_table *sgt;
+ int ret;
+
+ mutex_lock(lock);
+
+ sgt = attach-sgt;
+ /* return previously mapped sg table */
+ if (attach-dir == dir) {
+ mutex_unlock(lock);
+ return sgt;
+ }
+
+ /* release any previous cache */
+ if (attach-dir != DMA_NONE) {
+ dma_unmap_sg(db_attach-dev, sgt-sgl, sgt-orig_nents,
+ attach-dir);
+ attach-dir = DMA_NONE;
+ }
+
+ /* mapping to the client with new direction */
+ ret = dma_map_sg(db_attach-dev, sgt-sgl, sgt-orig_nents, dir);
+ if (ret = 0) {
+ pr_err(failed to map scatterlist\n);
+ mutex_unlock(lock);
+ return ERR_PTR(-EIO);
+ }
+
+ attach-dir = dir;
+
+ mutex_unlock(lock);
+
+ return sgt;
+}
+
+static void vb2_dc_dmabuf_ops_unmap(struct dma_buf_attachment *db_attach,
+ struct sg_table *sgt, enum dma_data_direction dir)
+{
+ /* nothing to be done here */
+}
+
+static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
+{
+ /* drop reference obtained in vb2_dc_get_dmabuf */
+ vb2_dc_put(dbuf-priv);
+}
+
+static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
+{
+ struct vb2_dc_buf *buf = dbuf-priv;
+
+ return buf-vaddr + pgnum * PAGE_SIZE;
+}
+
+static void
[PATCHv10 21/26] v4l: vb2-dma-contig: add reference counting for a device from allocator context
This patch adds taking reference to the device for MMAP buffers. Such buffers, may be exported using DMABUF mechanism. If the driver that created a queue is unloaded then the queue is released, the device might be released too. However, buffers cannot be released if they are referenced by DMABUF descriptor(s). The device pointer kept in a buffer must be valid for the whole buffer's lifetime. Therefore MMAP buffers should take a reference to the device to avoid risk of dangling pointers. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf2-dma-contig.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index b138b5c..2d661fd 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -148,6 +148,7 @@ static void vb2_dc_put(void *buf_priv) kfree(buf-sgt_base); } dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr); + put_device(buf-dev); kfree(buf); } @@ -168,6 +169,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size) return ERR_PTR(-ENOMEM); } + /* prevent the device from release while the buffer is exported */ + get_device(dev); + buf-dev = dev; buf-size = size; -- 1.7.9.5 -- 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
[PATCHv10 22/26] v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned
From: Marek Szyprowski m.szyprow...@samsung.com
The DMA transfer must be aligned to a specific value. If userptr is not aligned
to DMA requirements then unexpected corruptions of the memory may occur before
or after a buffer. To prevent such situations, all unligned userptr buffers
are rejected at VIDIOC_QBUF.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 2d661fd..571a919 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -493,6 +493,18 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned
long vaddr,
struct vm_area_struct *vma;
struct sg_table *sgt;
unsigned long contig_size;
+ unsigned long dma_align = dma_get_cache_alignment();
+
+ /* Only cache aligned DMA transfers are reliable */
+ if (!IS_ALIGNED(vaddr | size, dma_align)) {
+ pr_debug(user data must be aligned to %lu bytes\n, dma_align);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (!size) {
+ pr_debug(size is zero\n);
+ return ERR_PTR(-EINVAL);
+ }
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
--
1.7.9.5
--
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
[PATCHv10 23/26] v4l: vb2-dma-contig: align buffer size to PAGE_SIZE
Most operations on DMA and DMABUF framework need page
aligned buffers. This fix guarantees this requirement
for vb2-dma-contig buffers.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 571a919..002ee50 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -162,6 +162,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
size)
if (!buf)
return ERR_PTR(-ENOMEM);
+ /* align image size to PAGE_SIZE */
+ size = PAGE_ALIGN(size);
+
buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
if (!buf-vaddr) {
dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
--
1.7.9.5
--
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
[PATCHv10 24/26] v4l: s5p-fimc: support for dmabuf exporting
This patch enhances s5p-fimc with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/s5p-fimc/fimc-capture.c |9 +
drivers/media/platform/s5p-fimc/fimc-m2m.c | 10 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 246bb32..e5fd159 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1231,6 +1231,14 @@ static int fimc_cap_qbuf(struct file *file, void *priv,
return vb2_qbuf(fimc-vid_cap.vbq, buf);
}
+static int fimc_cap_expbuf(struct file *file, void *priv,
+ struct v4l2_exportbuffer *eb)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+
+ return vb2_expbuf(fimc-vid_cap.vbq, eb);
+}
+
static int fimc_cap_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
{
@@ -1355,6 +1363,7 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_qbuf= fimc_cap_qbuf,
.vidioc_dqbuf = fimc_cap_dqbuf,
+ .vidioc_expbuf = fimc_cap_expbuf,
.vidioc_prepare_buf = fimc_cap_prepare_buf,
.vidioc_create_bufs = fimc_cap_create_bufs,
diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c
b/drivers/media/platform/s5p-fimc/fimc-m2m.c
index 17067a7..1cd4fcf 100644
--- a/drivers/media/platform/s5p-fimc/fimc-m2m.c
+++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c
@@ -439,6 +439,15 @@ static int fimc_m2m_dqbuf(struct file *file, void *fh,
return v4l2_m2m_dqbuf(file, ctx-m2m_ctx, buf);
}
+static int fimc_m2m_expbuf(struct file *file, void *fh,
+ struct v4l2_exportbuffer *eb)
+{
+ struct fimc_ctx *ctx = fh_to_ctx(fh);
+
+ return v4l2_m2m_expbuf(file, ctx-m2m_ctx, eb);
+}
+
+
static int fimc_m2m_streamon(struct file *file, void *fh,
enum v4l2_buf_type type)
{
@@ -607,6 +616,7 @@ static const struct v4l2_ioctl_ops fimc_m2m_ioctl_ops = {
.vidioc_querybuf= fimc_m2m_querybuf,
.vidioc_qbuf= fimc_m2m_qbuf,
.vidioc_dqbuf = fimc_m2m_dqbuf,
+ .vidioc_expbuf = fimc_m2m_expbuf,
.vidioc_streamon= fimc_m2m_streamon,
.vidioc_streamoff = fimc_m2m_streamoff,
.vidioc_g_crop = fimc_m2m_g_crop,
--
1.7.9.5
--
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
[PATCHv10 25/26] v4l: s5p-tv: mixer: support for dmabuf exporting
This patch enhances s5p-tv with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/s5p-tv/mixer_video.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/platform/s5p-tv/mixer_video.c
b/drivers/media/platform/s5p-tv/mixer_video.c
index 2421e527..5e3cdb2 100644
--- a/drivers/media/platform/s5p-tv/mixer_video.c
+++ b/drivers/media/platform/s5p-tv/mixer_video.c
@@ -698,6 +698,15 @@ static int mxr_dqbuf(struct file *file, void *priv, struct
v4l2_buffer *p)
return vb2_dqbuf(layer-vb_queue, p, file-f_flags O_NONBLOCK);
}
+static int mxr_expbuf(struct file *file, void *priv,
+ struct v4l2_exportbuffer *eb)
+{
+ struct mxr_layer *layer = video_drvdata(file);
+
+ mxr_dbg(layer-mdev, %s:%d\n, __func__, __LINE__);
+ return vb2_expbuf(layer-vb_queue, eb);
+}
+
static int mxr_streamon(struct file *file, void *priv, enum v4l2_buf_type i)
{
struct mxr_layer *layer = video_drvdata(file);
@@ -725,6 +734,7 @@ static const struct v4l2_ioctl_ops mxr_ioctl_ops = {
.vidioc_querybuf = mxr_querybuf,
.vidioc_qbuf = mxr_qbuf,
.vidioc_dqbuf = mxr_dqbuf,
+ .vidioc_expbuf = mxr_expbuf,
/* Streaming control */
.vidioc_streamon = mxr_streamon,
.vidioc_streamoff = mxr_streamoff,
--
1.7.9.5
--
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
[PATCHv10 26/26] v4l: s5p-mfc: support for dmabuf exporting
This patch enhances s5p-mfc with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Kamil Debski k.deb...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 14 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index eb6a70b..6dad9a7 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -636,6 +636,19 @@ static int vidioc_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
return -EINVAL;
}
+/* Export DMA buffer */
+static int vidioc_expbuf(struct file *file, void *priv,
+ struct v4l2_exportbuffer *eb)
+{
+ struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
+
+ if (eb-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+ return vb2_expbuf(ctx-vq_src, eb);
+ if (eb-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+ return vb2_expbuf(ctx-vq_dst, eb);
+ return -EINVAL;
+}
+
/* Stream on */
static int vidioc_streamon(struct file *file, void *priv,
enum v4l2_buf_type type)
@@ -813,6 +826,7 @@ static const struct v4l2_ioctl_ops s5p_mfc_dec_ioctl_ops = {
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+ .vidioc_expbuf = vidioc_expbuf,
.vidioc_streamon = vidioc_streamon,
.vidioc_streamoff = vidioc_streamoff,
.vidioc_g_crop = vidioc_g_crop,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 2af6d52..22bf684 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1165,6 +1165,19 @@ static int vidioc_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
return ret;
}
+/* Export DMA buffer */
+static int vidioc_expbuf(struct file *file, void *priv,
+ struct v4l2_exportbuffer *eb)
+{
+ struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
+
+ if (eb-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+ return vb2_expbuf(ctx-vq_src, eb);
+ if (eb-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+ return vb2_expbuf(ctx-vq_dst, eb);
+ return -EINVAL;
+}
+
/* Stream on */
static int vidioc_streamon(struct file *file, void *priv,
enum v4l2_buf_type type)
@@ -1568,6 +1581,7 @@ static const struct v4l2_ioctl_ops s5p_mfc_enc_ioctl_ops
= {
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+ .vidioc_expbuf = vidioc_expbuf,
.vidioc_streamon = vidioc_streamon,
.vidioc_streamoff = vidioc_streamoff,
.vidioc_s_parm = vidioc_s_parm,
--
1.7.9.5
--
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 05/14] media: add a V4L2 OF parser
Hi Mauro, On Wednesday 10 October 2012 11:57:03 Mauro Carvalho Chehab wrote: Em Wed, 10 Oct 2012 16:48 +0200 Laurent Pinchart escreveu: On Wednesday 10 October 2012 10:45:22 Mauro Carvalho Chehab wrote: Em Wed, 10 Oct 2012 14:54 +0200 Laurent Pinchart escreveu: Also, ideally OF-compatible (I2C) drivers should run with no platform data, but soc-camera is using I2C device platform data intensively. To avoid modifying the soc-camera core and all drivers, I also trigger on the BUS_NOTIFY_BIND_DRIVER event and assign a reference to the dynamically created platform data to the I2C device. Would we also want to do this for all V4L2 bridge drivers? We could call this a prepare callback or something similar... If that's going to be an interim solution only I'm fine with keeping it in soc-camera. I'm far from being an OF expert, but why do we need to export I2C devices to DT/OF? On my understanding, it is the bridge code that should be responsible for detecting, binding and initializing the proper I2C devices. On several cases, it is impossible or it would cause lots of ugly hacks if we ever try to move away from platform data stuff, as only the bridge driver knows what initialization is needed for an specific I2C driver. In a nutshell, a DT-based platform doesn't have any board code (except in rare cases, but let's not get into that), and thus doesn't pass any platform data structure to drivers. However, drivers receive a DT node, which contains a hierarchical description of the hardware, and parse those to extract information necessary to configure the device. One very important point to keep in mind here is that the DT is not Linux- specific. DT bindings are designed to be portable, and thus must only contain hardware descriptions, without any OS-specific information or policy information. For instance information such as the maximum video buffers size is not allowed in the DT. The DT is used both to provide platform data to drivers and to instantiate devices. I2C device DT nodes are stored as children of the I2C bus master DT node, and are automatically instantiated by the I2C bus master. This is a significant change compared to our current situation where the V4L2 bridge driver receives an array of I2C board information structures and instatiates the devices itself. Most of the DT support work will go in supporting that new instantiation mechanism. The bridge driver doesn't control instantiation of the I2C devices anymore, but need to bind with them at runtime. To make things more complex, it is expected that most I2C drivers to be arch independent, and they should be allowed to be used by a personal computer or by an embedded device. Agreed. That's why platform data structures won't go away anytime soon, a PCI bridge driver for hardware that contain I2C devices will still instantiate the I2C devices itself. We don't plan to or even want to get rid of that mechanism, as there are perfectly valid use cases. However, for DT-based embedded platforms, we need to support a new instantiation mechanism. Let me give 2 such examples: - ir-i2c-kbd driver supports lots of IR devices. Platform_data is needed to specify what hardware will actually be used, and what should be the default Remote Controller keymap; That driver isn't used on embedded platforms so it doesn't need to be changed now. - Sensor drivers like ov2940 is needed by soc_camera and by other webcam drivers like em28xx. The setup for em28xx should be completely different than the one for soc_camera: the initial registers init sequence is different for both. As several registers there aren't properly documented, there's no easy way to parametrize the configuration. Such drivers will need to support both DT-based platform data and structure- based platform data. They will likely parse the DT node and fill a platform data structure, to avoid duplicating initialization code. Please note that the new subdevs instantiation mechanism needed for DT will need to handle any instantiation order, as we can't guarantee the I2C device and bridge device instantiation order with DT. It should thus then support the current instantiation order we use for PCI and USB platforms. So, for me, we should not expose the I2C devices directly on OF; it should, instead, see just the bridge, and let the bridge to map the needed I2C devices using the needed platform_data. We can't do that, there will be no platform data anymore with DT-based platforms. As a summary, platform data structures won't go away, I2C drivers that need to work both on DT-based and non-DT-based platforms will need to support both the DT and platform data structures to get platform data. PCI and USB bridges will still instantiate their I2C devices, and
Re: [PATCH] qv4l2: avoid empty titles for the video control tabs
Am 09.10.2012 17:24, schrieb Hans Verkuil: On Tue October 9 2012 16:46:04 Frank Schäfer wrote: The video control class names are used as titles for the GUI-tabs. The current code relies on the driver enumerating the control classes properly when using V4L2_CTRL_FLAG_NEXT_CTRL. But the UVC-driver (and likely others, too) don't do that, so we can end up with an empty class name string. Make sure we always have a control class title: If the driver didn't enumrate a class along with the controls, call VIDIOC_QUERYCTRL for the class explicitly. If that fails, fall back to an internal string list. NACK. qv4l2 is for testing drivers, so I *want* to see if a driver doesn't provide the control class name. They really should provide it, and it is not something that should be papered over. Hehe, ok. Then you might want to remove all the papering-over code a few lines above, too ? ;) Regards, Frank Regards, Hans -- 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
Test application for DMABUF support in V4L2
Hello everyone,
This mail contains an application to test DMABUF support
in V4L2 for VIVI and S5P-FIMC drivers. The application was
tested on linux-media for 3.7 with applied patchset
[PATCHv10 */26] Integration of videobuf2 with DMABUF
on Universal C210 board.
Compilation:
1. Fetch media-next, apply patchset [PATCHv10 */26] Integration of videobuf2
with DMABUF
2. Execute 'make headers_install' in kernel source
3. arm-linux-gnueabi-gcc v4l-dbuf.c -o v4l-dbuf -O2 -std=gnu99 -I
kernel/usr/include/
This app creates a simple pipeline between VIVI and two FIMC instances.
The scenario goes as follows:
1. FIMC0 creates an MMAP buffer at its OUTPUT queue. (testing vb2_dc_alloc)
2. The buffer from 1. is exported using VIDIOC_EXPBUF. (testing exporting in
vb2-dma-config)
3. The DMABUF from 2. is imported to VIVI at CAPTURE queue. (testing importing
in vb2-vmalloc)
4. Single frame is grabbed from VIVI into the DMABUF. (testing
vb2_dc_dmabuf_ops_vmap)
5. FIMC1 creates an MMAP buffer at its OUTPUT queue. (testing vb2_dc_alloc)
6. he buffer from 5. is exported using VIDIOC_EXPBUF. (testing exporting in
vb2-dma-config)
7. The DMABUF from 6. is imported by FIMC0 at CAPTURE queue. (testing importing
in vb2-dma-contig)
8. FIMC0 is used to process a frame (format conversion/scaling/rotation).
9. USERPTR is created from an anonymous or file mapping.
10. The USERPTR from 9. is passed to FIMC1 at CAPTURE queue. (testing
vb2_dc_get_userptr)
11. FIMC1 is used to process a frame (format conversion/scaling/rotation).
In the result, the USERPTR contains a frame from VIVI processed by
two FIMCs. The app should produce 'Test passed' text on finish.
The command line options allow to control the stages of the process
-v pathpath to vivi [default /dev/video0]
-f pathpath to fimc0 [default /dev/video1]
-F pathpath to fimc1 [default /dev/video3]
-0 4cc@WxH format between VIVI and FIMC0
-1 4cc@WxH format between FIMC0 and FIMC1
-2 4cc@WxH format between FIMC1 and destination
-V vertical flip on FIMC0
-H horizontal flip on FIMC0
-R angle rotation by angle [default 0] on FIMC0
-m size[@file[+offset]] destination mapping,
size 0 is adjusted automatically,
no file indicate anonymous mapping
-h print this help
For example:
v4l-dbuf -0 RGBP@320x200 -H -R 90 -1 RGB4@96x96 -2 YUYV@32x32 -m 0@/dev/fb0
does:
- grab frame from VIVI 320x200 in RGBP (RGB565) format
- convert this frame to 96x96 RGB4 (RGB32) format using FIMC0,
apply horizontal flip and 90 degree rotation
- convert result frame to 32x32 YUYV format using FIMC1
- store result in a framebuffer at /dev/fb0
Please, notice if destination file is missing, then anonymous mapping
is used. On platforms that support no SYSMMU for FIMC it is very likely
that VIDIOC_QBUF will fail if the size of the result image is larger
than a single page.
Please use -v, -f, -F options to setup proper paths to VIVI, FIMC0-M2M,
and FIMC1-M2M nodes.
At each stage the result frames are dumped in PPM format (Netpbm format).
Currently, dumping is supported only for RGB565, RGB32 and YUYV formats.
The app is not aborted if a format is not supported.
Please let us know if you have any further questions.
Regards,
Tomasz Stanislawski
/*
* V4L2 VIVI + FIMC + DMABUF sharing Test Application
*
* This application is used to test DMABUF sharing between VIVI and FIMC
* device.
*
* Authors:
* Tomasz Stanislawski t.stanisl...@samsung.com
*
* Date:
* 08.10.2012
*
*/
#include errno.h
#include fcntl.h
#include limits.h
#include signal.h
#include stdarg.h
#include stdbool.h
#include stdint.h
#include stdio.h
#include stdlib.h
#include string.h
#include sys/ioctl.h
#include sys/mman.h
#include sys/stat.h
#include sys/time.h
#include sys/types.h
#include sys/wait.h
#include time.h
#include unistd.h
#include linux/videodev2.h
#define ARRAY_SIZE(tab) \
(sizeof(tab) / sizeof(*tab))
#define CLEAR(s) memset(s, 0, sizeof(s))
#define MIN(x,y) ((x) (y) ? (x) : (y))
#define MAX(x,y) ((x) (y) ? (x) : (y))
#define CLAMP(x,l,h) ((x) (l) ? (l) : ((x) (h) ? (h) : (x)))
static inline int __info(const char *prefix, const char *file, int line,
const char *fmt, ...)
{
int errsv = errno;
va_list va;
va_start(va, fmt);
fprintf(stderr, %s(%s:%d): , prefix, file, line);
vfprintf(stderr, fmt, va);
va_end(va);
errno = errsv;
return 1;
}
#define ERRSTR strerror(errno)
#define LOG(...) fprintf(stderr, __VA_ARGS__)
#define ERR(...) __info(Error, __FILE__, __LINE__, __VA_ARGS__)
#define ERR_ON(cond, ...) ((cond) ? ERR(__VA_ARGS__) : 0)
#define CRIT(...) \
do { \
__info(Critical, __FILE__, __LINE__, __VA_ARGS__); \
exit(EXIT_FAILURE); \
} while(0)
#define CRIT_ON(cond, ...) do { if (cond) CRIT(__VA_ARGS__); } while(0)
struct format {
unsigned long fourcc;
unsigned long width;
unsigned long height;
[RFC] Samsung SoC camera DT bindings
Hi All,
The following is a brief description of Samsung SoC architecture from the
camera point of view and a corresponding device tree structure. It is based
on the media devices DT bindings design from Guennadi [1]. I incorporated
some changes proposed during reviews (e.g. s/link/endpoint). It seems the
common media bindings are more or less settled now and the discussions are
mostly about implementation of the common parsers and core code.
This RFC is just about an example of the media bindings for fairly complex
SoC architecture. I would be happy to get any feedback on that, while I'm
about to start adding support for this at the driver.
In Samsung SoCs there are multiple capture interfaces that can be attached
to each physical camera port, either parallel video bus or serial MIPI CSI-2.
c02+-+
c01 | | | | |
--o-+ CAM_IF.0 |-- memory
+-+ ++ | | | | |
| sensor A (MIPI CSI2)| | CSI-RX | | | | +-+
+-+-++--|---o- |
| | o- from ISP
+--+ | | |
| sensor B (parallel) | | | |
+--+-o- | |
| | | +-+
c11 | | c12 | |
--o-+ CAM_IF.1 |-- memory
| | | | |
| | | +-+
. . .
| | | +-+
c21 | |c22| | | to ISP
--o-+ CAM_IF_L.0 |-- (SoC
| | | | | internal
+-+ data bus)
As in the above figure, each external sensor can be connected to any of the
CAM_IFs at run-time. It's also possible to connect two CAM_IFs to a single
sensor in parallel. CSI-RX devices and parallel video bus port are connected
to CAM_IF.N devices internally through some sort of crossbar interconnect.
On some SoCs there is also an ISP, which can use one of the two limited
capture interfaces (CAM_IF_L.0) as front-ends and return video data to
a CAM_IF.N that acts as a DMA engine. Following configurations are possible:
sensor A - mipi-csi2 slave (CSI-RX) - CAM_IF.? - memory
sensor B - CAM_IF.? - memory
sensor A - mipi-csi2 slave (CSI-RX) - CAM_IF_LITE.? - memory
sensor B - CAM_IF_LITE.? - memory
sensor B - CAM_IF_LITE.? - ISP - CAM_IF.? - memory
sensor A - mipi-csi2 slave (CSI-RX) - CAM_IF_LITE.? - ISP - CAM_IF.?
- memory
Describing all these possible links by our port/endpoint convention would
result in unnecessarily complex structure. These SoC's internal data routing
could well be coded in the driver, depending on the available hardware
entities and based only on the compatible property.
On the other hand it would be useful to specify certain initial active link
configurations, so the device is in known and valid state after the driver
has initialized. I chose to specify only those default internal SoC links
in DT, leaving sorting out all possible routes for the driver.
The below device tree structure contains two camera sensors controlled over
an I2C bus, where m5mols is connected to the SoC through MIPI CSI-2 bus
and s5k5bafx is on a parallel video bus. There are following default links
specified there:
1) m5mols - csis0 - fimc0,
2) s5k4bafx - fimc1.
Any comments and suggestions are welcome.
/*===*/
/* Aliases for assigning platform entity indexes at the drivers */
aliases {
csis0 = csis_0;
csis1 = csis_1;
fimc0 = fimc_0;
fimc1 = fimc_1;
fimc2 = fimc_2;
fimc3 = fimc_3;
fimc_lite0 = fimc_lite_0;
fimc_lite1 = fimc_lite_1;
};
i2c0: i2c@0xfff2 {
...
/* Parallel bus IF sensor */
s5k5bafx: sensor@0x21 {
compatible = samsung,s5k5bafx;
reg = 0x21;
vddio-supply = regulator1;
vddcore-supply = regulator2;
clock-frequency = 2000;
clocks = mclk0;
clock-names = mclk;
port {
s5k5bafx_1: endpoint {
remote-endpoint = cam_a_endpoint;
bus-width = 8;
hsync-active = 0;
hsync-active = 1;
pclk-sample = 1;
};
};
};
/* MIPI CSI-2 bus IF sensor */
m5mols:
[PATCH] dma-buf: Use EXPORT_SYMBOL
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. Signed-off-by: Robert Morell rmor...@nvidia.com --- This patch is based on Linus's master branch. We held a discussion at ELC, and agreed that EXPORT_SYMBOL is more appropriate for this interface than EXPORT_SYMBOL_GPL. drivers/base/dma-buf.c | 34 +- 1 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 460e22d..24c28be 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -122,7 +122,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -148,7 +148,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) return fd; } -EXPORT_SYMBOL_GPL(dma_buf_fd); +EXPORT_SYMBOL(dma_buf_fd); /** * dma_buf_get - returns the dma_buf structure related to an fd @@ -174,7 +174,7 @@ struct dma_buf *dma_buf_get(int fd) return file-private_data; } -EXPORT_SYMBOL_GPL(dma_buf_get); +EXPORT_SYMBOL(dma_buf_get); /** * dma_buf_put - decreases refcount of the buffer @@ -189,7 +189,7 @@ void dma_buf_put(struct dma_buf *dmabuf) fput(dmabuf-file); } -EXPORT_SYMBOL_GPL(dma_buf_put); +EXPORT_SYMBOL(dma_buf_put); /** * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, @@ -234,7 +234,7 @@ err_attach: mutex_unlock(dmabuf-lock); return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(dma_buf_attach); +EXPORT_SYMBOL(dma_buf_attach); /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list; @@ -256,7 +256,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) mutex_unlock(dmabuf-lock); kfree(attach); } -EXPORT_SYMBOL_GPL(dma_buf_detach); +EXPORT_SYMBOL(dma_buf_detach); /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; @@ -283,7 +283,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return sg_table; } -EXPORT_SYMBOL_GPL(dma_buf_map_attachment); +EXPORT_SYMBOL(dma_buf_map_attachment); /** * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might @@ -304,7 +304,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, attach-dmabuf-ops-unmap_dma_buf(attach, sg_table, direction); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); /** @@ -332,7 +332,7 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, return ret; } -EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); +EXPORT_SYMBOL(dma_buf_begin_cpu_access); /** * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the @@ -354,7 +354,7 @@ void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, if (dmabuf-ops-end_cpu_access) dmabuf-ops-end_cpu_access(dmabuf, start, len, direction); } -EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); +EXPORT_SYMBOL(dma_buf_end_cpu_access); /** * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address @@ -371,7 +371,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf-ops-kmap_atomic(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); +EXPORT_SYMBOL(dma_buf_kmap_atomic); /** * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic. @@ -389,7 +389,7 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf-ops-kunmap_atomic) dmabuf-ops-kunmap_atomic(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); +EXPORT_SYMBOL(dma_buf_kunmap_atomic); /** * dma_buf_kmap - Map a page of the buffer object into kernel address space. The @@ -406,7 +406,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf-ops-kmap(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap); +EXPORT_SYMBOL(dma_buf_kmap); /** * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap. @@ -424,7 +424,7 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf-ops-kunmap) dmabuf-ops-kunmap(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap); +EXPORT_SYMBOL(dma_buf_kunmap); /** @@ -466,7 +466,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, return dmabuf-ops-mmap(dmabuf, vma); } -EXPORT_SYMBOL_GPL(dma_buf_mmap); +EXPORT_SYMBOL(dma_buf_mmap); /** * dma_buf_vmap - Create virtual mapping for the buffer object into kernel @@ -487,7 +487,7
Re: udev breakages -
On Wed, Oct 10, 2012 at 5:19 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Oct 4, 2012 at 9:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
I don't know how to handle the /dev/ptmx issue properly from within
devtmpfs, does anyone? Proposals are always welcome, the last time this
came up a week or so ago, I don't recall seeing any proposals, just a
general complaint.
Is it really a problem - devtmpfs is optional. It's a problem for the
userspace folks to handle and if they made it mandatory in their code
diddums, someone better go fork working versions.
If only there was a viable alternative to udev.
Distributions are being pushed around by the udev+systemd project
precisely because of this reason; udev maintainers have said that udev
on non-systemd systems is a dead end, so everyone that uses udev
(everyone) is being forced to switch to systemd if they want to
receive proper support, and at some point there might not be even a
choice.
I for one would like an alternative to both systemd and udev on my
Linux systems, and as of yet, I don't know of one.
A few years ago, the OpenWRT people pointed me to hotplug2 when I mentioned
udev made my poor m68k box with 12 MiB of RAM immediately go OOM.
Don't know if it's suitable for bigger machines, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] dma-buf: Use EXPORT_SYMBOL
Em Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com escreveu: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. Signed-off-by: Robert Morell rmor...@nvidia.com NAK, as already explained at: http://lists.freedesktop.org/archives/dri-devel/2012-January/018281.html 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: [PATCH 4/14] drivers/media/v4l2-core/videobuf2-core.c: fix error return code
On Sat, Oct 6, 2012 at 1:17 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
Em Thu, 6 Sep 2012 17:23:57 +0200
Peter Senna Tschudin peter.se...@gmail.com escreveu:
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
drivers/media/v4l2-core/videobuf2-core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 4da3df6..f6bc240 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1876,8 +1876,10 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
for (i = 0; i q-num_buffers; i++) {
fileio-bufs[i].vaddr = vb2_plane_vaddr(q-bufs[i], 0);
- if (fileio-bufs[i].vaddr == NULL)
+ if (fileio-bufs[i].vaddr == NULL) {
+ ret = -EFAULT;
goto err_reqbufs;
+ }
Had you test this patch? I suspect it breaks the driver, as there are
failures under
streaming handling that are acceptable, as it may indicate that userspace was
not
able to handle all queued frames in time. On such cases, what the Kernel does
is to
just discard the frame. Userspace is able to detect it, by looking inside the
timestamp
added on each frame.
No, I have not tested it. This was the only place the function was
returning non negative value for error path, so looked as a bug to me.
May I add a comment about returning non-negative value is intended
there?
fileio-bufs[i].size = vb2_plane_size(q-bufs[i], 0);
}
--
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
Cheers,
Mauro
--
Peter
--
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 05/14] media: add a V4L2 OF parser
On 10/10/2012 07:18 AM, Laurent Pinchart wrote: On Monday 08 October 2012 17:15:53 Guennadi Liakhovetski wrote: ... But how do you get the subdev pointer? With the notifier I get it from i2c_get_clientdata(client) and what do you do without it? How do you get to the client? And can't it get that from DT as well? No, I don't think there is a way to get a device pointer from a DT node. I don't believe there's a generic API for this (although perhaps there could be), but it can be implemented quite easily. For example, on Tegra, the SMMU needs to flip a bit in the AHB register space in order to enable itself. The SMMU DT node contains a phandle that points at the AHB DT node. The SMMU driver parses the phandle and passes the DT node pointer to the AHB driver. The AHB driver looks up the struct device that was instantiated for that node. See drivers/amba/tegra-ahb.c:tegra_ahb_enable_smmu(). There are a few other cases of similar code in the kernel, although I can't remember the others! -- 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 4/14] drivers/media/v4l2-core/videobuf2-core.c: fix error return code
Hi Peter,
On 10/10/2012 06:47 PM, Peter Senna Tschudin wrote:
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 4da3df6..f6bc240 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1876,8 +1876,10 @@ static int __vb2_init_fileio(struct vb2_queue *q,
int read)
*/
for (i = 0; i q-num_buffers; i++) {
fileio-bufs[i].vaddr = vb2_plane_vaddr(q-bufs[i], 0);
- if (fileio-bufs[i].vaddr == NULL)
+ if (fileio-bufs[i].vaddr == NULL) {
+ ret = -EFAULT;
goto err_reqbufs;
+ }
Had you test this patch? I suspect it breaks the driver, as there are
failures under
streaming handling that are acceptable, as it may indicate that userspace
was not
able to handle all queued frames in time. On such cases, what the Kernel
does is to
just discard the frame. Userspace is able to detect it, by looking inside
the timestamp
added on each frame.
No, I have not tested it. This was the only place the function was
returning non negative value for error path, so looked as a bug to me.
May I add a comment about returning non-negative value is intended
there?
There are several drivers depending on core modules like videobuf2. By making
random changes for something that _looks like_ a bug to you and not verifying
it by testing with at least one driver you are potentially causing trouble to
developers that are already busy fixing real bugs or working on new features.
I appreciate your help but I also don't want to see _any_ untested, not trivial
patches for core modules like videobuf2 being applied.
--
Thanks,
Sylwester
--
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] dma-buf: Use EXPORT_SYMBOL
On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them. Alan -- 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 3.6.0- 1/5] media/bfin: use module_platform_driver macro
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/media/platform/blackfin/bfin_capture.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index cb2eb26..ec476ef 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -1050,19 +1050,7 @@ static struct platform_driver bcap_driver = {
.probe = bcap_probe,
.remove = __devexit_p(bcap_remove),
};
-
-static __init int bcap_init(void)
-{
- return platform_driver_register(bcap_driver);
-}
-
-static __exit void bcap_exit(void)
-{
- platform_driver_unregister(bcap_driver);
-}
-
-module_init(bcap_init);
-module_exit(bcap_exit);
+module_platform_driver(bcap_driver);
MODULE_DESCRIPTION(Analog Devices blackfin video capture driver);
MODULE_AUTHOR(Scott Jiang scott.jiang.li...@gmail.com);
--
1.7.0.4
--
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 3.6.0- 2/5] media/m2m: use module_platform_driver macro
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/media/platform/m2m-deinterlace.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/m2m-deinterlace.c
b/drivers/media/platform/m2m-deinterlace.c
index 45164c4..fcdbb27 100644
--- a/drivers/media/platform/m2m-deinterlace.c
+++ b/drivers/media/platform/m2m-deinterlace.c
@@ -1108,17 +1108,5 @@ static struct platform_driver deinterlace_pdrv = {
.owner = THIS_MODULE,
},
};
-
-static void __exit deinterlace_exit(void)
-{
- platform_driver_unregister(deinterlace_pdrv);
-}
-
-static int __init deinterlace_init(void)
-{
- return platform_driver_register(deinterlace_pdrv);
-}
-
-module_init(deinterlace_init);
-module_exit(deinterlace_exit);
+module_platform_driver(deinterlace_pdrv);
--
1.7.0.4
--
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 3.6.0- 0/5] MEDIA: use module_platform_driver macro
From: Srinivas Kandagatla srinivas.kandaga...@st.com
Running below Coccinelle lookup pattern like below on the
latest kernel showed about 52 hits. This patch series is a subset
of those 52 patches, so that it will be easy for maintainers to review.
Hopefully these patches will get rid of some code duplication in kernel.
@ @
- initfunc(void)
- { return platform_driver_register(dr); }
...
- module_init(initfunc);
...
- exitfunc(void)
- { platform_driver_unregister(dr); }
...
- module_exit(exitfunc);
+ module_platform_driver(dr);
Srinivas Kandagatla (5):
media/bfin: use module_platform_driver macro
media/m2m: use module_platform_driver macro
media/mx2_emmaprp: use module_platform_driver macro
media/soc_camera: use module_platform_driver macro
media/ir_rx51: use module_platform_driver macro
drivers/media/platform/blackfin/bfin_capture.c | 14 +-
drivers/media/platform/m2m-deinterlace.c | 14 +-
drivers/media/platform/mx2_emmaprp.c | 14 +-
drivers/media/platform/soc_camera/soc_camera.c | 14 +-
drivers/media/rc/ir-rx51.c | 13 +
5 files changed, 5 insertions(+), 64 deletions(-)
--
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 3.6.0- 3/5] media/mx2_emmaprp: use module_platform_driver macro
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/media/platform/mx2_emmaprp.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/mx2_emmaprp.c
b/drivers/media/platform/mx2_emmaprp.c
index 8f22ce5..c45a9f5 100644
--- a/drivers/media/platform/mx2_emmaprp.c
+++ b/drivers/media/platform/mx2_emmaprp.c
@@ -1013,16 +1013,4 @@ static struct platform_driver emmaprp_pdrv = {
.owner = THIS_MODULE,
},
};
-
-static void __exit emmaprp_exit(void)
-{
- platform_driver_unregister(emmaprp_pdrv);
-}
-
-static int __init emmaprp_init(void)
-{
- return platform_driver_register(emmaprp_pdrv);
-}
-
-module_init(emmaprp_init);
-module_exit(emmaprp_exit);
+module_platform_driver(emmaprp_pdrv);
--
1.7.0.4
--
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 3.6.0- 4/5] media/soc_camera: use module_platform_driver macro
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/media/platform/soc_camera/soc_camera.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 3be9294..d4bfe29 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1585,19 +1585,7 @@ static struct platform_driver __refdata soc_camera_pdrv
= {
.owner = THIS_MODULE,
},
};
-
-static int __init soc_camera_init(void)
-{
- return platform_driver_register(soc_camera_pdrv);
-}
-
-static void __exit soc_camera_exit(void)
-{
- platform_driver_unregister(soc_camera_pdrv);
-}
-
-module_init(soc_camera_init);
-module_exit(soc_camera_exit);
+module_platform_driver(soc_camera_pdrv);
MODULE_DESCRIPTION(Image capture bus driver);
MODULE_AUTHOR(Guennadi Liakhovetski ker...@pengutronix.de);
--
1.7.0.4
--
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 3.6.0- 5/5] media/ir_rx51: use module_platform_driver macro
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/media/rc/ir-rx51.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 546199e..8cfe316 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -480,18 +480,7 @@ struct platform_driver lirc_rx51_platform_driver = {
.owner = THIS_MODULE,
},
};
-
-static int __init lirc_rx51_init(void)
-{
- return platform_driver_register(lirc_rx51_platform_driver);
-}
-module_init(lirc_rx51_init);
-
-static void __exit lirc_rx51_exit(void)
-{
- platform_driver_unregister(lirc_rx51_platform_driver);
-}
-module_exit(lirc_rx51_exit);
+module_platform_driver(lirc_rx51_platform_driver);
MODULE_DESCRIPTION(LIRC TX driver for Nokia RX51);
MODULE_AUTHOR(Nokia Corporation);
--
1.7.0.4
--
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
Broken Link on Your Site About Photo Album Programs - Follow-up
Hi Administrator, I wanted to follow up with you and make sure you had received my email I sent a little bit ago regarding the broken link on your site. If you are still updating your website, I have a similar resource that you can replace the broken link with if you are interested. Let me know! Best regards, Hannah Edwards -- 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
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:Wed Oct 10 19:00:21 CEST 2012 git hash:d92462401dde1effa04a51d0a15000e6246d2a43 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification 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
[PATCH v4 0/3] OMAP 3 CSI-2 configuration
Hi all, This is an update to an old patchset for CSI-2 configuration for OMAP 3430 and 3630. The patches have been tested on the 3630 only so far, and I don't plan to test them on 3430 in the near future. Changes made based on Kevin's and Laurent's comments since v3. Comments, questions and other kind of feedback is very welcome. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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 v4 1/3] omap3isp: Add CSI configuration registers from control block to ISP resources
Add the registers used to configure the CSI-2 receiver PHY on OMAP3430 and
3630 and map them in the ISP driver. The register is part of the control
block but it only is needed by the ISP driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 10 ++
drivers/media/platform/omap3isp/isp.c |6 --
drivers/media/platform/omap3isp/isp.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..9e4d5da 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -201,6 +201,16 @@ static struct resource omap3isp_resources[] = {
.flags = IORESOURCE_MEM,
},
{
+ .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
+ .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
+ 3,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL,
+ .end= OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
+ .flags = IORESOURCE_MEM,
+ },
+ {
.start = INT_34XX_CAM_IRQ,
.flags = IORESOURCE_IRQ,
}
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 6034dca..972e7b5 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -100,7 +100,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 OMAP3_ISP_IOMEM_RESZ |
1 OMAP3_ISP_IOMEM_SBL |
1 OMAP3_ISP_IOMEM_CSI2A_REGS1 |
- 1 OMAP3_ISP_IOMEM_CSIPHY2,
+ 1 OMAP3_ISP_IOMEM_CSIPHY2 |
+ 1 OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
},
{
.isp_rev = ISP_REVISION_15_0,
@@ -117,7 +118,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 OMAP3_ISP_IOMEM_CSI2A_REGS2 |
1 OMAP3_ISP_IOMEM_CSI2C_REGS1 |
1 OMAP3_ISP_IOMEM_CSIPHY1 |
- 1 OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ 1 OMAP3_ISP_IOMEM_CSI2C_REGS2 |
+ 1 OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
},
};
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 8be7487..6fed222 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -72,6 +72,8 @@ enum isp_mem_resources {
OMAP3_ISP_IOMEM_CSI2C_REGS1,
OMAP3_ISP_IOMEM_CSIPHY1,
OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
+ OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
OMAP3_ISP_IOMEM_LAST
};
--
1.7.2.5
--
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 v4 3/3] omap3isp: Configure CSI-2 phy based on platform data
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
This patch is dependent on omap3: Provide means for changing CSI2 PHY
configuration.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.h |3 -
drivers/media/platform/omap3isp/ispcsiphy.c | 148 ++-
drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
3 files changed, 78 insertions(+), 83 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 6fed222..accb3b0 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -129,9 +129,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes);
};
/*
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 12ae394..754d7a1 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -125,36 +125,6 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy, u32
iface, bool on,
}
/*
- * csiphy_lanes_config - Configuration of CSIPHY lanes.
- *
- * Updates HW configuration.
- * Called with phy-mutex taken.
- */
-static void csiphy_lanes_config(struct isp_csiphy *phy)
-{
- unsigned int i;
- u32 reg;
-
- reg = isp_reg_readl(phy-isp, phy-cfg_regs, ISPCSI2_PHY_CFG);
-
- for (i = 0; i phy-num_data_lanes; i++) {
- reg = ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
-ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
- reg |= (phy-lanes.data[i].pol
- ISPCSI2_PHY_CFG_DATA_POL_SHIFT(i + 1));
- reg |= (phy-lanes.data[i].pos
- ISPCSI2_PHY_CFG_DATA_POSITION_SHIFT(i + 1));
- }
-
- reg = ~(ISPCSI2_PHY_CFG_CLOCK_POL_MASK |
-ISPCSI2_PHY_CFG_CLOCK_POSITION_MASK);
- reg |= phy-lanes.clk.pol ISPCSI2_PHY_CFG_CLOCK_POL_SHIFT;
- reg |= phy-lanes.clk.pos ISPCSI2_PHY_CFG_CLOCK_POSITION_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-cfg_regs, ISPCSI2_PHY_CFG);
-}
-
-/*
* csiphy_power_autoswitch_enable
* @enable: Sets or clears the autoswitch function enable flag.
*/
@@ -199,43 +169,28 @@ static int csiphy_set_power(struct isp_csiphy *phy, u32
power)
}
/*
- * csiphy_dphy_config - Configure CSI2 D-PHY parameters.
- *
- * Called with phy-mutex taken.
+ * TCLK values are OK at their reset values
*/
-static void csiphy_dphy_config(struct isp_csiphy *phy)
-{
- u32 reg;
-
- /* Set up ISPCSIPHY_REG0 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG0);
-
- reg = ~(ISPCSIPHY_REG0_THS_TERM_MASK |
-ISPCSIPHY_REG0_THS_SETTLE_MASK);
- reg |= phy-dphy.ths_term ISPCSIPHY_REG0_THS_TERM_SHIFT;
- reg |= phy-dphy.ths_settle ISPCSIPHY_REG0_THS_SETTLE_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG0);
-
- /* Set up ISPCSIPHY_REG1 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG1);
-
- reg = ~(ISPCSIPHY_REG1_TCLK_TERM_MASK |
-ISPCSIPHY_REG1_TCLK_MISS_MASK |
-ISPCSIPHY_REG1_TCLK_SETTLE_MASK);
- reg |= phy-dphy.tclk_term ISPCSIPHY_REG1_TCLK_TERM_SHIFT;
- reg |= phy-dphy.tclk_miss ISPCSIPHY_REG1_TCLK_MISS_SHIFT;
- reg |= phy-dphy.tclk_settle ISPCSIPHY_REG1_TCLK_SETTLE_SHIFT;
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE14
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
-}
-
-static int csiphy_config(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes)
+static int omap3isp_csiphy_config(struct isp_csiphy *phy)
{
+ struct isp_csi2_device *csi2 = phy-csi2;
+ struct isp_pipeline *pipe = to_isp_pipeline(csi2-subdev.entity);
+ struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
+ struct isp_csiphy_lanes_cfg *lanes;
+ int csi2_ddrclk_khz;
unsigned int used_lanes = 0;
unsigned int i;
+ u32 reg;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
/* Clock and data lanes verification */
for (i = 0; i phy-num_data_lanes; i++) {
@@ -254,10 +209,56 @@ static int csiphy_config(struct isp_csiphy *phy,
[PATCH v4 2/3] omap3isp: Add PHY routing configuration
Add PHY routing configuration for both 3430 and 3630. Also add register bit
definitions of CSIRXFE and CAMERA_PHY_CTRL registers on OMAP 3430 and 3630,
respectively.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/platform/omap3isp/ispcsiphy.c | 92 +++
drivers/media/platform/omap3isp/ispreg.h| 22 +++
2 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 348f67e..12ae394 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -32,6 +32,98 @@
#include ispreg.h
#include ispcsiphy.h
+static void csiphy_routing_cfg_3630(struct isp_csiphy *phy, u32 iface,
+ bool ccp2_strobe)
+{
+ u32 reg = isp_reg_readl(
+ phy-isp, OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
+ u32 shift, mode;
+
+ switch (iface) {
+ case ISP_INTERFACE_CCP2B_PHY1:
+ reg = ~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ break;
+ case ISP_INTERFACE_CSI2C_PHY1:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ case ISP_INTERFACE_CCP2B_PHY2:
+ reg |= OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ break;
+ case ISP_INTERFACE_CSI2A_PHY2:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ }
+
+ /* Select data/clock or data/strobe mode for CCP2 */
+ switch (iface) {
+ case ISP_INTERFACE_CCP2B_PHY1:
+ case ISP_INTERFACE_CCP2B_PHY2:
+ if (ccp2_strobe)
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
+ else
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_CLOCK;
+ }
+
+ reg = ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK shift);
+ reg |= mode shift;
+
+ isp_reg_writel(phy-isp, reg,
+ OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
+}
+
+static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool on,
+ bool ccp2_strobe)
+{
+ uint32_t csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
+ | OMAP343X_CONTROL_CSIRXFE_RESET;
+
+ /* Nothing to configure here. */
+ if (iface == ISP_INTERFACE_CSI2A_PHY2)
+ return;
+
+ if (iface != ISP_INTERFACE_CCP2B_PHY1)
+ return;
+
+ if (!on) {
+ isp_reg_writel(phy-isp, 0,
+ OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
+ return;
+ }
+
+ if (ccp2_strobe)
+ csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
+
+ isp_reg_writel(phy-isp, csirxfe,
+ OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
+}
+
+/**
+ * Configure OMAP 3 CSI PHY routing.
+ *
+ * Note that the underlying routing configuration registers are part
+ * of the control (SCM) register space and part of the CORE power
+ * domain on both 3430 and 3630, so they will not hold their contents
+ * in off-mode.
+ *
+ * @phy: relevant phy device
+ * @iface: ISP_INTERFACE_*
+ * @on: power on or off
+ * @ccp2_strobe: false: data/clock, true: data/strobe
+ */
+static void csiphy_routing_cfg(struct isp_csiphy *phy, u32 iface, bool on,
+ bool ccp2_strobe)
+{
+ if (phy-isp-mmio_base[OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL]
+on)
+ return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
+ if (phy-isp-mmio_base[OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE])
+ return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
+}
+
/*
* csiphy_lanes_config - Configuration of CSIPHY lanes.
*
diff --git a/drivers/media/platform/omap3isp/ispreg.h
b/drivers/media/platform/omap3isp/ispreg.h
index e2c57f3..148108b 100644
--- a/drivers/media/platform/omap3isp/ispreg.h
+++ b/drivers/media/platform/omap3isp/ispreg.h
@@ -1583,4 +1583,26 @@
#define ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_MASK \
(0x7f ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_SHIFT)
+/*
-
+ * CONTROL registers for CSI-2 phy routing
+ */
+
+/* OMAP343X_CONTROL_CSIRXFE */
+#define OMAP343X_CONTROL_CSIRXFE_CSIB_INV (1 7)
+#define OMAP343X_CONTROL_CSIRXFE_RESENABLE (1 8)
+#define OMAP343X_CONTROL_CSIRXFE_SELFORM (1 10)
+#define OMAP343X_CONTROL_CSIRXFE_PWRDNZ(1 12)
+#define
Re: [PATCH 05/14] media: add a V4L2 OF parser
Hi Laurent, On 10/10/2012 03:25 PM, Laurent Pinchart wrote: On Tuesday 09 October 2012 13:00:24 Hans Verkuil wrote: On Tue 9 October 2012 12:34:48 Sylwester Nawrocki wrote: On 10/08/2012 11:40 AM, Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Sylwester Nawrocki wrote: I would really like to see more than one user until we add any core code. No that it couldn't be changed afterwards, but it would be nice to ensure the concepts are right and proven in real life. Unfortunately I don't have any more systems on which I could easily enough try this. I've got a beagleboard with a camera, but I don't think I'm a particularly good candidate for implementing DT support for OMAP3 camera drivers;-) Apart from that I've only got soc-camera based systems, of which none are _really_ DT-ready... At best I could try an i.MX31 based board, but that doesn't have a very well developed .dts and that would be soc-camera too anyway. I certainly wouldn't expect you would do all the job. I mean it would be good to possibly have some other developers adding device tree support based on that new bindings and new infrastructure related to them. As I mentioned in another e-mail, I plan to work on DT support for the OMAP3 ISP, but I first need generic clock framework support for OMAP3. OK, let's hope it's available soon. There have been recently some progress in device tree support for Exynos SoCs, including common clock framework support and we hope to add FDT support to the Samsung SoC camera devices during this kernel cycle, based on the newly designed media bindings. This is going to be a second attempt, after our initial RFC from May [1]. It would still be SoC specific implementation, but not soc-camera based. I wasn't a big fan of this asynchronous sub-devices probing, but it now seems to be a most complete solution to me. I think it just need to be done right at the v4l2-core so individual drivers don't get complicated too much. After investigating this some more I think I agree with that. There are some things where we should probably ask for advice from the i2c subsystem devs, I'm thinking of putting the driver back into the deferred-probe state in particular. We might actually not need that, it might be easier to handle the circular dependency problem from the other end. We could add a way (ioctl, sysfs, ...) to force a V4L2 bridge driver to release its subdevs. Once done, the subdev driver could be unloaded and/or the subdev device unregistered, which would release the resources used by the subdev, such as clocks. The bridge driver could then be unregistered. That sounds like an option. Perhaps it could be done by v4l2-core, e.g. a sysfs entry could be registered for a media or video device if driver requests it. I'm not sure if we should allow subdevs in released state, perhaps it's better to just unregister subdevs entirely right away ? Creating v4l2-core support for this is crucial as it is quite complex and without core support this is going to be a nightmare for drivers. -- Regards, Sylwester -- 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 05/14] media: add a V4L2 OF parser
On Wed, 10 Oct 2012, Sylwester Nawrocki wrote: Hi Laurent, On 10/10/2012 03:25 PM, Laurent Pinchart wrote: On Tuesday 09 October 2012 13:00:24 Hans Verkuil wrote: On Tue 9 October 2012 12:34:48 Sylwester Nawrocki wrote: On 10/08/2012 11:40 AM, Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Sylwester Nawrocki wrote: I would really like to see more than one user until we add any core code. No that it couldn't be changed afterwards, but it would be nice to ensure the concepts are right and proven in real life. Unfortunately I don't have any more systems on which I could easily enough try this. I've got a beagleboard with a camera, but I don't think I'm a particularly good candidate for implementing DT support for OMAP3 camera drivers;-) Apart from that I've only got soc-camera based systems, of which none are _really_ DT-ready... At best I could try an i.MX31 based board, but that doesn't have a very well developed .dts and that would be soc-camera too anyway. I certainly wouldn't expect you would do all the job. I mean it would be good to possibly have some other developers adding device tree support based on that new bindings and new infrastructure related to them. As I mentioned in another e-mail, I plan to work on DT support for the OMAP3 ISP, but I first need generic clock framework support for OMAP3. OK, let's hope it's available soon. There have been recently some progress in device tree support for Exynos SoCs, including common clock framework support and we hope to add FDT support to the Samsung SoC camera devices during this kernel cycle, based on the newly designed media bindings. This is going to be a second attempt, after our initial RFC from May [1]. It would still be SoC specific implementation, but not soc-camera based. I wasn't a big fan of this asynchronous sub-devices probing, but it now seems to be a most complete solution to me. I think it just need to be done right at the v4l2-core so individual drivers don't get complicated too much. After investigating this some more I think I agree with that. There are some things where we should probably ask for advice from the i2c subsystem devs, I'm thinking of putting the driver back into the deferred-probe state in particular. We might actually not need that, it might be easier to handle the circular dependency problem from the other end. We could add a way (ioctl, sysfs, ...) to force a V4L2 bridge driver to release its subdevs. Once done, the subdev driver could be unloaded and/or the subdev device unregistered, which would release the resources used by the subdev, such as clocks. The bridge driver could then be unregistered. That sounds like an option. Perhaps it could be done by v4l2-core, e.g. a sysfs entry could be registered for a media or video device if driver requests it. I'm not sure if we should allow subdevs in released state, perhaps it's better to just unregister subdevs entirely right away ? What speaks against holding a clock reference only during streaming, or at least between open and close? Wouldn't that solve the problem naturally? Yes, after giving up your reference to a clock at close() and re-acquiring it at open() you will have to make sure the frequency hasn't change, resp. adjust it, but I don't see it as a huge problem, I don't think many users on embedded systems will compete for your camera master clock. And if they do, you have a different problem, IMHO;-) Thanks Guennadi Creating v4l2-core support for this is crucial as it is quite complex and without core support this is going to be a nightmare for drivers. -- Regards, Sylwester --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Well, for my contributions to dmabuf, I don't object.. and I think because we are planning to use dma-buf in userspace for dri3 / dri-next, I think that basically makes it a userspace facing kernel infrastructure which would be required for open and proprietary drivers alike. So I don't see much alternative to making this EXPORT_SYMBOL(). Of course, IANAL. BR, -R Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them. Alan ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 05/14] media: add a V4L2 OF parser
On 10/10/2012 10:32 PM, Guennadi Liakhovetski wrote: We might actually not need that, it might be easier to handle the circular dependency problem from the other end. We could add a way (ioctl, sysfs, ...) to force a V4L2 bridge driver to release its subdevs. Once done, the subdev driver could be unloaded and/or the subdev device unregistered, which would release the resources used by the subdev, such as clocks. The bridge driver could then be unregistered. That sounds like an option. Perhaps it could be done by v4l2-core, e.g. a sysfs entry could be registered for a media or video device if driver requests it. I'm not sure if we should allow subdevs in released state, perhaps it's better to just unregister subdevs entirely right away ? What speaks against holding a clock reference only during streaming, or at least between open and close? Wouldn't that solve the problem naturally? Yes, after giving up your reference to a clock at close() and re-acquiring it at open() you will have to make sure the frequency hasn't change, resp. adjust it, but I don't see it as a huge problem, I don't think many users on embedded systems will compete for your camera master clock. And if they do, you have a different problem, IMHO;-) I agree, normally nobody should touch these clocks except the subdev (or as of now the host) drivers. It depends on a sensor, video encoder, etc. how much it tolerates switching the clock on/off. I suppose it's best to acquire/release it in .s_power callback, since only then the proper voltage supply, GPIO, clock enable/disable sequences could be ensured. I know those things are currently mostly ignored, but some sensors might be picky WRT their initialization/shutdown sequences and it would be good to ensure these sequences are fully controllable by the sensor driver itsels, where the host's architecture allows that. To summarize, I can't see how holding a clock only when a device is active could cause any problems, in case of camera sensors. I'm not sure about other devices, like e.g. tuners. -- Regards, Sylwester -- 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 05/14] media: add a V4L2 OF parser
On Wednesday 10 October 2012 10:50:20 Stephen Warren wrote: On 10/10/2012 07:18 AM, Laurent Pinchart wrote: On Monday 08 October 2012 17:15:53 Guennadi Liakhovetski wrote: ... But how do you get the subdev pointer? With the notifier I get it from i2c_get_clientdata(client) and what do you do without it? How do you get to the client? And can't it get that from DT as well? No, I don't think there is a way to get a device pointer from a DT node. I don't believe there's a generic API for this (although perhaps there could be), but it can be implemented quite easily. For example, on Tegra, the SMMU needs to flip a bit in the AHB register space in order to enable itself. The SMMU DT node contains a phandle that points at the AHB DT node. The SMMU driver parses the phandle and passes the DT node pointer to the AHB driver. The AHB driver looks up the struct device that was instantiated for that node. See drivers/amba/tegra-ahb.c:tegra_ahb_enable_smmu(). There are a few other cases of similar code in the kernel, although I can't remember the others! That's a very naive approach, but what about storing the struct device in struct device_node when the device is instantiated ? It's so simple that there's probably a good reason why that hasn't been implemented though. -- Regards, Laurent Pinchart -- 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 05/14] media: add a V4L2 OF parser
Hi Sylwester, On Wednesday 10 October 2012 22:23:35 Sylwester Nawrocki wrote: On 10/10/2012 03:25 PM, Laurent Pinchart wrote: On Tuesday 09 October 2012 13:00:24 Hans Verkuil wrote: On Tue 9 October 2012 12:34:48 Sylwester Nawrocki wrote: On 10/08/2012 11:40 AM, Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Sylwester Nawrocki wrote: I would really like to see more than one user until we add any core code. No that it couldn't be changed afterwards, but it would be nice to ensure the concepts are right and proven in real life. Unfortunately I don't have any more systems on which I could easily enough try this. I've got a beagleboard with a camera, but I don't think I'm a particularly good candidate for implementing DT support for OMAP3 camera drivers;-) Apart from that I've only got soc-camera based systems, of which none are _really_ DT-ready... At best I could try an i.MX31 based board, but that doesn't have a very well developed .dts and that would be soc-camera too anyway. I certainly wouldn't expect you would do all the job. I mean it would be good to possibly have some other developers adding device tree support based on that new bindings and new infrastructure related to them. As I mentioned in another e-mail, I plan to work on DT support for the OMAP3 ISP, but I first need generic clock framework support for OMAP3. OK, let's hope it's available soon. I've been told a month and a half ago that v3.7 was a plausible target, let's see. There have been recently some progress in device tree support for Exynos SoCs, including common clock framework support and we hope to add FDT support to the Samsung SoC camera devices during this kernel cycle, based on the newly designed media bindings. This is going to be a second attempt, after our initial RFC from May [1]. It would still be SoC specific implementation, but not soc-camera based. I wasn't a big fan of this asynchronous sub-devices probing, but it now seems to be a most complete solution to me. I think it just need to be done right at the v4l2-core so individual drivers don't get complicated too much. After investigating this some more I think I agree with that. There are some things where we should probably ask for advice from the i2c subsystem devs, I'm thinking of putting the driver back into the deferred-probe state in particular. We might actually not need that, it might be easier to handle the circular dependency problem from the other end. We could add a way (ioctl, sysfs, ...) to force a V4L2 bridge driver to release its subdevs. Once done, the subdev driver could be unloaded and/or the subdev device unregistered, which would release the resources used by the subdev, such as clocks. The bridge driver could then be unregistered. That sounds like an option. Perhaps it could be done by v4l2-core, e.g. a sysfs entry could be registered for a media or video device if driver requests it. That's what I was thinking about. I'm not sure if we should allow subdevs in released state, perhaps it's better to just unregister subdevs entirely right away ? I think we need three states: not created, unbound and bound (names are not set in stone). The not created state corresponds to a subdev that hasn't been created yet by its I2C/SPI/whatever driver (agreed, it's not really a state technically). Upon creation the subdev is not bound to any bridge driver. It later gets bound when the bridge driver requests the subdev through the API the V4L2 core will provide (most probably using notifiers). The new sysfs entry would be used to unbind subdevs (either selectively, or all in one go) from the bridge, in which case they will go back to the unbound state, allowing driver removal or device release. Creating v4l2-core support for this is crucial as it is quite complex and without core support this is going to be a nightmare for drivers. -- Regards, Laurent Pinchart -- 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 05/14] media: add a V4L2 OF parser
Hi Guennadi, On Wednesday 10 October 2012 22:32:22 Guennadi Liakhovetski wrote: On Wed, 10 Oct 2012, Sylwester Nawrocki wrote: On 10/10/2012 03:25 PM, Laurent Pinchart wrote: On Tuesday 09 October 2012 13:00:24 Hans Verkuil wrote: On Tue 9 October 2012 12:34:48 Sylwester Nawrocki wrote: On 10/08/2012 11:40 AM, Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Sylwester Nawrocki wrote: I would really like to see more than one user until we add any core code. No that it couldn't be changed afterwards, but it would be nice to ensure the concepts are right and proven in real life. Unfortunately I don't have any more systems on which I could easily enough try this. I've got a beagleboard with a camera, but I don't think I'm a particularly good candidate for implementing DT support for OMAP3 camera drivers;-) Apart from that I've only got soc-camera based systems, of which none are _really_ DT-ready... At best I could try an i.MX31 based board, but that doesn't have a very well developed .dts and that would be soc-camera too anyway. I certainly wouldn't expect you would do all the job. I mean it would be good to possibly have some other developers adding device tree support based on that new bindings and new infrastructure related to them. As I mentioned in another e-mail, I plan to work on DT support for the OMAP3 ISP, but I first need generic clock framework support for OMAP3. OK, let's hope it's available soon. There have been recently some progress in device tree support for Exynos SoCs, including common clock framework support and we hope to add FDT support to the Samsung SoC camera devices during this kernel cycle, based on the newly designed media bindings. This is going to be a second attempt, after our initial RFC from May [1]. It would still be SoC specific implementation, but not soc-camera based. I wasn't a big fan of this asynchronous sub-devices probing, but it now seems to be a most complete solution to me. I think it just need to be done right at the v4l2-core so individual drivers don't get complicated too much. After investigating this some more I think I agree with that. There are some things where we should probably ask for advice from the i2c subsystem devs, I'm thinking of putting the driver back into the deferred-probe state in particular. We might actually not need that, it might be easier to handle the circular dependency problem from the other end. We could add a way (ioctl, sysfs, ...) to force a V4L2 bridge driver to release its subdevs. Once done, the subdev driver could be unloaded and/or the subdev device unregistered, which would release the resources used by the subdev, such as clocks. The bridge driver could then be unregistered. That sounds like an option. Perhaps it could be done by v4l2-core, e.g. a sysfs entry could be registered for a media or video device if driver requests it. I'm not sure if we should allow subdevs in released state, perhaps it's better to just unregister subdevs entirely right away ? What speaks against holding a clock reference only during streaming, or at least between open and close? Wouldn't that solve the problem naturally? Yes, after giving up your reference to a clock at close() and re-acquiring it at open() you will have to make sure the frequency hasn't change, resp. adjust it, but I don't see it as a huge problem, I don't think many users on embedded systems will compete for your camera master clock. And if they do, you have a different problem, IMHO;-) That's an option as well. I'm a bit worried that it would make subdev drivers more complex, as they would need to acquire/release resources in a more fine- grained fashion at runtime, and handle failures dynamically there instead of doing it all at probe time. It could work though, I think we need to experiment the possible solutions to find out which one is the best. Regardless of how we solve the circular dependencies issue at unregistration time we will need an easy way for bridge drivers to bind to subdevs. I believe that's orthogonal to the unregistration problem, so we can start working on registration before knowing exactly how unregistration will be handled. Creating v4l2-core support for this is crucial as it is quite complex and without core support this is going to be a nightmare for drivers. -- Regards, Laurent Pinchart -- 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] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. I think he has that. Maybe he just needs to list them. But this doesn't change the license on the code at all really, so its actually not like a re-license where you need approval. But in any case I personally don't care about this interface being used if the alternative is they do it themselves. I'm still not going to debug things with a binary module taint. Dave. -- 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 v4 3/3] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
Thanks for the patch.
On Wednesday 10 October 2012 23:01:42 Sakari Ailus wrote:
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
This patch is dependent on omap3: Provide means for changing CSI2 PHY
configuration.
Is it still ?
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.h |3 -
drivers/media/platform/omap3isp/ispcsiphy.c | 148
drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
3 files changed, 78 insertions(+), 83 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index 6fed222..accb3b0 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -129,9 +129,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes);
};
/*
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c index 12ae394..754d7a1 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -125,36 +125,6 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
u32 iface, bool on, }
/*
- * csiphy_lanes_config - Configuration of CSIPHY lanes.
- *
- * Updates HW configuration.
- * Called with phy-mutex taken.
- */
-static void csiphy_lanes_config(struct isp_csiphy *phy)
-{
- unsigned int i;
- u32 reg;
-
- reg = isp_reg_readl(phy-isp, phy-cfg_regs, ISPCSI2_PHY_CFG);
-
- for (i = 0; i phy-num_data_lanes; i++) {
- reg = ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
- ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
- reg |= (phy-lanes.data[i].pol
- ISPCSI2_PHY_CFG_DATA_POL_SHIFT(i + 1));
- reg |= (phy-lanes.data[i].pos
- ISPCSI2_PHY_CFG_DATA_POSITION_SHIFT(i + 1));
- }
-
- reg = ~(ISPCSI2_PHY_CFG_CLOCK_POL_MASK |
- ISPCSI2_PHY_CFG_CLOCK_POSITION_MASK);
- reg |= phy-lanes.clk.pol ISPCSI2_PHY_CFG_CLOCK_POL_SHIFT;
- reg |= phy-lanes.clk.pos ISPCSI2_PHY_CFG_CLOCK_POSITION_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-cfg_regs, ISPCSI2_PHY_CFG);
-}
-
-/*
* csiphy_power_autoswitch_enable
* @enable: Sets or clears the autoswitch function enable flag.
*/
@@ -199,43 +169,28 @@ static int csiphy_set_power(struct isp_csiphy *phy,
u32 power) }
/*
- * csiphy_dphy_config - Configure CSI2 D-PHY parameters.
- *
- * Called with phy-mutex taken.
+ * TCLK values are OK at their reset values
*/
-static void csiphy_dphy_config(struct isp_csiphy *phy)
-{
- u32 reg;
-
- /* Set up ISPCSIPHY_REG0 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG0);
-
- reg = ~(ISPCSIPHY_REG0_THS_TERM_MASK |
- ISPCSIPHY_REG0_THS_SETTLE_MASK);
- reg |= phy-dphy.ths_term ISPCSIPHY_REG0_THS_TERM_SHIFT;
- reg |= phy-dphy.ths_settle ISPCSIPHY_REG0_THS_SETTLE_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG0);
-
- /* Set up ISPCSIPHY_REG1 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG1);
-
- reg = ~(ISPCSIPHY_REG1_TCLK_TERM_MASK |
- ISPCSIPHY_REG1_TCLK_MISS_MASK |
- ISPCSIPHY_REG1_TCLK_SETTLE_MASK);
- reg |= phy-dphy.tclk_term ISPCSIPHY_REG1_TCLK_TERM_SHIFT;
- reg |= phy-dphy.tclk_miss ISPCSIPHY_REG1_TCLK_MISS_SHIFT;
- reg |= phy-dphy.tclk_settle ISPCSIPHY_REG1_TCLK_SETTLE_SHIFT;
+#define TCLK_TERM0
+#define TCLK_MISS1
+#define TCLK_SETTLE 14
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
-}
-
-static int csiphy_config(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes)
+static int omap3isp_csiphy_config(struct isp_csiphy *phy)
{
+ struct isp_csi2_device *csi2 = phy-csi2;
+ struct isp_pipeline *pipe = to_isp_pipeline(csi2-subdev.entity);
+ struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
+ struct isp_csiphy_lanes_cfg *lanes;
+ int csi2_ddrclk_khz;
unsigned int used_lanes = 0;
unsigned int i;
+ u32 reg;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
/* Clock and data lanes verification */
for (i = 0; i
Re: [PATCH v4 2/3] omap3isp: Add PHY routing configuration
Hi Sakari,
Thanks for the patch.
On Wednesday 10 October 2012 23:01:41 Sakari Ailus wrote:
Add PHY routing configuration for both 3430 and 3630. Also add register bit
definitions of CSIRXFE and CAMERA_PHY_CTRL registers on OMAP 3430 and 3630,
respectively.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/platform/omap3isp/ispcsiphy.c | 92
drivers/media/platform/omap3isp/ispreg.h| 22 +++
2 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c index 348f67e..12ae394 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -32,6 +32,98 @@
#include ispreg.h
#include ispcsiphy.h
+static void csiphy_routing_cfg_3630(struct isp_csiphy *phy, u32 iface,
+ bool ccp2_strobe)
+{
+ u32 reg = isp_reg_readl(
+ phy-isp, OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
+ u32 shift, mode;
+
+ switch (iface) {
+ case ISP_INTERFACE_CCP2B_PHY1:
+ reg = ~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ break;
+ case ISP_INTERFACE_CSI2C_PHY1:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ case ISP_INTERFACE_CCP2B_PHY2:
+ reg |= OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ break;
+ case ISP_INTERFACE_CSI2A_PHY2:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ }
+
+ /* Select data/clock or data/strobe mode for CCP2 */
+ switch (iface) {
+ case ISP_INTERFACE_CCP2B_PHY1:
+ case ISP_INTERFACE_CCP2B_PHY2:
+ if (ccp2_strobe)
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
+ else
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_CLOCK;
+ }
+
+ reg = ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK shift);
+ reg |= mode shift;
+
+ isp_reg_writel(phy-isp, reg,
+OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
+}
+
+static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool
on,
+ bool ccp2_strobe)
+{
+ uint32_t csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
+ | OMAP343X_CONTROL_CSIRXFE_RESET;
Anything wrong with u32 ? :-)
(I would also align the | with the = but that's nitpicking)
+
+ /* Nothing to configure here. */
+ if (iface == ISP_INTERFACE_CSI2A_PHY2)
+ return;
+
+ if (iface != ISP_INTERFACE_CCP2B_PHY1)
+ return;
Can't you get rid of the first check ?
+ if (!on) {
+ isp_reg_writel(phy-isp, 0,
+OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
+ return;
+ }
+
+ if (ccp2_strobe)
+ csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
+
+ isp_reg_writel(phy-isp, csirxfe,
+OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
+}
+
+/**
+ * Configure OMAP 3 CSI PHY routing.
+ *
+ * Note that the underlying routing configuration registers are part
+ * of the control (SCM) register space and part of the CORE power
+ * domain on both 3430 and 3630, so they will not hold their contents
+ * in off-mode.
Could you please add a sentence to explain why that's not an issue ?
+ * @phy: relevant phy device
+ * @iface: ISP_INTERFACE_*
+ * @on: power on or off
+ * @ccp2_strobe: false: data/clock, true: data/strobe
+ */
+static void csiphy_routing_cfg(struct isp_csiphy *phy, u32 iface, bool on,
+bool ccp2_strobe)
+{
+ if (phy-isp-mmio_base[OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL]
+ on)
+ return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
+ if (phy-isp-mmio_base[OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE])
+ return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
+}
+
/*
* csiphy_lanes_config - Configuration of CSIPHY lanes.
*
diff --git a/drivers/media/platform/omap3isp/ispreg.h
b/drivers/media/platform/omap3isp/ispreg.h index e2c57f3..148108b 100644
--- a/drivers/media/platform/omap3isp/ispreg.h
+++ b/drivers/media/platform/omap3isp/ispreg.h
@@ -1583,4 +1583,26 @@
#define ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_MASK\
(0x7f ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_SHIFT)
+/*
---
-- + * CONTROL registers for CSI-2 phy
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em Thu, 11 Oct 2012 09:22:34 +1000 Dave Airlie airl...@gmail.com escreveu: On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. I think he has that. Maybe he just needs to list them. My understanding it that he doesn't, as the dmabuf interface exposes not only the code written by this driver's author, but other parts of the Kernel. Even if someone consider just the dmabuf driver, I participated and actively contributed, together with other open source developers, during the 3 days discussions that happened at Linaro's forum where most of dmabuf design was decided, and participated, reviewed, gave suggestions approved the code, etc via email. So, even not writing the dmabuf stuff myself, I consider myself as one of the intelectual authors of the solution. Also, as dmabuf will also expose media interfaces, my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. 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: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. I think he has that. Maybe he just needs to list them. My understanding it that he doesn't, as the dmabuf interface exposes not only the code written by this driver's author, but other parts of the Kernel. Even if someone consider just the dmabuf driver, I participated and actively contributed, together with other open source developers, during the 3 days discussions that happened at Linaro's forum where most of dmabuf design was decided, and participated, reviewed, gave suggestions approved the code, etc via email. So, even not writing the dmabuf stuff myself, I consider myself as one of the intelectual authors of the solution. Also, as dmabuf will also expose media interfaces, my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. Though that does beg the question why you care about this patch :-) Dave. -- 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: udev breakages -
Greg KH gre...@linuxfoundation.org writes:
On Thu, Oct 04, 2012 at 10:29:51AM -0700, Eric W. Biederman wrote:
There are still quite a few interesting cases that devtmpfs does not
even think about supporting. Cases that were reported when devtmpfs was
being reviewed.
Care to refresh my memory?
Anyone who wants something besides the default policy. Containers
chroots anyone who doesn't want /dev/console to be c 5 1.
Additionally the devtmpfs maintainership has not dealt with legitimate
concerns any better than this firmware issue has been dealt with. I
still haven't even hear a productive suggestion back on the hole
/dev/ptmx mess.
I don't know how to handle the /dev/ptmx issue properly from within
devtmpfs, does anyone? Proposals are always welcome, the last time this
came up a week or so ago, I don't recall seeing any proposals, just a
general complaint.
The proposal at that time was to work around the silliness with a little
kernel magic.
To recap for those who haven't watched closely. devpts now has a ptmx
device node and it would be very nice if we were to use that device
node instead of /dev/ptmx.
Baically it would be nice to tell udev to not create /dev/ptmx, and
instead to make /dev/ptmx a symlink to /dev/pts/ptmx.
I got to looking at the problem and if I don't worry about systemd and
just look at older versions of udev that are out there in the wild it
turns out the following udev configuratoin line does exactly what is
needed. It creats a symlink from /dev/ptmx to /dev/pts/ptmx. And if
on the odd chance devpts is not mounted it creates /dev/pts/ptmx as
well.
KERNEL==ptmx NAME:=pts/ptmx SYMLINK=ptmx
Does assigning to NAME to specify the device naming policy work in
systemd-udev or has that capability been ripped out?
Thinking about it. Since systemd-udev no longer supports changing the
device name. And likely it no longer even supports assigning to NAME
even for purposes of changing the target of the symlink. Then I expect
what we want to do is:
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index 147d1a4..7dc5bed 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -377,6 +377,7 @@ static int devtmpfsd(void *p)
goto out;
sys_chdir(/..); /* will traverse into overmounted root */
sys_chroot(.);
+ sys_symlink(pts/ptmx, ptmx);
complete(setup_done);
while (1) {
spin_lock(req_lock);
Eric
--
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
