Re: [PATCH] dvb_frontend: fix typos in comments and one function
Hi Steven, This and your other two patches are in http://www.kernellabs.com/hg/~stoth/saa7164-dev They look good to me. What is the proper process to see the patches accepted and integrated ? I want to be aligned with the way of working before sending other corrections or improvements. Thanks. -- Guillaume -- 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] dvb_frontend: fix typos in comments and one function
Hello,
Trivial patch for typos.
Signed-off-by: Guillaume Audirac guillaume.audi...@webag.fr
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 55ea260..e12a0f9 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -460,7 +460,7 @@ static void dvb_frontend_swzigzag(struct dvb_frontend
*fe)
if ((fepriv-state FESTATE_SEARCHING_FAST) || (fepriv-state
FESTATE_RETUNE)) {
fepriv-delay = fepriv-min_delay;
- /* peform a tune */
+ /* perform a tune */
retval = dvb_frontend_swzigzag_autotune(fe,
fepriv-check_wrapped);
if (retval 0) {
@@ -783,7 +783,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
return 0;
}
-static void dvb_frontend_get_frequeny_limits(struct dvb_frontend *fe,
+static void dvb_frontend_get_frequency_limits(struct dvb_frontend *fe,
u32 *freq_min, u32 *freq_max)
{
*freq_min = max(fe-ops.info.frequency_min,
fe-ops.tuner_ops.info.frequency_min);
@@ -807,7 +807,7 @@ static int dvb_frontend_check_parameters(struct
dvb_frontend *fe,
u32 freq_max;
/* range check: frequency */
- dvb_frontend_get_frequeny_limits(fe, freq_min, freq_max);
+ dvb_frontend_get_frequency_limits(fe, freq_min, freq_max);
if ((freq_min parms-frequency freq_min) ||
(freq_max parms-frequency freq_max)) {
printk(KERN_WARNING DVB: adapter %i frontend %i frequency %u
out of
range (%u..%u)\n,
@@ -1620,7 +1620,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
*inode, struct file *file,
case FE_GET_INFO: {
struct dvb_frontend_info* info = parg;
memcpy(info, fe-ops.info, sizeof(struct dvb_frontend_info));
- dvb_frontend_get_frequeny_limits(fe, info-frequency_min,
info-frequency_max);
+ dvb_frontend_get_frequency_limits(fe, info-frequency_min,
info-frequency_max);
/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
* do it, it is done for it. */
@@ -1719,7 +1719,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
*inode, struct file *file,
* (stv0299 for instance) take longer than 8msec to
* respond to a set_voltage command. Those switches
* need custom routines to switch properly. For all
-* other frontends, the following shoule work ok.
+* other frontends, the following should work ok.
* Dish network legacy switches (as used by Dish500)
* are controlled by sending 9-bit command words
* spaced 8msec apart.
--
1.6.3.3
--
Guillaume
--
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] dvb_frontend: fix typos in comments and one function
On Thu, May 6, 2010 at 8:30 AM, Guillaume Audirac guillaume.audi...@webag.fr wrote: Hello, Trivial patch for typos. Thanks Guillaume. I've had an open TDA10048 bug on my list for quite a while, I think you've already made reference to this in an earlier email. Essentially I'm told my a number of Australian users that the 10048 isn't broad-locking when tuned +- 167Khz away from the carrier, which it should definitely do. If you're in the mood for patching the 10048 and want to find and flip the broad-locking bit then I'd be certainly thrilled to test this. :) Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb_frontend: fix typos in comments and one function
Hello Steven, I've had an open TDA10048 bug on my list for quite a while, I think you've already made reference to this in an earlier email. Essentially I'm told my a number of Australian users that the 10048 isn't broad-locking when tuned +- 167Khz away from the carrier, which it should definitely do. If you're in the mood for patching the 10048 and want to find and flip the broad-locking bit then I'd be certainly thrilled to test this. :) Well, this is an interesting subject and there is a lot to say. Sorry in advance if you already know what I will explain: - the channel distribution is usually well known in DVB-T. For example, from 474MHz to 858MHz in UHF/8MHz. This channel distribution depends on each country. - due to the existing analogue channels, some FIXED frequency offsets have been introduced here and there to move the DVB-T channel away from the analogue channels depending on how critical it can be. These frequency offsets are commonly +/-166KHz everywhere, except in France (+/-N*166KHz with N=1,2,3) and in Australia (+/-125KHz) as far as I know. - hence the DVB-T channel can be shifted in IF by +/-125KHz, +/-166KHz, +/-333KHz, +/-500KHz. The channel decoder will or will not recover such an offset depending on the strategy. If it can lock, the IF signal will be partially filtered out by the IF filter and this impacts the performance. The best approach is to detect the potential frequency offset and re-program the tuner to the new frequency. Now about the TDA10048: - it naturally recovers the small offsets during the lock (error returned in FREQERR_R at 0x28 0x29): in 8MHz: +/-93KHz in 7MHz: +/-82KHz in 6MHz: +/-70KHz - the AUTOOFFSET bit allows to detect the fixed frequency offset whose value is returned in OFFSET_F (in 0x14) when there is no lock. If an offset is detected, it is applied to the tuner, then AUTOOFFSET is set to 0 and the acquisition is checked again. This is the normal and preferred way. The non-recommended option is to force the lock when a fixed offset is detected without reprogramming the tuner. This is possible only with certain firmware versions (=0x34), in forcing 1 in register 0x19[0], the fixed offset will still be available in OFFSET_F after the lock. For earlier firmware versions, the 0x19[0] bit has no effect. Ideally, for the channel demodulator driver, the API should provide an interface to set the frequency offset recovery (AUTO, NONE...) and to get the detected frequency offset if any. -- Guillaume -- 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
