मेजबान नियंत्रकों के लिए समर्थन का स्तर, जैसा कि मैंने सामान्य अवलोकन में लिखा था, कुछ घटनाओं के होने पर उच्च स्तर का कारण होना चाहिए और उच्च स्तर के काम करने के लिए आवश्यक कार्य प्रदान करना चाहिए।
सुविधा के लिए, मैं समर्थन कोड के विभिन्न तत्वों के बारे में बात करूंगा जिसमें वे नियंत्रण प्राप्त करते हैं।

USB सबसिस्टम लॉन्च

तैयारी: पीसीआई उपकरणों की सूची में यूएसबी नियंत्रक

USB सबसिस्टम को सिस्टम बूट के दौरान usb_init से usb_init पर कॉल करके शुरू किया जाता है।

जब तक यूएसबी शुरू होता है, तब तक pcidev_list पीसीआई उपकरणों की एक सूची तैयार हो चुकी होती है। USB नियंत्रकों को सभी PCI डिवाइसों के वर्ग, उपवर्ग और इंटरफ़ेस कोड द्वारा पहचाना जाता है:

टाइप	वर्ग	उपवर्ग	इंटरफ़ेस
UHCI	0Ch	03h	00h
OHCI	0Ch	03h	10h
EHCI	0Ch	03h	20h
xHCI	0Ch	03h	30h

usb_init पीसीआई उपकरणों की सूची के माध्यम से कई बार जाता है, हर बार यूएसबी नियंत्रकों को उजागर करता है।

BIOS नियंत्रण अक्षम करना

कुछ BIOS USB चूहों, USB कीबोर्ड और USB फ्लैश ड्राइव को संभाल सकते हैं, जो ऑपरेटिंग सिस्टम के लिए डेटा प्रदान करते हैं जो USB के बारे में नहीं जानते हैं। चूहों और कीबोर्ड से डेटा को PS / 2 प्रारूप में बदल दिया जाता है और एक तरह से या किसी अन्य को ऑपरेटिंग सिस्टम में उसी तरह लाया जाता है जैसे कि एक वास्तविक PS / 2 माउस और / या कीबोर्ड सिस्टम में मौजूद है। यूएसबी फ्लैश ड्राइव int 13h के दृष्टिकोण से एक हार्ड ड्राइव प्रतीत होता है - इस तरह के समर्थन को माउस समर्थन की तुलना में अधिक बार पाया जाता है, क्योंकि यह फ्लैश ड्राइव से डाउनलोड करने के लिए आवश्यक है।
ऑपरेटिंग सिस्टम किसी भी प्रोसेसर मोड का उपयोग कर सकता है और अपने आप किसी भी रुकावट को संभाल सकता है। ताकि ऐसी परिस्थितियों में BIOS अभी भी एक पूर्वानुमानित वातावरण के साथ नियंत्रण प्राप्त कर सके, 486 के दशक में वापस (i386SL के विशेष संस्करण के साथ शुरू, सटीक होना), इंटेल एक विशेष प्रोसेसर मोड सिस्टम मैनेजमेंट मोड (एसएमएम) के साथ आया, जिसमें BIOS काम करता है, ऑपरेटिंग को बाधित कर रहा है प्रणाली। स्वयं प्रोसेसर का उपयोग करके एसएमएम में आना असंभव है; प्रोसेसर इस मोड में प्रवेश करता है जब मदरबोर्ड हार्डवेयर एक विशेष सिस्टम मैनेजमेंट इंटरप्ट (SMI) सिग्नल भेजता है। चिपसेट में निर्मित USB नियंत्रक, एक नियम के रूप में, सेटिंग्स के आधार पर, व्यवधान के बजाय एसएमआई उत्पन्न कर सकता है।

pcidev_list माध्यम से पहला पास BIOS को यह बताने के लिए है कि USB नियंत्रक ऑपरेटिंग सिस्टम के नियंत्रण में हैं, इसलिए BIOS को अब उनके साथ कुछ भी नहीं करना चाहिए।

