DE102014111457B4

DE102014111457B4 - Topologie und bandbreiten-management für i/0 und eingehende av

Info

Publication number: DE102014111457B4
Application number: DE102014111457.4A
Authority: DE
Inventors: Srikanth Kambhatla
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2013-08-22
Filing date: 2014-08-12
Publication date: 2018-03-15
Anticipated expiration: 2034-08-13
Also published as: GB201414976D0; DE102014111457A1; GB2519640A8; GB2519640A; GB2519640B

Abstract

Verfahren zur Übertragung von Daten zwischen einem Senkegerät und einem Quellgerät über einen DisplayPort mit einem Main-Link und einem AUX-Link, wobei das Senkegerät dazu ausgebildet ist, über den Main-Link Audio-/visuellen Inhalt zu einem Quellgerät zu streamen, und über den AUX-Link Ein-/Ausgabeinformationen zu dem Quellgerät zu senden und von dem Quellgerät zu empfangen, wobei das Senkegerät das Quellgerät auffordert, einen Pfadwechsel durchzuführen, um Ein-/Ausgabeinformationen über den Main-Link zu senden, wobei das Quellgerät einen virtuellen Kanal innerhalb des Main-Links bestimmt, und wobei das Quellgerät oder das Senkegerät eine Ein-/Ausgabeoperation durchführt und Ein-/Ausgabeinformationen über den virtuellen Kanal gesendet werden.

Description

Allgemeiner Stand der Technik
Ein DisplayPort-Link besteht aus einem Hauptlink, einem Hilfskanal (AUX CH) und einer Hot-Plug Detect-(HPD)-Signalleitung. Der Hauptlink ist ein unidirektionaler Kanal mit hoher Bandbreite und niedriger Latenzzeit, der verwendet wird, um isochrone Datenströme wie nicht komprimiertes Video und Audio zu transportieren.
Der Hilfskanal ist ein bidirektionaler Halbduplex-Kanal, der für das Link-Management und die Gerätesteuerung verwendet wird. Das HPD-Signal dient auch als eine Interruptanfrage durch das Senkegerät.
Der gegenwärtige DisplayPort-(DP)-Standard, der von VESA erhältlich ist (v1.2a), streamt nur Audio und/oder Video aus einem Quellgerät (z. B. ein Grafikprozessor (GPU) und dessen Software) zu einem Senkegerät (z. B. ein lokaler Flachbildschirm oder ein externer Monitor). In der erweiterten DisplayPort-Spezifikation (v.1.4) ist die Ein-/Ausgabe-(I/O)-Unterstützung auf Berührungsinformationen, die in Form von verarbeiteten Human Interface Device-(HID)-Paketen gesendet wurden, begrenzt, die über den Hilfs-(AUX)-Kanal transportiert werden können.
US 2013/0080665 A1 zeigt ein System umfassend eine Quelle, eine Senke und eine Schnittstelle mit einem unidirektionalen Hauptlink, einem bidirektionalen Aux-Link und einer Interrupt Line. Von einem Touch-Screen an die Senke weitergegebene Touch-Screen Daten werden über den bidirektionalen Aux-Link mit einer Übertragungsrate R2 im Vollduplexbetrieb an die Quelle übertragen. Das Streamen von z. B. USB-Daten von der Quelle zur Senke wird über den leistungsfähigeren Hauptlink mit einer Übertragungsrate R1 durchgeführt.
US 2011/0004704 A1 zeigt beschreibt ein System in dem ein Peripheriegerät in Abstimmung mit einem Ausgabegerät gesteuert wird. Das System umfasst einen HDMI-Transmitter (Quelle) und einen HDMI-Receiver (Senke). Neben einer Vielzahl von unidirektionalen Kanälen (TMOSChannels) umfasst das System einen bidirektionalen Display-Data-Channel (312) und eine bidirektionale CEC-Line (314). Die CEC Line wird dazu benutzt, Daten von einem Touchscreen zu dem HDMI-Transmitter (der Quelle) zu übertragen.
Weitere verwandte, zum Stand der Technik gehörende Systeme sind aus US 2011/0243035 A1 und US 2008/0187028 A1 bekannt.
Die vorliegende Erfindung hat zur Aufgabe, ein Verfahren zur Übertragung von Daten über eine DisplayPort-Schnittstelle zu schaffen, bei dem auf mögliche Engpässe bei der Übertragung von Ein-Ausgabeinformationen reagiert werden kann.
Diese Aufgabe wird durch die in den unabhängigen Ansprüchen angegebene Erfindung gelöst. Vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.
Kurze Beschreibung der Zeichnungen
Einige Ausführungsformen werden in Bezug auf die folgenden Figuren beschrieben:
1 ist eine schematische Darstellung von I/O-Schichten in einem DP-MST-Gerät gemäß einer Ausführungsform;
2 ist ein Flussdiagramm für Isoch-I/O gemäß einer Ausführungsform;
3 ist ein Flussdiagramm für eingehende Bulk-I/O gemäß einer Ausführungsform;
4 ist ein Flussdiagramm für eine weitere Ausführungsform;
5 ist eine Systemabbildung für eine Ausführungsform; und
6 ist eine Vorderansicht einer Ausführungsform
Ausführliche Beschreibung
Gemäß einigen Ausführungsformen können DisplayPort- oder andere Displayschnittstellentopologie-Senkegeräte Audio-/visuellen (AV) Inhalt zu einem Quellgerät streamen oder I/O-Informationen an das Quellgerät senden oder davon empfangen. Diese I/O-Informationen können beispielsweise rohe Sensordaten für einen Touchscreen einschließen. Ein Empfangslink mit hoher Bandbreite (der in diesem Dokument als RX-Link bezeichnet wird) existiert unabhängig vom Hauptlink (ML). Der RX-Link kann unabhängig vom ML trainiert werden.
I/O und eingehendes AV machen von virtuellen Kanälen (VCs) Gebrauch, die unter Verwendung von Erweiterungen zu DP1.2a-Topologie-Management-Grundelementen festgelegt sind. Der Unterschied bei verschiedenen Arten von I/O und AV ergibt sich im Wesentlichen daraus, wo der VC festgelegt ist, ob er zugeordnet oder gemeinsam benutzt ist und aus dem Rahmenwerk für die Dienstequalität (QoS). Es gibt hierin zwei Arten von I/O-Daten: isochrone (die auch als Isoch bezeichnet werden) und Bulk. Der Hauptunterschied zwischen den zwei Arten von I/O besteht in Bezug auf Garantien der Pünktlichkeit der Lieferung: es gibt keine bei Bulk-I/O.
Gegenwärtige Lösungen für Touchscreens unterstützen nur die Übertragung von verarbeiteten HID-Berichten über einen Standard-AUX-Kanal In ähnlicher Weise ist das nicht standardisierte „Weißbuch”-Angebot für die Version 2 des universellen seriellen Busses (USB 2.0) über DP1.2a Fast AUX ein Angebot für eine spezielle Art von I/O über DisplayPort. Das USB 2.0-„Angebot” bezieht ein Rahmenwerk speziell zum Zweck der Unterstützung von USB 2.0 ein. Diese Lösungen adressieren keine Unterstützung für irgendeine andere I/O-Art und adressieren auch keine native Unterstützung bei DP für eingehende Audio- und/oder Videostreams.
Ein kompletteres oder generischeres natives Rahmenwerk unterstützt jede Art von I/O (isochron oder Bulk, mit QoS oder ohne, eingehend oder ausgehend, USB oder PCIe oder andere I/O-Busse). Eingehendes Audio und/oder Video wird als eine unabhängige Fähigkeit als I/O behandelt.
Eingehende I/O werden von der Fähigkeit einer Quelle unterstützt, einen (großen) Datenblock, optional bei einer gewünschten Frequenz, zu lesen – mit First-in-First-out-(FIFO)-Semantik. Sobald sie festgelegt ist, kann die Senke idealerweise die Datenübertragung nach der Erstkonfiguration bei dieser Frequenz aufrechterhalten. Auch für eingehende I/O kann eine Quelle spezielle DisplayPort-Konfigurationsdaten-(DPCD)-Register lesen, wo I/O-Daten durch DPCD-Register verfügbar gemacht werden; diese Zugriffe werden unter Verwendung lokaler oder entfernter AUX-Transaktionen ausgeführt.
Ausgehende I/O werden von einer Quelle unterstützt, die einen (großen) Datenblock, optional bei einer gewünschten Frequenz, schreiben kann – mit FIFO-Semantik. Bei einer idealen Lösung hält die Quelle die Übertragung dieses Datenblocks nach der Erstkonfiguration aufrecht. Außerdem kann eine Quelle für ausgehende I/O-Operationen, wo erforderlich, in spezielle DPCD-Register schreiben; diese Zugriffe werden unter Verwendung lokaler oder entfernter AUX-Transaktionen ausgeführt.
Unterschiedliche Arten von Transaktionen können isochrone I/O, welche die Lieferung in konfigurierten Intervallen und zugewiesenen Link-Bandbreiten einbeziehen, und Bulk-I/O, welche die besten Lieferungsanstrengungen (im Sinne von Zeit) und die FIFO-Semantik aufrechterhalten einschließen.
I/O und eingehende Audio/Video-(AV)-Funktionen sind verfügbar wenn der Multi-Stream-Transport-(MST)-Link 18, der einen Seitenbandkanal 18a mit HPD und einen Hilfskanal sowie Hauptlink 18b mit Sekundärdaten-Paketen (SDPs) einschließt, konfiguriert ist, sich in einer bidirektionalen Betriebsweise zu befinden. I/O-Schichten bei einem DisplayPort-Quellen-, -Zweig- oder Senkegerät sind in 1 gezeigt. Die Topologiemanagementschicht 10 und die Nutzdaten-Bandbreitenmanagementschicht 12 sind erweitert, um Nachrichtentransaktionen auf dem bidirektionalen Hauptlink für eingehende I/O und eingehendes AV-zu verwenden. Die Nutzdatenmapperschicht 14 ist eine Erweiterung des Stream-zu-virtuellem-Kanal-Zuordnungsblocks, um einen virtuellen Kanal für das Streamen der Zuordnung für eingehendes AV, einen virtuellen Kanal für Datenmapping für eingehende I/O und eine Daten-zu-virtuellem-Kanal-Zuordnung für ausgehende I/O einzuschließen. Die Topologiemanagementschicht, Nutzdaten-Bandbreitenmanagementschicht und der Nutzdatenmapper sind Teil des Standards DP Version 1.2 (Jan. 2010) Isochrone Transportschicht 26.
Der I/O-Richtlinienmacher 16 befindet sich parallel zum Stream-Richtlinienmacher (18) und ist verantwortlich dafür, I/O-zugehörige Richtlinien im Gerät zu implementieren. Er arbeitet in Verbindung mit dem Isoch-I/O-Manager 20 und den Bulk-I/O-Managerschichten 22, um I/O-Vermögen im Gerät zu ermöglichen. Der Isoch-I/O-Manager ist für die Einrichtung und Verwaltung des virtuellen Kanals (VC) für Isoch-I/O verantwortlich. Ähnlich ist der Bulk-I/O-Manager für die Einrichtung und Verwaltung des VC und für Datenprioritätsmanagement/-arbitrierung verantwortlich. Der I/O-Richtlinienmacher, Isoch-I/O-Manager und Bulk-I/O-Manager sind Teil der DP1.2-VC-Managementschicht 24. Sie können beide Dienste, die von irgendwelchen Elementen der DP1.2-Isoch-Transportschicht 26 bereitgestellt werden, verwenden.
Die I/O-Brückenschicht 28 ist ein Client der DP1.2-VC-Managementschicht und enthält Brückenprotokolle, die Abstraktionen, die I/O-Schnittstellen wie USB oder PCIe verfügbar gemacht werden, zu I/O-Diensten, die durch die DP1.2-VC-Managementschicht exportiert werden, zuordnen. PCIe-Brücken adressieren spezielle I/O-Busse. Es könnte auch eine generische I/O-Brücke 34 geben, die einen Satz von Abstraktionen unabhängig von speziellen I/O-Bussen bereitstellt.
Von der DP1.2-VC-Managementschicht verfügbare I/O-Dienste ohne die Notwendigkeit von irgendeinem Brücken bilden werden als die nativen I/O-Dienste 36 bezeichnet. Im Gegensatz dazu können bestimmte Brückenfunktionen erforderlich sein, um vorhandene I/O-Schnittstellen wie USB oder PCIe zu in der DP-Spezifikation definierter Funktionalität zuzuordnen. Diese Blöcke sind entsprechend als USB-Brücke 38 und PCIe-Brücke 40 gezeigt.
Anwendungen, die isochrone I/O-42 und/oder Bulk-I/O 44 verwenden, sind über dem I/O-Richtlinienmacher und Isoch-I/O und Bulk-I/O-Manager angeordnet.
Alle Links entlang eines gegebenen Pfades in einer Topologie befinden sich im bidirektionalen Modus bevor irgendwelche I/O-Datenübertragungen oder eingehendes AV-Streaming auf diesem Pfad initiiert werden kann. Dieser Wechsel wird durch das DP-Quellgerät auf diesem Pfad initiiert.
Ein DP-Senkegerät initiiert die REQUEST_BIDIRECTIONAL_MODE-Nachrichtentransaktion, um die DP-Quelle auf dem gewünschten Pfad aufzufordern, ein Wechseln zum bidirektionalen Modus entlang dieses Pfades zu initiieren; sie tut das, wenn sie wünscht, eine I/O-Datenübertragung zu initiieren.
Geräte geben ihre Fähigkeit, bidirektionalen Modus zu unterstützen, durch das Setzen des Bits BIDIRECTIONAL_CAP im DPCD-Register MSTM_CAP bekannt.
Wenn eine Quelle wünscht, einen Link zum bidirektionalen Modus zu wechseln:

