[RFC PATCH v5 1/2] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and and based on ww-mutexes[2] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and user application. This framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v5: - Rmove a dependence on reservation_object: the reservation_object is used to hook up to ttm and dma-buf for easy sharing of reservations across devices. However, the dmabuf sync can be used for all dma devices; v4l2 and drm based drivers, so doesn't need the reservation_object anymore. With regared to this, it adds 'void *sync' to dma_buf structure. - All patches are rebased on mainline, Linux v3.10. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); ... And the below can be used as access types: DMA_BUF_ACCESS_R - CPU will access a buffer for read. DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use interfaces for device driver: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed:
[RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call
This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.
With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/base/dma-buf.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 9a26981..e1b8583 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -80,9 +80,42 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
return dmabuf-ops-mmap(dmabuf, vma);
}
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+ struct dma_buf *dmabuf;
+ unsigned int type;
+ bool wait = false;
+
+ if (!is_dma_buf_file(file))
+ return -EINVAL;
+
+ dmabuf = file-private_data;
+
+ if ((fl-fl_type F_UNLCK) == F_UNLCK) {
+ dmabuf_sync_single_unlock(dmabuf);
+ return 0;
+ }
+
+ /* convert flock type to dmabuf sync type. */
+ if ((fl-fl_type F_WRLCK) == F_WRLCK)
+ type = DMA_BUF_ACCESS_W;
+ else if ((fl-fl_type F_RDLCK) == F_RDLCK)
+ type = DMA_BUF_ACCESS_R;
+ else
+ return -EINVAL;
+
+ if (fl-fl_flags FL_SLEEP)
+ wait = true;
+
+ /* TODO. the locking to certain region should also be considered. */
+
+ return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
+ .lock = dma_buf_lock,
};
/*
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/2 v5] Introduce buffer synchronization framework
Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. For generic user mode interface, we have used fcntl system call[3]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ Moreover, we had tried to find how we could utilize limited hardware resources more using buffer synchronization mechanism. And finally, we have realized that it could enhance performance using multi threads with this buffer synchronization mechanism: DMA and CPU works individually so CPU could perform other works while DMA is performing some works, and vise versa. However, in the conventional way, that is not easy to do so because DMA operation is depend on CPU operation, and vice versa. Conventional way: User Kernel - CPU writes something to src send the src to driver- update DMA register request DMA start(1)--- DMA start -completion signal(2)-- CPU accesses dst (1) Request DMA start after the CPU access to src buffer is completed. (2) Access dst buffer after DMA access to the dst buffer is completed. On the other hand, if there is something to control buffer access between CPU and DMA? The below shows that: User(thread a) User(thread b)Kernel - send a src to driver-- update DMA register lock the src request DMA start(1)-- CPU acccess to src unlock the srclock src and dst DMA start -completion signal(2)- lock dst DMA completion CPU access to dst unlock src and dst unlock DST (1) Try to start DMA operation while CPU is accessing the src buffer. (2) Try CPU access to dst buffer while DMA is accessing the dst buffer. This means that CPU or DMA could do more works. In the same way, we could reduce hand shaking overhead between two processes when those processes need to share a shared buffer. There may be other cases that we could reduce overhead as well. References: [1] http://lwn.net/Articles/470339/ [2] https://patchwork.kernel.org/patch/2625361/ [3] http://linux.die.net/man/2/fcntl Inki Dae (2): [RFC PATCH v5 1/2] dmabuf-sync: Introduce buffer synchronization framework [RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call Documentation/dma-buf-sync.txt | 290 + drivers/base/Kconfig |7 + drivers/base/Makefile |1 + drivers/base/dma-buf.c | 37 +++ drivers/base/dmabuf-sync.c | 674 include/linux/dma-buf.h| 16 + include/linux/dmabuf-sync.h| 178 +++ 7 files changed, 1203 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[DTV Tables] Now also on github.
Hey all, since I hadn't received any comment in the previous message (which was a reply only) I thought i get this through the list as well. I have created a github repostiory [0] for the dtv-tables so that it is easier for people to fork and upstream new data. I'm not a fan to using github and not having patches submitted to me/the mailing list, but this isn't source code, but data that I feel is important to have in the tree as fast as possible. I wouldn't be surprised that at some point some random manufacturer puts a reference to this tree into their system, be it closed or open, and it would be nice that our tables be as up to date as possible. The best workflow I can think of, is that I will merge requests on github, pull them to my local repository, send the commit to the ML list before pushing it to linuxtv.org, but if better ideas arise, I'm all ears. Oliver -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ov10635: Add OmniVision ov10635 SoC camera driver
Hi Guennadi, snip Well, I think, both of you will agree, that these register value lists look horrible and actually have little to do with open-source software, but I don't know what to do about them either. We could just reject them and only accept drivers, properly describing what they do with the hardware, or request to move this into one of firmware loading options... But I'm not sure any of these options would actually do us any good. Just sayin'. Any further thoughts on what to do about this driver? Based on what I have seen, we aren't going to get the info to properly describe _all_ of the registers. It's a shame the camera's registers don't default to usable settings, but that's what we have. In the case of this driver, there are a number of registers that are programmed based on the required resolution, framerate and format. Extracting that from the material I had was rather painful and the result is useful for anyone wanting to use this camera. Any register written to outside ov10635_regs_default[] should be programmed in some meaningful way, whereas those in ov10635_regs_default[] should be treated like firmware. However, even those registers accessed outside of ov10635_regs_default[] could still do with better descriptions. I should note that some of the values written to registers are empirically derived since they are based on device timing. I don't have any details about the device timing, just the values that were written for a number of different modes (resolution and framerate). Maybe the pragmatic approach is to use firmware for all those in ov10635_regs_default[], and the rest of the registers have to be well documented. I was asked to remove some comments about register names/functionality by OmniVision, but I can ask again if it helps. Thanks Phil -- 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 RFC] media: lirc: Allow lirc dev to talk to rc device
From: Srinivas Kandagatla srinivas.kandaga...@st.com
The use case is simple, if any rc device has allowed protocols =
RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never
called. The reason for this is, all of the key maps except lirc have some
KEYS in there map, so during rc_register_device process these keys are
matched against the input drivers and open is performed, so for the case
of RC_MAP_EMPTY, a tty/vt/keyboard is matched and the driver open is
performed.
In case of lirc, there is no match and result is that there is no open
performed, however the lirc-dev will go ahead and create a /dev/lirc0
node. Now when lircd/mode2 opens this device, no data is available
because the driver was never opened.
lirc_dev seems to have no link with actual rc device w.r.t open/close.
This patch adds the missing link rc_dev pointer to lirc_driver structure
for cases like this, so that it can do the open/close of the real driver
in accordance to lircd/mode2 open/close.
Without this patch its impossible to open a rc device which has
RC_TYPE_LIRC ad RC_MAP_LIRC set.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/media/rc/ir-lirc-codec.c |1 +
drivers/media/rc/lirc_dev.c | 14 ++
include/media/lirc_dev.h |1 +
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index e456126..d5ad27f 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -375,6 +375,7 @@ static int ir_lirc_register(struct rc_dev *dev)
drv-code_length = sizeof(struct ir_raw_event) * 8;
drv-fops = lirc_fops;
drv-dev = dev-dev;
+ drv-rc_dev = dev;
drv-owner = THIS_MODULE;
drv-minor = lirc_register_driver(drv);
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 8dc057b..485bf7d 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -35,6 +35,7 @@
#include linux/device.h
#include linux/cdev.h
+#include media/rc-core.h
#include media/lirc.h
#include media/lirc_dev.h
@@ -437,6 +438,7 @@ EXPORT_SYMBOL(lirc_unregister_driver);
int lirc_dev_fop_open(struct inode *inode, struct file *file)
{
struct irctl *ir;
+ struct rc_dev *rc_dev;
struct cdev *cdev;
int retval = 0;
@@ -467,6 +469,13 @@ int lirc_dev_fop_open(struct inode *inode, struct file
*file)
goto error;
}
+ rc_dev = ir-d.rc_dev;
+ if (rc_dev rc_dev-open) {
+ retval = rc_dev-open(rc_dev);
+ if (retval)
+ goto error;
+ }
+
cdev = ir-cdev;
if (try_module_get(cdev-owner)) {
ir-open++;
@@ -499,6 +508,7 @@ int lirc_dev_fop_close(struct inode *inode, struct file
*file)
{
struct irctl *ir = irctls[iminor(inode)];
struct cdev *cdev;
+ struct rc_dev *rc_dev;
if (!ir) {
printk(KERN_ERR %s: called with invalid irctl\n, __func__);
@@ -511,6 +521,10 @@ int lirc_dev_fop_close(struct inode *inode, struct file
*file)
WARN_ON(mutex_lock_killable(lirc_dev_lock));
+ rc_dev = ir-d.rc_dev;
+ if (rc_dev rc_dev-close)
+ rc_dev-close(rc_dev);
+
ir-open--;
if (ir-attached) {
ir-d.set_use_dec(ir-d.data);
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h
index 168dd0b..96dccb6 100644
--- a/include/media/lirc_dev.h
+++ b/include/media/lirc_dev.h
@@ -139,6 +139,7 @@ struct lirc_driver {
struct lirc_buffer *rbuf;
int (*set_use_inc) (void *data);
void (*set_use_dec) (void *data);
+ struct rc_dev *rc_dev;
const struct file_operations *fops;
struct device *dev;
struct module *owner;
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] usbtv: Add S-Video input support
Alongside already existing Composite input.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: linux-ker...@vger.kernel.org
Cc: linux-media@vger.kernel.org
---
drivers/media/usb/usbtv/usbtv.c | 99 ---
1 files changed, 82 insertions(+), 17 deletions(-)
diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c
index 9165017..9b250a7 100644
--- a/drivers/media/usb/usbtv/usbtv.c
+++ b/drivers/media/usb/usbtv/usbtv.c
@@ -91,17 +91,78 @@ struct usbtv {
u32 frame_id;
int chunks_done;
+ enum {
+ USBTV_COMPOSITE_INPUT,
+ USBTV_SVIDEO_INPUT,
+ } input;
int iso_size;
unsigned int sequence;
struct urb *isoc_urbs[USBTV_ISOC_TRANSFERS];
};
-static int usbtv_setup_capture(struct usbtv *usbtv)
+static int usbtv_set_regs(struct usbtv *usbtv, const u16 regs[][2], int size)
{
int ret;
int pipe = usb_rcvctrlpipe(usbtv-udev, 0);
int i;
- static const u16 protoregs[][2] = {
+
+ for (i = 0; i size; i++) {
+ u16 index = regs[i][0];
+ u16 value = regs[i][1];
+
+ ret = usb_control_msg(usbtv-udev, pipe, USBTV_REQUEST_REG,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ value, index, NULL, 0, 0);
+ if (ret 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int usbtv_select_input(struct usbtv *usbtv, int input)
+{
+ int ret;
+
+ static const u16 composite[][2] = {
+ { USBTV_BASE + 0x0105, 0x0060 },
+ { USBTV_BASE + 0x011f, 0x00f2 },
+ { USBTV_BASE + 0x0127, 0x0060 },
+ { USBTV_BASE + 0x00ae, 0x0010 },
+ { USBTV_BASE + 0x0284, 0x00aa },
+ { USBTV_BASE + 0x0239, 0x0060 },
+ };
+
+ static const u16 svideo[][2] = {
+ { USBTV_BASE + 0x0105, 0x0010 },
+ { USBTV_BASE + 0x011f, 0x00ff },
+ { USBTV_BASE + 0x0127, 0x0060 },
+ { USBTV_BASE + 0x00ae, 0x0030 },
+ { USBTV_BASE + 0x0284, 0x0088 },
+ { USBTV_BASE + 0x0239, 0x0060 },
+ };
+
+ switch (input) {
+ case USBTV_COMPOSITE_INPUT:
+ ret = usbtv_set_regs(usbtv, composite, ARRAY_SIZE(composite));
+ break;
+ case USBTV_SVIDEO_INPUT:
+ ret = usbtv_set_regs(usbtv, svideo, ARRAY_SIZE(svideo));
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ if (!ret)
+ usbtv-input = input;
+
+ return ret;
+}
+
+static int usbtv_setup_capture(struct usbtv *usbtv)
+{
+ int ret;
+ static const u16 setup[][2] = {
/* These seem to enable the device. */
{ USBTV_BASE + 0x0008, 0x0001 },
{ USBTV_BASE + 0x01d0, 0x00ff },
@@ -189,16 +250,13 @@ static int usbtv_setup_capture(struct usbtv *usbtv)
{ USBTV_BASE + 0x024f, 0x0002 },
};
- for (i = 0; i ARRAY_SIZE(protoregs); i++) {
- u16 index = protoregs[i][0];
- u16 value = protoregs[i][1];
+ ret = usbtv_set_regs(usbtv, setup, ARRAY_SIZE(setup));
+ if (ret)
+ return ret;
- ret = usb_control_msg(usbtv-udev, pipe, USBTV_REQUEST_REG,
- USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- value, index, NULL, 0, 0);
- if (ret 0)
- return ret;
- }
+ ret = usbtv_select_input(usbtv, usbtv-input);
+ if (ret)
+ return ret;
return 0;
}
@@ -443,10 +501,17 @@ static int usbtv_querycap(struct file *file, void *priv,
static int usbtv_enum_input(struct file *file, void *priv,
struct v4l2_input *i)
{
- if (i-index 0)
+ switch (i-index) {
+ case USBTV_COMPOSITE_INPUT:
+ strlcpy(i-name, Composite, sizeof(i-name));
+ break;
+ case USBTV_SVIDEO_INPUT:
+ strlcpy(i-name, S-Video, sizeof(i-name));
+ break;
+ default:
return -EINVAL;
+ }
- strlcpy(i-name, Composite, sizeof(i-name));
i-type = V4L2_INPUT_TYPE_CAMERA;
i-std = V4L2_STD_525_60;
return 0;
@@ -486,15 +551,15 @@ static int usbtv_g_std(struct file *file, void *priv,
v4l2_std_id *norm)
static int usbtv_g_input(struct file *file, void *priv, unsigned int *i)
{
- *i = 0;
+ struct usbtv *usbtv = video_drvdata(file);
+ *i = usbtv-input;
return 0;
}
static int usbtv_s_input(struct file *file, void *priv, unsigned int i)
{
- if (i 0)
- return -EINVAL;
- return 0;
+ struct usbtv *usbtv = video_drvdata(file);
+
Fwd: dtv-scan-tables tar archive
Mauro, I think the archive is generated incorrectly. Could you take a look and see why? I shamefully admit I still am not sure where you did what to generate these ;) Oliver Original Message Subject:dtv-scan-tables tar archive Date: Fri, 12 Jul 2013 10:59:56 +0200 From: Till Maas opensou...@till.name To: Oliver Schinagl oli...@schinagl.nl Hi Oliver, the tar archives at http://linuxtv.org/downloads/dtv-scan-tables/ are broken. xxd dtv-scan-tables-2013-04-12-495e59e.tar | less shows: | 000: 6769 7420 6172 6368 6976 6520 2d2d 666f git archive --fo | 010: 726d 6174 2074 6172 202d 2d70 7265 6669 rmat tar --prefi | 020: 7820 2f75 7372 2f73 6861 7265 2f64 7662 x /usr/share/dvb | 030: 2f20 4845 4144 0a70 6178 5f67 6c6f 6261 / HEAD.pax_globa | 040: 6c5f 6865 6164 6572 l_header It seems like the git archive commandline somehow ended in the tarball. E.g. the tarball should start with pax_global_header and not with git archive. Regards Till -- 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 the latest tuning channel config data of Taiwan.
From: Huei-Horng Yo hiroshi...@gmail.com Signed-off-by: Oliver Schinagl oli...@schinagl.nl --- channels-conf/dvb-t/tw-All | 21 + dvb-t/tw-All | 11 +++ dvb-t/tw-Kaohsiung | 6 -- dvb-t/tw-Taipei| 7 --- 4 files changed, 32 insertions(+), 13 deletions(-) create mode 100644 channels-conf/dvb-t/tw-All create mode 100644 dvb-t/tw-All delete mode 100644 dvb-t/tw-Kaohsiung delete mode 100644 dvb-t/tw-Taipei diff --git a/channels-conf/dvb-t/tw-All b/channels-conf/dvb-t/tw-All new file mode 100644 index 000..a7fbe50 --- /dev/null +++ b/channels-conf/dvb-t/tw-All @@ -0,0 +1,21 @@ +???:53300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:1001:1002:100 +???:53300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:1011:1012:101 +???:53300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:1021:1022:102 +??HD???:53300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:1031:1032:103 + PTS:54500:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2011:2012:201 +??2??? PTS2:54500:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2021:2022:202 + HTV:54500:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2031:2032:203 +???:55700:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:3001:3002:300 +???:55700:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:3011:3012:301 +???:55700:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:3021:3022:302 +??:55700:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:303 +??HD???:55700:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:3041:3042:304 +?? HD:56900:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2001:2002:200 +???:58100:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:4001:4002:400 +???:58100:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:4011:4012:401 +???:58100:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:4021:4022:402 +?? HD???:58100:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:4031:4032:403 +??CTS:59300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:5011:5012:501 +???:59300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:5021:5022:502 +?:59300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:5031:5032:503 +??HD:59300:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:5041:5042:504 diff --git a/dvb-t/tw-All b/dvb-t/tw-All new file mode 100644 index 000..8290355 --- /dev/null +++ b/dvb-t/tw-All @@ -0,0 +1,11 @@ +T 53300 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 53900 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 54500 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 55100 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 55700 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 56300 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 56900 6MHz 2/3 NONE QAM64 8k 1/4 NONE +T 57500 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 58100 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 58700 6MHz 2/3 NONE QAM16 8k 1/4 NONE +T 59300 6MHz 2/3 NONE QAM16 8k 1/4 NONE diff --git a/dvb-t/tw-Kaohsiung b/dvb-t/tw-Kaohsiung deleted file mode 100644 index f1eabc9..000 --- a/dvb-t/tw-Kaohsiung +++ /dev/null @@ -1,6 +0,0 @@ -# Taiwan - Kaohsiung, southern Taiwan -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 54500 6MHz 2/3 NONE QAM16 8k 1/4 NONE -T 54500 6MHz 2/3 NONE QAM16 8k 1/8 NONE -T 55700 6MHz 2/3 NONE QAM16 8k 1/4 NONE -T 55700 6MHz 2/3 NONE QAM16 8k 1/8 NONE diff --git a/dvb-t/tw-Taipei b/dvb-t/tw-Taipei deleted file mode 100644 index 3bba686..000 --- a/dvb-t/tw-Taipei +++
[RFC] Dropping of channels-conf from dtv-scan-tables
Hey all, The channels-conf directory in the dtv-scan-tables repository is bitrotten. Besides tw-All, the newest addition is over 6 years ago, with some being as old as 9 years. While I'm sure it's possible that the channels-conf are still accurate, it's not really needed any longer. Unless valid reasons are brought up to keep it, I will move it to a seperate branch and delete it from the master branch in the next few weeks. Thanks, Oliver -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] media: lirc: Allow lirc dev to talk to rc device
On Fri, Jul 12, 2013 at 09:55:28AM +0100, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
The use case is simple, if any rc device has allowed protocols =
RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never
called. The reason for this is, all of the key maps except lirc have some
KEYS in there map, so during rc_register_device process these keys are
matched against the input drivers and open is performed, so for the case
of RC_MAP_EMPTY, a tty/vt/keyboard is matched and the driver open is
performed.
In case of lirc, there is no match and result is that there is no open
performed, however the lirc-dev will go ahead and create a /dev/lirc0
node. Now when lircd/mode2 opens this device, no data is available
because the driver was never opened.
The rc device gets opened via the input interface. If the input device is
never opened (e.g. embedded with no console) then the rc open is never
called and lirc will not work either. So that's another case.
lirc_dev seems to have no link with actual rc device w.r.t open/close.
This patch adds the missing link rc_dev pointer to lirc_driver structure
for cases like this, so that it can do the open/close of the real driver
in accordance to lircd/mode2 open/close.
Without this patch its impossible to open a rc device which has
RC_TYPE_LIRC ad RC_MAP_LIRC set.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
drivers/media/rc/ir-lirc-codec.c |1 +
drivers/media/rc/lirc_dev.c | 14 ++
include/media/lirc_dev.h |1 +
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/media/rc/ir-lirc-codec.c
b/drivers/media/rc/ir-lirc-codec.c
index e456126..d5ad27f 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -375,6 +375,7 @@ static int ir_lirc_register(struct rc_dev *dev)
drv-code_length = sizeof(struct ir_raw_event) * 8;
drv-fops = lirc_fops;
drv-dev = dev-dev;
+ drv-rc_dev = dev;
drv-owner = THIS_MODULE;
drv-minor = lirc_register_driver(drv);
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 8dc057b..485bf7d 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -35,6 +35,7 @@
#include linux/device.h
#include linux/cdev.h
+#include media/rc-core.h
#include media/lirc.h
#include media/lirc_dev.h
@@ -437,6 +438,7 @@ EXPORT_SYMBOL(lirc_unregister_driver);
int lirc_dev_fop_open(struct inode *inode, struct file *file)
{
struct irctl *ir;
+ struct rc_dev *rc_dev;
struct cdev *cdev;
int retval = 0;
@@ -467,6 +469,13 @@ int lirc_dev_fop_open(struct inode *inode, struct file
*file)
goto error;
}
+ rc_dev = ir-d.rc_dev;
+ if (rc_dev rc_dev-open) {
+ retval = rc_dev-open(rc_dev);
+ if (retval)
+ goto error;
+ }
+
Now the rc device can have its open called twice; once via the input
system and then (while it is already opened) via lirc. The rc drivers do
not expect this.
cdev = ir-cdev;
if (try_module_get(cdev-owner)) {
ir-open++;
@@ -499,6 +508,7 @@ int lirc_dev_fop_close(struct inode *inode, struct file
*file)
{
struct irctl *ir = irctls[iminor(inode)];
struct cdev *cdev;
+ struct rc_dev *rc_dev;
if (!ir) {
printk(KERN_ERR %s: called with invalid irctl\n, __func__);
@@ -511,6 +521,10 @@ int lirc_dev_fop_close(struct inode *inode, struct file
*file)
WARN_ON(mutex_lock_killable(lirc_dev_lock));
+ rc_dev = ir-d.rc_dev;
+ if (rc_dev rc_dev-close)
+ rc_dev-close(rc_dev);
+
iguanair, nuvoton and ene_ir will disable the ir receiver when their close
function is called. If the device was also opened via the input interface,
the input interface will receive no new ir activity.
I think there should be some sort of (atomic) use counter so that the
rc device open or close only gets called once, whether opened via the
input interface or via lirc.
ir-open--;
if (ir-attached) {
ir-d.set_use_dec(ir-d.data);
diff --git a/include/media/lirc_dev.h b/include/media/lirc_dev.h
index 168dd0b..96dccb6 100644
--- a/include/media/lirc_dev.h
+++ b/include/media/lirc_dev.h
@@ -139,6 +139,7 @@ struct lirc_driver {
struct lirc_buffer *rbuf;
int (*set_use_inc) (void *data);
void (*set_use_dec) (void *data);
+ struct rc_dev *rc_dev;
const struct file_operations *fops;
struct device *dev;
struct module *owner;
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe
Re: [omap3isp] xclk deadlock
Hi Laurent, On 05.07.13 12:48, Laurent Pinchart wrote: Thanks for the explanation. It would be great if you could update your board/beagle/mt9p031 branch and include the discussed changes. Done. Could you please test it ? Thanks for you help. There are no errors about the clocks or regulators now but the rest does not work so well (everything mentioned below works fine on my old 3.2.24 kernel): 1. The images streamed to omapdss using omap3-isp-live look like they lost synchronization with a black bar horizontal bar jumping on the screen and other such artifacts (it looks as if both width and height were invalid). The framerate is about a half of what it should be. Adjusting the camera iris changes the lightness of the image so the whole pipeline is working to some extent (so these artifacts are not just some random memory patterns). The Register dumps are a little different between 3.2.24 and 3.10 [4]. 2. When exiting from live the kernel hangs more often then not (sometimes it is accompanied by Unhandled fault: external abort on non-linefetch in dispc_write_irqenable in omapdss). 3. After setting up a simple pipeline using media-ctl[2] I get CCDC won't become idle errors. If I do this after running live I also get (unless it hangs) the CCDC Register dump [1]. Otherwise I only get the stream of kernel log messages without anything else from omap3isp. 4. I recreated the live pipeline (judging by the lack of differences in media-ctl -p output [3]) and used yavta. I get the same hangs but when I don't I can check the UYVY frames one by one. They look bad at any stride (I dropped the UV components and tried to get some meaningful output in the GIMP raw image data import dialog by adjustung the width). [1]: [ 153.774017] omap3isp omap3isp: -CCDC Register dump- [ 153.781494] omap3isp omap3isp: ###CCDC PCR=0x [ 153.786773] omap3isp omap3isp: ###CCDC SYN_MODE=0x00030400 [ 153.792572] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 153.798431] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 153.804290] omap3isp omap3isp: ###CCDC HORZ_INFO=0x031f [ 153.810180] omap3isp omap3isp: ###CCDC VERT_START=0x [ 153.816101] omap3isp omap3isp: ###CCDC VERT_LINES=0x0257 [ 153.822052] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 153.827728] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x0640 [ 153.833648] omap3isp omap3isp: ###CCDC SDOFST=0x [ 153.839263] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 153.845001] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 153.850524] omap3isp omap3isp: ###CCDC DCSUB=0x [ 153.855987] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 153.861602] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 153.867156] omap3isp omap3isp: ###CCDC FPC=0x [ 153.872497] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 153.878265] omap3isp omap3isp: ###CCDC VDINT=0x02560190 [ 153.883789] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 153.889221] omap3isp omap3isp: ###CCDC REC656IF=0x [ 153.894958] omap3isp omap3isp: ###CCDC CFG=0x8000 [ 153.900299] omap3isp omap3isp: ###CCDC FMTCFG=0xc000 [ 153.905853] omap3isp omap3isp: ###CCDC FMT_HORZ=0x0320 [ 153.911651] omap3isp omap3isp: ###CCDC FMT_VERT=0x0258 [ 153.917388] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 153.923187] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 153.928955] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 153.934661] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 153.940338] omap3isp omap3isp: ###CCDC VP_OUT=0x04ae3200 [ 153.945922] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 153.951873] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 153.957916] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 153.964233] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 153.970733] omap3isp omap3isp: [ 154.174468] omap3isp omap3isp: CCDC won't become idle! [ 154.315917] omap3isp omap3isp: CCDC won't become idle! [ 154.340118] omap3isp omap3isp: CCDC won't become idle! [ 154.364349] omap3isp omap3isp: CCDC won't become idle! [ 154.388549] omap3isp omap3isp: CCDC won't become idle! [ 154.412750] omap3isp omap3isp: CCDC won't become idle! [ 154.436950] omap3isp omap3isp: CCDC won't become idle! [ 154.461151] omap3isp omap3isp: CCDC won't become idle! [ 154.485382] omap3isp omap3isp: CCDC won't become idle! [2]: media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v -f 'mt9p031 2-0048:0 [SGRBG12 800x600 (96,72)/2400x1800], OMAP3 ISP CCDC:1 [SGRBG8 800x600]' yavta -f SGRBG12 -s 800x600 -n 8 --skip 4 --capture=5 -F'frame-#.bin' $(media-ctl -e OMAP3 ISP CCDC output) [3]: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information
Help needed: Wrong Maintainer Contact
Hi, the maintainer contact for the cx231xx driver is broken - the author of that driver is not reachable via the email adress stated in the source file: srinivasa.de...@conexant.com [ host cnxtsmtp1.conexant.com [198.62.9.252]: 550 5.1.1 srinivasa.de...@conexant.com: Recipient address rejected: User unknown in relay recipient table] Is this the right place to report this? /Florian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CX23103 Video Grabber seems to be supported by cx231xx driver
Hi,
the chip CX23103 that is used in various devices sold e.g. in germany works
with the cx231xx stock driver.
The author of that driver is not reachable via the email adress stated in the
source file: srinivasa.de...@conexant.com
[ host cnxtsmtp1.conexant.com [198.62.9.252]: 550 5.1.1
srinivasa.de...@conexant.com: Recipient address rejected: User unknown in
relay recipient table]
In drivers/media/video/cx231xx/cx231xx-cards.c the struct usb_device_id
cx231xx_id_table[] needs these lines added:
{USB_DEVICE(0x1D19, 0x6109),
.driver_info = CX231XX_BOARD_PV_XCAPTURE_USB},
While the change is minimal due to the fact that no real technical
documentation is available on the chip the support was guessed - but worked for
video.
The videostream can pe played using mplayer tv:///0 - proof:
http://streibelt.de/blog/2013/06/23/kernel-patch-for-cx23103-video-grabber-linux-support/
However when trying to capture audio using audacity while playing the video
stream in mplayer my system locked (no message in syslog, complete freeze).
I posted this one month ago to this list without any reaction so I ask if this
is the correct way to get that grabber really supported.
I am willing to do any tests neccessary and try out patches.
/Florian
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Jul 12 19:00:20 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API 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: dtv-scan-tables tar archive
Em Fri, 12 Jul 2013 11:07:55 +0200
Oliver Schinagl oliver+l...@schinagl.nl escreveu:
Mauro,
I think the archive is generated incorrectly. Could you take a look and
see why? I shamefully admit I still am not sure where you did what to
generate these ;)
Basically, I run a script like the one below once a day at the crontab:
#!/bin/bash
LANG=C
PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
DIR=/some_temp_location/dtv-scan-tables
DATE=`git log -n1 '--pretty=format:%h %ai' |perl -ne 'print $2-$1 if
(m/([\da-f]+)\s+(\S+)/)'`
TODAY_TAR=dtv-scan-tables-$DATE.tar
FILE=$TODAY_TAR.bz2
REPO=/the_www_location/downloads/dtv-scan-tables/
run() {
echo $@
$@
if [ $? != 0 ]; then
echo Error $?. Please fix.
exit -1
fi
}
run cd $DIR
run git pull /git/dtv-scan-tables.git/ master
CHANGES=`git log --pretty=oneline -n1`
if [ $CHANGES = `cat .changes` ]; then
echo tarball already updated to the latest changeset.
echo Nothing to do.
exit;
fi
git archive --format tar --prefix /usr/share/dvb/ HEAD $TODAY_TAR
run bzip2 -f $TODAY_TAR
run mv $FILE $REPO
run ln -sf $FILE $REPO/dtv-scan-tables-LATEST.tar.bz2
(cd $REPO; md5sum *.bz2 md5sum)
echo $CHANGES .changes
Oliver
Original Message
Subject: dtv-scan-tables tar archive
Date: Fri, 12 Jul 2013 10:59:56 +0200
From: Till Maas opensou...@till.name
To: Oliver Schinagl oli...@schinagl.nl
Hi Oliver,
the tar archives at
http://linuxtv.org/downloads/dtv-scan-tables/
are broken.
xxd dtv-scan-tables-2013-04-12-495e59e.tar | less shows:
| 000: 6769 7420 6172 6368 6976 6520 2d2d 666f git archive --fo
| 010: 726d 6174 2074 6172 202d 2d70 7265 6669 rmat tar --prefi
| 020: 7820 2f75 7372 2f73 6861 7265 2f64 7662 x /usr/share/dvb
| 030: 2f20 4845 4144 0a70 6178 5f67 6c6f 6261 / HEAD.pax_globa
| 040: 6c5f 6865 6164 6572 l_header
It seems like the git archive commandline somehow ended in the tarball.
E.g. the tarball should start with pax_global_header and not with git
archive.
Thanks for pointing it to me. I fixed the script.
Regards
Till
--
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,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add initial DVB-T frequencies for Bulgaria
From: Vladimir Lalov v.la...@gmail.com Signed-off-by: Oliver Schinagl oli...@schinagl.nl --- dvb-t/bg-Sofia | 16 1 file changed, 16 insertions(+) create mode 100644 dvb-t/bg-Sofia diff --git a/dvb-t/bg-Sofia b/dvb-t/bg-Sofia new file mode 100644 index 000..82cc037 --- /dev/null +++ b/dvb-t/bg-Sofia @@ -0,0 +1,16 @@ +#-- +# file automatically generated by w_scan +# (http://wirbel.htpc-forum.de/w_scan/index2.html) +#! w_scan 20130331 1 0 TERRESTRIAL BG /w_scan +#-- +# location and provider: Sofia +# date (-mm-dd): 2013-05-13 +# provided by (opt): v.la...@gmail.com +# +# T[2] [plp_id] [system_id] freq bw fec_hi fec_lo mod tm guard hi [# comment] +#-- +T 49000 8MHz 2/3 NONEQAM64 8k 1/4 NONE # NURTS Digital +T 62600 8MHz 2/3 NONEQAM64 8k 1/4 NONE # NURTS Digital +T 72200 8MHz 2/3 NONEQAM64 8k 1/4 NONE # First Digital +T 81800 8MHz 2/3 NONEQAM16 8k 1/16 NONE # NURTS + -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] cx25821 regression from 3.9: BUG: bad unlock balance detected!
Friday, May 17, 2013, 11:52:17 AM, you wrote:
On Fri May 17 2013 11:04:50 Sander Eikelenboom wrote:
Friday, May 17, 2013, 10:25:24 AM, you wrote:
On Thu May 16 2013 19:41:42 Sander Eikelenboom wrote:
Hi Hans / Mauro,
With 3.10.0-rc1 (including the cx25821 changes from Hans), I get the bug
below which wasn't present with 3.9.
How do I reproduce this? I've tried to, but I can't make this happen.
Looking at the code I can't see how it could hit this bug anyway.
I'm using motion to grab and process 6 from the video streams of the card
i have (card with 8 inputs).
It seems the cx25821 underwent quite some changes between 3.9 and 3.10.
It did.
And in the past there have been some more locking issues around mmap and
media devices, although they seem to appear as circular locking dependencies
and with different devices.
- http://www.mail-archive.com/linux-media@vger.kernel.org/msg46217.html
- Under kvm: http://www.spinics.net/lists/linux-media/msg63322.html
Neither of those are related to this issue.
- Perhaps that running in a VM could have to do with it ?
- The driver on 3.9 occasionaly gives this, probably latency related (but
continues to work):
cx25821: cx25821_video_wakeup: 2 buffers handled (should be 1)
Could it be something double unlocking in that path ?
- Is there any extra debugging i could enable that could pinpoint the issue ?
Try this patch:
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index b762c5b..8f8d0e0 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -1208,7 +1208,6 @@ void cx25821_free_buffer(struct videobuf_queue *q,
struct cx25821_buffer *buf)
struct videobuf_dmabuf *dma = videobuf_to_dma(buf-vb);
BUG_ON(in_interrupt());
- videobuf_waiton(q, buf-vb, 0, 0);
videobuf_dma_unmap(q-dev, dma);
videobuf_dma_free(dma);
btcx_riscmem_free(to_pci_dev(q-dev), buf-risc);
I don't think the waiton is really needed for this driver.
What really should happen is that videobuf is replaced by videobuf2 in this
driver, but that's a fair amount of work.
Hi Hans,
After being busy for quite some time, i do have some spare time now.
Since i'm still having trouble with this driver, is there a patch series for a
similar driver
that was converted to videobuf2 ?
I don't know if it is entirely in my league, but i could give it a try when i
have a example.
--
Sander
Regards,
Hans
--
Sander
Regards,
Hans
--
Sander
[ 53.004968] =
[ 53.004968] [ BUG: bad unlock balance detected! ]
[ 53.004968] 3.10.0-rc1-20130516-jens+ #1 Not tainted
[ 53.004968] -
[ 53.004968] motion/3328 is trying to release lock (dev-lock) at:
[ 53.004968] [819be5f9] mutex_unlock+0x9/0x10
[ 53.004968] but there are no more locks to release!
[ 53.004968]
[ 53.004968] other info that might help us debug this:
[ 53.004968] 1 lock held by motion/3328:
[ 53.004968] #0: (mm-mmap_sem){++}, at: [81156cae]
vm_munmap+0x3e/0x70
[ 53.004968]
[ 53.004968] stack backtrace:
[ 53.004968] CPU: 1 PID: 3328 Comm: motion Not tainted
3.10.0-rc1-20130516-jens+ #1
[ 53.004968] Hardware name: Xen HVM domU, BIOS 4.3-unstable 05/16/2013
[ 53.004968] 819be5f9 88002ac35c58 819b9029
88002ac35c88
[ 53.004968] 810e615e 88002ac35cb8 88002b7c18a8
819be5f9
[ 53.004968] 88002ac35d28 810eb17e
810e7ba5
[ 53.004968] Call Trace:
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [819b9029] dump_stack+0x19/0x1b
[ 53.004968] [810e615e] print_unlock_imbalance_bug+0xfe/0x110
[ 53.004968] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.004968] [810eb17e] lock_release_non_nested+0x1ce/0x320
[ 53.004968] [810e7ba5] ?
debug_check_no_locks_freed+0x105/0x1b0
[ 53.353529] [819be5f9] ? mutex_unlock+0x9/0x10
[ 53.353529] [810eb3cc] lock_release+0xfc/0x250
[ 53.353529] [819be4b2] __mutex_unlock_slowpath+0xb2/0x1f0
[ 53.353529] [819be5f9] mutex_unlock+0x9/0x10
[ 53.353529] [81711105] videobuf_waiton+0x55/0x230
[ 53.353529] [8114d052] ? tlb_finish_mmu+0x32/0x50
[ 53.353529] [81154a46] ? unmap_region+0xc6/0x100
[ 53.353529] [81172e05] ? kmem_cache_free+0x195/0x230
[ 53.353529] [8172d3d9] cx25821_free_buffer+0x49/0xa0
[ 53.353529] [8172f939] cx25821_buffer_release+0x9/0x10
[ 53.353529] [81712c35] videobuf_vm_close+0xc5/0x160
[ 53.353529] [81154aa5] remove_vma+0x25/0x60
[ 53.353529]
[PATCH][dvb-apps] Fix 'scan' utility region 0x14 encoding from BIG5 to UTF-16BE
From: Huei-Horng Yo hiroshi...@gmail.com Signed-off-by: Huei-Horng Yo hiroshi...@gmail.com --- scan.patch Description: Binary data
Re: [PATCH][dvb-apps] Fix 'scan' utility region 0x14 encoding from BIG5 to UTF-16BE
於 西元2013年07月13日 10:44, Huei-Horng Yo 提到: From: Huei-Horng Yo hiroshi...@gmail.com Signed-off-by: Huei-Horng Yo hiroshi...@gmail.com --- Sorry, don't know how to keep tab in GMail and the attachment is encoded in MIME form. :( --- From: Huei-Horng Yo hiroshi...@gmail.com Signed-off-by: Huei-Horng Yo hiroshi...@gmail.com --- diff --git a/util/scan/scan.c b/util/scan/scan.c index 71a20db..98093ee 100644 --- a/util/scan/scan.c +++ b/util/scan/scan.c @@ -850,7 +850,7 @@ static void descriptorcpy(char **dest, const unsigned char *src, size_t len) case 0x11: type = ISO-10646; break; case 0x12: type = ISO-2022-KR; break; case 0x13: type = GB2312; break; - case 0x14: type = BIG5;break; + case 0x14: type = UTF-16BE;break; case 0x15: type = ISO-10646/UTF-8; break; case 0x10: /* ISO8859 */ if ((*(src + 1) != 0) || *(src + 2) 0x0f) -- 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
