[PATCH 45/49] dm: of-platadata: Add option for device instantiation

Simon Glass sjg at chromium.org
Sat Jan 23 16:10:24 CET 2021


Hi Walter,

On Tue, 5 Jan 2021 at 20:40, Walter Lozano <walter.lozano at collabora.com> 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 <sjg at chromium.org>
> > ---
> >
> >   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


More information about the U-Boot mailing list