On Mon, Dec 14, 2015 at 07:24:29AM +, Song, Ruiling wrote:
>
>
> > -Original Message-
> > From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf Of
> > Kristian H?gsberg
> > Sent: Monday, December 14, 2015 1:34 PM
> > To: Song, Ruiling
> > Cc: Winiarski, Michal ; intel-
> >
On Sat, Dec 12, 2015 at 03:16:59PM +, Emil Velikov wrote:
> On 11 December 2015 at 21:55, Jesse Barnes wrote:
> > Pick up context flags, softpin, etc.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > include/drm/i915_drm.h | 57
> > ++
> > 1 fi
%s/cpy/cpu
Reviewed-by: Sonika Jindal
On 12/12/2015 12:14 AM, Daniel Vetter wrote:
I missed this myself when reviewing
commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal
Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid
Long slee
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, December 14, 2015 4:28 PM
> To: Song, Ruiling
> Cc: k...@bitplanet.net; Winiarski, Michal ;
> mesa-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
> Wid
On Tue, 2015-11-24 at 13:22 +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2015 at 10:06:16AM +, Chris Wilson wrote:
> > On Fri, Nov 20, 2015 at 03:07:58PM +0530, Ankitprasad Sharma wrote:
> > > On Wed, 2015-11-18 at 10:59 +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 05, 2015 at 05:15:59PM +0
On Mon, Dec 14, 2015 at 08:41:05AM +, Song, Ruiling wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, December 14, 2015 4:28 PM
> > To: Song, Ruiling
> > Cc: k...@bitplanet.net; Winiarski, Michal
On Mon, Dec 14, 2015 at 05:46:41PM +0530, Deepak M wrote:
> Currently the iomap for VBT works only if the size of the
> VBT is less than 6KB, but if the size of the VBT exceeds
> 6KB than the physical address and the size of the VBT to
> be iomapped is specified in the mailbox3 and is iomapped
> ac
Hi Dave,
Last (very likely at least) drm-misc pull for 4.5. 3 big things:
- piles of docs for kms vtables.
- drm.debug dmesg output prettification from Ville (i915 parts are for 4.6
I think)
- connector mode probing/validating/merging cleanup from Ville.
From that last pile please cherry-pick
The total delay of HDMI hotplug detecting with 30ms have already
been split into a resolution of 3 retries of 10ms each, for the worst
cases. But it still suffered from only waiting 10ms at most in
intel_hdmi_detect(). This patch corrects it by reading hotplug status
with 4 times at most for 30ms d
On Fri, 11 Dec 2015, Takashi Iwai wrote:
> On Fri, 11 Dec 2015 07:07:53 +0100,
> Libin Yang wrote:
>>
>> >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> >>> b/drivers/gpu/drm/i915/intel_audio.c
>> >>> index 9aa83e7..5ad2e66 100644
>> >>> --- a/drivers/gpu/drm/i915/intel_audio.c
>> >>> +++
>
>
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Friday, December 11, 2015 5:06 PM
>To: Morton, Derek J
>Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Wood, Thomas
>Subject: Re: [Intel-gfx] [PATCH i-g-t] gem_flink_race/prim
On Mon, 14 Dec 2015 10:33:44 +0100,
Jani Nikula wrote:
>
> On Fri, 11 Dec 2015, Takashi Iwai wrote:
> > On Fri, 11 Dec 2015 07:07:53 +0100,
> > Libin Yang wrote:
> >>
> >> >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> >> >>> b/drivers/gpu/drm/i915/intel_audio.c
> >> >>> index 9aa83e7..5
On Mon, Dec 14, 2015 at 11:16:09AM +0530, ankitprasad.r.sha...@intel.com wrote:
> @@ -1150,8 +1252,9 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
> *data,
>* perspective, requiring manual detiling by the client.
>*/
> if (obj->tiling_mode == I915_TILING_NONE &&
> -
On Mon, Dec 14, 2015 at 11:16:11AM +0530, 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
On Mon, Dec 14, 2015 at 11:16:05AM +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 Mon, Dec 14, 2015 at 11:16:04AM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> we try a nonblocking pin for the whole object (since that is fastest if
> reused), then failing that we try to
gem_flink_race and prime_self_import have subtests which read the
number of open gem objects from debugfs to determine if objects have
leaked during the test. However the test can fail sporadically if
the number of gem objects changes due to other process activity.
This patch introduces a change to
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index d727b49..ebce8c9 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -357,6 +357,7 @@ typedef struct drm_i915_irq_wait {
> #define I915_PARAM_HAS_GPU_RESET 35
> #define I915_PARAM
On Mon, Dec 14, 2015 at 11:16:07AM +0530, ankitprasad.r.sha...@intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 17d679e..366080b9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_sto
On Mon, Dec 14, 2015 at 11:16:08AM +0530, ankitprasad.r.sha...@intel.com wrote:
> @@ -2039,6 +2052,8 @@ struct drm_i915_gem_object {
> struct list_head obj_exec_link;
>
> struct list_head batch_pool_link;
> + /** Used during stolen memory allocations to temporarily hold a ref */
>
On 12/11/2015 6:57 PM, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 02:49:52PM +, Chris Wilson wrote:
On Fri, Dec 11, 2015 at 02:34:13PM +, Michel Thierry wrote:
We detected if objects should be moved to the lower parts when 48-bit
support flag was not set, but not the other way around.
Dave Gordon writes:
> On 01/12/15 11:46, Tvrtko Ursulin wrote:
>>
>> On 23/10/15 18:02, Tomas Elf wrote:
>>> When clearing an execlist queue, instead of traversing it and
>>> unreferencing all
>>> requests while holding the spinlock (which might lead to thread
>>> sleeping with
>>> IRQs are turne
On Mon, Dec 14, 2015 at 11:16:10AM +0530, ankitprasad.r.sha...@intel.com wrote:
> +static int
> +copy_content(struct drm_i915_gem_object *obj,
> + struct drm_i915_private *i915,
> + struct address_space *mapping)
> +{
> + struct drm_mm_node node;
> + int ret, i;
> +
On Mon, 14 Dec 2015, Takashi Iwai wrote:
> On Mon, 14 Dec 2015 10:33:44 +0100,
> Jani Nikula wrote:
>>
>> On Fri, 11 Dec 2015, Takashi Iwai wrote:
>> > On Fri, 11 Dec 2015 07:07:53 +0100,
>> > Libin Yang wrote:
>> >>
>> >> >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> >> >>> b/drivers
On Mon, 14 Dec 2015 11:34:53 +0100,
Jani Nikula wrote:
>
> On Mon, 14 Dec 2015, Takashi Iwai wrote:
> > On Mon, 14 Dec 2015 10:33:44 +0100,
> > Jani Nikula wrote:
> >>
> >> On Fri, 11 Dec 2015, Takashi Iwai wrote:
> >> > On Fri, 11 Dec 2015 07:07:53 +0100,
> >> > Libin Yang wrote:
> >> >>
> >>
On Mon, Dec 14, 2015 at 09:54:06AM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 11:16:04AM +0530, ankitprasad.r.sha...@intel.com
> wrote:
> > From: Ankitprasad Sharma
> >
> > In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> > we try a nonblocking pin for the who
This series refactors the VBT and OpRegion code to support VBT bigger
than 6 KB. It's plenty of small, hopefully easy to review steps.
This series supersedes patches 2-6 of Deepak's series [1]. I took over
because I would not have been able to adequately describe in review what
I wanted done.
I'l
Check the quirk in intel_opregion_setup(), and don't initialize
opregion->vbt at all if the quirk says it's not present, hiding the
quirk from the rest of the driver.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 24 ++--
drivers/gpu/drm/i915/intel_op
From: Deepak M
Mailbox 5 is BIOS to Driver Notification mailbox is intended
to support BIOS to Driver event notification or data storage
for BIOS to Driver data synchronization purpose. Mailbox 5 is
the extension of mailbox 3.
v4 by Jani:
- don't add asle_ext to dev_priv as it's unused
- use u
The VBT in OpRegion should fit in mailbox #4.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 9f992e7c6185..3c76a8684ff2 1
This will simplify further work.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 41 +--
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 401e1141f55
Make the validation function a boolean operating on a buffer of given
size, removing the extra pointer dances.
Move the OpRegion based VBT validation to intel_opregion_setup(), only
initializing opregion->vbt if it's valid.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |
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.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 22 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gp
Hasn't been necessary since
commit 115719fceaa733d646e39cdce83cc32ddb891a49
Author: Williams, Dan J
Date: Mon Oct 12 21:12:57 2015 +
i915: switch from acpi_os_ioremap to memremap
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
1 file changed, 2 i
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.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h
Because we can. It's not to be touched so tell the compiler too.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu
The decision about which source will be used for VBT is done in
intel_parse_bios(), not in the VBT validation function. Make the VBT
validation function strictly about validation, and move the debug
logging to where it logically belongs.
This will make even more sense in the future when the valida
While at it, move the declaration to where everything else is declared.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_bios.c | 4 ++--
drivers/gpu/drm/i915/intel_bios.h | 2 --
4 files changed, 6 ins
On Mon, 14 Dec 2015, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 05:46:41PM +0530, Deepak M wrote:
>> Currently the iomap for VBT works only if the size of the
>> VBT is less than 6KB, but if the size of the VBT exceeds
>> 6KB than the physical address and the size of the VBT to
>> be iomapped i
On Mon, Dec 14, 2015 at 12:50:54PM +0200, Jani Nikula wrote:
> 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.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 22 +++
On Tue, 01 Dec 2015, Deepak M wrote:
> v3: rebase
>
> Cc: Jani Nikula
> Signed-off-by: Deepak M
Pushed this one as "drm/i915: add VBT address and size fields to ASLE
mailbox struct". Thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 4 +++-
> 1 file changed, 3
On Mon, 14 Dec 2015, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 12:50:54PM +0200, Jani Nikula wrote:
>> 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.
>>
>> Signed-off-by: Jani Nikula
>> ---
>>
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, the ring is idle and there is no information
inside the ring pertaining to the hang.
Signed-off-by:
From: Ville Syrjälä
The cursor code tries to treat base==0 to mean disabled. That fails
when the cursor bo gets bound at ggtt offset 0, and the user is left
looking at an invisible cursor.
We lose the disabled->disabled optimization, but that seems like
something better handled at a slightly hig
From: Ville Syrjälä
The vma may have been rebound between the last time the cursor was
enabled and now, so skipping the cursor gtt offset deduction is not
safe unless we would also reset cursor_bo to NULL when disabling the
cursor. Just thow cursor_bo to the bin instead since it's lost all
other
On Mon, Dec 14, 2015 at 10:48:51AM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 09:54:06AM +, Chris Wilson wrote:
> > On Mon, Dec 14, 2015 at 11:16:04AM +0530, ankitprasad.r.sha...@intel.com
> > wrote:
> > > From: Ankitprasad Sharma
> > >
> > > In pwrite_fast, map an object page by p
On 11/12/2015 15:57, Tvrtko Ursulin wrote:
On 11/12/15 13:11, john.c.harri...@intel.com wrote:
From: Peter Lawthers
In the 3.14 kernel, a signaled fence was indicated by the status field
== 1. In 4.x, a status == 0 indicates signaled, status < 0 indicates
error,
and status > 0 indicates act
From: Ville Syrjälä
These two should provide the minimal fix for the invisible cursor
problem that's been plaguing me and some other people. It's caused
by the cursor bo getting bound at ggtt offset 0, which the code then
considers to mean "not enabled". These patches get rid of that assumption,
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, the ring is idle and there is
On Mon, 14 Dec 2015, Gary Wang wrote:
> The total delay of HDMI hotplug detecting with 30ms have already
> been split into a resolution of 3 retries of 10ms each, for the worst
> cases. But it still suffered from only waiting 10ms at most in
> intel_hdmi_detect(). This patch corrects it by reading
On 11/12/15 22:59, Chris Wilson wrote:
Remove some redundant kernel messages as we deduce a hung GPU and
capture the error state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/
On Mon, Dec 14, 2015 at 01:06:51PM +0200, Jani Nikula wrote:
> On Mon, 14 Dec 2015, Chris Wilson wrote:
> > On Mon, Dec 14, 2015 at 12:50:54PM +0200, Jani Nikula wrote:
> >> In the future the VBT might not be in mailbox #4 of the ACPI OpRegion,
> >> thus unavailable in i915_opregion, so add a sepa
On Mon, Dec 14, 2015 at 01:16:47PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The vma may have been rebound between the last time the cursor was
> enabled and now, so skipping the cursor gtt offset deduction is not
> safe unless we would also reset cursor_bo to NULL whe
On Mon, Dec 14, 2015 at 01:16:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The cursor code tries to treat base==0 to mean disabled. That fails
> when the cursor bo gets bound at ggtt offset 0, and the user is left
> looking at an invisible cursor.
>
> We lose the di
Elsewhere we have adopted the convention of using '_link' to denote
elements in the list (and '_list' for the actual list_head itself), and
that the name should indicate which list the link belongs to (and
preferrably not just where the link is being stored).
s/vma_link/obj_link/ (we iterate over
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
I
In the next patch, request tracking is made more generic and for that we
need a new expanded struct and to separate out the logic changes from
the mechanical churn, we split out the structure renaming into this
patch. For extra fun, create a new i915_gem_request.h.
Signed-off-by: Chris Wilson
---
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
I
As we can now have multiple VMA inside the global GTT (with partial
mappings, rotations, etc), it is no longer true that there may just be a
single GGTT entry and so we should walk the full vma_list to count up
the actual usage. In addition to unifying the two walkers, switch from
multiplying the o
For the global GTT (and aliasing GTT), the address space is owned by the
device (it is a global resource) and so the per-file owner field is
NULL. For per-process GTT (where we create an address space per
context), each is owned by the opening file. We can use this ownership
information to both dis
Elsewhere we have adopted the convention of using '_link' to denote
elements in the list (and '_list' for the actual list_head itself), and
that the name should indicate which list the link belongs to (and
preferrably not just where the link is being stored).
s/vma_link/obj_link/ (we iterate over
This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae.
The patch was incomplete, introduced more problems of greater severity
than it solved and worse the solution was known and available at the
time of the patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |
The multiple levels of indirect do nothing but hinder the compiler and
the pointer chasing turns to be quite painful but painless to fix.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 13 ++---
drivers/gpu/drm/i915/i915_drv.h| 7 ---
driver
In order to prevent a leak of the vma on shared objects, we need to
hook into the object_close callback to destroy the vma on the object for
this file. However, if we destroyed that vma immediately we may cause
unexpected application stalls as we try to unbind a busy vma - hence we
defer the unbind
This patch is broken out of the next just to remove the code motion from
that patch and make it more readable. What we do here is move the
i915_vma_move_to_active() to i915_gem_execbuffer.c and put the three
stages (read, write, fenced) together so that future modifications to
active handling are a
When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two purposes.
First it allows us to flag the closed context and detect internal errors if
we to create any new objects for it (as it is removed from the user's
nam
On Mon, Dec 14, 2015 at 11:28:39AM +, Dave Gordon wrote:
> On 11/12/15 22:59, Chris Wilson wrote:
> >Remove some redundant kernel messages as we deduce a hung GPU and
> >capture the error state.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/i915_irq.c | 16 ++-
Hook the vma itself into the i915_gem_request_retire() so that we can
accurately track when a solitary vma is inactive (as opposed to having
to wait for the entire object to be idle). This improves the interaction
when using multiple contexts (with full-ppgtt) and eliminates some
frequent list walk
On 14 December 2015 at 09:04, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 08:41:05AM +, Song, Ruiling wrote:
>>
>>
>> > -Original Message-
>> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> > Vetter
>> > Sent: Monday, December 14, 2015 4:28 PM
>> > To: S
On 11/12/2015 15:29, Tvrtko Ursulin wrote:
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
Various projects desire a mechanism for managing dependencies between
work items asynchronously. This can also include work items across
complete different and independent syste
On 11/12/2015 14:28, Tvrtko Ursulin wrote:
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
requirement of not enabling interrupts until
Op 04-12-15 om 09:12 schreef Daniel Vetter:
> On Thu, Dec 03, 2015 at 12:01:02PM +0100, Maarten Lankhorst wrote:
>> Op 03-12-15 om 10:53 schreef Daniel Vetter:
>>> On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote:
This allows iteration over encoders without requiring connectio
On Tue, 2015-11-24 at 11:29 +0100, Maarten Lankhorst wrote:
> This fixes a warning when the crtc is turned off. In that case fb
> will be NULL, and crtc_clock will be 0. Because the crtc is no longer
> active this is not a bug, and shouldn't trigger the WARN_ON.
>
> Also remove handling a null crt
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results,
On Mon, Dec 14, 2015 at 11:46:22AM +, John Harrison wrote:
> >>@@ -1341,6 +1375,17 @@ i915_gem_do_execbuffer(struct drm_device
> >>*dev, void *data,
> >> u32 dispatch_flags;
> >> int ret;
> >> bool need_relocs;
> >>+int fd_fence_complete = -1;
> >>+int fd_fence_wait = low
On 14/12/15 11:22, John Harrison wrote:
On 11/12/2015 15:57, Tvrtko Ursulin wrote:
On 11/12/15 13:11, john.c.harri...@intel.com wrote:
From: Peter Lawthers
In the 3.14 kernel, a signaled fence was indicated by the status field
== 1. In 4.x, a status == 0 indicates signaled, status < 0 indic
On 14/12/15 11:58, John Harrison wrote:
On 11/12/2015 14:28, Tvrtko Ursulin wrote:
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
req
On Mon, Dec 14, 2015 at 12:21:32PM +, Tvrtko Ursulin wrote:
> >@@ -1229,18 +1219,13 @@ int __i915_wait_request(struct drm_i915_gem_request
> >*req,
> > s64 *timeout,
> > struct intel_rps_client *rps)
> > {
> >-struct intel_engine_cs *ring = i915_gem
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)
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 ++
driv
Hi All,
On 12 December 2015 at 12:54, Ian Bruntlett wrote:
> I've got a couple of third hand computers using Intel graphics (Dell
> Optiplex GX50, HP Compaq dc 7600) with graphics problems - Dell becomes
> unusable, screen is all white with black squiggles after running updates on
> Ubuntu 14.04
On Mon, Dec 14, 2015 at 12:50:50PM +0200, Jani Nikula wrote:
> Make the validation function a boolean operating on a buffer of given
> size, removing the extra pointer dances.
>
> Move the OpRegion based VBT validation to intel_opregion_setup(), only
> initializing opregion->vbt if it's valid.
>
On Mon, Dec 14, 2015 at 11:39:47AM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 11:28:39AM +, Dave Gordon wrote:
> > If this is a test that has disabled error state
> > capture (because it's *trying* to hang one or more rings) can we
> > still know how many rings have been diagnosed as
On Mon, Dec 14, 2015 at 12:50:53PM +0200, Jani Nikula wrote:
> Hasn't been necessary since
>
> commit 115719fceaa733d646e39cdce83cc32ddb891a49
> Author: Williams, Dan J
> Date: Mon Oct 12 21:12:57 2015 +
>
> i915: switch from acpi_os_ioremap to memremap
>
> Signed-off-by: Jani Nikula
This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae.
The patch was incomplete, introduced more problems of greater severity
than it solved and worse the solution was known and available at the
time of the patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |
Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC.
Instead of seeing the new dense graphics mode, I see the last VGA text
lines and no X appears either.
I saw something similar on I865G but have not had time to check if it is
the same issue.
ac9b8236551d1177fd07b56aef9b565d1
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
On Mon, Dec 14, 2015 at 01:54:38PM +, Chris Wilson wrote:
> This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae.
>
> The patch was incomplete, introduced more problems of greater severity
> than it solved and worse the solution was known and available at the
> time of the patch.
Bad
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 alternate location for VBT instead of mailbox #4.
> Use the alternate location if available and valid, falling back to
> mailbox #4 otherwise.
On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 12:50:50PM +0200, Jani Nikula wrote:
>> Make the validation function a boolean operating on a buffer of given
>> size, removing the extra pointer dances.
>>
>> Move the OpRegion based VBT validation to intel_opregion_setup(), onl
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 alternate location for VBT instead of mailbox #4.
> > Use the alternate l
On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 12:50:53PM +0200, Jani Nikula wrote:
>> Hasn't been necessary since
>>
>> commit 115719fceaa733d646e39cdce83cc32ddb891a49
>> Author: Williams, Dan J
>> Date: Mon Oct 12 21:12:57 2015 +
>>
>> i915: switch from acpi_os_
On Mon, 14 Dec 2015, 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 alternate location for VBT instead of mailbox #4.
>> Use the alternate location if available an
On Mon, Dec 14, 2015 at 04:34:50PM +0200, Jani Nikula wrote:
> On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2015 at 12:50:50PM +0200, Jani Nikula wrote:
> >> Make the validation function a boolean operating on a buffer of given
> >> size, removing the extra pointer dances.
> >>
>
On Mon, Dec 14, 2015 at 04:38:58PM +0200, Jani Nikula wrote:
> On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2015 at 12:50:53PM +0200, Jani Nikula wrote:
> >> Hasn't been necessary since
> >>
> >> commit 115719fceaa733d646e39cdce83cc32ddb891a49
> >> Author: Williams, Dan J
> >> D
On Sun, Dec 13, 2015 at 12:49:45PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 04:47:22PM +0200, Jani Nikula wrote:
> > We had the "The master control interrupt lied (SDE)!" check and error
> > message in place for a long time without any problems, until
> >
> > commit aaf5ec2e51ab1d9c5e9
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now that we have split out the seqno-barrier from the
engine->get_seqno() callback itself, we can move the users of the
seqno-barrier to the required callsites simplifying the common code and
making the required workaround handling much more explicit.
On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote:
> Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC.
That would seem to be SNB.
> Instead of seeing the new dense graphics mode, I see the last VGA text
> lines and no X appears either.
That's a bit weird. SNB has
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 11/12/15 11:33, Chris Wilson wrote:
> >Now that we have split out the seqno-barrier from the
> >engine->get_seqno() callback itself, we can move the users of the
> >seqno-barrier to the required callsites simplifying t
On Mon, Dec 14, 2015 at 11:32:23AM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 01:16:47PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The vma may have been rebound between the last time the cursor was
> > enabled and now, so skipping the cursor gtt offset
On Mon, Dec 14, 2015 at 05:35:02PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The vma may have been rebound between the last time the cursor was
> enabled and now, so skipping the cursor gtt offset deduction is not
> safe unless we would also reset cursor_bo to NULL whe
1 - 100 of 159 matches
Mail list logo
