linux-i3c.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* I3C Mastership RFC
@ 2019-11-06  9:33 Przemyslaw Gaj
  2019-11-10 10:30 ` Boris Brezillon
  0 siblings, 1 reply; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-06  9:33 UTC (permalink / raw)
  To: Vitor.Soares; +Cc: linux-i3c, bbrezillon

Hi Vitor,

We discussed with Joao in Lyon that you are ready with mastership RFC.
The question is when do you think you are able to post this proposal.
Our customer needs that and is pushing hard. I would like also to run all
the tests in our complex configuration and check how does it work.

-- 
-- 
Regards,
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-06  9:33 I3C Mastership RFC Przemyslaw Gaj
@ 2019-11-10 10:30 ` Boris Brezillon
  2019-11-11 12:30   ` Vitor Soares
  0 siblings, 1 reply; 27+ messages in thread
From: Boris Brezillon @ 2019-11-10 10:30 UTC (permalink / raw)
  To: Przemyslaw Gaj; +Cc: linux-i3c, bbrezillon, Vitor.Soares

Hi Przemek,

On Wed, 6 Nov 2019 10:33:16 +0100
Przemyslaw Gaj <pgaj@cadence.com> wrote:

> Hi Vitor,
> 
> We discussed with Joao in Lyon that you are ready with mastership RFC.
> The question is when do you think you are able to post this proposal.
> Our customer needs that and is pushing hard. I would like also to run all
> the tests in our complex configuration and check how does it work.

If you need this feature, I'd recommend that you lead the discussion
(as you did so far) and post a new version. Maybe try to address some of
the concerns raised by Vitor along the way. I know that you were in
favor of getting back to one of the previous iteration (discussed
during ELCE), so please go ahead and do what you think is the more
appropriate.

As part of this work, I'd like you to look at how mastership handover
is handled in HCI. I'm not asking you to implement an HCI driver, but
having an idea of what would be done in each of the new hooks would be
good (and maybe describing that in the cover letter).

Thanks,

Boris

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-10 10:30 ` Boris Brezillon
@ 2019-11-11 12:30   ` Vitor Soares
  2019-11-12  7:41     ` Boris Brezillon
  0 siblings, 1 reply; 27+ messages in thread
From: Vitor Soares @ 2019-11-11 12:30 UTC (permalink / raw)
  To: Boris Brezillon, Przemyslaw Gaj; +Cc: linux-i3c, bbrezillon, Vitor.Soares

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.

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.

Regarding the current approach (at least last Patch series and what I 
did) I still don't know if it is the best solution.
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. At least for me it seems to be more modular and 
ease to expand.

From: Boris Brezillon <boris.brezillon@collabora.com>
Date: Sun, Nov 10, 2019 at 10:30:05

> Hi Przemek,
> 
> On Wed, 6 Nov 2019 10:33:16 +0100
> Przemyslaw Gaj <pgaj@cadence.com> wrote:
> 
> > Hi Vitor,
> > 
> > We discussed with Joao in Lyon that you are ready with mastership RFC.
> > The question is when do you think you are able to post this proposal.
> > Our customer needs that and is pushing hard. I would like also to run all
> > the tests in our complex configuration and check how does it work.
>
> If you need this feature, I'd recommend that you lead the discussion
> (as you did so far) and post a new version. Maybe try to address some of
> the concerns raised by Vitor along the way. I know that you were in
> favor of getting back to one of the previous iteration (discussed
> during ELCE), so please go ahead and do what you think is the more
> appropriate.

I will try to put everything together and send a version so you can take 
a look.

> 
> As part of this work, I'd like you to look at how mastership handover
> is handled in HCI. I'm not asking you to implement an HCI driver, but
> having an idea of what would be done in each of the new hooks would be
> good (and maybe describing that in the cover letter).

We may need another call back for "deliver mastership" because the way 
how controllers do request/deliver may differ.

> 
> Thanks,
> 
> Boris

Apart of all this it necessary to think how request/deliver will take 
place in a functionally system.
  - main master just deliver the ownership to secondary master and expect 