यह महत्वपूर्ण है कि इस पास पर सभी साथियों को एक युग्मित ईएचसीआई नियंत्रक से संसाधित किया जाए। उदाहरण के लिए, आरोही पीसीआई निर्देशांक में ट्रैवर्सिंग यह सुनिश्चित करता है। कोड के पहले संस्करणों में, इस मार्ग को अलग से आवंटित नहीं किया गया था, और सभी EHCI नियंत्रकों को पहले संसाधित किया गया था; इसने कई विन्यासों पर काम किया, लेकिन परीक्षणों के दौरान यह पता चला कि सभी BIOS सही ढंग से नहीं लिखे गए हैं और गलत क्रम एसएमएम के अंदर सिस्टम क्रैश का कारण बन सकता है। विशेष रूप से, निम्नलिखित परिदृश्य संभव है:

• BIOS एक EHCI शटडाउन अनुरोध का पता लगाता है;
• BIOS नियंत्रक को डिकंफ़िगर करता है और इसके बारे में भूल जाता है;
• पोर्ट स्वामित्व एक साथी को स्थानांतरित करता है
• पोर्ट से जुड़ी एक फ्लैश ड्राइव भी एक साथी को जाती है;
• साथी एक नए उपकरण का संकेत देता है;
• चूंकि साथी अभी भी BIOS के नियंत्रण में है, यह डिवाइस को अपना मानता है, पता करता है कि यह किस तरह का डिवाइस है; एक पुरानी फ्लैश ड्राइव देखता है;
• और फिर यह पता चलता है कि यूएसबी फ्लैश ड्राइव के बारे में BIOS को याद है कि यह नियंत्रक पर स्थित था, जिसके बारे में BIOS सफलतापूर्वक भूल गया था। भूल गए नियंत्रक के डेटा का उपयोग करने की कोशिश जल्दी से एक दुखद अंत की ओर ले जाती है।

ईएचसीआई से पहले प्रसंस्करण साथी इस परिदृश्य की संभावना को समाप्त करता है।

BIOS को रिपोर्ट करने की विधि जो नियंत्रक को दी जानी चाहिए, नियंत्रक पर निर्भर करती है। संबंधित कार्यों को {u,o,e}hci_kickoff_bios कहा जाता है। UHCI, कालानुक्रमिक रूप से पहला इंटरफ़ेस है, एक विशेष संदेश प्रदान नहीं करता है, इसलिए uhci_kickoff_bios बस SMI पीढ़ी को बंद कर देता है और नियंत्रक को रोकता है। OHCI और EHCI में, BIOS के साथ संचार करने की प्रक्रिया सैद्धांतिक रूप से विनिर्देश में वर्णित है, लेकिन व्यावहारिक रूप से ... कुछ विवरण हैं। दोनों मामलों में, प्रक्रिया निम्नानुसार है: कुछ रजिस्टर में कुछ सेट करें और दूसरे बिट की वांछित स्थिति की प्रतीक्षा करें; यदि BIOS नियंत्रक के साथ काम करता है, तो नियंत्रक एसएमआई उत्पन्न करेगा, प्रोसेसर एसएमएम पर स्विच करेगा और BIOS को कॉल करेगा, BIOS नियंत्रक को अनलिमिटेड करेगा, दूसरे बिट को वांछित स्थिति में डाल देगा और एसएमएम से बाहर निकल जाएगा। ओएचसीआई के लिए प्रक्रिया का एक विस्तार यह है कि, जैसा कि परीक्षणों के दौरान निकला था, BIOS अच्छी तरह से चालू होने वाले रुकावट स्रोतों के साथ नियंत्रक को छोड़ सकता है; यदि कोई घटना एक अवरोध उत्पन्न करती है और ओएचसीआई चालक द्वारा अपने हैंडलर को स्थापित करने से पहले इंटरप्ट कंट्रोलर में बाधा उत्पन्न होती है, तो सिस्टम फिर से लटक जाएगा - ओएचसीआई बार-बार एक बाधा उत्पन्न करेगा, जिसे संभालने के लिए कोई नहीं है। इसलिए, BIOS के साथ बातचीत के दौरान ohci_kickoff_bios अवरोध उत्पन्न करता है और बातचीत के अंत में सभी OHCI रुकावट स्रोतों को बंद कर देता है। EHCI में, आप वास्तव में बिट को सेट नहीं कर सकते हैं "ऑपरेटिंग सिस्टम ने नियंत्रक स्वामित्व का अनुरोध किया है", आपको पहले यह जांचना होगा कि BIOS नियंत्रक का मालिक है; कुछ BIOS कंट्रोलर को "रिलीज़" करते हैं और सिस्टम बूट होने से पहले ही इसके बारे में भूल जाते हैं, SMI जेनरेशन बिट को नहीं हटाते हैं और अनुरोध को प्रोसेस नहीं कर सकते हैं - बार-बार SMI जेनरेट होने के कारण सिस्टम फिर से हैंग हो जाएगा।

