1

My device has a opencore-i2c that in turn exports multiple i2c/smbus interfaces. I have an x86_64 system, and I am able to add i2c devices that sit on the SMB0, SMB1 since the names SMB0 and SMB1 are known the system.

I having difficulty in declaring i2c devices that are behind the FPGA. FROM DSDT, I see declaration of SMB0 as follows

  Device (SMB0)
  {
      Name (_ADR, 0x001F0004)  // _ADR: Address
  }

This corresponds to the lspci output below which has SMBus at 00:1f.4

root# lspci | grep -i smbus
00:12.0 System peripheral: Intel Corporation DNV SMBus Contoller - Host (rev 11)
00:1f.4 SMBus: Intel Corporation DNV SMBus controller (rev 11)
root#

However in case of ocores, a single PCI device publishes multiple i2c-bus to the kernel once the driver is loaded. So, any pointers on how to publish this information via ACPI so that the i2c devices on those buses can be auto-enumerated after OCORE driver is loaded.

Reference: https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-ocores.c

In the above example, an i2c-adapter is created for each pci-function. The Device-Tree is expected to pass the address of the PCI-Resource, and the driver instantiates a single instance of the i2c-adapter.

In my case, the code is modified such that the base-address, and "number of i2c busses" on the given platform is passed as parameter.

The driver then then instantiates i2c busses with calls to i2c_add_numbered_adapter based on number of buses to create.

The offsets to communicate with the device are calculated as offsets from the "BAR" register.

0andriy
  • 4,183
  • 1
  • 24
  • 37
ksrikanth
  • 71
  • 9
  • Do you have a link to the i2c bus driver source code? And update your Q to show what you meant by the last paragraph. (Just in case, how to describe slave devices I explained here in several answers: https://stackoverflow.com/a/54967620/2511795, https://stackoverflow.com/a/46370798/2511795, etc) – 0andriy Jul 14 '20 at 20:01
  • Thanks @0andriy. Your examples help uderstand scenario where there are distinct addresses for each sub-device. In this case, there is one PCI-device. It has a single BAR. The device driver then publishes 1 or more i2c-buses. Hence from ACPI view, I assume it only sees one single device. The logical i2c-names that will be published by the driver are potentially not known to ACPI since they are generated when the driver starts. – ksrikanth Jul 16 '20 at 15:26
  • It's possible to describe this in ACPI and refer using `_ADR` value. However, to help you you need to share or point out to the piece of code that instantiates the drivers. – 0andriy Jul 16 '20 at 18:58
  • NOTE! The design you described is a begging for troubles! So, the hardware must be redesigned in order to provide proper multi-functional PCI (where BDF will be per each I2C bus, so, one PCI device can provide up to 8 functions / slots). – 0andriy Jul 16 '20 at 19:00
  • About usage of `_ADR` look into this answer: https://stackoverflow.com/a/60855157/2511795. It will you give an idea how to work around your case. But note, much better is to provide one device per I2C bus. – 0andriy Jul 16 '20 at 19:05
  • Thanks @0andriy. I am experimenting with use of _ADR. Will update once I make some progress. In our case the FPGA provides upto 16 devices. That could be the possible reason I think. – ksrikanth Jul 17 '20 at 03:51

0 Answers0