On 07/31/2016 07:02 PM, Simon Glass wrote:
Hi Stephen,
On 27 July 2016 at 15:24, Stephen Warren <swar...@wwwdotorg.org> wrote:
From: Stephen Warren <swar...@nvidia.com>
In Tegra186, on-SoC clocks are manipulated using IPC requests to the BPMP
(Boot and Power Management Processor). This change implements a driver
that does that. A tegra/ sub-directory is created to follow the existing
pattern. It is unconditionally selected by CONFIG_TEGRA186 since virtually
any Tegra186 build of U-Boot will need the feature.
diff --git a/drivers/clk/tegra/tegra186-clk.c b/drivers/clk/tegra/tegra186-clk.c
+static ulong tegra186_clk_get_rate(struct clk *clk)
+{
+ struct mrq_clk_request req;
+ struct mrq_clk_response resp;
+ int ret;
+
+ debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
+ clk->id);
+
+ req.cmd_and_id = (CMD_CLK_GET_RATE << 24) | clk->id;
+
+ ret = tegra186_bpmp_call(clk->dev->parent, MRQ_CLK,
+ &req, sizeof(req), &resp, sizeof(resp));
Isn't his a MISC driver? Perhaps you can add a new method to
UCLASS_MISC matching your requirements here?
The core BPMP driver is a MISC driver, yes.
I don't see any advantage of making this call something that the MISC
uclass supports directly. This function is an internal implementation
detail of the BPMP, and certainly not something that every single MISC
driver (for any SoC for any HW module) would implement. If we did add
direct support to the MISC uclass, then the MISC "ops" structure would
basically grow forever since every single SoC's/HW's internal function
calls would be added to it. This would just bloat it up unnecessarily,
and I don't see any advantage to offset the disadvantage of that bloat.
FWIW, the Linux MFD (Multi-Function Devices) stack typically has "child"
(sub-)devices call custom APIs like this on the "parent"/container.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
