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
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.
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?
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.
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?
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.
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.
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?
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.
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.
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.
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