Re: [GIT PULL FOR v3.6] mostly remove V4L2_FL_LOCK_ALL_FOPS
On Wed July 4 2012 21:28:23 Sylwester Nawrocki wrote:
Hi Hans,
On 07/04/2012 07:42 PM, Hans Verkuil wrote:
Hi Mauro,
This pull request builds on (and includes) this core patch series:
http://patchwork.linuxtv.org/patch/13180/
It is identical to the RFC patch series I posted before:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg48184.html
...except that I dropped the patches touching s5p-fimc and fimc-lite and the
final patch removing the flag altogether.
Sylwester posted patches for those two drivers, but they won't apply.
Sylwester,
can you rebase those patches? Once I have those, then I can make another
pull
request that fixes those two drivers and removes the flag completely.
First of all, sorry about the trouble. These patches are available at:
git://git.infradead.org/users/kmpark/linux-samsung v4l-fimc-next
The first one was already included in a pull request with fixes for 3.5-rc:
http://patchwork.linuxtv.org/patch/13149. It is not really needed for
your V4L2_FL_LOCK_ALL_FOPS removal changeset. You only need the top one from
the above branch.
The reason why those 2 patches won't apply to the current media tree is
a pending fixups pull request from over a month ago -
http://patchwork.linuxtv.org/patch/11503. These are mostly important fixes
for new code that went into 3.5, and I'm really not happy they're still not
upstream :(
So I would propose you to merge v4l-fimc-fixes branch from
git://git.infradead.org/users/kmpark/linux-samsung, then there won't be
any merge conflicts.
Please feel free to add the top patch:
s5p-fimc: Remove V4L2_FL_LOCK_ALL_FOPS flag
to your pull request including the patch removing V4L2_FL_LOCK_ALL_FOPS.
Here is a gitweb link:
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/v4l-fimc-next
Hi Sylwester,
It still doesn't apply. This patch starts with:
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index da2c40e..cb04a870 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -480,48 +480,59 @@ static int fimc_capture_set_default_format(struct
fimc_dev *fimc);
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
- int ret;
+ int ret = -EBUSY;
The actual current source code starts with:
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
int ret = v4l2_fh_open(file);
Quite different. That 'int ret = v4l2_fh_open(file);' line was added June 10th,
2011, so
I don't understand why that isn't in your git repository.
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: [GIT PULL FOR v3.6] mostly remove V4L2_FL_LOCK_ALL_FOPS
Hi Hans,
On 07/05/2012 08:54 AM, Hans Verkuil wrote:
Hi Sylwester,
It still doesn't apply. This patch starts with:
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index da2c40e..cb04a870 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -480,48 +480,59 @@ static int fimc_capture_set_default_format(struct
fimc_dev *fimc);
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
- int ret;
+ int ret = -EBUSY;
The actual current source code starts with:
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
int ret = v4l2_fh_open(file);
Quite different. That 'int ret = v4l2_fh_open(file);' line was added June
10th, 2011, so
I don't understand why that isn't in your git repository.
Because is has been removed by one of patches from v4l-fimc-fixes branch
that I sent to Mauro on 25th of May and is still not upstream.
Branch v4l-fimc-next depends on v4l-fimc-fixes, sorry if it wasn't clear
enough. You need to pull v4l-fimc-fixes branch first. If I would have
rebased patches for -next then the fixup patches wouldn't apply. That
just doesn't seem right.
Mauro, are you going to send another pull request to Linus for 3.5-rc,
including these patches: http://patchwork.linuxtv.org/patch/11503 ?
Regards,
--
Sylwester Nawrocki
실베스터 나브로츠키
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.6] mostly remove V4L2_FL_LOCK_ALL_FOPS
On Thu 5 July 2012 10:28:50 Sylwester Nawrocki wrote:
Hi Hans,
On 07/05/2012 08:54 AM, Hans Verkuil wrote:
Hi Sylwester,
It still doesn't apply. This patch starts with:
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index da2c40e..cb04a870 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -480,48 +480,59 @@ static int fimc_capture_set_default_format(struct
fimc_dev *fimc);
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
- int ret;
+ int ret = -EBUSY;
The actual current source code starts with:
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
int ret = v4l2_fh_open(file);
Quite different. That 'int ret = v4l2_fh_open(file);' line was added June
10th, 2011, so
I don't understand why that isn't in your git repository.
Because is has been removed by one of patches from v4l-fimc-fixes branch
that I sent to Mauro on 25th of May and is still not upstream.
Branch v4l-fimc-next depends on v4l-fimc-fixes, sorry if it wasn't clear
enough. You need to pull v4l-fimc-fixes branch first. If I would have
rebased patches for -next then the fixup patches wouldn't apply. That
just doesn't seem right.
Ah, OK. Sorry, I misunderstood.
In that case I'll just wait for Mauro to pull in the fimc-fixes, and then
I'll make another pull request to get this last FOPS usage fixed. If I start
pulling in fixes trees as well, then that's going to be confusing.
It's OK to have a second pull request later to finalize this as there is no
urgency associated with these patches.
Regards,
Hans
Mauro, are you going to send another pull request to Linus for 3.5-rc,
including these patches: http://patchwork.linuxtv.org/patch/11503 ?
Regards,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [media] s5p-tv: Use module_i2c_driver in sii9234_drv.c file
Hi Sachin,
Thank you for the patch.
On 07/04/2012 08:33 AM, Sachin Kamat wrote:
module_i2c_driver makes the code simpler by eliminating module_init
and module_exit calls.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Acked-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/media/video/s5p-tv/sii9234_drv.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/s5p-tv/sii9234_drv.c
b/drivers/media/video/s5p-tv/sii9234_drv.c
index 0f31ecc..6d348f9 100644
--- a/drivers/media/video/s5p-tv/sii9234_drv.c
+++ b/drivers/media/video/s5p-tv/sii9234_drv.c
@@ -419,14 +419,4 @@ static struct i2c_driver sii9234_driver = {
.id_table = sii9234_id,
};
-static int __init sii9234_init(void)
-{
- return i2c_add_driver(sii9234_driver);
-}
-module_init(sii9234_init);
-
-static void __exit sii9234_exit(void)
-{
- i2c_del_driver(sii9234_driver);
-}
-module_exit(sii9234_exit);
+module_i2c_driver(sii9234_driver);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/01] Add new driver for generic scaler
This patch add support gscaler device which is a new device for scaling and color space conversion on EXYNOS5 SoCs. This device supports the followings as key feature. 1) Input image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, TILE 2) Output image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, YUV444 3) Input rotation - 0/90/180/270 degree, X/Y Flip 4) Scale ratio - 1/16 scale down to 8 scale up 5) CSC - RGB to YUV / YUV to RGB 6) Size - 2048 x 2048 for tile or rotation - 4800 x 3344 other case changes since v1: - Rebased on latest media-next tree http://linuxtv.org/git/mchehab/media-next.git - Addressed review comments from Sylwester Nawrocki http://patchwork.linuxtv.org/patch/9909/ - Removed gscaler capture, output and media device features from V1, as we have a plan to incremently add those gscaler features soon. - adds NV12 format support - adds custom controls specific to gscaler driver Shaik Ameer Basha (1): media: gscaler: Add new driver for generic scaler drivers/media/video/Kconfig | 10 + drivers/media/video/Makefile |1 + drivers/media/video/exynos/Kconfig| 11 + drivers/media/video/exynos/Makefile |1 + drivers/media/video/exynos/gsc/Kconfig|7 + drivers/media/video/exynos/gsc/Makefile |3 + drivers/media/video/exynos/gsc/gsc-core.c | 1304 + drivers/media/video/exynos/gsc/gsc-core.h | 652 ++ drivers/media/video/exynos/gsc/gsc-m2m.c | 751 + drivers/media/video/exynos/gsc/gsc-regs.c | 579 + drivers/media/video/exynos/gsc/gsc-regs.h | 211 + include/linux/videodev2.h |2 + 12 files changed, 3532 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/exynos/Kconfig create mode 100644 drivers/media/video/exynos/Makefile create mode 100644 drivers/media/video/exynos/gsc/Kconfig create mode 100644 drivers/media/video/exynos/gsc/Makefile create mode 100644 drivers/media/video/exynos/gsc/gsc-core.c create mode 100644 drivers/media/video/exynos/gsc/gsc-core.h create mode 100644 drivers/media/video/exynos/gsc/gsc-m2m.c create mode 100644 drivers/media/video/exynos/gsc/gsc-regs.c create mode 100644 drivers/media/video/exynos/gsc/gsc-regs.h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
From: Hans Verkuil hans.verk...@cisco.com
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..2c56cc6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2048,6 +2048,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_FREQ_BANDS 0x0400
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2066,19 +2067,34 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1_LANG20x0004
struct v4l2_frequency {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 frequency;
- __u32 reserved[8];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 frequency;
+ __u32 reserved[8];
+};
+
+#define V4L2_BAND_MODULATION_VSB (1 1)
+#define V4L2_BAND_MODULATION_FM(1 2)
+#define V4L2_BAND_MODULATION_AM(1 3)
+
+struct v4l2_frequency_band {
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 index;
+ __u32 capability;
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u32 modulation;
+ __u32 reserved[9];
};
struct v4l2_hw_freq_seek {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 seek_upward;
- __u32 wrap_around;
- __u32 spacing;
- __u32 reserved[7];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 seek_upward;
+ __u32 wrap_around;
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
@@ -2646,6 +2662,10 @@ struct v4l2_create_buffers {
#define VIDIOC_QUERY_DV_TIMINGS _IOR('V', 99, struct v4l2_dv_timings)
#define VIDIOC_DV_TIMINGS_CAP _IOWR('V', 100, struct v4l2_dv_timings_cap)
+/* Experimental, this ioctl may change over the next couple of kernel
+ versions. */
+#define VIDIOC_ENUM_FREQ_BANDS _IOWR('V', 101, struct v4l2_frequency_band)
+
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] v4l2 spec: add VIDIOC_ENUM_FREQ_BANDS documentation.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/compat.xml | 12 ++ Documentation/DocBook/media/v4l/v4l2.xml |6 + .../DocBook/media/v4l/vidioc-enum-freq-bands.xml | 179 .../DocBook/media/v4l/vidioc-g-frequency.xml |7 +- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 26 ++- 5 files changed, 221 insertions(+), 9 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index ea42ef8..2ec8000 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2458,6 +2458,15 @@ details./para /orderedlist /section +section + titleV4L2 in Linux 3.6/title + orderedlist +listitem + paraAdded support for frequency band enumerations: VIDIOC-ENUM-FREQ-BANDS;./para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title @@ -2587,6 +2596,9 @@ ioctls./para paralink linkend=v4l2-auto-focus-areaconstant V4L2_CID_AUTO_FOCUS_AREA/constant/link control./para /listitem +listitem + paraSupport for frequency band enumeration: VIDIOC-ENUM-FREQ-BANDS; ioctl./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 008c2d7..c6e307b 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -140,6 +140,11 @@ structs, ioctls) must be noted in more detail in the history chapter applications. -- revision + revnumber3.6/revnumber + date2012-07-02/date + authorinitialshv/authorinitials + revremarkAdded VIDIOC_ENUM_FREQ_BANDS. + /revremark revnumber3.5/revnumber date2012-05-07/date authorinitialssa, sn/authorinitials @@ -534,6 +539,7 @@ and discussions on the V4L mailing list./revremark sub-enum-fmt; sub-enum-framesizes; sub-enum-frameintervals; +sub-enum-freq-bands; sub-enuminput; sub-enumoutput; sub-enumstd; diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml new file mode 100644 index 000..6541ba0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -0,0 +1,179 @@ +refentry id=vidioc-enum-freq-bands + refmeta +refentrytitleioctl VIDIOC_ENUM_FREQ_BANDS/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_ENUM_FREQ_BANDS/refname +refpurposeEnumerate supported frequency bands/refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_frequency_band +*parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_ENUM_FREQ_BANDS/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +note + titleExperimental/title + paraThis is an link linkend=experimental experimental /link + interface and may change in the future./para +/note + +paraEnumerates the frequency bands that a tuner or modulator supports. +To do this applications initialize the structfieldtuner/structfield, +structfieldtype/structfield and structfieldindex/structfield fields, +and zero out the structfieldreserved/structfield array of a v4l2-frequency-band; and +call the constantVIDIOC_ENUM_FREQ_BANDS/constant ioctl with a pointer +to this structure./para + +paraThis ioctl is supported if the constantV4L2_TUNER_CAP_FREQ_BANDS/constant capability +of the corresponding tuner/modulator is set./para + +table pgwide=1 frame=none id=v4l2-frequency-band + titlestruct structnamev4l2_frequency_band/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldtuner/structfield/entry + entryThe tuner or modulator index number. This is the +same value as in the v4l2-input; structfieldtuner/structfield +field and the
[PATCH 5/6] radio-cadet: fix RDS handling.
From: Hans Verkuil hans.verk...@cisco.com
The current RDS code suffered from bit rot. Clean it up and make it work again.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-cadet.c | 56 ++---
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 93536b7..d1fb427 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -71,7 +71,7 @@ struct cadet {
int sigstrength;
wait_queue_head_t read_queue;
struct timer_list readtimer;
- __u8 rdsin, rdsout, rdsstat;
+ u8 rdsin, rdsout, rdsstat;
unsigned char rdsbuf[RDS_BUFFER];
struct mutex lock;
int reading;
@@ -85,8 +85,8 @@ static struct cadet cadet_card;
* strength value. These values are in microvolts of RF at the tuner's input.
*/
static __u16 sigtable[2][4] = {
- { 5, 10, 30, 150 },
- { 28, 40, 63, 1000 }
+ { 2185, 4369, 13107, 65535 },
+ { 1835, 2621, 4128, 65535 }
};
@@ -240,10 +240,13 @@ static void cadet_setfreq(struct cadet *dev, unsigned
freq)
cadet_gettune(dev);
if ((dev-tunestat 0x40) == 0) { /* Tuned */
dev-sigstrength = sigtable[dev-curtuner][j];
- return;
+ goto reset_rds;
}
}
dev-sigstrength = 0;
+reset_rds:
+ outb(3, dev-io);
+ outb(inb(dev-io + 1) 0x7f, dev-io + 1);
}
@@ -259,7 +262,7 @@ static void cadet_handler(unsigned long data)
outb(0x80, dev-io); /* Select RDS fifo */
while ((inb(dev-io) 0x80) != 0) {
dev-rdsbuf[dev-rdsin] = inb(dev-io + 1);
- if (dev-rdsin == dev-rdsout)
+ if (dev-rdsin + 1 == dev-rdsout)
printk(KERN_WARNING cadet: RDS buffer
overflow\n);
else
dev-rdsin++;
@@ -278,11 +281,21 @@ static void cadet_handler(unsigned long data)
*/
init_timer(dev-readtimer);
dev-readtimer.function = cadet_handler;
- dev-readtimer.data = (unsigned long)0;
+ dev-readtimer.data = data;
dev-readtimer.expires = jiffies + msecs_to_jiffies(50);
add_timer(dev-readtimer);
}
+static void cadet_start_rds(struct cadet *dev)
+{
+ dev-rdsstat = 1;
+ outb(0x80, dev-io);/* Select RDS fifo */
+ init_timer(dev-readtimer);
+ dev-readtimer.function = cadet_handler;
+ dev-readtimer.data = (unsigned long)dev;
+ dev-readtimer.expires = jiffies + msecs_to_jiffies(50);
+ add_timer(dev-readtimer);
+}
static ssize_t cadet_read(struct file *file, char __user *data, size_t count,
loff_t *ppos)
{
@@ -291,26 +304,21 @@ static ssize_t cadet_read(struct file *file, char __user
*data, size_t count, lo
int i = 0;
mutex_lock(dev-lock);
- if (dev-rdsstat == 0) {
- dev-rdsstat = 1;
- outb(0x80, dev-io);/* Select RDS fifo */
- init_timer(dev-readtimer);
- dev-readtimer.function = cadet_handler;
- dev-readtimer.data = (unsigned long)dev;
- dev-readtimer.expires = jiffies + msecs_to_jiffies(50);
- add_timer(dev-readtimer);
- }
+ if (dev-rdsstat == 0)
+ cadet_start_rds(dev);
if (dev-rdsin == dev-rdsout) {
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
+ mutex_unlock(dev-lock);
interruptible_sleep_on(dev-read_queue);
+ mutex_lock(dev-lock);
}
while (i count dev-rdsin != dev-rdsout)
readbuf[i++] = dev-rdsbuf[dev-rdsout++];
- if (copy_to_user(data, readbuf, i))
+ if (i copy_to_user(data, readbuf, i))
i = -EFAULT;
unlock:
mutex_unlock(dev-lock);
@@ -345,7 +353,12 @@ static int vidioc_g_tuner(struct file *file, void *priv,
v-rangehigh = 1728000;/* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
v-audmode = V4L2_TUNER_MODE_STEREO;
- v-rxsubchans |= V4L2_TUNER_SUB_RDS;
+ outb(3, dev-io);
+ outb(inb(dev-io + 1) 0x7f, dev-io + 1);
+ mdelay(100);
+ outb(3, dev-io);
+ if (inb(dev-io + 1) 0x80)
+ v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
@@ -455,9 +468,16 @@ static int cadet_release(struct file *file)
static unsigned int cadet_poll(struct file *file, struct poll_table_struct
*wait)
{
struct cadet *dev = video_drvdata(file);
+ unsigned
[PATCH 2/6] v4l2: add core support for the new VIDIOC_ENUM_FREQ_BANDS ioctl.
From: Hans Verkuil hans.verk...@cisco.com
This adds the usual core support code for this new ioctl.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-dev.c|2 +
drivers/media/video/v4l2-ioctl.c | 88 -
include/media/v4l2-ioctl.h|2 +
4 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 5327ad3..81e5129 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1026,6 +1026,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_ENUM_DV_TIMINGS:
case VIDIOC_QUERY_DV_TIMINGS:
case VIDIOC_DV_TIMINGS_CAP:
+ case VIDIOC_ENUM_FREQ_BANDS:
ret = do_video_ioctl(file, cmd, arg);
break;
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index d13c47f..ca7ade4 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -728,6 +728,8 @@ static void determine_valid_ioctls(struct video_device
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_UNSUBSCRIBE_EVENT,
vidioc_unsubscribe_event);
SET_VALID_IOCTL(ops, VIDIOC_CREATE_BUFS, vidioc_create_bufs);
SET_VALID_IOCTL(ops, VIDIOC_PREPARE_BUF, vidioc_prepare_buf);
+ if (ops-vidioc_enum_freq_bands || ops-vidioc_g_tuner ||
ops-vidioc_g_modulator)
+ set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
bitmap_andnot(vdev-valid_ioctls, valid_ioctls, vdev-valid_ioctls,
BASE_VIDIOC_PRIVATE);
}
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 70e0efb..675d8a4 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -825,6 +825,17 @@ static void v4l_print_sliced_vbi_cap(const void *arg, bool
write_only)
p-service_lines[1][i]);
}
+static void v4l_print_freq_band(const void *arg, bool write_only)
+{
+ const struct v4l2_frequency_band *p = arg;
+
+ pr_cont(tuner=%u, type=%u, index=%u, capability=0x%x,
+ rangelow=%u, rangehigh=%u, modulation=0x%x\n,
+ p-tuner, p-type, p-index,
+ p-capability, p-rangelow,
+ p-rangehigh, p-modulation);
+}
+
static void v4l_print_u32(const void *arg, bool write_only)
{
pr_cont(value=%u\n, *(const u32 *)arg);
@@ -1245,10 +1256,14 @@ static int v4l_g_tuner(const struct v4l2_ioctl_ops *ops,
{
struct video_device *vfd = video_devdata(file);
struct v4l2_tuner *p = arg;
+ int err;
p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
- return ops-vidioc_g_tuner(file, fh, p);
+ err = ops-vidioc_g_tuner(file, fh, p);
+ if (!err)
+ p-capability |= V4L2_TUNER_CAP_FREQ_BANDS;
+ return err;
}
static int v4l_s_tuner(const struct v4l2_ioctl_ops *ops,
@@ -1262,6 +1277,18 @@ static int v4l_s_tuner(const struct v4l2_ioctl_ops *ops,
return ops-vidioc_s_tuner(file, fh, p);
}
+static int v4l_g_modulator(const struct v4l2_ioctl_ops *ops,
+ struct file *file, void *fh, void *arg)
+{
+ struct v4l2_modulator *p = arg;
+ int err;
+
+ err = ops-vidioc_g_modulator(file, fh, p);
+ if (!err)
+ p-capability |= V4L2_TUNER_CAP_FREQ_BANDS;
+ return err;
+}
+
static int v4l_g_frequency(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
{
@@ -1798,6 +1825,62 @@ static int v4l_g_sliced_vbi_cap(const struct
v4l2_ioctl_ops *ops,
return ops-vidioc_g_sliced_vbi_cap(file, fh, p);
}
+static int v4l_enum_freq_bands(const struct v4l2_ioctl_ops *ops,
+ struct file *file, void *fh, void *arg)
+{
+ struct video_device *vfd = video_devdata(file);
+ struct v4l2_frequency_band *p = arg;
+ enum v4l2_tuner_type type;
+ int err;
+
+ type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+
+ if (type != p-type)
+ return -EINVAL;
+ if (ops-vidioc_enum_freq_bands)
+ return ops-vidioc_enum_freq_bands(file, fh, p);
+
+ /* There is only one frequency band */
+ if (p-index)
+ return -EINVAL;
+ if (ops-vidioc_g_tuner) {
+ struct v4l2_tuner t = {
+ .index = p-tuner,
+ .type = type,
+ };
+
+ err = ops-vidioc_g_tuner(file, fh, t);
+ if (err)
+ return err;
+ p-capability = t.capability |
[PATCH 6/6] radio-cadet: implement frequency band enumeration.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-cadet.c | 129 +
1 file changed, 72 insertions(+), 57 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index d1fb427..18b8c71 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -66,7 +66,8 @@ struct cadet {
struct video_device vdev;
struct v4l2_ctrl_handler ctrl_handler;
int io;
- int curtuner;
+ bool is_fm_band;
+ u32 curfreq;
int tunestat;
int sigstrength;
wait_queue_head_t read_queue;
@@ -84,9 +85,9 @@ static struct cadet cadet_card;
* The V4L API spec does not define any particular unit for the signal
* strength value. These values are in microvolts of RF at the tuner's input.
*/
-static __u16 sigtable[2][4] = {
+static u16 sigtable[2][4] = {
+ { 1835, 2621, 4128, 65535 },
{ 2185, 4369, 13107, 65535 },
- { 1835, 2621, 4128, 65535 }
};
@@ -94,7 +95,7 @@ static int cadet_getstereo(struct cadet *dev)
{
int ret = V4L2_TUNER_SUB_MONO;
- if (dev-curtuner != 0) /* Only FM has stereo capability! */
+ if (!dev-is_fm_band) /* Only FM has stereo capability! */
return V4L2_TUNER_SUB_MONO;
outb(7, dev-io); /* Select tuner control */
@@ -149,20 +150,18 @@ static unsigned cadet_getfreq(struct cadet *dev)
/*
* Convert to actual frequency
*/
- if (dev-curtuner == 0) {/* FM */
- test = 12500;
- for (i = 0; i 14; i++) {
- if ((fifo 0x01) != 0)
- freq += test;
- test = test 1;
- fifo = fifo 1;
- }
- freq -= 1070; /* IF frequency is 10.7 MHz */
- freq = (freq * 16) / 1000; /* Make it 1/16 kHz */
+ if (!dev-is_fm_band)/* AM */
+ return ((fifo 0x7fff) - 450) * 16;
+
+ test = 12500;
+ for (i = 0; i 14; i++) {
+ if ((fifo 0x01) != 0)
+ freq += test;
+ test = test 1;
+ fifo = fifo 1;
}
- if (dev-curtuner == 1)/* AM */
- freq = ((fifo 0x7fff) - 2010) * 16;
-
+ freq -= 1070; /* IF frequency is 10.7 MHz */
+ freq = (freq * 16) / 1000; /* Make it 1/16 kHz */
return freq;
}
@@ -197,11 +196,12 @@ static void cadet_setfreq(struct cadet *dev, unsigned
freq)
int i, j, test;
int curvol;
+ dev-curfreq = freq;
/*
* Formulate a fifo command
*/
fifo = 0;
- if (dev-curtuner == 0) {/* FM */
+ if (dev-is_fm_band) {/* FM */
test = 102400;
freq = freq / 16; /* Make it kHz */
freq += 10700; /* IF is 10700 kHz */
@@ -213,10 +213,9 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
}
test = test 1;
}
- }
- if (dev-curtuner == 1) {/* AM */
- fifo = (freq / 16) + 2010;/* Make it kHz */
- fifo |= 0x10;/* Select AM Band */
+ } else {/* AM */
+ fifo = (freq / 16) + 450; /* Make it kHz */
+ fifo |= 0x10; /* Select AM Band */
}
/*
@@ -239,7 +238,7 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
cadet_gettune(dev);
if ((dev-tunestat 0x40) == 0) { /* Tuned */
- dev-sigstrength = sigtable[dev-curtuner][j];
+ dev-sigstrength = sigtable[dev-is_fm_band][j];
goto reset_rds;
}
}
@@ -338,39 +337,50 @@ static int vidioc_querycap(struct file *file, void *priv,
return 0;
}
+static const struct v4l2_frequency_band bands[] = {
+ {
+ .index = 0,
+ .name = AM MW,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 8320, /* 520 kHz */
+ .rangehigh = 26400,/* 1650 kHz */
+ }, {
+ .index = 1,
+ .name = FM,
+ .capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
+ V4L2_TUNER_CAP_RDS_BLOCK_IO | V4L2_TUNER_CAP_LOW |
+ V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 140, /* 87.5 MHz */
+ .rangehigh = 1728000, /* 108.0 MHz */
+ },
+};
+
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
+ if (v-index)
+
[PATCH 4/6] radio-cadet: upgrade to latest frameworks.
From: Hans Verkuil hans.verk...@cisco.com
- add control framework
- use core locking
- use V4L2_TUNER_CAP_LOW
- remove volume support: there is no hardware volume control
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-cadet.c | 243 +
1 file changed, 83 insertions(+), 160 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 16a089f..93536b7 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -41,6 +41,9 @@
#include linux/io.h /* outb, outb_p */
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
MODULE_AUTHOR(Fred Gleason, Russell Kroll, Quay Lu, Donald Song, Jason Lewis,
Scott McGrath, William McGrath);
MODULE_DESCRIPTION(A driver for the ADS Cadet AM/FM/RDS radio card.);
@@ -61,8 +64,8 @@ module_param(radio_nr, int, 0);
struct cadet {
struct v4l2_device v4l2_dev;
struct video_device vdev;
+ struct v4l2_ctrl_handler ctrl_handler;
int io;
- int users;
int curtuner;
int tunestat;
int sigstrength;
@@ -94,11 +97,9 @@ static int cadet_getstereo(struct cadet *dev)
if (dev-curtuner != 0) /* Only FM has stereo capability! */
return V4L2_TUNER_SUB_MONO;
- mutex_lock(dev-lock);
outb(7, dev-io); /* Select tuner control */
if ((inb(dev-io + 1) 0x40) == 0)
ret = V4L2_TUNER_SUB_STEREO;
- mutex_unlock(dev-lock);
return ret;
}
@@ -111,8 +112,6 @@ static unsigned cadet_gettune(struct cadet *dev)
* Prepare for read
*/
- mutex_lock(dev-lock);
-
outb(7, dev-io); /* Select tuner control */
curvol = inb(dev-io + 1); /* Save current volume/mute setting */
outb(0x00, dev-io + 1); /* Ensure WRITE-ENABLE is LOW */
@@ -134,8 +133,6 @@ static unsigned cadet_gettune(struct cadet *dev)
* Restore volume/mute setting
*/
outb(curvol, dev-io + 1);
- mutex_unlock(dev-lock);
-
return fifo;
}
@@ -161,7 +158,7 @@ static unsigned cadet_getfreq(struct cadet *dev)
fifo = fifo 1;
}
freq -= 1070; /* IF frequency is 10.7 MHz */
- freq = (freq * 16) / 100; /* Make it 1/16 MHz */
+ freq = (freq * 16) / 1000; /* Make it 1/16 kHz */
}
if (dev-curtuner == 1)/* AM */
freq = ((fifo 0x7fff) - 2010) * 16;
@@ -174,8 +171,6 @@ static void cadet_settune(struct cadet *dev, unsigned fifo)
int i;
unsigned test;
- mutex_lock(dev-lock);
-
outb(7, dev-io);/* Select tuner control */
/*
* Write the shift register
@@ -194,7 +189,6 @@ static void cadet_settune(struct cadet *dev, unsigned fifo)
test = 0x1c | ((fifo 23) 0x02);
outb(test, dev-io + 1);
}
- mutex_unlock(dev-lock);
}
static void cadet_setfreq(struct cadet *dev, unsigned freq)
@@ -209,7 +203,7 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
fifo = 0;
if (dev-curtuner == 0) {/* FM */
test = 102400;
- freq = (freq * 1000) / 16; /* Make it kHz */
+ freq = freq / 16; /* Make it kHz */
freq += 10700; /* IF is 10700 kHz */
for (i = 0; i 14; i++) {
fifo = fifo 1;
@@ -229,10 +223,8 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
* Save current volume/mute setting
*/
- mutex_lock(dev-lock);
outb(7, dev-io);/* Select tuner control */
curvol = inb(dev-io + 1);
- mutex_unlock(dev-lock);
/*
* Tune the card
@@ -240,10 +232,8 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
for (j = 3; j -1; j--) {
cadet_settune(dev, fifo | (j 16));
- mutex_lock(dev-lock);
outb(7, dev-io); /* Select tuner control */
outb(curvol, dev-io + 1);
- mutex_unlock(dev-lock);
msleep(100);
@@ -257,32 +247,6 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
}
-static int cadet_getvol(struct cadet *dev)
-{
- int ret = 0;
-
- mutex_lock(dev-lock);
-
- outb(7, dev-io);/* Select tuner control */
- if ((inb(dev-io + 1) 0x20) != 0)
- ret = 0x;
-
- mutex_unlock(dev-lock);
- return ret;
-}
-
-
-static void cadet_setvol(struct cadet *dev, int vol)
-{
- mutex_lock(dev-lock);
- outb(7, dev-io);/* Select tuner control */
- if (vol 0)
- outb(0x20, dev-io + 1);
-
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
Hi David, The in-kernel RC6 decoder already has margins of around 50% for most pulse/spaces (i.e. 444us +/- 222us). Changing the sample resolution from 10 to 6 us should have little to no effect on the RC6 decoding (also, the Windows driver uses a 50us resolution IIRC). Do you have a log of a successful and unsuccesful event (the timings that is)? I had a closer look. I dumped the RC6 debug, but I also printed the raw data in the interrupt handler: printk(%x %d %d\n, irdata, rawir.pulse, rawir.duration); A successful event begins with: 7f 1 127 7f 1 127 8 1 8 db 0 91 27 1 39 b3 0 51 26 1 38 b0 0 48 ir_rc6_decode: RC6 decode started at state 0 (2620us pulse) ir_rc6_decode: RC6 decode started at state 1 (910us space) ir_rc6_decode: RC6 decode started at state 2 (390us pulse) ir_rc6_decode: RC6 decode started at state 3 (510us space) ir_rc6_decode: RC6 decode started at state 2 (66us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) 26 1 38 db 0 91 26 1 38 dd 0 93 7d 1 125--- dd 0 93 25 1 37 b4 0 52 ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (910us space) ir_rc6_decode: RC6 decode started at state 2 (466us space) ir_rc6_decode: RC6 decode started at state 3 (380us pulse) ir_rc6_decode: RC6 decode started at state 4 (0us pulse) ir_rc6_decode: RC6 decode started at state 4 (930us space) ir_rc6_decode: RC6 decode started at state 5 (1250us pulse) ir_rc6_decode: RC6 decode started at state 6 (361us pulse) ir_rc6_decode: RC6 decode started at state 7 (930us space) Now compare to an unsuccesful event, in particular the byte I have tagged in both traces: 7f 1 127 7f 1 127 2 1 2 df 0 95 26 1 38 b0 0 48 26 1 38 b0 0 48 26 1 38 dc 0 92 26 1 38 ir_rc6_decode: RC6 decode started at state 0 (2560us pulse) ir_rc6_decode: RC6 decode started at state 1 (950us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (920us space) ir_rc6_decode: RC6 decode started at state 2 (476us space) dc 0 92 ff 0 127 de 0 94 25 1 37 b1 0 49 26 1 38 b0 0 48 26 1 38 ir_rc6_decode: RC6 decode started at state 3 (380us pulse) ir_rc6_decode: RC6 decode started at state 4 (0us pulse) ir_rc6_decode: RC6 decode started at state 4 (3130us space) ir_rc6_decode: RC6 decode failed at state 4 (3130us space) That should have been a pulse but it came out as a space. This makes me wonder if there is an issue with the run length encoding, perhaps when a pulse is the right size to just saturate it. It does seem like we set the top bit even though we should not have. If true we could choose any sample rate that avoids it. Anton -- 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
omap3isp: cropping bug in previewer?
Dear all,
I am trying to get a mt9p031 sensor running on a beagleboard-xm with the
following configuration:
Hardware:
- beagleboard-xm, rev c1
- Leopard Imaging cam module LI-5M03 with a mt9p031 5MP sensor
Software:
- Angstrom-distro built with bitbake using the setup-scripts from [4] (commit
da56a56b690bcc07a50716f1071e90e2b3a4fb47).
- own bitbake recipe to build a linux-omap kernel 3.5-rc1 from the tmdlind
branch (this source: [5], tag omap-fixes-for-v3.5-rc1)
- some patches to update the 3.5-rc1 omap3-isp module (not the whole kernel) to
the latest omap3isp-sensors-next branch from Laurent Pinchart [1]
- yavta with an extension to output data to stdout
- mediactl to configure the omap3isp pipeline
Problem:
I configure a pipe with mediactl from OMAP3 ISP CCDC input to the previewer
output (see [3] for a detailed log) with an example resolution of 800x600. This
resolution is adapted by the omap3isp driver to 846x639 at the previewer
output. In my understanding the adjustment of the resolution (from 800x600 to
846x639) is a result of the following process:
1) The closest possible windowing of the mt9p031 sensor is 864x648.
2) The ccdc-source pad crops the height by one line (see function
ccdc_try_format in ispccdc.c) - we are now on 864x647
3) The previewer (isppreview.c) crops a left margin of 8px and a right margin
of 6px (see the PREV_MARGIN_* defines) plus 4px if the input is from ccdc (see
preview_try_crop) - we are now on 846x639.
As there are no filters activated, the input size will not be modified by the
preview_config_input_size function.
When I now capture a frame with yavta (see [3] for details), I must use 846x639
as frame size (as this size is reported by the driver). But it seems that the
outputted image is 2px wider (that means 848x639). This results in a
scrambled/unusable image on screen when streaming (see [6]
bad-frame-846x639_on_display.bmp for an example how it looks like on screen).
Also the file size too big for a 846x639 image:
The frame size is 1083744 bytes, which is exactly 848*639*2 (NOT 846*639*2)!
Then I transformed the bad yuv-picture with raw2rgbpnm which gives me a good
picture with both frame-sizes (see bad-frame-846x639.pnm and
bad-frame-848x639_on_display.bmp in [6]).
So the picture-information seems to be good, but I guess that the input-size is
configured badly by the driver.
If you look in the isp-datasheet [7] in table 6-40 (page 1201) you see, that
the CFA interpolation block for bayer-mode crops 4 px per line and 4 lines.
So shouldn't we respect this in the preview_config_input_size function?
My RFC is:
Index: git/drivers/media/video/omap3isp/isppreview.c
===
--- git.orig/drivers/media/video/omap3isp/isppreview.c 2012-07-05
10:59:33.675358396 +0200
+++ git/drivers/media/video/omap3isp/isppreview.c 2012-07-05
12:14:33.723223514 +0200
@@ -1140,6 +1140,12 @@
}
if (features (OMAP3ISP_PREV_CHROMA_SUPP | OMAP3ISP_PREV_LUMAENH))
sph -= 2;
+ if (features OMAP3ISP_PREV_CFA) {
+ sph -= 2;
+ eph += 2;
+ slv -= 2;
+ elv += 2;
+ }
isp_reg_writel(isp, (sph ISPPRV_HORZ_INFO_SPH_SHIFT) | eph,
OMAP3_ISP_IOMEM_PREV, ISPPRV_HORZ_INFO);
===
NOTE: This still gives an unusable picture at the previewer output BUT if I
extend the pipeline to the resizer output, the picture is good. So I must be
missing something...
It would be nice, if someone could tell me, if my assumptions are right and
point me the right direction.
Further information:
- Bootup dmesg: [2]
- Configuration of the pipe with mediactl, capturing of an image with yavta and
analyze of the image with raw2rgbpnm: [3]
[1]
http://git.linuxtv.org/pinchartl/media.git/commit/019214973ee4f03c8f2d582468b914fcf3385089
[2] http://pastebin.com/7PQnzcmx
[3] http://pastebin.com/ChEaYHMy
[4] https://github.com/Angstrom-distribution/setup-scripts
[5] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
[6] https://www.dropbox.com/sh/p2fy5u4i71c3vy8/Fyya25YqK-
[7] http://www.ti.com/lit/ug/sprugn4q/sprugn4q.pdf
Greetings,
Florian Neuhaus
--
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: omap3isp: cropping bug in previewer?
Hi Florian,
On Thursday 05 July 2012 12:28:04 Florian Neuhaus wrote:
Dear all,
I am trying to get a mt9p031 sensor running on a beagleboard-xm with the
following configuration:
Hardware:
- beagleboard-xm, rev c1
- Leopard Imaging cam module LI-5M03 with a mt9p031 5MP sensor
Software:
- Angstrom-distro built with bitbake using the setup-scripts from [4]
(commit da56a56b690bcc07a50716f1071e90e2b3a4fb47). - own bitbake recipe to
build a linux-omap kernel 3.5-rc1 from the tmdlind branch (this source:
[5], tag omap-fixes-for-v3.5-rc1) - some patches to update the 3.5-rc1
omap3-isp module (not the whole kernel) to the latest omap3isp-sensors-next
branch from Laurent Pinchart [1] - yavta with an extension to output data
to stdout
- mediactl to configure the omap3isp pipeline
Problem:
I configure a pipe with mediactl from OMAP3 ISP CCDC input to the previewer
output (see [3] for a detailed log) with an example resolution of 800x600.
This resolution is adapted by the omap3isp driver to 846x639 at the
previewer output. In my understanding the adjustment of the resolution
(from 800x600 to 846x639) is a result of the following process: 1) The
closest possible windowing of the mt9p031 sensor is 864x648. 2) The
ccdc-source pad crops the height by one line (see function ccdc_try_format
in ispccdc.c) - we are now on 864x647 3) The previewer (isppreview.c) crops
a left margin of 8px and a right margin of 6px (see the PREV_MARGIN_*
defines) plus 4px if the input is from ccdc (see preview_try_crop) - we are
now on 846x639. As there are no filters activated, the input size will not
be modified by the preview_config_input_size function.
When I now capture a frame with yavta (see [3] for details), I must use
846x639 as frame size (as this size is reported by the driver). But it
seems that the outputted image is 2px wider (that means 848x639). This
results in a scrambled/unusable image on screen when streaming (see [6]
bad-frame-846x639_on_display.bmp for an example how it looks like on
screen). Also the file size too big for a 846x639 image: The frame size is
1083744 bytes, which is exactly 848*639*2 (NOT 846*639*2)!
The OMAP3 ISP pads lines to multiples of 32 or 64 bytes when reading
from/writing to memory. 846 pixels * 2 bytes per pixel is not a multiple of 32
bytes, so the line length gets padded to the next multiple, 848 pixels in this
case. The information is reported by the bytesperline field of the
v4l2_pix_format structure returned by VIDIOC_G_FMT and VIDIOC_S_FMT on the
preview engine output video node. You need to take the padding into account in
your application, that should solve your issue. raw2rgbpnm tries to detect
padding at the end of lines, and skips it automatically.
Then I transformed the bad yuv-picture with raw2rgbpnm which gives me a
good picture with both frame-sizes (see bad-frame-846x639.pnm and
bad-frame-848x639_on_display.bmp in [6]). So the picture-information seems
to be good, but I guess that the input-size is configured badly by the
driver. If you look in the isp-datasheet [7] in table 6-40 (page 1201) you
see, that the CFA interpolation block for bayer-mode crops 4 px per line
and 4 lines. So shouldn't we respect this in the preview_config_input_size
function? My RFC is:
Index: git/drivers/media/video/omap3isp/isppreview.c
===
--- git.orig/drivers/media/video/omap3isp/isppreview.c2012-07-05
10:59:33.675358396 +0200 +++
git/drivers/media/video/omap3isp/isppreview.c 2012-07-05
12:14:33.723223514
+0200 @@ -1140,6 +1140,12 @@
}
if (features (OMAP3ISP_PREV_CHROMA_SUPP | OMAP3ISP_PREV_LUMAENH))
sph -= 2;
+ if (features OMAP3ISP_PREV_CFA) {
+ sph -= 2;
+ eph += 2;
+ slv -= 2;
+ elv += 2;
+ }
isp_reg_writel(isp, (sph ISPPRV_HORZ_INFO_SPH_SHIFT) | eph,
OMAP3_ISP_IOMEM_PREV, ISPPRV_HORZ_INFO);
===
NOTE: This still gives an unusable picture at the previewer output BUT if I
extend the pipeline to the resizer output, the picture is good. So I must
be missing something...
It would be nice, if someone could tell me, if my assumptions are right and
point me the right direction.
Further information:
- Bootup dmesg: [2]
- Configuration of the pipe with mediactl, capturing of an image with yavta
and analyze of the image with raw2rgbpnm: [3]
[1]
http://git.linuxtv.org/pinchartl/media.git/commit/019214973ee4f03c8f2d58246
8b914fcf3385089 [2] http://pastebin.com/7PQnzcmx
[3] http://pastebin.com/ChEaYHMy
[4] https://github.com/Angstrom-distribution/setup-scripts
[5] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
[6] https://www.dropbox.com/sh/p2fy5u4i71c3vy8/Fyya25YqK-
[7] http://www.ti.com/lit/ug/sprugn4q/sprugn4q.pdf
--
Regards,
Laurent
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
hi Anton, it's very debatable that is fault of the Linux driver(s) and let me elaborate why i think so: i have Logitech Harmony 890 remote and MCE USB IR receiver that is supported by 'mceusb.c' in Linux, i.e. it's different than your IR receiver, but yet the work is very unstable together with my Harmony no matter what type of pulses are used, e.g. RC5, RC6 or NEC. however, that is true only if default setting for the Harmony are set in the Logitech software for Windows that i used to initially setup the remote. so, if in Logitech Harmony Remote Software (7.7.0) for Windows go to: Devices - Settings - select 'Troubleshoot' - click 'Next' - select '...responds to some commands either too many times or only occasionally' - click 'Next' then you're given the option to choose number from 0 to 5 with the following explanation by Logitech: If your device responds too slowly, or not at all when you press a button on the remote, increase the value to 4 or 5. If your device responds too quickly, lower the value to 2, 1 or 0. there are no any details about what actually that setting is doing to the Harmony firmware and in fact i found that neither the default value, nor Logitech suggestion what value to choose in which case are good, but using value of 2 fixed all the issues with my MCE USB IR receiver in Linux - totally stable and proper work. in short i think the problem is created from Harmony firmware and the proper solution is to just play with those numbers in Logitech software until you find the setting with which you get stable work. of course, someone more interested than i'm in this could do further investigation and understand the root cause of the issue and what changes in how Harmony firmware behaves based on those settings Logitech offered in their software, but my point is that i have similar issue with RC5 pulses, Harmony 890 and MCE USB IR receiver that is supported by 'mceusb.c' or quite different setup than yours and the fix i found is from Logitech side and the fact Logitech offered such setting suggests that the proper way to fix it. best regards, konstantin On Thu, Jul 5, 2012 at 1:30 PM, Anton Blanchard an...@samba.org wrote: Hi David, The in-kernel RC6 decoder already has margins of around 50% for most pulse/spaces (i.e. 444us +/- 222us). Changing the sample resolution from 10 to 6 us should have little to no effect on the RC6 decoding (also, the Windows driver uses a 50us resolution IIRC). Do you have a log of a successful and unsuccesful event (the timings that is)? I had a closer look. I dumped the RC6 debug, but I also printed the raw data in the interrupt handler: printk(%x %d %d\n, irdata, rawir.pulse, rawir.duration); A successful event begins with: 7f 1 127 7f 1 127 8 1 8 db 0 91 27 1 39 b3 0 51 26 1 38 b0 0 48 ir_rc6_decode: RC6 decode started at state 0 (2620us pulse) ir_rc6_decode: RC6 decode started at state 1 (910us space) ir_rc6_decode: RC6 decode started at state 2 (390us pulse) ir_rc6_decode: RC6 decode started at state 3 (510us space) ir_rc6_decode: RC6 decode started at state 2 (66us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) 26 1 38 db 0 91 26 1 38 dd 0 93 7d 1 125--- dd 0 93 25 1 37 b4 0 52 ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (910us space) ir_rc6_decode: RC6 decode started at state 2 (466us space) ir_rc6_decode: RC6 decode started at state 3 (380us pulse) ir_rc6_decode: RC6 decode started at state 4 (0us pulse) ir_rc6_decode: RC6 decode started at state 4 (930us space) ir_rc6_decode: RC6 decode started at state 5 (1250us pulse) ir_rc6_decode: RC6 decode started at state 6 (361us pulse) ir_rc6_decode: RC6 decode started at state 7 (930us space) Now compare to an unsuccesful event, in particular the byte I have tagged in both traces: 7f 1 127 7f 1 127 2 1 2 df 0 95 26 1 38 b0 0 48 26 1 38 b0 0 48 26 1 38 dc 0 92 26 1 38 ir_rc6_decode: RC6 decode started at state 0 (2560us pulse) ir_rc6_decode: RC6 decode started at state 1 (950us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (480us space) ir_rc6_decode: RC6 decode started at state 2 (36us space) ir_rc6_decode: RC6 decode started at state 2 (380us pulse) ir_rc6_decode: RC6 decode started at state 3 (920us space) ir_rc6_decode: RC6 decode started at state 2 (476us space) dc 0 92 ff 0 127 de 0 94 25 1 37 b1 0 49 26 1 38 b0 0
Re: [PATCH 0/6] Add frequency band information
Series looks good to me, ack series: Acked-by: Hans de Goede hdego...@redhat.com On 07/05/2012 12:25 PM, Hans Verkuil wrote: Hi Mauro, This should be the final patch series for adding multiband support to the kernel. This patch series assumes that this pull request was merged first: http://patchwork.linuxtv.org/patch/13180/ Changes since the previous RFC patch series: (See http://www.mail-archive.com/linux-media@vger.kernel.org/msg48549.html) - The name field was dropped. - A new modulation field was added that describes the possible modulation systems for that frequency band (currently only one modulation system can be supported per band). - Compat code was added to allow VIDIOC_ENUM_FREQ_BANDS to be used for existing drivers. A note regarding the cadet driver: I want to do a follow-up patch to this at a later date so that it uses the tea575x-tuner framework. But with these patches it will at least work correctly again. 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: [PATCH 4/4] radio-si470x: Lower firmware version requirements
On 07/05/2012 11:33 AM, Hans de Goede wrote:
Hi,
On 07/04/2012 05:23 PM, Antti Palosaari wrote:
On 06/14/2012 04:43 PM, Hans de Goede wrote:
With the changes from the previous patches device firmware version 14 +
usb microcontroller software version 1 works fine too.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/media/radio/si470x/radio-si470x-usb.c |2 +-
drivers/media/radio/si470x/radio-si470x.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c
b/drivers/media/radio/si470x/radio-si470x-usb.c
index 66b1ba8..40b963c 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -143,7 +143,7 @@ MODULE_PARM_DESC(max_rds_errors, RDS maximum
block errors: *1*);
* Software/Hardware Versions from Scratch Page
**/
#define RADIO_SW_VERSION_NOT_BOOTLOADABLE6
-#define RADIO_SW_VERSION7
+#define RADIO_SW_VERSION1
#define RADIO_HW_VERSION1
diff --git a/drivers/media/radio/si470x/radio-si470x.h
b/drivers/media/radio/si470x/radio-si470x.h
index fbf713d..b3b612f 100644
--- a/drivers/media/radio/si470x/radio-si470x.h
+++ b/drivers/media/radio/si470x/radio-si470x.h
@@ -189,7 +189,7 @@ struct si470x_device {
* Firmware Versions
**/
-#define RADIO_FW_VERSION15
+#define RADIO_FW_VERSION14
I just found out this patch serie and tested it - but no luck. Could
you say if I do something wrong or is it due to my device firmware
version?
I believe you're doing something wrong ...
I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and
arecord -r96000 -c2 -f S16_LE | aplay - to play sound. Just
silent white noise is heard.
You're not specifying which device arecord should record from so likely
it is taking
the default input of your soundcard (line/mic in), rather then recording
from the
radio device.
I tried to define hw:1,0 etc. but only hw:0,0 exists.
Note the latest radio from http://git.linuxtv.org/xawtv3.git will do the
digital loopback of
the sound itself, so try things again with running arecord / aplay, if
you then start radio
and exit again (so that you can see its startup messages) you should see
something like this:
Using alsa loopback: cap: hw:1,0 (/dev/radio0), out: default
Note radio will automatically select the correct alsa device to record
from for the radio-usb-stick.
For some reason I don't see that happening.
Jul 4 18:04:33 localhost kernel: [ 78.006361] usb 5-2: new
full-speed USB device number 2 using ohci_hcd
Jul 4 18:04:34 localhost kernel: [ 78.165127] usb 5-2: New USB
device found, idVendor=10c5, idProduct=819a
Jul 4 18:04:34 localhost kernel: [ 78.165131] usb 5-2: New USB
device strings: Mfr=1, Product=2, SerialNumber=0
Jul 4 18:04:34 localhost kernel: [ 78.165133] usb 5-2:
Manufacturer: www.rding.cn
Jul 4 18:04:34 localhost udevd[412]: specified group 'plugdev' unknown
Jul 4 18:04:34 localhost mtp-probe: checking bus 5, device 2:
/sys/devices/pci:00/:00:13.0/usb5/5-2
Jul 4 18:04:34 localhost mtp-probe: bus: 5, device: 2 was not an MTP
device
Jul 4 18:04:34 localhost kernel: [ 78.189884] Linux media
interface: v0.10
Jul 4 18:04:34 localhost kernel: [ 78.191940] Linux video capture
interface: v2.00
Jul 4 18:04:34 localhost kernel: [ 78.194058] radio-si470x 5-2:1.2:
DeviceID=0x1242 ChipID=0x060c
Jul 4 18:04:34 localhost kernel: [ 78.194061] radio-si470x 5-2:1.2:
This driver is known to work with firmware version 14,
Jul 4 18:04:34 localhost kernel: [ 78.194062] radio-si470x 5-2:1.2:
but the device has firmware version 12.
Jul 4 18:04:34 localhost kernel: [ 78.196041] radio-si470x 5-2:1.2:
software version 1, hardware version 7
Jul 4 18:04:34 localhost kernel: [ 78.196043] radio-si470x 5-2:1.2:
If you have some trouble using this driver,
Jul 4 18:04:34 localhost kernel: [ 78.196045] radio-si470x 5-2:1.2:
please report to V4L ML at linux-media@vger.kernel.org
Jul 4 18:04:34 localhost kernel: [ 78.339041] usbcore: registered
new interface driver radio-si470x
Jul 4 18:04:34 localhost kernel: [ 78.357056] usbcore: registered
new interface driver snd-usb-audio
And is there any cheap USB FM-radio device that is known to work on
Linux ? I would like to order one...
I've done my testing with this device:
http://www.tinydeal.com/usb-pcear-radio-recorder-for-pc-p-8603.html
And that one works, but I think yours should work fine too.
Mine device looks just similar. I have bought it maybe 3-4 years ago.
Could you check these logs:
last commit of xawtv3:
commit 2550984180f940c4379651245db468602cb38354
Author: Hans de Goede hdego...@redhat.com
Date: Thu Jun 21 14:42:42 2012 +0200
Don't call strdup on NULL
This fixes radio / xawtv crashing when no associated
Re: [PATCH 4/4] radio-si470x: Lower firmware version requirements
Hi, On 07/05/2012 03:35 PM, Antti Palosaari wrote: snip I believe you're doing something wrong ... I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and arecord -r96000 -c2 -f S16_LE | aplay - to play sound. Just silent white noise is heard. You're not specifying which device arecord should record from so likely it is taking the default input of your soundcard (line/mic in), rather then recording from the radio device. I tried to define hw:1,0 etc. but only hw:0,0 exists. Note the latest radio from http://git.linuxtv.org/xawtv3.git will do the digital loopback of the sound itself, so try things again with running arecord / aplay, if you then start radio and exit again (so that you can see its startup messages) you should see something like this: Using alsa loopback: cap: hw:1,0 (/dev/radio0), out: default Note radio will automatically select the correct alsa device to record from for the radio-usb-stick. For some reason I don't see that happening. Hmm, so it seems that for some reason alsa is not working with the usb sound-card part of the usb-stick. Can you try doing: ls /dev/snd/ Before and after plugging in the device, you should get a new PCMC?D0c device there. Otherwise see if you can enable some debugging options for snd-usb-audio and find out why it is not liking your device (and maybe at a quirk for it somewhere) ? If you do end up adding a quirk please let me know and I'll test with mine to ensure the quirck does not break working versions :) 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: omap3isp: cropping bug in previewer?
Hi Laurent,
Laurent Pinchart wrote on 2012-07-05:
When I now capture a frame with yavta (see [3] for details), I must use
846x639 as frame size (as this size is reported by the driver). But it
seems that the outputted image is 2px wider (that means 848x639). This
results in a scrambled/unusable image on screen when streaming (see
[6] bad-frame-846x639_on_display.bmp for an example how it looks like
on screen). Also the file size too big for a 846x639 image: The frame
size is 1083744 bytes, which is exactly 848*639*2 (NOT 846*639*2)!
The OMAP3 ISP pads lines to multiples of 32 or 64 bytes when reading
from/writing to memory. 846 pixels * 2 bytes per pixel is not a multiple of 32
bytes, so the line length gets padded to the next multiple, 848 pixels in this
case. The information is reported by the bytesperline field of the
v4l2_pix_format structure returned by VIDIOC_G_FMT and VIDIOC_S_FMT
on the
preview engine output video node. You need to take the padding into
account in
your application, that should solve your issue. raw2rgbpnm tries to detect
padding at the end of lines, and skips it automatically.
Thanks for your fast answer and the explanation!
So you're saying that yavta doesn't check that the image is coming from the
previewer-output and has maybe a padding? So yavta needs a patch to extend the
line width when not aligned on 32 bytes or strip out the padding?
If you look in the isp-datasheet [7] in table 6-40 (page
1201) you see, that the CFA interpolation block for bayer-mode crops 4
px per line and 4 lines. So shouldn't we respect this in the
preview_config_input_size function? My RFC is:
Index: git/drivers/media/video/omap3isp/isppreview.c
=
--- git.orig/drivers/media/video/omap3isp/isppreview.c 2012-07-05
10:59:33.675358396 +0200 +++
git/drivers/media/video/omap3isp/isppreview.c2012-07-05
12:14:33.723223514 +0200 @@ -1140,6 +1140,12 @@
} if (features (OMAP3ISP_PREV_CHROMA_SUPP |
OMAP3ISP_PREV_LUMAENH)) sph -= 2;
+if (features OMAP3ISP_PREV_CFA) {
+sph -= 2;
+eph += 2;
+slv -= 2;
+elv += 2;
+}
isp_reg_writel(isp, (sph ISPPRV_HORZ_INFO_SPH_SHIFT) | eph,
OMAP3_ISP_IOMEM_PREV, ISPPRV_HORZ_INFO);
=
NOTE: This still gives an unusable picture at the previewer output BUT if I
extend the pipeline to the resizer output, the picture is good. So I must
be missing something...
After reading your explanation about the padding, I understand why the image is
broken on the previewer out. But if I configure the pipeline to output on the
resizer-out, the image is still broken (without my patch). I used a resolution
of 800x600 for the resizer-out, so the alignment should be fine:
# media-ctl -v -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP
resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output: 0[1]'
# media-ctl -v -f 'mt9p031 2-0048:0 [SGRBG12 800x600], OMAP3 ISP CCDC:2
[SGRBG10 800x600], OMAP3 ISP preview:1 [UYVY 800x600], OMAP3 ISP resizer:1
[UYVY 800x600]'
# yavta -f UYVY -s 800x600 -n 8 --skip 3 --capture=1000 --stdout /dev/video6 |
mplayer - -demuxer rawvideo -rawvideo w=800:h=600:format=uyvy -vo fbdev
Does my patch just output a good picture by chance, or is there really an issue?
--
Best regards,
Florian Neuhaus
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
On Thu, 5 Jul 2012 20:30:35 +1000, Anton Blanchard an...@samba.org wrote: I had a closer look. I dumped the RC6 debug, but I also printed the raw data in the interrupt handler: printk(%x %d %d\n, irdata, rawir.pulse, rawir.duration); ... That should have been a pulse but it came out as a space. This makes me wonder if there is an issue with the run length encoding, perhaps when a pulse is the right size to just saturate it. It does seem like we set the top bit even though we should not have. It's quite weird to see a short space followed by a max space followed by a short space (0xdc 0xff 0xde). Almost like there's one or more (pulse) bytes missing in between. I've tested long pulses/spaces before and they've worked as expected (e.g. max, max, short eventsthe leading 0x7f 0x7f 0x08 sequence in your log is a good example). Now, there is a minor bug in the RLE decoding in that the duration should have 1 added to it (meaning that 0x00 or 0x80 are valid values). Just to make sure something like that isn't happening, could you correct the line in wbcir_irq_rx() which currently reads: rawir.duration = US_TO_NS((irdata 0x7F) * 10); so that it reads rawir.duration = US_TO_NS(((irdata 0x7F) + 1) * 10); However, I'm guessing you inserted the extra debug printk inside wbcir_irq_rx() so any 0x00 or 0x80 bytes would have been printed? Another possibility is that the printk in the interrupt handler causes overhead...could you do a debug run without the printk in the interrupt handler? Also, could you provide me with the full versions of both logs? (i.e. all the way to idleit might help spot a missed pulse/space) 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
Re: [PATCH 4/4] radio-si470x: Lower firmware version requirements
On 07/05/2012 04:41 PM, Hans de Goede wrote: Hi, On 07/05/2012 03:35 PM, Antti Palosaari wrote: snip I believe you're doing something wrong ... I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and arecord -r96000 -c2 -f S16_LE | aplay - to play sound. Just silent white noise is heard. You're not specifying which device arecord should record from so likely it is taking the default input of your soundcard (line/mic in), rather then recording from the radio device. I tried to define hw:1,0 etc. but only hw:0,0 exists. Note the latest radio from http://git.linuxtv.org/xawtv3.git will do the digital loopback of the sound itself, so try things again with running arecord / aplay, if you then start radio and exit again (so that you can see its startup messages) you should see something like this: Using alsa loopback: cap: hw:1,0 (/dev/radio0), out: default Note radio will automatically select the correct alsa device to record from for the radio-usb-stick. For some reason I don't see that happening. Hmm, so it seems that for some reason alsa is not working with the usb sound-card part of the usb-stick. Can you try doing: ls /dev/snd/ Before and after plugging in the device, you should get a new PCMC?D0c device there. Two files appears, controlC2 and pcmC2D0c. Otherwise see if you can enable some debugging options for snd-usb-audio and find out why it is not liking your device (and maybe at a quirk for it somewhere) ? If you do end up adding a quirk please let me know and I'll test with mine to ensure the quirck does not break working versions :) And now I can hear the voice too using arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay -. But loopback is still missing. 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 1/3] [media] tuner-core: call has_signal for both TV and radio
If g_tuner is called and the tuner is able to return the signal strength
via has_signal(), call the tunner callback to retrieve such data for all
tuner types, not only for radio ones.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tuner-core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 1ad5ab6..98adeee 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1178,6 +1178,8 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
return 0;
if (vt-type == t-mode analog_ops-get_afc)
vt-afc = analog_ops-get_afc(t-fe);
+ if (analog_ops-has_signal)
+ vt-signal = analog_ops-has_signal(t-fe);
if (vt-type != V4L2_TUNER_RADIO) {
vt-capability |= V4L2_TUNER_CAP_NORM;
vt-rangelow = tv_range[0] * 16;
@@ -1197,8 +1199,6 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
V4L2_TUNER_SUB_STEREO :
V4L2_TUNER_SUB_MONO;
}
- if (analog_ops-has_signal)
- vt-signal = analog_ops-has_signal(t-fe);
vt-audmode = t-audmode;
}
vt-capability |= V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] tuner-xc2028: Fix signal strength report
There are several bugs at the signal strength algorithm:
- It is using logical OR, instead of bit OR;
- It doesn't wait up to 18 ms as it should;
- the strength range is not ok.
Rework on it, in order to make it work.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-xc2028.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index 9638a69..42fdf5c 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -903,7 +903,7 @@ static int xc2028_signal(struct dvb_frontend *fe, u16
*strength)
{
struct xc2028_data *priv = fe-tuner_priv;
u16 frq_lock, signal = 0;
- int rc;
+ int rc, i;
tuner_dbg(%s called\n, __func__);
@@ -914,21 +914,28 @@ static int xc2028_signal(struct dvb_frontend *fe, u16
*strength)
mutex_lock(priv-lock);
/* Sync Lock Indicator */
- rc = xc2028_get_reg(priv, XREG_LOCK, frq_lock);
- if (rc 0)
- goto ret;
+ for (i = 0; i 3; i++) {
+ rc = xc2028_get_reg(priv, XREG_LOCK, frq_lock);
+ if (rc 0)
+ goto ret;
- /* Frequency is locked */
- if (frq_lock == 1)
- signal = 1 11;
+ if (frq_lock)
+ break;
+ msleep(6);
+ }
+
+ /* Frequency was not locked */
+ if (frq_lock == 2)
+ goto ret;
/* Get SNR of the video signal */
rc = xc2028_get_reg(priv, XREG_SNR, signal);
if (rc 0)
goto ret;
- /* Use both frq_lock and signal to generate the result */
- signal = signal || ((signal 0x07) 12);
+ /* Signal level is 3 bits only */
+
+ signal = ((1 12) - 1) | ((signal 0x07) 12);
ret:
mutex_unlock(priv-lock);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] tuner, xc2028: add support for get_afc()
Implement API support to return AFC frequency shift, as this device
supports it. The only other driver that implements it is tda9887,
and the frequency there is reported in Hz. So, use Hz also for this
tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-xc2028.c | 46 +++-
drivers/media/dvb/dvb-core/dvb_frontend.h |1 +
drivers/media/video/tuner-core.c | 11 +++
3 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index 42fdf5c..4857e86 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -924,7 +924,7 @@ static int xc2028_signal(struct dvb_frontend *fe, u16
*strength)
msleep(6);
}
- /* Frequency was not locked */
+ /* Frequency didn't lock */
if (frq_lock == 2)
goto ret;
@@ -947,6 +947,49 @@ ret:
return rc;
}
+static int xc2028_get_afc(struct dvb_frontend *fe, s32 *afc)
+{
+ struct xc2028_data *priv = fe-tuner_priv;
+ int i, rc;
+ u16 frq_lock = 0;
+ s16 afc_reg = 0;
+
+ rc = check_device_status(priv);
+ if (rc 0)
+ return rc;
+
+ mutex_lock(priv-lock);
+
+ /* Sync Lock Indicator */
+ for (i = 0; i 3; i++) {
+ rc = xc2028_get_reg(priv, XREG_LOCK, frq_lock);
+ if (rc 0)
+ goto ret;
+
+ if (frq_lock)
+ break;
+ msleep(6);
+ }
+
+ /* Frequency didn't lock */
+ if (frq_lock == 2)
+ goto ret;
+
+ /* Get AFC */
+ rc = xc2028_get_reg(priv, XREG_FREQ_ERROR, afc_reg);
+ if (rc 0)
+ return rc;
+
+ *afc = afc_reg * 15625; /* Hz */
+
+ tuner_dbg(AFC is %d Hz\n, *afc);
+
+ret:
+ mutex_unlock(priv-lock);
+
+ return rc;
+}
+
#define DIV 15625
static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */,
@@ -1392,6 +1435,7 @@ static const struct dvb_tuner_ops xc2028_dvb_tuner_ops = {
.release = xc2028_dvb_release,
.get_frequency = xc2028_get_frequency,
.get_rf_strength = xc2028_signal,
+ .get_afc = xc2028_get_afc,
.set_params= xc2028_set_params,
.sleep = xc2028_sleep,
};
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index e929d56..7c64c09 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -220,6 +220,7 @@ struct dvb_tuner_ops {
#define TUNER_STATUS_STEREO 2
int (*get_status)(struct dvb_frontend *fe, u32 *status);
int (*get_rf_strength)(struct dvb_frontend *fe, u16 *strength);
+ int (*get_afc)(struct dvb_frontend *fe, s32 *afc);
/** These are provided separately from set_params in order to
facilitate silicon
* tuners which require sophisticated tuning loops, controlling each
parameter separately. */
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 98adeee..b5a819a 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -228,6 +228,16 @@ static int fe_has_signal(struct dvb_frontend *fe)
return strength;
}
+static int fe_get_afc(struct dvb_frontend *fe)
+{
+ s32 afc = 0;
+
+ if (fe-ops.tuner_ops.get_afc)
+ fe-ops.tuner_ops.get_afc(fe, afc);
+
+ return 0;
+}
+
static int fe_set_config(struct dvb_frontend *fe, void *priv_cfg)
{
struct dvb_tuner_ops *fe_tuner_ops = fe-ops.tuner_ops;
@@ -247,6 +257,7 @@ static struct analog_demod_ops tuner_analog_ops = {
.set_params = fe_set_params,
.standby= fe_standby,
.has_signal = fe_has_signal,
+ .get_afc= fe_get_afc,
.set_config = fe_set_config,
.tuner_status = tuner_status
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv452e
On 07/05/2012 04:14 PM, Marx wrote: Maybe i did something wrong because I'm new to git, so below are steps i followed to compile new driver set: 1) git clone git://linuxtv.org/anttip/media_tree.git 2) git checkout -b pctv452e origin/pctv452e 3) copy config file from 3.4 kernel 4) make menuconfig, check everything seems ok, quit save 5) build kernel Debian way, and install it, reboot wuwek:~# uname -a Linux wuwek 3.5.0-rc5+ #1 SMP Thu Jul 5 09:22:36 CEST 2012 i686 GNU/Linux wuwek:~# lsusb Bus 001 Device 002: ID 2304:021f Pinnacle Systems, Inc. PCTV Sat HDTV Pro BDA Device Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub wuwek:~/pctv/pctv452e/media_tree# ls /dev/dvb* ls: nie ma dostępu do /dev/dvb*: Nie ma takiego pliku ani katalogu So, while device is recognized, and a driver seems to recognize device, there is no /dev/dvb* devices, so something went wrong. What can I do more? Marx Ps. I'm attaching dmesg output. The second dvb card is internal Prof Revolution 8000. I didn't load whole driver. Test load it manually first using modprobe dvb_usb_pctv452e Check if those modules are enabled, in file .config CONFIG_DVB_USB_V2=m CONFIG_DVB_USB_PCTV452E=m use make menuconfig to enable if disabled. Then make make install_modules make install as usually. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] tuner-xc2028: Fix signal strength report
On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab - /* Use both frq_lock and signal to generate the result */ - signal = signal || ((signal 0x07) 12); + /* Signal level is 3 bits only */ + + signal = ((1 12) - 1) | ((signal 0x07) 12); Are you sure this is correct? It's entirely possible the original code used a logical or because the signal level isn't valid unless there is a lock. The author may have been intending to say: if (signal != 0) /* There is a lock, so set the signal level */ signal = (signal 0x07) 12; else signal = 0 /* Leave signal level at zero since there is no lock */ I agree that the way the original code was written is confusing, but it may actually be correct. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] tuner-xc2028: Fix signal strength report
On Thu, Jul 5, 2012 at 10:25 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab - /* Use both frq_lock and signal to generate the result */ - signal = signal || ((signal 0x07) 12); + /* Signal level is 3 bits only */ + + signal = ((1 12) - 1) | ((signal 0x07) 12); Are you sure this is correct? It's entirely possible the original code used a logical or because the signal level isn't valid unless there is a lock. The author may have been intending to say: if (signal != 0) /* There is a lock, so set the signal level */ signal = (signal 0x07) 12; else signal = 0 /* Leave signal level at zero since there is no lock */ I agree that the way the original code was written is confusing, but it may actually be correct. On second reading, it would have needed to be a logical AND, not an OR in order for my suggestion to have been correct. That said, empirical results are definitely a stronger argument in this case. You did test this change in cases with no signal, signal lock with weak signal, and signal lock with strong signal, right? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] rtl2832 ver. 0.5: support for RTL2832 demod
Em 18-05-2012 15:47, Thomas Mair escreveu:
Changelog for ver. 0.5:
- fixed code style and naming errors
Changelog for ver. 0.4:
- removed statistics as their calculation was wrong
- fixed bug in Makefile
- indentation and code style improvements
Signed-off-by: Thomas Mair thomas.mai...@googlemail.com
---
drivers/media/dvb/frontends/Kconfig|7 +
drivers/media/dvb/frontends/Makefile |1 +
drivers/media/dvb/frontends/rtl2832.c | 823
drivers/media/dvb/frontends/rtl2832.h | 74 +++
drivers/media/dvb/frontends/rtl2832_priv.h | 260 +
5 files changed, 1165 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/rtl2832.c
create mode 100644 drivers/media/dvb/frontends/rtl2832.h
create mode 100644 drivers/media/dvb/frontends/rtl2832_priv.h
diff --git a/drivers/media/dvb/frontends/Kconfig
b/drivers/media/dvb/frontends/Kconfig
index f479834..f7d67d7 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -432,6 +432,13 @@ config DVB_RTL2830
help
Say Y when you want to support this frontend.
+config DVB_RTL2832
+ tristate Realtek RTL2832 DVB-T
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ Say Y when you want to support this frontend.
+
comment DVB-C (cable) frontends
depends on DVB_CORE
diff --git a/drivers/media/dvb/frontends/Makefile
b/drivers/media/dvb/frontends/Makefile
index b0381dc..2279c5d 100644
--- a/drivers/media/dvb/frontends/Makefile
+++ b/drivers/media/dvb/frontends/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_DVB_IT913X_FE) += it913x-fe.o
obj-$(CONFIG_DVB_A8293) += a8293.o
obj-$(CONFIG_DVB_TDA10071) += tda10071.o
obj-$(CONFIG_DVB_RTL2830) += rtl2830.o
+obj-$(CONFIG_DVB_RTL2832) += rtl2832.o
obj-$(CONFIG_DVB_M88RS2000) += m88rs2000.o
obj-$(CONFIG_DVB_AF9033) += af9033.o
diff --git a/drivers/media/dvb/frontends/rtl2832.c
b/drivers/media/dvb/frontends/rtl2832.c
new file mode 100644
index 000..d0cbe27
--- /dev/null
+++ b/drivers/media/dvb/frontends/rtl2832.c
@@ -0,0 +1,823 @@
+/*
+ * Realtek RTL2832 DVB-T demodulator driver
+ *
+ * Copyright (C) 2012 Thomas Mair thomas.mai...@gmail.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include rtl2832_priv.h
+
+
+int rtl2832_debug;
+module_param_named(debug, rtl2832_debug, int, 0644);
+MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).);
+
+
+static const int reg_mask[32] = {
+ 0x0001,
+ 0x0003,
+ 0x0007,
+ 0x000f,
+ 0x001f,
+ 0x003f,
+ 0x007f,
+ 0x00ff,
+ 0x01ff,
+ 0x03ff,
+ 0x07ff,
+ 0x0fff,
+ 0x1fff,
+ 0x3fff,
+ 0x7fff,
+ 0x,
+ 0x0001,
+ 0x0003,
+ 0x0007,
+ 0x000f,
+ 0x001f,
+ 0x003f,
+ 0x007f,
+ 0x00ff,
+ 0x01ff,
+ 0x03ff,
+ 0x07ff,
+ 0x0fff,
+ 0x1fff,
+ 0x3fff,
+ 0x7fff,
+ 0x
+};
It would be better to use a macro here like:
#define REG_MASK(b) ((1 ((b) + 1)) -1)
Even better, you could use the bitops.h BIT() macro:
#define REG_MASK(b) (BIT(b + 1) - 1)
+
+static const struct rtl2832_reg_entry registers[] = {
+ [DVBT_SOFT_RST] = {0x1, 0x1, 2, 2},
+ [DVBT_IIC_REPEAT] = {0x1, 0x1, 3, 3},
+ [DVBT_TR_WAIT_MIN_8K] = {0x1, 0x88, 11, 2},
+ [DVBT_RSD_BER_FAIL_VAL] = {0x1, 0x8f, 15, 0},
+ [DVBT_EN_BK_TRK]= {0x1, 0xa6, 7, 7},
+ [DVBT_AD_EN_REG]= {0x0, 0x8, 7, 7},
+ [DVBT_AD_EN_REG1] = {0x0, 0x8, 6, 6},
+ [DVBT_EN_BBIN] = {0x1, 0xb1, 0, 0},
+ [DVBT_MGD_THD0] = {0x1, 0x95, 7, 0},
+ [DVBT_MGD_THD1] = {0x1, 0x96, 7, 0},
+ [DVBT_MGD_THD2] = {0x1, 0x97, 7, 0},
+ [DVBT_MGD_THD3] = {0x1, 0x98, 7, 0},
+ [DVBT_MGD_THD4] = {0x1, 0x99, 7, 0},
+ [DVBT_MGD_THD5] = {0x1, 0x9a, 7, 0},
+ [DVBT_MGD_THD6] = {0x1, 0x9b, 7, 0},
+
Re: [PATCH v5 1/5] rtl2832 ver. 0.5: support for RTL2832 demod
On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
Em 18-05-2012 15:47, Thomas Mair escreveu:
Changelog for ver. 0.5:
- fixed code style and naming errors
Changelog for ver. 0.4:
- removed statistics as their calculation was wrong
- fixed bug in Makefile
- indentation and code style improvements
Signed-off-by: Thomas Mair thomas.mai...@googlemail.com
---
drivers/media/dvb/frontends/Kconfig|7 +
drivers/media/dvb/frontends/Makefile |1 +
drivers/media/dvb/frontends/rtl2832.c | 823
drivers/media/dvb/frontends/rtl2832.h | 74 +++
drivers/media/dvb/frontends/rtl2832_priv.h | 260 +
5 files changed, 1165 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/rtl2832.c
create mode 100644 drivers/media/dvb/frontends/rtl2832.h
create mode 100644 drivers/media/dvb/frontends/rtl2832_priv.h
diff --git a/drivers/media/dvb/frontends/Kconfig
b/drivers/media/dvb/frontends/Kconfig
index f479834..f7d67d7 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -432,6 +432,13 @@ config DVB_RTL2830
help
Say Y when you want to support this frontend.
+config DVB_RTL2832
+ tristate Realtek RTL2832 DVB-T
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ Say Y when you want to support this frontend.
+
comment DVB-C (cable) frontends
depends on DVB_CORE
diff --git a/drivers/media/dvb/frontends/Makefile
b/drivers/media/dvb/frontends/Makefile
index b0381dc..2279c5d 100644
--- a/drivers/media/dvb/frontends/Makefile
+++ b/drivers/media/dvb/frontends/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_DVB_IT913X_FE) += it913x-fe.o
obj-$(CONFIG_DVB_A8293) += a8293.o
obj-$(CONFIG_DVB_TDA10071) += tda10071.o
obj-$(CONFIG_DVB_RTL2830) += rtl2830.o
+obj-$(CONFIG_DVB_RTL2832) += rtl2832.o
obj-$(CONFIG_DVB_M88RS2000) += m88rs2000.o
obj-$(CONFIG_DVB_AF9033) += af9033.o
diff --git a/drivers/media/dvb/frontends/rtl2832.c
b/drivers/media/dvb/frontends/rtl2832.c
new file mode 100644
index 000..d0cbe27
--- /dev/null
+++ b/drivers/media/dvb/frontends/rtl2832.c
@@ -0,0 +1,823 @@
+/*
+ * Realtek RTL2832 DVB-T demodulator driver
+ *
+ * Copyright (C) 2012 Thomas Mair thomas.mai...@gmail.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include rtl2832_priv.h
+
+
+int rtl2832_debug;
+module_param_named(debug, rtl2832_debug, int, 0644);
+MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).);
+
+
+static const int reg_mask[32] = {
+ 0x0001,
+ 0x0003,
+ 0x0007,
+ 0x000f,
+ 0x001f,
+ 0x003f,
+ 0x007f,
+ 0x00ff,
+ 0x01ff,
+ 0x03ff,
+ 0x07ff,
+ 0x0fff,
+ 0x1fff,
+ 0x3fff,
+ 0x7fff,
+ 0x,
+ 0x0001,
+ 0x0003,
+ 0x0007,
+ 0x000f,
+ 0x001f,
+ 0x003f,
+ 0x007f,
+ 0x00ff,
+ 0x01ff,
+ 0x03ff,
+ 0x07ff,
+ 0x0fff,
+ 0x1fff,
+ 0x3fff,
+ 0x7fff,
+ 0x
+};
It would be better to use a macro here like:
#define REG_MASK(b) ((1 ((b) + 1)) -1)
Even better, you could use the bitops.h BIT() macro:
#define REG_MASK(b) (BIT(b + 1) - 1)
I said also that once for Thomas during review but he didn't changed it :)
+
+static const struct rtl2832_reg_entry registers[] = {
+ [DVBT_SOFT_RST] = {0x1, 0x1, 2, 2},
+ [DVBT_IIC_REPEAT] = {0x1, 0x1, 3, 3},
+ [DVBT_TR_WAIT_MIN_8K] = {0x1, 0x88, 11, 2},
+ [DVBT_RSD_BER_FAIL_VAL] = {0x1, 0x8f, 15, 0},
+ [DVBT_EN_BK_TRK]= {0x1, 0xa6, 7, 7},
+ [DVBT_AD_EN_REG]= {0x0, 0x8, 7, 7},
+ [DVBT_AD_EN_REG1] = {0x0, 0x8, 6, 6},
+ [DVBT_EN_BBIN] = {0x1, 0xb1, 0, 0},
+ [DVBT_MGD_THD0] = {0x1, 0x95, 7, 0},
+ [DVBT_MGD_THD1] = {0x1, 0x96, 7, 0},
+ [DVBT_MGD_THD2] = {0x1, 0x97, 7, 0},
+ [DVBT_MGD_THD3] = {0x1, 0x98, 7, 0},
+ [DVBT_MGD_THD4] = {0x1,
[RFCv1 PATCH 3/7] v4l2-subdev: add support for the new edid ioctls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ioctl.c | 13 +
drivers/media/video/v4l2-subdev.c |6 ++
include/media/v4l2-subdev.h |2 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index d7fa896..248cc28 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2169,6 +2169,19 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
break;
}
+ case VIDIOC_SUBDEV_G_EDID:
+ case VIDIOC_SUBDEV_S_EDID: {
+ struct v4l2_subdev_edid *edid = parg;
+
+ if (edid-blocks) {
+ *user_ptr = (void __user *)edid-edid;
+ *kernel_ptr = (void *)edid-edid;
+ *array_size = edid-blocks * 128;
+ ret = 1;
+ }
+ break;
+ }
+
case VIDIOC_S_EXT_CTRLS:
case VIDIOC_G_EXT_CTRLS:
case VIDIOC_TRY_EXT_CTRLS: {
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index db6e859..3d46cd6 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -348,6 +348,12 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
return v4l2_subdev_call(
sd, pad, set_selection, subdev_fh, sel);
}
+
+ case VIDIOC_SUBDEV_G_EDID:
+ return v4l2_subdev_call(sd, pad, get_edid, arg);
+
+ case VIDIOC_SUBDEV_S_EDID:
+ return v4l2_subdev_call(sd, pad, set_edid, arg);
#endif
default:
return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index c35a354..74c578f 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -476,6 +476,8 @@ struct v4l2_subdev_pad_ops {
struct v4l2_subdev_selection *sel);
int (*set_selection)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_selection *sel);
+ int (*get_edid)(struct v4l2_subdev *sd, struct v4l2_subdev_edid *edid);
+ int (*set_edid)(struct v4l2_subdev *sd, struct v4l2_subdev_edid *edid);
#ifdef CONFIG_MEDIA_CONTROLLER
int (*link_validate)(struct v4l2_subdev *sd, struct media_link *link,
struct v4l2_subdev_format *source_fmt,
--
1.7.10
--
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
[RFCv1 PATCH 7/7] ad9389b: driver for the Analog Devices AD9389B video encoder.
Initial version of this driver.
The full datasheets are available from the Analog Devices website:
http://ez.analog.com/docs/DOC-1741
Not all features of the receiver are supported by this driver for various
reasons. Most notably:
- No CEC support (the CEC API needs a lot more discussion)
- No HDCP repeater support (we don't use that either)
I'm sure that there are more things missing, but this driver does work
well for our hardware.
Note that I am using the register addresses instead of register names: the
datasheet containing the register descriptions is organized by register
address. Using names would make the datasheet lookup very hard. An attempt
was made to try and document what is being done when registers are used
instead.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/Kconfig | 11 +
drivers/media/video/Makefile|1 +
drivers/media/video/ad9389b.c | 1327 +++
include/media/ad9389b.h | 49 ++
include/media/v4l2-chip-ident.h |3 +
5 files changed, 1391 insertions(+)
create mode 100644 drivers/media/video/ad9389b.c
create mode 100644 include/media/ad9389b.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index b5a40f3..87dc30e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -473,6 +473,17 @@ config VIDEO_ADV7343
To compile this driver as a module, choose M here: the
module will be called adv7343.
+config VIDEO_AD9389B
+ tristate Analog Devices AD9389B encoder
+ depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices AD9389B video encoder.
+
+ This is a Analog Devices HDMI transmitter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad9389b.
+
config VIDEO_AK881X
tristate AK8813/AK8814 video encoders
depends on I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b8f2aaa..2e08ec1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/video/ad9389b.c b/drivers/media/video/ad9389b.c
new file mode 100644
index 000..33aadd8
--- /dev/null
+++ b/drivers/media/video/ad9389b.c
@@ -0,0 +1,1327 @@
+/*
+ * Analog Devices AD9389B/AD9889B video encoder driver
+ *
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/*
+ * References (c = chapter, p = page):
+ * REF_01 - Analog Devices, Programming Guide, AD9889B/AD9389B,
+ * HDMI Transitter, Rev. A, October 2010
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/videodev2.h
+#include linux/workqueue.h
+#include linux/v4l2-dv-timings.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+#include media/ad9389b.h
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+MODULE_DESCRIPTION(Analog Devices AD9389B/AD9889B video encoder driver);
+MODULE_AUTHOR(Hans Verkuil hans.verk...@cisco.com);
+MODULE_AUTHOR(Martin Bugge marbu...@cisco.com);
+MODULE_LICENSE(GPL);
+
+#define MASK_AD9389B_EDID_RDY_INT 0x04
+#define MASK_AD9389B_MSEN_INT 0x40
+#define MASK_AD9389B_HPD_INT0x80
+
+#define MASK_AD9389B_HPD_DETECT 0x40
+#define MASK_AD9389B_MSEN_DETECT0x20
+#define MASK_AD9389B_EDID_RDY 0x10
+
+#define EDID_MAX_RETRIES (8)
+#define EDID_DELAY 250
+#define EDID_MAX_SEGM 8
+
+/*
+**
+*
+* Arrays with configuration parameters for the AD9389B
+*
+**
+*/
+
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+};
+
+struct
[RFCv1 PATCH 5/7] v4l2-common: add CVT and GTF detection functions.
These two helper functions detect whether the analog video timings detected
by the video receiver match the VESA CVT or GTF standards.
They basically do the inverse of the CVT and GTF modeline calculations.
This patch also adds a helper function that will determine the aspect ratio
based on the provided EDID values. This aspect ratio can be given to the GTF
helper function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-common.c | 358 +
include/media/v4l2-common.h | 13 ++
2 files changed, 371 insertions(+)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1baec83..33e57d8 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -597,6 +597,364 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
}
EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info);
+/**
+ * v4l_match_dv_timings - check if two timings match
+ * @t1 - compare this v4l2_dv_timings struct...
+ * @t2 - with this struct.
+ * @pclock_delta - the allowed pixelclock deviation.
+ *
+ * Compare t1 with t2 with a given margin of error for the pixelclock.
+ */
+bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
+ const struct v4l2_dv_timings *t2,
+ unsigned pclock_delta)
+{
+ if (t1-type != t2-type || t1-type != V4L2_DV_BT_656_1120)
+ return false;
+ if (t1-bt.width == t2-bt.width
+ t1-bt.height == t2-bt.height
+ t1-bt.interlaced == t2-bt.interlaced
+ t1-bt.polarities == t2-bt.polarities
+ t1-bt.pixelclock = t2-bt.pixelclock - pclock_delta
+ t1-bt.pixelclock = t2-bt.pixelclock + pclock_delta
+ t1-bt.hfrontporch == t2-bt.hfrontporch
+ t1-bt.vfrontporch == t2-bt.vfrontporch
+ t1-bt.vsync == t2-bt.vsync
+ t1-bt.vbackporch == t2-bt.vbackporch
+ (!t1-bt.interlaced ||
+ (t1-bt.il_vfrontporch == t2-bt.il_vfrontporch
+t1-bt.il_vsync == t2-bt.il_vsync
+t1-bt.il_vbackporch == t2-bt.il_vbackporch)))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+
+/*
+ * CVT defines
+ * Based on Coordinated Video Timings Standard
+ * version 1.1 September 10, 2003
+ */
+
+#define CVT_PXL_CLK_GRAN 25 /* pixel clock granularity */
+
+/* Normal blanking */
+#define CVT_MIN_V_BPORCH 7 /* lines */
+#define CVT_MIN_V_PORCH_RND3 /* lines */
+#define CVT_MIN_VSYNC_BP 550 /* min time of vsync + back porch (us)
*/
+
+/* Normal blanking for CVT uses GTF to calculate horizontal blanking */
+#define CVT_CELL_GRAN 8 /* character cell granularity */
+#define CVT_M 600 /* blanking formula gradient */
+#define CVT_C 40 /* blanking formula offset */
+#define CVT_K 128 /* blanking formula scaling factor */
+#define CVT_J 20 /* blanking formula scaling factor */
+#define CVT_C_PRIME (((CVT_C - CVT_J) * CVT_K / 256) + CVT_J)
+#define CVT_M_PRIME (CVT_K * CVT_M / 256)
+
+/* Reduced Blanking */
+#define CVT_RB_MIN_V_BPORCH7 /* lines */
+#define CVT_RB_V_FPORCH3 /* lines */
+#define CVT_RB_MIN_V_BLANK 460 /* us */
+#define CVT_RB_H_SYNC 32 /* pixels */
+#define CVT_RB_H_BPORCH 80 /* pixels */
+#define CVT_RB_H_BLANK 160 /* pixels */
+
+/** v4l2_detect_cvt - detect if the given timings follow the CVT standard
+ * @frame_height - the total height of the frame (including blanking) in lines.
+ * @hfreq - the horizontal frequency in Hz.
+ * @vsync - the height of the vertical sync in lines.
+ * @polarities - the horizontal and vertical polarities (same as struct
+ * v4l2_bt_timings polarities).
+ * @fmt - the resulting timings.
+ *
+ * This function will attempt to detect if the given values correspond to a
+ * valid CVT format. If so, then it will return true, and fmt will be filled
+ * in with the found CVT timings.
+ */
+bool v4l2_detect_cvt(unsigned frame_height, unsigned hfreq, unsigned vsync,
+ u32 polarities, struct v4l2_dv_timings *fmt)
+{
+ int v_fp, v_bp, h_fp, h_bp, hsync;
+ int frame_width, image_height, image_width;
+ bool reduced_blanking;
+ unsigned pix_clk;
+
+ if (vsync 4 || vsync 7)
+ return false;
+
+ if (polarities == V4L2_DV_VSYNC_POS_POL)
+ reduced_blanking = false;
+ else if (polarities == V4L2_DV_HSYNC_POS_POL)
+ reduced_blanking = true;
+ else
+ return false;
+
+ /* Vertical */
+ if (reduced_blanking) {
+ v_fp = CVT_RB_V_FPORCH;
+ v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 99) / 100;
+ v_bp -= vsync + v_fp;
+
+
[RFCv1 PATCH 2/7] V4L2 spec: document the new DV controls and ioctls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/controls.xml | 149 +++ Documentation/DocBook/media/v4l/v4l2.xml |1 + .../DocBook/media/v4l/vidioc-subdev-g-edid.xml | 152 3 files changed, 302 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 8994132..da41504 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4269,4 +4269,153 @@ interface and may change in the future./para /table /section + +section id=dv-controls + titleDigital Video Control Reference/title + + note + titleExperimental/title + + paraThis is an link + linkend=experimentalexperimental/link interface and may + change in the future./para + /note + + para + The Digital Video control class is intended to control receivers + and transmitters for VGA, DVI, HDMI and DisplayPort. These controls + are generally expected to be private to the receiver or transmitter + subdevice that implements them, so they are only exposed on the + filename/dev/v4l-subdev*/filename device node. + /para + + paraNote that these devices can have multiple input or output pads which are + hooked up to e.g. HDMI connectors. Even though the subdevice will receive or + transmit video from/to only one of those pads, the other pads can still be + active when it comes to EDID and HDCP processing, allowing the device + to do the fairly slow EDID/HDCP handling in advance. This allows for quick + switching between connectors./para + + paraThese pads appear in several of the controls in this section as + bitmasks, one bit for each pad starting at bit 0. The maximum value of + the control is the set of valid pads./para + + table pgwide=1 frame=none id=dv-control-id + titleDigital Video Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* / + colspec colname=c2 colwidth=6* / + colspec colname=c3 colwidth=2* / + colspec colname=c4 colwidth=6* / + spanspec namest=c1 nameend=c2 spanname=id / + spanspec namest=c2 nameend=c4 spanname=descr / + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_DV_CLASS/constant/entry + entryclass/entry + /row + row + entry spanname=descrThe DV class descriptor./entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_HOTPLUG/constant/entry + entrybitmask/entry + /row + row + entry spanname=descrMany connectors have a hotplug pin which is high + if EDID information is available from the source. This control shows the + state of the hotplug pin as seen by the transmitter. + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + /entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_RXSENSE/constant/entry + entrybitmask/entry + /row + row + entry spanname=descrRx Sense is the detection of pull-ups on the TMDS +clock lines. This normally means that the sink has left/entered standby (i.e. + the transmitter can sense that the receiver is ready to receive video). + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to DVI-D and HDMI devices. + /entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_EDID_PRESENT/constant/entry + entrybitmask/entry + /row + row + entry spanname=descrWhen the transmitter sees the hotplug signal from the + receiver it will attempt to read the EDID. If set, then the transmitter has read + at least the first block (= 128 bytes). + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + /entry + /row + row + entry spanname=idconstantV4L2_CID_DV_TX_MODE/constant/entry + entry id=v4l2-dv-tx-modeenum v4l2_dv_tx_mode/entry + /row + row + entry spanname=descrHDMI transmitters can transmit in DVI-D mode (just video) + or in HDMI mode (video + audio +
[RFCv1 PATCH 0/7] Add adv7604/ad9389b drivers
Hi all, This RFC patch series builds on an earlier RFC patch series (posted only to linux-media) that adds support for DVI/HDMI/DP connectors to the V4L2 API. This earlier patch series is here: http://www.spinics.net/lists/linux-media/msg48529.html The first 3 patches are effectively unchanged compared to that patch series, patch 4 adds support for the newly defined controls to the V4L2 control framework and patch 5 adds helper functions to v4l2-common.c to help in detecting VESA CVT and GTF formats. Finally, two Analog Devices drivers are added to actually use this new API. The adv7604 is an HDMI/DVI receiver and the ad9389b is an HDMI transmitter. Another tree of mine also contains preliminary drivers for the adv7842 and adv7511: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/hdmi However, I want to start with adv7604 and ad9389b since those have had the most testing. As the commit message of says these drivers do not implement the full functionality of these devices, but that can be added later, either by Cisco or by others. A lot of work has been put into the V4L2 subsystem to reach this point, particularly the control framework, the VIDIOC_G/S/ENUM/QUERY_DV_TIMINGS ioctls, and the V4L2 event mechanism. So I'm very pleased to be able to finally post this code. Comments are welcome! Regards, Hans Verkuil -- 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
[RFCv1 PATCH 4/7] v4l2-ctrls.c: add support for the new DV controls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 9abd9ab..a664795 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -425,6 +425,18 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Gray,
NULL,
};
+ static const char * const dv_tx_mode[] = {
+ DVI-D,
+ HDMI,
+ NULL,
+ };
+ static const char * const dv_rgb_range[] = {
+ Automatic,
+ RGB limited range (16-235),
+ RGB full range (0-255),
+ NULL,
+ };
+
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +514,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DV_TX_MODE:
+ return dv_tx_mode;
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
+ return dv_rgb_range;
default:
return NULL;
@@ -733,6 +750,16 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_LINK_FREQ:return Link Frequency;
case V4L2_CID_PIXEL_RATE: return Pixel Rate;
+ /* DV controls */
+ case V4L2_CID_DV_CLASS: return Digital Video Controls;
+ case V4L2_CID_DV_TX_HOTPLUG:return Hotplug Present;
+ case V4L2_CID_DV_TX_RXSENSE:return RxSense Present;
+ case V4L2_CID_DV_TX_EDID_PRESENT: return EDID Present;
+ case V4L2_CID_DV_TX_MODE: return Transmit Mode;
+ case V4L2_CID_DV_TX_RGB_RANGE: return Tx RGB Quantization
Range;
+ case V4L2_CID_DV_RX_POWER_PRESENT: return Power Present;
+ case V4L2_CID_DV_RX_RGB_RANGE: return Rx RGB Quantization
Range;
+
default:
return NULL;
}
@@ -831,6 +858,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DV_TX_MODE:
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
@@ -852,6 +882,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_CLASS:
case V4L2_CID_IMAGE_SOURCE_CLASS:
case V4L2_CID_IMAGE_PROC_CLASS:
+ case V4L2_CID_DV_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -868,6 +899,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_ACTIVE_MARKER:
case V4L2_CID_3A_LOCK:
case V4L2_CID_AUTO_FOCUS_STATUS:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
@@ -932,6 +967,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FLASH_STROBE_STATUS:
case V4L2_CID_AUTO_FOCUS_STATUS:
case V4L2_CID_FLASH_READY:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
}
--
1.7.10
--
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
[RFCv1 PATCH 1/7] v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
These new controls and two new ioctls make it possible to properly support
VGA, DVI-A/D/I, HDMI and DisplayPort connectors. All these controls and the
ioctls are all at the sub-device level. They are meant for V4L2 bridge/platform
drivers or to be accessed on embedded systems through /dev/v4l-subdev* device
nodes.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/v4l2-subdev.h | 10 ++
include/linux/videodev2.h | 23 +++
2 files changed, 33 insertions(+)
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
index 812019e..158a784 100644
--- a/include/linux/v4l2-subdev.h
+++ b/include/linux/v4l2-subdev.h
@@ -160,6 +160,14 @@ struct v4l2_subdev_selection {
__u32 reserved[8];
};
+struct v4l2_subdev_edid {
+ __u32 pad;
+ __u32 start_block;
+ __u32 blocks;
+ __u32 reserved[5];
+ __u8 __user *edid;
+};
+
#define VIDIOC_SUBDEV_G_FMT_IOWR('V', 4, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_S_FMT_IOWR('V', 5, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_G_FRAME_INTERVAL \
@@ -178,5 +186,7 @@ struct v4l2_subdev_selection {
_IOWR('V', 61, struct v4l2_subdev_selection)
#define VIDIOC_SUBDEV_S_SELECTION \
_IOWR('V', 62, struct v4l2_subdev_selection)
+#define VIDIOC_SUBDEV_G_EDID _IOWR('V', 63, struct v4l2_subdev_edid)
+#define VIDIOC_SUBDEV_S_EDID _IOWR('V', 64, struct v4l2_subdev_edid)
#endif
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..1e0dc25 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1266,6 +1266,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_JPEG 0x009d/* JPEG-compression
controls */
#define V4L2_CTRL_CLASS_IMAGE_SOURCE 0x009e/* Image source
controls */
#define V4L2_CTRL_CLASS_IMAGE_PROC 0x009f /* Image processing controls */
+#define V4L2_CTRL_CLASS_DV 0x00a0 /* Digital Video controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -2009,6 +2010,28 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
+/* DV-class control IDs defined by V4L2 */
+#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
+#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
+
+#defineV4L2_CID_DV_TX_HOTPLUG (V4L2_CID_DV_CLASS_BASE
+ 1)
+#defineV4L2_CID_DV_TX_RXSENSE (V4L2_CID_DV_CLASS_BASE
+ 2)
+#defineV4L2_CID_DV_TX_EDID_PRESENT (V4L2_CID_DV_CLASS_BASE
+ 3)
+#defineV4L2_CID_DV_TX_MODE (V4L2_CID_DV_CLASS_BASE
+ 4)
+enum v4l2_dv_tx_mode {
+ V4L2_DV_TX_MODE_DVI_D = 0,
+ V4L2_DV_TX_MODE_HDMI= 1,
+};
+#define V4L2_CID_DV_TX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 5)
+enum v4l2_dv_rgb_range {
+ V4L2_DV_RGB_RANGE_AUTO= 0,
+ V4L2_DV_RGB_RANGE_LIMITED = 1,
+ V4L2_DV_RGB_RANGE_FULL= 2,
+};
+
+#defineV4L2_CID_DV_RX_POWER_PRESENT(V4L2_CID_DV_CLASS_BASE
+ 100)
+#define V4L2_CID_DV_RX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 101)
+
/*
* T U N I N G
*/
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
hi David, excuse me for my ignorance, but don't you think adjusting the IR receiver to universal remote control is fundamentally wrong, while the whole point of universal remote control like Logitech Harmony is to be adjusted to the IR receiver and be able to be adjusted to any IR receiver and not the other way around. so, that being said, my point is maybe the whole discussion here is just wild goose chase until those settings i mentioned in Logitech control software are not tried and there is no evidence that has already being done based on the information provided by Anton. we don't know what exactly those settings applied to Logitech Harmony firmware via Logitech control software do and it could be default pulse timings that are set trough them are just out of specification for RC6 and need to be manually refined using the Harmony firmware settings in question - once again after all universal remote control is supposed to be able to fit any IR receiver and any type of pulses and that's why provides series of different settings in order to do that - the issue seems more like misconfiguration of the universal remote control than Linux drivers problem. i'm just trying to save you time chasing not existing problems and don't mean anything else - i didn't even look at the source code you're discussing - i just have practical experience with Logitech Harmony 890 and thus i know keymaps and protocols are independently set from the proper pulse timings with Logitech control software. best regards, konstantin On Thu, Jul 5, 2012 at 5:13 PM, David Härdeman da...@hardeman.nu wrote: On Thu, 5 Jul 2012 20:30:35 +1000, Anton Blanchard an...@samba.org wrote: I had a closer look. I dumped the RC6 debug, but I also printed the raw data in the interrupt handler: printk(%x %d %d\n, irdata, rawir.pulse, rawir.duration); ... That should have been a pulse but it came out as a space. This makes me wonder if there is an issue with the run length encoding, perhaps when a pulse is the right size to just saturate it. It does seem like we set the top bit even though we should not have. It's quite weird to see a short space followed by a max space followed by a short space (0xdc 0xff 0xde). Almost like there's one or more (pulse) bytes missing in between. I've tested long pulses/spaces before and they've worked as expected (e.g. max, max, short eventsthe leading 0x7f 0x7f 0x08 sequence in your log is a good example). Now, there is a minor bug in the RLE decoding in that the duration should have 1 added to it (meaning that 0x00 or 0x80 are valid values). Just to make sure something like that isn't happening, could you correct the line in wbcir_irq_rx() which currently reads: rawir.duration = US_TO_NS((irdata 0x7F) * 10); so that it reads rawir.duration = US_TO_NS(((irdata 0x7F) + 1) * 10); However, I'm guessing you inserted the extra debug printk inside wbcir_irq_rx() so any 0x00 or 0x80 bytes would have been printed? Another possibility is that the printk in the interrupt handler causes overhead...could you do a debug run without the printk in the interrupt handler? Also, could you provide me with the full versions of both logs? (i.e. all the way to idleit might help spot a missed pulse/space) 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 -- 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 v5 1/5] rtl2832 ver. 0.5: support for RTL2832 demod
On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
Em 18-05-2012 15:47, Thomas Mair escreveu:
+static int rtl2832_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
+{
+ *strength = 0;
+ return 0;
+}
Why to implement the above, if they're doing nothing?
Other your findings were correct but for that I would like to comment.
Have you ever tested what happens you lest those without stub
implementation? IIRC ugly errors are seen for example zap and femon
outputs. Some kind of DVB-core changes are needed. And IIRC there was
some error code defined too for API - but such code does not exists.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
On Thu, 5 Jul 2012 17:39:18 +0300, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: excuse me for my ignorance, but don't you think adjusting the IR receiver to universal remote control is fundamentally wrong, while the whole point of universal remote control like Logitech Harmony is to be adjusted to the IR receiver and be able to be adjusted to any IR receiver and not the other way around. so, that being said, my point is maybe the whole discussion here is just wild goose chase until those settings i mentioned in Logitech control software are not tried and there is no evidence that has already being done based on the information provided by Anton. we don't know what exactly those settings applied to Logitech Harmony firmware via Logitech control software do and it could be default pulse timings that are set trough them are just out of specification for RC6 and need to be manually refined using the Harmony firmware settings in question - once again after all universal remote control is supposed to be able to fit any IR receiver and any type of pulses and that's why provides series of different settings in order to do that - the issue seems more like misconfiguration of the universal remote control than Linux drivers problem. i'm just trying to save you time chasing not existing problems and don't mean anything else - i didn't even look at the source code you're discussing - i just have practical experience with Logitech Harmony 890 and thus i know keymaps and protocols are independently set from the proper pulse timings with Logitech control software. Konstantin, thanks for your concern, but some of the byte sequences that Anton showed are incorrect in the sense that the receiver hardware should never generate them no matter what the (Logitech) remote is sending (unless I've misunderstood something of course). 0xdc 0xff 0xde is a sequence which shouldn't happen. So even if the Logitech can be tweaked (and I'm sure Anton is grateful for the information), there is something wrong here and I'd like to get to the bottom of what it is. Kind regards, David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] winbond-cir: Adjust sample frequency to improve reliability
David, i see your point - as i mentioned i have no any knowledge of IR receiver part you're discussing and/or its Linux drivers and don't want just to spam, but my simple thinking is that if the Logitech Harmony universal remote control is with wrongly configured firmware it can emit something that is so messed up that makes the IR receiver part behaves in completely unpredictable way. anyway, at least Anton have some ideas to try... On Thu, Jul 5, 2012 at 5:45 PM, David Härdeman da...@hardeman.nu wrote: On Thu, 5 Jul 2012 17:39:18 +0300, Konstantin Dimitrov kosio.dimit...@gmail.com wrote: excuse me for my ignorance, but don't you think adjusting the IR receiver to universal remote control is fundamentally wrong, while the whole point of universal remote control like Logitech Harmony is to be adjusted to the IR receiver and be able to be adjusted to any IR receiver and not the other way around. so, that being said, my point is maybe the whole discussion here is just wild goose chase until those settings i mentioned in Logitech control software are not tried and there is no evidence that has already being done based on the information provided by Anton. we don't know what exactly those settings applied to Logitech Harmony firmware via Logitech control software do and it could be default pulse timings that are set trough them are just out of specification for RC6 and need to be manually refined using the Harmony firmware settings in question - once again after all universal remote control is supposed to be able to fit any IR receiver and any type of pulses and that's why provides series of different settings in order to do that - the issue seems more like misconfiguration of the universal remote control than Linux drivers problem. i'm just trying to save you time chasing not existing problems and don't mean anything else - i didn't even look at the source code you're discussing - i just have practical experience with Logitech Harmony 890 and thus i know keymaps and protocols are independently set from the proper pulse timings with Logitech control software. Konstantin, thanks for your concern, but some of the byte sequences that Anton showed are incorrect in the sense that the receiver hardware should never generate them no matter what the (Logitech) remote is sending (unless I've misunderstood something of course). 0xdc 0xff 0xde is a sequence which shouldn't happen. So even if the Logitech can be tweaked (and I'm sure Anton is grateful for the information), there is something wrong here and I'd like to get to the bottom of what it is. Kind regards, David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tuner, xc2028: add support for get_afc()
On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote: Implement API support to return AFC frequency shift, as this device supports it. The only other driver that implements it is tda9887, and the frequency there is reported in Hz. So, use Hz also for this tuner. What is AFC and why it is needed? + + if (frq_lock) + break; + msleep(6); 6 ms is too small value for msleep(). you should use usleep_range() instead. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] radio-si470x: Lower firmware version requirements
Hi, On 07/05/2012 04:13 PM, Antti Palosaari wrote: On 07/05/2012 04:41 PM, Hans de Goede wrote: Hi, On 07/05/2012 03:35 PM, Antti Palosaari wrote: snip I believe you're doing something wrong ... I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and arecord -r96000 -c2 -f S16_LE | aplay - to play sound. Just silent white noise is heard. You're not specifying which device arecord should record from so likely it is taking the default input of your soundcard (line/mic in), rather then recording from the radio device. I tried to define hw:1,0 etc. but only hw:0,0 exists. Note the latest radio from http://git.linuxtv.org/xawtv3.git will do the digital loopback of the sound itself, so try things again with running arecord / aplay, if you then start radio and exit again (so that you can see its startup messages) you should see something like this: Using alsa loopback: cap: hw:1,0 (/dev/radio0), out: default Note radio will automatically select the correct alsa device to record from for the radio-usb-stick. For some reason I don't see that happening. Hmm, so it seems that for some reason alsa is not working with the usb sound-card part of the usb-stick. Can you try doing: ls /dev/snd/ Before and after plugging in the device, you should get a new PCMC?D0c device there. Two files appears, controlC2 and pcmC2D0c. Otherwise see if you can enable some debugging options for snd-usb-audio and find out why it is not liking your device (and maybe at a quirk for it somewhere) ? If you do end up adding a quirk please let me know and I'll test with mine to ensure the quirck does not break working versions :) And now I can hear the voice too using arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay -. But loopback is still missing. So if you start radio before starting the arecord, it won't do the loopback for you? Have you compiled xawtv with alsa support? (this requires the libalsa headers to be installed) 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: [PATCH 4/4] radio-si470x: Lower firmware version requirements
On 07/05/2012 06:08 PM, Hans de Goede wrote: Hi, On 07/05/2012 04:13 PM, Antti Palosaari wrote: On 07/05/2012 04:41 PM, Hans de Goede wrote: Hi, On 07/05/2012 03:35 PM, Antti Palosaari wrote: snip I believe you're doing something wrong ... I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and arecord -r96000 -c2 -f S16_LE | aplay - to play sound. Just silent white noise is heard. You're not specifying which device arecord should record from so likely it is taking the default input of your soundcard (line/mic in), rather then recording from the radio device. I tried to define hw:1,0 etc. but only hw:0,0 exists. Note the latest radio from http://git.linuxtv.org/xawtv3.git will do the digital loopback of the sound itself, so try things again with running arecord / aplay, if you then start radio and exit again (so that you can see its startup messages) you should see something like this: Using alsa loopback: cap: hw:1,0 (/dev/radio0), out: default Note radio will automatically select the correct alsa device to record from for the radio-usb-stick. For some reason I don't see that happening. Hmm, so it seems that for some reason alsa is not working with the usb sound-card part of the usb-stick. Can you try doing: ls /dev/snd/ Before and after plugging in the device, you should get a new PCMC?D0c device there. Two files appears, controlC2 and pcmC2D0c. Otherwise see if you can enable some debugging options for snd-usb-audio and find out why it is not liking your device (and maybe at a quirk for it somewhere) ? If you do end up adding a quirk please let me know and I'll test with mine to ensure the quirck does not break working versions :) And now I can hear the voice too using arecord -D hw:2,0 -r96000 -c2 -f S16_LE | aplay -. But loopback is still missing. So if you start radio before starting the arecord, it won't do the loopback for you? Have you compiled xawtv with alsa support? (this requires the libalsa headers to be installed) aah, that explains. compile time options summary aalib: no alsa : no dv : no QuickTime: no OpenMotif: no X11R6: no OpenGL : no zvbi : no libv4l : yes libexplain : no regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1] s5p-mfc: update MFC v4l2 driver to support MFC6.x
Hi Arun, First of all - your patch is incomplete. I cannot find a modified videodev2.h file. Compilation fails with a lot of undefined symbols - attached below. Please supply this file, then I will be able to provide you with more comments and a proper review. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center --- Errors In file included from drivers/media/video/s5p-mfc/s5p_mfc.c:25: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type make[4]: *** [drivers/media/video/s5p-mfc/s5p_mfc.o] Error 1 make[4]: *** Waiting for unfinished jobs In file included from drivers/media/video/s5p-mfc/s5p_mfc_intr.c:21: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type make[4]: *** [drivers/media/video/s5p-mfc/s5p_mfc_intr.o] Error 1 In file included from drivers/media/video/s5p-mfc/s5p_mfc_dec.c:27: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_dec.c:38: error: 'V4L2_PIX_FMT_NV12MT_16X16' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c:59: error: 'V4L2_PIX_FMT_NV21M' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c:73: error: 'V4L2_PIX_FMT_H264_MVC' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c:129: error: 'V4L2_PIX_FMT_VP8' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c: In function 'vidioc_try_fmt': drivers/media/video/s5p-mfc/s5p_mfc_dec.c:377: warning: comparison between pointer and integer drivers/media/video/s5p-mfc/s5p_mfc_dec.c: In function 'vidioc_s_fmt': drivers/media/video/s5p-mfc/s5p_mfc_dec.c:450: warning: comparison between pointer and integer make[4]: *** [drivers/media/video/s5p-mfc/s5p_mfc_dec.o] Error 1 In file included from drivers/media/video/s5p-mfc/s5p_mfc_enc.c:28: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_enc.c:38: error: 'V4L2_PIX_FMT_NV12MT_16X16' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:59: error: 'V4L2_PIX_FMT_NV21M' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:113: error: 'V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_MAX_BITS' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:113: error: initializer element is not constant drivers/media/video/s5p-mfc/s5p_mfc_enc.c:113: error: (near initialization for 'controls[1].maximum') drivers/media/video/s5p-mfc/s5p_mfc_enc.c:126: error: 'V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BITS' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:126: error: initializer element is not constant drivers/media/video/s5p-mfc/s5p_mfc_enc.c:126: error: (near initialization for 'controls[3].id') drivers/media/video/s5p-mfc/s5p_mfc_enc.c:202: error: 'V4L2_CID_MPEG_VIDEO_VBV_DELAY' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:202: error: initializer element is not constant drivers/media/video/s5p-mfc/s5p_mfc_enc.c:202: error: (near initialization for 'controls[12].id') drivers/media/video/s5p-mfc/s5p_mfc_enc.c:572: error: 'V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:572: error: initializer element is not constant drivers/media/video/s5p-mfc/s5p_mfc_enc.c:572: error: (near initialization for 'controls[55].id') drivers/media/video/s5p-mfc/s5p_mfc_enc.c:580: error: 'V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:580: error: initializer element is
[PATCH] media_build: add backport patch for request_firmware_nowait() to kernels = 2.6.32
In kernel 2.6.33 request_firmware_nowait() gained a new parameter to set
the memory allocation flags.
We have to remove this parameter to make the drxk driver (the only user of
request_firmware_nowait() so far) compilable again with kernels older
than 2.6.33.
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
backports/backports.txt |1 +
backports/v2.6.32_request_firmware_nowait.patch | 15 +++
2 files changed, 16 insertions(+), 0 deletions(-)
create mode 100644 backports/v2.6.32_request_firmware_nowait.patch
diff --git a/backports/backports.txt b/backports/backports.txt
index cc768d2..5554d9e 100644
--- a/backports/backports.txt
+++ b/backports/backports.txt
@@ -62,6 +62,7 @@ add v2.6.33_pvrusb2_sysfs.patch
[2.6.32]
add v2.6.32_kfifo.patch
+add v2.6.32_request_firmware_nowait.patch
[2.6.31]
add v2.6.31_nodename.patch
diff --git a/backports/v2.6.32_request_firmware_nowait.patch
b/backports/v2.6.32_request_firmware_nowait.patch
new file mode 100644
index 000..8483189
--- /dev/null
+++ b/backports/v2.6.32_request_firmware_nowait.patch
@@ -0,0 +1,15 @@
+---
+ drivers/media/dvb/frontends/drxk_hard.c |1 -
+ 1 files changed, 0 insertions(+), 1 deletions(-)
+
+--- a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
+@@ -6548,7 +6548,6 @@ struct dvb_frontend *drxk_attach(const struct
drxk_config *config,
+ status = request_firmware_nowait(THIS_MODULE, 1,
+ state-microcode_name,
+ state-i2c-dev.parent,
+-GFP_KERNEL,
+ state, load_firmware_cb);
+ if (status 0) {
+ printk(KERN_ERR
+
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] tuner-xc2028: Fix signal strength report
Em 05-07-2012 11:31, Devin Heitmueller escreveu: On Thu, Jul 5, 2012 at 10:25 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab - /* Use both frq_lock and signal to generate the result */ - signal = signal || ((signal 0x07) 12); + /* Signal level is 3 bits only */ + + signal = ((1 12) - 1) | ((signal 0x07) 12); Are you sure this is correct? It's entirely possible the original code used a logical or because the signal level isn't valid unless there is a lock. The author may have been intending to say: if (signal != 0) /* There is a lock, so set the signal level */ signal = (signal 0x07) 12; else signal = 0 /* Leave signal level at zero since there is no lock */ I agree that the way the original code was written is confusing, but it may actually be correct. No, the intention there were to do a bit OR. The idea there was that, if a lock was given, some signal would be received. The real signal level would be identified by the remaining bits. What it was happening due to the code mistake was: if (lock) return 1; else return 0; On second reading, it would have needed to be a logical AND, not an OR in order for my suggestion to have been correct. That said, empirical results are definitely a stronger argument in this case. You did test this change in cases with no signal, signal lock with weak signal, and signal lock with strong signal, right? Yes, it was tested and the new code works fine: it returns 0 without signal and it returns a value between 0 and 65535 depending on the signal strength. Just like the DVB API, the V4L2 API spec is not clear about what type of range should be applied for the signal (linea range? dB?). It just says that it should be between 0 and 6. In the case of xc2028/3028, there are only 3 bits for signal strengh. The levels are in dB, with an 8dB step, where 0 means a signal weaker than 8dB and 7 means 56 dB or upper. The code should now be coherent with that. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] rtl2832 ver. 0.5: support for RTL2832 demod
Em 05-07-2012 11:41, Antti Palosaari escreveu:
On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
Em 18-05-2012 15:47, Thomas Mair escreveu:
+static int rtl2832_read_signal_strength(struct dvb_frontend *fe, u16
*strength)
+{
+*strength = 0;
+return 0;
+}
Why to implement the above, if they're doing nothing?
Other your findings were correct but for that I would like to comment.
Have you ever tested what happens you lest those without stub implementation?
IIRC ugly errors are seen for example zap and femon outputs. Some kind of
DVB-core
changes are needed. And IIRC there was some error code defined too for API -
but such
code does not exists.
So, let's fix the dvb_core, and not fill drivers with stubs. With regards to
userspace
tools, they should be patched to accept the error code that signalizes that an
ioctl
was not implemented, and not try to fix an userpace issue in Kernel.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/5] rtl2832 ver. 0.5: support for RTL2832 demod
Em 05-07-2012 11:35, Antti Palosaari escreveu:
On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
Em 18-05-2012 15:47, Thomas Mair escreveu:
+static const int reg_mask[32] = {
+0x0001,
+0x0003,
+0x0007,
+0x000f,
+0x001f,
+0x003f,
+0x007f,
+0x00ff,
+0x01ff,
+0x03ff,
+0x07ff,
+0x0fff,
+0x1fff,
+0x3fff,
+0x7fff,
+0x,
+0x0001,
+0x0003,
+0x0007,
+0x000f,
+0x001f,
+0x003f,
+0x007f,
+0x00ff,
+0x01ff,
+0x03ff,
+0x07ff,
+0x0fff,
+0x1fff,
+0x3fff,
+0x7fff,
+0x
+};
It would be better to use a macro here like:
#define REG_MASK(b)((1 ((b) + 1)) -1)
Even better, you could use the bitops.h BIT() macro:
#define REG_MASK(b)(BIT(b + 1) - 1)
I said also that once for Thomas during review but he didn't changed it :)
As those findings are minor ones, I'll just apply the patch series
and add a patch replacing reg_mask table by a macro like above.
+static int rtl2832_read_signal_strength(struct dvb_frontend *fe, u16
*strength)
+{
+*strength = 0;
+return 0;
+}
Why to implement the above, if they're doing nothing?
Other your findings were correct but for that I would like to comment.
Have you ever tested what happens you lest those without stub implementation?
IIRC ugly errors are seen for example zap and femon outputs. Some kind of
DVB-core changes are needed. And IIRC there was some error code defined too
for API - but such code does not exists.
I'll keep those stubs for now, but we should really fix the core and not
allow/add
crap things like that.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please fix the DocBook index entries for ATSC/MH
Hi Michael, Please fix the DocBooc Index entries for ATSC/MH: Error: no ID for constraint linkend: atscmh-sccc-block-mode. Error: no ID for constraint linkend: atscmh-sccc-code-mode. Error: no ID for constraint linkend: atscmh-rs-frame-ensemble. Error: no ID for constraint linkend: atscmh-rs-frame-mode. Error: no ID for constraint linkend: atscmh-rs-code-mode. Error: no ID for constraint linkend: DTV-ATSCMH-CODE-MODE-PRI. Error: no ID for constraint linkend: DTV-ATSCMH-CODE-MODE-SEC. Error: no ID for constraint linkend: DTV-ATSCMH-SCCC-CODE_MODE-A. Error: no ID for constraint linkend: DTV-ATSCMH-SCCC-CODE_MODE-B. Error: no ID for constraint linkend: DTV-ATSCMH-SCCC-CODE_MODE-C. Error: no ID for constraint linkend: DTV-ATSCMH-SCCC-CODE_MODE-D. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: cropping bug in previewer?
Hi Florian,
On Thursday 05 July 2012 16:06:03 Florian Neuhaus wrote:
Laurent Pinchart wrote on 2012-07-05:
When I now capture a frame with yavta (see [3] for details), I must use
846x639 as frame size (as this size is reported by the driver). But it
seems that the outputted image is 2px wider (that means 848x639). This
results in a scrambled/unusable image on screen when streaming (see
[6] bad-frame-846x639_on_display.bmp for an example how it looks like
on screen). Also the file size too big for a 846x639 image: The frame
size is 1083744 bytes, which is exactly 848*639*2 (NOT 846*639*2)!
The OMAP3 ISP pads lines to multiples of 32 or 64 bytes when reading
from/writing to memory. 846 pixels * 2 bytes per pixel is not a multiple
of 32 bytes, so the line length gets padded to the next multiple, 848
pixels in this case. The information is reported by the bytesperline field
of the v4l2_pix_format structure returned by VIDIOC_G_FMT and VIDIOC_S_FMT
on the preview engine output video node. You need to take the padding into
account in your application, that should solve your issue. raw2rgbpnm
tries to detect padding at the end of lines, and skips it automatically.
Thanks for your fast answer and the explanation!
So you're saying that yavta doesn't check that the image is coming from the
previewer-output and has maybe a padding? So yavta needs a patch to extend
the line width when not aligned on 32 bytes or strip out the padding?
yavta takes the bytesperline field into account, and writes full frames to
disk, including padding. We could patch it to (optionally) discard the padding
bytes, although that kind of feature might belong to higher-level component
(such as raw2rgbpnm or custom applications).
If you look in the isp-datasheet [7] in table 6-40 (page
1201) you see, that the CFA interpolation block for bayer-mode crops 4
px per line and 4 lines. So shouldn't we respect this in the
preview_config_input_size function? My RFC is:
Index: git/drivers/media/video/omap3isp/isppreview.c
=
--- git.orig/drivers/media/video/omap3isp/isppreview.c 2012-07-05
10:59:33.675358396 +0200 +++
git/drivers/media/video/omap3isp/isppreview.c 2012-07-05
12:14:33.723223514 +0200 @@ -1140,6 +1140,12 @@
}
if (features (OMAP3ISP_PREV_CHROMA_SUPP |
OMAP3ISP_PREV_LUMAENH))
sph -= 2;
+ if (features OMAP3ISP_PREV_CFA) {
+ sph -= 2;
+ eph += 2;
+ slv -= 2;
+ elv += 2;
+ }
isp_reg_writel(isp, (sph ISPPRV_HORZ_INFO_SPH_SHIFT) | eph,
OMAP3_ISP_IOMEM_PREV, ISPPRV_HORZ_INFO);
=
NOTE: This still gives an unusable picture at the previewer output BUT if
I extend the pipeline to the resizer output, the picture is good. So I
must be missing something...
After reading your explanation about the padding, I understand why the image
is broken on the previewer out. But if I configure the pipeline to output
on the resizer-out, the image is still broken (without my patch). I used a
resolution of 800x600 for the resizer-out, so the alignment should be fine:
# media-ctl -v -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP
CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP
resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output: 0[1]'
# media-ctl -v -f 'mt9p031 2-0048:0 [SGRBG12 800x600], OMAP3 ISP CCDC:2
[SGRBG10 800x600], OMAP3 ISP preview:1 [UYVY 800x600], OMAP3 ISP
resizer:1 [UYVY 800x600]'
# yavta -f UYVY -s 800x600 -n 8 --skip 3 --capture=1000 --stdout /dev/video6
| mplayer - -demuxer rawvideo -rawvideo w=800:h=600:format=uyvy -vo fbdev
Does my patch just output a good picture by chance, or is there really an
issue?
There's really an issue, which was introduced in v3.5-rc1. Could you please
try the following patch instead of yours ?
diff --git a/drivers/media/video/omap3isp/isppreview.c
b/drivers/media/video/omap3isp/isppreview.c
index 9c6dd44..614752a 100644
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -1116,7 +1116,7 @@ static void preview_config_input_size(struct
isp_prev_device *prev, u32 active)
unsigned int elv = prev-crop.top + prev-crop.height - 1;
u32 features;
- if (format-code == V4L2_MBUS_FMT_Y10_1X10) {
+ if (format-code != V4L2_MBUS_FMT_Y10_1X10) {
sph -= 2;
eph += 2;
slv -= 2;
--
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: capture_mem limitations in OMAP ISP
Hi Michael, On Tuesday 03 July 2012 11:46:33 Michael Jones wrote: Hi Laurent co., I'm looking at the memory limitations in the omap3isp driver. 'struct isp_video' contains member 'capture_mem', which is set separately for each of our v4l2 video device nodes. The CCDC, for example, has capture_mem = 4096 * 4096 * 3 = 48MB, while the previewer and resizer each have twice that. Where do these numbers come from? That's mostly historical. When developing the driver for the N900 we set a limit to avoid putting too much pressure on the system memory, and 3x8MP buffers was considered to be enough. We could raise the limit, remove it completely, or implement a policy mechanism to let a privileged userspace application specify limits. The later might be interesting as a core V4L2 mechanism. Is the CCDC incapable of DMA'ing more than 48MB into memory? I know that ISP_VIDEO_MAX_BUFFERS also limits the # of buffers, but I assume this is basically an arbitrary number so we can have a finite array of isp_video_buffer's. The 48MB, on the other hand, looks like it might have a good reason. -- 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 FOR v3.5] davicni: vpfe:media controller based capture driver for dm365
Em 04-07-2012 02:01, Hadli, Manjunath escreveu: Mauro, Can you please pull the patches? Let me know if anything needs to be done from my side. -Manju On Thu, May 31, 2012 at 17:42:24, Hadli, Manjunath wrote: Mauro, The following patch set adds the media controller based driver TI dm365 SoC. Patches have gone through RFC and reviews and are pending for some time. The main support added here: -CCDC capture -Previewer -Resizer -AEW/AF -Some media formats supported on dm365 -PIX_FORMATs supported on dm365 --- The following changes since commit a01ee165a132fadb57659d26246e340d6ac53265: Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd (2012-05-28 13:10:41 -0700) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git pull_dm365_mc_for_mauro Manjunath Hadli (19): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 davinci: vpfe: add dm3xx IPIPEIF hardware support module davinci: vpfe: add IPIPE hardware layer support davinci: vpfe: add IPIPE support for media controller driver $ grep copy_ `quilt next`|wc -l 53 Wow! There's a lot of undocumented userspace API stuff there! Am I missing something? Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: Remove useless runtime-private_data usage
Em 12-06-2012 10:53, Ezequiel Garcia escreveu: Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- drivers/media/video/em28xx/em28xx-audio.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/em28xx/em28xx-audio.c b/drivers/media/video/em28xx/em28xx-audio.c index d7e2a3d..2fcddae 100644 --- a/drivers/media/video/em28xx/em28xx-audio.c +++ b/drivers/media/video/em28xx/em28xx-audio.c @@ -305,7 +305,6 @@ static int snd_em28xx_capture_open(struct snd_pcm_substream *substream) snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); dev-adev.capture_pcm_substream = substream; - runtime-private_data = dev; Are you sure that this can be removed? I think this is used internally by the alsa API, but maybe something has changed and this is not required anymore. Had you test em28xx audio with this change? Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] xc5000: Add support for DMB-TH and ISDB-T
xc5000 is just a tuner, not a decoder, so both DMB-TH and ISDB-T should work properly there: it is just a matter of teaching the driver what saw filter should be used and how to calculate the center frequency. Requested-by: Choi Wing Chan chanchoiw...@gmail.com Cc: Steven Toth st...@linuxtv.org Cc: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/common/tuners/xc5000.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/common/tuners/xc5000.c b/drivers/media/common/tuners/xc5000.c index dcca42c..bac8009 100644 --- a/drivers/media/common/tuners/xc5000.c +++ b/drivers/media/common/tuners/xc5000.c @@ -717,6 +717,12 @@ static int xc5000_set_params(struct dvb_frontend *fe) priv-freq_hz = freq - 175; priv-video_standard = DTV6; break; + case SYS_ISDBT: + /* All ISDB-T are currently for 6 MHz bw */ + if (!bw) + bw = 600; + /* fall to OFDM handling */ + case SYS_DMBTH: case SYS_DVBT: case SYS_DVBT2: dprintk(1, %s() OFDM\n, __func__); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: Remove useless runtime-private_data usage
Hi Mauro,
On Thu, Jul 5, 2012 at 1:57 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
dev-adev.capture_pcm_substream = substream;
- runtime-private_data = dev;
Are you sure that this can be removed? I think this is used internally
by the alsa API, but maybe something has changed and this is not
required anymore.
Yes, I'm sure.
Had you test em28xx audio with this change?
No, I did not test it.
To make this patch, I've considered two things:
1. Alsa documentation [1]
This is from chapter 5, Private Data section.
---
You can allocate a record for the substream and store it in
runtime-private_data. Usually, this is done in the open callback.
Don't mix this with pcm-private_data. The pcm-private_data usually
points to the chip instance assigned statically at the creation of
PCM, while the runtime-private_data points to a dynamic data
structure created at the PCM open callback.
static int snd_xxx_open(struct snd_pcm_substream *substream)
{
struct my_pcm_data *data;
data = kmalloc(sizeof(*data), GFP_KERNEL);
substream-runtime-private_data = data;
}
---
I think the part Don't mix this with pcm-private_data, is the one
related to this case.
Also, what alsa documentation calls chip instance is our em28xx
device structure.
2. Regular kernel practice:
Normally, private_data fields are suppose to be (private) data the
driver author wants
the core subsystem to pass him as callback parameter. The core
subsystem is not supposed
to use it in anyway (he wouldn't know how).
So, if you don't use it anywhere else in your code, it's safe to remove it.
If still in doubt, just don't apply it.
I'm not really concerned about one extra line,
rather about drivers doing unnecessary stuff,
and then others take these drivers as example
and spread the bloatness all over the place, so to speak.
[1] http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch05s05.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: Question about V4L2_MEMORY_USERPTR
Hi Hans-Petter, On Monday 02 July 2012 21:07:56 Hans Petter Selasky wrote: Hi Laurent and Sakari, For the sake of the matter, here is the driver in question: http://www.freshports.org/multimedia/webcamd/ Under native-Linux (kernel mode): I've looked at the linux-media code a bit and it appears that video data is copied directly from the USB callback functions to the destination process in userspace. This works because the userspace buffer is mapped into kernel memory it appears. Correct me if I'm wrong: video/videobuf-core.c: err = __videobuf_mmap_setup(q, count, size, V4L2_MEMORY_USERPTR); It's hard to tell from that line only. V4L2_MEMORY_USERPTR takes a memory pointer from userspace and uses it in the kernel. How the memory is used depends on the driver, it can be converted to a scatter list of physical memory and passed to the hardware, mapped to the kernel, be accessed using copy_from_user/copy_to_user, ... BTW videobuf1 is outdated, drivers will eventually be ported to videobuf2. Under FreeBSD where the Linux kernel code is running in user-space as a driver daemon, this part cannot be done exactly like this, so I've just patched out the V4L2_MEMORY_USERPTR feature until further. Am I clear? -- 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 3/3] [media] tuner, xc2028: add support for get_afc()
On Thu, Jul 5, 2012 at 5:05 PM, Antti Palosaari cr...@iki.fi wrote: On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote: Implement API support to return AFC frequency shift, as this device supports it. The only other driver that implements it is tda9887, and the frequency there is reported in Hz. So, use Hz also for this tuner. What is AFC and why it is needed? AFC is short for Automatic Frequency Control, by which a tuner automatically fine-tunes the frequency for the best reception, compensating for small offsets and oscillator frequency drift. This is however done automatically on the tuner, so its configuration is read-only. Aside from being a nice to know statistic, getting hold of the AFC frequency shift does as far as I know not have any practical uses related to properly operating the tuner. Regards, Bert -- 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] omap3isp: preview: Fix output size computation depending on input format
The preview engine crops 4 columns and 4 lines when CFA is enabled.
Commit b2da46e52fe7871cba36e1a435844502c0eccf39 (omap3isp: preview: Add
support for greyscale input) inverted the condition by mistake, fix
this.
Reported-by: Florian Neuhaus florian.neuh...@reberinformatik.ch
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isppreview.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This is a v3.5 regression, I'll send a pull request in the next couple of
days.
diff --git a/drivers/media/video/omap3isp/isppreview.c
b/drivers/media/video/omap3isp/isppreview.c
index 8a4935e..a48a747 100644
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -1102,7 +1102,7 @@ static void preview_config_input_size(struct
isp_prev_device *prev, u32 active)
unsigned int elv = prev-crop.top + prev-crop.height - 1;
u32 features;
- if (format-code == V4L2_MBUS_FMT_Y10_1X10) {
+ if (format-code != V4L2_MBUS_FMT_Y10_1X10) {
sph -= 2;
eph += 2;
slv -= 2;
--
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
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:Thu Jul 5 19:00:23 CEST 2012 git hash:e9da6b3ca5a6a0df8c8b790d8f1f4b232bed2a6b gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS 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: ERRORS linux-2.6.32.6-x86_64: ERRORS 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: ERRORS linux-2.6.32.6-i686: ERRORS 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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [media] tuner, xc2028: add support for get_afc()
Em 05-07-2012 14:37, Bert Massop escreveu: On Thu, Jul 5, 2012 at 5:05 PM, Antti Palosaari cr...@iki.fi wrote: On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote: Implement API support to return AFC frequency shift, as this device supports it. The only other driver that implements it is tda9887, and the frequency there is reported in Hz. So, use Hz also for this tuner. What is AFC and why it is needed? AFC is short for Automatic Frequency Control, by which a tuner automatically fine-tunes the frequency for the best reception, compensating for small offsets and oscillator frequency drift. This is however done automatically on the tuner, so its configuration is read-only. Aside from being a nice to know statistic, getting hold of the AFC frequency shift does as far as I know not have any practical uses related to properly operating the tuner. AFC might be useful on a few situations. For example, my CATV operator still broadcasts some channels in both analog and digital. The analog equipment there doesn't seem to be well-maintained, as some channels have frequency shifts or have some other artifacts. Still, analog broadcast is useful for me to test drivers ;) Anyway, adjusting the channel tables to consider that offset shift help to tune them a little faster and/or get a better quality by letting the PLL to work closer to the pilot carrier. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/9] soc-camera: Don't fail at module init time if no device is present
The soc-camera module exports functions that are needed by soc-camera
client drivers even when not running in soc-camera mode. Replace the
platform_driver_probe() with a platform_driver_register() call to avoid
module load failures if no soc-camera device is present.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 0421bf9..e7c6809 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1518,6 +1518,7 @@ static int __devexit soc_camera_pdrv_remove(struct
platform_device *pdev)
}
static struct platform_driver __refdata soc_camera_pdrv = {
+ .probe = soc_camera_pdrv_probe,
.remove = __devexit_p(soc_camera_pdrv_remove),
.driver = {
.name = soc-camera-pdrv,
@@ -1527,7 +1528,7 @@ static struct platform_driver __refdata soc_camera_pdrv =
{
static int __init soc_camera_init(void)
{
- return platform_driver_probe(soc_camera_pdrv, soc_camera_pdrv_probe);
+ return platform_driver_register(soc_camera_pdrv);
}
static void __exit soc_camera_exit(void)
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/9] Miscellaneous soc-camera patches
Here's the second version of the miscellaneous soc-camera patches that try to improve the interoperability between soc-camera clients and non soc-camera hosts. As with the previous version, all patches have been compile-tested but not runtime-tested as I lack the necessary hardware. Changes compared to v1: - Set priv-cfmt_code in ov2640 driver (3/9) - Split the soc-camera power off sequence change to its own patch (7/9) - Added an inline soc_camera_set_power() function (8/9) - Make sure the mt9m111 gets powered off completely if power on fails (8/9) - Simplify the s_power implementation in the ov5642 driver (8/9) - Don't modify power handling in the sh_mobile_csi2 driver - Don't pass a NULL device pointer to soc_camera_power_on() at probe time (8/9) - Fix physical device retrieval in soc_camera_platform_s_power() (8/9) - Don't loose return codes in mt9m111_video_probe() (9/9) - Remove unneeded enable/idle/disable calls in mt9p031 probe (9/9) Laurent Pinchart (9): soc-camera: Don't fail at module init time if no device is present soc-camera: Pass the physical device to the power operation ov2640: Don't access the device in the g_mbus_fmt operation ov772x: Don't access the device in the g_mbus_fmt operation tw9910: Don't access the device in the g_mbus_fmt operation soc_camera: Don't call .s_power() during probe soc-camera: Continue the power off sequence if one of the steps fails soc-camera: Add and use soc_camera_power_[on|off]() helper functions soc-camera: Push probe-time power management to drivers drivers/media/video/imx074.c | 30 ++- drivers/media/video/mt9m001.c | 26 ++- drivers/media/video/mt9m111.c | 116 ++-- drivers/media/video/mt9t031.c | 48 ++-- drivers/media/video/mt9t112.c | 21 +- drivers/media/video/mt9v022.c | 14 drivers/media/video/ov2640.c | 26 +-- drivers/media/video/ov5642.c | 31 ++-- drivers/media/video/ov6650.c | 28 ++-- drivers/media/video/ov772x.c | 31 ++-- drivers/media/video/ov9640.c | 27 ++- drivers/media/video/ov9740.c | 38 +++--- drivers/media/video/rj54n1cb0c.c | 27 ++- drivers/media/video/soc_camera.c | 101 +++-- drivers/media/video/soc_camera_platform.c | 11 +++- drivers/media/video/tw9910.c | 29 ++-- include/media/soc_camera.h| 10 +++ 17 files changed, 423 insertions(+), 191 deletions(-) -- 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 v2 4/9] ov772x: Don't access the device in the g_mbus_fmt operation
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 74e77d3..6d79b89 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -880,15 +880,11 @@ static int ov772x_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
static int ov772x_g_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
- struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
if (!priv-win || !priv-cfmt) {
- u32 width = VGA_WIDTH, height = VGA_HEIGHT;
- int ret = ov772x_set_params(client, width, height,
- V4L2_MBUS_FMT_YUYV8_2X8);
- if (ret 0)
- return ret;
+ priv-cfmt = ov772x_cfmts[0];
+ priv-win = ov772x_select_win(VGA_WIDTH, VGA_HEIGHT);
}
mf-width = priv-win-width;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/9] ov2640: Don't access the device in the g_mbus_fmt operation
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov2640.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ov2640.c b/drivers/media/video/ov2640.c
index 3c2c5d3..7c44d1f 100644
--- a/drivers/media/video/ov2640.c
+++ b/drivers/media/video/ov2640.c
@@ -837,10 +837,8 @@ static int ov2640_g_fmt(struct v4l2_subdev *sd,
if (!priv-win) {
u32 width = W_SVGA, height = H_SVGA;
- int ret = ov2640_set_params(client, width, height,
- V4L2_MBUS_FMT_UYVY8_2X8);
- if (ret 0)
- return ret;
+ priv-win = ov2640_select_win(width, height);
+ priv-cfmt_code = V4L2_MBUS_FMT_UYVY8_2X8;
}
mf-width = priv-win-width;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/9] tw9910: Don't access the device in the g_mbus_fmt operation
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/tw9910.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 8768efb..9f53eac 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -699,11 +699,9 @@ static int tw9910_g_fmt(struct v4l2_subdev *sd,
struct tw9910_priv *priv = to_tw9910(client);
if (!priv-scale) {
- int ret;
- u32 width = 640, height = 480;
- ret = tw9910_set_frame(sd, width, height);
- if (ret 0)
- return ret;
+ priv-scale = tw9910_select_norm(priv-norm, 640, 480);
+ if (!priv-scale)
+ return -EINVAL;
}
mf-width = priv-scale-width;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/9] soc-camera: Add and use soc_camera_power_[on|off]() helper functions
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(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 351e9ba..ade1987 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -268,6 +268,14 @@ static int imx074_g_chip_ident(struct v4l2_subdev *sd,
return 0;
}
+static int imx074_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);
+
+ return soc_camera_set_power(client-dev, icl, on);
+}
+
static int imx074_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
@@ -292,6 +300,7 @@ static struct v4l2_subdev_video_ops imx074_subdev_video_ops
= {
static struct v4l2_subdev_core_ops imx074_subdev_core_ops = {
.g_chip_ident = imx074_g_chip_ident,
+ .s_power= imx074_s_power,
};
static struct v4l2_subdev_ops imx074_subdev_ops = {
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 00583f5..cd71230 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -377,6 +377,14 @@ static int mt9m001_s_register(struct v4l2_subdev *sd,
}
#endif
+static int mt9m001_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);
+
+ return soc_camera_set_power(client-dev, icl, on);
+}
+
static int mt9m001_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
struct mt9m001 *mt9m001 = container_of(ctrl-handler,
@@ -566,6 +574,7 @@ static struct v4l2_subdev_core_ops mt9m001_subdev_core_ops
= {
.g_register = mt9m001_g_register,
.s_register = mt9m001_s_register,
#endif
+ .s_power= mt9m001_s_power,
};
static int mt9m001_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index b0c5299..a7a649a 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -832,10 +832,37 @@ static int mt9m111_video_probe(struct i2c_client *client)
return v4l2_ctrl_handler_setup(mt9m111-hdl);
}
+static int mt9m111_power_on(struct mt9m111 *mt9m111)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+ int ret;
+
+ ret = soc_camera_power_on(client-dev, icl);
+ if (ret 0)
+ return ret;
+
+ ret = mt9m111_resume(mt9m111);
+ if (ret 0) {
+ dev_err(client-dev, Failed to resume the sensor: %d\n, ret);
+ soc_camera_power_off(client-dev, icl);
+ }
+
+ return ret;
+}
+
+static void mt9m111_power_off(struct mt9m111 *mt9m111)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ mt9m111_suspend(mt9m111);
+ soc_camera_power_off(client-dev, icl);
+}
+
static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
{
struct mt9m111 *mt9m111 = container_of(sd, struct mt9m111, subdev);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret = 0;
mutex_lock(mt9m111-power_lock);
@@ -845,23 +872,18 @@ static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
* update the power state.
*/
if (mt9m111-power_count == !on) {
- if (on) {
- ret = mt9m111_resume(mt9m111);
-
[PATCH v2 9/9] soc-camera: Push probe-time power management to drivers
Several client drivers access the hardware at probe time, for instance
to read the probe chip ID. Such chips need to be powered up when being
probed.
soc-camera handles this by powering chips up in the soc-camera probe
implementation. However, this will break with non soc-camera hosts that
don't perform the same operations.
Fix the problem by pushing the power up/down from the soc-camera core
down to individual drivers on a needs basis.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c | 21 --
drivers/media/video/mt9m001.c| 17 +++-
drivers/media/video/mt9m111.c| 80 +
drivers/media/video/mt9t031.c| 37 +++--
drivers/media/video/mt9t112.c| 12 +-
drivers/media/video/mt9v022.c|5 ++
drivers/media/video/ov2640.c | 11 -
drivers/media/video/ov5642.c | 21 --
drivers/media/video/ov6650.c | 19 ++---
drivers/media/video/ov772x.c | 14 ++-
drivers/media/video/ov9640.c | 17 ++--
drivers/media/video/ov9740.c | 23 +++
drivers/media/video/rj54n1cb0c.c | 18 ++--
drivers/media/video/soc_camera.c | 20 -
drivers/media/video/tw9910.c | 12 +-
15 files changed, 204 insertions(+), 123 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index ade1987..f8534ee 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -310,26 +310,33 @@ static struct v4l2_subdev_ops imx074_subdev_ops = {
static int imx074_video_probe(struct i2c_client *client)
{
+ struct v4l2_subdev *subdev = i2c_get_clientdata(client);
int ret;
u16 id;
+ ret = imx074_s_power(subdev, 1);
+ if (ret 0)
+ return ret;
+
/* Read sensor Model ID */
ret = reg_read(client, 0);
if (ret 0)
- return ret;
+ goto done;
id = ret 8;
ret = reg_read(client, 1);
if (ret 0)
- return ret;
+ goto done;
id |= ret;
dev_info(client-dev, Chip ID 0x%04x detected\n, id);
- if (id != 0x74)
- return -ENODEV;
+ if (id != 0x74) {
+ ret = -ENODEV;
+ goto done;
+ }
/* PLL Setting EXTCLK=24MHz, 22.5times */
reg_write(client, PLL_MULTIPLIER, 0x2D);
@@ -411,7 +418,11 @@ static int imx074_video_probe(struct i2c_client *client)
reg_write(client, GROUPED_PARAMETER_HOLD, 0x00);/* off */
- return 0;
+ ret = 0;
+
+done:
+ imx074_s_power(subdev, 0);
+ return ret;
}
static int imx074_probe(struct i2c_client *client,
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index cd71230..d85be41 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -490,6 +490,10 @@ static int mt9m001_video_probe(struct soc_camera_link *icl,
unsigned long flags;
int ret;
+ ret = mt9m001_s_power(mt9m001-subdev, 1);
+ if (ret 0)
+ return ret;
+
/* Enable the chip */
data = reg_write(client, MT9M001_CHIP_ENABLE, 1);
dev_dbg(client-dev, write: %d\n, data);
@@ -511,7 +515,8 @@ static int mt9m001_video_probe(struct soc_camera_link *icl,
default:
dev_err(client-dev,
No MT9M001 chip detected, register read %x\n, data);
- return -ENODEV;
+ ret = -ENODEV;
+ goto done;
}
mt9m001-num_fmts = 0;
@@ -540,11 +545,17 @@ static int mt9m001_video_probe(struct soc_camera_link
*icl,
data == 0x8431 ? C12STM : C12ST);
ret = mt9m001_init(client);
- if (ret 0)
+ if (ret 0) {
dev_err(client-dev, Failed to initialise the camera\n);
+ goto done;
+ }
/* mt9m001_init() has reset the chip, returning registers to defaults */
- return v4l2_ctrl_handler_setup(mt9m001-hdl);
+ ret = v4l2_ctrl_handler_setup(mt9m001-hdl);
+
+done:
+ mt9m001_s_power(mt9m001-subdev, 0);
+ return ret;
}
static void mt9m001_video_remove(struct soc_camera_link *icl)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index a7a649a..8a10729 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -797,41 +797,6 @@ static int mt9m111_init(struct mt9m111 *mt9m111)
return ret;
}
-/*
- * Interface active, can use i2c. If it fails, it can indeed mean, that
- * this wasn't our capture interface, so, we wait for the right one
- */
-static int mt9m111_video_probe(struct i2c_client *client)
-{
- struct mt9m111 *mt9m111 = to_mt9m111(client);
- s32 data;
- int ret;
-
- data = reg_read(CHIP_VERSION);
-
- switch (data) {
- case 0x143a: /* MT9M111 or
[PATCH v2 7/9] soc-camera: Continue the power off sequence if one of the steps fails
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);
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,
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/9] soc_camera: Don't call .s_power() during probe
The .s_power() call only covers the .g_mbus_fmt() operation call.
Several clients required to be powered on to retrieve the current mbus
format but have now been fixed. The .s_power() call is thus not needed
anymore and can be removed.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index b03ffec..55b981f 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1133,10 +1133,6 @@ static int soc_camera_probe(struct soc_camera_device
*icd)
if (ret 0)
goto evidstart;
- ret = v4l2_subdev_call(sd, core, s_power, 1);
- if (ret 0 ret != -ENOIOCTLCMD)
- goto esdpwr;
-
/* Try to improve our guess of a reasonable window format */
if (!v4l2_subdev_call(sd, video, g_mbus_fmt, mf)) {
icd-user_width = mf.width;
@@ -1153,8 +1149,6 @@ static int soc_camera_probe(struct soc_camera_device *icd)
return 0;
-esdpwr:
- video_unregister_device(icd-vdev);
evidstart:
mutex_unlock(icd-video_lock);
soc_camera_free_user_formats(icd);
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/9] soc-camera: Pass the physical device to the power operation
There will be no soc_camera_device instance with a soc-camera device is
used with a non soc-camera host, so we won't be able to pass the
soc_camera_device fake platform device to board code. Pass the physical
device instead.
The argument is currently not used by any board file so this is safe.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_camera.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index e7c6809..b03ffec 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -62,7 +62,7 @@ static int soc_camera_power_on(struct soc_camera_device *icd,
}
if (icl-power) {
- ret = icl-power(icd-pdev, 1);
+ ret = icl-power(icd-control, 1);
if (ret 0) {
dev_err(icd-pdev,
Platform failed to power-on the camera.\n);
@@ -78,7 +78,7 @@ static int soc_camera_power_on(struct soc_camera_device *icd,
esdpwr:
if (icl-power)
- icl-power(icd-pdev, 0);
+ icl-power(icd-control, 0);
elinkpwr:
regulator_bulk_disable(icl-num_regulators,
icl-regulators);
@@ -95,7 +95,7 @@ static int soc_camera_power_off(struct soc_camera_device *icd,
return ret;
if (icl-power) {
- ret = icl-power(icd-pdev, 0);
+ ret = icl-power(icd-control, 0);
if (ret 0) {
dev_err(icd-pdev,
Platform failed to power-off the camera.\n);
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.6] V4L2 API cleanups
Em 11-06-2012 06:39, Sakari Ailus escreveu: On Mon, Jun 11, 2012 at 09:50:54AM +0200, Laurent Pinchart wrote: Hi Sakari, On Sunday 10 June 2012 23:22:59 Sakari Ailus wrote: Hi Mauro, Here are two V4L2 API cleanup patches; the first removes __user from videodev2.h from a few places, making it possible to use the header file as such in user space, while the second one changes the v4l2_buffer.input field back to reserved. The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181: [media] mt9m032: Implement V4L2_CID_PIXEL_RATE control (2012-05-24 09:27:24 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6 Sakari Ailus (2): v4l: Remove __user from interface structure definitions NAK, sorry. __user has a purpose, we need to add it where it's missing, not remove it where it's rightfully present. It's not quite as simple as adding __user everywhere it might belong to --- these structs are being used in kernel space, too. Only kernelspace see __user. The make headers_install target removes __user from the userspace copy. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.6] V4L2 API cleanups
Em 10-06-2012 17:22, Sakari Ailus escreveu: Hi Mauro, Here are two V4L2 API cleanup patches; the first removes __user from videodev2.h from a few places, making it possible to use the header file as such in user space, while the second one changes the v4l2_buffer.input field back to reserved. The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181: [media] mt9m032: Implement V4L2_CID_PIXEL_RATE control (2012-05-24 09:27:24 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6 Sakari Ailus (2): v4l: Remove __user from interface structure definitions v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT Indeed, no drivers use V4L2_BUF_FLAG_INPUT, although I think this should be used there, for some devices. There are several surveillance boards (mostly bttv boards, but there are also cx88 and saa7134 models in the market) where the same chip is used by up to 4 cameras. What software does is to switch the video input to sample one of those cameras on a given frequency (1/60Hz or 1/30Hz), in order to collect the streams for the 4 cameras. Without an input field there at the buffer metadata, it might happen that software would look into the wrong input. That's said, considering that: 1) no driver is currently filling buffer queue with its inputs field, this flag is not used anywhere; 2) an implementation for input switch currently requires userspace to tell Kernel to switch to the next input, with is racy; 3) a model where the Kernel itself would switch to the next input would require some Kernelspace changes. I agree that we can just remove this bad implementation. If latter needed, we'll need to not only reapply this patch but also to add a better way to allow time-sharing the same video sampler with multiple inputs. So, I'll apply this patch. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] omap3isp: fix dqbuf description comment
Hi Michael, Thanks for the patch. On Wednesday 27 June 2012 17:06:57 Michael Jones wrote: Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- drivers/media/video/omap3isp/ispqueue.c |9 ++--- 1 files changed, 2 insertions(+), 7 deletions(-) This comment looks like it was a copy-paste from the description of qbuf. You're right. I've applied your patch to my tree, with a slightly modified comment. diff --git a/drivers/media/video/omap3isp/ispqueue.c b/drivers/media/video/omap3isp/ispqueue.c index 5fda5d0..23915ce 100644 --- a/drivers/media/video/omap3isp/ispqueue.c +++ b/drivers/media/video/omap3isp/ispqueue.c @@ -908,13 +908,8 @@ done: * * This function is intended to be used as a VIDIOC_DQBUF ioctl handler. * - * The v4l2_buffer structure passed from userspace is first sanity tested. If - * sane, the buffer is then processed and added to the main queue and, if the - * queue is streaming, to the IRQ queue. - * - * Before being enqueued, USERPTR buffers are checked for address changes. If - * the buffer has a different userspace address, the old memory area is unlocked - * and the new memory area is locked. + * if nonblocking=1, returns -EAGAIN if no buffer is available. + * if nonblocking=0, waits on IRQ queue until a buffer becomes available. */ int omap3isp_video_queue_dqbuf(struct isp_video_queue *queue, struct v4l2_buffer *vbuf, int nonblocking) -- 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 FOR 3.6] V4L2 API cleanups
Hi Mauro, Mauro Carvalho Chehab wrote: Em 10-06-2012 17:22, Sakari Ailus escreveu: Hi Mauro, Here are two V4L2 API cleanup patches; the first removes __user from videodev2.h from a few places, making it possible to use the header file as such in user space, while the second one changes the v4l2_buffer.input field back to reserved. The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181: [media] mt9m032: Implement V4L2_CID_PIXEL_RATE control (2012-05-24 09:27:24 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6 Sakari Ailus (2): v4l: Remove __user from interface structure definitions v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT Indeed, no drivers use V4L2_BUF_FLAG_INPUT, although I think this should be used there, for some devices. There are several surveillance boards (mostly bttv boards, but there are also cx88 and saa7134 models in the market) where the same chip is used by up to 4 cameras. What software does is to switch the video input to sample one of those cameras on a given frequency (1/60Hz or 1/30Hz), in order to collect the streams for the 4 cameras. Without an input field there at the buffer metadata, it might happen that software would look into the wrong input. That's said, considering that: 1) no driver is currently filling buffer queue with its inputs field, this flag is not used anywhere; 2) an implementation for input switch currently requires userspace to tell Kernel to switch to the next input, with is racy; 3) a model where the Kernel itself would switch to the next input would require some Kernelspace changes. I agree that we can just remove this bad implementation. If latter needed, we'll need to not only reapply this patch but also to add a better way to allow time-sharing the same video sampler with multiple inputs. So, I'll apply this patch. Thanks! There was a discussion between Ezequiel and Hans that in my understanding led to a conclusion there's no such use case, at least one which would be properly supported by the hardware. (Please correct me if I'm mistaken.) URL:http://www.spinics.net/lists/linux-media/msg48474.html So if we ever get such hardware then we could start rethinking it. :-) Cheers, -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.6] V4L2 API cleanups
On Thu, Jul 5, 2012 at 6:21 PM, Sakari Ailus sakari.ai...@iki.fi wrote: There was a discussion between Ezequiel and Hans that in my understanding led to a conclusion there's no such use case, at least one which would be properly supported by the hardware. (Please correct me if I'm mistaken.) Concerning stk1160 devices with several video input (I own one with four video inputs), I can say that this is currently handled throught ioctl VIDIOC_S_INPUT. I.e, user must explicitly select one (and only one) input. In my very humble opinion (and assuming I understand this discussion properly) I think that if there is no hardware support for streaming multiple inputs at the same time, it's not kernel job to simulate it and cycle through several inputs and several buffer queues. My two cents, Ezequiel. -- 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 FOR 3.6] V4L2 API cleanups
Em 05-07-2012 18:21, Sakari Ailus escreveu: Hi Mauro, Mauro Carvalho Chehab wrote: Em 10-06-2012 17:22, Sakari Ailus escreveu: Hi Mauro, Here are two V4L2 API cleanup patches; the first removes __user from videodev2.h from a few places, making it possible to use the header file as such in user space, while the second one changes the v4l2_buffer.input field back to reserved. The following changes since commit 5472d3f17845c4398c6a510b46855820920c2181: [media] mt9m032: Implement V4L2_CID_PIXEL_RATE control (2012-05-24 09:27:24 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6 Sakari Ailus (2): v4l: Remove __user from interface structure definitions v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT Indeed, no drivers use V4L2_BUF_FLAG_INPUT, although I think this should be used there, for some devices. There are several surveillance boards (mostly bttv boards, but there are also cx88 and saa7134 models in the market) where the same chip is used by up to 4 cameras. What software does is to switch the video input to sample one of those cameras on a given frequency (1/60Hz or 1/30Hz), in order to collect the streams for the 4 cameras. Without an input field there at the buffer metadata, it might happen that software would look into the wrong input. That's said, considering that: 1) no driver is currently filling buffer queue with its inputs field, this flag is not used anywhere; 2) an implementation for input switch currently requires userspace to tell Kernel to switch to the next input, with is racy; 3) a model where the Kernel itself would switch to the next input would require some Kernelspace changes. I agree that we can just remove this bad implementation. If latter needed, we'll need to not only reapply this patch but also to add a better way to allow time-sharing the same video sampler with multiple inputs. So, I'll apply this patch. Thanks! There was a discussion between Ezequiel and Hans that in my understanding led to a conclusion there's no such use case, at least one which would be properly supported by the hardware. (Please correct me if I'm mistaken.) URL:http://www.spinics.net/lists/linux-media/msg48474.html So if we ever get such hardware then we could start rethinking it. :-) This use case exists and I've seen several embedded surveillance systems doing the right thing there (didn't look inside the source code), but I suspect that there's a lack of open-source applications over there and perhaps this used to be working with V4L1 API. Once I got one of such hardware borrowed and I noticed the issue, but I didn't manage to get more than one camera in order to properly address it there. It probably makes sense to have one set of video buffers per input, and let the Kernel to do switch the buffer per input, but doing that is not trivial with the V4L2 API. Another alternative would be to add an ioctl that would allow userspace to tell what inputs should be multiplexed, and then use the current way. Doing input switching everytime switching is bad, as the framerate per input will reduce. Also, input switching may generate artifacts, so drivers need to be aware of that and do the switching during the vertical retrace time. Anyway, let's discuss it the next time someone come up with this issue, and have some hardware with multiple cameras per input to test it. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: add selection API host operations
Hi Guennadi,
Thanks for the patch.
On Friday 22 June 2012 18:40:08 Guennadi Liakhovetski wrote:
Add .get_selection() and .set_selection() soc-camera host driver
operations. Additionally check, that the user is not trying to change the
output sizes during a running capture.
How will that interact with the crop operations ? The goal is to move away
from crop operations to selection operations, so we need to establish clear
rules.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c index 0421bf9..72798d2 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -902,6 +902,65 @@ static int soc_camera_s_crop(struct file *file, void
*fh, return ret;
}
+static int soc_camera_g_selection(struct file *file, void *fh,
+ struct v4l2_selection *s)
+{
+ struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+
+ /* With a wrong type no need to try to fall back to cropping */
+ if (s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ if (!ici-ops-get_selection)
+ return -ENOTTY;
+
+ return ici-ops-get_selection(icd, s);
+}
+
+static int soc_camera_s_selection(struct file *file, void *fh,
+ struct v4l2_selection *s)
+{
+ struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ int ret;
+
+ /* In all these cases cropping emulation will not help */
+ if (s-type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
+ (s-target != V4L2_SEL_TGT_COMPOSE_ACTIVE
+ s-target != V4L2_SEL_TGT_CROP_ACTIVE))
+ return -EINVAL;
+
+ if (s-target == V4L2_SEL_TGT_COMPOSE_ACTIVE) {
+ /* No output size change during a running capture! */
+ if (is_streaming(ici, icd)
+ (icd-user_width != s-r.width ||
+ icd-user_height != s-r.height))
+ return -EBUSY;
+
+ /*
+ * Only one user is allowed to change the output format, touch
+ * buffers, start / stop streaming, poll for data
+ */
+ if (icd-streamer icd-streamer != file)
+ return -EBUSY;
+ }
+
+ if (!ici-ops-set_selection)
+ return -ENOTTY;
+
+ ret = ici-ops-set_selection(icd, s);
+ if (!ret
+ s-target == V4L2_SEL_TGT_COMPOSE_ACTIVE) {
+ icd-user_width = s-r.width;
+ icd-user_height = s-r.height;
+ if (!icd-streamer)
+ icd-streamer = file;
+ }
+
+ return ret;
+}
+
static int soc_camera_g_parm(struct file *file, void *fh,
struct v4l2_streamparm *a)
{
@@ -1405,6 +1464,8 @@ static const struct v4l2_ioctl_ops
soc_camera_ioctl_ops = { .vidioc_cropcap = soc_camera_cropcap,
.vidioc_g_crop = soc_camera_g_crop,
.vidioc_s_crop = soc_camera_s_crop,
+ .vidioc_g_selection = soc_camera_g_selection,
+ .vidioc_s_selection = soc_camera_s_selection,
.vidioc_g_parm = soc_camera_g_parm,
.vidioc_s_parm = soc_camera_s_parm,
.vidioc_g_chip_ident = soc_camera_g_chip_ident,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index d865dcf..f997d6a 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -86,6 +86,8 @@ struct soc_camera_host_ops {
int (*cropcap)(struct soc_camera_device *, struct v4l2_cropcap *);
int (*get_crop)(struct soc_camera_device *, struct v4l2_crop *);
int (*set_crop)(struct soc_camera_device *, struct v4l2_crop *);
+ int (*get_selection)(struct soc_camera_device *, struct v4l2_selection
*);
+ int (*set_selection)(struct soc_camera_device *, struct v4l2_selection
*); /*
* The difference to .set_crop() is, that .set_livecrop is not allowed
* to change the output sizes
--
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 FOR 3.6] V4L2 API cleanups
Em 05-07-2012 18:31, Ezequiel Garcia escreveu: On Thu, Jul 5, 2012 at 6:21 PM, Sakari Ailus sakari.ai...@iki.fi wrote: There was a discussion between Ezequiel and Hans that in my understanding led to a conclusion there's no such use case, at least one which would be properly supported by the hardware. (Please correct me if I'm mistaken.) Concerning stk1160 devices with several video input (I own one with four video inputs), I can say that this is currently handled throught ioctl VIDIOC_S_INPUT. I.e, user must explicitly select one (and only one) input. In my very humble opinion (and assuming I understand this discussion properly) I think that if there is no hardware support for streaming multiple inputs at the same time, it's not kernel job to simulate it and cycle through several inputs and several buffer queues. Sorry, but I don't agree: some devices are clearly targeted to be used with multiple inputs being cycled. For example, this one [1]: http://www.geovision.com.tw/PT/Prod_GV800.asp has only 4 BT878 chips, but each one can switch up to 4 cameras, and this very same card is used on several commercial solutions for surveillance. As far as I know, the input switching should be commanded externally, as the hardware doesn't do that automatically. Even so, it has a high-speed switch, so it should be fine to do it at vertical refresh time. Implementing support for it using VIDIOC_S_INPUT is a very poor solution, as an ioctl call may happen after the vertical retrace, causing artifacts. The proper solution would be for the Kernel to switch to the next input during the IRQ handler. So, when a frame for input 0 is received, the driver should be switching to the next active input as soon as possible, in order to avoid artifacts. [1] Sorry, I were unable to discover the English version of this specific page. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: Add stk1160 new driver
On 07/06/2012 12:11 AM, Mauro Carvalho Chehab wrote:
+static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer
*p)
+{
+struct stk1160 *dev = video_drvdata(file);
+
+if (!stk1160_is_owner(dev, file))
+return -EBUSY;
+
+return vb2_dqbuf(dev-vb_vidq, p, file-f_flags O_NONBLOCK);
Why to use O_NONBLOCK here? it should be doing whatever userspace wants.
This is OK, since the third argument to vb2_dqbuf() is a boolean indicating
whether this call should be blocking or not. And a O_NONBLOCK masks this
information out from file-f_flags.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: Add stk1160 new driver
Em 05-07-2012 19:36, Sylwester Nawrocki escreveu:
On 07/06/2012 12:11 AM, Mauro Carvalho Chehab wrote:
+static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer
*p)
+{
+ struct stk1160 *dev = video_drvdata(file);
+
+ if (!stk1160_is_owner(dev, file))
+ return -EBUSY;
+
+ return vb2_dqbuf(dev-vb_vidq, p, file-f_flags O_NONBLOCK);
Why to use O_NONBLOCK here? it should be doing whatever userspace wants.
This is OK, since the third argument to vb2_dqbuf() is a boolean indicating
whether this call should be blocking or not. And a O_NONBLOCK masks this
information out from file-f_flags.
Ah! OK then.
It might be better to initialize it during vb2 initialization, at open,
instead of requiring this argument every time vb_dqbuf() is called.
Btw, just noticed a minor issue: an space is required before the operator.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] get_dvb_firmware: add logic to get sms1xx-hcw* firmware
The firmwares are there at the same place for a long time. However,
each time I need to remember where it is, I need to seek at the net.
The better is to just add a logic at the get_dvb_firmare script,
in order to obtain it from a reliable source.
Cc: Steven Toth st...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
Documentation/dvb/get_dvb_firmware | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index 94b0168..12d3952e 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -29,7 +29,7 @@ use IO::Handle;
af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
lme2510c_s7395_old, drxk, drxk_terratec_h5,
drxk_hauppauge_hvr930c, tda10071, it9135, it9137,
- drxk_pctv, drxk_terratec_htc_stick);
+ drxk_pctv, drxk_terratec_htc_stick, sms1xxx_hcw);
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -766,6 +766,28 @@ sub drxk_pctv {
$fwfile;
}
+sub sms1xxx_hcw {
+my $url = http://steventoth.net/linux/sms1xxx/;;
+my %files = (
+ 'sms1xxx-hcw-55xxx-dvbt-01.fw' = afb6f9fb9a71d64392e8564ef9577e5a,
+ 'sms1xxx-hcw-55xxx-dvbt-02.fw' = b44807098ba26e52cbedeadc052ba58f,
+ 'sms1xxx-hcw-55xxx-isdbt-02.fw' = dae934eeea85225acbd63ce6cfe1c9e4,
+);
+
+checkstandard();
+
+my $allfiles;
+foreach my $fwfile (keys %files) {
+ wgetfile($fwfile, $url/$fwfile);
+ verify($fwfile, $files{$fwfile});
+ $allfiles .= $fwfile;
+}
+
+$allfiles =~ s/^\s//;
+
+$allfiles;
+}
+
# ---
# Utilities
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] em28xx: fix em28xx-rc load
The logic that checks if a device has remote control is wrong. Due to that, the em28xx RC module is not loaded by default. Fix the logic, in order to make it work properly. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/video/em28xx/em28xx-cards.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c index 12bc54a..ca62b99 100644 --- a/drivers/media/video/em28xx/em28xx-cards.c +++ b/drivers/media/video/em28xx/em28xx-cards.c @@ -2888,7 +2888,7 @@ static void request_module_async(struct work_struct *work) if (dev-board.has_dvb) request_module(em28xx-dvb); - if (dev-board.has_ir_i2c !disable_ir) + if (dev-board.ir_codes !disable_ir) request_module(em28xx-rc); } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Avoid sysfs oops when an rc_dev's raw device is absent
Em 24-06-2012 21:00, Douglas Bagnall escreveu:
For some reason, when the lirc daemon learns that a usb remote control
has been unplugged, it wants to read the sysfs attributes of the
disappearing device. This is useful for uncovering transient
inconsistencies, but less so for keeping the system running when such
inconsistencies exist.
Under some circumstances (like every time I unplug my dvb stick from
my laptop), lirc catches an rc_dev whose raw event handler has been
removed (presumably by ir_raw_event_unregister), and proceeds to
interrogate the raw protocols supported by the NULL pointer.
This patch avoids the NULL dereference, and ignores the issue of how
this state of affairs came about in the first place.
Please add your Signed-off-by: as described at:
http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches
---
drivers/media/rc/rc-main.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 6e16b09..58789c9 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -775,10 +775,12 @@ static ssize_t show_protocols(struct device *device,
if (dev-driver_type == RC_DRIVER_SCANCODE) {
enabled = dev-rc_map.rc_type;
allowed = dev-allowed_protos;
- } else {
+ } else if (dev-raw) {
enabled = dev-raw-enabled_protocols;
allowed = ir_raw_get_allowed_protocols();
}
+ else
+ return -EINVAL;
The return code there should be -ENODEV, as the device got removed.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Avoid sysfs oops when an rc_dev's raw device is absent
Em 24-06-2012 22:44, Douglas Bagnall escreveu: hi, I probably should have sent that in reply to http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/49740 which is the problem it fixes. Some things which might be of interest: 1. I innocently followed the instructions on http://www.linuxtv.org/wiki/index.php/Maintaining_Git_trees (i.e., use v4l-dvb tree on top of linus tree) and spent a while looking at IR/ir-sysfs.c instead of rc/rc-main.c. How stable it seemed! no patches in years! So I added a warning at the top of the wiki page, though a fix from someone who knows would be preferable. Please help us updating the wiki pages. Unfortunately, almost all developers have no time to update wiki pages, and expect community help on that. 2. From the above, I ended up reading a lot of ancient history and saw that this was inadvertently sort of fixed for a few weeks in 2010 between a08c7c68f702e2a2797a4035b and d8b4b5822f51e2142b731b42. 3. I wrote: This patch avoids the NULL dereference, and ignores the issue of how this state of affairs came about in the first place. Would, in rc_unregister_device(), putting device_del(dev-dev) before ir_raw_event_unregister(dev) help? I've only been a kernel hacker for two hours so I am honestly clueless, but it seems like that might avert the race by hiding the structure from sysfs before it is pulled apart. Reverting the order might help on your specific case, but device_del() does more than just removing the driver: it also can free some used structures, with might lead into an OOPS, if the driver is polling for IR. So, your patch is likely less risky to cause side effects. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE: [PATCH v1] s5p-mfc: update MFC v4l2 driver to support MFC6.x
Hi Kamil, The patch for videodev2.h is already posted by Jeongtae Park and is under review. [1] Now as suggested by you, I will send that patch again and also by incorporating the review comments given there. [1] http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/45190 Regards Arun --- Original Message --- Sender : Kamil Debskik.deb...@samsung.com Software Engineer/Poland RD Center-Linux Platform (SSD)/Samsung Electronics Date : Jul 05, 2012 20:45 (GMT+05:30) Title : RE: [PATCH v1] s5p-mfc: update MFC v4l2 driver to support MFC6.x Hi Arun, First of all - your patch is incomplete. I cannot find a modified videodev2.h file. Compilation fails with a lot of undefined symbols - attached below. Please supply this file, then I will be able to provide you with more comments and a proper review. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center --- Errors In file included from drivers/media/video/s5p-mfc/s5p_mfc.c:25: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type make[4]: *** [drivers/media/video/s5p-mfc/s5p_mfc.o] Error 1 make[4]: *** Waiting for unfinished jobs In file included from drivers/media/video/s5p-mfc/s5p_mfc_intr.c:21: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type make[4]: *** [drivers/media/video/s5p-mfc/s5p_mfc_intr.o] Error 1 In file included from drivers/media/video/s5p-mfc/s5p_mfc_dec.c:27: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_dec.c:38: error: 'V4L2_PIX_FMT_NV12MT_16X16' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c:59: error: 'V4L2_PIX_FMT_NV21M' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c:73: error: 'V4L2_PIX_FMT_H264_MVC' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c:129: error: 'V4L2_PIX_FMT_VP8' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_dec.c: In function 'vidioc_try_fmt': drivers/media/video/s5p-mfc/s5p_mfc_dec.c:377: warning: comparison between pointer and integer drivers/media/video/s5p-mfc/s5p_mfc_dec.c: In function 'vidioc_s_fmt': drivers/media/video/s5p-mfc/s5p_mfc_dec.c:450: warning: comparison between pointer and integer make[4]: *** [drivers/media/video/s5p-mfc/s5p_mfc_dec.o] Error 1 In file included from drivers/media/video/s5p-mfc/s5p_mfc_enc.c:28: drivers/media/video/s5p-mfc/s5p_mfc_common.h:330: error: field 'hier_qp_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:335: error: field 'sei_fp_arrangement_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:338: error: field 'fmo_map_type' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_common.h:340: error: field 'fmo_chg_dir' has incomplete type drivers/media/video/s5p-mfc/s5p_mfc_enc.c:38: error: 'V4L2_PIX_FMT_NV12MT_16X16' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:59: error: 'V4L2_PIX_FMT_NV21M' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:113: error: 'V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_MAX_BITS' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:113: error: initializer element is not constant drivers/media/video/s5p-mfc/s5p_mfc_enc.c:113: error: (near initialization for 'controls[1].maximum') drivers/media/video/s5p-mfc/s5p_mfc_enc.c:126: error: 'V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BITS' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:126: error: initializer element is not constant drivers/media/video/s5p-mfc/s5p_mfc_enc.c:126: error: (near initialization for 'controls[3].id') drivers/media/video/s5p-mfc/s5p_mfc_enc.c:202: error: 'V4L2_CID_MPEG_VIDEO_VBV_DELAY' undeclared here (not in a function) drivers/media/video/s5p-mfc/s5p_mfc_enc.c:202: error: initializer element is not constant drivers/media/video/s5p-mfc/s5p_mfc_enc.c:202: error: (near
