> > Renesas R-Car Gen2 has two I2C IP cores. One can do DMA and automatic > > transfers to the PMIC, the other has I2C slave functionality. One cannot > > do I2C_SMBUS_QUICK, the other can. And some more kind of quirks. > > Sometimes you can mux the pins to GPIO, so you have a third option. > > > > This setup is the reason the demux driver exists. > > Have you run into scenarios where you dynamically switch between > the two masters in order to do different things (on one slave, or > on multiple slaves), or could you always decide on one of them > at boot time with that particular chip? My personal use case is debugging. R-Car H2 is great because I can always pinmux this or that I2C IP core to the same set of pins, and in 2 out of 4 cases even GPIO bitbang on top of that. So, it is great to compare behaviour, do scopes with the same type of setup, etc... For that, I do runtime switches, but the slaves are not really under real usage. I have absolutely no idea how $customers use it, sadly. > I think an SoC design we will likely see is an i3c master multiplexed with > an i2c master to access one bus. The i2c master can then use clock > stretching and other things that may not work in the i3c master, and it > may be used in the absence of proper i3c drivers in the OS. Multiplexed? Well, as soon you want to use I3C features like IBI, this is not going to work, right? It will not even work with Linux being an I2C slave itself. Or do you mean running the I3C and I2C controller simultaneously using the same wires? > However, that case cannot be handled with the abstraction in the > proposed i3c framework, which can only deal with multiple i3c > standard compliant masters. I'm also not sure if it can be added > to the i2c-demux-pinctrl driver. The I2C demuxer maps the whole bus to an i2c_adapter. You cannot select a master per client.
Attachment:
signature.asc
Description: PGP signature
