Excellent! I was just trying to pull together something similar based on the individual schematic documents! I think this supports the proposal on the table already, that we should prefer naming to be "modem orientated", rather than "pcie slot" orientated. For example, on APU2, the PE3/4_RST lines are wired to PCIe slots 1 & 2 (which are the two with USB) But on APU4, the PE3_RST reset, USB and SIM lines move from slot 1 to slot 3. So on APU4, you don't get the control over wireless disable (and reset is hazy) on the mpcie slot 1 for the wifi card. But in all cases the use of the reset/enable lines follow the modem slots, not the wifi slots So I maintain my proposal that it's far better to name the GPIOs relative to the USB & modem slots, since this is how they are being used on ALL schematics. Especially on APU5 (which is the oddball, having 3x modems + 6x SIMs), this is very much the case (Also, Enrico, you should beware that your current use might not be working as you expect, because I don't see that you have control over the wifi card enable on APU4 at all?) If we are now in agreement, perhaps we can proceed? I think if we make progress here, then I might also send in a patch to wire up all the other GPIOs. Thanks all Ed W On 27/02/2023 00:22, Philip Prindeville wrote: > Hi, > > I wanted to get the documentation straight from the proverbial horse's mouth, before I added any confusion of my own to the conversation. I reached out to Pascal and he was good enough to share this document with me. > > -Philip > > > > >> On Feb 17, 2023, at 5:20 AM, Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: >> >> On 14.01.23 00:04, Philip Prindeville wrote: >> >> Hello friends, >> >> sorry for being so late, busy with totally different things ... >> >>> My read of Enrico's comments were that using ACPI information to map >>> the GPIO lines would break backward compatibility. This part of the >>> effort was dropped. >> Yes, the big problem is inconsistent support in different firmware versions in the field. Older version generally don't have any acpi >> entries at all, later added it (but inconsitent and incomplete) and was >> dropped again later (haven't checked whether they reintroduced it >> again). >> >> Obviously, we can't expect users in the field to upgrade firmware and >> kernel in lockstep. So, we can only rely on this data for those boards >> where we can be sure that all shipped firmware versions have proper >> support (that really does it right). The problem also goes a bit deeper: >> just adding the GPIOs isn't really enough, they need proper (and >> consistent) names as well as mapping to the correct drivers (eg. LEDs). >> >> Oh, BTW, don't arbitrarily change gpio line names (at least for the >> already mainline-supported boards) - they're are used in the field. >> (well, I'm not actually satisfied with direct gpio access or things >> like modem reset lines, but haven't seen an actually fitting subsys >> for those). >> >> >> --mtx >> >> -- >> --- >> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert >> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren >> GPG/PGP-Schlüssel zu. >> --- >> Enrico Weigelt, metux IT consult >> Free software and Linux embedded engineering >> info@xxxxxxxxx -- +49-151-27565287
