Hi Caleb, On Fri, 19 Jul 2024 at 20:45, Caleb Connolly <caleb.conno...@linaro.org> wrote: > > > > On 19/07/2024 17:04, Simon Glass wrote: > > Hi Caleb, > > > > On Tue, 16 Jul 2024 at 08:16, Caleb Connolly <caleb.conno...@linaro.org> > > wrote: > >> > >> > >> > >> On 16/07/2024 09:04, Simon Glass wrote: > >>> Hi Caleb, > >>> > >>> On Mon, 15 Jul 2024 at 22:42, Caleb Connolly <caleb.conno...@linaro.org> > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 15/07/2024 13:39, Simon Glass wrote: > >>>>> On Mon, 15 Jul 2024 at 11:08, Caleb Connolly > >>>>> <caleb.conno...@linaro.org> wrote: > >>>>>> > >>>>>> Integrate cmd-db into the U-Boot driver model. > >>>>>> > >>>>>> This is just a wrapper around an in-memory database, so we just need to > >>>>>> get the address and validate that cmd-db is there. > >>>>>> > >>>>>> Since cmd_db_header will be stored in the .data section we can skip > >>>>>> bind if it's already set. > >>>>>> > >>>>>> Signed-off-by: Caleb Connolly <caleb.conno...@linaro.org> > >>>>>> --- > >>>>>> To: Simon Glass <s...@chromium.org> > >>>>>> --- > >>>>>> drivers/soc/qcom/cmd-db.c | 72 > >>>>>> +++++++++++++++-------------------------------- > >>>>>> include/soc/qcom/cmd-db.h | 3 -- > >>>>>> 2 files changed, 23 insertions(+), 52 deletions(-) > >>>>>> > >>>>> > >>>>> Reviewed-by: Simon Glass <s...@chromium.org> > >>>> > >>>> Thanks > >>>>> > >>>>> BTW, this is a MISC driver. Does it implement the read() operation? > >>>> > >>>> No, the API (as defined in the header file) takes a string and returns a > >>>> database entry. cmd-db users don't have an easily available handle to > >>>> the node / udevice regardless. > >>> > >>> OK. The closest thing might be UCLASS_SYSINFO, but it is designed for > >>> inside U-Boot and uses an int instead of a string for lookup. > >> > >> Right, I don't think we'll be able to find a more optimum solution here. > > > > OK > > > >>> > >>> Could you use the devicetree for this information? What sort of info is > >>> it? > >> > >> It maps resource names (e.g. "ldoa1" - the LDO1 regulator on PMIC A) to > >> the address of the resource on the RPMh co-processor. > >> > >> We need to support existing (upstream) devicetree, since this has > >> already been around for many years. > > > > OK., Has this problem been resolved in more recent platforms? > > What problem?
Well it sounds like the board is using some sort of firmware service to obtain configuration when it should be using the devicetree. Is that right? Regards, Simon
