Re: [Intel-gfx] [PATCH v3.5 02.5/22] drm/i915: add intel_display_suspend
Op 23-05-15 om 01:03 schreef Matt Roper:
On Thu, May 21, 2015 at 02:33:31PM +0200, Maarten Lankhorst wrote:
This is a function used to disable all crtc's. This makes it clearer
to distinguish between when mode needs to be preserved and when
it can be trashed.
To clarify, when you talk about mode being preserved or trashed here,
you're talking about the hardware's idea of the mode, not the driver's
software state, right? I.e., because when we shut down a power well the
registers vanish and whatever was programmed in them is lost?
See my comments farther down.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
Oops, I was trashing all state during suspend and on gpu reset.
I will send an amended intel_crtc_control patch too with the
suspend and prepare_reset parts taken out.
drivers/gpu/drm/i915/i915_drv.c | 4 +---
drivers/gpu/drm/i915/intel_display.c | 29 +++--
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 5cc57f2ec192..d1a090a9f653 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -600,7 +600,6 @@ static int skl_resume_prepare(struct drm_i915_private
*dev_priv);
static int i915_drm_suspend(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
-struct drm_crtc *crtc;
pci_power_t opregion_target_state;
int error;
@@ -631,8 +630,7 @@ static int i915_drm_suspend(struct drm_device *dev)
* for _thaw. Also, power gate the CRTC power wells.
*/
drm_modeset_lock_all(dev);
-for_each_crtc(dev, crtc)
-intel_crtc_control(crtc, false);
+intel_display_suspend(dev);
I'm not terribly familiar with the power well details, but it looks like
part of the motivation of commit
commit b04c5bd6fda54703e56f29569e4bca489d6c5a5c
Author: Borun Fu borun...@intel.com
Date: Sat Jul 12 10:02:27 2014 +0530
drm/i915: Power gating display wells during i915_pm_suspend
which added intel_crtc_control() was to ensure the power wells were
gated at this point; by replacing the intel_crtc_control() with
intel_display_suspend() here, you're removing that power well
programming...is that intentional (and is it going to cause the display
to stay in D0 state)?
If it is intentional, the comment above this block is out of date now.
Since this patch (and the following one) seem to change the semantics of
when we're touching power wells at various points in the code, maybe you
can elaborate a little bit on that in the commit message of one or both
commits.
You're right, I'm not touching power wells here. For the hang case that doesn't
matter but for pm_suspend it probably does.
The followup patch that converts intel_display_suspend to atomic modeset should
restore the old behavior.
I'll respin with some changes that I'll undo when converting
intel_display_suspend to atomic modeset.
One thing that also seems to unintentionally change behavior is
intel_display_set_init_power being unset by modeset_update_crtc_power_domains.
I'll fix that in the followup patch that converts this function to atomic.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make DRM_I915_WERROR depend on !COMPILE_TEST
On Mon, 25 May 2015, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote: With allyesconfig/allmodconfig, kbuild enables all the options it can, including DRM_I915_WERROR. That's not really what we want with -Werror, and this was breaking the build for Andrew. Andrew suggested to use COMPILE_TEST as a way to 'detect' these configurations. An alternative would be to inverse the condition of the option: DRM_I915_NO_WERROR. Setting that one to Y would have no effect, at the price of a bit of confusion. Another alternative would be to introduce a allyesmodconfig_n property to config entries, like the allnoconfig_y one we have today: - allnoconfig_y This declares the symbol as one that should have the value y when using allnoconfig. Used for symbols that hide other symbols. Of course, allyesmodconfig_n would set the value to n when using allmodconfig or allmodconfig. That alternative needs a bit more work though and may not be desirable, given that even allnoconfig_y is used only once today. Reported-by: Andrew Morton a...@linux-foundation.org Suggested-by: Andrew Morton a...@linux-foundation.org Cc: Andrew Morton a...@linux-foundation.org Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Damien Lespiau damien.lesp...@intel.com As a proxy, it seems reasonable. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Do you also have a patch for the broken code? :) One of the things I looked at was the compiler being silly. Jani. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 01.org: HTTPS: Please fix mixed content loading
On Sat, 23 May 2015, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Intel folks, accessing the resources at 01.org over HTTPS, some have mixed content loading issues. For example [1] loads an image from Gravatar – for whatever reason – over HTTP. Google Chromium reports for example the following. Mixed Content: The page at 'https://01.org/linuxgraphics/documentation/how-report-bugs' was loaded over HTTPS, but requested an insecure image 'http://www.gravatar.com/avatar/672c5e6b44ca5810141d82f730aad074.jpg?d=mms=50r=G'. This content should also be served over HTTPS. Thanks, Paul [1] https://01.org/linuxgraphics/documentation/how-report-bugs Thanks for the report, Paul. Rodrigo, please pass this on to whoever it is that maintains the site. Thanks, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make DRM_I915_WERROR depend on !COMPILE_TEST
On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote: With allyesconfig/allmodconfig, kbuild enables all the options it can, including DRM_I915_WERROR. That's not really what we want with -Werror, and this was breaking the build for Andrew. Andrew suggested to use COMPILE_TEST as a way to 'detect' these configurations. An alternative would be to inverse the condition of the option: DRM_I915_NO_WERROR. Setting that one to Y would have no effect, at the price of a bit of confusion. Another alternative would be to introduce a allyesmodconfig_n property to config entries, like the allnoconfig_y one we have today: - allnoconfig_y This declares the symbol as one that should have the value y when using allnoconfig. Used for symbols that hide other symbols. Of course, allyesmodconfig_n would set the value to n when using allmodconfig or allmodconfig. That alternative needs a bit more work though and may not be desirable, given that even allnoconfig_y is used only once today. Reported-by: Andrew Morton a...@linux-foundation.org Suggested-by: Andrew Morton a...@linux-foundation.org Cc: Andrew Morton a...@linux-foundation.org Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Damien Lespiau damien.lesp...@intel.com As a proxy, it seems reasonable. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Do you also have a patch for the broken code? :) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/i915/bxt: DSI encoder support in CRTC modeset
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
functions are re-used for modeset sequence. But DDI interface doesn't
include support for DSI.
This patch adds:
1. cases for DSI encoder, in those modeset functions and allows a CRTC modeset
2. Adds call to pre_pll enabled from CRTC modeset function. Nothing needs to
be
done as such in CRTC for DSI encoder, as PLL, clock and and transcoder
programming
will be taken care in encoder's pre_enable and pre_pll_enable function.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_ddi.c | 53
+
drivers/gpu/drm/i915/intel_display.c |6 +++-
drivers/gpu/drm/i915/intel_opregion.c |1 +
4 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 840f08f..6874121 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2452,6 +2452,7 @@ struct drm_i915_cmd_table {
INTEL_INFO(dev)-gen = 9)
#define HAS_DDI(dev) (INTEL_INFO(dev)-has_ddi)
+#define has_encoder_ddi(type)((type) == (INTEL_OUTPUT_DSI) ? 0 : 1)
#define HAS_FPGA_DBG_UNCLAIMED(dev) (INTEL_INFO(dev)-has_fpga_dbg)
#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index d602db2..2aef8b5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -395,6 +395,12 @@ void intel_prepare_ddi(struct drm_device *dev)
if (visited[port])
continue;
+ if (intel_dig_port-base.type ==
+ INTEL_OUTPUT_DSI) {
+ visited[intel_dig_port-port] = true;
+ continue;
+ }
+
ddi_get_encoder_port does not support DSI, and DSI does not have
intel_digital_port.
supports_hdmi = intel_dig_port
intel_dig_port_supports_hdmi(intel_dig_port);
@@ -1568,10 +1574,21 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe = intel_crtc-pipe;
enum transcoder cpu_transcoder = intel_crtc-config-cpu_transcoder;
- enum port port = intel_ddi_get_encoder_port(intel_encoder);
+ enum port port;
int type = intel_encoder-type;
uint32_t temp;
+ /*
+ * Fixme: BXT has DDI, so tries to follow a DDI modeset function,
It's FIXME, TODO, or XXX, upper case. Grep must find these.
+ * but DDI interface doesn't support DSI yet, so don't do anything
+ * for DSI encoders
+ */
+ if (!(HAS_DDI(dev) has_encoder_ddi(type))) {
HAS_DDI() is always true here.
Hmm. Perhaps it would be nicer if we added INVALID_PORT = -1 to enum
port, and had intel_ddi_get_encoder_port() return that for DSI. Then we
could leave most of the functions the same, with just
if (port == INVALID_PORT)
return;
at the beginning.
Daniel, opinions?
+ DRM_DEBUG_DRIVER(Not setting transcoder for DSI\n);
+ return;
+ }
+
+ port = intel_ddi_get_encoder_port(intel_encoder);
/* Enable TRANS_DDI_FUNC_CTL for the pipe to work in HDMI mode */
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
@@ -1779,11 +1796,17 @@ bool intel_ddi_get_hw_state(struct intel_encoder
*encoder,
void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc)
{
struct drm_crtc *crtc = intel_crtc-base;
- struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
- enum port port = intel_ddi_get_encoder_port(intel_encoder);
+ enum port port;
enum transcoder cpu_transcoder = intel_crtc-config-cpu_transcoder;
+ int type = intel_encoder-type;
+ if (!(HAS_DDI(dev) has_encoder_ddi(type)))
+ return;
+
+ port = intel_ddi_get_encoder_port(intel_encoder);
if (cpu_transcoder != TRANSCODER_EDP)
I915_WRITE(TRANS_CLK_SEL(cpu_transcoder),
TRANS_CLK_SEL_PORT(port));
@@ -1866,10 +1889,16 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc =
Re: [Intel-gfx] [PATCH 05/12] drm/i915/bxt: DSI encoder support in CRTC modeset
Please disregard this one, sent prematurely. Sorry.
On Mon, 25 May 2015, Jani Nikula jani.nik...@linux.intel.com wrote:
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
functions are re-used for modeset sequence. But DDI interface doesn't
include support for DSI.
This patch adds:
1. cases for DSI encoder, in those modeset functions and allows a CRTC
modeset
2. Adds call to pre_pll enabled from CRTC modeset function. Nothing needs to
be
done as such in CRTC for DSI encoder, as PLL, clock and and transcoder
programming
will be taken care in encoder's pre_enable and pre_pll_enable function.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_ddi.c | 53
+
drivers/gpu/drm/i915/intel_display.c |6 +++-
drivers/gpu/drm/i915/intel_opregion.c |1 +
4 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 840f08f..6874121 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2452,6 +2452,7 @@ struct drm_i915_cmd_table {
INTEL_INFO(dev)-gen = 9)
#define HAS_DDI(dev)(INTEL_INFO(dev)-has_ddi)
+#define has_encoder_ddi(type) ((type) == (INTEL_OUTPUT_DSI) ? 0 : 1)
#define HAS_FPGA_DBG_UNCLAIMED(dev) (INTEL_INFO(dev)-has_fpga_dbg)
#define HAS_PSR(dev)(IS_HASWELL(dev) || IS_BROADWELL(dev)
|| \
IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index d602db2..2aef8b5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -395,6 +395,12 @@ void intel_prepare_ddi(struct drm_device *dev)
if (visited[port])
continue;
+if (intel_dig_port-base.type ==
+INTEL_OUTPUT_DSI) {
+visited[intel_dig_port-port] = true;
+continue;
+}
+
ddi_get_encoder_port does not support DSI, and DSI does not have
intel_digital_port.
Jani.
supports_hdmi = intel_dig_port
intel_dig_port_supports_hdmi(intel_dig_port);
@@ -1568,10 +1574,21 @@ void intel_ddi_enable_transcoder_func(struct
drm_crtc *crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe = intel_crtc-pipe;
enum transcoder cpu_transcoder = intel_crtc-config-cpu_transcoder;
-enum port port = intel_ddi_get_encoder_port(intel_encoder);
+enum port port;
int type = intel_encoder-type;
uint32_t temp;
+/*
+ * Fixme: BXT has DDI, so tries to follow a DDI modeset function,
It's FIXME, TODO, or XXX, upper case. Grep must find these.
+ * but DDI interface doesn't support DSI yet, so don't do anything
+ * for DSI encoders
+ */
+if (!(HAS_DDI(dev) has_encoder_ddi(type))) {
HAS_DDI() is always true
+DRM_DEBUG_DRIVER(Not setting transcoder for DSI\n);
+return;
+}
+
+port = intel_ddi_get_encoder_port(intel_encoder);
/* Enable TRANS_DDI_FUNC_CTL for the pipe to work in HDMI mode */
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
@@ -1779,11 +1796,17 @@ bool intel_ddi_get_hw_state(struct intel_encoder
*encoder,
void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc)
{
struct drm_crtc *crtc = intel_crtc-base;
-struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+struct drm_device *dev = crtc-dev;
+struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-enum port port = intel_ddi_get_encoder_port(intel_encoder);
+enum port port;
enum transcoder cpu_transcoder = intel_crtc-config-cpu_transcoder;
+int type = intel_encoder-type;
+if (!(HAS_DDI(dev) has_encoder_ddi(type)))
+return;
+
+port = intel_ddi_get_encoder_port(intel_encoder);
if (cpu_transcoder != TRANSCODER_EDP)
I915_WRITE(TRANS_CLK_SEL(cpu_transcoder),
TRANS_CLK_SEL_PORT(port));
@@ -1866,10 +1889,16 @@ static void intel_ddi_pre_enable(struct
intel_encoder *intel_encoder)
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc = to_intel_crtc(encoder-crtc);
-enum port port = intel_ddi_get_encoder_port(intel_encoder);
+enum port port;
int type = intel_encoder-type;
int hdmi_level;
+if (!(HAS_DDI(dev)
Re: [Intel-gfx] [PATCH v2 1/9] drm/i915: Implement WaEnableHDMI8bpcBefore12bpc:snb, ivb
Reviewed-by: Ander Conselvan de Oliveira conselv...@gmail.com
On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
CPT/PPT require a specific procedure for enabling 12bpc HDMI. Implement
it, and to keep things neat pull the code into a function.
v2: Rebased due to crtc-config changes
s/HDMI_GC/HDMIUNIT_GC/ to match spec better
Factor out intel_enable_hdmi_audio()
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 74
+++
2 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2339ffa..e619e41 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6149,6 +6149,7 @@ enum skl_disp_power_wells {
#define _TRANSA_CHICKEN1 0xf0060
#define _TRANSB_CHICKEN1 0xf1060
#define TRANS_CHICKEN1(pipe) _PIPE(pipe, _TRANSA_CHICKEN1, _TRANSB_CHICKEN1)
+#define TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE (110)
#define TRANS_CHICKEN1_DP0UNIT_GC_DISABLE (14)
#define _TRANSA_CHICKEN2 0xf0064
#define _TRANSB_CHICKEN2 0xf1064
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a84c040..79cf445 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -814,6 +814,16 @@ static void intel_hdmi_get_config(struct intel_encoder
*encoder,
pipe_config-base.adjusted_mode.crtc_clock = dotclock;
}
+static void intel_enable_hdmi_audio(struct intel_encoder *encoder)
+{
+ struct intel_crtc *crtc = to_intel_crtc(encoder-base.crtc);
+
+ WARN_ON(!crtc-config-has_hdmi_sink);
+ DRM_DEBUG_DRIVER(Enabling HDMI audio on pipe %c\n,
+ pipe_name(crtc-pipe));
+ intel_audio_codec_enable(encoder);
+}
+
static void intel_enable_hdmi(struct intel_encoder *encoder)
{
struct drm_device *dev = encoder-base.dev;
@@ -854,12 +864,61 @@ static void intel_enable_hdmi(struct intel_encoder
*encoder)
POSTING_READ(intel_hdmi-hdmi_reg);
}
- if (intel_crtc-config-has_audio) {
- WARN_ON(!intel_crtc-config-has_hdmi_sink);
- DRM_DEBUG_DRIVER(Enabling HDMI audio on pipe %c\n,
- pipe_name(intel_crtc-pipe));
- intel_audio_codec_enable(encoder);
+ if (intel_crtc-config-has_audio)
+ intel_enable_hdmi_audio(encoder);
+}
+
+static void cpt_enable_hdmi(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *crtc = to_intel_crtc(encoder-base.crtc);
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder-base);
+ enum pipe pipe = crtc-pipe;
+ u32 temp;
+
+ temp = I915_READ(intel_hdmi-hdmi_reg);
+
+ temp |= SDVO_ENABLE;
+ if (crtc-config-has_audio)
+ temp |= SDVO_AUDIO_ENABLE;
+
+ /*
+ * WaEnableHDMI8bpcBefore12bpc:snb,ivb
+ *
+ * The procedure for 12bpc is as follows:
+ * 1. disable HDMI clock gating
+ * 2. enable HDMI with 8bpc
+ * 3. enable HDMI with 12bpc
+ * 4. enable HDMI clock gating
+ */
+
+ if (crtc-config-pipe_bpp 24) {
+ I915_WRITE(TRANS_CHICKEN1(pipe),
+I915_READ(TRANS_CHICKEN1(pipe)) |
+TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
+
+ temp = ~SDVO_COLOR_FORMAT_MASK;
+ temp |= SDVO_COLOR_FORMAT_8bpc;
}
+
+ I915_WRITE(intel_hdmi-hdmi_reg, temp);
+ POSTING_READ(intel_hdmi-hdmi_reg);
+
+ if (crtc-config-pipe_bpp 24) {
+ temp = ~SDVO_COLOR_FORMAT_MASK;
+ temp |= HDMI_COLOR_FORMAT_12bpc;
+
+ I915_WRITE(intel_hdmi-hdmi_reg, temp);
+ POSTING_READ(intel_hdmi-hdmi_reg);
+
+ I915_WRITE(TRANS_CHICKEN1(pipe),
+I915_READ(TRANS_CHICKEN1(pipe))
+~TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
+ }
+
+ if (crtc-config-has_audio)
+ intel_enable_hdmi_audio(encoder);
}
static void vlv_enable_hdmi(struct intel_encoder *encoder)
@@ -1829,7 +1888,10 @@ void intel_hdmi_init(struct drm_device *dev, int
hdmi_reg, enum port port)
intel_encoder-post_disable = vlv_hdmi_post_disable;
} else {
intel_encoder-pre_enable = intel_hdmi_pre_enable;
- intel_encoder-enable = intel_enable_hdmi;
+ if (HAS_PCH_CPT(dev))
+ intel_encoder-enable = cpt_enable_hdmi;
+ else
+ intel_encoder-enable = intel_enable_hdmi;
}
intel_encoder-type = INTEL_OUTPUT_HDMI;
Re: [Intel-gfx] [PATCH 05/12] drm/i915/bxt: DSI encoder support in CRTC modeset
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset
functions are re-used for modeset sequence. But DDI interface doesn't
include support for DSI.
This patch adds:
1. cases for DSI encoder, in those modeset functions and allows a CRTC modeset
2. Adds call to pre_pll enabled from CRTC modeset function. Nothing needs to
be
done as such in CRTC for DSI encoder, as PLL, clock and and transcoder
programming
will be taken care in encoder's pre_enable and pre_pll_enable function.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_ddi.c | 53
+
drivers/gpu/drm/i915/intel_display.c |6 +++-
drivers/gpu/drm/i915/intel_opregion.c |1 +
4 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 840f08f..6874121 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2452,6 +2452,7 @@ struct drm_i915_cmd_table {
INTEL_INFO(dev)-gen = 9)
#define HAS_DDI(dev) (INTEL_INFO(dev)-has_ddi)
+#define has_encoder_ddi(type)((type) == (INTEL_OUTPUT_DSI) ? 0 : 1)
#define HAS_FPGA_DBG_UNCLAIMED(dev) (INTEL_INFO(dev)-has_fpga_dbg)
#define HAS_PSR(dev) (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index d602db2..2aef8b5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -395,6 +395,12 @@ void intel_prepare_ddi(struct drm_device *dev)
if (visited[port])
continue;
+ if (intel_dig_port-base.type ==
+ INTEL_OUTPUT_DSI) {
+ visited[intel_dig_port-port] = true;
+ continue;
+ }
+
ddi_get_encoder_port does not support DSI, and DSI does not have
intel_digital_port.
Jani.
supports_hdmi = intel_dig_port
intel_dig_port_supports_hdmi(intel_dig_port);
@@ -1568,10 +1574,21 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe = intel_crtc-pipe;
enum transcoder cpu_transcoder = intel_crtc-config-cpu_transcoder;
- enum port port = intel_ddi_get_encoder_port(intel_encoder);
+ enum port port;
int type = intel_encoder-type;
uint32_t temp;
+ /*
+ * Fixme: BXT has DDI, so tries to follow a DDI modeset function,
It's FIXME, TODO, or XXX, upper case. Grep must find these.
+ * but DDI interface doesn't support DSI yet, so don't do anything
+ * for DSI encoders
+ */
+ if (!(HAS_DDI(dev) has_encoder_ddi(type))) {
HAS_DDI() is always true
+ DRM_DEBUG_DRIVER(Not setting transcoder for DSI\n);
+ return;
+ }
+
+ port = intel_ddi_get_encoder_port(intel_encoder);
/* Enable TRANS_DDI_FUNC_CTL for the pipe to work in HDMI mode */
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
@@ -1779,11 +1796,17 @@ bool intel_ddi_get_hw_state(struct intel_encoder
*encoder,
void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc)
{
struct drm_crtc *crtc = intel_crtc-base;
- struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
- enum port port = intel_ddi_get_encoder_port(intel_encoder);
+ enum port port;
enum transcoder cpu_transcoder = intel_crtc-config-cpu_transcoder;
+ int type = intel_encoder-type;
+ if (!(HAS_DDI(dev) has_encoder_ddi(type)))
+ return;
+
+ port = intel_ddi_get_encoder_port(intel_encoder);
if (cpu_transcoder != TRANSCODER_EDP)
I915_WRITE(TRANS_CLK_SEL(cpu_transcoder),
TRANS_CLK_SEL_PORT(port));
@@ -1866,10 +1889,16 @@ static void intel_ddi_pre_enable(struct intel_encoder
*intel_encoder)
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc = to_intel_crtc(encoder-crtc);
- enum port port = intel_ddi_get_encoder_port(intel_encoder);
+ enum port port;
int type = intel_encoder-type;
int hdmi_level;
+ if (!(HAS_DDI(dev) has_encoder_ddi(type))) {
+ DRM_ERROR(DDI func getting called for MIPI?\n);
+
Re: [Intel-gfx] [PATCH 11/12] drm/i915/bxt: Modify BXT BLC according to VBT changes
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Sunil Kamath sunil.kam...@intel.com
Latest VBT mentions which set of registers will be used for BLC,
as controller number field. Making use of this field in BXT
BLC implementation. Also, the registers are used in case control
pin indicates display DDI. Adding a check for this.
According to Bspec, BLC_PWM_*_2 uses the display utility pin for output.
To use backlight 2, enable the utility pin with mode = PWM
v2: Jani's review comments
addressed
- Add a prefix _ to BXT BLC registers definitions.
- Add bxt only comment for u8 controller
- Remove control_pin check for DDI controller
- Check for valid controller values
- Set pipe bits in UTIL_PIN_CTL
- Enable/Disable UTIL_PIN_CTL in enable/disable_backlight()
- If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity
Satheesh's review comment addressed
- If UTIL PIN is already enabled, BIOS would have programmed it. No
need to disable and enable again.
v3: Jani's review comments
- add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK
- Disable UTIL_PIN if controller 1 is used
- Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before enabling
UTIL_PIN
- check valid controller value in intel_bios.c
- add backlight.util_pin_active_low
- disable util pin before enabling
v4: Change for BXT-PO branch:
Stubbed unwanted definition which was existing before
because of DC6 patch.
UTIL_PIN_MODE_PWM (0x1b 24)
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Signed-off-by: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h| 28 +++---
drivers/gpu/drm/i915/intel_drv.h |2 +
drivers/gpu/drm/i915/intel_panel.c | 100
++--
3 files changed, 106 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f96f049..5e3958f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3509,17 +3509,29 @@ enum skl_disp_power_wells {
#define UTIL_PIN_CTL 0x48400
#define UTIL_PIN_ENABLE(1 31)
+#define UTIL_PIN_PIPE(x) ((x) 29)
+#define UTIL_PIN_PIPE_MASK (3 29)
+#define UTIL_PIN_MODE_PWM(1 24)
+#define UTIL_PIN_MODE_MASK (0xf 24)
+#define UTIL_PIN_POLARITY(1 22)
+
/* BXT backlight register definition. */
-#define BXT_BLC_PWM_CTL1 0xC8250
+#define _BXT_BLC_PWM_CTL10xC8250
#define BXT_BLC_PWM_ENABLE (1 31)
#define BXT_BLC_PWM_POLARITY (1 29)
-#define BXT_BLC_PWM_FREQ10xC8254
-#define BXT_BLC_PWM_DUTY10xC8258
-
-#define BXT_BLC_PWM_CTL2 0xC8350
-#define BXT_BLC_PWM_FREQ20xC8354
-#define BXT_BLC_PWM_DUTY20xC8358
-
+#define _BXT_BLC_PWM_FREQ1 0xC8254
+#define _BXT_BLC_PWM_DUTY1 0xC8258
+
+#define _BXT_BLC_PWM_CTL20xC8350
+#define _BXT_BLC_PWM_FREQ2 0xC8354
+#define _BXT_BLC_PWM_DUTY2 0xC8358
+
+#define BXT_BLC_PWM_CTL(controller)_PIPE(controller, \
+ _BXT_BLC_PWM_CTL1, _BXT_BLC_PWM_CTL2)
+#define BXT_BLC_PWM_FREQ(controller) _PIPE(controller, \
+ _BXT_BLC_PWM_FREQ1, _BXT_BLC_PWM_FREQ2)
+#define BXT_BLC_PWM_DUTY(controller) _PIPE(controller, \
+ _BXT_BLC_PWM_DUTY1, _BXT_BLC_PWM_DUTY2)
#define PCH_GTC_CTL 0xe7000
#define PCH_GTC_ENABLE (1 31)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 47bc729..ee9eb2b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -182,7 +182,9 @@ struct intel_panel {
bool enabled;
bool combination_mode; /* gen 2/4 only */
bool active_low_pwm;
+ bool util_pin_active_low; /* bxt+ */
struct backlight_device *device;
+ u8 controller; /* bxt+ only */
} backlight;
void (*backlight_power)(struct intel_connector *, bool enable);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 7d83527..23847f2 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,7 +32,10 @@
#include linux/kernel.h
#include linux/moduleparam.h
+#include drm/drm_panel.h
#include intel_drv.h
+#include intel_dsi.h
+#include i915_drv.h
void
intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
@@ -539,9 +542,10 @@ static u32
Re: [Intel-gfx] [PATCH] drm/i915: Make DRM_I915_WERROR depend on !COMPILE_TEST
On Mon, May 25, 2015 at 12:26:38PM +0300, Jani Nikula wrote: On Mon, 25 May 2015, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote: With allyesconfig/allmodconfig, kbuild enables all the options it can, including DRM_I915_WERROR. That's not really what we want with -Werror, and this was breaking the build for Andrew. Andrew suggested to use COMPILE_TEST as a way to 'detect' these configurations. An alternative would be to inverse the condition of the option: DRM_I915_NO_WERROR. Setting that one to Y would have no effect, at the price of a bit of confusion. Another alternative would be to introduce a allyesmodconfig_n property to config entries, like the allnoconfig_y one we have today: - allnoconfig_y This declares the symbol as one that should have the value y when using allnoconfig. Used for symbols that hide other symbols. Of course, allyesmodconfig_n would set the value to n when using allmodconfig or allmodconfig. That alternative needs a bit more work though and may not be desirable, given that even allnoconfig_y is used only once today. Reported-by: Andrew Morton a...@linux-foundation.org Suggested-by: Andrew Morton a...@linux-foundation.org Cc: Andrew Morton a...@linux-foundation.org Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Damien Lespiau damien.lesp...@intel.com As a proxy, it seems reasonable. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Do you also have a patch for the broken code? :) One of the things I looked at was the compiler being silly. We shr a 32bit constant by 32 bits, the compiler warning is genuine. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make DRM_I915_WERROR depend on !COMPILE_TEST
On Mon, 25 May 2015, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, May 25, 2015 at 12:26:38PM +0300, Jani Nikula wrote: On Mon, 25 May 2015, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, May 24, 2015 at 10:48:07AM +0100, Damien Lespiau wrote: With allyesconfig/allmodconfig, kbuild enables all the options it can, including DRM_I915_WERROR. That's not really what we want with -Werror, and this was breaking the build for Andrew. Andrew suggested to use COMPILE_TEST as a way to 'detect' these configurations. An alternative would be to inverse the condition of the option: DRM_I915_NO_WERROR. Setting that one to Y would have no effect, at the price of a bit of confusion. Another alternative would be to introduce a allyesmodconfig_n property to config entries, like the allnoconfig_y one we have today: - allnoconfig_y This declares the symbol as one that should have the value y when using allnoconfig. Used for symbols that hide other symbols. Of course, allyesmodconfig_n would set the value to n when using allmodconfig or allmodconfig. That alternative needs a bit more work though and may not be desirable, given that even allnoconfig_y is used only once today. Reported-by: Andrew Morton a...@linux-foundation.org Suggested-by: Andrew Morton a...@linux-foundation.org Cc: Andrew Morton a...@linux-foundation.org Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Damien Lespiau damien.lesp...@intel.com As a proxy, it seems reasonable. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Do you also have a patch for the broken code? :) One of the things I looked at was the compiler being silly. We shr a 32bit constant by 32 bits, the compiler warning is genuine. I meant gcc-4.4.4: cc1: warnings being treated as errors drivers/gpu/drm/i915/intel_tv.c: In function 'intel_tv_detect': drivers/gpu/drm/i915/intel_tv.c:1319: error: 'type' may be used uninitialized in this function Jani. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep color HDMI sinks
On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
GCP infoframes are required to inform the HDMI sink about the color
depth.
Send the GCP infoframe whenever the sink supports any deep color modes
since such sinks must anyway be capable of receiving them. For sinks
that don't support deep color let's skip the GCP in case it might
confuse the sink, although HDMI 1.4 spec does say all sinks must be
capable of reciving them. In theory we could skip the GCP infoframe
for deep color sinks in 8bpc mode as well since sinks must fall back to
8bpc whenever GCP isn't received for some time.
BSpec says we should disable GCP after disabling the port, so do that as
well.
v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
Rebased due to crtc-config changes
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_hdmi.c | 74
+++
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e619e41..dcd93b5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6010,6 +6010,9 @@ enum skl_disp_power_wells {
#define _VIDEO_DIP_CTL_A 0xe0200
#define _VIDEO_DIP_DATA_A0xe0208
#define _VIDEO_DIP_GCP_A 0xe0210
+#define GCP_COLOR_INDICATION(1 2)
+#define GCP_DEFAULT_PHASE_ENABLE(1 1)
+#define GCP_AV_MUTE (1 0)
#define _VIDEO_DIP_CTL_B 0xe1200
#define _VIDEO_DIP_DATA_B0xe1208
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 79cf445..87c4905 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -541,6 +541,66 @@ static void g4x_set_infoframes(struct drm_encoder
*encoder,
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
+static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder-dev;
+ struct drm_connector *connector;
+
+ WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
+
+ /*
+ * HDMI cloning is only supported on g4x which doesn't
+ * support deep color or GCP infoframes anyway so no
+ * need to worry about multiple HDMI sinks here.
+ */
+ list_for_each_entry(connector, dev-mode_config.connector_list, head)
+ if (connector-encoder == encoder)
+ return connector-display_info.bpc 8;
+
+ return false;
+}
+
+static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-dev-dev_private;
+ struct intel_crtc *crtc = to_intel_crtc(encoder-crtc);
+ u32 reg, val = 0;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_GCP(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_GCP(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_GCP(crtc-pipe);
+ else
+ return false;
+
+ /* Indicate color depth wheneven the sink supports deep color */
+ if (hdmi_sink_is_deep_color(encoder))
+ val |= GCP_COLOR_INDICATION;
+
+ I915_WRITE(reg, val);
+
+ return val != 0;
+}
+
+static void intel_disable_gcp_infoframe(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+ u32 reg;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_CTL(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_CTL(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_CTL(crtc-pipe);
+ else
+ return;
+
+ I915_WRITE(reg, I915_READ(reg) ~VIDEO_DIP_ENABLE_GCP);
+}
+
static void ibx_set_infoframes(struct drm_encoder *encoder,
bool enable,
struct drm_display_mode *adjusted_mode)
@@ -581,6 +641,9 @@ static void ibx_set_infoframes(struct drm_encoder
*encoder,
val = ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
VIDEO_DIP_ENABLE_GCP);
+ if (intel_hdmi_set_gcp_infoframe(encoder))
+ val |= VIDEO_DIP_ENABLE_GCP;
+
I915_WRITE(reg, val);
POSTING_READ(reg);
@@ -618,6 +681,9 @@ static void cpt_set_infoframes(struct drm_encoder
*encoder,
val = ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
VIDEO_DIP_ENABLE_GCP);
+ if (intel_hdmi_set_gcp_infoframe(encoder))
+ val |= VIDEO_DIP_ENABLE_GCP;
+
I915_WRITE(reg, val);
POSTING_READ(reg);
@@ -666,6 +732,9 @@ static void vlv_set_infoframes(struct drm_encoder
*encoder,
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep color HDMI sinks
On Mon, May 25, 2015 at 03:32:52PM +0300, Ander Conselvan De Oliveira wrote:
On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
GCP infoframes are required to inform the HDMI sink about the color
depth.
Send the GCP infoframe whenever the sink supports any deep color modes
since such sinks must anyway be capable of receiving them. For sinks
that don't support deep color let's skip the GCP in case it might
confuse the sink, although HDMI 1.4 spec does say all sinks must be
capable of reciving them. In theory we could skip the GCP infoframe
for deep color sinks in 8bpc mode as well since sinks must fall back to
8bpc whenever GCP isn't received for some time.
BSpec says we should disable GCP after disabling the port, so do that as
well.
v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
Rebased due to crtc-config changes
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_hdmi.c | 74
+++
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index e619e41..dcd93b5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6010,6 +6010,9 @@ enum skl_disp_power_wells {
#define _VIDEO_DIP_CTL_A 0xe0200
#define _VIDEO_DIP_DATA_A0xe0208
#define _VIDEO_DIP_GCP_A 0xe0210
+#define GCP_COLOR_INDICATION (1 2)
+#define GCP_DEFAULT_PHASE_ENABLE (1 1)
+#define GCP_AV_MUTE (1 0)
#define _VIDEO_DIP_CTL_B 0xe1200
#define _VIDEO_DIP_DATA_B0xe1208
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 79cf445..87c4905 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -541,6 +541,66 @@ static void g4x_set_infoframes(struct drm_encoder
*encoder,
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
+static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder-dev;
+ struct drm_connector *connector;
+
+ WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
+
+ /*
+* HDMI cloning is only supported on g4x which doesn't
+* support deep color or GCP infoframes anyway so no
+* need to worry about multiple HDMI sinks here.
+*/
+ list_for_each_entry(connector, dev-mode_config.connector_list, head)
+ if (connector-encoder == encoder)
+ return connector-display_info.bpc 8;
+
+ return false;
+}
+
+static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-dev-dev_private;
+ struct intel_crtc *crtc = to_intel_crtc(encoder-crtc);
+ u32 reg, val = 0;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_GCP(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_GCP(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_GCP(crtc-pipe);
+ else
+ return false;
+
+ /* Indicate color depth wheneven the sink supports deep color */
+ if (hdmi_sink_is_deep_color(encoder))
+ val |= GCP_COLOR_INDICATION;
+
+ I915_WRITE(reg, val);
+
+ return val != 0;
+}
+
+static void intel_disable_gcp_infoframe(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+ u32 reg;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_CTL(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_CTL(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_CTL(crtc-pipe);
+ else
+ return;
+
+ I915_WRITE(reg, I915_READ(reg) ~VIDEO_DIP_ENABLE_GCP);
+}
+
static void ibx_set_infoframes(struct drm_encoder *encoder,
bool enable,
struct drm_display_mode *adjusted_mode)
@@ -581,6 +641,9 @@ static void ibx_set_infoframes(struct drm_encoder
*encoder,
val = ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
VIDEO_DIP_ENABLE_GCP);
+ if (intel_hdmi_set_gcp_infoframe(encoder))
+ val |= VIDEO_DIP_ENABLE_GCP;
+
I915_WRITE(reg, val);
POSTING_READ(reg);
@@ -618,6 +681,9 @@ static void cpt_set_infoframes(struct drm_encoder
*encoder,
val = ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
VIDEO_DIP_ENABLE_GCP);
+ if (intel_hdmi_set_gcp_infoframe(encoder))
+ val |= VIDEO_DIP_ENABLE_GCP;
+
I915_WRITE(reg, val);
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep color HDMI sinks
On Mon, 2015-05-25 at 15:44 +0300, Ville Syrjälä wrote:
On Mon, May 25, 2015 at 03:32:52PM +0300, Ander Conselvan De Oliveira wrote:
On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
GCP infoframes are required to inform the HDMI sink about the color
depth.
Send the GCP infoframe whenever the sink supports any deep color modes
since such sinks must anyway be capable of receiving them. For sinks
that don't support deep color let's skip the GCP in case it might
confuse the sink, although HDMI 1.4 spec does say all sinks must be
capable of reciving them. In theory we could skip the GCP infoframe
for deep color sinks in 8bpc mode as well since sinks must fall back to
8bpc whenever GCP isn't received for some time.
BSpec says we should disable GCP after disabling the port, so do that as
well.
v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
Rebased due to crtc-config changes
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_hdmi.c | 74
+++
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index e619e41..dcd93b5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6010,6 +6010,9 @@ enum skl_disp_power_wells {
#define _VIDEO_DIP_CTL_A 0xe0200
#define _VIDEO_DIP_DATA_A0xe0208
#define _VIDEO_DIP_GCP_A 0xe0210
+#define GCP_COLOR_INDICATION(1 2)
+#define GCP_DEFAULT_PHASE_ENABLE(1 1)
+#define GCP_AV_MUTE (1 0)
#define _VIDEO_DIP_CTL_B 0xe1200
#define _VIDEO_DIP_DATA_B0xe1208
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 79cf445..87c4905 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -541,6 +541,66 @@ static void g4x_set_infoframes(struct drm_encoder
*encoder,
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
+static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder-dev;
+ struct drm_connector *connector;
+
+ WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
+
+ /*
+ * HDMI cloning is only supported on g4x which doesn't
+ * support deep color or GCP infoframes anyway so no
+ * need to worry about multiple HDMI sinks here.
+ */
+ list_for_each_entry(connector, dev-mode_config.connector_list, head)
+ if (connector-encoder == encoder)
+ return connector-display_info.bpc 8;
+
+ return false;
+}
+
+static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-dev-dev_private;
+ struct intel_crtc *crtc = to_intel_crtc(encoder-crtc);
+ u32 reg, val = 0;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_GCP(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_GCP(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_GCP(crtc-pipe);
+ else
+ return false;
+
+ /* Indicate color depth wheneven the sink supports deep color */
+ if (hdmi_sink_is_deep_color(encoder))
+ val |= GCP_COLOR_INDICATION;
+
+ I915_WRITE(reg, val);
+
+ return val != 0;
+}
+
+static void intel_disable_gcp_infoframe(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+ u32 reg;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_CTL(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_CTL(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_CTL(crtc-pipe);
+ else
+ return;
+
+ I915_WRITE(reg, I915_READ(reg) ~VIDEO_DIP_ENABLE_GCP);
+}
+
static void ibx_set_infoframes(struct drm_encoder *encoder,
bool enable,
struct drm_display_mode *adjusted_mode)
@@ -581,6 +641,9 @@ static void ibx_set_infoframes(struct drm_encoder
*encoder,
val = ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
VIDEO_DIP_ENABLE_GCP);
+ if (intel_hdmi_set_gcp_infoframe(encoder))
+ val |= VIDEO_DIP_ENABLE_GCP;
+
I915_WRITE(reg, val);
POSTING_READ(reg);
@@ -618,6 +681,9 @@ static void cpt_set_infoframes(struct drm_encoder
*encoder,
val = ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
VIDEO_DIP_ENABLE_GCP);
+ if
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep color HDMI sinks
On Mon, May 25, 2015 at 04:09:57PM +0300, Ander Conselvan De Oliveira wrote:
On Mon, 2015-05-25 at 15:44 +0300, Ville Syrjälä wrote:
On Mon, May 25, 2015 at 03:32:52PM +0300, Ander Conselvan De Oliveira wrote:
On Tue, 2015-05-05 at 17:06 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
GCP infoframes are required to inform the HDMI sink about the color
depth.
Send the GCP infoframe whenever the sink supports any deep color modes
since such sinks must anyway be capable of receiving them. For sinks
that don't support deep color let's skip the GCP in case it might
confuse the sink, although HDMI 1.4 spec does say all sinks must be
capable of reciving them. In theory we could skip the GCP infoframe
for deep color sinks in 8bpc mode as well since sinks must fall back to
8bpc whenever GCP isn't received for some time.
BSpec says we should disable GCP after disabling the port, so do that as
well.
v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
Rebased due to crtc-config changes
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_hdmi.c | 74
+++
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index e619e41..dcd93b5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6010,6 +6010,9 @@ enum skl_disp_power_wells {
#define _VIDEO_DIP_CTL_A 0xe0200
#define _VIDEO_DIP_DATA_A0xe0208
#define _VIDEO_DIP_GCP_A 0xe0210
+#define GCP_COLOR_INDICATION (1 2)
+#define GCP_DEFAULT_PHASE_ENABLE (1 1)
+#define GCP_AV_MUTE (1 0)
#define _VIDEO_DIP_CTL_B 0xe1200
#define _VIDEO_DIP_DATA_B0xe1208
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 79cf445..87c4905 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -541,6 +541,66 @@ static void g4x_set_infoframes(struct drm_encoder
*encoder,
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
+static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder-dev;
+ struct drm_connector *connector;
+
+
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
+
+ /*
+* HDMI cloning is only supported on g4x which doesn't
+* support deep color or GCP infoframes anyway so no
+* need to worry about multiple HDMI sinks here.
+*/
+ list_for_each_entry(connector,
dev-mode_config.connector_list, head)
+ if (connector-encoder == encoder)
+ return connector-display_info.bpc 8;
+
+ return false;
+}
+
+static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-dev-dev_private;
+ struct intel_crtc *crtc = to_intel_crtc(encoder-crtc);
+ u32 reg, val = 0;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_GCP(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_GCP(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_GCP(crtc-pipe);
+ else
+ return false;
+
+ /* Indicate color depth wheneven the sink supports deep color */
+ if (hdmi_sink_is_deep_color(encoder))
+ val |= GCP_COLOR_INDICATION;
+
+ I915_WRITE(reg, val);
+
+ return val != 0;
+}
+
+static void intel_disable_gcp_infoframe(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+ u32 reg;
+
+ if (HAS_DDI(dev_priv))
+ reg = HSW_TVIDEO_DIP_CTL(crtc-config-cpu_transcoder);
+ else if (IS_VALLEYVIEW(dev_priv))
+ reg = VLV_TVIDEO_DIP_CTL(crtc-pipe);
+ else if (HAS_PCH_SPLIT(dev_priv-dev))
+ reg = TVIDEO_DIP_CTL(crtc-pipe);
+ else
+ return;
+
+ I915_WRITE(reg, I915_READ(reg) ~VIDEO_DIP_ENABLE_GCP);
+}
+
static void ibx_set_infoframes(struct drm_encoder *encoder,
bool enable,
struct drm_display_mode *adjusted_mode)
@@ -581,6 +641,9 @@ static void ibx_set_infoframes(struct drm_encoder
*encoder,
val =
Re: [Intel-gfx] [PATCH 07/12] drm/i915/bxt: Program Tx Rx and Dphy clocks
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
BXT DSI clocks are different than previous platforms. So adding a
new function to program following clocks and dividers:
1. Program variable divider to generate input to Tx clock divider
(Output value must be 39.5Mhz)
2. Select divide by 2 option to get 20Mhz for Tx clock
3. Program 8by3 divider to generate Rx clock
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 51
++
drivers/gpu/drm/i915/intel_dsi.c |3 ++
drivers/gpu/drm/i915/intel_dsi.h |1 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 35 +++
4 files changed, 90 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5eeb2b7..f96f049 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7387,6 +7387,57 @@ enum skl_disp_power_wells {
#define GEN9_FUSE_PG1_ENABLED (1 26)
#define GEN9_FUSE_PG0_ENABLED (1 27)
+/* BXT MIPI clock controls */
+#define BXT_MAX_VAR_OUTPUT_KHZ 39500
+#define BXT_MIPI_CLOCK_CTL 0x46090
+#define BXT_MIPI_DIV_SHIFT 16
Same comments here, above and below, as in previous patches about
conventions for defining registers.
+
+/* Var clock divider to generate TX source. Result must be 39.5 M */
+#define BXT_MIPI1_ESCLK_VAR_DIV_MASK(0x3F 26)
+/* BXT MIPI clock controls */
+#define BXT_MAX_VAR_OUTPUT_KHZ 39500
+#define BXT_MIPI_CLOCK_CTL 0x46090
+#define BXT_MIPI_DIV_SHIFT 16
+
+/* Var clock divider to generate TX source. Result must be 39.5 M */
+#define BXT_MIPI1_ESCLK_VAR_DIV_MASK(0x3F 26)
+#define BXT_MIPI2_ESCLK_VAR_DIV_MASK(0x3F 10)
+#define BXT_MIPI_ESCLK_VAR_DIV_MASK(check)\
+ (0x3F ((!check) * BXT_MIPI_DIV_SHIFT + 10))
check?
Ugh, I hate the confusion between pipe and port for DSI. Yes, I'm
confused too.
Whichever it is, I'd prefer not using !check, because it conflates pipe
B and port C, adding to the confusion.
+#define BXT_MIPI_ESCLK_VAR_DIV(check, val)\
+ (val ((!check) * BXT_MIPI_DIV_SHIFT + 10))
+
+/* TX control divider to select actual TX clock output from (8x/var) */
+#define BXT_MIPI1_TX_ESCLK_FIXDIV_MASK(3 21)
+#define BXT_MIPI2_TX_ESCLK_FIXDIV_MASK(3 5)
+#define BXT_MIPI_TX_ESCLK_FIXDIV_MASK(check) \
+ (3 ((!check) * BXT_MIPI_DIV_SHIFT + 5))
+
+#define BXT_MIPI_TX_ESCLK_8XDIV_BY2(check)\
+ (0x0 ((!check) * BXT_MIPI_DIV_SHIFT + 5))
+#define BXT_MIPI_TX_ESCLK_8XDIV_BY4(check)\
+ (0x1 ((!check) * BXT_MIPI_DIV_SHIFT + 5))
+#define BXT_MIPI_TX_ESCLK_8XDIV_BY8(check)\
+ (0x2 ((!check) * BXT_MIPI_DIV_SHIFT + 5))
+
+/* RX control divider to select actual RX clock output from 8x*/
+#define BXT_MIPI1_RX_ESCLK_FIXDIV_MASK(3 19)
+#define BXT_MIPI2_RX_ESCLK_FIXDIV_MASK(3 3)
+#define BXT_MIPI_RX_ESCLK_FIXDIV_MASK(check) \
+ (3 ((!check) * BXT_MIPI_DIV_SHIFT + 3))
+#define BXT_MIPI_RX_ESCLK_8X_BY2(check) \
+ (1 ((!check) * BXT_MIPI_DIV_SHIFT + 3))
+#define BXT_MIPI_RX_ESCLK_8X_BY3(check) \
+ (2 ((!check) * BXT_MIPI_DIV_SHIFT + 3))
+#define BXT_MIPI_RX_ESCLK_8X_BY4(check) \
+ (3 ((!check) * BXT_MIPI_DIV_SHIFT + 3))
+
+/* BXT: Always prog DPHY dividers to 00 */
+#define BXT_MIPI_1_DPHY_DIVIDER_MASK (3 16)
+#define BXT_MIPI_2_DPHY_DIVIDER_MASK (3 0)
+#define BXT_MIPI_DPHY_DIVIDER_MASK(check) \
+ (3 ((!check) * BXT_MIPI_DIV_SHIFT))
+
/* BXT MIPI mode configure */
#define _BXT_MIPIA_TRANS_HACTIVE 0x6B0F8
#define _BXT_MIPIC_TRANS_HACTIVE 0x6B8F8
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 3a1bb04..729faf6 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -503,6 +503,9 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
tmp = I915_READ(DSPCLK_GATE_D);
tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
I915_WRITE(DSPCLK_GATE_D, tmp);
+ } else if (IS_BROXTON(dev)) {
+ /* Program Tx Rx and Dphy clocks */
+ bxt_dsi_program_clocks(dev, intel_dsi-ports);
intel_dsi-ports is a bit mask of ports, e.g. (1 PORT_A) | (1
PORT_B). I don't think this is what you mean or want to use here.
}
/* put device in ready state */
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index
Re: [Intel-gfx] [RFC 14/15] drm/i915: Program atomic watermarks via vblank job
Why don’t we do this wm update as part of the fb unpin what is the need for wq
here. May add some latency
Please clarify
Thanks,
Pallavi
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Matt Roper
Sent: Thursday, May 21, 2015 7:42 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [RFC 14/15] drm/i915: Program atomic watermarks via vblank
job
Use the new vblank job infrastructure to schedule watermark programming to
happen when the next vblank occurs.
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/intel_display.c | 38 +++-
drivers/gpu/drm/i915/intel_pm.c | 1 +
3 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d577eba..5134101 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -569,6 +569,7 @@ struct drm_i915_display_funcs {
struct drm_crtc *crtc,
uint32_t sprite_width, uint32_t sprite_height,
int pixel_size, bool enable, bool scaled);
+ void (*program_watermarks)(struct drm_i915_private *dev_priv);
void (*modeset_global_resources)(struct drm_atomic_state *state);
/* Returns the active state of the crtc, and if the crtc is active,
* fills out the pipe-config with the hw state. */ @@ -2494,6 +2495,12
@@ struct drm_i915_cmd_table { #define HAS_L3_DPF(dev) (IS_IVYBRIDGE(dev) ||
IS_HASWELL(dev)) #define NUM_L3_SLICES(dev) (IS_HSW_GT3(dev) ? 2 :
HAS_L3_DPF(dev))
+/*
+ * FIXME: Only some platforms have been transitioned to atomic
+watermark
+ * updates so far.
+ */
+#define HAS_ATOMIC_WM(dev_priv) (dev_priv-display.program_watermarks
+!= NULL)
+
#define GT_FREQUENCY_MULTIPLIER 50
#define GEN9_FREQ_SCALER 3
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9b56d07..b2012c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13209,6 +13209,24 @@ intel_disable_primary_plane(struct drm_plane *plane,
dev_priv-display.update_primary_plane(crtc, NULL, 0, 0); }
+static void
+do_update_watermarks(struct intel_crtc *intel_crtc,
+void *data,
+bool early,
+u32 seq)
+{
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc-base.dev);
+
+ /*
+* If we fired early because the CRTC is turning off, there's no
+* need to actually program watermarks.
+*/
+ if (early)
+ return;
+
+ dev_priv-display.program_watermarks(dev_priv);
+}
+
static void intel_begin_crtc_commit(struct drm_crtc *crtc) {
struct drm_device *dev = crtc-dev;
@@ -13251,7 +13269,7 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc)
if (intel_crtc-atomic.pre_disable_primary)
intel_pre_disable_primary(crtc);
- if (intel_crtc-atomic.update_wm)
+ if (!HAS_ATOMIC_WM(dev_priv) intel_crtc-atomic.update_wm)
intel_update_watermarks(crtc);
intel_runtime_pm_get(dev_priv);
@@ -13270,6 +13288,15 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_plane *p;
+ /*
+* If this platform supports atomic watermarks, schedule a job to
+* update watermarks when the next vblank occurs. Otherwise, just
+* update watermarks the old-fashioned way.
+*/
+ if (HAS_ATOMIC_WM(dev_priv))
+ intel_schedule_vblank_job(intel_crtc, do_update_watermarks,
+ NULL, dev_priv-wq, 1);
+
if (intel_crtc-atomic.evade)
intel_pipe_update_end(intel_crtc,
intel_crtc-atomic.start_vbl_count);
@@ -13290,10 +13317,11 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc)
if (intel_crtc-atomic.post_enable_primary)
intel_post_enable_primary(crtc);
- drm_for_each_legacy_plane(p, dev-mode_config.plane_list)
- if (intel_crtc-atomic.update_sprite_watermarks
- (1 drm_plane_index(p)))
- intel_update_sprite_watermarks(p, crtc);
+ if (!HAS_ATOMIC_WM(dev_priv))
+ drm_for_each_legacy_plane(p, dev-mode_config.plane_list)
+ if (intel_crtc-atomic.update_sprite_watermarks
+ (1 drm_plane_index(p)))
+ intel_update_sprite_watermarks(p, crtc);
memset(intel_crtc-atomic, 0, sizeof(intel_crtc-atomic)); } diff
--git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index
27337fe..7f0a0c1 100644
---
Re: [Intel-gfx] [PATCH 03/12] drm/i915/bxt: Disable DSI PLL for BXT
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch adds two new functions:
- disable_dsi_pll.
BXT DSI disable sequence and registers are
different from previous platforms.
- intel_disable_dsi_pll
wrapper function to re-use the same code for
multiple platforms. It checks platform type and
calls appropriate core pll disable function.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c |2 +-
drivers/gpu/drm/i915/intel_dsi.h |2 +-
drivers/gpu/drm/i915/intel_dsi_pll.c | 31 ++-
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 1927546..2c0ea6f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -553,7 +553,7 @@ static void intel_dsi_clear_device_ready(struct
intel_encoder *encoder)
usleep_range(2000, 2500);
}
- vlv_disable_dsi_pll(encoder);
+ intel_disable_dsi_pll(encoder);
}
static void intel_dsi_post_disable(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index 20cfcf07..759983e 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -122,7 +122,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
}
extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
-extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
+extern void intel_disable_dsi_pll(struct intel_encoder *encoder);
extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id);
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index a58f0a1..0cbcf32 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -267,7 +267,7 @@ static void vlv_enable_dsi_pll(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(DSI PLL locked\n);
}
-void vlv_disable_dsi_pll(struct intel_encoder *encoder)
+static void vlv_disable_dsi_pll(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
u32 tmp;
@@ -440,6 +440,23 @@ static void bxt_enable_dsi_pll(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(DSI PLL locked\n);
}
+static void bxt_disable_dsi_pll(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
+
+ DRM_DEBUG_KMS(\n);
+
+ /* Disable DSI PLL */
That is obvious from the code.
+ I915_WRITE(BXT_DSI_PLL_ENABLE, 0);
+
+ /* Should timeout and fail if not locked after 200 us */
+ if (wait_for((I915_READ(BXT_DSI_PLL_ENABLE)
+ BXT_DSI_PLL_LOCKED) == 0, 1)) {
+ DRM_ERROR(Disable: DSI PLL not locked\n);
not unlocked?
+ return;
Unnecessary return statement.
+ }
+}
+
void intel_enable_dsi_pll(struct intel_encoder *encoder)
{
struct drm_device *dev = encoder-base.dev;
@@ -451,3 +468,15 @@ void intel_enable_dsi_pll(struct intel_encoder *encoder)
else
DRM_ERROR(Invalid DSI device to pre_pll_enable\n);
}
+
+void intel_disable_dsi_pll(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+
+ if (IS_VALLEYVIEW(dev))
+ vlv_disable_dsi_pll(encoder);
+ else if (IS_BROXTON(dev))
+ bxt_disable_dsi_pll(encoder);
+ else
+ DRM_ERROR(Invalid DSI device to pre_pll_enable\n);
Please drop the else branch.
BR,
Jani.
+}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915/bxt: get DSI pixelclock
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
BXT's DSI PLL is different from that of VLV. So this patch
adds a new function to get the current DSI pixel clock based
on the PLL divider ratio and lane count.
This function is required for intel_dsi_get_config() function.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 10 --
drivers/gpu/drm/i915/intel_dsi.h |1 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 35
++
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 2663cdd..5fbcebe 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -714,7 +714,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
static void intel_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
- u32 pclk;
+ u32 pclk = 0;
Unnecessary initialization.
DRM_DEBUG_KMS(\n);
/*
@@ -723,7 +723,13 @@ static void intel_dsi_get_config(struct intel_encoder
*encoder,
*/
pipe_config-dpll_hw_state.dpll_md = 0;
- pclk = vlv_get_dsi_pclk(encoder, pipe_config-pipe_bpp);
+ if (IS_BROXTON(encoder-base.dev))
+ pclk = bxt_get_dsi_pclk(encoder, pipe_config-pipe_bpp);
+ else if (IS_VALLEYVIEW(encoder-base.dev))
+ pclk = vlv_get_dsi_pclk(encoder, pipe_config-pipe_bpp);
+ else
+ DRM_ERROR(Invalid DSI device to get config\n);
Please drop the else branch.
+
if (!pclk)
return;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index 8bc8d94..01e08e7 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -124,6 +124,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
extern void intel_disable_dsi_pll(struct intel_encoder *encoder);
extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
+extern u32 bxt_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
extern void bxt_dsi_program_clocks(struct drm_device *dev, int pipe);
extern void intel_dsi_reset_clocks(struct intel_encoder *encoder,
enum port port);
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 49330b0..073bd1f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -369,6 +369,41 @@ u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int
pipe_bpp)
return pclk;
}
+u32 bxt_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp)
+{
+ u32 pclk;
+ u32 dsi_clk;
+ u32 dsi_ratio;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
+
+ /* Divide by zero */
+ if (!pipe_bpp) {
+ DRM_ERROR(Invalid BPP(0)\n);
+ return 0;
+ }
+
+ dsi_ratio = I915_READ(BXT_DSI_PLL_CTL)
+ BXT_DSI_MASK_PLL_RATIO;
+
+ /* Invalid DSI ratio ? */
+ if (dsi_ratio BXT_DSI_PLL_RATIO_MIN ||
+ dsi_ratio BXT_DSI_PLL_RATIO_MAX) {
+ DRM_ERROR(Invalid DSI pll ratio(%u) programmed\n, dsi_ratio);
+ return 0;
+ }
+
+ dsi_clk = (dsi_ratio * BXT_REF_CLOCK_KHZ) / 2;
+
+ /* pixel_format and pipe_bpp should agree */
+ assert_bpp_mismatch(intel_dsi-pixel_format, pipe_bpp);
+
+ pclk = DIV_ROUND_CLOSEST(dsi_clk * intel_dsi-lane_count, pipe_bpp);
+
+ DRM_DEBUG_DRIVER(Calculated pclk=%u\n, pclk);
+ return pclk;
+}
+
void vlv_dsi_reset_clocks(struct intel_encoder *encoder, enum port port)
{
u32 temp;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915/bxt: DSI prepare changes for BXT
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch modifies dsi_prepare() function to support the same
modeset prepare sequence for BXT also. Main changes are:
1. BXT port control register is different than VLV.
2. BXT modeset sequence needs vdisplay and hdisplay programmed
for transcoder.
3. BXT can select PIPE for MIPI transcoders.
4. BXT needs to program register MIPI_INIT_COUNT for both the ports,
even if only one is being used.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 22 +++
drivers/gpu/drm/i915/intel_dsi.c | 79
+-
2 files changed, 91 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b63bdce..57c3a48 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7387,6 +7387,22 @@ enum skl_disp_power_wells {
#define GEN9_FUSE_PG1_ENABLED (1 26)
#define GEN9_FUSE_PG0_ENABLED (1 27)
+/* BXT MIPI mode configure */
+#define _BXT_MIPIA_TRANS_HACTIVE 0x6B0F8
+#define _BXT_MIPIC_TRANS_HACTIVE 0x6B8F8
+#define BXT_MIPI_TRANS_HACTIVE(tc) _TRANSCODER(tc, \
+ _BXT_MIPIA_TRANS_HACTIVE, _BXT_MIPIC_TRANS_HACTIVE)
+
+#define _BXT_MIPIA_TRANS_VACTIVE 0x6B0FC
+#define _BXT_MIPIC_TRANS_VACTIVE 0x6B8FC
+#define BXT_MIPI_TRANS_VACTIVE(tc) _TRANSCODER(tc, \
+ _BXT_MIPIA_TRANS_VACTIVE, _BXT_MIPIC_TRANS_VACTIVE)
+
+#define _BXT_MIPIA_TRANS_VTOTAL 0x6B100
+#define _BXT_MIPIC_TRANS_VTOTAL 0x6B900
+#define BXT_MIPI_TRANS_VTOTAL(tc) _TRANSCODER(tc, \
+ _BXT_MIPIA_TRANS_VTOTAL, _BXT_MIPIC_TRANS_VTOTAL)
Shouldn't these use _MIPI_PORT, not _TRANSCODER?
+
#define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and
C only */
#define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190)
@@ -7802,6 +7818,12 @@ enum skl_disp_power_wells {
#define READ_REQUEST_PRIORITY_HIGH (3 3)
#define RGB_FLIP_TO_BGR (1 2)
+/* BXT has a pipe select field */
It's obvious from the defines. Please put the defines in decreasing bit
shift order, i.e. these will be the first ones.
+#define BXT_PIPE_SELECT_A (0 7)
+#define BXT_PIPE_SELECT_B (1 7)
+#define BXT_PIPE_SELECT_C (2 7)
+#define BXT_PIPE_SELECT_MASK(7 7)
Two spaces after #define. _MASK goes first.
+
#define _MIPIA_DATA_ADDRESS (dev_priv-mipi_mmio_base + 0xb108)
#define _MIPIC_DATA_ADDRESS (dev_priv-mipi_mmio_base + 0xb908)
#define MIPI_DATA_ADDRESS(port) _MIPI_PORT(port,
_MIPIA_DATA_ADDRESS, \
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 2c0ea6f..892b518 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -726,6 +726,21 @@ static void set_dsi_timings(struct drm_encoder *encoder,
hbp = txbyteclkhs(hbp, bpp, lane_count, intel_dsi-burst_mode_ratio);
for_each_dsi_port(port, intel_dsi-ports) {
+ if (IS_BROXTON(dev)) {
+ /*
+ * Program hdisplay and vdisplay on MIPI transcoder.
+ * This is different from calculated hactive and
+ * vactive, as they are calculated per channel basis,
+ * whereas these values should be based on resolution.
+ */
+ I915_WRITE(BXT_MIPI_TRANS_HACTIVE(port),
+ mode-hdisplay);
+ I915_WRITE(BXT_MIPI_TRANS_VACTIVE(port),
+ mode-vdisplay);
+ I915_WRITE(BXT_MIPI_TRANS_VTOTAL(port),
+ mode-vtotal);
With the current definition of BXT_MIPI_TRANS_* these will fail for port
C.
+ }
+
I915_WRITE(MIPI_HACTIVE_AREA_COUNT(port), hactive);
I915_WRITE(MIPI_HFP_COUNT(port), hfp);
@@ -766,16 +781,38 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
}
for_each_dsi_port(port, intel_dsi-ports) {
- /* escape clock divider, 20MHz, shared for A and C.
- * device ready must be off when doing this! txclkesc? */
- tmp = I915_READ(MIPI_CTRL(PORT_A));
- tmp = ~ESCAPE_CLOCK_DIVIDER_MASK;
- I915_WRITE(MIPI_CTRL(PORT_A), tmp | ESCAPE_CLOCK_DIVIDER_1);
-
- /* read request priority
Re: [Intel-gfx] [PATCH 08/12] drm/i915/bxt: DSI disable and post-disable
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch contains changes to support DSI disble sequence in BXT.
The changes are:
1. BXT specific changes in clear_device_ready function.
2. BXT specific changes in DSI disable and post-disable functions.
3. Add a new function to reset BXT Dphy clock and dividers
(bxt_dsi_reset_clocks).
4. Moved some part of the vlv clock reset code, in a new function
(vlv_dsi_reset_clocks) maintaining the exact same sequence.
5. Wrapper function to call corresponding reset clock function.
Signed-off-by: Uma Shankar uma.shan...@intel.com
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 39
drivers/gpu/drm/i915/intel_dsi.h |2 ++
drivers/gpu/drm/i915/intel_dsi_pll.c | 41
++
3 files changed, 68 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 729faf6..e4b96bc 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -427,12 +427,16 @@ static void intel_dsi_port_disable(struct intel_encoder
*encoder)
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
enum port port;
u32 temp;
+ u32 port_ctrl;
for_each_dsi_port(port, intel_dsi-ports) {
/* de-assert ip_tg_enable signal */
- temp = I915_READ(MIPI_PORT_CTRL(port));
- I915_WRITE(MIPI_PORT_CTRL(port), temp ~DPI_ENABLE);
- POSTING_READ(MIPI_PORT_CTRL(port));
+ port_ctrl = IS_BROXTON(dev) ?
+ BXT_MIPI_PORT_CTRL(port) :
+ MIPI_PORT_CTRL(port);
+ temp = I915_READ(port_ctrl);
+ I915_WRITE(port_ctrl, temp ~DPI_ENABLE);
+ POSTING_READ(port_ctrl);
}
}
@@ -570,12 +574,7 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
/* Panel commands can be sent when clock is in LP11 */
I915_WRITE(MIPI_DEVICE_READY(port), 0x0);
- temp = I915_READ(MIPI_CTRL(port));
- temp = ~ESCAPE_CLOCK_DIVIDER_MASK;
- I915_WRITE(MIPI_CTRL(port), temp |
-intel_dsi-escape_clk_div
-ESCAPE_CLOCK_DIVIDER_SHIFT);
-
+ intel_dsi_reset_clocks(encoder, port);
I915_WRITE(MIPI_EOT_DISABLE(port), CLOCKSTOP);
temp = I915_READ(MIPI_DSI_FUNC_PRG(port));
@@ -594,12 +593,15 @@ static void intel_dsi_disable(struct intel_encoder
*encoder)
static void intel_dsi_clear_device_ready(struct intel_encoder *encoder)
{
+ struct drm_device *dev = encoder-base.dev;
You don't need dev. IS_BROXTON and IS_VALLEYVIEW eat both dev and
dev_priv.
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
enum port port;
u32 val;
+ u32 port_ctrl;
DRM_DEBUG_KMS(\n);
+
Unrelated whitespace change.
for_each_dsi_port(port, intel_dsi-ports) {
I915_WRITE(MIPI_DEVICE_READY(port), DEVICE_READY |
@@ -614,18 +616,27 @@ static void intel_dsi_clear_device_ready(struct
intel_encoder *encoder)
ULPS_STATE_ENTER);
usleep_range(2000, 2500);
+ if (IS_BROXTON(dev))
+ port_ctrl = BXT_MIPI_PORT_CTRL(port);
+ else if (IS_VALLEYVIEW(dev))
+ port_ctrl = MIPI_PORT_CTRL(PORT_A);
+ else {
+ DRM_ERROR(Invalid DSI device to clear device ready\n);
+ return;
Please drop all such else branches.
+ }
+
/* Wait till Clock lanes are in LP-00 state for MIPI Port A
* only. MIPI Port C has no similar bit for checking
*/
- if (wait_for(((I915_READ(MIPI_PORT_CTRL(PORT_A)) AFE_LATCHOUT)
+ if (wait_for(((I915_READ(port_ctrl) AFE_LATCHOUT)
== 0x0), 30))
DRM_ERROR(DSI LP not going Low\n);
/* Disable MIPI PHY transparent latch
* Common bit for both MIPI Port A MIPI Port C
*/
- val = I915_READ(MIPI_PORT_CTRL(PORT_A));
- I915_WRITE(MIPI_PORT_CTRL(PORT_A), val ~LP_OUTPUT_HOLD);
+ val = I915_READ(port_ctrl);
+ I915_WRITE(port_ctrl, val ~LP_OUTPUT_HOLD);
usleep_range(1000, 1500);
I915_WRITE(MIPI_DEVICE_READY(port), 0x00);
@@ -637,14 +648,14 @@ static void intel_dsi_clear_device_ready(struct
intel_encoder *encoder)
static void intel_dsi_post_disable(struct
[Intel-gfx] [PATCH] drm/i915: Force wmb() on using GTT io_mapping_map_wc
Since the advent of mmap(wc), where we reused the same cache domain for
WC and GTT paths (oh, how I regret that double-edged advice), we need to
be extra cautious when using GTT iomap_wc internally. Since userspace maybe
modifying through the mmap(wc) and we then modify modifying through an
aliased WC path through the GTT, those writes may overlap and not be
visible to the other path. Easiest to trigger appears to be write the
batch through mmap(wc) and then attempt to perform reloc the GTT,
corruption quickly ensues.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Akash Goel akash.g...@intel.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 517c5b8100d1..5f2bb1f92879 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3922,8 +3922,17 @@ i915_gem_object_set_to_gtt_domain(struct
drm_i915_gem_object *obj, bool write)
struct i915_vma *vma;
int ret;
- if (obj-base.write_domain == I915_GEM_DOMAIN_GTT)
+ if (obj-base.write_domain == I915_GEM_DOMAIN_GTT) {
+ /*
+* Userspace may be writing through mmap(wc) with
+* write_domain=GTT, so we need to explicitly flush before
+* transitioning to writing through the GTT, or vice versa.
+* As we reused the cache domain for both paths, we must
+* always have a write barrier just in case.
+*/
+ wmb();
return 0;
+ }
ret = i915_gem_object_wait_rendering(obj, !write);
if (ret)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915/bxt: Enable BXT DSI PLL
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch adds new functions for BXT clock and PLL programming.
They are:
1. configure_dsi_pll for BXT.
This function does the basic math and generates the divider ratio
based on requested pixclock, and program clock registers.
2. enable_dsi_pll function.
This function programs the calculated clock values on the PLL.
3. intel_enable_dsi_pll
Wrapper function to use same code for multiple platforms. It checks the
platform and calls appropriate core pll enable function.
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 35 ++
drivers/gpu/drm/i915/intel_dsi.c |2 +-
drivers/gpu/drm/i915/intel_dsi.h |2 +-
drivers/gpu/drm/i915/intel_dsi_pll.c | 85
+-
4 files changed, 121 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 46ef269..b63bdce 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7352,6 +7352,41 @@ enum skl_disp_power_wells {
/* MIPI DSI registers */
+/* BXT DSI PLL Control */
The macro name says this already, no need for the comment.
+#define BXT_DSI_PLL_CTL 0x161000
+#define BXT_DSI_PLL_MASK_PVD_RATIO (3 16)
The convention is to have _SHIFT and _MASK at the end of the name.
+#define BXT_DSI_PLL_PVD_RATIO_1 (116)
Spaces around . Please also add macro for _SHIFT.
+#define BXT_DSIC_16X_BY2 (1 10)
+#define BXT_DSIC_16X_BY3 (1 11)
+#define BXT_DSIC_16X_BY4 (3 10)
The convention is to shift the same amount for each alternative in a bit
field. E.g. (1 10), (2 10), (3 10).
+#define BXT_DSIA_16X_BY2 (1 8)
+#define BXT_DSIA_16X_BY3 (1 9)
+#define BXT_DSIA_16X_BY4 (3 8)
Same.
+#define BXT_DSI_MASK_FREQ_SEL(0xF 8)
_MASK at the end of the name, and the convention is to define _SHIFT
first, _MASK next, and the possible alternatives after that, i.e.
#define FOO_SHIFT 16
#define FOO_MASK (3 16)
#define FOO_A (1 16)
+#define BXT_DSI_PLL_RATIO_MAX0x7D
+#define BXT_DSI_PLL_RATIO_MIN0x22
+#define BXT_DSI_MASK_PLL_RATIO 0x7F
Same as above. The mask is 8 bits, i.e. 0xff.
The convention is to have bit names shifted by two spaces. For example,
#define REGISTER_NAME 0x5
#define SOME_BIT (1 5)
And please no empty lines between bit names, group them together.
+#define BXT_REF_CLOCK_KHZ19500
+
+#define BXT_DSI_PLL_ENABLE0x46080
+#define BXT_DSI_PLL_DO_ENABLE (1 31)
+#define BXT_DSI_PLL_LOCKED(1 30)
+
+/* BXT power well control2, for driver */
The macro name says this already, no need for the comment.
+#define BXT_PWR_WELL_CTL2 0x45404
+#define BXT_PWR_WELL_2_ENABLE (1 31)
+#define BXT_PWR_WELL_2_ENABLED(1 30)
+#define BXT_PWR_WELL_1_ENABLE (1 29)
+#define BXT_PWR_WELL_1_ENABLED(1 28)
+#define BXT_PWR_WELL_ENABLED (BXT_PWR_WELL_1_ENABLED | \
+ BXT_PWR_WELL_2_ENABLED)
+#define GEN9_FUSE_STATUS 0x42000
+#define GEN9_FUSE_PG2_ENABLED (1 25)
+#define GEN9_FUSE_PG1_ENABLED (1 26)
+#define GEN9_FUSE_PG0_ENABLED (1 27)
+
BXT_PWR_WELL_CTL2 and GEN9_FUSE_STATUS are not used in this series at
all, please remove them from this patch (and perhaps send them in a
separate patch).
#define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and
C only */
#define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 2419929e..1927546 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -903,8 +903,8 @@ static void intel_dsi_pre_pll_enable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
intel_dsi_prepare(encoder);
+ intel_enable_dsi_pll(encoder);
- vlv_enable_dsi_pll(encoder);
}
static enum drm_connector_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index 2784ac4..20cfcf07 100644
---
Re: [Intel-gfx] [PATCH 06/12] drm/i915/bxt: DSI enable for BXT
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch contains following changes:
1. MIPI device ready changes to support dsi_pre_enable. Changes
are specific to BXT device ready sequence. Added check for
ULPS mode(No effects on VLV).
2. Changes in dsi_enable to pick BXT port control register.
3. Changes in dsi_pre_enable to restrict DPIO programming for VLV
Signed-off-by: Shashank Sharma shashank.sha...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |7 ++
drivers/gpu/drm/i915/intel_dsi.c | 185
--
2 files changed, 144 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 57c3a48..5eeb2b7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7408,6 +7408,13 @@ enum skl_disp_power_wells {
#define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190)
#define _MIPIC_PORT_CTRL (VLV_DISPLAY_BASE + 0x61700)
#define MIPI_PORT_CTRL(port) _MIPI_PORT(port, _MIPIA_PORT_CTRL,
_MIPIC_PORT_CTRL)
+
+ /* BXT port control */
+#define _BXT_MIPIA_PORT_CTRL 0x6B0C0
+#define _BXT_MIPIC_PORT_CTRL 0x6B8C0
+#define BXT_MIPI_PORT_CTRL(tc) _TRANSCODER(tc, _BXT_MIPIA_PORT_CTRL,
\
+ _BXT_MIPIC_PORT_CTRL)
Shouldn't this use _MIPI_PORT, not _TRANSCODER?
+
#define DPI_ENABLE (1 31) /* A + C */
#define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27
#define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf 27)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 892b518..3a1bb04 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -286,6 +286,101 @@ static bool intel_dsi_compute_config(struct
intel_encoder *encoder,
return true;
}
+static void bxt_dsi_device_ready(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ enum port port;
+ u32 val;
+
+ DRM_DEBUG_KMS(\n);
+
+ /* Exit Low power state in 4 steps*/
+ for_each_dsi_port(port, intel_dsi-ports) {
+
+ /* 1. Enable MIPI PHY transparent latch */
+ val = I915_READ(BXT_MIPI_PORT_CTRL(port));
+ I915_WRITE(BXT_MIPI_PORT_CTRL(port), val | LP_OUTPUT_HOLD);
+ usleep_range(2000, 2500);
+
+ /* 2. Enter ULPS */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val = ~ULPS_STATE_MASK;
+ val |= (ULPS_STATE_ENTER | DEVICE_READY);
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
+ usleep_range(2, 3);
+
+ /* 3. Exit ULPS */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val = ~ULPS_STATE_MASK;
+ val |= (ULPS_STATE_EXIT | DEVICE_READY);
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
+ usleep_range(1000, 1500);
+
+ /* Clear ULPS and set device ready */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val = ~ULPS_STATE_MASK;
+ val |= DEVICE_READY;
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
+ }
+}
+
+static void vlv_dsi_device_ready(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
+ int pipe = intel_crtc-pipe;
enum pipe.
+ u32 val;
+ int count = 1;
+ u32 reg = 0;
+ bool afe_latchout = true;
+
+ DRM_DEBUG_KMS(\n);
+
+ pipe = intel_crtc-pipe;
+ reg = MIPI_PORT_CTRL(pipe);
Take care to not use pipe for port. Passing PIPE_B as port will *not*
use PORT_C.
+
+ /* Ceck LP state */
+ val = I915_READ(reg);
+ afe_latchout = (val AFE_LATCHOUT);
+
+ /* Enter low power state, if not already in */
+ if (afe_latchout) {
+ /* Enter ULPS, wait for 2.5 ms */
+ reg = MIPI_DEVICE_READY(pipe);
+ I915_WRITE(reg, val | ULPS_STATE_ENTER);
+ usleep_range(2000, 2500);
+ }
+
+ /* Enable transparent latch */
+ I915_WRITE(reg, val | LP_OUTPUT_HOLD);
+
+ if (intel_dsi-dual_link) {
+ count = 2;
+ pipe = PIPE_A;
+ }
+
+ do {
+ I915_WRITE(reg, val | ULPS_STATE_EXIT);
+ usleep_range(2000, 2500);
+ /* Clear ULPS state */
+ val = I915_READ(MIPI_DEVICE_READY(pipe)) ~ULPS_STATE_MASK;
+
Re: [Intel-gfx] [PATCH 11/12] drm/i915/bxt: Modify BXT BLC according to VBT changes
On Mon, 25 May 2015, Jani Nikula jani.nik...@linux.intel.com wrote:
On Fri, 22 May 2015, Uma Shankar uma.shan...@intel.com wrote:
From: Sunil Kamath sunil.kam...@intel.com
Latest VBT mentions which set of registers will be used for BLC,
as controller number field. Making use of this field in BXT
BLC implementation. Also, the registers are used in case control
pin indicates display DDI. Adding a check for this.
According to Bspec, BLC_PWM_*_2 uses the display utility pin for output.
To use backlight 2, enable the utility pin with mode = PWM
v2: Jani's review comments
addressed
- Add a prefix _ to BXT BLC registers definitions.
- Add bxt only comment for u8 controller
- Remove control_pin check for DDI controller
- Check for valid controller values
- Set pipe bits in UTIL_PIN_CTL
- Enable/Disable UTIL_PIN_CTL in enable/disable_backlight()
- If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity
Satheesh's review comment addressed
- If UTIL PIN is already enabled, BIOS would have programmed it. No
need to disable and enable again.
v3: Jani's review comments
- add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK
- Disable UTIL_PIN if controller 1 is used
- Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before enabling
UTIL_PIN
- check valid controller value in intel_bios.c
- add backlight.util_pin_active_low
- disable util pin before enabling
v4: Change for BXT-PO branch:
Stubbed unwanted definition which was existing before
because of DC6 patch.
UTIL_PIN_MODE_PWM (0x1b 24)
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Signed-off-by: Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Uma Shankar uma.shan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h| 28 +++---
drivers/gpu/drm/i915/intel_drv.h |2 +
drivers/gpu/drm/i915/intel_panel.c | 100
++--
3 files changed, 106 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index f96f049..5e3958f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3509,17 +3509,29 @@ enum skl_disp_power_wells {
#define UTIL_PIN_CTL0x48400
#define UTIL_PIN_ENABLE (1 31)
+#define UTIL_PIN_PIPE(x) ((x) 29)
+#define UTIL_PIN_PIPE_MASK (3 29)
+#define UTIL_PIN_MODE_PWM(1 24)
+#define UTIL_PIN_MODE_MASK (0xf 24)
+#define UTIL_PIN_POLARITY(1 22)
+
/* BXT backlight register definition. */
-#define BXT_BLC_PWM_CTL10xC8250
+#define _BXT_BLC_PWM_CTL1 0xC8250
#define BXT_BLC_PWM_ENABLE(1 31)
#define BXT_BLC_PWM_POLARITY (1 29)
-#define BXT_BLC_PWM_FREQ1 0xC8254
-#define BXT_BLC_PWM_DUTY1 0xC8258
-
-#define BXT_BLC_PWM_CTL20xC8350
-#define BXT_BLC_PWM_FREQ2 0xC8354
-#define BXT_BLC_PWM_DUTY2 0xC8358
-
+#define _BXT_BLC_PWM_FREQ1 0xC8254
+#define _BXT_BLC_PWM_DUTY1 0xC8258
+
+#define _BXT_BLC_PWM_CTL2 0xC8350
+#define _BXT_BLC_PWM_FREQ2 0xC8354
+#define _BXT_BLC_PWM_DUTY2 0xC8358
+
+#define BXT_BLC_PWM_CTL(controller)_PIPE(controller, \
+_BXT_BLC_PWM_CTL1, _BXT_BLC_PWM_CTL2)
+#define BXT_BLC_PWM_FREQ(controller) _PIPE(controller, \
+_BXT_BLC_PWM_FREQ1, _BXT_BLC_PWM_FREQ2)
+#define BXT_BLC_PWM_DUTY(controller) _PIPE(controller, \
+_BXT_BLC_PWM_DUTY1, _BXT_BLC_PWM_DUTY2)
#define PCH_GTC_CTL 0xe7000
#define PCH_GTC_ENABLE(1 31)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 47bc729..ee9eb2b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -182,7 +182,9 @@ struct intel_panel {
bool enabled;
bool combination_mode; /* gen 2/4 only */
bool active_low_pwm;
+bool util_pin_active_low; /* bxt+ */
struct backlight_device *device;
+u8 controller; /* bxt+ only */
} backlight;
void (*backlight_power)(struct intel_connector *, bool enable);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 7d83527..23847f2 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,7 +32,10 @@
#include linux/kernel.h
#include linux/moduleparam.h
+#include drm/drm_panel.h
#include intel_drv.h
+#include intel_dsi.h
+#include i915_drv.h
void
intel_fixed_panel_mode(const struct drm_display_mode
[Intel-gfx] [PATCH v2] drm/i915: Force wmb() on using GTT io_mapping_map_wc
Since the advent of mmap(wc), where we reused the same cache domain for WC and GTT paths (oh, how I regret that double-edged advice), we need to be extra cautious when using GTT iomap_wc internally. Since userspace maybe modifying through the mmap(wc) and we then modify modifying through an aliased WC path through the GTT, those writes may overlap and not be visible to the other path. Easiest to trigger appears to be write the batch through mmap(wc) and then attempt to perform reloc the GTT, corruption quickly ensues. v2: Be stricter and do a full mb() in case we are reading through one path and about to write through the second path. Also, apply the barriers on transitioning into the GTT domain as well to cover the white lie asychronous cases. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Akash Goel akash.g...@intel.com Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_gem.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 517c5b8100d1..f17168b2cd37 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3923,7 +3923,7 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write) int ret; if (obj-base.write_domain == I915_GEM_DOMAIN_GTT) - return 0; + goto out; ret = i915_gem_object_wait_rendering(obj, !write); if (ret) @@ -3943,13 +3943,6 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write) i915_gem_object_flush_cpu_write_domain(obj); - /* Serialise direct access to this object with the barriers for -* coherent writes from the GPU, by effectively invalidating the -* GTT domain upon first access. -*/ - if ((obj-base.read_domains I915_GEM_DOMAIN_GTT) == 0) - mb(); - old_write_domain = obj-base.write_domain; old_read_domains = obj-base.read_domains; @@ -3977,6 +3970,23 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write) list_move_tail(vma-mm_list, to_i915(obj-base.dev)-gtt.base.inactive_list); +out: + /* +* Userspace may be writing through mmap(wc) with +* write_domain=GTT (or even with a white lie unsynchronized write), +* so we need to explicitly flush before transitioning to writing +* through the GTT, or vice versa. As we reused the GTT cache domain +* for both paths, we must always have a memory barrier just in case. +* +* We need a full memory barrier in case we are reading through +* the GTT and before we starting through the WC (or vice versa). +* If we are only about to read through this access, we need only +* wait for any pending writes on the other path. +*/ + if (write) + mb(); + else + wmb(); return 0; } -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: disable IPS while getting the sink CRCs
From: Paulo Zanoni paulo.r.zan...@intel.com
This commit is the sink CRC version of:
commit 8c740dcea254a1472df2c0ac5ac585412a2507ec
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date: Fri Oct 17 18:42:03 2014 -0300
drm/i915: disable IPS while getting the pipe CRCs.
For some unknown reason, when IPS gets enabled, the sink CRC changes.
Since hsw_enable_ips() doesn't really guarantee to enable IPS (it
depends on package C-states), we can't really predict if IPS is
enabled or disabled while running our CRC tests, so let's just
completely disable IPS while sink CRCs are being used.
If we find a way to make IPS not change the pipe CRC result, we may
want to fix IPS and then revert this patch (and 8c740dcea too). While
this doesn't happen, let's merge this patch, so the IGT tests relying
on sink CRCs can work properly.
This was discovered while developing a new IGT test, which will
probably be called kms_frontbuffer_tracking.
Testcase: igt/kms_frontbuffer_tracking (not on upstream IGT yet)
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 66 -
1 file changed, 45 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index abd442a..62662de 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4041,46 +4041,70 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
*crc)
u8 buf;
int test_crc_count;
int attempts = 6;
+ int ret = 0;
- if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf) 0)
- return -EIO;
+ hsw_disable_ips(intel_crtc);
- if (!(buf DP_TEST_CRC_SUPPORTED))
- return -ENOTTY;
+ if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf) 0) {
+ ret = -EIO;
+ goto out;
+ }
+
+ if (!(buf DP_TEST_CRC_SUPPORTED)) {
+ ret = -ENOTTY;
+ goto out;
+ }
- if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0)
- return -EIO;
+ if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0) {
+ ret = -EIO;
+ goto out;
+ }
if (drm_dp_dpcd_writeb(intel_dp-aux, DP_TEST_SINK,
- buf | DP_TEST_SINK_START) 0)
- return -EIO;
+ buf | DP_TEST_SINK_START) 0) {
+ ret = -EIO;
+ goto out;
+ }
+
+ if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf) 0) {
+ ret = -EIO;
+ goto out;
+ }
- if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK_MISC, buf) 0)
- return -EIO;
test_crc_count = buf DP_TEST_COUNT_MASK;
do {
if (drm_dp_dpcd_readb(intel_dp-aux,
- DP_TEST_SINK_MISC, buf) 0)
- return -EIO;
+ DP_TEST_SINK_MISC, buf) 0) {
+ ret = -EIO;
+ goto out;
+ }
intel_wait_for_vblank(dev, intel_crtc-pipe);
} while (--attempts (buf DP_TEST_COUNT_MASK) == test_crc_count);
if (attempts == 0) {
DRM_DEBUG_KMS(Panel is unable to calculate CRC after 6
vblanks\n);
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
- if (drm_dp_dpcd_read(intel_dp-aux, DP_TEST_CRC_R_CR, crc, 6) 0)
- return -EIO;
+ if (drm_dp_dpcd_read(intel_dp-aux, DP_TEST_CRC_R_CR, crc, 6) 0) {
+ ret = -EIO;
+ goto out;
+ }
- if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0)
- return -EIO;
+ if (drm_dp_dpcd_readb(intel_dp-aux, DP_TEST_SINK, buf) 0) {
+ ret = -EIO;
+ goto out;
+ }
if (drm_dp_dpcd_writeb(intel_dp-aux, DP_TEST_SINK,
- buf ~DP_TEST_SINK_START) 0)
- return -EIO;
-
- return 0;
+ buf ~DP_TEST_SINK_START) 0) {
+ ret = -EIO;
+ goto out;
+ }
+out:
+ hsw_enable_ips(intel_crtc);
+ return ret;
}
static bool
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] tests: add kms_frontbuffer_tracking
From: Paulo Zanoni paulo.r.zan...@intel.com
This is a new test that should exercise the frontbuffer tracking
feature of the Kernel in a number of different ways. We use different
drawing methods, we use the primary, cursor and sprite planes, we can
test both on single and dual pipes, also on buffers not associated
with any CRTCs, etc.
We currently have assertions for both FBC and PSR, and we also have a
nop test mode that should disable both FBC and PSR, and can be
used for debugging.
This test is also capable of testing both FBC and PSR even if they are
disabled by default on the Kernel: the test knows how to change the
i915.ko parameters and then set them back after testing.
I am getting a small number of failures when I run this test, which
means we have some work to do on the Kernel.
I also still have a small list of additional subtests that I plan to
add to this test, and those tests are documented on the main function.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tests/.gitignore |1 +
tests/Makefile.sources |1 +
tests/kms_frontbuffer_tracking.c | 1825 ++
3 files changed, 1827 insertions(+)
create mode 100644 tests/kms_frontbuffer_tracking.c
Some interesting details:
On a tree from 2015, May 06, I get 18 failures and 357 successes. The
only FBC failures I get are from the MMAP_WC draw method, which is
maybe lacking proper frontbuffer tracking support on the Kernel. The
other 16 failures are for PSR, most of them with GTT MMAPs.
But if I use a tree from 2015, May 25, every single PSR test fails. We
need to investigate that. Maybe if I had finished this earlier we
would have an automated bisect. This also highlights the importance of
testing stuff even when they are disabled by default! I plan to patch
the other tests to do the same thing.
I am also seeing some FBC failures that happen right after booting. It
seems that the very first tests fail until I run a test that uses the
render ring. I'll have to investigate this.
I am also seeing some occasional corruptions on my eDP panel, but on
these cases both the pipe and sink CRC tests succeed! Maybe this is
some weird panel malfunction caused by the fact that we're doing tons
and tons of modesets on the panel.
diff --git a/tests/.gitignore b/tests/.gitignore
index a3f3143..dcead2c 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -134,6 +134,7 @@ kms_flip
kms_flip_event_leak
kms_flip_tiling
kms_force_connector
+kms_frontbuffer_tracking
kms_legacy_colorkey
kms_mmio_vs_cs_flip
kms_pipe_b_c_ivb
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 994c31b..3c93337 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -66,6 +66,7 @@ TESTS_progs_M = \
kms_flip \
kms_flip_event_leak \
kms_flip_tiling \
+ kms_frontbuffer_tracking \
kms_legacy_colorkey \
kms_mmio_vs_cs_flip \
kms_pipe_b_c_ivb \
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
new file mode 100644
index 000..f6554f9
--- /dev/null
+++ b/tests/kms_frontbuffer_tracking.c
@@ -0,0 +1,1825 @@
+/*
+ * Copyright © 2015 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.
+ *
+ * Authors: Paulo Zanoni paulo.r.zan...@intel.com
+ *
+ */
+
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+
+#include drmtest.h
+#include igt_aux.h
+#include igt_draw.h
+#include igt_kms.h
+#include igt_debugfs.h
+#include intel_chipset.h
+#include ioctl_wrappers.h
+
+#define FBC_PARAM_PATH /sys/module/i915/parameters/enable_fbc
+#define PSR_PARAM_PATH /sys/module/i915/parameters/enable_psr
+
+struct test_mode {
+ enum {
+ PIPE_SINGLE = 0,
+ PIPE_DUAL,
+ PIPE_COUNT,
+ } pipes;
+
+ enum {
+ SCREEN_PRIM = 0,
+ SCREEN_SCND,
+
Re: [Intel-gfx] drivers/gpu/drm/i915/i915_gem_gtt.c
On Mon, May 25, 2015 at 7:32 AM, Jani Nikula jani.nik...@linux.intel.com wrote: I'm not sure what is the approved way of fixing this. Perhaps disabling CONFIG_DRM_I915_WERROR when CONFIG_COMPILE_TEST=y. Maybe the answer right now is to just drop that config. Daniel? Agreed, that little experiment doesn't seem to be worth the trouble. I've pushed/sent-out the revert. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert drm/i915: Force clean compilation with -Werror
This reverts commit 118182e9d7d5afa0c7c10f568afb46ab78b462e9. It's causing too much trouble when compile-testing for non-i915 folks. Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Jani Nikula jani.nik...@intel.com Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/i915/Kconfig | 8 drivers/gpu/drm/i915/Kconfig.debug | 5 - drivers/gpu/drm/i915/Makefile | 2 -- 3 files changed, 15 deletions(-) delete mode 100644 drivers/gpu/drm/i915/Kconfig.debug diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 5e3aa87e8f48..74acca9bcd9d 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -71,11 +71,3 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT option changes the default for that module option. If in doubt, say N. - -menu DRM i915 Debugging - -depends on DRM_I915 - -source drivers/gpu/drm/i915/Kconfig.debug - -endmenu diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug deleted file mode 100644 index 070a03527bc5.. --- a/drivers/gpu/drm/i915/Kconfig.debug +++ /dev/null @@ -1,5 +0,0 @@ -config DRM_I915_WERROR - bool Force GCC to throw an error instead of a warning when compiling - default n - ---help--- - Add -Werror to the build flags for (and only for) i915.ko diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 93d99b744531..b7ddf48e1d75 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -2,8 +2,6 @@ # Makefile for the drm device driver. This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. -subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror - # Please keep these build lists sorted! # core driver code -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] kms_rotation_crc: Update rotation direction for kernel changes
Thanks for sending this.. I realized that I had a patch for this which I never
sent :)
Reviewed-by: Sonika Jindal sonika.jin...@intel.com
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Friday, May 22, 2015 3:31 PM
To: Intel-gfx@lists.freedesktop.org
Cc: Ursulin, Tvrtko; Ville Syrjälä; Jindal, Sonika
Subject: [PATCH i-g-t] kms_rotation_crc: Update rotation direction for kernel
changes
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
commit 1e8df16778b0d8fd8102b3ee799b028f8f961089
Author: Sonika Jindal sonika.jin...@intel.com
Date: Wed May 20 13:40:48 2015 +0530
drm/i915/skl: Swapping 90 and 270 to be compliant with Xrand
Changed the rotation direction so IGT needs to be told.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Sonika Jindal sonika.jin...@intel.com
---
tests/kms_rotation_crc.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index
e16056d..3fd77c4 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -61,21 +61,19 @@ paint_squares(data_t *data, drmModeModeInfo *mode,
igt_rotation_t rotation,
}
if (rotation == IGT_ROTATION_90) {
- /* Paint 4 squares with width == height in Blue, Red,
- Green, White Clockwise order to look like 90 degree rotated*/
- igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 0.0, 1.0);
- igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
- igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 1.0, 1.0);
- igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 1.0, 0.0);
-
- } else if (rotation == IGT_ROTATION_270) {
/* Paint 4 squares with width == height in Green, White,
Blue, Red Clockwise order to look like 270 degree rotated*/
igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 1.0, 0.0);
igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 1.0, 1.0);
igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 0.0, 0.0);
igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 0.0, 1.0);
-
+ } else if (rotation == IGT_ROTATION_270) {
+ /* Paint 4 squares with width == height in Blue, Red,
+ Green, White Clockwise order to look like 90 degree rotated*/
+ igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 0.0, 1.0);
+ igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
+ igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 1.0, 1.0);
+ igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0, 1.0, 0.0);
} else {
/* Paint with 4 squares of Red, Green, White, Blue Clockwise */
igt_paint_color(cr, 0, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
--
2.4.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
