Johannes Stezenbach wrote:
On Mon, May 29, 2006, Manu Abraham wrote:
Johannes Stezenbach wrote:
- 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 ?
IMHO the smaller an API is, the better.
ACK, with the last change (multiproto7), i think it is now reduced to
the smallest, IMHO.
Anything smaller would break it. Have some minor changes to it, since
rolloff can be removed , since it is present in matype1. A small comment
change also is needed.
Hint: The A in API is for application. If an application
doesn't need it, then don't put it inthe API.
Of course I can only draw from my personal experience
what an application might need, if someone can give good
reasons to have all these capabilities then we can add them.
(Also: The less new stuff in the API, the less needs to be
implemented for all the existing frontends which need to
support the new API.)
ACK. The only other addition is supporting multistandard device support.
If that is removed, well it would be hard to support them. Otherwise for
devices that support this the drivers will have to resort to something ugly.
- _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 ?
Working around hardware bugs in the API doesn't sound right.
Ok, if you are of that view, well i don't mind removing the IGNORE.
I suggest to work around in the implementation by taking
some values from shadow registers instead of reading them
:-(
Unfortunately there are no shadow registers, it is completely hidden
behind a pseudo bridge.
via i2c. But IIRC for some Twinhan the problem is not the
amount of data transferred but the timing of the transfer
(i.e. you can't read while the MCU is still busy trying
to lock on a signal). Right?
Yes, the other problem also exists, other than while tuning. :-(
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