नियंत्रक प्रारंभिक

अगर पहली पास usb_init USB नियंत्रकों का पता नहीं लगाता है, तो यह अपना काम बंद कर देता है। यदि USB नियंत्रक हैं, तो usb_init USB प्रसंस्करण के लिए आवंटित एक स्ट्रीम बनाता है और PCI डिवाइस की सूची से दो और पास बनाता है, प्रत्येक USB नियंत्रक के लिए usb_init_controller कहते usb_init_controller , एक संकेतक को usb_hardware_func संरचना में usb_hardware_func में पास करता है। दूसरी पास की प्रक्रिया ईएचसीआई, तीसरी - यूएचसीआई और ओएचसीआई। यहां ईएचसीआई को साथियों के सामने संसाधित किया जाता है, ताकि एचएस-डिवाइसेस को तुरंत ईएचसीआई के नियंत्रण में रखा जाए, ताकि वे खुद को एक साथी को संकेत दे सकें और तुरंत उससे लिया जा सके।

usb_init_controller फ़ंक्शन usb_init_controller में स्थित है। यह *hci_controller / usb_controller की एक जोड़ी के लिए मेमोरी आवंटित करता है, उन दोनों को शून्य से आरंभ करता है, कुछ usb_controller फ़ील्ड्स को इनिशियलाइज़ करता है, जिसके बीच usb_hardware_func ओर इशारा करते हुए HardwareFunc को अलग से नोट किया जाना चाहिए। इसके अलावा, यह usb_hardware_func.Init के नियंत्रक-विशिष्ट आरंभीकरण को भी कहता है। यदि कोई त्रुटि नहीं हुई है, तो अंतिम क्रिया के साथ, usb_init_controller सामान्य usb_controllers_list में नियंत्रक को पंजीकृत करता है और USB स्ट्रीम को जागृत करता है ताकि यह अगले वेक-अप समय के बारे में जानकारी को अपडेट कर सके।

usb_hardware_func.Init की विशिष्ट आरंभीकरण निम्नलिखित है:

• चैनल समूहों और उन दोनों के बीच संबंधों को जोड़ता है, जिसमें इंटरप्ट चैनल के बाइनरी ट्री भी शामिल हैं
• नियंत्रक से बाधा हैंडलर स्थापित करता है *hci_irq ;
• मेजबान नियंत्रक के रजिस्टरों को सही मान लिखते हैं, जिसमें *hci_controller संरचना का भौतिक पता लिखना शामिल है;
• रूट हब usb_controller.NumPorts के बंदरगाहों की संख्या की गणना करता है और सभी बंदरगाहों को बिजली की आपूर्ति करता है।

इंटरप्ट चैनलों के बाइनरी ट्री में सभी नियंत्रकों पर समान संरचना है, मैंने इसे पिछले लेख में वर्णित किया था। शेष प्रकार के चैनलों के बीच कनेक्शन नियंत्रक पर निर्भर करता है।

