linux-toradex.git/include/drm/i915_drm.h, branch v5.16-rc5

drm: Move port definition back to i915 header

2019-08-30T08:38:26+00:00

We dont need the definition of the enum port outside I915, anymore.
Hence move enum port definition into I915 driver itself.

v2:
  intel_display.h is included in intel_hdcp.h
v3:
  enum port is declared in headers.
v4:
  commit msg is rephrased.
v5:
  copyright year is updated [Tomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Jani Nikula 
Reviewed-by: Shashank Sharma 
Reviewed-by: Tomas Winkler 
Signed-off-by: Uma Shankar 
Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-3-ramalingam.c@intel.com

drm/i915: Drop extern qualifiers from header function prototypes

2019-07-12T12:04:54+00:00

Follow dim checkpatch recommendation so it doesn't complain on that now
and again on header file modifications.

v2: drop testing leftover (Chris)

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: https://patchwork.freedesktop.org/patch/msgid/20190712112429.740-2-janusz.krzysztofik@linux.intel.com

drm/i915/tgl: Add additional ports for Tiger Lake

2019-07-11T23:31:14+00:00

There are 2 new additional typeC ports in Tiger Lake and PORT-C is now a
combophy port. This results in 6 typeC ports and 3 combophy ports.
These 6 TC ports can be DP alternate mode, DP over thunderbolt, native
DP on legacy DP connector or native HDMI on legacy connector.

v2: Rebase on new modular FIA code (Lucas)
v3: Also add new port in port_identifier(), even though it can't
    possibly be used there (requested by José)
v4: Add conversion port->tc_port in helper function after introction of
    phy namespace (Lucas)

Cc: Anusha Srivatsa 
Signed-off-by: Vandita Kulkarni 
Signed-off-by: Lucas De Marchi 
Reviewed-by: Matt Roper 
Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-13-lucas.demarchi@intel.com

drm/i915: enum port definition is moved into i915_drm.h

2019-02-15T17:56:35+00:00

For the reusability of the enum port in other driver modules
(like mei_hdcp), enum port definition is moved from I915 local header
intel_display.h to drm/i915_drm.h

Signed-off-by: Ramalingam C 
Acked-by: Daniel Vetter 
[danvet: Fix subject prefix.]
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/1550219730-17734-3-git-send-email-ramalingam.c@intel.com

x86/gpu: reserve ICL's graphics stolen memory

2018-07-10T23:28:47+00:00

ICL changes the registers and addresses to 64 bits.

I also briefly looked at implementing an u64 version of the PCI config
read functions, but I concluded this wouldn't be trivial, so it's not
worth doing it for a single user that can't have any racing problems
while reading the register in two separate operations.

v2:
 - Scrub the development (non-public) changelog (Joonas).
 - Remove the i915.ko bits so this can be easily backported in order
   to properly avoid stolen memory even on machines without i915.ko
   (Joonas).
 - CC stable for the reasons above.

Issue: VIZ-9250
CC: stable@vger.kernel.org
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: x86@kernel.org
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Signed-off-by: Paulo Zanoni 
Fixes: 412310019a20 ("drm/i915/icl: Add initial Icelake definitions.")
Reviewed-by: Joonas Lahtinen 
Acked-by: Ingo Molnar 
Signed-off-by: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20180504203252.28048-1-paulo.r.zanoni@intel.com

x86/early-quirks: export the stolen region as a resource

2017-12-12T10:30:18+00:00

We duplicate the stolen discovery code in early-quirks and in i915,
however if we just export the region as a resource from early-quirks we
can nuke the duplication.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Paulo Zanoni 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Chris Wilson 
Acked-by: Ingo Molnar 
Signed-off-by: Joonas Lahtinen 
Link: https://patchwork.freedesktop.org/patch/msgid/20171211151822.20953-3-matthew.auld@intel.com

drm: avoid "possible bad bitmask?" warning

2016-08-09T20:18:26+00:00

Recent versions of gcc say this:

include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshift-overflow=]

Reported-by: David Binderman 
Signed-off-by: Dave Gordon 
Cc: Dave Airlie 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1470764110-23855-1-git-send-email-david.s.gordon@intel.com

drm/i915: Canonicalize stolen memory calculations

2016-04-25T10:30:32+00:00

Move the better constructs/comments from i915_gem_stolen.c to
early-quirks.c and increase readability in preparation of only
having one set of functions.

- intel_stolen_base -> gen3_stolen_base
- use phys_addr_t instead of u32 for address for future proofing

v2:
- Print the invalid register values (Chris)
  (Omitting the register prefix as it's visible from backtrace.)

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Ville Syrjälä 
Cc: Tvrtko Ursulin 
Acked-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
Signed-off-by: Joonas Lahtinen

x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms

2014-02-09T14:11:30+00:00

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.

The e820 map in said machine looks like this:

	BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
	BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
	BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
	BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
	BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
	BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
	BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
	BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
	BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
	BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
	BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved

That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen
memory would start there would place it on top of some ACPI
memory regions. So not a good idea as already stated.

The 9MB region after the ACPI regions at 0x1f700000 however
looks promising given that the macine reports the stolen memory
size to be 8MB. Looking at the PGTBL_CTL register, the GTT
entries are at offset 0x1fee00000, and given that the GTT
entries occupy 128KB, it looks like the stolen memory could
start at 0x1f700000 and the GTT entries would occupy the last
128KB of the stolen memory.

After some more digging through chipset documentation, I've
determined the BIOS first allocates space for something called
TSEG (something to do with SMM) from the top of memory, and then
it allocates the graphics stolen memory below that. Accordind to
the chipset documentation TSEG has a fixed size of 1MB on 855.
So that explains the top 1MB in the e820 region. And it also
confirms that the GTT entries are in fact at the end of the the
stolen memory region.

Derive the stolen memory base address on gen2 the same as the
BIOS does (TOM-TSEG_SIZE-stolen_size). There are a few
differences between the registers on various gen2 chipsets, so a
few different codepaths are required.

865G is again bit more special since it seems to support enough
memory to hit 4GB address space issues. This means the PCI
allocations will also affect the location of the stolen memory.
Fortunately there appears to be the TOUD register which may give
us the correct answer directly. But the chipset docs are a bit
unclear, so I'm not 100% sure that the graphics stolen memory is
always the last thing the BIOS steals. Someone would need to
verify it on a real system.

I tested this on the my 830 and 855 machines, and so far
everything looks peachy.

Signed-off-by: Ville Syrjälä 
Cc: Bjorn Helgaas 
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar

drm/i915/bdw: support GMS and GGMS changes

2013-11-08T17:09:39+00:00

All the BARs have the ability to grow.

v2: Pulled out the simulator workaround to a separate patch.
Rebased.

v3: Rebase onto latest vlv patches from Jesse.

v4: Rebased on top of the early stolen quirk patch from Jesse.

v5: Use the new macro names.
s/INTEL_BDW_PCI_IDS_D/INTEL_BDW_D_IDS
s/INTEL_BDW_PCI_IDS_M/INTEL_BDW_M_IDS
It's Jesse's fault for not following the convention I originally set.

Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Jesse Barnes 
Signed-off-by: Ben Widawsky 
Signed-off-by: Daniel Vetter