Re: [PATCH v2] musb: am35x: fix compile error due to control apis
On Thu, Jan 27, 2011 at 07:31:23AM -0500, Ben Gamari wrote: On Thu, 27 Jan 2011 06:48:10 +0200, Felipe Balbi ba...@ti.com wrote: sorry, quite busy at the moment, but here's one answer. Check this commit: commit a9c037832e9624e240c5019d0e01e9352e8f638d ... Thanks for the reply! So I take it that omap's usb_musb_init takes care of all of the new *_board_data fields now and therefore no board changes are necessary? correct. -- 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 v2] musb: am35x: fix compile error due to control apis
On Thu, 27 Jan 2011 06:48:10 +0200, Felipe Balbi ba...@ti.com wrote: sorry, quite busy at the moment, but here's one answer. Check this commit: commit a9c037832e9624e240c5019d0e01e9352e8f638d ... Thanks for the reply! So I take it that omap's usb_musb_init takes care of all of the new *_board_data fields now and therefore no board changes are necessary? Thanks, - Ben -- 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 v2] musb: am35x: fix compile error due to control apis
Hi, On Mon, Jan 24, 2011 at 10:45:22AM -0500, Ben Gamari wrote: On Tue, 18 Jan 2011 14:15:13 -0500, Ben Gamari bgamari.f...@gmail.com wrote: On Mon, 6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta ajay.gu...@ti.com wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. What happened to the board changes for board-am3517evm? Ping. A response would be appreciated. sorry, quite busy at the moment, but here's one answer. Check this commit: commit a9c037832e9624e240c5019d0e01e9352e8f638d Author: Ajay Kumar Gupta ajay.gu...@ti.com Date: Tue Dec 7 18:57:45 2010 +0530 musb: am35x: fix compile error due to control apis commit 4814ced5116e3b73dc4f63eec84999739fc8ed11 (OMAP: control: move plat-omap/control.h to mach-omap2/control.h) moved plat/control.h to another location, preventing drivers from accessing it, so we need to pass function pointers from arch code to be able to talk to internal PHY on AM35x. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com $ git describe a9c037832e9624e240c5019d0e01e9352e8f638d v2.6.37-rc1-95-ga9c0378 -- 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 v2] musb: am35x: fix compile error due to control apis
On Tue, 18 Jan 2011 14:15:13 -0500, Ben Gamari bgamari.f...@gmail.com wrote: On Mon, 6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta ajay.gu...@ti.com wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. What happened to the board changes for board-am3517evm? Ping. A response would be appreciated. Cheers, - Ben -- 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 v2] musb: am35x: fix compile error due to control apis
On Mon, 6 Dec 2010 13:43:31 +0530, Ajay Kumar Gupta ajay.gu...@ti.com wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. What happened to the board changes for board-am3517evm? This patch _really_ needs to include the necessary changes to a board. So far this change has already been handled very sloppily (i.e. 2.6.37 was released with am35x support that doesn't even build, much less function). If we continue with this patch as proposed, not only will board maintainers have absolutely no idea why USB isn't working in 2.6.38, but once they are lucky enough to stumble upon the reason they will have no idea how to fix the problem, having no template to work from. As I understand it, this patch has already been merged into mmotm. Can we please get a new version of this patch or even just a patch on top of this modifying one of the boards to accomodate this change so that the rest of us have some idea how to proceed? Thanks, - Ben -- 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 v2] musb: am35x: fix compile error due to control apis
Hello. On 06-12-2010 20:54, Tony Lindgren wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. I'm not fond of the whole approach. I'm not sure why accesses to the control registers are such a no-no, taking into account that one needs to access such regisyter to clear the interrupt... Because drivers should arch independent and any tinkering of the platform level registers will lead into pains later on that I end up having to deal with. To me it seem you just init to separate out the transceiver, right? We also have to install a hook to clear the MUSB level interrupt via the control register -- that's a thing that makes me dubious about not allowing drivers to access the control registers. Tony WBR, Sergei -- 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
[PATCH v2] musb: am35x: fix compile error due to control apis
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Patch created against recent Linus's tree.
Changes from v1:
- Moved musb reset part also to usb-musb.c so that all the
boards can use it.
- Corrected return value of set_mode() in case of null function
- Used pr_info/err instead of printk.
arch/arm/mach-omap2/usb-musb.c| 97
arch/arm/plat-omap/include/plat/usb.h |4 +
drivers/usb/musb/am35x.c | 134 +++-
3 files changed, 147 insertions(+), 88 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7260558..8c1d121 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -30,9 +30,102 @@
#include mach/irqs.h
#include mach/am35xx.h
#include plat/usb.h
+#include control.h
#ifdef CONFIG_USB_MUSB_SOC
+static void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+static void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+* Start the on-chip PHY and its PLL.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ pr_info(KERN_INFO Waiting for PHY clock good...\n);
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ pr_err(KERN_ERR musb PHY clock good timed
out\n);
+ break;
+ }
+ }
+ } else {
+ /*
+* Power down the on-chip PHY.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+static void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 = ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ pr_info(KERN_INFO Unsupported mode %u\n, musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
+
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */
.flags = IORESOURCE_MEM,
@@ -93,6 +186,10 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
} else if (cpu_is_omap3517() || cpu_is_omap3505()) {
musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
musb_resources[1].start = INT_35XX_USBOTG_IRQ;
+ board_data-set_phy_power = am35x_musb_phy_power;
+ board_data-clear_irq = am35x_musb_clear_irq;
+ board_data-set_mode = am35x_musb_set_mode;
+ board_data-reset = am35x_musb_reset;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 59c7fe7..7c0be5a 100644
---
Re: [PATCH v2] musb: am35x: fix compile error due to control apis
Hello.
On 06-12-2010 11:13, Ajay Kumar Gupta wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
I'm not fond of the whole approach. I'm not sure why accesses to the
control registers are such a no-no, taking into account that one needs to
access such regisyter to clear the interrupt...
Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7260558..8c1d121 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -30,9 +30,102 @@
#includemach/irqs.h
#includemach/am35xx.h
#includeplat/usb.h
+#include control.h
#ifdef CONFIG_USB_MUSB_SOC
+static void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval= ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
Why read it and ignore the result?
WBR, Sergei
--
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 v2] musb: am35x: fix compile error due to control apis
Hi, As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. I'm not fond of the whole approach. I'm not sure why accesses to the control registers are such a no-no, taking into account that one needs to access such regisyter to clear the interrupt... I think Tony is the right person to answer this :) Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com [...] diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb- musb.c [...] + regval= ~AM35XX_USBOTGSS_SW_RST; + omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET); + + regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); Why read it and ignore the result? This is due to recommendation for OMAPs as discussed at below Link, http://markmail.org/message/s3lp7xlyq7zxnjtc#query:+page:1+mid:kfia4ld4xgzek6kq+state:results Thanks, Ajay WBR, Sergei -- 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 v2] musb: am35x: fix compile error due to control apis
Hello. Gupta, Ajay Kumar wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. I'm not fond of the whole approach. I'm not sure why accesses to the control registers are such a no-no, taking into account that one needs to access such regisyter to clear the interrupt... I think Tony is the right person to answer this :) Yeah, I thought he must be reading linux-omap... Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com [...] diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c [...] + regval= ~AM35XX_USBOTGSS_SW_RST; + omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET); + + regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); Why read it and ignore the result? This is due to recommendation for OMAPs as discussed at below Link, http://markmail.org/message/s3lp7xlyq7zxnjtc#query:+page:1+mid:kfia4ld4xgzek6kq+state:results There is recommendation to read back the interrupt status register, which this register isn't. Anyway, a comment wouldn't hurt... Thanks, Ajay WBR, Sergei -- 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 v2] musb: am35x: fix compile error due to control apis
* Sergei Shtylyov sshtyl...@mvista.com [101206 09:04]: Hello. Gupta, Ajay Kumar wrote: As the control.h have been moved to new location and it's uses are not allowed to drivers directly so moving the phy control, interrupt clear and reset functionality to board files. I'm not fond of the whole approach. I'm not sure why accesses to the control registers are such a no-no, taking into account that one needs to access such regisyter to clear the interrupt... Because drivers should arch independent and any tinkering of the platform level registers will lead into pains later on that I end up having to deal with. To me it seem you just init to separate out the transceiver, right? I think Tony is the right person to answer this :) Yeah, I thought he must be reading linux-omap... I do yeah.. Might take a while to respond sometimes though :) Tony -- 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