चैनलों के बीच संचार: यूएचसीआई

UHCI कालानुक्रमिक रूप से सबसे सरल हार्डवेयर वाला पहला नियंत्रक है। इसमें केवल एक पॉइंटर UhciBaseAddressReg , UhciBaseAddressReg , UhciBaseAddressReg में तालिका की ओर इशारा करते हुए। प्रत्येक फ़्रेम आयरन तालिका के संबंधित तत्व को लोड करता है और लिंक का पालन करना शुरू करता है। आवधिक प्रसारण की श्रृंखला में अंतिम प्रत्येक फ्रेम द्वारा संसाधित इंटरप्ट चैनलों की एक सूची है। सूची के अंतिम चैनल से, लिंक नियंत्रण प्रसारण की सूची में पहले चैनल की ओर जाता है। नियंत्रण वाहिकाओं और डेटा सरणियों के प्रसारण के सभी चैनल एक अंगूठी में जुड़े हुए हैं। जब नियंत्रक सभी गैर-आवधिक चैनलों को संसाधित करता है, तो यह गैर-आवधिक चैनलों की सूची की शुरुआत में लौटता है; इस योजना के साथ, अगले फ्रेम के लिए इंतजार किए बिना, एक नया गैर-आवधिक प्रसारण तुरंत संसाधित होना शुरू हो जाता है।

प्रसंस्करण प्राथमिकताओं के लिए यूएसबी विनिर्देश की आवश्यकताओं के पूर्ण अनुपालन में, इस योजना का एक स्पष्ट लाभ लोहे की सादगी है। विपक्ष: एक भारी भार के साथ, जब नियंत्रक के पास फ्रेम के अंत तक सभी स्थानान्तरण को संसाधित करने का समय नहीं होता है, तो एक ही प्रकार के चैनल असमान होते हैं - जो भाग्यशाली हैं जो सूची के शीर्ष पर हैं उन्हें एक महत्वपूर्ण लाभ प्राप्त होता है - और एक छोटे से लोड के साथ नियंत्रक लगातार मेमोरी से सिर्फ पढ़ने में व्यस्त रहता है। यह सुनिश्चित करने के लिए कि कोई नया काम नहीं है। निम्नलिखित नियंत्रकों के डेवलपर्स ने UHCI के नुकसानों को ध्यान में रखा।

चैनलों के बीच संचार: OHCI

OHCI में सात पूर्णांक रजिस्टर हैं, जिनमें से छह चैनल से जुड़े हैं। रजिस्टरों में से एक OhciHCCAReg अन्य नियंत्रकों (समकालिक स्थानांतरणों के लिए समायोजित) के समान आवधिक चैनलों की एक तालिका की OhciPeriodCurrentEDReg इशारा करता है, दूसरा OhciPeriodCurrentEDReg वर्तमान आवधिक चैनल को इंगित करता है और इतना उदासीन है कि यह आरेख में भी नहीं दिखाया गया है।

नियंत्रण और डेटा सरणियों के चैनल स्वतंत्र सूचियों में एकत्र किए जाते हैं। प्रत्येक सूची में दो पॉइंटर्स होते हैं: सूची की शुरुआत के लिए एक पॉइंटर Ohci{Control,Bulk}HeadEDReg और एक पॉइंटर को वर्तमान चैनल Ohci{Control,Bulk}CurrentEDReg । नियंत्रक एक-दूसरे से स्वतंत्र रूप से तीन सूचियों पर आगे बढ़ सकता है; प्राथमिकता सूची USB आवश्यकताओं के अनुरूप है। प्रत्येक फ़्रेम नियंत्रक आवधिक चैनलों की सूची के माध्यम से चलता है, लेकिन, यूएचसीआई के विपरीत, यह अन्य सूचियों में अपनी स्थिति नहीं खोता है, इसलिए, एक ही सूची के सभी चैनल समान हैं; यह UHCI के पहले माइनस को बंद कर देता है। OHCI रजिस्टरों में भी दो बिट्स हैं "सूची में एक नया ट्रांसमिशन है", नियंत्रण चैनलों की सूची के लिए एक, डेटा सरणियों के चैनलों की सूची के लिए दूसरा, सॉफ्टवेयर को एक नया ट्रांसमिशन जोड़ते समय संबंधित बिट सेट करना होगा। जब नियंत्रक सूची से गुजरना शुरू करता है, तो वह थोड़ा रीसेट करता है। जब नियंत्रक सूची के अंत तक पहुंचता है, तो यह बिट पर दिखता है; यदि बिट सेट है, तो नियंत्रक सूची की शुरुआत में जाता है, अन्यथा यह सूची को संसाधित करना बंद कर देता है। यह UHCI के दूसरे माइनस को बंद कर देता है।

