On 11/30/23 07:20, Nuno Sá wrote:
On Thu, 2023-11-30 at 15:36 +0200, Andy Shevchenko wrote:
On Thu, Nov 30, 2023 at 11:20:32AM +0100, Nuno Sá wrote:
On Wed, 2023-11-29 at 21:55 +0100, Linus Walleij wrote:
On Wed, Nov 29, 2023 at 5:08 PM Nuno Sá <noname.nuno@xxxxxxxxx> wrote:
Cool, I actually thought that having the direction + get/set stuff would be
weird
given the fact that we can only PULL_LOW or HIGH_Z the pins.
There are several drivers in the kernel that implement .set_config(),
it's existing and should be enabled if it has uses.
Yeah, it might make sense to support it specially for the input case. AFAICT, if
I
use the .set_config() (but from a quick look I think we will need to add support
for
it in gpiolib for the high-z configuration), then I can't use the gpio_regmap
stuff.
As the driver stands I don't think I could do it anyways because setting gpio2-3
and
alert requires to write 0 on the register rather than 1. But again, I'm still
very
suspicious about the whole thing. The datasheet states:
"GPIO1-GPIO3 and ALERT all have comparators monitoring
the voltage on these pins with a threshold of 1.28V even when
the pins are configured as outputs."
But we can't really set the direction for gpio2-3 and the alert pins (only
getting
the level and setting it as PULL_LOW or HIGH_Z. gpio1 is the only one where we
can
configure it as input or open drain ouput. Bah, I'll try to see if someone
internally
can shed some light on this.
I have better proposal. If these GPIOs are not needed for the main
functionality of the hardware, can we just left it out for now and implement
later if required?
Well, I did spent some time on the gpio thing so I would like to have it in but yeah,
no hard feelings if it does not go in.
Problem with that is that it may end up not being used at all ... and thus start
bit-rotting immediately.
Guenter
