On Wed, 25 May 2022 06:04:44 +
Simon Ser wrote:
> On Wednesday, May 25th, 2022 at 00:03, Alex Deucher
> wrote:
>
> > > Why would anyone want to run at 8bpc when they have a panel with
> > > higher color depth? So I think someone is going to be doing that
> > > modeset eventually anyway.
On Mon, 23 May 2022 13:54:50 +0200
Sebastian Wick wrote:
> I was always under the impression that if you do an atomic commit
> without changing any properties that it won't result in a mode set
> which would clearly make the current behavior a bug.
This is a very good point.
If one does an atom
Alex Sierra writes:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration or THP.
>
> We
On Tue, 24 May 2022 14:33:20 -0400
Harry Wentland wrote:
> The supported EOTFs are defined in eotf_supported in drm_edid
> but userspace has no way of knowing what is and isn't supported
> when creating an HDR_OUTPUT_METADATA and will only know
> something is wrong when the atomic commit fails.
Commit 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in
encoder") added dsc_common_mode variable which was set to zero but then
again programmed, so drop the superfluous init.
Fixes: 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in encoder")
Reported-by: kernel test robot
Reviewed
On 24.05.22 20:32, Chuck Zmudzinski wrote:
> On 5/21/22 6:47 AM, Thorsten Leemhuis wrote:
>> On 20.05.22 16:48, Chuck Zmudzinski wrote:
>>> On 5/20/2022 10:06 AM, Jan Beulich wrote:
On 20.05.2022 15:33, Chuck Zmudzinski wrote:
> On 5/20/2022 5:41 AM, Jan Beulich wrote:
>> On 20.05.2
On Wed, 25 May 2022 at 01:03, Marijn Suijten
wrote:
>
> On 2022-05-24 02:43:01, Dmitry Baryshkov wrote:
> > Hi,
> >
> > On Tue, 24 May 2022 at 00:38, Marijn Suijten
> > wrote:
> > >
> > > As stated in [1] I promised to tackle and send this series.
> > >
> > > parent_hw pointers are easier to mana
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatten out
the fences into a dma_fence_array instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 61 +
On 2022-05-25 00:03, Alex Deucher wrote:
> On Tue, May 24, 2022 at 11:43 AM Ville Syrjälä
> wrote:
>> On Tue, May 24, 2022 at 11:36:22AM +0200, Hans de Goede wrote:
>>> Hi,
>>> On 5/23/22 13:54, Sebastian Wick wrote:
On Mon, May 23, 2022 at 10:23 AM Pekka Paalanen
wrote:
>
> Ni
On 25.05.22 10:37, Jan Beulich wrote:
> On 25.05.2022 09:45, Thorsten Leemhuis wrote:
>> On 24.05.22 20:32, Chuck Zmudzinski wrote:
>>> On 5/21/22 6:47 AM, Thorsten Leemhuis wrote:
I'm not a developer and I'm don't known the details of this thread and
the backstory of the regression, but
On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer
wrote:
> > Mind that "max bpc" is always in auto. It's only an upper limit, with
> > the assumption that the driver can choose less.
>
> It seems to me like the "max bpc" property is just kind of bad API,
> and trying to tweak it to cater to m
On 25/05/2022 11:24, Christian König wrote:
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatten out
the fences into a dma_fence_array instead.
Signed-off-by: Christian König
---
drivers
On 25/05/2022 12:26, Lionel Landwerlin wrote:
On 25/05/2022 11:24, Christian König wrote:
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatten out
the fences into a dma_fence_array instead.
This symbol is not used outside of imu_v11_0.c, so marks it
static.
Fixes the following w1 warning:
drivers/gpu/drm/amd/amdgpu/imu_v11_0.c:302:6: warning: no previous
prototype for ‘program_imu_rlc_ram’ [-Wmissing-prototypes].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/
On Thu, May 19, 2022 at 09:26:59AM -0700, Guillaume Ranquet wrote:
> On Thu, 12 May 2022 09:44, Maxime Ripard wrote:
> >Hi,
> >
> >On Wed, May 11, 2022 at 05:59:13AM -0700, Guillaume Ranquet wrote:
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >> >> +#include
> >>
On 24/05/2022 15:50, Rob Clark wrote:
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
On 23/05/2022 23:53, Rob Clark wrote:
On Mon, May 23, 2022 at 7:45 AM Tvrtko Ursulin
wrote:
Hi Rob,
On 28/07/2021 02:06, Rob Clark wrote:
From: Rob Clark
The drm/scheduler provides additiona
Il 19/04/22 11:41, jason-jh.lin ha scritto:
From: jason-jhlin
Hello Jason,
this series does not apply cleanly anymore on next-20220525, can you please
rebase and resend?
I hope that with a bit of coordination, we can get the entire display stack
finally upstreamed in v5.19... it's
On Sat, 7 May 2022 at 14:18, Jason Ekstrand wrote:
> This patch series actually contains two new ioctls. There is the export one
> mentioned above as well as an RFC for an import ioctl which provides the other
> half. The intention is to land the export ioctl since it seems like there's
> no rea
tended and that
there's no regression on older ones, so on all patches you can add my:
[Tested on MT6795, MT8173, MT8192, MT8195]
Tested-by: AngeloGioacchino Del Regno
BUT!
This series won't apply cleanly anymore on next-20220525 (same for vdosys0,
already pinged Jason about i
On Wed, 25 May 2022 09:23:51 +
Simon Ser wrote:
> On Wednesday, May 25th, 2022 at 10:35, Michel Dänzer
> wrote:
>
> > > Mind that "max bpc" is always in auto. It's only an upper limit, with
> > > the assumption that the driver can choose less.
> >
> > It seems to me like the "max bpc" pr
Am 25.05.22 um 11:35 schrieb Lionel Landwerlin:
On 25/05/2022 12:26, Lionel Landwerlin wrote:
On 25/05/2022 11:24, Christian König wrote:
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatt
Every iteration of for_each_available_child_of_node() decrements
the reference counter of the previous node. There is no decrement
when break out from the loop and results in refcount leak.
Add missing of_node_put() to fix this.
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
By this commit 2 related issues are solved:
Issue #1. Corruption in blend route/enable register:
Register corruption happens after using old_state->zpos to disable layer
state. Blend route/enable registers are shared with other layers
and other layers may have already assigned this PIPE to vali
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
From: Markus Schneider-Pargmann
DPINTF is similar to DPI but does not have the exact same feature set
or register layouts.
DPINTF is the sink of the display pipeline that is connected to the
DisplayPort controller and encoder unit. It takes the
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
Signed-off-by: Guillaume Ranquet
---
include/drm/drm_edid.h | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 144c495b99c4..37c420423625 100644
--- a/include/d
On 5/21/22 21:59, Tom Rix wrote:
> cppcheck reports
> [drivers/video/fbdev/xen-fbfront.c:226]: (style) Assignment of function
> parameter has no effect outside the function.
>
> The value parameter 'transp' is not used, so setting it can be removed.
>
> Signed-off-by: Tom Rix
applied to the fbde
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
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.
Signed-off-by: Markus Sch
Il 23/05/22 12:47, Guillaume Ranquet 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
Hi,
On Mon, May 23, 2022 at 12:47:34PM +0200, Guillaume Ranquet wrote:
> From: Markus Schneider-Pargmann
>
> DPINTF is similar to DPI but does not have the exact same feature set
> or register layouts.
>
> DPINTF is the sink of the display pipeline that is connected to the
> DisplayPort control
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not avai
Hi Linus Walleij
On 19/05/22 14:39, Linus Walleij wrote:
Nope. But add the rate limited error print please!
Will do.
Lots of magic numbers. You don't have a datasheet do you?
So you could #define some of the magic?
Unfortunately, I don't have a datasheet and the power on sequence is
taken
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
This patch adds External DisplayPort support to the mt8195 eDP driver.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dp.c | 104 +++---
1 file changed, 81 insertions(+), 23 deletions(-)
Your patch
Apologies I'm constantly behind on m-l discussions :-/
On Tue, May 17, 2022 at 12:28:17PM +0200, Christian König wrote:
> Am 09.05.22 um 16:10 schrieb Daniel Vetter:
> > On Mon, May 09, 2022 at 08:56:41AM +0200, Christian König wrote:
> > > Am 04.05.22 um 12:08 schrieb Daniel Vetter:
> > > > On Mo
On Fri, May 06, 2022 at 04:10:07PM +0200, Christian König wrote:
> dma_fence_chain containers cleanup signaled fences automatically, so
> filter those out from arrays as well.
>
> v2: fix missing walk over the array
> v3: massively simplify the patch and actually update the description.
>
> Signe
On Fri, May 06, 2022 at 04:10:05PM +0200, Christian König wrote:
> The selftests, fix the error handling, remove unused functions and stop
> leaking memory in failed tests.
>
> v2: fix the memory leak correctly.
>
> Signed-off-by: Christian König
I'm still a bit lost on all this (maybe add an e
On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> Reviewed-by: Christian König for the series.
>
> I assume you have the userspace part ready as well? If yes let's push this
> to drm-misc-next asap.
Hopefully I'm not too late, but I think all my review has also been
addressed. O
On Mon, May 23, 2022 at 05:59:02PM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, May 20, 2022 at 5:01 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, May 16, 2022 at 3:28 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi Douglas,
> > >
> > > I understand that you're trying to tell userspace th
вт, 24 мая 2022 г. в 22:13, Jernej Škrabec :
>
> Don't top post, it's annoying and against rules.
>
> Dne torek, 24. maj 2022 ob 19:10:06 CEST je Roman Stratiienko napisal(a):
> > Please draft a test for the zpos issue you're mentioning.
> >
> > It's very easy to do with kmsxx using python wrapper.
On Mon, 23 May 2022 at 15:55, Linus Walleij wrote:
>
> On Mon, May 23, 2022 at 2:46 PM Linus Walleij
> wrote:
> > On Fri, May 6, 2022 at 2:33 PM YueHaibing wrote:
> >
> > > While CONFIG_OF is n but COMPILE_TEST is y, we got this:
> > >
> > > WARNING: unmet direct dependencies detected for DRM_D
On Wed, May 25, 2022 at 2:46 AM Tvrtko Ursulin
wrote:
>
>
> On 24/05/2022 15:50, Rob Clark wrote:
> > On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 23/05/2022 23:53, Rob Clark wrote:
> >>> On Mon, May 23, 2022 at 7:45 AM Tvrtko Ursulin
> >>> wrote:
>
>
> >
On Wed, May 25, 2022 at 03:28:41PM +0200, Michel Dänzer wrote:
> On 2022-05-25 15:05, Daniel Vetter wrote:
> > On Tue, May 17, 2022 at 12:28:17PM +0200, Christian König wrote:
> >> Am 09.05.22 um 16:10 schrieb Daniel Vetter:
> >>> On Mon, May 09, 2022 at 08:56:41AM +0200, Christian König wrote:
> >
On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter wrote:
> > > Ofc in reality you can still flood your compositor and they're not very
> > > robust, but with umf it's trivial to just hang your compositor forever and
> > > nothing happens.
> >
> > You can add that to the list of reasons why com
Hi,
On Wed, 25 May 2022 at 15:07, Simon Ser wrote:
> On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter wrote:
> > > You can add that to the list of reasons why compositors need to stop
> > > using buffers with unsignaled fences. There's plenty of other reasons
> > > there already (the big one
Am 25.05.22 um 16:15 schrieb Daniel Stone:
Hi,
On Wed, 25 May 2022 at 15:07, Simon Ser wrote:
On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter wrote:
You can add that to the list of reasons why compositors need to stop
using buffers with unsignaled fences. There's plenty of other reasons
On Wed, May 25, 2022 at 04:22:48PM +0200, Christian König wrote:
> Am 25.05.22 um 16:15 schrieb Daniel Stone:
> > Hi,
> >
> > On Wed, 25 May 2022 at 15:07, Simon Ser wrote:
> > > On Wednesday, May 25th, 2022 at 15:51, Daniel Vetter
> > > wrote:
> > > > > You can add that to the list of reasons
On Tue, May 17, 2022 at 08:13:24AM +0200, Greg Kroah-Hartman wrote:
> On Mon, May 16, 2022 at 05:08:05PM -0700, T.J. Mercier wrote:
> > On Mon, May 16, 2022 at 12:21 PM Christian König
> > wrote:
> > >
> > > Am 16.05.22 um 20:08 schrieb T.J. Mercier:
> > > > On Mon, May 16, 2022 at 10:20 AM Christ
вт, 24 мая 2022 г. в 22:14, Jernej Škrabec :
>
> Dne torek, 24. maj 2022 ob 19:14:35 CEST je Roman Stratiienko napisal(a):
> > By the way, not related to this issue:
> >
> > I cherry-picked
> > https://patchwork.kernel.org/project/dri-devel/patch/20220424162633.12369-9-sam...@sholland.org/
> > and
Here is version 2 of the series adding support for job manager Valhall
(v9). CSF Valhall is not supported in this series. The core
issues/features are added for Mali-G57 "Natt" as the current target.
Natt is used in MT8192, which needs a few extra patches to follow
(currently blocked on MediaTek in
>From the kernel's perspective, (pre-CSF, "Job Manager") Valhall is more
or less compatible with Bifrost, although they differ to userspace. Add
a compatible for Valhall to the existing Bifrost bindings documentation.
As the first SoC with a Valhall GPU receiving mainline support, add a
specific c
Logically, this function is free of side effects, so any pointers it
takes should be const. Needed to avoid a warning in the next patch.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Some Valhall GPUs require resets when encountering bus faults due to
occlusion query writes. Add the issue bit for this and handle it.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 9 +++--
drivers/gpu/drm/panfrost/panfrost_issue
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3 ++
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs
define slightly different MAX_READS and MAX_WRITES fields, which
throttle outstanding reads and writes when set to non-zero values. When
left as zero, reads and writes are not throttled.
Both kbase and panfrost always zero th
Add the HW_FEATURE_CLEAN_ONLY_SAFE bit based on kbase. When I actually
tried to port the logic from kbase, trivial jobs raised Data Invalid
Faults, so this may depend on other coherency details. It's still useful
to have the bit to record the feature bit when adding new models.
Signed-off-by: Alys
Add the features, issues, and GPU ID for Mali-G57, a first-generation
Valhall GPU. Other first- and second-generation Valhall GPUs should be
similar.
v2: Split out issue list for r0p0 from newer Natt GPUs, as TTRX_3485 was
fixed in r0p1. Unfortunately, MT8192 has a r0p0, so we do need to handle
TT
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
v2: Use arm,mali-valhall-jm compatible.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --gi
TTRX_3485 requires the infamous "dummy job" workaround. I have this
workaround implemented in a local branch, but I have not yet hit a case
that requires it so I cannot test whether the implementation is correct.
In the mean time, add the quirk bit so we can document which platforms
may need it in
On Mon, May 16, 2022 at 04:56:13PM -0600, Jim Cromie wrote:
> DRM.debug API is 23 macros, issuing 10 exclusive categories of debug
> messages. By rough count, they are used 5140 times in the kernel.
> These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(),
> which checks bits in glob
On Wed, May 18, 2022 at 01:12:33PM +0300, Jani Nikula wrote:
> On Wed, 18 May 2022, Hans de Goede wrote:
> > Hi,
> >
> > On 5/18/22 10:44, Jani Nikula wrote:
> >> On Tue, 17 May 2022, Hans de Goede wrote:
> >>> Hi All,
> >>>
> >>> As mentioned in my RFC titled "drm/kms: control display brightness
Dne sreda, 25. maj 2022 ob 16:55:56 CEST je Roman Stratiienko napisal(a):
> вт, 24 мая 2022 г. в 22:14, Jernej Škrabec :
> >
> > Dne torek, 24. maj 2022 ob 19:14:35 CEST je Roman Stratiienko napisal(a):
> > > By the way, not related to this issue:
> > >
> > > I cherry-picked
> > > https://patchwork
ср, 25 мая 2022 г. в 18:14, Jernej Škrabec :
>
> Dne sreda, 25. maj 2022 ob 16:55:56 CEST je Roman Stratiienko napisal(a):
> > вт, 24 мая 2022 г. в 22:14, Jernej Škrabec :
> > >
> > > Dne torek, 24. maj 2022 ob 19:14:35 CEST je Roman Stratiienko napisal(a):
> > > > By the way, not related to this i
On Wed, May 18, 2022 at 10:54:46AM +0200, Christian König wrote:
> Use unrcu_pointer() instead of the manual cast.
>
> Signed-off-by: Christian König
TIL about unrcu_pointer, and also that entire code here freaks me out. But
at least this seems more with what other users of similar xchg and cmpx
Il 23/05/22 12:47, Guillaume Ranquet ha scritto:
From: Markus Schneider-Pargmann
This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.
The controller can have two forms,
On Sun, May 22, 2022 at 01:41:04AM +0200, Niels Dossche wrote:
> Other callers of drmm_kzalloc already return -ENOMEM on allocation
> failure. Change EINVAL to ENOMEM for consistency.
>
> Signed-off-by: Niels Dossche
Thanks, applied to drm-misc-next.
-Daniel
> ---
>
> Note:
> I found this issu
On Sat, May 21, 2022 at 04:13:42PM -0300, André Almeida wrote:
> Since commit ba420afab565 ("drm/vkms: Bugfix racing hrtimer vblank
> handle") the work is scheduled at vkms_vblank_simulate() and since
> commit 5ef8100a3919 ("drm/vkms: flush crc workers earlier in commit
> flow") the work is flushed
On Wed, May 25, 2022 at 10:35:47AM -0500, Jason Ekstrand wrote:
> On Wed, May 25, 2022 at 8:20 AM Daniel Vetter wrote:
>
> > On Mon, May 09, 2022 at 07:54:19AM +0200, Christian König wrote:
> > > Reviewed-by: Christian König for the series.
> > >
> > > I assume you have the userspace part ready
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
---
We caught garbage in
On 24/05/2022 15:57, Rob Clark wrote:
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
On 23/05/2022 23:53, Rob Clark wrote:
btw, one fun (but unrelated) issue I'm hitting with scheduler... I'm
trying to add an igt test to stress shrinker/eviction, similar to the
existing tests/i915/g
On 25/05/2022 14:41, Rob Clark wrote:
On Wed, May 25, 2022 at 2:46 AM Tvrtko Ursulin
wrote:
On 24/05/2022 15:50, Rob Clark wrote:
On Tue, May 24, 2022 at 6:45 AM Tvrtko Ursulin
wrote:
On 23/05/2022 23:53, Rob Clark wrote:
On Mon, May 23, 2022 at 7:45 AM Tvrtko Ursulin
wrote:
Hi Ro
On 5/18/22 03:44, Jani Nikula wrote:
On Tue, 17 May 2022, Hans de Goede wrote:
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step toward
Hi
Am 21.05.22 um 04:49 schrieb Benjamin Herrenschmidt:
On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote:
to build without PCI to see what happens.
If you bring any of the "heuristic" and palette support code in, you
need PCI. I don't see any reason to take it out.
Those old Macs
Some comments on this from my side too, not sure how good they are when it
comes more to the hw side of things :-)
On Thu, Apr 14, 2022 at 10:50:18AM +0200, Maxime Ripard wrote:
> On Wed, Apr 13, 2022 at 05:19:00PM -0500, Samuel Holland wrote:
> > This series adds a DRM driver for the electrophore
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
>
> On 24/05/2022 18:51, Matt Roper wrote:
> > On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Catch and log any garbage in the register, including no tiles marked, or
> > > mul
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
Signed-
Applied. Thanks!
Alex
On Wed, May 25, 2022 at 5:37 AM Jiapeng Chong
wrote:
>
> This symbol is not used outside of imu_v11_0.c, so marks it
> static.
>
> Fixes the following w1 warning:
>
> drivers/gpu/drm/amd/amdgpu/imu_v11_0.c:302:6: warning: no previous
> prototype for ‘program_imu_rlc_ram’ [
Test-with: 20220525183702.490989-1-matthew.a...@intel.com
--
2.34.3
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR.
Testcase: igt@i915_query@query-regions-unallocated
Testcase: igt@i915_query@query-regions-sanit
Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so it's just case
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +---
drivers/gpu/drm/i915/intel_m
On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion. Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access.
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Da
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.
Testcase: igt@gem_exec_capture@capture-recoverable-discrete
Signed-off-by: Matthew Auld
C
Just for CI.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 6c6f8cbd7321..119e53f5d9b1 100644
--- a/drivers/gpu/d
On 5/24/2022 16:59, Matt Roper wrote:
PVC also has a hwconfig table. Actually the current expectation is that
all future platforms will have hwconfig, so let's just change the
condition to an IP version check so that we don't need to keep updating
this for each new platform that shows up.
Cc: J
Hi Jani, thanks for your review. I got all the user space
implementation ready to see it in context.
libdrm patch to wrap this functionality:
https://www.spinics.net/lists/dri-devel/msg347318.html
Chromium user space implementation making direct use of the new prop flag:
crrev.com/c/3655850
The f
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related f
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/q
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Revi
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 41 +
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/qual
Hello Dominik,
I missed this email before and never answered. Sorry about that.
On 3/10/22 14:11, Dominik Kierner wrote:
> Hello Javier,
>
> I was working on a SSD130x driver as well, although with a different
> (drm_panel) approach and hit a bit of a roadblock.
My first attempt also was using
https://bugzilla.kernel.org/show_bug.cgi?id=213145
--- Comment #16 from Eric Wheeler (bugzilla-ker...@z.ewheeler.org) ---
FYI: 5.18 seems to be working! I guess the 5.13 driver from AMD needs to be
fixed, but thats on them...
--
You may reply to this email to add a comment.
You are receiving t
Hi,
On Wed, May 25, 2022 at 12:37 PM Kuogee Hsieh wrote:
>
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Stephen Boyd
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 41
> +
>
While 'ddc-i2c-bus' is a common property, it should be in a connector
node rather than the HDMI bridge node as the I2C bus goes to a
connector and not the HDMI block. Drop it from the example.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml | 1 -
1) add regulator_set_load() to eDP phy
2) add regulator_set_load() to DP phy
3) remove vdda related function out of eDP/DP controller
Kuogee Hsieh (3):
phy: qcom-edp: add regulator_set_load to edp phy
phy: qcom-qmp: add regulator_set_load to dp phy
drm/msm/dp: delete vdda regulator related f
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/q
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 40 -
1 file changed, 31 insertions(+), 9 deletions(-)
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Revi
1 - 100 of 131 matches
Mail list logo
