All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: "Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Michael J . Ruhl" <michael.j.ruhl@intel.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Riana Tauro" <riana.tauro@intel.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] drm/xe/mcu_i2c: Take over control of the controller enabling
Date: Wed, 24 Jun 2026 14:28:47 +0300	[thread overview]
Message-ID: <aju_byFudTOeN6qz@kuha> (raw)
In-Reply-To: <aju7-s04LShxB-i8@black.igk.intel.com>

On Wed, Jun 24, 2026 at 01:14:02PM +0200, Raag Jadav wrote:
> On Wed, Jun 24, 2026 at 01:13:56PM +0300, Heikki Krogerus wrote:
> > On Tue, Jun 23, 2026 at 04:39:05PM +0200, Raag Jadav wrote:
> > > On Mon, Jun 22, 2026 at 01:47:59PM +0200, Heikki Krogerus wrote:
> > > > Some platforms make an assumption that the i2c controller's
> > > > enabled state indicates also the power state of the
> > > > controller. This can create a problem when the controller is
> > > > in disabled state, because the hardware may assume
> > > > incorrectly that it is then also in low-power state.
> > > > 
> > > > To fix this, the controller is kept enabled by taking over
> > > > the IC_ENABLE register. The controller has to be disabled
> > > > when the configuration is updated and when the target
> > > > address or the slave address are assigned, so disabling it
> > > > when IC_CON, IC_TAR or IC_SAR registers are programmed, and
> > > > then re-enabling it again.
> > > 
> > > ...
> > > 
> > > >  static int xe_i2c_read(void *context, unsigned int reg, unsigned int *val)
> > > >  {
> > > >  	struct xe_i2c *i2c = context;
> > > >  
> > > > -	*val = xe_mmio_read32(i2c->mmio, XE_REG(reg + I2C_MEM_SPACE_OFFSET));
> > > > +	switch (reg) {
> > > 
> > > Curious, should I expect DW_IC_INTR_MASK case here which skips the MMIO?
> > 
> > Probable not. We have the ACCESS_POLLING flag set, so the
> > i2c-designware will only write 0 to that register. Check
> > __i2c_dw_write_intr_mask().
> 
> Yes, but I'm not sure if all the writes to DW_IC_INTR_MASK have been
> converted to use that helper yet, or did I miss something?

It is only written directly in slave mode, but since slave mode is not
supported with ACCESS_POLLING at the moment, we will never reach that
code.

I'm hoping we will never have to support ACCESS_POLLING in slave mode,
but I'll send a patch (not as part of this series) in any case where
I'll make sure DW_IC_INTR_MASK is only written from that helper.

Thanks,

-- 
heikki

  reply	other threads:[~2026-06-24 11:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22 11:47 [PATCH v1 0/2] drm/xe/i2c: alerts and controller enabling modifications Heikki Krogerus
2026-06-22 11:47 ` [PATCH v1 1/2] drm/xe/i2c: Handler for SMBus Alerts Heikki Krogerus
2026-06-22 12:04   ` sashiko-bot
2026-06-23 10:54   ` Andy Shevchenko
2026-06-23 11:44     ` Heikki Krogerus
2026-06-23 14:34   ` Raag Jadav
2026-06-24  9:23     ` Heikki Krogerus
2026-06-22 11:47 ` [PATCH v1 2/2] drm/xe/mcu_i2c: Take over control of the controller enabling Heikki Krogerus
2026-06-22 12:04   ` sashiko-bot
2026-06-23 10:56   ` Andy Shevchenko
2026-06-23 14:58     ` Raag Jadav
2026-06-23 18:10       ` Andy Shevchenko
2026-06-24  9:27         ` Heikki Krogerus
2026-06-23 14:39   ` Raag Jadav
2026-06-24 10:13     ` Heikki Krogerus
2026-06-24 11:14       ` Raag Jadav
2026-06-24 11:28         ` Heikki Krogerus [this message]
2026-06-22 16:34 ` ✗ CI.checkpatch: warning for drm/xe/i2c: alerts and controller enabling modifications Patchwork
2026-06-22 16:35 ` ✓ CI.KUnit: success " Patchwork
2026-06-22 17:36 ` ✓ Xe.CI.BAT: " Patchwork
2026-06-22 20:38 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-06-23 10:15 ` [PATCH v1 0/2] " Heikki Krogerus
2026-06-23 14:40   ` Raag Jadav

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=aju_byFudTOeN6qz@kuha \
    --to=heikki.krogerus@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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=riana.tauro@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --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.