As with the VBT DVO port, RKL uses PHY based mapping for the
VBT AUX CH. Adjust the code to use the new AUX_USBCn names
and add a comment to explain the situation.
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-7-ville.syrjala@linux.intel.com

Let's make the AUX CH names match the spec (AUX A-F for pre-tgl,
AUX A-C or AUX USBC1-6 for tgl+). And while at it let's include
the full encoder name in the AUX CH name as well (as opposed to
just using port_name() which wouldn't give us the right thing on
tgl+).
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-6-ville.syrjala@linux.intel.com

Just like with the DDIs tgl+ renamed the AUX CHs to reflect
the type of the DDI. Let's add the aliasing enum values for
the type-C AUX CHs.
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-5-ville.syrjala@linux.intel.com

Let's pimp the DDI encoder->name to reflect what the spec calls them.
Ie. on pre-tgl DDI A-F, on tgl+ DDI A-C or DDI TC1-6.

Also since each encoder is really a combination of the DDI and the PHY
we include the PHY name as well.

ICL is a bit special since it already has the two different types
of DDIs (combo or TC) but it still calls them just DDI A-F regarless
of the type. For that let's add an extra "(TC)" note to remind
is which type of DDI it really is.

The code is darn ugly, but not sure there's much we can do about it.
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-4-ville.syrjala@linux.intel.com

Since tgl the DDIs have been named A,B,C,TC1,TC2,TC3...
Add the appropriate enum values for the TC DDIs to enum port.

v2: Deal with rkl and dg1
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-3-ville.syrjala@linux.intel.com

Make the namespacing for enum tc_port better by adding
the TC_ to the actual enum values.

v2: Drop the extra TC (Lucas)
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-2-ville.syrjala@linux.intel.com

Remove the hand rolled array of WM0_PIPE register offsets
and use the standard _MMIO_PIPE3() instead.

v2: Take care of gvt too
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212211738.27770-1-ville.syrjala@linux.intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>

This patch fixes below warnings reported by coccicheck

./drivers/gpu/drm/i915/i915_debugfs.c:789:5-8: Unneeded variable: "ret". Return "0" on line 1012
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZou Wei <zou_wei@huawei.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1603937925-53176-1-git-send-email-zou_wei@huawei.com

The atomic check hooks must look up the encoder to be used with a
connector from the connector's atomic state, and not assume that it's
the connector's current attached encoder. The latter one can change
under the atomic check func, or can be unset yet as in the case of MST
connectors.

