Using AMC6821 I2C fan controller?

[kreyszig]

Hi,

I would like to use the AMC6821 I2C fan controller that came on my SolidRun HoneyComb LX2 (NXP LX2160) board, but it does load properly in FreeBSD (13.2-RELEASE). I can only see it with devinfo:

devinfo -v | grep I2C
unknown pnpinfo _HID=NXP0001 _UID=0 _CID=none at handle=\_SB_.I2C0
unknown pnpinfo _HID=NXP0002 _UID=0 _CID=none at handle=\_SB_.I2C0.MUX0
unknown pnpinfo _HID=PRP0001 _UID=0 _CID=none at handle=\_SB_.I2C0.MUX0.CH01.FAN1
unknown pnpinfo _HID=PRP0001 _UID=1 _CID=none at handle=\_SB_.I2C0.MUX0.CH03.THE1
unknown pnpinfo _HID=NXP0001 _UID=1 _CID=none at handle=\_SB_.I2C1

What do you think could be needed to get it to work properly?

Thank you!

 

[George]

Try bios/uefi settings. Maybe there is an option for automatic mode. FreeBSD has no fan driver (yet) except the acpi_ibm driver for thinkpads.

 

[kreyszig]

Try bios/uefi settings. Maybe there is an option for automatic mode. FreeBSD has no fan driver (yet) except the acpi_ibm driver for thinkpads.

Thank you,

No there is no automatic mode as far as I know, however the bios/uefi is open source. Would there be as well a way to control it by writing a program in the user space? Where should I look for this?

 

[covacat]

if iicbus and contoller are exposed use i2c from userland

 

[Phishfry]

Indeed start with ls /dev/iic* to scan buses.
Then use sysutils/i2c-tools to probe.

Then maybe need to hack on this:
sysutils/bsdhwmon/

GitHub - koitsu/bsdhwmon: Hardware sensor monitoring utility for FreeBSD

Hardware sensor monitoring utility for FreeBSD. Contribute to koitsu/bsdhwmon development by creating an account on GitHub.

github.com

To add this if not included:

linux/drivers/hwmon/amc6821.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

 

[kreyszig]

Indeed start with ls /dev/iic* to scan buses.
Then use sysutils/i2c-tools to probe.

Then maybe need to hack on this:
sysutils/bsdhwmon/

GitHub - koitsu/bsdhwmon: Hardware sensor monitoring utility for FreeBSD

Hardware sensor monitoring utility for FreeBSD. Contribute to koitsu/bsdhwmon development by creating an account on GitHub.

github.com

To add this if not included:

linux/drivers/hwmon/amc6821.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

Thanks,

No there is no iic or smb device. What makes a device "exposed"?

 

[Phishfry]

What makes a device "exposed"?

SB_.I2C0.MUX0.CH01.FAN1

This looks like an exposed ACPI device from PNP.

So just like mentioned:

no fan driver (yet) except the acpi_ibm driver for thinkpads.

There is no acpi_amc6821 driver.

Also no userland tool exists like sysutils/bsdfan for the acpi_ibm driver

 

[kreyszig]

This looks like an exposed ACPI device from PNP.

So just like mentioned:

There is no acpi_amc6821 driver.

Also no userland tool exists like sysutils/bsdfan for the acpi_ibm driver

But if I want to write my own userland tool, I will have to connect it to an ACPI device and not a device in /dev correct?

 

[Phishfry]

I will have to connect it to an ACPI device and not a device in /dev correct

The userland program would hook into acpi_honeycomb driver that does not exist.

 

[Phishfry]

This HoneyComb is high end Arm board.

I see some developers working with it here:

270805 – loader.efi: crashes with USB device attached

bugs.freebsd.org

You might want to give a shout in FreeBSD Arm Mailing List and ask what others are doing before writing any code..

 

[Phishfry]

You could probably have some control logic in acpi_honeycomb to control fans just for testing...

I believe the reason you would have acpi_driver and userland program is this:

acpi driver basically interacts with ACPI Tables for information (like sensors) and userland program does the actual logic.

21. ACPI Data Tables and Table Definition Language — ACPI Specification 6.4 documentation

 

[Phishfry]

What do you think could be needed to get it to work properly?

