25.07.2016, 11:28, "Wolfram Sang" <wsa@xxxxxxxxxxxxx>: > Please word wrap your messages. > >> but the line is muxed until timeout or answer received by RMC. BMCs >> are passive and only responds to requests. > > OK, I see. > > What about serialization? Can it happen that you send a request to BMC > #1 and before the answer, you need to send an urgent request to BMC #2? Timeout for answer is quite short. Please refer to table at page 24 in the IPMB proto spec. I2C slave support implemented in AMI/Emerson firmware doesn't work in such way – slave read after master write implemented right in the kernel module as an ioctl (it is atomic operation from the software perspective). It's like a usual read/write, but read implemented as slave read. There is no way to switch mux and request to BMC #2. Logically, this shouldn't happen too. Search for I2C_SLAVE_RDWR in https://raw.githubusercontent.com/facebook/openbmc/master/meta-aspeed/recipes-kernel/linux/files/patch-2.6.28.9/0000-linux-aspeed-064.patch for slave implementation details. Attn! it's a 1.4MB file. > > Is it common in IPMI world to use muxes for this case? It's not a common, but not restricted while MUX master (RMC side) is logically Master while BMC is usually passive (logically Slaves) and do not initiate IPMB requests on their own behalf. Only requests for I2C slave devices on other busses such as sensors. One exception is a communication with Intel ME. Intel ME acts as a Master on I2C, but there is no muxes between in any kind of HW design. Thus this bus is in Multi-Master mode permanently. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
