Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16-rc3 next-20211203]
[cannot apply to airlied/drm-next]
[If your
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20211203]
[cannot apply to drm-intel/for-linux-next anholt/for-next v5.16-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Fri, Dec 03, 2021 at 04:28:56PM +0100, Thierry Reding wrote:
> On Fri, Dec 03, 2021 at 01:25:17AM -0800, Kees Cook wrote:
> > The link_status array was not large enough to read the Adjust Request
> > Post Cursor2 register. Adjust the size to include it. Found with a
> > -Warray-bounds build:
>
On Fri, Dec 03, 2021 at 11:28:00PM +0100, Michal Wajdeczko wrote:
>
>
> On 03.12.2021 19:33, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > Update to the latest GuC release.
> >
> > The latest GuC firmware introduces a number of interface changes:
>
> Why can't we review
gem_ctx_create.basic-files can slam on kernel contexts to the extent
where request creation fails because the ring is full. When this happens
seqno numbers are skipped which can result the below GEM_BUG_ON blowing
in gt/intel_engine_pm.c:__engine_unpark:
GEM_BUG_ON(ce->timeline->seqno !=
On 12/2/2021 6:41 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-11-09 13:38:13)
From: Kuogee Hsieh
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and
On 03.12.2021 19:33, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Update to the latest GuC release.
>
> The latest GuC firmware introduces a number of interface changes:
Why can't we review all these changes in smaller patches and squash them
in separate CI series *after*
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index d44f18b..91582d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++
> De: "Rodrigo Siqueira"
> Objet: [PATCH v2 5/6] Documentation/gpu: Add basic overview of DC pipeline
>
> This commit describes how DCN works by providing high-level diagrams
> with an explanation of each component. In particular, it details the
> Global Sync signals.
>
> Signed-off-by: Rodrigo
On Fri, Dec 03, 2021 at 10:33:36AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Lots of testing is done with the DEBUG_GEM config option enabled but
> not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
> which are not hugely useful. Enabling full DEBUG_GUC
On Fri, Dec 03, 2021 at 10:33:39AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> If the GuC fails to load, it is useful to know what firmware file /
> version was attempted. So move the version info report to before the
> load attempt rather than only after a successful load.
On 12/2/2021 4:33 PM, Lucas De Marchi wrote:
On Thu, Dec 02, 2021 at 04:06:23PM -0800, john.c.harri...@intel.com
wrote:
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't
On 03/12/2021 22:32, Ameer Hamza wrote:
Fixed coverity warning by removing the dead code
Addresses-Coverity: 1494147 ("Logically dead code")
Signed-off-by: Ameer Hamza
Reviewed-by: Dmitry Baryshkov
---
Changes in v2:
removed the 'fail' part completely by moving DPU_ERROR and return
On Wed, Dec 01, 2021 at 08:48:31PM -0800, Matthew Brost wrote:
> From: Dan Carpenter
>
> Originally "out_fence" was set using out_fence = sync_file_create() but
> which returns NULL, but now it is set with out_fence = eb_requests_create()
> which returns error pointers. The error path needs to
Hello:
This patch was applied to bpf/bpf.git (master)
by Alexei Starovoitov :
On Thu, 2 Dec 2021 12:34:00 -0800 you wrote:
> cgroup.h (therefore swap.h, therefore half of the universe)
> includes bpf.h which in turn includes module.h and slab.h.
> Since we're about to get rid of that dependency
On Fri, Dec 03, 2021 at 10:33:35AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained
On 22/10/2021 20:33, Bjorn Andersson wrote:
On Fri 22 Oct 04:43 PDT 2021, Vladimir Lypak wrote:
This GPU is found on SoCs such as MSM8953(650MHz), SDM450(600MHz),
SDM632(725MHz).
Signed-off-by: Vladimir Lypak
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 34 ++
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
From: John Harrison
If the GuC fails to load, it is useful to know what firmware file /
version was attempted. So move the version info report to before the
load attempt rather than only after a successful load.
If the GuC does fail to load, then make the error messages visible
rather than
From: John Harrison
Update to the latest GuC release.
The latest GuC firmware introduces a number of interface changes:
GuC may return NO_RESPONSE_RETRY message for requests sent over CTB.
Add support for this reply and try resending the request again as a
new CTB message.
A KLV
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
From: John Harrison
Update to the latest GuC version. This includes a suite of interface
changes and new features with corresponding i915 side changes.
Also, fix/improve a bunch of other things while at it.
Signed-off-by: John Harrison
John Harrison (5):
drm/i915/uc: Allow platforms to
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
---
On 03/12/2021 06:36, Yang Li wrote:
fix the following smatch warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1675 dpu_plane_init() warn:
'>mplane_list' not removed from list
Reported-by: Abaci Robot
Signed-off-by: Yang Li
Reviewed-by: Dmitry Baryshkov
---
On 03/12/2021 19:18, Ameer Hamza wrote:
Fixed coverity warning by removing the dead code
Addresses-Coverity: 1494147 ("Logically dead code")
Signed-off-by: Ameer Hamza
While the patch is correct, remove the 'fail' part completely by moving
DPU_ERROR and return statement in place of
On Fri, Dec 3, 2021 at 9:43 AM Thierry Reding wrote:
>
> From: Thierry Reding
>
> SPI panels need to reference the SPI peripheral properties so that they
> can be properly validated.
Thanks for doing this.
>
> Signed-off-by: Thierry Reding
> ---
>
On Fri, Dec 3, 2021 at 1:03 PM Michel Dänzer wrote:
>
> On 2021-12-03 16:58, Matthias Brugger wrote:
> > Hi Mark,
> >
> > On 02/12/2021 16:11, Mark Yacoub wrote:
> >> From: Mark Yacoub
> >>
> >
> > please make sure to add the linux-mediatek mailinglist in any follow-up
> > communication.
> >
>
gem_ctx_create.basic-files can slam on kernel contexts to the extent
where request creation fails because the ring is full. When this happens
seqno numbers are skipped which can result the below GEM_BUG_ON blowing
in gt/intel_engine_pm.c:__engine_unpark:
GEM_BUG_ON(ce->timeline->seqno !=
On 2021-12-03 at 17:31:11 +, Matthew Auld wrote:
> On 03/12/2021 16:59, Ramalingam C wrote:
> > On 2021-12-03 at 12:24:20 +, Matthew Auld wrote:
> > > If this is LMEM then we get a 32 entry PT, with each PTE pointing to
> > > some 64K block of memory, otherwise it's just the usual 512
On 03/12/2021 17:30, Ramalingam C wrote:
On 2021-12-03 at 12:24:22 +, Matthew Auld wrote:
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
So we didn't hit this issue because we were always using the
engine->instance 0!?
Yes, AFAIK.
Looks
On 03/12/2021 17:25, Ramalingam C wrote:
On 2021-12-03 at 12:24:21 +, Matthew Auld wrote:
With object clearing/copying we need to be able to modify the PTEs on
the fly via some batch buffer, which means we need to be able to map the
paging structures(or at the very least the PT, but being
On 2021-12-03 at 12:24:24 +, Matthew Auld wrote:
> Ensure we account for any object rounding due to min_page_size
> restrictions.
>
> Signed-off-by: Matthew Auld
Reviewed-by: Ramalingam C
> Cc: Thomas Hellström
> Cc: Ramalingam C
> ---
> drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 +
On 2021-12-03 at 12:24:23 +, Matthew Auld wrote:
> No need to insert PTEs for the PTE window itself, also foreach expects a
> length not an end offset, which could be gigantic here with a second
> engine.
>
Looks good to me
Reviewed-by: Ramalingam C
> Signed-off-by: Matthew Auld
> Cc:
On 03/12/2021 16:59, Ramalingam C wrote:
On 2021-12-03 at 12:24:20 +, Matthew Auld wrote:
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
On 2021-12-03 at 12:24:22 +, Matthew Auld wrote:
> Ensure we add the engine base only after we calculate the qword offset
> into the PTE window.
So we didn't hit this issue because we were always using the
engine->instance 0!?
Looks good to me
Reviewed-by: Ramalingam C
>
> Signed-off-by:
On 2021-12-03 at 12:24:21 +, Matthew Auld wrote:
> With object clearing/copying we need to be able to modify the PTEs on
> the fly via some batch buffer, which means we need to be able to map the
> paging structures(or at the very least the PT, but being able to also
> map the PD might also be
On 2021-12-03 at 12:24:20 +, Matthew Auld wrote:
> If this is LMEM then we get a 32 entry PT, with each PTE pointing to
> some 64K block of memory, otherwise it's just the usual 512 entry PT.
> This very much assumes the caller knows what they are doing.
>
> Signed-off-by: Matthew Auld
> Cc:
On 2021-12-03 at 12:24:19 +, Matthew Auld wrote:
> The scratch page might not be allocated in LMEM(like on DG2), so instead
> of using that as the deciding factor for where the paging structures
> live, let's just query the pt before mapping it.
>
Looks good to me.
Reviewed-by: Ramalingam C
On 12/3/21 13:08, Liviu Dudau wrote:
On Fri, Dec 03, 2021 at 10:28:15AM +, Steven Price wrote:
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
Hi Mark,
On 02/12/2021 16:11, Mark Yacoub wrote:
From: Mark Yacoub
please make sure to add the linux-mediatek mailinglist in any follow-up
communication.
Regards,
Matthias
[Why]
drm_handle_vblank_events loops over vblank_event_list to send any event
that is current or has passed.
More
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this and that seems to
work okay.
v2:
* Added
From: Thierry Reding
SPI panels need to reference the SPI peripheral properties so that they
can be properly validated.
Signed-off-by: Thierry Reding
---
.../devicetree/bindings/display/panel/lgphilips,lb035q02.yaml| 1 +
.../devicetree/bindings/display/panel/sony,acx565akm.yaml|
On Fri, Dec 03, 2021 at 01:25:17AM -0800, Kees Cook wrote:
> The link_status array was not large enough to read the Adjust Request
> Post Cursor2 register. Adjust the size to include it. Found with a
> -Warray-bounds build:
>
> drivers/gpu/drm/drm_dp_helper.c: In function
>
On 12/3/21 16:00, Christian König wrote:
Am 03.12.21 um 15:50 schrieb Thomas Hellström:
On 12/3/21 15:26, Christian König wrote:
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then
Hi,
On 03/12/2021 12:31, Tomi Valkeinen wrote:
> On 17/11/2021 16:19, Neil Armstrong wrote:
>> This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
>>
>> This patch series adds virtual-plane support to omapdrm driver to allow the
>> use
>> of display wider than 2048 pixels.
On 12/3/21 14:15, Carsten Haitzler wrote:
On 12/3/21 10:09, Liviu Dudau wrote:
If drm_universal_plane_init() fails early we jump to the common
cleanup code
that calls komeda_plane_destroy() which in turn could access the
uninitalised
drm_plane and crash. Return early if an error is detected
Am 03.12.21 um 15:50 schrieb Thomas Hellström:
On 12/3/21 15:26, Christian König wrote:
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then shows up in the dma_fence_chain representing
On 12/3/21 15:26, Christian König wrote:
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then shows up in the dma_fence_chain representing the whole
migration?
What we'd like to happen
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then shows up in the dma_fence_chain representing the whole
migration?
What we'd like to happen during eviction is that we
1) await any
On Fri, Dec 03, 2021 at 08:34:50PM +0800, Kevin Tang wrote:
> Maxime Ripard 于2021年12月3日周五 18:38写道：
> >
> > On Mon, Oct 25, 2021 at 05:34:18PM +0800, Kevin Tang wrote:
> > > @@ -618,9 +619,25 @@ static void sprd_crtc_mode_set_nofb(struct drm_crtc
> > > *crtc)
> > > {
> > > struct sprd_dpu
Convert the Silicon Image sii902x HDMI bridge Device Tree binding
documentation to json-schema.
Add missing sil,sii9022-cpi and sil,sii9022-tpi compatible values.
Signed-off-by: Geert Uytterhoeven
---
RFC as I do not know the meaning of the various ports subnodes.
v2:
- Rework
On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
> Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
> >
> > On 12/1/21 12:25, Christian König wrote:
> > > Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
> > > >
> > > > On 12/1/21 11:32, Christian König wrote:
> > > > > Am
On 12/3/21 10:09, Liviu Dudau wrote:
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected without going through
the common code.
On Mon, Nov 29, 2021 at 04:31:57PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard 於 2021年11月26日 週五 下午11:45寫道：
> >
> > On Fri, Nov 19, 2021 at 06:24:34PM +0800, Jian-Hong Pan wrote:
> > > Maxime Ripard 於 2021年11月18日 週四 下午6:40寫道：
> > > >
> > > > On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
been made, simplefb has been unregistered and the KMS driver is entirely
in charge of the display.
Thus, we can notify the firmware it can free whatever resource it was
using to maintain simplefb functional.
Signed-off-by:
The bind hooks will modify their controller registers, so simplefb is
going to be unusable anyway. Let's avoid any transient state where it
could still be in the system but no longer functionnal.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 8
1 file changed, 4
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the
firmware the kernel is in charge of the display now and the firmware can
free whatever resources it was using.
Signed-off-by: Maxime Ripard
---
include/soc/bcm2835/raspberrypi-firmware.h | 1 +
1 file changed, 1 insertion(+)
Hi,
The VC4 driver has had limited support to disable the HDMI controllers and
pixelvalves at boot if the firmware has enabled them.
However, this proved to be limited, and a bit unreliable so a new firmware
command has been introduced some time ago to make it free all its resources and
disable
Hi Nicolas,
On Tue, Nov 30, 2021 at 12:45:49PM +0100, nicolas saenz julienne wrote:
> On Wed, 2021-11-17 at 15:50 +0100, Maxime Ripard wrote:
> > The VC4 driver has had limited support to disable the HDMI controllers and
> > pixelvalves at boot if the firmware has enabled them.
> >
> > However,
Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
On 12/1/21 12:25, Christian König wrote:
Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
On 12/1/21 11:32, Christian König wrote:
Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
[SNIP]
What we could do is to avoid all
Il 03/12/21 14:14, Dmitry Baryshkov ha scritto:
On 03/12/2021 13:43, AngeloGioacchino Del Regno wrote:
Il 01/12/21 21:20, Dmitry Baryshkov ha scritto:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the
On 03/12/2021 13:43, AngeloGioacchino Del Regno wrote:
Il 01/12/21 21:20, Dmitry Baryshkov ha scritto:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the entire stack of components because they all depend
On Fri, Dec 03, 2021 at 10:28:15AM +, Steven Price wrote:
> While the check for format_count > 64 in __drm_universal_plane_init()
> shouldn't be hit (it's a WARN_ON), in its current position it will then
> leak the plane->format_types array and fail to call
> drm_mode_object_unregister()
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20211203]
[cannot apply to drm-intel/for-linux-next anholt/for-next v5.16-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Maxime Ripard 于2021年12月3日周五 18:38写道：
>
> On Mon, Oct 25, 2021 at 05:34:18PM +0800, Kevin Tang wrote:
> > @@ -618,9 +619,25 @@ static void sprd_crtc_mode_set_nofb(struct drm_crtc
> > *crtc)
> > {
> > struct sprd_dpu *dpu = to_sprd_crtc(crtc);
> > struct drm_display_mode *mode =
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index a804c57b61df..0da27ec808dc 100644
---
This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 186 +++-
No need to insert PTEs for the PTE window itself, also foreach expects a
length not an end offset, which could be gigantic here with a second
engine.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
1 file changed, 1
Ensure we account for any object rounding due to min_page_size
restrictions.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
With object clearing/copying we need to be able to modify the PTEs on
the fly via some batch buffer, which means we need to be able to map the
paging structures(or at the very least the PT, but being able to also
map the PD might also be useful at some point) into the GTT. And since
the paging
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
The scratch page might not be allocated in LMEM(like on DG2), so instead
of using that as the deciding factor for where the paging structures
live, let's just query the pt before mapping it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
Enable accelerated moves and clearing on DG2. On such HW we have minimum page
size restrictions when accessing LMEM from the GTT, where we now have to use 64K
GTT pages or larger. With the ppGTT the page-table also has a slightly different
layout from past generations when using the 64K GTT
The Renesas RZ/G2{L, LC} SoC (a.k.a R9A07G044) has a Bifrost Mali-G31 GPU,
add a compatible string for it.
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
---
.../bindings/gpu/arm,mali-bifrost.yaml| 32 +--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git
RZ/G2L SoC embeds Mali-G31 bifrost GPU.
This patch series aims to add support for the same
It is tested with latest drm-misc-next + mesa21.3.0 +
out of tree patch for (du + DSI) + mesa configurtion for RZ/G2L.
Tested the kmscube application.
test logs:-
root@smarc-rzg2l:~# kmscube
Using
On 17/11/2021 16:19, Neil Armstrong wrote:
This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
This patch series adds virtual-plane support to omapdrm driver to allow the use
of display wider than 2048 pixels.
In order to do so we introduce the concept of hw_overlay which
Sorry for the late reply.
On 11/21/21 12:47, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker speaking.
>
> On 16.11.21 05:52, Harald Dunkel wrote:
>>
>> if I enable CONFIG_SYSFB_SIMPLEFB in 5.15.2 and use grub's default
>> configuration
>> (Debian sid amd64), then a
When using the modes that need the highest pixel rate we support (such
as 4k at 60Hz), using a 10 or 12 bpc output will put us over the limit
of what we can achieve.
In such a case, let's force our output to be YUV422 so that we can go
back down under the required clock rate.
Signed-off-by:
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 | 133
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
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
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
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
---
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
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
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
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
---
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
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
Il 01/12/21 21:20, Dmitry Baryshkov ha scritto:
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the entire stack of components because they all depend on interrupts
coming from the main `mdss` node (mdp5, or
On 25.11.21 13:00, Thorsten Leemhuis wrote:
> On 21.11.21 12:47, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker speaking.
> /me again
and again :-D
>> On 16.11.21 05:52, Harald Dunkel wrote:
>>>
>>> if I enable CONFIG_SYSFB_SIMPLEFB in 5.15.2 and use grub's default
On Mon, Oct 25, 2021 at 05:34:18PM +0800, Kevin Tang wrote:
> @@ -618,9 +619,25 @@ static void sprd_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> {
> struct sprd_dpu *dpu = to_sprd_crtc(crtc);
> struct drm_display_mode *mode = >state->adjusted_mode;
> + struct drm_encoder
1 - 100 of 121 matches
Mail list logo
