[ Upstream commit f690a4d7a8f66430662975511c86819dc9965bcc ]
It was reported that RPi3[1] and RPi Zero 2W boards have issues with
the Bluetooth. It turns out that when switching from initial to
operation speed host and device no longer can talk each other because
host uses incorrect UART baud rate.
The UART driver used in this case is amba-pl011. Original fix, see
below Github link[2], was inside pl011 module, but somehow it didn't
look as the right place to fix. Beside that this original rounding
function is not exactly perfect for all possible clock values. So I
deiced to move the hack to the platform which actually need it.
The UART clock is initialised to be as close to the requested
frequency as possible without exceeding it. Now that there is a
clock manager that returns the actual frequencies, an expected
48MHz clock is reported as 47999625. If the requested baud rate
== requested clock/16, there is no headroom and the slight
reduction in actual clock rate results in failure.
If increasing a clock by less than 0.1% changes it from ..999..
to ..000.., round it up.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1188238
[2] ab3f1b3953
Cc: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/20220912081306.24662-1-iivanov@suse.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6c5422851d8be8c7451e968fd2e6da41b6109e17 ]
When testing for a series affecting the VEC, it was discovered that
turning off and on the VEC clock is crashing the system.
It turns out that, when disabling the VEC clock, it's the only child of
the PLLC-per clock which will also get disabled. The source of the crash
is PLLC-per being disabled.
It's likely that some other device might not take a clock reference that
it actually needs, but it's unclear which at this point. Let's make
PLLC-per critical so that we don't have that crash.
Reported-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220926084509.12233-1-maxime@cerno.tech
Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1b24a132eba7a1c19475ba2510ec1c00af3ff914 ]
After commit 31fd9b79dc58 ("ARM: dts: BCM5301X: update CRU block
description") a warning from clk-iproc-pll.c was generated due to a
duplicate PLL name as well as the console stopped working. Upon closer
inspection it became clear that iproc_pll_clk_setup() used the Device
Tree node unit name as an unique identifier as well as a parent name to
parent all clocks under the PLL.
BCM5301X was the first platform on which that got noticed because of the
DT node unit name renaming but the same assumptions hold true for any
user of the iproc_pll_clk_setup() function.
The first 'clock-output-names' property is always guaranteed to be
unique as well as providing the actual desired PLL clock name, so we
utilize that to register the PLL and as a parent name of all children
clock.
Fixes: 5fe225c105 ("clk: iproc: add initial common clock support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rafał Miłecki <rafal@milecki.pl>
Link: https://lore.kernel.org/r/20220905161504.1526-1-f.fainelli@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 35f73cca1cecda0c1f8bb7d8be4ce5cd2d46ae8c ]
The function raspberrypi_fw_get_rate (e.g. used for the recalc_rate
hook) can fail to get the clock rate from the firmware. In this case
we cannot return a signed error value, which would be casted to
unsigned long. Fix this by returning 0 instead.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/20220625083643.4012-1-stefan.wahren@i2se.com
Fixes: 4e85e535e6 ("clk: bcm283x: add driver interfacing with Raspberry Pi's firmware")
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8ca011ef4af48a7af7b15afd8a4a44039dd04cea ]
The driver, once it found a divider, tries to round it up by increasing
the least significant bit of the fractional part by one when the
round_up argument is set and there's a remainder.
However, since it increases the divider it will actually reduce the
clock rate below what we were asking for, leading to issues with
clk_set_min_rate() that will complain that our rounded clock rate is
below the minimum of the rate.
Since the dividers are fairly precise already, let's remove that part so
that we can have clk_set_min_rate() working.
This is effectively a revert of 9c95b32ca0 ("clk: bcm2835: add a round
up ability to the clock divisor").
Fixes: 9c95b32ca0 ("clk: bcm2835: add a round up ability to the clock divisor")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Tested-by: Nicolas Saenz Julienne <nsaenz@kernel.org> # boot and basic functionality
Tested-by: Michael Stapelberg <michael@stapelberg.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210922125419.4125779-3-maxime@cerno.tech
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5517357a4733d7cf7c17fc79d0530cfa47add372 ]
The driver currently tries to pick the closest rate that is lower than
the rate being requested.
This causes an issue with clk_set_min_rate() since it actively checks
for the rounded rate to be above the minimum that was just set.
Let's change the logic a bit to pick the closest rate to the requested
rate, no matter if it's actually higher or lower.
Fixes: 6d18b8adbe ("clk: bcm2835: Support for clock parent selection")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Tested-by: Nicolas Saenz Julienne <nsaenz@kernel.org> # boot and basic functionality
Tested-by: Michael Stapelberg <michael@stapelberg.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210922125419.4125779-2-maxime@cerno.tech
Signed-off-by: Sasha Levin <sashal@kernel.org>
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
drivers/clk/bcm/clk-raspberrypi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Pull clk updates from Stephen Boyd:
"This contains no changes to the core framework. It is a collection of
various clk driver updates.
The biggest driver updates in terms of lines of code is the Allwinner
driver, closely followed by the Qualcomm and Mediatek drivers. All of
those hit high because we add so many lines of clk data. Coming in
fourth place is i.MX which also adds a bunch of clk data. This
accounts for the new driver additions this time around.
Otherwise the patches are lots of little cleanups and fixes for
various clk drivers that have baked in linux-next for a while. I
suppose one highlight or theme is that more clk drivers are being
updated to work as modules, which is interesting to see such critical
SoC infrastructure work as a loadable module.
New Drivers:
- Support qcom SM8150/SM8250 video and display clks
- Support Mediatek MT8167 clks
- Add clock for CRC block found on vf610 SoCs
- Add support for the Renesas R-Car V3U (R8A779A0) SoC
- Add support for the VSP for Resizing clock on Renesas RZ/G1H
- Support Allwinner A100 SoC clks
Removed Drivers:
- Remove i.MX21 clock driver, as i.MX21 platform support is being
dropped
Updates:
- Change how qcom's display port clks work
- Small non-critical fixes for TI clk driver
- Remove various unused variables in clk drivers
- Allow Rockchip clk driver to be a module
- Remove most __clk_lookup() calls in Samsung drivers (yay!)
- Support building i.MX ARMv8 platforms clock driver as module
- Some kerneldoc fixes here and there
- A couple of minor i.MX clk data corrections
- Update audio clock inverter and fdiv2 flag on Amlogic g12
- Make amlogic clk drivers configurable in Kconfig
- Fix Renesas VSP clock names to match corrected hardware
documentation
- Sigma-delta modulation on Allwinner R40
- Various fixes for at91 clk driver
- Use semicolons instead of commas in some places
- Mark some variables const so they can move to RO memory"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (102 commits)
clk: imx8mq: Fix usdhc parents order
clk: qcom: gdsc: Keep RETAIN_FF bit set if gdsc is already on
clk: Restrict CLK_HSDK to ARC_SOC_HSDK
clk: at91: sam9x60: support only two programmable clocks
clk: ingenic: Respect CLK_SET_RATE_PARENT in .round_rate
clk: ingenic: Don't tag custom clocks with CLK_SET_RATE_PARENT
clk: ingenic: Don't use CLK_SET_RATE_GATE for PLL
clk: ingenic: Use readl_poll_timeout instead of custom loop
clk: ingenic: Use to_clk_info() macro for all clocks
clk: bcm2835: add missing release if devm_clk_hw_register fails
clk: at91: clk-sam9x60-pll: remove unused variable
clk: at91: clk-main: update key before writing AT91_CKGR_MOR
clk: at91: remove the checking of parent_name
clk: clk-prima2: fix return value check in prima2_clk_init()
clk: mmp2: Fix the display clock divider base
clk: pxa: Constify static struct clk_ops
clk: baikal-t1: Mark Ethernet PLL as critical
clk: qoriq: modify MAX_PLL_DIV to 32
clk: axi-clkgen: Set power bits for fractional mode
clk: axi-clkgen: Add support for fractional dividers
...
Contrary to previous SoCs, bcm2711 doesn't have a prescaler in the PLL
feedback loop. Bypass it by zeroing fb_prediv_mask when running on
bcm2711.
Note that, since the prediv configuration bits were re-purposed, this
was triggering miscalculations on all clocks hanging from the VPU clock,
notably the aux UART, making its output unintelligible.
Fixes: 42de9ad400 ("clk: bcm2835: Add BCM2711_CLOCK_EMMC2 support")
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/20200730182619.23246-1-nsaenzjulienne@suse.de
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The RaspberryPi4 firmware actually exposes more clocks than are currently
handled by the driver and we will need to change some of them directly
based on the pixel rate for the display related clocks, or the load for the
GPU.
Since the firmware implements DVFS, this rate change can have a number of
side-effects, including adjusting the various PLL voltages or the PLL
parents. The firmware also implements thermal throttling, so even some
thermal pressure can change those parameters behind Linux back.
DVFS is currently implemented on the arm, core, h264, v3d, isp and hevc
clocks, so updating any of them using the MMIO driver (and thus behind the
firmware's back) can lead to troubles, the arm clock obviously being the
most problematic.
In order to make Linux play as nice as possible with those constraints, it
makes sense to rely on the firmware clocks as much as possible. However,
the firmware doesn't seem to provide some equivalents to their MMIO
counterparts, so we can't really replace that driver entirely.
Fortunately, the firmware has an interface to discover the clocks it
exposes.
Let's use it to discover, register the clocks in the clocks framework and
then expose them through the device tree for consumers to use them.
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/438d73962741a8c5f7c689319b7443b930a87fde.1592210452.git-series.maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
