Johannes Stezenbach wrote:
On Sat, May 06, 2006, Manu Abraham wrote:
Johannes Stezenbach wrote:
On Fri, May 05, 2006, Manu Abraham wrote:
+/**
+ * Supported Delivery systems, some devices
+ * are capable of supporting multiple delivery systems.
+ *
+ * FE_DELSYS_IGNORE, causes the delivery system
+ * not to be queried.
why is IGNORE useful?
As Trent explained it is used to query supported delivery systems
via GET_CAPS. So FE_DELSYS_IGNORE should be renamed to
FE_DELSYS_QUERY // use with FE_GET_CAPS to get bit set of delivery systems supported by hw
Well, he got it wrong. Well originally in the initial implementation
that was there, it was like that, but due to his changes/ideas only it
did not make any sense and had to be dropped. I did explain what it was
in my last mail. i don't know where Trent got that idea.
+enum fe_matype {
+ FE_MATYPE_IGNORE = (0 << 0),
+ FE_MATYPE_TRANSPORT = (1 << 0),
+ FE_MATYPE_GENERIC_PACKET = (1 << 1),
+ FE_MATYPE_GENERIC_CONTINUOUS = (1 << 2),
+ FE_MATYPE_RESERVED = (1 << 3),
+ FE_MATYPE_AUTO = (1 << 31)
+};
enum fe_matype isn't used anywhere
also, please always spell out non-obvious acronyms in a comment
(probably "mode adaption type")
But EN 302 307 defines MATYPE as a two-byte field, this
enum fe_matype is just the 2bit TS/GS field of the
whole MATYPE.
Form these 3 and
You wanted to say something? ;-)
It was around 4 - 5 AM, and my system said powerfail shutdown.. ;-)
For the frontend we can deduce the params from these values. Basically
we need to know the slope (ie, the Rolloff Rate, but it is conveniently
described that those slopes will be used for these mentioned types only.
So rather than putting numbers, names sounds much better). The rest of
the stuff needs to go into the demux and some are just a userspace
specific only. (ie, the application tells the demux what it needs, there
needs to be other changes than to the demux too. That was the one i
talked to you a couple of days along with Ralph, on an earlier mail, for
which you said you weren't interested) It has got nothing to do with the
demod.
Well, to put it quite right, to use DVB-S2, Applications have to change
, whatever it might be .. There is no shortcut using FRONTEND2 etc,
since there are other parameters what userspace will need to tell the
DVB-API as a whole, rather than the frontend itself.(Ref: D4 BBHeader EN
302 307, Table D2, p 52). If there are drivers and applications going in
for a workaround, they will surely be DVB-S2 incompatible.
+
+/**
+ * Supported Modulations.
+ * Some devices support multiple modulation types
actually, most demods do
+enum fe_modulations {
I prefer the singular for enum type names.
But that already exists, and did not want to tamper that.
That's actually another good reason to change the
name, people will confuse enum fe_modulation and
enum fe_modulations all the time.
Maybe fe_mod_types?
Ok, will change to fe_mod_types.
+enum fe_modcod {
+ FE_MODCOD_DUMMY_PLFRAME = 0,
enum fe_modcod isn't used anywhere except the
decode_dvbs2_modcod() helper function. Either
use it in the API or move it to dvb_frontend.h.
Compliant drivers uses the modcod straight away. I was still working on
the STB0899. I was of the thought would add it alongwith it.
But it isn't *used* anywhere in the API. Did you mean
to add a modcod field to dvbs2_params ?
If not, then why is fe_modcod in frontend.h?
I will be putting it into the dvbs2 struct. Have only 2 hands and a
complex device with 2 chips and many people hitting left and right (many
thanks to the people who did and are still helping) and there was some
posts on the ML, which did not seem right for the same, which would've
got me involved sending long posts. (For some people it might be fun
just to poke here and there without even going through the specs) So
only i did not comment on someone's earlier comment. Did not have the
time for that. Sorry, wasn't anything else
+enum fe_hierarchy_info {
+enum fe_rolloff {
+enum fe_interleaver {
EN 300 468 V1.7.1 combines these in a single
hierarchy_information field. Is it useful to
split them into three enums?
Well, i originally had it as one only, after the innumerous discussions
it became like that.
OK
+struct dvbs2_params {
+ __u32 symbol_rate;
+
+ enum fe_modulations modulation;
+ enum fe_fecrates fecrate;
+ enum fe_stream streamtype;
+ enum fe_fecrates coderate_HP;
+ enum fe_fecrates coderate_LP;
do we really have three fecs?
also, if you have hierachical modulation you need a way to
select the HP or LP stream
streamtype is used for that.
Ah, I missed that (was looking for "priority")...
Three fecs is still one too many, right?
Yup, Thanks.
I don't fully understand the DVB-S2 spec yet, but I think
the way to select the stream is by using an 8bit
input_stream_identifier.
H.3 describes it. 8 bits isn;t needed, anyway boiling down to the demod,
that doesn't happen, it is a simple knob to select between the streams.
There aren't many S2 chipsets. ST has STB0899, Broadcom has 4500.
Croadcom doesn't sell to PC card manufacturers, but only STB vendors.
There is Conexant also as i heard, but a very buggy chip. Well the S2
devices do have bugs. Even the datasheets have bugs.
You mean the dvbs2_delivery_system description from EN 300 468
is irrelevant for the current hardware? I.e. availbale
DVB-S2 tuners only support "normative broadcast mode"?
No, As i understood from the specs, Normative broadcast mode uses a
larger slope and larger Transmit powers. For other modes, to reduce
transmit powers, hence a steeper fall off, for the Nyquist filter.
(Nyquist Filter Rolloff Rate "Alpha") Continuing just below down..
(I wouldn't be surprised).
It also explains why enum fe_matype isn't used. I vote
for removing it for now.
It is used, for setting up the Rolloff rates. I just used it in
conjunction with the names so that it looks a bit cleaner.
Ref: P 18, 302 307. The STB0899 does support it. It is completely
according to the specs and not one step to the left or right.
It adheres to it completely, to the specs
I have the enumeration like this, which maps it to the STB0899 like
this. The demod needs it for the slope. ie to find the distance between
the 2 carriers, similarly to as in DVB-T, but the addition is that here
the didfferent cases of slopes are used for different causes and the
enumeration is for the causes rather than mentioning the slope. (I think
humans are better at remembering names rather than numbers)
enum stb0899_rrc_alpha {
STB0899_RRC_20,
STB0899_RRC_25,
STB0899_RRC_35
};
At the demux level, it applies in accordance to
Well, i can remove all these , no problem for me, only that it will
result in a hopeless driver. Maybe someone will cut and paste the
complete nonsense from the ST code, without understanding what it does even.
The state of the STV0299 is like that only. A nice chip, but a sad
driver. There are many cases where politics and some rampant comments
from some places have caused for drivers to be in the bad state. However
good an API might be it is as good as the drivers only. The people who
make such rampant comments they won't interested in those drivers even
as they are in some other geographical region, pushing for something
that do not exist even.
What you were looking at the rest of the Mode Adaptation, it has to be
in the demux, so there will be an enumeration in the demux API too. Well
as it is for the frontend API itself there has been more noise than
useful comments, wondering what it would be for the demux API next.
We can't do the demux specific part of the Mode Adaptation in the
frontend. Can we ? This i explained to Trent on his original post. Still
he doesn't understand. You can see the very same mail on the ML.
Sorry for the rant, really frustrated on the repeated comments. Sad
that the original poster didn't understand what it meant and still
doesn't, seeing today's post again. Well, people who read the comments
can understand it easily.
+struct pad_params {
+ __u8 pad[512];
+};
just scratch this struct and put the pad directly in the union
It would make it look a bit consistent though. Everyone else really
liked it, except for your comment and Trent's.
I prefer that if you look at the union you immediately
see that it is padded to N bytes.
I agree, what about struct pad128 ? that will maintain consistency as well.
+struct dvb_frontend_cap {
+ char name[128];
+
+ __u32 frequency_min;
+ __u32 frequency_max;
+ __u32 frequency_stepsize;
+ __u32 frequency_tolerance;
+ __u32 symbol_rate_min;
+ __u32 symbol_rate_max;
+ __u32 symbol_rate_tolerance;
+
+ enum fe_delsys delivery;
is this a bitset?
OK Trent explained to me how it works.
How about not deprecating FE_GET_INFO, but just deprecate the "type"
and "caps" fields of struct dvb_frontend_info?
No need to query name and min/max stuff over and over...
Why ? He got it wrong ! What if a multi standard tuner has different
min/max values ?
But there is enough explanation that i have put in the comments. I don't
know why Trent interpret's it differently.
Or is more comments necessary ? But i don't know what more can be
written for a flag in there, in each struct.
Delivery System, Yes. There can be multistandard devices
+ enum fe_inversion inversion;
What does the inversion do? dvb-core emulates FE_INVERSION_AUTO
if the hw can't do it, so caps would always report full
capabilities here, right?
Well, the driver uses it's own algorithm. And cannot use the
dvb_frontend_thread.
It has separate search algorithms for DVB-S and DVB-S2 modes
static int stb0899_get_caps(struct dvb_frontend *fe,
struct dvb_frontend_cap *caps)
{
switch (caps->delivery) {
case FE_DELSYS_DVBS:
stb0899_get_dvbs_caps(fe, caps);
break;
case FE_DELSYS_DSS:
stb0899_get_dss_caps(fe, caps);
break;
case FE_DELSYS_DVBS2:
stb0899_get_dvbs2_cap(fe, caps);
}
return 0;
}
This misses the FE_DELSYS_IGNORE case...
I did say that it was untested. Yes, but i intended to do a enumeration
which maps to the frontend API like this,
enum stb0899_delsys {
STB0899_DELSYS_IGNORE = 0,
STB0899_DELSYS_DVBS = mapped val,
STB0899_DELSYS_DSS = mapped val,
STB0899_DELSYS_DVBS2 = mapped val
};
BTW, is anyone working on a driver for a DVB-S2 tuner?
Or does anyone have a data sheet for such a device?
Yes, quite a lot of people have it now (as i understand, other than some
people around us), well that chips is something to make people real
crazy. The documents are available under NDA only.
Well, i have done ~ 3000 lines of code for the STB0899 + STB6100. I got
approval from Twinhan to publish the driver under OSS.
There are 4 cards now, (1) The Twinhan card (not the DST, but a brand
new one) (2) KNC1 (SAA7146 based) (3) TechnoTrend (SAA7146 based) (4)
Micronas (nGene) But none of these cards are out for purchase for the
public as of now, some few sample cards were sold/given by all these
vendors.
Currently, myself is taking a go at it. Ralph is having a nGene. For
testing we have a KNC1 and a Twinhan. We can test with the nGene too.
As far as i heard some people are trying to cut and paste the Windows
code for a minimal Linux DVB-S driver and trying to get an approval from
the vendor (from the ST sample code), but the problem is that the
original code for the DVB-S2 specific parts (It has 2 DSP's builtin, i2c
is really different) is not from ST itself, forgetting about the vendor
itself, but from a 3rd party and hence cannot be cut n' pasted.
But we (myself, Christoph, Andrew and Ralph) are working on it (you
might've seen the math functions, it all goes in there, there are more)
(Other's did help help in fixing various Areas, people who can be
mentioned are Marcel (mws) Sigmund and Julian providing various
feedbacks and bug hunting etc) Most of the things are done, it needs
some fixing here and there due to some bugs.
It has a Silicon Tuner based on the STB6100, hence the earlier
TUNER_RE_FACTORING by Andrew, which additionally took care of the PLL
thing too.
Regarding the Broadcom device, i think there is a driver (genpix) which
has a dst style frontend. But as i looked at the code , i didn't see any
S2 specifics.
Thanks for this info!
No issues, you are welcome.
Wow, didn't think that so much was there to be fixed ! Thanks for taking
the time to hunt them down. Taking a deep breath now.
I was surprised that so many Ack'ed this in it's current state,
but then I guess you all have been discussing this in private
mail and irc and you were all happy with it already.
I'm sorry that my late commenting delays this further.
It was quite a lot of work, what is just seen in this change is just
only the tip of the iceberg. We had so many issues, we had to get in so
many things fixed. Well, i was expecting that you would comment a bit
earlier. But anyway no probs. Since we certainly are in for an
improvement. Well , it touched almost all delivery systems and it was
not very easy.
No one can be blamed for that. Everyone did try their best to get the
best of their feedbacks.
I'm still not sure about the DVB-S2 API. So I would prefer
if the whole change would not be merged into mainline
until there is at least one fully functional DVB-S2 driver
in the tree (i.e. keep it in a v4l-dvb-s2 repo for now).
It will be too large a change and hope i would not have to redo the tree
again as it happened earlier. Would be nothing more than hard work
alone. Since you say it, i will keep it in the stb0899 repository, in
the forests @ linuxtv.org or at, thadathil.net ;-)
It will be a huge change though, to merge it that way. IMHO, it should
be taken in steps, the individual pieces. Well, i am open to either
ways. Maybe marking EXPERIMENTAL is better ?
If you think this is too much hassle, then at least
mark the DVB-S2 stuff as "EXPERIMENTAL / DO NOT USE / SUBJECT
TO CHANGE WITHOUT NOTICE" (in capitals). So that you can
break binary and source compatibilty for the DVB-S2 part
with clean conscience until it is proven stable.
Agreed?
Even if it is in a separate repo, it has to be marked EXPERIMENTAL, IMHO.
Almost dead now. ;-)
Thanks,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
