linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jolly Shah <jolly.shah@xilinx.com>
To: Stephen Boyd <sboyd@kernel.org>,
	Jolly Shah <jolly.shah@xilinx.com>,
	arm@kernel.org, linux-clk@vger.kernel.org,
	michal.simek@xilinx.com, mturquette@baylibre.com, olof@lixom.net
Cc: rajanv@xilinx.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Tejas Patel <tejas.patel@xilinx.com>,
	Rajan Vaja <rajan.vaja@xilinx.com>
Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags
Date: Fri, 29 May 2020 14:20:55 -0700	[thread overview]
Message-ID: <725e9477-647f-83b7-7fdf-7cdb7ae74586@xilinx.com> (raw)
In-Reply-To: <159070755756.69627.18401650656284023600@swboyd.mtv.corp.google.com>

Hi Stephan,

 > ------Original Message------
 > From: Stephen Boyd <sboyd@kernel.org>
 > Sent:  Thursday, May 28, 2020 4:12PM
 > To: Jolly Shah <jolly.shah@xilinx.com>, Arm <arm@kernel.org>, 
Linux-clk <linux-clk@vger.kernel.org>, Michal Simek 
<michal.simek@xilinx.com>, Mturquette <mturquette@baylibre.com>, Olof 
<olof@lixom.net>
 > Cc: Rajan Vaja <rajanv@xilinx.com>, 
Linux-arm-kernel@lists.infradead.org 
<linux-arm-kernel@lists.infradead.org>, Linux-kernel@vger.kernel.org 
<linux-kernel@vger.kernel.org>, Tejas Patel <tejas.patel@xilinx.com>, 
Rajan Vaja <rajan.vaja@xilinx.com>
 > Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction 
clock check from custom type flags
 >
> Quoting Jolly Shah (2020-05-28 10:44:01)
>> Hi Stephan,
>>
>> Thanks for the review.
>>
>>   > ------Original Message------
>>   > From: Stephen Boyd <sboyd@kernel.org>
>>   > Sent:  Tuesday, May 26, 2020 6:08PM
>>   > To: Jolly Shah <jolly.shah@xilinx.com>, Arm <arm@kernel.org>,
>> Linux-clk <linux-clk@vger.kernel.org>, Michal Simek
>> <michal.simek@xilinx.com>, Mturquette <mturquette@baylibre.com>, Olof
>> <olof@lixom.net>
>>   > Cc: Rajan Vaja <rajanv@xilinx.com>,
>> Linux-arm-kernel@lists.infradead.org
>> <linux-arm-kernel@lists.infradead.org>, Linux-kernel@vger.kernel.org
>> <linux-kernel@vger.kernel.org>, Tejas Patel <tejas.patel@xilinx.com>,
>> Rajan Vaja <rajan.vaja@xilinx.com>, Jolly Shah <jolly.shah@xilinx.com>
>>   > Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction
>> clock check from custom type flags
>>   >
>>> Quoting Jolly Shah (2020-03-12 14:31:39)
>>>> From: Tejas Patel <tejas.patel@xilinx.com>
>>>>
>>>> Older firmware version sets BIT(13) in clkflag to mark a
>>>> divider as fractional divider. Updated firmware version sets BIT(4)
>>>> in type flags to mark a divider as fractional divider since
>>>> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
>>>> framework flags.
>>>>
>>>> To support both old and new firmware version, consider BIT(13) from
>>>> clkflag and BIT(4) from type_flag to check if divider is fractional
>>>> or not.
>>>>
>>>> To maintain compatibility BIT(13) of clkflag in firmware will not be
>>>> used in future for any purpose and will be marked as unused.
>>>
>>> Why are we mixing the firmware flags with the ccf flags? They shouldn't
>>> be the same. The firmware should have its own 'flag numberspace' that is
>>> distinct from the common clk framework's 'flag numberspace'. Please fix
>>> the code.
>>>
>>
>> Yes firmware flags are using separate numberspace now. Firmware
>> maintains CCF and firmware specific flags separately but earlier
>> CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here
>> for backward compatibility. Driver takes care of not registering same
>> with CCF. Let me know if I misunderstood.
> 
> Why is the firmware maintaining CCF specific flags? The firmware
> shouldn't know about the CCF flag numbering at all. We can change the
> numbers that the CCF flags are assigned to randomly and that shouldn't
> mean that the firmware needs to change. Maybe I should apply this patch?

