Re: femon signal strength
On Wed, 26 Oct 2011 15:58:32 -0400 James bjloc...@lockie.ca wrote: On 10/26/11 15:49, Devin Heitmueller wrote: On Wed, Oct 26, 2011 at 3:45 PM, Jamesbjloc...@lockie.ca wrote: How many different formats are there (do I have to go through the archive)? Would it be feasable to change femon to handle different formats? There are three or four common formats, and there is no real way for an application to know which format was used unless it perhaps hard-codes some table of demodulator driver names into the source (which by the way will cause breakage if efforts are made to change the demods to use a common format). Devin I was thinking of a table. :-) How about adding switches to femon, it won't be automatic? I'm going to make femon work for my card, anyways. :-) This is no solution - drivers should be patched to deliver result in common format. femon is not the only application reading this values. And every application carrying its own set of correction tables doesn't help in any way. Shouldn't be to hard to agree on one scale and scale whatever value to that in reporting the signal strength. -- 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] Revert most of 15cc2bb [media] DVB: dtv_property_cache_submit shouldn't modifiy the cache
Hi,
I believe that I have found a problem with dtv_property_cache updating
when handling the legacy API. This was introduced between 2.6.39 and
3.0.
dtv_property_cache_submit() in dvb_frontend.c tests the field
delivery_system and if it's a legacy type (including SYS_UNDEFINED) then
it calls dtv_property_legacy_params_sync().
The original patch removed the assignment to delivery_system in this
function. However, the legacy API allows delivery_system to be
SYS_UNDEFINED - in fact is_legacy_delivery_system() tests for this
value.
If the delivery_system field is left as SYS_UNDEFINED then when tuning
is started, fe-ops.set_frontend() fails.
The current version of MythTV 0.24.1 is affected by this bug when using
a dvb-s2 card (tbs6981) tuned to a dvb-s channel.
Signed-off-by: Lawrence Rust l...@softsystem.co.uk
---
drivers/media/dvb/dvb-core/dvb_frontend.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 5b6b451..06c3975 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1076,7 +1076,7 @@ static void dtv_property_cache_sync(struct dvb_frontend
*fe,
*/
static void dtv_property_legacy_params_sync(struct dvb_frontend *fe)
{
- const struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
struct dvb_frontend_parameters *p = fepriv-parameters_in;
@@ -1088,12 +1088,14 @@ static void dtv_property_legacy_params_sync(struct
dvb_frontend *fe)
dprintk(%s() Preparing QPSK req\n, __func__);
p-u.qpsk.symbol_rate = c-symbol_rate;
p-u.qpsk.fec_inner = c-fec_inner;
+ c-delivery_system = SYS_DVBS;
break;
case FE_QAM:
dprintk(%s() Preparing QAM req\n, __func__);
p-u.qam.symbol_rate = c-symbol_rate;
p-u.qam.fec_inner = c-fec_inner;
p-u.qam.modulation = c-modulation;
+ c-delivery_system = SYS_DVBC_ANNEX_AC;
break;
case FE_OFDM:
dprintk(%s() Preparing OFDM req\n, __func__);
@@ -,10 +1113,15 @@ static void dtv_property_legacy_params_sync(struct
dvb_frontend *fe)
p-u.ofdm.transmission_mode = c-transmission_mode;
p-u.ofdm.guard_interval = c-guard_interval;
p-u.ofdm.hierarchy_information = c-hierarchy;
+ c-delivery_system = SYS_DVBT;
break;
case FE_ATSC:
dprintk(%s() Preparing VSB req\n, __func__);
p-u.vsb.modulation = c-modulation;
+ if ((c-modulation == VSB_8) || (c-modulation == VSB_16))
+ c-delivery_system = SYS_ATSC;
+ else
+ c-delivery_system = SYS_DVBC_ANNEX_B;
break;
}
}
--
1.7.4.1
--
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] Revert most of 15cc2bb [media] DVB: dtv_property_cache_submit shouldn't modifiy the cache
On 05.11.2011 16:19, Lawrence Rust wrote:
Hi,
I believe that I have found a problem with dtv_property_cache updating
when handling the legacy API. This was introduced between 2.6.39 and
3.0.
dtv_property_cache_submit() in dvb_frontend.c tests the field
delivery_system and if it's a legacy type (including SYS_UNDEFINED) then
it calls dtv_property_legacy_params_sync().
The original patch removed the assignment to delivery_system in this
function. However, the legacy API allows delivery_system to be
SYS_UNDEFINED - in fact is_legacy_delivery_system() tests for this
value.
If the delivery_system field is left as SYS_UNDEFINED then when tuning
is started, fe-ops.set_frontend() fails.
The current version of MythTV 0.24.1 is affected by this bug when using
a dvb-s2 card (tbs6981) tuned to a dvb-s channel.
How does MythTV set the parameters (i.e. using which interface, calls)?
If using S2API, it should also set DTV_DELIVERY_SYSTEM.
SYS_UNDEFINED get's set by dvb_frontend_clear_cache() only. I think it
would be better to call dtv_property_cache_init() from there to get rid
of it.
Signed-off-by: Lawrence Rust l...@softsystem.co.uk
---
drivers/media/dvb/dvb-core/dvb_frontend.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 5b6b451..06c3975 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1076,7 +1076,7 @@ static void dtv_property_cache_sync(struct dvb_frontend
*fe,
*/
static void dtv_property_legacy_params_sync(struct dvb_frontend *fe)
{
- const struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
struct dvb_frontend_parameters *p = fepriv-parameters_in;
@@ -1088,12 +1088,14 @@ static void dtv_property_legacy_params_sync(struct
dvb_frontend *fe)
dprintk(%s() Preparing QPSK req\n, __func__);
p-u.qpsk.symbol_rate = c-symbol_rate;
p-u.qpsk.fec_inner = c-fec_inner;
+ c-delivery_system = SYS_DVBS;
break;
case FE_QAM:
dprintk(%s() Preparing QAM req\n, __func__);
p-u.qam.symbol_rate = c-symbol_rate;
p-u.qam.fec_inner = c-fec_inner;
p-u.qam.modulation = c-modulation;
+ c-delivery_system = SYS_DVBC_ANNEX_AC;
break;
case FE_OFDM:
dprintk(%s() Preparing OFDM req\n, __func__);
@@ -,10 +1113,15 @@ static void dtv_property_legacy_params_sync(struct
dvb_frontend *fe)
p-u.ofdm.transmission_mode = c-transmission_mode;
p-u.ofdm.guard_interval = c-guard_interval;
p-u.ofdm.hierarchy_information = c-hierarchy;
+ c-delivery_system = SYS_DVBT;
break;
case FE_ATSC:
dprintk(%s() Preparing VSB req\n, __func__);
p-u.vsb.modulation = c-modulation;
+ if ((c-modulation == VSB_8) || (c-modulation == VSB_16))
+ c-delivery_system = SYS_ATSC;
+ else
+ c-delivery_system = SYS_DVBC_ANNEX_B;
break;
}
}
--
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] Revert most of 15cc2bb [media] DVB: dtv_property_cache_submit shouldn't modifiy the cache
On Sat, 2011-11-05 at 17:39 +0100, Andreas Oberritter wrote: [snip] How does MythTV set the parameters (i.e. using which interface, calls)? If using S2API, it should also set DTV_DELIVERY_SYSTEM. The following kern.log excerpt shows MythTV setting up the card: Nov 5 11:54:52 cyclops kernel: [ 4139.489804] dvb_frontend_ioctl (82) FE_SET_PROPERTY Nov 5 11:54:52 cyclops kernel: [ 4139.489806] dvb_frontend_ioctl_properties Nov 5 11:54:52 cyclops kernel: [ 4139.489808] dvb_frontend_ioctl_properties() properties.num = 1 Nov 5 11:54:52 cyclops kernel: [ 4139.489810] dvb_frontend_ioctl_properties() properties.props = bf95ec24 Nov 5 11:54:52 cyclops kernel: [ 4139.489813] dtv_property_dump() tvp.cmd= 0x0002 (DTV_CLEAR) Nov 5 11:54:52 cyclops kernel: [ 4139.489814] dtv_property_dump() tvp.u.data = 0xb7819a31 Nov 5 11:54:52 cyclops kernel: [ 4139.489816] dtv_property_process_set() Flushing property cache Nov 5 11:54:52 cyclops kernel: [ 4139.489841] dvb_frontend_ioctl (82) FE_SET_PROPERTY Nov 5 11:54:52 cyclops kernel: [ 4139.489842] dvb_frontend_ioctl_properties Nov 5 11:54:52 cyclops kernel: [ 4139.489843] dvb_frontend_ioctl_properties() properties.num = 7 Nov 5 11:54:52 cyclops kernel: [ 4139.489844] dvb_frontend_ioctl_properties() properties.props = 0a0acab0 Nov 5 11:54:52 cyclops kernel: [ 4139.489846] dtv_property_dump() tvp.cmd= 0x0011 (DTV_DELIVERY_SYSTEM) Nov 5 11:54:52 cyclops kernel: [ 4139.489848] dtv_property_dump() tvp.u.data = 0x Nov 5 11:54:52 cyclops kernel: [ 4139.489850] dtv_property_dump() tvp.cmd= 0x0003 (DTV_FREQUENCY) Nov 5 11:54:52 cyclops kernel: [ 4139.489851] dtv_property_dump() tvp.u.data = 0x0010104e Nov 5 11:54:52 cyclops kernel: [ 4139.489853] dtv_property_dump() tvp.cmd= 0x0004 (DTV_MODULATION) Nov 5 11:54:52 cyclops kernel: [ 4139.489854] dtv_property_dump() tvp.u.data = 0x Nov 5 11:54:52 cyclops kernel: [ 4139.489856] dtv_property_dump() tvp.cmd= 0x0006 (DTV_INVERSION) Nov 5 11:54:52 cyclops kernel: [ 4139.489857] dtv_property_dump() tvp.u.data = 0x0002 Nov 5 11:54:52 cyclops kernel: [ 4139.489859] dtv_property_dump() tvp.cmd= 0x0008 (DTV_SYMBOL_RATE) Nov 5 11:54:52 cyclops kernel: [ 4139.489860] dtv_property_dump() tvp.u.data = 0x014fb180 Nov 5 11:54:52 cyclops kernel: [ 4139.489861] dtv_property_dump() tvp.cmd= 0x0009 (DTV_INNER_FEC) Nov 5 11:54:52 cyclops kernel: [ 4139.489863] dtv_property_dump() tvp.u.data = 0x0009 Nov 5 11:54:52 cyclops kernel: [ 4139.489864] dtv_property_dump() tvp.cmd= 0x0001 (DTV_TUNE) Nov 5 11:54:52 cyclops kernel: [ 4139.489866] dtv_property_dump() tvp.u.data = 0x Nov 5 11:54:52 cyclops kernel: [ 4139.489867] dtv_property_process_set() Finalised property cache Nov 5 11:54:52 cyclops kernel: [ 4139.489869] dtv_property_cache_submit() legacy, modulation = 0 Nov 5 11:54:52 cyclops kernel: [ 4139.489870] dtv_property_legacy_params_sync() Preparing QPSK req Nov 5 11:54:52 cyclops kernel: [ 4139.489879] dvb_frontend_add_event Nov 5 11:54:52 cyclops kernel: [ 4139.489880] dvb_frontend_ioctl_properties() Property cache is full, tuning Nov 5 11:54:52 cyclops kernel: [ 4139.489897] dvb_frontend_thread: Frontend ALGO = DVBFE_ALGO_HW Nov 5 11:54:52 cyclops kernel: [ 4139.489899] dvb_frontend_poll Nov 5 11:54:52 cyclops kernel: [ 4139.489902] dvb_frontend_thread: Retune requested, FESTATE_RETUNE Nov 5 11:54:52 cyclops kernel: [ 4139.489903] dvb_frontend_ioctl (69) FE_READ_STATUS Nov 5 11:54:52 cyclops kernel: [ 4139.489907] TurboSight TBS 6981 Frontend: Nov 5 11:54:52 cyclops kernel: [ 4139.489907] tbs6981fe - delivery system 0 is not supported Note that DTV_DELIVERY_SYSTEM is set to 0 which worked OK in 2.6.39 SYS_UNDEFINED get's set by dvb_frontend_clear_cache() only. I think it would be better to call dtv_property_cache_init() from there to get rid of it. That doesn't fix this problem, which is explicitly setting DTV_DELIVERY_SYSTEM. A value of 0 (SYS_UNDEFINED) was accepted before this change and should continue to be accepted. In dtv_property_cache_submit the comment reads: /* For legacy delivery systems we don't need the delivery_system to * be specified, but we populate the older structures from the cache * so we can call set_frontend on older drivers. */ -- Lawrence -- 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] Revert most of 15cc2bb [media] DVB: dtv_property_cache_submit shouldn't modifiy the cache
On 05.11.2011 18:20, Lawrence Rust wrote: On Sat, 2011-11-05 at 17:39 +0100, Andreas Oberritter wrote: [snip] How does MythTV set the parameters (i.e. using which interface, calls)? If using S2API, it should also set DTV_DELIVERY_SYSTEM. The following kern.log excerpt shows MythTV setting up the card: Nov 5 11:54:52 cyclops kernel: [ 4139.489804] dvb_frontend_ioctl (82) FE_SET_PROPERTY Nov 5 11:54:52 cyclops kernel: [ 4139.489806] dvb_frontend_ioctl_properties Nov 5 11:54:52 cyclops kernel: [ 4139.489808] dvb_frontend_ioctl_properties() properties.num = 1 Nov 5 11:54:52 cyclops kernel: [ 4139.489810] dvb_frontend_ioctl_properties() properties.props = bf95ec24 Nov 5 11:54:52 cyclops kernel: [ 4139.489813] dtv_property_dump() tvp.cmd = 0x0002 (DTV_CLEAR) Nov 5 11:54:52 cyclops kernel: [ 4139.489814] dtv_property_dump() tvp.u.data = 0xb7819a31 Nov 5 11:54:52 cyclops kernel: [ 4139.489816] dtv_property_process_set() Flushing property cache Nov 5 11:54:52 cyclops kernel: [ 4139.489841] dvb_frontend_ioctl (82) FE_SET_PROPERTY Nov 5 11:54:52 cyclops kernel: [ 4139.489842] dvb_frontend_ioctl_properties Nov 5 11:54:52 cyclops kernel: [ 4139.489843] dvb_frontend_ioctl_properties() properties.num = 7 Nov 5 11:54:52 cyclops kernel: [ 4139.489844] dvb_frontend_ioctl_properties() properties.props = 0a0acab0 Nov 5 11:54:52 cyclops kernel: [ 4139.489846] dtv_property_dump() tvp.cmd = 0x0011 (DTV_DELIVERY_SYSTEM) Nov 5 11:54:52 cyclops kernel: [ 4139.489848] dtv_property_dump() tvp.u.data = 0x Nov 5 11:54:52 cyclops kernel: [ 4139.489850] dtv_property_dump() tvp.cmd = 0x0003 (DTV_FREQUENCY) Nov 5 11:54:52 cyclops kernel: [ 4139.489851] dtv_property_dump() tvp.u.data = 0x0010104e Nov 5 11:54:52 cyclops kernel: [ 4139.489853] dtv_property_dump() tvp.cmd = 0x0004 (DTV_MODULATION) Nov 5 11:54:52 cyclops kernel: [ 4139.489854] dtv_property_dump() tvp.u.data = 0x Nov 5 11:54:52 cyclops kernel: [ 4139.489856] dtv_property_dump() tvp.cmd = 0x0006 (DTV_INVERSION) Nov 5 11:54:52 cyclops kernel: [ 4139.489857] dtv_property_dump() tvp.u.data = 0x0002 Nov 5 11:54:52 cyclops kernel: [ 4139.489859] dtv_property_dump() tvp.cmd = 0x0008 (DTV_SYMBOL_RATE) Nov 5 11:54:52 cyclops kernel: [ 4139.489860] dtv_property_dump() tvp.u.data = 0x014fb180 Nov 5 11:54:52 cyclops kernel: [ 4139.489861] dtv_property_dump() tvp.cmd = 0x0009 (DTV_INNER_FEC) Nov 5 11:54:52 cyclops kernel: [ 4139.489863] dtv_property_dump() tvp.u.data = 0x0009 Nov 5 11:54:52 cyclops kernel: [ 4139.489864] dtv_property_dump() tvp.cmd = 0x0001 (DTV_TUNE) Nov 5 11:54:52 cyclops kernel: [ 4139.489866] dtv_property_dump() tvp.u.data = 0x Nov 5 11:54:52 cyclops kernel: [ 4139.489867] dtv_property_process_set() Finalised property cache Nov 5 11:54:52 cyclops kernel: [ 4139.489869] dtv_property_cache_submit() legacy, modulation = 0 Nov 5 11:54:52 cyclops kernel: [ 4139.489870] dtv_property_legacy_params_sync() Preparing QPSK req Nov 5 11:54:52 cyclops kernel: [ 4139.489879] dvb_frontend_add_event Nov 5 11:54:52 cyclops kernel: [ 4139.489880] dvb_frontend_ioctl_properties() Property cache is full, tuning Nov 5 11:54:52 cyclops kernel: [ 4139.489897] dvb_frontend_thread: Frontend ALGO = DVBFE_ALGO_HW Nov 5 11:54:52 cyclops kernel: [ 4139.489899] dvb_frontend_poll Nov 5 11:54:52 cyclops kernel: [ 4139.489902] dvb_frontend_thread: Retune requested, FESTATE_RETUNE Nov 5 11:54:52 cyclops kernel: [ 4139.489903] dvb_frontend_ioctl (69) FE_READ_STATUS Nov 5 11:54:52 cyclops kernel: [ 4139.489907] TurboSight TBS 6981 Frontend: Nov 5 11:54:52 cyclops kernel: [ 4139.489907] tbs6981fe - delivery system 0 is not supported Note that DTV_DELIVERY_SYSTEM is set to 0 which worked OK in 2.6.39 SYS_UNDEFINED get's set by dvb_frontend_clear_cache() only. I think it would be better to call dtv_property_cache_init() from there to get rid of it. That doesn't fix this problem, which is explicitly setting DTV_DELIVERY_SYSTEM. A value of 0 (SYS_UNDEFINED) was accepted before this change and should continue to be accepted. I don't get how this could be useful. MythTV knows what delivery system it wants to use, so it should pass this information to the kernel. Trying to set an invalid delivery system must fail. Using SYS_UNDEFINED as a pre-set default is different from setting SYS_UNDEFINED from userspace, which should always generate an error IMO, unless this is documented otherwise in the API specification. Regards, Andreas In dtv_property_cache_submit the comment reads: /* For legacy delivery systems we don't need the delivery_system to * be specified, but we populate the older structures from the cache * so we can call set_frontend on older drivers. */ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message
Re: [PATCH] Revert most of 15cc2bb [media] DVB: dtv_property_cache_submit shouldn't modifiy the cache
On Sat, 2011-11-05 at 18:38 +0100, Andreas Oberritter wrote: [snip] I don't get how this could be useful. MythTV knows what delivery system it wants to use, so it should pass this information to the kernel. Trying to set an invalid delivery system must fail. Using SYS_UNDEFINED as a pre-set default is different from setting SYS_UNDEFINED from userspace, which should always generate an error IMO, unless this is documented otherwise in the API specification. It's not ideal that MythTV is setting DTV_DELIVERY_SYSTEM to 0 and I have filed a bug against this. But that doesn't change the fact that the original patch significantly changed user parameter handling for no significant benefit. MythTV is probably the biggest client of v4l and will greatly hinder users upgrading to (Myth)Ubuntu 12.04 or Fedora 16 both of which use Linux 3.x. -- Lawrence -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Nov 5 19:00:17 CET 2011 git hash:31cea59efb3a4210c063f31c061ebcaff833f583 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification 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: fix truncated entity specification
When enumerating an entity, assign the entire entity specification
instead of only the first two words. (This requires giving the
specification union a name.)
So far, no driver actually uses more than two words, but this will
be needed for ALSA entities.
Signed-off-by: Clemens Ladisch clem...@ladisch.de
---
include/media/media-entity.h |2 +-
drivers/media/media-device.c |3 +--
drivers/media/video/v4l2-dev.c|4 ++--
drivers/media/video/v4l2-device.c |4 ++--
4 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index cd8bca6..d13de27 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -98,7 +98,7 @@ struct media_entity {
/* Sub-device specifications */
/* Nothing needed yet */
- };
+ } specification;
};
static inline u32 media_entity_type(struct media_entity *entity)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 16b70b4..bfb4e0b 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -107,8 +107,7 @@ static long media_device_enum_entities(struct media_device
*mdev,
u_ent.group_id = ent-group_id;
u_ent.pads = ent-num_pads;
u_ent.links = ent-num_links - ent-num_backlinks;
- u_ent.v4l.major = ent-v4l.major;
- u_ent.v4l.minor = ent-v4l.minor;
+ memcpy(u_ent.v4l, ent-specification, sizeof(ent-specification));
if (copy_to_user(uent, u_ent, sizeof(u_ent)))
return -EFAULT;
return 0;
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index a5c9ed1..1eb9ba1 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -703,8 +703,8 @@ int __video_register_device(struct video_device *vdev, int
type, int nr,
vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
- vdev-entity.v4l.major = VIDEO_MAJOR;
- vdev-entity.v4l.minor = vdev-minor;
+ vdev-entity.specification.v4l.major = VIDEO_MAJOR;
+ vdev-entity.specification.v4l.minor = vdev-minor;
ret = media_device_register_entity(vdev-v4l2_dev-mdev,
vdev-entity);
if (ret 0)
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index e6a2c3b..d8f58d8 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -217,8 +217,8 @@ int v4l2_device_register_subdev_nodes(struct v4l2_device
*v4l2_dev)
if (err 0)
return err;
#if defined(CONFIG_MEDIA_CONTROLLER)
- sd-entity.v4l.major = VIDEO_MAJOR;
- sd-entity.v4l.minor = vdev-minor;
+ sd-entity.specification.v4l.major = VIDEO_MAJOR;
+ sd-entity.specification.v4l.minor = vdev-minor;
#endif
}
return 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
