Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi, On 03/04/2012 10:58 PM, Xavion wrote: Hi Jean-Francois I can confirm that GSPCA v2.15.1 removes the bad pixels when I use Cheese or VLC. However, I'm sorry to report that the Motion problems unfortunately still remain. Is there something else I must do to overcome the below errors? I'm happy to keep testing newer GSPCA versions for you until we get this fixed. I guess that motion is using the JPG compressed frames rather then the i420 like special format these cameras also support, and it looks like we don't reserve enoug space to buffer these frames. To fix this we need to enlarge the size we reserve per frame in the sn9c20x driver, edit sn9c20x.c and search for vga_mode, in that table you will find a factor 4 / 8 (its in there 3 times), change all 3 occurences to 5 / 8 and try again, then 6 / 8, etc. Normally I would be suspicious about SOF / EOF detection when we need such a factor, but the timestamps in your log exactly match 30 fps, so that seems to be fine. And in my experience with the USB bandwidth stuff the sn9c20x does seem to compress less then other JPG cams, so it makes sense that it needs bigger buffers to store the frames too. Alternatively you can try if motion can be made to use a different format then JPG, by forcing it to use libv4l by starting it like this: LD_PRELOAD=/usr/lib/libv4l/v4l1-compat.so motion Note if you're on a rpm based 64 bit distro and motion is 64 bit too that should be: LD_PRELOAD=/usr/lib64/libv4l/v4l1-compat.so motion But that would just be working around the issue, it is better to fix the issue with using the JPG mode of the camera instead. Regards, Hans `-- tail /var/log/kernel.log Mar 5 08:25:52 Desktop kernel: [ 6673.781987] gspca_main: frame overflow 156309 155648 Mar 5 08:25:52 Desktop kernel: [ 6673.813992] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.849986] gspca_main: frame overflow 155693 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.881989] gspca_main: frame overflow 156021 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.917991] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.949993] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6673.985990] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.021981] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.053985] gspca_main: frame overflow 156309 155648 Mar 5 08:25:53 Desktop kernel: [ 6674.089989] gspca_main: frame overflow 156309 155648 `-- tail /var/log/errors.log Mar 5 08:24:16 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:16 Desktop motion: [1] Video device fatal error - Closing video device Mar 5 08:24:20 Desktop motion: [1] Retrying until successful connection with camera Mar 5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO (s-pframe 3): Input/output error Mar 5 08:24:27 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:27 Desktop motion: [1] Video device fatal error - Closing video device Mar 5 08:24:30 Desktop motion: [1] Retrying until successful connection with camera Mar 5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_DQBUF: EIO (s-pframe 0): Input/output error Mar 5 08:24:33 Desktop motion: [1] v4l2_next: VIDIOC_QBUF: Invalid argument Mar 5 08:24:33 Desktop motion: [1] Video device fatal error - Closing video device -- 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: [bug?] ov519 fails to handle Hercules Deluxe webcam
On Sun, 4 Mar 2012 18:38:01 -0600 Jonathan Nieder jrnie...@gmail.com wrote: Hi, Skippy le Grand Gourou wrote[1]: Hercules Deluxe USB webcam won't work, see the end of the kernel log. [...] [521041.808976] gspca: probing 05a9:4519 [521042.469094] ov519: I2C synced in 3 attempt(s) [521042.469097] ov519: starting OV7xx0 configuration [521042.469793] ov519: Unknown image sensor version: 2 [521042.469795] ov519: Failed to configure OV7xx0 [521042.469797] ov519: OV519 Config failed [521042.469807] ov519: probe of 3-1.4:1.0 failed with error -16 [521042.469884] gspca: probing 05a9:4519 [521467.885255] usbcore: deregistering interface driver ov519 [521467.885278] ov519: deregistered [521467.900288] gspca: main deregistered [521809.376462] dialog[12612]: segfault at 0 ip b77c6125 sp bf8861b0 error 4 in libncursesw.so.5.7[b77b5000+43000] [524303.418813] usb 3-1.3: USB disconnect, address 9 [...] [528511.174900] usb 3-1.4: USB disconnect, address 10 [528513.420812] usb 3-1.4: new full speed USB device using ehci_hcd and address 13 [528513.515013] usb 3-1.4: New USB device found, idVendor=05a9, idProduct=4519 [528513.515018] usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [528513.515021] usb 3-1.4: Product: USB Camera [528513.515023] usb 3-1.4: Manufacturer: OmniVision Technologies, Inc. [528513.515116] usb 3-1.4: configuration #1 chosen from 1 choice [528513.524620] Linux video capture interface: v2.00 [528513.526783] gspca: main v2.7.0 registered [528513.527299] gspca: probing 05a9:4519 [528514.190995] ov519: I2C synced in 3 attempt(s) [528514.190998] ov519: starting OV7xx0 configuration [528514.192570] ov519: Sensor is an OV7610 [528514.417110] ov519: probe of 3-1.4:1.0 failed with error -5 [528514.417139] usbcore: registered new interface driver ov519 [528514.417143] ov519: registered [...] 00:1a.0 USB Controller [0c03]: Intel Corporation Cougar Point USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Device [1043:844d] [...] Bus 001 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 012: ID 9e88:9e8f Bus 003 Device 013: ID 05a9:4519 OmniVision Technologies, Inc. Webcam Classic Bus 003 Device 005: ID 04a9:221c Canon, Inc. CanoScan LiDE 60 Bus 003 Device 006: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver [...] Kernel is Debian 2.6.32-41, which is closely based on stable 2.6.32.54. I don't see any obvious potential fixes in the diff relative to linux-next. Known problem? Any hints for tracking this down? Thanks, Jonathan [1] http://bugs.debian.org/662246 Hi Skippy and Jonathan, The git commit b877a9a7fb0 (gspca - ov519: Fix sensor detection problems) may have fix this problem. To be sure, try the gspca test version from my web site. -- 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: [bug?] ov519 fails to handle Hercules Deluxe webcam
Jean-Francois Moine wrote: Skippy le Grand Gourou wrote[1]: Hercules Deluxe USB webcam won't work, see the end of the kernel log. [...] [521041.808976] gspca: probing 05a9:4519 [521042.469094] ov519: I2C synced in 3 attempt(s) [521042.469097] ov519: starting OV7xx0 configuration [521042.469793] ov519: Unknown image sensor version: 2 [521042.469795] ov519: Failed to configure OV7xx0 [...] [528513.526783] gspca: main v2.7.0 registered [528513.527299] gspca: probing 05a9:4519 [528514.190995] ov519: I2C synced in 3 attempt(s) [528514.190998] ov519: starting OV7xx0 configuration [528514.192570] ov519: Sensor is an OV7610 [...] The git commit b877a9a7fb0 (gspca - ov519: Fix sensor detection problems) may have fix this problem. Oh! Yep, the symptoms match well --- sorry I missed it. To be sure, try the gspca test version from my web site. Skippy, assuming that works (and I expect it would), could you try the attached patch against 2.6.32.y? It works like this: 0. Prerequisites: apt-get install git build-essential 1. Get the kernel, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. Fetch point releases: cd linux git remote add -f stable \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 3. Try the 2.6.32.y branch: git checkout stable/linux-2.6.32.y cp /boot/config-$(uname -r) .config; # current configuration make localmodconfig; # optional: minimize configuration make; # optionally with -jnum for parallel build fakeroot -u make deb-pkg dpkg -i ../name of package reboot make localmodconfig works by leaving out drivers whose modules are not currently loaded, so take care to make sure the gspca and ov519 modules are built. (make nconfig customizes the configuration.) Hopefully this kernel reproduces the bug. 4. See if the patch helps: git am -3sc path to patch make; # maybe with -j4 fakeroot -u make deb-pkg dpkg -i ../name of package reboot Hopeful, Jonathan From: Jean-François Moine moin...@free.fr Date: Sun, 3 Jul 2011 05:17:27 -0300 Subject: [media] gspca - ov519: Fix sensor detection problems commit b877a9a7fb00d96bae4ab49c69f1be65b3e87e61 upstream. The sensor of some webcams could not be detected due to timing problems in sensor register reading. This patch adds bridge register readings before sensor register reading. Signed-off-by: Jean-François Moine moin...@free.fr Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- drivers/media/video/gspca/ov519.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/video/gspca/ov519.c b/drivers/media/video/gspca/ov519.c index e16557819782..7a31e432d038 100644 --- a/drivers/media/video/gspca/ov519.c +++ b/drivers/media/video/gspca/ov519.c @@ -1314,11 +1314,14 @@ static int ov518_i2c_r(struct sd *sd, __u8 reg) rc = reg_w(sd, R518_I2C_CTL, 0x03); if (rc 0) return rc; + reg_r8(sd, R518_I2C_CTL); /* Initiate 2-byte read cycle */ rc = reg_w(sd, R518_I2C_CTL, 0x05); if (rc 0) return rc; + reg_r8(sd, R518_I2C_CTL); + value = reg_r(sd, R51x_I2C_DATA); PDEBUG(D_USBI, i2c [0x%02X] - 0x%02X, reg, value); return value; -- 1.7.9.2
Re: [bug?] ov519 fails to handle Hercules Deluxe webcam
On Mon, 5 Mar 2012 03:34:30 -0600 Jonathan Nieder jrnie...@gmail.com wrote: To be sure, try the gspca test version from my web site. Skippy, assuming that works (and I expect it would), could you try the attached patch against 2.6.32.y? It works like this: 0. Prerequisites: apt-get install git build-essential 1. Get the kernel, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git [snip] This asks for a lot of job. With the gspca tarball (423Kb), you just need the linux-headers. And it permits further debugging... -- 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: [bug?] ov519 fails to handle Hercules Deluxe webcam
Jean-Francois Moine wrote: Jonathan Nieder jrnie...@gmail.com wrote: To be sure, try the gspca test version from my web site. Skippy, assuming that works (and I expect it would), could you try the attached patch against 2.6.32.y? It works like this: [...] 1. Get the kernel, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git [snip] This asks for a lot of job. Do you mean bandwidth? With the gspca tarball (423Kb), you just need the linux-headers. And it permits further debugging... I expect that this is fixed in 3.x.y already, so I wanted to confirm that that is the only fix needed to get it fixed in 2.6.32.y-longterm as well. Kind regards, 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: [PATCH 1/2] media: tvp5150: Add cropping support.
On Fri, Mar 2, 2012 at 9:35 AM, javier Martin javier.mar...@vista-silicon.com wrote: Hi all, I've been using and testing these patches successfully for a month. Do you have any comments on them? Do you think they are ready to be merged? [PATCH 1/2] media: tvp5150: Add cropping support [PATCH 2/2] media: tvp5150: Add g_mbus_fmt_callback fwiw, +1 for getting these merged. Enrico -- 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: media-dev: Add media devices for EXYNOS5
Hi sylwester, On 03/01/2012 07:44 AM, Sylwester Nawrocki wrote: Hi Sungchun, On 02/15/2012 07:02 AM, Sungchun Kang wrote: Since the EXYNOS5 SoCs have various multimedia IPs such as Gscaler, FIMC-LITE, and MIXER, and so on. Additionally, media controller interface is needed to configure connection between them and to control each IPs. This patch adds support media device for EXYNOS5 SoCs. Actually, there are three media devices such as below diagram which are using media control framework. Since they are not belong to one hardware block, we need to manage it for connecting with each devices. Follwing is detailed list of them: * Gscaler: general scaler Support memory to memory interface Support output interface from memory to display device(LCD, TV) Support capture interface from device(FIMC-LITE, FIMD) to memory * MIPI-CSIS Support interconnection(subdev interface) between devices Is there any difference in s5p/exynos4 and exynos5 MIPI-CSIS devices ? I suspect there isn't and the existing MIPI-CSIS driver can be used for exynos5 too. It is same hardware, and driver is almost identical. But I copied from s5p-fimc directory to exynos directory, because we use media controller framework in each other hardware. - reference from my first mail Surely, you are author of mipi-csis driver in s5p-fimc directory and I re-used most of your code. So, I will not submit mipi-csis driver. * FIMC-LITE Support capture interface from device(Sensor, MIPI-CSIS) to memory Support interconnection(subdev interface) between devices This device is also present on exynos4212/4412 SoCs. Can you tell what's difference between FIMC-LITE on Exynos4 and Exynos5 ? Either we need separate FIMC-LITE drivers or we need a shared one. I'd like to clarify this first. * MIXER Support output interface from memory to device(HDMI) Support interconnection(subdev interface) between devices * FIMD Support framebuffer interface Support subdev interface to display frames sent from Gscaler What about Exynos DRM driver ? Do you have any plans to integrate the V4L2 and the DRM driver ? IMHO DRM is more appropriate for some tasks on display side, like 2D operations, multiple outputs, windows, blending, etc. I don't know about DRM, can you explain to me about it, or let me know mail-thread? * Rotator Support memory to memory interface * m2m-scaler Support only memory to memory interface * And so on... 1) media 0 LCD Output path consists of Gscaler and FIMD(display controller). ++ +--+ | Gscaler-output | -- | FIMD | -- LCD ++ +--+ HDMI Output path consists of Gscaler, Mixer and HDMI. ++ +---+ +--+ | Gscaler-output | -- | MIXER | -- | HDMI | -- TV ++ +---+ +--+ ++ +---+ +---+ +-+ 2) media 1 Camera Capture path consists of MIPI-CSIS, FIMC-LITE and Gscaler ++ +---+ +-+ | Sensor | -- | FIMC-LITE | -- | Gscaler-capture | ++ +---+ +-+ ++ +---+ +---+ +- + | Sensor | -- | MIPI-CSIS | -- | FIMC-LITE | -- | Gscaler- capture | ++ +---+ +---+ +- + Signed-off-by: Sungchun Kangsungchun.k...@samsung.com --- drivers/media/video/exynos/mdev/Kconfig |8 ++ drivers/media/video/exynos/mdev/Makefile |2 + drivers/media/video/exynos/mdev/exynos-mdev.c | 115 ++ include/media/exynos_mc.h | 160 + 4 files changed, 285 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/exynos/mdev/Kconfig create mode 100644 drivers/media/video/exynos/mdev/Makefile create mode 100644 drivers/media/video/exynos/mdev/exynos-mdev.c create mode 100644 include/media/exynos_mc.h diff --git a/drivers/media/video/exynos/mdev/Kconfig b/drivers/media/video/exynos/mdev/Kconfig new file mode 100644 index 000..15134b0 --- /dev/null +++ b/drivers/media/video/exynos/mdev/Kconfig @@ -0,0 +1,8 @@ +config EXYNOS_MEDIA_DEVICE + bool + depends on MEDIA_EXYNOS + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + default y + help + This is a v4l2 driver for exynos media device. diff --git a/drivers/media/video/exynos/mdev/Makefile b/drivers/media/video/exynos/mdev/Makefile new file mode 100644 index 000..175a4bc --- /dev/null +++ b/drivers/media/video/exynos/mdev/Makefile @@ -0,0 +1,2 @@ +mdev-objs := exynos-mdev.o +obj-$(CONFIG_EXYNOS_MEDIA_DEVICE) += mdev.o diff --git
Re: [PATCH v4 04/34] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
Hi Sakari, Thanks for the patch. On Friday 02 March 2012 19:30:12 Sakari Ailus wrote: Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing). VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Except for the ACTIVE name, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Maybe we could discuss this on IRC with Tomasz ? -- 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 v4 06/34] v4l: Check pad number in get try pointer functions
Hi Sakari,
Thanks for the patch.
On Friday 02 March 2012 19:30:14 Sakari Ailus wrote:
Unify functions to get try pointers and validate the pad number accessed by
the user.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/media/v4l2-subdev.h | 30 +-
1 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index bcaf6b8..7e85035 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -565,23 +565,19 @@ struct v4l2_subdev_fh {
container_of(fh, struct v4l2_subdev_fh, vfh)
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
-static inline struct v4l2_mbus_framefmt *
-v4l2_subdev_get_try_format(struct v4l2_subdev_fh *fh, unsigned int pad)
-{
- return fh-pad[pad].try_fmt;
-}
-
-static inline struct v4l2_rect *
-v4l2_subdev_get_try_crop(struct v4l2_subdev_fh *fh, unsigned int pad)
-{
- return fh-pad[pad].try_crop;
-}
-
-static inline struct v4l2_rect *
-v4l2_subdev_get_try_compose(struct v4l2_subdev_fh *fh, unsigned int pad)
-{
- return fh-pad[pad].try_compose;
-}
+#define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)
\
+ static inline struct rtype *\
+ v4l2_subdev_get_try_##fun_name(struct v4l2_subdev_fh *fh, \
+unsigned int pad)\
+ { \
+ BUG_ON(unlikely(pad = vdev_to_v4l2_subdev( \
+ fh-vfh.vdev)-entity.num_pads)); \
+ return fh-pad[pad].field_name;\
+ }
+
+__V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, format, try_fmt)
+__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, crop, try_compose)
+__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, compose, try_compose)
#endif
extern const struct v4l2_file_operations v4l2_subdev_fops;
--
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 v4 08/34] v4l: Add subdev selections documentation: svg and dia files
Hi Sakari, Thanks for the patch. This version is more readable. What about also making the red lines dotted/dashed ? -- 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 v4 15/34] media: Add link_validate() op to check links to the sink pad
Hi Sakari, Thanks for the patch. On Friday 02 March 2012 19:30:23 Sakari Ailus wrote: The purpose of the link_validate() op is to allow an entity driver to ensure that the properties of the pads at the both ends of the link are suitable for starting the pipeline. link_validate is called on sink pads on active links which belong to the active part of the graph. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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 v4 16/34] media: Collect entities that are part of the pipeline before link validation
Hi Sakari,
Thanks for the patch.
On Friday 02 March 2012 19:30:24 Sakari Ailus wrote:
Make information available which entities are part of the pipeline before
link_validate() ops are being called.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/media-entity.c | 23 ---
include/media/media-entity.h |1 +
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d6d0e81..55f66c6 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -220,12 +220,19 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity, struct media_device *mdev = entity-parent;
struct media_entity_graph graph;
struct media_entity *entity_err = entity;
+ struct {
+ struct media_entity *entity;
+ struct media_link *link;
+ } to_validate[MEDIA_ENTITY_ENUM_MAX_DEPTH];
+ int nto_validate = 0;
int ret;
mutex_lock(mdev-graph_mutex);
media_entity_graph_walk_start(graph, entity);
+ pipe-entities = 0;
+
while ((entity = media_entity_graph_walk_next(graph))) {
unsigned int i;
@@ -237,6 +244,8 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity, if (entity-stream_count 1)
continue;
+ pipe-entities |= 1 entity-id;
+
if (!entity-ops || !entity-ops-link_validate)
continue;
@@ -251,12 +260,20 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity, if (link-sink-entity != entity)
continue;
- ret = entity-ops-link_validate(link);
- if (ret 0 ret != -ENOIOCTLCMD)
- goto error;
+ BUG_ON(nto_validate = MEDIA_ENTITY_ENUM_MAX_DEPTH);
+ to_validate[nto_validate].entity = entity;
+ to_validate[nto_validate].link = link;
+ nto_validate++;
}
}
+ for (nto_validate--; nto_validate = 0; nto_validate--) {
+ ret = to_validate[nto_validate].entity-ops-
+ link_validate(to_validate[nto_validate].link);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ goto error;
+ }
+
mutex_unlock(mdev-graph_mutex);
return 0;
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 0c16f51..bbfc8f2 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -27,6 +27,7 @@
#include linux/media.h
struct media_pipeline {
+ u32 entities;
This assume there will be no more than 32 entities. I don't think that's a
safe assumption, especially with ALSA devices. I'm not sure I would put this
in the media controller core just yet.
};
struct media_link {
--
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 v4 18/34] v4l: Implement v4l2_subdev_link_validate()
Hi Sakari, Thanks for the patch. On Friday 02 March 2012 19:30:26 Sakari Ailus wrote: v4l2_subdev_link_validate() is the default op for validating a link. In V4L2 subdev context, it is used to call a pad op which performs the proper link check without much extra work. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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 v4 23/34] omap3isp: Move setting constaints above media_entity_pipeline_start
Hi Sakari, Thanks for the patch. On Friday 02 March 2012 19:30:31 Sakari Ailus wrote: The clock rate for l3_ick is will soon be read during pipeline validation s/is will/will/ ? which is now part of media_entity_pipeline_start(). For that reason we set constraints earlier on. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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 v4 24/34] omap3isp: Assume media_entity_pipeline_start may fail
Hi Sakari,
Thanks for the patch.
On Friday 02 March 2012 19:30:32 Sakari Ailus wrote:
Since media_entity_pipeline_start() now does link validation, it may
actually fail. Perform the error handling.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 53
+-- 1 files changed, 29 insertions(+), 24
deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index b0d541b..f2621bc 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -997,14 +997,16 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) pipe-l3_ick =
clk_get_rate(video-isp-clock[ISP_CLK_L3_ICK]);
pipe-max_rate = pipe-l3_ick;
- media_entity_pipeline_start(video-video.entity, pipe-pipe);
+ ret = media_entity_pipeline_start(video-video.entity, pipe-pipe);
+ if (ret 0)
+ goto err_media_entity_pipeline_start;
/* Verify that the currently configured format matches the output of
* the connected subdev.
*/
ret = isp_video_check_format(video, vfh);
if (ret 0)
- goto error;
+ goto err_isp_video_check_format;
video-bpl_padding = ret;
video-bpl_value = vfh-format.fmt.pix.bytesperline;
@@ -1021,7 +1023,7 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) } else {
if (far_end == NULL) {
ret = -EPIPE;
- goto error;
+ goto err_isp_video_check_format;
}
state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
@@ -1032,7 +1034,7 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) /* Validate the pipeline and update its state. */
ret = isp_video_validate_pipeline(pipe);
if (ret 0)
- goto error;
+ goto err_isp_video_check_format;
pipe-error = false;
@@ -1054,7 +1056,7 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type)
ret = omap3isp_video_queue_streamon(vfh-queue);
if (ret 0)
- goto error;
+ goto err_isp_video_check_format;
/* In sensor-to-memory mode, the stream can be started synchronously
* to the stream on command. In memory-to-memory mode, it will be
@@ -1064,32 +1066,35 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) ret = omap3isp_pipeline_set_stream(pipe,
ISP_PIPELINE_STREAM_CONTINUOUS);
if (ret 0)
- goto error;
+ goto err_omap3isp_set_stream;
spin_lock_irqsave(video-queue-irqlock, flags);
if (list_empty(video-dmaqueue))
video-dmaqueue_flags |= ISP_VIDEO_DMAQUEUE_UNDERRUN;
spin_unlock_irqrestore(video-queue-irqlock, flags);
}
-error:
- if (ret 0) {
- omap3isp_video_queue_streamoff(vfh-queue);
- media_entity_pipeline_stop(video-video.entity);
- if (video-isp-pdata-set_constraints)
- video-isp-pdata-set_constraints(video-isp, false);
- /* The DMA queue must be emptied here, otherwise CCDC interrupts
- * that will get triggered the next time the CCDC is powered up
- * will try to access buffers that might have been freed but
- * still present in the DMA queue. This can easily get triggered
- * if the above omap3isp_pipeline_set_stream() call fails on a
- * system with a free-running sensor.
- */
- INIT_LIST_HEAD(video-dmaqueue);
- video-queue = NULL;
- }
+ video-streaming = 1;
+
+ mutex_unlock(video-stream_lock);
+ return 0;
- if (!ret)
- video-streaming = 1;
+err_omap3isp_set_stream:
+ omap3isp_video_queue_streamoff(vfh-queue);
+err_isp_video_check_format:
+ media_entity_pipeline_stop(video-video.entity);
+err_media_entity_pipeline_start:
Could you please shorten the labels a bit (err_set_stream, err_check_format
and err_pipeline_start for instance) ?
+ if (video-isp-pdata-set_constraints)
+ video-isp-pdata-set_constraints(video-isp, false);
+ /* The DMA queue must be emptied here, otherwise CCDC
+ * interrupts that will get triggered the next time the CCDC
+ * is powered up will try to access buffers that might have
+ * been freed but still present in the DMA queue. This can
+ * easily get triggered if the above
+ * omap3isp_pipeline_set_stream() call fails on a system with
+ * a free-running sensor.
Please reindent the text to the 80 columns limits.
+ */
+ INIT_LIST_HEAD(video-dmaqueue);
+ video-queue =
Re: [PATCH v4 26/34] omap3isp: Add information on external subdev to struct isp_pipeline
Hi Sakari,
Thanks for the patch.
On Friday 02 March 2012 19:30:34 Sakari Ailus wrote:
Add pointer to external subdev, pixel rate of the external subdev and bpp of
the format to struct isp_pipeline.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.h
b/drivers/media/video/omap3isp/ispvideo.h index d91bdb91..b198723 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -102,6 +102,9 @@ struct isp_pipeline {
bool do_propagation; /* of frame number */
bool error;
struct v4l2_fract max_timeperframe;
+ struct v4l2_subdev *external;
+ unsigned int external_rate;
+ int external_bpp;
unsigned int ? :-)
With that change,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
};
#define to_isp_pipeline(__e) \
--
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 v4 29/34] omap3isp: Default link validation for ccp2, csi2, preview and resizer
Hi Sakari, Thanks for the patch. On Friday 02 March 2012 19:30:37 Sakari Ailus wrote: Use default link validation for ccp2, csi2, preview and resizer. On ccp2, csi2 and ccdc we also collect information on external subdevs as one may be connected to those entities. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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 v4 34/34] rm680: Add camera init
Hi Sakari, Thanks for the patch. On Friday 02 March 2012 19:30:42 Sakari Ailus wrote: From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com This currently introduces an extra file to the arch/arm/mach-omap2 directory: board-rm680-camera.c. Keeping the device tree in mind, the context of the file could be represented as static data with one exception: the external clock to the sensor. This external clock is provided by the OMAP 3 SoC and required by the sensor. The issue is that the clock originates from the ISP and not from PRCM block as the other clocks and thus is not supported by the clock framework. Otherwise the sensor driver could just clk_get() and clk_enable() it, just like the regulators and gpios. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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 v4 09/34] v4l: Add subdev selections documentation
Hi Sakari, Thanks for the patch. On Friday 02 March 2012 19:30:17 Sakari Ailus wrote: Add documentation for V4L2 subdev selection API. This changes also experimental V4L2 subdev API so that scaling now works through selection API only. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi [snip] diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml b/Documentation/DocBook/media/v4l/dev-subdev.xml index 0916a73..ef99da1 100644 --- a/Documentation/DocBook/media/v4l/dev-subdev.xml +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml [snip] + paraThe scaling operation changes the size of the image by + scaling it to new dimensions. The scaling ratio isn't specified + explicitly, but is implied from the original and scaled image + sizes. Both sizes are represented by v4l2-rect;./para + + paraScaling support is optional. When supported by a subdev, + the crop rectangle on the subdev's sink pad is scaled to the + size configured using sub-subdev-g-selection; and + constantV4L2_SUBDEV_SEL_COMPOSE_ACTIVE/constant selection + target on the same pad. If the subdev supports scaling but no s/no/not/ (my bad, typo in my previous review) + composing, the top and left values are not used and must always + be set to zero./para s/// (don't copy the text blindly ;-)) [snip] +section + titleOrder of configuration and format propagation/title + + paraInside subdevs, the order of image processing steps will + always be from the sink pad towards the source pad. This is also + reflected in the order in which the configuration must be + performed by the user: the changes made will be propagated to + any subsequent stages. If this behaviour is not desired, the + user must set + constantV4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG/constant flag. This + flag causes that no propagation of the changes are allowed in + any circumstances. This may also cause the accessed rectangle to + be adjusted by the driver, depending on the properties of the + underlying hardware. Some drivers may not support this + flag./para Haven't we agreed that supporting the flag should be mandatory ? + paraThe coordinates to a step always refer to the active size + of the previous step. The exception to this rule is the source + compose rectangle, which refers to the sink compose bounds + rectangle --- if it is supported by the hardware./para [snip] diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml new file mode 100644 index 000..da1cc4f --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml [snip] +section + titleTypes of selection targets/title + + paraThe are two types of selection targets: active and bounds. s/The/There/ + The ACTIVE targets are the targets which configure the hardware. + The BOUNDS target will return a rectangle that contain all + possible ACTIVE rectangles./para +/section -- 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: [RESEND] [PATCH] media: ir-sony-decoder: 15bit function decode fix
Ping Another week's gone by with no response. It's a trivial patch, so can somebody please take a look at it? (or if I'm missing somebody relevant from CC, please add them) Thanks James On 27/02/12 11:53, James Hogan wrote: The raw Sony IR decoder decodes 15bit messages slightly incorrectly. To decode the function number, it shifts the bits right by 7 so that the function is in bits 7:1, masks with 0xFD (0b1101), and does an 8 bit reverse so it ends up in bits 6:0. The mask should be 0xFE to correspond with bits 7:1 (0b1110). The old mask had the effect of dropping the MSB of the function number from bit 6, and leaving the LSB of the device number in bit 7. Signed-off-by: James Hogan james.ho...@imgtec.com --- (note, i don't have a 15bit sony remote to test this with, but i'm pretty confident of it's correctness based on this: http://picprojects.org.uk/projects/sirc/sonysirc.pdf ) drivers/media/rc/ir-sony-decoder.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/rc/ir-sony-decoder.c b/drivers/media/rc/ir-sony-decoder.c index d5e2b50..dab98b3 100644 --- a/drivers/media/rc/ir-sony-decoder.c +++ b/drivers/media/rc/ir-sony-decoder.c @@ -130,7 +130,7 @@ static int ir_sony_decode(struct rc_dev *dev, struct ir_raw_event ev) case 15: device= bitrev8((data-bits 0) 0xFF); subdevice = 0; - function = bitrev8((data-bits 7) 0xFD); + function = bitrev8((data-bits 7) 0xFE); break; case 20: device= bitrev8((data-bits 5) 0xF8); -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Mon, 05 Mar 2012 09:33:18 +0100 Hans de Goede hdego...@redhat.com wrote: I guess that motion is using the JPG compressed frames rather then the i420 like special format these cameras also support, and it looks like we don't reserve enoug space to buffer these frames. To fix this we need to enlarge the size we reserve per frame in the sn9c20x driver, edit sn9c20x.c and search for vga_mode, in that table you will find a factor 4 / 8 (its in there 3 times), change all 3 occurences to 5 / 8 and try again, then 6 / 8, etc. Normally I would be suspicious about SOF / EOF detection when we need such a factor, but the timestamps in your log exactly match 30 fps, so that seems to be fine. And in my experience with the USB bandwidth stuff the sn9c20x does seem to compress less then other JPG cams, so it makes sense that it needs bigger buffers to store the frames too. Hi Hans, The JPEG compression quality of the sn9c20x is 95%. That's why the frames are so big. Then, if the quality is not settable, I wonder why to use the JPEG format. BTW, I wonder also about the SN9C20X_I420: this format asks for a buffer greater than the native image. So, as these webcams are USB 2.0, shouldn't it be simpler to have only Bayer in the driver? -- 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: [PATCH v3 09/10] v4l: Aptina-style sensor PLL support
Hi Andy,
On Sunday 04 March 2012 21:38:54 Andy Walls wrote:
On Sun, 2012-03-04 at 11:20 +0100, Laurent Pinchart wrote:
On Saturday 03 March 2012 12:35:09 Andy Walls wrote:
On Sat, 2012-03-03 at 16:28 +0100, Laurent Pinchart wrote:
Add a generic helper function to compute PLL parameters for PLL found
in
several Aptina sensors.
[snip]
+int aptina_pll_configure(struct device *dev, struct aptina_pll *pll,
+const struct aptina_pll_limits *limits)
+{
+ unsigned int mf_min;
+ unsigned int mf_max;
+ unsigned int p1_min;
+ unsigned int p1_max;
+ unsigned int p1;
+ unsigned int div;
+
+ if (pll-ext_clock limits-ext_clock_min ||
+ pll-ext_clock limits-ext_clock_max) {
+ dev_err(dev, pll: invalid external clock
frequency.\n);
+ return -EINVAL;
+ }
+
+ if (pll-pix_clock limits-pix_clock_max) {
+ dev_err(dev, pll: invalid pixel clock frequency.\n);
+ return -EINVAL;
+ }
+
+ /* Compute the multiplier M and combined N*P1 divisor. */
+ div = gcd(pll-pix_clock, pll-ext_clock);
+ pll-m = pll-pix_clock / div;
+ div = pll-ext_clock / div;
+
+ /* We now have the smallest M and N*P1 values that will result
in
the
+* desired pixel clock frequency, but they might be out of the
valid
+* range. Compute the factor by which we should multiply them
given
+* the following constraints:
+*
+* - minimum/maximum multiplier
+* - minimum/maximum multiplier output clock frequency assuming
the
+* minimum/maximum N value
+* - minimum/maximum combined N*P1 divisor
+*/
+ mf_min = DIV_ROUND_UP(limits-m_min, pll-m);
+ mf_min = max(mf_min, limits-out_clock_min /
+(pll-ext_clock / limits-n_min * pll-m));
+ mf_min = max(mf_min, limits-n_min * limits-p1_min / div);
+ mf_max = limits-m_max / pll-m;
+ mf_max = min(mf_max, limits-out_clock_max /
+ (pll-ext_clock / limits-n_max * pll-m));
+ mf_max = min(mf_max, DIV_ROUND_UP(limits-n_max *
limits-p1_max,
div));
+
+ dev_dbg(dev, pll: mf min %u max %u\n, mf_min, mf_max);
+ if (mf_min mf_max) {
+ dev_err(dev, pll: no valid combined N*P1 divisor.\n);
+ return -EINVAL;
+ }
+
+ /*
+* We're looking for the highest acceptable P1 value
Why the *highest* acceptable post-divide (P1) value?
According to the Aptina datasheets, it is desirable to keep (fEXTCLK / n)
as large as possible within the limits.
OK. I'm looking ath the MT9P031 datasheet now.
The PLL implemented looks like a Classical Digital PLL (DPLL) with
- a Phase/Frequency Detector (PFD) phase detector
- a prescaler (divide by n) of the external reference (ext_clock) in
front of of the PFD
- a post-divider (divide by p1) for dividing the VCO's operating
frequency down (out_clock) for use as an output
- a divider in the feedback loop to multiply (by m) the locked operating
frequency of the VCO compared to the prescaled ext_clock (ext_clock/n)
Aptina's recommendation to keep ext_clock/n as large as possible for
best performance makes sense intuitively: more frequent phase error
measurements probably leads to better phase tracking.
Since
pix_clock = ext_clock / n * m / p1
I guess the objective is really to minimize m/p1 in order to meet the
recommendation.
I agree.
for which a
+* multiplier factor MF exists that fulfills the following
conditions:
+*
+* 1. p1 is in the [p1_min, p1_max] range given by the limits
and is
+*even
+* 2. mf is in the [mf_min, mf_max] range computed above
+* 3. div * mf is a multiple of p1, in order to compute
+* n = div * mf / p1
+* m = pll-m * mf
+* 4. the internal clock frequency, given by ext_clock / n, is
in
the
+*[int_clock_min, int_clock_max] range given by the limits
+* 5. the output clock frequency, given by ext_clock / n * m,
is in
the
+*[out_clock_min, out_clock_max] range given by the limits
+*
So just to make your constrained optimzation problem even more complex:
I would imagine you would get faster PLL lock and less phase noise by
having the VCO operate near its center frequency.
If you think that is a sensible constraint, then that translates to
having the PLL output before post-divide (i.e. ext_clock / n * m), to be
as close as possible to the center frequency of the
RE: [PATCH] media: jpeg: add driver for a version 2.x of jpeg H/W
Hello송영목,
In general I think the v2x support should be designed to require
as little code changes as possible, and they should be related
to pure hardware differences only. Please see comments inline.
The tables (quantization, Huffman) logically contain mostly the
same data both in v3 and v2x and are defined by respective
standards. Only the arrangement of data is slightly different
(bytes vs 4-byte words). Please see comments inline.
On, March 02, 2012 12:47 AM 송영목 wrote:
...
diff --git a/drivers/media/video/s5p-jpeg/jpeg-core.c
b/drivers/media/video/s5p-jpeg/jpeg-core.c
index 1105a87..cf917cd 100644
--- a/drivers/media/video/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/video/s5p-jpeg/jpeg-core.c
...
diff --git a/drivers/media/video/s5p-jpeg/jpeg-hw-v2x.h
...
@@ -0,0 +1,387 @@
...
+
+#define S5P_JPEG_MIN_WIDTH 32
+#define S5P_JPEG_MIN_HEIGHT 32
+#define S5P_JPEG_MAX_WIDTH 8192
+#define S5P_JPEG_MAX_HEIGHT 8192
+#define S5P_JPEG_ENCODE 0
+#define S5P_JPEG_DECODE 1
+#define S5P_JPEG_RAW_IN_565 0
+#define S5P_JPEG_RAW_IN_422 1
+#define S5P_JPEG_SUBSAMPLING_422 0
+#define S5P_JPEG_SUBSAMPLING_420 1
+#define S5P_JPEG_RAW_OUT_422 0
+#define S5P_JPEG_RAW_OUT_420 1
This is a verbatim copy of what is defined in jpeg-hw-common.h
and should not be repeated here. Use jpeg-hw-common.h.
+/* Q-table for JPEG */
+/* ITU standard Q-table */
+static unsigned int ITU_Q_tbl[4][16] = {
+ {
+ 0x01010101, 0x01020303, 0x01010101, 0x01030303, /* Y */
+ 0x01010101, 0x02030303, 0x01010101, 0x03040403,
+ 0x01010203, 0x03050504, 0x01020303, 0x04050605,
+ 0x02030404, 0x05060605, 0x04050505, 0x06050505
+ } , {
+ 0x01010102, 0x05050505, 0x01010103, 0x05050505, /* CbCr */
+ 0x01010503, 0x05050505, 0x02030505, 0x05050505,
+ 0x05050505, 0x05050505, 0x05050505, 0x05050505,
+ 0x05050505, 0x05050505, 0x05050505, 0x05050505
+ } , {
+ 0x05020205, 0x0a161e25, 0x02020307, 0x0c232521, /* Y */
+ 0x0302050a, 0x16222b22, 0x0305090e, 0x1e393326,
+ 0x06091422, 0x2a384431, 0x0a122118, 0x34454b3c,
+ 0x1d283238, 0x44525142, 0x2d3c3e40, 0x4a424441
+ } , {
+ 0x05020205, 0x251e160a, 0x07030202, 0x2125230c, /* CbCr */
+ 0x0a050203, 0x222b2216, 0x0e090503, 0x2633391e,
+ 0x22140906, 0x3144382a, 0x1821120a, 0x3c4b4534,
+ 0x3832281d, 0x42515244, 0x403e3c2d, 0x4144424a
+ }
+};
This array is static so this makes all users of this header file
allocate it. Why not put it into jpeg-v2x.c? (however, see
below for considerations about duplication)
This comment applies to all array definitions of this kind
in this file.
+
+/* ITU Luminace Huffman Table */
+static unsigned int ITU_H_tbl_len_DC_luminance[4] = {
+ 0x01050100, 0x01010101, 0x0001, 0x
+};
This is in fact the same thing as hdctbl0[16] in jpeg v3,
only arranged in 4-byte words. It would be nice if
the same definitions were used in both versions. This applies
to all tables defined here.
+static unsigned int ITU_H_tbl_val_DC_luminance[3] = {
+ 0x03020100, 0x07060504, 0x0b0a0908
+};
The same thing as hdctblg0[12] in jpeg v3.
...
+static unsigned int ITU_H_tbl_val_DC_chrominance[3] = {
+ 0x03020100, 0x07060504, 0x0b0a0908
+};
The same thing as as hdctblg0[12] in jpeg v3 and
ITU_H_tbl_val_DC_luminance[3] in your code.
+
+static unsigned int ITU_H_tbl_len_AC_luminance[4] = {
+ 0x03010200, 0x03040203, 0x04040505, 0x7d01
+};
+
The same thing as hactbl0[16] in jpeg v3.
+static unsigned int ITU_H_tbl_val_AC_luminance[41] = {
+ 0x00030201, 0x12051104, 0x06413121, 0x07615113,
+ 0x32147122, 0x08a19181, 0xc1b14223, 0xf0d15215,
+ 0x72623324, 0x160a0982, 0x1a191817, 0x28272625,
+ 0x35342a29, 0x39383736, 0x4544433a, 0x49484746,
+ 0x5554534a, 0x59585756, 0x6564635a, 0x69686766,
+ 0x7574736a, 0x79787776, 0x8584837a, 0x89888786,
+ 0x9493928a, 0x98979695, 0xa3a29a99, 0xa7a6a5a4,
+ 0xb2aaa9a8, 0xb6b5b4b3, 0xbab9b8b7, 0xc5c4c3c2,
+ 0xc9c8c7c6, 0xd4d3d2ca, 0xd8d7d6d5, 0xe2e1dad9,
+ 0xe6e5e4e3, 0xeae9e8e7, 0xf4f3f2f1, 0xf8f7f6f5,
+ 0xfaf9
+};
+
The same thing as hactblg0[162] in jpeg v3.
...
+
+static inline void jpeg_reset(void __iomem *regs)
+{
+ unsigned long reg;
+
+ reg = readl(regs + S5P_JPEG_CNTL_REG);
+ writel(reg ~S5P_JPEG_SOFT_RESET_HI,
+ regs + S5P_JPEG_CNTL_REG);
+
+ ndelay(10);
Why not use usleep_range?
...
+static inline void jpeg_proc_mode(void __iomem *regs, unsigned long mode)
+{
+ unsigned int reg, m;
+
+ m = S5P_JPEG_DEC_MODE;
+ if (mode == S5P_JPEG_ENCODE)
+ m = S5P_JPEG_ENC_MODE;
+ else
+ m = S5P_JPEG_DEC_MODE;
+
+ reg = readl(regs + S5P_JPEG_CNTL_REG);
+ reg = S5P_JPEG_ENC_DEC_MODE_MASK;
+ reg |= m;
+
+ writel(reg,
Re: [RESEND] [PATCH] media: ir-sony-decoder: 15bit function decode fix
Hi James, On 3/5/2012 5:27 PM, James Hogan wrote: Ping Another week's gone by with no response. It's a trivial patch, so can somebody please take a look at it? (or if I'm missing somebody relevant from CC, please add them) You are not alone, GPIO IR patch is also in waiting mode... ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi, On 03/05/2012 01:03 PM, Jean-Francois Moine wrote: On Mon, 05 Mar 2012 09:33:18 +0100 Hans de Goedehdego...@redhat.com wrote: I guess that motion is using the JPG compressed frames rather then the i420 like special format these cameras also support, and it looks like we don't reserve enoug space to buffer these frames. To fix this we need to enlarge the size we reserve per frame in the sn9c20x driver, edit sn9c20x.c and search for vga_mode, in that table you will find a factor 4 / 8 (its in there 3 times), change all 3 occurences to 5 / 8 and try again, then 6 / 8, etc. Normally I would be suspicious about SOF / EOF detection when we need such a factor, but the timestamps in your log exactly match 30 fps, so that seems to be fine. And in my experience with the USB bandwidth stuff the sn9c20x does seem to compress less then other JPG cams, so it makes sense that it needs bigger buffers to store the frames too. Hi Hans, The JPEG compression quality of the sn9c20x is 95%. That's why the frames are so big. Then, if the quality is not settable, I wonder why to use the JPEG format. I think the quality is settable, and we are just not setting it to a very useful value. I'm afraid I don't have time to work on this atm, but if you are willing to take a shot at this, then I can test (I've such a camera). I'll send you a private mail with info on how to set the compression ratio. BTW, I wonder also about the SN9C20X_I420: this format asks for a buffer greater than the native image. Yes, but then the data is ready to use, since most apps actuall want i420, where as raw bayer needs a lot of CPU intensive processing before we get useful data out of it. 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
[PATCH] make mmap logs more readable.
From: Oleksij Rempel (Alexey Fisher) bug-tr...@fisher-privat.net
Signed-off-by: Oleksij Rempel (Alexey Fisher) bug-tr...@fisher-privat.net
---
lib/libv4l2/libv4l2.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 8dd01ba..f17fa45 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -1533,7 +1533,7 @@ void *v4l2_mmap(void *start, size_t length, int prot, int
flags, int fd,
start || length != V4L2_FRAME_BUF_SIZE ||
((unsigned int)offset ~0xFFu) !=
V4L2_MMAP_OFFSET_MAGIC) {
if (index != -1)
- V4L2_LOG(Passing mmap(%p, %d, ..., %x, through to the
driver\n,
+ V4L2_LOG(Passing mmap(start: %p, length: %d, offset:
%x) through to the driver\n,
start, (int)length, (int)offset);
if (offset ((1 MMAP2_PAGE_SHIFT) - 1)) {
@@ -1576,8 +1576,8 @@ void *v4l2_mmap(void *start, size_t length, int prot, int
flags, int fd,
result = devices[index].convert_mmap_buf +
buffer_index * V4L2_FRAME_BUF_SIZE;
- V4L2_LOG(Fake (conversion) mmap buf %u, seen by app at: %p\n,
- buffer_index, result);
+ V4L2_LOG(Fake (conversion) mmap buf %u, seen by app at: %p, length:
%d\n,
+ buffer_index, result, (int)length);
leave:
pthread_mutex_unlock(devices[index].stream_lock);
@@ -1620,13 +1620,13 @@ int v4l2_munmap(void *_start, size_t length)
pthread_mutex_unlock(devices[index].stream_lock);
if (unmapped) {
- V4L2_LOG(v4l2 fake buffer munmap %p, %d\n,
start, (int)length);
+ V4L2_LOG(v4l2 fake buffer munmap %p, length:
%d\n, start, (int)length);
return 0;
}
}
}
- V4L2_LOG(v4l2 unknown munmap %p, %d\n, start, (int)length);
+ V4L2_LOG(v4l2 unknown munmap %p, length: %d\n, start, (int)length);
return SYS_MUNMAP(_start, length);
}
--
1.7.9
--
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]NEXT:drivers:staging:media Fix comments and some typos in staging/media/*
From: Justin P. Mattock justinmatt...@gmail.com
linux-next:
I like to spend some time reading code, in doing so I have found some typos in
some of the comments.
The patch below fixes what I have found.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
drivers/staging/media/Kconfig |2 +-
drivers/staging/media/as102/as102_drv.c|2 +-
drivers/staging/media/as102/as102_fe.c |4 ++--
drivers/staging/media/go7007/go7007-v4l2.c |8
drivers/staging/media/lirc/lirc_serial.c |2 +-
drivers/staging/media/solo6x10/Kconfig |2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index 7e5caa3..4f4b7d6 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -6,7 +6,7 @@ menuconfig STAGING_MEDIA
don't have the normal Linux kernel quality level.
Most of them don't follow properly the V4L, DVB and/or RC API's,
so, they won't likely work fine with the existing applications.
- That also means that, one fixed, their API's will change to match
+ That also means that, once fixed, their API's will change to match
the existing ones.
If you wish to work on these drivers, to help improve them, or
diff --git a/drivers/staging/media/as102/as102_drv.c
b/drivers/staging/media/as102/as102_drv.c
index aae0505..ea4f992 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -27,7 +27,7 @@
#include linux/uaccess.h
#include linux/usb.h
-/* header file for Usb device driver*/
+/* header file for usb device driver*/
#include as102_drv.h
#include as102_fw.h
#include dvbdev.h
diff --git a/drivers/staging/media/as102/as102_fe.c
b/drivers/staging/media/as102/as102_fe.c
index bdc5a38..57daa8c 100644
--- a/drivers/staging/media/as102/as102_fe.c
+++ b/drivers/staging/media/as102/as102_fe.c
@@ -337,7 +337,7 @@ int as102_dvb_register_fe(struct as102_dev_t *as102_dev,
strncpy(dvb_fe-ops.info.name, as102_dev-name,
sizeof(dvb_fe-ops.info.name));
- /* register dbvb frontend */
+ /* register dvb frontend */
errno = dvb_register_frontend(dvb_adap, dvb_fe);
if (errno == 0)
dvb_fe-tuner_priv = as102_dev;
@@ -349,7 +349,7 @@ static void as10x_fe_copy_tps_parameters(struct
dtv_frontend_properties *fe_tps,
struct as10x_tps *as10x_tps)
{
- /* extract consteallation */
+ /* extract constellation */
switch (as10x_tps-modulation) {
case CONST_QPSK:
fe_tps-modulation = QPSK;
diff --git a/drivers/staging/media/go7007/go7007-v4l2.c
b/drivers/staging/media/go7007/go7007-v4l2.c
index 2b27d8d..8054378 100644
--- a/drivers/staging/media/go7007/go7007-v4l2.c
+++ b/drivers/staging/media/go7007/go7007-v4l2.c
@@ -1050,15 +1050,15 @@ static int vidioc_s_parm(struct file *filp, void *priv,
return 0;
}
-/* VIDIOC_ENUMSTD on go7007 were used for enumberating the supported fps and
+/* VIDIOC_ENUMSTD on go7007 were used for enumerating the supported fps and
its resolution, when the device is not connected to TV.
- This were an API abuse, probably used by the lack of specific IOCTL's to
- enumberate it, by the time the driver were written.
+ This is were an API abuse, probably used by the lack of specific IOCTL's to
+ enumerate it, by the time the driver was written.
However, since kernel 2.6.19, two new ioctls (VIDIOC_ENUM_FRAMEINTERVALS
and VIDIOC_ENUM_FRAMESIZES) were added for this purpose.
- The two functions bellow implements the newer ioctls
+ The two functions bellow implement the newer ioctls
*/
static int vidioc_enum_framesizes(struct file *filp, void *priv,
struct v4l2_frmsizeenum *fsize)
diff --git a/drivers/staging/media/lirc/lirc_serial.c
b/drivers/staging/media/lirc/lirc_serial.c
index 8dd8897..97352cf 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -1282,7 +1282,7 @@ MODULE_PARM_DESC(iommap, physical base for memory mapped
I/O
/*
* some architectures (e.g. intel xscale) align the 8bit serial registers
* on 32bit word boundaries.
- * See linux-kernel/serial/8250.c serial_in()/out()
+ * See linux-kernel/drivers/tty/serial/8250/8250.c serial_in()/out()
*/
module_param(ioshift, int, S_IRUGO);
MODULE_PARM_DESC(ioshift, shift I/O register offset (0 = no shift));
diff --git a/drivers/staging/media/solo6x10/Kconfig
b/drivers/staging/media/solo6x10/Kconfig
index 03dcac4..63352de 100644
--- a/drivers/staging/media/solo6x10/Kconfig
+++ b/drivers/staging/media/solo6x10/Kconfig
@@ -5,4 +5,4 @@ config SOLO6X10
select SND_PCM
---help---
This driver supports the Softlogic based MPEG-4 and h.264 codec
- codec cards.
+ cards.
--
1.7.5.4
--
To
Re: [PATCH 3/3] wl128x: Add sysfs based support for FM features
On Fri, Mar 2, 2012 at 3:22 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Wednesday, February 29, 2012 18:19:27 halli manjunatha wrote: On Wed, Feb 29, 2012 at 5:25 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday, February 28, 2012 23:52:21 halli manjunatha wrote: On Tue, Feb 28, 2012 at 4:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, February 27, 2012 17:29:18 halli manjunatha wrote: Hi Hans, Agreed I don't mind to create new controls for below things 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RDS AF turn ON/OFF 3) FM RX RSSI level set/get 4) FM TX Alternate Frequency set/get 5) FM RX De-Emphasis mode set/get However, previously you have suggested me to hide few controls (like band selection) from the user but few of our application wanted controls like above and that is why I have created the sysfs entries. Please suggest me how can I move forward with new controls or with sysfs? The first question is which of these controls are general to FM receivers or transmitters, and which are specific to this chipset. The chipset specific controls should be private controls (look at V4L2_CID_MPEG_CX2341X_BASE in videodev2.h how those are defined). The others should be defined as new controls of the FM_TX class or the FM_RX class. The FM_RX class should be defined as a new class as it doesn't exist at the moment. Don't forget to document these controls clearly. With regards to the band selection: I remember that there was a discussion, but not the details. Do you have a link to that discussion? I can't find it (at least not quickly :-) ). Below features are generic to all FM receivers so we can add new CID's for below features 1) FM RX RDS AF turn ON/OFF 2) FM TX Alternate Frequency set/get About other 3 features its different issue, 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RSSI level set/get 3) FM RX De-Emphasis mode set/get All these 3 features are generic to any FM receiver, only question is does all FM receivers wants to expose these controls to application writer? Good question, and there is no good answer at the moment. See e.g. this IRC discussion: http://www.spinics.net/lists/linux-media/msg44023.html In the absence of a good solution to this problem I am inclined to make these controls driver specific but marked experimental. The experimental tag allows us to eventually make it a generic control without too much hassle. Agreed, I will make them driver specific and mark them as experimental. Example Band selection, every FM receiver at the minimum supports both Europe and Japan band, now the question is should we add a CID to switch between these two bands? If we decide to add a band selection control, then that would be a menu control (since there are up to three bands) and it would only be implemented by drivers that need it. What I am still not clear on is *why* you would want this control. What is the reason your customers want this? What does it allow you to do that can't be done today? There are 2 reasons for this, First, our chip supports weather band, unlike other bands (Europe, Japan and Russian) user may wants to switch to weather band and wants to listen to weather report and again switches back to normal band. OK, that makes sense. Are the RX and TX independent with regards to band selection? Yes - RX and TX are independent of band selection Make sure that when the band is changed the rangelow and rangehigh values are also changed. If the current frequency is out of that range, then the frequency should be clamped to the closest value frequency. Although an alternative strategy might be to remember the last used frequency for each band. That might make more sense in the case of switching between a normal band and the weather band. We need to define and document which strategy should be used here. As of now when I switch to new band I just set the frequency to lowest of the new band. In this way user can seek and tune to what ever channel he wants. BTW, is the receiver for the weather band implemented as a separate receiver? I read that some devices can listen to the normal band and interrupt that when a weather report is broadcast on the weather band. That implies two receivers and it would require a rethink. Also, is this feature really implemented as separate frequency ranges in hardware? Or is the receiver able to receive on the whole range of frequencies from 65.8 (OIRT) to approx. 165 (weather band range)? Our chip wont have 2 receivers, it has only 1 receiver which can receive on whole frequency range from 65 MHz to 165 MHz. Is the datasheet of this device available somewhere? Sorry our newest chipset supports this feature so yet now we don't have any datasheet available on
Re: [PATCH] media: s5p-tv: support mc framework
Hi Jiun Yu, Thanks for proposing this patch. I was considering moving V4L2 TV drivers to Media Controller framework. I am glad that this patch was posted. However, there are still some important issues. Please refer to the comments below. On 02/29/2012 12:03 PM, Jiun Yu wrote: From: Jiun Yujiun...@samsung.com Samsung Exynos tv subsystem is composed of video processor, mixer, HDMI Tx and analog TV. Each h/w IP becomes a entity and also inputs of video and graphic layers become entities in media controller framework like below figure. +-+-+ +-+--+-+ +-++-+ | mxr-vd-grp0 |0| |0| mxr-sd-grp0 |1| | || | +-+-+ +-+--+-+ |0|| | +-+-+ | || | |0| hdmi-sd | +-+-+ +-+--+-+ +-+| | +-+-+ | mxr-vd-grp1 |0| |0| mxr-sd-grp1 |1| | || | +-+-+ +-+--+-+ |1| mxr-sd-blender |3| | || | +-+--+-+ +-+| | +-+-+ |0| mxr-sd-video |1| | || | |0| sdo-sd | +-+--+-+ |2|| | +-+-+ | || | +-++-+ What is the purpose for separating mxr-vd-* from mxr-sd-*. There is no additional HW chip hidden behind mxr-sd-* subdev. Using mxr-sd-video is rational because this subdev refers to VideoProcessor. This chip may makes use of its controls like brightness/contrast adjustment or image filtering. But why mxr-sd-video is not connected to any video node? What do you think about following topology: +-+--+-+ +-++-+ |0| mxr-vd-grp0 |1| | || | +-+--+-+ |0|| | +-+-+ | || | |0| hdmi-sd | +-+--+-+ +-+| | +-+-+ |0| mxr-vd-grp1 |1| | || | +-+--+-+ |1| mxr-sd-blender |3| | || | +-+-+ +-+--+-+ +-+| | +-+-+ | mxr-vd-video|0| |0| mxr-sd-vp |1| | || | |0| sdo-sd | +-+-+ +-+--+-+ |2|| | +-+-+ | || | +-++-+ It is much simpler because if contains 4 subdevs instead of 6 and allows to use every data sink as video node. * mxr-vd-grp0 video device type entity input of graphic0 layer * mxr-vd-grp1 video device type entity input of graphic1 layer * mxr-sd-grp0 sub-device type entity graphic0 layer part of mixer * mxr-sd-grp1 sub-device type entity graphic1 layer part of mixer * mxr-sd-video sub-device type entity video layer part of mixer I prefer to call it mxr-sd-vp (Video Processor). * mxr-sd-blender sub-device type entity blender part of mixer Would it be better to use name 'mxr-sd-mixer' instead of 'mxr-sd-blender'? The chip is called 'Mixer. The 'Blender' is some internal subblock of Mixer. * hdmi-sd sub-device type entity hdmi tx In future we should consider adding entities like HDMIPHY and MHL to MC topology. For now let HDMI driver deal with its slave devices. * sdo-sd sub-device type entity analog TV-out Signed-off-by: Jiun Yujiun...@samsung.com --- drivers/media/video/s5p-tv/hdmi_drv.c| 77 - drivers/media/video/s5p-tv/mixer.h | 52 ++ drivers/media/video/s5p-tv/mixer_drv.c | 224 ++ drivers/media/video/s5p-tv/mixer_grp_layer.c |2 +- drivers/media/video/s5p-tv/mixer_video.c | 127 --- drivers/media/video/s5p-tv/sdo_drv.c | 75 - 6 files changed, 478 insertions(+), 79 deletions(-) diff --git a/drivers/media/video/s5p-tv/hdmi_drv.c b/drivers/media/video/s5p-tv/hdmi_drv.c index 8b41a04..4c3cb7b 100644 --- a/drivers/media/video/s5p-tv/hdmi_drv.c +++ b/drivers/media/video/s5p-tv/hdmi_drv.c @@ -33,6 +33,8 @@
Re: [RESEND] [PATCH] media: ir-sony-decoder: 15bit function decode fix
Em 05-03-2012 11:32, Trilok Soni escreveu: Hi James, On 3/5/2012 5:27 PM, James Hogan wrote: Ping Another week's gone by with no response. It's a trivial patch, so can somebody please take a look at it? (or if I'm missing somebody relevant from CC, please add them) You are not alone, GPIO IR patch is also in waiting mode... Unfortunately, I'm very busy those days, testing a big patch series that it is re-writing one subsystem on several machines. Due to that, I had to reduce the timeslot for patch review. If your patches are at patchwork.linuxtv.org, you shouldn't worry... the patches are on my queue ;) I'll review them in time for 3.4. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media_build: fix snd_aci_* undefined warnings on kernels 2.6.33
WARNING: snd_aci_get_aci [/media/linux-common/experiment/media_build/v4l/radio-miropcm20.ko] undefined! WARNING: snd_aci_cmd [/media/linux-common/experiment/media_build/v4l/radio-miropcm20.ko] undefined! due to to the radio-miropcm20 module requiring sound/aci.h introduced in 2.6.33 Signed-off-by: Gianluca Gennari gennar...@gmail.com --- v4l/versions.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/v4l/versions.txt b/v4l/versions.txt index ff103bf..ad2ef2f 100644 --- a/v4l/versions.txt +++ b/v4l/versions.txt @@ -41,6 +41,8 @@ VIDEO_DT3155 [2.6.33] VIDEO_AK881X V4L2_MEM2MEM_DEV +# Requires sound/aci.h introduced in 2.6.33 +RADIO_MIROPCM20 [2.6.32] # These rely on arch support that wasn't available until 2.6.32 -- 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
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Mon, 5 Mar 2012 08:58:30 +1100 Xavion xavio...@gmail.com wrote: I can confirm that GSPCA v2.15.1 removes the bad pixels when I use Cheese or VLC. However, I'm sorry to report that the Motion problems unfortunately still remain. Is there something else I must do to overcome the below errors? I'm happy to keep testing newer GSPCA versions for you until we get this fixed. Hi again, I looked at the driver again, and thanks to Hans, I found you could easily lower the JPEG compression quality and stop buffer overflow. At line 2093 of build/sn9c20x.c (gspca test), there is: sd-quality = 95; Changing '95' to '80' should be enough. I will add this parameter as a video control as soon as it will be standard. Then you could adjust it with an external program as v4l2ucp. -- 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: [PATCH]NEXT:drivers:staging:media Fix comments and some typos in staging/media/*
On 03/05/2012 09:28 AM, David Santinoli wrote: On Mon, Mar 05, 2012 at 07:49:26AM -0800, Justin P. Mattock wrote: - The two functions bellow implements the newer ioctls + The two functions bellow implement the newer ioctls There's still some room for improvement here. :-) Cheers, David I can change bellow to below but is this intentional? i.e. a loud noise from the newer ioctl or something. Justin P. Mattock -- 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]NEXT:drivers:staging:media Fix comments and some typos in staging/media/*
On Mon, Mar 05, 2012 at 07:49:26AM -0800, Justin P. Mattock wrote: - The two functions bellow implements the newer ioctls + The two functions bellow implement the newer ioctls There's still some room for improvement here. :-) Cheers, 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: [Linaro-mm-sig] [PATCH 3/3] dma_buf: Add documentation for the new cpu access support
On Fri, Mar 2, 2012 at 6:23 PM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Daniel, Thanks for the patch. On Thu, Mar 01, 2012 at 04:36:01PM +0100, Daniel Vetter wrote: Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- Documentation/dma-buf-sharing.txt | 102 +++- 1 files changed, 99 insertions(+), 3 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 225f96d..f12542b 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -32,8 +32,12 @@ The buffer-user *IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details] For this first version, A buffer shared using the dma_buf sharing API: - *may* be exported to user space using mmap *ONLY* by exporter, outside of - this framework. -- may be used *ONLY* by importers that do not need CPU access to the buffer. + this framework. +- with this new iteration of the dma-buf api cpu access from the kernel has been + enable, see below for the details. + +dma-buf operations for device dma only +-- The dma_buf buffer sharing API usage contains the following steps: @@ -219,7 +223,99 @@ NOTES: If the exporter chooses not to allow an attach() operation once a map_dma_buf() API has been called, it simply returns an error. -Miscellaneous notes: +Kernel cpu access to a dma-buf buffer object + + +The motivation to allow cpu access from the kernel to a dma-buf object from the +importers side are: +- fallback operations, e.g. if the devices is connected to a usb bus and the + kernel needs to shuffle the data around first before sending it away. +- full transperancy for existing users on the importer side, i.e. userspace + should not notice the difference between a normal object from that subsystem + and an imported one backed by a dma-buf. This is really important for drm + opengl drivers that expect to still use all the existing upload/download + paths. + +Access to a dma_buf from the kernel context involves three steps: + +1. Prepare access, which invalidate any necessary caches and make the object + available for cpu access. +2. Access the object page-by-page with the dma_buf map apis +3. Finish access, which will flush any necessary cpu caches and free reserved + resources. Where it should be decided which operations are being done to the buffer when it is passed to user space and back to kernel space? How about spliting these operations to those done on the first time the buffer is passed to the user space (mapping to kernel address space, for example) and those required every time buffer is passed from kernel to user and back (cache flusing)? I'm asking since any unnecessary time-consuming operations, especially as heavy as mapping the buffer, should be avoidable in subsystems dealing with streaming video, cameras etc., i.e. non-GPU users. Well, this is really something for the buffer exporter to deal with.. since there is no way for an importer to create a userspace mmap'ing of the buffer. A lot of these expensive operations go away if you don't even create a userspace virtual mapping in the first place ;-) BR, -R +1. Prepare acces + + Before an importer can acces a dma_buf object with the cpu from the kernel + context, it needs to notice the exporter of the access that is about to + happen. + + Interface: + int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, + size_t start, size_t len, + enum dma_data_direction direction) + + This allows the exporter to ensure that the memory is actually available for + cpu access - the exporter might need to allocate or swap-in and pin the + backing storage. The exporter also needs to ensure that cpu access is + coherent for the given range and access direction. The range and access + direction can be used by the exporter to optimize the cache flushing, i.e. + access outside of the range or with a different direction (read instead of + write) might return stale or even bogus data (e.g. when the exporter needs to + copy the data to temporaray storage). + + This step might fail, e.g. in oom conditions. + +2. Accessing the buffer + + To support dma_buf objects residing in highmem cpu access is page-based using + an api similar to kmap. Accessing a dma_buf is done in aligned chunks of + PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which returns + a pointer in kernel virtual address space. Afterwards the chunk needs to be + unmapped again. There is no limit on how often a given chunk can be mapped + and unmmapped, i.e. the importer does not need to call begin_cpu_access again + before mapping the same chunk again. + + Interfaces: + void
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:Mon Mar 5 19:00:17 CET 2012 git hash:e8ca6d20a65d9d94693a0ed99b12d95b882dc859 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: 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-rc1-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-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
Re: [PATCH 2/3] dma-buf: add support for kernel cpu access
On Fri, Mar 2, 2012 at 23:24, Rob Clark robdcl...@gmail.com wrote: Perhaps we should check somewhere for required dmabuf ops fxns (like kmap_atomic here), rather than just calling unconditionally what might be a null ptr. At least put it in the WARN_ON(), but it might be nicer to catch a missing required fxns at export time, rather than waiting for an importer to try and call it. Less likely that way, for newly added required functions go unnoticed. (same comment applies below for the non-atomic variant.. and possibly some other existing dmabuf ops) Agreed, I'll rework the patch to do that when rebasing onto Sumit's latest tree. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
DVB-T initial scan file es-Huesca
Hello, here comes attached an update for the initial DVB-T scan file es-Huesca. Kind regards, Vicente. # DVB-T Huesca (Aragon) [Spain] [es-Huesca] # Generated by Vicente Hernando Ara bizen...@gmail.com # T[2] [plp_id] [system_id] freq bw fec_hi fec_lo mod tm guard hi [# comment] #-- T 65000 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 43 HTV-HuescaTelevision T 65800 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 44 La Sexta 2 T 66600 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 45 TVE HD T 69000 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 48 NITRO T 73800 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 54 BOING T 76200 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 57 ARAGON TV T 79400 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 61 TVE T 84200 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 67 T 85000 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 68 T 85800 8MHz 2/3 NONEQAM64 8k 1/4 NONE # CH 69
Re: [RESEND] [PATCH] media: ir-sony-decoder: 15bit function decode fix
On 5 March 2012 17:17, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 05-03-2012 11:32, Trilok Soni escreveu: Hi James, On 3/5/2012 5:27 PM, James Hogan wrote: Ping Another week's gone by with no response. It's a trivial patch, so can somebody please take a look at it? (or if I'm missing somebody relevant from CC, please add them) You are not alone, GPIO IR patch is also in waiting mode... Unfortunately, I'm very busy those days, testing a big patch series that it is re-writing one subsystem on several machines. Due to that, I had to reduce the timeslot for patch review. If your patches are at patchwork.linuxtv.org, you shouldn't worry... the patches are on my queue ;) I'll review them in time for 3.4. Okay no problem, sorry for nagging :) Thanks James -- 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] dvb: Buffer Overfolow in cx24110_set_fec
Can anyone comment on it ?
Is FEC_AUTO should be moved up as shown below ?
typedef enum fe_code_rate {
FEC_6_7,
,// Should FEC_AUTO, be placed here ?
FEC_7_8,
FEC_8_9,
, // At present FEC_AUTO is here
.
} fe_code_rate_t;
OR
Should rate[fec], g1[fec],and g2[fec] be initialized for
FEC_6_7 fec FEC_AUTO ??
If yes, what should be the initial values ?
Regards
Santosh
On Sun, Mar 4, 2012 at 7:11 PM, santosh prasad nayak
santoshprasadna...@gmail.com wrote:
Hi,
I am getting following error:
drivers/media/dvb/frontends/cx24110.c:210 cx24110_set_fec() error:
buffer overflow 'rate' 7 = 8
In cx24110_set_fec, arrays rate[] , g1[], g2[] have only 7 values.
typedef enum fe_code_rate {
FEC_6_7, // index 7
FEC_7_8, // index 8
FEC_8_9,
FEC_AUTO,
.
} fe_code_rate_t;
For FEC_6_7 fec FEC_AUTO , rate[fec]. g1[fec], g2[fec]
values are not defined initially.
Is it expected or bug ?
regards
Santosh
--
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 2/2] Driver: video: Use the macro DMA_BIT_MASK().
Can you please comment on it ?
Regards
Santosh
On Tue, Feb 21, 2012 at 3:43 PM, santosh nayak
santoshprasadna...@gmail.com wrote:
From: Santosh Nayak santoshprasadna...@gmail.com
Use the macro DMA_BIT_MASK instead of the constant 0x.
Signed-off-by: Santosh Nayak santoshprasadna...@gmail.com
---
drivers/media/video/cx18/cx18-driver.c | 4 ++--
drivers/media/video/ivtv/ivtv-driver.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index 349bd9c..08118e5 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -38,7 +38,7 @@
#include cx18-ioctl.h
#include cx18-controls.h
#include tuner-xc2028.h
-
+#include linux/dma-mapping.h
#include media/tveeprom.h
/* If you have already X v4l cards, then set this to X. This way
@@ -812,7 +812,7 @@ static int cx18_setup_pci(struct cx18 *cx, struct pci_dev
*pci_dev,
CX18_ERR(Can't enable device %d!\n, cx-instance);
return -EIO;
}
- if (pci_set_dma_mask(pci_dev, 0x)) {
+ if (pci_set_dma_mask(pci_dev, DMA_BIT_MASK(32))) {
CX18_ERR(No suitable DMA available, card %d\n, cx-instance);
return -EIO;
}
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 107e9e6..d84e5df 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -55,7 +55,7 @@
#include ivtv-routing.h
#include ivtv-controls.h
#include ivtv-gpio.h
-
+#include linux/dma-mapping.h
#include media/tveeprom.h
#include media/saa7115.h
#include media/v4l2-chip-ident.h
@@ -813,7 +813,7 @@ static int ivtv_setup_pci(struct ivtv *itv, struct
pci_dev *pdev,
IVTV_ERR(Can't enable device!\n);
return -EIO;
}
- if (pci_set_dma_mask(pdev, 0x)) {
+ if (pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
IVTV_ERR(No suitable DMA available.\n);
return -EIO;
}
--
1.7.4.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/2] radio-isa: PnP support for the new ISA radio framework
Add PnP support to the new ISA radio framework.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
diff --git a/drivers/media/radio/radio-isa.c b/drivers/media/radio/radio-isa.c
index 02bcead..b0c0d7a 100644
--- a/drivers/media/radio/radio-isa.c
+++ b/drivers/media/radio/radio-isa.c
@@ -26,6 +26,7 @@
#include linux/delay.h
#include linux/videodev2.h
#include linux/io.h
+#include linux/slab.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-fh.h
@@ -198,56 +199,31 @@ static bool radio_isa_valid_io(const struct
radio_isa_driver *drv, int io)
return false;
}
-int radio_isa_probe(struct device *pdev, unsigned int dev)
+struct radio_isa_card *radio_isa_alloc(struct radio_isa_driver *drv,
+ struct device *pdev)
{
- struct radio_isa_driver *drv = pdev-platform_data;
- const struct radio_isa_ops *ops = drv-ops;
struct v4l2_device *v4l2_dev;
- struct radio_isa_card *isa;
- int res;
+ struct radio_isa_card *isa = drv-ops-alloc();
+ if (!isa)
+ return NULL;
- isa = drv-ops-alloc();
- if (isa == NULL)
- return -ENOMEM;
dev_set_drvdata(pdev, isa);
isa-drv = drv;
- isa-io = drv-io_params[dev];
v4l2_dev = isa-v4l2_dev;
strlcpy(v4l2_dev-name, dev_name(pdev), sizeof(v4l2_dev-name));
- if (drv-probe ops-probe) {
- int i;
-
- for (i = 0; i drv-num_of_io_ports; ++i) {
- int io = drv-io_ports[i];
-
- if (request_region(io, drv-region_size,
v4l2_dev-name)) {
- bool found = ops-probe(isa, io);
-
- release_region(io, drv-region_size);
- if (found) {
- isa-io = io;
- break;
- }
- }
- }
- }
-
- if (!radio_isa_valid_io(drv, isa-io)) {
- int i;
+ return isa;
+}
- if (isa-io 0)
- return -ENODEV;
- v4l2_err(v4l2_dev, you must set an I/O address with io=0x%03x,
- drv-io_ports[0]);
- for (i = 1; i drv-num_of_io_ports; i++)
- printk(KERN_CONT /0x%03x, drv-io_ports[i]);
- printk(KERN_CONT .\n);
- kfree(isa);
- return -EINVAL;
- }
+int radio_isa_common_probe(struct radio_isa_card *isa, struct device *pdev,
+ int radio_nr, unsigned region_size)
+{
+ const struct radio_isa_driver *drv = isa-drv;
+ const struct radio_isa_ops *ops = drv-ops;
+ struct v4l2_device *v4l2_dev = isa-v4l2_dev;
+ int res;
- if (!request_region(isa-io, drv-region_size, v4l2_dev-name)) {
+ if (!request_region(isa-io, region_size, v4l2_dev-name)) {
v4l2_err(v4l2_dev, port 0x%x already in use\n, isa-io);
kfree(isa);
return -EBUSY;
@@ -300,8 +276,8 @@ int radio_isa_probe(struct device *pdev, unsigned int dev)
v4l2_err(v4l2_dev, Could not setup card\n);
goto err_node_reg;
}
- res = video_register_device(isa-vdev, VFL_TYPE_RADIO,
- drv-radio_nr_params[dev]);
+ res = video_register_device(isa-vdev, VFL_TYPE_RADIO, radio_nr);
+
if (res 0) {
v4l2_err(v4l2_dev, Could not register device node\n);
goto err_node_reg;
@@ -316,24 +292,110 @@ err_node_reg:
err_hdl:
v4l2_device_unregister(isa-v4l2_dev);
err_dev_reg:
- release_region(isa-io, drv-region_size);
+ release_region(isa-io, region_size);
kfree(isa);
return res;
}
-EXPORT_SYMBOL_GPL(radio_isa_probe);
-int radio_isa_remove(struct device *pdev, unsigned int dev)
+int radio_isa_common_remove(struct radio_isa_card *isa, unsigned region_size)
{
- struct radio_isa_card *isa = dev_get_drvdata(pdev);
const struct radio_isa_ops *ops = isa-drv-ops;
ops-s_mute_volume(isa, true, isa-volume ? isa-volume-cur.val : 0);
video_unregister_device(isa-vdev);
v4l2_ctrl_handler_free(isa-hdl);
v4l2_device_unregister(isa-v4l2_dev);
- release_region(isa-io, isa-drv-region_size);
+ release_region(isa-io, region_size);
v4l2_info(isa-v4l2_dev, Removed radio card %s\n, isa-drv-card);
kfree(isa);
return 0;
}
+
+int radio_isa_probe(struct device *pdev, unsigned int dev)
+{
+ struct radio_isa_driver *drv = pdev-platform_data;
+ const struct radio_isa_ops *ops = drv-ops;
+ struct v4l2_device *v4l2_dev;
+ struct radio_isa_card *isa;
+
+ isa = radio_isa_alloc(drv, pdev);
+ if (!isa)
+ return -ENOMEM;
+ isa-io = drv-io_params[dev];
+
[PATCH 2/2] radio-gemtek: add PnP support for AOpen FX-3D/Pro Radio
Add PnP support to radio-gemtek for AOpen FX-3D/Pro Radio card
(AD1816 + Gemtek radio).
Signed-off-by: Ondrej Zary li...@rainbow-software.org
diff --git a/drivers/media/radio/radio-gemtek.c
b/drivers/media/radio/radio-gemtek.c
index 9d7fdae..6ea0e23 100644
--- a/drivers/media/radio/radio-gemtek.c
+++ b/drivers/media/radio/radio-gemtek.c
@@ -29,6 +29,8 @@
#include linux/videodev2.h /* kernel radio structs */
#include linux/mutex.h
#include linux/io.h /* outb, outb_p */
+#include linux/pnp.h
+#include linux/slab.h
#include media/v4l2-ioctl.h
#include media/v4l2-device.h
#include radio-isa.h
@@ -282,6 +284,16 @@ static const struct radio_isa_ops gemtek_ops = {
static const int gemtek_ioports[] = { 0x20c, 0x30c, 0x24c, 0x34c, 0x248, 0x28c
};
+#ifdef CONFIG_PNP
+static struct pnp_device_id gemtek_pnp_devices[] = {
+ /* AOpen FX-3D/Pro Radio */
+ {.id = ADS7183, .driver_data = 0},
+ {.id = }
+};
+
+MODULE_DEVICE_TABLE(pnp, gemtek_pnp_devices);
+#endif
+
static struct radio_isa_driver gemtek_driver = {
.driver = {
.match = radio_isa_match,
@@ -291,6 +303,14 @@ static struct radio_isa_driver gemtek_driver = {
.name = radio-gemtek,
},
},
+#ifdef CONFIG_PNP
+ .pnp_driver = {
+ .name = radio-gemtek,
+ .id_table = gemtek_pnp_devices,
+ .probe = radio_isa_pnp_probe,
+ .remove = radio_isa_pnp_remove,
+ },
+#endif
.io_params = io,
.radio_nr_params = radio_nr,
.io_ports = gemtek_ioports,
@@ -304,12 +324,14 @@ static struct radio_isa_driver gemtek_driver = {
static int __init gemtek_init(void)
{
gemtek_driver.probe = probe;
+ pnp_register_driver(gemtek_driver.pnp_driver);
return isa_register_driver(gemtek_driver.driver, GEMTEK_MAX);
}
static void __exit gemtek_exit(void)
{
hardmute = 1; /* Turn off PLL */
+ pnp_unregister_driver(gemtek_driver.pnp_driver);
isa_unregister_driver(gemtek_driver.driver);
}
--
Ondrej Zary
--
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] Add CI support to az6007 driver
Jose Alberto Reguero skrev 2012-03-05 00:22: This patch add CI support to az6007 driver. Signed-off-by: Jose Alberto Reguerojaregu...@telefonica.net Since I have this device and have access to a CAM-card and program card to access the encrypted channels(DVB-C) I thought I should try this patch and report my findings. First I have to say that I'm just a user and no developer. After managing to include the patch in media_build I do get this in dmesg when inserting the CAM. [ 395.561886] dvb_ca adapter 2: DVB CAM detected and initialised successfully When scanning I can find my channels. I can watch unencrypted channels without problem even with the CAM inserted. When trying a encrypted channel with gnutv I get this: $ gnutv -adapter 2 -channels my-channels-v4.conf -out file t.mpg -timeout 30 TV3 Using frontend DRXK DVB-C DVB-T, type DVB-C status SCVYL | signal 02c7 | snr 00be | ber | unc 0704 | FE_HAS_LOCK en50221_tl_handle_sb: Received T_SB for connection not in T_STATE_ACTIVE from module on slot 00 en50221_stdcam_llci_poll: Error reported by stack:-7 CAM Application type: 01 CAM Application manufacturer: cafe CAM Manufacturer code: babe CAM Menu string: Conax Conditional Access CAM supports the following ca system ids: 0x0b00 Received new PMT - sending to CAM... And the resulting mpeg file is not watchable with mplayer. Do you want me to test anything? -- 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 v2 1/2] radio-isa: PnP support for the new ISA radio framework
Add PnP support to the new ISA radio framework.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
diff --git a/drivers/media/radio/radio-isa.c b/drivers/media/radio/radio-isa.c
index 02bcead..ed9039f 100644
--- a/drivers/media/radio/radio-isa.c
+++ b/drivers/media/radio/radio-isa.c
@@ -26,6 +26,7 @@
#include linux/delay.h
#include linux/videodev2.h
#include linux/io.h
+#include linux/slab.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-fh.h
@@ -198,56 +199,31 @@ static bool radio_isa_valid_io(const struct
radio_isa_driver *drv, int io)
return false;
}
-int radio_isa_probe(struct device *pdev, unsigned int dev)
+struct radio_isa_card *radio_isa_alloc(struct radio_isa_driver *drv,
+ struct device *pdev)
{
- struct radio_isa_driver *drv = pdev-platform_data;
- const struct radio_isa_ops *ops = drv-ops;
struct v4l2_device *v4l2_dev;
- struct radio_isa_card *isa;
- int res;
+ struct radio_isa_card *isa = drv-ops-alloc();
+ if (!isa)
+ return NULL;
- isa = drv-ops-alloc();
- if (isa == NULL)
- return -ENOMEM;
dev_set_drvdata(pdev, isa);
isa-drv = drv;
- isa-io = drv-io_params[dev];
v4l2_dev = isa-v4l2_dev;
strlcpy(v4l2_dev-name, dev_name(pdev), sizeof(v4l2_dev-name));
- if (drv-probe ops-probe) {
- int i;
-
- for (i = 0; i drv-num_of_io_ports; ++i) {
- int io = drv-io_ports[i];
-
- if (request_region(io, drv-region_size,
v4l2_dev-name)) {
- bool found = ops-probe(isa, io);
-
- release_region(io, drv-region_size);
- if (found) {
- isa-io = io;
- break;
- }
- }
- }
- }
-
- if (!radio_isa_valid_io(drv, isa-io)) {
- int i;
+ return isa;
+}
- if (isa-io 0)
- return -ENODEV;
- v4l2_err(v4l2_dev, you must set an I/O address with io=0x%03x,
- drv-io_ports[0]);
- for (i = 1; i drv-num_of_io_ports; i++)
- printk(KERN_CONT /0x%03x, drv-io_ports[i]);
- printk(KERN_CONT .\n);
- kfree(isa);
- return -EINVAL;
- }
+int radio_isa_common_probe(struct radio_isa_card *isa, struct device *pdev,
+ int radio_nr, unsigned region_size)
+{
+ const struct radio_isa_driver *drv = isa-drv;
+ const struct radio_isa_ops *ops = drv-ops;
+ struct v4l2_device *v4l2_dev = isa-v4l2_dev;
+ int res;
- if (!request_region(isa-io, drv-region_size, v4l2_dev-name)) {
+ if (!request_region(isa-io, region_size, v4l2_dev-name)) {
v4l2_err(v4l2_dev, port 0x%x already in use\n, isa-io);
kfree(isa);
return -EBUSY;
@@ -300,8 +276,8 @@ int radio_isa_probe(struct device *pdev, unsigned int dev)
v4l2_err(v4l2_dev, Could not setup card\n);
goto err_node_reg;
}
- res = video_register_device(isa-vdev, VFL_TYPE_RADIO,
- drv-radio_nr_params[dev]);
+ res = video_register_device(isa-vdev, VFL_TYPE_RADIO, radio_nr);
+
if (res 0) {
v4l2_err(v4l2_dev, Could not register device node\n);
goto err_node_reg;
@@ -316,24 +292,110 @@ err_node_reg:
err_hdl:
v4l2_device_unregister(isa-v4l2_dev);
err_dev_reg:
- release_region(isa-io, drv-region_size);
+ release_region(isa-io, region_size);
kfree(isa);
return res;
}
-EXPORT_SYMBOL_GPL(radio_isa_probe);
-int radio_isa_remove(struct device *pdev, unsigned int dev)
+int radio_isa_common_remove(struct radio_isa_card *isa, unsigned region_size)
{
- struct radio_isa_card *isa = dev_get_drvdata(pdev);
const struct radio_isa_ops *ops = isa-drv-ops;
ops-s_mute_volume(isa, true, isa-volume ? isa-volume-cur.val : 0);
video_unregister_device(isa-vdev);
v4l2_ctrl_handler_free(isa-hdl);
v4l2_device_unregister(isa-v4l2_dev);
- release_region(isa-io, isa-drv-region_size);
+ release_region(isa-io, region_size);
v4l2_info(isa-v4l2_dev, Removed radio card %s\n, isa-drv-card);
kfree(isa);
return 0;
}
+
+int radio_isa_probe(struct device *pdev, unsigned int dev)
+{
+ struct radio_isa_driver *drv = pdev-platform_data;
+ const struct radio_isa_ops *ops = drv-ops;
+ struct v4l2_device *v4l2_dev;
+ struct radio_isa_card *isa;
+
+ isa = radio_isa_alloc(drv, pdev);
+ if (!isa)
+ return -ENOMEM;
+ isa-io = drv-io_params[dev];
+
[PATCH v2 2/2] radio-gemtek: add PnP support for AOpen FX-3D/Pro Radio
Add PnP support to radio-gemtek for AOpen FX-3D/Pro Radio card
(AD1816 + Gemtek radio).
Signed-off-by: Ondrej Zary li...@rainbow-software.org
diff --git a/drivers/media/radio/radio-gemtek.c
b/drivers/media/radio/radio-gemtek.c
index 9d7fdae..235c0e3 100644
--- a/drivers/media/radio/radio-gemtek.c
+++ b/drivers/media/radio/radio-gemtek.c
@@ -29,6 +29,8 @@
#include linux/videodev2.h /* kernel radio structs */
#include linux/mutex.h
#include linux/io.h /* outb, outb_p */
+#include linux/pnp.h
+#include linux/slab.h
#include media/v4l2-ioctl.h
#include media/v4l2-device.h
#include radio-isa.h
@@ -282,6 +284,16 @@ static const struct radio_isa_ops gemtek_ops = {
static const int gemtek_ioports[] = { 0x20c, 0x30c, 0x24c, 0x34c, 0x248, 0x28c
};
+#ifdef CONFIG_PNP
+static struct pnp_device_id gemtek_pnp_devices[] = {
+ /* AOpen FX-3D/Pro Radio */
+ {.id = ADS7183, .driver_data = 0},
+ {.id = }
+};
+
+MODULE_DEVICE_TABLE(pnp, gemtek_pnp_devices);
+#endif
+
static struct radio_isa_driver gemtek_driver = {
.driver = {
.match = radio_isa_match,
@@ -291,6 +303,14 @@ static struct radio_isa_driver gemtek_driver = {
.name = radio-gemtek,
},
},
+#ifdef CONFIG_PNP
+ .pnp_driver = {
+ .name = radio-gemtek,
+ .id_table = gemtek_pnp_devices,
+ .probe = radio_isa_pnp_probe,
+ .remove = radio_isa_pnp_remove,
+ },
+#endif
.io_params = io,
.radio_nr_params = radio_nr,
.io_ports = gemtek_ioports,
@@ -304,12 +324,18 @@ static struct radio_isa_driver gemtek_driver = {
static int __init gemtek_init(void)
{
gemtek_driver.probe = probe;
+#ifdef CONFIG_PNP
+ pnp_register_driver(gemtek_driver.pnp_driver);
+#endif
return isa_register_driver(gemtek_driver.driver, GEMTEK_MAX);
}
static void __exit gemtek_exit(void)
{
hardmute = 1; /* Turn off PLL */
+#ifdef CONFIG_PNP
+ pnp_unregister_driver(gemtek_driver.pnp_driver);
+#endif
isa_unregister_driver(gemtek_driver.driver);
}
--
Ondrej Zary
--
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 1/2] radio-isa: PnP support for the new ISA radio framework
On Monday 05 March 2012 21:30:51 Ondrej Zary wrote: Add PnP support to the new ISA radio framework. [...] +int radio_isa_pnp_remove(struct pnp_dev *dev) Please ignore this patch, it's broken (this function should return void and radio-gemtek fails to compile without CONFIG_PNP). I've sent fixed v2 patch. -- Ondrej Zary -- 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: [Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access
On Fri, Mar 2, 2012 at 23:53, Rob Clark rob.cl...@linaro.org wrote: nitially the expectation was that userspace would not pass a buffer to multiple subsystems for writing (or that if it did, it would get the undefined results that one could expect).. so dealing w/ synchronization was punted. Imo synchronization should not be part of the dma_buf core, i.e. userspace needs to ensure that access is synchronized. begin/end_cpu_access are the coherency brackets (like map/unmap for device dma). And if userspace asks for a gun and some bullets, the kernel should just deliver. Even in drm/i915 gem land we don't (and simply can't) make any promises about concurrent reads/writes/ioctls. I expect, though, that one of the next steps is some sort of sync-object mechanism to supplement dmabuf Imo the only reason to add sync objects as explicit things is to make device-to-device sync more efficient by using hw semaphores and signalling lines. Or maybe a quick irq handler in the kernel that kicks of the next device. I don't think we should design these to make userspace simpler. Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 3/3] dma_buf: Add documentation for the new cpu access support
On Sat, Mar 3, 2012 at 01:23, Sakari Ailus sakari.ai...@iki.fi wrote: Where it should be decided which operations are being done to the buffer when it is passed to user space and back to kernel space? How about spliting these operations to those done on the first time the buffer is passed to the user space (mapping to kernel address space, for example) and those required every time buffer is passed from kernel to user and back (cache flusing)? I'm asking since any unnecessary time-consuming operations, especially as heavy as mapping the buffer, should be avoidable in subsystems dealing with streaming video, cameras etc., i.e. non-GPU users. I'm a bit confused about your comments because this interface extension doesn't support userspace mmap. So userspace isn't even part of the picture. Adding mmap support is something entirely different imo, and I have no idea yet how we should handle cache coherency for that. Yours, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [bug?] ov519 fails to handle Hercules Deluxe webcam
Le 05/03/2012 10:34, Jonathan Nieder a écrit : make localmodconfig; # optional: minimize configuration make; # optionally with -jnum for parallel build The compilation failed (see at the end of this email) and I didn't feel like trying to debug it so I went for Jean-François' build, and it seems to work fine (thanks !). HSJean-François, please have a look at http://fr.wikipedia.org/wiki/Casse_%28typographie%29 or http://www.cnrtl.fr/definition/casse (CASSE³) and you may switch back to French… ;-)/HS --- # LANG=en_US.utf8 make localmodconfig HOSTCC scripts/basic/fixdep In file included from /usr/include/sys/socket.h:40, from /usr/include/netinet/in.h:25, from /usr/include/arpa/inet.h:23, from scripts/basic/fixdep.c:116: /usr/include/bits/socket.h:370:24: error: asm/socket.h: No such file or directory make[1]: *** [scripts/basic/fixdep] Error 1 make: *** [scripts_basic] Error 2 # LANG=en_US.utf8 make HOSTCC scripts/basic/fixdep In file included from /usr/include/sys/socket.h:40, from /usr/include/netinet/in.h:25, from /usr/include/arpa/inet.h:23, from scripts/basic/fixdep.c:116: /usr/include/bits/socket.h:370:24: error: asm/socket.h: No such file or directory make[2]: *** [scripts/basic/fixdep] Error 1 make[1]: *** [scripts_basic] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. --- -- 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] Add CI support to az6007 driver
On Lunes, 5 de marzo de 2012 21:42:48 Roger Mårtensson escribió: Jose Alberto Reguero skrev 2012-03-05 00:22: This patch add CI support to az6007 driver. Signed-off-by: Jose Alberto Reguerojaregu...@telefonica.net Since I have this device and have access to a CAM-card and program card to access the encrypted channels(DVB-C) I thought I should try this patch and report my findings. First I have to say that I'm just a user and no developer. After managing to include the patch in media_build I do get this in dmesg when inserting the CAM. [ 395.561886] dvb_ca adapter 2: DVB CAM detected and initialised successfully When scanning I can find my channels. I can watch unencrypted channels without problem even with the CAM inserted. When trying a encrypted channel with gnutv I get this: $ gnutv -adapter 2 -channels my-channels-v4.conf -out file t.mpg -timeout 30 TV3 Using frontend DRXK DVB-C DVB-T, type DVB-C status SCVYL | signal 02c7 | snr 00be | ber | unc 0704 | FE_HAS_LOCK en50221_tl_handle_sb: Received T_SB for connection not in T_STATE_ACTIVE from module on slot 00 en50221_stdcam_llci_poll: Error reported by stack:-7 CAM Application type: 01 CAM Application manufacturer: cafe CAM Manufacturer code: babe CAM Menu string: Conax Conditional Access CAM supports the following ca system ids: 0x0b00 Received new PMT - sending to CAM... And the resulting mpeg file is not watchable with mplayer. Do you want me to test anything? -- No. I tested the patch with DVB-T an watch encrypted channels with vdr without problems. I don't know why you can't. I don't know gnutv. Try with other software if you want. Jose Alberto -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Guys Thanks very much for the follow-up emails. Our time-zone differences prevented me from replying sooner. I'm guessing you guys are both in Europe, whereas I'm down and across in Australia. As I plan to use this webcam for home security, I would prefer to keep the JPEG quality at or above 90% if possible. This is because it'd be difficult enough to see a burglar's face clearly at 640x480 with lossless quality. The good news is that the nasty errors I was getting yesterday have magically disappeared overnight! All I'm seeing today (at 90% and 75% quality) is what look to be non-fatal errors, since Motion seems to work correctly. root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:34:17 Desktop kernel: [ 7240.125172] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:36:40 Desktop kernel: [ 7382.545241] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:36:40 Desktop kernel: [ 7382.545246] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 Mar 6 08:40:12 Desktop kernel: [ 7594.685124] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:40:12 Desktop kernel: [ 7594.685129] gspca_main: ISOC data error: [1] len=0, status=-18 Mar 6 08:42:37 Desktop kernel: [ 7739.715758] gspca_sn9c20x: Set 640x480 Mar 6 08:46:06 Desktop kernel: [ 7948.598533] gspca_main: ISOC data error: [0] len=0, status=-18 Mar 6 08:46:06 Desktop kernel: [ 7948.598538] gspca_main: ISOC data error: [1] len=0, status=-18 In fairness to Motion, the default JPEG quality listed in its configuration file is only 75%. I had upped this to 90% for clarity, but subsequently reverting to the default configuration file didn't stop these errors. They also remained after I increased the three vga_mode ratios to 6 / 8 or changed Line 2093 of sn9c20x.c to sd-quality = 75;. Entering either of the following commands before starting Motion didn't make any difference either. export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so The other thing I'm wondering about is how to force SXGA (1280x1024) mode to be used. I've set the 'width' and 'height' variables in the Motion configuration file correctly, but I still see the following kernel output: Mar 6 08:37:46 Desktop kernel: [ 7448.680301] gspca_sn9c20x: Set 640x480 I should note that Motion defaults to V4L2_PIX_FMT_YUV420 in its configuration file, which is what I'd been using until now. From the look of the code in the sn9c20x.c file, I must use V4L2_PIX_FMT_SBGGR8 to get the 1280x1024 resolution. After making this change, I still saw Set 640x480 in the kernel output. How can the above errors be overcome and how can I force SXGA mode to be used by my applications? Thanks again for all of the assistance you've given me so far. -- 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: jpeg: add driver for a version 2.x of jpeg H/W
On Monday, March 05, 2012 3:00 PM Andrzej Pietrasiewicz wrote:
I forgot to sign my last post. One might think I was being rude.
So I fix it below.
Hello송영목,
In general I think the v2x support should be designed to require
as little code changes as possible, and they should be related
to pure hardware differences only. Please see comments inline.
The tables (quantization, Huffman) logically contain mostly the
same data both in v3 and v2x and are defined by respective
standards. Only the arrangement of data is slightly different
(bytes vs 4-byte words). Please see comments inline.
On, March 02, 2012 12:47 AM 송영목 wrote:
...
diff --git a/drivers/media/video/s5p-jpeg/jpeg-core.c
b/drivers/media/video/s5p-jpeg/jpeg-core.c
index 1105a87..cf917cd 100644
--- a/drivers/media/video/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/video/s5p-jpeg/jpeg-core.c
...
diff --git a/drivers/media/video/s5p-jpeg/jpeg-hw-v2x.h
...
@@ -0,0 +1,387 @@
...
+
+#define S5P_JPEG_MIN_WIDTH 32
+#define S5P_JPEG_MIN_HEIGHT32
+#define S5P_JPEG_MAX_WIDTH 8192
+#define S5P_JPEG_MAX_HEIGHT8192
+#define S5P_JPEG_ENCODE0
+#define S5P_JPEG_DECODE1
+#define S5P_JPEG_RAW_IN_5650
+#define S5P_JPEG_RAW_IN_4221
+#define S5P_JPEG_SUBSAMPLING_422 0
+#define S5P_JPEG_SUBSAMPLING_420 1
+#define S5P_JPEG_RAW_OUT_422 0
+#define S5P_JPEG_RAW_OUT_420 1
This is a verbatim copy of what is defined in jpeg-hw-common.h
and should not be repeated here. Use jpeg-hw-common.h.
+/* Q-table for JPEG */
+/* ITU standard Q-table */
+static unsigned int ITU_Q_tbl[4][16] = {
+ {
+ 0x01010101, 0x01020303, 0x01010101, 0x01030303, /* Y */
+ 0x01010101, 0x02030303, 0x01010101, 0x03040403,
+ 0x01010203, 0x03050504, 0x01020303, 0x04050605,
+ 0x02030404, 0x05060605, 0x04050505, 0x06050505
+ } , {
+ 0x01010102, 0x05050505, 0x01010103, 0x05050505, /* CbCr */
+ 0x01010503, 0x05050505, 0x02030505, 0x05050505,
+ 0x05050505, 0x05050505, 0x05050505, 0x05050505,
+ 0x05050505, 0x05050505, 0x05050505, 0x05050505
+ } , {
+ 0x05020205, 0x0a161e25, 0x02020307, 0x0c232521, /* Y */
+ 0x0302050a, 0x16222b22, 0x0305090e, 0x1e393326,
+ 0x06091422, 0x2a384431, 0x0a122118, 0x34454b3c,
+ 0x1d283238, 0x44525142, 0x2d3c3e40, 0x4a424441
+ } , {
+ 0x05020205, 0x251e160a, 0x07030202, 0x2125230c, /* CbCr */
+ 0x0a050203, 0x222b2216, 0x0e090503, 0x2633391e,
+ 0x22140906, 0x3144382a, 0x1821120a, 0x3c4b4534,
+ 0x3832281d, 0x42515244, 0x403e3c2d, 0x4144424a
+ }
+};
This array is static so this makes all users of this header file
allocate it. Why not put it into jpeg-v2x.c? (however, see
below for considerations about duplication)
This comment applies to all array definitions of this kind
in this file.
+
+/* ITU Luminace Huffman Table */
+static unsigned int ITU_H_tbl_len_DC_luminance[4] = {
+ 0x01050100, 0x01010101, 0x0001, 0x
+};
This is in fact the same thing as hdctbl0[16] in jpeg v3,
only arranged in 4-byte words. It would be nice if
the same definitions were used in both versions. This applies
to all tables defined here.
+static unsigned int ITU_H_tbl_val_DC_luminance[3] = {
+ 0x03020100, 0x07060504, 0x0b0a0908
+};
The same thing as hdctblg0[12] in jpeg v3.
...
+static unsigned int ITU_H_tbl_val_DC_chrominance[3] = {
+ 0x03020100, 0x07060504, 0x0b0a0908
+};
The same thing as as hdctblg0[12] in jpeg v3 and
ITU_H_tbl_val_DC_luminance[3] in your code.
+
+static unsigned int ITU_H_tbl_len_AC_luminance[4] = {
+ 0x03010200, 0x03040203, 0x04040505, 0x7d01
+};
+
The same thing as hactbl0[16] in jpeg v3.
+static unsigned int ITU_H_tbl_val_AC_luminance[41] = {
+ 0x00030201, 0x12051104, 0x06413121, 0x07615113,
+ 0x32147122, 0x08a19181, 0xc1b14223, 0xf0d15215,
+ 0x72623324, 0x160a0982, 0x1a191817, 0x28272625,
+ 0x35342a29, 0x39383736, 0x4544433a, 0x49484746,
+ 0x5554534a, 0x59585756, 0x6564635a, 0x69686766,
+ 0x7574736a, 0x79787776, 0x8584837a, 0x89888786,
+ 0x9493928a, 0x98979695, 0xa3a29a99, 0xa7a6a5a4,
+ 0xb2aaa9a8, 0xb6b5b4b3, 0xbab9b8b7, 0xc5c4c3c2,
+ 0xc9c8c7c6, 0xd4d3d2ca, 0xd8d7d6d5, 0xe2e1dad9,
+ 0xe6e5e4e3, 0xeae9e8e7, 0xf4f3f2f1, 0xf8f7f6f5,
+ 0xfaf9
+};
+
The same thing as hactblg0[162] in jpeg v3.
...
+
+static inline void jpeg_reset(void __iomem *regs)
+{
+ unsigned long reg;
+
+ reg = readl(regs + S5P_JPEG_CNTL_REG);
+ writel(reg ~S5P_JPEG_SOFT_RESET_HI,
+ regs + S5P_JPEG_CNTL_REG);
+
+ ndelay(10);
Why not use usleep_range?
...
+static inline void jpeg_proc_mode(void __iomem *regs, unsigned long
mode)
+{
+ unsigned int reg, m;
+
+ m = S5P_JPEG_DEC_MODE;
+ if (mode ==
