TK1 GPIO7 cannot be exported

Technical Support
, ,
1

Whenever i try to export gpio 233 i am getting the following error: “write error: Device or resource busy”.

As far as i know GPIO 233 is pin GPIO3_PDD.01 which maps to Apalis GPIO7. How can i use this GPIO pin?

2

This GPIO is used on our evalboards as a pcie switch reset. if you don’t use pcie and want to use this pin, you need to recompile the kernel with this patch:

--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -314,7 +314,7 @@ static unsigned long tegra_pcie_emc_rate = TEGRA_PCIE_EMC_CLK_102;
 
 #ifdef CONFIG_MACH_APALIS_TK1
 /* To disable the PCIe switch reset errata workaround */
-int g_pex_perst = 1;
+int g_pex_perst = 0;
 
 /* To disable the PCIe switch reset errata workaround */
 static int __init disable_pex_perst(char *s)
3

Thanks for the quick response. However, i am using pcie. So does this mean that i cannot use GPIO7?

4

Only if you have a custom carrier board that do not need the workaround for the pex pcie switch.

5

As indicated in the following commit message one may actually just specify pex_perst=0 on the kernel command line and no Linux kernel re-compilation would be required.

6

will this change disable pcie as well?

7

No, not at all resp. unless you are on the Apalis Evaluation board or the like requiring its PCIe switch to be reset like that.

8

Well, i am using the Ixora board

9

Then you should be perfectly fine with pex_perst=0.

10

I realize this is nearing 2 years later but we just ran into this. I had picked the Apalis TK1 GPIO7 (GPIO3_PDD.01) as a system function input based on the TK1 datasheet, and was surprised to observe the output driving the port being in logic conflict by default. The TK1 pins function table lists the SFIO0 function for GPIO3_PDD.01 as “pe0_rst_I” which appears to imply the port as input default similarly to “pe_wake_I”. This is further obscured by the lack of mention of pe0_rst_I in table 6-24 (additional PCIe Control Signals), however, GPIO7 is identified in table 6-4 as PEX_L0_RST_N with no further details.

Section 6.2 cautions about selecting the correct type of GPIO but it appears strictly aimed at the electrical capability of the IO, not the ball-name function. It would help if the datasheet identified the stock BSP default configurations of the GPIO ports in table 6-4 to allow designers to pick GPIOs that would not require patches to the Kernel that then need to be managed through successive BSP updates.

11

hi @RPHILLE

Could you ask a new question with providing all the details about the issue (hardware and software version of the module, carrier board version, …)?

Thanks and best regards,
Jaski