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. 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. -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
