Hello Jacopo and Linus,
On Monday, May 29, 2017, jmondi wrote:
> > > We can handle 'bi-directional' pins with static tables in our pin
> > > controller driver and not have it anywhere in DT.
> >
> > This sounds like a viable approach.
> >
> > I just want to know if "output-enable" is the right name?
> > "output-buffer-enable"?
>
> Great! Thanks!
>
> On naming: if we need "output-buffer-enable" should we add
> "input-buffer-enable" as well?
>
> Currently we are using "input-enable" to pair with "output-enable",
> but as you said, just "output-enable" when "output-high" and
> "output-low" are there already seems a bit confusing.
> At the same time "input-buffer-enable" seems to actually be just
> electrically equivalent to "input-enable", so adding it is a bit of a
> waste as well.
Here is what I think:
In the case of this driver, after we remove the 'bi-directional'
properties and hide the other odd-ball pin configurations in an internal
table, we are left with the MTU2 timer pins that can be either input or
output depending on what you want to do with them.
* If you want to use a MTU2 channel as a PWM, you set the pin as an
output.
* If you want to use a MTU2 channel as a input capture, you set the
pin as an input.
They are simply "direction-input" and "direction-output" properties that
don't really need to talk about "buffers".
But, instead of making any new properties, for the Renesas driver, let's
just stick with what already exists today:
* If you want a MTU2 channel as a PWM: select "output-low"
* If you want a MTU2 channel as a input capture: select "input-enable"
Side Note: You can also use output-high in addition to output-low
because it doesn't matter (the driver can't set the pin level anyway
because as soon as you assign the pin to MTU2, the MTU2 controls the
pin, not the PFC). So the Renesas driver can check for both.
Chris
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
