[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c8cd31a-46ba-ec6a-67a7-f3d9abe561ff@xilinx.com>
Date: Thu, 28 May 2020 10:44:01 -0700
From: Jolly Shah <jolly.shah@...inx.com>
To: Stephen Boyd <sboyd@...nel.org>,
Jolly Shah <jolly.shah@...inx.com>, arm@...nel.org,
linux-clk@...r.kernel.org, michal.simek@...inx.com,
mturquette@...libre.com, olof@...om.net
Cc: rajanv@...inx.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Tejas Patel <tejas.patel@...inx.com>,
Rajan Vaja <rajan.vaja@...inx.com>
Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction clock check
from custom type flags
Hi Stephan,
Thanks for the review.
> ------Original Message------
> From: Stephen Boyd <sboyd@...nel.org>
> Sent: Tuesday, May 26, 2020 6:08PM
> To: Jolly Shah <jolly.shah@...inx.com>, Arm <arm@...nel.org>,
Linux-clk <linux-clk@...r.kernel.org>, Michal Simek
<michal.simek@...inx.com>, Mturquette <mturquette@...libre.com>, Olof
<olof@...om.net>
> Cc: Rajan Vaja <rajanv@...inx.com>,
Linux-arm-kernel@...ts.infradead.org
<linux-arm-kernel@...ts.infradead.org>, Linux-kernel@...r.kernel.org
<linux-kernel@...r.kernel.org>, Tejas Patel <tejas.patel@...inx.com>,
Rajan Vaja <rajan.vaja@...inx.com>, Jolly Shah <jolly.shah@...inx.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@...inx.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.
Thanks,
Jolly Shah
Powered by blists - more mailing lists