summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-10-07clk: at91: select parent if main oscillator or bypass is enabledEugen Hristev1-3/+7
[ Upstream commit 69a6bcde7fd3fe6f3268ce26f31d9d9378384c98 ] Selecting the right parent for the main clock is done using only main oscillator enabled bit. In case we have this oscillator bypassed by an external signal (no driving on the XOUT line), we still use external clock, but with BYPASS bit set. So, in this case we must select the same parent as before. Create a macro that will select the right parent considering both bits from the MOR register. Use this macro when looking for the right parent. Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Link: https://lkml.kernel.org/r/1568042692-11784-2-git-send-email-eugen.hristev@microchip.com Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07mailbox: mediatek: cmdq: clear the event in cmdq initial flowBibby Hsieh1-0/+5
[ Upstream commit 6058f11870b8e6d4f5cc7b591097c00bf69a000d ] GCE hardware stored event information in own internal sysram, if the initial value in those sysram is not zero value it will cause a situation that gce can wait the event immediately after client ask gce to wait event but not really trigger the corresponding hardware. In order to make sure that the wait event function is exactly correct, we need to clear the sysram value in cmdq initial flow. Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07pinctrl: meson-gxbb: Fix wrong pinning definition for uart_cOtto Meier1-6/+6
[ Upstream commit cb0438e4436085d89706b5ccfce4d5da531253de ] Hi i tried to use the uart_C of the the odroid-c2. I enabled it in the dts file. During boot it crashed when the the sdcard slot is addressed. After long search in the net i found this: https://forum.odroid.com/viewtopic.php?f=139&t=25371&p=194370&hilit=uart_C#p177856 After changing the pin definitions accordingly erverything works. Uart_c is functioning and sdcard ist working. Fixes: 6db0f3a8a04e46 ("pinctrl: amlogic: gxbb: add more UART pins") Signed-off-by: Otto Meier <gf435@gmx.net> Link: https://lore.kernel.org/r/1cc32a18-464d-5531-7a1c-084390e2ecb1@gmx.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: qcom: gcc-sdm845: Use floor ops for sdcc clksStephen Boyd1-2/+2
[ Upstream commit 5e4b7e82d497580bc430576c4c9bce157dd72512 ] Some MMC cards fail to enumerate properly when inserted into an MMC slot on sdm845 devices. This is because the clk ops for qcom clks round the frequency up to the nearest rate instead of down to the nearest rate. For example, the MMC driver requests a frequency of 52MHz from clk_set_rate() but the qcom implementation for these clks rounds 52MHz up to the next supported frequency of 100MHz. The MMC driver could be modified to request clk rate ranges but for now we can fix this in the clk driver by changing the rounding policy for this clk to be round down instead of round up. Fixes: 06391eddb60a ("clk: qcom: Add Global Clock controller (GCC) driver for SDM845") Reported-by: Douglas Anderson <dianders@chromium.org> Cc: Taniya Das <tdas@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lkml.kernel.org/r/20190830195142.103564-1-swboyd@chromium.org Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amdgpu/si: fix ASIC testsJean Delvare1-3/+3
[ Upstream commit 77efe48a729588527afb4d5811b9e0acb29f5e51 ] Comparing adev->family with CHIP constants is not correct. adev->family can only be compared with AMDGPU_FAMILY constants and adev->asic_type is the struct member to compare with CHIP constants. They are separate identification spaces. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Cc: Ken Wang <Qingqing.Wang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: fix trigger not generated for freesyncYogesh Mohan Marimuthu1-0/+3
[ Upstream commit 1e7f100ce8c0640634b794604880d9204480c9f1 ] [Why] In newer hardware MANUAL_FLOW_CONTROL is not a trigger bit. Due to this front porch is fixed and in these hardware freesync does not work. [How] Change the programming to generate a pulse so that the event will be triggered, front porch will be cut short and freesync will work. Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: fix MPO HUBP underflow with Scatter GatherZi Yu Liao1-0/+3
[ Upstream commit 89cb5614736b9b5d3b833ca2237d10da6b4b0395 ] [why] With Scatter Gather enabled, HUBP underflows during MPO enabled video playback. hubp_init has a register write that fixes this problem, but the register is cleared when HUBP gets power gated. [how] Make a call to hubp_init during enable_plane, so that the fix can be applied after HUBP powers back on again. Signed-off-by: Zi Yu Liao <ziyu.liao@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/powerpaly: fix navi series custom peak level value errorKevin Wang1-0/+4
[ Upstream commit 706feb26f890e1b8297b5d14975160de361edf4f ] fix other navi asic set peak performance level error. because the navi10_ppt.c will handle navi12 14 asic, it will use navi10 peak value to set other asic, it is not correct. after patch: only navi10 use custom peak value, other asic will used default value. Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: support spdifCharlene Liu2-11/+10
[ Upstream commit b5a41620bb88efb9fb31a4fa5e652e3d5bead7d4 ] [Description] port spdif fix to staging: spdif hardwired to afmt inst 1. spdif func pointer spdif resource allocation (reserve last audio endpoint for spdif only) Signed-off-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: renesas: cpg-mssr: Set GENPD_FLAG_ALWAYS_ON for clock domainGeert Uytterhoeven1-1/+2
[ Upstream commit f787216f33ce5b5a2567766398f44ab62157114c ] The CPG/MSSR Clock Domain driver does not implement the generic_pm_domain.power_{on,off}() callbacks, as the domain itself cannot be powered down. Hence the domain should be marked as always-on by setting the GENPD_FLAG_ALWAYS_ON flag, to prevent the core PM Domain code from considering it for power-off, and doing unnessary processing. Note that this only affects RZ/A2 SoCs. On R-Car Gen2 and Gen3 SoCs, the R-Car SYSC driver handles Clock Domain creation, and offloads only device attachment/detachment to the CPG/MSSR driver. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: renesas: mstp: Set GENPD_FLAG_ALWAYS_ON for clock domainGeert Uytterhoeven1-1/+2
[ Upstream commit a459a184c978ca9ad538aab93aafdde873953f30 ] The CPG/MSTP Clock Domain driver does not implement the generic_pm_domain.power_{on,off}() callbacks, as the domain itself cannot be powered down. Hence the domain should be marked as always-on by setting the GENPD_FLAG_ALWAYS_ON flag, to prevent the core PM Domain code from considering it for power-off, and doing unnessary processing. This also gets rid of a boot warning when the Clock Domain contains an IRQ-safe device, e.g. on RZ/A1: sh_mtu2 fcff0000.timer: PM domain cpg_clocks will not be powered off Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07pinctrl: amd: disable spurious-firing GPIO IRQsDaniel Drake1-1/+11
[ Upstream commit d21b8adbd475dba19ac2086d3306327b4a297418 ] When cold-booting Asus X434DA, GPIO 7 is found to be already configured as an interrupt, and the GPIO level is found to be in a state that causes the interrupt to fire. As soon as pinctrl-amd probes, this interrupt fires and invokes amd_gpio_irq_handler(). The IRQ is acked, but no GPIO-IRQ handler was invoked, so the GPIO level being unchanged just causes another interrupt to fire again immediately after. This results in an interrupt storm causing this platform to hang during boot, right after pinctrl-amd is probed. Detect this situation and disable the GPIO interrupt when this happens. This enables the affected platform to boot as normal. GPIO 7 actually is the I2C touchpad interrupt line, and later on, i2c-multitouch loads and re-enables this interrupt when it is ready to handle it. Instead of this approach, I considered disabling all GPIO interrupts at probe time, however that seems a little risky, and I also confirmed that Windows does not seem to have this behaviour: the same 41 GPIO IRQs are enabled under both Linux and Windows, which is a far larger collection than the GPIOs referenced by the DSDT on this platform. Signed-off-by: Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/r/20190814090540.7152-1-drake@endlessm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/nouveau/volt: Fix for some cards having 0 maximum voltageMark Menzynski1-0/+2
[ Upstream commit a1af2afbd244089560794c260b2d4326a86e39b6 ] Some, mostly Fermi, vbioses appear to have zero max voltage. That causes Nouveau to not parse voltage entries, thus users not being able to set higher clocks. When changing this value Nvidia driver still appeared to ignore it, and I wasn't able to find out why, thus the code is ignoring the value if it is zero. CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Mark Menzynski <mmenzyns@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/nouveau/kms/tu102-: disable input lut when input is already FP16Ben Skeggs1-1/+3
[ Upstream commit 1e339ab2ac3c769c1b06b9fb7d532f8495ebc56d ] On Turing, an input LUT is required to transform inputs in fixed-point formats to FP16 for the internal display pipe. We provide an identity mapping whenever a window is enabled for this reason. HW has error checks to ensure when the input is already FP16, that the input LUT is also disabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amdgpu/sdma5: fix number of sdma5 trap irq types for navi1xXiaojie Yuan1-1/+2
[ Upstream commit 9e48495017342c5d445b25eedd86d6fd884a6496 ] v2: set num_types based on num_instances navi1x has 2 sdma engines but commit "e7b58d03b678 drm/amdgpu: reorganize sdma v4 code to support more instances" changes the max number of sdma irq types (AMDGPU_SDMA_IRQ_LAST) from 2 to 8 which causes amdgpu_irq_gpu_reset_resume_helper() to recover irq of sdma engines with following logic: (enable irq for sdma0) * 1 time (enable irq for sdma1) * 1 time (disable irq for sdma1) * 6 times as a result, after gpu reset, interrupt for sdma1 is lost. Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07vfio_pci: Restore original state on releasehexin1-4/+13
[ Upstream commit 92c8026854c25093946e0d7fe536fd9eac440f06 ] vfio_pci_enable() saves the device's initial configuration information with the intent that it is restored in vfio_pci_disable(). However, the commit referenced in Fixes: below replaced the call to __pci_reset_function_locked(), which is not wrapped in a state save and restore, with pci_try_reset_function(), which overwrites the restored device state with the current state before applying it to the device. Reinstate use of __pci_reset_function_locked() to return to the desired behavior. Fixes: 890ed578df82 ("vfio-pci: Use pci "try" reset interface") Signed-off-by: hexin <hexin15@baidu.com> Signed-off-by: Liu Qi <liuqi16@baidu.com> Signed-off-by: Zhang Yu <zhangyu31@baidu.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07pinctrl: tegra: Fix write barrier placement in pmx_writelSowjanya Komatineni1-1/+3
[ Upstream commit c2cf351eba2ff6002ce8eb178452219d2521e38e ] pmx_writel uses writel which inserts write barrier before the register write. This patch has fix to replace writel with writel_relaxed followed by a readback and memory barrier to ensure write operation is completed for successful pinctrl change. Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1565984527-5272-2-git-send-email-skomatineni@nvidia.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sunxi: Don't call clk_hw_get_name() on a hw that isn't registeredStephen Boyd1-2/+3
[ Upstream commit a7b85ad25a97cf897b4819a121655c483d86156f ] The implementation of clk_hw_get_name() relies on the clk_core associated with the clk_hw pointer existing. If of_clk_hw_register() fails, there isn't a clk_core created yet, so calling clk_hw_get_name() here fails. Extract the name first so we can print it later. Fixes: 1d80c14248d6 ("clk: sunxi-ng: Add common infrastructure") Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: zx296718: Don't reference clk_init_data after registrationStephen Boyd1-60/+49
[ Upstream commit 1a4549c150e27dbc3aea762e879a88209df6d1a5 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Jun Nie <jun.nie@linaro.org> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190815160020.183334-3-sboyd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sprd: Don't reference clk_init_data after registrationStephen Boyd1-2/+3
[ Upstream commit f6c90df8e7e33c3dc33d4d7471bc42c232b0510e ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Chunyan Zhang <zhang.chunyan@linaro.org> Cc: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-8-sboyd@kernel.org Acked-by: Baolin Wang <baolin.wang@linaro.org> Acked-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: meson: axg-audio: Don't reference clk_init_data after registrationStephen Boyd1-2/+5
[ Upstream commit 1610dd79d0f6202c5c1a91122255fa598679c13a ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-4-sboyd@kernel.org Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sirf: Don't reference clk_init_data after registrationStephen Boyd1-4/+8
[ Upstream commit af55dadfbce35b4f4c6247244ce3e44b2e242b84 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Guo Zeng <Guo.Zeng@csr.com> Cc: Barry Song <Baohua.Song@csr.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-6-sboyd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: actions: Don't reference clk_init_data after registrationStephen Boyd1-2/+3
[ Upstream commit cf9ec1fc6d7cceb73e7f1efd079d2eae173fdf57 ] A future patch is going to change semantics of clk_register() so that clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid referencing this member here so that we don't run into NULL pointer exceptions. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20190731193517.237136-2-sboyd@kernel.org [sboyd@kernel.org: Move name to after checking for error or NULL hw] Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: Register VUPDATE_NO_LOCK interrupts for DCN2Nicholas Kazlauskas1-10/+18
[ Upstream commit e40837afb9b011757e17e9f71d97853ca574bcff ] [Why] These are needed to send back DRM vblank events in the case where VRR is on. Without the interrupt enabled we're deferring the events into the vblank queue and userspace is left waiting forever to get back the events they need. Found using igt@kms_vrr - the test fails immediately due to vblank timeout. [How] Register them the same way we're handling it for DCN1. This fixes igt@kms_vrr for DCN2. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <David.Francis@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: reprogram VM config when system resumeLewis Huang1-0/+8
[ Upstream commit e5382701c3520b3ed66169a6e4aa6ce5df8c56e0 ] [Why] The vm config will be clear to 0 when system enter S4. It will cause hubbub didn't know how to fetch data when system resume. The flip always pending because earliest_inuse_address and request_address are different. [How] Reprogram VM config when system resume Signed-off-by: Lewis Huang <Lewis.Huang@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Eric Yang <eric.yang2@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: Fix frames_to_insert mathBayan Zabihiyan1-10/+17
[ Upstream commit a463b263032f7c98c5912207db43be1aa34a6438 ] [Why] The math on deciding on how many "frames to insert" sometimes sent us over the max refresh rate. Also integer overflow can occur if we have high refresh rates. [How] Instead of clipping the frame duration such that it doesn’t go below the min, just remove a frame from the number of frames to insert. + Use unsigned long long for intermediate calculations to prevent integer overflow. Signed-off-by: Bayan Zabihiyan <bayan.zabihiyan@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: fix issue where 252-255 values are clippedAnthony Koo1-1/+2
[ Upstream commit 1cbcfc975164f397b449efb17f59d81a703090db ] [Why] When endpoint is at the boundary of a region, such as at 2^0=1 we find that the last segment has a sharp slope and some points are clipped at the top. [How] If end point is 1, which is exactly at the 2^0 region boundary, we need to program an additional region beyond this point. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: sunxi-ng: v3s: add missing clock slices for MMC2 module clocksIcenowy Zheng1-0/+3
[ Upstream commit 720099603d1f62e37b789366d7e89824b009ca28 ] The MMC2 clock slices are currently not defined in V3s CCU driver, which makes MMC2 not working. Fix this issue. Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: ingenic/jz4740: Fix "pll half" divider not read/written properlyPaul Cercueil1-1/+8
[ Upstream commit 568b9de48d80bcf1a92e2c4fa67651abbb8ebfe2 ] The code was setting the bit 21 of the CPCCR register to use a divider of 2 for the "pll half" clock, and clearing the bit to use a divider of 1. This is the opposite of how this register field works: a cleared bit means that the /2 divider is used, and a set bit means that the divider is 1. Restore the correct behaviour using the newly introduced .div_table field. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lkml.kernel.org/r/20190701113606.4130-1-paul@crapouillou.net Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: qoriq: Fix -Wunused-const-variableNathan Huckleberry1-1/+1
[ Upstream commit a95fb581b144b5e73da382eaedb2e32027610597 ] drivers/clk/clk-qoriq.c:138:38: warning: unused variable 'p5020_cmux_grp1' [-Wunused-const-variable] static const struct clockgen_muxinfo p5020_cmux_grp1 drivers/clk/clk-qoriq.c:146:38: warning: unused variable 'p5020_cmux_grp2' [-Wunused-const-variable] static const struct clockgen_muxinfo p5020_cmux_grp2 In the definition of the p5020 chip, the p2041 chip's info was used instead. The p5020 and p2041 chips have different info. This is most likely a typo. Link: https://github.com/ClangBuiltLinux/linux/issues/525 Cc: clang-built-linux@googlegroups.com Signed-off-by: Nathan Huckleberry <nhuck@google.com> Link: https://lkml.kernel.org/r/20190627220642.78575-1-nhuck@google.com Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Scott Wood <oss@buserror.net> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07ipmi_si: Only schedule continuously in the thread in maintenance modeCorey Minyard1-5/+19
[ Upstream commit 340ff31ab00bca5c15915e70ad9ada3030c98cf8 ] ipmi_thread() uses back-to-back schedule() to poll for command completion which, on some machines, can push up CPU consumption and heavily tax the scheduler locks leading to noticeable overall performance degradation. This was originally added so firmware updates through IPMI would complete in a timely manner. But we can't kill the scheduler locks for that one use case. Instead, only run schedule() continuously in maintenance mode, where firmware updates should run. Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07pinctrl: stmfx: update pinconf settingsAlexandre Torgue1-12/+12
[ Upstream commit a502b343ebd0eab38f3cb33fbb84011847cf5aac ] According to the following tab (coming from STMFX datasheet), updates have to done in stmfx_pinconf_set function: -"type" has to be set when "bias" is configured as "pull-up or pull-down" -PIN_CONFIG_DRIVE_PUSH_PULL should only be used when gpio is configured as output. There is so no need to check direction. DIR | TYPE | PUPD | MFX GPIO configuration ----|------|------|--------------------------------------------------- 1 | 1 | 1 | OUTPUT open drain with internal pull-up resistor ----|------|------|--------------------------------------------------- 1 | 1 | 0 | OUTPUT open drain with internal pull-down resistor ----|------|------|--------------------------------------------------- 1 | 0 | 0/1 | OUTPUT push pull no pull ----|------|------|--------------------------------------------------- 0 | 1 | 1 | INPUT with internal pull-up resistor ----|------|------|--------------------------------------------------- 0 | 1 | 0 | INPUT with internal pull-down resistor ----|------|------|--------------------------------------------------- 0 | 0 | 1 | INPUT floating ----|------|------|--------------------------------------------------- 0 | 0 | 0 | analog (GPIO not used, default setting) Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/1564053416-32192-1-git-send-email-amelie.delaunay@st.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07PCI: rpaphp: Avoid a sometimes-uninitialized warningNathan Chancellor1-11/+7
[ Upstream commit 0df3e42167caaf9f8c7b64de3da40a459979afe8 ] When building with -Wsometimes-uninitialized, clang warns: drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is used uninitialized whenever 'for' loop exits because its condition is false [-Wsometimes-uninitialized] for (j = 0; j < entries; j++) { ^~~~~~~~~~~ drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs here if (fndit) ^~~~~ drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if it is always true for (j = 0; j < entries; j++) { ^~~~~~~~~~~ drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable 'fndit' to silence this warning int j, fndit; ^ = 0 fndit is only used to gate a sprintf call, which can be moved into the loop to simplify the code and eliminate the local variable, which will fix this warning. Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search ibm,drc-info property") Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com> Acked-by: Joel Savitz <jsavitz@redhat.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://github.com/ClangBuiltLinux/linux/issues/504 Link: https://lore.kernel.org/r/20190603221157.58502-1-natechancellor@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07clk: imx8mq: Mark AHB clock as criticalAbel Vesa1-1/+2
[ Upstream commit 9b9c60bed562c3718ae324a86f3f30a4ff983cf8 ] Initially, the TMU_ROOT clock was marked as critical, which automatically made the AHB clock to stay always on. Since the TMU_ROOT clock is not marked as critical anymore, following commit: "clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT" all the clocks that derive from ipg_root clock (and implicitly ahb clock) would also have to enable, along with their own gate, the AHB clock. But considering that AHB is actually a bus that has to be always on, we mark it as critical in the clock provider driver and then all the clocks that derive from it can be controlled through the dedicated per IP gate which follows after the ipg_root clock. Signed-off-by: Abel Vesa <abel.vesa@nxp.com> Tested-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07gpu: drm: radeon: Fix a possible null-pointer dereference in ↵Jia-Ju Bai1-1/+1
radeon_connector_set_property() [ Upstream commit f3eb9b8f67bc28783eddc142ad805ebdc53d6339 ] In radeon_connector_set_property(), there is an if statement on line 743 to check whether connector->encoder is NULL: if (connector->encoder) When connector->encoder is NULL, it is used on line 755: if (connector->encoder->crtc) Thus, a possible null-pointer dereference may occur. To fix this bug, connector->encoder is checked before being used. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/radeon: Fix EEH during kexecKyleMahlkuch1-0/+8
[ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ] During kexec some adapters hit an EEH since they are not properly shut down in the radeon_pci_shutdown() function. Adding radeon_suspend_kms() fixes this issue. Signed-off-by: KyleMahlkuch <kmahlkuc@linux.vnet.ibm.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: Use proper enum conversion functionsNathan Chancellor1-2/+2
[ Upstream commit d196bbbc28fab82624f7686f8b0da8e8644b6e6a ] clang warns: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8: warning: implicit conversion from enumeration type 'enum smu_clk_type' to different enumeration type 'enum amd_pp_clock_type' [-Wenum-conversion] dc_to_smu_clock_type(clk_type), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:421:14: warning: implicit conversion from enumeration type 'enum amd_pp_clock_type' to different enumeration type 'enum smu_clk_type' [-Wenum-conversion] dc_to_pp_clock_type(clk_type), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are functions to properly convert between all of these types, use them so there are no longer any warnings. Fixes: a43913ea50a5 ("drm/amd/powerplay: add function get_clock_by_type_with_latency for navi10") Fixes: e5e4e22391c2 ("drm/amd/powerplay: add interface to get clock by type with latency for display (v2)") Link: https://github.com/ClangBuiltLinux/linux/issues/586 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amdgpu: Fix hard hang for S/G display BOs.Andrey Grodzovsky2-5/+5
[ Upstream commit e4c4073b0139d055d43a9568690fc560aab4fa5c ] HW requires for caching to be unset for scanout BO mappings when the BO placement is in GTT memory. Usually the flag to unset is passed from user mode but for FB mode this was missing. v2: Keep all BO placement logic in amdgpu_display_supported_domains Suggested-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Shirish S <shirish.s@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/rockchip: Check for fast link training before enabling psrSean Paul1-4/+5
[ Upstream commit ad309284a52be47c8b3126c9376358bf381861bc ] Once we start shutting off the link during PSR, we're going to want fast training to work. If the display doesn't support fast training, don't enable psr. Changes in v2: - None Changes in v3: - None Changes in v4: - None Changes in v5: - None Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-3-sean@poorly.run Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-2-sean@poorly.run Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-9-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-8-sean@poorly.run Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-8-sean@poorly.run Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/panel: check failure cases in the probe funcNavid Emamdoost1-0/+13
[ Upstream commit afd6d4f5a52c16e1483328ac074abb1cde92c29f ] The following function calls may fail and return NULL, so the null check is added. of_graph_get_next_endpoint of_graph_get_remote_port_parent of_graph_get_remote_port Update: Thanks to Sam Ravnborg, for suggession on the use of goto to avoid leaking endpoint. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190724195534.9303-1-navid.emamdoost@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/bridge: sii902x: fix missing reference to mclk clockOlivier Moysan1-0/+1
[ Upstream commit 365d28c92f8cd3d3860f8dd057a8c136e24b3698 ] Add devm_clk_get call to retrieve reference to master clock. Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Reviewed-by: Jyri Sarha <jsarha@ti.com> Acked-by: Andrzej Hajda <a.hajda@samsung.com Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1563811560-29589-2-git-send-email-olivier.moysan@st.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/stm: attach gem fence to atomic stateAhmad Fatoum1-0/+2
[ Upstream commit 8fabc9c3109a71b3577959a05408153ae69ccd8d ] To properly synchronize with other devices the fence from the GEM object backing the framebuffer needs to be attached to the atomic state, so the commit work can wait on fence signaling. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190712084228.8338-1-l.stach@pengutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/tinydrm/Kconfig: drivers: Select BACKLIGHT_CLASS_DEVICENoralf Trønnes1-4/+4
[ Upstream commit 3389669ac5ea598562673c04971d7bb0fab0e9f1 ] The mipi_dbi helper is missing a dependency on DRM_KMS_HELPER and putting that in revealed this problem: drivers/video/fbdev/Kconfig:12:error: recursive dependency detected! drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:75: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:69: symbol DRM_KMS_HELPER is selected by TINYDRM_MIPI_DBI drivers/gpu/drm/tinydrm/Kconfig:11: symbol TINYDRM_MIPI_DBI is selected by TINYDRM_HX8357D drivers/gpu/drm/tinydrm/Kconfig:15: symbol TINYDRM_HX8357D depends on BACKLIGHT_CLASS_DEVICE drivers/video/backlight/Kconfig:144: symbol BACKLIGHT_CLASS_DEVICE is selected by FB_BACKLIGHT drivers/video/fbdev/Kconfig:187: symbol FB_BACKLIGHT depends on FB A symbol that selects DRM_KMS_HELPER can not depend on BACKLIGHT_CLASS_DEVICE. The reason for this is that DRM_KMS_FB_HELPER selects FB instead of depending on it. The tinydrm drivers have somehow gotten away with depending on BACKLIGHT_CLASS_DEVICE because DRM_TINYDRM selects DRM_KMS_HELPER and the drivers depend on that symbol. An audit shows that all DRM drivers that select DRM_KMS_HELPER and use BACKLIGHT_CLASS_DEVICE, selects it: DRM_TILCDC, DRM_GMA500, DRM_SHMOBILE, DRM_NOUVEAU, DRM_FSL_DCU, DRM_I915, DRM_RADEON, DRM_AMDGPU, DRM_PARADE_PS8622 Documentation/kbuild/kconfig-language.txt has a note regarding select: 1. 'select should be used with care since it doesn't visit dependencies.' This is not a problem since BACKLIGHT_CLASS_DEVICE doesn't have any dependencies. 2. 'In general use select only for non-visible symbols' BACKLIGHT_CLASS_DEVICE is user visible. The real solution to this would be to have DRM_KMS_FB_HELPER depend on the user visible symbol FB. That is a can of worms I'm not willing to tackle. I fear that such a change will result in me handling difficult fallouts for the next weeks. So I'm following DRM suite here. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-7-noralf@tronnes.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07video: ssd1307fb: Start page range at page_offsetMarko Kohtala1-1/+1
[ Upstream commit dd9782834dd9dde3624ff1acea8859f3d3e792d4 ] The page_offset was only applied to the end of the page range. This caused the display updates to cause a scrolling effect on the display because the amount of data written to the display did not match the range display expected. Fixes: 301bc0675b67 ("video: ssd1307fb: Make use of horizontal addressing mode") Signed-off-by: Marko Kohtala <marko.kohtala@okoko.fi> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Michal Vokáč <michal.vokac@ysoft.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-4-marko.kohtala@okoko.fi Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: Copy GSL groups when committing a new contextNicholas Kazlauskas1-0/+12
[ Upstream commit 21ffcc94d5b3dc024fedac700f1e7f9dacf4ab4f ] [Why] DC configures the GSL group for the pipe when pipe_split is enabled and we're switching flip types (buffered <-> immediate flip) on DCN2. In order to record what GSL group the pipe is using DC stores it in the pipe's stream_res. DM is not aware of this internal grouping, nor is DC resource. So when DM creates a dc_state context and passes it to DC the current GSL group is lost - DM never knew about it in the first place. After 3 immediate flips we run out of GSL groups and we're no longer able to correctly perform *any* flip for multi-pipe scenarios. [How] The gsl_group needs to be copied to the new context. DM has no insight into GSL grouping and could even potentially create a brand new context without referencing current hardware state. So this makes the most sense to have happen in DC. There are two places where DC can apply a new context: - dc_commit_state - dc_commit_updates_for_stream But what's shared between both of these is apply_ctx_for_surface. This logic only matters for DCN2, so it can be placed in dcn20_apply_ctx_for_surface. Before doing any locking (where the GSL group is setup) we can copy over the GSL groups before committing the new context. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Hersen Wu <hersen.wu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: Clear FEC_READY shadow register if DPCD write failsNikola Cornij1-0/+2
[ Upstream commit d68a74541735e030dea56f72746cd26d19986f41 ] [why] As a fail-safe, in case 'set FEC_READY' DPCD write fails, a HW shadow register should be cleared and the internal FEC stat should be set to 'not ready'. This is to make sure HW settings will be consistent with FEC_READY state on the RX. Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Reviewed-by: Joshua Aberback <Joshua.Aberback@amd.com> Acked-by: Chris Park <Chris.Park@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: fix not calling ppsmu to trigger PMESu Sung Chung1-0/+2
[ Upstream commit 18b401874aee10c80b5745c9b93280dae5a59809 ] [why] dcn20_clk_mgr_construct was not initializing pp_smu, and PME call gets filtered out by the null check [how] initialize pp_smu dcn20_clk_mgr_construct Signed-off-by: Su Sung Chung <Su.Chung@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: Power-gate all DSCs at driver init timeNikola Cornij1-0/+4
[ Upstream commit 75c35000235f3662f2810e9a59b0c8eed045432e ] [why] DSC should be powered-on only on as-needed basis, i.e. if the mode requires it [how] Loop over all the DSCs at driver init time and power-gate each Signed-off-by: Nikola Cornij <nikola.cornij@amd.com> Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/amd/display: add monitor patch to add T7 delayAnthony Koo2-0/+5
[ Upstream commit 88eac241a1fc500ce5274a09ddc4bd5fc2b5adb6 ] [Why] Specifically to one panel, TCON is able to accept active video signal quickly, but the Source Driver requires 2-3 frames of extra time. It is a Panel issue since TCON needs to take care of all Sink requirements including Source Driver. But in this case it does not. Customer is asking to add fixed T7 delay as panel workaround. [How] Add monitor specific patch to add T7 delay Signed-off-by: Anthony Koo <anthony.koo@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07drm/panel: simple: fix AUO g185han01 horizontal blankingLucas Stach1-3/+3
[ Upstream commit f8c6bfc612b56f02e1b8fae699dff12738aaf889 ] The horizontal blanking periods are too short, as the values are specified for a single LVDS channel. Since this panel is dual LVDS they need to be doubled. With this change the panel reaches its nominal vrefresh rate of 60Fps, instead of the 64Fps with the current wrong blanking. Philipp Zabel added: The datasheet specifies 960 active clocks + 40/128/160 clocks blanking on each of the two LVDS channels (min/typical/max), so doubled this is now correct. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1562764060.23869.12.camel@pengutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-24 05:28:54 +0300