LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> To: Wolfram Sang <wsa@the-dreams.de> Cc: Brendan Higgins <brendanhiggins@google.com>, Rob Herring <robh+dt@kernel.org>, Joel Stanley <joel@jms.id.au>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Mark Rutland <mark.rutland@arm.com>, Andrew Jeffery <andrew@aj.id.au>, linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org, Jarkko Nikula <jarkko.nikula@linux.intel.com>, James Feist <james.feist@linux.intel.com>, Vernon Mauery <vernon.mauery@linux.intel.com> Subject: Re: [PATCH i2c-next v9 5/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases Date: Wed, 28 Nov 2018 16:30:03 -0600 [thread overview] Message-ID: <2772b86e-6ffb-e289-40f2-f96d11b82349@linux.intel.com> (raw) In-Reply-To: <20181128215434.GA1666@kunai> On 11/28/2018 3:54 PM, Wolfram Sang wrote: > On Tue, Oct 30, 2018 at 02:09:16PM -0700, Jae Hyun Yoo wrote: >> In multi-master environment, this driver's master cannot know >> exactly when a peer master sends data to this driver's slave so a >> case can be happened that this master tries to send data through >> the master_xfer function but slave data from peer master is still >> being processed by this driver. > > So, that I get this correct: your IP core cannot detect a bus busy state > when its own slave address is acessed? Well, I know HW can have bugs, > but I still wonder because a bus is busy as soon as another START has > been detected, independent of which device is going to be accessed. > > Even if so, why can't you use a mutex to prevent any master_xfer while > slave_xfer is ongoing? > > Shouldn't that be enough according to the above description? Why do you > need the delay? I might be missing something... > This IP has a bus busy state bit which can cover master and slave operations but in case of slave operation, the bit is cleared little bit earlier than its actual completion so it's the reason why I made this patch. I agree with you that it still has a weak point since the bus can be changed to busy state immediately just after finishing the busy waiting delay. As you suggested, I'll try to implement it using a mutex instead of using delay. Thanks a lot for your comment. Jae >> To prevent any state corruption in the case, this patch adds >> checking code if any slave operation is ongoing and it waits up to >> the bus timeout duration before starting a master_xfer operation. >> >> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> >> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> >> --- >> drivers/i2c/busses/i2c-aspeed.c | 55 ++++++++++++++++++++++++--------- >> 1 file changed, 40 insertions(+), 15 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c >> index 833b6b6a4c7e..30c3ab3a4844 100644 >> --- a/drivers/i2c/busses/i2c-aspeed.c >> +++ b/drivers/i2c/busses/i2c-aspeed.c >> @@ -12,6 +12,7 @@ >> >> #include <linux/clk.h> >> #include <linux/completion.h> >> +#include <linux/delay.h> >> #include <linux/err.h> >> #include <linux/errno.h> >> #include <linux/i2c.h> >> @@ -115,6 +116,9 @@ >> /* 0x18 : I2CD Slave Device Address Register */ >> #define ASPEED_I2CD_DEV_ADDR_MASK GENMASK(6, 0) >> >> +/* Busy checking */ >> +#define ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US (10 * 1000) >> + >> enum aspeed_i2c_master_state { >> ASPEED_I2C_MASTER_INACTIVE, >> ASPEED_I2C_MASTER_START, >> @@ -156,6 +160,8 @@ struct aspeed_i2c_bus { >> int cmd_err; >> /* Protected only by i2c_lock_bus */ >> int master_xfer_result; >> + /* Multi-master */ >> + bool multi_master; >> #if IS_ENABLED(CONFIG_I2C_SLAVE) >> struct i2c_client *slave; >> enum aspeed_i2c_slave_state slave_state; >> @@ -596,27 +602,44 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, void *dev_id) >> return irq_remaining ? IRQ_NONE : IRQ_HANDLED; >> } >> >> +static int aspeed_i2c_check_bus_busy(struct aspeed_i2c_bus *bus) >> +{ >> + unsigned long timeout; >> + >> + if (bus->multi_master) { >> + might_sleep(); >> + /* Initialize it only when multi_master is set */ >> + timeout = jiffies + bus->adap.timeout; >> + } >> + >> + for (;;) { >> + if (!(readl(bus->base + ASPEED_I2C_CMD_REG) & >> + ASPEED_I2CD_BUS_BUSY_STS)) >> +#if IS_ENABLED(CONFIG_I2C_SLAVE) >> + if (bus->slave_state == ASPEED_I2C_SLAVE_STOP) >> +#endif >> + return 0; >> + if (!bus->multi_master) >> + break; >> + if (time_after(jiffies, timeout)) >> + break; >> + usleep_range((ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US >> 2) + 1, >> + ASPEED_I2C_BUS_BUSY_CHECK_INTERVAL_US); >> + } >> + >> + return aspeed_i2c_recover_bus(bus); >> +} >> + >> static int aspeed_i2c_master_xfer(struct i2c_adapter *adap, >> struct i2c_msg *msgs, int num) >> { >> struct aspeed_i2c_bus *bus = i2c_get_adapdata(adap); >> unsigned long time_left, flags; >> - int ret = 0; >> >> - spin_lock_irqsave(&bus->lock, flags); >> - bus->cmd_err = 0; >> - >> - /* If bus is busy, attempt recovery. We assume a single master >> - * environment. >> - */ >> - if (readl(bus->base + ASPEED_I2C_CMD_REG) & ASPEED_I2CD_BUS_BUSY_STS) { >> - spin_unlock_irqrestore(&bus->lock, flags); >> - ret = aspeed_i2c_recover_bus(bus); >> - if (ret) >> - return ret; >> - spin_lock_irqsave(&bus->lock, flags); >> - } >> + if (aspeed_i2c_check_bus_busy(bus)) >> + return -EAGAIN; >> >> + spin_lock_irqsave(&bus->lock, flags); >> bus->cmd_err = 0; >> bus->msgs = msgs; >> bus->msgs_index = 0; >> @@ -827,7 +850,9 @@ static int aspeed_i2c_init(struct aspeed_i2c_bus *bus, >> if (ret < 0) >> return ret; >> >> - if (!of_property_read_bool(pdev->dev.of_node, "multi-master")) >> + if (of_property_read_bool(pdev->dev.of_node, "multi-master")) >> + bus->multi_master = true; >> + else >> fun_ctrl_reg |= ASPEED_I2CD_MULTI_MASTER_DIS; >> >> /* Enable Master Mode */ >> -- >> 2.19.1 >>
next prev parent reply other threads:[~2018-11-28 22:30 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-30 21:09 [PATCH i2c-next v9 0/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases Jae Hyun Yoo 2018-10-30 21:09 ` [PATCH i2c-next v9 1/5] dt-bindings: i2c: Add 'bus-timeout-ms' and '#retries' properties as common optional Jae Hyun Yoo 2018-11-28 21:54 ` Wolfram Sang 2018-11-28 22:36 ` Jae Hyun Yoo 2018-10-30 21:09 ` [PATCH i2c-next v9 2/5] i2c: core: Add support reading of 'bus-timeout-ms' and '#retries' properties Jae Hyun Yoo 2018-10-30 21:09 ` [PATCH i2c-next v9 3/5] dt-bindings: i2c: aspeed: Add 'bus-timeout-ms' property as an optional property Jae Hyun Yoo 2018-10-30 21:09 ` [PATCH i2c-next v9 4/5] i2c: aspeed: Remove hard-coded bus timeout value setting Jae Hyun Yoo 2018-10-30 21:09 ` [PATCH i2c-next v9 5/5] i2c: aspeed: Add bus idle waiting logic for multi-master use cases Jae Hyun Yoo [not found] ` <201810310601.Odxb7qSY%fengguang.wu@intel.com> 2018-10-30 23:04 ` Jae Hyun Yoo 2018-11-01 17:44 ` kbuild test robot 2018-11-01 18:09 ` Jae Hyun Yoo 2018-11-28 21:54 ` Wolfram Sang 2018-11-28 22:30 ` Jae Hyun Yoo [this message] 2019-01-15 22:47 ` [PATCH i2c-next v9 0/5] " Wolfram Sang 2019-01-15 23:32 ` Jae Hyun Yoo
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=2772b86e-6ffb-e289-40f2-f96d11b82349@linux.intel.com \ --to=jae.hyun.yoo@linux.intel.com \ --cc=andrew@aj.id.au \ --cc=benh@kernel.crashing.org \ --cc=brendanhiggins@google.com \ --cc=devicetree@vger.kernel.org \ --cc=james.feist@linux.intel.com \ --cc=jarkko.nikula@linux.intel.com \ --cc=joel@jms.id.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-aspeed@lists.ozlabs.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=openbmc@lists.ozlabs.org \ --cc=robh+dt@kernel.org \ --cc=vernon.mauery@linux.intel.com \ --cc=wsa@the-dreams.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).