AM3356: About the behavior of /dev/input/event0 after suspend recovery

Hi expert

I forgot to describe important informations.

I'm using a GPIO pin as a wakeup-source.

Best regards.

Hello,

Can you please explain how you tested this?

Does the Event value change while is resuming or after its done resuming?

Best Regards,

Anshu

Hello, Anshu

We are conducting tests that repeats suspend and resume.

I don't know if this will change during the restart or after the restart is complete.
How can I check this?

Best regards,

Hello,

I want to make sure I understand correctly. Are you are using the Value hex digits of /dev/input/eventX to track the change of the GPIO signal?

Naomasa Ohya said:

I don't know if this will change during the restart or after the restart is complete.
How can I check this?

You can check the GPIO with a multimeter while its suspending/resuming to check. Its important to know at which point the GPIO signal changes.

Best Regards,

Anshu

Hello, Anshu

The wakeup pin is set in the device tree.
Event occurrence is detected via file descriptor.
Detects BATT_ONOFF signal by event.
Here is an overview of how it works.

- device tree:

    gpio_keys: wakeup_pins {
        compatible = "gpio-keys";

        gpio0_21 {
            label = "BATT_ONOFF";
            linux,code = <6>;
            gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
            wakeup-source;
            debounce-interval = <1000>;
        };

- source code:

I have attached an excerpt of the source code so that you can understand the process.

    int evnfd = open("/dev/input/event0", O_RDWR);
    
    FD_SET(evnfd, &fds);
    
    while(1) {
        maxfd = evnfd;
    	
        ret = select(maxfd + 1, &fds, NULL, NULL, NULL);
        if (ret > 0) {
        	
            if (FD_ISSET(evnfd, &fds)) {
            
            	read(evtfd, &event, sizeof(event));
            
                if (event.type == EV_KEY){
                    if (event.code == KEY_BATT_ONOFF) {
						if (event.value == 1) {
                            ■ON
						}else{
                            ■OFF
						}
					}
				}
			}
		}
	}

Best regards,

Hello,

Thank you for the details. Were you able to determine at which point the GPIO changes when the issue occurs?

Best Regards,

Anshu

Hello, Anshu

GPIO is not changing when the problem occurs.

When the problem occurred, even if I read /dev/input/event0 with ioctl, the value was OFF.

When I read the register value directly, I was able to read ON, so I think there is a problem with the device driver.

Because it occurs so rarely, it is very difficult to reproduce.

Is there any solution?

Best regards,

Hello,

Thank you for clarifying. What kind of event type does this GPIO create? Do you know which driver is being called?

Thanks,

Anshu

Hello, Anshu

Sorry for my late response.

I use only EV_KEY.

The driver thinks gpio-keys is being called.

Please refer to the above for device tree settings.

Best regards,

Hello,

Thanks for the confirmation. I recommended you try to debug the gpio_keys.c driver, so at least you can see the variable values when the issue does occur. There are a few functions that covers the event generation.

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/input/keyboard/gpio_keys.c?h=ti-linux-5.10.y#n61

You're also welcomed to reach out to the community if needed.