On Wed, 17 Oct 2012, vikram pandita wrote: > > Alan > I was looking at your implementation [1] on Periodic schedule > enable/disable using hrtimer. > Looks really neat. Thank you. > Current implementation is: > On Periodic Enable, Sate is: PSE =1 , PSS dont care - will be set > automatically after > 7 microframes time > On Periodic Disable, Sate is: PSE =0 , PSS dont care - will be cleared > automatically after > 7 microframes time > > Could you shed some light why we don't make sure that: > On Periodic Enable, Sate is: PSE =1 and PSS=1 > On Periodic Disable, State is: PSE =0 and PSS=0 > > Why on enable/disable would we not want to ensure PSS state is same as PSE? Because it would be a waste of time. Eventually the controller will set PSS equal to PSE; why should the driver wait for it? The driver can go on to do other useful work in the meantime. The EHCI spec states that PSE shouldn't be changed unless PSS is equal to PSE, so we have to wait _before_ changing PSE. But we don't have to wait _after_ changing it. > On 3.0 kernel with older implementation, this leads to HC died issues, > hence this query. The older implementation was a over-cautious; after waiting 1125 us it would die. The current implementation may be a little under-cautious, because it gives up waiting for PSS after about 20 ms (and it doesn't die). Some controllers may take even longer to adjust PSS, although I can't imagine why. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
