>
> 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 . . .

On Sat, Sep 10, 2016 at 3:00 PM, Jason Kridner <[email protected]> wrote:

> Is this a reason we can't get it working in both?
>
> On Sep 10, 2016, at 2:11 PM, William Hermans <[email protected]> wrote:
>
> 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
>
>
> On Sat, Sep 10, 2016 at 4:53 AM, JStrawson <[email protected]> wrote:
>
>> 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.
>>
>> --
>> 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 [email protected].
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/beagleboard/5e320958-e343-4e96-b347-8c7814365e2f%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/5e320958-e343-4e96-b347-8c7814365e2f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/CALHSORrDg9MzH89n_RD%2B-n-zV4QtSR_WTeqBcsDOOQaTYepNxA%
> 40mail.gmail.com
> <https://groups.google.com/d/msgid/beagleboard/CALHSORrDg9MzH89n_RD%2B-n-zV4QtSR_WTeqBcsDOOQaTYepNxA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/9AFE7358-5E36-4A9C-8974-19668C3C6114%40gmail.com
> <https://groups.google.com/d/msgid/beagleboard/9AFE7358-5E36-4A9C-8974-19668C3C6114%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORroCe37tiMLntfNptpqEg5dAtkabTYGW7GBASv1AQFpTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to