linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Adamski <krzysztof.adamski@nokia.com>
To: Manikanta Guntupalli <manikanta.guntupalli@xilinx.com>,
	michal.simek@xilinx.com, michal.simek@amd.com,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
	linux-kernel@vger.kernel.org, git@amd.com
Cc: Raviteja Narayanam <raviteja.narayanam@xilinx.com>
Subject: Re: [PATCH 01/12] i2c: xiic: Add standard mode support for > 255 byte read transfers
Date: Wed, 29 Jun 2022 14:18:34 +0200	[thread overview]
Message-ID: <9d90d39c-c5ce-409b-9b87-71592dcca1cc@nokia.com> (raw)
In-Reply-To: <1656072327-13628-2-git-send-email-manikanta.guntupalli@xilinx.com>


W dniu 24.06.2022 o 14:05, Manikanta Guntupalli pisze:
[...]
> +static void xiic_std_fill_tx_fifo(struct xiic_i2c *i2c)
> +{
> +	u8 fifo_space = xiic_tx_fifo_space(i2c);
> +	u16 data = 0;
> +	int len = xiic_tx_space(i2c);
> +
> +	dev_dbg(i2c->adap.dev.parent, "%s entry, len: %d, fifo space: %d\n",
> +		__func__, len, fifo_space);
> +
> +	if (len > fifo_space)
> +		len = fifo_space;
> +	else if (len && !(i2c->repeated_start))
> +		len--;
> +
> +	while (len--) {
> +		data = i2c->tx_msg->buf[i2c->tx_pos++];
> +		xiic_setreg16(i2c, XIIC_DTR_REG_OFFSET, data);
> +	}
> +}
This function looks very similar to the original xiic_fill_tx_fifo. The
only difference is that it does not decrease the len in case of
repeated_start (btw, why?), and it does not set the DYN_STOP bit. But
this could be done conditionally based on i2c->dynamic, instead. No need
for this duplication, in my opinion.
[...]
> @@ -579,31 +681,99 @@ static int xiic_busy(struct xiic_i2c *i2c)
>   static void xiic_start_recv(struct xiic_i2c *i2c)
>   {
>   	u16 rx_watermark;
> +	u8 cr = 0, rfd_set = 0;
>   	struct i2c_msg *msg = i2c->rx_msg = i2c->tx_msg;
> +	unsigned long flags;
>   
> -	/* Clear and enable Rx full interrupt. */
> -	xiic_irq_clr_en(i2c, XIIC_INTR_RX_FULL_MASK | XIIC_INTR_TX_ERROR_MASK);
> +	dev_dbg(i2c->adap.dev.parent, "%s entry, ISR: 0x%x, CR: 0x%x\n",
> +		__func__, xiic_getreg32(i2c, XIIC_IISR_OFFSET),
> +		xiic_getreg8(i2c, XIIC_CR_REG_OFFSET));
>   
> -	/* we want to get all but last byte, because the TX_ERROR IRQ is used
> -	 * to inidicate error ACK on the address, and negative ack on the last
> -	 * received byte, so to not mix them receive all but last.
> -	 * In the case where there is only one byte to receive
> -	 * we can check if ERROR and RX full is set at the same time
> -	 */
> -	rx_watermark = msg->len;
> -	if (rx_watermark > IIC_RX_FIFO_DEPTH)
> -		rx_watermark = IIC_RX_FIFO_DEPTH;
> -	xiic_setreg8(i2c, XIIC_RFD_REG_OFFSET, (u8)(rx_watermark - 1));

Do we really want to write 255 to RFD if msg->len == 0? That will set
the compare value in the RX_FIFO_PIRQ register to max value (15) but I
don't understand why we would like to do this.
Also, bits 31:4 are reserved so I think we should not try to touch them.

> +	/* Disable Tx interrupts */
> +	xiic_irq_dis(i2c, XIIC_INTR_TX_HALF_MASK | XIIC_INTR_TX_EMPTY_MASK);
>   
> -	if (!(msg->flags & I2C_M_NOSTART))
> -		/* write the address */
> -		xiic_setreg16(i2c, XIIC_DTR_REG_OFFSET,
> -			i2c_8bit_addr_from_msg(msg) | XIIC_TX_DYN_START_MASK);
>   
> -	xiic_irq_clr_en(i2c, XIIC_INTR_BNB_MASK);
> +	if (i2c->dynamic) {
> +		u8 bytes;
> +		u16 val;
>   
> -	xiic_setreg16(i2c, XIIC_DTR_REG_OFFSET,
> -		msg->len | ((i2c->nmsgs == 1) ? XIIC_TX_DYN_STOP_MASK : 0));
> +		/* Clear and enable Rx full interrupt. */
> +		xiic_irq_clr_en(i2c, XIIC_INTR_RX_FULL_MASK |
> +				XIIC_INTR_TX_ERROR_MASK);
> +
> +		/*
> +		 * We want to get all but last byte, because the TX_ERROR IRQ
> +		 * is used to indicate error ACK on the address, and
> +		 * negative ack on the last received byte, so to not mix
> +		 * them receive all but last.
> +		 * In the case where there is only one byte to receive
> +		 * we can check if ERROR and RX full is set at the same time
> +		 */
> +		rx_watermark = msg->len;
> +		bytes = min_t(u8, rx_watermark, IIC_RX_FIFO_DEPTH);
> +		bytes--;
Again, do we really want to write 255 to RFD if msg->len == 0?

> +
> +		xiic_setreg8(i2c, XIIC_RFD_REG_OFFSET, bytes);
> +
> +		local_irq_save(flags);
> +		if (!(msg->flags & I2C_M_NOSTART))
> +			/* write the address */
> +			xiic_setreg16(i2c, XIIC_DTR_REG_OFFSET,
> +				      i2c_8bit_addr_from_msg(msg) |
> +				      XIIC_TX_DYN_START_MASK);
When reviewing this patch, I tried to understand how the controller
knows if it should work in dynamic or in stanard mode. My understanding
is that in order to start the dynamic mode logic, we have to set the
DYN_START bit in the TX FIFO when we write an address there. Is this
correct? But we don't do that if I2C_M_NOSTART flag is set so how is
this supposed to work with this flag? I mean, does the controller really
supports doing I2C_M_NOSTART in dynamic mode?

Or does it support it at all? After all, when we skip this, we will
still write to the TX_FIFO register 5 lines below. How is the controller
supposed to know that the len that we write there is *not* actually an
address?

That being said, we do not annouce the I2C_FUNC_NOSTART support so maybe
we should not care at all and just remove the code handling the
I2C_M_NOSTART flag?
> +
> +		xiic_irq_clr_en(i2c, XIIC_INTR_BNB_MASK);
> +
> +		/* If last message, include dynamic stop bit with length */
> +		val = (i2c->nmsgs == 1) ? XIIC_TX_DYN_STOP_MASK : 0;
> +		val |= msg->len;
> +
> +		xiic_setreg16(i2c, XIIC_DTR_REG_OFFSET, val);
> +		local_irq_restore(flags);
> +	} else {
> +		cr = xiic_getreg8(i2c, XIIC_CR_REG_OFFSET);
> +
> +		/* Set Receive fifo depth */
> +		rx_watermark = msg->len;
> +		if (rx_watermark > IIC_RX_FIFO_DEPTH) {
> +			rfd_set = IIC_RX_FIFO_DEPTH - 1;
> +		} else if ((rx_watermark == 1) || (rx_watermark == 0)) {
> +			rfd_set = rx_watermark - 1;
Again, do we really want to write 255 to RFD if msg->len == 0?
[...]

Krzysztof

  reply	other threads:[~2022-06-29 12:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-24 12:05 [PATCH 00/12] i2c: xiic: Added Standard mode and SMBus Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 01/12] i2c: xiic: Add standard mode support for > 255 byte read transfers Manikanta Guntupalli
2022-06-29 12:18   ` Krzysztof Adamski [this message]
2022-07-13  7:54     ` Guntupalli, Manikanta
2022-07-20 10:26       ` Krzysztof Adamski
2022-07-26 10:35         ` Guntupalli, Manikanta
2022-06-24 12:05 ` [PATCH 02/12] i2c: xiic: Enter standard mode only " Manikanta Guntupalli
2022-06-29 12:21   ` Krzysztof Adamski
2022-06-30  8:06     ` Guntupalli, Manikanta
2022-06-24 12:05 ` [PATCH 03/12] i2c: xiic: Fix Rx and Tx paths in standard mode repeated start Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 04/12] i2c: xiic: Add wait for FIFO empty in send_tx Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 05/12] i2c: xiic: Use 'nmsgs' variable instead of repeated_start Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 06/12] i2c: xiic: Add smbus_block_read functionality Manikanta Guntupalli
2022-06-29 12:25   ` Krzysztof Adamski
2022-06-24 12:05 ` [PATCH 07/12] i2c: xiic: Switch to Xiic standard mode for i2c-read Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 08/12] i2c: xiic: Remove interrupt enable/disable in Rx path Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 09/12] dt-bindings: i2c: xiic: Add 'xlnx,axi-iic-2.1' to compatible Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 10/12] i2c: xiic: Update compatible with new IP version Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 11/12] i2c: xiic: Add SCL frequency configuration support Manikanta Guntupalli
2022-06-24 12:05 ` [PATCH 12/12] i2c: xiic: Correct the BNB interrupt enable sequence Manikanta Guntupalli
2022-06-29 13:13   ` Krzysztof Adamski
2022-07-13  8:02     ` Guntupalli, Manikanta

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=9d90d39c-c5ce-409b-9b87-71592dcca1cc@nokia.com \
    --to=krzysztof.adamski@nokia.com \
    --cc=git@amd.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manikanta.guntupalli@xilinx.com \
    --cc=michal.simek@amd.com \
    --cc=michal.simek@xilinx.com \
    --cc=raviteja.narayanam@xilinx.com \
    /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).