omapl138 gpio input value not changing

Hi Norman,

Thanks for your reply. I'll try the button elsewhere. I did think that the relation to BOOT pins might be an issue. I'll let you know if I have success!

Cheers,

George

Hi Norman,

I have moved everything to GP7[13]. As far as i can tell there is nothing here that should interfere with the input from a button. As before, I am able to toggle the output values and light an led, but when I add a button, the value remains the same.

I am using sysfs. The button runs high and on a push should set the gpio value to low. I've tested the button with an oscilloscope and confirmed that it behaves as expected.

I am wondering if there are settings in some of the other files that should be set?

For example, active_low (although i have tried both settings) or some settings in the power directory.

Just for completeness I added pinmux values for GP7[13] as below:

MUX_CFG(DA850, GPIO7_13, 16, 16, 15, 8, false);

Thanks,

George

The line "MUX_CFG(DA850, GPIO7_13, 16, 16, 15, 8, false)" looks good. Most GPIO problems are pinmux problems. If you can toggle the GPIO as an output, the input function should work without problems. Toggling the GPIO as an output proves that the pinmux and GPIO controller are good. Not much else left. I cannot think of anything in the configuration that could get in the way. If you do figure it out, please post the solution. I'd be curious. Maybe post the sysfs commands that you are using.

Thanks Norman. I think the issue may be related to the fact that we are using a pull-up switch, so when it is pressed it should toggle the GPIO to 0. I was digging around and saw mention of a pull up/down register. Perhaps I need to set something in there?

By the way, the sysfs commands are pretty standard.

echo 115 > export

cd gpio115

cat direction

"in"

cat value

1

Switch is showing high on oscilloscope. Press switch, cat value - no change.

Ive also tried modifying the values elsewhere (active_low both 0 and 1).

If I modify the pin to be output and change the value, the oscilloscope picks up the value change via the button!

Anyway - I'll talk to the hardware guys and make sure the wiring is correct. I'll also test it out on a different board, different switch.

I also have a kernel driver that exports the gpios and sets them up as in/out. But still the same issue, so I normally don't insmod it.

If you know anything about the pull up/down registers and if it is worthwhile pursuing that would be great.

Thanks so much for your assistance,

Cheers,

George

Great. I'll scan through everything tomorrow and let you know the outcome.

Thanks again.

Hi Norman,

I had a dig through everything. I'm not sure I've got the pullup/down register changes right, although the GPIO seems to be set up correctly.

At this point I am waiting to discuss the issue with the chap that wired up the switch.

As far as i can see from the documentation - using the internal pullup wouldn't make any difference to this situation anyway.

I'll update with progress,

George

Hi Norman,

Is there any sample code for setting of registers from the kernel (or a kernel module).

I can see that for the GPIO's I have chosen they default to pulldown. They require a 1 to activate the pull up.

My problem is, I am unable to find relevant headers where the registry identifiers are declared, and the names don't seem to be globally accessible.

I have been trying to modify another pin that has pullup set as default - but there are problems relating to the muxing and I am unable to get control and export the relevant pins. (this is totally another issue and not one for here really.)

Anyway, your help is greatly appreciated.

George

I don't quite understand about sample kernel code. The MUX code you got well in hand. Examples of gpio code are sprinked throughout the various drivers. The file "Documentation/gpio.txt" gives a good description of kernel and userspace gpio code. Each kernel version has different capabilities. I usually look at the sysfs gpio code for reference. It's at "drivers/gpio/gpiolib.c".

Some kernels have a debugfs that can help with debugging pinmux and gpio. Works great on the Overo platform. Never got it to work with the OMAP-L137. I might have missed something in the kernel config.

mkdir /tmp/debugfs
mount -t debugfs none /tmp/debugfs
cat /tmp/debugsfs/gpio

The usual other thing that causes GPIO/pinmux problems is when some other code grabs the pin after your code. I don't think this is the case here as you can toggle the pin as an output. If the pin was assigned away, yoy shouldn't be able to toggle the pin.

This might be nothing. Did you add "DA850_GPIO7_3" to the bottom of the enum list? Inserting in the middle would change the exising enumerations. In theory, the kernel build should detect the dependencies and recompile all the source dependent on the enumeration. To be sure, maybe try a total rebuild.

What I meant by sample kernel stuff is actually changing the value of the PUPDSEL and PUPDENA registers.

As I am unable to find definitions for them in any headers I am starting to enter into "I know nothing" territory.

The gpio headers that I can find, all offer options for setting direction, exporting, edge files etc - but the actual register that enables pull up or pull down isn't accessible via the normal gpio headers and c files.

I'll keep hunting, but any thoughts would be appreciated.

Oh, and I tried the suggestion of moving the enum entries and doing a clean build - but it didn't help unfortunately.

Ok, for example on an omap3 you can set the pull up or down in the pinmux settings:

MUX_VAL(GPIO_IDENTIFIER, (IEN | PD | M4));

On other boards there is even an omap_mux file that appears in debugfs - where you can literally echo in the pull up values you require.

The problem is definitely related to having the pullup pulldown set incorrectly.

There must be a way to change these values on an omapl138, surely?

For example - when I connect the board to CCS you can see the registers and set them to enable/disable and pull/up etc - but it isn't a persistent change and once I boot my kernel, those modifications are lost. But if CCS can change the values - surely it is possible for me to do it another way?

Hi Norman,

I ran the print output and I'm not sure that the register addresses are correct. The output is definitely not what is shown in the trm or when I plug into code composed.

Is there a map of the register addresses somewhere?

George

Actually - when i print the values returned from a raw_readl the values do seem correct.

For some reason, when I modify the value and do a raw writel the value isn't getting updated. I'll double check and let you know.

George

Yes - it seems the values are correct.

Once I have toggled the necessary bits, I perform a __raw_writel

Unfortunately this isn't updating the register for some reason. I'm assuming it is protected in some way - or I am just doing it wrong. Could you have a go at writing a new value into the register on your end and see if it is possible?

Ok - fixed the __raw_writel issue. Just waiting for one of the hardware guys and we are going to test the modifications.

I'll let you know - hopefully this is it.

Hi Norman,

Don't worry about testing it - I managed to get all of the software stuff working.

Just to confirm everything is looking better. The hardware guys had chosen a set of GPIO pins that were only usable as output.

I'm really sorry that we went through all of this stuff just to find this out - but as an exercise this has been hugely valuable. As part of the wider project it will be necessary to modify the pull up and pull down registers and go quite far into the pinmux settings in general.

I can only assume that, once they have things wired up correctly, we should be able to see the change in input value from a button.

Thanks so much for all of your help.

George