it take care of the bus.
  - secondary master request the ownership and automatically send back 
the ownership to the main master.
  - give a time window in which each master can own the bus.

All this are topics that I'm going discussing with people that are 
working with i3c.

Best regards,
Vitor Soares


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-11 12:30   ` Vitor Soares
@ 2019-11-12  7:41     ` Boris Brezillon
  2019-11-14  6:10       ` Przemyslaw Gaj
  0 siblings, 1 reply; 27+ messages in thread
From: Boris Brezillon @ 2019-11-12  7:41 UTC (permalink / raw)
  To: Vitor Soares, linux-i3c; +Cc: Przemyslaw Gaj, bbrezillon

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?

> 
> 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?

> 
> 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

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-12  7:41     ` Boris Brezillon
@ 2019-11-14  6:10       ` Przemyslaw Gaj
  2019-11-14 11:56         ` Vitor Soares
  0 siblings, 1 reply; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-14  6:10 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: linux-i3c, bbrezillon, Vitor Soares

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-14  6:10       ` Przemyslaw Gaj
@ 2019-11-14 11:56         ` Vitor Soares
  2019-11-14 12:32           ` Boris Brezillon
  0 siblings, 1 reply; 27+ messages in thread
From: Vitor Soares @ 2019-11-14 11:56 UTC (permalink / raw)
  To: Przemyslaw Gaj, Boris Brezillon; +Cc: linux-i3c, bbrezillon, Vitor Soares

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.

I based in all version and tried to pass everything to master.c file.
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.

Best regards,
Vitor Soares


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  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
  0 siblings, 2 replies; 27+ messages in thread
From: Boris Brezillon @ 2019-11-14 12:32 UTC (permalink / raw)
  To: Vitor Soares; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

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 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.

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).

BTW, you mentioned working on a lot of different topics, but most of
them were left unfinished (userspace i3cdev interface, I3C slave
framework/API, ...). Any plans to post RFCs on those aspects anytime
soon? I mean, there's plenty of topics to work on, and I'd really prefer
that each developer work on a different topic instead of duplicating the
effort...

Regards,

Boris

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-14 12:32           ` Boris Brezillon
@ 2019-11-14 12:59             ` Przemyslaw Gaj
  2019-11-14 14:17             ` Vitor Soares
  1 sibling, 0 replies; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-14 12:59 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: linux-i3c, bbrezillon, rafalc, Vitor Soares

Hi,

+Rafal

The 11/14/2019 13:32, Boris Brezillon wrote:
> 
> 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 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.
> 
> 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).

It depends when you are able to post it. If it's this or next week,
I'm ok. But otherwise, I have to start working on that now. I'm trying
to address your comments from my latest patch, having in mind HCI
implementation. As I said before, our customer is pushing. They have
boards with our hardware and they started using that. Please let me
know.

> 
> BTW, you mentioned working on a lot of different topics, but most of
> them were left unfinished (userspace i3cdev interface, I3C slave
> framework/API, ...). Any plans to post RFCs on those aspects anytime
> soon? I mean, there's plenty of topics to work on, and I'd really prefer
> that each developer work on a different topic instead of duplicating the
> effort...
> 
> Regards,
> 
> Boris

-- 
-- 
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  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-25  8:02               ` Przemyslaw Gaj
  1 sibling, 2 replies; 27+ messages in thread
From: Vitor Soares @ 2019-11-14 14:17 UTC (permalink / raw)
  To: Boris Brezillon, Vitor Soares; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

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.

> 
> > 
> > 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.

As I said previous for I3C spec 1.1 secondary master received a big 
improvement due the misunderstanding published in 1.0 spec. 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.

> 
> 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).

> Any plans to post RFCs on those aspects anytime
> soon? I mean, there's plenty of topics to work on, and I'd really prefer
> that each developer work on a different topic instead of duplicating the
> effort...
> 
> Regards,
> 
> Boris

Best regards,
Vitor Soares



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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  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
  1 sibling, 1 reply; 27+ messages in thread
From: Boris Brezillon @ 2019-11-14 14:50 UTC (permalink / raw)
  To: Vitor Soares; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-14 14:50               ` Boris Brezillon
