From: Wolfram Sang <wsa@the-dreams.de>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: Baolin Wang <baolin.wang@spreadtrum.com>,
Mark Rutland <mark.rutland@arm.com>,
Rob Herring <robh+dt@kernel.org>,
andriy.shevchenko@linux.intel.com, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Mark Brown <broonie@kernel.org>
Subject: Re: [RESEND PATCH v4 2/2] i2c: Add Spreadtrum I2C controller driver
Date: Mon, 28 Aug 2017 17:13:06 +0200 [thread overview]
Message-ID: <20170828151306.GA10688@katana> (raw)
In-Reply-To: <CAMz4ku+MJ49-Orp4mGL=jW0bfnko5o9fZgAjpZKqAMVUiw-o4Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
> >> + /*
> >> + * 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.
>
> For our I2C controller databook, if the master did not get one ACK
> from slave when writing data to salve, we should send one STOP signal
> to abort this data transfer or generate one repeated START signal to
> start one new data transfer cycle. Considering our I2C usage
Yes, so far so good.
> scenarios, we should dump registers to analyze I2C status and notify
> to user to re-start new data transfer.
I disagree here. You notify the users by returning -EIO. The upper layer
(e.g. the i2c client driver) will handle it, like the EEPROM driver
might retry after a while. This all is expected behaviour, so no need to
print the registers to the logfile.
If you really, really want to keep it, make it debug output. But I think
the sentence "we should dump all registers" needs to be rephrased.
> As I explained before, in our Spreadtrum platform, our regulator
> driver will depend on I2C driver and the regulator driver uses
> subsys_initcall() level to initialize. Moreover some other drivers
> like GPU, they will depend on regulator to set voltage and they also
> need initialization much earlier.
>
> Since it is arch_initcall() level, Andy suggested I should get rid of
> tristate (use bool) and drop module.h here and all leftovers like
> MODULE_*() calls including module_exit().
I see. So the driver is really so essential for proper bootup that it is
not even allowed to be unloaded. I might make an exception here and
allow arch_initcall() then. But I do wonder: did you try deferred
probing all over the place?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-08-28 15:13 UTC|newest]
Thread overview: 19+ 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
2017-07-14 9:01 ` 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-07-14 9:01 ` Baolin Wang
2017-08-27 15:30 ` Wolfram Sang
2017-08-28 3:21 ` Baolin Wang
2017-08-28 15:13 ` Wolfram Sang [this message]
2017-08-29 1:58 ` Baolin Wang
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
2017-07-24 6:51 ` Baolin Wang
[not found] ` <20170724065146.GA22330-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
2017-07-27 9:29 ` Baolin Wang
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
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=20170828151306.GA10688@katana \
--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 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.