Diskussion:Universal Host Controller Interface

Ich fange hier mal eine Fragen- und Anregungensammlung an:

• USBCMD.FGR: Wofür ist dieses Resumesignal denn genau gut, wann braucht man es?
• Bei FLBASEADD "steht der Hostcontroller kann hier während des Benutzens der Liste den Offset des aktuellen Elements eintragen". Kann er setzen oder muss er es? Wenn er es nur kann, ist das Feld irgendwie nutzlos.
• Was ist denn jetzt ein Frame genau? Eine Zeiteinheit (sieht bei SOFMOD so aus)? Aber wieso entspricht dann ein Eintrag in der Frameliste einem Frame? Wäre das nicht eher Information, was während eines Frames passieren soll? Ich finde das noch irgendwie verwirrend beschrieben.
• Kann man im Abschnitt PORTSC noch irgendwie deutlich machen, dass es davon mehrere gibt? Ich wusste nämlich erst nicht, was ich unter "der Port" verstehen soll.
• Bei den Datenstrukturen wäre es hilfreich, das nötige Alignment anzugeben. Dass das bei der Frameliste 4k sind, habe ich weiter oben aufgeschnappt. Was ist mit dem Rest? Von den Pointern her vermute ich 16 Byte. Bei QHLP/QELP willst du vermutlich sagen, dass es die oberen Bits der physischen Adresse sind, oder?
• Transferdeskriptoren: NAK, ACK, SETUP, IN, OUT? Bahnhof! (Okay, nicht ganz, aber Begriffe erst verwenden, nachdem sie erklärt sind, wäre nett)

Außerdem glaube ich, wäre es sinnvoll, erst die Datenstrukturen und damit das grundlegende Prinzip zu erklären, bevor man auf die einzelnen Register eingeht. --Taljeth 09:32, 2. Mär. 2010 (CET)

• USBCMD.FGR: Na ja, wie es eben dasteht *g*: "Wird dieses Bit gesetzt, dann wird das Resumesignal an allen aktivierten Rootports getrieben." Da müsste noch jemand (im Zweifelsfalle wieder ich mit Vorlage:EMEJMM) was zum USB-Artikel schreiben. Wenn der Hostcontroller sich im Suspendmodus befindet (also nichts tut und alle Geräte schlafen gelegt sind), dann setzt man das Bit, um ihn und alle angeschlossenen Geräte wieder aufzuwecken. Man treibt eben das Resumesignal auf allen Rootports.
• Bei FLBASEADD ist das Feld als reserviert eingetragen. Praktisch macht der HC damit wohl, was er will. Unter QEMU lässt er es 0, afair, und auf echten PCs schreibt er da den Offset hin. Im Grunde ist das Feld für den Treiber uninteressant und einfach nur auf 0 zu setzen.
• Frame müsste ebenfalls im USB-Artikel erklärt werden.
• Hm, na ja, oben steht ja, dass es zwei oder mehr Ports gibt. Aber das kann ich natürlich machen.
• OK, das Alignment gebe ich an. Das müssten überall 16 Bytes sein, ja. Und ja, ich meine, dass das den oberen Bits der physischen Adress entspricht, wobei man das wohl in der Einleitung auch irgendwo allgemeingültig hinschreiben kann, à la "Wenn in einem DWord (sry für den Begriff :D) ein Pointer anzugeben ist, dann wird er immer komplett in dieses DWord geschrieben. Felder, die nicht zum Pointer gehören, bedeuten, dass er hier 0 sein muss, also entsprechend ausgerichtet sein muss. Sind z. B. die Bits 4 – 31 für den Pointer reserviert, dann müssen dort die Bits 4 – 31 des Pointers eingetragen werden. Die niederwertigsten vier Bit der Adresse müssen dann 0 sein, d. h. der Puffer ist an 16 Byte auszurichten." – für eine bessere Formulierung wäre ich sehr dankbar ;-)
• Transferdeskriptoren: s. kommender USB-Artikel.
• Hm, jo, das mit den Datenstrukturen kann man natürlich auch umdrehen.

Also, zu vielen Begriffen: Ich habe die hier extra undefiniert gelassen (Frames, IN, OUT, SETUP, ...), weil die IMO nicht in diesen Artikel, sondern in einen USB-Artikel gehören – unabhängig davon, ob es schon einen USB-Artikel gibt oder nicht. ;-) --XanClic 13:24, 2. Mär. 2010 (CET)