AM335x MDIO continous activity

Yes, this is expected behavior as the MDIO state machine is constantly polling the PHY for status updates.

This functionality can be disabled, but the interface would cease to function as intended in the absence of these PHY updates. Some PHYs provide an interrupt pin that could be routed to a SoC GPIO and monitored by system software to process PHY updates, but there is no SW support implemented for this currently.

Thanks for the answer!

My problem is, that I'm trying to access the SMSC9303 switch switch via MDIO. And it has 32bit registers organised as 2 16bit registers. These registers need to be accessed back-to-back. Without any other frame in between. This will be "disturbed" by this state machine polling now.

So how can this polling be disabled? By clearing the ENABLE bit in the MDIOCONTROL register? Or is there any other way to do this?

Thanks,

Stefan

Correct, the MDIO can be disabled via the ENABLE bit in MDIOCONTROL.

Clearing MDIO ENABLE will stop the automatic polling, but it does so by disabling the interface altogether, which would prevent you from accessing your switch.

Hi -DK-,

Our customer wants to stop the automatic polling by the MDIO state machine.

While the ENABLE bit in MDIOCONTROL is cleared, can the user not use the MDIO interface of AM335x? Is the external MDIO controller needed to access the PHY register?

Best regards,

Daisuke

Hi Daisuke!

What we did was to not use the MDIO controller for the MDIO communication at all. We changed the multiplexing for the MDIO pins to GPIO and used a bitbang GPIO-MDIO driver instead. This works just fine.

HTP,

Stefan

Yeah, given the simplicity of the task, the MDIO controller (and its integration) manages to do a surprisingly poor job for it.  Not only is it impossible to disable the automatic polling (without disabling the whole thing), it can only produce a link change irq for a single PHY even though it polls the link status for all PHY addresses.  Worse yet, it actually has a second link change irq, but it's not connected to anything within the subsystem.  Very convenient, given that the whole point of the switch subsystem is to have two external ports, hence usually two PHYs to monitor.  The controller also has two link status inputs selectable as alternative source for link detection (with irq), perfect for connecting the RGMII in-band link status signals.  Except of course they aren't, nor is there any other way to get an IRQ on those.

Well done.

Thanks for the feedback Matthijs.

It's always going to be tricky to balance cost vs complexity when designing large SoC's, but I've forwarded this thread internally to those in a position to make functionality changes on follow-on devices.

Sorry if I was a bit harsh.  I do fully appreciate that with the complexity of large SoC, small details like these can easily get overlooked.  It is just a bit frustrating to see the functionality of some component greatly diminished by things like not connecting an irq output to anything or leaving or some input not-connected instead of connecting it to an "obvious" (with 20/20 hindsight) nearby candidate.  Especially since the link status monitoring, now rendered useless if you have 2 PHYs, is causing problems for people as this thread shows (and probably also adds unnecessary power consumption).

Hi Stefan,

Thank you for your reply.

I will suggest to our customer that they control the MDIO pins as GPIO by software if the MDIO is disabled via the ENABLE bit in MDIOCONTROL.

Hi Matthijs,

Thank you for your information.

Did you mention that the MLINK inputs are not pinned out?

Hi -DK-,

I found that DM814x has same issue.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/149750.aspx

If the LINKSEL bit in MDIOUSERPHYSELx is set, does the MDIO state machine stop polling the link status from the PHY with the corresponding address?

Best regards,

Daisuke

Daisuke Maeda said:

Hi Matthijs,

Did you mention that the MLINK inputs are not pinned out?

Yeah, I guess I could have been clearer but that's what I meant with:

Matthijs van Duin said:

The controller also has two link status inputs selectable as alternative source for link detection (with irq), perfect for connecting the RGMII in-band link status signals.  Except of course they aren't

Pinning MLINK out to the package seems less useful to me since you can always use a GPIO for that, but connecting it to an in-band link status signal produced by the RGMII (or in other devices SGMII) submodule seems to me the perfect application for it.

Daisuke Maeda said:

I found that DM814x has same issue.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/149750.aspx

The am335x and dm814x have exactly the same MDIO controller.  More generally, their ethernet subsystems are almost identical, except that am335x has slightly newer versions of some submodules, and moved all register blocks to different offsets (though the individual register blocks remain compatible, except for the switch which also moves some individual registers and bitfields around).  The people who need to maintain the drivers are probably very happy about that.

Comparison:

The subsystem wrapper changed from function code 0xEDA v1.1.0 to function 0xEDB v1.0.0, indicating a software-incompatible change, even though they look identical to me.  Perhaps it's meant to indicate the incompatible rearrangement of the overall subsystem, although that's of course not very useful since you already need to know which edition of the subsystem you have to know the offset of that register.

Daisuke Maeda said:

If the LINKSEL bit in MDIOUSERPHYSELx is set, does the MDIO state machine stop polling the link status from the PHY with the corresponding address?

No, its "PHY Alive" status bit still gets automatically set shortly after you clear it, which means the MDIO controller is still polling it.

Hi Matthijs,

Thank you for your reply.

Best regards,

Daisuke