This refactor is useful for some future work I'll be doing on the
execbuffer path. In addition to being a pretty easy prerequisite, it
also helped me track down the bug uncovered in the first patch.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 102 ++-
Simple refactor.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 82
1 files changed, 46 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1ee1872
The docs say this is required for Gen7, and since the bit was added for
Gen6, we are also setting it there pit pf paranoia. Particularly as
Chris points out, if PIPE_CONTROL counts as a 3d state packet.
This was found through doc inspection by Ken and applies to Gen6+;
Reported-by: Kenneth Graunk
After my refactoring, Chris noticed that we had a bug.
dev_priv keeps track of the current addressing mode that gets set at
execbuffer time. Unfortunately the existing code was doing this before
acquiring struct_mutex which leaves a race with another thread also
doing an execbuffer. If that wasn't
Here is the patch series with the fixes I mentioned. Still would like to
get some review, etc. before I officially repost the series.
I reordered it so that the actual bug fixes come first, and the
refactors come next. I would really like to get the refactors in though
because a) they helped find
On Wed, 12 Oct 2011 15:03:11 -0700
Jesse Barnes wrote:
> On Fri, 7 Oct 2011 14:38:44 -0400
> Adam Jackson wrote:
>
> > For transcoder A, we would never clear the DPLL[AB] select bit. If the
> > firmware had set us up on DPLLB, the effect would be to attempt to use
> > DPLLB for both pipes A a
On Wed, 2011-10-12 at 14:09 +1100, Bojan Smojver wrote:
> Bug #41705.
Going off list for a while (way too much info I don't need/cannot grok).
If anything new develops, please let me know through the bug. Thanks.
--
Bojan
___
Intel-gfx mailing list
In
On Fri, 7 Oct 2011 14:38:44 -0400
Adam Jackson wrote:
> For transcoder A, we would never clear the DPLL[AB] select bit. If the
> firmware had set us up on DPLLB, the effect would be to attempt to use
> DPLLB for both pipes A and B, which would probably be bad.
>
> Signed-off-by: Adam Jackson
On Wed, 12 Oct 2011 21:00:29 +0100
Chris Wilson wrote:
> On Wed, 12 Oct 2011 13:37:53 -0600, Keith Packard wrote:
> Non-text part: multipart/mixed
> Non-text part: multipart/signed
> > On Wed, 12 Oct 2011 11:12:59 -0700, Jesse Barnes
> > wrote:
> >
> > > +#define CURCNTR_IVB(pipe) _PIPE(pipe,
On Wed, 12 Oct 2011 13:37:53 -0600, Keith Packard wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On Wed, 12 Oct 2011 11:12:59 -0700, Jesse Barnes
> wrote:
>
> > +#define CURCNTR_IVB(pipe) _PIPE(pipe, _CURACNTR, _CURBCNTR_IVB)
> > +#define CURBASE_IVB(pipe) _PIPE(pipe, _
On Wed, 12 Oct 2011 11:12:59 -0700, Jesse Barnes
wrote:
> +#define CURCNTR_IVB(pipe) _PIPE(pipe, _CURACNTR, _CURBCNTR_IVB)
> +#define CURBASE_IVB(pipe) _PIPE(pipe, _CURABASE, _CURBBASE_IVB)
> +#define CURPOS_IVB(pipe) _PIPE(pipe, _CURAPOS, _CURBPOS_IVB)
Only two cursors?
--
keith.pack...@inte
On Wed, 2011-10-12 at 11:12 -0700, Jesse Barnes wrote:
> The cursor regs have moved around, add the offsets and new macros for
> getting at them.
>
> Signed-off-by: Jesse Barnes
Tested-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally signed message part
The cursor regs have moved around, add the offsets and new macros for
getting at them.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |8 ++
drivers/gpu/drm/i915/intel_display.c | 40 +
2 files changed, 43 insertions(+), 5 deletions
We can have more than just A and B these days.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 347a949..0e556e7 100644
Add a couple of checks now that we're using the 3rd transcoder:
1) make sure the transcoder PLL enable bit is set for the transcoder
in question
2) when checking actual PLL enable, use the selected PLL number rather
than the transcoder number (they could be different now)
Signed-off-
Add two new fields to the intel_crtc struct for 3 pipe support: no_pll
and use_pll_a. The no_pll field is only set on the 3rd pipe to indicate
that it doesn't have a PLL of its own and so shouldn't try to write the
main PLL regs. The use_pll_a field controls which PLL pipe 3 will
share, A or B.
On IVB with CPT or PPT PCH chips, FDI sync can be done with one or two wires
depending on the board configuration. For 3 pipe configurations, since
FDI B and C share lanes, composite sync must be used. The board design
specs require that composite sync always work in general too, so just
use it b
Required for 3 pipe functionality.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_crt.c | 18 +++---
drivers/gpu/drm/i915/intel_hdmi.c | 10 --
2 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm
Just a cleanup to make the mode_set function more manageable.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 45 ++---
1 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i9
Well almost anyway. IVB has 3 planes, pipes, transcoders, and FDI
interfaces, but only 2 pipe PLLs. So two of the pipes must use the same
pipe timings (e.g. 2 DP plus one other, or two HDMI with the same mode
and one other, etc.).
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c
Add a macro for accessing the two pipe PLLs and add a check to make sure
we don't access a non-existent one in the enable/disable functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |6 +++---
drivers/gpu/drm/i915/intel_display.c |6 ++
2 files changed, 9
Here's an updated set of 3 pipe patches that seem to work pretty well.
Additional testing & review appreciated. I think they're ready to merge
now but may not be bug free.
Thanks,
Jesse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://
On Tue, 11 Oct 2011 21:43:48 -0700
Ben Widawsky wrote:
> Some refactors, a bug fixes (found through refactoring), as well as
> setting a bit because the docs says so. That bit is hanging Daniel's
> machine, so we may want to hold off on the last patch for now.
>
> This patch series is in prepara
On Tue, 11 Oct 2011 21:43:50 -0700
Ben Widawsky wrote:
> Simple refactor.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 78
> +---
> 1 files changed, 47 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_
On Wed, 12 Oct 2011 15:41:11 +0100, Dave Airlie wrote:
> > Using the same basic plan as the VDD force delayed power off, make
> > turning the panel power off asynchronous.
>
> NAK, tested on my 2540p, up to this patch in macbook-air branch stuff
> worked, after this I just get black screen on re
> Using the same basic plan as the VDD force delayed power off, make
> turning the panel power off asynchronous.
NAK, tested on my 2540p, up to this patch in macbook-air branch stuff
worked, after this I just get black screen on resume.
Dave.
___
Intel-
Chris,
On Tue, Oct 11, 2011 at 09:01:20PM +0100, Chris Wilson wrote:
> If you are using SNA, the likely cause of the flash is the flush, read,
> modify, write of a fallback. That is we flush pending operations in the
> batchbuffer (likely a fill to the scanout), read back from the scanout
> the ju
On Tue, Oct 11, 2011 at 09:43:53PM -0700, Ben Widawsky wrote:
> The docs say this is required for Gen7, and since the bit was added for
> Gen6, we are also setting it there pit pf paranoia. Particularly as
> Chris points out, if PIPE_CONTROL counts as a 3d state packet.
>
> This was found through
On Oct 11, 2011, at 9:43 PM, Ben Widawsky wrote:
> The docs say this is required for Gen7, and since the bit was added for
> Gen6, we are also setting it there pit pf paranoia. Particularly as
> Chris points out, if PIPE_CONTROL counts as a 3d state packet.
>
> This was found through doc inspec
29 matches
Mail list logo
