Hello, Alan Cox wrote: >> Oh well, that's how we do PIO data transfer when not polling anyway. We >> kick HSM directly from the interrupt handler and do PIO inside the >> interrupt handler. The change made here is to make polling PIO act the >> same way. > > Which is making a horrendous problem worse than it was before. In PIO CD > mode I'm actually losing serial characters and time its that bad. Yeap, things get pretty choppy in PIO mode. > Right now we can push the pio transfer out to run after the IRQ handler a > variety of ways and the locking for it isn't too bad. Make this change > and we are sunk. So, are you suggesting pushing data transfer or the whole HSM to workqueue? I'm all for that. I just thought it didn't make sense to NACK the patch because it grabs locks while doing polling PIO, which mostly happens only for EH commands when we do all the heavy lifting PIO directly from the interrupt handler. Anyways, if that's the plan, as Albert suggested earlier, we can just mark that HSM is running in ap->pflags or somewhere and skip Status clearing if it's running. It's not like the controller is gonna raise interrupt while it's transferring data anyway (we always have leading status checks before data transfer). One thing I'm worried about is that somehow I'm thinking there are controllers/devices out there which choke if there PIO data transfer is interrupted (timing-wise). Is this something I just imagined up? Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
