On Fri, 2009-06-26 at 14:47 -0400, Devin Heitmueller wrote: > On Fri, Jun 26, 2009 at 2:34 PM, Andy Walls<awalls@xxxxxxxxx> wrote: > > Hmm, that sure sounds like a V4L2 spec violation. From the V4L2 close() > > description: > > > > "Closes the device. Any I/O in progress is terminated and resources > > associated with the file descriptor are freed. However data format > > parameters, current input or output, control values or other properties > > remain unchanged." > > > > > > Regards, > > Andy > > I have no idea how that would work with power management. It would > mean that all the tuners and demod drivers which don't maintain state > across powerdown would have to maintain some sort of cache of all of > the programmed registers, and we would need to add some sort of > "wakeup" callback which reprograms the device accordingly (currently > we have a sleep callback but not a corresponding callback to wake the > device back up). That sounds about right. > As a requirement, it might have been suitable for PCI cards where you > don't care about power management (and therefore never power anything > down), but I don't know how practical that is for USB or minicard > devices where power management is critical because you're on a > battery. All I'm saying is that it is obviously the expected behavior, it the specified behavior, and all the userland apps and scripts are written with that behavior in mind. The applications' expectation of that behavior is, of course, why we are having this discussion. Assuming arguendo, maintaing state in the face of power management is a hard requirement on the driver; I'll still contend it's harder to change the existing base of applications and user scripts. Until the spec and all the existing apps change, not adhering to the spec leads to user confusion. My $0.02 Regards, Andy > Devin -- 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
