When copy_thread is given a kernel function to run in arg->fn, this
does not necessarily mean it is a kernel thread. User threads can be
created this way (e.g., kernel_init, see also x86's copy_thread()).
These threads run a kernel function which may call kernel_execve()
and return, which returns like a userspace exec(2) syscall.
Kernel threads are to be differentiated with PF_KTHREAD, will always
have arg->fn set, and should never return from that function, instead
calling kthread_exit() to exit.
Create separate paths for the kthread and user kernel thread creation
logic. The kthread path will never exit and does not require a user
interrupt frame, so it gets a minimal stack frame.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-6-npiggin@gmail.com
If the system call return path always restores NVGPRs then there is no
need for ret_from_fork to do it. The HANDLER_RESTORE_NVGPRS does the
right thing for this.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-5-npiggin@gmail.com
The kernel thread path in copy_thread creates a user interrupt frame on
stack and stores the function and arg parameters there, and
ret_from_kernel_thread loads them. This is a slightly confusing way to
overload that frame. Non-volatile registers are loaded from the switch
frame, so the parameters can be stored there. The user interrupt frame
is now only used by user threads when they return to user.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-4-npiggin@gmail.com
The ret_from_fork code for 64e and 32-bit set r3 for
syscall_exit_prepare the same way that 64s does, so there should
be no need to special-case them in copy_thread.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-3-npiggin@gmail.com
The pkey registers (AMR, IAMR) do not get loaded from the switch frame
so it is pointless to save anything there. Remove the dead code.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230325122904.2375060-2-npiggin@gmail.com
The amdgpu driver builds some of its code with hard-float enabled,
whereas the rest of the kernel is built with soft-float.
When building with 64-bit long double, if soft-float and hard-float
objects are linked together, the build fails due to incompatible ABI
tags.
In the past there have been build errors in the amdgpu driver caused by
this, some of those were due to bad intermingling of soft & hard-float
code, but those issues have now all been fixed since commit 58ddbecb14
("drm/amd/display: move remaining FPU code to dml folder").
However it's still possible for soft & hard-float objects to end up
linked together, if the amdgpu driver is built-in to the kernel along
with the test_emulate_step.c code, which uses soft-float. That happens
in an allyesconfig build.
Currently those build errors are avoided because the amdgpu driver is
gated on 128-bit long double being enabled. But that's not a detail the
amdgpu driver should need to be aware of, and if another driver starts
using hard-float the same problem would occur.
All versions of the 64-bit ABI specify that long-double is 128-bits.
However some compilers, notably the kernel.org ones, are built to use
64-bit long double by default.
Apart from this issue of soft vs hard-float, the kernel doesn't care
what size long double is. In particular the kernel using 128-bit long
double doesn't impact userspace's ability to use 64-bit long double, as
musl does.
So always build the 64-bit kernel with 128-bit long double. That should
avoid any build errors due to the incompatible ABI tags. Excluding the
code that uses soft/hard-float, the vmlinux is identical with/without
the flag.
It does mean any code which is incorrectly intermingling soft &
hard-float code will build without error, so those bugs will need to be
caught by testing rather than at build time.
For more background see:
- commit d11219ad53 ("amdgpu: disable powerpc support for the newer display engine")
- commit c653c59178 ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
- https://lore.kernel.org/r/dab9cbd8-2626-4b99-8098-31fe76397d2d@app.fastmail.com
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Link: https://msgid.link/20230404102847.3303623-1-mpe@ellerman.id.au
There're two identical entries for ax1650 device in
iwl_dev_info_table. Remove one of the duplicate entries.
Fixes: 953e66a723 ("iwlwifi: add new ax1650 killer device")
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230410140721.897683-2-gregory.greenman@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add DTS for Qualcomm qrb4210-rb2 board which uses SM4250 SoC.
This adds debug uart, emmc, uSD and tlmm support along with
regulators found on this board.
Also defines the 'xo_board' and 'sleep_clk' frequencies for
this board.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
[bjorn: Squashed separate patch specifying regulator-system-load]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230411072840.2751813-3-bhupesh.sharma@linaro.org
Document the Qualcomm qrb4210-rb2 board based on Robotics version
of the Snapdragon SM4250 Soc, i.e. QRB4210.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230411072840.2751813-2-bhupesh.sharma@linaro.org
Extend the existing fan53555 driver to support the Rockchip RK860X
regulators.
RK8600/RK8601 are pretty similar to the FAN53555 regulators.
RK8602/RK8603 are a bit different, having a wider output voltage
selection range, from 0.5 V to 1.5 V in 6.25 mV steps. They also use
additional VSEL0/VSEL1 registers for the voltage selector, but the
enable and mode bits are still located in the original FAN53555 specific
VSEL0/VSEL1 registers.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230406194158.963352-9-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use dev_err_probe() instead of dev_err() in the probe function, which
ensures the error code is always printed and, additionally, simplifies
the code a bit.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-8-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In preparation for introducing support for additional regulators which
do not use the maximum number of voltage selectors available for a given
mask, improve the mask computation formula by using fls().
Note fls() requires the bitops header, hence include it explicitly and
drop bits.h which is already pulled by bitops.h.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-7-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For consistency and improved clarity, use BIT() and GENMASK() macros for
defining the bitfields inside the registers. No functional changes
intended.
While here, also fix DIE_{ID,REV} inconsistent indentation.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-6-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit b61ac767db ("regulator: fan53555: Convert to use
regulator_set_ramp_delay_regmap") removed the slew_shift member from
struct fan53555_device_info, hence the {CTL,TCS}_SLEW_SHIFT definitions
remained unused. Drop them.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-5-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add compatibles to support Rockchip RK860X regulators.
RK8600/RK8601 are pretty similar to the FAN53555 regulators, while
RK8602/RK8603 are a bit different, having a wider voltage selection
range.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230406194158.963352-2-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If bperf (perf tools that use BPF skels) sets evsel->leader_skel or
evsel->follower_skel then it appears that evsel->bpf_skel is set and can
trigger the following use-after-free:
==13575==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000014080 at pc 0x55684b939880 bp 0x7ffdfcf30d70 sp 0x7ffdfcf30d68
READ of size 8 at 0x60c000014080 thread T0
#0 0x55684b93987f in sample_filter_bpf__destroy tools/perf/bpf_skel/sample_filter.skel.h:44:11
#1 0x55684b93987f in perf_bpf_filter__destroy tools/perf/util/bpf-filter.c:155:2
#2 0x55684b98f71e in evsel__exit tools/perf/util/evsel.c:1521:2
#3 0x55684b98a352 in evsel__delete tools/perf/util/evsel.c:1547:2
#4 0x55684b981918 in evlist__purge tools/perf/util/evlist.c:148:3
#5 0x55684b981918 in evlist__delete tools/perf/util/evlist.c:169:2
#6 0x55684b887d60 in cmd_stat tools/perf/builtin-stat.c:2598:2
..
0x60c000014080 is located 0 bytes inside of 128-byte region [0x60c000014080,0x60c000014100)
freed by thread T0 here:
#0 0x55684b780e86 in free compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3
#1 0x55684b9462da in bperf_cgroup_bpf__destroy tools/perf/bpf_skel/bperf_cgroup.skel.h:61:2
#2 0x55684b9462da in bperf_cgrp__destroy tools/perf/util/bpf_counter_cgroup.c:282:2
#3 0x55684b944c75 in bpf_counter__destroy tools/perf/util/bpf_counter.c:819:2
#4 0x55684b98f716 in evsel__exit tools/perf/util/evsel.c:1520:2
#5 0x55684b98a352 in evsel__delete tools/perf/util/evsel.c:1547:2
#6 0x55684b981918 in evlist__purge tools/perf/util/evlist.c:148:3
#7 0x55684b981918 in evlist__delete tools/perf/util/evlist.c:169:2
#8 0x55684b887d60 in cmd_stat tools/perf/builtin-stat.c:2598:2
...
previously allocated by thread T0 here:
#0 0x55684b781338 in calloc compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
#1 0x55684b944e25 in bperf_cgroup_bpf__open_opts tools/perf/bpf_skel/bperf_cgroup.skel.h:73:35
#2 0x55684b944e25 in bperf_cgroup_bpf__open tools/perf/bpf_skel/bperf_cgroup.skel.h:97:9
#3 0x55684b944e25 in bperf_load_program tools/perf/util/bpf_counter_cgroup.c:55:9
#4 0x55684b944e25 in bperf_cgrp__load tools/perf/util/bpf_counter_cgroup.c:178:23
#5 0x55684b889289 in __run_perf_stat tools/perf/builtin-stat.c:713:7
#6 0x55684b889289 in run_perf_stat tools/perf/builtin-stat.c:949:8
#7 0x55684b888029 in cmd_stat tools/perf/builtin-stat.c:2537:12
Resolve by clearing 'evsel->bpf_skel' as part of bpf_counter__destroy().
Suggested-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: bpf@vger.kernel.org
Link: http://lore.kernel.org/lkml/20230411051718.267228-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This is a driver for the Amlogic SPI flash controller support
on A113L SoC.
Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230403183217.13280-3-mmkurbanov@sberdevices.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Adding support for MP5496 S1 regulator on IPQ9574 SoC.
Co-developed-by: Praveenkumar I <quic_ipkumar@quicinc.com>
Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com>
Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230407155727.20615-3-quic_devipriy@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add missing of_node_put()s before the returns to balance
of_node_get()s and of_node_put()s, which may get unbalanced
in case the for loop 'for_each_available_child_of_node' returns
early.
Fixes: 4302187d95 ("ASoC: mediatek: common: add soundcard driver common code")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Link: https://lore.kernel.org/r/202304090504.2K8L6soj-lkp@intel.com/
Signed-off-by: Aashish Sharma <shraash@google.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Trevor Wu <trevor.wu@mediatek.com>
Link: https://lore.kernel.org/r/20230411003431.4048700-1-shraash@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- Switch to REGCACHE_FLAT, the whole overhead of RBTREE is not worth it
with non sparse register set in the address range 1..7.
- Move register width to central location
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20230410223902.2321834-3-alexander.sverdlin@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make startup/shutdown callbacks symmetric to avoid clock subsystem warnings
(reproduced with "aplay --dump-hw-params" + ctrl-c):
WARNING: CPU: 0 PID: 102 at drivers/clk/clk.c:1048 clk_core_disable
lrclk already disabled
CPU: 0 PID: 102 Comm: aplay Not tainted 6.2.0-rc4 #1
Hardware name: Generic DT based system
...
clk_core_disable from clk_core_disable_lock
clk_core_disable_lock from ep93xx_i2s_shutdown
ep93xx_i2s_shutdown from snd_soc_dai_shutdown
snd_soc_dai_shutdown from soc_pcm_clean
soc_pcm_clean from soc_pcm_close
soc_pcm_close from snd_pcm_release_substream.part.0
snd_pcm_release_substream.part.0 from snd_pcm_release
snd_pcm_release from __fput
__fput from task_work_run
...
WARNING: CPU: 0 PID: 102 at drivers/clk/clk.c:907 clk_core_unprepare
lrclk already unprepared
CPU: 0 PID: 102 Comm: aplay Tainted: G W 6.2.0-rc4 #1
Hardware name: Generic DT based system
...
clk_core_unprepare from clk_unprepare
clk_unprepare from ep93xx_i2s_shutdown
ep93xx_i2s_shutdown from snd_soc_dai_shutdown
snd_soc_dai_shutdown from soc_pcm_clean
soc_pcm_clean from soc_pcm_close
soc_pcm_close from snd_pcm_release_substream.part.0
snd_pcm_release_substream.part.0 from snd_pcm_release
snd_pcm_release from __fput
__fput from task_work_run
...
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20230410223902.2321834-2-alexander.sverdlin@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The mapping of perf_events generic hardware events to actual PMU events on
ARM PMUv3 may not always be correct. This is in particular true for the
PERF_COUNT_HW_BRANCH_INSTRUCTIONS event. Although the mapping points to an
architected event, it may not always be available. This can be seen with a
simple:
$ perf stat -e branches sleep 0
Performance counter stats for 'sleep 0':
<not supported> branches
0.001401081 seconds time elapsed
Yet the hardware does have an event that could be used for branches.
Dynamically check for a supported hardware event which can be used for
PERF_COUNT_HW_BRANCH_INSTRUCTIONS at mapping time.
And with that:
$ perf stat -e branches sleep 0
Performance counter stats for 'sleep 0':
166,739 branches
0.000832163 seconds time elapsed
Co-developed-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Stephane Eranian <eranian@google.com>
Co-developed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Co-developed-by: Peter Newman <peternewman@google.com>
Signed-off-by: Peter Newman <peternewman@google.com>
Link: https://lore.kernel.org/all/YvunKCJHSXKz%2FkZB@FVFF77S0Q05N
Link: https://lore.kernel.org/r/20230411093809.657501-1-peternewman@google.com
Signed-off-by: Will Deacon <will@kernel.org>
1. Add support for 10-bit overlays
2. Add MediaTek SoC DRM (vdosys1) support for mt8195
3. Change mmsys compatible for mt8195 mediatek-drm
4. Only trigger DRM HPD events if bridge is attached
5. Change the aux retries times when receiving AUX_DEFER
-----BEGIN PGP SIGNATURE-----
iQJMBAABCgA2FiEEACwLKSDmq+9RDv5P4cpzo8lZTiQFAmQ0mPkYHGNodW5rdWFu
Zy5odUBrZXJuZWwub3JnAAoJEOHKc6PJWU4kv/wP/ixaRMppN9cIVB9UICxn31xJ
vzMyXScZ2cei/0nlTtWh2BOiHuw5BPvdUK9W+FqNDTf/EgRE7q9TLvEyB6DGEGOM
2Ahkcqw2rSnigP5rGFUKt9zFoVIc6YtiCG2jS65Q3UhuoBvoQZckTi/HhKGlw9KQ
piQCXZfTCSg67FHX109J1ASkh4B7hio8Pnk9X0+JqGI1U+y2RgWKhJV+o8BVmImE
3VFqEbqNPswy2GMYUWyRPTz89dw6ZPHswwbRPuOD5kGCY82QAZNxoVx8FkQD4GCv
1QTpZKb3dW8dUQBnkxXGtZ+8M/0H9ZjSvr4yjg0HF2HFQPof3UPie0MG7e4X1xUw
6spB4jSacvMHw89oIWg2eaIJ6D9iJVkevp8PiJsxS/pgvqHM4gCW9mCsEHxKVMQb
M2I0Z5tyfmiljrsiK0TDyv5uKHuozW6SX/nmCfLwvL4c1k/KOZuA7JBAEH2zMTMs
CBXMnFa9MgaVXdamEu/tbUOBfbaSsXde7dKWds1jYwIF3bAwRfuE/gtSkBVEqu1W
EABKUZTyd8/VwfsaEaQSF7N3e7bBSf5tjGZH/m2RHp2Eu/FsfeWxZK8/l8LMmGnr
4gF/dHTNOFMBg469EXS8BKouh40kJJjoj0c1IAOp5wcmH73RuGgXExbnVu3W7siC
fZPLDzUTSak5qC7tcpP1
=T2t7
-----END PGP SIGNATURE-----
Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next
Mediatek DRM Next for Linux 6.4
1. Add support for 10-bit overlays
2. Add MediaTek SoC DRM (vdosys1) support for mt8195
3. Change mmsys compatible for mt8195 mediatek-drm
4. Only trigger DRM HPD events if bridge is attached
5. Change the aux retries times when receiving AUX_DEFER
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230410233005.2572-1-chunkuang.hu@kernel.org
main pull request for v6.4
Core Display:
============
* Bugfixes for error handling during probe
* rework UBWC decoder programming
* prepare_commit cleanup
* bindings for SM8550 (MDSS, DPU), SM8450 (DP)
* timeout calculation fixup
* atomic: use drm_crtc_next_vblank_start() instead of our own
custom thing to calculate the start of next vblank
DP:
==
* interrupts cleanup
DPU:
===
* DSPP sub-block flush on sc7280
* support AR30 in addition to XR30 format
* Allow using REC_0 and REC_1 to handle wide (4k) RGB planes
* Split the HW catalog into individual per-SoC files
DSI:
===
* rework DSI instance ID detection on obscure platforms
GPU:
===
* uapi C++ compatibility fix
* a6xx: More robust gdsc reset
* a3xx and a4xx devfreq support
* update generated headers
* various cleanups and fixes
* GPU and GEM updates to avoid allocations which could trigger
reclaim (shrinker) in fence signaling path
* dma-fence deadline hint support and wait-boost
* a640 speedbin support
* a650 speedbin support
Conflicts in drivers/gpu/drm/msm/adreno/adreno_gpu.c:
Conflict between the 7fa5047a43 ("drm: Use of_property_present() for
testing DT property presence") and 9f251f9340 ("drm/msm/adreno: Use
OPP for every GPU generation"). The latter removed the of_ function
call outright, so I went with what's in the PR unchanged.
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvwuj5tabyW910+N-B=5kFNAC7QNYoQ=0xi3roBjQvFFQ@mail.gmail.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In preparation for reimplementing the do_vfp()->vfp_support_entry()
handover in C code, switch to using R3 to pass the 'success' return
address, rather than R9, as it cannot be used for parameter passing.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Instead of dereferencing thread_info in do_vfp, pass the thread_info
pointer to vfp_support_entry via R1. That way, we only use a single
caller save register, which makes it easier to convert do_vfp to C code
in a subsequent patch.
Note that, unlike the CPU number, which can change due to preemption,
passing the thread_info pointer can safely be done with preemption
enabled.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
- uAPI changes:
- Add a definition of a new Gaudi2 server type. This is used by userspace
to know what is the connectivity between the accelerators inside the
server
- New features and improvements:
- speedup h/w queues test in Gaudi2 to reduce device initialization times.
- Firmware related fixes:
- Fixes to the handshake protocol during f/w initialization.
- Sync f/w events interrupt in hard reset to avoid warning message.
- Improvements to extraction of the firmware version.
- Misc bug fixes and code cleanups. Notable fixes are:
- Multiple fixes for interrupt handling in Gaudi2.
- Unmap mapped memory in case TLB invalidation fails.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE7TEboABC71LctBLFZR1NuKta54AFAmQ0BEAACgkQZR1NuKta
54CxNQgArVWo/+IdKz4a+JtCHfHZm2lfPp7bl4Ck05PgF085lpX6bfO5NpTGAOJd
AJJNX5faqqRakg3BdDZ9u2FxGRGQltfjJt1KVD78vlOaux6nMw83XWWYDmzYHwPT
GYqPuluoiEQMqH4h95kwt3PyS9iILPon9gGIp4JVJCEWhFFa6TYyNr/rKdqNJUHz
ujfhLpkkV8GZ7KwMdtWCSTuprG7icHyu3yolZmNJ0Fx8AIZ0CQacxIr4WLa2n4Tv
CNnJYCTN9DNh8HfwDtm1wVb6Nq1am3DwZGOPXsy0Y8RhKf2VrGAFpW9wG07mL4Ep
EbPqTtO7fT4KGhdZ4JcUeeRg5F3gTw==
=Eit8
-----END PGP SIGNATURE-----
Merge tag 'drm-habanalabs-next-2023-04-10' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next
This tag contains additional habanalabs driver changes for v6.4:
- uAPI changes:
- Add a definition of a new Gaudi2 server type. This is used by userspace
to know what is the connectivity between the accelerators inside the
server
- New features and improvements:
- speedup h/w queues test in Gaudi2 to reduce device initialization times.
- Firmware related fixes:
- Fixes to the handshake protocol during f/w initialization.
- Sync f/w events interrupt in hard reset to avoid warning message.
- Improvements to extraction of the firmware version.
- Misc bug fixes and code cleanups. Notable fixes are:
- Multiple fixes for interrupt handling in Gaudi2.
- Unmap mapped memory in case TLB invalidation fails.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Oded Gabbay <ogabbay@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230410124637.GA2441888@ogabbay-vm-u20.habana-labs.com
With commit 8debed3efe ("kbuild: export top-level LDFLAGS_vmlinux
only to scripts/Makefile.vmlinux") applied, we no longer see the error
message while building the ARM zImage, but we do not have a good reason
to complicate the file path either.
'$(obj)/../../../../vmlinux' is canonicalized to 'vmlinux'.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Qualcomm PCIe controllers have debug registers in the MHI region that
count PCIe link transitions. Expose them over debugfs to userspace to
help debug the low power issues.
Note that even though the registers are prefixed as PARF_, they don't
live under the "parf" register region. The register naming is following
the Qualcomm's internal documentation as like other registers.
While at it, let's arrange the local variables in probe function to follow
reverse XMAS tree order.
Link: https://lore.kernel.org/r/20230316081117.14288-20-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
"mhi" register region contains the MHI registers that could be used by
the PCIe controller drivers to get debug information like PCIe link
transition counts on newer SoCs.
Link: https://lore.kernel.org/r/20230316081117.14288-16-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
qcom_pcie_config_sid_sm8250() function no longer applies only to SM8250.
So let's rename it to reflect the actual IP version and also move its
definition to keep it sorted as per IP revisions.
Link: https://lore.kernel.org/r/20230316081117.14288-15-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
To keep uniformity, let's use macros to define the total number of clocks
and supplies in qcom_pcie_resources_{2_7_0/2_9_0} structs.
Link: https://lore.kernel.org/r/20230316081117.14288-14-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
All the resets are asserted and deasserted at the same time. So the bulk
reset APIs can be used to handle them together. This simplifies the code
a lot.
It should be noted that there were delays in-between the reset asserts and
deasserts. But going by the config used by other revisions, those delays
are not really necessary. So a single delay after all asserts and one after
deasserts is used.
The total number of resets supported is 12 but only ipq4019 is using all of
them.
Link: https://lore.kernel.org/r/20230316081117.14288-13-manivannan.sadhasivam@linaro.org
Tested-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
All the resets are asserted and deasserted at the same time. So the bulk
reset APIs can be used to handle them together. This simplifies the code
a lot.
Link: https://lore.kernel.org/r/20230316081117.14288-12-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
All the clocks are enabled and disabled at the same time. So the bulk clock
APIs can be used to handle them together. This simplifies the code a lot.
Link: https://lore.kernel.org/r/20230316081117.14288-11-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
All the clocks are enabled and disabled at the same time. So the bulk clock
APIs can be used to handle them together. This simplifies the code a lot.
Link: https://lore.kernel.org/r/20230316081117.14288-10-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
All the clocks are enabled and disabled at the same time. So the bulk clock
APIs can be used to handle them together. This simplifies the code a lot.
Link: https://lore.kernel.org/r/20230316081117.14288-9-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
All the resets are asserted and deasserted at the same time. So the bulk
reset APIs can be used to handle them together. This simplifies the code
a lot.
While at it, let's also move the qcom_pcie_resources_2_1_0 struct below
qcom_pcie_resources_1_0_0 to keep it sorted.
Link: https://lore.kernel.org/r/20230316081117.14288-8-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
