[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20201011182254.17776-7-rayagonda.kokatanur@broadcom.com>
Date: Mon, 12 Oct 2020 15:03:04 -0700
From: Dhananjay Phadke <dphadke@...ux.microsoft.com>
To: rayagonda.kokatanur@...adcom.com
Cc: andriy.shevchenko@...ux.intel.com,
bcm-kernel-feedback-list@...adcom.com, brendanhiggins@...gle.com,
dphadke@...ux.microsoft.com, f.fainelli@...il.com,
linux-arm-kernel@...ts.infradead.org, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org, lori.hikichi@...adcom.com,
rjui@...adcom.com, sbranden@...adcom.com, wsa@...nel.org
Subject: [PATCH v1 6/6] i2c: iproc: handle rx fifo full interrupt
From: Rayagonda Kokatanur <rayagonda.kokatanur@...adcom.com>
On Sun, 11 Oct 2020 23:52:54 +0530, Rayagonda Kokatanur wrote:
> Add code to handle IS_S_RX_FIFO_FULL_SHIFT interrupt to support
> master write request with >= 64 bytes.
>
> Iproc has a slave rx fifo size of 64 bytes.
> Rx fifo full interrupt (IS_S_RX_FIFO_FULL_SHIFT) will be generated
> when RX fifo becomes full. This can happen if master issues write
> request of more than 64 bytes.
>
ARM cores run much faster than I2C bus, why would rx fifo go full when
rx interrupt is enabled and bytes are read out by bus driver isr?
Isn't fifo read pointer updated on these byte reads?
Does controller stretch clock when rx fifo is full (e.g. kernel has
crashed, bus driver isn't draining fifo)?
Powered by blists - more mailing lists