On Wed, 2014-02-19 at 21:20 -0500, Josh Boyer wrote:
> We've had a rather weird report[1] of the brightness adjustments being
> broken in a specific case with Thinkpad x220 hardware (SandyBridge
> based). If you boot the machine with it in a dock and then undock,
> the brightness adjustments do no
RC6 works a lot like HW contexts in that when the GPU enters RC6 it
saves away the state to a context, and loads it upon wake.
It's to be somewhat expected that BIOS will not set up valid GPU state.
As a result, if loading bad state can cause the GPU to get angry, it
would make sense then that we
Everything should be lined up now to make gen8 semaphores work like they
did on previous generations, so just do it.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i91
This appears to not actually be needed on the current code. Just putting
it on the ML so we can point bug reports at it later.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.
Simple debugfs file to display the current state of semaphores. This is
useful if you want to see the state without hanging the GPU.
NOTE: This patch is optional to the series.
NOTE2: Like the GPU error state collection, the reads are currently
incoherent.
Signed-off-by: Ben Widawsky
---
drive
Since the semaphore information is in an object, just dump it, and let
the user parse it later.
NOTE: The page being used for the semaphores are incoherent with the
CPU. No matter what I do, I cannot figure out a way to read anything but
0s. Note that the semaphore waits are indeed working.
v2: D
This abstraction again is in preparation for gen8. Gen8 will bring new
semantics for doing this operation.
While here, make the writes of MI_NOOPs explicit for non-existent rings.
This should have been implicit before.
NOTE: This is going to be removed in a few patches.
Reviewed-by: Ville Syrjäl
This will be helpful in abstracting some of the code in preparation for
gen8 semaphores.
v2: Move mbox stuff to a separate struct
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 10 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +--
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gpu_error.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index bcab114..2b64493 100644
--- a/drivers/gpu/
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've opted for, which should
be fairly future proof. Ie. I tried to define
With the ring mask we now have an easy way to know the number of rings
in the system, and therefore can accurately predict the number of dwords
to emit for semaphore signalling. This was not possible (easily)
previously.
There should be no functional impact, simply fewer instructions emitted.
Whi
Gen8 has already had some differentiation with how it handles rings.
Semaphores bring yet more differences, and now is as good a time as any
to do the split.
Also, since gen8 doesn't actually use semaphores up until this point,
put the proper "NULL" values in for the mbox info.
v2: v1 had a stale
Add_request has always contained both the semaphore mailbox updates as
well as the breadcrumb writes. Since the semaphore signal is the one
which actually knows about the number of dwords it needs to emit to the
ring, we move the ring_begin to that function. This allows us to remove
the hideously s
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update macros to not require the other ring's ring->id (Chris)
Signed-off-
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3d5dd4a..5f7bee8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/
This cleanup is similar to the GEN8 cleanup (though less necessary).
Having everything split will make cleaning the initialization path error
paths easier to understand.
Reviewed-by: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 26 +++---
Like cleanup in an earlier patch, the code becomes much more readable,
and easier to extend if we extract out helper functions for the various
stages of init.
Note that with this patch it becomes really simple, and tempting to begin
using the 'goto out' idiom with explicit free/fini semantics. I'v
The previous allocation mechanism would get 2 contiguous allocations,
one for the page directories, and one for the page tables. As each page
table is 1 page, and there are 512 of these per page directory, this
goes to 2MB. An unfriendly request at best. Worse still, our HW now
supports 4 page dire
Simply to match the GEN8 style of PPGTT initialization, split up the
allocations and mappings. Unlike GEN8, we skip a separate dma_addr_t
allocation function, as it is much simpler pre-gen8.
With this code it would be easy to make a more general PPGTT
initialization function with per GEN alloc/map
GEN8 never freed the PPGTT struct. As GEN8 doesn't use full PPGTT, the
leak is small and only found on a module reload. ie. I don't think this
needs to go to stable.
Reported-by: Ville Syrjälä
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
1 file changed, 1 insertion
This patch converts insert_entries and clear_range, both functions which
are specific to the VM. These functions tend to encapsulate the gen
specific PTE writes. Passing absolute addresses to the insert_entries,
and clear_range will help make the logic clearer within the functions as
to what's goin
This reverts commit 3a2ffb65eec6dbda2fd8151894f51c18b42c8d41.
Now that the code is fixed to use smaller allocations, it should be safe
to let the full GGTT be used on DW.
The testcase for this is anything which uses more than half of the GTT,
thus eclipsing the old limit.
With pre-requisite patc
I keep meaning to do this... by now almost the entire file has been
written by an Intel employee (including Daniel post-2010).
Reviewed-by: Imre Deak
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915
Create 3 clear stages in PPGTT init. This will help with upcoming
changes be more readable. The 3 stages are, allocation, dma mapping, and
writing the P[DT]Es
One nice benefit to the patches is that it makes 2 very clear error
points, allocation, and mapping, and avoids having to do any handling
a
Thanks to Imre's very detailed review, and Ville's observation of a
missed free (earlier bug), I think the series is finally starting to
shape up. I am having some unrelated problems on my BDW platform at the
moment, so they are not well tested.
Many patches are way past v2, but for th series it's
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, February 19, 2014 7:30 PM
> > > > Is there a 1:1 mapping between these connector nodes and ports of
> > > > Gfx
> > > display engine?
> > > > Eg. For Haswell Ultrabook, under
> > > > /sys/d
This got lost when we shuffled around our internal branch and
GEN7_FEATURES macro. There were no HW changes to support FBC, so we just
need to set the flag.
Cc: Daisy Sun
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/driver
Hi All,
We've had a rather weird report[1] of the brightness adjustments being
broken in a specific case with Thinkpad x220 hardware (SandyBridge
based). If you boot the machine with it in a dock and then undock,
the brightness adjustments do not work. That is with either the FN
keys or the GNOM
On Wed, 2014-02-19 at 14:40 -0800, Ben Widawsky wrote:
> On Wed, Feb 19, 2014 at 11:50:51PM +0200, Imre Deak wrote:
> > On Wed, 2014-02-19 at 12:09 -0800, Ben Widawsky wrote:
> > > Like cleanup in an earlier patch, the code becomes much more readable,
> > > and easier to extend if we extract out he
On Wed, Feb 19, 2014 at 11:50:51PM +0200, Imre Deak wrote:
> On Wed, 2014-02-19 at 12:09 -0800, Ben Widawsky wrote:
> > Like cleanup in an earlier patch, the code becomes much more readable,
> > and easier to extend if we extract out helper functions for the various
> > stages of init.
> >
> > Not
On Wed, 2014-02-19 at 12:09 -0800, Ben Widawsky wrote:
> Like cleanup in an earlier patch, the code becomes much more readable,
> and easier to extend if we extract out helper functions for the various
> stages of init.
>
> Note that with this patch it becomes really simple, and tempting to begin
On Wed, Feb 19, 2014 at 11:20:51PM +0200, Imre Deak wrote:
> On Wed, 2014-02-19 at 13:06 -0800, Ben Widawsky wrote:
> > On Wed, Feb 19, 2014 at 09:11:46PM +0200, Imre Deak wrote:
> > > On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> > > > The previous allocation mechanism would get 2 conti
On Wed, 2014-02-19 at 13:06 -0800, Ben Widawsky wrote:
> On Wed, Feb 19, 2014 at 09:11:46PM +0200, Imre Deak wrote:
> > On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> > > The previous allocation mechanism would get 2 contiguous allocations,
> > > one for the page directories, and one for
On Wed, Feb 19, 2014 at 11:00:17PM +0200, Imre Deak wrote:
> On Wed, 2014-02-19 at 12:06 -0800, Ben Widawsky wrote:
> > Create 3 clear stages in PPGTT init. This will help with upcoming
> > changes be more readable. The 3 stages are, allocation, dma mapping, and
> > writing the P[DT]Es
> >
> > One
V2: edit the commit message to contain more info
The W/A spreadsheet says this is still required, but the b-spec says
it's not for BYT-T. So the documentation is not clear. However,
our experience with the other SKUs of BYT-I/M on Android and Linux
suggests that setting this bit actually causes
On Wed, Feb 19, 2014 at 09:11:46PM +0200, Imre Deak wrote:
> On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> > The previous allocation mechanism would get 2 contiguous allocations,
> > one for the page directories, and one for the page tables. As each page
> > table is 1 page, and there ar
On Wed, 2014-02-19 at 12:06 -0800, Ben Widawsky wrote:
> Create 3 clear stages in PPGTT init. This will help with upcoming
> changes be more readable. The 3 stages are, allocation, dma mapping, and
> writing the P[DT]Es
>
> One nice benefit to the patches is that it makes 2 very clear error
> poin
Like cleanup in an earlier patch, the code becomes much more readable,
and easier to extend if we extract out helper functions for the various
stages of init.
Note that with this patch it becomes really simple, and tempting to begin
using the 'goto out' idiom with explicit free/fini semantics. I'v
Create 3 clear stages in PPGTT init. This will help with upcoming
changes be more readable. The 3 stages are, allocation, dma mapping, and
writing the P[DT]Es
One nice benefit to the patches is that it makes 2 very clear error
points, allocation, and mapping, and avoids having to do any handling
a
On Wed, 2014-02-19 at 21:11 +0200, Imre Deak wrote:
> On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> > The previous allocation mechanism would get 2 contiguous allocations,
> > one for the page directories, and one for the page tables. As each page
> > table is 1 page, and there are 512 o
On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> I keep meaning to do this... by now almost the entire file has been
> written by an Intel employee (including Daniel post-2010).
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
> 1 file changed, 1 inserti
On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> This reverts commit 3a2ffb65eec6dbda2fd8151894f51c18b42c8d41.
>
> Now that the code is fixed to use smaller allocations, it should be safe
> to let the full GGTT be used on DW.
>
> The testcase for this is anything which uses more than half
On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> The previous allocation mechanism would get 2 contiguous allocations,
> one for the page directories, and one for the page tables. As each page
> table is 1 page, and there are 512 of these per page directory, this
> goes to 1MB. An unfriendl
On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> This patch converts insert_entries and clear_range, both functions which
> are specific to the VM. These functions tend to encapsulate the gen
> specific PTE writes. Passing absolute addresses to the insert_entries,
> and clear_range will hel
On Thu, Feb 13, 2014 at 01:47:57PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 12, 2014 at 02:28:43PM -0800, Ben Widawsky wrote:
> > Rebased series from what I submitted a while ago:
> > http://lists.freedesktop.org/archives/intel-gfx/2013-December/037815.html
> >
> > It was mostly a clean rebase, b
On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> Like cleanup in an earlier patch, the code becomes much more readable,
> and easier to extend if we extract out helper functions for the various
> stages of init.
>
> Note that with this patch it becomes really simple, and tempting to begin
From: Mika Kuoppala
When we get control from BIOS there might be mt forcewake
bits already set. Apparently double write into mt forcewake
without proper clear/ack sequence in between will cause
system hang.
Fix this by clearing mt forcewake register on init,
like we do with older gens.
Signed-o
From: Mika Kuoppala
as they don't exists.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 25ceac4..cfb8011 10064
On Wed, 2014-02-12 at 14:28 -0800, Ben Widawsky wrote:
> Create 3 clear stages in PPGTT init. This will help with upcoming
> changes be more readable. The 3 stages are, allocation, dma mapping, and
> writing the P[DT]Es
>
> One nice benefit to the patches is that it makes 2 very clear error
> poin
That was a slip-up. All sound with EDID retrieval test - no need to skip it,
just tested it.
Thanks.
-Original Message-
From: Lespiau, Damien
Sent: Wednesday, February 19, 2014 2:46 PM
To: Santos, Joao
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] build: Skip kms_p
On Wed, Feb 19, 2014 at 02:19:19PM +, joao.san...@intel.com wrote:
> From: Joao Santos
>
> Skipping this test until we have Cairo in the build.
>
> Signed-off-by: Joao Santos
Thanks for the patch, pushed. Any more news on the EDID retrieval
script?
--
Damien
_
From: Joao Santos
Skipping this test until we have Cairo in the build.
Signed-off-by: Joao Santos
---
tests/Android.mk |1 +
1 file changed, 1 insertion(+)
diff --git a/tests/Android.mk b/tests/Android.mk
index 30be4a6..3069819 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -32,6
On Wed, 2014-02-19 at 14:35 +0200, Ville Syrjälä wrote:
> On Tue, Feb 18, 2014 at 12:02:09AM +0200, Imre Deak wrote:
> > The connector detect and get_mode handlers need to access the port
> > specific HW blocks to read the EDID etc. Get/put the port power domains
> > around these handlers.
> >
> >
On Tue, Feb 18, 2014 at 12:02:09AM +0200, Imre Deak wrote:
> The connector detect and get_mode handlers need to access the port
> specific HW blocks to read the EDID etc. Get/put the port power domains
> around these handlers.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_crt.c
On Tue, Feb 18, 2014 at 12:02:20AM +0200, Imre Deak wrote:
> Based on an early draft from Jesse.
>
> Add support for powering on/off the dynamic power wells on VLV by
> registering its display and dpio dynamic power wells with the power
> domain framework.
>
> For now power on all PHY TX lanes re
On Wed, Feb 19, 2014 at 09:08:39AM +, Lin, Mengdong wrote:
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, February 18, 2014 10:23 PM
> > To: Lin, Mengdong
> > Cc: Daniel Vetter; Takashi Iwai; alsa-de...@alsa-project.org; Barnes,
On Wed, Feb 19, 2014 at 09:33:11AM +, Goel, Akash wrote:
> Thanks for your inputs.
>
> Actually for our use cases, the 'scaling_mode' property currently being used
> for 'lvds' & 'dp', cannot be used as it is.
>
> For our use cases, we need to provide a fine level control to User, so as to
On Tue, Feb 18, 2014 at 07:23:13PM -0300, Paulo Zanoni wrote:
> 2014-02-18 18:34 GMT-03:00 Paulo Zanoni :
> > 2014-02-18 16:25 GMT-03:00 Mika Kuoppala :
> >> Chris Wilson writes:
> >>
> >>> We currently call intel_mark_idle() too often, as we do so as a
> >>> side-effect of processing the request
Reviewed-by: Sagar Kamble
On Wed, 2014-02-12 at 23:15 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We can pretend that we can rotate the entire pipe by rotating all the
> planes and adjusting their positions appropriately. Add a "rotation"
> property on the crtc which w
From: Sagar Kamble
With this patch two properties are added. One for CRTC+Sprite planes
and another for Cursor planes. Through these client will be able to
change the pixel format of the planes w.r.t Alpha channel.
Number of drm properties are limited so should we restrain from adding this
as drm
Thanks for your inputs.
Actually for our use cases, the 'scaling_mode' property currently being used
for 'lvds' & 'dp', cannot be used as it is.
For our use cases, we need to provide a fine level control to User, so as to be
able to choose the LetterBox/Pillar-box modes & also the Manual mode w
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, February 18, 2014 10:23 PM
> To: Lin, Mengdong
> Cc: Daniel Vetter; Takashi Iwai; alsa-de...@alsa-project.org; Barnes, Jesse;
> Zanoni, Paulo R; dri-devel; intel-gfx@lists.freedesktop.org
> Su
On 02/19/2014 03:33 PM, Matthew Garrett wrote:
> On Wed, Feb 19, 2014 at 03:31:29PM +0800, Aaron Lu wrote:
>
>> DID2 is in system memory region and has some assigned value like 0x400
>> when we read it. For this case it is easy since there is only one output
>> device that is of type LVDS so we ca
On Wed, Feb 19, 2014 at 06:13:53AM +, Goel, Akash wrote:
>
> Hello,
>
> We are planning to expose a new panel fitter property for the connectors.
> We have some use cases like a full screen video playback, where we can flip
> the frame buffer of any size irrespective of the pipe timings an
64 matches
Mail list logo