(1) Setzt sie das Bit BIDIRECTIONAL_EN im DPCD-Register MSTM_CTRL.
(2) Sobald sie die Bestätigung (Ack) für die DPCD-Transaktion in Schritt #1 empfängt, initiiert sie eine Trainingssequenz auf dem eingehenden Link. Die Mechanismen und das Verfahren, die hier beschrieben sind, können auf einer Vielzahl von PHY-Schicht-Implementierungen arbeiten, solange sie bidirektionalen Zugriff bei Verbindungsgeschwindigkeiten bereitstellen, die ausreichend sind, um die gewünschten I/O- und eingehenden AV-Durchsatzraten aufrechtzuerhalten.
(3) Sie liest optional die Bits BIDIRECTIONAL_STATUS im DPCD-Register SINK_STATUS in jedem Downstream-Gerät, um zu verifizieren, dass der Übergang zum bidirektionalen Modus in diesem Gerät abgeschlossen ist.

Wenn das Bit BIDIRECTIONAL_EN bei einem Zweiggerät bei einem seiner Eingabeports gesetzt ist, versucht sie, einen ähnlichen Wechsel bei jedem BIDIREKTIONAL-PHY-fähigen Gerät, das an dessen Ausgabeports erkannt wurde, zu initiieren.
Eine Sequenz von Operationen auf hoher Ebene für die I/O-Datenübertragung ist wie folgt:

(1) DP-Quellgerät weist einen VC wenn erforderlich entlang des gewünschten Pfades zu. Die Richtlinie für die VC-Zuweisung wird durch den I/O-Richtlinienmacher bei der DP-Quelle gesteuert. Der I/O-Richtlinienmacher kann optional VCs für bestimmte I/O-Operationen vorab zuweisen und sie nicht freigeben, bis er von diesen I/O-Operationen nicht mehr erwartet, dass sie auftreten.
(2) Das DP-Quellgerät konfiguriert alle Geräte entlang des gegebenen Pfades für die kommende I/O-Operation unter Verwendung der CONFIGURE_IO-Nachrichtentransaktion. Die für die kommenden I/O-Operationen zu verwendende VC-Nutzdaten-ID ist einer der Parameter in CONFIGURE_IO.
(3) Entweder die DP-Quelle oder die DP-Senke initiiert I/O-Datenübertragungen unter Verwendung der im vorherigen Schritt empfangenen Konfiguration.
(4) Das DP-Quellgerät gibt den VC gemäß den vom I/O-Richtlinienmacher festgelegten Richtlinien frei. Bei einer hohen Ebene werden ähnliche Sequenzen von Operationen auch für eingehendes AV-Streaming verwendet.

