[linux-dvb] [PATCH] Multi protocol support (stage #1)
abraham.manu at gmail.com
Thu Jun 1 23:47:59 CEST 2006
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. :-(
More information about the linux-dvb