1
0
Fork 0
alistair23-linux/drivers/gpu/drm/i915/intel_bios.h

224 lines
5.2 KiB
C
Raw Normal View History

/*
* Copyright © 2016 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
/*
* Please use intel_vbt_defs.h for VBT private data, to hide and abstract away
* the VBT from the rest of the driver. Add the parsed, clean data to struct
* intel_vbt_data within struct drm_i915_private.
*/
#ifndef _INTEL_BIOS_H_
#define _INTEL_BIOS_H_
enum intel_backlight_type {
INTEL_BACKLIGHT_PMIC,
INTEL_BACKLIGHT_LPSS,
INTEL_BACKLIGHT_DISPLAY_DDI,
INTEL_BACKLIGHT_DSI_DCS,
INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE,
};
struct edp_power_seq {
drm/i915: Correct eDP panel power sequencing delay computations Store the panel power sequencing delays in the dp private structure, rather than the global device structure. Who knows, maybe we'll get more than one eDP device in the future. From the eDP spec, we need the following numbers: T1 + T3 Power on to Aux Channel operation (panel_power_up_delay) This marks how long it takes the panel to boot up and get ready to receive aux channel communications. T8 Video signal to backlight on (backlight_on_delay) Once a valid video signal is being sent to the device, it can take a while before the panel is actuall showing useful data. This delay allows the panel to get something reasonable up before the backlight is turned on. T9 Backlight off to video off (backlight_off_delay) Turning the backlight off can take a moment, so this delay makes sure there is still valid video data on the screen. T10 Video off to power off (panel_power_down_delay) Presumably this delay allows the panel to perform an orderly shutdown of the display. T11 + T12 Power off to power on (panel_power_cycle_delay) So, once you turn the panel off, you have to wait a while before you can turn it back on. This delay is usually the longest in the entire sequence. Neither the VBIOS source code nor the hardware documentation has a clear mapping between the delay values they provide and those required by the eDP spec. The VBIOS code actually uses two different labels for the delay values in the five words of the relevant VBT table. **** MORE LATER *** Look at both the current hardware register settings and the VBT specified panel power sequencing timings. Use the maximum of the two delays, to make sure things work reliably. If there is no VBT data, then those values will be initialized to zero, so we'll just use the values as programmed in the hardware. Note that the BIOS just fetches delays from the VBT table to place in the hardware registers, so we should get the same values from both places, except for rounding. VBT doesn't provide any values for T1 or T2, so we'll always just use the hardware value for that. The panel power up delay is thus T1 + T2 + T3, which should be sufficient in all cases. The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy for T11, which isn't available anywhere. For the backlight delays, the eDP spec says T6 + T8 is the delay from the end of link training to backlight on and T9 is the delay from backlight off until video off. The hardware provides a 'backlight on' delay, which I'm taking to be T6 + T8 while the VBT provides something called 'T7', which I'm assuming is s On the macbook air I'm testing with, this yields a power-up delay of over 200ms and a power-down delay of over 600ms. It all works now, but we're frobbing these power controls several times during mode setting, making the whole process take an awfully long time. Signed-off-by: Keith Packard <keithp@keithp.com>
2011-09-28 17:48:10 -06:00
u16 t1_t3;
u16 t8;
u16 t9;
u16 t10;
drm/i915: Correct eDP panel power sequencing delay computations Store the panel power sequencing delays in the dp private structure, rather than the global device structure. Who knows, maybe we'll get more than one eDP device in the future. From the eDP spec, we need the following numbers: T1 + T3 Power on to Aux Channel operation (panel_power_up_delay) This marks how long it takes the panel to boot up and get ready to receive aux channel communications. T8 Video signal to backlight on (backlight_on_delay) Once a valid video signal is being sent to the device, it can take a while before the panel is actuall showing useful data. This delay allows the panel to get something reasonable up before the backlight is turned on. T9 Backlight off to video off (backlight_off_delay) Turning the backlight off can take a moment, so this delay makes sure there is still valid video data on the screen. T10 Video off to power off (panel_power_down_delay) Presumably this delay allows the panel to perform an orderly shutdown of the display. T11 + T12 Power off to power on (panel_power_cycle_delay) So, once you turn the panel off, you have to wait a while before you can turn it back on. This delay is usually the longest in the entire sequence. Neither the VBIOS source code nor the hardware documentation has a clear mapping between the delay values they provide and those required by the eDP spec. The VBIOS code actually uses two different labels for the delay values in the five words of the relevant VBT table. **** MORE LATER *** Look at both the current hardware register settings and the VBT specified panel power sequencing timings. Use the maximum of the two delays, to make sure things work reliably. If there is no VBT data, then those values will be initialized to zero, so we'll just use the values as programmed in the hardware. Note that the BIOS just fetches delays from the VBT table to place in the hardware registers, so we should get the same values from both places, except for rounding. VBT doesn't provide any values for T1 or T2, so we'll always just use the hardware value for that. The panel power up delay is thus T1 + T2 + T3, which should be sufficient in all cases. The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy for T11, which isn't available anywhere. For the backlight delays, the eDP spec says T6 + T8 is the delay from the end of link training to backlight on and T9 is the delay from backlight off until video off. The hardware provides a 'backlight on' delay, which I'm taking to be T6 + T8 while the VBT provides something called 'T7', which I'm assuming is s On the macbook air I'm testing with, this yields a power-up delay of over 200ms and a power-down delay of over 600ms. It all works now, but we're frobbing these power controls several times during mode setting, making the whole process take an awfully long time. Signed-off-by: Keith Packard <keithp@keithp.com>
2011-09-28 17:48:10 -06:00
u16 t11_t12;
} __packed;
drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline i915 code was doing the same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET / MIPI_SEQ_DEASSERT_RESET. Looking at the naming of the sequences that is the right thing to do, but the problem is, that the old mainline code and the ADF code was actually calling the right sequence (tested on a cube iwork8 air tablet), and the swapping of the calling breaks things. This breakage was likely not noticed in testing because on cherrytrail, currently chv_exec_gpio ends up disabling the gpio pins rather then setting them (this is fixed in the next patch in this patch-set). This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's places in the enum defining them, so that their (new) names match their actual use. Changes in v2: -Add a comment to the enum explaining that the assert/reassert names are swapped in the spec Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202150128.29871-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 2b8208ac93be2783edc627fc02d9ca50cc479923) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-02 08:01:28 -07:00
/*
* MIPI Sequence Block definitions
*
* Note the VBT spec has AssertReset / DeassertReset swapped from their
* usual naming, we use the proper names here to avoid confusion when
* reading the code.
*/
enum mipi_seq {
MIPI_SEQ_END = 0,
drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline i915 code was doing the same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET / MIPI_SEQ_DEASSERT_RESET. Looking at the naming of the sequences that is the right thing to do, but the problem is, that the old mainline code and the ADF code was actually calling the right sequence (tested on a cube iwork8 air tablet), and the swapping of the calling breaks things. This breakage was likely not noticed in testing because on cherrytrail, currently chv_exec_gpio ends up disabling the gpio pins rather then setting them (this is fixed in the next patch in this patch-set). This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's places in the enum defining them, so that their (new) names match their actual use. Changes in v2: -Add a comment to the enum explaining that the assert/reassert names are swapped in the spec Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202150128.29871-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 2b8208ac93be2783edc627fc02d9ca50cc479923) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-02 08:01:28 -07:00
MIPI_SEQ_DEASSERT_RESET, /* Spec says MipiAssertResetPin */
MIPI_SEQ_INIT_OTP,
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline i915 code was doing the same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET / MIPI_SEQ_DEASSERT_RESET. Looking at the naming of the sequences that is the right thing to do, but the problem is, that the old mainline code and the ADF code was actually calling the right sequence (tested on a cube iwork8 air tablet), and the swapping of the calling breaks things. This breakage was likely not noticed in testing because on cherrytrail, currently chv_exec_gpio ends up disabling the gpio pins rather then setting them (this is fixed in the next patch in this patch-set). This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's places in the enum defining them, so that their (new) names match their actual use. Changes in v2: -Add a comment to the enum explaining that the assert/reassert names are swapped in the spec Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202150128.29871-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 2b8208ac93be2783edc627fc02d9ca50cc479923) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-02 08:01:28 -07:00
MIPI_SEQ_ASSERT_RESET, /* Spec says MipiDeassertResetPin */
MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
MIPI_SEQ_TEAR_OFF, /* sequence block v3+ */
MIPI_SEQ_POWER_ON, /* sequence block v3+ */
MIPI_SEQ_POWER_OFF, /* sequence block v3+ */
MIPI_SEQ_MAX
};
enum mipi_seq_element {
MIPI_SEQ_ELEM_END = 0,
MIPI_SEQ_ELEM_SEND_PKT,
MIPI_SEQ_ELEM_DELAY,
MIPI_SEQ_ELEM_GPIO,
MIPI_SEQ_ELEM_I2C, /* sequence block v2+ */
MIPI_SEQ_ELEM_SPI, /* sequence block v3+ */
MIPI_SEQ_ELEM_PMIC, /* sequence block v3+ */
MIPI_SEQ_ELEM_MAX
};
#define MIPI_DSI_UNDEFINED_PANEL_ID 0
#define MIPI_DSI_GENERIC_PANEL_ID 1
struct mipi_config {
u16 panel_id;
/* General Params */
u32 enable_dithering:1;
u32 rsvd1:1;
u32 is_bridge:1;
u32 panel_arch_type:2;
u32 is_cmd_mode:1;
#define NON_BURST_SYNC_PULSE 0x1
#define NON_BURST_SYNC_EVENTS 0x2
#define BURST_MODE 0x3
u32 video_transfer_mode:2;
u32 cabc_supported:1;
#define PPS_BLC_PMIC 0
#define PPS_BLC_SOC 1
u32 pwm_blc:1;
/* Bit 13:10 */
#define PIXEL_FORMAT_RGB565 0x1
#define PIXEL_FORMAT_RGB666 0x2
#define PIXEL_FORMAT_RGB666_LOOSELY_PACKED 0x3
#define PIXEL_FORMAT_RGB888 0x4
u32 videomode_color_format:4;
/* Bit 15:14 */
#define ENABLE_ROTATION_0 0x0
#define ENABLE_ROTATION_90 0x1
#define ENABLE_ROTATION_180 0x2
#define ENABLE_ROTATION_270 0x3
u32 rotation:2;
u32 bta_enabled:1;
u32 rsvd2:15;
/* 2 byte Port Description */
#define DUAL_LINK_NOT_SUPPORTED 0
#define DUAL_LINK_FRONT_BACK 1
#define DUAL_LINK_PIXEL_ALT 2
u16 dual_link:2;
u16 lane_cnt:2;
u16 pixel_overlap:3;
u16 rgb_flip:1;
#define DL_DCS_PORT_A 0x00
#define DL_DCS_PORT_C 0x01
#define DL_DCS_PORT_A_AND_C 0x02
u16 dl_dcs_cabc_ports:2;
u16 dl_dcs_backlight_ports:2;
u16 rsvd3:4;
u16 rsvd4;
u8 rsvd5;
u32 target_burst_mode_freq;
u32 dsi_ddr_clk;
u32 bridge_ref_clk;
#define BYTE_CLK_SEL_20MHZ 0
#define BYTE_CLK_SEL_10MHZ 1
#define BYTE_CLK_SEL_5MHZ 2
u8 byte_clk_sel:2;
u8 rsvd6:6;
/* DPHY Flags */
u16 dphy_param_valid:1;
u16 eot_pkt_disabled:1;
u16 enable_clk_stop:1;
u16 rsvd7:13;
u32 hs_tx_timeout;
u32 lp_rx_timeout;
u32 turn_around_timeout;
u32 device_reset_timer;
u32 master_init_timer;
u32 dbi_bw_timer;
u32 lp_byte_clk_val;
/* 4 byte Dphy Params */
u32 prepare_cnt:6;
u32 rsvd8:2;
u32 clk_zero_cnt:8;
u32 trail_cnt:5;
u32 rsvd9:3;
u32 exit_zero_cnt:6;
u32 rsvd10:2;
u32 clk_lane_switch_cnt;
u32 hl_switch_cnt;
u32 rsvd11[6];
/* timings based on dphy spec */
u8 tclk_miss;
u8 tclk_post;
u8 rsvd12;
u8 tclk_pre;
u8 tclk_prepare;
u8 tclk_settle;
u8 tclk_term_enable;
u8 tclk_trail;
u16 tclk_prepare_clkzero;
u8 rsvd13;
u8 td_term_enable;
u8 teot;
u8 ths_exit;
u8 ths_prepare;
u16 ths_prepare_hszero;
u8 rsvd14;
u8 ths_settle;
u8 ths_skip;
u8 ths_trail;
u8 tinit;
u8 tlpx;
u8 rsvd15[3];
/* GPIOs */
u8 panel_enable;
u8 bl_enable;
u8 pwm_enable;
u8 reset_r_n;
u8 pwr_down_r;
u8 stdby_r_n;
} __packed;
/* all delays have a unit of 100us */
struct mipi_pps_data {
u16 panel_on_delay;
u16 bl_enable_delay;
u16 bl_disable_delay;
u16 panel_off_delay;
u16 panel_power_cycle_delay;
} __packed;
#endif /* _INTEL_BIOS_H_ */