Eingehende isochrone Übertragungen werden für AV-Streaming und für Isoch-I/O-Datenübertragungen von einer Senke zu einer Quelle verwendet – potenziell durch eine gegebene Zahl von Zwischenzweiggeräten.
Der VC für eingehende isochrone Übertragungen ist im eingehenden Pfad des bidirektionalen Hauptlinks unter Verwendung der IB_ALLOCATE_PAYLOAD-Nachrichtentransaktion zugewiesen. Diese Nachrichtentransaktion schlägt fehl, wenn irgendein Gerät entlang des Pfades nicht im bidirektionalen Modus bereit ist.
Eine detaillierte Sequenz für eingehende Isoch-I/O- und eingehendes AV für eine Ausführungsform ist in 2 gezeigt. Bei einigen Ausführungsformen kann die in 2 gezeigte Sequenz in Software, Firmware und/oder Hardware implementiert sein. Bei Software- und Firmware-Ausführungsformen kann sie durch vom Computer ausgeführte Befehle implementiert sein, die in einem oder mehreren nicht flüchtigen computerlesbaren Medien wie Magnet-, optische oder Halbleiterspeicher gespeichert sind. Getrennte Sequenzen können bei einigen Ausführungsformen für jedes der Quellen- 50, Zweig- 52, 54 und Senke-56-geräte verwendet werden.
Eine Anwendung bei der Quelle 50 übermittelt 58 die gewünschten Dienstparameter für die kommenden I/O zum Isoch-I/O-Manager bei der Quelle. Diese Parameterliste schließt die Senke 56 ein, von der die I/O-Daten- oder der AV-Stream angefordert wird. Alternativ übermittelt die Anwendung bei der Senke die gewünschten Parameter für die kommenden I/O zum Isoch-I/O-Manager bei der Senke. Diese Parameterliste schließt die für die I/O-Daten- oder den AV-Stream adressierte Quelle ein. Der Isoch-I/O-Manager bei der Senke sendet diese Parameter zum Isoch-I/O-Manager bei der Quelle unter Verwendung der REQUEST_IB_VC_ALLOCATION-Nachrichtentransaktion.
Der Isoch-I/O-Manager bei der Quelle berechnet die Nutzdatenbandbreitenzahl (PBN), die für die gewünschte Operation erforderlich 60 ist, indem er die Dienstparameter verwendet, die er empfangen hat.
Der Isoch-I/O-Manager bei der Quelle gibt die IB_ALLOCATE_PAYLOAD-Nachrichtentransaktion 62 aus, um den VC beim eingehenden Hauptlink festzulegen. Die Quellgeräte können nicht mehr als eine IB_ALLOCATE_PAYLOAD-Nachrichtentransaktionen aufweisen, die zu irgendeinem Zeitpunkt bei einer Ausführungsform ausstehen. Im Szenarium, bei dem die Senke direkt an der Quelle angebracht ist, degeneriert IB_ALLOCATE_PAYLOAD zu DPCD-Schreibvorgängen zur IB-Nutzdaten-ID-Tabelle bei der Senke. Die Nachrichtentransaktionen IB_ENUM_PATH_RESOURCES, IB_QUERY_PAYLOAD, IB_RESOURCE STATUS NOTIFY und IB CLEAR PAYLOAD ID TABLE arbeiten beim Hauptlink eingehend auf eine Weise analog zu ihren Entsprechungen beim Hauptlink.
Der Isoch-I/O-Manager bei der Quelle sendet eine CONFIGURE_IO-Nachrichtentransaktion 64 zur Zielsenke. Parameter für dieses CONFIGURE_IO können bei einer Ausführungsform wie folgt sein:

i. Service Type: wie von der Anwendung bereitgestellt
ii. Transfer Type: Periodisch
iii. Frequenz: wie von der Anwendung bereitgestellt
iv. IO_Type: Isochron
v. Richtung: Eingehend
vi. VC_Payload_ID: VC-Nutzdaten-ID zurückgegeben von IB_ALLOCATE_PAYLOAD (66)
vii. Service_Specific_Parameters: wie von der Anwendung bereitgestellt

Der Isoch-I/O-Manager bei Zwischenzweiggeräten und dem Senkegerät verarbeitet CONFIGURE_IO und bereitet auf die eingehende I/O- oder AV-Operation vor.
Der Isoch-I/O-Manager bei der Senke initiiert die Übertragung von I/O-Daten bei der gewünschten Frequenz oder initiiert den spezifizierten AV-Stream. Im Falle von I/O-Daten sendet der Isoch-I/O-Manager eine VC-Nutzdatenfüllsymbol-Sequenz, wenn es keine wirklichen zu sendenden Daten gibt.
Nach dem letztlichen Abschluss der I/O- oder AV-Operation, sendet der Isoch-I/O-Manager bei der Quelle die STOP_IB_TRANSFER-Nachrichtentransaktion, um die Übertragung zu stoppen. STOP_IB_TRANSFER bewirkt nicht, dass die VC-Nutzdaten-ID freigegeben wird.
Der Isoch-I/O-Manager bei der Quelle gibt optional den VC unter Verwendung der IB_ALLOCATE_PAYLOAD-Nachrichtentransaktion 66 frei. Dies veranlasst alle Geräte, die spezifizierte VC-Nutzdaten-ID freizugeben.
Bulk-I/O-Datenübertragungen sind nicht periodische I/O-Übertragungen, die vom Bulk-I/O-Manager basierend auf einem Parameter, der ein 3-Bit-Dienstqualität-(QoS)-Feld bei einer Ausführungsform sein könnte, eingeplant werden. Eine detaillierte Sequenz für eingehende Bulk-I/O gemäß einer Ausführungsform ist in 3 gezeigt. Bei einigen Ausführungsformen kann die in 3 gezeigte Sequenz in Software, Firmware und/oder Hardware implementiert sein. Bei Software- und Firmware-Ausführungsformen kann sie durch vom Computer ausgeführte Befehle implementiert sein, die in einem oder mehreren nicht flüchtigen computerlesbaren Medien wie Magnet-, optische oder Halbleiterspeicher gespeichert sind. Es können getrennte Sequenzen für jedes der Quellen-, Zweig- und Senkegeräte bei einigen Ausführungsformen verwendet werden. Die Sequenz schließt die folgenden Schritte ein:

(1) Der I/O-Richtlinienmacher bei der Quelle 100 weist optional den Bulk-I/O-Manager an, Bandbreite bei dem Pfad (ein VC, der von allen Bulk-I/O-Übertragungen gemeinsam benutzt wird) zu jeder Bulk-I/O-fähigen Senke 108, 112 bei Quellgeräteinitialisierungszeit vorab zuzuweisen 105. Dies ermöglicht eine bestimmte Untergrenze an Bandbreite, die anschließend verbessert, reduziert oder freigegeben werden kann. Solch eine Vorabzuweisung reserviert Bandbreite für Bulk-I/O und VCs für nachfolgende Isoch-I/O-Übertragungen werden um diese Bandbreite herum zugewiesen. Ohne eine Vorabzuweisung würde die dynamische Zuweisung des (gemeinsam benutzten) VC für Bulk-I/O um die VCs herum geschehen, die bis zu diesem Punkt für Isoch-I/O zugewiesen sind. Für dynamische Zuweisungen von VC für Bulk-I/O (wenn es welche gibt) verwenden Bulk-I/O die IB_ALLOCATE_PAYLOAD-Nachrichtentransaktion (108).
(2) Eine Anwendung bei der Quelle 110 übermittelt die gewünschten Parameter für die kommenden I/O zum Bulk-I/O-Manager bei der Quelle. Diese Parameterliste schließt die Senke ein, von der die I/O-Daten angefordert werden. Sie schließt auch die gewünschte 3-Bit-Dienstqualität (QoS) für diese Transaktion ein. Alternativ übermittelt 114, 116 die Anwendung bei der Senke die gewünschten Parameter für die kommenden I/O zum Bulk-I/O-Manager bei der Senke. Diese Parameterliste schließt die Quelle ein, zu der die I/O-Daten und der 3-Bit-QoS adressiert sind. Im Falle, dass ein VC für die Bulk-I/O-Transaktion noch nicht festgelegt wurde, sendet der Bulk-I/O-Manager bei der Senke die gleichen gewünschten Parameter zum Bulk-I/O-Manager bei der Quelle unter Verwendung der REQUEST_IB_VC_ALLOCATION-Nachrichtentransaktion.
(3) Wenn erforderlich, berechnet der Bulk-I/O-Manager bei der Quelle die PBN, die für die gewünschte Operation erforderlich ist, indem der die Parameter verwendet, die er empfangen hat. Er weist dann einen VC für Bulk-I/O unter Verwendung der IB_ALLOCATE_PAYLOAD-Nachrichtentransaktion 112 wie beschrieben in Schritt (1) oben zu.
(4) Der Bulk-I/O-Manager bei der Quelle sendet eine CONFIGURE_IO-Nachrichtentransaktion 114, 116 zur Zielsenke.
• Parameter für dieses CONFIGURE_IO können bei einer Ausführungsform wie folgt sein: i. Service Type: wie von der Anwendung bereitgestellt ii. Transfer Type: Monostabil iii. Priorität: 3-Bit-QoS bereitgestellt von der Anwendung iv. IO_Type: Bulk v. Richtung: Eingehend oder ausgehend, wie von der Anwendung gewünscht vi. VC_Payload_ID: der VC, der für diese Bulk-I/O-Übertragung zu verwenden ist vii. Service_Specific_Parameters: wie von der Anwendung bereitgestellt • Im Falle, dass die VC-Zuweisung als Reaktion auf eine vorausgehende REQUEST_IB_VC_ALLOCATION erfolgte, führt die Quelle diesen Schritt im Fall von einem Fehler bei der VC-Zuweisung aus. welche zur Senke zurückkommunizierte VC-Nutzdaten-ID ist INVALID_VC_PAYLOAD_ID, welche die Senke und Zwischenzweiggeräte veranlasst, den Rest der Parameter in dieser Nachrichtentransaktion zu ignorieren.
(5) Der Bulk-I/O-Manager bei den Zwischenzweiggeräten 102, 104 und dem Senkegerät 106 verarbeitet CONFIGURE_IO 116 und bereitet auf die eingehende I/O- oder AV-Operation 118 vor.
(6) Der Bulk-I/O-Manager beim I/O-Daten-Absender (Quelle oder Senke) plant 120 die Übertragung der I/O-Daten gemäß der 3-Bit-QoS.

