On 26/09/13 15:37, Dr. H. Nikolaus Schaller wrote: >>> Although one could argue that one is just controlling the GPIO and the other >>> one is controlling some regulator... >> >> Sorry, didn't understand that one... > > I meant that there could be a differece between enable/disable and power-on/off > (e.g. retaining register values vs. loosing everything). But I can't imagine that for > a simple video amplifier. Ah, I see. I'd still say there's just enable/disable from outside point of view. It's the driver's job to make things work so that configuration values are retained. If the hardware component is turned off so that it loses register values, the driver should first store the configuration into memory. So internally there may be different power levels, maybe some kind of timers to switch the component totally off if it's been disabled for some time, or such. Externally, I don't think those need to be visible. > Well, we can't boot w/o the board file yet for other reasons, i.e. a DT only > approach isn't our target yet. Sure, I'm fine with board file only version. My point was just that the solution should not be such that it's impossible to support with DT. For example, callbacks to board files are not possible with DT, so a solution that relies on callbacks to board files will not be accepted. And similarly board init calls are not supported with DT, so not acceptable. >> I don't want to make this more confusing, but... I wonder about the >> connector_type field. It's only function is to pass the value to VENC, >> which will then work differently. And it's also something that cannot be >> changed at runtime. Perhaps that, too, should be moved to VENC's >> platform data. > > I was also thinking about this topic. Well, the connector type is correctly > a property of the connector... But it logically controls some registers > in the DAC Output stage. So I had thought that the opa362 driver will > hand it over to the VENC and could check if it is really a composite > video (since AFAIK the OPA can't be used in a S-Video sytem). > But that again would be another chain of information flow from the > connector to the VENC making their APIs dependent. Right. I'm a bit leaning towards having it in the VENC platform data, and removing it from the connector. Well, it's not directly related to the issue at hand. You may just pass the connector type through OPA, and we can look at changing the connector type later. But if you want to have a try with the connector type at the same time, please go ahead. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
