From: Sean Anderson <seanga2@gmail.com>
To: Patrick Delaunay <patrick.delaunay@foss.st.com>, u-boot@lists.denx.de
Cc: Joe Hershberger <joe.hershberger@ni.com>,
Patrice Chotard <patrice.chotard@foss.st.com>,
uboot-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH 2/3] phy: stm32-usbphyc: usbphyc is a clock provider of ck_usbo_48m clock
Date: Sun, 8 May 2022 14:23:20 -0400 [thread overview]
Message-ID: <9ce9e654-da33-449a-58df-033e1c6479af@gmail.com> (raw)
In-Reply-To: <20220426143736.2.I0322692ca3c12c0bcacc7da24804b7dcf3402e58@changeid>
On 4/26/22 8:37 AM, Patrick Delaunay wrote:
> ck_usbo_48m is generated by usbphyc PLL and used by OTG controller
> for Full-Speed use cases with dedicated Full-Speed transceiver.
>
> ck_usbo_48m is available as soon as the PLL is enabled.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
> ---
>
> drivers/phy/phy-stm32-usbphyc.c | 79 +++++++++++++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/drivers/phy/phy-stm32-usbphyc.c b/drivers/phy/phy-stm32-usbphyc.c
> index 16c8799eca..e0b8fcb8f2 100644
> --- a/drivers/phy/phy-stm32-usbphyc.c
> +++ b/drivers/phy/phy-stm32-usbphyc.c
> @@ -7,6 +7,7 @@
>
> #include <common.h>
> #include <clk.h>
> +#include <clk-uclass.h>
> #include <div64.h>
> #include <dm.h>
> #include <fdtdec.h>
> @@ -17,6 +18,7 @@
> #include <usb.h>
> #include <asm/io.h>
> #include <dm/device_compat.h>
> +#include <dm/lists.h>
> #include <linux/bitops.h>
> #include <linux/delay.h>
> #include <power/regulator.h>
> @@ -49,6 +51,9 @@
> #define PLL_INFF_MIN_RATE 19200000 /* in Hz */
> #define PLL_INFF_MAX_RATE 38400000 /* in Hz */
>
> +/* USBPHYC_CLK48 */
> +#define USBPHYC_CLK48_FREQ 48000000 /* in Hz */
> +
> struct pll_params {
> u8 ndiv;
> u16 frac;
> @@ -355,6 +360,16 @@ static const struct phy_ops stm32_usbphyc_phy_ops = {
> .of_xlate = stm32_usbphyc_of_xlate,
> };
>
> +static int stm32_usbphyc_bind(struct udevice *dev)
> +{
> + int ret;
> +
> + ret = device_bind_driver_to_node(dev, "stm32-usbphyc-clk", "ck_usbo_48m",
> + dev_ofnode(dev), NULL);
> +
> + return log_ret(ret);
> +}
> +
> static int stm32_usbphyc_probe(struct udevice *dev)
> {
> struct stm32_usbphyc *usbphyc = dev_get_priv(dev);
> @@ -444,6 +459,70 @@ U_BOOT_DRIVER(stm32_usb_phyc) = {
> .id = UCLASS_PHY,
> .of_match = stm32_usbphyc_of_match,
> .ops = &stm32_usbphyc_phy_ops,
> + .bind = stm32_usbphyc_bind,
> .probe = stm32_usbphyc_probe,
> .priv_auto = sizeof(struct stm32_usbphyc),
> };
> +
> +struct stm32_usbphyc_clk {
> + bool enable;
> +};
> +
> +static ulong stm32_usbphyc_clk48_get_rate(struct clk *clk)
> +{
> + return USBPHYC_CLK48_FREQ;
What is the relationship between this clock and the PLL?
> +}
> +
> +static int stm32_usbphyc_clk48_enable(struct clk *clk)
> +{
> + struct stm32_usbphyc_clk *usbphyc_clk = dev_get_priv(clk->dev);
> + struct stm32_usbphyc *usbphyc;
> + int ret;
> +
> + if (usbphyc_clk->enable)
> + return 0;
> +
> + usbphyc = dev_get_priv(clk->dev->parent);
> +
> + /* ck_usbo_48m is generated by usbphyc PLL */
> + ret = stm32_usbphyc_pll_enable(usbphyc);
> + if (ret)
> + return ret;
> +
> + usbphyc_clk->enable = true;
> +
> + return 0;
> +}
> +
> +static int stm32_usbphyc_clk48_disable(struct clk *clk)
> +{
> + struct stm32_usbphyc_clk *usbphyc_clk = dev_get_priv(clk->dev);
> + struct stm32_usbphyc *usbphyc;
> + int ret;
> +
> + if (!usbphyc_clk->enable)
> + return 0;
> +
> + usbphyc = dev_get_priv(clk->dev->parent);
> +
> + ret = stm32_usbphyc_pll_disable(usbphyc);
> + if (ret)
> + return ret;
> +
> + usbphyc_clk->enable = false;
> +
> + return 0;
> +}
> +
> +const struct clk_ops usbphyc_clk48_ops = {
> + .get_rate = stm32_usbphyc_clk48_get_rate,
> + .enable = stm32_usbphyc_clk48_enable,
> + .disable = stm32_usbphyc_clk48_disable,
> +};
> +
> +U_BOOT_DRIVER(stm32_usb_phyc_clk) = {
> + .name = "stm32-usbphyc-clk",
> + .id = UCLASS_CLK,
> + .ops = &usbphyc_clk48_ops,
> + .priv_auto = sizeof(struct stm32_usbphyc_clk),
> +};
>
I see that in the next patch you call this device from drivers/clk/clk_stm32mp1.c
Why is this clock a separate driver from the clock driver?
--Sean
next prev parent reply other threads:[~2022-05-08 18:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 12:37 [PATCH 0/3] stm32mp: handle ck_usbo_48m clock provided by USBPHYC Patrick Delaunay
2022-04-26 12:37 ` [PATCH 1/3] phy: stm32-usbphyc: add counter of PLL consumer Patrick Delaunay
2022-05-06 14:18 ` Patrice CHOTARD
2022-05-10 7:45 ` [Uboot-stm32] " Patrice CHOTARD
2022-05-10 11:50 ` Patrice CHOTARD
2022-05-08 18:21 ` Sean Anderson
2022-05-09 14:37 ` Patrick DELAUNAY
2022-05-10 9:51 ` Amelie Delaunay
2022-05-11 16:48 ` Sean Anderson
2022-05-17 7:42 ` Patrick DELAUNAY
2022-06-11 15:43 ` Sean Anderson
2022-09-07 13:31 ` Patrick DELAUNAY
2022-04-26 12:37 ` [PATCH 2/3] phy: stm32-usbphyc: usbphyc is a clock provider of ck_usbo_48m clock Patrick Delaunay
2022-05-06 14:24 ` Patrice CHOTARD
2022-05-10 7:45 ` [Uboot-stm32] " Patrice CHOTARD
2022-05-08 18:23 ` Sean Anderson [this message]
2022-05-09 15:44 ` Patrick DELAUNAY
2022-09-07 13:31 ` Patrick DELAUNAY
2022-04-26 12:37 ` [PATCH 3/3] clk: stm32mp: handle ck_usbo_48m clock provided by USBPHYC Patrick Delaunay
2022-05-06 14:26 ` Patrice CHOTARD
2022-05-10 7:45 ` [Uboot-stm32] " Patrice CHOTARD
2022-09-07 13:32 ` Patrick DELAUNAY
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ce9e654-da33-449a-58df-033e1c6479af@gmail.com \
--to=seanga2@gmail.com \
--cc=joe.hershberger@ni.com \
--cc=patrice.chotard@foss.st.com \
--cc=patrick.delaunay@foss.st.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-stm32@st-md-mailman.stormreply.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox