All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Parshuram Thombare <pthombar@cadence.com>
Cc: mparab@cadence.com, bbrezillon@kernel.org, praneeth@ti.com,
	linux-kernel@vger.kernel.org, vitor.soares@synopsys.com,
	pgaj@cadence.com, linux-i3c@lists.infradead.org
Subject: Re: [PATCH v6 3/8] i3c: master: i3c mastership request and handover
Date: Thu, 30 Apr 2020 10:07:33 +0200	[thread overview]
Message-ID: <20200430100733.4e0dc578@collabora.com> (raw)
In-Reply-To: <1587140462-30209-1-git-send-email-pthombar@cadence.com>

On Fri, 17 Apr 2020 18:21:02 +0200
Parshuram Thombare <pthombar@cadence.com> wrote:

> +
> +/* This function is expected to be called with normaluse_lock */
> +int i3c_master_acquire_bus(struct i3c_master_controller *master)
> +{
> +	int ret = 0;
> +
> +	if (!master->this || master->this != master->bus.cur_master) {

Let's limit the number of indentations by doing

	if (master->this == master->bus.cur_master)
		return 0;


> +		if (master->mr_state == I3C_MR_IDLE) {
> +			master->mr_state = I3C_MR_WAIT_DA;
> +			init_completion(&master->mr_comp);
> +			queue_work(master->wq, &master->sec_mst_work);
> +			/*
> +			 * Bus acquire procedure may need write lock
> +			 * so release read lock before yielding
> +			 * to bus acquire state machine
> +			 */
> +			i3c_bus_normaluse_unlock(&master->bus);
> +			wait_for_completion(&master->mr_comp);
> +			i3c_bus_normaluse_lock(&master->bus);

Is that really enough? I remember we had something a bit more complex
to handle the case where bus is acquired to send a message to a device,
and another master on the bus re-acquires it before we have a chance to
send this message message. i3c_master_acquire_bus_ownership() was
dealing with that in Przemek series. It seems you've rewritten a lot of
these things. Would you mind explaining why, and how that works?

> +			if (master->mr_state != I3C_MR_DONE)
> +				ret = -EAGAIN;
> +			master->mr_state = I3C_MR_IDLE;
> +		} else {
> +			/*
> +			 * MR request is already in process for
> +			 * this master
> +			 */
> +			ret = -EAGAIN;
> +		}
> +	}
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_acquire_bus);



_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Parshuram Thombare <pthombar@cadence.com>
Cc: <bbrezillon@kernel.org>, <vitor.soares@synopsys.com>,
	<pgaj@cadence.com>, <linux-i3c@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <mparab@cadence.com>,
	<praneeth@ti.com>
Subject: Re: [PATCH v6 3/8] i3c: master: i3c mastership request and handover
Date: Thu, 30 Apr 2020 10:07:33 +0200	[thread overview]
Message-ID: <20200430100733.4e0dc578@collabora.com> (raw)
In-Reply-To: <1587140462-30209-1-git-send-email-pthombar@cadence.com>

On Fri, 17 Apr 2020 18:21:02 +0200
Parshuram Thombare <pthombar@cadence.com> wrote:

> +
> +/* This function is expected to be called with normaluse_lock */
> +int i3c_master_acquire_bus(struct i3c_master_controller *master)
> +{
> +	int ret = 0;
> +
> +	if (!master->this || master->this != master->bus.cur_master) {

Let's limit the number of indentations by doing

	if (master->this == master->bus.cur_master)
		return 0;


> +		if (master->mr_state == I3C_MR_IDLE) {
> +			master->mr_state = I3C_MR_WAIT_DA;
> +			init_completion(&master->mr_comp);
> +			queue_work(master->wq, &master->sec_mst_work);
> +			/*
> +			 * Bus acquire procedure may need write lock
> +			 * so release read lock before yielding
> +			 * to bus acquire state machine
> +			 */
> +			i3c_bus_normaluse_unlock(&master->bus);
> +			wait_for_completion(&master->mr_comp);
> +			i3c_bus_normaluse_lock(&master->bus);

Is that really enough? I remember we had something a bit more complex
to handle the case where bus is acquired to send a message to a device,
and another master on the bus re-acquires it before we have a chance to
send this message message. i3c_master_acquire_bus_ownership() was
dealing with that in Przemek series. It seems you've rewritten a lot of
these things. Would you mind explaining why, and how that works?

> +			if (master->mr_state != I3C_MR_DONE)
> +				ret = -EAGAIN;
> +			master->mr_state = I3C_MR_IDLE;
> +		} else {
> +			/*
> +			 * MR request is already in process for
> +			 * this master
> +			 */
> +			ret = -EAGAIN;
> +		}
> +	}
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_acquire_bus);



  reply	other threads:[~2020-04-30  8:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 16:19 [PATCH v6 0/8] I3C mastership handover support Parshuram Thombare
2020-04-17 16:19 ` Parshuram Thombare
2020-04-17 16:20 ` [PATCH v6 1/8] i3c: master: mastership handover document Parshuram Thombare
2020-04-17 16:20   ` Parshuram Thombare
2020-04-30  7:40   ` Boris Brezillon
2020-04-30  7:40     ` Boris Brezillon
2020-04-17 16:20 ` [PATCH v6 2/8] i3c: master: split bus_init callback into bus_init and master_set_info Parshuram Thombare
2020-04-17 16:20   ` Parshuram Thombare
2020-04-30  7:55   ` Boris Brezillon
2020-04-30  7:55     ` Boris Brezillon
2020-04-17 16:21 ` [PATCH v6 3/8] i3c: master: i3c mastership request and handover Parshuram Thombare
2020-04-17 16:21   ` Parshuram Thombare
2020-04-30  8:07   ` Boris Brezillon [this message]
2020-04-30  8:07     ` Boris Brezillon
2020-04-17 16:21 ` [PATCH v6 4/8] i3c: master: defslvs processing Parshuram Thombare
2020-04-17 16:21   ` Parshuram Thombare
2020-04-17 16:22 ` [PATCH v6 5/8] i3c: master: check for non null pointer Parshuram Thombare
2020-04-17 16:22   ` Parshuram Thombare
2020-04-17 16:22 ` [PATCH v6 6/8] i3c: master: secondary master initialization Parshuram Thombare
2020-04-17 16:22   ` Parshuram Thombare
2020-04-17 16:22 ` [PATCH v6 7/8] i3c: master: added sysfs key i3c_acquire_bus Parshuram Thombare
2020-04-17 16:22   ` Parshuram Thombare
2020-04-17 16:24 ` [PATCH v6 8/8] i3c: master: add mastership handover support to cdns i3c master driver Parshuram Thombare
2020-04-17 16:24   ` Parshuram Thombare

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=20200430100733.4e0dc578@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=bbrezillon@kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mparab@cadence.com \
    --cc=pgaj@cadence.com \
    --cc=praneeth@ti.com \
    --cc=pthombar@cadence.com \
    --cc=vitor.soares@synopsys.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.