चैनलों के बीच लिंक: EHCI

EHCI दो पॉइंटर रजिस्टरों तक सीमित है। उनमें से एक, EhciPeriodicListReg , अन्य नियंत्रकों के समान, आवधिक चैनलों की एक तालिका को इंगित करता है। एक और, EhciAsyncListReg , वर्तमान गैर-आवधिक चैनल को इंगित करता है। सभी गैर-आवधिक चैनल एक रिंग में बंद हो जाते हैं, अब यह एक शर्त है, UHCI के विपरीत, जहां यह संभावित कार्यान्वयनों में से एक है। आवधिक और गैर-आवधिक चैनलों के साथ चलना एक दूसरे से स्वतंत्र है, जो सभी गैर-आवधिक चैनलों को समान बनाता है। इंटेल ने यहां डेटा सरणी चैनलों पर नियंत्रण चैनल विशेषाधिकार की आवश्यकता की उपेक्षा करने का निर्णय लिया। ताकि गैर-आवधिक चैनलों में काम के अभाव में नियंत्रक, स्मृति से अंतहीन रीडिंग के लिए उत्सुक न हों, रिंग में मौजूद चैनलों में से एक को रिंग की "शुरुआत" के रूप में चिह्नित किया जाता है; जब नियंत्रक सक्रिय गियर्स का पता लगाए बिना रिंग के "शुरुआत" से दूसरी बार मिलता है, तो यह थोड़ी देर के लिए अंगूठी का प्रसंस्करण बंद कर देता है।

यूएसबी डिवाइस ऑपरेशन

USB विनिर्देशन की एक तस्वीर जो डिवाइस के विभिन्न राज्यों और उनके बीच संक्रमण का वर्णन करती है:

डिवाइस कनेक्शन

प्रारंभ के दौरान, डिवाइस कनेक्ट या डिस्कनेक्ट होने पर ओएचसीआई और ईएचसीआई नियंत्रक एक बाधा उत्पन्न करने के लिए कॉन्फ़िगर किए गए हैं। यूएचसीआई, अफसोस में, यह संभव नहीं है, इसलिए, यूएचसीआई नियंत्रक के साथ, यूएसबी स्ट्रीम समय-समय पर खुद से उठता है और कंट्रोलर पोर्ट को जोड़ता है, कनेक्शन स्थिति में बदलाव के लिए जाँच करता है। मतदान अंतराल UHCI_POLL_INTERVAL टाइमर टिक है, जो वर्तमान मूल्य पर 1 सेकंड है।

कनेक्टेड यूएसबी डिवाइस पावर्ड अवस्था में होस्ट कंट्रोलर के साथ इंटरैक्ट करना शुरू कर देता है।

एक नए USB उपकरण का आरंभ ... 100 मिलीसेकंड के एक ठहराव से होता है। चूंकि USB डिवाइस गतिशील रूप से जुड़े होते हैं, जब आप कनेक्ट करते हैं, तो संपर्कों के चीटर और कई लगातार कनेक्शन / डिस्कनेक्शन ईवेंट संभव हैं। उसी पोर्ट पर प्रत्येक नई घटना के साथ, उलटी गिनती फिर से शुरू हो जाती है। जब पावर्ड स्टेट एक पंक्ति में 100 मिलीसेकंड तक रहता है, तो कनेक्शन को स्थिर माना जाता है और कोड अगले इनिशियलाइज़ेशन चरण *hci_new_port आगे *hci_new_port ।

