| Message ID | 1469814151-2571-1-git-send-email-andreas@kemnade.info (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Andreas Kemnade <andreas@kemnade.info> [160729 11:14]: > The code assumes that omap2430_musb_enable() and > omap2430_musb_disable() is called in a balanced way. The > That fact is broken by the fact that musb_init_controller() calls > musb_platform_disable() to switch from unknown state to off state. OK, some spelling issues with the above paragraph though :) > That means that phy_power_off() is called first so that > phy->power_count gets -1 and the phy is not enabled on phy_power_on(). > In the probably common case of using the phy_twl4030, that > prevents also charging the battery and so makes further > kernel debugging hard. Is this with v4.7 kernel? Also, care to describe how you hit this and on which hardware? Just wondering.. > The patch prevents phy_power_off() from being called when > it is already off. OK Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2 Aug 2016 03:33:34 -0700 Tony Lindgren <tony@atomide.com> wrote: > * Andreas Kemnade <andreas@kemnade.info> [160729 11:14]: > > The code assumes that omap2430_musb_enable() and > > omap2430_musb_disable() is called in a balanced way. The > > That fact is broken by the fact that musb_init_controller() calls > > musb_platform_disable() to switch from unknown state to off state. > > OK, some spelling issues with the above paragraph though :) > > > That means that phy_power_off() is called first so that > > phy->power_count gets -1 and the phy is not enabled on > > phy_power_on(). In the probably common case of using the > > phy_twl4030, that prevents also charging the battery and so makes > > further kernel debugging hard. > > Is this with v4.7 kernel? Also, care to describe how you hit this > and on which hardware? Just wondering.. I got this error on the Openphoenux GTA04 phone. It has a DM3730 SoC and a TPS65950 companion. Severe charging problems were already observed with the 4.4rc1. I do not know if that already was exactly *this* problem. I have debugged and patched the v4.7 kernel. How I hit the problem: Just boot an that device and try to charge via usb. Should I resubmit the patch with an extended commit message? Regards, Andreas Kemnade
* Andreas Kemnade <andreas@kemnade.info> [160802 08:14]: > On Tue, 2 Aug 2016 03:33:34 -0700 > Tony Lindgren <tony@atomide.com> wrote: > > > * Andreas Kemnade <andreas@kemnade.info> [160729 11:14]: > > > The code assumes that omap2430_musb_enable() and > > > omap2430_musb_disable() is called in a balanced way. The > > > That fact is broken by the fact that musb_init_controller() calls > > > musb_platform_disable() to switch from unknown state to off state. > > > > OK, some spelling issues with the above paragraph though :) > > > > > That means that phy_power_off() is called first so that > > > phy->power_count gets -1 and the phy is not enabled on > > > phy_power_on(). In the probably common case of using the > > > phy_twl4030, that prevents also charging the battery and so makes > > > further kernel debugging hard. > > > > Is this with v4.7 kernel? Also, care to describe how you hit this > > and on which hardware? Just wondering.. > > I got this error on the Openphoenux GTA04 phone. It has a DM3730 > SoC and a TPS65950 companion. Severe charging problems were already > observed with the 4.4rc1. I do not know if that already was exactly > *this* problem. I have debugged and patched the v4.7 kernel. OK thanks for the info. > How I hit the problem: Just boot an that device and try to charge > via usb. OK so it's the twl4030 charger then I guess. > Should I resubmit the patch with an extended commit message? Well yeah it might be worth describing that it's the twl4030 charger that otherwise does not work properly. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2 Aug 2016 23:30:16 -0700 Tony Lindgren <tony@atomide.com> wrote: > * Andreas Kemnade <andreas@kemnade.info> [160802 08:14]: > > On Tue, 2 Aug 2016 03:33:34 -0700 > > Tony Lindgren <tony@atomide.com> wrote: > > > > > * Andreas Kemnade <andreas@kemnade.info> [160729 11:14]: > > > > The code assumes that omap2430_musb_enable() and > > > > omap2430_musb_disable() is called in a balanced way. The > > > > That fact is broken by the fact that musb_init_controller() > > > > calls musb_platform_disable() to switch from unknown state to > > > > off state. > > > > > > OK, some spelling issues with the above paragraph though :) > > > > > > > That means that phy_power_off() is called first so that > > > > phy->power_count gets -1 and the phy is not enabled on > > > > phy_power_on(). In the probably common case of using the > > > > phy_twl4030, that prevents also charging the battery and so > > > > makes further kernel debugging hard. > > > > > > Is this with v4.7 kernel? Also, care to describe how you hit this > > > and on which hardware? Just wondering.. > > > > I got this error on the Openphoenux GTA04 phone. It has a DM3730 > > SoC and a TPS65950 companion. Severe charging problems were already > > observed with the 4.4rc1. I do not know if that already was exactly > > *this* problem. I have debugged and patched the v4.7 kernel. > > OK thanks for the info. > > > How I hit the problem: Just boot an that device and try to charge > > via usb. > > OK so it's the twl4030 charger then I guess. > yes, besides from causing usb gadget problems, it has side effect towards the twl4030 charger. > > Should I resubmit the patch with an extended commit message? > > Well yeah it might be worth describing that it's the twl4030 > charger that otherwise does not work properly. > Ok, will resend a better commit message. Regards, Andreas Kemnade
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index aecb934..c7ae117 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -415,9 +415,10 @@ static void omap2430_musb_disable(struct musb *musb) struct device *dev = musb->controller; struct omap2430_glue *glue = dev_get_drvdata(dev->parent); - if (!WARN_ON(!musb->phy)) - phy_power_off(musb->phy); - + if (glue->enabled) { + if (!WARN_ON(!musb->phy)) + phy_power_off(musb->phy); + } if (glue->status != MUSB_UNKNOWN) omap_control_usb_set_mode(glue->control_otghs, USB_MODE_DISCONNECT);
The code assumes that omap2430_musb_enable() and omap2430_musb_disable() is called in a balanced way. The That fact is broken by the fact that musb_init_controller() calls musb_platform_disable() to switch from unknown state to off state. That means that phy_power_off() is called first so that phy->power_count gets -1 and the phy is not enabled on phy_power_on(). In the probably common case of using the phy_twl4030, that prevents also charging the battery and so makes further kernel debugging hard. The patch prevents phy_power_off() from being called when it is already off. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> --- drivers/usb/musb/omap2430.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)