Hi there,
I'm just trying to use some GPIO pins from the expansion headers to
read an input bit. But so far I cant configure that damn GPIO pin for
input.
I managed to get the input enable bit set and the correct input mode,
but still nothing. I'm using the generic functions gpio_request()
gpio_direction_input() and gpio_get_value().
Has anybody tried this or have any idea what could be wrong ?
Thank you.
Manuel
Hi there,
I'm just trying to use some GPIO pins from the expansion headers to
read an input bit. But so far I cant configure that damn GPIO pin for
input.I managed to get the input enable bit set and the correct input mode,
but still nothing. I'm using the generic functions gpio_request()
gpio_direction_input() and gpio_get_value().Has anybody tried this or have any idea what could be wrong ?
Do you know if the pin mux has been configured correctly either in U-boot
or by power up or by the kernel? If not, you will need to setup the pin mux
before it will work. The pin mux determines the current function of the pin.
Depending on what version of the kernel, the exact way to do it will vary a
bit. omap_cfg_reg() is the call to configure the pin mux for unless the top
of the git tree has changed it.
-- Hunyue
Depending on what version of the kernel, the exact way to do it will vary a
bit. omap_cfg_reg() is the call to configure the pin mux for unless the top
of the git tree has changed it.
$ find . -exec grep -H "omap_cfg_reg" {} \;
$
It seems that the git tree has changed it?!?!
Robert
Robert Kuhn wrote:
Depending on what version of the kernel, the exact way to do it will vary a
bit. omap_cfg_reg() is the call to configure the pin mux for unless the top
of the git tree has changed it.$ find . -exec grep -H "omap_cfg_reg" {} \;
$It seems that the git tree has changed it?!?!
Robert
Line 71 is an example call.
$ find . -exec grep -H "omap_cfg_reg" {} \;
$It seems that the git tree has changed it?!?!
Line 71 is an example call.
You are right. It's in mach/mux.h
Robert
Line 71 is an example call.
To use a specific ball (for example ball 28) on the expansion slot I have to:
1. set the right mux via omap_cfg_reg()
2. use gpio_direction_input and gpio_set_value for controlling the gpio
?
Is there an example for doing that? I find a quite difficult to find
the right parameters...
Robert
Hello all,
I wrote:
To use a specific ball (for example ball 28) on the expansion slot I have to:
1. set the right mux via omap_cfg_reg()
2. use gpio_direction_input and gpio_set_value for controlling the gpio
Okay, extremly bad example (28 is ground)...
But what about ball 9? After table 18 this is gpio 136. My questions are:
1. What is the right omap_cfg_reg() call to activate ball 9 as GPIO
136? After table 21 (Rev. B6 of the manual) this is option B. When I
look at $KERTNEL_DIR/arm/plat-omap/include/mach/mux.h I do see a lot
of defines but I do not know which is the right one. Is there any
documentation about that?
2. Whats the "name" of this gpio when I use gpio_setdirection etc.?
Thanks for any hints!
Robert
Hello all,
I wrote:
> To use a specific ball (for example ball 28) on the expansion slot I have
> to: 1. set the right mux via omap_cfg_reg()
> 2. use gpio_direction_input and gpio_set_value for controlling the gpioOkay, extremly bad example (28 is ground)...
But what about ball 9? After table 18 this is gpio 136. My questions are:
1. What is the right omap_cfg_reg() call to activate ball 9 as GPIO
136? After table 21 (Rev. B6 of the manual) this is option B. When I
look at $KERTNEL_DIR/arm/plat-omap/include/mach/mux.h I do see a lot
of defines but I do not know which is the right one. Is there any
documentation about that?
The right call is the call to a identifier that references the correct
register in the pin mux registers. A lot of the pins don't have definitions.
To add one:
The names used for the omap_cfg_reg doesn't matter.
For simplicity, I used XXX_FUNCTION as the name. If this code needs to be
distributed, you should use the appropriate name.
Side note, does anyone know which package the names reference? The few pins I
checked didn't seem to match the manual.
What matters is the register offset definition used in the mux.c file to
associate the name with the pin. The procedure is pretty much:
define the name in mux.h
give the name meaning in mux.c by associating it with the register offset
as defined in the TRM and the appropriate mux settings/pull up/down/etc.
2. Whats the "name" of this gpio when I use gpio_setdirection etc.?
The value that the gpio_* calls take is the gpio # of the gpio being
configured.
Hope this helps.
Hunyue , thank you for your help.
As far as I understand the name in
arch/arm/plat-omap/include/mach/mux.h is for example
BB_GPIO136
I can simply add it to the enums of omap34xx_index
Than I have to give the name meaning by writing something like
MUX_CFG_34XX("BB_GPIO136", 0x1ba,OMAP34XX_MUX_MODE0 |
OMAP34XX_PIN_INPUT_PULLUP)
(this is c&p from an other definition except the name)
in arch/arm/mach-omap2/mux.c
What TRM do you mean? I cannot find it in the BB System Reference Manual.
Robert
> What matters is the register offset definition used in the mux.c file to
> associate the name with the pin. The procedure is pretty much:
>
> define the name in mux.h
> give the name meaning in mux.c by associating it with the register offset
> as defined in the TRM and the appropriate mux settings/pull up/down/etc.Hunyue , thank you for your help.
As far as I understand the name in
arch/arm/plat-omap/include/mach/mux.h is for example
BB_GPIO136
I can simply add it to the enums of omap34xx_indexThan I have to give the name meaning by writing something like
MUX_CFG_34XX("BB_GPIO136", 0x1ba,OMAP34XX_MUX_MODE0 |
OMAP34XX_PIN_INPUT_PULLUP)
(this is c&p from an other definition except the name)
in arch/arm/mach-omap2/mux.c
Yes.
What TRM do you mean? I cannot find it in the BB System Reference Manual.
Technical Reference Manual. It is the manual for the OMAP3 processors.
It should be on the TI site. The SRM is for the Beagle board itself; the TRM
is for the OMAP3 processor used on the Beagle board.
What TRM do you mean? I cannot find it in the BB System Reference Manual.
Technical Reference Manual. It is the manual for the OMAP3 processors.
It should be on the TI site. The SRM is for the Beagle board itself; the TRM
is for the OMAP3 processor used on the Beagle board.
Okay, I will have a look, thank you.
Robert
I found in spruf98b.pdf
(http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=409&familyId=1526&abstractName=spruf98b)
the following line regarding GPIO_136:
Register Name Physical
Address Mode 0 ... Mode 4
CONTROL_PADCONF_MMC2_CLK[31:16] 0x4800 2164 mmc2_dat4
... gpio_136
This gives me this line for mux.c:
MUX_CFG_34XX("GPIO_136", 0x48002164,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
I am not sure if the address is right. The other ones are shorter
("0x5da"). And I do not know if OMAP34XX_PIN_INPUT_PULLUP is correct.
Can you give me a hint?
Thank you!
Robert
Robert
MUX_CFG_34XX("GPIO_136", 0x166,OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
did the trick. Its an offset not the real address!
Robert
> Robert
MUX_CFG_34XX("GPIO_136", 0x166,OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
did the trick. Its an offset not the real address!
One other detail is the offset for the macro is 16bit aligned where as the TRM
uses a 32bit physical address and entries for the lower and upper 16bits.
Just to make it easier for others who may also be figuring this out, I have
written a page with more details but basically the same information in this
thread.
Thank you - very usefull information!
One comment: the paths (like arch/arm/plat-omap/mux.h) are only valid
after a first kernel compilation which sets the necessary links.
Robert