KolibriOS में USB समर्थन: अंदर क्या है? भाग 2: मेजबान नियंत्रकों के साथ काम करने की मूल बातें

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

इंटरप्ट और थ्रेड्स

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

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

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

डेटा संरचनाएं

होस्ट नियंत्रक समर्थन स्तर के लिए निम्न संरचनाएँ महत्वपूर्ण हैं: नियंत्रक डेटा संरचना *_controller , चैनल डेटा संरचना *_pipe , *_pipe समकालिक स्थानांतरण डेटा संरचना *_gtd । उनमें से प्रत्येक में दो भाग होते हैं: होस्ट नियंत्रक के लिए विशिष्ट *hci_* और सभी usb_* नियंत्रकों के लिए सामान्य। मेजबान नियंत्रक को इसकी संरचनाओं के संरेखण की आवश्यकता होती है। नियंत्रक डेटा पृष्ठ संरेखण, अर्थात् 1000 h बाइट्स का उपयोग करता है। विभिन्न नियंत्रकों के लिए अन्य डेटा का संरेखण अलग है।

KolibriOS में, प्रत्येक संरचना के दोनों हिस्सों को क्रमिक रूप से मेमोरी में संग्रहीत किया जाता है। दोनों संरचनाओं के लिए मेमोरी एक चरण में आवंटित की जाती है, आवश्यक संरेखण को ध्यान में रखते हुए। मेमोरी में पहला भाग संरेखण सुनिश्चित करने के लिए मेजबान नियंत्रक के साथ संचार करने के लिए जिम्मेदार हिस्सा है। दोनों हिस्सों को संबोधित करने के लिए, एक एकल सूचक का उपयोग किया जाता है जो भागों के बीच की सीमा को इंगित करता है; नकारात्मक *hci_* लिए *hci_* डेटा, गैर-नकारात्मक लोगों के लिए - usb_* डेटा हैं। usb_controller सूचक लगातार usb_controller रजिस्टर में रखा गया है। चैनल usb_pipe सूचक है; usb_pipe फ़ील्ड में से एक संबंधित usb_controller लिए एक संकेतक है।

कोड जो संरचनाओं के लिए मेमोरी आवंटित करता है, उसे संरचनाओं के आकार और आवश्यक संरेखण दोनों को जानना चाहिए। *_controller , एक पृष्ठ पर अंक लगाना का उपयोग किया जाता है जो स्वचालित रूप से पृष्ठ सीमा पर संरेखण की गारंटी देता है। usb_controller को usb_controller के लिए जिम्मेदार कोड द्वारा बुलाया जाता है, संरचना का आकार *hci_controller से लिया गया है; जैसा कि मैंने सामान्य अवलोकन में उल्लेख किया है, usb_hardware_func मेजबान नियंत्रक के लिए बाकी कोड के लिए विशिष्ट चीजों का वर्णन करता है।
*_pipe और *_gtd प्रत्येक उदाहरण के लिए एक पृष्ठ आवंटित करना बेहद बेकार होगा, और छोटे ब्लॉकों के लिए एक सामान्य कर्नेल ढेर का उपयोग करना संरेखण आवश्यकताओं के कारण असुविधाजनक है। इसलिए, उनके लिए, कोड एक निश्चित आकार के ब्लॉक आवंटनकर्ता का उपयोग करता है, जो पृष्ठ का चयन करते हुए, इसे दिए गए आकार के ब्लॉकों में काटता है और उन्हें एक-एक करके देता है। यदि आबंटित आकार एक से अधिक है, उदाहरण के लिए, 16 बाइट्स, तो सभी आबंटित ब्लॉकों में 16 का पता एक से अधिक होगा। यहां, आबंटक को प्रत्येक आकार के लिए अलग डेटा की आवश्यकता होती है; इसलिए उन सभी को usb_hardware_func संरचना में शामिल नहीं करने के लिए, बाद में AllocPipe / FreePipe आवंटन / रिलीज FreePipe लिए *_pipe संरचनाओं और AllocTD / FreeTD की एक जोड़ी के लिए *_gtd संरचनाओं की एक जोड़ी शामिल है।

होस्ट नियंत्रक को उनके साथ काम करने के लिए सभी संरचनाओं के भौतिक पते जानना चाहिए। नियंत्रक प्रारंभ के दौरान *hci_controller संरचना का पता दर्ज किया गया है। गैर-समकालिक संचार के डेटा संरचनाओं के पते एक एकल लिंक की गई सूची में *hci_pipe अंदर पहले तत्व के भौतिक पते और *hci_pipe अंदर प्रत्येक अगले तत्व के भौतिक पते के साथ एकत्र किए जाते हैं।



