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 -
On Tue, 4 Sep 2012 21:02:57 +0100
Chris Wilson 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 tracking structures,
On Wed, 5 Sep 2012 16:23:55 -0700
Jesse Barnes wrote:
> On Sun, 19 Aug 2012 21:12:17 +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
>
On Tue, 4 Sep 2012 21:02:56 +0100
Chris Wilson 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.
>
> Signed-off-by: Chr
On Tue, 4 Sep 2012 21:02:55 +0100
Chris Wilson 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.
>
> Signed-off-by: Chr
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 si
On Tue, 4 Sep 2012 21:02:54 +0100
Chris Wilson 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 pages so we need to tak
On Tue, 4 Sep 2012 21:02:53 +0100
Chris Wilson wrote:
> In order to specialise functions depending upon the type of object, we
> can attach vfuncs to each object via a new ->ops pointer.
>
> For instance, this will be used in future patches to only bind pages from
> a dma-buf for the duration t
On Thu, 6 Sep 2012 13:54:09 -0700
Ben Widawsky 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
> CC: Jesse Barnes
> Signed-off-by: Ben Widawsky
>
On Thu, 6 Sep 2012 13:54:08 -0700
Ben Widawsky 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 have 3 states:
>
On Thu, 6 Sep 2012 13:54:06 -0700
Ben Widawsky 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: Jesse Barnes
--
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 f
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 disa
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 h
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
---
drivers/gpu/drm/i915/intel_dp.c | 74 +++-
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 the
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 ti
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
Tested-b
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
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
... because our current set_mode implementation doesn't bother to adjust
for the dpms state, we just forcefully update it. So stop pretending that
we're better than we are and rip out this extranous call.
Note that this totally confuses userspace, because the exposed connector
property isn't actua
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
---
drivers/gpu/drm/i915/intel_display.c | 8 +---
1 file changed, 5 inse
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.
Henc
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 alrea
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 an
From: Jesse Barnes
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 will show up under the
dr
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
CC: Jesse Barnes
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_sysfs.c | 36 +
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 - seri
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 ni
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
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 22 ++
From: Ben Widawsky
Name variables a bit better for copy-pasters. This got turned up as part
of review for upcoming sysfs patches.
CC: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_sysfs.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --g
The original patch was actually incorrect in stubbing out the sysfs for
l3 parity.
commit 5ab3633d6907018b0b830a720e877c3884d679c3
Author: Hunt Xu
Date: Sun Jul 1 03:45:07 2012 +
drm/i915: make rc6 in sysfs functions conditional
Unfortunately Hunt didn't respond to my review comments,
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
drm/i
On Wed, 5 Sep 2012 13:04:54 -0700
Jesse Barnes wrote:
> On Wed, 5 Sep 2012 21:56:08 +0200
> Daniel Vetter wrote:
>
> > On Wed, Sep 5, 2012 at 8:31 PM, Jesse Barnes
> > wrote:
> > > On Wed, 29 Aug 2012 23:13:29 +0200
> > > Daniel Vetter wrote:
> > >
> > >> Since this only calls crtc helper fu
On Wed, 5 Sep 2012 12:50:26 -0700
Jesse Barnes wrote:
> On Wed, 5 Sep 2012 21:48:52 +0200
> Daniel Vetter wrote:
>
> > On Wed, Sep 5, 2012 at 8:28 PM, Jesse Barnes
> > wrote:
> > >
> > > The variables have me confused a little... I would have expected
> > > update_state to take modeset_pipes
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 c
Otherwise the new&shiny 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
---
drivers/gpu/drm/i915/i915_dma.c | 5 ++---
drivers/gpu/d
On Thu, 6 Sep 2012 09:10:02 +0200, Daniel Vetter
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 the wait_event_tim
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.
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 c
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
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
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
On Wed, Sep 05, 2012 at 11:02:15AM -0700, Jesse Barnes wrote:
> On Sun, 19 Aug 2012 21:13:05 +0200
> Daniel Vetter 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 new, stage
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 wrote:
> >
> > > Hi all,
> > >
> > > Changes since last time around:
> > > - The prep patches are all merged now
43 matches
Mail list logo
