Move the panel specific VBT parsing to happen during the
output probing stage. Needs to be done because the VBT
parsing will need to look at the EDID to determine
the correct panel_type on some machines.
We split the parsed VBT data (i915->vbt) along the same
boundary. For the moment we just hoist all the panel
specific stuff into connector->panel.vbt since that seems
like the most convenient place for eg. the backlight code.
Note that we simply drop the drrs type check from
intel_drrs_frontbuffer_update() since that operates on the whole
device rather than a specific connector/encoder. But the check
was just a micro optimization so removing it doesn't actually
mattter for correctness.
TODO: Lot's of cleanup to be done in the future. Eg. most of
the DSI stuff could probably be eliminated entirely and just
parsed on demand during DSI init.
v2: Note the intel_drrs_frontbuffer_update() change
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Instead of duplicating the fixed/downclock modes we can just grab
the originals straight from the probed_modes list and keep them.
The next .get_modes() is going to repopulate the probed_modes list
anyway so whatever we leave there is just going to sit around until
that time wasting memory. In fact let's clear out the probed modes
list entirely to make sure we get 100% consistent behaviour starting
already from the very first real .get_modes().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Rather than having the connector init get the fixed mode back from
intel_panel and then feed it straight back into intel_panel_init()
let's just make the fixed mode lookup put the mode directly onto
the panel's fixed_modes list. Avoids the pointless round trip and
opens the door for further enhancements to the fixed mode handling.
v2: Make the debug message correct by using intel_panel_drrs_type() (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Let's start supporting static DRRS by trying to match the refresh
rate the user has requested, assuming the panel supports suitable
timings.
For now we stick to just our current two timings:
- fixed_mode: the panel's preferred mode
- downclock_mode: the lowest refresh rate mode we found
Some panels may support more timings than that, but we'll
have to convert our fixed_mode/downclock_mode pointers
into a full list before we can handle that.
v2: Rebase due to intel_panel_get_modes()
Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-16-ville.syrjala@linux.intel.com
Abstract away the details on where we store the fixed/downclock
modes, and also how we select them. Will be useful for static
DRRS (aka. allowing the user to select the refresh rate for the
panel).
We pass in the user requested mode to intel_panel_fixed_mode()
so that in the future it may try to match the refresh rate.
And intel_panel_downclock_mode() gets passed the adjusted_mode
we actually chose to use so that it may find a suitable lower
resresh rate variant.
v2: Hook it up for all encoders
s/fixed_mode/adjusted_mode/ in intel_panel_downclock_mode() (Jani)
Elaborate on the choice or arguments for the functions (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Let's introduce a compute_config() helper for fixed mode panels.
For now all it does is the fixed_mode->adjusted_mode copy.
Note that with sDVO we have to ask the external encoder chip
to spit out our actual display timings for us, so the fixed_mode
to adjusted_mode copy done by intel_panel_compute_config() is
redundant, but we still want to use it to do other checks for us
later. We'll be fine so long as we only call it before
intel_sdvo_get_preferred_input_mode() overwrites adjusted_mode
with the timings from the encoder.
v2: Use intel_panel_compute_config() with sDVO
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927185207.13620-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Hoist the intel_de.h include from intel_display_types.h one
level up. I need this in order to untangle the include order
so that I can add tracepoints into intel_de.h.
This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
intel_de_read_fw(...)
|
intel_de_write(...)
|
intel_de_write_fw(...)
)
@has_include@
@@
(
#include "intel_de.h"
|
#include "display/intel_de.h"
)
@depends on find && !has_include@
@@
+ #include "intel_de.h"
#include "intel_display_types.h"
@depends on find && !has_include@
@@
+ #include "display/intel_de.h"
#include "display/intel_display_types.h"
Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com
Registering multiple backlight devices with intel_backlight name will
obviously fail, regardless of whether they're two connectors in the same
drm device or two different drm devices.
It would be preferrable to switch to completely unique names, and sunset
the generic intel_backlight name. However, there are apparently users
out there that hardcode the name, so the change would break backward
compatibility.
As a compromise, register the first device with intel_backlight name. In
the common case, this is the only backlight device anyway. From the
second device on, use card%d-%s-backlight format, for example
card0-eDP-2-backlight, to make the name unique.
This approach does not preclude us from registering the first device
using the same naming scheme in the future.
v2: Keep using intel_backlight name for first backlight device
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2794
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7dc3f6974711ce44522189dc9db05d1e6e24e6d8.1619604743.git.jani.nikula@intel.com
While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:
1) Why is the == comparison special that deserves a separate
macro instead of just getting the version and comparing directly
like is done for >, >=, <=?
2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
brevity. If we remove the current users of IS_DISPLAY_VER(), we
could actually repurpose it for a range check
With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.
So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:
@@ expression dev_priv, E1; @@
- !IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) != E1
@@ expression dev_priv, E1; @@
- IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) == E1
@@ expression dev_priv, from, until; @@
- IS_DISPLAY_RANGE(dev_priv, from, until)
+ IS_DISPLAY_VER(dev_priv, from, until)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN()
in the display code to use DISPLAY_VER() comparisons instead. The
following semantic patch was used:
@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_DISPLAY_VER(dev_priv, E)
@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ DISPLAY_VER(dev_priv)
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_DISPLAY_VER(dev_priv, E)
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_DISPLAY_RANGE(dev_priv, from, until)
There are still some display-related uses of INTEL_GEN() in intel_pm.c
(watermark code) and i915_irq.c. Those will be updated separately.
v2:
- Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.
On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.
For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:
* If the panel's VBT reports VESA backlight support, assume it really
does support it
* If the panel's VBT reports DDI backlight controls:
* First probe for Intel's HDR backlight interface
* If that fails, probe for VESA's backlight interface
* If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
doesn't have DPCD backlight controls
Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-4-lyude@redhat.com
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.
So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:
* We now keep track of two separate backlight level ranges, one for the
high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
enablement separately
* Since the currently set backlight level might not be the same as the
currently programmed PWM backlight level, we stop setting
panel->backlight.level with the currently programmed PWM backlight
level in panel->backlight.pwm_funcs->setup(). Instead, we rely
on the higher level backlight control functions to retrieve the
current PWM backlight level (in this case, intel_pwm_get_backlight()).
Note that there are still a few PWM backlight setup callbacks that
do actually need to retrieve the current PWM backlight level, although
we no longer save this value in panel->backlight.level like before.
Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.
v9:
* Drop the intel_panel_invert_pwm_level() call in lpt_setup_backlight()
* Remove leftover detritus from lpt_setup_backlight()
v8:
* Go back to getting initial brightness level with
intel_pwm_get_backlight(), the other fix we had was definitely wrong.
v7:
* Use panel->backlight.pwm_funcs->get() to get the backlight level in
intel_pwm_setup_backlight(), lest we upset lockdep
* Rebase
* Rename intel_panel_sanitize_pwm_level() to intel_panel_invert_pwm_level()
v6:
* Make sure to grab connection_mutex before calling
intel_pwm_get_backlight() in intel_pwm_setup_backlight()
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: thaytan@noraisin.net
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-3-lyude@redhat.com
In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup() is called before we've fully read in the
current hardware state into our atomic state, we can't grab atomic
modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some
PWM backlight functions (vlv_get_backlight() in particular) require knowing
the currently used pipe we need to be able to discern the current display
pipe through other means. Luckily, we're already passing the current
display pipe to intel_panel_bl_funcs->setup() so all we have to do in order
to achieve this is pass down that parameter to intel_panel_bl_funcs->get().
So, fix this by accepting an additional pipe parameter in
intel_panel_bl_funcs->get(), and leave figuring out the current display
pipe up to the caller.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-2-lyude@redhat.com
The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
functions operate directly on the hardware registers. If inverting the
value is needed, using intel_panel_compute_brightness(), it should only
be done in the interface between hardware registers and
panel->backlight.level.
The CPU mode takeover code added in commit 5b1ec9ac7a
("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
hardware register and converts to panel->backlight.level correctly,
however the value written back should remain in the hardware register
"domain".
This hasn't been an issue, because GM45 machines are the only known
users of i915.invert_brightness and the brightness invert quirk, and
without one of them no conversion is made. It's likely nobody's ever hit
the problem.
Fixes: 5b1ec9ac7a ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.1+
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com
Instead of using intel_panel->backlight.level, have the caller provide us
with the current panel backlight value. We'll need this for when we
separate PWM-related backlight callbacks from other means of backlight
control (like DPCD backlight controls), as the caller of each PWM callback
will be responsible for converting the current brightness value to it's
respective PWM level.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-4-lyude@redhat.com
Since the display hardware is all there even when INTEL_DISPLAY_ENABLED
return false we have to be capable of shutting it down cleanly so
as to not anger the hw. To that end let's reduce the effect of
!INTEL_DISPLAY_ENABLE to just treating all outputs as disconnected.
Should prevent anyone from automagically enabling any of them, while
still allowing us to cleanly shut them down.
v2: Put the check into the right place for CRT
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200910164256.25983-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastset path.
Note that this commit also simplifies pwm_disable_backlight(), by dropping
the intel_panel_actually_set_backlight(..., 0) call. This call sets the
PWM to 0% duty-cycle. I believe that this call was only present as a
workaround for a bug in the pwm-crc.c driver where it failed to clear the
PWM_OUTPUT_ENABLE bit. This is fixed by an earlier patch in this series.
After the dropping of this workaround, the usleep call, which seems
unnecessary to begin with, has no useful effect anymore, so drop that too.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-18-hdegoede@redhat.com