@ 2019-11-14 20:15                 ` Przemyslaw Gaj
  0 siblings, 0 replies; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-14 20:15 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: linux-i3c, bbrezillon, Vitor Soares

The 11/14/2019 15:50, Boris Brezillon wrote:
> 
> 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.
> 

Yes, that's how my patch series works. When device wants to transfer
data, mastership is requested automatically.

> > 
> > > 
> > > 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.

-- 
-- 
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-14 14:17             ` Vitor Soares
  2019-11-14 14:50               ` Boris Brezillon
@ 2019-11-25  8:02               ` Przemyslaw Gaj
  2019-11-25 11:19                 ` Vitor Soares
  1 sibling, 1 reply; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-25  8:02 UTC (permalink / raw)
  To: Vitor Soares; +Cc: linux-i3c, Boris Brezillon, bbrezillon

Hi Vitor,

I don't want to bother you but I have to start working on that ASAP. I
hope you understand. Can you answer few questions?

The 11/14/2019 14:17, Vitor Soares 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.
> 

What is the status of that?

> > 
> > > 
> > > 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.

> As I said previous for I3C spec 1.1 secondary master received a big 
> improvement due the misunderstanding published in 1.0 spec. 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.
> 
> > 
> > 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).
> 
> > Any plans to post RFCs on those aspects anytime
> > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > that each developer work on a different topic instead of duplicating the
> > effort...
> > 
> > Regards,
> > 
> > Boris
> 
> Best regards,
> Vitor Soares
> 
> 

-- 
-- 
Regards,
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-25  8:02               ` Przemyslaw Gaj
@ 2019-11-25 11:19                 ` Vitor Soares
  2019-11-25 11:34                   ` Boris Brezillon
  0 siblings, 1 reply; 27+ messages in thread
From: Vitor Soares @ 2019-11-25 11:19 UTC (permalink / raw)
  To: Przemyslaw Gaj; +Cc: linux-i3c, Boris Brezillon, bbrezillon

Hi,

From: Przemyslaw Gaj <pgaj@cadence.com>
Date: Mon, Nov 25, 2019 at 08:02:22

> Hi Vitor,
> 
> I don't want to bother you but I have to start working on that ASAP. I
> hope you understand. Can you answer few questions?

Sorry I'm already working on it but I'm a bit delayed.

> 
> The 11/14/2019 14:17, Vitor Soares 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.
> > 
> 
> What is the status of that?

I found an issue in secondary master init flow on my side.

> 
> > > 
> > > > 
> > > > 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.

> 
> > As I said previous for I3C spec 1.1 secondary master received a big 
> > improvement due the misunderstanding published in 1.0 spec. 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.
> > 
> > > 
> > > 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).
> > 
> > > Any plans to post RFCs on those aspects anytime
> > > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > > that each developer work on a different topic instead of duplicating the
> > > effort...
> > > 
> > > Regards,
> > > 
> > > Boris
> > 
> > Best regards,
> > Vitor Soares
> > 
> > 
> 
> -- 
> -- 
> Regards,
> Przemyslaw Gaj

Again sorry for the delay. I will try to send this soon.

