Hi Daniel,
On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> Note that the string of platforms which have various issues with iommu
> and igfx is very long, thus far we only disabled it where there's no
> workaround to stop it from hanging the box, but otherwise left it
> enabled.
Any taker?
-Lionel
On 16/01/2019 15:36, Lionel Landwerlin wrote:
Taking the RFC off this series.
To quite the vTune team that tried the previous version :
"It reduces data collection overhead in VTune by 11x. It is great!"
The GPA team's report on the previous version was a drop in CPU
Quoting Tvrtko Ursulin (2019-01-22 09:31:31)
>
> On 18/01/2019 14:00, Chris Wilson wrote:
> > +/*
> > + * SPDX-License-Identifier: MIT
> > + *
> > + * Copyright © 2018 Intel Corporation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "i915_user_extensions.h"
> > +
On 21/01/2019 22:21, Chris Wilson wrote:
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different
On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40,
On Tue, Jan 22, 2019 at 11:39 AM Joerg Roedel wrote:
>
> On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> > @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> > quirk_iommu_g4x_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30,
On Tue, Jan 22, 2019 at 10:58 AM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-01-22 09:11:53)
> > On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson
> > wrote:
> > >
> > > Quoting Koenig, Christian (2019-01-22 08:49:30)
> > > > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > > > Rather than
Quoting Daniel Vetter (2019-01-22 09:11:53)
> On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson
> wrote:
> >
> > Quoting Koenig, Christian (2019-01-22 08:49:30)
> > > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > > Rather than every backend and GPU driver reinventing the same wheel for
> > > >
On Tue, Jan 15, 2019 at 12:46:50PM +0100, Hans de Goede wrote:
> Hi,
>
> On 15-01-19 10:56, Daniel Vetter wrote:
> > On Thu, Dec 27, 2018 at 04:24:51PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 27-12-18 15:42, Jani Nikula wrote:
> > > > On Tue, 25 Dec 2018, Hans de Goede wrote:
> > >
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/crt: split out
intel_crt_present() to platform specific setup
URL : https://patchwork.freedesktop.org/series/55540/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_12003_full
On Mon, Jan 21, 2019 at 10:24:30PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Logs can get confusing when some operations are done multiple times
> due to the ww mutex backoff. Add a debug print into
> drm_modeset_backoff() so that at least the reason for the odd
> looking logs will
On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use ENOENT consistently for the case where the requested property
> isn't found, and EINVAL for the case where the object has no
> properties whatsoever. Currenrly these are handled differently
> in the
On Mon, Jan 21, 2019 at 10:24:28PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Only some of the drm mode object lookups have a corresponding debug
> print for the lookup failure. That makes logs a bit hard to parse
> when you can't see where the bad object ID is being used. Add a bunch
On 21/01/2019 22:21, Chris Wilson wrote:
A repeated pattern is to test the signaled bit of our
request->fence.flags. Make this an inline to shorten a few lines and
remove unnecessary line continuations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 3 +--
On 21/01/2019 22:21, Chris Wilson wrote:
Replace the open-coding of advance with a call instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git
On 18/01/2019 14:00, Chris Wilson wrote:
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we
Hi,
On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The code managing the dbuf slices is borked and needs some
> real work to fix. In the meantime let's just stop using the
> second slice.
>
> Signed-off-by: Ville Syrjälä
> ---
>
On 18/01/2019 14:00, Chris Wilson wrote:
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_pmu.c | 47
Hi,
On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
wrote:
From: Ville Syrjälä
The code managing the dbuf slices is borked and needs some
real work to fix. In the meantime let's just stop using the
second slice.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 10
On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson wrote:
>
> Quoting Koenig, Christian (2019-01-22 08:49:30)
> > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > Rather than every backend and GPU driver reinventing the same wheel for
> > > user level debugging of HW execution, the common dma-fence
On 21/01/2019 22:20, Chris Wilson wrote:
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which,
Quoting Koenig, Christian (2019-01-22 08:49:30)
> Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > Rather than every backend and GPU driver reinventing the same wheel for
> > user level debugging of HW execution, the common dma-fence framework
> > should include the tracing infrastructure required
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/crt: split out
intel_crt_present() to platform specific setup
URL : https://patchwork.freedesktop.org/series/55540/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_12003
Am 22.01.19 um 00:20 schrieb Chris Wilson:
> Rather than every backend and GPU driver reinventing the same wheel for
> user level debugging of HW execution, the common dma-fence framework
> should include the tracing infrastructure required for most client API
> level flow visualisation.
>
> With
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 01:27:58PM +0200, Jani Nikula wrote:
>> We have a wrapper for a reason.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks, pushed to drm-misc-next.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/drm_dp_helper.c
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 04:21:30PM +0200, Jani Nikula wrote:
>> With new platforms not having CRT support and most conditions in
>> intel_crt_present() being specific to DDI, split out the CRT
>> initialization to platform specific blocks in the if
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 04:21:33PM +0200, Jani Nikula wrote:
>> With most platforms not having TV support, only call intel_tv_init() on
>> platforms that might actually have TV, specifically gens 3 and 4.
>>
>> This puts intel_tv_init() more in line
Now that intel_lvds_init() is only called for platforms that might have
LVDS, move the remaining checks to intel_setup_outputs(), again similar
to other outputs, and remove the overlapping checks.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |
Gen 2 mobile and not I830 is, in fact, I85X. Simplify.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Clarify that the name is specific to ILK+ PCH platforms.
v2: prefix the name with ilk rather than pch (Ville)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
With new platforms not having LVDS support, only call intel_lvds_init()
on platforms that might actually have LVDS. Move the comment about eDP
init to the PCH block where it's relevant.
This puts intel_lvds_init() more in line with the rest of the outputs,
and makes it slightly easier for the
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 04:21:32PM +0200, Jani Nikula wrote:
>> Now that intel_lvds_init() is only called for platforms that might have
>> LVDS, move the remaining checks to intel_setup_outputs(), again similar
>> to other outputs, and remove the
With most platforms not having TV support, only call intel_tv_init() on
platforms that might actually have TV, specifically gens 3 and 4.
This puts intel_tv_init() more in line with the rest of the outputs, and
makes it slightly easier for the uninitiated to figure out which
platforms actually
The VBT int_crt_support can't be trusted on earlier platforms, and is
always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We
can simplify the output setup by unconditionally calling
intel_crt_init() for these platforms.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
With new platforms not having CRT support and most conditions in
intel_crt_present() being specific to DDI, split out the CRT
initialization to platform specific blocks in the if ladder. Add new
Pineview block for this.
This puts intel_crt_init() more in line with the rest of the outputs,
and
On Mon, Jan 21, 2019 at 11:13 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> > >
> > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy
> > > kms drivers. Just removing it from all the atomic drivers caused lots of
> > > fallout, I expect even more if you entirely
101 - 136 of 136 matches
Mail list logo
