[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR07MB3196275A203E9BD8370A9549C1CD0@DM5PR07MB3196.namprd07.prod.outlook.com>
Date: Tue, 8 Dec 2020 06:00:33 +0000
From: Parshuram Raju Thombare <pthombar@...ence.com>
To: Nicolas Pitre <nico@...xnic.net>
CC: "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
"slongerbeam@...il.com" <slongerbeam@...il.com>,
"vitor.soares@...opsys.com" <vitor.soares@...opsys.com>,
"praneeth@...com" <praneeth@...com>,
Milind Parab <mparab@...ence.com>,
"linux-i3c@...ts.infradead.org" <linux-i3c@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v10 3/7] i3c: master: add i3c_secondary_master_register
>I'm not sure about the logic here. Why would the secondary master
>initialize the bus? If you make a distinction between primary and
>secondary, then the primary should be the owner of the bus and it should
>have enumerated it already. You should populate the bus structure with
>info provided by the primary master not from DT?
Here the bus initialization means programming HW for communicating over
I3C bus and initializing i3c_master_controller object, which is needed for both
primary and secondary masters. Yes, primary master is initial bus master,
it assign addresses to each device detected on I3C bus in DAA and broadcast
the list through DEFSLVS, which is used by secondary masters during their
remaining initialization.
Initial approach was to allow secondary master to get information about
devices on bus from DEFSLVS only, but it was later decided that secondary
master should parse DT as well for any I2C and I3C device information.
Regards,
Parshuram Thombare
Powered by blists - more mailing lists