RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux