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 p
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
> p
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
> ---
> drivers/gpu/drm/msm/msm_gem.
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 pat
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
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. Kr
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
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 09:25:57
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:
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. Kristen
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.
Revi
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.
Revie
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 ha
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
> server.
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 into
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 KMS, so just filter out alpha formats for
c 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 concrete examples of actual display controllers
> >&
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, there seems to be a little bit
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 here are
> all the repos/branch
On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter wrote:
> Since this also involves the kernel let's add dri-devel ...
>
> On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico
> wrote:
>> Hi all,
>>
>> As many of you already know, I've been working with James Jones on the
>> Generic Device Allocator
On Tue, Oct 24, 2017 at 9:39 AM, Noralf Trønnes wrote:
>
> Den 23.10.2017 23.32, skrev Kristian Høgsberg:
>>
>> 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.
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 | 6 +
> drivers/gpu/drm/drm_frame
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
>>> rockchip_dp_drm_encoder_atomic_check() to de
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 this.
Kristian
> ---
> tests/modetest/modetest
On Tue, Apr 18, 2017 at 11:03 AM, Emil Velikov wrote:
> On 18 April 2017 at 18:38, Kristian Høgsberg wrote:
>> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss
>> wrote:
>>> From: Sean Paul
>>>
>>> From drm_crtc.h, for use with the plane "rotat
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
> Reviewed-by: Sumit Semwal
> ---
> Changes since v1:
> - Added r-b
>
> include/drm/drm.h | 8 +
On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca wrote:
> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca wrote:
>>>
>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>
>>>>
>>>> On Wed
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 PM, Alex Deucher
wrote:
>
>
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. Kris
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 differe
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 isn
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 ++
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 a
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
"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 l
"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; int
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
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 Høgsber
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:
>>
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 M
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 ran
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
>>> allocat
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 Heap
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 s
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 we
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 p
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 drm_fourcc.h
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 we
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
>
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 us
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 co
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 us
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 ++-
> src/mesa/drivers/dri/i965/intel_screen.
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 i9
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 ++--
> src/mesa/drivers/dri/i915/intel
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 managi
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 I
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
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
> src/mesa/driv
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
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
> +
et an error and fall back to the user provided size.
Signed-off-by: Kristian Høgsberg
---
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
--- a/
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 renderi
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
>>
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 API:
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 API:
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c |3 ++-
2 files changed, 20 inser
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 limi
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 a/drivers/gpu/drm/drm_s
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
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c |3 ++-
2 files changed, 20
without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/drm_drv.c | 13 +++--
drivers/gpu/drm/drm_fops.c |9 ++---
drivers/gpu/drm/drm_pci.c |9 +
include/drm/drmP.h
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 a/drivers/gpu/drm
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
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, Rob
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 pu
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 insertions(+
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 a
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
>> > wrote:
>&g
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, Rob
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 deletion(-
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
+++ b
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 c
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
+++ b
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 pu
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 insertions(+
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
>
Kristian
> CC: Kristian Høgsberg
> Signed-off-by: Chad Versace
> ---
> dri2proto.txt | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/dri2proto.txt b/dri2proto.txt
> index df763c7..7bde067 100644
> --- a/dri2proto.txt
>
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 [
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 [
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
>> > >
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> > > sam
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
> +++
> ?includ
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
> +++
> includ
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
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 f
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 other
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 other
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
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
1 - 100 of 124 matches
Mail list logo
