Hi Boris > -----Original Message----- > From: Boris Brezillon [mailto:[email protected]] > Sent: Tuesday, February 27, 2018 9:13 PM > To: Przemyslaw Sroka <[email protected]> > Cc: Vitor Soares <[email protected]>; Boris Brezillon > <[email protected]>; Wolfram Sang <wsa@the- > dreams.de>; [email protected]; Jonathan Corbet <[email protected]>; > [email protected]; Greg Kroah-Hartman > <[email protected]>; Arnd Bergmann <[email protected]>; > Arkadiusz Golec <[email protected]>; Alan Douglas > <[email protected]>; Bartosz Folta <[email protected]>; Damian > Kos <[email protected]>; Alicja Jurasik-Urbaniak <[email protected]>; > Cyprian Wronka <[email protected]>; Suresh Punnoose > <[email protected]>; Thomas Petazzoni <thomas.petazzoni@free- > electrons.com>; Nishanth Menon <[email protected]>; Rob Herring > <[email protected]>; Pawel Moll <[email protected]>; Mark Rutland > <[email protected]>; Ian Campbell <[email protected]>; > Kumar Gala <[email protected]>; [email protected]; linux- > [email protected]; Geert Uytterhoeven <[email protected]>; Linus > Walleij <[email protected]> > 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 <[email protected]> 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
