Re: [RFC PATCH 1/3] adv7842: add new video decoder driver.
On 08/14/2013 05:10 AM, Prabhakar Lad wrote:
Hi Hans,
Thanks for the patch. Few nits below.
On Mon, Aug 12, 2013 at 6:43 PM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/adv7842.c | 3022
+++
include/media/adv7842.h | 226
4 files changed, 3261 insertions(+)
create mode 100644 drivers/media/i2c/adv7842.c
create mode 100644 include/media/adv7842.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b2cd8ca..847b711 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -206,6 +206,18 @@ config VIDEO_ADV7604
To compile this driver as a module, choose M here: the
module will be called adv7604.
+config VIDEO_ADV7842
+ tristate Analog Devices ADV7842 decoder
+ depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices ADV7842 video decoder.
+
+ This is a Analog Devices Component/Graphics/SD Digitizer
+ with 2:1 Multiplexed HDMI Receiver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7842.
+
config VIDEO_BT819
tristate BT819A VideoStream decoder
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index dc20653..b4cf972 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o
obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
new file mode 100644
index 000..84c9a83
--- /dev/null
+++ b/drivers/media/i2c/adv7842.c
@@ -0,0 +1,3022 @@
+/*
+ * adv7842 - Analog Devices ADV7842 video decoder driver
+ *
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+/*
+ * References (c = chapter, p = page):
+ * REF_01 - Analog devices, ADV7842, Register Settings Recommendations,
+ * Revision 2.5, June 2010
+ * REF_02 - Analog devices, Register map documentation, Documentation of
+ * the register maps, Software manual, Rev. F, June 2010
+ */
+
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/videodev2.h
+#include linux/workqueue.h
+#include linux/v4l2-dv-timings.h
+#include media/v4l2-device.h
+#include media/v4l2-ctrls.h
+#include media/adv7842.h
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+MODULE_DESCRIPTION(Analog Devices ADV7842 video decoder driver);
+MODULE_AUTHOR(Hans Verkuil hans.verk...@cisco.com);
+MODULE_AUTHOR(Martin Bugge marbu...@cisco.com);
+MODULE_LICENSE(GPL);
+
+/* ADV7842 system clock frequency */
+#define ADV7842_fsc (28636360)
+
+/*
+**
+*
+* Arrays with configuration parameters for the ADV7842
+*
+**
+*/
+
+struct adv7842_state {
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ struct v4l2_ctrl_handler hdl;
+ enum adv7842_mode mode;
+ struct v4l2_dv_timings timings;
+ enum adv7842_vid_std_select vid_std_select;
+ v4l2_std_id norm;
+ struct {
+ u8 edid[256];
+ u32 present;
+ } hdmi_edid;
+ struct {
+ u8 edid[256];
+ u32 present;
+ } vga_edid;
+ struct v4l2_fract aspect_ratio;
+ u32 rgb_quantization_range;
+ bool is_cea_format;
+ struct workqueue_struct *work_queues;
+ struct delayed_work
Re: [PATCH] v4l2-dev: Fix race condition on __video_register_device
On Tue 13 August 2013 17:04:06 Ricardo Ribalda Delgado wrote: When 2 devices are registered at the same time, in Part 2 both will get the same minor number, making Part6 crash, because it cannot create a create a device with a duplicated minor: You would expect that such core code would be bug free by now, but this is indeed a race condition. Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans [7.157648] [ cut here ] [7.157666] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xbd/0xe0() [7.157669] sysfs: cannot create duplicate filename '/dev/char/81:1' [7.157672] Modules linked in: qtec_xform(+) qt5023_video(+) videobuf2_vmalloc videobuf2_dma_sg videobuf2_memops videobuf2_core gpio_xilinx(+) qtec_white qtec_cmosis(+) qtec_pcie qt5023 [7.157694] CPU: 0 PID: 120 Comm: systemd-udevd Not tainted 3.10.0-qtec-standard #8 [7.157698] Hardware name: QTechnology QT5022/QT5022, BIOS PM_2.1.0.309 X64 05/23/2013 [7.157702] 0009 8801788358e8 8176c487 880178835928 [7.157707] 8106f6f0 880175759770 ffef 880175759930 [7.157712] 8801788359e8 880178bff000 880175759930 880178835988 [7.157718] Call Trace: [7.157728] [8176c487] dump_stack+0x19/0x1b [7.157735] [8106f6f0] warn_slowpath_common+0x70/0xa0 [7.157740] [8106f7d6] warn_slowpath_fmt+0x46/0x50 [7.157746] [81324b35] ? strlcat+0x65/0x90 [7.157750] [811d516d] sysfs_add_one+0xbd/0xe0 [7.157755] [811d5c6b] sysfs_do_create_link_sd+0xdb/0x200 [7.157760] [811d5db1] sysfs_create_link+0x21/0x40 [7.157765] [813e277b] device_add+0x21b/0x6d0 [7.157772] [813f2985] ? pm_runtime_init+0xe5/0xf0 [7.157776] [813e2c4e] device_register+0x1e/0x30 [7.157782] [8153e8c3] __video_register_device+0x313/0x610 [7.157791] [a00957c5] qtec_xform_probe+0x465/0x7a4 [qtec_xform] [7.157797] [813e7b13] platform_drv_probe+0x43/0x80 [7.157802] [813e531a] ? driver_sysfs_add+0x7a/0xb0 [7.157807] [813e584b] driver_probe_device+0x8b/0x3a0 [7.157812] [813e5c0b] __driver_attach+0xab/0xb0 [7.157816] [813e5b60] ? driver_probe_device+0x3a0/0x3a0 [7.157820] [813e37fd] bus_for_each_dev+0x5d/0xa0 [7.157825] [813e529e] driver_attach+0x1e/0x20 [7.157829] [813e4d3e] bus_add_driver+0x10e/0x280 [7.157833] [a0099000] ? 0xa0098fff [7.157837] [a0099000] ? 0xa0098fff [7.157842] [813e6317] driver_register+0x77/0x170 [7.157848] [81151bcc] ? __vunmap+0x9c/0x110 [7.157852] [a0099000] ? 0xa0098fff [7.157857] [813e7236] platform_driver_register+0x46/0x50 [7.157863] [a0099010] qtec_xform_plat_driver_init+0x10/0x12 [qtec_xform] [7.157869] [810002ea] do_one_initcall+0xea/0x1a0 [7.157875] [810cf1f1] load_module+0x1a91/0x2630 [7.157880] [8133bee0] ? ddebug_proc_show+0xe0/0xe0 [7.157887] [817760f2] ? page_fault+0x22/0x30 [7.157892] [810cfe7a] SyS_init_module+0xea/0x140 [7.157898] [8177e5b9] tracesys+0xd0/0xd5 [7.157902] ---[ end trace 660cc3a65a4bf01b ]--- [7.157939] __video_register_device: device_register failed Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com --- drivers/media/v4l2-core/v4l2-dev.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c index 5923c5d..3f75f99 100644 --- a/drivers/media/v4l2-core/v4l2-dev.c +++ b/drivers/media/v4l2-core/v4l2-dev.c @@ -873,6 +873,7 @@ int __video_register_device(struct video_device *vdev, int type, int nr, /* Should not happen since we thought this minor was free */ WARN_ON(video_device[vdev-minor] != NULL); + video_device[vdev-minor] = vdev; vdev-index = get_index(vdev); mutex_unlock(videodev_lock); @@ -936,9 +937,6 @@ int __video_register_device(struct video_device *vdev, int type, int nr, #endif /* Part 6: Activate this minor. The char device can now be used. */ set_bit(V4L2_FL_REGISTERED, vdev-flags); - mutex_lock(videodev_lock); - video_device[vdev-minor] = vdev; - mutex_unlock(videodev_lock); return 0; @@ -946,6 +944,7 @@ cleanup: mutex_lock(videodev_lock); if (vdev-cdev) cdev_del(vdev-cdev); + video_device[vdev-minor] = NULL; devnode_clear(vdev); mutex_unlock(videodev_lock); /* Mark this video device as never having been registered. */ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
RE: [PATCH V6 1/4] ARM: dts: Add DP PHY node to exynos5250.dtsi
Jingoo Han wrote:
Add PHY provider node for the DP PHY.
Signed-off-by: Jingoo Han jg1@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Kukjin Kim kgene@samsung.com
Thanks,
Kukjin
---
arch/arm/boot/dts/exynos5250.dtsi | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index fc9fb3d..c326c06 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -616,6 +616,12 @@
interrupts = 0 94 0;
};
+ dp_phy: video-phy@10040720 {
+ compatible = samsung,exynos5250-dp-video-phy;
+ reg = 0x10040720 4;
+ #phy-cells = 0;
+ };
+
dp-controller {
compatible = samsung,exynos5-dp;
reg = 0x145b 0x1000;
@@ -623,11 +629,8 @@
interrupt-parent = combiner;
#address-cells = 1;
#size-cells = 0;
-
- dptx-phy {
- reg = 0x10040720;
- samsung,enable-mask = 1;
- };
+ phys = dp_phy;
+ phy-names = dp;
};
fimd {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#719623: linux-image-3.10-2-amd64: kernel panic on inserting DVB-T stick
I took a quick look at the code and wonder if the problem is caused by an initial zero statistics message? This is all just a wild guess, but if it is correct, then the attached untested patch might fix it... Bjørn From d78a0599d5b5d4da384eae08bf7da316389dfbe5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= bj...@mork.no Date: Wed, 14 Aug 2013 10:24:39 +0200 Subject: [PATCH] [media] siano: fix divide error on 0 counters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ts_packets and ets_packets counters can be 0. Don't fall over if they are. Fixes: [ 846.851711] divide error: [#1] SMP [ 846.851806] Modules linked in: smsdvb dvb_core ir_lirc_codec lirc_dev ir_sanyo_decoder ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_hauppauge smsusb smsmdtv rc_core pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) parport_pc ppdev lp parport cpufreq_userspace cpufreq_powersave cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc ext4 jbd2 fuse tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm thinkpad_acpi nvram snd_page_alloc hid_generic snd_seq_midi snd_seq_midi_event arc4 usbhid snd_rawmidi uvcvideo hid iwldvm coretemp kvm_intel mac8021 1 cdc_wdm [ 846.853477] cdc_acm snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media kvm radeon r852 ttm joydev cdc_ether usbnet pcmcia mii sm_common nand btusb drm_kms_helper tpm_tis acpi_cpufreq bluetooth iwlwifi nand_ecc drm nand_ids i2c_i801 mtd snd_seq_device iTCO_wdt iTCO_vendor_support r592 memstick lpc_ich mperf tpm yenta_socket pcmcia_rsrc pcmcia_core cfg80211 snd_timer snd pcspkr i2c_algo_bit crc16 i2c_core tpm_bios processor mfd_core wmi psmouse mei_me rfkill mei serio_raw soundcore evdev battery button video ac microcode ext3 mbcache jbd md_mod dm_mirror dm_region_hash dm_log dm_mod sg sr_mod sd_mod cdrom crc_t10dif firewire_ohci sdhci_pci sdhci mmc_core firewire_core crc_itu_t thermal thermal_sys ahci libahci ehci_pci uhci_hcd ehci_hcd libata scsi_mod usbcore e1000 e usb_common [ 846.855310] ptp pps_core [ 846.855356] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.10-2-amd64 #1 Debian 3.10.5-1 [ 846.855490] Hardware name: LENOVO 4061WFA/4061WFA, BIOS 6FET92WW (3.22 ) 12/14/2011 [ 846.855609] task: 81613400 ti: 8160 task.ti: 8160 [ 846.855636] RIP: 0010:[a092be0c] [a092be0c] smsdvb_onresponse+0x264/0xa86 [smsdvb] [ 846.863906] RSP: 0018:88013bc03cf0 EFLAGS: 00010046 [ 846.863906] RAX: RBX: 880133bf6000 RCX: [ 846.863906] RDX: RSI: 88005d3b58c0 RDI: 880133bf6000 [ 846.863906] RBP: 88005d1da000 R08: 0058 R09: 0015 [ 846.863906] R10: 1a0d R11: 021a R12: 88005d3b58c0 [ 846.863906] R13: 88005d1da008 R14: ff8d R15: 880036cf5060 [ 846.863906] FS: () GS:88013bc0() knlGS: [ 846.863906] CS: 0010 DS: ES: CR0: 8005003b [ 846.863906] CR2: 7f3a4b69ae50 CR3: 36dac000 CR4: 000407f0 [ 846.863906] DR0: DR1: DR2: [ 846.863906] DR3: DR6: 0ff0 DR7: 0400 [ 846.863906] Stack: [ 846.863906] 88007a102000 88005d1da000 88005d3b58c0 00085824 [ 846.863906] a08c5aa3 88005d1da000 8800a6907390 8800a69073b0 [ 846.863906] 8800a6907000 a08b642c 021a 8800a69073b0 [ 846.863906] Call Trace: [ 846.863906] IRQ [ 846.863906] [ 846.863906] [a08c5aa3] ? smscore_onresponse+0x1d5/0x353 [smsmdtv] [ 846.863906] [a08b642c] ? smsusb_onresponse+0x146/0x192 [smsusb] [ 846.863906] [a004cb1a] ? usb_hcd_giveback_urb+0x6c/0xac [usbcore] [ 846.863906] [a0217be1] ? ehci_urb_done+0x62/0x72 [ehci_hcd] [ 846.863906] [a0217c82] ? qh_completions+0x91/0x364 [ehci_hcd] [ 846.863906] [a0219bba] ? ehci_work+0x8a/0x68e [ehci_hcd] [ 846.863906] [8107336c] ? timekeeping_get_ns.constprop.10+0xd/0x31 [ 846.863906] [81064d41] ? update_cfs_rq_blocked_load+0xde/0xec [ 846.863906] [81058ec2] ? run_posix_cpu_timers+0x25/0x575 [ 846.863906] [a021aa46] ? ehci_irq+0x211/0x23d [ehci_hcd] [ 846.863906] [a004c0c1] ? usb_hcd_irq+0x31/0x48 [usbcore] [ 846.863906] [810996fd] ? handle_irq_event_percpu+0x49/0x1a4 [ 846.863906] [8109988a] ? handle_irq_event+0x32/0x4b [ 846.863906] [8109bd76] ? handle_fasteoi_irq+0x80/0xb6 [ 846.863906] [8100e93e] ? handle_irq+0x18/0x20 [ 846.863906] [8100e657] ?
[PATCH 26/29] drivers/media/platform/coda.c: simplify use of devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,n,e,e1;
expression ret != 0;
identifier l;
@@
- res = platform_get_resource(pdev, IORESOURCE_MEM, n);
... when != res
- if (res == NULL) { ... \(goto l;\|return ret;\) }
... when != res
+ res = platform_get_resource(pdev, IORESOURCE_MEM, n);
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/media/platform/coda.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 66db0df..1a2192f 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -3122,11 +3122,6 @@ static int coda_probe(struct platform_device *pdev)
/* Get memory for physical registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(pdev-dev, failed to get memory region resource\n);
- return -ENOENT;
- }
-
dev-regs_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(dev-regs_base))
return PTR_ERR(dev-regs_base);
--
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 11/29] marvell-ccic/mmp-driver.c: simplify use of devm_ioremap_resource
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,n,e,e1;
expression ret != 0;
identifier l;
@@
- res = platform_get_resource(pdev, IORESOURCE_MEM, n);
... when != res
- if (res == NULL) { ... \(goto l;\|return ret;\) }
... when != res
+ res = platform_get_resource(pdev, IORESOURCE_MEM, n);
e = devm_ioremap_resource(e1, res);
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/media/platform/marvell-ccic/mmp-driver.c |8
1 file changed, 8 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index f06daa4..b5a19af 100644
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -396,10 +396,6 @@ static int mmpcam_probe(struct platform_device *pdev)
* Get our I/O memory.
*/
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(pdev-dev, no iomem resource!\n);
- return -ENODEV;
- }
mcam-regs = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(mcam-regs))
return PTR_ERR(mcam-regs);
@@ -409,10 +405,6 @@ static int mmpcam_probe(struct platform_device *pdev)
* should really be managed outside of this driver?
*/
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (res == NULL) {
- dev_err(pdev-dev, no power resource!\n);
- return -ENODEV;
- }
cam-power_regs = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(cam-power_regs))
return PTR_ERR(cam-power_regs);
--
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 0/29] simplify use of devm_ioremap_resource
devm_ioremap_resource often uses the result of a call to
platform_get_resource as its last argument. devm_ioremap_resource does
appropriate error handling on this argument, so error handling can be
removed from the call site. To make the connection between the call to
platform_get_resource and the call to devm_ioremap_resource more clear, the
former is also moved down to be adjacent to the latter.
In many cases, this patch changes the specific error value that is
returned on failure of platform_get_resource.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression pdev,res,n,e,e1;
expression ret != 0;
identifier l;
@@
(
res = platform_get_resource(pdev, IORESOURCE_MEM, n);
- if (res == NULL) { ... \(goto l;\|return ret;\) }
e = devm_ioremap_resource(e1, res);
|
- res = platform_get_resource(pdev, IORESOURCE_MEM, n);
... when != res
- if (res == NULL) { ... \(goto l;\|return ret;\) }
... when != res
+ res = platform_get_resource(pdev, IORESOURCE_MEM, n);
e = devm_ioremap_resource(e1, res);
)
// /smpl
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library
On Friday 09 August 2013 03:05 AM, Laurent Pinchart wrote:
Hi Archit,
On Monday 05 August 2013 16:56:46 Archit Taneja wrote:
On Monday 05 August 2013 01:43 PM, Tomi Valkeinen wrote:
On 02/08/13 17:03, Archit Taneja wrote:
+struct vpdma_data_format vpdma_yuv_fmts[] = {
+ [VPDMA_DATA_FMT_Y444] = {
+ .data_type = DATA_TYPE_Y444,
+ .depth = 8,
+ },
This, and all the other tables, should probably be consts?
That's true, I'll fix those.
+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+ u32 val = *valp;
+
+ val = ~(mask shift);
+ val |= (field mask) shift;
+ *valp = val;
+}
I think insert normally means, well, inserting a thing in between
something. What you do here is overwriting.
Why not just call it write_field?
sure, will change it.
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+ buf-size = size;
+ buf-mapped = 0;
Maybe true/false is clearer here that 0/1.
okay.
+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for
completion + */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list
*list) +{
+ /* we always use the first list */
+ int list_num = 0;
+ int list_size;
+
+ if (vpdma_list_busy(vpdma, list_num))
+ return -EBUSY;
+
+ /* 16-byte granularity */
+ list_size = (list-next - list-buf.addr) 4;
+
+ write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list-buf.dma_addr);
+ wmb();
What is the wmb() for?
VPDMA_LIST_ADDR needs to be written before VPDMA_LIST_ATTR, otherwise
VPDMA doesn't work. wmb() ensures the ordering.
write_reg() calls iowrite32(), which already includes an __iowmb().
I wasn't aware of that. I'll remove the wmb() call. Thanks for sharing
this info.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library
On Friday 09 August 2013 03:34 AM, Laurent Pinchart wrote:
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:38 Archit Taneja wrote:
The primary function of VPDMA is to move data between external memory and
internal processing modules(in our case, VPE) that source or sink data.
VPDMA is capable of buffering this data and then delivering the data as
demanded to the modules as programmed. The modules that source or sink data
are referred to as clients or ports. A channel is setup inside the VPDMA to
connect a specific memory buffer to a specific client. The VPDMA
centralizes the DMA control functions and buffering required to allow all
the clients to minimize the effect of long latency times.
Add the following to the VPDMA helper:
- A data struct which describe VPDMA channels. For now, these channels are
the ones used only by VPE, the list of channels will increase when
VIP(Video Input Port) also uses the VPDMA library. This channel information
will be used to populate fields required by data descriptors.
- Data structs which describe the different data types supported by VPDMA.
This data type information will be used to populate fields required by data
descriptors and used by the VPE driver to map a V4L2 format to the
corresponding VPDMA data type.
- Provide VPDMA register offset definitions, functions to read, write and
modify VPDMA registers.
- Functions to create and submit a VPDMA list. A list is a group of
descriptors that makes up a set of DMA transfers that need to be completed.
Each descriptor will either perform a DMA transaction to fetch input
buffers and write to output buffers(data descriptors), or configure the
MMRs of sub blocks of VPE(configuration descriptors), or provide control
information to VPDMA (control descriptors).
- Functions to allocate, map and unmap buffers needed for the descriptor
list, payloads containing MMR values and motion vector buffers. These use
the DMA mapping APIs to ensure exclusive access to VPDMA.
- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt on
the VPE interrupt line when a descriptor list is parsed completely and the
DMA transactions are completed. This requires masking the events in VPDMA
registers and configuring some top level VPE interrupt registers.
- Enable some VPDMA specific parameters: frame start event(when to start DMA
for a client) and line mode(whether each line fetched should be mirrored or
not).
- Function to load firmware required by VPDMA. VPDMA requires a firmware for
it's internal list manager. We add the required request_firmware apis to
fetch this firmware from user space.
- Function to dump VPDMA registers.
- A function to initialize VPDMA, this will be called by the VPE driver with
it's platform device pointer, this function will take care of loading VPDMA
firmware and returning a handle back to the VPE driver. The VIP driver will
also call the same init function to initialize it's own VPDMA instance.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 589 ++
drivers/media/platform/ti-vpe/vpdma.h | 154
drivers/media/platform/ti-vpe/vpdma_priv.h | 119 ++
3 files changed, 862 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/vpdma.c
create mode 100644 drivers/media/platform/ti-vpe/vpdma.h
create mode 100644 drivers/media/platform/ti-vpe/vpdma_priv.h
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c new file mode 100644
index 000..b15b3dd
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -0,0 +1,589 @@
[snip]
+static int get_field(u32 value, u32 mask, int shift)
+{
+ return (value (mask shift)) shift;
+}
+
+static int get_field_reg(struct vpdma_data *vpdma, int offset,
+ u32 mask, int shift)
I would call this read_field_reg().
+{
+ return get_field(read_reg(vpdma, offset), mask, shift);
+}
+
+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+ u32 val = *valp;
+
+ val = ~(mask shift);
+ val |= (field mask) shift;
+ *valp = val;
+}
get_field() and insert_field() are used in a single location, you can manually
inline them.
Thanks, I'll make these modifications.
+static void insert_field_reg(struct vpdma_data *vpdma, int offset, u32
field,
+ u32 mask, int shift)
+{
+ u32 val = read_reg(vpdma, offset);
+
+ insert_field(val, field, mask, shift);
+
+ write_reg(vpdma, offset, val);
+}
[snip]
+/*
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+ buf-size = size;
+ buf-mapped = 0;
+ buf-addr = kzalloc(size, GFP_KERNEL);
You should use the dma allocation API (depending on your needs,
dma_alloc_coherent for instance) to allocate DMA-able buffers.
I'm not sure about this, dma_map_single() api works fine on kzalloc'd
buffers. The above
Re: [RFCv2 PATCH 02/10] v4l2: add matrix support.
Hi Hans,
Thanks for the set!
On Mon, Aug 12, 2013 at 12:58:25PM +0200, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
This patch adds core support for matrices: querying, getting and setting.
Two initial matrix types are defined for motion detection (defining regions
and thresholds).
I requested in the past that no new IOCTLs would be added for an essential
extension of V4L2 control-like functionality. I understand developing a more
generic framework does not answer to the problems at hand right now, so I
think it's certainly fine to continue with matrix IOCTLs, too. But we still
should think a little about extensibility a little bit.
How about using the same ID space as the controls do for matrices, for
instance, so we won't get one more? The selections and controls have no ID
collisions at the moment.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-dev.c | 3 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 23 -
include/media/v4l2-ioctl.h | 8 +
include/uapi/linux/videodev2.h | 64
4 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index c8859d6..5e58df6 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -598,6 +598,9 @@ static void determine_valid_ioctls(struct video_device
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_UNSUBSCRIBE_EVENT,
vidioc_unsubscribe_event);
if (ops-vidioc_enum_freq_bands || ops-vidioc_g_tuner ||
ops-vidioc_g_modulator)
set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
+ SET_VALID_IOCTL(ops, VIDIOC_QUERY_MATRIX, vidioc_query_matrix);
+ SET_VALID_IOCTL(ops, VIDIOC_G_MATRIX, vidioc_g_matrix);
+ SET_VALID_IOCTL(ops, VIDIOC_S_MATRIX, vidioc_s_matrix);
if (is_vid) {
/* video specific ioctls */
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 68e6b5e..47debfc 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -549,7 +549,7 @@ static void v4l_print_cropcap(const void *arg, bool
write_only)
const struct v4l2_cropcap *p = arg;
pr_cont(type=%s, bounds wxh=%dx%d, x,y=%d,%d,
- defrect wxh=%dx%d, x,y=%d,%d\n,
+ defrect wxh=%dx%d, x,y=%d,%d,
pixelaspect %d/%d\n,
prt_names(p-type, v4l2_type_names),
p-bounds.width, p-bounds.height,
@@ -831,6 +831,24 @@ static void v4l_print_freq_band(const void *arg, bool
write_only)
p-rangehigh, p-modulation);
}
+static void v4l_print_query_matrix(const void *arg, bool write_only)
+{
+ const struct v4l2_query_matrix *p = arg;
+
+ pr_cont(type=0x%x, columns=%u, rows=%u, elem_min=%lld, elem_max=%lld,
elem_size=%u\n,
+ p-type, p-columns, p-rows,
+ p-elem_min.val, p-elem_max.val, p-elem_size);
+}
+
+static void v4l_print_matrix(const void *arg, bool write_only)
+{
+ const struct v4l2_matrix *p = arg;
+
+ pr_cont(type=0x%x, wxh=%dx%d, x,y=%d,%d, matrix=%p\n,
+ p-type, p-rect.width, p-rect.height,
+ p-rect.top, p-rect.left, p-matrix);
+}
+
static void v4l_print_u32(const void *arg, bool write_only)
{
pr_cont(value=%u\n, *(const u32 *)arg);
@@ -2055,6 +2073,9 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
+ IOCTL_INFO_STD(VIDIOC_QUERY_MATRIX, vidioc_query_matrix,
v4l_print_query_matrix, INFO_FL_CLEAR(v4l2_query_matrix, ref)),
+ IOCTL_INFO_STD(VIDIOC_G_MATRIX, vidioc_g_matrix, v4l_print_matrix,
INFO_FL_CLEAR(v4l2_matrix, matrix)),
+ IOCTL_INFO_STD(VIDIOC_S_MATRIX, vidioc_s_matrix, v4l_print_matrix,
INFO_FL_PRIO | INFO_FL_CLEAR(v4l2_matrix, matrix)),
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e0b74a4..7e4538e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -271,6 +271,14 @@ struct v4l2_ioctl_ops {
int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
const struct v4l2_event_subscription
*sub);
+ /* Matrix ioctls */
+ int (*vidioc_query_matrix) (struct file *file, void *fh,
+ struct v4l2_query_matrix *qmatrix);
+ int (*vidioc_g_matrix) (struct file *file, void *fh,
+
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing
things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1,
phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup
methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned
manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id,
is
frought with fragility and will break in the future in various
ways
when
devices get added to systems, making these strings constantly
have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that
this
happens today with the clock code, doesn't make it right, it
makes
the
clock code wrong. Others have already said that this is wrong
there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be
removed,
the
device id should be automatically created by the phy core just
to
make
things unique in sysfs, and no driver code should _ever_ be
reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this
subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people
trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
end up
adding similar infrastructure to the driver themselves to make
sure
we
don't end up with duplicate names in sysfs in case we have
multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we
lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns
its
own id and we *don't* want to add any requirement that the ID must
be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to
struct device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
Well, this is a total mess anyway... I don't really get the point of using
Re: [PATCH RFC v2 1/2] max77693: added device tree support
Hi Lee, I have no response from Samuel regarding this patch. Could you take care of it, I can rebase it again if necessary. Regards Andrzej On 07/17/2013 09:45 AM, Andrzej Hajda wrote: Hi Samuel, A while ago I have send rebased patch adding device-tree support for max77693 as you asked: https://patchwork.kernel.org/patch/2414341/ The patch is still not applied. Is there a reason for that or just an omission? Regards Andrzej On 04/08/2013 05:21 PM, Samuel Ortiz wrote: Hi Andrzej, On Tue, Feb 19, 2013 at 04:36:16PM +0100, Andrzej Hajda wrote: max77693 mfd main device uses only wakeup field from max77693_platform_data. This field is mapped to wakeup-source property in device tree. Device tree bindings doc will be added in max77693-led patch. Signed-off-by: Andrzej Hajda a.ha...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mfd/max77693.c | 40 +--- 1 file changed, 33 insertions(+), 7 deletions(-) This patch looks good to me, but doesn't apply to mfd-next. Would you mind rebasing it ? Cheers, Samuel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 1/2] max77693: added device tree support
I have no response from Samuel regarding this patch. Could you take care of it, I can rebase it again if necessary. Yes, please rebase onto v3.11-rc5 and resubmit. Thanks. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v4 2/2] [stage/sunxi-3.4] Add support for Allwinner (DVB/ATSC) Transport Stream Controller(s) (TSC)
OK, with the patched fex file and devices.c from [linux-sunxi] [PATCH v2 1/1] [sunxi-boards/a20] Add support for Allwinner (DVB/ATSC) Transport Stream Controller(s) (TSC) [PATCH v2 1/1] [stage/sunxi-3.4] sw_nand: sunxi devices core using wrong MMIO region range, overlaps TSC/TSI register base address 0x01c04000 and the driver patches from this topic here the driver basically loads and inits: [ 161.016837] [tsc-inf] tscdev_init: kmalloc memory, size: 0x212000 [ 161.042378] [tsc-dbg] register_tsiomem: check_mem_region return: 0 [ 161.055409] [tsc-dbg] register_tsiomem: devp-regsaddr: 0xf0104000 root@vdr2:~# cat /proc/iomem |grep -C 1 -i ts 01c03000-01c03fff : sw_nand 01c04000-01c04fff : ts regs 01c0a000-01c0afff : disp root@vdr2:~# ls -l /dev/ts* crw--- 1 root root 225, 0 Aug 14 19:10 /dev/tsc_dev And ioctl() triggers the controller setup successfully. root@vdr2:~# dd if=/dev/tsc_dev of=/dev/null bs=1K count=100 [ 1064.861178] [tsc-inf] tscdev_open: ahb_ts clk rate: 0x1 [ 1064.871506] [tsc-inf] tscdev_open: parent clock rate 38400 [ 1064.881674] [tsc-inf] tscdev_open: clock rate 19200 [ 1064.891079] [tsc-inf] tscdev_open: clock rate 19200 Ready to build the Philips CU1216-MKIII TDA10023 DVB-C- Receiver recycling SMT extension board next days. Others are invited to build boards with their receiver modules and extend driver Kconfig for more receivers, too. Next i2c and frontend driver integration, if someone can do that faster, pls don't wait for me and pls CC linux-media list. dvb_core integration after the hardware and driver PIO tests success. Thanks for all the great community support :-) y tom -- 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: st-rc: Add ST remote control driver
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP is common across all the ST parts for
settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx Tx functionality.
In this driver adds only Rx functionality via LIRC codec.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
---
Hi Chehab,
This is a very simple rc driver for IRB controller found in STi ARM CA9 SOCs.
STi ARM SOC support went in 3.11 recently.
This driver is a raw driver which feeds data to lirc codec for the user lircd
to decode the keys.
This patch is based on git://linuxtv.org/media_tree.git master branch.
Comments?
Thanks,
srini
Documentation/devicetree/bindings/media/st-rc.txt | 18 +
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/st_rc.c | 371 +
4 files changed, 400 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
create mode 100644 drivers/media/rc/st_rc.c
diff --git a/Documentation/devicetree/bindings/media/st-rc.txt
b/Documentation/devicetree/bindings/media/st-rc.txt
new file mode 100644
index 000..57f9ee8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st-rc.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for ST IR and UHF receiver
+
+Required properties:
+ - compatible: should be st,rc.
+ - st,uhfmode: boolean property to indicate if reception is in UHF.
+ - reg: base physical address of the controller and length of memory
+ mapped region.
+ - interrupts: interrupt number to the cpu. The interrupt specifier
+ format depends on the interrupt controller parent.
+
+Example node:
+
+ rc: rc@fe518000 {
+ compatible = st,rc;
+ reg = 0xfe518000 0x234;
+ interrupts = 0 203 0;
+ };
+
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 5a79c33..548a705 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -321,4 +321,14 @@ config IR_GPIO_CIR
To compile this driver as a module, choose M here: the module will
be called gpio-ir-recv.
+config RC_ST
+ tristate ST remote control receiver
+ depends on ARCH_STI LIRC
+ help
+Say Y here if you want support for ST remote control driver
+which allows both IR and UHF RX. IR RX receiver is the default mode.
+The driver passes raw pluse and space information to the LIRC decoder.
+
+If you're not sure, select N here.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 56bacf0..f4eb32c 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
+obj-$(CONFIG_RC_ST) += st_rc.o
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
new file mode 100644
index 000..712a2fb
--- /dev/null
+++ b/drivers/media/rc/st_rc.c
@@ -0,0 +1,371 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include media/rc-core.h
+#include linux/pinctrl/consumer.h
+
+struct st_rc_device {
+ struct device *dev;
+ int irq;
+ int irq_wake;
+ struct clk *sys_clock;
+ void*base; /* Register base address */
+ void*rx_base;/* RX Register base address */
+ struct rc_dev *rdev;
+ booloverclocking;
+ int sample_mult;
+ int sample_div;
+ boolrxuhfmode;
+};
+
+/* Registers */
+#define IRB_SAMPLE_RATE_COMM 0x64/* sample freq divisor*/
+#define IRB_CLOCK_SEL 0x70/* clock select */
+#define IRB_CLOCK_SEL_STATUS 0x74/* clock status */
+/* IRB IR/UHF receiver registers */
+#define IRB_RX_ON 0x40 /* pulse time capture */
+#define IRB_RX_SYS 0X44 /* sym period capture */
+#define IRB_RX_INT_EN 0x48 /* IRQ enable (R/W) */
+#define
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: Wed Aug 14 19:00:18 CEST 2013 git branch: test git hash: dfb9f94e8e5e7f73c8e2bcb7d4fb1de57e7c333d gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
[PATCH 1/1] cx23885-dvb: fix ds3000 ts2020 split for TEVII S471
A split for ds3000/ts2020 code forgot to change the TEVII_S471 code.
Change the TEVII_S471 according the changes to TEVII_S470.
Signed-off-by: Christian Volkmann c...@cv-sv.de
---
drivers/media/pci/cx23885/cx23885-dvb.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 9c5ed10..be98c49 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1038,7 +1038,6 @@ static int dvb_register(struct cx23885_tsport *port)
tevii_ts2020_config, i2c_bus-i2c_adap);
fe0-dvb.frontend-ops.set_voltage = f300_set_voltage;
}
-
break;
case CX23885_BOARD_DVBWORLD_2005:
i2c_bus = dev-i2c_bus[1];
@@ -1249,6 +1248,11 @@ static int dvb_register(struct cx23885_tsport *port)
fe0-dvb.frontend = dvb_attach(ds3000_attach,
tevii_ds3000_config,
i2c_bus-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ dvb_attach(ts2020_attach, fe0-dvb.frontend,
+ tevii_ts2020_config, i2c_bus-i2c_adap);
+ fe0-dvb.frontend-ops.set_voltage = f300_set_voltage;
+ }
break;
case CX23885_BOARD_PROF_8000:
i2c_bus = dev-i2c_bus[0];
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
