2020-04-06 23:29:17

by Parshuram Raju Thombare

[permalink] [raw]
Subject: [PATCH v1 0/3] I3C mastership handover support

Hi,

This patch series is to enable mastership handover feature in I3C
master subsystem and Cadence's I3C controller driver.


[PATCH 1/3]
i3c: master: split bus_init callback into bus_init and master_set_info
There are 2 reasons for this split
Currently bus_init callback is involved in
a. Controller specific settings such as clock prescalar, enabling
different functionalities and finally enabling the controller.
b. Allocating address to the main master and calling
i3c_master_set_info, which basically create a I3C device for master
and add it to system. This is fine for main master, but for
secondary master this should be deferred until controller actually
owns the bus/mastership.

Another reason is, to support secondary master initialization without
board info, controller specific bus mode setting need to be done twice
First with pure bus mode and second time when actual bus mode is known
based on data received through DEFSLVS, whereas master set info is
supposed to be done only once.

[PATCH 2/3]
i3c: add mastership handover support to i3c master subsystem
This patch add mastership handover support as per MIPI I3C
spec v1.0. Main master and secondary masters starts in pure
bus mode to allow enumeration (DAA) to happen in same bus mode.
Secondary masters are not required to have information about
other devices connected on the bus through board info, this
information is derived from DEFSLVS received from main
master. While acquiring mastership, requesting master always
make sure that it has active dynamic address, and received
DEFSLVS at least once. Mastership request state machine
make sure that any pending DEFSLVS is processed, so that
when device become master it always have correct view
of the bus.

[PATCH 3/3]
i3c: master: add mastership handover support to cdns i3c master driver
This patch adds mastership handover support to the Cadence
I3C controller driver. Basically, this include necessary
callbacks for mastership request.

Regards,
Parshuram Thombare

Parshuram Thombare (3):
i3c: master: split bus_init callback into bus_init and master_set_info
i3c: add mastership handover support to i3c master subsystem
i3c: master: add mastership handover support to cdns i3c master driver

drivers/i3c/master.c | 490 ++++++++++++++++++++++++---
drivers/i3c/master/dw-i3c-master.c | 29 +-
drivers/i3c/master/i3c-master-cdns.c | 385 ++++++++++++++++++---
include/linux/i3c/master.h | 47 ++-
4 files changed, 854 insertions(+), 97 deletions(-)

--
2.17.1


2020-04-08 10:23:35

by Boris Brezillon

[permalink] [raw]
Subject: Re: [PATCH v1 0/3] I3C mastership handover support

Hi Parshuram,

On Tue, 7 Apr 2020 00:20:45 +0200
Parshuram Thombare <[email protected]> wrote:

> Hi,
>
> This patch series is to enable mastership handover feature in I3C
> master subsystem and Cadence's I3C controller driver.

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).

Thanks,

Boris

>
>
> [PATCH 1/3]
> i3c: master: split bus_init callback into bus_init and master_set_info
> There are 2 reasons for this split
> Currently bus_init callback is involved in
> a. Controller specific settings such as clock prescalar, enabling
> different functionalities and finally enabling the controller.
> b. Allocating address to the main master and calling
> i3c_master_set_info, which basically create a I3C device for master
> and add it to system. This is fine for main master, but for
> secondary master this should be deferred until controller actually
> owns the bus/mastership.
>
> Another reason is, to support secondary master initialization without
> board info, controller specific bus mode setting need to be done twice
> First with pure bus mode and second time when actual bus mode is known
> based on data received through DEFSLVS, whereas master set info is
> supposed to be done only once.
>
> [PATCH 2/3]
> i3c: add mastership handover support to i3c master subsystem
> This patch add mastership handover support as per MIPI I3C
> spec v1.0. Main master and secondary masters starts in pure
> bus mode to allow enumeration (DAA) to happen in same bus mode.
> Secondary masters are not required to have information about
> other devices connected on the bus through board info, this
> information is derived from DEFSLVS received from main
> master. While acquiring mastership, requesting master always
> make sure that it has active dynamic address, and received
> DEFSLVS at least once. Mastership request state machine
> make sure that any pending DEFSLVS is processed, so that
> when device become master it always have correct view
> of the bus.
>
> [PATCH 3/3]
> i3c: master: add mastership handover support to cdns i3c master driver
> This patch adds mastership handover support to the Cadence
> I3C controller driver. Basically, this include necessary
> callbacks for mastership request.
>
> Regards,
> Parshuram Thombare
>
> Parshuram Thombare (3):
> i3c: master: split bus_init callback into bus_init and master_set_info
> i3c: add mastership handover support to i3c master subsystem
> i3c: master: add mastership handover support to cdns i3c master driver
>
> drivers/i3c/master.c | 490 ++++++++++++++++++++++++---
> drivers/i3c/master/dw-i3c-master.c | 29 +-
> drivers/i3c/master/i3c-master-cdns.c | 385 ++++++++++++++++++---
> include/linux/i3c/master.h | 47 ++-
> 4 files changed, 854 insertions(+), 97 deletions(-)
>

2020-04-08 15:25:29

by Parshuram Raju Thombare

[permalink] [raw]
Subject: RE: [PATCH v1 0/3] I3C mastership handover support

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
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
functionality, multi lane support etc which requires additional
steps in handover procedure. This structure will help to extend
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
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
state machine make sure it has active dynamic address (this may
seems repetitive, but it is to handle case of RSTDAA CCC), and
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
In pure bus mode during enumeration (DAA), this is to avoid need
of sec. master having device information through device tree, and at
the same time allowing enumeration to happened successfully.
Both main master and sec master change bus mode once enumeration
is done.

Regards,
Parshuram Thombare