Hi Paul,
> Am 04.03.2022 um 19:41 schrieb H. Nikolaus Schaller :
>
>
>
>> Am 04.03.2022 um 19:33 schrieb Paul Cercueil :
>>
>>
>>
>> Le ven., mars 4 2022 at 19:15:13 +0100, H. Nikolaus Schaller
>> a écrit :
>>> Hi Paul,
Am 04.03.2022 um 19:04 schrieb Paul Cercueil :
Le ven., mars
Le 04/03/2022 à 21:24, Lyude Paul a écrit :
> This mostly looks good to me. Just one question (and one comment down below
> that needs addressing). Is this with ppc32? (I ask because ppc64le doesn't
> seem to hit this compilation error).
That's with PPC64, see
http://kisskb.ellerman.id.au/kissk
On Fri, Mar 04, 2022 at 12:20:02PM +0900, Byungchul Park wrote:
>
> I found a point that the two wait channels don't lead a deadlock in
> some cases thanks to Jan Kara. I will fix it so that Dept won't
> complain it.
I sent my last (admittedly cranky) message before you sent this. I'm
glad you f
On Fri, Mar 04, 2022 at 09:42:37AM +0900, Byungchul Park wrote:
>
> All contexts waiting for any of the events in the circular dependency
> chain will be definitely stuck if there is a circular dependency as I
> explained. So we need another wakeup source to break the circle. In
> ext4 code, you m
On 3/3/2022 7:21 PM, Dmitry Baryshkov wrote:
Currently the msm platform driver is a multiplex handling several cases:
- headless GPU-only driver,
- MDP4 with flat device nodes,
- MDP5/DPU MDSS with all the nodes being children of MDSS node.
This results in not-so-perfect code, checking the ha
On 3/3/2022 7:21 PM, Dmitry Baryshkov wrote:
Since now there is just one mdss subdriver, drop all the indirection,
make msm_mdss struct completely opaque (and defined inside msm_mdss.c)
and call mdss functions directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
driv
On 3/3/2022 7:21 PM, Dmitry Baryshkov wrote:
MDP5 and DPU1 both provide the driver handling the MDSS region, which
handles the irq domain and (incase of DPU1) adds some init for the UBWC
controller. Unify those two pieces of code into a common driver.
Signed-off-by: Dmitry Baryshkov
Reviewe
On 3/4/22 17:22, Sascha Hauer wrote:
> On Wed, Mar 02, 2022 at 12:25:28PM +0100, Sascha Hauer wrote:
>> On Tue, Mar 01, 2022 at 01:39:31PM +, Robin Murphy wrote:
>>> On 2022-02-28 14:19, Sascha Hauer wrote:
On Fri, Feb 25, 2022 at 02:11:54PM +0100, Sascha Hauer wrote:
> On Fri, Feb 25,
Hi, Rob:
Would you like to take this series into your tree, or I take this
series into my tree?
Regards,
Chun-Kuang.
AngeloGioacchino Del Regno 於
2022年3月4日 週五 下午5:55寫道：
>
> The vdosys0 series carried a nice dt-bindings conversion of the old
> txt documentation for the entire mediatek-drm driver
Hi, Angelo:
AngeloGioacchino Del Regno 於
2022年3月4日 週五 下午5:55寫道：
>
> To avoid failure of dt_binding_check perform a slight refactoring
> of the examples: the main block is kept, but that required fixing
> the address and size cells, plus the inclusion of missing dt-bindings
> headers, required to
From: Akeem G Abodunrin
Since DG2 and beyond only support global preemption enable/disable (see
Wa_14015141709), userspace no longer has a way to control preemption on
a per-context basis. Preemption is globally enabled by default, but the
UMD teams have requested that we provide a debugfs inter
From: Akeem G Abodunrin
Starting with DG2, preemption can no longer be controlled using userspace
on a per-context basis. Instead, the hardware only allows us to enable or
disable preemption in a global, system-wide basis. Also, we lose the
ability to specify the preemption granularity (such as
Hi, Angelo:
AngeloGioacchino Del Regno 於
2022年3月4日 週五 下午5:55寫道：
>
> The property is called 'iommus' and not 'iommu'. Fix this typo.
Acked-by: Chun-Kuang Hu
>
> Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block
> to individual yaml")
> Signed-off-by: AngeloGioacchino
Hi, Angelo:
AngeloGioacchino Del Regno 於
2022年3月4日 週五 下午5:55寫道：
>
> The mediatek,gce-events property needs as value an array of uint32
> corresponding to the CMDQ events to listen to, and not any phandle.
Acked-by: Chun-Kuang Hu
>
> Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: s
On Fri, Mar 04, 2022 at 11:39:29AM +, Hyeonggon Yoo wrote:
> Works as expected, Thanks!
> I would report if there is anything else interesting.
Thanks a lot! What you have done is helpful.
Thanks,
Byungchul
> Tested-by: Hyeonggon Yoo <42.hye...@gmail.com>
>
> --
> Thank you, You are awesom
On Fri, Mar 04, 2022 at 10:28:57PM +0300, Sergei Shtylyov wrote:
> On 3/4/22 10:06 AM, Byungchul Park wrote:
>
> > cb92173d1f0 (locking/lockdep, cpu/hotplug: Annotate AP thread) was
>
>You need to enclose the commit summary in (""), not just (). :-)
Thank you! I will!
> > introduced to make
On Fri, Mar 04, 2022 at 12:13:12PM +0200, Jani Nikula wrote:
> On Thu, 03 Mar 2022, Matt Roper wrote:
> > From: Akeem G Abodunrin
> >
> > Starting with DG2, preemption can no longer be controlled using userspace
> > on a per-context basis. Instead, the hardware only allows us to enable or
> > dis
Hi Dave, Daniel,
A few things for 5.18, mostly bug fixes.
The following changes since commit 38a15ad9488e21cad8f42d3befca20f91e5b2874:
Merge tag 'amd-drm-next-5.18-2022-02-25' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-03-01 16:19:02
+1000)
are available in the Git re
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the
On Sat, 5 Mar 2022 at 00:49, Doug Anderson wrote:
> On Thu, Mar 3, 2022 at 4:16 PM Dmitry Baryshkov
> wrote:
> >
> > On Fri, 4 Mar 2022 at 02:56, Stephen Boyd wrote:
> > >
> > > Quoting Dmitry Baryshkov (2022-03-03 15:50:50)
> > > > On Thu, 3 Mar 2022 at 12:40, Vinod Polimera
> > > > wrote:
>
From: Fei Yang
GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the
On Thu, Mar 3, 2022 at 7:21 PM Dmitry Baryshkov
wrote:
>
> MSM DRM driver already allows one to compile out the DP or DSI support.
> Add support for disabling other features like MDP4/MDP5/DPU drivers or
> direct HDMI output support.
>
> Suggested-by: Stephen Boyd
> Signed-off-by: Dmitry Baryshko
On Fri, Mar 4, 2022 at 1:47 PM Dmitry Baryshkov
wrote:
>
> On Fri, 4 Mar 2022 at 23:23, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Fixes: f6d62d091cfd ("drm/msm/a6xx: add support for Adreno 660 GPU")
> > Signed-off-by: Rob Clark
>
> Reviewed-by: Dmitry Baryshkov
> However see the comment
On Tue, Mar 1, 2022 at 1:57 PM Patchwork
wrote:
>
> == Series Details ==
>
> Series: use dynamic-debug under drm.debug api (rev2)
> URL : https://patchwork.freedesktop.org/series/100289/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> c2ed9cc02d9c dyndbg: fix static_bra
Hi,
On Thu, Mar 3, 2022 at 4:16 PM Dmitry Baryshkov
wrote:
>
> On Fri, 4 Mar 2022 at 02:56, Stephen Boyd wrote:
> >
> > Quoting Dmitry Baryshkov (2022-03-03 15:50:50)
> > > On Thu, 3 Mar 2022 at 12:40, Vinod Polimera
> > > wrote:
> > > >
> > > > Kernel clock driver assumes that initial rate is
On Fri, 4 Mar 2022 at 23:23, Rob Clark wrote:
>
> From: Rob Clark
>
> Fixes: f6d62d091cfd ("drm/msm/a6xx: add support for Adreno 660 GPU")
> Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
However see the comment below.
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 1 +
> 1 file cha
On Fri, Mar 04, 2022 at 11:11:54PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 04, 2022 at 01:03:55PM -0800, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > Clang static analysis reports this issue
> > intel_dpll.c:472:31: warning: The left operand of '-'
> > is a garbage value [core.UndefinedBi
On Fri, Mar 04, 2022 at 01:03:55PM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> Clang static analysis reports this issue
> intel_dpll.c:472:31: warning: The left operand of '-'
> is a garbage value [core.UndefinedBinaryOperatorResult]
> this_err = abs(clock.dot - target);
>
From: Tom Rix
Clang static analysis reports this issue
intel_dpll.c:472:31: warning: The left operand of '-'
is a garbage value [core.UndefinedBinaryOperatorResult]
this_err = abs(clock.dot - target);
~ ^
In a loop clock.dot is set on successful call to
i9xx_calc_dpl
Hello Thomas,
On 3/4/22 21:00, Thomas Zimmermann wrote:
> Hi,
>
> I've merged the patches into drm-misc-fixes. Thanks a lot to both of you.
>
Ard already picked these through the efi tree:
https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/
> Best regards
> Thomas
>
--
Best reg
Hi Suraj
On 3/4/2022 6:16 AM, Kandpal, Suraj wrote:
Hi,
Hi,
Hi Abhinav,
Hi Laurent
Ok sure, I can take this up but I need to understand the
proposal a little bit more before proceeding on this. So we will
discuss this in another email where we specifically talk about the
connector changes.
This mostly looks good to me. Just one question (and one comment down below
that needs addressing). Is this with ppc32? (I ask because ppc64le doesn't
seem to hit this compilation error).
On Fri, 2022-03-04 at 18:20 +0100, Christophe Leroy wrote:
> While working on powerpc headers, I ended up with
From: Rob Clark
Fixes: f6d62d091cfd ("drm/msm/a6xx: add support for Adreno 660 GPU")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 02b479
The pull request you sent on Fri, 4 Mar 2022 13:34:36 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-03-04
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c4fc118ae26f9d4e5885d151f9b0f96467a136da
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
From: Rob Clark
refcount_t complains about 0->1 transitions, which isn't *quite* what we
wanted. So use dirtyfb==1 to mean that the fb is not connected to any
output that requires dirtyfb flushing, so that we can keep the underflow
and overflow checking.
Fixes: 9e4dde28e9cd ("drm/msm: Avoid dir
On 3/4/2022 03:59, Jani Nikula wrote:
On Thu, 24 Feb 2022, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as a check for
context registration, use the GuC id instead (being the thing that
actually gets registered with the GuC).
Al
Hi,
I've merged the patches into drm-misc-fixes. Thanks a lot to both of you.
Best regards
Thomas
Am 02.03.22 um 20:47 schrieb Javier Martinez Canillas:
Hello,
On 3/2/22 20:38, Michal Suchánek wrote:
Hello,
On Wed, Mar 02, 2022 at 08:31:25PM +0100, Thomas Zimmermann wrote:
Hi,
is this rea
Hi Nikita,
Le sam., déc. 25 2021 at 09:31:51 +0300, Nikita Yushchenko
a écrit :
Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
get ignored unless somebody calls drm_bridge_hpd_enable(). When the
connector for the bridge is bridge_connector, such a call is done from
drm_
In the fbtft_init_display() the init sequence is printed for
the debug purposes. Unfortunately the current code doesn't take
into account that values in the buffer are of the s16 type.
Consider that and replace the printing code with fbtft_par_dbg_hex()
call.
Fixes: b97014a9 ("staging/fbtft:
On Fri, Mar 04, 2022 at 05:23:32PM +, Matthew Auld wrote:
> The offset we get looks to be the exact start of DSM, but the
> inital_plane_vma expects the address to be relative.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> .../drm/i915/display/intel_plane_initial.c| 22
On 3/4/22 10:06 AM, Byungchul Park wrote:
> cb92173d1f0 (locking/lockdep, cpu/hotplug: Annotate AP thread) was
You need to enclose the commit summary in (""), not just (). :-)
> introduced to make lockdep_assert_cpus_held() work in AP thread.
>
> However, the annotation is too strong for tha
On 3/3/2022 2:51 PM, AngeloGioacchino Del Regno wrote:
Il 02/03/22 18:27, Akhil P Oommen ha scritto:
Retry infinitely on resume failure because there is nothing much we can
do if GPU is not ON. Also, this helps us to avoid checking for the
return value of pm_runtime_get() to see if GPU is ON.
S
> Am 04.03.2022 um 19:33 schrieb Paul Cercueil :
>
>
>
> Le ven., mars 4 2022 at 19:15:13 +0100, H. Nikolaus Schaller
> a écrit :
>> Hi Paul,
>>> Am 04.03.2022 um 19:04 schrieb Paul Cercueil :
>>> Le ven., mars 4 2022 at 18:51:14 +0100, H. Nikolaus Schaller
>>> a écrit :
Hi Paul, Nei
Le ven., mars 4 2022 at 19:15:13 +0100, H. Nikolaus Schaller
a écrit :
Hi Paul,
Am 04.03.2022 um 19:04 schrieb Paul Cercueil :
Le ven., mars 4 2022 at 18:51:14 +0100, H. Nikolaus Schaller
a écrit :
Hi Paul, Neil,
Am 04.03.2022 um 17:47 schrieb Paul Cercueil
:
From what I unders
Hi Paul,
> Am 04.03.2022 um 19:04 schrieb Paul Cercueil :
>
>
>
> Le ven., mars 4 2022 at 18:51:14 +0100, H. Nikolaus Schaller
> a écrit :
>> Hi Paul, Neil,
>>> Am 04.03.2022 um 17:47 schrieb Paul Cercueil :
>>> From what I understood in Nikolaus' last message, HDMI hotplug is actually
>>> c
Le ven., mars 4 2022 at 18:51:14 +0100, H. Nikolaus Schaller
a écrit :
Hi Paul, Neil,
Am 04.03.2022 um 17:47 schrieb Paul Cercueil :
From what I understood in Nikolaus' last message, HDMI hotplug is
actually correctly detected, so there's no need for polling. What is
missing is the ca
Hi Paul, Neil,
> Am 04.03.2022 um 17:47 schrieb Paul Cercueil :
>
> From what I understood in Nikolaus' last message, HDMI hotplug is actually
> correctly detected, so there's no need for polling. What is missing is the
> call to drm_kms_helper_hotplug_event *somewhere*, so that the information
While working on powerpc headers, I ended up with the following error.
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error:
conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, const char
*)'
make[5]: *** [scripts/Makefile.build:288:
drivers/gpu/drm/n
On Fri, 2022-03-04 at 17:42 +, Matthew Auld wrote:
> This is no longer possible since e6e1a304d759 ("drm/i915: vma is
> always
> backed by an object.").
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
LGTM.
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/i915_vma.c | 1
This is no longer possible since e6e1a304d759 ("drm/i915: vma is always
backed by an object.").
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_v
On 3/3/22 11:02, Matthew Auld wrote:
Currently this will enforce both 2M alignment and padding for any LMEM
pages inserted into the GGTT. However, this was only meant to be applied
to the compact-pt layout with the ppGTT. For the GGTT we can reduce the
alignment and padding to 64K.
Bspec: 4501
On DG2+ the initial fb shouldn't be placed anywhere close to DSM, and so
should just be allocated directly from LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_plane_initial.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --
The offset we get looks to be the exact start of DSM, but the
inital_plane_vma expects the address to be relative.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/display/intel_plane_initial.c| 22 +++
1 file changed, 18 insertions(+), 4 deletions(-)
diff
From: CQ Tang
When system does not have mappable aperture, ggtt->mappable_end=0. In
this case if we pass PIN_MAPPABLE when pinning vma, the pinning code
will return -ENOSPC. So conditionally set PIN_MAPPABLE if HAS_GMCH().
Suggested-by: Chris P Wilson
Signed-off-by: CQ Tang
Cc: Radhakrishna Sr
If this is an actual range allocation, and not some bias thing then the
resultant allocation will already be naturally contiguous without
needing any power-of-two rounding.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 ++-
1 file changed
For the ttm backend we can use existing placements fpfn and lpfn to
force the allocator to place the object at the requested offset,
potentially evicting stuff if the spot is currently occupied.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h
Add a generic interface for allocating an object at some specific
offset, and convert stolen over. Later we will want to hook this up to
different backends.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/display/intel_plane_initial.c| 4 +-
drivers/gpu/drm/i915/gem/i915_
From: Akeem G Abodunrin
On client platforms with reduced LMEM BAR, we should be able to continue
with driver load with reduced io_size. Instead of using the BAR size to
determine the how large stolen should be, we should instead use the
ADDR_RANGE register to figure this out(at least on platforms
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/
The leftover bits around dealing with stolen-local memory + small BAR, plus
some related fixes.
--
2.34.1
On Thu, Mar 3, 2022 at 3:37 PM Gustavo A. R. Silva
wrote:
>
> On Thu, Mar 03, 2022 at 12:19:57PM -0600, Gustavo A. R. Silva wrote:
> > On Thu, Mar 03, 2022 at 09:43:28AM -0800, Kees Cook wrote:
> > > On Thu, Mar 03, 2022 at 11:25:03AM -0600, Gustavo A. R. Silva wrote:
> > > > Fix the following Wst
Hi Neil,
Le ven., mars 4 2022 at 14:30:46 +0100, Neil Armstrong
a écrit :
Hi,
On 03/03/2022 18:59, H. Nikolaus Schaller wrote:
Hi Paul, Neil,
Am 03.03.2022 um 18:20 schrieb Paul Cercueil :
Hi Nikolaus,
[snip]
Well he said "the Ingenic DRM core" aka ingenic-drm-drv.c. You do
have access
Hi,
On Fri, Mar 4, 2022 at 7:46 AM Kieran Bingham
wrote:
>
> > > What about:
> > >
> > > pdata->no_hpd = of_property_read_bool(np, "no-hpd");
> > > if (panel && !pdata->no_hpd) {
> > > DRM_ERROR("Panels will not function with HPD. Enforcing
> > > no-hpd\n");
> > >
On Wed, Feb 23, 2022 at 10:20:18AM -0800, Doug Anderson wrote:
> On Wed, Feb 23, 2022 at 10:05 AM Kieran Bingham wrote:
> >
> > > > > + /* For DisplayPort, disable scrambling mode. */
> > > > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
> > > > > + regmap_
Hi Doug,
Quoting Doug Anderson (2022-02-23 18:25:13)
> Hi,
>
> On Wed, Feb 23, 2022 at 9:43 AM Kieran Bingham
> wrote:
> >
> > Hi All,
> >
> > I'm working to respin the remainder of these patches, now that I have
> > IRQ based HPD working on the SN65DSI86, and the (non-eDP) mode is used
> > for
On Fri, 04 Mar 2022 10:54:58 +0100, AngeloGioacchino Del Regno wrote:
> To avoid failure of dt_binding_check perform a slight refactoring
> of the examples: the main block is kept, but that required fixing
> the address and size cells, plus the inclusion of missing dt-bindings
> headers, required t
On Fri, 04 Mar 2022 10:54:57 +0100, AngeloGioacchino Del Regno wrote:
> The property is called 'iommus' and not 'iommu'. Fix this typo.
>
> Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block
> to individual yaml")
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
>
On Fri, 04 Mar 2022 10:54:56 +0100, AngeloGioacchino Del Regno wrote:
> The mediatek,gce-events property needs as value an array of uint32
> corresponding to the CMDQ events to listen to, and not any phandle.
>
> Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block
> to in
On Fri, 04 Mar 2022 10:33:11 +1030, Joel Stanley wrote:
> Convert the bindings to yaml and add the ast2600 compatible string.
>
> The legacy mfd description was put in place before the gfx bindings
> existed, to document the compatible that is used in the pinctrl
> bindings.
>
> Signed-off-by: Jo
The exact behaviour of DSI host controllers is not specified,
therefore define it.
Signed-off-by: Dave Stevenson
Reviewed-by: Laurent Pinchart
---
Documentation/gpu/drm-kms-helpers.rst | 7 +++
drivers/gpu/drm/drm_bridge.c | 39 +++
2 files changed,
Mapping to the drm_bridge flag pre_enable_upstream_first,
add a new flag prepare_upstream_first to drm_panel to allow
the panel driver to request that the upstream bridge should
be pre_enabled before the panel prepare.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/bridge/panel.c | 3 +++
in
DSI sink devices typically want the DSI host powered up and configured
before they are powered up. pre_enable is the place this would normally
happen, but they are called in reverse order from panel/connector towards
the encoder, which is the "wrong" order.
Add a new flag pre_enable_upstream_first
drm_bridge_chain_pre_enable is a subset of
drm_atomic_bridge_chain_pre_enable, and drm_bridge_chain_post_disable
is a subset of drm_atomic_bridge_chain_post_disable.
Change drm_bridge_chain_pre_enable and drm_bridge_chain_post_disable to
call the atomic versions with a NULL state, and ensure that
Hi All
Changes from v1:
- New patch to refactor drm_bridge_chain_post_disable and
drm_bridge_chain_pre_enable
to reuse drm_atomic_bridge_chain_post_disable /
drm_atomic_bridge_chain_pre_enable
but with a NULL state.
- New patch that adds a pre_enable_upstream_first to drm_panel.
- changed fr
Hi,
The writeback-check-output is currently broken on vc4.
It's in part due to a bug in the kernel driver that results in a page
flip timeout, but once that's fixed the test is still broken, and I'm
not sure how to solve this one.
Indeed, the frame comparison is done between the (XRGB) buffe
On Wed, Mar 02, 2022 at 12:25:28PM +0100, Sascha Hauer wrote:
> On Tue, Mar 01, 2022 at 01:39:31PM +, Robin Murphy wrote:
> > On 2022-02-28 14:19, Sascha Hauer wrote:
> > > On Fri, Feb 25, 2022 at 02:11:54PM +0100, Sascha Hauer wrote:
> > > > On Fri, Feb 25, 2022 at 12:41:23PM +, Robin Murp
Hi,
> > Hi,
> > > > Hi Abhinav,
> > > > > Hi Laurent
> > > > >
> > > > > Ok sure, I can take this up but I need to understand the
> > > > > proposal a little bit more before proceeding on this. So we will
> > > > > discuss this in another email where we specifically talk about the
> connector chan
Hi,
On 03/03/2022 18:59, H. Nikolaus Schaller wrote:
Hi Paul, Neil,
Am 03.03.2022 um 18:20 schrieb Paul Cercueil :
Hi Nikolaus,
[snip]
Well he said "the Ingenic DRM core" aka ingenic-drm-drv.c. You do have access
to the main drm_device in the ingenic_drm_bind() function, so you can add it
On 03/03/2022 19:09, John Harrison wrote:
Actions:
1)
Get a number from compute/OpenCL people for what they say is minimum
preempt timeout for default out of the box Linux desktop experience.
That would be the one that has been agreed upon by both linux software
arch and all UMD teams and h
On Thu, Mar 03, 2022 at 11:14:24AM +0200, Laurent Pinchart wrote:
> On Wed, Mar 02, 2022 at 06:00:08PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 29, 2021 at 5:47 PM Laurent Pinchart wrote:
> > > On Fri, Dec 24, 2021 at 08:23:09AM +0300, Nikita Yushchenko wrote:
> > > > Document the R-Car M3-
Hi José
Quoting Kieran Bingham (2022-03-03 21:59:26)
> Quoting José Expósito (2022-03-03 18:37:20)
> > On Mon, Feb 28, 2022 at 11:24:36PM +, Kieran Bingham wrote:
> > > Hi José
> > >
> > > Quoting José Expósito (2022-02-28 18:39:54)
> > > > The function "drm_of_find_panel_or_bridge" has been
Il 18/02/22 11:07, xinlei@mediatek.com ha scritto:
From: Xinlei Lee
Add the compatible because use different cmdq addresses in mt8186.
Signed-off-by: Xinlei Lee
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertio
Il 18/02/22 11:07, xinlei@mediatek.com ha scritto:
From: Xinlei Lee
Add dt-binding documentation of dsi for MediaTek MT8186 SoC.
Signed-off-by: Xinlei Lee
Reviewed-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 +
1 file ch
Il 18/02/22 11:07, xinlei@mediatek.com ha scritto:
From: Xinlei Lee
Convert mediatek,dsi.txt to mediatek,dsi.yaml format
Signed-off-by: Xinlei Lee
---
.../display/mediatek/mediatek,dsi.txt | 62 --
.../display/mediatek/mediatek,dsi.yaml| 85 +
On Thu, 24 Feb 2022, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The LRC descriptor pool is going away. So, stop using it as a check for
> context registration, use the GuC id instead (being the thing that
> actually gets registered with the GuC).
>
> Also, rename the set/clear/quer
Please also prefix cover letters with drm/mediatek if that's the only
place you're touching.
BR,
Jani.
On Fri, 04 Mar 2022, wrote:
> From: Xinlei Lee
>
> In upstream-v5.8, dsi_enable will operate panel_enable, but this
> modification has been moved in v5.9. In order to ensure the timing of
>
On Fri, Mar 04, 2022 at 04:06:41PM +0900, Byungchul Park wrote:
> Dept already prevents creating dependencies between different depths of
> the class indicated by *_lock_nested() when the lock acquisitions happen
> consecutively.
>
>lock A0 with depth
>lock_nested A1 with depth + 1
>..
On Fri, Mar 04, 2022 at 12:05:14PM +0100, Paul Kocialkowski wrote:
> On Fri 04 Mar 22, 12:00, Paul Kocialkowski wrote:
> > Hi Maxime,
> >
> > On Fri 04 Mar 22, 09:54, Maxime Ripard wrote:
> > > Hi Paul,
> > >
> > > On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote:
> > > > On Wed
On 03/03/2022 22:42, Matt Roper wrote:
From: Akeem G Abodunrin
Starting with DG2, preemption can no longer be controlled using userspace
on a per-context basis. Instead, the hardware only allows us to enable or
disable preemption in a global, system-wide basis. Also, we lose the
ability to sp
On Fri, 4 Mar 2022 at 13:47, Kandpal, Suraj wrote:
>
> Hi,
> > > Hi Abhinav,
> > > > Hi Laurent
> > > >
> > > > Ok sure, I can take this up but I need to understand the proposal a
> > > > little bit more before proceeding on this. So we will discuss this
> > > > in another email where we specifica
Le 04/03/2022 à 11:15, xinlei@mediatek.com a écrit :
From: Xinlei Lee
In upstream-v5.8, dsi_enable will operate panel_enable, but this
modification has been moved in v5.9. In order to ensure the timing of
dsi_power_on/off and the timing of pulling up/down the MIPI signal,
the modification
Hi,
> > Hi Abhinav,
> > > Hi Laurent
> > >
> > > Ok sure, I can take this up but I need to understand the proposal a
> > > little bit more before proceeding on this. So we will discuss this
> > > in another email where we specifically talk about the connector changes.
> > >
> > > Also, I am willing
Hi,
On Fri, 4 Mar 2022 at 12:56, Kandpal, Suraj wrote:
>
> Hi Abhinav,
> > Hi Laurent
> >
> > Ok sure, I can take this up but I need to understand the proposal a little
> > bit
> > more before proceeding on this. So we will discuss this in another email
> > where we specifically talk about the c
On Thu, 03 Mar 2022, Matt Roper wrote:
> From: Akeem G Abodunrin
>
> Starting with DG2, preemption can no longer be controlled using userspace
> on a per-context basis. Instead, the hardware only allows us to enable or
> disable preemption in a global, system-wide basis. Also, we lose the
> abili
Hi Abhinav,
> Hi Laurent
>
> Ok sure, I can take this up but I need to understand the proposal a little bit
> more before proceeding on this. So we will discuss this in another email
> where we specifically talk about the connector changes.
>
> Also, I am willing to take this up once the encoder
To avoid failure of dt_binding_check perform a slight refactoring
of the examples: the main block is kept, but that required fixing
the address and size cells, plus the inclusion of missing dt-bindings
headers, required to parse some of the values assigned to various
properties.
Fixes: 4ed545e7d10
The property is called 'iommus' and not 'iommu'. Fix this typo.
Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block to
individual yaml")
Signed-off-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 2 +-
1 file changed
The mediatek,gce-events property needs as value an array of uint32
corresponding to the CMDQ events to listen to, and not any phandle.
Fixes: 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block to
individual yaml")
Signed-off-by: AngeloGioacchino Del Regno
---
.../devicetree/
The vdosys0 series carried a nice dt-bindings conversion of the old
txt documentation for the entire mediatek-drm driver, but some of
the issues in there weren't seen.
This series is fixing all of the issues pointed out by a
`dt_binding_check` run, followed by `dtbs_check`.
AngeloGioacchino Del R
Hi Paul,
On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote:
> On Wed 02 Feb 22, 21:34, Jagan Teki wrote:
> > Devices can also be child nodes when we also control that device
> > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
> >
> > drm_of_find_panel_or_bridge c
1 - 100 of 111 matches
Mail list logo
