The HPD (Hot Plug Detect) signal is present in many (probably even
"most") eDP panels. For eDP, this signal isn't actually used for
detecting hot-plugs of the panel but is more akin to a "panel ready"
signal. After you provide power to the panel, panel timing diagrams
typically say that you should wait for HPD to be asserted (or wait a
fixed amount of time) before talking to the panel.
The panel-simple bindings describes many eDP panels and many of these
panels provide the HPD signal. We should add the HPD-related
properties to the panel-simple bindings. The HPD properties are
actually defined in panel-common.yaml, so adding them here just
documents that they are OK for panels handled by the panel-simple
bindings.
NOTE: whether or not we'd include HPD properties in the panel node is
more a property of the board design than the panel itself. For most
boards using these eDP panels everything "magically" works without
specifying any HPD properties and that's been why we haven't needed to
allow the HPD properties earlier. On these boards the HPD signal goes
directly to a dedicated "HPD" input to the eDP controller and this
connection doesn't need to be described in the device tree. The only
time the HPD properties are needed in the device tree are if HPD is
hooked up to a GPIO or if HPD is normally on the panel but isn't used
on a given board. That means that if we don't allow the HPD properties
in panel-simple then one could argue that we've got to boot all eDP
panels (or at least all those that someone could conceivably put on a
system where HPD goes to a GPIO or isn't hooked up) from panel-simple.
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.1.Ieb731d23680db4700cc41fe51ccc73ba0b785fb7@changeid
This adds a new driver for the Samsung DB7430 DPI display
controller as controlled over SPI.
Right now the only panel product we know that is using this
display controller is the LMS397KF04 but there may be more.
This is the first regular panel driver making use of the
MIPI DBI helper library. The DBI "device" portions can not
be used because that code assumes the use of a single
regulator and specific timings around the reset pulse that
do not match the DB7430 datasheet.
Cc: Paul Cercueil <[email protected]>
Cc: Doug Anderson <[email protected]>
Acked-by: Noralf Trønnes <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
In this patch we add a section to document what userspace should do to
find out the CRTC index. This is important as they may be many places in
the documentation that need this, so it's better to just point to this
section and avoid repetition.
Signed-off-by: Leandro Ribeiro <[email protected]>
Reviewed-by: Pekka Paalanen <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
If the VMM's (Qemu) memory backend is backed up by memfd + Hugepages
(hugetlbfs and not THP), we have to first find the hugepage(s) where
the Guest allocations are located and then extract the regular 4k
sized subpages from them.
v2: Ensure that the subpage and hugepage offsets are calculated correctly
when the range of subpage allocations cuts across multiple hugepages.
v3: Instead of repeatedly looking up the hugepage for each subpage,
only do it when the subpage allocation crosses over into a different
hugepage. (suggested by Gerd and DW)
v4: Fix the following warning identified by checkpatch:
CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
Cc: Gerd Hoffmann <[email protected]>
Signed-off-by: Vivek Kasireddy <[email protected]>
Signed-off-by: Dongwon Kim <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
[ kraxel: one more checkpatch format tweak ]
Signed-off-by: Gerd Hoffmann <[email protected]>
Drop disabling of gfxoff during VCN use. This allows gfxoff
to kick in and potentially save power if the user is not using
gfx for color space conversion or scaling.
VCN1.0 had a bug which prevented it from working properly with
gfxoff, so we disabled it while using VCN. That said, most apps
today use gfx for scaling and color space conversion rather than
overlay planes so it was generally in use anyway. This was fixed
on VCN2+, but since we mostly use gfx for color space conversion
and scaling and rapidly powering up/down gfx can negate the
advantages of gfxoff, we left gfxoff disabled. As more
applications use overlay planes for color space conversion
and scaling, this starts to be a win, so go ahead and leave
gfxoff enabled.
Note that VCN1.0 uses vcn_v1_0_idle_work_handler() and
vcn_v1_0_ring_begin_use() so they are not affected by this
patch.
Reviewed-by: James Zhu <[email protected]>
Acked-by: Christian König <[email protected]>
Reviewed-by: Boyuan Zhang <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.
Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.
For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Ben Skeggs <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control bits such as setting the brightness level over AUX, probing the
backlight's TCON, enabling/disabling the backlight over AUX if supported,
etc. Any PWM-related portions of backlight control are explicitly left up
to the driver, as these will vary from platform to platform.
The only exception to this is the calculation of the PWM frequency
pre-divider value. This is because the only platform-specific information
required for this is the PWM frequency of the panel, which the driver is
expected to provide if available. The actual algorithm for calculating this
value is standard and is defined in the eDP specification from VESA.
Note that these helpers do not yet implement the full range of features
the VESA backlight interface provides, and only provide the following
functionality (all of which was already present in i915's DPCD backlight
support):
* Basic control of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight
v3:
* Split out changes to i915's backlight code to separate patches to make it
easier to review
v4:
* Style/spelling changes from Thomas Zimmermann
v5:
* Start using new drm_dbg_*() functions
Signed-off-by: Lyude Paul <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
If we can't read DP_EDP_PWMGEN_BIT_COUNT in
intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency
defined in the VBT, we'll keep going in the function until we inevitably
fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in
doing this, so just return early.
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every driver from having to check everything against the eDP DPCD using DP
macros, which makes the code slightly easier to read (especially since the
names of some of the eDP capabilities don't exactly match up with what we
actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT
for instance).
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
v4:
* Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not
DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP work
again, also because I'd rather not mix a tree-wide refactor like that in
with a patch series intended to be around introducing DP backlight helpers.
So, for now let's just handle the return values from each function
correctly.
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
this value in intel_panel.backlight, and re-writing it as-needed.
Changes since v1:
* Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in
DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani
Signed-off-by: Lyude Paul <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Reviewed-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
We currently treat same slice mask as a same DBuf state and skip
updating the Dbuf slices, if we detect that.
This is wrong as if we have a multi to single pipe change or
vice versa, that would be treated as a same Dbuf state and thus
no changes required, so we don't get Mbus updated, causing issues.
Solution: check also mbus_join, in addition to slices mask.
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Fix the following sparse warnings generated by "make C=1":
drivers/gpu/drm/bridge/ti-sn65dsi83.c:429:13: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/bridge/ti-sn65dsi83.c:429:13: expected unsigned short [assigned] [usertype] val
drivers/gpu/drm/bridge/ti-sn65dsi83.c:429:13: got restricted __le16 [usertype]
drivers/gpu/drm/bridge/ti-sn65dsi83.c:432:13: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/bridge/ti-sn65dsi83.c:432:13: expected unsigned short [addressable] [assigned] [usertype] val
drivers/gpu/drm/bridge/ti-sn65dsi83.c:432:13: got restricted __le16 [usertype]
drivers/gpu/drm/bridge/ti-sn65dsi83.c:436:13: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/bridge/ti-sn65dsi83.c:436:13: expected unsigned short [addressable] [assigned] [usertype] val
drivers/gpu/drm/bridge/ti-sn65dsi83.c:436:13: got restricted __le16 [usertype]
drivers/gpu/drm/bridge/ti-sn65dsi83.c:438:13: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/bridge/ti-sn65dsi83.c:438:13: expected unsigned short [addressable] [assigned] [usertype] val
drivers/gpu/drm/bridge/ti-sn65dsi83.c:438:13: got restricted __le16 [usertype]
drivers/gpu/drm/bridge/ti-sn65dsi83.c:441:13: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/bridge/ti-sn65dsi83.c:441:13: expected unsigned short [addressable] [assigned] [usertype] val
drivers/gpu/drm/bridge/ti-sn65dsi83.c:441:13: got restricted __le16 [usertype]
Signed-off-by: Marek Vasut <[email protected]>
Cc: Adam Ford <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Frieder Schrempf <[email protected]>
Cc: Jagan Teki <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Loic Poulain <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Philippe Schenker <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Stephen Boyd <[email protected]>
Cc: Valentin Raevsky <[email protected]>
To: [email protected]
Signed-off-by: Robert Foss <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The object surf is not fully initialized and the uninitialized
field surf.data is being copied by the call to qxl_bo_create
via the call to qxl_gem_object_create. Set surf.data to zero
to ensure garbage data from the stack is not being copied.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: f64122c1f6 ("drm: add new QXL driver. (v1.4)")
Signed-off-by: Colin Ian King <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Gerd Hoffmann <[email protected]>
This introduces the following function that can exit and activate a psr
source when intel_psr is already enabled.
- intel_psr_pause(): Pause current PSR. It deactivates current psr state.
- intel_psr_resume(): Resume paused PSR. It activates paused psr state.
v2: Address Jose's review comment.
- Remove unneeded changes around the intel_psr_enable().
- Add intel_psr_post_exit() which processes waiting until PSR is idle
and WA for SelectiveFetch.
v3: Address Jose's review comment.
- Rename intel_psr_post_exit() to intel_psr_wait_exit_locked().
- Move WA_1408330847 to intel_psr_disable_locked()
- If the PSR is paused by an explicit intel_psr_paused() call, make the
intel_psr_flush() not to activate PSR.
v4: Address Jose's review comment.
- In order to avoid the scenario of PSR is not active but there is a
scheduled psr->work, it changes the check routine of intel_psr_pause()
for PSR's enablement from "psr->active" to "psr->enable".
Cc: José Roberto de Souza <[email protected]>
Cc: Stanislav Lisovskiy <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Gwan-gyeong Mun <[email protected]>
Signed-off-by: Matt Roper <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[Why]
To support a new visual confirm mode: swizzle to show the specific
color at the screen border according to different surface swizzle mode.
Currently we only support the Linear mode with red color.
Signed-off-by: Po-Ting Chen <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[WHY]
- Commit from userspace could cause link stream to disable and hdcp
auth to reset when the HDCP has already been enabled at the moment.
CP should fall back to DESIRED from ENABLED in such cases.
- This change was previously reverted due to a regression caused, which
has now been cleared.
[HOW]
In hdcp display removal, change CP to DESIRED if at the moment CP
is ENABLED before the auth reset and removal of linked list element.
Signed-off-by: Dingchen (David) Zhang <[email protected]>
Signed-off-by: Qingqing Zhuo <[email protected]>
Reviewed-by: Rodrigo Siqueira <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
There is an assert in cases where transition from ODM 2:1
to ODM 1:1 (bypass)
[How]
Remove assert since this case is now valid.
Update diags tests for ODM transitions.
Signed-off-by: Eric Bernstein <[email protected]>
Reviewed-by: Dmytro Laktyushkin <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Found a use case (IPKVM) that DP-VGA active dongle does
not return any EDID and the mentioned commit broke it.
[How]
This reverts "Disconnect non-DP with no EDID"
Signed-off-by: Roy Chan <[email protected]>
Reviewed-by: Chris Park <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why & How]
Add debugfs entry to force dsc decoding at PCON when DSC capable
external RX is connected. In such case, it is free to test DSC
decoding at external RX or at PCON.
Signed-off-by: Fangzhi Zuo <[email protected]>
Reviewed-by: Hersen Wu <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
When calculating recout width for an MPO plane on a mode that's using
ODM combine, driver can calculate a negative value, resulting in a
crash.
[How]
For negative widths, use zero such that validation will prune the
configuration correctly and disallow MPO.
Signed-off-by: Aric Cyr <[email protected]>
Reviewed-by: Krunoslav Kovac <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[WHY]
DISPCLK_MAX_ERRDET_CYCLES must be 7 to prevent connection loss when
changing DENTIST_DISPCLK_WDIVIDER from 126 to 127 and back.
Signed-off-by: Wesley Chalmers <[email protected]>
Reviewed-by: Dmytro Laktyushkin <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[WHY]
HW has handed down a new sequence that requires access to these
registers.
v2: squash in DCN3.1 fixes (Alex)
Signed-off-by: Wesley Chalmers <[email protected]>
Reviewed-by: Dmytro Laktyushkin <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[WHY]
HW has handed down a new sequence which requires access to the FIFO
ERRDET SW Override register.
Signed-off-by: Wesley Chalmers <[email protected]>
Reviewed-by: Dmytro Laktyushkin <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[Why]
Rearranging pipes with multiple displays and multiple planes cannot be
done atomically and requires a much improved sequence to deal with it.
[How]
To workaround such issues, prefer avoid pipe-split policy for
multidisplay scenarios.
Signed-off-by: Aric Cyr <[email protected]>
Reviewed-by: Krunoslav Kovac <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[why]
When OS overrides training link training parameters
for MST device to SST mode, MST resources are not
released and leak of the resource may result crash and
incorrect MST discovery during following hot plugs.
[how]
Retaining sink object to be reused by SST link and
releasing MST resources.
Signed-off-by: Vladimir Stempen <[email protected]>
Reviewed-by: Wenjing Liu <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
[why]
Allow specifying which panel to take PSR Residency
measurements from.
[how]
Pass panel instance to DMUB through GPINT in the upper
8 bits of the parameter.
Signed-off-by: Mikita Lipski <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Acked-by: Stylon Wang <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Douglas Anderson