Linux-i3c Archive on lore.kernel.org
 help / color / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vitor Soares <Vitor.Soares@synopsys.com>
Cc: Przemyslaw Gaj <pgaj@cadence.com>,
	"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	"bbrezillon@kernel.org" <bbrezillon@kernel.org>
Subject: Re: I3C Mastership RFC
Date: Thu, 14 Nov 2019 15:50:08 +0100
Message-ID: <20191114155008.6551459c@collabora.com> (raw)
In-Reply-To: <CH2PR12MB4216E136A2EBB0A2777C6212AE710@CH2PR12MB4216.namprd12.prod.outlook.com>

On Thu, 14 Nov 2019 14:17:38 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:

> From: Boris Brezillon <boris.brezillon@collabora.com>
> Date: Thu, Nov 14, 2019 at 12:32:14
> 
> > Hi Vitor,
> > 
> > On Thu, 14 Nov 2019 11:56:00 +0000
> > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> >   
> > > Hi,
> > > 
> > > From: Przemyslaw Gaj <pgaj@cadence.com>
> > > Date: Thu, Nov 14, 2019 at 06:10:12
> > >   
> > > > 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'm closing a task and after that I will prepare the RFC.  
> > 
> > Okay, can we have an estimate? Are we talking about days or weeks?  
> 
> I will prioritize it for next week.

Great!

> 
> >   
> > > 
> > > I based in all version and tried to pass everything to master.c file.  
> > 
> > I'm not sure what that means, but okay.
> >   
> > > Right now my challenge it to trigger mastership request when a device 
> > > driver want to access to the bus but I believe we can discuss that after.  
> > 
> > That's kind of a basic feature when talking about mastership handover,
> > but sure, we can discuss it after your RFC has been posted.  
> 
> I need to test if the time that device.c request the mastership and the 
> controller has effectively the ownership of the bus is short enough to 
> call i3c_dev_do_priv_xfers_locked(dev->desc, xfers, nxfers) before of all 
> housekeeping of bus takeover.

We sorted that out in Przemek series already. Please base your work on
what Przemek did (or at least look at it carefully), otherwise we're
going to re-do/re-review the same things we did a few months back.

> 
> > 
> > Note that I'm not super happy to have to go back to square 1 and throw
> > away all of the work done by Przemek, especially since Przemek was the
> > first one to post a patchset and he never really said he didn't
> > want or didn't have time to continue working on this task (not even
> > mentioning the time I spent reviewing those patches...).
> > 
> > If Przemek is fine with this situation I'm okay making an exception,
> > but be aware that it's not how we usually do: the person that posts a
> > patchset first leads the thing (of course, it's even better if there's
> > some kind of coordination before the patch is posted).  
> 
> Honestly it looks like I'm competing on this which is not the case.
> I just pointed out my concerns about this adoption because I see several 
> issues on it.

Couldn't these problems/limitations be addressed in the existing
implementation instead of re-implementing everything?

> The point is, at the end you can pick some parts of my sec 
> master code and integrate in your solution.

I wish you had tried to modify what Przemek started instead of starting
from scratch... Now someone will have to do the integration, but let's
move on. Please post an RFC (or a public branch) as soon as possible,
even if it's incomplete. It can even be something that doesn't compile.
The idea being to check what's missing/wrong in Przemek implementation
and see how we can merge the two.

> 
> As I said previous for I3C spec 1.1 secondary master received a big 
> improvement due the misunderstanding published in 1.0 spec.

Okay, I can't tell. Version 1.0 was already pretty clear to me with
regard to mastership handover.

> I don't know 
> any other protocol that implement such kind of feature and for this is 
> from far the most complex feature to implement in SO based systems from 
> i3c spec.

That's where the fun is, isn't it? :P

> 
> > 
> > BTW, you mentioned working on a lot of different topics, but most of
> > them were left unfinished (userspace i3cdev interface, I3C slave
> > framework/API, ...).  
> 
> The i3cdev does what we discuss during the proposal of i3c subsystem and 
> only expose i3c device without device driver yet I'm not happy with 
> transfer struct.
> For the tools I have for hdr and sdr transfers, for now I didn't feel the 
> need of a tool for ccc (but for testing purposes it would help a lot).

What about the I3C slave controller API/framework? Would be interesting
to have someone work on that topic, and you seemed to be worried about
how it would interact with masters that expose a real slave profile, so
looking at it would be a good starting point IMHO.

_______________________________________________
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
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 [this message]
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=20191114155008.6551459c@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=Vitor.Soares@synopsys.com \
    --cc=bbrezillon@kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=pgaj@cadence.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

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