Hello, 23.07.2016, 22:51, "Wolfram Sang" <wsa@xxxxxxxxxxxxx>: > Hi, > >> I'm working on multi-master i2c support in Aspeed SoC (AST2150, >> AST2300 and so on) and succeed with event passing to the slave >> software backend. Besides AST has two operation modes: byte transfer > > Which upstream driver does that SoC use? This one: https://github.com/openbmc/linux/blob/dev-4.4/drivers/i2c/busses/i2c-aspeed.c Plus my work-in-progress patch with slave support: https://github.com/ya-mouse/openbmc-target/blob/master/aspeed/patches-4.4/0068-openmouse-i2c-aspeed-slave-support.patch > >> and buffer transfer. While i2c slave framework operates over bytes. In >> current scheme I would able to receive an interrupt on buffer fill >> then call N-times event function with one byte. It is a little >> overhead there. What we can do there? > > Let me quote from Documentation/i2c/slave-interface: > > About buffers > ------------- > > During development of this API, the question of using buffers instead of just > bytes came up. Such an extension might be possible, usefulness is unclear at > this time of writing. Some points to keep in mind when using buffers: > > * Buffers should be opt-in and slave drivers will always have to support > byte-based transactions as the ultimate fallback because this is how the > majority of HW works. > > * For backends simulating hardware registers, buffers are not helpful because > on writes an action should be immediately triggered. For reads, the data in > the buffer might get stale. > > * A master can send STOP at any time. For partially transferred buffers, this > means additional code to handle this exception. Such code tends to be > error-prone. > >> Second one thing that I want to point is a slave support in I2C MUX/switch >> drivers. For instance I use PCA9548 switch and want to have N (N <= 8) slaves >> (one per channel) > > How do the other masters know that their channel is currently muxed then? And > what if two of them want to access two of your slaves at the same time? In current implementation this I2C switch might be only switched from one side (via i2c command). From the MUX point of view, there is only one master (which may mux) and a number of slaves behind each channel. But on proto level IPMB requires to act as multi-master to receive answers from other intelligent nodes. To receive answer requesting node have to switch to slave mode after master write request. Please take a look at page 13: http://www.intel.com/content/www/us/en/servers/ipmi/ipmp-spec-v1-0.html The quote: "Intelligent devices on the Intelligent Platform Management Bus transmit requests and responses as bus Masters and receive requests and response as bus Slaves. Thus, the only Master Write transactions are seen between intelligent nodes." > > This setup may work for one specific case but in general sounds pretty fragile > to me. This fragility shows in all the hacks needed to work around the proper > abstractions. I don't think much can be done about that. > > Regards, > > Wolfram -- 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
