Re: [REVIEW PATCH 2/4] media: remove the setting of the flag V4L2_FL_USE_FH_PRIO.
On 06/19/2014 07:22 PM, Ramakrishnan Muthukrishnan wrote: From: Ramakrishnan Muthukrishnan ramak...@cisco.com Since all the drivers that use `struct v4l2_fh' use the core priority checking, the setting of the flag in the drivers can be removed. Signed-off-by: Ramakrishnan Muthukrishnan ramak...@cisco.com Reviewed-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/common/saa7146/saa7146_fops.c| 1 - drivers/media/parport/bw-qcam.c| 1 - drivers/media/parport/c-qcam.c | 1 - drivers/media/parport/pms.c| 1 - drivers/media/parport/w9966.c | 1 - drivers/media/pci/bt8xx/bttv-driver.c | 1 - drivers/media/pci/cx18/cx18-streams.c | 1 - drivers/media/pci/cx25821/cx25821-video.c | 1 - drivers/media/pci/cx88/cx88-core.c | 1 - drivers/media/pci/ivtv/ivtv-streams.c | 1 - drivers/media/pci/meye/meye.c | 1 - drivers/media/pci/saa7134/saa7134-core.c | 1 - drivers/media/pci/saa7134/saa7134-empress.c| 1 - drivers/media/pci/sta2x11/sta2x11_vip.c| 1 - drivers/media/platform/arv.c | 1 - drivers/media/platform/blackfin/bfin_capture.c | 1 - drivers/media/platform/davinci/vpbe_display.c | 1 - drivers/media/platform/davinci/vpfe_capture.c | 1 - drivers/media/platform/davinci/vpif_capture.c | 1 - drivers/media/platform/davinci/vpif_display.c | 1 - drivers/media/platform/s3c-camif/camif-capture.c | 1 - drivers/media/platform/s5p-tv/mixer_video.c| 2 -- drivers/media/platform/vivi.c | 1 - drivers/media/radio/dsbr100.c | 1 - drivers/media/radio/radio-cadet.c | 1 - drivers/media/radio/radio-isa.c| 1 - drivers/media/radio/radio-keene.c | 1 - drivers/media/radio/radio-ma901.c | 1 - drivers/media/radio/radio-miropcm20.c | 1 - drivers/media/radio/radio-mr800.c | 1 - drivers/media/radio/radio-raremono.c | 1 - drivers/media/radio/radio-sf16fmi.c| 1 - drivers/media/radio/radio-si476x.c | 1 - drivers/media/radio/radio-tea5764.c| 1 - drivers/media/radio/radio-tea5777.c| 1 - drivers/media/radio/radio-timb.c | 1 - drivers/media/radio/si470x/radio-si470x-usb.c | 1 - drivers/media/radio/si4713/radio-platform-si4713.c | 1 - drivers/media/radio/si4713/radio-usb-si4713.c | 1 - drivers/media/radio/tea575x.c | 1 - drivers/media/usb/au0828/au0828-video.c| 2 -- drivers/media/usb/cpia2/cpia2_v4l.c| 1 - drivers/media/usb/cx231xx/cx231xx-417.c| 1 - drivers/media/usb/cx231xx/cx231xx-video.c | 1 - drivers/media/usb/em28xx/em28xx-video.c| 1 - drivers/media/usb/gspca/gspca.c| 1 - drivers/media/usb/hdpvr/hdpvr-video.c | 1 - drivers/media/usb/pwc/pwc-if.c | 1 - drivers/media/usb/s2255/s2255drv.c | 1 - drivers/media/usb/stk1160/stk1160-v4l.c| 1 - drivers/media/usb/stkwebcam/stk-webcam.c | 1 - drivers/media/usb/tlg2300/pd-radio.c | 1 - drivers/media/usb/tm6000/tm6000-video.c| 1 - drivers/media/usb/usbtv/usbtv-video.c | 1 - drivers/media/usb/uvc/uvc_driver.c | 1 - drivers/media/usb/zr364xx/zr364xx.c| 1 - drivers/staging/media/davinci_vpfe/vpfe_video.c| 1 - drivers/staging/media/go7007/go7007-v4l2.c | 1 - drivers/staging/media/msi3101/sdr-msi3101.c| 1 - drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c | 1 - drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 1 - drivers/staging/media/solo6x10/solo6x10-v4l2.c | 1 - 62 files changed, 64 deletions(-) diff --git a/drivers/media/common/saa7146/saa7146_fops.c b/drivers/media/common/saa7146/saa7146_fops.c index eda01bc..f2cc521 100644 --- a/drivers/media/common/saa7146/saa7146_fops.c +++ b/drivers/media/common/saa7146/saa7146_fops.c @@ -613,7 +613,6 @@ int saa7146_register_device(struct video_device **vid, struct saa7146_dev* dev, vfd-lock = dev-v4l2_lock; vfd-v4l2_dev = dev-v4l2_dev; vfd-tvnorms = 0; - set_bit(V4L2_FL_USE_FH_PRIO, vfd-flags); for (i = 0; i dev-ext_vv_data-num_stds; i++) vfd-tvnorms |= dev-ext_vv_data-stds[i].id; strlcpy(vfd-name, name, sizeof(vfd-name)); diff --git a/drivers/media/parport/bw-qcam.c b/drivers/media/parport/bw-qcam.c index 416507a..3c5dac4 100644 --- a/drivers/media/parport/bw-qcam.c +++ b/drivers/media/parport/bw-qcam.c @@ -990,7 +990,6 @@ static struct qcam *qcam_init(struct parport *port) qcam-vdev.fops =
Re: [REVIEW PATCH 3/4] media: v4l2-dev.h: remove V4L2_FL_USE_FH_PRIO flag.
On 06/19/2014 07:22 PM, Ramakrishnan Muthukrishnan wrote: From: Ramakrishnan Muthukrishnan ramak...@cisco.com Since none of the drivers are using it, this flag can be removed. Signed-off-by: Ramakrishnan Muthukrishnan ramak...@cisco.com Reviewed-by: Hans Verkuil hans.verk...@cisco.com --- include/media/v4l2-dev.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h index eec6e46..eb76cfd 100644 --- a/include/media/v4l2-dev.h +++ b/include/media/v4l2-dev.h @@ -44,8 +44,6 @@ struct v4l2_ctrl_handler; #define V4L2_FL_REGISTERED (0) /* file-private_data points to struct v4l2_fh */ #define V4L2_FL_USES_V4L2_FH (1) -/* Use the prio field of v4l2_fh for core priority checking */ -#define V4L2_FL_USE_FH_PRIO (2) /* Priority helper functions */ -- 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: [REVIEW PATCH 4/4] media: Documentation: remove V4L2_FL_USE_FH_PRIO flag.
On 06/19/2014 07:23 PM, Ramakrishnan Muthukrishnan wrote: From: Ramakrishnan Muthukrishnan ramak...@cisco.com Signed-off-by: Ramakrishnan Muthukrishnan ramak...@cisco.com Reviewed-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/video4linux/v4l2-framework.txt | 8 +--- Documentation/video4linux/v4l2-pci-skeleton.c | 5 - Documentation/zh_CN/video4linux/v4l2-framework.txt | 7 +-- 3 files changed, 2 insertions(+), 18 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 667a433..a11dff0 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -675,11 +675,6 @@ You should also set these fields: video_device is initialized you *do* know which parent PCI device to use and so you set dev_device to the correct PCI device. -- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework - handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct - v4l2_fh. Eventually this flag will disappear once all drivers use the core - priority handling. But for now it has to be set explicitly. - If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2 in your v4l2_file_operations struct. @@ -909,8 +904,7 @@ struct v4l2_fh struct v4l2_fh provides a way to easily keep file handle specific data that is used by the V4L2 framework. New drivers must use struct v4l2_fh -since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY) -if the video_device flag V4L2_FL_USE_FH_PRIO is also set. +since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY). The users of v4l2_fh (in the V4L2 framework, not the driver) know whether a driver uses v4l2_fh as its file-private_data pointer by diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c index 46904fe..006721e 100644 --- a/Documentation/video4linux/v4l2-pci-skeleton.c +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -883,11 +883,6 @@ static int skeleton_probe(struct pci_dev *pdev, const struct pci_device_id *ent) vdev-v4l2_dev = skel-v4l2_dev; /* Supported SDTV standards, if any */ vdev-tvnorms = SKEL_TVNORMS; - /* If this bit is set, then the v4l2 core will provide the support - * for the VIDIOC_G/S_PRIORITY ioctls. This flag will eventually - * go away once all drivers have been converted to use struct v4l2_fh. - */ - set_bit(V4L2_FL_USE_FH_PRIO, vdev-flags); video_set_drvdata(vdev, skel); ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1); diff --git a/Documentation/zh_CN/video4linux/v4l2-framework.txt b/Documentation/zh_CN/video4linux/v4l2-framework.txt index 0da95db..2b828e6 100644 --- a/Documentation/zh_CN/video4linux/v4l2-framework.txt +++ b/Documentation/zh_CN/video4linux/v4l2-framework.txt @@ -580,11 +580,6 @@ release()回调必须被设置，且在最后一个 video_device 用户退出之 v4l2_device 无法与特定的 PCI 设备关联，所有没有设置父设备。但当 video_device 配置后，就知道使用哪个父 PCI 设备了。 -- flags：可选。如果你要让框架处理设置 VIDIOC_G/S_PRIORITY ioctls， - 请设置 V4L2_FL_USE_FH_PRIO。这要求你使用 v4l2_fh 结构体。 - 一旦所有驱动使用了核心的优先级处理，最终这个标志将消失。但现在它 - 必须被显式设置。 - 如果你使用 v4l2_ioctl_ops，则应该在 v4l2_file_operations 结构体中 设置 .unlocked_ioctl 指向 video_ioctl2。 @@ -789,7 +784,7 @@ v4l2_fh 结构体 - v4l2_fh 结构体提供一个保存用于 V4L2 框架的文件句柄特定数据的简单方法。 -如果 video_device 的 flag 设置了 V4L2_FL_USE_FH_PRIO 标志，新驱动 +如果 video_device 标志，新驱动 必须使用 v4l2_fh 结构体，因为它也用于实现优先级处理（VIDIOC_G/S_PRIORITY）。 v4l2_fh 的用户（位于 V4l2 框架中，并非驱动）可通过测试 -- 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
bttv and colorspace
Hi Mauro, I wonder if you remember anything about the reported broken colorspace handling of bttv. The spec talks about V4L2_COLORSPACE_BT878 where the Y range is 16-253 instead of the usual 16-235. I downloaded a bt878 datasheet and that mentions the normal 16-235 range. I wonder if this was perhaps a bug in older revisions of the bt878. Do you remember anything about this? I plan on doing some tests with my bttv cards next week. The main reason I'm interested in this is that I am researching the colorspace handling in v4l2 (and how it is defined in the spec). That needs to be nailed down because today nobody really knows how it is supposed to work and it is a complicated topic. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 1/4] media: v4l2-core: remove the use of V4L2_FL_USE_FH_PRIO flag.
On 06/19/2014 07:22 PM, Ramakrishnan Muthukrishnan wrote:
From: Ramakrishnan Muthukrishnan ramak...@cisco.com
Since all the drivers that use `struct v4l2_fh' use the core priority
checking instead of doing it themselves, this flag can be removed.
This patch removes the usage of the flag from v4l2-core.
Signed-off-by: Ramakrishnan Muthukrishnan ramak...@cisco.com
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Thanks!
Hans
---
drivers/media/v4l2-core/v4l2-dev.c | 6 ++
drivers/media/v4l2-core/v4l2-fh.c| 13 +
drivers/media/v4l2-core/v4l2-ioctl.c | 9 +++--
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index 634d863..35698aa 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -563,11 +563,9 @@ static void determine_valid_ioctls(struct video_device
*vdev)
/* vfl_type and vfl_dir independent ioctls */
SET_VALID_IOCTL(ops, VIDIOC_QUERYCAP, vidioc_querycap);
- if (ops-vidioc_g_priority ||
- test_bit(V4L2_FL_USE_FH_PRIO, vdev-flags))
+ if (ops-vidioc_g_priority)
set_bit(_IOC_NR(VIDIOC_G_PRIORITY), valid_ioctls);
- if (ops-vidioc_s_priority ||
- test_bit(V4L2_FL_USE_FH_PRIO, vdev-flags))
+ if (ops-vidioc_s_priority)
set_bit(_IOC_NR(VIDIOC_S_PRIORITY), valid_ioctls);
SET_VALID_IOCTL(ops, VIDIOC_STREAMON, vidioc_streamon);
SET_VALID_IOCTL(ops, VIDIOC_STREAMOFF, vidioc_streamoff);
diff --git a/drivers/media/v4l2-core/v4l2-fh.c
b/drivers/media/v4l2-core/v4l2-fh.c
index e57c002..c97067a 100644
--- a/drivers/media/v4l2-core/v4l2-fh.c
+++ b/drivers/media/v4l2-core/v4l2-fh.c
@@ -37,6 +37,13 @@ void v4l2_fh_init(struct v4l2_fh *fh, struct video_device
*vdev)
fh-ctrl_handler = vdev-ctrl_handler;
INIT_LIST_HEAD(fh-list);
set_bit(V4L2_FL_USES_V4L2_FH, fh-vdev-flags);
+ /*
+ * determine_valid_ioctls() does not know if struct v4l2_fh
+ * is used by this driver, but here we do. So enable the
+ * prio ioctls here.
+ */
+ set_bit(_IOC_NR(VIDIOC_G_PRIORITY), vdev-valid_ioctls);
+ set_bit(_IOC_NR(VIDIOC_S_PRIORITY), vdev-valid_ioctls);
fh-prio = V4L2_PRIORITY_UNSET;
init_waitqueue_head(fh-wait);
INIT_LIST_HEAD(fh-available);
@@ -49,8 +56,7 @@ void v4l2_fh_add(struct v4l2_fh *fh)
{
unsigned long flags;
- if (test_bit(V4L2_FL_USE_FH_PRIO, fh-vdev-flags))
- v4l2_prio_open(fh-vdev-prio, fh-prio);
+ v4l2_prio_open(fh-vdev-prio, fh-prio);
spin_lock_irqsave(fh-vdev-fh_lock, flags);
list_add(fh-list, fh-vdev-fh_list);
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
@@ -78,8 +84,7 @@ void v4l2_fh_del(struct v4l2_fh *fh)
spin_lock_irqsave(fh-vdev-fh_lock, flags);
list_del_init(fh-list);
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
- if (test_bit(V4L2_FL_USE_FH_PRIO, fh-vdev-flags))
- v4l2_prio_close(fh-vdev-prio, fh-prio);
+ v4l2_prio_close(fh-vdev-prio, fh-prio);
}
EXPORT_SYMBOL_GPL(v4l2_fh_del);
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 16bffd8..8d4a25d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2190,7 +2190,6 @@ static long __video_do_ioctl(struct file *file,
const struct v4l2_ioctl_info *info;
void *fh = file-private_data;
struct v4l2_fh *vfh = NULL;
- int use_fh_prio = 0;
int debug = vfd-debug;
long ret = -ENOTTY;
@@ -2200,10 +2199,8 @@ static long __video_do_ioctl(struct file *file,
return ret;
}
- if (test_bit(V4L2_FL_USES_V4L2_FH, vfd-flags)) {
+ if (test_bit(V4L2_FL_USES_V4L2_FH, vfd-flags))
vfh = file-private_data;
- use_fh_prio = test_bit(V4L2_FL_USE_FH_PRIO, vfd-flags);
- }
if (v4l2_is_known_ioctl(cmd)) {
info = v4l2_ioctls[_IOC_NR(cmd)];
@@ -2212,7 +2209,7 @@ static long __video_do_ioctl(struct file *file,
!((info-flags INFO_FL_CTRL) vfh vfh-ctrl_handler))
goto done;
- if (use_fh_prio (info-flags INFO_FL_PRIO)) {
+ if (vfh (info-flags INFO_FL_PRIO)) {
ret = v4l2_prio_check(vfd-prio, vfh-prio);
if (ret)
goto done;
@@ -2237,7 +2234,7 @@ static long __video_do_ioctl(struct file *file,
ret = -ENOTTY;
} else {
ret = ops-vidioc_default(file, fh,
- use_fh_prio ? v4l2_prio_check(vfd-prio, vfh-prio) =
0 : 0,
+ vfh ? v4l2_prio_check(vfd-prio, vfh-prio) = 0 : 0,
cmd, arg);
}
--
To unsubscribe from this list:
Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)
On Fri, Jun 20, 2014 at 12:39 AM, H. Peter Anvin h...@zytor.com wrote: Aside: This is a pet peeve of mine and recently I've switched to rejecting all patch that have a BUG_ON, period. Please do, I have been for a few years now as well for the same reasons you cite. I'm actually concerned about this trend. Downgrading things to WARN_ON can allow a security bug in the kernel to continue to exist, for example, or make the error message disappear. I am wondering if the right thing here isn't to have a user (command line?) settable policy as to how to proceed on an assert violation, instead of hardcoding it at compile time. I should clarify: If it smells like the issue is a failure of our ioctl/syscall validation code to catch crap, BUG_ON is the right choice. And fundamentally I've had this rule since 1-2 years now, the only recent change I've done is switch my scripts from warning by default if there's a new BUG_ON to rejecting by default. Mostly because I'm lazy and let too many BUG_ONs pass through by default. Also if you add a new interface to i915 I'll make damn sure you supply a full set of nasty testcases to abuse the ioctl hard. In the end it's a tradeoff and overall I don't think I'm compromising security with my current set of rules. Also, people don't (yet) terribly care about data integrity as soon as their data has passed once through a gpu. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)
On Fri, Jun 20, 2014 at 1:42 AM, Greg KH gre...@linuxfoundation.org wrote: I'm actually concerned about this trend. Downgrading things to WARN_ON can allow a security bug in the kernel to continue to exist, for example, or make the error message disappear. A BUG_ON makes any error message disappear pretty quickly :) I'm talking about foolish ASSERT-like BUG_ON that driver authors like to add to their code when writing it to catch things they are messing up. After the code is working, they should be removed, like this one. Well except for cases where it's super performance critical I like to retain these WARN_ON asserts (not BUG_ON). Is the logic sufficient locked down with WARN_ONs? is actually one of the main review criteria I have for i915 patches, especially on the modeset side. They're a bit an annoyance for distro's since they result in a constant (but ever shifting) stream of backtraces, but for me they serve as an excellent early warning sign when our driver has yet again lost its marbles (or at least some) way before something user-visibly bad happens. And for those screaming that these checks should be hidden behind a config option and only enabled for validation: Nope, there's too many combinations of display hardware out there and I simply need our entire user base to serve as guinea pigs. There's really no other way to validate this mess called drm/i915. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: omap3-isp driver in CSI2 mode
Hi Michael, On Tuesday 17 June 2014 16:07:20 Михайло Новотний wrote: Hi Laurent. In my case, I don't receive any interrupts from CSI2 module My post on Ti forum: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/537/p/33699 1/1182836.aspx#1182836 Quoting your post: I find that I used incorrect data in mux init: omap3_mux_init(board_mux, OMAP_PACKAGE_CBB); on my board DM3730CBP100, I changedmux init to omap3_mux_init(board_mux, OMAP_PACKAGE_CBP); Now CSI2 interrupts occur. But now I have another problem. When I start stream, I always recive error: [ 83.435546] omap3isp omap3isp: CSI2: ComplexIO Error IRQ 1 [ 83.491149] omap3isp omap3isp: CSI2: ComplexIO Error IRQ 3 [ 83.544158] omap3isp omap3isp: CSI2: ComplexIO Error IRQ 1 [ 83.600830] omap3isp omap3isp: CSI2: ComplexIO Error IRQ 2 According to the OMAP3 TRM, bits 16 and 17 indicate a control error for lane 2 and 3 respectively. How many lanes does your sensor use, how are they routed, and how have you specified the OMAP3 ISP platform data in your board file ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Adel Group (asia) Ltd, a security equipment manufacturing company is interested in you to be their represent the company as a financial agent, to receive payment from their customers in your region.
Regards, Eric Lawson Human Resource ADEL Group (Asia) LTD -- 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: bttv and colorspace
On Fri, 2014-06-20 at 09:07 +0200, Hans Verkuil wrote: Hi Mauro, I wonder if you remember anything about the reported broken colorspace handling of bttv. The spec talks about V4L2_COLORSPACE_BT878 where the Y range is 16-253 instead of the usual 16-235. I downloaded a bt878 datasheet and that mentions the normal 16-235 range. I wonder if this was perhaps a bug in older revisions of the bt878. Do you remember anything about this? I have a Rockwell datasheet for the BrookTree 878/879 that has the Y 16-253 (16 is the pedestal level) and Cr/Cb 2-253 on page 118. I will email to you off list. Regards, Andy I plan on doing some tests with my bttv cards next week. The main reason I'm interested in this is that I am researching the colorspace handling in v4l2 (and how it is defined in the spec). That needs to be nailed down because today nobody really knows how it is supposed to work and it is a complicated topic. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: pvrusb2 has a new device (wintv-hvr-1955)
On Fri, Jun 20, 2014 at 1:48 AM, Matthew Thode prometheanf...@gentoo.org wrote: Just bought a wintv-hvr-1955 (sold as a wintv-hvr-1950) 160111 LF Rev B1|7 Talk to Hauppauge, they've already announced that they have a working Linux driver. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pvrusb2 has a new device (wintv-hvr-1955)
On June 20, 2014 7:29:42 AM CDT, Steven Toth st...@kernellabs.com wrote: On Fri, Jun 20, 2014 at 1:48 AM, Matthew Thode prometheanf...@gentoo.org wrote: Just bought a wintv-hvr-1955 (sold as a wintv-hvr-1950) 160111 LF Rev B1|7 Talk to Hauppauge, they've already announced that they have a working Linux driver. I talked to them and they did say that the driver hasn't been upstreamed, also gave me some hardware info. They wouldn't give me a driver/firmware that worked though and offered to RMA for an older device. The demodulator is a Si2177, can't find anything about it in the kernel though. They also mentioned a LG3306a, wasn't able to find anything on it (might have misheard a character). -- Matthew Thode (prometheanfire) -- 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: pvrusb2 has a new device (wintv-hvr-1955)
Just bought a wintv-hvr-1955 (sold as a wintv-hvr-1950) 160111 LF Rev B1|7 Talk to Hauppauge, they've already announced that they have a working Linux driver. I talked to them and they did say that the driver hasn't been upstreamed, also gave me some hardware info. They wouldn't give me a driver/firmware that worked though and offered to RMA for an older device. They'd previously announced publicly that the driver was available under NDA for a superset product (HVR-1975): Slashgear picked up the PR. http://www.slashgear.com/hauppauge-wintv-hvr-1975-usb-tv-receiver-offers-multi-format-support-27318809/ There are both 32-bit and 64-bit drivers for wider computer support, and for Linux users, driver support is provided under an NDA. ^^^ I suggest you ask them, they do have a solution. The demodulator is a Si2177, can't find anything about it in the kernel though. Correct. They also mentioned a LG3306a, wasn't able to find anything on it (might have misheard a character). LGDT3306 - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: pvrusb2 has a new device (wintv-hvr-1955)
On June 20, 2014 10:55:47 AM CDT, Steven Toth st...@kernellabs.com wrote: Just bought a wintv-hvr-1955 (sold as a wintv-hvr-1950) 160111 LF Rev B1|7 Talk to Hauppauge, they've already announced that they have a working Linux driver. I talked to them and they did say that the driver hasn't been upstreamed, also gave me some hardware info. They wouldn't give me a driver/firmware that worked though and offered to RMA for an older device. They'd previously announced publicly that the driver was available under NDA for a superset product (HVR-1975): Slashgear picked up the PR. http://www.slashgear.com/hauppauge-wintv-hvr-1975-usb-tv-receiver-offers-multi-format-support-27318809/ There are both 32-bit and 64-bit drivers for wider computer support, and for Linux users, driver support is provided under an NDA. ^^^ I suggest you ask them, they do have a solution. The demodulator is a Si2177, can't find anything about it in the kernel though. Correct. They also mentioned a LG3306a, wasn't able to find anything on it (might have misheard a character). LGDT3306 - Steve Ah, thanks. They didn't mention that an NDA was needed, I'll ask about it. -- Matthew Thode (prometheanfire) -- 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
Santander Finance We offer all purpose loan at 3% interest rate
We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegr...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Time for v4l-utils 1.2 release?
Hello, It's been 11 months since the 1.0.0 release. What do you think about releasing HEAD? Do you have any pending commits? Mauro, you tried to re-license the DVB library. What's the status there? Thanks, Gregor -- 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: Time for v4l-utils 1.2 release?
Em Fri, 20 Jun 2014 22:31:13 +0200 Gregor Jasny gja...@googlemail.com escreveu: Hello, It's been 11 months since the 1.0.0 release. What do you think about releasing HEAD? Do you have any pending commits? Mauro, you tried to re-license the DVB library. What's the status there? Hi Gregor, I was missing one formal ack on that. However, the previous demand of re-licinsing it as LGPL has gone, as gstreamer developers decided to implement DVBv5 there directly. So, I decided to keep it as-is for now, as there's no gain currently on changing the license. From my side, please go ahead and release 1.2 ;) Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REPOST PATCH 4/8] android: convert sync to fence api, v5
On Thu, Jun 19, 2014 at 02:28:14PM +0200, Daniel Vetter wrote: On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding thierry.red...@gmail.com wrote: With these changes, can we pull the android sync logic out of drivers/staging/ now? Afaik the google guys never really looked at this and acked it. So I'm not sure whether they'll follow along. The other issue I have as the maintainer of gfx driver is that I don't want to implement support for two different sync object primitives (once for dma-buf and once for android syncpts), and my impression thus far has been that even with this we're not there. I'm trying to get our own android guys to upstream their i915 syncpts support, but thus far I haven't managed to convince them to throw people's time at this. This has been discussed a fair bit internally recently and some of our GPU experts have raised concerns that this may result in seriously degraded performance in our proprietary graphics stack. Now I don't care very much for the proprietary graphics stack, but by extension I would assume that the same restrictions are relevant for any open-source driver as well. I'm still trying to fully understand all the implications and at the same time get some of the people who raised concerns to join in this discussion. As I understand it the concern is mostly about explicit vs. implicit synchronization and having this mechanism in the kernel will implicitly synchronize all accesses to these buffers even in cases where it's not needed (read vs. write locks, etc.). In one particular instance it was even mentioned that this kind of implicit synchronization can lead to deadlocks in some use-cases (this was mentioned for Android compositing, but I suspect that the same may happen for Wayland or X compositors). Well the implicit fences here actually can't deadlock. That's the entire point behind using ww mutexes. I've also heard tons of complaints about implicit enforced syncing (especially from opencl people), but in the end drivers and always expose unsynchronized access for specific cases. We do that in i915 for upload buffers and other fun stuff. This is about shared stuff across different drivers and different processes. Tegra K1 needs to share buffers across different drivers even for very basic use-cases since the GPU and display drivers are separate. So while I agree that the GPU driver can still use explicit synchronization for internal work, things aren't that simple in general. Let me try to reconstruct the use-case that caused the lock on Android: the compositor uses a hardware overlay to display an image. The system detects that there's little activity and instructs the compositor to put everything into one image and scan out only that (for power efficiency). Now with implicit locking the display driver has a lock on the image, so the GPU (used for compositing) needs to wait for it before it can composite everything into one image. But the display driver cannot release the lock on the image until the final image has been composited and can be displayed instead. This may not be technically a deadlock, but it's still a stalemate. Unless I'm missing something fundamental about DMA fences and ww mutexes I don't see how you can get out of this situation. Explicit vs. implicit synchronization may also become more of an issue as buffers are imported from other sources (such as cameras). Finally I've never seen anyone from google or any android product guy push a real driver enabling for syncpts to upstream, and google itself has a bit a history of constantly exchanging their gfx framework for the next best thing. So I really doubt this is worthwhile to pursue in upstream with our essentially eternal api guarantees. At least until we see serious uptake from vendors and gfx driver guys. Unfortunately the Intel android folks are no exception here and haven't pushed anything like this in my direction yet at all. Despite multiple pokes from my side. So from my side I think we should move ahead with Maarten's work and figure the android side out once there's real interest. The downside of that is that we may end up with two different ways to synchronize buffers if it turns out that we can't make Android (or other use-cases) work with DMA fence. However I don't think that justifies postponing this patch set indefinitely. Thierry pgp0OB8pDlJzP.pgp Description: PGP signature
Re: Time for v4l-utils 1.2 release?
On 06/20/2014 10:31 PM, Gregor Jasny wrote: Hello, It's been 11 months since the 1.0.0 release. What do you think about releasing HEAD? Do you have any pending commits? I've got two patches from Laurent pending that ensure that the 'installed kernel headers' are used. I plan on processing those on Monday. After that I think it's OK to do a release. Mauro, did you look at my email where I suggest to remove three apps from contrib? If you agree with that, then I can do that Monday as well. Regards, Hans Mauro, you tried to re-license the DVB library. What's the status there? Thanks, Gregor -- 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: Time for v4l-utils 1.2 release?
Em Sat, 21 Jun 2014 00:07:19 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 06/20/2014 10:31 PM, Gregor Jasny wrote: Hello, It's been 11 months since the 1.0.0 release. What do you think about releasing HEAD? Do you have any pending commits? I've got two patches from Laurent pending that ensure that the 'installed kernel headers' are used. I plan on processing those on Monday. After that I think it's OK to do a release. Mauro, did you look at my email where I suggest to remove three apps from contrib? If you agree with that, then I can do that Monday as well. Well, I don't remember about such email, nor I was able to find on a quick look. What apps are you planning to remove? Btw, I think it could be a good idea to be able to install some of those stuff under contrib to a separate package. I had to do a quick hack in order to install v4l2grab on a Tizen package, in order to be able to test a card there (as was needing to do some tests via CLI). 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
Best way to add subdev that doesn't use I2C or SPI?
Hello, I'm in the process of adding support for a new video decoder. However in this case it's an IP block on a USB bridge as opposed to the typical case which is an I2C device. Changing registers for the subdev is the same mechanism as changing registers in the rest of the bridge (a specific region of registers is allocated for the video decoder). Doing a subdev driver seems like the logical approach to keep the video decoder related routines separate from the rest of the bridge. It also allows the reuse of the code if we find other cases where the IP block is present in other devices. However I'm not really sure what the mechanics are for creating a subdev that isn't really an I2C device. I think we've had similar cases with the Conexant parts where the Mako was actually a block on the main bridge (i.e. cx23885/7/8, cx231xx). But in that case the cx25840 subdev just issues I2C commands and leverages the fact that you can talk to the parts over I2C even though they're really on-chip. Are there any other cases today where we have a subdev that uses traditional register access routines provided by the bridge driver to read/write the video decoder registers? In this case I would want to reuse the register read/write routines provided by the bridge, which ultimately are send as USB control messages. Any suggestions welcome (and in particular if you can point me to an example case where this is already being done). Thanks in advance, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
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: Sat Jun 21 04:00:41 CEST 2014 git branch: test git hash: 1fe3a8fe494463cfe2556a25ae41a1499725c178 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-14-gf11dd94 host hardware: x86_64 host os:3.14-5.slh.5-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: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-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: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-i686: OK linux-3.16-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-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: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-x86_64: OK linux-3.16-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: Best way to add subdev that doesn't use I2C or SPI?
Moikka Devin On 06/21/2014 04:58 AM, Devin Heitmueller wrote: Hello, I'm in the process of adding support for a new video decoder. However in this case it's an IP block on a USB bridge as opposed to the typical case which is an I2C device. Changing registers for the subdev is the same mechanism as changing registers in the rest of the bridge (a specific region of registers is allocated for the video decoder). Doing a subdev driver seems like the logical approach to keep the video decoder related routines separate from the rest of the bridge. It also allows the reuse of the code if we find other cases where the IP block is present in other devices. However I'm not really sure what the mechanics are for creating a subdev that isn't really an I2C device. I think we've had similar cases with the Conexant parts where the Mako was actually a block on the main bridge (i.e. cx23885/7/8, cx231xx). But in that case the cx25840 subdev just issues I2C commands and leverages the fact that you can talk to the parts over I2C even though they're really on-chip. Are there any other cases today where we have a subdev that uses traditional register access routines provided by the bridge driver to read/write the video decoder registers? In this case I would want to reuse the register read/write routines provided by the bridge, which ultimately are send as USB control messages. Any suggestions welcome (and in particular if you can point me to an example case where this is already being done). Thanks in advance, Devin Abuse I2C bus. If your integrated IP block is later sold as a separate chip, there is likely I2C bus used then. If you now abuse I2C it could be even possible that no changes at all is then needed or only small fixes. I have done that few times, not for V4L2 sub-device, but on DVB side. For example AF9015/AF9013 and AF9035/AF9033/IT913x. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Santander Finance We offer all purpose loan at 3% interest rate
We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegr...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
