Paulo Zanoni writes:
> The unclaimed register bit is only triggered when someone touches the
> specified register range.
>
I got the impression that we get the unclaimed access also
for other ranges, if they are powered down during access?
-Mika
> For the normal use case (with i915.mmio_debug=
On Fri, 04 Sep 2015, "Yang, Libin" wrote:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
>> Daniel Vetter
>> Sent: Wednesday, September 02, 2015 8:18 PM
>> To: Yang, Libin
>> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch;
>> jani.nik
On Fri, 04 Sep 2015 03:56:26 +0200,
Yang, Libin wrote:
>
>
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Wednesday, September 02, 2015 11:36 PM
> > To: Daniel Vetter
> > Cc: Jani Nikula; Yang, Libin; alsa-de...@alsa-project.org; intel-
> > g...@lists.freed
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Wednesday, September 02, 2015 11:36 PM
> To: Daniel Vetter
> Cc: Jani Nikula; Yang, Libin; alsa-de...@alsa-project.org; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> ville.syrj...@linux.intel.com
> Su
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, September 02, 2015 8:18 PM
> To: Yang, Libin
> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> jani.nik...@linux.intel.com; ville.syrj...@linux.intel.co
On Thu, Aug 20, 2015 at 03:42:27PM +, Vivi, Rodrigo wrote:
> Hi,
>
> Please consider pulling i915 updates to linux-firmware.git.
>
> The following changes since commit
> 38358cfcf50436bf4462b3e45f5b30ab66bb63a6:
>
> firmware: tegra: Update XHCI firmware to v50.10 for T210 (2015-08-12
> 14:
Unless future specs tells otherwise we can assume future gens
inherit some stuff from the previous so let's handle
missed cases when we know tehy should't be there and assume
default equals newest one.
No functional changes.
v2: Remove useless case as pointed out by Ville.
Ville Syrjälä
Signed-
On Thu, Sep 03, 2015 at 07:22:18PM +0200, Michał Winiarski wrote:
> + pts = kcalloc(pdpes * BITS_TO_LONGS(I915_PDES),
> + sizeof(unsigned long), GFP_TEMPORARY);
Something to remember is that kcalloc is written presuming that the size
argument (the second) is constant.
pts =
From: Chris Wilson
Delay the expensive read on the FPGA_DBG register from once per mmio to
once per forcewake section when we are doing the general wellbeing
check rather than the targetted error detection. This almost reduces
the overhead of the debug facility (for example when submitting execli
Hi
Following the discussions between Chris and I, here are some updated patches for
the unclaimed register subsystem. I still have some unanswered questions
regarding patch 4, but I decided to rebase it on top of my work, just in case we
decide to move forward with it.
Thanks,
Paulo
Chris Wilso
Fixes an issue introduced by:
commit 48572edd9d736d6fabd40b810a0de844ee4f800b
Author: Chris Wilson
Date: Thu Dec 18 10:55:50 2014 +
drm/i915: Disable the mmio.debug WARN after it fires
Since the above commit, on the default use case - i915.mmio_debug=0 -,
whenever we detect a single ac
I added this code on 8664281b64c457705db72fc60143d03827e75ca9, on
April 12 2013. Back then, we only had support for detecting unclaimed
registers on I915_WRITE operations, and we didn't have the
i915.mmio_debug infrastructure.
I tried to remember exactly why I added this code, and the only reason
The unclaimed register bit is only triggered when someone touches the
specified register range.
For the normal use case (with i915.mmio_debug=0), this commit will
avoid the extra __raw_i915_read32() call for every register outside
the specified range, at the expense of a few additional "if"
statem
From: Ville Syrjälä
We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI,
and just trying to frob the display timings to include borders results
in a corrupted picture. So reject the 'Center' scaling mode on GMCH
platforms for eDP and DSI.
TODO: Should really filter out the unsup
From: Ville Syrjälä
Compute the DSI PLL parameters during .compute_config() rather than
.pre_pll_enable() so that we can fail gracefully if we can't find
suitable parameters.
In order to do that we need to store the DSI PLL parameters in
pipe_config.
Signed-off-by: Ville Syrjälä
---
drivers/g
From: Ville Syrjälä
Add the scaling mode property to DSI connectors, handle changes in the
property value, and compute the panel fitter state during
.compute_config().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi.c | 69 +---
1 file change
From: Ville Syrjälä
The BIOS may leave the DSI PLL enabled in some wonky state where it just
refuses to lock. Simply disabling the PLL before reconfiguring it is not
enough to fix it, but power gating the PLL prior to reconfiguring does
work.
This happens on BYT FFRD8 when booting with HDMI conn
From: Ville Syrjälä
The pfit state is stored as register values, so dump them as hex instead
of decimal to make some sense of the error messages.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dr
From: Ville Syrjälä
Use the proper refclock frequency (100MHz) when reading out the
current DSI clock on CHV.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/driver
From: Ville Syrjälä
These BUGs don't serve any purpose IMO. Throw them out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
inde
From: Ville Syrjälä
Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While
the DPLL isn't used to provide the clock we still need the refclock, and
it appears that the pixel repeat factor also has an effect on DSI
output. So set up eveyrhing in DPLL and DPLL_MD as we would do for
From: Ville Syrjälä
VLV DPLL is sane and doesn't run on luck.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bddc17f..b33450
From: Ville Syrjälä
All the values in the DSI PLL LFSR seed table fit into 9bits, so change
the type to u16 from u32 to save a bit of space.
drivers/gpu/drm/i915/i915.ko:
-.rodata90824
+.rodata90760
Signed-off-by: Ville Syrjälä
---
drivers/gpu/
From: Ville Syrjälä
Supposedly the power sequencer still locks out the DPLL registers on
CHV, so let's issue a warning if it's still locked when enabling the
DPLL.
Also drop the redundant IS_MOBILE() check for VLV when we check the same
thing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/
From: Ville Syrjälä
Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local
pipe variable. Also makes it look more like the corresponding CHV code.
While at is change the CHV code to enum pipe from int,
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 15 +
From: Ville Syrjälä
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
to either pipe B or C. So do that to make pixel repeat work on pipes
B and C. Pipe A is fine without any tricks.
Fortunately the pixel repeat
From: Ville Syrjälä
The VLV and CHV DPLL disable and update are almost identical in
how the DPLL/DPLL_MD registers need to be set up. But the code
looks more different than it really is. Try to bring them into
line.
v2: s/chv_update_pll/chv_compute_dpll/
Signed-off-by: Ville Syrjälä
---
drive
From: Ville Syrjälä
As my previous half assed attempt [1] avoiding state checker warnings
for VLV/CHV DSI output shot down during review, I decided to actually
figure out what's the relationship between DSI and the DPLL registers.
Turns out there is one, so this series aims to make things robust
> > > > +
> > > > + /* redo AddFB */
> > > > + memset(&f, 0, sizeof(f));
> > > > +
> > > > + f.width = d->fb1_nv12.width;
> > > > + f.height = d->fb1_nv12.height;
> > > > + f.pixel_format = d->fb1_nv12.drm_format;
> > > > +
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, September 02, 2015 1:02 AM
> To: Konduru, Chandra
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Vetter, Daniel; Syrjala,
> Ville
> Subject: Re: [Intel-gfx] [PAT
On each call to gen8_alloc_va_range_3lvl we're allocating temporary
bitmaps needed for error handling. Unfortunately, when we increase
address space size (48b ppgtt) we do additional (512 - 4) calls to
kcalloc, increasing latency between exec and actual start of execution
on the GPU. Let's just do
On Wed, Sep 2, 2015 at 9:14 PM Matt Turner wrote:
> On Wed, Sep 2, 2015 at 9:01 PM, David Ho wrote:
> > Dear Rodrigo,
> >
> > Thank you for your help.
> >
> > I'll take a look at the PCI ID.
> >
> > However,
> > when I search GMA 3150 at 01.org, I came across this page:
> >
> https://01.org/linu
On 09/03/2015 12:36 AM, Jani Nikula wrote:
On Thu, 03 Sep 2015, yu@intel.com wrote:
> From: Alex Dai
>
> By using information from GuC css header, we can eliminate some
> hard code w.r.t size of some components of firmware.
>
> Signed-off-by: Alex Dai
> ---
> drivers/gpu/drm/i915/intel_g
From: Daniele Ceraolo Spurio
2 subparts of gem_bad_reloc check that the reloc address is below the
global gtt boundary. However, when executing from ppgtt the reloc
address can be greater than that and still be a valid address.
To be sure that we're using the right upper limit, select it based o
"Zanoni, Paulo R" writes:
> Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
>> A small, very small, step to sharing the duplicate code between
>> execlists and legacy submission engines, starting with the ringbuffer
>> allocation code.
>>
>> Signed-off-by: Chris Wilson
>> Cc: Arun Sil
On Thu, Sep 03, 2015 at 02:01:51PM +, Zanoni, Paulo R wrote:
> Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
> > A small, very small, step to sharing the duplicate code between
> > execlists and legacy submission engines, starting with the ringbuffer
> > allocation code.
> >
> > Si
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Instruction State Heap (ISH) must be in a
32-bit range, because the General Stat
This new version picks the suggestion from Michał Winiarski related to v3 [1].
48-bit virtual address range will be enabled in i915 soon, but some objects
must be referenced by 32-bit offsets. These patches use a new kernel flag to
specify if this restriction applies or not.
I'm sending these pat
Signed-off-by: Michel Thierry
---
intel/intel-symbol-check | 1 +
1 file changed, 1 insertion(+)
diff --git a/intel/intel-symbol-check b/intel/intel-symbol-check
index c555e6d..64ec4ed 100755
--- a/intel/intel-symbol-check
+++ b/intel/intel-symbol-check
@@ -39,6 +39,7 @@ drm_intel_bo_subdata
dr
Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
> A small, very small, step to sharing the duplicate code between
> execlists and legacy submission engines, starting with the ringbuffer
> allocation code.
>
> Signed-off-by: Chris Wilson
> Cc: Arun Siluvery
> Cc: Mika Kuoppala
> Cc: Da
On Thu, Sep 03, 2015 at 04:40:13PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 03, 2015 at 04:24:35PM +0300, Imre Deak wrote:
> > This register exists only pre GEN5, but atm we also access it on
> > VLV/BXT/CHV. Prevent accessing it on these latter platforms.
>
> We don't have LVDS on any of those p
On Thu, Sep 03, 2015 at 04:24:36PM +0300, Imre Deak wrote:
> These registers exist only before GEN5, so currently we may access
> undefined registers on VLV/CHV and BXT. Apply the workaround only pre
> GEN5.
>
> Since the workaround is relevant only when LVDS is present, for clarity
> apply it onl
On Thu, Sep 03, 2015 at 04:24:35PM +0300, Imre Deak wrote:
> This register exists only pre GEN5, but atm we also access it on
> VLV/BXT/CHV. Prevent accessing it on these latter platforms.
We don't have LVDS on any of those platforms.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i
These registers exist only before GEN5, so currently we may access
undefined registers on VLV/CHV and BXT. Apply the workaround only pre
GEN5.
Since the workaround is relevant only when LVDS is present, for clarity
apply it only if this is the case.
This triggered an unclaimed register access war
This register exists only pre GEN5, but atm we also access it on
VLV/BXT/CHV. Prevent accessing it on these latter platforms.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/dr
On Wed, 02 Sep 2015, Daniel Vetter wrote:
> On Tue, Sep 01, 2015 at 01:16:49PM +0300, Jani Nikula wrote:
>> On Thu, 27 Aug 2015, Sivakumar Thulasimani
>> wrote:
>> > From: "Thulasimani,Sivakumar"
>> >
>> > Compliance requires the driver to read dpcd register 0 to 12 and
>> > registers 0x200 to
On Thu, Aug 27, 2015 at 06:36:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Grab the connection_mutex around MSR link retraining to protect it
> against a concurrent modeset. We already do the same for SST.
>
> DP hpd_pulse can still otherwise race against modeset an
Arun Siluvery writes:
> On 02/09/2015 12:29, Chris Wilson wrote:
>> Fixes regression from
>> commit f1afe24f0e736b9d7f2275e2b1504af3fe612f2a
>> Author: Arun Siluvery
>> Date: Tue Aug 4 16:22:20 2015 +0100
>>
>> drm/i915: Change SRM, LRM instructions to use correct length
>>
>> which forgo
Having flushed all requests from all queues, we know that all
ringbuffers must now be empty. However, since we do not reclaim
all space when retiring the request (to prevent HEADs colliding
with rapid ringbuffer wraparound) the amount of available space
on each ringbuffer upon reset is less than wh
A small, very small, step to sharing the duplicate code between
execlists and legacy submission engines, starting with the ringbuffer
allocation code.
Signed-off-by: Chris Wilson
Cc: Arun Siluvery
Cc: Mika Kuoppala
Cc: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c| 49 +
Reviewed-by: Sonika Jindal
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Kumar, Mahesh
Sent: Thursday, September 3, 2015 4:17 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Avoid using un-initialize
Reviewed-by: Sonika Jindal
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Kumar, Mahesh
Sent: Thursday, September 3, 2015 4:17 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Add YUV pixel format in
To make kernel-doc happy, the i915_audio_component_audio_ops struct
cannot be nested.
Signed-off-by: David Henningsson
---
Note that I didn't do the same un-nesting for i915_audio_component_ops.
This is to make it easier to merge the pending sync_audio_rate patch set.
It applies on top of my ju
On Wed, Sep 02, 2015 at 03:19:25PM -0700, Rodrigo Vivi wrote:
> Unless future specs tells otherwise we can assume future gens
> inherit some stuff from the previous so let's handle
> missed cases when we know tehy should't be there and assume
> default equals newest one.
>
> No functional changes.
On Thu, Sep 03, 2015 at 10:33:44AM +0300, Jani Nikula wrote:
> On Thu, 03 Sep 2015, "Xie, William" wrote:
> > We suspect watermark has problem in kernel 3.14,
> > Does anyone have a new watermark patch for 3.14 similar as below patch:
> > http://patchwork.freedesktop.org/bundle/anderco/matt-waterm
GEN >= 9 supports YUV format for all planes, but it's not exported in
Capability list of primary plane. Add YUV formats in skl_primary_formats
list.
Testcase: igt/kms_universal_plane.c
Signed-off-by: Kumar, Mahesh
Cc: Konduru, Chandra
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file c
Don't rely on fb->bits_per_pixel as intel_framebuffer_init is not
filling bits_per_pixel field of fb-struct for YUV pixel format.
This leads to divide by zero error during watermark calculation.
Signed-off-by: Kumar, Mahesh
Cc: Konduru, Chandra
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 fil
On Thu, 03 Sep 2015, Takashi Iwai wrote:
> Argh, that's bad. Could you post incremental patches to correct to
> v5?
>
> At the next time please put revision number in the patch itself, not
> only in cover letter. You can do it with --subject-prefix option of
> git-format-patch.
FWIW you can als
On 02/09/2015 12:29, Chris Wilson wrote:
Fixes regression from
commit f1afe24f0e736b9d7f2275e2b1504af3fe612f2a
Author: Arun Siluvery
Date: Tue Aug 4 16:22:20 2015 +0100
drm/i915: Change SRM, LRM instructions to use correct length
which forgot to account for the length bias when declarin
On 2015-09-03 10:31, Takashi Iwai wrote:
On Thu, 03 Sep 2015 09:52:00 +0200,
David Henningsson wrote:
On 2015-08-28 19:02, David Henningsson wrote:
Hopefully last version? :-)
* Added commit text about duplicate events (patch 4/4)
* Added locks in bind/unbind on i915 side (patch 2/4
On Wed, 2015-09-02 at 16:14 +0200, Maarten Lankhorst wrote:
> Op 02-09-15 om 16:07 schreef Ander Conselvan De Oliveira:
> > On Thu, 2015-08-27 at 13:13 +0200, Maarten Lankhorst wrote:
> > > connector->encoder is initialized as NULL. Fix this by setting it in
> > > during pre enable. MST connectors
All tests require ppgtt, so checking for it later on has no effect.
Signed-off-by: Thomas Wood
---
tests/gem_storedw_loop.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
index 1bb276e..08a6ad6 100644
--- a/tests/gem_
Signed-off-by: Thomas Wood
---
tests/gem_storedw_loop.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
index 2263397..1bb276e 100644
--- a/tests/gem_storedw_loop.c
+++ b/tests/gem_storedw_loop.c
@@ -144,6 +144
On Thu, 03 Sep 2015 09:52:00 +0200,
David Henningsson wrote:
>
>
>
> On 2015-08-28 19:02, David Henningsson wrote:
> > Hopefully last version? :-)
> >
> > * Added commit text about duplicate events (patch 4/4)
> > * Added locks in bind/unbind on i915 side (patch 2/4)
> > * Fixed docbook co
On 9/2/2015 2:43 PM, Daniel Vetter wrote:
On Thu, Aug 27, 2015 at 02:18:32PM +0530, Sivakumar Thulasimani wrote:
From: "Thulasimani,Sivakumar"
This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.
This will allow both detection o
On Tue, 01 Sep 2015, Daniel Vetter wrote:
> On Thu, Aug 27, 2015 at 01:25:37PM +0300, Jani Nikula wrote:
>> No functional changes.
>>
>> Signed-off-by: Jani Nikula
>
> Merged the first 2 patches to dinq (rebased on top of the drm dp helper as
> the series originally did). But can't merge more si
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915
The remaining patches from [1] rebased on top of current nightly for
convenience. Just s/intel_dp_tps3_supported/drm_dp_tps3_supported/g.
BR,
Jani.
[1] http://mid.gmane.org/1440671138-17174-1-git-send-email-jani.nik...@intel.com
Jani Nikula (3):
drm/i915/dp: move TPS3 logic to where it's used
TPS3 is mandatory for downstream devices that support HBR2, and Intel
platforms that support HBR2 also support TPS3. Whenever TPS3 is
supported by both the source and sink, it should be used. In other
words, whenever the source and sink are capable of 5.4 Gbps link, we
should anyway go for TPS3, re
There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 31 +--
drivers/gpu/drm/i
On 2015-08-28 19:02, David Henningsson wrote:
Hopefully last version? :-)
* Added commit text about duplicate events (patch 4/4)
* Added locks in bind/unbind on i915 side (patch 2/4)
* Fixed docbook comments in i915 struct (patch 1/4)
* Removed port_mst_streaming parameter (patch 1/4)
On Thu, Aug 27, 2015 at 05:23:29PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> A address-only I2C_WRITE can't be replied with a short i2c ack, but I
> suppose it could be replied with an i2c defer. So the code should be
> prepared for an address-only I2C_WRITE_STATUS_UPD
On Thu, 03 Sep 2015, yu@intel.com wrote:
> From: Alex Dai
>
> By using information from GuC css header, we can eliminate some
> hard code w.r.t size of some components of firmware.
>
> Signed-off-by: Alex Dai
> ---
> drivers/gpu/drm/i915/intel_guc.h| 2 +-
> drivers/gpu/drm/i915/int
On Thu, 03 Sep 2015, "Xie, William" wrote:
> We suspect watermark has problem in kernel 3.14,
> Does anyone have a new watermark patch for 3.14 similar as below patch:
> http://patchwork.freedesktop.org/bundle/anderco/matt-watermarks/
Obviously can't speak for everyone out there, but the educated
74 matches
Mail list logo
