Hi Boris > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Tuesday, February 27, 2018 9:13 PM > To: Przemyslaw Sroka <psr...@cadence.com> > Cc: Vitor Soares <vitor.soa...@synopsys.com>; Boris Brezillon > <boris.brezil...@free-electrons.com>; Wolfram Sang <wsa@the- > dreams.de>; linux-...@vger.kernel.org; Jonathan Corbet <cor...@lwn.net>; > linux-...@vger.kernel.org; Greg Kroah-Hartman > <gre...@linuxfoundation.org>; Arnd Bergmann <a...@arndb.de>; > Arkadiusz Golec <ago...@cadence.com>; Alan Douglas > <adoug...@cadence.com>; Bartosz Folta <bfo...@cadence.com>; Damian > Kos <d...@cadence.com>; Alicja Jurasik-Urbaniak <ali...@cadence.com>; > Cyprian Wronka <cwro...@cadence.com>; Suresh Punnoose > <sure...@cadence.com>; Thomas Petazzoni <thomas.petazzoni@free- > electrons.com>; Nishanth Menon <n...@ti.com>; Rob Herring > <robh...@kernel.org>; Pawel Moll <pawel.m...@arm.com>; Mark Rutland > <mark.rutl...@arm.com>; Ian Campbell <ijc+devicet...@hellion.org.uk>; > Kumar Gala <ga...@codeaurora.org>; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; Geert Uytterhoeven <ge...@linux-m68k.org>; Linus > Walleij <linus.wall...@linaro.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 <psr...@cadence.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
