| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
(blair). This is what seems to be a first occurrence of this happening,
but it's easy to overcome by guarding the SoC-specific fuse values with
of_machine_is_compatible(). Do just that to enable frequency limiting
on these SoCs.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542772/
Signed-off-by: Rob Clark <[email protected]>
|
|
Before transitioning to using per-SoC and not per-Adreno speedbin
fuse values (need another patchset to land elsewhere), a good
improvement/stopgap solution is to use adreno_is_aXYZ macros in
place of explicit revision matching. Do so to allow differentiating
between A619 and A619_holi.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542777/
Signed-off-by: Rob Clark <[email protected]>
|
|
The GPU can only be one at a time. Turn a series of ifs into if +
elseifs to save some CPU cycles.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542770/
Signed-off-by: Rob Clark <[email protected]>
|
|
Adreno 619 expects some tunables to be set differently. Make up for it.
Fixes: b7616b5c69e6 ("drm/msm/adreno: Add A619 support")
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542782/
Signed-off-by: Rob Clark <[email protected]>
|
|
A610 is one of (if not the) lowest-tier SKUs in the A6XX family. It
features no GMU, as it's implemented solely on SoCs with SMD_RPM.
What's more interesting is that it does not feature a VDDGX line
either, being powered solely by VDDCX and has an unfortunate hardware
quirk that makes its reset line broken - after a couple of assert/
deassert cycles, it will hang for good and will not wake up again.
This GPU requires mesa changes for proper rendering, and lots of them
at that. The command streams are quite far away from any other A6XX
GPU and hence it needs special care. This patch was validated both
by running an (incomplete) downstream mesa with some hacks (frames
rendered correctly, though some instructions made the GPU hangcheck
which is expected - garbage in, garbage out) and by replaying RD
traces captured with the downstream KGSL driver - no crashes there,
ever.
Add support for this GPU on the kernel side, which comes down to
pretty simply adding A612 HWCG tables, altering a few values and
adding a special case for handling the reset line.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542779/
Signed-off-by: Rob Clark <[email protected]>
|
|
A619_holi is a GMU-less variant of the already-supported A619 GPU.
It's present on at least SM4350 (holi) and SM6375 (blair). No mesa
changes are required. Add the required kernel-side support for it.
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542775/
Signed-off-by: Rob Clark <[email protected]>
|
|
A610 and A619_holi don't support the feature. Disable it to make the GPU stop
crashing after almost each and every submission - the received data on
the GPU end was simply incomplete in garbled, resulting in almost nothing
being executed properly. Extend the disablement to adreno_has_gmu_wrapper,
as none of the GMU wrapper Adrenos that don't support yet seem to feature it.
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542774/
Signed-off-by: Rob Clark <[email protected]>
|
|
Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
but don't implement the associated GMUs. This is due to the fact that
the GMU directly pokes at RPMh. Sadly, this means we have to take care
of enabling & scaling power rails, clocks and bandwidth ourselves.
Reuse existing Adreno-common code and modify the deeply-GMU-infused
A6XX code to facilitate these GPUs. This involves if-ing out lots
of GMU callbacks and introducing a new type of GMU - GMU wrapper (it's
the actual name that Qualcomm uses in their downstream kernels).
This is essentially a register region which is convenient to model
as a device. We'll use it for managing the GDSCs. The register
layout matches the actual GMU_CX/GX regions on the "real GMU" devices
and lets us reuse quite a bit of gmu_read/write/rmw calls.
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542766/
Signed-off-by: Rob Clark <[email protected]>
|
|
Since the introduction of A6xx support, we've been enabling the CX GMU
power counter 0 in a bit of a weird spot. Move it to hw_init so that
GMU wrapper GPUs can reuse the same code paths. As a bonus, this order
makes it easier to compare mainline and downstream register access traces.
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542765/
Signed-off-by: Rob Clark <[email protected]>
|
|
Rename lower_bit to hbb_lo and explain what it signifies.
Add explanations (wherever possible to other tunables).
Port setting min_access_length, ubwc_mode and hbb_hi from downstream.
Reviewed-by: Rob Clark <[email protected]>
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542764/
Signed-off-by: Rob Clark <[email protected]>
|
|
Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also
need REG_A6XX_GBIF_HALT to be set to 0.
This is typically done automatically on successful GX collapse, but in
case that fails, we should take care of it.
Also, add a memory barrier to ensure it's gone through before jumping
to further initialization.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542760/
Signed-off-by: Rob Clark <[email protected]>
|
|
Introduce a6xx_gpu_sw_reset() in preparation for adding GMU wrapper
GPUs and reuse it in a6xx_gmu_force_off().
This helper, contrary to the original usage in GMU code paths, adds
a readback+delay sequence to ensure that the reset is never deasserted
too quickly due to e.g. OoO execution going crazy.
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542758/
Signed-off-by: Rob Clark <[email protected]>
|
|
Unify the indentation and explain the cryptic 0xF value.
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542756/
Signed-off-by: Rob Clark <[email protected]>
|
|
This function is responsible for telling the GPU to halt transactions
on all of its relevant buses, drain them and leave them in a predictable
state, so that the GPU can be e.g. reset cleanly.
Move the function to a6xx_gpu.c, remove the static keyword and add a
prototype in a6xx_gpu.h to accomodate for the move.
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542762/
Signed-off-by: Rob Clark <[email protected]>
|
|
As pointed out by Akhil during the review process of GMU wrapper
introduction [1], it makes sense to move this write into the function
that's responsible for forcibly shutting the GMU off.
It is also very convenient to move this to GMU-specific code, so that
it does not have to be guarded by an if-condition to avoid calling it
on GMU wrapper targets.
Move the write to the aforementioned a6xx_gmu_force_off() to achieve
that. No effective functional change.
[1] https://lore.kernel.org/linux-arm-msm/[email protected]/
Reviewed-by: Akhil P Oommen <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542752/
Signed-off-by: Rob Clark <[email protected]>
|
|
These two will be reused by at least A619_holi in the non-gmu
paths. Turn them non-static them to make it possible.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542751/
Signed-off-by: Rob Clark <[email protected]>
|
|
The adreno_is_revn rework came at the same time as A690 introduction
and that resulted in it not covering all cases. Fix it.
Signed-off-by: Konrad Dybcio <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542754/
Signed-off-by: Rob Clark <[email protected]>
|
|
Otherwise its failed to pass basic compile test on platform without
REGMAP_MMIO selected by defconfig
make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64-
SYNC include/config/auto.conf.cmd
Checking missing-syscalls for N32
CALL scripts/checksyscalls.sh
Checking missing-syscalls for O32
CALL scripts/checksyscalls.sh
CALL scripts/checksyscalls.sh
MODPOST Module.symvers
ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/gpu/drm/ingenic/ingenic-drm.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1
make: *** [Makefile:1978: modpost] Error 2
V2: Order alphabetically
Signed-off-by: Sui Jingfeng <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Signed-off-by: Paul Cercueil <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes maybe in time for v6.4-rc7:
- qaic leak and null deref fix.
- Fix runtime pm in nouveau.
- Fix array overflow in ti-sn65dsi86 pwm chip handling.
- Assorted null check fixes in nouveau.
Signed-off-by: Dave Airlie <[email protected]>
From: Maarten Lankhorst <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
All known issues fixed now, so re-enable PSR1 on hsw/bdw.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
Can't see why we'd want the sprite blocking PSR entry.
Mask it out.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
WA 0479 says: "Do not skip both TP1 and TP2/TP3". Let's just
stick the minimum 100us TP2/3 time in there to avoid that.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
hsw/bdw lack the pipe register vs. display register distinction
in their PSR masking capabilities. So to keep our CURSURFLIVE
tricks working we need to just unmask all display register writes
on these platforms. The downside being that any display regitster
(eg. even SWF regs) will cause a PSR exit.
Note that WaMaskMMIOWriteForPSR asks us to mask this on bdw, but
that won't work since we need those CURSURFLIVE tricks. Observations
on actual hardware show that this causes one extra PSR exit ~every
10 seconds, which is pretty much irrelevant. I suspect this is
due to the pcode poking at IPS_CTL. Disabling IPS does not stop it
however, so either I'm wrong or pcode pokes at the register
regardless of whether it's actually trying to enable/disable IPS.
Also when the machine is busy (eg. just running 'find /') these
extra PSR exits cease, which again points at pcode or some other
PM entity as being the culprit.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
Bspec asks us to unmask "vblank to registers" in the DPRS unit.
Note that I was unable to observe any change in hardware
behviour due to this bit on HSW. But let's do this anyway
in case it matters in some cases, and the corresponding bit
on BDW is abolutely critical as without it the hardware
won't generate any vblanks whatsoever after PSR exit.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
Implement WaPsrDPAMaskVBlankInSRD:hsw, which makes the hardware
generate the extra vblank between link training and first frame
being transmitted. This is the same thing that's controlled by
TRANS_CHICKEN[21] on skl+ (but due to the funky double buffering
it's effectively always at the rest value after DC5 exit). So
for consistent behaviour we want every platform to generate said
vblank. BDW is already setting this up correctly.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
Add the PSR interrupt handling code back for HSW. Looks like
the removal was never completed anyway since the irq setup
code was lest untouched.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
Deal with HSW/BDW in transcoder_has_psr2().
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
Reintroduce the special PSR AUX CH setup for hsw/bdw. Not all
of it was even removed (BDW AUX data registers were left behind).
Update the code to use REG_BIT() & co. while at it.
v2: Define the SRD_AUX_CTL bits in terms of DP_AUX_CTL bits (Jouni)
Add a comment explaining the hand rolled DPCD write (Jouni)
Cc: Jouni Högander <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
Add back hsw'w special SRD/PSR1 registers.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
In preparation for re-introducing HSW's different PSR1 register
offeets let's just wrap all the registers into functions.
Avoids having to make the register macros more complex.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
The multiplication got replaced by an addition in some cleanup.
This means we never write the correct data to some of the BDW
PSR data registers and thus we fail to actually wake up the
panel from PSR.
Fixes: 4ab4fa103217 ("drm/i915/psr: Make PSR registers relative to transcoders")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
PC8+ clobbers a bunch of displays registers which need to
be restored by hand or else we lost a bunch of workarounds.
The important ones for us are at least CHICKEN_PAR2* and
CHICKEN_PIPESL*.
Curiously at least some CHICKEN_PAR1* registers
are preserved by the hardware/firmware. Unfortunately Bspec
doens't really specify what gets clobbered vs. preserved
so further reverse engieering might be warranted to figure
out the specifics.
Note that PCH_LP_PARTITION_LEVEL_DISABLE is also set by
lpt_init_clock_gating() so the rmw in hsw_disable_pc8()
is now redundant. Remove it.
TODO: I suspect most gt stuff doesn't need this and we should
finish moving all of them from init_clock_gating() to
a more appropriate place...
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jouni Högander <[email protected]>
|
|
The debug print parameters were swapped in the output and they were
printed as decimal values, both the hardware address and the value.
Update the debug print to print the parameters in correct order, and
use hexadecimal print for both address and value.
Fixes: f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
It makes no sense to pass NULL parameters to dsi_ctrl_config() in the
disable case. Split dsi_ctrl_config() into enable and disable parts and
drop unused params.
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Marijn Suijten <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542559/
Link: https://lore.kernel.org/r/[email protected]
|
|
Several source clocks are not used anymore, so stop handling them.
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Marijn Suijten <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542558/
Link: https://lore.kernel.org/r/[email protected]
|
|
sm6115, sm6375 and qcm2290 do not have INTF_0. Drop corresponding
interface definitions.
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Reviewed-by: Marijn Suijten <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542180/
Link: https://lore.kernel.org/r/[email protected]
|
|
Each MERGE_3D block has just two registers. Correct the block length
accordingly.
Fixes: 4369c93cf36b ("drm/msm/dpu: initial support for merge3D hardware block")
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542177/
Reviewed-by: Marijn Suijten <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
During IRQ conversion we have lost the PP_DONE interrupts for sc7280
platform. This was left unnoticed, because this interrupt is only used
for CMD outputs and probably no sc7[12]80 systems use DSI CMD panels.
Fixes: 667e9985ee24 ("drm/msm/dpu: replace IRQ lookup with the data in hw catalog")
Signed-off-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Reviewed-by: Marijn Suijten <[email protected]>
Patchwork: https://patchwork.freedesktop.org/patch/542175/
Link: https://lore.kernel.org/r/[email protected]
|
|
This seems to have existed for ever but is now more apparant after
commit 9bff18d13473 ("drm/ttm: use per BO cleanup workers")
My analysis: two threads are running, one in the irq signalling the
fence, in dma_fence_signal_timestamp_locked, it has done the
DMA_FENCE_FLAG_SIGNALLED_BIT setting, but hasn't yet reached the
callbacks.
The second thread in nouveau_cli_work_ready, where it sees the fence is
signalled, so then puts the fence, cleanups the object and frees the
work item, which contains the callback.
Thread one goes again and tries to call the callback and causes the
use-after-free.
Proposed fix: lock the fence signalled check in nouveau_cli_work_ready,
so either the callbacks are done or the memory is freed.
Reviewed-by: Karol Herbst <[email protected]>
Fixes: 11e451e74050 ("drm/nouveau: remove fence wait code from deferred client work handler")
Cc: [email protected]
Signed-off-by: Dave Airlie <[email protected]>
Link: https://lore.kernel.org/dri-devel/[email protected]/
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-next
drm/i915 feature pull #2 for v6.5:
Features and functionality:
- Meteorlake PM demand (Vinod, Mika)
- Switch to dedicated workqueues to stop using flush_scheduled_work() (Luca)
Refactoring and cleanups:
- Move display runtime init under display/ (Matt)
- Async flip error message clarifications (Arun)
Fixes:
- Remove 10bit gamma on desktop gen3 parts, they don't support it (Ville)
- Fix driver probe error handling if driver creation fails (Matt)
- Fix all -Wunused-but-set-variable warnings, and enable it for i915 (Jani)
- Stop using edid_blob_ptr (Jani)
- Fix log level for "CDS interlane align done" (Khaled)
- Fix an unnecessary include prefix (Matt)
Merges:
- Backmerge drm-next to sync with drm-intel-gt-next (Jani)
Signed-off-by: Dave Airlie <[email protected]>
From: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
[Why]
The sequence for collecting down_reply from source perspective should
be:
Request_n->repeat (get partial reply of Request_n->clear message ready
flag to ack DPRX that the message is received) till all partial
replies for Request_n are received->new Request_n+1.
Now there is chance that drm_dp_mst_hpd_irq() will fire new down
request in the tx queue when the down reply is incomplete. Source is
restricted to generate interveleaved message transactions so we should
avoid it.
Also, while assembling partial reply packets, reading out DPCD DOWN_REP
Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be
wrapped up as a complete operation for reading out a reply packet.
Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
be risky. e.g. If the reply of the new request has overwritten the
DPRX DOWN_REP Sideband MSG buffer before source writing one to clear
DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
for the new request. Should handle the up request in the same way.
[How]
Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might
trigger drm_dp_mst_kick_tx() only when there is no on going message
transaction.
Changes since v1:
* Reworked on review comments received
-> Adjust the fix to let driver explicitly kick off new down request
when mst irq event is handled and acked
-> Adjust the commit message
Changes since v2:
* Adjust the commit message
* Adjust the naming of the divided 2 functions and add a new input
parameter "ack".
* Adjust code flow as per review comments.
Changes since v3:
* Update the function description of drm_dp_mst_hpd_irq_handle_event
Changes since v4:
* Change ack of drm_dp_mst_hpd_irq_handle_event() to be an array align
the size of esi[]
Signed-off-by: Wayne Lin <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Cc: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
|
|
If hmm_range_fault returns -EBUSY, we should call hmm_range_fault again
to validate the remaining pages. On one system with NUMA auto balancing
enabled, hmm_range_fault takes 6 seconds for 1GB range because CPU
migrate the range one page at a time. To be safe, increase timeout value
to 1 second for 128MB range.
Signed-off-by: Philip Yang <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
To extend UTCL2 reach.
Signed-off-by: Philip Yang <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
The driver only supports OLED controllers that have a native DRM_FORMAT_C1
pixel format and that is why it has harcoded a division of the width by 8.
But the driver might be extended to support devices that have a different
pixel format. So it's better to use the struct drm_format_info helpers to
compute the size of the buffer, used to store the pixels in native format.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The resolutions for these panels are fixed and defined in the Device Tree,
so there's no point to allocate the buffers on each plane update and that
can just be done once.
Let's do the allocation and free on the encoder enable and disable helpers
since that's where others initialization and teardown operations are done.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The driver only supports OLED controllers that have a page height of 8 but
there are devices that have different page heights. So it is better to not
hardcode this value and instead have it as a per controller data value.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently the driver hardcodes the default values to 96x16 pixels but this
default resolution depends on the controller. The datasheets for the chips
describes the following display controller resolutions:
- SH1106: 132 x 64 Dot Matrix OLED/PLED
- SSD1305: 132 x 64 Dot Matrix OLED/PLED
- SSD1306: 128 x 64 Dot Matrix OLED/PLED
- SSD1307: 128 x 39 Dot Matrix OLED/PLED
- SSD1309: 128 x 64 Dot Matrix OLED/PLED
Add this information to the devices' info structures, and use it set as a
default if not defined in DT rather than hardcoding to an arbitrary value.
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Smatch warns:
drivers/gpu/drm/i915/gt/uc/intel_huc.c:388
intel_huc_init() warn: missing error code 'err'
When the allocation of VMAs fail: The value of err is zero at this
point and it is passed to PTR_ERR and also finally returning zero which
is success instead of failure.
Fix this by adding the missing error code when VMA allocation fails.
Fixes: 08872cb13a71 ("drm/i915/mtl/huc: auth HuC via GSC")
Signed-off-by: Harshit Mogalapalli <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Signed-off-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Set compute partition mode interface in NBIO is no longer used. Remove
the only implementation from NBIO v7.9
Signed-off-by: Lijo Lazar <[email protected]>
Reviewed-by: Hawking Zhang <[email protected]>
Reviewed-by: Le Ma <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Update user space last_event_age when event age is enabled.
It is only for KFD_EVENT_TYPE_SIGNAL which is checked by user space.
Signed-off-by: James Zhu <[email protected]>
Reviewed-by: Felix Kuehling <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|