[linux-dvb] [PATCH] Multi protocol support (stage #1)

Johannes Stezenbach js at linuxtv.org
Thu Jun 1 23:20:11 CEST 2006

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?


More information about the linux-dvb mailing list