- 03 Jun, 2021 15 commits
-
-
Thierry Reding authored
The memory client IDs will subsequently be used to program override SIDs for the given clients depending on the device tree configuration. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-12-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
The Tegra210 (and earlier) driver now supports all the functionality that the Tegra186 (and later) driver does, so they can be unified. Note that previously the Tegra186 (and later) driver could be unloaded, even if that was perhaps not very useful. Older chips don't support that yet, but once they do this code can be reenabled. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-11-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
The memory controller hot resets are implemented in the BPMP on Tegra186 and later, so there's no need to provide an implementation via the memory controller driver. Conditionally register the reset controller only if needed. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-10-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
Make IRQ support optional to help unify the Tegra186 memory controller driver with this one. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-9-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
Tegra20 requires a slightly different interrupt handler than Tegra30 and later, so parameterize the handler, so that each SoC implementation can provide its own. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-8-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
Separate the setup code for Tegra30 and later into a ->setup() callback and set it for all applicable chips. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-7-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
The current per-SoC setup code runs at a fairly arbitrary point during probe, thereby making it less flexible for other SoC generations. Move the call around slightly (after only the very basic, common setup that applies to all SoC generations has been performed), which will allow it to be used for other implementations. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-6-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
Continuing the scheme of unification, push suspend/resume callbacks into per-SoC driver so that they can be properly parameterized. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-5-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
Subsequent patches will introduce further callbacks, so create a new struct tegra_mc_ops to collect all of them in a single place. Move the existing ->init() callback into the new structure. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-4-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
As another step towards unifying both the Tegra210 (and earlier) and Tegra186 (and later) memory controller drivers, unify the structures that are used to represent them. Note that this comes at a slight space penalty since some fields are not used on all generations, but the benefits of unifying the driver outweigh the downsides. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-3-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Thierry Reding authored
Subsequent patches will add more register fields to the tegra_mc_client structure, so consolidate all register field definitions into a common sub-structure for coherency. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210602163302.120041-2-thierry.reding@gmail.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Krzysztof Kozlowski authored
Merge tag 'tegra-for-5.14-memory' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into for-v5.14/tegra-mc memory: tegra: Changes for v5.14-rc1 This stable tag contains Dmitry's power domain work, including all the necessary dependencies from the regulator, clock and ARM SoC trees. Further work depends on memory controller changes here.
-
Dmitry Osipenko authored
Use common devm_tegra_core_dev_init_opp_table() helper for the OPP table initialization. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Use common devm_tegra_core_dev_init_opp_table() helper for the OPP table initialization. Tested-by: Paul Fertser <fercerpav@gmail.com> # PAZ00 T20 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Enable compile testing for all Tegra memory drivers. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
- 01 Jun, 2021 10 commits
-
-
Dmitry Osipenko authored
Fix compilation warning on 64bit platforms caused by implicit promotion of 32bit signed integer to a 64bit unsigned value which happens after enabling compile-testing of the EMC drivers. Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
-
Thierry Reding authored
-
Dmitry Osipenko authored
Add stubs needed for compile-testing of Tegra memory drivers. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Add missing stubs that will allow Tegra memory driver to be compile-tested by kernel build bots. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Add common helper which initializes OPP table for Tegra SoC core devices. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Paul Fertser <fercerpav@gmail.com> # PAZ00 T20 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Add stub required for compile-testing of drivers. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Ensure that SoC voltages are at a level suitable for a system reboot. This is important for some devices that use CPU reset method for the rebooting. SoC CPU and core voltages now are be restored to a level that is suitable for rebooting. This patch fixes hang on reboot on Asus Transformer TF101, it was also reported as fixing some of reboot issues on Toshiba AC100. Reported-by: Nikola Milosavljević <mnidza@outlook.com> Tested-by: Nikola Milosavljević <mnidza@outlook.com> # TF101 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
-
Dmitry Osipenko authored
Some NVIDIA Tegra devices use a CPU soft-reset method for the reboot and in this case we need to restore the coupled voltages to the state that is suitable for hardware during boot. Add new regulator_sync_voltage_rdev() helper which is needed by regulator drivers in order to sync voltage of a coupled regulators. Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
- 31 May, 2021 8 commits
-
-
Dmitry Osipenko authored
The Tegra clock driver contains legacy code which deasserts hardware reset when peripheral clocks are enabled. This behaviour comes from a pre-CCF era of the Tegra drivers. This is unacceptable for modern kernel drivers which use generic CCF and reset-control APIs because it breaks assumptions of the drivers about clk/reset sequences and about reset-propagation delays. Hence remove the awkward legacy behaviour from the clk driver. In particular PMC driver assumes that hardware blocks remains in reset while power domain is turning on, but the clk driver deasserts the reset before power clamp is removed, hence breaking the driver's assumption. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
The external clocks don't have reset bits as they don't belong to any specific hardware unit. Mark them as not having reset control for consistency. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Check whether thermal DIV2 throttle is active in order to report the CPU frequency properly. This very useful for userspace tools like cpufreq-info which show actual frequency asserted from hardware. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Zero clock rate doesn't make sense for PLLs and tegra-clk driver enters into infinite loop on trying to calculate PLL parameters for zero rate. Make code to error out if requested rate is zero. Originally this trouble was found by Robert Yang while he was trying to bring up upstream kernel on Samsung Galaxy Tab, which happened due to a bug in Tegra DRM driver that erroneously sets PLL rate to zero. This issues came over again recently during of kernel bring up on ASUS TF700T. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
Higher SCLK rates on Tegra20 require high core voltage. The higher clock rate may have a positive performance effect only for AHB DMA transfers and AVP CPU, but both aren't used by upstream kernel at all. Halve SCLK rate on Tegra20 in order to remove the high core voltage requirement. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
The PLLU (USB) consists of the PLL configuration itself and configuration of the PLLU outputs. The PLLU programming is inconsistent on T30 vs T114, where T114 immediately bails out if PLLU is enabled and T30 re-enables a potentially already enabled PLL (left after bootloader) and then fully reprograms it, which could be unsafe to do. The correct way should be to skip enabling of the PLL if it's already enabled and then apply configuration to the outputs. This patch doesn't fix any known problems, it's a minor improvement. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
The refcounting of the gate clocks has a bug causing the enable_refcnt to underflow when unused clocks are disabled. This happens because clk provider erroneously bumps the refcount if clock is enabled at a boot time, which it shouldn't be doing, and it does this only for the gate clocks, while peripheral clocks are using the same gate ops and the peripheral clocks are missing the initial bump. Hence the refcount of the peripheral clocks is 0 when unused clocks are disabled and then the counter is decremented further by the gate ops, causing the integer underflow. Fix this problem by removing the erroneous bump and by implementing the disable_unused() callback, which disables the unused gates properly. The visible effect of the bug is such that the unused clocks are never gated if a loaded kernel module grabs the unused clocks and starts to use them. In practice this shouldn't cause any real problems for the drivers and boards supported by the kernel today. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Dmitry Osipenko authored
The 600MHz is a too high clock rate for some SoC versions for the video decoder hardware and this may cause stability issues. Use 300MHz for the video decoder by default, which is supported by all hardware versions. Fixes: ed1a2459 ("clk: tegra: Add Tegra20/30 EMC clock implementation") Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
- 09 May, 2021 7 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Commit b9d79e4c ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Bit later than usual, I queued them all up on Friday then promptly forgot to write the pull request email. This is mainly amdgpu fixes, with some radeon/msm/fbdev and one i915 gvt fix thrown in. amdgpu: - MPO hang workaround - Fix for concurrent VM flushes on vega/navi - dcefclk is not adjustable on navi1x and newer - MST HPD debugfs fix - Suspend/resumes fixes - Register VGA clients late in case driver fails to load - Fix GEM leak in user framebuffer create - Add support for polaris12 with 32 bit memory interface - Fix duplicate cursor issue when using overlay - Fix corruption with tiled surfaces on VCN3 - Add BO size and stride check to fix BO size verification radeon: - Fix off-by-one in power state parsing - Fix possible memory leak in power state parsing msm: - NULL ptr dereference fix fbdev: - procfs disabled warning fix i915: - gvt: Fix a possible division by zero in vgpu display rate calculation" * tag 'drm-next-2021-05-10' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: Use device specific BO size & stride check. drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. drm/amd/pm: initialize variable drm/radeon: Avoid power table parsing memory leaks drm/radeon: Fix off-by-one power_state index heap overwrite drm/amd/display: Fix two cursor duplication when using overlay drm/amdgpu: add new MC firmware for Polaris12 32bit ASIC fbmem: Mark proc_fb_seq_ops as __maybe_unused drm/msm/dpu: Delete bonkers code drm/i915/gvt: Prevent divided by zero when calculating refresh rate amdgpu: fix GEM obj leak in amdgpu_display_user_framebuffer_create drm/amdgpu: Register VGA clients after init can no longer fail drm/amdgpu: Handling of amdgpu_device_resume return value for graceful teardown drm/amdgpu: fix r initial values drm/amd/display: fix wrong statement in mst hpd debugfs amdgpu/pm: set pp_dpm_dcefclk to readonly on NAVI10 and newer gpus amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID drm/amdgpu: fix concurrent VM flushes on Vega/Navi v2 drm/amd/display: Reject non-zero src_y and src_x for video planes
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fix from Jens Axboe: "Turns out the bio max size change still has issues, so let's get it reverted for 5.13-rc1. We'll shake out the issues there and defer it to 5.14 instead" * tag 'block-5.13-2021-05-09' of git://git.kernel.dk/linux-block: Revert "bio: limit bio max size"
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull cifs fixes from Steve French: "Three small SMB3 chmultichannel related changesets (also for stable) from the SMB3 test event this week. The other fixes are still in review/testing" * tag '5.13-rc-smb3-part3' of git://git.samba.org/sfrench/cifs-2.6: smb3: if max_channels set to more than one channel request multichannel smb3: do not attempt multichannel to server which does not support it smb3: when mounting with multichannel include it in requested capabilities
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Thomas Gleixner: "A set of scheduler updates: - Prevent PSI state corruption when schedule() races with cgroup move. A recent commit combined two PSI callbacks to reduce the number of cgroup tree updates, but missed that schedule() can drop rq::lock for load balancing, which opens the race window for cgroup_move_task() which then observes half updated state. The fix is to solely use task::ps_flags instead of looking at the potentially mismatching scheduler state - Prevent an out-of-bounds access in uclamp caused bu a rounding division which can lead to an off-by-one error exceeding the buckets array size. - Prevent unfairness caused by missing load decay when a task is attached to a cfs runqueue. The old load of the task was attached to the runqueue and never removed. Fix it by enforcing the load update through the hierarchy for unthrottled run queue instances. - A documentation fix fot the 'sched_verbose' command line option" * tag 'sched-urgent-2021-05-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Fix unfairness caused by missing load decay sched: Fix out-of-bound access in uclamp psi: Fix psi state corruption when schedule() races with cgroup move sched,doc: sched_debug_verbose cmdline should be sched_verbose
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fixes from Thomas Gleixner: "A set of locking related fixes and updates: - Two fixes for the futex syscall related to the timeout handling. FUTEX_LOCK_PI does not support the FUTEX_CLOCK_REALTIME bit and because it's not set the time namespace adjustment for clock MONOTONIC is applied wrongly. FUTEX_WAIT cannot support the FUTEX_CLOCK_REALTIME bit because its always a relative timeout. - Cleanups in the futex syscall entry points which became obvious when the two timeout handling bugs were fixed. - Cleanup of queued_write_lock_slowpath() as suggested by Linus - Fixup of the smp_call_function_single_async() prototype" * tag 'locking-urgent-2021-05-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Make syscall entry points less convoluted futex: Get rid of the val2 conditional dance futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI Revert 337f1304 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") locking/qrwlock: Cleanup queued_write_lock_slowpath() smp: Fix smp_call_function_single_async prototype
-