Hi,
I have following issue, while trying to boot Ubuntu on a development system to
Ubuntu UI. It boots to console terminal without any issue. If "startx" is
typed in the terminal then following error is encountered.
> > [ 1902.327] (EE) Screen(s) found
On DevCPT, the control register for Transcoder DP Sync Polarity is
TRANS_DP_CTL, not DP_CTL.
Without this patch, Many call trace occur on CPT machine with DP monitor.
The call trace is like: *ERROR* mismatch in adjusted_mode.flags(expected
X,found X)
v2: use intel-crtc to simple patch, suggested
Forgot the repo:
http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=ppgtt
On Thu, Jun 27, 2013 at 04:30:01PM -0700, Ben Widawsky wrote:
> First, I don't think this whole series is ready for merge yet. It is
> however ready for a review, and I think a lot of the prep patches in the
> series co
On Wed, Jun 12, 2013 at 01:37:19PM +0200, Daniel Vetter wrote:
> Now that the rps interrupt locking isn't clearly separated (at elast
> conceptually) from all the other interrupt locking having a different
> lock stopped making sense. With this we can (again) unifiy the
> ringbuffer irq refcounts w
On Wed, Jun 12, 2013 at 01:37:19PM +0200, Daniel Vetter wrote:
> Now that the rps interrupt locking isn't clearly separated (at elast
> conceptually) from all the other interrupt locking having a different
> lock stopped making sense. With this we can (again) unifiy the
> ringbuffer irq refcounts w
On Thu, Jun 27, 2013 at 04:31:02PM -0700, Ben Widawsky wrote:
> This requires doing an actual switch of the page tables during the
> context switch/execbuf.
>
> Along the way, cut away as much "aliasing" ppgtt as possible
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem.c
When originally implementing HW contexts it was not clear if we'd
strongly associate a context with a ring. Now it is clear, a context
will not belong to a ring. We've removed all remnants of it's usage. So
drop it completely now.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h
As of now (and this may change) we can't have aliasing PPGTT anymore (it
just won't happen). We do still have the aliasing ppgtt internally
though so we can use that to tell userspace if we have full PPGTT.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 7 +--
include/uapi
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 81 +
1 file changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 20d6265..6bbb602 100644
--- a/drivers/gpu/drm/i915/i915_d
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2dfa784..20d6265 100644
--- a/drivers/gpu/drm/i915
Dump the aliasing PPGTT with it. The aliasing PPGTT should actually
always be empty.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 60 +
3 files ch
vm->insert_entries was good enough. We can bring this function back
later if needed.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 22 --
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/i91
We have all the info earlier now, so we may as well avoid the excess
lookup.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 5 ++---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_gem_context.c| 21 ++---
drivers/g
This requires doing an actual switch of the page tables during the
context switch/execbuf.
Along the way, cut away as much "aliasing" ppgtt as possible
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c| 22 +-
drivers/gpu/drm/i915/i915_gem_context.c
This doesn't actually do the switch, but will actually add and remove
the new address spaces as needed. It is a good point for bisection.
It also adds create/destroy trace events. Notice the FIXME by the
destroy where I acknowledge a layering violation which can be fixed
later (or copy pasted, wha
Pin doesn't fit with PPGTT since the interface doesn't allow for the
context for which we want to pin.
Full PPGTT will bring a new "soft pin" interface. The semantics of which
will probably take some time to iron out.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 7 +++
We won't be calling enable() for all PPGTTs. We do need to write PDEs
for all PPGTTs however. By moving the writing to init (which is called
for all PPGTTs) we should accomplish this.
TODO: Eventually, we should allocate the page tables on demand.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm
In order to do the full context switch with address space, it's
convenient to have a way to switch the address space. We already have
this in our code - just pull it out to be called by the context switch
code later.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
dri
The docs seem to suggest this is the appropriate method (though it
doesn't say so outright). We certainly must do this for switching VMs on
the fly, since synchronizing the rings to MMIO updates isn't acceptable.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ++
We need to have the address space when reserving space for the objects.
Since the address space and context are tied together, and reserve
occurs before context switch (for good reason), we must lookup our
context earlier in the process.
This leaves some room for optimizations where we no longer n
At one time I was planning to call enable for all PPGTTs. I dropped
this, however I kept around this change because it looks better to me.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
drivers/gpu/drm/i915/i915_gem_gtt.c
In case something bad happens to the rings on init after a reset, but
debugfs is still available - we should still dump the information. This
is only possible with the change to do more teardown on reset.
NOTE: I've hit this in development, but it should be very unlikely once
the patches are stabl
Every file will get it's own context, and we use this context instead of
the default context. The default context still exists for future
shrinker usage as well as reset handling.
Since this now will cause open to fail if there is no space in the GGTT
for the PPGTT PDEs, and the context object, tr
Previously we dropped the association of a context to a ring. It is
however very important to know which ring a context ran on (we could
have reused the other member, but I was nitpicky).
This is very important when we switch address spaces, which unlike
context objects, do change per ring.
As an
With multiple rings having a last context, we must now unreference these
contexts.
This could be squashed if desired since it leaves the last patch broken.
However, because it was a bit tricky to catch, I've left it separated
for primarily review purposed
Signed-off-by: Ben Widawsky
---
drivers
This patch adds to changes for contexts on reset:
Sets last context to default - this will prevent the context switch
happening after a reset. That switch is not possible because the
rings are hung during reset and context switch requires reset. This
behavior will need to be reworked in the future,
We'll be doing a bit more stuff with each file, so having our own open
function should make things clean.
This also allows us to easily add conditionals for stuff we don't want
to do when we don't have HW contexts.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 4 +--
If we want to use contexts in more abstract terms (specifically with
PPGTT in mind), we need to allow them to be specified for any ring.
NOTE: This commit requires an update to intel-gpu-tools to make it not
fail.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c| 56 +
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f17d825..bead414 100644
--- a/dr
v2: Big conflict resolution on Damien's DEV_INFO_FOR_EACH stuff
v3: Resolved vebox addition
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 28 ++--
drivers/gpu/drm/i915/i915_drv.h | 11 ---
2 files changed, 26 insertions(+), 13 deletions(-)
d
It's quite common for an object to simply be on the inactive list (and
not unbound) when we want to free the context. This of course happens
with lazy unbinding. Simply, this is needed when an object isn't fully
unbound but we want to free one VMA of the object, for whatever reason.
Signed-off-by:
With context destruction, we always want to be able to tear down the
underlying address space. This is invoked on the last unreference to the
context which could happen before we've moved all objects to the
inactive list. To enable a clean tear down the address space, make sure
to process the reque
This allows us to be aware of all the VMAs leftover and teardown, and is
useful for debug. I suspect it will prove even more useful later.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 4
2 files changed, 6 insertions(+)
diff --gi
Probably need to squash whole thing, or just the inactive part, tbd...
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 14 ++--
drivers/gpu/drm/i915/i915_gem.c | 47 -
2 files changed, 35 insertions(+), 26 deletions(-)
diff --git
This is simply obj->active for now, but will serve a purpose when we
track activity per vma.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem.c| 18 --
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
The mm_list is used for the active/inactive LRUs. Since those LRUs are
per address space, the link should be per VM area
Because we'll only ever have 1 VMA before this point, it's not incorrect
to defer this change until this point in the patch series, and doing it
here makes the change much easie
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 53 -
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 28880bf..e1653fd 100644
--- a/drivers/gpu/drm/i91
Since the active/inactive lists are per VM, we need to modify the error
capture code to be aware of this, and also extend it to capture the
buffers from all the VMs. For now all the code assumes only 1 VM, but it
will become more generic over the next few patches.
NOTE: If the number of VMs in a r
This commit is split out because it's a bit tricky (or at least it was
for me). It could very well be squashed in to the previous commits.
The map_and_fenceable tracking is per object. Map_and_fenceable however
only makes sense in the context of the global gtt. As such, VMAs created
for any other
Remove the obj->gtt_space. See if it still works. This validates that
what we did in part 1 was correct.
BISECT WARNING: This patch was not meant for bisect. If it does end up
upstream, it should be included in the 3 part series for creating the
VMA.
Signed-off-by: Ben Widawsky
---
drivers/gpu/
This will be handy when we add VMs. It's not strictly, necessary, but it
will make the code much cleaner.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 26 +--
drivers/gpu/drm/i915/i915_drv.h| 21 +
drivers/gpu/drm/i915/i915_gem.c
Creates the VMA, but leaves the old obj->gtt_space in place. This
primarily just puts the basic infrastructure in place, and helps check
for leaks.
BISECT WARNING: This patch was not meant for bisect. If it does end up
upstream, it should be included in the 3 part series for creating the
VMA.
v2:
gtt_offset has always been == gtt_space->start. This makes an upcoming
change much easier to swallow.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 9 +++---
drivers/gpu/drm/i915/i915_drv.h| 7
drivers/gpu/drm/i915/i915_gem.c| 51
for file in `ls drivers/gpu/drm/i915/*.c` ; do sed -i
"s/dev_priv->mm.inactive_list/i915_gtt_mm-\>inactive_list/" $file; done
for file in `ls drivers/gpu/drm/i915/*.c` ; do sed -i
"s/dev_priv->mm.active_list/i915_gtt_mm-\>active_list/" $file; done
I've also opted to move the comments out of line
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(),
After we plumb our code to support multiple address spaces (VMs), there
are a few situations where we want to be able to traverse the list of
all address spaces in the system. Cases like eviction, or error state
collection are obvious example.
It's easy enough to test and make sure our list is acc
Every address space should support object allocation. It therefore makes
sense to have the allocator be part of the "superclass" which GGTT and
PPGTT will derive.
Since our maximum address space size is only 2GB we're not yet able to
avoid doing allocation/eviction; but we'd hope one day this beco
It doesn't apply to generic VMA, so it belongs with the gtt.
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.stolen_base/gtt.stolen_base/" $file;
done
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.stolen/gtt.stolen/" $file;
done
Signed-off-by: Ben Widaws
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.aliasing/gtt.aliasing/" $file;
done
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
drivers/gpu/drm/i915/i915_dma.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 6 +++---
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.gtt_mtrr/gtt.mtrr/" $file;
done
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 8
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/d
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions (insert entries), state (LRU lists) and
many of their characteristics (size), can be shared. Do that.
Created a i915_gtt_vm helper macro since for now we always want the
regular GTT address space. Event
The original pte_encode function needed the dev argument so we could do
platform specific handling via IS_GENX, etc. With the merging of a pte
encoding function there should never been a need to quirk away gen
specific details.
The patch doesn't do much but makes the upcoming reworks in gtt/ppgtt/
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 48 +++--
drivers/gpu/drm/i915/i915_gem_stolen.c | 20 +++---
drivers/gpu/drm/i915/intel_display.c | 6 ++---
drivers/gpu/drm/i915/intel_
Just for compactness.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 36 +++-
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 746b649..bb4ccb5 1
There isn't any special reason to do this other than it makes it obvious
that the two members are connected.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 -
2 files changed, 12 insertions(+), 11 deletion
A previous patch had set up the ppgtt and ggtt to use the same scratch
page, but still kept around both pointers. Kill it, it's not needed and
gets in our way for upcoming cleanups.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 5
When PPGTT support was originally enabled, it was only designed to
support 1 PPGTT. It therefore made sense to simply hide the GGTT space
required to enable this from the drm_mm allocator.
Since we intend to support full PPGTT, which means more than 1, and they
can be created and destroyed ad hoc
This is the second half to the previous patch in that now if PPGTT fails
to come up, contexts are disabled, and we don't even try to bring up
contexts when we don't have PPGTT support.
NB: PPGTT cleanup is now done in context unreference.
v2: Only cleanup if we set a cleanup vfunc. Don't clean PP
This will allows us to be able to check whether PPGTT was initialized
not by the pointer, but by the values of it's function pointers.
This will be used in the next patch in order to determine at context
destruction if the PPGTT needs cleanup. It should only occur in error
cases.
Signed-off-by: B
This will allow us to use the same code paths whether or not we have
PPGTT actually turned on. It will do all but actually enable the bits
that tell the HW to use PPGTT.
This patch also will help tie together contexts and PPGTT in the next
patch. That patch wants to disable contexts if there is no
In continuing to make default context/aliasing PPGTT behave like any
other context/PPGTT pair this patch sets us up by moving the
context/PPGTT init to a common location.
The resulting code isn't a huge improvement, but that will change in the
next patch (at least a bit).
In the process of doing
My long term vision is for contexts to have a 1:1 relationship with a
PPGTT. Sharing objects between address spaces would work similarly to
the flink/dmabuf model if needed.
The only current code to convert is the aliasing PPGTT. The aliasing
PPGTT is just the PPGTT for the default context.
The o
It's convenient to just call i915_gem_init_hw at reset because we'll be
adding new things to that function, and having just one function to call
instead of reimplementing it in two places is nice.
In order to accommodate we cleanup ringbuffers in order to bring them
back up cleanly. Optionally, we
We **need** to do this for exactly 1 reason, because we want to embed a
PPGTT into the context, but we don't want to special case the default
context.
To achieve that, we must be able to initialize contexts after the GTT is
setup (so we can allocate and pin the default context's BO), but before
th
The PPGTT PDEs serve as the guard page (as long as they remain at the
top) so we don't need yet another guard page. Note that there is a
potential issue if the aliasing PPGTT (and later, the default context)
relinquish this part of the GGTT. We should be able to assert that won't
happen however.
W
With the introduction of context refcounting we never explicitly
ref/unref the backing object. As such, the previous fix was a bit wonky.
Aside from fixing the above, this patch also puts us in good shape for
an upcoming patch which allows a failure to occur in between
context_init and the first d
From: Chris Wilson
Clients like i915 needs to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation o
This will help keep the next patch cleaner which will conditionally clear
the guard page, and use 0 num_entries when not actually clear space for
guard page.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/
Nothing outside of i915_gem_gtt.c and more specifically, the relevant
gen specific init function should need to know about number of PDEs, or
PTEs per PD. Exposing this will only lead to circumventing using the
upcoming VM abstraction.
To accomplish this, move the defines into the .c file, rename
Not only was there an extra, but since we now kzalloc the error state,
we don't need either.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 208e675..1
This helps when we have per VM buffer capturing.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 69 +++--
1 file changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index
First, I don't think this whole series is ready for merge yet. It is
however ready for a review, and I think a lot of the prep patches in the
series could be merged to make my rebasing life a bit easier. I cannot
continue ignoring pretty much all emails/bugs as I have for the last
month to wrap up
On Thu, Jun 27, 2013 at 11:14 PM, Paulo Zanoni wrote:
> 2013/6/25 Daniel Vetter :
>> Since we only have one interrupt handler and interrupt handlers are
>> non-reentrant.
>>
>> To drive the point really home give them all an _irq_handler suffix.
>
> Could we also add WARN(!in_irq()) or something e
2013/6/25 Daniel Vetter :
> Since we only have one interrupt handler and interrupt handlers are
> non-reentrant.
>
> To drive the point really home give them all an _irq_handler suffix.
Could we also add WARN(!in_irq()) or something equivalent for better
protection? Big backtraces are a nice way t
2013/6/12 Daniel Vetter :
> It's racy: There's no guarantee that we won't walk this code (due to a
> pch fifo underrun interrupt) while someone is changing the pointers
> around.
Can you please exemplify the "someone is changing the pointers around"
case? I need to make sure I fully understand thi
2013/6/12 Daniel Vetter :
> The current code won't report any fifo underruns on cpt if just one
> pipe has fifo underrun reporting disabled. We can't enable the
> interrupts, but we can still check the per-transcoder bits and so
> report the underrun delayed if:
> - We always clear the transcoder's
2013/6/12 Daniel Vetter :
> The preinstallhook is supposed to clear all interrupts. Doing it
> again in the postinstall hook has the risk that we're eating
> an interrupt source from the handler. If that happens too often,
> the kernel will disable our interrupt handler.
We do this with other regi
Now that we painstakingly track the shared pch dplls we can finally
implement pixel mutliplier readout support for pch ports, too.
v2: Undo the temporary hack to disable the sdvo pixel multiplier
cross-checking.
Cc: Imre Deak
Cc: Jesse Barnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i
On Thu, Jun 27, 2013 at 11:41:25AM -0300, Paulo Zanoni wrote:
> 2013/6/27 Daniel Vetter :
> > Our interrupt handler (in hardird context) could race with the timer
>
> s/hardird/hardirq/
>
> > (in softirq context), hence we need to hold the spinlock around the
> > call to ->hdp_irq_setup in intel_
On Tue, Jun 25, 2013 at 09:53:40PM -0700, Ben Widawsky wrote:
> With updates to the spec, we can actually see the context layout, and
> how many dwords are allocated. That table suggests we need 70720 bytes
> per HW context. Rounded up, this is 18 pages. Looking at what lives
> after the current 4
On Thu, Jun 27, 2013 at 04:54:44PM +0300, Mika Kuoppala wrote:
> Test both debugfs and sysfs error_state interfaces.
>
> Signed-off-by: Mika Kuoppala
> ---
> tests/ZZ_hangman | 34 +-
> 1 file changed, 21 insertions(+), 13 deletions(-)
>
> diff --git a/tests/ZZ
As we lie through the get_tiling ioctl about the swizzle mode, the
information that provides is unreliable and userspace has no way of
knowing the status of bit17 swizzling in the system. This prevents
userspace from using manual swizzling through a CPU map, which in
some circumstances is the optim
Our interrupt handler (in hardirq context) could race with the timer
(in softirq context), hence we need to hold the spinlock around the
call to ->hdp_irq_setup in intel_hpd_irq_handler, too.
But as an optimization (and more so to clarify things) we don't need
to do the irqsave/restore dance in th
The usual pattern for our sub-function irq_handlers is that they check
for the no-irq case themselves. This results in more streamlined code
in the upper irq handlers.
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich
Reviewed-by: Egbert Eich
Reviewed-by: Paulo Zanoni
Signed-off-
Everywhere the same.
Note that this patch leaves unnecessary braces behind, but the next
patch will kill those all anyway (including the if itself) so I've
figured I can keep the diff a bit smaller.
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich
Reviewed-by: Egbert Eich
Review
We already have a vfunc for this (and other parts of the hpd storm
handling code already use it).
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich
Reviewed-by: Egbert Eich
Reviewed-by: Paulo Zanoni
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 29 +
The combination of Paulo's fifo underrun detection code and Egbert's
hpd storm handling code unfortunately made the hpd storm handling code
racy.
To avoid duplicating tricky interrupt locking code over all platforms
start with a bit of refactoring. This patch is the very first step
since in the en
Just to keep the paranoia equal also sprinkle locking asserts over the
pipestat interrupt enable/disable functions.
Again this results in false positives in the interrupt setup. Add
bogo-locking for these and a big comment explaining why it's there and
that it's indeed unnecessary.
v2: Fix up the
On Thu, Jun 27, 2013 at 02:10:14PM +0800, rongqing...@windriver.com wrote:
> From: "Roy.Li"
>
> struct _Screen has no canDoBGNoneRoot when ABI_VIDEODRV_VERSION is less than
> 10.0
>
> Signed-off-by: Roy.Li
Thank you, pushed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
From: "Roy.Li"
struct _Screen has no canDoBGNoneRoot when ABI_VIDEODRV_VERSION is less than
10.0
Signed-off-by: Roy.Li
---
src/intel_display.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/intel_display.c b/src/intel_display.c
index 17168e5..0acb86d 100644
--- a/src/intel_displ
On 06/26/2013 04:12 PM, Winkler, Tomas wrote:
>
>
>>> Can you please send me the log part when this starts?
>>>
>>> Thanks
>>>
>>
>> It rolled over and I don't have prior messages. I tried reproducing twice and
>> didn't see it again. I will try a few more times and see if I can get it to
>> happe
On 06/25/2013 02:57 PM, Tomas Winkler wrote:
> On Tue, Jun 25, 2013 at 11:51 PM, Shuah Khan wrote:
>>
>> With this patch warn_on went away. Resume worked. I started seeing:
>>
>> [ 78.733062] mei_me :00:16.0: unexpected reset: dev_state =
>> RESETTING
>> [ 78.733079] mei_me :00:16.0:
On 06/25/2013 01:52 PM, Jesse Barnes wrote:
> On Tue, 25 Jun 2013 21:37:37 +0200
> Daniel Vetter wrote:
>
>>
>> Adding more lists to cc + Jesse since he's the guilty one for the
>> vt-switchless state restore stuff.
>
> Yeah, looks like we don't fetch the PLL state on resume from hibernate,
> lea
On 06/25/2013 02:06 PM, Jesse Barnes wrote:
> On Tue, 25 Jun 2013 19:59:28 +
> Shuah Khan wrote:
>
>> On 06/25/2013 01:52 PM, Jesse Barnes wrote:
>>> On Tue, 25 Jun 2013 21:37:37 +0200
>>> Daniel Vetter wrote:
>>>
>>
Adding more lists to cc + Jesse since he's the guilty one for the
2013/6/27 Daniel Vetter :
> Our interrupt handler (in hardird context) could race with the timer
s/hardird/hardirq/
> (in softirq context), hence we need to hold the spinlock around the
> call to ->hdp_irq_setup in intel_hpd_irq_handler, too.
>
> But as an optimization (and more so to clarify thi
To access 'error_state' through sysfs.
Signed-off-by: Mika Kuoppala
---
tests/drm_lib.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index 7eaf34e..72da4ad 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -29,4 +29,19 @@ if [
Test both debugfs and sysfs error_state interfaces.
Signed-off-by: Mika Kuoppala
---
tests/ZZ_hangman | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/tests/ZZ_hangman b/tests/ZZ_hangman
index 08c5514..303dbc7 100755
--- a/tests/ZZ_hangma
In preparation to have sysfs entries used in scripts
rename to more specific name.
Signed-off-by: Mika Kuoppala
---
tests/ZZ_hangman |2 +-
tests/debugfs_emon_crash |2 +-
tests/debugfs_reader |2 +-
tests/debugfs_wedged |4 ++--
tests/drm_lib.sh |8 ++
PSR tracking engine in HSW doesn't detect automagically some directly copy area
operations through scanout so we will have to kick it manually and
reschedule it to come back to normal operation as soon as possible.
v2: Before PSR Hook. Don't force it when busy yet.
v3: Solved small conflict.
Sign
This global value allows userspace know when PSR is enabled.
This will allow userspace emit more busy_ioctl when doing directly copy_area
operations through scanout allowing forced psr exit.
v2: Check for PSR enabled instead of active. (by Chris Wilson)
v3: Use existing intel_edp_is_psr_enabled f
1 - 100 of 114 matches
Mail list logo
