ext Gupta, Ajay Kumar wrote:
-----Original Message-----
From: Arnaud Mandy [mailto:ext-arnaud.2.ma...@nokia.com]
Sent: Thursday, December 17, 2009 7:41 PM
To: Gupta, Ajay Kumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Balbi Felipe
(Nokia-D/Helsinki); davi...@pacbell.net; Gadiyar, Anand
Subject: Re: [PATCH 2/3 v3] musb: Add context save and restore support
ext Gupta, Ajay Kumar wrote:
<snip>
#ifdef CONFIG_PM
+static struct musb_context_registers musb_context;
+
+void musb_save_context(struct musb *musb)
+{
Could you add one more parameter to this function call, which would
select either if we want to save the musb_platform context or not?
I m working at the moment on turning off the musb when cable unplugged
and turning it on with restoring context after cable re-connect.
In this case I don't need to restore the the musb_platform_context
since
I just set them before calling this one.
Same apply for restore.
what do you think?
I could also modify slightly this implementation after it is ready and
submit it.
I think you want to add the parameter in musb_platform_save_context()
and
not in musb_save_context.
If so then where do you restore them? {As you said before calling this}
In order to support off-mode, we need the transceiver driver to wake-up
the controller.
I m working on a hook which would allow that.
I want to take advantage of your implementation for saving/restoring
musb context, but saving the platform data is not necessary in my case.
Then how about having a platform specific flag within
musb_platform_save/restorae_context() implementation which wouldn't
save/restore when you don't need them.
I got your point, but how would this flag being passed into
musb_save_context()?
As a new musb struct member?
Maybe it musb_platform_save/restore_context(), shouldn't be called from
musb_save/restore_context();
I think if the requirement is generic and suits for all other platforms
Using musb then we can add it.
Yes it should.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
