Devicetree
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Baolin Wang <baolin.wang@spreadtrum.com>
Cc: mark.rutland@arm.com, robh+dt@kernel.org,
	andriy.shevchenko@linux.intel.com, linux-i2c@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	broonie@kernel.org, baolin.wang@linaro.org
Subject: Re: [RESEND PATCH v4 2/2] i2c: Add Spreadtrum I2C controller driver
Date: Sun, 27 Aug 2017 17:30:54 +0200	[thread overview]
Message-ID: <20170827153054.ijqxbjk25zpskojl@ninjato> (raw)
In-Reply-To: <acbfda522aa806284b86f8935278cc7f7133e876.1500021046.git.baolin.wang@spreadtrum.com>

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

Hi,

thanks for your submission.

> +static void sprd_i2c_dump_reg(struct sprd_i2c *i2c_dev)
> +{
> +	dev_err(&i2c_dev->adap.dev, ": ======dump i2c-%d reg=======\n",
> +		i2c_dev->adap.nr);
> +	dev_err(&i2c_dev->adap.dev, ": I2C_CTRL:0x%x\n",
> +		readl(i2c_dev->base + I2C_CTL));
> +	dev_err(&i2c_dev->adap.dev, ": I2C_ADDR_CFG:0x%x\n",
> +		readl(i2c_dev->base + I2C_ADDR_CFG));
> +	dev_err(&i2c_dev->adap.dev, ": I2C_COUNT:0x%x\n",
> +		readl(i2c_dev->base + I2C_COUNT));
> +	dev_err(&i2c_dev->adap.dev, ": I2C_RX:0x%x\n",
> +		readl(i2c_dev->base + I2C_RX));
> +	dev_err(&i2c_dev->adap.dev, ": I2C_STATUS:0x%x\n",
> +		readl(i2c_dev->base + I2C_STATUS));
> +	dev_err(&i2c_dev->adap.dev, ": ADDR_DVD0:0x%x\n",
> +		readl(i2c_dev->base + ADDR_DVD0));
> +	dev_err(&i2c_dev->adap.dev, ": ADDR_DVD1:0x%x\n",
> +		readl(i2c_dev->base + ADDR_DVD1));
> +	dev_err(&i2c_dev->adap.dev, ": ADDR_STA0_DVD:0x%x\n",
> +		readl(i2c_dev->base + ADDR_STA0_DVD));
> +	dev_err(&i2c_dev->adap.dev, ": ADDR_RST:0x%x\n",
> +		readl(i2c_dev->base + ADDR_RST));

I really thing register dumps should be dev_dbg().

> +}
> +
> +static void sprd_i2c_set_count(struct sprd_i2c *i2c_dev, u32 count)
> +{
> +	writel(count, i2c_dev->base + I2C_COUNT);
> +}
> +
> +static void sprd_i2c_send_stop(struct sprd_i2c *i2c_dev, int stop)
> +{
> +	unsigned int tmp = readl(i2c_dev->base + I2C_CTL);

u32? Here and in many other places?

...

> +static irqreturn_t sprd_i2c_isr_thread(int irq, void *dev_id)
> +{
> +	struct sprd_i2c *i2c_dev = dev_id;
> +	struct i2c_msg *msg = i2c_dev->msg;
> +	int ack = readl(i2c_dev->base + I2C_STATUS) & I2C_RX_ACK;
> +	u32 i2c_count = readl(i2c_dev->base + I2C_COUNT);
> +	u32 i2c_tran;
> +
> +	if (msg->flags & I2C_M_RD)
> +		i2c_tran = i2c_dev->count >= I2C_FIFO_FULL_THLD;
> +	else
> +		i2c_tran = i2c_count;
> +
> +	/*
> +	 * If we got one ACK from slave when writing data, and we did not

Here you say: "If we get ack..."

> +	 * finish this transmission (i2c_tran is not zero), then we should
> +	 * continue to write data.
> +	 *
> +	 * For reading data, ack is always 0, if i2c_tran is not 0 which
> +	 * means we still need to contine to read data from slave.
> +	 */
> +	if (i2c_tran && !ack) {

... but the code gives the assumption you did NOT get an ack. So, either
rename the variable to 'ack_err' or keep it 'ack' and invert the logic
when initializing the variable.

> +		sprd_i2c_data_transfer(i2c_dev);
> +		return IRQ_HANDLED;
> +	}
> +
> +	i2c_dev->err = 0;
> +
> +	/*
> +	 * If we did not get one ACK from slave when writing data, we should
> +	 * dump all registers to check I2C status.

Why? I would say no. NACK from a slave can always happen, e.g. when an
EEPROM is busy erasing a page.

> +	 */
> +	if (ack) {
> +		i2c_dev->err = -EIO;
> +		sprd_i2c_dump_reg(i2c_dev);
> +	} else if (msg->flags & I2C_M_RD && i2c_dev->count) {
> +		sprd_i2c_read_bytes(i2c_dev, i2c_dev->buf, i2c_dev->count);
> +	}
> +
> +	/* Transmission is done and clear ack and start operation */
> +	sprd_i2c_clear_ack(i2c_dev);
> +	sprd_i2c_clear_start(i2c_dev);
> +	complete(&i2c_dev->complete);
> +
> +	return IRQ_HANDLED;
> +}

...

> +
> +	pm_runtime_set_autosuspend_delay(i2c_dev->dev, SPRD_I2C_PM_TIMEOUT);
> +	pm_runtime_use_autosuspend(i2c_dev->dev);
> +	pm_runtime_set_active(i2c_dev->dev);
> +	pm_runtime_enable(i2c_dev->dev);
> +
> +	ret = pm_runtime_get_sync(i2c_dev->dev);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "i2c%d pm runtime resume failed!\n",
> +			pdev->id);

Error message has wrong text.

> +		goto err_rpm_put;
> +	}
> +
> +static int sprd_i2c_init(void)
> +{
> +	return platform_driver_register(&sprd_i2c_driver);
> +}
> +arch_initcall_sync(sprd_i2c_init);

arch_initcall? and no exit() function? Why is it that way and/or why
can't you use platform_module_driver()?

Rest looks good. I like the comments you added to the code.

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-08-27 15:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14  9:01 [RESEND PATCH v4 1/2] dt-bindings: i2c: Add Spreadtrum I2C controller documentation Baolin Wang
     [not found] ` <eda1f25512db9c6946b303dd43f518ae2f0f3b26.1500021045.git.baolin.wang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
2017-07-14  9:01   ` [RESEND PATCH v4 2/2] i2c: Add Spreadtrum I2C controller driver Baolin Wang
2017-08-27 15:30     ` Wolfram Sang [this message]
2017-08-28  3:21       ` Baolin Wang
2017-08-28 15:13         ` Wolfram Sang
2017-08-29  1:58           ` Baolin Wang
2017-07-24  6:51   ` [RESEND PATCH v4 1/2] dt-bindings: i2c: Add Spreadtrum I2C controller documentation Baolin Wang
     [not found]     ` <20170724065146.GA22330-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
2017-07-27  9:29       ` Baolin Wang
2017-08-03  7:29         ` Baolin Wang
2017-08-03  8:26           ` Peter Rosin
2017-08-03  8:45             ` Baolin Wang
2017-08-03  9:00               ` Wolfram Sang
2017-08-03  9:05                 ` Baolin Wang

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=20170827153054.ijqxbjk25zpskojl@ninjato \
    --to=wsa@the-dreams.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=baolin.wang@linaro.org \
    --cc=baolin.wang@spreadtrum.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@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