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
Attachment:
apugpio.xls
Description: MS-Excel spreadsheet
> 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
