mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Tretter <m.tretter@pengutronix.de>
To: Amit Sunil Dhamne <amit.sunil.dhamne@xilinx.com>
Cc: mturquette@baylibre.com, sboyd@codeaurora.org, sboyd@kernel.org,
	michal.simek@xilinx.com, mark.rutland@arm.com,
	linux-clk@vger.kernel.org, Rajan Vaja <rajan.vaja@xilinx.com>,
	tejasp@xilinx.com, linux-kernel@vger.kernel.org,
	jollys@xilinx.com, rajanv@xilinx.com,
	linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de
Subject: Re: [PATCH 1/3] clk: zynqmp: Use firmware specific common clock flags
Date: Tue, 30 Jun 2020 15:27:00 +0200	[thread overview]
Message-ID: <20200630132700.GA15753@pengutronix.de> (raw)
In-Reply-To: <1593477014-18443-2-git-send-email-amit.sunil.dhamne@xilinx.com>

On Mon, 29 Jun 2020 17:30:12 -0700, Amit Sunil Dhamne wrote:
> From: Rajan Vaja <rajan.vaja@xilinx.com>
> 
> Currently firmware passes CCF specific flags to ZynqMP clock driver.
> So firmware needs to be updated if CCF flags are changed. The firmware
> should have its own 'flag number space' that is distinct from the
> common clk framework's 'flag number space'. So define and use ZynqMP
> specific common clock flags instead of using CCF flags.
> 
> Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
> Signed-off-by: Amit Sunil Dhamne <amit.sunil.dhamne@xilinx.com>
> ---
>  drivers/clk/zynqmp/clk-zynqmp.h | 22 ++++++++++++++++++++++
>  drivers/clk/zynqmp/clkc.c       | 25 +++++++++++++++++++++++--
>  2 files changed, 45 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/zynqmp/clk-zynqmp.h b/drivers/clk/zynqmp/clk-zynqmp.h
> index 5beeb41..d8e580b 100644
> --- a/drivers/clk/zynqmp/clk-zynqmp.h
> +++ b/drivers/clk/zynqmp/clk-zynqmp.h
> @@ -10,6 +10,28 @@
> 
>  #include <linux/firmware/xlnx-zynqmp.h>
> 
> +/* Common Flags */
> +/* must be gated across rate change */
> +#define ZYNQMP_CLK_SET_RATE_GATE       BIT(0)
> +/* must be gated across re-parent */
> +#define ZYNQMP_CLK_SET_PARENT_GATE     BIT(1)
> +/* propagate rate change up one level */
> +#define ZYNQMP_CLK_SET_RATE_PARENT     BIT(2)
> +/* do not gate even if unused */
> +#define ZYNQMP_CLK_IGNORE_UNUSED       BIT(3)
> +/* do not use the cached clk rate */
> +#define ZYNQMP_CLK_GET_RATE_NOCACHE    BIT(6)
> +/* don't re-parent on rate change */
> +#define ZYNQMP_CLK_SET_RATE_NO_REPARENT        BIT(7)
> +/* do not use the cached clk accuracy */
> +#define ZYNQMP_CLK_GET_ACCURACY_NOCACHE        BIT(8)
> +/* recalc rates after notifications */
> +#define ZYNQMP_CLK_RECALC_NEW_RATES    BIT(9)
> +/* clock needs to run to set rate */
> +#define ZYNQMP_CLK_SET_RATE_UNGATE     BIT(10)
> +/* do not gate, ever */
> +#define ZYNQMP_CLK_IS_CRITICAL         BIT(11)
> +
>  enum topology_type {
>         TYPE_INVALID,
>         TYPE_MUX,
> diff --git a/drivers/clk/zynqmp/clkc.c b/drivers/clk/zynqmp/clkc.c
> index db8d0d7..8663587 100644
> --- a/drivers/clk/zynqmp/clkc.c
> +++ b/drivers/clk/zynqmp/clkc.c
> @@ -385,14 +385,35 @@ static int __zynqmp_clock_get_topology(struct clock_topology *topology,
>  {
>         int i;
>         u32 type;
> +       u32 flag;
> 
>         for (i = 0; i < ARRAY_SIZE(response->topology); i++) {
>                 type = FIELD_GET(CLK_TOPOLOGY_TYPE, response->topology[i]);
>                 if (type == TYPE_INVALID)
>                         return END_OF_TOPOLOGY_NODE;
>                 topology[*nnodes].type = type;
> -               topology[*nnodes].flag = FIELD_GET(CLK_TOPOLOGY_FLAGS,
> -                                                  response->topology[i]);
> +               flag = FIELD_GET(CLK_TOPOLOGY_FLAGS, response->topology[i]);
> +               topology[*nnodes].flag = 0;
> +               topology[*nnodes].flag |= (flag & ZYNQMP_CLK_SET_RATE_GATE) ?
> +                                          CLK_SET_RATE_GATE : 0;
> +               topology[*nnodes].flag |= (flag & ZYNQMP_CLK_SET_RATE_PARENT) ?
> +                                          CLK_SET_RATE_PARENT : 0;
> +               topology[*nnodes].flag |= (flag & ZYNQMP_CLK_IGNORE_UNUSED) ?
> +                                          CLK_IGNORE_UNUSED : 0;
> +               topology[*nnodes].flag |= (flag & ZYNQMP_CLK_GET_RATE_NOCACHE) ?
> +                                          CLK_GET_RATE_NOCACHE : 0;
> +               topology[*nnodes].flag |= (flag &
> +                                          ZYNQMP_CLK_SET_RATE_NO_REPARENT) ?
> +                                          CLK_SET_RATE_NO_REPARENT : 0;
> +               topology[*nnodes].flag |= (flag &
> +                                          ZYNQMP_CLK_GET_ACCURACY_NOCACHE) ?
> +                                          CLK_GET_ACCURACY_NOCACHE : 0;
> +               topology[*nnodes].flag |= (flag & ZYNQMP_CLK_RECALC_NEW_RATES) ?
> +                                          CLK_RECALC_NEW_RATES : 0;
> +               topology[*nnodes].flag |= (flag & ZYNQMP_CLK_SET_RATE_UNGATE) ?
> +                                          CLK_SET_RATE_UNGATE : 0;
> +               topology[*nnodes].flag |= (flag & ZYNQMP_CLK_IS_CRITICAL) ?
> +                                          CLK_IS_CRITICAL : 0;

I don't think that this is the right location for converting the ZYNQMP_CLK_*
flags to CLK_* flags. Here we are writing the flags to the struct
clock_topology, which is still ZynqMP specific. The conversion should rather
happen in the zynqmp_clk_register_*() functions, because these functions write
the flags to struct clk_init_data, which is part of the common clock
framework.

Maybe you could also add a helper function for converting the flags to make
this more readable.

Michael

>                 topology[*nnodes].type_flag =
>                                 FIELD_GET(CLK_TOPOLOGY_TYPE_FLAGS,
>                                           response->topology[i]);
> --
> 2.7.4
> 
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

  reply	other threads:[~2020-06-30 13:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30  0:30 [PATCH 0/3] clk: zynqmp: Add firmware specific " Amit Sunil Dhamne
2020-06-30  0:30 ` [PATCH 1/3] clk: zynqmp: Use firmware specific common " Amit Sunil Dhamne
2020-06-30 13:27   ` Michael Tretter [this message]
2020-06-30  0:30 ` [PATCH 2/3] clk: zynqmp: Use firmware specific divider " Amit Sunil Dhamne
2020-06-30  0:30 ` [PATCH 3/3] clk: zynqmp: Use firmware specific mux " Amit Sunil Dhamne

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=20200630132700.GA15753@pengutronix.de \
    --to=m.tretter@pengutronix.de \
    --cc=amit.sunil.dhamne@xilinx.com \
    --cc=jollys@xilinx.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=michal.simek@xilinx.com \
    --cc=mturquette@baylibre.com \
    --cc=rajan.vaja@xilinx.com \
    --cc=rajanv@xilinx.com \
    --cc=sboyd@codeaurora.org \
    --cc=sboyd@kernel.org \
    --cc=tejasp@xilinx.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

all inboxes | Powered by JetHome®