From: Boris Brezillon <boris.brezillon@collabora.com>
To: Parshuram Thombare <pthombar@cadence.com>
Cc: <bbrezillon@kernel.org>, <vitor.soares@synopsys.com>,
mparab@cadence.com, pgaj@cadence.com,
linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/3] I3C mastership handover support
Date: Wed, 8 Apr 2020 12:04:18 +0200 [thread overview]
Message-ID: <20200408120418.0d5235a6@collabora.com> (raw)
In-Reply-To: <1586211645-8065-1-git-send-email-pthombar@cadence.com>
Hi Parshuram,
On Tue, 7 Apr 2020 00:20:45 +0200
Parshuram Thombare <pthombar@cadence.com> 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(-)
>
next prev parent reply other threads:[~2020-04-08 10:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 22:20 [PATCH v1 0/3] I3C mastership handover support Parshuram Thombare
2020-04-06 22:21 ` [PATCH v1 1/3] i3c: master: split bus_init callback into bus_init and master_set_info Parshuram Thombare
2020-04-06 22:21 ` [PATCH v1 2/3] i3c: add mastership handover support to i3c master subsystem Parshuram Thombare
2020-04-06 22:21 ` [PATCH v1 3/3] i3c: master: add mastership handover support to cdns i3c master driver Parshuram Thombare
2020-04-08 10:04 ` Boris Brezillon [this message]
2020-04-08 15:06 ` [PATCH v1 0/3] I3C mastership handover support Parshuram Raju Thombare
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=20200408120418.0d5235a6@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=bbrezillon@kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mparab@cadence.com \
--cc=pgaj@cadence.com \
--cc=pthombar@cadence.com \
--cc=vitor.soares@synopsys.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