* [PATCH 1/3] musb: save dynfifo in musb struct
@ 2009-12-14 13:39 Ajay Kumar Gupta
[not found] ` <1260797982-28880-1-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org>
0 siblings, 1 reply; 26+ messages in thread
From: Ajay Kumar Gupta @ 2009-12-14 13:39 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
felipe.balbi-xNZwKgViW5gAvxtiuMwx3w,
david-b-yBeKhBN/0LDR7s880joybQ, Ajay Kumar Gupta
Save dynamic FIFO read only information for later uses such as, during
musb_save/restore_context functions.
Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org>
---
drivers/usb/musb/musb_core.c | 4 +++-
drivers/usb/musb/musb_core.h | 1 +
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 49f2346..d4adbbf 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1328,8 +1328,10 @@ static int __init musb_core_init(u16 musb_type, struct musb *musb)
reg = musb_read_configdata(mbase);
strcpy(aInfo, (reg & MUSB_CONFIGDATA_UTMIDW) ? "UTMI-16" : "UTMI-8");
- if (reg & MUSB_CONFIGDATA_DYNFIFO)
+ if (reg & MUSB_CONFIGDATA_DYNFIFO) {
strcat(aInfo, ", dyn FIFOs");
+ musb->dyn_fifo = true;
+ }
if (reg & MUSB_CONFIGDATA_MPRXE) {
strcat(aInfo, ", bulk combine");
#ifdef C_MP_RX
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 03d5090..969287c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -411,6 +411,7 @@ struct musb {
unsigned hb_iso_rx:1; /* high bandwidth iso rx? */
unsigned hb_iso_tx:1; /* high bandwidth iso tx? */
+ unsigned dyn_fifo:1; /* dynamic FIFO supported? */
#ifdef C_MP_TX
unsigned bulk_split:1;
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 26+ messages in thread[parent not found: <1260797982-28880-1-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org>]
* [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <1260797982-28880-1-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org> @ 2009-12-14 13:39 ` Ajay Kumar Gupta 2009-12-14 13:39 ` [PATCH 3/3] musb: Add 'extvbus' in musb_hdrc_platform_data Ajay Kumar Gupta [not found] ` <1260797982-28880-2-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org> 2009-12-14 16:24 ` [PATCH 1/3] musb: save dynfifo in musb struct Felipe Balbi 1 sibling, 2 replies; 26+ messages in thread From: Ajay Kumar Gupta @ 2009-12-14 13:39 UTC (permalink / raw) To: linux-usb-u79uwXL29TY76Z2rM5mHXA Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA, felipe.balbi-xNZwKgViW5gAvxtiuMwx3w, david-b-yBeKhBN/0LDR7s880joybQ, Ajay Kumar Gupta, Anand Gadiyar Adding support for MUSB register save and restore during system suspend and resume. Changes: - Added musb_save/restore_context() functions - Added platform specific musb_platform_save/restore_context() to handle platform specific jobs. - Maintaining BlackFin compatibility by adding read/write functions for registers which are not available in BlackFin Tested system suspend and resume on OMAP3EVM board. Signed-off-by: Anand Gadiyar <gadiyar-l0cyMroinI0@public.gmane.org> Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org> --- Changes from v2: - Saving/Restoring host only registers within is_host_enabled() check. - Saving/Restoring Tx/Rx FIFOSZ/FIFOADDR within musb->dynfifo check. drivers/usb/musb/musb_core.c | 157 +++++++++++++++++++++++++++++++++++++++++- drivers/usb/musb/musb_core.h | 39 ++++++++++ drivers/usb/musb/musb_regs.h | 90 ++++++++++++++++++++++++ drivers/usb/musb/omap2430.c | 16 ++++ 4 files changed, 300 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index d4adbbf..cd4462b 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2167,11 +2167,154 @@ static int __devexit musb_remove(struct platform_device *pdev) #ifdef CONFIG_PM +static struct musb_context_registers musb_context; + +void musb_save_context(struct musb *musb) +{ + int i; + void __iomem *musb_base = musb->mregs; + + if (is_host_enabled(musb)) { + musb_context.frame = musb_readw(musb_base, MUSB_FRAME); + musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE); + } + musb_context.power = musb_readb(musb_base, MUSB_POWER); + musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE); + musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE); + musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE); + musb_context.index = musb_readb(musb_base, MUSB_INDEX); + musb_context.devctl = musb_readb(musb_base, MUSB_DEVCTL); + + for (i = 0; i < MUSB_C_NUM_EPS; ++i) { + musb_writeb(musb_base, MUSB_INDEX, i); + musb_context.index_regs[i].txmaxp = + musb_readw(musb_base, 0x10 + MUSB_TXMAXP); + musb_context.index_regs[i].txcsr = + musb_readw(musb_base, 0x10 + MUSB_TXCSR); + musb_context.index_regs[i].rxmaxp = + musb_readw(musb_base, 0x10 + MUSB_RXMAXP); + musb_context.index_regs[i].rxcsr = + musb_readw(musb_base, 0x10 + MUSB_RXCSR); + + if (musb->dyn_fifo) { + musb_context.index_regs[i].txfifoadd = + musb_read_txfifoadd(musb_base); + musb_context.index_regs[i].rxfifoadd = + musb_read_rxfifoadd(musb_base); + musb_context.index_regs[i].txfifosz = + musb_read_txfifosz(musb_base); + musb_context.index_regs[i].rxfifosz = + musb_read_rxfifosz(musb_base); + } + if (is_host_enabled(musb)) { + musb_context.index_regs[i].txtype = + musb_readb(musb_base, 0x10 + MUSB_TXTYPE); + musb_context.index_regs[i].txinterval = + musb_readb(musb_base, 0x10 + MUSB_TXINTERVAL); + musb_context.index_regs[i].rxtype = + musb_readb(musb_base, 0x10 + MUSB_RXTYPE); + musb_context.index_regs[i].rxinterval = + musb_readb(musb_base, 0x10 + MUSB_RXINTERVAL); + + musb_context.index_regs[i].txfunaddr = + musb_read_txfunaddr(musb_base, i); + musb_context.index_regs[i].txhubaddr = + musb_read_txhubaddr(musb_base, i); + musb_context.index_regs[i].txhubport = + musb_read_txhubport(musb_base, i); + + musb_context.index_regs[i].rxfunaddr = + musb_read_rxfunaddr(musb_base, i); + musb_context.index_regs[i].rxhubaddr = + musb_read_rxhubaddr(musb_base, i); + musb_context.index_regs[i].rxhubport = + musb_read_rxhubport(musb_base, i); + } + } + + musb_writeb(musb_base, MUSB_INDEX, musb_context.index); + + musb_platform_save_context(&musb_context); +} + +void musb_restore_context(struct musb *musb) +{ + int i; + void __iomem *musb_base = musb->mregs; + void __iomem *ep_target_regs; + + musb_platform_restore_context(&musb_context); + + if (is_host_enabled(musb)) { + musb_writew(musb_base, MUSB_FRAME, musb_context.frame); + musb_writeb(musb_base, MUSB_TESTMODE, musb_context.testmode); + } + musb_writeb(musb_base, MUSB_POWER, musb_context.power); + musb_writew(musb_base, MUSB_INTRTXE, musb_context.intrtxe); + musb_writew(musb_base, MUSB_INTRRXE, musb_context.intrrxe); + musb_writeb(musb_base, MUSB_INTRUSBE, musb_context.intrusbe); + musb_writeb(musb_base, MUSB_DEVCTL, musb_context.devctl); + + for (i = 0; i < MUSB_C_NUM_EPS; ++i) { + musb_writeb(musb_base, MUSB_INDEX, i); + musb_writew(musb_base, 0x10 + MUSB_TXMAXP, + musb_context.index_regs[i].txmaxp); + musb_writew(musb_base, 0x10 + MUSB_TXCSR, + musb_context.index_regs[i].txcsr); + musb_writew(musb_base, 0x10 + MUSB_RXMAXP, + musb_context.index_regs[i].rxmaxp); + musb_writew(musb_base, 0x10 + MUSB_RXCSR, + musb_context.index_regs[i].rxcsr); + + if (musb->dyn_fifo) { + musb_write_txfifosz(musb_base, + musb_context.index_regs[i].txfifosz); + musb_write_rxfifosz(musb_base, + musb_context.index_regs[i].rxfifosz); + musb_write_txfifoadd(musb_base, + musb_context.index_regs[i].txfifoadd); + musb_write_rxfifoadd(musb_base, + musb_context.index_regs[i].rxfifoadd); + } + + if (is_host_enabled(musb)) { + musb_writeb(musb_base, 0x10 + MUSB_TXTYPE, + musb_context.index_regs[i].txtype); + musb_writeb(musb_base, 0x10 + MUSB_TXINTERVAL, + musb_context.index_regs[i].txinterval); + musb_writeb(musb_base, 0x10 + MUSB_RXTYPE, + musb_context.index_regs[i].rxtype); + musb_writeb(musb_base, 0x10 + MUSB_RXINTERVAL, + + musb_context.index_regs[i].rxinterval); + musb_write_txfunaddr(musb_base, i, + musb_context.index_regs[i].txfunaddr); + musb_write_txhubaddr(musb_base, i, + musb_context.index_regs[i].txhubaddr); + musb_write_txhubport(musb_base, i, + musb_context.index_regs[i].txhubport); + + ep_target_regs = + musb_read_target_reg_base(i, musb_base); + + musb_write_rxfunaddr(ep_target_regs, + musb_context.index_regs[i].rxfunaddr); + musb_write_rxhubaddr(ep_target_regs, + musb_context.index_regs[i].rxhubaddr); + musb_write_rxhubport(ep_target_regs, + musb_context.index_regs[i].rxhubport); + } + } + + musb_writeb(musb_base, MUSB_INDEX, musb_context.index); +} + static int musb_suspend(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); unsigned long flags; struct musb *musb = dev_to_musb(&pdev->dev); + u8 reg; if (!musb->clock) return 0; @@ -2179,15 +2322,23 @@ static int musb_suspend(struct device *dev) spin_lock_irqsave(&musb->lock, flags); if (is_peripheral_active(musb)) { - /* FIXME force disconnect unless we know USB will wake - * the system up quickly enough to respond ... + /* System is entering into suspend where gadget would not be + * able to respond to host and thus it will be in an unknown + * state for host. Re-enumeration of gadget is required after + * a resume. So we force a disconnect. */ + reg = musb_readb(musb->mregs, MUSB_POWER); + reg &= ~MUSB_POWER_SOFTCONN; + musb_writeb(musb->mregs, MUSB_POWER, reg); + } else if (is_host_active(musb)) { /* we know all the children are suspended; sometimes * they will even be wakeup-enabled. */ } + musb_save_context(musb); + if (musb->set_clock) musb->set_clock(musb->clock, 0); else @@ -2209,6 +2360,8 @@ static int musb_resume_noirq(struct device *dev) else clk_enable(musb->clock); + musb_restore_context(musb); + /* for static cmos like DaVinci, register values were preserved * unless for some reason the whole soc powered down or the USB * module got reset through the PSC (vs just being disabled). diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h index 969287c..38de1be 100644 --- a/drivers/usb/musb/musb_core.h +++ b/drivers/usb/musb/musb_core.h @@ -462,6 +462,45 @@ struct musb { #endif }; +#ifdef CONFIG_PM +struct musb_csr_regs { + /* FIFO registers */ + u16 txmaxp, txcsr, rxmaxp, rxcsr; + u16 rxfifoadd, txfifoadd; + u8 txtype, txinterval, rxtype, rxinterval; + u8 rxfifosz, txfifosz; + u8 txfunaddr, txhubaddr, txhubport; + u8 rxfunaddr, rxhubaddr, rxhubport; +}; + +struct musb_context_registers { + +#if defined(CONFIG_ARCH_OMAP34XX) + u32 otg_sysconfig, otg_forcestandby; +#endif + u8 power; + u16 intrtxe, intrrxe; + u8 intrusbe; + u16 frame; + u8 index, testmode; + + u8 devctl, misc; + + struct musb_csr_regs index_regs[MUSB_C_NUM_EPS]; +}; + +#if defined(CONFIG_ARCH_OMAP34XX) || defined(CONFIG_ARCH_OMAP2430) +extern void musb_platform_save_context(struct musb_context_registers + *musb_context); +extern void musb_platform_restore_context(struct musb_context_registers + *musb_context); +#else +#define musb_platform_save_context(x) do {} while (0) +#define musb_platform_restore_context(x) do {} while (0) +#endif + +#endif + static inline void musb_set_vbus(struct musb *musb, int is_on) { musb->board_set_vbus(musb, is_on); diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h index 473a94e..8ca8f23 100644 --- a/drivers/usb/musb/musb_regs.h +++ b/drivers/usb/musb/musb_regs.h @@ -321,6 +321,26 @@ static inline void musb_write_rxfifoadd(void __iomem *mbase, u16 c_off) musb_writew(mbase, MUSB_RXFIFOADD, c_off); } +static inline u8 musb_read_txfifosz(void __iomem *mbase) +{ + return musb_readb(mbase, MUSB_TXFIFOSZ); +} + +static inline u16 musb_read_txfifoadd(void __iomem *mbase) +{ + return musb_readw(mbase, MUSB_TXFIFOADD); +} + +static inline u8 musb_read_rxfifosz(void __iomem *mbase) +{ + return musb_readb(mbase, MUSB_RXFIFOSZ); +} + +static inline u16 musb_read_rxfifoadd(void __iomem *mbase) +{ + return musb_readw(mbase, MUSB_RXFIFOADD); +} + static inline u8 musb_read_configdata(void __iomem *mbase) { musb_writeb(mbase, MUSB_INDEX, 0); @@ -376,6 +396,36 @@ static inline void musb_write_txhubport(void __iomem *mbase, u8 epnum, qh_h_port_reg); } +static inline u8 musb_read_rxfunaddr(void __iomem *mbase, u8 epnum) +{ + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_RXFUNCADDR)); +} + +static inline u8 musb_read_rxhubaddr(void __iomem *mbase, u8 epnum) +{ + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_RXHUBADDR)); +} + +static inline u8 musb_read_rxhubport(void __iomem *mbase, u8 epnum) +{ + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_RXHUBPORT)); +} + +static inline u8 musb_read_txfunaddr(void __iomem *mbase, u8 epnum) +{ + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_TXFUNCADDR)); +} + +static inline u8 musb_read_txhubaddr(void __iomem *mbase, u8 epnum) +{ + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_TXHUBADDR)); +} + +static inline u8 musb_read_txhubport(void __iomem *mbase, u8 epnum) +{ + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_TXHUBPORT)); +} + #else /* CONFIG_BLACKFIN */ #define USB_BASE USB_FADDR @@ -455,6 +505,22 @@ static inline void musb_write_rxfifoadd(void __iomem *mbase, u16 c_off) { } +static inline u8 musb_read_txfifosz(void __iomem *mbase) +{ +} + +static inline u16 musb_read_txfifoadd(void __iomem *mbase) +{ +} + +static inline u8 musb_read_rxfifosz(void __iomem *mbase) +{ +} + +static inline u16 musb_read_rxfifoadd(void __iomem *mbase) +{ +} + static inline u8 musb_read_configdata(void __iomem *mbase) { return 0; @@ -500,6 +566,30 @@ static inline void musb_write_txhubport(void __iomem *mbase, u8 epnum, { } +static inline u8 musb_read_rxfunaddr(void __iomem *mbase, u8 epnum) +{ +} + +static inline u8 musb_read_rxhubaddr(void __iomem *mbase, u8 epnum) +{ +} + +static inline u8 musb_read_rxhubport(void __iomem *mbase, u8 epnum) +{ +} + +static inline u8 musb_read_txfunaddr(void __iomem *mbase, u8 epnum) +{ +} + +static inline u8 musb_read_txhubaddr(void __iomem *mbase, u8 epnum) +{ +} + +static inline void musb_read_txhubport(void __iomem *mbase, u8 epnum) +{ +} + #endif /* CONFIG_BLACKFIN */ #endif /* __MUSB_REGS_H__ */ diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 83beeac..15a3f27 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -255,6 +255,22 @@ int __init musb_platform_init(struct musb *musb) return 0; } +#ifdef CONFIG_PM +void musb_platform_save_context(struct musb_context_registers + *musb_context) +{ + musb_context->otg_sysconfig = omap_readl(OTG_SYSCONFIG); + musb_context->otg_forcestandby = omap_readl(OTG_FORCESTDBY); +} + +void musb_platform_restore_context(struct musb_context_registers + *musb_context) +{ + omap_writel(musb_context->otg_sysconfig, OTG_SYSCONFIG); + omap_writel(musb_context->otg_forcestandby, OTG_FORCESTDBY); +} +#endif + int musb_platform_suspend(struct musb *musb) { u32 l; -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 26+ messages in thread
* [PATCH 3/3] musb: Add 'extvbus' in musb_hdrc_platform_data 2009-12-14 13:39 ` [PATCH 2/3 v3] musb: Add context save and restore support Ajay Kumar Gupta @ 2009-12-14 13:39 ` Ajay Kumar Gupta 2009-12-14 16:37 ` Felipe Balbi [not found] ` <1260797982-28880-2-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org> 1 sibling, 1 reply; 26+ messages in thread From: Ajay Kumar Gupta @ 2009-12-14 13:39 UTC (permalink / raw) To: linux-usb; +Cc: linux-omap, felipe.balbi, david-b, Ajay Kumar Gupta Some of the board might use external Vbus power supply on musb interface which would require to program ULPI_BUSCONTROL register. Adding 'extvbus' flag which can be set from such boards which will be checked at musb driver files before programming ULPI_BUSCONTROL. Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> --- drivers/usb/musb/musb_core.c | 8 ++++++++ drivers/usb/musb/musb_regs.h | 5 +++++ include/linux/usb/musb.h | 3 +++ 3 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index cd4462b..826d01d 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2027,6 +2027,7 @@ bad_config: /* host side needs more setup */ if (is_host_enabled(musb)) { struct usb_hcd *hcd = musb_to_hcd(musb); + u8 busctl; otg_set_host(musb->xceiv, &hcd->self); @@ -2034,6 +2035,13 @@ bad_config: hcd->self.otg_port = 1; musb->xceiv->host = &hcd->self; hcd->power_budget = 2 * (plat->power ? : 250); + + /* program PHY to use external vBus if required */ + if (plat->extvbus) { + busctl = musb_readb(musb->mregs, MUSB_ULPI_BUSCONTROL); + busctl |= ULPI_USE_EXTVBUS; + musb_writeb(musb->mregs, MUSB_ULPI_BUSCONTROL, busctl); + } } /* For the host-only role, we can activate right away. diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h index 8ca8f23..cba724d 100644 --- a/drivers/usb/musb/musb_regs.h +++ b/drivers/usb/musb/musb_regs.h @@ -72,6 +72,10 @@ #define MUSB_DEVCTL_HR 0x02 #define MUSB_DEVCTL_SESSION 0x01 +/* ULPI VBUSCONTROL */ +#define ULPI_USE_EXTVBUS 0x01 +#define ULPI_USE_EXTVBUSIND 0x02 + /* TESTMODE */ #define MUSB_TEST_FORCE_HOST 0x80 #define MUSB_TEST_FIFO_ACCESS 0x40 @@ -246,6 +250,7 @@ /* REVISIT: vctrl/vstatus: optional vendor utmi+phy register at 0x68 */ #define MUSB_HWVERS 0x6C /* 8 bit */ +#define MUSB_ULPI_BUSCONTROL 0x70 /* 8 bit */ #define MUSB_EPINFO 0x78 /* 8 bit */ #define MUSB_RAMINFO 0x79 /* 8 bit */ diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h index d437556..4b7f8fa 100644 --- a/include/linux/usb/musb.h +++ b/include/linux/usb/musb.h @@ -76,6 +76,9 @@ struct musb_hdrc_platform_data { /* (HOST or OTG) msec/2 after VBUS on till power good */ u8 potpgt; + /* (HOST or OTG) program PHY for external Vbus */ + unsigned extvbus:1; + /* Power the device on or off */ int (*set_power)(int state); -- 1.6.2.4 ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH 3/3] musb: Add 'extvbus' in musb_hdrc_platform_data 2009-12-14 13:39 ` [PATCH 3/3] musb: Add 'extvbus' in musb_hdrc_platform_data Ajay Kumar Gupta @ 2009-12-14 16:37 ` Felipe Balbi [not found] ` <20091214163746.GC31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Felipe Balbi @ 2009-12-14 16:37 UTC (permalink / raw) To: ext Ajay Kumar Gupta Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, Balbi Felipe (Nokia-D/Helsinki), david-b@pacbell.net Hi, On Mon, Dec 14, 2009 at 02:39:42PM +0100, ext Ajay Kumar Gupta wrote: >diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h >index 8ca8f23..cba724d 100644 >--- a/drivers/usb/musb/musb_regs.h >+++ b/drivers/usb/musb/musb_regs.h >@@ -72,6 +72,10 @@ > #define MUSB_DEVCTL_HR 0x02 > #define MUSB_DEVCTL_SESSION 0x01 > >+/* ULPI VBUSCONTROL */ >+#define ULPI_USE_EXTVBUS 0x01 >+#define ULPI_USE_EXTVBUSIND 0x02 shouldn't these go to drivers/usb/otg/ulpi.c or include/usb/ulpi.h ? or is this musb specific ?? If it's musb specific, please prepend with MUSB_ -- balbi ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <20091214163746.GC31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>]
* RE: [PATCH 3/3] musb: Add 'extvbus' in musb_hdrc_platform_data [not found] ` <20091214163746.GC31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> @ 2009-12-15 4:07 ` Gupta, Ajay Kumar 0 siblings, 0 replies; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-15 4:07 UTC (permalink / raw) To: felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > -----Original Message----- > From: Felipe Balbi [mailto:felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org] > Sent: Monday, December 14, 2009 10:08 PM > To: Gupta, Ajay Kumar > Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Balbi Felipe > (Nokia-D/Helsinki); david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > Subject: Re: [PATCH 3/3] musb: Add 'extvbus' in musb_hdrc_platform_data > > Hi, > > On Mon, Dec 14, 2009 at 02:39:42PM +0100, ext Ajay Kumar Gupta wrote: > >diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h > >index 8ca8f23..cba724d 100644 > >--- a/drivers/usb/musb/musb_regs.h > >+++ b/drivers/usb/musb/musb_regs.h > >@@ -72,6 +72,10 @@ > > #define MUSB_DEVCTL_HR 0x02 > > #define MUSB_DEVCTL_SESSION 0x01 > > > >+/* ULPI VBUSCONTROL */ > >+#define ULPI_USE_EXTVBUS 0x01 > >+#define ULPI_USE_EXTVBUSIND 0x02 > > shouldn't these go to drivers/usb/otg/ulpi.c or include/usb/ulpi.h ? > > or is this musb specific ?? If it's musb specific, please prepend with > MUSB_ Yes, they are MUSB specific. I will append 'MUSB_' in next version. -Ajay > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <1260797982-28880-2-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <1260797982-28880-2-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org> @ 2009-12-14 16:33 ` Felipe Balbi 2009-12-14 16:39 ` Felipe Balbi [not found] ` <20091214163324.GB31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> 2009-12-17 13:38 ` Arnaud Mandy 1 sibling, 2 replies; 26+ messages in thread From: Felipe Balbi @ 2009-12-14 16:33 UTC (permalink / raw) To: ext Ajay Kumar Gupta Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbi Felipe (Nokia-D/Helsinki), david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org, Anand Gadiyar Hi, On Mon, Dec 14, 2009 at 02:39:41PM +0100, ext Ajay Kumar Gupta wrote: >+void musb_restore_context(struct musb *musb) >+{ >+ int i; >+ void __iomem *musb_base = musb->mregs; >+ void __iomem *ep_target_regs; >+ >+ musb_platform_restore_context(&musb_context); >+ >+ if (is_host_enabled(musb)) { >+ musb_writew(musb_base, MUSB_FRAME, musb_context.frame); >+ musb_writeb(musb_base, MUSB_TESTMODE, musb_context.testmode); >+ } >+ musb_writeb(musb_base, MUSB_POWER, musb_context.power); >+ musb_writew(musb_base, MUSB_INTRTXE, musb_context.intrtxe); >+ musb_writew(musb_base, MUSB_INTRRXE, musb_context.intrrxe); >+ musb_writeb(musb_base, MUSB_INTRUSBE, musb_context.intrusbe); >+ musb_writeb(musb_base, MUSB_DEVCTL, musb_context.devctl); >+ >+ for (i = 0; i < MUSB_C_NUM_EPS; ++i) { >+ musb_writeb(musb_base, MUSB_INDEX, i); >+ musb_writew(musb_base, 0x10 + MUSB_TXMAXP, >+ musb_context.index_regs[i].txmaxp); >+ musb_writew(musb_base, 0x10 + MUSB_TXCSR, >+ musb_context.index_regs[i].txcsr); >+ musb_writew(musb_base, 0x10 + MUSB_RXMAXP, >+ musb_context.index_regs[i].rxmaxp); >+ musb_writew(musb_base, 0x10 + MUSB_RXCSR, >+ musb_context.index_regs[i].rxcsr); >+ >+ if (musb->dyn_fifo) { if (musb->config->dyn_fifo) >@@ -2179,15 +2322,23 @@ static int musb_suspend(struct device *dev) > spin_lock_irqsave(&musb->lock, flags); > > if (is_peripheral_active(musb)) { >- /* FIXME force disconnect unless we know USB will wake >- * the system up quickly enough to respond ... >+ /* System is entering into suspend where gadget would not be >+ * able to respond to host and thus it will be in an unknown >+ * state for host. Re-enumeration of gadget is required after >+ * a resume. So we force a disconnect. > */ >+ reg = musb_readb(musb->mregs, MUSB_POWER); >+ reg &= ~MUSB_POWER_SOFTCONN; >+ musb_writeb(musb->mregs, MUSB_POWER, reg); >+ I think we should only allow suspend if cable isn't connected. What would happend if you have mounted fs (using mass storage), user is transferring files and you force a disconnect ? >diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c >index 83beeac..15a3f27 100644 >--- a/drivers/usb/musb/omap2430.c >+++ b/drivers/usb/musb/omap2430.c >@@ -255,6 +255,22 @@ int __init musb_platform_init(struct musb *musb) > return 0; > } > >+#ifdef CONFIG_PM >+void musb_platform_save_context(struct musb_context_registers >+ *musb_context) >+{ >+ musb_context->otg_sysconfig = omap_readl(OTG_SYSCONFIG); >+ musb_context->otg_forcestandby = omap_readl(OTG_FORCESTDBY); >+} >+ >+void musb_platform_restore_context(struct musb_context_registers >+ *musb_context) waaay too many exported functions already. Let's add some structure to pass functions pointers. I'll cook a patch adding suspend(), resume(), init() and friends and send tomorrow. Then your patch would add save_context() and restore_context(). -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 2/3 v3] musb: Add context save and restore support 2009-12-14 16:33 ` [PATCH 2/3 v3] musb: Add context save and restore support Felipe Balbi @ 2009-12-14 16:39 ` Felipe Balbi [not found] ` <20091214163324.GB31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> 1 sibling, 0 replies; 26+ messages in thread From: Felipe Balbi @ 2009-12-14 16:39 UTC (permalink / raw) To: Balbi Felipe (Nokia-D/Helsinki) Cc: ext Ajay Kumar Gupta, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, david-b@pacbell.net, Anand Gadiyar Hi, On Mon, Dec 14, 2009 at 05:33:24PM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote: >waaay too many exported functions already. Let's add some structure to >pass functions pointers. I'll cook a patch adding suspend(), resume(), >init() and friends and send tomorrow. > >Then your patch would add save_context() and restore_context(). unless you beat me on that :-) -- balbi ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <20091214163324.GB31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>]
* RE: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <20091214163324.GB31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> @ 2009-12-15 11:44 ` Gupta, Ajay Kumar [not found] ` <19F8576C6E063C45BE387C64729E739404372AAF0F-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-15 11:44 UTC (permalink / raw) To: felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org, Gadiyar, Anand <snip..> > >@@ -2179,15 +2322,23 @@ static int musb_suspend(struct device *dev) > > spin_lock_irqsave(&musb->lock, flags); > > > > if (is_peripheral_active(musb)) { > >- /* FIXME force disconnect unless we know USB will wake > >- * the system up quickly enough to respond ... > >+ /* System is entering into suspend where gadget would not > be > >+ * able to respond to host and thus it will be in an > unknown > >+ * state for host. Re-enumeration of gadget is required > after > >+ * a resume. So we force a disconnect. > > */ > >+ reg = musb_readb(musb->mregs, MUSB_POWER); > >+ reg &= ~MUSB_POWER_SOFTCONN; > >+ musb_writeb(musb->mregs, MUSB_POWER, reg); > >+ > > I think we should only allow suspend if cable isn't connected. What > would happend if you have mounted fs (using mass storage), user is > transferring files and you force a disconnect ? We force a disconnect during suspend which is actually triggered by user Only. So do we need to consider this scenario? Moreover, in case of OMAP3, as Smart-Idle/Stdby is enabled so system shouldn't enter into suspend state if cable is connected and data transfer is going on. -Ajay > > >diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c > >index 83beeac..15a3f27 100644 > >--- a/drivers/usb/musb/omap2430.c > >+++ b/drivers/usb/musb/omap2430.c -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <19F8576C6E063C45BE387C64729E739404372AAF0F-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* RE: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <19F8576C6E063C45BE387C64729E739404372AAF0F-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2009-12-15 12:04 ` Gadiyar, Anand [not found] ` <5A47E75E594F054BAF48C5E4FC4B92AB030ADD53A6-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Gadiyar, Anand @ 2009-12-15 12:04 UTC (permalink / raw) To: Gupta, Ajay Kumar, felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > > I think we should only allow suspend if cable isn't connected. What > > would happend if you have mounted fs (using mass storage), user is > > transferring files and you force a disconnect ? > > We force a disconnect during suspend which is actually triggered by user > Only. So do we need to consider this scenario? > Like Ajay says, the kernel would need to take a call either way: - Disallowing a system wide suspend, just because a USB cable is connected - Allow a system-wide suspend, but disconnect the gadget device. I would vote to allow a system-wide suspend. A user that tries to put a phone to standby in the middle of a data transfer shouldn't be too surprised that the data transfer was aborted. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <5A47E75E594F054BAF48C5E4FC4B92AB030ADD53A6-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <5A47E75E594F054BAF48C5E4FC4B92AB030ADD53A6-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2009-12-15 12:10 ` Felipe Balbi [not found] ` <20091215121032.GH3689-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Felipe Balbi @ 2009-12-15 12:10 UTC (permalink / raw) To: ext Gadiyar, Anand Cc: Gupta, Ajay Kumar, Balbi Felipe (Nokia-D/Helsinki), linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org Hi, On Tue, Dec 15, 2009 at 01:04:01PM +0100, ext Gadiyar, Anand wrote: >> > I think we should only allow suspend if cable isn't connected. What >> > would happend if you have mounted fs (using mass storage), user is >> > transferring files and you force a disconnect ? >> >> We force a disconnect during suspend which is actually triggered by user >> Only. So do we need to consider this scenario? >> > >Like Ajay says, the kernel would need to take a call either way: > >- Disallowing a system wide suspend, just because a USB cable is connected >- Allow a system-wide suspend, but disconnect the gadget device. > > >I would vote to allow a system-wide suspend. A user that tries to put >a phone to standby in the middle of a data transfer shouldn't be too >surprised that the data transfer was aborted. yes, but the problem would be the data corrupted. I'm pretty sure user will be a bit surprised that he now can't use his 27GB and lost all contacts, movies, smses, etc. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <20091215121032.GH3689-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>]
* RE: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <20091215121032.GH3689-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> @ 2009-12-15 12:36 ` Gupta, Ajay Kumar [not found] ` <19F8576C6E063C45BE387C64729E739404372AAF44-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-15 12:36 UTC (permalink / raw) To: felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org, Gadiyar, Anand Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > -----Original Message----- > From: Felipe Balbi [mailto:felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org] > Sent: Tuesday, December 15, 2009 5:41 PM > To: Gadiyar, Anand > Cc: Gupta, Ajay Kumar; Balbi Felipe (Nokia-D/Helsinki); linux- > usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > Subject: Re: [PATCH 2/3 v3] musb: Add context save and restore support > > Hi, > > On Tue, Dec 15, 2009 at 01:04:01PM +0100, ext Gadiyar, Anand wrote: > >> > I think we should only allow suspend if cable isn't connected. What > >> > would happend if you have mounted fs (using mass storage), user is > >> > transferring files and you force a disconnect ? > >> > >> We force a disconnect during suspend which is actually triggered by > user > >> Only. So do we need to consider this scenario? > >> > > > >Like Ajay says, the kernel would need to take a call either way: > > > >- Disallowing a system wide suspend, just because a USB cable is > connected > >- Allow a system-wide suspend, but disconnect the gadget device. > > > > > >I would vote to allow a system-wide suspend. A user that tries to put > >a phone to standby in the middle of a data transfer shouldn't be too > >surprised that the data transfer was aborted. > > yes, but the problem would be the data corrupted. I'm pretty sure user > will be a bit surprised that he now can't use his 27GB and lost all > contacts, movies, smses, etc. It should be system's responsibility for not entering into suspend mode when there is an ongoing active transfer. If this is reliable then there is no need for any force disconnect. On OMAP3EVM, I can see that system doesn't enter into suspend mode when cable is connected so should be fine for OMAP. Felipe/Ajay, What do you suggest, shall we remove this force disconnect code? -Ajay > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <19F8576C6E063C45BE387C64729E739404372AAF44-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* RE: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <19F8576C6E063C45BE387C64729E739404372AAF44-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2009-12-15 12:39 ` Gupta, Ajay Kumar 2009-12-15 12:48 ` Felipe Balbi 1 sibling, 0 replies; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-15 12:39 UTC (permalink / raw) To: Gupta, Ajay Kumar, felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org, Gadiyar, Anand Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > It should be system's responsibility for not entering into suspend mode > when > there is an ongoing active transfer. If this is reliable then there is no > need for any force disconnect. > > On OMAP3EVM, I can see that system doesn't enter into suspend mode when > cable is connected so should be fine for OMAP. > > Felipe/Ajay, oops! It's 'Felipe/Anand'. -Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <19F8576C6E063C45BE387C64729E739404372AAF44-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 2009-12-15 12:39 ` Gupta, Ajay Kumar @ 2009-12-15 12:48 ` Felipe Balbi 1 sibling, 0 replies; 26+ messages in thread From: Felipe Balbi @ 2009-12-15 12:48 UTC (permalink / raw) To: ext Gupta, Ajay Kumar Cc: Balbi Felipe (Nokia-D/Helsinki), Gadiyar, Anand, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org Hi, On Tue, Dec 15, 2009 at 01:36:32PM +0100, ext Gupta, Ajay Kumar wrote: >> -----Original Message----- >> From: Felipe Balbi [mailto:felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org] >> Sent: Tuesday, December 15, 2009 5:41 PM >> To: Gadiyar, Anand >> Cc: Gupta, Ajay Kumar; Balbi Felipe (Nokia-D/Helsinki); linux- >> usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org >> Subject: Re: [PATCH 2/3 v3] musb: Add context save and restore support >> >> Hi, >> >> On Tue, Dec 15, 2009 at 01:04:01PM +0100, ext Gadiyar, Anand wrote: >> >> > I think we should only allow suspend if cable isn't connected. What >> >> > would happend if you have mounted fs (using mass storage), user is >> >> > transferring files and you force a disconnect ? >> >> >> >> We force a disconnect during suspend which is actually triggered by >> user >> >> Only. So do we need to consider this scenario? >> >> >> > >> >Like Ajay says, the kernel would need to take a call either way: >> > >> >- Disallowing a system wide suspend, just because a USB cable is >> connected >> >- Allow a system-wide suspend, but disconnect the gadget device. >> > >> > >> >I would vote to allow a system-wide suspend. A user that tries to put >> >a phone to standby in the middle of a data transfer shouldn't be too >> >surprised that the data transfer was aborted. >> >> yes, but the problem would be the data corrupted. I'm pretty sure user >> will be a bit surprised that he now can't use his 27GB and lost all >> contacts, movies, smses, etc. > >It should be system's responsibility for not entering into suspend mode when >there is an ongoing active transfer. If this is reliable then there is no >need for any force disconnect. > >On OMAP3EVM, I can see that system doesn't enter into suspend mode when >cable is connected so should be fine for OMAP. > >Felipe/Ajay, >What do you suggest, shall we remove this force disconnect code? I would suggest that. we drop the force disconnect code. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <1260797982-28880-2-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org> 2009-12-14 16:33 ` [PATCH 2/3 v3] musb: Add context save and restore support Felipe Balbi @ 2009-12-17 13:38 ` Arnaud Mandy 2009-12-17 13:51 ` Gupta, Ajay Kumar 1 sibling, 1 reply; 26+ messages in thread From: Arnaud Mandy @ 2009-12-17 13:38 UTC (permalink / raw) To: ext Ajay Kumar Gupta Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbi Felipe (Nokia-D/Helsinki), david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org, Anand Gadiyar ext Ajay Kumar Gupta wrote: > Adding support for MUSB register save and restore during system > suspend and resume. > > Changes: > - Added musb_save/restore_context() functions > - Added platform specific musb_platform_save/restore_context() > to handle platform specific jobs. > - Maintaining BlackFin compatibility by adding read/write > functions for registers which are not available in BlackFin > > Tested system suspend and resume on OMAP3EVM board. > > Signed-off-by: Anand Gadiyar <gadiyar-l0cyMroinI0@public.gmane.org> > Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org> > --- > Changes from v2: > - Saving/Restoring host only registers within is_host_enabled() check. > - Saving/Restoring Tx/Rx FIFOSZ/FIFOADDR within musb->dynfifo check. > > drivers/usb/musb/musb_core.c | 157 +++++++++++++++++++++++++++++++++++++++++- > drivers/usb/musb/musb_core.h | 39 ++++++++++ > drivers/usb/musb/musb_regs.h | 90 ++++++++++++++++++++++++ > drivers/usb/musb/omap2430.c | 16 ++++ > 4 files changed, 300 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > index d4adbbf..cd4462b 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -2167,11 +2167,154 @@ static int __devexit musb_remove(struct platform_device *pdev) > > #ifdef CONFIG_PM > > +static struct musb_context_registers musb_context; > + > +void musb_save_context(struct musb *musb) > +{ > Could you add one more parameter to this function call, which would select either if we want to save the musb_platform context or not? I m working at the moment on turning off the musb when cable unplugged and turning it on with restoring context after cable re-connect. In this case I don't need to restore the the musb_platform_context since I just set them before calling this one. Same apply for restore. what do you think? I could also modify slightly this implementation after it is ready and submit it. > + int i; > + void __iomem *musb_base = musb->mregs; > + > + if (is_host_enabled(musb)) { > + musb_context.frame = musb_readw(musb_base, MUSB_FRAME); > + musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE); > + } > + musb_context.power = musb_readb(musb_base, MUSB_POWER); > + musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE); > + musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE); > + musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE); > + musb_context.index = musb_readb(musb_base, MUSB_INDEX); > + musb_context.devctl = musb_readb(musb_base, MUSB_DEVCTL); > + > + for (i = 0; i < MUSB_C_NUM_EPS; ++i) { > + musb_writeb(musb_base, MUSB_INDEX, i); > + musb_context.index_regs[i].txmaxp = > + musb_readw(musb_base, 0x10 + MUSB_TXMAXP); > + musb_context.index_regs[i].txcsr = > + musb_readw(musb_base, 0x10 + MUSB_TXCSR); > + musb_context.index_regs[i].rxmaxp = > + musb_readw(musb_base, 0x10 + MUSB_RXMAXP); > + musb_context.index_regs[i].rxcsr = > + musb_readw(musb_base, 0x10 + MUSB_RXCSR); > + > + if (musb->dyn_fifo) { > + musb_context.index_regs[i].txfifoadd = > + musb_read_txfifoadd(musb_base); > + musb_context.index_regs[i].rxfifoadd = > + musb_read_rxfifoadd(musb_base); > + musb_context.index_regs[i].txfifosz = > + musb_read_txfifosz(musb_base); > + musb_context.index_regs[i].rxfifosz = > + musb_read_rxfifosz(musb_base); > + } > + if (is_host_enabled(musb)) { > + musb_context.index_regs[i].txtype = > + musb_readb(musb_base, 0x10 + MUSB_TXTYPE); > + musb_context.index_regs[i].txinterval = > + musb_readb(musb_base, 0x10 + MUSB_TXINTERVAL); > + musb_context.index_regs[i].rxtype = > + musb_readb(musb_base, 0x10 + MUSB_RXTYPE); > + musb_context.index_regs[i].rxinterval = > + musb_readb(musb_base, 0x10 + MUSB_RXINTERVAL); > + > + musb_context.index_regs[i].txfunaddr = > + musb_read_txfunaddr(musb_base, i); > + musb_context.index_regs[i].txhubaddr = > + musb_read_txhubaddr(musb_base, i); > + musb_context.index_regs[i].txhubport = > + musb_read_txhubport(musb_base, i); > + > + musb_context.index_regs[i].rxfunaddr = > + musb_read_rxfunaddr(musb_base, i); > + musb_context.index_regs[i].rxhubaddr = > + musb_read_rxhubaddr(musb_base, i); > + musb_context.index_regs[i].rxhubport = > + musb_read_rxhubport(musb_base, i); > + } > + } > + > + musb_writeb(musb_base, MUSB_INDEX, musb_context.index); > + > + musb_platform_save_context(&musb_context); > +} > + > +void musb_restore_context(struct musb *musb) > +{ > + int i; > + void __iomem *musb_base = musb->mregs; > + void __iomem *ep_target_regs; > + > + musb_platform_restore_context(&musb_context); > + > + if (is_host_enabled(musb)) { > + musb_writew(musb_base, MUSB_FRAME, musb_context.frame); > + musb_writeb(musb_base, MUSB_TESTMODE, musb_context.testmode); > + } > + musb_writeb(musb_base, MUSB_POWER, musb_context.power); > + musb_writew(musb_base, MUSB_INTRTXE, musb_context.intrtxe); > + musb_writew(musb_base, MUSB_INTRRXE, musb_context.intrrxe); > + musb_writeb(musb_base, MUSB_INTRUSBE, musb_context.intrusbe); > + musb_writeb(musb_base, MUSB_DEVCTL, musb_context.devctl); > + > + for (i = 0; i < MUSB_C_NUM_EPS; ++i) { > + musb_writeb(musb_base, MUSB_INDEX, i); > + musb_writew(musb_base, 0x10 + MUSB_TXMAXP, > + musb_context.index_regs[i].txmaxp); > + musb_writew(musb_base, 0x10 + MUSB_TXCSR, > + musb_context.index_regs[i].txcsr); > + musb_writew(musb_base, 0x10 + MUSB_RXMAXP, > + musb_context.index_regs[i].rxmaxp); > + musb_writew(musb_base, 0x10 + MUSB_RXCSR, > + musb_context.index_regs[i].rxcsr); > + > + if (musb->dyn_fifo) { > + musb_write_txfifosz(musb_base, > + musb_context.index_regs[i].txfifosz); > + musb_write_rxfifosz(musb_base, > + musb_context.index_regs[i].rxfifosz); > + musb_write_txfifoadd(musb_base, > + musb_context.index_regs[i].txfifoadd); > + musb_write_rxfifoadd(musb_base, > + musb_context.index_regs[i].rxfifoadd); > + } > + > + if (is_host_enabled(musb)) { > + musb_writeb(musb_base, 0x10 + MUSB_TXTYPE, > + musb_context.index_regs[i].txtype); > + musb_writeb(musb_base, 0x10 + MUSB_TXINTERVAL, > + musb_context.index_regs[i].txinterval); > + musb_writeb(musb_base, 0x10 + MUSB_RXTYPE, > + musb_context.index_regs[i].rxtype); > + musb_writeb(musb_base, 0x10 + MUSB_RXINTERVAL, > + > + musb_context.index_regs[i].rxinterval); > + musb_write_txfunaddr(musb_base, i, > + musb_context.index_regs[i].txfunaddr); > + musb_write_txhubaddr(musb_base, i, > + musb_context.index_regs[i].txhubaddr); > + musb_write_txhubport(musb_base, i, > + musb_context.index_regs[i].txhubport); > + > + ep_target_regs = > + musb_read_target_reg_base(i, musb_base); > + > + musb_write_rxfunaddr(ep_target_regs, > + musb_context.index_regs[i].rxfunaddr); > + musb_write_rxhubaddr(ep_target_regs, > + musb_context.index_regs[i].rxhubaddr); > + musb_write_rxhubport(ep_target_regs, > + musb_context.index_regs[i].rxhubport); > + } > + } > + > + musb_writeb(musb_base, MUSB_INDEX, musb_context.index); > +} > + > static int musb_suspend(struct device *dev) > { > struct platform_device *pdev = to_platform_device(dev); > unsigned long flags; > struct musb *musb = dev_to_musb(&pdev->dev); > + u8 reg; > > if (!musb->clock) > return 0; > @@ -2179,15 +2322,23 @@ static int musb_suspend(struct device *dev) > spin_lock_irqsave(&musb->lock, flags); > > if (is_peripheral_active(musb)) { > - /* FIXME force disconnect unless we know USB will wake > - * the system up quickly enough to respond ... > + /* System is entering into suspend where gadget would not be > + * able to respond to host and thus it will be in an unknown > + * state for host. Re-enumeration of gadget is required after > + * a resume. So we force a disconnect. > */ > + reg = musb_readb(musb->mregs, MUSB_POWER); > + reg &= ~MUSB_POWER_SOFTCONN; > + musb_writeb(musb->mregs, MUSB_POWER, reg); > + > } else if (is_host_active(musb)) { > /* we know all the children are suspended; sometimes > * they will even be wakeup-enabled. > */ > } > > + musb_save_context(musb); > + > if (musb->set_clock) > musb->set_clock(musb->clock, 0); > else > @@ -2209,6 +2360,8 @@ static int musb_resume_noirq(struct device *dev) > else > clk_enable(musb->clock); > > + musb_restore_context(musb); > + > /* for static cmos like DaVinci, register values were preserved > * unless for some reason the whole soc powered down or the USB > * module got reset through the PSC (vs just being disabled). > diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h > index 969287c..38de1be 100644 > --- a/drivers/usb/musb/musb_core.h > +++ b/drivers/usb/musb/musb_core.h > @@ -462,6 +462,45 @@ struct musb { > #endif > }; > > +#ifdef CONFIG_PM > +struct musb_csr_regs { > + /* FIFO registers */ > + u16 txmaxp, txcsr, rxmaxp, rxcsr; > + u16 rxfifoadd, txfifoadd; > + u8 txtype, txinterval, rxtype, rxinterval; > + u8 rxfifosz, txfifosz; > + u8 txfunaddr, txhubaddr, txhubport; > + u8 rxfunaddr, rxhubaddr, rxhubport; > +}; > + > +struct musb_context_registers { > + > +#if defined(CONFIG_ARCH_OMAP34XX) > + u32 otg_sysconfig, otg_forcestandby; > +#endif > + u8 power; > + u16 intrtxe, intrrxe; > + u8 intrusbe; > + u16 frame; > + u8 index, testmode; > + > + u8 devctl, misc; > + > + struct musb_csr_regs index_regs[MUSB_C_NUM_EPS]; > +}; > + > +#if defined(CONFIG_ARCH_OMAP34XX) || defined(CONFIG_ARCH_OMAP2430) > +extern void musb_platform_save_context(struct musb_context_registers > + *musb_context); > +extern void musb_platform_restore_context(struct musb_context_registers > + *musb_context); > +#else > +#define musb_platform_save_context(x) do {} while (0) > +#define musb_platform_restore_context(x) do {} while (0) > +#endif > + > +#endif > + > static inline void musb_set_vbus(struct musb *musb, int is_on) > { > musb->board_set_vbus(musb, is_on); > diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h > index 473a94e..8ca8f23 100644 > --- a/drivers/usb/musb/musb_regs.h > +++ b/drivers/usb/musb/musb_regs.h > @@ -321,6 +321,26 @@ static inline void musb_write_rxfifoadd(void __iomem *mbase, u16 c_off) > musb_writew(mbase, MUSB_RXFIFOADD, c_off); > } > > +static inline u8 musb_read_txfifosz(void __iomem *mbase) > +{ > + return musb_readb(mbase, MUSB_TXFIFOSZ); > +} > + > +static inline u16 musb_read_txfifoadd(void __iomem *mbase) > +{ > + return musb_readw(mbase, MUSB_TXFIFOADD); > +} > + > +static inline u8 musb_read_rxfifosz(void __iomem *mbase) > +{ > + return musb_readb(mbase, MUSB_RXFIFOSZ); > +} > + > +static inline u16 musb_read_rxfifoadd(void __iomem *mbase) > +{ > + return musb_readw(mbase, MUSB_RXFIFOADD); > +} > + > static inline u8 musb_read_configdata(void __iomem *mbase) > { > musb_writeb(mbase, MUSB_INDEX, 0); > @@ -376,6 +396,36 @@ static inline void musb_write_txhubport(void __iomem *mbase, u8 epnum, > qh_h_port_reg); > } > > +static inline u8 musb_read_rxfunaddr(void __iomem *mbase, u8 epnum) > +{ > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_RXFUNCADDR)); > +} > + > +static inline u8 musb_read_rxhubaddr(void __iomem *mbase, u8 epnum) > +{ > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_RXHUBADDR)); > +} > + > +static inline u8 musb_read_rxhubport(void __iomem *mbase, u8 epnum) > +{ > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_RXHUBPORT)); > +} > + > +static inline u8 musb_read_txfunaddr(void __iomem *mbase, u8 epnum) > +{ > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_TXFUNCADDR)); > +} > + > +static inline u8 musb_read_txhubaddr(void __iomem *mbase, u8 epnum) > +{ > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_TXHUBADDR)); > +} > + > +static inline u8 musb_read_txhubport(void __iomem *mbase, u8 epnum) > +{ > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, MUSB_TXHUBPORT)); > +} > + > #else /* CONFIG_BLACKFIN */ > > #define USB_BASE USB_FADDR > @@ -455,6 +505,22 @@ static inline void musb_write_rxfifoadd(void __iomem *mbase, u16 c_off) > { > } > > +static inline u8 musb_read_txfifosz(void __iomem *mbase) > +{ > +} > + > +static inline u16 musb_read_txfifoadd(void __iomem *mbase) > +{ > +} > + > +static inline u8 musb_read_rxfifosz(void __iomem *mbase) > +{ > +} > + > +static inline u16 musb_read_rxfifoadd(void __iomem *mbase) > +{ > +} > + > static inline u8 musb_read_configdata(void __iomem *mbase) > { > return 0; > @@ -500,6 +566,30 @@ static inline void musb_write_txhubport(void __iomem *mbase, u8 epnum, > { > } > > +static inline u8 musb_read_rxfunaddr(void __iomem *mbase, u8 epnum) > +{ > +} > + > +static inline u8 musb_read_rxhubaddr(void __iomem *mbase, u8 epnum) > +{ > +} > + > +static inline u8 musb_read_rxhubport(void __iomem *mbase, u8 epnum) > +{ > +} > + > +static inline u8 musb_read_txfunaddr(void __iomem *mbase, u8 epnum) > +{ > +} > + > +static inline u8 musb_read_txhubaddr(void __iomem *mbase, u8 epnum) > +{ > +} > + > +static inline void musb_read_txhubport(void __iomem *mbase, u8 epnum) > +{ > +} > + > #endif /* CONFIG_BLACKFIN */ > > #endif /* __MUSB_REGS_H__ */ > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c > index 83beeac..15a3f27 100644 > --- a/drivers/usb/musb/omap2430.c > +++ b/drivers/usb/musb/omap2430.c > @@ -255,6 +255,22 @@ int __init musb_platform_init(struct musb *musb) > return 0; > } > > +#ifdef CONFIG_PM > +void musb_platform_save_context(struct musb_context_registers > + *musb_context) > +{ > + musb_context->otg_sysconfig = omap_readl(OTG_SYSCONFIG); > + musb_context->otg_forcestandby = omap_readl(OTG_FORCESTDBY); > +} > + > +void musb_platform_restore_context(struct musb_context_registers > + *musb_context) > +{ > + omap_writel(musb_context->otg_sysconfig, OTG_SYSCONFIG); > + omap_writel(musb_context->otg_forcestandby, OTG_FORCESTDBY); > +} > +#endif > + > int musb_platform_suspend(struct musb *musb) > { > u32 l; > -- > 1.6.2.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH 2/3 v3] musb: Add context save and restore support 2009-12-17 13:38 ` Arnaud Mandy @ 2009-12-17 13:51 ` Gupta, Ajay Kumar [not found] ` <19F8576C6E063C45BE387C64729E73940449F439C7-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-17 13:51 UTC (permalink / raw) To: Arnaud Mandy Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, Balbi Felipe (Nokia-D/Helsinki), david-b@pacbell.net, Gadiyar, Anand <snip> > > > > #ifdef CONFIG_PM > > > > +static struct musb_context_registers musb_context; > > + > > +void musb_save_context(struct musb *musb) > > +{ > > > > Could you add one more parameter to this function call, which would > select either if we want to save the musb_platform context or not? > I m working at the moment on turning off the musb when cable unplugged > and turning it on with restoring context after cable re-connect. > In this case I don't need to restore the the musb_platform_context since > I just set them before calling this one. > > Same apply for restore. > > what do you think? > I could also modify slightly this implementation after it is ready and > submit it. I think you want to add the parameter in musb_platform_save_context() and not in musb_save_context. If so then where do you restore them? {As you said before calling this} I think if the requirement is generic and suits for all other platforms Using musb then we can add it. -Ajay > > > + int i; > > + void __iomem *musb_base = musb->mregs; > > + > > + if (is_host_enabled(musb)) { > > + musb_context.frame = musb_readw(musb_base, MUSB_FRAME); > > + musb_context.testmode = musb_readb(musb_base, > MUSB_TESTMODE); > > + } > > + musb_context.power = musb_readb(musb_base, MUSB_POWER); > > + musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE); > > + musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE); > > + musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE); > > + musb_context.index = musb_readb(musb_base, MUSB_INDEX); > > + musb_context.devctl = musb_readb(musb_base, MUSB_DEVCTL); > > + > > + for (i = 0; i < MUSB_C_NUM_EPS; ++i) { > > + musb_writeb(musb_base, MUSB_INDEX, i); > > + musb_context.index_regs[i].txmaxp = > > + musb_readw(musb_base, 0x10 + MUSB_TXMAXP); > > + musb_context.index_regs[i].txcsr = > > + musb_readw(musb_base, 0x10 + MUSB_TXCSR); > > + musb_context.index_regs[i].rxmaxp = > > + musb_readw(musb_base, 0x10 + MUSB_RXMAXP); > > + musb_context.index_regs[i].rxcsr = > > + musb_readw(musb_base, 0x10 + MUSB_RXCSR); > > + > > + if (musb->dyn_fifo) { > > + musb_context.index_regs[i].txfifoadd = > > + musb_read_txfifoadd(musb_base); > > + musb_context.index_regs[i].rxfifoadd = > > + musb_read_rxfifoadd(musb_base); > > + musb_context.index_regs[i].txfifosz = > > + musb_read_txfifosz(musb_base); > > + musb_context.index_regs[i].rxfifosz = > > + musb_read_rxfifosz(musb_base); > > + } > > + if (is_host_enabled(musb)) { > > + musb_context.index_regs[i].txtype = > > + musb_readb(musb_base, 0x10 + > MUSB_TXTYPE); > > + musb_context.index_regs[i].txinterval = > > + musb_readb(musb_base, 0x10 + > MUSB_TXINTERVAL); > > + musb_context.index_regs[i].rxtype = > > + musb_readb(musb_base, 0x10 + > MUSB_RXTYPE); > > + musb_context.index_regs[i].rxinterval = > > + musb_readb(musb_base, 0x10 + > MUSB_RXINTERVAL); > > + > > + musb_context.index_regs[i].txfunaddr = > > + musb_read_txfunaddr(musb_base, i); > > + musb_context.index_regs[i].txhubaddr = > > + musb_read_txhubaddr(musb_base, i); > > + musb_context.index_regs[i].txhubport = > > + musb_read_txhubport(musb_base, i); > > + > > + musb_context.index_regs[i].rxfunaddr = > > + musb_read_rxfunaddr(musb_base, i); > > + musb_context.index_regs[i].rxhubaddr = > > + musb_read_rxhubaddr(musb_base, i); > > + musb_context.index_regs[i].rxhubport = > > + musb_read_rxhubport(musb_base, i); > > + } > > + } > > + > > + musb_writeb(musb_base, MUSB_INDEX, musb_context.index); > > + > > + musb_platform_save_context(&musb_context); > > +} > > + > > +void musb_restore_context(struct musb *musb) > > +{ > > + int i; > > + void __iomem *musb_base = musb->mregs; > > + void __iomem *ep_target_regs; > > + > > + musb_platform_restore_context(&musb_context); > > + > > + if (is_host_enabled(musb)) { > > + musb_writew(musb_base, MUSB_FRAME, musb_context.frame); > > + musb_writeb(musb_base, MUSB_TESTMODE, > musb_context.testmode); > > + } > > + musb_writeb(musb_base, MUSB_POWER, musb_context.power); > > + musb_writew(musb_base, MUSB_INTRTXE, musb_context.intrtxe); > > + musb_writew(musb_base, MUSB_INTRRXE, musb_context.intrrxe); > > + musb_writeb(musb_base, MUSB_INTRUSBE, musb_context.intrusbe); > > + musb_writeb(musb_base, MUSB_DEVCTL, musb_context.devctl); > > + > > + for (i = 0; i < MUSB_C_NUM_EPS; ++i) { > > + musb_writeb(musb_base, MUSB_INDEX, i); > > + musb_writew(musb_base, 0x10 + MUSB_TXMAXP, > > + musb_context.index_regs[i].txmaxp); > > + musb_writew(musb_base, 0x10 + MUSB_TXCSR, > > + musb_context.index_regs[i].txcsr); > > + musb_writew(musb_base, 0x10 + MUSB_RXMAXP, > > + musb_context.index_regs[i].rxmaxp); > > + musb_writew(musb_base, 0x10 + MUSB_RXCSR, > > + musb_context.index_regs[i].rxcsr); > > + > > + if (musb->dyn_fifo) { > > + musb_write_txfifosz(musb_base, > > + musb_context.index_regs[i].txfifosz); > > + musb_write_rxfifosz(musb_base, > > + musb_context.index_regs[i].rxfifosz); > > + musb_write_txfifoadd(musb_base, > > + musb_context.index_regs[i].txfifoadd); > > + musb_write_rxfifoadd(musb_base, > > + musb_context.index_regs[i].rxfifoadd); > > + } > > + > > + if (is_host_enabled(musb)) { > > + musb_writeb(musb_base, 0x10 + MUSB_TXTYPE, > > + musb_context.index_regs[i].txtype); > > + musb_writeb(musb_base, 0x10 + MUSB_TXINTERVAL, > > + musb_context.index_regs[i].txinterval); > > + musb_writeb(musb_base, 0x10 + MUSB_RXTYPE, > > + musb_context.index_regs[i].rxtype); > > + musb_writeb(musb_base, 0x10 + MUSB_RXINTERVAL, > > + > > + musb_context.index_regs[i].rxinterval); > > + musb_write_txfunaddr(musb_base, i, > > + musb_context.index_regs[i].txfunaddr); > > + musb_write_txhubaddr(musb_base, i, > > + musb_context.index_regs[i].txhubaddr); > > + musb_write_txhubport(musb_base, i, > > + musb_context.index_regs[i].txhubport); > > + > > + ep_target_regs = > > + musb_read_target_reg_base(i, musb_base); > > + > > + musb_write_rxfunaddr(ep_target_regs, > > + musb_context.index_regs[i].rxfunaddr); > > + musb_write_rxhubaddr(ep_target_regs, > > + musb_context.index_regs[i].rxhubaddr); > > + musb_write_rxhubport(ep_target_regs, > > + musb_context.index_regs[i].rxhubport); > > + } > > + } > > + > > + musb_writeb(musb_base, MUSB_INDEX, musb_context.index); > > +} > > + > > static int musb_suspend(struct device *dev) > > { > > struct platform_device *pdev = to_platform_device(dev); > > unsigned long flags; > > struct musb *musb = dev_to_musb(&pdev->dev); > > + u8 reg; > > > > if (!musb->clock) > > return 0; > > @@ -2179,15 +2322,23 @@ static int musb_suspend(struct device *dev) > > spin_lock_irqsave(&musb->lock, flags); > > > > if (is_peripheral_active(musb)) { > > - /* FIXME force disconnect unless we know USB will wake > > - * the system up quickly enough to respond ... > > + /* System is entering into suspend where gadget would > not be > > + * able to respond to host and thus it will be in an > unknown > > + * state for host. Re-enumeration of gadget is required > after > > + * a resume. So we force a disconnect. > > */ > > + reg = musb_readb(musb->mregs, MUSB_POWER); > > + reg &= ~MUSB_POWER_SOFTCONN; > > + musb_writeb(musb->mregs, MUSB_POWER, reg); > > + > > } else if (is_host_active(musb)) { > > /* we know all the children are suspended; sometimes > > * they will even be wakeup-enabled. > > */ > > } > > > > + musb_save_context(musb); > > + > > if (musb->set_clock) > > musb->set_clock(musb->clock, 0); > > else > > @@ -2209,6 +2360,8 @@ static int musb_resume_noirq(struct device *dev) > > else > > clk_enable(musb->clock); > > > > + musb_restore_context(musb); > > + > > /* for static cmos like DaVinci, register values were preserved > > * unless for some reason the whole soc powered down or the USB > > * module got reset through the PSC (vs just being disabled). > > diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h > > index 969287c..38de1be 100644 > > --- a/drivers/usb/musb/musb_core.h > > +++ b/drivers/usb/musb/musb_core.h > > @@ -462,6 +462,45 @@ struct musb { > > #endif > > }; > > > > +#ifdef CONFIG_PM > > +struct musb_csr_regs { > > + /* FIFO registers */ > > + u16 txmaxp, txcsr, rxmaxp, rxcsr; > > + u16 rxfifoadd, txfifoadd; > > + u8 txtype, txinterval, rxtype, rxinterval; > > + u8 rxfifosz, txfifosz; > > + u8 txfunaddr, txhubaddr, txhubport; > > + u8 rxfunaddr, rxhubaddr, rxhubport; > > +}; > > + > > +struct musb_context_registers { > > + > > +#if defined(CONFIG_ARCH_OMAP34XX) > > + u32 otg_sysconfig, otg_forcestandby; > > +#endif > > + u8 power; > > + u16 intrtxe, intrrxe; > > + u8 intrusbe; > > + u16 frame; > > + u8 index, testmode; > > + > > + u8 devctl, misc; > > + > > + struct musb_csr_regs index_regs[MUSB_C_NUM_EPS]; > > +}; > > + > > +#if defined(CONFIG_ARCH_OMAP34XX) || defined(CONFIG_ARCH_OMAP2430) > > +extern void musb_platform_save_context(struct musb_context_registers > > + *musb_context); > > +extern void musb_platform_restore_context(struct musb_context_registers > > + *musb_context); > > +#else > > +#define musb_platform_save_context(x) do {} while (0) > > +#define musb_platform_restore_context(x) do {} while (0) > > +#endif > > + > > +#endif > > + > > static inline void musb_set_vbus(struct musb *musb, int is_on) > > { > > musb->board_set_vbus(musb, is_on); > > diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h > > index 473a94e..8ca8f23 100644 > > --- a/drivers/usb/musb/musb_regs.h > > +++ b/drivers/usb/musb/musb_regs.h > > @@ -321,6 +321,26 @@ static inline void musb_write_rxfifoadd(void > __iomem *mbase, u16 c_off) > > musb_writew(mbase, MUSB_RXFIFOADD, c_off); > > } > > > > +static inline u8 musb_read_txfifosz(void __iomem *mbase) > > +{ > > + return musb_readb(mbase, MUSB_TXFIFOSZ); > > +} > > + > > +static inline u16 musb_read_txfifoadd(void __iomem *mbase) > > +{ > > + return musb_readw(mbase, MUSB_TXFIFOADD); > > +} > > + > > +static inline u8 musb_read_rxfifosz(void __iomem *mbase) > > +{ > > + return musb_readb(mbase, MUSB_RXFIFOSZ); > > +} > > + > > +static inline u16 musb_read_rxfifoadd(void __iomem *mbase) > > +{ > > + return musb_readw(mbase, MUSB_RXFIFOADD); > > +} > > + > > static inline u8 musb_read_configdata(void __iomem *mbase) > > { > > musb_writeb(mbase, MUSB_INDEX, 0); > > @@ -376,6 +396,36 @@ static inline void musb_write_txhubport(void > __iomem *mbase, u8 epnum, > > qh_h_port_reg); > > } > > > > +static inline u8 musb_read_rxfunaddr(void __iomem *mbase, u8 epnum) > > +{ > > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, > MUSB_RXFUNCADDR)); > > +} > > + > > +static inline u8 musb_read_rxhubaddr(void __iomem *mbase, u8 epnum) > > +{ > > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, > MUSB_RXHUBADDR)); > > +} > > + > > +static inline u8 musb_read_rxhubport(void __iomem *mbase, u8 epnum) > > +{ > > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, > MUSB_RXHUBPORT)); > > +} > > + > > +static inline u8 musb_read_txfunaddr(void __iomem *mbase, u8 epnum) > > +{ > > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, > MUSB_TXFUNCADDR)); > > +} > > + > > +static inline u8 musb_read_txhubaddr(void __iomem *mbase, u8 epnum) > > +{ > > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, > MUSB_TXHUBADDR)); > > +} > > + > > +static inline u8 musb_read_txhubport(void __iomem *mbase, u8 epnum) > > +{ > > + return musb_readb(mbase, MUSB_BUSCTL_OFFSET(epnum, > MUSB_TXHUBPORT)); > > +} > > + > > #else /* CONFIG_BLACKFIN */ > > > > #define USB_BASE USB_FADDR > > @@ -455,6 +505,22 @@ static inline void musb_write_rxfifoadd(void > __iomem *mbase, u16 c_off) > > { > > } > > > > +static inline u8 musb_read_txfifosz(void __iomem *mbase) > > +{ > > +} > > + > > +static inline u16 musb_read_txfifoadd(void __iomem *mbase) > > +{ > > +} > > + > > +static inline u8 musb_read_rxfifosz(void __iomem *mbase) > > +{ > > +} > > + > > +static inline u16 musb_read_rxfifoadd(void __iomem *mbase) > > +{ > > +} > > + > > static inline u8 musb_read_configdata(void __iomem *mbase) > > { > > return 0; > > @@ -500,6 +566,30 @@ static inline void musb_write_txhubport(void > __iomem *mbase, u8 epnum, > > { > > } > > > > +static inline u8 musb_read_rxfunaddr(void __iomem *mbase, u8 epnum) > > +{ > > +} > > + > > +static inline u8 musb_read_rxhubaddr(void __iomem *mbase, u8 epnum) > > +{ > > +} > > + > > +static inline u8 musb_read_rxhubport(void __iomem *mbase, u8 epnum) > > +{ > > +} > > + > > +static inline u8 musb_read_txfunaddr(void __iomem *mbase, u8 epnum) > > +{ > > +} > > + > > +static inline u8 musb_read_txhubaddr(void __iomem *mbase, u8 epnum) > > +{ > > +} > > + > > +static inline void musb_read_txhubport(void __iomem *mbase, u8 epnum) > > +{ > > +} > > + > > #endif /* CONFIG_BLACKFIN */ > > > > #endif /* __MUSB_REGS_H__ */ > > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c > > index 83beeac..15a3f27 100644 > > --- a/drivers/usb/musb/omap2430.c > > +++ b/drivers/usb/musb/omap2430.c > > @@ -255,6 +255,22 @@ int __init musb_platform_init(struct musb *musb) > > return 0; > > } > > > > +#ifdef CONFIG_PM > > +void musb_platform_save_context(struct musb_context_registers > > + *musb_context) > > +{ > > + musb_context->otg_sysconfig = omap_readl(OTG_SYSCONFIG); > > + musb_context->otg_forcestandby = omap_readl(OTG_FORCESTDBY); > > +} > > + > > +void musb_platform_restore_context(struct musb_context_registers > > + *musb_context) > > +{ > > + omap_writel(musb_context->otg_sysconfig, OTG_SYSCONFIG); > > + omap_writel(musb_context->otg_forcestandby, OTG_FORCESTDBY); > > +} > > +#endif > > + > > int musb_platform_suspend(struct musb *musb) > > { > > u32 l; > > -- > > 1.6.2.4 > > > > -- > > 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <19F8576C6E063C45BE387C64729E73940449F439C7-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <19F8576C6E063C45BE387C64729E73940449F439C7-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2009-12-17 14:10 ` Arnaud Mandy [not found] ` <4B2A3BEE.7000809-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Arnaud Mandy @ 2009-12-17 14:10 UTC (permalink / raw) To: ext Gupta, Ajay Kumar Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbi Felipe (Nokia-D/Helsinki), david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org, Gadiyar, Anand ext Gupta, Ajay Kumar wrote: > <snip> > >>> #ifdef CONFIG_PM >>> >>> +static struct musb_context_registers musb_context; >>> + >>> +void musb_save_context(struct musb *musb) >>> +{ >>> >>> >> Could you add one more parameter to this function call, which would >> select either if we want to save the musb_platform context or not? >> I m working at the moment on turning off the musb when cable unplugged >> and turning it on with restoring context after cable re-connect. >> In this case I don't need to restore the the musb_platform_context since >> I just set them before calling this one. >> >> Same apply for restore. >> >> what do you think? >> I could also modify slightly this implementation after it is ready and >> submit it. >> > > I think you want to add the parameter in musb_platform_save_context() and > not in musb_save_context. > If so then where do you restore them? {As you said before calling this} > In order to support off-mode, we need the transceiver driver to wake-up the controller. I m working on a hook which would allow that. I want to take advantage of your implementation for saving/restoring musb context, but saving the platform data is not necessary in my case. Maybe it musb_platform_save/restore_context(), shouldn't be called from musb_save/restore_context(); > I think if the requirement is generic and suits for all other platforms > Using musb then we can add it. > Yes it should. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <4B2A3BEE.7000809-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>]
* RE: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <4B2A3BEE.7000809-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> @ 2009-12-17 14:16 ` Gupta, Ajay Kumar [not found] ` <19F8576C6E063C45BE387C64729E73940449F439D9-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-17 14:16 UTC (permalink / raw) To: Arnaud Mandy Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbi Felipe (Nokia-D/Helsinki), david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org, Gadiyar, Anand > -----Original Message----- > From: Arnaud Mandy [mailto:ext-arnaud.2.mandy-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org] > Sent: Thursday, December 17, 2009 7:41 PM > To: Gupta, Ajay Kumar > Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Balbi Felipe > (Nokia-D/Helsinki); david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org; Gadiyar, Anand > Subject: Re: [PATCH 2/3 v3] musb: Add context save and restore support > > ext Gupta, Ajay Kumar wrote: > > <snip> > > > >>> #ifdef CONFIG_PM > >>> > >>> +static struct musb_context_registers musb_context; > >>> + > >>> +void musb_save_context(struct musb *musb) > >>> +{ > >>> > >>> > >> Could you add one more parameter to this function call, which would > >> select either if we want to save the musb_platform context or not? > >> I m working at the moment on turning off the musb when cable unplugged > >> and turning it on with restoring context after cable re-connect. > >> In this case I don't need to restore the the musb_platform_context > since > >> I just set them before calling this one. > >> > >> Same apply for restore. > >> > >> what do you think? > >> I could also modify slightly this implementation after it is ready and > >> submit it. > >> > > > > I think you want to add the parameter in musb_platform_save_context() > and > > not in musb_save_context. > > If so then where do you restore them? {As you said before calling this} > > > > In order to support off-mode, we need the transceiver driver to wake-up > the controller. > I m working on a hook which would allow that. > I want to take advantage of your implementation for saving/restoring > musb context, but saving the platform data is not necessary in my case. Then how about having a platform specific flag within musb_platform_save/restorae_context() implementation which wouldn't save/restore when you don't need them. > Maybe it musb_platform_save/restore_context(), shouldn't be called from > musb_save/restore_context(); > > > I think if the requirement is generic and suits for all other platforms > > Using musb then we can add it. > > > > Yes it should. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <19F8576C6E063C45BE387C64729E73940449F439D9-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <19F8576C6E063C45BE387C64729E73940449F439D9-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2009-12-17 15:17 ` Arnaud Mandy [not found] ` <4B2A4BA6.9010804-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Arnaud Mandy @ 2009-12-17 15:17 UTC (permalink / raw) To: ext Gupta, Ajay Kumar Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbi Felipe (Nokia-D/Helsinki), david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org, Gadiyar, Anand ext Gupta, Ajay Kumar wrote: >> -----Original Message----- >> From: Arnaud Mandy [mailto:ext-arnaud.2.mandy-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org] >> Sent: Thursday, December 17, 2009 7:41 PM >> To: Gupta, Ajay Kumar >> Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Balbi Felipe >> (Nokia-D/Helsinki); david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org; Gadiyar, Anand >> Subject: Re: [PATCH 2/3 v3] musb: Add context save and restore support >> >> ext Gupta, Ajay Kumar wrote: >> >>> <snip> >>> >>> >>>>> #ifdef CONFIG_PM >>>>> >>>>> +static struct musb_context_registers musb_context; >>>>> + >>>>> +void musb_save_context(struct musb *musb) >>>>> +{ >>>>> >>>>> >>>>> >>>> Could you add one more parameter to this function call, which would >>>> select either if we want to save the musb_platform context or not? >>>> I m working at the moment on turning off the musb when cable unplugged >>>> and turning it on with restoring context after cable re-connect. >>>> In this case I don't need to restore the the musb_platform_context >>>> >> since >> >>>> I just set them before calling this one. >>>> >>>> Same apply for restore. >>>> >>>> what do you think? >>>> I could also modify slightly this implementation after it is ready and >>>> submit it. >>>> >>>> >>> I think you want to add the parameter in musb_platform_save_context() >>> >> and >> >>> not in musb_save_context. >>> If so then where do you restore them? {As you said before calling this} >>> >>> >> In order to support off-mode, we need the transceiver driver to wake-up >> the controller. >> I m working on a hook which would allow that. >> I want to take advantage of your implementation for saving/restoring >> musb context, but saving the platform data is not necessary in my case. >> > > Then how about having a platform specific flag within > musb_platform_save/restorae_context() implementation which wouldn't > save/restore when you don't need them. > > I got your point, but how would this flag being passed into musb_save_context()? As a new musb struct member? > >> Maybe it musb_platform_save/restore_context(), shouldn't be called from >> musb_save/restore_context(); >> >> >>> I think if the requirement is generic and suits for all other platforms >>> Using musb then we can add it. >>> >>> >> Yes it should. >> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <4B2A4BA6.9010804-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>]
* RE: [PATCH 2/3 v3] musb: Add context save and restore support [not found] ` <4B2A4BA6.9010804-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> @ 2009-12-18 4:17 ` Gupta, Ajay Kumar 0 siblings, 0 replies; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-18 4:17 UTC (permalink / raw) To: Arnaud Mandy Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbi Felipe (Nokia-D/Helsinki), david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org, Gadiyar, Anand > >> In order to support off-mode, we need the transceiver driver to wake-up > >> the controller. > >> I m working on a hook which would allow that. > >> I want to take advantage of your implementation for saving/restoring > >> musb context, but saving the platform data is not necessary in my case. > >> > > > > Then how about having a platform specific flag within > > musb_platform_save/restorae_context() implementation which wouldn't > > save/restore when you don't need them. > > > > > > I got your point, but how would this flag being passed into > musb_save_context()? > As a new musb struct member? yes, from musb only and in that case we need to add another parameter to musb_platform_save/restore_context as you suggested. Once your testing is completed then you can submit a separate patch on this? Or if already done then we can update the current one before it is sent to Greg. -Ajay > > > > >> Maybe it musb_platform_save/restore_context(), shouldn't be called from > >> musb_save/restore_context(); > >> > >> > >>> I think if the requirement is generic and suits for all other > platforms > >>> Using musb then we can add it. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 1/3] musb: save dynfifo in musb struct [not found] ` <1260797982-28880-1-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org> 2009-12-14 13:39 ` [PATCH 2/3 v3] musb: Add context save and restore support Ajay Kumar Gupta @ 2009-12-14 16:24 ` Felipe Balbi 2009-12-15 4:04 ` Gupta, Ajay Kumar 1 sibling, 1 reply; 26+ messages in thread From: Felipe Balbi @ 2009-12-14 16:24 UTC (permalink / raw) To: ext Ajay Kumar Gupta Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Balbi Felipe (Nokia-D/Helsinki), david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org Hi, On Mon, Dec 14, 2009 at 02:39:40PM +0100, ext Ajay Kumar Gupta wrote: >Save dynamic FIFO read only information for later uses such as, during >musb_save/restore_context functions. > >Signed-off-by: Ajay Kumar Gupta <ajay.gupta-l0cyMroinI0@public.gmane.org> NAK >--- > drivers/usb/musb/musb_core.c | 4 +++- > drivers/usb/musb/musb_core.h | 1 + > 2 files changed, 4 insertions(+), 1 deletions(-) > >diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c >index 49f2346..d4adbbf 100644 >--- a/drivers/usb/musb/musb_core.c >+++ b/drivers/usb/musb/musb_core.c >@@ -1328,8 +1328,10 @@ static int __init musb_core_init(u16 musb_type, struct musb *musb) > reg = musb_read_configdata(mbase); > > strcpy(aInfo, (reg & MUSB_CONFIGDATA_UTMIDW) ? "UTMI-16" : "UTMI-8"); >- if (reg & MUSB_CONFIGDATA_DYNFIFO) >+ if (reg & MUSB_CONFIGDATA_DYNFIFO) { > strcat(aInfo, ", dyn FIFOs"); >+ musb->dyn_fifo = true; we have this inside struct musb_hdrc_config. This is duplicating that. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH 1/3] musb: save dynfifo in musb struct 2009-12-14 16:24 ` [PATCH 1/3] musb: save dynfifo in musb struct Felipe Balbi @ 2009-12-15 4:04 ` Gupta, Ajay Kumar [not found] ` <19F8576C6E063C45BE387C64729E739404372AAD03-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-15 4:04 UTC (permalink / raw) To: felipe.balbi@nokia.com Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, david-b@pacbell.net > -----Original Message----- > From: Felipe Balbi [mailto:felipe.balbi@nokia.com] > Sent: Monday, December 14, 2009 9:55 PM > To: Gupta, Ajay Kumar > Cc: linux-usb@vger.kernel.org; linux-omap@vger.kernel.org; Balbi Felipe > (Nokia-D/Helsinki); david-b@pacbell.net > Subject: Re: [PATCH 1/3] musb: save dynfifo in musb struct > > Hi, > > On Mon, Dec 14, 2009 at 02:39:40PM +0100, ext Ajay Kumar Gupta wrote: > >Save dynamic FIFO read only information for later uses such as, during > >musb_save/restore_context functions. > > > >Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> > > NAK > > >--- > > drivers/usb/musb/musb_core.c | 4 +++- > > drivers/usb/musb/musb_core.h | 1 + > > 2 files changed, 4 insertions(+), 1 deletions(-) > > > >diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > >index 49f2346..d4adbbf 100644 > >--- a/drivers/usb/musb/musb_core.c > >+++ b/drivers/usb/musb/musb_core.c > >@@ -1328,8 +1328,10 @@ static int __init musb_core_init(u16 musb_type, > struct musb *musb) > > reg = musb_read_configdata(mbase); > > > > strcpy(aInfo, (reg & MUSB_CONFIGDATA_UTMIDW) ? "UTMI-16" : "UTMI- > 8"); > >- if (reg & MUSB_CONFIGDATA_DYNFIFO) > >+ if (reg & MUSB_CONFIGDATA_DYNFIFO) { > > strcat(aInfo, ", dyn FIFOs"); > >+ musb->dyn_fifo = true; > > we have this inside struct musb_hdrc_config. > This is duplicating that. musb->config->dyn_fifo is coming from platform files and is user defined but we need to check if the mentor core itself supports dynamic fifo. See the dynamic fifo code snippet: -------------------------------------------------------- if (reg & MUSB_CONFIGDATA_DYNFIFO) { if (musb->config->dyn_fifo) status = ep_config_from_table(musb); else { ERR("reconfigure software for Dynamic FIFOs\n"); status = -ENODEV; } } else { -------------------------------------------------------- If CONFIGDATA register bit indicates that dynamic FIFO is supported then musb->config->dyn_fifo has to be set to '1' for suceessful initialization. Thus CONFIGDATA register bit alone is sufficient condition to save/restore Tx/Rx FIFOSZ/FIFOADDR registers. -Ajay > > -- > balbi ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <19F8576C6E063C45BE387C64729E739404372AAD03-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [PATCH 1/3] musb: save dynfifo in musb struct [not found] ` <19F8576C6E063C45BE387C64729E739404372AAD03-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2009-12-15 7:26 ` Felipe Balbi 2009-12-15 7:37 ` Gupta, Ajay Kumar 0 siblings, 1 reply; 26+ messages in thread From: Felipe Balbi @ 2009-12-15 7:26 UTC (permalink / raw) To: ext Gupta, Ajay Kumar Cc: Balbi Felipe (Nokia-D/Helsinki), linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org Hi, On Tue, Dec 15, 2009 at 05:04:30AM +0100, ext Gupta, Ajay Kumar wrote: >musb->config->dyn_fifo is coming from platform files and is user defined >but we need to check if the mentor core itself supports dynamic fifo. > >See the dynamic fifo code snippet: > >-------------------------------------------------------- > if (reg & MUSB_CONFIGDATA_DYNFIFO) { > if (musb->config->dyn_fifo) > status = ep_config_from_table(musb); > else { > ERR("reconfigure software for Dynamic FIFOs\n"); > status = -ENODEV; > } > } else { >-------------------------------------------------------- > >If CONFIGDATA register bit indicates that dynamic FIFO is supported then >musb->config->dyn_fifo has to be set to '1' for suceessful initialization. > >Thus CONFIGDATA register bit alone is sufficient condition to save/restore >Tx/Rx FIFOSZ/FIFOADDR registers. yes, but if the user has to reconfigure the sw for dyn_fifo anyways, so we can be sure musb->config->dyn_fifo is correct when you need. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH 1/3] musb: save dynfifo in musb struct 2009-12-15 7:26 ` Felipe Balbi @ 2009-12-15 7:37 ` Gupta, Ajay Kumar [not found] ` <19F8576C6E063C45BE387C64729E739404372AAE01-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-15 7:37 UTC (permalink / raw) To: felipe.balbi@nokia.com Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, david-b@pacbell.net > -----Original Message----- > From: Felipe Balbi [mailto:felipe.balbi@nokia.com] > Sent: Tuesday, December 15, 2009 12:57 PM > To: Gupta, Ajay Kumar > Cc: Balbi Felipe (Nokia-D/Helsinki); linux-usb@vger.kernel.org; linux- > omap@vger.kernel.org; david-b@pacbell.net > Subject: Re: [PATCH 1/3] musb: save dynfifo in musb struct > > Hi, > > On Tue, Dec 15, 2009 at 05:04:30AM +0100, ext Gupta, Ajay Kumar wrote: > >musb->config->dyn_fifo is coming from platform files and is user defined > >but we need to check if the mentor core itself supports dynamic fifo. > > > >See the dynamic fifo code snippet: > > > >-------------------------------------------------------- > > if (reg & MUSB_CONFIGDATA_DYNFIFO) { > > if (musb->config->dyn_fifo) > > status = ep_config_from_table(musb); > > else { > > ERR("reconfigure software for Dynamic FIFOs\n"); > > status = -ENODEV; > > } > > } else { > >-------------------------------------------------------- > > > >If CONFIGDATA register bit indicates that dynamic FIFO is supported then > >musb->config->dyn_fifo has to be set to '1' for suceessful > initialization. > > > >Thus CONFIGDATA register bit alone is sufficient condition to > save/restore > >Tx/Rx FIFOSZ/FIFOADDR registers. > > yes, but if the user has to reconfigure the sw for dyn_fifo anyways, so > we can be sure musb->config->dyn_fifo is correct when you need. As per current logic, user has to set dyn_fifo if mentor core supports it and it has to be set to '0' if core doesn't support it. So what's the need for musb->config->dyn_fifo at all. We can very well decide based on only CONFIGDATA register bits alone. I think we should just get rid of this unwanted user defined flag. I will post a patch on this along with next revision. -Ajay > > -- > balbi ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <19F8576C6E063C45BE387C64729E739404372AAE01-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [PATCH 1/3] musb: save dynfifo in musb struct [not found] ` <19F8576C6E063C45BE387C64729E739404372AAE01-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2009-12-15 7:40 ` Felipe Balbi [not found] ` <20091215074025.GB3147-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 26+ messages in thread From: Felipe Balbi @ 2009-12-15 7:40 UTC (permalink / raw) To: ext Gupta, Ajay Kumar Cc: Balbi Felipe (Nokia-D/Helsinki), linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org Hi, On Tue, Dec 15, 2009 at 08:37:38AM +0100, ext Gupta, Ajay Kumar wrote: >As per current logic, user has to set dyn_fifo if mentor core supports it >and it has to be set to '0' if core doesn't support it. So what's the need >for musb->config->dyn_fifo at all. We can very well decide based on only >CONFIGDATA register bits alone. > >I think we should just get rid of this unwanted user defined flag. I will >post a patch on this along with next revision. aaa ok, now I get what you're saying. You're suggesting to drop musb->config->dyn_fifo and decide ep_config_from_table() or ep_config_from_hw() based on CONFIGDATA. Ok, makes sense. But first remove that before saving dyn_fifo on musb structure. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <20091215074025.GB3147-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>]
* RE: [PATCH 1/3] musb: save dynfifo in musb struct [not found] ` <20091215074025.GB3147-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org> @ 2009-12-15 7:44 ` Gupta, Ajay Kumar 2009-12-15 8:32 ` Felipe Balbi 0 siblings, 1 reply; 26+ messages in thread From: Gupta, Ajay Kumar @ 2009-12-15 7:44 UTC (permalink / raw) To: felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > -----Original Message----- > From: Felipe Balbi [mailto:felipe.balbi-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org] > Sent: Tuesday, December 15, 2009 1:10 PM > To: Gupta, Ajay Kumar > Cc: Balbi Felipe (Nokia-D/Helsinki); linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux- > omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org > Subject: Re: [PATCH 1/3] musb: save dynfifo in musb struct > > Hi, > > On Tue, Dec 15, 2009 at 08:37:38AM +0100, ext Gupta, Ajay Kumar wrote: > >As per current logic, user has to set dyn_fifo if mentor core supports it > >and it has to be set to '0' if core doesn't support it. So what's the > need > >for musb->config->dyn_fifo at all. We can very well decide based on only > >CONFIGDATA register bits alone. > > > >I think we should just get rid of this unwanted user defined flag. I will > >post a patch on this along with next revision. > > aaa ok, now I get what you're saying. > > You're suggesting to drop musb->config->dyn_fifo and decide > ep_config_from_table() or ep_config_from_hw() based on CONFIGDATA. > > Ok, makes sense. But first remove that before saving dyn_fifo on musb > structure. Another point, BlackFin doesn't have CONFIGDATA register and it always Returns '0' from it's custom function musb_read_configdata(). As it returns '0' and also BlackFin doesn't support Dynamic FIFO so Should be fine. Any comment ? -Ajay > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH 1/3] musb: save dynfifo in musb struct 2009-12-15 7:44 ` Gupta, Ajay Kumar @ 2009-12-15 8:32 ` Felipe Balbi 0 siblings, 0 replies; 26+ messages in thread From: Felipe Balbi @ 2009-12-15 8:32 UTC (permalink / raw) To: ext Gupta, Ajay Kumar Cc: Balbi Felipe (Nokia-D/Helsinki), linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, david-b@pacbell.net Hi, On Tue, Dec 15, 2009 at 08:44:56AM +0100, ext Gupta, Ajay Kumar wrote: >Another point, BlackFin doesn't have CONFIGDATA register and it always >Returns '0' from it's custom function musb_read_configdata(). > >As it returns '0' and also BlackFin doesn't support Dynamic FIFO so >Should be fine. > >Any comment ? yeah, should be fine. -- balbi ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2009-12-18 4:17 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-14 13:39 [PATCH 1/3] musb: save dynfifo in musb struct Ajay Kumar Gupta
[not found] ` <1260797982-28880-1-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org>
2009-12-14 13:39 ` [PATCH 2/3 v3] musb: Add context save and restore support Ajay Kumar Gupta
2009-12-14 13:39 ` [PATCH 3/3] musb: Add 'extvbus' in musb_hdrc_platform_data Ajay Kumar Gupta
2009-12-14 16:37 ` Felipe Balbi
[not found] ` <20091214163746.GC31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
2009-12-15 4:07 ` Gupta, Ajay Kumar
[not found] ` <1260797982-28880-2-git-send-email-ajay.gupta-l0cyMroinI0@public.gmane.org>
2009-12-14 16:33 ` [PATCH 2/3 v3] musb: Add context save and restore support Felipe Balbi
2009-12-14 16:39 ` Felipe Balbi
[not found] ` <20091214163324.GB31829-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
2009-12-15 11:44 ` Gupta, Ajay Kumar
[not found] ` <19F8576C6E063C45BE387C64729E739404372AAF0F-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2009-12-15 12:04 ` Gadiyar, Anand
[not found] ` <5A47E75E594F054BAF48C5E4FC4B92AB030ADD53A6-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2009-12-15 12:10 ` Felipe Balbi
[not found] ` <20091215121032.GH3689-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
2009-12-15 12:36 ` Gupta, Ajay Kumar
[not found] ` <19F8576C6E063C45BE387C64729E739404372AAF44-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2009-12-15 12:39 ` Gupta, Ajay Kumar
2009-12-15 12:48 ` Felipe Balbi
2009-12-17 13:38 ` Arnaud Mandy
2009-12-17 13:51 ` Gupta, Ajay Kumar
[not found] ` <19F8576C6E063C45BE387C64729E73940449F439C7-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2009-12-17 14:10 ` Arnaud Mandy
[not found] ` <4B2A3BEE.7000809-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
2009-12-17 14:16 ` Gupta, Ajay Kumar
[not found] ` <19F8576C6E063C45BE387C64729E73940449F439D9-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2009-12-17 15:17 ` Arnaud Mandy
[not found] ` <4B2A4BA6.9010804-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
2009-12-18 4:17 ` Gupta, Ajay Kumar
2009-12-14 16:24 ` [PATCH 1/3] musb: save dynfifo in musb struct Felipe Balbi
2009-12-15 4:04 ` Gupta, Ajay Kumar
[not found] ` <19F8576C6E063C45BE387C64729E739404372AAD03-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2009-12-15 7:26 ` Felipe Balbi
2009-12-15 7:37 ` Gupta, Ajay Kumar
[not found] ` <19F8576C6E063C45BE387C64729E739404372AAE01-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2009-12-15 7:40 ` Felipe Balbi
[not found] ` <20091215074025.GB3147-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
2009-12-15 7:44 ` Gupta, Ajay Kumar
2009-12-15 8:32 ` Felipe Balbi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox