On Sat, 5 Apr 2014 17:21:04 +0200
Daniel Vetter wrote:
> On Fri, Apr 04, 2014 at 03:12:08PM -0700, Jesse Barnes wrote:
> > Needs to happen after clock is running or it doesn't behave correctly.
> >
> > v2: fix subject (Ville)
> > make it clearer that
This only applies to external sinks.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7642415..df7cc11 100644
--- a/drivers/gpu/drm
Some platforms may not have it, and enumerating it is both confusing and
time consuming due to the hotplug and DDC probing.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
This is supposed to fix some eDP PPS issues on some platforms.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 98cf24f..34d01be
The reason for these is lost in the mists of time, and they don't seem
to be necessary anymore, so drop them.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel
The spec changed the order awhile back to put the ports at the end
again, but we never updated. Things seem to work ok either way, but
apparently there are some failures fixed by the new order, so let's just
go ahead and do it.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel
This always indicates a bug somewhere.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6a6406f..c039f34 100644
--- a
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c | 18 --
1 file changed, 16 insertions(+), 2 dele
Needs to happen after clock is running or it doesn't behave correctly.
v2: fix subject (Ville)
make it clearer that this occurs in pre_enable (Paulo)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c | 18 --
1 file changed, 16 insertions(+), 2 dele
On Thu, 3 Apr 2014 22:55:24 +0200
Daniel Vetter wrote:
> On Thu, Apr 3, 2014 at 6:49 PM, Jesse Barnes wrote:
> >> > static bool intel_hdmi_get_hw_state(struct intel_encoder *encoder,
> >> > @@ -738,9 +736,13 @@ static void intel_enable_hdmi(struct int
On Thu, 3 Apr 2014 17:19:56 +0200
Daniel Vetter wrote:
> On Wed, Apr 02, 2014 at 10:08:54AM -0700, Jesse Barnes wrote:
> > Needs to happen after clock is running or it doesn't behave correctly.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > dr
otherwise, but not for KMS.
> */
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> dev_priv->dri1.allow_batchbuffer = 1;
> - return 0;
> + return ret;
> }
>
> void
Will we still have some loud spewing into the log in this case? If so,
then
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
it looks like this will still tear things down on suspend?
Maybe it's all the refactoring making me miss it. :)
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -34,6 +34,7 @@ struct intel_hw_status_page {
> #define I915_WRITE_IMR(ring, val) I915_WRITE(RING_IMR((ring)->mmio_base),
> val)
>
> #define I915_READ_MODE(ring) I915_READ(RING_MI_MODE((ring)->mmio_base))
> +#define I915_WRITE_MODE(ring, val)
> I915_WRITE(RING_MI_MODE((ring)->mmio_base), val)
>
> enum intel_ring_hangcheck_action {
> HANGCHECK_IDLE = 0,
Bad Chris, mixing a nice refactor and a nice fix in the same patch.
I'll still give you a cookie though.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> #include "i915_trace.h"
> #include "intel_drv.h"
>
> +#define CACHELINE_BYTES 64
> +
Are you sure it's 64 on every gen? It changes on the CPU side from
time to time... I thought it might have changed over time on the GPU
too but I haven't checked the s
IPE2(pipe, _PIPEA_FRMCOUNT_GM45)
>
> /* Cursor A & B regs */
> #define _CURACNTR (dev_priv->info.display_mmio_offset + 0x70080)
Oh fun.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
gt; + "pipe %c: enable_mask=0x%x, status_mask=0x%x\n",
> + pipe, enable_mask, status_mask))
> return;
>
> if ((pipestat & enable_mask) == 0)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
reg 0x%x == 0x%x\n",
> + pipe_name(pipe), reg, val);
> +
> return val;
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
PE_B;
> }
>
> + if (intel_crtc->config.has_dp_encoder)
> + intel_dp_set_m_n(intel_crtc);
> +
> intel_set_pipe_timings(intel_crtc);
>
> /* pipesrc and dspsize control the size that is scaled from,
Yeah I like it.
Reviewed-by: Je
These all have a
Tested-by: "Joon Jung "
too.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
We also do a disable later when we write a specific infoframe, but here
we do it to prevent sending a stale one before updating the infoframes.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
Needs to happen after clock is running or it doesn't behave correctly.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
Allows sending of the null packets for conformance.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3b804fc..fb9839b 100644
In case we end up bouncing these around between ports.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index b0413e1..ee892a4 100644
--- a
, Turbo freqs used on current machines matches.
> ---
I don't know what to do about this... I don't have a bunch of machines
to test with, and the docs say different.
But if you have feedback from the hw guys, I guess
Acked-by: Jesse Barnes
--
Jesse Barnes, I
gt; > >
> > > commit d978ef14456a38034f6c0e94a794129501f89200
> > > Author: Jesse Barnes
> > > Date: Fri Mar 7 08:57:51 2014 -0800
> > >
> > > drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS
> > > fbcon v12
> > >
> > > is to
On Tue, 01 Apr 2014 11:08:13 +0300
Jani Nikula wrote:
> On Mon, 31 Mar 2014, Jesse Barnes wrote:
> > Going below the minimum value may affect the BLC_EN line, so try to use
> > the VBT provided minimum where possible, otherwise use an experimentally
> > derived value to p
On Tue, 01 Apr 2014 12:27:43 +0300
Jani Nikula wrote:
> On Tue, 01 Apr 2014, Jani Nikula wrote:
> > On Mon, 31 Mar 2014, Jesse Barnes wrote:
> >> To make sure we properly follow the enable/disable sequences.
> >>
> >> Signed-off-by: Jesse Barnes
> >&
On Tue, 01 Apr 2014 10:19:29 +0300
Jani Nikula wrote:
> On Mon, 31 Mar 2014, Jesse Barnes wrote:
> > To make sure we properly follow the enable/disable sequences.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > driver
On Mon, 31 Mar 2014 21:07:04 +0200
Daniel Vetter wrote:
> On Mon, Mar 31, 2014 at 11:13:57AM -0700, Jesse Barnes wrote:
> > Going below the minimum value may affect the BLC_EN line, so try to use
> > the VBT provided minimum where possible, otherwise use an experimentally
>
nfoframe.
> >
> > v2: Ville's inputs incorporated. Added picture aspect ratio as part of
> > edid_cea_modes instead of DRM_MODE
> >
> > Signed-off-by: Vandana Kannan
> > Reviewed-by: Alex Deucher
>
> Reviewed-by: Ville Syrjälä
Note this one is neede
tions are
> satisfied, PAR is NONE as per initialization.
>
> As a next step, create a property that would enable a user space app to set
> aspect ratio. (will be pushed as a separate patch)
>
> Signed-off-by: Vandana Kannan
> Cc: Jesse Barnes
> Cc: Vijay Purushothaman
>
Going below the minimum value may affect the BLC_EN line, so try to use
the VBT provided minimum where possible, otherwise use an experimentally
derived value to prevent the panel from coming up.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915
To make sure we properly follow the enable/disable sequences.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c| 62 --
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_panel.c | 5 ++-
3 files changed, 65 insertions
With the new checks in place, we can see we're doing things backwards,
so fix them up per the spec.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gp
->gen > 3)
Funky indeed. I wonder if we should congratulate the user if we detect
this configuration. "Achievement unlocked: funky mode timings!".
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ited_color_range)
Hooray for SDVO. I really hope no one tries to do that on VLV...
(afaik it's unsupported but who knows the hw might work if someone
solders such a board together).
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
intel_pipe_has_type(&intel_crtc->base, INTEL_OUTPUT_SDVO))
> + vsyncshift = (adjusted_mode->crtc_htotal - 1) / 2;
> + else
> + vsyncshift = adjusted_mode->crtc_hsync_start -
> + adjusted_mode->crtc_htotal / 2;
> }
>
This makes HDMI testers happier on VLV platforms. It may be that we
need it for any non-SVO platform, but I don't have any tests to back
that up, so I'm leaving other pre-ILK platforms alone for now.
Tested-by: "Clint Taylor "
Signed-off-by: Jesse Barnes
---
On Thu, 20 Mar 2014 10:30:32 -0700
Jesse Barnes wrote:
> On Thu, 20 Mar 2014 14:42:32 +0100
> Daniel Vetter wrote:
>
> > On Wed, Mar 19, 2014 at 05:41:37PM -0700, Ben Widawsky wrote:
> > > I can't say it's completely unexpected that this would be your respons
imitive emission seems like
it's going to keep power consumption in a terrible state on BDW for the
forseeable future... moreover I guess this is something we need going
back forever for RC6 stability, at least according to the hw team. So
rather than blocking this, maybe we should commit it for all platforms!
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Chromium for disabling PSR in cases where it
doesn't work? Or to optimize power consumption when the kernel driver
gets it wrong? Or just for debug?
Seems potentially useful, just curious what motivated you guys.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
_
g the pd_mask.
>
> > + i915_pte_index(addr, pde_shift);
> > +
> > + return i915_pte_index(end, pde_shift) - i915_pte_index(addr, pde_shift);
> > +}
>
> Otherwise the helpers look a useful improvement in readability.
> -Chris
>
Can we use GTT_PAGE_SIZE here too? I'm worried the kernel PAGE_SIZE
will change at some point and blow us up. At least in places where
we're doing our own thing rather than using the x86 bits...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Junxiao, can you add you reviewed-by to this patch?
Thanks,
Jesse
On Mon, 3 Mar 2014 14:27:57 -0800
Jesse Barnes wrote:
> So don't try to allocate and program it, we're only fooling ourselves.
>
> Reported-by: "Chang, Junxiao"
> Signed-off-by: Jesse Barne
Let them eat cake.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_params.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index a66ffb6..5f81047 100644
--- a/drivers/gpu/drm/i915
From: Kristian Høgsberg
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gp
As of IVB, the memory controller does internal swizzling already, so we
shouldn't need to enable these. Based on an earlier fix from Kristian.
v2: preserve swizzling if BIOS had it set (Daniel)
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_
)
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
t;
> > That's what I meant. No delayed runtime_pm_put.
>
> Well I've figured we want to keep this ... have things changed
> sufficiently meanwhile? I've lost a bit track in all that recent
> shuffling ...
Can we pull the forcewake bits out of the reg functions and
On Fri, 14 Mar 2014 19:16:01 +0100
Daniel Vetter wrote:
> On Fri, Mar 14, 2014 at 7:03 PM, Jesse Barnes
> wrote:
> > Yeah just saying a man page should be required as part of any new
> > ioctl.
>
> Yeah I agree and long-term we'll get there. Otherwise I wouldn
On Fri, 14 Mar 2014 19:00:46 +0100
Daniel Vetter wrote:
> On Fri, Mar 14, 2014 at 6:06 PM, Jesse Barnes
> wrote:
> >> 3) Documentating userspace ABIs like ioctls structures&flags, properties
> >> and so on.
> >>
> >> I have no idea how to do 3
n page updates. We need to be
good about catching this on review for new stuff.
For older stuff I think there was a bit of momentum awhile back, but it
seems to have dissipated.
We could try to extract it from kernel source somehow, but for user API
stuff, I think we really want man pages in li
On Sat, 8 Mar 2014 11:36:24 +0100
Daniel Vetter wrote:
> On Fri, Mar 07, 2014 at 08:57:53AM -0800, Jesse Barnes wrote:
> > As of IVB, the memory controller does internal swizzling already, so we
> > shouldn't need to enable these. Based on an earlier fix from Kristian.
On Sat, 8 Mar 2014 11:33:15 +0100
Daniel Vetter wrote:
> On Fri, Mar 07, 2014 at 08:57:55AM -0800, Jesse Barnes wrote:
> > By stuffing the fb allocation into the crtc, we get mode set lifetime
> > refcounting for free, but have to handle the initial pin & fence
> > sligh
S fbs (Kristian)
pull out common bits (Jesse)
v13: move fb obj alloc out to _init
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 63
1 file changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm
From: Kristian Høgsberg
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gp
Some machines may have a broken VBT or no VBT at all, but we still want
to use SSC there. So check for it and keep it enabled if we see it
already on. Based on an earlier fix from Kristian.
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c
nditional (Daniel)
v12:fix up fb vs pipe size checking (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 1 -
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 174 +--
3 files changed, 166 insertio
n error (Daniel)
take fbdev fb ref and remove unused error path (Daniel)
Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 145 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_
As of IVB, the memory controller does internal swizzling already, so we
shouldn't need to enable these. Based on an earlier fix from Kristian.
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c| 7 +++
drivers/gpu/drm
Early at init time, we can try to read out the plane config structure
and try to preserve it if possible.
v2: alloc fb obj at init time after fetching plane config
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/intel_display.c | 92
This should allow BIOS fb inheritance to work on ILK+ machines too.
v2: handle tiled BIOS fbs (Kristian)
split out common bits (Jesse)
v3: alloc fb obj out in _init
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 62
1 file
t; 16) | crtc_x);
>
> @@ -492,6 +612,9 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc
> *crtc,
> I915_WRITE(DVSSURF(pipe),
> i915_gem_obj_ggtt_offset(obj) + dvssurf_offset);
> POSTING_READ(DVSSURF(pipe));
> +
> + if (atomic_update)
> + intel_pipe_update_end(intel_crtc, start_vbl_count);
> }
>
> static void
> @@ -500,7 +623,12 @@ ilk_disable_plane(struct drm_plane *plane, struct
> drm_crtc *crtc)
> struct drm_device *dev = plane->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> int pipe = intel_plane->pipe;
> + u32 start_vbl_count;
> + bool atomic_update;
> +
> + atomic_update = intel_pipe_update_start(intel_crtc, &start_vbl_count);
>
> I915_WRITE(DVSCNTR(pipe), I915_READ(DVSCNTR(pipe)) & ~DVS_ENABLE);
> /* Disable the scaler */
> @@ -509,6 +637,9 @@ ilk_disable_plane(struct drm_plane *plane, struct
> drm_crtc *crtc)
> I915_WRITE(DVSSURF(pipe), 0);
> POSTING_READ(DVSSURF(pipe));
>
> + if (atomic_update)
> + intel_pipe_update_end(intel_crtc, start_vbl_count);
> +
> /*
>* Avoid underruns when disabling the sprite.
>* FIXME remove once watermark updates are done properly.
Yeah looks like this will work ok.
I don't understand the prepare_to_wait() comment, since we're both
holding the crtc mutex and prepare_to_wait() will take the crtc
vbl_wait queue lock, but since things look safe as-is I guess it's not
a big deal.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
VLV_DPIO_TX_C_LANES_01_POWER_DOMAINS |
> +VLV_DPIO_TX_C_LANES_23_POWER_DOMAINS,
> + .ops = &vlv_dpio_power_well_ops,
> + .data = PUNIT_POWER_WELL_DPIO_TX_C_LANES_01,
> + },
> + {
> + .name = "dpio-tx-c-23",
> +
= intel_set_cpu_fifo_underrun_reporting_nolock(dev, pipe, enable);
> spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
> +
> return ret;
> }
>
Funky how diff left the spin_unlock line alone. :)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ng it to be enabled.
> - */
> void intel_power_domains_init_hw(struct drm_i915_private *dev_priv)
> {
> /* For now, we need the power well to be always enabled. */
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
dev_priv->display_irqs_enabled = true;
> +
> + if (dev_priv->dev->irq_enabled)
> + valleyview_display_irqs_install(dev_priv);
> +}
This made me do a double take, then I saw you were checking the actual
drm_device irq enabled state rather than checking the new
enc_to_intel_hdmi(&encoder->base);
> + enum intel_display_power_domain power_domain;
> u32 tmp;
>
> + power_domain = intel_display_port_power_domain(encoder);
> + if (!intel_display_power_enabled(dev_priv, power_domain))
> + return false;
&g
ret;
> }
>
> static bool
> intel_hdmi_detect_audio(struct drm_connector *connector)
> {
> - struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> + struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&intel_encoder->base);
> struct drm_i915_private *dev_priv = connector->dev->dev_private;
> + enum intel_display_power_domain power_domain;
> struct edid *edid;
> bool has_audio = false;
>
> + power_domain = intel_display_port_power_domain(intel_encoder);
> + intel_display_power_get(dev_priv, power_domain);
> +
> edid = drm_get_edid(connector,
> intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus));
> @@ -975,6 +996,8 @@ intel_hdmi_detect_audio(struct drm_connector *connector)
> kfree(edid);
> }
>
> + intel_display_power_put(dev_priv, power_domain);
> +
> return has_audio;
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
->count);
>
> - if (!--power_well->count && i915.disable_power_well)
> + if (!--power_well->count && i915.disable_power_well) {
> + DRM_DEBUG_KMS("disabling %s\n", power_well->name);
> po
each_pipe(pipe)
> + if (pipe != PIPE_A)
> + reset_vblank_counter(dev, pipe);
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
e.
> - */
> - dev_priv->irq_mask = (~enable_mask) |
> - I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT |
> - I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
> + dev_priv->irq_mask = ~enable_mask;
>
> I915_WRITE(PORT_HOTPLUG_EN, 0);
> POSTING_READ(PORT_HOTPLUG_EN);
Reviewed-by: Jesse
gt;pipe)))
> + return false;
> +
> pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> pipe_config->shared_dpll = DPLL_ID_PRIVATE;
>
Same goes here, though I suppose there's more room for additional,
specific domains down at this l
> - if (power_well->ops->sync_hw)
> - power_well->ops->sync_hw(dev_priv, power_well);
> - }
> + for_each_power_well(i, power_well, POWER_DOMAIN_MASK, power_domains)
> + power_well->ops->sync_hw(dev_priv, power_well);
> mutex_unlock(&power_domains->lock);
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
BIT(POWER_DOMAIN_PIPE_A) | \
> - BIT(POWER_DOMAIN_TRANSCODER_EDP))
> + BIT(POWER_DOMAIN_TRANSCODER_EDP) | \
> + BIT(POWER_DOMAIN_INIT))
> #define HSW_DISPLAY_POWER_DOMAINS ( \
> (POWER_DOMAIN_MASK & ~HSW_ALWAYS_ON_POWER_D
.is_enabled = hsw_power_well_enabled,
> .set = hsw_set_power_well,
> },
> @@ -5414,7 +5430,7 @@ static struct i915_power_well bdw_power_wells[] = {
> },
> {
> .name = "display",
> - .domains = POW
> Signed-off-by: Imre Deak
> Reviewed-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_dma.c | 14
> drivers/gpu/drm/i915/i915_drv.c | 4 +--
> drivers/gpu/drm/i915/i915_drv.h | 4 +--
> drivers/gpu/drm/i915/intel_display.c | 27 +++
&g
gs and/or tasks filed for all these, or just the one? We
need to make sure people are signed up to fix/review them, or it'll end
up staying disabled forever, and then we'll be stuck without a command
checker and some advanced features coming up...
--
Jesse Barnes, Intel Open Source Techn
No special reason. It shouldn't matter on BYT either, really, since
pipe A doesn't have special characteristics like it does on HSW.
Jesse
On Thu, 6 Mar 2014 17:19:22 +0800
"Lin, Mengdong" wrote:
> Hi Jesse,
>
>
>
> Could you tell us why Baytrail Gfx driver does not always use pipe A when
On Thu, 6 Mar 2014 11:28:13 +0200
Ville Syrjälä wrote:
> On Wed, Mar 05, 2014 at 02:48:30PM -0800, Jesse Barnes wrote:
> > It takes awhile to fetch the DPCD and EDID for caching, so take it out
> > of the critical path to improve init time.
> >
> >
On Thu, 6 Mar 2014 09:12:40 +
Chris Wilson wrote:
> On Wed, Mar 05, 2014 at 02:48:27PM -0800, Jesse Barnes wrote:
> > This gets us out of our init code and out to userspace quite a bit
> > faster, but does open us up to some bugs given the state of our init
> > time loc
On Thu, 6 Mar 2014 09:35:23 +
Chris Wilson wrote:
> On Wed, Mar 05, 2014 at 02:48:26PM -0800, Jesse Barnes wrote:
> > @@ -7554,6 +7610,8 @@ static int intel_crtc_cursor_set(struct drm_crtc
> > *crtc,
> > goto fail;
> > }
> &g
On Thu, 06 Mar 2014 01:29:14 +0200
Imre Deak wrote:
> On Wed, 2014-03-05 at 14:48 -0800, Jesse Barnes wrote:
> > This lets us return to userspace more quickly and should improve init
> > and suspend/resume times as well, allowing us to return to userspace
> > sooner.
>
In the hotplug case, nothing was grabbing VDD, leading to some warnings.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 763f235..78c883e 100644
--- a
This gets us out of our init code and out to userspace quite a bit
faster, but does open us up to some bugs given the state of our init
time locking.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c| 3 ++-
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915
Reduces params in a few places and makes workqueueing the eDP caching work
easier.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 23 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu
This lets us return to userspace more quickly and should improve init
and suspend/resume times as well, allowing us to return to userspace
sooner.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915
I'm worried about the locking in this... I've also commented out the
state checker, but that can be re-added as a check after any queued CRTC
changes as another queued item, so should be easy to fix.
This set drastically improves the init time of the i915 module (based on
initcall_debug timing),
Drivers ought to complain otherwise.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 4
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm
It takes awhile to fetch the DPCD and EDID for caching, so take it out
of the critical path to improve init time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 113 +---
1 file changed, 82 insertions(+), 31 deletions(-)
diff --git a
On Wed, 5 Mar 2014 19:34:45 +0100
Daniel Vetter wrote:
> On Wed, Mar 05, 2014 at 08:27:08AM -0800, Jesse Barnes wrote:
> > On Tue, 4 Mar 2014 22:08:12 +0100
> > Daniel Vetter wrote:
> >
> > > On Tue, Mar 04, 2014 at 12:33:01PM -0800, Jesse Barnes wrote:
> &
On Tue, 4 Mar 2014 22:08:12 +0100
Daniel Vetter wrote:
> On Tue, Mar 04, 2014 at 12:33:01PM -0800, Jesse Barnes wrote:
> > On Tue, 4 Mar 2014 21:08:42 +0100
> > Daniel Vetter wrote:
> >
> > > Both Ville and QA rather immediately complained that with the new
&
On Wed, 5 Mar 2014 13:55:00 +0100
Daniel Vetter wrote:
> On Thu, Feb 20, 2014 at 08:50:59PM +, Chris Wilson wrote:
> > On Thu, Feb 20, 2014 at 12:39:57PM -0800, Jesse Barnes wrote:
> > > Useful for bug reports.
> >
> > Hey, this would be useful for error state
(it even has hotplug handling and all that) fall back if more
> outputs could have been enabled.
>
> v2: Fix up my confusion about what enabled means - it's passed from
> the fbdev helper, we need to check for a non-zero connector->encoder
> link. Spotted by Ville.
>
&
On Tue, 4 Mar 2014 21:08:41 +0100
Daniel Vetter wrote:
> It started as a simple check whether anything is lit up, but now is't
> used to driver the general fallback logic to the default output
> configuration selector in the helper library. So rename it for more
> clarity.
>
tel_crtc(crtc)->unpin_work != NULL;
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> -
> - return pending;
> -}
> -
> bool intel_has_pending_fb_unpin(struct drm_device *dev)
> {
> struct intel_crtc *crtc;
Looks fine, my only comment is do we
On Fri, 7 Feb 2014 18:37:01 -0200
Rodrigo Vivi wrote:
> From: Jesse Barnes
>
> The intent is to get back to userspace as quickly as possible so it can
> start doing drawing or whatever. It should also allow our
> suspend/resume/init time to improve a lot.
>
> Signed
On Mon, 3 Mar 2014 11:14:09 -0800
Jesse Barnes wrote:
> On Thu, 27 Feb 2014 11:01:08 +0200
> Jani Nikula wrote:
>
> > On Thu, 27 Feb 2014, Jani Nikula wrote:
> > > On Wed, 26 Feb 2014, Jesse Barnes wrote:
> > >> On Mon, 13 Jan 2014 16:25:21 +05
So don't try to allocate and program it, we're only fooling ourselves.
Reported-by: "Chang, Junxiao"
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i
On Thu, 27 Feb 2014 11:01:08 +0200
Jani Nikula wrote:
> On Thu, 27 Feb 2014, Jani Nikula wrote:
> > On Wed, 26 Feb 2014, Jesse Barnes wrote:
> >> On Mon, 13 Jan 2014 16:25:21 +0530
> >> akash.g...@intel.com wrote:
> >>
> >>> From: Akash
701 - 800 of 3350 matches
Mail list logo
