t for really trivial structs.
But yeah I know it's a bit of work to shuffle stuff around, so maybe next
time ..
-Sima
> struct drm_sched_entity *current_entity;
> + struct list_headentities;
> struct rb_root_cached rb_tree_root;
> };
>
> --
> 2.46.0
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+ret = kstrtol(buf, 10, &val);
> >> +if (ret < 0)
> >> +return ret;
> >> +
> >> +if (val != 1 && val != 0 && val != -1) {
> >> +pr_err("Invalid value for gpu_recovery: %ld, excepted 0,1,-1\n",
> >> + val);
> >> +return -EINVAL;
> >> +}
> >> +
> >> +return param_set_int(buf, kp);
> >> +}
> >> +
> >> +static const struct kernel_param_ops amdgpu_gpu_recovery_ops = {
> >> +.set = amdgpu_set_gpu_recovery,
> >> +.get = param_get_int,
> >> +};
> >> +
> >> /**
> >>* DOC: gpu_recovery (int)
> >>* Set to enable GPU recovery mechanism (1 = enable, 0 = disable). The
> >> default is -1 (auto, disabled except SRIOV).
> >>*/
> >> MODULE_PARM_DESC(gpu_recovery, "Enable GPU recovery mechanism, (1 =
> >> enable, 0 = disable, -1 = auto)");
> >> -module_param_named(gpu_recovery, amdgpu_gpu_recovery, int, 0444);
> >> +module_param_cb(gpu_recovery, &amdgpu_gpu_recovery_ops,
> >> &amdgpu_gpu_recovery, 0644);
> >> /**
> >>* DOC: emu_mode (int)
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;
> Signed-off-by: Christian König
Acked-by: Simona Vetter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
&g
ottom (yeah some hw overscans and gets
pissed if there's not memory there). So I think it's best to go overboard
here with verbosity.
There's also really funny stuff like power-of-two alignment and things
like that, but I guess we'll get there if that's ever needed. That's also
why I think we don't need to add all possible linear modifiers from the
start, unless there's maybe too much confusion with stuff like "exactly
64b aligned pitch" and "at least 64b aligned pitch, but you can add lots
of padding if you feel like".
-""ma
>
> Regards,
> Lucas
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Dec 16, 2024 at 04:58:20PM -0500, Marek Olšák wrote:
> On Mon, Dec 16, 2024 at 9:53 AM Simona Vetter
> wrote:
>
> > On Mon, Dec 16, 2024 at 11:46:13AM +0100, Lucas Stach wrote:
> > > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > > &
quirements are generally implied. Mostly by stuff like tile size, but
there's others where the hw requirement flat out is that the buffer must
have a power-of-two stride (and maybe we should document these when they
pop up, but the only one I know of are the legacy i915 modifiers, which
are
On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
> On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
> > On Wed, Dec 18, 2024 at 11:24:58AM +0000, Simona Vetter wrote:
> > > For that reason I think linear modifiers with explicit pitch/size
> > > align
rucial part, because adding modifiers without
an actual use-case that they fix is just asking for more future trouble I
think.
-Sima
>
>
> --
> Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
> https://redhat.com \ Libre software enthusiast
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gt; modifiers and replace them with something that works.
I think Daniel's forward compatibility plan is more solid than trying to
deprecate LINEAR itself, that seems like too much an uphill battle to me.
-Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+
> .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 171
> drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 41 ++---
> drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c| 43 ++---
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 175
On Tue, Jan 21, 2025 at 02:21:57PM -0500, Marek Olšák wrote:
> On Mon, Jan 20, 2025 at 1:41 PM Simona Vetter
> wrote:
>
> > On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > >
> > > Am 18.01.25 um 03:37
/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c|2 +
> .../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c|2 +
> drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h |2 +
> drivers/gpu/drm/amd/include/amd_pcie.h | 18 +
> drivers/gpu/drm/amd/include/amd_shared.h |7 +-
> .../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_6_ppsmc.h |1 -
> drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h |3 +-
> drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h |1 +
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 286 ++-
> 40 files changed, 1743 insertions(+), 1400 deletions(-)
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
p.c | 13 +-
> .../drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c| 2 +
> .../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c| 2 +
> drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h | 2 +
> drivers/gpu/drm/amd/include/amd_shared.h | 2 +-
> .../amd/pm/swsmu/inc/pmf
re could be shared code that dtrt by
just looking at the modifier list.
-Sima
> Best regards
> Thomas
>
> >
> > Marek
> >
> > On Fri, Jan 17, 2025 at 9:18 AM Simona Vetter
> > wrote:
> >
> > On Wed, Jan 15, 2025 at 12:20:07PM +, Dan
reedom regarding placement. Drivers can expose
> > whatever they want within that definition, even exposing only 1 linear
> > modifier is OK. Then, you can look at modifiers of other drivers if you
> > want to find commonalities.
> >
> >
> > DRM_FORMAT_MOD_L
y can happen.
> I think I've just talked myself into the position that passing
> allocator constraints together with modifiers is the only way to
> actually solve this problem, at least without creating the sort of
> technical debt that meant we spent years fixing up implicit/explic
istian König
> Signed-off-by: Felix Kuehling
> Reviewed-by: Felix Kuehling
> Tested-by: Pak Nin Lui
> Cc: Simona Vetter
I thought the big reason we never did this was that there's no way to
account vram pinning properly, until now? But with the cgroup stuff
finally moving
MAP_USE(drm_dedbug_classes) to replace the
> > sprinkling of _USEs in drivers and helpers. IIRC, I tried adding a
> > _DEFINE into drm_drv.c, that didn't do it, so I punted for now.
> >
> > I think the dyndbg core additions are ready for review and merging
> > int
s/gpu/drm/radeon/atombios_dp.c | 8 +-
> include/drm/display/drm_dp_helper.h| 92 +-
> 12 files changed, 322 insertions(+), 315 deletions(-)
> ---
> base-commit: 565351ae7e0cee80e9b5ed84452a5b13644ffc4d
> change-id: 20241231-drm-rework-dpcd-access-b0fc2e47d613
>
> Best regards,
> --
> Dmitry Baryshkov
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
19 matches
Mail list logo
