#
bab87ef4 |
|
04-Jan-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Disable hotplug detection handlers during driver init/shutdown As described in the previous two patches an unexpected connector detection can happen during the init/shutdown sequences. Prevent these by returning the connector's current status from the detection handlers. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-10-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
|
#
94232d16 |
|
24-Oct-2023 |
Jouni Högander <jouni.hogander@intel.com> |
drm/i915/display: Move panel_use_ssc module parameter under display Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231024124109.384973-8-jouni.hogander@intel.com
|
#
fe63ea7c |
|
03-Oct-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: convert INTEL_DISPLAY_ENABLED() into a function There's no need for this to be a macro. Add some documentation too. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/480b9b697b2ffa0c8677115bd443ba633801c6c1.1696336887.git.jani.nikula@intel.com
|
#
f0f7ec74 |
|
01-Sep-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Relocate is_in_vrr_range() Move is_in_vrr_range() into intel_vrr.c in anticipation of more users, and rename it accordingly. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-8-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
e27525cc |
|
18-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Namespace pfit registers properly Give the PFIT_CONTROL bits a consistent namespace. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
08df6d30 |
|
18-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use REG_BIT() & co for the pre-ilk pfit registers Modernize the gmch pfit register definitions using REG_BIT/etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
a2da6702 |
|
04-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Allow arbitrary refresh rates with VRR eDP panels If the panel supports VRR it must be capable of accepting timings with arbitrary vblank length, within the valid VRR range. Use that fact to allow the user to request any refresh rate they like. We simply pick the next highest fixed mode from our list, and adjust the vblank to get the desired refresh rate in the end. Of course currently everything to do with the vrefresh is using 1Hz precision, so might not be exact. But we can improve that in the future by just upping our vrefresh precision. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404175431.23064-1-ville.syrjala@linux.intel.com Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
#
16bede13 |
|
31-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/lvds: Extract intel_lvds_regs.h Extract the integrated LVDS port register definitions into their own header file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
15d045fd |
|
25-Jan-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/panel: move panel fixed EDID to struct intel_panel It's a bit confusing to have two cached EDIDs in struct intel_connector with slightly different purposes. Make the distinction a bit clearer by moving the EDID cached for eDP and LVDS panels at connector init time to struct intel_panel, and name it fixed_edid. That's what it is, a fixed EDID for the panels. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> 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/328350ef918638928a8286cdbab3107c8258332d.1674643465.git.jani.nikula@intel.com
|
#
bf38bba3 |
|
25-Nov-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Try to use the correct power sequencer intiially on bxt/glk Currently on bxt/glk we just grab the power sequencer index from the VBT data even though it may not have been parsed yet. That could lead us to using the incorrect power sequencer during the initial panel probe. To avoid that let's try to read out the current state of the power sequencer from the hardware. Unfortunately the power sequencer no longer has anything in its registers to associate it with the port, so the best we can do is just iterate through the power sequencers and pick the first one. This should be sufficient for single panel cases. For the dual panel cases we probably need to go back to parsing the VBT before the panel probe (and hope that panel_type=0xff is never a thing in those cases). To that end the code always prefers the VBT panel sequencer, if available. v2: Restructure a bit for upcoming icp+ dual PPS support Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-5-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
|
#
3f9ffce5 |
|
25-Nov-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Do panel VBT init early if the VBT declares an explicit panel type Lots of ADL machines out there with bogus VBTs that declare two eDP child devices. In order for those to work we need to figure out which power sequencer to use before we try the EDID read. So let's do the panel VBT init early if we can, falling back to the post-EDID init otherwise. The post-EDID init panel_type=0xff approach of assuming the power sequencer should already be enabled doesn't really work with multiple eDP panels, and currently we just end up using the same power sequencer for both eDP ports, which at least confuses the wakeref tracking, and potentially also causes us to toggle the VDD for the panel when we should not. Cc: Animesh Manna <animesh.manna@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/20221125173156.31689-3-ville.syrjala@linux.intel.com
|
#
f70f8153 |
|
25-Nov-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_init_alloc() Introduce a place where we can initialize connector->panel after it's been allocated. We already have a intel_panel_init() so had to get creative with the name and came up with intel_panel_init_alloc(). Cc: Animesh Manna <animesh.manna@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/20221125173156.31689-2-ville.syrjala@linux.intel.com
|
#
801543b2 |
|
09-Nov-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: stop including i915_irq.h from i915_trace.h Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place. Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place. Also some places actually needed i915_irq.h too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> 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/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
|
#
2bd0db4b |
|
19-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Allow panel fixed modes to have differing sync polarities Apparently some panels declare multiple modes with random sync polarities. Seems a bit weird, but looks like Windows/GOP doesn't care, so let follow suit and accept alternate fixed modes regardless of their sync polarities. v2: Don't pollute the DRM_ namespace with a define (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6968 Acked-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/20221020093938.27200-1-ville.syrjala@linux.intel.com
|
#
22d9a255 |
|
03-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Setup final panel drrs_type already during init Now that we track the VBT drrs type per-panel we can move the has_drrs_modes() check to the panel init rather than doing it for every intel_panel_drrs_type() call. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003113249.16213-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
d1af925b |
|
03-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Tighten DRRS capability reporting Only report DRRS capability for the connector if its fixed_modes list contains at least two modes capable of seamless DRRS switch between them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003113249.16213-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
eb89e83c |
|
27-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes() Since commit a5810f551d0a ("drm/i915: Allow more varied alternate fixed modes for panels") intel_panel_add_edid_alt_fixed_modes() no longer considers vrr vs. drrs separately. So no reason to pass them as separate parameters either. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
d372ec94 |
|
27-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes() Since commit a5810f551d0a ("drm/i915: Allow more varied alternate fixed modes for panels") intel_panel_add_edid_alt_fixed_modes() no longer considers vrr vs. drrs separately. So no reason to pass them as separate parameters either. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit eb89e83c152b122a94e79527d63cb7c79823c37e) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
74d6f31f |
|
06-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add intel_panel_highest_mode() Add a function to get the fixed_mode with the highest clock. The plan is to use this for the link bw calculation on seamless DRRS panels so that we alwasy end up with the same link params regardless of the requested refresh rate. This will allow fastset to do seamless refresh rate changes based on userspace request instead of having to go for a full modeset. TODO: the function name isn't great 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/20220907091057.11572-15-ville.syrjala@linux.intel.com
|
#
a5810f55 |
|
30-Aug-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Allow more varied alternate fixed modes for panels On some systems the panel reports alternate modes with different blanking periods. If the EDID reports them and VBT doesn't tell us otherwise then I can't really see why they should be rejected. So allow their use for the purposes of static DRRS. For seamless DRRS we still require a much more exact match of course. But that logic only kicks in when selecting the downclock mode (or in the future when determining whether we can do a seamless refresh rate change due to a user modeset). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6374 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220830212436.2021-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
0c82118b |
|
29-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/quirks: abstract checking for display quirks Add intel_has_quirk() for checking if a display quirk is present. Avoid accessing i915->quirks all over the place. v2: Rebase Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/74f954ca81a8068033141a15686dffd01ad9b0f9.1661779055.git.jani.nikula@intel.com
|
#
a434689c |
|
29-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move vbt to display.vbt Move display VBT related members under drm_i915_private display sub-struct. v2: Rebase Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/db4b648b201ea0b79654fec2028120999a735db0.1661779055.git.jani.nikula@intel.com
|
#
6e939738 |
|
31-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Accept more fixed modes with VRR panels It seem that when dealing with VRR capable eDP panels we need to accept fixed modes with variable vblank length (which is what VRR varies dynamically). Typically the preferred mode seems to be a non-VRR more (lowish dotclock/refresh rate + short vblank). We also have examples where it looks like even the hblank length is a bit different between the preferred mode vs. VRR mode(s). So let's just accept anything that has matching hdisp+vdisp+flags. v2: Document that is_alt_drrs_mode() is a subset of is_alt_vrr_mode() (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125 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/20220531191844.11313-4-ville.syrjala@linux.intel.com
|
#
2db7d421 |
|
31-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Print out rejected fixed modes To help with debugging DRRS/VRR panel init let's dump out all the fixed modes we rejected for whatever reason. 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/20220531191844.11313-3-ville.syrjala@linux.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>
|
#
949665a6 |
|
04-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Respect VBT seamless DRRS min refresh rate Make sure our choice of downclock mode respects the VBT seameless DRRS min refresh rate limit. v2: s/vrefesh/vrefresh/ (Jani) 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/20220504150440.13748-10-ville.syrjala@linux.intel.com
|
#
c19909d0 |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Allow higher refresh rate alternate fixed modes We shouldn't restrict ourselves to just downclock modes with lower refresh rate than the preferred mode. Laptops these days can offer higher refresh rate modes as well. Remove the arbitrary limit and allow all modes that, apart from the clock, match the preferred mode. v2: s/add_edid_downclock_modes/add_edid_alt_fixed_modes/ (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
7634bef1 |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Allow an arbitrary number of downclock modes Remove the "two fixed modes only" limit and grab as many downclock modes from the EDID as we can find. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
ccaa9101 |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stop duplicating the EDID fixed/downclock modes 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>
|
#
3a3c4ce9 |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Combine the EDID fixed_mode+downclock_mode lookup into one The intel_panel_add_edid_fixed_mode() vs. intel_panel_add_edid_downclock_mode() split is not really helpful. Let's just roll those into a single function so that the connector init code doesn't have to care too much about this. All we need to know is whether DRRS should be allowed or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
05d2d45e |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Nuke intel_drrs_init() intel_drrs_init() is a mostly pointless wrapper around intel_panel_add_edid_downclock_mode(), get rid of it. The only really useful thing left in there is the debug print regarding the DRRS type supported by the connector. Let's just move that into intel_panel_init(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
54746f57 |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Refactor non-EDID fixed mode duplication All the non-EDID fixed mode functions basically do the exact same thing. Let's refactor the common bits into a shared function. There are minor differences on how the mode types are populated, whether the display info physical size is updated, and the debug print. The differences are purely accidental, so unifying them is actually a good thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
db10c14a |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Put fixed modes directly onto the panel's fixed_modes list 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>
|
#
5248cc78 |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_panel_encoder_fixed_mode() Apart from the EDID and VBT based mechanism we also sometimes use the encoder's current mode as the panel fixed mode. We currently have the same code for that duplicated in two places. Let's unify. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
14daee24 |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_panel_vbt_sdvo_fixed_mode() We have a function for duplicating the VBT LFP mode. Add the same for the VBT SDVO mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
688a9bbc |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rename intel_panel_vbt_fixed_mode() Rename intel_panel_vbt_fixed_mode() to intel_panel_vbt_lfp_fixed_mode() to be more descriptive. We'll have another VBT fixed mode function soon and we don't want to confuse the two. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
f01bae2d |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use DRM_MODE_FMT+DRM_MODE_ARG() Replace all drm_mode_debug_printmodeline() calls with DRM_MODE_FMT+DRM_MODE_ARG(). Makes the debug output a bit more terse in places where we previously had a newline in the precedeing drm_dbg_kms(), and avoids anything else sneaking in between the two printk()s in all cases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
5d2fd49d |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass intel_connector to intel_panel_{init,fini}() All the other intel_panel functions take struct intel_connector, so might as well make init()/fini() take one as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
345b7c4b |
|
14-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Convert fixed_mode/downclock_mode into a list Store the fixed_mode and downclock_mode as a real list, in preparation for exposing other supported modes as well. v2: Init the list in intel_sdvo_connector_alloc() too v3: Use list_first_entry_or_null() (Jani) 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/20220314152737.9125-1-ville.syrjala@linux.intel.com
|
#
c5ee2343 |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement static DRRS 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
|
#
f0a57798 |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_drrs_type() Add a helper to determine which type of DRRS the panel supports. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
43af6743 |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_preferred_fixed_mode() There are a couple of cases where we essentially just want to get/check the preferred fixed mode of the panel. Add a small helper for that to abstract away the direct pointer lookup. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
53f64f3a |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_get_modes() Several connectors want to return the fixed_mode from .get_modes(), add a helper to do that (and hide the details inside intel_panel.c). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
09270678 |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_{fixed,downclock}_mode() 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>
|
#
26111a16 |
|
23-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Start tracking PIPESRC as a drm_rect Instead of just having the pipe_src_{w,h} let's use a full drm_rect for it. This will be particularly useful to astract away some bigjoiner details. v2: No hweight() stuff yet Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-11-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
f5b8c316 |
|
29-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reject user modes that don't match fixed mode's refresh rate When using a panel with a fixed mode we don't change the refresh rate of the display. Reject any user requested mode which doesn't match that fixed refresh rate. Unfortunately when Xorg sees the scaling_mode property on the connecor it likes to automagically cook up modes whose refresh rate is a fair bit off from the fixed refresh rate we use. So we have to give it some extra latitude so that we don't start to reject all of it. v2: sDVO now uses intel_panel_compute_config() too v3: Add a debug message to inform the user what happened References: https://gitlab.freedesktop.org/drm/intel/-/issues/2939 References: https://gitlab.freedesktop.org/drm/intel/-/issues/3969 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929184536.8332-1-ville.syrjala@linux.intel.com
|
#
cff4c2c6 |
|
27-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_compute_config() 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>
|
#
00fc3787 |
|
23-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reject modes that don't match fixed_mode vrefresh When using a fixed mode we won't change the refresh rate ever. So filter out all modes that don't match the fixed_mode's refresh rate. I'm going to declare the "rounded to nearest Hz refresh rates must match" approach good enough for now. Note that we could start supporting multiple refresh rates with panels that can do it, but that would mean replacing the single fixed mode concept with a list of fixed modes. Then we could look for the closest match to the user's requested refresh rate and use that. But all of that would be a fair bit of work so we'll leave it for later. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2939 References: https://gitlab.freedesktop.org/drm/intel/-/issues/3969 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210923200109.4459-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
08243606 |
|
23-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_panel_mode_valid() Extract intel_panel_mode_valid() from the eDP code to a generic helper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210923200109.4459-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
4b93f49d |
|
25-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/panel: mass rename functions to have intel_panel_ prefix Follow the usual naming conventions. Also pull HAS_GMCH() check to intel_panel_fitting(). No functional changes. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9ff6e42e377bdb0c9349f50d9ea79671059633c7.1629888677.git.jani.nikula@intel.com
|
#
c0a52f8b |
|
25-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/backlight: mass rename functions to have intel_backlight_ prefix Follow the usual naming conventions. As a drive-by cleanup, also pass intel_connector instead of drm_connector to intel_backlight_setup(). No functional changes. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ea1c22370210abdd4f5547af73c71b902061ea50.1629888677.git.jani.nikula@intel.com
|
#
6cc42fbe |
|
25-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/backlight: extract backlight code to a separate file In a long overdue refactoring, split out backlight code to new intel_backlight.[ch]. Simple code movement, leave renames for follow-up work. No functional changes. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/97d310848f03061473b9b2328e2c5c4dcf263cfa.1629888677.git.jani.nikula@intel.com
|
#
3c6a4a02 |
|
18-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/panel: move intel_panel_use_ssc() out of headers There's no performance reason to have it as static inline; move it out of intel_display_types.h to reduce clutter and dependency on i915_drv.h. 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/6f2c05005e4fa43a5572b02b3f41363725ffdb4f.1629281426.git.jani.nikula@intel.com
|
#
7785ae0b |
|
30-Apr-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't include intel_de.h from intel_display_types.h 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
|
#
20f85ef8 |
|
28-Apr-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/backlight: use unique backlight device names 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
|
#
b08a759d |
|
28-Apr-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/backlight: clean up backlight device register Add connector and backlight device name to logging, and propagate error code from backlight_device_register() instead of flattening to -ENODEV. Storing the name in an allocated buffer is unnecessary here, but makes follow-up work on names much cleaner. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> 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/271206461d9c0f42755792236330b588df3b532e.1619604743.git.jani.nikula@intel.com
|
#
93e7e61e |
|
12-Apr-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/display: rename display version macros 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
|
#
2446e1d6 |
|
07-Apr-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate IS_GEN9_{BC,LP} Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com (cherry picked from commit 70bfb30743d5da73058b0a2271e9c127a84fb494) [Jani: cherry picked to topic branch to reduce conflicts] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
70bfb307 |
|
07-Apr-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate IS_GEN9_{BC,LP} Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com
|
#
005e9537 |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate most usage of INTEL_GEN() 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
|
#
8ff5446a |
|
28-Jan-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Remove references to struct drm_device.pdev Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v6: * also remove assignment in selftests/ in a later patch (Chris) v5: * remove assignment in later patch (Chris) v3: * rebased v2: * move gt/ and gvt/ changes into separate patches Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-2-tzimmermann@suse.de
|
#
4a8d7990 |
|
29-Jun-2020 |
Lyude Paul <lyude@redhat.com> |
drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) 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
|
#
a575c00e |
|
11-Sep-2020 |
Lyude Paul <lyude@redhat.com> |
drm/i915: Keep track of pwm-related backlight hooks separately 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
|
#
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
|
#
0d4ced1c |
|
08-Jan-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/backlight: fix CPU mode backlight takeover on LPT 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 5b1ec9ac7ab5 ("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: 5b1ec9ac7ab5 ("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
|
#
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
|
#
390218ca |
|
04-Dec-2020 |
Lyude Paul <lyude@redhat.com> |
drm/i915: Rename pwm_* backlight callbacks to ext_pwm_* Since we're going to need to add a set of lower-level PWM backlight control hooks to be shared by normal backlight controls and HDR backlight controls in SDR mode, let's add a prefix to the external PWM backlight functions so that the difference between them and the high level PWM-only backlight functions is a bit more obvious. This introduces no functional changes. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Cc: thaytan@noraisin.net Cc: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204223603.249878-3-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
|
#
bb83d5fb |
|
08-Jan-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/backlight: fix CPU mode backlight takeover on LPT 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 5b1ec9ac7ab5 ("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: 5b1ec9ac7ab5 ("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 (cherry picked from commit 0d4ced1c5bfe649196877d90442d4fd618e19153) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
b81dddb9 |
|
10-Sep-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnected 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>
|
#
f8bd54d2 |
|
03-Sep-2020 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: panel: Use atomic PWM API for devs with an external PWM controller 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
|
#
9a6ae5b3 |
|
03-Sep-2020 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: panel: Honor the VBT PWM min setting for devs with an external PWM controller So far for devices using an external PWM controller (devices using pwm_setup_backlight()), we have been hardcoding the minimum allowed PWM level to 0. But several of these devices specify a non 0 minimum setting in their VBT. Change pwm_setup_backlight() to use get_backlight_min_vbt() to get the minimum level. 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-17-hdegoede@redhat.com
|
#
6b51e7d2 |
|
03-Sep-2020 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller So far for devices using an external PWM controller (devices using pwm_setup_backlight()), we have been hardcoding the period-time passed to pwm_config() to 21333 ns. I suspect this was done because many VBTs set the PWM frequency to 200 which corresponds to a period-time of 5000000 ns, which greatly exceeds the PWM_MAX_PERIOD_NS define in the Crystal Cove PMIC PWM driver, which used to be 21333. This PWM_MAX_PERIOD_NS define was actually based on a bug in the PWM driver where its period and duty-cycle times where off by a factor of 256. Due to this bug the hardcoded CRC_PMIC_PWM_PERIOD_NS value of 21333 would result in the PWM driver using its divider of 128, which would result in a PWM output frequency of 6000000 Hz / 256 / 128 = 183 Hz. So actually pretty close to the default VBT value of 200 Hz. Now that this bug in the pwm-crc driver is fixed, we can actually use the VBT defined frequency. This is important because: a) With the pwm-crc driver fixed it will now translate the hardcoded CRC_PMIC_PWM_PERIOD_NS value of 21333 ns / 46 Khz to a PWM output frequency of 23 KHz (the max it can do). b) The pwm-lpss driver used on many models has always honored the 21333 ns / 46 Khz request Some panels do not like such high output frequencies. E.g. on a Terra Pad 1061 tablet, using the LPSS PWM controller, the backlight would go from off to max, when changing the sysfs backlight brightness value from 90-100%, anything under aprox. 90% would turn the backlight fully off. Honoring the VBT specified PWM frequency will also hopefully fix the various bug reports which we have received about users perceiving the backlight to flicker after a suspend/resume cycle. 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-16-hdegoede@redhat.com
|
#
27a79cbc |
|
03-Sep-2020 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: panel: Add get_vbt_pwm_freq() helper Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency out of get_backlight_max_vbt(). This is a preparation patch for honering the VBT PWM frequency for devices which use an external PWM controller (devices using pwm_setup_backlight()). 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-15-hdegoede@redhat.com
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
8a25c4be |
|
18-Jun-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/params: switch to device specific parameters Start using device specific parameters instead of module parameters for most things. The module parameters become the immutable initial values for i915 parameters. The device specific parameters in i915->params start life as a copy of i915_modparams. Any later changes are only reflected in the debugfs. The stragglers are: * i915.force_probe and i915.modeset. Needed before dev_priv is available. This is fine because the parameters are read-only and never modified. * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and I915_STATE_WARN_ON would result in massive and ugly churn. This is handled by not exposing the parameter via debugfs, and leaving the parameter writable in sysfs. This may be fixed up in follow-up work. * i915.inject_probe_failure. Only makes sense in terms of the module, not the device. This is handled by not exposing the parameter via debugfs. v2: Fix uc i915 lookup code (Michał Winiarski) Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
|
#
899c537c |
|
02-Jun-2020 |
Guru Das Srinagesh <gurus@codeaurora.org> |
drm/i915: Use 64-bit division macro Since the PWM framework is switching struct pwm_state.duty_cycle's datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle a 64-bit dividend. Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
#
aa7b3df8 |
|
28-Apr-2020 |
Arnd Bergmann <arnd@arndb.de> |
drm/i915: avoid unused scale_user_to_hw() warning After the function is no longer marked 'inline', there is now a new warning pointing out that the only caller is inside of an #ifdef: drivers/gpu/drm/i915/display/intel_panel.c:493:12: warning: 'scale_user_to_hw' defined but not used [-Wunused-function] 493 | static u32 scale_user_to_hw(struct intel_connector *connector, | ^~~~~~~~~~~~~~~~ Move the function itself into that #ifdef as well. Fixes: 81b55ef1f47b ("drm/i915: drop a bunch of superfluous inlines") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200428213106.3139170-1-arnd@arndb.de (cherry picked from commit 794bdcf71f47b98f6e003190069d5064123067ed) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
794bdcf7 |
|
28-Apr-2020 |
Arnd Bergmann <arnd@arndb.de> |
drm/i915: avoid unused scale_user_to_hw() warning After the function is no longer marked 'inline', there is now a new warning pointing out that the only caller is inside of an #ifdef: drivers/gpu/drm/i915/display/intel_panel.c:493:12: warning: 'scale_user_to_hw' defined but not used [-Wunused-function] 493 | static u32 scale_user_to_hw(struct intel_connector *connector, | ^~~~~~~~~~~~~~~~ Move the function itself into that #ifdef as well. Fixes: 81b55ef1f47b ("drm/i915: drop a bunch of superfluous inlines") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200428213106.3139170-1-arnd@arndb.de
|
#
d7ff281c |
|
22-Apr-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Have pfit calculations return an error code Change intel_{gmch,pch}_panel_fitting() to return a normal error vs. success int. We'll need this later to validate that the margin properties aren't misconfigured. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-6-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
4cecc7c0 |
|
22-Apr-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass connector state to pfit calculations Pass the entire connector state to intel_{gmch,pch}_panel_fitting(). For now we just need to get at .scaling_mode but in the future we'll want access to the margin properties as well. v2: Deal with intel_dp_ycbcr420_config() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-5-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
f650af72 |
|
22-Apr-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/pipe_config/crtc_state/ in pfit functions Follow the new naming convention and call the crtc state "crtc_state", and while at it drop the redundant crtc argument. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-4-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
35dd95b4 |
|
22-Apr-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use drm_rect to store the pfit window pos/size Make things a bit more abstract by replacing the pch_pfit.pos/size raw register values with a drm_rect. Makes it slighly more convenient to eg. compute the scaling factors. v2: Use drm_rect_init() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422161917.17389-3-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
81b55ef1 |
|
20-Apr-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: drop a bunch of superfluous inlines Remove a number of inlines from .c files, and let the compiler decide what's best. There's more to do, but need to start somewhere, and need to start setting the example. 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/20200420140438.14672-2-jani.nikula@intel.com
|
#
2b3c472c |
|
02-Apr-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/panel: use struct drm_device based logging Convert all the DRM_* logging macros to the struct drm_device based macros to provide device specific logging. No functional changes. Generated using the following semantic patch, originally written by Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_NOTE( +drm_notice(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Cc: Wambui Karuga <wambui.karugax@gmail.com> Reviewed-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200402114819.17232-2-jani.nikula@intel.com
|
#
ede9771d |
|
13-Mar-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass atomic state to encoder hooks We're going to want access to the atomic state for iterating the slave crtcs when enabling the port sync master crtc. Pass the atomic state all the way down. The alternative would be yet another encoder hook which we'll have to call after all the normal modeset stuff is done. Not really a fan of yet another hook just for this. Note that during readout state sanitation we are now going to pass NULL as the atomic state since we don't have one. We need to change that and then we can also s/crtc_state/crtc/ and s/conn_state/conn/ for the encoder hooks as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313164831.5980-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
d59b1d1b |
|
21-Feb-2020 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: panel: Use intel_panel_compute_brightness() from pwm_setup_backlight() Use intel_panel_compute_brightness() from pwm_setup_backlight() so that we correctly take i915_modparams.invert_brightness and/or QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial brightness value. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-1-hdegoede@redhat.com
|
#
9877db7d |
|
12-Feb-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Parametrize PFIT_PIPE Make the PFIT_PIPE stuff less ugly via parametrization. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
b04002f4 |
|
16-Feb-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Read rawclk_freq earlier Read the rawclk_freq during runtime info probing, prior to its first use in computing the CS timestamp frequency. Then store it in the runtime info, and include it in the debug printouts. Closes: https://gitlab.freedesktop.org/drm/intel/issues/834 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200216163445.555786-1-chris@chris-wilson.co.uk
|
#
e9318906 |
|
30-Jan-2020 |
Wambui Karuga <wambui.karugax@gmail.com> |
drm/i915/panel: automatic conversion to drm_device based logging macros. Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_panel.c using the following coccinelle script that transforms based on the existence of a struct drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were addressed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200130083229.12889-13-wambui.karugax@gmail.com
|
#
48522d3e |
|
28-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915/display/panel: Make WARN* drm specific where drm_priv 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_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. @rule1@ 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, ...) ) ...+> } @rule2@ 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-16-pankaj.laxminarayan.bharadiya@intel.com
|
#
0fac5a7c |
|
24-Jan-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/panel: use intel_de_*() functions for register access The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/efd117ff0a63ef6ec1a4514f2ee133ca33b3f0a0.1579871655.git.jani.nikula@intel.com
|
#
b6941311 |
|
16-Dec-2019 |
Hans de Goede <hdegoede@redhat.com> |
drm/i915: DSI: select correct PWM controller to use based on the VBT At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. This commit fixes using the wrong PWM controller on these devices by calling pwm_get() for the right PWM controller based on the VBT dsi.config.pwm_blc bit. Note this is part of a series which contains 2 other patches which renames the PWM lookup for the 1st SoC/LPSS PWM from "pwm_backlight" to "pwm_pmic_backlight" and the PWM lookup for the Crystal Cove PMIC PWM from "pwm_backlight" to "pwm_pmic_backlight". Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-4-hdegoede@redhat.com
|
#
2225f3c6 |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Perform automated conversions for crtc uapi/hw split, base -> uapi. Split up crtc_state->base to uapi. This is done using the following patch, ran after the previous commit that splits out any hw references: @@ struct intel_crtc_state *T; @@ -T->base +T->uapi Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-5-maarten.lankhorst@linux.intel.com
|
#
1326a92c |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Perform automated conversions for crtc uapi/hw split, base -> hw. Split up crtc_state->base to hw where appropriate. This is done using the following patch: @@ struct intel_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -T->base.x +T->hw.x @@ struct drm_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -to_intel_crtc_state(T)->base.x +to_intel_crtc_state(T)->hw.x Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-4-maarten.lankhorst@linux.intel.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
|