On Wed, Nov 18, 2009 at 07:09:14PM +0900, Magnus Damm wrote:
On Tue, Nov 17, 2009 at 9:59 PM, Mark Brown
I understand exactly what the runtime PM stuff and the driver are doing here, the issue is the mandatory suspend and resume functions.
Cool, but don't you think it makes sense to see how other architectures will deal with this first?
Of course, the other way of looking at it would be that it'd be good to provide the best possible implementation in the first architecture so that others can draw inspiration from it.
Looking at what you've got it seems clearly sane as-is modulo this issue and I can see how it maps onto the Samsung/OMAP style hardware so it doesn't set off any alarm bells for me on that front. The only thing I'm a bit unsure about with your implementation is mixing in the clock gating but to be honest that's something that could be changed on a per device basis anyway.
What is the reason for requiring that the driver provide stub functions? For me the issue is that if it's mandatory for the driver to provide the functions then having stub functions in there makes the driver look like it is abusing the API by not implementing mandatory functionality.
I see your point, but there is another side to it as well. Having the stubs there is a way of showing that these functions may be called as part of the Runtime PM management. Not having them would confuse people even more IMO.
Given that they're part of dev_pm_ops which already does such things as routine I'm not sure that it's particularly confusing. To me it's confusing that one might be required to do something at runtime suspend time - since the driver has to explicitly tell the PM core that the device is idle so it seems reasonable to expect that the hardware would already be quiesced and all that'd be needed would be to power down the block.
I can spend some time on updating the drivers and removing the nop-stubs if you'd like, but I'd rather not since I suspect that I'll have to update things again when we get Runtime PM for ARM or other non-sh architectures.
Like I say, the SH doesn't sound fundamentally different to the ARMs here.