Sequenzen für ausgehende Isoch- und Bulk-I/O sind den entsprechenden Sequenzen für eingehende I/O ähnlich. Die wesentlichen Unterschiede sind bei einer Ausführungsform wie folgt:

• Der Isoch oder Bulk-I/O-Manager bei der Quelle weist VC (nach Bedarf) für ausgehende I/O-Übertragungen bei dem Hauptlink unter Verwendung der ALLOCATE_PAYLOAD-Nachrichtentransaktion zu.
• Der Isoch oder Bulk-I/O-Manager bei der Quelle sendet die CONFIGURE_IO-Nachrichtentransaktion nach dem Zuweisen des VC wie für eingehende I/O erfolgt. Basierend darauf überwachen die Downstreamgeräte den VC auf I/O-Daten von der Quelle und propagieren sie Downstream.
• Im Falle von ausgehenden Bulk-I/O plant der Bulk-I/O-Manager bei der Quelle Daten von den Anwendungen für die Übertragung basierend auf deren 3-Bit-QoS-Feldern ein. Der Bulk-I/O-Manager in den Downstreamgeräten verarbeitet die empfangenen I/O-Daten in First-come-first-served-Reihenfolge.
• Im Falle von ausgehenden isochronen I/O initiiert der Isoch-I/O-Manager bei der Quelle die I/O-Übertragung gemäß der von der Anwendung spezifizierten Frequenz.

