Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/glk: Program pipe gamma and degamma tables
On Thu, 2017-01-26 at 16:21 +0200, Ville Syrjälä wrote:
> On Thu, Jan 26, 2017 at 01:24:24PM +0200, Ander Conselvan de Oliveira wrote:
> > The gamma tables in Geminilake were changed. There is no split-gamma
> > mode. Instead, there is a dedicated degamma table that is enabled
> > whenever pipe CSC is enabled.
> >
> > The dedicated gamma table has 16 bit precision but doesn't support
> > separate channels. Since that doesn't match the per-channel format of
> > the degamma LUT property, for now only a linear table is loaded and the
> > property ignored.
> >
> > v2: Remove empty line. (Ville)
> > Reuse broadwell code. (Ville)
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Ander Conselvan de Oliveira > l.com>
> > ---
> > drivers/gpu/drm/i915/i915_pci.c| 1 +
> > drivers/gpu/drm/i915/i915_reg.h| 14 +
> > drivers/gpu/drm/i915/intel_color.c | 60
> > +-
> > 3 files changed, 74 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index ecb487b..df2051b 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -403,6 +403,7 @@ static const struct intel_device_info
> > intel_geminilake_info = {
> > .platform = INTEL_GEMINILAKE,
> > .is_alpha_support = 1,
> > .ddb_size = 1024,
> > + .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> > };
> >
> > static const struct intel_device_info intel_kabylake_info = {
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 06bbe55..e029691 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8181,12 +8181,26 @@ enum {
> > #define _PAL_PREC_EXT_GC_MAX_A 0x4A420
> > #define _PAL_PREC_EXT_GC_MAX_B 0x4AC20
> > #define _PAL_PREC_EXT_GC_MAX_C 0x4B420
> > +#define _PAL_PREC_EXT2_GC_MAX_A0x4A430
> > +#define _PAL_PREC_EXT2_GC_MAX_B0x4AC30
> > +#define _PAL_PREC_EXT2_GC_MAX_C0x4B430
> >
> > #define PREC_PAL_INDEX(pipe) _MMIO_PIPE(pipe,
> > _PAL_PREC_INDEX_A, _PAL_PREC_INDEX_B)
> > #define PREC_PAL_DATA(pipe)_MMIO_PIPE(pipe,
> > _PAL_PREC_DATA_A, _PAL_PREC_DATA_B)
> > #define PREC_PAL_GC_MAX(pipe, i) _MMIO(_PIPE(pipe,
> > _PAL_PREC_GC_MAX_A, _PAL_PREC_GC_MAX_B) + (i) * 4)
> > #define PREC_PAL_EXT_GC_MAX(pipe, i) _MMIO(_PIPE(pipe,
> > _PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
> >
> > +#define _PRE_CSC_GAMC_INDEX_A 0x4A484
> > +#define _PRE_CSC_GAMC_INDEX_B 0x4AC84
> > +#define _PRE_CSC_GAMC_INDEX_C 0x4B484
> > +#define PRE_CSC_GAMC_AUTO_INCREMENT (1 << 10)
> > +#define _PRE_CSC_GAMC_DATA_A 0x4A488
> > +#define _PRE_CSC_GAMC_DATA_B 0x4AC88
> > +#define _PRE_CSC_GAMC_DATA_C 0x4B488
> > +
> > +#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe,
> > _PRE_CSC_GAMC_INDEX_A, _PRE_CSC_GAMC_INDEX_B)
> > +#define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe,
> > _PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
> > +
> > /* pipe CSC & degamma/gamma LUTs on CHV */
> > #define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
> > #define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
> > diff --git a/drivers/gpu/drm/i915/intel_color.c
> > b/drivers/gpu/drm/i915/intel_color.c
> > index 82a3bc9..2125aa3 100644
> > --- a/drivers/gpu/drm/i915/intel_color.c
> > +++ b/drivers/gpu/drm/i915/intel_color.c
> > @@ -380,7 +380,9 @@ static void bdw_load_gamma_lut(struct drm_crtc_state
> > *state, u32 offset)
> > WARN_ON(offset & ~PAL_PREC_INDEX_VALUE_MASK);
> >
> > I915_WRITE(PREC_PAL_INDEX(pipe),
> > - PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT | offset);
> > + (offset ? PAL_PREC_SPLIT_MODE : 0) |
> > + PAL_PREC_AUTO_INCREMENT |
> > + offset);
>
> This confused me for a bit. I was thinking we're using this to write the
> deamma part for the split gamma case as well, which would end up
> disabling the split gamma mode when doing that. But that's not actually
> what's happening since you had another function to write the degamma
> half.
>
> >
> > if (state->gamma_lut) {
> > struct drm_color_lut *lut =
> > @@ -443,6 +445,59 @@ static void broadwell_load_luts(struct drm_crtc_state
> > *state)
> > I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> > }
> >
> > +static void glk_load_degamma_lut(struct drm_crtc_state *state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(state->crtc->dev);
> > + enum pipe pipe = to_intel_crtc(state->crtc)->pipe;
> > + const uint32_t lut_size = 33;
> > + uint32_t i;
> > +
> > + /*
> > + * When setting the auto-increment bit, the hardware seems to
> > + * ignore the index bits, so we need to reset it to index 0
> > + * separately.
> > + */
>
> Interesting. Do we know if the same problem might be present in other
> gamma tables?
I haven't tested, bu
[Intel-gfx] [PATCH v3] drm/i915/glk: Program pipe gamma and degamma tables
The gamma tables in Geminilake were changed. There is no split-gamma
mode. Instead, there is a dedicated degamma table that is enabled
whenever pipe CSC is enabled.
The dedicated gamma table has 16 bit precision but doesn't support
separate channels. Since that doesn't match the per-channel format of
the degamma LUT property, for now only a linear table is loaded and the
property ignored.
v2: Remove empty line. (Ville)
Reuse broadwell code. (Ville)
v3: Don't write PIPE_CSC_MODE. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
Don't write CSC_MODE
---
drivers/gpu/drm/i915/i915_pci.c| 1 +
drivers/gpu/drm/i915/i915_reg.h| 14 +
drivers/gpu/drm/i915/intel_color.c | 58 +-
3 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ecb487b..df2051b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -403,6 +403,7 @@ static const struct intel_device_info intel_geminilake_info
= {
.platform = INTEL_GEMINILAKE,
.is_alpha_support = 1,
.ddb_size = 1024,
+ .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
};
static const struct intel_device_info intel_kabylake_info = {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 06bbe55..e029691 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8181,12 +8181,26 @@ enum {
#define _PAL_PREC_EXT_GC_MAX_A 0x4A420
#define _PAL_PREC_EXT_GC_MAX_B 0x4AC20
#define _PAL_PREC_EXT_GC_MAX_C 0x4B420
+#define _PAL_PREC_EXT2_GC_MAX_A0x4A430
+#define _PAL_PREC_EXT2_GC_MAX_B0x4AC30
+#define _PAL_PREC_EXT2_GC_MAX_C0x4B430
#define PREC_PAL_INDEX(pipe) _MMIO_PIPE(pipe, _PAL_PREC_INDEX_A,
_PAL_PREC_INDEX_B)
#define PREC_PAL_DATA(pipe)_MMIO_PIPE(pipe, _PAL_PREC_DATA_A,
_PAL_PREC_DATA_B)
#define PREC_PAL_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A,
_PAL_PREC_GC_MAX_B) + (i) * 4)
#define PREC_PAL_EXT_GC_MAX(pipe, i) _MMIO(_PIPE(pipe,
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
+#define _PRE_CSC_GAMC_INDEX_A 0x4A484
+#define _PRE_CSC_GAMC_INDEX_B 0x4AC84
+#define _PRE_CSC_GAMC_INDEX_C 0x4B484
+#define PRE_CSC_GAMC_AUTO_INCREMENT (1 << 10)
+#define _PRE_CSC_GAMC_DATA_A 0x4A488
+#define _PRE_CSC_GAMC_DATA_B 0x4AC88
+#define _PRE_CSC_GAMC_DATA_C 0x4B488
+
+#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
+#define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 82a3bc9..0627eee 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -380,7 +380,9 @@ static void bdw_load_gamma_lut(struct drm_crtc_state
*state, u32 offset)
WARN_ON(offset & ~PAL_PREC_INDEX_VALUE_MASK);
I915_WRITE(PREC_PAL_INDEX(pipe),
- PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT | offset);
+ (offset ? PAL_PREC_SPLIT_MODE : 0) |
+ PAL_PREC_AUTO_INCREMENT |
+ offset);
if (state->gamma_lut) {
struct drm_color_lut *lut =
@@ -443,6 +445,57 @@ static void broadwell_load_luts(struct drm_crtc_state
*state)
I915_WRITE(PREC_PAL_INDEX(pipe), 0);
}
+static void glk_load_degamma_lut(struct drm_crtc_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->crtc->dev);
+ enum pipe pipe = to_intel_crtc(state->crtc)->pipe;
+ const uint32_t lut_size = 33;
+ uint32_t i;
+
+ /*
+* When setting the auto-increment bit, the hardware seems to
+* ignore the index bits, so we need to reset it to index 0
+* separately.
+*/
+ I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
+ I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), PRE_CSC_GAMC_AUTO_INCREMENT);
+
+ /*
+* FIXME: The pipe degamma table in geminilake doesn't support
+* different values per channel, so this just loads a linear table.
+*/
+ for (i = 0; i < lut_size; i++) {
+ uint32_t v = (i * ((1 << 16) - 1)) / (lut_size - 1);
+
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
+ }
+
+ /* Clamp values > 1.0. */
+ while (i++ < 35)
+ I915_WRITE(PRE_CSC_GAMC_DATA(pipe), (1 << 16) - 1);
+}
+
+static void glk_load_luts(struct drm_crtc_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc_s
[Intel-gfx] [PATCH RFC 6/5] drm/i915: Merge BDW pipe gamma and degamma table code
The only difference between the code loading the pipe gamma and degamma
tables in BDW is that the gamma code also writes the registers that hold
the maximum values. So we can use the gamma code for the degamma table,
at the expense of writing the maximum value register twice, with
potenttially wrong values in the first time.
Cc: Ville Syrjälä
Signed-off-by: Ander Conselvan de Oliveira
---
Ville, does this help with the split gamma enable/disable confusion?
Note that I didn't test this.
Ander
---
drivers/gpu/drm/i915/intel_color.c | 57 ++
1 file changed, 15 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 08345e5..c686c37 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -340,54 +340,22 @@ static void haswell_load_luts(struct drm_crtc_state
*crtc_state)
hsw_enable_ips(intel_crtc);
}
-static void bdw_load_degamma_lut(struct drm_crtc_state *state)
+static void bdw_load_lut(struct drm_crtc_state *state, u32 offset,
+struct drm_color_lut *lut, u32 lut_size,
+bool split_mode)
{
struct drm_i915_private *dev_priv = to_i915(state->crtc->dev);
enum pipe pipe = to_intel_crtc(state->crtc)->pipe;
- uint32_t i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
-
- I915_WRITE(PREC_PAL_INDEX(pipe),
- PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT);
-
- if (state->degamma_lut) {
- struct drm_color_lut *lut =
- (struct drm_color_lut *) state->degamma_lut->data;
-
- for (i = 0; i < lut_size; i++) {
- uint32_t word =
- drm_color_lut_extract(lut[i].red, 10) << 20 |
- drm_color_lut_extract(lut[i].green, 10) << 10 |
- drm_color_lut_extract(lut[i].blue, 10);
-
- I915_WRITE(PREC_PAL_DATA(pipe), word);
- }
- } else {
- for (i = 0; i < lut_size; i++) {
- uint32_t v = (i * ((1 << 10) - 1)) / (lut_size - 1);
-
- I915_WRITE(PREC_PAL_DATA(pipe),
- (v << 20) | (v << 10) | v);
- }
- }
-}
-
-static void bdw_load_gamma_lut(struct drm_crtc_state *state, u32 offset)
-{
- struct drm_i915_private *dev_priv = to_i915(state->crtc->dev);
- enum pipe pipe = to_intel_crtc(state->crtc)->pipe;
- uint32_t i, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ uint32_t i;
WARN_ON(offset & ~PAL_PREC_INDEX_VALUE_MASK);
I915_WRITE(PREC_PAL_INDEX(pipe),
- (offset ? PAL_PREC_SPLIT_MODE : 0) |
+ (split_mode ? PAL_PREC_SPLIT_MODE : 0) |
PAL_PREC_AUTO_INCREMENT |
offset);
- if (state->gamma_lut) {
- struct drm_color_lut *lut =
- (struct drm_color_lut *) state->gamma_lut->data;
-
+ if (lut) {
for (i = 0; i < lut_size; i++) {
uint32_t word =
(drm_color_lut_extract(lut[i].red, 10) << 20) |
@@ -430,9 +398,12 @@ static void broadwell_load_luts(struct drm_crtc_state
*state)
return;
}
- bdw_load_degamma_lut(state);
- bdw_load_gamma_lut(state,
- INTEL_INFO(dev_priv)->color.degamma_lut_size);
+ bdw_load_lut(state, 0, (struct drm_color_lut *) state->degamma_lut,
+INTEL_INFO(dev_priv)->color.degamma_lut_size, true);
+ bdw_load_lut(state, INTEL_INFO(dev_priv)->color.degamma_lut_size,
+(struct drm_color_lut *) state->gamma_lut,
+INTEL_INFO(dev_priv)->color.gamma_lut_size,
+true);
intel_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_SPLIT);
@@ -489,7 +460,9 @@ static void glk_load_luts(struct drm_crtc_state *state)
}
glk_load_degamma_lut(state);
- bdw_load_gamma_lut(state, 0);
+ bdw_load_lut(state, 0, (struct drm_color_lut *) state->gamma_lut,
+INTEL_INFO(dev_priv)->color.gamma_lut_size,
+false);
intel_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_10BIT);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > When writing some testcases for nonblocking modesets. I found out that the > infinite wait on the old fb was causing issues. The crux of the issue here is the locked wait for old dependencies and the inability to inject the intel_prepare_reset disabling of all planes. There are a couple of locked waits on struct_mutex within the modeset locks for intel_overlay and if we happen to be using the display plane for the first time. The first I suggested solving using fences to track dependencies and keep the order between atomic states. Cancelling the outstanding modesets, replacing with a disable and then on restore jumping to the final state look doable. It also requires avoiding the struct_mutex for disabling, which is quite easy. To avoid the wait under struct_mutex, we've talked about switching to mmio, but for starters we could move the wait from inside intel_overlay into the fence for the atomic operation. (But's that a little more surgery than we would like for intel_overlay I guess - dig out Ville's patches for overlay planes?) And to prevent the wait under struct_mutex for pin_to_display_plane, my plane is to move that to an async fenced operation that is then naturally waited upon by the atomic modeset. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/gen9+: Enable hotplug detection early
For LSPCON resume time initialization we need to sample the
corresponding pin's HPD level, but this is only available when HPD
detection is enabled. Currently we enable detection only when enabling
HPD interrupts which is too late, so bring the enabling of detection
earlier.
This is needed by the next patch.
Cc: Shashank Sharma
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: # v4.9+
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_irq.c | 71 +
1 file changed, 51 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8440d8b..6daf522 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3142,24 +3142,33 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
*dev_priv)
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
}
+static void spt_hpd_detection_setup(struct drm_i915_private *dev_priv)
+{
+ u32 hotplug;
+
+ /* Enable digital hotplug on the PCH */
+ hotplug = I915_READ(PCH_PORT_HOTPLUG);
+ hotplug |= PORTA_HOTPLUG_ENABLE |
+ PORTB_HOTPLUG_ENABLE |
+ PORTC_HOTPLUG_ENABLE |
+ PORTD_HOTPLUG_ENABLE;
+ I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+
+ hotplug = I915_READ(PCH_PORT_HOTPLUG2);
+ hotplug |= PORTE_HOTPLUG_ENABLE;
+ I915_WRITE(PCH_PORT_HOTPLUG2, hotplug);
+}
+
static void spt_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
- u32 hotplug_irqs, hotplug, enabled_irqs;
+ u32 hotplug_irqs, enabled_irqs;
hotplug_irqs = SDE_HOTPLUG_MASK_SPT;
enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_spt);
ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
- /* Enable digital hotplug on the PCH */
- hotplug = I915_READ(PCH_PORT_HOTPLUG);
- hotplug |= PORTD_HOTPLUG_ENABLE | PORTC_HOTPLUG_ENABLE |
- PORTB_HOTPLUG_ENABLE | PORTA_HOTPLUG_ENABLE;
- I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
-
- hotplug = I915_READ(PCH_PORT_HOTPLUG2);
- hotplug |= PORTE_HOTPLUG_ENABLE;
- I915_WRITE(PCH_PORT_HOTPLUG2, hotplug);
+ spt_hpd_detection_setup(dev_priv);
}
static void ilk_hpd_irq_setup(struct drm_i915_private *dev_priv)
@@ -3196,18 +3205,15 @@ static void ilk_hpd_irq_setup(struct drm_i915_private
*dev_priv)
ibx_hpd_irq_setup(dev_priv);
}
-static void bxt_hpd_irq_setup(struct drm_i915_private *dev_priv)
+static void __bxt_hpd_detection_setup(struct drm_i915_private *dev_priv,
+u32 enabled_irqs)
{
- u32 hotplug_irqs, hotplug, enabled_irqs;
-
- enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_bxt);
- hotplug_irqs = BXT_DE_PORT_HOTPLUG_MASK;
-
- bdw_update_port_irq(dev_priv, hotplug_irqs, enabled_irqs);
+ u32 hotplug;
hotplug = I915_READ(PCH_PORT_HOTPLUG);
- hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
- PORTA_HOTPLUG_ENABLE;
+ hotplug |= PORTA_HOTPLUG_ENABLE |
+ PORTB_HOTPLUG_ENABLE |
+ PORTC_HOTPLUG_ENABLE;
DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
hotplug, enabled_irqs);
@@ -3217,7 +3223,6 @@ static void bxt_hpd_irq_setup(struct drm_i915_private
*dev_priv)
* For BXT invert bit has to be set based on AOB design
* for HPD detection logic, update it based on VBT fields.
*/
-
if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
hotplug |= BXT_DDIA_HPD_INVERT;
@@ -3231,6 +3236,23 @@ static void bxt_hpd_irq_setup(struct drm_i915_private
*dev_priv)
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
}
+static void bxt_hpd_detection_setup(struct drm_i915_private *dev_priv)
+{
+ __bxt_hpd_detection_setup(dev_priv, BXT_DE_PORT_HOTPLUG_MASK);
+}
+
+static void bxt_hpd_irq_setup(struct drm_i915_private *dev_priv)
+{
+ u32 hotplug_irqs, enabled_irqs;
+
+ enabled_irqs = intel_hpd_enabled_irqs(dev_priv, hpd_bxt);
+ hotplug_irqs = BXT_DE_PORT_HOTPLUG_MASK;
+
+ bdw_update_port_irq(dev_priv, hotplug_irqs, enabled_irqs);
+
+ __bxt_hpd_detection_setup(dev_priv, enabled_irqs);
+}
+
static void ibx_irq_postinstall(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3246,6 +3268,12 @@ static void ibx_irq_postinstall(struct drm_device *dev)
gen5_assert_iir_is_zero(dev_priv, SDEIIR);
I915_WRITE(SDEIMR, ~mask);
+
+ if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv) ||
+ HAS_PCH_LPT(dev_priv))
+ ; /* TODO: Enable HPD detection on older PCH platforms too */
+ else
+ spt_hpd_detection_setup(dev_priv);
}
static void gen5_gt_irq_postinstall(struct drm_device *dev)
@@ -3457,6 +3485,9 @@ static void gen8_de_irq_postinstall(
[Intel-gfx] [CI 1/2] drm/i915: Enable userspace to opt-out of implicit fencing
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties and wants more fine-grained access to buffers (e.g. it
may partition the buffer between uses and track fences on ranges rather
than the implicit fences tracking the whole object). It follows that
userspace needs a mechanism to avoid the kernel's serialisation on its
implicit fences before execbuf execution.
The next question is whether this is an object, execbuf or context flag.
Hybrid users (such as using explicit EGL_ANDROID_native_sync fencing on
shared winsys buffers, but implicit fencing on internal surfaces)
require a per-object level flag. Given that this flag need to be only
set once for the lifetime of the object, this reduces the convenience of
having an execbuf or context level flag (and avoids having multiple
pieces of uABI controlling the same feature).
Incorrect use of this flag will result in rendering corruption and GPU
hangs - but will not result in use-after-free or similar resource
tracking issues.
Serious caveat: write ordering is not strictly correct after setting
this flag on a render target on multiple engines. This affects all
subsequent GEM operations (execbuf, set-domain, pread) and shared
dma-buf operations. A fix is possible - but costly (both in terms of
further ABI changes and runtime overhead).
Testcase: igt/gem_exec_async
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Acked-by: Chad Versace
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +++
include/uapi/drm/i915_drm.h| 30 +-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0b87ae0ef942..8efa0d78ad98 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -349,6 +349,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_HANDLE_LUT:
case I915_PARAM_HAS_COHERENT_PHYS_GTT:
case I915_PARAM_HAS_EXEC_SOFTPIN:
+ case I915_PARAM_HAS_EXEC_ASYNC:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c66e90571031..6fd60682bf93 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -,6 +,9 @@ i915_gem_execbuffer_move_to_gpu(struct
drm_i915_gem_request *req,
list_for_each_entry(vma, vmas, exec_list) {
struct drm_i915_gem_object *obj = vma->obj;
+ if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
+ continue;
+
ret = i915_gem_request_await_object
(req, obj, obj->base.pending_write_domain);
if (ret)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 57093b455db6..5842a652f596 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -397,6 +397,13 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_SCHEDULER41
#define I915_PARAM_HUC_STATUS 42
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of
+ * synchronisation with implicit fencing on individual objects.
+ * See EXEC_OBJECT_ASYNC.
+ */
+#define I915_PARAM_HAS_EXEC_ASYNC 43
+
+
typedef struct drm_i915_getparam {
__s32 param;
/*
@@ -737,8 +744,29 @@ struct drm_i915_gem_exec_object2 {
#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
#define EXEC_OBJECT_PINNED (1<<4)
#define EXEC_OBJECT_PAD_TO_SIZE (1<<5)
+/* The kernel implicitly tracks GPU activity on all GEM objects, and
+ * synchronises operations with outstanding rendering. This includes
+ * rendering on other devices if exported via dma-buf. However, sometimes
+ * this tracking is too coarse and the user knows better. For example,
+ * if the object is split into non-overlapping ranges shared between different
+ * clients or engines (i.e. suballocating objects), the implicit tracking
+ * by kernel assumes that each operation affects the whole object rather
+ * than an individual range, causing needless synchronisation between clients.
+ * The kernel will also forgo any CPU cache flushes prior to rendering from
+ * the object as the client is expected to be also handling such domain
+ * tracking.
+ *
+ * The kernel maintains the implicit tracking in order to manage resources
+ * used by the GPU - this flag only disables the synchronisation prior to
+ * rendering w
[Intel-gfx] [PATCH 3/4] drm/i915/lspcon: Remove DPCD compare based resume time workaround
This effectively reverts
commit 489375c866c111f16cea93b2467ebe59c9022cc7
Author: Imre Deak
Date: Mon Oct 24 19:33:31 2016 +0300
drm/i915/lspcon: Add workaround for resuming in PCON mode
The workaround was added without considering that HPD is low during
the failed AUX transfers the WA fixed. Since the previous patch we
wait for HPD to get asserted. My tests also show that this happens
_after_ the DPCD reads start to return correct values. This
suggests that we don't need this WA any more, let's try to remove
it to reduce the clutter.
Cc: Shashank Sharma
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_drv.h| 1 -
drivers/gpu/drm/i915/intel_lspcon.c | 17 ++---
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b9cde11..b2882ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -989,7 +989,6 @@ struct intel_dp {
struct intel_lspcon {
bool active;
enum drm_lspcon_mode mode;
- bool desc_valid;
};
struct intel_digital_port {
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index c300647..71cbe9c 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -162,21 +162,8 @@ static void lspcon_resume_in_pcon_wa(struct intel_lspcon
*lspcon)
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
unsigned long start = jiffies;
- if (!lspcon->desc_valid)
- return;
-
while (1) {
- struct intel_dp_desc desc;
-
- /*
-* The w/a only applies in PCON mode and we don't expect any
-* AUX errors.
-*/
- if (!__intel_dp_read_desc(intel_dp, &desc))
- return;
-
- if (intel_digital_port_connected(dev_priv, dig_port) &&
- !memcmp(&intel_dp->desc, &desc, sizeof(desc))) {
+ if (intel_digital_port_connected(dev_priv, dig_port)) {
DRM_DEBUG_KMS("LSPCON recovering in PCON mode after %u
ms\n",
jiffies_to_msecs(jiffies - start));
return;
@@ -253,7 +240,7 @@ bool lspcon_init(struct intel_digital_port *intel_dig_port)
return false;
}
- lspcon->desc_valid = intel_dp_read_desc(dp);
+ intel_dp_read_desc(dp);
DRM_DEBUG_KMS("Success: LSPCON init\n");
return true;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/lspcon: Fix resume time initialization due to unasserted HPD
During system resume time initialization the HPD level on LSPCON ports
can stay low for an extended amount of time, leading to failed AUX
transfers and LSPCON initialization. Fix this by waiting for HPD to get
asserted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99178
Cc: Shashank Sharma
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: # v4.9+
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_lspcon.c | 5 -
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e0f9b9e..a7785ce 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4400,8 +4400,8 @@ static bool bxt_digital_port_connected(struct
drm_i915_private *dev_priv,
*
* Return %true if @port is connected, %false otherwise.
*/
-static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
-struct intel_digital_port *port)
+bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port)
{
if (HAS_PCH_IBX(dev_priv))
return ibx_digital_port_connected(dev_priv, port);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b71fece..b9cde11 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1489,6 +1489,8 @@ bool __intel_dp_read_desc(struct intel_dp *intel_dp,
bool intel_dp_read_desc(struct intel_dp *intel_dp);
int intel_dp_link_required(int pixel_clock, int bpp);
int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
+bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *port);
/* intel_dp_aux_backlight.c */
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index f6d4e69..c300647 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -158,6 +158,8 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
static void lspcon_resume_in_pcon_wa(struct intel_lspcon *lspcon)
{
struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
unsigned long start = jiffies;
if (!lspcon->desc_valid)
@@ -173,7 +175,8 @@ static void lspcon_resume_in_pcon_wa(struct intel_lspcon
*lspcon)
if (!__intel_dp_read_desc(intel_dp, &desc))
return;
- if (!memcmp(&intel_dp->desc, &desc, sizeof(desc))) {
+ if (intel_digital_port_connected(dev_priv, dig_port) &&
+ !memcmp(&intel_dp->desc, &desc, sizeof(desc))) {
DRM_DEBUG_KMS("LSPCON recovering in PCON mode after %u
ms\n",
jiffies_to_msecs(jiffies - start));
return;
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915: Support explicit fencing for execbuf
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase: igt/gem_exec_fence
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Acked-by: Chad Versace
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/i915_drv.c| 3 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 54 +++---
include/uapi/drm/i915_drm.h| 35 ++-
4 files changed, 86 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 183f5dc1c3f2..1ae0bb91ee60 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -19,6 +19,7 @@ config DRM_I915
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
+ select SYNC_FILE
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8efa0d78ad98..0e9f1226a2b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -350,6 +350,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_COHERENT_PHYS_GTT:
case I915_PARAM_HAS_EXEC_SOFTPIN:
case I915_PARAM_HAS_EXEC_ASYNC:
+ case I915_PARAM_HAS_EXEC_FENCE:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
@@ -2550,7 +2551,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_RENDER_ALLOW),
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6fd60682bf93..91c2393199a3 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -1595,6 +1596,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_execbuffer_params *params = ¶ms_master;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
+ struct dma_fence *in_fence = NULL;
+ struct sync_file *out_fence = NULL;
+ int out_fence_fd = -1;
int ret;
bool need_relocs;
@@ -1638,6 +1642,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
dispatch_flags |= I915_DISPATCH_RS;
}
+ if (args->flags & I915_EXEC_FENCE_IN) {
+ in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
+ if (!in_fence) {
+ ret = -EINVAL;
+ goto pre_mutex_err;
+ }
+ }
+
+ if (args->flags & I915_EXEC_FENCE_OUT) {
+ out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
+ if (out_fence_fd < 0) {
+ ret = out_fence_fd;
+ out_fence_fd = -1;
+ goto pre_mutex_err;
+ }
+ }
+
/* Take a local wakeref for preparing to dispatch the execbuf as
* we expect to access the hardware fairly frequently in the
* process. Upon first dispatch, we acquire another prolonged
@@ -1782,6 +1803,21 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
goto err_batch_unpin;
}
+ if (in_fence) {
+ ret = i915_gem_request_await_dma_fence(params->request,
+ in_fence);
+ if (ret < 0)
+ goto err_request;
+ }
+
+ if (out_fence_fd != -1) {
+ out_fence = sync_file_create(¶ms->request->fence);
+ if (!out_fence) {
+ ret = -ENOMEM;
+ goto err_request;
+ }
+ }
+
/* Whilst this request exists, batch_obj w
[Intel-gfx] [PATCH 4/4] drm/i915/gen5+, pch: Enable hotplug detection early
To be consistent with the recent change to enable hotplug detection
early on GEN9 platforms do the same on all non-GMCH platforms starting
from GEN5. On GMCH platforms enabling detection without interrupts isn't
trivial, since AUX and HPD have a shared interrupt line. It could be
done there too by using a SW interrupt mask, but I punt on that for now.
Cc: Shashank Sharma
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Daniel Vetter
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_irq.c | 79 ++---
1 file changed, 50 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6daf522..88c10b1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3109,9 +3109,34 @@ static u32 intel_hpd_enabled_irqs(struct
drm_i915_private *dev_priv,
return enabled_irqs;
}
+static void ibx_hpd_detection_setup(struct drm_i915_private *dev_priv)
+{
+ u32 hotplug;
+
+ /*
+* Enable digital hotplug on the PCH, and configure the DP short pulse
+* duration to 2ms (which is the minimum in the Display Port spec).
+* The pulse duration bits are reserved on LPT+.
+*/
+ hotplug = I915_READ(PCH_PORT_HOTPLUG);
+ hotplug &= ~(PORTB_PULSE_DURATION_MASK |
+PORTC_PULSE_DURATION_MASK |
+PORTD_PULSE_DURATION_MASK);
+ hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms;
+ hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms;
+ hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms;
+ /*
+* When CPU and PCH are on the same package, port A
+* HPD must be enabled in both north and south.
+*/
+ if (HAS_PCH_LPT_LP(dev_priv))
+ hotplug |= PORTA_HOTPLUG_ENABLE;
+ I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+}
+
static void ibx_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
- u32 hotplug_irqs, hotplug, enabled_irqs;
+ u32 hotplug_irqs, enabled_irqs;
if (HAS_PCH_IBX(dev_priv)) {
hotplug_irqs = SDE_HOTPLUG_MASK;
@@ -3123,23 +3148,7 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
*dev_priv)
ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
- /*
-* Enable digital hotplug on the PCH, and configure the DP short pulse
-* duration to 2ms (which is the minimum in the Display Port spec).
-* The pulse duration bits are reserved on LPT+.
-*/
- hotplug = I915_READ(PCH_PORT_HOTPLUG);
- hotplug &=
~(PORTD_PULSE_DURATION_MASK|PORTC_PULSE_DURATION_MASK|PORTB_PULSE_DURATION_MASK);
- hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms;
- hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms;
- hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms;
- /*
-* When CPU and PCH are on the same package, port A
-* HPD must be enabled in both north and south.
-*/
- if (HAS_PCH_LPT_LP(dev_priv))
- hotplug |= PORTA_HOTPLUG_ENABLE;
- I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+ ibx_hpd_detection_setup(dev_priv);
}
static void spt_hpd_detection_setup(struct drm_i915_private *dev_priv)
@@ -3171,9 +3180,25 @@ static void spt_hpd_irq_setup(struct drm_i915_private
*dev_priv)
spt_hpd_detection_setup(dev_priv);
}
+static void ilk_hpd_detection_setup(struct drm_i915_private *dev_priv)
+{
+ u32 hotplug;
+
+ /*
+* Enable digital hotplug on the CPU, and configure the DP short pulse
+* duration to 2ms (which is the minimum in the Display Port spec)
+* The pulse duration bits are reserved on HSW+.
+*/
+ hotplug = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ hotplug &= ~DIGITAL_PORTA_PULSE_DURATION_MASK;
+ hotplug |= DIGITAL_PORTA_HOTPLUG_ENABLE |
+ DIGITAL_PORTA_PULSE_DURATION_2ms;
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, hotplug);
+}
+
static void ilk_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
- u32 hotplug_irqs, hotplug, enabled_irqs;
+ u32 hotplug_irqs, enabled_irqs;
if (INTEL_GEN(dev_priv) >= 8) {
hotplug_irqs = GEN8_PORT_DP_A_HOTPLUG;
@@ -3192,15 +3217,7 @@ static void ilk_hpd_irq_setup(struct drm_i915_private
*dev_priv)
ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
}
- /*
-* Enable digital hotplug on the CPU, and configure the DP short pulse
-* duration to 2ms (which is the minimum in the Display Port spec)
-* The pulse duration bits are reserved on HSW+.
-*/
- hotplug = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
- hotplug &= ~DIGITAL_PORTA_PULSE_DURATION_MASK;
- hotplug |= DIGITAL_PORTA_HOTPLUG_ENABLE |
DIGITAL_PORTA_PULSE_DURATION_2ms;
- I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, hotplug);
+ ilk_hpd_detec
[Intel-gfx] [PATCH 0/4] drm/i915/lspcon: Fix resume time init due to low HPD
This patchset attempts to fix the sporadic LSPCON resume time failures reported by CI. The first two patches are the actual fix (for stable) the other two is cleanup and refactoring. Cc: Shashank Sharma Cc: Jani Nikula Cc: Ville Syrjälä Cc: Daniel Vetter Imre Deak (4): drm/i915/gen9+: Enable hotplug detection early drm/i915/lspcon: Fix resume time initialization due to unasserted HPD drm/i915/lspcon: Remove DPCD compare based resume time workaround drm/i915/gen5+,pch: Enable hotplug detection early drivers/gpu/drm/i915/i915_irq.c | 146 drivers/gpu/drm/i915/intel_dp.c | 4 +- drivers/gpu/drm/i915/intel_drv.h| 3 +- drivers/gpu/drm/i915/intel_lspcon.c | 18 + 4 files changed, 107 insertions(+), 64 deletions(-) -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/color: un-inline drm_color_lut_extract()
Hi Jani,
Looks good to me :
Reviewed-by: Lionel Landwerlin
On 23/01/17 09:42, Jani Nikula wrote:
The function is not that big, but it's also not used for anything
performance critical. Make it a normal function.
As a side effect, this apparently makes sparse smarter about what it's
doing, and gets rid of the warning:
./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for
type unsigned long
./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
constant value (8000 becomes 0)
Cc: Lionel Landwerlin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_color_mgmt.c | 24
include/drm/drm_color_mgmt.h | 27 ++-
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 789b4c65cd69..5618f60c7690 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -88,6 +88,30 @@
*/
/**
+ * drm_color_lut_extract - clamp&round LUT entries
+ * @user_input: input value
+ * @bit_precision: number of bits the hw LUT supports
+ *
+ * Extract a degamma/gamma LUT value provided by user (in the form of
+ * &drm_color_lut entries) and round it to the precision supported by the
+ * hardware.
+ */
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (16 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 16) {
+ val += 1UL << (16 - bit_precision - 1);
+ val >>= 16 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract);
+
+/**
* drm_crtc_enable_color_mgmt - enable color management properties
* @crtc: DRM CRTC
* @degamma_lut_size: the size of the degamma lut (before CSC)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index c767238ac9d5..bce4a532836d 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -25,6 +25,8 @@
#include
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
+
void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
uint degamma_lut_size,
bool has_ctm,
@@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-/**
- * drm_color_lut_extract - clamp&round LUT entries
- * @user_input: input value
- * @bit_precision: number of bits the hw LUT supports
- *
- * Extract a degamma/gamma LUT value provided by user (in the form of
- * &drm_color_lut entries) and round it to the precision supported by the
- * hardware.
- */
-static inline uint32_t drm_color_lut_extract(uint32_t user_input,
-uint32_t bit_precision)
-{
- uint32_t val = user_input;
- uint32_t max = 0x >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
-}
-
-
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake pipe CSC (rev2)
== Series Details == Series: Geminilake pipe CSC (rev2) URL : https://patchwork.freedesktop.org/series/18596/ State : success == Summary == Series 18596v2 Geminilake pipe CSC https://patchwork.freedesktop.org/api/1.0/series/18596/revisions/2/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:79 pass:66 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 66c972ab613b1f1d659f413f850047077f3363f0 drm-tip: 2017y-01m-27d-08h-06m-49s UTC integration manifest 40b3da38 drm/i915: Merge BDW pipe gamma and degamma table code 28b9d12 drm/i915/glk: Enable pipe CSC 81389e6 drm/i915/glk: Program pipe gamma and degamma tables 4a0d57f drm/i915: Split broadwell_load_luts() into smaller functions 446ac15 drm/i915/glk: Plane color correction register changes 9a2501c drm/i915: Disable plane gamma in SKL+ sprite planes == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3619/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Thu, 26 Jan 2017, Pierre-Louis Bossart
wrote:
> Enable chicken bit on LPE mode setup and unmute amp on
> notification
>
> FIXME: should these two phases done somewhere else?
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/gpu/drm/i915/i915_reg.h| 12
> drivers/gpu/drm/i915/intel_lpe_audio.c | 27 +++
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a9ffc8d..ee90f64 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2061,6 +2061,18 @@ enum skl_disp_power_wells {
> #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
> #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
>
> +/* DisplayPort Audio w/ LPE */
> +#define CHICKEN_BIT_DBG_ENABLE (1 << 0)
> +#define AMP_UNMUTE (1 << 1)
The convention is to define registers first and the contents/bits for
each register immedialy below. For groups of registers (like
PORT_EN_B/C/D below) define all registers first and bits immediately
below. (But note that the chicken register is not part of the group.)
> +#define AUD_CHICKEN_BIT_REG 0x62F38
> +#define AUD_PORT_EN_B_DBG0x62F20
> +#define AUD_PORT_EN_C_DBG0x62F28
> +#define AUD_PORT_EN_D_DBG0x62F2C
Please don't define these separately without the display base, use
(VLV_DISPLAY_BASE + 0x62f38) style instead. All the other uses of
VLV_DISPLAY_BASE in the file follow the same convention.
> +#define VLV_AUD_CHICKEN_BIT_REG _MMIO(VLV_DISPLAY_BASE +
> AUD_CHICKEN_BIT_REG)
> +#define VLV_AUD_PORT_EN_B_DBG_MMIO(VLV_DISPLAY_BASE +
> AUD_PORT_EN_B_DBG)
> +#define VLV_AUD_PORT_EN_C_DBG_MMIO(VLV_DISPLAY_BASE +
> AUD_PORT_EN_C_DBG)
> +#define VLV_AUD_PORT_EN_D_DBG_MMIO(VLV_DISPLAY_BASE +
> AUD_PORT_EN_D_DBG)
> +
Would be nice to have a macro VLV_AUD_PORT_EN_DBG(port), but damn those
reg offsets don't make it easy...
> #define GEN6_BSD_RNCID _MMIO(0x12198)
>
> #define GEN7_FF_THREAD_MODE _MMIO(0x20a0)
> diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
> b/drivers/gpu/drm/i915/intel_lpe_audio.c
> index 245523e..b3134ef 100644
> --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> @@ -248,6 +248,15 @@ static int lpe_audio_setup(struct drm_i915_private
> *dev_priv)
> goto err_free_irq;
> }
>
> + /* Enable DPAudio debug bits by default */
> + if (IS_CHERRYVIEW(dev_priv)) {
> + u32 chicken_bit;
> +
> + chicken_bit = I915_READ(VLV_AUD_CHICKEN_BIT_REG);
> + I915_WRITE(VLV_AUD_CHICKEN_BIT_REG,
> +chicken_bit | CHICKEN_BIT_DBG_ENABLE);
> + }
> +
> return 0;
> err_free_irq:
> irq_free_desc(dev_priv->lpe_audio.irq);
> @@ -357,6 +366,24 @@ void intel_lpe_audio_notify(struct drm_i915_private
> *dev_priv,
> pdata->tmds_clock_speed = tmds_clk_speed;
> if (link_rate)
> pdata->link_rate = link_rate;
> +
> + if (dp_output) { /* unmute the amp */
> + u32 audio_enable;
> +
> + if (port == PORT_B) {
> + audio_enable = I915_READ(VLV_AUD_PORT_EN_B_DBG);
> + I915_WRITE(VLV_AUD_PORT_EN_B_DBG,
> +audio_enable & ~AMP_UNMUTE);
> + } else if (port == PORT_C) {
> + audio_enable = I915_READ(VLV_AUD_PORT_EN_C_DBG);
> + I915_WRITE(VLV_AUD_PORT_EN_C_DBG,
> +audio_enable & ~AMP_UNMUTE);
> + } else if (port == PORT_D) {
> + audio_enable = I915_READ(VLV_AUD_PORT_EN_D_DBG);
> + I915_WRITE(VLV_AUD_PORT_EN_D_DBG,
> +audio_enable & ~AMP_UNMUTE);
> + }
> + }
> } else {
> memset(pdata->eld.eld_data, 0,
> HDMI_MAX_ELD_BYTES);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Record more information about the hanging contexts
Include extra information such as the user_handle and hw_id so that
userspace can identify which of their contexts hung, useful if they are
performing self-diagnositics.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 14 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 77 ++-
2 files changed, 59 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1c5145d0e53d..d0a48cceb15b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -970,6 +970,16 @@ struct drm_i915_error_state {
u32 semaphore_mboxes[I915_NUM_ENGINES - 1];
struct intel_instdone instdone;
+ struct drm_i915_error_context {
+ char comm[TASK_COMM_LEN];
+ int pid;
+ u32 handle;
+ u32 hw_id;
+ int ban_score;
+ int active;
+ int guilty;
+ } context;
+
struct drm_i915_error_object {
u64 gtt_offset;
u64 gtt_size;
@@ -1006,10 +1016,6 @@ struct drm_i915_error_state {
u32 pp_dir_base;
};
} vm_info;
-
- pid_t pid;
- char comm[TASK_COMM_LEN];
- int context_bans;
} engine[I915_NUM_ENGINES];
struct drm_i915_error_buffer {
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 5c8531baeb34..3b82339c2315 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -384,6 +384,15 @@ static void error_print_request(struct
drm_i915_error_state_buf *m,
erq->head, erq->tail);
}
+static void error_print_context(struct drm_i915_error_state_buf *m,
+ const char *header,
+ struct drm_i915_error_context *ctx)
+{
+ err_printf(m, "%s%s[%d] user_handle %d hw_id %d, ban score %d guilty %d
active %d\n",
+ header, ctx->comm, ctx->pid, ctx->handle, ctx->hw_id,
+ ctx->ban_score, ctx->guilty, ctx->active);
+}
+
static void error_print_engine(struct drm_i915_error_state_buf *m,
struct drm_i915_error_engine *ee)
{
@@ -457,6 +466,7 @@ static void error_print_engine(struct
drm_i915_error_state_buf *m,
error_print_request(m, " ELSP[0]: ", &ee->execlist[0]);
error_print_request(m, " ELSP[1]: ", &ee->execlist[1]);
+ error_print_context(m, " Active context: ", &ee->context);
}
void i915_error_printf(struct drm_i915_error_state_buf *e, const char *f, ...)
@@ -562,12 +572,12 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
for (i = 0; i < ARRAY_SIZE(error->engine); i++) {
if (error->engine[i].hangcheck_stalled &&
- error->engine[i].pid != -1) {
- err_printf(m, "Active process (on ring %s): %s [%d],
context bans %d\n",
+ error->engine[i].context.pid) {
+ err_printf(m, "Active process (on ring %s): %s [%d],
score %d\n",
engine_str(i),
- error->engine[i].comm,
- error->engine[i].pid,
- error->engine[i].context_bans);
+ error->engine[i].context.comm,
+ error->engine[i].context.pid,
+ error->engine[i].context.ban_score);
}
}
err_printf(m, "Reset count: %u\n", error->reset_count);
@@ -658,11 +668,13 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
obj = ee->batchbuffer;
if (obj) {
err_puts(m, dev_priv->engine[i]->name);
- if (ee->pid != -1)
- err_printf(m, " (submitted by %s [%d], bans
%d)",
- ee->comm,
- ee->pid,
- ee->context_bans);
+ if (ee->context.pid)
+ err_printf(m, " (submitted by %s [%d], ctx %d
[%d], score %d)",
+ ee->context.comm,
+ ee->context.pid,
+ ee->context.handle,
+ ee->context.hw_id,
+ ee->context.ban_score);
err_printf(m, " --- gtt_offset = 0x%08x %08x\n",
upper_32_bits(obj->gtt_offset),
Re: [Intel-gfx] [RFC PATCH 0/5] DisplayPort Audio on Cherrytrail
On Thu, 26 Jan 2017 21:05:36 +0100, Pierre-Louis Bossart wrote: > > The following patches enable DisplayPort Audio on Cherrytrail machines > when applied on top of Takashi's topic/intel-lpe-audio branch (tested > on Zotac PI330) > > There are a couple of opens where I could use some help: > - is it necessary to set a valid_bit which is used only for DP audio? > - is the sequence to set the chicken bits and unmute the amplifier ok or > can it be improved by being moved somewhere else in the i915 driver? > - the register offset to be used by the audio driver depends on a > combination of port/pipe/output type. Do we need to get access to the > pipe information and when is it available (initial trials showed the > pipe is still invalid when the audio notification happens) > > Feedback welcome! This makes indeed the audio on DP1 working on Dell Wyse 3040. But the output on DP3 is still broken. Now the transfer stalls. No wonder, as you changed the config base to A from C. I could make the config base changing per pipe, and now the stream flows on DP3, too. Alas, still no audio out. I'll send out my patchset on top of yours. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken DPMS with DisplayPort on CHV (also BYT?)
On Thu, 26 Jan 2017 15:19:44 +0100,
Takashi Iwai wrote:
>
> On Thu, 26 Jan 2017 14:58:55 +0100,
> Ville Syrjälä wrote:
> >
> > Hmm. Have you tried 9f2bdb006a7e ("drm/i915: Prevent PPS stealing
> > from a normal DP port on VLV/CHV") ?
>
> No, it's not tested. I'll prepare a test kernel with it.
Sridhara reported that my backport didn't help, unfortunately.
But it was a backport, so I might have missed something.
To be sure, I'll try to build a kernel from drm-intel-nightly, and let
them test again.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RFC 3/3] ALSA: x86: Use config base depending on the pipe
Now the pipe that is being used is passed over i915 notification, we
can re-setup the had_config_offset depending on it at the hotplug.
This allows, at least, the stream transfer on the second DP working on
Dell Wyse 3040 box here (although it's still not audible by other
reasons).
Signed-off-by: Takashi Iwai
---
sound/x86/intel_hdmi_lpe_audio.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c
index 23e5b34dcf41..55bc2cfd21c4 100644
--- a/sound/x86/intel_hdmi_lpe_audio.c
+++ b/sound/x86/intel_hdmi_lpe_audio.c
@@ -463,6 +463,22 @@ static void notify_audio_lpe(void *audio_ptr)
} else if (eld != NULL) {
+ switch (eld->pipe_id) {
+ case 0:
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
+ break;
+ case 1:
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_B;
+ break;
+ case 2:
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
+ break;
+ default:
+ dev_dbg(&hlpe_pdev->dev, "Invalid pipe %d\n",
+ eld->pipe_id);
+ break;
+ }
+
hdmi_set_eld(eld->eld_data);
mid_hdmi_audio_signal_event(HAD_EVENT_HOT_PLUG);
@@ -560,21 +576,15 @@ static int hdmi_lpe_audio_probe(struct platform_device
*pdev)
ctx->mmio_start = mmio_start;
ctx->tmds_clock_speed = DIS_SAMPLE_RATE_148_5;
- if (pci_dev_present(cherryview_ids)) {
+ if (pci_dev_present(cherryview_ids))
dev_dbg(&hlpe_pdev->dev, "%s: Cherrytrail LPE - Detected\n",
__func__);
- //ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
- /* FIXME: hard-coding to CONFIG_A enables DP audio on CHT,
-* how do I find out which config to use ?
-* the pipe is -1 (invalid) when the notify function is called,
-* so not sure how to go about this
-*/
- ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
- } else {
+ else
dev_dbg(&hlpe_pdev->dev, "%s: Baytrail LPE - Assume\n",
__func__);
- ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
- }
+
+ /* assume pipe A as default */
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
pdata = pdev->dev.platform_data;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RFC 0/3] Pass pipe to LPE audio
Hi,
this is a patch series to pass the pipe over LPE audio notification,
based on Pierre's latest patchset ("[RFC PATCH 0/5] DisplayPort Audio
on Cherrytrail").
Takashi
===
Takashi Iwai (3):
drm/i915: Avoid MST pipe handling for LPE audio
drm/i915: Pass pipe to LPE audio notification
ALSA: x86: Use config base depending on the pipe
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/intel_audio.c | 27 ++-
drivers/gpu/drm/i915/intel_lpe_audio.c | 3 ++-
include/drm/intel_lpe_audio.h | 1 +
sound/x86/intel_hdmi_lpe_audio.c | 32 +---
5 files changed, 39 insertions(+), 26 deletions(-)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RFC 2/3] drm/i915: Pass pipe to LPE audio notification
The LPE audio configuration depends on the pipe, thus we need to pass
the currently used pipe. It's now embedded in struct
intel_hdmi_lpe_audio_eld as well as port id.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/intel_audio.c | 6 +++---
drivers/gpu/drm/i915/intel_lpe_audio.c | 3 ++-
include/drm/intel_lpe_audio.h | 1 +
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1c7aa8fcd0fa..1c56c5832735 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3400,7 +3400,7 @@ int intel_lpe_audio_init(struct drm_i915_private
*dev_priv);
void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
- void *eld, int port, int tmds_clk_speed,
+ void *eld, int port, int pipe, int tmds_clk_speed,
bool dp_output, int link_rate);
/* intel_i2c.c */
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index d4e6d1136cfe..892169b7952b 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -634,12 +634,12 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder,
switch (intel_encoder->type) {
case INTEL_OUTPUT_HDMI:
- intel_lpe_audio_notify(dev_priv, connector->eld, port,
+ intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
crtc_state->port_clock,
false, 0);
break;
case INTEL_OUTPUT_DP:
- intel_lpe_audio_notify(dev_priv, connector->eld, port,
+ intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
adjusted_mode->crtc_clock,
true, crtc_state->port_clock);
break;
@@ -680,7 +680,7 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
(int) port, (int) pipe);
}
- intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
+ intel_lpe_audio_notify(dev_priv, NULL, port, pipe, 0, false, 0);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index b3134efdcf82..62bc3c6456e4 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -341,7 +341,7 @@ void intel_lpe_audio_teardown(struct drm_i915_private
*dev_priv)
* Notify lpe audio driver of eld change.
*/
void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
- void *eld, int port, int tmds_clk_speed,
+ void *eld, int port, int pipe, int tmds_clk_speed,
bool dp_output, int link_rate)
{
unsigned long irq_flags;
@@ -359,6 +359,7 @@ void intel_lpe_audio_notify(struct drm_i915_private
*dev_priv,
memcpy(pdata->eld.eld_data, eld,
HDMI_MAX_ELD_BYTES);
pdata->eld.port_id = port;
+ pdata->eld.pipe_id = pipe;
pdata->hdmi_connected = true;
pdata->dp_output = dp_output;
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index 857e0eafed79..410128e4cd70 100644
--- a/include/drm/intel_lpe_audio.h
+++ b/include/drm/intel_lpe_audio.h
@@ -31,6 +31,7 @@
struct intel_hdmi_lpe_audio_eld {
int port_id;
+ int pipe_id;
unsigned char eld_data[HDMI_MAX_ELD_BYTES];
};
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RFC 1/3] drm/i915: Avoid MST pipe handling for LPE audio
The pipe gets cleared to -1 for non-MST before the ELD audio
notification due to the MST audio support. This makes sense for
HD-audio that received the MST handling, but it's useless for LPE
audio. Handle the MST pipe hack conditionally only for HD-audio.
Reported-by: Pierre-Louis Bossart
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_audio.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 1645ce42b898..d4e6d1136cfe 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -624,13 +624,14 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder,
dev_priv->av_enc_map[pipe] = intel_encoder;
mutex_unlock(&dev_priv->av_mutex);
- /* audio drivers expect pipe = -1 to indicate Non-MST cases */
- if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
- pipe = -1;
-
- if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+ if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+ /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+ if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+ pipe = -1;
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
+ }
+
switch (intel_encoder->type) {
case INTEL_OUTPUT_HDMI:
intel_lpe_audio_notify(dev_priv, connector->eld, port,
@@ -671,13 +672,13 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
dev_priv->av_enc_map[pipe] = NULL;
mutex_unlock(&dev_priv->av_mutex);
- /* audio drivers expect pipe = -1 to indicate Non-MST cases */
- if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
- pipe = -1;
-
- if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+ if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+ /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+ if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+ pipe = -1;
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
+ }
intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Make uapi/i915_drm.h standalone
In order for us to be able to simply copy our uapi/i915_drm.h into
userspace it must be compilable as-is by userspace. For which we need
to hide the sparse markup for __user. This does impose the limitation
that we include our uapi/i915_drm.h last so that the attribute is
properly defined inside the kernel.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 202790a3e8e2..5b12506683f1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -29,6 +29,11 @@
#include "drm.h"
+/* Disable unused sparse attributes from userspace */
+#ifndef __user
+#define __user
+#endif
+
#if defined(__cplusplus)
extern "C" {
#endif
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/color: un-inline drm_color_lut_extract()
On Fri, 27 Jan 2017, Lionel Landwerlin wrote:
> Hi Jani,
>
> Looks good to me :
>
> Reviewed-by: Lionel Landwerlin
Thanks for the reviews, pushed... to drm-intel-next-queued instead of
drm-misc-next. /o\
Dave, Daniel, please advise, shall I revert or shall we let this flow in
via drm-intel?
Sorry for the mess.
BR,
Jani.
>
> On 23/01/17 09:42, Jani Nikula wrote:
>> The function is not that big, but it's also not used for anything
>> performance critical. Make it a normal function.
>>
>> As a side effect, this apparently makes sparse smarter about what it's
>> doing, and gets rid of the warning:
>>
>> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295)
>> for type unsigned long
>> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
>> constant value (8000 becomes 0)
>>
>> Cc: Lionel Landwerlin
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_color_mgmt.c | 24
>> include/drm/drm_color_mgmt.h | 27 ++-
>> 2 files changed, 26 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>> b/drivers/gpu/drm/drm_color_mgmt.c
>> index 789b4c65cd69..5618f60c7690 100644
>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>> @@ -88,6 +88,30 @@
>>*/
>>
>> /**
>> + * drm_color_lut_extract - clamp&round LUT entries
>> + * @user_input: input value
>> + * @bit_precision: number of bits the hw LUT supports
>> + *
>> + * Extract a degamma/gamma LUT value provided by user (in the form of
>> + * &drm_color_lut entries) and round it to the precision supported by the
>> + * hardware.
>> + */
>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
>> +{
>> +uint32_t val = user_input;
>> +uint32_t max = 0x >> (16 - bit_precision);
>> +
>> +/* Round only if we're not using full precision. */
>> +if (bit_precision < 16) {
>> +val += 1UL << (16 - bit_precision - 1);
>> +val >>= 16 - bit_precision;
>> +}
>> +
>> +return clamp_val(val, 0, max);
>> +}
>> +EXPORT_SYMBOL(drm_color_lut_extract);
>> +
>> +/**
>>* drm_crtc_enable_color_mgmt - enable color management properties
>>* @crtc: DRM CRTC
>>* @degamma_lut_size: the size of the degamma lut (before CSC)
>> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
>> index c767238ac9d5..bce4a532836d 100644
>> --- a/include/drm/drm_color_mgmt.h
>> +++ b/include/drm/drm_color_mgmt.h
>> @@ -25,6 +25,8 @@
>>
>> #include
>>
>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
>> +
>> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> uint degamma_lut_size,
>> bool has_ctm,
>> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>> int gamma_size);
>>
>> -/**
>> - * drm_color_lut_extract - clamp&round LUT entries
>> - * @user_input: input value
>> - * @bit_precision: number of bits the hw LUT supports
>> - *
>> - * Extract a degamma/gamma LUT value provided by user (in the form of
>> - * &drm_color_lut entries) and round it to the precision supported by the
>> - * hardware.
>> - */
>> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
>> - uint32_t bit_precision)
>> -{
>> -uint32_t val = user_input;
>> -uint32_t max = 0x >> (16 - bit_precision);
>> -
>> -/* Round only if we're not using full precision. */
>> -if (bit_precision < 16) {
>> -val += 1UL << (16 - bit_precision - 1);
>> -val >>= 16 - bit_precision;
>> -}
>> -
>> -return clamp_val(val, 0, max);
>> -}
>> -
>> -
>> #endif
>
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH libdrm 2/3] intel: Allow the client to control implicit synchronisation
The kernel allows implicit synchronisation to be disabled on individual
buffers. Use at your own risk.
Signed-off-by: Chris Wilson
---
intel/intel_bufmgr.h | 4
intel/intel_bufmgr_gem.c | 49
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 85e4ff78..f43ee470 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -184,6 +184,10 @@ int drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo);
int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo);
int drm_intel_gem_bo_unmap_gtt(drm_intel_bo *bo);
+#define HAVE_DRM_INTEL_GEM_BO_DISABLE_IMPLICIT_SYNC 1
+int drm_intel_bufmgr_gem_can_disable_implicit_sync(drm_intel_bufmgr *bufmgr);
+void drm_intel_gem_bo_disable_implicit_sync(drm_intel_bo *bo);
+
void *drm_intel_gem_bo_map__cpu(drm_intel_bo *bo);
void *drm_intel_gem_bo_map__gtt(drm_intel_bo *bo);
void *drm_intel_gem_bo_map__wc(drm_intel_bo *bo);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index c47cb9b2..554d079b 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -149,6 +149,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int bo_reuse : 1;
unsigned int no_exec : 1;
unsigned int has_vebox : 1;
+ unsigned int has_exec_async : 1;
bool fenced_relocs;
struct {
@@ -195,6 +196,8 @@ struct _drm_intel_bo_gem {
uint32_t swizzle_mode;
unsigned long stride;
+ unsigned long kflags;
+
time_t free_time;
/** Array passed to the DRM containing relocation information. */
@@ -575,12 +578,11 @@ drm_intel_add_validate_buffer2(drm_intel_bo *bo, int
need_fence)
bufmgr_gem->exec2_objects[index].relocation_count = bo_gem->reloc_count;
bufmgr_gem->exec2_objects[index].relocs_ptr = (uintptr_t)bo_gem->relocs;
bufmgr_gem->exec2_objects[index].alignment = bo->align;
- bufmgr_gem->exec2_objects[index].offset = bo_gem->is_softpin ?
- bo->offset64 : 0;
- bufmgr_gem->exec_bos[index] = bo;
- bufmgr_gem->exec2_objects[index].flags = flags;
+ bufmgr_gem->exec2_objects[index].offset = bo->offset64;
+ bufmgr_gem->exec2_objects[index].flags = flags | bo_gem->kflags;
bufmgr_gem->exec2_objects[index].rsvd1 = 0;
bufmgr_gem->exec2_objects[index].rsvd2 = 0;
+ bufmgr_gem->exec_bos[index] = bo;
bufmgr_gem->exec_count++;
}
@@ -1368,6 +1370,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo,
time_t time)
for (i = 0; i < bo_gem->softpin_target_count; i++)
drm_intel_gem_bo_unreference_locked_timed(bo_gem->softpin_target[i],
time);
+ bo_gem->kflags = 0;
bo_gem->reloc_count = 0;
bo_gem->used_as_reloc_target = false;
bo_gem->softpin_target_count = 0;
@@ -2766,6 +2769,40 @@ drm_intel_bufmgr_gem_enable_reuse(drm_intel_bufmgr
*bufmgr)
}
/**
+ * Disables implicit synchronisation before executing the bo
+ *
+ * This will cause rendering corruption unless you correctly manage explicit
+ * fences for all rendering involving this buffer - including use by others.
+ * Disabling the implicit serialisation is only required if that serialisation
+ * is too coarse (for example, you have split the buffer into many
+ * non-overlapping regions and are sharing the whole buffer between concurrent
+ * independent command streams).
+ *
+ * Note the kernel must advertise support via I915_PARAM_HAS_EXEC_ASYNC,
+ * which can be checked using drm_intel_bufmgr_can_disable_implicit_sync,
+ * or subsequent execbufs involving the bo will generate EINVAL.
+ */
+void
+drm_intel_gem_bo_disable_implicit_sync(drm_intel_bo *bo)
+{
+ drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+
+ bo_gem->kflags |= EXEC_OBJECT_ASYNC;
+}
+
+/**
+ * Query whether the kernel supports disabling of its implicit synchronisation
+ * before execbuf. See drm_intel_gem_bo_disable_implicit_sync()
+ */
+int
+drm_intel_bufmgr_gem_can_disable_implicit_sync(drm_intel_bufmgr *bufmgr)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
+
+ return bufmgr_gem->has_exec_async;
+}
+
+/**
* Enable use of fenced reloc type.
*
* New code should enable this to avoid unnecessary fence register
@@ -3635,6 +3672,10 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
bufmgr_gem->has_relaxed_fencing = ret == 0;
+ gp.param = I915_PARAM_HAS_EXEC_ASYNC;
+ ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
+ bufmgr_gem->has_exec_async = ret == 0;
+
bufmgr_gem->bufmgr.bo_alloc_userptr = check_bo_alloc_userptr;
gp.param = I915_PARAM_HAS_WAIT_TIMEOUT;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://l
[Intel-gfx] [PATCH libdrm 1/3] Import uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9
---
include/drm/i915_drm.h | 298 +
1 file changed, 279 insertions(+), 19 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index eb611a7a..e0ab500e 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -24,11 +24,19 @@
*
*/
-#ifndef _I915_DRM_H_
-#define _I915_DRM_H_
+#ifndef _UAPI_I915_DRM_H_
+#define _UAPI_I915_DRM_H_
#include "drm.h"
+#ifndef __user
+#define __user
+#endif
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
/* Please note that modifications to all structs defined here are
* subject to backwards-compatibility constraints.
*/
@@ -58,6 +66,30 @@
#define I915_ERROR_UEVENT "ERROR"
#define I915_RESET_UEVENT "RESET"
+/*
+ * MOCS indexes used for GPU surfaces, defining the cacheability of the
+ * surface data and the coherency for this data wrt. CPU vs. GPU accesses.
+ */
+enum i915_mocs_table_index {
+ /*
+* Not cached anywhere, coherency between CPU and GPU accesses is
+* guaranteed.
+*/
+ I915_MOCS_UNCACHED,
+ /*
+* Cacheability and coherency controlled by the kernel automatically
+* based on the DRM_I915_GEM_SET_CACHING IOCTL setting and the current
+* usage of the surface (used for display scanout or not).
+*/
+ I915_MOCS_PTE,
+ /*
+* Cached in all GPU caches available on the platform.
+* Coherency between CPU and GPU accesses to the surface is not
+* guaranteed without extra synchronization.
+*/
+ I915_MOCS_CACHED,
+};
+
/* Each region is a minimum of 16k, and there are at most 255 of them.
*/
#define I915_NR_TEX_REGIONS 255/* table size 2k - maximum due to use
@@ -218,6 +250,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_OVERLAY_PUT_IMAGE 0x27
#define DRM_I915_OVERLAY_ATTRS 0x28
#define DRM_I915_GEM_EXECBUFFER2 0x29
+#define DRM_I915_GEM_EXECBUFFER2_WRDRM_I915_GEM_EXECBUFFER2
#define DRM_I915_GET_SPRITE_COLORKEY 0x2a
#define DRM_I915_SET_SPRITE_COLORKEY 0x2b
#define DRM_I915_GEM_WAIT 0x2c
@@ -230,6 +263,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_USERPTR 0x33
#define DRM_I915_GEM_CONTEXT_GETPARAM 0x34
#define DRM_I915_GEM_CONTEXT_SETPARAM 0x35
+#define DRM_I915_PERF_OPEN 0x36
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -251,6 +285,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_INITDRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_INIT, struct drm_i915_gem_init)
#define DRM_IOCTL_I915_GEM_EXECBUFFER DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER, struct drm_i915_gem_execbuffer)
#define DRM_IOCTL_I915_GEM_EXECBUFFER2 DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER2, struct drm_i915_gem_execbuffer2)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER2_WR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER2_WR, struct drm_i915_gem_execbuffer2)
#define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
#define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
#define DRM_IOCTL_I915_GEM_BUSYDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
@@ -283,6 +318,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
#define DRM_IOCTL_I915_GEM_CONTEXT_GETPARAMDRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_GETPARAM, struct drm_i915_gem_context_param)
#define DRM_IOCTL_I915_GEM_CONTEXT_SETPARAMDRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_SETPARAM, struct drm_i915_gem_context_param)
+#define DRM_IOCTL_I915_PERF_OPEN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -293,25 +329,25 @@ typedef struct drm_i915_batchbuffer {
int DR1;/* hw flags for GFX_OP_DRAWRECT_INFO */
int DR4;/* window origin for GFX_OP_DRAWRECT_INFO */
int num_cliprects; /* mulitpass with multiple cliprects? */
- struct drm_clip_rect *cliprects;/* pointer to userspace
cliprects */
+ struct drm_clip_rect __user *cliprects; /* pointer to userspace
cliprects */
} drm_i915_batchbuffer_t;
/* As above, but pass a pointer to userspace buffer which can be
* validated by the kernel prior to sending to hardware.
*/
typedef struct _drm_i915_cmdbuffer {
- char *buf; /* pointer to userspace command buffer */
+ char __user *buf; /* pointer to userspace command buffer */
[Intel-gfx] [PATCH libdrm 3/3] intel: Support passing of explicit fencing from execbuf
Allow the caller to pass in an fd to an array of fences to control
serialisation of the execbuf in the kernel and on the GPU, and in return
allow creation of a fence fd for signaling the completion (and flushing)
of the batch. When the returned fence is signaled, all writes to the
buffers inside the batch will be complete and coherent from the cpu, or
other consumers. The return fence is a sync_file object and can be
passed to other users (such as atomic modesetting, or other drivers).
Signed-off-by: Chris Wilson
---
intel/intel_bufmgr.h | 6 ++
intel/intel_bufmgr_gem.c | 31 +++
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index f43ee470..11579fbc 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -221,6 +221,12 @@ int drm_intel_gem_context_get_id(drm_intel_context *ctx,
void drm_intel_gem_context_destroy(drm_intel_context *ctx);
int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
int used, unsigned int flags);
+int drm_intel_gem_bo_fence_exec(drm_intel_bo *bo,
+ drm_intel_context *ctx,
+ int used,
+ int in_fence,
+ int *out_fence,
+ unsigned int flags);
int drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int *prime_fd);
drm_intel_bo *drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr *bufmgr,
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 554d079b..9195f3e6 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -2376,6 +2376,7 @@ drm_intel_gem_bo_exec(drm_intel_bo *bo, int used,
static int
do_exec2(drm_intel_bo *bo, int used, drm_intel_context *ctx,
drm_clip_rect_t *cliprects, int num_cliprects, int DR4,
+int in_fence, int *out_fence,
unsigned int flags)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo->bufmgr;
@@ -2430,12 +2431,20 @@ do_exec2(drm_intel_bo *bo, int used, drm_intel_context
*ctx,
else
i915_execbuffer2_set_context_id(execbuf, ctx->ctx_id);
execbuf.rsvd2 = 0;
+ if (in_fence != -1) {
+ execbuf.rsvd2 = in_fence;
+ execbuf.flags |= I915_EXEC_FENCE_IN;
+ }
+ if (out_fence != NULL) {
+ *out_fence = -1;
+ execbuf.flags |= I915_EXEC_FENCE_OUT;
+ }
if (bufmgr_gem->no_exec)
goto skip_execution;
ret = drmIoctl(bufmgr_gem->fd,
- DRM_IOCTL_I915_GEM_EXECBUFFER2,
+ DRM_IOCTL_I915_GEM_EXECBUFFER2_WR,
&execbuf);
if (ret != 0) {
ret = -errno;
@@ -2451,6 +2460,9 @@ do_exec2(drm_intel_bo *bo, int used, drm_intel_context
*ctx,
}
drm_intel_update_buffer_offsets2(bufmgr_gem);
+ if (ret == 0 && out_fence != NULL)
+ *out_fence = execbuf.rsvd2 >> 32;
+
skip_execution:
if (bufmgr_gem->bufmgr.debug)
drm_intel_gem_dump_validation_list(bufmgr_gem);
@@ -2476,7 +2488,7 @@ drm_intel_gem_bo_exec2(drm_intel_bo *bo, int used,
int DR4)
{
return do_exec2(bo, used, NULL, cliprects, num_cliprects, DR4,
- I915_EXEC_RENDER);
+ -1, NULL, I915_EXEC_RENDER);
}
static int
@@ -2485,14 +2497,25 @@ drm_intel_gem_bo_mrb_exec2(drm_intel_bo *bo, int used,
unsigned int flags)
{
return do_exec2(bo, used, NULL, cliprects, num_cliprects, DR4,
- flags);
+ -1, NULL, flags);
}
int
drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
int used, unsigned int flags)
{
- return do_exec2(bo, used, ctx, NULL, 0, 0, flags);
+ return do_exec2(bo, used, ctx, NULL, 0, 0, -1, NULL, flags);
+}
+
+int
+drm_intel_gem_bo_fence_exec(drm_intel_bo *bo,
+ drm_intel_context *ctx,
+ int used,
+ int in_fence,
+ int *out_fence,
+ unsigned int flags)
+{
+ return do_exec2(bo, used, ctx, NULL, 0, 0, in_fence, out_fence, flags);
}
static int
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lspcon: Fix resume time init due to low HPD
== Series Details == Series: drm/i915/lspcon: Fix resume time init due to low HPD URL : https://patchwork.freedesktop.org/series/18656/ State : success == Summary == Series 18656v1 drm/i915/lspcon: Fix resume time init due to low HPD https://patchwork.freedesktop.org/api/1.0/series/18656/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:79 pass:66 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 93cbdef9696bcaa1279ae05c418b2794b71c2398 drm-tip: 2017y-01m-27d-09h-55m-16s UTC integration manifest 910551d drm/i915/gen5+, pch: Enable hotplug detection early 4fbb08f drm/i915/lspcon: Remove DPCD compare based resume time workaround bd5876e drm/i915/lspcon: Fix resume time initialization due to unasserted HPD d4c554d drm/i915/gen9+: Enable hotplug detection early == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3620/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/13] i2c: designware-baytrail: Acquire P-Unit access on bus acquire
On 01/23/2017 11:09 PM, Hans de Goede wrote: Acquire P-Unit access to stop others from accessing the P-Unit while the PMIC i2c bus is in use. This is necessary because accessing the P-Unit from the kernel may result in the P-Unit trying to access the PMIC i2c bus, which results in a hang when it happens while we own the PMIC i2c bus semaphore. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede Tested-by: tagorereddy Acked-by: Wolfram Sang --- Changes in v2: -Spelling: P-Unit, PMIC -Adjust for iosf_mbi_punit_lock/_unlock to _acquire/_release rename --- drivers/i2c/busses/i2c-designware-baytrail.c | 4 1 file changed, 4 insertions(+) Acked-by: Jarkko Nikula ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/13] i2c: designware-baytrail: Call pmic_bus_access_notifier_chain
On 01/23/2017 11:09 PM, Hans de Goede wrote: Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede Tested-by: tagorereddy Reviewed-by: Andy Shevchenko Acked-by: Wolfram Sang --- Changes in v2: -Spelling: P-Unit, PMIC --- drivers/i2c/busses/i2c-designware-baytrail.c | 4 1 file changed, 4 insertions(+) Acked-by: Jarkko Nikula ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Enable userspace to opt-out of implicit fencing
== Series Details == Series: series starting with [CI,1/2] drm/i915: Enable userspace to opt-out of implicit fencing URL : https://patchwork.freedesktop.org/series/18657/ State : failure == Summary == Series 18657v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/18657/revisions/1/mbox/ Test gem_busy: Subgroup basic-hang-default: pass -> FAIL (fi-hsw-4770r) fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:79 pass:66 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:227 dwarn:0 dfail:0 fail:1 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 93cbdef9696bcaa1279ae05c418b2794b71c2398 drm-tip: 2017y-01m-27d-09h-55m-16s UTC integration manifest 7996b0a drm/i915: Support explicit fencing for execbuf ef85029 drm/i915: Enable userspace to opt-out of implicit fencing == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3621/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/8] Tracepoints cleanup and improvements for requests
From: Tvrtko Ursulin During some performance analysis I have noticed that currently our trace points are in a bit of a mess, especially the ones relating to requests. This series attempts to tidy some of that and also adds some new trace points. These new trace points are usable to analyze the engine utilization and also look at how the scheduler resolves dependencies and fences, how much time requests spend being blocked, and so on. With some post-processing the new trace points can be used to generate request and engine timeline graphs like for example the on on this URL: https://people.freedesktop.org/~tursulin/trace-demo.html If people find this interesting we could also merge the post-processing tool to IGT. Although ideally, someone more versed in GUI development could pick up on the general idea an implement something better than the not very scalable or precise JS library I have used to prototype this. Current way of getting to the graphs is essentially: perf record -e -a -c 1 binary-to-be-traced perf script | trace.pl >output.html Tvrtko Tvrtko Ursulin (8): drm/i915/tracepoints: Tidy request event class drm/i915/tracepoints: Adjust i915_gem_ring_dispatch drm/i915/tracepoints: Tidy i915_gem_request_wait_begin drm/i915/tracepoints: Remove unused i915_gem_request_complete drm/i915/tracepoints: Add request submit and execute tracepoints drm/i915/tracepoints: Rename i915_gem_request_notify drm/i915/tracepoints: Add backend level request in and out tracepoints drm/i915/tracepoints: Add hw_id to context tracepoints drivers/gpu/drm/i915/Kconfig.debug | 11 +++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +- drivers/gpu/drm/i915/i915_gem_request.c| 2 + drivers/gpu/drm/i915/i915_guc_submission.c | 2 + drivers/gpu/drm/i915/i915_irq.c| 2 +- drivers/gpu/drm/i915/i915_trace.h | 122 - drivers/gpu/drm/i915/intel_lrc.c | 4 + 7 files changed, 124 insertions(+), 23 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 5/8] drm/i915/tracepoints: Add request submit and execute tracepoints
From: Tvrtko Ursulin
These new tracepoints are emitted once the request is ready to
be submitted to the GPU and once the request is about to
be submitted to the GPU, respectively.
Former condition triggers as soon as all the fences and
dependencies have been resolved, and the latter once the
backend is about to submit it to the GPU.
New tracepoint are enabled via the new
DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option which is disabled
by default to alleviate the performance impact concerns.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Kconfig.debug | 11 +++
drivers/gpu/drm/i915/i915_gem_request.c | 2 ++
drivers/gpu/drm/i915/i915_trace.h | 24
3 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 597648c7a645..4fba5e1356a0 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -58,3 +58,14 @@ config DRM_I915_SW_FENCE_DEBUG_OBJECTS
Recommended for driver developers only.
If in doubt, say "N".
+
+config DRM_I915_LOW_LEVEL_TRACEPOINTS
+bool "Enable low level request tracing events"
+depends on DRM_I915
+default n
+help
+ Choose this option to turn on low level request tracing events.
+ This provides the ability to precisely monitor engine utilisation
+ and also analyze the request dependency resolving timeline.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index 72b7f7d9461d..4a88b8ea01db 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -449,6 +449,7 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
switch (state) {
case FENCE_COMPLETE:
+ trace_i915_gem_request_submit(request);
request->engine->submit_request(request);
break;
@@ -468,6 +469,7 @@ execute_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
switch (state) {
case FENCE_COMPLETE:
+ trace_i915_gem_request_execute(request);
break;
case FENCE_FREE:
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index f08ccac0d959..1fe1417f8c4d 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -582,6 +582,30 @@ DEFINE_EVENT(i915_gem_request, i915_gem_request_add,
TP_ARGS(req)
);
+#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
+DEFINE_EVENT(i915_gem_request, i915_gem_request_submit,
+TP_PROTO(struct drm_i915_gem_request *req),
+TP_ARGS(req)
+);
+
+DEFINE_EVENT(i915_gem_request, i915_gem_request_execute,
+TP_PROTO(struct drm_i915_gem_request *req),
+TP_ARGS(req)
+);
+#else
+#if !defined(TRACE_HEADER_MULTI_READ)
+static inline void
+trace_i915_gem_request_submit(struct drm_i915_gem_request *req)
+{
+}
+
+static inline void
+trace_i915_gem_request_execute(struct drm_i915_gem_request *req)
+{
+}
+#endif
+#endif
+
TRACE_EVENT(i915_gem_request_notify,
TP_PROTO(struct intel_engine_cs *engine),
TP_ARGS(engine),
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/8] drm/i915/tracepoints: Tidy request event class
From: Tvrtko Ursulin
At the moment only the global seqno is logged which is not set
until the request is ready for submission.
Add the per-contex seqno and the context hardware id which are
both interesting data points.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_trace.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 4461df5a94fe..d890e4b03902 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -555,18 +555,23 @@ DECLARE_EVENT_CLASS(i915_gem_request,
TP_STRUCT__entry(
__field(u32, dev)
+__field(u32, ctx)
__field(u32, ring)
__field(u32, seqno)
+__field(u32, global)
),
TP_fast_assign(
__entry->dev = req->i915->drm.primary->index;
+ __entry->ctx = req->ctx->hw_id;
__entry->ring = req->engine->id;
- __entry->seqno = req->global_seqno;
+ __entry->seqno = req->fence.seqno;
+ __entry->global = req->global_seqno;
),
- TP_printk("dev=%u, ring=%u, seqno=%u",
- __entry->dev, __entry->ring, __entry->seqno)
+ TP_printk("dev=%u, ring=%u, ctx=%u, seqno=%u, global=%u",
+ __entry->dev, __entry->ring, __entry->ctx, __entry->seqno,
+ __entry->global)
);
DEFINE_EVENT(i915_gem_request, i915_gem_request_add,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints
From: Tvrtko Ursulin
Two new tracepoints placed at the call sites where requests are
actually passed to the GPU enable userspace to track engine
utilisation.
These tracepoints are only enabled when the
DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option is enabled.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 ++
drivers/gpu/drm/i915/i915_trace.h | 49 ++
drivers/gpu/drm/i915/intel_lrc.c | 4 +++
3 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ced9e26f075..beec88a30347 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -518,6 +518,8 @@ static void __i915_guc_submit(struct drm_i915_gem_request
*rq)
if (i915_vma_is_map_and_fenceable(rq->ring->vma))
POSTING_READ_FW(GUC_STATUS);
+ trace_i915_gem_request_in(rq, 0);
+
b_ret = guc_ring_doorbell(client);
client->submissions[engine_id] += 1;
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index d24b89d0e3ab..18dd21653a80 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -582,6 +582,35 @@ DEFINE_EVENT(i915_gem_request, i915_gem_request_add,
TP_ARGS(req)
);
+DECLARE_EVENT_CLASS(i915_gem_request_hw,
+ TP_PROTO(struct drm_i915_gem_request *req,
+unsigned int port),
+ TP_ARGS(req, port),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u32, ring)
+__field(u32, seqno)
+__field(u32, global_seqno)
+__field(u32, ctx)
+__field(u32, port)
+ ),
+
+ TP_fast_assign(
+ __entry->dev = req->i915->drm.primary->index;
+ __entry->ring = req->engine->id;
+ __entry->ctx = req->ctx->hw_id;
+ __entry->seqno = req->fence.seqno;
+ __entry->global_seqno = req->global_seqno;
+ __entry->port = port;
+ ),
+
+ TP_printk("dev=%u, ring=%u, ctx=%u, seqno=%u,
global_seqno=%u, port=%u",
+ __entry->dev, __entry->ring, __entry->ctx,
+ __entry->seqno, __entry->global_seqno,
+ __entry->port)
+);
+
#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
DEFINE_EVENT(i915_gem_request, i915_gem_request_submit,
TP_PROTO(struct drm_i915_gem_request *req),
@@ -592,6 +621,16 @@ DEFINE_EVENT(i915_gem_request, i915_gem_request_execute,
TP_PROTO(struct drm_i915_gem_request *req),
TP_ARGS(req)
);
+
+DEFINE_EVENT(i915_gem_request_hw, i915_gem_request_in,
+TP_PROTO(struct drm_i915_gem_request *req, unsigned int port),
+TP_ARGS(req, port)
+);
+
+DEFINE_EVENT(i915_gem_request_hw, i915_gem_request_out,
+TP_PROTO(struct drm_i915_gem_request *req, unsigned int port),
+TP_ARGS(req, port)
+);
#else
#if !defined(TRACE_HEADER_MULTI_READ)
static inline void
@@ -603,6 +642,16 @@ static inline void
trace_i915_gem_request_execute(struct drm_i915_gem_request *req)
{
}
+
+static inline void
+trace_i915_gem_request_in(struct drm_i915_gem_request *req, unsigned int port)
+{
+}
+
+static inline void
+trace_i915_gem_request_out(struct drm_i915_gem_request *req, unsigned int port)
+{
+}
#endif
#endif
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bee9d565b8f3..85581a05657b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -505,6 +505,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
cursor->priotree.priority = INT_MAX;
__i915_gem_request_submit(cursor);
+ trace_i915_gem_request_in(cursor, port - engine->execlist_port);
last = cursor;
submit = true;
}
@@ -561,6 +562,7 @@ static void intel_lrc_irq_handler(unsigned long data)
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct execlist_port *port = engine->execlist_port;
struct drm_i915_private *dev_priv = engine->i915;
+ unsigned int portidx = 0;
intel_uncore_forcewake_get(dev_priv, engine->fw_domains);
@@ -597,6 +599,8 @@ static void intel_lrc_irq_handler(unsigned long data)
execlists_context_status_change(port[0].request,
[Intel-gfx] [RFC 3/8] drm/i915/tracepoints: Tidy i915_gem_request_wait_begin
From: Tvrtko Ursulin
Provide the same information as the other request even classes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_trace.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 79162c369812..cbdbe7d6f5ef 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -619,7 +619,9 @@ TRACE_EVENT(i915_gem_request_wait_begin,
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, ring)
+__field(u32, ctx)
__field(u32, seqno)
+__field(u32, global)
__field(bool, blocking)
),
@@ -632,14 +634,16 @@ TRACE_EVENT(i915_gem_request_wait_begin,
TP_fast_assign(
__entry->dev = req->i915->drm.primary->index;
__entry->ring = req->engine->id;
- __entry->seqno = req->global_seqno;
+ __entry->ctx = req->ctx->hw_id;
+ __entry->seqno = req->fence.seqno;
+ __entry->global = req->global_seqno;
__entry->blocking =
mutex_is_locked(&req->i915->drm.struct_mutex);
),
- TP_printk("dev=%u, ring=%u, seqno=%u, blocking=%s",
- __entry->dev, __entry->ring,
- __entry->seqno, __entry->blocking ? "yes (NB)" : "no")
+ TP_printk("dev=%u, ring=%u, ctx=%u, seqno=%u, global=%u,
blocking=%s",
+ __entry->dev, __entry->ring, __entry->ctx, __entry->seqno,
+ __entry->global, __entry->blocking ? "yes (NB)" : "no")
);
DEFINE_EVENT(i915_gem_request, i915_gem_request_wait_end,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 8/8] drm/i915/tracepoints: Add hw_id to context tracepoints
From: Tvrtko Ursulin
It is useful to provide this info to match the one provided
in the request tracepoints.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_trace.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 18dd21653a80..e4b702063aa6 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -849,17 +849,19 @@ DECLARE_EVENT_CLASS(i915_context,
TP_STRUCT__entry(
__field(u32, dev)
__field(struct i915_gem_context *, ctx)
+ __field(u32, hw_id)
__field(struct i915_address_space *, vm)
),
TP_fast_assign(
+ __entry->dev = ctx->i915->drm.primary->index;
__entry->ctx = ctx;
+ __entry->hw_id = ctx->hw_id;
__entry->vm = ctx->ppgtt ? &ctx->ppgtt->base : NULL;
- __entry->dev = ctx->i915->drm.primary->index;
),
- TP_printk("dev=%u, ctx=%p, ctx_vm=%p",
- __entry->dev, __entry->ctx, __entry->vm)
+ TP_printk("dev=%u, ctx=%p, ctx_vm=%p, hw_id=%u",
+ __entry->dev, __entry->ctx, __entry->vm, __entry->hw_id)
)
DEFINE_EVENT(i915_context, i915_context_create,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/8] drm/i915/tracepoints: Adjust i915_gem_ring_dispatch
From: Tvrtko Ursulin
Rename it to i915_gem_request_queue and fix the logged info
equivalent to the i915_gem_request even class. Also moved it
a bit further apart from the i915_gem_request_add tracepoint
since they otherwise provide similar information too close in
time.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_trace.h | 11 +++
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c66e90571031..3cb7b0a3dd38 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1492,8 +1492,6 @@ execbuf_submit(struct i915_execbuffer_params *params,
if (ret)
return ret;
- trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
-
i915_gem_execbuffer_move_to_active(vmas, params->request);
return 0;
@@ -1803,6 +1801,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
params->dispatch_flags = dispatch_flags;
params->ctx = ctx;
+ trace_i915_gem_request_queue(params->request, dispatch_flags);
+
ret = execbuf_submit(params, args, &eb->vmas);
err_request:
__i915_add_request(params->request, ret == 0);
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index d890e4b03902..79162c369812 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -503,13 +503,14 @@ TRACE_EVENT(i915_gem_ring_sync_to,
__entry->seqno)
);
-TRACE_EVENT(i915_gem_ring_dispatch,
+TRACE_EVENT(i915_gem_request_queue,
TP_PROTO(struct drm_i915_gem_request *req, u32 flags),
TP_ARGS(req, flags),
TP_STRUCT__entry(
__field(u32, dev)
__field(u32, ring)
+__field(u32, ctx)
__field(u32, seqno)
__field(u32, flags)
),
@@ -517,13 +518,15 @@ TRACE_EVENT(i915_gem_ring_dispatch,
TP_fast_assign(
__entry->dev = req->i915->drm.primary->index;
__entry->ring = req->engine->id;
- __entry->seqno = req->global_seqno;
+ __entry->ctx = req->ctx->hw_id;
+ __entry->seqno = req->fence.seqno;
__entry->flags = flags;
dma_fence_enable_sw_signaling(&req->fence);
),
- TP_printk("dev=%u, ring=%u, seqno=%u, flags=%x",
- __entry->dev, __entry->ring, __entry->seqno,
__entry->flags)
+ TP_printk("dev=%u, ring=%u, ctx=%u, seqno=%u, flags=%x",
+ __entry->dev, __entry->ring, __entry->ctx, __entry->seqno,
+ __entry->flags)
);
TRACE_EVENT(i915_gem_ring_flush,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/8] drm/i915/tracepoints: Remove unused i915_gem_request_complete
From: Tvrtko Ursulin Tracepoint is not used and won't be suitable for its replacement. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_trace.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index cbdbe7d6f5ef..f08ccac0d959 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -607,11 +607,6 @@ DEFINE_EVENT(i915_gem_request, i915_gem_request_retire, TP_ARGS(req) ); -DEFINE_EVENT(i915_gem_request, i915_gem_request_complete, - TP_PROTO(struct drm_i915_gem_request *req), - TP_ARGS(req) -); - TRACE_EVENT(i915_gem_request_wait_begin, TP_PROTO(struct drm_i915_gem_request *req), TP_ARGS(req), -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 6/8] drm/i915/tracepoints: Rename i915_gem_request_notify
From: Tvrtko Ursulin
i915_gem_ring_notify is more appropriate since we do not have
the request information at this point, but it is simply a
signal from the engine that some request has been completed.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0ff75f2282fa..e16da1873be2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1035,7 +1035,7 @@ static void notify_ring(struct intel_engine_cs *engine)
{
set_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
if (intel_engine_wakeup(engine))
- trace_i915_gem_request_notify(engine);
+ trace_i915_gem_ring_notify(engine);
}
static void vlv_c0_read(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 1fe1417f8c4d..d24b89d0e3ab 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -606,7 +606,7 @@ trace_i915_gem_request_execute(struct drm_i915_gem_request
*req)
#endif
#endif
-TRACE_EVENT(i915_gem_request_notify,
+TRACE_EVENT(i915_gem_ring_notify,
TP_PROTO(struct intel_engine_cs *engine),
TP_ARGS(engine),
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/8] drm/i915/tracepoints: Tidy i915_gem_request_wait_begin
On Fri, Jan 27, 2017 at 12:01:22PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Provide the same information as the other request even classes. > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/i915_trace.h | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_trace.h > b/drivers/gpu/drm/i915/i915_trace.h > index 79162c369812..cbdbe7d6f5ef 100644 > --- a/drivers/gpu/drm/i915/i915_trace.h > +++ b/drivers/gpu/drm/i915/i915_trace.h > @@ -619,7 +619,9 @@ TRACE_EVENT(i915_gem_request_wait_begin, > TP_STRUCT__entry( >__field(u32, dev) >__field(u32, ring) > + __field(u32, ctx) >__field(u32, seqno) > + __field(u32, global) >__field(bool, blocking) >), > > @@ -632,14 +634,16 @@ TRACE_EVENT(i915_gem_request_wait_begin, > TP_fast_assign( > __entry->dev = req->i915->drm.primary->index; > __entry->ring = req->engine->id; > -__entry->seqno = req->global_seqno; > +__entry->ctx = req->ctx->hw_id; > +__entry->seqno = req->fence.seqno; > +__entry->global = req->global_seqno; > __entry->blocking = > > mutex_is_locked(&req->i915->drm.struct_mutex); We now have accurate information for this field from (flags & I915_WAIT_LOCKED). Let's fix that up as well and drop the NB. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/8] drm/i915/tracepoints: Rename i915_gem_request_notify
On Fri, Jan 27, 2017 at 12:01:25PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > i915_gem_ring_notify is more appropriate since we do not have > the request information at this point, but it is simply a > signal from the engine that some request has been completed. I was going to suggest intel_engine_notify. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints
On Fri, Jan 27, 2017 at 12:01:26PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Two new tracepoints placed at the call sites where requests are > actually passed to the GPU enable userspace to track engine > utilisation. > > These tracepoints are only enabled when the > DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option is enabled. > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/i915_guc_submission.c | 2 ++ > drivers/gpu/drm/i915/i915_trace.h | 49 > ++ > drivers/gpu/drm/i915/intel_lrc.c | 4 +++ > 3 files changed, 55 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > b/drivers/gpu/drm/i915/i915_guc_submission.c > index 8ced9e26f075..beec88a30347 100644 > --- a/drivers/gpu/drm/i915/i915_guc_submission.c > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c > @@ -518,6 +518,8 @@ static void __i915_guc_submit(struct drm_i915_gem_request > *rq) > if (i915_vma_is_map_and_fenceable(rq->ring->vma)) > POSTING_READ_FW(GUC_STATUS); > > + trace_i915_gem_request_in(rq, 0); But how to get out for guc? We could do a similar in for ringbuffer. The original way I used it was in == dispatch, out == ring-notify, which is why trace_i915_gem_ring_dispatch enabled the signaling. Hmm. Following on from that we can add the out tracepoint as a fence-callback. For the moment, I'd drop guc/legacy trace_i915_gem_request_in and we will try something more magical. Though once we do enable the fake GuC scheduler we will have an appropriate place to drop an trace_i915_gem_request_out. Just leaving ringbuffer as the odd one out, but for who arguably the in/out logic is not as important. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/8] drm/i915/tracepoints: Adjust i915_gem_ring_dispatch
On Fri, Jan 27, 2017 at 12:01:21PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Rename it to i915_gem_request_queue and fix the logged info > equivalent to the i915_gem_request even class. Also moved it > a bit further apart from the i915_gem_request_add tracepoint > since they otherwise provide similar information too close in > time. > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++-- > drivers/gpu/drm/i915/i915_trace.h | 11 +++ > 2 files changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index c66e90571031..3cb7b0a3dd38 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -1492,8 +1492,6 @@ execbuf_submit(struct i915_execbuffer_params *params, > if (ret) > return ret; > > - trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags); > - > i915_gem_execbuffer_move_to_active(vmas, params->request); > > return 0; > @@ -1803,6 +1801,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void > *data, > params->dispatch_flags = dispatch_flags; > params->ctx = ctx; > > + trace_i915_gem_request_queue(params->request, dispatch_flags); > + > ret = execbuf_submit(params, args, &eb->vmas); > err_request: > __i915_add_request(params->request, ret == 0); > diff --git a/drivers/gpu/drm/i915/i915_trace.h > b/drivers/gpu/drm/i915/i915_trace.h > index d890e4b03902..79162c369812 100644 > --- a/drivers/gpu/drm/i915/i915_trace.h > +++ b/drivers/gpu/drm/i915/i915_trace.h > @@ -503,13 +503,14 @@ TRACE_EVENT(i915_gem_ring_sync_to, > __entry->seqno) > ); > > -TRACE_EVENT(i915_gem_ring_dispatch, > +TRACE_EVENT(i915_gem_request_queue, > TP_PROTO(struct drm_i915_gem_request *req, u32 flags), > TP_ARGS(req, flags), > > TP_STRUCT__entry( >__field(u32, dev) >__field(u32, ring) > + __field(u32, ctx) >__field(u32, seqno) >__field(u32, flags) >), > @@ -517,13 +518,15 @@ TRACE_EVENT(i915_gem_ring_dispatch, > TP_fast_assign( > __entry->dev = req->i915->drm.primary->index; > __entry->ring = req->engine->id; > -__entry->seqno = req->global_seqno; > +__entry->ctx = req->ctx->hw_id; > +__entry->seqno = req->fence.seqno; > __entry->flags = flags; > dma_fence_enable_sw_signaling(&req->fence); In keeping with the better tracking for in/out, this hack to enable the notify irq here is no longer required. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/8] drm/i915/tracepoints: Remove unused i915_gem_request_complete
On Fri, Jan 27, 2017 at 12:01:23PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Tracepoint is not used and won't be suitable for its replacement. Indeed, superseded by trace_dma_fence_signaled. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Create context desc template when context is created
Move the invariant parts of context desc setup from execlist init
to context creation. This is advantageous when we need to
create different templates based on the context parametrization,
ie. for svm capable contexts.
v2: s/create/default, remove engine->ctx_desc_template
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 23 --
drivers/gpu/drm/i915/i915_reg.h | 15 ++
drivers/gpu/drm/i915/intel_lrc.c| 35 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
4 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 77458da..6801054 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -236,6 +236,26 @@ static int assign_hw_id(struct drm_i915_private *dev_priv,
unsigned *out)
return 0;
}
+static u32 default_desc_template(const struct drm_i915_private *dev_priv)
+{
+ u32 desc;
+
+ desc = GEN8_CTX_VALID |
+ GEN8_CTX_PRIVILEGE |
+ GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
+ GEN8_CTX_ADDRESSING_MODE_SHIFT;
+
+ if (IS_GEN8(dev_priv))
+ desc |= GEN8_CTX_L3LLC_COHERENT;
+
+ /* TODO: WaDisableLiteRestore when we start using semaphore
+* signalling between Command Streamers
+* ring->ctx_desc_template |= GEN8_CTX_FORCE_RESTORE;
+*/
+
+ return desc;
+}
+
static struct i915_gem_context *
__create_hw_context(struct drm_i915_private *dev_priv,
struct drm_i915_file_private *file_priv)
@@ -309,8 +329,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
- ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
-GEN8_CTX_ADDRESSING_MODE_SHIFT;
+ ctx->desc_template = default_desc_template(dev_priv);
ATOMIC_INIT_NOTIFIER_HEAD(&ctx->status_notifier);
/* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 672cb10..718268b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3361,11 +3361,26 @@ enum {
INTEL_LEGACY_64B_CONTEXT
};
+enum {
+ FAULT_AND_HANG = 0,
+ FAULT_AND_HALT, /* Debug only */
+ FAULT_AND_STREAM,
+ FAULT_AND_CONTINUE /* Unsupported */
+};
+
+#define GEN8_CTX_VALID (1<<0)
+#define GEN8_CTX_FORCE_PD_RESTORE (1<<1)
+#define GEN8_CTX_FORCE_RESTORE (1<<2)
+#define GEN8_CTX_L3LLC_COHERENT (1<<5)
+#define GEN8_CTX_PRIVILEGE (1<<8)
#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
#define GEN8_CTX_ADDRESSING_MODE(dev_priv) (USES_FULL_48BIT_PPGTT(dev_priv) ?\
INTEL_LEGACY_64B_CONTEXT : \
INTEL_LEGACY_32B_CONTEXT)
+#define GEN8_CTX_ID_SHIFT 32
+#define GEN8_CTX_ID_WIDTH 21
+
#define CHV_CLK_CTL1 _MMIO(0x101100)
#define VLV_CLK_CTL2 _MMIO(0x101104)
#define CLK_CTL2_CZCOUNT_30NS_SHIFT 28
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bee9d56..30d7715 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -190,12 +190,6 @@
#define CTX_R_PWR_CLK_STATE0x42
#define CTX_GPGPU_CSR_BASE_ADDRESS 0x44
-#define GEN8_CTX_VALID (1<<0)
-#define GEN8_CTX_FORCE_PD_RESTORE (1<<1)
-#define GEN8_CTX_FORCE_RESTORE (1<<2)
-#define GEN8_CTX_L3LLC_COHERENT (1<<5)
-#define GEN8_CTX_PRIVILEGE (1<<8)
-
#define ASSIGN_CTX_REG(reg_state, pos, reg, val) do { \
(reg_state)[(pos)+0] = i915_mmio_reg_offset(reg); \
(reg_state)[(pos)+1] = (val); \
@@ -212,14 +206,6 @@
reg_state[CTX_PDP0_LDW + 1] = lower_32_bits(px_dma(&ppgtt->pml4)); \
} while (0)
-enum {
- FAULT_AND_HANG = 0,
- FAULT_AND_HALT, /* Debug only */
- FAULT_AND_STREAM,
- FAULT_AND_CONTINUE /* Unsupported */
-};
-#define GEN8_CTX_ID_SHIFT 32
-#define GEN8_CTX_ID_WIDTH 21
#define GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT 0x17
#define GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT 0x26
@@ -267,21 +253,6 @@ int intel_sanitize_enable_execlists(struct
drm_i915_private *dev_priv, int enabl
return 0;
}
-static void
-logical_ring_init_platform_invariants(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
-
- engine->ctx_desc_template = GEN8_CTX_VALID;
- if (IS_GEN8(dev_priv))
- engine->ctx_desc_template |= GEN8_CTX_L3LLC_COHERENT;
- engine->ctx_desc_template |= GEN8_CTX_PRIVILEGE;
-
- /* TODO: WaDisableLiteRestore when we start using semaphore
-* signalling between Command Streamers */
- /* ring->ctx_desc_template |= GEN8_CTX_FORCE
[Intel-gfx] [PATCH] drm/i915: Check fence status after serialising with the spinlock
A very rare problem we encounter is that as retire the request we find that it appears to not have been yet executed. Other than malevolent hw, one possible explanation is that the update of the fence status on one cpu (an atomic_dec_and_test) is not yet visible to the retiree on another cpu. However, since retirement is serialised with execution via a fence-local spinlock, we can use these to ensure that we have sufficient barriers between the execution and the assert in retirement. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c index 72b7f7d9461d..53966e10c1d8 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.c +++ b/drivers/gpu/drm/i915/i915_gem_request.c @@ -210,10 +210,7 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request) struct i915_gem_active *active, *next; lockdep_assert_held(&request->i915->drm.struct_mutex); - GEM_BUG_ON(!i915_sw_fence_signaled(&request->submit)); - GEM_BUG_ON(!i915_sw_fence_signaled(&request->execute)); GEM_BUG_ON(!i915_gem_request_completed(request)); - GEM_BUG_ON(!request->i915->gt.active_requests); trace_i915_gem_request_retire(request); @@ -221,6 +218,10 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request) list_del_init(&request->link); spin_unlock_irq(&engine->timeline->lock); + GEM_BUG_ON(!i915_sw_fence_signaled(&request->submit)); + GEM_BUG_ON(!i915_sw_fence_signaled(&request->execute)); + GEM_BUG_ON(!request->i915->gt.active_requests); + /* We know the GPU must have read the request to have * sent us the seqno + interrupt, so use the position * of tail of the request to update the last known position -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Fri, Jan 27, 2017 at 12:08:58PM +0200, Jani Nikula wrote:
> On Thu, 26 Jan 2017, Pierre-Louis Bossart
> wrote:
> > Enable chicken bit on LPE mode setup and unmute amp on
> > notification
> >
> > FIXME: should these two phases done somewhere else?
> >
> > Signed-off-by: Pierre-Louis Bossart
> > ---
> > drivers/gpu/drm/i915/i915_reg.h| 12
> > drivers/gpu/drm/i915/intel_lpe_audio.c | 27 +++
> > 2 files changed, 39 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a9ffc8d..ee90f64 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2061,6 +2061,18 @@ enum skl_disp_power_wells {
> > #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
> > #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
> >
> > +/* DisplayPort Audio w/ LPE */
> > +#define CHICKEN_BIT_DBG_ENABLE (1 << 0)
> > +#define AMP_UNMUTE (1 << 1)
That should be called AMP_MUTE I think,
>
> The convention is to define registers first and the contents/bits for
> each register immedialy below. For groups of registers (like
> PORT_EN_B/C/D below) define all registers first and bits immediately
> below. (But note that the chicken register is not part of the group.)
>
> > +#define AUD_CHICKEN_BIT_REG0x62F38
Spec calls this AUD_CHICKENBIT_REG. Might as well follow it to the
letter.
> > +#define AUD_PORT_EN_B_DBG 0x62F20
> > +#define AUD_PORT_EN_C_DBG 0x62F28
> > +#define AUD_PORT_EN_D_DBG 0x62F2C
These match the spec. But to match the standard i915 convention they
should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit
register.
>
> Please don't define these separately without the display base, use
> (VLV_DISPLAY_BASE + 0x62f38) style instead. All the other uses of
> VLV_DISPLAY_BASE in the file follow the same convention.
>
> > +#define VLV_AUD_CHICKEN_BIT_REG_MMIO(VLV_DISPLAY_BASE +
> > AUD_CHICKEN_BIT_REG)
> > +#define VLV_AUD_PORT_EN_B_DBG _MMIO(VLV_DISPLAY_BASE +
> > AUD_PORT_EN_B_DBG)
> > +#define VLV_AUD_PORT_EN_C_DBG _MMIO(VLV_DISPLAY_BASE +
> > AUD_PORT_EN_C_DBG)
> > +#define VLV_AUD_PORT_EN_D_DBG _MMIO(VLV_DISPLAY_BASE +
> > AUD_PORT_EN_D_DBG)
> > +
>
> Would be nice to have a macro VLV_AUD_PORT_EN_DBG(port), but damn those
> reg offsets don't make it easy...
_MMIO_PORT3().
>
>
> > #define GEN6_BSD_RNCID _MMIO(0x12198)
> >
> > #define GEN7_FF_THREAD_MODE_MMIO(0x20a0)
> > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > index 245523e..b3134ef 100644
> > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > @@ -248,6 +248,15 @@ static int lpe_audio_setup(struct drm_i915_private
> > *dev_priv)
> > goto err_free_irq;
> > }
> >
> > + /* Enable DPAudio debug bits by default */
> > + if (IS_CHERRYVIEW(dev_priv)) {
VLV too. And like I said we might need this in the powerwell code as
well. You should make a test to see if the register value is retained
across the display power well being turned off. Eg. simply disable all
displays, check the log to make sure it really did turn off the display
power well, then re-enable some displays, and finally check if the
register value was retained or not).
> > + u32 chicken_bit;
> > +
> > + chicken_bit = I915_READ(VLV_AUD_CHICKEN_BIT_REG);
> > + I915_WRITE(VLV_AUD_CHICKEN_BIT_REG,
> > + chicken_bit | CHICKEN_BIT_DBG_ENABLE);
> > + }
> > +
> > return 0;
> > err_free_irq:
> > irq_free_desc(dev_priv->lpe_audio.irq);
> > @@ -357,6 +366,24 @@ void intel_lpe_audio_notify(struct drm_i915_private
> > *dev_priv,
> > pdata->tmds_clock_speed = tmds_clk_speed;
> > if (link_rate)
> > pdata->link_rate = link_rate;
> > +
> > + if (dp_output) { /* unmute the amp */
The spec doesn't distinquish DP vs. HDMI here. So I presume we should be
able to do this always.
And I think we might want to mute things again when disabling audio.
> > + u32 audio_enable;
> > +
> > + if (port == PORT_B) {
> > + audio_enable = I915_READ(VLV_AUD_PORT_EN_B_DBG);
> > + I915_WRITE(VLV_AUD_PORT_EN_B_DBG,
> > + audio_enable & ~AMP_UNMUTE);
> > + } else if (port == PORT_C) {
> > + audio_enable = I915_READ(VLV_AUD_PORT_EN_C_DBG);
> > + I915_WRITE(VLV_AUD_PORT_EN_C_DBG,
> > + audio_enable & ~AMP_UNMUTE);
> > + } else if (port == PORT_D) {
> > + audio_enable = I915_READ(VLV_AUD_PORT_EN_D_DBG);
>
Re: [Intel-gfx] [PATCH] drm/i915: Create context desc template when context is created
On Fri, Jan 27, 2017 at 03:03:09PM +0200, Mika Kuoppala wrote: > Move the invariant parts of context desc setup from execlist init > to context creation. This is advantageous when we need to > create different templates based on the context parametrization, > ie. for svm capable contexts. > > v2: s/create/default, remove engine->ctx_desc_template > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala > +#define GEN8_CTX_VALID (1<<0) > +#define GEN8_CTX_FORCE_PD_RESTORE (1<<1) > +#define GEN8_CTX_FORCE_RESTORE (1<<2) > +#define GEN8_CTX_L3LLC_COHERENT (1<<5) > +#define GEN8_CTX_PRIVILEGE (1<<8) > #define GEN8_CTX_ADDRESSING_MODE_SHIFT 3 > #define GEN8_CTX_ADDRESSING_MODE(dev_priv) (USES_FULL_48BIT_PPGTT(dev_priv) > ?\ > INTEL_LEGACY_64B_CONTEXT : \ > INTEL_LEGACY_32B_CONTEXT) > > +#define GEN8_CTX_ID_SHIFT 32 > +#define GEN8_CTX_ID_WIDTH 21 One thing to note for a future patch would be BUILD_BUG_ON(GEN8_CTX_ID_WIDTH < ilog2(MAX_CONTEXT_HW_ID)); now that it is exposed to i915_gem_context.c Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Make uapi/i915_drm.h standalone
== Series Details == Series: drm/i915: Make uapi/i915_drm.h standalone URL : https://patchwork.freedesktop.org/series/18670/ State : failure == Summary == Series 18670v1 drm/i915: Make uapi/i915_drm.h standalone https://patchwork.freedesktop.org/api/1.0/series/18670/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-connector-state: pass -> DMESG-WARN (fi-snb-2520m) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2600) fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:79 pass:66 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:215 dwarn:1 dfail:0 fail:0 skip:31 fi-snb-2600 total:206 pass:178 dwarn:0 dfail:0 fail:0 skip:27 93cbdef9696bcaa1279ae05c418b2794b71c2398 drm-tip: 2017y-01m-27d-09h-55m-16s UTC integration manifest 4976a1f drm/i915: Make uapi/i915_drm.h standalone == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3624/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:drm-intel-next-queued 0/1] htmldocs: include/drm/drm_color_mgmt.h:1: warning: no structured comments found
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 920bcd1820a6966b6224f62eadcb4e931bb72e8e commit: 2eebe4f2d5f4c91edc37801d828ba29edfbc7722 [0/1] drm/color: un-inline drm_color_lut_extract() reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. include/linux/init.h:1: warning: no structured comments found include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/drm/drm_drv.h:441: warning: No description found for parameter 'firstopen' include/drm/drm_drv.h:441: warning: No description found for parameter 'open' include/drm/drm_drv.h:441: warning: No description found for parameter 'preclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'postclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'lastclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_ioctl' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_quiescent' include/drm/drm_drv.h:441: warning: No description found for parameter 'context_dtor' include/drm/drm_drv.h:441: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_handler' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_preinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_postinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_uninstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_cleanup' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'vgaarb_irq' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:441: warning: No description found for parameter 'major' include/drm/drm_drv.h:441: warning: No description found for parameter 'minor' include/drm/drm_drv.h:441: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:441: warning: No description found for parameter 'name' include/drm/drm_drv.h:441: warning: No description found for parameter 'desc' include/drm/drm_drv.h:441: warning: No description found for parameter 'date' include/drm/drm_drv.h:441: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:441: warning: No description found for parameter 'dev_priv_size' include/drm/drm_drv.h:441: warning: No description found for parameter 'ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'num_ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'fops' include/drm/drm_drv.h:441: warning: No description found for parameter 'legacy_dev_list' >> include/drm/drm_color_mgmt.h:1: warning: no structured comments found drivers/media/dvb-core/dvb_frontend.h:677: warning: No description found for parameter 'refcount' drivers/char/tpm/tpm_vtpm_proxy.c:73: warning: No description found for parameter 'filp' drivers/char/tpm/tpm_vtpm_proxy.c:73: warning: No description found for parameter 'buf' drivers/char/tpm/tpm_vtpm_proxy.c:73: warning: No description found for parameter 'count' drivers
[Intel-gfx] ✗ Fi.CI.BAT: failure for Tracepoints cleanup and improvements for requests
== Series Details ==
Series: Tracepoints cleanup and improvements for requests
URL : https://patchwork.freedesktop.org/series/18676/
State : failure
== Summary ==
LD drivers/usb/storage/built-in.o
CC [M] drivers/gpu/drm/i915/gvt/render.o
CC [M] drivers/gpu/drm/i915/intel_lpe_audio.o
LD kernel/built-in.o
LD drivers/pci/pcie/aer/aerdriver.o
LD drivers/pci/pcie/aer/built-in.o
LD drivers/pci/pcie/built-in.o
LD net/packet/built-in.o
LD drivers/pci/built-in.o
LD drivers/scsi/scsi_mod.o
LD drivers/tty/serial/8250/8250.o
LD sound/built-in.o
LD drivers/gpu/drm/drm.o
LD drivers/iommu/built-in.o
LD [M] drivers/usb/serial/usbserial.o
LD drivers/acpi/acpica/acpi.o
LD drivers/thermal/thermal_sys.o
LD drivers/thermal/built-in.o
LD drivers/acpi/acpica/built-in.o
LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o
LD [M] drivers/net/ethernet/intel/e1000/e1000.o
LD drivers/usb/gadget/libcomposite.o
LD drivers/acpi/built-in.o
LD [M] drivers/mmc/core/mmc_block.o
LD drivers/mmc/built-in.o
LD drivers/video/fbdev/core/fb.o
LD drivers/video/fbdev/core/built-in.o
LD drivers/spi/built-in.o
In file included from ./include/trace/define_trace.h:95:0,
from drivers/gpu/drm/i915/i915_trace.h:912,
from drivers/gpu/drm/i915/i915_trace_points.c:12:
./include/trace/trace_events.h:331:37: error:
‘trace_event_type_funcs_i915_gem_request_hw’ defined but not used
[-Werror=unused-variable]
static struct trace_event_functions trace_event_type_funcs_##call = { \
^
drivers/gpu/drm/i915/./i915_trace.h:585:1: note: in expansion of macro
‘DECLARE_EVENT_CLASS’
DECLARE_EVENT_CLASS(i915_gem_request_hw,
^
In file included from ./include/trace/define_trace.h:95:0,
from drivers/gpu/drm/i915/i915_trace.h:912,
from drivers/gpu/drm/i915/i915_trace_points.c:12:
./include/trace/trace_events.h:726:13: error: ‘print_fmt_i915_gem_request_hw’
defined but not used [-Werror=unused-variable]
static char print_fmt_##call[] = print; \
^
drivers/gpu/drm/i915/./i915_trace.h:585:1: note: in expansion of macro
‘DECLARE_EVENT_CLASS’
DECLARE_EVENT_CLASS(i915_gem_request_hw,
^
LD drivers/tty/serial/8250/8250_base.o
LD drivers/tty/serial/8250/built-in.o
LD drivers/usb/gadget/udc/udc-core.o
LD drivers/usb/gadget/udc/built-in.o
LD drivers/usb/gadget/built-in.o
LD drivers/tty/serial/built-in.o
LD drivers/scsi/sd_mod.o
LD drivers/video/fbdev/built-in.o
LD drivers/scsi/built-in.o
AR lib/lib.a
EXPORTS lib/lib-ksyms.o
LD fs/btrfs/btrfs.o
LD lib/built-in.o
LD drivers/video/console/built-in.o
LD net/xfrm/built-in.o
LD drivers/video/built-in.o
LD drivers/usb/core/usbcore.o
LD fs/btrfs/built-in.o
LD drivers/usb/core/built-in.o
CC arch/x86/kernel/cpu/capflags.o
LD arch/x86/kernel/cpu/built-in.o
LD arch/x86/kernel/built-in.o
LD net/ipv4/built-in.o
LD drivers/tty/vt/built-in.o
LD drivers/tty/built-in.o
LD net/ipv6/ipv6.o
LD drivers/md/md-mod.o
LD [M] drivers/net/ethernet/intel/igb/igb.o
LD drivers/md/built-in.o
LD arch/x86/built-in.o
LD net/ipv6/built-in.o
cc1: all warnings being treated as errors
LD drivers/usb/host/xhci-hcd.o
scripts/Makefile.build:293: recipe for target
'drivers/gpu/drm/i915/i915_trace_points.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_trace_points.o] Error 1
make[4]: *** Waiting for unfinished jobs
LD fs/ext4/ext4.o
LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o
LD fs/ext4/built-in.o
LD fs/built-in.o
LD drivers/usb/host/built-in.o
LD drivers/usb/built-in.o
LD net/core/built-in.o
LD net/built-in.o
LD drivers/net/ethernet/built-in.o
LD drivers/net/built-in.o
scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:551: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:988: recipe for target 'drivers' failed
make: *** [drivers] Error 2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/13] drm/i915: Add intel_uncore_suspend / resume functions
On Mon, Jan 23, 2017 at 10:09:56PM +0100, Hans de Goede wrote:
> Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the
> (always true) restore_forcewake argument and add a new intel_uncore_resume
> function to replace the intel_uncore_forcewake_reset(dev_priv, false)
> calls done from the suspend / runtime_suspend functions and make
> intel_uncore_forcewake_reset private.
>
> This is a preparation patch for adding PMIC bus access notifier support.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
> drivers/gpu/drm/i915/i915_drv.h | 6 ++
> drivers/gpu/drm/i915/intel_uncore.c | 18 +++---
> 3 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index aefab9a..5a62d7a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1445,7 +1445,7 @@ static int i915_drm_suspend(struct drm_device *dev)
> opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
> intel_opregion_notify_adapter(dev_priv, opregion_target_state);
>
> - intel_uncore_forcewake_reset(dev_priv, false);
> + intel_uncore_suspend(dev_priv);
> intel_opregion_unregister(dev_priv);
>
> intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
> @@ -1690,7 +1690,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
> DRM_ERROR("Resume prepare failed: %d, continuing anyway\n",
> ret);
>
> - intel_uncore_early_sanitize(dev_priv, true);
> + intel_uncore_resume(dev_priv);
>
> if (IS_GEN9_LP(dev_priv)) {
> if (!dev_priv->suspended_to_idle)
> @@ -2344,7 +2344,7 @@ static int intel_runtime_suspend(struct device *kdev)
> return ret;
> }
>
> - intel_uncore_forcewake_reset(dev_priv, false);
> + intel_uncore_suspend(dev_priv);
Doing one from early_resume and the other from the normal suspend makes
my brain hurt a little. If we do that I think we should at least name
the functions appropriately.
>
> enable_rpm_wakeref_asserts(dev_priv);
> WARN_ON_ONCE(atomic_read(&dev_priv->pm.wakeref_count));
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e9b4ece..c717329 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2976,14 +2976,12 @@ int intel_irq_install(struct drm_i915_private
> *dev_priv);
> void intel_irq_uninstall(struct drm_i915_private *dev_priv);
>
> extern void intel_uncore_sanitize(struct drm_i915_private *dev_priv);
> -extern void intel_uncore_early_sanitize(struct drm_i915_private *dev_priv,
> - bool restore_forcewake);
> extern void intel_uncore_init(struct drm_i915_private *dev_priv);
> extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
> extern bool intel_uncore_arm_unclaimed_mmio_detection(struct
> drm_i915_private *dev_priv);
> extern void intel_uncore_fini(struct drm_i915_private *dev_priv);
> -extern void intel_uncore_forcewake_reset(struct drm_i915_private *dev_priv,
> - bool restore);
> +extern void intel_uncore_suspend(struct drm_i915_private *dev_priv);
> +extern void intel_uncore_resume(struct drm_i915_private *dev_priv);
> const char *intel_uncore_forcewake_domain_to_str(const enum
> forcewake_domain_id id);
> void intel_uncore_forcewake_get(struct drm_i915_private *dev_priv,
> enum forcewake_domains domains);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index abe0888..3767307 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -250,7 +250,7 @@ intel_uncore_fw_release_timer(struct hrtimer *timer)
> return HRTIMER_NORESTART;
> }
>
> -void intel_uncore_forcewake_reset(struct drm_i915_private *dev_priv,
> +static void __intel_uncore_forcewake_reset(struct drm_i915_private *dev_priv,
> bool restore)
Maybe leave out this rename to keep the diff a little easier to parse.
> {
> unsigned long irqflags;
> @@ -424,13 +424,17 @@ static void __intel_uncore_early_sanitize(struct
> drm_i915_private *dev_priv,
> if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST))
> info->has_decoupled_mmio = false;
>
> - intel_uncore_forcewake_reset(dev_priv, restore_forcewake);
> + __intel_uncore_forcewake_reset(dev_priv, restore_forcewake);
> }
>
> -void intel_uncore_early_sanitize(struct drm_i915_private *dev_priv,
> - bool restore_forcewake)
> +void intel_uncore_suspend(struct drm_i915_private *dev_priv)
> {
> - __intel_uncore_early_sanit
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Fri, 27 Jan 2017, Ville Syrjälä wrote:
> On Fri, Jan 27, 2017 at 12:08:58PM +0200, Jani Nikula wrote:
>> On Thu, 26 Jan 2017, Pierre-Louis Bossart
>> wrote:
>> > Enable chicken bit on LPE mode setup and unmute amp on
>> > notification
>> >
>> > FIXME: should these two phases done somewhere else?
>> >
>> > Signed-off-by: Pierre-Louis Bossart
>> > ---
>> > drivers/gpu/drm/i915/i915_reg.h| 12
>> > drivers/gpu/drm/i915/intel_lpe_audio.c | 27 +++
>> > 2 files changed, 39 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index a9ffc8d..ee90f64 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -2061,6 +2061,18 @@ enum skl_disp_power_wells {
>> > #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
>> > #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
>> >
>> > +/* DisplayPort Audio w/ LPE */
>> > +#define CHICKEN_BIT_DBG_ENABLE(1 << 0)
>> > +#define AMP_UNMUTE(1 << 1)
>
> That should be called AMP_MUTE I think,
>
>>
>> The convention is to define registers first and the contents/bits for
>> each register immedialy below. For groups of registers (like
>> PORT_EN_B/C/D below) define all registers first and bits immediately
>> below. (But note that the chicken register is not part of the group.)
>>
>> > +#define AUD_CHICKEN_BIT_REG 0x62F38
>
> Spec calls this AUD_CHICKENBIT_REG. Might as well follow it to the
> letter.
>
>> > +#define AUD_PORT_EN_B_DBG 0x62F20
>> > +#define AUD_PORT_EN_C_DBG 0x62F28
>> > +#define AUD_PORT_EN_D_DBG 0x62F2C
>
> These match the spec. But to match the standard i915 convention they
> should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit
> register.
>
>>
>> Please don't define these separately without the display base, use
>> (VLV_DISPLAY_BASE + 0x62f38) style instead. All the other uses of
>> VLV_DISPLAY_BASE in the file follow the same convention.
>>
>> > +#define VLV_AUD_CHICKEN_BIT_REG _MMIO(VLV_DISPLAY_BASE +
>> > AUD_CHICKEN_BIT_REG)
>> > +#define VLV_AUD_PORT_EN_B_DBG _MMIO(VLV_DISPLAY_BASE +
>> > AUD_PORT_EN_B_DBG)
>> > +#define VLV_AUD_PORT_EN_C_DBG _MMIO(VLV_DISPLAY_BASE +
>> > AUD_PORT_EN_C_DBG)
>> > +#define VLV_AUD_PORT_EN_D_DBG _MMIO(VLV_DISPLAY_BASE +
>> > AUD_PORT_EN_D_DBG)
>> > +
>>
>> Would be nice to have a macro VLV_AUD_PORT_EN_DBG(port), but damn those
>> reg offsets don't make it easy...
>
> _MMIO_PORT3().
Works for ports A, B, C, but here we have ports B, C, D.
BR,
Jani.
>
>>
>>
>> > #define GEN6_BSD_RNCID_MMIO(0x12198)
>> >
>> > #define GEN7_FF_THREAD_MODE _MMIO(0x20a0)
>> > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
>> > b/drivers/gpu/drm/i915/intel_lpe_audio.c
>> > index 245523e..b3134ef 100644
>> > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
>> > @@ -248,6 +248,15 @@ static int lpe_audio_setup(struct drm_i915_private
>> > *dev_priv)
>> >goto err_free_irq;
>> >}
>> >
>> > + /* Enable DPAudio debug bits by default */
>> > + if (IS_CHERRYVIEW(dev_priv)) {
>
> VLV too. And like I said we might need this in the powerwell code as
> well. You should make a test to see if the register value is retained
> across the display power well being turned off. Eg. simply disable all
> displays, check the log to make sure it really did turn off the display
> power well, then re-enable some displays, and finally check if the
> register value was retained or not).
>
>> > + u32 chicken_bit;
>> > +
>> > + chicken_bit = I915_READ(VLV_AUD_CHICKEN_BIT_REG);
>> > + I915_WRITE(VLV_AUD_CHICKEN_BIT_REG,
>> > + chicken_bit | CHICKEN_BIT_DBG_ENABLE);
>> > + }
>> > +
>> >return 0;
>> > err_free_irq:
>> >irq_free_desc(dev_priv->lpe_audio.irq);
>> > @@ -357,6 +366,24 @@ void intel_lpe_audio_notify(struct drm_i915_private
>> > *dev_priv,
>> >pdata->tmds_clock_speed = tmds_clk_speed;
>> >if (link_rate)
>> >pdata->link_rate = link_rate;
>> > +
>> > + if (dp_output) { /* unmute the amp */
>
> The spec doesn't distinquish DP vs. HDMI here. So I presume we should be
> able to do this always.
>
> And I think we might want to mute things again when disabling audio.
>
>> > + u32 audio_enable;
>> > +
>> > + if (port == PORT_B) {
>> > + audio_enable = I915_READ(VLV_AUD_PORT_EN_B_DBG);
>> > + I915_WRITE(VLV_AUD_PORT_EN_B_DBG,
>> > + audio_enable & ~AMP_UNMUTE);
>> > + } else if (port == PORT_C) {
>> > + audio_enable = I915_READ(VLV_AUD_PORT_EN_C_DBG);
>> > + I915_WRITE(VLV_
Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings
On Mon, Jan 23, 2017 at 10:09:58PM +0100, Hans de Goede wrote:
> Make sure the P-Unit or the PMIC i2c bus is not in use when we send a
> request to the P-Unit by calling iosf_mbi_punit_acquire() / _release()
> around P-Unit write accesses.
Can't we just stuff the calls into the actual punit write function
rather than sprinkling them all over the place?
+ a comment would be nice why it's there.
Do we need a kconfig select/depends on the iosf_mbi thing? Or some
ifdefs?
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> -Adjust for iosf_mbi_punit_lock/_unlock to _acquire/_release rename
> ---
> drivers/gpu/drm/i915/intel_display.c| 6 ++
> drivers/gpu/drm/i915/intel_pm.c | 9 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5604701..13e5152 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> static bool is_mmio_work(struct intel_flip_work *work)
> {
> @@ -6421,6 +6422,8 @@ static void valleyview_set_cdclk(struct drm_device
> *dev, int cdclk)
> cmd = 0;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
> +
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> val &= ~DSPFREQGUAR_MASK;
> val |= (cmd << DSPFREQGUAR_SHIFT);
> @@ -6430,6 +6433,7 @@ static void valleyview_set_cdclk(struct drm_device
> *dev, int cdclk)
>50)) {
> DRM_ERROR("timed out waiting for CDclk change\n");
> }
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
>
> mutex_lock(&dev_priv->sb_lock);
> @@ -6497,6 +6501,7 @@ static void cherryview_set_cdclk(struct drm_device
> *dev, int cdclk)
> cmd = DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1, cdclk) - 1;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> val &= ~DSPFREQGUAR_MASK_CHV;
> val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> @@ -6506,6 +6511,7 @@ static void cherryview_set_cdclk(struct drm_device
> *dev, int cdclk)
>50)) {
> DRM_ERROR("timed out waiting for CDclk change\n");
> }
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
>
> intel_update_cdclk(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 249623d..adff84a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -32,6 +32,7 @@
> #include "../../../platform/x86/intel_ips.h"
> #include
> #include
> +#include
>
> /**
> * DOC: RC6
> @@ -276,6 +277,7 @@ static void chv_set_memory_dvfs(struct drm_i915_private
> *dev_priv, bool enable)
> u32 val;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
>
> val = vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2);
> if (enable)
> @@ -290,6 +292,7 @@ static void chv_set_memory_dvfs(struct drm_i915_private
> *dev_priv, bool enable)
> FORCE_DDR_FREQ_REQ_ACK) == 0, 3))
> DRM_ERROR("timed out waiting for Punit DDR DVFS request\n");
>
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
> }
>
> @@ -298,6 +301,7 @@ static void chv_set_memory_pm5(struct drm_i915_private
> *dev_priv, bool enable)
> u32 val;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
>
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> if (enable)
> @@ -306,6 +310,7 @@ static void chv_set_memory_pm5(struct drm_i915_private
> *dev_priv, bool enable)
> val &= ~DSP_MAXFIFO_PM5_ENABLE;
> vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
>
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
> }
>
> @@ -4553,6 +4558,7 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
>
> if (IS_CHERRYVIEW(dev_priv)) {
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
>
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> if (val & DSP_MAXFIFO_PM5_ENABLE)
> @@ -4582,6 +4588,7 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
> wm->level = VLV_WM_LEVEL_DDR_DVFS;
> }
>
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
> }
>
> @@ -4988,7 +4995,9 @@ static void valleyview_set_rps(struct drm_i915_private
> *dev_priv, u8 val)
> I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
>
> if (val !=
Re: [Intel-gfx] [PATCH v2 12/13] drm/i915: Listen for PMIC bus access notifications
On Mon, Jan 23, 2017 at 10:09:57PM +0100, Hans de Goede wrote:
> Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
> the bus is accessed to avoid needing to do any forcewakes, which need
> PMIC bus access, while the PMIC bus is busy:
>
> This fixes errors like these showing up in dmesg, usually followed
> by a gfx or system freeze:
>
> [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake
> ack request.
> [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake
> ack request.
> i2c_designware 808622C1:06: punit semaphore timed out, resetting
> i2c_designware 808622C1:06: PUNIT SEM: 2
> i2c_designware 808622C1:06: couldn't acquire bus ownership
>
> Downside of this approach is that it causes wakeups whenever the PMIC
> bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
> to go idle when we hit a race, as forcewakes may be done from interrupt
> handlers where we cannot sleep to wait for the i2c PMIC bus access to
> finish.
>
> Note that the notifications and thus the wakeups will only happen on
> baytrail / cherrytrail devices using PMICs with a shared i2c bus for
> P-Unit and host PMIC access (i2c busses with a _SEM method in their
> APCI node), e.g. an axp288 PMIC.
>
> I plan to write some patches for drivers accessing the PMIC bus to
> limit their bus accesses to a bare minimum (e.g. cache registers, do not
> update battery level more often then 4 times a minute), to limit the
> amount of wakeups.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_uncore.c | 35 +++
> 2 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c717329..52f7dde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -721,6 +721,7 @@ struct intel_uncore {
> const struct intel_forcewake_range *fw_domains_table;
> unsigned int fw_domains_table_entries;
>
> + struct notifier_block pmic_bus_access_nb;
> struct intel_uncore_funcs funcs;
>
> unsigned fifo_count;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 3767307..175fe02 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -25,6 +25,7 @@
> #include "intel_drv.h"
> #include "i915_vgpu.h"
>
> +#include
> #include
>
> #define FORCEWAKE_ACK_TIMEOUT_MS 50
> @@ -429,12 +430,16 @@ static void __intel_uncore_early_sanitize(struct
> drm_i915_private *dev_priv,
>
> void intel_uncore_suspend(struct drm_i915_private *dev_priv)
> {
> + iosf_mbi_unregister_pmic_bus_access_notifier(
> + &dev_priv->uncore.pmic_bus_access_nb);
> __intel_uncore_forcewake_reset(dev_priv, false);
> }
>
> void intel_uncore_resume(struct drm_i915_private *dev_priv)
> {
> __intel_uncore_early_sanitize(dev_priv, true);
> + iosf_mbi_register_pmic_bus_access_notifier(
> + &dev_priv->uncore.pmic_bus_access_nb);
> i915_check_and_clear_faults(dev_priv);
> }
The early/normal/late suspend/resume ordering starts to bother me a
little more now. I wonder if we're totally safe wrt. the suspend/resume
order of the devices now.
> @@ -1390,6 +1395,28 @@ static void intel_uncore_fw_domains_init(struct
> drm_i915_private *dev_priv)
> dev_priv->uncore.fw_domains_table_entries = ARRAY_SIZE((d)); \
> }
>
> +static int i915_pmic_bus_access_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct drm_i915_private *dev_priv = container_of(nb,
> + struct drm_i915_private, uncore.pmic_bus_access_nb);
> +
> + switch (action) {
> + case MBI_PMIC_BUS_ACCESS_BEGIN:
> + /*
> + * forcewake all to make sure that we don't need to forcewake
> + * any power-planes while the pmic bus is busy.
> + */
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
I must say I don't really like this stuff at all. But if it helps I gues
we should go for it. I'd like to see the comment elaborate a bit more on
why we think it's is needed.
> + break;
> + case MBI_PMIC_BUS_ACCESS_END:
> + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + break;
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> void intel_uncore_init(struct drm_i915_private *dev_priv)
> {
> i915_check_vgpu(dev_priv);
> @@ -1399,6 +1426,8 @@ void intel_uncore_init(struct drm_i915_private
> *dev_priv)
> __intel_uncore_early_sanitize(dev_priv, false);
>
> dev_priv->uncore.unclaimed_mmio_check = 1;
> + dev_priv->uncore.pmic_bus_access_nb.n
[Intel-gfx] [PATCH libdrm v2] Import uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9
To sync with "drm/i915: Support explicit fencing for execbuf"
---
include/drm/i915_drm.h | 276 +++--
1 file changed, 266 insertions(+), 10 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index eb611a7a..5ebe0462 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -29,6 +29,10 @@
#include "drm.h"
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
/* Please note that modifications to all structs defined here are
* subject to backwards-compatibility constraints.
*/
@@ -58,6 +62,30 @@
#define I915_ERROR_UEVENT "ERROR"
#define I915_RESET_UEVENT "RESET"
+/*
+ * MOCS indexes used for GPU surfaces, defining the cacheability of the
+ * surface data and the coherency for this data wrt. CPU vs. GPU accesses.
+ */
+enum i915_mocs_table_index {
+ /*
+* Not cached anywhere, coherency between CPU and GPU accesses is
+* guaranteed.
+*/
+ I915_MOCS_UNCACHED,
+ /*
+* Cacheability and coherency controlled by the kernel automatically
+* based on the DRM_I915_GEM_SET_CACHING IOCTL setting and the current
+* usage of the surface (used for display scanout or not).
+*/
+ I915_MOCS_PTE,
+ /*
+* Cached in all GPU caches available on the platform.
+* Coherency between CPU and GPU accesses to the surface is not
+* guaranteed without extra synchronization.
+*/
+ I915_MOCS_CACHED,
+};
+
/* Each region is a minimum of 16k, and there are at most 255 of them.
*/
#define I915_NR_TEX_REGIONS 255/* table size 2k - maximum due to use
@@ -218,6 +246,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_OVERLAY_PUT_IMAGE 0x27
#define DRM_I915_OVERLAY_ATTRS 0x28
#define DRM_I915_GEM_EXECBUFFER2 0x29
+#define DRM_I915_GEM_EXECBUFFER2_WRDRM_I915_GEM_EXECBUFFER2
#define DRM_I915_GET_SPRITE_COLORKEY 0x2a
#define DRM_I915_SET_SPRITE_COLORKEY 0x2b
#define DRM_I915_GEM_WAIT 0x2c
@@ -230,6 +259,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_USERPTR 0x33
#define DRM_I915_GEM_CONTEXT_GETPARAM 0x34
#define DRM_I915_GEM_CONTEXT_SETPARAM 0x35
+#define DRM_I915_PERF_OPEN 0x36
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -251,6 +281,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_INITDRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_INIT, struct drm_i915_gem_init)
#define DRM_IOCTL_I915_GEM_EXECBUFFER DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER, struct drm_i915_gem_execbuffer)
#define DRM_IOCTL_I915_GEM_EXECBUFFER2 DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER2, struct drm_i915_gem_execbuffer2)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER2_WR DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER2_WR, struct drm_i915_gem_execbuffer2)
#define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
#define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
#define DRM_IOCTL_I915_GEM_BUSYDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
@@ -283,6 +314,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
#define DRM_IOCTL_I915_GEM_CONTEXT_GETPARAMDRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_GETPARAM, struct drm_i915_gem_context_param)
#define DRM_IOCTL_I915_GEM_CONTEXT_SETPARAMDRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_SETPARAM, struct drm_i915_gem_context_param)
+#define DRM_IOCTL_I915_PERF_OPEN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -357,8 +389,28 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_GPU_RESET35
#define I915_PARAM_HAS_RESOURCE_STREAMER 36
#define I915_PARAM_HAS_EXEC_SOFTPIN 37
-#define I915_PARAM_HAS_POOLED_EU 38
-#define I915_PARAM_MIN_EU_IN_POOL39
+#define I915_PARAM_HAS_POOLED_EU38
+#define I915_PARAM_MIN_EU_IN_POOL 39
+#define I915_PARAM_MMAP_GTT_VERSION 40
+
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
+ * priorities and the driver will attempt to execute batches in priority order.
+ */
+#define I915_PARAM_HAS_SCHEDULER41
+#define I915_PARAM_HUC_STATUS 42
+
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of
+ * synchronisation with implicit fencing on individual objects.
+ * See EXEC_OBJECT_ASYNC.
+ */
+#define I915_PARAM_HAS_EXEC_ASYNC 43
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Fri, Jan 27, 2017 at 03:51:34PM +0200, Jani Nikula wrote:
> On Fri, 27 Jan 2017, Ville Syrjälä wrote:
> > On Fri, Jan 27, 2017 at 12:08:58PM +0200, Jani Nikula wrote:
> >> On Thu, 26 Jan 2017, Pierre-Louis Bossart
> >> wrote:
> >> > Enable chicken bit on LPE mode setup and unmute amp on
> >> > notification
> >> >
> >> > FIXME: should these two phases done somewhere else?
> >> >
> >> > Signed-off-by: Pierre-Louis Bossart
> >> >
> >> > ---
> >> > drivers/gpu/drm/i915/i915_reg.h| 12
> >> > drivers/gpu/drm/i915/intel_lpe_audio.c | 27 +++
> >> > 2 files changed, 39 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> > b/drivers/gpu/drm/i915/i915_reg.h
> >> > index a9ffc8d..ee90f64 100644
> >> > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> > @@ -2061,6 +2061,18 @@ enum skl_disp_power_wells {
> >> > #define I915_HDMI_LPE_AUDIO_BASE(VLV_DISPLAY_BASE + 0x65000)
> >> > #define I915_HDMI_LPE_AUDIO_SIZE0x1000
> >> >
> >> > +/* DisplayPort Audio w/ LPE */
> >> > +#define CHICKEN_BIT_DBG_ENABLE (1 << 0)
> >> > +#define AMP_UNMUTE (1 << 1)
> >
> > That should be called AMP_MUTE I think,
> >
> >>
> >> The convention is to define registers first and the contents/bits for
> >> each register immedialy below. For groups of registers (like
> >> PORT_EN_B/C/D below) define all registers first and bits immediately
> >> below. (But note that the chicken register is not part of the group.)
> >>
> >> > +#define AUD_CHICKEN_BIT_REG 0x62F38
> >
> > Spec calls this AUD_CHICKENBIT_REG. Might as well follow it to the
> > letter.
> >
> >> > +#define AUD_PORT_EN_B_DBG 0x62F20
> >> > +#define AUD_PORT_EN_C_DBG 0x62F28
> >> > +#define AUD_PORT_EN_D_DBG 0x62F2C
> >
> > These match the spec. But to match the standard i915 convention they
> > should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit
> > register.
> >
> >>
> >> Please don't define these separately without the display base, use
> >> (VLV_DISPLAY_BASE + 0x62f38) style instead. All the other uses of
> >> VLV_DISPLAY_BASE in the file follow the same convention.
> >>
> >> > +#define VLV_AUD_CHICKEN_BIT_REG _MMIO(VLV_DISPLAY_BASE +
> >> > AUD_CHICKEN_BIT_REG)
> >> > +#define VLV_AUD_PORT_EN_B_DBG _MMIO(VLV_DISPLAY_BASE +
> >> > AUD_PORT_EN_B_DBG)
> >> > +#define VLV_AUD_PORT_EN_C_DBG _MMIO(VLV_DISPLAY_BASE +
> >> > AUD_PORT_EN_C_DBG)
> >> > +#define VLV_AUD_PORT_EN_D_DBG _MMIO(VLV_DISPLAY_BASE +
> >> > AUD_PORT_EN_D_DBG)
> >> > +
> >>
> >> Would be nice to have a macro VLV_AUD_PORT_EN_DBG(port), but damn those
> >> reg offsets don't make it easy...
> >
> > _MMIO_PORT3().
>
> Works for ports A, B, C, but here we have ports B, C, D.
(port)-PORT_B is easy enough to stick in there ;)
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/8] drm/i915/tracepoints: Rename i915_gem_request_notify
On 27/01/2017 12:20, Chris Wilson wrote: On Fri, Jan 27, 2017 at 12:01:25PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin i915_gem_ring_notify is more appropriate since we do not have the request information at this point, but it is simply a signal from the engine that some request has been completed. I was going to suggest intel_engine_notify. Yeah I know, but i915_trace.h seemed like a last remaining bastion of rings so I narrowly tipped to stick with it. But can change it just as well. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_stolen_to_physical() return phys_addr_t
On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote:
> The i915_stolen_to_physical() function has 'unsigned long' as its
> return type but it returns the 'base' variable, which is of type
> 'u32'. The only place where this function is called assigns the
> returned value to dev_priv->mm.stolen_base, which is of type
> 'phys_addr_t'. The return value is actually a physical address and
> everything else in the stolen memory code seems to be using
> phys_addr_t, so fix i915_stolen_to_physical() to use phys_addr_t.
Size of phys_addr_t depends on PAE no? So what if someone were to boot
a !PAE kernel on a machine where stolen lives somewhere >4GiB?
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 127d698..0816ebd 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -79,12 +79,12 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
> *dev_priv,
> mutex_unlock(&dev_priv->mm.stolen_lock);
> }
>
> -static unsigned long i915_stolen_to_physical(struct drm_i915_private
> *dev_priv)
> +static phys_addr_t i915_stolen_to_physical(struct drm_i915_private *dev_priv)
> {
> struct pci_dev *pdev = dev_priv->drm.pdev;
> struct i915_ggtt *ggtt = &dev_priv->ggtt;
> struct resource *r;
> - u32 base;
> + phys_addr_t base;
>
> /* Almost universally we can find the Graphics Base of Stolen Memory
>* at register BSM (0x5c) in the igfx configuration space. On a few
> @@ -196,7 +196,7 @@ static unsigned long i915_stolen_to_physical(struct
> drm_i915_private *dev_priv)
> if (INTEL_GEN(dev_priv) <= 4 &&
> !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv) && !IS_G4X(dev_priv)) {
> struct {
> - u32 start, end;
> + phys_addr_t start, end;
> } stolen[2] = {
> { .start = base, .end = base + ggtt->stolen_size, },
> { .start = base, .end = base + ggtt->stolen_size, },
> @@ -228,11 +228,12 @@ static unsigned long i915_stolen_to_physical(struct
> drm_i915_private *dev_priv)
>
> if (stolen[0].start != stolen[1].start ||
> stolen[0].end != stolen[1].end) {
> + phys_addr_t end = base + ggtt->stolen_size - 1;
> DRM_DEBUG_KMS("GTT within stolen memory at
> 0x%llx-0x%llx\n",
> (unsigned long long)ggtt_start,
> (unsigned long long)ggtt_end - 1);
> - DRM_DEBUG_KMS("Stolen memory adjusted to 0x%x-0x%x\n",
> - base, base + (u32)ggtt->stolen_size - 1);
> + DRM_DEBUG_KMS("Stolen memory adjusted to %pa - %pa\n",
> + &base, &end);
> }
> }
>
> @@ -261,8 +262,9 @@ static unsigned long i915_stolen_to_physical(struct
> drm_i915_private *dev_priv)
>* range. Apparently this works.
>*/
> if (r == NULL && !IS_GEN3(dev_priv)) {
> - DRM_ERROR("conflict detected with stolen region:
> [0x%08x - 0x%08x]\n",
> - base, base + (uint32_t)ggtt->stolen_size);
> + phys_addr_t end = base + ggtt->stolen_size;
> + DRM_ERROR("conflict detected with stolen region: [%pa -
> %pa]\n",
> + &base, &end);
> base = 0;
> }
> }
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints
On 27/01/2017 12:27, Chris Wilson wrote: On Fri, Jan 27, 2017 at 12:01:26PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Two new tracepoints placed at the call sites where requests are actually passed to the GPU enable userspace to track engine utilisation. These tracepoints are only enabled when the DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option is enabled. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_guc_submission.c | 2 ++ drivers/gpu/drm/i915/i915_trace.h | 49 ++ drivers/gpu/drm/i915/intel_lrc.c | 4 +++ 3 files changed, 55 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 8ced9e26f075..beec88a30347 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -518,6 +518,8 @@ static void __i915_guc_submit(struct drm_i915_gem_request *rq) if (i915_vma_is_map_and_fenceable(rq->ring->vma)) POSTING_READ_FW(GUC_STATUS); + trace_i915_gem_request_in(rq, 0); But how to get out for guc? We could do a similar in for ringbuffer. The original way I used it was in == dispatch, out == ring-notify, which is why trace_i915_gem_ring_dispatch enabled the signaling. That was my thinking as well. Hmm. Following on from that we can add the out tracepoint as a fence-callback. For the moment, I'd drop guc/legacy trace_i915_gem_request_in and we will try something more magical. Though once we do enable the fake GuC scheduler we will have an appropriate place to drop an trace_i915_gem_request_out. Just leaving ringbuffer as the odd one out, but for who arguably the in/out logic is not as important. Fence signalled is very lazy if no one is listening, no? So until the GUC backend I thought request_in and deriving the _out from _notify in userspace would be OK. Meaning enable signalling stays until then. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints
On Fri, Jan 27, 2017 at 01:59:54PM +, Tvrtko Ursulin wrote: > On 27/01/2017 12:27, Chris Wilson wrote: > >Hmm. Following on from that we can add the out tracepoint as a > >fence-callback. For the moment, I'd drop guc/legacy > >trace_i915_gem_request_in and we will try something more magical. Though > >once we do enable the fake GuC scheduler we will have an appropriate > >place to drop an trace_i915_gem_request_out. Just leaving ringbuffer as > >the odd one out, but for who arguably the in/out logic is not as > >important. > > Fence signalled is very lazy if no one is listening, no? So until > the GUC backend I thought request_in and deriving the _out from > _notify in userspace would be OK. Meaning enable signalling stays > until then. It's lazy unless we use fence_add_callback(). I was thinking of some magic inside the trace_request_in macro to add something like fence_add_callback(this_fence, __trace_request_out); It still has the problem request_out doesn't work unless request_in is also being watched, but it has the advantage of being the same for all generators (i.e. more convenient for userspace). But as it seems limited to ringbuffer, we may consider it no longer required? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC 6/5] drm/i915: Merge BDW pipe gamma and degamma table code
On Fri, Jan 27, 2017 at 11:19:49AM +0200, Ander Conselvan de Oliveira wrote:
> The only difference between the code loading the pipe gamma and degamma
> tables in BDW is that the gamma code also writes the registers that hold
> the maximum values. So we can use the gamma code for the degamma table,
> at the expense of writing the maximum value register twice, with
> potenttially wrong values in the first time.
>
> Cc: Ville Syrjälä
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
>
> Ville, does this help with the split gamma enable/disable confusion?
I might. Certainly it avoids a bunch of duplicated code. One comment
below...
>
> Note that I didn't test this.
>
> Ander
>
> ---
> drivers/gpu/drm/i915/intel_color.c | 57
> ++
> 1 file changed, 15 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 08345e5..c686c37 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -340,54 +340,22 @@ static void haswell_load_luts(struct drm_crtc_state
> *crtc_state)
> hsw_enable_ips(intel_crtc);
> }
>
> -static void bdw_load_degamma_lut(struct drm_crtc_state *state)
> +static void bdw_load_lut(struct drm_crtc_state *state, u32 offset,
> + struct drm_color_lut *lut, u32 lut_size,
> + bool split_mode)
Maybe pass PAL_PREC_SPLIT_MODE or 0 here directly? To make the callers
even more clear we could go as far as defining a symbolic name for the 0.
> {
> struct drm_i915_private *dev_priv = to_i915(state->crtc->dev);
> enum pipe pipe = to_intel_crtc(state->crtc)->pipe;
> - uint32_t i, lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> -
> - I915_WRITE(PREC_PAL_INDEX(pipe),
> -PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT);
> -
> - if (state->degamma_lut) {
> - struct drm_color_lut *lut =
> - (struct drm_color_lut *) state->degamma_lut->data;
> -
> - for (i = 0; i < lut_size; i++) {
> - uint32_t word =
> - drm_color_lut_extract(lut[i].red, 10) << 20 |
> - drm_color_lut_extract(lut[i].green, 10) << 10 |
> - drm_color_lut_extract(lut[i].blue, 10);
> -
> - I915_WRITE(PREC_PAL_DATA(pipe), word);
> - }
> - } else {
> - for (i = 0; i < lut_size; i++) {
> - uint32_t v = (i * ((1 << 10) - 1)) / (lut_size - 1);
> -
> - I915_WRITE(PREC_PAL_DATA(pipe),
> -(v << 20) | (v << 10) | v);
> - }
> - }
> -}
> -
> -static void bdw_load_gamma_lut(struct drm_crtc_state *state, u32 offset)
> -{
> - struct drm_i915_private *dev_priv = to_i915(state->crtc->dev);
> - enum pipe pipe = to_intel_crtc(state->crtc)->pipe;
> - uint32_t i, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
> + uint32_t i;
>
> WARN_ON(offset & ~PAL_PREC_INDEX_VALUE_MASK);
>
> I915_WRITE(PREC_PAL_INDEX(pipe),
> -(offset ? PAL_PREC_SPLIT_MODE : 0) |
> +(split_mode ? PAL_PREC_SPLIT_MODE : 0) |
> PAL_PREC_AUTO_INCREMENT |
> offset);
>
> - if (state->gamma_lut) {
> - struct drm_color_lut *lut =
> - (struct drm_color_lut *) state->gamma_lut->data;
> -
> + if (lut) {
> for (i = 0; i < lut_size; i++) {
> uint32_t word =
> (drm_color_lut_extract(lut[i].red, 10) << 20) |
> @@ -430,9 +398,12 @@ static void broadwell_load_luts(struct drm_crtc_state
> *state)
> return;
> }
>
> - bdw_load_degamma_lut(state);
> - bdw_load_gamma_lut(state,
> -INTEL_INFO(dev_priv)->color.degamma_lut_size);
> + bdw_load_lut(state, 0, (struct drm_color_lut *) state->degamma_lut,
> + INTEL_INFO(dev_priv)->color.degamma_lut_size, true);
> + bdw_load_lut(state, INTEL_INFO(dev_priv)->color.degamma_lut_size,
> + (struct drm_color_lut *) state->gamma_lut,
> + INTEL_INFO(dev_priv)->color.gamma_lut_size,
> + true);
>
> intel_state->gamma_mode = GAMMA_MODE_MODE_SPLIT;
> I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_SPLIT);
> @@ -489,7 +460,9 @@ static void glk_load_luts(struct drm_crtc_state *state)
> }
>
> glk_load_degamma_lut(state);
> - bdw_load_gamma_lut(state, 0);
> + bdw_load_lut(state, 0, (struct drm_color_lut *) state->gamma_lut,
> + INTEL_INFO(dev_priv)->color.gamma_lut_size,
> + false);
>
> intel_state->gamma_mode = GAMMA_MODE_MODE_10BIT;
> I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_10BIT);
> --
> 2.9.3
--
Ville Syrjälä
Intel OTC
___
Re: [Intel-gfx] [PATCH] drm/i915: fix use-after-free in page_flip_completed()
On Thu, Jan 26, 2017 at 02:46:20PM +, Chris Wilson wrote:
> On Thu, Jan 26, 2017 at 05:32:11PM +0300, Andrey Ryabinin wrote:
> > page_flip_completed() dereferences 'work' variable after executing
> > queue_work(). This is not safe as the 'work' item might be already freed
> > by queued work:
> >
> > BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr
> > 8803dc010f90
> > Call Trace:
> > __asan_report_load8_noabort+0x59/0x80
> > page_flip_completed+0x3ff/0x490
> > intel_finish_page_flip_mmio+0xe3/0x130
> > intel_pipe_handle_vblank+0x2d/0x40
> > gen8_irq_handler+0x4a7/0xed0
> > __handle_irq_event_percpu+0xf6/0x860
> > handle_irq_event_percpu+0x6b/0x160
> > handle_irq_event+0xc7/0x1b0
> > handle_edge_irq+0x1f4/0xa50
> > handle_irq+0x41/0x70
> > do_IRQ+0x9a/0x200
> > common_interrupt+0x89/0x89
> >
> > Freed:
> > kfree+0x113/0x4d0
> > intel_unpin_work_fn+0x29a/0x3b0
> > process_one_work+0x79e/0x1b70
> > worker_thread+0x611/0x1460
> > kthread+0x241/0x3a0
> > ret_from_fork+0x27/0x40
> >
> > Move queue_work() after trace_i915_flip_complete() to fix this.
> >
> > Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests &
> > completions")
> > Signed-off-by: Andrey Ryabinin
>
> That's old, and indeed does seem to be present from that commit and not
> exposed by something later.
>
> Cc: # v2.6.36+
> Reviewed-by: Chris Wilson
Applied, thanks for patch&review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: minor corner case fix to respect user's backlight setting
On Fri, 27 Jan 2017, Harry Pan wrote:
> When enabling panel backlight, if the current backlight level
> setting matches the panel's minimal, it would apply default policy to
> override the current level by the panel's maximum until next request
> to update brightness, this leads unexpected user confusion with
> temporary full power backlight.
>
> This odd could be reproduced as commands like these:
> $ xbacklight -set 0
> $ sudo sh -c 'echo mem > /sys/power/state'
> (resume)
>
> To fix this, slightly tinker the backlight level comparison from
> 'less-and-equal-to' to 'less-than'.
>
> Before: (dmesg | grep backlight # with drm.debug=0xe)
> [ 82.249265] [drm:intel_backlight_device_update_status [i915]] updating
> intel_backlight, brightness=0/5273
> [ 82.249282] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 207
> [ 82.249306] [drm:intel_edp_backlight_power [i915]] panel power control
> backlight disable
> [ 92.066041] [drm:intel_edp_backlight_off [i915]]
> [ 92.270489] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 0
> [ 94.080434] [drm:intel_edp_backlight_on.part.25 [i915]]
> [ 94.080476] [drm:intel_panel_enable_backlight [i915]] pipe A
> [ 94.080539] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 5273
>
> After:
> [ 72.874465] [drm:intel_backlight_device_update_status [i915]] updating
> intel_backlight, brightness=0/5273
> [ 72.874499] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 207
> [ 72.874540] [drm:intel_edp_backlight_power [i915]] panel power control
> backlight disable
> [ 86.807928] [drm:intel_edp_backlight_off [i915]]
> [ 87.013227] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 0
> [ 89.001829] [drm:intel_edp_backlight_on.part.25 [i915]]
> [ 89.001859] [drm:intel_panel_enable_backlight [i915]] pipe A
> [ 89.001926] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 207
>
> Fixes: 13f3fbe827d0 ("fix inconsistent brightness after resume")
That reference is not really true. We've had this policy of setting the
backlight to max at enable if it was previously zero for eons. Yes, it's
policy, not mechanism, but it's basically ABI.
For some reason the expectation is that the sequence:
1. set backlight to 0
2. dpms off
3. dpms on
does not lead to a black screen regardless of the user request to have 0
backlight. Your change breaks this.
> Signed-off-by: Harry Pan ---
>drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1
>insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 08ab6d7..e882139 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1104,7 +1104,7 @@ void intel_panel_enable_backlight(struct
> intel_connector *connector)
>
> WARN_ON(panel->backlight.max == 0);
>
> - if (panel->backlight.level <= panel->backlight.min) {
> + if (panel->backlight.level < panel->backlight.min) {
> panel->backlight.level = panel->backlight.max;
If we changed this to follow your logic, the sensible thing to do would
be to set the backlight to min, not max, in this case.
But the point is moot. I don't want to deal with the regressions that I
predict the change will inevitably cause.
BR,
Jani.
> if (panel->backlight.device)
> panel->backlight.device->props.brightness =
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/glk: Program pipe gamma and degamma tables
On Fri, Jan 27, 2017 at 11:02:30AM +0200, Ander Conselvan de Oliveira wrote:
> The gamma tables in Geminilake were changed. There is no split-gamma
> mode. Instead, there is a dedicated degamma table that is enabled
> whenever pipe CSC is enabled.
>
> The dedicated gamma table has 16 bit precision but doesn't support
> separate channels. Since that doesn't match the per-channel format of
> the degamma LUT property, for now only a linear table is loaded and the
> property ignored.
>
> v2: Remove empty line. (Ville)
> Reuse broadwell code. (Ville)
>
> v3: Don't write PIPE_CSC_MODE. (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Ander Conselvan de Oliveira
>
lgtm
Reviewed-by: Ville Syrjälä
>
> Don't write CSC_MODE
> ---
> drivers/gpu/drm/i915/i915_pci.c| 1 +
> drivers/gpu/drm/i915/i915_reg.h| 14 +
> drivers/gpu/drm/i915/intel_color.c | 58
> +-
> 3 files changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ecb487b..df2051b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -403,6 +403,7 @@ static const struct intel_device_info
> intel_geminilake_info = {
> .platform = INTEL_GEMINILAKE,
> .is_alpha_support = 1,
> .ddb_size = 1024,
> + .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> };
>
> static const struct intel_device_info intel_kabylake_info = {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 06bbe55..e029691 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8181,12 +8181,26 @@ enum {
> #define _PAL_PREC_EXT_GC_MAX_A 0x4A420
> #define _PAL_PREC_EXT_GC_MAX_B 0x4AC20
> #define _PAL_PREC_EXT_GC_MAX_C 0x4B420
> +#define _PAL_PREC_EXT2_GC_MAX_A 0x4A430
> +#define _PAL_PREC_EXT2_GC_MAX_B 0x4AC30
> +#define _PAL_PREC_EXT2_GC_MAX_C 0x4B430
>
> #define PREC_PAL_INDEX(pipe) _MMIO_PIPE(pipe, _PAL_PREC_INDEX_A,
> _PAL_PREC_INDEX_B)
> #define PREC_PAL_DATA(pipe) _MMIO_PIPE(pipe, _PAL_PREC_DATA_A,
> _PAL_PREC_DATA_B)
> #define PREC_PAL_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A,
> _PAL_PREC_GC_MAX_B) + (i) * 4)
> #define PREC_PAL_EXT_GC_MAX(pipe, i) _MMIO(_PIPE(pipe,
> _PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
>
> +#define _PRE_CSC_GAMC_INDEX_A0x4A484
> +#define _PRE_CSC_GAMC_INDEX_B0x4AC84
> +#define _PRE_CSC_GAMC_INDEX_C0x4B484
> +#define PRE_CSC_GAMC_AUTO_INCREMENT(1 << 10)
> +#define _PRE_CSC_GAMC_DATA_A 0x4A488
> +#define _PRE_CSC_GAMC_DATA_B 0x4AC88
> +#define _PRE_CSC_GAMC_DATA_C 0x4B488
> +
> +#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
> _PRE_CSC_GAMC_INDEX_B)
> +#define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
> _PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
> +
> /* pipe CSC & degamma/gamma LUTs on CHV */
> #define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
> #define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 82a3bc9..0627eee 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -380,7 +380,9 @@ static void bdw_load_gamma_lut(struct drm_crtc_state
> *state, u32 offset)
> WARN_ON(offset & ~PAL_PREC_INDEX_VALUE_MASK);
>
> I915_WRITE(PREC_PAL_INDEX(pipe),
> -PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT | offset);
> +(offset ? PAL_PREC_SPLIT_MODE : 0) |
> +PAL_PREC_AUTO_INCREMENT |
> +offset);
>
> if (state->gamma_lut) {
> struct drm_color_lut *lut =
> @@ -443,6 +445,57 @@ static void broadwell_load_luts(struct drm_crtc_state
> *state)
> I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> }
>
> +static void glk_load_degamma_lut(struct drm_crtc_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->crtc->dev);
> + enum pipe pipe = to_intel_crtc(state->crtc)->pipe;
> + const uint32_t lut_size = 33;
> + uint32_t i;
> +
> + /*
> + * When setting the auto-increment bit, the hardware seems to
> + * ignore the index bits, so we need to reset it to index 0
> + * separately.
> + */
> + I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
> + I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), PRE_CSC_GAMC_AUTO_INCREMENT);
> +
> + /*
> + * FIXME: The pipe degamma table in geminilake doesn't support
> + * different values per channel, so this just loads a linear table.
> + */
> + for (i = 0; i < lut_size; i++) {
> + uint32_t v = (i * ((1 << 16) - 1)) / (lut_size - 1);
> +
> + I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
> + }
> +
> + /* Clamp values > 1.0. */
> + while (i++ < 35
Re: [Intel-gfx] [alsa-devel] [PATCH RFC 1/3] drm/i915: Avoid MST pipe handling for LPE audio
On 01/27/2017 04:36 AM, Takashi Iwai wrote:
The pipe gets cleared to -1 for non-MST before the ELD audio
notification due to the MST audio support. This makes sense for
HD-audio that received the MST handling, but it's useless for LPE
audio. Handle the MST pipe hack conditionally only for HD-audio.
Reported-by: Pierre-Louis Bossart
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_audio.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 1645ce42b898..d4e6d1136cfe 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -624,13 +624,14 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder,
dev_priv->av_enc_map[pipe] = intel_encoder;
mutex_unlock(&dev_priv->av_mutex);
- /* audio drivers expect pipe = -1 to indicate Non-MST cases */
- if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
- pipe = -1;
-
- if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+ if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+ /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+ if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+ pipe = -1;
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
+ }
+
Cool. I missed this part, couldn't figure out where the -1 was coming from.
So do you get audio working on both of the DP ports now?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH RFC 1/3] drm/i915: Avoid MST pipe handling for LPE audio
On Fri, 27 Jan 2017 15:15:14 +0100,
Pierre-Louis Bossart wrote:
>
>
>
> On 01/27/2017 04:36 AM, Takashi Iwai wrote:
> > The pipe gets cleared to -1 for non-MST before the ELD audio
> > notification due to the MST audio support. This makes sense for
> > HD-audio that received the MST handling, but it's useless for LPE
> > audio. Handle the MST pipe hack conditionally only for HD-audio.
> >
> > Reported-by: Pierre-Louis Bossart
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/gpu/drm/i915/intel_audio.c | 21 +++--
> > 1 file changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 1645ce42b898..d4e6d1136cfe 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -624,13 +624,14 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder,
> > dev_priv->av_enc_map[pipe] = intel_encoder;
> > mutex_unlock(&dev_priv->av_mutex);
> > - /* audio drivers expect pipe = -1 to indicate Non-MST cases */
> > - if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
> > - pipe = -1;
> > -
> > - if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> > + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
> > + /* audio drivers expect pipe = -1 to indicate Non-MST cases */
> > + if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
> > + pipe = -1;
> > acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> > (int) port, (int) pipe);
> > + }
> > +
> Cool. I missed this part, couldn't figure out where the -1 was coming from.
> So do you get audio working on both of the DP ports now?
DP1 is working now.
DP3 starts streaming, but no audio came out yet :-<
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints
On 27/01/2017 14:07, Chris Wilson wrote: On Fri, Jan 27, 2017 at 01:59:54PM +, Tvrtko Ursulin wrote: On 27/01/2017 12:27, Chris Wilson wrote: Hmm. Following on from that we can add the out tracepoint as a fence-callback. For the moment, I'd drop guc/legacy trace_i915_gem_request_in and we will try something more magical. Though once we do enable the fake GuC scheduler we will have an appropriate place to drop an trace_i915_gem_request_out. Just leaving ringbuffer as the odd one out, but for who arguably the in/out logic is not as important. Fence signalled is very lazy if no one is listening, no? So until the GUC backend I thought request_in and deriving the _out from _notify in userspace would be OK. Meaning enable signalling stays until then. It's lazy unless we use fence_add_callback(). I was thinking of some magic inside the trace_request_in macro to add something like fence_add_callback(this_fence, __trace_request_out); It still has the problem request_out doesn't work unless request_in is also being watched, but it has the advantage of being the same for all generators (i.e. more convenient for userspace). But as it seems limited to ringbuffer, we may consider it no longer required? You mean bank on the GUC backend getting in soon? Yeah, that sounds reasonable. I'll drop the sw signalling from notify then. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > When writing some testcases for nonblocking modesets. I found out that the > > infinite wait on the old fb was causing issues. > > The crux of the issue here is the locked wait for old dependencies and > the inability to inject the intel_prepare_reset disabling of all planes. > There are a couple of locked waits on struct_mutex within the modeset > locks for intel_overlay and if we happen to be using the display plane > for the first time. > > The first I suggested solving using fences to track dependencies and > keep the order between atomic states. Cancelling the outstanding > modesets, replacing with a disable and then on restore jumping to the > final state look doable. It also requires avoiding the struct_mutex for > disabling, which is quite easy. To avoid the wait under struct_mutex, > we've talked about switching to mmio, but for starters we could move the > wait from inside intel_overlay into the fence for the atomic operation. > (But's that a little more surgery than we would like for intel_overlay I > guess - dig out Ville's patches for overlay planes?) And to prevent the > wait under struct_mutex for pin_to_display_plane, my plane is to move > that to an async fenced operation that is then naturally waited upon by > the atomic modeset. A bit more a hack, but a different idea, and I think hack for gen234.0 is ok: We complete all the requests before we start the hw reset with fence.error = -EIO. But we do this only when we need to get at the display locks. A slightly more elegant solution would be to trylock modeset locks, and if one of them fails (and only then) complete all requests with -EIO to get the concurrent modeset to proceed before we reset the hardware. That's essentially the logic we had before all the reworks, and it worked. But I didn't look at how scary that all would be to make it work again ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_stolen_to_physical() return phys_addr_t
On Fri, Jan 27, 2017 at 03:59:19PM +0200, Ville Syrjälä wrote: > On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote: > > The i915_stolen_to_physical() function has 'unsigned long' as its > > return type but it returns the 'base' variable, which is of type > > 'u32'. The only place where this function is called assigns the > > returned value to dev_priv->mm.stolen_base, which is of type > > 'phys_addr_t'. The return value is actually a physical address and > > everything else in the stolen memory code seems to be using > > phys_addr_t, so fix i915_stolen_to_physical() to use phys_addr_t. > > Size of phys_addr_t depends on PAE no? So what if someone were to boot > a !PAE kernel on a machine where stolen lives somewhere >4GiB? dma_addr_t should be correct there, right? And in effect we do regard this as only dma accessible, so the white lie would have some nice semantic benefits. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 7/8] drm/i915/tracepoints: Add backend level request in and out tracepoints
On Fri, Jan 27, 2017 at 02:18:06PM +, Tvrtko Ursulin wrote: > > On 27/01/2017 14:07, Chris Wilson wrote: > >On Fri, Jan 27, 2017 at 01:59:54PM +, Tvrtko Ursulin wrote: > >>On 27/01/2017 12:27, Chris Wilson wrote: > >>>Hmm. Following on from that we can add the out tracepoint as a > >>>fence-callback. For the moment, I'd drop guc/legacy > >>>trace_i915_gem_request_in and we will try something more magical. Though > >>>once we do enable the fake GuC scheduler we will have an appropriate > >>>place to drop an trace_i915_gem_request_out. Just leaving ringbuffer as > >>>the odd one out, but for who arguably the in/out logic is not as > >>>important. > >> > >>Fence signalled is very lazy if no one is listening, no? So until > >>the GUC backend I thought request_in and deriving the _out from > >>_notify in userspace would be OK. Meaning enable signalling stays > >>until then. > > > >It's lazy unless we use fence_add_callback(). I was thinking of some > >magic inside the trace_request_in macro to add something like > >fence_add_callback(this_fence, __trace_request_out); > > > >It still has the problem request_out doesn't work unless request_in is > >also being watched, but it has the advantage of being the same for all > >generators (i.e. more convenient for userspace). > > > >But as it seems limited to ringbuffer, we may consider it no longer > >required? > > You mean bank on the GUC backend getting in soon? Yeah, that sounds > reasonable. I'll drop the sw signalling from notify then. Considering Joonas asks quite regularly "are we nearly there yet", I think so. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 03:21:29PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > > When writing some testcases for nonblocking modesets. I found out that the > > > infinite wait on the old fb was causing issues. > > > > The crux of the issue here is the locked wait for old dependencies and > > the inability to inject the intel_prepare_reset disabling of all planes. > > There are a couple of locked waits on struct_mutex within the modeset > > locks for intel_overlay and if we happen to be using the display plane > > for the first time. > > > > The first I suggested solving using fences to track dependencies and > > keep the order between atomic states. Cancelling the outstanding > > modesets, replacing with a disable and then on restore jumping to the > > final state look doable. It also requires avoiding the struct_mutex for > > disabling, which is quite easy. To avoid the wait under struct_mutex, > > we've talked about switching to mmio, but for starters we could move the > > wait from inside intel_overlay into the fence for the atomic operation. > > (But's that a little more surgery than we would like for intel_overlay I > > guess - dig out Ville's patches for overlay planes?) And to prevent the > > wait under struct_mutex for pin_to_display_plane, my plane is to move > > that to an async fenced operation that is then naturally waited upon by > > the atomic modeset. > > A bit more a hack, but a different idea, and I think hack for gen234.0 is > ok: > > We complete all the requests before we start the hw reset with fence.error > = -EIO. But we do this only when we need to get at the display locks. A > slightly more elegant solution would be to trylock modeset locks, and if > one of them fails (and only then) complete all requests with -EIO to get > the concurrent modeset to proceed before we reset the hardware. That's > essentially the logic we had before all the reworks, and it worked. But I > didn't look at how scary that all would be to make it work again ... The modeset lock may not just be waiting on our requests (even on pnv we can expect that there are already users celebrating that pnv+nouveau finally works ;) and that the display is not the only user/observer of those requests. Using the requests to break the modeset lock just feels like the wrong approach. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Fri, Jan 27, 2017 at 03:17:34PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 27, 2017 at 12:08:58PM +0200, Jani Nikula wrote:
> > On Thu, 26 Jan 2017, Pierre-Louis Bossart
> > wrote:
> > > Enable chicken bit on LPE mode setup and unmute amp on
> > > notification
> > >
> > > FIXME: should these two phases done somewhere else?
> > >
> > > Signed-off-by: Pierre-Louis Bossart
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h| 12
> > > drivers/gpu/drm/i915/intel_lpe_audio.c | 27 +++
> > > 2 files changed, 39 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index a9ffc8d..ee90f64 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -2061,6 +2061,18 @@ enum skl_disp_power_wells {
> > > #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
> > > #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
> > >
> > > +/* DisplayPort Audio w/ LPE */
> > > +#define CHICKEN_BIT_DBG_ENABLE (1 << 0)
> > > +#define AMP_UNMUTE (1 << 1)
>
> That should be called AMP_MUTE I think,
>
> >
> > The convention is to define registers first and the contents/bits for
> > each register immedialy below. For groups of registers (like
> > PORT_EN_B/C/D below) define all registers first and bits immediately
> > below. (But note that the chicken register is not part of the group.)
> >
> > > +#define AUD_CHICKEN_BIT_REG 0x62F38
>
> Spec calls this AUD_CHICKENBIT_REG. Might as well follow it to the
> letter.
>
> > > +#define AUD_PORT_EN_B_DBG0x62F20
> > > +#define AUD_PORT_EN_C_DBG0x62F28
> > > +#define AUD_PORT_EN_D_DBG0x62F2C
>
> These match the spec. But to match the standard i915 convention they
> should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit
> register.
Actually they just match one version of the spec I had lying around.
Another versions says:
AUD_PORT_EN_B_DBG 0x62F20
AUD_PORT_EN_C_DBG 0x62F30
AUD_PORT_EN_D_DBG 0x62F34
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/color: un-inline drm_color_lut_extract()
On Fri, 27 Jan 2017, Jani Nikula wrote:
> On Fri, 27 Jan 2017, Lionel Landwerlin wrote:
>> Hi Jani,
>>
>> Looks good to me :
>>
>> Reviewed-by: Lionel Landwerlin
>
> Thanks for the reviews, pushed... to drm-intel-next-queued instead of
> drm-misc-next. /o\
>
> Dave, Daniel, please advise, shall I revert or shall we let this flow in
> via drm-intel?
>
> Sorry for the mess.
Reverted, there was a conflict in the docs updates as well so this is
easier. I'll post a rebase version of the patch.
BR,
Jani.
>
> BR,
> Jani.
>
>
>
>>
>> On 23/01/17 09:42, Jani Nikula wrote:
>>> The function is not that big, but it's also not used for anything
>>> performance critical. Make it a normal function.
>>>
>>> As a side effect, this apparently makes sparse smarter about what it's
>>> doing, and gets rid of the warning:
>>>
>>> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295)
>>> for type unsigned long
>>> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
>>> constant value (8000 becomes 0)
>>>
>>> Cc: Lionel Landwerlin
>>> Signed-off-by: Jani Nikula
>>> ---
>>> drivers/gpu/drm/drm_color_mgmt.c | 24
>>> include/drm/drm_color_mgmt.h | 27 ++-
>>> 2 files changed, 26 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>>> b/drivers/gpu/drm/drm_color_mgmt.c
>>> index 789b4c65cd69..5618f60c7690 100644
>>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>>> @@ -88,6 +88,30 @@
>>>*/
>>>
>>> /**
>>> + * drm_color_lut_extract - clamp&round LUT entries
>>> + * @user_input: input value
>>> + * @bit_precision: number of bits the hw LUT supports
>>> + *
>>> + * Extract a degamma/gamma LUT value provided by user (in the form of
>>> + * &drm_color_lut entries) and round it to the precision supported by the
>>> + * hardware.
>>> + */
>>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
>>> +{
>>> + uint32_t val = user_input;
>>> + uint32_t max = 0x >> (16 - bit_precision);
>>> +
>>> + /* Round only if we're not using full precision. */
>>> + if (bit_precision < 16) {
>>> + val += 1UL << (16 - bit_precision - 1);
>>> + val >>= 16 - bit_precision;
>>> + }
>>> +
>>> + return clamp_val(val, 0, max);
>>> +}
>>> +EXPORT_SYMBOL(drm_color_lut_extract);
>>> +
>>> +/**
>>>* drm_crtc_enable_color_mgmt - enable color management properties
>>>* @crtc: DRM CRTC
>>>* @degamma_lut_size: the size of the degamma lut (before CSC)
>>> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
>>> index c767238ac9d5..bce4a532836d 100644
>>> --- a/include/drm/drm_color_mgmt.h
>>> +++ b/include/drm/drm_color_mgmt.h
>>> @@ -25,6 +25,8 @@
>>>
>>> #include
>>>
>>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t
>>> bit_precision);
>>> +
>>> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>>> uint degamma_lut_size,
>>> bool has_ctm,
>>> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>>> int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>>> int gamma_size);
>>>
>>> -/**
>>> - * drm_color_lut_extract - clamp&round LUT entries
>>> - * @user_input: input value
>>> - * @bit_precision: number of bits the hw LUT supports
>>> - *
>>> - * Extract a degamma/gamma LUT value provided by user (in the form of
>>> - * &drm_color_lut entries) and round it to the precision supported by the
>>> - * hardware.
>>> - */
>>> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
>>> -uint32_t bit_precision)
>>> -{
>>> - uint32_t val = user_input;
>>> - uint32_t max = 0x >> (16 - bit_precision);
>>> -
>>> - /* Round only if we're not using full precision. */
>>> - if (bit_precision < 16) {
>>> - val += 1UL << (16 - bit_precision - 1);
>>> - val >>= 16 - bit_precision;
>>> - }
>>> -
>>> - return clamp_val(val, 0, max);
>>> -}
>>> -
>>> -
>>> #endif
>>
>>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: minor corner case fix to respect user's backlight setting
When enabling panel backlight, if the current backlight level
setting matches the panel's minimal, it would apply default policy to
override the current level by the panel's maximum until next request
to update brightness, this leads unexpected user confusion with
temporary full power backlight.
This odd could be reproduced as commands like these:
$ xbacklight -set 0
$ sudo sh -c 'echo mem > /sys/power/state'
(resume)
To fix this, slightly tinker the backlight level comparison from
'less-and-equal-to' to 'less-than'.
Before: (dmesg | grep backlight # with drm.debug=0xe)
[ 82.249265] [drm:intel_backlight_device_update_status [i915]] updating
intel_backlight, brightness=0/5273
[ 82.249282] [drm:intel_panel_actually_set_backlight [i915]] set backlight
PWM = 207
[ 82.249306] [drm:intel_edp_backlight_power [i915]] panel power control
backlight disable
[ 92.066041] [drm:intel_edp_backlight_off [i915]]
[ 92.270489] [drm:intel_panel_actually_set_backlight [i915]] set backlight
PWM = 0
[ 94.080434] [drm:intel_edp_backlight_on.part.25 [i915]]
[ 94.080476] [drm:intel_panel_enable_backlight [i915]] pipe A
[ 94.080539] [drm:intel_panel_actually_set_backlight [i915]] set backlight
PWM = 5273
After:
[ 72.874465] [drm:intel_backlight_device_update_status [i915]] updating
intel_backlight, brightness=0/5273
[ 72.874499] [drm:intel_panel_actually_set_backlight [i915]] set backlight
PWM = 207
[ 72.874540] [drm:intel_edp_backlight_power [i915]] panel power control
backlight disable
[ 86.807928] [drm:intel_edp_backlight_off [i915]]
[ 87.013227] [drm:intel_panel_actually_set_backlight [i915]] set backlight
PWM = 0
[ 89.001829] [drm:intel_edp_backlight_on.part.25 [i915]]
[ 89.001859] [drm:intel_panel_enable_backlight [i915]] pipe A
[ 89.001926] [drm:intel_panel_actually_set_backlight [i915]] set backlight
PWM = 207
Fixes: 13f3fbe827d0 ("fix inconsistent brightness after resume")
Signed-off-by: Harry Pan
---
drivers/gpu/drm/i915/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 08ab6d7..e882139 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1104,7 +1104,7 @@ void intel_panel_enable_backlight(struct intel_connector
*connector)
WARN_ON(panel->backlight.max == 0);
- if (panel->backlight.level <= panel->backlight.min) {
+ if (panel->backlight.level < panel->backlight.min) {
panel->backlight.level = panel->backlight.max;
if (panel->backlight.device)
panel->backlight.device->props.brightness =
--
2.6.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_stolen_to_physical() return phys_addr_t
On Fri, Jan 27, 2017 at 02:20:52PM +, Chris Wilson wrote: > On Fri, Jan 27, 2017 at 03:59:19PM +0200, Ville Syrjälä wrote: > > On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote: > > > The i915_stolen_to_physical() function has 'unsigned long' as its > > > return type but it returns the 'base' variable, which is of type > > > 'u32'. The only place where this function is called assigns the > > > returned value to dev_priv->mm.stolen_base, which is of type > > > 'phys_addr_t'. The return value is actually a physical address and > > > everything else in the stolen memory code seems to be using > > > phys_addr_t, so fix i915_stolen_to_physical() to use phys_addr_t. > > > > Size of phys_addr_t depends on PAE no? So what if someone were to boot > > a !PAE kernel on a machine where stolen lives somewhere >4GiB? > > dma_addr_t should be correct there, right? And in effect we do regard > this as only dma accessible, so the white lie would have some nice > semantic benefits. config ARCH_PHYS_ADDR_T_64BIT def_bool y depends on X86_64 || X86_PAE config ARCH_DMA_ADDR_T_64BIT def_bool y depends on X86_64 || HIGHMEM64G So looks like the size of dma_addr_t also depends on the config. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_stolen_to_physical() return phys_addr_t
On Fri, Jan 27, 2017 at 04:38:47PM +0200, Ville Syrjälä wrote: > On Fri, Jan 27, 2017 at 02:20:52PM +, Chris Wilson wrote: > > On Fri, Jan 27, 2017 at 03:59:19PM +0200, Ville Syrjälä wrote: > > > On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote: > > > > The i915_stolen_to_physical() function has 'unsigned long' as its > > > > return type but it returns the 'base' variable, which is of type > > > > 'u32'. The only place where this function is called assigns the > > > > returned value to dev_priv->mm.stolen_base, which is of type > > > > 'phys_addr_t'. The return value is actually a physical address and > > > > everything else in the stolen memory code seems to be using > > > > phys_addr_t, so fix i915_stolen_to_physical() to use phys_addr_t. > > > > > > Size of phys_addr_t depends on PAE no? So what if someone were to boot > > > a !PAE kernel on a machine where stolen lives somewhere >4GiB? > > > > dma_addr_t should be correct there, right? And in effect we do regard > > this as only dma accessible, so the white lie would have some nice > > semantic benefits. > > config ARCH_PHYS_ADDR_T_64BIT > def_bool y > depends on X86_64 || X86_PAE > > config ARCH_DMA_ADDR_T_64BIT > def_bool y > depends on X86_64 || HIGHMEM64G > > So looks like the size of dma_addr_t also depends on the config. We are dependent upon dma_addr_t (for transporting the addresses to the GTT), so use it and stick a warn or build bug if it ever comes up short? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Fri, 27 Jan 2017 15:35:47 +0100,
Ville Syrjälä wrote:
>
> On Fri, Jan 27, 2017 at 03:17:34PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 27, 2017 at 12:08:58PM +0200, Jani Nikula wrote:
> > > On Thu, 26 Jan 2017, Pierre-Louis Bossart
> > > wrote:
> > > > Enable chicken bit on LPE mode setup and unmute amp on
> > > > notification
> > > >
> > > > FIXME: should these two phases done somewhere else?
> > > >
> > > > Signed-off-by: Pierre-Louis Bossart
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/i915_reg.h| 12
> > > > drivers/gpu/drm/i915/intel_lpe_audio.c | 27 +++
> > > > 2 files changed, 39 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index a9ffc8d..ee90f64 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -2061,6 +2061,18 @@ enum skl_disp_power_wells {
> > > > #define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
> > > > #define I915_HDMI_LPE_AUDIO_SIZE 0x1000
> > > >
> > > > +/* DisplayPort Audio w/ LPE */
> > > > +#define CHICKEN_BIT_DBG_ENABLE (1 << 0)
> > > > +#define AMP_UNMUTE (1 << 1)
> >
> > That should be called AMP_MUTE I think,
> >
> > >
> > > The convention is to define registers first and the contents/bits for
> > > each register immedialy below. For groups of registers (like
> > > PORT_EN_B/C/D below) define all registers first and bits immediately
> > > below. (But note that the chicken register is not part of the group.)
> > >
> > > > +#define AUD_CHICKEN_BIT_REG0x62F38
> >
> > Spec calls this AUD_CHICKENBIT_REG. Might as well follow it to the
> > letter.
> >
> > > > +#define AUD_PORT_EN_B_DBG 0x62F20
> > > > +#define AUD_PORT_EN_C_DBG 0x62F28
> > > > +#define AUD_PORT_EN_D_DBG 0x62F2C
> >
> > These match the spec. But to match the standard i915 convention they
> > should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit
> > register.
>
> Actually they just match one version of the spec I had lying around.
> Another versions says:
>
> AUD_PORT_EN_B_DBG 0x62F20
> AUD_PORT_EN_C_DBG 0x62F30
> AUD_PORT_EN_D_DBG 0x62F34
That's it! Now finally I can hear the audio from DP3 with the
additional patch below.
thanks,
Takashi
---
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee90f64b89e8..5c577d242078 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2066,8 +2066,8 @@ enum skl_disp_power_wells {
#define AMP_UNMUTE (1 << 1)
#define AUD_CHICKEN_BIT_REG0x62F38
#define AUD_PORT_EN_B_DBG 0x62F20
-#define AUD_PORT_EN_C_DBG 0x62F28
-#define AUD_PORT_EN_D_DBG 0x62F2C
+#define AUD_PORT_EN_C_DBG 0x62F30
+#define AUD_PORT_EN_D_DBG 0x62F34
#define VLV_AUD_CHICKEN_BIT_REG_MMIO(VLV_DISPLAY_BASE +
AUD_CHICKEN_BIT_REG)
#define VLV_AUD_PORT_EN_B_DBG _MMIO(VLV_DISPLAY_BASE +
AUD_PORT_EN_B_DBG)
#define VLV_AUD_PORT_EN_C_DBG _MMIO(VLV_DISPLAY_BASE +
AUD_PORT_EN_C_DBG)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
Thanks Jani and Ville for the comments. Couple of precisions needed below:
#define GEN6_BSD_RNCID_MMIO(0x12198)
#define GEN7_FF_THREAD_MODE _MMIO(0x20a0)
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 245523e..b3134ef 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -248,6 +248,15 @@ static int lpe_audio_setup(struct drm_i915_private
*dev_priv)
goto err_free_irq;
}
+ /* Enable DPAudio debug bits by default */
+ if (IS_CHERRYVIEW(dev_priv)) {
VLV too. And like I said we might need this in the powerwell code as
well. You should make a test to see if the register value is retained
across the display power well being turned off. Eg. simply disable all
displays, check the log to make sure it really did turn off the display
power well, then re-enable some displays, and finally check if the
register value was retained or not).
VLV has DisplayPort? I thought this was an addition on CHT, and I really
don't know of any devices with this combination of HDaudio disabled+DP.
I'd rather keep this CHT-only until we find a device where this can be
tested.
On the powerwell, I could use more guidance. i tried this first solution
to see if streaming worked (and it did :-)). I don't mind moving the
code somewhere else but I have no idea where.
+ u32 chicken_bit;
+
+ chicken_bit = I915_READ(VLV_AUD_CHICKEN_BIT_REG);
+ I915_WRITE(VLV_AUD_CHICKEN_BIT_REG,
+ chicken_bit | CHICKEN_BIT_DBG_ENABLE);
+ }
+
return 0;
err_free_irq:
irq_free_desc(dev_priv->lpe_audio.irq);
@@ -357,6 +366,24 @@ void intel_lpe_audio_notify(struct drm_i915_private
*dev_priv,
pdata->tmds_clock_speed = tmds_clk_speed;
if (link_rate)
pdata->link_rate = link_rate;
+
+ if (dp_output) { /* unmute the amp */
The spec doesn't distinquish DP vs. HDMI here. So I presume we should be
able to do this always.
I'll try to see if HDMI still works with this. We could tentatively add
unmute in all cases but I'll need to add a test for Baytrail (no PORT_D)
so in the end it's the same number of tests.
And I think we might want to mute things again when disabling audio.
I was wondering if there would be side effects of writing to a register
controlling a port if that port is not connected any longer. I'll give
it a try.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma/fence: Export enable-signaling tracepoint for emission by drivers
On Tue, Jan 24, 2017 at 11:57:58AM +, Chris Wilson wrote: > Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, > however I have a need to manually perform the hw enabling of the > signaling and would like to emit this tracepoint for completeness. > > Signed-off-by: Chris Wilson > Cc: Sumit Semwal > Cc: Daniel Vetter Anybody for a quick ack and backmerge? :) > --- > drivers/dma-buf/dma-fence.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index a1bfc098ea10..d1f1f456f5c4 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -28,6 +28,7 @@ > > EXPORT_TRACEPOINT_SYMBOL(dma_fence_annotate_wait_on); > EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); > > /* > * fence context counter: each execution context should have its own > -- > 2.11.0 > -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl: Add missing SKL ID
Used by production device: Intel(R) Iris(TM) Graphics P555 Cc: Mika Kuoppala Cc: Rodrigo Vivi Signed-off-by: Michał Winiarski --- include/drm/i915_pciids.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index a1dd21d..466c715 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -265,7 +265,8 @@ INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \ INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ INTEL_VGA_DEVICE(0x1927, info), /* ULT GT3 */ \ - INTEL_VGA_DEVICE(0x192B, info) /* Halo GT3 */ \ + INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \ + INTEL_VGA_DEVICE(0x192D, info) /* SRV GT3 */ #define INTEL_SKL_GT4_IDS(info) \ INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \ -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma/fence: Export enable-signaling tracepoint for emission by drivers
Hi Chris, 2017-01-24 Chris Wilson : > Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, > however I have a need to manually perform the hw enabling of the > signaling and would like to emit this tracepoint for completeness. > > Signed-off-by: Chris Wilson > Cc: Sumit Semwal > Cc: Daniel Vetter > --- > drivers/dma-buf/dma-fence.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Gustavo Padovan Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
+#define AUD_PORT_EN_B_DBG 0x62F20 +#define AUD_PORT_EN_C_DBG 0x62F28 +#define AUD_PORT_EN_D_DBG 0x62F2C These match the spec. But to match the standard i915 convention they should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit register. Actually they just match one version of the spec I had lying around. Another versions says: AUD_PORT_EN_B_DBG 0x62F20 AUD_PORT_EN_C_DBG 0x62F30 AUD_PORT_EN_D_DBG 0x62F34 That's it! Now finally I can hear the audio from DP3 with the additional patch below. Wow. Thanks Ville for looking into this, we could have lost a lot of time. Do you happen to know if those previous values are due to poor documentation or a different skew we'd need to support, e.g. with a PCI-Id quirk? At any rate, 2 days to get DP audio working is pretty nice, this was a good week. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 02:31:55PM +, Chris Wilson wrote: > On Fri, Jan 27, 2017 at 03:21:29PM +0100, Daniel Vetter wrote: > > On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > > > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > > > When writing some testcases for nonblocking modesets. I found out that > > > > the > > > > infinite wait on the old fb was causing issues. > > > > > > The crux of the issue here is the locked wait for old dependencies and > > > the inability to inject the intel_prepare_reset disabling of all planes. > > > There are a couple of locked waits on struct_mutex within the modeset > > > locks for intel_overlay and if we happen to be using the display plane > > > for the first time. > > > > > > The first I suggested solving using fences to track dependencies and > > > keep the order between atomic states. Cancelling the outstanding > > > modesets, replacing with a disable and then on restore jumping to the > > > final state look doable. It also requires avoiding the struct_mutex for > > > disabling, which is quite easy. To avoid the wait under struct_mutex, > > > we've talked about switching to mmio, but for starters we could move the > > > wait from inside intel_overlay into the fence for the atomic operation. > > > (But's that a little more surgery than we would like for intel_overlay I > > > guess - dig out Ville's patches for overlay planes?) And to prevent the > > > wait under struct_mutex for pin_to_display_plane, my plane is to move > > > that to an async fenced operation that is then naturally waited upon by > > > the atomic modeset. > > > > A bit more a hack, but a different idea, and I think hack for gen234.0 is > > ok: > > > > We complete all the requests before we start the hw reset with fence.error > > = -EIO. But we do this only when we need to get at the display locks. A > > slightly more elegant solution would be to trylock modeset locks, and if > > one of them fails (and only then) complete all requests with -EIO to get > > the concurrent modeset to proceed before we reset the hardware. That's > > essentially the logic we had before all the reworks, and it worked. But I > > didn't look at how scary that all would be to make it work again ... > > The modeset lock may not just be waiting on our requests (even on pnv we > can expect that there are already users celebrating that pnv+nouveau > finally works ;) and that the display is not the only user/observer of > those requests. Using the requests to break the modeset lock just feels > like the wrong approach. It's a cycle, and we need to break it somewhere. Another option might be to break the cycle the same way we do it for gem locks: Wake up everyone and restart the modeset ioctl. Since the trouble only happens for synchronous modesets where we hold the locks while waiting for fences, we can also break out of that and restart. And I also don't think that would leak to other drivers, after all our gem locking restart dances also don't leak to other drivers - it's just our own driver's lock which are affected by these special wakupe semantics. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_stolen_to_physical() return phys_addr_t
On Fri, Jan 27, 2017 at 02:42:40PM +, Chris Wilson wrote: > On Fri, Jan 27, 2017 at 04:38:47PM +0200, Ville Syrjälä wrote: > > On Fri, Jan 27, 2017 at 02:20:52PM +, Chris Wilson wrote: > > > On Fri, Jan 27, 2017 at 03:59:19PM +0200, Ville Syrjälä wrote: > > > > On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote: > > > > > The i915_stolen_to_physical() function has 'unsigned long' as its > > > > > return type but it returns the 'base' variable, which is of type > > > > > 'u32'. The only place where this function is called assigns the > > > > > returned value to dev_priv->mm.stolen_base, which is of type > > > > > 'phys_addr_t'. The return value is actually a physical address and > > > > > everything else in the stolen memory code seems to be using > > > > > phys_addr_t, so fix i915_stolen_to_physical() to use phys_addr_t. > > > > > > > > Size of phys_addr_t depends on PAE no? So what if someone were to boot > > > > a !PAE kernel on a machine where stolen lives somewhere >4GiB? > > > > > > dma_addr_t should be correct there, right? And in effect we do regard > > > this as only dma accessible, so the white lie would have some nice > > > semantic benefits. > > > > config ARCH_PHYS_ADDR_T_64BIT > > def_bool y > > depends on X86_64 || X86_PAE > > > > config ARCH_DMA_ADDR_T_64BIT > > def_bool y > > depends on X86_64 || HIGHMEM64G > > > > So looks like the size of dma_addr_t also depends on the config. > > We are dependent upon dma_addr_t (for transporting the addresses to the > GTT), so use it and stick a warn or build bug if it ever comes up short? Needs a runtime check since the address comes from the firmware. But I guess we could just check whether it'll fit, and if not we simply don't use stolen? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 03:58:08PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 02:31:55PM +, Chris Wilson wrote: > > On Fri, Jan 27, 2017 at 03:21:29PM +0100, Daniel Vetter wrote: > > > On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > > > > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > > > > When writing some testcases for nonblocking modesets. I found out > > > > > that the > > > > > infinite wait on the old fb was causing issues. > > > > > > > > The crux of the issue here is the locked wait for old dependencies and > > > > the inability to inject the intel_prepare_reset disabling of all planes. > > > > There are a couple of locked waits on struct_mutex within the modeset > > > > locks for intel_overlay and if we happen to be using the display plane > > > > for the first time. > > > > > > > > The first I suggested solving using fences to track dependencies and > > > > keep the order between atomic states. Cancelling the outstanding > > > > modesets, replacing with a disable and then on restore jumping to the > > > > final state look doable. It also requires avoiding the struct_mutex for > > > > disabling, which is quite easy. To avoid the wait under struct_mutex, > > > > we've talked about switching to mmio, but for starters we could move the > > > > wait from inside intel_overlay into the fence for the atomic operation. > > > > (But's that a little more surgery than we would like for intel_overlay I > > > > guess - dig out Ville's patches for overlay planes?) And to prevent the > > > > wait under struct_mutex for pin_to_display_plane, my plane is to move > > > > that to an async fenced operation that is then naturally waited upon by > > > > the atomic modeset. > > > > > > A bit more a hack, but a different idea, and I think hack for gen234.0 is > > > ok: > > > > > > We complete all the requests before we start the hw reset with fence.error > > > = -EIO. But we do this only when we need to get at the display locks. A > > > slightly more elegant solution would be to trylock modeset locks, and if > > > one of them fails (and only then) complete all requests with -EIO to get > > > the concurrent modeset to proceed before we reset the hardware. That's > > > essentially the logic we had before all the reworks, and it worked. But I > > > didn't look at how scary that all would be to make it work again ... > > > > The modeset lock may not just be waiting on our requests (even on pnv we > > can expect that there are already users celebrating that pnv+nouveau > > finally works ;) and that the display is not the only user/observer of > > those requests. Using the requests to break the modeset lock just feels > > like the wrong approach. > > It's a cycle, and we need to break it somewhere. Another option might be > to break the cycle the same way we do it for gem locks: Wake up everyone > and restart the modeset ioctl. Since the trouble only happens for > synchronous modesets where we hold the locks while waiting for fences, we > can also break out of that and restart. And I also don't think that would > leak to other drivers, after all our gem locking restart dances also don't > leak to other drivers - it's just our own driver's lock which are affected > by these special wakupe semantics. It's a queue of nonblocking modesets that we need to worry about, afaik. Moving the wait for blocking modeset outside of modeset lock is easily achievable (and avoiding the other waits under both the modeset + struct_mutex I have at least an idea for). So the challenge is how to inject all-planes-off for gen3 and then allow the queue to continue again afterwards. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_stolen_to_physical() return phys_addr_t
On Fri, Jan 27, 2017 at 05:06:53PM +0200, Ville Syrjälä wrote: > On Fri, Jan 27, 2017 at 02:42:40PM +, Chris Wilson wrote: > > On Fri, Jan 27, 2017 at 04:38:47PM +0200, Ville Syrjälä wrote: > > > On Fri, Jan 27, 2017 at 02:20:52PM +, Chris Wilson wrote: > > > > On Fri, Jan 27, 2017 at 03:59:19PM +0200, Ville Syrjälä wrote: > > > > > On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote: > > > > > > The i915_stolen_to_physical() function has 'unsigned long' as its > > > > > > return type but it returns the 'base' variable, which is of type > > > > > > 'u32'. The only place where this function is called assigns the > > > > > > returned value to dev_priv->mm.stolen_base, which is of type > > > > > > 'phys_addr_t'. The return value is actually a physical address and > > > > > > everything else in the stolen memory code seems to be using > > > > > > phys_addr_t, so fix i915_stolen_to_physical() to use phys_addr_t. > > > > > > > > > > Size of phys_addr_t depends on PAE no? So what if someone were to boot > > > > > a !PAE kernel on a machine where stolen lives somewhere >4GiB? > > > > > > > > dma_addr_t should be correct there, right? And in effect we do regard > > > > this as only dma accessible, so the white lie would have some nice > > > > semantic benefits. > > > > > > config ARCH_PHYS_ADDR_T_64BIT > > > def_bool y > > > depends on X86_64 || X86_PAE > > > > > > config ARCH_DMA_ADDR_T_64BIT > > > def_bool y > > > depends on X86_64 || HIGHMEM64G > > > > > > So looks like the size of dma_addr_t also depends on the config. > > > > We are dependent upon dma_addr_t (for transporting the addresses to the > > GTT), so use it and stick a warn or build bug if it ever comes up short? > > Needs a runtime check since the address comes from the firmware. > But I guess we could just check whether it'll fit, and if not we > simply don't use stolen? That's what I was thinking as well. System comes up and the user may never even notice the error message. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Fri, Jan 27, 2017 at 08:47:50AM -0600, Pierre-Louis Bossart wrote:
> Thanks Jani and Ville for the comments. Couple of precisions needed below:
> >>
> >>> #define GEN6_BSD_RNCID _MMIO(0x12198)
> >>>
> >>> #define GEN7_FF_THREAD_MODE _MMIO(0x20a0)
> >>> diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
> >>> b/drivers/gpu/drm/i915/intel_lpe_audio.c
> >>> index 245523e..b3134ef 100644
> >>> --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> >>> +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> >>> @@ -248,6 +248,15 @@ static int lpe_audio_setup(struct drm_i915_private
> >>> *dev_priv)
> >>> goto err_free_irq;
> >>> }
> >>>
> >>> + /* Enable DPAudio debug bits by default */
> >>> + if (IS_CHERRYVIEW(dev_priv)) {
> > VLV too. And like I said we might need this in the powerwell code as
> > well. You should make a test to see if the register value is retained
> > across the display power well being turned off. Eg. simply disable all
> > displays, check the log to make sure it really did turn off the display
> > power well, then re-enable some displays, and finally check if the
> > register value was retained or not).
> VLV has DisplayPort?
Yes. And as I said earlier the docs don't make any distinciton between
HDMI and DP in the audio programming sequence. So based on the docs we
should always unmute the amp manually.
>I thought this was an addition on CHT, and I really
> don't know of any devices with this combination of HDaudio disabled+DP.
> I'd rather keep this CHT-only until we find a device where this can be
> tested.
>
> On the powerwell, I could use more guidance. i tried this first solution
> to see if streaming worked (and it did :-)). I don't mind moving the
> code somewhere else but I have no idea where.
1. boot with drm.debug=0xe
1. 'intel_reg read 0x62f38' just after boot, to see that the
chicken bit is as it should
2. disable all displays (eg. xset dpms force off)
3. grep 'power_well.*display' (make sure the last thing it says is
"disabling"
4. turn on the displays (eg. xset dpms force on)
5. 'intel_reg read 0x62f38' to check the chicken bit again
If it didn't survive then we need to set it in either in
vlv_display_power_well_init(), or we could just set it whenever
we set the AMP_MUTE bit for any of the ports.
>
> >>> + u32 chicken_bit;
> >>> +
> >>> + chicken_bit = I915_READ(VLV_AUD_CHICKEN_BIT_REG);
> >>> + I915_WRITE(VLV_AUD_CHICKEN_BIT_REG,
> >>> +chicken_bit | CHICKEN_BIT_DBG_ENABLE);
> >>> + }
> >>> +
> >>> return 0;
> >>> err_free_irq:
> >>> irq_free_desc(dev_priv->lpe_audio.irq);
> >>> @@ -357,6 +366,24 @@ void intel_lpe_audio_notify(struct drm_i915_private
> >>> *dev_priv,
> >>> pdata->tmds_clock_speed = tmds_clk_speed;
> >>> if (link_rate)
> >>> pdata->link_rate = link_rate;
> >>> +
> >>> + if (dp_output) { /* unmute the amp */
> > The spec doesn't distinquish DP vs. HDMI here. So I presume we should be
> > able to do this always.
>
> I'll try to see if HDMI still works with this. We could tentatively add
> unmute in all cases but I'll need to add a test for Baytrail (no PORT_D)
> so in the end it's the same number of tests.
>
> >
> > And I think we might want to mute things again when disabling audio.
> I was wondering if there would be side effects of writing to a register
> controlling a port if that port is not connected any longer. I'll give
> it a try.
Nothing apart from HPD circuitry really cares if there's anything
connectect or not.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/color: un-inline drm_color_lut_extract()
The function is not that big, but it's also not used for anything
performance critical. Make it a normal function.
As a side effect, this apparently makes sparse smarter about what it's
doing, and gets rid of the warning:
./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for
type unsigned long
./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
constant value (8000 becomes 0)
v2: rebased
Cc: Lionel Landwerlin
Reviewed-by: Daniel Vetter
Reviewed-by: Lionel Landwerlin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_color_mgmt.c | 24
include/drm/drm_color_mgmt.h | 27 ++-
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 789b4c65cd69..cc23b9a505c0 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -88,6 +88,30 @@
*/
/**
+ * drm_color_lut_extract - clamp and round LUT entries
+ * @user_input: input value
+ * @bit_precision: number of bits the hw LUT supports
+ *
+ * Extract a degamma/gamma LUT value provided by user (in the form of
+ * &drm_color_lut entries) and round it to the precision supported by the
+ * hardware.
+ */
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (16 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 16) {
+ val += 1UL << (16 - bit_precision - 1);
+ val >>= 16 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract);
+
+/**
* drm_crtc_enable_color_mgmt - enable color management properties
* @crtc: DRM CRTC
* @degamma_lut_size: the size of the degamma lut (before CSC)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index d9c2f680f5ae..bce4a532836d 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -25,6 +25,8 @@
#include
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
+
void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
uint degamma_lut_size,
bool has_ctm,
@@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-/**
- * drm_color_lut_extract - clamp and round LUT entries
- * @user_input: input value
- * @bit_precision: number of bits the hw LUT supports
- *
- * Extract a degamma/gamma LUT value provided by user (in the form of
- * &drm_color_lut entries) and round it to the precision supported by the
- * hardware.
- */
-static inline uint32_t drm_color_lut_extract(uint32_t user_input,
-uint32_t bit_precision)
-{
- uint32_t val = user_input;
- uint32_t max = 0x >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
-}
-
-
#endif
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make i915_stolen_to_physical() return phys_addr_t
Em Sex, 2017-01-27 às 15:59 +0200, Ville Syrjälä escreveu:
> On Thu, Jan 26, 2017 at 06:19:07PM -0200, Paulo Zanoni wrote:
> >
> > The i915_stolen_to_physical() function has 'unsigned long' as its
> > return type but it returns the 'base' variable, which is of type
> > 'u32'. The only place where this function is called assigns the
> > returned value to dev_priv->mm.stolen_base, which is of type
> > 'phys_addr_t'. The return value is actually a physical address and
> > everything else in the stolen memory code seems to be using
> > phys_addr_t, so fix i915_stolen_to_physical() to use phys_addr_t.
>
> Size of phys_addr_t depends on PAE no? So what if someone were to
> boot
> a !PAE kernel on a machine where stolen lives somewhere >4GiB?
Notice that this should not be possible today since we read the stolen
memory address from a 32 bit register. Of course, things may change in
the future, so having future-proof code is obviously good.
>
> >
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_gem_stolen.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 127d698..0816ebd 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -79,12 +79,12 @@ void i915_gem_stolen_remove_node(struct
> > drm_i915_private *dev_priv,
> > mutex_unlock(&dev_priv->mm.stolen_lock);
> > }
> >
> > -static unsigned long i915_stolen_to_physical(struct
> > drm_i915_private *dev_priv)
> > +static phys_addr_t i915_stolen_to_physical(struct drm_i915_private
> > *dev_priv)
> > {
> > struct pci_dev *pdev = dev_priv->drm.pdev;
> > struct i915_ggtt *ggtt = &dev_priv->ggtt;
> > struct resource *r;
> > - u32 base;
> > + phys_addr_t base;
> >
> > /* Almost universally we can find the Graphics Base of
> > Stolen Memory
> > * at register BSM (0x5c) in the igfx configuration space.
> > On a few
> > @@ -196,7 +196,7 @@ static unsigned long
> > i915_stolen_to_physical(struct drm_i915_private *dev_priv)
> > if (INTEL_GEN(dev_priv) <= 4 &&
> > !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv) &&
> > !IS_G4X(dev_priv)) {
> > struct {
> > - u32 start, end;
> > + phys_addr_t start, end;
> > } stolen[2] = {
> > { .start = base, .end = base + ggtt-
> > >stolen_size, },
> > { .start = base, .end = base + ggtt-
> > >stolen_size, },
> > @@ -228,11 +228,12 @@ static unsigned long
> > i915_stolen_to_physical(struct drm_i915_private *dev_priv)
> >
> > if (stolen[0].start != stolen[1].start ||
> > stolen[0].end != stolen[1].end) {
> > + phys_addr_t end = base + ggtt->stolen_size
> > - 1;
> > DRM_DEBUG_KMS("GTT within stolen memory at
> > 0x%llx-0x%llx\n",
> > (unsigned long
> > long)ggtt_start,
> > (unsigned long long)ggtt_end
> > - 1);
> > - DRM_DEBUG_KMS("Stolen memory adjusted to
> > 0x%x-0x%x\n",
> > - base, base + (u32)ggtt-
> > >stolen_size - 1);
> > + DRM_DEBUG_KMS("Stolen memory adjusted to
> > %pa - %pa\n",
> > + &base, &end);
> > }
> > }
> >
> > @@ -261,8 +262,9 @@ static unsigned long
> > i915_stolen_to_physical(struct drm_i915_private *dev_priv)
> > * range. Apparently this works.
> > */
> > if (r == NULL && !IS_GEN3(dev_priv)) {
> > - DRM_ERROR("conflict detected with stolen
> > region: [0x%08x - 0x%08x]\n",
> > - base, base + (uint32_t)ggtt-
> > >stolen_size);
> > + phys_addr_t end = base + ggtt-
> > >stolen_size;
> > + DRM_ERROR("conflict detected with stolen
> > region: [%pa - %pa]\n",
> > + &base, &end);
> > base = 0;
> > }
> > }
> > --
> > 2.7.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/5] drm: i915: add DisplayPort amp unmute for LPE audio mode
On Fri, Jan 27, 2017 at 08:55:19AM -0600, Pierre-Louis Bossart wrote: > > > > +#define AUD_PORT_EN_B_DBG 0x62F20 > > +#define AUD_PORT_EN_C_DBG 0x62F28 > > +#define AUD_PORT_EN_D_DBG 0x62F2C > >>> These match the spec. But to match the standard i915 convention they > >>> should be called _AUD_PORT_EN_B_DBG etc. Same forthe chicken bit > >>> register. > >> Actually they just match one version of the spec I had lying around. > >> Another versions says: > >> > >> AUD_PORT_EN_B_DBG 0x62F20 > >> AUD_PORT_EN_C_DBG 0x62F30 > >> AUD_PORT_EN_D_DBG 0x62F34 > > That's it! Now finally I can hear the audio from DP3 with the > > additional patch below. > Wow. Thanks Ville for looking into this, we could have lost a lot of > time. Do you happen to know if those previous values are due to poor > documentation or a different skew we'd need to support, e.g. with a > PCI-Id quirk? No idea really. You should really test this on both CHV and VLV with all possible port/pipe combinations to make sure we got it right. I trust these VLV/CHV docs about as much as I trust most politicians. Alternatively you could just read all those regs on both platforms and see if the values you get from them conform to any visible pattern that could tell us which offsets are the correct ones. They might not, in which case actual testing is the best bet. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Get correct display clock on 945gm
This is according to Mobile Intel® 945 Express Chipset
Family datasheet.
Signed-off-by: Arthur Heymans
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 27 +--
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 70d96162def6..c3141e40d938 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -114,7 +114,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GCFGC 0xf0 /* 915+ only */
#define GC_LOW_FREQUENCY_ENABLE (1 << 7)
#define GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4)
-#define GC_DISPLAY_CLOCK_333_MHZ (4 << 4)
+#define GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4)
#define GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4)
#define GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4)
#define GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 81c11499bcf0..307fc62e7c70 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7389,6 +7389,26 @@ static int i945_get_display_clock_speed(struct
drm_device *dev)
return 40;
}
+static int 945gm_get_display_clock_speed(struct drm_device *dev)
+{
+ struct pci_dev *pdev = dev->pdev;
+ u16 gcfgc = 0;
+
+ pci_read_config_word(pdev, GCFGC, &gcfgc);
+
+ if (gcfgc & GC_LOW_FREQUENCY_ENABLE)
+ return 13;
+ else {
+ switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
+ case GC_DISPLAY_CLOCK_333_320_MHZ:
+ return 32;
+ default:
+ case GC_DISPLAY_CLOCK_190_200_MHZ:
+ return 20;
+ }
+ }
+}
+
static int i915_get_display_clock_speed(struct drm_device *dev)
{
return 33;
@@ -7435,7 +7455,7 @@ static int i915gm_get_display_clock_speed(struct
drm_device *dev)
return 13;
else {
switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
- case GC_DISPLAY_CLOCK_333_MHZ:
+ case GC_DISPLAY_CLOCK_333_320_MHZ:
return 33;
default:
case GC_DISPLAY_CLOCK_190_200_MHZ:
@@ -15991,9 +16011,12 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
else if (IS_I915G(dev_priv))
dev_priv->display.get_display_clock_speed =
i915_get_display_clock_speed;
- else if (IS_I945GM(dev_priv) || IS_845G(dev_priv))
+ else if (IS_845G(dev_priv))
dev_priv->display.get_display_clock_speed =
i9xx_misc_get_display_clock_speed;
+ else if (IS_I945GM(dev_priv))
+ dev_priv->display.get_display_clock_speed =
+ 954gm_get_display_clock_speed;
else if (IS_I915GM(dev_priv))
dev_priv->display.get_display_clock_speed =
i915gm_get_display_clock_speed;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix use-after-free in page_flip_completed()
page_flip_completed() dereferences 'work' variable after executing
queue_work(). This is not safe as the 'work' item might be already freed
by queued work:
BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr
8803dc010f90
Call Trace:
__asan_report_load8_noabort+0x59/0x80
page_flip_completed+0x3ff/0x490
intel_finish_page_flip_mmio+0xe3/0x130
intel_pipe_handle_vblank+0x2d/0x40
gen8_irq_handler+0x4a7/0xed0
__handle_irq_event_percpu+0xf6/0x860
handle_irq_event_percpu+0x6b/0x160
handle_irq_event+0xc7/0x1b0
handle_edge_irq+0x1f4/0xa50
handle_irq+0x41/0x70
do_IRQ+0x9a/0x200
common_interrupt+0x89/0x89
Freed:
kfree+0x113/0x4d0
intel_unpin_work_fn+0x29a/0x3b0
process_one_work+0x79e/0x1b70
worker_thread+0x611/0x1460
kthread+0x241/0x3a0
ret_from_fork+0x27/0x40
Move queue_work() after trace_i915_flip_complete() to fix this.
Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests &
completions")
Signed-off-by: Andrey Ryabinin
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d702cf..f04a95cd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4268,10 +4268,10 @@ static void page_flip_completed(struct intel_crtc
*intel_crtc)
drm_crtc_vblank_put(&intel_crtc->base);
wake_up_all(&dev_priv->pending_flip_queue);
- queue_work(dev_priv->wq, &work->unpin_work);
-
trace_i915_flip_complete(intel_crtc->plane,
work->pending_flip_obj);
+
+ queue_work(dev_priv->wq, &work->unpin_work);
}
static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken DPMS with DisplayPort on CHV (also BYT?)
Please find My replay.
Thanks
Sridhar
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Thursday, January 26, 2017 7:50 PM
To: Ville Syrjälä
Cc: intel-gfx ; Michal Marek ;
Chen, Angus ; Jeffrey Cheung ; Hsu, Ray
; Venkatanara, Sridhara
Subject: Re: [Intel-gfx] Broken DPMS with DisplayPort on CHV (also BYT?)
On Thu, 26 Jan 2017 14:58:55 +0100,
Ville Syrjälä wrote:
>
> On Wed, Jan 25, 2017 at 01:56:35PM +0100, Takashi Iwai wrote:
> > Hi,
> >
> > we've got a bug report about the blank monitor on Cherry Trail
> > machines. And, Intel team (Cc'ed) spotted out that this seems
> > triggered by DPMS transition. A patch like below actually fixes the
> > problem.
> >
> > Of course it doesn't look like a right "fix". Do you guys have any
> > hint for further debugging?
>
> Is it some kind of new fangled MST capable monitor? I've noticed that
> those tend to be super easy to mess up.
The monitors are in Dell team. Sridhara, could you give details about the
problematic monitors?
[Sridhar] Monitor types E2316H, E2216H
http://www.dell.com/ed/business/p/dell-e2316h-monitor/pd
> > Some more (not alt-) facts:
> >
> > - The machine we've tested is a Cherry Trail based box with two
> > DisplayPorts. Intel team mentioned that there are other machines
> > suffering from the same problem.
>
> Is it really somehow tied to the machine? I would imagine it should
> behave exactly the same way no matter what machine you have.
A good question. Again the question is delegated to Sridhara :)
[Sridhar] It is tied to the Cherry Trail based box. Not observed with Bay Trail
machines.
> > - With some monitors, the screen remains blank during boot and on X.
> > This can be cured after "xset dpms force off" and resume, or
> > reconfiguring via xrandr.
> >
> > - The issue seems specific to DP connections. When two (identical)
> > monitors are connected, only one monitor goes blank.
>
> Hmm. Have you tried 9f2bdb006a7e ("drm/i915: Prevent PPS stealing from
> a normal DP port on VLV/CHV") ?
No, it's not tested. I'll prepare a test kernel with it.
Thanks!
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: use variadic macros and arrays to choose port/pipe based registers
This allows the use of more than 3 ports/pipes/whatever without tricks,
even if the register offsets are not evenly spaced.
There's the risk of out of bounds access if we're not careful; currently
that would "just" lead to the wrong register offset being used. It might
be possible to add build bug ons for build time constant indexing.
We already have ports defined up to E, not sure if we might have bugs
related to them and the current _PORT3() macro.
textdata bss dec hex filename
1239868 461994096 1290163 13afb3 drivers/gpu/drm/i915/i915.ko
1238828 461994096 1289123 13aba3 drivers/gpu/drm/i915/i915.ko
Cc: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 672cb102f477..c6435a447300 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -48,6 +48,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
}
+#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
+
#define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
#define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
#define _PLANE(plane, a, b) _PIPE(plane, a, b)
@@ -56,14 +58,11 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
#define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
#define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
-#define _PIPE3(pipe, a, b, c) ((pipe) == PIPE_A ? (a) : \
- (pipe) == PIPE_B ? (b) : (c))
+#define _PIPE3(pipe, ...) _PICK(pipe, __VA_ARGS__)
#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PIPE3(pipe, a, b, c))
-#define _PORT3(port, a, b, c) ((port) == PORT_A ? (a) : \
- (port) == PORT_B ? (b) : (c))
+#define _PORT3(port, ...) _PICK(port, __VA_ARGS__)
#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PORT3(pipe, a, b, c))
-#define _PHY3(phy, a, b, c) ((phy) == DPIO_PHY0 ? (a) : \
-(phy) == DPIO_PHY1 ? (b) : (c))
+#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
#define _MASKED_FIELD(mask, value) ({ \
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use variadic macros and arrays to choose port/pipe based registers
On Fri, Jan 27, 2017 at 05:57:06PM +0200, Jani Nikula wrote:
> This allows the use of more than 3 ports/pipes/whatever without tricks,
> even if the register offsets are not evenly spaced.
>
> There's the risk of out of bounds access if we're not careful; currently
> that would "just" lead to the wrong register offset being used. It might
> be possible to add build bug ons for build time constant indexing.
>
> We already have ports defined up to E, not sure if we might have bugs
> related to them and the current _PORT3() macro.
>
>text data bss dec hex filename
> 1239868 461994096 1290163 13afb3 drivers/gpu/drm/i915/i915.ko
> 1238828 461994096 1289123 13aba3 drivers/gpu/drm/i915/i915.ko
>
> Cc: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Tvrtko Ursulin
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 672cb102f477..c6435a447300 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -48,6 +48,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
> }
>
> +#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
Very neat. The danger is that for a variable index, the compiler will
plonk the array on the stack, for each invocation. Though for a constant
the compiler will see through it and generate the right constant.
https://godbolt.org/g/YCK1od
Given that it looks like the compiler will get smarter, this looks like
a much less error prone way of writing these.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Get correct display clock on 945gm
On Fri, Jan 27, 2017 at 03:44:27PM +0100, Arthur Heymans wrote:
> This is according to Mobile Intel® 945 Express Chipset
> Family datasheet.
>
> Signed-off-by: Arthur Heymans
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 27 +--
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 70d96162def6..c3141e40d938 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -114,7 +114,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define GCFGC0xf0 /* 915+ only */
> #define GC_LOW_FREQUENCY_ENABLE(1 << 7)
> #define GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4)
> -#define GC_DISPLAY_CLOCK_333_MHZ (4 << 4)
> +#define GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4)
> #define GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4)
> #define GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4)
> #define GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 81c11499bcf0..307fc62e7c70 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7389,6 +7389,26 @@ static int i945_get_display_clock_speed(struct
> drm_device *dev)
> return 40;
> }
>
> +static int 945gm_get_display_clock_speed(struct drm_device *dev)
> +{
> + struct pci_dev *pdev = dev->pdev;
> + u16 gcfgc = 0;
> +
> + pci_read_config_word(pdev, GCFGC, &gcfgc);
> +
> + if (gcfgc & GC_LOW_FREQUENCY_ENABLE)
> + return 13;
> + else {
> + switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
> + case GC_DISPLAY_CLOCK_333_320_MHZ:
> + return 32;
That indeed is what the docs say.
The code is tantalizingly close to the 915gm code now, so maybe
we could share it with a simple
if (IS_915GM(dev_priv))
return 32;
else
return 33;
?
Now if someone could figure out where to dig up the DDR and FSB clocks
we could also fix up the 190 vs. 200 MHz case...
> + default:
> + case GC_DISPLAY_CLOCK_190_200_MHZ:
> + return 20;
> + }
> + }
> +}
> +
> static int i915_get_display_clock_speed(struct drm_device *dev)
> {
> return 33;
> @@ -7435,7 +7455,7 @@ static int i915gm_get_display_clock_speed(struct
> drm_device *dev)
> return 13;
> else {
> switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
> - case GC_DISPLAY_CLOCK_333_MHZ:
> + case GC_DISPLAY_CLOCK_333_320_MHZ:
> return 33;
> default:
> case GC_DISPLAY_CLOCK_190_200_MHZ:
> @@ -15991,9 +16011,12 @@ void intel_init_display_hooks(struct
> drm_i915_private *dev_priv)
> else if (IS_I915G(dev_priv))
> dev_priv->display.get_display_clock_speed =
> i915_get_display_clock_speed;
> - else if (IS_I945GM(dev_priv) || IS_845G(dev_priv))
> + else if (IS_845G(dev_priv))
> dev_priv->display.get_display_clock_speed =
> i9xx_misc_get_display_clock_speed;
> + else if (IS_I945GM(dev_priv))
> + dev_priv->display.get_display_clock_speed =
> + 954gm_get_display_clock_speed;
> else if (IS_I915GM(dev_priv))
> dev_priv->display.get_display_clock_speed =
> i915gm_get_display_clock_speed;
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use variadic macros and arrays to choose port/pipe based registers
On Fri, Jan 27, 2017 at 05:57:06PM +0200, Jani Nikula wrote:
> This allows the use of more than 3 ports/pipes/whatever without tricks,
> even if the register offsets are not evenly spaced.
>
> There's the risk of out of bounds access if we're not careful; currently
> that would "just" lead to the wrong register offset being used. It might
> be possible to add build bug ons for build time constant indexing.
>
> We already have ports defined up to E, not sure if we might have bugs
> related to them and the current _PORT3() macro.
>
>text data bss dec hex filename
> 1239868 461994096 1290163 13afb3 drivers/gpu/drm/i915/i915.ko
> 1238828 461994096 1289123 13aba3 drivers/gpu/drm/i915/i915.ko
Fits in well with all the other preprocessor horrors we have ;)
I'm convinced.
Reviewed-by: Ville Syrjälä
>
> Cc: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Tvrtko Ursulin
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 672cb102f477..c6435a447300 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -48,6 +48,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
> }
>
> +#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
> +
> #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
> #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
> #define _PLANE(plane, a, b) _PIPE(plane, a, b)
> @@ -56,14 +58,11 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
> #define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
> #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))
> -#define _PIPE3(pipe, a, b, c) ((pipe) == PIPE_A ? (a) : \
> -(pipe) == PIPE_B ? (b) : (c))
> +#define _PIPE3(pipe, ...) _PICK(pipe, __VA_ARGS__)
> #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PIPE3(pipe, a, b, c))
> -#define _PORT3(port, a, b, c) ((port) == PORT_A ? (a) : \
> -(port) == PORT_B ? (b) : (c))
> +#define _PORT3(port, ...) _PICK(port, __VA_ARGS__)
> #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PORT3(pipe, a, b, c))
> -#define _PHY3(phy, a, b, c) ((phy) == DPIO_PHY0 ? (a) : \
> - (phy) == DPIO_PHY1 ? (b) : (c))
> +#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>
> #define _MASKED_FIELD(mask, value) ({
>\
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Get correct display clock on 945gm
Ville Syrjälä writes: > On Fri, Jan 27, 2017 at 03:44:27PM +0100, Arthur Heymans wrote: > > That indeed is what the docs say. > > The code is tantalizingly close to the 915gm code now, so maybe > we could share it with a simple > > if (IS_915GM(dev_priv)) > return 32; > else > return 33; > Agreed but it's the other way around ;) > Now if someone could figure out where to dig up the DDR and FSB clocks > we could also fix up the 190 vs. 200 MHz case... > >> +default: >> +case GC_DISPLAY_CLOCK_190_200_MHZ: >> +return 20; >> +} >> +} >> +} >> + Hmm that seems to be 915gm specific (always 200 on 945gm). According to "Mobile Intel® 915/910 Express Chipset: Datasheet", the only fsb/dram combo that has 190MHz is FSB: 533MHz, DDR333. All the other supported combos have 200Mhz set by that configuration. -- Arthur Heymans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma/fence: Export enable-signaling tracepoint for emission by drivers
fwiw, On 27 January 2017 at 20:25, Gustavo Padovan wrote: > Hi Chris, > > 2017-01-24 Chris Wilson : > >> Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, >> however I have a need to manually perform the hw enabling of the >> signaling and would like to emit this tracepoint for completeness. >> >> Signed-off-by: Chris Wilson >> Cc: Sumit Semwal >> Cc: Daniel Vetter >> --- >> drivers/dma-buf/dma-fence.c | 1 + >> 1 file changed, 1 insertion(+) > > Reviewed-by: Gustavo Padovan > Feel free to add my a-b :) > Gustavo > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thanks and regards, Sumit Semwal Linaro Mobile Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
