Re: [PATCH] em28xx: return -ENOTTY for tuner + frequency ioctls if the device has no tuner
On Tue 15 January 2013 18:06:57 Frank Schäfer wrote: Am 14.01.2013 10:20, schrieb Hans Verkuil: On Sun January 13 2013 13:50:50 Frank Schäfer wrote: Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/media/usb/em28xx/em28xx-video.c |8 1 Datei geändert, 8 Zeilen hinzugefügt(+) diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index 2eabf2a..4a7f73c 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -1204,6 +1204,8 @@ static int vidioc_g_tuner(struct file *file, void *priv, struct em28xx *dev = fh-dev; int rc; + if (dev-tuner_type == TUNER_ABSENT) + return -ENOTTY; rc = check_dev(dev); if (rc 0) return rc; @@ -1224,6 +1226,8 @@ static int vidioc_s_tuner(struct file *file, void *priv, struct em28xx *dev = fh-dev; int rc; + if (dev-tuner_type == TUNER_ABSENT) + return -ENOTTY; rc = check_dev(dev); if (rc 0) return rc; @@ -1241,6 +1245,8 @@ static int vidioc_g_frequency(struct file *file, void *priv, struct em28xx_fh *fh = priv; struct em28xx *dev = fh-dev; + if (dev-tuner_type == TUNER_ABSENT) + return -ENOTTY; if (0 != f-tuner) return -EINVAL; @@ -1255,6 +1261,8 @@ static int vidioc_s_frequency(struct file *file, void *priv, struct em28xx *dev = fh-dev; int rc; + if (dev-tuner_type == TUNER_ABSENT) + return -ENOTTY; rc = check_dev(dev); if (rc 0) return rc; Rather than doing this in each ioctl, I recommend using v4l2_disable_ioctl instead. See for example drivers/media/pci/ivtv/ivtv-streams.c. Hmm, thanks. I just did the same we currently do for the VIDIOC_G/S/QUERY_STD and VIDIOC_G/S_AUDIO ioctls, but yeah, disabling seems to be better. Btw, what about VIDIOC_G/S_PARAM ? Do they make sense for cameras ? Absolutely. Actually, s_parm should be disabled in the non-camera case since s_parm only makes sense for webcams. Regards, Hans Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] s5p-g2d: Add support for G2D H/W Rev.4.1
Hi Sachin,
I have just one small comment...
On 01/07/2013 07:44 AM, Sachin Kamat wrote:
+static void *g2d_get_drv_data(struct platform_device *pdev)
+{
+ struct g2d_variant *driver_data = NULL;
+
+ driver_data = (struct g2d_variant *)
+ platform_get_device_id(pdev)-driver_data;
+
+ return driver_data;
+}
How about adding this to g2d.h as:
static inline struct g2d_variant *g2d_get_drv_data(struct platform_device *pdev)
{
return (struct g2d_variant *)platform_get_device_id(pdev)-driver_data;
}
?
Otherwise the patch looks OK to me.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] s5p-g2d: Add support for G2D H/W Rev.4.1
Hi Sylwester,
On 16 January 2013 15:43, Sylwester Nawrocki s.nawro...@samsung.com wrote:
Hi Sachin,
I have just one small comment...
On 01/07/2013 07:44 AM, Sachin Kamat wrote:
+static void *g2d_get_drv_data(struct platform_device *pdev)
+{
+ struct g2d_variant *driver_data = NULL;
+
+ driver_data = (struct g2d_variant *)
+ platform_get_device_id(pdev)-driver_data;
+
+ return driver_data;
+}
How about adding this to g2d.h as:
static inline struct g2d_variant *g2d_get_drv_data(struct platform_device
*pdev)
{
return (struct g2d_variant
*)platform_get_device_id(pdev)-driver_data;
}
?
OK. I will move it to g2d.h and resend the patch.
Otherwise the patch looks OK to me.
--
Thanks,
Sylwester
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 5/7] seqno-fence: Hardware dma-buf implementation of fencing (v4)
Op 16-01-13 07:28, Inki Dae schreef:
2013/1/15 Maarten Lankhorst m.b.lankho...@gmail.com:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) = 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Documentation/DocBook/device-drivers.tmpl | 1 +
drivers/base/fence.c | 38 +++
include/linux/seqno-fence.h | 105
++
3 files changed, 144 insertions(+)
create mode 100644 include/linux/seqno-fence.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 6f53fc0..ad14396 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,6 +128,7 @@ X!Edrivers/base/interface.c
!Edrivers/base/dma-buf.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
/sect1
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index 28e5ffd..1d3f29c 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -24,6 +24,7 @@
#include linux/slab.h
#include linux/export.h
#include linux/fence.h
+#include linux/seqno-fence.h
atomic_t fence_context_counter = ATOMIC_INIT(0);
EXPORT_SYMBOL(fence_context_counter);
@@ -284,3 +285,40 @@ out:
return ret;
}
EXPORT_SYMBOL(fence_default_wait);
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence-ops-enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence-ops-signaled
seqno_fence-ops-signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+
+ dma_buf_put(f-sync_buf);
+ if (f-ops-release)
+ f-ops-release(fence);
+ else
+ kfree(f);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+ return f-ops-wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+ .enable_signaling = seqno_enable_signaling,
+ .signaled = seqno_signaled,
+ .wait = seqno_wait,
+ .release = seqno_release
+};
+EXPORT_SYMBOL_GPL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index 000..603adc0
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,105 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ * Rob Clark rob.cl...@linaro.org
+ * Maarten Lankhorst maarten.lankho...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __LINUX_SEQNO_FENCE_H
+#define __LINUX_SEQNO_FENCE_H
+
+#include linux/fence.h
+#include linux/dma-buf.h
+
+struct seqno_fence {
+ struct fence base;
+
+ const struct fence_ops *ops;
+ struct dma_buf *sync_buf;
+ uint32_t seqno_ofs;
+};
Hi maarten,
I'm applying dma-fence v11 and seqno-fence v4 to exynos drm and have
some proposals.
The above seqno_fence structure has only one dmabuf. Shouldn't it have
mutiple dmabufs? For example, in case of drm driver, when pageflip is
requested, one framebuffer could have one more gem buffer for NV12M
format. And this
Re: [Linaro-mm-sig] [PATCH 5/7] seqno-fence: Hardware dma-buf implementation of fencing (v4)
2013/1/16 Maarten Lankhorst maarten.lankho...@canonical.com:
Op 16-01-13 07:28, Inki Dae schreef:
2013/1/15 Maarten Lankhorst m.b.lankho...@gmail.com:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) = 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Documentation/DocBook/device-drivers.tmpl | 1 +
drivers/base/fence.c | 38 +++
include/linux/seqno-fence.h | 105
++
3 files changed, 144 insertions(+)
create mode 100644 include/linux/seqno-fence.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 6f53fc0..ad14396 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,6 +128,7 @@ X!Edrivers/base/interface.c
!Edrivers/base/dma-buf.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
/sect1
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index 28e5ffd..1d3f29c 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -24,6 +24,7 @@
#include linux/slab.h
#include linux/export.h
#include linux/fence.h
+#include linux/seqno-fence.h
atomic_t fence_context_counter = ATOMIC_INIT(0);
EXPORT_SYMBOL(fence_context_counter);
@@ -284,3 +285,40 @@ out:
return ret;
}
EXPORT_SYMBOL(fence_default_wait);
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence-ops-enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence-ops-signaled
seqno_fence-ops-signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+
+ dma_buf_put(f-sync_buf);
+ if (f-ops-release)
+ f-ops-release(fence);
+ else
+ kfree(f);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+ return f-ops-wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+ .enable_signaling = seqno_enable_signaling,
+ .signaled = seqno_signaled,
+ .wait = seqno_wait,
+ .release = seqno_release
+};
+EXPORT_SYMBOL_GPL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index 000..603adc0
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,105 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ * Rob Clark rob.cl...@linaro.org
+ * Maarten Lankhorst maarten.lankho...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __LINUX_SEQNO_FENCE_H
+#define __LINUX_SEQNO_FENCE_H
+
+#include linux/fence.h
+#include linux/dma-buf.h
+
+struct seqno_fence {
+ struct fence base;
+
+ const struct fence_ops *ops;
+ struct dma_buf *sync_buf;
+ uint32_t seqno_ofs;
+};
Hi maarten,
I'm applying dma-fence v11 and seqno-fence v4 to exynos drm and have
some proposals.
The above seqno_fence structure has only one dmabuf. Shouldn't it have
mutiple dmabufs? For example, in case of drm driver, when pageflip is
requested, one
[PATCH 2/4] staging: media: go7007: firmware protection Protection for unfirmware load
Signed-off-by: Volokh Konstantin volok...@gmail.com
---
drivers/staging/media/go7007/go7007-usb.c |2 +-
drivers/staging/media/go7007/go7007-v4l2.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/go7007/go7007-usb.c
b/drivers/staging/media/go7007/go7007-usb.c
index 5443e25..a6cad15 100644
--- a/drivers/staging/media/go7007/go7007-usb.c
+++ b/drivers/staging/media/go7007/go7007-usb.c
@@ -1245,7 +1245,6 @@ static void go7007_usb_disconnect(struct usb_interface
*intf)
struct urb *vurb, *aurb;
int i;
- go-status = STATUS_SHUTDOWN;
usb_kill_urb(usb-intr_urb);
/* Free USB-related structs */
@@ -1269,6 +1268,7 @@ static void go7007_usb_disconnect(struct usb_interface
*intf)
kfree(go-hpi_context);
go7007_remove(go);
+ go-status = STATUS_SHUTDOWN;
}
static struct usb_driver go7007_usb_driver = {
diff --git a/drivers/staging/media/go7007/go7007-v4l2.c
b/drivers/staging/media/go7007/go7007-v4l2.c
index e6fa543..a69250f 100644
--- a/drivers/staging/media/go7007/go7007-v4l2.c
+++ b/drivers/staging/media/go7007/go7007-v4l2.c
@@ -1832,5 +1832,6 @@ void go7007_v4l2_remove(struct go7007 *go)
mutex_unlock(go-hw_lock);
if (go-video_dev)
video_unregister_device(go-video_dev);
- v4l2_device_unregister(go-v4l2_dev);
+ if (go-status != STATUS_SHUTDOWN)
+ v4l2_device_unregister(go-v4l2_dev);
}
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] staging: media: go7007: i2c GPIO initialization Reset i2c stuff for GO7007_BOARDID_ADLINK_MPG24 need reset GPIO always when encoder initialize
Signed-off-by: Volokh Konstantin volok...@gmail.com
---
drivers/staging/media/go7007/go7007-driver.c |5 +
drivers/staging/media/go7007/go7007-usb.c|3 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/go7007/go7007-driver.c
b/drivers/staging/media/go7007/go7007-driver.c
index a66e339..c0ea312 100644
--- a/drivers/staging/media/go7007/go7007-driver.c
+++ b/drivers/staging/media/go7007/go7007-driver.c
@@ -173,6 +173,11 @@ static int go7007_init_encoder(struct go7007 *go)
go7007_write_addr(go, 0x3c82, 0x0001);
go7007_write_addr(go, 0x3c80, 0x00fe);
}
+ if (go-board_id == GO7007_BOARDID_ADLINK_MPG24) {
+ /* set GPIO5 to be an output, currently low */
+ go7007_write_addr(go, 0x3c82, 0x);
+ go7007_write_addr(go, 0x3c80, 0x00df);
+ }
return 0;
}
diff --git a/drivers/staging/media/go7007/go7007-usb.c
b/drivers/staging/media/go7007/go7007-usb.c
index a6cad15..9dbf5ec 100644
--- a/drivers/staging/media/go7007/go7007-usb.c
+++ b/drivers/staging/media/go7007/go7007-usb.c
@@ -1110,9 +1110,6 @@ static int go7007_usb_probe(struct usb_interface *intf,
} else {
u16 channel;
- /* set GPIO5 to be an output, currently low */
- go7007_write_addr(go, 0x3c82, 0x);
- go7007_write_addr(go, 0x3c80, 0x00df);
/* read channel number from GPIO[1:0] */
go7007_read_addr(go, 0x3c81, channel);
channel = 0x3;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] staging: media: go7007: call_all stream stuff Some Additional stuff for v4l2_subdev stream events partial need for new style framework. Also need for wis_tw2804 notification stuff
Signed-off-by: Volokh Konstantin volok...@gmail.com --- drivers/staging/media/go7007/go7007-v4l2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/staging/media/go7007/go7007-v4l2.c b/drivers/staging/media/go7007/go7007-v4l2.c index a69250f..2330861 100644 --- a/drivers/staging/media/go7007/go7007-v4l2.c +++ b/drivers/staging/media/go7007/go7007-v4l2.c @@ -953,6 +953,7 @@ static int vidioc_streamon(struct file *file, void *priv, } mutex_unlock(go-hw_lock); mutex_unlock(gofh-lock); + call_all(go-v4l2_dev, video, s_stream, 1); return retval; } @@ -968,6 +969,7 @@ static int vidioc_streamoff(struct file *file, void *priv, mutex_lock(gofh-lock); go7007_streamoff(go); mutex_unlock(gofh-lock); + call_all(go-v4l2_dev, video, s_stream, 0); return 0; } -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] staging: media: go7007: memory clear fix memory clearing for v4l2_subdev allocation
Signed-off-by: Volokh Konstantin volok...@gmail.com --- drivers/staging/media/go7007/go7007-driver.c |2 +- drivers/staging/media/go7007/go7007-v4l2.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/go7007/go7007-driver.c b/drivers/staging/media/go7007/go7007-driver.c index ece2dd1..a66e339 100644 --- a/drivers/staging/media/go7007/go7007-driver.c +++ b/drivers/staging/media/go7007/go7007-driver.c @@ -571,7 +571,7 @@ struct go7007 *go7007_alloc(struct go7007_board_info *board, struct device *dev) struct go7007 *go; int i; - go = kmalloc(sizeof(struct go7007), GFP_KERNEL); + go = kzalloc(sizeof(struct go7007), GFP_KERNEL); if (go == NULL) return NULL; go-dev = dev; diff --git a/drivers/staging/media/go7007/go7007-v4l2.c b/drivers/staging/media/go7007/go7007-v4l2.c index a78133b..e6fa543 100644 --- a/drivers/staging/media/go7007/go7007-v4l2.c +++ b/drivers/staging/media/go7007/go7007-v4l2.c @@ -98,7 +98,7 @@ static int go7007_open(struct file *file) if (go-status != STATUS_ONLINE) return -EBUSY; - gofh = kmalloc(sizeof(struct go7007_file), GFP_KERNEL); + gofh = kzalloc(sizeof(struct go7007_file), GFP_KERNEL); if (gofh == NULL) return -ENOMEM; ++go-ref_count; -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] staging: media: go7007: memory clear fix memory clearing for v4l2_subdev allocation
On Wed, Jan 16, 2013 at 05:00:48PM +0400, Volokh Konstantin wrote: Signed-off-by: Volokh Konstantin volok...@gmail.com Acked-by: Dan Carpenter dan.carpen...@oracle.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/4] staging: media: go7007: firmware protection Protection for unfirmware load
The problem is that the firmware was being unloaded on disconnect? regards, dan carpenter -- 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/4] staging: media: go7007: i2c GPIO initialization Reset i2c stuff for GO7007_BOARDID_ADLINK_MPG24 need reset GPIO always when encoder initialize
You've added the writes for GO7007_BOARDID_ADLINK_MPG24 but removed them for GO7007_BOARDID_XMEN and GO7007_BOARDID_XMEN_III. Won't that break those boards? regards, dan carpenter -- 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 RFCv10 00/15] DVB QoS statistics API
Em Tue, 15 Jan 2013 22:37:40 +0200 Antti Palosaari cr...@iki.fi escreveu: On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote: Em Tue, 15 Jan 2013 17:26:17 +0200 Antti Palosaari cr...@iki.fi escreveu: On 01/15/2013 04:49 PM, Antti Palosaari wrote: I am a little bit lazy to read all those patches, but I assume it is possible: * return SNR (CNR) as both dB and linear? * return signal strength as both dBm and linear? And what happens when when multiple statistics are queried, but fronted cannot perform all those? Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to be returned, whilst rest are not possible? As I remember DVBv5 API is broken by design and cannot return error code per request. OK, I read that patch still. All these are OK as there is SCALE flag used to inform if there is measurement or not available. No anymore question about these. Issues what I still would like to raise now are: 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for the sure? I'm OK with that. I doubt that it would be practical, but we have 64 bits for it, so db/1000 will fit. 2) Counter are reset when DELIVERY SYSTEM is set, practically when tuning attempt is done. There is new callback for that, but no API command. Functionality is correct for my eyes, is that extra callback needed? Not sure. It should be noticed that, at least on ISDB, some sort of reset may happen, for example if one layer disappears. The global BER will (with the current code) reflect the lack of the layer, by not summing up the data from the removed layer. Perhaps it makes more sense to, instead, add a way for the driver to flag when a counter reset happened. 3) Post-BER. I don't need it, but is there someone else who thinks there should be both pre-BER and post-BER? IMHO, just better to leave it out to keep it simple. In practice both pre-BER and post-BER are running relatively, lets say if pre-BER shows number 1000 then post-BER shows only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much interest to return it for userspace. Of course someone would like to know how much inner coder is working and fixing error bits and in that case both BERs are nice... I don't see any need for it. In the case of ISDB, I'll likely convert the post-BER error into per-layer CNR, as it might be useful for one. I don't have any strong opinion on that though. 4) Returning bit counts as BER and UCB means also driver should start polling work in order to keep driver internal counters up to date. Returning BER as rate is cheaper in that mean, as driver could make decision how often to poll and in which condition (and return values from cache). Keeping track of total bit counts means continuous polling! The way it was specified, the bit count/block count is relative to the same period where bit error/block error count was taken, and are there to calculate BER and PER. Eh, then this is functionality is against 2) what I asked about functionality of the counter reset. You should make decision to increase counters continuously and reset only given condition (on channel tune as it is done now) OR leave whole counter reset and increase to responsibility of the driver. Currently, it is monotonically increased after (2). There is one exception for it on the current implementation: in the case of multi-layers, where one layer vanishes - the global measure will not sum up the count for the vanished layer. Get rid of this behavior is not easy (and probably not right). I think that, in practice, such event would take years to happen, as broadcasters won't be changing the layers layout without a good reason (like adding multi-program streams or adding HD program on a channel that used to have only SD). Do you see conflict here??? My opinion is to remove counter reset callback and leave all to responsibility of the driver. IMO, the better is to live the responsibility to the driver. In this case, it makes sense to specify in the API that the drivers will reset it before overflow, and add some flag to indicate that a counter got a reset. Not all frontends allow continuous measurement of BER and PER. In the case of mb86a20s, BER is currently not continuous. I think that there's a way to do continuous PER measurement, but I need to double-check it. Personally I am going to implement that way it returns those bit counts from the driver cache. Driver makes decision when to make measurements, like just after channel is tuned and after that maybe once per minute or so. Right now, it is driver's decision on how to make such measures. I can see two ways of updating the status flags: 1) during DVB frontend polling call to get_frontend (or to other stats/status callbacks); 2) on a kernel thread inside the frontend driver, updating the cache. (1) is serialized. However, if we're
Re: [PATCH 2/4] staging: media: go7007: firmware protection Protection for unfirmware load
On Wed, Jan 16, 2013 at 04:35:45PM +0300, Dan Carpenter wrote: The problem is that the firmware was being unloaded on disconnect? regards, dan carpenter If no firmware was loaded (no exists,wrong or some error) then rmmod fails with OOPS, so need some protection stuff -- 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 RFCv10 00/15] DVB QoS statistics API
Em Wed, 16 Jan 2013 09:56:12 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari cr...@iki.fi wrote: On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote: Em Tue, 15 Jan 2013 17:26:17 +0200 Antti Palosaari cr...@iki.fi escreveu: On 01/15/2013 04:49 PM, Antti Palosaari wrote: I am a little bit lazy to read all those patches, but I assume it is possible: * return SNR (CNR) as both dB and linear? * return signal strength as both dBm and linear? And what happens when when multiple statistics are queried, but fronted cannot perform all those? Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to be returned, whilst rest are not possible? As I remember DVBv5 API is broken by design and cannot return error code per request. OK, I read that patch still. All these are OK as there is SCALE flag used to inform if there is measurement or not available. No anymore question about these. Issues what I still would like to raise now are: 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for the sure? I'm OK with that. I doubt that it would be practical, but we have 64 bits for it, so db/1000 will fit. 2) Counter are reset when DELIVERY SYSTEM is set, practically when tuning attempt is done. There is new callback for that, but no API command. Functionality is correct for my eyes, is that extra callback needed? Not sure. It should be noticed that, at least on ISDB, some sort of reset may happen, for example if one layer disappears. The global BER will (with the current code) reflect the lack of the layer, by not summing up the data from the removed layer. Perhaps it makes more sense to, instead, add a way for the driver to flag when a counter reset happened. 3) Post-BER. I don't need it, but is there someone else who thinks there should be both pre-BER and post-BER? IMHO, just better to leave it out to keep it simple. In practice both pre-BER and post-BER are running relatively, lets say if pre-BER shows number 1000 then post-BER shows only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much interest to return it for userspace. Of course someone would like to know how much inner coder is working and fixing error bits and in that case both BERs are nice... I don't see any need for it. In the case of ISDB, I'll likely convert the post-BER error into per-layer CNR, as it might be useful for one. I don't have any strong opinion on that though. 4) Returning bit counts as BER and UCB means also driver should start polling work in order to keep driver internal counters up to date. Returning BER as rate is cheaper in that mean, as driver could make decision how often to poll and in which condition (and return values from cache). Keeping track of total bit counts means continuous polling! The way it was specified, the bit count/block count is relative to the same period where bit error/block error count was taken, and are there to calculate BER and PER. Eh, then this is functionality is against 2) what I asked about functionality of the counter reset. You should make decision to increase counters continuously and reset only given condition (on channel tune as it is done now) OR leave whole counter reset and increase to responsibility of the driver. Do you see conflict here??? My opinion is to remove counter reset callback and leave all to responsibility of the driver. This, Is exactly one of the arguments that I raised. All statistics measurements should be the responsibility of the driver. Anything other than that, such an API is broken. All statistics measurements are already driver's responsibility on the proposed patches. The question is when to reset the counters. Not all frontends allow continuous measurement of BER and PER. In the case of mb86a20s, BER is currently not continuous. I think that there's a way to do continuous PER measurement, but I need to double-check it. Personally I am going to implement that way it returns those bit counts from the driver cache. Driver makes decision when to make measurements, like just after channel is tuned and after that maybe once per minute or so. No Error Rate measurement, ie BER, PER or FER measurement can/will be continuous on *any* demodulator. There's one of the above measure on mb86a20s that can be continuous (MER). On continuous mode, the demod will automatically start the next measure when the results got available. There's a lock bit that prevents the data to be overridden during the time the value is being read. First, there should be the minimum number of frames that should pass through the decision box, then for that number of frames to occur, depending upon the delivery system and the implementation type, the time required for this to be calculated on the demodulator
PcTV Nanostick 290e -- DVB-C frontend only working after reconnecting the device
Hi, I'm not sure if this has been already reported, but I was playing around with Nanostick 290e today and I encountered some weird behavior with the DVB-C frontend. The DVB-C frontend only seems to work once after plugging in the device. During subsequent uses, it fails to lock on to signal. However, you can unplug the Nanostick, plug it back in, and it is able to lock on again. But only once -- then you have to replug it again. The exact actions that I took: 1. Plug in the Nanostick. 2. Run dvbstream to record a DVB-C stream -- works OK. 3. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. 4. Unplug the Nanostick. Plug it back in. 5. Run dvbstream to record a DVB-C stream -- works OK. 6. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. I'm using kernel 3.2.0 on Ubuntu x86. The DVB-T/T2 frontend doesn't display this behavior. If anyone's interested in debugging this, I'll be happy to provide more information. Regards- -Radek -- 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/4] staging: media: go7007: i2c GPIO initialization Reset i2c stuff for GO7007_BOARDID_ADLINK_MPG24 need reset GPIO always when encoder initialize
On Wed, Jan 16, 2013 at 04:36:08PM +0300, Dan Carpenter wrote:
You've added the writes for GO7007_BOARDID_ADLINK_MPG24 but removed
them for GO7007_BOARDID_XMEN and GO7007_BOARDID_XMEN_III. Won't
that break those boards?
I don`t remove code for GO7007_BOARDID_XMEN and GO7007_BOARDID_XMEN_III.
case there are auto reusing for XMen and XMen-III:
look old code:
if ((go-board_id == GO7007_BOARDID_XMEN ||
go-board_id == GO7007_BOARDID_XMEN_III)
go-i2c_adapter_online) {
union i2c_smbus_data data;
/* Check to see if register 0x0A is 0x76 */
i2c_smbus_xfer(go-i2c_adapter, 0x21, I2C_CLIENT_SCCB,
I2C_SMBUS_READ, 0x0A, I2C_SMBUS_BYTE_DATA, data);
if (data.byte != 0x76) {
if (assume_endura) {
go-board_id = GO7007_BOARDID_ENDURA;
usb-board = board = board_endura;
go-board_info = board-main_info;
strncpy(go-name, Pelco Endura,
sizeof(go-name));
} else {
u16 channel;
- /* set GPIO5 to be an output, currently low */
- go7007_write_addr(go, 0x3c82, 0x);
- go7007_write_addr(go, 0x3c80, 0x00df);
/* read channel number from GPIO[1:0] */
go7007_read_addr(go, 0x3c81, channel);
channel = 0x3;
go-board_id = GO7007_BOARDID_ADLINK_MPG24;
Here any XMen or XMen-III will reassigned as Adlink-mpg24 id
so any i2c initialization will reassigned to that id and we can use that id in
init_encoder.
usb-board = board = board_adlink_mpg24;
go-board_info = board-main_info;
go-channel_number = channel;
snprintf(go-name, sizeof(go-name),
Adlink PCI-MPG24, channel #%d,
channel);
}
}
}
regards,
dan carpenter
--
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] s5p-g2d: Add support for G2D H/W Rev.4.1
Hi Sachin,
I tested your patch on Exynos 4210 and it works. Ack on my side.
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Wednesday, January 16, 2013 11:24 AM
To: Sylwester Nawrocki
Cc: linux-media@vger.kernel.org; ajaykumar...@samsung.com;
patc...@linaro.org; Kamil Debski
Subject: Re: [PATCH] s5p-g2d: Add support for G2D H/W Rev.4.1
Hi Sylwester,
On 16 January 2013 15:43, Sylwester Nawrocki s.nawro...@samsung.com
wrote:
Hi Sachin,
I have just one small comment...
On 01/07/2013 07:44 AM, Sachin Kamat wrote:
+static void *g2d_get_drv_data(struct platform_device *pdev) {
+ struct g2d_variant *driver_data = NULL;
+
+ driver_data = (struct g2d_variant *)
+ platform_get_device_id(pdev)-driver_data;
+
+ return driver_data;
+}
How about adding this to g2d.h as:
static inline struct g2d_variant *g2d_get_drv_data(struct
platform_device *pdev) {
return (struct g2d_variant
*)platform_get_device_id(pdev)-driver_data;
}
?
OK. I will move it to g2d.h and resend the patch.
Otherwise the patch looks OK to me.
--
Thanks,
Sylwester
--
With warm regards,
Sachin
--
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/4] staging: media: go7007: i2c GPIO initialization Reset i2c stuff for GO7007_BOARDID_ADLINK_MPG24 need reset GPIO always when encoder initialize
On Wed, Jan 16, 2013 at 06:00:13PM +0400, Volokh Konstantin wrote: On Wed, Jan 16, 2013 at 04:36:08PM +0300, Dan Carpenter wrote: You've added the writes for GO7007_BOARDID_ADLINK_MPG24 but removed them for GO7007_BOARDID_XMEN and GO7007_BOARDID_XMEN_III. Won't that break those boards? I don`t remove code for GO7007_BOARDID_XMEN and GO7007_BOARDID_XMEN_III. case there are auto reusing for XMen and XMen-III: Ah. Grand. Reviewed-by: Dan Carpenter dan.carpen...@oracle.com regards, dan carpenter -- 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: PcTV Nanostick 290e -- DVB-C frontend only working after reconnecting the device
On 01/16/2013 03:58 PM, Radoslaw Moszczynski wrote: Hi, I'm not sure if this has been already reported, but I was playing around with Nanostick 290e today and I encountered some weird behavior with the DVB-C frontend. The DVB-C frontend only seems to work once after plugging in the device. During subsequent uses, it fails to lock on to signal. However, you can unplug the Nanostick, plug it back in, and it is able to lock on again. But only once -- then you have to replug it again. The exact actions that I took: 1. Plug in the Nanostick. 2. Run dvbstream to record a DVB-C stream -- works OK. 3. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. 4. Unplug the Nanostick. Plug it back in. 5. Run dvbstream to record a DVB-C stream -- works OK. 6. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. I'm using kernel 3.2.0 on Ubuntu x86. The DVB-T/T2 frontend doesn't display this behavior. If anyone's interested in debugging this, I'll be happy to provide more information. Could you test first quite latest Kernel, 3.7 or even 3.8. If 3.7 behaves similarly, then test older Kernel 3.0. Working only on first tuning attempt sounds like it should not be common problem - otherwise there should be million bug reports like that. 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: PcTV Nanostick 290e -- DVB-C frontend only working after reconnecting the device
With Ubuntu's 3.5 kernel, the DVB-C frontend is not registered at all -- only DVB-T/T2 is available. I'll do some more testing with newer/older kernels over the next few days. Regards- -Radek -Original Message- From: Antti Palosaari [mailto:cr...@iki.fi] Sent: Wednesday, January 16, 2013 3:37 PM To: Radoslaw Moszczynski Cc: linux-media@vger.kernel.org Subject: Re: PcTV Nanostick 290e -- DVB-C frontend only working after reconnecting the device On 01/16/2013 03:58 PM, Radoslaw Moszczynski wrote: Hi, I'm not sure if this has been already reported, but I was playing around with Nanostick 290e today and I encountered some weird behavior with the DVB-C frontend. The DVB-C frontend only seems to work once after plugging in the device. During subsequent uses, it fails to lock on to signal. However, you can unplug the Nanostick, plug it back in, and it is able to lock on again. But only once -- then you have to replug it again. The exact actions that I took: 1. Plug in the Nanostick. 2. Run dvbstream to record a DVB-C stream -- works OK. 3. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. 4. Unplug the Nanostick. Plug it back in. 5. Run dvbstream to record a DVB-C stream -- works OK. 6. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. I'm using kernel 3.2.0 on Ubuntu x86. The DVB-T/T2 frontend doesn't display this behavior. If anyone's interested in debugging this, I'll be happy to provide more information. Could you test first quite latest Kernel, 3.7 or even 3.8. If 3.7 behaves similarly, then test older Kernel 3.0. Working only on first tuning attempt sounds like it should not be common problem - otherwise there should be million bug reports like that. 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 RFCv10 00/15] DVB QoS statistics API
On Wed, Jan 16, 2013 at 7:26 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 16 Jan 2013 09:56:12 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari cr...@iki.fi wrote: On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote: Em Tue, 15 Jan 2013 17:26:17 +0200 Antti Palosaari cr...@iki.fi escreveu: On 01/15/2013 04:49 PM, Antti Palosaari wrote: I am a little bit lazy to read all those patches, but I assume it is possible: * return SNR (CNR) as both dB and linear? * return signal strength as both dBm and linear? And what happens when when multiple statistics are queried, but fronted cannot perform all those? Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to be returned, whilst rest are not possible? As I remember DVBv5 API is broken by design and cannot return error code per request. OK, I read that patch still. All these are OK as there is SCALE flag used to inform if there is measurement or not available. No anymore question about these. Issues what I still would like to raise now are: 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for the sure? I'm OK with that. I doubt that it would be practical, but we have 64 bits for it, so db/1000 will fit. 2) Counter are reset when DELIVERY SYSTEM is set, practically when tuning attempt is done. There is new callback for that, but no API command. Functionality is correct for my eyes, is that extra callback needed? Not sure. It should be noticed that, at least on ISDB, some sort of reset may happen, for example if one layer disappears. The global BER will (with the current code) reflect the lack of the layer, by not summing up the data from the removed layer. Perhaps it makes more sense to, instead, add a way for the driver to flag when a counter reset happened. 3) Post-BER. I don't need it, but is there someone else who thinks there should be both pre-BER and post-BER? IMHO, just better to leave it out to keep it simple. In practice both pre-BER and post-BER are running relatively, lets say if pre-BER shows number 1000 then post-BER shows only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much interest to return it for userspace. Of course someone would like to know how much inner coder is working and fixing error bits and in that case both BERs are nice... I don't see any need for it. In the case of ISDB, I'll likely convert the post-BER error into per-layer CNR, as it might be useful for one. I don't have any strong opinion on that though. 4) Returning bit counts as BER and UCB means also driver should start polling work in order to keep driver internal counters up to date. Returning BER as rate is cheaper in that mean, as driver could make decision how often to poll and in which condition (and return values from cache). Keeping track of total bit counts means continuous polling! The way it was specified, the bit count/block count is relative to the same period where bit error/block error count was taken, and are there to calculate BER and PER. Eh, then this is functionality is against 2) what I asked about functionality of the counter reset. You should make decision to increase counters continuously and reset only given condition (on channel tune as it is done now) OR leave whole counter reset and increase to responsibility of the driver. Do you see conflict here??? My opinion is to remove counter reset callback and leave all to responsibility of the driver. This, Is exactly one of the arguments that I raised. All statistics measurements should be the responsibility of the driver. Anything other than that, such an API is broken. All statistics measurements are already driver's responsibility on the proposed patches. The question is when to reset the counters. Maybe you should give more thoughts to what you say in comparison to your patch. It looks like your comments contradict your patch. Not all frontends allow continuous measurement of BER and PER. In the case of mb86a20s, BER is currently not continuous. I think that there's a way to do continuous PER measurement, but I need to double-check it. Personally I am going to implement that way it returns those bit counts from the driver cache. Driver makes decision when to make measurements, like just after channel is tuned and after that maybe once per minute or so. No Error Rate measurement, ie BER, PER or FER measurement can/will be continuous on *any* demodulator. There's one of the above measure on mb86a20s that can be continuous (MER). On continuous mode, the demod will automatically start the next measure when the results got available. There's a lock bit that prevents the data to be overridden during the time the value is being read. Please stop your bluffing of people. MER
Re: PcTV Nanostick 290e -- DVB-C frontend only working after reconnecting the device
On 01/16/2013 05:15 PM, Radoslaw Moszczynski wrote: With Ubuntu's 3.5 kernel, the DVB-C frontend is not registered at all -- only DVB-T/T2 is available. I'll do some more testing with newer/older kernels over the next few days. That is because of changed functionality, multi-frontend to single-frontend. As now there is only one frontend which supports all the standards. You should set desired standard using tool: $ dvb-fe-tool --set-delsys=DVBC/ANNEX_A I am not a big fan of that new method of setting frontend type, especially because there is now both old and new ways offered. That new method dropped also way to tell supported frontend capabilities to the userspace (anyway, almost all demods support all capabilities defined by standard, so it is not a big loss). regards Antti Regards- -Radek -Original Message- From: Antti Palosaari [mailto:cr...@iki.fi] Sent: Wednesday, January 16, 2013 3:37 PM To: Radoslaw Moszczynski Cc: linux-media@vger.kernel.org Subject: Re: PcTV Nanostick 290e -- DVB-C frontend only working after reconnecting the device On 01/16/2013 03:58 PM, Radoslaw Moszczynski wrote: Hi, I'm not sure if this has been already reported, but I was playing around with Nanostick 290e today and I encountered some weird behavior with the DVB-C frontend. The DVB-C frontend only seems to work once after plugging in the device. During subsequent uses, it fails to lock on to signal. However, you can unplug the Nanostick, plug it back in, and it is able to lock on again. But only once -- then you have to replug it again. The exact actions that I took: 1. Plug in the Nanostick. 2. Run dvbstream to record a DVB-C stream -- works OK. 3. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. 4. Unplug the Nanostick. Plug it back in. 5. Run dvbstream to record a DVB-C stream -- works OK. 6. Run dvbstream to record a DVB-C stream again -- fail to lock on signal. I'm using kernel 3.2.0 on Ubuntu x86. The DVB-T/T2 frontend doesn't display this behavior. If anyone's interested in debugging this, I'll be happy to provide more information. Could you test first quite latest Kernel, 3.7 or even 3.8. If 3.7 behaves similarly, then test older Kernel 3.0. Working only on first tuning attempt sounds like it should not be common problem - otherwise there should be million bug reports like that. regards Antti -- http://palosaari.fi/ -- 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 RFCv10 00/15] DVB QoS statistics API
Em Wed, 16 Jan 2013 20:49:05 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On Wed, Jan 16, 2013 at 7:26 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 16 Jan 2013 09:56:12 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari cr...@iki.fi wrote: On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote: Em Tue, 15 Jan 2013 17:26:17 +0200 Antti Palosaari cr...@iki.fi escreveu: On 01/15/2013 04:49 PM, Antti Palosaari wrote: ... No Error Rate measurement, ie BER, PER or FER measurement can/will be continuous on *any* demodulator. There's one of the above measure on mb86a20s that can be continuous (MER). On continuous mode, the demod will automatically start the next measure when the results got available. There's a lock bit that prevents the data to be overridden during the time the value is being read. Please stop your bluffing of people. MER or Modulation Error Ratio is the Ratio between the RMS Signal Power to the RMS Error Power. When you state that *any* Home segment device which is supposed to be a cheap device doing demodulation, Error Correction and a plethora of other things: is doing real time RMS computations and generating ratios out of it, It makes me laugh. Huh, can't you read my English? I never said *any* Home segment device. I said, instead, that, on *mb86a20s*, for some measurements, like MER and CNR, there are two operational modes: automatic and manual. On automatic mode, the demod is continuously updating the measurements, and no data is discarded on such measures. In manual mode, it measures just a certain amount of time and stops. The kthread needs to manually start another measure. So, it is actually taken samples of the measurement. In manual mode, the measures are discrete in the sense that, if errors occur between outside the measurement intervals, those errors won't affect the measurement report. In the automatic mode, the measures are continuous in the sense that every error bit will affect the measurement. Yet, on both modes, the demod will wait for a given bit count (the bit count is programmable) to update the corresponding I2C registers. Now, that lock bit in that demodulator of yours expresses most likely what it is doing, It is most likely taking a snapshot of the parameters, doing computations and outputting the values to some shadowed registers. Yes. I never said otherwise. As others have stated in various threads, please stop giving excuses to cause breaking stuff. On my tests with the hardware, I can't see anything broken. However, if you're seeing something broken, please point to the specific patch and patch hunk. The old API is not dependent on any DVB standard, but it is purely a measure. It is, as it assumes that there's just one physical channel per transponder. ISDB doesn't fit on such concept, as it has 3 physical channels, each with its own CNR, BER, etc. As shown on the fist email of this series, measured with a real hardware, the BER before viterbi on a given signal condition was: Layer A BER: QOS_BIT_ERROR_COUNT[1] = 236 QOS_TOTAL_BITS_COUNT[1] = 917490 Layer B BER: QOS_BIT_ERROR_COUNT[2] = 1087629 QOS_TOTAL_BITS_COUNT[2] = 66125823 Clearly, the statistics for layer A is very different than the ones for Layer B. With the above stats, layer B (12-segment) is unusable, as BER is just too high. However, Layer A (1-segment) is usable. There are two programs being transmitted on the above ISDB-T channel. The 1-seg one works, as FEC 1/2 will likely fix most (or all) of the 236 errors there; the 12-seg one doesn't, because of the low S/N ratio of layer B physical channel, and the BER is just too high for FEC 7/8 to correct. If you have sufficient documentation, you can scale your demodulator statistics to fit in that window area. I had done something similarly with a MB86A16 demodulator. IIRC, some effort was done on the STV0900 and STV0903 demodulator support as well to fit into that convention. All you need to do is scale the output of your demodulator to fit into that window. To what scale? dB? linear? 0% to 100%? As there's no way to tell what's the used scale, if some scale is required, _all_ demods are required to be converted to that scale, otherwise, userspace can't rely on the scale. Are you capable of doing such change on _all demods? If not, please stop arguing that the existing API can be fixable. Besides that, changing the existing stats to whatever scale breaks userspace compatibility. BREAKING USERSPACE IS A BIG NO. What you are stating are just excuses, that do not exist. The same issue will exist, even with a new API and newer drivers not complying to that API. I don't understand, why you fail to accept that fact. Newer drivers that don't implement an API right (being the a new one or an existing one) need to be fixed before being
Re: [PATCH 2/4] staging: media: go7007: firmware protection Protection for unfirmware load
Hi Volokh, On Wed, Jan 16, 2013 at 10:42 AM, Volokh Konstantin volok...@gmail.com wrote: On Wed, Jan 16, 2013 at 04:35:45PM +0300, Dan Carpenter wrote: The problem is that the firmware was being unloaded on disconnect? If no firmware was loaded (no exists,wrong or some error) then rmmod fails with OOPS, so need some protection stuff This explanation should be part of the commit message. It helps people understand what you're doing and why it's needed. BTW, none of this 4-patch series has a detailed commit message besides the commit title. I know they are small patches, but I'm sure you can do better than that! -- 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: [PATCH RFCv10 00/15] DVB QoS statistics API
On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: If you have sufficient documentation, you can scale your demodulator statistics to fit in that window area. I had done something similarly with a MB86A16 demodulator. IIRC, some effort was done on the STV0900 and STV0903 demodulator support as well to fit into that convention. All you need to do is scale the output of your demodulator to fit into that window. To what scale? dB? linear? 0% to 100%? It is in a db scale, scaled to the window, IIRC. In an application, you can convert that window area, you can convert it into a linear scale as well. As there's no way to tell what's the used scale, if some scale is required, _all_ demods are required to be converted to that scale, otherwise, userspace can't rely on the scale. Are you capable of doing such change on _all demods? If not, please stop arguing that the existing API can be fixable. Besides that, changing the existing stats to whatever scale breaks userspace compatibility. BREAKING USERSPACE IS A BIG NO. Consider this simple situation: Your new API is using get_frontend and is polling the hardware, Now an existing application is also doing monitoring of the statistics. So, now all the decision box calculations are screwed. Now, WHO BROKE USERSPACE ? The same situation will happen for any new API that's going to be built. Scaling the output values of a demodulator, which doesn't behave in accordance to the specifications is NOT BREAKING USERSPACE. What you are stating are just excuses, that do not exist. The same issue will exist, even with a new API and newer drivers not complying to that API. I don't understand, why you fail to accept that fact. Newer drivers that don't implement an API right (being the a new one or an existing one) need to be fixed before being merged. It is as simple as that. Okay, so what happens when a device that doesn't fit into your QoS API, or that the outputs of it are broken because of your API ? I don't think it is that simple. What is eventually wanted is a 0-100% scale, a self rotating counter etc scaled to a maxima minima, rather than adding in complexities. This already exists, all it needs to do is add some more devices to be scaled to that convention. And more importantly, one is not going to get that real professional measurements from these *home segment* devices. One of the chipset manufacturers once told me that the PC segment never was interested in any real world performance oriented devices, it is all about cost and hence it is stuck with such low devices. The DVB API should be able to fit on both home and professional segment. I don't see any professional hardware drivers being written for the Linux DVB API. From the feedbacks we're getting during the media mini-summits, there are vendors that seem to be working on it. Anyway, what I'm saying is that the API should not be bound to any specific market segment. If drivers will be submitted upstream for professional hardware or not is a separate issue. You are the one who had been touting all along on many linux-media threads, on linux-kernel threads and what not; that API changes should not be made for hardware that is not submitted upstream. So, I don't buy your argument at all. Why did you argue with nvidia people that they shouldn't use dma-buf, unless their driver is upstream. The same should hold good for what you are talking now as well. Anyway, the existing API will be kept. Userspace may opt to use the legacy API if they're not interested on a scaled value. That is simply stating, that whatever other people like it or not, you will whack nonsense in. No. I'm simply stating that removing the existing API is not an option. Also, plese stop with fallacy: it is not me saying that the existing API is broken. I'm just the poor guy that is trying to fix the already known issue. Several users, userspace developers and kernelspace developers complain about the existing stats API. Even _you_ submitted a proposal years ago for a new stats API to try solving those issues. I submitted a proposal to distinguish between the various statistics modes used by different devices. But eventually it was found that it wasn't possible to fit *all* devices that do exist into any convention. That was why I didn't pursue that proposal further. From what I learned from that, such information provided should be the simplest possible thing, if we were to generalize on a large set of devices. When being generalized with a large set of devices, however clever you are or whatever technical might you have, you will still have issues with some devices or the other. The end thoughts gathered from many people was that such a generalization is futile, unless it is made for a very specific usecase. A home user targeted API gets too complex and unusable in such an approach, making it harder
Re: [PATCH RFCv10 00/15] DVB QoS statistics API
Al 16/01/2013 5:26, En/na Manu Abraham ha escrit: The simplest and easiest way to achieve commonality between the various demodulators is to use the existing API and scale whatever documented demodulators to that scacle, to best possible way, rather than adding more ambiguity and breakage. Note that an older version of the linux dvb api documentation clearly specified the scale to use, i.e. see http://linuxtv.org/downloads/legacy/old/linux_dvb_api-20020304.pdf The bit error rate, as a multiple of 10E-9 , is stored into *ber. Example: a value of 2500 corresponds to a bit error rate of 2.5 * 10E-6 or 1 error in 40 bits. The signal-to-noise ratio, as a multiple of 10E-6 dB, is stored into *snr. Example: a value of 12,300,000 corresponds to a signal-to-noise ratio of 12.3 dB. The signal strength value, as a multiple of 10E-6 dBm, is stored into *strength. Example: a value of -12,500,000 corresponds to a signalstrength value of -12.5 dBm. but for some reason later revisions of the api don't include the scale Bye -- Luca -- 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 RFCv10 00/15] DVB QoS statistics API
Em Wed, 16 Jan 2013 23:56:48 +0530
Manu Abraham abraham.m...@gmail.com escreveu:
Consider this simple situation:
Your new API is using get_frontend and is polling the hardware, Now an
existing application is also doing monitoring of the statistics. So, now all
the decision box calculations are screwed.
-EREADTHEFUCKINGPATCHES
Patch 04/15:
...
+static int mb86a20s_read_signal_strength_from_cache(struct dvb_frontend *fe,
+ u16 *strength)
+{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+
+ *strength = c-strength.stat[0].uvalue;
+
+ return 0;
}
...
The returned value there is in the same range as before.
Enough. If you don't read the patches, you're just making everybody
loosing their time with your biased and incorrect comments.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv10 00/15] DVB QoS statistics API
On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote: On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab snip It is a common sense that the existing API is broken. If my proposal requires adjustments, please comment on each specific patchset, instead of filling this thread of destructive and useless complains. No, the concept of such a generalization is broken, as each new device will be different and trying to make more generalization is a waste of developer time and effort. The simplest approach would be to do a coarse approach, which is not a perfect world, but it will do some good results for all the people who use Linux-DVB. Still, repeating myself we are not dealing with high end professional devices. If we have such devices, then it makes sense to start such a discussion. Anyway professional devices will need a lot of other API extensions, so your arguments on the need for professional devices that do not exist are pointless and not agreeable to. Let's step back a bit. As a sophisticated API user, I want to be able to give my end-users the following information: * Signal strength in dBm * Signal quality as poor, OK and good. * Ideally, increase signal strength to improve things or attenuate signal to improve things In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER != 0, and good is UNC == BER == 0. The idea is that a user seeing poor knows that they will see glitches in the output; a user seeing OK knows that there's no glitching right now, but that the setup is marginal and may struggle if anything changes, and a user seeing good knows that they've got high quality signal. VDR wants even simpler - it just wants strength and quality on a 0 to 100 scale, where 100 is perfect, and 0 is nothing present. In both cases, we want per-layer quality for ISDB-T, for the reasons you've already outlined. So, how do you provide such information? Is it enough to simply provide strength in dBm, and quality as 0 to 100, where anything under 33 indicates uncorrected errors, and anything under 66 indicates that quality is marginal? -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.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 RFCv10 00/15] DVB QoS statistics API
On Thu, Jan 17, 2013 at 12:59 AM, Simon Farnsworth simon.farnswo...@onelan.com wrote: On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote: On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab snip It is a common sense that the existing API is broken. If my proposal requires adjustments, please comment on each specific patchset, instead of filling this thread of destructive and useless complains. No, the concept of such a generalization is broken, as each new device will be different and trying to make more generalization is a waste of developer time and effort. The simplest approach would be to do a coarse approach, which is not a perfect world, but it will do some good results for all the people who use Linux-DVB. Still, repeating myself we are not dealing with high end professional devices. If we have such devices, then it makes sense to start such a discussion. Anyway professional devices will need a lot of other API extensions, so your arguments on the need for professional devices that do not exist are pointless and not agreeable to. Let's step back a bit. As a sophisticated API user, I want to be able to give my end-users the following information: * Signal strength in dBm * Signal quality as poor, OK and good. * Ideally, increase signal strength to improve things or attenuate signal to improve things In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER != 0, and good is UNC == BER == 0. The idea is that a user seeing poor knows that they will see glitches in the output; a user seeing OK knows that there's no glitching right now, but that the setup is marginal and may struggle if anything changes, and a user seeing good knows that they've got high quality signal. VDR wants even simpler - it just wants strength and quality on a 0 to 100 scale, where 100 is perfect, and 0 is nothing present. In both cases, we want per-layer quality for ISDB-T, for the reasons you've already outlined. So, how do you provide such information? Is it enough to simply provide strength in dBm, and quality as 0 to 100, where anything under 33 indicates uncorrected errors, and anything under 66 indicates that quality is marginal? With DVB v3 the stats are interpreted thus: http://linuxtv.org/downloads/legacy/old/linux_dvb_api-20020304.pdf But, I am also not a big fan of that, but nevertheless it would have worked if the drivers complied to that specification. The important thing that we learn from history is that with a multitude of devices with different topologies and methodologies, it is too hard to achieve a rigid structure. Given the following statistical information available: status 0x1f --- The demodulator status bits. 0x1f means all bits set, everything ok. signal [0x...0x] --- Signal Strength. snr [0x...0x] --- Signal/Noise Ratio. ber [0...0x] --- Bit Error Rate. The less the better. unc [0...0x] --- Number of Uncorrectable Blocks. Small numbers are preferable. With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, though the rate difference could be very little. For one layer, you could map the details as is, into the existing convention, while the other 2 could be retrieved querying the details for each of the layers. This will keep it simple, to avoid calculating values to try to make a global value. Care should be taken, as to not change the current behaviour. That way, all applications will be happy and still be working as is, while you will get detailed information on a per-layer basis. Now, to achieve a common standard, the values need to be fit into the window, what most drivers are trying to do. In most cases, it could be difficult to convert from one format to another one in it's current form, without causing real breakage to existing drivers. That said for each of the drivers, it couldn't be difficult to convert to a relative scale say something like a 0-100% scale, without dBuV, or mV or dB/10, or dB/100. There can be a zillion reason why a demodulator is using a scale in it's driver. It might not be easy or make sense to change those values to a newer scale. But it wouldn't be that hard to scale those to a relative scale. In fact many or quite a lot of drivers while providing the information in some specific form are also in that relative form. Does everyone working on the DVB drivers posses a spectrum analyzer to do calibration to dBwhatever ? At my side, I have had access to one some time back, but not anymore. As Klaus said, any idiot will understand the relative scale clearly, without much after thought. This will also help that all the developers need to see are the maxima / minima, which could be easy. This is userspace requesting to make things simpler, not to make it even more worser. Manu -- 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
Re: [PATCH RFCv10 00/15] DVB QoS statistics API
On Thu, Jan 17, 2013 at 12:52 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Wed, 16 Jan 2013 23:56:48 +0530
Manu Abraham abraham.m...@gmail.com escreveu:
Consider this simple situation:
Your new API is using get_frontend and is polling the hardware, Now an
existing application is also doing monitoring of the statistics. So, now all
the decision box calculations are screwed.
-EREADTHEFUCKINGPATCHES
Patch 04/15:
...
+static int mb86a20s_read_signal_strength_from_cache(struct dvb_frontend *fe,
+ u16 *strength)
+{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+
+ *strength = c-strength.stat[0].uvalue;
+
+ return 0;
}
...
The returned value there is in the same range as before.
Enough. If you don't read the patches, you're just making everybody
loosing their time with your biased and incorrect comments.
-EFUCKEDUPMORON
The behaviour of the ioctls did change completely.
Manu
--
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:Wed Jan 16 19:00:17 CET 2013 git hash:3151d14aa6e983aa36d51a80d0477859f9ba12af 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: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: WARNINGS linux-3.8-rc1-i686: OK linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: WARNINGS linux-3.8-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 RFCv10 00/15] DVB QoS statistics API
Em Wed, 16 Jan 2013 19:29:28 +
Simon Farnsworth simon.farnswo...@onelan.com escreveu:
On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
snip
It is a common sense that the existing API is broken. If my proposal
requires adjustments, please comment on each specific patchset, instead
of filling this thread of destructive and useless complains.
No, the concept of such a generalization is broken, as each new device will
be different and trying to make more generalization is a waste of developer
time and effort. The simplest approach would be to do a coarse approach,
which is not a perfect world, but it will do some good results for all the
people who use Linux-DVB. Still, repeating myself we are not dealing with
high end professional devices. If we have such devices, then it makes sense
to start such a discussion. Anyway professional devices will need a lot of
other API extensions, so your arguments on the need for professional
devices that do not exist are pointless and not agreeable to.
Let's step back a bit. As a sophisticated API user, I want to be able to give
my end-users the following information:
* Signal strength in dBm
* Signal quality as poor, OK and good.
* Ideally, increase signal strength to improve things or attenuate signal
to improve things
In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER != 0,
and good is UNC == BER == 0. The idea is that a user seeing poor knows
that they will see glitches in the output; a user seeing OK knows that
there's no glitching right now, but that the setup is marginal and may
struggle if anything changes, and a user seeing good knows that they've got
high quality signal.
VDR wants even simpler - it just wants strength and quality on a 0 to 100
scale, where 100 is perfect, and 0 is nothing present.
In both cases, we want per-layer quality for ISDB-T, for the reasons you've
already outlined.
So, how do you provide such information? Is it enough to simply provide
strength in dBm, and quality as 0 to 100, where anything under 33 indicates
uncorrected errors, and anything under 66 indicates that quality is marginal?
Unfortunately, not all devices can provide strength in dBm.
On this RFC proposal, the driver will report if the device is providing
it either in dBm or on a 0% to 100% scale.
UNC, BER and S/N ratio (actually, C/N) measures are provided. Again, S/N
can either be in dB or on a 0% to 100% scale.
A high S/N ratio means low UNC/BER counts, so S/N is probably what VDR would
use for a quality indicator.
Assuming that is_isdb is true for ISDB, and that pid_layer is equal
to the ISDB layer for a given program (determined elsewhere in the
code), In order to get the QoS properties, I would code it like the
following (untested) code:
...
if (parms-version = 0x510) {
struct dtv_property dvb_prop[6];
struct dtv_properties props;
int j, layer;
dvb_prop[0].cmd = DTV_QOS_SIGNAL_STRENGTH;
dvb_prop[1].cmd = DTV_QOS_CNR;
dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;
props.num = 6;
props.props = dvb_prop;
if (is_isdb)
layer = pid_layer;
else
layer = 0;
/* Do a DVBv5.10 stats call */
if (ioctl(parms-fd, FE_GET_PROPERTY, props) == 0)
display_statistics(dvb_prop, layer);
} else
/* DVBv3 fallback */
...
Where a display_statistics() that just shows every available measure
would be:
void display_statistics(struct dtv_property dvb_prop[6], unsigned layer)
{
printf(Signal strength: );
if (dvb_prop[0].u.st.len dvb_prop[0].u.st.stat[0].scale ==
FE_SCALE_DECIBEL)
printf(%d dBm\n, (int)dvb_prop[0].u.st.stat[0].svalue);
else if (dvb_prop[0].u.st.len dvb_prop[0].u.st.stat[0].scale ==
FE_SCALE_DECIBEL)
printf(%03.2f %\n, 100.*dvb_prop[0].u.st.stat[0].uvalue /
65535);
} else {
printf(not available\n);
}
printf(Carrier to Noise ratio: );
if (dvb_prop[1].u.st.len layer dvb_prop[1].u.st.stat[layer].scale
== FE_SCALE_DECIBEL)
printf(%d dB\n, (int)dvb_prop[1].u.st.stat[layer].svalue);
else if (dvb_prop[1].u.st.len layer
dvb_prop[1].u.st.stat[layer].scale == FE_SCALE_DECIBEL)
printf(%03.2f %\n, 100.*dvb_prop[1].u.st.stat[layer].uvalue /
65535);
} else {
printf(not available\n);
}
if (dvb_prop[2].u.st.len layer dvb_prop[2].u.st.stat[layer].scale
== FE_SCALE_COUNTER
Re: [PATCH RFCv10 00/15] DVB QoS statistics API
Em Thu, 17 Jan 2013 03:07:21 +0530 Manu Abraham abraham.m...@gmail.com escreveu: With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, though the rate difference could be very little. Where? There's no way to report per-layer report with DVBv3. And no, the difference is not very little: $ dmesg|grep -e mb86a20s_get_main_CNR -e bit error before -e bit count before [12785.798746] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 252. [12785.810743] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535. [12785.856385] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12786.399684] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12786.410678] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 248. [12786.422693] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535. [12786.425547] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 80209. [12786.437537] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536. [12786.919289] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12786.930410] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 213. [12786.942553] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535. [12786.989127] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12787.387172] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12787.398062] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 234. [12787.409657] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535. [12787.412529] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 83533. [12787.424293] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536. [12788.052702] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12788.063443] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 183. [12788.075438] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535. [12788.078165] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 91502. [12788.089946] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536. [12788.126411] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12788.388646] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12788.399268] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 181. [12788.410887] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535. [12789.189254] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285) [12789.200099] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 191. [12789.211719] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535. [12789.214465] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 83536. [12789.226348] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVICO DVB-T Dual Express2 and media_build
Is there anything else I can provide to help with this? On 12/01/13 01:48, Greg Bell wrote: Hi Guys, I'm trying to get my DVICO DVB-T Dual Express2 card working on an Ubuntu 12.10 system with the 3.5.0 kernel. lspci tells me it's a Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder. Numerically, that's 14f1:8852. However on insmod cx23885, the driver tells me it doesn't know what the card is. card=11 and card=9 both allow the driver to initialize, but I cannot scan channels. The Wiki (http://www.linuxtv.org/wiki/index.php/DViCO_FusionHDTV_DVB-T_Dual_Express2) seems to indicate the someone got it working, but the Making It Work instructions are not clear. I downloaded and built media_build, in the hopes that CX23885 driver was more current. Sorry, I'm not a kernel dev so I'm a bit clueless on this part. If I try to insmod the driver that lives in media_build, I get a -1 Invalid parameters error. I'm hesitant to make install them all over my /lib tree. Is that necessary to just to test? Thanks, Greg Bell -- 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: tuners: initialize hw and fw ids in xc4000.c
These variables are implicitly initialized by passing them to xc_get_version(). However, initializing them to 0 explicitly will avoid compile warnings. Signed-off-by: Simon Que s...@chromium.org --- drivers/media/tuners/xc4000.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/tuners/xc4000.c b/drivers/media/tuners/xc4000.c index 4937712..d9dd53d 100644 --- a/drivers/media/tuners/xc4000.c +++ b/drivers/media/tuners/xc4000.c @@ -934,7 +934,8 @@ static int check_firmware(struct dvb_frontend *fe, unsigned int type, intrc = 0, is_retry = 0; u16hwmodel; v4l2_std_idstd0; - u8 hw_major, hw_minor, fw_major, fw_minor; + u8 hw_major = 0, hw_minor = 0; + u8 fw_major = 0, fw_minor = 0; dprintk(1, %s called\n, __func__); -- 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: [PATCH RFCv10 00/15] DVB QoS statistics API
On Thu, Jan 17, 2013 at 3:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 17 Jan 2013 03:07:21 +0530 Manu Abraham abraham.m...@gmail.com escreveu: With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, though the rate difference could be very little. Where? There's no way to report per-layer report with DVBv3. To retrieve on a per layer basis, you will need exactly one control for that. Nothing more. You don't need such an intrusive patch. And no, the difference is not very little: $ dmesg|grep -e mb86a20s_get_main_CNR -e bit error before -e bit count before Maybe the difference is small or big. Honestly, I have little trust in code output by you, after all the antics in recent threads. Manu -- 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 RFCv10 00/15] DVB QoS statistics API
On Thu, Jan 17, 2013 at 3:31 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 16 Jan 2013 19:29:28 + Simon Farnsworth simon.farnswo...@onelan.com escreveu: On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote: On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab snip It is a common sense that the existing API is broken. If my proposal requires adjustments, please comment on each specific patchset, instead of filling this thread of destructive and useless complains. No, the concept of such a generalization is broken, as each new device will be different and trying to make more generalization is a waste of developer time and effort. The simplest approach would be to do a coarse approach, which is not a perfect world, but it will do some good results for all the people who use Linux-DVB. Still, repeating myself we are not dealing with high end professional devices. If we have such devices, then it makes sense to start such a discussion. Anyway professional devices will need a lot of other API extensions, so your arguments on the need for professional devices that do not exist are pointless and not agreeable to. Let's step back a bit. As a sophisticated API user, I want to be able to give my end-users the following information: * Signal strength in dBm * Signal quality as poor, OK and good. * Ideally, increase signal strength to improve things or attenuate signal to improve things In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER != 0, and good is UNC == BER == 0. The idea is that a user seeing poor knows that they will see glitches in the output; a user seeing OK knows that there's no glitching right now, but that the setup is marginal and may struggle if anything changes, and a user seeing good knows that they've got high quality signal. VDR wants even simpler - it just wants strength and quality on a 0 to 100 scale, where 100 is perfect, and 0 is nothing present. In both cases, we want per-layer quality for ISDB-T, for the reasons you've already outlined. So, how do you provide such information? Is it enough to simply provide strength in dBm, and quality as 0 to 100, where anything under 33 indicates uncorrected errors, and anything under 66 indicates that quality is marginal? Unfortunately, not all devices can provide strength in dBm. MB86A20 is not the only demodulator driver with the Linux DVB. And not all devices can output in dB scale proposed by you, But any device output can be scaled in a relative way. So I don't see any reason why userspace has to deal with cumbersome controls to deal with redundant statistics, which is nonsense. Manu -- 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] s5p-g2d: Add support for G2D H/W Rev.4.1
Modified the G2D driver (which initially supported only H/W Rev.3)
to support H/W Rev.4.1 present on Exynos4x12 and Exynos52x0 SOCs.
-- Set the SRC and DST type to 'memory' instead of using reset values.
-- FIMG2D v4.1 H/W uses different logic for stretching(scaling).
-- Use CACHECTL_REG only with FIMG2D v3.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Acked-by: Kamil Debski k.deb...@samsung.com
---
Changes since v1:
Moved g2d_get_drv_data() to g2d.h as suggested by
Sylwester Nawrocki s.nawro...@samsung.com.
---
drivers/media/platform/s5p-g2d/g2d-hw.c | 16 +++---
drivers/media/platform/s5p-g2d/g2d-regs.h |8 +++
drivers/media/platform/s5p-g2d/g2d.c | 31 +++-
drivers/media/platform/s5p-g2d/g2d.h | 17 +--
4 files changed, 63 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/s5p-g2d/g2d-hw.c
b/drivers/media/platform/s5p-g2d/g2d-hw.c
index 5b86cbe..e87bd93 100644
--- a/drivers/media/platform/s5p-g2d/g2d-hw.c
+++ b/drivers/media/platform/s5p-g2d/g2d-hw.c
@@ -28,6 +28,7 @@ void g2d_set_src_size(struct g2d_dev *d, struct g2d_frame *f)
{
u32 n;
+ w(0, SRC_SELECT_REG);
w(f-stride 0x, SRC_STRIDE_REG);
n = f-o_height 0xFFF;
@@ -52,6 +53,7 @@ void g2d_set_dst_size(struct g2d_dev *d, struct g2d_frame *f)
{
u32 n;
+ w(0, DST_SELECT_REG);
w(f-stride 0x, DST_STRIDE_REG);
n = f-o_height 0xFFF;
@@ -82,10 +84,14 @@ void g2d_set_flip(struct g2d_dev *d, u32 r)
w(r, SRC_MSK_DIRECT_REG);
}
-u32 g2d_cmd_stretch(u32 e)
+void g2d_set_v41_stretch(struct g2d_dev *d, struct g2d_frame *src,
+ struct g2d_frame *dst)
{
- e = 1;
- return e 4;
+ w(DEFAULT_SCALE_MODE, SRC_SCALE_CTRL_REG);
+
+ /* inversed scaling factor: src is numerator */
+ w((src-c_width 16) / dst-c_width, SRC_XSCALE_REG);
+ w((src-c_height 16) / dst-c_height, SRC_YSCALE_REG);
}
void g2d_set_cmd(struct g2d_dev *d, u32 c)
@@ -96,7 +102,9 @@ void g2d_set_cmd(struct g2d_dev *d, u32 c)
void g2d_start(struct g2d_dev *d)
{
/* Clear cache */
- w(0x7, CACHECTL_REG);
+ if (d-variant-hw_rev == TYPE_G2D_3X)
+ w(0x7, CACHECTL_REG);
+
/* Enable interrupt */
w(1, INTEN_REG);
/* Start G2D engine */
diff --git a/drivers/media/platform/s5p-g2d/g2d-regs.h
b/drivers/media/platform/s5p-g2d/g2d-regs.h
index 02e1cf5..950c742 100644
--- a/drivers/media/platform/s5p-g2d/g2d-regs.h
+++ b/drivers/media/platform/s5p-g2d/g2d-regs.h
@@ -35,6 +35,9 @@
#define SRC_COLOR_MODE_REG 0x030C /* Src Image Color Mode reg */
#define SRC_LEFT_TOP_REG 0x0310 /* Src Left Top Coordinate reg */
#define SRC_RIGHT_BOTTOM_REG 0x0314 /* Src Right Bottom Coordinate reg */
+#define SRC_SCALE_CTRL_REG 0x0328 /* Src Scaling type select */
+#define SRC_XSCALE_REG 0x032c /* Src X Scaling ratio */
+#define SRC_YSCALE_REG 0x0330 /* Src Y Scaling ratio */
/* Parameter Setting Registers (Dest) */
#define DST_SELECT_REG 0x0400 /* Dest Image Selection reg */
@@ -113,3 +116,8 @@
#define DEFAULT_WIDTH 100
#define DEFAULT_HEIGHT 100
+#define DEFAULT_SCALE_MODE (2 0)
+
+/* Command mode register values */
+#define CMD_V3_ENABLE_STRETCH (1 4)
+
diff --git a/drivers/media/platform/s5p-g2d/g2d.c
b/drivers/media/platform/s5p-g2d/g2d.c
index dcd5335..7e41529 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -604,8 +604,13 @@ static void device_run(void *prv)
g2d_set_flip(dev, ctx-flip);
if (ctx-in.c_width != ctx-out.c_width ||
- ctx-in.c_height != ctx-out.c_height)
- cmd |= g2d_cmd_stretch(1);
+ ctx-in.c_height != ctx-out.c_height) {
+ if (dev-variant-hw_rev == TYPE_G2D_3X)
+ cmd |= CMD_V3_ENABLE_STRETCH;
+ else
+ g2d_set_v41_stretch(dev, ctx-in, ctx-out);
+ }
+
g2d_set_cmd(dev, cmd);
g2d_start(dev);
@@ -791,6 +796,7 @@ static int g2d_probe(struct platform_device *pdev)
}
def_frame.stride = (def_frame.width * def_frame.fmt-depth) 3;
+ dev-variant = g2d_get_drv_data(pdev);
return 0;
@@ -830,9 +836,30 @@ static int g2d_remove(struct platform_device *pdev)
return 0;
}
+static struct g2d_variant g2d_drvdata_v3x = {
+ .hw_rev = TYPE_G2D_3X,
+};
+
+static struct g2d_variant g2d_drvdata_v4x = {
+ .hw_rev = TYPE_G2D_4X, /* Revision 4.1 for Exynos4X12 and Exynos5 */
+};
+
+static struct platform_device_id g2d_driver_ids[] = {
+ {
+ .name = s5p-g2d,
+ .driver_data = (unsigned long)g2d_drvdata_v3x,
+ }, {
+ .name = s5p-g2d-v4x,
+ .driver_data = (unsigned
[cx231xx] Support for Arm / Omap working at all?
Hi! I'm trying to get an Hauppauge Live Usb 2 video grabber to run on on Omap4 (Gumstix Duovero). I'm using Sakomans omap-3.6 head kernel sources from http://git.sakoman.com/git/gitweb.cgi?p=linux.git;a=summary . The hardware is successfully detected on the USB host port, the driver loads perfectly including the firmware. With v4l2-ctl --all I can see if thee video signal on the composite port is ok or if the sync is lost, but as soon as I use any v4l2 software (e.g. yavta) to grab some images the driver uses 100% of the cpu, returns the first image and after some seconds I see EPROTO (-71) errors in dmesg. First I get cx231xx #0: can't change interface 3 alt. no to 0 (err=-71) and then UsbInterface::sendCommand, failed with status --71 I did the following tests: - checked that all patches I found (e.g from http://git.linuxtv.org/mchehab/cx231xx.git) are included in my kernel, including the URB DMA related patches and the timing patches - tried the same on an Gumstix Overo (Overo Fire and Overo WarerStorm) on several different header boards. - tried older kernels (3.2 and 2.6.32) with rougly the same results or known errors due to missing patches Unfortunately I can't use other capture devices because the final hardware is custom made with the cx23102 chip :-( I could use an omap3 instead of an omap4, but omap4 is preferred. My questions are: - Did anybody ever used the cx231xx driver with an omap3 or omap4 successfully? - If yes, could you let me know the kernel version and maybe the config? - Any hints what I could try? I'm an expirienced embedded C programmer but I dont have much expirience in USB kernel drivers. Any help is greatly appriciated! Thanks in Advance! Jan-- 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
