[REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
Hello. I contacted you because I am hit by regression caused by your commit: 453afdd [media] cx23885: convert to vb2 My system: AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver) After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7 (have commit) I started receiving following IOMMU related messages: 1) AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d address=0x0637c000 flags=0x] where device=0a:00.0 is TBS6981 card sometimes this message was followed by storm of following messages: cx23885[0]: mpeg risc op code error ... 2) [ cut here ] WARNING: CPU: 1 PID: 6946 at drivers/iommu/amd_iommu.c:2637 dma_ops_domain_unmap.part.12+0x55/0x72() Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT xt_realm xt_addrtype xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set nf_nat_ftp xt_time xt_TCPMSS xt_tcpmss xt_policy xt_pkttype xt_physdev br_netfilter xt_NFQUEUE xt_NFLOG xt_mark xt_mac xt_length xt_helper xt_hashlimit xt_DSCP xt_dscp xt_CLASSIFY xt_AUDIT iptable_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle hwmon_vid bridge stp llc ipv6 cx24117 cx25840 snd_usb_audio snd_hwdep snd_usbmidi_lib uvcvideo snd_rawmidi videobuf2_vmalloc snd_hda_codec_hdmi ir_xmp_decoder ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_rc6_mce microcode k10temp mceusb cx23885 tda18271 altera_stapl videobuf2_dvb videobuf2_core videobuf2_dma_sg videobuf2_memops tveeprom cx2341x rc_core v4l2_common videodev si2157 si2168 saa716x_budget saa716x_core dvb_core nouveau i2c_algo_bit ttm snd_hda_intel drm_kms_helper snd_hda_controller sp5100_tco r8169 i2c_piix4 snd_hda_codec drm mii CPU: 1 PID: 6946 Comm: w_scan Tainted: GW 3.19.0-rc3-myrc01 #1 Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 2501 04/09/2014 0009 b0640fe8 b00bcf46 00d27000 b04eb2a0 00d46000 00d27000 8800b8287938 0001 01f8 Call Trace: [b0640fe8] ? dump_stack+0x40/0x50 [b00bcf46] ? warn_slowpath_common+0x93/0xab [b04eb2a0] ? dma_ops_domain_unmap.part.12+0x55/0x72 [b04eb2a0] ? dma_ops_domain_unmap.part.12+0x55/0x72 [b04ecc8c] ? __unmap_single.isra.15+0x7b/0xcf [b04ed43a] ? free_coherent+0x46/0x7e [c05b064f] ? __vb2_queue_cancel+0x1b8/0x1d6 [videobuf2_core] [c05b22e1] ? __reqbufs+0x15b/0x334 [videobuf2_core] [c05b2647] ? vb2_thread_stop+0x100/0x146 [videobuf2_core] [c05bc0ce] ? vb2_dvb_stop_feed+0x41/0x58 [videobuf2_dvb] [c052b4ea] ? dvb_dmxdev_filter_start+0x35/0x301 [dvb_core] [c052d12f] ? dmx_section_feed_stop_filtering+0x40/0x7b [dvb_core] [c052b307] ? dvb_dmxdev_feed_stop+0x5d/0x89 [dvb_core] [c052b60f] ? dvb_dmxdev_filter_start+0x15a/0x301 [dvb_core] [c052bd3f] ? dvb_demux_do_ioctl+0x1cc/0x4fe [dvb_core] [b016973d] ? path_openat+0x44d/0x55d [c052bb73] ? dvb_dmxdev_ts_callback+0xc2/0xc2 [dvb_core] [c052a6b9] ? dvb_usercopy+0xa7/0x127 [dvb_core] [b016a38f] ? do_filp_open+0x2b/0x6f [c052aa3f] ? dvb_demux_ioctl+0xd/0x11 [dvb_core] [c052aa32] ? dvb_dvr_ioctl+0x11/0x11 [dvb_core] [b016bf68] ? do_vfs_ioctl+0x360/0x424 [b0173706] ? __fd_install+0x15/0x40 [b015d5a9] ? do_sys_open+0x1b3/0x1c5 [b016c05f] ? SyS_ioctl+0x33/0x58 [b0646452] ? system_call_fastpath+0x12/0x17 ---[ end trace 2f92b32249912b0e ]--- 3) after enabling debug in DMA API, I started receiving following message: [ cut here ] WARNING: CPU: 1 PID: 6946 at lib/dma-debug.c:1093 check_unmap+0x180/0x7c6() cx23885 :0a:00.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00d27000] [size=504 bytes] Modules linked in: ip6table_filter ip6_tables act_police cls_basic cls_flow cls_fw cls_u32 sch_fq_codel sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT xt_realm xt_addrtype xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set nf_nat_ftp xt_time xt_TCPMSS xt_tcpmss xt_policy xt_pkttype xt_physdev br_netfilter xt_NFQUEUE xt_NFLOG xt_mark xt_mac xt_length xt_helper xt_hashlimit xt_DSCP xt_dscp xt_CLASSIFY xt_AUDIT iptable_raw iptable_nat nf_nat_ipv4 nf_nat iptable_mangle hwmon_vid bridge stp llc ipv6 cx24117 cx25840 snd_usb_audio snd_hwdep snd_usbmidi_lib uvcvideo snd_rawmidi
Re: dvb-t scan tables
Hey Brian, On 01/09/2015 12:22 AM, Brian Burch wrote: On 08/01/15 13:16, Jonathan McCrohan wrote: Hi Olliver/Brian/Adam, On 8 January 2015 09:29:10 GMT+00:00, Olliver Schinagl oli...@schinagl.nl wrote: snip Because I am basically an ubuntu user, I took the source from the latest debian unstable repository to generate my patch. I submitted it as an ubuntu bug so it would be documented and distributed throughout that particular distribution tree. I felt (perhaps wrongly) that submitting directly to the original developers would a) miss the documentation cascade, and b) might not be committed to the ubuntu repositories as quickly. While this might be the fastest way to get a seperated patch into ubuntu, ideally we'd like to have it as quickly as possible in the main tree. I'm not sure how quickly or _if at all_ ubuntu sends their table patches upstream! I would imagine the ubuntu devs keeping the patch until the patch fails, indicating that it has landed upstream ... So while faster in ubuntu, it wlll be slower, or not at all everywhere else :(. Submitting a bug against dtv-scan-tables to the Debian/Ubuntu bug tracker isn't the worst thing in the world; I maintain the package in Debian and keep it up to date. Ubuntu then syncs the package from Debian. I monitor both bug trackers for bug reports and send any upstream. There are a LOT of distros that branch off this particular tree. I use four of them, for example. In the past I've submitted fixes to the original developers of other packages, but it has taken months or years to get them pulled into the distros that matter to me. It is very frustrating to have a fix accepted but /still/ having to manually patch my own systems to maintain synchronisation with the main repositories. Yes, that's the reason why we split off the dtv-scan-tables from the dvb-utils repository, as some of those changes where lingering for ages. I've been advised by the ubuntu maintenance people that the best way to close the loop is to start at their end. If the report and the patch are credible, they usually push it upstream using the best path quite quickly. While it's an extra step and takes a bit longer, it certainly works ;) cc-ing me and the linux-media list with dtv-scan-tables in the subject does both ;) The big difference with normal code patches, and dvb patches is, we more or less rely on the persons in the area to verify the data, there's only very little that can get 'reviewed' as we don't know if the data is right or wrong. I hope to have a change to au_SunshineCoast quite soon, so I am very pleased to know that Jonathan will be looking after any changes that flow along my chosen path. cc me + ml and it'll happen faster. I don't think there is a perfect solution, but ubuntu/debian bugs often turn up high on general searches. If a fix exists, it is much easier to get maintainers of non-debian distros to accept a bug report, easy for them to pull down the source and then quickly release an update. also true, I like how tv-headend handles this, they pull the latest git periodically I think. (Thinks... it is a pity this thread didn't take place on the appropriate mailing list). CC-ed the list :) Best wishes, and thanks for the very useful software! Technically, it's not software ;) olliver Brian Best to send them directly upstream to linux-media@vger.kernel.org if you can manage it though :-) Jon -- 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: dvb-t scan tables
Hey Adam, I've merged your changes, but this last patch seems to go against the old (obsolete) dvbv3 stuff (that gets auto-generated afaik) and fails to apply. Look at the result on the various repositories and see what needs to be changed. Best way to send a patch, is to use git to checkout the tree, and then do a git format-patch to send the patch, saves me some work ;) Olliver On 01/08/2015 03:12 PM, Adam Laurie wrote: On 08/01/15 13:16, Jonathan McCrohan wrote: Submitting a bug against dtv-scan-tables to the Debian/Ubuntu bug tracker isn't the worst thing in the world; I maintain the package in Debian and keep it up to date. Ubuntu then syncs the package from Debian. I monitor both bug trackers for bug reports and send any upstream. Best to send them directly upstream to linux-media@vger.kernel.org if you can manage it though :-) Unfortunately the tables in /usr/share/dvb are even more broken and I have no simple way of testing any patch, but I would suggest they could be auto-generated from the correct one we've just created. As you can see, it's not just the frequencies that are wrong, but FEC and MOD etc: $ cat /usr/share/dvb/dvb-t/uk-StocklandHill # UK, Stockland Hill # http://www.ukfree.tv/txdetail.php?a=ST222014 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 514167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # PSB1 T 490167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # PSB2 #T 538167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # PSB3 (DVB-T2) T 505833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # COM4 T 481833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # COM5 T 529833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # COM6 For what it's worth, here is the patch, untested. If you're happy with it, I'll certainly send it to linux-media@vger.kernel.org - your call. cheers, Adam -- 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/7] tuner-core: properly initialize media controller subdev
Hi Mauro,
Thank you for the patch.
On Saturday 03 January 2015 18:09:33 Mauro Carvalho Chehab wrote:
Properly initialize tuner core subdev at the media controller.
That requires a new subtype at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c index 559f8372e2eb..114715ed0110
100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -134,6 +134,9 @@ struct tuner {
unsigned inttype; /* chip type id */
void*config;
const char *name;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_padpad;
+#endif
I'm not too familiar with tuners, do they all have a single output only and no
input ?
};
/*
@@ -434,6 +437,8 @@ static void set_type(struct i2c_client *c, unsigned int
type, t-name = analog_ops-info.name;
}
+ t-sd.entity.name = t-name;
+
Entity information is not supposed to change at runtime, I'm not sure to be
comfortable with this change.
set_type() is called at probe time and in tuner_s_type_addr(). The former just
duplicates the name initialization in tuner_probe(), so isn't really needed.
The later bothers me.
tuner_dbg(type set to %s\n, t-name);
t-mode_mask = new_mode_mask;
@@ -592,6 +597,7 @@ static int tuner_probe(struct i2c_client *client,
struct tuner *t;
struct tuner *radio;
struct tuner *tv;
+ int ret;
t = kzalloc(sizeof(struct tuner), GFP_KERNEL);
if (NULL == t)
@@ -696,6 +702,15 @@ register_client:
t-type,
t-mode_mask T_RADIO ? Radio : ,
t-mode_mask T_ANALOG_TV ? TV : );
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ t-pad.flags = MEDIA_PAD_FL_SOURCE;
+ t-sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t-sd.entity.name = t-name;
v4l2_subdev_init(), called by v4l2_i2c_subdev_init(), sets sd-entity.name to
point to sd-name. Is there a reason why the subdev name can't be used as the
entity name ?
+
+ ret = media_entity_init(t-sd.entity, 1, t-pad, 0);
+ if (ret 0)
+ tuner_err(failed to initialize media entity!\n);
+#endif
return 0;
}
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 707db275f92b..5ffde035789b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -66,6 +66,8 @@ struct media_device_info {
/* A converter of analogue video to its digital representation. */
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER (MEDIA_ENT_T_V4L2_SUBDEV + 4)
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER(MEDIA_ENT_T_V4L2_SUBDEV + 5)
+
#define MEDIA_ENT_FL_DEFAULT (1 0)
struct media_entity_desc {
--
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: [PATCHv2 1/9] media: Fix DVB representation at media controller API
Em Sun, 11 Jan 2015 16:05:32 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Hi Mauro,
On Sunday 11 January 2015 11:58:24 Mauro Carvalho Chehab wrote:
Em Sun, 11 Jan 2015 15:50:04 +0200 Laurent Pinchart escreveu:
On Saturday 03 January 2015 12:49:03 Mauro Carvalho Chehab wrote:
The DVB devices are identified via a (major, minor) tuple,
and not by a random id. Fix it, before we start using it.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..de333cc8261b 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,7 +97,10 @@ struct media_entity {
u32 device;
u32 subdevice;
} alsa;
-int dvb;
+struct {
+u32 major;
+u32 minor;
+} dvb;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..7902e800f019 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -27,7 +27,7 @@
#include linux/types.h
#include linux/version.h
-#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 1)
struct media_device_info {
char driver[16];
@@ -88,7 +88,10 @@ struct media_entity_desc {
__u32 device;
__u32 subdevice;
} alsa;
-int dvb;
+struct {
+__u32 major;
+__u32 minor;
+} dvb;
Won't this break compilation of existing userspace code ? As DVB is not
properly supported in MC at the moment we could consider that only
mediactl will be affected, so it shouldn't be a big issue.
Well, media-ctl uses a local copy of the videodev2.h header, so it won't
break.
It's media.h, but you're correct here.
Ah, yes, that's what I meant ;)
Btw, I have also the patches adding support for DVB at v4l-utils:
http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-utils.git/log/?h=dvb-media-ctl
I'm not aware of any other application using MC for DVB.
Yet, imagining that such application exists, then, IMHO, it is better
to break compilation for it, as probably such application was written for
some OOT driver that might be using its own version of the media
controller implementation.
OK. I'll remember that argument the next time I want to break a kernel API
though ;-)
:)
Actually, we're not breaking the Kernel API here, as DVB support
inside the media controller were never added.
Next time, we should be sure to not add provision for an API at
the Kernel without actually implementing it ;)
Btw, eventually we'll end facing the very same issue when we
merge support for ALSA. IMHO, it is just easier to use major,minor
for all devnodes than to use anything else.
Yet, you're right: maybe we should do, instead:
union {
struct {
u32 major;
u32 minor;
} dev;
/* DEPRECATED: old node specifications */
struct {
u32 major;
u32 minor;
} v4l;
struct {
u32 major;
u32 minor;
} fb;
struct {
u32 card;
u32 device;
u32 subdevice;
} alsa;
int dvb;
/* Sub-device specifications */
/* Nothing needed yet */
} info;
And change media-ctl to use info.dev for all devnodes. This will
provide a fix when we add support for alsa devnodes too.
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
az6027.c:undefined reference to `stb0899_attach'
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 4850d37d3a7c049f7dc3eb09d7ae4e5553ac521b commit: 7b34be71db533f3e0cf93d53cf62d036cdb5418a [media] use IS_ENABLED() macro date: 1 year, 11 months ago config: i386-randconfig-ib1-01112037 (attached as .config) reproduce: git checkout 7b34be71db533f3e0cf93d53cf62d036cdb5418a # save the attached .config to linux build tree make ARCH=i386 All error/warnings: drivers/built-in.o: In function `tfe8096p_tuner_attach': dib0700_devices.c:(.text+0x26a7eb): undefined reference to `dib8096p_get_i2c_tuner' dib0700_devices.c:(.text+0x26a860): undefined reference to `dib8000_set_gpio' drivers/built-in.o: In function `dib80xx_tuner_sleep': dib0700_devices.c:(.text+0x26a904): undefined reference to `dib8000_set_gpio' drivers/built-in.o: In function `dib80xx_tuner_reset': dib0700_devices.c:(.text+0x26a92c): undefined reference to `dib8000_set_gpio' drivers/built-in.o: In function `dib8096p_agc_startup': dib0700_devices.c:(.text+0x26a9c4): undefined reference to `dib8000_set_wbd_ref' dib0700_devices.c:(.text+0x26aa2a): undefined reference to `dib8000_update_pll' dib0700_devices.c:(.text+0x26aa39): undefined reference to `dib8000_ctrl_timf' drivers/built-in.o: In function `dib8090_get_adc_power': dib0700_devices.c:(.text+0x26aa6e): undefined reference to `dib8000_get_adc_power' drivers/built-in.o: In function `tfe8096p_frontend_attach': dib0700_devices.c:(.text+0x26c1b7): undefined reference to `dib8000_i2c_enumeration' drivers/built-in.o: In function `stk809x_frontend_attach': dib0700_devices.c:(.text+0x26c357): undefined reference to `dib8000_i2c_enumeration' drivers/built-in.o: In function `stk807xpvr_frontend_attach1': dib0700_devices.c:(.text+0x26c446): undefined reference to `dib8000_i2c_enumeration' drivers/built-in.o: In function `stk807xpvr_frontend_attach0': dib0700_devices.c:(.text+0x26c607): undefined reference to `dib8000_i2c_enumeration' drivers/built-in.o: In function `stk807x_frontend_attach': dib0700_devices.c:(.text+0x26c7a7): undefined reference to `dib8000_i2c_enumeration' drivers/built-in.o: In function `nim8096md_tuner_attach': dib0700_devices.c:(.text+0x26d175): undefined reference to `dib8000_get_slave_frontend' dib0700_devices.c:(.text+0x26d1a5): undefined reference to `dib8000_get_i2c_master' dib0700_devices.c:(.text+0x26d236): undefined reference to `dib8000_get_i2c_master' drivers/built-in.o: In function `dib809x_tuner_attach': dib0700_devices.c:(.text+0x26d392): undefined reference to `dib8000_get_i2c_master' drivers/built-in.o: In function `dib807x_tuner_attach': dib0700_devices.c:(.text+0x26d4a2): undefined reference to `dib8000_get_i2c_master' drivers/built-in.o: In function `dib8096_set_param_override': dib0700_devices.c:(.text+0x26d74d): undefined reference to `dib8000_set_wbd_ref' dib0700_devices.c:(.text+0x26d80c): undefined reference to `dib8000_set_gpio' dib0700_devices.c:(.text+0x26d820): undefined reference to `dib8000_pwm_agc_reset' dib0700_devices.c:(.text+0x26d82c): undefined reference to `dib8000_set_tune_state' drivers/built-in.o: In function `nim8096md_frontend_attach': dib0700_devices.c:(.text+0x26d9c7): undefined reference to `dib8000_i2c_enumeration' dib0700_devices.c:(.text+0x26da8e): undefined reference to `dib8000_set_slave_frontend' dib0700_devices.c:(.text+0x26db55): undefined reference to `dib8000_set_slave_frontend' drivers/built-in.o: In function `dib807x_set_param_override': dib0700_devices.c:(.text+0x26dc28): undefined reference to `dib8000_set_wbd_ref' drivers/built-in.o: In function `stk80xx_pid_filter': dib0700_devices.c:(.text+0x26ddf2): undefined reference to `dib8000_pid_filter' drivers/built-in.o: In function `stk80xx_pid_filter_ctrl': dib0700_devices.c:(.text+0x26de15): undefined reference to `dib8000_pid_filter_ctrl' drivers/built-in.o: In function `az6027_frontend_attach': az6027.c:(.text+0x271b0b): undefined reference to `stb0899_attach' az6027.c:(.text+0x271bd8): undefined reference to `stb0899_attach' drivers/built-in.o:(.rodata+0x4f82c): undefined reference to `dib8096p_tuner_sleep' drivers/built-in.o:(.rodata+0x4f830): undefined reference to `dib8096p_tuner_sleep' --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.8.0-rc3 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_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y
Re: [PATCH 1/7] tuner-core: properly initialize media controller subdev
Em Sun, 11 Jan 2015 16:02:41 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Hi Mauro,
Thank you for the patch.
On Saturday 03 January 2015 18:09:33 Mauro Carvalho Chehab wrote:
Properly initialize tuner core subdev at the media controller.
That requires a new subtype at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c index 559f8372e2eb..114715ed0110
100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -134,6 +134,9 @@ struct tuner {
unsigned inttype; /* chip type id */
void*config;
const char *name;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_padpad;
+#endif
I'm not too familiar with tuners, do they all have a single output only and
no
input ?
They have an input: the antenna connector. However, I don't see any need
to map it for most tuners, as there's generally just one input, hardwired
into the tuner chip.
There are some hardware with 2 antenna connectors, but for different
functions (FM and TV). They're selected automatically when the V4L2
driver switches between FM and TV.
In any case, the tuner-core doesn't provide any way to select the
antenna input.
So, if a driver would need to select the input, it would either need
to not use tuner-core or some patch will be required to add such
functionality inside tuner-core.
};
/*
@@ -434,6 +437,8 @@ static void set_type(struct i2c_client *c, unsigned int
type, t-name = analog_ops-info.name;
}
+ t-sd.entity.name = t-name;
+
Entity information is not supposed to change at runtime, I'm not sure to be
comfortable with this change.
set_type() is called at probe time and in tuner_s_type_addr(). The former
just
duplicates the name initialization in tuner_probe(), so isn't really needed.
The later bothers me.
The tuner-core driver is a core subdev implementation. It handles
the ioctl logic, but the actual driver is a different one. It also
have internally a probe logic that will load the correct tuner subdev.
The tuner_s_type_addr() callback, used only at bridge probing time,
is a way for the bridge driver to provide the name of the tuner driver
that should be loaded, plus its I2C address.
So, once the board is probed, the name shouldn't change.
tuner_dbg(type set to %s\n, t-name);
t-mode_mask = new_mode_mask;
@@ -592,6 +597,7 @@ static int tuner_probe(struct i2c_client *client,
struct tuner *t;
struct tuner *radio;
struct tuner *tv;
+ int ret;
t = kzalloc(sizeof(struct tuner), GFP_KERNEL);
if (NULL == t)
@@ -696,6 +702,15 @@ register_client:
t-type,
t-mode_mask T_RADIO ? Radio : ,
t-mode_mask T_ANALOG_TV ? TV : );
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ t-pad.flags = MEDIA_PAD_FL_SOURCE;
+ t-sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t-sd.entity.name = t-name;
v4l2_subdev_init(), called by v4l2_i2c_subdev_init(), sets sd-entity.name to
point to sd-name. Is there a reason why the subdev name can't be used as the
entity name ?
If we don't set entity.name to t-name, the sd-name will be tuner-core,
instead of the name of the real subdev.
+
+ ret = media_entity_init(t-sd.entity, 1, t-pad, 0);
+ if (ret 0)
+ tuner_err(failed to initialize media entity!\n);
+#endif
return 0;
}
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 707db275f92b..5ffde035789b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -66,6 +66,8 @@ struct media_device_info {
/* A converter of analogue video to its digital representation. */
#define MEDIA_ENT_T_V4L2_SUBDEV_DECODER(MEDIA_ENT_T_V4L2_SUBDEV + 4)
+#define MEDIA_ENT_T_V4L2_SUBDEV_TUNER (MEDIA_ENT_T_V4L2_SUBDEV + 5)
+
#define MEDIA_ENT_FL_DEFAULT (1 0)
struct media_entity_desc {
--
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: [PATCHv3 01/20] media: add new types for DVB devnodes
Hi Mauro,
On Thursday 08 January 2015 15:44:50 Mauro Carvalho Chehab wrote:
Em Thu, 08 Jan 2015 18:10:13 +0200 Laurent Pinchart escreveu:
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
Mauro Carvalho Chehab wrote:
Most of the DVB subdevs have already their own devnode.
Add support for them at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..707db275f92b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_V4L(MEDIA_ENT_T_DEVNODE +
1)
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE + 8)
I'd create another type for the DVB sub-type devices, as there is for
V4L2 sub-devices. I wonder what Laurent thinks.
I discussed this quickly with Laurent on IRC.
There are some concept differences between V4L2 and DVB.
At v4l2:
- the spec is one monolitic header (videodev2.h);
- one devnode is used to control everyhing (/dev/video?)
- there is one v4l core for all types of devices
At DVB:
- each different DVB API has its own header;
- each DVB device type has its own core (ok, they're
linked into one module, but internally they're almost independent);
- each different DVB API has its own devnode.
So, using SUBDEV for DVB (or at least for the devnodes) don't
make much sense.
Ok, there are still some things at DVB side that could be mapped as
subdev. The clear example is the tuner. However, in this case, the
same tuner can be either V4L, DVB or both. So, we need to define just
one subdev type for the tuner.
Also, each DVB device can be identified via major/minor pairs.
I wrote already (and submitted upstream) the patches for media-ctl to
recognize them. They're also on my experimental v4l-utils tree:
http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-
utils.git/log/?h=dvb-media-ctl
As I've mentioned in a previous discussion, the media_entity type field is
too restrictive. Not only does this use case show that we need a type,
sub-type and sub-sub-type, there are also entities that implement several
distinct types. I thus believe we need a new ioctl is needed to expose
detailed information about entities. This topic has been discussed
numerous times in the past, it just requires someone to implement it.
I'm not opposed to a short-term solution like the one proposed here, but
maybe we should instead decide it's time to implement the new ioctl
instead.
Ok, so let's stick with it for DVB. At DVB side, I don't see a need for
sub-sub-type, especially since DVB has no subdevs (except for the shared
tuner between DVB and V4L). Everything there are devnodes, with their
functionality strictly following the documentation, as the API is fully
handled inside the DVB core[1].
At the moment the MC API has a devnode type with a DVB devnode subtype.
Splitting DVB devnodes into different categories effectively create sub-
subtypes. That's what bothers mode, the type field is becoming a ragbag.
Also, I don't want to mix adding DVB media controller support with the
addition of a new ioctl.
*If* we conclude that a new ioctl is needed to support DVB in a clean way, I
don't see why that new ioctl shouldn't be considered as a prerequisite.
[1] For the non-deprecated DVB devnodes. DVB have 3 devnode types that
are deprecated because they implement functionality found elsewhere
(video, audio and OSD dvb APIs). Only one legacy driver implements it,
and there's no plan to ever add media controller or expand/accept
new drivers using those legacy APIs.
--
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: [PATCHv3 01/20] media: add new types for DVB devnodes
Em Sun, 11 Jan 2015 15:54:14 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Hi Mauro,
On Thursday 08 January 2015 15:44:50 Mauro Carvalho Chehab wrote:
Em Thu, 08 Jan 2015 18:10:13 +0200 Laurent Pinchart escreveu:
On Wednesday 07 January 2015 12:22:39 Mauro Carvalho Chehab wrote:
Em Wed, 07 Jan 2015 16:09:04 +0200 Sakari Ailus escreveu:
Mauro Carvalho Chehab wrote:
Most of the DVB subdevs have already their own devnode.
Add support for them at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 7902e800f019..707db275f92b 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -50,7 +50,14 @@ struct media_device_info {
#define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE +
1)
#define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE +
2)
#define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3)
-#define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE +
4)
+#define MEDIA_ENT_T_DEVNODE_DVB_FE(MEDIA_ENT_T_DEVNODE + 4)
+#define MEDIA_ENT_T_DEVNODE_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
+#define MEDIA_ENT_T_DEVNODE_DVB_DVR (MEDIA_ENT_T_DEVNODE + 6)
+#define MEDIA_ENT_T_DEVNODE_DVB_CA(MEDIA_ENT_T_DEVNODE + 7)
+#define MEDIA_ENT_T_DEVNODE_DVB_NET (MEDIA_ENT_T_DEVNODE + 8)
I'd create another type for the DVB sub-type devices, as there is for
V4L2 sub-devices. I wonder what Laurent thinks.
I discussed this quickly with Laurent on IRC.
There are some concept differences between V4L2 and DVB.
At v4l2:
- the spec is one monolitic header (videodev2.h);
- one devnode is used to control everyhing (/dev/video?)
- there is one v4l core for all types of devices
At DVB:
- each different DVB API has its own header;
- each DVB device type has its own core (ok, they're
linked into one module, but internally they're almost independent);
- each different DVB API has its own devnode.
So, using SUBDEV for DVB (or at least for the devnodes) don't
make much sense.
Ok, there are still some things at DVB side that could be mapped as
subdev. The clear example is the tuner. However, in this case, the
same tuner can be either V4L, DVB or both. So, we need to define just
one subdev type for the tuner.
Also, each DVB device can be identified via major/minor pairs.
I wrote already (and submitted upstream) the patches for media-ctl to
recognize them. They're also on my experimental v4l-utils tree:
http://git.linuxtv.org/cgit.cgi/mchehab/experimental-v4l-
utils.git/log/?h=dvb-media-ctl
As I've mentioned in a previous discussion, the media_entity type field is
too restrictive. Not only does this use case show that we need a type,
sub-type and sub-sub-type, there are also entities that implement several
distinct types. I thus believe we need a new ioctl is needed to expose
detailed information about entities. This topic has been discussed
numerous times in the past, it just requires someone to implement it.
I'm not opposed to a short-term solution like the one proposed here, but
maybe we should instead decide it's time to implement the new ioctl
instead.
Ok, so let's stick with it for DVB. At DVB side, I don't see a need for
sub-sub-type, especially since DVB has no subdevs (except for the shared
tuner between DVB and V4L). Everything there are devnodes, with their
functionality strictly following the documentation, as the API is fully
handled inside the DVB core[1].
At the moment the MC API has a devnode type with a DVB devnode subtype.
Splitting DVB devnodes into different categories effectively create sub-
subtypes. That's what bothers mode, the type field is becoming a ragbag.
As I explained before, and more detailed at:
http://www.spinics.net/lists/linux-media/msg85229.html
DVB is actually 3 different APIs (demux, frontend and CA). Those APIs
are independent, and each have an independent devnode. The dvr is a
special case: it is a devnode that doesn't accept ioctl's. It is just
an output devnode, controlled vis the demux API.
The only thing in common to those 3 APIs is that they belong to the same
device type. But some may argue that, on an hybrid device, the input,
remote controller and even V4L2 are also sub-types.
In any case, they're all devnodes, so MEDIA_ENT_T_DEVNODE_foo fits well.
Also, I don't want to mix adding DVB media controller support with the
addition of a new ioctl.
*If* we conclude that a new ioctl is needed to support DVB in a clean way, I
don't see why that new ioctl shouldn't be considered as a prerequisite.
I don't see the need of a new ioctl for DVB. DVB is even simpler than V4L2,
as it doesn't have subdevs (except for tuner).
Re: [PATCHv2 1/9] media: Fix DVB representation at media controller API
Hi Mauro,
Thank you for the patch.
On Saturday 03 January 2015 12:49:03 Mauro Carvalho Chehab wrote:
The DVB devices are identified via a (major, minor) tuple,
and not by a random id. Fix it, before we start using it.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..de333cc8261b 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,7 +97,10 @@ struct media_entity {
u32 device;
u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ u32 major;
+ u32 minor;
+ } dvb;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..7902e800f019 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -27,7 +27,7 @@
#include linux/types.h
#include linux/version.h
-#define MEDIA_API_VERSIONKERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSIONKERNEL_VERSION(0, 1, 1)
struct media_device_info {
char driver[16];
@@ -88,7 +88,10 @@ struct media_entity_desc {
__u32 device;
__u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } dvb;
Won't this break compilation of existing userspace code ? As DVB is not
properly supported in MC at the moment we could consider that only mediactl
will be affected, so it shouldn't be a big issue.
/* Sub-device specifications */
/* Nothing needed yet */
--
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: [PATCHv2 1/9] media: Fix DVB representation at media controller API
Em Sun, 11 Jan 2015 15:50:04 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu:
Hi Mauro,
Thank you for the patch.
On Saturday 03 January 2015 12:49:03 Mauro Carvalho Chehab wrote:
The DVB devices are identified via a (major, minor) tuple,
and not by a random id. Fix it, before we start using it.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..de333cc8261b 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,7 +97,10 @@ struct media_entity {
u32 device;
u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ u32 major;
+ u32 minor;
+ } dvb;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..7902e800f019 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -27,7 +27,7 @@
#include linux/types.h
#include linux/version.h
-#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 1)
struct media_device_info {
char driver[16];
@@ -88,7 +88,10 @@ struct media_entity_desc {
__u32 device;
__u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } dvb;
Won't this break compilation of existing userspace code ? As DVB is not
properly supported in MC at the moment we could consider that only mediactl
will be affected, so it shouldn't be a big issue.
Well, media-ctl uses a local copy of the videodev2.h header, so it won't
break.
I'm not aware of any other application using MC for DVB.
Yet, imagining that such application exists, then, IMHO, it is better
to break compilation for it, as probably such application was written for
some OOT driver that might be using its own version of the media
controller implementation.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/9] media: Fix DVB representation at media controller API
Hi Mauro,
On Sunday 11 January 2015 11:58:24 Mauro Carvalho Chehab wrote:
Em Sun, 11 Jan 2015 15:50:04 +0200 Laurent Pinchart escreveu:
On Saturday 03 January 2015 12:49:03 Mauro Carvalho Chehab wrote:
The DVB devices are identified via a (major, minor) tuple,
and not by a random id. Fix it, before we start using it.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..de333cc8261b 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -97,7 +97,10 @@ struct media_entity {
u32 device;
u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ u32 major;
+ u32 minor;
+ } dvb;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index d847c760e8f0..7902e800f019 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -27,7 +27,7 @@
#include linux/types.h
#include linux/version.h
-#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 0)
+#define MEDIA_API_VERSION KERNEL_VERSION(0, 1, 1)
struct media_device_info {
char driver[16];
@@ -88,7 +88,10 @@ struct media_entity_desc {
__u32 device;
__u32 subdevice;
} alsa;
- int dvb;
+ struct {
+ __u32 major;
+ __u32 minor;
+ } dvb;
Won't this break compilation of existing userspace code ? As DVB is not
properly supported in MC at the moment we could consider that only
mediactl will be affected, so it shouldn't be a big issue.
Well, media-ctl uses a local copy of the videodev2.h header, so it won't
break.
It's media.h, but you're correct here.
I'm not aware of any other application using MC for DVB.
Yet, imagining that such application exists, then, IMHO, it is better
to break compilation for it, as probably such application was written for
some OOT driver that might be using its own version of the media
controller implementation.
OK. I'll remember that argument the next time I want to break a kernel API
though ;-)
--
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
[PATCH] [media] usb: pvrusb2: pvrusb2-hdw: Remove unused function
Remove the function pvr2_hdw_cmd_powerdown() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c |5 -
drivers/media/usb/pvrusb2/pvrusb2-hdw.h |3 ---
2 files changed, 8 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 9623b62..972fa23 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -4035,11 +4035,6 @@ int pvr2_hdw_cmd_powerup(struct pvr2_hdw *hdw)
}
-int pvr2_hdw_cmd_powerdown(struct pvr2_hdw *hdw)
-{
- return pvr2_issue_simple_cmd(hdw,FX2CMD_POWER_OFF);
-}
-
int pvr2_hdw_cmd_decoder_reset(struct pvr2_hdw *hdw)
{
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
index 4184707..b108aaf 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.h
@@ -271,9 +271,6 @@ int pvr2_hdw_cmd_deep_reset(struct pvr2_hdw *);
/* Execute simple reset command */
int pvr2_hdw_cmd_powerup(struct pvr2_hdw *);
-/* suspend */
-int pvr2_hdw_cmd_powerdown(struct pvr2_hdw *);
-
/* Order decoder to reset */
int pvr2_hdw_cmd_decoder_reset(struct pvr2_hdw *);
--
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
[PATCH v3] Fix ALSA and DVB representation at media controller API
The previous provision for DVB media controller support were to
define an ID (likely meaning the adapter number) for the DVB
devnodes.
This is just plain wrong. Just like V4L, DVB devices (and ALSA,
or whatever) are identified via a (major, minor) tuple.
This is enough to uniquely identify a devnode, no matter what
API it implements.
So, before we go too far, let's mark the old v4l, dvb and alsa
devnode info as deprecated, and just call it as dev.
As we don't want to break compilation on already existing apps,
let's just keep the old definitions as-is, adding a note that
those are deprecated at media-entity.h.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
-
Laurent,
If you accept this patch, I'll respin the DVB media controller series
accordingly, and add the missing bits for DVB media controller at
at the documentation.
Regards,
Mauro
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index e00459185d20..3c3d9d25eb2f 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -83,7 +83,16 @@ struct media_entity {
struct media_pipeline *pipe;/* Pipeline this entity belongs to. */
union {
- /* Node specifications */
+ /* For all devnode types */
+ struct {
+ u32 major;
+ u32 minor;
+ } dev;
+
+ /* Sub-device specifications */
+ /* Nothing needed yet */
+
+ /* DEPRECATED: Old node specifications */
struct {
u32 major;
u32 minor;
@@ -98,9 +107,6 @@ struct media_entity {
u32 subdevice;
} alsa;
int dvb;
-
- /* Sub-device specifications */
- /* Nothing needed yet */
} info;
};
--
2.1.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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Jan 12 04:00:08 CET 2015 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-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: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16-i686: ERRORS linux-3.17-i686: ERRORS linux-3.18-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17-x86_64: ERRORS linux-3.18-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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] [media] usb: as102: as10x_cmd_cfg: Remove unused function
Remove the function as10x_cmd_eLNA_change_mode() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/media/usb/as102/as10x_cmd.h |1 -
drivers/media/usb/as102/as10x_cmd_cfg.c | 49 ---
2 files changed, 50 deletions(-)
diff --git a/drivers/media/usb/as102/as10x_cmd.h
b/drivers/media/usb/as102/as10x_cmd.h
index e06b84e..d87fc2f 100644
--- a/drivers/media/usb/as102/as10x_cmd.h
+++ b/drivers/media/usb/as102/as10x_cmd.h
@@ -518,6 +518,5 @@ int as10x_cmd_get_context(struct as10x_bus_adapter_t *adap,
uint16_t tag,
uint32_t *pvalue);
-int as10x_cmd_eLNA_change_mode(struct as10x_bus_adapter_t *adap, uint8_t mode);
int as10x_context_rsp_parse(struct as10x_cmd_t *prsp, uint16_t proc_id);
#endif
diff --git a/drivers/media/usb/as102/as10x_cmd_cfg.c
b/drivers/media/usb/as102/as10x_cmd_cfg.c
index c87f2ca..74def1f 100644
--- a/drivers/media/usb/as102/as10x_cmd_cfg.c
+++ b/drivers/media/usb/as102/as10x_cmd_cfg.c
@@ -130,55 +130,6 @@ out:
}
/**
- * as10x_cmd_eLNA_change_mode - send eLNA change mode command to AS10x
- * @adap: pointer to AS10x bus adapter
- * @mode: mode selected:
- * - ON: 0x0 = eLNA always ON
- * - OFF : 0x1 = eLNA always OFF
- * - AUTO : 0x2 = eLNA follow hysteresis parameters
- * to be ON or OFF
- *
- * Return 0 on success or negative value in case of error.
- */
-int as10x_cmd_eLNA_change_mode(struct as10x_bus_adapter_t *adap, uint8_t mode)
-{
- int error;
- struct as10x_cmd_t *pcmd, *prsp;
-
- pcmd = adap-cmd;
- prsp = adap-rsp;
-
- /* prepare command */
- as10x_cmd_build(pcmd, (++adap-cmd_xid),
- sizeof(pcmd-body.cfg_change_mode.req));
-
- /* fill command */
- pcmd-body.cfg_change_mode.req.proc_id =
- cpu_to_le16(CONTROL_PROC_ELNA_CHANGE_MODE);
- pcmd-body.cfg_change_mode.req.mode = mode;
-
- /* send command */
- if (adap-ops-xfer_cmd) {
- error = adap-ops-xfer_cmd(adap, (uint8_t *) pcmd,
- sizeof(pcmd-body.cfg_change_mode.req)
- + HEADER_SIZE, (uint8_t *) prsp,
- sizeof(prsp-body.cfg_change_mode.rsp)
- + HEADER_SIZE);
- } else {
- error = AS10X_CMD_ERROR;
- }
-
- if (error 0)
- goto out;
-
- /* parse response */
- error = as10x_rsp_parse(prsp, CONTROL_PROC_ELNA_CHANGE_MODE_RSP);
-
-out:
- return error;
-}
-
-/**
* as10x_context_rsp_parse - Parse context command response
* @prsp: pointer to AS10x command response buffer
* @proc_id:id of the command
--
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
[PATCH 1/2] lgdt3305: we only need to pass state into lgdt3305_mpeg_mode_polarity()
From: Michael Ira Krufky mkru...@linuxtv.org
Signed-off-by: Michael Ira Krufky mkru...@linuxtv.org
---
drivers/media/dvb-frontends/lgdt3305.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb-frontends/lgdt3305.c
b/drivers/media/dvb-frontends/lgdt3305.c
index 92c891a..b42d649 100644
--- a/drivers/media/dvb-frontends/lgdt3305.c
+++ b/drivers/media/dvb-frontends/lgdt3305.c
@@ -236,12 +236,12 @@ static inline int lgdt3305_mpeg_mode(struct
lgdt3305_state *state,
return lgdt3305_set_reg_bit(state, LGDT3305_TP_CTRL_1, 5, mode);
}
-static int lgdt3305_mpeg_mode_polarity(struct lgdt3305_state *state,
- enum lgdt3305_tp_clock_edge edge,
- enum lgdt3305_tp_valid_polarity valid)
+static int lgdt3305_mpeg_mode_polarity(struct lgdt3305_state *state)
{
u8 val;
int ret;
+ enum lgdt3305_tp_clock_edge edge = state-cfg-tpclk_edge;
+ enum lgdt3305_tp_valid_polarity valid = state-cfg-tpvalid_polarity;
lg_dbg(edge = %d, valid = %d\n, edge, valid);
@@ -740,9 +740,7 @@ static int lgdt3304_set_parameters(struct dvb_frontend *fe)
goto fail;
/* lgdt3305_mpeg_mode_polarity calls lgdt3305_soft_reset */
- ret = lgdt3305_mpeg_mode_polarity(state,
- state-cfg-tpclk_edge,
- state-cfg-tpvalid_polarity);
+ ret = lgdt3305_mpeg_mode_polarity(state);
fail:
return ret;
}
@@ -806,9 +804,7 @@ static int lgdt3305_set_parameters(struct dvb_frontend *fe)
goto fail;
/* lgdt3305_mpeg_mode_polarity calls lgdt3305_soft_reset */
- ret = lgdt3305_mpeg_mode_polarity(state,
- state-cfg-tpclk_edge,
- state-cfg-tpvalid_polarity);
+ ret = lgdt3305_mpeg_mode_polarity(state);
fail:
return ret;
}
--
2.1.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
[PULL] git://git.linuxtv.org/mkrufky/dvb lgdt3305 - add support for fixed tp clock mode
The following changes since commit 427ae153c65ad7a08288d86baf99000569627d03: [media] bq/c-qcam, w9966, pms: move to staging in preparation for removal (2014-12-16 23:21:44 -0200) are available in the git repository at: git://git.linuxtv.org/mkrufky/dvb lgdt3305 for you to fetch changes up to 85796f7c9a2c59ebf5e8a94384fa827aa3ce3e98: lgdt3305: add support for fixed tp clock mode (2014-12-21 16:54:55 -0500) Michael Ira Krufky (2): lgdt3305: we only need to pass state into lgdt3305_mpeg_mode_polarity() lgdt3305: add support for fixed tp clock mode drivers/media/dvb-frontends/lgdt3305.c | 17 - drivers/media/dvb-frontends/lgdt3305.h | 6 ++ 2 files changed, 14 insertions(+), 9 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
[PATCH 2/2] lgdt3305: add support for fixed tp clock mode
From: Michael Ira Krufky mkru...@linuxtv.org
Add support for controlling TP clock mode for VSB and QAM annex-B/C mode.
Gated clock mode is the default value, and does not support QAM annex-C.
The patch enables setting this control to fixed clock mode.
Signed-off-by: Michael Ira Krufky mkru...@linuxtv.org
---
drivers/media/dvb-frontends/lgdt3305.c | 3 +++
drivers/media/dvb-frontends/lgdt3305.h | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/media/dvb-frontends/lgdt3305.c
b/drivers/media/dvb-frontends/lgdt3305.c
index b42d649..873c63a 100644
--- a/drivers/media/dvb-frontends/lgdt3305.c
+++ b/drivers/media/dvb-frontends/lgdt3305.c
@@ -241,6 +241,7 @@ static int lgdt3305_mpeg_mode_polarity(struct
lgdt3305_state *state)
u8 val;
int ret;
enum lgdt3305_tp_clock_edge edge = state-cfg-tpclk_edge;
+ enum lgdt3305_tp_clock_mode mode = state-cfg-tpclk_mode;
enum lgdt3305_tp_valid_polarity valid = state-cfg-tpvalid_polarity;
lg_dbg(edge = %d, valid = %d\n, edge, valid);
@@ -253,6 +254,8 @@ static int lgdt3305_mpeg_mode_polarity(struct
lgdt3305_state *state)
if (edge)
val |= 0x08;
+ if (mode)
+ val |= 0x40;
if (valid)
val |= 0x01;
diff --git a/drivers/media/dvb-frontends/lgdt3305.h
b/drivers/media/dvb-frontends/lgdt3305.h
index d9ab556..9c03e53 100644
--- a/drivers/media/dvb-frontends/lgdt3305.h
+++ b/drivers/media/dvb-frontends/lgdt3305.h
@@ -37,6 +37,11 @@ enum lgdt3305_tp_clock_edge {
LGDT3305_TPCLK_FALLING_EDGE = 1,
};
+enum lgdt3305_tp_clock_mode {
+ LGDT3305_TPCLK_GATED = 0,
+ LGDT3305_TPCLK_FIXED = 1,
+};
+
enum lgdt3305_tp_valid_polarity {
LGDT3305_TP_VALID_LOW = 0,
LGDT3305_TP_VALID_HIGH = 1,
@@ -70,6 +75,7 @@ struct lgdt3305_config {
enum lgdt3305_mpeg_mode mpeg_mode;
enum lgdt3305_tp_clock_edge tpclk_edge;
+ enum lgdt3305_tp_clock_mode tpclk_mode;
enum lgdt3305_tp_valid_polarity tpvalid_polarity;
enum lgdt_demod_chip_type demod_chip;
};
--
2.1.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
