On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.

v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
cc: Simon Ser <contact@emersion.fr>
cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-dev@lists.freedesktop.org
Cc: Tony Ye <tony.ye@intel.com>
Cc: Slawomir Milczarek <slawomir.milczarek@intel.com>

add test to check handling of misaligned offsets and sizes

Signed-off-by: Robert Beckett <bob.beckett@collabora.com>

discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>

For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.

We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.

For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.

v3:
	* use needs_compact_pt flag to discriminate between
	  64K and 64K with compact-pt
	* add i915_vm_obj_min_alignment
	* use i915_vm_obj_min_alignment to round up vma reservation
	  if compact-pt instead of hard coding

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>

Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.

With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.

Suggested-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>

…drm-tip

…drm-tip

# Conflicts:
#	drivers/gpu/drm/i915/i915_drv.h

…-tip

# Conflicts:
#	drivers/gpu/drm/i915/i915_reg.h
#	drivers/gpu/drm/i915/intel_pm.c

# Conflicts:
#	drivers/gpu/drm/i915/display/intel_display_types.h
#	drivers/gpu/drm/msm/edp/edp.h
#	drivers/gpu/drm/msm/edp/edp_ctrl.c

…to drm-tip

… drm-tip

# Conflicts:
#	drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
#	drivers/gpu/drm/amd/display/dc/core/dc_link.c
#	drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c

…m-tip

Use REG_BIT() & co. to polish the vlv/chv sprite plane registers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-10-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

The stack_depot member was added without kernel-doc, leading to below
warning. Fix it.

./include/drm/drm_modeset_lock.h:74: warning: Function parameter or
member 'stack_depot' not described in 'drm_modeset_acquire_ctx'

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: cd06ab2 ("drm/locking: add backtrace for locking contended locks without backoff")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://patchwork.freedesktop.org/patch/msgid/20220120094856.3004147-1-jani.nikula@intel.com

Lots of machines these days seem to have a crappy type1 DP dual
mode adaptor chip slapped onto the motherboard. Based on the
DP dual mode spec we currently limit those to 165MHz max TMDS
clock.

Windows OTOH ignores DP dual mode adaptors when the VBT
indicates that the port is not actually DP++, so we can
perhaps assume that the vendors did intend that the 165MHz
clock limit doesn't apply here. Though it would be much
nicer if they actually declared an explicit limit through
VBT, but that doesn't seem to be happening either.

So in order to match Windows behaviour let's ignore the
DP dual mode adaptor's TMDS clock limit for ports that
don't look like DP++ in VBT.

Unfortunately many older VBTs misdelcare their DP++ ports
as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB
Lenovo ThinkPad X220). So we can't really do this universally
without risking black screens. I suppose a sensible cutoff
is HSW+ since that's when 4k became a thing and one might
assume that the machines have been tested to work with higher
TMDS clock rates.

v2: s/IS_BROADWELL/IS_HASWELL/

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/20211222161738.12478-1-ville.syrjala@linux.intel.com

Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just
a DP+HDMI check. The rest of the bits shouldn't really
matter anyway.

The slight change in behaviour here is that now we do look at
the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via
intel_bios_encoder_supports_hdmi()) when we previously ignored it.
The one platform we know that has problems with that bit is VLV.
But IIRC the problem was always that buggy VBTs basically never
set that bit. So that should be OK since all it would do is make
all DVI ports look like HDMI ports instead. Also can't imagine
there are many VLV machines with actual DVI ports in existence.

We still keep the rest of the dvo_port/aux_ch checks as we
can't trust that DP+HDMI device type equals DP++ due to
buggy VBTs.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Now that we parse the DDI port info from the VBT on all g4x+ platforms
we can throw out all the old codepaths in intel_bios_is_port_present(),
intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None
of these should be called on pre-g4x platforms.

For good measure throw in a WARN into intel_bios_is_port_present()
should someone get the urge to call it on older platforms. The
other two functions are specific to HDMI and DP so should not need
any protection as those encoder types don't even exist on older
platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Extend the vbt.ports[] stuff for all g4x+ platforms. We do need
to drop the version check as some elk/ctg machines may have VBTs
older than that. The oldest I know is an elk with version 142.
But the child device stuff has had the correct size since at
least version 125 (observed on my sdg), so from that angle this
should be totally safe.

This does couple of things:
- Start using the aux_ch/ddc_pin from VBT instead of just the
  hardcoded defaults. Hopefully there are no VBTs with entirely
  bogus information here.
- Start using i915->vbt.ports[] for intel_bios_is_port_dp_dual_mode().
  Should be fine as the logic doesn't actually change.
