Hi David and Laurent,
Gentle Ping.
Are you happy with this series?
Cheers,
Biju
> Subject: RE: [PATCH v3 0/2] Add RZ/G2L DSI driver
>
> Hi All,
>
> Gentle ping.
>
> Are you ok with this patch series? Please let me know.
>
> Cheers,
> Biju
>
> > Subject: [PATCH v3 0/2] Add RZ/G2L DSI drive
Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
>
> On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu wrote:
> > Andy Shevchenko 於 2022年7月5日 週二 清晨5:14寫道：
> > > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu wrote:
>
> Please, remove unneeded context when replying!
>
> ...
>
> > > > + brightness_val[
Hi Dave, Daniel,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2022-07-14:
Only a revert for amdgpu reverting the switch to the drm buddy
allocator.
The following changes since commit b68277f19e31a25312c4acccadb5cf1502e52e84:
drm/ssd130x: Fix pre-charge period setting (2022-07-07 1
Hi Liang,
Thanks for the patch.
The patch is ok but, since you're at it, maybe add of_node_put() in the
dcss_dev_destroy() too?
Thanks,
laurentiu
On Thu, Jul 07, 2022 at 10:32:14AM +0800, Liang He wrote:
> In dcss_dev_create(), we should call of_node_put() in fail path for
> of_graph_get_port_b
On Wed, 13 Jul 2022 13:35:56 +
Zack Rusin wrote:
> On Wed, 2022-07-13 at 10:20 +0300, Pekka Paalanen wrote:
> > On Wed, 13 Jul 2022 03:35:57 +
> > Zack Rusin wrote:
> >
> > > On Tue, 2022-07-12 at 10:56 +0300, Pekka Paalanen wrote:
> > > > On Mon, 11 Jul 2022 23:32:43 -0400
> > > >
At 2022-07-14 15:37:41, "Laurentiu Palcu" wrote:
>Hi Liang,
>
>Thanks for the patch.
>
>The patch is ok but, since you're at it, maybe add of_node_put() in the
>dcss_dev_destroy() too?
>
Thanks, laurentiu,
I miss it and I will add it soon.
>Thanks,
>laurentiu
>
>On Thu, Jul 07, 2022 at 10:3
In dcss_dev_create() and dcss_dev_destroy(), we should call of_node_put()
in fail path or before the dcss's destroy as of_graph_get_port_by_id() has
increased the refcount.
Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ")
Signed-off-by: Liang He
---
changelog:
v2: add o
Hi Sam,
Acked-by: Thomas Zimmermann
for the new changes.
Best regards
Thomas
Am 13.07.22 um 19:01 schrieb Sam Ravnborg:
We have an upcoming openchrome driver for VIA where some
of the files conflicts with the existing via driver.
It is not acceptable to just delete the existing DRI1
based d
Hi,
the email goes out a bit late, as -rc6 has already been tagged for a few
days. This means that drm-misc-next-fixes is now open for bug fixes, as
drm-next is in feature freeze until the next -rc1 comes out.
Some rules of thumb:
* if your patch fixes a bug in upstream, please put it into
Hi Christian
Am 12.07.22 um 12:28 schrieb Christian König:
This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
I only found this commit in drm-misc-next. Should the revert be
cherry-picked into drm-misc-next-fixes?
Best regards
Thomas
It turned out that this is not correct. Esp
Hi Maxime,
On Wed, Jul 13, 2022 at 11:37 AM Maxime Ripard wrote:
> On Mon, Jul 11, 2022 at 02:08:06PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jul 11, 2022 at 2:02 PM Maxime Ripard wrote:
> > > On Mon, Jul 11, 2022 at 01:59:28PM +0200, Geert Uytterhoeven wrote:
> > > > On Mon, Jul 11, 2022 a
Hi
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This commit is only present in drm-misc-next. Should the revert be
cherry-picked into drm-misc-next-fixes?
Best regards
Thomas
This is part of a revert of the following
Hi
Am 08.07.22 um 12:21 schrieb Arunpravin Paneer Selvam:
This reverts the following commits:
commit 708d19d9f362 ("drm/amdgpu: move internal vram_mgr function into the C
file")
commit 5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
commit c9cad937c0c5 ("drm/amdgpu: ad
Hi Thomas,
Am 14.07.22 um 10:40 schrieb Thomas Zimmermann:
Hi Christian
Am 12.07.22 um 12:28 schrieb Christian König:
This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
I only found this commit in drm-misc-next. Should the revert be
cherry-picked into drm-misc-next-fixes?
yes f
On Wed, 13 Jul 2022 18:00:59 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 05:54:44PM -0400, Rodrigo Vivi wrote:
> > On Wed, Jul 13, 2022 at 09:11:49AM +0100, Mauro Carvalho Chehab wrote:
> > > From: Jiapeng Chong
> > >
> > > Fix the following W=1 kernel warnings:
> > >
> > > drivers/g
Hi
Am 14.07.22 um 10:49 schrieb Christian König:
Hi Thomas,
Am 14.07.22 um 10:40 schrieb Thomas Zimmermann:
Hi Christian
Am 12.07.22 um 12:28 schrieb Christian König:
This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
I only found this commit in drm-misc-next. Should the revert
This patch series fixes integer overflow or integer truncation issues in
page lookups, ttm place configuration and scatterlist creation, etc.
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain integer
instead o
It moves overflows_type utility macro into drm util header from i915_utils
header. The overflows_type can be used to catch the truncation between data
types. And it adds safe_conversion() macro which performs a type conversion
(cast) of an source value into a new variable, checking that the
destina
From: Chris Wilson
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
A
From: Chris Wilson
There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the o
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big
to add vma. The direct function that returns -ENOSPC is
drm_mm_insert_node_in_range().
To handle the same error as other code returning -E2BIG when the size is
too large, it converts return value to -E2BIG.
Signed-off-by:
The __shmem_file_setup() function returns -EINVAL if size is greater than
MAX_LFS_FILESIZE. To handle the same error as other code that returns
-E2BIG when the size is too large, it add a code that returns -E2BIG when
the size is larger than the size that can be handled.
Signed-off-by: Gwan-gyeong
From: Chris Wilson
Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warnin
Hi,
This is a follow-up of the work to support the interactions between the hotplug
and the scrambling support for vc4:
https://lore.kernel.org/dri-devel/20210507150515.257424-11-max...@cerno.tech/
https://lore.kernel.org/dri-devel/20211025152903.1088803-10-max...@cerno.tech/
https://lore.kernel.
We don't modify the drm_display_mode pointer we have in the driver in
most places, so let's make them const.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 16
drivers/gpu/drm/vc4/vc4_hdmi.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git
Even though vc4_hdmi_supports_scrambling takes a mode as an argument, it
never uses it. Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/v
We recently introduced a new mutex to protect concurrent execution of
ALSA and KMS hooks, and the concurrent access to some of vc4_hdmi
fields.
However, using it in the detect hook was creating a reentrency issue
with CEC code. Indeed, calling cec_s_phys_addr_from_edid from detect
might call the C
Our detect callback has a bunch of operations to perform depending on
the current and last status of the connector, such a setting the CEC
physical address or enabling the scrambling again.
This is currently dealt with a bunch of if / else statetements that make
it fairly difficult to read and ext
Am 14.07.22 um 11:06 schrieb Thomas Zimmermann:
Hi
Am 14.07.22 um 10:49 schrieb Christian König:
Hi Thomas,
Am 14.07.22 um 10:40 schrieb Thomas Zimmermann:
Hi Christian
Am 12.07.22 um 12:28 schrieb Christian König:
This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
I only found
We'll need it earlier in the driver, so let's move it next to the other
scrambling-related helpers.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdm
We'll need the locking context in future patch, so let's convert .detect
to .detect_ctx.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
inde
During a hotplug cycle (such as a TV going out of suspend, or when the
cable is disconnected and reconnected), the expectation is that the same
state used before the disconnection is reused until the next commit.
However, the HDMI scrambling requires that some flags are set in the
monitor, and tho
There's some interactions between the SCDC setup and the disconnection /
reconnection of displays. Let's document it and a solution.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_scdc_helper.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/displ
On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
> > On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu wrote:
> > > Andy Shevchenko 於 2022年7月5日 週二 清晨5:14寫道：
> > > > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu wrote:
Please, once again, remove unneeded context
On 10/07/2022 10:41, Dmitry Baryshkov wrote:
> The commit fa384dd8b9b8 ("drm/msm/dp: delete vdda regulator related
> functions from eDP/DP controller") removed support for VDDA supplies
No such commit exists in next. Do not reference unpublished commits. If
this is your tree, be sure that it is in
Send DPCD DP_SET_POWER_D0 command to the monitor in .atomic_enable
callback. Without this command, some monitors won't show up again after
changing the resolution.
Fixes: 46ca7da7f1e8 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream")
Signed-off-by: Pin-Yen Lin
---
Changes in v2:
- Updat
On 10/07/2022 10:41, Dmitry Baryshkov wrote:
> Document missing definitions for opp-table (DP controller OPPs), aux-bus
> (DP AUX BUS) and data-lanes (DP/eDP lanes mapping) properties.
>
> Reviewed-by: Stephen Boyd
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/dp-controller
On Thu, Jul 14, 2022 at 11:27 AM Andy Shevchenko
wrote:
>
> On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
...
> > I have tried two methods so far, as follows
> > -
> > /*
> > * prop_va
On Thu, Jul 14, 2022 at 11:27:07AM +0200, Andy Shevchenko wrote:
> On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > I have tried two methods so far, as follows
> > -
> > /*
> > * prop_val = 1 --> 1 steps --> b'00
> > * prop_v
On Thu, Jul 14, 2022 at 11:47 AM Daniel Thompson
wrote:
>
> On Thu, Jul 14, 2022 at 11:27:07AM +0200, Andy Shevchenko wrote:
> > On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > > I have tried two methods so far, as follows
> > > -
>
Hi
Am 14.07.22 um 11:13 schrieb Christian König:
Am 14.07.22 um 11:06 schrieb Thomas Zimmermann:
Hi
Am 14.07.22 um 10:49 schrieb Christian König:
Hi Thomas,
Am 14.07.22 um 10:40 schrieb Thomas Zimmermann:
Hi Christian
Am 12.07.22 um 12:28 schrieb Christian König:
This reverts commit 8f619
On 14.07.2022 05:09, Murthy, Arun R wrote:
-Original Message-
From: Hajda, Andrzej
Sent: Wednesday, July 13, 2022 8:50 PM
To: Jani Nikula ; Ville Syrjälä
; Murthy, Arun R
Cc: Hajda, Andrzej ; Joonas Lahtinen
; Vivi, Rodrigo ;
Tvrtko Ursulin ; Daniel Vetter
; intel-...@lists.freedesktop.
On Wed, 13 Jul 2022 18:05:06 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:11:53AM +0100, Mauro Carvalho Chehab wrote:
> > There are a couple of issues at i915 display kernel-doc markups:
> >
> > drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning:
> > Function param
On 7/12/22 11:56, Dmitry Osipenko wrote:
> On 7/6/22 18:46, Alex Deucher wrote:
>> On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
>> wrote:
>>>
>>> On 2022-07-06 03:07, Dmitry Osipenko wrote:
>>>
Hello Andrey,
On 5/17/22 17:48, Dmitry Osipenko wrote:
> On 5/17/22 17:13, Andrey
On Wed, 13 Jul 2022 18:07:44 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:11:54AM +0100, Mauro Carvalho Chehab wrote:
> > There are several trivial warnings there, due to trivial things:
> > - lack of function name at the kerneldoc markup;
> > - undocumented structs with kernel-
User reported gpu page fault when running graphics applications
and in some cases garbaged graphics are observed as soon as X
starts. This patch fixes all the issues.
Fixed the typecast issue for fpfn and lpfn variables, thus
preventing the overflow problem which resolves the memory
corruption.
S
On 14/07/2022 12:38, Krzysztof Kozlowski wrote:
On 10/07/2022 10:41, Dmitry Baryshkov wrote:
The commit fa384dd8b9b8 ("drm/msm/dp: delete vdda regulator related
functions from eDP/DP controller") removed support for VDDA supplies
No such commit exists in next. Do not reference unpublished comm
On Thu, Jul 14, 2022 at 11:43 AM Andy Shevchenko
wrote:
> On Thu, Jul 14, 2022 at 11:27 AM Andy Shevchenko
> wrote:
> > On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > > Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
...
> > > * prop_val = 1 --> 1 steps --> b'00
> > > * prop_val = 2
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #81 from Danil (s48g...@gmail.com) ---
Nvidia released 515.57 drivers that fix "Nvidia being broken when used as
second GPU in Linux", my bug above.
Nvidia GPU works again when AMD GPU main.
--
You may reply to this email to add a co
On 30/06/2022 01:53, Marijn Suijten wrote:
parent_hw pointers are easier to manage and cheaper to use than
repeatedly formatting the parent name and subsequently leaving the clk
framework to perform lookups based on that name.
This series starts out by adding extra constructors for divider, mux
It is fairly common for named video modes to contain dashes (e.g.
"tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names
are not recognized, as the dash is considered to be a separator between
mode name and bpp.
Fix this by skipping any dashes that are not followed immediately by a
The mode parsing code recognizes named modes only if they are explicitly
listed in the internal whitelist, which is currently limited to "NTSC"
and "PAL".
Provide a mechanism for drivers to override this list to support custom
mode names.
Ideally, this list should just come from the driver's actu
When a idle BO, which is held open by another process, gets freed by
userspace and subsequently referenced again by e.g. importing it again,
userspace may assign a different softpin VA than the last time around.
As the kernel GEM object still exists, we likely have a idle mapping
with the old VA st
The same logic is already used in two different places and now
it will also be needed outside of the compilation unit, so split
it into a separate function.
Cc: sta...@vger.kernel.org # 5.19
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 23 +++
driver
There is a spelling mistake in a dml_print message. Fix it.
Signed-off-by: Colin Ian King
---
.../gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
b/dr
On 14/07/2022 12:15, Dmitry Baryshkov wrote:
> On 14/07/2022 12:38, Krzysztof Kozlowski wrote:
>> On 10/07/2022 10:41, Dmitry Baryshkov wrote:
>>> The commit fa384dd8b9b8 ("drm/msm/dp: delete vdda regulator related
>>> functions from eDP/DP controller") removed support for VDDA supplies
>>
>> No su
Extract the code to check for a named mode parameter into its own
function, to streamline the main parsing flow.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Hans de Goede
Acked-by: Thomas Zimmermann
---
v2:
- Add Reviewed-by, Acked-by,
- Fix length check.
---
drivers/gpu/drm/drm_modes.c
The various mode->*specified flags are not handled in an uniform way:
some flags are set by the corresponding drm_mode_parse_cmdline_*()
function, some flags by the caller of the function, and some flags by
both.
Make this uniform by making this the responsibility of the various
parsing helpers, i
We already discussed that the call to drm_sched_entity_select_rq() needs
to move to drm_sched_job_arm() to be able to set a new scheduler list
between _init() and _arm(). This was just not applied for some reason.
Signed-off-by: Christian König
CC: Andrey Grodzovsky
CC: dri-devel@lists.freedeskt
If no mode name part was specified, mode_end is zero, and the "ret ==
mode_end" check does the wrong thing.
Fix this by skipping all named mode handling when mode_end is zero.
Fixes: 7b1cce760afe38b4 ("drm/modes: parse_cmdline: Allow specifying
stand-alone options")
Signed-off-by: Geert Uytterho
Hi all,
This patch series contains fixes and improvements for specifying video
modes on the kernel command line.
Changes compared to v1[1]:
- Add Reviewed-by, Acked-by,
- Keep length check.
This has been tested on ARAnyM using a work-in-progress Atari DRM driver
(more info and relate
Reviewed-by: Allen Chen
-Original Message-
From: Pin-Yen Lin
Sent: Thursday, July 14, 2022 5:39 PM
To: Andrzej Hajda ; Neil Armstrong
; Robert Foss ; Laurent
Pinchart ; Jonas Karlman ;
Jernej Skrabec ; David Airlie ;
Daniel Vetter
Cc: Hsin-Yi Wang ; Allen Chen (陳柏宇)
; Pin-Yen Lin
Il 12/07/22 13:12, Bo-Chen Chen ha scritto:
From: Guillaume Ranquet
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Sign
On Thu, 14 Jul 2022 12:08:01 +0300
Gwan-gyeong Mun wrote:
> It moves overflows_type utility macro into drm util header from i915_utils
> header. The overflows_type can be used to catch the truncation between data
> types. And it adds safe_conversion() macro which performs a type conversion
> (cas
Am 13.07.22 um 17:47 schrieb Lucas De Marchi:
On Tue, Apr 26, 2022 at 10:21:43PM +0530, Balasubramani Vivekanandan
wrote:
Fast copy using non-temporal instructions for x86 currently exists at
two
locations. One is implemented in i915 driver at i915/i915_memcpy.c and
another copy at drm_cache.c.
On Thu, 14 Jul 2022 12:08:02 +0300
Gwan-gyeong Mun wrote:
> From: Chris Wilson
>
> We need to check that we avoid integer overflows when looking up a page,
> and so fix all the instances where we have mistakenly used a plain
> integer instead of a more suitable long. Be pedantic and add integer
Il 12/07/22 13:12, Bo-Chen Chen ha scritto:
From: Markus Schneider-Pargmann
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp()
On Thu, 14 Jul 2022 12:08:04 +0300
Gwan-gyeong Mun wrote:
> There is an impedance mismatch between the first/last valid page
> frame number of ttm place in unsigned and our memory/page accounting in
> unsigned long.
> As the object size is under the control of userspace, we have to be prudent
> a
Going forward, I'll be using my kernel.org for upstream work.
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Rob Herring
Cc: Krzysztof Kozlowski
Cc: dri-devel@lists.freedesktop.org
Cc: linux-l...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Lee Jones
Signed-off-by: Lee Jones
---
Do
https://bugzilla.kernel.org/show_bug.cgi?id=216120
--- Comment #4 from mat2003...@gmail.com ---
this patch:
https://gitlab.freedesktop.org/drm/amd/uploads/564b2cc2b5ea87357f39e45c3a1a44e2/0001-drm-amdgpu-Fix-for-drm-buddy-memory-corruption.patch
on top of 5.19.0-rc6 seems to fix the problem
tes
Il 12/07/22 13:12, Bo-Chen Chen ha scritto:
From: Guillaume Ranquet
This patch adds audio support to the DP driver for MT8195 with up to 8
channels.
Signed-off-by: Guillaume Ranquet
Signed-off-by: Bo-Chen Chen
---
drivers/gpu/drm/mediatek/mtk_dp.c | 723 ++
dri
Hi,
On Thu, Jul 14, 2022 at 11:04:06AM +0200, Geert Uytterhoeven wrote:
> If no mode name part was specified, mode_end is zero, and the "ret ==
> mode_end" check does the wrong thing.
>
> Fix this by skipping all named mode handling when mode_end is zero.
>
> Fixes: 7b1cce760afe38b4 ("drm/modes:
On Thu, Jul 14, 2022 at 11:04:07AM +0200, Geert Uytterhoeven wrote:
> Extract the code to check for a named mode parameter into its own
> function, to streamline the main parsing flow.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Hans de Goede
> Acked-by: Thomas Zimmermann
Acked-by: Ma
On Thu, Jul 14, 2022 at 11:04:08AM +0200, Geert Uytterhoeven wrote:
> The various mode->*specified flags are not handled in an uniform way:
> some flags are set by the corresponding drm_mode_parse_cmdline_*()
> function, some flags by the caller of the function, and some flags by
> both.
>
> Make
On Thu, Jul 14, 2022 at 11:04:10AM +0200, Geert Uytterhoeven wrote:
> It is fairly common for named video modes to contain dashes (e.g.
> "tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names
> are not recognized, as the dash is considered to be a separator between
> mode name and b
TLB cache invalidation can happen on two different situations:
1. synchronously, at __vma_put_pages();
2. asynchronously.
On the first case, TLB cache invalidation happens inside
__vma_put_pages(). So, no need to do it later on.
However, on the second case, the pages will keep in memory
until __
From: Chris Wilson
Skip all further TLB invalidations once the device is wedged and
had been reset, as, on such cases, it can no longer process instructions
on the GPU and the user no longer has access to the TLB's in each engine.
That helps to reduce the performance regression introduced by TLB
From: Piotr Piórkowski
Add a new way to invalidate TLB via GuC using actions 0x7002
(TLB_INVALIDATION_ALL).
Those actions will be used on upcoming patches.
Signed-off-by: Piotr Piórkowski
Cc: Michal Wajdeczko
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of
Add documentation for the kAPI functions that do TLB cache
invalidation via GuC.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche..
Transform the comments for intel_guc_tlb_inval_mode into a
kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@k
Add a description for intel_guc_tlb_invalidation_type enum.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
drive
From: Prathap Kumar Valsan
Add routines to interface with GuC firmware for selective TLB invalidation
supported on XeHP.
Signed-off-by: Prathap Kumar Valsan
Cc: Matthew Brost
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/
From: Prathap Kumar Valsan
Add an interface for GuC TLB actions, supporting both selective and
full TLB invalidations. After this change, when GuC is enabled,
tlb invalidations use GuC ct. Otherwise, use mmio interface.
Signed-off-by: Prathap Kumar Valsan
Cc: Niranjana Vishwanathapura
Cc: Fei
From: Chris Wilson
Ensure that the TLB of the OA unit is also invalidated
on gen12 HW, as just invalidating the TLB of an engine is not
enough.
Cc: sta...@vger.kernel.org
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Signed-off-by: Chris Wilson
Cc: Fei Yang
Cc: An
From: Chris Wilson
With multi-GT devices, the object may have been bound on each GT.
Invalidate the TLBs across all GT before releasing the pages
back to the system.
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of pe
From: Chris Wilson
Invalidate TLB in patch, in order to reduce performance regressions.
Currently, every caller performs a full barrier around a TLB
invalidation, ignoring all other invalidations that may have already
removed their PTEs from the cache. As this is a synchronous operation
and can
TLB invalidation is a slow operation. It should not be doing lightly, as it
causes performance regressions, like this:
[178.821002] i915 :00:02.0: [drm] *ERROR* rcs0 TLB invalidation did not
complete in 4ms!
This series contain
1) some patches that makes TLB invalidation to happen only on
From: Chris Wilson
Don't flush TLBs when the buffer is only used in the GGTT under full
control of the kernel, as there's no risk of concurrent access
and stale access from prefetch.
We only need to invalidate the TLB if they are accessible by the user.
That helps to reduce the performance regre
Add documentation for the 3 new members of struct intel_guc
that are used to handle TLB cache invalidation logic.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.or
From: Prathap Kumar Valsan
Add routines to interface with GuC firmware for TLB invalidation.
Signed-off-by: Prathap Kumar Valsan
Cc: Bruce Chang
Cc: Michal Wajdeczko
Cc: Matthew Brost
Cc: Chris Wilson
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of peopl
From: Prathap Kumar Valsan
For platforms supporting selective tlb invalidations, we don't need to
do a full tlb invalidation. Rather do a range based tlb invalidation for
every unbind of purged vma belongs to an active vm.
[mchehab: change moved from intel_ppgtt.c to i915_vma.c]
Signed-off-by: P
Add a kernel-doc markup to document this new macro.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
drivers/gpu/d
Add documentation to the TLB field inside
struct drm_i915_gem_object.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.or
From: Prathap Kumar Valsan
Add support for selective TLB invalidation, which is a platform
feature supported on XeHP.
Signed-off-by: Prathap Kumar Valsan
Cc: Niranjana Vishwanathapura
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing list
From: Chris Wilson
Check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already invalidated, so an
explicit TLB invalidation is not needed, thus reducing the
performance regression impact due to it.
This becomes more significant with GuC, as it c
Add a description for the kAPI functions inside intel_tlb.c.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v2 00/21] at:
https://lore.kernel.org/all/cover.1657800199.git.mche...@kernel.org/
driv
From: Chris Wilson
Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.
Signed-off-by: Chris Wilson
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
On Thu, Jul 14, 2022 at 11:04:09AM +0200, Geert Uytterhoeven wrote:
> The mode parsing code recognizes named modes only if they are explicitly
> listed in the internal whitelist, which is currently limited to "NTSC"
> and "PAL".
>
> Provide a mechanism for drivers to override this list to support
On 2022-07-11 11:13, Liviu Dudau wrote:
[...]
But nothing worrying. It does work, though doesn't compile due to:
drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function
‘komeda_kms_atomic_commit_hw_done’:
drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: error: ‘for’ loop
initial declar
1 - 100 of 173 matches
Mail list logo
