Re: [linux-media] stb0899: no lock on dvb-s2 transponders in SCR environment
On 27.04.2013 14:14, Reinhard Nissl wrote: Hi, my stb0899 card works properly on dvb-s and dvb-s2 transponders when using a direct port on my sat multiswitch. When using a SCR port on that multiswitch and changing VDR's config files accordingly, it only locks on dvb-s transponders. A SCR converts the selected transponder's frequency after the LNB (IF1) to a fixed frequency (for example 1076 MHz) by mixing the signal with a local oscialator frequency above IF1 so that the lower sideband of the mixing product appears at 1076 MHz. The lower sideband's spectrum is mirrored compared to the upper sideband, which is identical to the original spectrum on the original IF1. Could that be the reason why the stb0899 cannot lock on dvb-s2 transponders in an SCR environment? Any ideas on how to get a lock on dvb-s2 transponders? Just wanted to let you know that I can confirm the problem with the stb0899. On my TT S2-6400 I can receive DVB-S and DVB-S2 just fine with SCR. During development of SCR support for VDR I guess I did all tests with the 6400, so I didn't come across this problem. However, as a reaction to your posting I explicitly tested it with my budget cards, and there I indeed can only tune to DVB-S transponders. No idea how to solve this, though... Klaus -- 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
DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? Should a caller check against both EOPNOTSUPP *and* ENOTTY? I searched through linux/drivers/media and found that both values are used (EOPNOTSUPP 57 times and ENOTTY 71 times in the version I have in use). While ENOTTY seems to apply here (at least from its description, not from its name) ENOTTY Inappropriate ioctl for device (originally Not a typewriter) and I can see why this would be a reason for changing this, EOPNOTSUPP doesn't really seem to apply, since there is, I assume, no socket involved here: EOPNOTSUPP Operation not supported on socket The value I would actually expect to be used in case an operation is not supported by a device is ENOTSUP Operation not supported Interestingly the driver source uses ENOTSUPP (note the double 'P') 8 times, but that name is not defined according to man errno(3). So the bottom line is that there appears to be some confusion as to which errno value to return in case an operation is not supported. Maybe all these return values should be set to ENOTSUP (with a single 'P' at the end)? Klaus -- 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: [linux-media] Re: DVB: EOPNOTSUPP vs. ENOTTY in ioctl(FE_READ_UNCORRECTED_BLOCKS)
On 14.02.2013 20:50, Manu Abraham wrote: On Fri, Feb 15, 2013 at 12:46 AM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 08:05 PM, Manu Abraham wrote: On Thu, Feb 14, 2013 at 9:22 PM, Antti Palosaari cr...@iki.fi wrote: On 02/14/2013 03:12 PM, Klaus Schmidinger wrote: In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function. Is there a reason why this has been changed? I changed it in order to harmonize error codes. ENOTTY is correct error code for the case IOCTL is not implemented. What I think it is Kernel wide practice. By doing so, You BROKE User Space ABI. Whatever it is, we are not allowed to break User ABI. https://lkml.org/lkml/2012/12/23/75 Yes, it will change API, that's clear. But the hell, how you will get anything fixed unless you change it? Introduce totally new API every-time when bug is found? You should also understand that changing that single error code on that place will not change all the drivers and there will be still some other error statuses returned by individual drivers. It is about 100% clear that ENOTTY is proper error code for unimplemented IOCTL. I remember maybe more than one discussion about that unimplemented IOCTL error code. It seems to be defined by POSIX [1] standard. It could be. But what I stated is thus: There existed commonality where all unimplemented IOCTL's returned EOPNOTSUPP when the corresponding callback wasn't implemented. So, this was kind of standardized though it was not the ideal thing, though it was not a big issue, it just stated socket additionally. You changed it to ENOTTY to make it fit for the idealistic world. All applications that depended for ages, on those error are now broken. I'm sorry I stirred up this topic again. I wasn't aware that *this* was the reason for https://lkml.org/lkml/2012/12/23/75. As an application developer myself I don't mind if bugs in drivers are fixed, I just wanted to understand the rationale. So now I've learned that bugs in drivers can't be fixed, because some software might rely on the bug. Oh well... In this particular function of VDR I have now changed things to no longer check for any particular not supported errno value, just EINTR. I hope that one is standardized enough... Klaus -- 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: [linux-media] Re: [linux-media] Re: [PATCH RFCv10 00/15] DVB QoS statistics API
On 17.01.2013 18:37, Klaus Schmidinger wrote: On 17.01.2013 18:22, Antti Palosaari wrote: On 01/17/2013 07:16 PM, Manu Abraham wrote: On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari cr...@iki.fi wrote: On 01/17/2013 05:40 AM, Manu Abraham wrote: MB86A20 is not the only demodulator driver with the Linux DVB. And not all devices can output in dB scale proposed by you, But any device output can be scaled in a relative way. So I don't see any reason why userspace has to deal with cumbersome controls to deal with redundant statistics, which is nonsense. What goes to these units in general, dB conversion is done by the driver about always. It is quite hard or even impossible to find out that formula unless you has adjustable test signal generator. Also we could not offer always dBm as signal strength. This comes to fact that only recent silicon RF-tuners are able to provide RF strength. More traditionally that estimation is done by demod from IF/RF AGC, which leads very, very, rough estimation. What I am saying is that, rather than sticking to a dB scale, it would be better to fit it into a relative scale, ie loose dB altogether and use only the relative scale. With that approach any device can be fit into that convention. Even with an unknown device, it makes it pretty easy for anyone to fit into that scale. All you need is a few trial runs to get maxima/minima. When there exists only a single convention that is simple, it makes it more easier for people to stick to that convention, rather than for people to not support it. That is true. I don't have really clear opinion whether to force all to one scale, or return dBm those which could and that dummy scale for the others. Maybe I will still vote for both relative and dBm. Shortly there is two possibilities: 1) support only relative scale 2) support both dBm and relative scale (with dBm priority) [3) support only dBm is not possible] 4) support relative scale (mandatory!) and dBm (if applicable). I concur with Antti. Sorry, that should have been Manu - got the wrong quote level... Any device's values can be made to fit into a 0..100 (or whatever) range, so *that* should be the primary (and mandatory) value. If the device can do so, it can also provide a dB* value (replace * with anything you like, 'm', 'uV', 'uW', whatever) and maybe all other sorts of bells and whistles. So real world applications could simply and savely use the relative value (which is all they need), and special applications could fiddle around with dB values (provided the device in use can deliver them). @Mauro: here's some further reading for you, just in case ;-) http://en.wikipedia.org/wiki/KISS_principle http://www.inspireux.com/2008/07/14/a-designer-achieves-perfection-when-there-is-nothing-left-to-take-away Klaus -- 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: [linux-media] Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On 09.01.2013 12:02, Simon Farnsworth wrote: On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote: On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth simon.farnswo...@onelan.com wrote: The wireless folk use dBm (reference point 1 milliwatt), as that's the reference point used in the 802.11 standard. Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference point (so suitable for carrier to noise etc, or for when the reference point is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is 1mW, so that frontends report in dBm? Note that if the frontend internally uses a different reference point, the conversion is always going to be adding or subtracting a constant. Hi Simon, Probably the biggest issue you're going to have is that very few of the consumer-grade demodulators actually report data in that format. And only a small subset of those actually provide the documentation in their datasheet. snip My specific concern is that we already see people complaining that their cable system or aerial installer's meter comes up with one number, and our documentation has completely different numbers. When we dig, this usually turns out to be because our documentation is in dBm, while their installer is using dBmV or dBµW, and no-one at the customer site knows the differences. If consumer demods don't report in a dB scale at all, we should drop dB as a unit; if they do report in a true dB scale, but the reference point is normally not documented, we need some way to distinguish demods where the reference point is unknown, and demods where someone has taken the time to find the reference point (which can be done with a signal generator). This is sounding more and more like an argument for adding FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to tell the user that the signal strength reading from the application should match up to the signal strength reading on your installer's kit. Said applications could even choose to do the conversions for you, giving you all four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW). For that matter, even the SNR field being reported in dB isn't going to allow you to reliably compare across different demodulator chips. If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't really mean demod Y performs better - just that it's reporting a better number. However it does allow you to compare the demod against itself either across multiple frequencies or under different signal conditions - which is what typical users really care about. I'm not expecting people to compare across demods - I only care about the case where a user has got in a professional installer to help with their setup. The problem I want to avoid is a Linux application saying -48 dB signal strength, 15 dB CNR, and the installer's kit saying 60 dBuV signal strength, 20 dB CNR, when we have enough information for the Linux application to say -48 dBm (60 dBuV at 75Ω), 15 dB CNR, cueing the professional to remember that not all dB use the same reference point, and from there into accepting that Linux is reporting a similar signal strength and CNR to his kit. This also has implications for things like VDR - if the scale is FE_SCALE_DECIBEL but the measurement is absolute, the application probably doesn't want to report the measurement as a dB measure, but as an arbitrary scale; again, you don't want the application saying 50 dB, when the professional installer tells you that you have 0 dBuV. Actually VDR doesn't care about dB, dBuV, dBuW or whatever. All it wants to do is to display the signal strength and quality in a way that, as Devin stated so very appropriately, even an idiot can understand ;-) VDR displays a bar that goes from 0 (no signal at all) to full extent (perfect signal). So for VDR any value range that can be linearly converted to a range between 0% and 100% would do just fine. The only important thing is that it is the *same* for all frontends! Ideally I would expect values in the range 0x thru 0x. Klaus -- 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: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 03.01.2013 14:20, Mauro Carvalho Chehab wrote: Em Wed, 2 Jan 2013 00:38:50 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On Tue, Jan 1, 2013 at 10:59 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Tue, 1 Jan 2013 22:18:49 +0530 Manu Abraham abraham.m...@gmail.com escreveu: On Tue, Jan 1, 2013 at 8:30 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: [RFCv4] dvb: Add DVBv5 properties for quality parameters The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; per layer stats is a mythical bird, nothing of that sort does exist. Had you ever read or tried to get stats from an ISDB-T demod? If you had, you would see that it only provides per-layer stats. Btw, this is a requirement to follow the ARIB and ABNT ISDB specs. I understand you keep writing junk for ages, but nevertheless: Do you have any idea what's a BBHEADER (DVB-S2) or PLHEADER (DVB-T2) ? The headers do indicate what MODCOD (aka Modulation/Coding Standard follows, whatever mode ACM, VCM or CCM) follows. These MODCOD foolows a TDM approach with a hierarchial modulation principle. This is exactly what ISDB does too. No, I didn't check DVB-S2/T2 specs deeply enough to understand if they're doing the same thing as ISDB. Yet, ISDB-T doesn't use a TDM approach for hierarchical modulation. It uses a FDM (OFDM is a type of Frequency Division Multiplexing). So, if you're saying that DVB-S2 uses TDM, it is very different than ISDB-T. As DVB-T2 uses an FDM type of modulation (OFDM), it would be possible to segment the carriers there, just like ISDB, or to use TDM hierarchical modulation techniques. And for your info: The TMCC control information is common to all TMCC carriers and error correction is performed by using difference-set cyclic code. Yes, TMCC carriers are equal and they are always modulated using DBPSK. That is done to make it possible to receive the TMCC carriers even under worse SNR conditions, where it may not be possible to decode the segment groups. It seems that you completely missed the point though. On ISDB-T, the carriers that belong to each group of segments (except for the control carriers - carriers 1 to 107) uses a completely independent modulation. Also, as they're spaced in frequency, the interference of each segment is different. So, error indications are different on each segment. Btw, in any case, the datasheets of ISDB-T demods clearly shows that the BER measures are per segment group (layer). For example, for the BER measures before Viterbi, those are the register names for a certain demod: VBERSNUMA Bit count of BER measurement before Viterbi in A layer VBERSNUMB Bit count of BER measurement before Viterbi in B layer VBERSNUMC Bit count of BER measurement before Viterbi in C layer It has another set of registers for BER after Viterbi, and for PER after Viterbi and RS, for bit count errors, etc. There's no way to get any type of global BER measure, simply because ISDB-T demods don't provide. Maybe we should put all this theoretical discussion aside for the moment and think about what is *really* needed by real world applications. As with any receiver, VDR simply wants to have some measure of the signal's strength and quality. These are just two values that should be delivered by each frontend/demux, using the *same* defined and mandatory range. I don't care what exactly that is, but it needs to be the same for all devices. What values a particular driver uses internally to come up with these is of no interest to VDR. The signal strength might just be what is currently returned through FE_READ_SIGNAL_STRENGTH (however, normalized to the same range in all drivers, which currently is not the case). The signal quality might use flags like FE_HAS_SIGNAL, FE_HAS_CARRIER, FE_HAS_VITERBI, FE_HAS_SYNC, as well as SNR, BER and UNC (if available) to form some value where 0 means no quality at all, and 0x means excellent quality. If a particular frontend/demux uses totally different concepts, it can just use whatever it deems reasonable to form the strength and quality values. The important thing here is just that all this needs to be hidden inside the driver, and the only interface to an application are ioctl() calls that return these two values.
Re: [linux-media] [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 29.12.2012 00:56, Mauro Carvalho Chehab wrote:
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
include/uapi/linux/dvb/frontend.h | 78 ++-
1 file changed, 77 insertions(+), 1 deletion(-)
v3: Just update http://patchwork.linuxtv.org/patch/9578/ to current tip
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c12d452..a998b9a 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,21 @@ struct dvb_frontend_event {
#define DTV_INTERLEAVING 60
#define DTV_LNA 61
-#define DTV_MAX_COMMANDDTV_LNA
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 45 /* Enumerates supported QoS parameters
*/
+#define DTV_QUALITY_SNR46
+#define DTV_QUALITY_CNR47
+#define DTV_QUALITY_EsNo 48
+#define DTV_QUALITY_EbNo 49
+#define DTV_QUALITY_RELATIVE 50
+#define DTV_ERROR_BER 51
+#define DTV_ERROR_PER 52
+#define DTV_ERROR_PARAMS 53 /* Error count at TMCC or TPS carrier */
+#define DTV_FE_STRENGTH54
+#define DTV_FE_SIGNAL 55
+#define DTV_FE_UNC 56
+
+#define DTV_MAX_COMMANDDTV_FE_UNC
typedef enum fe_pilot {
PILOT_ON,
@@ -452,12 +466,74 @@ struct dtv_cmds_h {
__u32 reserved:30;/* Align */
};
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_DECIBEL: The scale is measured in dB, typically
+ * used on signal measures.
+ * @FE_SCALE_LINEAR: The scale is linear.
+ * typically used on error QoS parameters.
+ * @FE_SCALE_RELATIVE: The scale is relative.
+ */
+enum fecap_scale_params {
+ FE_SCALE_DECIBEL,
+ FE_SCALE_LINEAR,
+ FE_SCALE_RELATIVE
+};
+
+/**
+ * struct dtv_status - Used for reading a DTV status property
+ *
+ * @value: value of the measure. Should range from 0 to 0x;
+ * @scale: Filled with enum fecap_scale_params - the scale
+ * in usage for that parameter
+ * @min: minimum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0.
+ * @max: maximum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0x.
+ *
+ * At userspace, min/max values should be used to calculate the
+ * absolute value of that measure, if fecap_scale_params is not
+ * FE_SCALE_RELATIVE, using the following formula:
+ * measure = min + (value * (max - min) / 0x)
+ *
+ * For error count measures, typically, min = 0, and max = 0x,
+ * and the measure represent the number of errors detected.
+ *
+ * Up to 4 status groups can be provided. This is for the
+ * OFDM standards where the carriers can be grouped into
+ * independent layers, each with its own modulation. When
+ * such layers are used (for example, on ISDB-T), the status
+ * should be filled with:
+ * stat.status[0] = global statistics;
+ * stat.status[1] = layer A statistics;
+ * stat.status[2] = layer B statistics;
+ * stat.status[3] = layer C statistics.
+ * and stat.len should be filled with the latest filled status + 1.
+ * If the frontend doesn't provide a global statistics,
+ * stat.has_global should be 0.
+ * Delivery systems that don't use it, should just set stat.len and
+ * stat.has_global with 1, and fill just stat.status[0].
+ */
+struct dtv_status {
+ __u16 value;
+ __u16 scale;
+ __s16 min;
+ __s16 max;
+} __attribute__ ((packed));
+
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
+ __u8 len;
+ __u8 has_global;
+
Re: [linux-media] Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters
On 29.12.2012 17:36, Devin Heitmueller wrote: On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats; This RFC adds the header definitions meant to solve that issues. After discussed, I'll write a patch for the DocBook and add support for it on some demods. Support for dvbv5-zap and dvbv5-scan tools will also have support for those features. Hi Mauro, As I've told you multiple times in the past, where this proposal falls apart is in its complete lack of specificity for real world scenarios. You have a units field which is decibels, but in what unit? 1 dB / unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why the current snr field varies across even demods where we have the datasheets. Many demods reported in 0.1 dB increments, while others reported in 1/255 dB increments. What happens when you ask for the SNR field when there is so signal lock (on most demods the SNR registers return garbage in this case)? What is the return value to userland? What happens when the data is unavailable for some other reason? What happens when you have group of statistics being asked for in a single call and *one* of them cannot be provided for some reason (in which case you cannot rely on a simple errno value since it doesn't apply to the entire call)? You need to take a step back and think about this from an application implementors standpoint. Most app developers for the existing apps look to show two data points: a signal indicator (0-100%), and some form of SNR (usually in dB, plotted on a scale where something like 40 dB=100% [of course this max varies by modulation type]). What would I need to do with the data you've provided to show that info? Do I really need to be a background in signal theory and understand the difference between SNR and CNR in order to tell the user how good his signal is? Since as an app developer I typically only have one or two tuners, how the hell am I supposed to write a piece of code that shows those two pieces of information given the huge number of different combinations of data types that demods could return given the proposed API? We have similar issues for UNC/BER values. Is the value returned the number of errors since the last time the application asked? Is it the number of errors in the last two seconds? Is it the number of errors since I reached signal lock? Does asking for the value clear out the counter? How do we handle the case where I asked for the data for the first time ten minutes after I reached signal lock? Are drivers internally supposed to be polling the register and updating the counters even when the application doesn't ask for the data (to handle cases where the demod's registers only have an error count for the last second's worth of data)? And where the examples that show typical values for the different modulation types? For example, I'm no expert in DVB-C but I'm trying to write an app which can be used by those users. What range of values will the API typically return for that modulation type? What values are good values, which represent excellent signal conditions, and what values suggest that the signal will probably be failing? What happens when a driver doesn't support a particular statistic? Right now some drivers return -EINVAL, others just set the field to zero or 0x1fff (in which case the user is mislead to believe that there is no signal lock *all* the time). EXAMPLES EXAMPLES EXAMPLES. This is the whole reason that the API behaves inconsistently today - somebody who did one of the early demods returned in 1/255 dB format, and then some other developer who didn't have the first piece of hardware wrote a driver and because he/she didn't *know* what the field was supposed to contain (and couldn't try it his/herself), that developer wrote a driver which returned in 0.1 dB format. This needs to be defined *in the spec*, or else we'll end up with developers (both app developers and kernel develoeprs implementing new demods) guessing how the API should behave based on whatever hardware they have, which is how we got in this mess in the first place. In short, you need to describe typical usage scenarios in terms of what
[PATCH] DVB: stb0899: speed up getting BER values
stb0899_read_ber() takes 500ms (half a second!) to deliver the current
BER value. Apparently it takes 5 subsequent readings, with a 100ms pause
between them (and even before the first one). This is a real performance
brake if an application freqeuently reads the BER of several devices.
The attached patch reduces this to a single reading, with no more pausing.
I didn't observe any negative side effects of this change.
Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de
Klaus
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2012-04-23 15:10:35.994008188 +0200
+++ a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2012-04-23 15:29:40.544837905 +0200
@@ -1135,7 +1135,6 @@
struct stb0899_internal *internal = state-internal;
u8 lsb, msb;
- u32 i;
*ber = 0;
@@ -1143,14 +1142,9 @@
case SYS_DVBS:
case SYS_DSS:
if (internal-lock) {
- /* average 5 BER values */
- for (i = 0; i 5; i++) {
-msleep(100);
-lsb = stb0899_read_reg(state, STB0899_ECNT1L);
-msb = stb0899_read_reg(state, STB0899_ECNT1M);
-*ber += MAKEWORD16(msb, lsb);
- }
- *ber /= 5;
+ lsb = stb0899_read_reg(state, STB0899_ECNT1L);
+ msb = stb0899_read_reg(state, STB0899_ECNT1M);
+ *ber = MAKEWORD16(msb, lsb);
/* Viterbi Check */
if (STB0899_GETFIELD(VSTATUS_PRFVIT, internal-v_status)) {
/* Error Rate */
@@ -1163,13 +1157,9 @@
break;
case SYS_DVBS2:
if (internal-lock) {
- /* Average 5 PER values */
- for (i = 0; i 5; i++) {
-msleep(100);
-lsb = stb0899_read_reg(state, STB0899_ECNT1L);
-msb = stb0899_read_reg(state, STB0899_ECNT1M);
-*ber += MAKEWORD16(msb, lsb);
- }
+ lsb = stb0899_read_reg(state, STB0899_ECNT1L);
+ msb = stb0899_read_reg(state, STB0899_ECNT1M);
+ *ber = MAKEWORD16(msb, lsb);
/* ber = ber * 10 ^ 7 */
*ber *= 1000;
*ber /= (-1 + (1 (4 + 2 * STB0899_GETFIELD(NOE, internal-err_ctrl;
Re: [linux-media] [PATCH 2/2] stb0899: fixed reading of IF_AGC_GAIN register
When reading IF_AGC_GAIN register a wrong value for the base address
register was used (STB0899_DEMOD instead of STB0899_S2DEMOD). That
lead to a wrong signal strength value on DVB-S2 transponders.
Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
drivers/media/dvb/frontends/stb0899_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_drv.c
b/drivers/media/dvb/frontends/stb0899_drv.c
index 4a58afc..a2e9eba 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -983,7 +983,7 @@ static int stb0899_read_signal_strength(struct dvb_frontend
*fe, u16 *strength)
break;
case SYS_DVBS2:
if (internal-lock) {
-reg = STB0899_READ_S2REG(STB0899_DEMOD, IF_AGC_GAIN);
+reg = STB0899_READ_S2REG(STB0899_S2DEMOD, IF_AGC_GAIN);
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab,
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1, val);
Acked-by: Klaus Schmidinger klaus.schmidin...@tvdr.de
--
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: [linux-media] [PATCH 1/2] stb0899: set FE_HAS_SIGNAL flag in read_status
On 28.02.2012 19:40, Andreas Regel wrote:
In stb0899_read_status the FE_HAS_SIGNAL flag was not set in case of a
successful carrier lock. This change fixes that.
Signed-off-by: Andreas Regel andreas.re...@gmx.de
---
drivers/media/dvb/frontends/stb0899_drv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/stb0899_drv.c
b/drivers/media/dvb/frontends/stb0899_drv.c
index 38565be..4a58afc 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -1071,7 +1071,7 @@ static int stb0899_read_status(struct dvb_frontend *fe,
enum fe_status *status)
reg = stb0899_read_reg(state, STB0899_VSTATUS);
if (STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg)) {
dprintk(state-verbose, FE_DEBUG, 1, FE_HAS_CARRIER |
FE_HAS_LOCK);
-*status |= FE_HAS_CARRIER | FE_HAS_LOCK;
+*status |= FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_LOCK;
reg = stb0899_read_reg(state, STB0899_PLPARM);
if (STB0899_GETFIELD(VITCURPUN, reg)) {
@@ -1088,7 +1088,7 @@ static int stb0899_read_status(struct dvb_frontend *fe,
enum fe_status *status)
if (internal-lock) {
reg = STB0899_READ_S2REG(STB0899_S2DEMOD, DMD_STAT2);
if (STB0899_GETFIELD(UWP_LOCK, reg) STB0899_GETFIELD(CSM_LOCK,
reg)) {
-*status |= FE_HAS_CARRIER;
+*status |= FE_HAS_SIGNAL | FE_HAS_CARRIER;
dprintk(state-verbose, FE_DEBUG, 1,
UWP CSM Lock ! --- DVB-S2 FE_HAS_CARRIER);
Acked-by: Klaus Schmidinger klaus.schmidin...@tvdr.de
--
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: [linux-media] Re: [PATCH] stb0899: fix the limits for signal strength values
On 23.01.2012 20:43, Mauro Carvalho Chehab wrote:
Hi Klaus,
The patch didn't apply. It seems to be due to your emailer that mangled the
whitespaces.
Sorry about that. Here it is again as an attachment.
The patch looks correct on my eyes. Yet, I'd like to have Manu's ack on it.
Em 19-01-2012 15:39, Klaus Schmidinger escreveu:
stb0899_read_signal_strength() adds an offset to the result of the table lookup.
That offset must correspond to the lowest value in the lookup table, to make
sure
the result doesn't get below 0, which would mean a very high value since the
parameter is unsigned.
'strength' and 'snr' need to be initialized to 0 to make sure they have a
defined result in case there is no internal-lock.
Signed-off-by: Klaus Schmidingerklaus.schmidin...@tvdr.de
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-06-11
16:54:32.0 +0200
+++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-06-11
16:23:00.0 +0200
@@ -67,7 +67,7 @@
* Crude linear extrapolation below -84.8dBm and above -8.0dBm.
*/
static const struct stb0899_tab stb0899_dvbsrf_tab[] = {
- { -950, -128 },
+ { -750, -128 },
{ -748, -94 },
{ -745, -92 },
{ -735, -90 },
@@ -131,7 +131,7 @@
{ -730, 13645 },
{ -750, 13909 },
{ -766, 14153 },
- { -999, 16383 }
+ { -950, 16383 }
};
/* DVB-S2 Es/N0 quant in dB/100 vs read value * 100*/
@@ -964,6 +964,7 @@
int val;
u32 reg;
+ *strength = 0;
This is not needed, as strength is not initialized only on invalid delivery
systems,
where -EINVAL is returned.
What about the 'if' conditions within the valid delivery system cases?
For instance
case SYS_DSS:
if (internal-lock) {
...
if (STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg)) {
...
*strength = ...
}
}
break;
So there may be cases where strength has an undefined value, even
if this function returns 0.
switch (state-delsys) {
case SYS_DVBS:
case SYS_DSS:
@@ -987,7 +988,7 @@
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab,
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1, val);
- *strength += 750;
+ *strength += 950;
dprintk(state-verbose, FE_DEBUG, 1, IF_AGC_GAIN = 0x%04x,
C = %d * 0.1 dBm,
val 0x3fff, *strength);
}
@@ -1009,6 +1010,7 @@
u8 buf[2];
u32 reg;
+ *snr = 0;
This is not needed, as strength is not initialized only on invalid delivery
systems,
where -EINVAL is returned.
See above.
reg = stb0899_read_reg(state, STB0899_VSTATUS);
switch (state-delsys) {
case SYS_DVBS:
PS.: Another alternative for it would be the enclosed patch,
wich will be a little simpler, and will also preserve the slope
on the boundary values, used at the stb0899_table_lookup()
interpolation logic.
Well, as long as there are no negative values for strength...
However, I don't quite see why the range is 750 - 950 for DVB-S
and 750 - 999 for DVB-S2. Shouldn't this be the same maximum
value in both cases?
Klaus
[PATCH] stb0899: fix the limits for signal strength values
The current minimal measures for strengh is 750 - 950, for table
stb0899_dvbsrf_tab[], and 750 - 999, for stb0899_dvbs2rf_tab[].
Both are negative values. However, the strength measure is unsigned.
Don't allow negative values for strengh to underflow. Instead,
shift the scale, in order to have 0 as the lowest strength.
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
diff --git a/drivers/media/dvb/frontends/stb0899_drv.c
b/drivers/media/dvb/frontends/stb0899_drv.c
index 38565be..9cfdcb2 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -975,7 +975,7 @@ static int stb0899_read_signal_strength(struct dvb_frontend
*fe, u16 *strength)
val = (s32)(s8)STB0899_GETFIELD(AGCIQVALUE,
reg);
*strength =
stb0899_table_lookup(stb0899_dvbsrf_tab, ARRAY_SIZE(stb0899_dvbsrf_tab) - 1,
val);
- *strength += 750;
+ *strength += 950;
dprintk(state-verbose, FE_DEBUG, 1, AGCIQVALUE =
0x%02x, C = %d * 0.1 dBm,
val 0xff, *strength);
}
@@ -987,7 +987,7 @@ static int stb0899_read_signal_strength(struct dvb_frontend
*fe, u16 *strength)
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab,
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1
[PATCH] stb0899: fix the limits for signal strength values
stb0899_read_signal_strength() adds an offset to the result of the table lookup.
That offset must correspond to the lowest value in the lookup table, to make
sure
the result doesn't get below 0, which would mean a very high value since the
parameter is unsigned.
'strength' and 'snr' need to be initialized to 0 to make sure they have a
defined result in case there is no internal-lock.
Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-06-11
16:54:32.0 +0200
+++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-06-11
16:23:00.0 +0200
@@ -67,7 +67,7 @@
* Crude linear extrapolation below -84.8dBm and above -8.0dBm.
*/
static const struct stb0899_tab stb0899_dvbsrf_tab[] = {
- { -950, -128 },
+ { -750, -128 },
{ -748, -94 },
{ -745, -92 },
{ -735, -90 },
@@ -131,7 +131,7 @@
{ -730, 13645 },
{ -750, 13909 },
{ -766, 14153 },
- { -999, 16383 }
+ { -950, 16383 }
};
/* DVB-S2 Es/N0 quant in dB/100 vs read value * 100*/
@@ -964,6 +964,7 @@
int val;
u32 reg;
+ *strength = 0;
switch (state-delsys) {
case SYS_DVBS:
case SYS_DSS:
@@ -987,7 +988,7 @@
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab,
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1, val);
- *strength += 750;
+ *strength += 950;
dprintk(state-verbose, FE_DEBUG, 1, IF_AGC_GAIN = 0x%04x,
C = %d * 0.1 dBm,
val 0x3fff, *strength);
}
@@ -1009,6 +1010,7 @@
u8 buf[2];
u32 reg;
+ *snr = 0;
reg = stb0899_read_reg(state, STB0899_VSTATUS);
switch (state-delsys) {
case SYS_DVBS:
--
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: [RFCv2 PATCH 10/12] av7110: replace audio.h, video.h and osd.h by av7110.h.
On 24.11.2011 14:39, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com Create a new public header, av7110.h, that contains all the av7110 specific audio, video and osd APIs that used to be defined in dvb/audio.h, dvb/video.h and dvb/osd.h. These APIs are no longer part of DVBv5 but are now av7110-specific. This decision was taken during the 2011 Prague V4L-DVB workshop. Ideally av7110 would be converted to use the replacement V4L2 MPEG decoder API, but that's a huge job for such an old driver. Signed-off-by: Hans Verkuilhans.verk...@cisco.com This would break applications, especially VDR. I therefore strongly oppose this! You may introduce new APIs as you like, but don't break the existing ones that have worked for many years. Nacked-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Klaus -- 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: [linux-media] Re: [PATCH 05/13] [media] dvb/audio.h: Remove definition for AUDIO_GET_PTS
On 10.06.2011 15:18, Devin Heitmueller wrote: On Thu, Jun 9, 2011 at 9:07 AM, Andreas Oberrittero...@linuxtv.org wrote: ... implemented in *kernel* drivers for several generations of the dreambox. Well, let's see the source code to the drivers in question, and from there we can make some decisions on how to best proceed. Just a side note: VDR uses this (and others) in its full featured output devices. I'm not sure whether this discussion is aiming at completely doing away with these definitions, or if there will be a replacement. Just wanted to make you folks aware of this. Klaus -- 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: [linux-media] How to handle independent CA devices
On 09.09.2010 23:52, rjkm wrote: Hi, cards like the Digital Devices DuoFlex S2, cineS2 and upcoming hardware (octuple, network, etc.) have independent CA devices. This means that instead of having the stream routed from the frontend through the CI and only then into memory a stream can be sent from memory through the CI and back. So, the current device model does not fit this hardware. One could hide this fact inside the driver and send the stream from the frontend through the CI transparently to the API but this would prevent people from implementing new features like decoding a stream from a different DVB card, decoding streams from hard disk or even decoding several sub-streams from different transponders. The latter works with the current Windows driver but I have not implemented it in Linux yet. It also has to be supported by the CI modules. Some can decode 12 streams (6 times video/audio) at once. But decoding single streams already works fine. Currently, I am registering a different adapter for the CI. On a CineS2 with CI attached at the IO port I then have /dev/dvb/adapter[01] for the two DVB-S2 frontends and /dev/dvb/adapter2 just for the ca0 device. I am abusing the unused sec0 to write/read data to/from the CI module. For testing I hacked zap from dvb-apps to tune on adapter0 but use adapter2/ca0 to talk to the CI module. I then write the encrypted stream from adapter0/dvr0 into adapter2/sec0 and read the decoded stream back from adapter2/sec0. The encrypted stream of course has to contain all the PIDs of the ca_pmt. So, I would like to hear your opinions about how to handle such CA devices regarding device names/types, the DVB API and user libraries. Here's my 2ct as viewed from VDR: VDR already has mechanisms that allow independent handling of CAMs and receiving devices. Out of the box this currently only works for DVB devices that actually have a frontend and where the 'ca' device is under the same 'adapter' as the frontend. I could easily make it skip adapters that have no actual 'frontend' and set up separate cDvbCiAdapter objects for adapters that only have a 'ca' device and no frontend. However, VDR always assumes that the data to be recorded comes out of the 'dvr' device that's under the same adapter as the 'frontend'. So requiring that VDR would read from the frontend's 'dvr' device, write to the ca-adapter's 'sec' (or whatever) device, and finally read from that same 'sec' device again would be something I'd rather avoid. Besides, what if some PIDs are encrypted, while others are not? Should the unencrypted ones be read directly from 'dvr' and only the encrypted ones from 'sec'? That might mess with the proper sequence of the packets. As for decrypting data from several frontends through one CAM: I don't see this happening in VDR. Pay tv channels repeat their stuff often enough to find a slot where everything can be recorded. Others may, of course, welcome this ability, but I'd like to keep things simple in VDR. So I'm not against this, I just won't use it in VDR. As for recording encrypted and decrypting later: that's also something I don't see being used in VDR (again, mainly for KISS reasons). So, the bottom line is: I would appreciate an implementation where, given the configuration you described above, I could, e.g., tune using /dev/dvb/adapter0/frontend0, read the data stream from /dev/dvb/adapter0/dvr0 as usual, communicate with the CAM through /dev/dvb/adapter2/ca0 and (which is the tricky part, I guess) tell the driver or some library function to assign the CAM in /dev/dvb/adapter2/ca0 to the frontend|dvr in /dev/dvb/adapter0/frontend0|dvr0). Please forgive me if this sounds like a crazy request - I'm not a driver developer ;-) Klaus -- 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: [hg:v4l-dvb] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 10.05.2010 06:40, Patch from Klaus Schmidinger wrote: The patch number 14692 was added via Douglas Schilling Landgraf dougsl...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org This patch should not have been applied, as was decided in the original thread. I'm still waiting for any response to my new patch, posted in [PATCH] Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices) which replaces my original suggestion. Klaus -- From: Klaus Schmidinger klaus.schmidin...@tvdr.de Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. Priority: normal Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com Acked-by: Manu Abraham m...@linuxtv.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c |2 +- linux/drivers/media/dvb/frontends/cx24116.c |2 +- linux/include/linux/dvb/frontend.h |1 + 3 files changed, 3 insertions(+), 2 deletions(-) diff -r 31df1af24206 -r 0eabd1e76386 linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c --- a/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c Mon May 10 01:31:11 2010 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c Mon May 10 01:32:52 2010 -0300 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 +FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8 }, .release = gp8psk_fe_release, diff -r 31df1af24206 -r 0eabd1e76386 linux/drivers/media/dvb/frontends/cx24116.c --- a/linux/drivers/media/dvb/frontends/cx24116.c Mon May 10 01:31:11 2010 -0300 +++ b/linux/drivers/media/dvb/frontends/cx24116.c Mon May 10 01:32:52 2010 -0300 @@ -1496,7 +1496,7 @@ FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_2G_MODULATION | - FE_CAN_QPSK | FE_CAN_RECOVER +FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8 }, .release = cx24116_release, diff -r 31df1af24206 -r 0eabd1e76386 linux/include/linux/dvb/frontend.h --- a/linux/include/linux/dvb/frontend.h Mon May 10 01:31:11 2010 -0300 +++ b/linux/include/linux/dvb/frontend.h Mon May 10 01:32:52 2010 -0300 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB= 0x40, FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8= 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING= 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- Patch is available at: http://linuxtv.org/hg/v4l-dvb/rev/0eabd1e76386c37db6cef0a608901d3dd04a301f -- 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] Add FE_CAN_TURBO_FEC (was: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices)
Some (North American) providers use a non-standard mode called 8psk turbo fec. Since there is no flag in the driver that would allow an application to determine whether a particular device can handle turbo fec, the attached patch introduces FE_CAN_TURBO_FEC. Since there is no flag in the SI data that would indicate that a transponder uses turbo fec, VDR will assume that all 8psk transponders on DVB-S use turbo fec. Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-25 14:24:50.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB = 0x40, FE_HAS_EXTENDED_CAPS = 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_TURBO_FEC = 0x800, /* frontend supports turbo fec modulation */ FE_CAN_2G_MODULATION = 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING = 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-25 14:25:18.0 +0200 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 + FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_TURBO_FEC }, .release = gp8psk_fe_release,
Re: [linux-media] Re: [git:v4l-dvb/master] V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 04/21/10 09:58, Andreas Oberritter wrote: Hello Mauro, Mauro Carvalho Chehab wrote: Subject: V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices Author: Klaus Schmidinger klaus.schmidin...@tvdr.de Date:Sun Apr 11 06:12:52 2010 -0300 I wonder why this patch was applied without any modification. It seems like, as Manu pointed out, the flag should really indicate support for Turbo-FEC modes rather than just 8PSK (which is already a subset of FE_CAN_2G_MODULATION). Btw., there is also no FE_CAN_APSK_16, FE_CAN_APSK_32 or FE_CAN_DQPSK. Also, I'm unsure how to instruct a driver whether to choose Turbo-FEC mode or not in case it supports both DVB-S2 and what's used in the US. Third, it was stated that cx24116's support for Turbo-FEC was untested and probably unsupported. So I'd vote for reverting this patch until these issues are cleared. If my assumptions above are correct, my proposal is to rename the flag to FE_CAN_TURBO_FEC (as Manu proposed earlier) and remove it from cx24116.c. That's what I was intending to do - time permitting ;-) I was also surprised that the patch got applied, since I was in the middle of discussing this with Manu... Klaus -- 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: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 15.04.2010 22:21, Manu Abraham wrote: Hi Klaus, On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is FE_CAN_TURBO_FEC Well, when processing the NIT data in VDR, for instance, the possible modulation types that can be used according to the driver's frontend.h are QPSK, QAM_16, QAM_32, QAM_64, QAM_128, QAM_256, QAM_AUTO, VSB_8, VSB_16, PSK_8, APSK_16, APSK_32, DQPSK, There is nothing in frontend.h that would be in any way related to turbo fec (whatever that may be). Of course we can rename FE_CAN_PSK_8 to FE_CAN_TURBO_FEC, but wouldn't something like if (Modulation == PSK_8 !(frontendInfo.caps FE_CAN_TURBO_FEC)) return false; be even more irritating than a straight forward if (Modulation == PSK_8 !(frontendInfo.caps FE_CAN_PSK_8)) return false; After all it's if (Modulation == QAM_256 !(frontendInfo.caps FE_CAN_QAM_256)) return false; Please advise. Whatever you prefer is fine with me. All I need in VDR is a flag that allows me to detect whether a device can handle a given transponder's modulation. I don't really care how that flag is named ;-). FE_CAN_8PSK will be matched by any DVB-S2 capable frontend, so that name is very likely to cause a very large confusion. I chose FE_CAN_PSK_8 over FE_CAN_8PSK, because the modulation itself is named PSK_8. This allows for easily finding all PSK_8 related places with 'grep'. Personally I find the FE_CAN_8VSB and FE_CAN_16VSB misnomers, because the modulations are named VSB_8 and VSB_16, respectively. They should have been named FE_CAN_VSB_8 and FE_CAN_VSB_16 in the first place. But that's, of course, a different story... Klaus Schmidinger Another thing I am not entirely sure though ... The cx24116 requires a separate firmware and maybe some necessary code changes (?) for Turbo FEC to be supported, so I wonder whether applying the flag to the cx24116 driver would be any relevant With regards to the Genpix driver, i guess the flag would be necessary. Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com Other than for the naming of the Flag (which i suggest strongly to update the patch) and the application to the cx24116 driver, it looks appropriate; Acked-by: Manu Abraham m...@linuxtv.org --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-10 12:08:47.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB= 0x40, FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8= 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING= 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.0 +0200 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 + FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8 }, .release = gp8psk_fe_release, --- linux/drivers/media/dvb/frontends/cx24116.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.0 +0200 @@ -1496,7 +1496,7 @@ FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_2G_MODULATION | - FE_CAN_QPSK | FE_CAN_RECOVER + FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8 }, .release = cx24116_release, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More
Re: [linux-media] Re: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 18.04.2010 16:51, Manu Abraham wrote: On Sun, Apr 18, 2010 at 5:19 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 15.04.2010 22:21, Manu Abraham wrote: Hi Klaus, On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is FE_CAN_TURBO_FEC Well, when processing the NIT data in VDR, for instance, the possible modulation types that can be used according to the driver's frontend.h are QPSK, QAM_16, QAM_32, QAM_64, QAM_128, QAM_256, QAM_AUTO, VSB_8, VSB_16, PSK_8, APSK_16, APSK_32, DQPSK, There is nothing in frontend.h that would be in any way related to turbo fec (whatever that may be). Of course we can rename FE_CAN_PSK_8 to FE_CAN_TURBO_FEC, but wouldn't something like if (Modulation == PSK_8 !(frontendInfo.caps FE_CAN_TURBO_FEC)) return false; be even more irritating than a straight forward if (Modulation == PSK_8 !(frontendInfo.caps FE_CAN_PSK_8)) return false; After all it's if (Modulation == QAM_256 !(frontendInfo.caps FE_CAN_QAM_256)) return false; Please advise. Whatever you prefer is fine with me. All I need in VDR is a flag that allows me to detect whether a device can handle a given transponder's modulation. I don't really care how that flag is named ;-). Maybe I wasn't clear enough, why I stated that ... consider any DVB-S2 frontend: stb0899, cx24116, stv090x, ds3000 or any other any frontend .. All these devices are capable of demodulating 8PSK. Now, if people start adding capabilities that which the devices are capable, then it will cause a lot of problems for the applications themselves, since you don't get the differentiation between the frontends that you were originally looking for. Now looking at another angle .. consider the Genpix frontend, can it tune to 8PSK ? Yes, it can.. Eventually, it implies that, all DVB-S2 devices are 8PSK capable, but not all 8PSK capable devices are DVB-S2 capable. Since there are already FE_CAN_* flags for all but PSK_8, I guess it would make sense that all devices that support PSK_8 set the related FE_CAN_PSK_8 flag (or FE_CAN_8PSK, if you insist in continuing the suboptimal naming scheme), independent of the Turbo FEC thing. Now, assume the FE_CAN_PSK8 or FE_CAN8PSK flag; Does it really make any sense, when it is applied to the whole group of 8PSK frontends ? I guess not. You would require a flag that is capable of distinguishing between the S2 8PSK category and the other category. There already is such a flag: FE_CAN_2G_MODULATION. Looking back at history, originally France Telecom introduced the superior Error Correction scheme called Turbo Mode or so called Concatenated FEC mode on a 8PSK modulated carrier. This was a great approach, but they wanted to people to pay them a royalty and hence the general acceptance for it went down. In the initial phase, it was implemented in the Americas and for small clients alone. Eventually, the rest of the world wanted a royalty free approach and thus came LDPC which is just as good. So eventually while the difference between these 2 carriers is that while both are 8PSK modulated stream, the Error correction used with France Telecom's proprietary stream is Concatenated Codes, while for S2 and DVB.org it became LDPC. As you can see, the discriminating factor is the FEC, in this condition and nothing else. You will need a flag to discriminate between the FEC types, rather than the modulation, if things were to look more logical. I guess the problem, as I can see now, is that there is now way of telling from the SI data that a transponder uses 8psk turbo fec, or is there? Would it make sense to differentiate this in the following way: - an 8psk transponder on DVB-S is turbo fec - an 8psk transponder on DVB-S2 is *not* turbo fec ? So an 8psk/DVB-S transpoder will require a device that has FE_CAN_TURBO_FEC set, while an 8psk/DVB-S2 transpoder simply requires a DVB-S2 device (since there is no FE_CAN_PSK_8). Klaus -- 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] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com --- linux/include/linux/dvb/frontend.h.001 2010-04-05 16:13:08.0 +0200 +++ linux/include/linux/dvb/frontend.h 2010-04-10 12:08:47.0 +0200 @@ -62,6 +62,7 @@ FE_CAN_8VSB = 0x20, FE_CAN_16VSB= 0x40, FE_HAS_EXTENDED_CAPS= 0x80, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_PSK_8= 0x800, /* frontend supports 8psk modulation */ FE_CAN_2G_MODULATION= 0x1000, /* frontend supports 2nd generation modulation (DVB-S2) */ FE_NEEDS_BENDING= 0x2000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x4000, /* frontend can recover from a cable unplug automatically */ --- linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-04-10 12:18:37.0 +0200 @@ -349,7 +349,7 @@ * FE_CAN_QAM_16 is for compatibility * (Myth incorrectly detects Turbo-QPSK as plain QAM-16) */ - FE_CAN_QPSK | FE_CAN_QAM_16 + FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_PSK_8 }, .release = gp8psk_fe_release, --- linux/drivers/media/dvb/frontends/cx24116.c.001 2010-04-05 16:13:08.0 +0200 +++ linux/drivers/media/dvb/frontends/cx24116.c 2010-04-10 13:40:32.0 +0200 @@ -1496,7 +1496,7 @@ FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO | FE_CAN_2G_MODULATION | - FE_CAN_QPSK | FE_CAN_RECOVER + FE_CAN_QPSK | FE_CAN_RECOVER | FE_CAN_PSK_8 }, .release = cx24116_release, -- 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
[DVB] Sticky module dvb_pll
When I use the latest driver from http://linuxtv.org/hg/v4l-dvb (4d727d223236) and load all the modules I need, as in /sbin/modprobe firmware_class /sbin/modprobe i2c-core /sbin/insmod ./v4l1-compat.ko /sbin/insmod ./cx24113.ko /sbin/insmod ./s5h1420.ko /sbin/insmod ./videobuf-core.ko /sbin/insmod ./ttpci-eeprom.ko /sbin/insmod ./cx24123.ko /sbin/insmod ./saa7146.ko /sbin/insmod ./videodev.ko /sbin/insmod ./videobuf-dma-sg.ko /sbin/insmod ./saa7146_vv.ko /sbin/insmod ./mt352.ko /sbin/insmod ./ves1x93.ko /sbin/insmod ./dvb-core.ko /sbin/insmod ./stv0299.ko /sbin/insmod ./dvb-ttpci.ko /sbin/insmod ./budget-core.ko /sbin/insmod ./budget.ko /sbin/insmod ./b2c2-flexcop.ko /sbin/insmod ./b2c2-flexcop-pci.ko lsmod shows Module Size Used by dvb_pll16392 1 b2c2_flexcop_pci 14484 0 b2c2_flexcop 37004 1 b2c2_flexcop_pci budget 21508 0 budget_core15748 1 budget dvb_ttpci 351180 0 stv029914984 1 dvb_core 95724 5 b2c2_flexcop,budget,budget_core,dvb_ttpci,stv0299 ves1x9310884 2 mt352 10756 1 saa7146_vv 52352 1 dvb_ttpci videobuf_dma_sg18948 1 saa7146_vv videodev 44704 1 saa7146_vv saa714623816 4 budget,budget_core,dvb_ttpci,saa7146_vv cx2412318824 1 b2c2_flexcop ttpci_eeprom6656 2 budget_core,dvb_ttpci videobuf_core 23556 2 saa7146_vv,videobuf_dma_sg s5h142016388 1 b2c2_flexcop cx2411312420 1 b2c2_flexcop v4l1_compat18052 1 videodev w83781d34984 0 hwmon_vid 7040 1 w83781d iptable_filter 7552 0 ip_tables 17936 1 iptable_filter ip6_tables 19088 0 x_tables 21380 2 ip_tables,ip6_tables nfs 266964 1 lockd 72312 2 nfs nfs_acl 7680 1 nfs sunrpc197372 13 nfs,lockd,nfs_acl af_packet 26368 0 fuse 54044 1 loop 23044 0 dm_mod 66388 0 ppdev 13060 0 rtc_cmos 14752 0 rtc_core 24860 1 rtc_cmos rtc_lib 7040 1 rtc_core parport_pc 42428 0 parport40660 2 ppdev,parport_pc 8139too30976 0 sr_mod 21160 0 cdrom 38300 1 sr_mod i2c_ali153511268 0 8139cp 27392 0 i2c_ali15x312036 0 firmware_class 13696 3 b2c2_flexcop,budget,dvb_ttpci ali_agp11136 1 mii 9600 2 8139too,8139cp shpchp 37780 0 i2c_core 28820 15 dvb_pll,b2c2_flexcop,budget,budget_core,dvb_ttpci,stv0299,ves1x93,mt352,cx24123,ttpci_eeprom,s5h1420,cx24113,w83781d,i2c_ali1535,i2c_ali15x3 agpgart38580 1 ali_agp pci_hotplug33828 1 shpchp alim7101_wdt 11928 0 sg 39732 0 sd_mod 33048 4 ohci_hcd 27396 0 usbcore 152268 2 ohci_hcd edd14152 0 ext3 143880 2 mbcache13060 1 ext3 jbd61216 1 ext3 pata_ali 15620 3 libata164316 1 pata_ali scsi_mod 156404 4 sr_mod,sg,sd_mod,libata dock 15248 1 libata If immediately after that I do /sbin/rmmod dvb_ttpci /sbin/rmmod saa7146_vv /sbin/rmmod budget /sbin/rmmod b2c2_flexcop_pci /sbin/rmmod budget_core /sbin/rmmod stv0299 /sbin/rmmod b2c2_flexcop /sbin/rmmod videodev /sbin/rmmod videobuf_dma_sg /sbin/rmmod cx24113 /sbin/rmmod saa7146 /sbin/rmmod ttpci_eeprom /sbin/rmmod ves1x93 /sbin/rmmod s5h1420 /sbin/rmmod mt352 /sbin/rmmod v4l1_compat /sbin/rmmod dvb_core /sbin/rmmod dvb_pll ERROR: Module dvb_pll is in use /sbin/rmmod videobuf_core /sbin/rmmod cx24123 I get an error when trying to rmmod dvb_pll. lsmod then shows Module Size Used by dvb_pll16392 1 w83781d34984 0 hwmon_vid 7040 1 w83781d iptable_filter 7552 0 ip_tables 17936 1 iptable_filter ip6_tables 19088 0 x_tables 21380 2 ip_tables,ip6_tables nfs 266964 1 lockd 72312 2 nfs nfs_acl 7680 1 nfs sunrpc197372 13 nfs,lockd,nfs_acl af_packet 26368 0 fuse 54044 1 loop 23044 0 dm_mod 66388 0 ppdev 13060 0 rtc_cmos 14752 0 rtc_core 24860 1 rtc_cmos rtc_lib 7040 1 rtc_core parport_pc 42428 0 parport40660 2 ppdev,parport_pc 8139too30976 0 sr_mod 21160 0 cdrom 38300 1 sr_mod
Re: [linux-media] [DVB] compiling av7110 firmware into driver fails
On 05/18/09 22:33, Klaus Schmidinger wrote:
I always compile the current av7110 firmware into my driver,
so that I can have different driver/firmware versions to test
with. This used to work by doing
CONFIG_DVB_AV7110_FIRMWARE=y
CONFIG_DVB_AV7110_FIRMWARE_FILE=/home/kls/vdr/firmware/FW.current
in the v4l/.config file (where FW.current is a symlink to the
current firmware version).
With driver version c29ce3e2fc6a (2009-04-25) this still worked,
but with 0018ed9bbca3 (2009-05-16) it doesn't work any more.
Am I doing something wrong, or has this been broken?
Well, apparently nobody cares, so I've put together a patch
that fixes this, and attached it to this message - just in case
I'm not the only one who thinks removing this code was a bad idea...
This is a reverse diff, so apply it with 'diff -R'.
Klaus
diff -ruN v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/Kconfig v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/Kconfig
--- v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/Kconfig 2009-04-24 21:57:56.0 +0200
+++ v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/Kconfig 2009-05-12 18:13:13.0 +0200
@@ -28,25 +28,12 @@
download/extract it, and then copy it to /usr/lib/hotplug/firmware
or /lib/firmware (depending on configuration of firmware hotplug).
- Say Y if you own such a card and want to use it.
-
-config DVB_AV7110_FIRMWARE
- bool Compile AV7110 firmware into the driver
- depends on DVB_AV7110 !STANDALONE
- default y if DVB_AV7110=y
- help
- The AV7110 firmware is normally loaded by the firmware hotplug manager.
- If you want to compile the firmware into the driver you need to say
- Y here and provide the correct path of the firmware. You need this
- option if you want to compile the whole driver statically into the
- kernel.
+ Alternatively, you can download the file and use the kernel's
+ EXTRA_FIRMWARE configuration option to build it into your
+ kernel image by adding the filename to the EXTRA_FIRMWARE
+ configuration option string.
- All other people say N.
-
-config DVB_AV7110_FIRMWARE_FILE
- string Full pathname of av7110 firmware file
- depends on DVB_AV7110_FIRMWARE
- default /usr/lib/hotplug/firmware/dvb-ttpci-01.fw
+ Say Y if you own such a card and want to use it.
config DVB_AV7110_OSD
bool AV7110 OSD support
diff -ruN v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/Makefile v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/Makefile
--- v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/Makefile 2009-04-24 21:57:56.0 +0200
+++ v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/Makefile 2009-05-12 18:13:13.0 +0200
@@ -19,12 +19,3 @@
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/
EXTRA_CFLAGS += -Idrivers/media/common/tuners
-
-hostprogs-y := fdump
-
-ifeq ($(CONFIG_DVB_AV7110_FIRMWARE),y)
-$(obj)/av7110.o: $(obj)/av7110_firm.h
-
-$(obj)/av7110_firm.h: $(obj)/fdump
- $(obj)/fdump $(CONFIG_DVB_AV7110_FIRMWARE_FILE) dvb_ttpci_fw $@
-endif
diff -ruN v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/av7110.c v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/av7110.c
--- v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/av7110.c 2009-04-24 21:57:56.0 +0200
+++ v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/av7110.c 2009-05-12 18:13:13.0 +0200
@@ -1521,20 +1521,6 @@
return 0;
}
-#ifdef CONFIG_DVB_AV7110_FIRMWARE_FILE
-#include av7110_firm.h
-static void put_firmware(struct av7110* av7110)
-{
- av7110-bin_fw = NULL;
-}
-
-static inline int get_firmware(struct av7110* av7110)
-{
- av7110-bin_fw = dvb_ttpci_fw;
- av7110-size_fw = sizeof(dvb_ttpci_fw);
- return check_firmware(av7110);
-}
-#else
static void put_firmware(struct av7110* av7110)
{
vfree(av7110-bin_fw);
@@ -1583,8 +1569,6 @@
release_firmware(fw);
return ret;
}
-#endif
-
static int alps_bsrv2_tuner_set_params(struct dvb_frontend* fe, struct dvb_frontend_parameters *params)
{
diff -ruN v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/av7110_hw.c v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/av7110_hw.c
--- v4l-dvb-c29ce3e2fc6a/linux/drivers/media/dvb/ttpci/av7110_hw.c 2009-04-24 21:57:56.0 +0200
+++ v4l-dvb-0018ed9bbca3/linux/drivers/media/dvb/ttpci/av7110_hw.c 2009-05-12 18:13:13.0 +0200
@@ -198,29 +198,10 @@
/* we cannot write av7110 DRAM directly, so load a bootloader into
* the DPRAM which implements a simple boot protocol */
-static u8 bootcode[] = {
- 0xea, 0x00, 0x00, 0x0e, 0xe1, 0xb0, 0xf0, 0x0e, 0xe2, 0x5e, 0xf0, 0x04,
- 0xe2, 0x5e, 0xf0, 0x04, 0xe2, 0x5e, 0xf0, 0x08, 0xe2, 0x5e, 0xf0, 0x04,
- 0xe2, 0x5e, 0xf0, 0x04, 0xe2, 0x5e, 0xf0, 0x04, 0x2c, 0x00, 0x00, 0x24,
- 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x34,
- 0x00, 0x00, 0x00, 0x00, 0xa5, 0xa5, 0x5a, 0x5a, 0x00, 0x1f, 0x15, 0x55,
- 0x00, 0x00, 0x00, 0x09, 0xe5, 0x9f, 0xd0, 0x7c, 0xe5, 0x9f, 0x40, 0x74,
- 0xe3, 0xa0, 0x00, 0x00, 0xe5, 0x84
[DVB] compiling av7110 firmware into driver fails
I always compile the current av7110 firmware into my driver, so that I can have different driver/firmware versions to test with. This used to work by doing CONFIG_DVB_AV7110_FIRMWARE=y CONFIG_DVB_AV7110_FIRMWARE_FILE=/home/kls/vdr/firmware/FW.current in the v4l/.config file (where FW.current is a symlink to the current firmware version). With driver version c29ce3e2fc6a (2009-04-25) this still worked, but with 0018ed9bbca3 (2009-05-16) it doesn't work any more. Am I doing something wrong, or has this been broken? Klaus -- 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