इस कारण से, जिस पर मैं थोड़ी देर बाद चर्चा करूंगा, कनेक्शन के प्रसंस्करण के अगले कई चरणों को समानांतर में कई उपकरणों के लिए नहीं किया जा सकता है। इसलिए, अगले चरण से पहले, नए यूएसबी डिवाइस को तब तक इंतजार करना पड़ सकता है जब तक कि वर्तमान डिवाइस ने इन सभी चरणों को पूरा नहीं कर लिया हो। प्रतीक्षा का अंत *hci_new_port.reset के साथ चिह्नित किया गया है, जो कि *hci_new_port आंतरिक फ़ंक्शन का हिस्सा है, यदि प्रतीक्षा अनावश्यक हो गई है, और साथ ही इसे इंटरफ़ेस में usb_hardware_func.InitiateReset उच्च स्तर के लिए रखा गया है।

अगला, *hci_new_port.reset कोड नियंत्रक को नए डिवाइस के पोर्ट के लिए रीसेट सिग्नल को सक्षम करने का *hci_new_port.reset है। विनिर्देश के अनुसार, रीसेट कम से कम 10 मिलीसेकंड तक होना चाहिए। OHCI अपने आप ही समय को गिनता है, अंतराल के अंत में यह रीसेट सिग्नल को बंद कर देता है और एक अवरोध उत्पन्न करता है, जिसके हैंडलर USB स्ट्रीम को अगले चरण में जाने के लिए संकेत करता है। UHCI और EHCI में, आपको प्रोग्राम को समय-समय पर पढ़ने की आवश्यकता है। प्रोसेसर को निष्क्रिय स्टैंडबाय चक्र के साथ लोड नहीं करने के लिए, सिस्टम टाइमर के अनुसार जागने के लिए रीसेट सिग्नल योजनाओं को चालू करने के बाद यूएसबी स्ट्रीम और सो जाता है। KolibriOS में एक टाइमर 100 हर्ट्ज की आवृत्ति पर टिक जाता है, एक बार हर 10 मिलीसेकंड पर। न्यूनतम 10 मिलीसेकंड रीसेट की गारंटी देने के लिए, कोड दो टाइमर नमूनों की प्रतीक्षा करता है। टाइमर के दूसरे टिक के बाद, कोड नए डिवाइस के पोर्ट के लिए रीसेट सिग्नल को बंद कर देता है, *hci_port_reset_done , और अगले चरण पर आगे बढ़ता है।

USB2 में, रीसेट प्रक्रिया डिवाइस की गति निर्धारित करती है। मैं आपको पिछले भाग से याद दिलाता हूं कि ईएचसीआई केवल हाईस्पीड उपकरणों के साथ काम कर सकता है, और यूएसबी 1 गति पर चलने वाले सभी उपकरणों को एक यूएसबी 1 साथी या हब के लिए निर्देशित किया जाना चाहिए। सॉफ़्टवेयर बिंदु से, रीसेट के अंत के बाद, EHCI या तो पोर्ट को डेटा ट्रांसफर की अनुमति देता है या नहीं। यदि, रीसेट के बाद, पोर्ट अक्षम रहता है, तो कनेक्टेड डिवाइस USB2 गति पर काम नहीं करता है। इस मामले में, यह केवल बंदरगाह के मालिक को साथी को चुनने के तर्क को सूचित करने के लिए रहता है; उसके बाद, साथी एक सामान्य कनेक्शन ईवेंट देखेगा और उसे प्रोसेस करेगा।

