Re: [Nouveau] [PATCH 02/15] drm/amdgpu: use drm_* functions instead of duplicated code in amdgpu driver
On 2021-10-15 07:37, Claudio Suarez wrote:
> a) Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. The amdgpu driver still calls
> drm_detect_hdmi_monitor() to retrieve the same information, which
> is less efficient. Change to drm_display_info.is_hdmi
>
> This is a TODO task in Documentation/gpu/todo.rst
>
> b) drm_display_info is updated by drm_get_edid() or
> drm_connector_update_edid_property(). In the amdgpu driver it is almost
> always updated when the edid is read in amdgpu_connector_get_edid(),
> but not always. Change amdgpu_connector_get_edid() and
> amdgpu_connector_free_edid() to keep drm_display_info updated. This allows a)
> to work properly.
>
> c) Use drm_edid_get_monitor_name() instead of duplicating the code that
> parses the EDID in dm_helpers_parse_edid_caps()
>
> Also, remove the unused "struct dc_context *ctx" parameter in
> dm_helpers_parse_edid_caps()
>
Thanks for this work.
The fact that you listed three separate changes in this commit
is a clear indication that this patch should be three separate
patches instead. Separating the functional bits from the straight
refactor will help with bisection if this leads to a regression.
All changes look reasonable to me, though. With this patch split
into three patches in the sequence (b), (c), then (a) this is
Reviewed-by: Harry Wentland
Harry
> Signed-off-by: Claudio Suarez
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +++
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.h| 2 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 4 +-
> .../gpu/drm/amd/amdgpu/atombios_encoders.c| 6 +--
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 39 ++-
> drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
> drivers/gpu/drm/amd/display/dc/dm_helpers.h | 2 +-
> 9 files changed, 39 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index b9c11c2b2885..7b41a1120b70 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -25,6 +25,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -108,7 +109,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> case DRM_MODE_CONNECTOR_DVII:
> case DRM_MODE_CONNECTOR_HDMIB:
> if (amdgpu_connector->use_digital) {
> - if
> (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
> if (connector->display_info.bpc)
> bpc = connector->display_info.bpc;
> }
> @@ -116,7 +117,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> break;
> case DRM_MODE_CONNECTOR_DVID:
> case DRM_MODE_CONNECTOR_HDMIA:
> - if (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
> if (connector->display_info.bpc)
> bpc = connector->display_info.bpc;
> }
> @@ -125,7 +126,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> dig_connector = amdgpu_connector->con_priv;
> if ((dig_connector->dp_sink_type ==
> CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
> (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP) ||
> - drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + (amdgpu_connector_is_hdmi_monitor(connector))) {
> if (connector->display_info.bpc)
> bpc = connector->display_info.bpc;
> }
> @@ -149,7 +150,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector
> *connector)
> break;
> }
>
> - if (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
> /*
>* Pre DCE-8 hw can't handle > 12 bpc, and more than 12 bpc
> doesn't make
>* much sense without support for > 12 bpc framebuffers. RGB
> 4:4:4 at
> @@ -315,8 +316,10 @@ static void amdgpu_connector_get_edid(struct
> drm_connector *connector)
> i
Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On 2021-07-23 3:14 p.m., Cornij, Nikola wrote:
> [AMD Official Use Only]
>
> +Harry
>
> -Original Message-
> From: Daniel Vetter
> Sent: Friday, July 23, 2021 11:23 AM
> To: Arnd Bergmann
> Cc: Daniel Vetter ; Ben Skeggs ; David
> Airlie ; Lyude Paul ; Arnd Bergmann
> ; Ville Syrjälä ; Cornij,
> Nikola ; dri-devel ;
> Nouveau Dev ; Linux Kernel Mailing List
>
> Subject: Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with
> CONFIG_BACKLIGHT=n
>
> On Fri, Jul 23, 2021 at 12:16:31PM +0200, Arnd Bergmann wrote:
>> On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
>>>
>>> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
From: Arnd Bergmann
When the backlight support is disabled, the driver fails to build:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
'nv50_sor_atomic_disable':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
nouveau_connector' has no member named 'backlight'
1665 | struct nouveau_backlight *backlight =
nv_connector->backlight;
| ^~
drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
undefined type 'struct nouveau_backlight'
1670 | if (backlight && backlight->uses_dpcd) {
| ^~
drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
undefined type 'struct nouveau_backlight'
1671 | ret = drm_edp_backlight_disable(aux,
&backlight->edp_info);
|^~
The patch that introduced the problem already contains some #ifdef
checks, so just add another one that makes it build again.
Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD
backlight support for nouveau")
Signed-off-by: Arnd Bergmann
>>>
>>> Can we just toss the idea that BACKTLIGHT=n is a reasonable config
>>> for drm drivers using backlights, and add depends BACKLIGHT to all
>>> of them?
>>>
>>> I mean this is a perfect source of continued patch streams to keep
>>> us all busy, but beyond that I really don't see the point ... I
>>> frankly have better things to do, and especially with the big
>>> drivers we have making backlight optional saves comparitively nothing.
>>> -Daniel
>>
>> Yes! I'd definitely be in favor of that, I've wasted way too much time
>> trying to sort through dependency loops and other problems with backlight
>> support.
>>
>> Maybe we should leave the drivers/video/fbdev/ drivers untouched in
>> this regard, at least for the moment, but for the drivers/gpu/drm
>> users of backlight that would be a nice simplification, and even the
>> smallest ones are unlikely to be used on systems that are too memory
>> constrained to deal with 4KB extra .text.
>
> Yeah I think we can do this entirely ad-hoc, i.e. any time the backlight
> wheel wobbles off again we nail it down for good for that driver with a
> depends on BACKGLIGHT and remove any lingering #ifdef all over.
>
> If you want maybe start out with the biggest drm drivers in a series, I think
> if nouveau/amdgpu/i915 folks ack this you're good to go to just convert as
> things get in the way.
Sounds like a good idea to me.
Harry
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch/>>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 2021 X.Org Foundation Election Candidates
Correction, we have 7 candidates for 4 positions. I seem to have overlooked Walter Harms's nomination email. My sincerest apologies. His personal affiliation, statement of contribution, and personal statement are below. The full slate of candidates can be found at https://wiki.freedesktop.org/xorg/BoardOfDirectors/Elections/2021/ ## Walter Harms __Current Affiliation:__ Scientist @ Bundesamt für Strahlenschutz __Statement of Contribution:__ I am involved into the open source since studying physics several years ago. I am also certified trainer for programmers. I contributed in the last years to projects like linux kernel, man pages, etc. Since a few years i have commit rights for X11 and did some work on libX11 and libXt. __Personal Statement:__ Since i started to become a trainer i have a predilection for documentation. Xorg has a lot good documentation but today is it less. NTL what is important is the application. I would like to see more training material and more X11 applications especially for remote access. But i was never involved in the xorg organisation. So i see myself more as an apprentice. We will see if i can help. Thanks, Harry Wentland, on behalf of the X.Org elections committee On 2021-03-15 2:47 p.m., Harry Wentland wrote: To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 22 March 2021. We have 6 candidates who are running for 4 seats. They are (in alphabetical order): Samuel Iglesias Gonsálvez Manasi Navare Lyude Paul Rodrigo Siqueira Lucas Stach Daniel Vetter Attached below are the Personal Statements each candidate submitted for your consideration along with their Statements of Contribution that they submitted with the membership application. Please review each of the candidates' statements to help you decide whom to vote for during the upcoming election. If you have questions of the candidates, you should feel free to ask them here on the mailing list. The election committee will provide detailed instructions on how the voting system will work when the voting period begins. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Publication of Candidates & start of Candidate QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ** Nominees ** ## Samuel Iglesias Gonsálvez __Current Affiliation:__ Igalia __Personal Statement:__ I have been contributing to Mesa and piglit for 7 years improving open-source drivers for both OpenGL and Vulkan. During my time on the board, I have become the XDC organization coordinator and the XDC CFP committee chair, due to my experience organizing the XDC 2018 in A Coruña, Spain. Thanks to these experiences, I have been deeply involved in the XDC organization process, where I have helped make a great and welcoming conference every year. If I am elected, I plan to continue leading both the XDC organization process and the XDC CFP committee. ## Manasi Navare __Current Affiliation:__ Intel __Statement of contribution:__ I am a lead contributor to Intel’s Open source graphics kernel driver i915 as well as to the Linux Kernel DRM subsystem. One of my most widely used contributions is the Display Port Compliance code in i915, DRM as well as in Xserver and IGT to make the entire graphics stack Display Port compliant and reward the end users with black screen free displays. I have also enabled features like Display stream compression across DRM and i915 as per VESA’s DSC specification for Display Port. Most recently I have been working with both the DRM and i915 community as well as the AMD developers to implement and enable adaptive sync feature for variable refresh rate on display drivers for enhanced gaming experience. I also have commit rights to several upstream projects like drm-intel, drm-misc and Intel GPU Tools. I have served on X.org board of directors for last 2 years organizing XDC conferences, being on Code of Conduct committee for X.org and Freedesktop and taking over the treasurer responsibility since September 2020. __Personal Statement:__ I have been a Linux Open Source contributor for last 7 years since I joined Intel's Open source technology center. My major contributions are in enabling display interfaces and develop display features in upcoming display specifications in i915 and Linux DRM subsystem. I have presented several talks at Linux Graphics conferences like Embedded Linux Conference, XDC and FOSDEM on several graphics display features like Display Port compliance and Display Stream Compression, Tiled display suppor
[Nouveau] 2021 X.Org Foundation Election Candidates
To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 22 March 2021. We have 6 candidates who are running for 4 seats. They are (in alphabetical order): Samuel Iglesias Gonsálvez Manasi Navare Lyude Paul Rodrigo Siqueira Lucas Stach Daniel Vetter Attached below are the Personal Statements each candidate submitted for your consideration along with their Statements of Contribution that they submitted with the membership application. Please review each of the candidates' statements to help you decide whom to vote for during the upcoming election. If you have questions of the candidates, you should feel free to ask them here on the mailing list. The election committee will provide detailed instructions on how the voting system will work when the voting period begins. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Publication of Candidates & start of Candidate QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ** Nominees ** ## Samuel Iglesias Gonsálvez __Current Affiliation:__ Igalia __Personal Statement:__ I have been contributing to Mesa and piglit for 7 years improving open-source drivers for both OpenGL and Vulkan. During my time on the board, I have become the XDC organization coordinator and the XDC CFP committee chair, due to my experience organizing the XDC 2018 in A Coruña, Spain. Thanks to these experiences, I have been deeply involved in the XDC organization process, where I have helped make a great and welcoming conference every year. If I am elected, I plan to continue leading both the XDC organization process and the XDC CFP committee. ## Manasi Navare __Current Affiliation:__ Intel __Statement of contribution:__ I am a lead contributor to Intel’s Open source graphics kernel driver i915 as well as to the Linux Kernel DRM subsystem. One of my most widely used contributions is the Display Port Compliance code in i915, DRM as well as in Xserver and IGT to make the entire graphics stack Display Port compliant and reward the end users with black screen free displays. I have also enabled features like Display stream compression across DRM and i915 as per VESA’s DSC specification for Display Port. Most recently I have been working with both the DRM and i915 community as well as the AMD developers to implement and enable adaptive sync feature for variable refresh rate on display drivers for enhanced gaming experience. I also have commit rights to several upstream projects like drm-intel, drm-misc and Intel GPU Tools. I have served on X.org board of directors for last 2 years organizing XDC conferences, being on Code of Conduct committee for X.org and Freedesktop and taking over the treasurer responsibility since September 2020. __Personal Statement:__ I have been a Linux Open Source contributor for last 7 years since I joined Intel's Open source technology center. My major contributions are in enabling display interfaces and develop display features in upcoming display specifications in i915 and Linux DRM subsystem. I have presented several talks at Linux Graphics conferences like Embedded Linux Conference, XDC and FOSDEM on several graphics display features like Display Port compliance and Display Stream Compression, Tiled display support, Adaptive Sync or Variable Refresh rate kernel support for gaming and I have been already actively involved in IRC discussions with DRM and i915 maintainers to constantly provide any solution on display port questions and work on improving the kernel documentation and code quality. I have served on the X.org board of directors since 2019 helping in XDC 2019 and XDC 2020 organization and for ensuring the Code of Conduct on the X.org community and during XDC events. I have previously mentored for the KMS project in Outreachy 2018 winter program as well as administered the Google summer of code 2019 program and will continue to do so whenever I get an opportunity. I joined the Code of Conduct Freedesktop committee as well to ensure it is followed on all the Freedesktop projects and open source channels. I have recently stepped up to take over the treasurer responsibility as part of the X.org board and working with all our sponsors to get the invoicing for the X.org events. If I get elected I would like to continue being a treasurer managing the XDC sponsorship and invoicing responsibilities as well as continue serving on the Code of conduct committee for X.org and Freedesktop. In addition to this I would like to help out on XDC event website or
[Nouveau] 2021 X.Org Foundation Membership renewal period extended to Mar 18
Due to some hickups with some of the early election emails and the large spike in membership registrations the elections committee decided to extend the membership deadline by one week to Mar 18, 2021. If you have not renewed your membership please do so by Thursday, Mar 18 at https://members.x.org. The nominated candidates will be announced on Sunday, allowing for a week of Candidate QA before the start of election on Mon Mar 22. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Publication of Candidates & start of Candidate QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 2021 X.Org Foundation Membership renewal ENDS on THURSDAY Mar 11
The nomination period for the 2021 X.Org Foundation Board of Directors Election closed yesterday and the election is rapidly approaching. We currently only see membership renewals for 59 people. If you have not renewed your membership please do so by Thursday, Mar 11 at https://members.x.org. The nominated candidates will be announced a week from yesterday. There were some hickups with our earlier emails and we realize some of you may have not received them. To ensure you receive this email we're BCCing any member that has been registered as a member in the last 2 years. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 2021 X.Org Board of Directions Nomination period ends next Sunday
Unfortunately my previous email seems to not have been received by many people. I will send this email separately to each mailing list to hopefully get better coverage. The nomination period is currently ongoing. So far we have received 3 nominations and will need at least 4 to fill the vacant spots on the board. We hope you will consider putting your nomination forward. To nominate yourself or someone else please send the nomination, along with a personal statement to elections at x dot org. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 2021 X.Org Board of Directors Elections Nomination period is NOW
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2021 election are now open and will remain open until Sunday, the 7th of March. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2020 were Eric Anholt, Mark Filion, Keith Packard, and Harry Wentland. They will continue to serve until their term ends in 2022. Current directors whose term expires in 2021 are Samuel Iglesias Gonsálvez, Manasi D Navare, Lyude Paul, and Daniel Vetter. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations must be received before the end of day on Sunday, the 7th of March. Membership applications or renewals and completed personal statements must be received no later than the end of day on Thursday, the 11tth of March. The slate of candidates will be published on Monday, the 15th of March and candidate Q&A will begin then. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 2021 X.Org Foundation Membership renewal and election schedule
The 2021 X.Org Foundation elections are rapidly approaching. In preparation of the elections we would like to remind you that members will need to renew their membership each year in order to vote. Please take the time to renew your membership by logging into https://members.x.org and clicking on the "Apply" button to apply for the 2021-2022 membership. We would also like to encourage you to start considering yourself or someone else for nomination to the board. We will send another email to start the official nomination period when it opens. ** Election Schedule ** Nomination period Start: Mon 22nd February Nomination period End: Sun 7th March Deadline of X.Org membership application or renewal: Thu 11th March Publication of Candidates & start of Candidate QA: Mon 15th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v8 1/6] drm/dp_mst: Add PBN calculation for DSC modes
On 2019-08-26 2:05 p.m., David Francis wrote:
> With DSC, bpp can be fractional in multiples of 1/16.
>
> Change drm_dp_calc_pbn_mode to reflect this, adding a new
> parameter bool dsc. When this parameter is true, treat the
> bpp parameter as having units not of bits per pixel, but
> 1/16 of a bit per pixel
>
> v2: Don't add separate function for this
>
> Cc: amd-...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Reviewed-by: Manasi Navare
> Reviewed-by: Lyude Paul
Reviewed-by: Harry Wentland
Harry
> Signed-off-by: David Francis
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c| 16
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 2 +-
> include/drm/drm_dp_mst_helper.h | 3 +--
> 6 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index a0ed0154a9f0..abafb5221b44 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -235,7 +235,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
>
> /* TODO need to know link rate */
>
> - pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
>
> slots = drm_dp_find_vcpi_slots(mst_mgr, pbn);
> ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port, pbn, slots);
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 82add736e17d..3e7b7553cf4d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3534,10 +3534,11 @@ 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
> *
> * This uses the formula in the spec to calculate the PBN value for a mode.
> */
> -int drm_dp_calc_pbn_mode(int clock, int bpp)
> +int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
> {
> u64 kbps;
> s64 peak_kbps;
> @@ -3555,11 +3556,18 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
>* peak_kbps *= (1006/1000)
>* peak_kbps *= (64/54)
>* peak_kbps *= 8convert to bytes
> + *
> + * If the bpp is in units of 1/16, further divide by 16. Put this
> + * factor in the numerator rather than the denominator to avoid
> + * integer overflow
>*/
>
> numerator = 64 * 1006;
> denominator = 54 * 8 * 1000 * 1000;
>
> + if (dsc)
> + numerator /= 16;
> +
> kbps *= numerator;
> peak_kbps = drm_fixp_from_fraction(kbps, denominator);
>
> @@ -3570,19 +3578,19 @@ EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
> static int test_calc_pbn_mode(void)
> {
> int ret;
> - ret = drm_dp_calc_pbn_mode(154000, 30);
> + ret = drm_dp_calc_pbn_mode(154000, 30, false);
> if (ret != 689) {
> DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
> expected PBN %d, actual PBN %d.\n",
> 154000, 30, 689, ret);
> return -EINVAL;
> }
> - ret = drm_dp_calc_pbn_mode(234000, 30);
> + ret = drm_dp_calc_pbn_mode(234000, 30, false);
> if (ret != 1047) {
> DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
> expected PBN %d, actual PBN %d.\n",
> 234000, 30, 1047, ret);
> return -EINVAL;
> }
> - ret = drm_dp_calc_pbn_mode(297000, 24);
> + ret = drm_dp_calc_pbn_mode(297000, 24, false);
> if (ret != 1063) {
> DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
> expected PBN %d, actual PBN %d.\n",
> 297000, 24, 1063, ret);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2c5ac3dd647f..4f17f61f4453 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -61,7 +61,7 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
> crtc_state->pipe_bpp = bpp;
>
> crtc_st
Re: [Nouveau] [PATCH v2 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
On 2018-09-19 07:08 PM, Lyude Paul wrote: > Currently the way that we prevent userspace from performing new modesets > on MST connectors that have just been destroyed is rather broken. > There's nothing in the actual DRM DP MST topology helpers that checks > whether or not a connector still exists, instead each DRM driver does > this on it's own, usually by returning NULL from the best_encoder > callback which in turn, causes the atomic commit to fail. > > However, this is wrong in a rather subtle way. If ->best_encoder() > returns NULL, this makes ALL modesets involving the connector fail. This > includes modesets from userspace that would shut off the CRTCs being > used by the connector. Since this results in blocking any changes to a > connector's DPMS prop, it has the sideaffect of preventing legacy > modesetting users from ever disabling a CRTC that was previously enabled > for use in an MST topology. An example of this, where X tries to > change the DPMS property of an MST connector that was just detached from > the system: > > [ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > [CONNECTOR:82:DP-6] > [ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > [CONNECTOR:82:DP-6] status updated from connected to disconnected > [ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > [CONNECTOR:82:DP-6] disconnected > [ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1) > [ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event > ... > [ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, > DRM_IOCTL_MODE_SETPROPERTY > [ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state > 7155ba49 > [ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1) > [ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1) > [ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] > 97a6396e state to 7155ba49 > [ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all > current connectors for [CRTC:41:head-0] to 7155ba49 > [ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3) > [ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4) > [ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added > [CONNECTOR:82:DP-6] 87427144 state to 7155ba49 > [ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 7155ba49 > [ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > [CRTC:41:head-0] active changed > [ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > Updating routing for [CONNECTOR:82:DP-6] > [ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No > suitable encoder found for [CONNECTOR:82:DP-6] > [ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for > 7155ba49 failed: -22 > [ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic > state 7155ba49 > [ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4) > [ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3) > [ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2) > [ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2) > [ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state > 7155ba49 > [ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2) > [ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22 > > While this doesn't usually result in any errors that would be obvious to > the user, it does result in us leaving display resources on. This in > turn leads to unwanted sideaffects like inactive GPUs being left on > (usually from the resulting leaked runtime PM ref). > > So, provide an easier way of doing this that doesn't require breaking > ->best_encoder(): add a common drm_dp_mst_connector_atomic_check() > function that DRM drivers can call in order to have CRTC enabling > commits fail automatically if the MST port driving the connector no > longer exists. We'll also be able to expand upon this later as well once > we add MST fallback retraining support. > > Changes since v1: > - Use list_for_each_entry_safe in drm_dp_mst_connector_still_exists() - > Julia Lawall > > Signed-off-by: Lyude Paul > Cc: Julia Lawall > Cc: sta...@vger.kernel.org Whoops, missed the v2 earlier. It's still Acked-by: Harry Wentland Harry > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++ > include/drm/drm_dp_mst_helper.h | 3 ++ > 2 files changed, 79 insertions(+) > > diff --git a/driver
Re: [Nouveau] [PATCH 6/6] drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check()
On 2018-09-18 07:06 PM, Lyude Paul wrote:
> Hook this into amdgpu's atomic check for their connectors so they never
> get modesets on no-longer-present MST connectors. We'll also expand on
> this later once we add DP MST fallback retraining support.
>
> As well, turns out that the only atomic DRM driver without the
> ->best_encoder() bug is amdgpu. Congrats AMD!
>
> Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 12
> 1 file changed, 12 insertions(+)
>
> 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 9a300732ba37..d011a39f17b2 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
> @@ -294,10 +294,22 @@ static struct drm_encoder *dm_mst_best_encoder(struct
> drm_connector *connector)
> return &amdgpu_dm_connector->mst_encoder->base;
> }
>
> +static int
> +amdgpu_dm_mst_connector_atomic_check(struct drm_connector *connector,
> + struct drm_connector_state *new_cstate)
> +{
> + struct amdgpu_dm_connector *aconnector =
> + to_amdgpu_dm_connector(connector);
> +
> + return drm_dp_mst_connector_atomic_check(connector, new_cstate,
> + &aconnector->mst_mgr);
> +}
> +
> static const struct drm_connector_helper_funcs
> dm_dp_mst_connector_helper_funcs = {
> .get_modes = dm_dp_mst_get_modes,
> .mode_valid = amdgpu_dm_connector_mode_valid,
> .best_encoder = dm_mst_best_encoder,
> + .atomic_check = amdgpu_dm_mst_connector_atomic_check,
> };
>
> static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
On 2018-09-18 07:06 PM, Lyude Paul wrote: > Currently the way that we prevent userspace from performing new modesets > on MST connectors that have just been destroyed is rather broken. > There's nothing in the actual DRM DP MST topology helpers that checks > whether or not a connector still exists, instead each DRM driver does > this on it's own, usually by returning NULL from the best_encoder > callback which in turn, causes the atomic commit to fail. > > However, this is wrong in a rather subtle way. If ->best_encoder() > returns NULL, this makes ALL modesets involving the connector fail. This > includes modesets from userspace that would shut off the CRTCs being > used by the connector. Since this results in blocking any changes to a > connector's DPMS prop, it has the sideaffect of preventing legacy > modesetting users from ever disabling a CRTC that was previously enabled > for use in an MST topology. An example of this, where X tries to > change the DPMS property of an MST connector that was just detached from > the system: > > [ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > [CONNECTOR:82:DP-6] > [ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > [CONNECTOR:82:DP-6] status updated from connected to disconnected > [ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] > [CONNECTOR:82:DP-6] disconnected > [ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1) > [ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event > ... > [ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, > DRM_IOCTL_MODE_SETPROPERTY > [ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state > 7155ba49 > [ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1) > [ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1) > [ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] > 97a6396e state to 7155ba49 > [ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all > current connectors for [CRTC:41:head-0] to 7155ba49 > [ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3) > [ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4) > [ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added > [CONNECTOR:82:DP-6] 87427144 state to 7155ba49 > [ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 7155ba49 > [ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > [CRTC:41:head-0] active changed > [ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > Updating routing for [CONNECTOR:82:DP-6] > [ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No > suitable encoder found for [CONNECTOR:82:DP-6] > [ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for > 7155ba49 failed: -22 > [ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic > state 7155ba49 > [ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4) > [ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3) > [ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2) > [ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2) > [ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state > 7155ba49 > [ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2) > [ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22 > > While this doesn't usually result in any errors that would be obvious to > the user, it does result in us leaving display resources on. This in > turn leads to unwanted sideaffects like inactive GPUs being left on > (usually from the resulting leaked runtime PM ref). > > So, provide an easier way of doing this that doesn't require breaking > ->best_encoder(): add a common drm_dp_mst_connector_atomic_check() > function that DRM drivers can call in order to have CRTC enabling > commits fail automatically if the MST port driving the connector no > longer exists. We'll also be able to expand upon this later as well once > we add MST fallback retraining support. > > Signed-off-by: Lyude Paul > Cc: sta...@vger.kernel.org This does seem like a saner way to handle the case when the MST connector is gone. As this doesn't currently seem to affect amdgpu directly and I therefore might miss something I'll leave the RB to someone else, but you have my Acked-by: Harry Wentland Harry > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++ > include/drm/drm_dp_mst_helper.h | 3 ++ > 2 files changed, 7
Re: [Nouveau] [PATCH (repost) 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support
On 2018-08-17 10:11 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
>
> Signed-off-by: Hans Verkuil
> Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
> 2 files changed, 13 insertions(+), 2 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 34f34823bab5..77898c95bef6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -898,6 +898,7 @@ amdgpu_dm_update_connector_after_detect(struct
> amdgpu_dm_connector *aconnector)
> aconnector->dc_sink = sink;
> if (sink->dc_edid.length == 0) {
> aconnector->edid = NULL;
> + drm_dp_cec_unset_edid(&aconnector->dm_dp_aux.aux);
> } else {
> aconnector->edid =
> (struct edid *) sink->dc_edid.raw_edid;
> @@ -905,10 +906,13 @@ amdgpu_dm_update_connector_after_detect(struct
> amdgpu_dm_connector *aconnector)
>
> drm_connector_update_edid_property(connector,
> aconnector->edid);
> + drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
> + aconnector->edid);
> }
> amdgpu_dm_add_sink_to_freesync_module(connector,
> aconnector->edid);
>
> } else {
> + drm_dp_cec_unset_edid(&aconnector->dm_dp_aux.aux);
> amdgpu_dm_remove_sink_from_freesync_module(connector);
> drm_connector_update_edid_property(connector, NULL);
> aconnector->num_modes = 0;
> @@ -1059,12 +1063,16 @@ static void handle_hpd_rx_irq(void *param)
> drm_kms_helper_hotplug_event(dev);
> }
> }
> +
> if ((dc_link->cur_link_settings.lane_count != LANE_COUNT_UNKNOWN) ||
> - (dc_link->type == dc_connection_mst_branch))
> + (dc_link->type == dc_connection_mst_branch)) {
> dm_handle_hpd_rx_irq(aconnector);
> + }
These lines don't really add anything functional.
Either way, this patch is
Reviewed-by: Harry Wentland
Harry
>
> - if (dc_link->type != dc_connection_mst_branch)
> + if (dc_link->type != dc_connection_mst_branch) {
> + drm_dp_cec_irq(&aconnector->dm_dp_aux.aux);
> mutex_unlock(&aconnector->hpd_lock);
> + }
> }
>
> static void register_hpd_handlers(struct amdgpu_device *adev)
> @@ -2732,6 +2740,7 @@ static void amdgpu_dm_connector_destroy(struct
> drm_connector *connector)
> dm->backlight_dev = NULL;
> }
> #endif
> + drm_dp_cec_unregister_connector(&aconnector->dm_dp_aux.aux);
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> 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 9a300732ba37..18a3a6e5ffa0 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
> @@ -496,6 +496,8 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
> aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
>
> 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->mst_mgr.cbs = &dm_mst_cbs;
> drm_dp_mst_topology_mgr_init(
> &aconnector->mst_mgr,
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] drm/connector: Add generic underscan properties
On 2018-05-07 12:19 PM, Boris Brezillon wrote:
> On Mon, 7 May 2018 18:01:44 +0300
> Ville Syrjälä wrote:
>
>> On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillon wrote:
>>> We have 3 drivers defining the "underscan", "underscan hborder" and
>>> "underscan vborder" properties (radeon, amd and nouveau) and we are
>>> about to add the same kind of thing in VC4.
>>>
>>> Define generic underscan props and add new fields to the drm_connector
>>> state so that the property parsing logic can be shared by all DRM
>>> drivers.
>>>
>>> A driver can now attach underscan properties to its connector through
>>> the drm_connector_attach_underscan_properties() helper, and can
>>> check/apply the underscan setup based on the
>>> drm_connector_state->underscan fields.
>>>
>>> Signed-off-by: Boris Brezillon
>>> ---
>>> drivers/gpu/drm/drm_atomic.c| 12
>>> drivers/gpu/drm/drm_connector.c | 120
>>>
>>> include/drm/drm_connector.h | 78 ++
>>> 3 files changed, 210 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index dc850b4b6e21..b7312bd172c9 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -1278,6 +1278,12 @@ static int drm_atomic_connector_set_property(struct
>>> drm_connector *connector,
>>> return -EINVAL;
>>> }
>>> state->content_protection = val;
>>> + } else if (property == connector->underscan_mode_property) {
>>> + state->underscan.mode = val;
>>> + } else if (property == connector->underscan_hborder_property) {
>>> + state->underscan.hborder = val;
>>> + } else if (property == connector->underscan_vborder_property) {
>>> + state->underscan.vborder = val;
>>> } else if (connector->funcs->atomic_set_property) {
>>> return connector->funcs->atomic_set_property(connector,
>>> state, property, val);
>>> @@ -1359,6 +1365,12 @@ drm_atomic_connector_get_property(struct
>>> drm_connector *connector,
>>> *val = state->scaling_mode;
>>> } else if (property == connector->content_protection_property) {
>>> *val = state->content_protection;
>>> + } else if (property == connector->underscan_mode_property) {
>>> + *val = state->underscan.mode;
>>> + } else if (property == connector->underscan_hborder_property) {
>>> + *val = state->underscan.hborder;
>>> + } else if (property == connector->underscan_vborder_property) {
>>> + *val = state->underscan.vborder;
>>> } else if (connector->funcs->atomic_get_property) {
>>> return connector->funcs->atomic_get_property(connector,
>>> state, property, val);
>>> diff --git a/drivers/gpu/drm/drm_connector.c
>>> b/drivers/gpu/drm/drm_connector.c
>>> index dfc8ca1e9413..9937390b8a25 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -914,6 +914,31 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>>> drm_cp_enum_list)
>>> * can also expose this property to external outputs, in which case they
>>> * must support "None", which should be the default (since external screens
>>> * have a built-in scaler).
>>> + *
>>> + * underscan:
>>> + * This properties defines whether underscan is activated or not, and when
>>> + * it is activated, how the horizontal and vertical borders are calculated:
>>> + *
>>> + * off:
>>> + * Underscan is disabled. The output image shouldn't be scaled to
>>> + * take screen borders into account.
>>
>>> + * on:
>>> + * Underscan is activated and horizontal and vertical borders are
>>> + * specified through the "underscan hborder" and
>>> + * "underscan vborder" properties.
>>
>> How is the output scaled?
>
> In HW. The formula is
>
> hfactor = (hdisplay - hborder) / hdisplay
> vfactor = (vdisplay - vborder) / vdisplay
>
>> What does the user mode hdisplay/vdisplay mean
>> in this case?
>
> The same as before this patch: the output resolution. You just add
> black margins.
>
>> What if I want underscan without scaling?
>
> Then don't involve the DRM driver and do that from userspace: just
> fill the visible portion of the framebuffer and leave the rest black.
> There nothing the DRM driver can do to help with that, except maybe
> exposing the information about the active area of the screen. It would
> be nice to do that, but that means patching all userspace libs to take
> this into account.
>
>>
>>> + * auto:
>>> + * Underscan is activated and horizontal and vertical borders are
>>> + * automatically chosen by the driver.
>>
>> Seems overly vague to be useful. You didn't even seem to implement it
>> for vc4.
>
FWIW, amdgpu treats UNDERSCAN_AUTO like UNDERSCAN_ON. radeon and nouveau seem
to do the same. So there's probably
Re: [Nouveau] [v3 PATCH 3/3] drm/amd/display: Switch to using atomic_helper for flip.
On 2017-01-28 09:26 PM, Andrey Grodzovsky wrote:
> Swicth to use atomic helper.
> Start using actual user's given target_vblank value for flip
> instead of current value.
>
> v3:
> Update for movig pflip flags to crtc_state
>
> Change-Id: I25dae6d8c29de5d022a42aa99a18a32674b56cda
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 -
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 109
> -
> 2 files changed, 19 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 4c0a86e..3ff3c14 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -443,7 +443,6 @@ struct amdgpu_crtc {
> enum amdgpu_interrupt_state vsync_timer_enabled;
>
> int otg_inst;
> - uint32_t flip_flags;
> /* After Set Mode target will be non-NULL */
> struct dc_target *target;
> };
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
> index a443b70..148780d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
> @@ -1060,83 +1060,6 @@ static int dm_crtc_funcs_atomic_set_property(
> return 0;
> }
>
> -
> -static int amdgpu_atomic_helper_page_flip(struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags)
> -{
> - struct drm_plane *plane = crtc->primary;
> - struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
> - struct drm_atomic_state *state;
> - struct drm_plane_state *plane_state;
> - struct drm_crtc_state *crtc_state;
> - int ret = 0;
> -
> - state = drm_atomic_state_alloc(plane->dev);
> - if (!state)
> - return -ENOMEM;
> -
> - ret = drm_crtc_vblank_get(crtc);
> - if (ret)
> - return ret;
> -
> - state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> -retry:
> - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> - if (IS_ERR(crtc_state)) {
> - ret = PTR_ERR(crtc_state);
> - goto fail;
> - }
> - crtc_state->event = event;
> -
> - plane_state = drm_atomic_get_plane_state(state, plane);
> - if (IS_ERR(plane_state)) {
> - ret = PTR_ERR(plane_state);
> - goto fail;
> - }
> -
> - ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> - if (ret != 0)
> - goto fail;
> - drm_atomic_set_fb_for_plane(plane_state, fb);
> -
> - /* Make sure we don't accidentally do a full modeset. */
> - state->allow_modeset = false;
> - if (!crtc_state->active) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
> - crtc->base.id);
> - ret = -EINVAL;
> - goto fail;
> - }
> - acrtc->flip_flags = flags;
> -
> - ret = drm_atomic_nonblocking_commit(state);
> -
> -fail:
> - if (ret == -EDEADLK)
> - goto backoff;
> -
> - if (ret)
> - drm_crtc_vblank_put(crtc);
> -
> - drm_atomic_state_put(state);
> -
> - return ret;
> -backoff:
> - drm_atomic_state_clear(state);
> - drm_atomic_legacy_backoff(state);
> -
> - /*
> - * Someone might have exchanged the framebuffer while we dropped locks
> - * in the backoff code. We need to fix up the fb refcount tracking the
> - * core does for us.
> - */
> - plane->old_fb = plane->fb;
> -
> - goto retry;
> -}
> -
> /* Implemented only the options currently availible for the driver */
> static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = {
> .reset = drm_atomic_helper_crtc_reset,
> @@ -1145,7 +1068,7 @@ static int amdgpu_atomic_helper_page_flip(struct
> drm_crtc *crtc,
> .destroy = amdgpu_dm_crtc_destroy,
> .gamma_set = amdgpu_dm_atomic_crtc_gamma_set,
> .set_config = drm_atomic_helper_set_config,
> - .page_flip = amdgpu_atomic_helper_page_flip,
> + .page_flip_target = drm_atomic_helper_page_flip_target,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> .atomic_set_property = dm_crtc_funcs_atomic_set_property
> @@ -1626,7 +1549,8 @@ static void clear_unrelated_fields(struct
> drm_plane_state *state)
> static bool page_flip_needed(
> const struct drm_plane_state *new_state,
> const struct drm_plane_state *old_state,
> - bool commit_surface_required)
> + bool commit_surface_required,
> + uint32_t pflip_flags)
> {
> struct drm_plane_state old_state_tmp;
> struct drm_plane_state new_state_tmp;
> @@ -1679,7 +1603,7 @@ static bool page_flip_needed(
>
Re: [Nouveau] [PATCH 0/4] Allow ASYNC flip with atomic helpers.
On 2017-01-16 03:39 PM, Laurent Pinchart wrote: Hi Andrey, Thank you for the patches. On Monday 16 Jan 2017 10:44:54 Andrey Grodzovsky wrote: This series is a folow-up on https://patchwork.kernel.org/patch/9501787/ The first patch makes changes to atomic helpers to allow for drives with ASYNC flip support to use them. Patches 2 and 3 are to use this in AMDGPU/DC and patch 4 is possible cleanup in nouveau/kms who seems to have the duplicate the helper as we did to support ASYNC flips. I have my doubts regarding this. I'd much rather see userspace moving to the atomic API instead of extending support for legacy APIs. This change is not about introducing the async flag but cleaning up the legacy helpers to make sure drivers that currently use it through the legacy IOCTLs can benefit from the helpers and not have to roll their own. If the problem is with the pflip_flags, wouldn't drivers still need that after moving userspace to the atomic IOCTL? I don't disagree with you on having userspace move to atomic but I don't expect to see all userspace drivers move to atomic in the next couple months. Why not clean this up in the meantime? Harry Andrey Grodzovsky (4): drm/atomic: Save flip flags in drm_plane_state drm/amdgpu: Remove flip_flag from amdgpu_crtc drm/amd/display: Switch to using atomic_helper for flip. drm/nouveau/kms/nv50: Switch to using atomic helper for flip. drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 92 --- drivers/gpu/drm/drm_atomic_helper.c| 10 +-- drivers/gpu/drm/nouveau/nv50_display.c | 77 ++ include/drm/drm_plane.h| 8 ++ 5 files changed, 22 insertions(+), 166 deletions(-) ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
