| Message ID | 1252357252-29484-1-git-send-email-miguel.aguilar@ridgerun.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
2 comments 1) You have missed the corresponding board specific hacks in phy_off which leads to 2) Kevin has already asked for board specific stuff to be handled differently in response to the DM646x patch. Thanks, Sandeep > -----Original Message----- > From: davinci-linux-open-source-bounces@linux.davincidsp.com > [mailto:davinci-linux-open-source-bounces@linux.davincidsp.com] On Behalf > Of miguel.aguilar@ridgerun.com > Sent: Monday, September 07, 2009 5:01 PM > To: davinci-linux-open-source@linux.davincidsp.com; Narnakaje, Snehaprabha > Cc: santiago.nunez@ridgerun.com; todd.fischer@ridgerun.com; > clark.becker@ridgerun.com; Miguel Aguilar > Subject: [PATCH 1/2] USB: DaVinci: Add DM365 support to DaVinci USB driver > > From: Miguel Aguilar <miguel.aguilar@ridgerun.com> > > Modifies the DaVinci USB driver in order to support the DM365 platform. > > This patch needs the patch called "DaVinci: DM365: Correct USB source > clock" > by Sandeep Paulraj to work properly because it fixes the USB clock source > for DM365. > > Signed-off-by: Miguel Aguilar <miguel.aguilar@ridgerun.com> > --- > drivers/usb/musb/Kconfig | 4 ++-- > drivers/usb/musb/davinci.c | 20 ++++++++++++++++---- > drivers/usb/musb/davinci.h | 1 + > 3 files changed, 19 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index 803adcb..9878a64 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -23,7 +23,7 @@ config USB_MUSB_HDRC > or the USB host role, or both. > > Texas Instruments familiies using this IP include DaVinci > - (35x, 644x ...), OMAP 243x, OMAP 3, and TUSB 6010. > + (35x, 36x, 644x ...), OMAP 243x, OMAP 3, and TUSB 6010. > > Analog Devices parts using this IP include Blackfin BF54x, > BF525 and BF527. > @@ -42,7 +42,7 @@ config USB_MUSB_SOC > default y if (BF54x && !BF544) > default y if (BF52x && !BF522 && !BF523) > > -comment "DaVinci 35x and 644x USB support" > +comment "DaVinci 35x, 36x, 644x USB support" > depends on USB_MUSB_HDRC && ARCH_DAVINCI > > comment "OMAP 243x high speed USB support" > diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c > index e16ff60..f5374f9 100644 > --- a/drivers/usb/musb/davinci.c > +++ b/drivers/usb/musb/davinci.c > @@ -62,10 +62,19 @@ static inline void phy_on(void) > { > u32 phy_ctrl = __raw_readl(USB_PHY_CTRL); > > - /* power everything up; start the on-chip PHY and its PLL */ > - phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN); > - phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON; > - __raw_writel(phy_ctrl, USB_PHY_CTRL); > + if (cpu_is_davinci_dm365()) > + /* > + * DM365 PHYCLKFREQ field [15:12] is set to 2 > + * to get clock from 24MHz crystal > + */ > + __raw_writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN | > + USBPHY_CLKFREQ_24MHZ, USB_PHY_CTRL); > + else { > + /* power everything up; start the on-chip PHY and its PLL */ > + phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | > USBPHY_PHYPDWN); > + phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | > USBPHY_PHYPLLON; > + __raw_writel(phy_ctrl, USB_PHY_CTRL); > + } > > /* wait for PLL to lock before proceeding */ > while ((__raw_readl(USB_PHY_CTRL) & USBPHY_PHYCLKGD) == 0) > @@ -189,6 +198,8 @@ static void davinci_source_power(struct musb *musb, > int is_on, int immediate) > if (immediate) > vbus_state = is_on; > #endif > + if (cpu_is_davinci_dm365()) > + gpio_set_value(33, is_on); > } > > static void davinci_set_vbus(struct musb *musb, int is_on) > @@ -427,6 +438,7 @@ int __init musb_platform_init(struct musb *musb) > } > __raw_writel(deepsleep, DM355_DEEPSLEEP); > } > + > > /* reset the controller */ > musb_writel(tibase, DAVINCI_USB_CTRL_REG, 0x1); > diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h > index 046c844..ceabb36 100644 > --- a/drivers/usb/musb/davinci.h > +++ b/drivers/usb/musb/davinci.h > @@ -16,6 +16,7 @@ > > /* Integrated highspeed/otg PHY */ > #define USBPHY_CTL_PADDR (DAVINCI_SYSTEM_MODULE_BASE + 0x34) > +#define USBPHY_CLKFREQ_24MHZ BIT(13) > #define USBPHY_DATAPOL BIT(11) /* (dm355) switch D+/D- */ > #define USBPHY_PHYCLKGD BIT(8) > #define USBPHY_SESNDEN BIT(7) /* v(sess_end) comparator */ > -- > 1.6.0.4 > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Hello. Miguel Aguilar wrote: >>> From: Miguel Aguilar <miguel.aguilar@ridgerun.com> >>> >>> Modifies the DaVinci USB driver in order to support the DM365 platform. >>> >>> This patch needs the patch called "DaVinci: DM365: Correct USB source >>> clock" >>> by Sandeep Paulraj to work properly because it fixes the USB clock >>> source >>> for DM365. >>> Signed-off-by: Miguel Aguilar <miguel.aguilar@ridgerun.com> [...] >>> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c >>> index e16ff60..f5374f9 100644 >>> --- a/drivers/usb/musb/davinci.c >>> +++ b/drivers/usb/musb/davinci.c >>> @@ -62,10 +62,19 @@ static inline void phy_on(void) >>> { >>> u32 phy_ctrl = __raw_readl(USB_PHY_CTRL); >>> >>> - /* power everything up; start the on-chip PHY and its PLL */ >>> - phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN); >>> - phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON; >>> - __raw_writel(phy_ctrl, USB_PHY_CTRL); >>> + if (cpu_is_davinci_dm365()) >>> + /* >>> + * DM365 PHYCLKFREQ field [15:12] is set to 2 >>> + * to get clock from 24MHz crystal >>> + */ >>> + __raw_writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN | >>> + USBPHY_CLKFREQ_24MHZ, USB_PHY_CTRL); >> I suspect that the USB clock selection is board specific, not SoC >> specific, hence it should bein board-dm366-evm.c. > [MA] Does the other Davinci platforms handle the USB clock selection as > board specific? Other DaVincis don't have clock selection. DA830 EVM handles the clock selection in the board code because the clock can be internal or external, presumably depending on the board. On DM365, as I can see, the clock source is also selectable... >>> @@ -189,6 +198,8 @@ static void davinci_source_power(struct musb >>> *musb, int is_on, int immediate) >>> if (immediate) >>> vbus_state = is_on; >>> #endif >>> + if (cpu_is_davinci_dm365()) >>> + gpio_set_value(33, is_on); >> This is surely *board specific* code, should e done thru the >> callback in the platform data as pointed out by Kevin already. > [MA] I already took a look into DM646x USB patch thread and the > discussion about the board specific issue, but Is there any agreement > about the way to handle do this? Like use a usb_vbus_control in the > board file. > There are still many board specific stuff inside USB DaVinci driver so > that would be better if we will be able to follow a clear way to do > this, and define what belongs to driver, SoC and board domains, so Is > there any current work in this way to move the board specific stuff from > driver to board file in a standard way? Hopefully so, by Swaminathan. WBR, Sergei
Miguel Aguilar <miguel.aguilar@ridgerun.com> writes: > [MA] I already took a look into DM646x USB patch thread and the > discussion about the board specific issue, but Is there any agreement > about the way to handle do this? Like use a usb_vbus_control in the > board file. > > There are still many board specific stuff inside USB DaVinci driver so > that would be better if we will be able to follow a clear way to do > this, and define what belongs to driver, SoC and board domains, so Is > there any current work in this way to move the board specific stuff > from driver to board file in a standard way? I was hoping for a proposal (ideally in the form of a patch) from Swami after the review of his earlier patch. Since nothing has been forthcoming from from him, any others are welcome. Kevin
Kevin Hilman <khilman@deeprootsystems.com> writes: > Miguel Aguilar <miguel.aguilar@ridgerun.com> writes: > >> [MA] I already took a look into DM646x USB patch thread and the >> discussion about the board specific issue, but Is there any agreement >> about the way to handle do this? Like use a usb_vbus_control in the >> board file. >> >> There are still many board specific stuff inside USB DaVinci driver so >> that would be better if we will be able to follow a clear way to do >> this, and define what belongs to driver, SoC and board domains, so Is >> there any current work in this way to move the board specific stuff >> from driver to board file in a standard way? > > > I was hoping for a proposal (ideally in the form of a patch) from > Swami after the review of his earlier patch. > > Since nothing has been forthcoming from from him, any others are > welcome. Ooops, responded to this before I saw Swami is working on this. Please feel free to send any ideas/suggestions/prefernces to Swami, and Cc list. Kevin
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 803adcb..9878a64 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -23,7 +23,7 @@ config USB_MUSB_HDRC or the USB host role, or both. Texas Instruments familiies using this IP include DaVinci - (35x, 644x ...), OMAP 243x, OMAP 3, and TUSB 6010. + (35x, 36x, 644x ...), OMAP 243x, OMAP 3, and TUSB 6010. Analog Devices parts using this IP include Blackfin BF54x, BF525 and BF527. @@ -42,7 +42,7 @@ config USB_MUSB_SOC default y if (BF54x && !BF544) default y if (BF52x && !BF522 && !BF523) -comment "DaVinci 35x and 644x USB support" +comment "DaVinci 35x, 36x, 644x USB support" depends on USB_MUSB_HDRC && ARCH_DAVINCI comment "OMAP 243x high speed USB support" diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index e16ff60..f5374f9 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -62,10 +62,19 @@ static inline void phy_on(void) { u32 phy_ctrl = __raw_readl(USB_PHY_CTRL); - /* power everything up; start the on-chip PHY and its PLL */ - phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN); - phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON; - __raw_writel(phy_ctrl, USB_PHY_CTRL); + if (cpu_is_davinci_dm365()) + /* + * DM365 PHYCLKFREQ field [15:12] is set to 2 + * to get clock from 24MHz crystal + */ + __raw_writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN | + USBPHY_CLKFREQ_24MHZ, USB_PHY_CTRL); + else { + /* power everything up; start the on-chip PHY and its PLL */ + phy_ctrl &= ~(USBPHY_OSCPDWN | USBPHY_OTGPDWN | USBPHY_PHYPDWN); + phy_ctrl |= USBPHY_SESNDEN | USBPHY_VBDTCTEN | USBPHY_PHYPLLON; + __raw_writel(phy_ctrl, USB_PHY_CTRL); + } /* wait for PLL to lock before proceeding */ while ((__raw_readl(USB_PHY_CTRL) & USBPHY_PHYCLKGD) == 0) @@ -189,6 +198,8 @@ static void davinci_source_power(struct musb *musb, int is_on, int immediate) if (immediate) vbus_state = is_on; #endif + if (cpu_is_davinci_dm365()) + gpio_set_value(33, is_on); } static void davinci_set_vbus(struct musb *musb, int is_on) @@ -427,6 +438,7 @@ int __init musb_platform_init(struct musb *musb) } __raw_writel(deepsleep, DM355_DEEPSLEEP); } + /* reset the controller */ musb_writel(tibase, DAVINCI_USB_CTRL_REG, 0x1); diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h index 046c844..ceabb36 100644 --- a/drivers/usb/musb/davinci.h +++ b/drivers/usb/musb/davinci.h @@ -16,6 +16,7 @@ /* Integrated highspeed/otg PHY */ #define USBPHY_CTL_PADDR (DAVINCI_SYSTEM_MODULE_BASE + 0x34) +#define USBPHY_CLKFREQ_24MHZ BIT(13) #define USBPHY_DATAPOL BIT(11) /* (dm355) switch D+/D- */ #define USBPHY_PHYCLKGD BIT(8) #define USBPHY_SESNDEN BIT(7) /* v(sess_end) comparator */