Le 13/01/2022 à 08:31, Hsin-Yi Wang a écrit :
Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory
handled by driver detach.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +++--
1 file changed, 3 insertions(+), 6 deleti
Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory
handled by driver detach.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
v2->v3: remove kfree() in anx7625_i2c_remove().
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 10 +++---
1 file changed, 3 insertions(+), 7 de
Support reading edid through aux channel if panel is connected to aux
bus. Extend anx7625_aux_dpcd_trans() to implement aux transfer function:
1. panel is populated in devm_of_dp_aux_populate_ep_devices(), so move
anx7625_parse_dt() after.
2. Use pm runtime autosuspend since aux transfer functi
List panel under aux-bus node if it's connected to anx7625's aux bus.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
.../display/bridge/analogix,anx7625.yaml| 17 +
1 file changed, 17 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/anal
Hi Dave and Daniel,
here's this week's PR for drm-misc-next-fixes.
Best regards
Thomas
drm-misc-next-fixes-2022-01-13:
* Fix use of CRTC state's active vs enable in atomic helper
The following changes since commit 5da8b49de472c1da8658466d4f63ef8d9251a819:
dt-bindings: display: bridge: lvds-c
On Thu, Jan 13, 2022 at 4:04 PM Christophe JAILLET
wrote:
>
> Le 13/01/2022 à 08:31, Hsin-Yi Wang a écrit :
> > Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory
> > handled by driver detach.
> >
> > Signed-off-by: Hsin-Yi Wang
> > Reviewed-by: Xin Ji
> > ---
> > drivers/gpu
The 1Netbook OneXPlayer uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Raymond Jay Golo
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.
Don't populate the read-only array flex_regs on the stack but
instead it static const. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King
---
RESEND: Use correct e-mail address for sign-off and From: in e-mail.
---
drivers/gpu/drm/i915/i915_perf.c | 2 +-
1 file change
The variable 'size' is being assigned a value that is never read,
the assignment is redundant and can be removed. Cleans up clang-scan
warning:
drivers/gpu/drm/vc4/vc4_bo.c:358:2: warning: Value stored to 'size'
is never read [deadcode.DeadStores]
size = roundup(size, PAGE_SIZE);
Signed-o
'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.
Remove the redundant 'flush_workqueue()' calls.
Signed-off-by: Xu Wang
---
drivers/video/backlight/lm3630a_bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backl
ping!
This patchset got lost. Patches 4 and 5 still need a review.
Am 01.12.21 um 12:46 schrieb Thomas Zimmermann:
Fix a number of compiler warnings in the AGP drivers. No functional
changes.
v2:
* ati-agp: free page in error branch (Helge)
* nvidia-agp: Mark temp as __maybe_un
On Wed, 12 Jan 2022, Colin Ian King wrote:
> Don't populate the read-only array flex_regs on the stack but
> instead it static const. Also makes the object code a little smaller.
>
> Signed-off-by: Colin Ian King
>
> ---
>
> RESEND: Use correct e-mail address for sign-off and From: in e-mail.
Th
Hi Dave and Daniel,
A few fixes for the merge window.
One dealing with runtime PM handling on the PXP unbind path and a few
regarding the newly added TTM backend support.
Regards,
Tvrtko
---
drm-intel-next-fixes-2022-01-13:
- Hold runtime PM wakelock during PXP unbind (Juston Li)
- Three fi
On 12/15/21 10:47 PM, Yannick Fertre wrote:
> Replace the legacy register access by regmap API.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/ltdc.c | 138 ++---
> drivers/gpu/drm/stm/ltdc.h | 1 +
> 2 files changed, 68 insertions(+), 71 deletio
Some drivers whose planes only support linear layout fb do not support format
modifiers.
These drivers should support modifiers, however the DRM core should handle this
rather than open-coding in every driver.
In this patch series, these drivers expose format modifiers based on the
following sugge
Set fb_modifiers_not_supported flag in legacy drivers whose planes
support non-linear layouts but does not support modifiers, and replace
allow_fb_modifiers with fb_modifiers_not_supported.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 +++---
drivers/gpu/drm/
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers. However, there are legacy drivers such as radeon that do not
support modifiers but infer the actual layout of the underlying buffer.
Therefore, a new flag not_support_fb_modifires is introduced for these
legacy driv
Since almost drivers support fb modifiers, allow_fb_modifiers is
replaced with fb_modifiers_not_supported and removed.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/drm_framebuffer.c| 6 +++---
drivers/gpu/drm/drm_ioctl.c | 2 +-
drivers/gpu/drm/drm_pla
On 12/01/2022 19:20, Alyssa Rosenzweig wrote:
>>> Now that we only list features of interest to kernel space, lots of GPUs
>>> have the same feature bits. To cut down on the repetition in the file,
>>> merge feature lists that are identical between similar GPUs.
>>>
>>> Note that this leaves some u
On 12/15/21 10:47 PM, Yannick Fertre wrote:
> LTDC 40100 hw version supports the YCbCr 422 output,
> reducing the output pins from 24 to 16. This feature
> is useful for some external devices like HDMI bridges.
>
> Both ITU-R BT.601 & ITU-R BT.709 are supported.
>
> It is also possible to choose
On 12/15/21 10:48 PM, Yannick Fertre wrote:
> Recent ltdc hardware versions offer the ability
> to update a plane independently of others planes.
> This is could be useful especially if a plane is
> assigned to another OS.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/stm/ltdc.c | 2
Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
Il 12/11/21 11:55, Yong Wu ha scritto:
After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use pm_runtime_disable instead.
meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
rename it
Hello,
Thanks for submitting this cleanup patch.
On Tue, 11 Jan 2022 at 04:41, lzmlzm wrote:
>
A commit message is necessary for all changes, no matter how trivial.
> Signed-off-by: lzmlzm
Is your name listed correctly above? For the 'Signed-off-by' tag to be
meaningful, a real name needs to
Il 13/01/22 11:15, Hans Verkuil ha scritto:
On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
Il 12/11/21 11:55, Yong Wu ha scritto:
After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use p
On 12/15/21 10:48 PM, Yannick Fertre wrote:
> This feature allows the generation of any RGB pixel format.
> The list of supported formats is no longer linked to the
> register LXPFCR_PF, that the reason why a list of drm formats is
> defined for each display controller version.
>
> Signed-off-by:
On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
> Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
>> Il 12/11/21 11:55, Yong Wu ha scritto:
>>> After this patchset, mtk_vcodec_release_enc_pm has only one line.
>>> then remove that function, use pm_runtime_disable instead.
>>>
>>> m
Hello Guangming,
On Wed, 5 Jan 2022 at 12:05, wrote:
>
> From: Guangming.Cao
>
> On Tue, 2022-01-04 at 08:47 +0100, Christian K鰊ig wrote:
> > Am 03.01.22 um 19:57 schrieb John Stultz:
> > > On Mon, Dec 27, 2021 at 1:52 AM wrote:
> > > > From: Guangming
> > > >
> > >
> > > Thanks for submitting
Hello Weizhao,
On Tue, 4 Jan 2022 at 13:13, John Stultz wrote:
>
> On Mon, Jan 3, 2022 at 11:36 PM Weizhao Ouyang wrote:
> >
> > Fix cma_heap_buffer mutex locking critical section to protect vmap_cnt
> > and vaddr.
> >
> > Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the
>
On 13/01/2022 10:01, Alexey Sheplyakov wrote:
> Hi, Steven!
>
> Thanks for such a detailed explanation of T628 peculiarities.
>
> On Wed, Jan 12, 2022 at 05:03:15PM +, Steven Price wrote:
>> On 10/01/2022 17:42, Alyssa Rosenzweig wrote:
Whether it's worth the effort depends on whether an
We want to remove more members of i915_vma, which requires the locking to be
held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to the
object may be held by th
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some objects' locks.
Previously, this was spread over sev
Because we will start to require the obj->resv lock for unbinding,
ensure these shrinker functions also take the lock.
This requires some function signature changes, to ensure that the
ww context is passed around, but is mostly straightforward.
Previously this was split up into several patches, b
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Changes since v1:
- Remove -ENOSPC warning, can still happen with concurrent mmaps
where we can't u
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 55 +--
Previously, short term pinning in execbuf was required because i915_vma was
effectively independent from objects, and has its own refcount, locking,
lifetime rules and pinning.
This series removes the separate locking, by requiring vma->obj->resv to be
held when pinning and unbinding. This will al
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
protected by the object lock.
This removes the need to unpin, which is done by just releasing the
lock.
eb_reserve is slightly reworked for readability, but the same steps
are still done:
- First pass pins with NONBLOCK.
- Second
From: Guangming
Add a size check for allocation since the allocation size is
always less than the total DRAM size.
Without this check, once the invalid size allocation runs on a process that
can't be killed by OOM flow(such as "gralloc" on Android devices), it will
cause a kernel exception, and
>-Original Message-
>From: dri-devel On Behalf Of
>guangming@mediatek.com
>Sent: Thursday, January 13, 2022 7:34 AM
>To: sumit.sem...@linaro.org
>Cc: linux-arm-ker...@lists.infradead.org; mingyuan...@mediatek.com;
>Guangming ;
>wsd_upstr...@mediatek.com; linux-ker...@vger.kernel.org;
>-Original Message-
>From: dri-devel On Behalf Of
>Ruhl, Michael J
>Sent: Thursday, January 13, 2022 7:58 AM
>To: guangming@mediatek.com; sumit.sem...@linaro.org
>Cc: jianjiao.z...@mediatek.com; lm...@codeaurora.org;
>wsd_upstr...@mediatek.com; christian.koe...@amd.com; linux-
>ker..
Am 13.01.22 um 14:00 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Ruhl, Michael J
Sent: Thursday, January 13, 2022 7:58 AM
To: guangming@mediatek.com; sumit.sem...@linaro.org
Cc: jianjiao.z...@mediatek.com; lm...@codeaurora.org;
wsd_upstr...@mediatek.com;
On 1/7/22 6:26 PM, José Expósito wrote:
Hi Simon,
On Wed, Jan 05, 2022 at 11:54:43PM +, Simon Ser wrote:
Pushed patches 1 & 2 to drm-misc-next. Thanks for your contribution!
Thanks a lot for the review and for applying the changes, appreciate it.
Is there something that needs to impro
On 12/15/21 10:46 PM, Yannick Fertre wrote:
Hello,
List of new feature:
* Replace the legacy register access by regmap API.
* Support of YCbCr 422 output
* Update layer shadow registers per plane.
* Support of YCbCr output (planar, semiplanar & coplanar)
These featues are available only with
On 1/13/22 12:44, Maarten Lankhorst wrote:
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Changes since v1:
- Remove -ENOSPC warning, can still
Series is:
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Yang Li
Sent: Thursday, January 13, 2022 3:12 PM
To: airl...@linux.ie; Chen, Guchun
Cc: dan...@ffwll.ch; Deucher, Alexander ; Koenig,
Christian ; Pan, Xinhui ;
amd-...@lists.freedesktop.org; dri-devel@lists
Hi Esaki-san,
On Thu, 13 Jan 2022 at 09:44, Tomohito Esaki wrote:
> Some drivers whose planes only support linear layout fb do not support format
> modifiers.
> These drivers should support modifiers, however the DRM core should handle
> this
> rather than open-coding in every driver.
>
> In thi
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 structure also has a
colorspace field used to signal whether an RGB or
Hi,
This is another attempt at supporting the HDMI YUV output in the vc4 HDMI
driver.
This is a follow-up of
https://lore.kernel.org/dri-devel/20210317154352.732095-1-max...@cerno.tech/
And the discussions that occured recently on the mailing lists and IRC about
this.
The series mentioned above
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, RGB 4:4:4 shall be supported and
optionally YCBCR 4:4:4 may be suppo
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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.
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:4 in Deep Color modes is
indicated with the DC_Y444 bit. If DC_
The HDMI specification mentions YCbCr everywhere, but our enums have
YCrCb. Let's rename it to match.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
.../drm/arm/display/komeda/d71/d71_component.c | 12 ++--
drivers/gpu/drm/bridge/adv7511/adv7511_
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 the callbacks take the
entire mode, and call our new helper to tell w
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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
1 file changed, 2 insertio
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
to add new matrices to perform the conversions, so we should switc
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an
opaque value. Let's replace it with properly defined values.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_regs.h | 3 +++
2 files changed, 5 ins
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.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4
Our code is doing the same clock rate validation in multiple instances.
Let's create a helper to share the rate validation.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu
The code to compute our clock rate for a given setup will be called in
multiple places in the next patches, so let's create a separate function
for it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 49 +++---
1 file changed, 34 insertions(+), 15 de
The current code only base its decision for whether the scrambler must be
enabled or not on the pixel clock of the mode, but doesn't take the bits
per color into account.
Let's leverage the new function to compute the clock rate in the
scrambler setup code.
Signed-off-by: Maxime Ripard
---
driv
In the function that validates that the clock isn't too high, we've only
taken our controller limitations into account so far.
However, the sink can have a limit on the maximum TMDS clock it can deal
with too which is exposed through the EDID and the drm_display_info.
Make sure we check it.
Sign
Currently we take the max_bpc property as the bpc value and do not try
anything else.
However, what the other drivers seem to be doing is that they would try
with the highest bpc allowed by the max_bpc property and the hardware
capabilities, test if it results in an acceptable configuration, and i
In addition to the RGB444 output, the BCM2711 HDMI controller supports
the YUV444 and YUV422 output formats.
Let's add support for them in the driver, but still use RGB as the
preferred format.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 289 ++
On 13.01.2022 00:26, Matthew Brost wrote:
> On Thu, Jan 13, 2022 at 12:21:17AM +0100, Michal Wajdeczko wrote:
>> On 11.01.2022 17:30, Matthew Brost wrote:
...
>>> @@ -1863,6 +1861,33 @@ static void guc_submit_request(struct i915_request
>>> *rq)
>>> spin_unlock_irqrestore(&sched_engine->l
On 1/13/22 12:44, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some object
> >>> Note that this leaves some unmerged identical Bifrost feature lists, as
> >>> there are more features affecting Bifrost kernel space that we do not
> >>> yet hanlde.
> >>
> >> NIT: s/hanlde/handle/ ;)
> >>
> >> Do you have any features in mind that we're missing? The list looks very
> >> simi
On 13-01-2022 15:33, Thomas Hellström (Intel) wrote:
>
> On 1/13/22 12:44, Maarten Lankhorst wrote:
>> i915_gem_evict_vm will need to be able to evict objects that are
>> locked by the current ctx. By testing if the current context already
>> locked the object, we can do this correctly. This allows
This adds support for DRM_BRIDGE_ATTACH_NO_CONNECTOR by adding the
bridge get_edid() and detect() callbacks after refactoring the connector
get_modes() and connector_detect() callbacks.
In order to keep the bridge working, extra code in get_modes() has been
moved to more logical places.
Signed-of
On 1/13/22 12:44, Maarten Lankhorst wrote:
Because we will start to require the obj->resv lock for unbinding,
ensure these shrinker functions also take the lock.
Perhaps "vma eviction utilities" rather than "shrinker functions"?
This requires some function signature changes, to ensure that t
On 1/13/22 12:44, Maarten Lankhorst wrote:
We want to remove more members of i915_vma, which requires the locking to be
Checkpatch.pl warning.
On 1/13/22 12:44, Maarten Lankhorst wrote:
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
Reviewed-by: Tho
On Thu, Jan 13, 2022 at 08:48:06AM +, Xu Wang wrote:
> 'destroy_workqueue()' already drains the queue before destroying it, so
> there is no need to flush it explicitly.
>
> Remove the redundant 'flush_workqueue()' calls.
>
> Signed-off-by: Xu Wang
Reviewed-by: Daniel Thompson
Daniel.
On Thu, Jan 13, 2022 at 03:18:14PM +0100, Michal Wajdeczko wrote:
>
>
> On 13.01.2022 00:26, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 12:21:17AM +0100, Michal Wajdeczko wrote:
> >> On 11.01.2022 17:30, Matthew Brost wrote:
>
> ...
>
> >>> @@ -1863,6 +1861,33 @@ static void guc_submit_re
Il 10/01/22 09:46, Nancy.Lin ha scritto:
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
allocates
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add driver data of mt8195 vdosys1 to mediatek-drm.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
This is a preparation for adding support for mt8195 vdosys1 mutex.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Modify mmsys for support 64 bit and different reset
base.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be
Il 10/01/22 09:46, Nancy.Lin ha scritto:
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Hi Hans,
On 13/01/2022 11:15, Hans Verkuil wrote:
On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
Il 12/11/21 11:55, Yong Wu ha scritto:
After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function
From: Rob Clark
Reported-by: Danylo Piliaiev
Fixes: 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers
Move the multi-lrc guc_id from the lower allocation partition (0 to
number of multi-lrc guc_ids) to upper allocation partition (number of
single-lrc to max guc_ids).
This will help when a native driver transitions to a PF after driver
load time. If the perma-pin guc_ids (kernel contexts) are in a
I may have missed some discussions, but I'm objecting against this patch:
b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling acceleration,
part 1 (from TODO list)")
Can we please (partly) revert it and restore the scrolling behaviour,
where fbcon uses fb_copyarea() to copy the screen
On 1/13/22 09:51, Thomas Zimmermann wrote:
> ping!
>
> This patchset got lost. Patches 4 and 5 still need a review.
for patches 4 & 5:
Acked-by: Helge Deller
Helge
>
> Am 01.12.21 um 12:46 schrieb Thomas Zimmermann:
>> Fix a number of compiler warnings in the AGP drivers. No functional
>> chang
This short serie contains the maintainer status update sent recently by
Benjamin Gaignard (see [1] for details) and add new maintainers for
various stm & sti files.
[1]
https://lore.kernel.org/lkml/20210706163033.795805-1-benjamin.gaign...@collabora.com/
Benjamin Gaignard (1):
MAINTAINERS: Up
Add Alain as sti maintainer for both drm/sti & cec/sti.
Add Raphaël as stm maintainer for drm/stm.
Signed-off-by: Philippe Cornu
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6bea080d0159..708f8c86e4c9 100644
--- a/MAINTAINERS
+++ b/MAINTA
From: Benjamin Gaignard
Update Benjamin Gaignard address and remove it from no more maintained
drivers.
Signed-off-by: Benjamin Gaignard
---
MAINTAINERS | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2345ce8521..6bea080d0159 100644
---
On 1/11/2022 15:11, Matthew Brost wrote:
In the i915 there are several hacks in place to make request cancelation
work with an old version of the GuC which delivered the G2H indicating
schedule disable is done before G2H indicating a context reset. Version
69 fixes this, so we can remove these ha
On 1/11/2022 15:11, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption tim
On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> On 1/11/2022 15:11, Matthew Brost wrote:
> > Add a cancel request selftest that results in an engine reset to cancel
> > the request as it is non-preemptable. Also insert a NOP request after
> > the cancelled request and confirm that
Hi All,
RZ/G2{H, M, N} SoC has dw_hdmi IP and it was working ok(colour) till the commit
7cd70656d1285b79("drm/bridge: display-connector: implement bus fmts callbacks").
After this patch, the screen becomes greenish(may be it is setting it into YUV
format??).
By checking the code, previously it
On 1/12/2022 8:13 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-12 14:17:54)
On 1/12/2022 12:00 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-01-11 10:43:23)
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symm
I think we'll also want to do a conditional disable for DC
(drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c) since it only
enables modifiers on newer HW. Something like "if (modifiers == NULL)
fb_modifiers_not_supported = true;" in amdgpu_dm_plane_init.
On Thu, Jan 13, 2022 at 10:44 AM Tomohito
After a small fix to error capture code, we now can flush G2H during a
GT reset which simplifies code and seals some extreme corner case races.
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
drm/i915/guc: Flush G2H handler duri
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL do fully decouple the error capture from fence signalling.
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which is turn depends on resets) we
can safely flush the G2H handler during a GT reset. This is eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
Signed-
On 1/13/2022 09:34, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
On 1/11/2022 15:11, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the canc
On Thu, Jan 13, 2022 at 09:59:35AM -0800, John Harrison wrote:
> On 1/13/2022 09:34, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> > > On 1/11/2022 15:11, Matthew Brost wrote:
> > > > Add a cancel request selftest that results in an engine reset to cancel
1 - 100 of 151 matches
Mail list logo
