From: Mike Isely <isely@isely.net>
To: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: Stefan Wahren <wahrenst@gmx.net>,
mike.isely@cobaltdigital.com, Andi Shyti <andi.shyti@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Phil Elwell <phil@raspberrypi.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Ray Jui <rjui@broadcom.com>,
Scott Branden <sbranden@broadcom.com>,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mike Isely at pobox <isely@pobox.com>
Subject: aborting i2c bcm2835 controller [was: [PATCH 2/2] [i2c-bcm2835] ALWAYS enable INTD]
Date: Wed, 1 Nov 2023 16:12:13 -0500 (CDT) [thread overview]
Message-ID: <2c8c3030-ede6-5283-a0a9-703df43245ac@isely.net> (raw)
In-Reply-To: <ba291591-a733-78a6-f315-20e1c17e8677@isely.net>
On Wed, 1 Nov 2023, Mike Isely wrote:
[...]
> > > Given that the hardware can detect clock stretch problems then there
> > > really should be no circumstance where the controller silicon can leave
> > > the bus stuck.
> >
> > I can't find my debug notes from May, but it was aborting part way
> > through a multi-byte read from the touchscreen without a STOP
> > condition, leaving the touch controller still thinking it was still
> > clocking out the current byte, so it messed up the next transaction.
> > Hitting BCM2835_I2C_C with BCM2835_I2C_C_CLEAR whilst BCM2835_I2C_S_TA
> > is set will abort immediately with no STOP :-(
>
> That's probably because the DLEN register still has a non-zero value and
> now the hardware is waiting for you to push more bytes into the FIFO
> (since you just cleared out what was already there). Thus it won't
> release the bus until it has processed all expected bytes. Setting DLEN
> to zero first then clearing the FIFO might be the way to fix that.
I just re-read the datasheet and it does indeed state that clearing the
FIFO would abort the transaction. But are you doing the clearing by
just writing a word to the control register with CLEAR set or were you
ensuring to preserve the state of I2CEN as well? Because if you were
also unintentionally writing a zero to I2CEN as well I can see that
freezing the RTL's state machine and thus jamming the bus. To actually
do the abort still requires a few state transitions in order release the
bus - and if the controller has been disabled then a jam would not be
unexpected. In all other cases in the driver, you're only writing to
the control register after the hardware has idled, so disabling the
controller in this way would be working ok.
I wonder if hitting CLEAR while also keeping I2CEN set and INTD on would
then allow the hardware to sequence itself to release the bus then issue
a DONE back to the driver once everything is idle.
[...]
-Mike
prev parent reply other threads:[~2023-11-01 21:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 16:21 [PATCH 0/2] Fix error-leg bugs / misbehaviors in i2c-bcm2835 driver mike.isely
2023-10-30 16:21 ` [PATCH 1/2] [i2c-bcm2835] Fully clean up hardware state machine after a timeout mike.isely
2023-10-31 11:43 ` Andi Shyti
2023-10-31 15:14 ` Dave Stevenson
2023-10-31 16:26 ` Mike Isely
2023-10-31 12:36 ` Stefan Wahren
2023-10-30 16:21 ` [PATCH 2/2] [i2c-bcm2835] ALWAYS enable INTD mike.isely
2023-10-31 12:37 ` Stefan Wahren
2023-10-31 15:34 ` Dave Stevenson
2023-10-31 16:44 ` Mike Isely
2023-10-31 18:04 ` Dave Stevenson
2023-11-01 19:26 ` Mike Isely
2023-11-01 21:12 ` Mike Isely [this message]
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=2c8c3030-ede6-5283-a0a9-703df43245ac@isely.net \
--to=isely@isely.net \
--cc=andi.shyti@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=florian.fainelli@broadcom.com \
--cc=isely@pobox.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=mike.isely@cobaltdigital.com \
--cc=phil@raspberrypi.com \
--cc=rjui@broadcom.com \
--cc=sbranden@broadcom.com \
--cc=wahrenst@gmx.net \
/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
all inboxes | Powered by JetHome®