422d05da14
An i2c bus can be divided into segments which can be selectively connected and disconnected from the main bus. This is usually done to enable using multiple slave devices having the same address, by isolating the devices onto separate bus segments, only one of which is connected to the main bus at once. There are several types of i2c bus muxes, which break down into two general categories... - Muxes which are themselves i2c slaves. These devices respond to i2c commands on their upstream bus, and based on those commands, connect various downstream buses to the upstream. In newbus terms, they are both a child of an iicbus and the parent of one or more iicbus instances. - Muxes which are not i2c devices themselves. Such devices are part of the i2c bus electrically, but in newbus terms their parent is some other bus. The association with the upstream bus must be established by separate metadata (such as FDT data). In both cases, the mux driver has one or more iicbus child instances representing the downstream buses. The mux driver implements the iicbus_if interface, as if it were an iichb host bridge/i2c controller driver. It services the IO requests sent to it by forwarding them to the iicbus instance representing the upstream bus, after electrically connecting the upstream bus to the downstream bus that hosts the i2c slave device which made the IO request. The net effect is automatic mux switching which is transparent to slaves on the downstream buses. They just do i2c IO they way they normally do, and the bus is electrically connected for the duration of the IO and then idled when it is complete. The existing iicbus_if callback() method is enhanced so that the parameter passed to it can be a struct which contains a device_t for the requesting bus and slave devices. This change is done by adding a flag that indicates the extra values are present, and making the flags field the first field of a new args struct. If the flag is set, the iichb or mux driver can recast the pointer-to-flags into a pointer-to-struct and access the extra fields. Thus abi compatibility with older drivers is retained (but a mux cannot exist on the bus with the older iicbus driver in use.) A new set of core support routines exists in iicbus.c. This code will help implement mux drivers for any type of mux hardware by supplying all the boilerplate code that forwards IO requests upstream. It also has code for parsing metadata and instantiating the child iicbus instances based on it. Two new hardware mux drivers are added. The ltc430x driver supports the LTC4305/4306 mux chips which are controlled via i2c commands. The iic_gpiomux driver supports any mux hardware which is controlled by manipulating the state of one or more gpio pins. Test Plan Tested locally using a variety of mux'd bus configurations involving both ltc4305 and a homebrew gpio-controlled mux. Tested configurations included cascaded muxes (unlikely in the real world, but useful to prove that 'it all just works' in terms of the automatic switching and upstream forwarding of IO requests).
79 lines
3.3 KiB
C
79 lines
3.3 KiB
C
/*-
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
*
|
|
* Copyright (c) 2019 Ian Lepore <ian@freebsd.org>
|
|
*
|
|
* Redistribution and use in source and binary forms, with or without
|
|
* modification, are permitted provided that the following conditions
|
|
* are met:
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
* notice, this list of conditions and the following disclaimer.
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
* documentation and/or other materials provided with the distribution.
|
|
*
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
* SUCH DAMAGE.
|
|
*
|
|
* $FreeBSD$
|
|
*/
|
|
|
|
#ifndef __IICMUX_H
|
|
#define __IICMUX_H
|
|
|
|
#define IICMUX_MAX_BUSES 16 /* More than any available mux chip. */
|
|
|
|
/*
|
|
* IICMUX_SELECT_IDLE instructs the mux hardware driver to do whatever it is
|
|
* configured to do when the downstream buses are idle. Hardware has varying
|
|
* capabilities; it may disconnect all downstream buses, or connect a specific
|
|
* bus, or just leave whatever bus was last used connected. Hardware which is
|
|
* capable of various choices will have some mechanism to configure the choice
|
|
* which is handled outside of the iicmux framework.
|
|
*/
|
|
#define IICMUX_SELECT_IDLE (-1)
|
|
|
|
/*
|
|
* The iicmux softc; chip drivers should embed one of these as the first member
|
|
* variable of their own softc struct, and must call iicmux_attach() to
|
|
* initialize it before calling any other iicmux functions.
|
|
*/
|
|
struct iicmux_softc {
|
|
device_t busdev; /* Upstream i2c bus (may not be our parent). */
|
|
device_t dev; /* Ourself. */
|
|
int maxbus; /* Index of highest populated busdevs slot. */
|
|
int numbuses; /* Number of buses supported by the chip. */
|
|
int debugmux; /* Write debug messages when > 0. */
|
|
device_t childdevs[IICMUX_MAX_BUSES]; /* Child bus instances. */
|
|
#ifdef FDT
|
|
phandle_t childnodes[IICMUX_MAX_BUSES]; /* Child bus fdt nodes. */
|
|
#endif
|
|
};
|
|
|
|
DECLARE_CLASS(iicmux_driver);
|
|
|
|
/*
|
|
* Helpers to call from attach/detach functions of chip-specific drivers.
|
|
*
|
|
* The iicmux_attach() function initializes the core driver's portion of the
|
|
* softc, and creates child iicbus instances for any children it can identify
|
|
* using hints and FDT data. If a chip driver does its own device_add_child()
|
|
* calls to add other downstream buses that participate in the mux switching, it
|
|
* must call iicmux_add_child() to inform the core driver of the downstream
|
|
* busidx<->device_t relationship.
|
|
*/
|
|
int iicmux_add_child(device_t dev, device_t child, int busidx);
|
|
int iicmux_attach(device_t dev, device_t busdev, int numbuses);
|
|
int iicmux_detach(device_t dev);
|
|
|
|
#endif
|