Hi Boris > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@xxxxxxxxxxx] > Sent: Tuesday, February 27, 2018 9:13 PM > To: Przemyslaw Sroka <psroka@xxxxxxxxxxx> > Cc: Vitor Soares <Vitor.Soares@xxxxxxxxxxxx>; Boris Brezillon > <boris.brezillon@xxxxxxxxxxxxxxxxxx>; Wolfram Sang <wsa@the- > dreams.de>; linux-i2c@xxxxxxxxxxxxxxx; Jonathan Corbet <corbet@xxxxxxx>; > linux-doc@xxxxxxxxxxxxxxx; Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx>; Arnd Bergmann <arnd@xxxxxxxx>; > Arkadiusz Golec <agolec@xxxxxxxxxxx>; Alan Douglas > <adouglas@xxxxxxxxxxx>; Bartosz Folta <bfolta@xxxxxxxxxxx>; Damian > Kos <dkos@xxxxxxxxxxx>; Alicja Jurasik-Urbaniak <alicja@xxxxxxxxxxx>; > Cyprian Wronka <cwronka@xxxxxxxxxxx>; Suresh Punnoose > <sureshp@xxxxxxxxxxx>; Thomas Petazzoni <thomas.petazzoni@free- > electrons.com>; Nishanth Menon <nm@xxxxxx>; Rob Herring > <robh+dt@xxxxxxxxxx>; Pawel Moll <pawel.moll@xxxxxxx>; Mark Rutland > <mark.rutland@xxxxxxx>; Ian Campbell <ijc+devicetree@xxxxxxxxxxxxxx>; > Kumar Gala <galak@xxxxxxxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>; Linus > Walleij <linus.walleij@xxxxxxxxxx> > 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@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
