From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Wolfram Sang <wsa@kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"linux@roeck-us.net" <linux@roeck-us.net>,
"jdelvare@suse.com" <jdelvare@suse.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 6/6] i2c: mpc: Interrupt driven transfer
Date: Sun, 11 Apr 2021 21:31:47 +0000 [thread overview]
Message-ID: <723acaa7-ff57-40c2-a733-a520c5899800@alliedtelesis.co.nz> (raw)
In-Reply-To: <20210410201302.GC2471@kunai>
On 11/04/21 8:13 am, Wolfram Sang wrote:
> On Mon, Mar 29, 2021 at 02:52:06PM +1300, Chris Packham wrote:
>> The fsl-i2c controller will generate an interrupt after every byte
>> transferred. Make use of this interrupt to drive a state machine which
>> allows the next part of a transfer to happen as soon as the interrupt is
>> received. This is particularly helpful with SMBUS devices like the LM81
>> which will timeout if we take too long between bytes in a transfer.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Okay, this change is too large and HW specific for a detailed review.
> But I trust you and hope you will be around to fix regressions if I
> apply it for 5.13?
Yep I plan on being around. I've got access to a couple of designs with
P2040 and T2081 so hopefully that's sufficient to deal with any
regressions. One issue is a lack of different i2c devices (the systems
we have tend to use the same devices) but hopefully any reports of
regression will be from people with access to such devices.
> That kind of leads to the question if you want to
> step up as the maintainer for this driver?
Sure can do. It'd be nice if it was someone from NXP but I think they've
lost interest in the PowerPC based SoCs. Should I send a patch for
MAINTAINERS? If so does that go through the i2c tree?
> Only thing I noticed was a "BUG" and "BUG_ON" and wonder if we really
> need to halt the kernel in that case. Maybe WARN is enough?
Yeah I think they can both be WARN variants. The one in mpc_xfer() can
happily continue. It's a little less clear what I should do in
mpc_i2c_do_action() if the WARN is ever hit but in theory it should be
an unreachable case anyway so the only thing that could get there is
some kind of memory corruption which would likely cause a crash elsewhere.
Do you want me to send a V3 of just that patch?
> I'll apply the first five patches now, they look good to me.
>
next prev parent reply other threads:[~2021-04-11 21:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-29 1:52 [PATCH v2 0/6] i2c: mpc: Refactor to improve responsiveness Chris Packham
2021-03-29 1:52 ` [PATCH v2 1/6] dt-bindings: i2c-mpc: Document interrupt property as required Chris Packham
2021-03-30 15:13 ` Rob Herring
2021-03-29 1:52 ` [PATCH v2 2/6] dt-bindings: i2c: convert i2c-mpc to json-schema Chris Packham
2021-03-30 15:18 ` Rob Herring
2021-03-29 1:52 ` [PATCH v2 3/6] i2c: mpc: Make use of i2c_recover_bus() Chris Packham
2021-03-29 1:52 ` [PATCH v2 4/6] i2c: mpc: make interrupt mandatory and remove polling code Chris Packham
2021-04-10 20:16 ` Wolfram Sang
2021-04-11 23:57 ` Chris Packham
2021-03-29 1:52 ` [PATCH v2 5/6] i2c: mpc: use device managed APIs Chris Packham
2021-04-12 22:52 ` Andy Shevchenko
2021-04-12 22:55 ` Andy Shevchenko
2021-04-12 23:21 ` Chris Packham
2021-04-12 23:26 ` Chris Packham
2021-04-12 23:34 ` Andy Shevchenko
2021-03-29 1:52 ` [PATCH v2 6/6] i2c: mpc: Interrupt driven transfer Chris Packham
2021-04-10 20:13 ` Wolfram Sang
2021-04-11 21:31 ` Chris Packham [this message]
2021-04-12 18:17 ` Wolfram Sang
2021-04-12 22:57 ` Andy Shevchenko
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=723acaa7-ff57-40c2-a733-a520c5899800@alliedtelesis.co.nz \
--to=chris.packham@alliedtelesis.co.nz \
--cc=devicetree@vger.kernel.org \
--cc=jdelvare@suse.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=robh+dt@kernel.org \
--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).