Re: DSS display-new custom enable/disable hooks

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]