On 10/9/2015 1:24 AM, Daniel Vetter wrote:
On Thu, Oct 08, 2015 at 05:38:58PM +0300, Jani Nikula wrote:
On Thu, 08 Oct 2015, Ville Syrjälä wrote:
On Mon, Oct 05, 2015 at 04:43:14PM +0530, Sonika Jindal wrote:
For all the encoders, call the hot_plug if it is registered.
This is required for
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-svm.c | 115 +++-
include/linux/intel-iommu.h | 21
2 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 1260e87..ace1
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 22 +-
drivers/iommu/intel-svm.c | 71 +
include/linux/intel-iommu.h | 5
3 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/d
This provides basic PASID support for endpoint devices, tested with a
version of the i915 driver.
A given process can bind to only one device per IOMMU for now. Making
that more generic isn't particularly difficult but isn't needed yet, and
can come later once the basic functionality is stable.
E
If the device itself reports ATS in its PCIe capabilities, but the BIOS
neglects to provide an ATSR structure to indicate that the root port can
also cope, then assume the latter is lying.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 11 ---
1 file changed, 8 insertio
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c| 42 +++---
include/linux/intel-iommu.h | 10 +-
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 8757f8d..80e3c17 100644
-
Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables on supported hardware.
Signed-off-by: David Woodhouse
---
drivers/iommu/Kconfig | 8 ++
drivers/iommu/Makefile | 1 +
drivers/iommu/intel-iommu.c | 14 ++
drivers/iommu/intel-svm.c | 65 +
As long as we use an identity mapping to work around the worst of the
hardware bugs which caused us to defeature it and change the definition
of the capability bit, we *can* use PASID support on the devices which
advertised it in bit 28 of the Extended Capability Register.
Allow people to do so wi
This patch set enables PASID support for the Intel IOMMU, along with
page request support.
Like its AMD counterpart, it exposes an IOMMU-specific API. I believe
we'll have a session at the Kernel Summit later this month in which we
can work out a generic API which will cover the two (now) existing
On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote:
>
> Could someone clarify what this means from the TDR point of view,
> please? When you say "context blew up" I'm guessing that you mean that
> come context caused the fault handler to get involved somehow?
>
> Does this imply that the offend
It's been reported that the atomic watermark series triggers some
regressions on SKL, which we haven't been able to track down yet. Let's
temporarily revert these patches while we track down the root cause.
This commit squashes the reverts of:
76305b1 drm/i915: Calculate watermark configuration
On Thu, Oct 08, 2015 at 09:26:19PM +, Zanoni, Paulo R wrote:
> Em Sex, 2015-08-28 às 17:46 +0300, Ville Syrjälä escreveu:
> > On Fri, Aug 14, 2015 at 06:34:09PM -0300, Paulo Zanoni wrote:
> > > The doc is pretty clear that this register should be set to 0 on
> > > SNB.
> > > We already write y_
On Thu, Oct 01, 2015 at 07:55:57PM -0300, Paulo Zanoni wrote:
> We were considering the whole framebuffer height, but the spec says we
> should only consider the active display height size. There were still
> some unclear questions based on the spec, but the hardware guys
> clarified them for us. A
Em Sex, 2015-08-28 às 17:46 +0300, Ville Syrjälä escreveu:
> On Fri, Aug 14, 2015 at 06:34:09PM -0300, Paulo Zanoni wrote:
> > The doc is pretty clear that this register should be set to 0 on
> > SNB.
> > We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines
> > below.
>
> Bspec says:
> "
From: Chris Wilson
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
Howe
On 09/23/2015 08:52 AM, Paulo Zanoni wrote:
> Technology has evolved and now we have eDP panels with 3200x1800
> resolution. In the meantime, the BIOS guys didn't change the default
> 32mb for stolen memory. On top of that, we can't assume our users will
> be able to increase the default stolen mem
On Thu, Oct 08, 2015 at 05:38:58PM +0300, Jani Nikula wrote:
> On Thu, 08 Oct 2015, Ville Syrjälä wrote:
> > On Mon, Oct 05, 2015 at 04:43:14PM +0530, Sonika Jindal wrote:
> >> For all the encoders, call the hot_plug if it is registered.
> >> This is required for connected boot and resume cases to
In preparation for the upcoming TDR per-engine hang recovery enablement the
stability of the error state capture code needs to be addressed. The biggest
reason for this is that in order to test TDR a long-duration test needs to be
run for several hours during which a large number of hangs is handle
Avoid NULL pointer exceptions in the display driver for certain critical cases
when unpin_work has turned out to be NULL.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu
Grab execlist lock when cleaning up execlist queues after GPU reset to avoid
concurrency problems between the context event interrupt handler and the reset
path immediately following a GPU reset.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c | 5 +
1 file changed, 5 insertions
Using safe list iterators alleviates the problem of unsynchronized driver list
manipulations while error state capture is in the process of traversing lists.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gpu_error.c | 38 +--
1 file changed, 19 insertions
Since we're not synchronizing the ring request list during error state capture
the request list state might change between the time the corresponding error
request list was allocated and dimensioned to the time when the ring request
list is actually captured into the error state. If this happens, t
Error state capture is dependent on i915_gem_active_request() and
i915_gem_obj_is_pinned(). Since there is no synchronization between error state
capture and the driver state we at least need to use safe list iterators in
these functions to alleviate the problem of request/vma lists changing during
When submitting semaphores in execlist mode the hang checker crashes in this
function because it is only runnable in ring submission mode. The reason this
is of particular interest to the TDR patch series is because we use semaphores
as a mean to induce hangs during testing (which is the recommende
Sometimes the iterated vma objects are NULL apparently. Be aware of this while
iterating and do early exit instead of causing a NULL pointer exception.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
In the past vmas have sometimes turned out to be NULL when capturing buffer
objects during error state capture. To avoid NULL pointer exceptions throw a
WARNING and exit early and be prepared for the error state not being fully
accurate following this point.
Signed-off-by: Tomas Elf
---
drivers/
On Tue, Sep 08, 2015 at 02:58:52PM +0200, Christian König wrote:
> Patches #1, #6, #7, #8 and #10 are Reviewed-by: Christian König
> .
>
> That should be everything touching radeon/amdgpu if I missed something leave
> me a note.
Ok with an irc r-b from Chris and David I and yours here I pulled in
On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote:
> On Thu, 2015-10-08 at 11:43 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > EDID detailed timings have a resolution of 10kHz for the pixel clock, so
> > they can't represent certain CEA/HDMI modes accurate
On Thu, Oct 08, 2015 at 05:26:44PM +0100, Tvrtko Ursulin wrote:
>
> On 08/10/15 17:03, Ville Syrjälä wrote:
> > On Thu, Oct 08, 2015 at 03:03:11PM +0100, Tvrtko Ursulin wrote:
> >>
> >> Hi,
> >>
> >> On 08/10/15 14:45, Ville Syrjälä wrote:
> >>> On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Urs
On 08/10/15 17:03, Ville Syrjälä wrote:
On Thu, Oct 08, 2015 at 03:03:11PM +0100, Tvrtko Ursulin wrote:
Hi,
On 08/10/15 14:45, Ville Syrjälä wrote:
On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Prevent leaking VMAs and PPGTT VMs when objects are impo
On Thu, 2015-10-08 at 11:43 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> EDID detailed timings have a resolution of 10kHz for the pixel clock, so
> they can't represent certain CEA/HDMI modes accurately. If we see a mode
> coming in via detailed timings which otherwise ma
Please ignore these two patches. They contain errors and are superseded by a
new patch series I just
sent.
Ander
On Mon, 2015-10-05 at 17:44 +0300, Ander Conselvan de Oliveira wrote:
> Simplify intel_dp_pre_emphasis_max() by grouping the conditions for VLV,
> HSW, BDW and gen 9 together, since t
On 10/08/2015 05:44 AM, Ville Syrjälä wrote:
On Thu, Oct 08, 2015 at 03:39:26PM +0300, Jani Nikula wrote:
On Thu, 08 Oct 2015, Ville Syrjälä wrote:
On Wed, Oct 07, 2015 at 02:38:29PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
The TMDS_296M define was computing as 296704 but
On Thu, Oct 08, 2015 at 03:03:11PM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 08/10/15 14:45, Ville Syrjälä wrote:
> > On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Prevent leaking VMAs and PPGTT VMs when objects are imported
> >> via flink.
On Thu, Oct 08, 2015 at 04:12:31PM +0100, Michel Thierry wrote:
> On 10/8/2015 3:37 PM, Tvrtko Ursulin wrote:
> >From: Tvrtko Ursulin
> >
> >commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
> >Author: Tvrtko Ursulin
> >Date: Mon Oct 5 13:26:36 2015 +0100
> >
> > drm/i915: Clean up associated
On Fri, Sep 04, 2015 at 09:59:00AM -0700, Jesse Barnes wrote:
> New file with VT-d SVM and PASID handling functions and page table
> management. This belongs in the IOMMU code (along with some extra bits
> for waiting for invalidations and page faults to complete, flushing the
> device IOTLB, etc.
On Thu, Oct 08, 2015 at 12:44:09PM +0200, Johannes Stezenbach wrote:
> On Wed, Oct 07, 2015 at 01:26:32PM +0200, Johannes Stezenbach wrote:
> > On Tue, Oct 06, 2015 at 11:04:53PM -0400, Alex Deucher wrote:
> > > On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach
> > > wrote:
> > > >
> > > > I h
On 10/8/2015 3:37 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
Author: Tvrtko Ursulin
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915: Clean up associated VMAs on context destruction
Introduced a wrong assumption that all contexts have a
On Thu, Oct 08, 2015 at 03:31:08PM +0100, Tvrtko Ursulin wrote:
>
> On 08/10/15 12:09, Chris Wilson wrote:
> >On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote:
> >>>-struct drm_i915_gem_object *
> >>>-i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
> >>>+static bool
>
On Thu, Oct 08, 2015 at 12:03:30PM +0100, Damien Lespiau wrote:
> The DMC firmware version decoding was different in my patch and I'm sure
> it worked then. Maye the header has changed :(
By the way, if this is indeed the case, could you fix
intel_firmware_decode as well?
http://cgit.freedeskt
On 10/8/2015 5:53 PM, Mika Kuoppala wrote:
Animesh Manna writes:
On 9/21/2015 2:00 PM, Mika Kuoppala wrote:
Jani Nikula writes:
On Fri, 18 Sep 2015, Mika Kuoppala wrote:
If csr/dmc firmware is known to be outdated, notify
user.
What would break if we requested a firmware version that
On 10/08/2015 02:07 AM, Chris Wilson wrote:
> On Wed, Oct 07, 2015 at 11:34:17AM -0700, Wayne Boyer wrote:
>> From: Chris Wilson
>>
>> A long time ago (before 3.14) we relied on a permanent pinning of the
>> ifbdev to lock the fb in place inside the GGTT. However, the
>> introduction of stealing t
From: Tvrtko Ursulin
commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
Author: Tvrtko Ursulin
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915: Clean up associated VMAs on context destruction
Introduced a wrong assumption that all contexts have a ppgtt
instance. This is not true when full PPGT
On Thu, 08 Oct 2015, Ville Syrjälä wrote:
> On Mon, Oct 05, 2015 at 04:43:14PM +0530, Sonika Jindal wrote:
>> For all the encoders, call the hot_plug if it is registered.
>> This is required for connected boot and resume cases to generate
>> fake hpd resulting in reading of edid.
>> Removing the i
On 08/10/15 12:09, Chris Wilson wrote:
On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote:
-struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
+static bool
+mark_free(struct drm_i915_gem_object *obj, struct list_head *unwind)
+{
+ BUG
On Thu, Oct 08, 2015 at 07:27:59PM +0530, Sudip Mukherjee wrote:
> Use goto to handle the error path to avoid duplicating the same code. In
> the error path intel_dig_port is the last one to be released as it was
> the first one to be allocated and ideally the error path should be the
> reverse of
On Thu, Oct 08, 2015 at 07:28:00PM +0530, Sudip Mukherjee wrote:
> We were not checking the return value of drm_encoder_init() which can
> fail. And if it fails then we will be working with an uninitialized
> encoder.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-off-by: Sudip Mukherjee
Que
Hi,
On 08/10/15 14:45, Ville Syrjälä wrote:
On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Prevent leaking VMAs and PPGTT VMs when objects are imported
via flink.
Scenario is that any VMAs created by the importer will be left
dangling after the importer
We were not checking the return value of drm_encoder_init() which can
fail. And if it fails then we will be working with an uninitialized
encoder.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Sudip Mukherjee
---
Sent on 27/07/2015
drivers/gpu/drm/i915/intel_dp.c | 6 --
1 file change
Hi,
On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface.
This will cover prime objects as well as stolen memory bac
Use goto to handle the error path to avoid duplicating the same code. In
the error path intel_dig_port is the last one to be released as it was
the first one to be allocated and ideally the error path should be the
reverse of the execution path.
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: S
On Thu, Oct 08, 2015 at 02:39:24PM +0100, Chris Wilson wrote:
> I have instances where I want to use drm_malloc_ab() but with a custom
> gfp mask. And with those, where I want a temporary allocation, I want to
> try a high-order kmalloc() before using a vmalloc().
>
> So refactor my usage into drm
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-de...@lists.freedes
On Mon, Oct 05, 2015 at 01:26:36PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Prevent leaking VMAs and PPGTT VMs when objects are imported
> via flink.
>
> Scenario is that any VMAs created by the importer will be left
> dangling after the importer exits, or destroys the PPGTT conte
Huang, please try this patch.
BR,
Jani.
On Tue, 29 Sep 2015, Jani Nikula wrote:
> Also adding Cc: intel-gfx, please include that in follow-ups.
>
> Thanks,
> Jani.
>
> On Tue, 29 Sep 2015, Jani Nikula wrote:
>> Although we don't support or enable CPU PWM with LPT/SPT based systems,
>> it may
On Mon, Oct 05, 2015 at 04:43:14PM +0530, Sonika Jindal wrote:
> For all the encoders, call the hot_plug if it is registered.
> This is required for connected boot and resume cases to generate
> fake hpd resulting in reading of edid.
> Removing the initial sdvo hot_plug call too so that it will be
On Wed, Oct 07, 2015 at 06:05:46PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 03:52:02PM +0100, Nick Hoath wrote:
> > Shovel all context related objects through the active queue and obj
> > management.
> >
> > - Added callback in vma_(un)bind to add CPU (un)mapping at same time
> > if
Hi Chris,
[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please
ignore]
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/intel_ringbu
On Thu, Oct 08, 2015 at 03:58:13PM +0300, Ville Syrjälä wrote:
> > + pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY);
>
> Random driveby: kmalloc_array()
That would be scary, imagine having enough pages in the object to
overflow unsigned long :)
> Also __GFP_NOWARN?
True.
> I wond
On Thu, Oct 08, 2015 at 01:39:55PM +0100, Chris Wilson wrote:
> We now have two implementations for vmapping a whole object, one for
> dma-buf and one for the ringbuffer. If we couple the vmapping into the
> obj->pages lifetime, then we can reuse an obj->vmapping for both and at
> the same time cou
On Thu, Oct 08, 2015 at 03:39:26PM +0300, Jani Nikula wrote:
> On Thu, 08 Oct 2015, Ville Syrjälä wrote:
> > On Wed, Oct 07, 2015 at 02:38:29PM -0700, clinton.a.tay...@intel.com wrote:
> >> From: Clint Taylor
> >>
> >> The TMDS_296M define was computing as 296704 but the mode->clock is
> >> 2967
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the vmapping into the
obj->pages lifetime, then we can reuse an obj->vmapping for both and at
the same time couple it into the shrinker.
Signed-off-by: Chris Wilson
---
drivers/g
Ringbuffers are now being written to either through LLC or WC paths, so
treating them as simply iomem is no longer adequate. However, for the
older !llc hardware, the hardware is documentated as treating the TAIL
register update as serialising, so we can relax the barriers when filling
the rings (b
If we have llc coherency, we can write directly into the ringbuffer
using ordinary cached writes rather than forcing WC access.
v2: An important consequence is that we can forgo the mappable request
for WB ringbuffers, allowing for many more simultaneous contexts.
Signed-off-by: Chris Wilson
---
On Thu, 08 Oct 2015, Ville Syrjälä wrote:
> On Wed, Oct 07, 2015 at 02:38:29PM -0700, clinton.a.tay...@intel.com wrote:
>> From: Clint Taylor
>>
>> The TMDS_296M define was computing as 296704 but the mode->clock is
>> 296700 as defined by EDID. Adjusted define to allow correct detection
>> of t
On Tue, Oct 06, 2015 at 03:52:01PM +0100, Nick Hoath wrote:
> There is a desire to simplify the i915 driver by reducing the number of
> different code paths introduced by the LRC / execlists support. As the
> execlists request is now part of the gem request it is possible and
> desirable to unify
Animesh Manna writes:
> On 9/21/2015 2:00 PM, Mika Kuoppala wrote:
>> Jani Nikula writes:
>>
>>> On Fri, 18 Sep 2015, Mika Kuoppala wrote:
If csr/dmc firmware is known to be outdated, notify
user.
>>> What would break if we requested a firmware version that works? Or we've
>>> made it
On Thu, Oct 08, 2015 at 05:43:41PM +0530, Kumar, Shobhit wrote:
> On 10/08/2015 04:59 PM, Imre Deak wrote:
> > On to, 2015-10-08 at 09:58 +0530, Shobhit Kumar wrote:
> >> Reuse what is programmed by pre-os, but in case there is no pre-os
> >> initialization, init the cdclk with the max value by def
On 10/08/2015 04:59 PM, Imre Deak wrote:
On to, 2015-10-08 at 09:58 +0530, Shobhit Kumar wrote:
Reuse what is programmed by pre-os, but in case there is no pre-os
initialization, init the cdclk with the max value by default untill
dynamic cdclk support comes.
v2: Check if BIOS programmed correc
On to, 2015-10-08 at 09:58 +0530, Shobhit Kumar wrote:
> Reuse what is programmed by pre-os, but in case there is no pre-os
> initialization, init the cdclk with the max value by default untill
> dynamic cdclk support comes.
>
> v2: Check if BIOS programmed correctly rather than always calling ini
On 07/10/2015 17:14, Daniel Vetter wrote:
On Wed, Oct 07, 2015 at 08:16:42AM -0700, Jesse Barnes wrote:
On 10/07/2015 06:00 AM, David Woodhouse wrote:
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
+
+ ret = handle_mm_fault(mm, vma, address,
+ desc.wr_
On Thu, Oct 08, 2015 at 11:43:29AM +0100, Tvrtko Ursulin wrote:
> >-struct drm_i915_gem_object *
> >-i915_gem_object_create_stolen(struct drm_device *dev, u64 size)
> >+static bool
> >+mark_free(struct drm_i915_gem_object *obj, struct list_head *unwind)
> >+{
> >+BUG_ON(obj->stolen == NULL);
>
On Fri, Sep 18, 2015 at 06:17:05PM +0300, Mika Kuoppala wrote:
> Parse csr/dmc firmware version and augment debug message
> by printing it.
>
> Cc: Animesh Manna
> Signed-off-by: Mika Kuoppala
FWIW I did something similar in the past, but that contribution was
denied. I also had the DC states e
On Thu, Oct 08, 2015 at 11:54:29AM +0530, ankitprasad.r.sha...@intel.com wrote:
> + /* stolen objects are already pinned to prevent shrinkage */
> + memset(&node, 0, sizeof(node));
> + ret = drm_mm_insert_node_in_range_generic(&i915->gtt.base.mm,
> +
On Thu, 08 Oct 2015, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> The TMDS_296M define was computing as 296704 but the mode->clock is
> 296700 as defined by EDID. Adjusted define to allow correct detection
> of the need to program the correct N value for 29.97 and 23.98 refresh
> rat
On Thu, Oct 08, 2015 at 11:54:26AM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> Propagating correct error codes to userspace by using ERR_PTR and
> PTR_ERR macros for stolen memory based object allocation. We generally
> return -ENOMEM to the user whenever there is
On Wed, Oct 07, 2015 at 01:26:32PM +0200, Johannes Stezenbach wrote:
> On Tue, Oct 06, 2015 at 11:04:53PM -0400, Alex Deucher wrote:
> > On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach wrote:
> > >
> > > I have a NEC EA244WMi monitor connected to an Asus P8H77-V
> > > mainboard with Ivy Bridg
Hi,
On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evictin
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
> We just need to pass in an address to execute and some flags, since we
> don't have to worry about buffer relocation or any of the other usual
> stuff. Returns a fence to be used for synchronization.
> ---
> drivers/gpu/drm/i915/i915_dma.c
On 07/10/2015 17:14, Daniel Vetter wrote:
On Wed, Oct 07, 2015 at 08:16:42AM -0700, Jesse Barnes wrote:
On 10/07/2015 06:00 AM, David Woodhouse wrote:
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
+
+ ret = handle_mm_fault(mm, vma, address,
+ desc.wr_
Hi,
On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user whenever there is a failure in object
alloc
On 9/18/2015 8:47 PM, Mika Kuoppala wrote:
Add debugfs entry for csr/dmc fw to inspect firmware
loading status and version.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 32
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/g
On 9/18/2015 8:47 PM, Mika Kuoppala wrote:
Parse csr/dmc firmware version and augment debug message
by printing it.
Cc: Animesh Manna
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_csr.c | 7 ++-
2 files changed, 8 insertions(+),
On Thu, Oct 08, 2015 at 10:32:39AM +0100, Tvrtko Ursulin wrote:
>
> On 07/10/15 17:19, Chris Wilson wrote:
> >On Wed, Oct 07, 2015 at 04:57:25PM +0100, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 06/10/15 11:39, Chris Wilson wrote:
> >>>Since the remove of the pin-ioctl, we only care about not
On 28/09/15 15:14, Daniel Vetter wrote:
On Mon, Sep 28, 2015 at 02:52:30PM +0100, Chris Wilson wrote:
On Mon, Sep 28, 2015 at 03:42:22PM +0200, Daniel Vetter wrote:
On Wed, Sep 23, 2015 at 09:07:24PM +0100, Chris Wilson wrote:
If the client revokes the virtual address it asked to be mapped in
On 9/21/2015 2:00 PM, Mika Kuoppala wrote:
Jani Nikula writes:
On Fri, 18 Sep 2015, Mika Kuoppala wrote:
If csr/dmc firmware is known to be outdated, notify
user.
What would break if we requested a firmware version that works? Or we've
made it so that we only request the major version bec
On 07/10/15 17:19, Chris Wilson wrote:
On Wed, Oct 07, 2015 at 04:57:25PM +0100, Tvrtko Ursulin wrote:
Hi,
On 06/10/15 11:39, Chris Wilson wrote:
Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_disp
On Wed, Oct 07, 2015 at 04:30:35PM +0300, Francisco Jerez wrote:
> Chris Wilson writes:
>
> > On Wed, Oct 07, 2015 at 02:44:00PM +0300, Francisco Jerez wrote:
> >> This programs the L3 configuration based on the sizes given for each
> >> partition as arguments. The relevant register writes are a
From: Ville Syrjälä
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[0.00] BIOS-e820: [mem 0x000
On Wed, Oct 07, 2015 at 11:34:17AM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and reusing its address in
> t
On 07/10/15 15:19, Daniel Vetter wrote:
On Tue, Oct 06, 2015 at 07:28:10PM +0300, Ville Syrjälä wrote:
On Tue, Oct 06, 2015 at 08:16:19AM -0700, Matt Roper wrote:
On Tue, Oct 06, 2015 at 05:42:42PM +0300, Ville Syrjälä wrote:
On Tue, Oct 06, 2015 at 07:29:54AM -0700, Matt Roper wrote:
On Tue
On 07/10/15 22:07, Vivek Kasireddy wrote:
Hi Tvrtko,
On Wed, 7 Oct 2015 15:07:30 +0100
Tvrtko Ursulin wrote:
Hi,
On 07/10/15 03:35, Vivek Kasireddy wrote:
This new subtest will validate a Y-tiled object's tiling mode
against its associated fb modifier.
Cc: Tvrtko Ursulin
Signed-off-by:
On Thu, Oct 08, 2015 at 10:19:14AM +0200, Daniel Vetter wrote:
> On Wed, Oct 07, 2015 at 10:08:25PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Apparently writing the DPLL register P1/P2 divider fields won't trigger
> > an actual change in the DPLL output unless VG
From: Ville Syrjälä
EDID detailed timings have a resolution of 10kHz for the pixel clock, so
they can't represent certain CEA/HDMI modes accurately. If we see a mode
coming in via detailed timings which otherwise matches one of the
CEA/HDMI modes except the clock is just a bit off, let's assume t
From: Ville Syrjälä
Rounding to the closest kHz seems like the better option that round
down or up when computing the alternate clock for CEA/HDMI modes.
It'll give us a slightly more accurate clock in some cases.
Not sure why I went for the down+up approach originally. Perhaps
I was thinking we
From: Ville Syrjälä
drm_edid.c now computes the alternate CEA clocks using
DIV_ROUND_CLOSEST(), so follow suit in the N/CTS setup to make sure we
pick the right setting for the mode.
Unfortunately we can't actually use DIV_ROUND_CLOSEST() here due to the
({}) construct used, so just stick in raw
On Thu, Oct 08, 2015 at 10:17:30AM +0200, Daniel Vetter wrote:
> On Wed, Oct 07, 2015 at 10:08:24PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We accidentally lost the initial DPLL register write in
> > 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M
> >
>
On Thu, Oct 08, 2015 at 09:57:49AM +0200, Javier Martinez Canillas wrote:
> There is a typo in the function i915_handle_error()
> kernel-doc and the word register is spelled wrongly.
>
> Signed-off-by: Javier Martinez Canillas
Both kerneldoc patches applied, thanks.
-Daniel
> ---
>
> drivers/
On Wed, Oct 07, 2015 at 10:08:25PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently writing the DPLL register P1/P2 divider fields won't trigger
> an actual change in the DPLL output unless VGA mode is enabled for
> prior to the register write that changes the P1/P
On Wed, Oct 07, 2015 at 10:08:24PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We accidentally lost the initial DPLL register write in
> 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M
>
> The "three times for luck" hack probably saved us from a total
> disaster.
1 - 100 of 105 matches
Mail list logo
