Re: [PATCH V2 0/8] ARM: dts: Various OMAP2+ device-tree updates

2013-03-17 Thread Anil Kumar
Hi Benoit, On Fri, Mar 15, 2013 at 8:00 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Jon, On 03/15/2013 02:57 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but

Re: [net PATCH 1/1] drivers: net: ethernet: ti: davinci_emac: fix usage of cpdma_check_free_tx_desc()

2013-03-17 Thread David Miller
From: Prabhakar Lad prabhakar.cse...@gmail.com Date: Sat, 16 Mar 2013 12:43:14 +0530 Hi Mugunthan Thanks for the patch! On Fri, Mar 15, 2013 at 7:40 PM, Mugunthan V N mugunthan...@ti.com wrote: Fix which was done in the following commit in cpsw driver has to be taken forward to davinci

[PATCHv2 0/7] usb: phy: twl4030-usb fixes

2013-03-17 Thread Grazvydas Ignotas
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

[PATCHv2 1/7] usb: phy: twl4030-usb: don't enable PHY during init

2013-03-17 Thread Grazvydas Ignotas
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

[PATCHv2 2/7] usb: phy: twl4030-usb: ignore duplicate events

2013-03-17 Thread Grazvydas Ignotas
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

[PATCHv2 3/7] usb: phy: twl4030-usb: don't switch the phy on/off needlessly

2013-03-17 Thread Grazvydas Ignotas
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

[PATCHv2 4/7] usb: phy: twl4030-usb: poll for ID disconnect

2013-03-17 Thread Grazvydas Ignotas
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. This patch also moves twl-linkstat

[PATCHv2 6/7] usb: musb: omap2430: turn off vbus on cable disconnect

2013-03-17 Thread Grazvydas Ignotas
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 on USB_EVENT_NONE to be sure musb session is ended on cable unplug so that PM works.

[PATCHv2 7/7] usb: musb: gadget: use platform callback to enable vbus

2013-03-17 Thread Grazvydas Ignotas
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

[PATCHv2 5/7] usb: phy: twl4030-usb: check if vbus is driven by twl itself

2013-03-17 Thread Grazvydas Ignotas
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 ---

Re: commit 6797b4f causes boot hangs with nfsroot

2013-03-17 Thread Paul Walmsley
Hi Jon, On Sat, 16 Mar 2013, Paul Walmsley wrote: Looks like commit 6797b4fe0e554ce71f47038fd929c9ca929a9f3c (ARM: OMAP2+: Prevent potential crash if GPMC probe fails) causes hangs on boot. I suspect it may only occur when the root filesystem is on NFS over GPMC-based Ethernet. Looks