| Age | Commit message (Collapse) | Author |
|---|
|
xiic_smbus_block_read_setup() recalculates i2c->rx_msg->len based on the
length byte returned by the device, but historically clobbered the PEC
byte expectation the SMBus core had baked into msg->len. That dropped
the PEC byte from the caller's buffer on the normal and chunked
receive-fifo branches.
Compute pec_len up-front as (i2c->rx_msg->len - 1) -- the trailing bytes
the caller has already accounted for beyond the length byte, 1 when the
SMBus core enabled PEC, and possibly more for an I2C_M_RECV_LEN request
coming from i2c-dev -- and add it to the new length in every branch:
- chunked: the trailing bytes do not fit in the Rx FIFO, so drain in
chunks. The guard becomes (rxmsg_len + pec_len > IIC_RX_FIFO_DEPTH)
rather than rxmsg_len alone, both because pec_len bytes also have to
fit and because it is what bounds rfd_set in the else branch below
to the 4 bits of XIIC_RFD_REG_OFFSET.
- padded (1 + rxmsg_len + pec_len < SMBUS_BLOCK_READ_MIN_LEN): the
hardware needs at least 3 bytes on the bus to exit the read cleanly
(the second byte is already being clocked in by the time the ISR
reads the length byte and is too late to NACK), so we still pad
rx_msg->len up to SMBUS_BLOCK_READ_MIN_LEN. The dummy trailing byte
that gets drained must then be trimmed off before handing the
message back to the SMBus core; otherwise i2c_smbus_check_pec()
reads buf[len-1] (= dummy) instead of the real PEC byte at buf[1]
and rejects every clean zero-length block read with -EBADMSG.
Record the true valid byte count in a new field
i2c->smbus_actual_len and trim rx_msg->len down to it in
xiic_smbus_trim_len(), called from both completion sites that clear
rx_msg: xiic_process()'s RX_FULL branch and xiic_recv_atomic(),
which drains the FIFO with interrupts off.
smbus_actual_len is per-receive state, so xiic_start_recv() clears
it before every receive. Only the padded branch ever sets it, and a
block read aborted by arbitration loss or a TX error never reaches
the completion site, so without that clear a stale value would trim
the length of an unrelated later read.
The condition is expressed in total bytes rather than the old
"(rxmsg_len == 1) || (rxmsg_len == 0)" so that a request carrying
more than one trailing byte does not get padded: padding records a
length the drain never reaches, which would hand the caller a byte
that was never received.
- normal: all trailing bytes fit in one FIFO fill. rfd_set gains
pec_len for the same reason the length does. Because the padded
branch above has already taken every case with fewer than
SMBUS_BLOCK_READ_MIN_LEN total bytes, rxmsg_len + pec_len is at
least 2 here and the subtraction cannot underflow the u8.
Fixes: e4c1ff772e1a ("i2c: xiic: Add smbus_block_read functionality")
Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
Cc: <stable@vger.kernel.org> # v6.3+
Acked-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260924-i2c-xiic-v7-1-df7e752332ef@nexthop.ai
|
|
All execution paths in the cdev layer now run in process context.
Use a mutex instead of a spinlock for client-level locking.
Link: https://lore.kernel.org/r/20260927230724.119305-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The transition state of an iso_resource_auto client resource has no
effect on the client, so the client-level lock is not suitable for
protecting it.
At present, this state is the only member that requires mutual
exclusion. Adding a separate lock for it would be excessive.
Change the type of the transition state to atomic_t and use an atomic
compare-and-swap operation to preserve consistency.
Link: https://lore.kernel.org/r/20260927230724.119305-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
mc_probe() acquires a reference to the remote processor with
rproc_get_by_phandle(), but mc_remove() does not release the reference.
rproc_shutdown() only balances the power reference acquired by rproc_boot();
it does not drop the device reference acquired by rproc_get_by_phandle(). As
a result, successful driver removal leaves the remoteproc reference
unbalanced.
Call rproc_put() during removal to release the reference acquired in
mc_probe().
[ bp: Massage commit message. ]
Fixes: d5fe2fec6c40d ("EDAC: Add a driver for the AMD Versal NET DDR controller")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260913053532.1324671-1-lgs201920130244@gmail.com
|
|
Add the renesas,r9a08g046-tsu compatible string and its default
(software) calibration constants for RZ/G3L, used when FUSE
calibration values are missing.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260925061617.127349-4-biju.das.jz@bp.renesas.com
|
|
data
Move the default (software) calibration values SW_CALIB0_VAL and
SW_CALIB1_VAL, used when FUSE values are missing, into a new
struct rzg3s_thermal_info retrieved via of_device_get_match_data().
This allows different SoCs sharing this driver to provide their own
default calibration constants, which is needed as RZ/G3L uses
different values than RZ/G3S.
No functional change intended for RZ/G3S.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260925061617.127349-3-biju.das.jz@bp.renesas.com
|
|
The TSENS v2 software driver currently clamps trip_min_temp and
trip_max_temp to -40°C and 120°C respectively. However, the
TSENS v2 hardware temperature threshold registers support a wider
programmable range from -204°C to +204°C.
On newer chipsets using TSENS v2, devices may legitimately operate
beyond the existing software limits (for example, up to 130°C). When a
trip temperature is programmed outside the software clamped range, it is
constrained to 120°C on the upper end or -40°C on the lower end.
If the actual temperature continues to exceed this clamped limit, the
threshold is immediately violated again, which can result in a
continuous interrupt storm.
Expand the TSENS v2 software trip temperature limits to match the full
hardware supported range (-204°C to +204°C). This avoids repeated
threshold reprogramming and ensures correct trip handling on TSENS v2
based platforms.
Signed-off-by: Priyansh Jain <priyansh.jain@oss.qualcomm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260508100700.772985-3-priyansh.jain@oss.qualcomm.com
|
|
calls
pm_runtime_put_autosuspend() already calls pm_runtime_mark_last_busy()
internally, so the explicit calls are not needed. Remove them.
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
Link: https://patch.msgid.link/20260916120003.87018-6-ovidiu.panait.rb@renesas.com
|
|
Add support for CrgA section containing the AArch32 IOP CPU state, which
may appear when an AArch32 RTKit IOP crashes.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
Link: https://patch.msgid.link/20260919-rtkit-armv7-crashlog-v1-2-f4a671ea453c@gmail.com
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
This section contains AArch64 CPU state of the IOP when the exception
occurred, including register information. Rename this section to be clear
about the CPU architecture as support for crashlog section with AArch32
CPU state will be added.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
Link: https://patch.msgid.link/20260919-rtkit-armv7-crashlog-v1-1-f4a671ea453c@gmail.com
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux
Pull i2c fix from Andi Shyti:
- qcom-geni: select the correct source clock table entry
* tag 'i2c-fixes-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux:
i2c: qcom-geni: Fix hardcoded clock index in SE_GENI_CLK_SEL
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
- Fix LLC mis-scheduling bugs (Tim Chen, Lu Wang)
- Fix cache-grouping related scheduling statistics UAF bugs (Tim Chen)
- Skip kernel threads for cache aware scheduling to rubustify the code
(Chen Yu)
- Refresh LLC capacity across CPU hotplug, to fix capacity
underestimation bug (Davi Chaves Azevedo)
- Account PSI IRQ time to the execution context, not the scheduling
context, to fix proxy scheduling accounting bug (Zhan Xusheng)
* tag 'sched-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/core: Account PSI IRQ time to the execution context, not the scheduling context
sched/cache: Refresh LLC capacity across CPU hotplug, to fix capacity underestimation bug
sched/cache: Skip kernel threads for cache aware scheduling to rubustify the code
sched/cache: Introduce task_struct->sched_cache_grp to fix UAF
sched/cache: Decouple sched_cache_group from mm to fix UAF
sched/cache: Honor migrate_llc_task semantics in active load balance, to fix LLC mis-scheduling bug
sched/cache: Keep nr_pref_llc_running in the runnable domain, to fix LLC mis-scheduling bug
|
|
Normally if we are under enough memory pressure, the shrinker will
eventually start waiting for BOs to become idle. In some very latency
sensitive use-cases this is undesirable.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/753011/
Message-ID: <20260912145922.24115-2-robin.clark@oss.qualcomm.com>
|
|
More than 2x speedup on darktable benchmark which was bottlenecked on
page allocation/pinning.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/753009/
Message-ID: <20260912145922.24115-1-robin.clark@oss.qualcomm.com>
|
|
A306 and A306A implement only three VBIF XIN halt request bits.
Consequently, waiting for the full 6-bit A3xx mask times out and
prevents runtime suspend.
This issue was reproduced on a DragonBoard 410c: the request reads back
as 0x7 and the acknowledgment as 0x00070007 - the poll eventually
returns -ETIMEDOUT, and a3xx_pm_suspend fails with -EBUSY.
The downstream kgsl driver corroborates this (see link). Since the
single-character difference between A3XX_VBIF_XIN_HALT_CTRL0_MASK and
A30X_VBIF_XIN_HALT_CTRL0_MASK could be confusing to read, the narrowed
GENMASK is instead defined inline in a3xx_vbif_halt().
Fixes: be0e82b8e0c9 ("drm/msm/a3xx: Drain VBIF before GPU suspend")
Link: https://android.googlesource.com/kernel/msm/+/c90c7feeca2f5839ad6824f816c0bd207602a2f4/drivers/gpu/msm/adreno_a3xx.c#637
Assisted-by: LLM
Signed-off-by: Sam Day <me@samcday.com>
Patchwork: https://patchwork.freedesktop.org/patch/756513/
Message-ID: <20260926-a306-vbif-mask-v1-1-2bae5e81c05a@samcday.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
The unwind loop drops the vm_bo reference taken while locking before
advancing to the next entry. drm_gpuvm_bo_put() may drop the last
reference, removing and freeing the vm_bo, after which the plain list
iterator dereferences freed memory to advance.
Use the safe iterator, which saves the next entry before the body runs.
Fixes: fe4952b5f27cca5d ("drm/msm: Convert vm locking")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Patchwork: https://patchwork.freedesktop.org/patch/754331/
Message-ID: <20260916175548.2089821-1-vulab@iscas.ac.cn>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Adreno 845 GPU is present in the Maili SoC. It is very similar to Hawi GPU
(A850), except that it doesn't have a MALU unit. Add the necessary
register lists and a catalog entry to support this GPU.
Signed-off-by: Bhaskar Reddy Valluru <bvalluru@qti.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755606/
Message-ID: <20260923-hawi-gpu-v1-9-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Add HFI support for the GMU THINMEM_CFG feature and provide the
configuration value used by the Adreno 850 GPU in the catalog.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755603/
Message-ID: <20260923-hawi-gpu-v1-8-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Adreno 850 is the next generation of A8x GPU present in Hawi SoC. It shares
the ADRENO_8XX_GEN2 family and slice architecture with A840, but has many
architectural improvements. There is a new block Matrix ALU (MALU) which
helps to accelerate certain compute workloads. Also, there is a new Bx rail
that powers a part of the GPU IP. GMU is now powered by a dedicated GDSC
powered by MxG rail.
Add a new catalog entry along with the necessary register lists and
additional changes to support the aforementioned new features.
Hawi SoC support UBWC v7.0, but GPU is unaffected by this upgrade.
Assisted-by: LLM
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755601/
Message-ID: <20260923-hawi-gpu-v1-7-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
In some chipsets like Hawi, the GPU arc level can exceed the highest
available MX corner. In that case, use the highest non-zero MX vote instead
of failing GMU initialization.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755599/
Message-ID: <20260923-hawi-gpu-v1-6-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Some A8x targets have a third memory rail (BX) in addition to GX and MX.
On these targets the GMU dependency vote carries a per-corner BX vote in
bits 25:20, which otherwise default to all-ones (no BX constraint).
Prepare BX vote field to pass this new voltage recommendation to GMU.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755597/
Message-ID: <20260923-hawi-gpu-v1-5-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
The GMU RPMh vote construction repeats two patterns across
a6xx_gmu_rpmh_arc_votes_init() and a6xx_gmu_rpmh_dep_votes_init():
reading a cmd-db aux-data resource (with the same "halve the byte count
and reject empty" handling), and scanning an arc level array for the
first corner that satisfies a target level.
Refactor out a6xx_gmu_rpmh_read_arc() and a6xx_gmu_rpmh_arc_index() to
reduce code duplication and improve code readability.
Assisted-by: LLM
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755595/
Message-ID: <20260923-hawi-gpu-v1-4-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
a6xx_gmu_rpmh_dep_votes_init() iterates the GPU frequency list
(gmu->gpu_freqs) but was passed gmu->dev to resolve each frequency to an
arc level. This results in generation of incorrect dependency votes
table. To fix this, pass gpu->pdev->dev, which owns the GPU OPP table.
Also, reorder the dependency vote init to improve clarity.
Fixes: 06cfbca0e1c6 ("drm/msm/a6xx: Share dependency vote table with GMU")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755593/
Message-ID: <20260923-hawi-gpu-v1-3-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Using the requested level can pick a secondary corner lower than the one
required to support the chosen primary corner, under-voting the
dependent rail. To fix this, match against the selected primary voltage
instead.
Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755592/
Message-ID: <20260923-hawi-gpu-v1-2-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Instead of voting ACV for all bw corners for A8x GPU, restrict it to BW
votes above the perfmode_bw threshold, similar to the A7x GPUs.
Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support")
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755589/
Message-ID: <20260923-hawi-gpu-v1-1-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Add support for Adreno X2-85 GPU present in Mahua SoC. This GPU is a
smaller version of Glymur GPU with fewer slices and smaller internal
memories, but shares the same register layout. Also, the GMU chipid is
different when compared to Glymur's GPU. Add a new catalog entry to
support this GPU.
Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/756256/
Message-ID: <20260925-mahua-gpu-v1-3-0fa0bfd8d315@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf events fixes from Ingo Molnar:
- Fixes for KVM guest PEBS virtualization (Sean Christopherson)
- Fixes for various Intel PMUs related to PEBS data-source (Dapeng Mi)
- Fix Intel Panther Cove event scheduling constraints (Dapeng Mi)
- Fix Intel DMR/NVL OMR extra registers event scheduling (Dapeng Mi)
- Rename two confusingly named PMU attributes (Dapeng Mi)
- Fix a refcount leak in attach_perf_ctx_data() (Namhyung Kim)
- Fix NULL pointer dereference crash in __perf_pmu_sched_task()
(Puranjay Mohan)
- Fix CPU-wide event scheduling (Puranjay Mohan)
- Fix x86 LBR branch entry generation (Puranjay Mohan)
* tag 'perf-urgent-2026-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Fill branch entries with a single assignment
perf/core: Run sched_task() for PMUs with only CPU-wide events
perf/core: Fix NULL pmu_ctx passed to pmu->sched_task()
perf/core: Fix a refcount leak in attach_perf_ctx_data()
perf/x86/intel: Rename NVL offcore_rsp attribute to offmodule_rsp
perf/x86/intel: Rename DMR offcore_rsp attribute to offmodule_rsp
perf/x86/intel: Fix precise OMR event scheduling for DMR/NVL
perf/x86/intel: Constrain Panther Cove UOPS_DISPATCHED events to PMCs 0-3
perf/x86/intel: Delete dead NVL PEBS data-source initcall
perf/x86/intel: Fix Panther Cove PEBS data-source snoop states
perf/x86/intel: Remove incorrect Panther Cove PEBS data-source constraints
perf/x86/intel: Remove incorrect LionCove PEBS data-source constraints
perf/x86/intel: Update arw_latency_data() mem-op direction handling
perf/x86/intel: Fix DKT PEBS load/store direction for latency events, to fix sample classification
perf/x86/intel: Fix CMT PEBS load/store direction for latency events, to fix sample classification
perf/x86/intel: Fix GRT PEBS load/store direction for latency events, to fix sample classification
perf/x86/intel: Make @data a mandatory param for intel_guest_get_msrs()
perf/x86/intel: Don't pointlessly context switch DS_AREA (and PEBS config) if PEBS is unused
perf/x86/intel: Don't write PEBS_ENABLED on host<=>guest xfers if CPU has PEBS isolation, to fix stuck PEBS_ENABLED
perf/x86/intel: Ensure KVM guest PEBS path doesn't set unwanted PERF_GLOBAL_CTRL bits
|
|
Convert open-coded if/else with set_bit/clear_bit to the assign_bit API.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://patch.msgid.link/20260918141926.3023230-1-peng.fan@oss.nxp.com
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
|
|
Add the GPU GID to the reported GPU info. This is the 16-byte SHA-1
based identifier GSP-RM reports for the GPU.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-14-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add the short GPU name to the GPU info structure. As with the full name
it is copied from a validated, NUL-terminated string extracted by
nova-core rather than from the raw firmware bytes.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-13-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add the full GPU name to the GPU info structure. The name is copied from
the validated, NUL-terminated string nova-core already extracts from the
GSP static info rather than from the raw firmware bytes.
GpuInfo::new() is deliberately fallible here. A malformed name string
from the GSP is unexpected and is reported to userspace as an error
rather than being silently replaced with an empty name.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-12-apopple@nvidia.com
[ Use ..pin_init::zeroed() instead of ..default::Default(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
nova-drm currently only exposes a primary node even though all of its
ioctls are already marked DRM_RENDER_ALLOW. Set the DRIVER_RENDER
feature so that a render node (/dev/dri/renderDXX) is created as well.
This is required to allow render and compute clients to interact with
nova-drm.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-11-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently nova-drm reads the VRAM BAR size directly from the PCIe device
which requires trying to cast the parent device into a PCIe device. This
obviously requires the parent device to actually be a PCIe bus device.
Whilst that is true today it may not always be the case, and there
is no reason to make this assumption now that NovaCoreApi can hold a
reference to the bound PCIe device.
So convert nova-drm to using nova-core to obtain the VRAM_BAR_SIZE
parameter.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-10-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a field to the GPU info structure containing the total usable
framebuffer size. The usable framebuffer excludes GSP carveouts and
other protected regions, so it may differ from the BAR size and total
physical VRAM.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-9-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add an extensible info ioctl and use it to report basic GPU information.
One of the first things userspace needs to know about a GPU is its
architecture and which chip it is, so add those as the first fields in
the GPU info result. The chip identifier is opaque to userspace and is
only meaningful when compared against the values of enum
drm_nova_chipid.
The ioctl selects an information type by ID and writes the result through
a sized userspace buffer. The kernel truncates results to the supplied
size, allowing information structures to grow and new logical information
groups to be added without introducing new ioctls. Passing a NULL data
pointer returns the size of the requested information structure instead.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-8-apopple@nvidia.com
[ Avoid 'as' casts (add From<Chipset> for u32, From<Architecture> for
u32 and use IntoSafeCast, IntoSafeCastArch); improve / simplify a few
comments. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The chip identifier uniquely identifies a GPU chip and needs to be
exposed to user-space so it can look up chip specific properties that
cannot be derived from the architecture alone. This adds a public enum
to the userspace headers for each chip ID. Nova-core can then use this
enum to define its chipsets.
The values are opaque to user-space. They may be compared against the
enum to identify a chip but user-space must not assume the values carry
any particular meaning or encoding.
This does create a coupling between nova-drm and nova-core whereby
nova-core depends on the values defined by the user-space API for
nova-drm. However this is entirely appropriate as nova-core must be
bound by the UAPI headers as the enum values are read by nova-core and
passed through to user-space.
Note that nova-core currently refers to the chipid as a chipset. This
isn't ideal given that chipid is the preferred and more accurate term
and is what should be exposed via the uAPI. Therefore a future patch
series will be posted that aligns nova-core internals to using chipid
rather than chipset.
Assisted-by: LLM
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-6-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The GPU architecture to be exposed to user-space. This adds a public
enum to the userspace headers for each chip architecture. Nova-core can
then use this enum to define its architectures.
This does create a coupling between nova-drm and nova-core whereby
nova-core depends on the values defined by the user-space API for
nova-drm. However this is entirely appropriate as nova-core must be
bound by the UAPI headers as the enum values are read by nova-core and
passed through to user-space.
It also requires a minor change to the bounded_enum! macro to match the
architecture values in an expression context.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-5-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently the nova-drm stub driver doesn't really interact with a real
device, so it doesn't have any registration data and has no way to call
into nova-core.
To allow for this add a DrmRegData type which will hold a
NovaCoreApiHandle for the NovaCoreApi associated with the auxbus device.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260909064506.910162-4-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Nova core will be used to export core functionality to other drivers
which will bind to it via auxiliary bus devices. Add a NovaCoreApi type
which drivers can use to call nova-core methods.
Auxiliary bus drivers obtain a NovaCoreApiHandle for a particular GPU
using NovaCoreApi::of(). This takes a reference to a bound auxiliary bus
device and checks that its registration data is a NovaCoreApi. The
NovaCoreApi itself is then accessed by passing a closure to
NovaCoreApiHandle::with().
Closure based access is used because NovaCoreApi cannot be assumed to be
covariant over its lifetime. It references the Gpu, which will carry
locks around types holding device resources, making it invariant.
Covariant sub-fields can still be returned directly from the closure
thanks to the lifetime bound on registration_data_with().
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-3-apopple@nvidia.com
[ Rebase and use pin_chain() for Gpu::run_selftests(). - Danilo ]
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
BarUser should not use 'gpu as a name for its lifetime; stick to a
generic 'a until we need pin-init selfref for this struct.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
There is no need for a reference count here. BarUserAccess can just
borrow from BarUser.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-4-dakr@kernel.org
[ Update stale comment in run_self_test(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Remove the unnecessary Arc around BarUser and get rid of
Result<impl PinInit<T>> in favor of impl PinInit<T, Error>.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Make Bar1 an alias for a borrowed pci::Bar in order to match the Bar0
type alias.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
This reverts commit 105c42566a550e2d05fc14f763216a8765ee5d0e.
The 32-bit quirk was incorrectly applied to JMicron JMicron JMB582/JMB585,
but it turns out that the root cause was actually a problem with BIOS
configuration of PCIe root ports, enabling a features that causes problems
with 64-bit DMA.
This problem has now been fixed in commit 4fde44822512 ("x86/PCI: Disable
enhanced atomics on AMD NBIO 7.7 and 7.11").
Since the real root cause has now been fixed, we can revert this incorrect
quirk.
Cc: Arthur Husband <artmoty@gmail.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20260908190600.226485-3-mario.limonciello@amd.com
Signed-off-by: Niklas Cassel <cassel@kernel.org>
|
|
During packet cancellation, the work item for the AT request context is
disabled. As a result, packets for request subactions are not processed
by the work item even if they finished, since the work item can not be
scheduled from hardIRQ handling.
Run the work item immediately after re-enabling it.
Link: https://lore.kernel.org/r/20260927044407.65497-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
transaction request packets
When fw_card_driver.cancel_packet() returns a non-zero value, the request
subaction of the transaction has already finished. It means that the
packet for the request subaction has already received an ack code and a
timestamp, so there is no need to check them.
Remove the unnecessary branch for the ack code and timestamp.
Link: https://lore.kernel.org/r/20260927044407.65497-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
Arrange the local variables to avoid a goto statement when copying events
to the userspace buffer.
Link: https://lore.kernel.org/r/20260927034343.28076-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
xchg() is useful for exchanging a pointer and returning the old value,
even when atomicity is not required.
Link: https://lore.kernel.org/r/20260927034343.28076-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
available
The in_shutdown member of client structure is set only when releasing
file descriptor, thus no need to wake up the client itself.
Link: https://lore.kernel.org/r/20260927034343.28076-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
