From: Yicong Yang <yangyicong@hisilicon.com>
To: Dmitry Osipenko <digetx@gmail.com>, <wsa@kernel.org>,
<linux-i2c@vger.kernel.org>
Cc: <andriy.shevchenko@linux.intel.com>, <treding@nvidia.com>,
<jarkko.nikula@linux.intel.com>, <rmk+kernel@armlinux.org.uk>,
<song.bao.hua@hisilicon.com>, <john.garry@huawei.com>,
<prime.zeng@huawei.com>, <linuxarm@huawei.com>
Subject: Re: [PATCH v3 2/3] i2c: add support for HiSilicon I2C controller
Date: Wed, 24 Mar 2021 17:30:19 +0800 [thread overview]
Message-ID: <e18bec78-8913-2d11-00b9-e229688caae6@hisilicon.com> (raw)
In-Reply-To: <7801d460-c1f4-5088-0ba0-47a07d187a2a@gmail.com>
Hi Dmitry,
Thanks for reviewing this.
On 2021/3/22 23:21, Dmitry Osipenko wrote:
> Hello Yicong,
>
> 22.03.2021 14:10, Yicong Yang пишет:
>> Add HiSilicon I2C controller driver for the Kunpeng SoC. It provides
>> the access to the i2c busses, which connects to the eeprom, rtc, etc.
>>
>> The driver works with IRQ mode, and supports basic I2C features and 10bit
>> address. The DMA is not supported.
>>
>> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
>> ---
>> drivers/i2c/busses/Kconfig | 10 +
>> drivers/i2c/busses/Makefile | 1 +
>> drivers/i2c/busses/i2c-hisi.c | 525 ++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 536 insertions(+)
>> create mode 100644 drivers/i2c/busses/i2c-hisi.c
>
> ...
>> +
>> +#define NSEC_TO_CYCLES(ns, clk_rate_khz) (DIV_ROUND_UP_ULL((clk_rate_khz) * (ns), NSEC_PER_MSEC))
>
> This is a very long line, you should split it into two.
will split.
>
> Parens around DIV_ROUND_UP_ULL aren't needed.
>
will drop the parens.
> ...
>> +static void hisi_i2c_enable_int(struct hisi_i2c_controller *ctlr, u32 mask)
>> +{
>> + writel(mask, ctlr->iobase + HISI_I2C_INT_MASK);
>
> Why you don't use relaxed versions of readl/writel? Do you really need
> to insert memory barriers?
>
this will not be used during the transfer process, so a relaxed version of readl/writel
will not have performance enhancement.
the barriers are necessary as i want to make the operations in order to avoid potential
problems caused by reordering.
>> +}
>> +
>> +static void hisi_i2c_disable_int(struct hisi_i2c_controller *ctlr, u32 mask)
>> +{
>> + writel((~mask) & HISI_I2C_INT_ALL, ctlr->iobase + HISI_I2C_INT_MASK);
>> +}
>> +
>> +static void hisi_i2c_clear_int(struct hisi_i2c_controller *ctlr, u32 mask)
>> +{
>> + writel(mask, ctlr->iobase + HISI_I2C_INT_CLR);
>> +}
>> +
>> +static void hisi_i2c_handle_errors(struct hisi_i2c_controller *ctlr)
>> +{
>> + u32 int_err = ctlr->xfer_err, reg;
>> +
>> + if (int_err & HISI_I2C_INT_FIFO_ERR) {
>> + reg = readl(ctlr->iobase + HISI_I2C_FIFO_STATE);
>> +
>> + if (reg & HISI_I2C_FIFO_STATE_RX_RERR)
>> + dev_err(ctlr->dev, "rx fifo error read.\n");
>
> The dot "." in the end of error messages is unnecessary.
>
i'd like to keep this, as i think this is rather driver specific and not
violating any rules.
> ...
>> +/*
>> + * Initialize the transfer information and start the I2C bus transfer.
>> + * We only configure the transfer and do some pre/post works here, and
>> + * wait for the transfer done. The major transfer process is performed
>> + * in the IRQ handler.
>> + */
>> +static int hisi_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
>> + int num)
>> +{
>> + struct hisi_i2c_controller *ctlr = i2c_get_adapdata(adap);
>> + DECLARE_COMPLETION_ONSTACK(done);
>> + int ret = num;
>> +
>> + hisi_i2c_reset_xfer(ctlr);
>> + ctlr->completion = &done;
>> + ctlr->msg_num = num;
>> + ctlr->msgs = msgs;
>> +
>> + hisi_i2c_start_xfer(ctlr);
>> +
>> + if (!wait_for_completion_timeout(ctlr->completion, adap->timeout)) {
>> + hisi_i2c_disable_int(ctlr, HISI_I2C_INT_ALL);
>
> This doesn't save you from racing with the interrupt handler. It looks
> like you need to enable/disable IRQ around the completion, similarly to
> what NVIDIA Tegra I2C driver does.
>
thanks for suggestion.
the hardware between tegra and this one is a little different as we don't provide
a way to reinit the controller. so {synchronize,disable}_irq() after mask
the interrupt here will avoid the race.
Thanks,
Yicong
> .
>
next prev parent reply other threads:[~2021-03-24 9:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 11:10 [PATCH v3 0/3] Add support for HiSilicon I2C controller Yicong Yang
2021-03-22 11:10 ` [PATCH v3 1/3] i2c: core: add managed function for adding i2c adapters Yicong Yang
2021-03-22 16:35 ` Andy Shevchenko
2021-03-24 8:26 ` Yicong Yang
2021-03-24 11:05 ` Andy Shevchenko
2021-03-22 16:45 ` Dmitry Osipenko
2021-03-24 8:29 ` Yicong Yang
2021-03-24 11:06 ` Andy Shevchenko
2021-03-22 11:10 ` [PATCH v3 2/3] i2c: add support for HiSilicon I2C controller Yicong Yang
2021-03-22 15:21 ` Dmitry Osipenko
2021-03-24 9:30 ` Yicong Yang [this message]
2021-03-24 12:26 ` Dmitry Osipenko
2021-03-22 16:59 ` Andy Shevchenko
2021-03-24 10:07 ` Yicong Yang
2021-03-24 11:15 ` Andy Shevchenko
2021-03-22 17:04 ` Andy Shevchenko
2021-03-24 10:21 ` Yicong Yang
2021-03-24 11:16 ` Andy Shevchenko
2021-03-22 11:10 ` [PATCH v3 3/3] MAINTAINERS: Add maintainer for HiSilicon I2C driver Yicong Yang
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=e18bec78-8913-2d11-00b9-e229688caae6@hisilicon.com \
--to=yangyicong@hisilicon.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=digetx@gmail.com \
--cc=jarkko.nikula@linux.intel.com \
--cc=john.garry@huawei.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=prime.zeng@huawei.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=song.bao.hua@hisilicon.com \
--cc=treding@nvidia.com \
--cc=wsa@kernel.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 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).