चैनलों को कई सूचियों में बांटा गया है। प्रत्येक सूची के अंदर तीन कनेक्शन होते हैं: हार्डवेयर के लिए अगले चैनल का भौतिक पता, सॉफ्टवेयर के लिए अगले और पिछले चैनलों के आभासी पते। एक सूची में नियंत्रण प्रसारण के लिए सभी चैनल शामिल हैं। एक अन्य सूची में डेटा सरणियों को प्रसारित करने के लिए सभी चैनल शामिल हैं।
इंटरप्ट चैनल की सूची एक बाइनरी ट्री में आयोजित की जाती है, जैसा कि चित्र में दिखाया गया है, जहां सर्कल इंटरप्ट चैनल की सूची दर्शाते हैं और तीर निम्नलिखित तत्वों के भौतिक पते दर्शाते हैं। मेजबान नियंत्रक समय की प्रत्येक इकाई (UHCI और OHCI के लिए एक फ्रेम, EHCI के लिए एक माइक्रोफ्रेम) शुरू करता है, फ्रेम नंबर के निचले n बिट्स (बस फ्रेम, भले ही यह EHCI हो) ले कर, पता तालिका के तत्त्व को लेता है जो *hci_controller , और का हिस्सा है। अगले तत्व के लिंक का अनुसरण करना शुरू करता है। पहली सूची इस प्रकार हर 2 ⁿ मिलीसेकंड पर एक बार संसाधित की जाएगी। फिर लिंक के जोड़े "एक साथ चिपके रहते हैं": दो लिंक अगली सूची में ले जाते हैं ताकि अगली सूची को पता तालिका के एक पूरे चक्र में दो बार ^n-1 मिलीसेकंड के बाद नियंत्रक का ध्यान दो बार प्राप्त हो। अंत में एक सूची है जिसके तत्वों को प्रत्येक मिलीसेकंड संसाधित किया जाता है। इंटरप्ट चैनलों का ऐसा संगठन आपको दो की शक्ति से मिलीसेकंड में व्यक्त किए गए प्रसंस्करण अंतराल के साथ चैनलों को लागू करने की अनुमति देता है। USB विनिर्देशन आपको अनुरोध के मुकाबले वास्तविक मतदान अंतराल बनाने की अनुमति देता है।

EHCI में, एक नियोजन इकाई एक माइक्रोफ़्रेम है, जो एक फ्रेम से 8 गुना छोटा है। हालांकि, चैनल सूचियों पर चलना अभी भी फ्रेम नंबर द्वारा निर्देशित है। इसलिए, प्रत्येक रुकावट चैनल में एक 8-बिट बिटमास्क होता है, जिसमें प्रत्येक बिट फ्रेम के अंदर एक माइक्रोफ्रेम से मेल खाती है, बिट का एक शून्य मान लिंक के माध्यम से चलने की तत्काल निरंतरता की ओर जाता है। कुछ चैनलों में दो ऐसे मुखौटे हैं जो एकल बिट्स में अंतर नहीं करते हैं, लेकिन बाद में उस पर अधिक।

समकालिक प्रसारण के लिए समर्थन का विकास चल रहा है, इसलिए अभी मैं हार्डवेयर के बारे में कुछ शब्द कहूंगा। ohci_pipe में, ohci_pipe को दूसरों के समान संबोधित किया जाता है: ohci_pipe में एक बिट है जो ट्रांसमिशन डेटा संरचनाओं, ohci_pipe के प्रारूप के लिए जिम्मेदार है और बाकी एक अलग प्रारूप का उपयोग करते हैं। यूएचसीआई और ईएचसीआई में आइसोक्रोनस चैनलों के लिए डेटा संरचनाएं नहीं हैं, और आइसोक्रोनस ट्रांसमिशन संरचनाओं को अवरोधन संरचनाओं के साथ पता तालिका में डाला जाता है। ताकि नियंत्रक समझ सके कि क्या पता एक चैनल को इंगित करता है या एक समकालिक संचरण (जिसमें वास्तव में दो अलग-अलग प्रकार हैं), पते के दो बिट्स उस संरचना के प्रकार को आवंटित किए जाते हैं जो इस पते पर स्थित है। नतीजतन, यूएचसीआई और ईएचसीआई के लिए संख्या एन 10 है, लेकिन प्रति सेकंड या उससे अधिक मतदान अंतराल का समर्थन नहीं करना है, लेकिन इतना है कि एक समकालिक स्थानांतरण के एक टुकड़े को संसाधित करने के बाद, सॉफ़्टवेयर के पास अगले टुकड़े का अनुरोध करने के लिए एक दूसरा है। OHCI n = 5 में।