This fixes
[    7.940719] Oops: 0000 [#1] SMP NOPTI
[    7.944407] CPU: 2 PID: 143 Comm: kworker/2:2 Not tainted 5.6.0-1023-oem #23-Ubuntu
[    7.952102] Hardware name: Dell Inc. Latitude 7320/, BIOS 88.87.11 09/07/2020
[    7.959278] Workqueue: events output_poll_execute [drm_kms_helper]
[    7.965511] RIP: 0010:intel_psr_atomic_check+0x37/0xa0 [i915]
[    7.971327] Code: 80 2d 06 00 00 20 74 42 80 b8 34 71 00 00 00 74 39 48 8b 72 08 48 85 f6 74 30 80 b8 f8 71 00 00 00 74 27 4c 8b 87 80 04 00 00 <41> 8b 78 78 83 ff 08 77 19 31 c9 83 ff 05 77 19 48 81 c1 20 01 00
[    7.977541] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input5
[    7.990154] RSP: 0018:ffffb864c073fac8 EFLAGS: 00010202
[    7.990155] RAX: ffff8c5d55ce0000 RBX: ffff8c5d54519000 RCX: 0000000000000000
[    7.990155] RDX: ffff8c5d55cb30c0 RSI: ffff8c5d89a0c800 RDI: ffff8c5d55fcf800
[    7.990156] RBP: ffffb864c073fac8 R08: 0000000000000000 R09: ffff8c5d55d9f3a0
[    7.990156] R10: ffff8c5d55cb30c0 R11: 0000000000000009 R12: ffff8c5d55fcf800
[    7.990156] R13: ffff8c5d55cb30c0 R14: ffff8c5d56989cc0 R15: ffff8c5d56989cc0
[    7.990158] FS:  0000000000000000(0000) GS:ffff8c5d8e480000(0000) knlGS:0000000000000000
[    8.047193] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    8.052970] CR2: 0000000000000078 CR3: 0000000856500005 CR4: 0000000000760ee0
[    8.060137] PKRU: 55555554
[    8.062867] Call Trace:
[    8.065361]  intel_digital_connector_atomic_check+0x53/0x130 [i915]
[    8.071703]  intel_dp_mst_atomic_check+0x5b/0x200 [i915]
[    8.077074]  drm_atomic_helper_check_modeset+0x1db/0x790 [drm_kms_helper]
[    8.083942]  intel_atomic_check+0x92/0xc50 [i915]
[    8.088705]  ? drm_plane_check_pixel_format+0x4f/0xb0 [drm]
[    8.094345]  ? drm_atomic_plane_check+0x7a/0x3a0 [drm]
[    8.099548]  drm_atomic_check_only+0x2b1/0x450 [drm]
[    8.104573]  drm_atomic_commit+0x18/0x50 [drm]
[    8.109070]  drm_client_modeset_commit_atomic+0x1c9/0x200 [drm]
[    8.115056]  drm_client_modeset_commit_force+0x55/0x160 [drm]
[    8.120866]  drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper]
[    8.128415]  drm_fb_helper_set_par+0x34/0x50 [drm_kms_helper]
[    8.134225]  drm_fb_helper_hotplug_event.part.0+0xb4/0xe0 [drm_kms_helper]
[    8.141150]  drm_fb_helper_hotplug_event+0x1c/0x30 [drm_kms_helper]
[    8.147481]  intel_fbdev_output_poll_changed+0x6f/0xa0 [i915]
[    8.153287]  drm_kms_helper_hotplug_event+0x2c/0x40 [drm_kms_helper]
[    8.159709]  output_poll_execute+0x1aa/0x1c0 [drm_kms_helper]
[    8.165506]  process_one_work+0x1e8/0x3b0
[    8.169561]  worker_thread+0x4d/0x400
[    8.173249]  kthread+0x104/0x140
[    8.176515]  ? process_one_work+0x3b0/0x3b0
[    8.180726]  ? kthread_park+0x90/0x90
[    8.184416]  ret_from_fork+0x1f/0x40

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2361
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2486Reported-by: NWilliam Tseng <william.tseng@intel.com>
Reported-by: NCooper Chiou <cooper.chiou@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201027160928.3665377-1-imre.deak@intel.com

First check in the function is if swsci() is supported. All the error
paths are easy to figure out the reason, so remove the extra debug
message: it's normal not to support swsci() e.g. in dgfx.

v2: Rather than special case dgfx, just remove the debug message
    (from Ville)
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/20201027044618.719064-2-lucas.demarchi@intel.com

Do not create the display debugfs files when we don't have display.

Based on previous patch by José Souza.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201027044618.719064-1-lucas.demarchi@intel.com

HPD pins are inverted for DG1 platform.

Bspec: 49956
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NClinton A Taylor <clinton.a.taylor@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021082034.3170478-3-lucas.demarchi@intel.com

DG1 has one more combo phy port, no TC and all irq handling goes through
SDE, like for MCC.

v2: Also change intel_hpd_pin_default() to include DG1 mapping
v3, v4: Rebase on hpd refactor

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021082034.3170478-2-lucas.demarchi@intel.com

Writes to CURSURFLIVE in TGL are causing IOMMU errors and visual
glitches that are often reproduced when executing CPU intensive
workloads while a eDP 4K panel is attached.

Manually exiting PSR causes the frontbuffer to be updated without
glitches and the IOMMU errors are also gone but this comes at the cost
of less time with PSR active.

So using this workaround until this issue is root caused and a better
fix is found.

The current code is already ready to enable PSR after this exit if
there is not other frontbuffer modifications.

Adding a new if block in psr_force_hw_tracking_exit() instead of reuse
the else/gen8- block because the plan is to revert this workaround
as soon as a better solution is found.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Tested-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201002231627.24528-1-jose.souza@intel.com

