Hi
Am 24.01.22 um 23:16 schrieb Daniel Vetter:
Also add notes that for atomic drivers it's really somewhere else and
no longer in struct drm_crtc.
Maybe we should put a bigger warning here that this is confusing,
since the pixel format is a plane property, but the GAMMA_LUT property
is on the c
Hi Daniel,
Thanks for your patch!
On Mon, Jan 24, 2022 at 11:16 PM Daniel Vetter wrote:
> Also add notes that for atomic drivers it's really somewhere else and
> no longer in struct drm_crtc.
>
> Maybe we should put a bigger warning here that this is confusing,
> since the pixel format is a plan
Cc regressions
On Mon, Jan 24, 2022 at 10:04 PM Helge Deller wrote:
> This series reverts two patches which disabled scrolling acceleration in
> fbcon/fbdev. Those patches introduced a regression for fbdev-supported graphic
> cards because of the performance penalty by doing screen scrolling by s
Hi
Am 24.01.22 um 15:23 schrieb Jocelyn Falempe:
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
[Public]
Hey Lyude,
Sorry, just got chance to get back to this and BIG THANKS to elaborating in
such details!
Following are some of my comments : )
> -Original Message-
> From: Lyude Paul
> Sent: Wednesday, January 19, 2022 9:59 AM
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.or
On Tue, Jan 25, 2022 at 09:22:15AM +0100, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> Thanks for your patch!
>
> On Mon, Jan 24, 2022 at 11:16 PM Daniel Vetter wrote:
> > Also add notes that for atomic drivers it's really somewhere else and
> > no longer in struct drm_crtc.
> >
> > Maybe we shoul
On Mon, Jan 24, 2022 at 05:18:07PM -0500, Alex Deucher wrote:
> On Mon, Jan 24, 2022 at 5:16 PM Daniel Vetter wrote:
> >
> > Also add notes that for atomic drivers it's really somewhere else and
> > no longer in struct drm_crtc.
> >
> > Maybe we should put a bigger warning here that this is confus
On Tue, Jan 25, 2022 at 09:35:54AM +0100, Daniel Vetter wrote:
> On Tue, Jan 25, 2022 at 09:22:15AM +0100, Geert Uytterhoeven wrote:
> > Hi Daniel,
> >
> > Thanks for your patch!
> >
> > On Mon, Jan 24, 2022 at 11:16 PM Daniel Vetter
> > wrote:
> > > Also add notes that for atomic drivers it's
Hi Marek,
On Mon, Jan 24, 2022 at 02:52:46PM +0100, Marek Szyprowski wrote:
> 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
> pat
On Sun, Jan 23, 2022 at 06:52:01PM +0100, Uwe Kleine-König wrote:
> 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 va
Hey!
Truly, idk if this is the right sort of place to ask, but it seems to
be the most appropriate (I was redirected here from the dead
dri-...@lists.freedesktop.org mailing list). Feel free to point me
somewhere else if this isn't where I should be asking this question!
I'm working on an X11 com
When the DSI is in video mode, all commands are rejected.
Detect current DSI mode in mtk_dsi_host_transfer() and switch modes
temporarily to allow commands to be sent.
Signed-off-by: Julien STEPHAN
Signed-off-by: Mattijs Korpershoek
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 34 +
On Tue, Jan 25, 2022 at 09:39:23AM +0100, Daniel Vetter wrote:
> On Tue, Jan 25, 2022 at 09:35:54AM +0100, Daniel Vetter wrote:
> > On Tue, Jan 25, 2022 at 09:22:15AM +0100, Geert Uytterhoeven wrote:
> > > Hi Daniel,
> > >
> > > Thanks for your patch!
> > >
> > > On Mon, Jan 24, 2022 at 11:16 PM
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #58 from Andrew Ammerlaan (andrewammerl...@gentoo.org) ---
> Jan 24 16:33:05 [kernel] [2.785931] amdgpu :28:00.0: amdgpu: RAS:
> optional ras ta ucode is not available
> Jan 24 16:33:05 [kernel] [2.790137] amdgpu :28:00
Misc fixes and refactoring in HDMI2.1 PCON helper functions.
Ankit Nautiyal (3):
drm/i915_hdmi: Fix the definition of intel_hdmi_dsc_get_bpp
drm/drm_edid: Add helper to get max FRL rate for an HDMI sink
drm/i915/display: Simplify helpers for getting DSC slices and bpp
drivers/gpu/drm/drm_e
Fix the data-type of the argument output_format to enum, for the
function intel_hdmi_dsc_get_bpp.
Fixes: 6e6cb758e035 ("drm/i915: Add helper functions for calculating DSC
parameters for HDMI2.1")
Cc: Ankit Nautiyal
Cc: Uma Shankar
Cc: Jani Nikula
Cc: "Ville Syrj_l_"
Cc: "Jos_ Roberto de Souza
Move the common function for getting the max FRL rate for an HDMI sink,
from intel_dp.c to drm/drm_edid.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 38 +
drivers/gpu/drm/i915/display/intel_dp.c | 19 -
include/drm/drm_edid.h
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 (Jocelyn)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez
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
---
Documentation/gpu/todo.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Docume
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
Genralize the helper for getting DSC slice count and compressed bpp
for HDMI sink supporting DSC.
This patch:
-Removes the assumption on the bpc and sends it as an argument for
calculating compressed bpc.
-Sends the resolution, and output format as parameters for which the
DSC paremeters are to be
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
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 [
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:
* store memory region in struct for later cleanup (Javier)
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/si
This v2 of the patchset. I forgot to adapt the subject line :/
Am 25.01.22 um 10:12 schrieb Thomas Zimmermann:
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
On Thu, 20 Jan 2022 16:16:11 +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 mode, R
On Thu, 20 Jan 2022 16:16:13 +0100, Maxime Ripard wrote:
> The HDMI specification mentions YCbCr everywhere, but our enums have
> YCrCb. Let's rename it to match.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 20 Jan 2022 16:16:10 +0100, Maxime Ripard wrote:
> The drm_hdmi_avi_infoframe_colorspace() function actually sets the
> colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe
> structure with DRM_MODE_COLORIMETRY_* values.
>
> To make things worse, the hdmi_avi_infoframe str
On Thu, 20 Jan 2022 16:16:14 +0100, Maxime Ripard wrote:
> We're going to need to tell whether we want to run with a full or
> limited range RGB output in multiple places in the code, so let's create
> a helper that will return whether we need with full range or not.
>
>
Applied to drm/drm-misc
On Thu, 20 Jan 2022 16:16:18 +0100, Maxime Ripard wrote:
> The current CSC setup code for the BCM2711 uses a sequence of register
> writes to configure the CSC depending on whether we output using a full
> or limited range.
>
> However, with the upcoming introduction of the YUV output, we're going
On Thu, 20 Jan 2022 16:16:12 +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 YCBCR 4:4
On Thu, 20 Jan 2022 16:16:16 +0100, Maxime Ripard wrote:
> On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration
> depends on whether we're using an RGB or YUV output. Let's move that
> configuration to the CSC setup.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 20 Jan 2022 16:16:19 +0100, Maxime Ripard wrote:
> In order to support the YUV output, we'll need the atomic state to know
> what is the state of the associated property in the CSC setup callback.
>
> Let's change the prototype of that callback to allow us to access it.
>
>
Applied to d
On Thu, 20 Jan 2022 16:16:17 +0100, Maxime Ripard wrote:
> On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
> opaque value. Let's replace it with properly defined values.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 20 Jan 2022 16:16:15 +0100, Maxime Ripard wrote:
> The CSC callbacks takes a boolean as an argument to tell whether we're
> using the full range or limited range RGB.
>
> However, with the upcoming YUV support, the logic will be a bit more
> complex. In order to address this, let's make th
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 cpumask as soon as it finds
first set bit, while cpumask_weight() co
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.
Suggested-by: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 ins
Hello Thomas,
On 1/25/22 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:
> * store memory region in struct for later cleanup (Ja
On Tue, 25 Jan 2022, Ankit Nautiyal wrote:
> Fix the data-type of the argument output_format to enum, for the
> function intel_hdmi_dsc_get_bpp.
The subject prefix should be "drm/i915/hdmi:".
>
> Fixes: 6e6cb758e035 ("drm/i915: Add helper functions for calculating DSC
> parameters for HDMI2.1")
On Tue, Jan 25, 2022 at 10:52:18AM +0200, Ville Syrjälä wrote:
> On Tue, Jan 25, 2022 at 09:39:23AM +0100, Daniel Vetter wrote:
> > On Tue, Jan 25, 2022 at 09:35:54AM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 25, 2022 at 09:22:15AM +0100, Geert Uytterhoeven wrote:
> > > > Hi Daniel,
> > > >
>
On Tue, 25 Jan 2022, Ankit Nautiyal wrote:
> Move the common function for getting the max FRL rate for an HDMI sink,
> from intel_dp.c to drm/drm_edid.
The subject prefix should be "drm/edid:"
But I'm not sure these functions belong in drm_edid.c though. If you see
a function prefixed drm_hdmi_,
On Tue, Jan 25, 2022 at 10:32:51AM +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.
It's not really obvious that it can't be an issu
On Tue, 25 Jan 2022, 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.
Side note, and hijacking the thread a bit: I think it's a historical
On 21/01/2022 11:50, Tvrtko Ursulin wrote:
On 20/01/2022 16:44, Rob Clark wrote:
[snip]
If there is a tool somewhere that displays this info, that would be
useful for testing my implementation.
I have a patch to Intel specific intel_gpu_top (see
https://patchwork.freedesktop.org/patch/46
Wow, nice.
Certainly +1 from my side to have that generalized, documented and
uniform among all drivers.
Regards,
Christian.
Am 25.01.22 um 11:24 schrieb Tvrtko Ursulin:
On 21/01/2022 11:50, Tvrtko Ursulin wrote:
On 20/01/2022 16:44, Rob Clark wrote:
[snip]
If there is a tool somewhere
On Sat, 22 Jan 2022 at 00:14, Matthew Brost wrote:
>
> Using more guc_ids in the stealing guc id test has no real benefit.
> Tearing down lots of contexts all at the same time takes a bit of time
> due to the H2G / G2H ping-pong with the GuC. On some slower platforms
> this can cause timeous when
Ensure we drop the reference to the last rq, otherwise we are leaking
the context etc. Also don't zero the previous valid context.
Signed-off-by: Matthew Auld
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/d
On 1/25/2022 3:15 PM, Jani Nikula wrote:
On Tue, 25 Jan 2022, Ankit Nautiyal wrote:
Fix the data-type of the argument output_format to enum, for the
function intel_hdmi_dsc_get_bpp.
The subject prefix should be "drm/i915/hdmi:".
Thanks for pointing it out. Will fix this.
Fixes: 6e6cb758e
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 selftests? Oh yes, why is missing from the
commit message.), but I'd emit i
On 1/25/2022 3:22 PM, Jani Nikula wrote:
On Tue, 25 Jan 2022, Ankit Nautiyal wrote:
Move the common function for getting the max FRL rate for an HDMI sink,
from intel_dp.c to drm/drm_edid.
The subject prefix should be "drm/edid:"
But I'm not sure these functions belong in drm_edid.c though.
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
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
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
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
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
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 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
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
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/
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
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 (
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 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
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
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).
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 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
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
[+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
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
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 ++
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: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: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 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, 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 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
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 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
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
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 ++
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
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
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
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_
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
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
---
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.
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
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 +--
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 +++
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
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
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
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
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
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
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
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
1 - 100 of 150 matches
Mail list logo
