#
b3baf0c0 |
|
15-Feb-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make backlight setup debugs consistent It's confusing to debug backlight issues when one can't easily even tell what kind of backlight control was selected. Sprinkle uniform debug messages to all the backlight setup functions. Also the one that was already there (ext_pwm) was using drm_info() for some reason. I don't think that's warranted so switch it to drm_dbg_kms() as well. v2: Deal with AUX backlights too (Jani) Move the VLV/CHV initial pipe debug there too (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230215135616.30411-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
75217c2f |
|
16-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dsi: use VBT backlight and CABC port definitions directly Drop the intermediate values stored in intel_dsi and use the VBT values directly, now that they're conveniently stored in panel->vbt. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8b3765f1e1dc4d436b312016f72647e03ba49f94.1660664162.git.jani.nikula@intel.com
|
#
3cf05076 |
|
10-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/bios: Split VBT data into per-panel vs. global parts 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>
|
#
d1260be7 |
|
09-Nov-2021 |
William Tseng <william.tseng@intel.com> |
drm/i915/dsi: transmit brightness command in HS state In Video Mode, if DSI transcoder is set to transmit packets in LP Escape mode, screen flickering would be obseved when brightness commands are continuously and quickly transmitted to a panel. The problem may be resolved by changing the mode to transmit packets from Low Power to HS. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: William Tseng <william.tseng@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110010217.26759-1-william.tseng@intel.com
|
#
ddb8cd4e |
|
08-Sep-2021 |
Lee Shawn C <shawn.c.lee@intel.com> |
drm/i915/dsi: Read/write proper brightness value via MIPI DCS command Driver has to swap the endian before send brightness level value to tcon. v2: Use __be16 instead of u16 to fix sparse warning. v3: Send one or two bytes brightness value depend on the precision. v4: get data length of brightness value more easily. Reported-by: kernel test robot <lkp@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-6-shawn.c.lee@intel.com
|
#
84d3d71f |
|
08-Sep-2021 |
Lee Shawn C <shawn.c.lee@intel.com> |
drm/i915/dsi: Retrieve max brightness level from VBT So far, DCS backlight driver hardcode (0xFF) for max brightness level. MIPI DCS spec allow max 0xFFFF for set_display_brightness (51h) command. And VBT brightness precision bits can support 8 ~ 16 bits. We should set correct precision bits in VBT that meet panel's request. Driver can refer to this setting then configure max brightness level in DCS backlight driver properly. v2: modify variable name brightness_precision_bits instead of max_brightness_level. v3: fix checkpatch warning. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-5-shawn.c.lee@intel.com
|
#
31b10c1a |
|
14-Jan-2021 |
Lyude Paul <lyude@redhat.com> |
drm/i915: Pass port to intel_panel_bl_funcs.get() 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
|
#
6423cb7f |
|
04-Dec-2020 |
Lyude Paul <lyude@redhat.com> |
drm/i915: Pass down brightness values to enable/disable backlight callbacks 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
|
#
1494a1de |
|
30-Nov-2020 |
Dave Airlie <airlied@redhat.com> |
drm/i915: refactor panel backlight control functions. (v2) This moves the functions into static const instead of having funcs and data in the same struct. It leaves the power callback alone, as it is used in a different manner. v2: leave power callback alone (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130210945.31850-1-airlied@gmail.com
|
#
f4224a4c |
|
28-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915/display: Make WARN* drm specific where drm_device ptr is available drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule4@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-20-pankaj.laxminarayan.bharadiya@intel.com
|
#
fa7edcd2 |
|
04-Dec-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use intel_attached_encoder() It's easy to confuse the drm_connector->encoder (legacy state adjusted during modeset) and intel_connector->encoder (the statically (sans. MST) attached encoder of the connector). For the latter let's use intel_attached_encoder() consistently. @@ identifier F !~ "^intel_attached_encoder$"; struct intel_connector *C; expression E; @@ F(...) { <... ( C->encoder = E | - C->encoder + intel_attached_encoder(C) ) ...> } @@ identifier F !~ "^intel_attached_encoder$"; struct drm_connector *C; expression E; @@ F(...) { <... ( to_intel_connector(C)->encoder = E | - to_intel_connector(C)->encoder + intel_attached_encoder(to_intel_connector(C)) ) ...> } v2: Regenerated Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-6-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
|
#
b7d02c3a |
|
04-Dec-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass intel_encoder to enc_to_*() Lots of enc_to_foo(&encoder->base) around. Simplify by passing in the intel_encoder instead. @find@ identifier F =~ "^enc_to_.*"; identifier E; @@ F(struct drm_encoder *E) { ... } @@ identifier find.F; identifier find.E; @@ F( - struct drm_encoder *E + struct intel_encoder *encoder ) { <... - E + &encoder->base ...> } @@ identifier find.F; expression E; @@ - F(E) + F(to_intel_encoder(E)) @@ expression E; @@ - to_intel_encoder(&E->base) + E Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-4-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
|
#
1d455f8d |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: rename intel_drv.h to display/intel_display_types.h Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the include guard name in the renamed file Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com
|
#
379bc100 |
|
13-Jun-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move modesetting output/encoder code under display/ Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-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/20190613084416.6794-2-jani.nikula@intel.com
|