13.06.2019 14:30, Bitan Biswas пишет: > > > On 6/12/19 7:30 AM, Dmitry Osipenko wrote: >> 11.06.2019 13:51, Bitan Biswas пишет: >>> Fix expression for residual bytes(less than word) transfer >>> in I2C PIO mode RX/TX. >>> >>> Signed-off-by: Bitan Biswas <bbiswas@xxxxxxxxxx> >>> --- >> >> [snip] >> >>> /* >>> - * Update state before writing to FIFO. If this casues us >>> + * Update state before writing to FIFO. If this causes us >>> * to finish writing all bytes (AKA buf_remaining goes to >>> 0) we >>> * have a potential for an interrupt (PACKET_XFER_COMPLETE is >>> - * not maskable). We need to make sure that the isr sees >>> - * buf_remaining as 0 and doesn't call us back re-entrantly. >>> + * not maskable). >>> */ >>> buf_remaining -= words_to_transfer * BYTES_PER_FIFO_WORD; >> >> Looks like the comment could be removed altogether because it doesn't >> make sense since interrupt handler is under xfer_lock which is kept >> locked during of tegra_i2c_xfer_msg(). > I would push a separate patch to remove this comment because of > xfer_lock in ISR now. > >> >> Moreover the comment says that "PACKET_XFER_COMPLETE is not maskable", >> but then what I2C_INT_PACKET_XFER_COMPLETE masking does? >> > I2C_INT_PACKET_XFER_COMPLETE masking support available in Tegra chips > newer than Tegra30 allows one to not see interrupt after Packet transfer > complete. With the xfer_lock in ISR the scenario discussed in comment > can be ignored. Also note that xfer_lock could be removed and replaced with a just irq_enable/disable() calls in tegra_i2c_xfer_msg() because we only care about IRQ not firing during of the preparation process. It also looks like tegra_i2c_[un]nmask_irq isn't really needed and all IRQ's could be simply unmasked during the driver's probe, in that case it may worth to add a kind of "in-progress" flag to catch erroneous interrupts.
