>Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915/mtl: Define MOCS and PAT tables
>for MTL
>
> Hi Fei,
>
> On Mon, Apr 03, 2023 at 03:50:26PM +0300, Jani Nikula wrote:
>> On Fri, 31 Mar 2023, fei.y...@intel.com wrote:
>>> From: Fei Yang
>>>
>>> On MTL, GT can no longer allocate on LLC - only the
On Thu, Apr 06, 2023 at 10:57:48AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:4b0f4525dc4f Add linux-next specific files for 20230331
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13ea0159c8
> kernel
Hi Fei,
On 4/6/2023 4:55 PM, Yang, Fei wrote:
> On 4/1/2023 8:38 AM, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> On MTL, GT can no longer allocate on LLC - only the CPU can.
>> This, along with addition of support for ADM/L4 cache calls a
>> MOCS/PAT table update.
>> Also add PTE encode
On 4/6/23 14:28, Daniel Vetter wrote:
On Thu, 6 Apr 2023 at 19:20, Maíra Canal wrote:
After commit 8ba1648567e2 ("drm: vkms: Refactor the plane composer to
accept new formats") the composition is no longer performed on top of
the primary plane, but instead on top of the CRTC, which means that
Hello,
syzbot found the following issue on:
HEAD commit:4b0f4525dc4f Add linux-next specific files for 20230331
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13ea0159c8
kernel config: https://syzkaller.appspot.com/x/.config?x=85cc4b935a1f7194
On Thu, Apr 06, 2023 at 07:42:44PM +0200, Daniel Vetter wrote:
> But I think there's tools to make sure we don't dig a complete hole with
> these it sounds like. I guess another topic for pestering the rust folks.
Or to put it very bluntly: Could we make Arc at least runtime enforce
(with the
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.
Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.
Signed-off-by: Alan Previn
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Also add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
For both cases, in the back-end gsccs functions for sending messages
to the
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1. UAPI update:
Without actually changing backward compatible behavior, update
i915's drm-uapi comments that describe the possible error values
when creating a context with I915_CONTEXT_PARAM_PROTECTED_CONTENT.
Since the first merge of PXP support on ADL, i915 returns
-ENXIO if a dependency such
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for
This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created
On Fri, Apr 07, 2023 at 02:11:32AM +0900, Asahi Lina wrote:
> On 07/04/2023 00.30, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 11:43:19PM +0900, Asahi Lina wrote:
> > > On 06/04/2023 22.37, Daniel Vetter wrote:
> > > > On Thu, Apr 06, 2023 at 09:21:47PM +0900, Asahi Lina wrote:
> > > > > On
On Thu, 6 Apr 2023 at 19:20, Maíra Canal wrote:
>
> After commit 8ba1648567e2 ("drm: vkms: Refactor the plane composer to
> accept new formats") the composition is no longer performed on top of
> the primary plane, but instead on top of the CRTC, which means that
> now we have a background.
>
>
After commit 8ba1648567e2 ("drm: vkms: Refactor the plane composer to
accept new formats") the composition is no longer performed on top of
the primary plane, but instead on top of the CRTC, which means that
now we have a background.
This opens to the possibility of coloring the background with a
On Thu, Apr 6, 2023 at 5:45 PM Daniel Vetter wrote:
>
> Yeah this all looks great and very hyperlinked.
>
> I think the only nit I have is that for types with two or more type
> variables (like the rbtree) what each of them should represent in the top
> intro. I can guess it's and not the other
On 07/04/2023 00.30, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 11:43:19PM +0900, Asahi Lina wrote:
On 06/04/2023 22.37, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 09:21:47PM +0900, Asahi Lina wrote:
On 06/04/2023 19.09, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 06:05:11PM +0900,
On Thu, 6 Apr 2023 at 18:58, Matthew Brost wrote:
>
> On Thu, Apr 06, 2023 at 08:32:59AM +0200, Daniel Vetter wrote:
> > On Wed, Apr 05, 2023 at 11:58:44PM +, Matthew Brost wrote:
> > > On Wed, Apr 05, 2023 at 03:09:08PM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 04, 2023 at 07:48:27PM
Hi Linus,
As expected not much because a bunch of people are enjoying spring break
around easter. I'll be gone until Tue too.
Cheers, Daniel
drm-fixes-2023-04-06:
drm-fixes for 6.3-rc6
Mostly i915 fixes: dp mst for compression/dsc, perf ioctl uaf, ctx rpm
accounting, gt reset vs huc loading.
On Thu, Apr 06, 2023 at 08:32:59AM +0200, Daniel Vetter wrote:
> On Wed, Apr 05, 2023 at 11:58:44PM +, Matthew Brost wrote:
> > On Wed, Apr 05, 2023 at 03:09:08PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 04, 2023 at 07:48:27PM +, Matthew Brost wrote:
> > > > On Tue, Apr 04, 2023 at
On Fri, Mar 31, 2023 at 01:36:02PM +0200, Stanislaw Gruszka wrote:
> From: Karol Wachowski
>
> Currently job->done_fence is added to every BO handle within a job. If job
> handle (command buffer) is shared between multiple submits, KMD will add
> the fence in each of them. Then bo_wait_ioctl()
On 07/04/2023 01.13, Daniel Vetter wrote:
On Fri, Apr 07, 2023 at 12:53:47AM +0900, Asahi Lina wrote:
On 06/04/2023 23.15, Daniel Vetter wrote:
On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
drm_mm provides a simple range allocator, useful for managing virtual
address ranges. Add
On Mon, Apr 03, 2023 at 11:30:57PM -0300, Fabio Estevam wrote:
> From: Jagan Teki
>
> Samsung MIPI DSIM bridge can be found on Exynos and NXP's
> i.MX8M Mini/Nano/Plus SoCs.
>
> Convert exynos_dsim.txt to yaml.
>
> Used the example node from exynos5433.dtsi instead of the one used in
> the
On 3/31/23 01:02, Jani Nikula wrote:
On Thu, 30 Mar 2023, "Gustavo A. R. Silva" wrote:
Friendly ping: who can take this, please?
It's in drm-intel-gt-next.
Awesome. :) Thank you!
--
Gustavo
commit 02abecdeebfcd3848b26b70778dd7f6eb0db65e1
Author: Gustavo A. R. Silva
On Thu, Apr 06, 2023 at 10:03:51AM -0400, Rodrigo Vivi wrote:
> Hi Daniel,
>
> Here goes drm-intel-next-2023-04-06:
>
> - Fix DPT+shmem combo and add i915.enable_dpt modparam (Ville)
> - i915.enable_sagv module parameter (Ville)
> - Correction to QGV related register addresses (Vinod)
> - IPS
On Thu, 6 Apr 2023 at 17:59, Daniel Vetter wrote:
>
> On Thu, Apr 06, 2023 at 05:33:18PM +0200, Christian König wrote:
> > Am 06.04.23 um 17:24 schrieb Lucas Stach:
> > > Am Donnerstag, dem 06.04.2023 um 16:21 +0200 schrieb Christian König:
> > > > Am 06.04.23 um 12:45 schrieb Lucas Stach:
> > >
On Fri, Apr 07, 2023 at 12:53:47AM +0900, Asahi Lina wrote:
> On 06/04/2023 23.15, Daniel Vetter wrote:
> > On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
> > > drm_mm provides a simple range allocator, useful for managing virtual
> > > address ranges. Add a Rust abstraction to expose
Change locking policy of mmap() callback, making exporters responsible
for handling dma-buf reservation locking. Previous locking policy stated
that dma-buf is locked for both importers and exporters by the dma-buf
core, which caused a deadlock problem for DRM drivers in a case of
self-imported
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by:
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
This patchset makes dma-buf exporters responisble for taking care of
the reservation lock. I also included patch that moves drm-shmem to use
reservation lock, to let CI test the whole set. I'm going to take all
the patches via the drm-misc tree, please give an ack.
Previous policy stated that
On 05/04/2023 21.33, Daniel Vetter wrote:
On Tue, Mar 07, 2023 at 11:25:34PM +0900, Asahi Lina wrote:
DRM Sync Objects are a container for a DMA fence, and can be waited on
signaled, exported, and imported from userspace. Add a Rust abstraction
so Rust DRM drivers can support this
On Thu, Apr 06, 2023 at 05:33:18PM +0200, Christian König wrote:
> Am 06.04.23 um 17:24 schrieb Lucas Stach:
> > Am Donnerstag, dem 06.04.2023 um 16:21 +0200 schrieb Christian König:
> > > Am 06.04.23 um 12:45 schrieb Lucas Stach:
> > > > Am Donnerstag, dem 06.04.2023 um 10:27 +0200 schrieb Daniel
Am Mittwoch, dem 05.04.2023 um 16:44 -0400 schrieb Luben Tuikov:
> On 2023-04-05 13:44, Lucas Stach wrote:
> > Hi Luben,
> >
> > Am Dienstag, dem 04.04.2023 um 00:31 -0400 schrieb Luben Tuikov:
> > > On 2023-03-28 04:54, Lucas Stach wrote:
> > > > Hi Danilo,
> > > >
> > > > Am Dienstag, dem
On 06/04/2023 23.15, Daniel Vetter wrote:
On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
drm_mm provides a simple range allocator, useful for managing virtual
address ranges. Add a Rust abstraction to expose this module to Rust
drivers.
Signed-off-by: Asahi Lina
In the cover
Hi Rob,
Thanks for the review.
On Fri, Apr 7, 2023 at 12:15 AM Rob Herring wrote:
>
> On Fri, Mar 31, 2023 at 05:11:43PM +0800, Pin-yen Lin wrote:
> > ITE IT6505 can be used in systems to switch the DP traffic between
> > two downstreams, which can be USB Type-C DisplayPort alternate mode
> >
On Thu, Apr 06, 2023 at 05:28:59PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 6, 2023 at 4:15 PM Daniel Vetter wrote:
> >
> > Documentation:
> >
> > In drm we try to document all the interfaces that drivers use with formal
> > docs. Yes there's some areas that are not great for historical reasons,
Am 06.04.23 um 17:24 schrieb Lucas Stach:
Am Donnerstag, dem 06.04.2023 um 16:21 +0200 schrieb Christian König:
Am 06.04.23 um 12:45 schrieb Lucas Stach:
Am Donnerstag, dem 06.04.2023 um 10:27 +0200 schrieb Daniel Vetter:
On Thu, 6 Apr 2023 at 10:22, Christian König wrote:
Am 05.04.23 um
On Thu, Apr 06, 2023 at 11:43:19PM +0900, Asahi Lina wrote:
> On 06/04/2023 22.37, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 09:21:47PM +0900, Asahi Lina wrote:
> > > On 06/04/2023 19.09, Daniel Vetter wrote:
> > > > On Thu, Apr 06, 2023 at 06:05:11PM +0900, Asahi Lina wrote:
> > > > > On
On Thu, Apr 6, 2023 at 4:15 PM Daniel Vetter wrote:
>
> Documentation:
>
> In drm we try to document all the interfaces that drivers use with formal
> docs. Yes there's some areas that are not great for historical reasons,
> but for new stuff and new wrappers we're really trying:
>
> - This helps
Am Donnerstag, dem 06.04.2023 um 16:21 +0200 schrieb Christian König:
> Am 06.04.23 um 12:45 schrieb Lucas Stach:
> > Am Donnerstag, dem 06.04.2023 um 10:27 +0200 schrieb Daniel Vetter:
> > > On Thu, 6 Apr 2023 at 10:22, Christian König
> > > wrote:
> > > > Am 05.04.23 um 18:09 schrieb Luben
On 06/04/2023 22.48, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 10:15:56PM +0900, Asahi Lina wrote:
On 06/04/2023 20.55, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 01:44:22PM +0900, Asahi Lina wrote:
On 05/04/2023 23.37, Daniel Vetter wrote:
On Tue, Mar 07, 2023 at 11:25:43PM +0900,
On Fri, Mar 31, 2023 at 05:11:39PM +0800, Pin-yen Lin wrote:
> Analogix 7625 can be used in systems to switch the DP traffic between
> two downstreams, which can be USB Type-C DisplayPort alternate mode
> lane or regular DisplayPort output ports.
>
> Update the binding to accommodate this usage
On Fri, Mar 31, 2023 at 05:11:43PM +0800, Pin-yen Lin wrote:
> ITE IT6505 can be used in systems to switch the DP traffic between
> two downstreams, which can be USB Type-C DisplayPort alternate mode
> lane or regular DisplayPort output ports.
>
> Update the binding to accommodate this usage by
smatch reports
drivers/gpu/drm/vc4/vc4_irq.c:60:1: warning: symbol
'render_wait' was not declared. Should it be static?
This variable is not used so remove it.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/vc4/vc4_irq.c | 2 --
1 file changed, 2 deletions(-)
diff --git
On Thu, Apr 06, 2023 at 03:55:10PM +0200, Daniel Vetter wrote:
> On Thu, Apr 06, 2023 at 04:18:46PM +0300, Mikko Perttunen wrote:
> > On 4/6/23 16:09, Daniel Vetter wrote:
> > > On Thu, Apr 06, 2023 at 02:14:04PM +0200, Thierry Reding wrote:
> > > > Hi Dave, Daniel,
> > > >
> > > > The following
> On 4/1/2023 8:38 AM, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> On MTL, GT can no longer allocate on LLC - only the CPU can.
>> This, along with addition of support for ADM/L4 cache calls a
>> MOCS/PAT table update.
>> Also add PTE encode functions for MTL as it has different PAT
>>
On Thu, Apr 6, 2023, at 16:30, Thomas Zimmermann wrote:
> Replace the architecture's fb_is_primary_device() with the generic
> one from . No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Thomas Bogendoerfer
I think you should at least mention that the existing
fb_pgprotect()
On Thu, Apr 6, 2023, at 16:30, Thomas Zimmermann wrote:
> +
> static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> unsigned long off)
> {
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> }
> +#define fb_pgprotect
On 06/04/2023 22.37, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 09:21:47PM +0900, Asahi Lina wrote:
On 06/04/2023 19.09, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 06:05:11PM +0900, Asahi Lina wrote:
On 06/04/2023 17.27, Daniel Vetter wrote:
On Thu, 6 Apr 2023 at 10:22, Christian König
On Thu, Apr 6, 2023, at 16:30, Thomas Zimmermann wrote:
> Generic implementations of fb_pgprotect() and fb_is_primary_device()
> have been in the source code for a long time. Prepare the header file
> to make use of them.
>
> Improve the code by using an inline function for fb_pgprotect()
> and by
Replace the architecture's fbdev helpers with the generic
ones from . No functional changes.
v2:
* use default implementation for fb_pgprotect() (Arnd)
Signed-off-by: Thomas Zimmermann
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/include/asm/fb.h | 15 +--
1 file
Replace the architecture's fb_is_primary_device() with the generic
one from . No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Vineet Gupta
---
arch/arc/include/asm/fb.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arc/include/asm/fb.h
Fix trailing whitespaces. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/console/sticon.c | 4 +-
drivers/video/console/sticore.c | 102 ++---
drivers/video/fbdev/sticore.h | 14 +--
drivers/video/fbdev/stifb.c | 156
Replace the architecture's fb_is_primary_device() with the generic
one from . No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
---
arch/powerpc/include/asm/fb.h | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Replace the architecture's fbdev helpers with the generic
ones from . No functional changes.
v2:
* use default implementation for fb_pgprotect() (Arnd)
Signed-off-by: Thomas Zimmermann
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: John Paul Adrian Glaubitz
---
arch/sh/include/asm/fb.h | 15
Replace the architecture's fbdev helpers with the generic
ones from . No functional changes.
v2:
* use default implementation for fb_pgprotect() (Arnd)
Signed-off-by: Thomas Zimmermann
Cc: Huacai Chen
Cc: WANG Xuerui
---
arch/loongarch/include/asm/fb.h | 15 +--
1 file
Include for correctness. Sparc does provide
it's own implementation of the contained functions.
v2:
* restore the original fb_pgprotect()
Signed-off-by: Thomas Zimmermann
Cc: "David S. Miller"
---
arch/sparc/include/asm/fb.h | 7 +--
1 file changed, 5 insertions(+), 2
Replace the architecture's fb_is_primary_device() with the generic
one from on systems without CONFIG_STI_CORE. No
functional changes.
Signed-off-by: Thomas Zimmermann
Cc: "James E.J. Bottomley"
Cc: Helge Deller
---
arch/parisc/include/asm/fb.h | 15 ---
1 file changed, 8
STI core files have been located in console and fbdev code. Move
the source code and header to the directories for video helpers.
Also update the config and build rules such that the code depends
on the config symbol CONFIG_STI_CORE, which STI console and STI
framebuffer select automatically.
Move PARISC's implementation of fb_is_primary_device() into the
architecture directory. This the place of the declaration and
where other architectures implement this function. No functional
changes.
Signed-off-by: Thomas Zimmermann
Cc: "James E.J. Bottomley"
Cc: Helge Deller
---
Replace the architecture's fb_is_primary_device() with the generic
one from . No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Thomas Bogendoerfer
---
arch/mips/include/asm/fb.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/mips/include/asm/fb.h
Fix trailing whitespaces. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: "James E.J. Bottomley"
Cc: Helge Deller
---
arch/parisc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index
Include and set the required preprocessor tokens
correctly. x86 now implements its own set of fb helpers, but still
follows the overall pattern.
Signed-off-by: Thomas Zimmermann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: "H. Peter Anvin"
---
Other architectures implment fb_is_primary_device() in a source
file. Do the same on sparc. No functional changes, but allows to
remove several include statement from .
v2:
* don't include in header file
Signed-off-by: Thomas Zimmermann
Cc: "David S. Miller"
---
arch/sparc/Makefile
Merge all variants of fb_pgprotect() into a single function body.
There are two different cases for MMU systems. For non-MMU systems,
the function body will be empty. No functional changes, but this
will help with the switch to .
Signed-off-by: Thomas Zimmermann
---
arch/m68k/include/asm/fb.h |
Replace the architecture's fbdev helpers with the generic
ones from . No functional changes.
v2:
* use default implementation for fb_pgprotect() (Arnd)
Signed-off-by: Thomas Zimmermann
Cc: Russell King
---
arch/arm/include/asm/fb.h | 15 +--
1 file changed, 1 insertion(+),
Replace the architecture's fb_is_primary_device() with the generic
one from . No functional changes.
v2:
* provide empty fb_pgprotect() on non-MMU systems
Signed-off-by: Thomas Zimmermann
Cc: Geert Uytterhoeven
---
arch/m68k/include/asm/fb.h | 10 --
1 file changed, 4
Replace the architecture's fb_is_primary_device() with the generic
one from . No functional changes.
Signed-off-by: Thomas Zimmermann
---
arch/ia64/include/asm/fb.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/ia64/include/asm/fb.h
Various architectures provide with helpers for fbdev
framebuffer devices. Share the contained code where possible. There
is already , which implements generic (as in
'empty') functions of the fbdev helpers. The header was added in
commit aafe4dbed0bf ("asm-generic: add generic versions of common
Generic implementations of fb_pgprotect() and fb_is_primary_device()
have been in the source code for a long time. Prepare the header file
to make use of them.
Improve the code by using an inline function for fb_pgprotect()
and by removing include statements. The default mode set by
Am 06.04.23 um 12:45 schrieb Lucas Stach:
Am Donnerstag, dem 06.04.2023 um 10:27 +0200 schrieb Daniel Vetter:
On Thu, 6 Apr 2023 at 10:22, Christian König wrote:
Am 05.04.23 um 18:09 schrieb Luben Tuikov:
On 2023-04-05 10:05, Danilo Krummrich wrote:
On 4/4/23 06:31, Luben Tuikov wrote:
On
Hi
Am 06.04.23 um 16:04 schrieb Marius Vlad:
[...]
For multiple outputs, you can attach multiple encoders/connectors to
the same CRTC. They will then all display the same screen at the same
display resolution
Yeah, this kind of sounds like cloning to me, and would like to display
On Tue, Mar 07, 2023 at 11:25:32PM +0900, Asahi Lina wrote:
> drm_mm provides a simple range allocator, useful for managing virtual
> address ranges. Add a Rust abstraction to expose this module to Rust
> drivers.
>
> Signed-off-by: Asahi Lina
In the cover letter you mentioned the design open
Hi
Am 05.04.23 um 17:53 schrieb Arnd Bergmann:
On Wed, Apr 5, 2023, at 17:05, Thomas Zimmermann wrote:
Generic implementations of fb_pgprotect() and fb_is_primary_device()
have been in the source code for a long time. Prepare the header file
to make use of them.
Improve the code by using an
Hi Daniel,
Here goes drm-intel-next-2023-04-06:
- Fix DPT+shmem combo and add i915.enable_dpt modparam (Ville)
- i915.enable_sagv module parameter (Ville)
- Correction to QGV related register addresses (Vinod)
- IPS debugfs per-crtc and new file for false_color (Ville)
- More clean-up and
Hi Thomas,
Thanks for the clarifications! Made a couple of remarks in-line.
On 4/6/23 14:29, Thomas Zimmermann wrote:
Hi
Am 06.04.23 um 11:17 schrieb Marius Vlad:
Hi Maira,
Thanks a lot for taking a look. Yeah, indeed, this creates a new
connector, a CRTC and planes for it. Terminology
On Thu, Apr 06, 2023 at 02:19:20PM +0200, Lucas Stach wrote:
> Am Donnerstag, dem 06.04.2023 um 14:09 +0200 schrieb Daniel Vetter:
> > On Thu, Apr 06, 2023 at 12:45:12PM +0200, Lucas Stach wrote:
> > > Am Donnerstag, dem 06.04.2023 um 10:27 +0200 schrieb Daniel Vetter:
> > > > On Thu, 6 Apr 2023
On Thu, Apr 06, 2023 at 04:18:46PM +0300, Mikko Perttunen wrote:
> On 4/6/23 16:09, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 02:14:04PM +0200, Thierry Reding wrote:
> > > Hi Dave, Daniel,
> > >
> > > The following changes since commit
> > > e8d018dd0257f744ca50a729e3d042cf2ec9da65:
> > >
On Thu, Apr 06, 2023 at 10:32:29PM +0900, Asahi Lina wrote:
> On 06/04/2023 20.25, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 02:02:55PM +0900, Asahi Lina wrote:
> > > On 05/04/2023 23.44, Daniel Vetter wrote:
> > > > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > > > +///
On 4/6/23 16:09, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 02:14:04PM +0200, Thierry Reding wrote:
Hi Dave, Daniel,
The following changes since commit e8d018dd0257f744ca50a729e3d042cf2ec9da65:
Linux 6.3-rc3 (2023-03-19 13:27:55 -0700)
are available in the Git repository at:
On Thu, Apr 06, 2023 at 10:15:56PM +0900, Asahi Lina wrote:
> On 06/04/2023 20.55, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 01:44:22PM +0900, Asahi Lina wrote:
> > > On 05/04/2023 23.37, Daniel Vetter wrote:
> > > > On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
> > > > > +///
The macro values just don't match the specs. Fix them.
Fixes: 1482ec00be4a ("drm: Add missing DP DSC extended capability definitions.")
Cc: Vinod Govindapillai
Cc: Stanislav Lisovskiy
Signed-off-by: Jani Nikula
---
include/drm/display/drm_dp.h | 4 ++--
1 file changed, 2 insertions(+), 2
The operator precedence between << and & is wrong, leading to the high
byte being completely ignored. For example, with the 6.4 format, 32
becomes 0 and 24 becomes 8. Fix it, and remove the slightly confusing
and unnecessary DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT macro while at it.
Fixes:
On Thu, Apr 06, 2023 at 09:21:47PM +0900, Asahi Lina wrote:
> On 06/04/2023 19.09, Daniel Vetter wrote:
> > On Thu, Apr 06, 2023 at 06:05:11PM +0900, Asahi Lina wrote:
> > > On 06/04/2023 17.27, Daniel Vetter wrote:
> > > > On Thu, 6 Apr 2023 at 10:22, Christian König
> > > > wrote:
> > > > >
>
On 06/04/2023 18.48, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 06:27:27PM +0900, Asahi Lina wrote:
On 06/04/2023 18.15, Asahi Lina wrote:
On 06/04/2023 18.06, Christian König wrote:
Am 06.04.23 um 10:49 schrieb Asahi Lina:
On 06/04/2023 17.29, Christian König wrote:
Am 05.04.23 um 18:34
On 06/04/2023 20.25, Daniel Vetter wrote:
On Thu, Apr 06, 2023 at 02:02:55PM +0900, Asahi Lina wrote:
On 05/04/2023 23.44, Daniel Vetter wrote:
On Tue, Mar 07, 2023 at 11:25:43PM +0900, Asahi Lina wrote:
+/// Look up a GEM object handle for a `File` and return an `ObjectRef` for it.
From: Daniel Vetter
With the preceding patches it's become defunct. Also I'm about to add
a different boolean argument, so it's better to keep the confusion
down to the absolute minimum.
v2: Since the hypervfb patch got droppped (it's only a pci device for
gen1 vm, not for gen2) there is one
From: Daniel Vetter
vga_default_device really is supposed to cover all corners, at least
for x86. Additionally checking for rom shadowing should be redundant,
because the bios/fw only does that for the boot vga device.
If this turns out to be wrong, then most likely that's a special case
which
From: Daniel Vetter
Instead of calling aperture_remove_conflicting_devices() to remove the
conflicting devices, just call to aperture_detach_devices() to detach
the device that matches the same PCI BAR / aperture range. Since the
former is just a wrapper of the latter plus a sysfb_disable()
The hardware for gma500 is different from the rest, as it uses stolen
framebuffer memory that is not available via PCI BAR. The regular PCI
removal helper cannot detect the framebuffer, while the non-PCI helper
misses possible conflicting VGA devices (i.e., a framebuffer or text
console).
Gma500
From: Daniel Vetter
Since vgaarb has been promoted to be a core piece of the pci subsystem
we don't have to open code random guesses anymore, we actually know
this in a platform agnostic way, and there's no need for an x86
specific hack. See also commit 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
From: Daniel Vetter
A few reasons for this:
- It's really the only one where this matters. I tried looking around,
and I didn't find any non-pci vga-compatible controllers for x86
(since that's the only platform where we had this until a few
patches ago), where a driver participating in
101 - 200 of 307 matches
Mail list logo
