lkml.org 
[lkml]   [2018]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 2/7] i3c: Add core I3C infrastructure
    Hi Przemek,

    On Tue, 27 Feb 2018 17:06:37 +0000
    Przemyslaw Sroka <psroka@cadence.com> wrote:

    > > > >
    > > > > 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).
    >
    > Below are 2 examples on how DAA can be executed:
    > 1st:
    > A1) SETDASA to devices with SA

    I'm not even sure all devices with a static address needs to be
    assigned a dynamic address with SETDASA (actually, I'm almost sure
    it's not the case, since, according to section "5.1.9.3 CCC Command
    Definitions" of the spec, all I3C slaves have to support ENTDAA). To me,
    it looks like you'd want to do that only is you really need to reserve
    a specific dynamic address and prevent the DAA step from assigning it
    to another device.

    > B1) DAA to remaining devices
    > C1) GET BCR/DCR/PID to devices that initially had SA
    > NOTES: C1 is optional and order of B1 and C1 can be changed

    While that's true in principle, in Linux we'll always retrieve
    BCR/DCR/PID (and more, like MAXDS), no matter how the device obtained
    its dynamic address.

    >
    > 2nd:
    > A2) DAA to all devices
    > NOTES: no need for any follow up steps as all information is collected during DAA

    As said above, that's not exactly how the Linux implementation works.
    Right now I'm ignoring the information retrieved during DAA and forcing
    a GETPID/GETBCR/GETDCR for every discovered device. This approach is
    generating a bit more traffic on the bus, but it also makes the
    implementation more generic, because we have a single function to add
    an I3C device, no matter how it's been assigned a dynamic address.

    >
    > As we can see 2nd approach is more generic and do not see any reason to add special handling for SETDASA unless there is any reasonable reason to do otherwise.

    I agree on one thing: as long as you don't have to reserve a specific
    dynamic address, SETDASA is not required. At least, that's my
    understanding.

    Regards,

    Boris

    --
    Boris Brezillon, Bootlin (formerly Free Electrons)
    Embedded Linux and Kernel engineering
    https://bootlin.com

    \
     
     \ /
      Last update: 2018-02-27 21:26    [W:6.003 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site