Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
Richard == Richard Cochran richardcoch...@gmail.com writes: Hi, As Peter Korsgaard mentioned we need to have infrastructure to handle CPSW kind of hardware. Richard This will be a big job, I think, but I agree that it is worth doing. Richard I can think of one other switch-with-host-port device. Maybe Richard we should start off by making a list of actual products and Richard their capabilities, in order to get an overall idea of what we Richard would need to develop. Next to the dsa stuff with external switches, I can think of 3 other devices off the top of my head: Freescale imx287: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX287 Freescale T1022: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=T1020 Ralink RT3502: http://www.netcheif.com/Reviews/VigorFly200/PDF/RT3052-product%20brief.pdf -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. Somehow, I feel this is almost a nitpick, so don't take this too seriously. Regards, -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: drop select MACH_NOKIA_RM696
On Sat, 2013-03-09 at 00:01 +, Russell King - ARM Linux wrote:
It's actually quite clever. There's two levels to it.
The first is that CONFIG_MACH_xxx result in their machine_is_xxx() macros
being defined to constant zero if the CONFIG option is not enabled. That
allows the compiler to throw away code for disabled platforms because
the expression is always false.
Otherwise, they end up as (machine_arch_type == MACH_TYPE_xxx).
The second is the magic which happens when two CONFIG_MACH_xxx are
selected. If only one is selected, then machine_arch_type is defined
to the appropriate MACH_TYPE_xxx. This means that the above expression
becomes constant-true, and the conditional is eliminated.
If more than one is selected, then machine_arch_type is defined to a
variable which is appropriately set to one of the MACH_TYPE_xxx values.
At boot?
So, the result is that:
- de-selected platforms have their if (machine_is_xxx()) { } optimised
out of the kernel.
- for a kernel built targetting one platform, all the
if (machine_is_xxx()) tests are optimised away, leaving only the
relevant code behind.
- otherwise, we get the _appropriate_ conditional code for the
configuration generated.
Thanks for clarifying this. Quite clever indeed.
However, going back to that MACH_NOKIA_RM696. If there exists only a
select of this symbol and no config MACH_NOKIA_RM696 entry, then the
symbol will never be generated in the output .config file.
[...]
My conclusion is... it's a mess.
That mess can only be fully cleaned up if the code for the RM-696 that
now is maintained in some unknown to me repository gets merged into
mainline, can't it?
In the meantime, how do you prefer I solve the (trivial) issue of an
useless select for MACH_NOKIA_RM696? Drop that select or add an (equally
useless) config entry for MACH_NOKIA_RM696? Or should I try to ignore it
for the time being?
Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: hwmod data: disable MIDLEMODE control for musb
For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than force
standby before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and force standby is restored before
suspend attempt.
Keeping the register set at force standby (reset value) makes it work
and device still functions properly. musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal, so perhaps
MIDLEMODE is not even needed? Note that TI PSP kernels also have
similar workarounds.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ac7e03e..0388bba 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1666,11 +1666,15 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_usbhsotg_sysc = {
.rev_offs = 0x0400,
.sysc_offs = 0x0404,
.syss_offs = 0x0408,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
- SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ /*
+* musb has MMIDLEMODE, but if we ever enable the device not in force
+* idle mode, core_pwrdm does not enter idle states at least on 36xx.
+* Note that musb also has OTG_FORCESTDBY register that the driver
+* uses to control MSTANDBY signal manually.
+*/
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: musb: honour initial transceiver state
As the OTG transceiver driver usually starts first, it should already
have default_a variable set according to ID pin state, so don't
override it. In case default_a was not changed by trasceiver, it will
default to 0 and this code will work as before.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/musb/musb_core.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 60b41cc..f95404e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1955,9 +1955,13 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb_write_ulpi_buscontrol(musb-mregs, busctl);
}
- MUSB_DEV_MODE(musb);
- musb-xceiv-otg-default_a = 0;
- musb-xceiv-state = OTG_STATE_B_IDLE;
+ if (musb-xceiv-otg-default_a) {
+ MUSB_HST_MODE(musb);
+ musb-xceiv-state = OTG_STATE_A_IDLE;
+ } else {
+ MUSB_DEV_MODE(musb);
+ musb-xceiv-state = OTG_STATE_B_IDLE;
+ }
status = musb_gadget_setup(musb);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: musb: gadget: clear gadget_driver when gadget is stopped
Some musb glue drivers use gadget_driver pointer to know if any gadget drivers are loaded at some moment and base further decisions on it, like to do runtime suspend/resume or not. Right now the pointer is left alone on stop and OMAP musb glue later does wrong runtime_pm decisions because of it. Clear the gadget_driver pointer on remove, it's invalid after stop anyway. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- drivers/usb/musb/musb_gadget.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 19998e9..1ddb889 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -2057,6 +2057,7 @@ static int musb_gadget_stop(struct usb_gadget *g, dev_dbg(musb-controller, unregistering driver %s\n, driver-function); musb-is_active = 0; + musb-gadget_driver = NULL; musb_platform_try_idle(musb, 0); spin_unlock_irqrestore(musb-lock, flags); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: musb: log VBUS error
VBUS_ERROR is a serious error that the driver often doesn't recover from
in my tests, so we should at least inform the user about it.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/musb/musb_core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f95404e..df6a54e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
break;
}
- dev_dbg(musb-controller, VBUS_ERROR in %s (%02x, %s), retry
#%d, port1 %08x\n,
+ dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb-controller,
+ VBUS_ERROR in %s (%02x, %s), retry #%d, port1
%08x\n,
otg_state_string(musb-xceiv-state),
devctl,
({ char *s;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] usb: otg: twl4030-usb fixes
I have a pandora board which has similar musb setup to beagleboard (OMAP3530 + TWL4030) and musb never worked well on it for me in mainline. Well it usually works if you plug the cable once, but as soon as you start replugging cables and mixing host adapter into the game it totally breaks and reboot is then needed. Host mode is especially broken, any replugs after musb has been in host mode result in dead port that needs reboot to recover. With this series I can switch host/peripheral cables any way I like and even suspend works with cable plugged with musb in peripheral mode! (ARM: OMAP3: hwmod data: disable MIDLEMODE control for musb is needed that was sent separately). This also fixes power drain when cable is plugged an no gadget driver is loaded. Grazvydas Ignotas (7): usb: otg: twl4030-usb: don't enable PHY during init usb: otg: twl4030-usb: ignore duplicate events usb: otg: twl4030-usb: don't switch the phy on/off needlessly usb: otg: twl4030-usb: poll for ID disconnect usb: otg: twl4030-usb: check if vbus is driven by twl itself usb: musb: omap2430: turn off vbus on cable disconnect usb: musb: gadget: use platform callback to enable vbus drivers/usb/musb/musb_gadget.c |5 +- drivers/usb/musb/omap2430.c|1 + drivers/usb/otg/twl4030-usb.c | 105 ++-- 3 files changed, 82 insertions(+), 29 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] usb: otg: twl4030-usb: ignore duplicate events
In some rare cases we may get multiple interrupts that will generate
duplicate omap_musb_mailbox() calls. This is a problem because each
VBUS/ID event generates runtime_pm call in OMAP glue code, causing
unbalanced gets or puts and breaking PM.
The same goes for initial state, glue already defaults to no cable
state, so only bother it if we have VBUS or ID.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/otg/twl4030-usb.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 1515c0b..0ea576a 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -491,9 +491,10 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
{
struct twl4030_usb *twl = _twl;
enum omap_musb_vbus_id_status status;
+ enum omap_musb_vbus_id_status status_prev = twl-linkstat;
status = twl4030_usb_linkstat(twl);
- if (status 0) {
+ if (status 0 status != status_prev) {
/* FIXME add a set_power() method so that B-devices can
* configure the charger appropriately. It's not always
* correct to consume VBUS power, and how much current to
@@ -530,7 +531,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
twl-asleep = 1;
status = twl4030_usb_linkstat(twl);
- if (status 0)
+ if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
omap_musb_mailbox(twl-linkstat);
sysfs_notify(twl-dev-kobj, NULL, vbus);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] usb: otg: twl4030-usb: don't switch the phy on/off needlessly
With runtime_pm in place there is no longer need to turn the phy on/off in OTG layer on cable connect/disconnect, OMAP glue does this through otg.set_suspend() callback after it's called through omap_musb_mailbox() on VBUS/ID interrupt. Not doing this will save power when cable is connected but no gadget driver is loaded. This will also have side effect of automatic USB charging no longer working without twl4030_charger driver, so be sure to enable it if charging is needed. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- drivers/usb/otg/twl4030-usb.c |6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 0ea576a..90a19ff 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c @@ -506,12 +506,6 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) * USB_LINK_VBUS state. musb_hdrc won't care until it * starts to handle softconnect right. */ - if (status == OMAP_MUSB_VBUS_OFF || - status == OMAP_MUSB_ID_FLOAT) - twl4030_phy_suspend(twl, 0); - else - twl4030_phy_resume(twl); - omap_musb_mailbox(twl-linkstat); } sysfs_notify(twl-dev-kobj, NULL, vbus); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] usb: otg: twl4030-usb: check if vbus is driven by twl itself
At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 2c1c27e..8f0d6cf 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -248,11 +248,31 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg,
u8 bits)
/*-*/
+static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
+{
+ int ret;
+
+ ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
+ if (ret 0 || !(ret PHY_DPLL_CLK))
+ /*
+* if clocks are off, registers are not updated,
+* but we can assume we don't drive VBUS in this case
+*/
+ return false;
+
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0)
+ return false;
+
+ return (ret (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
+}
+
static enum omap_musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
{
int status;
enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
+ booldriving_vbus = false;
twl-vbus_supplied = false;
@@ -270,20 +290,26 @@ static enum omap_musb_vbus_id_status
if (status 0)
dev_err(twl-dev, USB link status err %d\n, status);
else if (status (BIT(7) | BIT(2))) {
- if (status (BIT(7)))
-twl-vbus_supplied = true;
+ if (status BIT(7)) {
+ driving_vbus = twl4030_is_driving_vbus(twl);
+ if (driving_vbus)
+ status = ~BIT(7);
+ }
if (status BIT(2))
linkstat = OMAP_MUSB_ID_GROUND;
- else
+ else if (status BIT(7)) {
linkstat = OMAP_MUSB_VBUS_VALID;
+ twl-vbus_supplied = true;
+ } else
+ linkstat = OMAP_MUSB_VBUS_OFF;
} else {
if (twl-linkstat != OMAP_MUSB_UNKNOWN)
linkstat = OMAP_MUSB_VBUS_OFF;
}
- dev_dbg(twl-dev, HW_CONDITIONS 0x%02x/%d; link %d\n,
- status, status, linkstat);
+ dev_dbg(twl-dev, HW_CONDITIONS 0x%02x; link %d, driving_vbus %d\n,
+ status, linkstat, driving_vbus);
/* REVISIT this assumes host and peripheral controllers
* are registered, and that both are active...
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] usb: otg: twl4030-usb: poll for ID disconnect
On pandora, STS_USB interrupt doesn't arrive on USB host cable disconnect
for some reason while VBUS is driven by twl itself, but STS_HW_CONDITIONS
is updated correctly. It does work fine when PHY is powered down though.
To work around that we have to poll.
TI PSP kernels have similar workarounds, so (many?) more boards are likely
affected.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 90a19ff..2c1c27e 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -163,6 +163,8 @@ struct twl4030_usb {
boolvbus_supplied;
u8 asleep;
boolirq_enabled;
+
+ struct delayed_work id_workaround_work;
};
/* internal define on top of container_of */
@@ -412,6 +414,16 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
__twl4030_phy_resume(twl);
twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
+
+ /*
+* XXX When VBUS gets driven after musb goes to A mode,
+* ID_PRES related interrupts no longer arrive, why?
+* Register itself is updated fine though, so we must poll.
+*/
+ if (twl-linkstat == OMAP_MUSB_ID_GROUND) {
+ cancel_delayed_work(twl-id_workaround_work);
+ schedule_delayed_work(twl-id_workaround_work, HZ);
+ }
}
static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
@@ -513,6 +525,28 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
return IRQ_HANDLED;
}
+static void twl4030_id_workaround_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work, struct twl4030_usb,
+ id_workaround_work.work);
+ enum omap_musb_vbus_id_status status_prev = twl-linkstat;
+ enum omap_musb_vbus_id_status status;
+
+ status = twl4030_usb_linkstat(twl);
+ if (status != status_prev) {
+ dev_dbg(twl-dev, handle missing status change: %d-%d\n,
+ status_prev, status);
+ twl-linkstat = status_prev;
+ twl4030_usb_irq(0, twl);
+ }
+
+ /* don't schedule during sleep - irq works right then */
+ if (status == OMAP_MUSB_ID_GROUND !twl-asleep) {
+ cancel_delayed_work(twl-id_workaround_work);
+ schedule_delayed_work(twl-id_workaround_work, HZ);
+ }
+}
+
static void twl4030_usb_phy_init(struct twl4030_usb *twl)
{
enum omap_musb_vbus_id_status status;
@@ -613,6 +647,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
+ INIT_DELAYED_WORK(twl-id_workaround_work, twl4030_id_workaround_work);
+
err = twl4030_usb_ldo_init(twl);
if (err) {
dev_err(pdev-dev, ldo init failed\n);
@@ -653,6 +689,7 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
struct twl4030_usb *twl = platform_get_drvdata(pdev);
int val;
+ cancel_delayed_work(twl-id_workaround_work);
free_irq(twl-irq, twl);
device_remove_file(twl-dev, dev_attr_vbus);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] usb: musb: omap2430: turn off vbus on cable disconnect
On USB_EVENT_ID event the musb glue enables VBUS by calling
omap2430_musb_set_vbus(musb, 1) that sets the session bit, but on
USB_EVENT_NONE reverse action is never made, and that breaks PM.
Disable VBUS unconditionally on USB_EVENT_NONE to be sure musb
session is ended on cable unplug so that PM works.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/musb/omap2430.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a39c11..d430677 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -296,6 +296,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
pm_runtime_put_autosuspend(dev);
}
+ omap2430_musb_set_vbus(musb, 0);
if (data-interface_type == MUSB_INTERFACE_UTMI) {
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] usb: musb: gadget: use platform callback to enable vbus
On some platform configurations (like OMAP3+twl4030) it's the platform code that enables VBUS, not OTG transceiver, so call vbus platform callback instead, it will then call the transceiver if needed. This fixes a use case where USB cable is plugged first and gadget driver is loaded later after that. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- drivers/usb/musb/musb_gadget.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index be18537..19998e9 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1972,9 +1972,8 @@ static int musb_gadget_start(struct usb_gadget *g, goto err; } - if ((musb-xceiv-last_event == USB_EVENT_ID) -otg-set_vbus) - otg_set_vbus(otg, 1); + if (musb-xceiv-last_event == USB_EVENT_ID) + musb_platform_set_vbus(musb, 1); hcd-self.uses_pio_for_control = 1; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] usb: otg: twl4030-usb: don't enable PHY during init
There is no need to do it, otg.set_suspend(false) (which itself
comes from runtime_pm OMAP glue calls) will enable it later anyway.
This used to be the place where things were enabled if booted with
cable connected before runtime_pm conversion, but now can be dropped.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/otg/twl4030-usb.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..1515c0b 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -522,19 +522,17 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
{
enum omap_musb_vbus_id_status status;
- status = twl4030_usb_linkstat(twl);
- if (status 0) {
- if (status == OMAP_MUSB_VBUS_OFF ||
- status == OMAP_MUSB_ID_FLOAT) {
- __twl4030_phy_power(twl, 0);
- twl-asleep = 1;
- } else {
- __twl4030_phy_resume(twl);
- twl-asleep = 0;
- }
+ /*
+* Start in sleep state, we'll get called through set_suspend()
+* callback when musb is runtime resumed and it's time to start.
+*/
+ __twl4030_phy_power(twl, 0);
+ twl-asleep = 1;
+ status = twl4030_usb_linkstat(twl);
+ if (status 0)
omap_musb_mailbox(twl-linkstat);
- }
+
sysfs_notify(twl-dev-kobj, NULL, vbus);
}
@@ -649,9 +647,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
- /* Power down phy or make it work according to
-* current link state.
-*/
twl4030_usb_phy_init(twl);
dev_info(pdev-dev, Initialized TWL4030 USB module\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
