* Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
@ 2024-11-07 15:51 Konstantin Aladyshev
2024-11-08 8:26 ` Andy Shevchenko
2024-11-08 8:46 ` Andy Shevchenko
0 siblings, 2 replies; 10+ messages in thread
From: Konstantin Aladyshev @ 2024-11-07 15:51 UTC (permalink / raw)
To: linux-acpi, linux-i2c, andriy.shevchenko
Hello!
I'm trying to add I2C devices to I2C/SMBus buses via the ACPI SSDT
overlay method. I've managed to do it for the I2C buses, but can't get
it working for the SMBus (PIIX4).
Now the long description of what I've tried and learned.
I've successfully managed to add my I2C devices to the I2C buses. In
this case I2C buses are described in the ACPI code of my system like
this:
```
Device (I2CF)
{
Name (_HID, "AMDI0010")
Name (_UID, 0x05)
Method (_CRS, 0, Serialized) {...}
Method (_STA, 0, NotSerialized) {...}
}
```
These buses are present in the system as:
```
$ i2cdetect -l
i2c-0 unknown Synopsys DesignWare I2C adapter N/A
...
```
For my custom device (at24 EEPROM) I've created SSDT table:
```
DefinitionBlock ("at24.aml", "SSDT", 5, "", "AT24", 1)
{
External (_SB_.I2CF, DeviceObj)
Scope (\_SB.I2CF)
{
Device (EEP0) {
Name (_HID, "PRP0001")
Name (_DDN, "Atmel AT24 compatible EEPROM")
Name (_CRS, ResourceTemplate () {
I2cSerialBusV2 (
0x0050, // I2C Slave Address
ControllerInitiated,
400000, // Bus speed
AddressingMode7Bit,
"\\_SB.I2CF", // Link to ACPI I2C host controller
0
)
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", Package() { "atmel,24c128" } },
}
})
}
}
}
```
And after I've loaded it via 'acpi_configfs' I can successfully see
EEPROM in the system:
```
root@ubuntu-SP3:/home/ubuntu/acpi/custom# hexdump -C
/sys/bus/i2c/devices/i2c-PRP0001\:00/eeprom
00000000 63 6a a9 05 00 65 14 35 9f 81 a7 60 aa c2 18 d2 |cj...e.5...`....|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00004000
```
Now I'm trying to add devices to the SMBus bus. Which in my case is
produced from the i2c_piix4 PCI device:
```
$ lspci -s 00:14.0 -vvvxxx
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
NUMA node: 0
IOMMU group: 58
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4, sp5100_tco
00: 22 10 0b 79 03 04 20 02 61 00 05 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 0b 79
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
```
It is described as simple as this in the system ACPI code:
```
Device (SMBS) // \_SB_.PCI0.SMBS
{
Name (_ADR, 0x00140000) // _ADR: Address
}
```
And produces several I2C busses to the system:
```
i2c-7 unknown SMBus PIIX4 adapter port 0 at 0b00 N/A
i2c-8 unknown SMBus PIIX4 adapter port 2 at 0b00 N/A
i2c-9 unknown SMBus PIIX4 adapter port 1 at 0b20 N/A
```
No matter how I've tried, I can't get to add my custom devices to
these SMBus buses.
Apparently just using "\\_SB.PCI0.SMBS" is not enough for this case.
Maybe I need to somehow create port nodes for this Device? Or maybe it
is not possible at all with the current piix driver?
Anyway I've started digging and I've noticed that for the I2C device
there are two physical_nodes in the sysfs. Where the 'physical_node'
is a standard folder and 'physical_node1' is a direct link to the
proper i2c bus:
```
$ ls -la /sys/bus/acpi/devices/AMDI0010\:03/
total 0
drwxr-xr-x 4 root root 0 Nov 7 18:07 .
drwxr-xr-x 294 root root 0 Nov 7 18:05 ..
-r--r--r-- 1 root root 4096 Nov 7 18:06 hid
-r--r--r-- 1 root root 4096 Nov 7 18:06 modalias
-r--r--r-- 1 root root 4096 Nov 7 18:06 path
lrwxrwxrwx 1 root root 0 Nov 7 18:06 physical_node ->
../../../platform/AMDI0010:03
lrwxrwxrwx 1 root root 0 Nov 7 18:06 physical_node1 ->
../../../platform/AMDI0010:03/i2c-1
drwxr-xr-x 2 root root 0 Nov 7 18:06 power
-r--r--r-- 1 root root 4096 Nov 7 18:06 status
lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
-r--r--r-- 1 root root 4096 Nov 7 18:06 uid
drwxr-xr-x 3 root root 0 Nov 7 18:05 wakeup
$ ls -la /sys/bus/acpi/devices/AMDI0010\:03/physical_node/
total 0
drwxr-xr-x 4 root root 0 Nov 7 18:08 .
drwxr-xr-x 7335 root root 0 Nov 7 18:05 ..
lrwxrwxrwx 1 root root 0 Nov 7 18:05 driver ->
../../../bus/platform/drivers/i2c_designware
-rw-r--r-- 1 root root 4096 Nov 7 18:08 driver_override
lrwxrwxrwx 1 root root 0 Nov 7 18:08 firmware_node ->
../../LNXSYSTM:00/LNXSYBUS:00/AMDI0010:03
drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-1
-r--r--r-- 1 root root 4096 Nov 7 18:08 modalias
drwxr-xr-x 2 root root 0 Nov 7 18:08 power
lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../bus/platform
-rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
$ ls -la /sys/bus/acpi/devices/AMDI0010\:03/physical_node1/
total 0
drwxr-xr-x 4 root root 0 Nov 7 18:08 .
drwxr-xr-x 4 root root 0 Nov 7 18:08 ..
--w------- 1 root root 4096 Nov 7 18:08 delete_device
lrwxrwxrwx 1 root root 0 Nov 7 18:08 device -> ../../AMDI0010:03
lrwxrwxrwx 1 root root 0 Nov 7 18:08 firmware_node ->
../../../LNXSYSTM:00/LNXSYBUS:00/AMDI0010:03
drwxr-xr-x 3 root root 0 Nov 7 18:05 i2c-dev
-r--r--r-- 1 root root 4096 Nov 7 18:05 name
--w------- 1 root root 4096 Nov 7 18:08 new_device
drwxr-xr-x 2 root root 0 Nov 7 18:08 power
lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../../bus/i2c
-rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
-r--r--r-- 1 root root 4096 Nov 7 18:08 waiting_for_supplier
```
But in the case of SMBus there is only one 'physical_node' folder (but
3 i2c buses) :
```
$ ls -l /sys/bus/acpi/devices/device\:25/
total 0
-r--r--r-- 1 root root 4096 Nov 7 18:07 adr
-r--r--r-- 1 root root 4096 Nov 7 18:07 path
lrwxrwxrwx 1 root root 0 Nov 7 18:07 physical_node ->
../../../../pci0000:00/0000:00:14.0
drwxr-xr-x 2 root root 0 Nov 7 18:07 power
lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
drwxr-xr-x 3 root root 0 Nov 7 18:05 wakeup
$ ls -l /sys/bus/acpi/devices/device\:25/physical_node/
total 0
-r--r--r-- 1 root root 4096 Nov 7 18:07 ari_enabled
-rw-r--r-- 1 root root 4096 Nov 7 18:07 broken_parity_status
-r--r--r-- 1 root root 4096 Nov 7 18:05 class
-rw-r--r-- 1 root root 256 Nov 7 18:07 config
-r--r--r-- 1 root root 4096 Nov 7 18:07 consistent_dma_mask_bits
-rw-r--r-- 1 root root 4096 Nov 7 18:07 d3cold_allowed
-r--r--r-- 1 root root 4096 Nov 7 18:05 device
-r--r--r-- 1 root root 4096 Nov 7 18:07 dma_mask_bits
lrwxrwxrwx 1 root root 0 Nov 7 18:05 driver ->
../../../bus/pci/drivers/piix4_smbus
-rw-r--r-- 1 root root 4096 Nov 7 18:07 driver_override
-rw-r--r-- 1 root root 4096 Nov 7 18:07 enable
lrwxrwxrwx 1 root root 0 Nov 7 18:07 firmware_node ->
../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:25
drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-7
drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-8
drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-9
lrwxrwxrwx 1 root root 0 Nov 7 18:07 iommu -> ../0000:00:00.2/iommu/ivhd3
lrwxrwxrwx 1 root root 0 Nov 7 18:07 iommu_group ->
../../../kernel/iommu_groups/58
-r--r--r-- 1 root root 4096 Nov 7 18:07 irq
drwxr-xr-x 2 root root 0 Nov 7 18:07 link
-r--r--r-- 1 root root 4096 Nov 7 18:07 local_cpulist
-r--r--r-- 1 root root 4096 Nov 7 18:07 local_cpus
-r--r--r-- 1 root root 4096 Nov 7 18:07 modalias
-rw-r--r-- 1 root root 4096 Nov 7 18:07 msi_bus
-rw-r--r-- 1 root root 4096 Nov 7 18:07 numa_node
drwxr-xr-x 2 root root 0 Nov 7 18:07 power
-r--r--r-- 1 root root 4096 Nov 7 18:07 power_state
--w--w---- 1 root root 4096 Nov 7 18:07 remove
--w------- 1 root root 4096 Nov 7 18:07 rescan
-r--r--r-- 1 root root 4096 Nov 7 18:05 resource
-r--r--r-- 1 root root 4096 Nov 7 18:07 revision
lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../bus/pci
-r--r--r-- 1 root root 4096 Nov 7 18:07 subsystem_device
-r--r--r-- 1 root root 4096 Nov 7 18:07 subsystem_vendor
-rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
-r--r--r-- 1 root root 4096 Nov 7 18:05 vendor
```
Maybe I need to modify ACPI code somehow to create these
'physical_nodesX' folders for the relevant i2c-7/8/9 buses?
Any feedback is appreciated.
Best regards,
Konstantin Aladyshev
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-07 15:51 Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method Konstantin Aladyshev
@ 2024-11-08 8:26 ` Andy Shevchenko
2024-11-08 8:29 ` Andy Shevchenko
2024-11-08 8:46 ` Andy Shevchenko
1 sibling, 1 reply; 10+ messages in thread
From: Andy Shevchenko @ 2024-11-08 8:26 UTC (permalink / raw)
To: Konstantin Aladyshev; +Cc: linux-acpi, linux-i2c
On Thu, Nov 07, 2024 at 06:51:03PM +0300, Konstantin Aladyshev wrote:
> Hello!
>
> I'm trying to add I2C devices to I2C/SMBus buses via the ACPI SSDT
> overlay method. I've managed to do it for the I2C buses, but can't get
> it working for the SMBus (PIIX4).
...
> Now I'm trying to add devices to the SMBus bus. Which in my case is
> produced from the i2c_piix4 PCI device:
> ```
> $ lspci -s 00:14.0 -vvvxxx
> 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
> Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> NUMA node: 0
> IOMMU group: 58
> Kernel driver in use: piix4_smbus
> Kernel modules: i2c_piix4, sp5100_tco
> 00: 22 10 0b 79 03 04 20 02 61 00 05 0c 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 0b 79
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ```
>
> It is described as simple as this in the system ACPI code:
> ```
> Device (SMBS) // \_SB_.PCI0.SMBS
> {
> Name (_ADR, 0x00140000) // _ADR: Address
So, you need to add Device objects here
The driver (drivers/i2c/busses/i2c-piix4.c::1157) has this call:
acpi_preset_companion(&adap->dev, ACPI_COMPANION(&dev->dev), hw_port_nr);
Means, that the _ADR will be evaluated, but there is none for the ports, only
for the physical device.
So, you need something like this:
Scope (\_SB_.PCI0.SMBS)
{
Device (SMB1)
{
Name (_ADR, 0)
}
Device (SMB1)
{
Name (_ADR, 1)
}
Device (SMB2)
{
Name (_ADR, 2)
}
}
And then refer to the controller (respective port) as, for example,
\_SB_.PCI0.SMBS.SMB1
in your SSDT. Note, the above _ADR assignments you should also add to SSDT
(better to the same one).
> }
> ```
> And produces several I2C busses to the system:
> ```
> i2c-7 unknown SMBus PIIX4 adapter port 0 at 0b00 N/A
> i2c-8 unknown SMBus PIIX4 adapter port 2 at 0b00 N/A
> i2c-9 unknown SMBus PIIX4 adapter port 1 at 0b20 N/A
> ```
>
> No matter how I've tried, I can't get to add my custom devices to
> these SMBus buses.
>
> Apparently just using "\\_SB.PCI0.SMBS" is not enough for this case.
> Maybe I need to somehow create port nodes for this Device? Or maybe it
> is not possible at all with the current piix driver?
>
> Anyway I've started digging and I've noticed that for the I2C device
> there are two physical_nodes in the sysfs. Where the 'physical_node'
> is a standard folder and 'physical_node1' is a direct link to the
> proper i2c bus:
> Maybe I need to modify ACPI code somehow to create these
> 'physical_nodesX' folders for the relevant i2c-7/8/9 buses?
If you succeed with the above, please add the respective section to
the Documentation/i2c/busses/i2c-piix4.rst and send a patch. It will
be very appreciated!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-08 8:26 ` Andy Shevchenko
@ 2024-11-08 8:29 ` Andy Shevchenko
0 siblings, 0 replies; 10+ messages in thread
From: Andy Shevchenko @ 2024-11-08 8:29 UTC (permalink / raw)
To: Konstantin Aladyshev; +Cc: linux-acpi, linux-i2c
On Fri, Nov 08, 2024 at 10:26:33AM +0200, Andy Shevchenko wrote:
> On Thu, Nov 07, 2024 at 06:51:03PM +0300, Konstantin Aladyshev wrote:
> > I'm trying to add I2C devices to I2C/SMBus buses via the ACPI SSDT
> > overlay method. I've managed to do it for the I2C buses, but can't get
> > it working for the SMBus (PIIX4).
...
> > Now I'm trying to add devices to the SMBus bus. Which in my case is
> > produced from the i2c_piix4 PCI device:
> > ```
> > $ lspci -s 00:14.0 -vvvxxx
> > 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
> > Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
> > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> > ParErr- Stepping- SERR- FastB2B- DisINTx+
> > Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
> > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > NUMA node: 0
> > IOMMU group: 58
> > Kernel driver in use: piix4_smbus
> > Kernel modules: i2c_piix4, sp5100_tco
> > 00: 22 10 0b 79 03 04 20 02 61 00 05 0c 00 00 80 00
> > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 0b 79
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ```
> >
> > It is described as simple as this in the system ACPI code:
> > ```
> > Device (SMBS) // \_SB_.PCI0.SMBS
> > {
> > Name (_ADR, 0x00140000) // _ADR: Address
>
> So, you need to add Device objects here
>
> The driver (drivers/i2c/busses/i2c-piix4.c::1157) has this call:
>
> acpi_preset_companion(&adap->dev, ACPI_COMPANION(&dev->dev), hw_port_nr);
>
> Means, that the _ADR will be evaluated, but there is none for the ports, only
> for the physical device.
>
> So, you need something like this:
>
> Scope (\_SB_.PCI0.SMBS)
> {
> Device (SMB1)
> {
> Name (_ADR, 0)
> }
> Device (SMB1)
> {
> Name (_ADR, 1)
> }
> Device (SMB2)
> {
> Name (_ADR, 2)
> }
> }
>
>
> And then refer to the controller (respective port) as, for example,
>
> \_SB_.PCI0.SMBS.SMB1
>
> in your SSDT. Note, the above _ADR assignments you should also add to SSDT
> (better to the same one).
>
> > }
> > ```
> > And produces several I2C busses to the system:
> > ```
> > i2c-7 unknown SMBus PIIX4 adapter port 0 at 0b00 N/A
> > i2c-8 unknown SMBus PIIX4 adapter port 2 at 0b00 N/A
> > i2c-9 unknown SMBus PIIX4 adapter port 1 at 0b20 N/A
> > ```
> >
> > No matter how I've tried, I can't get to add my custom devices to
> > these SMBus buses.
> >
> > Apparently just using "\\_SB.PCI0.SMBS" is not enough for this case.
> > Maybe I need to somehow create port nodes for this Device? Or maybe it
> > is not possible at all with the current piix driver?
> >
> > Anyway I've started digging and I've noticed that for the I2C device
> > there are two physical_nodes in the sysfs. Where the 'physical_node'
> > is a standard folder and 'physical_node1' is a direct link to the
> > proper i2c bus:
>
> > Maybe I need to modify ACPI code somehow to create these
> > 'physical_nodesX' folders for the relevant i2c-7/8/9 buses?
>
> If you succeed with the above, please add the respective section to
> the Documentation/i2c/busses/i2c-piix4.rst and send a patch. It will
> be very appreciated!
The last but not least remark: you have to load your SSDT _before_ the driver,
which means the only methods you may use either initramfs or EFI variable.
ACPI ConfigFS won't work!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-07 15:51 Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method Konstantin Aladyshev
2024-11-08 8:26 ` Andy Shevchenko
@ 2024-11-08 8:46 ` Andy Shevchenko
2024-11-08 9:27 ` Florian Eckert
1 sibling, 1 reply; 10+ messages in thread
From: Andy Shevchenko @ 2024-11-08 8:46 UTC (permalink / raw)
To: Konstantin Aladyshev, Florian Eckert; +Cc: linux-acpi, linux-i2c
+Cc: Florian (as this indeed rang a bell to me)
https://lore.kernel.org/all/d84fb798722762862a7fb08f1e343b6a@dev.tdt.de/
On Thu, Nov 07, 2024 at 06:51:03PM +0300, Konstantin Aladyshev wrote:
> Hello!
>
> I'm trying to add I2C devices to I2C/SMBus buses via the ACPI SSDT
> overlay method. I've managed to do it for the I2C buses, but can't get
> it working for the SMBus (PIIX4).
>
> Now the long description of what I've tried and learned.
>
> I've successfully managed to add my I2C devices to the I2C buses. In
> this case I2C buses are described in the ACPI code of my system like
> this:
> ```
> Device (I2CF)
> {
> Name (_HID, "AMDI0010")
> Name (_UID, 0x05)
> Method (_CRS, 0, Serialized) {...}
> Method (_STA, 0, NotSerialized) {...}
> }
> ```
>
> These buses are present in the system as:
> ```
> $ i2cdetect -l
> i2c-0 unknown Synopsys DesignWare I2C adapter N/A
> ...
> ```
>
> For my custom device (at24 EEPROM) I've created SSDT table:
> ```
> DefinitionBlock ("at24.aml", "SSDT", 5, "", "AT24", 1)
> {
> External (_SB_.I2CF, DeviceObj)
>
> Scope (\_SB.I2CF)
> {
> Device (EEP0) {
> Name (_HID, "PRP0001")
> Name (_DDN, "Atmel AT24 compatible EEPROM")
> Name (_CRS, ResourceTemplate () {
> I2cSerialBusV2 (
> 0x0050, // I2C Slave Address
> ControllerInitiated,
> 400000, // Bus speed
> AddressingMode7Bit,
> "\\_SB.I2CF", // Link to ACPI I2C host controller
> 0
> )
> })
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () { "compatible", Package() { "atmel,24c128" } },
> }
> })
> }
> }
> }
> ```
>
> And after I've loaded it via 'acpi_configfs' I can successfully see
> EEPROM in the system:
> ```
> root@ubuntu-SP3:/home/ubuntu/acpi/custom# hexdump -C
> /sys/bus/i2c/devices/i2c-PRP0001\:00/eeprom
> 00000000 63 6a a9 05 00 65 14 35 9f 81 a7 60 aa c2 18 d2 |cj...e.5...`....|
> 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> *
> 00004000
> ```
>
>
> Now I'm trying to add devices to the SMBus bus. Which in my case is
> produced from the i2c_piix4 PCI device:
> ```
> $ lspci -s 00:14.0 -vvvxxx
> 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
> Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> NUMA node: 0
> IOMMU group: 58
> Kernel driver in use: piix4_smbus
> Kernel modules: i2c_piix4, sp5100_tco
> 00: 22 10 0b 79 03 04 20 02 61 00 05 0c 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 22 10 0b 79
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ```
>
> It is described as simple as this in the system ACPI code:
> ```
> Device (SMBS) // \_SB_.PCI0.SMBS
> {
> Name (_ADR, 0x00140000) // _ADR: Address
> }
> ```
> And produces several I2C busses to the system:
> ```
> i2c-7 unknown SMBus PIIX4 adapter port 0 at 0b00 N/A
> i2c-8 unknown SMBus PIIX4 adapter port 2 at 0b00 N/A
> i2c-9 unknown SMBus PIIX4 adapter port 1 at 0b20 N/A
> ```
>
> No matter how I've tried, I can't get to add my custom devices to
> these SMBus buses.
>
> Apparently just using "\\_SB.PCI0.SMBS" is not enough for this case.
> Maybe I need to somehow create port nodes for this Device? Or maybe it
> is not possible at all with the current piix driver?
>
> Anyway I've started digging and I've noticed that for the I2C device
> there are two physical_nodes in the sysfs. Where the 'physical_node'
> is a standard folder and 'physical_node1' is a direct link to the
> proper i2c bus:
> ```
> $ ls -la /sys/bus/acpi/devices/AMDI0010\:03/
> total 0
> drwxr-xr-x 4 root root 0 Nov 7 18:07 .
> drwxr-xr-x 294 root root 0 Nov 7 18:05 ..
> -r--r--r-- 1 root root 4096 Nov 7 18:06 hid
> -r--r--r-- 1 root root 4096 Nov 7 18:06 modalias
> -r--r--r-- 1 root root 4096 Nov 7 18:06 path
> lrwxrwxrwx 1 root root 0 Nov 7 18:06 physical_node ->
> ../../../platform/AMDI0010:03
> lrwxrwxrwx 1 root root 0 Nov 7 18:06 physical_node1 ->
> ../../../platform/AMDI0010:03/i2c-1
> drwxr-xr-x 2 root root 0 Nov 7 18:06 power
> -r--r--r-- 1 root root 4096 Nov 7 18:06 status
> lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../../bus/acpi
> -rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
> -r--r--r-- 1 root root 4096 Nov 7 18:06 uid
> drwxr-xr-x 3 root root 0 Nov 7 18:05 wakeup
>
> $ ls -la /sys/bus/acpi/devices/AMDI0010\:03/physical_node/
> total 0
> drwxr-xr-x 4 root root 0 Nov 7 18:08 .
> drwxr-xr-x 7335 root root 0 Nov 7 18:05 ..
> lrwxrwxrwx 1 root root 0 Nov 7 18:05 driver ->
> ../../../bus/platform/drivers/i2c_designware
> -rw-r--r-- 1 root root 4096 Nov 7 18:08 driver_override
> lrwxrwxrwx 1 root root 0 Nov 7 18:08 firmware_node ->
> ../../LNXSYSTM:00/LNXSYBUS:00/AMDI0010:03
> drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-1
> -r--r--r-- 1 root root 4096 Nov 7 18:08 modalias
> drwxr-xr-x 2 root root 0 Nov 7 18:08 power
> lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../bus/platform
> -rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
>
> $ ls -la /sys/bus/acpi/devices/AMDI0010\:03/physical_node1/
> total 0
> drwxr-xr-x 4 root root 0 Nov 7 18:08 .
> drwxr-xr-x 4 root root 0 Nov 7 18:08 ..
> --w------- 1 root root 4096 Nov 7 18:08 delete_device
> lrwxrwxrwx 1 root root 0 Nov 7 18:08 device -> ../../AMDI0010:03
> lrwxrwxrwx 1 root root 0 Nov 7 18:08 firmware_node ->
> ../../../LNXSYSTM:00/LNXSYBUS:00/AMDI0010:03
> drwxr-xr-x 3 root root 0 Nov 7 18:05 i2c-dev
> -r--r--r-- 1 root root 4096 Nov 7 18:05 name
> --w------- 1 root root 4096 Nov 7 18:08 new_device
> drwxr-xr-x 2 root root 0 Nov 7 18:08 power
> lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../../bus/i2c
> -rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
> -r--r--r-- 1 root root 4096 Nov 7 18:08 waiting_for_supplier
> ```
>
> But in the case of SMBus there is only one 'physical_node' folder (but
> 3 i2c buses) :
> ```
> $ ls -l /sys/bus/acpi/devices/device\:25/
> total 0
> -r--r--r-- 1 root root 4096 Nov 7 18:07 adr
> -r--r--r-- 1 root root 4096 Nov 7 18:07 path
> lrwxrwxrwx 1 root root 0 Nov 7 18:07 physical_node ->
> ../../../../pci0000:00/0000:00:14.0
> drwxr-xr-x 2 root root 0 Nov 7 18:07 power
> lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../../../bus/acpi
> -rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
> drwxr-xr-x 3 root root 0 Nov 7 18:05 wakeup
>
> $ ls -l /sys/bus/acpi/devices/device\:25/physical_node/
> total 0
> -r--r--r-- 1 root root 4096 Nov 7 18:07 ari_enabled
> -rw-r--r-- 1 root root 4096 Nov 7 18:07 broken_parity_status
> -r--r--r-- 1 root root 4096 Nov 7 18:05 class
> -rw-r--r-- 1 root root 256 Nov 7 18:07 config
> -r--r--r-- 1 root root 4096 Nov 7 18:07 consistent_dma_mask_bits
> -rw-r--r-- 1 root root 4096 Nov 7 18:07 d3cold_allowed
> -r--r--r-- 1 root root 4096 Nov 7 18:05 device
> -r--r--r-- 1 root root 4096 Nov 7 18:07 dma_mask_bits
> lrwxrwxrwx 1 root root 0 Nov 7 18:05 driver ->
> ../../../bus/pci/drivers/piix4_smbus
> -rw-r--r-- 1 root root 4096 Nov 7 18:07 driver_override
> -rw-r--r-- 1 root root 4096 Nov 7 18:07 enable
> lrwxrwxrwx 1 root root 0 Nov 7 18:07 firmware_node ->
> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:25
> drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-7
> drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-8
> drwxr-xr-x 4 root root 0 Nov 7 18:05 i2c-9
> lrwxrwxrwx 1 root root 0 Nov 7 18:07 iommu -> ../0000:00:00.2/iommu/ivhd3
> lrwxrwxrwx 1 root root 0 Nov 7 18:07 iommu_group ->
> ../../../kernel/iommu_groups/58
> -r--r--r-- 1 root root 4096 Nov 7 18:07 irq
> drwxr-xr-x 2 root root 0 Nov 7 18:07 link
> -r--r--r-- 1 root root 4096 Nov 7 18:07 local_cpulist
> -r--r--r-- 1 root root 4096 Nov 7 18:07 local_cpus
> -r--r--r-- 1 root root 4096 Nov 7 18:07 modalias
> -rw-r--r-- 1 root root 4096 Nov 7 18:07 msi_bus
> -rw-r--r-- 1 root root 4096 Nov 7 18:07 numa_node
> drwxr-xr-x 2 root root 0 Nov 7 18:07 power
> -r--r--r-- 1 root root 4096 Nov 7 18:07 power_state
> --w--w---- 1 root root 4096 Nov 7 18:07 remove
> --w------- 1 root root 4096 Nov 7 18:07 rescan
> -r--r--r-- 1 root root 4096 Nov 7 18:05 resource
> -r--r--r-- 1 root root 4096 Nov 7 18:07 revision
> lrwxrwxrwx 1 root root 0 Nov 7 18:05 subsystem -> ../../../bus/pci
> -r--r--r-- 1 root root 4096 Nov 7 18:07 subsystem_device
> -r--r--r-- 1 root root 4096 Nov 7 18:07 subsystem_vendor
> -rw-r--r-- 1 root root 4096 Nov 7 18:05 uevent
> -r--r--r-- 1 root root 4096 Nov 7 18:05 vendor
> ```
>
> Maybe I need to modify ACPI code somehow to create these
> 'physical_nodesX' folders for the relevant i2c-7/8/9 buses?
>
> Any feedback is appreciated.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-08 8:46 ` Andy Shevchenko
@ 2024-11-08 9:27 ` Florian Eckert
2024-11-08 11:23 ` Andy Shevchenko
2024-11-08 11:48 ` Konstantin Aladyshev
0 siblings, 2 replies; 10+ messages in thread
From: Florian Eckert @ 2024-11-08 9:27 UTC (permalink / raw)
To: Konstantin Aladyshev; +Cc: Andy Shevchenko, linux-acpi, linux-i2c
Hello Konstantin,
On 2024-11-08 09:46, Andy Shevchenko wrote:
> +Cc: Florian (as this indeed rang a bell to me)
>
> https://lore.kernel.org/all/d84fb798722762862a7fb08f1e343b6a@dev.tdt.de/
The message was forwarded by Andy because I had a similar problem with
my APU3 [1]
from PC-engine [2], which is also using the PIIX4 for I2C (SMBUS).
>> Maybe I need to modify ACPI code somehow to create these
>> 'physical_nodesX' folders for the relevant i2c-7/8/9 buses?
I don't know if that helps, but with the following SSDT overlay I
managed
to get the driver to feel responsible for the mcp23017 via the I2C
(SMBUS) of
the APU3. The mcp23017 is used on my APU3 to add additional LEDs to
'/sys/class/leds'.
```
DefinitionBlock ("mcp.aml", "SSDT", 5, "TEST", "MCP", 2)
{
External (\_SB.PCI0.SBUS, DeviceObj)
Scope (\_SB.PCI0.SBUS)
{
Device (I2C0)
{
Name (_ADR, Zero)
Device (GPIO)
{
Name (_HID, "PRP0001")
Name (_DDN, "MCP23017 pinctrl")
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (
0x24,
ControllerInitiated,
100000,
AddressingMode7Bit,
"\\_SB.PCI0.SBUS.I2C0",
0x00
)
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"compatible", "microchip,mcp23017" },
}
})
Device (LEDS)
{
Name (_HID, "PRP0001")
Name (_DDN, "GPIO LEDs device")
Name (_CRS, ResourceTemplate ()
{
GpioIo (
Exclusive,
PullNone,
0,
0,
IoRestrictionOutputOnly,
"\\_SB.PCI0.SBUS.I2C0.GPIO",
0)
{
0,
1,
2,
3,
4,
5,
6,
7,
}
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"compatible", Package() { "gpio-leds" } },
},
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package ()
{"led-0", "LED0"},
Package ()
{"led-1", "LED1"},
Package ()
{"led-2", "LED2"},
Package ()
{"led-3", "LED3"},
Package ()
{"led-4", "LED4"},
Package ()
{"led-5", "LED5"},
Package ()
{"led-6", "LED6"},
Package ()
{"led-7", "LED7"},
}
})
Name (LED0, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:green:led1"},
Package ()
{"default-state", "off"},
Package ()
{"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 0, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
Name (LED1, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:green:led2"},
Package ()
{"default-state", "off"},
Package
() {"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 1, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
Name (LED2, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:green:led3"},
Package ()
{"default-state", "off"},
Package ()
{"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 2, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
Name (LED3, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:green:led4"},
Package ()
{"default-state", "off"},
Package ()
{"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 3, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
Name (LED4, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:green:led5"},
Package ()
{"default-state", "off"},
Package ()
{"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 4, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
Name (LED5, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:green:led6"},
Package ()
{"default-state", "off"},
Package ()
{"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 5, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
Name (LED6, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:green:led7"},
Package ()
{"default-state", "off"},
Package ()
{"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 6, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
Name (LED7, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package ()
{"label", "khan:red:led8"},
Package ()
{"default-state", "off"},
Package ()
{"linux,default-trigger", "default-off"},
Package ()
{"gpios", Package () {^LEDS, 0, 7, 1}},
Package ()
{"retain-state-suspended", 1},
}
})
}
}
}
}
}
```
Best regards
Florian
[1] https://pcengines.ch/apu3d4.htm
[2] https://pcengines.ch/
[3]
https://github.com/pcengines/coreboot/blob/8d3e714804b1b2bb5bc89e3ffd9cb3c34f8eb0c6/src/southbridge/amd/pi/hudson/acpi/fch.asl#L29
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-08 9:27 ` Florian Eckert
@ 2024-11-08 11:23 ` Andy Shevchenko
2024-11-08 11:48 ` Konstantin Aladyshev
1 sibling, 0 replies; 10+ messages in thread
From: Andy Shevchenko @ 2024-11-08 11:23 UTC (permalink / raw)
To: Florian Eckert; +Cc: Konstantin Aladyshev, linux-acpi, linux-i2c
On Fri, Nov 08, 2024 at 10:27:08AM +0100, Florian Eckert wrote:
> On 2024-11-08 09:46, Andy Shevchenko wrote:
> > +Cc: Florian (as this indeed rang a bell to me)
> >
> > https://lore.kernel.org/all/d84fb798722762862a7fb08f1e343b6a@dev.tdt.de/
>
> The message was forwarded by Andy because I had a similar problem with my
> APU3 [1]
> from PC-engine [2], which is also using the PIIX4 for I2C (SMBUS).
>
> > > Maybe I need to modify ACPI code somehow to create these
> > > 'physical_nodesX' folders for the relevant i2c-7/8/9 buses?
>
> I don't know if that helps, but with the following SSDT overlay I managed
> to get the driver to feel responsible for the mcp23017 via the I2C (SMBUS)
> of the APU3. The mcp23017 is used on my APU3 to add additional LEDs to
> '/sys/class/leds'.
Thanks for prompt response!
Can you, folks, elaborate and update the in-kernel documentation [1]
by adding a section to it for the above topic, so next time I have got
a Q like this I can point to there?
[1]: Documentation/i2c/busses/i2c-piix4.rst
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-08 9:27 ` Florian Eckert
2024-11-08 11:23 ` Andy Shevchenko
@ 2024-11-08 11:48 ` Konstantin Aladyshev
2024-11-08 12:47 ` Andy Shevchenko
1 sibling, 1 reply; 10+ messages in thread
From: Konstantin Aladyshev @ 2024-11-08 11:48 UTC (permalink / raw)
To: Florian Eckert; +Cc: Andy Shevchenko, linux-acpi, linux-i2c
Thanks for the help!
I've created the following SSDT:
```
DefinitionBlock ("at24.aml", "SSDT", 5, "", "AT24", 1)
{
External (_SB_.PCI0.SMBS, DeviceObj)
Scope (\_SB_.PCI0.SMBS)
{
Device (SMB0) {
Name (_ADR, 0)
}
Device (SMB1) {
Name (_ADR, 1)
}
Device (SMB2) {
Name (_ADR, 2)
}
}
Scope (\_SB.PCI0.SMBS)
{
Device (EEP0) {
Name (_HID, "PRP0001")
Name (_DDN, "Atmel AT24 compatible EEPROM")
Name (_CRS, ResourceTemplate () {
I2cSerialBusV2 (
0x0050, // I2C Slave Address
ControllerInitiated,
400000, // Bus speed
AddressingMode7Bit,
"\\_SB.PCI0.SMBS.SMB0", // Link to ACPI I2C host
controller
0
)
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", Package() { "atmel,24c128" } },
}
})
}
}
}
```
and have added it via initrd.
I think I've tried this ACPI code before, but only via acpi_configfs,
which apparently was too late.
Now I can see that SMBS device contains 3 subdevices for the relevant
i2c busses:
```
$ cat /sys/bus/acpi/devices/device\:25/path
\_SB_.PCI0.SMBS
$ ls -l /sys/bus/acpi/devices/device\:25/
total 0
-r--r--r-- 1 root root 4096 Nov 8 12:23 adr
drwxr-xr-x 3 root root 0 Nov 8 12:21 device:26
drwxr-xr-x 3 root root 0 Nov 8 12:21 device:27
drwxr-xr-x 3 root root 0 Nov 8 12:21 device:28
-r--r--r-- 1 root root 4096 Nov 8 12:23 path
lrwxrwxrwx 1 root root 0 Nov 8 12:23 physical_node ->
../../../../pci0000:00/0000:00:14.0
drwxr-xr-x 2 root root 0 Nov 8 12:23 power
drwxr-xr-x 3 root root 0 Nov 8 12:21 PRP0001:00
lrwxrwxrwx 1 root root 0 Nov 8 12:21 subsystem -> ../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Nov 8 12:21 uevent
drwxr-xr-x 3 root root 0 Nov 8 12:21 wakeup
$ ls -l /sys/bus/acpi/devices/device\:25/device\:26/
total 0
-r--r--r-- 1 root root 4096 Nov 8 12:23 adr
-r--r--r-- 1 root root 4096 Nov 8 12:23 path
lrwxrwxrwx 1 root root 0 Nov 8 12:23 physical_node ->
../../../../../pci0000:00/0000:00:14.0/i2c-7
drwxr-xr-x 2 root root 0 Nov 8 12:23 power
lrwxrwxrwx 1 root root 0 Nov 8 12:21 subsystem -> ../../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Nov 8 12:21 uevent
$ ls -l /sys/bus/acpi/devices/device\:25/device\:27/
total 0
-r--r--r-- 1 root root 4096 Nov 8 12:24 adr
-r--r--r-- 1 root root 4096 Nov 8 12:24 path
lrwxrwxrwx 1 root root 0 Nov 8 12:24 physical_node ->
../../../../../pci0000:00/0000:00:14.0/i2c-9
drwxr-xr-x 2 root root 0 Nov 8 12:24 power
lrwxrwxrwx 1 root root 0 Nov 8 12:21 subsystem -> ../../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Nov 8 12:21 uevent
$ ls -l /sys/bus/acpi/devices/device\:25/device\:28/
total 0
-r--r--r-- 1 root root 4096 Nov 8 12:24 adr
-r--r--r-- 1 root root 4096 Nov 8 12:24 path
lrwxrwxrwx 1 root root 0 Nov 8 12:24 physical_node ->
../../../../../pci0000:00/0000:00:14.0/i2c-8
drwxr-xr-x 2 root root 0 Nov 8 12:24 power
lrwxrwxrwx 1 root root 0 Nov 8 12:21 subsystem -> ../../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Nov 8 12:21 uevent
```
And my PRP0001 device is finally created and added to the correct bus:
```
$ ls -l /sys/bus/acpi/devices/device\:25/PRP0001\:00/
total 0
-r--r--r-- 1 root root 4096 Nov 8 12:25 hid
-r--r--r-- 1 root root 4096 Nov 8 12:25 modalias
-r--r--r-- 1 root root 4096 Nov 8 12:25 path
lrwxrwxrwx 1 root root 0 Nov 8 12:25 physical_node ->
../../../../../pci0000:00/0000:00:14.0/i2c-7/i2c-PRP0001:00
drwxr-xr-x 2 root root 0 Nov 8 12:25 power
lrwxrwxrwx 1 root root 0 Nov 8 12:21 subsystem -> ../../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Nov 8 12:21 uevent
```
However I was using the at24 device only as an example.
My real target device is jc42
(https://github.com/torvalds/linux/blob/906bd684e4b1e517dd424a354744c5b0aebef8af/drivers/hwmon/jc42.c#L600).
Here you can see that I can actually provide a driver for it and use:
```
# echo jc42 0x30 > /sys/bus/i2c/devices/i2c-7/new_device
# i2cdetect -y 7
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: 10 11 -- -- -- -- -- -- -- -- -- -- UU -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- 35 36 -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- 4a -- -- -- -- --
50: -- -- -- -- 54 -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- 73 -- -- -- --
# cat /sys/bus/i2c/devices/i2c-7/7-001c/hwmon/hwmon4/temp1_input
34000
```
But when I try to perform binding via ACPI, device is created, but for
some reason driver is not connected:
```
$ sudo i2cdetect -y 7
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: 10 11 -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- 35 36 -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- 4a -- -- -- -- --
50: -- -- -- -- 54 -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- 73 -- -- -- --
$ cat /sys/bus/i2c/devices/i2c-7/i2c-PRP0001\:00/name
jc-42.4-temp
ubuntu@ubuntu-SP3:~$ cat /sys/bus/i2c/devices/i2c-7/i2c-PRP0001\:00/modalias
of:Njc42TCjedec,jc-42.4-temp
$ ls -l /sys/bus/i2c/devices/i2c-7/i2c-PRP0001\:00/
total 0
lrwxrwxrwx 1 root root 0 Nov 8 14:35 firmware_node ->
../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:25/PRP0001:00
-r--r--r-- 1 root root 4096 Nov 8 14:35 modalias
-r--r--r-- 1 root root 4096 Nov 8 14:33 name
drwxr-xr-x 2 root root 0 Nov 8 14:35 power
lrwxrwxrwx 1 root root 0 Nov 8 14:33 subsystem -> ../../../../../bus/i2c
-rw-r--r-- 1 root root 4096 Nov 8 14:33 uevent
-r--r--r-- 1 root root 4096 Nov 8 14:35 waiting_for_supplier
```
Does it mean that jc42 driver doesn't support ACPI binding?
Just in case here is my SSDT:
```
DefinitionBlock ("jc42.aml", "SSDT", 5, "", "JC42", 1)
{
External (_SB_.PCI0.SMBS, DeviceObj)
Scope (\_SB_.PCI0.SMBS)
{
Device (SMB0) {
Name (_ADR, 0)
}
Device (SMB1) {
Name (_ADR, 1)
}
Device (SMB2) {
Name (_ADR, 2)
}
}
Scope (\_SB.PCI0.SMBS)
{
Device (JC42) {
Name (_HID, "PRP0001")
Name (_DDN, "JC42 Temperature sensor")
Name (_CRS, ResourceTemplate () {
I2cSerialBusV2 (
0x001c, // I2C Slave Address
ControllerInitiated,
400000, // Bus speed
AddressingMode7Bit,
"\\_SB.PCI0.SMBS.SMB0", // Link to ACPI I2C host
controller
0
)
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", Package() {
"jedec,jc-42.4-temp" } },
}
})
}
}
}
```
Best regards,
Konstantin Aladyshev
On Fri, Nov 8, 2024 at 12:27 PM Florian Eckert <fe@dev.tdt.de> wrote:
>
> Hello Konstantin,
>
> On 2024-11-08 09:46, Andy Shevchenko wrote:
> > +Cc: Florian (as this indeed rang a bell to me)
> >
> > https://lore.kernel.org/all/d84fb798722762862a7fb08f1e343b6a@dev.tdt.de/
>
> The message was forwarded by Andy because I had a similar problem with
> my APU3 [1]
> from PC-engine [2], which is also using the PIIX4 for I2C (SMBUS).
>
> >> Maybe I need to modify ACPI code somehow to create these
> >> 'physical_nodesX' folders for the relevant i2c-7/8/9 buses?
>
> I don't know if that helps, but with the following SSDT overlay I
> managed
> to get the driver to feel responsible for the mcp23017 via the I2C
> (SMBUS) of
> the APU3. The mcp23017 is used on my APU3 to add additional LEDs to
> '/sys/class/leds'.
>
> ```
> DefinitionBlock ("mcp.aml", "SSDT", 5, "TEST", "MCP", 2)
> {
> External (\_SB.PCI0.SBUS, DeviceObj)
>
> Scope (\_SB.PCI0.SBUS)
> {
> Device (I2C0)
> {
> Name (_ADR, Zero)
> Device (GPIO)
> {
> Name (_HID, "PRP0001")
> Name (_DDN, "MCP23017 pinctrl")
> Name (_CRS, ResourceTemplate ()
> {
> I2cSerialBus (
> 0x24,
> ControllerInitiated,
> 100000,
> AddressingMode7Bit,
> "\\_SB.PCI0.SBUS.I2C0",
> 0x00
> )
> })
> Name (_DSD, Package ()
> {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {
> "compatible", "microchip,mcp23017" },
> }
> })
>
> Device (LEDS)
> {
> Name (_HID, "PRP0001")
> Name (_DDN, "GPIO LEDs device")
> Name (_CRS, ResourceTemplate ()
> {
> GpioIo (
> Exclusive,
> PullNone,
> 0,
> 0,
>
> IoRestrictionOutputOnly,
>
> "\\_SB.PCI0.SBUS.I2C0.GPIO",
> 0)
> {
> 0,
> 1,
> 2,
> 3,
> 4,
> 5,
> 6,
> 7,
> }
> })
>
> Name (_DSD, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {
> "compatible", Package() { "gpio-leds" } },
> },
>
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () {
> Package ()
> {"led-0", "LED0"},
> Package ()
> {"led-1", "LED1"},
> Package ()
> {"led-2", "LED2"},
> Package ()
> {"led-3", "LED3"},
> Package ()
> {"led-4", "LED4"},
> Package ()
> {"led-5", "LED5"},
> Package ()
> {"led-6", "LED6"},
> Package ()
> {"led-7", "LED7"},
> }
> })
>
> Name (LED0, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:green:led1"},
> Package ()
> {"default-state", "off"},
> Package ()
> {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 0, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
>
> Name (LED1, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:green:led2"},
> Package ()
> {"default-state", "off"},
> Package
> () {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 1, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
>
> Name (LED2, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:green:led3"},
> Package ()
> {"default-state", "off"},
> Package ()
> {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 2, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
>
> Name (LED3, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:green:led4"},
> Package ()
> {"default-state", "off"},
> Package ()
> {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 3, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
>
> Name (LED4, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:green:led5"},
> Package ()
> {"default-state", "off"},
> Package ()
> {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 4, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
>
> Name (LED5, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:green:led6"},
> Package ()
> {"default-state", "off"},
> Package ()
> {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 5, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
>
> Name (LED6, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:green:led7"},
> Package ()
> {"default-state", "off"},
> Package ()
> {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 6, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
>
> Name (LED7, Package () {
>
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package ()
> {"label", "khan:red:led8"},
> Package ()
> {"default-state", "off"},
> Package ()
> {"linux,default-trigger", "default-off"},
> Package ()
> {"gpios", Package () {^LEDS, 0, 7, 1}},
> Package ()
> {"retain-state-suspended", 1},
> }
> })
> }
> }
> }
> }
> }
> ```
>
> Best regards
>
> Florian
>
> [1] https://pcengines.ch/apu3d4.htm
> [2] https://pcengines.ch/
> [3]
> https://github.com/pcengines/coreboot/blob/8d3e714804b1b2bb5bc89e3ffd9cb3c34f8eb0c6/src/southbridge/amd/pi/hudson/acpi/fch.asl#L29
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-08 11:48 ` Konstantin Aladyshev
@ 2024-11-08 12:47 ` Andy Shevchenko
2024-11-11 12:09 ` Konstantin Aladyshev
0 siblings, 1 reply; 10+ messages in thread
From: Andy Shevchenko @ 2024-11-08 12:47 UTC (permalink / raw)
To: Konstantin Aladyshev; +Cc: Florian Eckert, linux-acpi, linux-i2c
On Fri, Nov 08, 2024 at 02:48:44PM +0300, Konstantin Aladyshev wrote:
> Thanks for the help!
> $ cat /sys/bus/acpi/devices/device\:25/path
These cat:s you made are mostly useless in this case. And you should look for
the real device folders in sysfs and firmware_node links there.
...
> However I was using the at24 device only as an example.
> My real target device is jc42
> (https://github.com/torvalds/linux/blob/906bd684e4b1e517dd424a354744c5b0aebef8af/drivers/hwmon/jc42.c#L600).
> Does it mean that jc42 driver doesn't support ACPI binding?
Kinda. I just sent a patch, please test and provide your Tested-by if it helps.
...
> Just in case here is my SSDT:
> ```
> DefinitionBlock ("jc42.aml", "SSDT", 5, "", "JC42", 1)
> {
> External (_SB_.PCI0.SMBS, DeviceObj)
>
> Scope (\_SB_.PCI0.SMBS)
> {
> Device (SMB0) {
> Name (_ADR, 0)
> }
> Device (SMB1) {
> Name (_ADR, 1)
> }
> Device (SMB2) {
> Name (_ADR, 2)
> }
> }
>
> Scope (\_SB.PCI0.SMBS)
While this works, we expect Scope to be under the respective host controller, i.e.
Scope (\_SB.PCI0.SMBS.SMB0)
in your case.
> {
> Device (JC42) {
> Name (_HID, "PRP0001")
> Name (_DDN, "JC42 Temperature sensor")
> Name (_CRS, ResourceTemplate () {
> I2cSerialBusV2 (
> 0x001c, // I2C Slave Address
> ControllerInitiated,
> 400000, // Bus speed
> AddressingMode7Bit,
> "\\_SB.PCI0.SMBS.SMB0", // Link to ACPI I2C host
> controller
> 0
> )
> })
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () { "compatible", Package() {
> "jedec,jc-42.4-temp" } },
> }
> })
> }
> }
> }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-08 12:47 ` Andy Shevchenko
@ 2024-11-11 12:09 ` Konstantin Aladyshev
2024-11-11 12:48 ` Andy Shevchenko
0 siblings, 1 reply; 10+ messages in thread
From: Konstantin Aladyshev @ 2024-11-11 12:09 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Florian Eckert, linux-acpi, linux-i2c
Sorry, I needed some time to recompile my kernel.
I've verified your patch for the jc42 driver and it works as expected.
Now the driver correctly connects to the I2C device and the hwmon
directory created in the sysfs.
Thanks for the help!
I've also sent a patchset for the piix4 documentation update as you've
requested. Please review.
Best regards,
Konstantin Aladyshev
On Fri, Nov 8, 2024 at 3:47 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Nov 08, 2024 at 02:48:44PM +0300, Konstantin Aladyshev wrote:
> > Thanks for the help!
>
>
> > $ cat /sys/bus/acpi/devices/device\:25/path
>
> These cat:s you made are mostly useless in this case. And you should look for
> the real device folders in sysfs and firmware_node links there.
>
> ...
>
> > However I was using the at24 device only as an example.
> > My real target device is jc42
> > (https://github.com/torvalds/linux/blob/906bd684e4b1e517dd424a354744c5b0aebef8af/drivers/hwmon/jc42.c#L600).
>
> > Does it mean that jc42 driver doesn't support ACPI binding?
>
> Kinda. I just sent a patch, please test and provide your Tested-by if it helps.
>
> ...
>
> > Just in case here is my SSDT:
> > ```
> > DefinitionBlock ("jc42.aml", "SSDT", 5, "", "JC42", 1)
> > {
> > External (_SB_.PCI0.SMBS, DeviceObj)
> >
> > Scope (\_SB_.PCI0.SMBS)
> > {
> > Device (SMB0) {
> > Name (_ADR, 0)
> > }
> > Device (SMB1) {
> > Name (_ADR, 1)
> > }
> > Device (SMB2) {
> > Name (_ADR, 2)
> > }
> > }
> >
> > Scope (\_SB.PCI0.SMBS)
>
> While this works, we expect Scope to be under the respective host controller, i.e.
>
> Scope (\_SB.PCI0.SMBS.SMB0)
>
> in your case.
>
> > {
> > Device (JC42) {
> > Name (_HID, "PRP0001")
> > Name (_DDN, "JC42 Temperature sensor")
> > Name (_CRS, ResourceTemplate () {
> > I2cSerialBusV2 (
> > 0x001c, // I2C Slave Address
> > ControllerInitiated,
> > 400000, // Bus speed
> > AddressingMode7Bit,
> > "\\_SB.PCI0.SMBS.SMB0", // Link to ACPI I2C host
> > controller
> > 0
> > )
> > })
> >
> > Name (_DSD, Package () {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package () {
> > Package () { "compatible", Package() {
> > "jedec,jc-42.4-temp" } },
> > }
> > })
> > }
> > }
> > }
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method
2024-11-11 12:09 ` Konstantin Aladyshev
@ 2024-11-11 12:48 ` Andy Shevchenko
0 siblings, 0 replies; 10+ messages in thread
From: Andy Shevchenko @ 2024-11-11 12:48 UTC (permalink / raw)
To: Konstantin Aladyshev; +Cc: Florian Eckert, linux-acpi, linux-i2c
On Mon, Nov 11, 2024 at 03:09:55PM +0300, Konstantin Aladyshev wrote:
> Sorry, I needed some time to recompile my kernel.
> I've verified your patch for the jc42 driver and it works as expected.
> Now the driver correctly connects to the I2C device and the hwmon
> directory created in the sysfs.
Thank you for confirming that! It will be part of v6.13-rc1
(and the respective release).
> Thanks for the help!
You're welcome!
> I've also sent a patchset for the piix4 documentation update as you've
> requested. Please review.
Thanks, I will.
> On Fri, Nov 8, 2024 at 3:47 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Nov 08, 2024 at 02:48:44PM +0300, Konstantin Aladyshev wrote:
> > > Thanks for the help!
> >
> > > $ cat /sys/bus/acpi/devices/device\:25/path
> >
> > These cat:s you made are mostly useless in this case. And you should look for
> > the real device folders in sysfs and firmware_node links there.
> >
> > ...
> >
> > > However I was using the at24 device only as an example.
> > > My real target device is jc42
> > > (https://github.com/torvalds/linux/blob/906bd684e4b1e517dd424a354744c5b0aebef8af/drivers/hwmon/jc42.c#L600).
> >
> > > Does it mean that jc42 driver doesn't support ACPI binding?
> >
> > Kinda. I just sent a patch, please test and provide your Tested-by if it helps.
> >
> > ...
> >
> > > Just in case here is my SSDT:
> > > ```
> > > DefinitionBlock ("jc42.aml", "SSDT", 5, "", "JC42", 1)
> > > {
> > > External (_SB_.PCI0.SMBS, DeviceObj)
> > >
> > > Scope (\_SB_.PCI0.SMBS)
> > > {
> > > Device (SMB0) {
> > > Name (_ADR, 0)
> > > }
> > > Device (SMB1) {
> > > Name (_ADR, 1)
> > > }
> > > Device (SMB2) {
> > > Name (_ADR, 2)
> > > }
> > > }
> > >
> > > Scope (\_SB.PCI0.SMBS)
> >
> > While this works, we expect Scope to be under the respective host controller, i.e.
> >
> > Scope (\_SB.PCI0.SMBS.SMB0)
> >
> > in your case.
> >
> > > {
> > > Device (JC42) {
> > > Name (_HID, "PRP0001")
> > > Name (_DDN, "JC42 Temperature sensor")
> > > Name (_CRS, ResourceTemplate () {
> > > I2cSerialBusV2 (
> > > 0x001c, // I2C Slave Address
> > > ControllerInitiated,
> > > 400000, // Bus speed
> > > AddressingMode7Bit,
> > > "\\_SB.PCI0.SMBS.SMB0", // Link to ACPI I2C host
> > > controller
> > > 0
> > > )
> > > })
> > >
> > > Name (_DSD, Package () {
> > > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > Package () {
> > > Package () { "compatible", Package() {
> > > "jedec,jc-42.4-temp" } },
> > > }
> > > })
> > > }
> > > }
> > > }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-11-11 12:48 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-07 15:51 Adding I2C devices to the SMBus (PIIX4) via the ACPI SSDT overlay method Konstantin Aladyshev
2024-11-08 8:26 ` Andy Shevchenko
2024-11-08 8:29 ` Andy Shevchenko
2024-11-08 8:46 ` Andy Shevchenko
2024-11-08 9:27 ` Florian Eckert
2024-11-08 11:23 ` Andy Shevchenko
2024-11-08 11:48 ` Konstantin Aladyshev
2024-11-08 12:47 ` Andy Shevchenko
2024-11-11 12:09 ` Konstantin Aladyshev
2024-11-11 12:48 ` Andy Shevchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox