Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in
OpenGL programs such as Google MapsGL, Google Earth, and gzdoom.
While commit 09be664ecc77d58 introduced the workaround, the register
write didn't actually stick: a printk and I915_READ immediately after
the write would return the
On Wed, 25 Apr 2012 13:57:07 +0200
Daniel Vetter wrote:
> Hi all,
>
> In the light of the recent oops in the error state code I've resurrected my
> gpu
> hangman and brushed it up a bit. Together with the hangman check in i-g-t
> (which
> now also works a bit more reliable) we'll have a basic
Wait request is poorly named IMO. After working with these functions for
some time, I feel it's much clearer to name the functions more
appropriately.
Of course we must update the callers to use the new name as well.
This leaves room within our namespace for a *real* wait request function
at some
This helps implement glClientWaitSync.
Finally we can use the new timed seqno waiting function to allow
userspace to wait on a request with a timeout. This implements that
interface.
The new ioctl is very straight forward, there is a flags field which I
envision may be useful for various flush pe
Refactor.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 122 +--
1 file changed, 65 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f054439..63eda79 100644
--- a/drivers/
Insert a wait parameter in the code so we can possibly timeout on a
seqno wait if need be. The code should be functionally the same as
before because all the callers will continue to retry if an arbitrary
timeout elapses.
We'd like to have nanosecond granularity, but the only way to do this is
wit
It turns out throttle had an almost identical bit of code to do the
wait. Now we can call the new helper directly. This is just a bonus,
and not needed for the overall series.
v2: remove irq_get/put which is now in __wait_seqno (Ben)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_g
It's about to go away anyway. Just here to help bisection.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 06668eb..4de0515 100644
--
i915_wait_request is actually a fairly large function encapsulating
quite a few different operations. Because being able to wait on seqnos
in various conditions is useful, extracting that bit of code to a helper
function seems useful
v2: pull the irq_get/put as well (Ben)
Signed-off-by: Ben Widaw
The only time irq_get should fail is during unload or suspend. Both of
these points should try to quiesce the GPU before disabling interrupts
and so the atomic polling should never occur.
This was recommended by Chris Wilson as a way of reducing added
complexity to the polled wait which I introduc
The waiting_seqno is not terribly useful, and as such we can remove it
so that we'll be able to extract lockless code.
v2: Keep the information for error_state (Chris)
Check if ring is initialized in hangcheck (Chris)
Capture the waiting ring (Chris)
Signed-off-by: Ben Widawsky
---
drivers/gpu/
This extra bit of interrupt enabling code doesn't belong in the wait
seqno function. If anything we should pull it out to a helper so the
throttle code can also use it. The history is a bit vague, but I am
going to attempt to just dump it, unless someone can argue otherwise.
Removing this allows f
Not every caller of gpu_idle needs to retire requests. Try to pick only
the callers that need it. This was originally combined with the previous
patch in the first series on the mailing list.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c|1 -
drivers/gpu/drm/i91
This originates from a hack by me to quickly fix a bug in an earlier
patch where we needed control over whether or not waiting on a seqno
actually did any retire list processing. Since the two operations aren't
clearly related, we should pull the parameter out of the wait function,
and make the cal
Hopefully addressed all the comments from the first series. Tests and
sample libdrm remain in the same place.
Much thanks to Chris Wilson on helping me smash this into shape.
Ben Widawsky (12):
drm/i915: remove do_retire from i915_wait_request
drm/i915: remove some extra retiring
drm/i915:
On Thu, Apr 26, 2012 at 11:19:08PM +0200, Daniel Vetter wrote:
> i915_dma.c contains most of the old dri1 horror-show, so move
> the remaining bits there, too. The code has been removed and
> the only thing left are some stubs to ensure that userspace
> doesn't try to use this stuff. vblank_pipe_se
Because this is the place where we actually use the results of
them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 112 --
drivers/gpu/drm/i915/intel_pm.c | 113 +++
2 files changed, 113 insertions(+),
Two things:
- ring->virtual start is an __iomem pointer, treat it accordingly.
- dev_priv->status_page.page_addr is now always a cpu addr, no pointer
casting needed for that.
Take the opportunity to remove the unnecessary drm indirection when
setting up the ringbuffer iomapping.
Signed-off-by:
To get the fun stuff out of the way, the legacy hws is allocated by
userspace when the gpu needs a gfx hws. And there's no reference-counting
going on, so userspace can simply screw everyone over.
At least it's not as horrible as i810, where the ringbuffer is allocated
by userspace ...
We can't f
We kzalloc dev_priv, and we never use hws_map in intel_ringbuffer.c.
Reviewed-by: Chris Wilson
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers
They're now in intel_pm.c, so group them a bit better.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f4f1e8b..7c323c5 100
We now have a nice home for power management code, so let's use it!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 472 +-
drivers/gpu/drm/i915/intel_drv.h |3 +
drivers/gpu/drm/i915/intel_pm.c | 478
Unfortunately there has been dri1 userspace that used gem to manage
the gtt and hence also needed cliprects in the execbuf ioctl. So
we can't ever remove that code without breaking the ioctl abi.
But at least we can disable it on gen5+, because these horrible
versions of mesa have not supported th
Wohoo!
Now we only need to move all the gem/kms stuff that accidentally
landed in i915_dma.c out of it, and this will be our legacy dri1
grave-yard.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 26 ++
drivers/gpu
... and hide it in i915_dma.c.
This way all the legacy stuff dealing with READ_BREADCRUMB and
LP_RING and friends is in i915_dma.c.
v2: Rebase on top of Chris Wilson's rework irq handling code.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 13 +
Let's just get this out of the way.
v2: Rebase against ENODEV changes.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 110 +++
drivers/gpu/drm/i915/i915_drv.h |4 --
drivers/gpu/drm/i915/i915_irq.c | 110 --
We never supported dri1 on gen5+.
VLV never had that code, so no need to remove it.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.
This is a pretty racy way to close these races, and we have
much better means to cope with these races meanwhile: For
non-broken userspace we correctly wait for any outstanding
rendering, for broken userspace the hangcheck will save the
day.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
The LP refers to 'low priority' as opposed to the high priority
ring on gen2/3. So lets constrain its use to the code of that era.
Unfortunately we can't yet completely remove the associated
macros from common headers and shove them into i915_dma.c to
the other dri1 legacy support code, a few clea
Assigned in setparam, used never.
I didn't bother to dig through the archives to figure out what
this was supposed to do.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |1 -
drivers/gpu/drm/i915/i915_drv.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff -
Even the horrible gen3 XvMC code has learned to do this
right by the time xf86-video-intel releases learned to do
kernel modesetting. So we can just disallow this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
dif
... and shove allow_batchbuffer in there. More dragons will
follow suit.
There's the curious case that we allow this for KMS ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |8
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
drivers/gpu/drm/i915/i915_gem.c
i915_dma.c contains most of the old dri1 horror-show, so move
the remaining bits there, too. The code has been removed and
the only thing left are some stubs to ensure that userspace
doesn't try to use this stuff. vblank_pipe_set only returns 0
without any side-effects, so we can even stub it out w
Hi all,
Essentially just rebased on top of latest dinq. Happy bikeshedding!
Cheers, Daniel
Daniel Vetter (17):
drm/i915: move dri1 vblank stubs to i915_dma.c
drm/i915: create dev_priv->dri1 dragon dungeon^W^W sub-struct
drm/i915 disallow physical batchbuffers for KMS
drm/i915: rip out de
Hi all,
Essentially just rebased on top of latest dinq. Happy bikeshedding!
Cheers, Daniel
Daniel Vetter (17):
drm/i915: move dri1 vblank stubs to i915_dma.c
drm/i915: create dev_priv->dri1 dragon dungeon^W^W sub-struct
drm/i915 disallow physical batchbuffers for KMS
drm/i915: rip out de
On Wed, Apr 25, 2012 at 01:55:24PM -0700, Jesse Barnes wrote:
> On Tue, 24 Apr 2012 22:59:52 +0100
> Chris Wilson wrote:
>
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 11 ---
> > 1 file changed, 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i9
On Wed, Apr 25, 2012 at 10:28:41AM -0700, Kamal Mostafa wrote:
> i915.enable_backlight=0 can be used to disable i915 backlight control
> and the /sys/class/backlight/intel_backlight interface -- useful for
> systems where intel_backight conflicts with BIOS backlight control.
>
> BugLink: https://l
I've missed this one.
v2: Chris Wilson noticed another register.
v3: Color choice improvements.
Reviewed-by: Chris Wilson
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |8 ++--
drivers/gpu/drm/i915/i915_reg.h |2 --
drivers/gpu/drm/i915/intel_pm.c |3 +--
3 f
On Thu, Apr 26, 2012 at 03:21:09PM -0300, Eugeni Dodonov wrote:
> On Haswell, only one pipe can work in FDI mode, so this patch prevents
> messing with wrong registers when FDI is being used by non-first pipe.
>
> Signed-off-by: Eugeni Dodonov
I think we need to restrict the vga encoder to pipe
Haswell has different DIP control registers and offsets.
v2: also add the new DIP frame registers, as suggested by Daniel Vetter.
v2.1: fix a typo in HSW_VIDEO_DIP_VS_DATA name for 2nd register.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h | 34 +++
On Mon, 16 Apr 2012 15:29:41 +0100, Chris Wilson
wrote:
> IvyBridge has the ability to pageflip from either the Render or Blitter
> rings. Scheduling the pageflip on the active ring (if the new scanout is
> being rendered on either pipeline) saves inserting a semaphore (if
> available) and forcin
On Thu, Apr 26, 2012 at 03:21:11PM -0300, Eugeni Dodonov wrote:
> Starting with Haswell, DDI ports can work in FDI mode to support
> connectivity with the outputs located on the PCH.
>
> This commit adds support for such connections in the intel_ddi module, and
> provides Haswell-specific function
On Thu, 26 Apr 2012 21:33:02 +0200, Daniel Vetter
wrote:
> /* On GEN3 we really need to make sure the ARB C3 LP bit is set */
> if (IS_GEN3(dev)) {
> - u32 tmp = I915_READ(MI_ARB_STATE);
> - if (!(tmp & MI_ARB_C3_LP_WRITE_ENABLE)) {
> - /* a
Haswell has different DIP registers which we need to use for infoframes,
so add proper infrastructure to address that.
v2: add a comment to indicate that full DIP frames support is still not
there, as suggested by Daniel Vetter.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.
Haswell has different DIP control registers and offsets.
v2: also add the new DIP frame registers, as suggested by Daniel Vetter.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/g
I've missed this one.
v2: Chris Wilson noticed another register.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |6 ++
drivers/gpu/drm/i915/i915_reg.h |2 --
drivers/gpu/drm/i915/intel_pm.c |3 +--
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/
On Thu, Apr 26, 2012 at 09:12:16PM +0200, Carsten Emde wrote:
> Daniel,
>
> >Depending upon how things are set up, this might help.
> Yeah, thanks a lot, works great now!
>
> I removed patch 3/4 and 4/4 and pushed this one; so currently applied are:
> [PATCH 1/4] drm/i915: clear up backlight inve
On Thu, Apr 26, 2012 at 03:20:56PM -0300, Eugeni Dodonov wrote:
> Haswell has different DIP control registers and offsets.
>
> Signed-off-by: Eugeni Dodonov
Afaict hsw has a dip reg for every type of info frame, whereas older
machines have one dip reg and a switch in the control reg. Can you ple
DDI is introduced starting with Haswell GPU generation. So to simplify its
management in the future, we also add intel_ddi.c to hold all the
DDI-related items.
Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the
Daniel,
Depending upon how things are set up, this might help.
Yeah, thanks a lot, works great now!
I removed patch 3/4 and 4/4 and pushed this one; so currently applied are:
[PATCH 1/4] drm/i915: clear up backlight inversion confusion on gen4
[PATCH 2/4] drm/i915: completely revert the invert
v2: check for num_pipe instead, as suggested by Jesse
CC: Jesse Barnes
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_pm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0552058..4e0a
On Thu, 26 Apr 2012 18:24:54 +0200, Daniel Vetter
wrote:
> I've missed this one.
And MI_ARB_STATE.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mai
On Thu, 26 Apr 2012 15:20:59 -0300
Eugeni Dodonov wrote:
> Signed-off-by: Eugeni Dodonov
> ---
> drivers/gpu/drm/i915/intel_pm.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c index 0552058..06
On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.
Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
p
This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.
Signed-off-by: Eugeni Dodonov
---
drivers/char/agp/intel-agp.c|4
drivers/gpu/drm/i915/i915_drv.c |7 +++
2 files changed, 11 insertions(+)
diff --git a/dr
Move intel_hdmi data structure and support functions to a shared location,
to allow their usage from intel_ddi module.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_drv.h | 18 +-
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
2 files changed, 20
This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_ddi.c | 388 ++
1 file ch
Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.
Note that this bit does not indicates whether t
Those are driven by DDIs on Haswell architecture, so we need to keep track
of which DDI is being used on each output.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.
Those values can be programmed individually, by doi
DDI is introduced starting with Haswell GPU generation. So to simplify its
management in the future, we also add intel_ddi.c to hold all the
DDI-related items.
Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5be2ff1..b7e50af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/driv
Starting with Haswell, DDI ports can work in FDI mode to support
connectivity with the outputs located on the PCH.
This commit adds support for such connections in the intel_ddi module, and
provides Haswell-specific functionality to make it work.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/dr
As suggested by Chris Wilson and Daniel Vetter, this chunk of code can be
simplified with a more simple check.
CC: Daniel Vetter
CC: Chris Wilson
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff
On Haswell, only one pipe can work in FDI mode, so this patch prevents
messing with wrong registers when FDI is being used by non-first pipe.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff
Prevent bogus asserts on DDI-related paths.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 35 --
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display
Avoid bogus asserts on Lynx Point.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8308da0..ca0edbf 100644
--- a/drivers/gpu
The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.
v2: improve comment as per Chris Wilson suggestion
v3: incorporate latest changes in specs.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1
This attempts to enable all the available power wells during the
initialization.
Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considera
On Haswell, the recommended PCH-connected output is the one driven by DDI
E in FDI mode, used for VGA connection. All the others are handled by the
CPU.
Note that this does not accounts for Haswell/PPT combination yet.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 1
This should be already configured when FDI auto-negotiation is done.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/
This will throw a DRM_ERROR message when an unknown sdvox register is
given to intel_hdmi_init. When this happens, things could going to be pretty
much broken afterwards, so we better detect this as soon as possible.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c |2 ++
v2: prevent possible conflicts with VLV.
v3: simplify IRQ handling for Gen5+ onwards.
v1 Reviewed-by: Rodrigo Vivi
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_irq.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/d
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_pm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0552058..06f38ec 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/
With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.
v2: de-inline the function and address changes in bits names
v3: protect operations with dpio_lock, increase timeout to 100 for
paranoia sake.
v4:
Haswell has different DIP registers which we need to use for infoframes,
so add proper infrastructure to address that.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_hdmi.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i91
Haswell has different DIP control registers and offsets.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f1f4d8f..4f17b74 100644
--- a
Hi,
This patch aims at addressing all the bikesheds I had for the past ones, and
re-structure the patches in a more logical way.
The major changes are the introduction of the intel_ddi.c module, cleanup of
the debugging patches, and addition of functions to simplify digital outputs
handling for D
On Thu, Apr 26, 2012 at 07:25:32PM +0200, Daniel Vetter wrote:
> Depending upon how things are set up, this might help. If not, please
> install intel-gpu-tools and grab the output of intel_reg_dumper both
> when booting with nomodeset and when booting with kms.
>
> Thanks, Daniel
btw, all these
Depending upon how things are set up, this might help. If not, please
install intel-gpu-tools and grab the output of intel_reg_dumper both
when booting with nomodeset and when booting with kms.
Thanks, Daniel
---
drivers/gpu/drm/i915/intel_drv.h |3 ++-
drivers/gpu/drm/i915/intel_lvds.c |
On Thu, Apr 26, 2012 at 06:48:36PM +0200, Carsten Emde wrote:
> Bit #28 of the backlight control BLC_PWM_CTL2 is normally used
> to indicate whether the brightness of the panel backlight is
> inverted. Sometimes, however, bit #29 is used for this purpose.
> Add a quirk to mark machines that do so.
Bit #28 of the backlight control BLC_PWM_CTL2 is normally used
to indicate whether the brightness of the panel backlight is
inverted. Sometimes, however, bit #29 is used for this purpose.
Add a quirk to mark machines that do so.
Signed-off-by: Carsten Emde
---
drivers/gpu/drm/i915/i915_drv.h
The Acer Aspire 5734Z uses bit #29 instead of bit #28 to indicate that
the panel backlight brightness is inverted. Assign it to the related
quirk.
Signed-off-by: Carsten Emde
---
drivers/gpu/drm/i915/intel_display.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-tip/drivers/gpu/dr
The quirk to indicate that the panel backlight brightness is
inverted is not longer needed. Remove it.
Signed-off-by: Carsten Emde
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_display.c | 10 --
2 files changed, 11 deletions(-)
Index: linux-tip/driver
On 04/23/2012 06:55 PM, Carsten Emde wrote:
> On 04/23/2012 05:56 PM, Daniel Vetter wrote:
>> On Mon, Apr 23, 2012 at 05:38:27PM +0200, Carsten Emde wrote:
>>> On 04/23/2012 05:22 PM, Daniel Vetter wrote:
>> Ok, so the polarity bit does work as advertised. But I still don't
>> understand how your m
There's a bit in the docs for gen4 only that says whether the
backlight control is inverted. And both the quirk we have and
all bugs only concern i965gm and gm45 (and mostly Acer) afaics.
So lets drop the quirk and use the bit instead.
Also clean up the BLC register definitions a bit by correctly
On Thu, Apr 26, 2012 at 05:35:01PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Nothing major here and imo can wait a bit if you don't have anything
> important in drm-fixes yet:
> - VGA load-detect fix. This bug seems to be as old as the load-detect code
> (2.6.30), but needs stupid userspace (up
I've picked this up for -fixes, with Jesse's irc r-b added.
-Daniel
On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
> We seem to have a decent confusion between the output timings and the
> input timings of the sdvo encoder. If I understand the code correctly,
> we use the original
On Wed, Apr 11, 2012 at 12:37:24AM +0200, Daniel Vetter wrote:
> On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
> > Reported-and-Tested-by: Bernard Blackham
>
> This tested-by is actually a lie, I've mixed up a few bug reports. Bug
> reporter is currently on vacation and will test
I've missed this one.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h |1 -
drivers/gpu/drm/i915/intel_pm.c |3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f1f4d8f..529e0c9 1006
Hi Dave,
Nothing major here and imo can wait a bit if you don't have anything
important in drm-fixes yet:
- VGA load-detect fix. This bug seems to be as old as the load-detect code
(2.6.30), but needs stupid userspace (upowerd trying to detect
connectors on dpms-off outputs) to actually kill t
Every time we use the device after a period of idleness, check that the
power management setup is still sane. This is to workaround a bug
whereby it seems that we begin suppressing power management interrupts,
preventing SandyBridge+ from going into turbo mode.
This patch does have a side-effect.
The only question is the units for the interrupt thresholds. Everywhere
we treat the min/max frequencies in units of 50MHz. However, indications
seem to be that we expect the thresholds in units of 100MHz - though
currently we program them using the 50MHz values.
Cc: Jesse Barnes
---
drivers/gpu
On Wed, Apr 25, 2012 at 11:30:24PM -0300, Eugeni Dodonov wrote:
> On Apr 25, 2012 9:01 AM, "Daniel Vetter" wrote:
> > + /* Also reset the gpu hangman. */
> > + if (dev_priv->stop_rings) {
> > + DRM_DEBUG("Simulated gpu hang, resetting stop_rings\n");
>
> Maybe also print
94 matches
Mail list logo