स्थानान्तरण और लेन-देन

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

डेटा का आकार जो एक जोड़ी *_gtd संरचनाओं का वर्णन कर सकता है, वह भी सीमित है। यदि सभी डेटा एक *_gtd में फिट नहीं *_gtd , तो हस्तांतरण को कई भागों में विभाजित किया जाना चाहिए। स्प्लिट स्थानों को चुना जाना चाहिए ताकि डिवाइस के दृष्टिकोण से, एक ट्रांसमिशन में क्या हो रहा है, अर्थात, अंतिम को छोड़कर सभी भागों का आकार अधिकतम लेनदेन आकार से विभाजित होना चाहिए।

UHCI इंटेल द्वारा निर्मित कालानुक्रमिक पहला इंटरफ़ेस है; UHCI हार्डवेयर कार्यान्वयन की सादगी पर केंद्रित है। नतीजतन, यूएचसीआई नियंत्रक को स्थानांतरण के बारे में कुछ भी नहीं पता है, और एक uhci_gtd संरचना एक लेनदेन का वर्णन करती है। बड़े हस्तांतरणों के लिए, यह सभी लेन-देन के लिए अलग-अलग मेमोरी के एक बड़े ओवरहेड की ओर जाता है।
OHCI और EHCI में, नियंत्रक पहले से ही लेनदेन में स्वतंत्र रूप से लंबे हस्तांतरण को विभाजित करने में सक्षम है, यहां प्रतिबंध कमजोर हैं। ohci_gtd में डेटा के दो पृष्ठों के लिए दो फ़ील्ड हैं, सबसे अच्छे मामले में यह 2000h बाइट्स है, सबसे खराब स्थिति में (यदि डेटा xxxxxFFFh पते से शुरू होता है) - 1001h बाइट्स = 4 किलोबाइट + 1 बाइट। पाँच पृष्ठ पहले से ही ehci_gtd में ehci_gtd , जो सबसे खराब स्थिति में 4001h बाइट्स की सीमा देता है। यदि अधिक डेटा है, तो ट्रांसमिशन को अभी भी कई टुकड़ों में विभाजित करने की आवश्यकता है।

USB2 में, विभाजित लेनदेन दिखाई दिए। USB2 विनिर्देश ने 480 मेगाबिट्स (उच्च-गति, HS) की एक नई डेटा अंतरण दर को जोड़ा है, लेकिन अभी भी दो गति USB1, 12 मेगाबिट्स (पूर्ण-गति, FS) और 1.5 मेगाबिट्स / s (कम-गति, LS) का समर्थन करता है )। एक समय में एक यूएसबी बस पर, आप केवल एक डिवाइस के साथ संवाद कर सकते हैं। USB1 में, एक मेजबान कंट्रोलर द्वारा नियंत्रित बस एक समान थी, और एलएस डिवाइस को लेनदेन के दौरान यह (12 मेगाबिट्स / सक्षम) 1.5 मेगाबिट्स / सेकंड की गति से काम करती थी। यूएसबी 2 में, एचएस बस को उसी तरह से धीमा करना अव्यावहारिक होगा, इसलिए एक सामान्य बस है जो हमेशा उच्च गति पर काम करती है, और कई एफएस / एलएस बसें जिनसे एफएस / एलएस डिवाइस जुड़े हुए हैं। बसों के बीच संचार हब की जिम्मेदारी है जिससे कम गति वाला डिवाइस जुड़ा हुआ है; विनिर्देशन ट्रांस्लेशन ट्रांसलेटर (TT) हब के संबंधित भाग को नाम देता है।

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



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

EHCI और साथियों

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



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

श्रृंखला के सभी लेख

भाग 1: सामान्य रूपरेखा
भाग 2: मेजबान नियंत्रकों के साथ काम करने की मूल बातें
भाग 3: होस्ट कंट्रोलर सपोर्ट कोड
भाग 4: चैनल समर्थन स्तर
भाग 5: तार्किक उपकरण स्तर
भाग 6: हब ड्राइवर