linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Florian Eckert <fe@dev.tdt.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Enrico Weigelt <info@metux.net>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jean Delvare <jdelvare@suse.com>,
	Florian.Eckert@googlemail.com, linux-gpio@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org
Subject: Re: Add a SSDT ACPI description to recognize my I2C device connected via SMBus
Date: Thu, 23 Sep 2021 23:26:18 +0300	[thread overview]
Message-ID: <CAHp75Vcc_6mcR4gC-MzVTjTBpuozMJMFTosQjpXN8A25pndNpg@mail.gmail.com> (raw)
In-Reply-To: <d84fb798722762862a7fb08f1e343b6a@dev.tdt.de>

On Thu, Sep 23, 2021 at 5:26 PM Florian Eckert <fe@dev.tdt.de> wrote:

...

> This is my aml file that I tried with. It loads but nothing happens.

It's ASL, have you compiled it?

> DefinitionBlock ("mcp23s08.aml", "SSDT", 5, "", "IO", 2)
> {
>      External (\_SB.PCI0.SBUS, DeviceObj)
>
>      Device (\_SB.PCI0.SBUS.BUS0)
>      {

>          Name (_CID, "smbus")
>          NAME (_ADR, Zero)

This seems not right.

First of all, using _ADR along with _HID or _CID is against ACPI
specification. Second, the _CID value is against specification. (AR:
Please, drop _CID)

Third, what does _ADR == 0 mean? In the ACPI the _ADR == 0 for the PCI
device is only allowed for the PCI Host Bridge. What you need to put
here is the address of the PCI device, but it looks like you added the
BUS0 device which is not needed at all and ACPI tables already provide
it. Share (decompiled) DSDT of the device in question somewhere and we
can check this. (Okay, nevermind, I found something, see below)

>          Device (PIN)
>          {
>              Name (_HID, "PRP0001")
>              Name (_DDN, "io expander")
>              Name (_CRS, ResourceTemplate () {
>                  I2cSerialBus (
>                      0x24,                   // Bus address

Bus?! It's a slave address, i.e. your MCP chip address.

>                      ControllerInitiated,    // Don't care
>                      400000,                 // Fast mode (400 kHz)
>                      AddressingMode7Bit,     // 7-bit addressing
>                      "\\_SB.PCI0.SBUS.BUS0", // I2C host controller

Should be double checked, see above. Otherwise it seems good.

>                      0                       // Must be 0
>                  )
>              })
>
>              Name (_DSD, Package () {
>                  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>                  Package () {
>                      Package () { "compatible", Package () {
> "microchip,mcp23017" } },

Have you read https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt
just in case?

(I think compatible should be enough, but who knows)

>                  }
>              })
>          }
>      }
> }
>
> In Coreboot the SMBus named SBUS and is on address 0x0014000 [7].

Exactly. It means 00:14.0 in BDF notation.

> But I'm not sure if that's right at all.
> Somehow I don't understand how the io expander is connected to SMBus.
> According to my research, however, it should fit.
>
> The SMBus device driver i2c-piix4 creates 3 I2C devices:
> ls -la /sys/bus/i2c/devices/
> ../../../devices/pci0000:00/0000:00:14.0/i2c-0 (SMBus PIIX4 adapter port
> 0 at 0b00)
> ../../../devices/pci0000:00/0000:00:14.0/i2c-1 (SMBus PIIX4 adapter port
> 2 at 0b00)

Same I/O for two different ports?!

> ../../../devices/pci0000:00/0000:00:14.0/i2c-2 (SMBus PIIX4 adapter port
> 1 at 0b20)

Ah, it looks like a multifunctional device. In that case you have to
be sure the driver of the I2C controller is ready for the ACPI
enumeration (seems not). Basically you may use _ADR == 0, 1, ... for
children, but you need to document this and agree with AMD on the use.

Okay, it seems it has this:
  https://elixir.bootlin.com/linux/v5.15-rc2/source/drivers/i2c/i2c-mux.c#L396
which should populate a firmware node to a certain child.

> The mcp23s08 is connected to the i2c-0 with address 0x24

The mcp23s08 can not be connected to I2C. It's a SPI device.
Which chip do you actually have? I believe it's MCP23017 or MCP23018,
which is I2C.


Summary:
1) _CID notation is wrong in ASL;
2) driver seems supports the _ADR schema which you have used in ASL;
3) something fishy about I/O addresses in the sysfs (is it a typo when
you composed the email?);
4) it's unclear what you did with ASL to get it loaded;
5) as Mika suggested, have you checked the kernel configuration?

Otherwise I can't see anything else suspicious here.

-- 
With Best Regards,
Andy Shevchenko

  parent reply	other threads:[~2021-09-23 20:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07 17:38 [PATCH v1 1/9] pinctrl: mcp23s08: Get rid of legacy platform data Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 2/9] pinctrl: mcp23s08: Deduplicate IRQ chip filling Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 3/9] pinctrl: mcp23s08: Consolidate SPI and I²C code Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 4/9] pinctrl: mcp23s08: Drop unused parameter in mcp23s08_probe_one() Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 5/9] pinctrl: mcp23s08: Refactor mcp23s08_spi_regmap_init() Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 6/9] pinctrl: mcp23s08: Propagate error code from device_property_read_u32() Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 7/9] pinctrl: mcp23s08: Make use of device properties Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 8/9] pinctrl: mcp23s08: Use for_each_set_bit() and hweight_long() Andy Shevchenko
2020-04-07 17:38 ` [PATCH v1 9/9] pinctrl: mcp23s08: Split to three parts: core, I²C, SPI Andy Shevchenko
2020-04-16 10:35 ` [PATCH v1 1/9] pinctrl: mcp23s08: Get rid of legacy platform data Linus Walleij
2020-10-09  9:15   ` Martin Hundebøll
2020-10-09 14:02     ` Andy Shevchenko
2020-10-09 16:02       ` Andy Shevchenko
2021-09-16 12:51 ` Florian Eckert
2021-09-22  6:36   ` Andy Shevchenko
2021-09-22  7:53     ` Andy Shevchenko
2021-09-23 14:17       ` Add a SSDT ACPI description to recognize my I2C device connected via SMBus Florian Eckert
2021-09-23 16:24         ` Mika Westerberg
2021-09-23 20:26         ` Andy Shevchenko [this message]
2021-09-23 20:29           ` Andy Shevchenko
2021-09-29 22:40           ` Florian Eckert
2021-09-30  6:15             ` Andy Shevchenko
2021-09-30  6:19               ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHp75Vcc_6mcR4gC-MzVTjTBpuozMJMFTosQjpXN8A25pndNpg@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=Florian.Eckert@googlemail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=fe@dev.tdt.de \
    --cc=info@metux.net \
    --cc=jdelvare@suse.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).