Re: linux-next: Tree for July 12 (v4l2-ioctl.c)
On Tue July 17 2012 04:25:35 Ming Lei wrote: On Thu, Jul 12, 2012 at 11:49 PM, Randy Dunlap rdun...@xenotime.net wrote: On 07/11/2012 11:03 PM, Stephen Rothwell wrote: Hi all, Changes since 20120710: on i386 and/or x86_64, drivers/media/video/v4l2-ioctl.c has too many errors to be listed here. This is the beginning few lines of the errors: I see the errors on ARM too. A fix can be found here: http://patchwork.linuxtv.org/patch/13336/ 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
Re: linux-next: Tree for July 12 (v4l2-ioctl.c)
Hi all, On Tue, 17 Jul 2012 08:48:37 +0200 Hans Verkuil hverk...@xs4all.nl wrote: On Tue July 17 2012 04:25:35 Ming Lei wrote: On Thu, Jul 12, 2012 at 11:49 PM, Randy Dunlap rdun...@xenotime.net wrote: on i386 and/or x86_64, drivers/media/video/v4l2-ioctl.c has too many errors to be listed here. This is the beginning few lines of the errors: I see the errors on ARM too. A fix can be found here: http://patchwork.linuxtv.org/patch/13336/ And I have been applying that fix to linux-next since next-20120713 - though Mauro has not applied it to the v4l-dvb tree yet ... -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpLNLxOlwHQE.pgp Description: PGP signature
Re: libv4l2: error dequeuing buf: Resource temporarily unavailable
ffmpeg -t 30 -f video4linux2 -s vga -r 25 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg works, right? If PAL, you may add -tvstd pal option. Am Montag, den 16.07.2012, 10:50 -0700 schrieb Charlie X. Liu: Your driver load may not be quite right or got some conflicts. According to: http://www.kernel.org/doc/Documentation/video4linux/CARDLIST.saa7134, the Terratec Cinergy 400 TV should be card=8. Have you tried: restart, modprobe -r saa7134, modprobe saa7134 card=8, dmesg | grep saa7134, and checked if the Terratec Cinergy 400 TV showed up correctly? If right, it should be Ok: ffmpeg -f video4linux2 -i /dev/video0 out.mpg ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg ffmpeg -t 60 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-60sec.avi ..., etc. Thanks a lot for your help. The card is loaded OK. I tried it with the card=8 parameter in a newly created file /etc/modprobe.d/saa7134.conf. It seems to be loaded properly: dmesg | grep saa7134 [ 24.978050] saa7134[0]: found at :04:01.0, rev: 1, irq: 17, latency: 32, mmio: 0xfe50 [ 24.978058] saa7134[0]: subsystem: 153b:1142, board: Terratec Cinergy 400 TV [card=8,insmod option] [ 24.978073] saa7134[0]: board init: gpio is 5 [ 25.053979] input: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0/input6 [ 25.054018] rc0: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0 [ 25.187509] saa7134[0]: i2c eeprom 00: 3b 15 42 11 ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187517] saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187523] saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187529] saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187535] saa7134[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187541] saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187547] saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187553] saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187559] saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187566] saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187571] saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187577] saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187583] saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187589] saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187595] saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187601] saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.716134] saa7134[0]: registered device video0 [v4l2] [ 25.716157] saa7134[0]: registered device vbi0 [ 25.998624] saa7134 ALSA driver for DMA sound loaded [ 25.998650] saa7134[0]/alsa: saa7134[0] at 0xfe50 irq 17 registered as card -1 ffmpeg -f video4linux2 -i /dev/video0 test.mpg gives still the error mentioned in the subject, ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg gives an I/O error while setting the framerate ffmpeg version 0.10.4 Copyright (c) 2000-2012 the FFmpeg developers built on Jun 13 2012 09:51:06 with gcc 4.7.0 20120507 (Red Hat 4.7.0-5) configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-gnutls --enable-libass --enable-libcdio --enable-libcelt --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopenjpeg --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect libavutil 51. 35.100 / 51. 35.100 libavcodec 53. 61.100 / 53. 61.100 libavformat53. 32.100 / 53. 32.100 libavdevice53. 4.100 / 53. 4.100 libavfilter 2. 61.100 / 2. 61.100 libswscale 2. 1.100 / 2. 1.100 libswresample 0. 6.100 / 0. 6.100 libpostproc52. 0.100 / 52. 0.100 Please use -b:a or -b:v, -b is ambiguous [video4linux2,v4l2 @
TechnoTrend Budget CI stutters and often fails at tuning encrypted channel.
Hi list, I have been using a tt1500, a saa7146 PCI DVB-T tuner for well over a year now. Running gentoo 64bit tracking the ~amd64 branch (that only get bi-monthly upgraded) I've been always more or less up to date. This card however has never properly worked. I've been running vdr 1.6.* since that is what's stably in gentoo. Whilst writing this down I realized I still have to test me-tv to double check my findings. Some background info. Here in NL we have 4 FTA channels and about 20 conax encrypted channels that the CAM in the CI module decrypts. I have two smartcards, of which one is only in active use at the moment. When changing channels between the FTA channels, the first 'bug' occurs. Somtimes (not predictably or anything, about 50% of the channel changes) sound stutters the first few seconds, upto 30 seconds sometimes. It sounds almost if the sound is being fed through some sort of PWM, that slowly catches up. So first you hear 1 second of audio, 3 seconds of nothing, then 1 second of audio again, then 2 seconds of nothing etc. This audio delay is random. E.g. sometimes it stutters for about 30 seconds while it has a hard time to catch up, other times the audio needs only 2 or 3 seconds to catch up. Very occasionally it instantly works right. The stuttering appears to be worse on encrypted channels. Encrypted channels has the additional annoyance, that quote often, an entire channel is not available. That is, every channel in its bouqet. Simply waiting on that channel for about a minute or two, mysteriously brings the unavailable channel up. Allthough it 'feels' like changing channel helps this fix faster, it's just a placebo effect if you ask me ;) I cannot safely say that the same skipping happens to the video, I have not noticed it really. I have checked signal strength etc and though the strength is only at 55%, the SNR is at 99% quite stable and the BER (unrecoverable errors? are at 0). If for some reason there is interferance, bad whether, blocked antenna, then the BER goes up followed by distorted imagery and with really bad signal bad audio as well (humans are more sensitive to bad audio iirc). I'm not sure what to profile, where to enable debugging, what logs to check or what to do to help 'fix' this. lspci output: 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH DVB T-1500 Flags: bus master, medium devsel, latency 32, IRQ 18 Memory at f0162000 (32-bit, non-prefetchable) [size=512] Kernel drive in use: budget_ci dvb /proc/interrupts 18:499107651 IO-APIC-fasteoi saa7146 (0) Tuner: tda10046h dvb-t, firmware revision 20 Thank you for your time, oliver -- 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 8/9] soc-camera: Add and use soc_camera_power_[on|off]() helper functions
Hi Laurent,
On 07/17/2012 04:24 AM, Laurent Pinchart wrote:
Hi David,
Thanks for the review.
You're welcome.
On Monday 16 July 2012 02:17:43 David Cohen wrote:
On 07/05/2012 11:38 PM, Laurent Pinchart wrote:
Instead of forcing all soc-camera drivers to go through the mid-layer to
handle power management, create soc_camera_power_[on|off]() functions
that can be called from the subdev .s_power() operation to manage
regulators and platform-specific power handling. This allows non
soc-camera hosts to use soc-camera-aware clients.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c |9 +++
drivers/media/video/mt9m001.c |9 +++
drivers/media/video/mt9m111.c | 52 +-
drivers/media/video/mt9t031.c | 11 +++-
drivers/media/video/mt9t112.c |9 +++
drivers/media/video/mt9v022.c |9 +++
drivers/media/video/ov2640.c |9 +++
drivers/media/video/ov5642.c | 10 +++-
drivers/media/video/ov6650.c |9 +++
drivers/media/video/ov772x.c |9 +++
drivers/media/video/ov9640.c | 10 +++-
drivers/media/video/ov9740.c | 15 +-
drivers/media/video/rj54n1cb0c.c |9 +++
drivers/media/video/soc_camera.c | 83
drivers/media/video/soc_camera_platform.c | 11 -
drivers/media/video/tw9910.c |9 +++
include/media/soc_camera.h| 10
17 files changed, 225 insertions(+), 58 deletions(-)
[snip]
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 3eb07c2..effd0f1 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -786,16 +786,29 @@ static int ov9740_g_chip_ident(struct v4l2_subdev
*sd,
static int ov9740_s_power(struct v4l2_subdev *sd, int on)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
struct ov9740_priv *priv = to_ov9740(sd);
+ int ret;
- if (!priv-current_enable)
+ if (on) {
+ ret = soc_camera_power_on(client-dev, icl);
+ if (ret 0)
+ return ret;
+ }
+
+ if (!priv-current_enable) {
+ if (!on)
+ soc_camera_power_off(client-dev, icl);
After your changes, this function has 3 if's (one nested) where all of
them checks on variable due to you need to mix on and
priv-current_enable checks. However, code's traceability is not so
trivial.
How about if you nest priv-current_enable into last if and keep
only that one?
See an incomplete code below:
return 0;
+ }
if (on) {
soc_camera_power_on();
if (!priv-current_enable)
return;
ov9740_s_fmt(sd, priv-current_mf);
ov9740_s_stream(sd, priv-current_enable);
} else {
ov9740_s_stream(sd, 0);
Execute ov9740_s_stream() conditionally:
if (priv-current_enable) {
ov9740_s_stream();
priv-current_enable = true;
}
+ soc_camera_power_off(client-dev, icl);
priv-current_enable = true;
priv-current_enable is set to false when ov9740_s_stream(0) is called
then this function sets it back to true afterwards. So, in case you want
to have no functional change, it seems to me you should call
soc_camera_power_off() after that variable has its original value set
back.
In this case, even if you don't like my suggestion, you still need to
swap those 2 lines above. :)
What do you think of
Sounds good to me :)
Br,
David Cohen
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 3eb07c2..10c0ba9 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -786,17 +786,27 @@ static int ov9740_g_chip_ident(struct v4l2_subdev *sd,
static int ov9740_s_power(struct v4l2_subdev *sd, int on)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
struct ov9740_priv *priv = to_ov9740(sd);
-
- if (!priv-current_enable)
- return 0;
+ int ret;
if (on) {
- ov9740_s_fmt(sd, priv-current_mf);
- ov9740_s_stream(sd, priv-current_enable);
+ ret = soc_camera_power_on(client-dev, icl);
+ if (ret 0)
+ return ret;
+
+ if (priv-current_enable) {
+ ov9740_s_fmt(sd, priv-current_mf);
+ ov9740_s_stream(sd, 1);
+ }
} else {
- ov9740_s_stream(sd, 0);
- priv-current_enable = true;
+ if (priv-current_enable) {
+
RE: [PATCH] [media] davinci: vpfe: Add documentation
Hi Laurent,
Thank you for your comments.
On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
Hi Manjunath,
Thanks for the patch.
On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
Documentation/video4linux/davinci-vpfe-mc.txt | 263
+ 1 files changed, 263 insertions(+), 0
deletions(-)
create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
b/Documentation/video4linux/davinci-vpfe-mc.txt new file mode 100644
index 000..968194f
--- /dev/null
+++ b/Documentation/video4linux/davinci-vpfe-mc.txt
@@ -0,0 +1,263 @@
+Davinci Video processing Front End (VPFE) driver
+
+Copyright (C) 2012 Texas Instruments Inc
+
+Contacts: Manjunath Hadli manjunath.ha...@ti.com
+
+Introduction
+
+
+This file documents the Texas Instruments Davinci Video processing Front
End
+(VPFE) driver located under drivers/media/video/davinci. The original
driver
+exists for Davinci VPFE, which is now being changed to Media Controller
+Framework.
+
+Currently the driver has been successfully used on the following version of
Davinci:
+
+ DM365/DM368
Does the driver still support the DM644x ?
Yes. The driver supports DM6446. We will add the Dm6446x patches on these.
+The driver implements V4L2, Media controller and v4l2_subdev interfaces.
+Sensor, lens and flash drivers using the v4l2_subdev interface in the
kernel
+are supported.
+
+
+Split to subdevs
+
+
+The Davinic VPFE is split into V4L2 subdevs, each of the blocks inside the
s/Davinic/Davinci/
OK. Thanks.
VPFE
+having one subdev to represent it. Each of the subdevs provide a V4L2
subdev
+interface to userspace.
+
+ DAVINCI CCDC
+ DAVINCI PREVIEWER
+ DAVINCI RESIZER
the DM36x VPFE documentation doesn't split the hardware in CCDC, PREVIEWER
and
RESIZER modules, but in ISIF, IPIPEIF and IPIPE. Why don't you use those
names
? It looks like you're introducing an abstraction layer on top of the
existing
driver. Why is that needed, why don't you just port the driver to the MC API
instead ?
Please see below my comment for enumerating internal modules.
+ DAVINCI AEW
+ DAVINCI AF
+
+Each possible link in the VPFE is modeled by a link in the Media controller
+interface. For an example program see [1].
+
+
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports standard V4L2
+IOCTLs and controls where possible and practical. Much of the functions
provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+ Sets/Gets the parameters required by the previewer module
+Parameter:
+ /**
+* struct prev_module_param- structure to configure preview modules
+* @version: Version of the preview module
Who is responsible for filling this field, the application or the driver ?
The application is responsible for filling this info. He would enumerate the
capabilities first and set them using S_PARAM/G_PARAM.
+* @len: Length of the module config structure
+* @module_id: Module id
+* @param: pointer to module config parameter.
What is module_id for ? What does param point to ?
There are a lot of tiny modules in the previewer/resizer which are enumerated
as individual modules. The param points to the parameter set that the module
expects to be set.
+*/
+ struct prev_module_param {
+ char version[IMP_MAX_NAME_SIZE];
Is there a need to express the version as a string instead of an integer ?
It could be integer. It is generally a fixed point num, and easy to read it
as a string than an integer. Can I keep it as a string?
+ unsigned short len;
+ unsigned short module_id;
+ void *param;
+ };
+
+2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
+Description:
+ Sets/Gets the configuration required by the previewer channel
+Parameter:
+ /**
+* struct prev_channel_config - structure for configuring the previewer
channel
+* @len: Length of the user configuration
+* @config: pointer to either single shot config or continuous
+*/
+ struct prev_channel_config {
+ unsigned short len;
+ void *config;
+ };
What's the difference between parameters and configuration ? What does config
point to ?
Config is setting which is
Re: TechnoTrend Budget CI stutters and often fails at tuning encrypted channel.
On 17-07-12 10:30, Oliver Schinagl wrote: Hi list, I have been using a tt1500, a saa7146 PCI DVB-T tuner for well over a year now. Running gentoo 64bit tracking the ~amd64 branch (that only get bi-monthly upgraded) I've been always more or less up to date. This card however has never properly worked. I've been running vdr 1.6.* since that is what's stably in gentoo. Whilst writing this down I realized I still have to test me-tv to double check my findings. Some background info. Here in NL we have 4 FTA channels and about 20 conax encrypted channels that the CAM in the CI module decrypts. I have two smartcards, of which one is only in active use at the moment. When changing channels between the FTA channels, the first 'bug' occurs. Somtimes (not predictably or anything, about 50% of the channel changes) sound stutters the first few seconds, upto 30 seconds sometimes. It sounds almost if the sound is being fed through some sort of PWM, that slowly catches up. So first you hear 1 second of audio, 3 seconds of nothing, then 1 second of audio again, then 2 seconds of nothing etc. This audio delay is random. E.g. sometimes it stutters for about 30 seconds while it has a hard time to catch up, other times the audio needs only 2 or 3 seconds to catch up. Very occasionally it instantly works right. The stuttering appears to be worse on encrypted channels. Encrypted channels has the additional annoyance, that quote often, an entire channel is not available. That is, every channel in its bouqet. Simply waiting on that channel for about a minute or two, mysteriously brings the unavailable channel up. Allthough it 'feels' like changing channel helps this fix faster, it's just a placebo effect if you ask me ;) I cannot safely say that the same skipping happens to the video, I have not noticed it really. I have checked signal strength etc and though the strength is only at 55%, the SNR is at 99% quite stable and the BER (unrecoverable errors? are at 0). If for some reason there is interferance, bad whether, blocked antenna, then the BER goes up followed by distorted imagery and with really bad signal bad audio as well (humans are more sensitive to bad audio iirc). I'm not sure what to profile, where to enable debugging, what logs to check or what to do to help 'fix' this. lspci output: 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH DVB T-1500 Flags: bus master, medium devsel, latency 32, IRQ 18 Memory at f0162000 (32-bit, non-prefetchable) [size=512] Kernel drive in use: budget_ci dvb /proc/interrupts 18:499107651 IO-APIC-fasteoi saa7146 (0) Tuner: tda10046h dvb-t, firmware revision 20 Thank you for your time, oliver P.S. I forgot to mention, that once tuned to a channel, I can receive (and decode) it fine for many hours. I think the longest I had one channel up was about 8 hours or so without issue. A dvb-t radio channel (thus not dab) i had up for even longer, so once it goes, it goes on happily forever! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Manjunath, Thank you for the patch. Just some nitpicking, please see below. On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 171 + include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -356,6 +356,9 @@ listitemparaIf the pixel components are DPCM-compressed, a mention of the DPCM compression and the number of bits per compressed pixel component./para /listitem + listitemparaIf the pixel components are ALAW-compressed, a mention of the + ALAW compression and the number of bits per compressed pixel component./para + /listitem I would group ALAW and DPCM compression, as they're mutally exclusive. Something like transferred on the same number of bits. Common values are 8, 10 and 12. /para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of - the DPCM compression and the number of bits per compressed pixel - component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -572,6 +575,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry +
Re: [PATCH v4 2/2] v4l2: add new pixel formats supported on dm365
Hi Manjunath,
Thank you for the patch.
A couple of comments below.
On Friday 30 March 2012 10:09:14 Hadli, Manjunath wrote:
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |
2 +
include/linux/videodev2.h |8 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode
100644
index 000..9b5c80d
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ refentry
+ refmeta
+ refentrytitle
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ /refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname id=V4L2-PIX-FMT-SRGGB10ALAW8
+ constantV4L2_PIX_FMT_SRGGB10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGRBG10ALAW8
+ constantV4L2_PIX_FMT_SGRBG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGBRG10ALAW8
+ constantV4L2_PIX_FMT_SGBRG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SBGGR10ALAW8
+ constantV4L2_PIX_FMT_SBGGR10ALAW8/constant
+ /refname
+ refpurpose10-bit Bayer formats compressed to 8 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraThe following four pixel formats are raw sRGB / Bayer
+ formats with 10 bits per colour compressed to 8 bits each,
+ using the A-LAW algorithm. Each colour component consumes 8
+ bits of memory. In other respects this format is similar to
+ xref linkend=V4L2-PIX-FMT-SRGGB8./xref/para
+ /refsect1
+ /refentry
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644
index 000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+ refentry id=V4L2-PIX-FMT-UV8
+ refmeta
+ refentrytitleV4L2_PIX_FMT_UV8 ('UV8')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_UV8/constant/refname
+ refpurposeUV plane interleaved/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraIn this format there is no Y plane, Only CbCr plane. ie
+ (UV interleaved)/para
+ example
+ title
+ constantV4L2_PIX_FMT_UV8/constant
+pixel image
+ /title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript20/subscript/entry
+ entryCrsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCrsubscript21/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryCbsubscript30/subscript/entry
+ entryCrsubscript30/subscript/entry
+ entryCbsubscript31/subscript/entry
+
Re: [PATCH v2 7/9] soc-camera: Continue the power off sequence if one of the steps fails
Hi Laurent,
On 07/17/2012 02:45 AM, Laurent Pinchart wrote:
Hi David,
Thank you for the review.
You're welcome.
On Monday 16 July 2012 01:24:37 David Cohen wrote:
On 07/05/2012 11:38 PM, Laurent Pinchart wrote:
Powering off a device is a best effort task: failure to execute one of
the steps should not prevent the next steps to be executed. For
instance, an I2C communication error when putting the chip in stand-by
mode should not prevent the more agressive next step of turning the
chip's power supply off.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c index 55b981f..bbd518f 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -89,18 +89,15 @@ static int soc_camera_power_off(struct
soc_camera_device *icd,
struct soc_camera_link *icl)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- int ret = v4l2_subdev_call(sd, core, s_power, 0);
+ int ret;
- if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV)
- return ret;
+ v4l2_subdev_call(sd, core, s_power, 0);
Fair enough. I agree we should not prevent power off because of failure
in this step. But IMO we should not silently bypass it too. How about
an error message?
I'll add that.
if (icl-power) {
ret = icl-power(icd-control, 0);
- if (ret 0) {
+ if (ret 0)
dev_err(icd-pdev,
Platform failed to power-off the camera.\n);
- return ret;
- }
}
ret = regulator_bulk_disable(icl-num_regulators,
One more comment. Should this function's return value being based fully
on last action? If any earlier error happened but this last step is
fine, IMO we should not return 0.
Good point. What about this (on top of the current patch) ?
That sounds nice to me :)
Regards,
David Cohen
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index bbd518f..7bf21da 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -89,21 +89,30 @@ static int soc_camera_power_off(struct soc_camera_device
*icd,
struct soc_camera_link *icl)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- int ret;
+ int ret = 0;
+ int err;
- v4l2_subdev_call(sd, core, s_power, 0);
+ err = v4l2_subdev_call(sd, core, s_power, 0);
+ if (err 0 err != -ENOIOCTLCMD err != -ENODEV) {
+ dev_err(icd-pdev, Subdev failed to power-off the camera.\n);
+ ret = err;
+ }
if (icl-power) {
- ret = icl-power(icd-control, 0);
- if (ret 0)
+ err = icl-power(icd-control, 0);
+ if (err 0) {
dev_err(icd-pdev,
Platform failed to power-off the camera.\n);
+ ret = ret ? : err;
+ }
}
- ret = regulator_bulk_disable(icl-num_regulators,
+ err = regulator_bulk_disable(icl-num_regulators,
icl-regulators);
- if (ret 0)
+ if (err 0) {
dev_err(icd-pdev, Cannot disable regulators\n);
+ ret = ret ? : err;
+ }
return ret;
}
--
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] Documentation: DocBook DRM framework documentation
On Friday 13 July 2012 02:00:23 Laurent Pinchart wrote: Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/drm.tmpl | 2835 - 1 files changed, 2226 insertions(+), 609 deletions(-) Hi everybody, Here's the DRM kernel framework documentation previously posted to the dri-devel mailing list. The documentation has been reworked, converted to DocBook and merged with the existing DocBook DRM documentation stub. The result doesn't cover the whole DRM API but should hopefully be good enough for a start. I've done my best to follow a natural flow starting at initialization and covering the major DRM internal topics. As I'm not a native English speaker I'm not totally happy with the result, so if anyone wants to edit the text please feel free to do so. Review will as usual be appreciated, and acks will be even more welcome (I've been working on this document for longer than I feel comfortable with). Just for information, a compiled copy of the DRM documentation with this patch applied can be found at http://www.ideasonboard.org/media/drm/. That might be easier to review than the patch. -- 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: dma-buf/fbdev: one-to-many support
The main issue is that fbdev has been designed with the implicit assumption that an fbdev driver will always own the graphics memory it uses. All components in the stack, from drivers to applications, have been designed around that assumption. We could of course fix this, revamp the fbdev API and turn it into a modern graphics API, but I really wonder whether it would be worth it. DRM has been getting quite a lot of attention lately, especially from embedded developers and vendors, and the trend seems to me like the (Linux) world will gradually move from fbdev to DRM. Please feel free to disagree :-) I would disagree on the main issue bit. All the graphics cards have their own formats and cache management rules. Simply sharing a buffer doesn't work - which is why all of the extra gloop will be needed. Alan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Laurent, Thanks for the review. On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: Hi Manjunath, Thank you for the patch. Just some nitpicking, please see below. On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 171 + include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -356,6 +356,9 @@ listitemparaIf the pixel components are DPCM-compressed, a mention of the DPCM compression and the number of bits per compressed pixel component./para /listitem + listitemparaIf the pixel components are ALAW-compressed, a mention of the + ALAW compression and the number of bits per compressed pixel component./para + /listitem I would group ALAW and DPCM compression, as they're mutally exclusive. Something like transferred on the same number of bits. Common values are 8, 10 and 12. /para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of - the DPCM compression and the number of bits per compressed pixel - component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem Ok. listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -572,6 +575,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry +
RE: [PATCH v4 2/2] v4l2: add new pixel formats supported on dm365
Hi Laurent,
On Tue, Jul 17, 2012 at 16:29:44, Laurent Pinchart wrote:
Hi Manjunath,
Thank you for the patch.
A couple of comments below.
On Friday 30 March 2012 10:09:14 Hadli, Manjunath wrote:
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |
2 +
include/linux/videodev2.h |8 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode
100644
index 000..9b5c80d
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ refentry
+ refmeta
+ refentrytitle
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ /refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname id=V4L2-PIX-FMT-SRGGB10ALAW8
+ constantV4L2_PIX_FMT_SRGGB10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGRBG10ALAW8
+ constantV4L2_PIX_FMT_SGRBG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGBRG10ALAW8
+ constantV4L2_PIX_FMT_SGBRG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SBGGR10ALAW8
+ constantV4L2_PIX_FMT_SBGGR10ALAW8/constant
+ /refname
+ refpurpose10-bit Bayer formats compressed to 8 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraThe following four pixel formats are raw sRGB / Bayer
+ formats with 10 bits per colour compressed to 8 bits each,
+ using the A-LAW algorithm. Each colour component consumes 8
+ bits of memory. In other respects this format is similar to
+ xref linkend=V4L2-PIX-FMT-SRGGB8./xref/para
+ /refsect1
+ /refentry
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644
index 000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+ refentry id=V4L2-PIX-FMT-UV8
+ refmeta
+ refentrytitleV4L2_PIX_FMT_UV8 ('UV8')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_UV8/constant/refname
+ refpurposeUV plane interleaved/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraIn this format there is no Y plane, Only CbCr plane. ie
+ (UV interleaved)/para
+ example
+ title
+ constantV4L2_PIX_FMT_UV8/constant
+ pixel image
+ /title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript20/subscript/entry
+ entryCrsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCrsubscript21/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryCbsubscript30/subscript/entry
+ entryCrsubscript30/subscript/entry
+ entryCbsubscript31/subscript/entry
+
Re: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Manjunath, On Tuesday 17 July 2012 11:41:11 Hadli, Manjunath wrote: On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 171 include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml [snip] @@ -965,6 +1036,56 @@ entryysubscript1/subscript/entry entryysubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-UV8-1X8 That's a weird one. Just out of curiosity, what's the point of transferring chroma information without luma ? DM365 supports this format. Right, but what is it used for ? [snip] @@ -2415,6 +2536,56 @@ entryusubscript1/subscript/entry entryusubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-YDYC8-1X16 What is this beast ? We at least need a textual description, as I have no idea what the format corresponds to. This was discussed earlier over here http://patchwork.linuxtv.org/patch/8843/ My bad, I should have remembered that. Please add a textual description of the format, it's not clear from the name what D and C are. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] uvcvideo: Support super speed endpoints
Compute the maximum number of bytes per interval using the burst and
multiplier values for super speed endpoints.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_video.c | 28 +++-
1 files changed, 23 insertions(+), 5 deletions(-)
Hi Tony,
Could you please test the following patch ?
I wonder whether it would make sense to move the uvc_endpoint_max_bpi()
function to the USB core.
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index 7ac4347..0d2e5c2 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -1439,6 +1439,26 @@ static void uvc_uninit_video(struct uvc_streaming
*stream, int free_buffers)
}
/*
+ * Compute the maximum number of bytes per interval for an endpoint.
+ */
+static unsigned int uvc_endpoint_max_bpi(struct usb_device *dev,
+struct usb_host_endpoint *ep)
+{
+ u16 psize;
+
+ switch (dev-speed) {
+ case USB_SPEED_SUPER:
+ return ep-ss_ep_comp.wBytesPerInterval;
+ case USB_SPEED_HIGH:
+ psize = usb_endpoint_maxp(ep-desc);
+ return (psize 0x07ff) * (1 + ((psize 11) 3));
+ default:
+ psize = usb_endpoint_maxp(ep-desc);
+ return psize 0x07ff;
+ }
+}
+
+/*
* Initialize isochronous URBs and allocate transfer buffers. The packet size
* is given by the endpoint.
*/
@@ -1450,8 +1470,7 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream,
u16 psize;
u32 size;
- psize = le16_to_cpu(ep-desc.wMaxPacketSize);
- psize = (psize 0x07ff) * (1 + ((psize 11) 3));
+ psize = uvc_endpoint_max_bpi(stream-dev-udev, ep);
size = stream-ctrl.dwMaxVideoFrameSize;
npackets = uvc_alloc_urb_buffers(stream, size, psize, gfp_flags);
@@ -1506,7 +1525,7 @@ static int uvc_init_video_bulk(struct uvc_streaming
*stream,
u16 psize;
u32 size;
- psize = le16_to_cpu(ep-desc.wMaxPacketSize) 0x07ff;
+ psize = usb_endpoint_maxp(ep-desc) 0x7ff;
size = stream-ctrl.dwMaxPayloadTransferSize;
stream-bulk.max_payload_size = size;
@@ -1595,8 +1614,7 @@ static int uvc_init_video(struct uvc_streaming *stream,
gfp_t gfp_flags)
continue;
/* Check if the bandwidth is high enough. */
- psize = le16_to_cpu(ep-desc.wMaxPacketSize);
- psize = (psize 0x07ff) * (1 + ((psize 11) 3));
+ psize = uvc_endpoint_max_bpi(stream-dev-udev, ep);
if (psize = bandwidth psize = best_psize) {
altsetting = alts-desc.bAlternateSetting;
best_psize = psize;
--
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: [GIT PULL] Davinci VPIF feature enhancement and fixes for v3.5
On Tue 10 July 2012 14:53:52 Lad, Prabhakar wrote: Hi Mauro, Please pull the following VPIF driver feature enhancement and fixes for v3.5 Thanks and Regards, --Prabhakar Lad Just for the record: Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans The following changes since commit bd0a521e88aa7a06ae7aabaed7ae196ed4ad867a: Linux 3.5-rc6 (2012-07-07 17:23:56 -0700) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git pull_vpif Lad, Prabhakar (2): davinci: vpif capture: migrate driver to videobuf2 davinci: vpif display: migrate driver to videobuf2 Manjunath Hadli (12): davinci: vpif: add check for genuine interrupts in the isr davinci: vpif: make generic changes to re-use the vpif drivers on da850/omap-l138 soc davinci: vpif: make request_irq flags as shared davinci: vpif: fix setting of data width in config_vpif_params() function davinci: vpif display: size up the memory for the buffers from the buffer pool davinci: vpif capture: size up the memory for the buffers from the buffer pool davinci: vpif: add support for clipping on output data davinci: vpif display: Add power management support davinci: vpif capture:Add power management support davinci: vpif: Add suspend/resume callbacks to vpif driver davinci: vpif: add build configuration for vpif drivers davinci: vpif: Enable selection of the ADV7343 and THS7303 drivers/media/video/davinci/Kconfig| 30 +- drivers/media/video/davinci/Makefile |8 +- drivers/media/video/davinci/vpif.c | 45 ++- drivers/media/video/davinci/vpif.h | 45 ++ drivers/media/video/davinci/vpif_capture.c | 690 +++- drivers/media/video/davinci/vpif_capture.h | 16 +- drivers/media/video/davinci/vpif_display.c | 684 +++ drivers/media/video/davinci/vpif_display.h | 23 +- include/media/davinci/vpif_types.h |2 + 9 files changed, 881 insertions(+), 662 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/2] media: add new mediabus format enums for dm365
Hi Laurent, On Tue, Jul 17, 2012 at 17:25:42, Laurent Pinchart wrote: Hi Manjunath, On Tuesday 17 July 2012 11:41:11 Hadli, Manjunath wrote: On Tue, Jul 17, 2012 at 16:26:24, Laurent Pinchart wrote: On Friday 30 March 2012 10:09:13 Hadli, Manjunath wrote: add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 171 include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml [snip] @@ -965,6 +1036,56 @@ entryysubscript1/subscript/entry entryysubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-UV8-1X8 That's a weird one. Just out of curiosity, what's the point of transferring chroma information without luma ? DM365 supports this format. Right, but what is it used for ? Sorry about that. The Resizer in Dm365 can take only chroma and resize the buffer. It can also take luma of course.In general it can take UV8, Y8 and also UYVY. [snip] @@ -2415,6 +2536,56 @@ entryusubscript1/subscript/entry entryusubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-YDYC8-1X16 What is this beast ? We at least need a textual description, as I have no idea what the format corresponds to. This was discussed earlier over here http://patchwork.linuxtv.org/patch/8843/ My bad, I should have remembered that. Please add a textual description of the format, it's not clear from the name what D and C are. I see no description for individual MBUS formats but a collective para on everything together. Would you like me to add in the same or otherwise can you point to me where I can add this description? Thx, --Manju -- 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: dma-buf/fbdev: one-to-many support
Hi Laurent and Alan On Tue, Jul 17, 2012 at 1:24 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: The main issue is that fbdev has been designed with the implicit assumption that an fbdev driver will always own the graphics memory it uses. All components in the stack, from drivers to applications, have been designed around that assumption. We could of course fix this, revamp the fbdev API and turn it into a modern graphics API, but I really wonder whether it would be worth it. DRM has been getting quite a lot of attention lately, especially from embedded developers and vendors, and the trend seems to me like the (Linux) world will gradually move from fbdev to DRM. Please feel free to disagree :-) I would disagree on the main issue bit. All the graphics cards have their own formats and cache management rules. Simply sharing a buffer doesn't work - which is why all of the extra gloop will be needed. This is exactly why I suggested adding an owner field. A driver could then check whether the buffer it is supposed to share/takeover is from a compatible (or even the same) driver/device. If it is not, it would simply reject using the buffer. Then again, if we have multiple devices that are incompatible, we are still unable to share the buffer. So this attempt would only be useful if we have tons of DisplayLink devices attached that all use the same driver, for example. Regarding DRM: In user-space I prefer DRM over fbdev. With the introduction of the dumb-buffers there isn't even the need to have mesa installed. However, fblog runs in kernel space and currently cannot use DRM as there is no in-kernel DRM API. I looked at drm-fops.c whether it is easy to create a very simple in-kernel API but then I dropped the idea as this might be too complex for a simple debugging-only driver. Another attempt would be making the drm-fb-helper more generic so we can use this layer as in-kernel DRM API. I had a deeper look into this this weekend and so as a summary I think all in-kernel graphics access is probably not worth optimizing it. fbcon is already working great and fblog is only used during boot and oopses/panics and can be restricted to a single device. I will have another look at the drivers in a few weeks but if you tell me that this is not easy to implement, I will probably have to let this idea go. Thanks David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
media_build: ov534_9.c:1381:3: error: implicit declaration of function 'err'
Hello Jean-François, I just tried to build drivers using media_build.git. Could you look that issue? /media_build/v4l/ov534_9.c: In function 'sd_init': /media_build/v4l/ov534_9.c:1381:3: error: implicit declaration of function 'err' [-Werror=implicit-function-declaration] Diff against 3.5-rc5 says: 26a27 #undef pr_fmt 1380c1381 pr_err(Unknown sensor %04x, sensor_id); --- err(Unknown sensor %04x, sensor_id); regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: media_build: ov534_9.c:1381:3: error: implicit declaration of function 'err'
On 07/17/2012 03:27 PM, Antti Palosaari wrote: Hello Jean-François, I just tried to build drivers using media_build.git. Could you look that issue? /media_build/v4l/ov534_9.c: In function 'sd_init': /media_build/v4l/ov534_9.c:1381:3: error: implicit declaration of function 'err' [-Werror=implicit-function-declaration] Diff against 3.5-rc5 says: 26a27 #undef pr_fmt 1380c1381 pr_err(Unknown sensor %04x, sensor_id); --- err(Unknown sensor %04x, sensor_id); argh, same seem to be for hdpvr-core.c. Forget whole issue. 3.5-rc5 seems to have fixed those correctly but media_build.git downloads older drivers. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patches to media_build, and a few other things
On 07/17/2012 01:21 AM, Hin-Tak Leung wrote: I have a couple of patches to my local media_build repo, which do these: - a new option --as-is to the build script. It basically suppresses any git pull/rebase to both media_build and the ./media subdirectory (if used in combination with --main-git). In combination to --main-git, you are left on your own and be wholy responsible about what is inside ./media - I use that to check Antti's work (which is on a branch), and also since I have some interrim patches to media_build itself, I would prefer I can tell it not to pull/merge . - a small change to v4l/Makefile , to install under /lib/modules/$(KERNELRELEASE)/updates/... - recent fedora seems to have a modprobe preference to load from ../updates/... (or at least, that's the case of having installed compat-wireless at some stage - one might want to steal some code from that?), when more than one kernel module of the same name exists. This is so as not to trash distro-shipped modules (and also if one cleans out .../updates/... and runs depmod -a, one is back to distro as shipped behavior). Also trashing distro-shipped modules have the side-effect of making drpm not to work and whole kernel packages are downloaded in the next yum upgrade. I also have a suggestion to make: - How http://linux/linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2 is generated, probably should be documented. Over the weekend I was playing with one with timestamp Jul 7, and it is quite broken with firstly header files not in the right place (linux/v4l2-common.h instead of media/v4l2-common.h), and also the following: media_build/v4l/../linux/include/media/v4l2-dev.h:127:2: error: unknown type name 'v4l2_std_id' media_build/v4l/../linux/include/media/v4l2-dev.h:128:2: error: unknown type name 'v4l2_std_id' media_build/v4l/../linux/include/media/v4l2-dev.h:135:32: error: 'BASE_VIDIOC_PRIVATE' undeclared here (not in a function) I see that the Jul 16 version has both of these issues fixed... but I am not against having a look myself if it is urgent enough for me (considered that it was broken for 9 days). - a few of the firmware files are newer/different than distro-shipped... I am less bothered by it trashing distro-shipped packaged files as the linux-firmware package is rarely upgraded. But maybe one can try pushing some of that upstream? The last one, something for Antti to figure out: - I found that that part of backports/api_version.patch, which changes LINUX_VERSION_CODE to V4L2_VERSION in drivers/media/video/v4l2-ioctl.c, is relocated from line 930-ish in http://linux/linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2 to line 590-ish in Antti's dvb_core branch. So there are commits which are in linux-media-LATEST.tar.bz2 and not in Antti's branch or vice versa. (so that's any reason who one wants to know how linux-media-LATEST.tar.bz2 is made). I used Linus 3.5 development tree as a base and rebased it continuously to latest rc. Current media_build.git seems to download some older files. I could guess it is tar'ed from Kernel 3.4 /drivers/media/ Patch which likely breaks backports/api_version.patch is that: http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg13388.html regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP
The following 2 patches add driver for S5K4ECGX sensor with embedded ISP SoC, and minor v4l2 control API enhancement. S5K4ECGX is 5M CMOS Image sensor from Samsung. Currenlty ony preview mode is supported. (no capture mode/face detection) Sangwook Lee (2): v4l: Add factory register values form S5K4ECGX sensor v4l: Add v4l2 subdev driver for S5K4ECGX sensor drivers/media/video/Kconfig |7 + drivers/media/video/Makefile|1 + drivers/media/video/s5k4ecgx.c | 871 ++ drivers/media/video/s5k4ecgx_regs.h | 3121 +++ include/media/s5k4ecgx.h| 29 + 5 files changed, 4029 insertions(+) create mode 100644 drivers/media/video/s5k4ecgx.c create mode 100644 drivers/media/video/s5k4ecgx_regs.h create mode 100644 include/media/s5k4ecgx.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor
This dirver implements preview mode of the S5K4ECGX sensor.
capture (snapshot) operation, face detection are missing now.
Following controls are supported:
contrast/saturation/birghtness/sharpness
Signed-off-by: Sangwook Lee sangwook@linaro.org
---
drivers/media/video/Kconfig|7 +
drivers/media/video/Makefile |1 +
drivers/media/video/s5k4ecgx.c | 871
include/media/s5k4ecgx.h | 29 ++
4 files changed, 908 insertions(+)
create mode 100644 drivers/media/video/s5k4ecgx.c
create mode 100644 include/media/s5k4ecgx.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 99937c9..45d7f99 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -559,6 +559,13 @@ config VIDEO_S5K6AA
This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M
camera sensor with an embedded SoC image signal processor.
+config VIDEO_S5K4ECGX
+tristate Samsung S5K4ECGX sensor support
+depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
+---help---
+ This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M
+ camera sensor with an embedded SoC image signal processor.
+
source drivers/media/video/smiapp/Kconfig
comment Flash devices
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d209de0..605bf35 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
+obj-$(CONFIG_VIDEO_S5K4ECGX)+= s5k4ecgx.o
obj-$(CONFIG_VIDEO_SMIAPP) += smiapp/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
diff --git a/drivers/media/video/s5k4ecgx.c b/drivers/media/video/s5k4ecgx.c
new file mode 100644
index 000..68a1977
--- /dev/null
+++ b/drivers/media/video/s5k4ecgx.c
@@ -0,0 +1,871 @@
+/*
+ * Driver for s5k4ecgx (5MP Camera) from SAMSUNG
+ * a quarter-inch optical format 1.4 micron 5 megapixel (Mp)
+ * CMOS image sensor, as reffering to s5k6aa.c
+ *
+ * Copyright (C) 2012, Linaro, Sangwook Lee sangwook@linaro.org
+ * Copyright (C) 2012, Insignal Co,. Ltd, Homin Lee suap...@insignal.co.kr
+ * Copyright (C) 2011, SAMSUNG ELECTRONICS
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/vmalloc.h
+#include linux/slab.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/media-entity.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-mediabus.h
+#include media/s5k4ecgx.h
+
+#include s5k4ecgx_regs.h
+
+static int debug;
+module_param(debug, int, 0644);
+
+#define S5K4ECGX_DRIVER_NAME s5k4ecgx
+
+/* Basic windows sizes */
+#define S5K4ECGX_OUT_WIDTH_DEF 640
+#define S5K4ECGX_OUT_HEIGHT_DEF480
+#define S5K4ECGX_WIN_WIDTH_MAX 1024
+#define S5K4ECGX_WIN_HEIGHT_MAX600
+#define S5K4ECGX_WIN_WIDTH_MIN 176
+#define S5K4ECGX_WIN_HEIGHT_MIN144
+
+/* Firmware revision information */
+#define S5K4ECGX_REVISION_1_1 0x11
+#define S5K4ECGX_FW_VERSION0x4EC0
+#define REG_FW_VERSION 0x71A4
+#define REG_FW_REVISION0x71A6
+
+/* For now we use only one user configuration register set */
+#define S5K4ECGX_MAX_PRESETS 1
+
+/* Review this depending on system */
+#define S5K4ECGX_POLL_TIME 1 /* ms */
+
+/* General purpose parameters */
+#define REG_USER_BRIGHTNESS0x722C /* Brigthness */
+#define REG_USER_CONTRAST 0x722E /* Contrast */
+#define REG_USER_SATURATION0x7230 /* Saturation */
+
+/* FIXME: No information availble about these register from the datasheet */
+#define REG_USER_SHARP10x7A28
+#define REG_USER_SHARP20x7ADE
+#define REG_USER_SHARP30x7B94
+#define REG_USER_SHARP40x7C4A
+#define REG_USER_SHARP50x7D00
+
+#define LSB(X) (((X) 0xFF))
+#define MSB(Y) (((Y) 8) 0xFF)
+
+/*
+ * Preview size lists supported by sensor
+ */
+struct regval_list *pview_size[] = {
+ s5k4ecgx_176_preview,
+ s5k4ecgx_352_preview,
+ s5k4ecgx_640_preview,
+ s5k4ecgx_720_preview,
+};
+
+struct s5k4ecgx_framesize {
+ u32 idx; /* Should indicate index of pview_size */
+ u32 width;
+ u32 height;
+};
+
+/*
+ * TODO: currently only preview is supported and snapshopt(capture)
+ * is not
Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Thanks! Mauro Mensagem original Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 De: Theodore Ts'o ty...@mit.edu Para: James Bottomley james.bottom...@hansenpartnership.com CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel linux-ker...@vger.kernel.org On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: Hi All, We have set aside the second day of the kernel summit (Tuesday 28 August) as mini-summit day. So far we have only the PCI mini summit on this day, so if you can think of other topics, please send them to the kernel summit discuss list: ksummit-2012-disc...@lists.linux-foundation.org Looking at the available rooms, we think we can run about four or five mini summits. As an added incentive, mini summit organisers get to pick who they invite and all the people they pick will get an automatic invitation to the third day of the kernel summit (but not the core first day) and the evening events. OK, so far I believe I've heard concrete suggestions from identified (or fairly well identified :-) stuckees willing to organize mini-summits for: * ARM * Media * PCI * memcg I may have missed some, so if people could send a message to the discuss list with [MINI-SUMMIT] in the subbject line and the name of the proposed mini-summit, that would be really helpful. Please indicate whether you are volunteering to help organize the proposed mini-summit, or identify someone you think can be volunteered. :-) Things that we will be asking the mini-summit chars to determine, in addition to who should be given invites for Tuesday and Wednesday is an estimate of how much time you need, and a list of sub-topics (and who might lead the sub-topic discussion). We will be asking you to create a fairly well-defined schedule, with 30 and 60 minute slots, so that we can publish a schedule and so that people who might need to hop between mini-summits, have a chance to do so. So please start thinking about how long each of your sub-topics will need to be, and who might be needed for a particular sub-topic's discussion to be successful. There may be a number of developers, with fingers in multiple subsystem, where scheduling may become a bit of a challenge. Thanks!! - Ted ___ Ksummit-2012-discuss mailing list ksummit-2012-disc...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
As we did in 2012, we're planning to do a media summit again at KS/2012. Excellent. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'm interested. I like the idea of some cross-subsystem pollination, talking with the ALSA people for example ... and given that ARM is growing, I'd like to catch up and understand where ARM silicon is heading in terms of embedded video decoding and any support for hardware specific features we may / may not have / need. ... and of course, if we have anyone from Intel then we should be asking if/when their Intel Media SDK (hardware H264 encoding) is going to become a reality, or possibly kickstart that process. -- Steven Toth - 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: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
Hi Guennadi, On 07/16/2012 10:55 AM, Guennadi Liakhovetski wrote: Hi Sylwester Thanks for your comments to my RFC and for pointing out to this your earlier patch series. Unfortunately, I missed in in May, let me try to provide some thoughts about this, we should really try to converge our proposals. Maybe a discussion at KS would help too. Thank you for the review. I was happy to see your RFC, as previously there seemed to be not much interest in DT among the media guys. Certainly, we need to work on a common approach to ensure interoperability of existing drivers and to avoid having people inventing different bindings for common features. I would also expect some share of device specific bindings, as diversity of media devices is significant. I'd be great to discuss these things at KS, especially support for proper suspend/resume sequences. Also having common sessions with other subsystems folks, like ASoC, for example, might be a good idea. I'm not sure if I'll be travelling to the KS though. :) On Fri, 25 May 2012, Sylwester Nawrocki wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC (camera host interface DMA engine and image processor). This patch adds support for instantiating the MIPI-CSIS devices from DT and parsing all SoC and board specific properties from device tree. The MIPI DPHY control callback is now called directly from within the driver, the platform code must ensure this callback does the right thing for each SoC. The cell-index property is used to ensure proper signal routing, from physical camera port, through MIPI-CSI2 receiver to the DMA engine (FIMC?). It's also helpful in exposing the device topology in user space at /dev/media? devnode (Media Controller API). This patch also defines a common property (data-lanes) for MIPI-CSI receivers and transmitters. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- Documentation/devicetree/bindings/video/mipi.txt |5 + .../bindings/video/samsung-mipi-csis.txt | 47 ++ drivers/media/video/s5p-fimc/mipi-csis.c | 97 +++- drivers/media/video/s5p-fimc/mipi-csis.h |1 + 4 files changed, 126 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/mipi.txt create mode 100644 Documentation/devicetree/bindings/video/samsung-mipi-csis.txt diff --git a/Documentation/devicetree/bindings/video/mipi.txt b/Documentation/devicetree/bindings/video/mipi.txt new file mode 100644 index 000..5aed285 --- /dev/null +++ b/Documentation/devicetree/bindings/video/mipi.txt @@ -0,0 +1,5 @@ +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters + + - data-lanes : number of differential data lanes wired and actively used in +communication between the transmitter and the receiver, this +excludes the clock lane; Wouldn't it be better to use the standard bus-width DT property? I can't see any problems with using bus-width. It seems sufficient and could indeed be better, without a need to invent new MIPI-CSI specific names. That was my first RFC on that and my perspective wasn't probably broad enough. :) diff --git a/Documentation/devicetree/bindings/video/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/video/samsung-mipi-csis.txt new file mode 100644 index 000..7bce6f4 --- /dev/null +++ b/Documentation/devicetree/bindings/video/samsung-mipi-csis.txt @@ -0,0 +1,47 @@ +Samsung S5P/EXYNOS SoC MIPI-CSI2 receiver (MIPI CSIS) +- + +Required properties: + +- compatible - one of : +samsung,s5pv210-csis, +samsung,exynos4210-csis, +samsung,exynos4212-csis, +samsung,exynos4412-csis; +- reg : physical base address and size of the device memory mapped registers; +- interrupts : should contain MIPI CSIS interrupt; the format of the +interrupt specifier depends on the interrupt controller; +- cell-index : the hardware instance index; Not sure whether this is absolutely needed... Wouldn't it be sufficient to just enumerate them during probing? As Grant pointed to me, the cell-index property is something that we should be avoiding. But I needed something like this in the driver, to differentiate between the multiple IP instances. I cannot simply assign the indexes in random way to the hardware instances. Each of the MIPI-CSI Slaves has different properties (e.g. supporting max. 2 or 4 data lanes). Additionally, a particular MIPI-CSI Slave instance is hard-wired inside the SoC to the FIMC input mux (cross-bar) and physical video port. IOW, an image sensor/video port/MIPI-CSIS instance assignment is fixed. If two MIPI-CSI image sensors are connected, one of them will work only with MIPI-CSIS0, and the other only with
Re: libv4l2: error dequeuing buf: Resource temporarily unavailable
Your driver load may not be quite right or got some conflicts. According to: http://www.kernel.org/doc/Documentation/video4linux/CARDLIST.saa7134, the Terratec Cinergy 400 TV should be card=8. Have you tried: restart, modprobe -r saa7134, modprobe saa7134 card=8, dmesg | grep saa7134, and checked if the Terratec Cinergy 400 TV showed up correctly? If right, it should be Ok: ffmpeg -f video4linux2 -i /dev/video0 out.mpg ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg ffmpeg -t 60 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-60sec.avi ..., etc. Thanks a lot for your help. The card is loaded OK. I tried it with the card=8 parameter in a newly created file /etc/modprobe.d/saa7134.conf. It seems to be loaded properly: dmesg | grep saa7134 [ 24.978050] saa7134[0]: found at :04:01.0, rev: 1, irq: 17, latency: 32, mmio: 0xfe50 [ 24.978058] saa7134[0]: subsystem: 153b:1142, board: Terratec Cinergy 400 TV [card=8,insmod option] [ 24.978073] saa7134[0]: board init: gpio is 5 [ 25.053979] input: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0/input6 [ 25.054018] rc0: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0 [ 25.187509] saa7134[0]: i2c eeprom 00: 3b 15 42 11 ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187517] saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187523] saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187529] saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187535] saa7134[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187541] saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187547] saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187553] saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187559] saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187566] saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187571] saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187577] saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187583] saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187589] saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187595] saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187601] saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.716134] saa7134[0]: registered device video0 [v4l2] [ 25.716157] saa7134[0]: registered device vbi0 [ 25.998624] saa7134 ALSA driver for DMA sound loaded [ 25.998650] saa7134[0]/alsa: saa7134[0] at 0xfe50 irq 17 registered as card -1 ffmpeg -f video4linux2 -i /dev/video0 test.mpg gives still the error mentioned in the subject, ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg gives an I/O error while setting the framerate ffmpeg version 0.10.4 Copyright (c) 2000-2012 the FFmpeg developers built on Jun 13 2012 09:51:06 with gcc 4.7.0 20120507 (Red Hat 4.7.0-5) configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-gnutls --enable-libass --enable-libcdio --enable-libcelt --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopenjpeg --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect libavutil 51. 35.100 / 51. 35.100 libavcodec 53. 61.100 / 53. 61.100 libavformat53. 32.100 / 53. 32.100 libavdevice53. 4.100 / 53. 4.100 libavfilter 2. 61.100 / 2. 61.100 libswscale 2. 1.100 / 2. 1.100 libswresample 0. 6.100 / 0. 6.100 libpostproc52. 0.100 / 52. 0.100 Please use -b:a or -b:v, -b is ambiguous [video4linux2,v4l2 @ 0x9bd440] ioctl set time per frame(1/30) failed /dev/video0: Input/output error While we have
Re: [RFC/PATCH 06/13] media: s5p-fimc: Add device tree support for FIMC-LITE
On 07/16/2012 11:15 AM, Guennadi Liakhovetski wrote: --- a/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/camera/soc/samsung-fimc.txt @@ -39,6 +39,21 @@ Required properties: depends on the SoC revision. For S5PV210 valid values are: 0...2, for Exynos4x1x: 0...3. + +'fimc-lite' device node +--- + +Required properties: + +- compatible : should be one of: + samsung,exynos4212-fimc; + samsung,exynos4412-fimc; +- reg : physical base address and size of the device's memory mapped + registers; +- interrupts : should contain FIMC-LITE interrupt; +- cell-index : FIMC-LITE IP instance index; Same as in an earlier patch - not sure this is needed. It is needed for setting up a pipeline of multiple sub-device within a SoC. As I commented on patch 2/13 I'd like to replace this with proper entries in the aliases node. Some sub-devices have registers that these indexes need to be directly written to. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
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:Tue Jul 17 19:00:20 CEST 2012 git hash:931efdf58bd83af8d0578a6cc53421675daf6d41 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-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-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 apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: libv4l2: error dequeuing buf: Resource temporarily unavailable
It means, your FFmpeg may not be installed properly or has dependency issue. To confirm it, use Ubuntu-10.04-LTS--LiveDVD (that can be downloaded from: http://cdimage.ubuntu.com/releases/lucid/release/ ) without installation, and run sudo apt-get install ffmpeg before running: $ modprobe -r saa7134 $ modprobe saa7134 card=8 $ ffmpeg -t 300 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-5min.mpg or $ ffmpeg -t 600 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-10min.avi The FFmpeg commands listed above had been proven working well, with Sensoray Model 811 (http://www.sensoray.com/products/811.htm), 911 (http://www.sensoray.com/products/911.htm), 614-NC (http://www.sensoray.com/products/614.htm), and 314-NC (http://www.sensoray.com/products/314.htm), which are all SAA7134-based frame/video capture boards. -Original Message- From: llar...@gmx.net [mailto:llar...@gmx.net] Sent: Tuesday, July 17, 2012 11:46 AM To: char...@sensoray.com Cc: linux-media@vger.kernel.org Subject: Re: libv4l2: error dequeuing buf: Resource temporarily unavailable Your driver load may not be quite right or got some conflicts. According to: http://www.kernel.org/doc/Documentation/video4linux/CARDLIST.saa713 4, the Terratec Cinergy 400 TV should be card=8. Have you tried: restart, modprobe -r saa7134, modprobe saa7134 card=8, dmesg | grep saa7134, and checked if the Terratec Cinergy 400 TV showed up correctly? If right, it should be Ok: ffmpeg -f video4linux2 -i /dev/video0 out.mpg ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg ffmpeg -t 60 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-60sec.avi ..., etc. Thanks a lot for your help. The card is loaded OK. I tried it with the card=8 parameter in a newly created file /etc/modprobe.d/saa7134.conf. It seems to be loaded properly: dmesg | grep saa7134 [ 24.978050] saa7134[0]: found at :04:01.0, rev: 1, irq: 17, latency: 32, mmio: 0xfe50 [ 24.978058] saa7134[0]: subsystem: 153b:1142, board: Terratec Cinergy 400 TV [card=8,insmod option] [ 24.978073] saa7134[0]: board init: gpio is 5 [ 25.053979] input: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0/input6 [ 25.054018] rc0: saa7134 IR (Terratec Cinergy 40 as /devices/pci:00/:00:1c.4/:03:00.0/:04:01.0/rc/rc0 [ 25.187509] saa7134[0]: i2c eeprom 00: 3b 15 42 11 ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187517] saa7134[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187523] saa7134[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187529] saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187535] saa7134[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187541] saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187547] saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187553] saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187559] saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187566] saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187571] saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187577] saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187583] saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187589] saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187595] saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.187601] saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 25.716134] saa7134[0]: registered device video0 [v4l2] [ 25.716157] saa7134[0]: registered device vbi0 [ 25.998624] saa7134 ALSA driver for DMA sound loaded [ 25.998650] saa7134[0]/alsa: saa7134[0] at 0xfe50 irq 17 registered as card -1 ffmpeg -f video4linux2 -i /dev/video0 test.mpg gives still the error mentioned in the subject, ffmpeg -t 30 -f video4linux2 -s vga -r 30 -b 2000k -i /dev/video0 out-vga-2M-30sec.mpg gives an I/O error while setting the framerate ffmpeg version 0.10.4 Copyright (c) 2000-2012 the FFmpeg developers built on Jun 13 2012 09:51:06 with gcc 4.7.0 20120507 (Red Hat 4.7.0-5) configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --enable-bzlib
Re: Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Tue July 17 2012 19:30:53 Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd like to have 30 minutes to discuss a few V4L2 API ambiguities or just plain weirdness, just like I did last year. I'll make an RFC issues to discuss beforehand. I might also have a short presentation/demo of v4l2-compliance, as I believe more people need to know about that utility. Regards, Hans Thanks! Mauro Mensagem original Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 De: Theodore Ts'o ty...@mit.edu Para: James Bottomley james.bottom...@hansenpartnership.com CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel linux-ker...@vger.kernel.org On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: Hi All, We have set aside the second day of the kernel summit (Tuesday 28 August) as mini-summit day. So far we have only the PCI mini summit on this day, so if you can think of other topics, please send them to the kernel summit discuss list: ksummit-2012-disc...@lists.linux-foundation.org Looking at the available rooms, we think we can run about four or five mini summits. As an added incentive, mini summit organisers get to pick who they invite and all the people they pick will get an automatic invitation to the third day of the kernel summit (but not the core first day) and the evening events. OK, so far I believe I've heard concrete suggestions from identified (or fairly well identified :-) stuckees willing to organize mini-summits for: * ARM * Media * PCI * memcg I may have missed some, so if people could send a message to the discuss list with [MINI-SUMMIT] in the subbject line and the name of the proposed mini-summit, that would be really helpful. Please indicate whether you are volunteering to help organize the proposed mini-summit, or identify someone you think can be volunteered. :-) Things that we will be asking the mini-summit chars to determine, in addition to who should be given invites for Tuesday and Wednesday is an estimate of how much time you need, and a list of sub-topics (and who might lead the sub-topic discussion). We will be asking you to create a fairly well-defined schedule, with 30 and 60 minute slots, so that we can publish a schedule and so that people who might need to hop between mini-summits, have a chance to do so. So please start thinking about how long each of your sub-topics will need to be, and who might be needed for a particular sub-topic's discussion to be successful. There may be a number of developers, with fingers in multiple subsystem, where scheduling may become a bit of a challenge. Thanks!! - Ted ___ Ksummit-2012-discuss mailing list ksummit-2012-disc...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss -- 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: [RFC] media DT bindings
On Wed July 11 2012 16:27:52 Guennadi Liakhovetski wrote:
Hi all
Background
==
With ARM adoption of flat Device Trees a need arises to move platform
device descriptions and their data from platform files to DT. This has
also to be done for media devices, e.g., video capture and output
interfaces, data processing devices, camera sensors, TV decoders and
encoders. This RFC is trying to spawn a discussion to define standard V4L
DT bindings. The first version will concentrate on the capture path,
mostly taking care of simple capture-interface - camera sensor / TV
decoder configurations. Since the author is not working intensively yet
with the Media Controller API, pad-level configuration, these topics might
be underrepresented in this RFC. I hope others, actively working in these
areas, will fill me in on them.
Overview
As mentioned above, typical configurations, that we'll be dealing with
consist of a DMA data capture engine, one or more data sources like camera
sensors, possibly some data processing units. Data capture and processing
engines are usually platform devices, whereas data source devices are
typically I2C slaves. Apart from defining each device we'll also describe
connections between them as well as properties of those connections.
Capture devices
==
These are usually platform devices, integrated into respective SoCs. There
also exist external image processing devices, but they are rare. Obvious
differences between them and integrated devices include a different bus
attribution and a need to explicitly describe the connection to the SoC.
As far as capture devices are concerned, their configuration will
typically include a few device-specific bindings, as well as standard
ones. Standard bindings will include the usual reg, interrupts,
clock-frequency properties.
It is more complex to describe external links. We need to describe
configurations, used with various devices, attached to various pads. It is
proposed to describe such links as child nodes. Each such link will
reference a client pad, a local pad and specify the bus configuration. The
media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
proposed to describe both the bus-width in the parallel case and the
number of lanes in the serial case, using the standard bus-width
property.
On the parallel bus common properties include signal polarities, possibly
data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if lines 7:0),
protocol (e.g., BT.656). Additionally device-specific properties can be
defined.
A MIPI CSI-2 bus common properties would include, apart from the number of
lanes, routed to that client, the clock frequency, a channel number,
possibly CRC and ECC flags.
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg = 0xfe91 0xa0;
interrupts = 0x880;
bus-width = 16; /* #lines routed on the board */
clock-frequency = 5000; /* max clock */
#address-cells = 1;
#size-cells = 0;
...
ov772x-1 = {
reg = 0;
client = ov772x@0x21-0;
local-pad = parallel-sink;
remote-pad = parallel-source;
bus-width = 8;/* used data lines */
data-shift = 0; /* lines 7:0 are used */
hsync-active = 1; /* active high */
vsync-active = 1; /* active high */
pclk-sample = 1; /* rising */
clock-frequency = 2400;
};
};
Client devices
==
Client nodes are children on their respective busses, e.g., i2c. This
placement leads to these devices being possibly probed before respective
host interfaces, which will fail due to known reasons. Therefore client
drivers have to be adapted to request a delayed probing, as long as the
respective video host hasn't probed.
Client nodes will include all the properties, usual for their busses.
Additionally they will specify properties private to this device type and
common for all V4L2 client devices - device global and per-link. I think,
we should make it possible to define client devices, that can at run-time
be connected to different sinks, even though such configurations might not
be very frequent. To achieve this we also specify link information in
child devices, similar to those in host nodes above. This also helps
uniformity and will let us implement and use a universal link-binding
parser. So, a node, that has been referenced above could look like
ov772x@0x21-0 = {
compatible = omnivision,ov772x;
reg
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Mauro On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd love to attend, especially since, as you have seen, I've started doing some work on V4L DT bindings, but so far it very much looks like I won't be able to do so unfortunately. Thanks Guennadi Thanks! Mauro Mensagem original Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 De: Theodore Ts'o ty...@mit.edu Para: James Bottomley james.bottom...@hansenpartnership.com CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel linux-ker...@vger.kernel.org On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: Hi All, We have set aside the second day of the kernel summit (Tuesday 28 August) as mini-summit day. So far we have only the PCI mini summit on this day, so if you can think of other topics, please send them to the kernel summit discuss list: ksummit-2012-disc...@lists.linux-foundation.org Looking at the available rooms, we think we can run about four or five mini summits. As an added incentive, mini summit organisers get to pick who they invite and all the people they pick will get an automatic invitation to the third day of the kernel summit (but not the core first day) and the evening events. OK, so far I believe I've heard concrete suggestions from identified (or fairly well identified :-) stuckees willing to organize mini-summits for: * ARM * Media * PCI * memcg I may have missed some, so if people could send a message to the discuss list with [MINI-SUMMIT] in the subbject line and the name of the proposed mini-summit, that would be really helpful. Please indicate whether you are volunteering to help organize the proposed mini-summit, or identify someone you think can be volunteered. :-) Things that we will be asking the mini-summit chars to determine, in addition to who should be given invites for Tuesday and Wednesday is an estimate of how much time you need, and a list of sub-topics (and who might lead the sub-topic discussion). We will be asking you to create a fairly well-defined schedule, with 30 and 60 minute slots, so that we can publish a schedule and so that people who might need to hop between mini-summits, have a chance to do so. So please start thinking about how long each of your sub-topics will need to be, and who might be needed for a particular sub-topic's discussion to be successful. There may be a number of developers, with fingers in multiple subsystem, where scheduling may become a bit of a challenge. Thanks!! - Ted ___ Ksummit-2012-discuss mailing list ksummit-2012-disc...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss ___ Workshop-2011 mailing list workshop-2...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 --- 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: [RFC/PATCH 05/13] media: s5p-fimc: Add device tree support for FIMC devices
On 07/16/2012 11:13 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Karol Lewandowskik.lewando...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com From the documentation below I think, I understand what it does, but why is it needed? It doesn't describe your video subsystem topology, right? How various subdevices are connected. It just lists them all in one node... A description for this patch would be very welcome IMHO and, maybe, such a node can be completely avoided? Sorry, I'll provide better description in next iteration. It's true it doesn't describe the topology in detail, as there are multiple one-to many possible connections between sub-devices. An exact topology is coded in the driver and can be changed through MC API. The samsung,camif-mux-id and video-bus-type properties at sensor nodes just specify to which physical SoC camera port an image sensor is connected. Originally the all camera devices were supposed to land under common 'camera' node. And a top level driver would be registering all platform devices. With this approach it would be possible to better control PM handling (which currently depends on an order of registering devices to the driver core). But then we discovered that we couldn't use OF_DEV_AUXDATA in such case, which was required to preserve platform device names, in order for the clock API to work. So I've moved some sub-devices out of 'camera' node and have added only a list of phandles to them in that node. This is rather a cheap workaround.. I think all camera sub-devices should be placed under common node, as there are some properties that don't belong to any sub-node: GPIO config, clocks, to name a few. Of course simpler devices might not need such a composite node. I think we can treat the sub-device interdependencies as an issue separate from a need for a common node. If some devices need to reflect the topology better, we probably could include in some nodes (a list of) phandles to other nodes. This could ease parsing the topology at the drivers, by using existing OF infrastructure. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb: push down ioctl lock in dvb_usercopy
Hi! I don't want to press or annoy anybody, but may I ask what's the status of this patch[1]? On Thu, Jun 21, 2012 at 07:44:15PM +0200, sch...@macnetix.de wrote: Since most dvb ioctls wrap their real work with dvb_usercopy, the static mutex used in dvb_usercopy effectively is a global lock for dvb ioctls. Unfortunately, frontend ioctls can be blocked by the frontend thread for several seconds; this leads to unacceptable lock contention. Mitigate that by pushing the mutex from dvb_usercopy down to the individual, device specific ioctls. On our systems, this patch has a great effect in terms of scalability when operating multiple DVB tuners. Is it going to be considered? Thanks, Nikolaus [1] http://patchwork.linuxtv.org/patch/12989/ -- 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/6] staging/media/solo6x10: use module_pci_driver macro
On Tue, Jul 10, 2012 at 3:45 AM, Devendra Naga devendra.a...@gmail.com wrote:
the driver duplicates the module_pci_driver code,
how?
module_pci_driver is used for those drivers whose
init and exit paths does only register and unregister
to pci API and nothing else.
so use the module_pci_driver macro instead
Signed-off-by: Devendra Naga devendra.a...@gmail.com
---
drivers/staging/media/solo6x10/core.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/staging/media/solo6x10/core.c
b/drivers/staging/media/solo6x10/core.c
index d2fd842..3ee9b12 100644
--- a/drivers/staging/media/solo6x10/core.c
+++ b/drivers/staging/media/solo6x10/core.c
@@ -318,15 +318,4 @@ static struct pci_driver solo_pci_driver = {
.remove = solo_pci_remove,
};
-static int __init solo_module_init(void)
-{
- return pci_register_driver(solo_pci_driver);
-}
-
-static void __exit solo_module_exit(void)
-{
- pci_unregister_driver(solo_pci_driver);
-}
-
-module_init(solo_module_init);
-module_exit(solo_module_exit);
+module_pci_driver(solo_pci_driver);
Acked-by: Ismael Luceno ismael.luc...@gmail.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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Steven, On Tuesday 17 July 2012 13:49:43 Steven Toth wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. Excellent. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'm interested. I like the idea of some cross-subsystem pollination, talking with the ALSA people for example ... That's very much in line with the KS/LPC spirit, I'd like to see that happen as well. We've been talking about media controller support in ALSA for ages :-) and given that ARM is growing, I'd like to catch up and understand where ARM silicon is heading in terms of embedded video decoding and any support for hardware specific features we may / may not have / need. Information about future directions is unfortunately usually private, but we can always ask. To be honest I sometimes feel like even SoC vendors themselves don't know where they're heading to :-) If only that, a presentation about the latest media-related hardware developments on ARM would be good to get everybody up to speed. ... and of course, if we have anyone from Intel then we should be asking if/when their Intel Media SDK (hardware H264 encoding) is going to become a reality, or possibly kickstart that process. -- 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/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor
Hi Sangwook,
I've few comments, some just nitpicking. Feel free to disagree. :)
On 07/17/2012 07:17 PM, Sangwook Lee wrote:
This dirver implements preview mode of the S5K4ECGX sensor.
capture (snapshot) operation, face detection are missing now.
Following controls are supported:
contrast/saturation/birghtness/sharpness
Signed-off-by: Sangwook Lee sangwook@linaro.org
---
drivers/media/video/Kconfig|7 +
drivers/media/video/Makefile |1 +
drivers/media/video/s5k4ecgx.c | 871
include/media/s5k4ecgx.h | 29 ++
4 files changed, 908 insertions(+)
create mode 100644 drivers/media/video/s5k4ecgx.c
create mode 100644 include/media/s5k4ecgx.h
[snip]
+/*
+ * V4L2 subdev controls
+ */
+static int s5k4ecgx_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+
+ struct v4l2_subdev *sd = container_of(ctrl-handler, struct s5k4ecgx,
+ handler)-sd;
+ struct s5k4ecgx *priv = to_s5k4ecgx(sd);
+ int err = 0;
+
+ v4l2_dbg(1, debug, sd, ctrl: 0x%x, value: %d\n, ctrl-id, ctrl-val);
+ mutex_lock(priv-lock);
+
+ switch (ctrl-id) {
+ case V4L2_CID_CONTRAST:
+ err = s5k4ecgx_write_ctrl(sd, REG_USER_CONTRAST, ctrl-val);
+ break;
+
+ case V4L2_CID_SATURATION:
+ err = s5k4ecgx_write_ctrl(sd, REG_USER_SATURATION, ctrl-val);
+ break;
+
+ case V4L2_CID_SHARPNESS:
+ err |= s5k4ecgx_write_ctrl(sd, REG_USER_SHARP1, ctrl-val);
+ err |= s5k4ecgx_write_ctrl(sd, REG_USER_SHARP2, ctrl-val);
+ err |= s5k4ecgx_write_ctrl(sd, REG_USER_SHARP3, ctrl-val);
+ err |= s5k4ecgx_write_ctrl(sd, REG_USER_SHARP4, ctrl-val);
+ err |= s5k4ecgx_write_ctrl(sd, REG_USER_SHARP5, ctrl-val);
+ break;
+
+ case V4L2_CID_BRIGHTNESS:
+ err = s5k4ecgx_write_ctrl(sd, REG_USER_BRIGHTNESS, ctrl-val);
+ break;
+ default:
+ v4l2_dbg(1, debug, sd, unknown set ctrl id 0x%x\n, ctrl-id);
+ err = -ENOIOCTLCMD;
+ break;
+ }
+
+ /* Review this */
+ priv-reg_type = TOK_TERM;
+
+ if (err 0)
+ v4l2_err(sd, Failed to write videoc_s_ctrl err %d\n, err);
I like to hold locks only when strictly necessary. You could write
this error message after it's released.
+ mutex_unlock(priv-lock);
+
+ return err;
+}
+
+static const struct v4l2_ctrl_ops s5k4ecgx_ctrl_ops = {
+ .s_ctrl = s5k4ecgx_s_ctrl,
+};
+
+/*
+ * Reading s5k4ecgx version information
+ */
+static int s5k4ecgx_registered(struct v4l2_subdev *sd)
+{
+ struct s5k4ecgx *priv = to_s5k4ecgx(sd);
+ int ret;
+
+ if (!priv-set_power) {
+ v4l2_err(sd, Failed to call power-up function!\n);
Maybe it's more accurate to say function isn't set.
+ return -EIO;
+ }
+
+ mutex_lock(priv-lock);
+ priv-set_power(true);
+ /* Time to stablize sensor */
+ mdelay(priv-mdelay);
+ ret = s5k4ecgx_read_fw_ver(sd);
+ priv-set_power(false);
+ mutex_unlock(priv-lock);
+
+ return ret;
+}
+
+/*
+ * V4L2 subdev internal operations
+ */
+static int s5k4ecgx_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+
+ struct v4l2_mbus_framefmt *format = v4l2_subdev_get_try_format(fh, 0);
+ struct v4l2_rect *crop = v4l2_subdev_get_try_crop(fh, 0);
+
+ format-colorspace = s5k4ecgx_formats[0].colorspace;
+ format-code = s5k4ecgx_formats[0].code;
+ format-width = S5K4ECGX_OUT_WIDTH_DEF;
+ format-height = S5K4ECGX_OUT_HEIGHT_DEF;
+ format-field = V4L2_FIELD_NONE;
+
+ crop-width = S5K4ECGX_WIN_WIDTH_MAX;
+ crop-height = S5K4ECGX_WIN_HEIGHT_MAX;
+ crop-left = 0;
+ crop-top = 0;
+
+ return 0;
+}
+
+
+static const struct v4l2_subdev_internal_ops s5k4ecgx_subdev_internal_ops = {
+ .registered = s5k4ecgx_registered,
+ .open = s5k4ecgx_open,
+};
+
+static int s5k4ecgx_s_power(struct v4l2_subdev *sd, int val)
+{
+ struct s5k4ecgx *priv = to_s5k4ecgx(sd);
+
+ if (!priv-set_power)
+ return -EIO;
+
+ v4l2_dbg(1, debug, sd, Switching %s\n, val ? on : off);
+
+ if (val) {
+ priv-set_power(val);
+ /* Time to stablize sensor */
+ mdelay(priv-mdelay);
+ /* Loading firmware into ARM7 core of sensor */
+ if (s5k4ecgx_write_array(sd, s5k4ecgx_init_regs) 0)
+ return -EIO;
Shouldn't you s_power(0) in case of error?
+ s5k4ecgx_init_parameters(sd);
+ } else {
+ priv-set_power(val);
+ }
+
+ return 0;
+}
+
+static int s5k4ecgx_log_status(struct v4l2_subdev *sd)
+{
+ v4l2_ctrl_handler_log_status(sd-ctrl_handler, sd-name);
+
+ return 0;
+}
+
+static const struct
Re: TechnoTrend Budget CI stutters and often fails at tuning encrypted channel.
On 07/17/12 11:53, Oliver Schinagl wrote: On 17-07-12 10:30, Oliver Schinagl wrote: Hi list, I have been using a tt1500, a saa7146 PCI DVB-T tuner for well over a year now. Running gentoo 64bit tracking the ~amd64 branch (that only get bi-monthly upgraded) I've been always more or less up to date. This card however has never properly worked. I've been running vdr 1.6.* since that is what's stably in gentoo. Whilst writing this down I realized I still have to test me-tv to double check my findings. Some background info. Here in NL we have 4 FTA channels and about 20 conax encrypted channels that the CAM in the CI module decrypts. I have two smartcards, of which one is only in active use at the moment. When changing channels between the FTA channels, the first 'bug' occurs. Somtimes (not predictably or anything, about 50% of the channel changes) sound stutters the first few seconds, upto 30 seconds sometimes. It sounds almost if the sound is being fed through some sort of PWM, that slowly catches up. So first you hear 1 second of audio, 3 seconds of nothing, then 1 second of audio again, then 2 seconds of nothing etc. This audio delay is random. E.g. sometimes it stutters for about 30 seconds while it has a hard time to catch up, other times the audio needs only 2 or 3 seconds to catch up. Very occasionally it instantly works right. The stuttering appears to be worse on encrypted channels. Encrypted channels has the additional annoyance, that quote often, an entire channel is not available. That is, every channel in its bouqet. Simply waiting on that channel for about a minute or two, mysteriously brings the unavailable channel up. Allthough it 'feels' like changing channel helps this fix faster, it's just a placebo effect if you ask me ;) I cannot safely say that the same skipping happens to the video, I have not noticed it really. I have checked signal strength etc and though the strength is only at 55%, the SNR is at 99% quite stable and the BER (unrecoverable errors? are at 0). If for some reason there is interferance, bad whether, blocked antenna, then the BER goes up followed by distorted imagery and with really bad signal bad audio as well (humans are more sensitive to bad audio iirc). I'm not sure what to profile, where to enable debugging, what logs to check or what to do to help 'fix' this. lspci output: 00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH DVB T-1500 Flags: bus master, medium devsel, latency 32, IRQ 18 Memory at f0162000 (32-bit, non-prefetchable) [size=512] Kernel drive in use: budget_ci dvb /proc/interrupts 18: 499 107651 IO-APIC-fasteoi saa7146 (0) Tuner: tda10046h dvb-t, firmware revision 20 Thank you for your time, oliver P.S. I forgot to mention, that once tuned to a channel, I can receive (and decode) it fine for many hours. I think the longest I had one channel up was about 8 hours or so without issue. A dvb-t radio channel (thus not dab) i had up for even longer, so once it goes, it goes on happily forever! -- After spending about 5? Hours compiling Kaffeine and it's dependancies, I gave that a go. (me-tv does not support CAM's). While tuning went a little iffy at the start, not sure why, signal kept dropping and some SNR spikes, I managed to get all my channels tuned. Kaffeine is much much slower when changing channels. Takes about 2-4 seconds (haven't properly timed it). Kaffeine however never failed to tune a channel and sound always started properly. Btw, I noticed the sound stuttering seems somewhat buffering related, it the sound that IS heard, is often the almost the same 'sample', but does slowly move forward in time. I can immagine that Kaffeine does some really smart things VDR doesn't do, but even the slow channel change doesn't explain why VDR often fails to properly tune. So it seems that the hardware is working quite well albeit slow on channel changing (in kaffeine anyway). I have tried a later version of VDR, as the whole reason i'm digging into this is, is because I was trying to get openbricks/geexbox/VDR/xbmc working where VDR is one of the development versions. So anybody have any idea where to start finding the cause? Is it really VDR? Or is it something in the driver afterall? Anybody can share their experiences with a hardware! CAM? P.S. I'm supprised about the bad signal, as I live about 500meters from the transmitter ... Oliver -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Guennadi, On Tuesday 17 July 2012 21:51:02 Guennadi Liakhovetski wrote: On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd love to attend, especially since, as you have seen, I've started doing some work on V4L DT bindings, As you already know, that's a topic I'm very interested in. DT bindings will likely involve rethinking how the V4L2 core and V4L2 drivers instantiate subdevices, a media summit would have been a good occasion to discuss that. However, we probably need an RFC to start with. but so far it very much looks like I won't be able to do so unfortunately. :-/ -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Mauro, On Tuesday 17 July 2012 14:30:53 Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. Great news! The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Sakari and I will spend time on the long-awaited media controller library in a couple of weeks, I hope to have results to present during the summit. Depending on the audience, I would also be interested in getting feedback from SoC vendors who are not (yet) active in the V4L2 community on our approach and how we could best help them. This could include discussions about Android, as I believe we need to push V4L2 on that platform. Guennadi's recent work on an Android V4L2 camera library is a good first step in that direction. -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Count me in when we have this discussion as this is something we too are working on. Rgds, Palash -Original Message- From: workshop-2011-boun...@linuxtv.org [mailto:workshop-2011-boun...@linuxtv.org] On Behalf Of Laurent Pinchart Sent: Tuesday, July 17, 2012 3:47 PM To: workshop-2...@linuxtv.org Cc: Linux Media Mailing List Subject: Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Hi Mauro, On Tuesday 17 July 2012 14:30:53 Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. Great news! The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Sakari and I will spend time on the long-awaited media controller library in a couple of weeks, I hope to have results to present during the summit. Depending on the audience, I would also be interested in getting feedback from SoC vendors who are not (yet) active in the V4L2 community on our approach and how we could best help them. This could include discussions about Android, as I believe we need to push V4L2 on that platform. Guennadi's recent work on an Android V4L2 camera library is a good first step in that direction. -- Regards, Laurent Pinchart ___ Workshop-2011 mailing list workshop-2...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 Conexant E-mail Firewall (Conexant.Com) made the following annotations - ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** - -- 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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
On 07/13/2012 04:16 PM, Steven Toth wrote: There is set_property() and get_property() callbacks defined for FE already. But those are not used. My opinion is that those callbacks should be changed to deliver data for demodulator and for tuner too instead of current method - which is common huge properties cache structure shared between all sub-drivers. I don't like it all as it is stupid to add stuff that common structure for every standard we has. Lets take example device that supports DVB-C and other device supports ISDB-T. How many common parameters we has? I think only one - frequency. All the others are just waste. When we did DVB V5 for S2 we added set/get property for the demodulators, from memory I had some cx24116 S2 specifics that I was passing, and I expected other demod drivers to adopt the same mechanism. It was fairly obvious at the time that we needed a much more generic way to pass internel controls around from the core to the demods. cx24116 driver does not define set_property() or get_property() currently. I looked the history and yes, there has been those calls. But what I saw - only stub implementation. It still may be possible that there has been real implementation in some time as I didn't looked through all commits - was too many commits to check manually. And later Mauro has removed totally those unused calls with mention it uses DVB v5 *only*. commit 1ac6a854ad444680bffbacd9e340e40c75adc367 Author: Mauro Carvalho Chehab mche...@redhat.com Date: Thu Dec 22 17:28:11 2011 -0300 [media] cx24116: report delivery system and cleanups This is one of the first drivers using DVBv5. It relies only on DVBv5 way, but still it contains some stub for unused methods. Remove them, add the delivery system and do some trivial cleanups. So I suspect you remember wrong. At least there is now common misunderstood what is aimed and what is really done about those callbacks. The cache was to support backwards compatible V3 interfaces and demods, amongst other things. That is what I see cache could be needed. No reason why a new demod today could not support get/set only for configuration. That patch adds set_property() and get_property() handling for dvb-frontend. http://kerneltrap.org/mailarchive/git-commits-head/2008/10/13/3643454/thread For me it looks like meaning is to use those for valid parameters. For example demod driver supports DVB-S but set_property() is called with unsupported delivery system DVB-S2. Driver could nack it and it is never even added to the cache. If success is returned then dvb-frontend adds given parameter to cache and finally calls set_frontend() in order to make demod make tuning request using cached values. But yes, it looks like those calls are possible to use for setting parameters to demod as every parameter is passed for demod using set_frontend() too. What I think I am going to make new RFC which changes that so every parameter from userspace is passed to the demodulator driver (using set_property() - change it current functionality) and not cached to the common cache at all. Shortly: change current common cache based parameter transmission to happen set parameter to demodulator one by one. The other reason for the common cache was to allow sets of parameters to be pushed into the kernel from apps then, at the most appropriate time, tuned. The order of operations becomes irrelevant, so the cache is highly useful, else you end up with demods caching all of their own parameters anyway, many drivers duplicating a frequency field in their provate contexts, for example. It's hard to imaging how not using the cache today. Maybe I should make an example. For demod it should be trivial, but for tuner you must still pass frequency and bandwidth using cache as struct dvb_frontend_parameters was removed some time ago. What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface? I sent PATCH RFC for DVB API to add LNA support yesterday. It is new API Understood, thanks for the note. All in all, I would like to see kind of solution where every property is passed to the every driver: * bridge - set_property(FREQUENCY, 666555000) * tuner - set_property(FREQUENCY, 666555000) * demod - set_property(FREQUENCY, 666555000) and each driver then picks needed parameters. Likely it is still too much work without enough benefits to implement... regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dma-buf/fbdev: one-to-many support
Hi David, On Tuesday 17 July 2012 14:23:18 David Herrmann wrote: On Tue, Jul 17, 2012 at 1:24 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: The main issue is that fbdev has been designed with the implicit assumption that an fbdev driver will always own the graphics memory it uses. All components in the stack, from drivers to applications, have been designed around that assumption. We could of course fix this, revamp the fbdev API and turn it into a modern graphics API, but I really wonder whether it would be worth it. DRM has been getting quite a lot of attention lately, especially from embedded developers and vendors, and the trend seems to me like the (Linux) world will gradually move from fbdev to DRM. Please feel free to disagree :-) I would disagree on the main issue bit. All the graphics cards have their own formats and cache management rules. Simply sharing a buffer doesn't work - which is why all of the extra gloop will be needed. This is exactly why I suggested adding an owner field. A driver could then check whether the buffer it is supposed to share/takeover is from a compatible (or even the same) driver/device. If it is not, it would simply reject using the buffer. Then again, if we have multiple devices that are incompatible, we are still unable to share the buffer. So this attempt would only be useful if we have tons of DisplayLink devices attached that all use the same driver, for example. Regarding DRM: In user-space I prefer DRM over fbdev. With the introduction of the dumb-buffers there isn't even the need to have mesa installed. However, fblog runs in kernel space and currently cannot use DRM as there is no in-kernel DRM API. I looked at drm-fops.c whether it is easy to create a very simple in-kernel API but then I dropped the idea as this might be too complex for a simple debugging-only driver. Another attempt would be making the drm-fb-helper more generic so we can use this layer as in-kernel DRM API. I had a deeper look into this this weekend and so as a summary I think all in-kernel graphics access is probably not worth optimizing it. fbcon is already working great and fblog is only used during boot and oopses/panics and can be restricted to a single device. I will have another look at the drivers in a few weeks but if you tell me that this is not easy to implement, I will probably have to let this idea go. My gut feeling is that, given the effort required to add new APIs, it would be more interesting to work on an in-kernel DRM API to make drmcon and drmlog implementations possible without any fbdev compatibility layer. That's rather a long term goal though. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