रीसेट के बाद, कई डिवाइस पहले से ही उच्च स्तर पर कॉन्फ़िगर करने के लिए तैयार हैं। लेकिन सभी नहीं। विनिर्देश को रीसेट के बाद कम से कम 10 मिलीसेकंड के ठहराव की आवश्यकता होती है, और, जैसा कि परीक्षण दिखाते हैं, कुछ उपकरणों को वास्तव में इस ठहराव की आवश्यकता होती है। पिछले चरण के समान, USB स्ट्रीम दो टाइमर गणनाओं में सो जाती है, इस बार OHCI सहित सभी नियंत्रकों के लिए।

एक रीसेट और एक बाद के ठहराव के बाद, डिवाइस संचालित स्थिति से डिफ़ॉल्ट स्थिति में स्विच हो जाता है - दो में से एक "आधा काम" बताता है कि जब डिवाइस शून्य समापन बिंदु के लिए डेटा प्राप्त करने और भेजने के लिए तैयार है, लेकिन अभी तक पूरी तरह से आरंभिक नहीं है। डिफ़ॉल्ट स्थिति में, डिवाइस USB बस पर शून्य पते पर प्रतिक्रिया करता है। यही कारण है कि समानांतर में दो उपकरणों के लिए रीसेट करना असंभव है: अन्यथा, दो डिवाइस निकल गए होंगे, जिनमें से प्रत्येक ने सोचा होगा कि बाद की सेटिंग विशेष रूप से इसके लिए लागू होती है।

डिवाइस का शून्य समापन ऑपरेशन के लिए तैयार है, यह चैनल खोलने का समय है। चैनल संरचना में चैनल की विशेषताएं शामिल हैं - उदाहरण के लिए, इसका प्रकार - और डिवाइस की विशेषताएं: डिवाइस की गति, बस पर डिवाइस का पता, सूचक से usb_controller । *hci_port_init कोड जिसे इस चरण में कहा जाता है, *hci_new_device फ़ंक्शन के संचालन को *hci_new_device है, जो कि usb_hardware_func.NewDevice हब के लिए API में बनाया गया है। उत्तरार्द्ध एक छद्म चैनल संरचना तैयार करता है जिसमें डिवाइस की विशेषताओं को सही ढंग से भरा जाता है, और चैनल की विशेषताओं के मूल्य मायने नहीं रखते हैं। इस पर, होस्ट कंट्रोलर सपोर्ट कोड स्वतंत्र क्रियाओं को usb_new_device करता है और लॉजिकल usb_new_device के usb_new_device फंक्शन पर कंट्रोल usb_new_device करता है; इसके अलावा, जब तक उपकरण बंद नहीं किया जाता है, तब तक होस्ट कंट्रोलर सपोर्ट कोड केवल उच्च स्तर के अनुरोधों को निष्पादित करता है।

चैनल खोलने और चैनल प्रसारण

नियंत्रक के दृष्टिकोण से, ट्रांसमिशन डिस्क्रिप्टर (एक डिस्क्रिप्टर पूरे ट्रांसमिशन का वर्णन कर सकता है, या हो सकता है कि कुछ भाग, नियंत्रक के आधार पर) एकल-लिंक की गई सूची के रूप में व्यवस्थित हो, पहले डिस्क्रिप्टर का भौतिक पता चैनल संरचना में है, अगले डिस्क्रिप्टर का भौतिक पता पिछले वर्णनकर्ता में है। जब नियंत्रक एक डिस्क्रिप्टर को संसाधित करता है, तो यह वहां अगले डिस्क्रिप्टर का पता लिखकर चैनल संरचना को अपडेट करता है। यह निम्नानुसार है कि जब ट्रांसमिशन कतार चल रही है, तो होस्ट कंट्रोलर सपोर्ट कोड हार्डवेयर के साथ दौड़ की स्थिति से बचने के लिए अगले डिस्क्रिप्टर के पते को अपडेट नहीं कर सकता है। कार्य को व्यवस्थित करने के लिए, आपको कतार के अंत में एक अतिरिक्त खाली विवरणक की आवश्यकता होती है। नियंत्रक के लिए एक खाली हैंडल निष्क्रिय है। जब कोड एक डिस्क्रिप्टर जोड़ना चाहता है, तो यह वर्तमान खाली डिस्क्रिप्टर भरता है, अगले खाली डिस्क्रिप्टर का चयन करता है, पुराने डिस्क्रिप्टर में नए डिस्क्रिप्टर के लिए एक लिंक डालता है, पुराने डिस्क्रिप्टर को अंतिम क्रिया के साथ सक्रिय करता है और यह सब कंट्रोलर के साथ रिकॉर्ड को इंटरसेक्ट किए बिना करता है। जब नियंत्रक निष्क्रिय डिस्क्रिप्टर पर पहुंचता है, तो यह चैनल संरचना में निष्क्रिय डिस्क्रिप्टर के लिंक को छोड़कर कतार को संसाधित करना बंद कर देता है।

