On Thu, Aug 14, 2014 at 05:45:59PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 14, 2014 at 04:23:16PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
> > > We lost the software state tracking due to reset, so don't
> > > complain if it doesn't match.
> >
On Thu, Aug 14, 2014 at 11:52:47PM +, Wilde, Martin wrote:
> Greetings,
>
> I am submitting the below changes to i915 Gfx driver to support resume time
> Responsiveness measurements. These changes parallel the work already done in
> the IVB Windows Gfx driver. These changes in addition to
Greetings,
I am submitting the below changes to i915 Gfx driver to support resume time
Responsiveness measurements. These changes parallel the work already done in
the IVB Windows Gfx driver. These changes in addition to other OTS scripts
(suspend_resume) allow tracking of what is referred to
From: Clint Taylor
Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
duty cycle take affect at the
From: Ville Syrjälä
My Fujistsu-Siemens Lifebook S6010 doesn't like to resume from
S3 unless VGACNTR has been restore to the original value. The BIOS
value in this case was 0x0124008E. Setting the "VGA disable" bit
doesn't interfere with the S3 resume fortunately.
Signed-off-by: Ville Syrjälä
-
From: Ville Syrjälä
The spec says:
"For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata,
GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31
(DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in
both the DPLL A Control Register (06014h-06017h) and DPLL B Co
From: Ville Syrjälä
830M has problems when some of the pipes are disabled. Namely if a
plane, DVO port etc. is currently assigned to a disabled pipe, it
can't moved to the other pipe until the current pipe is also enabled.
To keep things simple just leave both pipes running all the time.
Ideally
From: Ville Syrjälä
830 really does want the pipe A quirk. The planes and ports don't
react to any register writes unless the pipe currently attached
to them is running, so it's impossible to move them to the other
pipe unless both pipes are running.
Also it's documented that the DPLL must be en
From: Ville Syrjälä
The vbt on my Fujitsu-Siemens Lifebook S6010 provides two 800x600 modes,
60Hz and 56Hz. The magic register values we have correspond to the 60Hz
mode, and as I don't know how one would trick the VGA BIOS to set up
the 56Hz mode we can't get the magic values for the orther mode
From: Ville Syrjälä
Try to use the same programming sequence as used by the IEGD driver.
Also shovel the magic register values into a big static const array.
The register values are actually the based on what the BIOS programs
on the Fujitsu-Siemens Lifebook S6010. IEGD seemed to have hardcoded
From: Ville Syrjälä
In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Looks like IEGD does a one time init of these three registers. We don't
have a good one time init place in the ns2501 driver, so let's ju
From: Ville Syrjälä
To more closely match the IEGD ns2501 driver behaviour, call the
mode_set hook while the DVO port is still disabled, then enable the DVO
port, and finally call the dpms hook.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dvo.c | 5 +++--
1 file changed, 3 inse
From: Ville Syrjälä
Disable double wide even if the pipe quirk compels us to leave the
pipe running. Double wide has certain implications for the plane
assignments so best keep it off.
Also helps resuming from S3 on the Fujitsu-Siemens Lifebook S6010
when double wide was enabled prior to suspend
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/dvo_ns2501.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 74f2af7..85030d4 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501
From: Ville Syrjälä
Calling the mode_set hook on DPMS changes doesn't seem to be necessary
for ns2501. Just drop it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dvo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/
From: Ville Syrjälä
Just pass the intel_crtc around instead of dev_priv+pipe.
Also make intel_wait_for_pipe_off() static since it's only used in
intel_display.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 37 +---
drivers/gpu/drm/i9
From: Ville Syrjälä
On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead
of DVOC.
FIXME: Maybe need to dig out the correct DVO port from VBT
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
From: Ville Syrjälä
My 830 is unhappy with trickle feed enabled. The symptom is that
the image on the screen shifts a bit to right occasionally.
The BIOS initially disables trickle feed, but it gets reset during
suspend, so we need to re-disable it ourselves. Juse disable it
always.
Also disabl
From: Ville Syrjälä
The max watermark value for gen2 planes B and C is 0x1f, instead of
the 0x3f that plane A uses.
Also check against the max even if the pipe is disabled since the
FIFO size exceeds the plane B and C max watermark value.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/
From: Ville Syrjälä
Thomas asked me to repost my 830/ns2501 patches. So here they are. I added
a few more patches (trickle feed and unused ring init) to fix some post-resume
issues. The primary plane rmw elimination patches and some locking/load detect
fixes already got merged.
Apart from these
From: Ville Syrjälä
gen2/3 platforms have a boatload of rings we're not using. On my 830
the BIOS/hw can leave some of those "active" after resume which will
prevent c3 entry. The ring is apparently considered active whenever
head != tail even if the ring is disabled.
Disable and clear all such
On Thu, Aug 14, 2014 at 12:49:06PM -0700, Rodrigo Vivi wrote:
> Tested-by and Reviewed-by: Rodrigo Vivi
Thanks a lot for testing and review, happy that we've tracked this one
down. Patch merged to dinq (since psr is unfortunately already disabled
again in 3.17 upstream).
-Daniel
>
>
> On Fri,
On Thu, Jul 24, 2014 at 05:04:41PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> If we receive a storm of requests for the same context (see
> gem_storedw_loop_*)
> we might end up iterating over too many elements in interrupt time, looking
> for
> contexts to squash together. Instead, sh
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
> Handle all context status events in the context status buffer on every
> context switch interrupt. We only remove work from the execlist queue
> after a context status buffer reports that it has completed and we only
> attempt to sche
On Thu, Jul 24, 2014 at 05:04:40PM +0100, Thomas Daniel wrote:
> From: Oscar Mateo
>
> In the current Execlists feeding mechanism, full preemption is not
> supported yet: only lite-restores are allowed (this is: the GPU
> simply samples a new tail pointer for the context currently in
> execution)
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
> Handle all context status events in the context status buffer on every
> context switch interrupt. We only remove work from the execlist queue
> after a context status buffer reports that it has completed and we only
> attempt to sche
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
> Handle all context status events in the context status buffer on every
> context switch interrupt. We only remove work from the execlist queue
> after a context status buffer reports that it has completed and we only
> attempt to sche
On Thu, Jul 24, 2014 at 05:04:39PM +0100, Thomas Daniel wrote:
> Handle all context status events in the context status buffer on every
> context switch interrupt. We only remove work from the execlist queue
> after a context status buffer reports that it has completed and we only
> attempt to sche
On Thu, Jul 24, 2014 at 05:04:38PM +0100, Thomas Daniel wrote:
> From: Michel Thierry
>
> Context switch (and execlist submission) should happen only when
> other contexts are not active, otherwise pre-emption occurs.
>
> To assure this, we place context switch requests in a queue and those
> re
On Thu, Jul 24, 2014 at 05:04:38PM +0100, Thomas Daniel wrote:
> From: Michel Thierry
>
> Context switch (and execlist submission) should happen only when
> other contexts are not active, otherwise pre-emption occurs.
>
> To assure this, we place context switch requests in a queue and those
> re
2014-08-14 12:06 GMT-03:00 Paulo Zanoni :
> From: Paulo Zanoni
>
> If we're runtime suspended and try to use the plane interfaces, we
> will get a lot of WARNs saying we did the wrong thing.
>
> We need to get runtime PM references to pin the objects, and to
> change the fences. The pin functions
On Wed, Aug 13, 2014 at 05:30:07PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > > Vetter
> > > Sent: Monday, August 11, 2014 10:25 PM
>
Hi Jani,
On 13-8-2014 3:43, Jani Nikula wrote:
> On Wed, 23 Jul 2014, Hans de Goede wrote:
>> On 07/22/2014 08:52 AM, Daniel Vetter wrote:
>>> On Tue, Jul 22, 2014 at 8:42 AM, Hans de Goede wrote:
>>> Also please grab latest intel-gpu-tools and record a register dump
>>> with intel_reg_dump,
Tested-by and Reviewed-by: Rodrigo Vivi
On Fri, Aug 8, 2014 at 11:27 AM, Daniel Vetter
wrote:
> We treat other plane updates in the same fashion. Spotted because
> Rodrigo kept reporting a bug in the PSR code where the frontbuffer was
> eternally stuck with a dirty cursor bit set.
>
> The psr
On Mon, 11 Aug 2014 23:33:57 +0200
Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 11:08:38AM -0700, Daisy Sun wrote:
> > BDW supports GT C0 residency reporting in constant time unit. Driver
> > calculates GT utilization based on C0 residency and adjusts RP
> > frequency up/down accordingly. For o
On Thu, Aug 14, 2014 at 05:51:48PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > For stolen pages, since it is verboten to access them directly on many
> > architectures, we have to read them through the GTT aperture. If they
> > are not accessible through the aperture, then we have to
On Thu, Aug 14, 2014 at 10:04:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We changed to an interrupt based vblank wait (as opposed to polling)
> in:
> commit 44bd93a3d367913d883be6abba9a6e51a53c4e90
> Author: Daniel Vetter
> Date: Fri Jul 25 23:36:44 2014 +020
From: Ville Syrjälä
We changed to an interrupt based vblank wait (as opposed to polling)
in:
commit 44bd93a3d367913d883be6abba9a6e51a53c4e90
Author: Daniel Vetter
Date: Fri Jul 25 23:36:44 2014 +0200
drm/i915: Use generic vblank wait
However we already had vblank waits on the wrong si
On Thu, Aug 14, 2014 at 08:33:23PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 7:58 PM, Ville Syrjälä
> wrote:
> > Sure but the user can supply any mode, doesn't have to be on any list.
> > And the only sane rule for the frobbing would be that you can (slightly)
> > reduce hdisp/vdisp bu
On Thu, Aug 14, 2014 at 11:09:25AM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Pixel replicated modes should be 720 horizontal pixel and pixel
> replicated by the HW across the HDMI cable at 2X pixel clock. Current
> horizontal resolution of 1440 does not allow pixel duplica
On Thu, Aug 14, 2014 at 7:58 PM, Ville Syrjälä
wrote:
> Sure but the user can supply any mode, doesn't have to be on any list.
> And the only sane rule for the frobbing would be that you can (slightly)
> reduce hdisp/vdisp but never expand them so that there will never be any
> extra garbage expos
From: Clint Taylor
Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently
On Thu, Aug 14, 2014 at 07:36:13PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 6:45 PM, Ville Syrjälä
> wrote:
> > On Thu, Aug 14, 2014 at 06:07:44PM +0200, Daniel Vetter wrote:
> >> On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
> >> wrote:
> >> > My quick grep audit tells me the viewp
On Thu, Aug 14, 2014 at 6:45 PM, Ville Syrjälä
wrote:
> On Thu, Aug 14, 2014 at 06:07:44PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
>> wrote:
>> > My quick grep audit tells me the viewport check and
>> > drm_primary_helper_update() are the only places in the c
2014-08-14 13:51 GMT-03:00 :
> From: Arun Siluvery
>
> This patch adds a new test to verify applied workarounds before
> and after an operation such as gpu reset, suspend/resume.
>
> It is a simple test which captures w/a state at the beginning and
> compares their status with the state after the
From: Arun Siluvery
This patch adds a new test to verify applied workarounds before
and after an operation such as gpu reset, suspend/resume.
It is a simple test which captures w/a state at the beginning and
compares their status with the state after the operation.
v2: w/a table is removed from
From: Arun Siluvery
The workarounds at the moment are initialized in init_clock_gating() but
they are lost during reset, suspend/resume; this patch moves workarounds
that are part of register state context to render ring init fn otherwise
default context ends up with incorrect values as they don'
On Thu, Aug 14, 2014 at 06:07:44PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
> wrote:
> > My quick grep audit tells me the viewport check and
> > drm_primary_helper_update() are the only places in the core that care.
> > The latter is rather dubious anyway since
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Thursday, August 14, 2014 5:28 PM
> To: Intel Graphics Development
> Cc: Mateo Lozano, Oscar; Daniel, Thomas; Daniel Vetter
> Subject: [PATCH] drm/i915: Add temporary ring->ctx backpointer
>
> From: Oscar
From: Oscar Mateo
The execlist patches have a bit a convoluted and long history and due
to that have the actual submission still misplaced deeply burried in
the low-level ringbuffer handling code. This design goes back to the
legacy ringbuffer code with its tricky lazy request and simple work
sub
On Thu, Aug 14, 2014 at 03:56:20PM +, Daniel, Thomas wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Thursday, August 14, 2014 4:37 PM
> > To: Daniel, Thomas
> > Cc: Daniel Vetter; intel-gfx@lists.freed
On Thu, Aug 14, 2014 at 5:45 PM, Ville Syrjälä
wrote:
> My quick grep audit tells me the viewport check and
> drm_primary_helper_update() are the only places in the core that care.
> The latter is rather dubious anyway since the clipping should be done
> against the adjusted mode and not the user
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, August 14, 2014 4:37 PM
> To: Daniel, Thomas
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context
On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote:
> Make sure plane rotation is reset correctly when restoring the fbdev
> configuration by using drm_mode_plane_set_obj_prop. This calls the
> driver's set_property callback and ensures the rotation is actually
> changed.
>
> Bugzilla: ht
Mika Kuoppala writes:
> Daniel Vetter writes:
>
>> On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
>>> We lost the software state tracking due to reset, so don't
>>> complain if it doesn't match.
>>
>> This sounds more like gpu reset should be a bit more careful (even more
>> care
On Thu, Aug 14, 2014 at 05:26:27PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 06:06:58PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 14, 2014 at 04:42:01PM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel
>
Add a function to restore the previous VT mode after
igt_set_vt_graphics_mode is called.
Signed-off-by: Thomas Wood
---
lib/igt_kms.c | 27 +--
lib/igt_kms.h | 1 +
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 11fd4e
The following patches allow the VT mode to be reset and then add a check in
kms_rotation_crc to ensure the rotation has been restored. The test in
kms_rotation_crc uses CRC values to determine this rather than just reading the
property since the original issue exposed an inconsistency between the c
Make sure the rotation is reset after the VT mode is restored by
collecting the unrotated CRC and comparing with the CRC value after VT mode
has been restored. The CRC is used to ensure the hardware state is checked,
rather than any software state.
References: https://bugs.freedesktop.org/show_bug
On Thu, Aug 14, 2014 at 05:32:28PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 03:09:45PM +, Daniel, Thomas wrote:
> > When it comes to the execlist submission (actually as early as the execlist
> > request queueing), the engine and context are indeed used and required.
> > intel_logi
Make sure plane rotation is reset correctly when restoring the fbdev
configuration by using drm_mode_plane_set_obj_prop. This calls the
driver's set_property callback and ensures the rotation is actually
changed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236
Signed-off-by: Thomas Wo
On Thu, Aug 14, 2014 at 05:26:27PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 06:06:58PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 14, 2014 at 04:42:01PM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel
>
Hi,
Do we have some (possiblly CRC based) tests coming for this? it'd be
super good to be able to test the work indepedently of a compositor when
reviewing. At the end of the day, we do really want tests covering that
code.
Thanks,
--
Damien
On Thu, Aug 14, 2014 at 02:54:21PM +0530, akash.g...
On Thu, Aug 14, 2014 at 03:09:45PM +, Daniel, Thomas wrote:
> When it comes to the execlist submission (actually as early as the execlist
> request queueing), the engine and context are indeed used and required.
> intel_logical_ring_advance_and_submit() is the lrc function analogous to
> __inte
On Thu, Aug 14, 2014 at 06:06:58PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 14, 2014 at 04:42:01PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
> > > From: Akash Goel
> > > + /* Check if the current FB is compatible with new request
Daniel Vetter writes:
> On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
>> We lost the software state tracking due to reset, so don't
>> complain if it doesn't match.
>
> This sounds more like gpu reset should be a bit more careful (even more
> careful than we already are compared
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, August 13, 2014 4:16 PM
> To: Daniel, Thomas
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context
On Thu, Aug 14, 2014 at 04:42:01PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
> > + /* Check if the current FB is compatible with new requested
> > + Pipesrc values by the User */
> > + i
From: Paulo Zanoni
If we're runtime suspended and try to use the plane interfaces, we
will get a lot of WARNs saying we did the wrong thing.
We need to get runtime PM references to pin the objects, and to
change the fences. The pin functions are the ideal places for
this, but intel_crtc_cursor_s
On Thu, Aug 14, 2014 at 01:18:46PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Wed, Aug 13, 2014 at 05:50:38PM +0300, Mika Kuoppala wrote:
> >> Chris Wilson writes:
> >>
> >> > The current error state harks back to the era of just a single VM. For
> >> > full-ppgtt, we capture e
On Thu, Aug 14, 2014 at 05:45:59PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 14, 2014 at 04:23:16PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
> > > We lost the software state tracking due to reset, so don't
> > > complain if it doesn't match.
> >
Chris Wilson writes:
> For stolen pages, since it is verboten to access them directly on many
> architectures, we have to read them through the GTT aperture. If they
> are not accessible through the aperture, then we have to abort.
>
> This was complicated by
>
> commit 8b6124a633d8095b0c8364f585
On Thu, Aug 14, 2014 at 04:23:16PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
> > We lost the software state tracking due to reset, so don't
> > complain if it doesn't match.
>
> This sounds more like gpu reset should be a bit more careful (even mo
On Thu, Aug 14, 2014 at 02:54:27PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
> + /* Check if the current FB is compatible with new requested
> +Pipesrc values by the User */
> + if (new_width > fb->width ||
> + new_height > fb
On Mon, 11 Aug 2014, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 01:15:35PM +0300, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> intel_enable_pipe_a() gets called with all the modeset locks already
>> held (by drm_modeset_lock_all()), so trying to grab the same
>> locks us
On Tue, 12 Aug 2014, Paulo Zanoni wrote:
> 2014-08-12 13:39 GMT-03:00 :
>> From: Ville Syrjälä
>>
>> Make sure the cursor gets fully clipped when enabling it on a disabled
>> crtc via setplane. This will prevent the lower level code from
>> attempting to enable the cursor in hardware.
>
> If thi
On Thu, Aug 14, 2014 at 02:54:25PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This patch removes the check for change in pitch of frame buffer
> across page flips. Since there is a support for MMIO based page
> flips, we can update the plane registers to update the
> FB pitch & acc
On Thu, Aug 14, 2014 at 04:50:19PM +0300, Jani Nikula wrote:
> On Thu, 14 Aug 2014, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > Currently the Graphics Driver provides an interface through which
> > one can get a snapshot of the overall Graphics memory consumption.
> > Also there i
On Thu, Aug 14, 2014 at 03:46:43PM +0300, Mika Kuoppala wrote:
> We lost the software state tracking due to reset, so don't
> complain if it doesn't match.
This sounds more like gpu reset should be a bit more careful (even more
careful than we already are compared to earlier kernels) with making s
On Thu, Aug 14, 2014 at 11:36:11AM +0100, Chris Wilson wrote:
> On Wed, Aug 13, 2014 at 10:58:54AM +0100, Chris Wilson wrote:
> > If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE
> > will silently fail. This leads to an indefinite hang as WAITACTIVE never
> > returns causing
On Thu, Aug 14, 2014 at 01:07:06PM +0300, Jani Nikula wrote:
> On Thu, 14 Aug 2014, Daniel Vetter wrote:
> > On Thu, Aug 14, 2014 at 8:54 AM, Chris Wilson
> > wrote:
> >> I disaggree with the conversion of the BUG_ON though, a WARN there is
> >> going to screw up unpredictably (well, a hard hang
On Thu, 2014-08-14 at 16:50 +0300, Jani Nikula wrote:
> On Thu, 14 Aug 2014, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > Currently the Graphics Driver provides an interface through which
> > one can get a snapshot of the overall Graphics memory consumption.
> > Also there is an in
On Thu, Aug 14, 2014 at 02:51:15PM +0300, Imre Deak wrote:
> On Wed, 2014-08-13 at 23:07 +0530, sagar.a.kam...@intel.com wrote:
> > From: Sagar Kamble
> >
> > With this change, intel_runtime_suspend and intel_runtime_resume functions
> > become completely platform agnostic. Platform specific susp
On Thu, 14 Aug 2014, sourab.gu...@intel.com wrote:
> From: Sourab Gupta
>
> Currently the Graphics Driver provides an interface through which
> one can get a snapshot of the overall Graphics memory consumption.
> Also there is an interface available, which provides information
> about the several
From: Sourab Gupta
Currently the Graphics Driver provides an interface through which
one can get a snapshot of the overall Graphics memory consumption.
Also there is an interface available, which provides information
about the several memory related attributes of every single Graphics
buffer crea
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
v2: fix build error
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gp
We lost the software state tracking due to reset, so don't
complain if it doesn't match.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
On Thu, Aug 14, 2014 at 02:53:44PM +0530, Sharma, Shashank wrote:
> Hi Daniel,
>
> I can do all the changes accordingly and upload a new patch.
>
> This is what I am going to do:
> 1. Change the EDID caching time to a second from a minute (probably there
> was a miscommunication).
> 2. Remove the
On Wed, 2014-08-13 at 23:07 +0530, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> With this change, intel_runtime_suspend and intel_runtime_resume functions
> become completely platform agnostic. Platform specific suspend/resume
> changes are moved to intel_suspend_complete and intel_re
On Wed, Aug 13, 2014 at 10:58:54AM +0100, Chris Wilson wrote:
> If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE
> will silently fail. This leads to an indefinite hang as WAITACTIVE never
> returns causing lockups on boot. This issue becomes apparent when the
> kernel driver
Chris Wilson writes:
> On Wed, Aug 13, 2014 at 05:50:38PM +0300, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > The current error state harks back to the era of just a single VM. For
>> > full-ppgtt, we capture every bo on every VM. It behoves us to then print
>> > every bo for every VM,
On Thu, 14 Aug 2014, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 8:54 AM, Chris Wilson
> wrote:
>> I disaggree with the conversion of the BUG_ON though, a WARN there is
>> going to screw up unpredictably (well, a hard hang without any output
>> is the predictable outcome). I'd like to have as
Hi Daniel,
I can do all the changes accordingly and upload a new patch.
This is what I am going to do:
1. Change the EDID caching time to a second from a minute (probably
there was a miscommunication).
2. Remove the gen_check
3. Use the connector->edid pointer to cache EDID.
I have only few p
From: Akash Goel
Added a new drm crtc property which provides control
to vary the Pipe Src or Crtc size.
With this, User can flip the frame buffers of resolution, which
is different from the currently selected mode. For this Driver will
appropriately enable the Panel fitter internally, for the r
From: Akash Goel
This patch adds a new drm crtc property for varying the Pipe Src size
or the Panel fitter input size. Pipe Src controls the size that is
scaled from.
This will allow to dynamically flip the frame buffers
of different resolutions.
For this Driver internally enables the Panel fitte
From: Akash Goel
This patch adds a check on the Max down scale ratio supported by the
Panel fitter. If Source width/height is too big, that the downscale
ratio of more than 1.125 is needed to fit into the Output window,
then that configuration will be rejected.
Signed-off-by: Akash Goel
Signed-
From: Akash Goel
Updated drm documentation to include description of
Crtc size property
Signed-off-by: Akash Goel
Signed-off-by: Pallavi G
---
Documentation/DocBook/drm.tmpl | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Docu
From: Akash Goel
This patch changes the return type of panel fitter configuration
functions from 'void', so that an error could be returned back to
User space, either during the modeset time or when some property
is being set, if the configuation is not valid.
Signed-off-by: Akash Goel
Signed-o
From: Akash Goel
This patch changes the return type of 'crtc_restore_mode'
function from 'void', so that an error could be returned back to
User space, from the set property ioctl call, if the configuation
is not valid.
Signed-off-by: Akash Goel
Signed-off-by: Pallavi G
---
drivers/gpu/drm/i91
From: Akash Goel
This patch removes the check for change in pitch of frame buffer
across page flips. Since there is a support for MMIO based page
flips, we can update the plane registers to update the
FB pitch & accordingly the offsets in LINOFF/TILEOFF registers.
The plane registers are updated
1 - 100 of 102 matches
Mail list logo
