Hi,

The hardware challenges that these patches address are so severe that I'm
marking both of them as fixes. In both cases the GPU may silently end up in
unresponsive state (or worse). The second patch has been refactored so that it
includes the direct AMC alert handling in Xe instead of the normal alert handler
registration. The subject lines were also changed to highlight the fact that
these are fixes. Ramesh helped me with the testing and with the implementation
for the AMC alert handling.

Changed since v2:
- Added Fixes tag to both patches.
- i2c-designware is no longer supplied with an interrupt so it will be in
  polling mode (ACCESS_POLLING will be enabled). The IRQ path in hardware can't
  handle the amount of interrupts the i2c controller generates. Only the
  interrupts from the SMBus Alert line are left enabled.
- The registration of the default smbus alert handler is dropped.
- The AMC alerts are handled directly in Xe. All the alerts will cause the
  device to be declared as wedged at least for now.
- Cleanups proposed by Raag.

v2: https://lore.kernel.org/lkml/20260625125939.429078-1-heikki.krogerus@linux.intel.com/

Changed since v1:
- Global header for the DesignWare I2C registers which meant a bit of
  patch refactoring.
- Selecting CONFIG_SMBUS in CONFIG_XE and handling smbus in xe_i2c.c instead of
  separate file.
- Storing the alert device to the client array and providing enum for the
  clients.
- Allowing other fields in the IC_ENABLE register to be updated except the
  Enable bit.
- Can't sleep in xe_i2c_disable() so using udelay().

v1: https://lore.kernel.org/lkml/20260622114759.3464047-1-heikki.krogerus@linux.intel.com/

This includes support for the SMBus alerts, and special handling for the
IC_ENABLE register.

Thanks,

Heikki Krogerus (3):
  i2c: designware: Global register definitions
  drm/xe/i2c: Fix the interrupt handling
  drm/xe/i2c: Keep the i2c controller always enabled

 MAINTAINERS                                |   1 +
 drivers/gpu/drm/xe/Makefile                |   4 +-
 drivers/gpu/drm/xe/regs/xe_i2c_regs.h      |   2 +
 drivers/gpu/drm/xe/xe_amc.c                | 173 +++++++++++++++++++++
 drivers/gpu/drm/xe/xe_amc.h                |  25 +++
 drivers/gpu/drm/xe/xe_i2c.c                | 136 +++++++++-------
 drivers/gpu/drm/xe/xe_i2c.h                |  14 +-
 drivers/i2c/busses/i2c-designware-common.c |   2 +
 drivers/i2c/busses/i2c-designware-core.h   |  85 +---------
 drivers/i2c/busses/i2c-designware-master.c |   2 +
 drivers/i2c/busses/i2c-designware-slave.c  |   2 +
 include/linux/designware_i2c.h             | 107 +++++++++++++
 12 files changed, 405 insertions(+), 148 deletions(-)
 create mode 100644 drivers/gpu/drm/xe/xe_amc.c
 create mode 100644 drivers/gpu/drm/xe/xe_amc.h
 create mode 100644 include/linux/designware_i2c.h

-- 
2.50.1

On Mon, Jul 13, 2026 at 05:55:58PM +0200, Heikki Krogerus wrote:
> Hi,
> 
> The hardware challenges that these patches address are so severe that I'm
> marking both of them as fixes. In both cases the GPU may silently end up in
> unresponsive state (or worse). The second patch has been refactored so that it
> includes the direct AMC alert handling in Xe instead of the normal alert handler
> registration. The subject lines were also changed to highlight the fact that
> these are fixes. Ramesh helped me with the testing and with the implementation
> for the AMC alert handling.
> 
> Changed since v2:
> - Added Fixes tag to both patches.
> - i2c-designware is no longer supplied with an interrupt so it will be in
>   polling mode (ACCESS_POLLING will be enabled). The IRQ path in hardware can't
>   handle the amount of interrupts the i2c controller generates. Only the
>   interrupts from the SMBus Alert line are left enabled.
> - The registration of the default smbus alert handler is dropped.
> - The AMC alerts are handled directly in Xe. All the alerts will cause the
>   device to be declared as wedged at least for now.
> - Cleanups proposed by Raag.
> 
> v2: https://lore.kernel.org/lkml/20260625125939.429078-1-heikki.krogerus@linux.intel.com/
> 
> Changed since v1:
> - Global header for the DesignWare I2C registers which meant a bit of
>   patch refactoring.
> - Selecting CONFIG_SMBUS in CONFIG_XE and handling smbus in xe_i2c.c instead of
>   separate file.
> - Storing the alert device to the client array and providing enum for the
>   clients.
> - Allowing other fields in the IC_ENABLE register to be updated except the
>   Enable bit.
> - Can't sleep in xe_i2c_disable() so using udelay().
> 
> v1: https://lore.kernel.org/lkml/20260622114759.3464047-1-heikki.krogerus@linux.intel.com/
> 
> This includes support for the SMBus alerts, and special handling for the
> IC_ENABLE register.
> 
> Thanks,


