From: Dave Airlie
Daniel suggested this should move here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_crtc.c | 230
drivers/gpu/drm/i915/display/intel_sprite.c | 228 ---
2 files changed, 230 insertions(+), 228 deletions(-)
diff
From: Dave Airlie
This just refactors out the fdi code to a separate file.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 685 +-
.../drm/i915/display/intel_display_types.h| 9
From: Dave Airlie
This just cleans these up a bit.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_gen9_plane.c | 4 ++--
drivers/gpu/drm/i915/display/intel_sprite.c | 7 +++
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display
From: Dave Airlie
There may be more crtc code that can be pulled out, but this
is a good start.
RFC: maybe call the new file something different
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_crtc.c| 953
From: Dave Airlie
Daniel asked for this, but it's a bit messy and I'm not sure
how best to clean it up yet.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_crt.c | 1 +
drivers/gpu/drm/i915/display/intel_ddi.c | 151 +--
drivers/gpu/drm/i9
From: Dave Airlie
This pulls a large chunk of the pll calculation code out of
intel_display.c to a new file.
One function makse sense to be an inline, otherwise this
is pretty much a straight copy cover. also all the
remaining hooks for g45 and older end up the same now.
Signed-off-by: Dave
From: Dave Airlie
This file is a monster, let's start simple, the cursor plane code
seems pretty standalone, and splits out easily enough.
Reviewed-by: Ville Syrjälä
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/di
The first 4 patches are fixed up and reviewed, so it would be
good if we could land those at least.
I haven't had much time to rework the others, I've removed the legacy,
and added header files and renamed some functions where it wasn't too
intrusive.
I think the file names probably do need revis
From: Dave Airlie
There is no need for a comma use here.
Reviewed-by: Ville Syrjälä
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu
From: Dave Airlie
This will be used for some refactoring in other files, so move it
first.
Signed-off-by: Dave Airlie
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
drivers/gpu/drm/i915/display/intel_display_types.h | 6 ++
2 files changed
From: Dave Airlie
This function is going to be used in a later change, so clean it
up first before moving it.
Reviewed-by: Ville Syrjälä
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 78 +--
.../drm/i915/display/intel_display_types.h| 6
There are all in this branch
https://github.com/airlied/linux/commits/i915-display-refactor
I moved more code in the skl planes patch and move some pipe code in
there as well
Will repost those tomorrow most likely.
Dave.
On Thu, 10 Dec 2020 at 14:18, Dave Airlie wrote:
>
> The first
From: Dave Airlie
Daniel asked for this, but it's a bit messy and I'm not sure
how best to clean it up yet.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_ddi.c | 151 +--
drivers/gpu/drm/i915/display/intel_ddi.h | 14 +-
drivers/gp
From: Dave Airlie
This pulls a large chunk of the pll calculation code out of
intel_display.c to a new file.
One function makse sense to be an inline, otherwise this
is pretty much a straight copy cover. also all the
remaining hooks for g45 and older end up the same now.
Signed-off-by: Dave
From: Dave Airlie
There is no need for a comma use here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display
From: Dave Airlie
rework the plane init calls to do the gen test one level higher.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/display/intel_crtc.c | 16 +-
.../gpu/drm/i915/display/intel_gen9_plane.c | 1427
From: Dave Airlie
This just refactors out the fdi code to a separate file.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 684 +-
drivers/gpu/drm/i915/display/intel_display.h | 10
From: Dave Airlie
This file is a monster, let's start simple, the cursor plane code
seems pretty standalone, and splits out easily enough.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_cursor.c
From: Dave Airlie
There may be more crtc code that can be pulled out, but this
is a good start.
RFC: maybe call the new file something different
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_crtc.c| 951
From: Dave Airlie
This function is going to be used in a later change, so clean it
up first before moving it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 78 +--
.../drm/i915/display/intel_display_types.h| 6 ++
2 files changed, 42
From: Dave Airlie
This will be used for some refactoring in other files, so move it
first.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
drivers/gpu/drm/i915/display/intel_display_types.h | 6 ++
2 files changed, 6 insertions(+), 6 deletions
The first 3 are just moving some functions to inline and fixing
a wrong comma, the next 4 are cleaned up from yesterday.
hsw fdi is definitely a WIP.
Skl planes migration is along the lines of what danvet asked for.
Dave.
___
Intel-gfx mailing list
I
On Wed, 9 Dec 2020 at 20:48, Daniel Vetter wrote:
>
> On Wed, Dec 9, 2020 at 5:22 AM Dave Airlie wrote:
> >
> > From: Dave Airlie
> >
> > This just refactors out the fdi code to a separate file.
> >
> > Signed-off-by: Dave Airlie
>
> There
On Wed, 9 Dec 2020 at 21:48, Ville Syrjälä
wrote:
>
> On Wed, Dec 09, 2020 at 10:51:52AM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This file is a monster, let's start simple, the cursor plane code
> > seems pretty standalone, and splits out easily
From: Dave Airlie
This just refactors out the fdi code to a separate file.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 684 +-
drivers/gpu/drm/i915/display/intel_display.h | 10
From: Dave Airlie
This pulls a large chunk of the pll calculation code out of
intel_display.c to a new file.
One function makse sense to be an inline, otherwise this
is pretty much a straight copy cover. also all the
remaining hooks for g45 and older end up the same now.
Fixed one , instead of
From: Dave Airlie
There may be more crtc code that can be pulled out, but this
is a good start.
RFC: maybe call the new file something different
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_crtc.c| 951
From: Dave Airlie
This file is a monster, let's start simple, the cursor plane code
seems pretty standalone, and splits out easily enough.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_cursor.c
Recent events led me to notice a 20k loc file that seems excessive.
If a new driver came along and asked to merge this monster I'd say no,
so why has the in tree code gotten this bad. Standards are clearly
not being kept once code is merged, which doesn't bode well for the
future.
Anyways, as an
From: Dave Airlie
This file is a monster, let's start simple, the cursor plane code
seems pretty standalone, and splits out easily enough.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_cursor.c
From: Dave Airlie
This moves the functions into static const instead of having
funcs and data in the same struct.
It leaves the power callback alone, as it is used in a different
manner.
v2: leave power callback alone (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
.../drm
From: Dave Airlie
This moves the functions into static const instead of having
funcs and data in the same struct.
The only problem is the power callback gets overridden in the
eDP code so deal with that, might be worth seeing if that can be
done differently.
Signed-off-by: Dave Airlie
On Thu, 17 Sept 2020 at 03:19, Lyude Paul wrote:
>
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
On Fri, 13 Nov 2020 at 09:08, Rodrigo Vivi wrote:
>
> Hi Dave and Daniel,
>
> This is the same set as last week + couple new fixes targeting stable.
>
But I merged last weeks set and it's in rc3, maybe you can generate
the pull request relative to origin/master or drm/drm-fixes because
I'm not su
I've been trying to work out what path invalidate the vmas for the
following userspace behaviour, seen with iris/X.org but it's a bit of
a maze.
(address are fictional)
userspace allocates bo 1, assigns it a VMA. 0x1000
userspace allocates bo 2, assigns it a VMA 0x2000
Submits work with these ad
On Fri, 11 Sep 2020 at 22:27, Joonas Lahtinen
wrote:
>
> + Jani and Ville
>
> Quoting Matthew Auld (2020-09-11 11:56:56)
> > On 11/09/2020 06:42, Dave Airlie wrote:
> > > I've just been looking at the current DG1 uapi, and I can't see any
> > > f
I've just been looking at the current DG1 uapi, and I can't see any
flag to allow userspace to upfront say it was a contiguous vram BO.
I think you'd really want this for scanout, since otherwise you'll
have to migrate any non-contig to contig when it transitions to
scanout, and cause an extra set
For the two armada patches.
Reviewed-by: Dave Airlie
On Sat, 5 Sep 2020 at 00:40, Daniel Vetter wrote:
>
> Also remove the now no longer needed build bug on since that's already
> not needed anymore with drmm_add_final_kfree. Conversion to managed
> drm_device cleanup i
From: Dave Airlie
This looked like indirect ptr for not much reason in the create
object path, I just wonder why it couldn't be simpler like this,
The tests aren't cleaned up but this was more of is this a good idea
test patch.
---
drivers/gpu/drm/i915/gem/i915_gem_lme
On Thu, 27 Aug 2020 at 06:44, Harald Arnesen wrote:
>
> Linus Torvalds [26.08.2020 20:04]:
>
> > On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
> >> Somehow related to lightdm or xfce4? However, it is a regression, since
> >> kernel 5.8 works.
> > Yeah, apparently there's something else wr
On Wed, 19 Aug 2020 at 10:38, Linus Torvalds
wrote:
>
> Ping on this?
>
> The code disassembles to
>
> 24: 8b 85 d0 fd ff ffmov-0x230(%ebp),%eax
> 2a:* c7 03 01 00 40 10movl $0x1041,(%ebx) <-- trapping instruction
> 30: 89 43 04 mov%eax,0x4(%ebx)
> 33: 8b
On Thu, 30 Apr 2020 at 03:24, Chris Wilson wrote:
>
> We need to keep the default context state around to instantiate new
> contexts (aka golden rendercontext), and we also keep it pinned while
> the engine is active so that we can quickly reset a hanging context.
> However, the default contexts a
Hi Matthew,
do you have a rebase of these or a git tree with them, once I hit the
PPGTT support applying started to get messy.
Dave.
On Fri, 10 Jul 2020 at 21:58, Matthew Auld wrote:
>
> This is Lucas' DG1 enabling series[1], plus some of the DG1 specific enablers
> for supporting LMEM on top,
On Fri, 31 Jul 2020 at 02:26, Joonas Lahtinen
wrote:
>
> Hi Dave & Daniel,
>
> (Covering for Jani here for drm-intel-next-fixes)
>
> 5 new commits over drm-intel-next here.
>
> Fix for KASAN detected race condition and linux-next scheduler
> WARNs. Patch to avoid IRQ spinlock and Cc: stable PMU re
On Fri, 7 Aug 2020 at 19:46, Joonas Lahtinen
wrote:
>
> Quoting Dave Airlie (2020-07-13 08:09:30)
> > On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote:
> > >
> > > We need to add support for pwrite'ing an LMEM object.
> >
> > why? DG1 is a disc
On Fri, 7 Aug 2020 at 17:12, Chris Wilson wrote:
>
> Quoting Dave Airlie (2020-08-04 22:45:25)
> > On Mon, 3 Aug 2020 at 05:36, Chris Wilson wrote:
> > >
> > > Quoting Dave Airlie (2020-08-02 18:56:44)
> > > > On Mon, 3 Aug 2020 at 02:44, Chris Wilson
On Mon, 3 Aug 2020 at 05:36, Chris Wilson wrote:
>
> Quoting Dave Airlie (2020-08-02 18:56:44)
> > On Mon, 3 Aug 2020 at 02:44, Chris Wilson wrote:
> > >
> > > Lots of small incremental improvements to reduce execution latency
> > > which basically offs
On Wed, 29 Jul 2020 at 01:21, Chris Wilson wrote:
>
> The flags passed to the wait_entry.func are passed onwards to
> try_to_wake_up(), which has a very particular interpretation for its
> wake_flags. In particular, beyond the published WF_SYNC, it has a few
> internal flags as well. Since we pass
On Mon, 3 Aug 2020 at 02:44, Chris Wilson wrote:
>
> Lots of small incremental improvements to reduce execution latency
> which basically offsets the small regressions incurred when compared to
> 5.7. And then there are some major fixes found while staring agape at
> lockstat.
What introduced the
On Sun, 2 Aug 2020 at 04:29, Chris Wilson wrote:
>
> Our timeline lock is our defence against a concurrent execbuf
> interrupting our request construction. we need hold it throughout or,
> for example, a second thread may interject a relocation request in
> between our own relocation request and e
I've got a 66 patch series here, does it have a cover letter I missed?
Does it have a what is the goal of this series? Does it tell the
reviewer where things are headed and why this is a good idea from a
high level.
The problem with these series is they are impossible to review from a
WTF does it
On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel)
wrote:
>
>
> On 7/21/20 9:45 AM, Christian König wrote:
> > Am 21.07.20 um 09:41 schrieb Daniel Vetter:
> >> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
> >> wrote:
> >>> Hi,
> >>>
> >>> On 7/9/20 2:33 PM, Daniel Vetter
>
> >> That's also why I'm not positive on the "no hw preemption, only
> >> scheduler" case: You still have a dma_fence for the batch itself,
> >> which means still no userspace controlled synchronization or other
> >> form of indefinite batches allowed. So not getting us any closer to
> >> enablin
On Thu, 16 Jul 2020 at 20:11, Matthew Auld wrote:
>
> On 16/07/2020 01:43, Dave Airlie wrote:
> > On Wed, 15 Jul 2020 at 00:35, Matthew Auld wrote:
> >>
> >> On 13/07/2020 06:09, Dave Airlie wrote:
> >>> On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote
On Wed, 15 Jul 2020 at 00:35, Matthew Auld wrote:
>
> On 13/07/2020 06:09, Dave Airlie wrote:
> > On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote:
> >>
> >> We need to add support for pwrite'ing an LMEM object.
> >
> > why? DG1 is a discrete GPU, t
On Wed, 15 Jul 2020 at 02:57, Tang, CQ wrote:
>
>
>
> > -Original Message-
> > From: Auld, Matthew
> > Sent: Tuesday, July 14, 2020 8:02 AM
> > To: Dave Airlie
> > Cc: Intel Graphics Development ; Tang, CQ
> > ; Joonas Lahtinen ;
> >
t two can be merged without causing any pain. Feel
> free to add my ab on them.
>
> And the third one can go in immediately as well.
Acked-by: Dave Airlie for the first 2 +
indefinite explains.
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, 10 Jul 2020 at 22:00, Matthew Auld wrote:
>
> We need to add support for pwrite'ing an LMEM object.
why? DG1 is a discrete GPU, these interfaces we already gross and
overly hacky for integrated, I'd prefer not to drag them across into
discrete land.
same goes for pread.
You have no lega
On Fri, 10 Jul 2020 at 22:01, Matthew Auld wrote:
>
> From: CQ Tang
>
> Add "REGION_STOLEN" device info to dg1, create stolen memory
> region from upper portion of local device memory, starting
> from DSMBASE.
>
> The memory region is marked with "is_devmem=true".
So is stolen fake on LMEM devic
On Tue, 7 Jul 2020 at 18:36, Matthew Auld wrote:
>
> On 01/07/2020 00:27, Dave Airlie wrote:
> > On Sat, 27 Jun 2020 at 03:17, Daniele Ceraolo Spurio
> > wrote:
> >>
> >>
> >>
> >> On 6/26/20 12:14 AM, Lucas De Marchi wrote:
> >>&g
On Sat, 27 Jun 2020 at 03:17, Daniele Ceraolo Spurio
wrote:
>
>
>
> On 6/26/20 12:14 AM, Lucas De Marchi wrote:
> > Cc Matt and Daniele
> >
> > On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie wrote:
> >>
> >> I can't figure this out easily so
I can't figure this out easily so I'd thought I'd just ask, but does
DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
mappable VRAM vs non-mappable in patches, is it planned to just thrash
the aperture if userspace ever ties to map too much of it.
Are pagetables stored in the vi
On Fri, 26 Jun 2020 at 05:27, Jani Nikula wrote:
>
> On Fri, 26 Jun 2020, Dave Airlie wrote:
> > WTUF?
> >
> > How did this ever land in my tree, there is no ACK on this from anyone
> > in core dma-buf,
> >
> > Intel team, clean your house up here, I&#x
On Fri, 8 May 2020 at 15:58, Joonas Lahtinen
wrote:
>
> Quoting Dave Airlie (2020-05-07 21:27:27)
> > On Fri, 8 May 2020 at 01:44, Chris Wilson wrote:
> > >
> > > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > > The Vulkan driver in Mesa fo
WTUF?
How did this ever land in my tree, there is no ACK on this from anyone
in core dma-buf,
Intel team, clean your house up here, I'm going to have to ask you to
stop Chris merging stuff without oversight, if this sort of thing
happens, this is totally unacceptable.
Dave.
Signed-off-by: Chr
On Wed, 24 Jun 2020 at 07:19, Chris Wilson wrote:
>
> Quoting Dave Airlie (2020-06-23 22:01:24)
> > On Tue, 23 Jun 2020 at 20:03, Chris Wilson wrote:
> > >
> > > Quoting Thomas Hellström (Intel) (2020-06-23 10:33:20)
> > > > Hi, Chris!
> > >
On Wed, 24 Jun 2020 at 11:36, Stephen Rothwell wrote:
>
> Hi all,
>
> On Wed, 17 Jun 2020 10:59:29 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.
On Tue, 23 Jun 2020 at 20:03, Chris Wilson wrote:
>
> Quoting Thomas Hellström (Intel) (2020-06-23 10:33:20)
> > Hi, Chris!
> >
> > On 6/22/20 11:59 AM, Chris Wilson wrote:
> > > In order to actually handle eviction and what not, we need to process
> > > all the objects together under a common loc
On Mon, 22 Jun 2020 at 19:55, Jani Nikula wrote:
>
> On Mon, 22 Jun 2020, Daniel Vetter wrote:
> > On Wed, Jun 17, 2020 at 05:42:15PM -0700, Lucas De Marchi wrote:
> >> From: Abdiel Janulgue
> >>
> >> Bspec: 33617, 33617
> >>
> >> Cc: José Roberto de Souza
> >> Cc: Daniele Ceraolo Spurio
> >>
On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-06-04 09:12:09)
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> > this explicit annotation ca
On Thu, 14 May 2020 at 03:10, Joonas Lahtinen
wrote:
>
> Ping for merging this? If there are no issues, I'd prefer to pull in
> next gvt-next and tag the final pull sooner than later.
Can you check that I'm correct and this isn;'t in patchwork. I've
checked both the dri-devel and intel-gfx patchw
On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece
On Fri, 8 May 2020 at 01:44, Chris Wilson wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do. On
Acked-by: Dave Airlie
On Tue, 5 Nov 2019 at 21:06, Joonas Lahtinen
wrote:
>
> Dave, ping for Acked-by here so we can merge? You already gave an
> early ack in IRC while travelling.
>
> Regards, Joonas
>
> Quoting Joonas Lahtinen (2019-08-30 13:50:53)
> > To
On Sat, 29 Feb 2020 at 05:34, Eric Anholt wrote:
>
> On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote:
> >
> > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > >
> > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> > > > b)
On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
>
> On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> > b) we probably need to take a large step back here.
> >
> > Look at this from a sponsor POV, why would I give X.org/fd.o
> > sponsorship money that they are
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 with our
> communities, and is used extensively. This especially inclu
On Tue, 25 Feb 2020 at 07:13, Chris Wilson wrote:
>
> Quoting Linus Torvalds (2020-02-24 20:18:03)
> > Let's add in some of the i915 people and list.
>
> Haswell eating kittens. The offending patch will be rolled back shortly.
> -Chris
https://patchwork.freedesktop.org/patch/354775/
is the patch
looping in intel-gfx + Jani.
On Tue, 18 Feb 2020 at 05:20, sinisa wrote:
>
>
> On 2020-02-16 22:32, Linus Torvalds wrote:
> > ...
> > Chris Wilson (19):
> > drm/i915/pmu: Correct the rc6 offset upon enabling
> > drm/i915/gem: Take local vma references for the parser
> > drm
The landing of the i915 CVE fixes into Linus tree has created a bit of
a mess in linux-next and downstream in drm-next trees.
I talked to Daniel and he had talked to Joonas a bit, and I decided to
go with what Daniel describes as the YOLO merge, where I just solve it
and pray, and everyone else ve
LGTM, thanks,
Reviewed-by: Dave Airlie
On Sat, 9 Nov 2019 at 10:52, Manasi Navare wrote:
>
> In case of tiled displays, if we hotplug just one connector,
> fbcon currently just selects the preferred mode and if it is
> tiled mode then that becomes a problem if rest of the til
er on hotplug when we probe the client modeset,
> > > > we we dont find all the connectors for all tiles, then on a connector
> > > > with one tile, just fallback to the first available non tiled mode
> > > > to display over a single connector.
>
driver on hotplug when we probe the client modeset,
> we we dont find all the connectors for all tiles, then on a connector
> with one tile, just fallback to the first available non tiled mode
> to display over a single connector.
>
> Suggested-by: Ville Syrjälä
> Suggested-by: Da
On Tue, 22 Oct 2019 at 01:49, Sean Paul wrote:
>
> On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen wrote:
> >
> > Hi,
> >
> > On 18/10/2019 23:11, Sean Paul wrote:
> > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen
> > > wrote:
> > >>
> > >> Hi Sean,
> > >>
> > >> On 17/10/2019 22:26, Sean Pau
On Thu, 12 Sep 2019 at 23:33, Joonas Lahtinen
wrote:
>
> Quoting Dave Airlie (2019-08-13 22:20:52)
> > On Sat, 10 Aug 2019 at 08:26, Matthew Auld wrote:
> > >
> > > In preparation for upcoming devices with device local memory, introduce
> > > the
> >
On Fri, 23 Aug 2019 at 05:29, Rodrigo Vivi wrote:
>
> Hi Dave and Daniel,
>
> Here goes the final pull request targeting 5.4.
For some reason patchwork hasn't picked this up. or if it has I can't
see it. Not sure whether it was the earlier patch code in it or
something else malformed.
Dave.
On Sat, 10 Aug 2019 at 08:26, Matthew Auld wrote:
>
> In preparation for upcoming devices with device local memory, introduce the
> concept of different memory regions, and a simple buddy allocator to manage
> them in i915.
>
> One of the concerns raised from v1 was around not using enough of TTM,
On Sat, 3 Aug 2019 at 20:47, Maxime Ripard wrote:
>
> Hi Daniel, Dave,
>
> Here is the first (and pretty late) drm-misc-next PR.
>
> It's pretty big due to the lateness, but there's nothing really major
> showing up. It's pretty much the usual bunch of reworks, fixes, and
> new helpers being intro
Daniel, drm-misc-next-fixes?
Dave.
On Fri, 26 Apr 2019 at 12:25, wrote:
>
> Hi Dave,
>
> > -Original Message-
> > From: Dave Airlie [mailto:airl...@gmail.com]
> > Sent: Friday, April 26, 2019 11:19 AM
> > To: Yamada, Masahiro/山田 真弘
> > Cc: David
ux/kernel/git/masahiroy/linux-kbuild.git
> > build-test
>
>
> Is somebody taking care of this?
>
Are you expecting this to be merged in the drm tree? if so please
indicate that when posting.
I'd assumed this would go via kbuild tree.
If the later,
Acked-by: Dave Airlie
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
04-24
10:52:52 +1000)
drm regression fixes (i915 and virtio-gpu)
----
Dave Airlie (2):
Revert "drm/i915/fbdev: Actually configure untiled displays"
Revert "drm/virtio:
This patch broke userspace. I'm reverting it.
I know userspace was broken, but since it's a userspace lots of people
are using we shouldn't break it.
We either need to add this as a config option that we can let people
pick the breakage, or detect broken userspace somehow and magic around
it.
Bu
On Mon, 25 Mar 2019 at 22:49, Joonas Lahtinen
wrote:
>
> Hi Dave & Daniel,
>
> First batch of features for 5.2, tagged last week.
I asked on irc, but got no answer I saw,
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/i915/i915_gem_context.c:698:12:
warning: ‘context_barrier_task’ defined but
> > At the end of the day, I don't really care that much. I get it, we
> > all have large projects with scarce resources. I just think a few
> > years down the road we'll all regret it as a community.
>
> AMD and others have also spent years tuning TTM for both UMA and VRAM,
> but especially VRAM
On Tue, 19 Feb 2019 at 23:32, Joonas Lahtinen
wrote:
>
> + dri-devel mailing list, especially for the buddy allocator part
>
> Quoting Dave Airlie (2019-02-15 02:47:07)
> > On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote:
> > >
> > > In preparation for upcom
On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote:
>
> In preparation for upcoming devices with device local memory, introduce the
> concept of different memory regions, and a simple buddy allocator to manage
> them.
This is missing the information on why it's not TTM.
Nothing against extending i
On Sat, 2 Feb 2019 at 18:29, Rodrigo Vivi wrote:
>
> Hi Dave and Daniel,
>
> Here goes another pull request for 5.1.
dim complained:
Chris committed this without an S-O-B, now because it's all Intel this
probably doesn't matter, so I'll pull it, put please try and let it
not happen again.
Dave.
I merged the i915 tree into drm-next this morning, but got a major
conflict on the drm-tip rebuild in intel_workarounds.c.
I'm not sure if I did wrong thing, but there were a couple of places
where the code seemed inconsistent and I couldn't track down what was
actually wanted. I'd appreciate some
On Fri, 2 Nov 2018 at 20:21, Jani Nikula wrote:
>
>
> Hi Dave -
>
> I just tagged this minutes ago, but I'm sending this now because I'll be
> out for about a week. I don't expect you to pull this until some time
> after -rc1 anyway. I'm asking Joonas and Rodrigo to tell you if this
> one's a go o
main one,
I've no idea what a baseline IGT test run looks like on non-intel hw,
how useful is it?
Acked-by: Dave Airlie
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
301 - 400 of 810 matches
Mail list logo
