Re: I3C Mastership RFC

Boris Brezillon
2019-11-14T14:50:24Z

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.