[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240603160018.29498c2f@xps-13>
Date: Mon, 3 Jun 2024 16:00:18 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Frank Li <Frank.Li@....com>
Cc: Conor Culhane <conor.culhane@...vaco.com>, Alexandre Belloni
<alexandre.belloni@...tlin.com>, linux-i3c@...ts.infradead.org (moderated
list:SILVACO I3C DUAL-ROLE MASTER), linux-kernel@...r.kernel.org (open
list), imx@...ts.linux.dev
Subject: Re: [PATCH 1/1] i3c: master: svc: resend target address when get
NACK
Hi Frank,
Frank.Li@....com wrote on Fri, 31 May 2024 12:33:00 -0400:
> According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3:
>
> If the Controller chooses to start an I3C Message with an I3C Dynamic
> Address, then special provisions shall be made because that same I3C Target
> may be initiating an IBI or a Controller Role Request. So, one of three
> things may happen: (skip 1, 2)
>
> 3. The Addresses match and the RnW bits also match, and so neither
> Controller nor Target will ACK since both are expecting the other side to
> provide ACK. As a result, each side might think it had "won" arbitration,
> but neither side would continue, as each would subsequently see that the
> other did not provide ACK.
> ...
> For either value of RnW: Due to the NACK, the Controller shall defer the
> Private Write or Private Read, and should typically transmit the Target
> ^^^^^^^^^^^^^^^^^^^
> Address again after a Repeated START (i.e., the next one or any one prior
> ^^^^^^^^^^^^^
> to a STOP in the Frame). Since the Address Header following a Repeated
> START is not arbitrated, the Controller will always win (see Section
> 5.1.2.2.4).
>
> Resend target address again if address is not 7E and controller get NACK.
>
> Signed-off-by: Frank Li <Frank.Li@....com>
I'm not getting 100% of it, but looks okay, so:
Reviewed-by: Miquel Raynal <miquel.raynal@...tlin.com>
Thanks,
Miquèl
Powered by blists - more mailing lists