I think we all missed something very basic. Is iic/iicbus module even loadered on this box?

kldstat
kldload iic
ls /dev

 

[kreyszig]

The userland program would hook into acpi_honeycomb driver that does not exist.

Ok so I would need to write a kernel driver regardless to access the device from userland?

 

[kreyszig]

You could probably have some control logic in acpi_honeycomb to control fans just for testing...

I believe the reason you would have acpi_driver and userland program is this:

acpi driver basically interacts with ACPI Tables for information (like sensors) and userland program does the actual logic.

21. ACPI Data Tables and Table Definition Language — ACPI Specification 6.4 documentation

Ok thanks I will look at this

 

[kreyszig]

I think we all missed something very basic. Is iic/iicbus module even loadered on this box?

kldstat
kldload iic
ls /dev

No I did try loading iic and no device appeared. There was no output about a device found in dmesg either.

 

[kreyszig]

I am starting to write an acpi module to expose the i2c device. I have this in my ACPI table:

Device (MUX0)
{
Name (_HID, "NXP0002") // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
I2cSerialBusV2 (0x0077, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.I2C0",
0x00, ResourceConsumer, , Exclusive,
)
})
Device (CH01)
{
Name (_ADR, One) // _ADR: Address
Name (_UID, One) // _UID: Unique ID
Device (FAN1)
{
Name (_HID, "PRP0001") // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
I2cSerialBusV2 (0x0018, ControllerInitiated, 0x000186A0,
AddressingMode7Bit, "\\_SB.I2C0.MUX0.CH01",
0x00, ResourceConsumer, , Exclusive,
)
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"compatible",
"ti,amc6821"
}
}
})
}
}

I am able to probe "NXP002" with the following code:

static char *honeycomb_ids[] = {"NXP0002", NULL};

static int
acpi_honeycomb_probe(device_t dev)
{
int rv;

if (acpi_disabled("honeycomb") || device_get_unit(dev) != 0)
return (ENXIO);
rv = ACPI_ID_PROBE(device_get_parent(dev), dev, honeycomb_ids, NULL);

if (rv <= 0)
device_set_desc(dev, "HoneyComb ACPI Extras");

return (rv);
}

However I don't really know what to do to generate the iic device from there, or to communicate with it from the ACPI module? Thanks!

 

[kreyszig]

Would that be correct? I have no idea if FreeBSD extracts the 0x0018 address from the _CRS entry using iicbus_get_addr? iicbus_get_addr returns 176, I don't know if it shifts 0x0018 to that or not?

static char *amc6821_ids[] = {"PRP0001", NULL};

static int
amc6821_acpi_probe(device_t dev)
{
int rv;

if (acpi_disabled("amc6821") || device_get_unit(dev) != 0)
return (ENXIO);
rv = ACPI_ID_PROBE(device_get_parent(dev), dev, amc6821_ids, NULL);

if (rv <= 0)
device_set_desc(dev, "AMC6821 Integrated PWM fan controller");

return (rv);
}

static int
amc6821_acpi_attach(device_t dev)
{
struct amc6821_softc *sc;

sc = device_get_softc(dev);
sc->sc_dev = dev;
sc->sc_addr = iicbus_get_addr(dev);

return (0);
}

 

[kreyszig]

I just came across this: https://reviews.freebsd.org/D24917 . So it looks there should be I2C support on FreeBSD for my LX2160 SOC! However on my system The Vybrid I2C controller does not get detected. I am using 14.0-RELEASE-p3 with the GENERIC arm64 kernel.

Compared to this dmesg output I have found: https://gist.github.com/agrajag9/bbb49048447510a128cb3304546e174b , mine says

memac_mdio_acpi0: <Freescale XGMAC MDIO Bus> iomem 0x8b96000-0x8b96fff irq 7 on acpi0
memacphy_acpi0: <MEMAC PHY (acpi)> on memac_mdio_acpi0
memac_mdio_acpi1: <Freescale XGMAC MDIO Bus> iomem 0x8b97000-0x8b97fff irq 8 on acpi0

(same irqs as the i2c controllers)
The output I have is very similar to this one: https://gist.github.com/yarshure/b8a236734d8a39361f9e8344fffd58fa.

What can be going one? Thanks!