Russ Dill <russ.dill@xxxxxxxxx> writes: > On Mon, Jul 2, 2012 at 9:54 AM, Kevin Hilman <khilman@xxxxxx> wrote: >> Felipe, Keshava, >> >> Kevin Hilman <khilman@xxxxxx> writes: >> >>> Felipe Balbi <balbi@xxxxxx> writes: >>> >>> [...] >>> >>>> Keshava is reverting a fix for a HW errata. I can't accept it as it will >>>> cause regressions. Granted, regression by regression, there's no change, >>>> but I simply can't knowingly cause a regression to the driver just to >>>> have PM working. We need a real fix for this issue. >>> >>> Sure, as long as there is a fix in this -rc cycle. >>> >>> This driver intoduced changes in v3.5 that break PM for the whole SoC >>> (by preventing CORE retention.) These changes were clearly not tested >>> with PM. >>> >>> If you cannot fix this during the -rc cycle, then you need to revert the >>> driver PM changes that broke PM for the *whole* SoC. >> >> What's the status of this regression? >> >> This is still broken in v3.5-rc and is preventing CORE retention for the >> *whole* SoC. >> >> Please fix this, either with a proper fix, or a revert for 3.5-rc. > > Were you able to merge my patches that at least fix the oops on boot > and get EHCI working again on omap-3xxx? I didn't try your patches specifically, but those are not the problems I'm most worried about. I'm mostly worried about the fact that when EHCI is enabled (and working), it prevents the CORE powerdomain from hitting retention in idle, and thus prevents the whole chip from hitting retention in idle. I'm also worried that the owners of this code are running out of time to fix these several serious regresions for v3.5. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
