Date:   Tue, 27 Feb 2018 20:24:43 +0000
From:   Przemyslaw Sroka <psroka@...ence.com>
To:     Boris Brezillon <boris.brezillon@...tlin.com>
CC:     Vitor Soares <Vitor.Soares@...opsys.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.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>,
        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>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.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>
Subject: RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure

Hi Boris

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@...tlin.com]
> Sent: Tuesday, February 27, 2018 9:13 PM
> To: Przemyslaw Sroka <psroka@...ence.com>
> Cc: Vitor Soares <Vitor.Soares@...opsys.com>; Boris Brezillon
> <boris.brezillon@...e-electrons.com>; Wolfram Sang <wsa@...-
> dreams.de>; linux-i2c@...r.kernel.org; Jonathan Corbet <corbet@....net>;
> linux-doc@...r.kernel.org; Greg Kroah-Hartman
> <gregkh@...uxfoundation.org>; Arnd Bergmann <arnd@...db.de>;
> 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>; Thomas Petazzoni <thomas.petazzoni@...e-
> electrons.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; linux-
> kernel@...r.kernel.org; Geert Uytterhoeven <geert@...ux-m68k.org>; Linus
> Walleij <linus.walleij@...aro.org>
> Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> 
> EXTERNAL MAIL
> 
> 
> Hi Przemek,
> 
> On Tue, 27 Feb 2018 16:43:27 +0000
> Przemyslaw Sroka <psroka@...ence.com> wrote:
> 
> > >
> > > >> Either important is the SETDASA for declared I3C devices. So the
> > > >> DAA process should start by send an SETDASA and them ENTDAA
> CCC
> > > command.
> > > > My understanding was that SETDASA was not mandatory, and was
> only
> > > > useful when one wants to assign a specific dynamic address to a
> > > > slave that has a static address (which is again not mandatory).
> > > > I've tested it, and even devices with a static address participate
> > > > to the DAA procedure if they've not been assigned a dynamic
> > > > address yet, so I don't see the need for this SETDASA step if you
> > > > don't need to assign a particular dynamic address to the device.
> > > >
> > > > Could you tell me why you think SETDASA is required?
> > >
> > > Yes, you are right... But in my opinion it is required as it does
> > > part of DAA process.
> >
> > SETDASA is simply faster than ENTDAA, but only if there is no need to
> > collect BCR/DCR/PID of such devices. I think most applications would
> > like to have them as an status information so  after all ENTDAA can be
> > regarded as an generic approach (unless I'm mistaken).
> 
> Actually, we could retrieve BCR/DCR/PID (and all other relevant
> information, like MAXDS) even with the SETDASA approach. We just need to
> send the according CCC commands after SETDASA.
> 
I agree, what I meant by "SETDASA is simply faster than ENTDAA, but only if there is no need to collect BCR/DCR/PID of such devices." Is that it is faster than DAA but only if not followed by GET CCC commands to gather BCR/DCR/PID. I think we are on the same page here.

> But that's also my understanding that ENTDAA should always work, and
> SETDASA usage is only needed if you want to reserve a dynamic address
> and assign it to a device before DAA takes place. This way you can enforce
> the device priority (WRT IBIs). But honestly, that's the only use case I can
> think of, and to me, it sounds like an advanced feature we may want to
> support at some point, but don't need in the initial implementation.
>
Still ENTDAA seems to be sufficient for IBI prioritization but I can imagine some use cases where people would like to use it for such purposes. Note that SETDASA is applicable only for devices with SA so it is self-explanatory that it cannot be considered as utility to define priorities for all devices before ENTDAA. 

> --
> Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and
> Kernel engineering https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__bootlin.com&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3G
> Z-_haXqY&r=b0WPdqYyu0KH4-vSatt-ViJE1riZ603zdXl3hHHp_TU&m=wM54-
> BGcSfHEklVRsw02O-bnyNkLTe9c0RyBP_ExzPA&s=pxQrogG-
> Nq4XOMU7SPZ2FZNbgnbnjdERtMm_h7ZcdCE&e=

Regards,
Przemek

Powered by blists - more mailing lists