On Mon, Aug 1, 2016, at 09:16 PM, Charles Steinkuehler wrote: > On 8/1/2016 1:25 PM, John Kasunich wrote: > > > > Is it device tree that determines whether pins are used for MMC or GPIO, > > etc? > > Not exactly. Ultimately, it is the pinmux control register in the chip > that sets the pin mode. This is typically controlled by the kernel's > pinmux driver via device-tree entries, but can also be subjected to > 'tricks', like I do with the universal cape overlay (I craft several > useful pin modes then export them using the pinmux-helper module so > pinmux control can happen at run-time in user space, but it's still the > kernel's pinmux driver that does the low-level writes to the physical > pinmux registers). It's also possible to circumvent the kernel entirely > and do things like setup the pinmux values via PRU initiated writes.
I'm familiar with pinmuxes from programming AVR's (bare metal, no OS). I'm not familiar with device tree, apparently its a Linux thing intended to provide portability/abstraction to the inherently very simple pinmux. Personally I'm much happier and more comfortable just accessing the pin control registers. Device tree and pinmux helper are just extra levels of complexity. I suppose they are needed for portability and to allow configuration from user space. But our drivers run in kernel space and have direct access to the registers. And this particular driver is specific to the beaglebone and already has hard-coded addresses, so there is no need for a portability layer. Table 4.1 on page 20 of the chip datasheet ( http://www.ti.com/lit/ds/symlink/am3358.pdf ) lists all the available modes for every pin. Chapter 9.2.2 on page 1401 of the chip technical reference manual ( http://www.ti.com/lit/ug/spruh73n/spruh73n.pdf ) explains the bits in the pad control registers. The hal_bb_gpio driver is actually being pretty clumsy about things. It does write to the pin control registers, and forces the pin to mode 7 (GPIO mode), regardless of what its initial mode might have been. (see configure_pin() at line 440) So other than making sure a GPIO bank is alive, it doesn't seem like the device tree does much. Or more precisely, it doesn't matter what the device tree does, the HAL driver is going to come along and over-write it. If it doesn't crash by attempting to access a bank that has no clock. A kinder friendlier version of the driver would READ the pin control register, and if the pin isn't already set to mode 7 (by device tree at boot, or by your utility), it would refuse to let HAL use the pin and print a meaningful error message. That would ensure that if a pin was already being used by the LCD or MMC or HDMI interface the driver wouldn't stomp on it, since the mode would be set to something other than 7. > > > Seems like in the ideal world the "claimed" field in the bb_gpio_pin > > structures would be set using data from device tree, so that if the MMC > > is enabled you can't tell the HAL driver to use that pin. > > > > As written, it looks like the only thing the "claimed" field does is keeps > > you from using the same pin as a HAL input and HAL output at the > > same time. It does nothing to convey "claims" on the pin by other > > things like the MMC. > > > > I guess I want to learn more about device tree. > > The device tree is basically an *.ini file, just with a bit more > structure. It is a way to get pieces of key/value data from a > configuration file into the kernel code. Any meaning of the values in > the device-tree is provided by the kernel module code that looks at it. > And similar to an *.ini file, there are several ways to create > hard-to-find bugs (like subtle misspelling of a keyword) that are > difficult to fully check for when editing the dts file or creating the > binary dtbo. > > -- > Charles Steinkuehler > [email protected] > I haven't set up to build from source because I really just want to USE machinekit, not hack on it. But I may have no choice, since my project uses several custom HAL components. (They are already written and tested, on a LinuxCNC based system. But I want to port to machinekit so I can use the beaglebone instead of a bulky desktop + monitor + keyboard + mouse.) I have several small fixes I want to make (for example, when Michael added "newthread" to halcmd he forgot to add a description of the command to the help function (line 4132 of /src/hal/utils/halcmd_commands.c) or to the man page. I should be able to add that documentation. Although the newthread command accepts options like "posix" and "nowait" that aren't perfectly clear. I'll have to read the source and try to figure out what Micheal had in mind. Yet another case where the author of the code would have been the best person to write the docs. Anyway, assuming I get a build system working I may attempt a version of the hal_bb_gpio driver that respects the mode as set by device tree, and that doesn't crash if you select a disabled bank. -- John Kasunich [email protected] -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