Got it. Will fix it.

Thanks,
Jolly Shah


> 
> ---8<----
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index bd1ee9039558..c1f36bca85b0 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -16,22 +16,22 @@
>    *
>    * Please update clk_flags[] in drivers/clk/clk.c when making changes here!
>    */
> -#define CLK_SET_RATE_GATE	BIT(0) /* must be gated across rate change */
> -#define CLK_SET_PARENT_GATE	BIT(1) /* must be gated across re-parent */
> -#define CLK_SET_RATE_PARENT	BIT(2) /* propagate rate change up one level */
> -#define CLK_IGNORE_UNUSED	BIT(3) /* do not gate even if unused */
> +#define CLK_SET_RATE_GATE	BIT(13) /* must be gated across rate change */
> +#define CLK_SET_PARENT_GATE	BIT(2) /* must be gated across re-parent */
> +#define CLK_SET_RATE_PARENT	BIT(3) /* propagate rate change up one level */
> +#define CLK_IGNORE_UNUSED	BIT(4) /* do not gate even if unused */
>   				/* unused */
>   				/* unused */
> -#define CLK_GET_RATE_NOCACHE	BIT(6) /* do not use the cached clk rate */
> -#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
> -#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy */
> -#define CLK_RECALC_NEW_RATES	BIT(9) /* recalc rates after notifications */
> -#define CLK_SET_RATE_UNGATE	BIT(10) /* clock needs to run to set rate */
> -#define CLK_IS_CRITICAL		BIT(11) /* do not gate, ever */
> +#define CLK_GET_RATE_NOCACHE	BIT(5) /* do not use the cached clk rate */
> +#define CLK_SET_RATE_NO_REPARENT BIT(6) /* don't re-parent on rate change */
> +#define CLK_GET_ACCURACY_NOCACHE BIT(7) /* do not use the cached clk accuracy */
> +#define CLK_RECALC_NEW_RATES	BIT(8) /* recalc rates after notifications */
> +#define CLK_SET_RATE_UNGATE	BIT(9) /* clock needs to run to set rate */
> +#define CLK_IS_CRITICAL		BIT(10) /* do not gate, ever */
>   /* parents need enable during gate/ungate, set rate and re-parent */
> -#define CLK_OPS_PARENT_ENABLE	BIT(12)
> +#define CLK_OPS_PARENT_ENABLE	BIT(11)
>   /* duty cycle call may be forwarded to the parent clock */
> -#define CLK_DUTY_CYCLE_PARENT	BIT(13)
> +#define CLK_DUTY_CYCLE_PARENT	BIT(12)
>   
>   struct clk;
>   struct clk_hw;
> 

  reply	other threads:[~2020-05-29 21:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12 21:31 [PATCH v2 0/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags Jolly Shah
2020-03-12 21:31 ` [PATCH v2 1/2] drivers: clk: zynqmp: Add support for " Jolly Shah
2020-05-27  1:01   ` Stephen Boyd
2020-03-12 21:31 ` [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check from " Jolly Shah
2020-05-27  1:01   ` Stephen Boyd
2020-05-27  1:08   ` Stephen Boyd
2020-05-28 17:44     ` Jolly Shah
2020-05-28 23:12       ` Stephen Boyd
2020-05-29 21:20         ` Jolly Shah [this message]
2020-03-23 21:15 ` [PATCH v2 0/2] " Jolly Shah
2020-04-09 20:48 ` Jolly Shah

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=725e9477-647f-83b7-7fdf-7cdb7ae74586@xilinx.com \
    --to=jolly.shah@xilinx.com \
    --cc=arm@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=mturquette@baylibre.com \
    --cc=olof@lixom.net \
    --cc=rajan.vaja@xilinx.com \
    --cc=rajanv@xilinx.com \
    --cc=sboyd@kernel.org \
    --cc=tejas.patel@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;
as well as URLs for NNTP newsgroup(s).