The docs say you cannot change the PDEs of a currently running context. If you
are changing the PDEs of the currently running context then. We never
map new PDEs of a running context, and expect them to be present - so I
think this is okay. (We can unmap, but this should also be okay since we
only
This patch continues on the idea from the previous patch. From here on,
in the steady state, PDEs are all pointing to the scratch page table (as
recommended in the spec). When an object is allocated in the VA range,
the code will determine if we need to allocate a page for the page
table. Similarly
Having a more general way of doing mappings will allow the ability to
easy map and unmap a specific page table. Specifically in this case, we
pass down the page directory + entry, and the page table to map. This
works similarly to the x86 code.
The same work will need to happen for GEN8. At that p
We have some fanciness coming up. This patch just breaks out the logic.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_ge
Start using size/length through the GEN8 code. The same approach was
taken for gen7. The difference with gen8 to this point is we need to
take care to the do the page directory allocations, as well as the page
tables.
This patch is meant to show how things will look (more or less) if I
keep up in
Move the remaining members over to the new page table structures.
This can be squashed with the previous commit if desire. The reasoning
is the same as that patch. I simply felt it is easier to review if split.
Signed-off-by: Ben Widawsky
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
There is never a case where we don't want to do it. Since we've broken
up the allocations into nice clean helper functions, it's both easy and
obvious to do the dma mapping at the same time.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 78
Instead of implementing the full tracking + dynamic allocation, this
patch does a bit less than half of the work, by tracking and warning on
unexpected conditions. The tracking itself follows which PTEs within a
page table are currently being used for objects. The next patch will
modify this to act
Map and unmap are common operations across all generations for
pagetables. With a simple helper, we can get a nice net code reduction
as well as simplified complexity.
There is some room for optimization here, for instance with the multiple
page mapping, that can be done in one pci_map operation.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5f3666a..04d40fa 100644
--- a/drivers/gpu/drm/i915/i915_debu
With a little bit of macro magic, and the fact that every page
table/dir/etc. we wish to map will have a page, and daddr member, we can
greatly simplify and reduce code.
The patch introduces an i915_dma_map/unmap which has the same semantics
as pci_map_page, but is 1 line, and doesn't require newl
The current code will both potentially print a WARN, and setup part of
the PPGTT structure. Neither of these harm the current code, it is
simply for clarity, and to perhaps prevent later bugs, or weird
debug messages.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 -
TODO: Do header files need a copyright?
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 162 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 57 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 225
3 files changed, 227
Split out single mappings which will help with upcoming work. Also while
here, rename the function because it is a better description - but this
function is going away soon.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 ++---
1 file cha
Upcoming patches will use the terms map and unmap in references to the
page table entries. Having this distinction will really help with code
clarity at that point.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions
The actual correct way to think about this with the new style of page
table data structures is as the actual entry that is being indexed into
the array. "pd", and "pt" aren't representative of what the operation is
doing.
The clarity here will improve the readability of future patches.
Signed-off
Similar to the patch a few back in the series, we can always map and
unmap page directories when we do their allocation and teardown. Page
directory pages only exist on gen8+, so this should only effect behavior
on those platforms.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gt
These patches live here, based on my temporary Broadwell branch:
http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=dynamic_pt_alloc
First, and most importantly, this work should have no impact on current
drm-intel code because PPGTT is currently shut off there. To actually
test this patch ser
The old code (I'm having trouble finding the commit) had a reason for
doing things when there was an error, and would continue on, thus the
!ret. For the newer code however, this looks completely silly.
Follow the normal idiom of if (ret) return ret.
Also, put the pde wiring in the gen specific i
As we move toward dynamic page table allocation, it becomes much easier
to manage our data structures if break do things less coarsely by
breaking up all of our actions into individual tasks. This makes the
code easier to write, read, and verify.
Aside from the dissection of the allocation functi
These page table helpers make the code much cleaner. There is some
room to use the arch/x86 header files. The reason I've opted not to is
in several cases, the definitions are dictated by the CONFIG_ options
which do not always indicate the restrictions in the GPU. While here,
clean up the defines
Thus far we've opted to make complex code requiring difficult review. In
the future, the code is only going to become more complex, and as such
we'll take the hit now and start to encapsulate things.
To help transition the code nicely there is some wasted space in gen6/7.
This will be ameliorated
This will be useful for some upcoming patches which do more platform
specific work. Having it in one central place just makes things a bit
cleaner and easier.
There is a small functional change here. There are more calls to the
tracepoints.
NOTE: I didn't actually end up using this patch for the
This patch existed for another reason which no longer exists. I liked
it, so I kept it in the series. It can skipped if undesirable.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
di
trivial.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b3e31fd..084e82f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm
There often is not enough memory to dump the full contents of the PPGTT.
As a temporary bandage, to continue getting valuable basic PPGTT info,
wrap the dangerous, memory hungry part inside of a new verbose version
of the debugfs file.
Also while here we can split out the ppgtt print function so i
Therefore we can do it from our general init function. Eventually, I
hope to have a lot more commonality like this. It won't arrive yet, but
this was a nice easy one.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
di
From: Rob Bradford
This test has the following subtests:
- test_correct for correctness of the data
- test_map_unmap checks for mapping idempotency
- test_reprime checks for dma-buf creation idempotency
- test_forked checks for multiprocess access
- test_refcounting checks for buffer reference co
This function is only used on ILK+, so rename it accordingly.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6dbaf66..47bf433 100644
No need of any here.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d34add5..c6743f0 100644
--- a/drivers/gpu/drm
In the future, we'll need the height of the fb we're fetching from
memory for WM computation.
At some point in the future, it'd be nice to give a pointer to a
mystical plane_config structure instead of chaplet of parameters.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.h
Jani Nikula writes:
> Here's two patches to try, separately, *without* the quirk: [...]
Okay, I've tried both and neither works. However, I've noticed that
while the backlight level never changes even though I'm changing it with
Fn+F4/Fn+F5, it *does* get registered somewhere because if I bring
To gain more coverage on interface, default context and banning.
As there is no proper reset support for gen <= 3, we only
do limited interface testing on those.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 91 ++-
1 file changed, 75 in
Jani Nikula writes:
> Please file a new bug on DRM/Intel component at [1]. Please attach
> intel_reg_dumper output (tool from intel-gpu-tools [2]) with and without
> the revert. Please also attach dmesg with drm.debug=0xe from early
> boot.
Done, https://bugs.freedesktop.org/show_bug.cgi?id=7627
Hi Daniel,
Daniel Vetter writes:
> Please never just send a mail to maintainers, always cc mailing lists.
Yes, sorry, I sent this privately because it wasn't a fully-formed bug
report; I just wanted Jani to confirm that it wasn't intentionally
broken as of -rc7.
> Have you tested with the patc
On Mon, Mar 17, 2014 at 04:43:36PM +0200, Jani Nikula wrote:
> This is a small follow-up fix to the series of eDP VDD back and forth
> we've had recently. This is effectively a combined revert of three
> commits:
>
> commit 2c2894f698fffd8ff53e1e1d3834f9e1035b1f39
> Author: Paulo Zanoni
> Date:
On Mon, Mar 17, 2014 at 5:17 PM, Woodhouse, David
wrote:
> I think I have found this problem on the IOMMU side. We usually assume
> that RMRRs are for boot-time only, such as USB controllers for the
> legacy keyboard/mouse emulation. And a patch sneaked in which
> effectively *unmaps* the RMRR reg
On Mon, 17 Mar 2014, Romain Francoise wrote:
> Hi Daniel,
>
> Daniel Vetter writes:
>
>> Please never just send a mail to maintainers, always cc mailing lists.
>
> Yes, sorry, I sent this privately because it wasn't a fully-formed bug
> report; I just wanted Jani to confirm that it wasn't intenti
Several places (such as intel_cache_expire) call intel_emit_batch_flush,
so it needs to work on Broadwell. Sometimes the batch is empty, in
which case current_batch may not yet be BLT_RING.
The PIPE_CONTROL code has not been ported to work on Broadwell, so
trying to do a render ring flush will ha
On Mon, 2014-03-17 at 16:17 +, David Woodhouse wrote:
>
> Can't tell though, because my machine is still dying in an endless
> stream of
> [ 199.647850] [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR*
> Interrupt arrived before CRTCs were setup up
Except when the failure mode is differen
On Fri, 2014-03-14 at 23:10 +0100, Daniel Vetter wrote:
>
> I've asked you on private irc whether this range matches/overlaps with
> stolen - we know of things blowing up at least on earlier generations
> in combination with dmar. Please boot with drm.debug=0xe and scan for
> the stolen mem report
On Mon, 17 Mar 2014, Jani Nikula wrote:
> On Mon, 17 Mar 2014, Romain Francoise wrote:
>> Hi Daniel,
>>
>> Daniel Vetter writes:
>>
>>> Please never just send a mail to maintainers, always cc mailing lists.
>>
>> Yes, sorry, I sent this privately because it wasn't a fully-formed bug
>> report; I
On Mon, 17 Mar 2014, Romain Francoise wrote:
> Hi Daniel,
>
> Daniel Vetter writes:
>
>> Please never just send a mail to maintainers, always cc mailing lists.
>
> Yes, sorry, I sent this privately because it wasn't a fully-formed bug
> report; I just wanted Jani to confirm that it wasn't intenti
On Mon, 17 Mar 2014, Rodrigo Vivi wrote:
> On Mon, Mar 17, 2014 at 11:08 AM, Rodrigo Vivi wrote:
>> On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
>>> - if (!intel_dp_aux_native_read(intel_dp, DP_TEST_SINK_MISC, buf, 1))
>>> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_
On Mon, Mar 17, 2014 at 11:08 AM, Rodrigo Vivi wrote:
> On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
>> Functionality remains largely the same as before.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 257
>> +-
>> dri
On Mon, 17 Mar 2014, Rodrigo Vivi wrote:
> I would prefer an else instead of unecessary comparisons and
> assignment that will be override..
In general I agree, but see next patch. ;)
BR,
Jani.
>
> But anyway it works, so feel free to use:
> Reviewed-by: Rodrigo Vivi
>
> On Fri, Mar 14, 2014
forgot to say that this patch needs a rebase on -nightly
On Mon, Mar 17, 2014 at 11:09 AM, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
>> Introduce _edp_panel_vdd_on() that returns true if the call enabled vdd,
>> and a matching disab
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
> The functionality remains largerly the same. The main difference is that
> i2c-over-aux defer timeouts are increased to be safe for all use cases
> instead of depending on DP device type and properties.
I was going to ask about different time
This is a small follow-up fix to the series of eDP VDD back and forth
we've had recently. This is effectively a combined revert of three
commits:
commit 2c2894f698fffd8ff53e1e1d3834f9e1035b1f39
Author: Paulo Zanoni
Date: Fri Mar 7 20:05:20 2014 -0300
drm/i915: properly disable the VDD when
This reverts
commit dff392dbd258381a6c3164f38420593f2d291e3b
Author: Paulo Zanoni
Date: Fri Dec 6 17:32:41 2013 -0200
drm/i915: don't touch the VDD when disabling the panel
which didn't take into account
commit 6cb49835da0426f69a2931bc2a0a8156344b0e41
Author: Daniel Vetter
Date: Sun Ma
I would prefer an else instead of unecessary comparisons and
assignment that will be override..
But anyway it works, so feel free to use:
Reviewed-by: Rodrigo Vivi
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
> Do a slight rearrangement of the switch to prep for follow-up.
>
> Signed-of
Reviewed-by: Rodrigo Vivi
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
> Introduce _edp_panel_vdd_on() that returns true if the call enabled vdd,
> and a matching disable is needed. Keep edp_panel_vdd_on() as a helper
> for when it is expected the vdd is off.
>
> Signed-off-by: Jani Niku
Reviewed-by: Rodrigo Vivi
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
> This is prep work for conversion to generic drm i2c-over-aux helpers
> where we won't have the function to do this at.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c |9 ++---
> 1 f
Reviewed-by: Rodrigo Vivi
//Although I know it has been already reviewed ;)
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
> Let the drivers specify the name of the I2C-over-AUX adapter to maintain
> backwards compatibility in the sysfs when converting to the new
> I2C-over-AUX helper inf
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula wrote:
> Functionality remains largely the same as before.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 257
> +-
> drivers/gpu/drm/i915/intel_drv.h |1 +
> 2 files changed, 116 i
On Mon, Mar 17, 2014 at 01:17:32PM +, Chris Wilson wrote:
> On Sat, Mar 15, 2014 at 11:30:18AM -0700, Ben Widawsky wrote:
> > On Sat, Mar 15, 2014 at 03:20:23PM +, Chris Wilson wrote:
> > > On Sat, Mar 15, 2014 at 12:47:22PM +0100, Daniel Vetter wrote:
> > > > On Fri, Mar 14, 2014 at 05:21:
Please never just send a mail to maintainers, always cc mailing lists.
On Mon, Mar 17, 2014 at 2:33 PM, Romain Francoise wrote:
> Moving from v3.13 to v3.14-rc7 breaks backlight control on my Dell
> XPS13, which I assume is because of this change:
>
> http://git.kernel.org/linus/bc0bb9fd1c7810407
On Sat, Mar 15, 2014 at 11:30:18AM -0700, Ben Widawsky wrote:
> On Sat, Mar 15, 2014 at 03:20:23PM +, Chris Wilson wrote:
> > On Sat, Mar 15, 2014 at 12:47:22PM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 14, 2014 at 05:21:36PM -0700, Ben Widawsky wrote:
> > > > Broken by:
> > > > commit 0294
On Mon, 2014-03-17 at 12:21 +, Chris Wilson wrote:
> +EXPORT_SYMBOL(interval_tree_insert);
> +EXPORT_SYMBOL(interval_tree_remove);
> +EXPORT_SYMBOL(interval_tree_iter_first);
> +EXPORT_SYMBOL(interval_tree_iter_next);
I'd prefer to see EXPORT_SYMBOL_GPL for this.
--
dwmw2
smime.p7s
Descr
lib/interval_tree.c provides a simple interface for an interval-tree
(an augmented red-black tree) but is only built when testing the generic
macros for building interval-trees. For drivers with modest needs,
export the simple interval-tree library as is.
v2: Lots of help from Michel Lespinasse to
A common issue we have is that retiring requests causes recursion
through GTT manipulation or page table manipulation which we can only
handle at very specific points. However, to maintain internal
consistency (enforced through our sanity checks on write_domain at
various points in the GEM object l
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, w
Hi Dave,
drm-intel-next-2014-03-07:
- fine-grained display power domains for byt (Imre)
- runtime pm prep patches for !hsw from Paulo
- WiZ hashing flag updates from Ville
- ppgtt setup cleanup and enabling of full 4G range on bdw (Ben)
- fixes from Jesse for the inherited intial config code
- gpu
Hi Dave,
Two 3.14 specific fixes, two cc: stable.
I'm afraid I've accumulated a slight backlog of fixes. This pull is to
get the tested stuff out of the way first. I'll be pushing more patches
soon, and will send another pull once our QA has had some time to run
them.
BR,
Jani.
The following
On Mon, Mar 17, 2014 at 11:14:25AM +0200, Jani Nikula wrote:
> On Mon, 17 Mar 2014, Jani Nikula wrote:
> > On Sat, 15 Mar 2014, Ben Widawsky wrote:
> >> Broken by:
> >> commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd
> >> Author: Chris Wilson
> >> Date: Thu Mar 13 12:00:29 2014 +
> >>
> >>
On Mon, 2014-03-10 at 22:07 +, 'Chris Wilson' wrote:
> On Mon, Mar 10, 2014 at 04:12:23PM +, Gupta, Sourab wrote:
> >
> > Hi Chris,
> >
> > For the issue mentioned by you ( regarding botching up ioctls), we
> > understand that this is related to the
> > compatibility between the older/n
On Mon, 17 Mar 2014, Jani Nikula wrote:
> On Sat, 15 Mar 2014, Ben Widawsky wrote:
>> Broken by:
>> commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd
>> Author: Chris Wilson
>> Date: Thu Mar 13 12:00:29 2014 +
>>
>> drm/i915: Consolidate forcewake resetting to a single function
>>
>
> Do
On Mon, Mar 17, 2014 at 12:51:24PM +1000, Dave Airlie wrote:
> Booted drm-next merged into Linus 3.14-rc7 this morning,
>
> got splatted.
>
> Ivybridge, one DP one DVI monitor.
Oh, the infamous. We have a report of these for pretty much all our our hw
platforms up to ivb (I think hsw is fine ac
On Sat, Mar 8, 2014 at 7:49 PM, wrote:
> From: Sagar Kamble
>
> v1: Added 128x128 and 256x256 cursor size support.
>
> v2: Refined the test to use igt_subtest_f and automate enumeration.
>
> Signed-off-by: Sagar Kamble
Hm, do you have an update of this patch to use the drm ioctl to query
the m
On Sat, 15 Mar 2014, Ben Widawsky wrote:
> Broken by:
> commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd
> Author: Chris Wilson
> Date: Thu Mar 13 12:00:29 2014 +
>
> drm/i915: Consolidate forcewake resetting to a single function
>
Does this result in https://bugs.freedesktop.org/show_b
70 matches
Mail list logo
