Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Parshuram Raju Thombare <pthombar@cadence.com>
To:     Boris Brezillon <boris.brezillon@collabora.com>
CC:     "bbrezillon@kernel.org" <bbrezillon@kernel.org>,
        "vitor.soares@synopsys.com" <vitor.soares@synopsys.com>,
        Milind Parab <mparab@cadence.com>,
        Przemyslaw Gaj <pgaj@cadence.com>,
        "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v1 0/3] I3C mastership handover support
Thread-Topic: [PATCH v1 0/3] I3C mastership handover support
Thread-Index: AQHWDGGkJ2c7JAPQnkCuagmae7dgMKhvAV4AgABNf1A=
Date:   Wed, 8 Apr 2020 15:06:22 +0000
Message-ID: <DM5PR07MB31968BA9407E114EBE193C1BC1C00@DM5PR07MB3196.namprd07.prod.outlook.com>
References: <1586211645-8065-1-git-send-email-pthombar@cadence.com>
 <20200408120418.0d5235a6@collabora.com>
In-Reply-To: <20200408120418.0d5235a6@collabora.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: cadence.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 349310e1-85da-48ee-75ae-08d7dbce66d6
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 15:06:22.9612
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d36035c5-6ce6-4662-a3dc-e762e61ae4c9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QQ+IAdKA+Rr6CvB9EFBEPnO2ltUz9DBNtaHwE3n6WsBpntuMNMFu5iGUvX1t++1SzWXma+sKZSYO6GqwffOKEKuM+7IWu9R2WORJeWd0t4E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR07MB4119
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676
 definitions=2020-04-07_10:2020-04-07,2020-04-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_check_notspam policy=outbound_check score=0 mlxscore=0
 spamscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 bulkscore=0
 mlxlogscore=943 lowpriorityscore=0 malwarescore=0 phishscore=0
 clxscore=1011 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2003020000 definitions=main-2004080122
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Boris,

>It's definitely not the first version (as implied in the subject), and
>I'd like a proper changelog detailing what has changed since the last
>version (the one sent by Przemek).

Sure, I will resend patches with updated version and change log.

But just to summarize, main changes are
1. Secondary master deferring initialization i.e. registering devices
     representing other device as well as master itself, until bus
     ownership is achieved.
2. Moved bus request from slave and bus handover from current=20
    Master to separate state machines. This is to assist any further
    changes in mastership request/handover procedures. e.g. MIPI
    v1.1 specify additional features likes bus yield at the will of current
    master to sec master selected by current master, group address=20
    functionality, multi lane support etc which requires additional
    steps in handover procedure. This structure will help to extend=20
    the functionality further.
3. We don't really need secondary master to be aware other devices
    on the bus through mechanism like device tree, since main master
    broadcast this information through DEFSLVS. And receiving this
    information does not require sec. master driver to be loaded, at=20
    least in case of CDNS I3C controller .DEFSLVS information is stored
    by HW inside a table which is later accessed by controller driver,
    to be passed to I3C master subsystem. Sec master initialization=20
    state machine make sure it has active dynamic address (this may
    seems repetitive, but it is to handle case of RSTDAA CCC), and=20
    DEFSLVS is received at least once. And IMO we don't really need
    to process DEFSLVS for a sec master until it want to become current
    master.
4. Another important change is setting main master and sec master=20
    In pure bus mode during enumeration (DAA), this is to avoid need
    of sec. master having device information through device tree, and at =20
    the same time allowing enumeration to happened successfully.
    Both main master and sec master change bus mode once enumeration
    is done.

Regards,
Parshuram Thombare