Cc: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-6-matthew.d.roper@intel.com

If VT-d is active, the memory bandwidth usage of the display is 5%
higher.  Take this into account when determining whether we can support
a display configuration.

Bspec: 64631
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-5-matthew.d.roper@intel.com

Aside from the hardware-managed PG0, XE_LPD has power wells 1-2 and
A-D.  These power wells should be enabled/disabled according to the
following dependency tree (enable top to bottom, disable bottom to top):

               PG0
                |
             --PG1--
            /       \
          PGA     --PG2--
                 /   |   \
               PGB  PGC  PGD

PWR_WELL_CTL follows the general ICL/TGL design and places PG A-D in the
bits that would have been PG 6-9 under the old scheme.

PWR_WELL_CTL_{DDI,AUX}'s bit indexing for DDI's A-C and TC1 is the same
as TGL, but DDI-D is placed at index 7 (bits 14 & 15).

v2:
 - Squash in LPSP status patch from Uma since it's also a
   powerwell-specific change.

Bspec: 49233
Bspec: 49503
Bspec: 49504
Bspec: 49505
Bspec: 49296
Bspec: 50090
Bspec: 53920
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-4-matthew.d.roper@intel.com

XE_LPD's plane support is identical to RKL and ADL-S --- 5 universal + 1
cursor with NV12 UV support on planes 1-3 and NV12 Y support on planes
4-5.

v2:
 - Drop the extra 90/270 rotation check in skl_plane_check_fb(); the DRM
   property code will already prevent userspace from passing us values
   that weren't advertised.  (Lucas)

Bspec: 53657
Bspec: 49251
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-3-matthew.d.roper@intel.com

Fix the typo in DPCD caps used for checking SRC CTL mode of
HDMI2.1 PCON

v2: Corrected Fixes tag (Jani Nikula).
v3: Rebased.

Fixes: 04b6603d ("drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available")

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: "Ville Syrj_l_" <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: NSwati Sharma <swati2.sharma@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210511120930.12218-1-ankit.k.nautiyal@intel.com

This workaround requires that VIDEO_DIP_ENABLE_VSC_HSW is never set
with PSR.

BSpec: 54369
BSpec: 54077
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-5-jose.souza@intel.com

HSW_TVIDEO_DIP_CTL is read but not used.
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-4-jose.souza@intel.com

No functional changes in here.

Cc: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-3-jose.souza@intel.com

All of this places don't need to intel_psr_enabled() that will lock
psr mutex, check state and unlock.

Instead it can directly check PSR state in intel_crtc_state, the only
place that was not possible was intel_read_dp_vsc_sdp() but since
"drm/i915/display: Fill PSR state during hardware configuration read
out" it is possible.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-2-jose.souza@intel.com

So far if we had a mismatch between the state asked and what was
programmed in hardware for PSR, this mismatch would go unnoticed.

So here adding the PSR to the hardware configuration readout,
EDP_PSR_CTL and EDP_PSR2_CTL can't be directly read because its state
flips due to other factors like frontbuffer modifications and CRC.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-1-jose.souza@intel.com

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.
Signed-off-by: NWerner Sembach <wse@tuxedocomputers.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-4-wse@tuxedocomputers.com

Couples the decission between RGB and YCbCr420 mode and the check if the
port clock can archive the required frequency. Other checks and
configuration steps that where previously done in between can also be done
before or after.

This allows for are cleaner implementation of retrying different color
encodings.

A slight change in behaviour occurs with this patch: If YCbCr420 is not
allowed but display is YCbCr420 only it no longer fails, but just prints
an error and tries to fallback on RGB.
Signed-off-by: NWerner Sembach <wse@tuxedocomputers.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-3-wse@tuxedocomputers.com

Moves some checks that later will be performed 2 times to an own function.
This avoids duplicate code later on.
Signed-off-by: NWerner Sembach <wse@tuxedocomputers.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-2-wse@tuxedocomputers.com

Instead of poluting the normal code path in intel_display.c, make
intel_bios.c handle the brokenness of the VBT.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-5-lucas.demarchi@intel.com

