problems with certain GPIOs on a AM3517

Hi Arno,

First you have to do the pinmux settings and then do request GPIO.

1. omap_mux_init_gpio(102, OMAP_PIN_OUTPUT);
or
omap_mux_init_signal("cam_d3.gpio_102", OMAP_PIN_OUPUT);

2.  ret = gpio_request(102, "nCONFIG");
if (ret) goto free_nCONFIG;
gpio_direction_output(102);  /* is that still necessary? */
gpio_export(102, true);

Make sure that no other portion of the code modify the same pin. By using mux entries we can identify which pins are used for which purpose, by using debugfs. Follow this post http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/168911/616699.aspx#616699

Debugfs entries will give the currently used GPIO values.

http://processors.wiki.ti.com/index.php/GPIO_Driver_Guide#Sysfs_control_-_User_Space

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

Hi Anil,

Thank you very much for your answer and the also for 2 very useful links!!

Unfortunately, I still did not succeed. With your help I can now at least verify that my settings are used:

# cat /sys/kernel/debug/omap_mux/cam_d3 
name: cam_d3.gpio_102 (0x4800211c/0x0ec = 0x0004), b c24, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE4
signals: cam_d3 | NA | NA | NA | gpio_102 | NA | NA | safe_mode

# cat /sys/kernel/debug/gpio 
GPIOs 0-31, gpio:
 gpio-24  (dvi_pon             ) out lo
 gpio-25  (USB1 PHY reset      ) out hi

GPIOs 32-63, gpio:
 gpio-57  (led gpio            ) out hi

GPIOs 64-95, gpio:

GPIOs 96-127, gpio:
 gpio-100 (CONF_DONE           ) out hi
 gpio-101 (INIT_DONE           ) out hi
 gpio-102 (nCONFIG             ) out hi
 gpio-103 (nSTATUS             ) out hi
 gpio-104 (OE_FPGA             ) out hi
 gpio-117 (edt_ft5x06 wake     ) out hi
 gpio-121 (enableButton        ) in  hi
 gpio-124 (disableButton       ) in  hi

GPIOs 128-159, gpio:
 gpio-136 (ADS7846 pendown     ) in  lo irq-296 edge-falling
 gpio-138 (panel_pwr           ) out hi
 gpio-139 (lcd_panel_pon       ) out lo
 gpio-153 (smsc911x irq        ) in  hi
 gpio-156 ([auto]              ) out hi

GPIOs 160-191, gpio:

But no matter to which value I set the output value of, e.g., gpio102, I always get the same signal on the oscilloscope (high). And if I configure the gpio as an input I always get value 0, no matter which voltage I apply.

Do I need to enable/disable some clocks to get it working? Or do I need to enable the respectice gpio bank somehow?

So far this problem only appears for pins of the camera module. The other gpios seem to work as expected. The only special thing I can see about them is that they have available a mux-mode "hw_dbg". But as I do not set them to this mux mode, I assume this is of no importance, right?

Best regards

Arno

Hi Arno,

Do you configuring the pin direction in pinmux register or not?

If you are using a pin as input then you have to configure that pin as INPUT enabled (OMAP_PIN_INPUT). If ouput then OMAP_PIN_OUTPUT.

How are you changing the GPIO values?

Can you try also with

$ echo "high" > /sys/class/gpio/gpio<number>/direction (or)

$ echo "low" > /sys/class/gpio/gpio<number>/direction

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

Hi Anil,

I tried different methods. First I used

$ echo in > /sys/class/gpio/gpioXXX/direction

and 

$ echo out > /sys/class/gpio/gpioXXX/direction

to change between input and output mode from the shell. When this did not help I additionally changed the pin muxing in the kernel module from

omap_mux_init_signal("cam_d3.gpio_102", OMAP_PIN_OUTPUT);

gpio_request(102, "nCONFIG");

gpio_direction_output(102, 1);

gpio_export(102, 1 );

for output mode to

omap_mux_init_signal("cam_d3.gpio_102", OMAP_PIN_INPUT);

gpio_request(102, "nCONFIG");

gpio_direction_input(102);

gpio_export(102, 1 );

to input mode. When I use the pins as output I can write 0 or 1 to  the  /sys/class/gpio/gpioXXX/value attribute. I can confirm that the value is written correctly by using 

$ cat  /sys/class/gpio/gpioXXX/value

But the voltage at the pin stays high, regardless of the value written.

When I use the pins as input then "cat  /sys/class/gpio/gpioXXX/value" always returns 0, no matter what voltage I apply to the pin.

Best regards

Arno

Hi again,

On my search for an explanation for my problems I just stumbled across the topic "L3 Security and Firewalls". Unfortunately this is very new to me and I'm having problems understanding the AM35x Manual at this point. But I see that the "Camera-VPFE" belongs to IP-Subsystem which can be locked in some way, in order to secure the device.

Could this be related to my problems? How can I check that?

In the x-loader sources I'm using I see that some other subsystems (GPMC, OCM, RT) are unlocked explicitly. Do I need to unlock the IP-subsystem, too? Has that to be done in the x-loader or can it alternatively be done in a kernel module?

Best regards

Arno

Hi,

Sorry, it's me again. Still creatively searching for a solution ;)

It turned out that a newer x-loader was available which also unlocked the IP-subsystem. And even with this x-loader my problem persists.

The next thing I stumbled across is a discrepancy between GPIO numbers in x-loader source code and AM35x technical reference manuals. In the x-loader sources of several AM3517 based boards I found the following line:

MUX_VAL(CP(CAM_WEN),        (IEN  | PTD | DIS | M4)) /*GPIO_167*/\

relating the "ccdc_wen" pin to gpio number 167. In all the TI documents, however, I see this pin being related to gpio_98. Is this a typo in the source code? Or is it for real?

Googling for related stuff I found the a simlar thing source code for another AM3517 based board:

MUX_VAL(CP(CAM_FLD),            (IDIS | PTD | DIS | M4)) /*GPIO_98*/\

The ccdc_field pin here is related to gpio_98 while in the TI documents it's connected to gpio_95.

Where does this discrepency come from? If the numbering in the source code is correct, where do I get information about the correct gpio numbers for all pins?

Best regards

Arno

Hi Arno,

Can you look at AM35x TRM (sprugr0b)

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

Hi Anil,

This  Technical Reference Manual  (sprugr0b) together with the newest Errata (sprz306c) is exactly what I have been studying again and again in the past week while dealing with my problem.

Unfortunately it doesn't help me.

But in the last hour I found out that the discrepancy in GPIO numbers, I reported in my previous post, is due to a difference between OMAP35x (spruf98w) and AM35x (sprugr0b). The camera related pins have slightly different names in the cases ("cam_" for omap35x and "ccdc_" for am35x) but mostly have identical function and GPIO numbers. Only  these 2 pins WEN and FLD have different numbers. So this again didn't help me. 

I don't understand, though, why the x-loaders for AM35x based boards use the OMAP35x based register and pin names. Pretty confusing.

Best regards

Arno

To whom it may concern,

The problem is solved. Well, at least the problem source is identified:

The PADCONF register addresses of the camera related pins for the AM3517 are wrong in all current sources of x-loader, u-boot and linux kernel.

They all use adresses which are valid for OMAP35xx based system while the AM3517 obviously is AM35x based. Unfortunately the registers addresses for the camera pins are different for these two classes of MPUs. 

Best regards

Arno