|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 07/13/2012 12:07 AM, Steven Toth wrote:
Resend in plaintext, it got bounced from vger. On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth <stoth@xxxxxxxxxxxxxx> wrote:Is there anyone who could say straight now what is best approach and where to look example?I don't have an answer but the topic does interest me. :) Nobody understands the relationship between the bridge and the sub-component as well as the bridge driver. The current interfaces are limiting in many ways. We solve that today with rather ugly 'attach' structures that are inflexible, for example to set gpios to a default state. Then, once that interface is attached, the bridge effectively loses most of the control to the tuner and/or demod. The result is a large disconnect between the bridge and subcomponents.
I agree that mostly. For example that GPIO. It fits very poorly for interfaces that are highly given hardware design dependent like GPIOs. You can code logic like GPIO0 is LED, GPIO0 is tuner reset, GPIO0 is LNA and then set that logic in attach(). Due to that I am looking for better alternative.
Why limit any interface extension to GPIOs? Why not make something a little more flexible so we can pass custom messages around? get(int parm, *value) and set(int parm, value) Bridges and demods can define whatever parmid's they like in their attach headers. (Like we do for callbacks currently). For example, some tuners have temperature sensors, I have no ability to read that today from the bridge, other than via I2C - then I'm pulling i2c device specific logic into the bridge. :(
Yes! indeed, it is only possibly just like you said. Fortunately this kind of properties are not very common. Temperature is offered by many tuners, but there is no much need for that info in bridge. Maybe force sleep or switch powers totally off by using GPIO to prevent overheat.
It would be nice to be able to demod/tunerptr->get(XC5000_PARAM_TEMP, &value), for example. Get/Set I/F is a bit of a classic, between tuners and video decoders. This (at least a while ago) was poorly handled, or not at all. Only the bridge really knows how to deal with odd component configurations like this, yet it has little or no control.
IF information is now set tuner on attach() and then tuner delivers that info to demodulator via .get_if_frequency() which is member of tuner ops. Technically that solution works. If hardware design based IFs are not given as parameter on tuner attach() tuner should use tuner default IFs which are likely quite correct.
I'd want to see a list of 4 or 5 good get/set use cases though, with some unusual parms, before I'd really believe a generic get/set is more appropriate than a strongly typed set of additional function pointers.
Generally speaking for that set/get, I sent mail about ~same issue yesterday.
http://www.spinics.net/lists/linux-media/msg50202.htmlThere is set_property() and get_property() callbacks defined for FE already. But those are not used. My opinion is that those callbacks should be changed to deliver data for demodulator and for tuner too instead of current method - which is common huge properties cache structure shared between all sub-drivers. I don't like it all as it is stupid to add stuff that common structure for every standard we has. Lets take example device that supports DVB-C and other device supports ISDB-T. How many common parameters we has? I think only one - frequency. All the others are just waste.
What I think I am going to make new RFC which changes that so every parameter from userspace is passed to the demodulator driver (using set_property() - change it current functionality) and not cached to the common cache at all. Shortly: change current common cache based parameter transmission to happen set parameter to demodulator one by one.
What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface?
I sent PATCH RFC for DVB API to add LNA support yesterday. It is new API parameter. User could select ON/OFF/AUTO and on AUTO mode driver should make decision, likely taking signal measurements etc. New callback is added for frontend. If bridge likes to handle LNA it sets that callback in order to get user requests. When bridge gets that set_lna() callback it examines what user request and likely sets GPIOs.
regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html