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