- Start using i915->vbt.ports[] for intel_bios_is_port_edp().
  The old codepath only looks at the DP DVO ports, the new codepath
  looks at both DP and HDMI DVO ports. In principle that should not
  matter. We also stop looking at some of the other device type bits
  (eg. LVDS,MIPI,ANALOG,etc.). Hopefully no VBT is broken enough that
  it sets up totally conflicting device type bits (eg. LVDS+eDP at the
  same time). We also lose the "g4x->no eDP ever" hardcoding (shouldn't
  be hard to re-introduce that into eg. sanitize_device_type() if needed).

Lightly smoke tested on a set of machines (one of ctg,ilk,snb,ivb each)
with both DP and HDMI (DP++). Everything still worked as it should.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

CHV is currently straddling the divide by using parse_ddi_ports() stuff
for aux_ch/ddc_pin but going through all old codepaths for the rest
(intel_bios_is_port_present(), intel_bios_is_port_edp(),
intel_bios_is_port_dp_dual_mode()). Let's switch over full and use
i915->vbt.ports[] for the rest of the stuff.

dvo_port_to_port() doesn't know about DSI so we won't get into
any kind of "is port B HDMI or DSI or both?" conundrum, which
could otherwise happen on VLV/CHV due to DSI ports living in a
separate world from the other digital ports.

Including Jani's detailed analysis here for posterity:
"We stop checking for port A for CHV in intel_bios_is_port_present(), but
 it's a warn and I don't recall any bug reports, so probably fine. We
 could add a check in parse_ddi_port(), but meh.

 Ditto for intel_bios_is_port_dp_dual_mode(), except it doesn't have a
 warn.

 The eDP check in intel_bios_is_port_edp() becomes slightly more
 relaxed. Both the old and new check require these to be set:

 - DEVICE_TYPE_DISPLAYPORT_OUTPUT
 - DEVICE_TYPE_INTERNAL_CONNECTOR.

 The old code also required these to be unset:

 - DEVICE_TYPE_MIPI_OUTPUT
 - DEVICE_TYPE_COMPOSITE_OUTPUT
 - DEVICE_TYPE_DUAL_CHANNEL
 - DEVICE_TYPE_LVDS_SIGNALING
 - DEVICE_TYPE_TMDS_DVI_SIGNALING
 - DEVICE_TYPE_VIDEO_SIGNALING
 - DEVICE_TYPE_ANALOG_OUTPUT

 It's possible we've added these just as a sanity check for broken VBTs
 more than anything. I guess I'd see if actual problems arise.

 Bottom line, I think the functional changes matter only for VBTs with
 bogus data."

I agree that it should work assuming the VBT isn't totally insane.
Modern windows drivers also don't seem to check any of those
additional device type bits, which may or may not matter for older
devices (no idea what some old driver versions are checking).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Pull the "do we want to use i915->vbt.ports[]?" check into
a central place.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Replace module_platform_driver() with drm_module_platform_driver(). The
DRM macro respects drm_firmware_drivers_only() and fails if the flag has
been set.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-11-javierm@redhat.com

Replace module_platform_driver() with drm_module_platform_driver(). The
DRM macro respects drm_firmware_drivers_only() and fails if the flag has
been set.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-10-javierm@redhat.com

Replace module_platform_driver() with drm_module_platform_driver(). The
DRM macro respects drm_firmware_drivers_only() and fails if the flag has
been set.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-9-javierm@redhat.com

Replace module_platform_driver() with drm_module_platform_driver(). The
DRM macro respects drm_firmware_drivers_only() and fails if the flag has
been set.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-8-javierm@redhat.com

Provide a helper macro to register platform DRM drivers. The new
macro behaves like module_platform_driver() with an additional
test if DRM modesetting has been enabled.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-7-javierm@redhat.com

Replace module_pci_driver() with drm_module_pci_driver(). The DRM macro
respects drm_firmware_drivers_only() and fails if the flag has been set.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-6-javierm@redhat.com

Remove custom cirrus_init() and cirrus_exit() functions and initialize
the module with DRM module helpers.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-5-javierm@redhat.com

Remove custom bochs_init() and bochs_exit() functions and initialize
the module with DRM module helpers.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-4-javierm@redhat.com

Remove custom ast_init() and ast_exit() functions and initialize the
module with DRM module helpers.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-3-javierm@redhat.com

Provide helper macros to register PCI-based DRM drivers. The new
macros behave like module_pci_driver() with an additional test if
DRM modesetting has been enabled.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222082831.196562-2-javierm@redhat.com

This async flip vt-d w/a was moved to a different place in
commit 7d396ca ("drm/i195: Make the async flip VT-d workaround
dynamic") but the drm-intel-fixes cherry-pick commit b2d73de
("drm/i915: Extend the async flip VT-d w/a to skl/bxt") resurrected
the original code as well. So now we have this w/a in two places.
Remove the resurrected zombie code.

Not done as a revert to hopefully prevent any kind of
automagic stable backport.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211208150050.17230-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

The 1Netbook OneXPlayer uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.

Signed-off-by: Raymond Jay Golo <rjgolo@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjgolo@gmail.com