On 16/04/2020 02:37, Drew Fustini wrote:
On Wed, Apr 15, 2020 at 08:59:09AM -0500, Robert Nelson wrote:
On Wed, Apr 15, 2020 at 8:47 AM Grygorii Strashko
<grygorii.strashko@xxxxxx> wrote:
On 15/04/2020 16:20, Robert Nelson wrote:
Hi Grygorii,
On Wed, Apr 15, 2020 at 8:15 AM Grygorii Strashko
<grygorii.strashko@xxxxxx> wrote:
For this platforms the dynamic GPIO muxing/configuration is not supported, and GPIO block by itself
does not provide such functions as pullup/pulldown.
Correct, that's the state today, while Drew is investing time into
trying to figure out how to properly extend this feature into our
platform.
Sry, but it's not clear what's the final target (at least from public part of this thread).
We are mainly targeting am335x based devices. Today (well last few
years) we've utilized a "hack-ish" kernel module (bone-pinmux-helper)
to allow users to overide/change the pinmux-ing directly from
user-space... (This evil module allows us to specify a list of
options for each pin, thus users can easily configure specifies of the
pin, aka gpio_pd/gpio_pu/etc from user-space...). Since that time,
mainline has now grown a generic gpio pull-up/pull-down functionality,
with the ability to re-control these values directly from a generic
gpio library (libgpiod).
Hello Grygorii -
As Robert described, I wanted to make us of the new support for bias
flags in the gpiolib uapi which allows userspace libraries like libgpiod
set pull-up or pull-down on lines [0].
Is there no way for gpio-omap to call into the pinctrl-single backend to
set the bias bits (PULLUDEN and PULLTYPESEL) in pad control registers?
I'm not sure how this could help ;( If there were dedicated GPIO pins - then yes.
But on all Sitara SoCs the pins are multi-functional and GPIO is not a primary function.
So to use some PIN as GPIO the MUX_MODE has to be *carefully* changed - and for this DT updated.
Which, in turn, means proper pull-up/pull-down can also be configured at the same time.
And all above is static configuration - even if it involves connecting different modules to BB.
(Changing MUX_MODE from user space sounds very unsafe for me.)
Next, how it can be ensured that User space will not corrupt PIN which is not a GPIO?
Usually only set of GPIOs per bank are really muxed out as GPIO and, right now, there is no
way to say which ones, because pinmuxing and GPIOs configurations are going through different frameworks.
Lets say request come to configure GPIO1.20 to PULLUDEN - there is no way to be sure this pin
is actually pinmuxed as GPIO and not rgmii2_td1. And everything depends on DT and User qualification.
Now this is safe - just User will not get what he wants if he misses with GPIO number.
But if GPIO driver will be allowed to go and change some pinmux - it can kill rgmii2.
Or do you have more global ideas for pinmux management?
--
Best regards,
grygorii
