OMAP4460 wakeup GPIO configuration

Hi Egor,

You are correct that only gpio_1 or gpio_wk1 can be used at a time.  Your pin muxing looks OK since you are only using gpio_wk1 as mux mode 3, and you have set OMAP_WAKEUP_EN.  This line of your debug output is not an issue:

 _omap_mux_get_by_name: Could not find signal sim_clk.gpio_wk1

In mux.c, omap_mux_get_by_name() traverses the mux tables looking for sim_clk.  It is not found in the first mux table (core) but is found in the second mux table (wkup), so it is set successfully.

Which software release are you working with?

Have you used the gpio_request() and gpio_direction_input() functions when initializing the GPIO?  For example, from board-4430sdp.c:

gpio_request(HDMI_GPIO_HPD, NULL);
omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT | OMAP_PULL_ENA);
gpio_direction_input(HDMI_GPIO_HPD);

Regards,

Gina

Yes, I have.

Unfortunatelly Variscite use gpio_wk1 for their needs...so i changed to gpio_3.

I run Variscite's kernel 3.1.5 and in platform setup file wrote following:

omap_mux_init_signal("kpd_row2.gpio_3", OMAP_MUX_MODE7 | OMAP_PIN_INPUT); /* gpio_3 */
omap_mux_init_signal("sim_cd.gpio_wk3", OMAP_MUX_MODE3 | OMAP_PIN_INPUT | OMAP_WAKEUP_EN ); /* gpio_wk3 */
    
if(gpio_is_valid( VAR_GPIO_POWER_BUTTON ))
{
        gpio_request( VAR_GPIO_POWER_BUTTON, "GPOI_3");
        gpio_direction_input(VAR_GPIO_POWER_BUTTON);
        printk("GPIO_%d value: %d\n", VAR_GPIO_POWER_BUTTON,
                gpio_get_value( VAR_GPIO_POWER_BUTTON ));
        gpio_free( VAR_GPIO_POWER_BUTTON );
 }
else
{
        printk("%s(): ========== GPIO_3 not valid =========\n", __FUNCTION__);
        return -1;
}

after that i load driver which request gpio_3 again and set up gpio_3 IRQ line as IRQF_TRIGGER_FALLING.

I try to get gpio_3 pin level with gpio_get_value and always get high level even when i press button which short this pin to GND.

So interrupts isn't generate.

Not sure what your schematic looks like; you can only physically connect to gpio_wk_* or gpio _*, not both.

In OMAP4460 gpio_[0:3] and and gpio_wk[0:3] share same pins, and you can select what function do you want gpio_X or gpio_wkX.

I checked gpio_3 - it works fine - gpio_get_value returns proper levels and interrupt is generated but gpio_wk3 always returns high level. May be this channel activates only in power down mode or something else. I'll check it later or may be TI people can describe such gpio_wkX behavior.

WBR,

Egor,

Please see section 25.4.6.2 in the OMAP TRM for details about using wake-up with GPIOs.  The TRMs are located here: http://www.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12037#65

Regards,
Gina 

Hi, Gina.

Thank you for your help.

You mean following TRM lines about gpio_wkX:

The wake-up-enable register allows masking of the expected transition on input GPIO to prevent the
generation of a wake-up request. The wake-up-enable register is programmed synchronously with the
interface clock before any idle mode request coming from the host processor

So if i understand correctly they always feel some of pin level and don't generate any interreupts while CPU is in normal work mode and they become fully functional gpio in low power mode where they can feel level transition and generate wake up events.

Is it correct?

And i can check if it works correclty only when i suspend CPU?

Unfortunately suspend/resume in Variscite's kernel 3.1.5 broken. Some of TI sent patches to repair suspend/resume on ARM mailing list. This patches made for 3.4 branch, i'll try to port on 3.1.5 and see the result.

WBR,

Hi, Michael and Gina.

Thank you for your answers. My fault that i didn't check pinmux table more carefully.

I thought that they share same pin but has a different capabilities.

On Varicsite's module there is gpio_3 but not gpio_wk3.

I'll try to make suspend/resume working.

In any cases thank you agian.

WBR,

Hi Michael,

Just a minor question/clarification to this as you write that one can only connect to one or the other, but NOT both. I think we agree, but just to be 100% clear I would add that one of cause can use both balls simultaneously but not having them both set for GPIO input simultaneously (as they internally share the same GPIO control signal).

In the "extreme" case I however think you could actually use both as GPIO output simultaneously (although admitting that I have never tried it, but I see no reason it wouldn't work) although they of cause would always show the same output signal. But it might maybe help one in a special tight routing/layout case.

Please don't hesitate correct me in case you see any reason this wouldn't work - Best eegards - Enjoy your weekend
  Søren

Hello, Soren;

for the first part, no, because the input on one will affect the input on the other, even if they are in different modes.  We have seen failures due to this scenario.

for the second part, if you guaranteeing both are GPIO OUTPUTs only, it would seem that this could work, and they will be the same signal.  But you probably would just choose one or the other for the best routing scenario, and leave the other unconnected.

To assure no unintended results, please choose one and leave the other unconnected.

Kind regards, Michael

Hi Michael,

Thanks for your fast feedback, which (unfortunately) gave rise to a few new questions/comments, as I'm not sure I fully understand/agree :-)...

1) Using GPIO(_WK)3 as an example, does this mean that you can't use SIM_CD (Ball J1) and KPD_ROW5 (ball K27) simultaneously in these functions, as it is on Blaze schematics? This I would find very strange, but I admit that I haven't tried, but judging from "Figure 18-8. Active Mode Pad Configuration Bit Fields vs I/O Cell Mapping" I would as well find it strange that input pins in different mux modes would affect each other?

Can you point to any "official" documentation/errata describing this effect/problem in more detail, as I think this would be both highly needed and beneficial to understand actual limitations in case you point above is right? Is it a problem for all GPIOs (gpio0-3 and gpio100-104) which all can be found at two balls?

2) I agree that it wouldn't be optimal nor advisable. Main purpose was to describe actual limits (as I understand them) to make sure my understanding is/was 100% correct...

I hope you can clarify above item as well?

Kind regards, Søren

While researching the TRM for a response for a different question from you (but similar) I came across Figure 25-4 and a note that says the balls of GPIO_wk_x and GPIO_x can be routed to different signals and mux'd internally.  So you are correct, with my apologies.

Having said that, I know that I have seen failures from this; I can only conclude that it must be a result of incorrect Pad Configuration (Section 18.4.8), part of the same note.

Section 25 of the TRM is a good source for GPIO explanation, particularly the GPIO_wk usage.

Kind regards,

Hi Michael,

No problem and no apologies needed. Main point for me is to ensure that we are all aligned and continuing a high quality Q&A forum for people to use and learn from :-)

See replies to your posts in my other post in a short while
  Søren