1fe15be1 | 29-Nov-2023 |
Jay Buddhabhatti <jay.buddhabhatti@amd.com> |
drivers: clk: zynqmp: update divider round rate logic
Currently zynqmp divider round rate is considering single parent and calculating rate and parent rate accordingly. But if divider clock flag is
drivers: clk: zynqmp: update divider round rate logic
Currently zynqmp divider round rate is considering single parent and calculating rate and parent rate accordingly. But if divider clock flag is set to SET_RATE_PARENT then its not trying to traverse through all parent rate and not selecting best parent rate from that. So use common divider_round_rate() which is traversing through all clock parents and its rate and calculating proper parent rate.
Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver") Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Link: https://lore.kernel.org/r/20231129112916.23125-3-jay.buddhabhatti@amd.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
30eaf021 | 26-Aug-2022 |
Quanyang Wang <quanyang.wang@windriver.com> |
clk: zynqmp: pll: rectify rate rounding in zynqmp_pll_round_rate
The function zynqmp_pll_round_rate is used to find a most appropriate PLL frequency which the hardware can generate according to the
clk: zynqmp: pll: rectify rate rounding in zynqmp_pll_round_rate
The function zynqmp_pll_round_rate is used to find a most appropriate PLL frequency which the hardware can generate according to the desired frequency. For example, if the desired frequency is 297MHz, considering the limited range from PS_PLL_VCO_MIN (1.5GHz) to PS_PLL_VCO_MAX (3.0GHz) of PLL, zynqmp_pll_round_rate should return 1.872GHz (297MHz * 5).
There are two problems with the current code of zynqmp_pll_round_rate:
1) When the rate is below PS_PLL_VCO_MIN, it can't find a correct rate when the parameter "rate" is an integer multiple of *prate, in other words, if "f" is zero, zynqmp_pll_round_rate won't return a valid frequency which is from PS_PLL_VCO_MIN to PS_PLL_VCO_MAX. For example, *prate is 33MHz and the rate is 660MHz, zynqmp_pll_round_rate will not boost up rate and just return 660MHz, and this will cause clk_calc_new_rates failure since zynqmp_pll_round_rate returns an invalid rate out of its boundaries.
2) Even if the rate is higher than PS_PLL_VCO_MIN, there is still a risk that zynqmp_pll_round_rate returns an invalid rate because the function DIV_ROUND_CLOSEST makes some loss in the fractional part. If the parent clock *prate is 33333333Hz and we want to set the PLL rate to 1.5GHz, this function will return 1499999985Hz by using the formula below: value = *prate * DIV_ROUND_CLOSEST(rate, *prate)). This value is also invalid since it's slightly smaller than PS_PLL_VCO_MIN. because DIV_ROUND_CLOSEST makes some loss in the fractional part.
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Link: https://lore.kernel.org/r/20220826142030.213805-1-quanyang.wang@windriver.com Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
8bdb15cd | 06-Apr-2022 |
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> |
clk: zynqmp: Check the return type zynqmp_pm_query_data
Check the return type of zynqmp_pm_query_data(qdata, ret_payload);
Addresses-Coverity: Event check_return Signed-off-by: Shubhrajyoti Datta <
clk: zynqmp: Check the return type zynqmp_pm_query_data
Check the return type of zynqmp_pm_query_data(qdata, ret_payload);
Addresses-Coverity: Event check_return Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/20220406092211.19017-1-shubhrajyoti.datta@xilinx.com Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
6ab9810c | 18-May-2022 |
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> |
clk: zynqmp: Add a check for NULL pointer
Add a NULL pointer check as clk_hw_get_parent can return NULL.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.
clk: zynqmp: Add a check for NULL pointer
Add a NULL pointer check as clk_hw_get_parent can return NULL.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/20220518055314.2486-1-shubhrajyoti.datta@xilinx.com Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
acc1c732 | 10-May-2022 |
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> |
clk: zynqmp: Replaced strncpy() with strscpy()
Replaced strncpy() with strscpy() as the clock names are supposed to be NULL terminated.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.
clk: zynqmp: Replaced strncpy() with strscpy()
Replaced strncpy() with strscpy() as the clock names are supposed to be NULL terminated.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/20220510070154.29528-2-shubhrajyoti.datta@xilinx.com Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
dd80fb2d | 10-May-2022 |
Ian Nam <young.kwan.nam@xilinx.com> |
clk: zynqmp: Fix stack-out-of-bounds in strncpy`
"BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68"
Linux-ATF interface is using 16 bytes of SMC payload. In case clock name is longer than 15 by
clk: zynqmp: Fix stack-out-of-bounds in strncpy`
"BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68"
Linux-ATF interface is using 16 bytes of SMC payload. In case clock name is longer than 15 bytes, string terminated NULL character will not be received by Linux. Add explicit NULL character at last byte to fix issues when clock name is longer.
This fixes below bug reported by KASAN:
================================================================== BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68 Read of size 1 at addr ffff0008c89a7410 by task swapper/0/1
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.0-00396-g81ef9e7-dirty #3 Hardware name: Xilinx Versal vck190 Eval board revA (QSPI) (DT) Call trace: dump_backtrace+0x0/0x1e8 show_stack+0x14/0x20 dump_stack+0xd4/0x108 print_address_description.isra.0+0xbc/0x37c __kasan_report+0x144/0x198 kasan_report+0xc/0x18 __asan_load1+0x5c/0x68 strncpy+0x30/0x68 zynqmp_clock_probe+0x238/0x7b8 platform_drv_probe+0x6c/0xc8 really_probe+0x14c/0x418 driver_probe_device+0x74/0x130 __device_attach_driver+0xc4/0xe8 bus_for_each_drv+0xec/0x150 __device_attach+0x160/0x1d8 device_initial_probe+0x10/0x18 bus_probe_device+0xe0/0xf0 device_add+0x528/0x950 of_device_add+0x5c/0x80 of_platform_device_create_pdata+0x120/0x168 of_platform_bus_create+0x244/0x4e0 of_platform_populate+0x50/0xe8 zynqmp_firmware_probe+0x370/0x3a8 platform_drv_probe+0x6c/0xc8 really_probe+0x14c/0x418 driver_probe_device+0x74/0x130 device_driver_attach+0x94/0xa0 __driver_attach+0x70/0x108 bus_for_each_dev+0xe4/0x158 driver_attach+0x30/0x40 bus_add_driver+0x21c/0x2b8 driver_register+0xbc/0x1d0 __platform_driver_register+0x7c/0x88 zynqmp_firmware_driver_init+0x1c/0x24 do_one_initcall+0xa4/0x234 kernel_init_freeable+0x1b0/0x24c kernel_init+0x10/0x110 ret_from_fork+0x10/0x18
The buggy address belongs to the page: page:ffff0008f9be1c88 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 raw: 0008d00000000000 ffff0008f9be1c90 ffff0008f9be1c90 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff page dumped because: kasan: bad access detected
addr ffff0008c89a7410 is located in stack of task swapper/0/1 at offset 112 in frame: zynqmp_clock_probe+0x0/0x7b8
this frame has 3 objects: [32, 44) 'response' [64, 80) 'ret_payload' [96, 112) 'name'
Memory state around the buggy address: ffff0008c89a7300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff0008c89a7380: 00 00 00 00 f1 f1 f1 f1 00 04 f2 f2 00 00 f2 f2 >ffff0008c89a7400: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffff0008c89a7480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff0008c89a7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ==================================================================
Signed-off-by: Ian Nam <young.kwan.nam@xilinx.com> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/20220510070154.29528-3-shubhrajyoti.datta@xilinx.com Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
6e1cc688 | 23-Aug-2021 |
Michal Simek <michal.simek@xilinx.com> |
clk: zynqmp: Fix kernel-doc format
Align structure and function names with definitions.
Issues are reported by kernel-doc script as: drivers/clk/zynqmp/clk-gate-zynqmp.c:24: warning: expecting prot
clk: zynqmp: Fix kernel-doc format
Align structure and function names with definitions.
Issues are reported by kernel-doc script as: drivers/clk/zynqmp/clk-gate-zynqmp.c:24: warning: expecting prototype for struct clk_gate. Prototype was for struct zynqmp_clk_gate instead drivers/clk/zynqmp/clk-gate-zynqmp.c:75: warning: expecting prototype for zynqmp_clk_gate_is_enable(). Prototype was for zynqmp_clk_gate_is_enabled() instead
Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/26526e144296373b2c75e75865dd023158f9bfc7.1629718424.git.michal.simek@xilinx.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
e7296d16 | 18-Aug-2021 |
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> |
clk: zynqmp: Fix a memory leak
Fix a memory leak of mux.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/20210818065929.12835-3-shubhrajyoti.datta@
clk: zynqmp: Fix a memory leak
Fix a memory leak of mux.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Link: https://lore.kernel.org/r/20210818065929.12835-3-shubhrajyoti.datta@xilinx.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
03aea91b | 28-Jun-2021 |
Rajan Vaja <rajan.vaja@xilinx.com> |
clk: zynqmp: Handle divider specific read only flag
Add support for divider specific read only CCF flag (CLK_DIVIDER_READ_ONLY).
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Link: https://lore
clk: zynqmp: Handle divider specific read only flag
Add support for divider specific read only CCF flag (CLK_DIVIDER_READ_ONLY).
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Link: https://lore.kernel.org/r/20210628070122.26217-5-rajan.vaja@xilinx.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
54530ed1 | 28-Jun-2021 |
Rajan Vaja <rajan.vaja@xilinx.com> |
clk: zynqmp: Use firmware specific mux clock flags
Use ZynqMP specific mux clock flags instead of using CCF flags.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Link: https://lore.kernel.org/r/
clk: zynqmp: Use firmware specific mux clock flags
Use ZynqMP specific mux clock flags instead of using CCF flags.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Link: https://lore.kernel.org/r/20210628070122.26217-4-rajan.vaja@xilinx.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
1b09c308 | 28-Jun-2021 |
Rajan Vaja <rajan.vaja@xilinx.com> |
clk: zynqmp: Use firmware specific divider clock flags
Use ZynqMP specific divider clock flags instead of using CCF flags.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Link: https://lore.kerne
clk: zynqmp: Use firmware specific divider clock flags
Use ZynqMP specific divider clock flags instead of using CCF flags.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Link: https://lore.kernel.org/r/20210628070122.26217-3-rajan.vaja@xilinx.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
610a5d83 | 28-Jun-2021 |
Rajan Vaja <rajan.vaja@xilinx.com> |
clk: zynqmp: Use firmware specific common clock flags
Currently firmware passes CCF specific flags to ZynqMP clock driver. So firmware needs to be updated if CCF flags are changed. The firmware shou
clk: zynqmp: Use firmware specific common clock flags
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> Link: https://lore.kernel.org/r/20210628070122.26217-2-rajan.vaja@xilinx.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
b9ec1c1f | 01-May-2021 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
clk: zynqmp: pll: Remove some dead code
'clk_hw_set_rate_range()' does not return any error code and 'ret' is known to be 0 at this point, so this message can never be displayed.
Remove it.
Fixes:
clk: zynqmp: pll: Remove some dead code
'clk_hw_set_rate_range()' does not return any error code and 'ret' is known to be 0 at this point, so this message can never be displayed.
Remove it.
Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/71a9fed5f762a71248b8ac73c0a15af82f3ce1e2.1619867987.git.christophe.jaillet@wanadoo.fr Reviewed-by: Michael Tretter <m.tretter@pengutronix.de> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
394cdb69 | 06-Apr-2021 |
Quanyang Wang <quanyang.wang@windriver.com> |
clk: zynqmp: pll: add set_pll_mode to check condition in zynqmp_pll_enable
If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever, we shouldn't skip invoking PM_CLOCK_ENABLE fn even though t
clk: zynqmp: pll: add set_pll_mode to check condition in zynqmp_pll_enable
If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever, we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this pll has been enabled. In ATF implementation, it will only assign the mode to the variable (struct pm_pll *)pll->mode when handling IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force ATF send request to PWU to set the pll mode to PLL's register.
There is a scenario that happens in enabling VPLL_INT(clk_id:96): 1) VPLL_INT has been enabled during booting. 2) A driver calls clk_set_rate and according to the rate, the VPLL_INT should be set to FRAC mode. Then zynqmp_pll_set_mode is called to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point ATF just stores the mode to a variable. 3) This driver calls clk_prepare_enable and zynqmp_pll_enable is called to try to enable VPLL_INT pll. Because of 1), the function zynqmp_pll_enable just returns without doing anything after checking that this pll has been enabled.
In the scenario above, the pll mode of VPLL_INT will never be set successfully. So adding set_pll_mode to check condition to fix it.
Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver") Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20210406153131.601701-1-quanyang.wang@windriver.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
d7fd3f9f | 06-Apr-2021 |
Quanyang Wang <quanyang.wang@windriver.com> |
clk: zynqmp: move zynqmp_pll_set_mode out of round_rate callback
The round_rate callback should only perform rate calculation and not involve calling zynqmp_pll_set_mode to change the pll mode. So l
clk: zynqmp: move zynqmp_pll_set_mode out of round_rate callback
The round_rate callback should only perform rate calculation and not involve calling zynqmp_pll_set_mode to change the pll mode. So let's move zynqmp_pll_set_mode out of round_rate and to set_rate callback.
Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver") Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Link: https://lore.kernel.org/r/20210406154015.602779-1-quanyang.wang@windriver.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
21f23753 | 22-Mar-2021 |
Punit Agrawal <punit1.agrawal@toshiba.co.jp> |
clk: zynqmp: Drop dependency on ARCH_ZYNQMP
The clock driver depends on ZYNQMP_FIRMWARE which in turn depends on ARCH_ZYNQMP. Simplify the Kconfig by dropping the redundant dependency on ARCH_ZYNQMP
clk: zynqmp: Drop dependency on ARCH_ZYNQMP
The clock driver depends on ZYNQMP_FIRMWARE which in turn depends on ARCH_ZYNQMP. Simplify the Kconfig by dropping the redundant dependency on ARCH_ZYNQMP as it'll be applied transitively via ZYNQMP_FIRMWARE.
Signed-off-by: Punit Agrawal <punit1.agrawal@toshiba.co.jp> Link: https://lore.kernel.org/r/20210322061754.1065367-3-punit1.agrawal@toshiba.co.jp Reviewed-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|