Message-ID: <3D2681D9-1ACC-42FF-9FAB-D86B3C689003@cadence.com>
Date:   Thu, 30 Aug 2018 19:00:39 +0000
From:   Przemyslaw Gaj <pgaj@...ence.com>
To:     vitor <Vitor.Soares@...opsys.com>,
        Boris Brezillon <boris.brezillon@...tlin.com>
CC:     "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        Sekhar Nori <nsekhar@...com>, Wolfram Sang <wsa@...-dreams.de>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Przemyslaw Sroka <psroka@...ence.com>,
        Arkadiusz Golec <agolec@...ence.com>,
        Alan Douglas <adouglas@...ence.com>,
        Bartosz Folta <bfolta@...ence.com>,
        Damian Kos <dkos@...ence.com>,
        Alicja Jurasik-Urbaniak <alicja@...ence.com>,
        Cyprian Wronka <cwronka@...ence.com>,
        Suresh Punnoose <sureshp@...ence.com>,
        Rafal Ciepiela <rafalc@...ence.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Nishanth Menon <nm@...com>, Rob Herring <robh+dt@...nel.org>,
        Pawel Moll <pawel.moll@....com>,
        Mark Rutland <mark.rutland@....com>,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        Kumar Gala <galak@...eaurora.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Xiang Lin <Xiang.Lin@...aptics.com>,
        Peter Rosin <peda@...ntia.se>
Subject: Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure

Hi Vitor,

On 8/30/18, 3:57 PM, "vitor" <Vitor.Soares@...opsys.com> wrote:

    EXTERNAL MAIL
    
    
    Hi Przemyslaw
    
Just Przemek :)
    
    On 28-08-2018 13:55, Przemyslaw Gaj wrote:
    > Hi Vitor,
    >
    > I have already implemented Mastership request/handover but we are waiting for Boris’s patch to be accepted and merged. Anyway, my comments below.
    >
    > On 8/28/18, 2:02 PM, "Boris Brezillon" <boris.brezillon@...tlin.com> wrote:
    >
    >      EXTERNAL MAIL
    >      
    >      
    >      Hi Vitor,
    >      
    >      On Tue, 28 Aug 2018 12:50:12 +0100
    >      vitor <Vitor.Soares@...opsys.com> wrote:
    >      
    >      > Hi Boris,
    >      >
    >      > The DT Bindings say "The node describing an I3C bus should be named
    >      > i3c-master.". Do you have a field for secondary master?
    >
    > I think we don’t need separate field for secondary master. Main and secondary masters
    > support similar functionalities. It’s enough to have this state internally and do mastership it it's needed.
    
    Yes, you are right.
    
    >
    >      >
    >      > On 24-08-2018 19:16, Boris Brezillon wrote:
    >      > > Well, before even considering supporting secondary master registration,
    >      > > we need to handle mastership handover. As for the DAA operation, it's
    >      > > likely to be host specific, so we'll have to add a new hook to the
    >      > > i3c_master_controller_ops struct.
    >      > Do you mean when master try to delegate the bus ownership through
    >      > GETACCMST? or to get the bus ownership with IBI-MR?
    >      
    >      I think we need to support both.
    >
    > I agree.
    
    That's ok to me.
    
    >      
    >      >
    >      > I think that could be useful to pass the ibi type on request_ibi(),
    >      > there is some case where the master doesn't support IBI-MR.
    >      
    >      Actually, I was planning on making it completely separate from
    >      regular slave IBIs. That is, the master controller driver would demux
    >      the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
    >      mastership handover work to the workqueue (pretty much what we do for
    >      Hot-Join already). Mastership handover is anyway likely to be IP
    >      specific, so I don't think there's a need to make it look like a
    >      regular IBI.
    >
    > I think it's better to have separate function to do mastership request.
    >      
    >      Regarding whether IBI-MR support should be exposed to the I3C framework
    >      or not depends on how much will be automated on the framework side. I
    >      don't the answer yet, but that's probably something will figure out
    >      along the road.
    >
    > My current implementation is: when request_mastership field
    > of i3c_master_controller_ops structure is set, master driver supports mastership requests.
    > That's how I check if this is supported or not.
    >      
    >      Regards,
    >      
    >      Boris
    >      
    > Regards,
    > Przemek
    >
    when you say request_mastership, do you mean the current master do the 
    mastership hand-off or the secondary master request to be current master?

I mean secondary master requests to be current master. Current master do the mastership
hand-off using GETACCMST command.
    
    So, per my understanding since the Main master support the hand-off of 
    the bus you accept all incoming MR, right? Or do you check all devices BCR?

I'm not sure what do you mean here. Mastership request(MR) is from secondary master
to current master. Current master can NACK this request if for example it comes from 
wrong device. If it's ok, current master sends GETACCMST command and secondary master 
may ACK or NACK this command. It it's acked, secondary master becomes current master.
    
    Best regards,
    Vitor Soares

Please let me know if something is unclear.

Regards,
Przemek
    

Powered by blists - more mailing lists