linux-stable.git/Documentation/DocBook/gpu.tmpl, branch linux-4.6.y

drm: Add helper for DP++ adaptors

2016-06-08T01:23:41+00:00

commit b3daa5ef52c26acd7432c787989bd92d48070c76 upstream.

Add a helper which aids in the identification of DP dual mode
(aka. DP++) adaptors. There are several types of adaptors
specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI

Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz and they provide a register informing the
source device what the actual limit is. Supposedly also type 1 adaptors
may optionally implement this register. This TMDS clock limit is the
main reason why we need to identify these adaptors.

Type 1 adaptors provide access to their internal registers and the sink
DDC bus through I2C. Type 2 adaptors provide this access both via I2C
and I2C-over-AUX. A type 2 source device may choose to implement either
of these methods. If a source device implements the I2C-over-AUX
method, then the driver will obviously need specific support for such
adaptors since the port is driven like an HDMI port, but DDC
communication happes over the AUX channel.

This helper should be enough to identify the adaptor type (some
type 1 DVI adaptors may be a slight exception) and the maximum TMDS
clock limit. Another feature that may be available is control over
the TMDS output buffers on the adaptor, possibly allowing for some
power saving when the TMDS link is down.

Other user controllable features that may be available in the adaptors
are downstream i2c bus speed control when using i2c-over-aux, and
some control over the CEC pin. I chose not to provide any helper
functions for those since I have no use for them in i915 at this time.
The rest of the registers in the adaptor are mostly just information,
eg. IEEE OUI, hardware and firmware revision, etc.

v2: Pass adaptor type to helper functions to ease driver implementation
    Fix a bunch of typoes (Paulo)
    Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
    the type (Paulo)
    Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
    Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
    ease future LSPCON enabling
    Remove the unused DP_DUAL_MODE_LAST_RESERVED define
v3: Fix kernel doc function argument descriptions (Jani)
    s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
    Add kernel doc for enum drm_dp_dual_mode_type
    Actually build the docs
    Fix more typoes
v4: Adjust code indentation of type2 adaptor detection (Shashank)
    Add debug messages for failurs cases (Shashank)
v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)

Cc: Tore Anderson 
Cc: Paulo Zanoni 
Cc: Shashank Sharma 
Cc: Daniel Vetter 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma  (v4)
Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit ede53344dbfd1dd43bfd73eb6af743d37c56a7c3)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm: introduce pipe color correction properties

2016-03-08T12:57:32+00:00

Patch based on a previous series by Shashank Sharma.

This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.

The following properties can be added to a pipe :
  - DEGAMMA_LUT : blob containing degamma LUT
  - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
  - CTM : transformation matrix applied after the degamma LUT
  - GAMMA_LUT : blob containing gamma LUT
  - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT

DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.

A helper is also provided so legacy gamma correction is redirected
through these new properties.

v2: Register LUT size properties as range

v3: Fix round in drm_color_lut_get_value() helper
    More docs on how degamma/gamma properties are used

v4: Update contributors

v5: Rename CTM_MATRIX property to CTM (Doh!)
    Add legacy gamma_set atomic helper
    Describe CTM/LUT acronyms in the kernel doc

v6: Fix missing blob unref in drm_atomic_helper_crtc_reset

Signed-off-by: Shashank Sharma 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
Acked-by: Rob Bradford 
[danvet: CrOS maintainers are also happy with the userspacde side:
https://codereview.chromium.org/1182063002/ ]
Reviewed-by: Daniel Stone 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com

apple-gmux: Add helper for presence detect

2016-02-09T10:21:11+00:00

Centralize gmux' ACPI HID in a header file and add apple_gmux_present().
This can be used by other drivers to activate quirks specific to dual
GPU MacBook Pros & Mac Pros. The alternative would be to hardcode DMI
or PCI IDs and amend them whenever Apple introduces a new machine.

Tested-by: Lukas Wunner 
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Signed-off-by: Lukas Wunner 
Reviewed-by: Darren Hart 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/89c23769058a340e5e11d4a7102f3793d3b0c94c.1452525860.git.lukas@wunner.de

vga_switcheroo: Add handler flags infrastructure

2016-02-09T10:21:07+00:00

Allow handlers to declare their capabilities and allow clients to
obtain that information. So far we have these use cases:

* If the handler is able to switch DDC separately, clients need to
  probe EDID with drm_get_edid_switcheroo(). We should allow them
  to detect a capable handler to ensure this function only gets
  called when needed.

* Likewise if the handler is unable to switch AUX separately, the active
  client needs to communicate link training parameters to the inactive
  client, which may then skip the AUX handshake and set up its output
  with these pre-calibrated values (DisplayPort specification v1.1a,
  section 2.5.3.3). Clients need a way to recognize such a situation.

The flags for the radeon_atpx_handler and amdgpu_atpx_handler are
initially set to 0, this can later on be amended with
  handler_flags |= VGA_SWITCHEROO_CAN_SWITCH_DDC;
when a ->switch_ddc callback is added.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Lukas Wunner 
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Signed-off-by: Lukas Wunner 
Reviewed-by: Darren Hart 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/2b0d93ed6e511ca09e95e45e0b35627f330fabce.1452525860.git.lukas@wunner.de

Merge tag 'topic/drm-misc-2016-02-08' of git://anongit.freedesktop.org/drm-intel into drm-next

2016-02-09T00:39:11+00:00

First drm-misc pull req for 4.6. Big one is the drm_event cleanup, which
is also prep work for adding android fence support to kms (Gustavo is
planning to do that). Otherwise random small bits all over.

* tag 'topic/drm-misc-2016-02-08' of git://anongit.freedesktop.org/drm-intel: (33 commits)
  gma500: clean up an excessive and confusing helper
  drm/gma500: remove helper function
  drm/vmwgfx: Nuke preclose hook
  drm/vc4: Nuke preclose hook
  drm/tilcdc: Nuke preclose hook
  drm/tegra: Stop cancelling page flip events
  drm/shmob: Nuke preclose hook
  drm/rcar: Nuke preclose hook
  drm/omap: Nuke close hooks
  drm/msm: Nuke preclose hooks
  drm/imx: Unconfuse preclose logic
  drm/exynos: Remove event cancelling from postclose
  drm/atmel: Nuke preclose
  drm/i915: Nuke intel_modeset_preclose
  drm: Nuke vblank event file cleanup code
  drm: Clean up pending events in the core
  drm/vblank: Use drm_event_reserve_init
  drm/vmwgfx: fix a NULL dereference
  drm/crtc-helper: Add caveat to disable_unused_functions doc
  drm/gma500: Remove empty preclose hook
  ...

drm: kerneldoc for drm_fops.c

2016-01-25T07:39:58+00:00

Just prep work before I throw more drm_event refactorings on top.

Acked-by: Daniel Stone 
Reviewed-by: Alex Deucher 
Link: http://patchwork.freedesktop.org/patch/msgid/1452548477-15905-2-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued

2016-01-18T07:18:16+00:00

Pull in Dave's drm-next pull request to have a clean base for 4.6.
Also, we need the various atomic state extensions Maarten recently
created.

Conflicts are just adjacent changes that all resolve to nothing in git
diff.

Signed-off-by: Daniel Vetter

apple-gmux: Add initial documentation

2016-01-11T14:56:23+00:00

Document what I've learned so far about the gmux so that we can
collaboratively reverse-engineer its remaining unknown bits
without everyone having to start from scratch.

The DOC sections are bound together in the gpu.tmpl DocBook
under a new vga_switcheroo "Handlers" chapter. Eventually
this should be amended with documentation about the four other
handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM,
radeon ATPX, amdgpu ATPX).

