i.MX7D - Why are upper/lower bytes of GPIO1 implemented differently?

[billgessaman]

This question is driven by trying to correctly understand how LPSR mode works and make sure our custom design will have the expected functionality to resume from LPSR.  Our design is based on the i.MX7D Sabre board with DDR3L memory and we are running Linux based on L4.1.15-1.0.0GA.  I'm using Rev 0.1 of the Reference Manual.

In the LPSR Mode section of the RM it says - "In LPSR mode, the supported wakeup source are RTC alarm, ONOFF event, security/tamper and also the 16 GPIO pads."  We happen to have both NVCC_GPIO1 and NVCC_GPIO2 connected to LDO3 in the PF3000 so we have adjusted the PMIC programming to leave LDO3 on in LPSR mode.  Then I notice that the lower 8 bits of GPIO1 are implemented by the IOMUX LPSR block and the upper 8 bits are implemented in the larger IOMUXC block.  Why this asymmetry in the implementation if all 16 bits are available as wakeup sources in LPSR?

Additionally, there are two registers (IOMUXC_LPSR_GPR_IOMUXC_LPSR_GPR20 and IOMUXC_LPSR_GPR_IOMUXC_LPSR_GPR21) in the IOMUXC_LPSR_GPR memory map that implement alternate pad control for the upper 8 bits of GPIO1.  There is no explanation as to why this is available and I can find nothing in the BSP that makes use of these extra pad control bits in these two GPR registers.  Does anyone have knowledge about why the implementation is different?  I can't imagine that this is a case of having to hide information in the Security Reference Manual.

Thanks,

Bill Gessaman

[igorpadykov]

Hi Bill

this is done for flexibility of usage as explained in RM

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[billgessaman]

Hi Igor,

Thanks for the answer but that wasn't the question that I was asking.  I did already understand the flexibility of being able to split the GPIO1 I/O between two different power supply rails.

I will try to rephrase my questions and be more specific:

1. The lower 8 bits of GPIO1 are implemented by the IOMUX LPSR block which remain powered in LPSR mode, and the upper 8 bits are implemented in the larger IOMUXC block which I think is *not* powered in LPSR mode.  Why were all 16 bits of GPIO1 not implemented in the IOMUXC LPSR block if all 16 GPIO pads are available as wakeup sources in LPSR?  Note that the mux control in the IOMUXC LPSR memory map below shows only bits 0 through 7.

2.  There are two special registers (IOMUXC_LPSR_GPR_IOMUXC_LPSR_GPR20 and IOMUXC_LPSR_GPR_IOMUXC_LPSR_GPR21) that implement some form of "alternate" pad control for GPIO1 bits 8 through 15.  See example of one of these registers shown below.  Is this because the "normal" pad control for these I/O is lost when the i.MX7 goes into LPSR mode?  I cannot find anywhere in the Linux BSP that these two registers are written if they are critical to maintaining pad control on GPIO1 bites 8 through 15 when in LPSR mode.  Shouldn't there be some explanation given about this???

Thanks,

Bill Gessaman

[igorpadykov]

Hi Bill

1. seems not all 16 bits of GPIO1 are implemented in the IOMUXC LPSR block in the same way,
   however all 16 GPIO pads may be powered in LPSR mode and available as wakeup sources in LPSR.

2. these two registers just allow more flexible "alternate" pad control for GPIO1 bits 8 through 15,
   "normal" pad control for these I/O is lost when the i.MX7 goes into LPSR mode and used IOMUXC_LPSR settings.
   Strictly speaking LPSR mode is not supported in nxp reference boards and linux bsp may not have full codes for it.

Best regards
igor