mbox series

[RFC,0/6] i2c: Enabling use of aspeed-i2c with ACPI

Message ID 20230525152203.32190-1-Jonathan.Cameron@huawei.com
Headers show
Series i2c: Enabling use of aspeed-i2c with ACPI | expand

Message

Jonathan Cameron May 25, 2023, 3:21 p.m. UTC 
From the school of dirty hacks we do to prove something works, enable
work to proceed elsewhere:

MCTP over I2C from ACPI emulated hosts (both x86 and ARM64).

The first 4 patches might be suitable for upstream inclusion, the
last two not - though I hope we can move to Niyas' work on ACPI clock
management once that is ready.

Why do this crazy thing?

Ultimately we want a standards based way to use the CXL Fabric Management
API FM-API. In real systems that is likely to be driven from a separate
'host' such as a BMC, but for test purposes it is convenient to be able
to do that from an QEMU emulated machine that is also capable of using
the CXL kernel stack.

That CXL kernel stack is currently ACPI only (and people care about
x86 for some reason). One of the defined interfaces over which FM-API
commands can be issued is MCTP.

The kernel MCTP stack has upstream drivers for MCTP over I2C.
Upstream QEMU emulates the Aspeed I2C controller with the necessary
two way support. There are patches on list adding the MCTP parts
https://lore.kernel.org/qemu-devel/20230425063540.46143-2-its@irrelevant.dk/
and I've ported an earlier CXL FMAPI EP emulator over to that.

ACPI has a 'magic' HID of PRP0001 which allows the use of a device tree binding
(mostly) with an ACPI DSDT entry.  A suitable chunk is something like

(dumped from a working x86 setup)

    Device (MCTP)
    {
        Name (_HID, "PRP0001")  // _HID: Hardware ID
        Name (_DSD, Package (0x02)  // _DSD: Device-Specific Data
        {
            ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
            Package (0x03)
            {
                Package (0x02)
                {
                     "compatible",
                     "aspeed,ast2600-i2c-bus"
                },
                Package (0x02)
                {
                    "bus-frequency",
                    0x00061A80
                },
                Package (0x02)
                {
                    "mctp-controller",
                    One
                }
            }
        })
        Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
        {
            QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
                0x0000000000000000, // Granularity
                0x00000004800FC080, // Range Minimum
                0x00000004800FC0FF, // Range Maximum
                0x0000000000000000, // Translation Offset
                0x0000000000000080, // Length
                ,, , AddressRangeMemory, TypeStatic)
            Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
            {
                0x00000007,
            }
        })
    }
    Device (MCTS)
    {
        Name (_HID, "PRP0001")  // _HID: Hardware ID
        Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
        {
            I2cSerialBusV2 (0x0050, DeviceInitiated, 0x000186A0,
                AddressingMode7Bit, "\\_SB.MCTP",
                0x00, ResourceProducer, , Exclusive,
                )
        })
        Name (_DSD, Package (0x02)  // _DSD: Device-Specific Data
        {
            ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
            Package (0x01)
            {
                Package (0x02)
                {
                    "compatible",
                    "mctp-i2c-controller"
                }
            }
        })
    }

QEMU patches will follow soon and will include documentation on
how to actually poke this to do something useful. I'll post a reply
to this with the link when posted.

Cc: Niyas Sait <niyas.sait@linaro.org>
Cc: Klaus Jensen <its@irrelevant.dk>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Jeremy Kerr <jk@codeconstruct.com.au>
Cc: Matt Johnston <matt@codeconstruct.com.au>
Cc: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>

Jonathan Cameron (6):
  i2c: acpi: set slave mode flag
  i2c: aspeed: Use platform_get_irq() instead of opencoding
  i2c: aspeed: switch to generic fw properties.
  i2c: aspeed: Set the fwnode for the adap->dev
  HACK: i2c: aspeed: Comment the clock and reset out.
  HACK: i2c: aspeed: Enable build without COMPILE_TEST

 drivers/i2c/busses/Kconfig      |  1 -
 drivers/i2c/busses/i2c-aspeed.c | 36 ++++++++++++++++-----------------
 drivers/i2c/i2c-core-acpi.c     |  3 +++
 3 files changed, 20 insertions(+), 20 deletions(-)


base-commit: f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6

Comments

Jonathan Cameron May 25, 2023, 4:18 p.m. UTC | #1 
On Thu, 25 May 2023 16:21:57 +0100
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:

