mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Adamski <krzysztof.adamski@nokia.com>
To: 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, marex@denx.de,
	joe@perches.com
Subject: Re: [PATCH v2 03/10] i2c: xiic: Switch to Xiic standard mode for i2c-read
Date: Wed, 29 Jun 2022 14:47:37 +0200	[thread overview]
Message-ID: <ad7626bd-bcbb-48fc-5e32-bc95fafcb917@nokia.com> (raw)
In-Reply-To: <20210626102806.15402-4-raviteja.narayanam@xilinx.com>

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?

Krzysztof


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

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-26 10:27 [PATCH v2 00/10] i2c: xiic: Add features, bug fixes Raviteja Narayanam
2021-06-26 10:27 ` [PATCH v2 01/10] i2c: xiic: Fix Tx Interrupt path for grouped messages Raviteja Narayanam
2021-06-26 10:27 ` [PATCH v2 02/10] i2c: xiic: Add standard mode support for > 255 byte read transfers Raviteja Narayanam
2022-06-29 11:02   ` Krzysztof Adamski
2022-06-29 11:39     ` Michal Simek
2022-06-29 12:07       ` Krzysztof Adamski
2021-06-26 10:27 ` [PATCH v2 03/10] i2c: xiic: Switch to Xiic standard mode for i2c-read Raviteja Narayanam
2022-06-29 12:47   ` Krzysztof Adamski [this message]
2022-06-29 14:05     ` Marek Vasut
2022-06-29 14:09       ` Krzysztof Adamski
2022-06-29 14:34         ` Marek Vasut
2022-06-30  8:23         ` Datta, Shubhrajyoti
2022-07-01  7:01           ` Krzysztof Adamski
2022-07-04  5:45             ` Datta, Shubhrajyoti
2021-06-26 10:28 ` [PATCH v2 04/10] i2c: xiic: Remove interrupt enable/disable in Rx path Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 05/10] dt-bindings: i2c: xiic: Add 'xlnx,axi-iic-2.1' to compatible Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 06/10] i2c: xiic: Update compatible with new IP version Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 07/10] i2c: xiic: Return value of xiic_reinit Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 08/10] i2c: xiic: Fix the type check for xiic_wakeup Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 09/10] i2c: xiic: Fix coding style issues Raviteja Narayanam
2021-06-26 10:28 ` [PATCH v2 10/10] i2c: xiic: Add smbus_block_read functionality Raviteja Narayanam
2021-06-28  7:23 ` [PATCH v2 00/10] i2c: xiic: Add features, bug fixes Michal Simek
2021-07-16 16:01   ` Marek Vasut
2021-07-19 10:09     ` Raviteja Narayanam
2021-07-19 18:00       ` Marek Vasut
2021-07-20 14:19         ` Raviteja Narayanam
2021-07-20 21:43           ` Marek Vasut
2021-07-26  5:26             ` Raviteja Narayanam
2021-07-26 13:12               ` Marek Vasut
2021-07-28 10:11                 ` Raviteja Narayanam
2021-07-28 18:47                   ` Marek Vasut
2022-06-28  7:50                     ` 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=ad7626bd-bcbb-48fc-5e32-bc95fafcb917@nokia.com \
    --to=krzysztof.adamski@nokia.com \
    --cc=git@xilinx.com \
    --cc=joe@perches.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --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

all inboxes | Powered by JetHome®