On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework. It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area. It
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82113/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9057_full -> Patchwork_18577_full
Summary
---
On Fri, 2020-09-25 at 15:17 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> intel_{enable,disable}_sagv() are no longer needed outside the
> compilation unit. Make them static.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä <
>
On Fri, 2020-09-25 at 15:17 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> Move the intel_crtc_atomic_check() call out from the variable
> declarations to a place where we can actually see it.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by:
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82113/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9057 -> Patchwork_18577
Summary
---
**WARNING**
== Series Details ==
Series: series starting with [01/11] mm: update the documentation for vfree
(rev2)
URL : https://patchwork.freedesktop.org/series/82063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9057_full -> Patchwork_18576_full
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82113/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ea290b73bdf2 drm/i915/guc: Update to use firmware v49.0.1
-:231: WARNING:LONG_LINE: line length of 103 exceeds 100
From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 31 ---
1 file changed, 22
From: Daniele Ceraolo Spurio
This will enable HuC loading for Gen11+ by default if the binaries
are available on the system. GuC submission still requires explicit
enabling by the user.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer
From: John Harrison
Update to the latest GuC firmware and enable by default.
Signed-off-by: John Harrison
Daniele Ceraolo Spurio (1):
drm/i915/uc: turn on GuC/HuC auto mode by default
John Harrison (3):
drm/i915/guc: Update to use firmware v49.0.1
drm/i915/guc: Improved reporting when
From: John Harrison
Was hitting null pointers and similar issues when running various
module load/unload and inject failure type tests. So clear those
pointers down when the objects have been de-allocated.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 1 +
== Series Details ==
Series: drm/i915: Finish (de)gamma readout prep bits
URL : https://patchwork.freedesktop.org/series/82099/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18575_full
Summary
Hi Thomas,
On Fri, Sep 25, 2020 at 01:55:57PM +0200, Thomas Zimmermann wrote:
> Dma-buf provides vmap() and vunmap() for retriving and releasing mappings
> of dma-buf memory in kernel address space. The functions operate with plain
> addresses and the assumption is that the memory can be accessed
== Series Details ==
Series: Add support for DP-HDMI2.1 PCON
URL : https://patchwork.freedesktop.org/series/82098/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18574_full
Summary
---
== Series Details ==
Series: series starting with [1/2] drm/i915: Make intel_{enable,
disable}_sagv() static
URL : https://patchwork.freedesktop.org/series/82096/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18573_full
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
URL : https://patchwork.freedesktop.org/series/81647/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18572_full
On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> cc back a few others who were unintentionally dropped from the thread
> earlier.
>
> Someone (at Google) helped me dig into this a little more and they
> found a document titled "eDP Backlight Brightness bit alignment" sent
> out for
On Fri, Sep 25, 2020 at 07:02:47PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> > Add the helpers and register definitions needed to read out the common
> > and per-PHY LTTPR capabilities and perform link training in the LTTPR
> > non-transparent mode.
== Series Details ==
Series: series starting with [01/11] mm: update the documentation for vfree
(rev2)
URL : https://patchwork.freedesktop.org/series/82063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9057 -> Patchwork_18576
On Fri, Sep 25, 2020 at 07:03:50PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 24, 2020 at 09:48:04PM +0300, Imre Deak wrote:
> > By default LTTPRs should be in transparent link training mode,
> > nevertheless in this patch we switch to this default mode explicitly.
> >
> > The DP Standard
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which
On Thu, Sep 24, 2020 at 09:48:04PM +0300, Imre Deak wrote:
> By default LTTPRs should be in transparent link training mode,
> nevertheless in this patch we switch to this default mode explicitly.
>
> The DP Standard recommends this, supposedly because an LTTPR may be left
> in the non-transparent
On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> Add the helpers and register definitions needed to read out the common
> and per-PHY LTTPR capabilities and perform link training in the LTTPR
> non-transparent mode.
>
> v2:
> - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR()
On Fri, Sep 25, 2020 at 03:08:59PM +0100, Matthew Auld wrote:
> > + i = 0;
> > + for_each_sgt_page(page, iter, obj->mm.pages)
> > + pages[i++] = page;
> > + vaddr = vmap(pages, n_pages, 0, pgprot);
> > + if (pages != stack)
> > + kvfree(pages);
>
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock
requirement for execution callbacks"
URL : https://patchwork.freedesktop.org/series/82091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18571_full
Hi all,
Friendly ping: who can take this?
Thanks
--
Gustavo
On 9/10/20 05:21, Gustavo A. R. Silva wrote:
> Fix inconsistent IS_ERR and PTR_ERR in i915_gem_object_copy_blt().
>
> The proper pointer to be passed as argument to PTR_ERR() is vma[1].
>
> This bug was detected with the help of
On Fri, Sep 25, 2020 at 01:29:49PM +0100, Tvrtko Ursulin wrote:
>
> On 25/09/2020 12:58, Jason Gunthorpe wrote:
> > On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 25/09/2020 08:13, Leon Romanovsky wrote:
> > > > On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
> > > diff --git a/tools/testing/scatterlist/main.c
> > > b/tools/testing/scatterlist/main.c
> > > index 0a1464181226..4899359a31ac 100644
> > > +++ b/tools/testing/scatterlist/main.c
> > > @@ -55,14 +55,13 @@ int main(void)
> > >
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int
On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote:
>
> On 25/09/2020 08:13, Leon Romanovsky wrote:
> > On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 22/09/2020 09:39, Leon Romanovsky wrote:
> > > > From: Maor Gottlieb
> > > >
> > > > Extend
On 9/25/2020 2:41 PM, Tvrtko Ursulin wrote:
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG
On 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index
On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replace the last call to alloc_vm_area with an open coded version using
> an iterator in struct gnttab_vm_area instead of the triple indirection
> magic in alloc_vm_area.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
> allows to fill put the phys_addr values directly instead of doing
> another loop over all addresses.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
-boris
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82086/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18570_full
Quoting Tvrtko Ursulin (2020-09-25 14:19:22)
>
> On 25/09/2020 11:01, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-09-24 14:43:08)
> >>
> >> On 16/09/2020 10:42, Chris Wilson wrote:
> >>> Currently, we check we can send a pulse prior to disabling the
> >>> heartbeat to verify that we can
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical
On 25/09/2020 14:39, Maor Gottlieb wrote:
On 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
== Series Details ==
Series: drm/i915: Finish (de)gamma readout prep bits
URL : https://patchwork.freedesktop.org/series/82099/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18575
Summary
---
From: Ville Syrjälä
Dump the sizes of the software LUTs in the state dump. Makes
it a bit easier to see which is present without having to
decode it from the gamma_mode and other bits of state.
v2: Drop a spurious "is" in commit msg (Uma)
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
== Series Details ==
Series: drm/i915: Finish (de)gamma readout prep bits
URL : https://patchwork.freedesktop.org/series/82099/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
On 25/09/2020 11:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-09-24 15:26:56)
On 16/09/2020 10:42, Chris Wilson wrote:
Verify that if a context is active at the time it is closed, that it is
either persistent and preemptible (with hangcheck running) or it shall
be removed from
From: Ville Syrjälä
Previously intel_dump_pipe_config() used to dump the full crtc state
whether or not the crtc was logically enabled or not. As that meant
occasionally dumping confusing stale garbage I changed it to
check whether the crtc is logically enabled or not. However I did
not realize
From: Ville Syrjälä
The easy prep stuff from my earlier (de)gamma readout series.
All reviewed already by Uma (thanks). The rest of that series
still needs some work.
Ville Syrjälä (9):
drm/i915: Fix state checker hw.active/hw.enable readout
drm/i915: Move MST master transcoder dump earlier
== Series Details ==
Series: Add support for DP-HDMI2.1 PCON
URL : https://patchwork.freedesktop.org/series/82098/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18574
Summary
---
**SUCCESS**
No
On 25/09/2020 11:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-09-24 14:43:08)
On 16/09/2020 10:42, Chris Wilson wrote:
Currently, we check we can send a pulse prior to disabling the
heartbeat to verify that we can change the heartbeat, but since we may
re-evaluate execution upon
From: Ville Syrjälä
glk_read_lut_10() works just fine for all bdw+ platforms, so
rename it.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Move chv_cgm_gamma_pack() next to the other CGM gamma functions.
Right now it's stuck in the middle of the CGM degamma functions.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 14 +++---
1 file changed, 7
From: Ville Syrjälä
Since bdw_read_lut_10() uses the auto-increment mode we must
have an equal number of entries in the software LUT and the
hardware LUT. WARN if that is not the case.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 7
From: Ville Syrjälä
Move the MST master transcoder dump next to the other transcoder
bits.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Just for some extra consistency let's reset the glk degamma LUT
index back to 0 after we're dong trawling the LUT.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 6 +-
1 file changed, 5 insertions(+), 1
From: Ville Syrjälä
CGM_PIPE_GAMMA_RED_MASK & co. are misplaced. Move then below the
relevant register. And while at it add the degamma counterparts.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 ++---
1 file changed, 6 insertions(+), 3
From: Ville Syrjälä
Since gamma_mode can have more than two values on ilk+
let's use switch statements when interpreting them.
v2: Fix typo (Uma)
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 92 --
1 file changed,
On 24/09/2020 14:58, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that
On 24/09/2020 14:58, Christoph Hellwig wrote:
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap
On 24/09/2020 14:58, Christoph Hellwig wrote:
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
== Series Details ==
Series: Add support for DP-HDMI2.1 PCON
URL : https://patchwork.freedesktop.org/series/82098/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Add support for DP-HDMI2.1 PCON
URL : https://patchwork.freedesktop.org/series/82098/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ca36191ea8ce drm/edid: Add additional HFVSDB fields for HDMI2.1
-:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing
== Series Details ==
Series: series starting with [1/2] drm/i915: Make intel_{enable,
disable}_sagv() static
URL : https://patchwork.freedesktop.org/series/82096/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18573
== Series Details ==
Series: series starting with [1/2] drm/i915: Make intel_{enable,
disable}_sagv() static
URL : https://patchwork.freedesktop.org/series/82096/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
URL : https://patchwork.freedesktop.org/series/81647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18572
Summary
On 25/09/2020 12:58, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote:
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299
The details are mentioned in DP to HDMI2.1 PCON Enum/Config
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 305
include/drm/drm_dp_helper.h | 81 +
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.
Signed-off-by: Ankit Nautiyal
---
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
From: Ville Syrjälä
Move the intel_crtc_atomic_check() call out from the variable
declarations to a place where we can actually see it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
intel_{enable,disable}_sagv() are no longer needed outside the
compilation unit. Make them static.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
URL : https://patchwork.freedesktop.org/series/81647/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
URL : https://patchwork.freedesktop.org/series/81647/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c94eaf86e18e dma-buf: Add struct dma-buf-map for storing struct
dma_buf.vaddr_ptr
-:47:
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock
requirement for execution callbacks"
URL : https://patchwork.freedesktop.org/series/82091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18571
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is
This patch adds struct dma_buf_map and its helpers to the documentation. A
short tutorial is included.
v3:
* update documentation in a separate patch
* expand docs (Daniel)
* carry-over acks from patch 1
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
Dma-buf provides vmap() and vunmap() for retriving and releasing mappings
of dma-buf memory in kernel address space. The functions operate with plain
addresses and the assumption is that the memory can be accessed with load
and store operations. This is not the case on some architectures (e.g.,
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock
requirement for execution callbacks"
URL : https://patchwork.freedesktop.org/series/82091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e9ed1a8a1759 drm/i915: Redo "Remove
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers
Hi
Am 23.09.20 um 16:27 schrieb Christian König:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
>> The new type struct dma_buf_map represents a mapping of dma-buf memory
>> into kernel space. It contains a flag, is_iomem, that signals users to
>> access the mapped memory with I/O operations
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82086/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18570
Quoting Chris Wilson (2020-08-13 00:33:00)
> We expose the heartbeat interval on each engine, allowing the sysadim to
> disable them if they prefer avoiding any interruption for their GPU
> tasks. A caveat to allowing the contexts to run without checks is that
> we require such contexts to be
Quoting Chris Wilson (2020-09-16 12:42:17)
> We only allow persistent requests to remain on the GPU past the closure
> of their containing context (and process) so long as they are continuously
> checked for hangs or allow other requests to preempt them, as we need to
> ensure forward progress of
On Thu, Sep 24, 2020 at 08:43:33PM +, Souza, Jose wrote:
> On Thu, 2020-09-24 at 22:48 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> >
> > Implement display w/a #1142. This supposedly fixes some underruns
> > with FBC+VTd. Bspec says we should
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82086/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6e02c964a485 drm/atomic: document and enforce rules
The reordering and rebasing of commit 2e4c6c1a9db5 ("drm/i915: Remove
i915_request.lock requirement for execution callbacks") caused it to
revert an earlier correction. Let us restore commit 99f0a640d464
("drm/i915: Remove requirement for holding i915_request.lock for
breadcrumbs")
Fixes:
We have to be very careful while walking the timeline->requests list
under the RCU guard, as the requests (and so rq->link) use
SLAB_TYPESAFE_BY_RCU and so the requests may be reallocated within an
rcu grace period. As the requests are reallocated, they are removed from
one list and placed on
Quoting Tvrtko Ursulin (2020-09-24 15:26:56)
>
> On 16/09/2020 10:42, Chris Wilson wrote:
> > Verify that if a context is active at the time it is closed, that it is
> > either persistent and preemptible (with hangcheck running) or it shall
> > be removed from execution.
> >
> > Fixes:
Quoting Tvrtko Ursulin (2020-09-24 14:43:08)
>
> On 16/09/2020 10:42, Chris Wilson wrote:
> > Currently, we check we can send a pulse prior to disabling the
> > heartbeat to verify that we can change the heartbeat, but since we may
> > re-evaluate execution upon changing the heartbeat interval we
On Fri, Sep 25, 2020 at 09:41:48AM +0100, Chris Wilson wrote:
> We can only assigned random addresses with impunity if we know we have
> complete control over the ppGTT. If the ppGTT is shared, either aliased
> with the global GTT or simply the global GTT on ancient HW, then we have
> to be
On Fri, 25 Sep 2020 10:46:51 +0200
Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
>
> v2: Move misplaced hunk to the right patch (Pekka)
Hi,
both patches
Acked-by: Pekka Paalanen
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
v2: Move misplaced hunk to the right patch (Pekka)
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other
On Fri, Sep 25, 2020 at 11:24:46AM +0300, Pekka Paalanen wrote:
> On Wed, 23 Sep 2020 17:18:52 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global
We can only assigned random addresses with impunity if we know we have
complete control over the ppGTT. If the ppGTT is shared, either aliased
with the global GTT or simply the global GTT on ancient HW, then we have
to be careful in case they are objects already fixed in place inside the
GTT, e.g.
1 - 100 of 104 matches
Mail list logo
