Quoting Chunming Zhou (2018-10-19 11:26:41)
> Signed-off-by: Chunming Zhou
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Christian König
> ---
> drivers/gpu/drm/drm_syncobj.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/driv
Quoting Chunming Zhou (2018-10-15 09:55:48)
> This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
> syncobj in kernel side:
> This extension introduces a new type of syncobj that has an integer payload
> identifying a point in a timeline. Such timeline syncobjs support the
Quoting Jani Nikula (2018-10-16 10:59:42)
> On Mon, 15 Oct 2018, Stephen Boyd wrote:
> > When I enable UBSAN and compile this driver with clang I get the
> > following build error:
> >
> > drivers/gpu/drm/i915/intel_engine_cs.o: In function
> > `intel_engine_init_execlist':
> >
Quoting Rodrigo Siqueira (2018-10-08 15:52:20)
> For historical reason, the function drm_wait_vblank_ioctl always return
> -EINVAL if something gets wrong. This scenario limits the flexibility
> for the userspace make detailed verification of the problem and take
> some action. In particular, the
Quoting Maarten Lankhorst (2018-10-02 11:51:45)
> Op 23-08-18 om 00:57 schreef Matt Roper:
> > On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
> >> Add plane alpha blending support with the different blend modes.
> >> This has been tested on a icl to show the correct results,
>
Quoting Jason Ekstrand (2018-09-26 10:43:59)
> On Wed, Sep 26, 2018 at 3:18 AM Chris Wilson wrote:
>
> Quoting Jason Ekstrand (2018-09-26 08:17:03)
> > We attempt to get fences earlier in the hopes that everything will
> > already have fences and no callbacks w
s/gpu/drm/drm_syncobj.c
> @@ -97,6 +97,8 @@ static int drm_syncobj_fence_get_or_add_callback(struct
> drm_syncobj *syncobj,
> {
> int ret;
>
> + WARN_ON(*fence);
I would have just put if (*fence) return; since the function is tied to
the array_wait implementation.
Reviewed-by: Chris
t; like this patch:
>
> commit 70109354fed232dfce8fb2c7cadf635acbe03e19
> Author: Chris Wilson
> Date: Wed Sep 5 16:31:16 2018 +0100
>
> drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
b
Quoting Daniel Vetter (2018-09-21 10:15:41)
> On Tue, Sep 18, 2018 at 11:07:20AM +0100, Chris Wilson wrote:
> > After schedule() returns 0, we must do one last check of COND to
> > determine the reason for the wakeup with 0 jiffies remaining before
> > reporting the timeou
-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_syncobj.c | 41 +--
1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e254f97fed7d..5bcb3ef9b256 100644
--- a/drivers
neglected its RCU protection.
Fixes: e28bd101ae1b ("drm: rename null fence to stub fence in syncobj v2")
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_syncobj.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj
Quoting Chris Chiu (2018-09-19 12:29:33)
> I have few ASUS laptops, X705FD(Intel i7-8565), X560UD(Intel i5-8250U)
> and X530UN(Intel i7-8550U) share the same problem. The HDMI connector
> status stays 'connected' even the HDMI cable has been unplugged.
> Then the status in sysfs would never change
-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 41 +--
1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e254f97fed7d..5bcb3ef9b256 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b
Both the .enable_signaling and .release of the null syncobj fence
can be replaced by the default callbacks for a small reduction in code
size.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm
Quoting José Roberto de Souza (2018-09-17 22:22:44)
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> Cc: C
Quoting Souza, Jose (2018-09-14 17:30:59)
> On Fri, 2018-09-14 at 09:15 +0100, Chris Wilson wrote:
> > Quoting José Roberto de Souza (2018-09-13 23:13:41)
> > > @@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void
> > > *data, struct drm_file *file_priv)
&g
Quoting Chris Wilson (2018-09-13 20:20:50)
> If the ioctl is not supported on a particular piece of HW/driver
> combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily
> distinguished from both the lack of the ioctl and from a regular invalid
> parameter.
>
> v2:
NOTSUP as that is
documented to have the same value as ENOTSUP under Linux. (At least
until somebody decided to make ENOTSUP unique.)
> Cc: Chris Wilson
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_ioctl.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> d
errno says
"ENOTSUP and EOPNOTSUPP have the same value on Linux,
but according to POSIX.1 these error values should be
distinct."
so use EOPNOTSUPP as its equivalent.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
Reviewed-by: Daniel V
Quoting Lucas De Marchi (2018-09-13 19:23:49)
> +Chris
>
> On 9/13/18 12:19 AM, Chih-Wei Huang wrote:
> > Note this patch breaks drm_gralloc:
> >
> > FAILED:
> > out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/libgralloc_drm_intermediates/LINKED/libgralloc_drm.so
> > /bin/bash -c
le currently let's make the code more correct and use
> the per-device driver_features instead.
>
> Cc: Chris Wilson
> Signed-off-by: Ville Syrjälä
One day we will be able to have driver const again,
Reviewed-by: Chris Wilson
-Chris
___
dr
te it (eg. various vfunc assignments). We'll
> need to fix all that up before we can make it const.
>
> And while at it fix up the type of the feature flag passed to
> drm_core_check_feature().
>
> v2: Streamline the && vs. & (Chris)
> s/int/u32/ in drm_core_chec
(most where EINVAL) for a failed
drm_core_check_feature(). Update everybody to report ENOTSUPP.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_bufs.c| 32 +++
drivers/gpu/drm
(most where EINVAL) for a failed
drm_core_check_feature(). Update everybody to report ENOTSUPP.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_bufs.c| 32 +++
drivers/gpu/drm
Quoting Daniel Vetter (2018-09-12 10:02:47)
> On Wed, Sep 12, 2018 at 10:50 AM, Chris Wilson
> wrote:
> > Quoting Daniel Vetter (2018-09-12 09:39:30)
> >> On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson
> >> wrote:
> >> > If the ioctl is not su
Quoting Daniel Vetter (2018-09-12 09:39:30)
> On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson
> wrote:
> > If the ioctl is not supported on a particular piece of HW/driver
> > combination, report ENODEV so that it can be easily distinguished from
> > both the lack of the
If the ioctl is not supported on a particular piece of HW/driver
combination, report ENODEV so that it can be easily distinguished from
both the lack of the ioctl and from a regular invalid parameter.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm
Quoting Lucas De Marchi (2018-09-06 18:51:37)
> On Thu, Sep 06, 2018 at 06:38:52PM +0100, Chris Wilson wrote:
> > Quoting Emil Velikov (2018-09-06 16:14:07)
> > > From: Emil Velikov
> > >
> > > They're used internally and never meant to be part of the API
Quoting Emil Velikov (2018-09-06 16:14:07)
> From: Emil Velikov
>
> They're used internally and never meant to be part of the API.
> Add the drm_private notation, which should resolve that.
>
> Cc: Eric Engestrom
> Cc: Lucas De Marchi
> Cc: Chris Wilson
>
Quoting Chris Wilson (2018-09-05 16:31:16)
> Since this is handling user provided bpp and depth, we need to sanity
> check and propagate the EINVAL back rather than assume what the insane
> client intended and fill the logs with DRM_ERROR.
>
> v2: Check both bpp and depth match th
neric gen macro
> intel: get gen once for gen >= 9
The opens are fine and I didn't find anything else to question, so the
series is
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
to reserve 0 against any future
fourcc.
v3: Mark up DRM_FORMAT_C8 as being {bpp:8, depth:8}
Testcase: igt/kms_addfb_basic/legacy-format
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Michel Dänzer
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fourcc.c | 37
Quoting Chris Wilson (2018-09-05 11:22:05)
> Since this is handling user provided bpp and depth, we need to sanity
> check and propagate the EINVAL back rather than assume what the insane
> client intended and fill the logs with DRM_ERROR.
>
> v2: Check both bpp and depth match th
to reserve 0 against any future
fourcc.
Testcase: igt/kms_addfb_basic/legacy-format
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_fourcc.c | 33 +--
drivers/gpu/drm/drm_framebuffer.c | 7 ++-
include/uapi/drm
Quoting Daniel Vetter (2018-09-04 22:46:33)
> On Tue, Sep 04, 2018 at 09:53:19PM +0100, Chris Wilson wrote:
> > Since this is handling user provided bpp and depth, we need to sanity
> > check and propagate the EINVAL back rather than assume what the insane
> > client inten
Since this is handling user provided bpp and depth, we need to sanity
check and propagate the EINVAL back rather than assume what the insane
client intended and fill the logs with DRM_ERROR.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
So I am presuming
Quoting Daniel Vetter (2018-09-04 14:08:12)
> On Tue, Sep 04, 2018 at 12:57:19PM +0100, Chris Wilson wrote:
> > The ioctl arguments are under control of the user and as such we should
> > resist any temptation to flood the kernel logs with their errors.
> > Relegate the DRM_ER
, so that the concerned process can inspect its own
debug info for EINVAL without them being hitting syslog at all.)
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_vblank.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b
Using a spinlock to serialize the destroy function, within the destroy
function itself does not prevent the buggy driver from shooting
themselves in the foot - either way they still have a use-after-free
issue.
Reported-by: Jia-Ju Bai
Signed-off-by: Chris Wilson
Cc: Davidlohr Bueso
Cc: Liviu
Quoting Jia-Ju Bai (2018-09-01 13:20:41)
> The driver may sleep with holding a spinlock.
>
> The function call paths (from bottom to top) in Linux-4.16 are:
>
> [FUNC] kmalloc(GFP_KERNEL)
> drivers/gpu/drm/drm_mm.c, 130:
> kmalloc in show_leaks
> drivers/gpu/drm/drm_mm.c, 913:
>
Quoting Lucas De Marchi (2018-08-31 17:06:01)
> On Fri, Aug 31, 2018 at 09:16:23AM +0100, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2018-08-29 01:35:28)
> > > +bool intel_is_genx(unsigned int devid, int gen)
> > > +{
> > > + const struct pci_devi
Quoting Daniel Vetter (2018-08-31 10:04:39)
> On Thu, Aug 30, 2018 at 11:00:01PM +0200, Michał Mirosław wrote:
> > This series cleans up duplicated code for replacing firmware FB
> > driver with proper DRI driver and adds handover support to
> > Tegra driver.
> >
> > This is a sligtly updated
Quoting Lucas De Marchi (2018-08-29 01:35:31)
> The 2 PCI IDs that are used for the command line overrid mechanism
> were left defined. The rest can be gone and then we just use the kernel
> defines.
>
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_chipset.c | 5 ++
>
Quoting Lucas De Marchi (2018-08-29 17:01:11)
> On Wed, Aug 29, 2018 at 11:32:35AM +0100, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2018-08-29 01:35:31)
> > > The 2 PCI IDs that are used for the command line overrid mechanism
> > > were left defined.
> >
&g
Quoting Lucas De Marchi (2018-08-29 01:35:28)
> +static const struct pci_device {
> + uint16_t device;
> + uint16_t gen;
> +} pciids[] = {
Add a comment here as well for the ordering requirement.
/* Keep ids sorted by gen; latest gen first */
We're unlikely to notice a comment in
Quoting Lucas De Marchi (2018-08-29 01:35:32)
> We don't need to call IS_GEN() for each gen >= 9: we can rather use the
> new intel_is_genx() helper to iterate the pciids array once.
>
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_bufmgr_gem.c | 8 +---
> intel/intel_decode.c | 8
Quoting Lucas De Marchi (2018-08-29 01:35:31)
> The 2 PCI IDs that are used for the command line overrid mechanism
> were left defined.
What makes them so special? Why not just match on the override devid?
-Chris
___
dri-devel mailing list
Quoting Lucas De Marchi (2018-08-28 02:00:27)
> On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > > index 4a34b7be..8a0e3e76 100644
> &
Quoting Lucas De Marchi (2018-08-27 22:19:54)
> On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > That should help cut down the object size expansion. But longer term I'd
>
> I'm not opposed to turning it
Quoting Lucas De Marchi (2018-08-25 00:56:46)
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 4a34b7be..8a0e3e76 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -568,6 +568,26 @@
>
> #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
>
>
Quoting Christian König (2018-08-09 15:54:31)
> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
> > On Thu, Aug 9, 2018 at 3:58 PM, Christian König
> > wrote:
> >> Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
> >>> On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
> >>> [SNIP]
> >>
.
>
> v2: Protect the meaningful space! (Chris)
>
> Signed-off-by: Daniel Vetter
> Cc: Kees Cook
> Cc: Cihangir Akturk
> Cc: Chris Wilson
> Cc: Sean Paul
> Cc: Daniel Vetter
1-4,
Reviewed-by: Chris Wilson
-Chris
___
dri-devel
Quoting Christian König (2018-08-09 12:37:08)
> void reservation_object_add_shared_fence(struct reservation_object *obj,
> struct dma_fence *fence)
> {
> - struct reservation_object_list *old, *fobj = obj->staged;
> + struct
Quoting Daniel Vetter (2018-08-09 09:33:49)
> On Wed, Jul 04, 2018 at 11:29:08AM +0200, Daniel Vetter wrote:
> > static void vgem_fence_release(struct dma_fence *base)
> > {
> > struct vgem_fence *fence = container_of(base, typeof(*fence), base);
> > @@ -76,11 +66,7 @@ static void
the
fence array.
v4: Drop the fence array ref after assigning to reservation_object
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported
bo's. (v5)")
Signed-off
_atomic and map function pointers
optional")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Sumit Semwal
---
drivers/dma-buf/dma-buf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158.
the
fence array.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported
bo's. (v5)")
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: "Christian König"
Quoting Christian König (2018-08-07 19:18:55)
> Am 07.08.2018 um 20:14 schrieb Chris Wilson:
> > Quoting Christian König (2018-08-07 18:57:16)
> >> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> >>> amdgpu only uses shared-fences internally, but dmabuf importers rely
Quoting Christian König (2018-08-07 18:57:16)
> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers
optional")
mdgpu: Attach exclusive fence to prime exported
bo's. (v5)")
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: "Christian König"
---
This time, hopefully proofread and references complete.
-Chris
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 ---
1 file ch
are signaled (ensuring that we can not
be signaled before the completion of any earlier write).
v2: reservation_object is already locked by amdgpu_bo_reserve()
Testcase: igt/amd_prime/amd-to-i915
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: "Christian König"
---
drivers/gpu/drm/
Quoting Huang Rui (2018-08-07 11:56:24)
> On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the i
are signaled (ensuring that we can not
be signaled before the completion of any earlier write).
v2: reservation_object is already locked by amdgpu_bo_reserve()
Testcase: igt/amd_prime/amd-to-i915
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: "Christian König"
---
drivers/gpu/drm/
are signaled (ensuring that we can not
be signaled before the completion of any earlier write).
Testcase: igt/amd_prime/amd-to-i915
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: "Christian König"
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 70 ---
1 file c
Quoting Manasi Navare (2018-08-03 20:18:42)
> On Tue, Jul 31, 2018 at 10:16:45PM +0100, Chris Wilson wrote:
> > Quoting Manasi Navare (2018-07-31 22:07:06)
> > > + /* PPS 4 */
> > > + pps_sdp->pps_payload.pps_4 =
Quoting Gwan-gyeong Mun (2018-08-03 17:41:50)
Even for trivial patches, always include a changelog. In this case, I
added "Trivial typo, s/loose/lose/, in i915_drm_resume."
> Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Chris Wilson
And pushed, thanks for the spelling corre
Quoting Manasi Navare (2018-07-31 22:07:06)
> + /* PPS 4 */
> + pps_sdp->pps_payload.pps_4 = (u8)((dsc_cfg->bits_per_pixel &
> + DSC_PPS_BPP_HIGH_MASK) >>
> + DSC_PPS_MSB_SHIFT) |
To avoid overhanging
Quoting Souza, Jose (2018-07-17 18:02:17)
> On Tue, 2018-07-17 at 08:28 +0100, Chris Wilson wrote:
> > Quoting José Roberto de Souza (2018-07-16 23:38:36)
> > > GPU accelerators usually don't have display block or the display
> > > driver part can be disable when
Quoting José Roberto de Souza (2018-07-16 23:38:36)
> GPU accelerators usually don't have display block or the display
> driver part can be disable when building driver(for servers it save
> some resources) so it is important let userspace check this
> capability too.
We currently communicate
Quoting José Roberto de Souza (2018-07-16 23:38:38)
> @@ -1395,9 +1379,22 @@ int i915_driver_load(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> goto out_cleanup_hw;
> }
>
> + ret = intel_irq_install(dev_priv);
> + if (ret)
> +
Quoting Gustavo A. R. Silva (2018-07-16 13:39:33)
> err is assigned to -EIO, but this value is never actually
> used and *err* is updated later on.
>
> Remove such reduntant code.
The mistake is that err is lost, possible masking the test failure.
Looks like the unwind needs to be refactored?
Quoting Jordan Crouse (2018-07-12 19:59:25)
> Do a bit of cleanup to prepare for upcoming changes to pass the
> hanging task comm and cmdline to the crash dump function.
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 18 ++
> 1 file changed, 10
Quoting Jordan Crouse (2018-07-12 19:59:24)
> Convert the existing GPU show function to use the GPU state to
> dump the information rather than reading it directly from the hardware.
> This will require an additional step to capture the state before
> dumping it for the existing nodes but it will
Quoting Jordan Crouse (2018-07-12 19:59:22)
> Add a put function for the coredump printer to bypass printf()
> for constant strings for a speed boost.
>
> v2: Add EXPORT_SYMBOL for _drm_puts_coredump
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/drm_print.c | 43
Quoting Jordan Crouse (2018-07-12 19:59:19)
> Add a drm printer suitable for use with the read callback for
> devcoredump or other suitable buffer based output format that
> isn't otherwise covered by seq_file.
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/drm_print.c | 74
r_puts -> err_puts pointed out by the 01.org bot
> v2: Update API to be cleaner for the caller as suggested by Chris Wilson
>
> Signed-off-by: Jordan Crouse
> ---
> +static inline long
> +ascii85_encode_len(long len)
> +{
> + return DIV_ROUND_UP(len, 4);
> +}
&g
Quoting Dominique Martinet (2018-07-12 00:24:46)
> Change it to use strlcpy instead
>
> Signed-off-by: Dominique Martinet
Thanks for the spotting the issue and providing a fix, pushed.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Quoting Dominique Martinet (2018-07-12 00:24:46)
> Change it to use strlcpy instead
>
> Signed-off-by: Dominique Martinet
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.or
Quoting Dominique Martinet (2018-07-11 08:46:15)
> This is effectively no-op as the next line writes a nul at the final
> byte of the buffer, so copying one letter less does not change the
> behaviour.
>
> Signed-off-by: Dominique Martinet
> ---
>
> gcc 8 gives the following warning, which I am
Quoting Haneen Mohammed (2018-07-09 16:44:26)
> +struct page **get_pages(struct vkms_gem_object *vkms_obj)
> +{
> + struct drm_gem_object *gem_obj = _obj->gem;
> + struct page **pages = vkms_obj->pages;
> +
> + if (!pages) {
> + mutex_lock(_obj->pages_lock);
> +
Quoting Rodrigo Siqueira (2018-06-21 13:16:13)
> VKMS currently does not handle dumb data, and as a consequence, it does
> not provide mechanisms for handling gem. This commit adds the necessary
> support for gem object/handler and the dumb functions.
I may have been naive, but I didn't think
Quoting Rodrigo Siqueira (2018-07-05 17:28:20)
> Hi and thanks for all the feedback, I will work on the suggestions you sent,
> but I have some doubts:
>
> On 07/05, Chris Wilson wrote:
> > Quoting Daniel Vetter (2018-07-05 09:20:13)
> > > On Thu, Jul 05, 2018 a
Quoting Jani Nikula (2018-07-05 09:58:57)
> On Thu, 05 Jul 2018, Chris Chiu wrote:
> > Hi,
> > We have few ASUS laptops X705FD (The new WiskyLake), X560UD (intel
> > i5-8250U), X530UN (intel i7-8550U) share the same problem, which is
> > the HDMI connector status stays connected even the HDMI
Quoting Daniel Vetter (2018-07-05 09:20:13)
> On Thu, Jul 05, 2018 at 12:48:43AM -0300, Rodrigo Siqueira wrote:
> > + ktime_t current_timestamp;
> > +
> > + hrtimer_init(>vblank_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>
> Can't we use absolute timer mode here? That avoids all the
Quoting Daniel Vetter (2018-07-03 08:03:09)
> On Mon, Jul 02, 2018 at 12:52:31PM +0300, Ville Syrjälä wrote:
> > On Mon, Jul 02, 2018 at 09:46:23AM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 28, 2018 at 10:43:01PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > We only
l
> reservation_object_reserve_shared before).
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michel Dänzer
I've convinced myself (or rather have not found a valid argument
against) that being able to call reserve_shared + add_shared multiple
times for the same fence is an intended
Quoting Michal Hocko (2018-06-22 16:02:42)
> Hi,
> this is an RFC and not tested at all. I am not very familiar with the
> mmu notifiers semantics very much so this is a crude attempt to achieve
> what I need basically. It might be completely wrong but I would like
> to discuss what would be a
Quoting Gustavo Padovan (2018-06-22 11:04:16)
> Hi Akhil,
>
> On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote:
> > Each fence object holds function pointers of the module that
> > initialized
> > it. Allowing the module to unload before this fence's release is
> > catastrophic. So, keep a
Quoting Koenig, Christian (2018-06-20 17:28:33)
>
>
> Am 20.06.2018 18:22 schrieb Chris Wilson :
>
> Fix i915's CI build after the removal of the dmabuf->kmap interface that
> left the mock routines intact.
>
> In file included from drivers/gpu/drm/i
buf *dma_buf, unsigned long
page_num)
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
---
drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 12
1 file changed, 12 deletions(-
reject in the call to create the mmap (with a sanity check
in the fault handler).
v2: Check the vma->vm_flags during mmap() to allow readonly access.
v3: Remove VM_MAYWRITE to curtail mprotect()
Testcase: igt/gem_userptr_blits/readonly_mmap*
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Quoting Bloomfield, Jon (2018-06-14 17:36:29)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Thursday, June 14, 2018 9:07 AM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Chris Wilson
> > ;
> > Bloom
reject in the call to create the mmap (with a sanity check
in the fault handler).
v2: Check the vma->vm_flags during mmap() to allow readonly access.
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: Joonas Lahtinen
Cc: Matthew Auld
Cc: David Herrmann
---
drivers/gpu/drm/drm_ge
Quoting Daniel Rosenberg (2018-06-06 00:40:41)
> The format specifier %p can leak kernel addresses
> while not valuing the kptr_restrict system settings.
> Use %pK instead of %p, which also evaluates whether
> kptr_restrict is set.
This is backwards though. You never care about the actual value
, we convert into the cached rbtree variant
which tracks the leftmost node for us. However, currently we sorted into
ascending size order so the leftmost node is the smallest, and so to
make it the largest hole we need to invert our sorting.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk&
be
the best split, start with a request to try once at most. That is return
the top-most (or lowest) hole if it fulfils the alignment and size
requirements.
v2: Documentation, by why of example (selftests) and kerneldoc.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Joonas La
If we can use an unmappable ring, try to pin it out of the mappable
aperture. This simple layout preference is to try and keep the mappable
aperture reserved and available to handle GGTT mmapping requests from
userspace without causing evictions and GPU stalls.
Signed-off-by: Chris Wilson <
() both degrade to a slow rbtree walk after their
small cache is exhausted). For the real world, the number of search
steps is unlikely to be significant as we should only need to search
once per new context.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joo
Quoting Joonas Lahtinen (2018-05-18 11:05:36)
> Quoting Chris Wilson (2018-05-13 10:50:09)
> > To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> > times), doing a search by address over a pathologically fragmented
> > address space is exceeding slow.
701 - 800 of 3670 matches
Mail list logo
