All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: linux-i2c@vger.kernel.org, Andi Shyti <andi.shyti@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jan Dabros <jsd@semihalf.com>,
	Jiawen Wu <jiawenwu@trustnetic.com>,
	Sanket Goswami <Sanket.Goswami@amd.com>,
	Basavaraj Natikar <Basavaraj.Natikar@amd.com>,
	michael.j.ruhl@intel.com, Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v2 9/9] i2c: designware: Implement generic polling mode code for Wangxun 10Gb NIC
Date: Tue, 6 Feb 2024 17:28:20 +0200	[thread overview]
Message-ID: <ZcJQFAa7Kspgb1En@smile.fi.intel.com> (raw)
In-Reply-To: <20240206145158.227254-10-jarkko.nikula@linux.intel.com>

On Tue, Feb 06, 2024 at 04:51:58PM +0200, Jarkko Nikula wrote:
> I got an idea the i2c-designware should not need duplicated state
> machines for the interrupt and polling modes. The IP is practically the
> same and state transitions happens in response to the events that can be
> observed from the DW_IC_RAW_INTR_STAT register. Either by interrupts or
> by polling.
> 
> Another reasons are the interrupt mode is the most tested, has handling
> for special cases as well as transmit abort handling and those are
> missing from two polling mode quirks.
> 
> Patch implements a generic polling mode by using existing code for
> interrupt mode. This is done by moving event handling from the
> i2c_dw_isr() into a new i2c_dw_process_transfer() that will be called
> both from the i2c_dw_isr() and a polling loop.
> 
> Polling loop is implemented in a new i2c_dw_wait_transfer() that is
> shared between both modes. In interrupt mode it waits for the completion
> object as before. In polling mode both completion object and
> DW_IC_RAW_INTR_STAT are polled to determine completed transfer and state
> transitions.
> 
> Loop tries to save power by sleeping "stetson guessed" range between
> 3 and 25 µS which falls between 10 cycles of High-speed mode 3.4 Mb/s
> and Fast mode 400 kHz. With it the CPU usage was reduced under heavy
> Fast mode I2C transfer without much increase in total transfer time but
> otherwise no more effort has been put to optimize this.
> 
> I decided to convert the txgbe_i2c_dw_xfer_quirk() straight to generic
> polling mode code in this patch. It doesn't have HW dependent quirks
> like the amd_i2c_dw_xfer_quirk() does have and without users this patch
> is needless.

...

I believe even with a single point of out we may do better this one, see below.

> +static int i2c_dw_wait_transfer(struct dw_i2c_dev *dev)
> +{
> +	unsigned long timeout = dev->adapter.timeout;
> +	unsigned int stat;

> +	int ret = 0;

	int ret;

> +	if (!(dev->flags & ACCESS_POLLING)) {
> +		ret = wait_for_completion_timeout(&dev->cmd_complete,
> +						  timeout) ? 0 : -ETIMEDOUT;

		ret = wait_for_completion_timeout(&dev->cmd_complete, timeout);

> +	} else {
> +		timeout += jiffies;
> +		do {
> +			if (try_wait_for_completion(&dev->cmd_complete))
> +				goto out;

				break;

> +			stat = i2c_dw_read_clear_intrbits(dev);
> +			if (stat)
> +				i2c_dw_process_transfer(dev, stat);
> +			else
> +				/* Try save some power */
> +				usleep_range(3, 25);
> +		} while (time_before(jiffies, timeout));

> +		ret = ETIMEDOUT;

		ret = time_before(jiffies, timeout);

> +	}

> +out:

	if (ret)
		return 0;

	return -ETIMEDOUT;

> +	return ret;
> +}

This will make same error code for both branches without need to synchronise,
meaning better maintenance.

-- 
With Best Regards,
Andy Shevchenko



      reply	other threads:[~2024-02-06 15:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-06 14:51 [PATCH v2 0/9] i2c: designware: Generic polling mode code Jarkko Nikula
2024-02-06 14:51 ` [PATCH v2 1/9] i2c: designware: Add some flexiblity to the model info Jarkko Nikula
2024-02-06 15:30   ` Andy Shevchenko
2024-02-09 14:14     ` Jarkko Nikula
2024-02-09 14:25       ` Andy Shevchenko
2024-02-06 14:51 ` [PATCH v2 2/9] i2c: designware: Convert arbitration semaphore flag as semaphore type Jarkko Nikula
2024-02-06 14:51 ` [PATCH v2 3/9] i2c: designware: Convert shared_with_punit boolean " Jarkko Nikula
2024-02-06 14:51 ` [PATCH v2 4/9] i2c: designware: Uniform initialization flow for polling mode Jarkko Nikula
2024-02-06 15:13   ` Andy Shevchenko
2024-02-06 14:51 ` [PATCH v2 5/9] i2c: designware: Do not enable interrupts shortly in " Jarkko Nikula
2024-02-06 14:51 ` [PATCH v2 6/9] i2c: designware: Use accessors to DW_IC_INTR_MASK register Jarkko Nikula
2024-02-06 14:51 ` [PATCH v2 7/9] i2c: designware: Move interrupt handling functions before i2c_dw_xfer() Jarkko Nikula
2024-02-06 15:18   ` Andy Shevchenko
2024-02-06 14:51 ` [PATCH v2 8/9] i2c: designware: Fix RX FIFO depth define on Wangxun 10Gb NIC Jarkko Nikula
2024-02-06 14:51 ` [PATCH v2 9/9] i2c: designware: Implement generic polling mode code for " Jarkko Nikula
2024-02-06 15:28   ` Andy Shevchenko [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=ZcJQFAa7Kspgb1En@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=Basavaraj.Natikar@amd.com \
    --cc=Sanket.Goswami@amd.com \
    --cc=andi.shyti@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=jsd@semihalf.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=michael.j.ruhl@intel.com \
    --cc=mika.westerberg@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.