Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Oliver Endriss wrote: Manu Abraham wrote: On 8/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Ideally, what's provided by the demod and not the tuner max/min. The tuners max/min should be checked by the demod on setting params. The upper/lower limits in the demodulator drivers, came from the concept of a frontend as a whole. Independant bounds do not make sense (except internally -- It is the demod driver that which sets parameters for the tuner. The external world doesn't need to know what's the limit of the tuner, but only of the frontend as a whole). Ideally, the demodulator should just demodulate only. There are some cases, there are some cases which are not. Ok, I'm trying to put all pieces together: There might be cases where demod and tuner have different limits. So FE_GET_INFO and dvb_frontend_check_parameters() should use the 'smallest common bandwidth': freq_min = max(fe-ops.info.frequency_min, fe-ops.tuner_ops.info.frequency_min); if (fe-ops.info.frequency_max == 0) freq_max = fe-ops.tuner_ops.info.frequency_max; else if (fe-ops.tuner_ops.info.frequency_max == 0) freq_max = fe-ops.info.frequency_max; else freq_max = min(fe-ops.info.frequency_max, fe-ops.tuner_ops.info.frequency_max); if (freq_min == 0 || freq_max == 0) printk(KERN_WARNING frequency limits undefined - please fix the driver\n); Conclusions: - A tuner-only driver must set fe-ops.tuner_ops.info. - Monolithic drivers must set fe-ops.tuner_ops.info or fe-ops.info (or both). I apologize for my delayed response -- I had to leave town unexpectedly. No problem. The above is OK with me. As I understand it, we cannot remove fe-ops.info.frequency_max|min because it is part of the userspace API. I wasn't thinking about that fact when I wrote my last email in this thread. We should keep this in mind, for whenever the time comes that we do have to break API compat. Basically, the internal data structures don't have to be the same as the external API data structures. The GET_INFO ioctl might collect its data from anywhere... I think we should postpone cleaning-up the frontend data until multiproto has been merged. It will add more compatibility stuff, so it might be worth cleaning up these things afterwards. For now I have committed Hartmut's patch and the fix above. CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On 8/8/07, Oliver Endriss [EMAIL PROTECTED] wrote: Manu Abraham wrote: On 8/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Ideally, what's provided by the demod and not the tuner max/min. The tuners max/min should be checked by the demod on setting params. The upper/lower limits in the demodulator drivers, came from the concept of a frontend as a whole. Independant bounds do not make sense (except internally -- It is the demod driver that which sets parameters for the tuner. The external world doesn't need to know what's the limit of the tuner, but only of the frontend as a whole). Ideally, the demodulator should just demodulate only. There are some cases, there are some cases which are not. Ok, I'm trying to put all pieces together: There might be cases where demod and tuner have different limits. So FE_GET_INFO and dvb_frontend_check_parameters() should use the 'smallest common bandwidth': freq_min = max(fe-ops.info.frequency_min, fe-ops.tuner_ops.info.frequency_min); if (fe-ops.info.frequency_max == 0) freq_max = fe-ops.tuner_ops.info.frequency_max; else if (fe-ops.tuner_ops.info.frequency_max == 0) freq_max = fe-ops.info.frequency_max; else freq_max = min(fe-ops.info.frequency_max, fe-ops.tuner_ops.info.frequency_max); if (freq_min == 0 || freq_max == 0) printk(KERN_WARNING frequency limits undefined - please fix the driver\n); Conclusions: - A tuner-only driver must set fe-ops.tuner_ops.info. - Monolithic drivers must set fe-ops.tuner_ops.info or fe-ops.info (or both). Ok? Currently, with our status that's the best we can do. Probably, we can hope to have better drivers in the future. Regards, manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Oliver Endriss wrote: Manu Abraham wrote: On 8/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Ideally, what's provided by the demod and not the tuner max/min. The tuners max/min should be checked by the demod on setting params. The upper/lower limits in the demodulator drivers, came from the concept of a frontend as a whole. Independant bounds do not make sense (except internally -- It is the demod driver that which sets parameters for the tuner. The external world doesn't need to know what's the limit of the tuner, but only of the frontend as a whole). Ideally, the demodulator should just demodulate only. There are some cases, there are some cases which are not. Ok, I'm trying to put all pieces together: There might be cases where demod and tuner have different limits. So FE_GET_INFO and dvb_frontend_check_parameters() should use the 'smallest common bandwidth': freq_min = max(fe-ops.info.frequency_min, fe-ops.tuner_ops.info.frequency_min); if (fe-ops.info.frequency_max == 0) freq_max = fe-ops.tuner_ops.info.frequency_max; else if (fe-ops.tuner_ops.info.frequency_max == 0) freq_max = fe-ops.info.frequency_max; else freq_max = min(fe-ops.info.frequency_max, fe-ops.tuner_ops.info.frequency_max); if (freq_min == 0 || freq_max == 0) printk(KERN_WARNING frequency limits undefined - please fix the driver\n); Conclusions: - A tuner-only driver must set fe-ops.tuner_ops.info. - Monolithic drivers must set fe-ops.tuner_ops.info or fe-ops.info (or both). I apologize for my delayed response -- I had to leave town unexpectedly. The above is OK with me. As I understand it, we cannot remove fe-ops.info.frequency_max|min because it is part of the userspace API. I wasn't thinking about that fact when I wrote my last email in this thread. We should keep this in mind, for whenever the time comes that we do have to break API compat. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On 8/9/07, Michael Krufky [EMAIL PROTECTED] wrote: I apologize for my delayed response -- I had to leave town unexpectedly. The above is OK with me. As I understand it, we cannot remove fe-ops.info.frequency_max|min because it is part of the userspace API. I wasn't thinking about that fact when I wrote my last email in this thread. We should keep this in mind, for whenever the time comes that we do have to break API compat. That one (the frontend definition) is still needed. The max/min in the tuner is the one that which is redundant for the moment (It would be needed internally though, for better drivers). Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Manu Abraham wrote: On 8/9/07, Michael Krufky [EMAIL PROTECTED] wrote: I apologize for my delayed response -- I had to leave town unexpectedly. The above is OK with me. As I understand it, we cannot remove fe-ops.info.frequency_max|min because it is part of the userspace API. I wasn't thinking about that fact when I wrote my last email in this thread. We should keep this in mind, for whenever the time comes that we do have to break API compat. That one (the frontend definition) is still needed. The max/min in the tuner is the one that which is redundant for the moment (It would be needed internally though, for better drivers). OK. In that case, what Oliver has proposed seems completely appropriate. Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On 8/9/07, Michael Krufky [EMAIL PROTECTED] wrote: Manu Abraham wrote: On 8/9/07, Michael Krufky [EMAIL PROTECTED] wrote: I apologize for my delayed response -- I had to leave town unexpectedly. The above is OK with me. As I understand it, we cannot remove fe-ops.info.frequency_max|min because it is part of the userspace API. I wasn't thinking about that fact when I wrote my last email in this thread. We should keep this in mind, for whenever the time comes that we do have to break API compat. That one (the frontend definition) is still needed. The max/min in the tuner is the one that which is redundant for the moment (It would be needed internally though, for better drivers). OK. In that case, what Oliver has proposed seems completely appropriate. See the other mail what i wrote, in reply to Oliver: Currently, with our status that's the best we can do. Probably, we can hope to have better drivers in the future. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky mkrufky at linuxtv.org writes: ...snip... That's fine with me... except I just don't see why we shouldn't just have the demod drivers that have the integrated tuning functionality just fill tuner_ops.info.frequency_max|min anyway. The point is, the structures will be present regardless of whether any tuner_ops are actually filled. This is an opportunity to remove the frequency_min|max from the demod ops.info structure, as we all agree that it is inappropriate there anyhow. If we do this, then we will have a standard across the board. Regards, Mike Having looked around for such information myself, it would possibly help consistency of tuner/demod/demux drivers if there was a standard/'best practice' for implementing such software, giving the decision points based on the actual device(s) features, reflecting into implemented code. e.g. if the device is a tuner: - create this file (from a template ?) - fill in these structure fields based on xxx values - write these functions - add these Kconfig settings ... This would ensure in the current case that there is no misunderstanding about the roles of different, possibly duplicated, fields, and which has precedence. Also when to specifically use a tuner or frontend structure. Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Oliver Endriss schrieb: e9hack wrote: Currently, I'm missing something in the tuner modules (and I didn't ask for it). It isn't possible to wait for getting the pll lock. The tuning function of the TT-C2300 does wait. It isn't possible to switch the time constant of the loop filter after getting the lock. Usually, it is recommended for any pll chips. Have a look how I implemented that in the tda10086 driver (search for 'has_lock'). The lock of the tuner pll has nothing to do with the lock of the demodulator. The TT-C2300 uses a very simple pll chip (TDA6405). Usually, it can use the simple pll (dvb-pll.c), but it must wait for the lock, because the tuning is very slow (50..150ms). I don't see any benefit, if the tuning code is moved from one file to another new one. - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Manu Abraham wrote: On 8/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Ideally, what's provided by the demod and not the tuner max/min. The tuners max/min should be checked by the demod on setting params. The upper/lower limits in the demodulator drivers, came from the concept of a frontend as a whole. Independant bounds do not make sense (except internally -- It is the demod driver that which sets parameters for the tuner. The external world doesn't need to know what's the limit of the tuner, but only of the frontend as a whole). Ideally, the demodulator should just demodulate only. There are some cases, there are some cases which are not. Ok, I'm trying to put all pieces together: There might be cases where demod and tuner have different limits. So FE_GET_INFO and dvb_frontend_check_parameters() should use the 'smallest common bandwidth': freq_min = max(fe-ops.info.frequency_min, fe-ops.tuner_ops.info.frequency_min); if (fe-ops.info.frequency_max == 0) freq_max = fe-ops.tuner_ops.info.frequency_max; else if (fe-ops.tuner_ops.info.frequency_max == 0) freq_max = fe-ops.info.frequency_max; else freq_max = min(fe-ops.info.frequency_max, fe-ops.tuner_ops.info.frequency_max); if (freq_min == 0 || freq_max == 0) printk(KERN_WARNING frequency limits undefined - please fix the driver\n); Conclusions: - A tuner-only driver must set fe-ops.tuner_ops.info. - Monolithic drivers must set fe-ops.tuner_ops.info or fe-ops.info (or both). Ok? CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Hi,
the min frequencies of the DVB-C frontends are wrong. In Europe, the center
frequency of the lowest
channel is 50.5MHz and not 51MHz. All known cards with the
stv0297/tda0002x/ves1820 frontend are
able to tune to this frequency. I've changed the range to the lowest channel -
1/2 bandwidth and the
highest channel + 1/2 bandwidth. For the design of the dvb driver, the
frequency ranges must be part
of the tuner and not of the frontend itself. The same frontend may be used for
different tuners. The
attached patch does only fix the ranges and not the design.
- Hartmut
Signed-off-by: Hartmut Birr [EMAIL PROTECTED]
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/stv0297.c
--- a/linux/drivers/media/dvb/frontends/stv0297.c Fri Aug 03 18:42:33 2007 -0300
+++ b/linux/drivers/media/dvb/frontends/stv0297.c Mon Aug 06 19:14:31 2007 +0200
@@ -680,8 +680,8 @@ static struct dvb_frontend_ops stv0297_o
.info = {
.name = ST STV0297 DVB-C,
.type = FE_QAM,
- .frequency_min = 6400,
- .frequency_max = 13,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.frequency_stepsize = 62500,
.symbol_rate_min = 87,
.symbol_rate_max = 1170,
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/tda10021.c
--- a/linux/drivers/media/dvb/frontends/tda10021.c Fri Aug 03 18:42:33 2007 -0300
+++ b/linux/drivers/media/dvb/frontends/tda10021.c Mon Aug 06 19:14:31 2007 +0200
@@ -439,8 +439,8 @@ static struct dvb_frontend_ops tda10021_
.name = Philips TDA10021 DVB-C,
.type = FE_QAM,
.frequency_stepsize = 62500,
- .frequency_min = 5100,
- .frequency_max = 85800,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.symbol_rate_min = (XIN/2)/64, /* SACLK/64 == (XIN/2)/64 */
.symbol_rate_max = (XIN/2)/4, /* SACLK/4 */
#if 0 /* keep */
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/tda10023.c
--- a/linux/drivers/media/dvb/frontends/tda10023.c Fri Aug 03 18:42:33 2007 -0300
+++ b/linux/drivers/media/dvb/frontends/tda10023.c Mon Aug 06 19:14:31 2007 +0200
@@ -504,8 +504,8 @@ static struct dvb_frontend_ops tda10023_
.name = Philips TDA10023 DVB-C,
.type = FE_QAM,
.frequency_stepsize = 62500,
- .frequency_min = 5100,
- .frequency_max = 85800,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.symbol_rate_min = (SYSCLK/2)/64, /* SACLK/64 == (SYSCLK/2)/64 */
.symbol_rate_max = (SYSCLK/2)/4, /* SACLK/4 */
#if 0
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/ves1820.c
--- a/linux/drivers/media/dvb/frontends/ves1820.c Fri Aug 03 18:42:33 2007 -0300
+++ b/linux/drivers/media/dvb/frontends/ves1820.c Mon Aug 06 19:14:31 2007 +0200
@@ -410,8 +410,8 @@ static struct dvb_frontend_ops ves1820_o
.name = VLSI VES1820 DVB-C,
.type = FE_QAM,
.frequency_stepsize = 62500,
- .frequency_min = 5100,
- .frequency_max = 85800,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.caps = FE_CAN_QAM_16 |
FE_CAN_QAM_32 |
FE_CAN_QAM_64 |
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
e9hack wrote:
Hi,
the min frequencies of the DVB-C frontends are wrong. In Europe, the center
frequency of the lowest
channel is 50.5MHz and not 51MHz. All known cards with the
stv0297/tda0002x/ves1820 frontend are
able to tune to this frequency. I've changed the range to the lowest channel
- 1/2 bandwidth and the
highest channel + 1/2 bandwidth. For the design of the dvb driver, the
frequency ranges must be part
of the tuner and not of the frontend itself. The same frontend may be used
for different tuners. The
attached patch does only fix the ranges and not the design.
Now I'm beginning to have doubts about Oliver's original patch:
dvb_frontend: Range check of frequency and symbol rate
http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of
fe-ops.info.frequency_min|max ???
-Mike
Signed-off-by: Hartmut Birr [EMAIL PROTECTED]
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/stv0297.c
--- a/linux/drivers/media/dvb/frontends/stv0297.c Fri Aug 03 18:42:33
2007 -0300
+++ b/linux/drivers/media/dvb/frontends/stv0297.c Mon Aug 06 19:14:31
2007 +0200
@@ -680,8 +680,8 @@ static struct dvb_frontend_ops stv0297_o
.info = {
.name = ST STV0297 DVB-C,
.type = FE_QAM,
- .frequency_min = 6400,
- .frequency_max = 13,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.frequency_stepsize = 62500,
.symbol_rate_min = 87,
.symbol_rate_max = 1170,
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/tda10021.c
--- a/linux/drivers/media/dvb/frontends/tda10021.cFri Aug 03 18:42:33
2007 -0300
+++ b/linux/drivers/media/dvb/frontends/tda10021.cMon Aug 06 19:14:31
2007 +0200
@@ -439,8 +439,8 @@ static struct dvb_frontend_ops tda10021_
.name = Philips TDA10021 DVB-C,
.type = FE_QAM,
.frequency_stepsize = 62500,
- .frequency_min = 5100,
- .frequency_max = 85800,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.symbol_rate_min = (XIN/2)/64, /* SACLK/64 == (XIN/2)/64 */
.symbol_rate_max = (XIN/2)/4, /* SACLK/4 */
#if 0 /* keep */
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/tda10023.c
--- a/linux/drivers/media/dvb/frontends/tda10023.cFri Aug 03 18:42:33
2007 -0300
+++ b/linux/drivers/media/dvb/frontends/tda10023.cMon Aug 06 19:14:31
2007 +0200
@@ -504,8 +504,8 @@ static struct dvb_frontend_ops tda10023_
.name = Philips TDA10023 DVB-C,
.type = FE_QAM,
.frequency_stepsize = 62500,
- .frequency_min = 5100,
- .frequency_max = 85800,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.symbol_rate_min = (SYSCLK/2)/64, /* SACLK/64 ==
(SYSCLK/2)/64 */
.symbol_rate_max = (SYSCLK/2)/4, /* SACLK/4 */
#if 0
diff -r 5bb1af77fdc5 linux/drivers/media/dvb/frontends/ves1820.c
--- a/linux/drivers/media/dvb/frontends/ves1820.c Fri Aug 03 18:42:33
2007 -0300
+++ b/linux/drivers/media/dvb/frontends/ves1820.c Mon Aug 06 19:14:31
2007 +0200
@@ -410,8 +410,8 @@ static struct dvb_frontend_ops ves1820_o
.name = VLSI VES1820 DVB-C,
.type = FE_QAM,
.frequency_stepsize = 62500,
- .frequency_min = 5100,
- .frequency_max = 85800,
+ .frequency_min = 4700,
+ .frequency_max = 86200,
.caps = FE_CAN_QAM_16 |
FE_CAN_QAM_32 |
FE_CAN_QAM_64 |
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. The intention to write the frequency patch was some trouble with w_scan, which starts on 50.5MHz. - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
e9hack wrote: Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. The intention to write the frequency patch was some trouble with w_scan, which starts on 50.5MHz. FYI, I never mentioned pll framework The DVB subsystem uses dvb_frontend tuner modules, in many, but not all cases. This is used by silicon and pll tuners alike. IMHO, if there is a separate tuner used in conjunction to the demod, it is better to factor out the tuner to a separate dvb_frontend style module, rather than leaving it hardcoded within the demod driver. This may result in a benefit of removal of duplicated code, in cases where multiple demods are using the same tuner. I don't know if this is the case in your situation, but it is the case with many others. Cheers, Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Oliver Endriss wrote: Michael Krufky wrote: e9hack wrote: Hi, the min frequencies of the DVB-C frontends are wrong. In Europe, the center frequency of the lowest channel is 50.5MHz and not 51MHz. All known cards with the stv0297/tda0002x/ves1820 frontend are able to tune to this frequency. I've changed the range to the lowest channel - 1/2 bandwidth and the highest channel + 1/2 bandwidth. For the design of the dvb driver, the frequency ranges must be part of the tuner and not of the frontend itself. The same frontend may be used for different tuners. The attached patch does only fix the ranges and not the design. Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Hm, I was not aware that there is another info.frequency_min|max in tuner_ops. :-( Do we need both of them? I think it's most appropriate to keep tuner_ops.info.frequency_min|max , since it is the tuner that we're talking about. If the demodulator itself does not have such limitations, then we should not have such a field in the demod ops.info section. I believe that this is leftover from before Andrew's original dvb tuner refactoring. Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Oliver Endriss wrote: Michael Krufky wrote: e9hack wrote: Hi, the min frequencies of the DVB-C frontends are wrong. In Europe, the center frequency of the lowest channel is 50.5MHz and not 51MHz. All known cards with the stv0297/tda0002x/ves1820 frontend are able to tune to this frequency. I've changed the range to the lowest channel - 1/2 bandwidth and the highest channel + 1/2 bandwidth. For the design of the dvb driver, the frequency ranges must be part of the tuner and not of the frontend itself. The same frontend may be used for different tuners. The attached patch does only fix the ranges and not the design. Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Hm, I was not aware that there is another info.frequency_min|max in tuner_ops. :-( Do we need both of them? I think it's most appropriate to keep tuner_ops.info.frequency_min|max , since it is the tuner that we're talking about. If the demodulator itself does not have such limitations, then we should not have such a field in the demod ops.info section. I believe that this is leftover from before Andrew's original dvb tuner refactoring. It is an API issue: FE_GET_INFO returns fe-ops.info, so we cannot easily drop this field. What about modifying dvb_pll_attach to override fe-ops.info.frequency? CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Oliver Endriss wrote: Michael Krufky wrote: Oliver Endriss wrote: Michael Krufky wrote: e9hack wrote: Hi, the min frequencies of the DVB-C frontends are wrong. In Europe, the center frequency of the lowest channel is 50.5MHz and not 51MHz. All known cards with the stv0297/tda0002x/ves1820 frontend are able to tune to this frequency. I've changed the range to the lowest channel - 1/2 bandwidth and the highest channel + 1/2 bandwidth. For the design of the dvb driver, the frequency ranges must be part of the tuner and not of the frontend itself. The same frontend may be used for different tuners. The attached patch does only fix the ranges and not the design. Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Hm, I was not aware that there is another info.frequency_min|max in tuner_ops. :-( Do we need both of them? I think it's most appropriate to keep tuner_ops.info.frequency_min|max , since it is the tuner that we're talking about. If the demodulator itself does not have such limitations, then we should not have such a field in the demod ops.info section. I believe that this is leftover from before Andrew's original dvb tuner refactoring. It is an API issue: FE_GET_INFO returns fe-ops.info, so we cannot easily drop this field. What about modifying dvb_pll_attach to override fe-ops.info.frequency? No, because dvb-pll is only one of many dvb_frontend tuner drivers. We would have to modify all dvb_frontend tuner drivers to set this field -- but they are already setting this field, inside tuner_ops.info. Instead, we can modify FE_GET_INFO to return fe-ops.tuner_ops.info.frequency_min|max instead. The current demodulator drivers that have the tuning code hardcoded inside should also set the tuner_ops.info fields as well. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Trent Piepho wrote: On Mon, 6 Aug 2007, e9hack wrote: Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. I think it would make more sense for the demodulator drivers to fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max. A frontend driver that doesn't use a separate tuner driver (like DST) would set the fe-ops.info.frequency_min|max directly. The way I see it, the demod driver that doesn't have a separate tuner driver should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because otherwise those fields will be there anyway, just remaining empty. Those structures are not pointers, and we should always be able to rely on their presence. There is no need for BOTH ops.info.frequency_min|max AND ops.tuner_ops.info.frequency_min|max -- Michael Krufky ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Trent Piepho wrote: On Mon, 6 Aug 2007, e9hack wrote: Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Agreed. I think it would make more sense for the demodulator drivers to fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max. A frontend driver that doesn't use a separate tuner driver (like DST) would set the fe-ops.info.frequency_min|max directly. Afaics the demod driver cannot fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max, because the tuner driver will be attached _after_ the demod driver (see budget-av.c for example). The way I see it, the demod driver that doesn't have a separate tuner driver should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because otherwise those fields will be there anyway, just remaining empty. Those structures are not pointers, and we should always be able to rely on their presence. There is no need for BOTH ops.info.frequency_min|max AND ops.tuner_ops.info.frequency_min|max The following drivers set ops.tuner_ops.info.frequency_min|max: dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100. All other drivers use ops.info.frequency_min|max. What about this: dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if non-zero. Otherwise it would continue to use ops.info.frequency_min|max. CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Oliver Endriss wrote: Michael Krufky wrote: Trent Piepho wrote: On Mon, 6 Aug 2007, e9hack wrote: Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Agreed. I think it would make more sense for the demodulator drivers to fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max. A frontend driver that doesn't use a separate tuner driver (like DST) would set the fe-ops.info.frequency_min|max directly. Afaics the demod driver cannot fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max, because the tuner driver will be attached _after_ the demod driver (see budget-av.c for example). The way I see it, the demod driver that doesn't have a separate tuner driver should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because otherwise those fields will be there anyway, just remaining empty. Those structures are not pointers, and we should always be able to rely on their presence. There is no need for BOTH ops.info.frequency_min|max AND ops.tuner_ops.info.frequency_min|max The following drivers set ops.tuner_ops.info.frequency_min|max: dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100. All other drivers use ops.info.frequency_min|max. What about this: dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if non-zero. Otherwise it would continue to use ops.info.frequency_min|max. That's fine with me... except I just don't see why we shouldn't just have the demod drivers that have the integrated tuning functionality just fill tuner_ops.info.frequency_max|min anyway. The point is, the structures will be present regardless of whether any tuner_ops are actually filled. This is an opportunity to remove the frequency_min|max from the demod ops.info structure, as we all agree that it is inappropriate there anyhow. If we do this, then we will have a standard across the board. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky wrote: Oliver Endriss wrote: Michael Krufky wrote: Trent Piepho wrote: On Mon, 6 Aug 2007, e9hack wrote: Michael Krufky schrieb: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? I didn't see the ranges from the tuner, because the dvb-c drivers don't use the pll framework. They have very simple tuning functions only. We should use both values. One part may be more restrictive than the other one. Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Agreed. I think it would make more sense for the demodulator drivers to fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max. A frontend driver that doesn't use a separate tuner driver (like DST) would set the fe-ops.info.frequency_min|max directly. Afaics the demod driver cannot fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max, because the tuner driver will be attached _after_ the demod driver (see budget-av.c for example). The way I see it, the demod driver that doesn't have a separate tuner driver should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because otherwise those fields will be there anyway, just remaining empty. Those structures are not pointers, and we should always be able to rely on their presence. There is no need for BOTH ops.info.frequency_min|max AND ops.tuner_ops.info.frequency_min|max The following drivers set ops.tuner_ops.info.frequency_min|max: dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100. All other drivers use ops.info.frequency_min|max. What about this: dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if non-zero. Otherwise it would continue to use ops.info.frequency_min|max. That's fine with me... except I just don't see why we shouldn't just have the demod drivers that have the integrated tuning functionality just fill tuner_ops.info.frequency_max|min anyway. The point is, the structures will be present regardless of whether any tuner_ops are actually filled. This is an opportunity to remove the frequency_min|max from the demod ops.info structure, as we all agree that it is inappropriate there anyhow. If we do this, then we will have a standard across the board. That's fine if we agree that we have to touch most frontend drivers. If we choose to do that, we should remove ops.info.frequency_min|max, i.e. remove 'struct dvb_frontend_info' from 'struct frontend_ops' and add something like 'struct dvb_demod_info' instead. We must not modify 'struct dvb_frontend_info' because it is an API data structure. Afaics 'frequency_stepsize' can be substituted by 'frequency_step', but what should we do with 'frequency_tolerance'? CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On 8/7/07, Oliver Endriss [EMAIL PROTECTED] wrote:
I didn't see the ranges from the tuner, because the dvb-c drivers don't
use the pll framework. They
have very simple tuning functions only. We should use both values. One
part may be more restrictive
than the other one.
Most demodulators don't have frequency ranges. They just take whatever
the
tuner gives them at a fixed intermediate frequency. It's really the tuner
that has the frequency range.
Agreed.
Though demodulators don't have frequency ranges, they do have
bandwidth's (not DVB-T bandwidth, i mean bandwidth for the loop, ie
loop bandwidth)
Currently none of our in tree drivers do calculate _any_ loop
bandwidth etc, but just blindly set up values based on predefined
values.
But not the same case anymore. We will have divers using these parameters.
I think it would make more sense for the demodulator drivers to fill
fe-ops.info.frequency_min|max using
fe-ops.tuner_ops.info.frequency_min|max.
A frontend driver that doesn't use a separate tuner driver (like DST)
would
set the fe-ops.info.frequency_min|max directly.
Afaics the demod driver cannot fill fe-ops.info.frequency_min|max using
fe-ops.tuner_ops.info.frequency_min|max, because the tuner driver will
be attached _after_ the demod driver (see budget-av.c for example).
With new devices i have been doing calculations based on these, In
fact you can see it here:
with a silicon tuner:
267 static int stb6100_set_bandwidth(struct dvb_frontend *fe,
u32 bandwidth)
250 static int stb6100_get_bandwidth(struct dvb_frontend *fe,
u32 *bandwidth)
327 static int stb6100_set_frequency(struct dvb_frontend *fe,
u32 frequency)
296 static int stb6100_get_frequency(struct dvb_frontend *fe,
u32 *frequency)
with a PLL (as of current), i have to use
1237 static int knc1_dvbs2_sd1878_pll_get_bandwidth(struct
dvb_frontend *fe, u32 *bandwidth)
1238 {
1239 /* FIXME ! need to calculate the bandwidth */
1240 *bandwidth = 6000;
1241
1242 return 0;
1243 }
Now it can be that the tuner and the demodulator have fixed spectral
limits, but also that they can differ.
In the case that which it differs, we will need separate max/min for
both. In such a case it would be better to have them for internal
bound checks at run time.
The way I see it, the demod driver that doesn't have a separate tuner driver
should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because
otherwise those fields will be there anyway, just remaining empty. Those
structures are not pointers, and we should always be able to rely on their
presence.
There is no need for BOTH ops.info.frequency_min|max AND
ops.tuner_ops.info.frequency_min|max
The following drivers set ops.tuner_ops.info.frequency_min|max:
dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100.
All other drivers use ops.info.frequency_min|max.
What about this:
dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if
non-zero. Otherwise it would continue to use ops.info.frequency_min|max.
The idea what i was having was that individual demodulators can do
their own CUSTOM tuning algorithm.
111 /*
112 ** ALGO_HW: (Hardware Algorithm)
113 *
114 *Devices that support this algorithm, do everything in hardware
115 *and no software support is needed to handle them.
116 *Requesting these devices to LOCK is the only thing required,
117 *device is supposed to do everything in the hardware
118 *
119 ** ALGO_SW: (Software Algorithm)
120 *
121 *These are dumb devices, that require software to do everything
122 *
123 ** ALGO_CUSTOM: (Customizable Agorithm)
124 *
125 *Devices having this algorithm can be customized to have specific
126 *algorithms in the frontend driver, rather than simply doing a
127 *software zig-zag. In this case the zigzag maybe hardware
assisted
128 *or it maybe completely done in hardware. In all cases, usage of
129 *this algorithm, in conjunction with the search and track
130 *callbacks utilizes the driver specific algorithm to be used.
131 *
132 ** ALGO_RECOVERY: (Recovery Algorithm)
133 *
134 *These devices has AUTO recovery capabilities from LOCK failure
135 */
136 enum dvbfe_algo {
137 DVBFE_ALGO_HW = (1 0),
138 DVBFE_ALGO_SW = (1 1),
139 DVBFE_ALGO_CUSTOM = (1 2),
140
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
e9hack wrote: Currently, I'm missing something in the tuner modules (and I didn't ask for it). It isn't possible to wait for getting the pll lock. The tuning function of the TT-C2300 does wait. It isn't possible to switch the time constant of the loop filter after getting the lock. Usually, it is recommended for any pll chips. Have a look how I implemented that in the tda10086 driver (search for 'has_lock'). CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On 8/7/07, Trent Piepho [EMAIL PROTECTED] wrote: Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Not true: look at the MB86A16. It is a DC (Direct Conversion) receiver. There is no tuner used alongwith (a similar case goes for the MB86A15, but that is far from being similar) and hence no IF. But in either case, absolutely _no_ tuner. There are other DC receivers as well, mentioned the MB86A16 as an example, since being more familiar with it. I think it would make more sense for the demodulator drivers to fill fe-ops.info.frequency_min|max using fe-ops.tuner_ops.info.frequency_min|max. A frontend driver that doesn't use a separate tuner driver (like DST) would set the fe-ops.info.frequency_min|max directly. DST, inside the host CPU, does calculations based on the upper and lower bounds, but that generally results in almost the same defined spectral definition according to the standards. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On 8/6/07, Michael Krufky [EMAIL PROTECTED] wrote: Now I'm beginning to have doubts about Oliver's original patch: dvb_frontend: Range check of frequency and symbol rate http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6 Should we be checking fe-ops.tuner_ops.info.frequency_min|max , instead of fe-ops.info.frequency_min|max ??? Ideally, what's provided by the demod and not the tuner max/min. The tuners max/min should be checked by the demod on setting params. The upper/lower limits in the demodulator drivers, came from the concept of a frontend as a whole. Independant bounds do not make sense (except internally -- It is the demod driver that which sets parameters for the tuner. The external world doesn't need to know what's the limit of the tuner, but only of the frontend as a whole). Ideally, the demodulator should just demodulate only. There are some cases, there are some cases which are not. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On Tue, 7 Aug 2007, Manu Abraham wrote: On 8/7/07, Trent Piepho [EMAIL PROTECTED] wrote: Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Not true: look at the MB86A16. It is a DC (Direct Conversion) receiver. There is no tuner used alongwith (a similar case goes for the MB86A15, but that is far from being similar) and hence no IF. But in either case, absolutely _no_ tuner. Look at what I wrote. Most demodulators ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