As we disable the interrupt during suspend, also reset the irq_mask to
short-circuit subsystems that later try to turn off their interrupt
source.

<4>[  101.816730] i915 0000:00:02.0: drm_WARN_ON(!intel_irqs_enabled(dev_priv))
<4>[  101.816853] WARNING: CPU: 3 PID: 4241 at drivers/gpu/drm/i915/i915_irq.c:343 ilk_update_display_irq+0xb3/0x130 [i915]

v2: Reset irq_mask for i8xx_irq_reset as well, and split patch to focus
on only i915->irq_mask
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201022114246.28566-1-chris@chris-wilson.co.uk

The block comment for cnl_program_nearest_filter_coefs() has a wonderful
diagram, but although it is marked up as kerneldoc does not use the
markup for providing the function definition.

drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'dev_priv' not described in 'cnl_program_nearest_filter_coefs'
drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'pipe' not described in 'cnl_program_nearest_filter_coefs'
drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'id' not described in 'cnl_program_nearest_filter_coefs'
drivers/gpu/drm/i915/display/intel_display.c:6341: warning: Function parameter or member 'set' not described in 'cnl_program_nearest_filter_coefs'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021185649.17759-1-chris@chris-wilson.co.uk

We don't currently handle the initial fb readout correctly
for 90/270 degree rotated scanout. Reject it.

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201020194330.28568-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Let's unmask the PCU event irq _after_ we've set up the
hardware and software to deal with the fallout. We can
also drop the PCU event bit from DEIER except when we
need it for rps.

And on the disable side we replace the hand rolled (and
unlocked) DEIER/IIR/IMR frobbing with ilk_disable_display_irq().
Ocd does require me to reorder it to be symmetric with
the enable path however.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-5-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Let's make sure the lower level interrupt bits are all lined
up before we flip on the master interrupt.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-4-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

A bunch of the ips calculations require 64bit math. In particular
'corr' and 'corr2' look like they can overflow on 32bit systems.
Switch to explicit u64 for those.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-3-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

There is no GEN6_RPSTAT1 on ILK. Instead of reading that let's
try to get the same information from MEMSTAT_ILK. At least it
seems to track MEMSWCTL frequency request perfectly on my ILK.
It needs the same invert trick as the request value.

We don't want to put the invert thing into intel_gpu_freq()
and intel_freq_opcode() because that would incorrectly invert
the min/max/etc frequencies also.

One day someone might want to reverse engineer the formula for
converting these numbers to Hz, but for now we'll just report
them raw.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Restore RPS for ILK-M. We lost it when an extra HAS_RPS()
check appeared in intel_rps_enable().

Unfortunaltey this just makes the performance worse on my
ILK because intel_ips insists on limiting the GPU freq to
the minimum. If we don't do the RPS init then intel_ips will
not limit the frequency for whatever reason. Either it can't
get at some required information and thus makes wrong decisions,
or we mess up some weights/etc. and cause it to make the wrong
decisions when RPS init has been done, or the entire thing is
just wrong. Would require a bunch of reverse engineering to
figure out what's going on.

Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 9c878557 ("drm/i915/gt: Use the RPM config register to determine clk frequencies")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

GEN >= 10 hardware supports the programmable scaler filter.

Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.

changes since v3:
* None
changes since v2:
* Use updated functions
* Add ps_ctrl var to contain the full PS_CTRL register value (Ville)
* Duplicate the scaling filter in crtc and plane hw state (Ville)
changes since v1:
* None
Changes since RFC:
* Enable properties for GEN >= 10 platforms (Ville)
* Do not round off the crtc co-ordinate (Danial Stone, Ville)
* Add new functions to handle scaling filter setup (Ville)
* Remove coefficient set 0 hardcoding.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-5-pankaj.laxminarayan.bharadiya@intel.com

Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest source pixel value.

Both IS and NN preserve the clarity of the original image. Integer
scaling is particularly useful for pixel art games that rely on
sharp, blocky images to deliver their distinctive look.

Introduce functions to configure the scaler filter coefficients to
enable nearest-neighbor filtering.

Bspec: 49247

