[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200923112631.GB30271@trex>
Date: Wed, 23 Sep 2020 13:26:31 +0200
From: "Jorge Ramirez-Ortiz, Foundries" <jorge@...ndries.io>
To: "Jorge Ramirez-Ortiz, Foundries" <jorge@...ndries.io>
Cc: Jens Wiklander <jens.wiklander@...aro.org>, sumit.garg@...aro.org,
ricardo@...ndries.io, mike@...ndries.io, tee-dev@...ts.linaro.org,
linux-kernel@...r.kernel.org, op-tee@...ts.trustedfirmware.org
Subject: Re: [PATCH] drivers: optee: i2c: add bus retry configuration
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@...ndries.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
>
> >
> > Cheers,
> > Jens
> >
> > > ret = i2c_master_recv(&client, params[2].u.memref.shm->kaddr,
> > > params[2].u.memref.size);
> > > break;
> > > case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
> > > + client.adapter->retries = params[1].u.value.b;
> > > ret = i2c_master_send(&client, params[2].u.memref.shm->kaddr,
> > > params[2].u.memref.size);
> > > break;
> > > @@ -126,6 +132,7 @@ static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
> > > arg->ret = TEEC_SUCCESS;
> > > }
> > >
> > > + client.adapter->retries = retries;
> > > i2c_put_adapter(client.adapter);
> > > kfree(params);
> > > return;
> > > --
> > > 2.17.1
> > >
Powered by blists - more mailing lists