Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9d90d39c-c5ce-409b-9b87-71592dcca1cc@nokia.com>
Date:   Wed, 29 Jun 2022 14:18:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH 01/12] i2c: xiic: Add standard mode support for > 255 byte
 read transfers
Content-Language: en-US
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>
References: <1656072327-13628-1-git-send-email-manikanta.guntupalli@xilinx.com>
 <1656072327-13628-2-git-send-email-manikanta.guntupalli@xilinx.com>
From:   Krzysztof Adamski <krzysztof.adamski@nokia.com>
In-Reply-To: <1656072327-13628-2-git-send-email-manikanta.guntupalli@xilinx.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aElkT1NYdU9NTXNlOWc1bWZZU0loaUY0aDVQT0FibTFlbVJtK2tVTUhqbkN1?=
 =?utf-8?B?SkVMaVk2Q0hzc2xZNjh2NVdnT2doK2JEL21nbWpJTzJNOHQrdlVwbU8wMFFs?=
 =?utf-8?B?MTIraDRvV05XazczNWl3SHdYaDEzQllYZHdLRE5oYzBXZTNINSs0SGVtbWJM?=
 =?utf-8?B?eUZpR1hKOXFrMExKMHFCNk1Dbnh4cUR2bEZEalUzL1I5MDFZMVNsYzI1RHh1?=
 =?utf-8?B?bDFZbWNkTEI2WmRCYWZHUzZyNVJJWFRMbUtlU3U0WmxDTGt1Ulh1VHFtN0ho?=
 =?utf-8?B?T1QrWTg5OUhNTHQzdHZreUZNaU1yZmVacXJJM2czVy8xanRNbk15N0M4UXdP?=
 =?utf-8?B?eXM3RzU5UFJUMXFsTWp0ekZ5YkNJQmttb09BUVNxaHprOFkvUXV1aWtra3U2?=
 =?utf-8?B?TmN4Um5rOVJGOVdpY3ZjTi9yTnFaZjdQYWtxWWcyVzBRemtydnBYMVgwaWlm?=
 =?utf-8?B?UGlCT2lqUkMyN0M0ZUYzb0k4UENsNWVJN2ZGc21YSEQvaSs4cFhlTTd5UzZx?=
 =?utf-8?B?eVk1bDhINmlHaExOU2ZHTjVDVExUY1lNaDUvQTVwZDV4WnFwQU5mTC9QemJK?=
 =?utf-8?B?RU5IQXpUdi9KZ1J2MHpDM0N6ZlBvZlBnaXoxWUpqR2pjYUhUODN0Z1NKNEZo?=
 =?utf-8?B?SjljZUVsbWRzOTFqZVE0cDgxcU1SWDBkN3RjczA4a29DVWFVMVhsNEl0YXAz?=
 =?utf-8?B?elJzY3pWNGZLNkZuWFFNSnpJM3VTRVFXSVd1YWd6eWsvYW12MkZFN2FRQ1lJ?=
 =?utf-8?B?ZzdpTFJWM0c0OTZva04yOEpodnhIQUsyVUpjRWZFamxlQm5iWnZiamlHaHFw?=
 =?utf-8?B?b0EwSTA1K0xFQWhPNHZ6c2s1Z25KOERaUVZKcWZtazVRMjdrRytudkNUbC9C?=
 =?utf-8?B?UFBaQ2pqTXFxckNweGh3WjNBcUZ6amU5dzlqYWczc1dXWGhmSlNMNytJTHdJ?=
 =?utf-8?B?bDZEdTZJZVJNRDRFdVJ6M2xLaU9VV2l3NklHQ2IvRUwxUUdhdFVnelc3Y2s5?=
 =?utf-8?B?Q3BRNVdyYUFkOWMycFpsN1dkTnVaOFVzU1Z4SEZqd2Q2TFk5a2huc3g0dVBT?=
 =?utf-8?B?QStrUnpqR0hJdUZBdkFrVWdqaHNvamNyZmRta3NwanFzQ3NpYzhtWlBwNU1K?=
 =?utf-8?B?dHlEdEphcmRDWG1nd3h3YysrYkhHaEx0eTAxWFExYW8wTEZnNXgxMTFlREhv?=
 =?utf-8?B?R2VrZXg3aHZ6MFFUTmxUNmRSSktpdE9GSEd4Zm8zUko4NHBmZWNHQ3NhOFdu?=
 =?utf-8?B?YkNUcURxcC9ma3R5U2p4V1JPYjFVdDRud0tVTnhNRmRlVlNsZ2ZFak1ybU1a?=
 =?utf-8?B?LzEyMVdLRXlQMTRVUGFVOWw3RWlsbGNVdW02NCswRUdLM2NNZWd2TVBuMExE?=
 =?utf-8?B?TkVHZ2xVaytQNGdTdytLdkhvRzVmdUdlTlZvNlJjNVdWbXg3WXUwWDBOTWFs?=
 =?utf-8?B?bG1zT2twSEN3WWJ0ZndSVVNGbG8rMzNGWlc4L2J1RGplWVAyUjY3QUgwdkdz?=
 =?utf-8?B?QTJhZlFpd25wSHEzUy9oOW1MMDBhZ2RyMU5PSElwcmZwWWlBMExxOEM1dG1X?=
 =?utf-8?B?d3lCMWFMWVRCdmJ6eE0yMGhIdEUwY21PQzUxK0JjQUFneFVMMnlBWk8xYnEv?=
 =?utf-8?B?UmI2SGxsMCtFRWZHbmU2emlISENVUUJJaEFRK2NFbjdzZmlvSnJianFqUTBq?=
 =?utf-8?B?UnNPcFRLRlRscHNQOFNLTC9OSEdpaWVid09oZGNjeVIwM2xCaDVCTTNBNWkr?=
 =?utf-8?B?TDNzZkhqMFA0Ri9nbEhLYll6cVYvU2R1NE5mc0lZdHB0NnJuajNnV0ZJTllC?=
 =?utf-8?B?bDhucldGaHhIV2tsejRJNE9LVjhjMUlVTStJdklJSlk4Vk1BVDhtdGhxeU5Y?=
 =?utf-8?B?VlY1c3A1ODFvcnRodlExb1Zma3pOZUNzcC9vemp2YVNFMURQWCswaEFLTFpK?=
 =?utf-8?B?bEhHWlgraFhDdVZDMUJ6eU0xT3V6Lzlvb1ZjcUFmMk53anJWWFhBMUpiaVBs?=
 =?utf-8?B?U2dkbEtqSVdDK3BRYzFZWExhem4yaVNGRVJybHl0a2RrYTc5dHhRWVUxdUN3?=
 =?utf-8?B?WGFkUWowdGFZYzltekdFai84cjR4eHI3THQ3dmhQSUtLRmxIemlmSSs4eG8y?=
 =?utf-8?B?NHI2YjlBSmo2MnQ0c1BSV200cnd5c2JXQVhlTnd0R2FGdC9BYjdJd3g2bk5x?=
 =?utf-8?B?UkE9PQ==?=
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a0cb7db-fcae-4b78-e4b2-08da59c97f42
X-MS-Exchange-CrossTenant-AuthSource: DU2PR07MB8110.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jun 2022 12:18:38.6610
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 36/DHD2K5S881/cLxrR1MG0zb7YEoqmcawxFbc/eWhzoQ/MVtmHw3szSE8E1i+bWeDK3LP5LOZlyhY9o3NqSstKhkHm7oh43j6j6NYS5yTo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR07MB8242
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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