From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <441BC8F8.50002@austin.rr.com> Date: Sat, 18 Mar 2006 02:46:48 -0600 From: Lonnie Mendez User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] question on implementation of uhci host controller driver References: <0da22f726ce8d3d875d3d6710f523acd@terzarima.net> In-Reply-To: <0da22f726ce8d3d875d3d6710f523acd@terzarima.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 173a629a-ead1-11e9-9d60-3106f5b1d025 Charles Forsyth wrote: >>being set. Of course this doesn't explain why it works on physical >>hardware. >> >> > >probably because the bit reflects the state of the frame processor, >so that the bit is set iff it is halted, regardless how it came to be that way >(which is what i'd expected, and indeed i believe that bit is set after reset). >it's a reasonable way to do the hardware, but software probably just >memsets an emulated register to 0 and doesn't set the bit initially. > Hm. The initial (default) value for USBSTS register is 0. Looking at HCRESET it states that "the Host Controller module resets its internal timers, counters, state machines, etc to their initial value." GRESET does something similar. If the initial value isn't the default value then I'll be understanding this a whole lot better. For comparison, here is the initial take from windows xp's uhci driver: uhci readw port=0x0000 val=0x0000 uhci writew port=0x0000 val=0x0004 uhci writew port=0x0000 val=0x0000 uhci writew port=0x0004 val=0x0000 uhci readw port=0x0000 val=0x0000 uhci writew port=0x0000 val=0x0000 uhci readw port=0x0002 val=0x0000 uhci readw port=0x0002 val=0x0000 uhci readw port=0x0002 val=0x0000 uhci readw port=0x0002 val=0x0000