On Wed, Sep 11, 2013 at 11:39:30PM +0100, Chris Wilson wrote:
> On Wed, Sep 11, 2013 at 02:57:54PM -0700, Ben Widawsky wrote:
> > @@ -464,11 +465,12 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> > struct intel_ring_buffer *ring,
> >
On Fri, 13 Sep 2013 17:27:54 -0700
Jesse Barnes wrote:
> This reverts commit 65ce4bf5a15fcd4d15898be47795d0550eb2325c.
Found this was breaking eDP for me with -nightly as of today on Baley
Bay boards.
Chris, can you verify this on your system too? I'm working on getting
a new one with eDP supp
This reverts commit 65ce4bf5a15fcd4d15898be47795d0550eb2325c.
---
drivers/gpu/drm/i915/intel_display.c | 20 +---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drive
We never took the lock ourselves and all callers expect the struct_mutex
to be locked upon return (be it success or error), thereore dropping the
lock along the error paths looks to be a vestigial error from
commit db1b76ca6a79c774074ae87bee7afc0825a478f5
Author: Daniel Vetter
Date: Tue Jul 9 1
2013/9/13 Ville Syrjälä :
> On Fri, Sep 13, 2013 at 05:05:59PM -0300, Paulo Zanoni wrote:
>> Hi
>>
>> 2013/9/12 :
>> > From: Ville Syrjälä
>> >
>> > Add APIs to get/put power well references for specific purposes.
>> >
>> > Also reorganize the internal i915_request power well handling to use the
2013/9/12 Daniel Vetter :
> Sprinkling random special functions all over the place always
> has the risk that we miss it somewhere. Furthermore in this
> case the ordering wrt gem_init_hw was actually different between
> the driver load sequence and the resume sequence.
>
> So just call this at the
On Fri, Sep 13, 2013 at 05:27:59PM -0300, Paulo Zanoni wrote:
> 2013/9/12 :
> > From: Ville Syrjälä
> >
> > VGA registers live inside the power well on HSW, so in order to write
> > the VGA MSR register we need the power well to be on.
> >
> > We really must write to the register to properly clea
On Fri, Sep 13, 2013 at 05:05:59PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/9/12 :
> > From: Ville Syrjälä
> >
> > Add APIs to get/put power well references for specific purposes.
> >
> > Also reorganize the internal i915_request power well handling to use the
> > reference count just like every
2013/9/12 :
> From: Ville Syrjälä
>
> We increase/decrease the power well refcount in several places now, and
> all of those places need to do the same thing, so pull that code into
> a few small helper functions.
>
> Signed-off-by: Ville Syrjälä
I don't think we need those "__" in the beginni
Hi
2013/9/12 :
> From: Ville Syrjälä
>
> Add APIs to get/put power well references for specific purposes.
>
> Also reorganize the internal i915_request power well handling to use the
> reference count just like everyone else. This way all we need to do is
> check the reference count and we know
2013/9/12 :
> From: Ville Syrjälä
>
> VGA registers live inside the power well on HSW, so in order to write
> the VGA MSR register we need the power well to be on.
>
> We really must write to the register to properly clear the
> VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when
2013/9/12 :
> From: Ville Syrjälä
>
> VGA registers/memory live inside the the display power well. Add a power
> domain for VGA.
>
> Signed-off-by: Ville Syrjälä
(see comments in patch 1/5)
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel
2013/9/12 :
> From: Ville Syrjälä
>
> The init and resume codepaths want to handel the power well in slightly
> different ways, so pull the power well init out from
> intel_modeset_init_hw() which gets called in both cases.
Can you please explain more? Where's the slight difference?
(also, I'm
On Fri, Sep 13, 2013 at 05:19:34PM -0300, Paulo Zanoni wrote:
> 2013/9/12 :
> > From: Ville Syrjälä
> >
> > The init and resume codepaths want to handel the power well in slightly
> > different ways, so pull the power well init out from
> > intel_modeset_init_hw() which gets called in both cases.
On Fri, Sep 13, 2013 at 05:09:09PM -0300, Paulo Zanoni wrote:
> 2013/9/12 :
> > From: Ville Syrjälä
> >
> > We increase/decrease the power well refcount in several places now, and
> > all of those places need to do the same thing, so pull that code into
> > a few small helper functions.
> >
> > S
On Fri, Sep 13, 2013 at 7:43 PM, Hans de Bruin wrote:
> On 09/12/2013 10:49 PM, Daniel Vetter wrote:
>>
>> On Thu, Sep 12, 2013 at 10:45:10PM +0200, Hans de Bruin wrote:
>>>
>>> On 09/10/2013 01:00 PM, Jani Nikula wrote:
Hi Hans -
On Sat, 07 Sep 2013, Hans de Bruin wrote:
On 09/12/2013 10:49 PM, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 10:45:10PM +0200, Hans de Bruin wrote:
On 09/10/2013 01:00 PM, Jani Nikula wrote:
Hi Hans -
On Sat, 07 Sep 2013, Hans de Bruin wrote:
Since a day or two the screen of my laptop goes blank when the kernel
switches resolutio
On Thu, Sep 12, 2013 at 10:28:32PM -0700, Ben Widawsky wrote:
> Using LRI for setting the remapping registers allows us to stream l3
> remapping information. This is necessary to handle per context remaps as
> we'll see implemented in an upcoming patch.
>
> Using the ring also means we don't need
On Fri, Sep 13, 2013 at 5:54 PM, Ben Widawsky wrote:
> On Fri, Sep 13, 2013 at 11:12:11AM +0200, Daniel Vetter wrote:
>> On Thu, Sep 12, 2013 at 10:28:41PM -0700, Ben Widawsky wrote:
>> > Haswell added the ability to inject errors which is extremely useful for
>> > testing. Add two arguments to th
On Fri, Sep 13, 2013 at 06:14:38PM +0200, Daniel Vetter wrote:
> On Fri, Sep 13, 2013 at 5:54 PM, Ben Widawsky wrote:
> > On Fri, Sep 13, 2013 at 11:12:11AM +0200, Daniel Vetter wrote:
> >> On Thu, Sep 12, 2013 at 10:28:41PM -0700, Ben Widawsky wrote:
> >> > Haswell added the ability to inject err
On Fri, Sep 13, 2013 at 11:12:11AM +0200, Daniel Vetter wrote:
> On Thu, Sep 12, 2013 at 10:28:41PM -0700, Ben Widawsky wrote:
> > Haswell added the ability to inject errors which is extremely useful for
> > testing. Add two arguments to the tool to inject, and uninject.
> >
> > Signed-off-by: Ben
On Thu, 12 Sep 2013, Daniel Vetter wrote:
> On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra wrote:
> > If 'sane' userspace is never supposed to do this, then only insane
> > userspace is going to hurt from this and that's a GOOD (tm) thing,
> > right? ;-)
>
> Afaik sane userspace doesn't hit the
On Thu, 12 Sep 2013, Daniel Vetter wrote:
> On Thu, Sep 12, 2013 at 9:58 PM, Thomas Gleixner wrote:
> >
> >> On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra
> >> wrote:
> >> > If 'sane' userspace is never supposed to do this, then only insane
> >> > userspace is going to hurt from this and that
On Thu, 12 Sep 2013, Daniel Vetter wrote:
> On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner wrote:
> >> I think for ttm drivers it's just execbuf being exploitable. But on
> >> drm/i915 we've
> >> had the same issue with the pwrite/pread ioctls, so a simple
> >> glBufferData(glMap) kind of recu
On Thu, 12 Sep 2013, Peter Zijlstra wrote:
> On Thu, Sep 12, 2013 at 05:35:43PM +0100, Chris Wilson wrote:
> > Not quite, as it would be possible for the evil userspace to trigger a
> > GPU hang that would cause the sane userspace to spin indefinitely
> > waiting for the error recovery to kick in
On Fri, Sep 13, 2013 at 04:07:19PM +0200, Daniel Vetter wrote:
> On Fri, Sep 13, 2013 at 04:38:28PM +0300, Jani Nikula wrote:
> > On Fri, 13 Sep 2013, Daniel Vetter wrote:
> > > On Fri, Sep 13, 2013 at 11:03:09AM +0300, Jani Nikula wrote:
> > >> Flat out skip anything to do with PLL if we have a D
On Fri, Sep 13, 2013 at 07:05:31PM +0530, Sandeep Ramankutty wrote:
> Change: Add support to change the pixel format, base surface address, tiling
> mode, tiling
> offset on the flow during the primary plane flip.
Tell us why first. Why this patch is necesary is the fundamental reason
that we nee
On Fri, Sep 13, 2013 at 04:56:04PM +0300, Eero Tamminen wrote:
> Hi,
>
> Attached patch fixes typo in intel_lid.man.
Thanks for the diff, pushed. Next time don't hesitate to use git
format-patch, that's really the preferred way to send patches and makes
it easy to preserver the author and the com
On Fri, Sep 13, 2013 at 07:05:31PM +0530, Sandeep Ramankutty wrote:
> Change: Add support to change the pixel format, base surface address, tiling
> mode, tiling
> offset on the flow during the primary plane flip.
>
> Issue: This support is needed by hardware composer to meet the performance
> op
On Fri, Sep 13, 2013 at 04:38:28PM +0300, Jani Nikula wrote:
> On Fri, 13 Sep 2013, Daniel Vetter wrote:
> > On Fri, Sep 13, 2013 at 11:03:09AM +0300, Jani Nikula wrote:
> >> Flat out skip anything to do with PLL if we have a DSI encoder (and thus
> >> DSI PLL). Also skip PLL computation if the en
Hi,
Attached patch fixes typo in intel_lid.man.
- Eero
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may cont
On Fri, Sep 13, 2013 at 04:47:53PM +0300, Jani Nikula wrote:
> On Fri, 13 Sep 2013, Ville Syrjälä wrote:
> > On Fri, Sep 13, 2013 at 04:04:03PM +0300, Jani Nikula wrote:
> >> On Mon, 09 Sep 2013, ville.syrj...@linux.intel.com wrote:
> >> > From: Ville Syrjälä
> >> >
> >> > Add the 120MHz refernce
I think this is just the right thing to do, so:
Reviewed-by: Rodrigo Vivi
On Thu, Sep 12, 2013 at 1:58 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We don't seem to be using the pointer after it's unmapped, so this
> patch doesn't fix any bug I can reproduce.
>
> Signed-off-by: Paulo Zanoni
On Fri, Sep 13, 2013 at 04:41:42PM +0300, Jani Nikula wrote:
> On Fri, 13 Sep 2013, Damien Lespiau wrote:
> > On Fri, Sep 13, 2013 at 12:21:21PM +0300, Jani Nikula wrote:
> >> On Fri, 13 Sep 2013, Paulo Zanoni wrote:
> >> > From: Paulo Zanoni
> >> >
> >> > So far we control all the reads an none
On Fri, 13 Sep 2013, Ville Syrjälä wrote:
> On Fri, Sep 13, 2013 at 04:04:03PM +0300, Jani Nikula wrote:
>> On Mon, 09 Sep 2013, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > Add the 120MHz refernce clock case for PCH DPLLs.
>> >
>> > Also determine the reference clock f
On Fri, 13 Sep 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We already extract the DPLL state to pipe_config, so let's make use of
> it in i9xx_crtc_clock_get() and avoid the register reads.
>
> This will also make the function closer to being useable with PCH DPLL
> since
On Fri, 13 Sep 2013, Damien Lespiau wrote:
> On Fri, Sep 13, 2013 at 12:21:21PM +0300, Jani Nikula wrote:
>> On Fri, 13 Sep 2013, Paulo Zanoni wrote:
>> > From: Paulo Zanoni
>> >
>> > So far we control all the reads an none of them exceeds the current
>> > limit of 20 bytes, but we never think a
On Fri, 13 Sep 2013, Daniel Vetter wrote:
> On Fri, Sep 13, 2013 at 11:03:09AM +0300, Jani Nikula wrote:
>> Flat out skip anything to do with PLL if we have a DSI encoder (and thus
>> DSI PLL). Also skip PLL computation if the encoder has already set
>> clocks. This allows for some tidying up of t
Change: Add support to change the pixel format, base surface address, tiling
mode, tiling
offset on the flow during the primary plane flip.
Issue: This support is needed by hardware composer to meet the performance
optimization requirement for 3D benchmark. This patch enables change in
pixel form
From: Ville Syrjälä
We already extract the DPLL state to pipe_config, so let's make use of
it in i9xx_crtc_clock_get() and avoid the register reads.
This will also make the function closer to being useable with PCH DPLL
since the registers for those live in a different address.
Also kill the us
On Fri, Sep 13, 2013 at 03:40:55PM +0300, Jani Nikula wrote:
> On Fri, 06 Sep 2013, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We already extract the DPLL state to pipe_config, so let's make use of
> > it in i9xx_crtc_clock_get() and avoid the register reads.
>
> What ab
On Fri, Sep 13, 2013 at 04:04:03PM +0300, Jani Nikula wrote:
> On Mon, 09 Sep 2013, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add the 120MHz refernce clock case for PCH DPLLs.
> >
> > Also determine the reference clock frequency more accurately by
> > checking for the PL
On Mon, 09 Sep 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add the 120MHz refernce clock case for PCH DPLLs.
>
> Also determine the reference clock frequency more accurately by
> checking for the PLLB_REF_INPUT_SPREADSPECTRUMIN refclk input
> mode. The gen2 code already ch
From: Ville Syrjälä
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we
can kill the get_clock() callback and instead do the clock readout
in get_pipe_config().
Also i9xx_crtc_clock_get() can now extract the frequency of the PCH
DPLL, so use it to populate port_clock accurat
On Fri, Sep 13, 2013 at 11:03:09AM +0300, Jani Nikula wrote:
> Flat out skip anything to do with PLL if we have a DSI encoder (and thus
> DSI PLL). Also skip PLL computation if the encoder has already set
> clocks. This allows for some tidying up of the code, including a
> superfluous call to intel
On Fri, Sep 13, 2013 at 02:57:37PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 13, 2013 at 11:03:08AM +0300, Jani Nikula wrote:
> > The cursor is supposed to be disabled during crtc mode set (disabled by
> > ctrc disable). Assert this is the case.
> >
> > v2: move cursor disabled assert next to plan
From: Ville Syrjälä
Extract the code to calculate the dotclock from the link clock and M/N
values into a new function from ironlake_crtc_clock_get().
The new function can be used to calculate the dotclock for both FDI and
DP cases.
Also simplify the code a bit along the way.
v2: Don't forget a
On Thu, Sep 12, 2013 at 10:28:29PM -0700, Ben Widawsky wrote:
> The buf pointer used during l3_write is just char *, therefore it does
> not require the silly any addition of offset.
>
> v2: Also fix i915_l3_read with a suggested logic from Ville
>
> Cc: Ville Syrjälä
> Signed-off-by: Ben Widaws
On Fri, Sep 06, 2013 at 11:29:02PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We want to do fuzzy clock checks for other things besides
> adjusted_mode.clock, so just pass two two clocks to compare
> to intel_fuzzy_clock_check().
>
> Reviewed-by: Jani Nikula
> Signed-
On Fri, Sep 13, 2013 at 12:21:21PM +0300, Jani Nikula wrote:
> On Fri, 13 Sep 2013, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > So far we control all the reads an none of them exceeds the current
> > limit of 20 bytes, but we never think about this when reviewing
> > patches, so we may at
On Fri, Sep 13, 2013 at 1:23 PM, Ville Syrjälä
wrote:
>
> So you might want to turn this function into some generic function to
> calculate both GMBUS and AUX clocks for VLV. You could just take the
> target frequency (2 or 4 in these cases) as a parameter and return the
> calculated divider.
I t
On Fri, Sep 13, 2013 at 03:30:51PM +0300, Jani Nikula wrote:
> On Fri, 06 Sep 2013, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Extract the code to calculate the dotclock from the link clock and M/N
> > values into a new function from ironlake_crtc_clock_get().
> >
> > The
On Fri, 06 Sep 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We already extract the DPLL state to pipe_config, so let's make use of
> it in i9xx_crtc_clock_get() and avoid the register reads.
What about the calls through intel_dvo_init/intel_lvds_init ->
intel_crtc_mode_get
On Fri, 06 Sep 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Extract the code to calculate the dotclock from the link clock and M/N
> values into a new function from ironlake_crtc_clock_get().
>
> The new function can be used to calculate the dotclock for both FDI and
> DP c
On Tue, 10 Sep 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add functions to read out the CPU and PCH transcoder M/N values,
> and use them to fill out the pipe config dp_m_n information. And
> while at it populate has_dp_encoder too.
>
> Also refactor ironlake_get_fdi_m_n_
On Fri, Sep 13, 2013 at 11:03:08AM +0300, Jani Nikula wrote:
> The cursor is supposed to be disabled during crtc mode set (disabled by
> ctrc disable). Assert this is the case.
>
> v2: move cursor disabled assert next to plane asserts (Ville)
>
> Suggested-by: Chris Wilson
> Signed-off-by: Jani
On Fri, 06 Sep 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On CTG+ read out the pipe bpp setting from hardware and fill it into
> pipe config. Also check it appropriately.
>
> v2: Don't do the pipe_bpp extraction inside the PCH only code block on
> ILK+.
> Avoid th
On Fri, Sep 13, 2013 at 02:39:20PM +0800, Chon Ming Lee wrote:
> Without the DPIO cmnreset, the PLL fail to lock. This should have
> done by BIOS.
>
> v2: Move this to intel_uncore_sanitize to allow it to get call during
> resume path. (Daniel)
>
> Signed-off-by: Chon Ming Lee
> ---
> drivers/
On Fri, 06 Sep 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> It would be easier if adjusted_mode.clock would be the pipe pixel clock,
> and it actually is, except for the cases where pixel_multiplier > 1.
>
> So let's change intel_sdvo to use port_clock as the multiplied clo
On Fri, Sep 13, 2013 at 02:39:21PM +0800, Chon Ming Lee wrote:
> CDCLK is used to generate the gmbus clock. This is normally done by
> BIOS. This is only for valleyview platform.
>
> v2: Move this to intel_i2c_reset to allow reprogram the gmbus frequency
> during resume. (Daniel)
>
> Signed-off-
On Thu, 12 Sep 2013, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Sometimes I see the "non asle set request??" message on my Haswell
> machine, so I decided to get the spec and see if some bits are missing
> from the mask. We do have some bits missing from the mask, so this
> patch adds them. But
For patches 1,2,3,6,7:
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, Sep 12, 2013 at 08:36:18PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 12, 2013 at 01:58:17PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Because this PCI config register doesn't exist on Gen5+.
> >
> > Signed-off-by: Paulo Zanoni
>
> Yep. Can't see it in configdb. Actually
On Thu, Sep 12, 2013 at 10:44:39PM +0100, Chris Wilson wrote:
> On Thu, Sep 12, 2013 at 06:06:43PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Both callers had code to sanitize the uncore and restore the GTT
> > mappings just before calling __i915_drm_thaw, so Chris suggested I
> >
On Thu, Sep 12, 2013 at 10:28:31PM -0700, Ben Widawsky wrote:
> Certain HSW SKUs have a second bank of L3. This L3 remapping has a
> separate register set, and interrupt from the first "slice". A slice is
> simply a term to define some subset of the GPU's l3 cache. This patch
> implements both the
On 09/13/2013 10:58 AM, Maarten Lankhorst wrote:
Op 13-09-13 10:23, Thomas Hellstrom schreef:
On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
Op 13-09-13 09:46, Thomas Hellstrom schreef:
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2
On Fri, Sep 13, 2013 at 12:17:17PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 12, 2013 at 10:28:34PM -0700, Ben Widawsky wrote:
> > On both Ivybridge and Haswell, row remapping information is saved and
> > restored with context. This means, we never actually properly supported
> > the l3 remapping b
On Fri, 13 Sep 2013, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> So far we control all the reads an none of them exceeds the current
> limit of 20 bytes, but we never think about this when reviewing
> patches, so we may at some point in the future overflow the buffer.
>
> My initial patch just a
On Thu, Sep 12, 2013 at 10:28:34PM -0700, Ben Widawsky wrote:
> On both Ivybridge and Haswell, row remapping information is saved and
> restored with context. This means, we never actually properly supported
> the l3 remapping because our sysfs interface is asynchronous (and not
> tied to any conte
On Thu, Sep 12, 2013 at 10:28:41PM -0700, Ben Widawsky wrote:
> Haswell added the ability to inject errors which is extremely useful for
> testing. Add two arguments to the tool to inject, and uninject.
>
> Signed-off-by: Ben Widawsky
Do we run any risk that a concurrent write/read to the same r
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
> On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra wrote:
> > On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
> >> >>if (!bo_tryreserve()) {
> >> >> up_read mmap_sem(); // Release the mmap_sem to avoid deadlocks.
Op 13-09-13 10:23, Thomas Hellstrom schreef:
> On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
>> Op 13-09-13 09:46, Thomas Hellstrom schreef:
>>> On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
> On 09/12/2013 11:50 PM, Maarten Lankhorst wrot
On Fri, Sep 13, 2013 at 11:03:08AM +0300, Jani Nikula wrote:
> The cursor is supposed to be disabled during crtc mode set (disabled by
> ctrc disable). Assert this is the case.
>
> v2: move cursor disabled assert next to plane asserts (Ville)
>
> Suggested-by: Chris Wilson
> Signed-off-by: Jani
On Fri, Sep 13, 2013 at 2:59 AM, Rob Clark wrote:
> I guess in i915 (and ttm) case, the issue arises due to need for CPU
> access to buffer via GTT? In which case I should be safe to drop the
> set_need_resched() as well? (Since CPU always has direct access to the
> pages.) Or am I missing somet
On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra wrote:
> On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
>> >>if (!bo_tryreserve()) {
>> >> up_read mmap_sem(); // Release the mmap_sem to avoid deadlocks.
>> >> bo_reserve(); // Wait for the BO to become avai
On Fri, Sep 13, 2013 at 10:54:45AM +0300, Ville Syrjälä wrote:
> On Fri, Sep 13, 2013 at 10:50:02AM +0300, Ville Syrjälä wrote:
> > On Fri, Sep 13, 2013 at 10:40:16AM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 12, 2013 at 09:13:56PM +0100, Chris Wilson wrote:
> > > > On Thu, Sep 12, 2013 at 10:4
On 09/13/2013 10:32 AM, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:23 AM, Thomas Hellstrom
wrote:
As previously mentioned, copy_from_user should return -EFAULT, since the
VMAs are marked with VM_IO. It should not recurse into fault(), so evil
user-space looses.
I haven't put a printk in t
On Fri, Sep 13, 2013 at 10:23 AM, Thomas Hellstrom
wrote:
> As previously mentioned, copy_from_user should return -EFAULT, since the
> VMAs are marked with VM_IO. It should not recurse into fault(), so evil
> user-space looses.
I haven't put a printk in the code to prove this, but gem mmap also
s
On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
> >>if (!bo_tryreserve()) {
> >> up_read mmap_sem(); // Release the mmap_sem to avoid deadlocks.
> >> bo_reserve(); // Wait for the BO to become available
> >> (interruptible)
> >> bo_unreserve();
On Fri, Sep 13, 2013 at 7:33 AM, Thomas Hellstrom wrote:
> Given that all copy_to_user / copy_from_user paths are actually hit during
> testing, right?
Ime it requires a bit of ingenuity to properly test this from
userspace. We're using a few tricks in drm/i915 kernel testing:
- When we hand a gt
On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
Op 13-09-13 09:46, Thomas Hellstrom schreef:
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2
On Thu, Sep 12, 2013 at 10:28:30PM -0700, Ben Widawsky wrote:
> Haswell changed the log registers to be WO, so we can no longer read
> them to determine the programming (which sucks, see later note). For
> now, simply use the cached value, and hope HW doesn't screw us over.
>
> Bugzilla: https://b
Flat out skip anything to do with PLL if we have a DSI encoder (and thus
DSI PLL). Also skip PLL computation if the encoder has already set
clocks. This allows for some tidying up of the code, including a
superfluous call to intel_limit() for LVDS downclock path.
Signed-off-by: Jani Nikula
Review
The cursor is supposed to be disabled during crtc mode set (disabled by
ctrc disable). Assert this is the case.
v2: move cursor disabled assert next to plane asserts (Ville)
Suggested-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 23 ++
On Fri, Sep 13, 2013 at 10:50:02AM +0300, Ville Syrjälä wrote:
> On Fri, Sep 13, 2013 at 10:40:16AM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 12, 2013 at 09:13:56PM +0100, Chris Wilson wrote:
> > > On Thu, Sep 12, 2013 at 10:45:43PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
Op 13-09-13 09:46, Thomas Hellstrom schreef:
> On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
>> Op 13-09-13 08:44, Thomas Hellstrom schreef:
>>> On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
> On 09/12/2013 05:45 PM, Maarten Lankhorst wrot
On Fri, Sep 13, 2013 at 10:40:16AM +0300, Ville Syrjälä wrote:
> On Thu, Sep 12, 2013 at 09:13:56PM +0100, Chris Wilson wrote:
> > On Thu, Sep 12, 2013 at 10:45:43PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > On HSW enabling a plane on a disabled pipe m
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 1
On Thu, Sep 12, 2013 at 09:13:56PM +0100, Chris Wilson wrote:
> On Thu, Sep 12, 2013 at 10:45:43PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On HSW enabling a plane on a disabled pipe may hang the entire system.
> > And there's no good reason for doing it ever, s
On Thu, Sep 12, 2013 at 09:09:05PM +0100, Chris Wilson wrote:
> On Thu, Sep 12, 2013 at 10:45:41PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Jani Nikula
> >
> > The cursor is disabled before crtc mode set in crtc disable (and we
> > assert this is the case), and enabled afterwards in
On Thu, Sep 12, 2013 at 09:08:17PM +0100, Chris Wilson wrote:
> On Thu, Sep 12, 2013 at 10:45:42PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On HSW enabling a plane on a disabled pipe may hang the entire system.
> > And there's no good reason for doing it ever, s
Op 13-09-13 08:44, Thomas Hellstrom schreef:
> On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
>> Op 12-09-13 18:44, Thomas Hellstrom schreef:
>>> On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
> On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra
92 matches
Mail list logo
