On Thu, Dec 20, 2012 at 12:17 AM, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > On Wed, Dec 19, 2012 at 9:14 AM, Mark Brown > <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> On Wed, Dec 19, 2012 at 12:32:01PM +0000, Grant Likely wrote: >> >>> I'm not convinced on the design of this protocol. It won't scale beyond >>> 2 bus masters and it seems very specific to the design of a specific >>> piece of hardware. I don't think it is mature enough to bake into the >> >> I ought to point out that the original patch would've baked this into >> the Samsung I2C driver but I asked for it to be split out as it's >> nothing to do with the controller really and I'm sure I've seen it >> before. > > Grant your idea looks nice to me. I only worry if we should wait until > we have a second user before going so far with it. But it is certainly > a nice general solution. > > The scaling beyond two bus masters would require the code to be > changed to check more input lines from other masters. Best avoided for > now I think until we have a use for it. There is two parts to this; the design of the binding, and the implementation. Of the two, the binding is the most difficult to change, so it is important to get something we can live with long term sorted out now. The implementation can start somewhat naive, with a plan for how to extend it. Regarding the scaling to multiple devices, it is a much smaller issue (if an issue at all) if the arbitration back end is pluggable. Then it becomes easy to support hardware with a different arbitration protocol. If it gets baked into the core i2c code, then we've got a problem and a lot more scrutiny needs to be put into this specific protocol. g. -- 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
