Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse

[Michael Williamson <michael.williamson@criticallink.com>]

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