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 Laurent,
> Subject: Re: [RFC 10/28] drm: rcar-du: of: Increase buff size for
> compatible variable
>
> Hi Geert,
>
> On Mon, Jan 24, 2022 at 09:18:52AM +0100, Geert Uytterhoeven wrote:
> > On Sun, Jan 23, 2022 at 2:52 PM Laurent Pinchart wrote:
> > > On Fri, Jan 14, 2022 at 11:17:19AM +0100,
On Tue, Jan 25, 2022 at 07:03:43PM +0200, Jani Nikula wrote:
> The DP 2.0 errata completely overhauls the 128b/132b link training, with
> no provisions for backward compatibility with the original DP 2.0
> specification.
>
> The changes are too intrusive to consider reusing the same code for both
On Tue, Jan 25, 2022 at 11:39 PM Bjorn Helgaas wrote:
>
> [+cc Maarten, Maxime, Thomas; beginning of thread:
> https://lore.kernel.org/r/20220106000658.243509-1-helg...@kernel.org]
>
> On Tue, Jan 25, 2022 at 10:51:15AM +0800, Huacai Chen wrote:
> > Hi, Bjorn,
> >
> > Why this series still missing
On Wed, Jan 05, 2022 at 12:04:34PM +0100, Oleksij Rempel wrote:
> Hi Shawn,
>
> sorry for the delay, I just came back to work.
>
> On Mon, Dec 06, 2021 at 09:06:28AM +0800, Shawn Guo wrote:
> > On Mon, Nov 22, 2021 at 01:43:10PM +0100, Oleksij Rempel wrote:
> > > The tsc2046 is an ADC used as tou
Hi Geert,
On Mon, Jan 24, 2022 at 09:18:52AM +0100, Geert Uytterhoeven wrote:
> 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 compa
Following what was done in drm_cache.c, when the stub for
remap_io_mapping() was added in commit 67c430bbaae1 ("drm/i915: Skip
remap_io_mapping() for non-x86 platforms"), it was added a log message.
However the WARN_ON_ONCE() should already be enough - we don't want to
spam the log with those messa
Architectures others than x86 have a stub implementation calling
WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
the header-test target will fail with:
HDRTEST drivers/gpu/drm/i915/i915_mm.h
In file included from :
./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_ma
Only x86 and in some cases PPC have support added in drm_cache.c for the
clflush class of functions. However warning once is sufficient to taint
the log instead of spamming it with "Architecture has no drm_cache.c
support" every few millisecond.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas
Some minor fixes and changes to help porting i915 to arm64, or even
anything !x86.
Lucas De Marchi (3):
drm: Stop spamming log with drm_cache message
drm/i915: Do not spam log with missiing arch support
drm/i915: Fix header test for !CONFIG_X86
drivers/gpu/drm/drm_cache.c| 3 ---
drive
On 2022-01-25 19:12, Helge Deller wrote:
Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable bitblt and fillrect hardware acceleration in the framebuffer
console. If disabled, such acceleration will not be used, even if it is
supported by the graphics hardware driver.
If
Hi,
On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
wrote:
>
> Hello Doug,
>
> On 1/25/22 22:54, Douglas Anderson wrote:
> > Recently we added generic "edp-panel"s probed by EDID. To support
> > panels in this way we look at the panel ID in the EDID and look up the
> > panel in a table t
Hi Dave & Daniel,
A few fixes for v5.17.
The following changes since commit 6ed95285382d6f90a3c3a11d5806a5eb7db715c3:
drm/msm/a5xx: Fix missing CP_PROTECT for SMMU on A540 (2021-12-17
15:09:46 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git drm-msm
Hello Doug,
On 1/25/22 22:54, Douglas Anderson wrote:
> Recently we added generic "edp-panel"s probed by EDID. To support
> panels in this way we look at the panel ID in the EDID and look up the
> panel in a table that has power sequence timings. If we find a panel
> that's not in the table we wil
Since now all GPU resets are serialzied there is no need for this.
This patch also reverts 'drm/amdgpu: race issue when jobs on 2 ring timeout'
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 89 ++
1 file chang
Since we serialize all resets no need to protect from concurrent
resets.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_xg
We should have a single instance per entrire reset domain.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 1 +
driver
This functions needs to be split into 2 parts where
one is called only once for locking single instance of
reset_domain's sem and reset flag and the other part
which handles MP1 states should still be called for
each device in XGMI hive.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/a
Since we have a single instance of reset semaphore which we
lock only once even for XGMI hive we don't need the nested
locking hint anymore.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff
We want single instance of reset sem across all
reset clients because in case of XGMI we should stop
access cross device MMIO because any of them could be
in a reset in the moment.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdg
Use reset domain wq also for non TDR gpu recovery trigers
such as sysfs and RAS. We must serialize all possible
GPU recoveries to gurantee no concurrency there.
For TDR call the original recovery function directly since
it's already executed from within the wq. For others just
use a wrapper to qeue
The reset domain contains register access semaphor
now and so needs to be present as long as each device
in a hive needs it and so it cannot be binded to XGMI
hive life cycle.
Adress this by making reset domain refcounted and pointed
by each member of the hive and the hive itself.
Signed-off-by: A
Restrict jobs resubmission to suspend case
only since schedulers not initialised yet on
probe.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
No need to to trigger another work queue inside the work queue.
v3:
Problem:
Extra reset caused by host side FLR notification
following guest side triggered reset.
Fix: Preven qeuing flr_work from mailbox irq if guest
already executing a reset.
Suggested-by: Liu Shaoyun
Signed-off-by: Andrey Gr
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/d
Defined a reset_domain struct such that
all the entities that go through reset
together will be serialized one against
another. Do it for both single device and
XGMI hive cases.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Daniel Vetter
Suggested-by: Christian König
Reviewed-by: Christian Kön
This patchset is based on earlier work by Boris[1] that allowed to have an
ordered workqueue at the driver level that will be used by the different
schedulers to queue their timeout work. On top of that I also serialized
any GPU reset we trigger from within amdgpu code to also go through the same
o
Recently we added generic "edp-panel"s probed by EDID. To support
panels in this way we look at the panel ID in the EDID and look up the
panel in a table that has power sequence timings. If we find a panel
that's not in the table we will still attempt to use it but we'll use
conservative timings. W
this patchwork CI test is failing.
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21938/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
I dont understand what went wrong, but I dont see how patchset could
be involved,
it is drm.debug code, and I dont see evidence that it is even active.
It wo
On 1/25/22 12:21, Andy Shevchenko wrote:
> Replace 'depends on FB_TFT' by 'if FB_TFT ... endif'
> for the sake of deduplication.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/video/fbtft/Kconfig | 33 -
> 1 file changed, 4 insertions(+), 29 deletions(-)
>
https://bugzilla.kernel.org/show_bug.cgi?id=215436
spassw...@web.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
The driver is in maintenance mode, i.e. no new drivers will be accepted,
and for a long time it is part of the kernel, means no need to clone any
separate sources.
Signed-off-by: Andy Shevchenko
---
drivers/video/fbtft/README | 32
drivers/video/fbtft/TODO | 3
Let's maintain occasional fixes to the fbtft driver.
Signed-off-by: Andy Shevchenko
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..16e614606ac1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7372,9 +7372,11 @@
The driver is under maintenance mode, but some of the devices supported
by it are not going to be converted to (tiny) DRM in the feasible future.
In order to support them, move driver out from staging.
Signed-off-by: Andy Shevchenko
---
MAINTAINERS | 2 +-
Replace 'depends on FB_TFT' by 'if FB_TFT ... endif'
for the sake of deduplication.
Signed-off-by: Andy Shevchenko
---
drivers/video/fbtft/Kconfig | 33 -
1 file changed, 4 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbtft/Kconfig b/drivers/video/fb
Since we got a maintainer for fbdev, I would like to
unorphan fbtft (with the idea of sending PRs to Helge)
and move it out of staging since there is no more clean
up work expected and no more drivers either.
Thoughts?
Andy Shevchenko (4):
fbtft: Unorphan the driver
fbtft: Move driver out fro
On 1/25/22 20:17, Helge Deller wrote:
> On 1/25/22 20:12, Helge Deller wrote:
>> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
>> enable bitblt and fillrect hardware acceleration in the framebuffer
>> console. If disabled, such acceleration will not be used, even if it is
>>
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no long
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
Suggested-by: Ma
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting
This series continues support for 64K pages for discrete cards.
It supersedes the 64K patches from
https://patchwork.freedesktop.org/series/95686/#rev4
Changes since that series:
- set min alignment for DG2 to 2MB in i915_address_space_init
- replace coloring with simpler 2MB VA alignment for lme
On 1/25/22 20:12, Helge Deller wrote:
> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
> enable bitblt and fillrect hardware acceleration in the framebuffer
> console. If disabled, such acceleration will not be used, even if it is
> supported by the graphics hardware driver.
Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable bitblt and fillrect hardware acceleration in the framebuffer
console. If disabled, such acceleration will not be used, even if it is
supported by the graphics hardware driver.
If you plan to use DRM as your main graphics
Reviewed-by: Lyude Paul
On Tue, 2022-01-25 at 00:58 +0800, Zhou Qingyang wrote:
> In nvkm_acr_hsfw_load_bl(), the return value of kmalloc() is directly
> passed to memcpy(), which could lead to undefined behavior on failure
> of kmalloc().
>
> Fix this bug by using kmemdup() instead of kmalloc()
On 1/25/2022 01:13, Colin Ian King wrote:
There is a spelling mistake in a drm_err error message. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by: John Harrison
However, note that this message is going to be deleted anyway. Or at
least dropped down to an informational. Partly, there was c
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #60 from Spencer (s...@nandre.com) ---
As an append to both comments, a working boot spits out this:
Loading firmware: amdgpu/navi10_sos.bin
Loading firmware: amdgpu/navi10_asd.bin
Loading firmware: amdgpu/navi10_ta.bin
amdgpu :28
On 1/20/2022 2:24 PM, Daniele Ceraolo Spurio wrote:
Starting from xehpsdv, bit 0 of of the GuC shim control register has
been repurposed, while bit 2 is now reserved, so we need to avoid
setting those for their old meaning on newer platforms.
Cc: Vinay Belgaumkar
Cc: Stuart Summers
Signed-of
On 1/24/2022 5:50 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-24 14:44:52)
DP driver is a generic driver which supports both eDP and DP.
For debugging purpose it is required to have capabilities to
differentiate message are generated from eDP or DP. This patch
add connector type into
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #59 from Spencer (s...@nandre.com) ---
>Is this a custom built kernel? Is amdgpu built into the kernel or enabled as a
>module? In the former case, is all required firmware also built into the
>kernel? In the later case, is all require
On Tue, Jan 25, 2022 at 1:28 AM Tvrtko Ursulin
wrote:
>
>
> On 23/01/2022 18:38, Yury Norov wrote:
> > i915_pmu_cpu_online() calls cpumask_weight() to check if any bit of a
> > given cpumask is set. We can do it more efficiently with cpumask_empty()
> > because cpumask_empty() stops traversing the
Hi Dave, Daniel,
this patch relaxes the submit size checks added in the last merge
window. Turns out that we have existing userspace that overruns its max
size target due to a bug and thus gets denied now.
Regards,
Lucas
The following changes since commit
e783362eb54cd99b2cac8b3a9aeac942e6f6ac07
Acked-by: Lyude Paul
BTW - I made a ton of progress last week on getting all of this stuff moved
into the atomic state :), mainly just trying to get amd hooked up with this
now (and need to rebase):
https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/mst-atomic-only-v1
So we soon won't n
Make use of the struct_size() helper instead of an open-coded version,
in order to avoid any potential type mistakes or integer overflows that,
in the worst scenario, could lead to heap overflows.
Also, address the following sparse warnings:
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:792:23: warnin
Add a driver that will work with most MIPI DBI compatible SPI panels.
This avoids adding a driver for every new MIPI DBI compatible controller
that is to be used by Linux. The 'compatible' Device Tree property with
a '.bin' suffix will be used to load a firmware file that contains the
controller co
Hi,
This patchset adds a driver that will work with most MIPI DBI compatible
SPI panels out there.
It's a follow up on 'drm/tiny/st7735r: Match up with staging/fbtft
driver'[1] which aimed at making the st7735r driver work with all panels
adding DT properties.
Maxime gave[2] a good overview of t
devm_drm_dev_alloc() can't allocate structures that embed a structure
which then again embeds drm_device. Workaround this by adding a
driver_private pointer to struct mipi_dbi_dev which the driver can use for
its additional state.
Signed-off-by: Noralf Trønnes
---
include/drm/drm_mipi_dbi.h | 2
Add binding for MIPI DBI compatible SPI panels.
v2:
- Fix path for panel-common.yaml
- Use unevaluatedProperties
- Drop properties which are in the allOf section
- Drop model property (Rob)
Signed-off-by: Noralf Trønnes
---
.../display/panel/panel-mipi-dbi-spi.yaml | 59 +++
On Mon, Jan 24, 2022 at 01:25:13PM +0100, Christian König wrote:
> 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 +--
On Mon, Jan 24, 2022 at 01:25:14PM +0100, Christian König wrote:
> 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
I think I get what yo
128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
slot 0 for metadata.
Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
on Encoding Format") added support for updating the topology state
accordingly, and commit 41724ea273cd ("drm/amd/display: Add DP 2.
The DP 2.0 errata changes DP_128B132B_TRAINING_AUX_RD_INTERVAL (DPCD
0x2216) completely. Add a new function to read that. Follow-up will need
to clean up existing functions.
v2: fix reversed interpretation of bit 7 meaning (Uma)
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
Try to avoid the timeout during debugging.
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i91
128b/132b updates to reflect DP 2.0 errata changes, plus some other DP
updates.
Jani Nikula (8):
drm/dp: add drm_dp_128b132b_read_aux_rd_interval()
drm/dp: add 128b/132b link status helpers from DP 2.0 E11
drm/dp: add some new DPCD macros from DP 2.0 E11
drm/i915/dp: move intel_dp_prepare_
Add some of the new additions from DP 2.0 E11.
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
include/drm/dp/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/dp/drm_dp_helper.h b/include/drm/dp/drm_dp_helper.h
index c499d735b992..69487bd8ed56
Call it from the higher level function, as it will be shared between two
code paths.
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i9
Abstract link status check to a function that takes 128b/132b and 8b/10b
into account, and use it. Also dump link status on failures.
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 39 ++-
.../drm/i915/display/in
The DP 2.0 errata redefines link training. There are some new status
bits, and some of the old ones need to be checked independently. Add
helpers to do this.
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/dp/drm_dp.c| 63 ++
The DP 2.0 errata completely overhauls the 128b/132b link training, with
no provisions for backward compatibility with the original DP 2.0
specification.
The changes are too intrusive to consider reusing the same code for both
8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
On Mon, Jan 24, 2022 at 01:25:08PM +0100, Christian König wrote:
> 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 +++
> dri
On Mon, Jan 24, 2022 at 01:25:07PM +0100, Christian König wrote:
> 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 manage
On Tue, Jan 25, 2022 at 12:27:43PM +, Tvrtko Ursulin wrote:
>
> On 24/01/2022 15:01, Matthew Brost wrote:
> > Add request cancel trace point guarded by
> > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINT.
>
> Okay-ish I guess (There is pr_notice with the only real caller, but I
> suppose you want it for
Hi, Jitao:
Jitao Shi 於 2022年1月12日 週三 下午11:01寫道：
>
> DP Spec 1.4a 3.3 requires dp detect the hpd with debounce.
>
> Upstream implementations should implement HPD signal de-bouncing on
> an external connection. A period of 100ms should be used for
> detecting an HPD connect event (i.e., the event,
On Tue, Jan 25, 2022 at 03:27:31PM +, Tvrtko Ursulin wrote:
>
> On 24/01/2022 15:01, Matthew Brost wrote:
> > 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
Hi, AngeloGioacchino:
AngeloGioacchino Del Regno 於
2022年1月18日 週二 下午9:41寫道：
>
> Optimize mtk_drm_crtc_duplicate_state() by switching from kzalloc() to
> kmalloc(): the only variable of this struct that gets checked in other
> functions is `pending_config`, but if that's set to false, then all of
>
On Mon, Jan 24, 2022 at 01:25:06PM +0100, Christian König wrote:
> 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/dr
Hi, AngeloGioacchino:
AngeloGioacchino Del Regno 於
2022年1月18日 週二 下午9:38寫道：
>
> There is no need to zero out the newly allocated memory because we are
> duplicating all members of struct mtk_plane_state: switch to kmalloc
> to save some overhead.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: An
On Mon, Jan 24, 2022 at 01:25:04PM +0100, Christian König wrote:
> 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 ++
On Mon, Jan 24, 2022 at 01:25:03PM +0100, Christian König wrote:
> 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/amdgp
[+cc Maarten, Maxime, Thomas; beginning of thread:
https://lore.kernel.org/r/20220106000658.243509-1-helg...@kernel.org]
On Tue, Jan 25, 2022 at 10:51:15AM +0800, Huacai Chen wrote:
> Hi, Bjorn,
>
> Why this series still missing in 5.17-rc1? :(
1) It was posted late in the cycle (Jan 6, when the
Hi Thomas,
On 1/25/22 10:12, Thomas Zimmermann wrote:
> 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
On 24/01/2022 15:01, Matthew Brost wrote:
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 execlist
On Tue, Jan 25, 2022 at 03:29:28PM +0100, Maxime Ripard wrote:
> Even though we have the other drm_display_info fields reset, the DC
> modes are missing.
>
> This shouldn't be an issue since it's explicitly reset every time a new
> EDID is parsed.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by:
On Tue, 25 Jan 2022 10:32:51 +0100, Maxime Ripard wrote:
> Even though we have the other drm_display_info fields reset, the DC
> modes are missing.
>
> This shouldn't be an issue since it's explicitely reset every time a new
> EDID is parsed.
>
>
> [...]
Applied to drm/drm-misc (drm-misc-next).
Even though we have the other drm_display_info fields reset, the DC
modes are missing.
This shouldn't be an issue since it's explicitly reset every time a new
EDID is parsed.
Suggested-by: Ville Syrjälä
Signed-off-by: Maxime Ripard
Reviewed-by: Jani Nikula
Reviewed-by: Ville Syrjälä
Link:
ht
The HVS core clock isn't really obvious, so let's add a bunch more
comments and some logging for easier debugging.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/v
Now that the clock driver makes sure we never end up with a rate of 0,
the HDMI driver doesn't need to care anymore.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/
The core clock and M2MC clocks are shared between some devices (Unicam
controllers and the HVS, and the HDMI controllers, respectively) that
will have various, varying, requirements depending on their current work
load.
Since those loads can require a fairly high clock rate in extreme
conditions (
The M2MC clock provides the state machine clock for both HDMI
controllers.
However, if no HDMI monitor is plugged in at boot, its clock rate will
be left at 0 by the firmware and will make any register access end up in
a CPU stall, even though the clock was enabled.
We had some code in the HDMI c
In order to reset the range on a clock, we need to call
clk_set_rate_range with a minimum of 0 and a maximum of ULONG_MAX. Since
it's fairly inconvenient, let's introduce a clk_drop_range() function
that will do just this.
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/
We only export a bunch of firmware clocks, and some of them require
special treatment.
This has been do so far using some tests on the clock id in various
places, but this is fairly hard to extend and doesn't scale very well.
Since we'll need some more cases in the next patches, let's switch to a
The code in clk_set_rate_range() will, if the current rate is outside of
the new range, will force it to the minimum or maximum. This is
equivalent to using clamp, while being less readable. Let's switch to
using clamp instead.
Signed-off-by: Maxime Ripard
---
drivers/clk/clk.c | 6 +-
1 fil
When we change a clock minimum or maximum using clk_set_rate_range(),
clk_set_min_rate() or clk_set_max_rate(), the current code will only
trigger a new rate change if the rate is outside of the new boundaries.
However, a clock driver might want to always keep the clock rate to
one of its boundary
The current core while setting the min and max rate properly in the
clk_request structure will not make sure that the requested rate is
within these boundaries, leaving it to each and every driver to make
sure it is.
Add a clamp call to make sure it's always done, and add a few unit tests
to make
Hi,
This is a follow-up of the discussion here:
https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
and here:
https://lore.kernel.org/all/20210914093515.260031-1-max...@cerno.tech/
While the initial proposal implemented a new API to temporarily raise and lower
clock rates
Let's test various parts of the rate-related clock API with the kunit
testing framework.
Cc: kunit-...@googlegroups.com
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/.kunitconfig | 1 +
drivers/clk/Kconfig | 7 +
drivers/clk/Makefile | 1 +
drivers/clk/c
Hi,
Thanks for the fix.
On 25/01/2022 10:12, 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.
v2:
* use I/O memory if request_mem_region() fails
On Mon, Jan 24, 2022 at 04:24:37PM +, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler
>
> Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
>
> Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")
>
> Signed-off-by: Carsten Haitzler
Ac
On Tue, 25 Jan 2022, Jani Nikula wrote:
> On Sun, 23 Jan 2022, Yaroslav Bolyukin wrote:
>> Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data
>>
>> Definitions were already provided as type I, but not used
>>
>> Signed-off-by: Yaroslav Bolyukin
>
> Reviewed-by: Jani Nikula
1 - 100 of 150 matches
Mail list logo
