== Series Details ==
Series: Enhancement to intel_dp_aux_backlight driver (rev4)
URL : https://patchwork.freedesktop.org/series/21086/
State : failure
== Summary ==
make: Entering directory '/home/cidrm/kernel'
CHK include/config/kernel.release
CHK include/generated/uapi/linux/vers
== Series Details ==
Series: Enhancement to intel_dp_aux_backlight driver (rev4)
URL : https://patchwork.freedesktop.org/series/21086/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
On Wed, Apr 19, 2017 at 01:01:55PM +0200, Arkadiusz Hiler wrote:
> Currently whole igt_kms.c is disabled while compiling on Android without
> cairo, so this tests does not compile.
>
> There should be cleaner a way to disable only cairo dependant parts
> which should allow us to enable at least so
On Wed, 03 May 2017, Sean Paul wrote:
> Each pull request is accompanied by a summary that is stored in the git tag
> from which it is generated. These summaries all share the same template with
> headers classifying changes to UAPI, Cross-subsystem, Core, and Drivers. This
> patch adds this templ
Op 03-05-17 om 20:03 schreef Ville Syrjälä:
> On Wed, May 03, 2017 at 06:18:46PM +0200, Maarten Lankhorst wrote:
>> Op 03-05-17 om 18:07 schreef Ville Syrjälä:
>>> On Wed, May 03, 2017 at 05:53:34PM +0200, Maarten Lankhorst wrote:
Op 03-05-17 om 16:11 schreef Ville Syrjälä:
> On Wed, May 0
On Wed, Apr 26, 2017 at 03:36:16PM -0300, Paulo Zanoni wrote:
> > I have a feeling I asked this before, but why aren't we just fixing
> > the kernel to report it correctly? For any platform with FBC2 it
> > should be trivial,
>
> Right, I see there's a reg for that for ILK/SNB.
>
> > for FBC1 sl
On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote:
> On Thu, Apr 27, 2017 at 06:30:42PM +0300, David Weinehall wrote:
> > On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote:
> > > On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote:
> > > > Add a bunch of MOCS en
On Wed, Apr 26, 2017 at 03:28:09AM -0700, Oscar Mateo wrote:
> This test got inadvertently disabled by commit 83884e97 (Restore
> "lib: Open debugfs files for the given DRM device") when the
> initialization order got changed (dbg_init before gem_init).
>
> v2:
> - The asserts on fd are useless
On 04/05/2017 09:35, Arkadiusz Hiler wrote:
On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote:
On Thu, Apr 27, 2017 at 06:30:42PM +0300, David Weinehall wrote:
On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote:
On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall
On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> Cannonlake is a Intel® Processor containing Intel® HD Graphics
> following Kabylake.
>
> It is Gen10.
>
> Let's start by adding the platform definition based on previous
> platforms but yet as alpha_support.
>
> On following patches we wil
On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> From: James Irwin
>
> Issue: VIZ-4525
>
> Reviewed-by: Damien Lespiau
> Signed-off-by: James Irwin
> Signed-off-by: Damien Lespiau
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> 1
Hi,
On 04.05.2017 11:53, Tvrtko Ursulin wrote:
On 04/05/2017 09:35, Arkadiusz Hiler wrote:
On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote:
But what is being counter suggested is that their is no reason for these
mocs entries. If the sdk is just using mocs registers without first
On Wed, 03 May 2017, Anusha Srivatsa wrote:
> From: Rodrigo Vivi
>
> Split out BXT and CNP's setup_backlight(),enable_backlight(),
> disable_backlight() and hz_to_pwm() into
> two separate functions instead of reusing BXT function.
>
> Reuse set_backlight() and get_backlight() since they have
> n
acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
bytes. Instead we convert them to use uuid_le type. At the same time we
convert current users.
acpi_str_to_uuid() becomes useless after the conversion and it's safe to
get rid of it.
The conversion fixes a potential bug in int34
Hi,
On 3 May 2017 at 06:14, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
In terms of the blob as uABI, we've got an implementation inside
Weston which works:
https://git.collabora.com/cgit/user/daniels/weston.git/commit/?h=wip/2017-04/atomic-v11-WIP&id=0a47cb63947e
T
Since unifying ringbuffer/execlist submission to use
engine->pin_context, we ensure that the intel_ring is available before
we start constructing the request. We can therefore move the assignment
of the request->ring to the central i915_gem_request_alloc() and not
require it in every engine->reques
On 04/05/2017 10:21, Eero Tamminen wrote:
Hi,
On 04.05.2017 11:53, Tvrtko Ursulin wrote:
On 04/05/2017 09:35, Arkadiusz Hiler wrote:
On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote:
But what is being counter suggested is that their is no reason for
these
mocs entries. If the sdk
On Thu, 04 May 2017, Andy Shevchenko wrote:
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c
> b/drivers/gpu/drm/i915/intel_acpi.c
> index eb638a1e69d2..72bfe6ceadf8 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -15,13 +15,9 @@ static struct intel
A good default for garbage entries from the user is to follow the
default setting of the object (i.e. the PTE). Currently they use the
uncached entry, and now the only way to accidentally hit uncached
performance is via explicit use of the uncached MOCS or setting the
object to uncached. Note that
== Series Details ==
Series: drm/i915: Use engine->context_pin() to report the intel_ring (rev2)
URL : https://patchwork.freedesktop.org/series/23884/
State : success
== Summary ==
Series 23884v2 drm/i915: Use engine->context_pin() to report the intel_ring
https://patchwork.freedesktop.org/api
-resend/20170504-003948
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
== Series Details ==
Series: drm/i915: Set all undefined MOCS entries to follow PTE
URL : https://patchwork.freedesktop.org/series/23941/
State : success
== Summary ==
Series 23941v1 drm/i915: Set all undefined MOCS entries to follow PTE
https://patchwork.freedesktop.org/api/1.0/series/23941/r
hdac_wait_for_cmd_dmas() uses a jiffie timeout to ensure that we do not
wait forever for stuck hardware. However, it is called from an
irq-disabled context which prevents jiffie from advancing and so the
loop doesn't terminate if the hardware fails. This can then cause NMI
watchdog warnings, such a
On Thu, 04 May 2017 12:18:29 +0200,
Chris Wilson wrote:
>
> hdac_wait_for_cmd_dmas() uses a jiffie timeout to ensure that we do not
> wait forever for stuck hardware. However, it is called from an
> irq-disabled context which prevents jiffie from advancing and so the
> loop doesn't terminate if th
On Thu, May 04, 2017 at 12:25:26PM +0200, Takashi Iwai wrote:
> On Thu, 04 May 2017 12:18:29 +0200,
> Chris Wilson wrote:
> >
> > hdac_wait_for_cmd_dmas() uses a jiffie timeout to ensure that we do not
> > wait forever for stuck hardware. However, it is called from an
> > irq-disabled context whic
On Thu, 04 May 2017 12:30:32 +0200,
Vinod Koul wrote:
>
> On Thu, May 04, 2017 at 12:25:26PM +0200, Takashi Iwai wrote:
> > On Thu, 04 May 2017 12:18:29 +0200,
> > Chris Wilson wrote:
> > >
> > > hdac_wait_for_cmd_dmas() uses a jiffie timeout to ensure that we do not
> > > wait forever for stuck
== Series Details ==
Series: ALSA: hda: Use loop counter for hdac_wait_for_cmd_dmas() timeout
URL : https://patchwork.freedesktop.org/series/23948/
State : success
== Summary ==
Series 23948v1 ALSA: hda: Use loop counter for hdac_wait_for_cmd_dmas() timeout
https://patchwork.freedesktop.org/ap
On Thu, May 04, 2017 at 12:25:26PM +0200, Takashi Iwai wrote:
> On Thu, 04 May 2017 12:18:29 +0200,
> Chris Wilson wrote:
> >
> > hdac_wait_for_cmd_dmas() uses a jiffie timeout to ensure that we do not
> > wait forever for stuck hardware. However, it is called from an
> > irq-disabled context whic
On Thu, May 04, 2017 at 10:12:52AM +0200, Maarten Lankhorst wrote:
> Op 03-05-17 om 20:03 schreef Ville Syrjälä:
> > On Wed, May 03, 2017 at 06:18:46PM +0200, Maarten Lankhorst wrote:
> >> Op 03-05-17 om 18:07 schreef Ville Syrjälä:
> >>> On Wed, May 03, 2017 at 05:53:34PM +0200, Maarten Lankhorst
On Thu, May 04, 2017 at 10:09:57AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Set all undefined MOCS entries to follow PTE
> URL : https://patchwork.freedesktop.org/series/23941/
> State : success
>
> == Summary ==
>
> Series 23941v1 drm/i915: Set all undefined MOCS e
On Thu, May 04, 2017 at 09:53:35AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Use engine->context_pin() to report the intel_ring (rev2)
> URL : https://patchwork.freedesktop.org/series/23884/
> State : success
>
> == Summary ==
>
> Series 23884v2 drm/i915: Use engine-
On Thu, May 04, 2017 at 11:59:53AM +0100, Chris Wilson wrote:
> On Thu, May 04, 2017 at 10:09:57AM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Set all undefined MOCS entries to follow PTE
> > URL : https://patchwork.freedesktop.org/series/23941/
> > State : success
With the atomic watermark calculations calculate intermediary watermark
values and update the watermarks atomically.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 103 +
I've only compile time tested this and the series depends on
Ville's gen4x watermark conversion so CI will fail to apply it.
Maarten Lankhorst (7):
drm/i915: Calculate gen3- watermarks semi-atomically.
drm/i915: Program gen3- watermarks atomically
drm/i915: Convert pineview watermarks to ato
The gen3 watermark calculations are converted to atomic,
but the wm update calls are still done through the legacy
functions.
This will make it easier to bisect things if they go wrong.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 +-
drivers/gpu/drm/i915/inte
Pineview seems to have different watermarks from the other
platforms and are calculated separately.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pm.c | 134 ++-
2 files changed, 92 insertions(+), 4
Gen4 watermark is handled same as gen3-. Calculate
the optimal watermarks atomically first, and program
it in the legacy helper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 136
1 file changed, 95 insertions(+), 41 deletions(-)
Use crtc->active directly instead. This is still not completely
optimal and needs fixing, but it's about as good as using
intel_crtc_active.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 19 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gp
We're already calculating the watermarks correctly, now we have to
program them too.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/
The legacy watermark infrastructure is now unused, so remove it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_atomic.c | 2 -
drivers/gpu/drm/i915/intel_display.c | 75 ++--
drivers/gpu/drm/i915/int
Replace the large comment about requiring the powerwell for
intel_uncore_arm_unclaimed_mmio_detection() by moving the arming of the
mmio error detection into the powerwell held for modesetting. Thereby
also accomplishing the goal of only arming the mmio detection after a
full modeset.
Signed-off-b
Chris Wilson writes:
> Typically, there is space available within the ring and if not we have
> to wait (by definition a slow path). Rearrange the code to reduce the
> number of branches and stack size for the hotpath, accomodating a slight
> growth for the wait.
>
> v2: Fix the new assert that p
== Series Details ==
Series: drm/i915: Move the unclaimed mmio detection into the powerwell for KMS
URL : https://patchwork.freedesktop.org/series/23955/
State : success
== Summary ==
Series 23955v1 drm/i915: Move the unclaimed mmio detection into the powerwell
for KMS
https://patchwork.freed
On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and
On Thu, May 04, 2017 at 03:11:45PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Typically, there is space available within the ring and if not we have
> > to wait (by definition a slow path). Rearrange the code to reduce the
> > number of branches and stack size for the hotpath, accom
On Fri, 2017-04-07 at 18:12 -0300, Paulo Zanoni wrote:
> Em Qui, 2017-04-06 às 12:15 -0700, Rodrigo Vivi escreveu:
> > One of the steps for PLL (un)initialization is to (un)map
> > the correspondent DDI that is actually using that PLL.
> >
> > So, let's do this step following the places already st
On Thu, May 04, 2017 at 03:35:51PM +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2017-04-07 at 18:12 -0300, Paulo Zanoni wrote:
> > Em Qui, 2017-04-06 às 12:15 -0700, Rodrigo Vivi escreveu:
> > > One of the steps for PLL (un)initialization is to (un)map
> > > the correspondent DDI that is act
We are using some scratch registers in MMIO based send function.
Make their base and count flexible in preparation of upcoming
GuC firmware/hardware changes. While around, change cmd len
parameter verification from WARN_ON to GEM_BUG_ON as we don't
need this all the time.
v2: call out WARN/GEM_BUG
On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote:
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index cbf7763d8091..420d51b286ad 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1808,10 +1808,9 @@ IOMMU_INIT_POST(detect_intel_iommu);
> * for Dir
On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> One of the steps for PLL (un)initialization is to (un)map
> the correspondent DDI that is actually using that PLL.
>
> So, let's do this step following the places already stablished
> and used so far, although spec put this as part of PLL
>
Chris Wilson writes:
> On Thu, May 04, 2017 at 03:11:45PM +0300, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > Typically, there is space available within the ring and if not we have
>> > to wait (by definition a slow path). Rearrange the code to reduce the
>> > number of branches and sta
Op 04-05-17 om 14:44 schreef Ville Syrjälä:
> On Thu, May 04, 2017 at 03:35:51PM +0300, Ander Conselvan De Oliveira wrote:
>> On Fri, 2017-04-07 at 18:12 -0300, Paulo Zanoni wrote:
>>> Em Qui, 2017-04-06 às 12:15 -0700, Rodrigo Vivi escreveu:
One of the steps for PLL (un)initialization is to (
On Thu, May 04, 2017 at 03:59:05PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Thu, May 04, 2017 at 03:11:45PM +0300, Mika Kuoppala wrote:
> >> Chris Wilson writes:
> >>
> >> > Typically, there is space available within the ring and if not we have
> >> > to wait (by definition a
Typically, there is space available within the ring and if not we have
to wait (by definition a slow path). Rearrange the code to reduce the
number of branches and stack size for the hotpath, accomodating a slight
growth for the wait.
v2: Fix the new assert that packets are not larger than the act
Some callers immediately want to know the current ring->space after
calling intel_ring_update_space(), which we can freely provide via the
return parameter.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 12
drivers/gpu/drm/i9
Exploit the power-of-two ring size to compute the space across the
wraparound using a mask rather than a if. Convert to unsigned integers
so the operation is well defined.
References: https://bugs.freedesktop.org/show_bug.cgi?id=99671
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mi
On Thu, May 04, 2017 at 03:02:07PM +0200, Maarten Lankhorst wrote:
> Op 04-05-17 om 14:44 schreef Ville Syrjälä:
> > On Thu, May 04, 2017 at 03:35:51PM +0300, Ander Conselvan De Oliveira wrote:
> >> On Fri, 2017-04-07 at 18:12 -0300, Paulo Zanoni wrote:
> >>> Em Qui, 2017-04-06 às 12:15 -0700, Rodr
On Thu, 2017-04-06 at 12:15 -0700, Rodrigo Vivi wrote:
> From: "Kahola, Mika"
>
> DPLL's are defined in DPCLKA_CFGCR0 register (0x6C200). Let's use these
> definitions when computing dpll's for ddi ports.
>
> v2: (Rodrigo) Remove register that was defined in another patch with
> fixed name a
On Thu, 04 May 2017, Michal Wajdeczko wrote:
> We are using some scratch registers in MMIO based send function.
> Make their base and count flexible in preparation of upcoming
> GuC firmware/hardware changes. While around, change cmd len
> parameter verification from WARN_ON to GEM_BUG_ON as we do
On Wed, May 03, 2017 at 05:09:08PM +0300, Ville Syrjälä wrote:
> On Wed, May 03, 2017 at 09:26:38AM +0200, Daniel Vetter wrote:
> > In the previous patch we've implemented hwmode tracking a la i915 for
> > the vblank timestamp calculations. But that was just the basic
> > semantics, i915 has some n
On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
> Explicitly assign the default priority, and give it a name (macro).
>
> Signed-off-by: Chris Wilson
> kref_init(&ctx->ref);
> list_add_tail(&ctx->link, &dev_priv->context_list);
> ctx->i915 = dev_priv;
> + ctx->prior
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Avoid the branch in computing
intel_ring_space()
URL : https://patchwork.freedesktop.org/series/23958/
State : success
== Summary ==
Series 23958v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
On Thu, May 4, 2017 at 4:21 AM, Andy Shevchenko
wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
Chris Wilson writes:
> As the handler is now quite complex, involving a few atomics, the cost
> of the function preamble is negligible in comparison and so we should
> leave the function out-of-line for better I$.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu
On Thu, May 04, 2017 at 02:08:44PM +0100, Chris Wilson wrote:
> Exploit the power-of-two ring size to compute the space across the
> wraparound using a mask rather than a if. Convert to unsigned integers
> so the operation is well defined.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?
On Thu, May 04, 2017 at 10:35:33AM +0200, Arkadiusz Hiler wrote:
> On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote:
> > On Thu, Apr 27, 2017 at 06:30:42PM +0300, David Weinehall wrote:
> > > On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote:
> > > > On Wed, Apr 26, 2017 a
On Thu, May 04, 2017 at 04:17:13PM +0200, Michal Wajdeczko wrote:
> On Thu, May 04, 2017 at 02:08:44PM +0100, Chris Wilson wrote:
> > Exploit the power-of-two ring size to compute the space across the
> > wraparound using a mask rather than a if. Convert to unsigned integers
> > so the operation is
On Thu, May 04, 2017 at 04:17:13PM +0200, Michal Wajdeczko wrote:
> On Thu, May 04, 2017 at 02:08:44PM +0100, Chris Wilson wrote:
> > Exploit the power-of-two ring size to compute the space across the
> > wraparound using a mask rather than a if. Convert to unsigned integers
> > so the operation is
On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
> A good default for garbage entries from the user is to follow the
> default setting of the object (i.e. the PTE). Currently they use the
> uncached entry, and now the only way to accidentally hit uncached
> performance is via explicit
On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
> > Explicitly assign the default priority, and give it a name (macro).
> >
> > Signed-off-by: Chris Wilson
>
>
>
> > kref_init(&ctx->ref);
> > list_add_tail(&ctx->l
Hi,
Running current -git on my laptop (20FB, X1 Carbon gen4, skylake), I get
a lot of the below warnings. Things seem to work fine (in fact it seems
faster in general use than previously), but it's a lot of warning spew.
[ 764.877978] [drm] Atomic update on pipe (A) took 156 us, max time under
On May 04 2017 or thereabouts, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
From: Tvrtko Ursulin
Since the scatterlist length field is an unsigned int, make
sure that sg_alloc_table_from_pages does not overflow it while
coallescing pages to a single entry.
v2: Drop reference to future use. Use UINT_MAX.
v3: max_segment must be page aligned.
v4: Do not rely on compiler t
From: Tvrtko Ursulin
Drivers like i915 benefit from being able to control the maxium
size of the sg coallesced segment while building the scatter-
gather list.
Introduce and export the __sg_alloc_table_from_pages function
which will allow it that control.
v2: Reorder parameters. (Chris Wilson)
From: Tvrtko Ursulin
Scatterlist entries have an unsigned int for the offset so
correct the sg_alloc_table_from_pages function accordingly.
Since these are offsets withing a page, unsigned int is
wide enough.
Also converts callers which were using unsigned long locally
with the lower_32_bits an
From: Tvrtko Ursulin
With the addition of __sg_alloc_table_from_pages we can control
the maximum coallescing size and eliminate a separate path for
allocating backing store here.
Similar to 871dfbd67d4e ("drm/i915: Allow compaction upto
SWIOTLB max segment size") this enables more compact sg lis
On Thu, 4 May 2017 03:09:40 +
"Chen, Xiaoguang" wrote:
> Hi Alex, do you have any comments for this interface?
>
> >-Original Message-
> >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> >Behalf Of Chen, Xiaoguang
> >Sent: Wednesday, May 03, 2017 9:39 AM
On Thu, May 04, 2017 at 04:22:15PM +0300, Jani Nikula wrote:
> On Thu, 04 May 2017, Michal Wajdeczko wrote:
> > We are using some scratch registers in MMIO based send function.
> > Make their base and count flexible in preparation of upcoming
> > GuC firmware/hardware changes. While around, change
On Thursday, May 4, 2017 7:47:21 AM PDT David Weinehall wrote:
> On Thu, May 04, 2017 at 10:35:33AM +0200, Arkadiusz Hiler wrote:
> > Thanks for rephrasing - that's exactly what I am concerned with.
> >
> > Did you just use the MediaSDK as it is - meaning that MOCS entries
> > beyond the set of th
From: Markus Elfring
Date: Thu, 4 May 2017 11:04:45 +0200
Some single characters should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 32
From: Markus Elfring
Date: Thu, 4 May 2017 13:17:10 +0200
Some text was put into a sequence by separate function calls.
Print the same data by two single function calls instead.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
1 file changed, 2 insertions(+),
From: Markus Elfring
Date: Thu, 4 May 2017 14:04:38 +0200
Use space characters at some source code places according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
di
From: Markus Elfring
Date: Thu, 4 May 2017 14:15:00 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: quoted string split across lines
Thus fix the affected source code place.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
From: Markus Elfring
Date: Thu, 4 May 2017 13:20:47 +0200
Some strings which did not contain data format specifications should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
dr
From: Markus Elfring
Date: Thu, 4 May 2017 13:40:53 +0200
Do not use curly brackets at some source code places
where a single statement should be sufficient.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ---
1 file changed, 8 insertions(+), 11 dele
From: Markus Elfring
Date: Thu, 4 May 2017 14:23:32 +0200
Two single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_ge
From: Markus Elfring
Date: Thu, 4 May 2017 14:30:37 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: quoted string split across lines
Thus fix the affected source code place.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
From: Markus Elfring
Date: Thu, 4 May 2017 13:52:19 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written …
Thus fix affected source code places.
== Series Details ==
Series: series starting with [1/4] lib/scatterlist: Fix offset type in
sg_alloc_table_from_pages
URL : https://patchwork.freedesktop.org/series/23969/
State : success
== Summary ==
Series 23969v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
On Thu, May 04, 2017 at 09:26:09AM -0600, Jens Axboe wrote:
> Hi,
>
> Running current -git on my laptop (20FB, X1 Carbon gen4, skylake), I get
> a lot of the below warnings. Things seem to work fine (in fact it seems
> faster in general use than previously), but it's a lot of warning spew.
>
> [
On 05/04/2017 11:42 AM, Ville Syrjälä wrote:
> On Thu, May 04, 2017 at 09:26:09AM -0600, Jens Axboe wrote:
>> Hi,
>>
>> Running current -git on my laptop (20FB, X1 Carbon gen4, skylake), I get
>> a lot of the below warnings. Things seem to work fine (in fact it seems
>> faster in general use than p
David Weinehall writes:
> On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
>> A good default for garbage entries from the user is to follow the
>> default setting of the object (i.e. the PTE). Currently they use the
>> uncached entry, and now the only way to accidentally hit uncached
From: Ville Syrjälä
Turns out our skills in decoding the CLKCFG register weren't good
enough. On this particular elk the answer we got was 400 MHz when
in reality the clock was running at 266 MHz, which then caused us
to program a bogus AUX clock divider that caused all AUX communication
to fail.
== Series Details ==
Series: drm/i915: Fix rawclk readout for g4x
URL : https://patchwork.freedesktop.org/series/23978/
State : success
== Summary ==
Series 23978v1 drm/i915: Fix rawclk readout for g4x
https://patchwork.freedesktop.org/api/1.0/series/23978/revisions/1/mbox/
fi-bdw-5557u t
Hi,
This v4 of the series to add dma_buf import functions for vgem. This version
primarily focuses on adding a new approach for an alternate dma_buf attach
after platformdev was removed.
Thanks,
Laura
Laura Abbott (3):
drm/vgem: Add a dummy platform device
drm/prime: Introduce drm_gem_prime_
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using any available device structure.
Signed-off-by: Laura Abbott
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Reviewed-by: Chris Wilson
Signed-off-by: Laura Abbott
---
v4: Use new drm_gem_prime_import_dev function
---
drivers/gpu/drm/vgem/vgem_drv.c |
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Reviewed-by: Chris Wilson
Signed-off-by: Laura Abbott
---
v4: Switch from the now remo
We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Instead of
deleting them, taking a snapshot allows us to access them after driver
load is completed.
Cc: Oscar Mateo
Cc: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo
== Series Details ==
Series: dma_buf import support for vgem (rev2)
URL : https://patchwork.freedesktop.org/series/23824/
State : success
== Summary ==
Series 23824v2 dma_buf import support for vgem
https://patchwork.freedesktop.org/api/1.0/series/23824/revisions/2/mbox/
Test gem_exec_flush:
1 - 100 of 140 matches
Mail list logo
