From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: <linux-i2c@vger.kernel.org>
Cc: Wolfram Sang <wsa@kernel.org>, Niyas Sait <niyas.sait@linaro.org>,
Klaus Jensen <its@irrelevant.dk>,
Andy Shevchenko <andy@kernel.org>, <linux-acpi@vger.kernel.org>,
Jeremy Kerr <jk@codeconstruct.com.au>,
"Matt Johnston" <matt@codeconstruct.com.au>,
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>,
<linux-cxl@vger.kernel.org>,
"Viacheslav A . Dubeyko" <viacheslav.dubeyko@bytedance.com>
Subject: Re: [RFC PATCH 0/6] i2c: Enabling use of aspeed-i2c with ACPI
Date: Thu, 25 May 2023 17:18:55 +0100 [thread overview]
Message-ID: <20230525171844.00004e8b@huawei.com> (raw)
In-Reply-To: <20230525152203.32190-1-Jonathan.Cameron@huawei.com>
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
prev parent reply other threads:[~2023-05-25 16:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 15:21 [RFC PATCH 0/6] i2c: Enabling use of aspeed-i2c with ACPI Jonathan Cameron
2023-05-25 15:21 ` [RFC PATCH 1/6] i2c: acpi: set slave mode flag Jonathan Cameron
2023-05-26 19:43 ` Andy Shevchenko
2023-05-25 15:21 ` [RFC PATCH 2/6] i2c: aspeed: Use platform_get_irq() instead of opencoding Jonathan Cameron
2023-05-26 21:06 ` Andy Shevchenko
2023-05-25 15:22 ` [RFC PATCH 3/6] i2c: aspeed: switch to generic fw properties Jonathan Cameron
2023-05-26 21:11 ` Andy Shevchenko
2023-05-30 14:16 ` Jonathan Cameron
2023-05-25 15:22 ` [RFC PATCH 4/6] i2c: aspeed: Set the fwnode for the adap->dev Jonathan Cameron
2023-05-26 21:13 ` Andy Shevchenko
2023-05-25 15:22 ` [RFC PATCH 5/6] HACK: i2c: aspeed: Comment the clock and reset out Jonathan Cameron
2023-05-26 21:16 ` Andy Shevchenko
2023-05-30 14:40 ` Jonathan Cameron
2023-05-26 23:36 ` kernel test robot
2023-05-25 15:22 ` [RFC PATCH 6/6] HACK: i2c: aspeed: Enable build without COMPILE_TEST Jonathan Cameron
2023-05-26 10:37 ` kernel test robot
2023-05-26 21:30 ` kernel test robot
2023-05-30 14:44 ` Jonathan Cameron
2023-05-25 16:18 ` Jonathan Cameron [this message]
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=20230525171844.00004e8b@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=andy@kernel.org \
--cc=its@irrelevant.dk \
--cc=jk@codeconstruct.com.au \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=niyas.sait@linaro.org \
--cc=sheshas@marvell.com \
--cc=viacheslav.dubeyko@bytedance.com \
--cc=wsa@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.