Re: [Intel-gfx] [drm-rerere PATCH] nightly.conf: drop amd branches from drm-tip
[AMD Public Use] > -Original Message- > From: Jani Nikula > Sent: Wednesday, May 19, 2021 4:50 AM > To: dim-to...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; > jani.nik...@intel.com; Deucher, Alexander > ; Koenig, Christian > ; Pan; Pan, Xinhui ; > Daniel Vetter > Subject: [drm-rerere PATCH] nightly.conf: drop amd branches from drm-tip > > We've had a stale repo for amd in drm-tip since around v4.15 i.e. for more > than three years. Nobody seems to notice or care. Drop the amd branches > from drm-tip. > > Having the current amd branches in drm-tip would be nice to have, if only to > have a common drm integration tree. However, maintaining that has a cost > due to the inevitable conflicts. We can add the branches back if and when > there's interest in sharing the burden. > > Cc: Alex Deucher > Cc: Christian König > Cc: Pan, Xinhui > Cc: Daniel Vetter > Signed-off-by: Jani Nikula Reviewed-by: Alex Deucher > --- > nightly.conf | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/nightly.conf b/nightly.conf index 9211550ef75c..35fb1d9ba600 > 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -40,12 +40,6 @@ git://anongit.freedesktop.org/drm-misc > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > misc&data=04%7C01%7Calexander.deucher%40amd.com%7C5903896cf > 2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7 > C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am > p;sdata=espN%2BoIX9SjLh2Py%2FkqlVsi0p9Ru%2Fet2M11XWqJ5eUQ%3D&a > mp;reserved=0 > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > misc.git&data=04%7C01%7Calexander.deucher%40amd.com%7C590389 > 6cf2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0 > %7C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=E5cwRH0Pr9JkIfIMNkNzjlLn5hN6k0inxBkk%2Bwhd1lk%3D&r > eserved=0 > " > -drm_tip_repos[drm-amd]=" > -ssh://git.freedesktop.org/git/drm/drm-amd > -git://anongit.freedesktop.org/drm/drm-amd > - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > amd&data=04%7C01%7Calexander.deucher%40amd.com%7C5903896cf > 2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7 > C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am > p;sdata=1kQe4t89CyANqRhNUpQ2RP3Ndz7A3sdd%2FiWZ7FmKHM4%3D&a > mp;reserved=0 > - > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fano > ngit.freedesktop.org%2Fgit%2Fdrm%2Fdrm- > amd.git&data=04%7C01%7Calexander.deucher%40amd.com%7C590389 > 6cf2e642afb05408d91aa30f6d%7C3dd8961fe4884e608e11a82d994e183d%7C0 > %7C0%7C637570109906926805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=vVqMWMbdJFHJW8j09tn1m7ItGSL0RmfeDbJZFWoYBf4%3D&am > p;reserved=0 > -" > drm_tip_repos[drm]=" > ssh://git.freedesktop.org/git/drm/drm > git://anongit.freedesktop.org/drm/drm > @@ -76,17 +70,14 @@ drm_tip_config=( > "drmdrm-fixes" > "drm-misc drm-misc-fixes" > "drm-intel drm-intel-fixes" > - "drm-amddrm-amd-fixes" > > "drmdrm-next" > "drm-misc drm-misc-next-fixes" > "drm-intel drm-intel-next-fixes" > - "drm-amddrm-amd-next-fixes" > > "drm-misc drm-misc-next" > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > - "drm-amddrm-amd-next" > > "sound-upstream for-linus" > "sound-upstream for-next" > -- > 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/20] drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()
[AMD Official Use Only - Internal Distribution Only]
I'm fine with having these changes go through drm-misc.
Alex
From: Lipski, Mikita
Sent: Wednesday, April 21, 2021 10:23 AM
To: Lyude Paul ; dri-de...@lists.freedesktop.org
; intel-gfx@lists.freedesktop.org
; nouv...@lists.freedesktop.org
; amd-...@lists.freedesktop.org
; Ville Syrjälä ;
Jani Nikula ; Rodrigo Vivi
; Thomas Zimmermann ; Thierry
Reding
Cc: Wang, Chao-kai (Stylon) ; Lipski, Mikita
; Park, Chris ; Brol, Eryk
; Li, Sun peng (Leo) ; Lakha,
Bhawanpreet ; Lin, Wayne ;
Siqueira, Rodrigo ; open list
; Kazlauskas, Nicholas
; Somasundaram, Meenakshikumar
; David Airlie ; Pillai,
Aurabindo ; Daniel Vetter ; Bas
Nieuwenhuizen ; Deucher, Alexander
; Cornij, Nikola ; Wentland,
Harry ; Koenig, Christian
Subject: Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to
amdgpu_dm_initialize_dp_connector()
Thanks for the change!
Reviewed-by: Mikita Lipski
On 2021-04-19 6:55 p.m., Lyude Paul wrote:
> While working on moving i2c device registration into drm_dp_aux_init() - I
> realized that in order to do so we need to make sure that drivers calling
> drm_dp_aux_init() handle any errors it could possibly return. In the
> process of doing that, I noticed that the majority of AMD's code for DP
> connector creation doesn't attempt to do any real error handling.
>
> So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
> while we're at it. This way we can handle the error codes from
> drm_dp_aux_init().
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++-
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 44 +++
> .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 6 +--
> 3 files changed, 45 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a0c8c41e4e57..fc5d315bbb05 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7608,10 +7608,9 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>aconnector->i2c = i2c;
>res = i2c_add_adapter(&i2c->base);
> -
>if (res) {
>DRM_ERROR("Failed to register hw i2c %d\n", link->link_index);
> - goto out_free;
> + goto fail_free;
>}
>
>connector_type = to_drm_connector_type(link->connector_signal);
> @@ -7625,8 +7624,7 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>if (res) {
>DRM_ERROR("connector_init failed\n");
> - aconnector->connector_id = -1;
> - goto out_free;
> + goto fail_id;
>}
>
>drm_connector_helper_add(
> @@ -7643,15 +7641,22 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>drm_connector_attach_encoder(
>&aconnector->base, &aencoder->base);
>
> - if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
> - || connector_type == DRM_MODE_CONNECTOR_eDP)
> - amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> -
> -out_free:
> - if (res) {
> - kfree(i2c);
> - aconnector->i2c = NULL;
> + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP) {
> + res = amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> + if (res)
> + goto fail_cleanup;
>}
> +
> + return 0;
> +fail_cleanup:
> + drm_connector_cleanup(&aconnector->base);
> +fail_id:
> + aconnector->connector_id = -1;
> +fail_free:
> + kfree(i2c);
> + aconnector->i2c = NULL;
> +
>return res;
> }
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 73cdb9fe981a..3dee9cce9c9e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -425,33 +425,39 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs
> = {
>.add_connector = dm_dp_add_mst_connector,
> };
>
> -void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
> -struct amdgpu_dm_connector *aconnector,
> -int link_index
Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem
> -Original Message- > From: Wentland, Harry > Sent: Wednesday, September 11, 2019 8:16 PM > To: Ramalingam C ; intel- > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > daniel.vet...@intel.com > Cc: gwan-gyeong@intel.com; Kumar, Ranjeet > ; Deucher, Alexander > ; Lakha, Bhawanpreet > > Subject: Re: [PATCH v7 04/11] drm: revocation check at drm subsystem > > Adding a couple AMD guys. > > I know this is already merged but I have a few questions after some internal > discussions. > > On 2019-05-07 12:27 p.m., Ramalingam C wrote: > > On every hdcp revocation check request SRM is read from fw file > > /lib/firmware/display_hdcp_srm.bin > > > > According to section 5 of the HDCP 2.3 spec [1] a device compliant with HDCP > 2.0 and higher must be capable of storing and updating the SRM in non- > volatile memory. Section 5.2 describes how this SRM needs to be updated > when a new version is served alongside protected content. > > Isn't /lib/firmware intended for static firmware making updates to the folder > problematic for anyone but the system's package maintainer? I've heard /lib > might even be treated as read-only in certain environments. > This would mean it'd be impossible to support HDCP 2.x on those systems. > > Wouldn't it be easier to provide a sysfs entry for SRM that allows userspace > (e.g. system startup/shutdown scripts) to (a) retrieve the SRM from the > HDCP implementation for non-volatile storage and (b) to pass the SRM to the > HDCP implementation for revocation checking? Also, IIRC, for level 1 support, I think the srm parsing has to happen on something other than the CPU, so I'm not sure where need to do any parsing in software, at least for HDCP 2.x. Alex > > [1] > https://www.digital- > cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_ > 3.pdf > > Thanks, > Harry > > > SRM table is parsed and stored at drm_hdcp.c, with functions exported > > for the services for revocation check from drivers (which implements > > the HDCP authentication) > > > > This patch handles the HDCP1.4 and 2.2 versions of SRM table. > > > > v2: > > moved the uAPI to request_firmware_direct() [Daniel] > > v3: > > kdoc added. [Daniel] > > srm_header unified and bit field definitions are removed. [Daniel] > > locking improved. [Daniel] > > vrl length violation is fixed. [Daniel] > > v4: > > s/__swab16/be16_to_cpu [Daniel] > > be24_to_cpu is done through a global func [Daniel] > > Unused variables are removed. [Daniel] > > unchecked return values are dropped from static funcs [Daniel] > > > > Signed-off-by: Ramalingam C > > Acked-by: Satyeshwar Singh > > Reviewed-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms-helpers.rst | 6 + > > drivers/gpu/drm/Makefile | 2 +- > > drivers/gpu/drm/drm_hdcp.c| 333 > ++ > > drivers/gpu/drm/drm_internal.h| 4 + > > drivers/gpu/drm/drm_sysfs.c | 2 + > > include/drm/drm_hdcp.h| 24 ++ > > 6 files changed, 370 insertions(+), 1 deletion(-) create mode 100644 > > drivers/gpu/drm/drm_hdcp.c > > > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > > b/Documentation/gpu/drm-kms-helpers.rst > > index 14102ae035dc..0fe726a6ee67 100644 > > --- a/Documentation/gpu/drm-kms-helpers.rst > > +++ b/Documentation/gpu/drm-kms-helpers.rst > > @@ -181,6 +181,12 @@ Panel Helper Reference .. kernel-doc:: > > drivers/gpu/drm/drm_panel_orientation_quirks.c > > :export: > > > > +HDCP Helper Functions Reference > > +=== > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c > > + :export: > > + > > Display Port Helper Functions Reference > > === > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index > > 72f5036d9bfa..dd02e9dec810 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \ > > drm_plane.o drm_color_mgmt.o drm_print.o \ > > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ > > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ > > - drm_atomic_uapi.o > > + drm_atomic_uapi.o drm_hdcp.o > > > > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o > > drm_context.o drm_dma.o drm_scatter.o drm_lock.
Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.
Acked-by: Alex Deucher
From: Hans Verkuil
Sent: Thursday, August 22, 2019 4:08 AM
To: Dariusz Marcinkiewicz ; dri-de...@lists.freedesktop.org
; linux-me...@vger.kernel.org
Cc: David Airlie ; nouv...@lists.freedesktop.org
; Dhinakaran Pandiyan
; Koo, Anthony ; Francis,
David ; amd-...@lists.freedesktop.org
; Zuo, Jerry ; Ben Skeggs
; Li, Sun peng (Leo) ;
intel-gfx@lists.freedesktop.org ; Maxime
Ripard ; Rodrigo Vivi ; Sean Paul
; Thomas Lim ;
linux-ker...@vger.kernel.org ; Manasi Navare
; Deucher, Alexander ;
Koenig, Christian ; Ville Syrjälä
Subject: Re: [PATCH v7 1/9] drm_dp_cec: add connector info support.
Alex, Ville/Rodrigo, Ben,
Can you (hopefully) Ack this patch so that I can merge it?
Thank you!
Hans
On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Hans Verkuil
> ---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 25 ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
> include/drm/drm_dp_helper.h | 17 ++---
> 5 files changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 16218a202b591..5ec14efd4d8cb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
>drm_dp_aux_register(&aconnector->dm_dp_aux.aux);
>drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> - aconnector->base.name, dm->adev->dev);
> + &aconnector->base);
>aconnector->mst_mgr.cbs = &dm_mst_cbs;
>drm_dp_mst_topology_mgr_init(
>&aconnector->mst_mgr,
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b15cee85b702b..b457c16c3a8bb 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,7 +8,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> /*
> @@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct
> work_struct *work)
> */
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> {
> - u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
> + struct drm_connector *connector = aux->cec.connector;
> + u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> +CEC_CAP_CONNECTOR_INFO;
> + struct cec_connector_info conn_info;
>unsigned int num_las = 1;
>u8 cap;
>
> @@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>
>/* Create a new adapter */
>aux->cec.adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
> - aux, aux->cec.name, cec_caps,
> + aux, connector->name, cec_caps,
> num_las);
>if (IS_ERR(aux->cec.adap)) {
>aux->cec.adap = NULL;
>goto unlock;
>}
> - if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
> +
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> + cec_s_conn_info(aux->cec.adap, &conn_info);
> +
> + if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
>cec_delete_adapter(aux->cec.adap);
>aux->cec.adap = NULL;
>} else {
> @@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> /**
> * drm_dp_cec_register_connector() - register a new connector
> * @aux: DisplayPort AUX channel
> - * @name: name of the CEC device
> - * @parent: parent device
> + * @connector: drm connector
> *
> * A new connector was registered with associated CEC adapter name and
> * CEC adapter parent device. After registering the name and parent
> * drm_dp_cec_set_edid() is called to check if the connector supports
> * CEC and to register a CEC adapter if that is the case.
> */
> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
> -
Re: [Intel-gfx] [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
[AMD Public Use]
> -Original Message-
> From: amd-gfx On Behalf Of
> Daniel Vetter
> Sent: Monday, September 7, 2020 3:15 AM
> To: Jan Kiszka ; amd-gfx list g...@lists.freedesktop.org>; Wentland, Harry ;
> Kazlauskas, Nicholas
> Cc: dri-devel ; intel-gfx g...@lists.freedesktop.org>; Thomas Zimmermann
> ; Ville Syrjala
> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
>
> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote:
> >
> > On 11.02.20 18:04, Daniel Vetter wrote:
> > > On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> > >> From: Ville Syrjälä
> > >>
> > >> WARN if the encoder possible_crtcs is effectively empty or contains
> > >> bits for non-existing crtcs.
> > >>
> > >> v2: Move to drm_mode_config_validate() (Daniel)
> > >> Make the docs say we WARN when this is wrong (Daniel)
> > >> Extract full_crtc_mask()
> > >>
> > >> Cc: Thomas Zimmermann
> > >> Cc: Daniel Vetter
> > >> Signed-off-by: Ville Syrjälä
> > >
> > > When pushing the fixup needs to be applied before the validation
> > > patch here, because we don't want to anger the bisect gods.
> > >
> > > Reviewed-by: Daniel Vetter
> > >
> > > I think with the fixup we should be good enough with the existing
> > > nonsense in drivers. Fingers crossed.
> > > -Daniel
> > >
> > >
> > >> ---
> > >> drivers/gpu/drm/drm_mode_config.c | 27
> ++-
> > >> include/drm/drm_encoder.h | 2 +-
> > >> 2 files changed, 27 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_mode_config.c
> > >> b/drivers/gpu/drm/drm_mode_config.c
> > >> index afc91447293a..4c1b350ddb95 100644
> > >> --- a/drivers/gpu/drm/drm_mode_config.c
> > >> +++ b/drivers/gpu/drm/drm_mode_config.c
> > >> @@ -581,6 +581,29 @@ static void
> validate_encoder_possible_clones(struct drm_encoder *encoder)
> > >> encoder->possible_clones, encoder_mask); }
> > >>
> > >> +static u32 full_crtc_mask(struct drm_device *dev) {
> > >> +struct drm_crtc *crtc;
> > >> +u32 crtc_mask = 0;
> > >> +
> > >> +drm_for_each_crtc(crtc, dev)
> > >> +crtc_mask |= drm_crtc_mask(crtc);
> > >> +
> > >> +return crtc_mask;
> > >> +}
> > >> +
> > >> +static void validate_encoder_possible_crtcs(struct drm_encoder
> > >> +*encoder) {
> > >> +u32 crtc_mask = full_crtc_mask(encoder->dev);
> > >> +
> > >> +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> > >> + (encoder->possible_crtcs & ~crtc_mask) != 0,
> > >> + "Bogus possible_crtcs: "
> > >> + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
> > >> + encoder->base.id, encoder->name,
> > >> + encoder->possible_crtcs, crtc_mask); }
> > >> +
> > >> void drm_mode_config_validate(struct drm_device *dev) {
> > >> struct drm_encoder *encoder;
> > >> @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
> drm_device *dev)
> > >> drm_for_each_encoder(encoder, dev)
> > >> fixup_encoder_possible_clones(encoder);
> > >>
> > >> -drm_for_each_encoder(encoder, dev)
> > >> +drm_for_each_encoder(encoder, dev) {
> > >> validate_encoder_possible_clones(encoder);
> > >> +validate_encoder_possible_crtcs(encoder);
> > >> +}
> > >> }
> > >> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> > >> index 3741963b9587..b236269f41ac 100644
> > >> --- a/include/drm/drm_encoder.h
> > >> +++ b/include/drm/drm_encoder.h
> > >> @@ -142,7 +142,7 @@ struct drm_encoder {
> > >> * the bits for all &drm_crtc objects this encoder can be connected
> > >> to
> > >> * before calling drm_dev_register().
> > >> *
> > >> - * In reality almost every driver gets this wrong.
> > >> + * You will get a WARN if you get this wrong in the driver.
> > >> *
> > >> * Note that since CRTC objects can't be hotplugged the assigned
> indices
> > >> * are stable and hence known before registering all objects.
> > >> --
> > >> 2.24.1
> > >>
> > >
> >
> > Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
>
> Adding amdgpu display folks.
I took a quick look at this and it looks like we limit the number of crtcs
later in the mode init process if the number of physical displays can't
actually use more crtcs. E.g., the physical board configuration would only
allow for 3 active displays even if the hardware technically supports 4 crtcs.
I presume that way we can just leave the additional hardware power gated all
the time.
Alex
> -Daniel
>
> >
> > [ 14.033246] [ cut here ]
> > [ 14.033248] Bogus possible_crtcs: [ENCODER:65:TMDS-65]
> possible_crtcs=0xf (full crtc mask=0x7)
> > [ 14.033279] WARNING: CPU: 0 PID: 282 at
> ../drivers/gpu/drm/drm_mode_config.c:622
> drm_mode_config_validate+0x17d/0x200 [drm]
> > [ 14.033279] Modules linked in: amdgpu(E+) mfd_core(E)
> snd_hda_codec_realtek(E) kvm_amd(E) gpu_sched(E) i2c_algo_bit(E) ttm(E)
> snd_hda_co
Re: [Intel-gfx] [PATCH 08/14] drm/amdgpu: Remove default best_encoder hook from DC
> -Original Message-
> From: Daniel Vetter
> Sent: Wednesday, September 5, 2018 9:48 AM
> To: Li, Sun peng (Leo)
> Cc: DRI Development ; Intel Graphics
> Development ; Daniel Vetter
> ; Deucher, Alexander
> ; Wentland, Harry
> ; Grodzovsky, Andrey
> ; Cheng, Tony ; S,
> Shirish
> Subject: Re: [PATCH 08/14] drm/amdgpu: Remove default best_encoder
> hook from DC
>
> On Wed, Sep 5, 2018 at 3:45 PM, Leo Li wrote:
> >
> >
> > On 2018-09-03 12:54 PM, Daniel Vetter wrote:
> >>
> >> For atomic driver this is the default, no need to reimplement it. We
> >> still need to keep the copypasta for not-atomic drivers though, since
> >> no one polished the legacy crtc helpers as much as the atomic ones.
> >
> >
> > Thanks for the patch! It seems I made an identical change here:
> > https://lists.freedesktop.org/archives/amd-gfx/2018-August/026064.html
> >
> > One line difference though. I wasn't aware that the default is used
> > when .best_encoder is null, so I just hooked it to the default helper.
> >
> > If it's OK with you, I'll do a follow-up to drop the hook, so we don't
> > have two conflicting patches in flight.
>
> I have a follow-up patches to unexport the helper, so would be good if Alex
> sends out the pull request so I can sort this all out in drm-misc-next. I
> don't
> want to split up the patch series if possible.
> Or we just deal with the conflict, it's minor.
>
> Alex?
I'm planning to send the PR next week when I'm back in the office. I can drop
Leo's patch when I send the PR if that makes things easier.
Alex
> -Daniel
>
> > Leo
> >
> >
> >>
> >> Signed-off-by: Daniel Vetter
> >> Cc: Alex Deucher
> >> Cc: Harry Wentland
> >> Cc: Andrey Grodzovsky
> >> Cc: Tony Cheng
> >> Cc: "Leo (Sunpeng) Li"
> >> Cc: Shirish S
> >> ---
> >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23
> ---
> >> 1 file changed, 23 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> index af6adffba788..333f9904f135 100644
> >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> >> @@ -2794,28 +2794,6 @@ static const struct drm_connector_funcs
> >> amdgpu_dm_connector_funcs = {
> >> .atomic_get_property =
> amdgpu_dm_connector_atomic_get_property
> >> };
> >> -static struct drm_encoder *best_encoder(struct drm_connector
> >> *connector)
> >> -{
> >> - int enc_id = connector->encoder_ids[0];
> >> - struct drm_mode_object *obj;
> >> - struct drm_encoder *encoder;
> >> -
> >> - DRM_DEBUG_DRIVER("Finding the best encoder\n");
> >> -
> >> - /* pick the encoder ids */
> >> - if (enc_id) {
> >> - obj = drm_mode_object_find(connector->dev, NULL, enc_id,
> >> DRM_MODE_OBJECT_ENCODER);
> >> - if (!obj) {
> >> - DRM_ERROR("Couldn't find a matching encoder for
> >> our connector\n");
> >> - return NULL;
> >> - }
> >> - encoder = obj_to_encoder(obj);
> >> - return encoder;
> >> - }
> >> - DRM_ERROR("No encoder id\n");
> >> - return NULL;
> >> -}
> >> -
> >> static int get_modes(struct drm_connector *connector)
> >> {
> >> return amdgpu_dm_connector_get_modes(connector);
> >> @@ -2934,7 +2912,6 @@ amdgpu_dm_connector_helper_funcs = {
> >> */
> >> .get_modes = get_modes,
> >> .mode_valid = amdgpu_dm_connector_mode_valid,
> >> - .best_encoder = best_encoder
> >> };
> >> static void dm_crtc_helper_disable(struct drm_crtc *crtc)
> >>
> >
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/core: Change declaration for gamma_set.
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, June 06, 2016 12:00 PM
> To: Maarten Lankhorst
> Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> Mathieu Larouche; VMware Graphics; Ben Skeggs; Deucher, Alexander;
> Thierry Reding; Koenig, Christian
> Subject: Re: [PATCH] drm/core: Change declaration for gamma_set.
>
> On Mon, Jun 06, 2016 at 11:18:09AM +0200, Maarten Lankhorst wrote:
> > Change return value to int to propagate errors from gamma_set,
> > and remove start parameter. Updates always use the full size,
> > and some drivers even ignore the start parameter altogether.
>
> Commit message should explain why we suddenly need to pass up the error
> code, too:
>
> "This is needed for atomic drivers, where an atomic commit can fail with
> EAGAIN and should be restarted."
>
> I'll add that when merging, but will wait for a bit more acks/r-b first.
Thanks. I was just about to ask why this was necessary. Patch is:
Acked-by: Alex Deucher
> -Daniel
> >
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: David Airlie
> > Cc: Patrik Jakobsson
> > Cc: Ben Skeggs
> > Cc: Eric Anholt
> > Cc: VMware Graphics
> > Cc: Mathieu Larouche
> > Cc: Thierry Reding
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 10 ++
> > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 10 ++
> > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 10 ++
> > drivers/gpu/drm/ast/ast_mode.c | 10 ++
> > drivers/gpu/drm/cirrus/cirrus_mode.c| 8 +---
> > drivers/gpu/drm/drm_atomic_helper.c | 13 ++---
> > drivers/gpu/drm/drm_crtc.c | 2 +-
> > drivers/gpu/drm/drm_fb_helper.c | 4 +---
> > drivers/gpu/drm/gma500/gma_display.c| 9 +
> > drivers/gpu/drm/gma500/gma_display.h| 4 ++--
> > drivers/gpu/drm/mgag200/mgag200_mode.c | 9 +
> > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 12 +++-
> > drivers/gpu/drm/nouveau/nv50_display.c | 9 +
> > drivers/gpu/drm/radeon/radeon_display.c | 11 +++
> > drivers/gpu/drm/vc4/vc4_crtc.c | 8 +---
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +---
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 ++--
> > include/drm/drm_atomic_helper.h | 6 +++---
> > include/drm/drm_crtc.h | 4 ++--
> > 19 files changed, 85 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > index 8227344d2ff6..16de862ea51f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > @@ -2667,19 +2667,21 @@ static void dce_v10_0_cursor_reset(struct
> drm_crtc *crtc)
> > }
> > }
> >
> > -static void dce_v10_0_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
> u16 *green,
> > - u16 *blue, uint32_t start, uint32_t size)
> > +static int dce_v10_0_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16
> *green,
> > + u16 *blue, uint32_t size)
> > {
> > struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
> > - int end = (start + size > 256) ? 256 : start + size, i;
> > + int i;
> >
> > /* userspace palettes are always correct as is */
> > - for (i = start; i < end; i++) {
> > + for (i = 0; i < size; i++) {
> > amdgpu_crtc->lut_r[i] = red[i] >> 6;
> > amdgpu_crtc->lut_g[i] = green[i] >> 6;
> > amdgpu_crtc->lut_b[i] = blue[i] >> 6;
> > }
> > dce_v10_0_crtc_load_lut(crtc);
> > +
> > + return 0;
> > }
> >
> > static void dce_v10_0_crtc_destroy(struct drm_crtc *crtc)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > index af26ec0bc59d..6e0ae8e2e65c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > @@ -2678,19 +2678,21 @@ static void dce_v11_0_cursor_reset(struct
> drm_crtc *crtc)
> > }
> > }
> >
> > -static void dce_v11_0_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
> u16 *green,
> > - u16 *blue, uint32_t start, uint32_t size)
> > +static int dce_v11_0_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16
> *green,
> > +
Re: [Intel-gfx] [PATCH v2] drm: Complete CEA modedb(VIC 1-107)
> -Original Message-
> From: Shashank Sharma [mailto:shashank.sha...@intel.com]
> Sent: Wednesday, November 02, 2016 5:46 AM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: airl...@redhat.com; daniel.vet...@intel.com;
> jose.ab...@synopsys.com; Shashank Sharma; Deucher, Alexander
> Subject: [PATCH v2] drm: Complete CEA modedb(VIC 1-107)
>
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using the existing techniques, we have
> to complete the modedb (VIC=65 onwards).
>
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
I don't have the spec in front of me to double check the timings, but assuming
the previous typos were addressed, the patch is:
Reviewed-by: Alex Deucher
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Sonika Jindal
> Reviewed-by: Jose Abreu
> Reviewed-by: Alex Deucher
>
> Cc: Jose Abreu
> Cc: Alex Deucher
>
> V2: Addressed review comments from Jose:
> - fix the timings for VIC 83, 90 and 91
> - fix formatting for VIC 93-107
> ---
> drivers/gpu/drm/drm_edid.c | 215
> +
> 1 file changed, 215 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9506933..d18602c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,221 @@ struct minimode {
> 2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 30, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 50, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 60, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 100, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280,
> 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 120, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio =
> HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920,
> 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125,
Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
Adding Harry and Tony from our display team to review. > -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Thursday, November 10, 2016 1:20 PM > To: Manasi Navare; dri-de...@lists.freedesktop.org; intel- > g...@lists.freedesktop.org > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during > modeset > > On Thu, 10 Nov 2016, Manasi Navare wrote: > > Link training failure is handled by lowering the link rate first > > until it reaches the minimum and keeping the lane count maximum > > and then lowering the lane count until it reaches minimim. These > > fallback values are saved and hotplug uevent is sent to the userspace > > after setting the connector link status property to BAD. Userspace > > should triiger another modeset on a uevent and if link status property > > is BAD. This will retrain the link at fallback values. > > This is repeated until the link is successfully trained. > > > > This has been validated to pass DP compliance. > > This cover letter and the commit messages do a good job of explaining > what the patches do. However, you're lacking the crucial information of > *why* we need userspace cooperation to handle link training failures on > DP mode setting, and *why* a new connector property is a good solution > for this. > > Here goes, including some alternative approaches we've considered (and > even tried): > > At the time userspace does setcrtc, we've already promised the mode > would work. The promise is based on the theoretical capabilities of the > link, but it's possible we can't reach this in practice. The DP spec > describes how the link should be reduced, but we can't reduce the link > below the requirements of the mode. Black screen follows. > > One idea would be to have setcrtc return a failure. However, it is my > understanding that it already should not fail as the atomic checks have > passed [citation needed]. It would also conflict with the idea of making > setcrtc asynchronous in the future, returning before the actual mode > setting and link training. > > Another idea is to train the link "upfront" at hotplug time, before > pruning the mode list, so that we can do the pruning based on practical > not theoretical capabilities. However, the changes for link training are > pretty drastic, all for the sake of error handling and DP compliance, > when the most common happy day scenario is the current approach of link > training at mode setting time, using the optimal parameters for the > mode. It is also not certain all hardware could do this without the pipe > on; not even all our hardware can do this. Some of this can be solved, > but not trivially. > > Both of the above ideas also fail to address link degradation *during* > operation. > > So the idea presented in these patches is to do this in a way that a) > changes the current happy day scenario as little as possible, to avoid > regressions, b) can be implemented the same way by all drm drivers, c) > is still opt-in for the drivers and userspace, and opting out doesn't > regress the user experience, d) doesn't prevent drivers from > implementing better or alternate approaches, possibly without userspace > involvement. And, of course, handles all the issues presented. > > The solution is to add a "link status" connector property. In the usual > happy day scenario, this is always "good". If something fails during or > after a mode set, the kernel driver can set the link status to "bad", > prune the mode list based on new information as necessary, and send a > hotplug uevent for userspace to have it re-check the valid modes through > getconnector, and try again. If the theoretical capabilities of the link > can't be reached, the mode list is trimmed based on that. > > If the userspace is not aware of the property, the user experience is > the same as it currently is. If the userspace is aware of the property, > it has a chance to improve user experience. If a drm driver does not > modify the property (it stays "good"), the user experience is the same > as it currently is. A drm driver can also choose to try to handle more > of the failures in kernel, hardware not limiting, or it can choose to > involve userspace more. Up to the drivers. > > The reason for adding the property is to handle link training failures, > but it is not limited to DP or link training. For example, if we > implement asynchronous setcrtc, we can use this to report any failures > in that. > > Finally, while DP CTS compliance is advertized (which is great, a
Re: [Intel-gfx] [PATCH v5 10/12] drm/i915: Defer probe if gmux is present but its driver isn't
> -Original Message- > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Thursday, February 18, 2016 6:11 PM > To: Lukas Wunner > Cc: dri-devel; platform-driver-...@vger.kernel.org; intel-gfx; Ben Skeggs; > Deucher, Alexander > Subject: Re: [PATCH v5 10/12] drm/i915: Defer probe if gmux is present but > its driver isn't > > On Thu, Feb 18, 2016 at 11:20 PM, Lukas Wunner wrote: > > Hi, > > > > On Thu, Feb 18, 2016 at 10:39:05PM +0100, Daniel Vetter wrote: > >> On Thu, Feb 18, 2016 at 9:34 PM, Lukas Wunner > wrote: > >> > > >> >> Ok, makes sense. I still think adding the check to the client_register > >> >> function would be good, just as a safety measure. > >> > > >> > Hm, the idea of calling vga_switcheroo_client_probe_defer() twice > >> > causes me pain in the stomach. It's surprising for drivers which > >> > just don't need it at the moment (amdgpu and snd_hda_intel) and > >> > it feels like overengineering and pampering driver developers > >> > beyond reasonable measure. Also while the single existing check is > >> > cheap, we might later on add checks that take more time and slow > >> > things down. > >> > >> It's motivated by Rusty's API Manifesto: > >> > >> http://sweng.the-davies.net/Home/rustys-api-design-manifesto > > > > Interesting, thank you. > > > > > >> With the mandatory check in _register we reach level 5 - it'll blow up > >> at runtime when we try to register it. > > > > The manifesto says "5. Do it right or it will always break at runtime". > > > > However even if we add a > WARN_ON(vga_switcheroo_client_probe_defer(pdev)) > > to register_client(), it will not *always* spew a stacktrace but only on > > the machines this concerns (MacBook Pros). Since failure to defer breaks > > GPU switching, level 5 is already reached. Chances are this won't go > > unnoticed by the user. > > If we fail the register hopefully the driver checks for that and might > blow up somewhere in untested error handling code. But there's a good > chance it'll fail (we can encourage that more by adding must_check to > the function declaration). In that case you get a nice bug report with > splat from users hitting this. > > Without this it'll silently work, and all the reports you get is > "linux is shit, gpu switching doesn't work". > > In both cases it can sometimes succeed, which is not great indeed. But > I'm trying to fix that by injection EDEFER points artificially > somehow. Not yet figured out that one. > > But irrespective of the precise failure mode making the defer check > mandatory by just including it in _register() is better since it makes > it impossible to forget to call it when its needed. So imo clearly the > more robust API. And that's my metric for evaluating new API - how > easy/hard is it to abuse/get wrong. > > >> For more context: We have tons of fun with EPROBE_DEFER handling > >> between i915 and snd-hda > > > > I don't understand, there is currently not a single occurrence of > > EPROBE_DEFER in i915, apart from the one I added. > > > > In sound/ there are 88 occurrences of EPROBE_DEFER in soc/, plus 1 in > > ppc/ and that's it. So not a single one in pci/hda/ where hda_intel.c > > resides. > > > > Is the fun with EPROBE_DEFER handling caused by the lack thereof? > > Yes, there's one instance where i915 shoudl defer missing. The real > trouble is that snd-hda has some really close ties with i915, and > resolves those with probe-defer. And blows up all the time since we > started using this, and with hdmi/dp you really always have to test > both together in CI, snd-hda is pretty much a part of the intel gfx > driver nowadays. Deferred probing is ime real trouble. To further complicate things, AMD dGPUs have HDA audio on board as well. Alex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/35] drm: Protect dev->filelist with its own mutex
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Wednesday, April 27, 2016 3:09 AM > To: Alex Deucher > Cc: Chris Wilson; Daniel Vetter; DRI Development; Deucher, Alexander; Intel > Graphics Development; Daniel Vetter > Subject: Re: [Intel-gfx] [PATCH 08/35] drm: Protect dev->filelist with its own > mutex > > On Wed, Apr 27, 2016 at 09:06:09AM +0200, Daniel Vetter wrote: > > On Tue, Apr 26, 2016 at 05:45:44PM -0400, Alex Deucher wrote: > > > On Tue, Apr 26, 2016 at 4:52 PM, Chris Wilson > wrote: > > > > On Tue, Apr 26, 2016 at 07:29:41PM +0200, Daniel Vetter wrote: > > > >> amdgpu gained dev->struct_mutex usage, and that's because it's > walking > > > >> the dev->filelist list. Protect that list with it's own lock to take > > > >> one more step towards getting rid of struct_mutex usage in drivers > > > >> once and for all. > > > >> > > > >> While doing the conversion I noticed that 2 debugfs files in i915 > > > >> completely lacked appropriate locking. Fix that up too. > > > >> > > > >> v2: don't forget to switch to > drm_gem_object_unreference_unlocked. > > > >> > > > >> Cc: Alex Deucher > > > >> Signed-off-by: Daniel Vetter > > > > > > > > Just wondering if this worth converting over. Opening/closing isn't > > > > going to be high contention, I hope, though we can certainly write > > > > stress cases for it! The goal for drivers to stop using the struct_mutex > > > > as their BKL, which doesn't preclude keeping the struct_mutex around > for > > > > where it makes sense to have a single mutex rather than a multitude. > > > > > > > > I have some misgivings over this, but only because I think its overkill. > > > > Reviewed-by: Chris Wilson > > > > > > I agree with Chris' sentiments. > > > > It's not to have more speed or less contention, but just to have fewer > > things to worry about when reviewing locking. Hence orthogonal locks for > > independent parts. > > > > My goal is that in the end dev->struct_mutex is only used by some existing > > drivers for their internals, plus all the legacy core stuff. And never > > even used by modern drivers. New locks are pretty cheap, and not > dragging > > in the entire legacy horror show has benefits. > > > > When/once I tackle the one thing left (master locking) I might move the > > master handling under this lock too (since it's closely related to open > > files). Not sure yet. > > Oh and the main reason I did it here: Much easier to review using git grep > struct_mutex than auditing codepaths. With this drivers have no reason to > ever grab struct_mutex (not even for debugfs or similar), since the last > remaining bit (master control) really shouldn't be a concern for drivers > ever. > > That also makes reviewing new drivers simpler: Contains struct_mutex? > Reject it! I'm convinced! Thanks for cleaning this up. Alex > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: squash lines for simple wrapper functions
> -Original Message-
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Tuesday, September 06, 2016 7:04 PM
> To: David Airlie; dri-de...@lists.freedesktop.org
> Cc: Masahiro Yamada; Gustavo Padovan; Yakir Yang; Huang, Ray; Deucher,
> Alexander; Liu, Monk; Zhou, David(ChunMing); Daniel Vetter; Heiko
> Stuebner; Huang, JinHuiEric; Cui, Flora; Inki Dae; Krzysztof Kozlowski; Dave
> Airlie; Jani Nikula; intel-gfx@lists.freedesktop.org; Frediano Ziglio; Li,
> Samuel;
> Koenig, Christian; Tomasz Figa; Sumit Semwal; linux-ker...@vger.kernel.org;
> StDenis, Tom; Dan Carpenter
> Subject: [PATCH] drm: squash lines for simple wrapper functions
>
> Remove unneeded variables and assignments.
>
> Signed-off-by: Masahiro Yamada
Please split these up per driver.
Alex
> ---
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c| 6 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c| 6 +-
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20
> drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++-
> drivers/gpu/drm/i915/i915_drv.c | 8 +---
> drivers/gpu/drm/qxl/qxl_draw.c| 7 ++-
> drivers/gpu/drm/qxl/qxl_release.c | 7 ++-
> drivers/gpu/drm/radeon/cik.c | 6 +-
> drivers/gpu/drm/radeon/r100.c | 6 +-
> drivers/gpu/drm/radeon/r600.c | 6 +-
> 11 files changed, 17 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index b818461..0d5307a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -5854,11 +5854,7 @@ static int gfx_v8_0_set_clockgating_state(void
> *handle,
>
> static u32 gfx_v8_0_ring_get_rptr_gfx(struct amdgpu_ring *ring)
> {
> - u32 rptr;
> -
> - rptr = ring->adev->wb.wb[ring->rptr_offs];
> -
> - return rptr;
> + return ring->adev->wb.wb[ring->rptr_offs];
> }
>
> static u32 gfx_v8_0_ring_get_wptr_gfx(struct amdgpu_ring *ring)
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> index a64715d..b165c78 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> @@ -190,12 +190,8 @@ out:
> */
> static uint32_t sdma_v2_4_ring_get_rptr(struct amdgpu_ring *ring)
> {
> - u32 rptr;
> -
> /* XXX check if swapping is necessary on BE */
> - rptr = ring->adev->wb.wb[ring->rptr_offs] >> 2;
> -
> - return rptr;
> + return ring->adev->wb.wb[ring->rptr_offs] >> 2;
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index 653ce5e..cf253b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -335,12 +335,8 @@ out:
> */
> static uint32_t sdma_v3_0_ring_get_rptr(struct amdgpu_ring *ring)
> {
> - u32 rptr;
> -
> /* XXX check if swapping is necessary on BE */
> - rptr = ring->adev->wb.wb[ring->rptr_offs] >> 2;
> -
> - return rptr;
> + return ring->adev->wb.wb[ring->rptr_offs] >> 2;
> }
>
> /**
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 48030f0..d37d112 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -1073,34 +1073,22 @@ void analogix_dp_set_lane3_link_training(struct
> analogix_dp_device *dp,
>
> u32 analogix_dp_get_lane0_link_training(struct analogix_dp_device *dp)
> {
> - u32 reg;
> -
> - reg = readl(dp->reg_base +
> ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
> - return reg;
> + return readl(dp->reg_base +
> ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
> }
>
> u32 analogix_dp_get_lane1_link_training(struct analogix_dp_device *dp)
> {
> - u32 reg;
> -
> - reg = readl(dp->reg_base +
> ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
> - return reg;
> + return readl(dp->reg_base +
> ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
> }
>
> u32 analogix_dp_get_lane2_link_training(struct analogix_dp_device *dp)
> {
> - u32 reg;
> -
> - reg = readl(dp->reg_base +
> ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
> - return reg;
> + return readl(dp->reg_base +
> ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
> }
>
Re: [Intel-gfx] [PATCH 0/6] Pipe level color management
> -Original Message-
> From: Daniel Stone [mailto:dan...@fooishbar.org]
> Sent: Friday, January 22, 2016 10:05 AM
> To: Lionel Landwerlin
> Cc: intel-gfx; Thierry Reding; Deucher, Alexander; dri-devel
> Subject: Re: [Intel-gfx] [PATCH 0/6] Pipe level color management
>
> Hi Lionel,
>
> On 21 January 2016 at 15:03, Lionel Landwerlin
> wrote:
> > Hi,
> >
> > This serie introduces pipe level color management through a set of
> properties
> > attached to the CRTC. It also provides an implementation for some Intel
> > platforms.
> >
> > This serie is based of a previous set of patches by Shashank Sharma and
> takes
> > into account of the comments by Daniel Stone & Daniel Vetter.
>
> This is a lot more tractable than previous series, thanks! I think a
> lot of the confusion I had around this was from the number of
> hardware-specific features stuffed into this, and the manner in which
> they were stuffed in. For example, with the previous series, it looks
> like you could configure both PRE_CTM and POST_CTM LUTs in 12-bit
> mode, which is impossible as the PRM suggests the only way to have
> both LUTs active is with split-gamma mode. (For anyone else looking at
> the Broadwell PRM, note the split-gamma mode describes the two LUTs
> completely backwards: the only thing that makes sense is for the
> pre-CTM LUT to have a range of 0..1.0, and the post-CTM LUT to have a
> range of -3.0..3.0, rather than the other way around.)
>
> Now with everything just using split-gamma mode, I'm much happier with
> how this is looking. I took a look at some other architectures to see
> how this would fit, and also had a chat with Richard Hughes to clear
> some things up. AMD seems to support every possible mode under the
> sun, so should support any API we came up with. Most other
> architectures only implemented a single gamma table (equivalent to
> legacy gamma ramp), but there was one I have fairly detailed
> documentation for and also supports everything.
>
> The degamma/colour-transform-matrix/gamma model is definitely a good
> one, and it seems like everyone agrees on a 3x3 matrix for CTM. So
> far, so good. What I worry about is the _values_ we put into the CTM.
>
> Intel supports two quite fun properties of matrix output. Firstly, the
> range is (-3.0..3.0) rather than the (0.0..1.0) you might expect.
> Negative values are axis-mirrored, i.e. lut2_index =
> fabs(matrix_output), thus giving us a LUT range of (0.0..3.0).
> Secondly, whilst (0.0..1.0) is represented by linear LUT entries, the
> LUT values for (1.0..3.0) are calculated by a linear interpolation
> between LUT entry #512 (i.e. that for 1.0) and a bonus entry #513
> (value for 3.0). I haven't seen this supported anywhere else, so would
> tend towards mirroring the last value into the extra supernumerary
> entry, i.e. emulate saturation for matrix output values to 1.0.
>
> I don't really know what to do about negative values as CTM output,
> since the doc I have here is silent on whether negative values are
> similarly axis-mirrored/sign-stripped, or whether they are instead
> clamped to 0.0. Either way, I'm not really sure it's behaviour we can
> rely upon to be portable.
>
> As a detail, the architecture I'm looking at has mixed granularity for
> the second (post-CTM) LUT: lower RGB-value entries have higher
> granularity (precision in LUT indexing), with lower granularity for
> higher entries. I don't think this is a problem though, since we can
> just decimate in the kernel (i.e. ignore every n'th LUT entry, to
> write a smaller LUT to hardware than we received to userspace).
>
> Anyway, beyond that, it seems there are a few things we agree on:
> - optional pre-matrix ('degamma') per-channel LUT of variable
> length, but (from a userspace point of view) fixed precision, input &
> output ranges 0.0..1.0
> - optional 3x3 matrix with input range [0.0,1.0], with output values
> saturating to 1.0, and negative values producing undefined behaviour
> - optional post-matrix ('gamma') per-channel LUT of variable length,
> but (from a userspace point of view) fixed precision, input & output
> ranges 0.0..1.0
>
> This would mean missing some Intel-specific features, but whether or
> not this is actually required I don't really know. At least it seems
> like it would be enough to implement standard ICC profile correction
> from Weston in a hardware-independent manner.
>
> Thierry, Alex, did you have any comments or ideas on this?
Adding Harry to comment as he's more familiar with our display hardware color
management.
Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dim: Enforce review requirements
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, May 24, 2017 5:28 AM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Patrik Jakobsson; Lukas
> Wunner; Deucher, Alexander; Christian König; Sean Paul; Daniel Vetter
> Subject: [PATCH] dim: Enforce review requirements
>
> We can't check this when applying (since r-b/a-b tags often get added
> afterwards), but we can check this when pushing. This only looks at
> patches authored by the pusher.
>
> Also update the docs to highlight that review requirements hold
> especially also for bugfixes.
>
> Cc: Patrik Jakobsson
> Cc: Lukas Wunner
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Sean Paul
> Signed-off-by: Daniel Vetter
Acked-by: Alex Deucher
> ---
> dim | 42 ++
> drm-misc.rst | 4 +++-
> 2 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/dim b/dim
> index baa0b3832314..79738a1b37a0 100755
> --- a/dim
> +++ b/dim
> @@ -340,6 +340,15 @@ function git_branch_exists # branch
> fi
> }
>
> +function git_committer_email
> +{
> + if ! commiter_email=$(git config --get user.email) ; then
> + commiter_email=$EMAIL
> + fi
> +
> + echo $commiter_email
> +}
> +
> # get message id from file
> # $1 = file
> message_get_id ()
> @@ -632,11 +641,32 @@ function dim_rebuild_tip
> exit 1
> fi
> }
> +
> +# additional patch checks before pushing, e.g. for r-b tags
> +function checkpatch_commit_push
> +{
> + local sha1
> +
> + sha1=$1
> +
> + # check for a-b/r-b tag
> + if git show -s $sha1 | grep -qi '\(reviewed\|acked\)\S*-by:' ; then
> + return
> + fi
> +
> + # check for commiter != author
> + if [[ $(git show -s $sha1 --format="format:%ce") != $(git show -s
> $sha1 --format="format:%ae") ]]; then
> + return
> + fi
> +
> + warn_or_fail "$sha1 is lacking mandatory review"
> +}
> +
> # push branch $1, rebuild drm-tip. the rest of the arguments are passed to
> git
> # push.
> function dim_push_branch
> {
> - local branch remote
> + local branch remote commiter_email
>
> branch=${1:?$usage}
> shift
> @@ -645,6 +675,12 @@ function dim_push_branch
>
> remote=$(branch_to_remote $branch)
>
> + commiter_email=$(git_committer_email)
> +
> + for sha1 in $(git rev-list $branch@{u}..$branch --
> committer="$commiter_email" --no-merges) ; do
> + checkpatch_commit_push $sha1
> + done
> +
> git push $DRY_RUN $remote $branch "$@"
>
> update_linux_next $branch drm-intel-next-queued drm-intel-next-
> fixes drm-intel-fixes
> @@ -690,9 +726,7 @@ function dim_apply_branch
>
> message_id=$(message_get_id $file)
>
> - if ! commiter_email=$(git config --get user.email) ; then
> - commiter_email=$EMAIL
> - fi
> + commiter_email=$(git_committer_email)
>
> patch_from=$(grep "From:" "$file" | head -1)
> if [[ "$patch_from" != *"$commiter_email"* ]] ; then
> diff --git a/drm-misc.rst b/drm-misc.rst
> index caba8dc77696..d56c3c7f92a3 100644
> --- a/drm-misc.rst
> +++ b/drm-misc.rst
> @@ -90,7 +90,9 @@ Merge Criteria
> Right now the only hard merge criteria are:
>
> * Patch is properly reviewed or at least Ack, i.e. don't just push your own
> - stuff directly.
> + stuff directly. This rule holds even more for bugfix patches - it would be
> + embarrassing if the bugfix contains a small gotcha that review would have
> + caught.
>
> * drm-misc is for drm core (non-driver) patches, subsystem-wide
> refactorings,
>and small trivial patches all over (including drivers). For a detailed
> list of
> --
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests: Increase value of I915_MAX_PIPES to 6
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of sunpeng...@amd.com
> Sent: Thursday, June 08, 2017 3:11 PM
> To: intel-gfx@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> Wentland, Harry
> Cc: Li, Sun peng
> Subject: [PATCH i-g-t] tests: Increase value of I915_MAX_PIPES to 6
>
> From: "Leo (Sunpeng) Li"
>
> Increasing max pipe count to 6 to support AMD GPU's.
>
> Since some tests' behavior depends on this value, small changes are made
> to remove this dependency:
>
> * kms_ccs: Early abort if wanted_pipe is out-of-bounds.
> * kms_concurrent: Check if pipe is within bounds first.
> * kms_pipe_color: Prevent skipping of subsequent tests by placing
> generated tests in a 'igt_subtest_group'.
> * kms_plane: Move pipe and plane index checking to subtest group level.
>
> Signed-off-by: Leo (Sunpeng) Li
> ---
> lib/igt_kms.c | 10 --
> lib/igt_kms.h | 3 +++
> tests/kms_ccs.c| 2 ++
> tests/kms_concurrent.c | 2 +-
> tests/kms_pipe_color.c | 3 ++-
> tests/kms_plane.c | 8 +---
> 6 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index c77716b..1bb62f0 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -319,12 +319,12 @@ const unsigned char* igt_kms_get_alt_edid(void)
> */
> const char *kmstest_pipe_name(enum pipe pipe)
> {
> - const char *str[] = { "A", "B", "C" };
> + const char *str[] = { "A", "B", "C", "D", "E", "F"};
>
> if (pipe == PIPE_NONE)
> return "None";
>
> - if (pipe > 2)
> + if (pipe > 5)
Use I915_MAX_PIPES here rather than hardcoding 5. With that fixed the patch is:
Acked-by: Alex Deucher
> return "invalid";
>
> return str[pipe];
> @@ -344,6 +344,12 @@ int kmstest_pipe_to_index(char pipe)
> return 1;
> else if (pipe == 'C')
> return 2;
> + else if (pipe == 'D')
> + return 3;
> + else if (pipe == 'E')
> + return 4;
> + else if (pipe == 'F')
> + return 5;
> else
> return -EINVAL;
> }
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 9567a26..8f7c2bb 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -54,6 +54,9 @@ enum pipe {
> PIPE_A = 0,
> PIPE_B,
> PIPE_C,
> + PIPE_D,
> + PIPE_E,
> + PIPE_F,
> I915_MAX_PIPES
> };
> const char *kmstest_pipe_name(enum pipe pipe);
> diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
> index d829152..0795e3a 100644
> --- a/tests/kms_ccs.c
> +++ b/tests/kms_ccs.c
> @@ -250,6 +250,8 @@ static void test(data_t *data)
> int valid_tests = 0;
> enum pipe wanted_pipe = data->pipe;
>
> + igt_skip_on(wanted_pipe >= display->n_pipes);
> +
> for_each_pipe_with_valid_output(display, data->pipe, data-
> >output) {
> if (wanted_pipe != PIPE_NONE && data->pipe !=
> wanted_pipe)
> continue;
> diff --git a/tests/kms_concurrent.c b/tests/kms_concurrent.c
> index b34540b..db06a37 100644
> --- a/tests/kms_concurrent.c
> +++ b/tests/kms_concurrent.c
> @@ -351,8 +351,8 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
> igt_fixture {
> int valid_tests = 0;
>
> - igt_require(data->display.pipes[pipe].n_planes > 0);
> igt_skip_on(pipe >= data->display.n_pipes);
> + igt_require(data->display.pipes[pipe].n_planes > 0);
>
> for_each_valid_output_on_pipe(&data->display, pipe,
> output)
> valid_tests++;
> diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
> index fd58ac8..da49eb1 100644
> --- a/tests/kms_pipe_color.c
> +++ b/tests/kms_pipe_color.c
> @@ -1180,7 +1180,8 @@ igt_main
> }
>
> for (int pipe = 0; pipe < I915_MAX_PIPES; pipe++)
> - run_tests_for_pipe(&data, pipe);
> + igt_subtest_group
> + run_tests_for_pipe(&data, pipe);
>
> igt_subtest_f("invalid-lut-sizes")
> invalid_lut_sizes(&data);
> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> index e1bd467..34418ca 100644
> --- a/tests/kms_plane.c
> +++ b/tests/kms_plane.c
> @@ -354,9 +354,6 @@ test_plane_panning(data_t *data, enum pipe pipe,
> int plane,
> igt_output_t *output;
> int connected_outs = 0;
>
> - igt_skip_on(pipe >= data->display.n_pipes);
> - igt_skip_on(plane >= data->display.pipes[pipe].n_planes);
> -
> for_each_valid_output_on_pipe(&data->display, pipe, output) {
> test_plane_panning_with_output(data, pipe, plane, output,
> flags);
> @@ -369,6 +366,11 @@ test_plane_panning(data_t *data, enum pipe pipe,
> int plane,
> static void
> run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
> {
> + igt_fixture {
> + igt_skip_on(pipe >= data->display.n_pipes);
> + igt_requir
Re: [Intel-gfx] [PATCH i-g-t v2] tests: Increase value of I915_MAX_PIPES to 6
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of sunpeng...@amd.com
> Sent: Friday, June 09, 2017 4:18 PM
> To: intel-gfx@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> Wentland, Harry
> Cc: Li, Sun peng
> Subject: [PATCH i-g-t v2] tests: Increase value of I915_MAX_PIPES to 6
>
> From: "Leo (Sunpeng) Li"
>
> Increasing max pipe count to 6 to support AMD GPU's.
>
> Since some tests' behavior depends on this value, small changes are made
> to remove this dependency:
>
> * kms_ccs: Early abort if wanted_pipe is out-of-bounds.
> * kms_concurrent: Check if pipe is within bounds first.
> * kms_pipe_color: Prevent skipping of subsequent tests by placing
> generated tests in a 'igt_subtest_group'.
> * kms_plane: Move pipe and plane index checking to subtest group level.
>
> v2: Change invalid pipe check on kmstest_pipe_name() to use
> I915_MAX_PIPE
>
> Signed-off-by: Leo (Sunpeng) Li
Acked-by: Alex Deucher
> ---
> lib/igt_kms.c | 10 --
> lib/igt_kms.h | 3 +++
> tests/kms_ccs.c| 2 ++
> tests/kms_concurrent.c | 2 +-
> tests/kms_pipe_color.c | 3 ++-
> tests/kms_plane.c | 8 +---
> 6 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index c77716b..473094d 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -319,12 +319,12 @@ const unsigned char* igt_kms_get_alt_edid(void)
> */
> const char *kmstest_pipe_name(enum pipe pipe)
> {
> - const char *str[] = { "A", "B", "C" };
> + const char *str[] = { "A", "B", "C", "D", "E", "F"};
>
> if (pipe == PIPE_NONE)
> return "None";
>
> - if (pipe > 2)
> + if (pipe >= I915_MAX_PIPES)
> return "invalid";
>
> return str[pipe];
> @@ -344,6 +344,12 @@ int kmstest_pipe_to_index(char pipe)
> return 1;
> else if (pipe == 'C')
> return 2;
> + else if (pipe == 'D')
> + return 3;
> + else if (pipe == 'E')
> + return 4;
> + else if (pipe == 'F')
> + return 5;
> else
> return -EINVAL;
> }
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 9567a26..8f7c2bb 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -54,6 +54,9 @@ enum pipe {
> PIPE_A = 0,
> PIPE_B,
> PIPE_C,
> + PIPE_D,
> + PIPE_E,
> + PIPE_F,
> I915_MAX_PIPES
> };
> const char *kmstest_pipe_name(enum pipe pipe);
> diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
> index d829152..0795e3a 100644
> --- a/tests/kms_ccs.c
> +++ b/tests/kms_ccs.c
> @@ -250,6 +250,8 @@ static void test(data_t *data)
> int valid_tests = 0;
> enum pipe wanted_pipe = data->pipe;
>
> + igt_skip_on(wanted_pipe >= display->n_pipes);
> +
> for_each_pipe_with_valid_output(display, data->pipe, data-
> >output) {
> if (wanted_pipe != PIPE_NONE && data->pipe !=
> wanted_pipe)
> continue;
> diff --git a/tests/kms_concurrent.c b/tests/kms_concurrent.c
> index b34540b..db06a37 100644
> --- a/tests/kms_concurrent.c
> +++ b/tests/kms_concurrent.c
> @@ -351,8 +351,8 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
> igt_fixture {
> int valid_tests = 0;
>
> - igt_require(data->display.pipes[pipe].n_planes > 0);
> igt_skip_on(pipe >= data->display.n_pipes);
> + igt_require(data->display.pipes[pipe].n_planes > 0);
>
> for_each_valid_output_on_pipe(&data->display, pipe,
> output)
> valid_tests++;
> diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
> index fd58ac8..da49eb1 100644
> --- a/tests/kms_pipe_color.c
> +++ b/tests/kms_pipe_color.c
> @@ -1180,7 +1180,8 @@ igt_main
> }
>
> for (int pipe = 0; pipe < I915_MAX_PIPES; pipe++)
> - run_tests_for_pipe(&data, pipe);
> + igt_subtest_group
> + run_tests_for_pipe(&data, pipe);
>
> igt_subtest_f("invalid-lut-sizes")
> invalid_lut_sizes(&data);
> diff --git a/tests/kms_plane.c b/tests/kms_plane.c
> index e1bd467..34418ca 100644
> --- a/tests/kms_plane.c
> +++ b/tests/kms_plane.c
> @@ -354,9 +354,6 @@ test_plane_panning(data_t *data, enum pipe pipe,
> int plane,
> igt_output_t *output;
> int connected_outs = 0;
>
> - igt_skip_on(pipe >= data->display.n_pipes);
> - igt_skip_on(plane >= data->display.pipes[pipe].n_planes);
> -
> for_each_valid_output_on_pipe(&data->display, pipe, output) {
> test_plane_panning_with_output(data, pipe, plane, output,
> flags);
> @@ -369,6 +366,11 @@ test_plane_panning(data_t *data, enum pipe pipe,
> int plane,
> static void
> run_tests_for_pipe_plane(data_t *data, enum pipe pipe)
> {
> + igt_fixture {
> + igt_skip_on(pipe >= data->display.n_pipes);
> +
Re: [Intel-gfx] [PATCH 13/13] drm/atomic-helper: Realign function parameters
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Tuesday, June 27, 2017 11:00 AM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Grodzovsky, Andrey;
> Deucher, Alexander; Daniel Vetter
> Subject: [PATCH 13/13] drm/atomic-helper: Realign function parameters
>
> Too jarring.
>
> Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic
> helpers (v2)")
> Cc: Andrey Grodzovsky
> Cc: Alex Deucher
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2f269e4267da..5a80b6960ae1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2964,12 +2964,11 @@
> drm_atomic_helper_connector_set_property(struct drm_connector
> *connector,
> }
> EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
>
> -static int page_flip_common(
> - struct drm_atomic_state *state,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags)
> +static int page_flip_common(struct drm_atomic_state *state,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_plane_state *plane_state;
> @@ -3063,13 +3062,12 @@
> EXPORT_SYMBOL(drm_atomic_helper_page_flip);
> * Returns:
> * Returns 0 on success, negative errno numbers on failure.
> */
> -int drm_atomic_helper_page_flip_target(
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags,
> - uint32_t target,
> - struct drm_modeset_acquire_ctx *ctx)
> +int drm_atomic_helper_page_flip_target(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event
> *event,
> +uint32_t flags,
> +uint32_t target,
> +struct drm_modeset_acquire_ctx *ctx)
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_atomic_state *state;
> --
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in addition to tags
> -Original Message-
> From: dim-tools [mailto:dim-tools-boun...@lists.freedesktop.org] On Behalf
> Of Sean Paul
> Sent: Wednesday, November 01, 2017 8:52 AM
> To: Gustavo Padovan
> Cc: Daniel Vetter; Intel Graphics Development; dim-
> to...@lists.freedesktop.org; dri-devel; Daniel Vetter
> Subject: Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in
> addition to tags
>
> On Wed, Nov 1, 2017 at 7:12 AM, Gustavo Padovan
> wrote:
> > 2017-10-31 Sean Paul :
> >
> >> On Tue, Oct 31, 2017 at 1:31 PM, Daniel Vetter wrote:
> >> > On Tue, Oct 31, 2017 at 5:14 PM, Sean Paul
> wrote:
> >> >> On Tue, Oct 31, 2017 at 4:27 AM, Jani Nikula
> >> >> wrote:
> >> >>>
> >> >>> Reminder, we have this new list dim-to...@lists.freedesktop.org for
> >> >>> maintainer tools patches. Cc'd.
> >> >>>
> >> >>
> >> >> Ahh, cool. I didn't realize dim grew up!
> >> >>
> >> >>> On Mon, 30 Oct 2017, Sean Paul wrote:
> >> Expanding on Jani's work to sign tags, this patch adds signing for git
> >> commit/am.
> >> >>>
> >> >>> I guess I'd like more rationale here. Is this something we should be
> >> >>> doing? Is anyone else doing this?
> >> >>>
> >> >>
> >> >> Sure thing. Signing commits allows Dave to use --verify-signatures
> >> >> when pulling. If something is not signed, we'll know it was either not
> >> >> applied with dim, or was altered on fdo (both warrant investigation).
> >> >>
> >> >> I suspect no one else is doing this since most trees are single
> >> >> maintainer, and it's not possible to sign commits via git send-email.
> >> >> Since we have the committer model, and a bunch of people with
> access
> >> >> to fdo and the tree, I think it's important to add this. Especially
> >> >> since we can do it in dim without overhead.
> >> >>
> >> Signed-off-by: Sean Paul
> >> ---
> >>
> >> This has been lightly tested with dim apply-branch/dim push-
> branch.
> >>
> >> Sean
> >>
> >> dim | 78
> +--
> --
> >> 1 file changed, 51 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/dim b/dim
> >> index 527989aff9ad..cd5e41f89a3a 100755
> >> --- a/dim
> >> +++ b/dim
> >> @@ -67,9 +67,6 @@
> DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-
> $HOME/.dim.template.signature}
> >> # dim pull-request tag summary template
> >>
> DIM_TEMPLATE_TAG_SUMMARY=${DIM_TEMPLATE_TAG_SUMMARY:-
> $HOME/.dim.template.tagsummary}
> >>
> >> -# GPG key id for signing tags. If unset, don't sign.
> >> -DIM_GPG_KEYID=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
> >> -
> >> #
> >> # Internal configuration.
> >> #
> >> @@ -104,6 +101,20 @@ test_request_recipients=(
> >> # integration configuration
> >> integration_config=nightly.conf
> >>
> >> +# GPG key id for signing tags. If unset, don't sign.
> >> +function gpg_keyid_for_tag
> >> +{
> >> + echo "${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}"
> >> + return 0
> >> +}
> >> +
> >> +# GPG key id for committing (git commit/am). If unset, don't sign.
> >> +function gpg_keyid_for_commit
> >> +{
> >> + echo "${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}"
> >> + return 0
> >> +}
> >> >>>
> >> >>> This seems like an overly complicated way to achieve what you want.
> >> >>>
> >> >>> Just put these under "Internal configuration." instead:
> >> >>>
> >> >>> dim_gpg_sign_tag=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
> >> >>> dim_gpg_sign_commit=${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}
> >> >>>
> >> >>> And use directly in git tag and commit, respectively?
> >> >>>
> >> >>
> >> >> Yep, sounds good.
> >> >>
> >> >>> Although... perhaps starting to sign tags should not force signing
> >> >>> commits?
> >> >>>
> >> >>
> >> >> Why would it be desirable to *not* sign tags?
> >> >
> >> > Again, what's the threat model you're trying to defend against? Atm
> >> > anyone with commit rights to fd.o can push whatever they want to. If
> >> > they want to be evil, they can also push whatever kind of garbage they
> >> > want to, including commit signature and and fake Link: and review
> >> > tags. With pull requests/tags signing them prevents a
> >> > man-in-the-midddle attack of the unprotected pull request in the mail,
> >> > but I still don't see what signing commits protects against.
> >>
> >> This is protecting against a bad actor (either through a committer's
> >> account, or some other fdo account) gaining access to the tree on fdo
> >> and either adding a malicious commit, or altering an existing commit.
> >
> > Yeah, but then we need to enforce it for all committer
>
> My hope is that dim makes it easy enough to get everyone on board
> eventually. In the interim, the people with signing commits will be
> able to attest that those commits were applied by them.
>
> > and we also need
> > a signing party to sign each others keys.
>
> I feel like most o
Re: [Intel-gfx] [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and bw codes
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@intel.com]
> Sent: Monday, October 09, 2017 5:30 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: jani.nik...@intel.com; Deucher, Alexander; Thierry Reding; Rob Clark;
> Sean Paul; Manasi Navare; dri-de...@lists.freedesktop.org
> Subject: [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and
> bw codes
>
> Falling back to the lowest value is likely the only thing we can do, but
> doing it silently seems like a bad thing to do. Catch it early and make
> loud noises.
>
> Cc: Alex Deucher
> Cc: Thierry Reding
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Manasi Navare
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_dp_helper.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 08af8d6b844b..dca21b5a03ec 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -137,8 +137,10 @@
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
> u8 drm_dp_link_rate_to_bw_code(int link_rate)
> {
> switch (link_rate) {
> - case 162000:
> default:
> + WARN(1, "unknown DP link rate %d, using %x\n", link_rate,
> + DP_LINK_BW_1_62);
> + case 162000:
> return DP_LINK_BW_1_62;
> case 27:
> return DP_LINK_BW_2_7;
> @@ -151,8 +153,9 @@ EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
> int drm_dp_bw_code_to_link_rate(u8 link_bw)
> {
> switch (link_bw) {
> - case DP_LINK_BW_1_62:
> default:
> + WARN(1, "unknown DP link bw code %x, using 162000\n",
> link_bw);
> + case DP_LINK_BW_1_62:
> return 162000;
> case DP_LINK_BW_2_7:
> return 27;
> --
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the sound-asoc tree with the drm-misc tree
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, October 18, 2017 6:08 AM
> To: Deucher, Alexander; Mukunda, Vijendar; Zhu, Rex; Daniel Vetter; Intel
> Graphics; DRI; Liam Girdwood
> Cc: Linux-Next Mailing List; Linux Kernel Mailing List; alsa-devel@alsa-
> project.org
> Subject: Re: linux-next: manual merge of the sound-asoc tree with the drm-
> misc tree
>
> On Wed, Oct 18, 2017 at 10:57:33AM +0100, Mark Brown wrote:
>
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your
> tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> Actually I'm just going to discard the AMD drivers from the ASoC tree
> because the build produces reams of errors like those below, the changes
> to move the chip type definitions around weren't fully baked. Please
> resend both the pull request and the patches with this fixed. Note also
> that if you're basing something on Linus' tree you should use a tagged
> release rather than just a random commit.
Your conflict change affectively reverted 1e4448648333a which is what caused
the problem. It looks like Dave did not yet pull the request I made. I can
send another pull request, but you may run into the same issue if you resolve
the conflict the same way again.
Alex
>
> In file included from
> /home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu.h:51:0,
> from
> /home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu_conn
> ectors.c:31:
> /home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/../include/amd
> _shared.h:33:6: error: nested redefinition of 'enum amd_asic_type'
> enum amd_asic_type {
> ^
> /home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/../include/amd
> _shared.h:33:6: error: redeclaration of 'enum amd_asic_type'
> In file included from
> /home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/../include/amd
> _shared.h:26:0,
> from
> /home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu.h:51,
> from
> /home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu_conn
> ectors.c:31:
> /home/broonie/tmpfs/next/include/drm/amd_asic_type.h:28:6: note:
> originally defined here
> enum amd_asic_type {
> ^
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the sound-asoc tree with the drm-misc tree
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, October 18, 2017 5:58 AM
> To: Deucher, Alexander; Mukunda, Vijendar; Zhu, Rex; Daniel Vetter; Intel
> Graphics; DRI; Liam Girdwood
> Cc: Linux-Next Mailing List; Linux Kernel Mailing List
> Subject: linux-next: manual merge of the sound-asoc tree with the drm-misc
> tree
>
> Hi all,
>
> Today's linux-next merge of the sound-asoc tree got a conflict in:
>
> drivers/gpu/drm/amd/include/amd_shared.h
>
> between commit:
>
> cfa289fd4986c ("drm/amdgpu: rename amdgpu_dpm_funcs to
> amd_pm_funcs")
>
> from the drm-misc tree and commit:
>
> 1e4448648333a ("drm/amdgpu Moving amdgpu asic types to a separate
> file")
The patch below effectively reverts 1e4448648333a. If you drop the patch
below, you should be fine.
Alex
>
> from the sound-asoc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/gpu/drm/amd/include/amd_shared.h
> index de6fc2731b98,3a49fbd8baf8..
> --- a/drivers/gpu/drm/amd/include/amd_shared.h
> +++ b/drivers/gpu/drm/amd/include/amd_shared.h
> @@@ -23,37 -23,10 +23,39 @@@
> #ifndef __AMD_SHARED_H__
> #define __AMD_SHARED_H__
>
> - #define AMD_MAX_USEC_TIMEOUT20 /* 200 ms */
> + #include
>
> +struct seq_file;
> +
> +/*
> + * Supported ASIC types
> + */
> +enum amd_asic_type {
> +CHIP_TAHITI = 0,
> +CHIP_PITCAIRN,
> +CHIP_VERDE,
> +CHIP_OLAND,
> +CHIP_HAINAN,
> +CHIP_BONAIRE,
> +CHIP_KAVERI,
> +CHIP_KABINI,
> +CHIP_HAWAII,
> +CHIP_MULLINS,
> +CHIP_TOPAZ,
> +CHIP_TONGA,
> +CHIP_FIJI,
> +CHIP_CARRIZO,
> +CHIP_STONEY,
> +CHIP_POLARIS10,
> +CHIP_POLARIS11,
> +CHIP_POLARIS12,
> +CHIP_VEGA10,
> +CHIP_RAVEN,
> +CHIP_LAST,
> +};
> +
> + #define AMD_MAX_USEC_TIMEOUT20 /* 200 ms */
> +
> /*
>* Chip flags
>*/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 00/28] DRM API Conversions
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Cihangir Akturk
> Sent: Friday, August 11, 2017 8:33 AM
> Cc: de...@driverdev.osuosl.org; linux-arm-...@vger.kernel.org; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; etna...@lists.freedesktop.org; Cihangir Akturk;
> amd-...@lists.freedesktop.org; dan...@ffwll.ch;
> nouv...@lists.freedesktop.org; linux-te...@vger.kernel.org;
> virtualizat...@lists.linux-foundation.org; freedr...@lists.freedesktop.org
> Subject: [PATCH v3 00/28] DRM API Conversions
>
> Changes since v2:
>
> - Patch series is based on *drm-misc-next* as suggested by Sean Paul.
>
> - Dropped patch 05 (drm/atmel-hlcdc) and patch 25 (drm/vc4) from v2,
> since they were already pulled in the drm-misc-next
>
> Changes since v1:
>
> - This time patches were generated with coccinelle instead of my own
> script, as suggested by Daniel Vetter.
>
> - Fixed the typo in commit messages. s/adn/and
>
FWIW, I already picked up v1 of these patches for radeon and amdgpu.
Alex
> Note: I've included r-b, a-b tags, as these patches are identical to v1
> except for the file: drivers/gpu/drm/i915/i915_gem_object.h
>
> This patch set replaces the occurrences of drm_*_reference() and
> drm_*_unreference() with the new drm_*_get() and drm_*_put()
> functions.
> All patches in the series do the same thing, converting to the new APIs.
> I created patches per DRM driver as suggested by Daniel Vetter.
>
> This patch set was generated by scripts/coccinelle/api/drm-get-put.cocci
>
> Previous thread can be reached at:
> https://marc.info/?l=dri-devel&m=150178288816047
>
> Background:
>
> In the kernel, reference counting APIs use *_get(), *_put() style naming
> to reference-count the objects. But DRM subsystem uses a different
> naming for them such as *_reference(), *_unreference() which is
> inconsistent with the other reference counting APIs in the kernel. To
> solve this consistency issue, Thierry Reding introduced a couple of
> functions and compatibility aliases in the following commits for them.
>
> commit 020a218f95bd3ceff7dd1022ff7ebc0497bc7bf9
> Author: Thierry Reding
> Date: Tue Feb 28 15:46:38 2017 +0100
>
> drm: Introduce drm_mode_object_{get,put}()
>
> commit ad09360750afa18a0a0ce0253d6ea6033abc22e7
> Author: Thierry Reding
> Date: Tue Feb 28 15:46:39 2017 +0100
>
> drm: Introduce drm_connector_{get,put}()
>
> commit a4a69da06bc11a937a6e417938b1bb698ee1fa46
> Author: Thierry Reding
> Date: Tue Feb 28 15:46:40 2017 +0100
>
> drm: Introduce drm_framebuffer_{get,put}()
>
> commit e6b62714e87c8811d5564b6a0738dcde63a51774
> Author: Thierry Reding
> Date: Tue Feb 28 15:46:41 2017 +0100
>
> drm: Introduce drm_gem_object_{get,put}()
>
> commit 6472e5090be7c78749a3c279b4faae87ab835c40
> Author: Thierry Reding
> Date: Tue Feb 28 15:46:42 2017 +0100
>
> drm: Introduce drm_property_blob_{get,put}()
>
> Cihangir Akturk (28):
> drm/amdgpu: switch to drm_*_get(), drm_*_put() helpers
> drm: mali-dp: switch to drm_*_get(), drm_*_put() helpers
> drm/armada: switch to drm_*_get(), drm_*_put() helpers
> drm/ast: switch to drm_*_get(), drm_*_put() helpers
> drm/bochs: switch to drm_*_get(), drm_*_put() helpers
> drm/cirrus: switch to drm_*_get(), drm_*_put() helpers
> drm/etnaviv: switch to drm_*_get(), drm_*_put() helpers
> drm/exynos: switch to drm_*_get(), drm_*_put() helpers
> drm/gma500: switch to drm_*_get(), drm_*_put() helpers
> drm/hisilicon: switch to drm_*_get(), drm_*_put() helpers
> drm/i915: switch to drm_*_get(), drm_*_put() helpers
> drm/imx: switch to drm_*_get(), drm_*_put() helpers
> drm/mediatek: switch to drm_*_get(), drm_*_put() helpers
> drm/mgag200: switch to drm_*_get(), drm_*_put() helpers
> drm/msm: switch to drm_*_get(), drm_*_put() helpers
> drm/nouveau: switch to drm_*_get(), drm_*_put() helpers
> drm/omapdrm: switch to drm_*_get(), drm_*_put() helpers
> drm/qxl: switch to drm_*_get(), drm_*_put() helpers
> drm/radeon: switch to drm_*_get(), drm_*_put() helpers
> drm/rockchip: switch to drm_*_get(), drm_*_put() helpers
> drm/tegra: switch to drm_*_get(), drm_*_put() helpers
> drm/tilcdc: switch to drm_*_get(), drm_*_put() helpers
> drm/udl: switch to drm_*_get(), drm_*_put() helpers
> drm/vc4: switch to drm_*_get(), drm_*_put() helpers
> drm/vgem: switch to drm_*_get(), drm_*_put() helpers
> drm/virtio: switch to drm_*_get(), drm_*_put() helpers
> drm/vmwgfx: switch to drm_*_get(), drm_*_put() helpers
> drm: vboxvideo: switch to drm_*_get(), drm_*_put() helpers
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 4 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 22 ++
Re: [Intel-gfx] [PATCH 04/11] drm/radeon: Use regular fbdev I/O helpers
[Public]
> -Original Message-
> From: Thomas Zimmermann
> Sent: Friday, May 12, 2023 4:42 AM
> To: dan...@ffwll.ch; airl...@gmail.com; maarten.lankho...@linux.intel.com;
> mrip...@kernel.org; javi...@redhat.com
> Cc: dri-de...@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; intel-gfx@lists.freedesktop.org; linux-
> arm-...@vger.kernel.org; freedr...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; linux-te...@vger.kernel.org; Thomas
> Zimmermann ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui
> Subject: [PATCH 04/11] drm/radeon: Use regular fbdev I/O helpers
>
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's helpers.
> Radeon does not use damage handling, so DRM's fbdev helpers are mere
> wrappers around the fbdev code.
>
> Add CONFIG_DRM_RADEON_FBDEV_EMULATION to select the necessary
> Kconfig options automatically. Make fbdev emulation depend on the new
> config option.
>
> By using fbdev helpers directly within each DRM fbdev emulation, we can
> eventually remove DRM's wrapper functions entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "Pan, Xinhui"
Feel free to take this through whatever tree makes sense.
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/Kconfig| 8
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/radeon_fbdev.c | 9 -
> drivers/gpu/drm/radeon/radeon_mode.h | 2 +-
> 4 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/Kconfig
> b/drivers/gpu/drm/radeon/Kconfig index e19d77d58810..66b741d96cc4
> 100644
> --- a/drivers/gpu/drm/radeon/Kconfig
> +++ b/drivers/gpu/drm/radeon/Kconfig
> @@ -8,6 +8,7 @@ config DRM_RADEON
> select DRM_DISPLAY_DP_HELPER
> select DRM_DISPLAY_HELPER
> select DRM_KMS_HELPER
> + select DRM_RADEON_FBDEV_EMULATION if
> DRM_FBDEV_EMULATION
> select DRM_SUBALLOC_HELPER
> select DRM_TTM
> select DRM_TTM_HELPER
> @@ -39,3 +40,10 @@ config DRM_RADEON_USERPTR
> help
> This option selects CONFIG_MMU_NOTIFIER if it isn't already
> selected to enabled full userptr support.
> +
> +config DRM_RADEON_FBDEV_EMULATION
> + bool
> + depends on DRM_RADEON
> + select FB_CFB_COPYAREA
> + select FB_CFB_FILLRECT
> + select FB_CFB_IMAGEBLIT
> diff --git a/drivers/gpu/drm/radeon/Makefile
> b/drivers/gpu/drm/radeon/Makefile index a8734b7d0485..46c1446196a9
> 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -76,7 +76,7 @@ radeon-y += \
> vce_v1_0.o \
> vce_v2_0.o
>
> -radeon-$(CONFIG_DRM_FBDEV_EMULATION) += radeon_fbdev.o
> +radeon-$(CONFIG_DRM_RADEON_FBDEV_EMULATION) +=
> radeon_fbdev.o
> radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> radeon-$(CONFIG_ACPI) += radeon_acpi.o
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fbdev.c
> b/drivers/gpu/drm/radeon/radeon_fbdev.c
> index fe76e29910ef..dcabe527f9c0 100644
> --- a/drivers/gpu/drm/radeon/radeon_fbdev.c
> +++ b/drivers/gpu/drm/radeon/radeon_fbdev.c
> @@ -24,6 +24,7 @@
> * David Airlie
> */
>
> +#include
> #include
> #include
> #include
> @@ -193,11 +194,9 @@ static const struct fb_ops radeon_fbdev_fb_ops = {
> DRM_FB_HELPER_DEFAULT_OPS,
> .fb_open = radeon_fbdev_fb_open,
> .fb_release = radeon_fbdev_fb_release,
> - .fb_read = drm_fb_helper_cfb_read,
> - .fb_write = drm_fb_helper_cfb_write,
> - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> + .fb_fillrect = cfb_fillrect,
> + .fb_copyarea = cfb_copyarea,
> + .fb_imageblit = cfb_imageblit,
> .fb_destroy = radeon_fbdev_fb_destroy, };
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 1decdcec0264..c5a8e25a4c97 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -939,7 +939,7 @@ void dce4_program_fmt(struct drm_encoder
> *encoder); void dce8_program_fmt(struct drm_encoder *encoder);
>
> /* fbdev layer */
> -#if defined(CONFIG_DRM_FBDEV_EMULATION)
> +#if defined(CONFIG_DRM_RADEON_FBDEV_EMULATION)
> void radeon_fbdev_setup(struct radeon_device *rdev); void
> radeon_fbdev_set_suspend(struct radeon_device *rdev, int state); bool
> radeon_fbdev_robj_is_fb(struct radeon_device *rdev, struct radeon_bo
> *robj);
> --
> 2.40.1
Re: [Intel-gfx] [PATCH v4 02/30] drm/dp_mst: Fix fractional DSC bpp handling
[Public]
> -Original Message-
> From: Wentland, Harry
> Sent: Wednesday, November 8, 2023 9:40 AM
> To: Imre Deak ; intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä ; Manasi Navare
> ; Lyude Paul ; Francis,
> David ; Mikita Lipski ;
> Deucher, Alexander
> Subject: Re: [PATCH v4 02/30] drm/dp_mst: Fix fractional DSC bpp handling
>
>
>
> On 2023-10-30 11:58, Imre Deak wrote:
> > From: Ville Syrjälä
> >
> > The current code does '(bpp << 4) / 16' in the MST PBN calculation,
> > but that is just the same as 'bpp' so the DSC codepath achieves
> > absolutely nothing. Fix it up so that the fractional part of the bpp
> > value is actually used instead of truncated away. 64*1006 has enough
> > zero lsbs that we can just shift that down in the dividend and thus
> > still manage to stick to a 32bit divisor.
> >
> > And while touching this, let's just make the whole thing more
> > straightforward by making the passed in bpp value .4 binary fixed
> > point always, instead of having to pass in different things based on
> > whether DSC is enabled or not.
> >
> > v2:
> > - Fix DSC kunit test cases.
> >
> > Cc: Manasi Navare
> > Cc: Lyude Paul
> > Cc: Harry Wentland
> > Cc: David Francis
> > Cc: Mikita Lipski
> > Cc: Alex Deucher
> > Fixes: dc48529fb14e ("drm/dp_mst: Add PBN calculation for DSC modes")
> > Reviewed-by: Lyude Paul (v1)
> > Signed-off-by: Ville Syrjälä
> > [Imre: Fix kunit test cases]
> > Signed-off-by: Imre Deak
>
> Acked-by: Harry Wentland
Acked-by: Alex Deucher
>
> Harry
>
> > ---
> > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 +--
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +--
> > .../gpu/drm/tests/drm_dp_mst_helper_test.c| 6 +++---
> > include/drm/display/drm_dp_mst_helper.h | 2 +-
> > 7 files changed, 14 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 9a712791f309f..ada3773869ff0 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6918,7 +6918,7 @@ static int
> dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
> > max_bpc);
> > bpp = convert_dc_color_depth_into_bpc(color_depth) * 3;
> > clock = adjusted_mode->clock;
> > - dm_new_connector_state->pbn =
> drm_dp_calc_pbn_mode(clock, bpp, false);
> > + dm_new_connector_state->pbn =
> drm_dp_calc_pbn_mode(clock, bpp <<
> > +4);
> > }
> >
> > dm_new_connector_state->vcpi_slots = diff --git
> > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index d3b13d362edac..9a58e1a4c5f49 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -1642,7 +1642,7 @@ enum dc_status
> dm_dp_mst_is_port_support_mode(
> > } else {
> > /* check if mode could be supported within full_pbn */
> > bpp = convert_dc_color_depth_into_bpc(stream-
> >timing.display_color_depth) * 3;
> > - pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz
> / 10, bpp, false);
> > + pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz
> / 10, bpp
> > +<< 4);
> >
> > if (pbn > aconnector->mst_output_port->full_pbn)
> > return DC_FAIL_BANDWIDTH_VALIDATE; diff --git
> > a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 0e0d0e76de065..772b00ebd57bd 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -4718,13 +4718,12 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
> >
> > /**
> > * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
> > - * @clock: dot clock for the mode
> > - * @bpp: bpp for the mode.
> > - * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
> > + * @clock: dot cl
Re: [Intel-gfx] [PULL] drm-misc-next
[Public] > -Original Message- > From: dim-tools On Behalf Of > John Paul Adrian Glaubitz > Sent: Monday, January 23, 2023 10:01 AM > To: tzimmerm...@suse.de > Cc: tvrtko.ursu...@linux.intel.com; dim-to...@lists.freedesktop.org; > daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; rodrigo.v...@intel.com; airl...@gmail.com > Subject: Re: [PULL] drm-misc-next > > Hi Thomas! > > > Driver Changes: > > > > * Remove obsolete drivers for userspace modesetting i810, mga, r128, > >savage, sis, tdfx, via > > Is the Rage 128 GPU still supported via the generic modesetting driver? > > I'm asking because, we're still supporting PowerMacs in Debian Ports of > which some of those are sporting a Rage 128 GPU. Similar question applies to > the > i810 GPU used in some old ThinkPads, for example. These are not KMS drivers. They are just the kernel component needed for 3D rendering. These drivers have nothing to do with driving the displays on these cards. For display support you need to use the old Xorg DDXs for these cards or the relevant non-DRM fbdev drivers. Alex > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
RE: quadbuffer stereo
[Public] Quadbuffer stereo is not supported on Linux. Alex From: amd-gfx On Behalf Of adblover Sent: Monday, June 24, 2024 6:53 AM To: intel-gfx@lists.freedesktop.org; amd-...@lists.freedesktop.org Subject: quadbuffer stereo I have no idea how to enable quadbuffer stereo (hdmi-3d) on linux for intel and amdgpu. I tried using Option Stereo 12 with this result (WW) AMDGPU(0): Option "Stereo" is not used Hoping for solutions for both cards (intel arc,renoir) thanks -- #xorg.conf that I used Section "ServerLayout" Identifier "xserver" Screen 0 "screen" 0 0 InputDevice"keyb" "CoreKeyboard" InputDevice"mouse" "CorePointer" EndSection Section "ServerFlags" Option "AllowMouseOpenFail" "true" # allows the server to start up even if the mouse does not work #Option "DontVTSwitch""false" # allow switching between virtual terminal # Option "DontZoom""true" # disable / (resolution switching) EndSection Section "Files" #RgbPath "/usr/X11R6/lib/X11/rgb" #ModulePath "/usr/X11R6/lib/modules" # More information: http://ftp.x.org/pub/X11R7.0/doc/html/fonts.html FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi" # True type and type1 fonts are also handled via xftlib, see /etc/X11/XftConfig! FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/share/fonts/ttf/western" FontPath "/usr/share/fonts/ttf/decoratives" FontPath "/usr/share/fonts/truetype/ttf-bitstream-vera" FontPath "/usr/share/fonts/latex-ttf-fonts" FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection Section "Module" Load "dbe" # double buffer extension Load "dri" # direct rendering Load "glx" # 3D layer Load "amdgpu" Load "modesetting" Load "glamoregl" Load "extmod"# some commonly used server extensions (e.g. shape extension) Load "record"# recording extension Load "evdev" # generic input handling driver on Linux Load "bitmap"# bitmap fonts Load "ddc" # ddc probing of monitor Load "freetype" # font rendering EndSection Section "InputDevice" Identifier "keyb" Option "CoreKeyboard" Driver "evdev" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "de" #Option "XkbOptions" "u" EndSection Section "InputDevice" Identifier "mouse" Driver "evdev" #Option "Device" "/dev/input/mice" #Option "ZAxisMapping" "4 5" #Option "Buttons" "5" #Option "SendCoreEvents""true" EndSection Section "Monitor" Identifier "sony" Option "DPMS" "true" #HorizSync31.0 - 61.0 #VertRefresh 50.0 - 90.0 EndSection Section "Device" Identifier "card" Driver "amdgpu" Option "Stereo" "12" EndSection Section "Screen" Identifier "screen" Device "card" Monitor"sony" SubSection "Display" Depth 24 Modes "1920x1080" EndSubSection SubSection "Display" Depth 32 Modes "1920x1080" EndSubSection SubSection "Extensions" Option "Composite" "Disable" EndSubSection EndSection # Make sure you have the relevant Debian packages on your system # to be able to use DRI (libgl1-mesa-dri for example) Section "DRI" Mode 0666 EndSection
RE: [PATCH 1/9] drm/amdgpu: Use backlight power constants
[Public]
> -Original Message-
> From: Thomas Zimmermann
> Sent: Wednesday, July 31, 2024 8:17 AM
> To: maarten.lankho...@linux.intel.com; mrip...@kernel.org;
> airl...@gmail.com; dan...@ffwll.ch
> Cc: amd-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org; Thomas
> Zimmermann ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui
> Subject: [PATCH 1/9] drm/amdgpu: Use backlight power constants
>
> Replace FB_BLANK_ constants with their counterparts from the backlight
> subsystem. The values are identical, so there's no change in functionality or
> semantics.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Xinhui Pan
This patch and the radeon patch are:
Acked-by: Alex Deucher
Feel free to take them via whatever tree makes sense if you are trying to keep
the patches together, or let me know if you want me to pick them up.
Thanks,
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index 25feab188dfe..650ec95bb40a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -215,7 +215,7 @@ void
> amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder
> *amdgpu_encode
> dig->bl_dev = bd;
>
> bd->props.brightness =
> amdgpu_atombios_encoder_get_backlight_brightness(bd);
> - bd->props.power = FB_BLANK_UNBLANK;
> + bd->props.power = BACKLIGHT_POWER_ON;
> backlight_update_status(bd);
>
> DRM_INFO("amdgpu atom DIG backlight initialized\n");
> --
> 2.45.2
RE: [PATCH 1/2] drm/print: drop include debugfs.h and include where needed
[Public] > -Original Message- > From: Jani Nikula > Sent: Wednesday, April 24, 2024 9:55 AM > To: dri-de...@lists.freedesktop.org > Cc: Andrzej Hajda ; Maxime Ripard > ; Jacek Lawrynowicz > ; Stanislaw Gruszka > ; Oded Gabbay ; > Russell King ; David Airlie ; Daniel > Vetter ; Neil Armstrong ; Robert > Foss ; Laurent Pinchart > ; Jonas Karlman ; > Jernej Skrabec ; Maarten Lankhorst > ; Thomas Zimmermann > ; Rodrigo Vivi ; Joonas > Lahtinen ; Tvrtko Ursulin > ; Frank Binns ; Matt Coster > ; Rob Clark ; Abhinav > Kumar ; Dmitry Baryshkov > ; Sean Paul ; Marijn Suijten > ; Karol Herbst ; Lyude > Paul ; Danilo Krummrich ; Deucher, > Alexander ; Koenig, Christian > ; Pan, Xinhui ; Alain > Volmat ; Huang, Ray ; > Zack Rusin ; Broadcom internal kernel review list > ; Lucas De Marchi > ; Thomas Hellström > ; intel-gfx@lists.freedesktop.org; intel- > x...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; > freedr...@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd- > g...@lists.freedesktop.org > Subject: Re: [PATCH 1/2] drm/print: drop include debugfs.h and include where > needed > > On Mon, 22 Apr 2024, Jani Nikula wrote: > > Surprisingly many places depend on debugfs.h to be included via > > drm_print.h. Fix them. > > > > v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe > > > > v2: Also fix ivpu and vmwgfx > > > > Reviewed-by: Andrzej Hajda > > Acked-by: Maxime Ripard > > Link: > > > https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908 > -1- > > jani.nik...@intel.com > > Signed-off-by: Jani Nikula > > While the changes all over the place are small, mostly just adding the > debugfs.h include, please consider acking. I've sent this a few times already. > For radeon: Acked-by: Alex Deucher > Otherwise, I'll merge this by the end of the week, acks or not. > > Thanks, > Jani. > > > > > > > --- > > > > Cc: Jacek Lawrynowicz > > Cc: Stanislaw Gruszka > > Cc: Oded Gabbay > > Cc: Russell King > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Andrzej Hajda > > Cc: Neil Armstrong > > Cc: Robert Foss > > Cc: Laurent Pinchart > > Cc: Jonas Karlman > > Cc: Jernej Skrabec > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: Jani Nikula > > Cc: Rodrigo Vivi > > Cc: Joonas Lahtinen > > Cc: Tvrtko Ursulin > > Cc: Frank Binns > > Cc: Matt Coster > > Cc: Rob Clark > > Cc: Abhinav Kumar > > Cc: Dmitry Baryshkov > > Cc: Sean Paul > > Cc: Marijn Suijten > > Cc: Karol Herbst > > Cc: Lyude Paul > > Cc: Danilo Krummrich > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: "Pan, Xinhui" > > Cc: Alain Volmat > > Cc: Huang Rui > > Cc: Zack Rusin > > Cc: Broadcom internal kernel review list > > > > Cc: Lucas De Marchi > > Cc: "Thomas Hellström" > > Cc: dri-de...@lists.freedesktop.org > > Cc: intel-gfx@lists.freedesktop.org > > Cc: intel...@lists.freedesktop.org > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedr...@lists.freedesktop.org > > Cc: nouv...@lists.freedesktop.org > > Cc: amd-...@lists.freedesktop.org > > --- > > drivers/accel/ivpu/ivpu_debugfs.c | 2 ++ > > drivers/gpu/drm/armada/armada_debugfs.c | 1 + > > drivers/gpu/drm/bridge/ite-it6505.c | 1 + > > drivers/gpu/drm/bridge/panel.c | 2 ++ > > drivers/gpu/drm/drm_print.c | 6 +++--- > > drivers/gpu/drm/i915/display/intel_dmc.c| 1 + > > drivers/gpu/drm/imagination/pvr_fw_trace.c | 1 + > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 ++ > > drivers/gpu/drm/nouveau/dispnv50/crc.c | 2 ++ > > drivers/gpu/drm/radeon/r100.c | 1 + > > drivers/gpu/drm/radeon/r300.c | 1 + > > drivers/gpu/drm/radeon/r420.c | 1 + > > drivers/gpu/drm/radeon/r600.c | 3 ++- > > drivers/gpu/drm/radeon/radeon_fence.c | 1 + > > drivers/gpu/drm/radeon/radeon_gem.c | 1 + > > drivers/gpu/drm/radeon/radeon_ib.c | 2 ++ > > drivers/gpu/drm/radeon/radeon_pm.c | 1 + > > drivers/gpu/drm/radeon/radeon_ring.c| 2 ++ > > drivers/gpu/drm/radeon/radeon_ttm.c | 1 + > > drivers/gpu/drm/radeon/rs400.c | 1 + > > drivers/gpu/drm/radeon/rv515.c | 1 + > > drivers/gpu/drm/sti/sti_drv.c | 1 + &g
Re: [Intel-gfx] [PATCH v6 1/1] Documentation: drm: describing drm properties exposed by various drivers
> -Original Message-
> From: sagar.a.kam...@intel.com [mailto:sagar.a.kam...@intel.com]
> Sent: Tuesday, March 11, 2014 6:38 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sagar Kamble; Rob Landley; Dave Airlie; Daniel Vetter; Laurent Pinchart;
> David Herrmann; Deucher, Alexander; Ville Syrjälä; Purushothaman, Vijay A;
> linux-...@vger.kernel.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v6 1/1] Documentation: drm: describing drm properties
> exposed by various drivers
>
> From: Sagar Kamble
>
> Started documenting drm properties for drm drivers. This patch provides
> information about properties in drm, i915, psb and cdv/gma-500. Information
> about other properties can be added on top of these.
>
> v2: Added description of drm properties in armada, exynos, i2c/ch7006,
> noveau,
> omap, qxl, radeon, rcar-du
>
> v3: Removed "Property Object" column since it is implementation related.
> Property
> type column refined.[Ville's review comments]
>
> v4: Removed whitespace warnings and minor nits. [Randy's review
> comments]
>
> v5: Restructured output for ENUM properties
>
> v6: Review comments on formatting the table. [Laurent's review comments]
>
> Cc: Rob Landley
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: David Herrmann
> Cc: Alex Deucher
> Cc: "Ville Syrjälä"
> Cc: Sagar Kamble
> Cc: "Purushothaman, Vijay A"
> Cc: linux-...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
>
> Signed-off-by: Sagar Kamble
> ---
> Documentation/DocBook/drm.tmpl | 848
> +
> 1 file changed, 848 insertions(+)
>
> diff --git a/Documentation/DocBook/drm.tmpl
> b/Documentation/DocBook/drm.tmpl
> index ed1d6d2..ae5e606 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2317,6 +2317,854 @@ void intel_crt_init(struct drm_device *dev)
>pointer to the target object, a pointer to the previously created
> property
>and an initial instance value.
>
> +
> +
> + The following table gives description of drm properties exposed by
> various
> + modules/drivers.
> +
> +
> +
> +
> +
> +Owner Module/Drivers
> +Group
> +Property Name
> +Type
> +Property Values
> +Object attached
> +Description/Restrictions
> +
> +
> +DRM
> +Generic
> +“EDID”
> +BLOB | IMMUTABLE
> +0
> +Connector
> +Contains id of edid blob ptr object.
> +
> +
> +“DPMS”
> +ENUM
> +{ “On”, “Standby”, “Suspend”, “Off” }
> +Connector
> +Contains DPMS operation mode value.
> +
> +
> +DVI-I
> +“subconnector”
> +ENUM
> +{ “Unknown”, “DVI-D”, “DVI-A” }
> +Connector
> +TBD
> +
> +
> +“select subconnector”
> +ENUM
> +{ “Automatic”, “DVI-D”, “DVI-A” }
> +Connector
> +TBD
> +
> +
> +TV
> +“subconnector”
> +ENUM
> +{ "Unknown", "Composite", "SVIDEO", "Component",
> "SCART" }
> +Connector
> +TBD
> +
> +
> +“select subconnector”
> +ENUM
> +{ "Automatic", "Composite", "SVIDEO", "Component",
> "SCART" }
> +Connector
> +TBD
> +
> +
> +“mode”
> +ENUM
> +{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.
> +Connector
> +TBD
> +
> +
> +“left margin”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“right margin”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“top margin”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“bottom margin”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“brightness”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“contrast”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“flicker reduction”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“overscan”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“saturation”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +“hue”
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +Optional
> +“scaling mode”
> +ENUM
> +{ "None", "Full", "Center", "Full aspect" }
> +Connector
> +TBD
> +
> +
> +“dirty”
> +ENUM | IMMUTABLE
> +{ "Off", "On", "Annotate" }
> +Connector
> +TBD
> +
> +
> +i915
> +Generic
> +"Broadcast RGB"
> +ENUM
> +{
Re: [Intel-gfx] [PATCH] drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH, HEIGHT} caps
> -Original Message-
> From: Damien Lespiau [mailto:damien.lesp...@intel.com]
> Sent: Friday, March 28, 2014 8:31 AM
> To: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org; Sagar Kamble; Chris Wilson; Deucher,
> Alexander; Imre Deak
> Subject: [PATCH] drm: Specify a bit more the
> DRM_CAP_CURSOR_{WIDTH,HEIGHT} caps
>
> Earlier this week, there was a bit of confusion about those new
> capabilities, to the point I think it's better to document the intention
> and API contract.
>
> The comment documents the current situation:
> - the radeon driver returns the only valid size for the hw
> - i915 returns the maximun cursor size
> - other drivers fall back to returning 64x64
>
> The common contract is to return a valid cursor size.
>
> Cc: Sagar Kamble
> Cc: Chris Wilson
> Cc: Alex Deucher
> Cc: Imre Deak
> Signed-off-by: Damien Lespiau
Reviewed-by: Alex Deucher
> ---
> include/uapi/drm/drm.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b06c8ed..ec6b259 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -619,6 +619,15 @@ struct drm_gem_open {
> #define DRM_PRIME_CAP_EXPORT0x2
> #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
> #define DRM_CAP_ASYNC_PAGE_FLIP 0x7
> +/*
> + * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid
> widthxheight
> + * combination for the hardware cursor. The intention is that a hardware
> + * agnostic userspace can query a cursor plane size to use.
> + *
> + * Note that the cross-driver contract is to merely return a valid size;
> + * drivers are free to attach another meaning on top, eg. i915 returns the
> + * maximum plane size.
> + */
> #define DRM_CAP_CURSOR_WIDTH 0x8
> #define DRM_CAP_CURSOR_HEIGHT0x9
>
> --
> 1.8.3.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/7] Rename DP training vswing/pre-emph defines
> -Original Message- > From: Jindal, Sonika [mailto:sonika.jin...@intel.com] > Sent: Wednesday, August 27, 2014 2:09 AM > To: Jindal, Sonika; intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; kgene@samsung.com; > jg1@samsung.com; airl...@linux.ie; Deucher, Alexander; > thierry.red...@gmail.com; Lespiau, Damien > Subject: RE: [Intel-gfx] [PATCH v2 0/7] Rename DP training vswing/pre-emph > defines > > Hi, > > Did anybody get a chance to review the patches? > Adding respective owners for different drivers.. I gave my RB to danvet on IRC, but if you need it: Reviewed-by: Alex Deucher > > Thanks, > Sonika > > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Jindal, Sonika > Sent: Tuesday, August 19, 2014 1:42 PM > To: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2 0/7] Rename DP training vswing/pre-emph > defines > > Hi, > > Did anybody get a chance to review other patches in this series? > I got r-b for 2 patches (patches with changes in drm and i915) from Damien. > > Thanks, > Sonika > > -Original Message- > From: Jindal, Sonika > Sent: Friday, August 8, 2014 4:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Jindal, Sonika > Subject: [PATCH v2 0/7] Rename DP training vswing/pre-emph defines > > From: Sonika Jindal > > Rename the defines to have levels instead of values for vswing and pre- > emph levels as the values may differ in other scenarios like low vswing of > eDP 1.4 where the values are different. > Updated in all the drivers as well > > v2: Keeping the old defines in first patch and removing them in last patch. > Used cocci semantic patch to replace the defines. > > Sonika Jindal (7): > drm: Renaming DP training vswing pre emph defines > drm/i915: Renaming DP training vswing pre emph defines > drm/exynos: Renaming DP training vswing pre emph defines > drm/gma500: Renaming DP training vswing pre emph defines > drm/radeon: Renaming DP training vswing pre emph defines > drm/tegra: Renaming DP training vswing pre emph defines > drm: Remove old defines for vswing and pre-emph values > > drivers/gpu/drm/exynos/exynos_dp_core.c |4 +- > drivers/gpu/drm/gma500/cdv_intel_dp.c |4 +- > drivers/gpu/drm/gma500/intel_bios.c | 16 +-- > drivers/gpu/drm/i915/intel_bios.c | 16 +-- > drivers/gpu/drm/i915/intel_dp.c | 194 > +++ > drivers/gpu/drm/radeon/atombios_dp.c|4 +- > drivers/gpu/drm/tegra/dpaux.c |4 +- > include/drm/drm_dp_helper.h | 16 +-- > 8 files changed, 129 insertions(+), 129 deletions(-) > > -- > 1.7.10.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
RE: [PATCH v4] docs/gpu: ci: update flake tests requirements
[Public]
> -Original Message-
> From: Vignesh Raman
> Sent: Tuesday, October 1, 2024 9:51 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; amd-
> g...@lists.freedesktop.org
> Cc: dani...@collabora.com; helen.ko...@collabora.com; airl...@gmail.com;
> dan...@ffwll.ch; robdcl...@gmail.com; guilherme.ga...@collabora.com;
> sergi.blanch.to...@collabora.com; deborah.brou...@collabora.com;
> dmitry.barysh...@linaro.org; mrip...@kernel.org; rodrigo.v...@intel.com;
> quic_abhin...@quicinc.com; linux-media...@lists.infradead.org; linux-
> amlo...@lists.infradead.org; linux-rockc...@lists.infradead.org; linux-arm-
> m...@vger.kernel.org; intel-gfx@lists.freedesktop.org;
> virtualizat...@lists.linux.dev;
> linux-ker...@vger.kernel.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH v4] docs/gpu: ci: update flake tests requirements
>
> Hi amdgpu Maintainers,
>
> On 30/09/24 15:22, Vignesh Raman wrote:
> > Update the documentation to specify linking to a relevant GitLab issue
> > or email report for each new flake entry. Added specific GitLab issue
> > urls for amdgpu, i915, msm and xe driver.
> >
> > Acked-by: Maxime Ripard
> > Acked-by: Rodrigo Vivi #intel and xe
> > Acked-by: Abhinav Kumar # msm
> > Acked-by: Dmitry Baryshkov # msm
> > Signed-off-by: Vignesh Raman
> > ---
> >
> > v2:
> > - Add gitlab issue link for msm driver.
> >
> > v3:
> > - Update docs to specify we use email reporting or GitLab issues for flake
> > entries.
> >
> > v4:
> > - Add gitlab issue link for xe driver.
> >
> > ---
> > Documentation/gpu/automated_testing.rst | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/gpu/automated_testing.rst
> > b/Documentation/gpu/automated_testing.rst
> > index 2d5a28866afe..6d7c6086034d 100644
> > --- a/Documentation/gpu/automated_testing.rst
> > +++ b/Documentation/gpu/automated_testing.rst
> > @@ -68,19 +68,25 @@ known to behave unreliably. These tests won't cause a
> job to fail regardless of
> > the result. They will still be run.
> >
> > Each new flake entry must be associated with a link to the email
> > reporting the -bug to the author of the affected driver, the board
> > name or Device Tree name of -the board, the first kernel version
> > affected, the IGT version used for tests, -and an approximation of the
> > failure rate.
> > +bug to the author of the affected driver or the relevant GitLab
> > +issue. The entry must also include the board name or Device Tree
> > +name, the first kernel version affected, the IGT version used for tests,
> > and an
> approximation of the failure rate.
> >
> > They should be provided under the following format::
> >
> > - # Bug Report: $LORE_OR_PATCHWORK_URL
> > + # Bug Report: $LORE_URL_OR_GITLAB_ISSUE
> > # Board Name: broken-board.dtb
> > # Linux Version: 6.6-rc1
> > # IGT Version: 1.28-gd2af13d9f
> > # Failure Rate: 100
> > flaky-test
> >
> > +Use the appropriate link below to create a GitLab issue:
> > +amdgpu driver: https://gitlab.freedesktop.org/drm/amd/-/issues
>
> Please could you ack this patch. Thanks.
Acked-by: Alex Deucher
>
> > +i915 driver: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues
> > +msm driver: https://gitlab.freedesktop.org/drm/msm/-/issues
> > +xe driver: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues
> > +
> > drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
> > ---
> >
>
> Regards,
> Vignesh
RE: [PATCH 28/28] drm: Remove DRM aperture helpers
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Thomas
> Zimmermann
> Sent: Monday, September 30, 2024 9:03 AM
> To: javi...@redhat.com; airl...@gmail.com; sim...@ffwll.ch;
> maarten.lankho...@linux.intel.com; mrip...@kernel.org
> Cc: dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org; Thomas Zimmermann
> ; Jonathan Corbet
> Subject: [PATCH 28/28] drm: Remove DRM aperture helpers
>
> The DRM aperture helpers are wrappers around video helpers from
> . There are no callers of these functions. Remove them
> entirely.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Jonathan Corbet
Series is:
Acked-by: Alex Deucher
> ---
> Documentation/gpu/drm-internals.rst | 12 --
> MAINTAINERS | 2 -
> drivers/gpu/drm/Makefile| 1 -
> drivers/gpu/drm/drm_aperture.c | 192
> include/drm/drm_aperture.h | 38 --
> 5 files changed, 245 deletions(-)
> delete mode 100644 drivers/gpu/drm/drm_aperture.c delete mode 100644
> include/drm/drm_aperture.h
>
> diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-
> internals.rst
> index 11d9a5730fb2..cb9ae282771c 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -75,18 +75,6 @@ Module Initialization .. kernel-doc::
> include/drm/drm_module.h
> :doc: overview
>
> -Managing Ownership of the Framebuffer Aperture
> ---
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
> - :doc: overview
> -
> -.. kernel-doc:: include/drm/drm_aperture.h
> - :internal:
> -
> -.. kernel-doc:: drivers/gpu/drm/drm_aperture.c
> - :export:
> -
> Device Instance and Driver Handling
> ---
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5a0b7bfb6315..e71e12085a9f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7097,12 +7097,10 @@ M:Javier Martinez Canillas
> L: dri-de...@lists.freedesktop.org
> S: Maintained
> T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> -F: drivers/gpu/drm/drm_aperture.c
> F: drivers/gpu/drm/tiny/ofdrm.c
> F: drivers/gpu/drm/tiny/simpledrm.c
> F: drivers/video/aperture.c
> F: drivers/video/nomodeset.c
> -F: include/drm/drm_aperture.h
> F: include/linux/aperture.h
> F: include/video/nomodeset.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index
> 3894f43f6d47..31d8bf60a2fd 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -34,7 +34,6 @@ endif
> subdir-ccflags-$(CONFIG_DRM_WERROR) += -Werror
>
> drm-y := \
> - drm_aperture.o \
> drm_atomic.o \
> drm_atomic_uapi.o \
> drm_auth.o \
> diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
> deleted
> file mode 100644 index 5729f3bb4398..
> --- a/drivers/gpu/drm/drm_aperture.c
> +++ /dev/null
> @@ -1,192 +0,0 @@
> -// SPDX-License-Identifier: MIT
> -
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -
> -/**
> - * DOC: overview
> - *
> - * A graphics device might be supported by different drivers, but only one
> - * driver can be active at any given time. Many systems load a generic
> - * graphics drivers, such as EFI-GOP or VESA, early during the boot process.
> - * During later boot stages, they replace the generic driver with a
> dedicated,
> - * hardware-specific driver. To take over the device the dedicated driver
> - * first has to remove the generic driver. DRM aperture functions manage
> - * ownership of DRM framebuffer memory and hand-over between drivers.
> - *
> - * DRM drivers should call drm_aperture_remove_conflicting_framebuffers()
> - * at the top of their probe function. The function removes any generic
> - * driver that is currently associated with the given framebuffer memory.
> - * If the framebuffer is located at PCI BAR 0, the rsp code looks as in the
> - * example given below.
> - *
> - * .. code-block:: c
> - *
> - * static const struct drm_driver example_driver = {
> - * ...
> - * };
> - *
> - * static int remove_conflicting_framebuffers(struct pci_dev *pdev)
> - * {
> - * resource_size_t base, size;
> - * int ret;
> - *
> - * base = pci_resource_start(pdev, 0);
> - * size = pci_resource_len(pdev, 0);
> - *
> - * return drm_aperture_remove_conflicting_framebuffers(base, size,
> - *
> &example_driver);
> - * }
> - *
> - * static int probe(struct pci_dev *pdev)
> - * {
> - * int ret;
> - *
> - * // Remove any generic drivers...
> - * ret = remove_conflicting_framebuffers(pdev);
> - * if (ret)
> - * return ret;
> - *
> - * // ... and initialize the hardware.
> - * ...
> - *
> - *
RE: [PATCH v2 09/19] drm/amdgpu: Pass along the format info from .fb_create() to drm_helper_mode_fill_fb_struct()
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Ville
> Syrjala
> Sent: Tuesday, July 1, 2025 5:07 AM
> To: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org; Deucher,
> Alexander ; amd-...@lists.freedesktop.org;
> Thomas Zimmermann
> Subject: [PATCH v2 09/19] drm/amdgpu: Pass along the format info from
> .fb_create() to drm_helper_mode_fill_fb_struct()
>
> From: Ville Syrjälä
>
> Plumb the format info from .fb_create() all the way to
> drm_helper_mode_fill_fb_struct() to avoid the redundant lookup.
>
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Reviewed-by: Thomas Zimmermann
> Signed-off-by: Ville Syrjälä
Series is:
Acked-by: Alex Deucher
Feel free to take the amdgpu/radeon bits via drm-misc.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 4cbbae543e34..2bc0d9a2509f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1196,13 +1196,14 @@ static int amdgpu_display_get_fb_info(const struct
> amdgpu_framebuffer *amdgpu_fb static int
> amdgpu_display_gem_fb_verify_and_init(struct drm_device *dev,
>struct amdgpu_framebuffer *rfb,
>struct drm_file *file_priv,
> + const struct drm_format_info
> *info,
>const struct drm_mode_fb_cmd2
> *mode_cmd,
>struct drm_gem_object *obj)
> {
> int ret;
>
> rfb->base.obj[0] = obj;
> - drm_helper_mode_fill_fb_struct(dev, &rfb->base, NULL, mode_cmd);
> + drm_helper_mode_fill_fb_struct(dev, &rfb->base, info, mode_cmd);
> /* Verify that the modifier is supported. */
> if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
> mode_cmd->modifier[0])) {
> @@ -1331,7 +1332,7 @@ amdgpu_display_user_framebuffer_create(struct
> drm_device *dev,
> }
>
> ret = amdgpu_display_gem_fb_verify_and_init(dev, amdgpu_fb, file_priv,
> - mode_cmd, obj);
> + info, mode_cmd, obj);
> if (ret) {
> kfree(amdgpu_fb);
> drm_gem_object_put(obj);
> --
> 2.49.0