changes since v6:
* Trust compiler, remove pointless inline keyword from cnl_coef_tap()
  & cnl_nearest_filter_coef() functions (Ville)
changes since v4:
* Make cnl_coef_tap(), cnl_nearest_filter_coef() inline (Uma)
changes since v3:
* None
changes since v2:
* Move APIs from 5/5 into this patch.
* Change filter programming related function names to cnl_*, move
  filter select bits related code into inline function (Ville)
changes since v1:
* Rearrange skl_scaler_setup_nearest_neighbor_filter() to iterate the
  registers directly instead of the phases and taps (Ville)

changes since RFC:
* Refine the skl_scaler_setup_nearest_neighbor_filter() logic (Ville)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-4-pankaj.laxminarayan.bharadiya@intel.com

Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.

changes since v3:
* None
changes since v2:
* Change macro names to CNL_* and  use +(set)*8 instead of adding
  another trip through _PICK_EVEN (Ville).
changes since v1:
* None
changes since RFC:
* Parametrize scaler coeffient macros by 'set' (Ville)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-3-pankaj.laxminarayan.bharadiya@intel.com

Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.

Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for a CRTC by calling
drm_crtc_create_scaling_filter().

NN filter works by filling in the missing color values in the upscaled
image with that of the coordinate-mapped nearest source pixel value.

NN filter for integer multiple scaling can be particularly useful for
for pixel art games that rely on sharp, blocky images to deliver their
distinctive look.

changes since: v6:
* Move property doc to existing "Standard CRTC Properties" and
  "Plane Composition Properties" doc comments (Simon)
changes since v3:
* Refactor code, add new function for common code (Ville)
changes since v2:
* Create per-plane and per-CRTC scaling filter property (Ville)
changes since v1:
* None
changes since RFC:
* Add separate properties for plane and CRTC (Ville)

Link: https://github.com/xbmc/xbmc/pull/18194
Link: https://github.com/xbmc/xbmc/pull/18567Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Acked-by: NSimon Ser <contact@emersion.fr>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-2-pankaj.laxminarayan.bharadiya@intel.com

No functional changes in this patch.

With Bigjoiner, there are 2 pipes driving 2 halfs of 1
transcoder. The transcoder_mode has the full timings, and is used
for configuring the transcoder with the intended mode after
joining the 2 halves.
To clear the confusion, we rename intel_set_pipe_timings to
intel_set_transcoder_timings

v2:
* Split the renaming into separate patch (Ville)

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008214535.22942-2-manasi.d.navare@intel.com

Sort the ICL PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-14-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Sort the CNL PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-13-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Sort the CFL PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-12-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Sort the CML PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-11-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Sort the KBL PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-10-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Sort the SKL PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-9-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Sort the HSW PCI IDs numerically. Some order seems better than
randomness.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-8-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Most of the HSW PCI IDs are upper case hex numbers, but a
few are lower case. Make it consistent so these don't
stick out like a sore thumb.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-7-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Bunch of the SKL SKUs currently documented as GT3/4 seem to actually
be GT3e/4e. Fix up the comments.

Cc: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-6-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Add three new devices 0x1913, 0x1915, and 0x1917 also known as
iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15.
Signed-off-by: NAlexei Podtelezhnikov <apodtele@gmail.com>
[vsyrjala: Split separate changes into separate patchs,
           Sort the IDs]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-5-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Reclassify 0x1923, 0x1927 according to specifications. Of note,
the second to last digit seems to correspond to GT#.
Signed-off-by: NAlexei Podtelezhnikov <apodtele@gmail.com>
[vsyrjala: Split separate changes into separate patches,
           Sort the IDs]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-4-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Reclassify 0x192A according to specifications. Of note, the
second to last digit seems to correspond to GT#.
Signed-off-by: NAlexei Podtelezhnikov <apodtele@gmail.com>
[vsyrjala: Split separate changes into separate patches]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-3-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>

Reclassify 0x0426 as GT3 (GT2+) according to specifications and the second
least significant digit.
Signed-off-by: NAlexei Podtelezhnikov <apodtele@gmail.com>
[vsyrjala: s/GT2/GT3/ in the comment]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716172106.2656-2-ville.syrjala@linux.intel.comReviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>