All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Wiklander <jens.wiklander@linaro.org>
To: op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH] drivers: optee: i2c: add bus retry configuration
Date: Wed, 23 Sep 2020 14:13:56 +0200	[thread overview]
Message-ID: <20200923121356.GA1659958@jade> (raw)
In-Reply-To: <20200923112631.GB30271@trex>

[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]

On Wed, Sep 23, 2020 at 01:26:31PM +0200, Jorge Ramirez-Ortiz, Foundries wrote:
> On 23/09/20, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 22/09/20, Jens Wiklander wrote:
> > > On Wed, Sep 16, 2020 at 05:27:32PM +0200, Jorge Ramirez-Ortiz wrote:
> > > > Allow OP-TEE to specify the number of retries in the adaptor.
> > > > 
> > > > Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
> > > > ---
> > > >  drivers/tee/optee/rpc.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
> > > > index 1e3614e4798f..2d46a9ecb1de 100644
> > > > --- a/drivers/tee/optee/rpc.c
> > > > +++ b/drivers/tee/optee/rpc.c
> > > > @@ -58,6 +58,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
> > > >  	struct tee_param *params;
> > > >  	size_t i;
> > > >  	int ret = -EOPNOTSUPP;
> > > > +	int retries = 0;
> > > >  	u8 attr[] = {
> > > >  		TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> > > >  		TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> > > > @@ -102,12 +103,17 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
> > > >  	client.addr = params[0].u.value.c;
> > > >  	snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr);
> > > >  
> > > > +	/* cache the current value */
> > > > +	retries = client.adapter->retries;
> > > > +
> > > >  	switch (params[0].u.value.a) {
> > > >  	case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
> > > > +		client.adapter->retries = params[1].u.value.b;
> > > Do we need to take any locks befor this?
> > 
> > no I dont think so: there is no need for bus locks when requesting a
> > transfer via i2c_master_recv/send; the lock for the bus segment gets
> > taken later on, when the actual transfer hppens ( __i2c_transfer())
> > 
> > the functionality implemented in this function pretty much mimicks
> > what is done in the normal world via /dev/i2c-X
> > (drivers/i2c/i2c_dev.c)
> >
> 
> correction (of course)
>   - i2cdev_read --> i2c_master_recv
>   - i2cdev->write -->i2c_master_send
> > 
> > and now the retry count setup on the adaptor with this commit.
> > 
> >  - i2cdev_ioctl I2C_RETRIES

I don't understand. Do you mean that client.adapter->retries doesn't
need to be protected from concurrent updates? Or is it already protected
by some other mechanism?

Cheers,
Jens

WARNING: multiple messages have this Message-ID (diff)
From: Jens Wiklander <jens.wiklander@linaro.org>
To: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>
Cc: sumit.garg@linaro.org, ricardo@foundries.io, mike@foundries.io,
	tee-dev@lists.linaro.org, linux-kernel@vger.kernel.org,
	op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH] drivers: optee: i2c: add bus retry configuration
Date: Wed, 23 Sep 2020 14:13:56 +0200	[thread overview]
Message-ID: <20200923121356.GA1659958@jade> (raw)
In-Reply-To: <20200923112631.GB30271@trex>

On Wed, Sep 23, 2020 at 01:26:31PM +0200, Jorge Ramirez-Ortiz, Foundries wrote:
> On 23/09/20, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 22/09/20, Jens Wiklander wrote:
> > > On Wed, Sep 16, 2020 at 05:27:32PM +0200, Jorge Ramirez-Ortiz wrote:
> > > > Allow OP-TEE to specify the number of retries in the adaptor.
> > > > 
> > > > Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
> > > > ---
> > > >  drivers/tee/optee/rpc.c | 7 +++++++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
> > > > index 1e3614e4798f..2d46a9ecb1de 100644
> > > > --- a/drivers/tee/optee/rpc.c
> > > > +++ b/drivers/tee/optee/rpc.c
> > > > @@ -58,6 +58,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
> > > >  	struct tee_param *params;
> > > >  	size_t i;
> > > >  	int ret = -EOPNOTSUPP;
> > > > +	int retries = 0;
> > > >  	u8 attr[] = {
> > > >  		TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> > > >  		TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT,
> > > > @@ -102,12 +103,17 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
> > > >  	client.addr = params[0].u.value.c;
> > > >  	snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr);
> > > >  
> > > > +	/* cache the current value */
> > > > +	retries = client.adapter->retries;
> > > > +
> > > >  	switch (params[0].u.value.a) {
> > > >  	case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
> > > > +		client.adapter->retries = params[1].u.value.b;
> > > Do we need to take any locks befor this?
> > 
> > no I dont think so: there is no need for bus locks when requesting a
> > transfer via i2c_master_recv/send; the lock for the bus segment gets
> > taken later on, when the actual transfer hppens ( __i2c_transfer())
> > 
> > the functionality implemented in this function pretty much mimicks
> > what is done in the normal world via /dev/i2c-X
> > (drivers/i2c/i2c_dev.c)
> >
> 
> correction (of course)
>   - i2cdev_read --> i2c_master_recv
>   - i2cdev->write -->i2c_master_send
> > 
> > and now the retry count setup on the adaptor with this commit.
> > 
> >  - i2cdev_ioctl I2C_RETRIES

I don't understand. Do you mean that client.adapter->retries doesn't
need to be protected from concurrent updates? Or is it already protected
by some other mechanism?

Cheers,
Jens

  reply	other threads:[~2020-09-23 12:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16 15:27 [PATCH] drivers: optee: i2c: add bus retry configuration Jorge Ramirez-Ortiz
2020-09-22 16:38 ` Jens Wiklander
2020-09-22 16:38   ` Jens Wiklander
2020-09-23 11:18   ` Jorge Ramirez-Ortiz, Foundries
2020-09-23 11:18     ` Jorge Ramirez-Ortiz, Foundries
2020-09-23 11:26     ` Jorge Ramirez-Ortiz, Foundries
2020-09-23 11:26       ` Jorge Ramirez-Ortiz, Foundries
2020-09-23 12:13       ` Jens Wiklander [this message]
2020-09-23 12:13         ` Jens Wiklander
2020-09-23 13:51         ` Jorge Ramirez-Ortiz, Foundries
2020-09-23 13:51           ` Jorge Ramirez-Ortiz, Foundries

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=20200923121356.GA1659958@jade \
    --to=jens.wiklander@linaro.org \
    --cc=op-tee@lists.trustedfirmware.org \
    /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.