Johannes Stezenbach wrote:
Apart from the S2 stuff (haven't looked at it in this
version of the patch), there are still a couple of
things which I don't like. Most of them I pointed
out earlier already, but to summaryize and give
some additional explanation:
- too much unnecessary capabilites stuff; I receive a private
mail from Trent and answered:
> See, the DVB Wiki lists a number of applications. You can check them
> all, not one of then looks at fe_caps_t. Why should they?
> If fe_type_t says it's e.g. a DVB-T frontend, that's all the
> application needs to know.
Agreed, an application that does use DVB-T doesn't need to query
capabilities. But that doesn't mean others have to suffer ?
Or do you mean to remove only the capabilities that which is relevant to
DVB-T ?
>
> I realise it's different for ATSC, so we have to come up with
> a way to handle it. However, adding a ton of totally
> superflous DVB capability cruft to the API is IMHO wrong.
> (This is just my personal opinion, of course, if a number
> of people vote for it I will simply be overruled.)
>
> ATSC is different than DVB, so needs different handling.
(Well, the DVB-S2 standard contains optional parts, so it
seems useful to be able to query this, but for the mandatory
parts and the other DVB standard it just is NOT useful.)
- _IGNORE values: IIRC you said the purpose is to avoid unnecessary
I2C bus traffic for FE_GET_PARAMS; however I think the amount
of I2C bus traffic is insignificantly low, if you disagree
then please back it up with numbers (how many bytes
transferred/registers read for FE_GET_PARAMS?)
On some devices having an onboard MCU, it won't just query the field
that which is in the API, so it has to bent according to the API. In
this "bending " scenario, many things are lost. But even bent than also
the API does additionally tax the device.
Well at least on one MCU based design you can find many crying out
loudly on the ML about i2c communication errors.
Well, that's my POV, if we can reduce some parameters to be queried to
make the driver behave at least a bit better, then why not ?
- you patch contains changes which are independent of
the API change (enum tuner_param, struct tuner_state etc.):
please move them to a seperate patch
You are right. Ok, i will separate it out.
- struct dvbs_params etc. still have superflous pad
There were comments that the padding on all to make it look similar (to
make it look consistent)...
Well, i don't mind removing that pad.
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
