diff options
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/bitbangmii.rst | 75 | ||||
| -rw-r--r-- | doc/develop/driver-model/design.rst | 6 | ||||
| -rw-r--r-- | doc/develop/index.rst | 1 | ||||
| -rw-r--r-- | doc/develop/release_cycle.rst | 2 |
4 files changed, 81 insertions, 3 deletions
diff --git a/doc/develop/bitbangmii.rst b/doc/develop/bitbangmii.rst new file mode 100644 index 00000000000..35a4a0cb7f9 --- /dev/null +++ b/doc/develop/bitbangmii.rst @@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later +.. Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>, Industrie Dial Face S.p.A., 2009 + +Bit-banged MII bus support +========================== + +The miiphybb ( Bit-banged MII bus driver ) supports an arbitrary number of +MII buses. This feature is useful when a driver uses different MII buses for +different PHYs and all (or a part) of these buses are implemented via +bit-banging mode. + +The driver requires that the following macro is defined in the board +configuration file: + +* CONFIG_BITBANGMII - Enable the miiphybb driver + +The driver code needs to allocate a regular MDIO device using mdio_alloc() +and assign .read and .write accessors which wrap bb_miiphy_read() and +bb_miiphy_write() functions respectively. The bb_miiphy_read() and +bb_miiphy_write() functions take a pointer to a callback structure, +struct bb_miiphy_bus_ops. The struct bb_miiphy_bus_ops has the following +fields/callbacks (see miiphy.h for details): + +.. code-block:: c + + int (*mdio_active)() // Activate the MDIO pin as output + int (*mdio_tristate)() // Activate the MDIO pin as input/tristate pin + int (*set_mdio)() // Write the MDIO pin + int (*get_mdio)() // Read the MDIO pin + int (*set_mdc)() // Write the MDC pin + int (*delay)() // Delay function + +The driver code will look like: + +.. code-block:: c + + static const struct bb_miiphy_bus_ops ravb_bb_miiphy_bus_ops = { + .mdio_active = ravb_bb_mdio_active, + .mdio_tristate = ravb_bb_mdio_tristate, + .set_mdio = ravb_bb_set_mdio, + .get_mdio = ravb_bb_get_mdio, + .set_mdc = ravb_bb_set_mdc, + .delay = ravb_bb_delay, + }; + + static int ravb_bb_miiphy_read(struct mii_dev *miidev, int addr, + int devad, int reg) + { + return bb_miiphy_read(miidev, &ravb_bb_miiphy_bus_ops, + addr, devad, reg); + } + + static int ravb_bb_miiphy_write(struct mii_dev *miidev, int addr, + int devad, int reg, u16 value) + { + return bb_miiphy_write(miidev, &ravb_bb_miiphy_bus_ops, + addr, devad, reg, value); + } + + static int ravb_probe(struct udevice *dev) + { + struct mii_dev *mdiodev; + ... + mdiodev = mdio_alloc(); + if (!mdiodev) + return -ENOMEM; + + mdiodev->read = ravb_bb_miiphy_read; + mdiodev->write = ravb_bb_miiphy_write; + mdiodev->priv = eth; + snprintf(mdiodev->name, sizeof(mdiodev->name), dev->name); + + ret = mdio_register(mdiodev); + ... + } diff --git a/doc/develop/driver-model/design.rst b/doc/develop/driver-model/design.rst index 92f638a0204..30093737200 100644 --- a/doc/develop/driver-model/design.rst +++ b/doc/develop/driver-model/design.rst @@ -843,8 +843,10 @@ steps (see device_probe()): activated and 'known' by the uclass. For some platforms, certain devices must be probed to get the platform into -a working state. To help with this, drivers marked with DM_FLAG_PROBE_AFTER_BIND -will be probed immediately after all devices are bound. For now, this happens in +a working state. To help with this, devices marked with DM_FLAG_PROBE_AFTER_BIND +will be probed immediately after all devices are bound. This flag must be set +on the device in its ``bind()`` function with +``dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND)``. For now, this happens in SPL, before relocation and after relocation. See the call to ``dm_autoprobe()`` for where this is done. diff --git a/doc/develop/index.rst b/doc/develop/index.rst index d9f2a838207..c907f8c9c2c 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -9,6 +9,7 @@ General .. toctree:: :maxdepth: 1 + bitbangmii board_best_practices codingstyle designprinciples diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index dc5bb340ff2..e736dc0616e 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -76,7 +76,7 @@ For the next scheduled release, release candidates were made on:: * U-Boot v2025.04-rc4 was released on Mon 10 March 2025. -.. * U-Boot v2025.04-rc5 was released on Mon 24 March 2025. +* U-Boot v2025.04-rc5 was released on Mon 24 March 2025. Please note that the following dates are planned only and may be deviated from as needed. |