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. 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.) > >- _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. I suggest to work around in the implementation by taking some values from shadow registers instead of reading them 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? Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
