Messages in this thread | | | Subject | Re: [PATCH v1 6/6] i2c: iproc: handle rx fifo full interrupt | From | Ray Jui <> | Date | Mon, 26 Oct 2020 17:36:04 -0700 |
| |
On 10/26/2020 8:13 AM, Rayagonda Kokatanur wrote: > Hi Dhanajay, > > On Fri, Oct 23, 2020 at 11:12 PM Ray Jui <ray.jui@broadcom.com> wrote: >> >> >> >> On 10/12/2020 3:03 PM, Dhananjay Phadke wrote: >>> From: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.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? >> >> Hi Rayagonda, >> >> Could you please reply on this question? For transactions > 64 bytes, do >> we batch until RX FIFO is full before we read out the data? > > Sorry I missed this question. > Yes with current design we are batching 64 bytes for translation > 64 bytes. >
So we do batch the transfer and read them in one shot, and that's how the FIFO full interrupt is being utilized for. That sounds okay to me.
Thanks,
Ray
> Best regards, > Rayagonda > > >> >> Thanks, >> >> Ray >> >>> Does controller stretch clock when rx fifo is full (e.g. kernel has >>> crashed, bus driver isn't draining fifo)? >>> [unhandled content-type:application/pkcs7-signature]
| |