Re: [Freedreno] [PATCH v3 00/23] drm/msm: de-struct_mutex-ification

On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote: > > From: Rob Clark > > This doesn't remove *all* the struct_mutex, but it covers the worst > of it, ie. shrinker/madvise/free/retire. The submit path still uses > struct_mutex, but it still needs *something* serialize a portion of > the submit

Re: [Freedreno] [PATCH v3 07/23] drm/msm/submit: Move copy_from_user ahead of locking bos

On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote: > > From: Rob Clark > > We cannot switch to using obj->resv for locking without first moving all > the copy_from_user() ahead of submit_lock_objects(). Otherwise in the > mm fault path we aquire mm->mmap_sem before obj lock, but in the submit >

Re: [Freedreno] [PATCH v3 06/23] drm/msm/gem: Move locking in shrinker path

On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote: > > From: Rob Clark > > Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to > skip over bo's that are already locked. This gets rid of the nested > lock classes. > > Signed-off-by: Rob Clark > --- >

Re: [Freedreno] [PATCH 00/14] drm/msm: de-struct_mutex-ification

On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote: > > From: Rob Clark > > This doesn't remove *all* the struct_mutex, but it covers the worst > of it, ie. shrinker/madvise/free/retire. The submit path still uses > struct_mutex, but it still needs *something* serialize a portion of > the submit

Re: [PATCH 13/14] drm/msm: Drop struct_mutex in shrinker path

On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote: > > On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote: > > > > On Sun, 4 Oct 2020 12:21:45 > > > From: Rob Clark > > > > > > Now that the inactive_list is protected by mm_lock, and everything > > > else on per-obj basis is protected

Re: [Freedreno] [PATCH 2/3] drm/msm: Convert shrinker msgs to tracepoints

On Tue, Sep 1, 2020 at 8:41 AM Rob Clark wrote: > > From: Rob Clark > > This reduces the spam in dmesg when we start hitting the shrinker, and > replaces it with something we can put on a timeline while profiling or > debugging system issues. That is a good solution, Reviewed-by: Kristian H.

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Thu, Feb 27, 2020 at 7:38 PM Dave Airlie wrote: > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote: > > > > Hi all, > > > > You might have read the short take in the X.org board meeting minutes > > already, here's the long version. > > > > The good news: gitlab.fd.o has become very popular

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

On Tue, Jan 14, 2020 at 8:41 AM Rob Clark wrote: > > On Tue, Jan 14, 2020 at 7:58 AM Jordan Crouse wrote: > > > > On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote: > > > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse > > > wrote: > > > > > > > > On Mon, Jan 13, 2020 at

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

On Mon, Jan 13, 2020 at 3:17 PM Rob Clark wrote: > > On Mon, Jan 13, 2020 at 2:55 PM Brian Ho wrote: > > > > On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote: > > > On Mon, Jan 13, 2020 at 8:25 AM Rob Clark wrote: > > > > > > > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho wrote:

Re: [Freedreno] [PATCH 2/3] drm/msm/dpu: Avoid a null de-ref while recovering from kms init fail

On Tue, May 7, 2019 at 12:18 PM Jordan Crouse wrote: > > In the failure path for dpu_kms_init() it is possible to get to the MMU > destroy function with uninitialized MMU structs. Check for NULl and skip s/NULl/NULL > if needed. > > Signed-off-by: Jordan Crouse Reviewed-by: Kristian H.

Re: [Freedreno] [PATCH v1 2/3] drm/msm: Print all 64 bits of the faulting IOMMU address

On Tue, May 7, 2019 at 11:02 AM Jordan Crouse wrote: > > When we move to 64 bit addressing for a5xx and a6xx targets we will start > seeing pagefaults at larger addresses so format them appropriately in the > log message for easier debugging. Yes please, this has confused me more than once.

Re: [Freedreno] [PATCH] drm/msm: fix handling of cmdstream offset

