Re: [linux-media] [PATCH 2/2] stb0899: fixed reading of IF_AGC_GAIN register
When reading IF_AGC_GAIN register a wrong value for the base address
register was used (STB0899_DEMOD instead of STB0899_S2DEMOD). That
lead to a wrong signal strength value on DVB-S2 transponders.
Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
drivers/media/dvb/frontends/stb0899_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_drv.c
b/drivers/media/dvb/frontends/stb0899_drv.c
index 4a58afc..a2e9eba 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -983,7 +983,7 @@ static int stb0899_read_signal_strength(struct dvb_frontend
*fe, u16 *strength)
break;
case SYS_DVBS2:
if (internal-lock) {
-reg = STB0899_READ_S2REG(STB0899_DEMOD, IF_AGC_GAIN);
+reg = STB0899_READ_S2REG(STB0899_S2DEMOD, IF_AGC_GAIN);
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab,
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1, val);
Acked-by: Klaus Schmidinger klaus.schmidin...@tvdr.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] [PATCH 1/2] stb0899: set FE_HAS_SIGNAL flag in read_status
On 28.02.2012 19:40, Andreas Regel wrote:
In stb0899_read_status the FE_HAS_SIGNAL flag was not set in case of a
successful carrier lock. This change fixes that.
Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
drivers/media/dvb/frontends/stb0899_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_drv.c
b/drivers/media/dvb/frontends/stb0899_drv.c
index 38565be..4a58afc 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -1071,7 +1071,7 @@ static int stb0899_read_status(struct dvb_frontend *fe,
enum fe_status *status)
reg = stb0899_read_reg(state, STB0899_VSTATUS);
if (STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg)) {
dprintk(state-verbose, FE_DEBUG, 1, FE_HAS_CARRIER |
FE_HAS_LOCK);
-*status |= FE_HAS_CARRIER | FE_HAS_LOCK;
+*status |= FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_LOCK;
reg = stb0899_read_reg(state, STB0899_PLPARM);
if (STB0899_GETFIELD(VITCURPUN, reg)) {
@@ -1088,7 +1088,7 @@ static int stb0899_read_status(struct dvb_frontend *fe,
enum fe_status *status)
if (internal-lock) {
reg = STB0899_READ_S2REG(STB0899_S2DEMOD, DMD_STAT2);
if (STB0899_GETFIELD(UWP_LOCK, reg) STB0899_GETFIELD(CSM_LOCK,
reg)) {
-*status |= FE_HAS_CARRIER;
+*status |= FE_HAS_SIGNAL | FE_HAS_CARRIER;
dprintk(state-verbose, FE_DEBUG, 1,
UWP CSM Lock ! --- DVB-S2 FE_HAS_CARRIER);
Acked-by: Klaus Schmidinger klaus.schmidin...@tvdr.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 32/33] smiapp: Add driver.
Hi Sakari,
On Wednesday 29 February 2012 07:41:50 Sakari Ailus wrote:
On Mon, Feb 27, 2012 at 04:38:49PM +0100, Laurent Pinchart wrote:
On Monday 20 February 2012 03:57:11 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor
as three subdevs, pixel array, binner and scaler --- in case the device
has a scaler.
Currently it relies on the board code for external clock handling. There
is no fast way out of this dependency before the ISP drivers (omap3isp)
among others will be able to export that clock through the clock
framework instead.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
[snip]
+
+ dev_dbg(client-dev, format_model_type %s\n,
+ fmt_model_type == SMIAPP_FRAME_FORMAT_MODEL_TYPE_2BYTE
+ ? 2 byte :
+ fmt_model_type == SMIAPP_FRAME_FORMAT_MODEL_TYPE_4BYTE
+ ? 4 byte : is simply bad);
Simply ? :-)
Yeah, well, it's not that complex. :-) Do you think I should change that to
something else?
No, that's fine. I just found it funny that the format could be simply bad
:-)
[snip]
+ if (embedded_start == -1 || embedded_end == -1)
+ embedded_start = embedded_end = 0;
One assignment per line please.
I'm not sure if you gain any clarity with that, but I guess it's a norm
still. Fixed.
It's very easy to miss one of the assignments if you group them in a single
line.Or at least it is for me.
[snip]
+ case V4L2_CID_VBLANK:
+ exposure = sensor-exposure-val;
+
+ __smiapp_update_exposure_limits(sensor);
+
+ if (exposure sensor-exposure-maximum) {
+ sensor-exposure-val =
+ sensor-exposure-maximum;
+ rval = smiapp_set_ctrl(
+ sensor-exposure);
Shouldn't you call the V4L2 control API here instead ? Otherwise no
control change event will be generated for the exposure time. Will this
work as expected if the user sets the exposure time in the same
VIDIOC_S_EXT_CTRLS call ?
Good question. I'm holding the ctrl handler lock here and so can't use the
regular functions to perform the change. Perhaps time to implement
__v4l2_subdev_s_ext_ctrls() and use that?
Do you mean __v4l2_ctrl_s_ctrl() ? I think it would make sense, yes.
+ if (sensor-pixel_array-ctrl_handler.error) {
+ dev_err(client-dev,
+ pixel array controls initialization failed (%d)\n,
+ sensor-pixel_array-ctrl_handler.error);
Shouldn't you call v4l2_ctrl_handler_free() here ?
Yes. Fixed.
+ return sensor-pixel_array-ctrl_handler.error;
+ }
+
+ sensor-pixel_array-sd.ctrl_handler =
+ sensor-pixel_array-ctrl_handler;
+
+ v4l2_ctrl_cluster(2, sensor-hflip);
Shouldn't you move this before the control handler check ?
Why? It can't fail.
I thought it could fail. You could then leave it here, but it would be easier
from a maintenance point of view to check the error code after completing all
control-related initialization, as it would avoid introducing a bug if for
some reason the v4l2_ctrl_cluster() function needs to return an error later.
[snip]
+static int smiapp_update_mode(struct smiapp_sensor *sensor)
+{
This function isn't protected by the sensor mutex when called from
s_power, but it changes controls. The other call paths seem OK, but you
might want to double-check them.
It's actually not an issue. When s_power is being called there are no other
users and the power_lock serialises it.
Are you sure about that? s_power can be called from both the subdev video node
open() handlers (assuming the sensor is in the pipe).
I implemented it this way since the control setup acquires the same lock
that I would have to hold while powering up. The power_lock fixes this
issue.
I cleaned this up so that I won't take sensor-mutex at all anymore.
[snip]
+ dev_dbg(client-dev, module 0x%2.2x-0x%4.4x\n,
module 0x%02x-0x%04x\n (and similarly below) ?
Hmm. %y.yx means exactly y characters of %x. What does %0yx mean?
at least y characters, pad with 0. You can keep %y.yx if you prefer it.
+ minfo-manufacturer_id, minfo-model_id);
+
+ dev_dbg(client-dev,
+ module revision 0x%2.2x-0x%2.2x date %2.2d-%2.2d-%2.2d\n,
+ minfo-revision_number_major, minfo-revision_number_minor,
+ minfo-module_year, minfo-module_month, minfo-module_day);
+
+ dev_dbg(client-dev, sensor 0x%2.2x-0x%4.4x\n,
+ minfo-sensor_manufacturer_id, minfo-sensor_model_id);
+
+ dev_dbg(client-dev,
+ sensor revision 0x%2.2x firmware version 0x%2.2x\n,
+ minfo-sensor_revision_number, minfo-sensor_firmware_version);
+
+ dev_dbg(client-dev, smia version %2.2d smiapp version %2.2d\n,
+
Re: [Linaro-mm-sig] [PATCHv23 00/16] Contiguous Memory Allocator
2012/2/23 Marek Szyprowski m.szyprow...@samsung.com:
Hi,
This is (yet another) quick update of CMA patches. I've rebased them
onto next-20120222 tree from
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and
fixed the bug pointed by Aaro Koskinen.
For the whole series:
Tested-by: Barry Song baohua.s...@csr.com
and i also write a simple kernel helper to test the CMA:
/*
* kernek module helper for testing CMA
*
* Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group company.
*
* Licensed under GPLv2 or later.
*/
#include linux/module.h
#include linux/device.h
#include linux/fs.h
#include linux/miscdevice.h
#include linux/dma-mapping.h
#define CMA_NUM 10
static struct device *cma_dev;
static dma_addr_t dma_phys[CMA_NUM];
static void *dma_virt[CMA_NUM];
/* any read request will free coherent memory, eg.
* cat /dev/cma_test
*/
static ssize_t
cma_test_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
int i;
for (i = 0; i CMA_NUM; i++) {
if (dma_virt[i]) {
dma_free_coherent(cma_dev, (i + 1) * SZ_1M,
dma_virt[i], dma_phys[i]);
_dev_info(cma_dev, free virt: %p phys: %p\n,
dma_virt[i], (void
*)dma_phys[i]);
dma_virt[i] = NULL;
break;
}
}
return 0;
}
/*
* any write request will alloc coherent memory, eg.
* echo 0 /dev/cma_test
*/
static ssize_t
cma_test_write(struct file *file, const char __user *buf, size_t
count, loff_t *ppos)
{
int i;
int ret;
for (i = 0; i CMA_NUM; i++) {
if (!dma_virt[i]) {
dma_virt[i] = dma_alloc_coherent(cma_dev, (i + 1) *
SZ_1M,
dma_phys[i], GFP_KERNEL);
if (dma_virt[i])
_dev_info(cma_dev, alloc virt: %p phys: %p\n,
dma_virt[i], (void
*)dma_phys[i]);
else {
dev_err(cma_dev, no mem in CMA area\n);
ret = -ENOMEM;
}
break;
}
}
return count;
}
static const struct file_operations cma_test_fops = {
.owner =THIS_MODULE,
.read =cma_test_read,
.write =cma_test_write,
};
static struct miscdevice cma_test_misc = {
.name = cma_test,
.fops = cma_test_fops,
};
static int __init cma_test_init(void)
{
int ret = 0;
ret = misc_register(cma_test_misc);
if (unlikely(ret)) {
pr_err(failed to register cma test misc device!\n);
return ret;
}
cma_dev = cma_test_misc.this_device;
cma_dev-coherent_dma_mask = ~0;
_dev_info(cma_dev, registered.\n);
return ret;
}
module_init(cma_test_init);
static void __exit cma_test_exit(void)
{
misc_deregister(cma_test_misc);
}
module_exit(cma_test_exit);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Barry Song baohua.s...@csr.com);
MODULE_DESCRIPTION(kernel module to help the test of CMA);
MODULE_ALIAS(CMA test);
While fulfilling dd if=/dev/mmcblk0 of=/dev/null bs=4096
count=102400 and dd if=/dev/zero of=/data/1 bs=4096
count=102400 to exhaust memory at background,
i alloc the contiguous memories using the cma_test driver:
$echo 0 /dev/cma_test
[ 16.582216] misc cma_test: alloc virt: ceb0 phys: 0eb0
$echo 0 /dev/cma_test
[ 20.843395] misc cma_test: alloc virt: cec0 phys: 0ec0
$echo 0 /dev/cma_test
[ 21.774601] misc cma_test: alloc virt: cee0 phys: 0ee0
$echo 0 /dev/cma_test
[ 22.925633] misc cma_test: alloc virt: cf10 phys: 0f10
i did see the page write back is executed and contiguous memories are
always available.
P.S. the whole series was also back ported to 2.6.38.8 which our
release is based on.
Best regards
Marek Szyprowski
Samsung Poland RD Center
Links to previous versions of the patchset:
v22: http://www.spinics.net/lists/linux-media/msg44370.html
v21: http://www.spinics.net/lists/linux-media/msg44155.html
v20: http://www.spinics.net/lists/linux-mm/msg29145.html
v19: http://www.spinics.net/lists/linux-mm/msg29145.html
v18: http://www.spinics.net/lists/linux-mm/msg28125.html
v17: http://www.spinics.net/lists/arm-kernel/msg148499.html
v16: http://www.spinics.net/lists/linux-mm/msg25066.html
v15: http://www.spinics.net/lists/linux-mm/msg23365.html
v14: http://www.spinics.net/lists/linux-media/msg36536.html
v13: (internal, intentionally not released)
v12: http://www.spinics.net/lists/linux-media/msg35674.html
v11: http://www.spinics.net/lists/linux-mm/msg21868.html
v10: http://www.spinics.net/lists/linux-mm/msg20761.html
v9: http://article.gmane.org/gmane.linux.kernel.mm/60787
v8: http://article.gmane.org/gmane.linux.kernel.mm/56855
v7: http://article.gmane.org/gmane.linux.kernel.mm/55626
v6:
Re: [Linaro-mm-sig] [PATCHv23 12/16] mm: trigger page reclaim in alloc_contig_range() to stabilise watermarks
2012/2/23 Marek Szyprowski m.szyprow...@samsung.com:
alloc_contig_range() performs memory allocation so it also should keep
track on keeping the correct level of memory watermarks. This commit adds
a call to *_slowpath style reclaim to grab enough pages to make sure that
the final collection of contiguous pages from freelists will not starve
the system.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Tested-by: Rob Clark rob.cl...@linaro.org
Tested-by: Ohad Ben-Cohen o...@wizery.com
Tested-by: Benjamin Gaignard benjamin.gaign...@linaro.org
Tested-by: Robert Nelson robertcnel...@gmail.com
---
include/linux/mmzone.h | 9 +++
mm/page_alloc.c | 62
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 4781f30..77db8c0 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -63,8 +63,10 @@ enum {
#ifdef CONFIG_CMA
# define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+# define cma_wmark_pages(zone) zone-min_cma_pages
#else
# define is_migrate_cma(migratetype) false
+# define cma_wmark_pages(zone) 0
#endif
#define for_each_migratetype_order(order, type) \
@@ -371,6 +373,13 @@ struct zone {
/* see spanned/present_pages for more description */
seqlock_t span_seqlock;
#endif
+#ifdef CONFIG_CMA
+ /*
+ * CMA needs to increase watermark levels during the allocation
+ * process to make sure that the system is not starved.
+ */
+ unsigned long min_cma_pages;
+#endif
struct free_area free_area[MAX_ORDER];
#ifndef CONFIG_SPARSEMEM
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7a0d286..39cd74f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5092,6 +5092,11 @@ static void __setup_per_zone_wmarks(void)
low + (min 2);
zone-watermark[WMARK_HIGH] = min_wmark_pages(zone) +
low + (min 1);
+
+ zone-watermark[WMARK_MIN] += cma_wmark_pages(zone);
+ zone-watermark[WMARK_LOW] += cma_wmark_pages(zone);
+ zone-watermark[WMARK_HIGH] += cma_wmark_pages(zone);
+
setup_zone_migrate_reserve(zone);
spin_unlock_irqrestore(zone-lock, flags);
}
@@ -5695,6 +5700,56 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
return ret 0 ? 0 : ret;
}
+/*
+ * Update zone's cma pages counter used for watermark level calculation.
+ */
+static inline void __update_cma_watermarks(struct zone *zone, int count)
+{
+ unsigned long flags;
+ spin_lock_irqsave(zone-lock, flags);
+ zone-min_cma_pages += count;
+ spin_unlock_irqrestore(zone-lock, flags);
+ setup_per_zone_wmarks();
+}
+
+/*
+ * Trigger memory pressure bump to reclaim some pages in order to be able to
+ * allocate 'count' pages in single page units. Does similar work as
+ *__alloc_pages_slowpath() function.
+ */
+static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int count)
+{
+ enum zone_type high_zoneidx = gfp_zone(gfp_mask);
+ struct zonelist *zonelist = node_zonelist(0, gfp_mask);
+ int did_some_progress = 0;
+ int order = 1;
+ unsigned long watermark;
+
+ /*
+ * Increase level of watermarks to force kswapd do his job
+ * to stabilise at new watermark level.
+ */
+ __update_cma_watermarks(zone, count);
+
+ /* Obey watermarks as if the page was being allocated */
+ watermark = low_wmark_pages(zone) + count;
+ while (!zone_watermark_ok(zone, 0, watermark, 0, 0)) {
+ wake_all_kswapd(order, zonelist, high_zoneidx,
zone_idx(zone));
+
+ did_some_progress = __perform_reclaim(gfp_mask, order,
zonelist,
+ NULL);
+ if (!did_some_progress) {
+ /* Exhausted what can be done so it's blamo time */
+ out_of_memory(zonelist, gfp_mask, order, NULL);
out_of_memory() has got another param in the newest next/master tree,
out_of_memory(zonelist, gfp_mask, order, NULL, false) should be OK.
-barry
--
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] Add missing slab.h to fix linux-next compile errors
Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/radio/radio-aimslab.c b/drivers/media/radio/radio-aimslab.c index 862dfce..98e0c8c 100644 --- a/drivers/media/radio/radio-aimslab.c +++ b/drivers/media/radio/radio-aimslab.c @@ -32,6 +32,7 @@ #include linux/delay.h /* msleep */ #include linux/videodev2.h /* kernel radio structs */ #include linux/io.h /* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-ctrls.h diff --git a/drivers/media/radio/radio-aztech.c b/drivers/media/radio/radio-aztech.c index 8117fdf..177bcbd 100644 --- a/drivers/media/radio/radio-aztech.c +++ b/drivers/media/radio/radio-aztech.c @@ -21,6 +21,7 @@ #include linux/delay.h /* udelay */ #include linux/videodev2.h /* kernel radio structs */ #include linux/io.h /* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-ctrls.h diff --git a/drivers/media/radio/radio-gemtek.c b/drivers/media/radio/radio-gemtek.c index 9d7fdae..2e639ce 100644 --- a/drivers/media/radio/radio-gemtek.c +++ b/drivers/media/radio/radio-gemtek.c @@ -29,6 +29,7 @@ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/io.h /* outb, outb_p */ +#include linux/slab.h #include media/v4l2-ioctl.h #include media/v4l2-device.h #include radio-isa.h diff --git a/drivers/media/radio/radio-isa.c b/drivers/media/radio/radio-isa.c index 02bcead..06f9063 100644 --- a/drivers/media/radio/radio-isa.c +++ b/drivers/media/radio/radio-isa.c @@ -26,6 +26,7 @@ #include linux/delay.h #include linux/videodev2.h #include linux/io.h +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-fh.h diff --git a/drivers/media/radio/radio-terratec.c b/drivers/media/radio/radio-terratec.c index 2b82dd7..be10a80 100644 --- a/drivers/media/radio/radio-terratec.c +++ b/drivers/media/radio/radio-terratec.c @@ -26,6 +26,7 @@ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/io.h /* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.h diff --git a/drivers/media/radio/radio-trust.c b/drivers/media/radio/radio-trust.c index 0703a80..26a8c60 100644 --- a/drivers/media/radio/radio-trust.c +++ b/drivers/media/radio/radio-trust.c @@ -21,6 +21,7 @@ #include linux/ioport.h #include linux/videodev2.h #include linux/io.h +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.h diff --git a/drivers/media/radio/radio-typhoon.c b/drivers/media/radio/radio-typhoon.c index 145d10c..eb72a4d 100644 --- a/drivers/media/radio/radio-typhoon.c +++ b/drivers/media/radio/radio-typhoon.c @@ -33,6 +33,7 @@ #include linux/ioport.h /* request_region */ #include linux/videodev2.h /* kernel radio structs */ #include linux/io.h /* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.h diff --git a/drivers/media/radio/radio-zoltrix.c b/drivers/media/radio/radio-zoltrix.c index 33dc089..026e88e 100644 --- a/drivers/media/radio/radio-zoltrix.c +++ b/drivers/media/radio/radio-zoltrix.c @@ -45,6 +45,7 @@ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/io.h /* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.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
Re: [Linaro-mm-sig] [PATCHv23 13/16] drivers: add Contiguous Memory Allocator
2012/2/23 Marek Szyprowski m.szyprow...@samsung.com: The Contiguous Memory Allocator is a set of helper functions for DMA mapping framework that improves allocations of contiguous memory chunks. CMA grabs memory on system boot, marks it with MIGRATE_CMA migrate type and gives back to the system. Kernel is allowed to allocate only movable pages within CMA's managed memory so that it can be used for example for page cache when DMA mapping do not use it. On dma_alloc_from_contiguous() request such pages are migrated out of CMA area to free required contiguous block and fulfill the request. This allows to allocate large contiguous chunks of memory at any time assuming that there is enough free memory available in the system. This code is heavily based on earlier works by Michal Nazarewicz. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Michal Nazarewicz min...@mina86.com Acked-by: Arnd Bergmann a...@arndb.de Tested-by: Rob Clark rob.cl...@linaro.org Tested-by: Ohad Ben-Cohen o...@wizery.com Tested-by: Benjamin Gaignard benjamin.gaign...@linaro.org Tested-by: Robert Nelson robertcnel...@gmail.com if there is a /proc/cmainfo like /proc/slabinfo, it might be helpful to people as we can see the usage of CMA clearly. Thanks barry -- 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 v3 32/33] smiapp: Add driver.
Hi,
On 02/29/2012 10:35 AM, Laurent Pinchart wrote:
+ if (sensor-pixel_array-ctrl_handler.error) {
+ dev_err(client-dev,
+ pixel array controls initialization failed (%d)\n,
+ sensor-pixel_array-ctrl_handler.error);
Shouldn't you call v4l2_ctrl_handler_free() here ?
Yes. Fixed.
+ return sensor-pixel_array-ctrl_handler.error;
+ }
+
+ sensor-pixel_array-sd.ctrl_handler =
+ sensor-pixel_array-ctrl_handler;
+
+ v4l2_ctrl_cluster(2, sensor-hflip);
Shouldn't you move this before the control handler check ?
Why? It can't fail.
I thought it could fail. You could then leave it here, but it would be easier
from a maintenance point of view to check the error code after completing all
control-related initialization, as it would avoid introducing a bug if for
some reason the v4l2_ctrl_cluster() function needs to return an error later.
By calling v4l2_ctrl_cluster() after the control handler check you're sure
sensor-hflip is a pointer to a valid control. In case the HFLIP control
creation fails and you try to cluster that, unpredictable things may happen.
Well, predictable, e.g. BUG_ON() in v4l2_ctrl_cluster(). :-)
So using v4l2_ctrl_cluster() before checking ctrl_handler.error would require
validating the control pointer or maybe something more.
--
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
[PATCH] media: s5p-tv: support mc framework
From: Jiun Yu jiun...@samsung.com
Samsung Exynos tv subsystem is composed of video processor, mixer, HDMI Tx
and analog TV. Each h/w IP becomes a entity and also inputs of video and graphic
layers become entities in media controller framework like below figure.
+-+-+ +-+--+-+ +-++-+
| mxr-vd-grp0 |0| |0| mxr-sd-grp0 |1| | || |
+-+-+ +-+--+-+ |0|| |
+-+-+
| || |
|0| hdmi-sd |
+-+-+ +-+--+-+ +-+| |
+-+-+
| mxr-vd-grp1 |0| |0| mxr-sd-grp1 |1| | || |
+-+-+ +-+--+-+ |1| mxr-sd-blender |3|
| || |
+-+--+-+ +-+| |
+-+-+
|0| mxr-sd-video |1| | || |
|0| sdo-sd |
+-+--+-+ |2|| |
+-+-+
| || |
+-++-+
* mxr-vd-grp0
video device type entity
input of graphic0 layer
* mxr-vd-grp1
video device type entity
input of graphic1 layer
* mxr-sd-grp0
sub-device type entity
graphic0 layer part of mixer
* mxr-sd-grp1
sub-device type entity
graphic1 layer part of mixer
* mxr-sd-video
sub-device type entity
video layer part of mixer
* mxr-sd-blender
sub-device type entity
blender part of mixer
* hdmi-sd
sub-device type entity
hdmi tx
* sdo-sd
sub-device type entity
analog TV-out
Signed-off-by: Jiun Yu jiun...@samsung.com
---
drivers/media/video/s5p-tv/hdmi_drv.c| 77 -
drivers/media/video/s5p-tv/mixer.h | 52 ++
drivers/media/video/s5p-tv/mixer_drv.c | 224 ++
drivers/media/video/s5p-tv/mixer_grp_layer.c |2 +-
drivers/media/video/s5p-tv/mixer_video.c | 127 ---
drivers/media/video/s5p-tv/sdo_drv.c | 75 -
6 files changed, 478 insertions(+), 79 deletions(-)
diff --git a/drivers/media/video/s5p-tv/hdmi_drv.c
b/drivers/media/video/s5p-tv/hdmi_drv.c
index 8b41a04..4c3cb7b 100644
--- a/drivers/media/video/s5p-tv/hdmi_drv.c
+++ b/drivers/media/video/s5p-tv/hdmi_drv.c
@@ -33,6 +33,8 @@
#include media/v4l2-common.h
#include media/v4l2-dev.h
#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/exynos_mc.h
#include regs-hdmi.h
@@ -42,6 +44,10 @@ MODULE_LICENSE(GPL);
/* default preset configured on probe */
#define HDMI_DEFAULT_PRESET V4L2_DV_1080P60
+/* sink pad number of hdmi subdev */
+#define HDMI_PAD_SINK 0
+/* number of hdmi subdev pads */
+#define HDMI_PADS_NUM 1
struct hdmi_resources {
struct clk *hdmi;
@@ -62,6 +68,8 @@ struct hdmi_device {
struct device *dev;
/** subdev generated by HDMI device */
struct v4l2_subdev sd;
+ /** sink pad of hdmi subdev */
+ struct media_pad pad;
/** V4L2 device structure */
struct v4l2_device v4l2_dev;
/** subdev of HDMIPHY interface */
@@ -863,12 +871,68 @@ fail:
return -ENODEV;
}
+static int hdmi_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ return 0;
+}
+
+/* hdmi entity operations */
+static const struct media_entity_operations hdmi_entity_ops = {
+ .link_setup = hdmi_link_setup,
+};
+
+static int hdmi_register_entity(struct hdmi_device *hdev)
+{
+ struct v4l2_subdev *sd = hdev-sd;
+ struct media_pad *pad = hdev-pad;
+ struct media_entity *me = sd-entity;
+ struct device *dev = hdev-dev;
+ struct exynos_md *md;
+ int ret;
+
+ dev_dbg(dev, HDMI entity init\n);
+
+ /* init hdmi subdev */
+ v4l2_subdev_init(sd, hdmi_sd_ops);
+ sd-owner = THIS_MODULE;
+ strlcpy(sd-name, hdmi-sd, sizeof(sd-name));
+
+ dev_set_drvdata(dev, sd);
+
+ /* init hdmi subdev as entity */
+ pad[HDMI_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
+ me-ops = hdmi_entity_ops;
+ ret = media_entity_init(me, HDMI_PADS_NUM, pad, 0);
+ if (ret) {
+ dev_err(dev, failed to initialize media entity\n);
+ return ret;
+ }
+
+ /* get output media ptr for registering hdmi's sd */
+ md = (struct exynos_md *)module_name_to_driver_data(MDEV_MODULE_NAME);
+ if (!md) {
+ dev_err(dev, failed to get output media device\n);
+ return -ENODEV;
+ }
+
+ /* regiser HDMI subdev as entity to v4l2_dev pointer of
+
Re: [PATCH 3/3] wl128x: Add sysfs based support for FM features
On Tuesday, February 28, 2012 23:52:21 halli manjunatha wrote: On Tue, Feb 28, 2012 at 4:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, February 27, 2012 17:29:18 halli manjunatha wrote: Hi Hans, Agreed I don't mind to create new controls for below things 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RDS AF turn ON/OFF 3) FM RX RSSI level set/get 4) FM TX Alternate Frequency set/get 5) FM RX De-Emphasis mode set/get However, previously you have suggested me to hide few controls (like band selection) from the user but few of our application wanted controls like above and that is why I have created the sysfs entries. Please suggest me how can I move forward with new controls or with sysfs? The first question is which of these controls are general to FM receivers or transmitters, and which are specific to this chipset. The chipset specific controls should be private controls (look at V4L2_CID_MPEG_CX2341X_BASE in videodev2.h how those are defined). The others should be defined as new controls of the FM_TX class or the FM_RX class. The FM_RX class should be defined as a new class as it doesn't exist at the moment. Don't forget to document these controls clearly. With regards to the band selection: I remember that there was a discussion, but not the details. Do you have a link to that discussion? I can't find it (at least not quickly :-) ). Below features are generic to all FM receivers so we can add new CID's for below features 1) FM RX RDS AF turn ON/OFF 2) FM TX Alternate Frequency set/get About other 3 features its different issue, 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RSSI level set/get 3) FM RX De-Emphasis mode set/get All these 3 features are generic to any FM receiver, only question is does all FM receivers wants to expose these controls to application writer? Good question, and there is no good answer at the moment. See e.g. this IRC discussion: http://www.spinics.net/lists/linux-media/msg44023.html In the absence of a good solution to this problem I am inclined to make these controls driver specific but marked experimental. The experimental tag allows us to eventually make it a generic control without too much hassle. Example Band selection, every FM receiver at the minimum supports both Europe and Japan band, now the question is should we add a CID to switch between these two bands? If we decide to add a band selection control, then that would be a menu control (since there are up to three bands) and it would only be implemented by drivers that need it. What I am still not clear on is *why* you would want this control. What is the reason your customers want this? What does it allow you to do that can't be done today? Regards, Hans Below is the link to our discussion on the same topic a few time back. https://lkml.org/lkml/2010/11/18/43 There is one other thing that would be nice if that could be changed in the driver: currently there is only one radio device that can be used for both the receiver and the transmitter. During a V4L meeting last year we had a discussion about that and the conclusion was that receivers and transmitters should have their own radio device. The reason for that decision was that the VIDIOC_G/S_FREQUENCY ioctls cannot tell the difference between a transmitter and a receiver. If you have separate receiver and transmitter radio nodes this confusion goes away. In addition, this same restriction already applies to video and vbi nodes (i.e. a video or vbi node can be used for capture or output, but not both, unless it is a mem2mem device). I don't know how much work it is to implement this, but I would appreciate it if you could think about this a bit. I will look in to this and submit a new patch to create 2 separate device nodes for FM RX and FM TX once after this patch set. Regards Manju Regards, Hans Regards Manju On Sat, Feb 25, 2012 at 2:16 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Manjunatha! On Friday, February 24, 2012 21:14:31 manjunatha_ha...@ti.com wrote: From: Manjunatha Halli x0130...@ti.com This patch adds support for below features via sysfs file system 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RDS AF turn ON/OFF 3) FM RX RSSI level set/get 4) FM TX Alternate Frequency set/get 5) FM RX De-Emphasis mode set/get Why sysfs? Wouldn't it make more sense to create controls for this? That's the V4L way... Regards, Hans Also this patch fixes below issues 1) FM audio volume gain setting 2) Default rssi level is set to 8 instead of 20 3) Issue related to audio mute/unmute 4)Enable FM RX AF support in driver 5)In wrap_around seek mode try for once
[RESEND 2] [PATCH] rc/ir-raw: fix BUG_ON, using kfifo_rec_ptr_1 instead of kfifo
Raw IR events are passed to the raw event thread through a kfifo. The
size of the event struct is 12 bytes, and space for 512 events is
reserved in the kfifo (6144 bytes), however this is rounded down to 4096
bytes (the next power of 2) by __kfifo_alloc().
4096 bytes is not divisible by 12 therefore if the fifo fills up, a
third of a record will be written in the end of the kfifo by
ir_raw_event_store() because the recsize of the fifo is 0 (it doesn't
have records). When this is read by ir_raw_event_thread() a corrupted or
partial record will be read, and in the case of a partial record the
BUG_ON(retval != sizeof(ev)) gets hit too.
According to samples/kfifo/record-example.c struct kfifo_rec_ptr_1 can
handle records of a length between 0 and 255 bytes, so change struct
ir_raw_event_ctrl to use that instead of struct kfifo.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
drivers/media/rc/rc-core-priv.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index c6ca870..989ea08 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -35,7 +35,7 @@ struct ir_raw_event_ctrl {
struct list_headlist; /* to keep track of raw
clients */
struct task_struct *thread;
spinlock_t lock;
- struct kfifokfifo; /* fifo for the
pulse/space durations */
+ struct kfifo_rec_ptr_1 kfifo; /* fifo for the
pulse/space durations */
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
struct rc_dev *dev; /* pointer to the
parent rc_dev */
--
1.7.2.3
--
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] [PATCHv23 00/16] Contiguous Memory Allocator
On Wed, 29 Feb 2012 10:35:42 +0100, Barry Song 21cn...@gmail.com wrote: 2012/2/23 Marek Szyprowski m.szyprow...@samsung.com: This is (yet another) quick update of CMA patches. I've rebased them onto next-20120222 tree from git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and fixed the bug pointed by Aaro Koskinen. For the whole series: Tested-by: Barry Song baohua.s...@csr.com and i also write a simple kernel helper to test the CMA: Would it make sense to make a patch out of it putting it to tools/cma (or similar)? -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -- 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 v3 1/1] rc: Add support for GPIO based IR Receiver driver.
Hi Mauro/Wilson, On 2/29/2012 1:59 AM, James Hogan wrote: On Tue, Feb 28, 2012 at 11:21:40AM +0530, Ravi Kumar V wrote: Adds GPIO based IR Receiver driver. It decodes signals using decoders available in rc framework. Signed-off-by: Ravi Kumar Vkumar...@codeaurora.org Looks good to me (but I'm no expert). Please review this patch. Thank you James for the review comments. ---Trilok Soni -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: rotator: Add new image rotator driver for EXYNOS
This patch adds support image rotator driver for EXYNOS
SoCs and this is including following:
1) Image format
: RGB565/888, YUV422 1p, YUV420 2p/3p
2) Rotation
: 0/90/180/270 degree and X/Y Flip
Signed-off-by: Ayoung Sim a@samsung.com
Signed-off-by: Sunyoung Kang sy0816.k...@samsung.com
---
NOTE:
This patch has been created based on following
- media: media-dev: Add media devices for EXYNOS5 by Sungchun Kang
- media: fimc-lite: Add new driver for camera interface by Sungchun Kang
Dear Mauro,
I couldn't find your review on Sungchun Kang's patches has been submitted
2weeks ago.
Since this is based on them, we _really_ need your comments on that.
If any problems/comments, please kindly let us know.
Thanks.
Sunyoung.
drivers/media/video/exynos/Kconfig|1 +
drivers/media/video/exynos/Makefile |1 +
drivers/media/video/exynos/rotator/Kconfig| 12 +
drivers/media/video/exynos/rotator/Makefile |9 +
drivers/media/video/exynos/rotator/rotator-core.c | 1490 +
drivers/media/video/exynos/rotator/rotator-regs.c | 215 +++
drivers/media/video/exynos/rotator/rotator-regs.h | 70 +
drivers/media/video/exynos/rotator/rotator.h | 325 +
8 files changed, 2123 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos/rotator/Kconfig
create mode 100644 drivers/media/video/exynos/rotator/Makefile
create mode 100644 drivers/media/video/exynos/rotator/rotator-core.c
create mode 100644 drivers/media/video/exynos/rotator/rotator-regs.c
create mode 100644 drivers/media/video/exynos/rotator/rotator-regs.h
create mode 100644 drivers/media/video/exynos/rotator/rotator.h
diff --git a/drivers/media/video/exynos/Kconfig
b/drivers/media/video/exynos/Kconfig
index a84097d..38a885d 100644
--- a/drivers/media/video/exynos/Kconfig
+++ b/drivers/media/video/exynos/Kconfig
@@ -12,6 +12,7 @@ config VIDEO_EXYNOS
if VIDEO_EXYNOS
source drivers/media/video/exynos/mdev/Kconfig
source drivers/media/video/exynos/fimc-lite/Kconfig
+ source drivers/media/video/exynos/rotator/Kconfig
endif
config MEDIA_EXYNOS
diff --git a/drivers/media/video/exynos/Makefile
b/drivers/media/video/exynos/Makefile
index 56cb7b2..24f19c5 100644
--- a/drivers/media/video/exynos/Makefile
+++ b/drivers/media/video/exynos/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_EXYNOS_MEDIA_DEVICE) += mdev/
obj-$(CONFIG_VIDEO_EXYNOS_FIMC_LITE) += fimc-lite/
+obj-$(CONFIG_VIDEO_EXYNOS_ROTATOR) += rotator/
EXTRA_CLAGS += -Idrivers/media/video
diff --git a/drivers/media/video/exynos/rotator/Kconfig
b/drivers/media/video/exynos/rotator/Kconfig
new file mode 100644
index 000..332a997
--- /dev/null
+++ b/drivers/media/video/exynos/rotator/Kconfig
@@ -0,0 +1,12 @@
+config VIDEO_EXYNOS_ROTATOR
+ bool EXYNOS Image Rotator Driver
+ select V4L2_MEM2MEM_DEV
+ select VIDEOBUF2_DMA_CONTIG
+ default n
+ ---help---
+ Support for Image Rotator Driver with v4l2 on EXYNOS SoCs
+
+config VIDEO_SAMSUNG_MEMSIZE_ROT
+ int Memory size in kbytes for ROTATOR
+ depends on VIDEO_EXYNOS_ROTATOR
+ default 9216
diff --git a/drivers/media/video/exynos/rotator/Makefile
b/drivers/media/video/exynos/rotator/Makefile
new file mode 100644
index 000..6f74403
--- /dev/null
+++ b/drivers/media/video/exynos/rotator/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (c) 2012 Samsung Electronics Co., Ltd.
+# http://www.samsung.com
+#
+# Licensed under GPLv2
+#
+
+rotator-objs := rotator-core.o rotator-regs.o
+obj-$(CONFIG_VIDEO_EXYNOS_ROTATOR) += rotator.o
diff --git a/drivers/media/video/exynos/rotator/rotator-core.c
b/drivers/media/video/exynos/rotator/rotator-core.c
new file mode 100644
index 000..0c91196
--- /dev/null
+++ b/drivers/media/video/exynos/rotator/rotator-core.c
@@ -0,0 +1,1490 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Core file for Samsung EXYNOS Image Rotator driver
+ *
+ * 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.
+*/
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/clk.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
+
+#include rotator.h
+
+module_param_named(log_level, log_level, uint, 0644);
+
+static struct rot_fmt rot_formats[] = {
+ {
+ .name = RGB565,
+ .pixelformat= V4L2_PIX_FMT_RGB565,
+ .num_planes = 1,
+ .nr_comp= 1,
+ .bitperpixel= { 16 },
+ }, {
+ .name = XRGB-, 32 bps,
+ .pixelformat= V4L2_PIX_FMT_RGB32,
+
Re: [Linaro-mm-sig] [PATCHv23 00/16] Contiguous Memory Allocator
Michal, 2012/2/29 Michal Nazarewicz min...@mina86.com: On Wed, 29 Feb 2012 10:35:42 +0100, Barry Song 21cn...@gmail.com wrote: 2012/2/23 Marek Szyprowski m.szyprow...@samsung.com: This is (yet another) quick update of CMA patches. I've rebased them onto next-20120222 tree from git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and fixed the bug pointed by Aaro Koskinen. For the whole series: Tested-by: Barry Song baohua.s...@csr.com and i also write a simple kernel helper to test the CMA: Would it make sense to make a patch out of it putting it to tools/cma (or similar)? i can send a patch for this. i am just thinking, should it be placed in tools/ as a test utility or Documents/ as an example to explain CMA to users who want to use cma. i also think we should have a seperate document to explain cma in details in documents/, and my helper program can be placed there. how do you think? -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- thanks barry -- 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] [PATCHv23 00/16] Contiguous Memory Allocator
On Wed, 29 Feb 2012 14:34:02 +0100, Barry Song 21cn...@gmail.com wrote: 2012/2/29 Michal Nazarewicz min...@mina86.com: On Wed, 29 Feb 2012 10:35:42 +0100, Barry Song 21cn...@gmail.com wrote: and i also write a simple kernel helper to test the CMA: Would it make sense to make a patch out of it putting it to tools/cma (or similar)? i can send a patch for this. i am just thinking, should it be placed in tools/ as a test utility or Documents/ as an example to explain CMA to users who want to use cma. I'd put it in tools/. i also think we should have a seperate document to explain cma in details in documents/, and my helper program can be placed there. I'm currently writing an article for LWN which I hope will also lead to something worth putting in Documentation/. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -- 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] [PATCHv23 00/16] Contiguous Memory Allocator
2012/2/29 Michal Nazarewicz min...@mina86.com: On Wed, 29 Feb 2012 14:34:02 +0100, Barry Song 21cn...@gmail.com wrote: 2012/2/29 Michal Nazarewicz min...@mina86.com: On Wed, 29 Feb 2012 10:35:42 +0100, Barry Song 21cn...@gmail.com wrote: and i also write a simple kernel helper to test the CMA: Would it make sense to make a patch out of it putting it to tools/cma (or similar)? i can send a patch for this. i am just thinking, should it be placed in tools/ as a test utility or Documents/ as an example to explain CMA to users who want to use cma. I'd put it in tools/. ok. i will handle this. i also think we should have a seperate document to explain cma in details in documents/, and my helper program can be placed there. I'm currently writing an article for LWN which I hope will also lead to something worth putting in Documentation/. fine. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -barry -- 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: Video Capture Issue
Hi Aguirre Sergio,
1) Looks like it could be a data lane issue. OMAP detects lots of
ERRSOTSYNCHS errors
on the datalanes (CSI2_COMPLEXIO_IRQSTATUS)
2) Even if i configure it to use only one data lane on both sides. It detects
errors on other data lanes.
That explains the abnormally high number of these error interrupts and a
frame completion interrupt once in a while.
I guess, I need to check my configuration settings.
Thanks,
Sriram
On Tue, Feb 28, 2012 at 9:12 PM, Aguirre, Sergio saagui...@ti.com wrote:
Hi Sriram,
On Tue, Feb 28, 2012 at 8:46 AM, Sriram V vshrir...@gmail.com wrote:
Hi Aguirre Sergio,
On Tue, Feb 28, 2012 at 9:08 AM, Aguirre, Sergio saagui...@ti.com wrote:
Sriram,
On Sun, Feb 26, 2012 at 8:54 AM, Sriram V vshrir...@gmail.com wrote:
Hi,
When I take the dump of the buffer which is pointed by DATA MEM
PING ADDRESS. It always shows 0x55.
Even if i write 0x00 to the address. I do notice that it quickly
changes to 0x55.
Under what conditions could this happen? What am i missing here.
If you're using yavta for capture, notice that it clears out the
buffers before queuing them in:
static int video_queue_buffer(struct device *dev, int index, enum
buffer_fill_mode fill)
{
struct v4l2_buffer buf;
int ret;
...
...
if (dev-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
...
} else {
if (fill BUFFER_FILL_FRAME)
memset(dev-buffers[buf.index].mem, 0x55,
dev-buffers[index].size);
if (fill BUFFER_FILL_PADDING)
memset(dev-buffers[buf.index].mem +
dev-buffers[index].size,
0x55, dev-buffers[index].padding);
}
...
}
So, just make sure this condition is not met.
Unfortunately, this condition is met. For some reason, ISS thinks
it has got valid frame. Whereas the Image data is not populated into
the buffers.
The register CSI2_CTX_CTRL1_i[COUNT] keeps getting toggled between 0 and 1
indicating a frame arrival.
I also notice that on some frames, The first 0x200 bytes contains data
other than 0x55
and the rest are 0x55.
Probably this could be related to resolution settings or hsync and
vsync settings.
Probably, my chip configuration is faulty.
Hmm, sounds like it.
Can you try adding this to the top of the file?
#define DEBUG
So that the dev_dbg() prints get executed?
I'm curious to see if you detect any ComplexIO errors on
omap4iss_csi2_isr()...
I do notice that the OMAP4 ISS is tested to work with OV5640 (YUV422
Frames) and OV5650 (Raw Data)
When you say 422 Frames only. Do you mean 422-8Bit Mode?.
Yes. When saving YUV422 to memory, you can only use this mode AFAIK.
I havent tried RAW12 which my device gives, Do i have to update only
the Data Format Selection register
of the ISS for RAW12?
Ok, now it makes sense.
So, if your CSI2 source is giving, you need to make sure:
CSI2_CTX_CTRL2_0.FORMAT[9:0] is:
- 0xAC: RAW12 + EXP16
or
- 0x2C: RAW12
The difference is that the EXP16 variant, will save to memory in
expansion to 2 bytes, instead of 12 bits, so it'll be byte aligned.
Can you try attached patch?
With RAW12 configuration, I dont see any interrupts at all.
Ok,
Then this means your CSI2 transmitter (sensor) is actually sending
YUV422, and not RAW12.
Nevermind that patch then...
Regards,
Sergio
Regards,
Sergio
Please advice.
On Thu, Feb 23, 2012 at 11:24 PM, Sriram V vshrir...@gmail.com wrote:
Hi,
1) An Hexdump of the captured file shows 0x55 at all locations.
Is there any buffer location i need to check.
2) I have tried with devel branch.
3) Changing the polarities doesnt help either.
4) The sensor is giving out YUV422 8Bit Mode,
Will 0x52001074 = 0x0A1E (UYVY Format) it bypass the ISP
and dump directly into memory.
On 2/23/12, Aguirre, Sergio saagui...@ti.com wrote:
Hi Sriram,
On Thu, Feb 23, 2012 at 11:25 AM, Sriram V vshrir...@gmail.com wrote:
Hi,
1) I am trying to get a HDMI to CSI Bridge chip working with OMAP4 ISS.
The issue is the captured frames are completely green in color.
Sounds like the buffer is all zeroes, can you confirm?
2) The Chip is configured to output VGA Color bar sequence with
YUV422-8Bit and
uses datalane 0 only.
3) The Format on OMAP4 ISS is UYVY (Register 0x52001074 = 0x0A1E)
I am trying to directly dump the data into memory without ISP
processing.
Please advice.
Just to be clear on your environment, which branch/commitID are you based
on?
Regards,
Sergio
--
Regards,
Sriram
--
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
--
Regards,
Sriram
--
Regards,
Sriram
--
Regards,
Sriram
--
Regards,
Sriram
--
To unsubscribe
Re: [PATCH 3/3] wl128x: Add sysfs based support for FM features
On Wed, Feb 29, 2012 at 5:25 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday, February 28, 2012 23:52:21 halli manjunatha wrote: On Tue, Feb 28, 2012 at 4:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, February 27, 2012 17:29:18 halli manjunatha wrote: Hi Hans, Agreed I don't mind to create new controls for below things 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RDS AF turn ON/OFF 3) FM RX RSSI level set/get 4) FM TX Alternate Frequency set/get 5) FM RX De-Emphasis mode set/get However, previously you have suggested me to hide few controls (like band selection) from the user but few of our application wanted controls like above and that is why I have created the sysfs entries. Please suggest me how can I move forward with new controls or with sysfs? The first question is which of these controls are general to FM receivers or transmitters, and which are specific to this chipset. The chipset specific controls should be private controls (look at V4L2_CID_MPEG_CX2341X_BASE in videodev2.h how those are defined). The others should be defined as new controls of the FM_TX class or the FM_RX class. The FM_RX class should be defined as a new class as it doesn't exist at the moment. Don't forget to document these controls clearly. With regards to the band selection: I remember that there was a discussion, but not the details. Do you have a link to that discussion? I can't find it (at least not quickly :-) ). Below features are generic to all FM receivers so we can add new CID's for below features 1) FM RX RDS AF turn ON/OFF 2) FM TX Alternate Frequency set/get About other 3 features its different issue, 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RSSI level set/get 3) FM RX De-Emphasis mode set/get All these 3 features are generic to any FM receiver, only question is does all FM receivers wants to expose these controls to application writer? Good question, and there is no good answer at the moment. See e.g. this IRC discussion: http://www.spinics.net/lists/linux-media/msg44023.html In the absence of a good solution to this problem I am inclined to make these controls driver specific but marked experimental. The experimental tag allows us to eventually make it a generic control without too much hassle. Agreed, I will make them driver specific and mark them as experimental. Example Band selection, every FM receiver at the minimum supports both Europe and Japan band, now the question is should we add a CID to switch between these two bands? If we decide to add a band selection control, then that would be a menu control (since there are up to three bands) and it would only be implemented by drivers that need it. What I am still not clear on is *why* you would want this control. What is the reason your customers want this? What does it allow you to do that can't be done today? There are 2 reasons for this, First, our chip supports weather band, unlike other bands (Europe, Japan and Russian) user may wants to switch to weather band and wants to listen to weather report and again switches back to normal band. Second, for FM TX, our chip supports band selection for FM transmitter, so if the same phone is used in different regions of world then user can switch to the actual band and start transmitting by choosing a blank frequency in that band. Regards Manju Regards, Hans Below is the link to our discussion on the same topic a few time back. https://lkml.org/lkml/2010/11/18/43 There is one other thing that would be nice if that could be changed in the driver: currently there is only one radio device that can be used for both the receiver and the transmitter. During a V4L meeting last year we had a discussion about that and the conclusion was that receivers and transmitters should have their own radio device. The reason for that decision was that the VIDIOC_G/S_FREQUENCY ioctls cannot tell the difference between a transmitter and a receiver. If you have separate receiver and transmitter radio nodes this confusion goes away. In addition, this same restriction already applies to video and vbi nodes (i.e. a video or vbi node can be used for capture or output, but not both, unless it is a mem2mem device). I don't know how much work it is to implement this, but I would appreciate it if you could think about this a bit. I will look in to this and submit a new patch to create 2 separate device nodes for FM RX and FM TX once after this patch set. Regards Manju Regards, Hans Regards Manju On Sat, Feb 25, 2012 at 2:16 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Manjunatha! On Friday, February 24, 2012 21:14:31 manjunatha_ha...@ti.com wrote: From: Manjunatha Halli x0130...@ti.com This patch adds support for below features via
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 Feb 29 19:00:33 CET 2012 git hash:e8ca6d20a65d9d94693a0ed99b12d95b882dc859 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-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-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS 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
rtl2830: __udivdi3 undefined
http://kisskb.ellerman.id.au/kisskb/buildresult/5759200/
ERROR: __udivdi3 [drivers/media/dvb/frontends/rtl2830.ko] undefined!
I didn't look too deeply into it, but I think it's caused by the num
/= priv-cfg.xtal
in rtl2830_init() (with num being u64).
Can't it use do_div() instead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: media-dev: Add media devices for EXYNOS5
Hi Sungchun, On 02/15/2012 07:02 AM, Sungchun Kang wrote: Since the EXYNOS5 SoCs have various multimedia IPs such as Gscaler, FIMC-LITE, and MIXER, and so on. Additionally, media controller interface is needed to configure connection between them and to control each IPs. This patch adds support media device for EXYNOS5 SoCs. Actually, there are three media devices such as below diagram which are using media control framework. Since they are not belong to one hardware block, we need to manage it for connecting with each devices. Follwing is detailed list of them: * Gscaler: general scaler Support memory to memory interface Support output interface from memory to display device(LCD, TV) Support capture interface from device(FIMC-LITE, FIMD) to memory * MIPI-CSIS Support interconnection(subdev interface) between devices Is there any difference in s5p/exynos4 and exynos5 MIPI-CSIS devices ? I suspect there isn't and the existing MIPI-CSIS driver can be used for exynos5 too. * FIMC-LITE Support capture interface from device(Sensor, MIPI-CSIS) to memory Support interconnection(subdev interface) between devices This device is also present on exynos4212/4412 SoCs. Can you tell what's difference between FIMC-LITE on Exynos4 and Exynos5 ? Either we need separate FIMC-LITE drivers or we need a shared one. I'd like to clarify this first. * MIXER Support output interface from memory to device(HDMI) Support interconnection(subdev interface) between devices * FIMD Support framebuffer interface Support subdev interface to display frames sent from Gscaler What about Exynos DRM driver ? Do you have any plans to integrate the V4L2 and the DRM driver ? IMHO DRM is more appropriate for some tasks on display side, like 2D operations, multiple outputs, windows, blending, etc. * Rotator Support memory to memory interface * m2m-scaler Support only memory to memory interface * And so on... 1) media 0 LCD Output path consists of Gscaler and FIMD(display controller). ++ +--+ | Gscaler-output | -- | FIMD | -- LCD ++ +--+ HDMI Output path consists of Gscaler, Mixer and HDMI. ++ +---+ +--+ | Gscaler-output | -- | MIXER | -- | HDMI | -- TV ++ +---+ +--+ ++ +---+ +---+ +-+ 2) media 1 Camera Capture path consists of MIPI-CSIS, FIMC-LITE and Gscaler ++ +---+ +-+ | Sensor | -- | FIMC-LITE | -- | Gscaler-capture | ++ +---+ +-+ ++ +---+ +---+ +-+ | Sensor | -- | MIPI-CSIS | -- | FIMC-LITE | -- | Gscaler-capture | ++ +---+ +---+ +-+ Signed-off-by: Sungchun Kangsungchun.k...@samsung.com --- drivers/media/video/exynos/mdev/Kconfig |8 ++ drivers/media/video/exynos/mdev/Makefile |2 + drivers/media/video/exynos/mdev/exynos-mdev.c | 115 ++ include/media/exynos_mc.h | 160 + 4 files changed, 285 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/exynos/mdev/Kconfig create mode 100644 drivers/media/video/exynos/mdev/Makefile create mode 100644 drivers/media/video/exynos/mdev/exynos-mdev.c create mode 100644 include/media/exynos_mc.h diff --git a/drivers/media/video/exynos/mdev/Kconfig b/drivers/media/video/exynos/mdev/Kconfig new file mode 100644 index 000..15134b0 --- /dev/null +++ b/drivers/media/video/exynos/mdev/Kconfig @@ -0,0 +1,8 @@ +config EXYNOS_MEDIA_DEVICE + bool + depends on MEDIA_EXYNOS + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + default y + help + This is a v4l2 driver for exynos media device. diff --git a/drivers/media/video/exynos/mdev/Makefile b/drivers/media/video/exynos/mdev/Makefile new file mode 100644 index 000..175a4bc --- /dev/null +++ b/drivers/media/video/exynos/mdev/Makefile @@ -0,0 +1,2 @@ +mdev-objs := exynos-mdev.o +obj-$(CONFIG_EXYNOS_MEDIA_DEVICE)+= mdev.o diff --git a/drivers/media/video/exynos/mdev/exynos-mdev.c b/drivers/media/video/exynos/mdev/exynos-mdev.c new file mode 100644 index 000..a76e7c3 --- /dev/null +++ b/drivers/media/video/exynos/mdev/exynos-mdev.c @@ -0,0 +1,115 @@ +/* drviers/media/video/exynos/mdev/exynos-mdev.c + * + * Copyright (c) 2011 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * EXYNOS5 SoC series media device driver + * + * 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. +*/ +
3.1/3.2 uvcvideo and Creative Live! Cam Optia AF
Hi Laurent, We've had a bug report [1] in Fedora for a while now that the uvcvideo driver no longer works on the Creative Live! Cam Optia AF (ID 041e:4058) in the 3.1 and 3.2 kernels. The bug has all the various output from dmesg, lsusb, etc. I'm wondering if there is anything further we can do to help diagnose what might be going wrong here. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=739448 -- 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] Add missing slab.h to fix linux-next compile errors
On 02/29/2012 01:50 AM, Hans Verkuil wrote: Signed-off-by: Hans Verkuil hans.verk...@cisco.com Reported-by: Randy Dunlap rdun...@xenotime.net Acked-by: Randy Dunlap rdun...@xenotime.net Thanks. diff --git a/drivers/media/radio/radio-aimslab.c b/drivers/media/radio/radio-aimslab.c index 862dfce..98e0c8c 100644 --- a/drivers/media/radio/radio-aimslab.c +++ b/drivers/media/radio/radio-aimslab.c @@ -32,6 +32,7 @@ #include linux/delay.h /* msleep */ #include linux/videodev2.h /* kernel radio structs */ #include linux/io.h/* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-ctrls.h diff --git a/drivers/media/radio/radio-aztech.c b/drivers/media/radio/radio-aztech.c index 8117fdf..177bcbd 100644 --- a/drivers/media/radio/radio-aztech.c +++ b/drivers/media/radio/radio-aztech.c @@ -21,6 +21,7 @@ #include linux/delay.h /* udelay */ #include linux/videodev2.h /* kernel radio structs */ #include linux/io.h/* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-ctrls.h diff --git a/drivers/media/radio/radio-gemtek.c b/drivers/media/radio/radio-gemtek.c index 9d7fdae..2e639ce 100644 --- a/drivers/media/radio/radio-gemtek.c +++ b/drivers/media/radio/radio-gemtek.c @@ -29,6 +29,7 @@ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/io.h/* outb, outb_p */ +#include linux/slab.h #include media/v4l2-ioctl.h #include media/v4l2-device.h #include radio-isa.h diff --git a/drivers/media/radio/radio-isa.c b/drivers/media/radio/radio-isa.c index 02bcead..06f9063 100644 --- a/drivers/media/radio/radio-isa.c +++ b/drivers/media/radio/radio-isa.c @@ -26,6 +26,7 @@ #include linux/delay.h #include linux/videodev2.h #include linux/io.h +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-fh.h diff --git a/drivers/media/radio/radio-terratec.c b/drivers/media/radio/radio-terratec.c index 2b82dd7..be10a80 100644 --- a/drivers/media/radio/radio-terratec.c +++ b/drivers/media/radio/radio-terratec.c @@ -26,6 +26,7 @@ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/io.h/* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.h diff --git a/drivers/media/radio/radio-trust.c b/drivers/media/radio/radio-trust.c index 0703a80..26a8c60 100644 --- a/drivers/media/radio/radio-trust.c +++ b/drivers/media/radio/radio-trust.c @@ -21,6 +21,7 @@ #include linux/ioport.h #include linux/videodev2.h #include linux/io.h +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.h diff --git a/drivers/media/radio/radio-typhoon.c b/drivers/media/radio/radio-typhoon.c index 145d10c..eb72a4d 100644 --- a/drivers/media/radio/radio-typhoon.c +++ b/drivers/media/radio/radio-typhoon.c @@ -33,6 +33,7 @@ #include linux/ioport.h/* request_region */ #include linux/videodev2.h /* kernel radio structs */ #include linux/io.h/* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.h diff --git a/drivers/media/radio/radio-zoltrix.c b/drivers/media/radio/radio-zoltrix.c index 33dc089..026e88e 100644 --- a/drivers/media/radio/radio-zoltrix.c +++ b/drivers/media/radio/radio-zoltrix.c @@ -45,6 +45,7 @@ #include linux/videodev2.h /* kernel radio structs */ #include linux/mutex.h #include linux/io.h/* outb, outb_p */ +#include linux/slab.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include radio-isa.h -- -- ~Randy -- 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
audio is not working
I am running an athlon ii 945 with a hauppauge wintv 1600 capture card. I have a version of mythtv installed (0.24) in which I downloaded the latest V4L-DVB Device Drivers from git://linuxtv.org/media_build.git, built them, and then installed. Everything is up to date with the software packages. The video records perfectly fine but the audio is missing. The backend log has the following indicators of problems: 2012-02-29 22:30:28.722 AFD Warning: ScanATSCCaptionStreams() called with no PMT 2012-02-29 22:30:28.763 AFD: Opened codec 0x7f7180007f30, id(MPEG2VIDEO) type(Video) 2012-02-29 22:30:28.797 AFD: codec MP2 has 2 channels 2012-02-29 22:30:28.830 AFD: Opened codec 0x7f718000abe0, id(MP2) type(Audio) 2012-02-29 22:30:28.951 [mpeg2video @ 0x7f719986c700]warning: first frame is no keyframe 2012-02-29 22:30:29.016 [mpeg2video @ 0x7f719986c700]warning: first frame is no keyframe 2012-02-29 22:35:12.770 [mpeg2video @ 0x7f719986c700]00 motion_type at 28 10 2012-02-29 22:35:12.815 [mpeg2video @ 0x7f719986c700]Warning MVs not available 2012-02-29 22:35:12.859 [mp2 @ 0x7f719986c700]incomplete frame 2012-02-29 22:35:12.899 AFD Error: Unknown audio decoding error In the syslog I am seeing entries (a log of them) like this: Feb 29 22:29:56 bifrosttv kernel: [ 1154.739451] cx18-0: Skipped encoder IDX, MDL 442, 2 times - it must have dropped out of rotation Feb 29 22:29:56 bifrosttv kernel: [ 1154.739459] cx18-0: Skipped encoder IDX, MDL 443, 2 times - it must have dropped out of rotation Feb 29 22:29:56 bifrosttv kernel: [ 1154.739465] cx18-0: Skipped encoder IDX, MDL 444, 2 times - it must have dropped out of rotation Feb 29 22:29:56 bifrosttv kernel: [ 1154.739472] cx18-0: Could not find MDL 438 for stream encoder IDX Feb 29 22:29:56 bifrosttv kernel: [ 1154.739478] cx18-0: Could not find MDL 441 for stream encoder IDX Feb 29 22:30:00 bifrosttv kernel: [ 1158.736285] cx18-0: Skipped encoder IDX, MDL 444, 1 times - it must have dropped out of rotation Feb 29 22:30:00 bifrosttv kernel: [ 1158.736325] cx18-0: Could not find MDL 441 for stream encoder IDX Feb 29 22:30:00 bifrosttv kernel: [ 1158.736335] cx18-0: Could not find MDL 442 for stream encoder IDX Feb 29 22:30:00 bifrosttv kernel: [ 1158.736431] cx18-0: Could not find MDL 443 for stream encoder IDX Feb 29 22:30:00 bifrosttv kernel: [ 1158.736437] cx18-0: Could not find MDL 444 for stream encoder IDX Feb 29 22:30:00 bifrosttv kernel: [ 1158.736475] cx18-0: Could not find MDL 442 for stream encoder IDX Does anyone have suggestions or ideas I can try? -- 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