> From the school of dirty hacks we do to prove something works, enable
> work to proceed elsewhere:
> 
> MCTP over I2C from ACPI emulated hosts (both x86 and ARM64).
> 
> The first 4 patches might be suitable for upstream inclusion, the
> last two not - though I hope we can move to Niyas' work on ACPI clock
> management once that is ready.
> 
> Why do this crazy thing?
> 
> Ultimately we want a standards based way to use the CXL Fabric Management
> API FM-API. In real systems that is likely to be driven from a separate
> 'host' such as a BMC, but for test purposes it is convenient to be able
> to do that from an QEMU emulated machine that is also capable of using
> the CXL kernel stack.
> 
> That CXL kernel stack is currently ACPI only (and people care about
> x86 for some reason). One of the defined interfaces over which FM-API
> commands can be issued is MCTP.
> 
> The kernel MCTP stack has upstream drivers for MCTP over I2C.
> Upstream QEMU emulates the Aspeed I2C controller with the necessary
> two way support. There are patches on list adding the MCTP parts
> https://lore.kernel.org/qemu-devel/20230425063540.46143-2-its@irrelevant.dk/
> and I've ported an earlier CXL FMAPI EP emulator over to that.
> 
> ACPI has a 'magic' HID of PRP0001 which allows the use of a device tree binding
> (mostly) with an ACPI DSDT entry.  A suitable chunk is something like
> 
> (dumped from a working x86 setup)
> 
>     Device (MCTP)
>     {
>         Name (_HID, "PRP0001")  // _HID: Hardware ID
>         Name (_DSD, Package (0x02)  // _DSD: Device-Specific Data
>         {
>             ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
>             Package (0x03)
>             {
>                 Package (0x02)
>                 {
>                      "compatible",
>                      "aspeed,ast2600-i2c-bus"
>                 },
>                 Package (0x02)
>                 {
>                     "bus-frequency",
>                     0x00061A80
>                 },
>                 Package (0x02)
>                 {
>                     "mctp-controller",
>                     One
>                 }
>             }
>         })
>         Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
>         {
>             QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
>                 0x0000000000000000, // Granularity
>                 0x00000004800FC080, // Range Minimum
>                 0x00000004800FC0FF, // Range Maximum
>                 0x0000000000000000, // Translation Offset
>                 0x0000000000000080, // Length
>                 ,, , AddressRangeMemory, TypeStatic)
>             Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
>             {
>                 0x00000007,
>             }
>         })
>     }
>     Device (MCTS)
>     {
>         Name (_HID, "PRP0001")  // _HID: Hardware ID
>         Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
>         {
>             I2cSerialBusV2 (0x0050, DeviceInitiated, 0x000186A0,
>                 AddressingMode7Bit, "\\_SB.MCTP",
>                 0x00, ResourceProducer, , Exclusive,
>                 )
>         })
>         Name (_DSD, Package (0x02)  // _DSD: Device-Specific Data
>         {
>             ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
>             Package (0x01)
>             {
>                 Package (0x02)
>                 {
>                     "compatible",
>                     "mctp-i2c-controller"
>                 }
>             }
>         })
>     }
> 
> QEMU patches will follow soon and will include documentation on
> how to actually poke this to do something useful. I'll post a reply
> to this with the link when posted.

https://lore.kernel.org/linux-cxl/20230525160859.32517-1-Jonathan.Cameron@huawei.com/T/#t
https://gitlab.com/jic23/qemu cxl-2023-05-25

> 
> Cc: Niyas Sait <niyas.sait@linaro.org>
> Cc: Klaus Jensen <its@irrelevant.dk>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Jeremy Kerr <jk@codeconstruct.com.au>
> Cc: Matt Johnston <matt@codeconstruct.com.au>
> Cc: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
> 
> Jonathan Cameron (6):
>   i2c: acpi: set slave mode flag
>   i2c: aspeed: Use platform_get_irq() instead of opencoding
>   i2c: aspeed: switch to generic fw properties.
>   i2c: aspeed: Set the fwnode for the adap->dev
>   HACK: i2c: aspeed: Comment the clock and reset out.
>   HACK: i2c: aspeed: Enable build without COMPILE_TEST
> 
>  drivers/i2c/busses/Kconfig      |  1 -
>  drivers/i2c/busses/i2c-aspeed.c | 36 ++++++++++++++++-----------------
>  drivers/i2c/i2c-core-acpi.c     |  3 +++
>  3 files changed, 20 insertions(+), 20 deletions(-)
> 
> 
> base-commit: f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6