> Also Digital didn't used switches to spare a few cent, the i2c was > integrated into the chipset and adding multiple channel didn't work > easily.
We also use i2c switches in our product because we have only one i2c channel, but there are many devices on that channel that have to have the same address (think multiple plug-in cards). We have cards that have multiple SFP fiber nodes that are all on the same address, but only one pair of i2c lines to the board. There are good technical reasons why one needs i2c switches in real-world systems. It was cheaper to do the multiplexing than to get a SoC with real multichannel support. > > Thanks for this example. Do you know enough about this code that you > > can help further if Constantine has questions regarding it and Sam has > > no time to answer? > > I will try to help you with questions, but I just know the driver not > the attachment framework. > IIRC Warner Losh did the hint based attachment framework, so he will > likely be able to help you about this. I have a similar driver to the ds1672 as well that's waiting to go into the tree. I'll be happy to answer questions about them both. The whole reason I did hinted i2c was that I have an i2c bus here in my boxes at work that has both 16-bit and 8-bit eeprom on it. The's no way to probe eeprom devices. If you look at only 8-bit addresses, then you'll fail to see the 16-bit ones on the bus. If you look only at the 16-bit ones, then you will write a byte to the 8-bit ones due to the aborted write used to set the read addresses. I also had one device that we wound up not using hang the bus after a 0-byte write to it. It drove the clock line low and nobody else could clock after that. Since this was two years ago, I don't recall the part in question anymore and the hardware guy that I did the evaluation has left the company. Probing the i2c bus is dangerous. You might get away with it in liminited environments, but in general it is bad medicine. However, when I talked to Constatine about it, it seemed like he understood the dangers and was willing to make it optional. Warner _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