खाली डिस्क्रिप्टर की आवश्यकता का एहसास होने के बाद, एक चैनल खोलना और ट्रांसमिशन ट्रांसमीशन करना काफी सरल है। जब आप usb_hardware_func.InitPipe = *hci_init_pipe तो आप मदद करते हैं:

• किसी मौजूदा चैनल या छद्म चैनल से उपकरण विशेषताओं की प्रतिलिपि बनाएँ,
• प्रेषित डेटा के आधार पर चैनल की विशेषताओं को भरें,
• चैनल संरचना में खाली वर्णनकर्ता का भौतिक पता पंजीकृत करें,
• एक खाली डिस्क्रिप्टर को निष्क्रिय के रूप में प्रारंभ करें,
• अंतिम चरण चैनल को संबंधित सूची में सम्मिलित करना है।

आवधिक चैनलों के लिए, आपको अभी भी वांछित सूची का चयन करने की आवश्यकता है; यह योजनाकार का कार्य है, जिसकी चर्चा मैं अगले लेख में करूंगा। कतार में स्थानांतरण usb_hardware_func.AllocTransfer = *hci_alloc_transfer से स्थानांतरण usb_hardware_func.AllocTransfer = *hci_alloc_transfer एक चरण के लिए usb_hardware_func.AllocTransfer = *hci_alloc_transfer को भरने में विभाजित किया जाता है, जिसे दो या तीन बार नियंत्रण हस्तांतरण के लिए कहा जाता है, और हस्तांतरण की usb_hardware_func.InsertTransfer = *hci_insert_transferफ़ंक्शन AllocTransferट्रांसफर चरण को अलग-अलग डिस्क्रिप्टर में विभाजित करता है और उन्हें भरता है, एक खाली डिस्क्रिप्टर से शुरू होता है और यदि आवश्यक हो तो अतिरिक्त डिस्क्रिप्टर को हाइलाइट करता है। फ़ंक्शन InsertTransferपूर्व खाली वर्णनकर्ता को सक्रिय करता है।

प्रत्येक डिस्क्रिप्टर में एक आईओसी बिट होता है, जो पूरा होने पर बाधित होता है। जब नियंत्रक IOC बिट सेट के साथ डिस्क्रिप्टर को संसाधित करता है, तो यह एक बाधा उत्पन्न करता है। होस्ट कंट्रोलर सपोर्ट कोड इसे प्रत्येक ट्रांसमिशन के अंतिम डिस्क्रिप्टर में सेट करता है।
OHCI - , ( IOC) : , . ohci_controller , , . OHCI «» , .
UHCI EHCI , UHCI EHCI , , , .
USB, *hci_process_finalized_td . — , ; . — , callback- , .

. , , — ( « » ). , usb_hardware_func.SetDeviceAddress : . , usb_hardware_func.SetEndpointPacketSize : . UHCI — , , . , . , . EHCI , , , . , : , , , , .

OHCI EHCI , , . , . OHCI . EHCI Interrupt on Async Advance Doorbell : « , » . , . , .

: — OHCI EHCI, UHCI — usb_device_disconnected , . , 100 , .

1:
2: -
3: -
4:
5:
6: