pinmux broken on hdmi pins in 4.4-ti kernel but working in 4.4-bone kernel

[JStrawson]

Hello all,

I've been using both fixed pinmux and pinmux helper entries in my device tree overlay successfully in Wheezy. However, while moving forward into Jessie I've discovered that the pinmux helper only generates the 'state' fd in /sys/devices/platform/ocp/ocp\:P8_37_pinmux/state for non-lcd/hdmi pins. I observed this with cape-universala, cape-univ-hdmi, and my own cape so I looked for disparities between kernels.

It seems Robert's 4.4.20-bone-rt kernel works just fine for all pins including hdmi pins. However the ti kernel that ships with the stable public images (2016-08-28, 2016-5-13) is missing pinmux functionality for all LCD/hdmi pins. I have checked with the following kernels:

not working: 4.4.9-ti-r25  4.4.20-ti-r43 4.7.3-bone2

working: 4.4.20-bone-rt-r13

Furthermore, normal fixed pinmux settings in overlay's target = <&am33xx_pinmux> section, (like BB-UART5 for exmaple) do not seem to have an effect in these ti kernels either. So right now I can't access anything between P8_27 and P8_46 without installing a new kernel.

Is there a workaround for this? I would like everything to work on the kernel in regular releases.

Thank you for any input.

[William Hermans]

Sure, the work around is don't use those kernels.

william@beaglebone:~$ uname -r
4.4.14-ti-r34
william@beaglebone:~$ ls /sys/class/gpio
export  gpiochip0  gpiochip32  gpiochip64  gpiochip96  unexport
william@beaglebone:~$ sudo sh -c "echo '115' > /sys/class/gpio/export"
[sudo] password for william:
william@beaglebone:~$ ls /sys/class/gpio/gpio115
active_low  device  direction  edge  power  subsystem  uevent  value
william@beaglebone:~$ ls /sys/devices/platform/ocp/
40300000.ocmcram          48038000.mcasp  480c8000.mailbox               49000000.edma      56000000.sgx
40302000.ocmcram_nocache  4803c000.mcasp  480ca000.spinlock              49800000.tptc      driver_override
44e07000.gpio             48042000.timer  4819c000.i2c                   49900000.tptc      modalias
44e09000.serial           48044000.timer  481a0000.spi                   49a00000.tptc      ocp:l4_wkup@44c00000
44e0b000.i2c              48046000.timer  481ac000.gpio                  4a100000.ethernet  of_node
44e35000.wdt              48048000.timer  481ae000.gpio                  4a300000.pruss     power
44e3e000.rtc              4804a000.timer  481d8000.mmc                   4c000000.emif      subsystem
47400000.usb              4804c000.gpio   48200000.interrupt-controller  53100000.sham      uevent
48030000.spi              48060000.mmc    48310000.rng                   53500000.aes

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5e320958-e343-4e96-b347-8c7814365e2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Kridner]

Is this a reason we can't get it working in both?

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrDg9MzH89n_RD%2B-n-zV4QtSR_WTeqBcsDOOQaTYepNxA%40mail.gmail.com.

[William Hermans]

Is this a reason we can't get it working in both?

Are you speaking to me Jason ?

If so I'm not sure what the problem the OP is having. But I can say that "we" do not need to to any extra pin muxing with the 4.4.x kernels. We can just use sysfs to export the gpio's we need, then set direction, and value. *IF* all we need is gpio.

Some of the things I have noticed about universal io. First, you can only have one overlay loaded that uses any pins it seems. Secondly of all the overlays I've tried to use, non of them let you mux *everything*. So thirdly, what happens is that you have to attempt to use two overlays that somehow overlap, but do not mux the same pins. . . For our own purposes this seemed impossible. So, I had to craft my own overlay base on two different universal io overlays. Which I needed to use all the epwmss pins as pwm, then around 25 other pins for gpio. 6 inputs, the rest all outputs.

The overlay univ-all that Robert created based on one of Charles' universal io overlays seems to mux the most, and be useful. But again, for us, it wasn't perfect. Not a complaint, just an observation. This is why I *was* working on universal-io single pin mux files. But after discussing that with Charles, it sounds like that would not be very useful. For most people.

Now I *could* personally create a universal-io overlay that would allow users to mux *every_single_pin* the way they see fit. But would my effort be wasted ? I do not know . . .

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrDg9MzH89n_RD%2B-n-zV4QtSR_WTeqBcsDOOQaTYepNxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9AFE7358-5E36-4A9C-8974-19668C3C6114%40gmail.com.

[William Hermans]

Oh, and right. I'm still not clear on if SPI can be muxed outside of the given board overlay file. While at the same time, it seems that universal io does not work correctly for at least one pin for the Bealebone green. I tried my best to isolate the problem as indicated in the post I made a few days ago. But am still not sure how to proceed further. It's almost like the BBG has differnt circuitry, for that one pin - gpio1_16 which is tied through a resistor to gpio2_0 for the purpose of bringing emmc_cmd out externally according to a post made by Gerald in 2014.

[William Hermans]

While at the same time, it seems that universal io does not work correctly for at least one pin for the Bealebone green.

That is not correct. universal io, and I assume any device tree file will work fine for gpio1_16. What I meant to say is that while every other pin on a beaglebone green can be set as a gpio, using the sysfs libGPIO interface. pin gpio1_16 *must* first have a device tre overlay file loaded for it to function correctly.

What I've found that happens is that gpio1_16 seems to function correctly but does not properly report input values correctly. They'll always read '0' whether that pin is pulled high, or low - externally.

[JStrawson]

Alright, sorted it out. It looks like the pinmux helper entries for the hdmi pins are not present in the base am335x-boneblack.dtb but enabling am335x-boneblack-emmc-overlay.dtb in uEnv.txt enables pinmux for the hdmi pins. Thanks Jason for pointing me in the right direction!