IB_ENUM_PATH_RESOURCES ist eine Pfadressourcen-Nachrichtentransaktion, die verwendet wird, um die minimal verfügbare PBN auf dem eingehenden Pfad des bidirektionalen Hauptlinks zu bestimmen. Die Syntax für die Anfrage und Ack_Reply für diese Nachrichtentransaktion ist mit der Syntax für das ausgehende Äquivalent (ENUM_PATH_RESOURCES) identisch, die bereits in der DisplayPort-Spez. v1.2a definiert ist. Ein Gerät im Pfad schlägt bei dieser Anfrage fehl, wenn es sich nicht bereits im bidirektionalen Modus befindet, wenn es diese Nachricht empfängt.
IB_ALLOCATE_PAYLOAD ist eine Pfad- oder Knotenanfragen-Nachrichtentransaktion, die eine Änderung der Nutzdatenzuweisung für einen virtuellen Kanal zwischen dem DP-Quellen- und Senkegerät auf dem eingehenden Pfad des bidirektionalen Links ermöglicht. Die IB_ALLOCATE_PAYLOAD-Anfrage wird verwendet, um Nutzdaten für einen neuen virtuellen Kanal zuzuordnen, die Nutzdatenzuweisung eines vorhandenen virtuellen Kanals zu ändern oder die Nutzdatenzuweisung eines vorhandenen virtuellen Kanals zu löschen. Die Syntax für die Anfrage und Ack_Reply für diese Nachrichtentransaktion ist identisch mit der Syntax für ALLOCATE_PAYLOAD, die bereits im DP-Standard v1.2a definiert ist. Ein Gerät im Pfad schlägt bei dieser Anfrage fehl, wenn es sich nicht bereits im bidirektionalen Modus befindet, wenn es diese Nachricht empfängt.
Die Geräte pflegen eine IB-VC-Nutzdaten-ID-Tabelle, um IB-VC-Zuweisungen auf dem eingehenden Pfad des bidirektionalen Links nachzuverfolgen.
Die IB_QUERY_PAYLOAD-Nachrichtentransaktion bestimmt die verfügbare PBN für den virtuellen Kanal auf dem spezifizierten durch den IB-VC-Nutzdaten-ID-Parameter. Die Syntax für die Anfrage und Ack_Reply für diese Nachrichtentransaktion ist identisch mit der Syntax für QUERY_PAYLOAD, die bereits im DP-Standard v1.2a definiert ist. Ein Gerät im Pfad schlägt bei dieser Anfrage fehl, wenn es sich nicht bereits im bidirektionalen Modus befindet, wenn es diese Nachricht empfängt.
IB_RESOURCE_STATUS_NOTIFY ist eine Knoten-Broadcast-Nachrichtentransaktion, deren Funktionalität und Syntax für Anfrage und Ack_Reply derjenigen für RESOURCE_STATUS_NOTIFY entspricht, die bereits im DP-Standard v1.2a definiert ist. Ein Unterschied ist, dass diese Nachrichtentransaktion für Bandbreitenereignisse auf dem eingehenden Pfad mit bidirektionalem Modus verwendet wird.
Nach dem Empfangen dieser Nachricht kann die DP-Quelle die IB_QUERY_PAYLOAD-Anfrage verwenden, um zu bestimmen, welche Streams noch zugewiesen sind und welche als Reaktion auf die Bandbreitenereignisse freigegeben wurden.
Die IB_CLEAR_PAYLOAD_ID_TABLE Pfad-Broadcast-Nachrichtentransaktion wird durch ein MST-Datenverarbeitungsgerät im bidirektionalen Modus gesendet, um alle IB-VC-Nutzdaten-IDs freizugeben, die zu dem Port zugewiesen sind, von dem die Nachricht empfangen wurde. Wie im Fall von CLEAR_PAYLOAD_ID_TABLE wird diese Nachricht nur zu denjenigen Downstream-Ports mit IB-VC-Nutzdaten gesendet, die vom Eingabeport zugewiesen sind, der gelöscht wird. Die Syntax für Anfrage und Ack_Reply für diese Nachrichtentransaktion ist mit derjenigen für CLEAR_PAYLOAD_ID_TABLE identisch, wie bereits definiert im DP-Standard v1.2a.
Die CONFIGURE_IO-Pfad-Nachrichtentransaktion wird durch eine DP-Quelle zum Senkegerät gesendet, um Geräte entlang des Pfades mit Parametern zu konfigurieren, die in der kommenden I/O-Übertragung verwendet werden. Ein Gerät im Pfad schlägt bei dieser Anfrage fehl, wenn es sich nicht bereits im bidirektionalen Modus befindet, wenn es diese Nachricht empfängt.
Eine Quelle initiiert die STOP_IB_TRANSFER-Pfad-Nachrichtentransaktion, um eine isochrone, periodische, eingehende I/O- oder AV-Übertragung zu stoppen, die sie in der Vergangenheit initiiert hatte. Die spezielle eingehende Übertragung, die zu stoppen ist, wird durch die VC-Nutzdaten-ID bestimmt, die als ein Parameter in dieser Nachrichtentransaktion eingeschlossen ist. Die Nachrichtentransaktion wird den ganzen Weg zum Zielknoten propagiert, wobei Zwischengeräte ihre Statustabellen vor dem Propagieren der ACK_Reply zurück zur Quelle aktualisieren. Ein Gerät im Pfad schlägt bei dieser Anfrage fehl, wenn es sich nicht bereits im bidirektionalen Modus befindet, wobei die VC-Nutzdaten-ID für eine eingehende, isochrone und periodische I/O-Übertragung bereits in Verwendung ist.
Die Syntax für STOP_IB_TRANSFER_Request ist genau die Gleiche wie für CONFIGURE_IO_Request, die bereits im DP-Standard v1.2a definiert ist. Der Unterschied ist, dass die Parameter von der Senke für die kommende Übertragung vorgeschlagen werden. Wichtig ist, dass der Parameter VC_Payload_ID von der Senke auf Null eingestellt und nicht von der Quelle interpretiert wird.
Eine Senke initiiert die REQUEST_IB_VC_ALLOCATION-Knoten-Nachrichtentransaktion, um die Quelle aufzufordern, einen VC für eine eingehende Übertragung, die von einer Senke initiiert wird, zuzuordnen. Die Übertragung könnte für isochrone I/O, Bulk-I/O oder für eingehendes AV sein. Die Senke kommuniziert alle Parameter für diese vorgeschlagene Übertragung zur Quelle. Die Quelle bestimmt den erforderlichen PBN basierend auf diesen Parametern und initiiert die Zuweisung eines geeigneten IB_VC (nach Bedarf) und benachrichtigt alle Geräte entlang des Pfades (einschließlich der Senke) über den VC und die für die kommende eingehende Übertragung zu verwendenden Parameter. Die Senke sollte bereits im bidirektionalen Modus sein, wenn sie einen REQUEST_IB_VC_ALLOCATION initiiert.
I/O-Geräte und ihre Fähigkeiten können unter Verwendung von LINK_ADDRESS festgestellt werden, wenn sie in Downstream-Datenverarbeitungsgeräte eingesteckt sind:
Input_Port
Wenn auf eins gesetzt, sind die Port-Informationen für ein uPacket RX. Sonst sind die Port-Informationen für uPacket TX.
IO_Port
Wenn auf eins gesetzt, ist der Port für ein I/O-Gerät. Sonst ist er für ein AV-Gerät.
IB_Audio_Capable
Wenn auf eins gesetzt, ist der Port zu eingehendem Audio fähig.
IB_Video_Capable
Wenn auf eins gesetzt, ist der Port zu eingehendem Video fähig.
Number_SDP_Stream_Sinks
Number SDP_Stream_Sinks berichtet die Anzahl an SDP-Stream-Senken, die mit dem DP-Port verbunden sind. Diese Zahl ist gültig, wenn DisplayPort_Device_Plug_Status auf eins gesetzt ist.
IB_Isoch_IO_Capable
Wenn auf eins gesetzt, ist das Gerät an diesem Port zu eingehenden Isoch-I/O fähig. Diese Zahl ist gültig, wenn DisplayPort_Device_Plug_Status auf eins gesetzt ist.
OB_Isoch_IO_Capable
Wenn auf eins gesetzt, ist das Gerät an diesem Port zu ausgehenden Isoch-I/O fähig. Diese Zahl ist gültig, wenn DisplayPort_Device_Plug_Status auf eins gesetzt ist.
IB_Bulk_IO
Wenn auf eins gesetzt, ist das Gerät an diesem Port zu eingehenden Bulk-I/O fähig. Diese Zahl ist gültig, wenn DisplayPort_Device_Plug_Status auf eins gesetzt ist.
OB_Isoch_IO_Capable
Wenn auf eins gesetzt, ist das Gerät an diesem Port zu ausgehenden Bulk-I/O fähig. Diese Zahl ist gültig, wenn DisplayPort_Device_Plug_Status auf eins gesetzt ist.
Native_IO_Services_Capability
Dies ist ein Bitfeld, das native I/O-Leistungsfähigkeiten des Gerätes an diesem Port anzeigt. Die Codierung dieses Bitfeldes folgt der Definition des DPCD-Registers 62001h. Diese Zahl ist gültig, wenn DisplayPort_Device_Plug_Status auf eins gesetzt ist.
Bridged_IO_Services_Capability
Wenn auf eins gesetzt, ist der Port zu ausgehenden Bulk-IO fähig. Die Codierung dieses Bitfeldes folgt der Definition des DPCD-Registers 62002h. Diese Zahl ist gültig, wenn DisplayPort_Device_Plug_Status auf eins gesetzt ist.
Unter Bezugnahme auf 4 kann eine Sequenz für das Implementieren von I/O und eingehendem AV in einem Quellgerät gemäß einigen Ausführungsformen in Software, Firmware und/oder Hardware implementiert sein. Bei Software- und Firmware-Ausführungsformen kann sie durch vom Computer ausgeführte Befehle implementiert sein, die in einem oder mehreren nicht flüchtigen computerlesbaren Medien wie Magnet-, optischer oder Halbleiterspeicher gespeichert sind.
Die Sequenz 150 beginnt damit, dass der Senke ermöglicht wird, AV-Inhalt der im Block 152 angezeigten Quellen zu streamen. Dann wird der Senke ermöglicht, AV-Informationen von der Quelle wie gezeigt in Block 154 zu empfangen. Dann wird der Senke ermöglicht, AV-I/O-Informationen wie gezeigt in Block 156 zur Quelle zu transportieren.
5 veranschaulicht eine Ausführungsform eines Systems 700. Bei Ausführungsformen kann das System 700 ein Mediensystem sein, obwohl das System 700 nicht auf diesen Zusammenhang begrenzt ist. Beispielsweise kann das System 700 in einen Personal Computer (PC), einen Laptop-Computer, einen Ultra-Laptop-Computer, ein Tablet, ein Touchpad, einen tragbaren Computer, einen Handheld-Computer, einen Palmtop-Computer, einen Personal Digital Assistant (PDA), ein Mobiltelefon, eine Kombination aus Mobiltelefon und PDA, ein Fernsehgerät, ein intelligentes Gerät (z. B. Smartphone, Smart-Tablet oder Smart-Fernsehgerät), ein mobiles Internetgerät (MID), ein Nachrichtengerät, ein Datenkommunikationsgerät usw. eingebunden sein.
Bei Ausführungsformen umfasst das System 700 eine Plattform 702, die mit einem Display 720 gekoppelt ist. Die Plattform 702 kann Inhalt von einem Inhaltgerät wie das bzw. die Inhaltdienstgeräte 730 oder Inhaltlieferungsgeräte 740 oder anderen ähnlichen Inhaltsquellen empfangen. Ein Navigationscontroller 750, der ein oder mehrere Navigationsmerkmale umfasst, kann verwendet werden, um, beispielsweise mit der Plattform 702 und/oder dem Display 720 zu interagieren. Jede dieser Komponenten wird im Folgenden ausführlicher erläutert.
Bei Ausführungsformen kann die Plattform 702 jede Kombination aus einem Chipsatz 705, Prozessor 710, Memory 712, Speicher 714, Grafiksubsystem 715, Anwendungen 716 und/oder Funkgerät 718 umfassen. Der Chipsatz 705 kann Interkommunikation zwischen Prozessor 710, Memory 712, Speicher 714, Grafik-Subsystem 715 und den Anwendungen 716 und/oder Funkgerät 718 bereitstellen. Beispielsweise kann der Chipsatz 705 einen Speicheradapter (nicht dargestellt) einschließen, der imstande ist, Interkommunikation mit dem Speicher 714 bereitzustellen.
Der Prozessor 710 kann als Complex Instruction Set Computer-(CISC), Reduced Instruction Set Computer-(RISC)-Prozessoren, mit x86-Befehlssatz kompatible Prozessoren, als Mehrkern- oder jeder andere Mikroprozessor oder Hauptprozessor (CPU) implementiert sein. Bei Ausführungsformen kann der Prozessor 710 den bzw. die Dual-Core-Prozessoren, Dual-Core-Mobilprozessoren und so weiter umfassen. Der Prozessor kann die Sequenz von 8 zusammen mit der Memory 712 implementieren.
Memory 712 kann als ein flüchtiges Speichergerät implementiert sein, wie z. B., aber nicht beschränkt auf, ein Direktzugriffsspeicher (RAM), dynamischer Direktzugriffsspeicher (DRAM) oder statischer RAM (SRAM).
Der Speicher 714 kann als ein Permanentspeichergerät implementiert sein, wie z. B., aber nicht beschränkt auf, ein magnetisches Diskettenlaufwerk, optisches Diskettenlaufwerk, Bandlaufwerk, ein internes Speichergerät, ein angeschlossenes Speichergerät, Flash-Memory, batteriegepufferter SDRAM (synchroner DRAM) und/oder ein Speichergerät, auf das über ein Netzwerk zugegriffen werden kann. Bei Ausführungsformen kann der Speicher 714 Technologie umfassen, um den Schutz für verbesserte Speicherleistung für wertvolle digitale Medien zu erhöhen, wenn beispielsweise mehrere Festplattenlaufwerke eingeschlossen sind.
Das Grafik-Subsystem 715 kann eine Verarbeitung von Bildern wie Standbilder oder Videos zum Anzeigen durchführen. Das Grafiksubsystem 715 kann beispielsweise ein Grafikprozessor (GPU) oder eine visuelle Verarbeitungseinheit (VPU) sein. Eine analoge oder digitale Schnittstelle kann verwendet werden, um das Grafik-Subsystem 715 und Display 720 kommunikativ zu koppeln. Beispielsweise kann die Schnittstelle irgendeine von einer High-Definition-Multimedia-Schnittstelle, einem DisplayPort, einer drahtlosen HDMI und/oder von drahtlosen HD-konformen Techniken sein. Das Grafik-Subsystem 715 könnte in Prozessor 710 oder dem Chipsatz 705 integriert sein. Das Grafik-Subsystem 715 kann eine eigenständige Karte sein, die kommunikativ mit dem Chipsatz 705 gekoppelt ist.
Die hierin beschriebenen Grafik- und/oder Videoverarbeitungstechniken können in verschiedenen Hardwarearchitekturen implementiert sein. Beispielsweise kann Grafik- und/oder Videofunktionalität innerhalb eines Chipsatzes integriert sein. Alternativ kann ein separater Grafik- und/oder Videoprozessor verwendet sein. Als noch eine weitere Ausführungsform können die Grafik- und/oder Videofunktionen durch einen Universalprozessor, einschließlich eines Mehrkernprozessors, implementiert sein. Bei einer weiteren Ausführungsform können die Funktionen in einem Unterhaltungselektronikgerät implementiert sein.
Das Funkgerät 718 kann ein oder mehrere Funkgeräte einschließen, die Signale unter Verwendung verschiedener geeigneter drahtloser Kommunikationstechniken senden und empfangen können. Diese Techniken können Kommunikationen über ein oder mehrere drahtlose Netzwerke einbeziehen. Beispielhafte drahtlose Netzwerke schließen ein (sind aber nicht beschränkt auf) drahtlose lokale Netzwerke (WLANs), drahtlose Personal Area Networks (WPANs), drahtlose Metropolitane Area Networks (WMANs), Mobilfunknetze und Satellitennetze. Beim Kommunizieren über solche Netzwerke kann das Funkgerät 718 gemäß einem oder mehreren anwendbaren Kommunikations- oder Networking-Standards in irgendeiner Version arbeiten.
Bei Ausführungsformen kann das Display 720 jede Art von Fernsehmonitor oder -display umfassen. Das Display 720 kann beispielsweise einen Computerbildschirm, Berührungsbildschirm, Videomonitor, ein fernsehartiges Gerät und/oder einen Fernseher umfassen. Das Display 720 kann digital und/oder analog sein. Bei Ausführungsformen kann das Display 720 ein holografisches Display sein. Außerdem kann das Display 720 eine transparente Fläche sein, die eine visuelle Projektion empfangen kann. Solche Projektionen können verschiedene Formen von Informationen, Images und/oder Objekten übermitteln. Beispielsweise können solche Projektionen eine visuelle Überlagerung für eine mobile erweiterte Realitäts-(MAR)-Anwendung sein. Mit der Steuerung von einer oder mehreren Softwareanwendungen 716 kann die Plattform 702 die Benutzeroberfläche 722 auf dem Display 720 anzeigen.
Bei Ausführungsformen können das bzw. die Inhaltdienstgeräte 730 durch jeden nationalen, internationalen und/oder unabhängigen Dienst gehostet und deshalb beispielsweise für die Plattform 702 über das Internet zugänglich sein. Das bzw. die Inhaltdienstgeräte 730 können mit der Plattform 702 und/oder dem Display 720 gekoppelt sein. Die Plattform 702 und/oder das bzw. die Inhaltdienstgeräte 730 können mit einem Netzwerk 760 gekoppelt sein, um Medieninformationen zu und von Netzwerk 760 zu kommunizieren (z. B. zu senden und/oder zu empfangen). Das bzw. die Inhaltlieferungsgeräte 740 können auch mit der Plattform 702 und/oder dem Display 720 gekoppelt sein.
Bei Ausführungsformen können das bzw. die Inhaltdienstgeräte 730 eine Kabelfernseh-Box, einen Personal-Computer, ein Netzwerk, Telefon, internetfähige Geräte oder Apparate, die fähig sind, digitale Informationen und/oder Inhalte zu liefern, und jedes andere ähnliche Gerät, das fähig ist, unidirektional oder bidirektional Inhalt zwischen Inhaltsanbietern und der Plattform 702 und/Display 720 über das Netzwerk 760 oder direkt zu kommunizieren, umfassen. Es ist offensichtlich, dass der Inhalt unidirektional und/oder bidirektional zu und von irgendwelchen der Komponenten im System 700 und einem Inhaltsanbieter über das Netzwerk 760 kommuniziert werden kann. Beispiele für Inhalt können jede Medieninformation einschließen, einschließlich beispielsweise Video, Musik, medizinische und Spieleinformationen und so weiter.
Das bzw. die Inhaltdienstgeräte 730 empfangen Inhalt wie Kabelfernsehprogramme einschließlich Medieninformationen, digitalen Informationen und/oder anderem Inhalt. Beispiele von Inhaltsanbietern können jeden Kabel- oder Satellitenfernsehen- oder Radio- oder Internetinhaltsanbieter einschließen. Die bereitgestellten Beispiele sind nicht dazu beabsichtigt, die anwendbaren Ausführungsformen zu begrenzen.
Bei Ausführungsformen kann die Plattform 702 Steuerungssignale vom Navigationscontroller 750 empfangen, der ein oder mehrere Navigationsmerkmale aufweisen kann. Die Navigationsmerkmale des Controllers 750 können verwendet werden, um beispielsweise mit der Benutzeroberfläche 722 zu interagieren. Bei Ausführungsformen kann der Navigationscontroller 750 ein Zeigegerät sein, das eine Computerhardwarekomponente (speziell ein HID-Gerät) sein kann, die einem Benutzer ermöglicht, räumliche (z. B. kontinuierliche und mehrdimensionale) Daten in einen Computer einzugeben. Viele Systeme wie grafische Benutzeroberflächen (GUI) und Fernseher und Monitore ermöglichen dem Benutzer, den Computer oder Fernseher unter Verwendung physischer Gesten zu steuern und Daten an ihn bereitzustellen.
Bewegungen der Navigationsmerkmale des Controllers 750 können auf ein Display (z. B. Display 720) durch Bewegungen eines Zeigers, Cursors, Entfernungseinstellrings oder eines anderen auf dem Display angezeigten optischen Anzeigers als Echo gegeben werden. Beispielsweise können unter der Steuerung von Softwareanwendungen 716 die Navigationsmerkmale, die auf dem Navigationscontroller 750 lokalisiert sind, zu virtuellen Navigationsmerkmalen zugeordnet sein, die beispielsweise auf der Benutzeroberfläche 722 angezeigt werden. Bei Ausführungsformen kann der Controller 750 keine separate Komponente sein, sondern in die Plattform 702 und/oder das Display 720 integriert sein. Ausführungsformen sind jedoch nicht auf die in dem Kontext gezeigten oder hierin beschriebenen Elemente beschränkt.
Bei Ausführungsformen können Treiber (nicht gezeigt) Technologie umfassen, um es Benutzern zu ermöglichen, die Plattform 702, wie beispielsweise einen Fernseher, durch das Berühren eines Knopfes nach dem anfänglichen Systemstart sofort ein- und auszuschalten. Programmlogik kann der Plattform 702 erlauben, Inhalt zu Medienadaptern oder anderen Inhaltdienstgeräten 730 oder Inhaltlieferungsgeräten 740 zu streamen, wenn die Plattform „ausgeschaltet” ist. Zusätzlich kann der Chipsatz 705 Hardware- und/oder Softwareunterstützung für beispielsweise 5.1 Surround-Sound-Audio und/oder High-Definition 7.1 Surround-Sound-Audio umfassen. Treiber können einen Grafiktreiber für integrierte Grafikplattformen beinhalten. Bei Ausführungsformen kann der Grafiktreiber eine Peripheral Component Interconnect-(PCI)-Express-Grafikkarte umfassen.
Bei verschiedenen Ausführungsformen können eine oder mehrere der Komponenten, die in System 700 gezeigt sind, integriert sein. Beispielsweise können die Plattform 702 und die Inhaltdienstgeräte 730 integriert sein oder die Plattform 702 und Inhaltlieferungsgeräte 740 können integriert sein oder die Plattform 702, Inhaltdienstgeräte 730 und Inhaltlieferungsgeräte 740 können integriert sein. Bei verschiedenen Ausführungsformen können die Plattform 702 und das Display 720 eine integrierte Einheit sein. Das Display 720 und das bzw. die Inhaltdienstgeräte 730 können beispielsweise integriert sein oder das Display 720 und das bzw. die Inhaltlieferungsgeräte 740 können integriert sein. Diese Beispiele sind nicht dazu beabsichtigt, den Umfang zu begrenzen.
Bei verschiedenen Ausführungsformen kann das System 700 als ein drahtloses System, ein drahtgebundenes System oder eine Kombination von beiden implementiert sein. Wenn es als ein drahtloses System implementiert ist, kann das System 700 Komponenten und Schnittstellen einschließen, die für eine Kommunikation über ein drahtloses gemeinsam benutztes Medium geeignet sind, wie z. B. eine oder mehrere Antennen, Transmitter, Empfänger, Transceiver, Verstärker, Filter, Steuerlogik und so weiter. Ein Beispiel drahtloser gemeinsam benutzter Medien kann Teile eines Drahtlos-Spektrums, wie z. B. das RF-Spektrum usw. beinhalten. Wenn es als ein drahtgebundenes System implementiert ist, kann das System 700 Komponenten und Schnittstellen beinhalten, die für eine Kommunikation über drahtgebundene Kommunikationsmedien geeignet sind, wie z. B. I/O-Adapter, physische Verbinder, um den I/O-Adapter mit einem entsprechenden drahtgebundenen Kommunikationsmedium zu verbinden, eine Netzwerkkarte (NIC), Plattencontroller, Videocontroller, Audiocontroller und so weiter. Beispiele von drahtgebundenen Kommunikationsmedien können einen Draht, Kabel, Metallleiter, Leiterplatte (PCB), Backplane, Vermittlungsstelle, Halbleitermaterial, verdrillte Drähte, Koaxialkabel, faseroptische Verbindung und so weiter einschließen.
Die Plattform 702 kann einen oder mehrere logische oder physikalische Kanäle festlegen, um Informationen zu kommunizieren. Die Informationen können Medieninformationen und Steuerinformation einschließen. Medieninformationen können sich auf jegliche Daten beziehen, die einen für einen Benutzer bestimmten Inhalt darstellen. Beispiele von Inhalt können beispielsweise Daten aus einer Gesprächsunterhaltung, Videokonferenz, Streaming-Video, elektronische Post-(„E-Mail”)-Nachricht, Mailbox-Nachricht, alphanumerische Symbole, Grafiken, ein Bild, Video, Text usw. einschließen. Daten aus einer Gesprächsunterhaltung können beispielsweise Sprachinformationen, Phasen des Schweigens, Hintergrundgeräusche, Hintergrundrauschen, Töne und so weiter sein. Steuerinformationen können sich auf jegliche Daten beziehen, die Befehle oder Steuerwörter darstellen, die für ein automatisiertes System bestimmt sind. Beispielsweise können Steuerinformationen verwendet werden, um Medieninformationen durch ein System weiterzuleiten, oder einen Knoten anzuweisen, die Medieninformationen auf eine vorher festgelegte Art und Weise zu verarbeiten. Die Ausführungsformen sind jedoch nicht auf die Elemente oder den Kontext, der in 5 gezeigt oder beschrieben ist, beschränkt.
Wie oben beschrieben kann das System 700 in variierenden physischen Stilen oder Formfaktoren verkörpert sein. 6 veranschaulicht Ausführungsformen eines Gerätes mit kleinem Formfaktor 800, in dem das System 700 verkörpert sein kann. Bei Ausführungsformen kann beispielsweise das Gerät 800 als ein mobiles Computergerät mit Drahtlos-Fähigkeiten implementiert sein. Ein mobiles Computergerät kann sich auf jedes Gerät mit einem Verarbeitungssystem und einer mobilen Stromquelle oder Stromversorgung beziehen, wie beispielsweise eine oder mehrere Batterien.
Wie oben beschrieben, können Beispiele eines mobilen Computergeräts einen Personal Computer (PC), einen Laptop-Computer, einen Ultra-Laptop-Computer, ein Tablet, ein Touchpad, einen tragbaren Computer, einen Handheld-Computer, einen Palmtop-Computer, einen Minicomputer (PDA), ein Mobiltelefon, eine Kombination aus Mobiltelefon und PDA, ein Fernsehgerät, ein intelligentes Gerät (z. B. Smartphone, Smart-Tablet oder Smart-Fernsehgerät), ein mobiles Internetgerät (MID), ein Nachrichtengerät, ein Datenkommunikationsgerät und so weiter einschließen.
Beispiele von mobilen Computergeräten können ebenso Computer einschließen, die so angeordnet sind, dass sie von einer Person getragen werden können, wie zum Beispiel ein Handgelenk-Computer, ein Finger-Computer, ein Ring-Computer, ein Brillen-Computer, ein Gürtelclip-Computer, ein Armband-Computer, Schuh-Computer, Kleidungs-Computer und andere tragbare Computer. Bei Ausführungsformen kann beispielsweise ein mobiles Computergerät als ein Smartphone implementiert sein, das in der Lage ist, Computeranwendungen sowie Sprachkommunikationen und/oder Datenkommunikationen auszuführen. Obwohl einige Ausführungsformen beispielhaft mit einem mobilen Computergerät als ein Smartphone implementiert beschrieben sein können, kann es selbstverständlich sein, dass auch weitere Ausführungsformen unter Verwendung anderer drahtloser mobiler Computergeräte implementiert sein können. Die Ausführungsformen sind in diesem Kontext nicht eingeschränkt.
Die folgenden Abschnitte und/oder Beispiele betreffen weitere Ausführungsformen:
Eine beispielhafte Ausführungsform kann ein Verfahren sein, das umfasst, einem Senkegerät zu ermöglichen, Audio-/visuellen Inhalt zu einem Quellgerät über eine Displayschnittstelle zu streamen und dem Senkegerät zu ermöglichen, Audio-/visuelle und/oder Ein-/Ausgabeinformationen von einem Quellgerät zu empfangen und Audio- und/oder Video- und/oder Ein-/Ausgabeinformationen zu einem Quellgerät über die Displayschnittstelle zu senden. Das Verfahren kann auch einschließen, dass die Ein-/Ausgabeinformationen rohe Touchscreen-Sensordaten einschließen. Das Verfahren kann auch das Bereitstellen eines Hauptlinks und eines unabhängigen Empfangslinks einschließen. Das Verfahren kann auch das Implementieren einer DisplayPort-Topologie einschließen, die Audio-/visuelle und Ein-/Ausgabegeräte einschließt. Das Verfahren kann auch das Unterstützen von sowohl isochronen als auch Bulk-Ein-/Ausgabeübertragungen und von eingehendem Audio und/oder Video einschließen. Das Verfahren kann auch das Ermöglichen von mehreren gleichzeitigen Ein-/Ausgabeoperationen einschließen. Das Verfahren kann auch das Ermöglichen von Priorisierung von Bulk-I/O von Anwendungen bei einem Gerät einschließen, das eine Anfrage originiert. Das Verfahren kann auch einschließen, Entitäten zu ermöglichen, bei gleichzeitigen Isoch-I/O-Anwendungen bei einem originierenden Gerät diese nach Priorität zu ordnen. Das Verfahren kann auch das Ermöglichen des Entdeckens von Ein-/Ausgabegeräten und ihren Fähigkeiten einschließen, wenn sie in Downstreamgeräte eingesteckt sind, und dadurch das Anwenden eines Adressenerzeugungsmechanismus für eine DisplayPort-Schnittstelle für Ein-/Ausgabegeräte. Das Verfahren kann auch einschließen, der Quelle zu ermöglichen, einen Datenblock mit FiFo-Semantik zu lesen. Das Verfahren kann auch einschließen, der Quelle zu ermöglichen, die DisplayPort-Konfigurationsdatenregister für eingehende und ausgehende Ein-/Ausgabeinformationen zu lesen. Das Verfahren kann auch einschließen, dass eine Senke eine Quelle auffordert, einen Wechsel zu initiieren, um eine Ein-/Ausgabedatenübertragung von der Senke zur Quelle zu ermöglichen. Das Verfahren kann auch einschließen, der Quelle zu ermöglichen, alle Geräte entlang des Pfades für die Ein-/Ausgabedatenübertragung zu konfigurieren.
Eine weitere beispielhafte Ausführungsform kann ein oder mehrere nicht flüchtige computerlesbare Medien sein, die Befehle speichern, die von einem Prozessor ausgeführt werden, um eine Sequenz auszuführen, die einem Senkegerät ermöglicht, Audio-/visuellen Inhalt zu einem Quellgerät zu streamen und dem Senkegerät ermöglicht, Audio-/visuelle Ein-/Ausgabeinformationen von einem Quellgerät zu empfangen und Audio/Video-Ein/Ausgabeinformationen zu einem Quellgerät zu senden. Die Medien, wobei die Ein-/Ausgabeinformationen rohe Touchscreen-Sensordaten einschließen. Die Medien können einschließen, dass die Sequenz das Bereitstellen eines Hauptlinks und eines unabhängigen Empfangslinks einschließt. Die Medien können einschließen, dass die Sequenz das Implementieren einer DisplayPort-Topologie einschließt. Die Medien können einschließen, dass die Sequenz das Unterstützen von sowohl isochronen als auch Bulk-Übertragungen und eingehendem Audio und Video einschließt. Die Medien können einschließen, dass die Sequenz einschließt, der Quelle zu ermöglichen, einen Datenblock mit FiFo-Semantik zu lesen. Die Medien können einschließen, dass die Sequenz einschließt, der Quelle zu ermöglichen, DisplayPort-Konfigurationsdatenregister für eingehende und ausgehende Ein-/Ausgabeinformationen zu lesen. Die Medien können einschließen, dass die Sequenz einschließt, dass eine Senke eine Quelle auffordert, einen Wechsel zu initiieren, um eine Ein-/Ausgabedatenübertragung von der Senke zur Quelle zu ermöglichen. Die Medien können einschließen, dass die Sequenz einschließt, der Quelle zu ermöglichen, alle Geräte entlang des Pfades für die Ein-/Ausgabedatenübertragung zu konfigurieren.
Bei einer weiteren beispielhaften Ausführungsform kann eine Senke sein, die umfasst, dass ein Prozessor Audio-/visuellen Inhalt zu einem Quellgerät streamt, Audio-/visuelle Ein-/Ausgabeinformationen von einem Quellgerät zu empfangen und Audio/Video-Ein-/Ausgabeinformationen zu einem Quellgerät zu senden, und einen mit dem Prozessor gekoppelter Memory. Die Senke, wobei die Ein-/Ausgabeinformationen rohe Touchscreen-Sensordaten einschließen. Die Senke des Prozessors stellt einen Hauptlink und einen unabhängigen Empfangslink bereit. Die Senke des Prozessors implementiert eine DisplayPort-Topologie. Die Senke des Prozessors unterstützt sowohl isochrone als auch Bulk-Übertragungen und eingehendes Audio und Video. Die Senke des Prozessors fordert eine Quelle an, einen Wechsel zu initiieren, um eine Ein-/Ausgabedatenübertragung von der Senke zur Quelle zu ermöglichen. Die Senke kann ein Display einschließen, das mit dem Prozessor kommunikativ gekoppelt ist. Die Senke kann eine Batterie einschließen, die mit dem Prozessor gekoppelt ist.
Verweise in dieser Beschreibung auf „eine Ausführungsform” bedeuten, dass ein bestimmtes Merkmal, eine Struktur oder Charakteristik, die in Verbindung mit der Ausführungsform beschrieben wird, mindestens in einer innerhalb der vorliegenden Offenbarung eingeschlossenen Implementierung eingeschlossen ist. Somit beziehen sich Verwendungen des Ausdrucks „bei einer Ausführungsform” nicht notwendigerweise auf die gleiche Ausführungsform. Außerdem können die bestimmten Merkmale, Strukturen oder Charakteristika in anderen geeigneten Formen eingeführt werden, die sich von der bestimmten veranschaulichten Ausführungsform unterscheiden, und alle solche Formen können innerhalb der Ansprüche der vorliegenden Anmeldung eingeschlossen sein.
Während die Anmeldung unter Verwendung einer begrenzten Anzahl von Ausführungsformen beschrieben wurde, ist dem Fachmann bewusst, dass viele weitere Modifizierungen und Varianten möglich sind. Die beigefügten Ansprüche sollen alle solchen Modifikationen und Varianten abdecken, die dem Sinn und Schutzbereich der Offenbarung entsprechen.

