Hi Laurent,
On Sun, Jan 23, 2022 at 2:52 PM Laurent Pinchart
wrote:
> On Fri, Jan 14, 2022 at 11:17:19AM +0100, Geert Uytterhoeven wrote:
> > On Wed, Jan 12, 2022 at 6:46 PM Biju Das wrote:
> > > Increase buff size for compatible variable to avoid stack corruption
> > > with RZ/G2L SoC's(renesas
On Thu, Jan 20, 2022 at 04:16:11PM +0100, Maxime Ripard wrote:
> The current code, when parsing the EDID Deep Color depths, that the
> YUV422 cannot be used, referring to the HDMI 1.3 Specification.
>
> This specification, in its section 6.2.4, indeed states:
>
> For each supported Deep Color m
On Thu, Jan 20, 2022 at 04:16:12PM +0100, Maxime Ripard wrote:
> The current code assumes that the RGB444 and YUV444 formats are the
> same, but the HDMI 2.0 specification states that:
>
>The three DC_XXbit bits above only indicate support for RGB 4:4:4 at
>that pixel size. Support for YCB
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
as the first is not required, while the second, if not included,
prdouces the following error:
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_bind_dep_await’:
drivers/gpu/drm/i915/i915_vma_resource.c:381:9:
On Thu, Jan 20, 2022 at 04:16:13PM +0100, Maxime Ripard wrote:
> The HDMI specification mentions YCbCr everywhere, but our enums have
> YCrCb. Let's rename it to match.
I think the CrCb nonsense came from the EDID spec. Though IIRC
it used both CbCr and CrCb terminology in different places.
Either
Hi
Am 24.01.22 um 02:08 schrieb Andi Shyti:
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
as the first is not required, while the second, if not included,
prdouces the following error:
'produces'
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_bin
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
as the first is not required, while the second, if not included,
prdouces the following error:
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_bind_dep_await’:
drivers/gpu/drm/i915/i915_vma_resource.c:381:9:
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
as the first is not required, while the second, if not included,
prodouces the following error:
drivers/gpu/drm/i915/i915_vma_resource.c: In function
‘i915_vma_resource_bind_dep_await’:
drivers/gpu/drm/i915/i915_vma_resource.c:381:9:
Sorry for spamming! Just called the command from the history
On Mon, Jan 24, 2022 at 11:42:43AM +0200, Andi Shyti wrote:
> Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
> as the first is not required, while the second, if not included,
> prdouces the following error:
>
> drivers
On 1/23/22 23:30, Wei Liu wrote:
> On Sun, Jan 23, 2022 at 10:27:56PM +, Michael Kelley (LINUX) wrote:
>> From: Wei Liu Sent: Sunday, January 23, 2022 1:56 PM
>>>
>>> On Sun, Jan 16, 2022 at 09:53:06PM +, Haiyang Zhang wrote:
> -Original Message-
> From: Michael K
Hi Christoph and Jason:
Have been talking with Raj. I am going to work on this series this week.
Thanks,
Zhi.
-Original Message-
From: Christoph Hellwig
Sent: Monday, January 24, 2022 11:40 AM
To: Wang, Zhi A
Cc: Christoph Hellwig ; Zhi Wang ;
intel-...@lists.freedesktop.org; intel-g
The static array page_count is read-only so it make sense to make
it const.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/selftests/scatterlist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/scatterlist.c
b/drivers/gpu/drm/i915/self
The static array channel_offsets is read-only so it make sense to make
it const.
Signed-off-by: Colin Ian King
---
drivers/gpu/ipu-v3/ipu-dc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index ca96b235491a..b0
Hello,
this series goal is to change the spi remove callback's return value to void.
After numerous patches nearly all drivers already return 0 unconditionally.
The four first patches in this series convert the remaining three drivers to
return 0, the final patch changes the remove prototype and c
The value returned by an spi driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error
On Fri, 21 Jan 2022, Luiz Sampaio wrote:
> Hello, Daniel
>
> Thanks for your reply. This is one of my first patches, so I am still
> learning. This series of patches affects others subsystems too (hid,
> leds, sound etc). Should I create series for each subsystem
> separately, instead of creating
On 1/21/22 08:20, Gerd Hoffmann wrote:
>>> So if this really has to come back then I think the pragmatic approach is
>>> to do it behind a CONFIG_FBCON_ACCEL, default n, and with a huge warning
>>> that enabling that shouldn't be done for any distro which only enables
>>> firmware and drm fbdev dri
On Fri, 21 Jan 2022 at 23:44, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-01-20 23:37:45)
> > On Fri, 21 Jan 2022 at 07:30, Stephen Boyd wrote:
> > >
> > > Quoting Dmitry Baryshkov (2022-01-19 14:16:15)
> > > > diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> > > > b/drivers/gpu/drm/
Op 24-01-2022 om 10:44 schreef Andi Shyti:
> Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion
> as the first is not required, while the second, if not included,
> prodouces the following error:
>
> drivers/gpu/drm/i915/i915_vma_resource.c: In function
> ‘i915_vma_resource_bind_dep_a
[snip]
>
> What about this proposal:
> a) adding a Kconfig option like:
>CONFIG_FB_DRIVERS - enable if you need the fbdev drivers. For DRM-only
> this should be disabled.
> b) Add to every native fbdev driver a "depends on FB_DRIVERS" in the Kconfig
> files.
> c) That way we can use "#if de
Hi
Am 24.01.22 um 12:10 schrieb Helge Deller:
[...]
Here is my proposed way forward:
a) I will resend the patches which reverts the remove-fbcon-hardware-scolling
patches
to the mailing lists. I'll adjust the stable tags and update the commit
messages.
b) Then after some days I'll include
On 1/24/22 12:33, Thomas Zimmermann wrote:
[snip]
>> Thoughts?
>
> I can't say I approve keeping fbdev alive, but...
>
> With fbdev emulation, every DRM driver is an fbdev driver too. So
> CONFIG_FB_DRIVER is somewhat misleading. Better add an option like
> CONFIG_FBCON_HW_SCROLLING and have
Am 24.01.22 um 02:54 schrieb ira.we...@intel.com:
From: Ira Weiny
Changes from V1:
Use memcpy_to_page() where appropriate
Rebased to latest
The kmap() call may cause issues with work being done with persistent memory.
For this and other reasons it is being deprecated.
I'm rea
Hi guys,
let's hope that I have fixed and documented everything now.
This fixes the fundamental problem in TTM that during a move a buffer
has resources allocated from two different domains at the same time.
Additional to that it's a prerequisite to remove ghost objects and
allow to allocate mul
Make sure we call the common cleanup function in all
implementations of the resource manager.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c| 2 ++
It is simply a lot cleaner to have this around instead of adding
the device throughout the call chain.
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 2 +-
drivers/gpu/drm/amd
Keep track for which BO a resource was allocated.
This is necessary to move the LRU handling into the resources.
A bit problematic is i915 since it tries to use the resource
interface without a BO which is illegal from the conceptional
point of view.
v2: Document that this is a weak reference and
Instead of duplicating that at different places add an iterator over all
the resources in a resource manager.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 41 +++
drivers/gpu/drm/ttm/ttm_device.c | 26 -
drivers/gpu/drm/ttm/ttm
This is provided by TTM now.
Also switch man->size to bytes instead of pages and fix the double
printing of size and usage in debugfs.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 50 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +--
This way we finally fix the problem that new resource are
not immediately evict-able after allocation.
That has caused numerous problems including OOM on GDS handling
and not being able to use TTM as general resource manager.
v2: stop assuming in ttm_resource_fini that res->bo is still valid.
Si
Use the one provided by TTM instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 2 --
drivers/gpu/drm/radeon/radeon_kms.c| 7 --
drivers/gpu/drm/radeon/radeon_object.c | 30 +++---
drivers/gpu/drm/radeon/radeon_object.h | 1 -
drive
This is provided by TTM now.
Also switch man->size to bytes instead of pages and fix the double
printing of size and usage in debugfs.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/a
It makes sense to have this in the common manager for debugging and
accounting of how much resources are used.
v2: cleanup kerneldoc a bit
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/ttm/ttm_resource.c | 8
include/drm/ttm/ttm_resource.h | 20 +++
We have the BO pointer in the base structure now as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 49 -
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/
Instead of providing the bulk move structure for each LRU update set
this as property of the BO. This should avoid costly bulk move rebuilds
with some games under RADV.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 72
Not just TT and VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_resource.c | 49 +-
include/drm/ttm/ttm_device.h | 2 --
include/drm/ttm/ttm_resource.h | 4 +--
3 files changed, 16 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/d
Smatch detected a divide by zero bug in check_overlay_scaling().
drivers/gpu/drm/i915/display/intel_overlay.c:976 check_overlay_scaling()
error: potential divide by zero bug '/ rec->dst_height'.
drivers/gpu/drm/i915/display/intel_overlay.c:980 check_overlay_scaling()
error: potenti
Add a TODO item about requesting memory regions for each driver. The
current DRM drivers don't do this consistently.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gp
From: Javier Martinez Canillas
The sysfb_create_simplefb() function requests a IO memory resource for the
simple-framebuffer platform device, but it also marks it as busy which can
lead to drivers requesting the same memory resource to fail.
Let's drop the IORESOURCE_BUSY flag and let drivers to
Hot-unplug all firmware-framebuffer devices as part of removing
them via remove_conflicting_framebuffers() et al. Releases all
memory regions to be acquired by native drivers.
Firmware, such as EFI, install a framebuffer while posting the
computer. After removing the firmware-framebuffer device fr
Requesting the framebuffer memory in simpledrm marks the memory
range as busy. This used to be done by the firmware sysfb code,
but the driver is the correct place.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 20 +++-
1 file changed, 15 insertions(+),
Requesting the framebuffer memory in simpledrm marks the memory
range as busy. This used to be done by the firmware sysfb code,
but the driver is the correct place.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/simplefb.c | 59 --
1 file changed, 42 ins
Request framebuffer memory in simpledrm and simplefb. Do a hot-unplug
operation when removing fbdev firmware drivers.
After being unloaded by a hardware driver, simplefb leaves behind the
firmware framebuffer's platform device. This prevents other drivers
from acquiring the memory as reported at [
Hi
Am 21.01.22 um 16:25 schrieb dann frazier:
[...]
hey,
I'm seeing a regression that I bisected down to this change. I
installed GNOME on a couple of different server models that have
AMI-based BMCs, which provide a web-based graphics display (virtual
KVM). When I enter the lock screen on c
Since i915_gem_create_context() function return error pointers,
the kernel_context() function does not return null, It returns error
pointers too. Using IS_ERR() to check the return value to fix this.
Signed-off-by: Miaoqian Lin
---
Changes in v2:
- clean up unneeded initialization of err.
---
d
set_cache_level may unbind the object, which will result in the below
lockdep splat:
<6> [184.578145] [IGT] kms_addfb_basic: starting subtest
addfb25-framebuffer-vs-set-tiling
<4> [184.578220] [ cut here ]
<4> [184.578221] WARN_ON(debug_locks &&
!(lock_is_held(&(&((obj)->b
Hi guys,
as previously discussed only dma_fence_chain with its previous fence is
actually made to build up larger dma_fence structures. Everything else should
either flatten all fences into a single dma_fence_array or just add each fence
separately to the dma_resv object.
Please review and/or
Instead of calling the debug operation directly.
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index
Drivers should not add containers as shared fences to the dma_resv
object, instead each fence should be added individually.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/dma-buf/dma-resv.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the subclasses.
Signed-off-by: Christian König
---
include/linux/dma-fence-array.h | 15 +
Instead of calling the debug operation directly.
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu
Chaining of dma_fence_chain objects is only allowed through the prev
fence and not through the contained fence.
Warn about that when we create a dma_fence_chain.
v2: fix comment style
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Reviewed-by: Thomas Hellström
---
drivers/dma-buf/
It's not allowed to nest another dma_fence container into a dma_fence_array
or otherwise we can run into recursion.
Warn about that when we create a dma_fence_array.
v2: fix comment style and typo in the warning pointed out by Thomas
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
--
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
- Retur
It's a reoccurring pattern that we need to extract the fence
from a dma_fence_chain object. Add a helper for this.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 6 ++
include/linux/dma-fence-chain.h | 15 +++
2 files changed, 17 insertions(+), 4 deleti
Decomposing fence containers don't seem to make any sense here.
So just remove the function entirely and call dma_fence_wait() directly.
Signed-off-by: Christian König
Cc: VMware Graphics
Cc: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
Instead of manually messing with the data structures use the iterators
and extraction helpers provided by the framework.
This whole handling should essentially go away when boost handling is
implemented in the core dma-buf framework.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i
Instead of manually extracting the fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index f7d8487799b2..
On Fri, 21 Jan 2022, Matthew Brost wrote:
> On Fri, Jan 21, 2022 at 09:28:46AM +0200, Jani Nikula wrote:
>> On Thu, 20 Jan 2022, Matthew Brost wrote:
>> > Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
>> > set, before CT write / read as this could result in a read across t
On Mon, Jan 24, 2022 at 12:12:12PM +0200, zhi.wang.li...@gmail.com wrote:
> Hi Christoph and Jason:
>
> Have been talking with Raj. I am going to work on this series this week.
Thanks!
Jason
On Mon, Jan 24, 2022 at 10:52:22AM +0100, Helge Deller wrote:
> On 1/23/22 23:30, Wei Liu wrote:
> > On Sun, Jan 23, 2022 at 10:27:56PM +, Michael Kelley (LINUX) wrote:
> >> From: Wei Liu Sent: Sunday, January 23, 2022 1:56 PM
> >>>
> >>> On Sun, Jan 16, 2022 at 09:53:06PM +, Haiyang Zhang
On 1/24/22 14:31, Wei Liu wrote:
> On Mon, Jan 24, 2022 at 10:52:22AM +0100, Helge Deller wrote:
>> On 1/23/22 23:30, Wei Liu wrote:
>>> On Sun, Jan 23, 2022 at 10:27:56PM +, Michael Kelley (LINUX) wrote:
From: Wei Liu Sent: Sunday, January 23, 2022 1:56 PM
>
> On Sun, Jan 16, 202
Hello Thomas,
Thanks for the patch.
On 1/24/22 13:36, Thomas Zimmermann wrote:
> Hot-unplug all firmware-framebuffer devices as part of removing
> them via remove_conflicting_framebuffers() et al. Releases all
> memory regions to be acquired by native drivers.
>
> Firmware, such as EFI, install
TE-gpio, if defined, is placed in the panel's node, not the parent DSI
node. Change the devm_gpiod_get_optional() to gpiod_get_optional() and
pass proper device node to it. The code already has a proper cleanup
path, so it looks that the devm_* variant has been applied assidentally
during the conve
From: Tom Rix
clang static analysis reports this represenative problem
amdgpu_smu.c:144:18: warning: The left operand of '*' is a garbage value
return clk_freq * 100;
^
If there is no get_dpm_ultimate_freq function,
smu_get_dpm_freq_range returns success without s
On 1/24/22 14:52, Javier Martinez Canillas wrote:
[snip]
>> @@ -1898,9 +1917,13 @@ EXPORT_SYMBOL(register_framebuffer);
>> void
>> unregister_framebuffer(struct fb_info *fb_info)
>> {
>> -mutex_lock(®istration_lock);
>> +bool forced_out = fb_info->forced_out;
>> +
>> +if (!forced_o
On 1/24/22 13:36, Thomas Zimmermann wrote:
> Requesting the framebuffer memory in simpledrm marks the memory
> range as busy. This used to be done by the firmware sysfb code,
> but the driver is the correct place.
>
> Signed-off-by: Thomas Zimmermann
> ---
Looks good to me.
Reviewed-by: Javier
On Mon, Jan 24, 2022 at 02:48:57PM +0100, Helge Deller wrote:
> On 1/24/22 14:31, Wei Liu wrote:
[...]
> >>
> >> Linus hasn't pulled my tree yet, and he will probably not before the
> >> next merge window. So, if this is an urgent bugfix for you, I can offer
> >> to drop it from the fbdev tree and
Hi
Am 24.01.22 um 14:52 schrieb Javier Martinez Canillas:
Hello Thomas,
Thanks for the patch.
On 1/24/22 13:36, Thomas Zimmermann wrote:
Hot-unplug all firmware-framebuffer devices as part of removing
them via remove_conflicting_framebuffers() et al. Releases all
memory regions to be acquired
On 24/01/2022 13:36, Thomas Zimmermann wrote:
Requesting the framebuffer memory in simpledrm marks the memory
range as busy. This used to be done by the firmware sysfb code,
but the driver is the correct place.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 20 +++
On 1/24/2022 7:22 PM, t...@redhat.com wrote:
From: Tom Rix
clang static analysis reports this represenative problem
amdgpu_smu.c:144:18: warning: The left operand of '*' is a garbage value
return clk_freq * 100;
^
If there is no get_dpm_ultimate_freq functi
On 1/24/22 13:36, Thomas Zimmermann wrote:
> Requesting the framebuffer memory in simpledrm marks the memory
> range as busy. This used to be done by the firmware sysfb code,
> but the driver is the correct place.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/video/fbdev/simplefb.c | 59 +
On 1/24/22 13:36, Thomas Zimmermann wrote:
> Add a TODO item about requesting memory regions for each driver. The
> current DRM drivers don't do this consistently.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux
On 1/24/22 15:19, Thomas Zimmermann wrote:
[snip]
>>> + if (dev_is_platform(dev)) {
>>
>> In do_register_framebuffer() creating the fb%d is not a fatal error. It would
>> be safer to do if (!IS_ERR_OR_NULL(dev) && dev_is_platform(dev)) instead
>> here.
>>
>> https://elixir.boot
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 58a242871b28..9ea
On Sun, 23 Jan 2022, Philipp Zabel wrote:
> Add minimal support for parsing VSDBs documented in Microsoft's "EDID
> extension for head-mounted and specialized monitors" [1]. The version
> field and the desktop usage flag can be used to set the non_desktop
> connector property.
>
> [1]
> https://d
On Sun, 23 Jan 2022, Philipp Zabel wrote:
> On Tue, Dec 28, 2021 at 11:10 AM Jani Nikula wrote:
>>
>> Improve non-desktop quirk logging if the EDID indicates non-desktop. If
>> both are set, note about redundant quirk. If there's no quirk but the
>> EDID indicates non-desktop, don't log non-deskt
Fix request cancellation + add request cancel low level trace point.
v2:
- Update cancel reset selftest preemption timeout value to zero
- Fix bug in execlists cancel code
Signed-off-by: Matthew Brost
Matthew Brost (4):
drm/i915: Add request cancel low level trace point
drm/i915/guc: Ca
Set the preemption timeout to zero to prove that request cancellation
with preemption disabled works. Also this seals a race between a
possible preemption and request cancellation.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/selftests/i915_request.c | 7 ---
1 file changed, 4 inser
Change the preemption timeout to the smallest possible value (1 us) when
disabling scheduling to cancel a request and restore it after
cancellation. This not only cancels the request as fast as possible, it
fixes a bug where the preemption timeout is 0 which results in the
schedule disable hanging
Add request cancel trace point guarded by
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINT.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.h | 1 +
drivers/gpu/drm/i915/i915_trace.h | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_
More than 1 request can be submitted to a single ELSP at a time if
multiple requests are ready run to on the same context. When a request
is canceled it is marked bad, an idle pulse is triggered to the engine
(high priority kernel request), the execlists scheduler sees that
running request is bad a
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 58a242871b28..6e3
Sorry - noise. Ignore this one. Following one is fixed.
On 1/24/22 15:13, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 file cha
On 2022-01-21 20:23, Randy Dunlap wrote:
> Change a static function's comment from "/**" (indicating kernel-doc
> notation) to "/*" (indicating a regular C language comment).
> This prevents multiple kernel-doc warnings:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warnin
On Mon, 2022-01-24 at 14:03 +0100, Christian König wrote:
> Decomposing fence containers don't seem to make any sense here.
>
> So just remove the function entirely and call dma_fence_wait()
> directly.
>
> Signed-off-by: Christian König
> Cc: VMware Graphics
> Cc: Zack Rusin
Looks good. That
On 1/24/22 12:50, Javier Martinez Canillas wrote:
> On 1/24/22 12:33, Thomas Zimmermann wrote:
>
> [snip]
>
>>> Thoughts?
>>
>> I can't say I approve keeping fbdev alive, but...
>>
>> With fbdev emulation, every DRM driver is an fbdev driver too. So
>> CONFIG_FB_DRIVER is somewhat misleading. Bette
Hi
Am 24.01.22 um 16:29 schrieb Helge Deller:
On 1/24/22 12:50, Javier Martinez Canillas wrote:
On 1/24/22 12:33, Thomas Zimmermann wrote:
[snip]
Thoughts?
I can't say I approve keeping fbdev alive, but...
With fbdev emulation, every DRM driver is an fbdev driver too. So
CONFIG_FB_DRIVER
On 1/24/22 14:02, Maarten Lankhorst wrote:
set_cache_level may unbind the object, which will result in the below
lockdep splat:
<6> [184.578145] [IGT] kms_addfb_basic: starting subtest
addfb25-framebuffer-vs-set-tiling
<4> [184.578220] [ cut here ]
<4> [184.578221] WARN
Hi Helge,
On Mon, Jan 24, 2022 at 4:30 PM Helge Deller wrote:
> On 1/24/22 12:50, Javier Martinez Canillas wrote:
> > On 1/24/22 12:33, Thomas Zimmermann wrote:
> >
> > [snip]
> >
> >>> Thoughts?
> >>
> >> I can't say I approve keeping fbdev alive, but...
> >>
> >> With fbdev emulation, every DRM
On Mon, Jan 24, 2022 at 12:33 PM Thomas Zimmermann wrote:
> With fbdev emulation, every DRM driver is an fbdev driver too. So
Some are even without?
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: ret = register_framebuffer(info);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven
On Mon, Jan 24, 2022 at 04:29:34PM +0100, Helge Deller wrote:
> On 1/24/22 12:50, Javier Martinez Canillas wrote:
> > On 1/24/22 12:33, Thomas Zimmermann wrote:
> >
> > [snip]
> >
> >>> Thoughts?
> >>
> >> I can't say I approve keeping fbdev alive, but...
> >>
> >> With fbdev emulation, every DRM d
Sorry - I meant disregard THIS one - following patch is right.
On 1/24/22 14:58, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 f
On Mon, 2022-01-24 at 13:36 +0100, Thomas Zimmermann wrote:
> Hot-unplug all firmware-framebuffer devices as part of removing
> them via remove_conflicting_framebuffers() et al. Releases all
> memory regions to be acquired by native drivers.
>
> Firmware, such as EFI, install a framebuffer while p
On Mon, 2022-01-24 at 13:36 +0100, Thomas Zimmermann wrote:
> From: Javier Martinez Canillas
>
> The sysfb_create_simplefb() function requests a IO memory resource for
> the
> simple-framebuffer platform device, but it also marks it as busy which
> can
> lead to drivers requesting the same memory
On Sun, 23 Jan 2022 18:25:18 +0100, Noralf Trønnes wrote:
> Add binding for MIPI DBI compatible SPI panels.
>
> Signed-off-by: Noralf Trønnes
> ---
> .../display/panel/panel-mipi-dbi-spi.yaml | 69 +++
> 1 file changed, 69 insertions(+)
> create mode 100644
> Documentatio
On Sun, 23 Jan 2022 17:37:27 +, Caleb Connolly wrote:
> Add devicetree bindings for the Focaltech FTS touchscreen drivers.
>
> Signed-off-by: Caleb Connolly
> ---
> .../input/touchscreen/focaltech,fts.yaml | 78 +++
> 1 file changed, 78 insertions(+)
> create mode 10064
On Sun, Jan 23, 2022 at 05:54:05PM -0800, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> kmap() is being deprecated and these instances are easy to convert to
> kmap_local_page().
>
> Furthermore, in gma_crtc_cursor_set() use the memcpy_from_page() helper
> instead of an open coded use of kmap
On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes wrote:
>
> Add binding for MIPI DBI compatible SPI panels.
I'm sure we already have MIPI DBI panels. What's this for?
>
> Signed-off-by: Noralf Trønnes
> ---
> .../display/panel/panel-mipi-dbi-spi.yaml | 69 +++
> 1 file chang
Hi
Am 24.01.22 um 16:50 schrieb Geert Uytterhoeven:
On Mon, Jan 24, 2022 at 12:33 PM Thomas Zimmermann wrote:
With fbdev emulation, every DRM driver is an fbdev driver too. So
Some are even without?
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: ret = register_framebuffer(info);
Well, I counted
1 - 100 of 185 matches
Mail list logo
