Re: [PATCH] USB: otg: twl4030: fix phy initialization
2010/9/5 Felipe Balbi m...@felipebalbi.com: Hi, On Sat, 4 Sep 2010 23:36:39 +0800, Ming Lei tom.leim...@gmail.com wrote: Considered bit PHYPWD of PHY_PWR_CTRL is zero at default, say, OTG phy is not put into power down after system poweron, so 2.6.36-rc3 will make musb device mode broken if bootloader doesn't touch PHYPWD of PHY_PWR_CTRL. Could you ack the patch if no further objections or give other suggestions? I don't see why that patch should cause problems with device mode. Fact is that transceiver is only asleep when PHYPWD bit is true and without setting that flag correctly we were leaving phy's LDOs powered on for nothing when we were booting without a USB cable connected. If you don't explain exactly what is the problem you see (besides the WARN) it's to help any further, specially now Oh, I already explain the cause in detail in this thread. http://marc.info/?l=linux-kernelm=128347462130590w=2 No problem, do it again, if you have any questions about the explanation please feel free to let me know. issue #1:(musb device not work with cable connected with PC) -twl-asleep is set as zero in .probe since bootloader has not powerdown phy -EVENT_VBUS returned from twl4030_usb_linkstat since usb cable is connected with PC -twl4030_phy_resume is called but does nothing since twl-asleep is zero -the following are not called to initialize otg phy: twl4030_phy_power / twl4030_i2c_access / twl4030_usb_set_mode -so musb device mode does not work issue #2:(regulator 'unbalanced disables' warnings ) -twl-asleep is set as zero in .probe since bootloader has not powerdown phy -EVENT_NONE returned from twl4030_usb_linkstat since no usb cable is connected with board -twl4030_phy_suspend is called -twl4030_phy_power is called since twl-asleep is zero -regulator_disable is called for power down case -so cause the kernel warning since no regulator_enable is called before that I'm 100% without HW to test against. I'm also in a big hurry packing a buch of stuff for moving to another appartment, so if there isn't enough information, I can't be of any help. Sorry for disturbing you, hope you have a happy moving, :-) Still, I would NACK you patch because I don't think it's approaching the correct problem. If you only see that WARN, you could start by chaging the code so that: if (!regulator_is_enabled(twl-usb3v1) regulator_enable(twl-usb3v1); Yes, it is another fix for the issue #2, just different way for the same problem, right? and similarly for the regulator_disable() call, then check whether there are any other problems. If there are, we will take it from there. All in all, I doubt that patch would cause break anything since it's just checking the initial state from the transceiver itself to set a flag in the driver structure, that's all. No, .asleep flag is set according to the current link state, instead of the initial state of transceiver. I don't think the patch will cause break anything. If you think it will, please describe the break in detail. thanks, -- Lei Ming -- 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
Re: [PATCH] USB: otg: twl4030: fix phy initialization
Hi, On Sun, 5 Sep 2010 14:42:51 +0800, Ming Lei tom.leim...@gmail.com wrote: issue #1:(musb device not work with cable connected with PC) -twl-asleep is set as zero in .probe since bootloader has not powerdown phy -EVENT_VBUS returned from twl4030_usb_linkstat since usb cable is connected with PC -twl4030_phy_resume is called but does nothing since twl-asleep is zero -the following are not called to initialize otg phy: twl4030_phy_power / twl4030_i2c_access / twl4030_usb_set_mode -so musb device mode does not work ok, I see. So what you could do is enable regulators on probe based on PHYPWR bit. Sorry for disturbing you, hope you have a happy moving, :-) np, tks :-) No, .asleep flag is set according to the current link state, instead of the initial state of transceiver. I don't think the patch will cause break anything. If you think it will, please describe the break in detail. if we revert that patch, you'll see that usb3v1 ldos are left on if we never plug/unplug usb cable. AFAIR, the reset state of those LDOs is ON, so that's why we need that patch. I'll try to work on it monday judging I'll have laptop and HW available by then. -- balbi -- 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
Re: [PATCH] USB: otg: twl4030: fix phy initialization
2010/9/5 Felipe Balbi m...@felipebalbi.com: Hi, On Sun, 5 Sep 2010 14:42:51 +0800, Ming Lei tom.leim...@gmail.com wrote: issue #1:(musb device not work with cable connected with PC) -twl-asleep is set as zero in .probe since bootloader has not powerdown phy -EVENT_VBUS returned from twl4030_usb_linkstat since usb cable is connected with PC -twl4030_phy_resume is called but does nothing since twl-asleep is zero -the following are not called to initialize otg phy: twl4030_phy_power / twl4030_i2c_access / twl4030_usb_set_mode -so musb device mode does not work ok, I see. So what you could do is enable regulators on probe based on PHYPWR bit. This patch will enable regulators on probe based on current link state returned from twl4030_usb_linkstat instead of PHYPWR bit. If vbus or ID event detected, call __twl4030_phy_resume to enable regulators/ phy power/set mode to make phy into work state, or else call __twl4030_phy_power(0) to power down otg phy. See twl4030_usb_phy_init introduced in the patch. No, .asleep flag is set according to the current link state, instead of the initial state of transceiver. I don't think the patch will cause break anything. If you think it will, please describe the break in detail. if we revert that patch, you'll see that usb3v1 ldos are left on You commit before does fix one problem, which may keep phy in power on even no cable connected, so I do not request a simple revert, :-). if we never plug/unplug usb cable. AFAIR, the reset state of those LDOs is ON, so that's why we need that patch. From Table 5-373 of TPS65950 manual[1], usb3v1 ldo is in sleep state after reset. But it is put into active state in twl4030_usb_ldo_init now, seems activating it too early. I have verified it OK on beagle board to remove the early activating of usb3v1 in twl4030_usb_ldo_init. I'll merge it into the v2 of the patch and post it for your review. I'll try to work on it monday judging I'll have laptop and HW available by then. Very good, thanks your work! [1], TPS65950 Technical Reference Manual, http://www.ti.com/litv/pdf/swcu050e thanks, -- Lei Ming -- 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
RE: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB
-Original Message- From: Taneja, Archit Sent: Saturday, September 04, 2010 2:12 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB This lets omap_vout driver build and run without VRFB. It works along the lines of the following patch series: OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB https://patchwork.kernel.org/patch/105371/ A variable rotation_type is introduced in omapvideo_info like the way in omapfb_info to make both vrfb and non vrfb rotation possible. [Hiremath, Vaibhav] Archit, Currently omap_vout driver only supports VRFB based rotation, it doesn't support SDMA based rotation (unlike OMAPFB) and neither you patch adds it. Thanks, Vaibhav Since VRFB is tightly coupled with the omap_vout driver, a handful of vrfb-specific functions have been defined and placed in omap_vout_vrfb.c This series applies along with the previously submitted patch: https://patchwork.kernel.org/patch/146401/ Archit Taneja (2): V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram rotation drivers/media/video/omap/Kconfig |1 - drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 502 ++-- - drivers/media/video/omap/omap_vout_vrfb.c | 417 drivers/media/video/omap/omap_vout_vrfb.h | 40 +++ drivers/media/video/omap/omap_voutdef.h | 26 ++ 6 files changed, 582 insertions(+), 405 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h -- 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
Cpufreq for s3c2440 FriendlyArm
Hi all, Did anyone try the cpufreq on the mini2440 ? and did anyone get it working on the board ? Each time I do the configuration in the kernel I found nothing on the board ,however after the compilation I found the cpufreq.o pll.o but no file concerning that on the board . Any help will be appreciated. Best Regards, -- 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
Re: Cpufreq for s3c2440 FriendlyArm
Dne Ne 5. září 2010 22:30:00 tarek attia napsal(a): Hi all, Did anyone try the cpufreq on the mini2440 ? and did anyone get it working on the board ? Each time I do the configuration in the kernel I found nothing on the board ,however after the compilation I found the cpufreq.o pll.o but no file concerning that on the board . Any help will be appreciated. I believe you have the wrong mailing list here. LAK CCed. Best Regards, -- 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 -- 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
RE: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB
Hi, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Saturday, September 04, 2010 2:12 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB This lets omap_vout driver build and run without VRFB. It works along the lines of the following patch series: OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB https://patchwork.kernel.org/patch/105371/ A variable rotation_type is introduced in omapvideo_info like the way in omapfb_info to make both vrfb and non vrfb rotation possible. [Hiremath, Vaibhav] Archit, Currently omap_vout driver only supports VRFB based rotation, it doesn't support SDMA based rotation (unlike OMAPFB) and neither you patch adds it. [Archit]The above description in the git commit is a mistake from my end. The main purpose of the patch is to get omap_vout running without VRFB. I am not sure if we need to enable SDMA rotation for V4L2 though, we would always have vrfb and tiler on omap3 and omap4 respectively. How do you think things should be handled in the non vrfb case? Should we try to get rotation running or should the driver return an error if userspace tries to enable rotation in a non-vrfb mode? Thanks, Archit Since VRFB is tightly coupled with the omap_vout driver, a handful of vrfb-specific functions have been defined and placed in omap_vout_vrfb.c This series applies along with the previously submitted patch: https://patchwork.kernel.org/patch/146401/ Archit Taneja (2): V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram rotation drivers/media/video/omap/Kconfig |1 - drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 502 ++-- - drivers/media/video/omap/omap_vout_vrfb.c | 417 drivers/media/video/omap/omap_vout_vrfb.h | 40 +++ drivers/media/video/omap/omap_voutdef.h | 26 ++ 6 files changed, 582 insertions(+), 405 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h-- 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
