Remove residual blank line at start of MakefileThis is a residual of the $FreeBSD$ removal.MFC After: 3 days (though I'll just run the command on the branches)Sponsored by: Netflix
sys: Remove $FreeBSD$: one-line sh patternRemove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
Add support for i2c bus mux hardware.An i2c bus can be divided into segments which can be selectively connectedand disconnected from the main bus. This is usually done to enable usingmultiple sla
Add support for i2c bus mux hardware.An i2c bus can be divided into segments which can be selectively connectedand disconnected from the main bus. This is usually done to enable usingmultiple slave devices having the same address, by isolating the devicesonto separate bus segments, only one of which is connected to the main busat once.There are several types of i2c bus muxes, which break down into two generalcategories... - 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 instancesrepresenting the downstream buses. The mux driver implements the iicbus_ifinterface, as if it were an iichb host bridge/i2c controller driver. Itservices the IO requests sent to it by forwarding them to the iicbusinstance representing the upstream bus, after electrically connecting theupstream bus to the downstream bus that hosts the i2c slave device whichmade the IO request.The net effect is automatic mux switching which is transparent to slaves onthe downstream buses. They just do i2c IO they way they normally do, and thebus is electrically connected for the duration of the IO and then idled whenit is complete.The existing iicbus_if callback() method is enhanced so that the parameterpassed to it can be a struct which contains a device_t for the requestingbus and slave devices. This change is done by adding a flag that indicatesthe extra values are present, and making the flags field the first field ofa new args struct. If the flag is set, the iichb or mux driver can recastthe pointer-to-flags into a pointer-to-struct and access the extrafields. Thus abi compatibility with older drivers is retained (but a muxcannot 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 helpimplement mux drivers for any type of mux hardware by supplying all theboilerplate code that forwards IO requests upstream. It also has code forparsing metadata and instantiating the child iicbus instances based on it.Two new hardware mux drivers are added. The ltc430x driver supports theLTC4305/4306 mux chips which are controlled via i2c commands. Theiic_gpiomux driver supports any mux hardware which is controlled bymanipulating the state of one or more gpio pins. Test PlanTested locally using a variety of mux'd bus configurations involving bothltc4305 and a homebrew gpio-controlled mux. Tested configurations includedcascaded muxes (unlikely in the real world, but useful to prove that 'it alljust works' in terms of the automatic switching and upstream forwarding ofIO requests).
show more ...