Linux-i3c Archive on lore.kernel.org
 help / color / Atom feed
From: Przemyslaw Gaj <pgaj@cadence.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	"bbrezillon@kernel.org" <bbrezillon@kernel.org>,
	Vitor Soares <Vitor.Soares@synopsys.com>
Subject: Re: I3C Mastership RFC
Date: Thu, 14 Nov 2019 07:10:12 +0100
Message-ID: <20191114061011.GA25288@global.cadence.com> (raw)
In-Reply-To: <20191112084127.6efc6fac@collabora.com>

Hi Vitor,

The 11/12/2019 08:41, Boris Brezillon wrote:
> 
> Hi Vitor,
> 
> On Mon, 11 Nov 2019 12:30:45 +0000
> Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> 
> > Hi Boris and Przemek,
> > 
> > I have a working version for tests purposes. Yet, I have some basic TODOS 
> > to address during the takeover of the bus.
> 
> Okay. Would you mind sharing a branch with this material so Przemek and
> I can have a look at it?

So, Vitor, can you share your changes? Can you tell me what you had to
change to make it work? Also, which patch version is this based on?

> 
> > 
> > I don't know if you are aware but the secondary master feature 
> > description was improved for the spec v1.1 and it makes sense to take a 
> > look on that.
> 
> Unfortunately I don't have access to non-public specs, but I guess
> Przemek has access to it. Any specific details you want to share
> regarding secondary master/mastership handover in v1.1?

Yes, that's it. Regarding secondary master features, the description is
improved, mostly clarified IMO.

> 
> > 
> > Regarding the current approach (at least last Patch series and what I 
> > did) I still don't know if it is the best solution.
> 
> That's exactly what we're trying to sort out :-).
> 
> > I remember in the beginning of secondary master support I discuss with 
> > Boris about USB OTG vs I2C slave mode and now having a better 
> > understanding how USB OTG works I think we should address secondary 
> > master in a similar way.
> 
> I don't remember mentioning OTG. I did mention the USB gadget model
> which I thought was a good approach for the I3C slave feature, but
> AFAICT, OTG is quite different from the I3C mastership handover
> mechanism. Master/slave selection in OTG is based on a pin (ID pin
> IIRC), and AFAIR the device can't change role dynamically (it has to be
> unplugged). Can you be more specific about what you think should be
> taken from the OTG approach?
> 
> > At least for me it seems to be more modular and 
> > ease to expand.
> 
> I keep thinking we won't be able to address both things at the same
> time. As I said many times, I3C slave support sounds orthogonal to the
> I3C mastership handover bits. I know the master acts as a 'slave' when
> it doesn't own the bus, but it's a rather specific slave profile (at
> least if the secondary master only implements the master profile) where
> only MR events can be sent/received. I don't think we should expose it
> as an I3C slave (or gadget if we make an analogy with the USB subsystem)
> in that case.
> 
> Can we please focus on I3C mastership handover here, and put I3C slave
> support on the side. BTW, if you have a draft for the I3C slave
> framework, don't hesitate to post it, that's something we can review in
> parallel.
> 
> Regards,
> 
> Boris

-- 
--
Regards,
Przemek

_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06  9:33 Przemyslaw Gaj
2019-11-10 10:30 ` Boris Brezillon
2019-11-11 12:30   ` Vitor Soares
2019-11-12  7:41     ` Boris Brezillon
2019-11-14  6:10       ` Przemyslaw Gaj [this message]
2019-11-14 11:56         ` Vitor Soares
2019-11-14 12:32           ` Boris Brezillon
2019-11-14 12:59             ` Przemyslaw Gaj
2019-11-14 14:17             ` Vitor Soares
2019-11-14 14:50               ` Boris Brezillon
2019-11-14 20:15                 ` Przemyslaw Gaj
2019-11-25  8:02               ` Przemyslaw Gaj
2019-11-25 11:19                 ` Vitor Soares
2019-11-25 11:34                   ` Boris Brezillon
2019-11-25 11:42                     ` Vitor Soares
2019-11-25 11:55                       ` Przemyslaw Gaj
2019-11-25 12:03                         ` Vitor Soares
2019-11-25 12:22                           ` Boris Brezillon
2019-11-25 13:00                             ` Vitor Soares
2019-11-25 13:09                               ` Boris Brezillon
2019-11-25 14:27                                 ` Vitor Soares
2019-11-25 14:50                                   ` Boris Brezillon
2019-11-25 14:59                                   ` Przemyslaw Gaj
2019-11-25 15:22                                     ` Vitor Soares
2019-11-25 12:25                           ` Przemyslaw Gaj
2019-11-25 12:56                             ` Vitor Soares
2019-11-25 11:50                     ` Przemyslaw Gaj

Reply instructions:

You may reply publically 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=20191114061011.GA25288@global.cadence.com \
    --to=pgaj@cadence.com \
    --cc=Vitor.Soares@synopsys.com \
    --cc=bbrezillon@kernel.org \
    --cc=boris.brezillon@collabora.com \
    --cc=linux-i3c@lists.infradead.org \
    /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

Linux-i3c Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-i3c/0 linux-i3c/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-i3c linux-i3c/ https://lore.kernel.org/linux-i3c \
		linux-i3c@lists.infradead.org
	public-inbox-index linux-i3c

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-i3c


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git