On 11/01/2012 02:08 PM, Dmitry Osipenko wrote: > On 01.11.2012 21:23, Stephen Warren wrote: >> I'm curious how; in what environment. As far as I know, the Tegra >> support in the mainline kernel doesn't actually support suspend/resume. >> I assume you cherry-picked this pinctrl driver into some other kernel, >> and tested this patch there? > > I added support for suspend/resume since 3.5-rc1, when actually started > updating kernel to mainline. The only differences from mainline 3.7 kernel now > are: custom clk framework from downstream's kernel with some modifications, > dvfs support, video, wifi and other specific drivers for my tablet. I will > continue posting patches in order to support suspending in mainline kernel. > Also will try to implement dvfs with common clk framework... have some thoughts > how better realise it. OK, it sounds like you'll make some very useful contributions. Thanks in advance. >> The one major different between this patch and the downstream patch I >> reviewed is how suspend/resume is triggered. This uses suspend_noirq, >> whereas the downstream patch registers the callbacks using >> register_syscore_ops(). Apparently the latter is required (at least in >> our downstream kernel) in order to ensure that pinctrl gets suspended >> after all other drivers. >> >> I Cc'd Pritesh to comment on this. >> >> Still, perhaps device probe ordering should ensure this upstream so >> using register_syscore_ops() might not be necessary, although that >> relies on drivers probing in the correct order, which they may not >> without explicitly pinctrl_get() calls... back to that same problem again! > > I know about that difference. My first realisation used syscore_ops, but then > I thought that possibly may be more than one pinctrl device that uses tegra > driver and decided to use _noirq pm ops. From your msg I assume that we can > have only one device Yes, there certainly is only one pinmux device on Tegra. I agree it's a little icky to have to use global variables for syscore_ops, but I don't think it will actually cause any practical issue. > and besides current realisation needs some changes to > support more than one device. So should I send V2 or my patch will be useless > because Pritesh already realised it? I'd suggest that Pritesh posts his patch too, and you can both look at each-other's work and come up with a final solution. By the way, your mailer created a rather odd header: > In-Reply-To: <5092B007.7050609@xxxxxxxxxxxxx> That makes sense, but: > Reply-To: 5092B007.7050609@xxxxxxxxxxxxx That looks like a botched In-Reply-To header. That text certainly isn't a valid email address, but rather a message ID. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
