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: Mon, 25 Nov 2019 13:22:19 +0100 [thread overview]
Message-ID: <20191125132219.2e45d084@collabora.com> (raw)
In-Reply-To: <CH2PR12MB421667CED7F6A5FF0299E732AE4A0@CH2PR12MB4216.namprd12.prod.outlook.com>
On Mon, 25 Nov 2019 12:03:42 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> From: Przemyslaw Gaj <pgaj@cadence.com>
> Date: Mon, Nov 25, 2019 at 11:55:16
>
> > The 11/25/2019 11:42, Vitor Soares wrote:
> > >
> > > Hi Boris,
> > >
> > > From: Boris Brezillon <boris.brezillon@collabora.com>
> > > Date: Mon, Nov 25, 2019 at 11:34:52
> > >
> > > > On Mon, 25 Nov 2019 11:19:44 +0000
> > > > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> > > >
> > > > > > > > >
> > > > > > > > > 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.
> > > > > > >
> > > > > > > >
> > > > > > > > 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. The point is, at the end you can pick some parts of my sec
> > > > > > > master code and integrate in your solution.
> > > > > > >
> > > > > >
> > > > > > Can you point me to the version of the patch your changes are based on?
> > > > > > And also, can you tell me what issues you faced? I would like to check
> > > > > > if they are already adressed in my code.
> > > > >
> > > > > I used v3 and v4. From v5, I found useful the switch case (request,
> > > > > deliver, handoff, takeover) in hc side.
> > > > >
> > > > > I didn't hardly test how device.c request mastership but I suspect it
> > > > > won't work properly. When you do i3c_dev_do_priv_xfers_locked() you might
> > > > > not be the master yet.
> > > >
> > > > I'm pretty sure we solved that already (that's what
> > > > i3c_master_acquire_bus_ownership() calls are supposed to take care of).
> > > > Can you be a bit more specific? What makes you think the master might
> > > > not be in control of the bus when i3c_dev_do_priv_xfers_locked() is
> > > > called?
> > >
> > > You are assuming that after i3c_master_acquire_bus_ownership() return,
> > > secondary master already owns the bus. Main master can ack the MR request
> > > and not send the CETACCMST immediately.
> > >
> >
> > In Cadence HC driver, I'm waiting for GETACCMST longer, polling the
> > status and after I exit from ->request_mastership(), I'm the bus owner.
> > If not, error exit code is returned and we can't make the transfers.
> > Are you able to implement the same behavior?
>
> You can assume everyone will do in that way. What happen if you receive a
> request or an information from current master?
We have this ->request_mastership() method so controllers that have
this logic (MR+wait(GETACCMST) automated can still interface with the
subsystem. If your controller handles the MR/GETACCMST separately, it
shouldn't be hard to implement, and we can even provide an helper if
people end up duplicating the code.
_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2019-11-25 12:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 9:33 I3C Mastership RFC 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
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 [this message]
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 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=20191125132219.2e45d084@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.