Claims

Verfahren zur Übertragung von Daten zwischen einem Senkegerät und einem Quellgerät über einen DisplayPort mit einem Main-Link und einem AUX-Link, wobei das Senkegerät dazu ausgebildet ist, über den Main-Link Audio-/visuellen Inhalt zu einem Quellgerät zu streamen, und über den AUX-Link Ein-/Ausgabeinformationen zu dem Quellgerät zu senden und von dem Quellgerät zu empfangen, wobei das Senkegerät das Quellgerät auffordert, einen Pfadwechsel durchzuführen, um Ein-/Ausgabeinformationen über den Main-Link zu senden, wobei das Quellgerät einen virtuellen Kanal innerhalb des Main-Links bestimmt, und wobei das Quellgerät oder das Senkegerät eine Ein-/Ausgabeoperation durchführt und Ein-/Ausgabeinformationen über den virtuellen Kanal gesendet werden.
Verfahren nach Anspruch 1, einschließend das Bereitstellen eines Hauptlinks und eines unabhängigen Empfangslinks.
Verfahren nach Anspruch 1, einschließend das Implementieren einer DisplayPort-Topologie, die Audio-/visuelle und Ein-/Ausgabegeräte einschließt.
Verfahren nach Anspruch 1, einschließend das Unterstützen von sowohl isochronen als auch Bulk-Ein-/Ausgabeübertragungen und von eingehendem Audio und/oder Video.
Verfahren nach Anspruch 4, einschließend das Ermöglichen mehrerer gleichzeitiger, isochroner I/O-Operationen.
Verfahren nach Anspruch 4, einschließend das Ermöglichen von Priorisierung von Bulk-I/O-Operationen von Anwendungen bei einem Gerät, das eine Anfrage originiert.
Verfahren nach Anspruch 4, einschließend Entitäten in die Lage zu versetzen, bei gleichzeitigen, isochronen I/O-Anwendungen bei einem originierenden Gerät diese nach Priorität zu ordnen.
Verfahren nach Anspruch 4, einschließend das Ermöglichen des Entdeckens von Ein-/Ausgabegeräten und ihren Fähigkeiten, wenn sie in Downstreamgeräte eingesteckt sind, und dadurch das Anwenden eines Adressenerzeugungsmechanismus für eine DisplayPort-Schnittstelle für Ein-/Ausgabegeräte.
Verfahren nach Anspruch 1; einschließend dem Quellgerät zu ermöglichen, einen Datenblock mit FiFo-Semantik zu lesen.
Verfahren nach Anspruch 1, einschließend dem Quellgerät zu ermöglichen, DisplayPort-Konfigurationsdatenregister für eingehende und ausgehende Ein-/Ausgabeinformationen zu lesen.
Verfahren nach Anspruch 1; einschließend, dass ein Senkegerät ein Quellgerät auffordert, einen Wechsel zu initiieren, um eine Ein-/Ausgabedatenübertragung von dem Senkegerät zudem Quellgerät zu ermöglichen.
Ein oder mehrere nicht flüchtige, computerlesbare Medien, die Befehle speichern, die durch einen Prozessor ausgeführt werden, um ein Verfahren nach den Ansprüchen 1–11 auszuführen.