On Wed, Sep 05, 2012 at 04:23:55PM -0700, Jesse Barnes wrote:
On Sun, 19 Aug 2012 21:12:17 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi all,
Changes since last time around:
- The prep patches are all merged now.
- I've left out the actual DP fixes/cleanups, I think we should
On Thu, Sep 06, 2012 at 08:55:40AM +0200, Daniel Vetter wrote:
On Wed, Sep 05, 2012 at 04:23:55PM -0700, Jesse Barnes wrote:
On Sun, 19 Aug 2012 21:12:17 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi all,
Changes since last time around:
- The prep patches are all merged
On Wed, Sep 05, 2012 at 11:02:15AM -0700, Jesse Barnes wrote:
On Sun, 19 Aug 2012 21:13:05 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
The is this encoder cloned check will be reused by the lvds encoder,
hence exract it.
v2: Be a bit more careful about that we need to check the
The gmbus interrupt generation is rather fiddly: We can only ever
enable one interrupt source (but we always want to check for NAK
in addition to the real bit). And the bits in the gmbus status
register don't map at all to the bis in the irq register.
To prepare for this mess, start by extracting
Only enables the interrupt and puts a irq handler into place, doesn't
do anything yet.
Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
pnv, but there the irq is marked as Test mode).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c |
We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
hand-roll the wait_event_timeout code so that we wake up every
jiffie and can
GMBUS_ACTIVE has inverted sense and so doesn't fit into the
wait_hw_status helper, hence create a new gmbus_wait_idle functions.
Also, we only care about the idle irq event and nothing else, which
allows us to use the wait_event_timeout helper directly without
jumping through hoops to catch NAKs.
On Thu, 6 Sep 2012 09:10:02 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
GMBUS_ACTIVE has inverted sense and so doesn't fit into the
wait_hw_status helper, hence create a new gmbus_wait_idle functions.
Also, we only care about the idle irq event and nothing else, which
allows us to use
Otherwise the newshiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c |
We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
hand-roll the wait_event_timeout code so that we wake up every
jiffie and can
On Wed, 5 Sep 2012 12:50:26 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 5 Sep 2012 21:48:52 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Sep 5, 2012 at 8:28 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
The variables have me confused a little... I
On Wed, 5 Sep 2012 13:04:54 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 5 Sep 2012 21:56:08 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Sep 5, 2012 at 8:31 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Wed, 29 Aug 2012 23:13:29 +0200
Daniel Vetter
Not very thoroughly tested yet. I'll be adding igt tests ASAP.
Ben Widawsky (6):
drm/i915: Enable some sysfs stuff without CONFIG_PM
drm/i915: variable renames
drm/i915: #define gpu freq multipler
drm/i915: Add current GPU freq to sysfs
drm/i915: Add setters for min/max frequency
The original patch was actually incorrect in stubbing out the sysfs for
l3 parity.
commit 5ab3633d6907018b0b830a720e877c3884d679c3
Author: Hunt Xu mhun...@gmail.com
Date: Sun Jul 1 03:45:07 2012 +
drm/i915: make rc6 in sysfs functions conditional
Unfortunately Hunt didn't respond to my
From: Ben Widawsky benjamin.widaw...@intel.com
Name variables a bit better for copy-pasters. This got turned up as part
of review for upcoming sysfs patches.
CC: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_sysfs.c | 16
Magic numbers are bad mmmkay. In this case in particular the value is
especially weird because the docs say multiple things. We'll need this
value for sysfs, so extracting it is useful for that as well.
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
Userspace applications such as PowerTOP are interesting in being able to
read the current GPU frequency. The patch itself sets up a generic array
for gen6 attributes so we can easily add other items in the future (and
it also happens to be just about the cleanest way to do this).
The patch is a
Provide a standardized sysfs interface for setting min, and max
frequencies. The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We have 3 states:
RP0 - ie. max frequency
RP1 - ie. local min frequency
RPn -
This is useful for userspace utilities which wish to use the previous
interface, specifically for micromanaging the increase/decrease steps by
setting min == max.
CC: Jacob Pan jacob.jun@linux.intel.com
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
From: Jesse Barnes jbar...@virtuousgeek.org
On SNB and IVB, there's an MSR (also exposed through MCHBAR) we can use
to read out the amount of energy used over time. Expose this in sysfs
to make it easy to do power comparisons with different configurations.
If the platform supports it, the file
On Sun, Aug 19, 2012 at 09:12:17PM +0200, Daniel Vetter wrote:
Hi all,
Changes since last time around:
- The prep patches are all merged now.
- I've left out the actual DP fixes/cleanups, I think we should merge those
in a
separte step.
- A few bugfixes (thanks to Paulo, Jani and
Hi all,
Just a few small follow-ups
- 2 patches to make pch/fdi handling more strict and add more asserts to check
that.
- 2 patches to make dpms handling around modesets more strict.
All four have been included in the modeset-rework branch since a long time and
hence seen tons of testing
Even with the old crtc helper code we should have disabled all
encoders on that pipe by now, and with the new code this would
definitely paper over a bug. We already have the necessary checks
in place in intel_disable_transcoder, so if we accidentally leave
a pch port on, this will be caught.
Because they should have been disabled when shutting down the display
pipe previously. To ensure that this is the case, add a few assserts
instead of unconditionally disabling the fdi link.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 8 +---
Hopefully this makes userspace slightly less confused about us
frobbing the dpms state behind its back. Yeah, it would be better
to be more careful with not changing the dpms state, but that is
quite more invasive.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
We need to check whether the _other plane is on our pipe, not whether
our plane is on the other pipe. Otherwise if not both pipes/planes are
active, we won't properly clean up the mess and set up our desired
plane-pipe mapping.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51265
Hi all!
Finally.
Now that the modeset-rework is merge I can finally dump the cpu edp fixes and
cleanups. Avoids my ivb edp from getting angry and leaving random pipes stuck in
the active state and the panel in the passive state.
Again, has been part of the modeset-rework branch since a longer
The cpu eDP encoder has some horrible hacks to set up the DP pll at
the right time. To be able to move them to the right place, add some
more encoder callbacks so that this can happen at the right time.
LVDS has some similar funky hacks, but that would require more work
(we need to move around
By using the new pre_enabel/post_disable functions.
To ensure that we only frob the cpu edp pll while the pipe is off add
the relevant asserts. Thanks to the new output state staging, this is
now really easy.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
With the previous patch to clean up where exactly these two functions
are getting called, this patch can tackle the enable/disable code
itself:
- WARN if the port enable bit is in the wrong state or if the edp pll
bit is in the wrong state, just for paranoia's sake.
- Don't disable the edp pll
These have been added because dp links are fiddle things and don't
like it when we try to re-train an enabled output (or disable a
disabled output harder). And because the crtc helper code is
ridiculously bad add tracking the modeset state.
But with the new code in place it is simply a bug to
See bspec, Vol3 Part2, Section 1.1.3 Display Mode Set Sequence. This
applies to all platforms where we currently support eDP on, i.e. ilk,
snb ivb.
Without this change we fail to light up the eDP port on previously
unused crtcs (likely because something is stuck on the old pipe), and
we also
On Thu, 6 Sep 2012 13:54:06 -0700
Ben Widawsky b...@bwidawsk.net wrote:
Magic numbers are bad mmmkay. In this case in particular the value is
especially weird because the docs say multiple things. We'll need this
value for sysfs, so extracting it is useful for that as well.
Reviewed-by:
On Thu, 6 Sep 2012 13:54:08 -0700
Ben Widawsky b...@bwidawsk.net wrote:
Provide a standardized sysfs interface for setting min, and max
frequencies. The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We
On Thu, 6 Sep 2012 13:54:09 -0700
Ben Widawsky b...@bwidawsk.net wrote:
This is useful for userspace utilities which wish to use the previous
interface, specifically for micromanaging the increase/decrease steps by
setting min == max.
CC: Jacob Pan jacob.jun@linux.intel.com
CC: Jesse
On Tue, 4 Sep 2012 21:02:54 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
We need to refcount our pages in order to prevent reaping them at
inopportune times, such as when they currently vmapped or exported to
another driver. However, we also wish to keep the lazy deallocation of
our
On 2012-09-06 14:09, Michael Larabel wrote:
Have you discussed this with Radeon/Nouveau to see if they would
adopt a common sysfs interface? In the past, Eugeni Dodonov and I had
talked about this with a desire to have the open-source drivers
expose
the useful information for monitoring in a
On Tue, 4 Sep 2012 21:02:55 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
On Tue, 4 Sep 2012 21:02:56 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
On Wed, 5 Sep 2012 16:23:55 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Sun, 19 Aug 2012 21:12:17 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi all,
Changes since last time around:
- The prep patches are all merged now.
- I've left out the actual DP fixes/cleanups,
On Tue, 4 Sep 2012 21:02:57 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.
One major advantage, other than unifying the page
Provide a standardized sysfs interface for setting min, and max
frequencies. The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We have 3 states:
RP0 - ie. max frequency
RP1 - ie. preferred min frequency
RPn -
42 matches
Mail list logo
