From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Williamson Subject: Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse Date: Thu, 09 Sep 2010 17:25:40 -0400 Message-ID: <4C8950D4.9060102@criticallink.com> References: <1283891142-15522-1-git-send-email-cyril@ti.com> <871v95f2xv.fsf@deeprootsystems.com> <4C86F369.6040906@criticallink.com> <4C880733.5010909@ti.com> <4C882EAA.9030903@criticallink.com> <4C892AC0.80409@criticallink.com> <4C893ADE.809@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C893ADE.809@ti.com> Sender: netdev-owner@vger.kernel.org To: cyril@ti.com Cc: Kevin Hilman , "tony@atomide.com" , "netdev@vger.kernel.org" , "davinci-linux-open-source@linux.davincidsp.com" , "linux-omap@vger.kernel.org" , "davem@davemloft.net" List-Id: linux-omap@vger.kernel.org Hi Cyril, On 09/09/2010 03:51 PM, Cyril Chemparathy wrote: > Hi Mike, > > [...] >> The hang is in wait_for_user_access() in the davinci_mdio_read() call. Looks like >> the state machine got put back into IDLE somewhere between the MDIO probe and the >> EMAC probe. Seems like there should be some sort of time-out and error message >> in the wait_for_user_access() method.... (maybe even a check for IDLE??) >> >> If I add a patch to check the state machine for IDLE and then re-enable it in the >> davinci_mdio_read() call, it is able to press on and come up. I don't see any calls >> to the davinci_mdio_suspend() call, so I am wondering if the EMAC probe routine, >> particularly the application of the SOFTRESET, is causing the MDIO to drop back to >> IDLE / disabled. >> >> I can post the patch if you like, but it is a bit of a hack... > > An EMAC soft-reset clobbering the MDIO controller state is a > possibility. I will poll TI designers to see if this could be the case. > > In any case, a couple of unanswered questions remain: > > 1. Why don't other davinci devices display similar behavior? > > 2. If the answer to #1 above is that the timing window is pretty slim > (i.e., only if an MDIO read/write is in progress during EMAC > soft-reset), why do we hit this situation consistently on > mityomap? Has it been confirmed that this only happens on mityomap? Has anyone had success using a da850 evm or other da850 platform? The configuration for the mityomap, wrt to the EMAC/MII/MDIO, is pretty much identical to the da850 evm using the MII interface. The only difference I am aware of is the assigned address to the PHY chip. The reference clocks and rates are identical, AFAIK, to the evm. > > I have put together a quick patch (tested dm365). See attached. Your patch doesn't work with my board. It does attempt to reset the bus on the read call, but following wait_for_user_access() calls are timing out and the _read() and _write() calls punt. I bumped up the MDIO_TIMEOUT to 100 ms, and it works. I'm wondering if the scanning logic has to complete an entire cycle (all 32 phys) before issuing a request, and if it's a lot slower than expected. I also found that the initial scanning logic would not reliably find the PHY until I bumped up the delay time following the reset operation. Sometimes it would, sometimes no. Also, your while(1) loops with the continue conditions on the second wait_for_user_access() in the read and writes might need some consideration, i.e.: while (1) { ret = wait_for_user_access(data); if (ret == -EAGAIN) continue; if (ret < 0) break; __raw_writel(reg, &data->regs->user[0].access); ret = wait_for_user_access(data); if (ret == -EAGAIN) continue; ^^^^^^^^^ <--- this will re-issue the request.... what you want? if (ret < 0) break; reg = __raw_readl(&data->regs->user[0].access); ret = (reg & USERACCESS_ACK) ? (reg & USERACCESS_DATA) : -EIO; break; } Also, on the shutdown, I get a major kernel trace. Here is the dump, as much as I could catch of it.... (I need a better terminal program) Deconfiguring network interfaces... ------------[ cut here ]------------ WARNING: at kernel/softirq.c:143 local_bh_enable+0x40/0xb4() Modules linked in: [] (unwind_backtrace+0x0/0xec) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null+0x1c/0x24) from [] (local_bh_enable+0x40/0xb4) [] (local_bh_enable+0x40/0xb4) from [] (__netif_receive_skb+0xf8/0x3d0) [] (__netif_receive_skb+0xf8/0x3d0) from [] (emac_rx_handler+0x40/0xcc) [] (emac_rx_handler+0x40/0xcc) from [] (__cpdma_chan_free+0xac/0xb0) [] (__cpdma_chan_free+0xac/0xb0) from [] (__cpdma_chan_process+0xe4/0x114) [] (__cpdma_chan_process+0xe4/0x114) from [] (cpdma_chan_stop+0xf0/0x1c8) [] (cpdma_chan_stop+0xf0/0x1c8) from [] (cpdma_ctlr_stop+0x80/0xe4) [] (cpdma_ctlr_stop+0x80/0xe4) from [] (emac_dev_stop+0xb0/0x13c) [] (emac_dev_stop+0xb0/0x13c) from [] (__dev_close+0x74/0x98) [] (__dev_close+0x74/0x98) from [] (__dev_change_flags+0xac/0x13c) [] (__dev_change_flags+0xac/0x13c) from [] (dev_change_flags+0x10/0x44) [] (dev_change_flags+0x10/0x44) from [] (devinet_ioctl+0x2dc/0x6f4) [] (devinet_ioctl+0x2dc/0x6f4) from [] (sock_ioctl+0x1fc/0x258) [] (sock_ioctl+0x1fc/0x258) from [] (do_vfs_ioctl+0x550/0x5c0) [] (do_vfs_ioctl+0x550/0x5c0) from [] (sys_ioctl+0x38/0x5c) [] (sys_ioctl+0x38/0x5c) from [] (ret_fast_syscall+0x0/0x2c) ---[ end trace 0e686330480db12e ]--- ------------[ cut here ]------------ WARNING: at drivers/net/davinci_emac.c:1025 __cpdma_chan_free+0xac/0xb0() Modules linked in: [] (unwind_backtrace+0x0/0xec) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null+0x1c/0x24) from [] (__cpdma_chan_free+0xac/0xb0) [] (__cpdma_chan_free+0xac/0xb0) from [] (__cpdma_chan_process+0xe4/0x114) [] (__cpdma_chan_process+0xe4/0x114) from [] (cpdma_chan_stop+0xf0/0x1c8) [] (cpdma_chan_stop+0xf0/0x1c8) from [] (cpdma_ctlr_stop+0x80/0xe4) [] (cpdma_ctlr_stop+0x80/0xe4) from [] (emac_dev_stop+0xb0/0x13c) [] (emac_dev_stop+0xb0/0x13c) from [] (__dev_close+0x74/0x98) [] (__dev_close+0x74/0x98) from [] (__dev_change_flags+0xac/0x13c) [] (__dev_change_flags+0xac/0x13c) from [] (dev_change_flags+0x10/0x44) [] (dev_change_flags+0x10/0x44) from [] (devinet_ioctl+0x2dc/0x6f4) [] (devinet_ioctl+0x2dc/0x6f4) from [] (sock_ioctl+0x1fc/0x258) [] (sock_ioctl+0x1fc/0x258) from [] (do_vfs_ioctl+0x550/0x5c0) [] (do_vfs_ioctl+0x550/0x5c0) from [] (sys_ioctl+0x38/0x5c) [] (sys_ioctl+0x38/0x5c) from [] (ret_fast_syscall+0x0/0x2c) ---[ end trace 0e686330480db12f ]--- Thanks for the help. -Mike