Re: [PATCH 16/21] [staging] tm6000: Select interface on first open.
* Mauro Carvalho Chehab wrote: Em 01-09-2011 02:19, Thierry Reding escreveu: * Mauro Carvalho Chehab wrote: Em 04-08-2011 04:14, Thierry Reding escreveu: Instead of selecting the default interface setting when preparing isochronous transfers, select it on the first call to open() to make sure it is available earlier. Hmm... I fail to see what this is needed earlier. The ISOC endpont is used only when the device is streaming. Did you get any bug related to it? If so, please describe it better. I'm not sure whether this really fixes a bug, but it seems a little wrong to me to selecting the interface so late in the process when in fact the device is already being configured before (video standard, audio mode, firmware upload, ...). Some applications may open the device just to change the controls. All other drivers only set alternates/interfaces when the streaming is requested, as alternates/interfaces are needed only there. Okay, I didn't know that it was only necessary for streaming. Thinking about it, this may actually be part of the fix for the device hangs sometimes for inexplicable reasons bug that this whole patch series seems to fix. It is unlikely, except if the firmware inside the chip is broken (unfortunately, we have serious reasons to believe that the internal firmware on this chipset has serious bugs). Indeed! =) I prefer to not apply this patch, except if we have a good reason for that, as otherwise this driver will behave different than the others. Okay, it's your call. Unfortunately I no longer have the hardware available to test if this is really related to the bug. I'll have to check again when I have the hardware. Thierry pgpsUbhnaVM5J.pgp Description: PGP signature
[PATCH 1/2] [media] tm6000: Add fast USB access quirk
Some devices support fast access to registers using the USB interface
while others require a certain delay after each operation. This commit
adds a quirk that can be enabled by devices that don't need the delay.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging/tm6000/tm6000-core.c |3 ++-
drivers/staging/tm6000/tm6000.h |6 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 64fc1c6..93a0772 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -89,7 +89,8 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
kfree(data);
- msleep(5);
+ if ((dev-quirks TM6000_QUIRK_NO_USB_DELAY) == 0)
+ msleep(5);
mutex_unlock(dev-usb_lock);
return ret;
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index dac2063..0e35812 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -169,6 +169,10 @@ struct tm6000_endpoint {
unsignedmaxsize;
};
+enum {
+ TM6000_QUIRK_NO_USB_DELAY,
+};
+
struct tm6000_core {
/* generic device properties */
charname[30]; /* name (including
minor) of the device */
@@ -260,6 +264,8 @@ struct tm6000_core {
struct usb_isoc_ctl isoc_ctl;
spinlock_t slock;
+
+ unsigned long quirks;
};
enum tm6000_ops_type {
--
1.7.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] tm6000: Enable fast USB quirk on Cinergy Hybrid
The Cinergy Hybrid cards are known not to need an artificial delay after
USB accesses so the quirk can safely be enabled.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging/tm6000/tm6000-cards.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 5393976..aa18173 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -1002,6 +1002,16 @@ static int fill_board_specific_data(struct tm6000_core
*dev)
dev-vinput[2] = tm6000_boards[dev-model].vinput[2];
dev-rinput = tm6000_boards[dev-model].rinput;
+ /* setup per-model quirks */
+ switch (dev-model) {
+ case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+ dev-quirks |= TM6000_QUIRK_NO_USB_DELAY;
+ break;
+
+ default:
+ break;
+ }
+
/* initialize hardware */
rc = tm6000_init(dev);
if (rc 0)
--
1.7.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] tm6000: Add fast USB access quirk
* Thierry Reding wrote:
Some devices support fast access to registers using the USB interface
while others require a certain delay after each operation. This commit
adds a quirk that can be enabled by devices that don't need the delay.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging/tm6000/tm6000-core.c |3 ++-
drivers/staging/tm6000/tm6000.h |6 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 64fc1c6..93a0772 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -89,7 +89,8 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
kfree(data);
- msleep(5);
+ if ((dev-quirks TM6000_QUIRK_NO_USB_DELAY) == 0)
+ msleep(5);
This is of course completely wrong. The quirk as defined below is actually a
bit position. I'll send another update where the quirk is defined as bit mask
for the given position.
Thierry
mutex_unlock(dev-usb_lock);
return ret;
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index dac2063..0e35812 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -169,6 +169,10 @@ struct tm6000_endpoint {
unsignedmaxsize;
};
+enum {
+ TM6000_QUIRK_NO_USB_DELAY,
+};
+
struct tm6000_core {
/* generic device properties */
charname[30]; /* name (including
minor) of the device */
@@ -260,6 +264,8 @@ struct tm6000_core {
struct usb_isoc_ctl isoc_ctl;
spinlock_t slock;
+
+ unsigned long quirks;
};
enum tm6000_ops_type {
--
1.7.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
pgpt1m9stptxO.pgp
Description: PGP signature
Re: [PATCH] media: none of the drivers should be enabled by default
Hi Mauro On Wed, 31 Aug 2011, Mauro Carvalho Chehab wrote: [snip] I can't comment on the remote controller drivers as I haven't been involved with that. Mauro? If RC is disabled, most PC cards don't work (bttv, cx88, ivtv, dvb-usb, ...). Ok, this is due to a lack of proper module support on those drivers, but changing it requires some work on each driver that depends on RC. wouldn't a simple select RC_CORE in those drivers solve this? E.g., for BT848 diff --git a/drivers/media/video/bt8xx/Kconfig b/drivers/media/video/bt8xx/Kconfig index 7da5c2e..28c087bd 100644 --- a/drivers/media/video/bt8xx/Kconfig +++ b/drivers/media/video/bt8xx/Kconfig @@ -4,7 +4,7 @@ config VIDEO_BT848 select I2C_ALGOBIT select VIDEO_BTCX select VIDEOBUF_DMA_SG - depends on RC_CORE + select RC_CORE select VIDEO_TUNER select VIDEO_TVEEPROM select VIDEO_MSP3400 if VIDEO_HELPER_CHIPS_AUTO and deselect RC_CORE: diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 899f783..259a3e7 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -1,7 +1,6 @@ menuconfig RC_CORE tristate Remote Controller adapters depends on INPUT - default INPUT ---help--- Enable support for Remote Controllers on Linux. This is needed in order to support several video capture adapters. This way by default you have no RCs, but as soon as you enable one card, like bttv, you get all potentially needed drivers. Also, if RC is selected, the RC decoder protocols need to be enabled by default, as otherwise several devices will stop working, as, on modern devices, there's no hardware anymore to decode the IR pulses. The RC protocol Kconfig options are there, in fact, to allow disabling some RC decoding protocol when people are 100% sure that such software decoder won't be needed on some particular environment. Ok, they can be selected. Or even I don't mind them being turned on by default, when RC is on, as long as RC itself is off by default. With regards to the tuners: perhaps it is sufficient to default MEDIA_ATTACH to 'y'? That should prevent building those tuners that are not needed. Sorry, I don't see how this should work. I mean tuners under drivers/media/common/tuners/. I wouldn't change anything else here. Tuners are required for all TV and DVB cards. Maybe we can put an explicit Kconfig item for TV devices, and change the config stuff to something like: config MEDIA_NEED_TUNER tristate menuconfig MEDIA_TV tristate TV and grabber cards select MEDIA_NEED_TUNER ... menuconfig MEDIA_WEBCAMS tristate Webcameras ... config DVB_CORE tristate DVB for Linux depends on NET INET select CRC32 select MEDIA_NEED_TUNER config MEDIA_TUNER_TDA827X tristate Philips TDA827X silicon tuner depends on VIDEO_MEDIA I2C default MEDIA_NEED_TUNER if MEDIA_TUNER_CUSTOMIZE help A DVB-T silicon tuner module. Say Y when you want to support this tuner. There's one problem with the above strategy: on a few drivers, the same driver is used for both webcams and TV. I know that em28xx has this problem, as the same driver also supports the non-UVC em27xx-based webcams. I think that the same is true also for usbvision. If we put those devices under the TV and grabber cards, people that have just a em28xx-based webcam won't find them inside the MEDIA_WEBCAMS menus. Of course, we can workaround it, by creating a fake item inside the webcams menu, like: Yes, sure, or maybe put it under some hybrid menu. menuconfig MEDIA_WEBCAMS tristate Webcameras config MEDIA_EM27xx tristate em27xx-based webcams and put some glue magic between MEDIA_EM27xx and em28xx: config VIDEO_EM28XX depends on MEDIA_EM27xx if MEDIA_EM27xx ehem... why not just config MEDIA_EM27xx tristate em27xx-based webcams select VIDEO_EM28XX Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] [media] tm6000: Enable fast USB quirk on Cinergy Hybrid
The Cinergy Hybrid cards are known not to need an artificial delay after
USB accesses so the quirk can safely be enabled.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging/tm6000/tm6000-cards.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 5393976..aa18173 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -1002,6 +1002,16 @@ static int fill_board_specific_data(struct tm6000_core
*dev)
dev-vinput[2] = tm6000_boards[dev-model].vinput[2];
dev-rinput = tm6000_boards[dev-model].rinput;
+ /* setup per-model quirks */
+ switch (dev-model) {
+ case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+ dev-quirks |= TM6000_QUIRK_NO_USB_DELAY;
+ break;
+
+ default:
+ break;
+ }
+
/* initialize hardware */
rc = tm6000_init(dev);
if (rc 0)
--
1.7.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] [media] tm6000: Add fast USB access quirk
Some devices support fast access to registers using the USB interface
while others require a certain delay after each operation. This commit
adds a quirk that can be enabled by devices that don't need the delay.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/staging/tm6000/tm6000-core.c |3 ++-
drivers/staging/tm6000/tm6000.h |4
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 64fc1c6..93a0772 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -89,7 +89,8 @@ int tm6000_read_write_usb(struct tm6000_core *dev, u8
req_type, u8 req,
kfree(data);
- msleep(5);
+ if ((dev-quirks TM6000_QUIRK_NO_USB_DELAY) == 0)
+ msleep(5);
mutex_unlock(dev-usb_lock);
return ret;
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index dac2063..5bdce84 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -169,6 +169,8 @@ struct tm6000_endpoint {
unsignedmaxsize;
};
+#define TM6000_QUIRK_NO_USB_DELAY (1 0)
+
struct tm6000_core {
/* generic device properties */
charname[30]; /* name (including
minor) of the device */
@@ -260,6 +262,8 @@ struct tm6000_core {
struct usb_isoc_ctl isoc_ctl;
spinlock_t slock;
+
+ unsigned long quirks;
};
enum tm6000_ops_type {
--
1.7.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Sakari
On Thu, 1 Sep 2011, Sakari Ailus wrote:
Hi Guennadi,
Thanks for the patch!!
On Wed, Aug 31, 2011 at 08:02:41PM +0200, Guennadi Liakhovetski wrote:
A possibility to preallocate and initialise buffers of different sizes
in V4L2 is required for an efficient implementation of a snapshot
mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
VIDIOC_PREPARE_BUF and defines respective data structures.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-compat-ioctl32.c | 67
+---
drivers/media/video/v4l2-ioctl.c | 29
include/linux/videodev2.h | 15 ++
include/media/v4l2-ioctl.h|2 +
4 files changed, 105 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 61979b7..85758d2 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -159,11 +159,16 @@ struct v4l2_format32 {
} fmt;
};
-static int get_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+struct v4l2_create_buffers32 {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format32format; /* filled in by the user, plane
sizes calculated by the driver */
+ __u32 reserved[8];
+};
+
+static int __get_v4l2_format32(struct v4l2_format *kp, struct
v4l2_format32 __user *up)
{
- if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_format32)) ||
- get_user(kp-type, up-type))
- return -EFAULT;
switch (kp-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
@@ -192,11 +197,24 @@ static int get_v4l2_format32(struct v4l2_format *kp,
struct v4l2_format32 __user
}
}
-static int put_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+static int get_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+{
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_format32)) ||
+ get_user(kp-type, up-type))
+ return -EFAULT;
+ return __get_v4l2_format32(kp, up);
+}
+
+static int get_v4l2_create32(struct v4l2_create_buffers *kp, struct
v4l2_create_buffers32 __user *up)
+{
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_create_buffers32)) ||
+ copy_from_user(kp, up, offsetof(struct v4l2_create_buffers32,
format.fmt)))
+ return -EFAULT;
+ return __get_v4l2_format32(kp-format, up-format);
+}
+
+static int __put_v4l2_format32(struct v4l2_format *kp, struct
v4l2_format32 __user *up)
{
- if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_format32)) ||
- put_user(kp-type, up-type))
- return -EFAULT;
switch (kp-type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
@@ -225,6 +243,22 @@ static int put_v4l2_format32(struct v4l2_format *kp,
struct v4l2_format32 __user
}
}
+static int put_v4l2_format32(struct v4l2_format *kp, struct v4l2_format32
__user *up)
+{
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_format32)) ||
+ put_user(kp-type, up-type))
+ return -EFAULT;
+ return __put_v4l2_format32(kp, up);
+}
+
+static int put_v4l2_create32(struct v4l2_create_buffers *kp, struct
v4l2_create_buffers32 __user *up)
+{
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_create_buffers32))
||
+ copy_to_user(up, kp, offsetof(struct v4l2_create_buffers32,
format.fmt)))
+ return -EFAULT;
+ return __put_v4l2_format32(kp-format, up-format);
+}
+
struct v4l2_standard32 {
__u32index;
__u32id[2]; /* __u64 would get the alignment wrong */
@@ -702,6 +736,8 @@ static int put_v4l2_event32(struct v4l2_event *kp,
struct v4l2_event32 __user *u
#define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
#define VIDIOC_TRY_EXT_CTRLS32 _IOWR('V', 73, struct v4l2_ext_controls32)
#defineVIDIOC_DQEVENT32_IOR ('V', 89, struct v4l2_event32)
+#define VIDIOC_CREATE_BUFS32 _IOWR('V', 92, struct
v4l2_create_buffers32)
+#define VIDIOC_PREPARE_BUF32 _IOW ('V', 93, struct v4l2_buffer32)
#define VIDIOC_OVERLAY32 _IOW ('V',
Re: [PATCH 3/9 v6] V4L: document the new VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctl()s
On Thu, 1 Sep 2011, Sakari Ailus wrote: Hi Guennadi, On Wed, Aug 31, 2011 at 08:02:42PM +0200, Guennadi Liakhovetski wrote: Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Hans Verkuil hverk...@xs4all.nl Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Marek Szyprowski m.szyprow...@samsung.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Pawel Osciak pa...@osciak.com Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/media/v4l/io.xml | 17 +++ Documentation/DocBook/media/v4l/v4l2.xml |2 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 147 .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96 + 4 files changed, 262 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml [snip] + refsect1 +titleDescription/title + +paraApplications can optionally call the +constantVIDIOC_PREPARE_BUF/constant ioctl to pass ownership of the buffer +to the driver before actually enqueuing it, using the +constantVIDIOC_QBUF/constant ioctl, and to prepare it for future I/O. +Such preparations may include cache invalidation or cleaning. Performing them I think it could be added that the first time when the buffer is prepared, the preparation may include very time consuming tasks such as memory allocation and iommu mapping of that memory. Sure, looking forward to your incremental patch. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add camera controls for the ov5642 driver
On Thu, 1 Sep 2011, Sakari Ailus wrote: On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote: 2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com: [clip] If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated. I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled V4L2_CID_PRIVATE_BASE deprecated and read Documentation/feature-removal-schedule.txt. I couldn't find anything. Hmm. Did you happen to check when that has been written? :) Please use this one instead: URL:http://hverkuil.home.xs4all.nl/spec/media.html Drivers can also implement their own custom controls using V4L2_CID_PRIVATE_BASE and higher values. Which specific location describes V4L2_CID_PRIVATE_BASE differently there? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
Hi Gary, On Thursday 01 September 2011 00:34:20 Gary Thomas wrote: On 2011-08-31 10:33, Laurent Pinchart wrote: On Wednesday 31 August 2011 18:25:28 Enrico wrote: On Wed, Aug 31, 2011 at 5:15 PM, Laurent Pinchart wrote: I've just sent three preliminary patches to the list to add YUYV support in the OMAP3 ISP CCDC. What tree are those based on? On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2. Sorry to be a pain, but is there an easy way to generate a patchset for this tree against the vanilla released 3.0 tree? (that's what my tree is using) You can apply the 4 YUV patches I've sent to the list only. They won't apply cleanly though, you will need to fix them. -- 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
[GIT PULL] Videobuf2 FIMC fixes
Hello Mauro, I've collected all the separate patches for VideoBuf2 and FIMC to a single branch. Please pull them to your media tree. The following changes since commit 69d232ae8e95a229e7544989d6014e875deeb121: [media] omap3isp: ccdc: Use generic frame sync event instead of private HS_VS event (2011-08-29 12:38:51 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung for_mauro Andrzej Pietrasiewicz (1): media: mem2mem: eliminate possible NULL pointer dereference Marek Szyprowski (5): media: vb2: add a check if queued userptr buffer is large enough media: vb2: fix handling MAPPED buffer flag media: vb2: change plane sizes array to unsigned int[] media: vb2: dma contig allocator: use dma_addr instread of paddr media: vb2: change queue initialization order Sylwester Nawrocki (3): s5p-fimc: Add runtime PM support in the mem-to-mem driver s5p-csis: Handle all available power supplies s5p-csis: Rework the system suspend/resume helpers Tomasz Stanislawski (1): media: v4l: remove single to multiplane conversion Yu Tang (1): media: vb2: fix userptr VMA release seq drivers/media/video/Kconfig |2 +- drivers/media/video/atmel-isi.c | 24 ++- drivers/media/video/marvell-ccic/mcam-core.c | 12 +- drivers/media/video/mem2mem_testdev.c|2 +- drivers/media/video/mx3_camera.c |4 +- drivers/media/video/pwc/pwc-if.c |4 +- drivers/media/video/s5p-fimc/fimc-capture.c | 85 ++--- drivers/media/video/s5p-fimc/fimc-core.c | 287 +++--- drivers/media/video/s5p-fimc/fimc-core.h | 16 +- drivers/media/video/s5p-fimc/fimc-reg.c |2 +- drivers/media/video/s5p-fimc/mipi-csis.c | 90 + drivers/media/video/s5p-mfc/s5p_mfc.c|4 +- drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 14 +- drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 34 ++-- drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 14 +- drivers/media/video/s5p-tv/mixer.h |2 - drivers/media/video/s5p-tv/mixer_grp_layer.c |2 +- drivers/media/video/s5p-tv/mixer_video.c | 24 +- drivers/media/video/s5p-tv/mixer_vp_layer.c |4 +- drivers/media/video/sh_mobile_ceu_camera.c |6 +- drivers/media/video/v4l2-ioctl.c | 250 +- drivers/media/video/v4l2-mem2mem.c | 18 +- drivers/media/video/videobuf2-core.c | 205 ++- drivers/media/video/videobuf2-dma-contig.c | 16 +- drivers/media/video/videobuf2-memops.c |6 +- drivers/media/video/vivi.c |4 +- include/media/videobuf2-core.h | 23 ++- include/media/videobuf2-dma-contig.h |6 +- 28 files changed, 567 insertions(+), 593 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Guennadi,
On Thursday 01 September 2011 09:03:52 Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 08:02:41PM +0200, Guennadi Liakhovetski wrote:
[snip]
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V',
91, struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_PREPARE_BUF_IOW('V', 93, struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return anything to
the user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have I
misunderstood you?
This caught my eyes as well. Do you think VIDIOC_PREPARE_BUF could need to
return information to userspace in the future ?
--
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 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
On Thu, Sep 01, 2011 at 09:03:52AM +0200, Guennadi Liakhovetski wrote:
Hi Sakari
Hi Guennadi,
On Thu, 1 Sep 2011, Sakari Ailus wrote:
[clip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..988e1be 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -653,6 +653,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_ERROR 0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
+/* Cache handling flags */
+#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0400
+#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
/*
* O V E R L A Y P R E V I E W
@@ -2092,6 +2095,15 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
+/* VIDIOC_CREATE_BUFS */
+struct v4l2_create_buffers {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format format; /* type is used always, the
rest if sizeimage == 0 */
+ __u32 reserved[8];
+};
How about splitting the above comments? These lines are really long.
Kerneldoc could also be used, I think.
Sure, how about this incremental patch:
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Subject: V4L: improve struct v4l2_create_buffers documentation
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 988e1be..64e0bf2 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2095,12 +2095,20 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
-/* VIDIOC_CREATE_BUFS */
+/**
+ * struct v4l2_create_buffers - VIDIOC_CREATE_BUFS argument
+ * @index: on return, index of the first created buffer
+ * @count: entry: number of requested buffers,
+ * return: number of created buffers
+ * @memory: buffer memory type
+ * @format: frame format, for which buffers are requested
+ * @reserved:future extensions
+ */
struct v4l2_create_buffers {
- __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 index;
__u32 count;
enum v4l2_memorymemory;
- struct v4l2_format format; /* type is used always, the
rest if sizeimage == 0 */
+ struct v4l2_format format;
__u32 reserved[8];
};
Thanks! This looks good to me. Could you do a similar change to the
compat-IOCTL version of this struct (v4l2_create_buffers32)?
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_PREPARE_BUF_IOW('V', 93, struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return anything to the
user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have I
misunderstood you?
I was thinking if this will be the case now and in the foreseeable future as
this can't be changed after once defined. I just wanted to bring this up
even though I don't see myself that any of the fields would need to be
returned to the user. But there are reserved fields...
So unless someone comes up with something quick, I think this should stay
as-is.
--
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add camera controls for the ov5642 driver
On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi Liakhovetski wrote: On Thu, 1 Sep 2011, Sakari Ailus wrote: On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote: 2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com: [clip] If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated. I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled V4L2_CID_PRIVATE_BASE deprecated and read Documentation/feature-removal-schedule.txt. I couldn't find anything. Hmm. Did you happen to check when that has been written? :) Please use this one instead: URL:http://hverkuil.home.xs4all.nl/spec/media.html Drivers can also implement their own custom controls using V4L2_CID_PRIVATE_BASE and higher values. Which specific location describes V4L2_CID_PRIVATE_BASE differently there? That was a general comment, not related to the private base. There's no use for a three-year-old spec as a reference! The control framework does not support private controls, for example. The controls should be put to their own class in videodev2.h nowadays, that's my understanding. Cc Hans. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
On Thu, 1 Sep 2011, Laurent Pinchart wrote:
Hi Guennadi,
On Thursday 01 September 2011 09:03:52 Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 08:02:41PM +0200, Guennadi Liakhovetski wrote:
[snip]
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT
_IOW('V',
91, struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_PREPARE_BUF _IOW('V', 93, struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return anything to
the user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have I
misunderstood you?
This caught my eyes as well. Do you think VIDIOC_PREPARE_BUF could need to
return information to userspace in the future ?
Let's see: [PATCH 2/9 v6], it has been an _IOW since v1, posted on
01.04 - exactly 5 months ago, when it was still called SUBMIT_BUF. So,
IIRC, since then noone has come up with even a doubt, that this might need
to change in the future (until today), let alone an example, what might
need to be given back.
But sure, I cannot look into the future, so, I'm all ears.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9t001: Aptina (Micron) MT9T001 3MP sensor driver
Hi Sakari,
Thanks for the review.
On Wednesday 31 August 2011 20:23:33 Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 02:24:12PM +0200, Laurent Pinchart wrote:
The MT9T001 is a parallel 3MP sensor from Aptina (formerly Micron)
controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports binning and
cropping, and the gain, exposure, test pattern and black level controls.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
[snip]
diff --git a/drivers/media/video/mt9t001.c
b/drivers/media/video/mt9t001.c new file mode 100644
index 000..32ab217
--- /dev/null
+++ b/drivers/media/video/mt9t001.c
@@ -0,0 +1,788 @@
[snip]
+/*
+ * mt9m001 i2c address 0x5d
Is it also that for mt8t001?
Do you mean mt9t001 ? :-) The comment isn't really useful, I've removed it.
+ */
[snip]
+static struct mt9t001 *to_mt9t001(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct mt9t001, subdev);
+}
I guess you could add inline here, or define it as a macro.
I've added inline.
+static int mt9t001_read(struct i2c_client *client, const u8 reg)
+{
+ s32 data = i2c_smbus_read_word_data(client, reg);
+ return data 0 ? data : swab16(data);
Is the swab16 correct here? What about be16_to_cpu()?
Fixed.
+}
+
+static int mt9t001_write(struct i2c_client *client, const u8 reg,
+const u16 data)
+{
+ return i2c_smbus_write_word_data(client, reg, swab16(data));
Ditto.
+}
[snip]
+static int mt9t001_s_stream(struct v4l2_subdev *subdev, int enable)
+{
+ struct mt9t001 *mt9t001 = to_mt9t001(subdev);
+
+ /* Switch to master normal mode or stop sensor readout */
+ return mt9t001_set_output_control(mt9t001,
+ enable ? 0 : MT9T001_OUTPUT_CONTROL_CHIP_ENABLE,
+ enable ? MT9T001_OUTPUT_CONTROL_CHIP_ENABLE : 0);
I wonder if an if would be better here. You also could change the
mt9t001_set_output_control() to take in the number of the bit and whether
you enable or disable it.
I've added more code to s_stream, the code looks cleaner now.
+}
[snip]
+#define V4L2_CID_TEST_PATTERN (V4L2_CID_USER_BASE | 0x1001)
Thest pattern is something that almost every sensor have.
+#define V4L2_CID_GAIN_RED (V4L2_CTRL_CLASS_CAMERA | 0x1001)
+#define V4L2_CID_GAIN_GREEN1 (V4L2_CTRL_CLASS_CAMERA |
0x1002)
+#define V4L2_CID_GAIN_GREEN2 (V4L2_CTRL_CLASS_CAMERA |
0x1003)
The greens are usually not numbered but have either blue/red subscript
based on the colour of the adjacent pixel as far as I understand. What
about calling them GREEN_RED or GREEN_R (and same for blue)?
Good point. I've fixed that.
Also these are quite low level controls as opposed to the other higher
level controls in this class. I wonder if creating a separate class for
them would make sense. We'll need a new class for the hblank/vblank
controls anyway. I might call it sensor.
These controls could be also standardised.
I agree.
A sensor control class might make sense for these 5 controls, but they can
also be useful for non-sensor hardware (for instance with an analog pixel
decoder).
+#define V4L2_CID_GAIN_BLUE (V4L2_CTRL_CLASS_CAMERA | 0x1004)
+
+static int mt9t001_gain_data(s32 *gain)
+{
+ /* Gain is controlled by 2 analog stages and a digital stage. Valid
+* values for the 3 stages are
+*
+* StageMin Max Step
+* --
+* First analog stage x1 x2 1
+* Second analog stage x1 x4 0.125
+* Digital stagex1 x16 0.125
+*
+* To minimize noise, the gain stages should be used in the second
+* analog stage, first analog stage, digital stage order. Gain from a
+* previous stage should be pushed to its maximum value before the next
+* stage is used.
+*/
+ if (*gain = 32)
+ return *gain;
+
+ if (*gain = 64) {
+ *gain = ~1;
+ return (1 6) | (*gain 1);
+ }
+
+ *gain = ~7;
+ return ((*gain - 64) 5) | (1 6) | 32;
+}
This one looks very similar to another Aptina sensor driver. My comment
back then was that the analog and digital gain should be separate controls
as the user typically would e.g. want to know (s)he's using digital gain
instead of analog one.
What about implementing this?
It's a good question whether we need one or two new controls. If the answer
is two, then how do they relate to the existing control?
I'm not too sure about this. If an application needs that much control over
the hardware, wouldn't it be hardware-specific anyway, and know about control
ranges ? The mt9t001 actually has 3 gain stages, so one might even argue that
we should expose 3 gain controls :-)
+static int mt9t001_ctrl_freeze(struct mt9t001 *mt9t001, bool freeze)
+{
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler sits...@yahoo.com wrote: Hi, I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a USB webcam. See below: Could you try the attached patch? eeepc kernel: [ 1263.874756] cheese[3402]: segfault at 58 ip 080630b6 sp afc2c840 error 4 in cheese[8048000+24000] eeepc kernel: [ 1393.419370] uvcvideo: Non-zero status (-84) in status completion handler. eeepc kernel: [ 1393.500719] usb 3-2: USB disconnect, device number 4 eeepc kernel: [ 1393.504351] uvcvideo: Failed to resubmit video URB (-19). eeepc kernel: [ 1495.428853] BUG: unable to handle kernel paging request at 6b6b6bcb eeepc kernel: [ 1495.429017] IP: [b0358d37] dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] *pde = eeepc kernel: [ 1495.429017] Oops: [#1] DEBUG_PAGEALLOC eeepc kernel: [ 1495.429017] eeepc kernel: [ 1495.429017] Pid: 3476, comm: cheese Not tainted 3.1.0-rc3-00270-g7a54f5e-dirty #485 ASUSTeK Computer INC. 900/900 eeepc kernel: [ 1495.429017] EIP: 0060:[b0358d37] EFLAGS: 00010202 CPU: 0 eeepc kernel: [ 1495.429017] EIP is at dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] EAX: 6b6b6b6b EBX: eb08d870 ECX: EDX: eb08d930 eeepc kernel: [ 1495.429017] ESI: eb08d870 EDI: eb08d870 EBP: d3249cac ESP: d3249cac eeepc kernel: [ 1495.429017] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 eeepc kernel: [ 1495.429017] Process cheese (pid: 3476, ti=d3248000 task=df46d870 task.ti=d3248000) eeepc kernel: [ 1495.429017] Stack: eeepc kernel: [ 1495.429017] d3249cb8 b03e77a1 d307b840 d3249ccc b03e77d1 d307b840 eb08d870 eb08d830 eeepc kernel: [ 1495.429017] d3249ce4 b03ed3b7 0246 d307b840 eb08d870 d3021b80 d3249cec b03ed565 eeepc kernel: [ 1495.429017] d3249cfc b03e044d e8323d10 b06e013c d3249d18 b0355fb9 fffe d3249d1c eeepc kernel: [ 1495.429017] Call Trace: eeepc kernel: [ 1495.429017] [b03e77a1] v4l2_device_disconnect+0x11/0x30 eeepc kernel: [ 1495.429017] [b03e77d1] v4l2_device_unregister+0x11/0x50 eeepc kernel: [ 1495.429017] [b03ed3b7] uvc_delete+0x37/0x110 eeepc kernel: [ 1495.429017] [b03ed565] uvc_release+0x25/0x30 eeepc kernel: [ 1495.429017] [b03e044d] v4l2_device_release+0x9d/0xc0 eeepc kernel: [ 1495.429017] [b0355fb9] device_release+0x19/0x90 eeepc kernel: [ 1495.429017] [b03adfdc] ? usb_hcd_unlink_urb+0x7c/0x90 eeepc kernel: [ 1495.429017] [b026b99c] kobject_release+0x3c/0x90 eeepc kernel: [ 1495.429017] [b026b960] ? kobject_del+0x30/0x30 eeepc kernel: [ 1495.429017] [b026ca4c] kref_put+0x2c/0x60 eeepc kernel: [ 1495.429017] [b026b88d] kobject_put+0x1d/0x50 eeepc kernel: [ 1495.429017] [b03b2385] ? usb_autopm_put_interface+0x25/0x30 eeepc kernel: [ 1495.429017] [b03f0e5d] ? uvc_v4l2_release+0x5d/0xd0 eeepc kernel: [ 1495.429017] [b0355d2f] put_device+0xf/0x20 eeepc kernel: [ 1495.429017] [b03dfa96] v4l2_release+0x56/0x60 eeepc kernel: [ 1495.429017] [b019c8dc] fput+0xcc/0x220 eeepc kernel: [ 1495.429017] [b01990f4] filp_close+0x44/0x70 eeepc kernel: [ 1495.429017] [b012b238] put_files_struct+0x158/0x180 eeepc kernel: [ 1495.429017] [b012b100] ? put_files_struct+0x20/0x180 eeepc kernel: [ 1495.429017] [b012b2a0] exit_files+0x40/0x50 eeepc kernel: [ 1495.429017] [b012b9e7] do_exit+0x5a7/0x660 eeepc kernel: [ 1495.429017] [b0135f72] ? __dequeue_signal+0x12/0x120 eeepc kernel: [ 1495.429017] [b055edf2] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [b012badc] do_group_exit+0x3c/0xb0 eeepc kernel: [ 1495.429017] [b015792b] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [b013755f] get_signal_to_deliver+0x18f/0x570 eeepc kernel: [ 1495.429017] [b01020f7] do_signal+0x47/0x9e0 eeepc kernel: [ 1495.429017] [b055edf2] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [b015792b] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [b0123300] ? T.1034+0x30/0xc0 eeepc kernel: [ 1495.429017] [b055c45f] ? schedule+0x29f/0x640 eeepc kernel: [ 1495.429017] [b0102ac8] do_notify_resume+0x38/0x40 eeepc kernel: [ 1495.429017] [b055f154] work_notifysig+0x9/0x11 eeepc kernel: [ 1495.429017] Code: e5 5d 83 f8 01 19 c0 f7 d0 83 e0 f0 c3 8d b4 26 00 00 00 00 55 85 c0 89 e5 75 09 31 c0 5d c3 90 8d 74 26 00 8b 40 04 85 c0 74 f0 8b 40 60 5d c3 8d 74 26 00 55 89 e5 53 89 c3 83 ec 04 8b 40 04 eeepc kernel: [ 1495.429017] EIP: [b0358d37] dev_get_drvdata+0x17/0x20 SS:ESP 0068:d3249cac eeepc kernel: [ 1495.429017] CR2: 6b6b6bcb eeepc kernel: [ 1495.466975] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: [ 1495.467860] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: last message repeated 3 times eeepc kernel: [ 1495.512610] ---[ end trace 73ec16848794e5a5 ]--- eeepc kernel: [ 1495.512620] Fixing recursive fault but reboot is needed! -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a
Re: [PATCH] media: Add camera controls for the ov5642 driver
Hi Sakari, On 09/01/2011 10:47 AM, Sakari Ailus wrote: On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi Liakhovetski wrote: On Thu, 1 Sep 2011, Sakari Ailus wrote: On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote: 2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com: [clip] If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated. I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled V4L2_CID_PRIVATE_BASE deprecated and read Documentation/feature-removal-schedule.txt. I couldn't find anything. Hmm. Did you happen to check when that has been written? :) Please use this one instead: URL:http://hverkuil.home.xs4all.nl/spec/media.html Drivers can also implement their own custom controls using V4L2_CID_PRIVATE_BASE and higher values. Which specific location describes V4L2_CID_PRIVATE_BASE differently there? That was a general comment, not related to the private base. There's no use for a three-year-old spec as a reference! The control framework does not support private controls, for example. The controls should be put to their own class in videodev2.h nowadays, that's my understanding. Cc Hans. Is this really the case that we close the door for private controls in the mainline kernel ? Or am I misunderstanding something ? How about v4l2_ctrl_new_custom() ? What if there are controls applicable to single driver only ? Do we really want to have plenty of such in videodev2.h ? -- Sylwester Nawrocki Samsung Poland RD Center -- 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/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:03:52AM +0200, Guennadi Liakhovetski wrote:
Hi Sakari
Hi Guennadi,
On Thu, 1 Sep 2011, Sakari Ailus wrote:
[clip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..988e1be 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -653,6 +653,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_ERROR0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
+/* Cache handling flags */
+#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0400
+#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
/*
* O V E R L A Y P R E V I E W
@@ -2092,6 +2095,15 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
+/* VIDIOC_CREATE_BUFS */
+struct v4l2_create_buffers {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format format; /* type is used
always, the rest if sizeimage == 0 */
+ __u32 reserved[8];
+};
How about splitting the above comments? These lines are really long.
Kerneldoc could also be used, I think.
Sure, how about this incremental patch:
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Subject: V4L: improve struct v4l2_create_buffers documentation
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 988e1be..64e0bf2 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2095,12 +2095,20 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
-/* VIDIOC_CREATE_BUFS */
+/**
+ * struct v4l2_create_buffers - VIDIOC_CREATE_BUFS argument
+ * @index: on return, index of the first created buffer
+ * @count: entry: number of requested buffers,
+ * return: number of created buffers
+ * @memory:buffer memory type
+ * @format:frame format, for which buffers are requested
+ * @reserved: future extensions
+ */
struct v4l2_create_buffers {
- __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 index;
__u32 count;
enum v4l2_memorymemory;
- struct v4l2_format format; /* type is used always, the
rest if sizeimage == 0 */
+ struct v4l2_format format;
__u32 reserved[8];
};
Thanks! This looks good to me. Could you do a similar change to the
compat-IOCTL version of this struct (v4l2_create_buffers32)?
Of course, I'll submit an incremental patch as soon as this is accepted
for upstream, unless there are other important changes to this patch and a
new revision is anyway unavoidable.
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
#defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_PREPARE_BUF _IOW('V', 93, struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return anything to
the
user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have I
misunderstood you?
I was thinking if this will be the case now and in the foreseeable future as
this can't be changed after once defined. I just wanted to bring this up
even though I don't see myself that any of the fields would need to be
returned to the user. But there are reserved fields...
So unless someone comes up with something quick, I think this should stay
as-is.
Agree. I understand, it is important to try to design the user-space API
as clever as possible, so, I'm relying on our combined wisdom for it. But
even that is probably limited, so, mistakes are still possible. Therefore,
unless someone comes up with a realistic reason, why this has to be _IOWR,
we shall keep it _IOW and be prepared to delight our user-space colleagues
with more shiny new ioctl()s in the somewhat near future;-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a
Re: Getting started with OMAP3 ISP
On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2. Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward: Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628 Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628 Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch. I tried also to route it through the resizer but nothing changes. Is it normal that --enum-formats returns this? Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. - Available formats: Video format: () 0x0 buffer size 0 Thanks, 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: Getting started with OMAP3 ISP
Hi Enrico, On Thursday 01 September 2011 11:51:58 Enrico wrote: On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote: On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2. Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward: Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628 Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628 Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch. Does your tvp5150 generate progressive or interlaced images ? I tried also to route it through the resizer but nothing changes. Is it normal that --enum-formats returns this? Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. - Available formats: Video format: () 0x0 buffer size 0 Yes that's normal. Format enumeration on video device nodes isn't supported by the OMAP3 ISP driver. -- 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 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:03:52AM +0200, Guennadi Liakhovetski wrote:
Hi Sakari
Hi Guennadi,
On Thu, 1 Sep 2011, Sakari Ailus wrote:
[clip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..988e1be 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -653,6 +653,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_ERROR 0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
+/* Cache handling flags */
+#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0400
+#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
/*
* O V E R L A Y P R E V I E W
@@ -2092,6 +2095,15 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
+/* VIDIOC_CREATE_BUFS */
+struct v4l2_create_buffers {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format format; /* type is used always, the
rest if sizeimage == 0 */
+ __u32 reserved[8];
+};
How about splitting the above comments? These lines are really long.
Kerneldoc could also be used, I think.
Sure, how about this incremental patch:
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Subject: V4L: improve struct v4l2_create_buffers documentation
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 988e1be..64e0bf2 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2095,12 +2095,20 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
-/* VIDIOC_CREATE_BUFS */
+/**
+ * struct v4l2_create_buffers - VIDIOC_CREATE_BUFS argument
+ * @index: on return, index of the first created buffer
+ * @count: entry: number of requested buffers,
+ * return: number of created buffers
+ * @memory:buffer memory type
+ * @format:frame format, for which buffers are requested
+ * @reserved: future extensions
+ */
struct v4l2_create_buffers {
- __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 index;
__u32 count;
enum v4l2_memorymemory;
- struct v4l2_format format; /* type is used always, the
rest if sizeimage == 0 */
+ struct v4l2_format format;
__u32 reserved[8];
};
Thanks! This looks good to me. Could you do a similar change to the
compat-IOCTL version of this struct (v4l2_create_buffers32)?
Of course, I'll submit an incremental patch as soon as this is accepted
for upstream, unless there are other important changes to this patch and a
new revision is anyway unavoidable.
Ok. I'll send a small patch to the documentation as well then.
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_PREPARE_BUF_IOW('V', 93, struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return anything to the
user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have I
misunderstood you?
I was thinking if this will be the case now and in the foreseeable future as
this can't be changed after once defined. I just wanted to bring this up
even though I don't see myself that any of the fields would need to be
returned to the user. But there are reserved fields...
So unless someone comes up with something quick, I think this should stay
as-is.
Agree. I understand, it is important to try to design the user-space API
as clever as possible, so, I'm relying on our combined wisdom for it. But
even that is probably limited, so, mistakes are still possible. Therefore,
unless someone comes up with a realistic reason, why this has to be _IOWR,
we shall keep it _IOW and be prepared to delight our user-space colleagues
with more shiny new ioctl()s in the somewhat near future;-)
What we could also do is to mark the new IOCTLs experimental, and remove
the note after one or two more kernel releases. This would allow
postponing the decision.
We also don't have anyone using these ioctls from user space as far as I
understand, so we might get important input later on as well.
Cheers,
--
Sakari Ailus
Re: Getting started with OMAP3 ISP
On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Thursday 01 September 2011 11:51:58 Enrico wrote: On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote: On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2. Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward: Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628 Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628 Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch. Does your tvp5150 generate progressive or interlaced images ? In the driver it is setup to decode by default in bt656 mode, so interlaced. I've read on the omap trm that the isp can deinterlace it setting properly SDOFST, i just noticed in the register dump this: omap3isp omap3isp: ###CCDC SDOFST=0x and maybe this is related too: omap3isp omap3isp: ###CCDC REC656IF=0x Moreover i just found this [1] old thread about the same problem, i'm reading it now. Enrico [1]: http://www.spinics.net/lists/linux-media/msg28079.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] mt9t001: Aptina (Micron) MT9T001 3MP sensor driver
On Thu, Sep 01, 2011 at 11:05:05AM +0200, Laurent Pinchart wrote:
Hi Sakari,
Thanks for the review.
On Wednesday 31 August 2011 20:23:33 Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 02:24:12PM +0200, Laurent Pinchart wrote:
The MT9T001 is a parallel 3MP sensor from Aptina (formerly Micron)
controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports binning and
cropping, and the gain, exposure, test pattern and black level controls.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
[snip]
diff --git a/drivers/media/video/mt9t001.c
b/drivers/media/video/mt9t001.c new file mode 100644
index 000..32ab217
--- /dev/null
+++ b/drivers/media/video/mt9t001.c
@@ -0,0 +1,788 @@
[snip]
+/*
+ * mt9m001 i2c address 0x5d
Is it also that for mt8t001?
Do you mean mt9t001 ? :-) The comment isn't really useful, I've removed it.
Ack.
+ */
[snip]
+static struct mt9t001 *to_mt9t001(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct mt9t001, subdev);
+}
I guess you could add inline here, or define it as a macro.
I've added inline.
+static int mt9t001_read(struct i2c_client *client, const u8 reg)
+{
+ s32 data = i2c_smbus_read_word_data(client, reg);
+ return data 0 ? data : swab16(data);
Is the swab16 correct here? What about be16_to_cpu()?
Fixed.
+}
+
+static int mt9t001_write(struct i2c_client *client, const u8 reg,
+ const u16 data)
+{
+ return i2c_smbus_write_word_data(client, reg, swab16(data));
Ditto.
+}
[snip]
+static int mt9t001_s_stream(struct v4l2_subdev *subdev, int enable)
+{
+ struct mt9t001 *mt9t001 = to_mt9t001(subdev);
+
+ /* Switch to master normal mode or stop sensor readout */
+ return mt9t001_set_output_control(mt9t001,
+ enable ? 0 : MT9T001_OUTPUT_CONTROL_CHIP_ENABLE,
+ enable ? MT9T001_OUTPUT_CONTROL_CHIP_ENABLE : 0);
I wonder if an if would be better here. You also could change the
mt9t001_set_output_control() to take in the number of the bit and whether
you enable or disable it.
I've added more code to s_stream, the code looks cleaner now.
+}
[snip]
+#define V4L2_CID_TEST_PATTERN(V4L2_CID_USER_BASE | 0x1001)
Thest pattern is something that almost every sensor have.
+#define V4L2_CID_GAIN_RED(V4L2_CTRL_CLASS_CAMERA |
0x1001)
+#define V4L2_CID_GAIN_GREEN1 (V4L2_CTRL_CLASS_CAMERA |
0x1002)
+#define V4L2_CID_GAIN_GREEN2 (V4L2_CTRL_CLASS_CAMERA |
0x1003)
The greens are usually not numbered but have either blue/red subscript
based on the colour of the adjacent pixel as far as I understand. What
about calling them GREEN_RED or GREEN_R (and same for blue)?
Good point. I've fixed that.
Also these are quite low level controls as opposed to the other higher
level controls in this class. I wonder if creating a separate class for
them would make sense. We'll need a new class for the hblank/vblank
controls anyway. I might call it sensor.
These controls could be also standardised.
I agree.
A sensor control class might make sense for these 5 controls, but they can
also be useful for non-sensor hardware (for instance with an analog pixel
decoder).
What about calling it differently then?
V4L2_CTRL_CLASS_SOURCE
V4L2_CTRL_CLASS_IMAGE_SOURCE
V4L2_CTRL_CLASS_MBUS_SOURCE
+#define V4L2_CID_GAIN_BLUE (V4L2_CTRL_CLASS_CAMERA |
0x1004)
+
+static int mt9t001_gain_data(s32 *gain)
+{
+ /* Gain is controlled by 2 analog stages and a digital stage. Valid
+ * values for the 3 stages are
+ *
+ * StageMin Max Step
+ * --
+ * First analog stage x1 x2 1
+ * Second analog stage x1 x4 0.125
+ * Digital stagex1 x16 0.125
+ *
+ * To minimize noise, the gain stages should be used in the second
+ * analog stage, first analog stage, digital stage order. Gain from a
+ * previous stage should be pushed to its maximum value before the next
+ * stage is used.
+ */
+ if (*gain = 32)
+ return *gain;
+
+ if (*gain = 64) {
+ *gain = ~1;
+ return (1 6) | (*gain 1);
+ }
+
+ *gain = ~7;
+ return ((*gain - 64) 5) | (1 6) | 32;
+}
This one looks very similar to another Aptina sensor driver. My comment
back then was that the analog and digital gain should be separate controls
as the user typically would e.g. want to know (s)he's using digital gain
instead of analog one.
What about implementing this?
It's a good question whether we need one or two new controls. If the answer
is two, then how do they relate to the existing control?
I'm not too sure about this. If an application
Updated DVB-S file Thor-1.0W
Hi I have attached a patch for Thor-1.0W. Most of the mux updates are for the new Thor 6 satellite. http://www.telenorsbc.com/templates/Page.aspx?id=783 I have also taking the liberty to update one of the existing muxes. http://www.telenorsbc.com/templates/Page.aspx?id=674 I have tested the patch with tvheadend and it works without any problems. Best regards, Harald Thor-1.0W.patch Description: Binary data
Re: [PATCH 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
On Thu, 1 Sep 2011, Sakari Ailus wrote:
Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:03:52AM +0200, Guennadi Liakhovetski wrote:
Hi Sakari
Hi Guennadi,
On Thu, 1 Sep 2011, Sakari Ailus wrote:
[clip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..988e1be 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -653,6 +653,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_ERROR0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
+/* Cache handling flags */
+#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0400
+#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
/*
* O V E R L A Y P R E V I E W
@@ -2092,6 +2095,15 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
+/* VIDIOC_CREATE_BUFS */
+struct v4l2_create_buffers {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format format; /* type is used
always, the rest if sizeimage == 0 */
+ __u32 reserved[8];
+};
How about splitting the above comments? These lines are really long.
Kerneldoc could also be used, I think.
Sure, how about this incremental patch:
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Subject: V4L: improve struct v4l2_create_buffers documentation
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 988e1be..64e0bf2 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2095,12 +2095,20 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
-/* VIDIOC_CREATE_BUFS */
+/**
+ * struct v4l2_create_buffers - VIDIOC_CREATE_BUFS argument
+ * @index: on return, index of the first created buffer
+ * @count: entry: number of requested buffers,
+ * return: number of created buffers
+ * @memory: buffer memory type
+ * @format: frame format, for which buffers are requested
+ * @reserved:future extensions
+ */
struct v4l2_create_buffers {
- __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 index;
__u32 count;
enum v4l2_memorymemory;
- struct v4l2_format format; /* type is used always, the
rest if sizeimage == 0 */
+ struct v4l2_format format;
__u32 reserved[8];
};
Thanks! This looks good to me. Could you do a similar change to the
compat-IOCTL version of this struct (v4l2_create_buffers32)?
Of course, I'll submit an incremental patch as soon as this is accepted
for upstream, unless there are other important changes to this patch and a
new revision is anyway unavoidable.
Ok. I'll send a small patch to the documentation as well then.
Good, thanks!
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
#defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_PREPARE_BUF _IOW('V', 93, struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return anything to
the
user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have I
misunderstood you?
I was thinking if this will be the case now and in the foreseeable future
as
this can't be changed after once defined. I just wanted to bring this up
even though I don't see myself that any of the fields would need to be
returned to the user. But there are reserved fields...
So unless someone comes up with something quick, I think this should stay
as-is.
Agree. I understand, it is important to try to design the user-space API
as clever as possible, so, I'm relying on our combined wisdom for it. But
even that is probably limited, so, mistakes are still possible. Therefore,
unless someone comes up with a realistic reason, why this has to be _IOWR,
we shall keep it _IOW and be prepared to delight our user-space colleagues
with more shiny new ioctl()s in the somewhat near future;-)
What we could also do is to mark the new IOCTLs experimental, and remove
the note after one or two more kernel
Re: [PATCH 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
On Thu, Sep 01, 2011 at 12:51:58PM +0200, Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:03:52AM +0200, Guennadi Liakhovetski wrote:
Hi Sakari
Hi Guennadi,
On Thu, 1 Sep 2011, Sakari Ailus wrote:
[clip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..988e1be 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -653,6 +653,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_ERROR 0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is
valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
+/* Cache handling flags */
+#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0400
+#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
/*
* O V E R L A Y P R E V I E W
@@ -2092,6 +2095,15 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
+/* VIDIOC_CREATE_BUFS */
+struct v4l2_create_buffers {
+ __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format format; /* type is used
always, the rest if sizeimage == 0 */
+ __u32 reserved[8];
+};
How about splitting the above comments? These lines are really long.
Kerneldoc could also be used, I think.
Sure, how about this incremental patch:
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Subject: V4L: improve struct v4l2_create_buffers documentation
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 988e1be..64e0bf2 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2095,12 +2095,20 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
-/* VIDIOC_CREATE_BUFS */
+/**
+ * struct v4l2_create_buffers - VIDIOC_CREATE_BUFS argument
+ * @index: on return, index of the first created buffer
+ * @count: entry: number of requested buffers,
+ * return: number of created buffers
+ * @memory:buffer memory type
+ * @format:frame format, for which buffers are requested
+ * @reserved: future extensions
+ */
struct v4l2_create_buffers {
- __u32 index; /* output: buffers
index...index + count - 1 have been created */
+ __u32 index;
__u32 count;
enum v4l2_memorymemory;
- struct v4l2_format format; /* type is used
always, the rest if sizeimage == 0 */
+ struct v4l2_format format;
__u32 reserved[8];
};
Thanks! This looks good to me. Could you do a similar change to the
compat-IOCTL version of this struct (v4l2_create_buffers32)?
Of course, I'll submit an incremental patch as soon as this is accepted
for upstream, unless there are other important changes to this patch and
a
new revision is anyway unavoidable.
Ok. I'll send a small patch to the documentation as well then.
Good, thanks!
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_PREPARE_BUF_IOW('V', 93, struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return anything
to the
user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have I
misunderstood you?
I was thinking if this will be the case now and in the foreseeable
future as
this can't be changed after once defined. I just wanted to bring this up
even though I don't see myself that any of the fields would need to be
returned to the user. But there are reserved fields...
So unless someone comes up with something quick, I think this should stay
as-is.
Agree. I understand, it is important to try to design the user-space API
as clever as possible, so, I'm relying on our combined wisdom for it. But
even that is probably limited, so, mistakes are still possible.
Therefore,
unless someone comes up with a realistic reason, why this has to be
_IOWR,
we shall keep it _IOW and be
[PATCH 1/1] v4l: Add note on buffer locking to memory and DMA mapping to PREPARE_BUF
Add note to documentation of VIDIOC_PREPARE_BUF that the preparation done by the IOCTL may include locking buffers to system memory and creating DMA mappings for them. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- .../DocBook/media/v4l/vidioc-prepare-buf.xml |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml b/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml index 509e752..7177c2f 100644 --- a/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml @@ -52,9 +52,11 @@ constantVIDIOC_PREPARE_BUF/constant ioctl to pass ownership of the buffer to the driver before actually enqueuing it, using the constantVIDIOC_QBUF/constant ioctl, and to prepare it for future I/O. -Such preparations may include cache invalidation or cleaning. Performing them -in advance saves time during the actual I/O. In case such cache operations are -not required, the application can use one of +Such preparations may include locking the buffer to system memory and +creating DMA mapping for it (on the first time +constantVIDIOC_PREPARE_BUF/constant is called), cache invalidation or +cleaning. Performing them in advance saves time during the actual I/O. In +case such cache operations are not required, the application can use one of constantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant and constantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant flags to skip the respective step./para -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add camera controls for the ov5642 driver
On Thu, Sep 01, 2011 at 11:14:08AM +0200, Sylwester Nawrocki wrote: Hi Sakari, On 09/01/2011 10:47 AM, Sakari Ailus wrote: On Thu, Sep 01, 2011 at 09:15:20AM +0200, Guennadi Liakhovetski wrote: On Thu, 1 Sep 2011, Sakari Ailus wrote: On Wed, Aug 31, 2011 at 03:27:49PM +, Bastian Hecht wrote: 2011/8/28 Laurent Pinchart laurent.pinch...@ideasonboard.com: [clip] If I'm not mistaken V4L2_CID_PRIVATE_BASE is deprecated. I checked at http://v4l2spec.bytesex.org/spec/x542.htm, googled V4L2_CID_PRIVATE_BASE deprecated and read Documentation/feature-removal-schedule.txt. I couldn't find anything. Hmm. Did you happen to check when that has been written? :) Please use this one instead: URL:http://hverkuil.home.xs4all.nl/spec/media.html Drivers can also implement their own custom controls using V4L2_CID_PRIVATE_BASE and higher values. Which specific location describes V4L2_CID_PRIVATE_BASE differently there? That was a general comment, not related to the private base. There's no use for a three-year-old spec as a reference! The control framework does not support private controls, for example. The controls should be put to their own class in videodev2.h nowadays, that's my understanding. Cc Hans. Is this really the case that we close the door for private controls in the mainline kernel ? Or am I misunderstanding something ? How about v4l2_ctrl_new_custom() ? What if there are controls applicable to single driver only ? Do we really want to have plenty of such in videodev2.h ? We have some of those already in videodev2.h. I'm not certain if I'm happy with this myself, considering e.g. that we could get a few truckloads of only camera lens hardware specific controls in the near future. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/21] [media] tuner/xc2028: Fix frequency offset for radio mode.
Hi Thierry,
I have been having problems with the radio tuner in my leadtek 1800h
card. This card has the xc2028 tuner. Using fmtools i would get an error
message similar to - frequency out of range 0.0 - 0.0.
After seeing you patches at the beginning of last month I installed the
recent drivers at the time and applied your patches. The frequency out
of range error went away but the only sound I got was static. I then
discovered the frequency is out by 2.7MHz, so if I want to listen to
104.9 I need to tune the radio to 107.6.
On Ubuntu 10.04 the card works fine, the errors started when applying
the recent V4L drivers that I require for another card.
Are you able to help resolve this problem and get this card working
properly again.
Thanks
Andrew
On 1/09/2011 3:10 PM, Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
Em 04-08-2011 04:14, Thierry Reding escreveu:
In radio mode, no frequency offset is needed. While at it, split off the
frequency offset computation for digital TV into a separate function.
Nah, it is better to keep the offset calculation there. there is already
a set_freq for DVB. breaking the frequency logic even further seems to
increase the driver's logic. Also, patch is simpler and easier to review.
Okay, no problem. Feel free to replace the patch with yours.
The patch bellow seems to be better. On a quick review, I think that the
send_seq(priv, {0x00, 0x00})
sequence may be wrong. I suspect that the device is just discarding that,
but changing it needs more testing.
I ran across that as well, but I didn't dare touch it because I wasn't sure
what the broader impact would be.
Thierry
--
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: Getting started with OMAP3 ISP
On 2011-09-01 03:51, Enrico wrote: On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2. Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward: Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628 Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628 I'm at nearly the same point, but I'm getting a couple of strange messages: # media-ctl -r -l 'tvp5150m1 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] # media-ctl -f 'tvp5150m1 2-005c:0[UYVY 720x480], OMAP3 ISP CCDC:0[UYVY 720x480], OMAP3 ISP CCDC:1[UYVY 720x480]' Setting up format UYVY 720x480 on pad tvp5150m1 2-005c/0 Format set: unknown 720x480 Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0 Format set: unknown 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1 Format set: UYVY 720x480 # yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: UYVY (59565955) 720x480 buffer size 691200 Video format: UYVY (59565955) 720x480 buffer size 691200 6 buffers requested. length: 691200 offset: 0 Buffer 0 mapped at address 0x40211000. length: 691200 offset: 692224 Buffer 1 mapped at address 0x402dc000. length: 691200 offset: 1384448 Buffer 2 mapped at address 0x4047f000. length: 691200 offset: 2076672 Buffer 3 mapped at address 0x40614000. length: 691200 offset: 2768896 Buffer 4 mapped at address 0x40792000. Buffer 5 mapped at address 0x40854000. Unable to start streaming: 32. What does 'Format set: unknown 720x480' mean from media-ctl? Why 'Unable to start streaming: 32' - is this an EPIPE error? Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch. I tried also to route it through the resizer but nothing changes. Is it normal that --enum-formats returns this? Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. - Available formats: Video format: () 0x0 buffer size 0 Thanks, Enrico -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Getting started with OMAP3 ISP
Hi Gary, On Thursday 01 September 2011 14:50:59 Gary Thomas wrote: On 2011-09-01 03:51, Enrico wrote: On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote: On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp - omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2. Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward: Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628 Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628 I'm at nearly the same point, but I'm getting a couple of strange messages: # media-ctl -r -l 'tvp5150m1 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] # media-ctl -f 'tvp5150m1 2-005c:0[UYVY 720x480], OMAP3 ISP CCDC:0[UYVY 720x480], OMAP3 ISP CCDC:1[UYVY 720x480]' Setting up format UYVY 720x480 on pad tvp5150m1 2-005c/0 Format set: unknown 720x480 Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0 Format set: unknown 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1 Format set: UYVY 720x480 # yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: UYVY (59565955) 720x480 buffer size 691200 Video format: UYVY (59565955) 720x480 buffer size 691200 6 buffers requested. length: 691200 offset: 0 Buffer 0 mapped at address 0x40211000. length: 691200 offset: 692224 Buffer 1 mapped at address 0x402dc000. length: 691200 offset: 1384448 Buffer 2 mapped at address 0x4047f000. length: 691200 offset: 2076672 Buffer 3 mapped at address 0x40614000. length: 691200 offset: 2768896 Buffer 4 mapped at address 0x40792000. Buffer 5 mapped at address 0x40854000. Unable to start streaming: 32. What does 'Format set: unknown 720x480' mean from media-ctl? That probably means that media-ctl got compiled against a different media controller API version than the one running on your system. Make sure you set the --with-kernel-headers= to the path to kernel headers for the kernel running on your system. Why 'Unable to start streaming: 32' - is this an EPIPE error? That means the pipeline hasn't been configured properly. Either the pipeline is broken, or formats on two ends of a link don't match. Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch. I tried also to route it through the resizer but nothing changes. Is it normal that --enum-formats returns this? Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. - Available formats: Video format: () 0x0 buffer size 0 -- 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 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Sakari,
On Thursday 01 September 2011 13:06:12 Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 12:51:58PM +0200, Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
Guennadi Liakhovetski wrote:
On Thu, 1 Sep 2011, Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 09:03:52AM +0200, Guennadi Liakhovetski
wrote:
Hi Sakari
Hi Guennadi,
On Thu, 1 Sep 2011, Sakari Ailus wrote:
[clip]
diff --git a/include/linux/videodev2.h
b/include/linux/videodev2.h index fca24cc..988e1be 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -653,6 +653,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_ERROR0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is
valid
*/ #define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is
valid */
+/* Cache handling flags */
+#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0400
+#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x0800
/*
* O V E R L A Y P R E V I E W
@@ -2092,6 +2095,15 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
+/* VIDIOC_CREATE_BUFS */
+struct v4l2_create_buffers {
+ __u32 index; /* output: buffers
index...index + count
- 1
have been created */ + __u32 count;
+ enum v4l2_memorymemory;
+ struct v4l2_format format; /* type is used
always, the
rest
if sizeimage == 0 */ + __u32 reserved[8];
+};
How about splitting the above comments? These lines are really
long. Kerneldoc could also be used, I think.
Sure, how about this incremental patch:
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Subject: V4L: improve struct v4l2_create_buffers documentation
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 988e1be..64e0bf2 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2095,12 +2095,20 @@ struct v4l2_dbg_chip_ident {
__u32 revision;/* chip revision, chip specific */
} __attribute__ ((packed));
-/* VIDIOC_CREATE_BUFS */
+/**
+ * struct v4l2_create_buffers - VIDIOC_CREATE_BUFS argument
+ * @index: on return, index of the first created buffer
+ * @count: entry: number of requested buffers,
+ * return: number of created buffers
+ * @memory: buffer memory type
+ * @format: frame format, for which buffers are requested
+ * @reserved:future extensions
+ */
struct v4l2_create_buffers {
- __u32 index; /* output: buffers
index...index + count - 1
have
been created */ + __u32 index;
__u32 count;
enum v4l2_memorymemory;
- struct v4l2_format format; /* type is used
always, the
rest if
sizeimage == 0 */ + struct v4l2_format format;
__u32 reserved[8];
};
Thanks! This looks good to me. Could you do a similar change to the
compat-IOCTL version of this struct (v4l2_create_buffers32)?
Of course, I'll submit an incremental patch as soon as this is
accepted for upstream, unless there are other important changes to
this patch and a new revision is anyway unavoidable.
Ok. I'll send a small patch to the documentation as well then.
Good, thanks!
+
/*
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT
_IOW('V', 91, struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers) +#define VIDIOC_PREPARE_BUF _IOW('V', 93,
struct v4l2_buffer)
Does prepare_buf ever do anything that would need to return
anything to the user? I guess the answer is no?
Exactly, that's why it's an _IOW ioctl(), not an _IOWR, or have
I misunderstood you?
I was thinking if this will be the case now and in the foreseeable
future as this can't be changed after once defined. I just wanted
to bring this up even though I don't see myself that any of the
fields would need to be returned to the user. But there are
reserved fields...
So unless someone comes up with something quick, I think this should
stay as-is.
Agree. I understand, it is important to try to design the user-space
API as clever as
Re: [PATCH 2/9 v6] V4L: add two new ioctl()s for multi-size videobuffer management
On Thu, 1 Sep 2011, Laurent Pinchart wrote: Hi Sakari, On Thursday 01 September 2011 13:06:12 Sakari Ailus wrote: [snip] That's my understanding, but of course someone could just say no when we try to do that. I think that if something is marked experimental at least the argument that it can't be changed is a little bit moot since the users have been notified of this beforehand. There are a few examples of this. At least the V4L2 subdev and MC interfaces are marked experimental. However, we haven't actually tried to use that to make changes which might break user space since we haven't got a need to. Hans, Laurent: do you have an opinion on this? We should of course try to keep the API and ABI compatible across kernel versions, but experimental APIs can be changed. It also depends on how widely the API has been picked up by userspace and how much the changes would break it. Being experimental isn't an excuse for making userspace's life a nightmare. Right, they deserve it regardless;-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9t001: Aptina (Micron) MT9T001 3MP sensor driver
Hi Sakari,
On Thursday 01 September 2011 12:33:11 Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 11:05:05AM +0200, Laurent Pinchart wrote:
On Wednesday 31 August 2011 20:23:33 Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 02:24:12PM +0200, Laurent Pinchart wrote:
The MT9T001 is a parallel 3MP sensor from Aptina (formerly Micron)
controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports binning
and cropping, and the gain, exposure, test pattern and black level
controls.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
[snip]
+#define V4L2_CID_TEST_PATTERN (V4L2_CID_USER_BASE | 0x1001)
Thest pattern is something that almost every sensor have.
+#define V4L2_CID_GAIN_RED (V4L2_CTRL_CLASS_CAMERA |
0x1001)
+#define V4L2_CID_GAIN_GREEN1 (V4L2_CTRL_CLASS_CAMERA |
0x1002)
+#define V4L2_CID_GAIN_GREEN2 (V4L2_CTRL_CLASS_CAMERA |
0x1003)
[snip]
Also these are quite low level controls as opposed to the other higher
level controls in this class. I wonder if creating a separate class for
them would make sense. We'll need a new class for the hblank/vblank
controls anyway. I might call it sensor.
These controls could be also standardised.
I agree.
A sensor control class might make sense for these 5 controls, but they
can also be useful for non-sensor hardware (for instance with an analog
pixel decoder).
What about calling it differently then?
V4L2_CTRL_CLASS_SOURCE
V4L2_CTRL_CLASS_IMAGE_SOURCE
V4L2_CTRL_CLASS_MBUS_SOURCE
Calling differently is probably a good idea. I'm not sure which name is the
best though. I need to sleep on that.
Gain is an issue, as it can be applied at any stage in the pipeline. As such
it doesn't really belong to a source class.
+#define V4L2_CID_GAIN_BLUE (V4L2_CTRL_CLASS_CAMERA |
0x1004)
+
+static int mt9t001_gain_data(s32 *gain)
+{
+ /* Gain is controlled by 2 analog stages and a digital stage.
Valid
+* values for the 3 stages are
+*
+* StageMin Max Step
+* --
+* First analog stage x1 x2 1
+* Second analog stage x1 x4 0.125
+* Digital stagex1 x16 0.125
+*
+* To minimize noise, the gain stages should be used in the
second
+* analog stage, first analog stage, digital stage order. Gain
from
a + * previous stage should be pushed to its maximum value before
the next + * stage is used.
+*/
+ if (*gain = 32)
+ return *gain;
+
+ if (*gain = 64) {
+ *gain = ~1;
+ return (1 6) | (*gain 1);
+ }
+
+ *gain = ~7;
+ return ((*gain - 64) 5) | (1 6) | 32;
+}
This one looks very similar to another Aptina sensor driver. My comment
back then was that the analog and digital gain should be separate
controls as the user typically would e.g. want to know (s)he's using
digital gain instead of analog one.
What about implementing this?
It's a good question whether we need one or two new controls. If the
answer is two, then how do they relate to the existing control?
I'm not too sure about this. If an application needs that much control
over the hardware, wouldn't it be hardware-specific anyway, and know
about control ranges ? The mt9t001 actually has 3 gain stages, so one
might even argue that we should expose 3 gain controls :-)
At least we should have two different ones. The driver might implement a
policy for the single exposure control which would be combination of the
two, but I'd rather see this done more genericly in libv4l: the algorithm
is trivial and the same, and I also think this is relatively generic.
The algorithm isn't that generic, it depends on the hardware and how the gain
stages are implemented.
I don't think there's a need to show the secondary analog gain stage to the
user, especially if the relation of the two stages is so simple. Are the
units also the same?
I'm not sure what you mean here. Gains have no units :-)
--
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] media: none of the drivers should be enabled by default
Em 01-09-2011 03:39, Guennadi Liakhovetski escreveu: Hi Mauro On Wed, 31 Aug 2011, Mauro Carvalho Chehab wrote: [snip] I can't comment on the remote controller drivers as I haven't been involved with that. Mauro? If RC is disabled, most PC cards don't work (bttv, cx88, ivtv, dvb-usb, ...). Ok, this is due to a lack of proper module support on those drivers, but changing it requires some work on each driver that depends on RC. wouldn't a simple select RC_CORE in those drivers solve this? E.g., for BT848 diff --git a/drivers/media/video/bt8xx/Kconfig b/drivers/media/video/bt8xx/Kconfig index 7da5c2e..28c087bd 100644 --- a/drivers/media/video/bt8xx/Kconfig +++ b/drivers/media/video/bt8xx/Kconfig @@ -4,7 +4,7 @@ config VIDEO_BT848 select I2C_ALGOBIT select VIDEO_BTCX select VIDEOBUF_DMA_SG - depends on RC_CORE + select RC_CORE The usage of select is evil and tricky, as select doesn't validate dependency of the selected symbol. With the above line, Kernel compilation will break if INPUT is not selected, as you forgot to add: depends on INPUT We had exactly this bug reported in the past. We should really get rid of selects, especially when the selected symbol has dependencies. Also, the long term idea is to do things like: config VIDEO_BT848_INPUT depends on RC_CORE And change the drivers to allow compiling with RC disabled. We did this already for a couple drivers (saa7134 and em28xx). One option to not use select would be to do the reverse, as the Kbuild maintainers pointed us: using the same strategy as we did for tuners. E. g., using one approach like: config RC_CORE depends on VIDEO_BT848 | VIDEO_CX88 | ... default y The problem with this approach is that people will forget to update the RC_CORE dependency as new cards were added (we tried things like that in the past). So, the solution should be, instead: config MEDIA_TV tristate Enable TV/grabber devices config VIDEO_BT848 depends on MEDIA_TV config RC_CORE depends on MEDIA_TV if MEDIA_TV default y if MEDIA_TV Again, the problem is that a few Webcam devices are supported by the same driver that also provide TV support. So, we'll need to add the option for the user to select such on both the MEDIA_TV and the MEDIA_WEBCAM groups. Hmm... maybe we can do something different, grouping devices by their support bus: menuconfig MEDIA_PCI # put here all PCI devices menuconfig MEDIA_USB # put here all PCI devices menuconfig MEDIA_SOC # put here all SoC devices that aren't connected via PCI or USB config MEDIA_TV depends on MEDIA_PCI | MEDIA_USB | DVB_CORE config RC_CORE depends on MEDIA_TV if MEDIA_TV default y if MEDIA_TV This way, the default for RC_CORE will be N. It will only be activated if a PCI or USB device is selected, or if the user manually selects it, in order to enable a RC only device. This also means that the ISA and PARPORT devices will have their own menu. select VIDEO_TUNER select VIDEO_TVEEPROM select VIDEO_MSP3400 if VIDEO_HELPER_CHIPS_AUTO and deselect RC_CORE: diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 899f783..259a3e7 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -1,7 +1,6 @@ menuconfig RC_CORE tristate Remote Controller adapters depends on INPUT - default INPUT ---help--- Enable support for Remote Controllers on Linux. This is needed in order to support several video capture adapters. This way by default you have no RCs, but as soon as you enable one card, like bttv, you get all potentially needed drivers. Also, if RC is selected, the RC decoder protocols need to be enabled by default, as otherwise several devices will stop working, as, on modern devices, there's no hardware anymore to decode the IR pulses. The RC protocol Kconfig options are there, in fact, to allow disabling some RC decoding protocol when people are 100% sure that such software decoder won't be needed on some particular environment. Ok, they can be selected. Or even I don't mind them being turned on by default, when RC is on, as long as RC itself is off by default. With regards to the tuners: perhaps it is sufficient to default MEDIA_ATTACH to 'y'? That should prevent building those tuners that are not needed. Sorry, I don't see how this should work. I mean tuners under drivers/media/common/tuners/. I wouldn't change anything else here. Tuners are required for all TV and DVB cards. Maybe we can put an explicit Kconfig item for TV devices, and change the config stuff to something like: config MEDIA_NEED_TUNER tristate menuconfig MEDIA_TV tristate TV and grabber cards select MEDIA_NEED_TUNER ... menuconfig MEDIA_WEBCAMS tristate Webcameras ... config DVB_CORE tristate DVB for Linux
Re: Getting started with OMAP3 ISP
On Thu, Sep 1, 2011 at 12:24 PM, Enrico ebut...@users.berlios.de wrote:
On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart
Does your tvp5150 generate progressive or interlaced images ?
In the driver it is setup to decode by default in bt656 mode, so interlaced.
I've read on the omap trm that the isp can deinterlace it setting
properly SDOFST, i just noticed in the register dump this:
omap3isp omap3isp: ###CCDC SDOFST=0x
and maybe this is related too:
omap3isp omap3isp: ###CCDC REC656IF=0x
Moreover i just found this [1] old thread about the same problem, i'm
reading it now.
Enrico
[1]: http://www.spinics.net/lists/linux-media/msg28079.html
Still not working, and much more doubts :D
1) In board code isp_parallel_platform_data i added the bt656 = 1
setting and i see it gets applied, but reading code and omap trm i've
found that you must set ISPCCDC_REC656IF_ECCFVH flag too.
2) ispccdc.c:ccdc_config_outlineoffset(..) seems broken to me.
It is used only once in ccdc_configure:
ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0, 0);
so the last two parameters are always set to 0, while they should be
(conditionally) set with for ex. EVENODD, 1
Moreover the implementation has this (hope it will keep formatting...):
switch (oddeven) {
case EVENEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7) ISPCCDC_SDOFST_LOFST0_SHIFT);
break;
case ODDEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7) ISPCCDC_SDOFST_LOFST1_SHIFT);
break;
case EVENODD:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7) ISPCCDC_SDOFST_LOFST2_SHIFT);
break;
case ODDODD:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7) ISPCCDC_SDOFST_LOFST3_SHIFT);
break;
default:
break;
}
But reading the omap trm (Figure 12-77) it seems to me that all the
LOFSTX should be set.
3) Last but not least, i'm using V4L2_MBUS_FMT_UYVY8_1X16 format in
tvp5150, but i'm not sure it is correct. What is the proper format for
bt656? Maybe V4L2_MBUS_FMT_UYVY8_2X8?
Thanks,
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 5/7 v5] V4L: vb2: add support for buffers of different sizes on a single queue
Hi Pawel
On Mon, 29 Aug 2011, Guennadi Liakhovetski wrote:
On Sun, 28 Aug 2011, Pawel Osciak wrote:
[snip]
Could you share the userspace code that you used for testing this? I
just wanted to get a feel of how those new ioctls fall into place
together.
Theoretically - yes, just will have to clean up the code a bit;-) Will try
to find some time for this in the next couple of days.
Below is a patch to the current capture-example.c. It is not extremely
intelligent, many things are hard-coded, but you should get the idea.
Also, did you try multiple CREATE_BUFS calls?
Yes, it currently does two CREATE_BUFS, I might try to mix REQBUFS with
CREATE_BUFS too though.
With this patch you can use the -q flag to choose, whether you want your
first buffers to be allocated per REQBUFS or CREATE_BUFS. Both options
work.
Locally I have an even much dirtier, but more useful version of this
patch, that draws one buffer size on the framebuffer, and stores the other
one in .pgm files, all works well.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
diff --git a/contrib/test/capture-example.c b/contrib/test/capture-example.c
index 417615a..ab0d8fb 100644
--- a/contrib/test/capture-example.c
+++ b/contrib/test/capture-example.c
@@ -38,14 +38,23 @@ struct buffer {
size_t length;
};
+enum {
+ false = 0,
+ true= 1
+};
+
static char*dev_name;
static enum io_method io = IO_METHOD_MMAP;
static int fd = -1;
struct buffer *buffers;
-static unsigned int n_buffers;
+static unsigned int n_buffers, n_buffers_alt;
static int out_buf;
static int force_format;
static int frame_count = 70;
+static unsigned intwidth, height, fourcc, colorspace;
+static unsigned intwidth_alt = 320, height_alt = 240,
+ fourcc_alt = V4L2_PIX_FMT_NV12, colorspace_alt = V4L2_COLORSPACE_JPEG;
+static _Bool use_request;
static void errno_exit(const char *s)
{
@@ -64,6 +73,61 @@ static int xioctl(int fh, unsigned long int request, void
*arg)
return r;
}
+static int create_buffers(unsigned int *width, unsigned int *height,
+ unsigned int fcc, unsigned int clrspc, int n)
+{
+ int i, ret;
+ struct v4l2_create_buffers create = {
+ .memory = V4L2_MEMORY_MMAP,
+ .count = n,
+ .format = {
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .fmt.pix = {
+ .width = *width,
+ .height = *height,
+ .pixelformat = fcc,
+ .field = V4L2_FIELD_ANY,
+ .colorspace = clrspc,
+ },
+ },
+ };
+ struct v4l2_buffer buf = {
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .memory = V4L2_MEMORY_MMAP,
+ .field = V4L2_FIELD_ANY,
+ };
+ struct v4l2_pix_format *pix = create.format.fmt.pix;
+
+ ret = xioctl(fd, VIDIOC_TRY_FMT, create.format);
+ if (ret 0) {
+ fprintf(stderr, TRY_FMT should never fail!: %d\n, ret);
+ errno_exit(VIDIOC_TRY_FMT);
+ }
+ fprintf(stderr, TRY_FMT(%ux%u:%x) - %u\n, pix-width, pix-height,
+pix-pixelformat, pix-sizeimage);
+
+ *width = pix-width;
+ *height = pix-height;
+
+ ret = xioctl(fd, VIDIOC_CREATE_BUFS, create);
+ if (ret 0)
+ errno_exit(VIDIOC_CREATE_BUFS);
+
+ fprintf(stderr, CREATE_BUFS(%d@%d)\n, create.count, create.index);
+
+ for (i = create.index; i create.index + create.count; i++) {
+ buf.index = i;
+ ret = xioctl(fd, VIDIOC_PREPARE_BUF, buf);
+ if (ret 0)
+ errno_exit(VIDIOC_PREPARE_BUF);
+ }
+
+ if (i create.index)
+ return i - create.index;
+
+ return ret;
+}
+
static void process_image(const void *p, int size)
{
if (out_buf)
@@ -74,7 +138,7 @@ static void process_image(const void *p, int size)
fflush(stdout);
}
-static int read_frame(void)
+static int read_frame(_Bool do_queue)
{
struct v4l2_buffer buf;
unsigned int i;
@@ -120,11 +184,11 @@ static int read_frame(void)
}
}
- assert(buf.index n_buffers);
+ assert(buf.index n_buffers + n_buffers_alt);
process_image(buffers[buf.index].start, buf.bytesused);
- if (-1 == xioctl(fd, VIDIOC_QBUF, buf))
+ if (do_queue -1 == xioctl(fd, VIDIOC_QBUF, buf))
errno_exit(VIDIOC_QBUF);
break;
@@ -154,11 +218,11 @@ static int read_frame(void)
buf.length == buffers[i].length)
Re: Getting started with OMAP3 ISP
Hi Enrico,
On Thursday 01 September 2011 16:12:42 Enrico wrote:
On Thu, Sep 1, 2011 at 12:24 PM, Enrico ebut...@users.berlios.de wrote:
On Thu, Sep 1, 2011 at 11:55 AM, Laurent Pinchart
Does your tvp5150 generate progressive or interlaced images ?
In the driver it is setup to decode by default in bt656 mode, so
interlaced.
I've read on the omap trm that the isp can deinterlace it setting
properly SDOFST, i just noticed in the register dump this:
omap3isp omap3isp: ###CCDC SDOFST=0x
and maybe this is related too:
omap3isp omap3isp: ###CCDC REC656IF=0x
Moreover i just found this [1] old thread about the same problem, i'm
reading it now.
Enrico
[1]: http://www.spinics.net/lists/linux-media/msg28079.html
Still not working, and much more doubts :D
1) In board code isp_parallel_platform_data i added the bt656 = 1
setting and i see it gets applied, but reading code and omap trm i've
found that you must set ISPCCDC_REC656IF_ECCFVH flag too.
That's not mandatory, but I suppose it wouldn't hurt.
2) ispccdc.c:ccdc_config_outlineoffset(..) seems broken to me.
It is used only once in ccdc_configure:
ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0, 0);
so the last two parameters are always set to 0, while they should be
(conditionally) set with for ex. EVENODD, 1
Moreover the implementation has this (hope it will keep formatting...):
switch (oddeven) {
case EVENEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7)
ISPCCDC_SDOFST_LOFST0_SHIFT); break;
case ODDEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7)
ISPCCDC_SDOFST_LOFST1_SHIFT); break;
case EVENODD:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7)
ISPCCDC_SDOFST_LOFST2_SHIFT); break;
case ODDODD:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
(numlines 0x7)
ISPCCDC_SDOFST_LOFST3_SHIFT); break;
default:
break;
}
But reading the omap trm (Figure 12-77) it seems to me that all the
LOFSTX should be set.
The driver currently has no support for interlaced video. This code has never
been properly tested.
3) Last but not least, i'm using V4L2_MBUS_FMT_UYVY8_1X16 format in
tvp5150, but i'm not sure it is correct. What is the proper format for
bt656? Maybe V4L2_MBUS_FMT_UYVY8_2X8?
You should use V4L2_MBUS_FMT_UYVY8_2X8, as video data is transmitted on a 8-
bit bus with two samples per pixel.
--
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] mt9t001: Aptina (Micron) MT9T001 3MP sensor driver
On Thu, Sep 01, 2011 at 03:48:22PM +0200, Laurent Pinchart wrote:
Hi Sakari,
On Thursday 01 September 2011 12:33:11 Sakari Ailus wrote:
On Thu, Sep 01, 2011 at 11:05:05AM +0200, Laurent Pinchart wrote:
On Wednesday 31 August 2011 20:23:33 Sakari Ailus wrote:
On Wed, Aug 31, 2011 at 02:24:12PM +0200, Laurent Pinchart wrote:
The MT9T001 is a parallel 3MP sensor from Aptina (formerly Micron)
controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports binning
and cropping, and the gain, exposure, test pattern and black level
controls.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
[snip]
+#define V4L2_CID_TEST_PATTERN(V4L2_CID_USER_BASE |
0x1001)
Thest pattern is something that almost every sensor have.
+#define V4L2_CID_GAIN_RED(V4L2_CTRL_CLASS_CAMERA |
0x1001)
+#define V4L2_CID_GAIN_GREEN1 (V4L2_CTRL_CLASS_CAMERA |
0x1002)
+#define V4L2_CID_GAIN_GREEN2 (V4L2_CTRL_CLASS_CAMERA |
0x1003)
[snip]
Also these are quite low level controls as opposed to the other higher
level controls in this class. I wonder if creating a separate class for
them would make sense. We'll need a new class for the hblank/vblank
controls anyway. I might call it sensor.
These controls could be also standardised.
I agree.
A sensor control class might make sense for these 5 controls, but they
can also be useful for non-sensor hardware (for instance with an analog
pixel decoder).
What about calling it differently then?
V4L2_CTRL_CLASS_SOURCE
V4L2_CTRL_CLASS_IMAGE_SOURCE
V4L2_CTRL_CLASS_MBUS_SOURCE
Calling differently is probably a good idea. I'm not sure which name is the
best though. I need to sleep on that.
Gain is an issue, as it can be applied at any stage in the pipeline. As such
it doesn't really belong to a source class.
True. Analog gain does still belong there.
We might need more than one new class.
+#define V4L2_CID_GAIN_BLUE (V4L2_CTRL_CLASS_CAMERA |
0x1004)
+
+static int mt9t001_gain_data(s32 *gain)
+{
+ /* Gain is controlled by 2 analog stages and a digital stage.
Valid
+ * values for the 3 stages are
+ *
+ * StageMin Max Step
+ * --
+ * First analog stage x1 x2 1
+ * Second analog stage x1 x4 0.125
+ * Digital stagex1 x16 0.125
+ *
+ * To minimize noise, the gain stages should be used in the
second
+ * analog stage, first analog stage, digital stage order. Gain
from
a +* previous stage should be pushed to its maximum value before
the next + * stage is used.
+ */
+ if (*gain = 32)
+ return *gain;
+
+ if (*gain = 64) {
+ *gain = ~1;
+ return (1 6) | (*gain 1);
+ }
+
+ *gain = ~7;
+ return ((*gain - 64) 5) | (1 6) | 32;
+}
This one looks very similar to another Aptina sensor driver. My comment
back then was that the analog and digital gain should be separate
controls as the user typically would e.g. want to know (s)he's using
digital gain instead of analog one.
What about implementing this?
It's a good question whether we need one or two new controls. If the
answer is two, then how do they relate to the existing control?
I'm not too sure about this. If an application needs that much control
over the hardware, wouldn't it be hardware-specific anyway, and know
about control ranges ? The mt9t001 actually has 3 gain stages, so one
might even argue that we should expose 3 gain controls :-)
At least we should have two different ones. The driver might implement a
policy for the single exposure control which would be combination of the
two, but I'd rather see this done more genericly in libv4l: the algorithm
is trivial and the same, and I also think this is relatively generic.
The algorithm isn't that generic, it depends on the hardware and how the gain
stages are implemented.
At least the et8ek8 prefers the same. There may be some parameters that
might be needed for the algorithm which might need to be a little more
complex than that.
I don't think there's a need to show the secondary analog gain stage to the
user, especially if the relation of the two stages is so simple. Are the
units also the same?
I'm not sure what you mean here. Gains have no units :-)
Uh, well, at least the granularity of the gain steps can be different in
different gain stages.
--
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of
Re: [PATCH 02/21] [media] tuner/xc2028: Fix frequency offset for radio mode.
Em 01-09-2011 09:45, Andrew Goff escreveu:
Hi Thierry,
I have been having problems with the radio tuner in my leadtek 1800h card.
This card has the xc2028 tuner. Using fmtools i would get an error message
similar to - frequency out of range 0.0 - 0.0.
This is due to a bug at the tuner core.
After seeing you patches at the beginning of last month I installed the
recent drivers at the time and applied your patches. The frequency out of
range error went away but the only sound I got was static. I then discovered
the frequency is out by 2.7MHz, so if I want to listen to 104.9 I need to
tune the radio to 107.6.
Try to remove Thierry xc3028 patch. His patches were applied already at the
main tree
(I applied them very early today).
On Ubuntu 10.04 the card works fine, the errors started when applying the
recent V4L drivers that I require for another card.
Are you able to help resolve this problem and get this card working properly
again.
Thanks
Andrew
On 1/09/2011 3:10 PM, Thierry Reding wrote:
* Mauro Carvalho Chehab wrote:
Em 04-08-2011 04:14, Thierry Reding escreveu:
In radio mode, no frequency offset is needed. While at it, split off the
frequency offset computation for digital TV into a separate function.
Nah, it is better to keep the offset calculation there. there is already
a set_freq for DVB. breaking the frequency logic even further seems to
increase the driver's logic. Also, patch is simpler and easier to review.
Okay, no problem. Feel free to replace the patch with yours.
The patch bellow seems to be better. On a quick review, I think that the
send_seq(priv, {0x00, 0x00})
sequence may be wrong. I suspect that the device is just discarding that,
but changing it needs more testing.
I ran across that as well, but I didn't dare touch it because I wasn't sure
what the broader impact would be.
Thierry
--
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: migrate soc-camera to the new V4L2 control framework
On Thursday, September 01, 2011 09:47:19 LBM wrote: Hello Hans Verkuil Thank you very much for your work for us about migrate soc-camera to the new V4L2 control framework! I can't find the full code about the migrate soc-camera to the new V4L2 control framework.I just see something on some PATCH.so, if you can email the full codes to me ? THANKS LEE The code is available here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/soc1 It's not quite ready yet: I found some issues with my patches for mt9m001, mt9m111 and mt9t031. I hope to address those in a few days. But the remainder of the patches is fine I believe. Unfortunately I am unable to test them since I have temporarily no access to a soc-camera platform. 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
Using atmel-isi for direct output on framebuffer ?
Hello Josh, I am currently looking at V4L2 and your atmel-isi driver for an AT91 based platform on which I would like the ISI interface to capture the image from a camera and have this image directly output in RGB format at a specific location on the screen (so that it can be nicely integrated into a Qt application for example). At the moment, I grab frames from the V4L2 device to userspace, do the YUV - RGB conversion manually in my application, and then displays the converted frame on the framebuffer thanks to normal Qt painting mechanisms. This works, but obviously consumes a lot of CPU. From the AT91 datasheet, I understand that the ISI interface is capable of doing the YUV - RGB conversion and is also capable of outputting the frame at some location in the framebuffer, but I don't see how to use this capability with the Linux V4L2 and framebuffer infrastructures. Is this possible ? If so, could you provide some pointers or starting points to get me started ? If not, what is missing in the driver ? Thanks a lot, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting started with OMAP3 ISP
On 2011-09-01 07:26, Laurent Pinchart wrote: Hi Gary, On Thursday 01 September 2011 14:50:59 Gary Thomas wrote: On 2011-09-01 03:51, Enrico wrote: On Wed, Aug 31, 2011 at 6:33 PM, Laurent Pinchart wrote: On http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp - omap3isp-next (sorry for not mentioning it), but the patch set was missing a patch. I've sent a v2. Thanks Laurent, i can confirm it is a step forward. With your tree and patches (and my tvp5150 patch) i made a step forward: Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up format UYVY 720x628 on pad tvp5150 2-005c/0 Format set: UYVY 720x628 Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x628 I'm at nearly the same point, but I'm getting a couple of strange messages: # media-ctl -r -l 'tvp5150m1 2-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] # media-ctl -f 'tvp5150m1 2-005c:0[UYVY 720x480], OMAP3 ISP CCDC:0[UYVY 720x480], OMAP3 ISP CCDC:1[UYVY 720x480]' Setting up format UYVY 720x480 on pad tvp5150m1 2-005c/0 Format set: unknown 720x480 Setting up format unknown 720x480 on pad OMAP3 ISP CCDC/0 Format set: unknown 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/0 Format set: UYVY 720x480 Setting up format UYVY 720x480 on pad OMAP3 ISP CCDC/1 Format set: UYVY 720x480 # yavta -f UYVY -s 720x480 -n 6 --capture=6 -F /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: UYVY (59565955) 720x480 buffer size 691200 Video format: UYVY (59565955) 720x480 buffer size 691200 6 buffers requested. length: 691200 offset: 0 Buffer 0 mapped at address 0x40211000. length: 691200 offset: 692224 Buffer 1 mapped at address 0x402dc000. length: 691200 offset: 1384448 Buffer 2 mapped at address 0x4047f000. length: 691200 offset: 2076672 Buffer 3 mapped at address 0x40614000. length: 691200 offset: 2768896 Buffer 4 mapped at address 0x40792000. Buffer 5 mapped at address 0x40854000. Unable to start streaming: 32. What does 'Format set: unknown 720x480' mean from media-ctl? That probably means that media-ctl got compiled against a different media controller API version than the one running on your system. Make sure you set the --with-kernel-headers= to the path to kernel headers for the kernel running on your system. To make sure, I just rebuilt 'media-ctl' against my latest kernel (headers). I'm using a OpenEmbedded derivative (Yocto) so this is all automatic. # bitbake virtual/kernel media-ctl -c cleansstate # bitbake virtual/kernel # bitbake media-ctl Sadly, I still get the same error. Why 'Unable to start streaming: 32' - is this an EPIPE error? That means the pipeline hasn't been configured properly. Either the pipeline is broken, or formats on two ends of a link don't match. Probably because of the unknown (above). Here's what the pertinent nodes say: - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [UYVY 720x480] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'tvp5150m1 2-005c':pad0 [ACTIVE] pad1: Output [UYVY 720x480] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [UYVY 720x479] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 16: tvp5150m1 2-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev8 pad0: Output [unknown 720x480 (1,1)/720x480] - 'OMAP3 ISP CCDC':pad0 [ACTIVE] Ideas where to look for the 'unknown' mode? Now the problem is that i can't get a capture with yavta, it blocks on the VIDIO_DQBUF ioctl. Probably something wrong in my patch. I tried also to route it through the resizer but nothing changes. Is it normal that --enum-formats returns this? Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. - Available formats: Video format: () 0x0 buffer size 0 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/19 v4] s5p-fimc driver conversion to media controller and control framework
Hello, following is a fourth version of the patchset converting s5p-fimc driver to the media controller API and the new control framework. Mauro, could you please have a look at the patches and let me know of any doubts? I tried to provide possibly detailed description of what each patch does and why. The changeset is available at: http://git.infradead.org/users/kmpark/linux-2.6-samsung branch: v4l_fimc_for_mauro on top of patches from Marek's 'Videobuf2 FIMC fixes pull request which this series depends on. Changes since v3: - more detailed commit descriptions - add missing dependency on EXPERIMENTAL and mark the driver as experimental in the config menu - removed the first patch as of v3 series, it has been posted separately - added 2 new patches: 18/19, 19/19 - moved the link_setup capture video node media entity operation to the capture subdev entity; the link_setup op prevented having 2 active source attached to single data sink, there is no need for this at the video node entity as it has only an immutable link; Instead we guard the number of sources being connected to the FIMC capture subdev - rebased onto recent vb2 modifications changing the queue initialization order - s/fimc_start_capture/fimc_init_capture, s/fimc_capture_apply_cfg/fimc_capture_config_update - slightly improved the comments and fixed typos Changes since v2: - reworked (runtime) power management; - added pm_runtime_get_sync/pm_runtime_put around sensor registration code so the clock for sensors is enabled during host driver's probe(); - reworked try_crop operation handler to support multiple of the prescaler ratio relationship constraint for format at the sink pad; - corrected fimc_md_unregister_entities() function Sylwester Nawrocki (19): s5p-fimc: Remove registration of video nodes from probe() s5p-fimc: Remove sclk_cam clock handling s5p-fimc: Limit number of available inputs to one s5p-fimc: Remove sensor management code from FIMC capture driver s5p-fimc: Remove v4l2_device from video capture and m2m driver s5p-fimc: Add the media device driver s5p-fimc: Conversion to use struct v4l2_fh s5p-fimc: Convert to the new control framework s5p-fimc: Add media operations in the capture entity driver s5p-fimc: Add PM helper function for streaming control s5p-fimc: Correct color format enumeration s5p-fimc: Convert to use media pipeline operations s5p-fimc: Add subdev for the FIMC processing block s5p-fimc: Add support for JPEG capture s5p-fimc: Add v4l2_device notification support for single frame capture s5p-fimc: Use consistent names for the buffer list functions s5p-fimc: Add runtime PM support in the camera capture driver s5p-fimc: Correct crop offset alignment on exynos4 s5p-fimc: Remove single-planar capability flags drivers/media/video/Kconfig |5 +- drivers/media/video/s5p-fimc/Makefile |2 +- drivers/media/video/s5p-fimc/fimc-capture.c | 1416 ++ drivers/media/video/s5p-fimc/fimc-core.c| 884 - drivers/media/video/s5p-fimc/fimc-core.h| 201 +++-- drivers/media/video/s5p-fimc/fimc-mdevice.c | 857 drivers/media/video/s5p-fimc/fimc-mdevice.h | 118 +++ drivers/media/video/s5p-fimc/fimc-reg.c | 74 +- drivers/media/video/s5p-fimc/regs-fimc.h|8 +- include/media/s5p_fimc.h| 11 + 10 files changed, 2551 insertions(+), 1025 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.c create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.h Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- 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 09/19 v4] s5p-fimc: Add media operations in the capture entity driver
Add the link_setup handler for the camera capture video node.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 32 +++
drivers/media/video/s5p-fimc/fimc-core.h|2 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 0c237a7..95996fb 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -669,6 +669,37 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_g_input = fimc_cap_g_input,
};
+/* Media operations */
+static int fimc_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct video_device *vd = media_entity_to_video_device(entity);
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(remote-entity);
+ struct fimc_dev *fimc = video_get_drvdata(vd);
+
+ if (WARN_ON(fimc == NULL))
+ return 0;
+
+ dbg(%s -- %s, flags: 0x%x. input: 0x%x,
+ local-entity-name, remote-entity-name, flags,
+ fimc-vid_cap.input);
+
+ if (flags MEDIA_LNK_FL_ENABLED) {
+ if (fimc-vid_cap.input != 0)
+ return -EBUSY;
+ fimc-vid_cap.input = sd-grp_id;
+ return 0;
+ }
+
+ fimc-vid_cap.input = 0;
+ return 0;
+}
+
+static const struct media_entity_operations fimc_media_ops = {
+ .link_setup = fimc_link_setup,
+};
+
/* fimc-lock must be already initialized */
int fimc_register_capture_device(struct fimc_dev *fimc,
struct v4l2_device *v4l2_dev)
@@ -743,6 +774,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
if (ret)
goto err_ent;
+ vfd-entity.ops = fimc_media_ops;
vfd-ctrl_handler = ctx-ctrl_handler;
return 0;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 1825e33..87a89f1 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -305,6 +305,7 @@ struct fimc_m2m_device {
* @reqbufs_count: the number of buffers requested in REQBUFS ioctl
* @input_index: input (camera sensor) index
* @refcnt: driver's private reference counter
+ * @input: capture input type, grp_id of the attached subdev
* @user_subdev_api: true if subdevs are not configured by the host driver
*/
struct fimc_vid_cap {
@@ -323,6 +324,7 @@ struct fimc_vid_cap {
unsigned intreqbufs_count;
int input_index;
int refcnt;
+ u32 input;
booluser_subdev_api;
};
--
1.7.6
--
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 10/19 v4] s5p-fimc: Add PM helper function for streaming control
Move the camera capture H/W initialization sequence to a separate
function. This is needed for reuse in the following runtime PM code.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 74 +++
drivers/media/video/s5p-fimc/fimc-core.c|4 +-
drivers/media/video/s5p-fimc/fimc-core.h|3 +
3 files changed, 46 insertions(+), 35 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 95996fb..6c4dca0 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -30,6 +30,44 @@
#include fimc-mdevice.h
#include fimc-core.h
+static int fimc_init_capture(struct fimc_dev *fimc)
+{
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
+ struct fimc_sensor_info *sensor;
+ unsigned long flags;
+ int ret = 0;
+
+ if (fimc-pipeline.sensor == NULL || ctx == NULL)
+ return -ENXIO;
+ if (ctx-s_frame.fmt == NULL)
+ return -EINVAL;
+
+ sensor = v4l2_get_subdev_hostdata(fimc-pipeline.sensor);
+
+ spin_lock_irqsave(fimc-slock, flags);
+ fimc_prepare_dma_offset(ctx, ctx-d_frame);
+ fimc_set_yuv_order(ctx);
+
+ fimc_hw_set_camera_polarity(fimc, sensor-pdata);
+ fimc_hw_set_camera_type(fimc, sensor-pdata);
+ fimc_hw_set_camera_source(fimc, sensor-pdata);
+ fimc_hw_set_camera_offset(fimc, ctx-s_frame);
+
+ ret = fimc_set_scaler_info(ctx);
+ if (!ret) {
+ fimc_hw_set_input_path(ctx);
+ fimc_hw_set_prescaler(ctx);
+ fimc_hw_set_mainscaler(ctx);
+ fimc_hw_set_target_format(ctx);
+ fimc_hw_set_rotation(ctx);
+ fimc_hw_set_effect(ctx);
+ fimc_hw_set_output_path(ctx);
+ fimc_hw_set_out_dma(ctx);
+ }
+ spin_unlock_irqrestore(fimc-slock, flags);
+ return ret;
+}
+
static void fimc_capture_state_cleanup(struct fimc_dev *fimc)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
@@ -85,47 +123,17 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
{
struct fimc_ctx *ctx = q-drv_priv;
struct fimc_dev *fimc = ctx-fimc_dev;
- struct s5p_fimc_isp_info *isp_info;
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
int min_bufs;
int ret;
fimc_hw_reset(fimc);
+ vid_cap-frame_count = 0;
- ret = v4l2_subdev_call(fimc-vid_cap.sd, video, s_stream, 1);
- if (ret ret != -ENOIOCTLCMD)
- goto error;
-
- ret = fimc_prepare_config(ctx, ctx-state);
+ ret = fimc_init_capture(fimc);
if (ret)
goto error;
- isp_info = fimc-pdata-isp_info[fimc-vid_cap.input_index];
- fimc_hw_set_camera_type(fimc, isp_info);
- fimc_hw_set_camera_source(fimc, isp_info);
- fimc_hw_set_camera_offset(fimc, ctx-s_frame);
-
- if (ctx-state FIMC_PARAMS) {
- ret = fimc_set_scaler_info(ctx);
- if (ret) {
- err(Scaler setup error);
- goto error;
- }
- fimc_hw_set_input_path(ctx);
- fimc_hw_set_prescaler(ctx);
- fimc_hw_set_mainscaler(ctx);
- fimc_hw_set_target_format(ctx);
- fimc_hw_set_rotation(ctx);
- fimc_hw_set_effect(ctx);
- }
-
- fimc_hw_set_output_path(ctx);
- fimc_hw_set_out_dma(ctx);
-
- INIT_LIST_HEAD(fimc-vid_cap.pending_buf_q);
- INIT_LIST_HEAD(fimc-vid_cap.active_buf_q);
- fimc-vid_cap.frame_count = 0;
- fimc-vid_cap.buf_index = 0;
-
set_bit(ST_CAPT_PEND, fimc-state);
min_bufs = fimc-vid_cap.reqbufs_count 1 ? 2 : 1;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 69ba2cc..565f1dd 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -476,7 +476,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
/* Set order for 1 and 2 plane YCBCR 4:2:2 formats. */
-static void fimc_set_yuv_order(struct fimc_ctx *ctx)
+void fimc_set_yuv_order(struct fimc_ctx *ctx)
{
/* The one only mode supported in SoC. */
ctx-in_order_2p = S5P_FIMC_LSB_CRCB;
@@ -518,7 +518,7 @@ static void fimc_set_yuv_order(struct fimc_ctx *ctx)
dbg(ctx-out_order_1p= %d, ctx-out_order_1p);
}
-static void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f)
+void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f)
{
struct samsung_fimc_variant *variant = ctx-fimc_dev-variant;
u32 i, depth = 0;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 87a89f1..1d2cfda
[PATCH 05/19 v4] s5p-fimc: Remove v4l2_device from video capture and m2m driver
Currently there is a v4l2_device instance being registered per each
(capture and memory-to-memory) video node created per FIMC H/W instance.
This patch is a prerequisite for using the top level v4l2_device
instantiated by the media device driver.
To retain current debug trace semantic (so it's possible to distinguish
between the capture and m2m FIMC) the video_device is used in place
of v4l2_device where appropriate.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 39 +++
drivers/media/video/s5p-fimc/fimc-core.c| 54 ++-
drivers/media/video/s5p-fimc/fimc-core.h| 15 ---
drivers/media/video/s5p-fimc/fimc-reg.c |7 ++-
4 files changed, 47 insertions(+), 68 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 40f3330..a1ac986 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -191,7 +191,6 @@ static int buffer_prepare(struct vb2_buffer *vb)
{
struct vb2_queue *vq = vb-vb2_queue;
struct fimc_ctx *ctx = vq-drv_priv;
- struct v4l2_device *v4l2_dev = ctx-fimc_dev-m2m.v4l2_dev;
int i;
if (!ctx-d_frame.fmt || vq-type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
@@ -201,7 +200,8 @@ static int buffer_prepare(struct vb2_buffer *vb)
unsigned long size = get_plane_size(ctx-d_frame, i);
if (vb2_plane_size(vb, i) size) {
- v4l2_err(v4l2_dev, User buffer too small (%ld
%ld)\n,
+ v4l2_err(ctx-fimc_dev-vid_cap.vfd,
+User buffer too small (%ld %ld)\n,
vb2_plane_size(vb, i), size);
return -EINVAL;
}
@@ -413,7 +413,8 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
pix = f-fmt.pix_mp;
frame-fmt = find_format(f, FMT_FLAGS_M2M | FMT_FLAGS_CAM);
if (!frame-fmt) {
- err(fimc target format not found\n);
+ v4l2_err(fimc-vid_cap.vfd,
+Not supported capture (FIMC target) color format\n);
return -EINVAL;
}
@@ -473,7 +474,7 @@ static int fimc_cap_streamon(struct file *file, void *priv,
return -EBUSY;
if (!(ctx-state FIMC_DST_FMT)) {
- v4l2_err(fimc-vid_cap.v4l2_dev, Format is not set\n);
+ v4l2_err(fimc-vid_cap.vfd, Format is not set\n);
return -EINVAL;
}
@@ -603,9 +604,8 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
return ret;
if (!(ctx-state FIMC_DST_FMT)) {
- v4l2_err(fimc-vid_cap.v4l2_dev,
-Capture color format not set\n);
- return -EINVAL; /* TODO: make sure this is the right value */
+ v4l2_err(fimc-vid_cap.vfd, Capture format is not set\n);
+ return -EINVAL;
}
f = ctx-s_frame;
@@ -614,7 +614,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
ctx-d_frame.width, ctx-d_frame.height,
ctx-rotation);
if (ret) {
- v4l2_err(fimc-vid_cap.v4l2_dev, Out of the scaler range\n);
+ v4l2_err(fimc-vid_cap.vfd, Out of the scaler range\n);
return ret;
}
@@ -658,16 +658,16 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
};
/* fimc-lock must be already initialized */
-int fimc_register_capture_device(struct fimc_dev *fimc)
+int fimc_register_capture_device(struct fimc_dev *fimc,
+struct v4l2_device *v4l2_dev)
{
- struct v4l2_device *v4l2_dev = fimc-vid_cap.v4l2_dev;
struct video_device *vfd;
struct fimc_vid_cap *vid_cap;
struct fimc_ctx *ctx;
struct v4l2_format f;
struct fimc_frame *fr;
struct vb2_queue *q;
- int ret;
+ int ret = -ENOMEM;
ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
if (!ctx)
@@ -685,20 +685,14 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
fr-width = fr-f_width = fr-o_width = 640;
fr-height = fr-f_height = fr-o_height = 480;
- snprintf(v4l2_dev-name, sizeof(v4l2_dev-name),
-%s.capture, dev_name(fimc-pdev-dev));
-
- ret = v4l2_device_register(NULL, v4l2_dev);
- if (ret)
- goto err_info;
-
vfd = video_device_alloc();
if (!vfd) {
v4l2_err(v4l2_dev, Failed to allocate video device\n);
- goto err_v4l2_reg;
+ goto err_vd_alloc;
}
- strlcpy(vfd-name, v4l2_dev-name, sizeof(vfd-name));
+ snprintf(vfd-name, sizeof(vfd-name), %s.capture,
+
[PATCH 12/19 v4] s5p-fimc: Convert to use media pipeline operations
In the camera capture driver use fimc_pipeline_* calls provided by
the media device driver part, in place where v4l2_subdev_call() were
used. This way the capture driver don't need to differentiate between
various H/W pipeline setups, i.e. if the MIPI-CSI receiver subdev is
used or not.
Remove the sync_capture_fmt() function instead of which
fimc_pipeline_try_format() is introduced in the following patch adding
the FIMC capture subdev.
The TRY_FMT ioctl function is completed by a subsequent patch adding
the capture subdev, so the try_fmt routines can be reused in the subdev
and the video node ioctl handlers.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 118 --
drivers/media/video/s5p-fimc/fimc-core.c| 125 +++
drivers/media/video/s5p-fimc/fimc-core.h| 11 ++-
3 files changed, 130 insertions(+), 124 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 32c2854..f0fed61 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -68,7 +68,7 @@ static int fimc_init_capture(struct fimc_dev *fimc)
return ret;
}
-static void fimc_capture_state_cleanup(struct fimc_dev *fimc)
+static int fimc_capture_state_cleanup(struct fimc_dev *fimc)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_vid_buffer *buf;
@@ -76,7 +76,8 @@ static void fimc_capture_state_cleanup(struct fimc_dev *fimc)
spin_lock_irqsave(fimc-slock, flags);
fimc-state = ~(1 ST_CAPT_RUN | 1 ST_CAPT_PEND |
-1 ST_CAPT_SHUT | 1 ST_CAPT_STREAM);
+1 ST_CAPT_SHUT | 1 ST_CAPT_STREAM |
+1 ST_CAPT_ISP_STREAM);
fimc-vid_cap.active_buf_cnt = 0;
@@ -92,6 +93,11 @@ static void fimc_capture_state_cleanup(struct fimc_dev *fimc)
}
spin_unlock_irqrestore(fimc-slock, flags);
+
+ if (test_bit(ST_CAPT_ISP_STREAM, fimc-state))
+ return fimc_pipeline_s_stream(fimc, 0);
+ else
+ return 0;
}
static int fimc_stop_capture(struct fimc_dev *fimc)
@@ -111,11 +117,7 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
!test_bit(ST_CAPT_SHUT, fimc-state),
FIMC_SHUTDOWN_TIMEOUT);
- v4l2_subdev_call(cap-sd, video, s_stream, 0);
-
- fimc_capture_state_cleanup(fimc);
- dbg(state: 0x%lx, fimc-state);
- return 0;
+ return fimc_capture_state_cleanup(fimc);
}
@@ -138,9 +140,14 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
min_bufs = fimc-vid_cap.reqbufs_count 1 ? 2 : 1;
- if (fimc-vid_cap.active_buf_cnt = min_bufs)
+ if (vid_cap-active_buf_cnt = min_bufs
+ !test_and_set_bit(ST_CAPT_STREAM, fimc-state)) {
fimc_activate_capture(ctx);
+ if (!test_and_set_bit(ST_CAPT_ISP_STREAM, fimc-state))
+ fimc_pipeline_s_stream(fimc, 1);
+ }
+
return 0;
error:
fimc_capture_state_cleanup(fimc);
@@ -202,11 +209,11 @@ static int buffer_prepare(struct vb2_buffer *vb)
struct fimc_ctx *ctx = vq-drv_priv;
int i;
- if (!ctx-d_frame.fmt || vq-type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+ if (ctx-d_frame.fmt == NULL)
return -EINVAL;
for (i = 0; i ctx-d_frame.fmt-memplanes; i++) {
- unsigned long size = get_plane_size(ctx-d_frame, i);
+ unsigned long size = ctx-d_frame.payload[i];
if (vb2_plane_size(vb, i) size) {
v4l2_err(ctx-fimc_dev-vid_cap.vfd,
@@ -214,7 +221,6 @@ static int buffer_prepare(struct vb2_buffer *vb)
vb2_plane_size(vb, i), size);
return -EINVAL;
}
-
vb2_set_plane_payload(vb, i, size);
}
@@ -223,10 +229,10 @@ static int buffer_prepare(struct vb2_buffer *vb)
static void buffer_queue(struct vb2_buffer *vb)
{
- struct fimc_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
- struct fimc_dev *fimc = ctx-fimc_dev;
struct fimc_vid_buffer *buf
= container_of(vb, struct fimc_vid_buffer, vb);
+ struct fimc_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
+ struct fimc_dev *fimc = ctx-fimc_dev;
struct fimc_vid_cap *vid_cap = fimc-vid_cap;
unsigned long flags;
int min_bufs;
@@ -252,11 +258,17 @@ static void buffer_queue(struct vb2_buffer *vb)
min_bufs = vid_cap-reqbufs_count 1 ? 2 : 1;
+
if (vb2_is_streaming(vid_cap-vbq)
vid_cap-active_buf_cnt = min_bufs
- !test_and_set_bit(ST_CAPT_STREAM, fimc-state))
+ !test_and_set_bit(ST_CAPT_STREAM, fimc-state)) {
[PATCH 19/19 v4] s5p-fimc: Remove single-planar capability flags
The driver supports only multi-planar API and conversion to single-planar API should be done in libv4l2. Remove misleading single planar capability flags to avoid problems in applications and libv4l2. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/s5p-fimc/fimc-capture.c |3 +-- drivers/media/video/s5p-fimc/fimc-core.c|1 - 2 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c b/drivers/media/video/s5p-fimc/fimc-capture.c index 9ca9462..de885db 100644 --- a/drivers/media/video/s5p-fimc/fimc-capture.c +++ b/drivers/media/video/s5p-fimc/fimc-capture.c @@ -615,8 +615,7 @@ static int fimc_vidioc_querycap_capture(struct file *file, void *priv, strncpy(cap-driver, fimc-pdev-name, sizeof(cap-driver) - 1); strncpy(cap-card, fimc-pdev-name, sizeof(cap-card) - 1); cap-bus_info[0] = 0; - cap-capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_CAPTURE | - V4L2_CAP_VIDEO_CAPTURE_MPLANE; + cap-capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_CAPTURE_MPLANE; return 0; } diff --git a/drivers/media/video/s5p-fimc/fimc-core.c b/drivers/media/video/s5p-fimc/fimc-core.c index 8978360..4158cb3 100644 --- a/drivers/media/video/s5p-fimc/fimc-core.c +++ b/drivers/media/video/s5p-fimc/fimc-core.c @@ -864,7 +864,6 @@ static int fimc_m2m_querycap(struct file *file, void *fh, strncpy(cap-card, fimc-pdev-name, sizeof(cap-card) - 1); cap-bus_info[0] = 0; cap-capabilities = V4L2_CAP_STREAMING | - V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_VIDEO_CAPTURE_MPLANE | V4L2_CAP_VIDEO_OUTPUT_MPLANE; return 0; -- 1.7.6 -- 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 08/19 v4] s5p-fimc: Convert to the new control framework
Convert the v4l controls code to use the new control framework.
fimc_ctrls_activate/deactivate functions are introduced for the
transparent DMA transfer mode (JPEG), where the rotation and flipping
controls are not supported.
The capture video node does not inherit sensors' controls when the
subdevs are configured by the user space (user_subdev_api == true).
However by default after the driver's initialization
the 'user-subdev_api' flag is false and any sensor controls will
also be available at the video node.
When the pipeline links are disconnected through the media device
the FIMC and any sensor inherited controls are destroyed and then
again created when the pipeline connection completes.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 61 +++---
drivers/media/video/s5p-fimc/fimc-core.c| 291 +++
drivers/media/video/s5p-fimc/fimc-core.h| 34 ++--
drivers/media/video/s5p-fimc/fimc-mdevice.c | 11 +-
drivers/media/video/s5p-fimc/fimc-reg.c | 32 +---
5 files changed, 188 insertions(+), 241 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 562b23c..0c237a7 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -27,6 +27,7 @@
#include media/videobuf2-core.h
#include media/videobuf2-dma-contig.h
+#include fimc-mdevice.h
#include fimc-core.h
static void fimc_capture_state_cleanup(struct fimc_dev *fimc)
@@ -273,6 +274,31 @@ static struct vb2_ops fimc_capture_qops = {
.stop_streaming = stop_streaming,
};
+/**
+ * fimc_capture_ctrls_create - initialize the control handler
+ * Initialize the capture video node control handler and fill it
+ * with the FIMC controls. Inherit any sensor's controls if the
+ * 'user_subdev_api' flag is false (default behaviour).
+ * This function need to be called with the graph mutex held.
+ */
+int fimc_capture_ctrls_create(struct fimc_dev *fimc)
+{
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
+ int ret;
+
+ if (WARN_ON(vid_cap-ctx == NULL))
+ return -ENXIO;
+ if (vid_cap-ctx-ctrls_rdy)
+ return 0;
+
+ ret = fimc_ctrls_create(vid_cap-ctx);
+ if (ret || vid_cap-user_subdev_api)
+ return ret;
+
+ return v4l2_ctrl_add_handler(vid_cap-ctx-ctrl_handler,
+ fimc-pipeline.sensor-ctrl_handler);
+}
+
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
@@ -293,9 +319,10 @@ static int fimc_capture_open(struct file *file)
return ret;
}
- ++fimc-vid_cap.refcnt;
+ if (++fimc-vid_cap.refcnt == 1)
+ ret = fimc_capture_ctrls_create(fimc);
- return 0;
+ return ret;
}
static int fimc_capture_close(struct file *file)
@@ -306,6 +333,7 @@ static int fimc_capture_close(struct file *file)
if (--fimc-vid_cap.refcnt == 0) {
fimc_stop_capture(fimc);
+ fimc_ctrls_delete(fimc-vid_cap.ctx);
vb2_queue_release(fimc-vid_cap.vbq);
}
@@ -546,30 +574,6 @@ static int fimc_cap_dqbuf(struct file *file, void *priv,
return vb2_dqbuf(fimc-vid_cap.vbq, buf, file-f_flags O_NONBLOCK);
}
-static int fimc_cap_s_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct fimc_dev *fimc = video_drvdata(file);
- struct fimc_ctx *ctx = fimc-vid_cap.ctx;
- int ret = -EINVAL;
-
- /* Allow any controls but 90/270 rotation while streaming */
- if (!fimc_capture_active(ctx-fimc_dev) ||
- ctrl-id != V4L2_CID_ROTATE ||
- (ctrl-value != 90 ctrl-value != 270)) {
- ret = check_ctrl_val(ctx, ctrl);
- if (!ret) {
- ret = fimc_s_ctrl(ctx, ctrl);
- if (!ret)
- ctx-state |= FIMC_PARAMS;
- }
- }
- if (ret == -EINVAL)
- ret = v4l2_subdev_call(ctx-fimc_dev-vid_cap.sd,
- core, s_ctrl, ctrl);
- return ret;
-}
-
static int fimc_cap_cropcap(struct file *file, void *fh,
struct v4l2_cropcap *cr)
{
@@ -656,10 +660,6 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_streamon= fimc_cap_streamon,
.vidioc_streamoff = fimc_cap_streamoff,
- .vidioc_queryctrl = fimc_vidioc_queryctrl,
- .vidioc_g_ctrl = fimc_vidioc_g_ctrl,
- .vidioc_s_ctrl = fimc_cap_s_ctrl,
-
.vidioc_g_crop = fimc_cap_g_crop,
.vidioc_s_crop = fimc_cap_s_crop,
[PATCH 16/19 v4] s5p-fimc: Use consistent names for the buffer list functions
Also correct and improve *_queue_add/pop functions description.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |6 ++--
drivers/media/video/s5p-fimc/fimc-core.c|6 ++--
drivers/media/video/s5p-fimc/fimc-core.h| 38 +-
3 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 7fafd12..4693846 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -84,12 +84,12 @@ static int fimc_capture_state_cleanup(struct fimc_dev *fimc)
/* Release buffers that were enqueued in the driver by videobuf2. */
while (!list_empty(cap-pending_buf_q)) {
- buf = pending_queue_pop(cap);
+ buf = fimc_pending_queue_pop(cap);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
while (!list_empty(cap-active_buf_q)) {
- buf = active_queue_pop(cap);
+ buf = fimc_active_queue_pop(cap);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
@@ -279,7 +279,7 @@ static void buffer_queue(struct vb2_buffer *vb)
fimc_hw_set_output_addr(fimc, buf-paddr, buf_id);
buf-index = vid_cap-buf_index;
- active_queue_add(vid_cap, buf);
+ fimc_active_queue_add(vid_cap, buf);
if (++vid_cap-buf_index = FIMC_MAX_OUT_BUFS)
vid_cap-buf_index = 0;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 52f0862..4369c4f 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -338,7 +338,7 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc, bool
final)
test_bit(ST_CAPT_RUN, fimc-state) final) {
ktime_get_real_ts(ts);
- v_buf = active_queue_pop(cap);
+ v_buf = fimc_active_queue_pop(cap);
tv = v_buf-vb.v4l2_buf.timestamp;
tv-tv_sec = ts.tv_sec;
@@ -355,12 +355,12 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc, bool
final)
if (!list_empty(cap-pending_buf_q)) {
- v_buf = pending_queue_pop(cap);
+ v_buf = fimc_pending_queue_pop(cap);
fimc_hw_set_output_addr(fimc, v_buf-paddr, cap-buf_index);
v_buf-index = cap-buf_index;
/* Move the buffer to the capture active queue */
- active_queue_add(cap, v_buf);
+ fimc_active_queue_add(cap, v_buf);
dbg(next frame: %d, done frame: %d,
fimc_hw_get_frame_index(fimc), v_buf-index);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 6ec8b37..82ac597 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -745,22 +745,27 @@ static inline void fimc_deactivate_capture(struct
fimc_dev *fimc)
}
/*
- * Add buf to the capture active buffers queue.
- * Locking: Need to be called with fimc_dev::slock held.
+ * Buffer list manipulation functions. Must be called with fimc.slock held.
*/
-static inline void active_queue_add(struct fimc_vid_cap *vid_cap,
- struct fimc_vid_buffer *buf)
+
+/**
+ * fimc_active_queue_add - add buffer to the capture active buffers queue
+ * @buf: buffer to add to the active buffers list
+ */
+static inline void fimc_active_queue_add(struct fimc_vid_cap *vid_cap,
+struct fimc_vid_buffer *buf)
{
list_add_tail(buf-list, vid_cap-active_buf_q);
vid_cap-active_buf_cnt++;
}
-/*
- * Pop a video buffer from the capture active buffers queue
- * Locking: Need to be called with fimc_dev::slock held.
+/**
+ * fimc_active_queue_pop - pop buffer from the capture active buffers queue
+ *
+ * The caller must assure the active_buf_q list is not empty.
*/
-static inline struct fimc_vid_buffer *
-active_queue_pop(struct fimc_vid_cap *vid_cap)
+static inline struct fimc_vid_buffer *fimc_active_queue_pop(
+ struct fimc_vid_cap *vid_cap)
{
struct fimc_vid_buffer *buf;
buf = list_entry(vid_cap-active_buf_q.next,
@@ -770,16 +775,23 @@ active_queue_pop(struct fimc_vid_cap *vid_cap)
return buf;
}
-/* Add video buffer to the capture pending buffers queue */
+/**
+ * fimc_pending_queue_add - add buffer to the capture pending buffers queue
+ * @buf: buffer to add to the pending buffers list
+ */
static inline void fimc_pending_queue_add(struct fimc_vid_cap *vid_cap,
struct fimc_vid_buffer *buf)
{
list_add_tail(buf-list, vid_cap-pending_buf_q);
}
-/*
[PATCH 18/19 v4] s5p-fimc: Correct crop offset alignment on exynos4
Horizontal crop offset must be multiple of 2 otherwise
color distortion occurs.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index a528a76..8978360 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1898,7 +1898,7 @@ static struct samsung_fimc_variant fimc0_variant_exynos4
= {
.has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
- .hor_offs_align = 1,
+ .hor_offs_align = 2,
.out_buf_count = 32,
.pix_limit = s5p_pix_limit[1],
};
@@ -1910,7 +1910,7 @@ static struct samsung_fimc_variant fimc3_variant_exynos4
= {
.has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
- .hor_offs_align = 1,
+ .hor_offs_align = 2,
.out_buf_count = 32,
.pix_limit = s5p_pix_limit[3],
};
--
1.7.6
--
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 15/19 v4] s5p-fimc: Add v4l2_device notification support for single frame capture
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 47 +++
drivers/media/video/s5p-fimc/fimc-core.h|2 +
drivers/media/video/s5p-fimc/fimc-mdevice.c |1 +
include/media/s5p_fimc.h|9 +
4 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index adbbb63..7fafd12 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -1076,6 +1076,53 @@ static const struct media_entity_operations
fimc_sd_media_ops = {
.link_setup = fimc_link_setup,
};
+/**
+ * fimc_sensor_notify - v4l2_device notification from a sensor subdev
+ * @sd: pointer to a subdev generating the notification
+ * @notification: the notification type, must be S5P_FIMC_TX_END_NOTIFY
+ * @arg: pointer to an u32 type integer that stores the frame payload value
+ *
+ * The End Of Frame notification sent by sensor subdev in its still capture
+ * mode. If there is only a single VSYNC generated by the sensor at the
+ * beginning of a frame transmission, FIMC does not issue the LastIrq
+ * (end of frame) interrupt. And this notification is used to complete the
+ * frame capture and returning a buffer to user-space. Subdev drivers should
+ * call this notification from their last 'End of frame capture' interrupt.
+ */
+void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned int notification,
+ void *arg)
+{
+ struct fimc_sensor_info *sensor;
+ struct fimc_vid_buffer *buf;
+ struct fimc_md *fmd;
+ struct fimc_dev *fimc;
+ unsigned long flags;
+
+ if (sd == NULL)
+ return;
+
+ sensor = v4l2_get_subdev_hostdata(sd);
+ fmd = entity_to_fimc_mdev(sd-entity);
+
+ spin_lock_irqsave(fmd-slock, flags);
+ fimc = sensor ? sensor-host : NULL;
+
+ if (fimc arg notification == S5P_FIMC_TX_END_NOTIFY
+ test_bit(ST_CAPT_PEND, fimc-state)) {
+ unsigned long irq_flags;
+ spin_lock_irqsave(fimc-slock, irq_flags);
+ if (!list_empty(fimc-vid_cap.active_buf_q)) {
+ buf = list_entry(fimc-vid_cap.active_buf_q.next,
+struct fimc_vid_buffer, list);
+ vb2_set_plane_payload(buf-vb, 0, *((u32 *)arg));
+ }
+ fimc_capture_irq_handler(fimc, true);
+ fimc_deactivate_capture(fimc);
+ spin_unlock_irqrestore(fimc-slock, irq_flags);
+ }
+ spin_unlock_irqrestore(fmd-slock, flags);
+}
+
static int fimc_subdev_enum_mbus_code(struct v4l2_subdev *sd,
struct v4l2_subdev_fh *fh,
struct v4l2_subdev_mbus_code_enum *code)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 9b44875..6ec8b37 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -723,6 +723,8 @@ void fimc_unregister_capture_device(struct fimc_dev *fimc);
int fimc_capture_ctrls_create(struct fimc_dev *fimc);
int fimc_vid_cap_buf_queue(struct fimc_dev *fimc,
struct fimc_vid_buffer *fimc_vb);
+void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned int notification,
+ void *arg);
int fimc_capture_suspend(struct fimc_dev *fimc);
int fimc_capture_resume(struct fimc_dev *fimc);
int fimc_capture_config_update(struct fimc_ctx *ctx);
diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.c
b/drivers/media/video/s5p-fimc/fimc-mdevice.c
index 6fb19c0..199aa86 100644
--- a/drivers/media/video/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/video/s5p-fimc/fimc-mdevice.c
@@ -761,6 +761,7 @@ static int __devinit fimc_md_probe(struct platform_device
*pdev)
v4l2_dev = fmd-v4l2_dev;
v4l2_dev-mdev = fmd-media_dev;
+ v4l2_dev-notify = fimc_sensor_notify;
snprintf(v4l2_dev-name, sizeof(v4l2_dev-name), %s,
dev_name(pdev-dev));
diff --git a/include/media/s5p_fimc.h b/include/media/s5p_fimc.h
index 086a7aa..2b58904 100644
--- a/include/media/s5p_fimc.h
+++ b/include/media/s5p_fimc.h
@@ -60,4 +60,13 @@ struct s5p_platform_fimc {
struct s5p_fimc_isp_info *isp_info;
int num_clients;
};
+
+/*
+ * v4l2_device notification id. This is only for internal use in the kernel.
+ * Sensor subdevs should issue S5P_FIMC_TX_END_NOTIFY notification in single
+ * frame capture mode when there is only one VSYNC pulse issued by the sensor
+ * at begining of the frame transmission.
+ */
+#define S5P_FIMC_TX_END_NOTIFY _IO('e', 0)
+
#endif /* S5P_FIMC_H_ */
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the
[PATCH 17/19 v4] s5p-fimc: Add runtime PM support in the camera capture driver
Add support for whole pipeline suspend/resume. Sensors must support
suspend/resume through s_power subdev operation.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 83 +++---
drivers/media/video/s5p-fimc/fimc-core.c| 10 ++--
drivers/media/video/s5p-fimc/fimc-core.h|1 +
3 files changed, 66 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 4693846..9ca9462 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -69,30 +69,32 @@ static int fimc_init_capture(struct fimc_dev *fimc)
return ret;
}
-static int fimc_capture_state_cleanup(struct fimc_dev *fimc)
+static int fimc_capture_state_cleanup(struct fimc_dev *fimc, bool suspend)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_vid_buffer *buf;
unsigned long flags;
spin_lock_irqsave(fimc-slock, flags);
- fimc-state = ~(1 ST_CAPT_RUN | 1 ST_CAPT_PEND |
-1 ST_CAPT_SHUT | 1 ST_CAPT_STREAM |
-1 ST_CAPT_ISP_STREAM);
+ fimc-state = ~(1 ST_CAPT_RUN | 1 ST_CAPT_SHUT |
+1 ST_CAPT_STREAM | 1 ST_CAPT_ISP_STREAM);
+ if (!suspend)
+ fimc-state = ~(1 ST_CAPT_PEND | 1 ST_CAPT_SUSPENDED);
- fimc-vid_cap.active_buf_cnt = 0;
-
- /* Release buffers that were enqueued in the driver by videobuf2. */
- while (!list_empty(cap-pending_buf_q)) {
+ /* Release unused buffers */
+ while (!suspend !list_empty(cap-pending_buf_q)) {
buf = fimc_pending_queue_pop(cap);
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
-
+ /* If suspending put unused buffers onto pending queue */
while (!list_empty(cap-active_buf_q)) {
buf = fimc_active_queue_pop(cap);
- vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ if (suspend)
+ fimc_pending_queue_add(cap, buf);
+ else
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
-
+ set_bit(ST_CAPT_SUSPENDED, fimc-state);
spin_unlock_irqrestore(fimc-slock, flags);
if (test_bit(ST_CAPT_ISP_STREAM, fimc-state))
@@ -101,9 +103,8 @@ static int fimc_capture_state_cleanup(struct fimc_dev *fimc)
return 0;
}
-static int fimc_stop_capture(struct fimc_dev *fimc)
+static int fimc_stop_capture(struct fimc_dev *fimc, bool suspend)
{
- struct fimc_vid_cap *cap = fimc-vid_cap;
unsigned long flags;
if (!fimc_capture_active(fimc))
@@ -116,9 +117,9 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
wait_event_timeout(fimc-irq_queue,
!test_bit(ST_CAPT_SHUT, fimc-state),
- FIMC_SHUTDOWN_TIMEOUT);
+ (2*HZ/10)); /* 200 ms */
- return fimc_capture_state_cleanup(fimc);
+ return fimc_capture_state_cleanup(fimc, suspend);
}
/**
@@ -181,7 +182,7 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
return 0;
error:
- fimc_capture_state_cleanup(fimc);
+ fimc_capture_state_cleanup(fimc, false);
return ret;
}
@@ -193,17 +194,46 @@ static int stop_streaming(struct vb2_queue *q)
if (!fimc_capture_active(fimc))
return -EINVAL;
- return fimc_stop_capture(fimc);
+ return fimc_stop_capture(fimc, false);
}
int fimc_capture_suspend(struct fimc_dev *fimc)
{
- return -EBUSY;
+ bool suspend = fimc_capture_busy(fimc);
+
+ int ret = fimc_stop_capture(fimc, suspend);
+ if (ret)
+ return ret;
+ return fimc_pipeline_shutdown(fimc);
}
+static void buffer_queue(struct vb2_buffer *vb);
+
int fimc_capture_resume(struct fimc_dev *fimc)
{
+ struct fimc_vid_cap *vid_cap = fimc-vid_cap;
+ struct fimc_vid_buffer *buf;
+ int i;
+
+ if (!test_and_clear_bit(ST_CAPT_SUSPENDED, fimc-state))
+ return 0;
+
+ INIT_LIST_HEAD(fimc-vid_cap.active_buf_q);
+ vid_cap-buf_index = 0;
+ fimc_pipeline_initialize(fimc, fimc-vid_cap.vfd-entity,
+false);
+ fimc_init_capture(fimc);
+
+ clear_bit(ST_CAPT_SUSPENDED, fimc-state);
+
+ for (i = 0; i vid_cap-reqbufs_count; i++) {
+ if (list_empty(vid_cap-pending_buf_q))
+ break;
+ buf = fimc_pending_queue_pop(vid_cap);
+ buffer_queue(buf-vb);
+ }
return 0;
+
}
static unsigned int get_plane_size(struct fimc_frame *fr, unsigned int plane)
@@ -271,8 +301,9 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_lock_irqsave(fimc-slock,
[PATCH 14/19 v4] s5p-fimc: Add support for JPEG capture
Add support for transparent DMA transfer of JPEG data with MIPI-CSI2
USER1 format. In JPEG mode the color effect, scaling and cropping
is not supported as well as image rotation and flipping thus these
controls are marked as inactive if V4L2_PIX_FMT_JPEG pixel format
was selected.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 17 ++-
drivers/media/video/s5p-fimc/fimc-core.c| 70 ++-
drivers/media/video/s5p-fimc/fimc-core.h|7 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 31
drivers/media/video/s5p-fimc/regs-fimc.h|8 +--
5 files changed, 81 insertions(+), 52 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 62fd8a1..adbbb63 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -60,7 +60,7 @@ static int fimc_init_capture(struct fimc_dev *fimc)
fimc_hw_set_mainscaler(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
- fimc_hw_set_effect(ctx);
+ fimc_hw_set_effect(ctx, false);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
clear_bit(ST_CAPT_APPLY_CFG, fimc-state);
@@ -731,6 +731,17 @@ static int fimc_cap_try_fmt_mplane(struct file *file, void
*fh,
return 0;
}
+static void fimc_capture_mark_jpeg_xfer(struct fimc_ctx *ctx, bool jpeg)
+{
+ ctx-scaler.enabled = !jpeg;
+ fimc_ctrls_activate(ctx, !jpeg);
+
+ if (jpeg)
+ set_bit(ST_CAPT_JPEG, ctx-fimc_dev-state);
+ else
+ clear_bit(ST_CAPT_JPEG, ctx-fimc_dev-state);
+}
+
static int fimc_capture_set_format(struct fimc_dev *fimc, struct v4l2_format
*f)
{
struct fimc_ctx *ctx = fimc-vid_cap.ctx;
@@ -783,6 +794,8 @@ static int fimc_capture_set_format(struct fimc_dev *fimc,
struct v4l2_format *f)
if (!(ctx-state FIMC_DST_CROP))
set_frame_crop(ff, 0, 0, pix-width, pix-height);
+ fimc_capture_mark_jpeg_xfer(ctx, fimc_fmt_is_jpeg(ff-fmt-color));
+
/* Reset cropping and set format at the camera interface input */
if (!fimc-vid_cap.user_subdev_api) {
ctx-s_frame.fmt = s_fmt;
@@ -1133,6 +1146,8 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
*mf = fmt-format;
return 0;
}
+ fimc_capture_mark_jpeg_xfer(ctx, fimc_fmt_is_jpeg(ffmt-color));
+
ff = fmt-pad == FIMC_SD_PAD_SINK ?
ctx-s_frame : ctx-d_frame;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index ffcccb2..52f0862 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -159,22 +159,28 @@ static struct fimc_fmt fimc_formats[] = {
.memplanes = 2,
.colplanes = 2,
.flags = FMT_FLAGS_M2M,
+ }, {
+ .name = JPEG encoded data,
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .color = S5P_FIMC_JPEG,
+ .depth = { 8 },
+ .memplanes = 1,
+ .colplanes = 1,
+ .mbus_code = V4L2_MBUS_FMT_JPEG_1X8,
+ .flags = FMT_FLAGS_CAM,
},
};
-int fimc_check_scaler_ratio(int sw, int sh, int dw, int dh, int rot)
+int fimc_check_scaler_ratio(struct fimc_ctx *ctx, int sw, int sh,
+ int dw, int dh, int rotation)
{
- int tx, ty;
+ if (rotation == 90 || rotation == 270)
+ swap(dw, dh);
- if (rot == 90 || rot == 270) {
- ty = dw;
- tx = dh;
- } else {
- tx = dw;
- ty = dh;
- }
+ if (!ctx-scaler.enabled)
+ return (sw == dw sh == dh) ? 0 : -EINVAL;
- if ((sw = SCALER_MAX_HRATIO * tx) || (sh = SCALER_MAX_VRATIO * ty))
+ if ((sw = SCALER_MAX_HRATIO * dw) || (sh = SCALER_MAX_VRATIO * dh))
return -EINVAL;
return 0;
@@ -321,7 +327,7 @@ static int stop_streaming(struct vb2_queue *q)
return 0;
}
-static void fimc_capture_irq_handler(struct fimc_dev *fimc)
+void fimc_capture_irq_handler(struct fimc_dev *fimc, bool final)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_vid_buffer *v_buf;
@@ -329,7 +335,7 @@ static void fimc_capture_irq_handler(struct fimc_dev *fimc)
struct timespec ts;
if (!list_empty(cap-active_buf_q)
- test_bit(ST_CAPT_RUN, fimc-state)) {
+ test_bit(ST_CAPT_RUN, fimc-state) final) {
ktime_get_real_ts(ts);
v_buf = active_queue_pop(cap);
@@ -364,7
[PATCH 11/19 v4] s5p-fimc: Correct color format enumeration
Replace fimc_find_format() and find_mbus_format() with single function
that can return a pointer to the private format description based
on fourcc, media bus code or index in the table.
Create separate VIDIOC_ENUM_FMT ioctl handlers for video capture
and mem-to-mem video node. This is needed because some formats are
valid only for the video capture and some only for the mem-to-mem
video node.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 32 +
drivers/media/video/s5p-fimc/fimc-core.c| 62 ++-
drivers/media/video/s5p-fimc/fimc-core.h|5 +-
drivers/media/video/s5p-fimc/fimc-mdevice.c |2 +-
4 files changed, 57 insertions(+), 44 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 6c4dca0..32c2854 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -389,6 +389,22 @@ static int fimc_vidioc_querycap_capture(struct file *file,
void *priv,
return 0;
}
+static int fimc_cap_enum_fmt_mplane(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ struct fimc_fmt *fmt;
+
+ fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM | FMT_FLAGS_M2M,
+ f-index);
+ if (!fmt)
+ return -EINVAL;
+ strncpy(f-description, fmt-name, sizeof(f-description) - 1);
+ f-pixelformat = fmt-fourcc;
+ if (fmt-fourcc == V4L2_MBUS_FMT_JPEG_1X8)
+ f-flags |= V4L2_FMT_FLAG_COMPRESSED;
+ return 0;
+}
+
/* Synchronize formats of the camera interface input and attached sensor. */
static int sync_capture_fmt(struct fimc_ctx *ctx)
{
@@ -407,7 +423,7 @@ static int sync_capture_fmt(struct fimc_ctx *ctx)
}
dbg(w: %d, h: %d, code= %d, fmt-width, fmt-height, fmt-code);
- frame-fmt = find_mbus_format(fmt, FMT_FLAGS_CAM);
+ frame-fmt = fimc_find_format(NULL, fmt-code, FMT_FLAGS_CAM, -1);
if (!frame-fmt) {
err(fimc source format not found\n);
return -EINVAL;
@@ -469,12 +485,10 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
frame = ctx-d_frame;
pix = f-fmt.pix_mp;
- frame-fmt = find_format(f, FMT_FLAGS_M2M | FMT_FLAGS_CAM);
- if (!frame-fmt) {
- v4l2_err(fimc-vid_cap.vfd,
-Not supported capture (FIMC target) color format\n);
+ frame-fmt = fimc_find_format(pix-pixelformat, NULL,
+ FMT_FLAGS_M2M | FMT_FLAGS_CAM, 0);
+ if (WARN(frame-fmt == NULL, Pixel format lookup failed\n))
return -EINVAL;
- }
for (i = 0; i frame-fmt-colplanes; i++) {
frame-payload[i] =
@@ -654,7 +668,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
struct v4l2_crop *cr)
static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops = {
.vidioc_querycap= fimc_vidioc_querycap_capture,
- .vidioc_enum_fmt_vid_cap_mplane = fimc_vidioc_enum_fmt_mplane,
+ .vidioc_enum_fmt_vid_cap_mplane = fimc_cap_enum_fmt_mplane,
.vidioc_try_fmt_vid_cap_mplane = fimc_cap_try_fmt_mplane,
.vidioc_s_fmt_vid_cap_mplane= fimc_cap_s_fmt_mplane,
.vidioc_g_fmt_vid_cap_mplane= fimc_cap_g_fmt_mplane,
@@ -715,7 +729,6 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
struct video_device *vfd;
struct fimc_vid_cap *vid_cap;
struct fimc_ctx *ctx;
- struct v4l2_format f;
struct fimc_frame *fr;
struct vb2_queue *q;
int ret = -ENOMEM;
@@ -730,9 +743,8 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
ctx-state = FIMC_CTX_CAP;
/* Default format of the output frames */
- f.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB32;
fr = ctx-d_frame;
- fr-fmt = find_format(f, FMT_FLAGS_M2M);
+ fr-fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, 0);
fr-width = fr-f_width = fr-o_width = 640;
fr-height = fr-f_height = fr-o_height = 480;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 565f1dd..3bcf6b7 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -866,18 +866,17 @@ static int fimc_m2m_querycap(struct file *file, void *fh,
return 0;
}
-int fimc_vidioc_enum_fmt_mplane(struct file *file, void *priv,
- struct v4l2_fmtdesc *f)
+static int fimc_m2m_enum_fmt_mplane(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
{
struct fimc_fmt *fmt;
- if (f-index = ARRAY_SIZE(fimc_formats))
+ fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_M2M,
[PATCH 06/19 v4] s5p-fimc: Add the media device driver
Add a top level media device driver aggregating FIMC video devnodes,
MIPI-CSIS and sensor subdevs. This driver gathers all media entities
and creates the possible links between them during initialization. By
default some links will be activated to enable access to all available
sensors in the system. For example if there are sensors S0, S1 listed
in the media device platform data definition they will be by default
assigned to FIMC0, FIMC1 respectively, which in turn will corresponds
to separate /dev/video?.
There is enough FIMC H/W entities to cover all available physical camera
interfaces in the system.
The fimc media device driver is bound to the s5p-fimc-md platform device.
Such platform device should be created by board initialization code
and camera sensors description array need to be specified as its
platform data.
The media device driver also implements various video pipeline operations,
for enabling subdevs power, streaming, etc., which will be used by the
capture video node driver.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig |5 +-
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-core.c| 33 +-
drivers/media/video/s5p-fimc/fimc-core.h| 16 +-
drivers/media/video/s5p-fimc/fimc-mdevice.c | 829 +++
drivers/media/video/s5p-fimc/fimc-mdevice.h | 118
include/media/s5p_fimc.h|2 +
7 files changed, 983 insertions(+), 22 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.c
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 14326d7..6279663 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -949,8 +949,9 @@ config VIDEO_MX2
Interface
config VIDEO_SAMSUNG_S5P_FIMC
- tristate Samsung S5P and EXYNOS4 camera host interface driver
- depends on VIDEO_V4L2 PLAT_S5P PM_RUNTIME
+ tristate Samsung S5P and EXYNOS4 camera interface driver
(EXPERIMENTAL)
+ depends on VIDEO_V4L2 I2C PLAT_S5P PM_RUNTIME \
+ VIDEO_V4L2_SUBDEV_API EXPERIMENTAL
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
diff --git a/drivers/media/video/s5p-fimc/Makefile
b/drivers/media/video/s5p-fimc/Makefile
index df6954a..33dec7f 100644
--- a/drivers/media/video/s5p-fimc/Makefile
+++ b/drivers/media/video/s5p-fimc/Makefile
@@ -1,4 +1,4 @@
-s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o
+s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o fimc-mdevice.o
s5p-csis-objs := mipi-csis.o
obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS) += s5p-csis.o
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index ba3af3a..7bb701b 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -28,6 +28,7 @@
#include media/videobuf2-dma-contig.h
#include fimc-core.h
+#include fimc-mdevice.h
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
sclk_fimc, fimc
@@ -1867,6 +1868,7 @@ static struct fimc_pix_limit s5p_pix_limit[4] = {
static struct samsung_fimc_variant fimc0_variant_s5p = {
.has_inp_rot = 1,
.has_out_rot = 1,
+ .has_cam_if = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 8,
@@ -1875,6 +1877,7 @@ static struct samsung_fimc_variant fimc0_variant_s5p = {
};
static struct samsung_fimc_variant fimc2_variant_s5p = {
+ .has_cam_if = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 8,
@@ -1886,6 +1889,7 @@ static struct samsung_fimc_variant fimc0_variant_s5pv210
= {
.pix_hoff= 1,
.has_inp_rot = 1,
.has_out_rot = 1,
+ .has_cam_if = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 8,
@@ -1897,6 +1901,7 @@ static struct samsung_fimc_variant fimc1_variant_s5pv210
= {
.pix_hoff= 1,
.has_inp_rot = 1,
.has_out_rot = 1,
+ .has_cam_if = 1,
.has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
@@ -1906,6 +1911,7 @@ static struct samsung_fimc_variant fimc1_variant_s5pv210
= {
};
static struct samsung_fimc_variant fimc2_variant_s5pv210 = {
+ .has_cam_if = 1,
.pix_hoff= 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
@@ -1918,6 +1924,7 @@ static struct samsung_fimc_variant fimc0_variant_exynos4
= {
.pix_hoff= 1,
.has_inp_rot = 1,
.has_out_rot = 1,
+ .has_cam_if = 1,
.has_cistatus2 = 1,
.has_mainscaler_ext = 1,
.min_inp_pixsize = 16,
@@ -1927,8 +1934,9 @@ static
[PATCH 07/19 v4] s5p-fimc: Conversion to use struct v4l2_fh
This is a prerequisite for the patch converting the driver to use
the control framework. As the capture driver does not use per file
handle contexts, two separate ioctl handlers are created for it
(vidioc_try_fmt_mplane, and vidioc_g_fmt_mplane) so there is no
handlers shared between the memory-to-memory and capture video node.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 114 ++
drivers/media/video/s5p-fimc/fimc-core.c| 179 ++
drivers/media/video/s5p-fimc/fimc-core.h| 10 +-
3 files changed, 165 insertions(+), 138 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index a1ac986..562b23c 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -276,7 +276,10 @@ static struct vb2_ops fimc_capture_qops = {
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
- int ret = 0;
+ int ret = v4l2_fh_open(file);
+
+ if (ret)
+ return ret;
dbg(pid: %d, state: 0x%lx, task_pid_nr(current), fimc-state);
@@ -285,11 +288,12 @@ static int fimc_capture_open(struct file *file)
return -EBUSY;
ret = pm_runtime_get_sync(fimc-pdev-dev);
- if (ret)
+ if (ret 0) {
+ v4l2_fh_release(file);
return ret;
+ }
++fimc-vid_cap.refcnt;
- file-private_data = fimc-vid_cap.ctx;
return 0;
}
@@ -307,22 +311,20 @@ static int fimc_capture_close(struct file *file)
pm_runtime_put(fimc-pdev-dev);
- return 0;
+ return v4l2_fh_release(file);
}
static unsigned int fimc_capture_poll(struct file *file,
struct poll_table_struct *wait)
{
- struct fimc_ctx *ctx = file-private_data;
- struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
return vb2_poll(fimc-vid_cap.vbq, file, wait);
}
static int fimc_capture_mmap(struct file *file, struct vm_area_struct *vma)
{
- struct fimc_ctx *ctx = file-private_data;
- struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
return vb2_mmap(fimc-vid_cap.vbq, vma);
}
@@ -340,8 +342,7 @@ static const struct v4l2_file_operations fimc_capture_fops
= {
static int fimc_vidioc_querycap_capture(struct file *file, void *priv,
struct v4l2_capability *cap)
{
- struct fimc_ctx *ctx = file-private_data;
- struct fimc_dev *fimc = ctx-fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
strncpy(cap-driver, fimc-pdev-name, sizeof(cap-driver) - 1);
strncpy(cap-card, fimc-pdev-name, sizeof(cap-card) - 1);
@@ -388,20 +389,41 @@ static int sync_capture_fmt(struct fimc_ctx *ctx)
return 0;
}
+static int fimc_cap_g_fmt_mplane(struct file *file, void *fh,
+struct v4l2_format *f)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
+
+ if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+ return -EINVAL;
+
+ return fimc_fill_format(ctx-d_frame, f);
+}
+
+static int fimc_cap_try_fmt_mplane(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
+
+ return fimc_try_fmt_mplane(ctx, f);
+}
+
static int fimc_cap_s_fmt_mplane(struct file *file, void *priv,
struct v4l2_format *f)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_dev *fimc = ctx-fimc_dev;
- struct fimc_frame *frame;
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc-vid_cap.ctx;
struct v4l2_pix_format_mplane *pix;
+ struct fimc_frame *frame;
int ret;
int i;
if (f-type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
return -EINVAL;
- ret = fimc_vidioc_try_fmt_mplane(file, priv, f);
+ ret = fimc_try_fmt_mplane(ctx, f);
if (ret)
return ret;
@@ -443,7 +465,7 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
static int fimc_cap_enum_input(struct file *file, void *priv,
struct v4l2_input *i)
{
- struct fimc_ctx *ctx = priv;
+ struct fimc_dev *fimc = video_drvdata(file);
if (i-index != 0)
return -EINVAL;
@@ -467,8 +489,8 @@ static int fimc_cap_g_input(struct file *file, void *priv,
unsigned int *i)
static int fimc_cap_streamon(struct file *file, void *priv,
enum v4l2_buf_type type)
{
- struct
[PATCH 03/19 v4] s5p-fimc: Limit number of available inputs to one
The current driver allowed camera sensors to be used only with single
FIMC H/W instance, FIMC0..FIMC2/3, designated at compile time. Remaining FIMC
entities could be used for video processing only, as mem-to-mem devices.
Required camera could be selected with S_INPUT ioctl at one devnode only.
However in that case it was not possible to use both cameras independently
at the same time, as all sensors were registered to single FIMC capture
driver. In most recent S5P SoC version there is enough FIMC H/W instances
to cover all physical camera interfaces.
Each FIMC instance exports its own video devnode. Thus we distribute
the camera sensors one per each /dev/video? by default. It will allow to
use both camera simultaneously by opening different video node.
The camera sensors at FIMC are now not selected with S_INPUT ioctl, there
is one input only available per /dev/video?.
By default a single sensor is connected at FIMC input as specified by the
media device platform data subdev description table. This assignment
can be changed at runtime through the pipeline reconfiguration at the media
device level.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 43 ---
1 files changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 6efd952..b786c2c 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -577,57 +577,26 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
}
static int fimc_cap_enum_input(struct file *file, void *priv,
-struct v4l2_input *i)
+ struct v4l2_input *i)
{
struct fimc_ctx *ctx = priv;
- struct s5p_platform_fimc *pldata = ctx-fimc_dev-pdata;
- struct s5p_fimc_isp_info *isp_info;
- if (i-index = pldata-num_clients)
+ if (i-index != 0)
return -EINVAL;
- isp_info = pldata-isp_info[i-index];
i-type = V4L2_INPUT_TYPE_CAMERA;
- strncpy(i-name, isp_info-board_info-type, 32);
return 0;
}
-static int fimc_cap_s_input(struct file *file, void *priv,
- unsigned int i)
+static int fimc_cap_s_input(struct file *file, void *priv, unsigned int i)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_dev *fimc = ctx-fimc_dev;
- struct s5p_platform_fimc *pdata = fimc-pdata;
-
- if (fimc_capture_active(ctx-fimc_dev))
- return -EBUSY;
-
- if (i = pdata-num_clients)
- return -EINVAL;
-
-
- if (fimc-vid_cap.sd) {
- int ret = v4l2_subdev_call(fimc-vid_cap.sd, core, s_power, 0);
- if (ret)
- err(s_power failed: %d, ret);
-
- clk_disable(fimc-clock[CLK_CAM]);
- }
-
- /* Release the attached sensor subdevice. */
- fimc_subdev_unregister(fimc);
-
- return fimc_isp_subdev_init(fimc, i);
+ return i == 0 ? i : -EINVAL;
}
-static int fimc_cap_g_input(struct file *file, void *priv,
- unsigned int *i)
+static int fimc_cap_g_input(struct file *file, void *priv, unsigned int *i)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_vid_cap *cap = ctx-fimc_dev-vid_cap;
-
- *i = cap-input_index;
+ *i = 0;
return 0;
}
--
1.7.6
--
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 04/19 v4] s5p-fimc: Remove sensor management code from FIMC capture driver
The sensor subdevs need to be shared between all available FIMC instances.
Remove their registration from FIMC capture driver so they can then be
registered to the media device driver.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 139 +--
drivers/media/video/s5p-fimc/fimc-core.h|2 +-
2 files changed, 2 insertions(+), 139 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index b786c2c..40f3330 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -16,12 +16,9 @@
#include linux/bug.h
#include linux/interrupt.h
#include linux/device.h
-#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/list.h
#include linux/slab.h
-#include linux/clk.h
-#include linux/i2c.h
#include linux/videodev2.h
#include media/v4l2-device.h
@@ -32,126 +29,6 @@
#include fimc-core.h
-static struct v4l2_subdev *fimc_subdev_register(struct fimc_dev *fimc,
- struct s5p_fimc_isp_info *isp_info)
-{
- struct i2c_adapter *i2c_adap;
- struct fimc_vid_cap *vid_cap = fimc-vid_cap;
- struct v4l2_subdev *sd = NULL;
-
- i2c_adap = i2c_get_adapter(isp_info-i2c_bus_num);
- if (!i2c_adap)
- return ERR_PTR(-ENOMEM);
-
- sd = v4l2_i2c_new_subdev_board(vid_cap-v4l2_dev, i2c_adap,
- isp_info-board_info, NULL);
- if (!sd) {
- v4l2_err(vid_cap-v4l2_dev, failed to acquire subdev\n);
- return NULL;
- }
-
- v4l2_info(vid_cap-v4l2_dev, subdevice %s registered successfuly\n,
- isp_info-board_info-type);
-
- return sd;
-}
-
-static void fimc_subdev_unregister(struct fimc_dev *fimc)
-{
- struct fimc_vid_cap *vid_cap = fimc-vid_cap;
- struct i2c_client *client;
-
- if (vid_cap-input_index 0)
- return; /* Subdevice already released or not registered. */
-
- if (vid_cap-sd) {
- v4l2_device_unregister_subdev(vid_cap-sd);
- client = v4l2_get_subdevdata(vid_cap-sd);
- i2c_unregister_device(client);
- i2c_put_adapter(client-adapter);
- vid_cap-sd = NULL;
- }
-
- vid_cap-input_index = -1;
-}
-
-/**
- * fimc_subdev_attach - attach v4l2_subdev to camera host interface
- *
- * @fimc: FIMC device information
- * @index: index to the array of available subdevices,
- *-1 for full array search or non negative value
- *to select specific subdevice
- */
-static int fimc_subdev_attach(struct fimc_dev *fimc, int index)
-{
- struct fimc_vid_cap *vid_cap = fimc-vid_cap;
- struct s5p_platform_fimc *pdata = fimc-pdata;
- struct s5p_fimc_isp_info *isp_info;
- struct v4l2_subdev *sd;
- int i;
-
- for (i = 0; i pdata-num_clients; ++i) {
- isp_info = pdata-isp_info[i];
-
- if (index = 0 i != index)
- continue;
-
- sd = fimc_subdev_register(fimc, isp_info);
- if (!IS_ERR_OR_NULL(sd)) {
- vid_cap-sd = sd;
- vid_cap-input_index = i;
-
- return 0;
- }
- }
-
- vid_cap-input_index = -1;
- vid_cap-sd = NULL;
- v4l2_err(vid_cap-v4l2_dev, fimc%d: sensor attach failed\n,
-fimc-id);
- return -ENODEV;
-}
-
-static int fimc_isp_subdev_init(struct fimc_dev *fimc, unsigned int index)
-{
- struct s5p_fimc_isp_info *isp_info;
- struct s5p_platform_fimc *pdata = fimc-pdata;
- int ret;
-
- if (index = pdata-num_clients)
- return -EINVAL;
-
- isp_info = pdata-isp_info[index];
-
- if (isp_info-clk_frequency)
- clk_set_rate(fimc-clock[CLK_CAM], isp_info-clk_frequency);
-
- ret = clk_enable(fimc-clock[CLK_CAM]);
- if (ret)
- return ret;
-
- ret = fimc_subdev_attach(fimc, index);
- if (ret)
- return ret;
-
- ret = fimc_hw_set_camera_polarity(fimc, isp_info);
- if (ret)
- return ret;
-
- ret = v4l2_subdev_call(fimc-vid_cap.sd, core, s_power, 1);
- if (!ret)
- return ret;
-
- /* enabling power failed so unregister subdev */
- fimc_subdev_unregister(fimc);
-
- v4l2_err(fimc-vid_cap.v4l2_dev, ISP initialization failed: %d\n,
-ret);
-
- return ret;
-}
-
static void fimc_capture_state_cleanup(struct fimc_dev *fimc)
{
struct fimc_vid_cap *cap = fimc-vid_cap;
@@ -411,15 +288,7 @@ static int fimc_capture_open(struct file *file)
if (ret)
return ret;
- if (++fimc-vid_cap.refcnt == 1) {
- ret =
[PATCH 02/19 v4] s5p-fimc: Remove sclk_cam clock handling
There are 2 separate clock outputs available in the SoC for external sensors.
These two clocks can be shared among all FIMC entities and there is
currently no any arbitration of the clocks in the driver.
So make the capture driver not touching these clocks and let them be
be properly handled at the media device driver level, enabling proper
arbitration between FIMC entities.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c | 12 ++--
drivers/media/video/s5p-fimc/fimc-core.h |3 +--
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index e042fdc..1d8d655 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -30,7 +30,7 @@
#include fimc-core.h
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
- sclk_fimc, fimc, sclk_cam
+ sclk_fimc, fimc
};
static struct fimc_fmt fimc_formats[] = {
@@ -1636,7 +1636,6 @@ static int fimc_probe(struct platform_device *pdev)
struct samsung_fimc_driverdata *drv_data;
struct s5p_platform_fimc *pdata;
int ret = 0;
- int cap_input_index = -1;
dev_dbg(pdev-dev, %s():\n, __func__);
@@ -1689,14 +1688,6 @@ static int fimc_probe(struct platform_device *pdev)
goto err_req_region;
}
- fimc-num_clocks = MAX_FIMC_CLOCKS - 1;
-
- /* Check if a video capture node needs to be registered. */
- if (pdata pdata-num_clients 0) {
- cap_input_index = 0;
- fimc-num_clocks++;
- }
-
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(pdev-dev, failed to get IRQ resource\n);
@@ -1705,6 +1696,7 @@ static int fimc_probe(struct platform_device *pdev)
}
fimc-irq = res-start;
+ fimc-num_clocks = MAX_FIMC_CLOCKS;
ret = fimc_clk_get(fimc);
if (ret)
goto err_regs_unmap;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index c8a2bab..d82bff8 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -34,7 +34,7 @@
/* Time to wait for next frame VSYNC interrupt while stopping operation. */
#define FIMC_SHUTDOWN_TIMEOUT ((100*HZ)/1000)
-#define MAX_FIMC_CLOCKS3
+#define MAX_FIMC_CLOCKS2
#define MODULE_NAMEs5p-fimc
#define FIMC_MAX_DEVS 4
#define FIMC_MAX_OUT_BUFS 4
@@ -46,7 +46,6 @@
enum {
CLK_BUS,
CLK_GATE,
- CLK_CAM,
};
enum fimc_dev_flags {
--
1.7.6
--
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 01/19 v4] s5p-fimc: Remove registration of video nodes from probe()
Do not register video nodes during FIMC device probe. Also make
fimc_register_m2m_device() public for use by the media device driver.
The video nodes are to be registered during the media device driver
initialization, altogether with the subdev devnodes. The video
capture nodes need to be registered as last ones when the remaining
pipeline elements are already initialized.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 14 +-
drivers/media/video/s5p-fimc/fimc-core.c| 55 ++
drivers/media/video/s5p-fimc/fimc-core.h|1 +
3 files changed, 17 insertions(+), 53 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 19d398b..6efd952 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -905,19 +905,8 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
if (ret)
goto err_ent;
- ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
- if (ret) {
- v4l2_err(v4l2_dev, Failed to register video device\n);
- goto err_vd_reg;
- }
-
- v4l2_info(v4l2_dev,
- FIMC capture driver registered as /dev/video%d\n,
- vfd-num);
return 0;
-err_vd_reg:
- media_entity_cleanup(vfd-entity);
err_ent:
video_device_release(vfd);
err_v4l2_reg:
@@ -934,7 +923,10 @@ void fimc_unregister_capture_device(struct fimc_dev *fimc)
if (vfd) {
media_entity_cleanup(vfd-entity);
+ /* Can also be called if video device was
+ not registered */
video_unregister_device(vfd);
}
kfree(fimc-vid_cap.ctx);
+ fimc-vid_cap.ctx = NULL;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index fdc1d75..e042fdc 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1494,7 +1494,7 @@ static struct v4l2_m2m_ops m2m_ops = {
.job_abort = fimc_job_abort,
};
-static int fimc_register_m2m_device(struct fimc_dev *fimc)
+int fimc_register_m2m_device(struct fimc_dev *fimc)
{
struct video_device *vfd;
struct platform_device *pdev;
@@ -1541,22 +1541,9 @@ static int fimc_register_m2m_device(struct fimc_dev
*fimc)
}
ret = media_entity_init(vfd-entity, 0, NULL, 0);
- if (ret)
- goto err_m2m_r3;
-
- ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
- if (ret) {
- v4l2_err(v4l2_dev,
-%s(): failed to register video device\n, __func__);
- goto err_m2m_r4;
- }
- v4l2_info(v4l2_dev,
- FIMC m2m driver registered as /dev/video%d\n, vfd-num);
+ if (!ret)
+ return 0;
- return 0;
-err_m2m_r4:
- media_entity_cleanup(vfd-entity);
-err_m2m_r3:
v4l2_m2m_release(fimc-m2m.m2m_dev);
err_m2m_r2:
video_device_release(fimc-m2m.vfd);
@@ -1566,15 +1553,19 @@ err_m2m_r1:
return ret;
}
-static void fimc_unregister_m2m_device(struct fimc_dev *fimc)
+void fimc_unregister_m2m_device(struct fimc_dev *fimc)
{
- if (fimc == NULL)
+ if (!fimc)
return;
- v4l2_m2m_release(fimc-m2m.m2m_dev);
+ if (fimc-m2m.m2m_dev)
+ v4l2_m2m_release(fimc-m2m.m2m_dev);
v4l2_device_unregister(fimc-m2m.v4l2_dev);
- media_entity_cleanup(fimc-m2m.vfd-entity);
- video_unregister_device(fimc-m2m.vfd);
+ if (fimc-m2m.vfd) {
+ media_entity_cleanup(fimc-m2m.vfd-entity);
+ /* Can also be called if video device wasn't registered */
+ video_unregister_device(fimc-m2m.vfd);
+ }
}
static void fimc_clk_put(struct fimc_dev *fimc)
@@ -1739,27 +1730,11 @@ static int fimc_probe(struct platform_device *pdev)
goto err_pm;
}
- ret = fimc_register_m2m_device(fimc);
- if (ret)
- goto err_alloc;
-
- /* At least one camera sensor is required to register capture node */
- if (cap_input_index = 0) {
- ret = fimc_register_capture_device(fimc);
- if (ret)
- goto err_m2m;
- }
-
- dev_dbg(pdev-dev, %s(): fimc-%d registered successfully\n,
- __func__, fimc-id);
+ dev_dbg(pdev-dev, FIMC.%d registered successfully\n, fimc-id);
pm_runtime_put(pdev-dev);
return 0;
-err_m2m:
- fimc_unregister_m2m_device(fimc);
-err_alloc:
- vb2_dma_contig_cleanup_ctx(fimc-alloc_ctx);
err_pm:
pm_runtime_put(pdev-dev);
err_irq:
@@ -1773,7 +1748,6 @@ err_req_region:
kfree(fimc-regs_res);
err_info:
kfree(fimc);
-
Updated DVB-T scandata for es-Donostia
Hi, This is the updated scan data for es-Donostia: T 49000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 55400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 56200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 62600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 63400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 65800 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 69000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 78600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 81000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 85000 8MHz 2/3 NONE QAM64 8k 1/4 NONE Regards, Tuukka -- 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: Getting started with OMAP3 ISP
On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas g...@mlbassoc.com wrote:
- entity 16: tvp5150m1 2-005c (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev8
pad0: Output [unknown 720x480 (1,1)/720x480]
- 'OMAP3 ISP CCDC':pad0 [ACTIVE]
Ideas where to look for the 'unknown' mode?
I didn't notice that, if you are using UYVY8_2X8 the reason is in
media-ctl main.c:
{ UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
You can add a line like:
{ UYVY2X8, V4L2_MBUS_FMT_UYVY8_2X8 },
recompile and it should work, i'll try it now.
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: Getting started with OMAP3 ISP
On Thu, Sep 1, 2011 at 6:14 PM, Enrico ebut...@users.berlios.de wrote:
On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas g...@mlbassoc.com wrote:
- entity 16: tvp5150m1 2-005c (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev8
pad0: Output [unknown 720x480 (1,1)/720x480]
- 'OMAP3 ISP CCDC':pad0 [ACTIVE]
Ideas where to look for the 'unknown' mode?
I didn't notice that, if you are using UYVY8_2X8 the reason is in
media-ctl main.c:
{ UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
You can add a line like:
{ UYVY2X8, V4L2_MBUS_FMT_UYVY8_2X8 },
recompile and it should work, i'll try it now.
That worked, but now there is another problem.
yavta will set UYVY (PIX_FMT), this will cause a call to
ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
for (i = 0; i ARRAY_SIZE(formats); ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
that is it will stop at the first matching array item, and that's:
{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_UYVY8_1X16, 0,
V4L2_PIX_FMT_UYVY, 16, 16, },
but you wanted this:
{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
V4L2_MBUS_FMT_UYVY8_2X8, 0,
V4L2_PIX_FMT_UYVY, 8, 16, },
so a better check could be to check for width too, but i don't know if
it's possibile to pass a width requirement or if it's already there in
some struct passed to the function.
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: Getting started with OMAP3 ISP
Hi Enrico,
On Thursday 01 September 2011 19:24:54 Enrico wrote:
On Thu, Sep 1, 2011 at 6:14 PM, Enrico ebut...@users.berlios.de wrote:
On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomas g...@mlbassoc.com wrote:
- entity 16: tvp5150m1 2-005c (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev8
pad0: Output [unknown 720x480 (1,1)/720x480]
- 'OMAP3 ISP CCDC':pad0 [ACTIVE]
Ideas where to look for the 'unknown' mode?
I didn't notice that, if you are using UYVY8_2X8 the reason is in
media-ctl main.c:
{ UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
You can add a line like:
{ UYVY2X8, V4L2_MBUS_FMT_UYVY8_2X8 },
recompile and it should work, i'll try it now.
That worked, but now there is another problem.
That's correct. My bad for not spotting it sooner.
yavta will set UYVY (PIX_FMT), this will cause a call to
ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
for (i = 0; i ARRAY_SIZE(formats); ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
that is it will stop at the first matching array item, and that's:
{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_UYVY8_1X16, 0,
V4L2_PIX_FMT_UYVY, 16, 16, },
but you wanted this:
{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
V4L2_MBUS_FMT_UYVY8_2X8, 0,
V4L2_PIX_FMT_UYVY, 8, 16, },
so a better check could be to check for width too, but i don't know if
it's possibile to pass a width requirement or if it's already there in
some struct passed to the function.
That's not really an issue, as the isp_video_pix_to_mbus() and
isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill
the bytesperline and sizeimage fields. From a quick look at the code
isp_video_check_format() should succeed as well.
Have you run into any specific issue with isp_video_pix_to_mbus() when using
V4L2_MBUS_FMT_UYVY8_2X8 ?
--
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: Getting started with OMAP3 ISP
On 2011-09-01 12:14, Laurent Pinchart wrote:
Hi Enrico,
On Thursday 01 September 2011 19:24:54 Enrico wrote:
On Thu, Sep 1, 2011 at 6:14 PM, Enricoebut...@users.berlios.de wrote:
On Thu, Sep 1, 2011 at 5:16 PM, Gary Thomasg...@mlbassoc.com wrote:
- entity 16: tvp5150m1 2-005c (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev8
pad0: Output [unknown 720x480 (1,1)/720x480]
- 'OMAP3 ISP CCDC':pad0 [ACTIVE]
Ideas where to look for the 'unknown' mode?
I didn't notice that, if you are using UYVY8_2X8 the reason is in
media-ctl main.c:
{ UYVY, V4L2_MBUS_FMT_UYVY8_1X16 },
You can add a line like:
{ UYVY2X8, V4L2_MBUS_FMT_UYVY8_2X8 },
recompile and it should work, i'll try it now.
That worked, but now there is another problem.
That's correct. My bad for not spotting it sooner.
Will you be adding this to the media-ctl tree? Would you like a patch?
yavta will set UYVY (PIX_FMT), this will cause a call to
ispvideo.c:isp_video_pix_to_mbus(..), that will do this:
for (i = 0; i ARRAY_SIZE(formats); ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
that is it will stop at the first matching array item, and that's:
{ V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_UYVY8_1X16, 0,
V4L2_PIX_FMT_UYVY, 16, 16, },
but you wanted this:
{ V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_UYVY8_2X8,
V4L2_MBUS_FMT_UYVY8_2X8, 0,
V4L2_PIX_FMT_UYVY, 8, 16, },
so a better check could be to check for width too, but i don't know if
it's possibile to pass a width requirement or if it's already there in
some struct passed to the function.
That's not really an issue, as the isp_video_pix_to_mbus() and
isp_video_mbus_to_pix() calls in isp_video_set_format() are just used to fill
the bytesperline and sizeimage fields. From a quick look at the code
isp_video_check_format() should succeed as well.
Have you run into any specific issue with isp_video_pix_to_mbus() when using
V4L2_MBUS_FMT_UYVY8_2X8 ?
Not yet - I was able to configure the pipeline as
# media-ctl -f 'tvp5150m1 2-005c:0[UYVY2X8 720x480], OMAP3 ISP CCDC:0[UYVY2X8
720x480], OMAP3 ISP CCDC:1[UYVY2X8 720x480]'
and this gets me all the way into my driver (which I'm now working on)
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using atmel-isi for direct output on framebuffer ?
Hi Thomas On Thu, 1 Sep 2011, Thomas Petazzoni wrote: Hello Josh, I am currently looking at V4L2 and your atmel-isi driver for an AT91 based platform on which I would like the ISI interface to capture the image from a camera and have this image directly output in RGB format at a specific location on the screen (so that it can be nicely integrated into a Qt application for example). Isn't this what V4L2_CAP_VIDEO_OVERLAY type drivers are doing? I've never dealt with those, but it seems to be exactly what you need. ATM there are no soc-camera drivers, implementing this capability, so, looks like implementing this in atmel-isi won't be a very boring task for you;-) Thanks Guennadi At the moment, I grab frames from the V4L2 device to userspace, do the YUV - RGB conversion manually in my application, and then displays the converted frame on the framebuffer thanks to normal Qt painting mechanisms. This works, but obviously consumes a lot of CPU. From the AT91 datasheet, I understand that the ISI interface is capable of doing the YUV - RGB conversion and is also capable of outputting the frame at some location in the framebuffer, but I don't see how to use this capability with the Linux V4L2 and framebuffer infrastructures. Is this possible ? If so, could you provide some pointers or starting points to get me started ? If not, what is missing in the driver ? Thanks a lot, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote: On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler sits...@yahoo.com wrote: I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a USB webcam. See below: Could you try the attached patch? This patch fixed the oops but extending the sequence (enable camera, start cheese, disable camera, watch cheese pause, enable camera, quit cheese, start cheese) causes the following poison overwritten warning to appear: [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) [ 191.277965] input: CNF7129 as /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 [ 220.287366] = [ 220.287379] BUG kmalloc-512: Poison overwritten [ 220.287384] - [ 220.287387] [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of 0x6b [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50 age=210617 cpu=0 pid=16 [ 220.287421] T.974+0x29d/0x5e0 [ 220.287427] kmem_cache_alloc+0x167/0x180 [ 220.287433] uvc_probe+0x54/0xd50 [ 220.287441] usb_probe_interface+0xd5/0x1d0 [ 220.287448] driver_probe_device+0x80/0x1a0 [ 220.287455] __device_attach+0x41/0x50 [ 220.287460] bus_for_each_drv+0x53/0x80 [ 220.287466] device_attach+0x89/0xa0 [ 220.287472] bus_probe_device+0x25/0x40 [ 220.287478] device_add+0x5a9/0x660 [ 220.287484] usb_set_configuration+0x562/0x670 [ 220.287491] generic_probe+0x36/0x90 [ 220.287497] usb_probe_device+0x24/0x50 [ 220.287503] driver_probe_device+0x80/0x1a0 [ 220.287509] __device_attach+0x41/0x50 [ 220.287515] bus_for_each_drv+0x53/0x80 [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0 pid=1645 [ 220.287530] __slab_free+0x1f8/0x300 [ 220.287536] kfree+0x100/0x140 [ 220.287541] uvc_delete+0xfe/0x110 [ 220.287547] uvc_release+0x25/0x30 [ 220.287555] v4l2_device_release+0x9d/0xc0 [ 220.287560] device_release+0x19/0x90 [ 220.287567] kobject_release+0x3c/0x90 [ 220.287573] kref_put+0x2c/0x60 [ 220.287578] kobject_put+0x1d/0x50 [ 220.287587] put_device+0xf/0x20 [ 220.287593] v4l2_release+0x56/0x60 [ 220.287599] fput+0xcc/0x220 [ 220.287605] filp_close+0x44/0x70 [ 220.287613] put_files_struct+0x158/0x180 [ 220.287619] exit_files+0x40/0x50 [ 220.287626] do_exit+0xec/0x660 [ 220.287632] INFO: Slab 0xef722180 objects=23 used=23 fp=0x (null) flags=0x4080 [ 220.287639] INFO: Object 0xec90f060 @offset=12384 fp=0xec90cac0 [ 220.287642] [ 220.287647] Bytes b4 0xec90f050: 6d 06 00 00 88 c8 fe ff 5a 5a 5a 5a 5a 5a 5a 5a mÈþÿ [ 220.287681] Object 0xec90f060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287713] Object 0xec90f070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287746] Object 0xec90f080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287778] Object 0xec90f090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287811] Object 0xec90f0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287843] Object 0xec90f0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287876] Object 0xec90f0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287908] Object 0xec90f0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287941] Object 0xec90f0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287973] Object 0xec90f0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288006] Object 0xec90f100: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f110: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f120: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f130: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f140: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f150: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkk [ 220.288012] Object 0xec90f160: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f170: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f180: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f190: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f1a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f1b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012]
Re: [PATCH v2 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Hi Manjunath,
A few comments below...
On 08/29/2011 05:07 PM, Manjunath Hadli wrote:
add support for dm3xx IPIPEIF hardware setup. This is the
lowest software layer for the dm3x vpfe driver which directly
accesses hardware. Add support for features like default
pixel correction, dark frame substraction and hardware setup.
Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netaguntenagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/dm3xx_ipipeif.c | 317
+++
drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++
include/linux/dm3xx_ipipeif.h | 64 ++
3 files changed, 639 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h
create mode 100644 include/linux/dm3xx_ipipeif.h
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
b/drivers/media/video/davinci/dm3xx_ipipeif.c
new file mode 100644
index 000..ebc8895
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
@@ -0,0 +1,317 @@
...
+
+static void ipipeif_config_dpc(struct ipipeif_dpc *dpc)
+{
+ u32 val;
+
+ /* Intialize val*/
+ val = 0;
s/Intialize/Initialize ? But this comment doesn't seem much helpful
and could probably be removed. Also it might be better to just do:
u32 val = 0;
+
+ if (dpc-en) {
+ val = (dpc-en 1) IPIPEIF_DPC2_EN_SHIFT;
+ val |= dpc-thr IPIPEIF_DPC2_THR_MASK;
+ }
+
+ regw_if(val, IPIPEIF_DPC2);
+}
+
...
+
+static int __devinit dm3xx_ipipeif_probe(struct platform_device *pdev)
+{
+ static resource_size_t res_len;
+ struct resource *res;
+ int status;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res-end - res-start + 1;
resource_size(res) macro could be used here
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res)
+ return -EBUSY;
+
+ ipipeif_base_addr = ioremap_nocache(res-start, res_len);
+ if (!ipipeif_base_addr) {
+ status = -EBUSY;
+ goto fail;
+ }
+ return 0;
+
+fail:
+ release_mem_region(res-start, res_len);
+
+ return status;
+}
+
+static int dm3xx_ipipeif_remove(struct platform_device *pdev)
+{
+ struct resource *res;
+
+ iounmap(ipipeif_base_addr);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res)
+ release_mem_region(res-start, res-end - res-start + 1);
release_mem_region(res-start, resource_size(res));
+ return 0;
+}
+
+static struct platform_driver dm3xx_ipipeif_driver = {
+ .driver = {
+ .name = dm3xx_ipipeif,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(dm3xx_ipipeif_remove),
+ .probe = dm3xx_ipipeif_probe,
+};
+
+static int dm3xx_ipipeif_init(void)
+{
+ return platform_driver_register(dm3xx_ipipeif_driver);
+}
+
+static void dm3xx_ipipeif_exit(void)
+{
+ platform_driver_unregister(dm3xx_ipipeif_driver);
+}
+
+module_init(dm3xx_ipipeif_init);
+module_exit(dm3xx_ipipeif_exit);
+
+MODULE_LICENSE(GPL2);
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.h
b/drivers/media/video/davinci/dm3xx_ipipeif.h
new file mode 100644
index 000..f3289f0
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.h
@@ -0,0 +1,258 @@
+/*
...
+
+/* IPIPEIF Register Offsets from the base address */
+#define IPIPEIF_ENABLE (0x00)
+#define IPIPEIF_CFG1 (0x04)
+#define IPIPEIF_PPLN (0x08)
+#define IPIPEIF_LPFR (0x0c)
+#define IPIPEIF_HNUM (0x10)
+#define IPIPEIF_VNUM (0x14)
+#define IPIPEIF_ADDRU(0x18)
+#define IPIPEIF_ADDRL(0x1c)
+#define IPIPEIF_ADOFS(0x20)
+#define IPIPEIF_RSZ (0x24)
+#define IPIPEIF_GAIN (0x28)
+
+/* Below registers are available only on IPIPE 5.1 */
+#define IPIPEIF_DPCM (0x2c)
+#define IPIPEIF_CFG2 (0x30)
+#define IPIPEIF_INIRSZ (0x34)
+#define IPIPEIF_OCLIP(0x38)
+#define IPIPEIF_DTUDF(0x3c)
+#define IPIPEIF_CLKDIV (0x40)
+#define IPIPEIF_DPC1 (0x44)
+#define IPIPEIF_DPC2 (0x48)
+#define IPIPEIF_DFSGVL (0x4c)
+#define IPIPEIF_DFSGTH (0x50)
+#define IPIPEIF_RSZ3A(0x54)
+#define IPIPEIF_INIRSZ3A (0x58)
+#define IPIPEIF_RSZ_MIN (16)
+#define IPIPEIF_RSZ_MAX (112)
+#define IPIPEIF_RSZ_CONST
Re: [PATCH v2 4/8] davinci: vpfe: add support for CCDC hardware for dm365
Hi Manjunath, few more comments below.. On 08/29/2011 05:07 PM, Manjunath Hadli wrote: add support for ccdc on dm365 SoC. ccdc is responsible for capturing video data- both raw bayer through sync seperate signals and through BT656/1120 interfaces. This driver implements the hardware functionality. Mainly- setting of hardware, validation of parameters, and isr configuration. Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Signed-off-by: Nagabhushana Netaguntenagabhushana.netagu...@ti.com --- drivers/media/video/davinci/ccdc_types.h | 43 + drivers/media/video/davinci/dm365_ccdc.c | 1519 + drivers/media/video/davinci/dm365_ccdc.h | 88 ++ drivers/media/video/davinci/dm365_ccdc_regs.h | 309 + include/linux/dm365_ccdc.h| 664 +++ 5 files changed, 2623 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/ccdc_types.h create mode 100644 drivers/media/video/davinci/dm365_ccdc.c create mode 100644 drivers/media/video/davinci/dm365_ccdc.h create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h create mode 100644 include/linux/dm365_ccdc.h ... +#define CCDC_LINEAR_LUT0_ADDR0x1c7c000 +#define CCDC_LINEAR_LUT1_ADDR0x1c7c400 + +/* Masks Shifts below */ +#define START_PX_HOR_MASK(0x7fff) +#define NUM_PX_HOR_MASK (0x7fff) +#define START_VER_ONE_MASK (0x7fff) +#define START_VER_TWO_MASK (0x7fff) +#define NUM_LINES_VER(0x7fff) + +/* gain - offset masks */ +#define GAIN_INTEGER_MASK(0x7) +#define GAIN_INTEGER_SHIFT (0x9) +#define GAIN_DECIMAL_MASK(0x1ff) +#define OFFSET_MASK (0xfff) +#define GAIN_SDRAM_EN_SHIFT (12) +#define GAIN_IPIPE_EN_SHIFT (13) +#define GAIN_H3A_EN_SHIFT(14) +#define OFST_SDRAM_EN_SHIFT (8) +#define OFST_IPIPE_EN_SHIFT (9) +#define OFST_H3A_EN_SHIFT(10) +#define GAIN_OFFSET_EN_MASK (0x7700) + +/* Culling */ +#define CULL_PAT_EVEN_LINE_SHIFT (8) + +/* CCDCFG register */ +#define CCDC_YCINSWP_RAW (0x00 4) +#define CCDC_YCINSWP_YCBCR (0x01 4) +#define CCDC_CCDCFG_FIDMD_LATCH_VSYNC(0x00 6) +#define CCDC_CCDCFG_WENLOG_AND (0x00 8) +#define CCDC_CCDCFG_TRGSEL_WEN (0x00 9) +#define CCDC_CCDCFG_EXTRG_DISABLE(0x00 10) +#define CCDC_LATCH_ON_VSYNC_DISABLE (0x01 15) +#define CCDC_LATCH_ON_VSYNC_ENABLE (0x00 15) +#define CCDC_DATA_PACK_MASK (0x03) +#define CCDC_DATA_PACK16 (0x0) +#define CCDC_DATA_PACK12 (0x1) +#define CCDC_DATA_PACK8 (0x2) +#define CCDC_PIX_ORDER_SHIFT (11) +#define CCDC_PIX_ORDER_MASK (0x01) +#define CCDC_BW656_ENABLE(0x01 5) + +/* MODESET registers */ +#define CCDC_VDHDOUT_INPUT (0x00 0) +#define CCDC_INPUT_MASK (0x03) +#define CCDC_INPUT_SHIFT (12) +#define CCDC_RAW_INPUT_MODE (0x00) +#define CCDC_FID_POL_MASK(0x01) +#define CCDC_FID_POL_SHIFT (4) +#define CCDC_HD_POL_MASK (0x01) +#define CCDC_HD_POL_SHIFT(3) +#define CCDC_VD_POL_MASK (0x01) +#define CCDC_VD_POL_SHIFT(2) +#define CCDC_DATAPOL_NORMAL (0x00) +#define CCDC_DATAPOL_MASK(0x01) +#define CCDC_DATAPOL_SHIFT (6) +#define CCDC_EXWEN_DISABLE (0x00) +#define CCDC_EXWEN_MASK (0x01) +#define CCDC_EXWEN_SHIFT (5) +#define CCDC_FRM_FMT_MASK(0x01) +#define CCDC_FRM_FMT_SHIFT (7) +#define CCDC_DATASFT_MASK(0x07) +#define CCDC_DATASFT_SHIFT (8) +#define CCDC_LPF_SHIFT (14) +#define CCDC_LPF_MASK(0x1) + +/* GAMMAWD registers */ +#define CCDC_ALAW_GAMA_WD_MASK (0xf) +#define CCDC_ALAW_GAMA_WD_SHIFT (1) +#define CCDC_ALAW_ENABLE (0x01) +#define CCDC_GAMMAWD_CFA_MASK(0x01) +#define CCDC_GAMMAWD_CFA_SHIFT (5) + +/* HSIZE registers */ +#define CCDC_HSIZE_FLIP_MASK (0x01) +#define CCDC_HSIZE_FLIP_SHIFT(12) +#define CCDC_LINEOFST_MASK (0xfff) + +/*
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler sits...@yahoo.com wrote: On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote: On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler sits...@yahoo.com wrote: I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a USB webcam. See below: Could you try the attached patch? This patch fixed the oops but extending the sequence (enable camera, start cheese, disable camera, watch cheese pause, enable camera, quit cheese, start cheese) causes the following poison overwritten warning to appear: It seems another bug, I can reproduce this as well. uvc_device is freed in uvc_delete, struct v4l2_device vdev is the member of struct uvc_device, so vdev is also freed. Later v4l2_device operations on vdev will overwrite the poison memory area. [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) [ 191.277965] input: CNF7129 as /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 [ 220.287366] = [ 220.287379] BUG kmalloc-512: Poison overwritten [ 220.287384] - [ 220.287387] [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of 0x6b [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50 age=210617 cpu=0 pid=16 [ 220.287421] T.974+0x29d/0x5e0 [ 220.287427] kmem_cache_alloc+0x167/0x180 [ 220.287433] uvc_probe+0x54/0xd50 [ 220.287441] usb_probe_interface+0xd5/0x1d0 [ 220.287448] driver_probe_device+0x80/0x1a0 [ 220.287455] __device_attach+0x41/0x50 [ 220.287460] bus_for_each_drv+0x53/0x80 [ 220.287466] device_attach+0x89/0xa0 [ 220.287472] bus_probe_device+0x25/0x40 [ 220.287478] device_add+0x5a9/0x660 [ 220.287484] usb_set_configuration+0x562/0x670 [ 220.287491] generic_probe+0x36/0x90 [ 220.287497] usb_probe_device+0x24/0x50 [ 220.287503] driver_probe_device+0x80/0x1a0 [ 220.287509] __device_attach+0x41/0x50 [ 220.287515] bus_for_each_drv+0x53/0x80 [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0 pid=1645 [ 220.287530] __slab_free+0x1f8/0x300 [ 220.287536] kfree+0x100/0x140 [ 220.287541] uvc_delete+0xfe/0x110 [ 220.287547] uvc_release+0x25/0x30 [ 220.287555] v4l2_device_release+0x9d/0xc0 [ 220.287560] device_release+0x19/0x90 [ 220.287567] kobject_release+0x3c/0x90 [ 220.287573] kref_put+0x2c/0x60 [ 220.287578] kobject_put+0x1d/0x50 [ 220.287587] put_device+0xf/0x20 [ 220.287593] v4l2_release+0x56/0x60 [ 220.287599] fput+0xcc/0x220 [ 220.287605] filp_close+0x44/0x70 [ 220.287613] put_files_struct+0x158/0x180 [ 220.287619] exit_files+0x40/0x50 [ 220.287626] do_exit+0xec/0x660 [ 220.287632] INFO: Slab 0xef722180 objects=23 used=23 fp=0x (null) flags=0x4080 [ 220.287639] INFO: Object 0xec90f060 @offset=12384 fp=0xec90cac0 [ 220.287642] [ 220.287647] Bytes b4 0xec90f050: 6d 06 00 00 88 c8 fe ff 5a 5a 5a 5a 5a 5a 5a 5a mÈþÿ [ 220.287681] Object 0xec90f060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287713] Object 0xec90f070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287746] Object 0xec90f080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287778] Object 0xec90f090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287811] Object 0xec90f0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287843] Object 0xec90f0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287876] Object 0xec90f0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287908] Object 0xec90f0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287941] Object 0xec90f0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287973] Object 0xec90f0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288006] Object 0xec90f100: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f110: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f120: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f130: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f140: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f150: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkk [ 220.288012] Object 0xec90f160: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f170: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012]
Re: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
On Fri, Sep 2, 2011 at 12:59 PM, Dave Young hidave.darks...@gmail.com wrote: On Fri, Sep 2, 2011 at 3:10 AM, Sitsofe Wheeler sits...@yahoo.com wrote: On Thu, Sep 01, 2011 at 05:02:51PM +0800, Dave Young wrote: On Tue, Aug 30, 2011 at 4:48 AM, Sitsofe Wheeler sits...@yahoo.com wrote: I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a USB webcam. See below: Could you try the attached patch? This patch fixed the oops but extending the sequence (enable camera, start cheese, disable camera, watch cheese pause, enable camera, quit cheese, start cheese) causes the following poison overwritten warning to appear: It seems another bug, I can reproduce this as well. uvc_device is freed in uvc_delete, struct v4l2_device vdev is the member of struct uvc_device, so vdev is also freed. Later v4l2_device operations on vdev will overwrite the poison memory area. Please try attached patch on top of previous one, in this patch I move v4l2_device_put after vdev-release in function v4l2_device_release Not sure if this is a right fix, comments? [ 191.240695] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) [ 191.277965] input: CNF7129 as /devices/pci:00/:00:1d.7/usb1/1-8/1-8:1.0/input/input9 [ 220.287366] = [ 220.287379] BUG kmalloc-512: Poison overwritten [ 220.287384] - [ 220.287387] [ 220.287394] INFO: 0xec90f150-0xec90f150. First byte 0x6a instead of 0x6b [ 220.287410] INFO: Allocated in uvc_probe+0x54/0xd50 age=210617 cpu=0 pid=16 [ 220.287421] T.974+0x29d/0x5e0 [ 220.287427] kmem_cache_alloc+0x167/0x180 [ 220.287433] uvc_probe+0x54/0xd50 [ 220.287441] usb_probe_interface+0xd5/0x1d0 [ 220.287448] driver_probe_device+0x80/0x1a0 [ 220.287455] __device_attach+0x41/0x50 [ 220.287460] bus_for_each_drv+0x53/0x80 [ 220.287466] device_attach+0x89/0xa0 [ 220.287472] bus_probe_device+0x25/0x40 [ 220.287478] device_add+0x5a9/0x660 [ 220.287484] usb_set_configuration+0x562/0x670 [ 220.287491] generic_probe+0x36/0x90 [ 220.287497] usb_probe_device+0x24/0x50 [ 220.287503] driver_probe_device+0x80/0x1a0 [ 220.287509] __device_attach+0x41/0x50 [ 220.287515] bus_for_each_drv+0x53/0x80 [ 220.287522] INFO: Freed in uvc_delete+0xfe/0x110 age=22 cpu=0 pid=1645 [ 220.287530] __slab_free+0x1f8/0x300 [ 220.287536] kfree+0x100/0x140 [ 220.287541] uvc_delete+0xfe/0x110 [ 220.287547] uvc_release+0x25/0x30 [ 220.287555] v4l2_device_release+0x9d/0xc0 [ 220.287560] device_release+0x19/0x90 [ 220.287567] kobject_release+0x3c/0x90 [ 220.287573] kref_put+0x2c/0x60 [ 220.287578] kobject_put+0x1d/0x50 [ 220.287587] put_device+0xf/0x20 [ 220.287593] v4l2_release+0x56/0x60 [ 220.287599] fput+0xcc/0x220 [ 220.287605] filp_close+0x44/0x70 [ 220.287613] put_files_struct+0x158/0x180 [ 220.287619] exit_files+0x40/0x50 [ 220.287626] do_exit+0xec/0x660 [ 220.287632] INFO: Slab 0xef722180 objects=23 used=23 fp=0x (null) flags=0x4080 [ 220.287639] INFO: Object 0xec90f060 @offset=12384 fp=0xec90cac0 [ 220.287642] [ 220.287647] Bytes b4 0xec90f050: 6d 06 00 00 88 c8 fe ff 5a 5a 5a 5a 5a 5a 5a 5a mÈþÿ [ 220.287681] Object 0xec90f060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287713] Object 0xec90f070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287746] Object 0xec90f080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287778] Object 0xec90f090: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287811] Object 0xec90f0a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287843] Object 0xec90f0b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287876] Object 0xec90f0c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287908] Object 0xec90f0d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287941] Object 0xec90f0e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.287973] Object 0xec90f0f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288006] Object 0xec90f100: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f110: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f120: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f130: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f140: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 220.288012] Object 0xec90f150: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b
