On Sat, Jan 21, 2012 at 09:38:13PM +0100, Sylwester Nawrocki wrote: > On 01/21/2012 07:31 PM, Mark Brown wrote: > > Yeah, me too but it seemed idiomatic. Frankly I don't really understand > > why there's a synchronous version of put. > The synchronous put callbacks might be needed for instance in a bus core code > to make sure the child device drivers aren't accessing resources while > bus adapter (USB/PCI) is being unplugged for example. In cases like platform In those cases it feels like we ought to either do what we do with suspend and make sure the device is resumed on the exit path (like we do when we're entering system suspend) or just disable the PM operations, especially given that we're reference counting. > I2C bus controller it might be more optimal to use asynchronous put versions. > As there are usually performed fast multiple adjacent transfers and multiple > put runtime get/put might be merged to one get/put due to scheduling latency. > However I've never really measured that. Implementing autosuspend might give > some insights about that. As I was just saying in another thread I do think it's probably worth considering adding some small amount of autosuspend by default in order to try to deal with that sort of pattern. Of course for I2C devices I rather suspect the bus is sufficiently slow that any performance work we do in the host is immaterial. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
