Linux-i3c Archive on lore.kernel.org
 help / color / Atom feed
* I3C Mastership RFC
@ 2019-11-06  9:33 Przemyslaw Gaj
  2019-11-10 10:30 ` Boris Brezillon
  0 siblings, 1 reply; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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
  1 sibling, 1 reply; 11+ 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] 11+ 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
  0 siblings, 1 reply; 11+ 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] 11+ 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; 11+ 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] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ 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

Linux-i3c Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-i3c/0 linux-i3c/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-i3c linux-i3c/ https://lore.kernel.org/linux-i3c \
		linux-i3c@lists.infradead.org
	public-inbox-index linux-i3c

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-i3c


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git