On Saturday, March 4, 2017 at 5:56:04 AM UTC-8, Charles Steinkuehler wrote:
>
> On 3/3/2017 10:04 PM, ags wrote:
> ...
> > *I haven't tried it (don't want to damage hardware) but does this mean
> that
> > directly poking at the GPIO registers from userspace with /dev/mem &
> mmap()
> > won't work?
> > *if this is correct so far, what prevents loading a series of cape
> overlays that
> > change the configuration of a pin with this "old" style of pinmux
> control?
>
Using the "old" method, why can't cape overlays be repeatedly used to
reconfigure pins? (Not that it is a better
method than the universal cape and config-pin utility - just that I must be
missing something
important in understanding how this works).
>
> In the "old days", you could do this if you were root. Now I believe
> the hardware configuration register space is setup with memory
> protections so you have to access it from kernel space or you get an
> exception. You can still work around this if you're root by playing
> "tricks" (you can use something like the DMA engine or PRU to write
> values to the pinmux registers, bypassing the MMU).
>
> If I map these IO configuration registers using /dev/mem and access, am I
not enlisting the kernel (with it's privileges)?
(If this opens up an entirely new topic on memory access and user space,
let'd defer to avoid further scope creep)
> 3) this is where things start being less clear to me: I think I was just
> > understanding pinmuxing; now I see devices with properties "pinctrl-0;"
> with no
> > value. Is that because the devices no longer "own" their pins, but the
> > config-pin driver does?
>
> Not every device need to manage pins. Some devices don't have any
> pins (a DMA controller, cryptographic acceleartor, etc) and sometime
> the pins are already setup or are controlled by a different driver
> (like the pinmux-helper driver).
>
> OK, that makes sense. But then why is there a pinctrl-0 property at all
(why not omit that property entirely)?
If the node is configuring a specific device, with it's own driver, then
the driver could not
even look for that property, as there are no pins associated with the
device.
Is this a way of reusing existing drivers and avoiding bloat of
one-driver-per-device?
> > 4) the cape-universal node uses the "gpio-of-helper" driver, and
> apparently has
> > a node for each header pin, with a 3-tuple. It looks like {mode,?,0} but
> that's
> > a guess. I've searched, and found some examples from Pantelis Antoniou,
> but no
> > explanation.
>
> The gpio-of-helper exports the GPIO pins so this doesn't have to be
> done by the user. The three values you are referring to describe a
> particular GPIO pin. The number of values needed, and their meaning
> is device specific:
>
> https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
> <https://www.google.com/url?q=https%3A%2F%2Fwww.kernel.org%2Fdoc%2FDocumentation%2Fdevicetree%2Fbindings%2Fgpio%2Fgpio.txt&sa=D&sntz=1&usg=AFQjCNH6eOlIiqmOvmMZS_RimDCkCfpD5w>
>
>
> Thanks, this is a great source of information - though hard to find some
things in the hierarchy
(as someone that doesn't have enough experience to follow the structure
without searching around.
ex: gpio-of-helper is not found under ./bindings/gpio. Where can I find
that?).
If pins are exported using gpio-of-helper, are they then unavailable for
direct use ("ownership"?)
by devices that are configured in the dt? For instance, if I want to enable
a UART and configure (pinmux)
pins for it's exclusive use, do I need to modify the dt to not export those
pins using gpio-of-helper?
Or will they coexist - but then could a user use config-pin and 'steal"
those pins from the UART?
Has the dt "exclusive-use = ..." concept been deprecated as well?
> > Ultimately, I'd like to understand this so that I can create
> mappings/dts on my
> > own, rather than just relying on finding something that works offered by
> someone
> > else.
>
> Read through the device tree binding documentation in the kernel
> source. It is also helpful to view the full working device tree from
> your system. You can take the binary device tree from /boot and
> convert it into source with dtc. Then instead of a bunch of dangling
> references like &gpio3, you can go to gpio3 and see what it is, which
> will help you find it's documentation in the kernel's Documentation
> directory.
>
> I meant to include in the previous post that I am looking at a complete dt
(I think) that
I extracted from the running system using the "dtc -I fs" option.
> --
> Charles Steinkuehler
> cha...@steinkuehler.net <javascript:>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/58d3205e-2aaa-4a96-97ce-8b3486855d8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