Please take a look to Shashiko review and let us know in case of false positives:
https://sashiko.dev/#/patchset/20260713155601.711389-1-heikki.krogerus%40linux.intel.com

> 
> Heikki Krogerus (3):
>   i2c: designware: Global register definitions
>   drm/xe/i2c: Fix the interrupt handling
>   drm/xe/i2c: Keep the i2c controller always enabled
> 
>  MAINTAINERS                                |   1 +
>  drivers/gpu/drm/xe/Makefile                |   4 +-
>  drivers/gpu/drm/xe/regs/xe_i2c_regs.h      |   2 +
>  drivers/gpu/drm/xe/xe_amc.c                | 173 +++++++++++++++++++++
>  drivers/gpu/drm/xe/xe_amc.h                |  25 +++
>  drivers/gpu/drm/xe/xe_i2c.c                | 136 +++++++++-------
>  drivers/gpu/drm/xe/xe_i2c.h                |  14 +-
>  drivers/i2c/busses/i2c-designware-common.c |   2 +
>  drivers/i2c/busses/i2c-designware-core.h   |  85 +---------
>  drivers/i2c/busses/i2c-designware-master.c |   2 +
>  drivers/i2c/busses/i2c-designware-slave.c  |   2 +
>  include/linux/designware_i2c.h             | 107 +++++++++++++
>  12 files changed, 405 insertions(+), 148 deletions(-)
>  create mode 100644 drivers/gpu/drm/xe/xe_amc.c
>  create mode 100644 drivers/gpu/drm/xe/xe_amc.h
>  create mode 100644 include/linux/designware_i2c.h
> 
> -- 
> 2.50.1
>

Hi Rodrigo,

On Tue, Jul 14, 2026 at 11:54:16AM -0400, Rodrigo Vivi kirjoitti:
> On Mon, Jul 13, 2026 at 05:55:58PM +0200, Heikki Krogerus wrote:
> > Hi,
> > 
> > The hardware challenges that these patches address are so severe that I'm
> > marking both of them as fixes. In both cases the GPU may silently end up in
> > unresponsive state (or worse). The second patch has been refactored so that it
> > includes the direct AMC alert handling in Xe instead of the normal alert handler
> > registration. The subject lines were also changed to highlight the fact that
> > these are fixes. Ramesh helped me with the testing and with the implementation
> > for the AMC alert handling.
> > 
> > Changed since v2:
> > - Added Fixes tag to both patches.
> > - i2c-designware is no longer supplied with an interrupt so it will be in
> >   polling mode (ACCESS_POLLING will be enabled). The IRQ path in hardware can't
> >   handle the amount of interrupts the i2c controller generates. Only the
> >   interrupts from the SMBus Alert line are left enabled.
> > - The registration of the default smbus alert handler is dropped.
> > - The AMC alerts are handled directly in Xe. All the alerts will cause the
> >   device to be declared as wedged at least for now.
> > - Cleanups proposed by Raag.
> > 
> > v2: https://lore.kernel.org/lkml/20260625125939.429078-1-heikki.krogerus@linux.intel.com/
> > 
> > Changed since v1:
> > - Global header for the DesignWare I2C registers which meant a bit of
> >   patch refactoring.
> > - Selecting CONFIG_SMBUS in CONFIG_XE and handling smbus in xe_i2c.c instead of
> >   separate file.
> > - Storing the alert device to the client array and providing enum for the
> >   clients.
> > - Allowing other fields in the IC_ENABLE register to be updated except the
> >   Enable bit.
> > - Can't sleep in xe_i2c_disable() so using udelay().
> > 
> > v1: https://lore.kernel.org/lkml/20260622114759.3464047-1-heikki.krogerus@linux.intel.com/
> > 
> > This includes support for the SMBus alerts, and special handling for the
> > IC_ENABLE register.
> > 
> > Thanks,
> 
> 
> Please take a look to Shashiko review and let us know in case of false positives:
> https://sashiko.dev/#/patchset/20260713155601.711389-1-heikki.krogerus%40linux.intel.com

The high ones are false positive.

- The SMBus interrupts are not cleared the same way as the other
  interrupts.
- i2c-designware driver does not modify the timings unless it is
  supplied a clock device (struct clk).

The rest I'll check and fix as needed together with the modifications
proposed by Raag.

Thanks,

-- 
heikki