Message-ID: <20240903150038.3f224ec9@xps-13>
Date: Tue, 3 Sep 2024 15:00:38 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Frank Li <Frank.li@....com>
Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>, Boris Brezillon
 <boris.brezillon@...labora.com>, Parshuram Thombare <pthombar@...ence.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Boris Brezillon
 <bbrezillon@...nel.org>, Arnd Bergmann <arnd@...db.de>, Conor Culhane
 <conor.culhane@...vaco.com>, linux-i3c@...ts.infradead.org,
 linux-kernel@...r.kernel.org, imx@...ts.linux.dev
Subject: Re: [PATCH v3 03/11] i3c: master: Extend address status bit to 4
 and add I3C_ADDR_SLOT_EXT_INIT

Hi Frank,

Frank.li@....com wrote on Mon, 2 Sep 2024 14:20:51 -0400:

> On Mon, Sep 02, 2024 at 04:12:50PM +0200, Miquel Raynal wrote:
> > Hi Frank,
> >  
> > > > > switch to this address if it is free.
> > > > >  *
> > > > > In step 1, i3c_bus_get_free_addr() is called. To optimize for step 2b, this
> > > > > function should return an address that is not pre-reserved by any target
> > > > > device with an assigned address in the device tree (DT).  
> > > >
> > > > This does not make sense, if you want to optimize for 2b, why not
> > > > selecting the assigned-address property in the first place if it's
> > > > available?  
> > >
> > > This is my first idea. But I gived up this way.
> > >
> > > Select an assigned-address here will involve a big change in i3c framework.
> > > There are no PID information in i3c_master_get_free_addr().
> > >
> > > In DAA flow:
> > > - SVC is get PID first, the get_free_addr(). This case, we can use PID to
> > > get dt assigned address.(if change/add API)
> > > - But HCI, it is difference, hci_cmd_v2_daa(), get_free_addr() firstly then
> > > send out DAA command. So no PID information when call get_free_addr().
> > >
> > > To cover both case, return a *real* free address here is simplest solution.  
> >
> > But this is a limitation of the HCI driver? So why not addressing this
> > in the HCI driver instead? It would greatly simplify the core logic
> > which becomes complex for wrong reasons.  
> 
> It is reasonable requirement to reduce stall SCL time. After get PID, SCL
> have to stall low to wait for software get dynamtic address, I3C spec allow
> relative long time for this, but still better if hardware can send out PID
> and dynamatic address together withoug stall SCL low. Pre-alloc adddress is
> good method if consider this.

I don't think it is worth the trouble, given the complexity of all
the changes. I prefer to simplify a bit the software and keep it
readable than gaining few us with SCL low. In this case you also spend
more time on the configuration I guess, so is it better than keeping
SCL low (it will be low for some time anyway).

> > > >  Also, I don't understand why you would care to specifically
> > > > *not* return an address that might be the default one for another
> > > > device in the first place.  
> > >
> > > If devices A (want adddress 0xA), device B (want address 0xB), if both
> > > device send hot join at the same time. device B's PID less than device A,
> > >
> > > Device B will be found firstly, call get_free_addr(), 0xA will be return
> > > if no this patch.
> > >
> > > Device A, call try_get_freeaddr() to get 0xB.
> > >
> > > So Devcie B will be assign to 0xA, and Device A will be assign to address 0xB.
> > >
> > > After do_daa command, framework will add device B and device A into i3c bus.
> > >
> > > When framework try to add device B to i3c bus, framework will try switch
> > > device B's address to 0xB from 0xA, but it will be fail because 0xB already
> > > assigned to device A.  
> >
> > Well, okay, but that's exactly the situation that will happen if these
> > devices are not described in your DT. I guess it's expected that a
> > device not described in your DT can be connected, thanks to the
> > hot-join feature. In this case you cannot know what is this device
> > preferred address and you might end-up in the exact same situation.  
> 
> If not descript in DT, it means that any dynmatic address can be assigned.

That's the point of view of the host. But a device might be "critical"
and expect a low address, but the host not being aware. This is the
same situation as your A and B conflict example.

> > May I question the need for preferred addresses at all? Is this even
> > part of the spec? What is the use-case?  
> 
> It is implements detail. I3C spec said lower dynamtic address have high IBI
> priority. Spec just said assign lower dynamtic address if want to higher
> IBI prioerity. Using DT assign-address just is one implement method.

Thanks for all the information, for me the HCI driver must be modified
to retrieve the PID before assigning the dynamic address.

Thanks,
Miquèl

Powered by blists - more mailing lists