AM625: SDK 08.06.00.42: Kernel 5.10: GPIO state on deep sleep

Hello Jonathan Cormier

Thank you for the query.

Jonathan Cormier said:

What is the gpio state for the A53 when the processor is in deep sleep?  Do they become high-Z or stay in their previous state?

This is a combination of hardware and software implementation.

Can you please share the development environment you are using? 

Regards,

Sreenivasa

Hello Jonathan Cormier

The below referenced thread could help you to understand the implementation status.

(17) AM625: DDR4 and LPDDR4 Power consumption during deep sleep mode and Boot Time - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa

The referenced documentation did not help. 

Kallikuppa Sreenivasa said:

This is a combination of hardware and software implementation.

Can you please share the development environment you are using? 

The hardware is the AM625 SOC.  The software is the Linux 5.10 Processor SDK kernel.

I don't know what additional information you need.

Hello Jonathan Cormier

Thank you. I am assigning to the expert.

Regards,

Sreenivasa

Hello Jonathan Cormier

Please refer below inputs 

The application software is responsible for deepsleep (DS) padconf configuration for all states needed in low power mode.

The linux expert provided the below inputs:

When AM62x is in DeepSleep, the main domain is powered off.

The hardware expert provided the below inputs: 

Do they become high-Z or stay in their previous state?

I don’t think this has been optimized yet. My understanding is we expect the answer to be a highZ state, but using either a pull up or down is application/PCB layout specific.

Additionally, please refer to Table 6-1. Pin Attributes of the datasheet provides the state of the IOs after reset.

Regards,

Sreenivasa

Okay that's good to know.  So just to confirm all IO that isn't one of the WKUP pins will be powered off (effectively reset) in deep sleep?

Then presumably on resume the kernel will restore the previous gpio state.

Hello Jonathan Cormier

Please refer below inputs 

The application software is responsible for deepsleep (DS) padconf configuration for all states needed in low power mode.

This section provides all the available option on the GPIOs

6.1.2 Pad Configuration Register Modules

6.1.2.2 Pad Configuration Register Functional Description

DeepSleep IO status programming register bits

DS_PULLTYPE_SEL

DS_PULLUD_EN

DSOUT_VAL

DSOUT_DIS

DS_EN

IO isolation and DeepSleep IO setting control register bits

ISO_BYP

FORCE_DS_EN

Wakeup event programming register bits

WKUP_EVT

WKUP_EN

WK_LVL_POL

WK_LVL_EN

It’s applicable to all LVCMOS IOs listed in the list of pad config registers with those DS setting bits.

Regards,

Sreenivasa

Okay so the pins can be configured to a set state in deep sleep.  Any idea if the kernel uses this feature and how to configure it?

Hello Jonathan Cormier

Thank you.

Have you had a chance to check the below 

3.2.2.11.4. S/W Architecture of System Suspend — Processor SDK AM62x Documentation

Power management section 

if you need some clarification, please add Kernel info or updates to the title to be able to assign the query to the right expert.

Regards,

Sreenivasa

Thanks updated the post title.

The linked documentation doesn't mention what the expected state of the GPIO is when in deep sleep.  Though it does imply that the test LED goes off, it doesn't mention if that is because the pin goes high-z and an external pulldown turns off the LED or if the led driver turns off the pin on suspend. 

It doesn't mention the DS_ registers so I'm assuming the kernel doesn't have any support for them.

Hello Jonathan Cormier

Thank you.

Sorry for the confusion. Please have the below title for the thread as the original : AM625: GPIO state on deep sleep 

For kernel information i would request you to 

please add Kernel info or updates to the title and start a new thread to be able to assign the query to the right expert.

Jonathan Cormier said:

The linked documentation doesn't mention what the expected state of the GPIO is when in deep sleep.  Though it does imply that the test LED goes off, it doesn't mention if that is because the pin goes high-z and an external pulldown turns off the LED or if the led driver turns off the pin on suspend. 

It doesn't mention the DS_ registers so I'm assuming the kernel doesn't have any support for them.

As mentioned above, if you could start a new thread for kernel related queries, the thread could be assigned to the experts.

Regards,

Sreenivasa

Why can't this thread be assigned to the appropriate experts? This was always a kernel question

Hello Jonathan Cormier

Thank you for checking.

We started with the GPIO state during deep sleep and I do not believe this was a kernel related question to start with.

After all the clarifications the question about the kernel came up

 Okay so the pins can be configured to a set state in deep sleep.  Any idea if the kernel uses this feature and how to configure it?

Since this is questions that is going to come up as a common query from a number of E2E users, I wanted to have the Hardware – The datasheet and TRM related discussion separate from Kernel related questions for the other E2E users to reuse.

 We typically encourage discussing one specific topic in an E2E thread.

 If there is a concern starting a new thread from your side I do not see any concern to reassign the same thread.   The Software expert will have to read the whole thread to answer and could cause delay in reply.

FYI

Initial thread topic

AM625: GPIO state on deep sleep

Current thread Topic

AM625: SDK 08.06.00.42: Kernel 5.10: GPIO state on deep sleep

 Regards,

Sreenivasa

Kallikuppa Sreenivasa said:

 If there is a concern starting a new thread from your side I do not see any concern to reassign the same thread.   The Software expert will have to read the whole thread to answer and could cause delay in reply.

Right. If I create a new thread then I'll have to repeat all of this again, instead of them just being able to read all that was already discussed.

Hello Jonathan Cormier

Thank you for the note,

FYI, when you start a new thread the moderation team assigns the thread to the right expert.

I will look for the expert and reassign to the thread.

Regards,

Sreenivasa