From: Sonika Jindal
Signed-off-by: Sonika Jindal
---
tests/kms_rotation_crc.c | 80 ++
1 file changed, 59 insertions(+), 21 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 9f272fa..6c9674e 100644
--- a/tests/kms_
From: Sonika Jindal
The cursor plane also supports 180 degree rotation. Add a new
"cursor-rotation" property on the crtc which controls this.
Unlike sprites, the cursor has a fixed size, so if you have a small
cursor image with the rest of the bo filled by transparent pixels,
simply flipping the
From: Sonika Jindal
This allows the cursor plane to be updated the same way as primary and sprites,
and same set_property handler is used for all of these planes.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_display.c | 27 +++
1 file changed, 27 insert
On Fri, 12 Sep 2014, Ville Syrjälä wrote:
> On Fri, Sep 12, 2014 at 04:42:33PM +0100, Chris Wilson wrote:
>> On Fri, Sep 12, 2014 at 05:01:57PM +0300, ville.syrj...@linux.intel.com
>> wrote:
>> > From: Ville Syrjälä
>> >
>> > Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
>>
From: Ville Syrjälä
The cursor plane also supports 180 degree rotation. Add a new
"cursor-rotation" property on the crtc which controls this.
Unlike sprites, the cursor has a fixed size, so if you have a small
cursor image with the rest of the bo filled by transparent pixels,
simply flipping the
Please look into this first:
https://bugs.freedesktop.org/show_bug.cgi?id=83130
BR,
Jani.
On Mon, 15 Sep 2014, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> This allows the cursor plane to be updated the same way as primary and
> sprites,
> and same set_property handler is used for
On Sat, Sep 13, 2014 at 07:45:01PM +0200, Sedat Dilek wrote:
> With LLVM v3.4.2 I got this error reported:
> ...
> intel_driver.c:1182:2: error: implicit declaration of function
> 'intel_sync_close' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
> intel_sync_close(screen);
>
On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote:
> The current drm-next misses Ville's original Patch 14/19, the one i first
> objected, then objected to my objection. It is needed to avoid actual
> regressions. Attached a trivially rebased (v2) of Ville's patch to go on top
> of drm-
Hi Dave,
Here's the updated topic/core-stuff pull request with the two patches
already merged into drm-fixes dropped.
Cheers, Daniel
The following changes since commit edbaae5a5cab89de0e64b8c03ebd9a8d5d266550:
Merge tag 'topic/vblank-rework-2014-09-12' of
git://anongit.freedesktop.org/drm-i
On Fri, Sep 12, 2014 at 07:49:25PM -0400, Rodrigo Vivi wrote:
> In some cases like when PSR just got enabled the panel need more vblank
> times to calculate CRC. I figured that out with the new PSR test cases
> facing some cases that I had a green screen but a blank CRC. Even with
> 2 vblank waits
On Fri, Sep 12, 2014 at 05:29:44PM -0700, Rodrigo Vivi wrote:
> Please ignore this full series here.
>
> I have a better one that let PSR on HSW in a better stage with only 1 idle
> frame and without changing the 100ms. Actually if we are brave we can
> reduce this to 24 or less. The new work is c
On Sat, Sep 13, 2014 at 05:17:29PM +0100, Chris Wilson wrote:
> On Fri, Sep 12, 2014 at 08:53:33PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > It seems cleaner if we keep CURCNTR at 0 when the cursor is disabled,
> > so don't set the CURSOR_PIPE_CSC_ENABLE bit unle
On Fri, Sep 12, 2014 at 09:38:13PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Allow tests to specify the plane size instead of assuming that the
> entire FB will be scanned out.
>
> To keep the current tests working without having to sprinkle
> igt_plane_set_size() cal
On Fri, 12 Sep 2014, Chris Clayton wrote:
> On 09/12/14 13:46, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> The limited color range knob is in the port registers on
>> g4x and vlv/chv for HDMI, and on g4x for DP. Add the relevant code
>> to read out the hardware state into p
From: Ben Widawsky
The simple explanation is, the docs say to do this for GEN8. Perhaps we
want to do this for GEN7 too, I am not certain.
PDPs are saved and restored with context. Contexts (without execlists)
only exist on the render ring. The docs say that PDPs are not power
context save/resto
Yet another place that wasn't properly transformed when implementing
SOix. While at it convert the checks to WARN_ON on gen5+ (since we
don't have UMS potentially doing stupid things on those platforms).
And also add the corresponding checks to the put functions (again with
a WARN_ON) for gen5+.
C
In our suspend/resume and driver load code we enable power wells and
interrupts in different order than with runtime pm, which means code
needs to check for that and act accordingly. Unfortunately with the
SOiX support the "are interrupts enabled" checks went out of sync.
Fix up more places. This
On Mon, Sep 15, 2014 at 10:29:47AM +0100, Michel Thierry wrote:
> From: Ben Widawsky
>
> The simple explanation is, the docs say to do this for GEN8. Perhaps we
> want to do this for GEN7 too, I am not certain.
>
> PDPs are saved and restored with context. Contexts (without execlists)
> only exi
On Mon, Sep 15, 2014 at 11:41:19AM +0200, Daniel Vetter wrote:
> Yet another place that wasn't properly transformed when implementing
> SOix. While at it convert the checks to WARN_ON on gen5+ (since we
> don't have UMS potentially doing stupid things on those platforms).
> And also add the corresp
On Mon, Sep 15, 2014 at 11:48 AM, Chris Wilson wrote:
> intel_engine_cs *ring)
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> unsigned long flags;
>>
>> + WARN_ON(!intel_irqs_enabled(dev_priv));
>
> Please no. This would be a BUG().
No BUG if not doing it means the dr
On Mon, Sep 08, 2014 at 03:21:09PM +0300, Imre Deak wrote:
> We want to enable/disable display IRQs only if global i915 IRQs are
> enabled. To check the latter it's not enough to consult the DRM
> dev->irq_enabled flag, since runtime PM can disable/enable IRQs
> and it won't adjust this flag only t
On Mon, Sep 15, 2014 at 11:51:42AM +0200, Daniel Vetter wrote:
> On Mon, Sep 15, 2014 at 11:48 AM, Chris Wilson
> wrote:
> > intel_engine_cs *ring)
> >> struct drm_i915_private *dev_priv = dev->dev_private;
> >> unsigned long flags;
> >>
> >> + WARN_ON(!intel_irqs_enabled(dev_priv
On Sat, 13 Sep 2014, Rodrigo Vivi wrote:
> In some cases like when PSR just got enabled the panel need more vblank
> times to calculate CRC. I figured that out with the new PSR test cases
> facing some cases that I had a green screen but a blank CRC. Even with
> 2 vblank waits on kernel + 2 vblank
On Mon, Sep 15, 2014 at 11:56 AM, Chris Wilson wrote:
> On Mon, Sep 15, 2014 at 11:51:42AM +0200, Daniel Vetter wrote:
>> On Mon, Sep 15, 2014 at 11:48 AM, Chris Wilson
>> wrote:
>> > intel_engine_cs *ring)
>> >> struct drm_i915_private *dev_priv = dev->dev_private;
>> >> unsigned lo
On Mon, Sep 15, 2014 at 12:08:39PM +0200, Daniel Vetter wrote:
> On Mon, Sep 15, 2014 at 11:56 AM, Chris Wilson
> wrote:
> > On Mon, Sep 15, 2014 at 11:51:42AM +0200, Daniel Vetter wrote:
> >> On Mon, Sep 15, 2014 at 11:48 AM, Chris Wilson
> >> wrote:
> >> > intel_engine_cs *ring)
> >> >>
Ok, let me check this.
Regards,
Sonika
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Monday, September 15, 2014 1:26 PM
To: Jindal, Sonika; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Update plane parameters for
cursor
On Mon, Sep 15, 2014 at 9:58 AM, Chris Wilson wrote:
> On Sat, Sep 13, 2014 at 07:45:01PM +0200, Sedat Dilek wrote:
>> With LLVM v3.4.2 I got this error reported:
>> ...
>> intel_driver.c:1182:2: error: implicit declaration of function
>> 'intel_sync_close' is invalid in C99
>> [-Werror,-Wimplic
This replicates what we've done in i915 in
commit 31e4b89acbd7b19c9a8557e6e660a583a0b97daa
Author: Damien Lespiau
Date: Mon Aug 18 13:51:00 2014 +0100
drm/i915: Print the pipe on which the vblank wait times out
to make sure that when we switch i915 to drm_wait_one_vblank that the
debug ou
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
fragmentation of pinned buffers inside the aperture, a question only the
kernel can easily
Yet another place that wasn't properly transformed when implementing
SOix. While at it convert the checks to WARN_ON on gen5+ (since we
don't have UMS potentially doing stupid things on those platforms).
And also add the corresponding checks to the put functions (again with
a WARN_ON) for gen5+.
v
On Mon, Sep 15, 2014 at 02:05:56PM +0200, Daniel Vetter wrote:
> This replicates what we've done in i915 in
>
> commit 31e4b89acbd7b19c9a8557e6e660a583a0b97daa
> Author: Damien Lespiau
> Date: Mon Aug 18 13:51:00 2014 +0100
>
> drm/i915: Print the pipe on which the vblank wait times out
>
On Mon, Sep 15, 2014 at 02:52:03PM +0200, Daniel Vetter wrote:
> Yet another place that wasn't properly transformed when implementing
> SOix. While at it convert the checks to WARN_ON on gen5+ (since we
> don't have UMS potentially doing stupid things on those platforms).
> And also add the corresp
On Sat, Sep 13, 2014 at 05:23:23PM +0100, Chris Wilson wrote:
> On Fri, Sep 12, 2014 at 08:53:35PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
> > height down to 8 lines from the otherwise squ
On Sat, Sep 13, 2014 at 05:20:10PM +0100, Chris Wilson wrote:
> On Fri, Sep 12, 2014 at 08:53:34PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Only write CURBASE when something about the cursor changed. Also
> > eliminate the unnecessary posting read after writing
On Mon, Sep 15, 2014 at 04:36:38PM +0300, Ville Syrjälä wrote:
> On Sat, Sep 13, 2014 at 05:20:10PM +0100, Chris Wilson wrote:
> > On Fri, Sep 12, 2014 at 08:53:34PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Only write CURBASE when something about the
This does not seem to make a difference for the structs in question, but
document the intent.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/int
This does not seem to make a difference for the structs in question, but
document the intent.
v2: also pack union child_device_config (Daniel)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/
Hi Dave,
So final feature pull request for 3.18. QA isn't really done yet with the
manul testing, but this help up a week of soaking so should be fairly
ok-ish. And I think holding up merging doesn't really help anyone,
especially since I want to rebase my 3.19 queue on top of drm-next with
all th
On Mon, Sep 15, 2014 at 04:59:28PM +0300, Jani Nikula wrote:
> This does not seem to make a difference for the structs in question, but
> document the intent.
>
> v2: also pack union child_device_config (Daniel)
>
> Signed-off-by: Jani Nikula
Queued for -next, thanks for the patch.
-Daniel
> --
On Mon, Sep 15, 2014 at 01:33:44PM +0100, Chris Wilson wrote:
> When constructing a batchbuffer, it is sometimes crucial to know the
> largest hole into which we can fit a fenceable buffer (for example when
> handling very large objects on gen2 and gen3). This depends on the
> fragmentation of pinn
All the interrupt setup/teardown hooks are always run from plain
process context. So again just the _irq variant is good enough.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 42 ++---
1 file changed, 18 insertions(+), 24 deletions(-)
dif
Work functions are in process context, so plain _irq spinlock variants
is all we need.
The hpd reenable work didn't follow the _work/_work_func postfix
naming scheme, so adjust that while at it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 28
Now we tackle the functions also called from interrupt handlers.
- intel_check_page_flip is exclusively called from irq handlers, so a
plain spin_lock is all we need. In i915_irq.c we have the convention
to give all such functions an _irq_handler postfix, but that would
look strange and als
Hi all,
So I've tried to figure out a way how to clear up our irq setup mess, but
instead only managed to get sidetracked on a spinlock usage review.
Review highly welcome.
Cheers, Daniel
Daniel Vetter (11):
drm/i915: Clarify event_lock locking, process context
drm/i915: Clarify event_lock
irq handlers always run with interrupts locally disabled, so
plain spinlocks is all we need. I've also reviewed again that they
all follow the _irq_handler postfix convention.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 15 ++-
1 file changed, 6 insertions(+),
Grab bag for all the special cases:
- i9xx_check_fifo_underruns is only called from crtc_enable hooks,
i.e. process context.
- i915_enable_asle_pipestat is only called from interrupt postinstall
hooks. So again process context.
- gen8_irq_power_well_post_enable is called from the runtime pm cod
Only one place looked in need of a bit of polish: hsw_restore_lcpll.
It's used by the runtime pm code and hence is always called from
process context. No irq flag saving required.
Another thing I've stumbled over is that we might need to add a
raw forcewake_get/put helpers which don't grab a runti
It's good practice to use the more specific versions for irq save
spinlocks both as executable documentation and to enforce saner
design. The _irqsave version really should only be used if the calling
context is unknown and there's a good reason to call a function from
all kinds of places.
This is
i915_capture_error_state can be called from all kinds of contexts, so
needs the full irqsave dance. But the other two places to grab and
release the error state are only called from process context. So
simplify them to the plaine _irq spinlock versions to clarify the
locking semantics.
Cc: Mika Ku
The ->queue_flip callback is always called from process context, so
plain _irq spinlock variants are enough.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/driv
->detect callbacks are only ever called from process context, and
there's no fancy nesting going on here. So plain _irq spinlock
variants is what we want.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a
Originally the irq safe spinlock was required because of asle
interrupts. But since
commit 7bd688cd66db93f6430f6e2b3145ee5686daa315
Author: Jani Nikula
Date: Fri Nov 8 16:48:56 2013 +0200
drm/i915: handle backlight through chip specific functions
there's no need for this any more. So swit
This will hopefully make it easier to navigate the code without the need
to consult the full PM documentation.
v2:
- add a comment that the freeze handler is also called after rebooting
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 16
1 file changed, 16 insert
Checking for GT faults is not specific in any way to S4 thaw, so do it
also during S3 resume, S4 restore and driver load time. This allows us to
unify the Sx handlers in an upcoming patch.
v2:
- move the check to intel_uncore_early_sanitize(), so we check at driver
load time too (Chris)
Signed-
On Mon, Sep 15, 2014 at 04:52:27PM +0300, Konstantin Belousov wrote:
> So what will happen when old usermode program (with short old structure)
> calls the ioctl ? I believe the memory which happens to be located
> after the structure is corrupted, or am I missing some magic there ?
>
> I.e., the
Hi Brad,
Thanks for the comments. I'll have to find Damien's SKL patches. I know he's
been on vacation and I haven't looked for them. Mika Kuoppala is submitting
the IGT patches for null_state_gen. They are related to mine, in a sense,
since they generate the intel_renderstate_genx.c files.
On Mon, Sep 15, 2014 at 06:21:56PM +0300, Imre Deak wrote:
> Checking for GT faults is not specific in any way to S4 thaw, so do it
> also during S3 resume, S4 restore and driver load time. This allows us to
> unify the Sx handlers in an upcoming patch.
>
> v2:
> - move the check to intel_uncore_e
>From DPM documentation, thaw_early should undo actions by freeze_late.
Can we move following snippet from thaw_early to thaw to comply with
this?
intel_uncore_early_sanitize(dev, true);
intel_uncore_sanitize(dev);
intel_power_domains_init_hw(dev_priv);
On Wed, 2014-09-10
The point of doing these in thaw_early is to work around an ordering
issue wrt. to the hda driver, see the comment in i915_resume_early(). I
don't see a problem of having them in thaw_early; if you meant that they
lack the corresponding cleanup calls in freeze_late, it's just because
they don't hav
In some cases like when PSR just got enabled the panel need more vblank
times to calculate CRC. I figured that out with the new PSR test cases
facing some cases that I had a green screen but a blank CRC. Even with
2 vblank waits on kernel + 2 vblank waits on test case.
So let's give up to 6 vblank
If something while getting panel CRC this means that probably hw I/O error
so hw is busted and try again shouldn't help much.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
61 matches
Mail list logo
