From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sat, 23 Jan 2021 08:10:24 -0700 Subject: [PATCH 45/49] dm: of-platadata: Add option for device instantiation In-Reply-To: <5a73966a-2744-a776-f7d8-2c768cdf6deb@collabora.com> References: <20201229033535.99990-1-sjg@chromium.org> <20201229033535.99990-46-sjg@chromium.org> <5a73966a-2744-a776-f7d8-2c768cdf6deb@collabora.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Walter, On Tue, 5 Jan 2021 at 20:40, Walter Lozano wrote: > > > On 12/29/20 12:35 AM, Simon Glass wrote: > > Add Kconfig options to support build-time device instantiation. When > > fully implemented, this will allow dtoc to create U-Boot devices (i.e. > > struct udevice records) at build time, thus reducing code space in > > SPL. > > > > For now this defaults to off, but will be enabled when the rest of > > the implementation is in place. > > > > Signed-off-by: Simon Glass > > --- > > > > dts/Kconfig | 23 +++++++++++++++++++++-- > > scripts/Makefile.spl | 4 ++++ > > 2 files changed, 25 insertions(+), 2 deletions(-) > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > index 71f50552e4f..e861ea48d01 100644 > > --- a/dts/Kconfig > > +++ b/dts/Kconfig > > @@ -355,15 +355,24 @@ config SPL_OF_PLATDATA > > compatible string, then adding platform data and U_BOOT_DRVINFO > > declarations for each node. See of-plat.txt for more information. > > > > +if SPL_OF_PLATDATA > > + > > config SPL_OF_PLATDATA_PARENT > > bool "Support parent information in devices" > > - depends on SPL_OF_PLATDATA > > default y > > help > > Generally it is useful to be able to access the parent of a device > > with of-platdata. To save space this can be disabled, but in that > > case dev_get_parent() will always return NULL; > > > > +config SPL_OF_PLATDATA_INST > > Not sure about the limits to config names, I understand that > SPL_OF_PLATDATA_INST means SPL_OF_PLATDATA_INSTANCE? I'm not sure but > maybe a better name could be SPL_OF_PLATDATA_BTIME_DEV. To be honest I > find it difficult to come with nice name. Yes that's right - INST standards for instantiate. I don't think there is a limit to the name length, but obviously longer names are harder to read. BTIME doesn't seem any more enlightening that INST though. I will try out SPL_OF_PLATDATA_INSTANTIATE and see how long it looks! > > > + bool "Declare devices at build time" > > + help > > + Declare devices as udevice instances so that they do not need to be > > + bound when U-Boot starts. This can save time and code space. > > + > > +endif > > + > > config TPL_OF_PLATDATA > > bool "Generate platform data for use in TPL" > > depends on TPL_OF_CONTROL > > @@ -385,13 +394,23 @@ config TPL_OF_PLATDATA > > compatible string, then adding platform data and U_BOOT_DRVINFO > > declarations for each node. See of-plat.txt for more information. > > > > +if TPL_OF_PLATDATA > > + > > config TPL_OF_PLATDATA_PARENT > > bool "Support parent information in devices" > > - depends on TPL_OF_PLATDATA > > default y > > help > > Generally it is useful to be able to access the parent of a device > > with of-platdata. To save space this can be disabled, but in that > > case dev_get_parent() will always return NULL; > > > > +config TPL_OF_PLATDATA_INST > > Same here. Also I have a question, in which case TPL_OF_PLATDATA_INST > and SPL_OF_PLATDATA_INST would have different values. Which is the value > of decoupling the TPL and SPL behavior? Or is use for consistency with > SPL_OF_PLATDATA_PARENT and TPL_OF_PLATDATA_PARENT (which also not sure > if needed to have two different options). It is partly consistency, but also just that CONFIG_IS_ENABLED() only works if you define them separately. Also I want to be able to check TPL_OF_PLATDATA_INST by itself without having to check TPL_OF_PLATDATA first. Regards, Simon