Hi again,
El lun, 09-05-2011 a las 15:45 -0400, Jarod Wilson escribiÃ:
> Well, looking at the resume function, I wasn't sure if I wanted to
> mess with things while it was possibly trying to finish up tx, but
> upon closer inspection, I don't think we can ever get into the
> state where we're actually doing anything in the tx handler where
> it would matter. If dev->transmitting is true and we're actually
> able to grab the spinlock, it means we're just in the middle of
> the mdelay for remaining_us, and everything done after that is
> partially redundant with init_hardware anyway. So yeah, it looks
> safe to me to just put in the init_hardware unconditionally above
> the check for dev->transmitting.
>
> On a related note though... what are the actual chances that we are
> suspending in the middle of tx, and what are the chances it would
> actually be of any use to resume that tx after waking up?
>
> So what I'm now thinking is this: add a wait_event_interruptible on
> tx_ended in the suspend path if dev->transmitting to let tx finish
> before we suspend. Then in resume, we're never resuming in the
> middle of tx and the whole conditional goes away.
That looks like an approach way nicer than the current one. That way
sent codes wouldn't be interrupted during transmission by a concurrent
suspend request and, yes, the resume function is more elegant too.
Please go ahead with this idea if you wish :-)
Best regards,
Juan JesÃs.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
