Hi Danilo,
kernel test robot noticed the following build errors:
[auto build test ERROR on b2139fb5051554a7f297e4ad584ef1bc26c76d5d]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-sched-implement-dynamic-job-flow-control/20231031-082915
base
Use GEM shmem for buffer management code;
Previously sent as RFC:
https://lore.kernel.org/dri-devel/20230901164842.178654-1-stanislaw.grus...@linux.intel.com/
Compared to RFC only changelog's were improved.
Jacek Lawrynowicz (4):
accel/ivpu: Allocate vpu_addr in gem->open() callback
accel/iv
From: Jacek Lawrynowicz
Use gem->open() callback to simplify the code and prepare for gem_shmem
conversion. It is called during handle creation for a gem object,
during prime import and in BO_CREATE ioctl. Hence can be used for vpu_addr
allocation. On the way remove unused bo->user_ptr field.
Si
From: Jacek Lawrynowicz
ivpu_bo_remove_all_bos_from_context() could race with ivpu_bo_free()
when prime buffer was closed after vpu device was closed.
Move the bo_list from context to vdev and use a dedicated lock to
sync it. This list is not modified when BO is added/removed from
a context.
Al
From: Jacek Lawrynowicz
Usages of DRM_IVPU_BO_UNCACHED should be replaced by DRM_IVPU_BO_WC.
There is no functional benefit from DRM_IVPU_BO_UNCACHED if these
buffers are never mapped to host VM.
This allows to cut the buffer handling code in the kernel driver
by half.
Usage of DRM_IVPU_BO_UNCA
From: Jacek Lawrynowicz
Use struct drm_gem_shmem_object as a base for struct ivpu_bo.
This cuts by 50% the buffer management code.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/Kconfig| 2 +-
drivers/accel/ivpu/ivpu_d
On Mon, 2023-10-30 at 18:00 +0800, Moudy Ho wrote:
> Add a compatible string for the PADDING block in MediaTek MT8195 that
> is controlled by MDP3.
>
> Signed-off-by: Moudy Ho
> ---
> .../bindings/display/mediatek/mediatek,padding.yaml | 4
> +++-
> 1 file changed, 3 insertions(+), 1 d
This is required to get the V3D module to load with Raspberry Pi 5.
Signed-off-by: Iago Toral Quiroga
Reviewed-by: Stefan Wahren
Reviewed-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3
BCM2712, Raspberry Pi 5's SoC, contains a V3D core. So add its specific
compatible to the bindings.
Signed-off-by: Iago Toral Quiroga
Reviewed-by: Maíra Canal
---
Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree
V3D 7.x takes a new parameter to configure TFU jobs that needs
to be provided by user space.
Signed-off-by: Iago Toral Quiroga
Reviewed-by: Maíra Canal
---
v2: added s-o-b, fixed typo in commit message (Maíra Canal)
include/uapi/drm/v3d_drm.h | 5 +
1 file changed, 5 insertions(+)
diff --
This series includes patches to update the V3D kernel module
that drives the VideoCore VI GPU in Raspberry Pi 4 to also support
the Video Core VII iteration present in Raspberry Pi 5.
The first patch in the series adds a small uAPI update required for
TFU jobs, the second patch addresses the bulk
This patch updates a number of register addresses that have
been changed in Raspberry Pi 5 (V3D 7.1) and updates the
code to use the corresponding registers and addresses based
on the actual V3D version.
Signed-off-by: Iago Toral Quiroga
Reviewed-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_debu
On Mon, 2023-10-30 at 14:26 -0500, Rob Herring wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
> On Mon, 30 Oct 2023 18:00:22 +0800, Moudy Ho wrote:
> > Add a compatible string for the PADDING block in MediaT
On Mon, 30 Oct 2023 at 21:52, Abhinav Kumar wrote:
>
>
>
> On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
> > As we have dropped the variadic parts of SSPP sub-blocks declarations,
> > deduplicate them now, reducing memory cruft.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > .../msm/disp/d
On Mon, 30 Oct 2023 at 22:24, Abhinav Kumar wrote:
>
>
>
> On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
> > Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
> > are all related to different versions of the same HW scaling block.
> > Corresponding driver parts use scaler_blk
On Mon, Oct 30, 2023 at 04:23:20PM -0700, Bjorn Andersson wrote:
> During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> typically take 1-2ms to complete. As expected this results in poor
> performance, something that has been mitigated by proposing running the
> iommu in non-stri
MT8195 RSZ inherited from MT8183, add the corresponding
compatible name to it.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/media/mediatek,mdp3-rsz.yaml| 6 +-
1 file changed, 5 insertions(+), 1 deletion(
To simplify maintenance and avoid branches, the identical component
should be merged and placed in the path belonging to the MDP
(from display/* to media/*).
In addition, currently only MDP utilizes RDMA through CMDQ, and the
necessary properties for "mediatek,gce-events", and "mboxes" have been
s
Added the configuration for MT8195 RDMA. In comparison to MT8183, it
no longer shares SRAM with RSZ, and there are now preconfigured 5 mbox.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
---
.../bindings/media/mediatek,mdp3-rdma.yaml| 21 +++
1 file change
Add the fundamental hardware configuration of component STITCH,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-stitch.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Docum
Add a compatible string for the PADDING block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
---
.../bindings/display/mediatek/mediatek,padding.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display
Add a compatible string for the AAL block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Acked-by: Conor Dooley
Reviewed-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
1 file changed, 1 insertion(+)
diff --gi
Add the fundamental hardware configuration of component TDSHP,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-tdshp.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Docume
Add a compatible string for the COLOR block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 +
1 file changed, 1 insertion(+)
Add a compatible string for the MERGE block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 1 +
1 file changed, 1 insertion(+)
Add compatible string and GCE property for MT8195 SPLIT, of
which is operated by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,split.yaml | 27 +++
1 file changed, 27 insertions(+)
The DMA-related nodes RDMA/WROT in MDP3 should be changed to generic names.
In addition, fix improper space indent in example.
Fixes: 4ad7b39623ab ("media: dt-binding: mediatek: add bindings for MediaTek
MDP3 components")
Signed-off-by: Moudy Ho
Acked-by: Rob Herring
Reviewed-by: AngeloGioacchi
Add the fundamental hardware configuration of component TCC,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-tcc.yaml | 62 +++
1 file changed, 62 i
Changes since v8:
- Rebase on linux-next.
- Dependent dtsi files:
https://patchwork.kernel.org/project/linux-mediatek/list/?series=797543
- Depends on:
Message ID = 20231024130048.14749-9-shawn.s...@mediatek.com
- Following Rob's suggestion, the number of 'clocks' and 'mboxes' items are
restr
MT8195 WROT inherited from MT8183, add the corresponding
compatible name to it.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/media/mediatek,mdp3-wrot.yaml | 6 +-
1 file changed, 5 insertions(+), 1 deletion
Add a compatible string for the OVL block in MediaTek MT8195 that
is controlled by MDP3.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Acked-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
1 file changed, 1 insertion(+)
di
Add the fundamental hardware configuration of component FG,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-fg.yaml | 61 +++
1 file changed, 61 in
Add the fundamental hardware configuration of component HDR,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/media/mediatek,mdp3-hdr.yaml | 61 +++
1 file changed, 61 i
Hi Danilo,
kernel test robot noticed the following build errors:
[auto build test ERROR on b2139fb5051554a7f297e4ad584ef1bc26c76d5d]
url:
https://github.com/intel-lab-lkp/linux/commits/Danilo-Krummrich/drm-sched-implement-dynamic-job-flow-control/20231031-082915
base
On Tue, 2023-10-31 at 15:43 +0800, moudy ho wrote:
> On Mon, 2023-10-30 at 14:26 -0500, Rob Herring wrote:
> >
> > External email : Please do not click links or open attachments
> > until
> > you have verified the sender or the content.
> >
> > On Mon, 30 Oct 2023 18:00:22 +0800, Moudy Ho w
Il 30/10/23 15:57, Steven Price ha scritto:
On 30/10/2023 13:22, AngeloGioacchino Del Regno wrote:
Currently, the GPU is being internally powered off for runtime suspend
and turned back on for runtime resume through commands sent to it, but
note that the GPU doesn't need to be clocked during the
Il 30/10/23 15:57, Steven Price ha scritto:
On 30/10/2023 13:22, AngeloGioacchino Del Regno wrote:
Some platforms/SoCs can power off the GPU entirely by completely cutting
off power, greatly enhancing battery time during system suspend: add a
new pm_feature GPU_PM_VREG_OFF to allow turning off t
On Fri, 13 Oct 2023, Ville Syrjala wrote:
> entrirely. But perhaps a better idea would be to follow the
> OpenGL int<->float conversion rules, in which case we get
> the following results:
Do you have a pointer to the rules handy, I couldn't find it. :(
Might also add the reference to the commit
Hi Javier,
On Fri, Oct 27, 2023 at 11:33 AM Javier Martinez Canillas
wrote:
> Jocelyn Falempe writes:
> > On 21/10/2023 00:52, Javier Martinez Canillas wrote:
> >> Avoid a possible uninitialized use of the crtc_state variable in function
> >> ssd132x_primary_plane_atomic_check() and avoid the fo
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> Use drm_WARN() and drm_WARN_ON() variants to indicate drivers the
> context the failing VM resides in.
>
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/drm_gpuvm.c | 32 ++--
> --
> drivers/gpu
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Fri, Oct 27, 2023 at 11:33 AM Javier Martinez Canillas
> wrote:
>> Jocelyn Falempe writes:
>> > On 21/10/2023 00:52, Javier Martinez Canillas wrote:
>> >> Avoid a possible uninitialized use of the crtc_state variable in function
>> >>
v2 of https://patchwork.freedesktop.org/series/123384/
Jani Nikula (6):
drm/edid: split out drm_eld.h from drm_edid.h
drm/eld: replace uint8_t with u8
drm/edid: include drm_eld.h only where required
drm/edid: use a temp variable for sads to drop one level of
dereferences
drm/edid: ad
The drm_edid.[ch] files are starting to be a bit crowded, and with plans
to add more ELD related functionality, it's perhaps cleanest to split
the ELD code out to a header of its own.
Include drm_eld.h from drm_edid.h for starters, and leave it to
follow-up work to only include drm_eld.h where nee
Reduce the dependencies on drm_eld.h. Some files might be able to drop
the dependency on drm_edid.h too with the direct inclusion of drm_eld.h.
Cc: Mitul Golani
Reviewed-by: Mitul Golani
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 1 +
drivers/gpu/drm/
Add helpers to pack/unpack SADs. Both ways and non-static, as follow-up
work needs them.
v2: Add include to get the declarations
Cc: Mitul Golani
Reviewed-by: Mitul Golani
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 34 +-
drivers/gpu/drm/dr
Occasionally it's necessary for drivers to modify the SADs of an ELD,
but it's not so cool to have drivers poke at the ELD buffer directly.
Using the helpers to translate between 3-byte SAD and struct cea_sad,
add ELD helpers to get/set the SADs from/to an ELD.
v2: s/i/sad_index/ (Mitul)
Cc: Mit
Unify on kernel types.
Cc: Mitul Golani
Reviewed-by: Chaitanya Kumar Borah
Reviewed-by: Mitul Golani
Signed-off-by: Jani Nikula
---
include/drm/drm_eld.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/drm/drm_eld.h b/include/drm/drm_eld.h
index 9bde
Use a temporary variable struct cea_sad *, instead of using struct
cea_sad ** directly with the double dereferences. It's arguably easier
on the eyes, and drops a set of parenthesis too.
Cc: Mitul Golani
Reviewed-by: Mitul Golani
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 16 +
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, October 31, 2023 3:47 PM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; Golani, Mitulkumar Ajitkumar
> ; Nikula, Jani
>
> Subject: [PATCH v2 6/6] drm/eld: add helpers to modify the SADs of an ELD
>
Hi Javier,
On Tue, Oct 31, 2023 at 11:11 AM Javier Martinez Canillas
wrote:
> Geert Uytterhoeven writes:
> > On Fri, Oct 27, 2023 at 11:33 AM Javier Martinez Canillas
> > wrote:
> >> Jocelyn Falempe writes:
> >> > On 21/10/2023 00:52, Javier Martinez Canillas wrote:
> >> >> Avoid a possible un
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> Add an abstraction layer between the drm_gpuva mappings of a
> particular
> drm_gem_object and this GEM object itself. The abstraction represents
> a
> combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> holds
> a list of
Il 31/10/23 09:59, AngeloGioacchino Del Regno ha scritto:
Il 30/10/23 15:57, Steven Price ha scritto:
On 30/10/2023 13:22, AngeloGioacchino Del Regno wrote:
Currently, the GPU is being internally powered off for runtime suspend
and turned back on for runtime resume through commands sent to it,
Hi Jan,
On 31/10/2023 08:24, Jan Kiszka wrote:
On 30.10.23 20:28, Aradhya Bhatia wrote:
With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
rely on format negotiation to setup the encoder format.
Add th
This is now merged to gt-next
Thanks,
Nirmoy
On 10/18/2023 4:04 PM, Nirmoy Das wrote:
On 10/18/2023 3:00 PM, Andi Shyti wrote:
Hi Nirmoy,
gen8_ggtt_invalidate() is only needed for limited set of platforms
where GGTT is mapped as WC. This was added as way to fix WC based
GGTT in
commit 0
Am 31.10.23 um 01:26 schrieb Danilo Krummrich:
Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler is initialized with a credit
limit that corresponds to the number of jobs which can be sent to the
hardware.
This implies that for
On 28.09.2023 13:16, Dmitry Baryshkov wrote:
> Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
>
> Signed-off-by: Dmitry Baryshkov
> ---
I only have a few style comments (and timers-howto.txt fixes)
[...]
> +#define HDMI_8974_VCO_MAX_FREQ 18UL
> +#define HDMI_8974_VCO_
On 28.09.2023 13:16, Dmitry Baryshkov wrote:
> Add support for HDMI PHY on Qualcomm MSM8x60 / APQ8060 platforms.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Do you have the PLL working locally? Would it make sense to ship them both?
Konrad
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> Add an abstraction layer between the drm_gpuva mappings of a
> particular
> drm_gem_object and this GEM object itself. The abstraction represents
> a
> combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> holds
> a list of
Geert Uytterhoeven writes:
> Hi Javier,
[...]
>> >> Pushed to drm-misc (drm-misc-next). Thanks!
>> >
>> > Looks like you introduced an unintended
>> >
>> > (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948)
>> >
>> > ?
>> >
>>
>> No, that's intended. It's added by the `dim
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> Currently the DRM GPUVM offers common infrastructure to track GPU VA
> allocations and mappings, generically connect GPU VA mappings to
> their
> backing buffers and perform more complex mapping operations on the
> GPU VA
> space.
>
> Ho
On Tue, 31 Oct 2023, Thomas Hellström wrote:
> On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
>> + * Returns: a pointer to the &drm_gpuvm_bo on success, NULL on
>
> Still needs s/Returns:/Return:/g
FWIW, both work to accommodate the variance across the kernel, although
I think only th
On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote:
> Geert Uytterhoeven writes:
>
> > Hi Javier,
>
> [...]
>
> >> >> Pushed to drm-misc (drm-misc-next). Thanks!
> >> >
> >> > Looks like you introduced an unintended
> >> >
> >> > (cherry picked from commit 9e4db199e66d
Hi,
On 31.10.2023 00:03, Mario Marietto wrote:
> We are a team of linux enthusiasts who are trying to boot Xen on a
> Samsung XE303C12 Chromebook aka "snow" following the suggestions in
> the slide show presentation here:
> https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-n
Hi, Jaak and Evan,
On Sun, Oct 29, 2023 at 9:42 AM Huacai Chen wrote:
>
> On Sat, Oct 28, 2023 at 7:06 PM Jaak Ristioja wrote:
> >
> > On 26.10.23 03:58, Huacai Chen wrote:
> > > Hi, Jaak,
> > >
> > > On Thu, Oct 26, 2023 at 2:49 AM Jaak Ristioja wrote:
> > >>
> > >> On 25.10.23 16:23, Huacai C
On 31.10.23 11:53, Tomi Valkeinen wrote:
> Hi Jan,
>
> On 31/10/2023 08:24, Jan Kiszka wrote:
>> On 30.10.23 20:28, Aradhya Bhatia wrote:
>>> With new connector model, tc358767 will not create the connector, when
>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
>>> rely
On 10/31/23 12:13, Christian König wrote:
Am 31.10.23 um 01:26 schrieb Danilo Krummrich:
Currently, job flow control is implemented simply by limiting the number
of jobs in flight. Therefore, a scheduler is initialized with a credit
limit that corresponds to the number of jobs which can be sen
On Tue, Oct 31, 2023 at 01:42:17PM +0200, José Pekkarinen wrote:
> On 2023-10-31 07:48, Greg KH wrote:
> > On Mon, Oct 30, 2023 at 07:17:48PM +0200, José Pekkarinen wrote:
> > > This patch addresses the following warning spotted by
> > > using coccinelle where the case checked does the same
> > > t
On Mon, Oct 30, 2023 at 04:23:20PM -0700, Bjorn Andersson wrote:
> During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> typically take 1-2ms to complete. As expected this results in poor
> performance, something that has been mitigated by proposing running the
> iommu in non-stri
On Mon, 23 Oct 2023 22:16:46 +0200
Danilo Krummrich wrote:
> Currently GPUVM offers common infrastructure to track GPU VA allocations
> and mappings, generically connect GPU VA mappings to their backing
> buffers and perform more complex mapping operations on the GPU VA space.
>
> However, there
On Tue, Oct 31, 2023 at 1:19 AM Manivannan Sadhasivam
wrote:
>
> On Mon, Oct 30, 2023 at 04:23:20PM -0700, Bjorn Andersson wrote:
> > During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> > typically take 1-2ms to complete. As expected this results in poor
> > performance, someth
On Tue, Oct 31, 2023 at 5:35 AM Johan Hovold wrote:
>
> On Mon, Oct 30, 2023 at 04:23:20PM -0700, Bjorn Andersson wrote:
> > During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> > typically take 1-2ms to complete. As expected this results in poor
> > performance, something that
Hi Christian,
On 17.10.2023 14:10, Christian König wrote:
Am 17.10.23 um 14:06 schrieb Karolina Stolarek: >> Oh! Could you at least take
a look at ttm_bo_reserve_deadlock and/or
interrupted subtests? I'm not 100% sure if my solution is right.
Than this will have to wait till next week when I
On 2023-10-31 07:48, Greg KH wrote:
On Mon, Oct 30, 2023 at 07:17:48PM +0200, José Pekkarinen wrote:
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.
From: Tvrtko Ursulin
PVC support will not be coming to i915 so get rid of its partial
enablement and reduce the driver maintenance burden.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
drivers/gpu/
From: Tvrtko Ursulin
XeHP SDV was a pre-production hardware used to bring up PVC and was not
generally available and has since been decided will be supported in the
new xe driver and not i915.
v2:
* Correct historical fact SDV was for PVC, not ATS. (John)
Signed-off-by: Tvrtko Ursulin
Cc: Joh
Hi Maxime,
On Tue, Oct 31, 2023 at 12:53 PM Maxime Ripard wrote:
> On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote:
> > Geert Uytterhoeven writes:
> > >> >> Pushed to drm-misc (drm-misc-next). Thanks!
> > >> >
> > >> > Looks like you introduced an unintended
> > >> >
> >
Hi Alexey,
trying to answer some of the questions since Alex is currently on vacation.
Am 30.10.23 um 17:01 schrieb Alexey Klimov:
Hi Alex,
On Thu, 26 Oct 2023 at 19:53, Alex Deucher wrote:
On Thu, Oct 26, 2023 at 1:33 PM Alexey Klimov wrote:
#regzbot introduced: 1cfb4d612127
#regzbot titl
On 31/10/2023 14:18, Jan Kiszka wrote:
On 31.10.23 11:53, Tomi Valkeinen wrote:
Hi Jan,
On 31/10/2023 08:24, Jan Kiszka wrote:
On 30.10.23 20:28, Aradhya Bhatia wrote:
With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-cont
On 2023-10-31 14:20, Greg KH wrote:
On Tue, Oct 31, 2023 at 01:42:17PM +0200, José Pekkarinen wrote:
On 2023-10-31 07:48, Greg KH wrote:
> On Mon, Oct 30, 2023 at 07:17:48PM +0200, José Pekkarinen wrote:
> > This patch addresses the following warning spotted by
> > using coccinelle where the cas
Il 31/10/23 04:18, Chen-Yu Tsai ha scritto:
On Mon, Oct 30, 2023 at 9:23 PM AngeloGioacchino Del Regno
wrote:
Currently, the GPU is being internally powered off for runtime suspend
and turned back on for runtime resume through commands sent to it, but
note that the GPU doesn't need to be clock
Hi Danilo,
sorry for splitting up the mail thread. I had to fetch this mail from my
spam folder for some reason.
Am 30.10.23 um 18:56 schrieb Danilo Krummrich:
Hi Christian,
[SNIP]
And yes, we can live with the overhead of making jobs
slightly bigger than they actually are, thus potentially
discovery
drivers/gpu/drm/bridge/tc358767.c | 32
1 file changed, 32 insertions(+)
---
base-commit: 79d94360d50fcd487edcfe118a47a2881534923f
change-id: 20231031-tc358767-58e3ebdf95f0
Best regards,
--
Tomi Valkeinen
When a display controller driver uses DRM_BRIDGE_ATTACH_NO_CONNECTOR,
tc358767 will behave properly and skip the creation of the connector.
However, tc_get_display_props(), which is used to find out about the DP
monitor and link, is only called from two places: .atomic_enable() and
tc_connector_ge
From: Aradhya Bhatia
With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
rely on format negotiation to setup the encoder format.
Add the missing input-format negotiation hook in the
drm_bridge_funcs to co
On Tue, 31 Oct 2023 at 13:17, Konrad Dybcio wrote:
>
> On 28.09.2023 13:16, Dmitry Baryshkov wrote:
> > Add support for HDMI PHY on Qualcomm MSM8x60 / APQ8060 platforms.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> Do you have the PLL working locally? Would it make sense to ship them both?
On 10/26/23 19:25, Luben Tuikov wrote:
On 2023-10-26 12:39, Danilo Krummrich wrote:
On 10/23/23 05:22, Luben Tuikov wrote:
The GPU scheduler has now a variable number of run-queues, which are set up at
drm_sched_init() time. This way, each driver announces how many run-queues it
requires (sup
In Vulkan, it is the application's responsibility to perform adequate
synchronization before a sparse unmap, replace or BO destroy operation.
This adds an option to AMDGPU_VA_OPs to disable redundant implicit sync
that happens on sparse unmap or replace operations.
This has seen a significant impr
In short, eviction never really belonged to the vm_status state machine.
Even when evicted, the BO could belong to either the moved or done state.
The "evicted" state needed to handle both cases, causing greater confusion.
Additionally, there were inconsistencies in the definition of an evicted
BO
These are considered map operations rather than unmap, and there is no
point of doing implicit synchronization here.
Signed-off-by: Tatsuyuki Ishi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
For detection of the new explicit sync functionality without having to try
the ioctl.
Signed-off-by: Tatsuyuki Ishi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amd
In Vulkan, it is the application's responsibility to perform adequate
synchronization before a sparse unmap, replace or BO destroy operation.
Until now, the kernel applied the same rule as implicitly-synchronized
APIs like OpenGL, which with per-VM BOs made page table updates stall the
queue comple
All the state changes are handled in the TTM move callback; doing it again
here just leads to more confusion.
The table update remains here because it needs to be done exactly once,
while doing it in the move callback will result it getting triggered twice,
once by the actual BO and once by the sh
The current amdgpu_gem_va_update_vm only tries to perform updates for the
BO specified in the GEM ioctl; however, when a binding is split, the
adjacent bindings also need to be updated. Such updates currently ends up
getting deferred until next submission which causes stalls.
Introduce a new state
On Tue, Oct 31, 2023 at 02:00:06PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Tue, Oct 31, 2023 at 12:53 PM Maxime Ripard wrote:
> > On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote:
> > > Geert Uytterhoeven writes:
> > > >> >> Pushed to drm-misc (drm-misc-next)
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
In short, eviction never really belonged to the vm_status state machine.
I strongly disagree to that.
Even when evicted, the BO could belong to either the moved or done state.
The "evicted" state needed to handle both cases, causing greater confusi
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
The current amdgpu_gem_va_update_vm only tries to perform updates for the
BO specified in the GEM ioctl; however, when a binding is split, the
adjacent bindings also need to be updated. Such updates currently ends up
getting deferred until next submiss
On Tue, Oct 31, 2023 at 2:57 PM Christian König
wrote:
> Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
> > The current amdgpu_gem_va_update_vm only tries to perform updates for the
> > BO specified in the GEM ioctl; however, when a binding is split, the
> > adjacent bindings also need to be update
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
All the state changes are handled in the TTM move callback; doing it again
here just leads to more confusion.
The state move here is because we need to track which PDs/PTs are
already validated and which have new locations reflected in the PDEs.
W
On 10/31/2023 1:16 AM, Dmitry Baryshkov wrote:
On Mon, 30 Oct 2023 at 21:52, Abhinav Kumar wrote:
On 10/6/2023 6:14 AM, Dmitry Baryshkov wrote:
As we have dropped the variadic parts of SSPP sub-blocks declarations,
deduplicate them now, reducing memory cruft.
Signed-off-by: Dmitry Barys
Am 31.10.23 um 14:59 schrieb Bas Nieuwenhuizen:
On Tue, Oct 31, 2023 at 2:57 PM Christian König
wrote:
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
> The current amdgpu_gem_va_update_vm only tries to perform
updates for the
> BO specified in the GEM ioctl; however, when a bi
1 - 100 of 241 matches
Mail list logo
