From 3a848662c75118e1ee4653e08e25943d8b4ab8b7 Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Sat, 2 Jan 2016 18:47:17 +0100 Subject: vga_switcheroo: Prettify documentation 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 --- Documentation/DocBook/gpu.tmpl | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 6c6e81a9eaf4..225a246c5f53 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -3625,37 +3625,37 @@ int num_ioctls; Modes of Use - - Manual switching and manual power control + + Manual switching and manual power control !Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control - - - Driver power control + + + Driver power control !Pdrivers/gpu/vga/vga_switcheroo.c Driver power control - + - - Public functions + + API + + Public functions !Edrivers/gpu/vga/vga_switcheroo.c - - - - Public structures + + + Public structures !Finclude/linux/vga_switcheroo.h vga_switcheroo_handler !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops - - - - Public constants + + + Public constants !Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id !Finclude/linux/vga_switcheroo.h vga_switcheroo_state - - - - Private structures + + + Private structures !Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv !Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client + !Cdrivers/gpu/vga/vga_switcheroo.c -- cgit v1.2.3 From df7d678bea8ba8904bdb293c8e96aa9488f7dbee Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Mon, 4 Jan 2016 07:53:36 +0100 Subject: drm/docs: more leftovers from the big vtable documentation pile 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 --- Documentation/DocBook/gpu.tmpl | 188 ------------------------------- include/drm/drm_modeset_helper_vtables.h | 44 +++++++- 2 files changed, 41 insertions(+), 191 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 225a246c5f53..faa5e0d4208d 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1578,194 +1578,6 @@ void intel_crt_init(struct drm_device *dev) To use it, a driver must provide bottom functions for all of the three KMS entities. - - Legacy CRTC Helper Operations - - - bool (*mode_fixup)(struct drm_crtc *crtc, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - - Let CRTCs adjust the requested mode or reject it completely. This - operation returns true if the mode is accepted (possibly after being - adjusted) or false if it is rejected. - - - The mode_fixup operation should reject the - mode if it can't reasonably use it. The definition of "reasonable" - is currently fuzzy in this context. One possible behaviour would be - to set the adjusted mode to the panel timings when a fixed-mode - panel is used with hardware capable of scaling. Another behaviour - would be to accept any input mode and adjust it to the closest mode - supported by the hardware (FIXME: This needs to be clarified). - - - - int (*mode_set_base)(struct drm_crtc *crtc, int x, int y, - struct drm_framebuffer *old_fb) - - Move the CRTC on the current frame buffer (stored in - crtc->fb) to position (x,y). Any of the frame - buffer, x position or y position may have been modified. - - - This helper operation is optional. If not provided, the - drm_crtc_helper_set_config function will fall - back to the mode_set helper operation. - - - FIXME: Why are x and y passed as arguments, as they can be accessed - through crtc->x and - crtc->y? - - - - void (*prepare)(struct drm_crtc *crtc); - - Prepare the CRTC for mode setting. This operation is called after - validating the requested mode. Drivers use it to perform - device-specific operations required before setting the new mode. - - - - int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode, int x, int y, - struct drm_framebuffer *old_fb); - - Set a new mode, position and frame buffer. Depending on the device - requirements, the mode can be stored internally by the driver and - applied in the commit operation, or - programmed to the hardware immediately. - - - The mode_set operation returns 0 on success - or a negative error code if an error occurs. - - - - void (*commit)(struct drm_crtc *crtc); - - Commit a mode. This operation is called after setting the new mode. - Upon return the device must use the new mode and be fully - operational. - - - - - - Encoder Helper Operations - - - bool (*mode_fixup)(struct drm_encoder *encoder, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - - Let encoders adjust the requested mode or reject it completely. This - operation returns true if the mode is accepted (possibly after being - adjusted) or false if it is rejected. See the - mode_fixup CRTC helper - operation for an explanation of the allowed adjustments. - - - - void (*prepare)(struct drm_encoder *encoder); - - Prepare the encoder for mode setting. This operation is called after - validating the requested mode. Drivers use it to perform - device-specific operations required before setting the new mode. - - - - void (*mode_set)(struct drm_encoder *encoder, - struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - - Set a new mode. Depending on the device requirements, the mode can - be stored internally by the driver and applied in the - commit operation, or programmed to the - hardware immediately. - - - - void (*commit)(struct drm_encoder *encoder); - - Commit a mode. This operation is called after setting the new mode. - Upon return the device must use the new mode and be fully - operational. - - - - - - Connector Helper Operations - - - struct drm_encoder *(*best_encoder)(struct drm_connector *connector); - - Return a pointer to the best encoder for the connecter. Device that - map connectors to encoders 1:1 simply return the pointer to the - associated encoder. This operation is mandatory. - - - - int (*get_modes)(struct drm_connector *connector); - - Fill the connector's probed_modes list - by parsing EDID data with drm_add_edid_modes, - adding standard VESA DMT modes with drm_add_modes_noedid, - or calling drm_mode_probed_add directly for every - supported mode and return the number of modes it has detected. This - operation is mandatory. - - - Note that the caller function will automatically add standard VESA - DMT modes up to 1024x768 if the get_modes - helper operation returns no mode and if the connector status is - connector_status_connected. There is no need to call - drm_add_edid_modes manually in that case. - - - The vrefresh value is computed by - drm_helper_probe_single_connector_modes. - - - When parsing EDID data, drm_add_edid_modes fills the - connector display_info - width_mm and - height_mm fields. When creating modes - manually the get_modes helper operation must - set the display_info - width_mm and - height_mm fields if they haven't been set - already (for instance at initialization time when a fixed-size panel is - attached to the connector). The mode width_mm - and height_mm fields are only used internally - during EDID parsing and should not be set when creating modes manually. - - - - int (*mode_valid)(struct drm_connector *connector, - struct drm_display_mode *mode); - - Verify whether a mode is valid for the connector. Return MODE_OK for - supported modes and one of the enum drm_mode_status values (MODE_*) - for unsupported modes. This operation is optional. - - - As the mode rejection reason is currently not used beside for - immediately removing the unsupported mode, an implementation can - return MODE_BAD regardless of the exact reason why the mode is not - valid. - - - Note that the mode_valid helper operation is - only called for modes detected by the device, and - not for modes set by the user through the CRTC - set_config operation. - - - - Atomic Modeset Helper Functions Reference diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h index 29e0dc50031d..a126a0d7aed4 100644 --- a/include/drm/drm_modeset_helper_vtables.h +++ b/include/drm/drm_modeset_helper_vtables.h @@ -131,6 +131,20 @@ struct drm_crtc_helper_funcs { * Atomic drivers which need to inspect and adjust more state should * instead use the @atomic_check callback. * + * Also beware that neither core nor helpers filter modes before + * passing them to the driver: While the list of modes that is + * advertised to userspace is filtered using the connector's + * ->mode_valid() callback, neither the core nor the helpers do any + * filtering on modes passed in from userspace when setting a mode. It + * is therefore possible for userspace to pass in a mode that was + * previously filtered out using ->mode_valid() or add a custom mode + * that wasn't probed from EDID or similar to begin with. Even though + * this is an advanced feature and rarely used nowadays, some users rely + * on being able to specify modes manually so drivers must be prepared + * to deal with it. Specifically this means that all drivers need not + * only validate modes in ->mode_valid() but also in ->mode_fixup() to + * make sure invalid modes passed in from userspace are rejected. + * * RETURNS: * * True if an acceptable configuration is possible, false if the modeset @@ -188,7 +202,9 @@ struct drm_crtc_helper_funcs { * This callback is used by the legacy CRTC helpers to set a new * framebuffer and scanout position. It is optional and used as an * optimized fast-path instead of a full mode set operation with all the - * resulting flickering. Since it can't update other planes it's + * resulting flickering. If it is not present + * drm_crtc_helper_set_config() will fall back to a full modeset, using + * the ->mode_set() callback. Since it can't update other planes it's * incompatible with atomic modeset support. * * This callback is only used by the CRTC helpers and deprecated. @@ -439,6 +455,20 @@ struct drm_encoder_helper_funcs { * Atomic drivers which need to inspect and adjust more state should * instead use the @atomic_check callback. * + * Also beware that neither core nor helpers filter modes before + * passing them to the driver: While the list of modes that is + * advertised to userspace is filtered using the connector's + * ->mode_valid() callback, neither the core nor the helpers do any + * filtering on modes passed in from userspace when setting a mode. It + * is therefore possible for userspace to pass in a mode that was + * previously filtered out using ->mode_valid() or add a custom mode + * that wasn't probed from EDID or similar to begin with. Even though + * this is an advanced feature and rarely used nowadays, some users rely + * on being able to specify modes manually so drivers must be prepared + * to deal with it. Specifically this means that all drivers need not + * only validate modes in ->mode_valid() but also in ->mode_fixup() to + * make sure invalid modes passed in from userspace are rejected. + * * RETURNS: * * True if an acceptable configuration is possible, false if the modeset @@ -640,8 +670,16 @@ struct drm_connector_helper_funcs { * In this function drivers then parse the modes in the EDID and add * them by calling drm_add_edid_modes(). But connectors that driver a * fixed panel can also manually add specific modes using - * drm_mode_probed_add(). Finally drivers that support audio probably - * want to update the ELD data, too, using drm_edid_to_eld(). + * drm_mode_probed_add(). Drivers which manually add modes should also + * make sure that the @display_info, @width_mm and @height_mm fields of the + * struct #drm_connector are filled in. + * + * Virtual drivers that just want some standard VESA mode with a given + * resolution can call drm_add_modes_noedid(), and mark the preferred + * one using drm_set_preferred_mode(). + * + * Finally drivers that support audio probably want to update the ELD + * data, too, using drm_edid_to_eld(). * * This function is only called after the ->detect() hook has indicated * that a sink is connected and when the EDID isn't overridden through -- cgit v1.2.3 From 3d7b75fdae9c81dd71c7573dbc285af90e0924fa Mon Sep 17 00:00:00 2001 From: Lukas Wunner Date: Mon, 11 Jan 2016 00:08:35 +0100 Subject: apple-gmux: Add initial documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- Documentation/DocBook/gpu.tmpl | 22 ++++++++ drivers/platform/x86/apple-gmux.c | 113 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 135 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index faa5e0d4208d..a8669330b456 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -3470,8 +3470,30 @@ int num_ioctls; + + Handlers + + apple-gmux Handler +!Pdrivers/platform/x86/apple-gmux.c Overview +!Pdrivers/platform/x86/apple-gmux.c Interrupt + + Graphics mux +!Pdrivers/platform/x86/apple-gmux.c Graphics mux + + + Power control +!Pdrivers/platform/x86/apple-gmux.c Power control + + + Backlight control +!Pdrivers/platform/x86/apple-gmux.c Backlight control + + + + !Cdrivers/gpu/vga/vga_switcheroo.c !Cinclude/linux/vga_switcheroo.h +!Cdrivers/platform/x86/apple-gmux.c diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c index 976efeb3f2ba..2b921dea10f4 100644 --- a/drivers/platform/x86/apple-gmux.c +++ b/drivers/platform/x86/apple-gmux.c @@ -3,6 +3,7 @@ * * Copyright (C) Canonical Ltd. * Copyright (C) 2010-2012 Andreas Heider + * Copyright (C) 2015 Lukas Wunner * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -26,6 +27,24 @@ #include #include +/** + * DOC: Overview + * + * :1: http://www.latticesemi.com/en/Products/FPGAandCPLD/LatticeXP2.aspx + * :2: http://www.renesas.com/products/mpumcu/h8s/h8s2100/h8s2113/index.jsp + * + * gmux is a microcontroller built into the MacBook Pro to support dual GPUs: + * A {1}[Lattice XP2] on pre-retinas, a {2}[Renesas R4F2113] on retinas. + * + * (The MacPro6,1 2013 also has a gmux, however it is unclear why since it has + * dual GPUs but no built-in display.) + * + * gmux is connected to the LPC bus of the southbridge. Its I/O ports are + * accessed differently depending on the microcontroller: Driver functions + * to access a pre-retina gmux are infixed `_pio_`, those for a retina gmux + * are infixed `_index_`. + */ + struct apple_gmux_data { unsigned long iostart; unsigned long iolen; @@ -247,6 +266,20 @@ static bool gmux_is_indexed(struct apple_gmux_data *gmux_data) return false; } +/** + * DOC: Backlight control + * + * :3: http://www.ti.com/lit/ds/symlink/lp8543.pdf + * :4: http://www.ti.com/lit/ds/symlink/lp8545.pdf + * + * On single GPU MacBooks, the PWM signal for the backlight is generated by + * the GPU. On dual GPU MacBook Pros by contrast, either GPU may be suspended + * to conserve energy. Hence the PWM signal needs to be generated by a separate + * backlight driver which is controlled by gmux. The earliest generation + * MBP5 2008/09 uses a {3}[TI LP8543] backlight driver. All newer models + * use a {4}[TI LP8545]. + */ + static int gmux_get_brightness(struct backlight_device *bd) { struct apple_gmux_data *gmux_data = bl_get_data(bd); @@ -273,6 +306,68 @@ static const struct backlight_ops gmux_bl_ops = { .update_status = gmux_update_status, }; +/** + * DOC: Graphics mux + * + * :5: http://pimg-fpiw.uspto.gov/fdd/07/870/086/0.pdf + * :6: http://www.nxp.com/documents/data_sheet/CBTL06141.pdf + * :7: http://www.ti.com/lit/ds/symlink/hd3ss212.pdf + * :8: https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf + * :9: http://www.ti.com/lit/ds/symlink/sn74lv4066a.pdf + * :10: http://pdf.datasheetarchive.com/indexerfiles/Datasheets-SW16/DSASW00308511.pdf + * :11: http://www.ti.com/lit/ds/symlink/ts3ds10224.pdf + * + * On pre-retinas, the LVDS outputs of both GPUs feed into gmux which muxes + * either of them to the panel. One of the tricks gmux has up its sleeve is + * to lengthen the blanking interval of its output during a switch to + * synchronize it with the GPU switched to. This allows for a flicker-free + * switch that is imperceptible by the user ({5}[US 8,687,007 B2]). + * + * On retinas, muxing is no longer done by gmux itself, but by a separate + * chip which is controlled by gmux. The chip is triple sourced, it is + * either an {6}[NXP CBTL06142], {7}[TI HD3SS212] or {8}[Pericom PI3VDP12412]. + * The panel is driven with eDP instead of LVDS since the pixel clock + * required for retina resolution exceeds LVDS' limits. + * + * Pre-retinas are able to switch the panel's DDC pins separately. + * This is handled by a {9}[TI SN74LV4066A] which is controlled by gmux. + * The inactive GPU can thus probe the panel's EDID without switching over + * the entire panel. Retinas lack this functionality as the chips used for + * eDP muxing are incapable of switching the AUX channel separately (see + * the linked data sheets, Pericom would be capable but this is unused). + * However the retina panel has the NO_AUX_HANDSHAKE_LINK_TRAINING bit set + * in its DPCD, allowing the inactive GPU to skip the AUX handshake and + * set up the output with link parameters pre-calibrated by the active GPU. + * + * The external DP port is only fully switchable on the first two unibody + * MacBook Pro generations, MBP5 2008/09 and MBP6 2010. This is done by an + * {6}[NXP CBTL06141] which is controlled by gmux. It's the predecessor of the + * eDP mux on retinas, the difference being support for 2.7 versus 5.4 Gbit/s. + * + * The following MacBook Pro generations replaced the external DP port with a + * combined DP/Thunderbolt port and lost the ability to switch it between GPUs, + * connecting it either to the discrete GPU or the Thunderbolt controller. + * Oddly enough, while the full port is no longer switchable, AUX and HPD + * are still switchable by way of an {10}[NXP CBTL03062] (on pre-retinas + * MBP8 2011 and MBP9 2012) or two {11}[TI TS3DS10224] (on retinas) under the + * control of gmux. Since the integrated GPU is missing the main link, + * external displays appear to it as phantoms which fail to link-train. + * + * gmux receives the HPD signal of all display connectors and sends an + * interrupt on hotplug. On generations which cannot switch external ports, + * the discrete GPU can then be woken to drive the newly connected display. + * The ability to switch AUX on these generations could be used to improve + * reliability of hotplug detection by having the integrated GPU poll the + * ports while the discrete GPU is asleep, but currently we do not make use + * of this feature. + * + * gmux' initial switch state on bootup is user configurable via the EFI + * variable `gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9` (5th byte, + * 1 = IGD, 0 = DIS). Based on this setting, the EFI firmware tells gmux to + * switch the panel and the external DP connector and allocates a framebuffer + * for the selected GPU. + */ + static int gmux_switchto(enum vga_switcheroo_client_id id) { if (id == VGA_SWITCHEROO_IGD) { @@ -288,6 +383,14 @@ static int gmux_switchto(enum vga_switcheroo_client_id id) return 0; } +/** + * DOC: Power control + * + * gmux is able to cut power to the discrete GPU. It automatically takes care + * of the correct sequence to tear down and bring up the power rails for + * core voltage, VRAM and PCIe. + */ + static int gmux_set_discrete_state(struct apple_gmux_data *gmux_data, enum vga_switcheroo_state state) { @@ -352,6 +455,16 @@ static const struct vga_switcheroo_handler gmux_handler = { .get_client_id = gmux_get_client_id, }; +/** + * DOC: Interrupt + * + * gmux is also connected to a GPIO pin of the southbridge and thereby is able + * to trigger an ACPI GPE. On the MBP5 2008/09 it's GPIO pin 22 of the Nvidia + * MCP79, on all following generations it's GPIO pin 6 of the Intel PCH. + * The GPE merely signals that an interrupt occurred, the actual type of event + * is identified by reading a gmux register. + */ + static inline void gmux_disable_interrupts(struct apple_gmux_data *gmux_data) { gmux_write8(gmux_data, GMUX_PORT_INTERRUPT_ENABLE, -- cgit v1.2.3