Read GPIO problem

[pfeerick]

Note:  I do understand 'what' everyone believes export "should" accomplish, and I certainly also believe that it should be possible to guarantee the default operation of an exported pad;  however, my personal 'reality' is that it is more important to help users understand the complete operation rather than arguing over what 'should' be happening.  At the end of the day, do you want the pad to work or not ??  That's the simple question you need to answer for yourself.

Um, don't you mean you understand what export DOES on the board that people are most familiar with this funtionality? Because on the raspberry pi, there is no need to set the direction, because the initial sysfs values are correct!! When you export a pin, and then do a 'cat /sys/kernel/debug/gpio' on the rPi, the values you see are actually representational of the pin state, not false (i.e. gpio-4 sysfs in lo).

However, when you move to other boards, such as the Orange Pi Zero, you are out of luck... they are left floating just like with the pine64. Yes, it is nice to have it working, but exceptionalism is not good either... because this means this is yet another thing that makes the RPi-2 bus not RPi-2 compatible. So at the end of the day, I would like to either make it do what everyone expects it to do, or if that is not possible, document it as a known issue, because it is not rPi behaviour. Anything else is just looking at it with rose-tinted glasses, and making excuses.

[MarkHaysHarris777]

Note:  I do understand 'what' everyone believes export "should" accomplish, and I certainly also believe that it should be possible to guarantee the default operation of an exported pad;  however, my personal 'reality' is that it is more important to help users understand the complete operation rather than arguing over what 'should' be happening.  At the end of the day, do you want the pad to work or not ??  That's the simple question you need to answer for yourself.

Um, don't you mean you understand what export DOES on the board that people are most familiar with this funtionality? Because on the raspberry pi, there is no need to set the direction, because the initial sysfs values are correct!! When you export a pin, and then do a 'cat /sys/kernel/debug/gpio' on the rPi, the values you see are actually representational of the pin state, not false (i.e. gpio-4 sysfs in lo).

However, when you move to other boards, such as the Orange Pi Zero, you are out of luck... they are left floating just like with the pine64. Yes, it is nice to have it working, but exceptionalism is not good either... because this means this is yet another thing that makes the RPi-2 bus not RPi-2 compatible. So at the end of the day, I would like to either make it do what everyone expects it to do, or if that is not possible, document it as a known issue, because it is not rPi behaviour. Anything else is just looking at it with rose-tinted glasses, and making excuses.

Yes, of course,  which is what I stated in post #8. 

...  the Raspberry PI people do go to great lengths to make sure that the board can be relied upon to match the /sys/class/gpio/  filesystem, as well to make sure that the default pin states can be relied upon too ( stipulated ).

I suppose I agree with this part of your argument in as far as the PI2 bus is trying to be compatible (sort-of) with the Raspberry PI ( it is actually incompatible in several points, but leaving that aside for the moment ).

It could be argued both ways IMHO.  On the one hand, in an automated sense, if export would leave the pins in an expected default state for some people this would be desirable from the standpoint that it would be less work and more consistent.  On the other hand, I question whether it is not better when dealing with hardware to make sure that the state of the pads is explicitly stated in the user space initialization routines ?  This is an honest question. I mean its only a couple of lines of code to make sure that the state of the pin is set explicitly.

Thinking about this some more this evening I´m thinking that if it were possible, there ought to be a PI2 compatibility mode;  particularly in the sysfs method and in the RPi.GPIO-PineA64 routines. In any case I´m supposing that not only the dts would need tweaking, but the sysfs kernel module component as well. 

I´m going to check tomorrow to see whether the Rock64 has a similar issue.

[pfeerick]

My point the whole time as been simply that... if you export the pin, and it says that it's state is currently x, then it should damn well be x. not y, or z... x. The Raspberry Pi folks know that is what should be the case, so they made sure it was. Otherwise, the pin should have have a 'indeterminate' state, so that you know it hasn't been set yet.

A separate 'compatibility' mode isn't needed, especially when we are talking about the RPi bus. It either isn't or is. We already know that it isn't, so the focus should then be making it as compatible as possible, and documenting well the areas which it isn't. As far as the default state, it should be an input as the sysfs expects, and should be that as soon as possible. Not getting into a discussion over how soon it should do it, or what happens before then... this is a SBC, not a micro-controller... it's going to be sloppy. I do think for simplicity sake it should be done at boot - so probably in uboot. And I still wonder if the DTS is the root of the problem there... if you read some of the gpio-controller info, it appears that the default states *may* be defined there...

https://www.kernel.org/doc/Documentation...o/gpio.txt

[MarkHaysHarris777]

My point the whole time as been simply that... if you export the pin, and it says that it's state is currently x, then it should damn well be x. not y, or z... x. The Raspberry Pi folks know that is what should be the case, so they made sure it was. Otherwise, the pin should have have a 'indeterminate' state, so that you know it hasn't been set yet.  

My 4K R64 board came in yesterday ; so I played with it most of the night,  found that it does NOT have this issue.   If the pin is exported its direction is set IN, the active_low is set 0 and its value is set "1".  If the pin is grounded than the value changes to "0".  

So we need to get to the bottom of it;  is it a dts|dtb issue, a hardware issue with the PineA64+,  or a build issue ( something inconsistent with export somehow ).

[martinayotte]

Personally, I think it is more "by hardware design" where Rockchip and AllWinner engineers views diverge in the way GPIOs are implemented.