We have done unclaimed register access check in normal
(mmio_debug=0) mode once per write. This adds probability
of finding the exact sequence where we did the bad access, but
also adds burden to each write.
As we have mmio_debug available for more fine grained analysis,
give up accuracy of detect
d test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20151215]
[cannot apply to v4.4-rc5]
url:
https://github.com/0day-ci/linux/commits/Yetunde-Adebisi/drm-i915-Add-Backlight-Control-using-DPCD-for-eDP-connectors-v4/20151216-030252
base: git://anongit.freedesktop.o
> -Original Message-
> From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
> Sent: Tuesday, December 15, 2015 4:09 AM
> To: Song, Ruiling ; k...@bitplanet.net; Winiarski,
> Michal
> Cc: intel-gfx@lists.freedesktop.org; mesa-...@lists.freedesktop.org; Ben
> Widawsky ; dri-de...@lists.fre
On Tuesday, December 15, 2015 10:06:33 AM Alan Stern wrote:
> On Mon, 14 Dec 2015, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki
> >
> > Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
> > that will increment the device's runtime PM usage counter and
> > return 'true' i
On Tuesday, December 15, 2015 03:28:54 PM Ulf Hansson wrote:
> On 14 December 2015 at 23:22, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
>
> As we already have pm_runtime_set_active() and pm_runtime_active(),
> cha
Atm, we assert that the device is not suspended until the point when the
device is truly put to a suspended state. This is fine, but we can catch
more problems if we check that RPM refcount is non-zero. After that one
drops to zero we shouldn't access the device any more, even if the actual
device
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
between commit:
8fbf9d92a7bc ("drm/vmwgfx: Implement the cursor_set2 callback v2")
from Linus' tree and
Is this something close to what we wanted to optimize for edp resume time and
using wall clock.
-Original Message-
From: Kumar, Abhay
Sent: Tuesday, December 15, 2015 2:17 PM
To: Intel-gfx@lists.freedesktop.org
Cc: Kumar, Abhay
Subject: [PATCH] drm/i915: edp resume/On time optimization.
On Wed, Dec 16, 2015 at 12:18:20AM +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 04:13:49PM -0800, Ben Widawsky wrote:
> > This has been incorrect since the original commit from Oscar Mateo here:
> > commit 4da46e1e5bb7e7396fad172cdaffbe496562f3d8
> > Author: Oscar Mateo
> > Date: Thu Jul
On Tue, Dec 15, 2015 at 04:13:49PM -0800, Ben Widawsky wrote:
> This has been incorrect since the original commit from Oscar Mateo here:
> commit 4da46e1e5bb7e7396fad172cdaffbe496562f3d8
> Author: Oscar Mateo
> Date: Thu Jul 24 17:04:27 2014 +0100
>
> drm/i915/bdw: GEN-specific logical ring
On Wed, Dec 16, 2015 at 12:52:34AM +0200, Imre Deak wrote:
> On Tue, 2015-12-15 at 21:07 +, Chris Wilson wrote:
> > My current thinking is that the hangcheck/RPS tasks are wrong - and
> > that
> > we do actually have explicit wakerefs that should cover their
> > lifetimes
> > (but we fail to ac
This has been incorrect since the original commit from Oscar Mateo here:
commit 4da46e1e5bb7e7396fad172cdaffbe496562f3d8
Author: Oscar Mateo
Date: Thu Jul 24 17:04:27 2014 +0100
drm/i915/bdw: GEN-specific logical ring emit request
The command's offset field is only 10 bits, and this is cor
On Tue, 2015-12-15 at 22:57 +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> > All platforms with power well support have runtime PM support, so
> > simplify things by explicitly disabling power well support on
> > platforms
> > without runtime PM support.
On Tue, 2015-12-15 at 21:07 +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 08:10:35PM +0200, Imre Deak wrote:
> > Atm, we assert that the device is not suspended until the point
> > when the
> > device is truly put to a suspended state. This is fine, but we can
> > catch
> > more problems if
From: Abhay Kumar
Make resume codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
drivers/gpu/drm/i915/intel_dp.c | 18 ++
drivers/gpu/drm/i91
On Tue, Dec 15, 2015 at 07:19:24PM -0200, Paulo Zanoni wrote:
> 2015-12-15 19:08 GMT-02:00 Ville Syrjälä :
> > On Tue, Dec 15, 2015 at 06:51:56PM -0200, Paulo Zanoni wrote:
> >> 2015-12-14 18:15 GMT-02:00 :
> >> > From: Ville Syrjälä
> >> >
> >> > Gen2/3 platforms have some unusual tile dimension
2015-12-15 19:08 GMT-02:00 Ville Syrjälä :
> On Tue, Dec 15, 2015 at 06:51:56PM -0200, Paulo Zanoni wrote:
>> 2015-12-14 18:15 GMT-02:00 :
>> > From: Ville Syrjälä
>> >
>> > Gen2/3 platforms have some unusual tile dimensions. Account
>> > for them to make the test work correctly.
>> >
>> > Signed
On Tue, Dec 15, 2015 at 06:51:56PM -0200, Paulo Zanoni wrote:
> 2015-12-14 18:15 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > Gen2/3 platforms have some unusual tile dimensions. Account
> > for them to make the test work correctly.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > tests/gem_mmap_
On Tue, Dec 15, 2015 at 08:10:35PM +0200, Imre Deak wrote:
> Atm, we assert that the device is not suspended until the point when the
> device is truly put to a suspended state. This is fine, but we can catch
> more problems if we check that RPM refcount is non-zero. After that one
> drops to zero
On Tue, Dec 15, 2015 at 08:10:30PM +0200, Imre Deak wrote:
> All platforms with power well support have runtime PM support, so
> simplify things by explicitly disabling power well support on platforms
> without runtime PM support. This results in holding the init power domain
> reference whenever t
2015-12-14 18:15 GMT-02:00 :
> From: Ville Syrjälä
>
> Gen2/3 platforms have some unusual tile dimensions. Account
> for them to make the test work correctly.
>
> Signed-off-by: Ville Syrjälä
> ---
> tests/gem_mmap_gtt.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions
On Mon, Dec 14, 2015 at 09:52:10PM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 10:15:51PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Gen2/3 platforms have some unusual tile dimensions. Account
> > for them to make the test work correctly.
>
> iirc, for t
On Tue, Dec 01, 2015 at 04:17:12AM +0530, Deepak M wrote:
> The generic gpio is sequence is parsed from the VBT and the
> GPIO table is updated with the North core, South core and
> SUS core elements.
>
> v2: Move changes in sideband.c file to new patch(Jani), rebase
> v3: Moved the Macro`s to int
On Tue, Dec 01, 2015 at 04:17:11AM +0530, Deepak M wrote:
> Adding a argument to the gpio read/write functions
> which accepts the block name.
>
> v2: rebase
> v3: rebase
>
> Cc: Jani Nikula
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/i915_drv.h| 5 +++--
> drivers/gpu/d
Hi Yetunde,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20151215]
[cannot apply to v4.4-rc5]
url:
https://github.com/0day-ci/linux/commits/Yetunde-Adebisi/drm-i915-Add-Backlight-Control-using-DPCD-for-eDP-connectors-v4/20151216-030252
base: git
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 10 --
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_ru
On 14/12/15 22:17, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 05:13:43PM +, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 04:30:04PM +, Nick Hoath wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 900ffd0..7df3c7a 100644
--- a/dr
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_
We can make the RPM dependency on RC6 explciit in the code by taking an
actual RPM reference, instead of avoiding to drop the initial one. This
will also enable us to remove the HAS_RUNTIME_PM special casing from
more places in the next patch.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/in
The device should be on for the whole duration of the update, so check
for this.
v2:
- use the existing dev_priv directly everywhere (Ville)
v3:
- check also that we are in an RPM atomic section (Chris)
- add the assert to i915_ggtt_insert_entries/clear_range too (Chris)
Signed-off-by: Imre Deak
All platforms with power well support have runtime PM support, so
simplify things by explicitly disabling power well support on platforms
without runtime PM support. This results in holding the init power domain
reference whenever the driver is loaded in addition to an RPM reference,
which reflects
In some cases we want to check whether we hold an RPM wakelock reference
for the whole duration of a sequence. To achieve this add a new RPM atomic
sequence
counter that we increment any time the wakelock refcount drops to zero.
Check whether the sequence number stays the same during the atomic
se
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 2c2151f..9945040 100644
--- a/drivers/gpu/drm/i915/int
On Tue, Dec 15, 2015 at 07:45:42PM +0200, Mika Kuoppala wrote:
> Imre mentioned that chv might also have capability to
> track unclaimed mmio accesses. Ville added that
> both chv and vlv has this capability and he had already
> made this way back [1]. Mimic what Ville's patch does
> but adapt on t
On 15/12/15 14:54, Chris Wilson wrote:
On Tue, Dec 15, 2015 at 02:41:47PM +, Dave Gordon wrote:
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Using stolen backed objects as a batchbuffer may result into a kernel
panic during relocation. Added a check to
Atm, we assert that the device is not suspended until the point when the
device is truly put to a suspended state. This is fine, but we can catch
more problems if we check that RPM refcount is non-zero. After that one
drops to zero we shouldn't access the device any more, even if the actual
device
As a preparation for follow-up patches add a new helper that checks
whether we hold an RPM reference, since this is what we want most of
the cases. Atm this helper will only check for the HW suspended state, a
follow-up patch will do the actual change to check the refcount instead.
One exception is
v2-v3:
- unchanged
v4:
- keep the corresponding check in the get helper (Chris)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 29157f
We don't really need to check this flag in the get/put/assert helpers,
as on platforms without RPM support we won't ever enable RPM. That means
pm.suspend will be always false and the assert will be always true.
Do this to simplify the code and to let us extend the RPM asserts to all
platforms for
This is v4 of [1]. It has the following changes:
- fix module reload that got broken in v3 due to removal of HAS_RUNTIME_PM
(added patch 1-3 + revised patch 4)
- disable the wakeref asserts in the IRQ handlers and RPS work too
(revised patch 7)
Imre Deak (10):
drm/i915: clarify comment abou
Imre mentioned that chv might also have capability to
track unclaimed mmio accesses. Ville added that
both chv and vlv has this capability and he had already
made this way back [1]. Mimic what Ville's patch does
but adapt on top of less frequent mmio accesses by
omitting checking always on reg writ
Access the unclaimed reg detection register through
one helper which also does cleanup. Note that we now access
the register only if the platform has the actual non claimed
access bit. This prevents reading the register with gens that
doesn't have the register or the unclaimed bit,
when debug_mmio
On Thu, Dec 03, 2015 at 11:37:36AM -0800, Matt Roper wrote:
> If we fail to reconstruct the BIOS fb (e.g., because the FB is too
> large), we'll be left with plane state that indicates the primary plane
> is visible yet has a NULL fb. This mismatch causes problems later on
> (e.g., for the waterma
On 14/12/15 11:28, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 11:14:31AM +, Dave Gordon wrote:
On 11/12/15 22:59, Chris Wilson wrote:
The request tells us where to read the ringbuf from, so use that
information to simplify the error capture. If no request was active at
the time of the hang
On 11/12/15 22:59, Chris Wilson wrote:
igt likes to inject GPU hangs into its command streams. However, as we
expect these hangs, we don't actually want them recorded in the dmesg
output or stored in the i915_error_state (usually). To accomodate this
allow userspace to set a flag on the context t
On 11/12/15 18:15, Daniel Vetter wrote:
On Wed, Dec 09, 2015 at 07:39:56PM +, Dave Gordon wrote:
On 09/12/15 16:15, Tvrtko Ursulin wrote:
Hi,
On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite functio
On Tue, Dec 15, 2015 at 02:56:10PM +, Dave Gordon wrote:
> On 14/12/15 15:39, Thierry Reding wrote:
> >On Wed, Dec 09, 2015 at 05:08:02PM +0100, Daniel Vetter wrote:
> >>Every time I type or review docs this seems a bit different. Try to
> >>document the common style so we can try to unify at l
On 10 December 2015 at 09:27, Morton, Derek J wrote:
>>
>>
>>-Original Message-
>>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>>Daniel Vetter
>>Sent: Thursday, December 10, 2015 9:07 AM
>>To: Wood, Thomas
>>Cc: intel-gfx@lists.freedesktop.org
>>Subject: R
On 11/12/15 01:17, yu@intel.com wrote:
From: Alex Dai
Split GuC work queue space checking from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handl
Use the connector type instead of VBT directly to decide which backlight
mechanism to use on VLV/CHV. (Indirectly, this is the same thing, but
hides the VBT use.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
The VBT is a monster and it keeps growing. Originally we've extracted
bits and pieces out of there, and added them cleanly to our own
structures in dev_priv->vbt, with our own macros. Later on we've been
slipping and we have copied stuff from VBT verbatim, using the same
structs and defines as in V
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 50
drivers/gpu/drm/i915/intel_lvds.c | 53 +--
3 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/dr
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 38 ++
drivers/gpu/drm/i915/intel_tv.c | 43 +--
3 files changed, 40 insertions(+), 42 deletions(-)
diff --git a/driv
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 33 -
drivers/gpu/drm/i915/intel_dsi.c | 23 ++-
3 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915
We've been accumulating code across the driver that depends on the VBT
specific structures and defines. The VBT is an uncontrollable
beast. Encourage encapsulation of the VBT data by hiding the structures
and defines in a private header only to be included from intel_bios.c.
Signed-off-by: Jani Ni
The intel_bios.h header doesn't even need it, but other headers included
from i915_drv.h do. Let's untangle the mess a bit.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --gi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 33 +
drivers/gpu/drm/i915/intel_dp.c | 21 +
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i9
Using lower_32_bits and upper_32_bits macros was accidentally dropped in:
commit 8b4d57e7b75cb0bd01d11ad7f597909034a316aa
Author: Michał Winiarski
Date: Wed Sep 9 16:07:10 2015 +0200
intel: Add support for softpin
Let's restore previous, more readable format.
Cc: Kristian
On Mon, Dec 14, 2015 at 04:54:02PM +0200, Ville Syrjälä wrote:
> On Sun, Dec 13, 2015 at 12:49:45PM +, Chris Wilson wrote:
> > i7-5557U nuc currently connected to HDMI.
>
> Sigh. Do those correcpond to AUX attempts by any chance? IIRC that was where
> Jani saw the problem on his BDW.
>
> Oh a
On Mon, 14 Dec 2015, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
> that will increment the device's runtime PM usage counter and
> return 'true' if its status is RPM_ACTIVE and its usage counter
> is greater than 0 at th
Hi Ankitprasad,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.4-rc5 next-20151215]
url:
https://github.com/0day-ci/linux/commits/ankitprasad-r-sharma-intel-com/drm-i915-Allow-use-of-get_dma_address-for-stolen-backed-objects/20151215-191838
base: git
Ville Syrjälä writes:
> On Tue, Dec 15, 2015 at 04:25:07PM +0200, Mika Kuoppala wrote:
>> Currently interrupt code is the only place checking
>> for the unclaimed register access prior to actual register
>> macros using the same functionality. Rename the function
>> and make it return bool so tha
Ville Syrjälä writes:
> On Tue, Dec 15, 2015 at 04:25:12PM +0200, Mika Kuoppala wrote:
>> Imre mentioned that chv might also have capability to
>> track unclaimed mmio accesses. And it has, so take it
>> into use.
>
> VLV too.
>
> My old patch:
> http://lists.freedesktop.org/archives/intel-gfx/20
On 14/12/15 15:39, Thierry Reding wrote:
On Wed, Dec 09, 2015 at 05:08:02PM +0100, Daniel Vetter wrote:
Every time I type or review docs this seems a bit different. Try to
document the common style so we can try to unify at least new docs.
v2: Spelling fixes from Pierre, Laurent and Jani.
v3:
On Tue, Dec 15, 2015 at 04:44:25PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 04:25:12PM +0200, Mika Kuoppala wrote:
> > Imre mentioned that chv might also have capability to
> > track unclaimed mmio accesses. And it has, so take it
> > into use.
>
> VLV too.
>
> My old patch:
> http:/
On Tue, Dec 15, 2015 at 02:41:47PM +, Dave Gordon wrote:
> On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
> >From: Ankitprasad Sharma
> >
> >Using stolen backed objects as a batchbuffer may result into a kernel
> >panic during relocation. Added a check to prevent the panic and fail
>
Hello,
We launched Intel GPU Tools on 7 platforms: Skylake-Y, Braswell-M,
Broadwell-U, Baytrail-M, Haswell-U, Ivy Bridge and Sandy Bridge to
validate tag drm-intel-testing-2015-12-04 (kernel 4.4-rc3).
Unusual numbers of tests are fail on BSW and SKL, they must be executed
again (managed as not ru
Chris Wilson writes:
> On Tue, Dec 15, 2015 at 04:25:06PM +0200, Mika Kuoppala wrote:
>> Access the unclaimed reg detection register through
>> one helper which also does cleanup. Note that we now access
>> the register only if the platform has the actual non claimed
>> access bit. This prevents
On Tue, Dec 15, 2015 at 04:25:09PM +0200, Mika Kuoppala wrote:
> We have done unclaimed register access check in normal
> (mmio_debug=0) mode once per write. This adds probability
> of finding the exact sequence where we did the bad access, but
> also adds burden to each write.
>
> As we have mmio
On Tue, Dec 15, 2015 at 04:25:09PM +0200, Mika Kuoppala wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 471f120..3a9229b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13545,6 +13545
On Tue, Dec 15, 2015 at 04:25:07PM +0200, Mika Kuoppala wrote:
> Currently interrupt code is the only place checking
> for the unclaimed register access prior to actual register
> macros using the same functionality. Rename the function
> and make it return bool so that the possible error message
>
On Tue, Dec 15, 2015 at 04:25:12PM +0200, Mika Kuoppala wrote:
> Imre mentioned that chv might also have capability to
> track unclaimed mmio accesses. And it has, so take it
> into use.
VLV too.
My old patch:
http://lists.freedesktop.org/archives/intel-gfx/2013-May/027599.html
>
> Cc: Imre Dea
On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Using stolen backed objects as a batchbuffer may result into a kernel
panic during relocation. Added a check to prevent the panic and fail
the execbuffer call. It is not recommended to use stolen object as
a batch
On Tue, Dec 15, 2015 at 04:25:06PM +0200, Mika Kuoppala wrote:
> Access the unclaimed reg detection register through
> one helper which also does cleanup. Note that we now access
> the register only if the platform has the actual non claimed
> access bit. This prevents reading the register with gen
On Tue, Dec 15, 2015 at 04:25:11PM +0200, Mika Kuoppala wrote:
> This is a natural boundary to peek if our power domain
> management is accurate.
No, I have plans for this to be very frequent. In that bold plan,
the suspend/resume boundary is more sensible.
-Chris
--
Chris Wilson, Intel Open Sou
On 14 December 2015 at 23:22, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
As we already have pm_runtime_set_active() and pm_runtime_active(),
changing the new function name to "pm_runtime_get_if_active" may be
better!?
If something, the usual suspect being bios, access hw
behind our back, don't let it slide into situation where
normal register access will detect this and spit out
a warn on into dmesg. On some bdw bioses this happens
during igt/bat run always and as there is not much we can
do about it, its better
This is a natural boundary to peek if our power domain
management is accurate.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index
Currently interrupt code is the only place checking
for the unclaimed register access prior to actual register
macros using the same functionality. Rename the function
and make it return bool so that the possible error message
context is clear in the caller side. The motivation is to allow
usage of
Remove char* assignments and add branching hint and
also constify the parameters.
This results in a 35 bytes shorter fast path, so author
boldly assumes it helps without doing in-depth assembly
analysis.
v2: use WARN's branching (Chris), commit name (Joonas)
Cc: Joonas Lahtinen
Cc: Chris Wilson
Imre mentioned that chv might also have capability to
track unclaimed mmio accesses. And it has, so take it
into use.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_uncore.c | 34 +++
Access the unclaimed reg detection register through
one helper which also does cleanup. Note that we now access
the register only if the platform has the actual non claimed
access bit. This prevents reading the register with gens that
doesn't have the register or the unclaimed bit,
when debug_mmio
We have done unclaimed register access check in normal
(mmio_debug=0) mode once per write. This adds probability
of finding the exact sequence where we did the bad access, but
also adds burden to each write.
As we have mmio_debug available for more fine grained analysis,
give up accuracy of detect
On Mon, Dec 14, 2015 at 04:34:34PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 04:19:50PM +0200, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2015 at 12:50:55PM +0200, Jani Nikula wrote:
> > > The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
> > > mailbox may specify an al
On Tue, Dec 15, 2015 at 12:03:11PM +, Morton, Derek J wrote:
> >
> >
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> >Of ville.syrj...@linux.intel.com
> >Sent: Monday, December 14, 2015 8:16 PM
> >To: intel-gfx@lists.freedesktop.org
On Tue, Dec 15, 2015 at 02:01:24PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 01:29:59PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 15, 2015 at 11:16:52AM +, Chris Wilson wrote:
> > > On Tue, Dec 15, 2015 at 12:57:15PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Dec 15, 2015 at 09:5
On Tue, Dec 15, 2015 at 04:26:07PM +0530, ankitprasad.r.sha...@intel.com wrote:
> +static int
> +i915_gem_gtt_copy(struct drm_device *dev,
> +struct drm_i915_gem_object *obj, uint64_t size,
> +uint64_t data_offset, uint64_t data_ptr)
> +{
> + struct drm_i915_priv
>
>
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>ville.syrj...@linux.intel.com
>Sent: Monday, December 14, 2015 8:16 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH i-g-t 5/7] lib/debugfs: Read the crc frame counte
On Tue, Dec 15, 2015 at 01:29:59PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 11:16:52AM +, Chris Wilson wrote:
> > On Tue, Dec 15, 2015 at 12:57:15PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 15, 2015 at 09:57:22AM +, Chris Wilson wrote:
> > > > On Tue, Dec 15, 2015 at 11:41
On Tue, Dec 15, 2015 at 04:26:06PM +0530, ankitprasad.r.sha...@intel.com wrote:
> +static int
> +stolen_evict(struct drm_i915_private *dev_priv, u64 size)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_i915_gem_object *obj;
> - struct drm_mm_node *stolen;
On Tue, Dec 15, 2015 at 04:26:03PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> This patch adds support for clearing buffer objects via CPU/GTT. This
> is particularly useful for clearing out the non shmem backed objects.
> Currently intend to use this only for buff
On ti, 2015-12-15 at 13:35 +0200, Mika Kuoppala wrote:
> Some igt tests wants to drop caches by writing to this debugfs
> entry. The call to shrinker may ensure and it wants to update
> the fence registers, so hardware access happens. This access
> can happen in a spot where the block containing th
On Tue, Dec 15, 2015 at 04:26:08PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Chris Wilson
> +static int
> +copy_content(struct drm_i915_gem_object *obj,
> + struct drm_i915_private *i915,
> + struct address_space *mapping)
> +{
> + struct drm_mm_node node;
>
On Tue, Dec 15, 2015 at 11:22:29AM +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 01:05:56PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 15, 2015 at 10:24:13AM +, Chris Wilson wrote:
> > > The other question, does this obsolete our work around? Can I be that
> > > optimisitic?
> >
> > Th
Chris Wilson writes:
> On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
>> When we drop caches, this debugfs entry does hardware access later in
>> the chain, when fences are updated, so it needs a runtime pm ref.
>>
>> Dropping caches is used by some igt/bat tests, so this fixes
>
Some igt tests wants to drop caches by writing to this debugfs
entry. The call to shrinker may ensure and it wants to update
the fence registers, so hardware access happens. This access
can happen in a spot where the block containing these registers
might bepowered down.
To avoid getting unclaimed
On Tue, Dec 15, 2015 at 11:16:52AM +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 12:57:15PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 15, 2015 at 09:57:22AM +, Chris Wilson wrote:
> > > On Tue, Dec 15, 2015 at 11:41:44AM +0200, Ville Syrjälä wrote:
> > > > On Mon, Dec 14, 2015 at 08:54
On Tue, Dec 15, 2015 at 01:05:56PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 15, 2015 at 10:24:13AM +, Chris Wilson wrote:
> > The other question, does this obsolete our work around? Can I be that
> > optimisitic?
>
> The CS TLB one? I think I tried it at some point, and things till
> failed.
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
mailbox may specify an alternate location for VBT instead of mailbox #4.
Use the alternate location if available and valid, falling back to
mailbox #4 otherwise.
v2: Update debug logging (Ville)
Signed-off-by: Jani Nikula
---
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion,
thus unavailable in i915_opregion, so add a separate file for the VBT.
v2: Drop the locking as unneeded (Chris)
v3: Rebase
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 +
1 - 100 of 129 matches
Mail list logo
