[GIT PULL FOR v3.18] cx23885: convert to the latest frameworks, including vb2
Hi Mauro, This pull request converts the cx23885 driver to the latest V4L2 core frameworks, removing about 1000 lines in the process. It now passes the v4l2-compliance tests and, frankly, feels much more robust. I have tested this with my HVR-1800 board with video (compressed and uncompressed), vbi, dvb and alsa, including several duration stress tests. As usual, the vb2 conversion is a beast of a patch. But the vb2 conversion affected video, vbi, dvb and alsa, so it's all over the place. And it is all or nothing. See the commit log of that patch for some more information. It also changed the risc code to simplify the code and to get rid of all the timeouts that were copied-and-pasted from cx88. If anyone knows of a reason for these timeouts, please let me know. I have tried to separate the risc code changes from the vb2 changes, but that was impossible to get to work with vb1. I dropped the vb2 fix I included in my earlier pull request since that fix will appear in v3.17 (i.e. before this driver is upstreamed) anyway. Regards, Hans The following changes since commit b250392f7b5062cf026b1423e27265e278fd6b30: [media] media: ttpci: fix av7110 build to be compatible with CONFIG_INPUT_EVDEV (2014-08-21 15:25:38 -0500) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git cx23b for you to fetch changes up to 7552750cc31d5925b9d44eb2a5c98504fa64c38b: cx23885: Add busy checks before changing formats (2014-08-29 08:31:53 +0200) Hans Verkuil (20): cx23885: fix querycap cx23885: fix audio input handling cx23885: support v4l2_fh and g/s_priority cx23885: use core locking, switch to unlocked_ioctl. cx23885: convert to the control framework cx23885: convert 417 to the control framework cx23885: fix format colorspace compliance error cx23885: map invalid fields to a valid field. cx23885: drop radio-related dead code cx23885: drop type field from struct cx23885_fh cx23885: drop unused clip fields from struct cx23885_fh cx23885: fmt, width and height are global, not per-fh. cx23885: drop videobuf abuse in cx23885-alsa cx23885: use video_drvdata to get cx23885_dev pointer cx23885: convert to vb2 cx23885: fix field handling cx23885: fix weird sizes. cx23885: remove FSF address as per checkpatch cx23885: remove btcx-risc dependency cx23885: Add busy checks before changing formats drivers/media/pci/cx23885/Kconfig |5 +- drivers/media/pci/cx23885/Makefile|1 - drivers/media/pci/cx23885/altera-ci.c |8 +- drivers/media/pci/cx23885/altera-ci.h |4 - drivers/media/pci/cx23885/cimax2.c|4 - drivers/media/pci/cx23885/cimax2.h|4 - drivers/media/pci/cx23885/cx23885-417.c | 501 ++- drivers/media/pci/cx23885/cx23885-alsa.c | 109 +-- drivers/media/pci/cx23885/cx23885-av.c|5 - drivers/media/pci/cx23885/cx23885-av.h|5 - drivers/media/pci/cx23885/cx23885-cards.c |6 - drivers/media/pci/cx23885/cx23885-core.c | 362 --- drivers/media/pci/cx23885/cx23885-dvb.c | 136 ++--- drivers/media/pci/cx23885/cx23885-f300.c |4 - drivers/media/pci/cx23885/cx23885-i2c.c | 12 - drivers/media/pci/cx23885/cx23885-input.c |5 - drivers/media/pci/cx23885/cx23885-input.h |5 - drivers/media/pci/cx23885/cx23885-ioctl.c | 10 +- drivers/media/pci/cx23885/cx23885-ioctl.h |4 - drivers/media/pci/cx23885/cx23885-ir.c|5 - drivers/media/pci/cx23885/cx23885-ir.h|5 - drivers/media/pci/cx23885/cx23885-reg.h |4 - drivers/media/pci/cx23885/cx23885-vbi.c | 282 -- drivers/media/pci/cx23885/cx23885-video.c | 1294 + drivers/media/pci/cx23885/cx23885-video.h |5 - drivers/media/pci/cx23885/cx23885.h | 127 +++- drivers/media/pci/cx23885/cx23888-ir.c|5 - drivers/media/pci/cx23885/cx23888-ir.h|5 - drivers/media/pci/cx23885/netup-eeprom.c |4 - drivers/media/pci/cx23885/netup-eeprom.h |4 - drivers/media/pci/cx23885/netup-init.c|4 - drivers/media/pci/cx23885/netup-init.h|4 - 32 files changed, 951 insertions(+), 1987 deletions(-) -- 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
[GIT PULL FOR v3.18] Add vivid test driver, remove old vivi test driver
Hi Mauro, This adds the new vivid driver as a replacement for the old vivi. This pull request is identical to the v2 patch series posted earlier: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/81354 except for the final patch that removes the vivi driver which is new to this pull request. One question: the vivid driver (like the vivi driver) is not build by default. Should that be changed? In my opinion this driver should be enabled by distros, so I am in favor of changing Kconfig. Let me know if you agree and I'll make a follow up patch or you can change this yourself. Regards, Hans The following changes since commit b250392f7b5062cf026b1423e27265e278fd6b30: [media] media: ttpci: fix av7110 build to be compatible with CONFIG_INPUT_EVDEV (2014-08-21 15:25:38 -0500) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git vivid2 for you to fetch changes up to d5f410f54e87ba420de839dec4e806707cc2aff2: vivi: remove driver, it's replaced by vivid. (2014-08-25 13:49:53 +0200) Hans Verkuil (13): vb2: fix multiplanar read() with non-zero data_offset vivid.txt: add documentation for the vivid driver vivid: add core driver code vivid: add the control handling code vivid: add the video capture and output parts vivid: add VBI capture and output code vivid: add the kthread code that controls the video rate vivid: add a simple framebuffer device for overlay testing vivid: add the Test Pattern Generator vivid: add support for radio receivers and transmitters vivid: add support for software defined radio vivid: enable the vivid driver vivi: remove driver, it's replaced by vivid. Documentation/video4linux/vivid.txt | 1109 +++ drivers/media/platform/Kconfig| 15 +- drivers/media/platform/Makefile |2 +- drivers/media/platform/vivi.c | 1542 - drivers/media/platform/vivid/Kconfig | 19 + drivers/media/platform/vivid/Makefile |6 + drivers/media/platform/vivid/vivid-core.c | 1390 ++ drivers/media/platform/vivid/vivid-core.h | 520 ++ drivers/media/platform/vivid/vivid-ctrls.c| 1502 +++ drivers/media/platform/vivid/vivid-ctrls.h| 34 ++ drivers/media/platform/vivid/vivid-kthread-cap.c | 885 + drivers/media/platform/vivid/vivid-kthread-cap.h | 26 ++ drivers/media/platform/vivid/vivid-kthread-out.c | 304 + drivers/media/platform/vivid/vivid-kthread-out.h | 26 ++ drivers/media/platform/vivid/vivid-osd.c | 400 + drivers/media/platform/vivid/vivid-osd.h | 27 ++ drivers/media/platform/vivid/vivid-radio-common.c | 189 drivers/media/platform/vivid/vivid-radio-common.h | 40 ++ drivers/media/platform/vivid/vivid-radio-rx.c | 287 drivers/media/platform/vivid/vivid-radio-rx.h | 31 ++ drivers/media/platform/vivid/vivid-radio-tx.c | 141 ++ drivers/media/platform/vivid/vivid-radio-tx.h | 29 ++ drivers/media/platform/vivid/vivid-rds-gen.c | 165 +++ drivers/media/platform/vivid/vivid-rds-gen.h | 53 +++ drivers/media/platform/vivid/vivid-sdr-cap.c | 499 + drivers/media/platform/vivid/vivid-sdr-cap.h | 34 ++ drivers/media/platform/vivid/vivid-tpg-colors.c | 310 + drivers/media/platform/vivid/vivid-tpg-colors.h | 64 +++ drivers/media/platform/vivid/vivid-tpg.c | 1439 drivers/media/platform/vivid/vivid-tpg.h | 438 +++ drivers/media/platform/vivid/vivid-vbi-cap.c | 356 +++ drivers/media/platform/vivid/vivid-vbi-cap.h | 40 ++ drivers/media/platform/vivid/vivid-vbi-gen.c | 248 +++ drivers/media/platform/vivid/vivid-vbi-gen.h | 33 ++ drivers/media/platform/vivid/vivid-vbi-out.c | 247 +++ drivers/media/platform/vivid/vivid-vbi-out.h | 34 ++ drivers/media/platform/vivid/vivid-vid-cap.c | 1729 + drivers/media/platform/vivid/vivid-vid-cap.h | 71 +++ drivers/media/platform/vivid/vivid-vid-common.c | 571 drivers/media/platform/vivid/vivid-vid-common.h | 61 +++ drivers/media/platform/vivid/vivid-vid-out.c | 1205 +++ drivers/media/platform/vivid/vivid-vid-out.h | 57 +++
[GIT PULL FOR v3.18] Add driver for tw68xx PCI grabber boards
This adds the tw68 PCI driver. These two patches are identical to the v3 patch series I posted earlier: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/81407 Regards, Hans The following changes since commit b250392f7b5062cf026b1423e27265e278fd6b30: [media] media: ttpci: fix av7110 build to be compatible with CONFIG_INPUT_EVDEV (2014-08-21 15:25:38 -0500) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git tw68 for you to fetch changes up to f9c0c8edba28682cd6ab7254f2da911272053989: MAINTAINERS: add tw68 entry (2014-08-26 08:26:39 +0200) Hans Verkuil (2): tw68: add support for Techwell tw68xx PCI grabber boards MAINTAINERS: add tw68 entry MAINTAINERS |8 + drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile |1 + drivers/media/pci/tw68/Kconfig | 10 + drivers/media/pci/tw68/Makefile |3 + drivers/media/pci/tw68/tw68-core.c | 434 drivers/media/pci/tw68/tw68-reg.h | 195 drivers/media/pci/tw68/tw68-risc.c | 230 +++ drivers/media/pci/tw68/tw68-video.c | 1060 +++ drivers/media/pci/tw68/tw68.h | 231 +++ 10 files changed, 2173 insertions(+) create mode 100644 drivers/media/pci/tw68/Kconfig create mode 100644 drivers/media/pci/tw68/Makefile create mode 100644 drivers/media/pci/tw68/tw68-core.c create mode 100644 drivers/media/pci/tw68/tw68-reg.h create mode 100644 drivers/media/pci/tw68/tw68-risc.c create mode 100644 drivers/media/pci/tw68/tw68-video.c create mode 100644 drivers/media/pci/tw68/tw68.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] v4l: ti-vpe: Remove casting the return value which is a void pointer
Casting the return value which is a void pointer is redundant.
The conversion from void pointer to any other pointer type is
guaranteed by the C programming language.
Signed-off-by: Jingoo Han
---
drivers/media/platform/ti-vpe/vpe.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 972f43f69206..aa7f96852a8c 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -2343,8 +2343,7 @@ v4l2_dev_unreg:
static int vpe_remove(struct platform_device *pdev)
{
- struct vpe_dev *dev =
- (struct vpe_dev *) platform_get_drvdata(pdev);
+ struct vpe_dev *dev = platform_get_drvdata(pdev);
v4l2_info(&dev->v4l2_dev, "Removing " VPE_MODULE_NAME);
--
2.0.0
--
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 2/3] rc: Introduce hix5hd2 IR transmitter driver
On 08/28/2014 08:46 PM, Zhangfei Gao wrote:
From: Guoxiong Yan
IR transmitter driver for Hisilicon hix5hd2 soc
By default all protocols are disabled.
For example nec decoder can be enabled by either
1. ir-keytable -p nec
2. echo nec > /sys/class/rc/rc0/protocols
See see Documentation/ABI/testing/sysfs-class-rc
(...)
+static irqreturn_t hix5hd2_ir_rx_interrupt(int irq, void *data)
+{
+ u32 symb_num, symb_val, symb_time;
+ u32 data_l, data_h;
+ u32 irq_sr, i;
+ struct hix5hd2_ir_priv *priv = data;
+
+ irq_sr = readl_relaxed(priv->base + IR_INTS);
+ if (irq_sr & INTMS_OVERFLOW) {
+ /*
+* we must read IR_DATAL first, then we can clean up
+* IR_INTS availably since logic would not clear
+* fifo when overflow, drv do the job
+*/
+ ir_raw_event_reset(priv->rdev);
+ symb_num = readl_relaxed(priv->base + IR_DATAH);
+ for (i = 0; i < symb_num; i++)
+ readl_relaxed(priv->base + IR_DATAL);
+
+ writel_relaxed(INT_CLR_OVERFLOW, priv->base + IR_INTC);
+ dev_info(priv->dev, "overflow, level=%d\n",
+IR_CFG_INT_THRESHOLD);
+ }
+
+ if ((irq_sr & INTMS_SYMBRCV) || (irq_sr & INTMS_TIMEOUT)) {
+ DEFINE_IR_RAW_EVENT(ev);
+
+ symb_num = readl_relaxed(priv->base + IR_DATAH);
+ for (i = 0; i < symb_num; i++) {
+ symb_val = readl_relaxed(priv->base + IR_DATAL);
+ data_l = ((symb_val & 0x) * 10);
+ data_h = ((symb_val >> 16) & 0x) * 10;
+ symb_time = (data_l + data_h) / 10;
+
+ ev.duration = US_TO_NS(data_l);
+ ev.pulse = true;
+ ir_raw_event_store(priv->rdev, &ev);
+
+ if (symb_time < IR_CFG_SYMBOL_MAXWIDTH) {
+ ev.duration = US_TO_NS(data_h);
+ ev.pulse = false;
+ ir_raw_event_store(priv->rdev, &ev);
+ } else {
+ hix5hd2_ir_send_lirc_timeout(priv->rdev);
+ }
+ }
+
+ if (irq_sr & INTMS_SYMBRCV)
+ writel_relaxed(INT_CLR_RCV, priv->base + IR_INTC);
+ if (irq_sr & INTMS_TIMEOUT)
+ writel_relaxed(INT_CLR_TIMEOUT, priv->base + IR_INTC);
+ }
+
+ /* Empty software fifo */
+ ir_raw_event_handle(priv->rdev);
+ return IRQ_HANDLED;
+}
+
It looks good if the entire ISR() above the probe()/remove() functionalities
of the driver. Maximum of the developers follows this structure.
(...)
+static struct of_device_id hix5hd2_ir_table[] = {
+ { .compatible = "hisilicon,hix5hd2-ir", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hix5hd2_ir_table);
+
Every driver put these device ids above *struct platform_driver* definition.
So that we can see the of_match_table
+static int hix5hd2_ir_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct rc_dev *rdev;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct hix5hd2_ir_priv *priv;
+ struct device_node *node = pdev->dev.of_node;
+
+ priv = devm_kzalloc(dev, sizeof(struct hix5hd2_ir_priv), GFP_KERNEL);
sizeof(*priv)...?
+ if (!priv)
+ return -ENOMEM;
+
(...)
+#endif
+
+static SIMPLE_DEV_PM_OPS(hix5hd2_ir_pm_ops, hix5hd2_ir_suspend,
+hix5hd2_ir_resume);
+
We can move the device ids here
+static struct platform_driver hix5hd2_ir_driver = {
+ .driver = {
+ .name = IR_HIX5HD2_NAME,
+ .of_match_table = hix5hd2_ir_table,
+ .pm = &hix5hd2_ir_pm_ops,
+ },
+ .probe = hix5hd2_ir_probe,
+ .remove = hix5hd2_ir_remove,
+};
+
+module_platform_driver(hix5hd2_ir_driver);
+
+MODULE_DESCRIPTION("RC Transceiver driver for hix5hd2 platforms");
+MODULE_AUTHOR("Guoxiong Yan ");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:hix5hd2-ir");
--
Regards,
Varka Bhadram.
--
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/3] rc: Add DT bindings for hix5hd2
On 08/28/2014 08:46 PM, Zhangfei Gao wrote:
From: Guoxiong Yan
Signed-off-by: Guoxiong Yan
Signed-off-by: Zhangfei Gao
---
.../devicetree/bindings/media/hix5hd2-ir.txt | 25
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
new file mode 100644
index 000..2bd88b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -0,0 +1,25 @@
+Device-Tree bindings for hix5hd2 ir IP
+
+Required properties:
+- compatible: Should contain "hisilicon,hix5hd2-ir".
+- reg: Base physical address of the controller and length of memory
+ mapped region.
+- interrupts: interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the interrupt
+ controller parent.
+- clocks: clock phandle and specifier pair.
+- hisilicon,power-syscon: phandle of syscon used to control power.
+
It would be readable if
Required properties:
- compatible: Should contain "hisilicon,hix5hd2-ir".
- reg : Base physical address of the controller and length of
memory mapped region.
- interrupts: interrupt-specifier for the sole interrupt generated
by
the device. The interrupt specifier format depends on
the interrupt
controller parent.
...
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example node:
+
+ ir: ir@f8001000 {
+ compatible = "hisilicon,hix5hd2-ir";
+ reg = <0xf8001000 0x1000>;
+ interrupts = <0 47 4>;
+ clocks = <&clock HIX5HD2_FIXED_24M>;
+ hisilicon,power-syscon = <&sysctrl>;
+ linux,rc-map-name = "rc-tivo";
+ };
--
Regards,
Varka Bhadram.
--
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 Aug 29 04:00:15 CEST 2014 git branch: test git hash: b250392f7b5062cf026b1423e27265e278fd6b30 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.16-1.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.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.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-rc1-i686: 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.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS 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: Advice on DVB-S/S2 card and CAM support
On 08/28/2014 05:44 PM, Kaya Saman wrote: In my research I got suggested the Digital Devices line of products: http://www.digitaldevices.de/ They are German so hopefully the quality will be extremely good and they all seem natively supported. Not natively supported. In my understanding ddbridge DVB-S/S2 is supported, but CAM/CI has some problems as it is implemented differently than kernel. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
moikka! On 08/28/2014 12:07 PM, Akihiro TSUKADA wrote: moikka, thanks for the comment. I have feeling DVBv5 API is aimed to transfer data via property cached. I haven't done much driver for DVBv5 statistics, but recently I implemented CNR (DVBv5 stats) to Si2168 driver and it just writes all the values directly to property cache. I expect RF strength (RSSI) is just similar. Currently, the demod of PT3 card (tc90522) gets RSSI data from the connected tuner (mxl301rf) via tuner_ops.get_signal_strength_dbm() and sets property cache in fe->ops.get_frontend() (which is called before returning property cache value by dvb_frontend_ioctl_properties()). If the tuner driver should set property cache directly, when is the right timing to do so? In fe->ops.tuner_ops.get_status() ? or in the old fe->ops.tuner_ops.get_signal_strength()? or Should I change get_signal_strength_dbm(fe, s64 *) to update_signal_strength(fe) and let the tuner driver set property cache there? I think tuner driver should set c->strength as own. Look drivers/media/dvb-core/dvb_frontend.c /* Fill quality measures */ case DTV_STAT_SIGNAL_STRENGTH: tvp->u.st = c->strength; break; So user-space just get info what is set to struct dtv_frontend_properties. That is similarly than CNR and all the other statistics. Start polling thread, which polls once per 2 sec or so, which reads RSSI and writes value to struct dtv_frontend_properties. That it is, in my understanding. Same for all those DVBv5 stats. Mauro knows better as he designed that functionality. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of g_webcam uvc-gadget
Hi Ricardo, On Wednesday 27 August 2014 18:09:13 Ricardo Ribalda Delgado wrote: > Hello > > Is somebody using/supporting g_webcam? I believe so, as I get kernel patches from time to time. > The only reference userland server is uvc-gadget from > http://git.ideasonboard.org/?p=uvc-gadget.git;a=summary ? That's the only public userspace implementation I know of. And I should be blamed for not having taken the time to properly review and apply Bhupesh's patches :-/ > I have an industrial fpga camera that speaks v4l2, my plan is to > export it as an uvc camera via usb3380 as a debug interface. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/video4linux: don't build without CONFIG_VIDEO_V4L2
2014-08-29 0:42 GMT+04:00 Randy Dunlap :
> On 08/28/14 13:34, Andrey Vagin wrote:
>> Otherwise we get warnings:
>> WARNING: "vb2_ops_wait_finish"
>> [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
>> WARNING: "vb2_ops_wait_prepare"
>> [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
>> ...
>> WARNING: "video_unregister_device"
>> [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
>>
>> Fixes: 8db5ab4b50fb ("Documentation: add makefiles for more targets")
>>
>> Cc: Peter Foley
>> Cc: Mauro Carvalho Chehab
>> Cc: Randy Dunlap
>> Signed-off-by: Andrey Vagin
>> ---
>> Documentation/video4linux/Makefile | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/video4linux/Makefile
>> b/Documentation/video4linux/Makefile
>> index d58101e..f19f38e 100644
>> --- a/Documentation/video4linux/Makefile
>> +++ b/Documentation/video4linux/Makefile
>> @@ -1 +1,3 @@
>> +ifneq ($(CONFIG_VIDEO_V4L2),)
>> obj-m := v4l2-pci-skeleton.o
>> +endif
>>
>
> The Kconfig file for this module says:
>
> config VIDEO_PCI_SKELETON
> tristate "Skeleton PCI V4L2 driver"
> depends on PCI && BUILD_DOCSRC
> depends on VIDEO_V4L2 && VIDEOBUF2_CORE && VIDEOBUF2_MEMOPS
>
> so it should already be limited to VIDEO_V4L2 being enabled.
>
> What kernel or linux-next version did you see a problem with?
Eh, I'm late. It was fixed already
commit 81820f32ffaf393d9379c326d670257c63306a26
Author: Mark Brown
Date: Wed Aug 27 10:18:51 2014 +1000
v4l2-pci-skeleton: Only build if PCI is available
Sorry for the noise.
>
> Please send the failing .config file so that I can check it.
>
> Thanks.
>
> --
> ~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
Re: [PATCH] Documentation/video4linux: don't build without CONFIG_VIDEO_V4L2
On 08/28/14 13:34, Andrey Vagin wrote:
> Otherwise we get warnings:
> WARNING: "vb2_ops_wait_finish"
> [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
> WARNING: "vb2_ops_wait_prepare"
> [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
> ...
> WARNING: "video_unregister_device"
> [Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
>
> Fixes: 8db5ab4b50fb ("Documentation: add makefiles for more targets")
>
> Cc: Peter Foley
> Cc: Mauro Carvalho Chehab
> Cc: Randy Dunlap
> Signed-off-by: Andrey Vagin
> ---
> Documentation/video4linux/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/video4linux/Makefile
> b/Documentation/video4linux/Makefile
> index d58101e..f19f38e 100644
> --- a/Documentation/video4linux/Makefile
> +++ b/Documentation/video4linux/Makefile
> @@ -1 +1,3 @@
> +ifneq ($(CONFIG_VIDEO_V4L2),)
> obj-m := v4l2-pci-skeleton.o
> +endif
>
The Kconfig file for this module says:
config VIDEO_PCI_SKELETON
tristate "Skeleton PCI V4L2 driver"
depends on PCI && BUILD_DOCSRC
depends on VIDEO_V4L2 && VIDEOBUF2_CORE && VIDEOBUF2_MEMOPS
so it should already be limited to VIDEO_V4L2 being enabled.
What kernel or linux-next version did you see a problem with?
Please send the failing .config file so that I can check it.
Thanks.
--
~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
[PATCH] Documentation/video4linux: don't build without CONFIG_VIDEO_V4L2
Otherwise we get warnings:
WARNING: "vb2_ops_wait_finish"
[Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
WARNING: "vb2_ops_wait_prepare"
[Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
...
WARNING: "video_unregister_device"
[Documentation//video4linux/v4l2-pci-skeleton.ko] undefined!
Fixes: 8db5ab4b50fb ("Documentation: add makefiles for more targets")
Cc: Peter Foley
Cc: Mauro Carvalho Chehab
Cc: Randy Dunlap
Signed-off-by: Andrey Vagin
---
Documentation/video4linux/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/video4linux/Makefile
b/Documentation/video4linux/Makefile
index d58101e..f19f38e 100644
--- a/Documentation/video4linux/Makefile
+++ b/Documentation/video4linux/Makefile
@@ -1 +1,3 @@
+ifneq ($(CONFIG_VIDEO_V4L2),)
obj-m := v4l2-pci-skeleton.o
+endif
--
1.9.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
Hauppauge WinTV-HVR 1900 high BER and unable to switch to Composite input
Hi, [p.s. sorry if this appears twice, I tried attaching the log output files but not sure if the list software allows that, so have added to Dropbox instead] checking the wiki the WinTV HVR-1900 is suggested as supported: http://www.linuxtv.org/wiki/index.php/Pvrusb2 http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1950 http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1900 I am running Arch Linux with Kernel 3.16.1-6 and all other libraries and packages up to date as of writing this posting. For some reason I am experiencing a quite high BER on the DVB-T tuner side and also I'm unable to switch to the "composite" input for most of the time. On some rare occasions the RCA input works but very rarely. I have read a similar posting to my issues: http://www.isely.net/pipermail/pvrusb2/2009-October/002646.html The kernel and daemon output logs are attached. [EDIT] https://www.dropbox.com/sh/z3h7b1kctma9kh4/AAB_n_bi4EP1v86M0546-7Vka?dl=0 Having attempted to test out MythTV and TVHeadend, both work fine with the DVB-T portion but have issues switching to the analog inputs. TVH in particular keeps claiming "no MPEG encoder found", when the card does have an MPEG2 encoder. MythTV says either "permission denied" or "unable to connect"? Running cat /dev/video0 > outputfile.avi does work however, the output is just a black screen with a colored line bar flickering at the bottom of the video space? All suggested firmware files have been installed and loaded though the logs suggest something wrong with the pvrusb2 driver? Would anybody be able to help? Thanks. Kaya -- 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: randconfig build error with next-20140828, in drivers/media/radio/radio-miropcm20.c
On Thu, Aug 28, 2014 at 09:17:14AM -0700, Jim Davis wrote: > Building with the attached random configuration file, > > CC [M] drivers/media/radio/radio-miropcm20.o > drivers/media/radio/radio-miropcm20.c: In function ‘rds_waitread’: > drivers/media/radio/radio-miropcm20.c:90:3: error: implicit > declaration of function ‘inb’ [-Werror=implicit-function-declaration] >byte = inb(aci->aci_port + ACI_REG_RDS); >^ > drivers/media/radio/radio-miropcm20.c: In function ‘rds_rawwrite’: > drivers/media/radio/radio-miropcm20.c:106:3: error: implicit > declaration of function ‘outb’ [-Werror=implicit-function-declaration] >outb(byte, aci->aci_port + ACI_REG_RDS); >^ > cc1: some warnings being treated as errors > make[3]: *** [drivers/media/radio/radio-miropcm20.o] Error 1 > make[2]: *** [drivers/media/radio] Error 2 > make[1]: *** [drivers/media] Error 2 Hi, Can you please try the attached patch , for me it solved the error/ thanks sudip diff --git a/drivers/media/radio/radio-miropcm20.c b/drivers/media/radio/radio-miropcm20.c index 998919e..3309f7c 100644 --- a/drivers/media/radio/radio-miropcm20.c +++ b/drivers/media/radio/radio-miropcm20.c @@ -36,6 +36,7 @@ #include #include #include +#include #define RDS_DATASHIFT 2 /* Bit 2 */ #define RDS_DATAMASK(1 << RDS_DATASHIFT)
Re: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
On 08/28/2014 07:32 PM, Hans Verkuil wrote:
> On 08/28/2014 07:18 PM, Mauro Carvalho Chehab wrote:
>> Em Thu, 28 Aug 2014 18:40:53 +0200
>> Hans Verkuil escreveu:
>>
>>> On 08/28/2014 06:25 PM, Laurent Pinchart wrote:
Hi Philipp,
On Thursday 28 August 2014 18:09:35 Philipp Zabel wrote:
> Am Donnerstag, den 28.08.2014, 14:24 +0200 schrieb Laurent Pinchart:
>>> A driver could then do the following:
>>>
>>> static struct v4l2_pixfmt_info driver_formats[] = {
>>>
>>> { .pixelformat = V4L2_PIX_FMT_YUYV },
>>> { .pixelformat = V4L2_PIX_FMT_YUV420 },
>>>
>>> };
>>>
>>> int driver_probe(...)
>>> {
>>>
>>> ...
>>> v4l2_init_pixfmt_array(driver_formats,
>>>
>>> ARRAY_SIZE(driver_formats));
>>>
>>> ...
>>>
>>> }
>>
>> Good question. This option consumes more memory, and prevents the driver-
>> specific format info arrays to be const, which bothers me a bit.
>
> Also, this wouldn't help drivers that don't want to take these
> additional steps, which probably includes a lot of camera drivers with
> only a few formats.
>
>> On the other hand it allows drivers to override some of the default
>> values for odd cases.
>
> Hm, but those cases don't have to use the v4l2_pixfmt_info at all.
>
>> I won't nack this approach, but I'm wondering whether a better
>> solution wouldn't be possible. Hans, Mauro, Guennadi, any opinion ?
>
> We could keep the global v4l2_pixfmt_info array sorted by fourcc value
> and do a binary search (would have to be kept in mind when adding new
> formats)
I like that option, provided we can ensure that the array is sorted. This
can
get a bit tricky, and Hans might wear his "don't over-optimize" hat :-)
>>
>> The big issue is that, afaikt, there's no way to make gcc to order it,
>> so the order would need to be manually ensured. This is challenging, and
>> makes the review process complex if done right.
>>
>> I really don't see any gain on applying such patch. If the concern is
>> just about properly naming the pixel formats, it is a way easier to use
>> some defines for the names, and use the defines.
>
> It's not just the names, also the bit depth etc. Most drivers need that
> information
> and having it in a central place simplifies driver design. Yes, it slightly
> increases the amount of memory, but that is insignificant compared to the huge
> amount of memory necessary for video buffers. And reducing driver complexity
> is
> always good since that has always been the main problem with drivers, not
> memory
> or code performance.
I just want to add that we should try out any core solution with an existing
driver
(e.g. saa7134) to see if whatever solution we come up with actually makes
drivers
less complex. The saa7134 is from what I've seen fairly representative of most
in
that is has additional fields besides the name, fourcc and depth that are driver
specific. So how will that be handled...
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: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
On 08/28/2014 07:18 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 28 Aug 2014 18:40:53 +0200
> Hans Verkuil escreveu:
>
>> On 08/28/2014 06:25 PM, Laurent Pinchart wrote:
>>> Hi Philipp,
>>>
>>> On Thursday 28 August 2014 18:09:35 Philipp Zabel wrote:
Am Donnerstag, den 28.08.2014, 14:24 +0200 schrieb Laurent Pinchart:
>> A driver could then do the following:
>>
>> static struct v4l2_pixfmt_info driver_formats[] = {
>>
>> { .pixelformat = V4L2_PIX_FMT_YUYV },
>> { .pixelformat = V4L2_PIX_FMT_YUV420 },
>>
>> };
>>
>> int driver_probe(...)
>> {
>>
>> ...
>> v4l2_init_pixfmt_array(driver_formats,
>>
>> ARRAY_SIZE(driver_formats));
>>
>> ...
>>
>> }
>
> Good question. This option consumes more memory, and prevents the driver-
> specific format info arrays to be const, which bothers me a bit.
Also, this wouldn't help drivers that don't want to take these
additional steps, which probably includes a lot of camera drivers with
only a few formats.
> On the other hand it allows drivers to override some of the default
> values for odd cases.
Hm, but those cases don't have to use the v4l2_pixfmt_info at all.
> I won't nack this approach, but I'm wondering whether a better
> solution wouldn't be possible. Hans, Mauro, Guennadi, any opinion ?
We could keep the global v4l2_pixfmt_info array sorted by fourcc value
and do a binary search (would have to be kept in mind when adding new
formats)
>>>
>>> I like that option, provided we can ensure that the array is sorted. This
>>> can
>>> get a bit tricky, and Hans might wear his "don't over-optimize" hat :-)
>
> The big issue is that, afaikt, there's no way to make gcc to order it,
> so the order would need to be manually ensured. This is challenging, and
> makes the review process complex if done right.
>
> I really don't see any gain on applying such patch. If the concern is
> just about properly naming the pixel formats, it is a way easier to use
> some defines for the names, and use the defines.
It's not just the names, also the bit depth etc. Most drivers need that
information
and having it in a central place simplifies driver design. Yes, it slightly
increases the amount of memory, but that is insignificant compared to the huge
amount of memory necessary for video buffers. And reducing driver complexity is
always good since that has always been the main problem with drivers, not memory
or code performance.
> Btw, that's how we solved
> this issue at rc core:
>
> http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/include/media/rc-map.h
>
> Also, that means a less footprint for tiny Kernels.
>
>> Well, for small sets of data (which this is) a binary search may well be
>> slower than a simple search. So yes, you should do some performance tests
>> before going with the more complex option.
>
> with 128 pixformats, a binary search takes 8 ifs against 128.
Actually, that's 64 on average. Even less if you know that some formats will
be searched for a lot more frequently than others and you can order your data
accordingly.
> So, it
> should be faster.
Binary search has a lot more overhead than a simple array traversal. I did
experiments with this when I worked on the control framework, and it was
very surprising how slow binary search was compared to a simple linked list
traversal. I think I needed well over 100 elements before the binary search
became faster. You really need to test things like this if you know the data
set is relatively small.
>
> Yet, even on a very slow machine, seeking for 128 formats is still
> likely fast enough to not affect performance of a media application.
I agree with that.
>> By placing the commonly used pixel formats at the beginning of the list I
>> suspect a simple search is the fastest lookup method, and very easy to
>> implement as well.
>
> IMHO, we shouldn't apply this approach, as we're just growing the
> Kernel size without any real benefit.
Simplifying drivers is the real benefit.
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: Advice on DVB-S/S2 card and CAM support
On 08/28/2014 05:26 PM, P. van Gaans wrote: On 08/28/2014 04:44 PM, Kaya Saman wrote: On 08/28/2014 04:47 AM, P. van Gaans wrote: On 07/28/2014 01:44 AM, Kaya Saman wrote: Hi, I'm wondering what the best solution for getting satellite working on Linux is? Currently I have a satellite box with CAM module branded by the Satellite TV provider we are with. As I am now migrating everything including TV through my HTPC environment I would also like to link the satellite box up to the HTPC too to take advantage of the PVR and streaming capabilities. I run XBMC as my frontend so I was looking into TV Headend to take care of PVR side of things. My greatest issue though is what is the best solution for getting the satellite system into the HTPC? After some research my first idea was to use a satellite tuner card; models are available for Hauppauge and other vendors so really it was about which was going to offer best compatibility with Linux? (distro is Arch Linux with 3.15 kernel) The model of card I was looking was from DVB-Sky: http://www.dvbsky.net/Products_S950C.html something like that, which has CAM module slot and is DVB-S/S2 compatible and claims to have drivers supported by the Linuxtv project. Or alternately going for something like this: http://www.dvbsky.net/Products_T9580.html as it has a combined DVB-T tuner, then using a USB card reader for the CAM "smart card". Has anyone used the cards above, what are the opinions relating to them? Also would they work with motorized dishes? Since I'm not sure if "all" CAM's are supported as apparently our satellite tv provider wanted to lock out other receivers so they force people to use their own product; my second idea was to perhaps use a capture card with RCA inputs. Something like this: http://www.c21video.com/viewcast/osprey-210.html perhaps or a Hauppauge HD-PVR mk I edition: which according to the wiki is supported. Looking forward to hearing advice. Thanks. Kaya -- 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 Hi Kaya, Hi, many thanks for the response! RCA inputs is probably the last thing you want. Less quality, more of a pain to set up. Unfortunately I need the composite inputs due to a set-top box which is used to watch (non-English) sports with; and they are paid channels. The box is non-HD so only RCA (Phono) or SCART output. You may or may not be able to use that CAM - but even if it's supported, a CAM has downsides. It generally only supports one channel at a time - and surely not multiple channels from different frequencies (if you have more tuners). And it's more expensive, both the tuner (that needs a CI slot) and the CAM you need. Also, I'm not sure if tvheadend nowadays supports a CAM - it used not to, but support may have been added. The main downside of a phoenix-mode cardreader is that it's harder to set up, but if you can find a guide for your provider it's generally doable. It's cheaper, more flexible and allows for faster channel switching. I doubt the provider will have a guide as they "claim" to want to lock everybody into their own set-top box - the non-HD one described above. As for a tuner, I personally suggest going for a USB-tuner. You never know if you want to connect you tuner to a notebook or NAS or anything in the future, with USB you're more flexible. If you do go for PCI-e, Tevii appears to have some supported products that are also available. If you go for USB, support is somewhat problematic (problematic because many supported tuners are no longer available in stores), you'll have to see what's locally available. (perhaps also check second-hand) Be careful, some devices have various revisions. Always check http://linuxtv.org/wiki/index.php/Hardware_Device_Information I did go this route eventually (since writing my initial post) :-) currently - though this was supposed to be my "last resort" route. I grabbed a Hauppauge WinTV PVR-1900 EU version. According to these guides: http://www.linuxtv.org/wiki/index.php/Pvrusb2 http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1950 http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1900 It is supported. I will need to write a separate posting for it though as I'm a little stuck with it. The BER is quite high and also I can't switch to the 'composite' input most of the time though on rare occasion it does work? The PCI/ or PCI-E card is still an option for me as it will go into a rather large HTPC case which I can also use as a server for distributed TV around the network. Very recently, Antti reviewed a patch from nibble.max to support the DVBsky S960. (and presumably it's direct clones from Mystique) This is a pretty cheap tuner that can still be found in shops. It would appear that as soon as this patch gets merged, this device will be supported if
Re: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
Em Thu, 28 Aug 2014 18:40:53 +0200
Hans Verkuil escreveu:
> On 08/28/2014 06:25 PM, Laurent Pinchart wrote:
> > Hi Philipp,
> >
> > On Thursday 28 August 2014 18:09:35 Philipp Zabel wrote:
> >> Am Donnerstag, den 28.08.2014, 14:24 +0200 schrieb Laurent Pinchart:
> A driver could then do the following:
>
> static struct v4l2_pixfmt_info driver_formats[] = {
>
> { .pixelformat = V4L2_PIX_FMT_YUYV },
> { .pixelformat = V4L2_PIX_FMT_YUV420 },
>
> };
>
> int driver_probe(...)
> {
>
> ...
> v4l2_init_pixfmt_array(driver_formats,
>
> ARRAY_SIZE(driver_formats));
>
> ...
>
> }
> >>>
> >>> Good question. This option consumes more memory, and prevents the driver-
> >>> specific format info arrays to be const, which bothers me a bit.
> >>
> >> Also, this wouldn't help drivers that don't want to take these
> >> additional steps, which probably includes a lot of camera drivers with
> >> only a few formats.
> >>
> >>> On the other hand it allows drivers to override some of the default
> >>> values for odd cases.
> >>
> >> Hm, but those cases don't have to use the v4l2_pixfmt_info at all.
> >>
> >>> I won't nack this approach, but I'm wondering whether a better
> >>> solution wouldn't be possible. Hans, Mauro, Guennadi, any opinion ?
> >>
> >> We could keep the global v4l2_pixfmt_info array sorted by fourcc value
> >> and do a binary search (would have to be kept in mind when adding new
> >> formats)
> >
> > I like that option, provided we can ensure that the array is sorted. This
> > can
> > get a bit tricky, and Hans might wear his "don't over-optimize" hat :-)
The big issue is that, afaikt, there's no way to make gcc to order it,
so the order would need to be manually ensured. This is challenging, and
makes the review process complex if done right.
I really don't see any gain on applying such patch. If the concern is
just about properly naming the pixel formats, it is a way easier to use
some defines for the names, and use the defines. Btw, that's how we solved
this issue at rc core:
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/include/media/rc-map.h
Also, that means a less footprint for tiny Kernels.
> Well, for small sets of data (which this is) a binary search may well be
> slower than a simple search. So yes, you should do some performance tests
> before going with the more complex option.
with 128 pixformats, a binary search takes 8 ifs against 128. So, it
should be faster.
Yet, even on a very slow machine, seeking for 128 formats is still
likely fast enough to not affect performance of a media application.
> By placing the commonly used pixel formats at the beginning of the list I
> suspect a simple search is the fastest lookup method, and very easy to
> implement as well.
IMHO, we shouldn't apply this approach, as we're just growing the
Kernel size without any real benefit.
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 -next] media/radio: fix radio-miropcm20.c build with io.h header file
From: Randy Dunlap Fix build errors in radio-miropcm20.c due to missing header file: drivers/media/radio/radio-miropcm20.c: In function 'rds_waitread': drivers/media/radio/radio-miropcm20.c:90:3: error: implicit declaration of function 'inb' [-Werror=implicit-function-declaration] drivers/media/radio/radio-miropcm20.c: In function 'rds_rawwrite': drivers/media/radio/radio-miropcm20.c:106:3: error: implicit declaration of function 'outb' [-Werror=implicit-function-declaration] Reported-by: Jim Davis Signed-off-by: Randy Dunlap --- drivers/media/radio/radio-miropcm20.c |1 + 1 file changed, 1 insertion(+) Index: linux-next-20140828/drivers/media/radio/radio-miropcm20.c === --- linux-next-20140828.orig/drivers/media/radio/radio-miropcm20.c +++ linux-next-20140828/drivers/media/radio/radio-miropcm20.c @@ -27,6 +27,7 @@ #include #include +#include #include #include #include -- 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: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
On 08/28/2014 06:25 PM, Laurent Pinchart wrote:
> Hi Philipp,
>
> On Thursday 28 August 2014 18:09:35 Philipp Zabel wrote:
>> Am Donnerstag, den 28.08.2014, 14:24 +0200 schrieb Laurent Pinchart:
A driver could then do the following:
static struct v4l2_pixfmt_info driver_formats[] = {
{ .pixelformat = V4L2_PIX_FMT_YUYV },
{ .pixelformat = V4L2_PIX_FMT_YUV420 },
};
int driver_probe(...)
{
...
v4l2_init_pixfmt_array(driver_formats,
ARRAY_SIZE(driver_formats));
...
}
>>>
>>> Good question. This option consumes more memory, and prevents the driver-
>>> specific format info arrays to be const, which bothers me a bit.
>>
>> Also, this wouldn't help drivers that don't want to take these
>> additional steps, which probably includes a lot of camera drivers with
>> only a few formats.
>>
>>> On the other hand it allows drivers to override some of the default
>>> values for odd cases.
>>
>> Hm, but those cases don't have to use the v4l2_pixfmt_info at all.
>>
>>> I won't nack this approach, but I'm wondering whether a better
>>> solution wouldn't be possible. Hans, Mauro, Guennadi, any opinion ?
>>
>> We could keep the global v4l2_pixfmt_info array sorted by fourcc value
>> and do a binary search (would have to be kept in mind when adding new
>> formats)
>
> I like that option, provided we can ensure that the array is sorted. This can
> get a bit tricky, and Hans might wear his "don't over-optimize" hat :-)
Well, for small sets of data (which this is) a binary search may well be
slower than a simple search. So yes, you should do some performance tests
before going with the more complex option.
By placing the commonly used pixel formats at the beginning of the list I
suspect a simple search is the fastest lookup method, and very easy to
implement as well.
Regards,
Hans
>
>> or build a hash table (more complicated code, consumes memory).
>
--
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: Advice on DVB-S/S2 card and CAM support
On 08/28/2014 04:44 PM, Kaya Saman wrote: On 08/28/2014 04:47 AM, P. van Gaans wrote: On 07/28/2014 01:44 AM, Kaya Saman wrote: Hi, I'm wondering what the best solution for getting satellite working on Linux is? Currently I have a satellite box with CAM module branded by the Satellite TV provider we are with. As I am now migrating everything including TV through my HTPC environment I would also like to link the satellite box up to the HTPC too to take advantage of the PVR and streaming capabilities. I run XBMC as my frontend so I was looking into TV Headend to take care of PVR side of things. My greatest issue though is what is the best solution for getting the satellite system into the HTPC? After some research my first idea was to use a satellite tuner card; models are available for Hauppauge and other vendors so really it was about which was going to offer best compatibility with Linux? (distro is Arch Linux with 3.15 kernel) The model of card I was looking was from DVB-Sky: http://www.dvbsky.net/Products_S950C.html something like that, which has CAM module slot and is DVB-S/S2 compatible and claims to have drivers supported by the Linuxtv project. Or alternately going for something like this: http://www.dvbsky.net/Products_T9580.html as it has a combined DVB-T tuner, then using a USB card reader for the CAM "smart card". Has anyone used the cards above, what are the opinions relating to them? Also would they work with motorized dishes? Since I'm not sure if "all" CAM's are supported as apparently our satellite tv provider wanted to lock out other receivers so they force people to use their own product; my second idea was to perhaps use a capture card with RCA inputs. Something like this: http://www.c21video.com/viewcast/osprey-210.html perhaps or a Hauppauge HD-PVR mk I edition: which according to the wiki is supported. Looking forward to hearing advice. Thanks. Kaya -- 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 Hi Kaya, Hi, many thanks for the response! RCA inputs is probably the last thing you want. Less quality, more of a pain to set up. Unfortunately I need the composite inputs due to a set-top box which is used to watch (non-English) sports with; and they are paid channels. The box is non-HD so only RCA (Phono) or SCART output. You may or may not be able to use that CAM - but even if it's supported, a CAM has downsides. It generally only supports one channel at a time - and surely not multiple channels from different frequencies (if you have more tuners). And it's more expensive, both the tuner (that needs a CI slot) and the CAM you need. Also, I'm not sure if tvheadend nowadays supports a CAM - it used not to, but support may have been added. The main downside of a phoenix-mode cardreader is that it's harder to set up, but if you can find a guide for your provider it's generally doable. It's cheaper, more flexible and allows for faster channel switching. I doubt the provider will have a guide as they "claim" to want to lock everybody into their own set-top box - the non-HD one described above. As for a tuner, I personally suggest going for a USB-tuner. You never know if you want to connect you tuner to a notebook or NAS or anything in the future, with USB you're more flexible. If you do go for PCI-e, Tevii appears to have some supported products that are also available. If you go for USB, support is somewhat problematic (problematic because many supported tuners are no longer available in stores), you'll have to see what's locally available. (perhaps also check second-hand) Be careful, some devices have various revisions. Always check http://linuxtv.org/wiki/index.php/Hardware_Device_Information I did go this route eventually (since writing my initial post) :-) currently - though this was supposed to be my "last resort" route. I grabbed a Hauppauge WinTV PVR-1900 EU version. According to these guides: http://www.linuxtv.org/wiki/index.php/Pvrusb2 http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1950 http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1900 It is supported. I will need to write a separate posting for it though as I'm a little stuck with it. The BER is quite high and also I can't switch to the 'composite' input most of the time though on rare occasion it does work? The PCI/ or PCI-E card is still an option for me as it will go into a rather large HTPC case which I can also use as a server for distributed TV around the network. Very recently, Antti reviewed a patch from nibble.max to support the DVBsky S960. (and presumably it's direct clones from Mystique) This is a pretty cheap tuner that can still be found in shops. It would appear that as soon as this patch gets merged, this device will be supported if you compile v4l-dvb yourself, and in time support wi
Re: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
Hi Philipp,
On Thursday 28 August 2014 18:09:35 Philipp Zabel wrote:
> Am Donnerstag, den 28.08.2014, 14:24 +0200 schrieb Laurent Pinchart:
> > > A driver could then do the following:
> > >
> > > static struct v4l2_pixfmt_info driver_formats[] = {
> > >
> > > { .pixelformat = V4L2_PIX_FMT_YUYV },
> > > { .pixelformat = V4L2_PIX_FMT_YUV420 },
> > >
> > > };
> > >
> > > int driver_probe(...)
> > > {
> > >
> > > ...
> > > v4l2_init_pixfmt_array(driver_formats,
> > >
> > > ARRAY_SIZE(driver_formats));
> > >
> > > ...
> > >
> > > }
> >
> > Good question. This option consumes more memory, and prevents the driver-
> > specific format info arrays to be const, which bothers me a bit.
>
> Also, this wouldn't help drivers that don't want to take these
> additional steps, which probably includes a lot of camera drivers with
> only a few formats.
>
> > On the other hand it allows drivers to override some of the default
> > values for odd cases.
>
> Hm, but those cases don't have to use the v4l2_pixfmt_info at all.
>
> > I won't nack this approach, but I'm wondering whether a better
> > solution wouldn't be possible. Hans, Mauro, Guennadi, any opinion ?
>
> We could keep the global v4l2_pixfmt_info array sorted by fourcc value
> and do a binary search (would have to be kept in mind when adding new
> formats)
I like that option, provided we can ensure that the array is sorted. This can
get a bit tricky, and Hans might wear his "don't over-optimize" hat :-)
> or build a hash table (more complicated code, consumes memory).
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] rc: Introduce hix5hd2 IR transmitter driver
On Thu, Aug 28, 2014 at 11:16:16PM +0800, Zhangfei Gao wrote:
> From: Guoxiong Yan
>
> IR transmitter driver for Hisilicon hix5hd2 soc
>
> By default all protocols are disabled.
> For example nec decoder can be enabled by either
> 1. ir-keytable -p nec
> 2. echo nec > /sys/class/rc/rc0/protocols
> See see Documentation/ABI/testing/sysfs-class-rc
I'm not sure that's true any more. All protocols are enabled, right?
>
> Signed-off-by: Guoxiong Yan
> Signed-off-by: Zhangfei Gao
> ---
> drivers/media/rc/Kconfig | 11 ++
> drivers/media/rc/Makefile |1 +
> drivers/media/rc/ir-hix5hd2.c | 351
> +
> 3 files changed, 363 insertions(+)
> create mode 100644 drivers/media/rc/ir-hix5hd2.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 5e626af..64dc8bb 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -164,6 +164,17 @@ config IR_ENE
> To compile this driver as a module, choose M here: the
> module will be called ene_ir.
>
> +config IR_HIX5HD2
> + tristate "Hisilicon hix5hd2 IR remote control"
> + depends on RC_CORE
> + help
> + Say Y here if you want to use hisilicon remote control.
> + The driver passes raw pulse and space information to the LIRC decoder.
> + To compile this driver as a module, choose M here: the module will be
> + called hisi_ir.
The module won't be called that.
> +
> + If you're not sure, select N here
> +
> config IR_IMON
> tristate "SoundGraph iMON Receiver and Display"
> depends on USB_ARCH_HAS_HCD
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 9f9843a1..0989f94 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
>
> # stand-alone IR receivers/transmitters
> obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
> +obj-$(CONFIG_IR_HIX5HD2) += ir-hix5hd2.o
> obj-$(CONFIG_IR_IMON) += imon.o
> obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o
> obj-$(CONFIG_IR_MCEUSB) += mceusb.o
> diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
> new file mode 100644
> index 000..1839709
> --- /dev/null
> +++ b/drivers/media/rc/ir-hix5hd2.c
> @@ -0,0 +1,351 @@
> +/*
> + * Copyright (c) 2014 Linaro Ltd.
> + * Copyright (c) 2014 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define IR_ENABLE0x00
> +#define IR_CONFIG0x04
> +#define CNT_LEADS0x08
> +#define CNT_LEADE0x0c
> +#define CNT_SLEADE 0x10
> +#define CNT0_B 0x14
> +#define CNT1_B 0x18
> +#define IR_BUSY 0x1c
> +#define IR_DATAH 0x20
> +#define IR_DATAL 0x24
> +#define IR_INTM 0x28
> +#define IR_INTS 0x2c
> +#define IR_INTC 0x30
> +#define IR_START 0x34
> +
> +/* interrupt mask */
> +#define INTMS_SYMBRCV(BIT(24) | BIT(8))
> +#define INTMS_TIMEOUT(BIT(25) | BIT(9))
> +#define INTMS_OVERFLOW (BIT(26) | BIT(10))
> +#define INT_CLR_OVERFLOW BIT(18)
> +#define INT_CLR_TIMEOUT BIT(17)
> +#define INT_CLR_RCV BIT(16)
> +#define INT_CLR_RCVTIMEOUT (BIT(16) | BIT(17))
> +
> +#define IR_CLK 0x48
> +#define IR_CLK_ENABLEBIT(4)
> +#define IR_CLK_RESET BIT(5)
> +
> +#define IR_CFG_WIDTH_MASK0x
> +#define IR_CFG_WIDTH_SHIFT 16
> +#define IR_CFG_FORMAT_MASK 0x3
> +#define IR_CFG_FORMAT_SHIFT 14
> +#define IR_CFG_INT_LEVEL_MASK0x3f
> +#define IR_CFG_INT_LEVEL_SHIFT 8
> +/* only support raw mode */
> +#define IR_CFG_MODE_RAW BIT(7)
> +#define IR_CFG_FREQ_MASK 0x7f
> +#define IR_CFG_FREQ_SHIFT0
> +#define IR_CFG_INT_THRESHOLD 1
> +/* symbol start from low to high, symbol stream end at high*/
> +#define IR_CFG_SYMBOL_FMT0
> +#define IR_CFG_SYMBOL_MAXWIDTH 0x3e80
> +
> +#define IR_HIX5HD2_NAME "hix5hd2-ir"
> +
> +struct hix5hd2_ir_priv {
> + int irq;
> + void*base;
> + struct device *dev;
> + struct rc_dev *rdev;
> + struct regmap *regmap;
> + struct clk *clock;
> + const char *map_name;
map_name member is only assigned, it's unused.
> + unsigned long rate;
> +};
> +
> +static void hix5hd2_ir_send_lirc_timeout(struct rc_dev *rdev)
> +{
> + DEFINE_IR_RAW_EVENT(ev);
> +
> + ev.timeout = true;
> +
randconfig build error with next-20140828, in drivers/media/radio/radio-miropcm20.c
Building with the attached random configuration file, CC [M] drivers/media/radio/radio-miropcm20.o drivers/media/radio/radio-miropcm20.c: In function ‘rds_waitread’: drivers/media/radio/radio-miropcm20.c:90:3: error: implicit declaration of function ‘inb’ [-Werror=implicit-function-declaration] byte = inb(aci->aci_port + ACI_REG_RDS); ^ drivers/media/radio/radio-miropcm20.c: In function ‘rds_rawwrite’: drivers/media/radio/radio-miropcm20.c:106:3: error: implicit declaration of function ‘outb’ [-Werror=implicit-function-declaration] outb(byte, aci->aci_port + ACI_REG_RDS); ^ cc1: some warnings being treated as errors make[3]: *** [drivers/media/radio/radio-miropcm20.o] Error 1 make[2]: *** [drivers/media/radio] Error 2 make[1]: *** [drivers/media] Error 2 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.17.0-rc2 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_TASKS_RCU=y # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_RT_GROUP_SCHED=y # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_LTO_MENU is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set CONFIG_BUG=y # CONFIG_PCSPKR_PLATFORM is not set CONFIG_BASE_FULL=y # CONFIG_FUT
Re: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
Hi Laurent,
Am Donnerstag, den 28.08.2014, 14:24 +0200 schrieb Laurent Pinchart:
> > A driver could then do the following:
> >
> > static struct v4l2_pixfmt_info driver_formats[] = {
> > { .pixelformat = V4L2_PIX_FMT_YUYV },
> > { .pixelformat = V4L2_PIX_FMT_YUV420 },
> > };
> >
> > int driver_probe(...)
> > {
> > ...
> > v4l2_init_pixfmt_array(driver_formats,
> > ARRAY_SIZE(driver_formats));
> > ...
> > }
>
> Good question. This option consumes more memory, and prevents the driver-
> specific format info arrays to be const, which bothers me a bit.
Also, this wouldn't help drivers that don't want to take these
additional steps, which probably includes a lot of camera drivers with
only a few formats.
> On the other hand it allows drivers to override some of the default
> values for odd cases.
Hm, but those cases don't have to use the v4l2_pixfmt_info at all.
> I won't nack this approach, but I'm wondering whether a better
> solution wouldn't be possible. Hans, Mauro, Guennadi, any opinion ?
We could keep the global v4l2_pixfmt_info array sorted by fourcc value
and do a binary search (would have to be kept in mind when adding new
formats) or build a hash table (more complicated code, consumes memory).
regards
Philipp
--
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 v3 3/3] ARM: dts: hix5hd2: add ir node
Signed-off-by: Zhangfei Gao
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index 7b1cb53..1d7cd04 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -391,7 +391,7 @@
};
sysctrl: system-controller@ {
- compatible = "hisilicon,sysctrl";
+ compatible = "hisilicon,sysctrl", "syscon";
reg = <0x 0x1000>;
reboot-offset = <0x4>;
};
@@ -476,5 +476,13 @@
interrupts = <0 70 4>;
clocks = <&clock HIX5HD2_SATA_CLK>;
};
+
+ ir: ir@001000 {
+ compatible = "hisilicon,hix5hd2-ir";
+ reg = <0x001000 0x1000>;
+ interrupts = <0 47 4>;
+ clocks = <&clock HIX5HD2_FIXED_24M>;
+ hisilicon,power-syscon = <&sysctrl>;
+ };
};
};
--
1.7.9.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 v3 2/3] rc: Introduce hix5hd2 IR transmitter driver
From: Guoxiong Yan
IR transmitter driver for Hisilicon hix5hd2 soc
By default all protocols are disabled.
For example nec decoder can be enabled by either
1. ir-keytable -p nec
2. echo nec > /sys/class/rc/rc0/protocols
See see Documentation/ABI/testing/sysfs-class-rc
Signed-off-by: Guoxiong Yan
Signed-off-by: Zhangfei Gao
---
drivers/media/rc/Kconfig | 11 ++
drivers/media/rc/Makefile |1 +
drivers/media/rc/ir-hix5hd2.c | 351 +
3 files changed, 363 insertions(+)
create mode 100644 drivers/media/rc/ir-hix5hd2.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 5e626af..64dc8bb 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -164,6 +164,17 @@ config IR_ENE
To compile this driver as a module, choose M here: the
module will be called ene_ir.
+config IR_HIX5HD2
+ tristate "Hisilicon hix5hd2 IR remote control"
+ depends on RC_CORE
+ help
+Say Y here if you want to use hisilicon remote control.
+The driver passes raw pulse and space information to the LIRC decoder.
+To compile this driver as a module, choose M here: the module will be
+called hisi_ir.
+
+If you're not sure, select N here
+
config IR_IMON
tristate "SoundGraph iMON Receiver and Display"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 9f9843a1..0989f94 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
+obj-$(CONFIG_IR_HIX5HD2) += ir-hix5hd2.o
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
new file mode 100644
index 000..1839709
--- /dev/null
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -0,0 +1,351 @@
+/*
+ * Copyright (c) 2014 Linaro Ltd.
+ * Copyright (c) 2014 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IR_ENABLE 0x00
+#define IR_CONFIG 0x04
+#define CNT_LEADS 0x08
+#define CNT_LEADE 0x0c
+#define CNT_SLEADE 0x10
+#define CNT0_B 0x14
+#define CNT1_B 0x18
+#define IR_BUSY0x1c
+#define IR_DATAH 0x20
+#define IR_DATAL 0x24
+#define IR_INTM0x28
+#define IR_INTS0x2c
+#define IR_INTC0x30
+#define IR_START 0x34
+
+/* interrupt mask */
+#define INTMS_SYMBRCV (BIT(24) | BIT(8))
+#define INTMS_TIMEOUT (BIT(25) | BIT(9))
+#define INTMS_OVERFLOW (BIT(26) | BIT(10))
+#define INT_CLR_OVERFLOW BIT(18)
+#define INT_CLR_TIMEOUTBIT(17)
+#define INT_CLR_RCVBIT(16)
+#define INT_CLR_RCVTIMEOUT (BIT(16) | BIT(17))
+
+#define IR_CLK 0x48
+#define IR_CLK_ENABLE BIT(4)
+#define IR_CLK_RESET BIT(5)
+
+#define IR_CFG_WIDTH_MASK 0x
+#define IR_CFG_WIDTH_SHIFT 16
+#define IR_CFG_FORMAT_MASK 0x3
+#define IR_CFG_FORMAT_SHIFT14
+#define IR_CFG_INT_LEVEL_MASK 0x3f
+#define IR_CFG_INT_LEVEL_SHIFT 8
+/* only support raw mode */
+#define IR_CFG_MODE_RAWBIT(7)
+#define IR_CFG_FREQ_MASK 0x7f
+#define IR_CFG_FREQ_SHIFT 0
+#define IR_CFG_INT_THRESHOLD 1
+/* symbol start from low to high, symbol stream end at high*/
+#define IR_CFG_SYMBOL_FMT 0
+#define IR_CFG_SYMBOL_MAXWIDTH 0x3e80
+
+#define IR_HIX5HD2_NAME"hix5hd2-ir"
+
+struct hix5hd2_ir_priv {
+ int irq;
+ void*base;
+ struct device *dev;
+ struct rc_dev *rdev;
+ struct regmap *regmap;
+ struct clk *clock;
+ const char *map_name;
+ unsigned long rate;
+};
+
+static void hix5hd2_ir_send_lirc_timeout(struct rc_dev *rdev)
+{
+ DEFINE_IR_RAW_EVENT(ev);
+
+ ev.timeout = true;
+ ir_raw_event_store(rdev, &ev);
+}
+
+static irqreturn_t hix5hd2_ir_rx_interrupt(int irq, void *data)
+{
+ u32 symb_num, symb_val, symb_time;
+ u32 data_l, data_h;
+ u32 irq_sr, i;
+ struct hix5hd2_ir_priv *priv = data;
+
+ irq_sr = readl_relaxed(priv->base + IR_INTS);
+ if (irq_sr & INTMS_OVERFLOW) {
+ /*
+* we must read IR_DATAL first, then we can clean up
+* IR_INTS a
[PATCH v3 0/3] Introduce hix5hd2 IR transmitter driver
v3: Got info from Mauro, 3.17 disable all protocol by default, specific protocol can be selected via ir-keytable and /sys/class/rc/rc0/protocols Got suggestion from Sean, add rdev specific info, like timeout, resoluton. Add optional property "linux,rc-map-name", if kernel keymap is used otherwise user space keymap will be used. v2: Rebase to 3.17-rc1, solve two issues: a) rc_set_allowed_protocols is deprecated b) rc-ir-raw.c add empty change_protocol, which block using all protocol For example, when rdev->map_name = RC_MAP_LIRC, ir-nec-decoder can not be used. Guoxiong Yan (2): rc: Add DT bindings for hix5hd2 rc: Introduce hix5hd2 IR transmitter driver Zhangfei Gao (1): ARM: dts: hix5hd2: add ir node .../devicetree/bindings/media/hix5hd2-ir.txt | 25 ++ arch/arm/boot/dts/hisi-x5hd2.dtsi | 10 +- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile |1 + drivers/media/rc/ir-hix5hd2.c | 351 5 files changed, 397 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt create mode 100644 drivers/media/rc/ir-hix5hd2.c -- 1.7.9.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 v3 1/3] rc: Add DT bindings for hix5hd2
From: Guoxiong Yan
Signed-off-by: Guoxiong Yan
Signed-off-by: Zhangfei Gao
---
.../devicetree/bindings/media/hix5hd2-ir.txt | 25
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
new file mode 100644
index 000..2bd88b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -0,0 +1,25 @@
+Device-Tree bindings for hix5hd2 ir IP
+
+Required properties:
+- compatible: Should contain "hisilicon,hix5hd2-ir".
+- reg: Base physical address of the controller and length of memory
+ mapped region.
+- interrupts: interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the interrupt
+ controller parent.
+- clocks: clock phandle and specifier pair.
+- hisilicon,power-syscon: phandle of syscon used to control power.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example node:
+
+ ir: ir@f8001000 {
+ compatible = "hisilicon,hix5hd2-ir";
+ reg = <0xf8001000 0x1000>;
+ interrupts = <0 47 4>;
+ clocks = <&clock HIX5HD2_FIXED_24M>;
+ hisilicon,power-syscon = <&sysctrl>;
+ linux,rc-map-name = "rc-tivo";
+ };
--
1.7.9.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: [PATCH] usb: gadget: f_uvc fix transition to video_ioctl2
On Thu, Aug 28, 2014 at 04:39:27PM +0200, Andrzej Pietrasiewicz wrote: > W dniu 28.08.2014 o 13:28, Laurent Pinchart pisze: > > > > >>diff --git a/drivers/usb/gadget/function/f_uvc.c > >>b/drivers/usb/gadget/function/f_uvc.c index 5209105..95dc1c6 100644 > >>--- a/drivers/usb/gadget/function/f_uvc.c > >>+++ b/drivers/usb/gadget/function/f_uvc.c > >>@@ -411,6 +411,7 @@ uvc_register_video(struct uvc_device *uvc) > >>video->fops = &uvc_v4l2_fops; > >>video->ioctl_ops = &uvc_v4l2_ioctl_ops; > >>video->release = video_device_release; > >>+ video->vfl_dir = VFL_DIR_TX; > > > >Do you have any objection against squashing this patch into "usb: gadget: > >f_uvc: Move to video_ioctl2" ? > > > Not at all. Feel free to squash it. This is in my testing/fixes, though. I'll drop it from there. -- balbi signature.asc Description: Digital signature
Re: Advice on DVB-S/S2 card and CAM support
On 08/28/2014 04:47 AM, P. van Gaans wrote: On 07/28/2014 01:44 AM, Kaya Saman wrote: Hi, I'm wondering what the best solution for getting satellite working on Linux is? Currently I have a satellite box with CAM module branded by the Satellite TV provider we are with. As I am now migrating everything including TV through my HTPC environment I would also like to link the satellite box up to the HTPC too to take advantage of the PVR and streaming capabilities. I run XBMC as my frontend so I was looking into TV Headend to take care of PVR side of things. My greatest issue though is what is the best solution for getting the satellite system into the HTPC? After some research my first idea was to use a satellite tuner card; models are available for Hauppauge and other vendors so really it was about which was going to offer best compatibility with Linux? (distro is Arch Linux with 3.15 kernel) The model of card I was looking was from DVB-Sky: http://www.dvbsky.net/Products_S950C.html something like that, which has CAM module slot and is DVB-S/S2 compatible and claims to have drivers supported by the Linuxtv project. Or alternately going for something like this: http://www.dvbsky.net/Products_T9580.html as it has a combined DVB-T tuner, then using a USB card reader for the CAM "smart card". Has anyone used the cards above, what are the opinions relating to them? Also would they work with motorized dishes? Since I'm not sure if "all" CAM's are supported as apparently our satellite tv provider wanted to lock out other receivers so they force people to use their own product; my second idea was to perhaps use a capture card with RCA inputs. Something like this: http://www.c21video.com/viewcast/osprey-210.html perhaps or a Hauppauge HD-PVR mk I edition: which according to the wiki is supported. Looking forward to hearing advice. Thanks. Kaya -- 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 Hi Kaya, Hi, many thanks for the response! RCA inputs is probably the last thing you want. Less quality, more of a pain to set up. Unfortunately I need the composite inputs due to a set-top box which is used to watch (non-English) sports with; and they are paid channels. The box is non-HD so only RCA (Phono) or SCART output. You may or may not be able to use that CAM - but even if it's supported, a CAM has downsides. It generally only supports one channel at a time - and surely not multiple channels from different frequencies (if you have more tuners). And it's more expensive, both the tuner (that needs a CI slot) and the CAM you need. Also, I'm not sure if tvheadend nowadays supports a CAM - it used not to, but support may have been added. The main downside of a phoenix-mode cardreader is that it's harder to set up, but if you can find a guide for your provider it's generally doable. It's cheaper, more flexible and allows for faster channel switching. I doubt the provider will have a guide as they "claim" to want to lock everybody into their own set-top box - the non-HD one described above. As for a tuner, I personally suggest going for a USB-tuner. You never know if you want to connect you tuner to a notebook or NAS or anything in the future, with USB you're more flexible. If you do go for PCI-e, Tevii appears to have some supported products that are also available. If you go for USB, support is somewhat problematic (problematic because many supported tuners are no longer available in stores), you'll have to see what's locally available. (perhaps also check second-hand) Be careful, some devices have various revisions. Always check http://linuxtv.org/wiki/index.php/Hardware_Device_Information I did go this route eventually (since writing my initial post) :-) currently - though this was supposed to be my "last resort" route. I grabbed a Hauppauge WinTV PVR-1900 EU version. According to these guides: http://www.linuxtv.org/wiki/index.php/Pvrusb2 http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1950 http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1900 It is supported. I will need to write a separate posting for it though as I'm a little stuck with it. The BER is quite high and also I can't switch to the 'composite' input most of the time though on rare occasion it does work? The PCI/ or PCI-E card is still an option for me as it will go into a rather large HTPC case which I can also use as a server for distributed TV around the network. Very recently, Antti reviewed a patch from nibble.max to support the DVBsky S960. (and presumably it's direct clones from Mystique) This is a pretty cheap tuner that can still be found in shops. It would appear that as soon as this patch gets merged, this device will be supported if you compile v4l-dvb yourself, and in time support will ma
Re: [PATCH] usb: gadget: f_uvc fix transition to video_ioctl2
W dniu 28.08.2014 o 13:28, Laurent Pinchart pisze: diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index 5209105..95dc1c6 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -411,6 +411,7 @@ uvc_register_video(struct uvc_device *uvc) video->fops = &uvc_v4l2_fops; video->ioctl_ops = &uvc_v4l2_ioctl_ops; video->release = video_device_release; + video->vfl_dir = VFL_DIR_TX; Do you have any objection against squashing this patch into "usb: gadget: f_uvc: Move to video_ioctl2" ? Not at all. Feel free to squash it. AP -- 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: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
Hi Philipp,
On Wednesday 27 August 2014 11:30:14 Philipp Zabel wrote:
> Am Dienstag, den 26.08.2014, 12:01 +0200 schrieb Laurent Pinchart:
> [...]
>
> > > +};
> > > +
> > > +const struct v4l2_pixfmt *v4l2_pixfmt_by_fourcc(u32 fourcc)
> > > +{
> > > + int i;
> >
> > The loop counter is always positive, it can be an unsigned int.
>
> I'll change that.
>
> > > + for (i = 0; i < ARRAY_SIZE(v4l2_pixfmts); i++) {
> > > + if (v4l2_pixfmts[i].pixelformat == fourcc)
> > > + return v4l2_pixfmts + i;
> > > + }
> >
> > We currently have 123 pixel formats defined, and that number will keep
> > increasing. I wonder if something more efficient than an O(n) array lookup
> > would be worth it.
>
> How about a function similar to soc_mbus_find_fmtdesc that uses an array
> provided by the driver:
>
> const struct v4l2_pixfmt_info *v4l2_find_pixfmt(u32 pixelformat,
> const struct v4l2_pixfmt_info *array, unsigned int len)
> {
> unsigned int i;
>
> for (i = 0; i < len; i++) {
> if (pixelformat == array[i].pixelformat)
> return array + i;
> }
>
> return NULL;
> }
>
> And a function to fill this driver specific array from the global array
> once:
>
> void v4l2_init_pixfmt_array(struct v4l2_pixfmt_info *array, int len)
> {
> unsigned int i;
>
> for (i = 0; i < len; i++)
> array[i] = *v4l2_pixfmt_by_fourcc(array[i].pixelformat);
> }
>
> A driver could then do the following:
>
> static struct v4l2_pixfmt_info driver_formats[] = {
> { .pixelformat = V4L2_PIX_FMT_YUYV },
> { .pixelformat = V4L2_PIX_FMT_YUV420 },
> };
>
> int driver_probe(...)
> {
> ...
> v4l2_init_pixfmt_array(driver_formats,
> ARRAY_SIZE(driver_formats));
> ...
> }
Good question. This option consumes more memory, and prevents the driver-
specific format info arrays to be const, which bothers me a bit. On the other
hand it allows drivers to override some of the default values for odd cases. I
won't nack this approach, but I'm wondering whether a better solution wouldn't
be possible. Hans, Mauro, Guennadi, any opinion ?
> [...]
>
> > > +unsigned int v4l2_sizeimage(const struct v4l2_pixfmt *fmt, unsigned int
> > > width,
> > > + unsigned int height)
> > > +{
> >
> > A small comment would be useful here to explain why we don't round up in
> > the second case.
>
> Agreed, I think the YUV410 case is a good example for this.
>
> [...]
>
> > > +/**
> > > + * struct v4l2_pixfmt - internal V4L2 pixel format description
> >
> > Maybe struct v4l2_pixfmt_info ?
>
> That's fine with me.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the omap3isp
Hi Stefan, On Wednesday 27 August 2014 12:24:46 Stefan Herbrechtsmeier wrote: > Am 04.08.2014 um 17:25 schrieb Laurent Pinchart: > > On Monday 04 August 2014 11:24:13 Stefan Herbrechtsmeier wrote: > >> Hi Laurent, > >> > >> thank you very much for your help. > >> > >> The problem is cross talk on the camera flex cable of the Gumstix Overo. > >> The XCLKA signal is beside PCLK and VS. > > > > Right, I should have mentioned that. It's a know issue, and there's not > > much that can be done about it without a hardware redesign. A ground (or > > power supply) signal should really have been inserted on each side of the > > XCLKA and PCLK signals. > > Exists a list about knowing issues with the Gumstix Overo? Because I > have some problems with the MMC3 too. Not to my knowledge. This crosstalk issue is something I've discovered and reported to Gumstix a couple of years ago. > >> Additionally the OV5647 camera tristate all outputs by default. This > >> leads to HS_VS_IRQ interrupts. > > > > This should be taken care of by pull-up or pull-down resistors on the > > camera signals. I've disabled them with the Caspa camera given the low > > drive strength of the buffer on the camera board, but you could enable > > them on your system. > > I have manually rework my camera adapter and change the camera clock > from XCLKA to XCLKB. Additionally I have enable the pull-ups in my > device tree. Now the camera sensor from the Raspberry Pi camera module > works together with the Gumstix Overo. Great. Any chance to see a driver for the ov5647 being submitted to the linux- media mailing list ? :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_uvc fix transition to video_ioctl2
Hi Andrzej, Thank you for the patch. On Wednesday 27 August 2014 17:16:38 Andrzej Pietrasiewicz wrote: > UVC video node is a TX device from the point of view of the gadget, > so we cannot rely on the video struct being filled with zeros, because > VFL_DIR_TX is actually 1. > > Suggested-by: Sylwester Nawrocki > Signed-off-by: Andrzej Pietrasiewicz > --- > drivers/usb/gadget/function/f_uvc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/gadget/function/f_uvc.c > b/drivers/usb/gadget/function/f_uvc.c index 5209105..95dc1c6 100644 > --- a/drivers/usb/gadget/function/f_uvc.c > +++ b/drivers/usb/gadget/function/f_uvc.c > @@ -411,6 +411,7 @@ uvc_register_video(struct uvc_device *uvc) > video->fops = &uvc_v4l2_fops; > video->ioctl_ops = &uvc_v4l2_ioctl_ops; > video->release = video_device_release; > + video->vfl_dir = VFL_DIR_TX; Do you have any objection against squashing this patch into "usb: gadget: f_uvc: Move to video_ioctl2" ? > strlcpy(video->name, cdev->gadget->name, sizeof(video->name)); > > uvc->vdev = video; -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] [media] rc: remove change_protocol in rc-ir-raw.c
On 08/27/2014 07:34 PM, Mauro Carvalho Chehab wrote:
With commit 4924a311a62f ("[media] rc-core: rename ir-raw.c"),
empty change_protocol was introduced.
No. This was introduced on this changeset:
commit da6e162d6a4607362f8478c715c797d84d449f8b
Author: David Härdeman
Date: Thu Apr 3 20:32:16 2014 -0300
[media] rc-core: simplify sysfs code
As a result, rc_register_device will set dev->enabled_protocols
addording to rc_map->rc_type, which prevent using all protocols.
I strongly suspect that this patch will break some things, as
the new code seems to expect that this is always be set.
See the code at store_protocols(): if this callback is not set,
then it won't allow to disable a protocol.
Also, this doesn't prevent using all protocols. You can still use
"ir-keytable -p all" to enable all protocols (the "all" protocol
type were introduced recently at the userspace tool).
From the way I see, setting the protocol when a table is loaded
is not a bad thing, as:
- if RC tables are loaded, the needed protocol to decode it is
already known;
- by running just one IR decoder, the IR handling routine will
be faster and will consume less power;
- on a real case scenario, it is a way more likely that just one
decoder will ever be needed by the end user.
So, I think that this is just annoying for developers when are checking
if all decoders are working, by sending keycodes from different IR types
at the same time.
Thanks Mauro for the kind explanation.
ir-keytable seems also enalbe specific protocol
-p, --protocol=PROTOCOL
Currently we use lirc user space decoder/keymap and only need
pulse-length information from kernel.
Well, you can use ir-keytable to disable everything but lirc, not
compile the other hardware decoders or directly write "lirc" to
/sys/class/rc/rc0/protocols (see Documentation/ABI/testing/sysfs-class-rc).
Anyway, I suggest you to use the hardware decoder instead of lirc,
as the in-kernel decoders should be lighter than lirc and works pretty
well, but this is, of course, your decision.
Btw, it would make sense, IMHO, to have a way to setup LIRC daemon to
enable LIRC output on a given remote controller, and, optionally,
disabling the hardware decoders that are needlessly enabled.
Thanks Mauro
Double checked, both ir-keytable and /sys/class/rc/rc0/protocols can
enable/disable protocols, which is much easier than dts passing
information, and by default all protocols are disabled.
Thanks for this kind information.
--
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 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
moikka, thanks for the comment. > I have feeling DVBv5 API is aimed to transfer data via property cached. > I haven't done much driver for DVBv5 statistics, but recently I > implemented CNR (DVBv5 stats) to Si2168 driver and it just writes all > the values directly to property cache. I expect RF strength (RSSI) is > just similar. Currently, the demod of PT3 card (tc90522) gets RSSI data from the connected tuner (mxl301rf) via tuner_ops.get_signal_strength_dbm() and sets property cache in fe->ops.get_frontend() (which is called before returning property cache value by dvb_frontend_ioctl_properties()). If the tuner driver should set property cache directly, when is the right timing to do so? In fe->ops.tuner_ops.get_status() ? or in the old fe->ops.tuner_ops.get_signal_strength()? or Should I change get_signal_strength_dbm(fe, s64 *) to update_signal_strength(fe) and let the tuner driver set property cache there? -- akihiro -- 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
[GIT PULL]: few dma-buf updates for 3.17-rc3
Hi Linus, The major changes for 3.17 already went via Greg-KH's tree this time as well; this is a small pull request for dma-buf - all documentation related. Could you please pull? The following changes since commit f1bd473f95e02bc382d4dae94d7f82e2a455e05d: Merge branch 'sec-v3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security (2014-08-27 17:32:37 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/for-3.17-rc3 for you to fetch changes up to 1f58d9465c568eb47cab939bbc4f30ae51863295: dma-buf/fence: Fix one more kerneldoc warning (2014-08-28 11:59:38 +0530) Small dma-buf pull request for 3.17-rc3 Gioh Kim (1): Documentation/dma-buf-sharing.txt: update API descriptions Thierry Reding (2): dma-buf/fence: Fix a kerneldoc warning dma-buf/fence: Fix one more kerneldoc warning Documentation/dma-buf-sharing.txt | 14 -- drivers/dma-buf/fence.c | 2 +- include/linux/seqno-fence.h | 1 + 3 files changed, 10 insertions(+), 7 deletions(-) -- 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: randconfig build error with next-20140826, in Documentation/video4linux
On Wed, Aug 27, 2014 at 10:33:46AM -0700, Jim Davis wrote: > On Wed, Aug 27, 2014 at 3:58 AM, Sudip Mukherjee > wrote: > > > Hi, > > I tried to build next-20140826 with your given config file . But for me > > everything was fine. > > Well, you should be able to reproduce it. Do these steps work for you? > > jim@krebstar:~/linux2$ git checkout next-20140826 > HEAD is now at 1c9e4561f3b2... Add linux-next specific files for 20140826 > jim@krebstar:~/linux2$ git clean -fdx > jim@krebstar:~/linux2$ cp ~/randconfig-1409069188.txt .config > jim@krebstar:~/linux2$ make oldconfig > HOSTCC scripts/basic/fixdep > HOSTCC scripts/kconfig/conf.o > SHIPPED scripts/kconfig/zconf.tab.c > SHIPPED scripts/kconfig/zconf.lex.c > SHIPPED scripts/kconfig/zconf.hash.c > HOSTCC scripts/kconfig/zconf.tab.o > HOSTLD scripts/kconfig/conf > scripts/kconfig/conf --oldconfig Kconfig > # > # configuration written to .config > # > jim@krebstar:~/linux2$ make -j4 >buildlog.txt 2>&1 > jim@krebstar:~/linux2$ grep ERROR buildlog.txt > ERROR: "vb2_ops_wait_finish" > [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! > > (followed by many more similar lines). yes , it worked. thanks . i was missing the oldconfig . thanks sudip -- 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
