On Wed, 21 Sep 2011 09:47:59 +0530, Jesse Barnes
wrote:
> I'm worried this makes our PPS even more complex and hard to follow.
> I'd rather see VDD AUX applied only when we need it (dpms, mode set and
> detect; for hotplug we can assume the panel is alive) and that we
> carefully disable it afte
On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
wrote:
> This one mixes up lots of cleanups plus the EDID read with the power
> changes.
I think the cleanups are;
1) edp checks inside vdd_on and vdd_off to make the other code a bit
easier to read.
2) Hold VDD on until the end of dp_com
On Mon, 19 Sep 2011 15:22:03 -0700
Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then remembe
On Mon, 19 Sep 2011 15:22:00 -0700
Keith Packard wrote:
> The eDP panel may not be able to respond to aux channel communications
> unless it has power supplied. During mode setting, power may be
> cut-off during panel power sequencing. Make sure that any aux channel
> communications will work by
Add the addresses and definitions I care about for Panel Self Refresh, as
documented in the eDP spec.
I'm sending these out before some other patches because this should be a fairly
simple one to get upstream and not require too much fuss (where the others may
have some fuss).
This file is a mess
On Tue, 20 Sep 2011 13:06:43 +0200
Daniel Vetter wrote:
> On Mon, Sep 19, 2011 at 09:25:00PM -0700, Ben Widawsky wrote:
> > I'm going to keep this short...
> > Patch 5 is my test case.
> > On Gen6 I see slightly better performance. On Gen5 I see really
> > really improvements (like 3x) for non GT
On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter wrote:
> Now non-blocking cpu mmaps make very much sense on llc/snooped buffer
> objects. So I think we actually need an ioctl to get obj->cache_level so
> userspace can decide whether it should use non-blocking gtt mmaps or cpu
> (non-bloc
On Tue, 20 Sep 2011 18:31:25 +0100, Simon Farnsworth
wrote:
> + /* Set up hotplug command - note paranoia about contents of reply.
> + * We simply clear out the bits we understand, and hope that
> + * the rest are in good shape for the hardware.
> + */
> + intel_sdvo_get_v
On Tue, Sep 20, 2011 at 10:17:25AM -0700, Eric Anholt wrote:
> On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter wrote:
> > - Why do we need any patches for gtt non-blocking mmaps? I've re-read our
> > code, and afaics we're only calling wait_rendering from gem_fault if
> > obj->gtt_space == N
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of hel
On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter wrote:
> - Why do we need any patches for gtt non-blocking mmaps? I've re-read our
> code, and afaics we're only calling wait_rendering from gem_fault if
> obj->gtt_space == NULL. I.e. there's no way the gpu is currently using
> the data and
On Tue, 20 Sep 2011 17:57:21 +0100, Simon Farnsworth
wrote:
> Sounds perfectly reasonable to me. I'll whip up patch v5 before I head home
> tonight.
Thanks much, I hate to bikeshed this far, but I doubt anyone else will
ever go back and rework this code later on.
> I'll add a comment to the c
On Tuesday 20 September 2011, Keith Packard wrote:
> On Tue, 20 Sep 2011 17:38:37 +0100, Simon Farnsworth
wrote:
> > This interacts badly with the need I've found to call this function every
> > time a hotplug interrupt comes through (explained below) - I'm not sure
> > how to track back from th
On Tue, 20 Sep 2011 17:38:37 +0100, Simon Farnsworth
wrote:
> This interacts badly with the need I've found to call this function every
> time
> a hotplug interrupt comes through (explained below) - I'm not sure how to
> track back from the encoder (which gets the callback) to the SDVO device
On Tue, 20 Sep 2011 12:41:16 +0200, Rainer Dorsch wrote:
> I am wondering what I could do to figure out the root cause of the problem. I
> forgot to try, but I assume, that I could ssh into the machine and do some
> diagnosis, when the problem occurs. Are there logs which could help? I attach
On Tuesday 20 September 2011, Keith Packard wrote:
> On Tue, 20 Sep 2011 15:17:38 +0100, Simon Farnsworth
wrote:
> > - if (on) {
> > - intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL,
> > 0); - status = intel_sdvo_read_response(intel_sdvo,
> > &re
On Tue, 20 Sep 2011 17:24:21 +0100, Chris Wilson
wrote:
> On Tue, 20 Sep 2011 08:47:21 -0700, Keith Packard wrote:
> > We were relying on the BIOS to set these bits, which doesn't always
> > happen.
>
> Do we need to clear IRQ bits on uninstall, for example to prevent
> "Interrupt 19: no one ca
On Tue, 20 Sep 2011 15:17:38 +0100, Simon Farnsworth
wrote:
> - if (on) {
> - intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
> NULL, 0);
> - status = intel_sdvo_read_response(intel_sdvo, &response, 2);
> + intel_sdvo_write_cmd(intel_sdvo, SDVO_CM
On Tue, 20 Sep 2011 08:47:21 -0700, Keith Packard wrote:
> We were relying on the BIOS to set these bits, which doesn't always
> happen.
Do we need to clear IRQ bits on uninstall, for example to prevent
"Interrupt 19: no one cared!" or is that due to a different cause?
More of a general question
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
v2: set the hotplug bits in the irq post-install hook, just
like we do for pre-PCH hardware.
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_r
On Tuesday 20 September 2011, Simon Farnsworth
wrote:
> I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
> poll for connection on DVI attached by SDVO.
>
> As my SDVO DVI supports hotplug detect interrupts, the fix is to
> enable them, and hook them in to the various bits of d
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of hel
On Tuesday 20 September 2011, Chris Wilson wrote:
> On Tue, 20 Sep 2011 13:52:59 +0100, Simon Farnsworth
wrote:
> > + connector = intel_sdvo_find_connector(intel_sdvo);
> > + if (connector->polled == DRM_CONNECTOR_POLL_HPD) {
> > + intel_encoder->hot_plug = intel_sdvo_enable_hotplu
On Tue, 20 Sep 2011 13:52:59 +0100, Simon Farnsworth
wrote:
> + connector = intel_sdvo_find_connector(intel_sdvo);
> + if (connector->polled == DRM_CONNECTOR_POLL_HPD) {
> + intel_encoder->hot_plug = intel_sdvo_enable_hotplug;
> + intel_sdvo_enable_hotplug(intel_en
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of hel
On Tuesday 20 September 2011, Chris Wilson wrote:
> Couldn't spot anything wrong with the logic, so just style nitpicking.
> I'll have to fix the Ubuntu snafu that's preventing my one machine with
> a hotpluggable SDVO device from booting before I can test. Also need to
> find someone with the SDV
On Sat, Sep 17, 2011 at 09:57:05PM +0100, Chris Wilson wrote:
> On Sat, 17 Sep 2011 20:55:47 +0200, Daniel Vetter
> wrote:
> > The gtt_pwrite slowpath grabs the userspace memory with
> > get_user_pages. This will not work for non-page backed memory, like a
> > gtt mmapped gem object. Hence fall t
On Tue, 20 Sep 2011 11:45:00 +0100, Simon Farnsworth
wrote:
> I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
> poll for connection on DVI attached by SDVO.
>
> As my SDVO DVI supports hotplug detect interrupts, the fix is to
> enable them, and hook them in to the various bit
On Mon, Sep 19, 2011 at 09:25:00PM -0700, Ben Widawsky wrote:
> I'm going to keep this short...
> Patch 5 is my test case.
> On Gen6 I see slightly better performance. On Gen5 I see really really
> improvements (like 3x) for non GTT write only maps over regular mmaps.
> GTT mappings don't really sh
Hello,
I have occasionally (maybe once a week) the problem, that the video signal on
my system is dead when resuming after a suspend. The system itself is up an
running (and re-suspends after 10 minutes of inactivity as configured). When I
resume the re-suspend, that usually works. I.e. here th
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the
poll for connection on DVI attached by SDVO.
As my SDVO DVI supports hotplug detect interrupts, the fix is to
enable them, and hook them in to the various bits of driver
infrastructure so that they work reliably.
With lots of hel
On Mon, 19 Sep 2011 12:07:54 -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
These are a nice set of cleanups and the extra fault reporting may come
in handy. (I thought that fault register was to be used in conjunction
with ppgtt in order for the gpu to fault in pages...)
As Daniel me
On Tuesday 20 September 2011, Keith Packard wrote:
> On Wed, 17 Aug 2011 10:52:21 +0100, Simon Farnsworth
wrote:
> > static bool
> > intel_sdvo_multifunc_encoder(struct intel_sdvo *intel_sdvo)
> >
> > @@ -2062,7 +2053,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
> > int device)
>
On Mon, 19 Sep 2011 21:25:03 -0700, Ben Widawsky wrote:
> When doing a GTT mapping, the pages are not backed until taking a fault.
> If we know that the object is write only, when the fault happens we do not
> need
> to make the pages coherent with the CPU. This allows for semi fast prefaults
>
34 matches
Mail list logo
