From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: "Matthew Brost" <matthew.brost@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Andi Shyti" <andi.shyti@kernel.org>,
"Ramesh Babu B" <ramesh.babu.b@intel.com>,
"Michael J. Ruhl" <michael.j.ruhl@intel.com>,
linux-kernel@vger.kernel.org, intel-xe@lists.freedesktop.org,
stable@vger.kernel.org
Subject: Re: [PATCH v5 2/3] drm/xe/i2c: Fix the interrupt handling
Date: Thu, 16 Jul 2026 10:14:49 +0300 [thread overview]
Message-ID: <aliE6bZI_1fzA_xi@kuha> (raw)
In-Reply-To: <alhuIcCmf3Pu31t1@black.igk.intel.com>
On Thu, Jul 16, 2026 at 07:37:37AM +0200, Raag Jadav wrote:
> On Wed, Jul 15, 2026 at 05:31:52PM +0200, Heikki Krogerus wrote:
> > The platforms that support the interrupt from the I2C
> > adapter can not handle the amount of interrupts the adapter
> > generates because of the way the IRQ is routed in the
> > hardware. The I2C controller driver has to be kept in
> > polling mode because of that.
> >
> > The AMC MCU can still generate critical alerts that have to
> > be handled. The interrupt from SMBus Alert is left enabled
> > and handled separately in the Xe. The alerts from the AMC
> > will cause the device to be declared wedged for now.
>
> ...
>
> > +static void xe_amc_work(struct work_struct *work)
> > +{
> > + const struct amc_request *request = &amc_get_alert_reason;
> > + struct xe_amc *amc = from_work(amc, work, work);
> > + struct amc_response response;
> > + struct i2c_client *client;
> > + int ret;
> > +
> > + client = amc->i2c->client[XE_I2C_CLIENT_AMC];
> > + if (!client)
> > + goto out_reassert_interrupt;
> > +
> > + ret = i2c_master_send(client, (u8 *)request, sizeof(*request));
> > + if (ret < 0) {
> > + dev_err(&client->dev, "failed to send request (%d)\n", ret);
> > + goto out_reassert_interrupt;
> > + }
> > +
> > + /* AMC needs 20ms to generate the response. */
> > + fsleep(20 * USEC_PER_MSEC);
> > +
> > + ret = i2c_master_recv(client, (u8 *)&response, sizeof(response));
> > + if (ret < 0) {
> > + dev_err(&client->dev, "failed to read response (%d)\n", ret);
> > + goto out_reassert_interrupt;
> > + }
> > +
> > + if (!response.header.len) {
> > + dev_err(&client->dev, "empty response from AMC\n");
> > + goto out_reassert_interrupt;
> > + }
> > +
> > + if (memcmp(&response.message, &request->message, sizeof(struct amc_message))) {
> > + dev_err(&client->dev, "response does not match the request\n");
> > + goto out_reassert_interrupt;
> > + }
> > +
> > + if (response.error) {
> > + dev_err(&client->dev, "AMC error 0x%02x\n", response.error);
> > + goto out_reassert_interrupt;
> > + }
>
> [1] See below.
>
> > + dev_dbg(&client->dev, "%s: Alert reason: %d\n", __func__, response.value);
> > +
> > + switch (response.value) {
> > + case AMC_ALERT_FW_DOWNLOAD:
> > + case AMC_ALERT_THERMAL_TRIP:
> > + case AMC_ALERT_OOB_REQUEST:
> > + case AMC_ALERT_OOB_RESET:
> > + case AMC_ALERT_CATERR:
> > + xe_device_declare_wedged(i2c_client_to_xe_device(client));
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > +out_reassert_interrupt:
> > + xe_mmio_rmw32(amc->i2c->mmio, I2C_CONFIG_CMD, PCI_COMMAND_INTX_DISABLE, 0);
>
> One of the rules of wedging is that it's a last resort and there shouldn't
> be any hardware access afterwards, so I think a more suitable place for
> re-assert is before[1] we process the response.
Makes sense. I'll fix this.
> > +}
>
> ...
>
> > +static void xe_i2c_handle_smbus_alert(struct xe_i2c *i2c)
> > +{
> > + u32 stat;
> > +
> > + stat = xe_mmio_read32(i2c->mmio, I2C_REG(DW_IC_SMBUS_INTR_STAT));
> > + if (!stat)
> > + return;
> > +
> > + xe_mmio_write32(i2c->mmio, I2C_REG(DW_IC_CLR_SMBUS_INTR), stat);
> > +
> > + xe_mmio_rmw32(i2c->mmio, I2C_CONFIG_CMD, 0, PCI_COMMAND_INTX_DISABLE);
>
> As per updated arch, this is now taken care by the firmware and can be
> dropped.
Okay, good. I wanted to ask you why we do that after the i2c adapter
interrupt is cleared instead of before that, but now it does not
matter :)
Thanks Raag!
--
heikki
next prev parent reply other threads:[~2026-07-16 7:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 15:31 [PATCH v5 0/3] drm/xe/i2c: alerts and controller enabling modifications Heikki Krogerus
2026-07-15 15:31 ` [PATCH v5 1/3] i2c: designware: Global register definitions Heikki Krogerus
2026-07-15 15:31 ` [PATCH v5 2/3] drm/xe/i2c: Fix the interrupt handling Heikki Krogerus
2026-07-16 5:37 ` Raag Jadav
2026-07-16 7:14 ` Heikki Krogerus [this message]
2026-07-15 15:31 ` [PATCH v5 3/3] drm/xe/i2c: Keep the i2c controller always enabled Heikki Krogerus
2026-07-15 16:04 ` ✗ CI.checkpatch: warning for drm/xe/i2c: alerts and controller enabling modifications (rev5) Patchwork
2026-07-15 16:05 ` ✓ CI.KUnit: success " Patchwork
2026-07-15 16:42 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-15 20:53 ` ✓ Xe.CI.FULL: " Patchwork
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=aliE6bZI_1fzA_xi@kuha \
--to=heikki.krogerus@linux.intel.com \
--cc=andi.shyti@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=michael.j.ruhl@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=raag.jadav@intel.com \
--cc=ramesh.babu.b@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=stable@vger.kernel.org \
--cc=thomas.hellstrom@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 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.