Re: S3C244X/S3C64XX SoC camera host interface driver questions
Hi, On 11/08/2012 07:47 PM, Andrey Gusakov wrote: Ok, thanks. I will add the missing CONFIG_PM_RUNTIME dependency in Kconfig. The driver has to have PM_RUNTIME enabled since on s3c64xx SoCs there are power domains and the camera power domain needs to be enabled for the CAMIF operation. The pm_runtime_* calls in the driver are supposed to ensure that. I wonder why it works for you without PM_RUNTIME, i.e. how comes the power domain is enabled. It is supposed to be off by default. DS says that all power domaint are on after reset. My bootloader did not switch then off. So when linux start everything is on. CONFIG_PM_RUNTIME was disabled, so nothing switch them off in linux too. Yes, indeed. But there was a PM code added that is supposed to disable all unused power domains on the system boot. I noticed that one needs to call explicitly s3c64xx_pm_init() function from machine_init() callback within the board file. So far this function is called only in mach-crag6410.c. I'm not sure it it won't kill the display if you use it though. Probably PM domain state should be read from a respective register and this information passed to pm_genpd_init() function within s3c64_pm_init(). I hope to eventually prepare the ov9650 sensor driver for mainline. Your help in making it ready for VER=0x52 would be very much appreciated. :-) I'll try to helpful. Next step is to make ov2460 work. For now I can only recommend you to make the ov2460 driver more similar to the ov9650 one. Thanks, I'll try. P.S. I add support of image effects just for fun. And found in DS that s3c2450 also support effects. It's FIMC in-between of 2440 and 6400/6410. Does anyone have s3c2450 hardware to test it? Patches adding image effect are welcome. I'm bit to busy to play with these things, other than I don't have hardware to test it. I wasn't really aware of CAMIF in s3c2450. I think a separate variant data structure would need to be defined for s3c2450. If anyone ever needs it it could be added easily. For now I'll pretend this version doesn't exist. :-) Attached. I often get VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device This is an issue in the v4l2-ctl, it is going to be fixed by adding VIDIOC_SUBDEV_QUERYCAP ioctl for subdevs. It has been just discussed today. I guess you get it when running v4l2-ctl on /dev/v4l-subdev* ? or system error: Inappropriate ioctl for device I think this one is caused by unimplemented VIDIOC_G/S_PARM ioctls at the s3c-camif driver. Is it because of not implemented set/get framerate func? How this Yes, I think so. ioctls as above. should work? I mean framerate heavy depend of sensor's settings. So set/get framerate call to fimc should get/set framerate from sensor. What is mechanism of such things? With user space subdev API one should control frame interval directly on the sensor subdev device node [1]. For Gstreamer to work with VIDIOC_G/S_PARM ioctls we need a dedicated v4l2 library (possibly with a plugin for s3c-camif, but that shouldn't be needed since it is very simple driver) that will translate those video node ioctls into the subdev node ioctls [2]. Unfortunately such library is still not available. And same question about synchronizing format of sensor and FIMC pads. I make ov2640 work, but if did not call media-ctl for sensor, format of FIMC sink pad and format of sensor source pad different. I think I missed something, but reading other sources did not help. As I explained previously, s3c-fimc is supposed to synchronize format with the sensor subdev. Have you got pad level get_fmt callback implemented in the ov2640 driver ? Could you post your 'media-ctl -p' output, run right after the system boot ? [1] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-frame-interval.html [2] http://git.linuxtv.org/v4l-utils.git/tree/ - From 04b88737f65f772f8b375234a92c7cdd481eac1b Mon Sep 17 00:00:00 2001 From: Andrey Gusakov dron_...@mail.ru Date: Mon, 5 Nov 2012 15:50:23 +0400 Subject: [PATCH] S3C-FIMC: add effect controls SN: I prefer using s3c-camif name, FIMC appears only in later version of the SoCs. Also would be nice to put at least some brief description why this patch is needed. Signed-off-by: Andrey Gusakov dron_...@mail.ru --- drivers/media/platform/s3c-camif/camif-capture.c | 58 -- drivers/media/platform/s3c-camif/camif-core.h|5 ++ drivers/media/platform/s3c-camif/camif-regs.c| 38 ++ drivers/media/platform/s3c-camif/camif-regs.h|6 ++- 4 files changed, 89 insertions(+), 18 deletions(-) diff --git a/drivers/media/platform/s3c-camif/camif-capture.c b/drivers/media/platform/s3c-camif/camif-capture.c index ca31c45..046ebf6 100644 --- a/drivers/media/platform/s3c-camif/camif-capture.c +++ b/drivers/media/platform/s3c-camif/camif-capture.c @@ -81,6 +81,9 @@ static int s3c_camif_hw_init(struct camif_dev *camif,
Re: [PATCH v7 0/8] of: add display helper
On Thu, Nov 08, 2012 at 03:35:47PM -0600, Rob Herring wrote: On 10/31/2012 04:28 AM, Steffen Trumtrar wrote: Hi! Finally, v7 of the series. Changes since v6: - get rid of some empty lines etc. - move functions to their subsystems - split of_ from non-of_ functions - add at least some kerneldoc to some functions Regards, Steffen Steffen Trumtrar (8): video: add display_timing struct and helpers of: add helper to parse display timings of: add generic videomode description video: add videomode helpers fbmon: add videomode helpers fbmon: add of_videomode helpers drm_modes: add videomode helpers drm_modes: add of_videomode helpers .../devicetree/bindings/video/display-timings.txt | 139 +++ drivers/gpu/drm/drm_modes.c| 78 + drivers/of/Kconfig | 12 ++ drivers/of/Makefile|2 + drivers/of/of_display_timings.c| 185 drivers/of/of_videomode.c | 47 + Not sure why you moved this, but please move this back to drivers/video. We're trying to move subsystem specific pieces out of drivers/of. Rob Hm, the of_xxx part always was in drivers/of, but I can move that. No problem. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 dma-buf support test with UVC + i915 test application
Em Thu, 08 Nov 2012 19:34:14 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: On Thursday 08 November 2012 19:14:18 Laurent Pinchart wrote: Hi Mauro, Here's the application I've used to test V4L2 dma-buf support with a UVC webcam and an Intel GPU supported by the i915 driver. The kernel code is available in my git tree at git://linuxtv.org/pinchartl/media.git devel/dma-buf-v10 (http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/devel/v4l2- clock) Don't forget to enable dma-buf and UVC support when compiling the kernel. The userspace code is based on the v4l2-drm-example application written by Tomasz (the original code is available at git://git.infradead.org/users/kmpark/public-apps). I need to clean up my modifications to push them back to the repository, in the meantime the code is attached to this e-mail. To compile the application, just run make with the KDIR variable set to the path to your Linux kernel tree with the dma-buf patches applied. Don't forget to make headers_install in the kernel tree as the Makefile will look for headers in $KDIR/usr. You will need a recent version of libdrm with plane support available. 2.4.39 should do. The following command line will capture VGA YUYV data from the webcam and display it on the screen. You need to run it in a console as root without the X server running. ./dmabuf-sharing -M i915 -o 7:3:1600x900 -i /dev/video0 -S 640,480 -f YUYV -F YUYV -s 640,480@0,0 -t 640,480@0,0 -b 2 I forgot to mention that the -o parameter takes the connector ID, CRTC ID and mode as parameters. The mode is easy to find, but the connector and CRTC IDs are a bit more tricky. You can run the modetest application (part of libdrm but not installed by most distributions, so a manual compilation is needed) to dump all CRTC, encoder and connector information to the console. Pick the connector associated with your display, and the CRTC associated with the encoder associated with that connector. Didn't work: $ sudo ./modetest trying to load module i915...failed. trying to load module radeon...failed. trying to load module nouveau...failed. trying to load module vmwgfx...failed. trying to load module omapdrm...failed. failed to load any modules, aborting. Even so, $ sudo /usr/bin/dristat /dev/dri/card0 and: $ lsmod|grep i915 i915 530346 2 video 18936 1 i915 i2c_algo_bit 13257 1 i915 drm_kms_helper 44701 1 i915 drm 255010 3 i915,drm_kms_helper i2c_core 38314 5 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit The GPU on this notebook is this one: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Dell Device 026f Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at f800 (64-bit, non-prefetchable) [size=1M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915 Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.8] Davinci VPBE feature enhancement and fixes
Hi Mauro, Can you please pull the following patches for Davinci VPBE driver. The first patch fixes the build warnings for readl/writel, the second patch migrates the driver to videobuf2 usage and the third patch set's device caps. Thanks and Regards, --Prabhakar Lad The following changes since commit 2cb654fd281e1929aa3b9f5f54f492135157a613: MAINTAINERS: add support for tea5761/tea5767 tuners (2012-11-02 12:09:00 -0200) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for_mauro Lad, Prabhakar (3): media: davinci: vpbe: fix build warning media: davinci: vpbe: migrate driver to videobuf2 media: davinci: vpbe: set device capabilities drivers/media/platform/davinci/Kconfig|2 +- drivers/media/platform/davinci/vpbe_display.c | 305 +++-- drivers/media/platform/davinci/vpbe_osd.c |9 +- include/media/davinci/vpbe_display.h | 15 +- include/media/davinci/vpbe_osd.h |2 +- 5 files changed, 199 insertions(+), 134 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
[GIT PULL FOR v3.8] Davinci media: migration to common clock framework
Hi Mauro,
Can you please pull the following patch which migrates the media
drivers for Davinci to common clock framework usage.
Thanks and Regards,
--Prabhakar Lad
The following changes since commit 2cb654fd281e1929aa3b9f5f54f492135157a613:
MAINTAINERS: add support for tea5761/tea5767 tuners (2012-11-02
12:09:00 -0200)
are available in the git repository at:
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git davinci_media
Murali Karicheri (1):
media:davinci: clk - {prepare/unprepare} for common clk
drivers/media/platform/davinci/dm355_ccdc.c |8 ++--
drivers/media/platform/davinci/dm644x_ccdc.c | 16 ++--
drivers/media/platform/davinci/isif.c|5 -
drivers/media/platform/davinci/vpbe.c| 10 +++---
drivers/media/platform/davinci/vpif.c|8
5 files changed, 31 insertions(+), 16 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] [media] vpif_display: fix return value check in vpif_reqbufs()
Hi Wei,
Thanks for the patch.
On Wed, Oct 24, 2012 at 4:59 PM, Wei Yongjun weiyj...@gmail.com wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function vb2_dma_contig_init_ctx() returns
ERR_PTR() and never returns NULL. The NULL test in the return value
check should be replaced with IS_ERR().
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/davinci/vpif_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index b716fbd..5453bbb 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -972,9 +972,9 @@ static int vpif_reqbufs(struct file *file, void *priv,
}
/* Initialize videobuf2 queue as per the buffer type */
common-alloc_ctx = vb2_dma_contig_init_ctx(vpif_dev);
- if (!common-alloc_ctx) {
+ if (IS_ERR(common-alloc_ctx)) {
Right check would be IS_ERR_OR_NULL(). Can you merge this
patch 'vpif_capture: fix return value check in vpif_reqbufs()' with
this one and post a v2 with above changes ?
Regards,
--Prabhakar Lad
vpif_err(Failed to get the context\n);
- return -EINVAL;
+ return PTR_ERR(common-alloc_ctx);
}
q = common-buffer_queue;
q-type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 回复： soc camera driver module may case memory leak
Hi
Well, I must confess, I'm surprised:-) It looks like you're right. This
leak, if indeed there is one, has been there since the very first version
of soc-camera. I've spent some time looking at the code and so far I don't
find an explanation for the missing videobuf_mmap_free() call. I'll have
another look and, unless I find an explanation, why it's not needed, I'll
make a patch.
Also keep in mind, that this bug is only relevant for videobuf(1) drivers,
which anyway have to be converted to videobuf2;-)
Thanks
Guennadi
On Wed, 7 Nov 2012, �~F~M�~[~^��~V wrote:
Dear Guennadi
I'm sure it's a bug.In linux-2.6.x, we call open() will allocate a struct
soc_camera_file which contains struct videobuf_queue;then usr will call
request_buffer, soc_camera module will call videobuf_alloc_vb(q) which will
be installed in q-bufs[i].
My question is how to free q-bufs[i] which is allocated from vb
= kzalloc(size + sizeof(*mem), GFP_KERNEL) if we use videobuf-dma-contig
memory model?
videobuf_mmap_free()-kfree(q-bufs[i]) should call at every
call close();we can't call kfree(q-bufs[i]) at q-ops-buf_release which is
called in stream_off(), because q-bufs[i] reserve struct videobuf_mapping,
unmap() will can't free videobuf which is used to store video data. Also
can't call videobuf_mmap_free()-kfree(q-bufs[i]) at last close(), because
in linux-2.6.x once open() allocates a videobuf_queue.
In linux-3.x.x, we should call
videobuf_mmap_free()-kfree(q-bufs[i]) only once at module remove callbcak
function.
You say, videobuf mmap allocations will be freed automatically.
I want to known soc_camera module how to free q-bufs[i] automatically.
If is there no bug in soc camera module , i'm sure all device
driver use soc camera module have bugs, such as sh_mobile_ceu_caera.c,
mx1_caera.c, mx3_caera.c etc. all of them donn't call
videobuf_mmap_free()-kfree(q-bufs[i]).
Your reply will be higly appreciated!
-- 原始邮件 --
发件人: Guennadi Liakhovetskig.liakhovet...@gmx.de;
发送时间: 2012年11月6日(星期二) 晚上7:30
收件人: 再回首308123...@qq.com;
抄送: linux-medialinux-media@vger.kernel.org;
主题: Re: soc camera driver module may case memory leak
Hi
On Mon, 5 Nov 2012, ~F~M ~[~^ ~V wrote:
Dear sir:
why not call videobuf_mmap_free,when device close call soc_camera_close
in linux-2.6.x;
I haven't found any version, where this has been done. I don't think this
is needed, because videobuf mmap allocations will be freed automatically
upon the last close(). Please, dismiss your bugzilla entry.
Thanks
Guennadi
do the same in linux-3.x.x?
video capture flow:
1)open
2)set fmt
3)request buffer--__videobuf_mmap_setup--videobuf_alloc_vb(q)
4)mmap
5)enqueue, dequeue
6)unmap
7)close---soc_camera_close--?should call:videobuf_mmap_free
NOTE:
I have reviewed all the code, found:soc_camera_driver device driver coders
has no way(callback function) to call videobuf_mmap_free; it will case
memory leak.N r y b X ǧv ^ ){.n + { bj) w*jg ݢj/ z ޖ 2 ޙ )ߡ a G h j:+v w
٥
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
---
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] it913x: [BUG] fix correct endpoint size when pid filter on.
On 11/08/2012 11:30 PM, Malcolm Priestley wrote: On Thu, 2012-11-08 at 22:18 +0200, Antti Palosaari wrote: On 11/08/2012 07:48 PM, Malcolm Priestley wrote: On 07/11/12 23:43, Antti Palosaari wrote: Malcolm, Have you newer tested it with USB1.1 port? Stream is totally broken. Hi Antti Hmm, yes it is a bit choppy on dvb-usb-v2. I will have a look at it. Fedora's stock 3.6.5-1.fc17.x86_64 is even more worse - no picture at all when using vlc. Clearly visible difference is pid filter count. dvb-usb says 5 filters whilst dvb-usb-v2 says 32 pid filters. dvb_usb_v2: will use the device's hardware PID filter (table count: 32) dvb-usb: will use the device's hardware PID filter (table count: 5). I kept the count as the hardware default with dvb-usb-v2, with 5, users can still run in to trouble with Video PIDs. I have traced it to an incorrect endpoint size when the PID filter is enabled. It also affected USB 2.0 with the filter on. Bug fixed. Lets add proper tags. Happy weekend! Reported-by: Antti Palosaari cr...@iki.fi Tested-by: Antti Palosaari cr...@iki.fi Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- drivers/media/usb/dvb-usb-v2/it913x.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/it913x.c b/drivers/media/usb/dvb-usb-v2/it913x.c index 695f910..29300e3 100644 --- a/drivers/media/usb/dvb-usb-v2/it913x.c +++ b/drivers/media/usb/dvb-usb-v2/it913x.c @@ -643,7 +643,8 @@ static int it913x_frontend_attach(struct dvb_usb_adapter *adap) struct it913x_state *st = d-priv; int ret = 0; u8 adap_addr = I2C_BASE_ADDR + (adap-id 5); - u16 ep_size = adap-stream.buf_size / 4; + u16 ep_size = (adap-pid_filtering) ? TS_BUFFER_SIZE_PID / 4 : + TS_BUFFER_SIZE_MAX / 4; u8 pkt_size = 0x80; if (d-udev-speed != USB_SPEED_HIGH) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] em28xx: add support fur USB bulk transfers
Em Thu, 08 Nov 2012 20:03:47 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 30.10.2012 19:18, schrieb Frank Schäfer:
Am 30.10.2012 06:06, schrieb Mauro Carvalho Chehab:
snip
Did a git bisect. The last patch where the bug doesn't occur is this
changeset:
em28xx: add module parameter for selection of the preferred USB
transfer type
That means that this changeset broke it:
em28xx: use common urb data copying function for vbi and non-vbi devices
Ok, thanks.
That means we are VERY close...
I think this is the only change that could cause the trouble:
@@ -599,6 +491,7 @@ static inline int em28xx_urb_data_copy_vbi(struct
em28xx *dev, struct urb *urb)
len = actual_length - 4;
} else if (p[0] == 0x22 p[1] == 0x5a) {
/* start video */
+ dev-capture_type = 1;
p += 4;
len = actual_length - 4;
} else {
Could you try again with this line commented out ? (em28xx-video.c, line
494 in the patched file).
usb_debug=1 would be usefull, too.
I didn't test them with my Silvercrest webcam yet.
I re-tested 5 minutes ago with this device and it works fine.
Btw, which frame rates do you get ? ;)
Regards,
Frank
Today I had the chance to test these patches with a Hauppauge HVR-930c.
Couldn't test analog TV (not supported yet), but DVB works fine, too.
While I would love to have it, analog support for HVR-930C would likely
not happen. I don't know anyone working on it. There are two issues there:
1) it uses an unsupported micronas analog demod chipset;
2) drx-k requrires some changes to tune on analog mode.
As usual, patches for it are of course very welcome.
So patches 1 to 21 have been tested now and do at least not cause any
regressions.
I would like to drop the last two patches (22+23) of this series, because
- they are actually not related to USB bulk transfers
- patch 22 needs to be fixed for analog+vbi (will get an analog device
for testing next week)
- I'm working on further improvements/changes in this area (including
em25xx support)
So I will better come up with a separate patch series later.
OK.
Will send a v2 of this patch series soon.
Regards,
Frank
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: [omap3-isp-live] Autofocus buffer interpretation of H3A engine
Hi Laurent, Laurent Pinchart wrote on 2012-11-04: The AD5821 is similar to the AD5820, for which I have a driver that I need to clean up and post. Would you be interested in that ? Yes, you can send me the driver. Just as a note: I (probably) found an error in the current ad5398 and ad5821 driver http://lxr.free-electrons.com/source/drivers/regulator/ad5398.c It seems that the enable and disable functions are switched (at least for the ad5821). Also it's not possible to set the maximum current. I've done a patch but didn't have the time to submit it. Is this the right place for it? Even though that buffer structure is pretty simple, I'm afraid I can't provide that information as it's covered by an NDA. I have written the TI-support and here's the answer: START QUOTE After checking it seems that we unfortunately do not make the DM37x H3A documention available. Implementing Autofocus is quite complexe and the documentation is likely not going to provide enough help. A lot of experience is required to handle the mecanics and control loop aspect for the Autofocus. We have partners that do have experience with the H3A module and that might be able to help. For example MMS that mentionned is the below document: http://www.ti.com/lit/ml/swpt052/swpt052.pdf Also Leopard Imaging has experience on the H3A: https://www.leopardimaging.com/Services.html END QUOTE It's sad that they can't provide any further information, because we are not that far to get this stuff working... could try to figure it out ourselves. Looking at the FCam project, I've found http://vcs.maemo.org/svn/fcam/fcam- dev/tags/1.1.0/src/N900/V4L2Sensor.cpp Does that help figuring out what the buffer contains ? That helps a lot! Thank you. I found also a little info here: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg18438.html I haven't started, and it's currently not on my to-do list I'm afraid. That's too bad, as your help is always appreciated. Have you already seen my patch for the rotation in your omap3-isp-live program? I have seen also another little issue, if you are interested (snapshot_init should be after aewb as the output format changes during snapshot-init). I am now off for 3 weeks (annual refresher course in the Swiss armed forces). Regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 dma-buf support test with UVC + i915 test application
Em Thu, 08 Nov 2012 19:34:14 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: On Thursday 08 November 2012 19:14:18 Laurent Pinchart wrote: Hi Mauro, Here's the application I've used to test V4L2 dma-buf support with a UVC webcam and an Intel GPU supported by the i915 driver. The kernel code is available in my git tree at git://linuxtv.org/pinchartl/media.git devel/dma-buf-v10 (http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/devel/v4l2- clock) Don't forget to enable dma-buf and UVC support when compiling the kernel. The userspace code is based on the v4l2-drm-example application written by Tomasz (the original code is available at git://git.infradead.org/users/kmpark/public-apps). I need to clean up my modifications to push them back to the repository, in the meantime the code is attached to this e-mail. To compile the application, just run make with the KDIR variable set to the path to your Linux kernel tree with the dma-buf patches applied. Don't forget to make headers_install in the kernel tree as the Makefile will look for headers in $KDIR/usr. You will need a recent version of libdrm with plane support available. 2.4.39 should do. The following command line will capture VGA YUYV data from the webcam and display it on the screen. You need to run it in a console as root without the X server running. ./dmabuf-sharing -M i915 -o 7:3:1600x900 -i /dev/video0 -S 640,480 -f YUYV -F YUYV -s 640,480@0,0 -t 640,480@0,0 -b 2 I forgot to mention that the -o parameter takes the connector ID, CRTC ID and mode as parameters. The mode is easy to find, but the connector and CRTC IDs are a bit more tricky. You can run the modetest application (part of libdrm but not installed by most distributions, so a manual compilation is needed) to dump all CRTC, encoder and connector information to the console. Pick the connector associated with your display, and the CRTC associated with the encoder associated with that connector. Got modetest running, but I didn't figure out what of the values below should be used for the -o parameter: trying to load module i915...success. Encoders: id crtctypepossible crtcs possible clones 6 3 LVDS0x0003 0x0001 13 0 DAC 0x0003 0x0002 15 0 TVDAC 0x0003 0x0004 Connectors: id encoder status typesize (mm) modes encoders 5 6 connected LVDS290x180 1 6 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 1280x800 60 1280 1328 1360 1448 800 803 809 823 flags: nhsync, nvsync; type: preferred, driver props: 1 EDID: flags: immutable blob blobs: value: 000006af2414 01110103801d12780a87f594574f8c27 2750540001010101010101010101 010101010101ee1b00a8502017303020 360022b41019ee1b00a850201730 3020360022b410fe0044 5739303980423145573100fe 0001010a20200022 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 7 scaling mode: flags: enum enums: None=0 Full=1 Center=2 Full aspect=3 value: 3 12 0 disconnectedVGA 0x0 0 13 14 0 disconnecteds-video 0x0 0 15 CRTCs: id fb pos size 3 9 (0,0) (0x0) 1280x800 60 1280 1328 1360 1448 800 803 809 823 flags: nhsync, nvsync; type: preferred, driver props: 4 0 (0,0) (0x0) 0 0 0 0 0 0 0 0 0 flags: ; type: props: Planes: id crtcfb CRTC x,yx,y gamma size Frame buffers: id sizepitch Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 dma-buf support test with UVC + i915 test application
Em Fri, 9 Nov 2012 17:37:42 +0100 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Thu, 08 Nov 2012 19:34:14 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: On Thursday 08 November 2012 19:14:18 Laurent Pinchart wrote: Hi Mauro, Here's the application I've used to test V4L2 dma-buf support with a UVC webcam and an Intel GPU supported by the i915 driver. The kernel code is available in my git tree at git://linuxtv.org/pinchartl/media.git devel/dma-buf-v10 (http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/devel/v4l2- clock) Don't forget to enable dma-buf and UVC support when compiling the kernel. The userspace code is based on the v4l2-drm-example application written by Tomasz (the original code is available at git://git.infradead.org/users/kmpark/public-apps). I need to clean up my modifications to push them back to the repository, in the meantime the code is attached to this e-mail. To compile the application, just run make with the KDIR variable set to the path to your Linux kernel tree with the dma-buf patches applied. Don't forget to make headers_install in the kernel tree as the Makefile will look for headers in $KDIR/usr. You will need a recent version of libdrm with plane support available. 2.4.39 should do. The following command line will capture VGA YUYV data from the webcam and display it on the screen. You need to run it in a console as root without the X server running. ./dmabuf-sharing -M i915 -o 7:3:1600x900 -i /dev/video0 -S 640,480 -f YUYV -F YUYV -s 640,480@0,0 -t 640,480@0,0 -b 2 I forgot to mention that the -o parameter takes the connector ID, CRTC ID and mode as parameters. The mode is easy to find, but the connector and CRTC IDs are a bit more tricky. You can run the modetest application (part of libdrm but not installed by most distributions, so a manual compilation is needed) to dump all CRTC, encoder and connector information to the console. Pick the connector associated with your display, and the CRTC associated with the encoder associated with that connector. Got modetest running, but I didn't figure out what of the values below should be used for the -o parameter: trying to load module i915...success. Encoders: idcrtctypepossible crtcs possible clones 6 3 LVDS0x0003 0x0001 130 DAC 0x0003 0x0002 150 TVDAC 0x0003 0x0004 Connectors: idencoder status typesize (mm) modes encoders 5 6 connected LVDS290x180 1 6 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 1280x800 60 1280 1328 1360 1448 800 803 809 823 flags: nhsync, nvsync; type: preferred, driver props: 1 EDID: flags: immutable blob blobs: value: 000006af2414 01110103801d12780a87f594574f8c27 2750540001010101010101010101 010101010101ee1b00a8502017303020 360022b41019ee1b00a850201730 3020360022b410fe0044 5739303980423145573100fe 0001010a20200022 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 7 scaling mode: flags: enum enums: None=0 Full=1 Center=2 Full aspect=3 value: 3 120 disconnectedVGA 0x0 0 13 140 disconnecteds-video 0x0 0 15 CRTCs: idfb pos size 3 9 (0,0) (0x0) 1280x800 60 1280 1328 1360 1448 800 803 809 823 flags: nhsync, nvsync; type: preferred, driver props: 4 0 (0,0) (0x0) 0 0 0 0 0 0 0 0 0 flags: ; type: props: Planes: idcrtcfb CRTC x,yx,y gamma size Frame buffers: idsizepitch FYI, this is that I'm getting there: # ./dmabuf-sharing -M i915 -o 5:3:1280x800 -i /dev/video0 -S 640,480 -f YUYV -F YUYV -s 640,480@0,0 -t 640,480@0,0 -b 2 G_FMT(start): width = 640, height = 480, 4cc = YUYV G_FMT(final): width = 640, height = 480, 4cc = YUYV size = 614400 pitch = 1280 bo 1 640x480 bpp 16 size 614400 (614400) dbuf_fd = 5 bo 2 640x480 bpp 16 size 614400 (614400) dbuf_fd = 6 buffers ready WARN(dmabuf-sharing.c:278): connector 5 is not supported ERROR(dmabuf-sharing.c:441) : failed to find valid mode Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 5/8] fbmon: add videomode helpers
Hi Steffen,
On Fri, Nov 09, 2012 at 02:55:45, Steffen Trumtrar wrote:
Hi!
On Wed, Oct 31, 2012 at 03:30:03PM +, Manjunathappa, Prakash wrote:
Hi Steffen,
On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
*fbmode)
+{
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ fbmode-pixclock = KHZ2PICOS(vm-pixelclock / 1000);
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ if (vm-hah)
+ fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm-vah)
+ fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm-interlaced)
+ fbmode-vmode |= FB_VMODE_INTERLACED;
+ if (vm-doublescan)
+ fbmode-vmode |= FB_VMODE_DOUBLE;
+
pixelclk-inverted property of the panel is not percolated fb_videomode.
Please let me know if I am missing something.
The next version is almost finished. Only thing I'm missing is this.
And I actually do not know which flag would represent an inverted pixelclock
in fb_videomode. Does anybody have any idea what I have to do here?
if (vm-pixelclk_pol)
fbmode-sync = ???
That's as far as I have come and I don't see a flag that seems right.
Is this even a valid property of fb_videomode?
Thanks for considering it, I see IMX addresses it as proprietary FB_SYNC_ flag.
FB_SYNC_CLK_INVERT: arch/arm/plat-mxc/include/mach/mx3fb.h
Thanks,
Prakash
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 21/21] em28xx: add module parameter for selection of the preferred USB transfer type
Am 08.11.2012 21:46, schrieb Devin Heitmueller: On Thu, Nov 8, 2012 at 1:37 PM, Frank Schäfer fschaefer@googlemail.com wrote: at least the Silvercrest Webcam 1.3mpix (board 71) exposes both endpoint types (0x82=isoc and 0x84=bulk). Ah, interesting. It might be worthwhile to log a warning in dmesg if the user sets the modprobe option but the board doesn't actually expose any bulk endpoints. This might help avoid questions from users (we already got one such question by somebody who believed enabling this would put the device into bulk mode even though his hardware didn't support it). Devin Well, I deliberately called the module 'prefer_bulk' (and not 'use_bulk', 'force_bulk' ...) which should imply that nothing is guaranteed. And selecting bulk transfers for a device which actually doesn not provide bulk support doesn't make sense and is clearly the users fault. Anway, I'm fine with adding a warning message and maybe I could extend the module parameter description, too. I'm going to wait for further feedback from Mauro before sending an updated version of the patch (series). Regards, Frank -- 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 00/23] em28xx: add support fur USB bulk transfers
Am 09.11.2012 17:02, schrieb Mauro Carvalho Chehab:
Em Thu, 08 Nov 2012 20:03:47 +0200
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 30.10.2012 19:18, schrieb Frank Schäfer:
Am 30.10.2012 06:06, schrieb Mauro Carvalho Chehab:
snip
Did a git bisect. The last patch where the bug doesn't occur is this
changeset:
em28xx: add module parameter for selection of the preferred USB
transfer type
That means that this changeset broke it:
em28xx: use common urb data copying function for vbi and non-vbi devices
Ok, thanks.
That means we are VERY close...
I think this is the only change that could cause the trouble:
@@ -599,6 +491,7 @@ static inline int em28xx_urb_data_copy_vbi(struct
em28xx *dev, struct urb *urb)
len = actual_length - 4;
} else if (p[0] == 0x22 p[1] == 0x5a) {
/* start video */
+ dev-capture_type = 1;
p += 4;
len = actual_length - 4;
} else {
Could you try again with this line commented out ? (em28xx-video.c, line
494 in the patched file).
usb_debug=1 would be usefull, too.
I didn't test them with my Silvercrest webcam yet.
I re-tested 5 minutes ago with this device and it works fine.
Btw, which frame rates do you get ? ;)
Regards,
Frank
Today I had the chance to test these patches with a Hauppauge HVR-930c.
Couldn't test analog TV (not supported yet), but DVB works fine, too.
While I would love to have it, analog support for HVR-930C would likely
not happen. I don't know anyone working on it. There are two issues there:
1) it uses an unsupported micronas analog demod chipset;
2) drx-k requrires some changes to tune on analog mode.
Yeah, I heard about that. :(
As usual, patches for it are of course very welcome.
I don't own this device, just borrowed it for some minutes for testing.
Apart from that, it seems I will be busy with the Laplace webcam support
for the next years... :D
Regards,
Frank
So patches 1 to 21 have been tested now and do at least not cause any
regressions.
I would like to drop the last two patches (22+23) of this series, because
- they are actually not related to USB bulk transfers
- patch 22 needs to be fixed for analog+vbi (will get an analog device
for testing next week)
- I'm working on further improvements/changes in this area (including
em25xx support)
So I will better come up with a separate patch series later.
OK.
Will send a v2 of this patch series soon.
Regards,
Frank
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 21/21] em28xx: add module parameter for selection of the preferred USB transfer type
On Fri, Nov 9, 2012 at 11:00 AM, Frank Schäfer fschaefer@googlemail.com wrote: Well, I deliberately called the module 'prefer_bulk' (and not 'use_bulk', 'force_bulk' ...) which should imply that nothing is guaranteed. And selecting bulk transfers for a device which actually doesn not provide bulk support doesn't make sense and is clearly the users fault. Anway, I'm fine with adding a warning message and maybe I could extend the module parameter description, too. I'm going to wait for further feedback from Mauro before sending an updated version of the patch (series). Yeah, none of this should hold up it being merged as-is. A patch adding the warning can be submitted after the fact. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [PATCH v7 5/8] fbmon: add videomode helpers
Hi!
On Fri, Nov 09, 2012 at 04:54:16PM +, Manjunathappa, Prakash wrote:
Hi Steffen,
On Fri, Nov 09, 2012 at 02:55:45, Steffen Trumtrar wrote:
Hi!
On Wed, Oct 31, 2012 at 03:30:03PM +, Manjunathappa, Prakash wrote:
Hi Steffen,
On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int videomode_to_fb_videomode(struct videomode *vm, struct
fb_videomode *fbmode)
+{
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ fbmode-pixclock = KHZ2PICOS(vm-pixelclock / 1000);
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ if (vm-hah)
+ fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm-vah)
+ fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm-interlaced)
+ fbmode-vmode |= FB_VMODE_INTERLACED;
+ if (vm-doublescan)
+ fbmode-vmode |= FB_VMODE_DOUBLE;
+
pixelclk-inverted property of the panel is not percolated fb_videomode.
Please let me know if I am missing something.
The next version is almost finished. Only thing I'm missing is this.
And I actually do not know which flag would represent an inverted pixelclock
in fb_videomode. Does anybody have any idea what I have to do here?
if (vm-pixelclk_pol)
fbmode-sync = ???
That's as far as I have come and I don't see a flag that seems right.
Is this even a valid property of fb_videomode?
Thanks for considering it, I see IMX addresses it as proprietary FB_SYNC_
flag.
FB_SYNC_CLK_INVERT: arch/arm/plat-mxc/include/mach/mx3fb.h
No problem. So, it seems this flag has to be set in some imx-specific
videomode_to_fb_videomode function. It is included in the
struct videomode, so that should be no problem. But it will not be
part of this series.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Nov 9 19:00:21 CET 2012 git hash:2cb654fd281e1929aa3b9f5f54f492135157a613 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] videobuf2-core: Verify planes lengths for output buffers
On Tue, Oct 16, 2012 at 8:37 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
For output buffers application provide to the kernel the number of bytes
they stored in each plane of the buffer. Verify that the value is
smaller than or equal to the plane length.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
Acked-by: Pawel Osciak pa...@osciak.com
drivers/media/v4l2-core/videobuf2-core.c | 39
++
1 files changed, 39 insertions(+), 0 deletions(-)
Changes compared to v1:
- Sanity check the data_offset value for each plane.
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 432df11..479337d 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -296,6 +296,41 @@ static int __verify_planes_array(struct vb2_buffer *vb,
const struct v4l2_buffer
}
/**
+ * __verify_length() - Verify that the bytesused value for each plane fits in
+ * the plane length and that the data offset doesn't exceed the bytesused
value.
+ */
+static int __verify_length(struct vb2_buffer *vb, const struct v4l2_buffer
*b)
+{
+ unsigned int length;
+ unsigned int plane;
+
+ if (!V4L2_TYPE_IS_OUTPUT(b-type))
+ return 0;
+
+ if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) {
+ for (plane = 0; plane vb-num_planes; ++plane) {
+ length = (b-memory == V4L2_MEMORY_USERPTR)
+ ? b-m.planes[plane].length
+ : vb-v4l2_planes[plane].length;
+
+ if (b-m.planes[plane].bytesused length)
+ return -EINVAL;
+ if (b-m.planes[plane].data_offset =
+ b-m.planes[plane].bytesused)
+ return -EINVAL;
+ }
+ } else {
+ length = (b-memory == V4L2_MEMORY_USERPTR)
+ ? b-length : vb-v4l2_planes[0].length;
+
+ if (b-bytesused length)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/**
* __buffer_in_use() - return true if the buffer is in use and
* the queue cannot be freed (by the means of REQBUFS(0)) call
*/
@@ -975,6 +1010,10 @@ static int __buf_prepare(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
struct vb2_queue *q = vb-vb2_queue;
int ret;
+ ret = __verify_length(vb, b);
+ if (ret 0)
+ return ret;
+
switch (q-memory) {
case V4L2_MEMORY_MMAP:
ret = __qbuf_mmap(vb, b);
--
Regards,
Laurent Pinchart
--
Best regards,
Pawel Osciak
--
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