Requires kernel-doc with asciidoc support.

The EFI variable was reverse-engineered by Bruno Bierbaumer
and Andreas Heider .

Some of the remaining open questions:

* How are vblank intervals synchronized on retinas to achieve seamless
switching? Is the DP mux capable of this? It's not mentioned in the
data sheets. Or is it done at the OS level, i.e. do we have to
synchronize vblank intervals between DRM drivers? There's a signal
coming from the panel connector and going into gmux, could this be
the vblank signal as received by the panel to properly time the
switch?

* On retinas there's an I2C bus between gmux and the connector of the
right I/O board, apparently leading to the Parade PS8401A HDMI
repeater. What is this for, is it controlled via gmux registers?
Data sheet:
http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/

* On retinas there's an I2C bus between gmux and the LED driver.
Pre-retinas connected the LED driver to SMBUS. Are there additional
gmux registers on retinas to control it?

* The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the
retina MacBook Pro. The Mac Pro doesn't have a built-in display,
so what is its purpose? Power control of the dual FirePro GPUs?
Switching of the external DP/Thunderbolt ports? The iFixit teardown
clearly shows one TI HD3SS212 DisplayPort mux on the logic board next
to one of the three Thunderbolt controllers. However six muxes would
be necessary to switch all six ports between GPUs. The mux is probably
necessary for one of the display configurations allowed by Apple,
but which one?
https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778
https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge
https://support.apple.com/en-us/HT202801

* Registers we haven't decoded yet:
0x700 32 Bit configmap?
0x708 32 Bit power sequence?
0x712 8 Bit status of clock from panel on retinas?
0x713 8 Bit dito?
0x724 16 Bit backlight, raw value?
0x760 32 Bit backlight
0x764 32 Bit backlight
0x768 8 Bit backlight
0x76a 16 Bit backlight
0x76c 16 Bit backlight
0x76e 16 Bit backlight
0x77f edp/dp/hdmi probe? retina only.

* Addition by Bruno Prémont :
"Missing is also precise knowledge as to what the gmux depends on.
From behavioral reports, it is somehow sensitive to VGA IO/MEM
routing (it apparently needs the routing to go to integrated GPU,
not discrete GPU).
When the routing is inappropriate backlight control IO just reads back
as 0xFF (and eventually gmux IO in general does so)."

Signed-off-by: Lukas Wunner
Acked-by: Darren Hart
Link: http://patchwork.freedesktop.org/patch/msgid/da309e436fbeac886477d80376457b7d83ea4b2d.1452431795.git.lukas@wunner.de
Signed-off-by: Daniel Vetter

drm/docs: more leftovers from the big vtable documentation pile

2016-01-05T15:21:35+00:00

Another pile of vfuncs from the old gpu.tmpl xml documentation that
I've forgotten to delete. I spotted a few more things to
clarify/extend in the new kerneldoc while going through this once
more.

v2: Spelling fixes (Thierry).

v3: More spelling fixes and use Thierry's proposal to clarify why
drivers need to validate modes both in ->mode_fixup and ->mode_valid.

Cc: Laurent Pinchart 
Cc: Thierry Reding 
Acked-by: Thierry Reding 
Signed-off-by: Daniel Vetter

vga_switcheroo: Prettify documentation

2016-01-04T07:11:49+00:00

Fix indentation of vga_switcheroo sections in gpu.tmpl.

Change section type of API documentation from "chapter" to "sect1"
so that the individual functions no longer clutter up the ToC.
Group together under a new "API" chapter.

Fix wording "heretoforth" -> "henceforth".

Signed-off-by: Lukas Wunner 
Signed-off-by: Daniel Vetter