On Mon, Oct 15, 2018 at 10:33 AM Rob Clark wrote: > > Userspace hasn't used submit cmds with submit_offset != 0 for a while, > but this starts cropping up again with cmdstream sub-buffer-allocation > in libdrm_freedreno. > > Doesn't do much good to increment the buf ptr before assigning it.

Re: [ANNOUNCE] libdrm 2.4.94

On Fri, Aug 24, 2018 at 1:13 AM Michel Dänzer wrote: > > On 2018-08-24 12:37 a.m., Kristian H. Kristensen wrote: > > Benjamin Gaignard (2): > > tests/modetest: Add atomic support > > tests/util: Add support for stm module > > > > Christian König (7): > > amdgpu: stop using the

Re: [ANNOUNCE] libdrm 2.4.94

On Thu, Aug 23, 2018 at 10:44 PM Laurent Carlier wrote: > > Le vendredi 24 août 2018, 00:37:51 CEST Kristian H. Kristensen a écrit : > > https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2 > > -> Forbidden > > You don't have permission to access /libdrm/libdrm-2.4.94.tar.bz2 on this >

Re: [PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu

On Mon, Jun 11, 2018 at 11:26 AM Jordan Crouse wrote: > > Now that the IOMMU is the master of it's own power we don't need to bring > up the GPU to do IOMMU operations. This is good because bringing up a6xx > requires the GMU so calling pm_runtime_get_sync() too early in the process > gets us

Re: [PATCH] drm/rockchip: Filter out alpha formats for primary plane

On Mon, Apr 16, 2018 at 2:59 PM Eric Anholt wrote: > "Kristian H. Kristensen" writes: > > Rockchip doesn't support per-pixel alpha blending for the lowest > > window in the stack. While the hw supports restacking the windows, we > > don't expose that in

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

< hoegsb...@google.com> wrote: > >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico < mvicom...@nvidia.com> wrote: > >>>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg < hoegsb...@gmail.com> wrote: > >>>>> I'd like to see concret

Re: [Intel-gfx] i915 PSR test results and cursor lag

On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson wrote: > Quoting Andy Lutomirski (2018-02-01 17:40:22) > > *However*, I do see one unfortunate side effect of turning on PSR. It > > seems that, when I move my cursor a little bit after a few seconds of > > doing nothing,

Re: [Mesa-dev] [ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept)

On Thu, Dec 21, 2017 at 6:21 AM, Ville Syrjälä wrote: > Here's a quick proof of concept implementation of HDR support > for Wayland/Weston/Mesa. > > I'm not posting this as patches right now because I'm not sure > that would do much good given how rough this is. But

Re: [PATCH] drm/framebuffer: Add framebuffer debugfs file

On Tue, Oct 24, 2017 at 9:39 AM, Noralf Trønnes <nor...@tronnes.org> wrote: > > Den 23.10.2017 23.32, skrev Kristian Høgsberg: >> >> On Mon, Oct 23, 2017 at 9:47 AM, Noralf Trønnes <nor...@tronnes.org> >> wrote: >>> >>> Add debugfs file

Re: [PATCH] drm/framebuffer: Add framebuffer debugfs file

On Mon, Oct 23, 2017 at 9:47 AM, Noralf Trønnes wrote: > Add debugfs file that dumps info about the framebuffers and its planes. > Also dump info about any connected gem object(s). > > Signed-off-by: Noralf Trønnes > --- > drivers/gpu/drm/drm_debugfs.c

Re: [PATCH v2] drm/rockchip: Use an enum to identify Rockchip VOPs

On Wed, Oct 18, 2017 at 5:49 PM, Mark yao wrote: > On 2017年10月19日 01:52, Brian Norris wrote: >> >> Hi Kristian, >> >> On Thu, Nov 03, 2016 at 12:46:48PM -0700, Kristian Högsberg wrote: >>> >>> We used to call drm_of_encoder_active_endpoint_id() from >>>

Re: [PATCH libdrm] modetest: Decode IN_FORMATS plane blob property

On Thu, Sep 28, 2017 at 4:44 PM, Kristian H. Kristensen wrote: > This teaches modetest about the new IN_FORMATS blob and decodes the > blob to show supported formats and modifiers. > > Signed-off-by: Kristian H. Kristensen I went ahead and pushed

Re: [PATCH libdrm v2] Header: Add rotation property fields

On Tue, Apr 18, 2017 at 11:03 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 18 April 2017 at 18:38, Kristian Høgsberg <hoegsb...@gmail.com> wrote: >> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss <robert.f...@collabora.com> >> wrote: >>&

Re: [PATCH libdrm v2] Header: Add rotation property fields

On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss wrote: > From: Sean Paul > > From drm_crtc.h, for use with the plane "rotation" property. > > Signed-off-by: Sean Paul > Signed-off-by: Robert Foss >

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfons...@vmware.com> wrote: > On 24/03/17 19:10, Kristian Høgsberg wrote: >> >> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfons...@vmware.com> wrote: >>> >>> On 23/03/17 01:38, Rob Clark wrote: &

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca wrote: > On 23/03/17 01:38, Rob Clark wrote: >> >> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray wrote: >>> >>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote: On Wed, Mar 22, 2017 at 12:40

[PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2

On Wed, Dec 21, 2016 at 7:42 AM Rob Clark wrote: > On Wed, Dec 21, 2016 at 4:19 AM, Ville Syrjälä > wrote: > > On Wed, Dec 21, 2016 at 10:15:15AM +0100, Daniel Vetter wrote: > >> On Tue, Dec 20, 2016 at 07:46:12PM -0500, Rob Clark wrote: > >> > On Tue, Dec 20, 2016 at 7:12 PM, Kristian H.

[PATCH] drm_fourcc: Document linear modifier

Did we forget about this one? I guess I could commit it myself, but I'm not sure which branch to push it too... Kristian On Wed, Nov 9, 2016 at 4:10 PM Kristian Kristensen wrote: > On Wed, Nov 9, 2016 at 4:36 AM, Daniel Vetter > wrote: > > Not setting the fb modifiers flag is something

[PATCH] drm/rockchip: Use an enum to identify Rockchip VOPs

On Thu, Nov 3, 2016 at 8:47 AM Sean Paul wrote: > On Tue, Nov 1, 2016 at 3:41 PM, Kristian H. Kristensen > wrote: > > We used to call drm_of_encoder_active_endpoint_id() from > > rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the > > active encoder. However, the encoder

[PATCH] Add drmModeAddFB2WithModifiers() which takes format modifiers

On Tue, Sep 13, 2016 at 3:59 PM, Rob Clark wrote: > On Tue, Sep 13, 2016 at 6:07 PM, Kristian H. Kristensen > wrote: >> The only current user of this open codes the ioctl. Let's add an entry >> point for this to libdrm. >> >> Signed-off-by: Kristian H. Kristensen >> --- >> xf86drmMode.c | 21

[PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

Why is this useful if only root can use it? Kristian On Wed, Jul 20, 2016 at 12:39 PM, Chris Wilson wrote: > When performing driver testing, one factor we want to test is how we > handle a foreign fence that is never signaled. We can wait on that fence > indefinitely, in which case the driver

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

Kristian Høgsberg writes: > "Song, Ruiling" writes: > >>> -Original Message- >>> From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf Of >>> Kristian H?gsberg >>> Sent: Monday, December 14, 2015 1:34 PM >>> To: Song, Ruiling >>> Cc: Winiarski, Michal ; intel- >>> gfx

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

"Song, Ruiling" writes: >> -Original Message- >> From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf Of >> Kristian H?gsberg >> Sent: Monday, December 14, 2015 1:34 PM >> To: Song, Ruiling >> Cc: Winiarski, Michal ; intel- >> gfx at lists.freedesktop.org; mesa-dev at

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

"Song, Ruiling" writes: >> -Original Message- >> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel >> Vetter >> Sent: Monday, December 14, 2015 4:28 PM >> To: Song, Ruiling >> Cc: krh at bitplanet.net; Winiarski, Michal ; >> mesa-dev at lists.freedesktop.org;

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling wrote: >> -Original Message- >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf >> Of Micha? Winiarski >> Sent: Wednesday, September 9, 2015 10:07 PM >> To: intel-gfx at lists.freedesktop.org >> Cc: Ben Widawsky

[Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

On Fri, Dec 4, 2015 at 6:24 AM, Michel Thierry wrote: > On 11/18/2015 10:53 PM, Kristian Høgsberg wrote: >> >> On Wed, Oct 14, 2015 at 5:11 AM, Michel Thierry >> wrote: >>> >>> On 10/14/2015 8:19 AM, Daniel Vetter wrote: On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian

[Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

On Wed, Oct 14, 2015 at 5:11 AM, Michel Thierry wrote: > On 10/14/2015 8:19 AM, Daniel Vetter wrote: >> >> On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian Høgsberg wrote: >>> >>> On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry >>> wrote: On 10/13/2015 3:13 PM, Emil Velikov wrote:

[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry wrote: > On 10/13/2015 3:13 PM, Emil Velikov wrote: >> >> On 13 October 2015 at 13:16, Michel Thierry >> wrote: >>> >>> On 10/6/2015 2:12 PM, Michel Thierry wrote: On 10/5/2015 7:06 PM, Kristian Høgsberg wrote: > > > On

[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry wrote: > On 9/14/2015 2:54 PM, Michał Winiarski wrote: >> >> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote: >>> >>> Gen8+ supports 48-bit virtual addresses, but some objects must always be >>> allocated inside the 32-bit address

[Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range

On Mon, Aug 10, 2015 at 2:21 AM, Michel Thierry wrote: > Hi, > > Thanks for the comments, > > On 8/7/2015 11:46 PM, Kristian Høgsberg wrote: >> >> On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry >> wrote: >>> >>> Gen8+ supports 48-bit virtual addresses, but some objects must always be >>>

[Intel-gfx] [PATCH mesa v3] i965/gen8+: bo in state base address must be in 32-bit address range

On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry wrote: > Gen8+ supports 48-bit virtual addresses, but some objects must always be > allocated inside the 32-bit address range. > > In specific, any resource used with flat/heapless (0x-0xf000) > General State Heap or Intruction State

[PATCH] Prevent zero sized wl_egl_window

On Fri, Feb 14, 2014 at 09:31:45AM +0200, Pekka Paalanen wrote: > On Thu, 13 Feb 2014 18:18:23 + > "Yeh, Sinclair" wrote: > > > > The below seems fine, but I wonder if we could make this one cause an > > > error to be returned later where we can, rather than silently ignoring. > > > I'm not

[PATCH] drm: Don't reference objects in the flink name idr

On Tue, Dec 3, 2013 at 7:26 AM, Daniel Vetter wrote: > On Mon, Dec 02, 2013 at 05:36:17PM -0800, Kristian H?gsberg wrote: >> There's no reason to keep a reference to objects in the name idr. Each >> handle to an object has a reference to the object and just before we >> destroy the last handle

[PATCH] drm: Don't reference objects in the flink name idr

There's no reason to keep a reference to objects in the name idr. Each handle to an object has a reference to the object and just before we destroy the last handle we take the object out of the name idr. Thus, if an object is in the name idr, there's at least one reference to the object. Or to

[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote: > On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote: > > Daniel Vetter writes: > > > >> Hm, where do we have the canonical source for all these fourcc codes? I'm > >> asking since we have our own copy in the kernel as

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

On Wed, Nov 6, 2013 at 10:09 AM, Keith Packard wrote: > Kristian H?gsberg writes: > >> It just the two older create context functions (which fall back to >> calling driCreateContextAtribs) and allocateBuffer and releaseBuffer. >> The two buffer functions are __DRIbuffer specific of course, but

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

On Wed, Nov 6, 2013 at 6:55 AM, Keith Packard wrote: > Kristian H?gsberg writes: > >> Having written the GBM and Wayland suport for this, it's pretty clear >> that we just want to use __DRIdri2Extension instead of duplicating >> these functions. Support for the __DRIimage based getBuffers is a

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

On Mon, Nov 04, 2013 at 06:23:27PM -0800, Keith Packard wrote: > These provide an interface between the driver and the loader to allocate > color buffers through the DRIimage extension interface rather than through a > loader-specific extension (as is used by DRI2, for instance). > > The driver

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

On Tue, Nov 5, 2013 at 4:59 PM, Keith Packard wrote: > Kristian H?gsberg writes: > > >> We can drop width and height now and just get it from either of the >> returned images. Format is a function of the __DRIconfig and doesn't >> change, so we could make that something you can query from the

[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension

On Mon, Nov 04, 2013 at 06:23:27PM -0800, Keith Packard wrote: > These provide an interface between the driver and the loader to allocate > color buffers through the DRIimage extension interface rather than through a > loader-specific extension (as is used by DRI2, for instance). > > The driver

[PATCH 6/8] dri/i915,dri/i965: Use driGLFormatToImageFormat and driImageFormatToGLFormat

On Mon, Nov 04, 2013 at 06:23:26PM -0800, Keith Packard wrote: > Remove private versions of these functions Reviewed-by: Kristian H?gsberg > Signed-off-by: Keith Packard > --- > src/mesa/drivers/dri/i915/intel_screen.c | 53 ++- >

[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*

On Mon, Nov 04, 2013 at 06:23:25PM -0800, Keith Packard wrote: > The __DRI_IMAGE_FORMAT codes are used by the image extension, drivers need to > be able to translate between them. Instead of duplicating this translation in > each driver, create a shared version. I'll take the bait... before the

[PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd

On Mon, Nov 04, 2013 at 06:23:23PM -0800, Keith Packard wrote: > Instead of assuming that the size will be height * pitch, have the caller pass > in the size explicitly. > > Signed-off-by: Keith Packard > --- > src/mesa/drivers/dri/i915/intel_regions.c | 4 ++-- >

[Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader

On Tue, Nov 05, 2013 at 12:04:32PM -0800, Eric Anholt wrote: > Keith Packard writes: > > > Keith Packard writes: > > > >> This sequence first adds a a couple of new DRIimage extensions to the > >> dri/common, dri/i915 and dri/i965 directories which define a > >> loader-independent API for

[PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver

I sent a reply to the sourceforge addresses in the original emails, but I didn't see it show up in the archives. Trying again with the freedesktop addresses. On Thu, Oct 31, 2013 at 04:13:15PM -0700, Keith Packard wrote: > This hooks DRI3 support into the GLX layer, the DRI common layer and the

[PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver

On Thu, Oct 31, 2013 at 04:13:15PM -0700, Keith Packard wrote: > This hooks DRI3 support into the GLX layer, the DRI common layer and the Intel > driver. > > Signed-off-by: Keith Packard > --- > configure.ac | 10 +- > include/GL/internal/dri_interface.h

[PATCH 4/6] dri/intel: Add intel_fd_for_region

On Thu, Oct 31, 2013 at 04:13:14PM -0700, Keith Packard wrote: > Returns a prime file descriptor for the specified region. > > Signed-off-by: Keith Packard > --- > src/mesa/drivers/dri/i915/intel_regions.c | 13 + > src/mesa/drivers/dri/i915/intel_regions.h | 4 >

[PATCH 2/6] dri/intel: Split out DRI2 buffer update code to separate function

On Thu, Oct 31, 2013 at 04:13:12PM -0700, Keith Packard wrote: > Make an easy place to splice in a DRI3 version of this function > > Signed-off-by: Keith Packard > --- > src/mesa/drivers/dri/i915/intel_context.c | 90 > +-- > src/mesa/drivers/dri/i965/brw_context.c

[PATCH 1/6] drivers/dri/common: A few dri2 functions are not actually DRI2 specific

On Thu, Oct 31, 2013 at 04:13:11PM -0700, Keith Packard wrote: > This just renames them so that they can be used with the DRI3 extension > without causing too much confusion. > > Signed-off-by: Keith Packard > --- > src/mesa/drivers/dri/common/dri_util.c | 50 >

[PATCH] intel: Set bo size from lseek if kernel supports it

an error and fall back to the user provided size. Signed-off-by: Kristian Høgsberg k...@bitplanet.net --- intel/intel_bufmgr_gem.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index f98f7a7..278f5c8 100644

[PATCH v2 5/6] drm/i915: Support render nodes

On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson wrote: > On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote: >> From: Kristian H?gsberg >> >> Enable support for drm render nodes for i915 by flagging the ioctls that >> are safe and just needed for rendering. >> >> Cc: Daniel Vetter >>

Re: [PATCH v2 5/6] drm/i915: Support render nodes

On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote: From: Kristian Høgsberg k...@bitplanet.net Enable support for drm render nodes for i915 by flagging the ioctls that are safe and just needed

[RFC 1/4] time: export getnstime_raw_and_real for DRM

On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak wrote: > Needed by the upcoming DRM raw monotonic timestamp support. I just had a quick look at driver/input/evdev.c, since evdev devices did a similar change recently to allow evdev timestamp from the monotonic clock. They're using a different time

[PATCH 2/3] drm: Add support for render nodes

This patch introduces a new kind of drm device node: the render node. A render node exposes a safe subset of the legacy drm device ioctls and can only be used for rendering. The legacy node supports modesetting, DRI1 and global buffer sharing, while the render node only supports rendering and

[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes

We got the minor number base right, but limit is too big and causes the minor numer ranges for the control and render nodes to overlap. Signed-off-by: Kristian H?gsberg --- drivers/gpu/drm/drm_stub.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 0/3] [RFC] DRM Render Nodes

Here's the patch to implement render nodes as discussed in the "DRM2" talk at XDC: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 The core problem is that DRM security is compromised in the face of VT switching and multiple DRM masters. Any local user can access all shared buffers

[PATCH 0/3] [RFC] DRM Render Nodes

Here's the patch to implement render nodes as discussed in the DRM2 talk at XDC: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 The core problem is that DRM security is compromised in the face of VT switching and multiple DRM masters. Any local user can access all shared buffers from

[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes

We got the minor number base right, but limit is too big and causes the minor numer ranges for the control and render nodes to overlap. Signed-off-by: Kristian Høgsberg k...@bitplanet.net --- drivers/gpu/drm/drm_stub.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] Sync the mode flags for the stereo 3D formats

On Wed, Sep 12, 2012 at 06:47:56PM +0100, Damien Lespiau wrote: From: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- include/drm/drm_mode.h | 35 +-- xf86drmMode.h | 35

Re: [PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

On Wed, Sep 12, 2012 at 06:48:19PM +0100, Damien Lespiau wrote: From: Damien Lespiau damien.lesp...@intel.com Now that modes have flags to describe which 3d formats the sink supports, it's time to test them. The new test cycles through the supported 3D formats and paint 3D stereoscopic

Re: [RFC 0/9] nuclear pageflip

On Fri, Sep 14, 2012 at 5:14 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 12 Sep 2012 21:58:31 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä

[PATCH] intel: Mark bo's exported to prime as not reusable

On Fri, Sep 14, 2012 at 5:03 PM, Chris Wilson wrote: > On Fri, 14 Sep 2012 17:01:18 -0400, Kristian H?gsberg > wrote: >> On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson >> wrote: >> > On Fri, 14 Sep 2012 16:37:53 -0400, Kristian H?gsberg > > bitplanet.net> wrote: >> >> It's the same situation

[RFC 0/9] nuclear pageflip

On Fri, Sep 14, 2012 at 5:14 PM, Jesse Barnes wrote: > On Wed, 12 Sep 2012 21:58:31 +0300 > Ville Syrj?l? wrote: > >> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: >> > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrj?l? >> > wrote: >> > > On Wed, Sep 12, 2012 at 10:48:16AM -0500,

[PATCH] intel: Mark bo's exported to prime as not reusable

On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson wrote: > On Fri, 14 Sep 2012 16:37:53 -0400, Kristian H?gsberg > wrote: >> It's the same situation as flink and we need take the same pre-cautions. >> --- >> intel/intel_bufmgr_gem.c |8 +++- >> 1 file changed, 7 insertions(+), 1

[PATCH] intel: Mark bo's exported to prime as not reusable

It's the same situation as flink and we need take the same pre-cautions. --- intel/intel_bufmgr_gem.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 3bcc849..92c0444 100644 --- a/intel/intel_bufmgr_gem.c +++

[PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

On Wed, Sep 12, 2012 at 06:48:19PM +0100, Damien Lespiau wrote: > From: Damien Lespiau > > Now that modes have flags to describe which 3d formats the sink > supports, it's time to test them. > > The new test cycles through the supported 3D formats and paint 3D > stereoscopic images taken from

[PATCH] Sync the mode flags for the stereo 3D formats

On Wed, Sep 12, 2012 at 06:47:56PM +0100, Damien Lespiau wrote: > From: Damien Lespiau > > Signed-off-by: Damien Lespiau > --- > include/drm/drm_mode.h | 35 +-- > xf86drmMode.h | 35 +-- > 2 files changed, 42

[PATCH] intel: Mark bo's exported to prime as not reusable

It's the same situation as flink and we need take the same pre-cautions. --- intel/intel_bufmgr_gem.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 3bcc849..92c0444 100644 --- a/intel/intel_bufmgr_gem.c +++

Re: [PATCH] intel: Mark bo's exported to prime as not reusable

On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg k...@bitplanet.net wrote: It's the same situation as flink and we need take the same pre-cautions. --- intel/intel_bufmgr_gem.c |8 +++- 1 file

Re: [PATCH] intel: Mark bo's exported to prime as not reusable

On Fri, Sep 14, 2012 at 5:03 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 14 Sep 2012 17:01:18 -0400, Kristian Høgsberg k...@bitplanet.net wrote: On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg

[PATCH] dri2proto: Fix documented opcodes

On Wed, May 2, 2012 at 3:03 PM, Chad Versace wrote: > Fix the documented opcodes in dri2proto.txt to be consistent with the > actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It > looks like the opcodes were incorrect due to copy-paste errors). Looks correct to me. Kristian

Re: [PATCH] dri2proto: Fix documented opcodes

correct to me. Kristian CC: Kristian Høgsberg k...@bitplanet.net Signed-off-by: Chad Versace chad.vers...@linux.intel.com ---  dri2proto.txt |   18 +-  1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/dri2proto.txt b/dri2proto.txt index df763c7..7bde067 100644

[RFC v2] Revive the work on render-nodes branch

On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie wrote: > On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic > wrote: >> The following set of patches is the reword of the series >> sent two weeks ago [2] that will revive the drm-render-nodes [1] >> branch. Details of the original series are described in

Re: [RFC v2] Revive the work on render-nodes branch

On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic ihad...@research.bell-labs.com wrote: The following set of patches is the reword of the series sent two weeks ago [2] that will revive the drm-render-nodes [1] branch. Details

[RFC PATCH] drm: Add plane event

On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter wrote: > On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrj?l? wrote: >> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote: >> > On 04/18/2012 02:25 PM, Rob Clark wrote: >> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim> > >

Re: [RFC PATCH] drm: Add plane event

On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrjälä wrote: On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote: On 04/18/2012 02:25 PM, Rob Clark wrote: On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung

[PATCH 1/7] drm: base prime support

On Wed, Feb 22, 2012 at 2:29 PM, Ben Widawsky wrote: > From: Dave Airlie > > --- > ?drivers/gpu/drm/Makefile ? ?| ? ?2 +- > ?drivers/gpu/drm/drm_drv.c ? | ? ?3 + > ?drivers/gpu/drm/drm_gem.c ? | ? ?3 +- > ?drivers/gpu/drm/drm_prime.c | ?126 > +++ >

Re: [PATCH 1/7] drm: base prime support

On Wed, Feb 22, 2012 at 2:29 PM, Ben Widawsky b...@bwidawsk.net wrote: From: Dave Airlie airl...@redhat.com ---  drivers/gpu/drm/Makefile    |    2 +-  drivers/gpu/drm/drm_drv.c   |    3 +  drivers/gpu/drm/drm_gem.c   |    3 +-  drivers/gpu/drm/drm_prime.c |  126

DRM KMS Modesetting

2011/11/15 David Herrmann : > 2011/11/15 Kristian H?gsberg : >> On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes >> wrote: >>> On Mon, 14 Nov 2011 21:47:09 +0100 >>> David Herrmann wrote: > I had to modify the resolution the test was searching for > to 1920x1200 instead of 1024x600 since

DRM KMS Modesetting

On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes wrote: > On Mon, 14 Nov 2011 21:47:09 +0100 > David Herrmann wrote: >> > I had to modify the resolution the test was searching for >> > to 1920x1200 instead of 1024x600 since I tested on a DP attached >> > monitor, and fix the connector id, but

Re: DRM KMS Modesetting

On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrm...@googlemail.com wrote: I had to modify the resolution the test was searching for to 1920x1200 instead of 1024x600 since I tested on a DP attached

Re: DRM KMS Modesetting

2011/11/15 David Herrmann dh.herrm...@googlemail.com: 2011/11/15 Kristian Høgsberg k...@bitplanet.net: On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 14 Nov 2011 21:47:09 +0100 David Herrmann dh.herrm...@googlemail.com wrote: I had to modify

[PATCH] drm/core: add ioctl to query device/driver capabilities

On Sun, Feb 20, 2011 at 8:17 PM, Ben Skeggs wrote: > From: Ben Skeggs > > We're coming to see a need to have a set of generic capability checks in > the core DRM, in addition to the driver-specific ioctls that already > exist. Looks good to me, just one comment: I don't think we need the driver

Re: [PATCH] drm/core: add ioctl to query device/driver capabilities

On Sun, Feb 20, 2011 at 8:17 PM, Ben Skeggs skeg...@gmail.com wrote: From: Ben Skeggs bske...@redhat.com We're coming to see a need to have a set of generic capability checks in the core DRM, in addition to the driver-specific ioctls that already exist. Looks good to me, just one comment: I

[PATCH 1/4] drm: fix headers to include linux/types.h

On Wed, Dec 1, 2010 at 11:54 AM, Julien Cristau wrote: > On Wed, Dec ?1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote: > >> For headers that get exported to userland and make use of u32 style >> type names, it is advised to include linux/types.h. >> >> This fixes 5 headers_check warnings. >>

Re: [PATCH 1/4] drm: fix headers to include linux/types.h

On Wed, Dec 1, 2010 at 11:54 AM, Julien Cristau jcris...@debian.org wrote: On Wed, Dec  1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote: For headers that get exported to userland and make use of u32 style type names, it is advised to include linux/types.h. This fixes 5 headers_check

[PATCH 1/9] drivers/gpu/drm/drm_stub.c: Use printf extension %pV

On Tue, Nov 9, 2010 at 7:35 PM, Joe Perches wrote: > Using %pV reduces the number of printk calls and > eliminates any possible message interleaving from > other printk calls. > > Signed-off-by: Joe Perches > --- > ?drivers/gpu/drm/drm_stub.c | ? 14 +++--- > ?1 files changed, 11

Re: [PATCH 1/9] drivers/gpu/drm/drm_stub.c: Use printf extension %pV

On Tue, Nov 9, 2010 at 7:35 PM, Joe Perches j...@perches.com wrote: Using %pV reduces the number of printk calls and eliminates any possible message interleaving from other printk calls. Signed-off-by: Joe Perches j...@perches.com ---  drivers/gpu/drm/drm_stub.c |   14 +++---  1

[PATCH 14/14] drm: kill agp indirection mess

On Mon, Aug 23, 2010 at 4:53 PM, Daniel Vetter wrote: > There's no point in jumping through two indirections. So kill one > and call the kernels agp functions directly. > > Signed-off-by: Daniel Vetter > --- > ?drivers/gpu/drm/drm_agpsupport.c | ? 40 +++-- >

  1   2   >