On 27.02.23 14:48, Ed W wrote: Hello friends, sorry for the delay: currently busy w/ finishing some other, completely unrelated projects (ugly osgi stuff) and need to care about family matters ... so please give me some more time to get my head around :o In the meantime checked that my most concerning applications in the field are using sysfs interface (and only apu2/3), so we can live w/ adding syminks (maybe by udev) to remain compatible. So, I'm open to changes, but please let's think this through very very careful, so we don't need to change that ever again - and hopefully something more generic than just the apu boards.
I think this supports the proposal on the table already, that we should prefer naming to be "modem orientated", rather than "pcie slot" orientated.
Why not port oriented ? Of course we'd need some kind of (maybe just informal/conventional) abstraction of ports, representing the physical slot (instead of pci or usb ports). Does anybody here have an formal specification of these physical ports ? Is there some reliable standard that describes the pins and their actual meaning or do HW vendors just happen to have some informal aggreement ?
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.
Saying "the pci slots, which also have usb" shows some confusion about what we're actually coping with. Looking at an APU2 or 3, we have * mPCIE1 * mPCIE2 * mpCIE3 / mSATA Now it's getting interesting: mpcie vs msata are electrically incompatible. There could be some way for auto detection, since some lines are reseved in either one while reserved (left floating) in the other one. Yet have to clear more carefully which the overlapping lines actually are - maybe sata vs usb ? I think we actually have at least two different types of ports here, while some might even miss some features: a) standard mpcie (with usual pcie+USB) b) mpci/msata: msata instead of usb The RST lines are goint to certain *connector* as a whole, not just either pci or usb. Thus, we really should have some representation of the port as a whole (each has it's own name and may or may not have an RST line, may or may not have USB or SATA lines). Another interesting aspect to consider: I haven't found any precise definition of how long the RST lines must be pulled. Probably there's some minimum time, but not an hard maximum. In the long run, we should have some reset functionality that handles that, instead of having userland playing around directly w/ raw gpios. And yet another one: the mpie port has some more interesting things, eg. transceiver power (->rfkill) and activity signal. Yet have to check which ones are actually connected on which boards. Bottom line: we really should invent some kind of subsys for those things, so userland doesn't need any board- (or even just family-) specfic logic. In a few weeks, I've hopefully got some more spare time - then I'll look closer into it. --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