Best regards,
Vitor Soares

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  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:50                     ` Przemyslaw Gaj
  0 siblings, 2 replies; 27+ messages in thread
From: Boris Brezillon @ 2019-11-25 11:34 UTC (permalink / raw)
  To: Vitor Soares; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

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?

> 
> >   
> > > As I said previous for I3C spec 1.1 secondary master received a big 
> > > improvement due the misunderstanding published in 1.0 spec. 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.
> > >   
> > > > 
> > > > 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).
> > >   
> > > > Any plans to post RFCs on those aspects anytime
> > > > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > > > that each developer work on a different topic instead of duplicating the
> > > > effort...
> > > > 
> > > > Regards,
> > > > 
> > > > Boris  
> > > 
> > > Best regards,
> > > Vitor Soares
> > > 
> > >   
> > 
> > -- 
> > -- 
> > Regards,
> > Przemyslaw Gaj  
> 
> Again sorry for the delay. I will try to send this soon.

Can you please share what you have now (even if it's not finished) so
Przemek can start looking at it?

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-25 11:34                   ` Boris Brezillon
@ 2019-11-25 11:42                     ` Vitor Soares
  2019-11-25 11:55                       ` Przemyslaw Gaj
  2019-11-25 11:50                     ` Przemyslaw Gaj
  1 sibling, 1 reply; 27+ messages in thread
From: Vitor Soares @ 2019-11-25 11:42 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

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.

I was thinking to delay i3c_dev_do_priv_xfers_locked() with a work delay 
or so. Do you have any idea?

> 
> > 
> > >   
> > > > As I said previous for I3C spec 1.1 secondary master received a big 
> > > > improvement due the misunderstanding published in 1.0 spec. 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.
> > > >   
> > > > > 
> > > > > 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).
> > > >   
> > > > > Any plans to post RFCs on those aspects anytime
> > > > > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > > > > that each developer work on a different topic instead of duplicating the
> > > > > effort...
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Boris  
> > > > 
> > > > Best regards,
> > > > Vitor Soares
> > > > 
> > > >   
> > > 
> > > -- 
> > > -- 
> > > Regards,
> > > Przemyslaw Gaj  
> > 
> > Again sorry for the delay. I will try to send this soon.
> 
> Can you please share what you have now (even if it's not finished) so
> Przemek can start looking at it?

I will try today.

Best regads,
Vitor Soares


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-25 11:34                   ` Boris Brezillon
  2019-11-25 11:42                     ` Vitor Soares
@ 2019-11-25 11:50                     ` Przemyslaw Gaj
  1 sibling, 0 replies; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-25 11:50 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: linux-i3c, bbrezillon, Vitor Soares

The 11/25/2019 12:34, Boris Brezillon wrote:
> 
> 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?
> 

That's it. We solved that already and I remember Vitor mentioned about
that during patchset review.

What about your ->request_mastership() implementation? Does it ensure
you are the owner of the bus when you return from that function?

