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:
[<c002e684>] (unwind_backtrace+0x0/0xec) from [<c003e284>] (warn_slowpath_common+0x4c/0x64)
[<c003e284>] (warn_slowpath_common+0x4c/0x64) from [<c003e2b8>] (warn_slowpath_null+0x1c/0x24)
[<c003e2b8>] (warn_slowpath_null+0x1c/0x24) from [<c0043e80>] (local_bh_enable+0x40/0xb4)
[<c0043e80>] (local_bh_enable+0x40/0xb4) from [<c01f3760>] (__netif_receive_skb+0xf8/0x3d0)
[<c01f3760>] (__netif_receive_skb+0xf8/0x3d0) from [<c01d344c>] (emac_rx_handler+0x40/0xcc)
[<c01d344c>] (emac_rx_handler+0x40/0xcc) from [<c01d3fe8>] (__cpdma_chan_free+0xac/0xb0)
[<c01d3fe8>] (__cpdma_chan_free+0xac/0xb0) from [<c01d40d0>] (__cpdma_chan_process+0xe4/0x114)
[<c01d40d0>] (__cpdma_chan_process+0xe4/0x114) from [<c01d4238>] (cpdma_chan_stop+0xf0/0x1c8)
[<c01d4238>] (cpdma_chan_stop+0xf0/0x1c8) from [<c01d4390>] (cpdma_ctlr_stop+0x80/0xe4)
[<c01d4390>] (cpdma_ctlr_stop+0x80/0xe4) from [<c01d2c00>] (emac_dev_stop+0xb0/0x13c)
[<c01d2c00>] (emac_dev_stop+0xb0/0x13c) from [<c01f5b40>] (__dev_close+0x74/0x98)
[<c01f5b40>] (__dev_close+0x74/0x98) from [<c01f3168>] (__dev_change_flags+0xac/0x13c)
[<c01f3168>] (__dev_change_flags+0xac/0x13c) from [<c01f5994>] (dev_change_flags+0x10/0x44)
[<c01f5994>] (dev_change_flags+0x10/0x44) from [<c023cf60>] (devinet_ioctl+0x2dc/0x6f4)
[<c023cf60>] (devinet_ioctl+0x2dc/0x6f4) from [<c01e484c>] (sock_ioctl+0x1fc/0x258)
[<c01e484c>] (sock_ioctl+0x1fc/0x258) from [<c00aa0f0>] (do_vfs_ioctl+0x550/0x5c0)
[<c00aa0f0>] (do_vfs_ioctl+0x550/0x5c0) from [<c00aa198>] (sys_ioctl+0x38/0x5c)
[<c00aa198>] (sys_ioctl+0x38/0x5c) from [<c0029f00>] (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:
[<c002e684>] (unwind_backtrace+0x0/0xec) from [<c003e284>] (warn_slowpath_common+0x4c/0x64)
[<c003e284>] (warn_slowpath_common+0x4c/0x64) from [<c003e2b8>] (warn_slowpath_null+0x1c/0x24)
[<c003e2b8>] (warn_slowpath_null+0x1c/0x24) from [<c01d3fe8>] (__cpdma_chan_free+0xac/0xb0)
[<c01d3fe8>] (__cpdma_chan_free+0xac/0xb0) from [<c01d40d0>] (__cpdma_chan_process+0xe4/0x114)
[<c01d40d0>] (__cpdma_chan_process+0xe4/0x114) from [<c01d4238>] (cpdma_chan_stop+0xf0/0x1c8)
[<c01d4238>] (cpdma_chan_stop+0xf0/0x1c8) from [<c01d4390>] (cpdma_ctlr_stop+0x80/0xe4)
[<c01d4390>] (cpdma_ctlr_stop+0x80/0xe4) from [<c01d2c00>] (emac_dev_stop+0xb0/0x13c)
[<c01d2c00>] (emac_dev_stop+0xb0/0x13c) from [<c01f5b40>] (__dev_close+0x74/0x98)
[<c01f5b40>] (__dev_close+0x74/0x98) from [<c01f3168>] (__dev_change_flags+0xac/0x13c)
[<c01f3168>] (__dev_change_flags+0xac/0x13c) from [<c01f5994>] (dev_change_flags+0x10/0x44)
[<c01f5994>] (dev_change_flags+0x10/0x44) from [<c023cf60>] (devinet_ioctl+0x2dc/0x6f4)
[<c023cf60>] (devinet_ioctl+0x2dc/0x6f4) from [<c01e484c>] (sock_ioctl+0x1fc/0x258)
[<c01e484c>] (sock_ioctl+0x1fc/0x258) from [<c00aa0f0>] (do_vfs_ioctl+0x550/0x5c0)
[<c00aa0f0>] (do_vfs_ioctl+0x550/0x5c0) from [<c00aa198>] (sys_ioctl+0x38/0x5c)
[<c00aa198>] (sys_ioctl+0x38/0x5c) from [<c0029f00>] (ret_fast_syscall+0x0/0x2c)
---[ end trace 0e686330480db12f ]---
Thanks for the help.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
