On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:
> Hi Jason,
>
> Thank you for your patch.
>
> Missatge de jason-jh.lin del dia dj., 22
> de jul. 2021 a les 11:26:
> >
> > There are 2 display hardware path in mt8195, namely vdosys0 and
> > vdosys1, so add their definition in mtk-m
Hi Iskren,
thanks for your patch!
On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev wrote:
> +required:
> + - compatible
> + - reset-gpios
> + - iovdd-supply
> + - vddr-supply
> + - port
I do not think port should be required because the DSI
framework allows panels to be put as children right
Hi Iskren,
thanks for your patch!
On Mon, Feb 1, 2021 at 5:56 PM Iskren Chernev wrote:
> The Samsung Galaxy S5 uses the samsung s6e3fa2 AMOLED cmd LCD panel.
>
> This driver was generated with [1], with the addition of
> mipi_dsi_dcs_set_display_on at the end of the on method.
>
> [1] https://g
On Sun, Jul 25, 2021 at 5:01 PM Sam Ravnborg wrote:
> This driver supports two different panels:
>
> S6E3FA2
> EA8064G
>
> They differ on a lot of the tables and requires different init.
> In other words there is only a little boiler plate code that is in
> common.
>
> I think it
We already have logging for ADDFB2. Add some logging for RMFB as
well.
This can be handy when trying to find out why a CRTC gets magically
disabled.
v2: make log message more explicit, add log messages to
drm_framebuffer_remove (Daniel)
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
drivers/g
Since there's no struct to attach the docs to, document the IOCTL
definition.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Leandro Ribeiro
---
include/uapi/drm/drm.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/
On Sun, Jul 25, 2021 at 4:04 PM Alexey Minnekhanov
wrote:
> The Samsung S6E3FA2 AMOLED cmd LCD panel is used on Samsung Galaxy
> S5 (klte) phone.
>
> Signed-off-by: Alexey Minnekhanov
Grr gmail put this in my spam folder, sorry for confused mails.
With Sam's comments addressed:
Reviewed-by: Li
On Fri, 23 Jul 2021 at 18:49, Jason Ekstrand wrote:
>
> Are there IGTs for this anywhere?
https://patchwork.freedesktop.org/series/92580/
>
> On Fri, Jul 23, 2021 at 12:47 PM Jason Ekstrand wrote:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
> >
> > On Fri, Jul 23, 20
Hi Alexey,
I had some gmail problems and replied to the very old driver
by Iskren, sorry for the mess.
I overall like this driver a lot. Some of Sam's comments could
be addressed especially for backlight.
I think the driver should indeed handle both the physical
displays like you do here.
On Su
On Fri, 23 Jul 2021 at 18:48, Jason Ekstrand wrote:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
Cool, is that ready to go? i.e can we start merging the kernel + IGT side.
>
> On Fri, Jul 23, 2021 at 6:35 AM Matthew Auld wrote:
> >
> > From: Chris Wilson
> >
> > Jason Ek
On Fri, 23 Jul 2021 at 18:22, Jason Ekstrand wrote:
>
> __i915_ttm_get_pages does two things. First, it calls ttm_bo_validate()
> to check the given placement and migrate the BO if needed. Then, it
> updates the GEM object to match, in case the object was migrated. If
> no migration occured, ho
On Fri, 23 Jul 2021 at 18:22, Jason Ekstrand wrote:
>
> Without TTM, we have no such hook so we exit early but this is fine
> because we use TTM on all LMEM platforms and, on integrated platforms,
> there is no real migration. If we do have the hook, it's better to just
> let TTM handle the migra
On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote:
>
> This patch series fixes an issue with discrete graphics on Intel where we
> allowed dma-buf import while leaving the object in local memory. This
> breaks down pretty badly if the import happened on a different physical
> device.
>
> v7:
>
Op 23-07-2021 om 13:34 schreef Matthew Auld:
> From: Chris Wilson
>
> Jason Ekstrand requested a more efficient method than userptr+set-domain
> to determine if the userptr object was backed by a complete set of pages
> upon creation. To be more efficient than simply populating the userptr
> using
On Wednesday, July 21st, 2021 at 13:39, Daniel Vetter wrote:
> I think it would be really good to link to
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction
>
> for all the property related ioctl. That entire class vs instance
> confusion is pretty common I
On 23/07/2021 20:29, Daniel Vetter wrote:
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_ce to just a
slab_ce.
Cc: Jas
On 23/07/2021 17:43, Daniel Stone wrote:
Hi Tvrtko,
Thanks for typing this up!
On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin
wrote:
+Mandatory fully standardised keys
+-
+
+- drm-driver:
+
+String shall contain a fixed string uniquely identified the driver han
On 23/07/2021 18:45, Nieto, David M wrote:
[AMD Official Use Only]
I just want to make a comment that with this approach (the ns)
calculating the percentage will take at least two reads of the fdinfo
per pid over some time. Some engines may be able to provide a single
shot percentage usage
Hi Artjom,
Le lun., juil. 26 2021 at 01:15:27 +0300, Artjom Vejsel
a écrit :
The Gopher 2b LCD panel is used in Gopher 2b handhelds.
It's simple panel with NewVision NV3047 driver, but SPI lines are not
connected.
It has no specific name, since it's unique to that handhelds.
lot name at AliE
On Mon, Jul 26, 2021 at 4:18 AM Sam Ravnborg wrote:
>
> Hi Zheyu,
>
> On Sun, Jul 25, 2021 at 02:10:51AM +, Zheyu Ma wrote:
> > Zheyu Ma (3):
> > video: fbdev: kyro: add a check against divide error
> > video: fbdev: riva: add a check against divide error
> > video: fbdev: asiliantfb: ad
Zheyu Ma (3):
video: fbdev: asiliantfb: Error out if 'pixclock' equals zero
video: fbdev: kyro: Error out if 'pixclock' equals zero
video: fbdev: riva: Error out if 'pixclock' equals zero
drivers/video/fbdev/asiliantfb.c | 3 +++
drivers/video/fbdev/kyro/fbdev.c | 3 +++
drivers/video/fbdev
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of 'pixclock',
it may cause divide error.
Fix this by checking whether 'pixclock' is zero first.
The following log reveals it:
[ 43.861711] divide error: [#1] PREEMPT
The userspace program could pass any values to the driver through
ioctl() interface. if the driver doesn't check the value of 'pixclock',
it may cause divide error because the value of 'lineclock' and
'frameclock' will be zero.
Fix this by checking whether 'pixclock' is zero in kyrofb_check_var().
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of 'pixclock',
it may cause divide error.
Fix this by checking whether 'pixclock' is zero first.
The following log reveals it:
[ 33.396850] divide error: [#1] PREEMPT
On Fri, Jul 23, 2021 at 05:11:12PM -0700, Lucas De Marchi wrote:
> Remove registers that are not used anymore due to CNL removal and rename
> those that are.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 192 ++-
On Fri, Jul 23, 2021 at 05:11:11PM -0700, Lucas De Marchi wrote:
> Replace all remaining handling of GRAPHICS_VER {==,>=} 10 with
> {==,>=} 11. With the removal of CNL, there is no platform with graphics
> version equals 10.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
>
Hi Jason,
Missatge de Jason-JH Lin del dia dl., 26
de jul. 2021 a les 9:02:
>
> On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:
> > Hi Jason,
> >
> > Thank you for your patch.
> >
> > Missatge de jason-jh.lin del dia dj., 22
> > de jul. 2021 a les 11:26:
> > >
> > > There are 2 di
On Fri, Jul 23, 2021 at 05:11:13PM -0700, Lucas De Marchi wrote:
> Cleanup remaining cases that we find CNL in the codebase.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.
On Fri, Jul 23, 2021 at 05:11:01PM -0700, Lucas De Marchi wrote:
> With the removal of CNL, let's consider GLK as the first platform using
> those constants since GLK has DISPLAY_VER == 10.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/skl_s
On Fri, Jul 23, 2021 at 05:11:14PM -0700, Lucas De Marchi wrote:
> The numbers of scalers and sprites depend on the display version, so use
> it instead of GRAPHICS_VER. We were mixing both, which let me confused
> while removing CNL and GRAPHICS_VER == 10.
>
> Signed-off-by: Lucas De Marchi
> --
On Fri, Jul 23, 2021 at 05:11:05PM -0700, Lucas De Marchi wrote:
> Remove references for CNL from pch detection.
for a moment I almost thought you were removing the CNP support...
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_pch.c | 5 +
On Sat, Jul 24, 2021 at 10:02:15PM -0700, Lucas De Marchi wrote:
> On Sat, Jul 24, 2021 at 06:41:21PM +0100, Christoph Hellwig wrote:
> > Still tests fine:
> >
> > Tested-by: Christoph Hellwig
>
> I just pushed this to drm-intel-next as part of another series and
> added your Tested-by.
>
> Ro
On Fri, Jul 23, 2021 at 05:11:10PM -0700, Lucas De Marchi wrote:
> With all the users removed, finish removing the CNL platform definitions.
> We will leave the PCI IDs around as those are exposed to userspace.
> Even if mesa doesn't support CNL anymore, let's avoid build breakages
> due to changin
On Fri, Jul 23, 2021 at 05:11:04PM -0700, Lucas De Marchi wrote:
> Only one reference to CNL that is not needed, but code is the same for
> GEN9_BC, so leave the code around and just remove the special
> case for CNL.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> driver
On Fri, Jul 23, 2021 at 05:10:58PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in skl_universal_plane.c.
>
> Remove code and rename functions/macros accordingly to use ICL prefix.
>
> Signed-off-by: Lucas De Marchi
On Fri, Jul 23, 2021 at 05:11:08PM -0700, Lucas De Marchi wrote:
> With the removal of CNL, let's consider ICL as the first platform using
> those constants.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 24 +++
>
On Thu, 8 Jul 2021 14:10:45 +0200
Christian König wrote:
> >> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> >> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> >> @@ -254,6 +254,9 @@ static int panfrost_acquire_object_fences(struct
> >> panfrost_job *job)
> >>return
On Fri, Jul 23, 2021 at 05:10:59PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_display_power.c.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> .../drm/i915/display/intel_display_p
Hi
> Gesendet: Montag, 26. Juli 2021 um 02:27 Uhr
> Von: "Chun-Kuang Hu"
> As I've discussed in [1], SOUT has many bits and need to be cleared
> before set new value. Of course, write only could do the clear, but
> for MOUT, it clear the bits that should not be cleared. If you want to
> use the t
On Fri, Jul 23, 2021 at 05:10:56PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_ddi.c.
>
> A lot of special code for CNL can be removed. There were some
> __cnl.*() functions that were created to share the i
On Fri, Jul 23, 2021 at 05:11:09PM -0700, Lucas De Marchi wrote:
> With the removal of CNL, let's consider ICL as the first platform using
> that index.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
(
I got myself thinking that some patches like this could be squashed into oth
On Fri, Jul 23, 2021 at 05:10:55PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_dp.c.
>
> Remove code and rename functions/macros accordingly to use ICL prefix.
>
> Signed-off-by: Lucas De Marchi
Reviewed
On Fri, Jul 23, 2021 at 05:11:00PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-
> ...
On Fri, Jul 23, 2021 at 05:11:06PM -0700, Lucas De Marchi wrote:
> Consider the new WOPCM size as starting in ICL rather than CNL since the
> latter is being removed from the driver.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_wopcm.c | 10 +
On Fri, Jul 23, 2021 at 05:11:02PM -0700, Lucas De Marchi wrote:
> Remove special handling of PORT_F in i915_irq.c and only do it for
> DISPLAY_VER == 11.
oh! ignore my previous thought about removing the port F...
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
> drive
On Fri, Jul 23, 2021 at 05:10:52PM -0700, Lucas De Marchi wrote:
> The only real platform with DISPLAY_VER == 10 is GLK. We don't need to
> handle CNL explicitly in intel_ddi.c.
>
> Remove code and rename functions/macros accordingly to use ICL prefix.
> There's one leftover reference to cnl that
On Fri, Jul 23, 2021 at 05:10:57PM -0700, Lucas De Marchi wrote:
> Only one reference to CNL that is not needed, but code is the same for
> DISPLAY_VER >= 11, so leave the code around and just remove the special
> case for CNL.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
On Fri, Jul 23, 2021 at 05:10:54PM -0700, Lucas De Marchi wrote:
> Remove DMC firmware for CNL.
>
> Signed-off-by: Lucas De Marchi
Cc: Anusha Srivatsa
We need to remove the binary from linux-firmware.git as well
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 9 -
> 1 file changed
On Fri, Jul 23, 2021 at 05:10:53PM -0700, Lucas De Marchi wrote:
> Only one reference to CNL that is not needed, but code is the same for
> DISPLAY_VER >= 11, so leave the code around and just remove the special
> case for CNL.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> ---
On Fri, Jul 23, 2021 at 05:11:03PM -0700, Lucas De Marchi wrote:
> Remove support for CNL as it's highly untested, probably broken, and
> there is no real platform that requires this code. This is part of CNL
> removal from i915.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
> -
Hello, Paul!
Thanks for your investigation.
But while this two panels are compatible with the timing set in the
driver, their timing ranges are different ([1], [2]) and therefore
should have different compatible strings.
[1]: https://wendangmao.net/doc/753b5635102de2bd960588e2-51.html
[2]
On Thu, Jul 01, 2021 at 06:07:09PM +0100, Normunds Rieksts wrote:
> Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image
> compression protocol and format.
> It is designed to provide guaranteed bandwidth and memory footprint
> reductions in graphics and media use-cases.
>
> This pa
On Mon, Jul 26, 2021 at 11:32:37AM +, tcs_kernel(腾讯云内核开发者) wrote:
> yres and vyres can be controlled by user mode paramaters, and cause p->vrows
> to become a negative value. While this value be passed to real_y function,
> the ypos will be out of screen range.
> This is an out-of-bounds writ
Hi Nicolas,
On Mon, Jul 26, 2021 at 08:38:18AM +0800, Nicolas Boichat wrote:
> On Sun, Jul 25, 2021 at 9:31 PM Sam Ravnborg wrote:
> >
> > On Tue, Jun 29, 2021 at 07:47:21AM +0800, Nicolas Boichat wrote:
> > > Many of the DSI flags have names opposite to their actual effects,
> > > e.g. MIPI_DSI_
Hi,
On Mon, Jul 26, 2021 at 11:32:37AM +, tcs_kernel(腾讯云内核开发者) wrote:
> yres and vyres can be controlled by user mode paramaters, and cause p->vrows
> to become a negative value. While this value be passed to real_y function,
> the ypos will be out of screen range.
> This is an out-of-bounds
On Mon, Jul 26, 2021 at 06:20:03AM -0400, Rodrigo Vivi wrote:
On Sat, Jul 24, 2021 at 10:02:15PM -0700, Lucas De Marchi wrote:
On Sat, Jul 24, 2021 at 06:41:21PM +0100, Christoph Hellwig wrote:
> Still tests fine:
>
> Tested-by: Christoph Hellwig
I just pushed this to drm-intel-next as part o
From: Rob Clark
A couple tweaks to reduce fence signal latency.
Rob Clark (2):
drm/msm: Let fences read directly from memptrs
drm/msm: Signal fences sooner
drivers/gpu/drm/msm/msm_fence.c | 11 +--
drivers/gpu/drm/msm/msm_fence.h | 41 +++---
drivers/gpu/d
From: Rob Clark
Let dma_fence::signaled, etc, read directly from the address that the hw
is writing with updated completed fence seqno, so we can potentially
notice that the fence is signaled sooner.
Plus add some docs.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 11 ++
From: Rob Clark
Nothing we do to in update_fences() can't be done in an atomic context,
so move this into the GPU's irq context to reduce latency (and call
dma_fence_signal() so we aren't relying on dma_fence_is_signaled() which
would defeat the purpose).
Signed-off-by: Rob Clark
---
drivers/g
From: Rob Clark
This is the outcome of trying to fix some bad gpu freq behavior seen in
some use-cases, in particular mobile games that throttle themselves to
30fps. With the existing tuning, we'd end up spending most of the time
that we should be running fast at a low freq, and most of the idle
From: Rob Clark
Before we start adding more cleverness, split it into it's own file.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +-
drivers/gpu/drm/msm/msm_gpu.c | 116 +-
drivers/gpu/drm/m
From: Rob Clark
In the next patch, it grows a bit more, so lets not duplicate the logic
in multiple places.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu
From: Rob Clark
This adds a few things to try and make frequency scaling better match
the workload:
1) Longer polling interval to avoid whip-lashing between too-high and
too-low frequencies in certain workloads, like mobile games which
throttle themselves to 30fps.
Previously our polli
From: Rob Clark
Conversion to gpu_scheduler, and bonus removal of
drm_gem_object_put_locked()
v2: Fix priority mixup (msm UAPI has lower numeric priority value as
higher priority, inverse of drm/scheduler) and add some comments
in the UAPI header to clarify.
Now that we move active
From: Rob Clark
Fix a couple incorrect or misspelt comments, and add submitqueue doc
comment.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.h | 3 +--
drivers/gpu/drm/msm/msm_gem_submit.c | 1 +
drivers/gpu/drm/msm/msm_gpu.h | 15 +++
From: Rob Clark
If we don't have a gpu, there is no need to create a submitqueue, which
lets us simplify the error handling and submitqueue creation.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_submitqueue.c | 22 +++---
1 file changed, 11 in
From: Rob Clark
No idea why we were still using this. It certainly hasn't been needed
for some time. So drop the pointless twin codepaths.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c
From: Rob Clark
Now that no one is using it, remove it.
Signed-off-by: Rob Clark
Acked-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 22 --
include/drm/drm_gem.h | 2 --
2 files changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/d
From: Rob Clark
Move all the locked/active/pinned state handling to msm_gem_submit.c.
In particular, for drm/scheduler, we'll need to do all this before
pushing the submit job to the scheduler. But while we're at it we can
get rid of the dupicate pin and refcnt.
Signed-off-by: Rob Clark
Acked-
From: Rob Clark
In the next patch, we start having more than a single potential failure
reason.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem_submit.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/dr
From: Rob Clark
No need for this to be split in two parts.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm
From: Rob Clark
For existing adrenos, there is one or more ringbuffer, depending on
whether preemption is supported. When preemption is supported, each
ringbuffer has it's own priority. A submitqueue (which maps to a
gl context or vk queue in userspace) is mapped to a specific ring-
buffer at c
From: Rob Clark
It is sufficient to serialize on the submit queue now.
Signed-off-by: Rob Clark
Acked-by: Christian König
---
drivers/gpu/drm/msm/msm_gem_submit.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/g
From: Rob Clark
Previously the (non-fd) fence returned from submit ioctl was a raw
seqno, which is scoped to the ring. But from UABI standpoint, the
ioctls related to seqno fences all specify a submitqueue. We can
take advantage of that to replace the seqno fences with a cyclic idr
handle.
Thi
From: Rob Clark
The drm/scheduler provides additional prioritization on top of that
provided by however many number of ringbuffers (each with their own
priority level) is supported on a given generation. Expose the
additional levels of priority to userspace and map the userspace
priority back to
From: Rob Clark
Mark all the bos in the submit as active, before pinning, to prevent
evicting a buffer in the same submit to make room for a buffer earlier
in the table.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 2 --
drivers/gpu/drm/msm/msm_gem_submit.c | 28 +++
> From: Vitaly Lubart
>
> Export PAVP client to work with i915 driver, for binding it uses kernel
> component framework.
>
> Signed-off-by: Vitaly Lubart
> Signed-off-by: Tomas Winkler
> Signed-off-by: Daniele Ceraolo Spurio
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/misc/mei/Kconfig
On Mon, Jul 26, 2021 at 06:59:35AM -0400, Rodrigo Vivi wrote:
On Fri, Jul 23, 2021 at 05:11:02PM -0700, Lucas De Marchi wrote:
Remove special handling of PORT_F in i915_irq.c and only do it for
DISPLAY_VER == 11.
oh! ignore my previous thought about removing the port F...
of course I only sa
On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld
wrote:
>
> On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote:
> >
> > This patch series fixes an issue with discrete graphics on Intel where we
> > allowed dma-buf import while leaving the object in local memory. This
> > breaks down pretty badly if
On Mon, Jul 26, 2021 at 3:06 AM Matthew Auld
wrote:
>
> On Fri, 23 Jul 2021 at 18:48, Jason Ekstrand wrote:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12044
>
> Cool, is that ready to go? i.e can we start merging the kernel + IGT side.
Yes, it's all reviewed. Though, it s
On Mon, Jul 26, 2021 at 3:31 AM Maarten Lankhorst
wrote:
>
> Op 23-07-2021 om 13:34 schreef Matthew Auld:
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > to determine if the userptr object was backed by a complete set of pages
> > upon c
Hi Daniel,
On Wed, Jul 21, 2021 at 02:05:01PM +0200, Daniel Vetter wrote:
> On Tue, Jul 20, 2021 at 03:45:19PM +0200, Maxime Ripard wrote:
> > Interactions between bridges, panels, MIPI-DSI host and the component
> > framework are not trivial and can lead to probing issues when
> > implementing a
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> When modesetting (aka the full pci driver, which has nothing to do
> with disable_display option, which just gives you the full pci driver
> without the display driver) is disabled, we load nothing and do
> nothing.
>
> So move that check fi
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_cache to ju
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_blocks to j
On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote:
>
> On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld
> wrote:
> >
> > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote:
> > >
> > > This patch series fixes an issue with discrete graphics on Intel where we
> > > allowed dma-buf import while leavi
On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
wrote:
>
>
> On 23/07/2021 20:29, Daniel Vetter wrote:
> > With the global kmem_cache shrink infrastructure gone there's nothing
> > special and we can convert them over.
> >
> > I'm doing this split up into each patch because there's quite a bit of
>
On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld
wrote:
>
> On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote:
> >
> > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 23 Jul 2021 at 18:21, Jason Ekstrand wrote:
> > > >
> > > > This patch series fixes an issue with disc
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_luts to jus
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_objects to
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote:
>
> On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
> wrote:
> >
> >
> > On 23/07/2021 20:29, Daniel Vetter wrote:
> > > With the global kmem_cache shrink infrastructure gone there's nothing
> > > special and we can convert them over.
> > >
>
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_requests|ex
On 7/26/2021 8:04 AM, Winkler, Tomas wrote:
From: Vitaly Lubart
Export PAVP client to work with i915 driver, for binding it uses kernel
component framework.
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
dr
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_dependencie
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> With the global kmem_cache shrink infrastructure gone there's nothing
> special and we can convert them over.
>
> I'm doing this split up into each patch because there's quite a bit of
> noise with removing the static global.slab_vmas to jus
On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
>
> No longer used.
>
> Cc: Jason Ekstrand
> Signed-off-by: Daniel Vetter
Reviewed-by: Jason Ekstrand
But, also, tvrtko is right that dumping all that stuff in i915_pci.c
isn't great. Mind typing a quick follow-on that moves i915_init/exit
On Mon, 26 Jul 2021 at 16:32, Jason Ekstrand wrote:
>
> On Mon, Jul 26, 2021 at 10:29 AM Matthew Auld
> wrote:
> >
> > On Mon, 26 Jul 2021 at 16:11, Jason Ekstrand wrote:
> > >
> > > On Mon, Jul 26, 2021 at 3:12 AM Matthew Auld
> > > wrote:
> > > >
> > > > On Fri, 23 Jul 2021 at 18:21, Jason Ek
On 7/24/2021 4:13 PM, Matthew Brost wrote:
On Fri, Jul 23, 2021 at 05:47:45PM -0700, Daniele Ceraolo Spurio wrote:
On 7/22/2021 4:53 PM, Matthew Brost wrote:
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function t
On 26/07/2021 16:42, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
wrote:
On 23/07/2021 20:29, Daniel Vetter wrote:
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can conv
On 26/07/2021 16:14, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 3:31 AM Maarten Lankhorst
wrote:
Op 23-07-2021 om 13:34 schreef Matthew Auld:
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a c
1 - 100 of 238 matches
Mail list logo