Direction on gen9+ was to stop reading the straps and only rely on the
VBT for marking the port presence. This happened while dealing with
WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
normal flow. See commit 885d3e5b ("drm/i915/display: fix comment on
skl straps").

For gen 10 it's hard to say if this will work or not since I can't test
it, so leave it with the same behavior as before.

For PCH_TGP we should still rely on the VBT to make ports E and F not
available.

v2 (Ville):
  - use display ver >= 9 to make it consistent with the rest of the
    driver instead of checking for == 9
  - also handle CNL and only initialize port F if it is
    IS_CNL_WITH_PORT_F. Eventually CNL may be removed, but while it
    isn't let's keep it consistent everywhere
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-4-lucas.demarchi@intel.com

Direction on gen >= 9 was to stop using straps and rely on VBT
indicating if the port is present or not. Remove FIXME comment since
this will never be "fixed".
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-3-lucas.demarchi@intel.com

Since commit 45c0673a ("drm/i915/bios: start using the
intel_bios_encoder_data directly") we lookup the devdata for each port
in intel_ddi_init() and just return if the port is not present in VBT
(or if we didn't create a fake devdata for it if VBT is not available).

So in intel_display.c we don't have to check
intel_bios_is_port_present(), just rely on the check in
intel_ddi_init().

v2: Rebase on commit 45c0673a ("drm/i915/bios: start using the
intel_bios_encoder_data directly") re-using that check in intel_ddi_init()
instead of adding a new one.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-2-lucas.demarchi@intel.com

Enable padding of DPT FB strides to POT, using the FB remapping logic.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-11-imre.deak@intel.com

The specification only requires DPT FB strides to be POT aligned, but
there seems to be also a minimum of 8 stride tile requirement. Scanning
out FBs with < 8 stride tiles will result in pipe faults (even though
the stride is POT aligned).
Signed-off-by: NImre Deak <imre.deak@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-10-imre.deak@intel.com

The latest specification removed the support for 90/270 FB rotation on
ADL_P, even though legacy Y-tiled surfaces are supported. Align the code
accordingly.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-9-imre.deak@intel.com

Alderlake-P have a new stride restriction when using DPT and it is used
by non linear framebuffers. Stride needs to be a power of two to take
full DPT rows, but stride is a parameter set by userspace.

What we could do is use a fake stride when doing DPT allocation so
HW requirements are met and userspace don't need to be changed to
met this power of two restrictions but this change will take a while
to be implemented so for now adding this restriction in driver to
reject atomic commits that would cause visual corruptions.

BSpec: 53393
Acked-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-8-imre.deak@intel.com

XE_LPD supports plane strides up to 128KB.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJuha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-7-imre.deak@intel.com

GTT remapping allow us to have planes with strides larger than HW
supports but DPT + GTT remapping is still not properly handled so
falling back to plane HW limitations for now.

This patch can be dropped when DPT + GTT remapping is correctly
handled but until then we need this limitation for all display13
platforms to avoid pipe faults.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-6-imre.deak@intel.com

Add support for DPT (display page table). DPT is a
slightly peculiar two level page table scheme used for
tiled scanout buffers (linear uses direct ggtt mapping
still). The plane surface address will point at a page
in the DPT which holds the PTEs for 512 actual pages.
Thus we require 1/512 of the ggttt address space
compared to a direct ggtt mapping.

We create a new DPT address space for each framebuffer and
track two vmas (one for the DPT, another for the ggtt).

TODO:
- Is the i915_address_space approaach sane?
- Maybe don't map the whole DPT to write the PTEs?
- Deal with remapping/rotation? Need to create a
  separate DPT for each remapped/rotated plane I
  guess. Or else we'd need to make the per-fb DPT
  large enough to support potentially several
  remapped/rotated vmas. How large should that be?
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NBommu Krishnaiah <krishnaiah.bommu@intel.com>
Cc: Wilson Chris P <Chris.P.Wilson@intel.com>
Cc: Tang CQ <cq.tang@intel.com>
Cc: Auld Matthew <matthew.auld@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NWilson Chris P <Chris.P.Wilson@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-5-imre.deak@intel.com

Let's start preparing for upcoming platforms that will use an XE_LPD
design.

v2:
 - Use the now-preferred "XE_LPD" term to refer to this design
 - Utilize DISPLAY_VER() rather than a feature flag
 - Drop unused mbus_size field (Lucas)
v3:
 - Adjust for dbuf.{size,slice_mask} (Ville)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v2)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-2-imre.deak@intel.com

When scanning out NV12 if we at any time have the plane enabled
while the scaler is disabled we get a pretty catastrophic
underrun.

Let's reorder the operations so that we try to avoid that happening
even if our vblank evade fails and the scaler enable/disable and
the plane enable/disable get latched during two diffent frames.

This takes care of the most common cases. I suppose there is still
at least a theoretical possibility of hitting this if one plane
takes the scaler away from another plane before the second plane
had a chance to set up another scaler for its use. But that
is starting to get a bit complicated, especially since the plane
commit order already has to be carefully sequenced to avoid any
dbuf overlaps. So plugging this 100% may prove somewhat hard...

Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506073836.14848-1-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

I doubt anyone has used the display error state since CS flips
went the way of the dodo. Just nuke it.

It might be semi interesting to have something like this for
FIFO underruns and the like, but as it stands this wouldn't
provide a sufficient amount of information. So would need
an extensive rewrite anyway.

The lockless power well handling is also racy, so this could
just be contributing noise to test results if we end up
accessing something with the relevant power well already
disabled.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210505191140.14215-1-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

The implementation of two workarounds are missing causing failures
in CI with pre-production HW.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210505213801.80772-1-jose.souza@intel.com

Replace the hand rolled PLL lock bit waits with intel_de_wait_for_*().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Replace the hand rolled rmw sequences with intel_de_rmw().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Replace the hand rolled rmw sequences with intel_de_rmw().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Replace the hand rolled rmw sequences with intel_de_rmw().

Jani pointed out that intel_de_rmw() skips the write if the
value does not change. That should be totally fine here, but
let's at least acknowledge the change in behaviour in case I'm
somehow wrong...
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Extract a few of the switch statements into helper functions to
reduce the pollution in the cdclk programming functions.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

We lost the i915_reg_rw tracepoint for a lot of display registers
when we switched from the heavyweight normal register accessors to
the lightweight _fw() variants. See eg. commit dd584fc0
("drm/i915: Use I915_READ_FW for plane updates").

Put the tracepoints back so that the register traces might
actually be useful. Hopefully these should be close to free
when the tracepoint is not enabled and thus not slow down
our vblank critical sections significantly.

v2: Copy paste the same-cacheline-hang warning from
    intel_uncore.h (Anshuman)

Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-2-ville.syrjala@linux.intel.com

Hoist the intel_de.h include from intel_display_types.h one
level up. I need this in order to untangle the include order
so that I can add tracepoints into intel_de.h.

This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
intel_de_read_fw(...)
|
intel_de_write(...)
|
intel_de_write_fw(...)
)

@has_include@
@@
(
 #include "intel_de.h"
|
 #include "display/intel_de.h"
)

@depends on find && !has_include@
@@
+ #include "intel_de.h"
  #include "intel_display_types.h"

@depends on find && !has_include@
@@
+ #include "display/intel_de.h"
  #include "display/intel_display_types.h"

Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com

Make sure that the XYUV8888 format is handled correctly when it's used
with a MC_CCS modifier framebuffer. Besides this format not working, the
driver will also return an incorrect error value when trying to use it,
indicating that the second color plane in the framebuffer is set
unexpectedly.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210501002853.4132009-1-imre.deak@intel.com

Make one step to pass intel_framebuffer to all intel_fb functions.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210414155208.3161335-2-imre.deak@intel.com

Cleanup the code. No functional changes.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6c2f6afa4c8866f8c1714b4f8dba9ea2d1509e4a.1620115983.git.jani.nikula@intel.com

Lift the masking outside of the if branches. No functional changes.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a87fd5e66b52c4d52a568888e1b8037841786fd2.1620115982.git.jani.nikula@intel.com

Registering multiple backlight devices with intel_backlight name will
obviously fail, regardless of whether they're two connectors in the same
drm device or two different drm devices.

It would be preferrable to switch to completely unique names, and sunset
the generic intel_backlight name. However, there are apparently users
out there that hardcode the name, so the change would break backward
compatibility.

As a compromise, register the first device with intel_backlight name. In
the common case, this is the only backlight device anyway. From the
second device on, use card%d-%s-backlight format, for example
card0-eDP-2-backlight, to make the name unique.

This approach does not preclude us from registering the first device
using the same naming scheme in the future.

v2: Keep using intel_backlight name for first backlight device

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2794Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7dc3f6974711ce44522189dc9db05d1e6e24e6d8.1619604743.git.jani.nikula@intel.com