Port-arm archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BeagleBone Black and GPIO issues
On Wed, 2024-10-23 at 09:58 -0600, Brook Milligan wrote:
> >
> It sounds like you are focusing on how other drivers could access the
> pinctrl driver. Am I understanding correctly? No doubt that would
> be ideal.
>
> However, from the perspective of userland control of gpio state, why
> is that needed? When does a driver need access to the control
> module? For now, drivers seem to do fine ignoring it.
The driver interface is a "Big Question(tm)" that should require more
work than just programming the control registers. I have focused on
getting something that works rather than answering said question.
What I have done is to add a public interface to the pinctrl-single
driver allow anything in the kernel request a pin on a device to be
changed. I then added a function into the ftdbus framework to allow
anything in the kernel to lookup which pin control device has attached
itself to given phandle. Then I added code to the TI GPIO module to
parse the lists of phandle and pin number translations in the gpio-
ranges FDT property.
The only information that is missing is knowing what values in the pin
control registers implement what functions and that just has to be
hardcoded into the TI GPIO module, which I've also done.
This isn't ready to commit, but it does seem to work. The kernel knows
it has pullups and pulldowns. When I enable a pullup the voltage on the
pin reads 3.2 V on my multimeter. When I enable a pulldown the the
voltage on the pin reads 1.6 V which doesn't make me super happy, but
it doesn't seem to be floating.
The parse_gpio_ranges() needs a better home than the TI GPIO driver.
Also, I've only implemented support for the Sitara processor in the
BBB. The TI GPIO driver supports a bunch of different TI GPIO
implementations and so it will need to support a bunch of different
control modules.
I have some diffs against -current at
https://www.must-have-coffee.gen.nz/~lloyd/ti_pinmux.diff. Give them a
go and tell me how much is broken. The gpioow driver no longer works
for my application and I don't know why, mostly because I haven't
looked into it yet.
Ngā mihi,
Lloyd
Home |
Main Index |
Thread Index |
Old Index