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 Mesa merge window is closing soon, I'm finally getting bac
Early platforms use the same PCH as HSW, and to avoid triggering the
!ULT, and !HSW warnings, simply put it first in the search.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
From: Daniel Vetter
Gives us hotplug, gmbus, dp aux and south errors (underrun
reporting!).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
i
From: Daniel Vetter
HW engineers have listened and given us again a real interrupt with
masking and status regs. Yay!
For consistency with other platforms call the #define FIFO_UNDERRUN.
Eventually we also might need to have some enable/disable functions
for bdw display interrupts, but for now o
On Thu, Nov 07, 2013 at 10:58:24AM -0800, Ben Widawsky wrote:
> On Thu, Nov 07, 2013 at 07:54:59PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 7, 2013 at 7:46 PM, Ben Widawsky wrote:
> > > On Thu, Nov 07, 2013 at 07:36:50PM +0100, Daniel Vetter wrote:
> > >> On Thu, Nov 7, 2013 at 7:11 PM, Ben Wid
Note that with this patch I see this on boot when the preallocated
objects are scanned:
[3.951078] WARNING: CPU: 1 PID: 398 at lib/list_debug.c:36 __list_add+0x8a/0
xc0()
[3.951081] list_add double add: new=88003fa42ba8, prev=88003f9903c0,
next=88003fa42ba8.
[3.951083] Mod
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fi
On Thu, Nov 07, 2013 at 10:56:52AM -0800, Jesse Barnes wrote:
> On Thu, 7 Nov 2013 19:57:49 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Make the cur_delay limiting code a bit less prone to typo errors
> > by using clamp_t().
> >
> > Signed-off-by: Ville Syrjä
On Thu, Nov 07, 2013 at 07:54:59PM +0100, Daniel Vetter wrote:
> On Thu, Nov 7, 2013 at 7:46 PM, Ben Widawsky wrote:
> > On Thu, Nov 07, 2013 at 07:36:50PM +0100, Daniel Vetter wrote:
> >> On Thu, Nov 7, 2013 at 7:11 PM, Ben Widawsky wrote:
> >> >> > @@ -63,7 +65,7 @@ static void exec(int fd, uin
On Thu, 7 Nov 2013 19:57:49 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make the cur_delay limiting code a bit less prone to typo errors
> by using clamp_t().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 ++
> 1 file changed, 2 ins
On Thu, 7 Nov 2013 19:57:48 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Polling to make sure the current GPU frequency matches the last
> requested frequency should not be necessay, and if there's some
> throttling involved, the two might not match anyway.
>
> Since we
On Thu, Nov 7, 2013 at 7:46 PM, Ben Widawsky wrote:
> On Thu, Nov 07, 2013 at 07:36:50PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 7, 2013 at 7:11 PM, Ben Widawsky wrote:
>> >> > @@ -63,7 +65,7 @@ static void exec(int fd, uint32_t handle, uint32_t
>> >> > offset)
>> >> > gem_exec[0].relocs_
On Thu, Nov 07, 2013 at 07:36:50PM +0100, Daniel Vetter wrote:
> On Thu, Nov 7, 2013 at 7:11 PM, Ben Widawsky wrote:
> >> > @@ -63,7 +65,7 @@ static void exec(int fd, uint32_t handle, uint32_t
> >> > offset)
> >> > gem_exec[0].relocs_ptr = (uintptr_t) gem_reloc;
> >> > gem_exec[0].alignme
On Thu, Nov 7, 2013 at 7:11 PM, Ben Widawsky wrote:
>> > @@ -63,7 +65,7 @@ static void exec(int fd, uint32_t handle, uint32_t
>> > offset)
>> > gem_exec[0].relocs_ptr = (uintptr_t) gem_reloc;
>> > gem_exec[0].alignment = 0;
>> > gem_exec[0].offset = 0;
>> > - gem_exec[0].flags = 0;
On Thu, 2013-11-07 at 13:36 +0200, Imre Deak wrote:
> On Thu, 2013-11-07 at 11:38 +0200, Imre Deak wrote:
> > On Wed, 2013-11-06 at 18:32 -0200, Paulo Zanoni wrote:
> > > 2013/10/28 Imre Deak :
> > > > On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
> > > >> From: Paulo Zanoni
> > > >>
> >
On Thu, Nov 07, 2013 at 07:43:48PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 06, 2013 at 01:56:26PM -0200, Rodrigo Vivi wrote:
> > From: Chris Wilson
> >
> > The RPS register writing routines use the current value of min/max to
> > set certain limits and interrupt gating. If we set those afterwar
On Thu, Nov 07, 2013 at 09:33:06AM +0100, Daniel Vetter wrote:
> On Wed, Nov 06, 2013 at 08:05:02PM -0800, Ben Widawsky wrote:
> > This test assumes that using gem_pin will pin in the same address space
> > used by execbuf. Since pin is for the global GTT only, use the existing
> > flag to notify i
From: Ville Syrjälä
Make the cur_delay limiting code a bit less prone to typo errors
by using clamp_t().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/
From: Ville Syrjälä
Polling to make sure the current GPU frequency matches the last
requested frequency should not be necessay, and if there's some
throttling involved, the two might not match anyway.
Since we're still seeing this trigger occasionally, and it just
introduces a rather pointless 1
On Wed, Nov 06, 2013 at 01:56:26PM -0200, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> The RPS register writing routines use the current value of min/max to
> set certain limits and interrupt gating. If we set those afterwards, we
> risk setting up the hw incorrectly and losing power management e
On Thu, Nov 07, 2013 at 07:25:59PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Broadwell should also use hsw_crt_get_config(). Just move the
> function pointer assignment to the if HAS_DDI block we already
> have there.
>
> Signed-off-by: Ville Syrjälä
lgtm, merged to
From: Ville Syrjälä
Broadwell should also use hsw_crt_get_config(). Just move the
function pointer assignment to the if HAS_DDI block we already
have there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff
On Thu, Nov 07, 2013 at 08:54:00AM -0800, Jesse Barnes wrote:
> On Thu, 7 Nov 2013 15:23:27 +0800
> Chon Ming Lee wrote:
>
> > The max frequency reporting is not correct. But there is already an
> > existing
> > valleyview_rps_max_freq and valleyview_rps_min_freq to get the
> > frequency. Use
On Thu, 7 Nov 2013 15:23:27 +0800
Chon Ming Lee wrote:
> The max frequency reporting is not correct. But there is already an existing
> valleyview_rps_max_freq and valleyview_rps_min_freq to get the
> frequency. Use that for i915_cur_delayinfo.
>
> Signed-off-by: Chon Ming Lee
> ---
> drive
On Thu, 7 Nov 2013 16:01:50 +0200
Ville Syrjälä wrote:
> On Thu, Nov 07, 2013 at 09:49:55PM +0800, Lee, Chon Ming wrote:
> > On 11/07 14:46, Ville Syrjälä wrote:
> > > On Thu, Nov 07, 2013 at 03:23:26PM +0800, Chon Ming Lee wrote:
> > > > For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS
On Wed, 2013-11-06 at 13:56 -0200, Rodrigo Vivi wrote:
> From: Ville Syrjälä
>
> Use the same wait_for_vblank code for CTG that we use for ILK+.
>
> Also fix the name of the frame counter register while at it.
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Imre D
On Wed, Nov 06, 2013 at 11:25:55AM -0800, Jesse Barnes wrote:
> Retrieve current framebuffer config info from the regs and create an fb
> object for the buffer the BIOS or boot loader left us. This should
> allow for smooth transitions to userspace apps once we finish the
> initial configuration c
On Thu, 7 Nov 2013 14:22:55 +
Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 11:25:55AM -0800, Jesse Barnes wrote:
> > Retrieve current framebuffer config info from the regs and create an fb
> > object for the buffer the BIOS or boot loader left us. This should
> > allow for smooth transition
On Thu, Nov 07, 2013 at 06:16:47PM +0200, Imre Deak wrote:
> On Wed, 2013-11-06 at 13:56 -0200, Rodrigo Vivi wrote:
> > From: Ville Syrjälä
> >
> > When the hardware frame counter reads 0xff and we're already past
> > vblank start, we'd return 0x100 as the vblank counter value. Once
> > w
On Wed, 2013-11-06 at 13:56 -0200, Rodrigo Vivi wrote:
> From: Ville Syrjälä
>
> When the hardware frame counter reads 0xff and we're already past
> vblank start, we'd return 0x100 as the vblank counter value. Once
> we'd cross into the next frame's active portion, the vblank counter
> wo
On Thu, 7 Nov 2013 20:21:19 +0800
"Bityutskiy, Artem" wrote:
> Hi,
>
> Tizen IVI does not boot to UI anymore on ByT-I boards with kernel 3.12,
> just like with 3.12-rc1, rc2, etc. v3.11 works fine.
>
> I tried to enable drm.debugging, but could not figure out what is going
> wrong. I've attache
Cc back the the mailing list.
On 11/07 22:35, Lee, Chon Ming wrote:
> On 11/07 16:21, Ville Syrjälä wrote:
> > On Thu, Nov 07, 2013 at 03:23:27PM +0800, Chon Ming Lee wrote:
> > > The max frequency reporting is not correct. But there is already an
> > > existing
> > > valleyview_rps_max_freq and
On Thu, Nov 07, 2013 at 03:31:52PM +0100, Daniel Vetter wrote:
> Reported-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff
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/gpu/drm/i915/intel_ringb
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 bf71e352fd74..1ce5722c2462 1
On Wed, Nov 06, 2013 at 11:25:55AM -0800, Jesse Barnes wrote:
> Retrieve current framebuffer config info from the regs and create an fb
> object for the buffer the BIOS or boot loader left us. This should
> allow for smooth transitions to userspace apps once we finish the
> initial configuration c
On Thu, Nov 07, 2013 at 03:23:27PM +0800, Chon Ming Lee wrote:
> The max frequency reporting is not correct. But there is already an existing
> valleyview_rps_max_freq and valleyview_rps_min_freq to get the
> frequency. Use that for i915_cur_delayinfo.
>
> Signed-off-by: Chon Ming Lee
> ---
>
On Thu, Nov 07, 2013 at 04:01:50PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 07, 2013 at 09:49:55PM +0800, Lee, Chon Ming wrote:
> > On 11/07 14:46, Ville Syrjälä wrote:
> > > On Thu, Nov 07, 2013 at 03:23:26PM +0800, Chon Ming Lee wrote:
> > > > For DDR data rate reporting by Punit in PUNIT_GPU_FR
On Thu, Nov 07, 2013 at 02:49:24PM +0100, Daniel Vetter wrote:
> - 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 suppor
On Thu, Nov 07, 2013 at 09:49:55PM +0800, Lee, Chon Ming wrote:
> On 11/07 14:46, Ville Syrjälä wrote:
> > On Thu, Nov 07, 2013 at 03:23:26PM +0800, Chon Ming Lee wrote:
> > > For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual
> > > data encoding is 00b=800, 01b=1066, 10b=1333,
On Thu, Nov 07, 2013 at 02:49:55PM +0100, Daniel Vetter wrote:
> 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.
On 11/07 14:46, Ville Syrjälä wrote:
> On Thu, Nov 07, 2013 at 03:23:26PM +0800, Chon Ming Lee wrote:
> > For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual
> > data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333.
> >
> > Some premium VLV sku will get the DDR_DATA_RATE set a
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 the enabling of hotplug
- 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 error bits are about fau
The rest of the patches (2,4,5,7) look fine to me, so:
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Nov 07, 2013 at 11:05:45AM +0100, Daniel Vetter wrote:
> 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.
This looks OK, so:
Reviewed-by: Ville Syrjälä
But
On Thu, Nov 07, 2013 at 11:05:42AM +0100, Daniel Vetter wrote:
> 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.
On Thu, Nov 07, 2013 at 02:05:55PM +0100, Daniel Vetter wrote:
> Cool, thanks for testing. Since I'm paranoid about this I've added an
> assert into the relevant fixture block to make sure the batch would really
> work safe for the condition we're testing. That way we're maximally robust
> against
On Thu, Nov 07, 2013 at 11:05:40AM +0100, Daniel Vetter wrote:
> 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:
On Wed, Nov 06, 2013 at 07:52:23PM +, Barbalho, Rafael wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Wednesday, November 06, 2013 6:52 PM
> > To: Barbalho, Rafael
> > Cc: intel-gfx@lists.freedesktop.o
On Thu, Nov 07, 2013 at 11:56:22AM +, Ramakutty, SandeepX wrote:
> Hi Ville,
>
> Thanks for the feedback.
>
> The BUN indicates this as a workaround for hardware limitation. It specifies
> that if the interrupt is not disabled on a pipe that is disabled, the system
> will not go to C3 state
On Thu, Nov 07, 2013 at 03:23:26PM +0800, Chon Ming Lee wrote:
> For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual
> data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333.
>
> Some premium VLV sku will get the DDR_DATA_RATE set as 11. As a result,
> the turbo frequency repor
On Thu, Nov 07, 2013 at 10:25:44AM +0800, Lee, Chon Ming wrote:
> On 11/06 14:02, Ville Syrjälä wrote:
>
> > > -#define _DPIO_IREF_CTL_A 0x8040
> > > -#define _DPIO_IREF_CTL_B 0x8060
> > > -#define DPIO_IREF_CTL(pipe) _PIPE(pipe, _DPIO_IREF_CTL_A,
> > > _DPIO_IREF_CTL_B)
> > > +#d
On 07/11/2013 13:23, Artem Bityutskiy wrote:
Anyway, I've bisected it, and found out that this commit fixes our
problem:
0b6279520519 drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT
Jesse, Daniel, any idea what is the issue and why this patch fixes it?
The thing is that Tizen IV
Hi Ville,
Thanks for the feedback.
The BUN indicates this as a workaround for hardware limitation. It specifies
that if the interrupt is not disabled on a pipe that is disabled, the system
will not go to C3 state. This affects situations when only edp is connected and
hdmi is not connected. Th
On Thu, 2013-11-07 at 11:38 +0200, Imre Deak wrote:
> On Wed, 2013-11-06 at 18:32 -0200, Paulo Zanoni wrote:
> > 2013/10/28 Imre Deak :
> > > On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
> > >> From: Paulo Zanoni
> > >>
> > >> This patch adds the initial infrastructure to allow a Runtime
HW engineers have listened and given us again a real interrupt with
masking and status regs. Yay!
For consistency with other platforms call the #define FIFO_UNDERRUN.
Eventually we also might need to have some enable/disable functions
for bdw display interrupts, but for now open-coding seems to be
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/i915_irq.c b/drivers/gpu
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 the enabling of hotplug
Gives us hotplug, gmbus, dp aux and south errors (underrun
reporting!).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 686afe0a98f1..510
- 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 error bits are about fau
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 changed, 6 insertions(
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.c | 40 +++
On Wed, 2013-11-06 at 18:32 -0200, Paulo Zanoni wrote:
> 2013/10/28 Imre Deak :
> > On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> This patch adds the initial infrastructure to allow a Runtime PM
> >> implementation that sets the device to its D3 state. Th
Hi Dave,
Bit a bit -fixes pull request in the merge window than usual dua to two
feauture-y things:
- Display CRCs are now enabled on all platforms, including the odd DP case
on gm45/vlv. Since this is a testing-only feature it should ever hurt,
but I figured it'll help with regression-testing
On Wed, Nov 06, 2013 at 11:55:53AM -0800, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
>
> On Wed, 06 Nov 2013 19:12:29 + bugzilla-dae...@bugzilla.kernel.org wrote:
This looks scary. Is this reproducible and
We don't want any ERROR for simulated gpu hangs, otoh printing the
error code when the reset failed for real should be interesting.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71333
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertio
On Wed, Nov 06, 2013 at 01:56:29PM -0200, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> v2: Fixed the botched locking on init_hw failure in i915_reset (Ville)
> Call cleanup_ringbuffer on failed context create in init_hw (Ville)
>
> v3: Add dev argument ti clean_ringbuffer
>
> Reviewed-by: Kenne
On Wed, Nov 06, 2013 at 08:05:02PM -0800, Ben Widawsky wrote:
> This test assumes that using gem_pin will pin in the same address space
> used by execbuf. Since pin is for the global GTT only, use the existing
> flag to notify i915.ko that the exec object is special.
>
> Cc: Chris Wilson
> Signed
On Wed, Nov 06, 2013 at 08:05:02PM -0800, Ben Widawsky wrote:
> This test assumes that using gem_pin will pin in the same address space
> used by execbuf. Since pin is for the global GTT only, use the existing
> flag to notify i915.ko that the exec object is special.
Interesting. Yes, I think you
70 matches
Mail list logo
