DP83826E: Interrupt pin as wakeup source in embedded Linux

In case it might help, I used mii-diag to get the following report ( mii-diag -v):

mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Using the default interface 'eth0'.
  Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x3100).
 The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
 Basic mode control register 0x3100: Auto-negotiation enabled.
 You have link beat, and everything is working OK.
   This transceiver is capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 Your link partner advertised c1e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   End of basic transceiver information.

libmii.c:v2.11 2/28/2005  Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
 MII PHY #0 transceiver registers:
   3100 786d 2000 a131 0de1 c1e1 000d 2001
   0000 0000 0100 0000 0000 4007 0000 0000
   0215 010b 00fc 00f7 0000 0000 0100 0065
   0480 ec00 0000 007d 05ee 0000 0102 0000.
 Basic mode control register 0x3100: Auto-negotiation enabled.
 Basic mode status register 0x786d ... 786d.
   Link status: established.
   Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 Vendor ID is 08:00:28:--:--:--, model 19 rev. 1.
   No specific information is known about this transceiver type.
 I'm advertising 0de1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
   Advertising no additional info pages.
   IEEE 802.3 CSMA/CD protocol.
 Link partner capability is c1e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Negotiation  completed.

Edit: some extra information... I can use mdio_tool if necessary to read and write single MII registers. I used that tool to set bit 2 (Test Interrupt) of register 0x11 (PHYSCR) and the interrupt pin is set to 0 as desired. That confirms that the hardware is not keeping the pin from toggling and therefore there must be a configuration issue.

HI Javier,

Let me check with the team on this. Will get back to you by mid week.

Thanks,

David

Thank you for your reply, any news on this?

To speed things up I am trying to set the WoL/interrupt registers manually with mdio_tool until I get a right solution in the DT. This is just an experiment to check if the system reacts to the interrupt as desired, but the final solution should not set registers manually and just rely on the Linux device driver and the right definition in the DT.

I have noticed that if I try to set the bit 0 (WoL Magic Packet Enable) of the RXFCFG1 register (0x4A0), when I read the register again its value is still 0, so no interrupts are generated when a Magic Packet arrives. As I said, in "freeze" state the system wakes up when I send a Magic Packet, but I guess it is because the GMAC reacts to it and not the PHY itself.

Might that be related with the real issue? When I read this register right after booting (and keeping the DT  I get 0x3100, which according to the datasheet does not look right.

Hi Javier,

I am not familiar with the difference between freeze and suspend-to-RAM power mode. This you can check with the MAC team. 

Have you enabled interrupts in register 0x11, bit[1], and made the INT/PWDN pin as interrupt in bit[0]? WoL Packet Interrupt should also be enabled in register 0x13, bit[1]. 

Register 0x4A1 has the magic packet status, not 0x4A0. Please read bit[0] of 0x4A1 after you send a magic packet and let me know the results. 

Thanks,

David

As I said, I am using mdio-tool to read the registers you mentioned, but I just realised that only the first 32 registers can be read and any address beyond 0x1F is shifted to that range e.g. 0x20 = 0x00, 0x21 = 0x01, etc. Therefore I read some weird value from the 0x4A0 register and the same happens when I try to read 0x4A1, which returns 0x786D -> which is register 0x01. I had a look at the code and the tool itself is not the bottleneck because it does not has any address limit. I also hacked mii-diag a little bit to have two tools to compare and read all the PHY registers at once with the -v flag and the same issue arose. Originally mii-diag -v reads only the first 32 registers, which is probably not a coincidence.... what tool are you using to read the registers beyond 0x1F? It seems that there is some kind of limitation in the device driver or in the API...

Hi Javier,

Please see section 9.3.11.1 of the datasheet for instructions to access the extended register space (>0x1F). Let me know when you are able to read/write register 0x4A0, 0x4A1, etc.

Thanks,

David

I could read the register 0x4A1 as follows:

mdio-tool w eth0 0x0D 0x001F   -> the value written to 0x0E (ADDAR register) is an address

mdio-tool w eth0 0x0E 0x04A1   -> Register 0x04A1

mdio-tool w eth0 0x0D 0x401F   -> the value written to 0x0E is data

mdio-tool r eth0 0x0E          -> read value from 0x04A1: 0x1000

The value I read seems to be right because 0x1000 is the register reset value. But if I send a Magic Packet I still read the same value and the bit 0 does not toggle.The rest of the configuration seems to be right:

mdio-tool r eth0 0x11: 0x010B

mdio-tool r eth0 0x13: 0x00F7

and the Magic Packet is received and acknowledged by the MAC when it is available (no deep standby mode). I know that because I can wake up the system that way. What might make the PHY not react to the Magic Packet? Is there any restriction e.g. it must be UDP/TCP? By the way, I am using wakeonlan to send the Magic Packet.

Edit: I tried etherwake as well but I got the same results.

Hi Javier,

I found a previous thread stating they had success with unicast magic packets but not broadcast magic packets. Can you try using unicast if you are not already?

Have a look at this previous thread as well as SNLA261 as they may be of help (part numbers are different but same principles may apply).

Let me bring this up with the team for further ideas.

Thanks,

David

Hi Javier,

A missing piece here is the destination address must be programmed in the RXFPMD registers (0x4A2 - 0x4A4). Please try this and let me know the results. 

Thanks,

David