[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1433748471.15883.14.camel@mtksdaap41>
Date: Mon, 8 Jun 2015 15:27:51 +0800
From: James Liao <jamesjj.liao@...iatek.com>
To: Stephen Boyd <sboyd@...eaurora.org>,
Sascha Hauer <kernel@...gutronix.de>
CC: Sascha Hauer <s.hauer@...gutronix.de>,
Mike Turquette <mturquette@...aro.org>,
<srv_heupstream@...iatek.com>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
Henry Chen <henryc.chen@...iatek.com>,
Ricky Liang <jcliang@...omium.org>,
Rob Herring <robh+dt@...nel.org>,
<linux-mediatek@...ts.infradead.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Yingjoe Chen <yingjoe.chen@...iatek.com>,
"Eddie Huang" <eddie.huang@...iatek.com>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/5] Add Mediatek MT8173 subsystem clocks support
Hi Stephen,
On Fri, 2015-06-05 at 17:59 -0700, Stephen Boyd wrote:
> Perhaps an example would be best. In DT we would have:
>
> vencsys: vencsys@...00 {
> compatible = "mtk,vencsys";
> reg = <0x10000 0x1000>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> };
>
> myconsumer@...00 {
> compatible = "mtk,vencsys";
> reg = <0x12000 0x100>;
> clocks = <&vencsys 10>;
> clock-names = "core";
> };
>
> (Or are the consumers only children of the subsystem?
> It's not clear to me)
In our case the vencsys clocks may use used by its own driver and other
drivers (such as SMI driver).
> And then in the mtk,vencsys driver we would create a platform
> device named something like "mtk-vencsys-clk" and assign the
> of_node of the device to be the of_node that is assigned to the
> mtk,vencsys device.
>
> static int vencsys_probe(struct platform_device *pdev)
> {
> int ret;
> struct device_node *np = pdev->dev.of_node;
> struct platform_device *clk_pdev;
>
> clk_pdev = platform_device_alloc("mtk-vencsys-clk", -1);
> clk_pdev->dev.of_node = of_node;
> ret = platform_device_add(clk_pdev);
> if (ret)
> return ret;
> }
>
> Then we could put a mtk-vencsys-clk driver in drivers/clk/ that
> does the clk driver part...
>
> static int clk_vencsys_probe(struct platform_device *pdev)
> {
> int ret;
> struct device_node *np = pdev->dev.of_node;
> struct regmap *regmap;
>
> ret = of_clk_add_provider(np, of_clk_src_onecell_get, ..);
> if (ret)
> return ret;
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
>
> }
>
> And similar things could be done for the reset driver.
>
It looks like there is only one DT node (vencsys@...00) but there are
several drivers refer to this DT node, and then we use a dummy driver
(or a "top driver") to aggregate drivers with different features (clk,
reset etc.).
It means we need to provide vencsys clk driver in drivers/clk and
vencsys reset driver in drivers/reset, and also to provide a vencsys top
driver in, for example, soc/mediatek, right?
Now we have 3 choice:
1. implement vencsys clock driver and reset driver in drivers/clk.
2. implement vencsys clock driver and reset driver in drivers/soc.
3. implement vencsys clock driver in drivers/clk, vencsys reset driver
in drivers/reset, and vencsys top driver in drivers/soc.
Sascha, do you have comments for these 3 solutions?
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists