On 19/07/2024 17:04, Simon Glass wrote:
Hi Caleb,
On Tue, 16 Jul 2024 at 08:16, Caleb Connolly caleb.connolly@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.connolly@linaro.org wrote:
On 15/07/2024 13:39, Simon Glass wrote:
On Mon, 15 Jul 2024 at 11:08, Caleb Connolly caleb.connolly@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.connolly@linaro.org
To: Simon Glass sjg@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 sjg@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?
Regards, Simon