The pipe B and pipe C interrupt mask and enable registers are now part
of the pipe, so disabling the pipe power wells will lost the contests of
the registers.
Art totally debugged this one!
Cc: Art Runyan
Cc: Paulo Zanoni
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++
On 11/07/2013 10:32 PM, Daniel Vetter wrote:
> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
>>> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick wrote:
On 10/27/2013 05:30 AM, Daniel Vetter wrote:
> On Fri, Oct 25, 2013 at 06:
On 11/08/2013 11:00 AM, Dave Airlie wrote:
> On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick wrote:
>> On 11/07/2013 10:32 PM, Daniel Vetter wrote:
>>> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
> On Tue, Oct 29, 2013 at 11:29 P
On Tue, Nov 05, 2013 at 02:00:08PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We only depend on the intel-gtt module for GTT frobbign on older gens.
> The intel_agp module is optional, except for UMS and some old XvMC
> userland on gen3. So make AGP support optional. As
$DRI_CFLAGS does not actually exist. The PKG_CHECK_MODULES call creates
a $DRI1_CFLAGS variable instead. This doesn't break often because
"recent" versions of xorg-server.pc indirectly depend on xf86driproto.pc
thus bringing in the required CFLAGS through $XORG_CFLAGS.
Bugzilla: https://bugs.gento
On Fri, Nov 8, 2013 at 7:19 PM, Paulo Zanoni wrote:
>> I think we discussed this in some meeting, and
>> GTT maps were the only thing that came to my mind. But IIRC you
>> said that you weren't actually sure whether GTT maps still work in
>> PC8. Has that been verified or is it still an open quest
Hi Daniel, dear intel-experts,
please find a revised patch attached that addresses the flicker with
panning on the i830 chipset. This patch has now been tested
on various screen layouts and seems to be quite reliable, i.e. I haven't
seen the flicker since.
Unfortunately, I have not been able
We now have the max backlight value cached. Use it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 45 +++-
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_pane
The backlight code has grown rather hairy, not least because the
hardware registers and bits have repeatedly been shuffled around. And
this isn't expected to get any easier with new hardware. Make things
easier for our (read: my) poor brains, and split the code up into chip
specific functions.
The
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index a821949..e82b2dd 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/
No longer needed. We now have fully cached max backlight values.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h|1 -
drivers/gpu/drm/i915/intel_panel.c | 133
2 files changed, 134 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_d
The backlight enable code now has the smarts to do the right thing.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |6 -
drivers/gpu/drm/i915/i915_suspend.c | 45 ---
2 files changed, 51 deletions(-)
diff --git a/drivers/gpu/drm/i915
Hi all -
This series is a successor to [1], but with too many changes to list so
I'll just consider this v1 of the patches.
This is pretty much a rewrite of our backlight code. Highlights:
* All the platform specific stuff in platform specific functions. The
code is much easier to follow, and
On Wed, Oct 30, 2013 at 03:44:16PM +0200, Mika Kuoppala wrote:
> This ioctl returns reset stats for specified context.
>
> The struct returned contains context loss counters.
>
> reset_count:all resets across all contexts
> batch_active: active batches lost on resets
> batch_pending: pendi
On Wed, Oct 30, 2013 at 03:44:15PM +0200, Mika Kuoppala wrote:
> reset_counter will be incremented twice per successful
> reset. Odd values mean reset is in progress and even values
> mean that reset has completed.
Could you also update the lengthy comment above reset_counter. It looks
quite stale
Prepare for being able to use the information at enable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_panel.c | 68 +---
2 files changed, 58 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i
On Fri, 8 Nov 2013 16:53:31 +0200
Artem Bityutskiy wrote:
> Thanks Jesse for you answer, but it brought more questions.
>
> On Thu, 2013-11-07 at 08:04 -0800, Jesse Barnes wrote:
> > Hm, I wonder if this bug is also related to the backlight stuff Jani
> > recently pushed fixes for.
>
> OK.
>
>
I've always felt the backlight device conditional build has been all
backwards. Make it feel right.
Gently move things towards connector based stuff while at it.
There should be no functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |9 +++--
drivers/gpu
On Thu, Nov 07, 2013 at 09:40:49PM -0800, Ben Widawsky wrote:
> Sometimes the VBT lies, I guess? I can't explain why this occurs, but it
> does on the early platforms we have.
>
> Since it seems never unsafe to do this, I don't feel we need any quirk
> or warnings.
>
> Cc: Paulo Zanoni
> Signed-
Hi Dave,
So here's the Broadwell pull request. From a kernel driver pov there's
two areas with big changes in Broadwell:
- Completely new enumerated interrupt bits. On the plus side it now looks
fairly unform and sane.
- Completely new pagetable layout.
To ensure minimal impact on existing plat
On Fri, Nov 08, 2013 at 10:10:31AM +0200, Jani Nikula wrote:
> Fix CONFIG_ACPI=n build fail
>
> CC drivers/gpu/drm/i915/intel_opregion.o
> drivers/gpu/drm/i915/intel_opregion.c: In function ‘intel_opregion_setup’:
> drivers/gpu/drm/i915/intel_opregion.c:879:2: error: ‘asle_work’ undeclared
2013/11/4 Ville Syrjälä :
> On Mon, Oct 28, 2013 at 10:20:56AM -0200, Paulo Zanoni wrote:
>> 2013/10/27 Daniel Vetter :
>> > On Fri, Oct 25, 2013 at 11:44:05AM -0200, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> This test is based on pc8.c. It copies most of the tests from pc8.c,
>> >>
From: Paulo Zanoni
All the callers seem to rely on the correct behavior of gem_mmap__cpu,
so add some assertions to catch the unexpected cases. This way we
won't need to worry about adding assertions to all the callers.
Signed-off-by: Paulo Zanoni
---
lib/drmtest.c| 4 ++--
tests/g
On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick wrote:
> On 11/07/2013 10:32 PM, Daniel Vetter wrote:
>> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
>>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick
wrote:
> On 10/27/2013
On Fri, Nov 08, 2013 at 11:25:17AM +0200, Ville Syrjälä wrote:
> On Thu, Nov 07, 2013 at 10:43:30AM +0800, Chon Ming Lee wrote:
> > Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current
> > DPIO register definition doesn't have a structure way to break them
> > down. As a result
From: Paulo Zanoni
That's just misleading.
Signed-off-by: Paulo Zanoni
---
lib/drmtest.c| 2 +-
lib/drmtest.h| 2 +-
tests/gem_cs_tlb.c | 3 +--
tests/gem_evict_everything.c | 3 +--
tests/gem_fence_thrash.c | 2 +-
tests/gem_gtt_speed.c
On Fri, Nov 08, 2013 at 04:25:01PM +0100, Thomas Richter wrote:
> Hi Daniel, dear intel-experts,
>
> please find a revised patch attached that addresses the flicker with
> panning on the i830 chipset. This patch has now been tested
> on various screen layouts and seems to be quite reliable, i.e. I
Thanks Jesse for you answer, but it brought more questions.
On Thu, 2013-11-07 at 08:04 -0800, Jesse Barnes wrote:
> Hm, I wonder if this bug is also related to the backlight stuff Jani
> recently pushed fixes for.
OK.
> It looks like you have an eDP panel here,
No, we do not have it at all.
Move from dev_priv to connector->panel. We still don't allow multiple
sysfs interfaces, though.
There should be no functional changes, except for a slight reordering of
connector backlight and sysfs destroy calls. (This change happens now
that the backlight device is actually per-connector, even t
On Thu, Nov 07, 2013 at 09:40:44PM -0800, Ben Widawsky wrote:
> Many GENs generally perform the same actions just on different
> registers. This is true going forward as well. To ease the transition a
> bit, extract the common code where possible.
>
> Signed-off-by: Ben Widawsky
As explained on
ALthough usually there's only one connector that supports backlight,
this also finds the correct connector. Before, we only updated the
connector on pipe A, which might not be the one with backlight. (This
only made a difference on BYT.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_
It has per pipe registers.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index e82b2dd..5bd64db 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 9a55b36..3dd9f57d 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i91
On Fri, 8 Nov 2013 07:32:05 +0100
Daniel Vetter wrote:
> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
> > On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
> >> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick
> >> wrote:
> >>> On 10/27/2013 05:30 AM, Daniel Vetter wrote:
> On Fr
For what we care about ULT and ULX are interchangeable. We know of 3
types of pciids for these cases. I am not sure if at some point we will
need to distinguish ULT and ULX.
Cc: Paulo Zanoni
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 7 ++-
1 file changed, 6 insertion
We should now have all the information we need to do a full
initialization of the backlight registers.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 145 ++--
1 file changed, 89 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i9
This allows more flexibility in the ordering of the register writes, and
lets us drop level setting altogether as necessary on a per platform
basis.
For gen2-gen3, this is the only thing that happens in enable/disable.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 48 +++
This confused me some many times that I think it is appropriate to add a
small comment to instruct the reader of the code that it is indeed doing
what it is supposed to do.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
From: Daniel Vetter
- Pipe underrun can't just be enabled, we need some support code like
on ilk-hsw to make this happen. So drop it for now.
- CRC error is a special mode of the CRC hardware that we don't use,
so again drop it. Real CRC support for bdw will be added later.
- All the other er
Somehow this got missed or dropped during development. The simulator
does not use forcewake, so it's entirely possible it never worked
correctly. After the mmio rework, this will end up in an OOPs, and the
system will not boot.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_uncore.c
From: Daniel Vetter
The handling of the error interrupts isn't wired up at all. And it
hasn't been ever since ilk happened, so don't bother.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gp
On Thu, Nov 07, 2013 at 03:45:16PM +0200, Ville Syrjälä wrote:
> The rest of the patches (2,4,5,7) look fine to me, so:
>
> Reviewed-by: Ville Syrjälä
Pulled them all into bdw-stage1, thanks for review. I've also pulled in a
few of Ben's fixups already (and squash a few of them). On the other I'
From: Daniel Vetter
Reported-by: Ville Syrjälä
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bf71e3
Sometimes the VBT lies, I guess? I can't explain why this occurs, but it
does on the early platforms we have.
Since it seems never unsafe to do this, I don't feel we need any quirk
or warnings.
Cc: Paulo Zanoni
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 fil
From: Daniel Vetter
Let's cache the IMR value like on other platforms. This is needed to
implement the underrun reporting since then we'll have two places that
change the same register at runtime.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 18 ++
1 file
commit 771bafb1fef22206d96942e41826e317374df51e
Author: Ben Widawsky
Date: Sat Nov 2 21:07:00 2013 -0700
drm/i915/bdw: Handle forcewake for writes on gen8
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_uncore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/d
Prior to Haswell the CPU control register for backlight
(BLC_PWM_CPU_CTL) toggled the PCH baclight pin for us. This made some
sense as there was no pin on the CPU. With Haswell came the introduction
of a CPU backlight pin, but the interface was still controlled by
software with the same mechnism. B
Because of the way in which we're allocating the pages for the Aliasing
PPGTT, we cannot actually successfully alloc enough space for anything
greater than 2GB.
Instead of a quick hack to fix this, we should defer until we have the
real solution in place (allocating much less contiguous space).
T
It serves no real purpose and is displayed (in a non-maskable fashion)
on every object sync.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 925c911..989be12
On Thu, Nov 07, 2013 at 10:43:30AM +0800, Chon Ming Lee wrote:
> Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current
> DPIO register definition doesn't have a structure way to break them
> down. As a result it is not easy to match the PHY/PLL registers with the
> configdb docum
This patch existed before, but was lost over time.
Note that reset is still somewhat problematic in my limited testing (ie.
module_reload will not pass) but it can be disabled with a module
parameter, and support should be considered preliminary anyway.
Signed-off-by: Ben Widawsky
---
drivers/g
On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
>> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick wrote:
>>> On 10/27/2013 05:30 AM, Daniel Vetter wrote:
On Fri, Oct 25, 2013 at 06:42:35PM -0700, Ian Romanick wrote:
> Since the
Many GENs generally perform the same actions just on different
registers. This is true going forward as well. To ease the transition a
bit, extract the common code where possible.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_panel.c | 25 +
1 file changed, 1
From: Daniel Vetter
The layout of the CRC registers is the same as on hsw, only the
interrupt handling has changed a bit. So trivial to wire up, yay!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i9
From: Daniel Vetter
Useful for dp aux to work better. Also stop enabling the port A
hotplug event - eDP panels are expected to fire that interupt and
we're not really ready to deal with them. This is consistent with how
we handle port A on ilk-hsw.
The more important bit is that we must delay th
From: Daniel Vetter
We have a per-pipe bit in the master irq control register, so use it.
This allows us to drop the masks for aggregate interrupt bits and be a
bit more explicit in the code. It also removes one indentation level.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.
For our posting read we were reading only 32b on BDW. There was a FIXME
already - the warning is annoying.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gp
2013/11/8 Ben Widawsky :
> Sometimes the VBT lies, I guess? I can't explain why this occurs, but it
> does on the early platforms we have.
We don't decide to init/not-init VGA based on the VBT. Function
intel_setup_outputs has "if (!IS_ULT(dev)) intel_crtc_init(dev)". As
far as I remember, we're t
I am unclear how this got messed up in the shuffle, but it did.
Cc: Imre Deak
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
in
Fix CONFIG_ACPI=n build fail
CC drivers/gpu/drm/i915/intel_opregion.o
drivers/gpu/drm/i915/intel_opregion.c: In function ‘intel_opregion_setup’:
drivers/gpu/drm/i915/intel_opregion.c:879:2: error: ‘asle_work’ undeclared
(first use in this function)
drivers/gpu/drm/i915/intel_opregion.c:879
60 matches
Mail list logo
