From: Matthew Auld
On some platforms the hw has dropped support for 4K GTT pages when
dealing with LMEM, and due to the design of 64K GTT pages in the hw, we
can only mark the *entire* page-table as operating in 64K GTT mode,
since the enable bit is still on the pde, and not the pte. And since
From: Matthew Auld
LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Reviewed-by: Lucas De
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c
Preparational patches for 64k page support.
Matthew Auld (3):
drm/i915/xehpsdv: set min page-size to 64K
drm/i915/gtt/xehpsdv: move scratch page to system memory
drm/i915: enforce min page size for scratch
Stuart Summers (1):
drm/i915: Add has_64k_pages flag
On 12/7/21 17:43, Laurent Pinchart wrote:
[...]
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
index f1541cc05297..5cfda6f2ba69 100644
---
Hi Marek,
Thank you for the patch.
On Sat, Nov 27, 2021 at 04:24:02AM +0100, Marek Vasut wrote:
> The TC358767/TC358867/TC9595 are all capable of operating in multiple
> modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the
> DPI output port, which can now be connected both as
On 12/7/21 17:28, Dave Stevenson wrote:
Hi,
[...]
Secondly the datasheet states that the DSI Reference Clock Source
Division Selection is done by the MODE1 pin, and switches between
HSCKBY2 divided by 7 and HSCKBY2 divided by 9. There is a stated
assumption that HSCK is either 364MHz or
On Tue, 7 Dec 2021 at 13:59, Marek Vasut wrote:
>
> On 12/7/21 14:34, Dave Stevenson wrote:
>
> Hi,
>
> The TC358767/TC358867/TC9595 are all capable of operating either from
> attached Xtal or from DSI clock lane clock. In case the later is used,
> all I2C accesses will fail until
Hi,
On Mon, Dec 6, 2021 at 5:44 PM Philip Chen wrote:
>
> Hi
>
> On Mon, Dec 6, 2021 at 4:29 PM Douglas Anderson wrote:
> >
> > When we added the support for the AUX channel in commit 13afcdd7277e
> > ("drm/bridge: parade-ps8640: Add support for AUX channel") we forgot
> > to set "drm_dev" to
In the DC driver, we have multiple acronyms that are not obvious most of
the time; the same idea is valid for amdgpu. This commit introduces a DC
and amdgpu glossary in order to make it easier to navigate through our
driver.
Changes since V2:
- Add MMHUB
Changes since V1:
- Yann: Divide
This commit describes how DCN works by providing high-level diagrams
with an explanation of each component. In particular, it details the
Global Sync signals.
Change since V2:
- Add a comment about MMHUBBUB.
Signed-off-by: Rodrigo Siqueira
---
.../gpu/amdgpu/display/config_example.svg |
Display core documentation is not well organized, and it is hard to find
information due to the lack of sections. This commit reorganizes the
documentation layout, and it is preparation work for future changes.
Changes since V1:
- Christian: Group amdgpu documentation together.
- Daniel: Drop
Display core provides a feature that makes it easy for users to debug
Multiple planes by enabling a visual notification at the bottom of each
plane. This commit introduces how to use such a feature.
Signed-off-by: Rodrigo Siqueira
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 34
Introduce how to collect DTN log from debugfs.
Signed-off-by: Rodrigo Siqueira
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst
b/Documentation/gpu/amdgpu/display/dc-debug.rst
Display core provides a feature that makes it easy for users to debug
Pipe Split. This commit introduces how to use such a debug option.
Signed-off-by: Rodrigo Siqueira
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 28 +--
1 file changed, 26 insertions(+), 2 deletions(-)
Display Core (DC) is one of the components under amdgpu, and it has
multiple features directly related to the KMS API. Unfortunately, we
don't have enough documentation about DC in the upstream, which makes
the life of some external contributors a little bit more challenging.
For these reasons,
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
v1:
- Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
v2:
- Use
From: Kevin Tang
Adds MIPI DSI Controller
support for Unisoc's display subsystem.
v5:
- Remove panel_in port for dsi node.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
.../display/sprd/sprd,sharkl3-dsi-host.yaml | 88 +++
1
Adds DPU(Display Processor Unit) support for the Unisoc's display
subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
v2:
- Use drm_xxx to replace all DRM_XXX.
- Use kzalloc to replace devm_kzalloc for sprd_dpu structure init.
v3:
- Remove dpu_layer stuff
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
Reviewed-by: Rob Herring
---
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internal
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Unisoc's display pipeline have several components as below
description, multi display controllers and corresponding physical
ChangeList:
RFC v1:
1. only upstream modeset and atomic at first commit.
2. remove some unused code;
3. use alpha and blend_mode properties;
3. add yaml support;
4. remove auto-adaptive panel driver;
5. bugfix
RFC v2:
1. add sprd crtc and plane module for KMS, preparing for multi crtc
2. remove
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> We are moving away from short term pinning, and need a way to evict
> objects locked by the current context. Pass the ww context to all
> eviction functions, so that they can evict objects that are already
> locked by the current ww
On 07/12/2021 13:10, Tvrtko Ursulin wrote:
On 18/10/2021 10:10, Matthew Auld wrote:
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
On 12/7/21 14:34, Dave Stevenson wrote:
Hi,
The TC358767/TC358867/TC9595 are all capable of operating either from
attached Xtal or from DSI clock lane clock. In case the later is used,
all I2C accesses will fail until the DSI clock lane is running and
supplying clock to the chip.
Move all
On Mon, 6 Dec 2021 at 20:24, Marek Vasut wrote:
>
> On 12/6/21 19:01, Dave Stevenson wrote:
> > Hi Marek
>
> Hi,
>
> >> The TC358767/TC358867/TC9595 are all capable of operating either from
> >> attached Xtal or from DSI clock lane clock. In case the later is used,
> >> all I2C accesses will fail
On 18/10/2021 10:10, Matthew Auld wrote:
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional
Hi
Am 07.12.21 um 12:54 schrieb John Keeping:
Are you able to pick this up (and [1])? Otherwise what is needed here
and who should pick this up?
[1] https://lore.kernel.org/dri-devel/20211101114622.813536-1-j...@metanate.com/
I added both patches to drm-misc-next.
Best regards
Thomas
This is now handled by the DMA-buf framework in the dma_resv obj.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 7 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c| 11 +++---
Add an usage for submissions independent of implicit sync but still
interesting for memory management.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 2 +-
drivers/dma-buf/st-dma-resv.c | 2 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
We have previously done that in the individual drivers but it is
more defensive to move that into the common code.
Dynamic attachments should wait for map operations to complete by themselves.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 18
Makes the code a bit more simpler.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index
Add an usage for kernel submissions. Waiting for those
are mandatory for dynamic DMA-bufs.
Signed-off-by: Christian König
---
drivers/dma-buf/st-dma-resv.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
Not needed any more now we have that inside the framework.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 52 +++--
2 files changed, 6 insertions(+), 47 deletions(-)
diff --git
This change adds the dma_resv_usage enum and allows us to specify why a
dma_resv object is queried for its containing fences.
Additional to that a dma_resv_usage_rw() helper function is added to aid
retrieving the fences for a read or write userspace submission.
This is then deployed to the
Instead of distingting between shared and exclusive fences specify
the fence usage while adding fences.
Rework all drivers to use this interface instead and deprecate the old one.
v2: some kerneldoc comments suggested by Daniel
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c
Audit all the users of dma_resv_add_excl_fence() and make sure they
reserve a shared slot also when only trying to add an exclusive fence.
This is the next step towards handling the exclusive fence like a
shared one.
v2: fix missed case in amdgpu
Signed-off-by: Christian König
---
Use dma_resv_get_singleton() here to eventually get more than one write
fence as single fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
Use dma_resv_get_singleton() here to eventually get more than one write
fence as single fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git
So far we had the approach of using a directed acyclic
graph with the dma_resv obj.
This turned out to have many downsides, especially it means
that every single driver and user of this interface needs
to be aware of this restriction when adding fences. If the
rules for the DAG are not followed
This was added because of the now dropped shared on excl dependency.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 --
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git
Drivers should never touch this directly.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 17 +
include/linux/dma-resv.h | 17 -
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c
Get the write fence using dma_resv_for_each_fence instead of accessing
it manually.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
Instead use the new dma_resv_get_singleton function.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index
Instead use the new dma_resv_get_singleton function.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index
Instead use the new dma_resv_get_singleton function.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index
We can get the excl fence together with the shared ones as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 14 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 --
3 files
Returning the exclusive fence separately is no longer used.
Instead add a write parameter to indicate the use case.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 48
drivers/dma-buf/st-dma-resv.c| 26 ++-
Add a function to simplify getting a single fence for all the fences in
the dma_resv object.
v2: fix ref leak in error handling
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 52 ++
include/linux/dma-resv.h | 2 ++
2 files changed, 54
Use dma_resv_wait() instead of extracting the exclusive fence and
waiting on it manually.
Signed-off-by: Christian König
---
drivers/infiniband/core/umem_dmabuf.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/umem_dmabuf.c
Drivers should never touch this directly.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 26 ++
include/linux/dma-resv.h | 26 +-
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c
This function allows to replace fences from the shared fence list when
we can gurantee that the operation represented by the original fence has
finished or no accesses to the resources protected by the dma_resv
object any more when the new fence finishes.
Then use this function in the amdkfd code
Hi Daniel,
just a gentle ping that you wanted to take a look at this.
Not much changed compared to the last version, only a minor bugfix in
the dma_resv_get_singleton error handling.
Regards,
Christian.
+Hans and Imre
On Mon, Dec 06, 2021 at 02:31:40PM -0800, Bjorn Andersson wrote:
> On Thu 07 Oct 03:17 PDT 2021, Heikki Krogerus wrote:
> > On Wed, Oct 06, 2021 at 01:26:35PM -0700, Prashant Malani wrote:
> > > (CC+ Heikki)
> [..]
> > > On Wed, Oct 6, 2021 at 8:19 AM Doug Anderson
> > > wrote:
>
Am 07.12.21 um 12:35 schrieb Bas Nieuwenhuizen:
On Tue, Dec 7, 2021 at 12:28 PM Lionel Landwerlin
wrote:
On 07/12/2021 13:00, Christian König wrote:
Am 07.12.21 um 11:40 schrieb Bas Nieuwenhuizen:
On Tue, Dec 7, 2021 at 8:21 AM Christian König
wrote:
Am 07.12.21 um 08:10 schrieb Lionel
Hi Thomas,
On Mon, Nov 01, 2021 at 11:34:15AM +, John Keeping wrote:
> On Sun, 31 Oct 2021 19:09:39 +0100
> Thomas Zimmermann wrote:
> > Am 30.10.21 um 14:05 schrieb John Keeping:
> > > On Fri, Oct 29, 2021 at 09:00:08PM +0200, Thomas Zimmermann wrote:
> > >> Am 29.10.21 um 13:50 schrieb
On Tue, Dec 7, 2021 at 12:28 PM Lionel Landwerlin
wrote:
>
> On 07/12/2021 13:00, Christian König wrote:
> > Am 07.12.21 um 11:40 schrieb Bas Nieuwenhuizen:
> >> On Tue, Dec 7, 2021 at 8:21 AM Christian König
> >> wrote:
> >>> Am 07.12.21 um 08:10 schrieb Lionel Landwerlin:
> On 07/12/2021
On 07/12/2021 13:00, Christian König wrote:
Am 07.12.21 um 11:40 schrieb Bas Nieuwenhuizen:
On Tue, Dec 7, 2021 at 8:21 AM Christian König
wrote:
Am 07.12.21 um 08:10 schrieb Lionel Landwerlin:
On 07/12/2021 03:32, Bas Nieuwenhuizen wrote:
See the comments in the code. Basically if the
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
wrote:
>
> Now that freeing objects takes the object lock when destroying the
> backing pages, we can confidently take the object lock even for dead
> objects.
That looks to be a future patch, at least with non-TTM backend? Does
something need to
Am 07.12.21 um 11:40 schrieb Bas Nieuwenhuizen:
On Tue, Dec 7, 2021 at 8:21 AM Christian König wrote:
Am 07.12.21 um 08:10 schrieb Lionel Landwerlin:
On 07/12/2021 03:32, Bas Nieuwenhuizen wrote:
See the comments in the code. Basically if the seqno is already
signalled then we get a NULL
Hi Dan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc4 next-20211207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On Tue, 7 Dec 2021 at 10:06, Maarten Lankhorst
wrote:
>
> On 06-12-2021 18:10, Matthew Auld wrote:
> > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> > wrote:
> >> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> >> the special handling, all callers use the defaults
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
wrote:
>
> In the next commit, we don't evict when refcount = 0.
>
> igt_vm_isolation() continuously tries to pin/unpin at same address,
> but also calls put() on the object, which means the object may not
> be unpinned in time.
>
> Instead of this,
On Tue, Dec 7, 2021 at 8:21 AM Christian König wrote:
>
> Am 07.12.21 um 08:10 schrieb Lionel Landwerlin:
> > On 07/12/2021 03:32, Bas Nieuwenhuizen wrote:
> >> See the comments in the code. Basically if the seqno is already
> >> signalled then we get a NULL fence. If we then put the NULL fence
>
From: tommy-huang
Add interrupt clear register define for further chip support.
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx.h | 1 +
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git
From: Joel Stanley
Enable the GFX device with a framebuffer memory region.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
From: tommy-huang
Add AST2600 chip support and setting.
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index
From: tommy-huang
Add more gfx reset control for ast2600.
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-g6.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index e38c3742761b..b92b24609660
From: tommy-huang
Add more reset and clock select code for AST2600.
The gfx_flags parameter was added for chip caps idenified.
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx.h | 16 +++-
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 16
From: tommy-huang
Add more gfx reset control for ast2600.
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-g6.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index a730c7706ecf..ae7a18b27701
From: Joel Stanley
The GFX device is present in the AST2600 SoC.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-g6.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
From: tommy-huang
v4:
Add necessary reset control for ast2600.
Add chip caps for futher use.
These code are test on AST2500 and AST2600 by below steps.
1. Add below config to turn VT and LOGO on.
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
Am 07.12.21 um 11:20 schrieb Thomas Zimmermann:
Hi
Am 07.12.21 um 10:54 schrieb Hector Martin:
Hi, thanks for the review!
On 07/12/2021 18.40, Thomas Zimmermann wrote:
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
Add XRGB emulation support for devices that can only do
XRGB2101010.
Hi
Am 07.12.21 um 10:54 schrieb Hector Martin:
Hi, thanks for the review!
On 07/12/2021 18.40, Thomas Zimmermann wrote:
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple
Maxime Ripard 於 2021年12月3日 週五 下午10:03寫道：
>
> On Mon, Nov 29, 2021 at 04:31:57PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard 於 2021年11月26日 週五 下午11:45寫道：
> > >
> > > On Fri, Nov 19, 2021 at 06:24:34PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard 於 2021年11月18日 週四 下午6:40寫道：
> > > > >
> > > >
On 06-12-2021 18:10, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> wrote:
>> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
>> the special handling, all callers use the defaults anyway. We only remap
>> in ggtt, so default case will fall
Hi, thanks for the review!
On 07/12/2021 18.40, Thomas Zimmermann wrote:
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is
> -Original Message-
> From: Srivatsa, Anusha
> Sent: Monday, December 6, 2021 9:59 AM
> To: 'Tvrtko Ursulin' ; intel-
> g...@lists.freedesktop.org
> Cc: x...@kernel.org; dri-devel@lists.freedesktop.org; Ingo Molnar
> ; Borislav Petkov ; Dave Hansen
> ; Joonas Lahtinen
> ; Nikula, Jani
Am 06.12.21 um 19:37 schrieb Dan Moulding:
On 04.12.21 17:40, Stefan Fritsch wrote:
Hi,
when updating from 5.14 to 5.15 on a system with NVIDIA GP108 [GeForce
GT 1030] (NV138) and Ryzen 9 3900XT using kde/plasma on X (not wayland),
there is a regression: There is now some annoying black
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
Add XRGB emulation support for devices that can only do XRGB2101010.
This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.
Signed-off-by: Hector Martin
---
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
This is the format used by the bootloader framebuffer on Apple ARM64
platforms.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Hector Martin
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi
Am 07.12.21 um 09:55 schrieb Dan Carpenter:
I appologize. This thread has been really frustrating. I got mixed up
because I recently sent patches for ingenic and vc4. Also we are
working against different trees so maybe that is part of the problem?
I'm looking at today's linux-next.
Am 07.12.21 um 10:02 schrieb Thomas Zimmermann:
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.
Signed-off-by: Hector Martin
Acked-by: Thomas
Hi
Am 07.12.21 um 08:29 schrieb Hector Martin:
This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.
Signed-off-by: Hector Martin
Acked-by: Thomas Zimmermann
This looks much better than before.
Add CCs
On Tue, Dec 7, 2021 at 7:37 AM Brandon Nielsen wrote:
> Monitors no longer sleep properly on my system (dual monitor connected
> via DP->DVI, amdgpu, x86_64). The monitors slept properly on 5.14, but
> stopped during the 5.15 series. I have also filed this bug on the kernel
> bugzilla[0]
I appologize. This thread has been really frustrating. I got mixed up
because I recently sent patches for ingenic and vc4. Also we are
working against different trees so maybe that is part of the problem?
I'm looking at today's linux-next. Your patch has been applied.
Yes. You updated all
Remove duplicated include in drm_gem_shmem_helper.c
Signed-off-by: Yihao Han
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 621924116eb4..7915047cb041 100644
---
Hello,
I found warnings in the stable tree.
Commit: a2547651bc896f95a3680a6a0a27401e7c7a1080 ("Linux 5.15.6")
There are two unique warn locations:
ammarfaizi2@integral2:~$ sudo dmesg -Sr | grep -oiE 'WARNING:.+' | sort | uniq
[sudo] password for ammarfaizi2:
WARNING: CPU: 1 PID: 722 at
On Tue, Nov 30, 2021 at 12:35:45PM -0800, Brian Norris wrote:
> Hi Pekka,
>
> On Fri, Nov 19, 2021 at 12:38:41PM +0200, Pekka Paalanen wrote:
> > On Thu, 18 Nov 2021 17:46:10 -0800
> > Brian Norris wrote:
> > > On Thu, Nov 18, 2021 at 12:39:28PM +0200, Pekka Paalanen wrote:
> > > > On Wed, 17
Hi
Am 06.12.21 um 15:40 schrieb Dan Carpenter:
On Mon, Dec 06, 2021 at 12:16:24PM +0100, Thomas Zimmermann wrote:
Hi
Am 06.12.21 um 11:42 schrieb Dan Carpenter:
On Tue, Nov 30, 2021 at 10:52:55AM +0100, Thomas Zimmermann wrote:
GEM helper libraries use struct drm_driver.gem_create_object to
101 - 191 of 191 matches
Mail list logo
