Chapter 169. PHY Event Polling
Prev Part XLV. Ethernet Device Support Next

Chapter 169. PHY Event Polling

Table of Contents

169.1. Introduction
169.2. Configuration

169.1. Introduction

Optional support for a background, normally low priority, thread to poll for PHY state changes is available when enabling the CYGPKG_IO_ETH_DRIVERS_PHY_EVENT_THREAD option.

This is useful on targets where there is no physical, interrupt-driven, support for asynchronous PHY notifications to be forwarded to the application processor. When enabled, the polling thread periodically checks for PHY state changes (e.g. LINK up/down), and on detecting a change in PHY state the Ethernet driver world is notified as-if from an interrupt DSR as would be the case for hardware signalling.

For example, the PHY event support allows for applications to be made aware of network cable changes that may require address changes.

For low resource systems, where the application may already have a suitable monitor or periodic thread, then the CYGPKG_IO_ETH_DRIVERS_PHY_EVENT_THREAD option can be disabled and the eth_drv_phy_thread() function in the src/net/phy_thread.c source file used as an example for implementing the necessary PHY polling and network stack callback.

169.2. Configuration

The PHY polling thread is relatively simple, with it continuously iterating over the configured interfaces with a defined period between PHY status calls.

Available options

CYGPKG_IO_ETH_DRIVERS_PHY_EVENT_THREAD

For backwards compatability this feature is normally disabled by default. It is also only relevant if the underlying hardware does not provide support for interrupt-driven PHY event notification.

When this option is enabled then the operation of the polling thread can be tuned by the further configuration options made available. The support does add the overhead of a thread+stack, plus the CPU load of periodic PHY register polling.

CYGPNUM_IO_ETH_DRIVERS_PHY_EVENT_THREAD_PRI

This option specifies the priority of the background PHY state polling thread. Normally it can be a low priority thread such that this feature does not impact the core application processing significantly.

However the priority may need to be tuned to the actual requirements for the specific application. For example, if the primary function of the application is network routing then it may be that a higher-priorty thread, with higher-frequency polling is required to respond to PHY LINK loss/recovery with lower latency.

CYGNUM_IO_ETH_DRIVERS_PHY_EVENT_THREAD_STACK

This option allows the statically allocated stack for the polling thread to be tuned for low-memory systems. The default setting for this option has been set at a safe level, and is more than sufficient on the majority of systems.

[Note]Note

If diagnostic code is enabled then the stack requirement will need to be higher than a system without, for example, diag_printf() calls.

CYGNUM_IO_ETH_DRIVERS_PHY_EVENT_THREAD_PERIOD
This option specifies the ideal, minimum, period in milliseconds between PHY status requests. The actual time between PHY status poll operations will depend on the system load and the relative priority of the polling thread (CYGNUM_IO_ETH_DRIVERS_PHY_EVENT_THREAD_PRI).
CYGNUM_IO_ETH_DRIVERS_PHY_EVENT_THREAD_DELAY

This option specifies the delay in milliseconds after the polling thread is started before the first PHY status check is performed. The actual time before the first polling period will depend on the system load and the relative priority of the polling thread (CYGNUM_IO_ETH_DRIVERS_PHY_EVENT_THREAD_PRI), but will be at least as long as this configured delay.

This option allows for the PHY polling to be deferring during system startup to allow for initialisation to complete. i.e. all Ethernet driver controller instances to be initialised, without unnecessary polling slowing down the system startup.

Prev Up Next
DRV_HDWR_pbuf_pool_free_hook() Home Chapter 170. CDC-EEM Target USB driver