Apalis imx8qm 1.1 free GPIO7 causes wifi to be disabled Torizon 5.4 build10

I am trying to free up GPIO7 as we use that as a input on our device. in the past version Torizon 5.1 i did this by following device overlay

/dts-v1/;
/plugin/;
/ {
	compatible = "toradex,apalis-imx8";
};

&pciea{
       status="disabled";
};

&reg_pcie_switch{
        status="disabled";
};

Now we are trying to migrate to newer version of Torizon 5.4 build 10 but the above overlay causes the wifi to be disabled. is something wrong in the above overlay

in version 5.5 devel it seems to work.

could someone from Toradex confirm the issue being there with release.

Hi @nkj,

This is quite odd, I don’t see any changes in the kernel between the 5.4 release and now that should affect this behavior. This is the only commit I could find that even touches wifi or PCIE: linux-toradex.git - Linux kernel for Apalis and Colibri modules

However the changes in this commit don’t seem like they should affect this issue. Honestly I can’t tell what caused or fixed this issue. Whatever it was, it’s not something we intentionally did on our side.

In any case we plan to be feature freezing Torizon soon for the upcoming 5.5.0 quarterly release, planned to be released start of January. So, if it works for you now in the 5.5.0-devel images then it should also work in the next release.

Best Regards,
Jeremias

Hi @jeremias.tx

I also like to use GPIO7 as gpio but I am not sure about the consequences of disabling pcie. I use the ixora carrier board, does this mean the mini pcie slot is not usable anymore?

thanks in advance

Hi @bearsh,

If you look at the device tree, Apalis GPIO 7 is used to control the regulator for PCIE 1 on the Apalis i.MX8. If you want to use GPIO 7 and still want this PCIE then you can just modify the device tree to use a different GPIO for this regulator.

Best Regards,
Jeremias

Thanks @jeremias.tx
Sorry to bother you again, but I still don’t fully understand.

Apalis GPIO 7 is used to control the regulator for PCIE 1 on the Apalis i.MX8

  • Is this regulator populated somewhere? I don’t see it mentioned in either the Apalis i.MX8 datasheet nor the Ixora datasheet.
  • If it is, how can I use a different IO to control it?
  • Does this pin have any impact on the usage of Ixora’s Mini PCIe (X25)?

So in the end, I don’t understand how to use this regulator and what exactly it is for. For our product we use the Ixora carrier board and for now we don’t need any device connected to PCIe (except the internally connected WIFI module). But maybe in the future demands changes and we need a WAN module on the pcie slot. is this still possible?

thanks

Is this regulator populated somewhere? I don’t see it mentioned in either the Apalis i.MX8 datasheet nor the Ixora datasheet.

It’s on the module, there are a number of regulators for various sub-systems and components on our modules. You can see for which sub-systems there are regulators by looking at the device tree: imx8-apalis-v1.1.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis and Colibri modules

If it is, how can I use a different IO to control it

In the device tree this is the node that describes the regulator to PCIE 1: imx8-apalis-v1.1.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis and Colibri modules

In that node there is this line pinctrl-0 = <&pinctrl_gpio7>;. This refers to a group of pins. If you search for pinctrl_gpio7 in the same file you’ll find that this refers to Apalis GPIO 7. Therefore if you want to use GPIO 7 for other purposes but still want this regulator working you need to give it a substitute pin. They key is finding another pin that is available or can be taken off an interface you don’t require.

We have an article on device tree customization that you may also find useful: Device Tree Customization

Does this pin have any impact on the usage of Ixora’s Mini PCIe (X25)?

Yes, as far as I understand PCIE 1 on the Apalis i.MX8 is the PCIE interface that goes to X25 on the Ixora. GPIO 7 is used for the regulator that goes to PCIE 1. Therefore it implicitly has an impact on PCIE 1.

So in summary just modify the device tree to use a different pin than GPIO 7 and you should be fine.

Best Regards,
Jeremias

In that node there is this line pinctrl-0 = <&pinctrl_gpio7>; . This refers to a group of pins. If you search for pinctrl_gpio7 in the same file you’ll find that this refers to Apalis GPIO 7. Therefore if you want to use GPIO 7 for other purposes but still want this regulator working you need to give it a substitute pin. They key is finding another pin that is available or can be taken off an interface you don’t require.

I still don’t understand how this is possible. If there is a regulator physically connected on the module, how can I change the gpio used to enable it. I mean the enable line from the regulator would then be physically wired to the ball MLB_SIG / LSIO.GPIO3.IO26. So why should changing the device tree have an impact on that? Why should changing the device tree also change a physical connection?

https://docs.toradex.com/101123-apalis-arm-carrier-board-design-guide.pdf chapter 2.25.1 / table 37 says about GPIO7:

General-purpose GPIO, used on the evaluation board as a reset signal for the PCIe switch

but this seems not to be true for the Ixora board as GPIO7 is not connected to anything apart X27 (extension connector)

so I’m even more confused…

Apologies, I double-checked and I was initially incorrect. I thought the regulator (which is used for the PCIe reset) was on the module. I made this incorrect assumption since the node for the regulator was in the module level device tree imx8-apalis-v1.1.dtsi, instead of the carrier board level device tree. But I believe you are correct the regulator/reset isn’t present on the Ixora board, only the evaluation board.

In which case you should have no issues, since the hardware isn’t present on the Ixora. However, you’ll still need to modify the device tree to “disable” reg_pcie_switch.

This is because even though that hardware isn’t present on the Ixora. Due to it being defined in the module-level device tree the software will still reserve this pin for the regulator software driver. Which is why you need to disable/remove it so that the kernel won’t attempt to reserve control.

Best Regards,
Jeremias

Thanks you @jeremias.tx, I really appreciate it! Now every should be clear.

Best Regards

Glad I could help, apologies again about the initial confusion there.

Hi @nkj

I just realized that WIFI also stopped working after freeing GPIO7 (or maybe some other changes), so I’m wondering if it is working for you. I’m on 5.5.0-build.11 which is supposed to work.

Hi @bearsh,

Just to chime in I tried freeing GPIO7 on 5.5.0-build.11 and WiFi still seems to work fine for me after the change. I did a similar overlay to what nkj showed in his initial message. This only touches the pciea interface so it shouldn’t affect the on-module WiFi which is on pcieb.

Best Regards,
Jeremias

thanks @jeremias.tx

it definitely needs more investigation on my side… just for completeness, I did free GPIO7 the following way:
I use a customized dts file with following entries related to pcie/gpio

/* disable picea  to free GPIO7 */
&pciea {
	/delete-property/ vpcie-supply;
};

/* disable regulator switch to free GPIO7 */
&reg_pcie_switch {
	status="disabled";
};