> > 
> > >   
> > > > As I said previous for I3C spec 1.1 secondary master received a big 
> > > > improvement due the misunderstanding published in 1.0 spec. 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.
> > > >   
> > > > > 
> > > > > 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).
> > > >   
> > > > > Any plans to post RFCs on those aspects anytime
> > > > > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > > > > that each developer work on a different topic instead of duplicating the
> > > > > effort...
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Boris  
> > > > 
> > > > Best regards,
> > > > Vitor Soares
> > > > 
> > > >   
> > > 
> > > -- 
> > > -- 
> > > Regards,
> > > Przemyslaw Gaj  
> > 
> > Again sorry for the delay. I will try to send this soon.
> 
> Can you please share what you have now (even if it's not finished) so
> Przemek can start looking at it?

Yeah, would be great.

-- 
-- 
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-25 11:42                     ` Vitor Soares
@ 2019-11-25 11:55                       ` Przemyslaw Gaj
  2019-11-25 12:03                         ` Vitor Soares
  0 siblings, 1 reply; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-25 11:55 UTC (permalink / raw)
  To: Vitor Soares; +Cc: linux-i3c, Boris Brezillon, bbrezillon

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?
 
> I was thinking to delay i3c_dev_do_priv_xfers_locked() with a work delay 
> or so. Do you have any idea?
> 
> > 
> > > 
> > > >   
> > > > > As I said previous for I3C spec 1.1 secondary master received a big 
> > > > > improvement due the misunderstanding published in 1.0 spec. 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.
> > > > >   
> > > > > > 
> > > > > > 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).
> > > > >   
> > > > > > Any plans to post RFCs on those aspects anytime
> > > > > > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > > > > > that each developer work on a different topic instead of duplicating the
> > > > > > effort...
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > Boris  
> > > > > 
> > > > > Best regards,
> > > > > Vitor Soares
> > > > > 
> > > > >   
> > > > 
> > > > -- 
> > > > -- 
> > > > Regards,
> > > > Przemyslaw Gaj  
> > > 
> > > Again sorry for the delay. I will try to send this soon.
> > 
> > Can you please share what you have now (even if it's not finished) so
> > Przemek can start looking at it?
> 
> I will try today.
> 
> Best regads,
> Vitor Soares
> 

-- 
-- 
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-25 11:55                       ` Przemyslaw Gaj
@ 2019-11-25 12:03                         ` Vitor Soares
  2019-11-25 12:22                           ` Boris Brezillon
  2019-11-25 12:25                           ` Przemyslaw Gaj
  0 siblings, 2 replies; 27+ messages in thread
From: Vitor Soares @ 2019-11-25 12:03 UTC (permalink / raw)
  To: Przemyslaw Gaj; +Cc: linux-i3c, Boris Brezillon, bbrezillon

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?

>  
> > I was thinking to delay i3c_dev_do_priv_xfers_locked() with a work delay 
> > or so. Do you have any idea?
> > 
> > > 
> > > > 
> > > > >   
> > > > > > As I said previous for I3C spec 1.1 secondary master received a big 
> > > > > > improvement due the misunderstanding published in 1.0 spec. 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.
> > > > > >   
> > > > > > > 
> > > > > > > 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).
> > > > > >   
> > > > > > > Any plans to post RFCs on those aspects anytime
> > > > > > > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > > > > > > that each developer work on a different topic instead of duplicating the
> > > > > > > effort...
> > > > > > > 
> > > > > > > Regards,
> > > > > > > 
> > > > > > > Boris  
> > > > > > 
> > > > > > Best regards,
> > > > > > Vitor Soares
> > > > > > 
> > > > > >   
> > > > > 
> > > > > -- 
> > > > > -- 
> > > > > Regards,
> > > > > Przemyslaw Gaj  
> > > > 
> > > > Again sorry for the delay. I will try to send this soon.
> > > 
> > > Can you please share what you have now (even if it's not finished) so
> > > Przemek can start looking at it?
> > 
> > I will try today.
> > 
> > Best regads,
> > Vitor Soares
> > 
> 
> -- 
> -- 
> Przemyslaw Gaj

Best regards,
Vitor Soares
_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-25 12:03                         ` Vitor Soares
@ 2019-11-25 12:22                           ` Boris Brezillon
  2019-11-25 13:00                             ` Vitor Soares
  2019-11-25 12:25                           ` Przemyslaw Gaj
  1 sibling, 1 reply; 27+ messages in thread
From: Boris Brezillon @ 2019-11-25 12:22 UTC (permalink / raw)
  To: Vitor Soares; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-25 12:03                         ` Vitor Soares
  2019-11-25 12:22                           ` Boris Brezillon
@ 2019-11-25 12:25                           ` Przemyslaw Gaj
  2019-11-25 12:56                             ` Vitor Soares
  1 sibling, 1 reply; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-25 12:25 UTC (permalink / raw)
  To: Vitor Soares; +Cc: linux-i3c, Boris Brezillon, bbrezillon

The 11/25/2019 12:03, Vitor Soares 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?

1. By default, my HC driver rejects incoming GETACCMST, just nacks that.
When I want to request mastership, I'm enabling that using MST_ACK and
secondary master starts acking GETACCMST. I can extend that easily if
needed to ack GETACCMST by default. Just need to handle one more irq.

2. What kind of information? DEFSLVS?

> 
> >  
> > > I was thinking to delay i3c_dev_do_priv_xfers_locked() with a work delay 
> > > or so. Do you have any idea?
> > > 
> > > > 
> > > > > 
> > > > > >   
> > > > > > > As I said previous for I3C spec 1.1 secondary master received a big 
> > > > > > > improvement due the misunderstanding published in 1.0 spec. 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.
> > > > > > >   
> > > > > > > > 
> > > > > > > > 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).
> > > > > > >   
> > > > > > > > Any plans to post RFCs on those aspects anytime
> > > > > > > > soon? I mean, there's plenty of topics to work on, and I'd really prefer
> > > > > > > > that each developer work on a different topic instead of duplicating the
> > > > > > > > effort...
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > 
> > > > > > > > Boris  
> > > > > > > 
> > > > > > > Best regards,
> > > > > > > Vitor Soares
> > > > > > > 
> > > > > > >   
> > > > > > 
> > > > > > -- 
> > > > > > -- 
> > > > > > Regards,
> > > > > > Przemyslaw Gaj  
> > > > > 
> > > > > Again sorry for the delay. I will try to send this soon.
> > > > 
> > > > Can you please share what you have now (even if it's not finished) so
> > > > Przemek can start looking at it?
> > > 
> > > I will try today.
> > > 
> > > Best regads,
> > > Vitor Soares
> > > 
> > 
> > -- 
> > -- 
> > Przemyslaw Gaj
> 
> Best regards,
> Vitor Soares

-- 
-- 
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-25 12:25                           ` Przemyslaw Gaj
@ 2019-11-25 12:56                             ` Vitor Soares
  0 siblings, 0 replies; 27+ messages in thread
From: Vitor Soares @ 2019-11-25 12:56 UTC (permalink / raw)
  To: Przemyslaw Gaj; +Cc: linux-i3c, Boris Brezillon, bbrezillon

From: Przemyslaw Gaj <pgaj@cadence.com>
Date: Mon, Nov 25, 2019 at 12:25:23

> The 11/25/2019 12:03, Vitor Soares 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?
> 
> 1. By default, my HC driver rejects incoming GETACCMST, just nacks that.
> When I want to request mastership, I'm enabling that using MST_ACK and

As I comment  in one of your patch, we need a method as for ibi to enable 
MR for a particular device.
It something that I don't have for now. 

> secondary master starts acking GETACCMST. I can extend that easily if
> needed to ack GETACCMST by default. Just need to handle one more irq.

This is not the case. My understanding is that:

Secondary master do MR request them is polling for a GETACCMST,  am I 
right?

> 
> 2. What kind of information? DEFSLVS?

DEFSLVS, GETSTATUS or other possible CCC.


Best regards,
Vitor Soares



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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-25 12:22                           ` Boris Brezillon
@ 2019-11-25 13:00                             ` Vitor Soares
  2019-11-25 13:09                               ` Boris Brezillon
  0 siblings, 1 reply; 27+ messages in thread
From: Vitor Soares @ 2019-11-25 13:00 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

Hi,

From: Boris Brezillon <boris.brezillon@collabora.com>
Date: Mon, Nov 25, 2019 at 12:22:19

> 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. 

I can also poll the GETACCMST but we are assuming nothing will happen 
between MR and GETACCMST.

> 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.

I already implement a callback in my code so each controller be able to 
do their stuff in that in request/deliver mastership.

Best regards,
Vitor Soares


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-25 13:00                             ` Vitor Soares
@ 2019-11-25 13:09                               ` Boris Brezillon
  2019-11-25 14:27                                 ` Vitor Soares
  0 siblings, 1 reply; 27+ messages in thread
From: Boris Brezillon @ 2019-11-25 13:09 UTC (permalink / raw)
  To: Vitor Soares; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

On Mon, 25 Nov 2019 13:00:17 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:

> > > > > > 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.   
> 
> I can also poll the GETACCMST but we are assuming nothing will happen 
> between MR and GETACCMST.

Nothing coming from the master that tries to acquire the bus, yes.
Nothing coming from the current master, no, and that shouldn't be a
problem as long as those operations don't involve acquiring bus->lock.
And if some of those operation involve acquiring the lock (I'd still
need to understand which operation that would be) they'll just be
delayed/rejected.

> 
> > 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.  
> 
> I already implement a callback in my code so each controller be able to 
> do their stuff in that in request/deliver mastership.

Can you share some details here? What would those callbacks supposed to
do and when would they be called?

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  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
  0 siblings, 2 replies; 27+ messages in thread
From: Vitor Soares @ 2019-11-25 14:27 UTC (permalink / raw)
  To: Boris Brezillon; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

From: Boris Brezillon <boris.brezillon@collabora.com>
Date: Mon, Nov 25, 2019 at 13:09:36

> On Mon, 25 Nov 2019 13:00:17 +0000
> Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> 
> > > > > > > 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.   
> > 
> > I can also poll the GETACCMST but we are assuming nothing will happen 
> > between MR and GETACCMST.
> 
> Nothing coming from the master that tries to acquire the bus, yes.
> Nothing coming from the current master, no, and that shouldn't be a
> problem as long as those operations don't involve acquiring bus->lock.
> And if some of those operation involve acquiring the lock (I'd still
> need to understand which operation that would be) they'll just be
> delayed/rejected.

You are assuming this is straight forward which is not the case. Between 
MR and GETACCMST may happen everything as in a Master-Slave topology.
For me, poll the controller to check when GETACCMST arrive and lock 
everything is not a solution.

> 
> > 
> > > 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.  
> > 
> > I already implement a callback in my code so each controller be able to 
> > do their stuff in that in request/deliver mastership.
> 
> Can you share some details here? What would those callbacks supposed to
> do and when would they be called?

My understanding is that different controllers may have different ways to 
deliver the bus ownership hence I implemented that.

Best regards,
Vitor Soares

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  2019-11-25 14:27                                 ` Vitor Soares
@ 2019-11-25 14:50                                   ` Boris Brezillon
  2019-11-25 14:59                                   ` Przemyslaw Gaj
  1 sibling, 0 replies; 27+ messages in thread
From: Boris Brezillon @ 2019-11-25 14:50 UTC (permalink / raw)
  To: Vitor Soares; +Cc: Przemyslaw Gaj, linux-i3c, bbrezillon

On Mon, 25 Nov 2019 14:27:18 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:

> From: Boris Brezillon <boris.brezillon@collabora.com>
> Date: Mon, Nov 25, 2019 at 13:09:36
> 
> > On Mon, 25 Nov 2019 13:00:17 +0000
> > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> >   
> > > > > > > > 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.     
> > > 
> > > I can also poll the GETACCMST but we are assuming nothing will happen 
> > > between MR and GETACCMST.  
> > 
> > Nothing coming from the master that tries to acquire the bus, yes.
> > Nothing coming from the current master, no, and that shouldn't be a
> > problem as long as those operations don't involve acquiring bus->lock.
> > And if some of those operation involve acquiring the lock (I'd still
> > need to understand which operation that would be) they'll just be
> > delayed/rejected.  
> 
> You are assuming this is straight forward which is not the case. Between 
> MR and GETACCMST may happen everything as in a Master-Slave topology.

Like what? Be more specific, I want real examples that don't work
because of the way mastership handover is done in Przemek's proposal.

> For me, poll the controller to check when GETACCMST arrive and lock 
> everything is not a solution.

We don't lock everything: other devs can still communicate until we've
acquired the bus, and the slave end of your master should also work
(since the master is still not acting as a master yet).
We do prevent new MR request once we've acquired the bus to avoid
situations where another master requests bus ownership before we could
send the messages we were asked to send (device driver request). But
that's a completely orthogonal thing, and has nothing to do with the
polling solution you seem to complain about.
BTW, you don't have to poll the reg value, using interrupt-based
waiting is fine too. My point is, if we want to keep the code simple,
we have to make this operation synchronous from the caller PoV.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: I3C Mastership RFC
  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
  1 sibling, 1 reply; 27+ messages in thread
From: Przemyslaw Gaj @ 2019-11-25 14:59 UTC (permalink / raw)
  To: Vitor Soares; +Cc: linux-i3c, Boris Brezillon, bbrezillon

The 11/25/2019 14:27, Vitor Soares wrote:
> 
> From: Boris Brezillon <boris.brezillon@collabora.com>
> Date: Mon, Nov 25, 2019 at 13:09:36
> 
> > On Mon, 25 Nov 2019 13:00:17 +0000
> > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> > 
> > > > > > > > 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.   
> > > 
> > > I can also poll the GETACCMST but we are assuming nothing will happen 
> > > between MR and GETACCMST.
> > 
> > Nothing coming from the master that tries to acquire the bus, yes.
> > Nothing coming from the current master, no, and that shouldn't be a
> > problem as long as those operations don't involve acquiring bus->lock.
> > And if some of those operation involve acquiring the lock (I'd still
> > need to understand which operation that would be) they'll just be
> > delayed/rejected.
> 
> You are assuming this is straight forward which is not the case. Between 
> MR and GETACCMST may happen everything as in a Master-Slave topology.
> For me, poll the controller to check when GETACCMST arrive and lock 
> everything is not a solution.
> 

I understand your point. I'm sure that one of my patchset supported
your use case. I introduced the function which lets the subsystem
takeover the bus. Even when we receive GETACCMST without requesting
mastership. I assume you are trying do the same thing now.

The only thing I remember when you reviewed my patch, you wanted to pass
device list to that function.

> > 
> > > 
> > > > 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.  
> > > 
> > > I already implement a callback in my code so each controller be able to 
> > > do their stuff in that in request/deliver mastership.
> > 
> > Can you share some details here? What would those callbacks supposed to
> > do and when would they be called?
> 
> My understanding is that different controllers may have different ways to 
> deliver the bus ownership hence I implemented that.
> 
> Best regards,
> Vitor Soares

-- 
-- 
Przemyslaw Gaj

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* RE: I3C Mastership RFC
  2019-11-25 14:59                                   ` Przemyslaw Gaj
@ 2019-11-25 15:22                                     ` Vitor Soares
  0 siblings, 0 replies; 27+ messages in thread
From: Vitor Soares @ 2019-11-25 15:22 UTC (permalink / raw)
  To: Przemyslaw Gaj; +Cc: linux-i3c, Boris Brezillon, bbrezillon

From: Przemyslaw Gaj <pgaj@cadence.com>
Date: Mon, Nov 25, 2019 at 14:59:26

> The 11/25/2019 14:27, Vitor Soares wrote:
> > 
> > From: Boris Brezillon <boris.brezillon@collabora.com>
> > Date: Mon, Nov 25, 2019 at 13:09:36
> > 
> > > On Mon, 25 Nov 2019 13:00:17 +0000
> > > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> > > 
> > > > > > > > > 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.   
> > > > 
> > > > I can also poll the GETACCMST but we are assuming nothing will happen 
> > > > between MR and GETACCMST.
> > > 
> > > Nothing coming from the master that tries to acquire the bus, yes.
> > > Nothing coming from the current master, no, and that shouldn't be a
> > > problem as long as those operations don't involve acquiring bus->lock.
> > > And if some of those operation involve acquiring the lock (I'd still
> > > need to understand which operation that would be) they'll just be
> > > delayed/rejected.
> > 
> > You are assuming this is straight forward which is not the case. Between 
> > MR and GETACCMST may happen everything as in a Master-Slave topology.
> > For me, poll the controller to check when GETACCMST arrive and lock 
> > everything is not a solution.
> > 
> 
> I understand your point. I'm sure that one of my patchset supported
> your use case. I introduced the function which lets the subsystem
> takeover the bus. Even when we receive GETACCMST without requesting
> mastership. I assume you are trying do the same thing now.
> 
> The only thing I remember when you reviewed my patch, you wanted to pass
> device list to that function.
> 

That is not my concern. That is working fine in my side.
Please check spec 1.1 and see if what you are implementing fits on it.

> > > 
> > > > 
> > > > > 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.  
> > > > 
> > > > I already implement a callback in my code so each controller be able to 
> > > > do their stuff in that in request/deliver mastership.
> > > 
> > > Can you share some details here? What would those callbacks supposed to
> > > do and when would they be called?
> > 
> > My understanding is that different controllers may have different ways to 
> > deliver the bus ownership hence I implemented that.
> > 
> > Best regards,
> > Vitor Soares
> 
> -- 
> -- 
> Przemyslaw Gaj


Best regards,
Vitor Soares

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2019-11-25 15:29 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).