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: <80c524c3-8c31-346d-2691-48f93fa6001f@denx.de>
Date:   Wed, 29 Jun 2022 16:05:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH v2 03/10] i2c: xiic: Switch to Xiic standard mode for
 i2c-read
Content-Language: en-US
To:     Krzysztof Adamski <krzysztof.adamski@nokia.com>,
        Raviteja Narayanam <raviteja.narayanam@xilinx.com>,
        linux-i2c@vger.kernel.org, michal.simek@xilinx.com
Cc:     linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        git@xilinx.com, joe@perches.com
References: <20210626102806.15402-1-raviteja.narayanam@xilinx.com>
 <20210626102806.15402-4-raviteja.narayanam@xilinx.com>
 <ad7626bd-bcbb-48fc-5e32-bc95fafcb917@nokia.com>
From:   Marek Vasut <marex@denx.de>
In-Reply-To: <ad7626bd-bcbb-48fc-5e32-bc95fafcb917@nokia.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 6/29/22 14:47, Krzysztof Adamski wrote:
> W dniu 26.06.2021 o 12:27, Raviteja Narayanam pisze:
>> Xilinx I2C IP has two modes of operation, both of which implement
>> I2C transactions. The only difference from sw perspective is the
>> programming sequence for these modes.
>> Dynamic mode  -> Simple to program, less number of steps in sequence.
>> Standard mode -> Gives flexibility, more number of steps in sequence.
>>
>> In dynamic mode, during the i2c-read transactions, if there is a
>> delay(> 200us) between the register writes (address & byte count),
>> read transaction fails. On a system with load, this scenario is
>> occurring frequently.
>> To avoid this, switch to standard mode if there is a read request.
>>
>> Added a quirk to identify the IP version effected by this and follow
>> the standard mode.
>>
>> Signed-off-by: Raviteja Narayanam <raviteja.narayanam@xilinx.com>
> 
> [...]
> 
> If those two modes only differ in software complexity but we are not
> able to support only the simpler one and we have support for the more
> complicated (standard mode) anyways, we know that standard mode
> can handle or the cases while dynamic mode cannot, we also know that
> dynamic mode is broken on some versions of the core, why do we actually
> keep support for dynamic mode?

If I recall it right, the dynamic mode was supposed to handle transfers 
longer than 255 Bytes, which the core cannot do in Standard mode. It is 
needed e.g. by Atmel MXT touch controller. I spent a lot of time 
debugging the race conditions in the XIIC, which I ultimately fixed (the 
patches are upstream), but the long transfers I rather fixed in the MXT 
driver instead.

I also recall there was supposed to be some update for the XIIC core 
coming with newer vivado, but I might be wrong about that.