2019 Election Round 2 voting OPEN

[Wentland, Harry]

To all X.Org Foundation Members:

The round 2 of X.Org Foundation's annual election is now open and will remain 
open until 23:59 UTC on 2 May 2019.

Four of the eight director seats are open during this election, with the four 
nominees receiving the highest vote totals serving as directors for two year 
terms.

There were six candidates nominated. For a complete list of the candidates and 
their personal statements, please visit the 2019 X.Org Elections page at 
https://www.x.org/wiki/BoardOfDirectors/Elections/2019/

The new bylaw changes were approved in the first round of voting.

Here are some instructions on how to cast your vote:

Login to the membership system at: https://members.x.org/

If you do not remember your password, you can click on the "lost password" 
button and enter your user name. An e-mail will be sent to you with your 
password. If you have problems with the membership system, please e-mail 
members...@x.org.

When you login you will see an "Active Ballots" section with the "X.Org 2019 
Elections Round 2" ballot. When you click on that you will be presented with a 
page describing the ballot. At the bottom you will find a number of dropdowns 
that let you rank your candidates by order of preference.

For the election: There is a pull-down selection box for 1st choice, 2nd, 
choice, and so on. Pick your candidates top to bottom in order of preference, 
avoiding duplicates.

After you have completed your ballot, click the "Cast vote" button. Note that 
once you click this button, your votes will be cast and you will not be able to 
make further changes, so please make sure you are satisfied with your votes 
before clicking the "Cast vote" button.

After you click the "Vote" button, the system will verify that you have 
completed a valid ballot. If your ballot is invalid (e.g., you duplicated a 
selection or did not answer the By-laws approval question), it will return you 
to the previous voting page. If your ballot is valid, your votes will be 
recorded and the system will show you a notice that your votes were cast.

Note that the election will close at 23:59 UTC on 2 May 2019. At that time, the 
election committee will count the votes and present the results to the current 
board for validation. After the current board validates the results, the 
election committee will present the results to the Members.

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Foundation Elections Results... and a Redo

[Wentland, Harry]

The turnout for the first election and the vote on the bylaw changes was 80% 
(56/70).

Harry

On 2019-04-11 8:03 p.m., Harry Wentland wrote:
> To all X.Org Foundation Members:
> 
> The 2019 X.Org ballot closed yesterday. There is some good and some bad news.
> 
> The Good News:
> The vote on the bylaw changes passed with 53 for, 1 against, and 2 abstaining.
> 
> The Bad News:
> Due to some issues with our new members website all votes for new board 
> members were recorded incorrectly. Thankfully this was fairly obvious. We 
> believe we've found the bug and have a fix for it: 
> https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/commit/15f27d45f1d9b1767377814835f2359f7f76c7e5
> 
> The Redo:
> To assure you and us that we've completely fixed the issues with our 
> elections site we have decided to run a brief mock election where you can 
> vote for your favorite pastry. This will run until Monday Apr 15 noon UTC 
> after which we'll tally and publish the results and confirm whether we fixed 
> the issue. Please leave your vote at https://members.x.org/ballot/3/admin
> 
> If this all looks good we will start the new election for board members a 
> week from today, on Apr 18, until May 2.
> 
> You can expect another email from me early-to-mid next week to confirm the 
> start of the new election for board members.
> 
> We received quite a few membership signups after the membership deadline. 
> We've decided to approve all currently pending signups.
> 
> Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 X.Org Foundation Election Round 2 Starting Thursday

[Wentland, Harry]

To all X.Org Foundation Members:

as per my last email the election for X.Org board members was invalid due to a 
bug with the voting systems. We apologize for this and the inconvenience caused 
to you all. The bug has been fixed and tested with a mock election (see results 
at the end).

Round 2 of the election will therefore proceed starting Thursday, April 18, and 
close on Thursday May 2.

Please take the time to vote.

Updated Schedule:
   Nomination period Start: Jan 31 00:00 UTC
   Nomination period End: Feb 28 23:59 UTC
   Deadline of X.Org membership application or renewal: Mar 07 23:59 UTC
   Publication of Candidates & start of Candidate QA: Mar 11
   Election Start: Mar 21 00:00 UTC - Delayed to March 21, again delayed to 
March 27 at 02:00 UTC
   Election End: Apr 4 23:59 UTC - Extended to April 11, 02:00 UTC
   Round 2 Election Start: Apr 18 00:00:00 UTC
   Round 2 Election End: May 2 23:59:00 UTC

Harry, on behalf of the X.Org elections committee

---

Mock election results

Ballot Statistics
Turnout: 27.4% (23 / 84)

Select: How much do you like pastries?
Answer  Votes
42  47.8% (11 / 23)
A lot   34.8% (8 / 23)
To death17.4% (4 / 23)

Ranking: Rank the following lovely pastries!
Option  Rank 1  Rank 2  Rank 3  Rank 4  Rank 5  Rank 6  Final 
Score
Apple strudel   13  4   2   1   1   2   113
Cinnamon Roll   3   7   3   1   2   7   79
Gâteau Basque   3   4   4   1   8   3   76
Beaver Tails3   1   4   8   3   4   73
Trdelník0   5   3   6   7   2   71
Runeberg's torte1   2   7   6   2   5   71
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Foundation Elections Results... and a Redo

[Wentland, Harry]

Correction on the link for the mock election. That should be 
https://members.x.org/ballot/3/vote, not /admin.

It will also be linked from the members homepage and shown as the current 
ballot.

Harry

On 2019-04-11 8:03 p.m., Harry Wentland wrote:
> To all X.Org Foundation Members:
> 
> The 2019 X.Org ballot closed yesterday. There is some good and some bad news.
> 
> The Good News:
> The vote on the bylaw changes passed with 53 for, 1 against, and 2 abstaining.
> 
> The Bad News:
> Due to some issues with our new members website all votes for new board 
> members were recorded incorrectly. Thankfully this was fairly obvious. We 
> believe we've found the bug and have a fix for it: 
> https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/commit/15f27d45f1d9b1767377814835f2359f7f76c7e5
> 
> The Redo:
> To assure you and us that we've completely fixed the issues with our 
> elections site we have decided to run a brief mock election where you can 
> vote for your favorite pastry. This will run until Monday Apr 15 noon UTC 
> after which we'll tally and publish the results and confirm whether we fixed 
> the issue. Please leave your vote at https://members.x.org/ballot/3/admin
> 
> If this all looks good we will start the new election for board members a 
> week from today, on Apr 18, until May 2.
> 
> You can expect another email from me early-to-mid next week to confirm the 
> start of the new election for board members.
> 
> We received quite a few membership signups after the membership deadline. 
> We've decided to approve all currently pending signups.
> 
> Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 X.Org Foundation Elections Results... and a Redo

[Wentland, Harry]

To all X.Org Foundation Members:

The 2019 X.Org ballot closed yesterday. There is some good and some bad news.

The Good News:
The vote on the bylaw changes passed with 53 for, 1 against, and 2 abstaining.

The Bad News:
Due to some issues with our new members website all votes for new board members 
were recorded incorrectly. Thankfully this was fairly obvious. We believe we've 
found the bug and have a fix for it: 
https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/commit/15f27d45f1d9b1767377814835f2359f7f76c7e5

The Redo:
To assure you and us that we've completely fixed the issues with our elections 
site we have decided to run a brief mock election where you can vote for your 
favorite pastry. This will run until Monday Apr 15 noon UTC after which we'll 
tally and publish the results and confirm whether we fixed the issue. Please 
leave your vote at https://members.x.org/ballot/3/admin

If this all looks good we will start the new election for board members a week 
from today, on Apr 18, until May 2.

You can expect another email from me early-to-mid next week to confirm the 
start of the new election for board members.

We received quite a few membership signups after the membership deadline. We've 
decided to approve all currently pending signups.

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Last week of voting for X.Org 2019 Election and By-laws approval

[Wentland, Harry]

To all X.Org Foundation Members:

We're currently halfway through our annual election at 71.4% turnout. If you 
haven't done so please login to https://members.x.org/, click on the Active 
ballot "X.Org 2019 Elections v2 and xorg+fdo merger" and leave your vote.

In order to pass the proposed bylaw changes we'll need at least a 2/3 majority 
so we highly encourage each and everyone of you to vote. It only takes a couple 
of minutes.

The election will close at 02:00 UTC on 11 April 2019.

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 Election and By-laws approval voting OPEN

[Wentland, Harry]

To all X.Org Foundation Members:

The X.Org Foundation's annual election is now open and will remain open until 
02:00 UTC on 11 April 2019.

Four of the eight director seats are open during this election, with the four 
nominees receiving the highest vote totals serving as directors for two year 
terms.

There were six candidates nominated. For a complete list of the candidates and 
their personal statements, please visit the 2019 X.Org Elections page at 
https://www.x.org/wiki/BoardOfDirectors/Elections/2019/

In addition to the board election, we are also voting on whether or not to 
approve of the new By-laws.

Here are some instructions on how to cast your vote:

Login to the membership system at: https://members.x.org/

If you do not remember your password, you can click on the "lost password" 
button and enter your user name. An e-mail will be sent to you with your 
password. If you have problems with the membership system, please e-mail 
members...@x.org.

When you login you will see an "Active Ballots" section with the "X.Org 2019 
Elections v2" ballot. When you click on that you will be presented with a page 
describing the ballot. At the bottom you will find a number of dropdowns that 
let you rank your candidates by order of preference, as well as a question on 
whether to accept the proposed By-laws changes.

For the election: There is a pull-down selection box for 1st choice, 2nd, 
choice, and so on. Pick your candidates top to bottom in order of preference, 
avoiding duplicates.

For the By-laws: If you approve of the new By-laws, select "yes" from the 
dropdown. If you do not approve of the new By-laws, select "no" from the 
dropdown. If you wish to abstain from this question, select "Abstain".

There is a link to the new By-laws in the ballot description, as well as a link 
to the patch introducing the change.

Note that answering this question is required for your vote to be validated.

After you have completed your ballot, click the "Cast vote" button. Note that 
once you click this button, your votes will be cast and you will not be able to 
make further changes, so please make sure you are satisfied with your votes 
before clicking the "Cast vote" button.

After you click the "Vote" button, the system will verify that you have 
completed a valid ballot. If your ballot is invalid (e.g., you duplicated a 
selection or did not answer the By-laws approval question), it will return you 
to the previous voting page. If your ballot is valid, your votes will be 
recorded and the system will show you a notice that your votes were cast.

Note that the election will close at 02:00 UTC on 11 April 2019. At that time, 
the election committee will count the votes and present the results to the 
current board for validation. After the current board validates the results, 
the election committee will present the results to the Members.

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 X.Org Foundation Election Opening in 35 hours

[Wentland, Harry]

To all X.Org Foundation Members:

We've had some problems with the previous ballot (i.e. I didn't create it 
properly) that opened last Thursday. Apologies to the two people that already 
voted.

We've re-created the ballot (v2). It will open on March 27 at 2am UTC and close 
on April 11 at 2am UTC.

Updated Schedule:
  Nomination period Start: Jan 31 00:00 UTC
  Nomination period End: Feb 28 23:59 UTC
  Deadline of X.Org membership application or renewal: Mar 07 23:59 UTC
  Publication of Candidates & start of Candidate QA: Mar 11
  Election Start: Mar 21 00:00 UTC - Delayed to March 21, again delayed to 
March 27 at 02:00 UTC
  Election End: Apr 4 23:59 UTC - Extended to April 11, 02:00 UTC

I will send a reminder the day the polls open.

I apologize for the many delays.

Please take some time to familiarize yourself with the proposed bylaw changes 
and the candidates. Details are at 
https://www.x.org/wiki/BoardOfDirectors/Elections/2019/

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

[Wentland, Harry]

On 2019-03-21 5:39 a.m., Mario Kleiner wrote:
> On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas
>  wrote:
>>
>> On 3/20/19 3:51 AM, Mario Kleiner wrote:
>>> Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
>>>
>>> On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas
>>>  wrote:

 On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote:
> On 3/18/19 1:19 PM, Mario Kleiner wrote:

...snip...

>> diff --git 
>> a/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c 
>> b/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c
>> index e04ae49..10ac6de 100644
>> --- a/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c
>> +++ b/drivers/gpu/drm/amd/display/dc/irq/dcn10/irq_service_dcn10.c
>> @@ -56,6 +56,18 @@ enum dc_irq_source to_dal_irq_source_dcn10(
>>   return DC_IRQ_SOURCE_VBLANK5;
>>   case DCN_1_0__SRCID__DC_D6_OTG_VSTARTUP:
>>   return DC_IRQ_SOURCE_VBLANK6;
>> +case DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT:
>> +return DC_IRQ_SOURCE_VUPDATE1;
>> +case DCN_1_0__SRCID__OTG1_IHC_V_UPDATE_NO_LOCK_INTERRUPT:
>> +return DC_IRQ_SOURCE_VUPDATE2;
>> +case DCN_1_0__SRCID__OTG2_IHC_V_UPDATE_NO_LOCK_INTERRUPT:
>> +return DC_IRQ_SOURCE_VUPDATE3;
>> +case DCN_1_0__SRCID__OTG3_IHC_V_UPDATE_NO_LOCK_INTERRUPT:
>> +return DC_IRQ_SOURCE_VUPDATE4;
>> +case DCN_1_0__SRCID__OTG4_IHC_V_UPDATE_NO_LOCK_INTERRUPT:
>> +return DC_IRQ_SOURCE_VUPDATE5;
>> +case DCN_1_0__SRCID__OTG5_IHC_V_UPDATE_NO_LOCK_INTERRUPT:
>> +return DC_IRQ_SOURCE_VUPDATE6;

 I'm not sure we necessarily want to reuse the same
 DC_IRQ_SOURCE_VUPDATE1...6 definitions here again when it's really
 V_UPDATE_NO_LOCK.

>>>
>>> Hm. The problem is that if we use different ones for DCE and DCN we
>>> need special-case handling in amdgpu_dm.c, e.g., in
>>> amdgpu_dm_set_vupdate_irq_state() and dm_set_vupdate_irq() to detect
>>> if it is caling DCE or DCN (how to detect this?) to select different
>>> irq sources IRQ_TYPE_VUPDATE vs IRQ_TYPE_VUPDATE_NO_LOCK and such?
>>> And definitions like "struct amdgpu_irq_src vupdate_irq;" should then
>>> also exist twice as vupdate_irq and vupdate_irq_no_lock for correct
>>> naming?
>>>
>>> Or we'd name the IRQ source and all relevant data structures and
>>> functions something like DC_IRQ_SOURCE_VBLANK_END1..6 to describe what
>>> it signals instead of to what it corresponds in hardware? That would
>>> be what was done with the regular DC_IRQ_SOURCE_VBLANK1..6. It signals
>>> start of vblank, but the underlying hw interrupts are actually a
>>> properly programmed VLINE0 irq on DCE and a VSTARTUP irq on DCN.
>>
>>
>> Ah, I see what you mean. Maybe this is for the better to share the same
>> names then. I'll defer this to Harry.
>>

I'd tend to agree with Mario. I think it's best to keep the same semantic for 
VUPDATE.

The regular VUPDATE has some interaction with the master lock. I imagine we 
want something that fires independently of it, which looks to be the _NO_LOCK 
version.

That said, both VSTARTUP and VUPDATE can occur before VSYNC on DCN. With most 
timings this probably won't occur but if our back porch is really small we'd 
see that happening. If we need to guarantee that this interrupt occurs no 
sooner than vline 0 we will need to register a vline IRQ.

As for VSTARTUP and VUPDATE, VSTARTUP is the IRQ that has an impact on the 
behavior of render clients as it's the deadline for frame submissions. After 
VSTARTUP any new framebuffer address update is postponed to the next frame 
(unless we do immediate flip).

So for now VUPDATE_NO_LOCK is probably fine and will improve our situation 
except for VRR displays with a really short back porch. Not sure those even 
exist.

>>>
>>> Of course this all assumes we need to use the NO_LOCK variant on DCN?
>>> We haven't tested what the regular VUPDATE_IRQ does, because i don't
>>> have a suitable test machine, and my use of the NO_LOCK variant was
>>> just based on my interpretation of this little comment in the DCN
>>> header file:
>>>
>>> #define DCN_1_0__SRCID__OTG0_IHC_V_UPDATE_NO_LOCK_INTERRUPT 0x57 //
>>> "OTG0 VUPDATE event without lock interrupt, VUPDATE is update event
>>> for double buffered registers"
>>>
>>> and the absence of any explanatory comment in the define of regular 
>>> V_UPDATE:
>>>
>>> #define DCN_1_0__SRCID__DC_D1_OTG_V_UPDATE 0x18 // D1 : OTG V_update
>>> OTG1_IHC_V_UPDATE_INTERRUPT
>>>
>>> I assumed the NO_LOCK means not affected by the state of any of the hw
>>> locks, so regular V_UPDATE might be affected by them. You agreed with
>>> that, but we never tested what regular V_UPDATE would do on DCN. Do we
>>> actually know for sure from hw specs that it would not work, ie. not
>>> unconditionally fire the IRQ at every end of VBLANK, as we need?
>>
>> FWIW,

Re: randr: Virtual monitor not present with MST display

[Wentland, Harry]

On 2019-03-18 5:58 p.m., Paul Menzel wrote:
> 
> Dear Harry,
> 

... snip ...

>>
>> Michel, do you know if this is supposed to work with
>> xf86-video-amdgpu? When I've tried it before I didn't have any luck but
>> didn't have time to look into it.
> 
> Sorry, what is your question. With the commit from the merge request applied 
> it works here. Also, the commit was added to the master branch in the mean 
> time.
> 

Ah, of course. Somehow I thought this was still targetting the modesetting 
driver and didn't notice it's on video-amdgpu.

Apologies for the confusion.

Harry

> 
> Kind regards,
> 
> Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: randr: Virtual monitor not present with MST display

[Wentland, Harry]

On 2019-03-08 4:11 a.m., Michel Dänzer wrote:
> On 2019-03-06 5:35 p.m., Paul Menzel wrote:
>> On 03/06/19 15:55, Michel Dänzer wrote:
>>> On 2019-03-06 1:41 p.m., Paul Menzel wrote:
 On 03/05/19 20:07, Alex Deucher wrote:
> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote:

>> Using the MST display Dell UP3214Q (two panels) with an AMD system,
>> the virtual monitor object is not created. GDM and Xfce consider both
>> panels as separate screens (`xrandr --listmonitors`).
>>
>> [...]

 I didn’t provide the output of xrandr in my previous message.

 $ xrandr --listmonitors
  Monitors: 2
  0: +DisplayPort-9 1920/698x2160/392+0+0  DisplayPort-9
  1: +DisplayPort-10 1920/698x2160/392+1920+0  DisplayPort-10

 Please find the X.Org X Server log attached.

>> With an Intel system, the monitor object is shown.

 To clarify, the modesetting driver is used with the Intel hardware.
>>>
>>> Does this work better with the modesetting driver on the AMD system?
>>
>> With Linux 4.19.19, there was the same problem with the modesetting driver
>> during my limited testing.
>>
>> Updating to Linux 4.20.13, it worked with the modesetting driver, but the
>> AMDGPU driver still failed to properly utilize the MST monitor.
> 
> Does
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/32
> help?
> 

Michel, do you know if this is supposed to work with xf86-video-amdgpu? When 
I've tried it before I didn't have any luck but didn't have time to look into 
it.

Harry

> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 X.Org Foundation Election Delayed

[Wentland, Harry]

To all X.Org Foundation Members:

In order to give members more time to process the proposed changes to the bylaw 
the elections committee decided to delay the start of voting by one week.

Updated Schedule:
  Nomination period Start: Jan 31 00:00 UTC
  Nomination period End: Feb 28 23:59 UTC
  Deadline of X.Org membership application or renewal: Mar 07 23:59 UTC
  Publication of Candidates & start of Candidate QA: Mar 11
  Election Start: Mar 21 00:00 UTC
  Election End: Apr 4 23:59 UTC

Please take some time to familiarize yourself with the proposed bylaw changes 
and the candidates. Details are at 
https://www.x.org/wiki/BoardOfDirectors/Elections/2019/

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Bylaw Changes Vote

[Wentland, Harry]

To all X.Org Foundation Members:

My previous emails about the 2019 X.Org elections failed to mention on 
important ballot items that we'd like to vote on, in addition to the new board 
members: the Bylaw change 

The updated Bylaws to be voted on can be found here: 
https://gitlab.freedesktop.org/xorgfoundation/bylaws/blob/bylaw-updates/bylaws.pdf
The individual changes can be seen here: 
https://gitlab.freedesktop.org/xorgfoundation/bylaws/commit/06e7f04f79131df2c86e9cdfedc00aa1d1ec3f52

Please take a look.

To give members more time to understand and discuss this the elections 
committee decided to move the election out by a week. Voting will start Mar 21.

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Foundation Election Candidates

[Wentland, Harry]

On 2019-03-14 4:40 p.m., Luc Verhaegen wrote:
> On Thu, Mar 14, 2019 at 08:36:13PM +0000, Wentland, Harry wrote:
>> On 2019-03-12 6:49 a.m., Luc Verhaegen wrote:
>>>
>>> Are these candidates the only thing we will be voting on?
>>>
>>
>> You're right. The FDO question totally slipped me mind.
>>
>> We'll also be voting on the bylaw change I sent out sometime toward the end 
>> of last year to facilitate the marriage of fdo and x.org.
>>
>> I'll send out details shortly.
> 
> Cool, thanks!
> 
> This way members can actually review and perhaps discuss this instead of 
> being confrontend with this when voting for just candidates, without 
> preparation, which could've perhaps invalidated the result.
> 

Definitely a big oversight on my part. Details are now on 
https://www.x.org/wiki/BoardOfDirectors/Elections/2019/

I'll bring this up at today's board meeting. Not sure if this warrants delaying 
start of voting but I'd consider extending the end date.

Harry

> Luc Verhaegen.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Foundation Election Candidates

[Wentland, Harry]

On 2019-03-12 6:49 a.m., Luc Verhaegen wrote:
> On Tue, Mar 12, 2019 at 12:24:00AM +0000, Wentland, Harry wrote:
>> To all X.Org Foundation Members:
>>
>> The election for the X.Org Foundation Board of Directors will begin on 
>> 14 March 2019. We have 6 candidates who are running for 4 seats. They 
>> are (in alphabetical order):
> 
>> 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.
>>
>> Harry, on behalf of the X.Org elections committee
> 
> Are these candidates the only thing we will be voting on?
> 

You're right. The FDO question totally slipped me mind.

We'll also be voting on the bylaw change I sent out sometime toward the end of 
last year to facilitate the marriage of fdo and x.org.

I'll send out details shortly.

Harry

> Luc Verhaegen.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 X.Org Foundation Election Candidates

[Wentland, Harry]

To all X.Org Foundation Members:

The election for the X.Org Foundation Board of Directors will begin on 14 March 
2019. We have 6 candidates who are running for 4 seats. They are (in 
alphabetical order):

Samuel Iglesias Gonsálvez
Arkadiusz Hiler
Manasi Navare
Lyude Paul
Daniel Vetter
Trevor Woerner

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.

Harry, on behalf of the X.Org elections committee

# Nominees

## Samuel Iglesias Gonsálvez
__Current Affiliation:__ Igalia

__Personal Statement:__

I have been contributing to Mesa for 5 years, specifically to the Intel
drivers for OpenGL and Vulkan. I was one of the organizers of XDC 2018
in A Coruña, Spain. If I am elected, I will use my experience on XDC
2018 to improve the organization of future XDC, help to spread X.Org
technologies and help X.org project as much as possible.

## Arkadiusz Hiler
__Current Affiliation:__ Intel

__Personal Statement:__

My main interest is in quality and automated testing throughout the
graphics stack. Especially helping the areas that are lagging behind: testing
the kernel and KMS plumbing.

I would like to focus on building open source testing toolbox so that anyone
can mix and match bits of it to build their testing infrastructure.

There are a lot of exotic setups and edge cases that are hard to exercise
locally by developers due to lack of hardware. Automating those cases by
software faking it or by granting access to the testing infrastructures
benefits the whole community. It also a good way of lowering the bar for
new contributors and enables refactoring with confidence.

## 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. Most recently I have been 
involved in upstreaming Display Stream Compression feature across DRM i915 to 
enable high resolutions like 5K@120. I also have commit rights to several 
upstream projects like drm-intel, drm-misc and Intel GPU Tools.

__Personal Statement:__

I have been Linux Open Source contributor for last 4 years since I joined 
Intel's Open source technology center.  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. 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 proactively started attending X.org board meetings on IRC to better 
understand working of X.org and at XDC 2018, I also volunteered in the Code of 
Conduct committee during the conference and I was the point of contact for 
this. I am also currently a mentor for the KMS project in Outreachy winter 
program and committed to mentor the Google summer of code program as well.

If I get elected, I would like to contribute by helping organize the X.org 
foundation conferences, screening the papers and any help needed in terms of 
public relations, working with the sponsors or code of conduct on the day of 
the conference to make the events a huge success. I would also like to leverage 
 my open source working knowledge on any technical help required for the X.org 
events.

## Lyude Paul
__Current Affiliation:__ Red Hat

__Personal Statement:__

One of the people who helped start Panfrost! Also a
contributor to nouveau, i915, amdgpu, radeon, weston, Xorg, multiple X DDXs,
libinput, the wayland protocol, various other non-graphics related bits in the
kernel, and probably more!

__Statement of Contribution:__

I originally found out about Linux through a rather
unexpected place: an Ubuntu booth at an Anime convention. I was in awe of the
beauty of the all-mighty Compiz workspace switching cube and ended up deciding
to give it a shot on my own computer. I ended up loving Linux, and quickly found
I couldn't go back to other operating systems. I also wanted to become involved,
but didn't really know how to at first. After years of being a user throughout
high school and the start of my college career, I ended up taking on the
challenge of trying t

Re: 2019 X.Org Board of Directors Elections Nomination period is NOW

[Wentland, Harry]

The nomination period is now closed. We'll announce nominees March 7.

Note also that the membership deadline is March 7. If you haven't signed-up to 
be a member and would like to do so there's only 6 more days left.

Harry

On 2019-02-14 5:27 p.m., Wentland, Harry wrote:
> Since we haven't seen an onslaught of nominations we've decided to extend the 
> nomination period for another two weeks. Please consider nominating yourself 
> or anyone else you think would be a suitable candidate. This is your chance 
> to help steer the future of X.Org and serve the community.
> 
> Updated election schedule (if no further delays):
> Jan 31 - nomination period begins
> Feb 28 - extended nomination period ends
> Mar 7  - publish candidates, membership deadline
> Mar 14 - election period begins
> Mar 28 - election period ends
> 
> Harry
> 
> On 2019-02-11 10:38 a.m., Wentland, Harry wrote:
>> So far we've received a couple of nominations for four open spots. The 
>> official nomination period ends this Thursday. Please let us know if you'd 
>> like to nominate someone including yourself.
>>
>> Harry
>>
>> On 2019-01-31 5:08 p.m., Wentland, Harry wrote:
>>> 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 2019 election are now open and will remain open until 
>>> 23:59 UTC on 14 February 2019.
>>>
>>> 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 2018 were Keith 
>>> Packard, Bryce Harrington, Eric Anholt, and Harry Wentland. They will 
>>> continue to serve until their term ends in 2020. Current directors whose 
>>> term expires in 2019 are Rob Clark, Martin Peres, Taylor Campbell 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, membership applications or renewals and completed personal 
>>> statements must be received no later than 23:59 UTC on 14 February 2019.
>>>
>>> The slate of candidates will be published 21 February 2019 and candidate 
>>> Q&A will begin then. The deadline for Xorg membership applications and 
>>> renewals is 21 February 2019.
>>>
>>> Cheers, Harry Wentland, on behalf of the X.Org BoD
>>>
>>>
>>>
>>>
>>> ___
>>> memb...@foundation.x.org: X.Org Foundation Members
>>> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
>>> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
>>>
>> ___
>> memb...@foundation.x.org: X.Org Foundation Members
>> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
>> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
>>
> ___
> memb...@foundation.x.org: X.Org Foundation Members
> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Board of Directors Elections Nomination period is NOW

[Wentland, Harry]

Since we haven't seen an onslaught of nominations we've decided to extend the 
nomination period for another two weeks. Please consider nominating yourself or 
anyone else you think would be a suitable candidate. This is your chance to 
help steer the future of X.Org and serve the community.

Updated election schedule (if no further delays):
Jan 31 - nomination period begins
Feb 28 - extended nomination period ends
Mar 7  - publish candidates, membership deadline
Mar 14 - election period begins
Mar 28 - election period ends

Harry

On 2019-02-11 10:38 a.m., Wentland, Harry wrote:
> So far we've received a couple of nominations for four open spots. The 
> official nomination period ends this Thursday. Please let us know if you'd 
> like to nominate someone including yourself.
> 
> Harry
> 
> On 2019-01-31 5:08 p.m., Wentland, Harry wrote:
>> 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 2019 election are now open and will remain open until 
>> 23:59 UTC on 14 February 2019.
>>
>> 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 2018 were Keith 
>> Packard, Bryce Harrington, Eric Anholt, and Harry Wentland. They will 
>> continue to serve until their term ends in 2020. Current directors whose 
>> term expires in 2019 are Rob Clark, Martin Peres, Taylor Campbell 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, membership applications or renewals and completed personal 
>> statements must be received no later than 23:59 UTC on 14 February 2019.
>>
>> The slate of candidates will be published 21 February 2019 and candidate Q&A 
>> will begin then. The deadline for Xorg membership applications and renewals 
>> is 21 February 2019.
>>
>> Cheers, Harry Wentland, on behalf of the X.Org BoD
>>
>>
>>
>>
>> ___
>> memb...@foundation.x.org: X.Org Foundation Members
>> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
>> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
>>
> ___
> memb...@foundation.x.org: X.Org Foundation Members
> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Block fb changes for async plane updates

[Wentland, Harry]

On 2019-01-07 12:41 p.m., Nicholas Kazlauskas wrote:
> The prepare_fb call always happens on new_plane_state.
> 
> The drm_atomic_helper_cleanup_planes checks to see if
> plane state pointer has changed when deciding to call cleanup_fb on
> either the new_plane_state or the old_plane_state.
> 
> For a non-async atomic commit the state pointer is swapped, so this
> helper calls prepare_fb on the new_plane_state and cleanup_fb on the
> old_plane_state. This makes sense, since we want to prepare the
> framebuffer we are going to use and cleanup the the framebuffer we are
> no longer using.
> 
> For the async atomic update helpers this differs. The async atomic
> update helpers perform in-place updates on the existing state. They call
> drm_atomic_helper_cleanup_planes but the state pointer is not swapped.
> This means that prepare_fb is called on the new_plane_state and
> cleanup_fb is called on the new_plane_state (not the old).
> 
> In the case where old_plane_state->fb == new_plane_state->fb then
> there should be no behavioral difference between an async update
> and a non-async commit. But there are issues that arise when
> old_plane_state->fb != new_plane_state->fb.
> 
> The first is that the new_plane_state->fb is immediately cleaned up
> after it has been prepared, so we're using a fb that we shouldn't
> be.
> 
> The second occurs during a sequence of async atomic updates and
> non-async regular atomic commits. Suppose there are two framebuffers
> being interleaved in a double-buffering scenario, fb1 and fb2:
> 
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> 
> We call cleanup_fb on fb2 twice in this example scenario, and any
> further use will result in use-after-free.
> 
> The simple fix to this problem is to block framebuffer changes
> in the drm_atomic_helper_async_check function for now.
> 
> Cc: Daniel Vetter 
> Cc: Harry Wentland 
> Cc: Andrey Grodzovsky 
> Cc:  # v4.14+
> Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane 
> update")
> Signed-off-by: Nicholas Kazlauskas 

Patch is merged to drm-misc-fixes with Daniel's RB from IRC and Andrey's and my 
AB.

Harry

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 54e2ae614dcc..f4290f6b0c38 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1602,6 +1602,15 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>   old_plane_state->crtc != new_plane_state->crtc)
>   return -EINVAL;
>  
> + /*
> +  * FIXME: Since prepare_fb and cleanup_fb are always called on
> +  * the new_plane_state for async updates we need to block framebuffer
> +  * changes. This prevents use of a fb that's been cleaned up and
> +  * double cleanups from occuring.
> +  */
> + if (old_plane_state->fb != new_plane_state->fb)
> + return -EINVAL;
> +
>   funcs = plane->helper_private;
>   if (!funcs->atomic_async_update)
>   return -EINVAL;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/dsc: Change infoframe_pack to payload_pack

[Wentland, Harry]

On 2019-02-13 9:45 a.m., David Francis wrote:
> The function drm_dsc_pps_infoframe_pack only
> packed the payload portion of the infoframe.
> Change the input struct to the PPS payload
> to clarify the function's purpose and allow
> for drivers with their own handling of sdp.
> (e.g. drivers with their own struct for
> all SDP transactions)
> 
> Signed-off-by: David Francis 

Reviewed-by: Harry Wentland 

Again, ideally we'd want an AB from i915 guys as well.

Harry

> ---
>  drivers/gpu/drm/drm_dsc.c | 86 +++
>  drivers/gpu/drm/i915/intel_vdsc.c |  2 +-
>  include/drm/drm_dsc.h |  2 +-
>  3 files changed, 45 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 9e675dd39a44..4ada4d4f59ac 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -38,42 +38,42 @@ void drm_dsc_dp_pps_header_init(struct 
> drm_dsc_pps_infoframe *pps_sdp)
>  EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
>  
>  /**
> - * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> + * drm_dsc_pps_payload_pack() - Populates the DSC PPS payload
>   * using the DSC configuration parameters in the order expected
>   * by the DSC Display Sink device. For the DSC, the sink device
>   * expects the PPS payload in the big endian format for the fields
>   * that span more than 1 byte.
>   *
> - * @pps_sdp:
> - * Secondary data packet for DSC Picture Parameter Set
> + * @pps_payload:
> + * DSC Picture Parameter Set
>   * @dsc_cfg:
>   * DSC Configuration data filled by driver
>   */
> -void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
> +void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set 
> *pps_payload,
>   const struct drm_dsc_config *dsc_cfg)
>  {
>   int i;
>  
>   /* Protect against someone accidently changing struct size */
> - BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
> + BUILD_BUG_ON(sizeof(*pps_payload) !=
>DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
>  
> - memset(&pps_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
> + memset(pps_payload, 0, sizeof(*pps_payload));
>  
>   /* PPS 0 */
> - pps_sdp->pps_payload.dsc_version =
> + pps_payload->dsc_version =
>   dsc_cfg->dsc_version_minor |
>   dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
>  
>   /* PPS 1, 2 is 0 */
>  
>   /* PPS 3 */
> - pps_sdp->pps_payload.pps_3 =
> + pps_payload->pps_3 =
>   dsc_cfg->line_buf_depth |
>   dsc_cfg->bits_per_component << DSC_PPS_BPC_SHIFT;
>  
>   /* PPS 4 */
> - pps_sdp->pps_payload.pps_4 =
> + pps_payload->pps_4 =
>   ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
>   dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> @@ -82,7 +82,7 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>  
>   /* PPS 5 */
> - pps_sdp->pps_payload.bits_per_pixel_low =
> + pps_payload->bits_per_pixel_low =
>   (dsc_cfg->bits_per_pixel & DSC_PPS_LSB_MASK);
>  
>   /*
> @@ -93,103 +93,103 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>*/
>  
>   /* PPS 6, 7 */
> - pps_sdp->pps_payload.pic_height = cpu_to_be16(dsc_cfg->pic_height);
> + pps_payload->pic_height = cpu_to_be16(dsc_cfg->pic_height);
>  
>   /* PPS 8, 9 */
> - pps_sdp->pps_payload.pic_width = cpu_to_be16(dsc_cfg->pic_width);
> + pps_payload->pic_width = cpu_to_be16(dsc_cfg->pic_width);
>  
>   /* PPS 10, 11 */
> - pps_sdp->pps_payload.slice_height = cpu_to_be16(dsc_cfg->slice_height);
> + pps_payload->slice_height = cpu_to_be16(dsc_cfg->slice_height);
>  
>   /* PPS 12, 13 */
> - pps_sdp->pps_payload.slice_width = cpu_to_be16(dsc_cfg->slice_width);
> + pps_payload->slice_width = cpu_to_be16(dsc_cfg->slice_width);
>  
>   /* PPS 14, 15 */
> - pps_sdp->pps_payload.chunk_size = 
> cpu_to_be16(dsc_cfg->slice_chunk_size);
> + pps_payload->chunk_size = cpu_to_be16(dsc_cfg->slice_chunk_size);
>  
>   /* PPS 16 */
> - pps_sdp->pps_payload.initial_xmit_delay_high =
> + pps_payload->initial_xmit_delay_high =
>   ((dsc_cfg->initial_xmit_delay &
> DSC_PPS_INIT_XMIT_DELAY_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT);
>  
>   /* PPS 17 */
> - pps_sdp->pps_payload.initial_xmit_delay_low =
> + pps_payload->initial_xmit_delay_low =
>   (dsc_cfg->initial_xmit_delay & DSC_PPS_LSB_MASK);
>  
>   /* PPS 18, 19 */
> - pps_sdp->pps_payload.initial_dec_delay =
> + pps_payload->initial_dec_delay =
>   cpu_to_be16(dsc_cfg->initial_dec_delay);
>  
>   /* PPS 20 is 0 */
>  
>   /* PPS 21 */
> - pps_sdp->

Re: [PATCH 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params

[Wentland, Harry]

On 2019-02-13 9:45 a.m., David Francis wrote:
> Native 420 and 422 transfer modes are new in DSC1.2
> 
> In these modes, each two pixels of a slice are treated as one
> pixel, so the slice width is half as large (round down) for
> the purposes of calucating the groups per line and chunk size
> in bytes
> 
> In native 422 mode, each pixel has four components, so the
> mux component of a group is larger by one additional mux word
> and one additional component
> 
> Now that there is native 422 support, the configuration option
> previously called enable422 is renamed to simple_422 to avoid
> confusion
> 
> Signed-off-by: David Francis 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dsc.c | 31 +++
>  drivers/gpu/drm/i915/intel_vdsc.c |  4 ++--
>  include/drm/drm_dsc.h |  4 ++--
>  3 files changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 4b0e3c9c3ff8..9e675dd39a44 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -77,7 +77,7 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   ((dsc_cfg->bits_per_pixel & DSC_PPS_BPP_HIGH_MASK) >>
>DSC_PPS_MSB_SHIFT) |
>   dsc_cfg->vbr_enable << DSC_PPS_VBR_EN_SHIFT |
> - dsc_cfg->enable422 << DSC_PPS_SIMPLE422_SHIFT |
> + dsc_cfg->simple_422 << DSC_PPS_SIMPLE422_SHIFT |
>   dsc_cfg->convert_rgb << DSC_PPS_CONVERT_RGB_SHIFT |
>   dsc_cfg->block_pred_enable << DSC_PPS_BLOCK_PRED_EN_SHIFT;
>  
> @@ -246,19 +246,34 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
> *vdsc_cfg)
>   unsigned long final_scale = 0;
>   unsigned long rbs_min = 0;
>  
> - /* Number of groups used to code each line of a slice */
> - groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> -DSC_RC_PIXELS_PER_GROUP);
> + if (vdsc_cfg->native_420 || vdsc_cfg->native_422) {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width / 2,
> +DSC_RC_PIXELS_PER_GROUP);
>  
> - /* chunksize in Bytes */
> - vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> -   vdsc_cfg->bits_per_pixel,
> -   (8 * 16));
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> / 2 *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + } else {
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> *
> +   
> vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> + }
>  
>   if (vdsc_cfg->convert_rgb)
>   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> (4 * vdsc_cfg->bits_per_component + 4)
> - 2);
> + else if (vdsc_cfg->native_422)
> + num_extra_mux_bits = 4 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 3 * (4 * vdsc_cfg->bits_per_component) - 2;
>   else
>   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
>   (4 * vdsc_cfg->bits_per_component + 4) +
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index c76cec8bfb74..7702c5c8b3f2 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -369,7 +369,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
>   DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
>  
>   /* Gen 11 does not support YCbCr */
> - vdsc_cfg->enable422 = false;
> + vdsc_cfg->simple_422 = false;
>   /* Gen 11 does not support VBR */
>   vdsc_cfg->vbr_enable = false;
>   vdsc_cfg->block_pred_enable 

Re: [PATCH 1/3] drm/i915: Move dsc rate params compute into drm

[Wentland, Harry]

On 2019-02-13 9:45 a.m., David Francis wrote:
> The function intel_compute_rc_parameters is part of the dsc spec
> and is not driver-specific. Other drm drivers might like to use
> it.  The function is not changed; just moved and renamed.
> 
> Signed-off-by: David Francis 

Reviewed-by: Harry Wentland 

This one also needs an RB or AB from i915 guys.

Harry

> ---
>  drivers/gpu/drm/drm_dsc.c | 133 ++
>  drivers/gpu/drm/i915/intel_vdsc.c | 125 +---
>  include/drm/drm_dsc.h |   1 +
>  3 files changed, 135 insertions(+), 124 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index bc2b23adb072..4b0e3c9c3ff8 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -226,3 +227,135 @@ void drm_dsc_pps_infoframe_pack(struct 
> drm_dsc_pps_infoframe *pps_sdp,
>   /* PPS 94 - 127 are O */
>  }
>  EXPORT_SYMBOL(drm_dsc_pps_infoframe_pack);
> +
> +/**
> + * drm_dsc_compute_rc_parameters() - Write rate control
> + * parameters to the dsc configuration. Some configuration
> + * fields must be present beforehand.
> + *
> + * @dsc_cfg:
> + * DSC Configuration data partially filled by driver
> + */
> +int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> +{
> + unsigned long groups_per_line = 0;
> + unsigned long groups_total = 0;
> + unsigned long num_extra_mux_bits = 0;
> + unsigned long slice_bits = 0;
> + unsigned long hrd_delay = 0;
> + unsigned long final_scale = 0;
> + unsigned long rbs_min = 0;
> +
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> +   vdsc_cfg->bits_per_pixel,
> +   (8 * 16));
> +
> + if (vdsc_cfg->convert_rgb)
> + num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> +   (4 * vdsc_cfg->bits_per_component + 4)
> +   - 2);
> + else
> + num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 2 * (4 * vdsc_cfg->bits_per_component) - 2;
> + /* Number of bits in one Slice */
> + slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
> +
> + while ((num_extra_mux_bits > 0) &&
> +((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
> + num_extra_mux_bits--;
> +
> + if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> + vdsc_cfg->initial_scale_value = groups_per_line + 8;
> +
> + /* scale_decrement_interval calculation according to DSC spec 1.11 */
> + if (vdsc_cfg->initial_scale_value > 8)
> + vdsc_cfg->scale_decrement_interval = groups_per_line /
> + (vdsc_cfg->initial_scale_value - 8);
> + else
> + vdsc_cfg->scale_decrement_interval = 
> DSC_SCALE_DECREMENT_INTERVAL_MAX;
> +
> + vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> + (vdsc_cfg->initial_xmit_delay *
> +  vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
> +
> + if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> + DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
> InitialXmitDelay\n");
> + return -ERANGE;
> + }
> +
> + final_scale = (vdsc_cfg->rc_model_size * 8) /
> + (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
> + if (vdsc_cfg->slice_height > 1)
> + /*
> +  * NflBpgOffset is 16 bit value with 11 fractional bits
> +  * hence we multiply by 2^11 for preserving the
> +  * fractional part
> +  */
> + vdsc_cfg->nfl_bpg_offset = 
> DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
> + (vdsc_cfg->slice_height 
> - 1));
> + else
> + vdsc_cfg->nfl_bpg_offset = 0;
> +
> + /* 2^16 - 1 */
> + if (vdsc_cfg->nfl_bpg_offset > 65535) {
> + DRM_DEBUG_KMS("NflBpgOffset is too large for this slice 
> height\n");
> + return -ERANGE;
> + }
> +
> + /* Number of groups used to code the entire slice */
> + groups_total = groups_per_line * vdsc_cfg->slice_height;
> +
> + /* slice_bpg_offset is 16 bit value with 11 fractional bits */
> + vdsc_cfg->slice_bpg_offset = DIV_ROUND_UP(((vdsc_cfg->rc_model_size -
> + vdsc_cfg->initial_offset +
> + num_

Re: 2019 X.Org Board of Directors Elections Nomination period is NOW

[Wentland, Harry]

So far we've received a couple of nominations for four open spots. The official 
nomination period ends this Thursday. Please let us know if you'd like to 
nominate someone including yourself.

Harry

On 2019-01-31 5:08 p.m., Wentland, Harry wrote:
> 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 2019 election are now open and will remain open until 
> 23:59 UTC on 14 February 2019.
> 
> 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 2018 were Keith 
> Packard, Bryce Harrington, Eric Anholt, and Harry Wentland. They will 
> continue to serve until their term ends in 2020. Current directors whose term 
> expires in 2019 are Rob Clark, Martin Peres, Taylor Campbell 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, membership applications or renewals and completed personal 
> statements must be received no later than 23:59 UTC on 14 February 2019.
> 
> The slate of candidates will be published 21 February 2019 and candidate Q&A 
> will begin then. The deadline for Xorg membership applications and renewals 
> is 21 February 2019.
> 
> Cheers, Harry Wentland, on behalf of the X.Org BoD
> 
> 
> 
> 
> ___
> memb...@foundation.x.org: X.Org Foundation Members
> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 X.Org Board of Directors Elections Nomination period is NOW

[Wentland, Harry]

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 2019 election are now open and will remain open until 23:59 
UTC on 14 February 2019.

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 2018 were Keith Packard, 
Bryce Harrington, Eric Anholt, and Harry Wentland. They will continue to serve 
until their term ends in 2020. Current directors whose term expires in 2019 are 
Rob Clark, Martin Peres, Taylor Campbell 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, membership applications or renewals and completed personal 
statements must be received no later than 23:59 UTC on 14 February 2019.

The slate of candidates will be published 21 February 2019 and candidate Q&A 
will begin then. The deadline for Xorg membership applications and renewals is 
21 February 2019.

Cheers, Harry Wentland, on behalf of the X.Org BoD




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/vkms: Modify memset() in compute_crc function

[Wentland, Harry]

On 2019-01-29 5:00 p.m., Mamta Shukla wrote:
> Replace memset(vaddr_out + src_offset + 24, 0,  8) with
> memset(vaddr_out + src_offset + 3, 0, 1) because memset fills
> memory in bytes and not in bits.
> 
> Signed-off-by: Mamta Shukla 

Series is
Reviewed-by: Harry Wentland 

Harry

> ---
> No changes in v2.
> 
>  drivers/gpu/drm/vkms/vkms_crc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index dc6cb4c2cced..5135642fb204 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -31,7 +31,7 @@ static uint32_t compute_crc(void *vaddr_out, struct 
> vkms_crc_data *crc_out)
>+ (i * crc_out->pitch)
>+ (j * crc_out->cpp);
>   /* XRGB format ignores Alpha channel */
> - memset(vaddr_out + src_offset + 24, 0,  8);
> + memset(vaddr_out + src_offset + 3, 0, 1);
>   crc = crc32_le(crc, vaddr_out + src_offset,
>  sizeof(u32));
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines

[Wentland, Harry]

On 2019-01-29 1:56 p.m., Guenter Roeck wrote:
> On Tue, Jan 29, 2019 at 10:30:31AM -0500, Alex Deucher wrote:
>> On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry  
>> wrote:
>>>
>>> On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote:
>>>> arch/x86/Makefile disables SSE and SSE2 for the whole kernel.  The
>>>> AMDGPU drivers modified in this patch re-enable SSE but not SSE2.  Turn
>>>> on SSE2 to support emitting double precision floating point instructions
>>>> rather than calls to non-existent (usually available from gcc_s or
>>>> compiler_rt) floating point helper routines.
>>>>
>>>> Link: 
>>>> https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html
>>>> Link: https://github.com/ClangBuiltLinux/linux/issues/327
>>>> Cc: sta...@vger.kernel.org # 4.19
>>>> Reported-by: S, Shirish 
>>>> Reported-by: Matthias Kaehlcke 
>>>> Suggested-by: James Y Knight 
>>>> Suggested-by: Nathan Chancellor 
>>>> Signed-off-by: Nick Desaulniers 
>>>> Tested-by: Guenter Roeck 
>>>
>>> Reviewed-by: Harry Wentland 
>>>
>>> and applied.
>>>
>>
>> This patch causes a segfault:
>> https://bugs.freedesktop.org/show_bug.cgi?id=109487
>>
>> Any ideas?
>>
> 
> Set -msse2 only for clang ? I suspect, though, that this might only
> solve the compile problem. If I understand correctly, the first
> warning in the log is due to BREAK_TO_DEBUGGER(), suggesting that
> something is seriously wrong. Maybe enabling sse2 results in different
> results from floating point operations.
> 
> Unfortunately I don't have a system with the affected GPU,
> so I can't run any tests on real hardware. Unless someone can test
> with real hardware, I think we have no choice but to revert the
> patch.
> 

Might be a good idea. Even though, best to revert for now until we understand 
what's going on.

It seems like people at AMD building with gcc 5.4 are fine, but those using gcc 
7.3 or 8.2 experience the crash.

Harry

> Guenter
> 
>> Alex
>>
>>> Harry
>>>
>>>> ---
>>>>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +-
>>>>  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 2 +-
>>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
>>>> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>>>> index 95f332ee3e7e..dc85a3c088af 100644
>>>> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>>>> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>>>> @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),)
>>>>   cc_stack_align := -mstack-alignment=16
>>>>  endif
>>>>
>>>> -calcs_ccflags := -mhard-float -msse $(cc_stack_align)
>>>> +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align)
>>>>
>>>>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
>>>>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
>>>> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
>>>> b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>>> index d97ca6528f9d..33c7d7588712 100644
>>>> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>>> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
>>>> @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),)
>>>>   cc_stack_align := -mstack-alignment=16
>>>>  endif
>>>>
>>>> -dml_ccflags := -mhard-float -msse $(cc_stack_align)
>>>> +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align)
>>>>
>>>>  CFLAGS_display_mode_lib.o := $(dml_ccflags)
>>>>  CFLAGS_display_pipe_clocks.o := $(dml_ccflags)
>>>>
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines

[Wentland, Harry]

On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote:
> arch/x86/Makefile disables SSE and SSE2 for the whole kernel.  The
> AMDGPU drivers modified in this patch re-enable SSE but not SSE2.  Turn
> on SSE2 to support emitting double precision floating point instructions
> rather than calls to non-existent (usually available from gcc_s or
> compiler_rt) floating point helper routines.
> 
> Link: https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html
> Link: https://github.com/ClangBuiltLinux/linux/issues/327
> Cc: sta...@vger.kernel.org # 4.19
> Reported-by: S, Shirish 
> Reported-by: Matthias Kaehlcke 
> Suggested-by: James Y Knight 
> Suggested-by: Nathan Chancellor 
> Signed-off-by: Nick Desaulniers 
> Tested-by: Guenter Roeck 

Reviewed-by: Harry Wentland 

and applied.

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +-
>  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> index 95f332ee3e7e..dc85a3c088af 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),)
>   cc_stack_align := -mstack-alignment=16
>  endif
>  
> -calcs_ccflags := -mhard-float -msse $(cc_stack_align)
> +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align)
>  
>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> index d97ca6528f9d..33c7d7588712 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),)
>   cc_stack_align := -mstack-alignment=16
>  endif
>  
> -dml_ccflags := -mhard-float -msse $(cc_stack_align)
> +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align)
>  
>  CFLAGS_display_mode_lib.o := $(dml_ccflags)
>  CFLAGS_display_pipe_clocks.o := $(dml_ccflags)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Foundation Membership deadline for voting in the election

[Wentland, Harry]

There have been a bunch of sign-ups without names which makes for a confusing 
list on https://members.x.org/members

If you get chance please update your name and affiliation in your profile 
(username > Your Profile).

Harry

On 2019-01-24 9:42 a.m., Wentland, Harry wrote:
> Note that you will have to re-register in the new system. Your previous 
> credentials won't work.
> 
> Harry
> 
> On 2019-01-24 8:42 a.m., Wentland, Harry wrote:
>> The 2019 X.Org Foundation elections are rapidly approaching. We will be 
>> forwarding the nominating process to the membership shortly. Please find the 
>> election schedule below.
>>
>> Please note that only current members can vote in the upcoming election, and 
>> that the deadline for new memberships or renewals to vote in the upcoming 
>> election is 21 February 2019 at 23:59 UTC.
>>
>> If you are interested in joining the X.Org Foundation or in renewing your 
>> membership, please visit the membership system site at: 
>> https://members.x.org/
>>
>> Note that this year the membership site got a complete overhaul. If you 
>> experience any problems please open a ticket here: 
>> https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=
>>
>> Election Schedule:
>> Jan 31 - nomination period begins
>> Feb 14 - nomination period ends
>> Feb 21 - publish candidates, membership deadline
>> Feb 28 - election period begins
>> Mar 14 - election period ends
>>
>>
>> Harry Wentland, on behalf of the X.Org elections committee
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 2019 X.Org Foundation Membership deadline for voting in the election

[Wentland, Harry]

Note that you will have to re-register in the new system. Your previous 
credentials won't work.

Harry

On 2019-01-24 8:42 a.m., Wentland, Harry wrote:
> The 2019 X.Org Foundation elections are rapidly approaching. We will be 
> forwarding the nominating process to the membership shortly. Please find the 
> election schedule below.
> 
> Please note that only current members can vote in the upcoming election, and 
> that the deadline for new memberships or renewals to vote in the upcoming 
> election is 21 February 2019 at 23:59 UTC.
> 
> If you are interested in joining the X.Org Foundation or in renewing your 
> membership, please visit the membership system site at: https://members.x.org/
> 
> Note that this year the membership site got a complete overhaul. If you 
> experience any problems please open a ticket here: 
> https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=
> 
> Election Schedule:
> Jan 31 - nomination period begins
> Feb 14 - nomination period ends
> Feb 21 - publish candidates, membership deadline
> Feb 28 - election period begins
> Mar 14 - election period ends
> 
> 
> Harry Wentland, on behalf of the X.Org elections committee
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 X.Org Foundation Membership deadline for voting in the election

[Wentland, Harry]

The 2019 X.Org Foundation elections are rapidly approaching. We will be 
forwarding the nominating process to the membership shortly. Please find the 
election schedule below.

Please note that only current members can vote in the upcoming election, and 
that the deadline for new memberships or renewals to vote in the upcoming 
election is 21 February 2019 at 23:59 UTC.

If you are interested in joining the X.Org Foundation or in renewing your 
membership, please visit the membership system site at: https://members.x.org/

Note that this year the membership site got a complete overhaul. If you 
experience any problems please open a ticket here: 
https://gitlab.freedesktop.org/xorgfoundation/xorg_membership/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=

Election Schedule:
Jan 31 - nomination period begins
Feb 14 - nomination period ends
Feb 21 - publish candidates, membership deadline
Feb 28 - election period begins
Mar 14 - election period ends


Harry Wentland, on behalf of the X.Org elections committee


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [igt-dev] [PATCH] drm/doc: Make igts for cross-driver stuff mandatory

[Wentland, Harry]

On 2019-01-22 2:19 p.m., Daniel Vetter wrote:
> On Tue, Jan 22, 2019 at 8:00 PM Wentland, Harry  
> wrote:
>> On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
>>> Compared to the RFC[1] no changes to the patch itself, but igt moved
>>> forward a lot:
>>>
>>> - gitlab CI builds with: reduced configs/libraries, arm cross build
>>>   and a sysroot build (should address all the build/cross platform
>>>   concerns raised in the RFC discussions).
>>>
>>> - tests reorganized into subdirectories so that the i915-gem tests
>>>   don't clog the main/shared tests directory anymore
>>>
>>> - quite a few more non-intel people contributing/reviewing/committing
>>>   igt tests patches.
>>>
>>> I think this addresses all the concerns raised in the RFC discussions,
>>> and assuming there's enough Acks and no new issues that pop up, we can
>>> go ahead with this.
>>>
>>> 1: https://patchwork.kernel.org/patch/10648851/
>>> Cc: Petri Latvala 
>>> Cc: Arkadiusz Hiler 
>>> Cc: Liviu Dudau 
>>> Cc: Sean Paul 
>>> Cc: Eric Anholt 
>>> Cc: Alex Deucher 
>>> Cc: Dave Airlie 
>>> Signed-off-by: Daniel Vetter 
>>
>> I'm all for anything resembling TDD and standardizing on one test framework. 
>> IGT works quite well for us for testing display stuff. We still have a way 
>> to go but have been trying to adopt this requirement lately anyways for the 
>> DC driver. Can't really comment on anything beyond display, though, for AMD.
>>
>> No matter how much I want this to be mandatory, seeing the discussions with 
>> ARM and the comment about lack of CRC on Nouveau makes me think that we 
>> might not be quite ready to go there. Implementing DWB is non-trivial. VKMS 
>> knows how to compute a CRC from a framebuffer, but that's the trivial part. 
>> Setting up the HW and SW to do DWB is the hard part.
> 
> We also discussed a bit writeback implementations on irc, and it looks
> like you can't really use writeback to accurately test that your
> compositing engine is programmed correctly, since on at least vc4,
> malidp and msm (not yet merged upstream) the writeback engine can't be
> shared with any other outputs, often it even needs a
> dedicated/special-purpose CRTC (at least vc4 from what I can tell).
> That means if you botch your programming and e.g. cause an underrun
> scanning out continous-update outputs, then the writeback won't show
> that to you, since it's composited separately. I guess we could teach
> igt to run these tests on the special crtc->writeback pipeline only,
> but essentially that's a new testcase, and not really testing the
> actual display: It tests writeback, not hdmi/dp/panels/whatever real
> outputs you have.
> 
> I'd say we'll shrug these cases off as "can't be reasonable tested,
> won't have an igt". First driver team with hw that can be validated
> gets to fill the gaps :-) In practice still going to be a lot better
> than no tests at all, just exercising the feature will be useful, and
> will make it a lot easier for the next team to add the crc based tests
> on top.
> 

I think that's reasonable. After all, we want to start somewhere.

Would it make sense to append something like ", if such a test can be 
reasonably made using IGT for the target HW." to make it clear to contributors 
that in cases like the one discussed this is at the reviewers discretion?

With that change (or anything else that clarifies your intentions as described 
above) I'd be happy to give my AB.

Harry

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [igt-dev] [PATCH] drm/doc: Make igts for cross-driver stuff mandatory

[Wentland, Harry]

On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
> 
> - gitlab CI builds with: reduced configs/libraries, arm cross build
>   and a sysroot build (should address all the build/cross platform
>   concerns raised in the RFC discussions).
> 
> - tests reorganized into subdirectories so that the i915-gem tests
>   don't clog the main/shared tests directory anymore
> 
> - quite a few more non-intel people contributing/reviewing/committing
>   igt tests patches.
> 
> I think this addresses all the concerns raised in the RFC discussions,
> and assuming there's enough Acks and no new issues that pop up, we can
> go ahead with this.
> 
> 1: https://patchwork.kernel.org/patch/10648851/
> Cc: Petri Latvala 
> Cc: Arkadiusz Hiler 
> Cc: Liviu Dudau 
> Cc: Sean Paul 
> Cc: Eric Anholt 
> Cc: Alex Deucher 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 

I'm all for anything resembling TDD and standardizing on one test framework. 
IGT works quite well for us for testing display stuff. We still have a way to 
go but have been trying to adopt this requirement lately anyways for the DC 
driver. Can't really comment on anything beyond display, though, for AMD.

No matter how much I want this to be mandatory, seeing the discussions with ARM 
and the comment about lack of CRC on Nouveau makes me think that we might not 
be quite ready to go there. Implementing DWB is non-trivial. VKMS knows how to 
compute a CRC from a framebuffer, but that's the trivial part. Setting up the 
HW and SW to do DWB is the hard part.

Harry

> ---
>  Documentation/gpu/drm-uapi.rst | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index a752aa561ea4..413915d6b7d2 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -238,6 +238,13 @@ DRM specific patterns. Note that ENOTTY has the slightly 
> unintuitive meaning of
>  Testing and validation
>  ==
>  
> +Testing Requirements for userspace API
> +--
> +
> +New cross-driver userspace interface extensions, like new IOCTL, new KMS
> +properties, new files in sysfs or anything else that constitutes an API 
> change
> +need to have driver-agnostic testcases in IGT for that feature.
> +
>  Validating changes with IGT
>  ---
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 00/16] MST refcounting/atomic helpers cleanup

[Wentland, Harry]

On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> This is the series I've been working on for a while now to get all of
> the atomic DRM drivers in the tree to use the atomic MST helpers, and to
> make the atomic MST helpers actually idempotent. Turns out it's a lot
> more difficult to do that without also fixing how port and branch device
> refcounting works so that it actually makes sense, since the current
> upstream implementation requires a ton of magic in the atomic helpers to
> work around properly and in many situations just plain doesn't work as
> intended.
> 
> There's still more cleanup that can be done, but I think this is a good
> place to start off for now :).
> 
> This version just contains some changes that I forgot to make that had
> been requested much earlier, mainly in regards to the atomic checking
> code I added to i915 and nouveau (but not the helpers).
> 
> Also, per-request I've made a gitlab branch available for this:
> 
> https://gitlab.freedesktop.org/lyudess/linux/commits/wip/mst-dual-kref-start-v4
> 
> Lyude Paul (16):
>   drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and
> friends
>   drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
>   drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref
> fails
>   drm/dp_mst: Stop releasing VCPI when removing ports from topology
>   drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
>   drm/i915: Keep malloc references to MST ports
>   drm/amdgpu/display: Keep malloc ref to MST port
>   drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
>   drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
>   drm/nouveau: Keep malloc references to MST ports
>   drm/nouveau: Stop unsetting mstc->port, use malloc refs
>   drm/nouveau: Grab payload lock in nv50_msto_payload()
>   drm/dp_mst: Add some atomic state iterator macros
>   drm/dp_mst: Start tracking per-port VCPI allocations
>   drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
>   drm/nouveau: Use atomic VCPI helpers for MST
> 

Somehow I left my RB on v2 for a while. Either way patches 2-5, and 7 are
Reviewed-by: Harry Wentland 

Haven't had a chance to take a look at 13-15 but noticed the "Changes since v" 
mention versions that either aren't on the mailing list or don't line up with 
the patch versioning.

Harry 

>  .../gpu/dp-mst/topology-figure-1.dot  |  52 +
>  .../gpu/dp-mst/topology-figure-2.dot  |  56 ++
>  .../gpu/dp-mst/topology-figure-3.dot  |  59 ++
>  Documentation/gpu/drm-kms-helpers.rst |  26 +-
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  11 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c | 938 ++
>  drivers/gpu/drm/i915/intel_connector.c|   4 +
>  drivers/gpu/drm/i915/intel_display.c  |   4 +
>  drivers/gpu/drm/i915/intel_dp_mst.c   |  55 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  96 +-
>  include/drm/drm_dp_mst_helper.h   | 151 ++-
>  11 files changed, 1203 insertions(+), 249 deletions(-)
>  create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot
>  create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot
>  create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 07/16] drm/amdgpu/display: Keep malloc ref to MST port

[Wentland, Harry]

On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> Just like i915 and nouveau, it's a good idea for us to hold a malloc
> reference to the port here so that we never pass a freed pointer to any
> of the DP MST helper functions.
> 
> Also, we stop unsetting aconnector->port in
> dm_dp_destroy_mst_connector(). There's literally no point to that
> assignment that I can see anyway.
> 
> Signed-off-by: Lyude Paul 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 

Reviewed-by: Harry Wentland 

Harry


> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c   | 11 +++
>  1 file changed, 7 insertions(+), 4 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 5e7ca1f3a8d1..24632727e127 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
> @@ -191,6 +191,7 @@ dm_dp_mst_connector_destroy(struct drm_connector 
> *connector)
>   drm_encoder_cleanup(&amdgpu_encoder->base);
>   kfree(amdgpu_encoder);
>   drm_connector_cleanup(connector);
> + drm_dp_mst_put_port_malloc(amdgpu_dm_connector->port);
>   kfree(amdgpu_dm_connector);
>  }
>  
> @@ -363,7 +364,9 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
> *mgr,
>   amdgpu_dm_connector_funcs_reset(connector);
>  
>   DRM_INFO("DM_MST: added connector: %p [id: %d] [master: %p]\n",
> - aconnector, connector->base.id, aconnector->mst_port);
> +  aconnector, connector->base.id, aconnector->mst_port);
> +
> + drm_dp_mst_get_port_malloc(port);
>  
>   DRM_DEBUG_KMS(":%d\n", connector->base.id);
>  
> @@ -379,12 +382,12 @@ static void dm_dp_destroy_mst_connector(struct 
> drm_dp_mst_topology_mgr *mgr,
>   struct amdgpu_dm_connector *aconnector = 
> to_amdgpu_dm_connector(connector);
>  
>   DRM_INFO("DM_MST: Disabling connector: %p [id: %d] [master: %p]\n",
> - aconnector, connector->base.id, 
> aconnector->mst_port);
> +  aconnector, connector->base.id, aconnector->mst_port);
>  
> - aconnector->port = NULL;
>   if (aconnector->dc_sink) {
>   amdgpu_dm_update_freesync_caps(connector, NULL);
> - dc_link_remove_remote_sink(aconnector->dc_link, 
> aconnector->dc_sink);
> + dc_link_remove_remote_sink(aconnector->dc_link,
> +aconnector->dc_sink);
>   dc_sink_release(aconnector->dc_sink);
>   aconnector->dc_sink = NULL;
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/16] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs

[Wentland, Harry]

On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> Up until now, freeing payloads on remote MST hubs that just had ports
> removed has almost never worked because we've been relying on port
> validation in order to stop us from accessing ports that have already
> been freed from memory, but ports which need their payloads released due
> to being removed will never be a valid part of the topology after
> they've been removed.
> 
> Since we've introduced malloc refs, we can replace all of the validation
> logic in payload helpers which are used for deallocation with some
> well-placed malloc krefs. This ensures that regardless of whether or not
> the ports are still valid and in the topology, any port which has an
> allocated payload will remain allocated in memory until it's payloads
> have been removed - finally allowing us to actually release said
> payloads correctly.
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
>  1 file changed, 30 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ef8637f37564..11dd3ede7b7d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2100,10 +2100,6 @@ static int drm_dp_payload_send_msg(struct 
> drm_dp_mst_topology_mgr *mgr,
>   u8 sinks[DRM_DP_MAX_SDP_STREAMS];
>   int i;
>  
> - port = drm_dp_mst_topology_get_port_validated(mgr, port);
> - if (!port)
> - return -EINVAL;
> -
>   port_num = port->port_num;
>   mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
>   if (!mstb) {
> @@ -2111,10 +2107,8 @@ static int drm_dp_payload_send_msg(struct 
> drm_dp_mst_topology_mgr *mgr,
>  port->parent,
>  &port_num);
>  
> - if (!mstb) {
> - drm_dp_mst_topology_put_port(port);
> + if (!mstb)
>   return -EINVAL;
> - }
>   }
>  
>   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> @@ -2151,7 +2145,6 @@ static int drm_dp_payload_send_msg(struct 
> drm_dp_mst_topology_mgr *mgr,
>   kfree(txmsg);
>  fail_put:
>   drm_dp_mst_topology_put_mstb(mstb);
> - drm_dp_mst_topology_put_port(port);
>   return ret;
>  }
>  
> @@ -2256,15 +2249,16 @@ static int drm_dp_destroy_payload_step2(struct 
> drm_dp_mst_topology_mgr *mgr,
>   */
>  int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
>  {
> - int i, j;
> - int cur_slots = 1;
>   struct drm_dp_payload req_payload;
>   struct drm_dp_mst_port *port;
> + int i, j;
> + int cur_slots = 1;
>  
>   mutex_lock(&mgr->payload_lock);
>   for (i = 0; i < mgr->max_payloads; i++) {
>   struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
>   struct drm_dp_payload *payload = &mgr->payloads[i];
> + bool put_port = false;
>  
>   /* solve the current payloads - compare to the hw ones
>  - update the hw view */
> @@ -2272,12 +2266,20 @@ int drm_dp_update_payload_part1(struct 
> drm_dp_mst_topology_mgr *mgr)
>   if (vcpi) {
>   port = container_of(vcpi, struct drm_dp_mst_port,
>   vcpi);
> - port = drm_dp_mst_topology_get_port_validated(mgr,
> -   port);
> - if (!port) {
> - mutex_unlock(&mgr->payload_lock);
> - return -EINVAL;
> +
> + /* Validated ports don't matter if we're releasing
> +  * VCPI
> +  */
> + if (vcpi->num_slots) {
> + port = drm_dp_mst_topology_get_port_validated(
> + mgr, port);
> + if (!port) {
> + mutex_unlock(&mgr->payload_lock);
> + return -EINVAL;
> + }
> + put_port = true;
>   }
> +
>   req_payload.num_slots = vcpi->num_slots;
>   

Re: [PATCH v2 04/16] drm/dp_mst: Stop releasing VCPI when removing ports from topology

[Wentland, Harry]

On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 356a95aba2d8..ef8637f37564 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1175,8 +1175,6 @@ static void drm_dp_destroy_port(struct kref *kref)
>   struct drm_dp_mst_topology_mgr *mgr = port->mgr;
>  
>   if (!port->input) {
> - port->vcpi.num_slots = 0;
> -
>   kfree(port->cached_edid);
>  
>   /*
> @@ -3491,12 +3489,6 @@ static void drm_dp_destroy_connector_work(struct 
> work_struct *work)
>   drm_dp_port_teardown_pdt(port, port->pdt);
>   port->pdt = DP_PEER_DEVICE_NONE;
>  
> - if (!port->input && port->vcpi.vcpi > 0) {
> - drm_dp_mst_reset_vcpi_slots(mgr, port);
> - drm_dp_update_payload_part1(mgr);
> - drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
> - }
> -
>   drm_dp_mst_put_port_malloc(port);
>   send_hotplug = true;
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 03/16] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails

[Wentland, Harry]

On 2018-12-19 7:19 p.m., Lyude Paul wrote:
> While this isn't a complete fix, this will improve the reliability of
> drm_dp_get_last_connected_port_and_mstb() pretty significantly during
> hotplug events, since there's a chance that the in-memory topology tree
> may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
> is called and thus might end up causing our search to fail on an mstb
> whose topology refcount has reached 0, but has not yet been removed from
> it's parent.
> 
> Ideally, we should further fix this problem by ensuring that we deal
> with the potential for racing with a hotplug event, which would look
> like this:
> 
> * drm_dp_payload_send_msg() retrieves the last living relative of mstb
>   with drm_dp_get_last_connected_port_and_mstb()
> * drm_dp_payload_send_msg() starts building payload message
>   At the same time, mstb gets unplugged from the topology and is no
>   longer the actual last living relative of the original mstb
> * drm_dp_payload_send_msg() tries sending the payload message, hub times
>   out
> * Hub timed out, we give up and run away-resulting in the payload being
>   leaked
> 
> This could be fixed by restarting the
> drm_dp_get_last_connected_port_and_mstb() search whenever we get a
> timeout, sending the payload to the new mstb, then repeating until
> either the entire topology is removed from the system or
> drm_dp_get_last_connected_port_and_mstb() fails. But since the above
> race condition is not terribly likely, we'll address that in a later
> patch series once we've improved the recovery handling for VCPI
> allocations in the rest of the DP MST helpers.
> 
> Signed-off-by: Lyude Paul 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 55 +--
>  1 file changed, 44 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index b380ada09e90..356a95aba2d8 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2043,25 +2043,50 @@ static struct drm_dp_mst_port 
> *drm_dp_get_last_connected_port_to_mstb(struct drm
>   return 
> drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
>  }
>  
> -static struct drm_dp_mst_branch 
> *drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
> -  struct 
> drm_dp_mst_branch *mstb,
> -  int 
> *port_num)
> +/**
> + * drm_dp_get_last_connected_port_and_mstb() - Find the last living relatives
> + * in a topology of a given branch device
> + * @mgr: The topology manager to use
> + * @mstb: The disconnected branch device
> + * @port_num: Where to store the number of the last connected port
> + *
> + * Searches upwards in the topology starting from @mstb to try to find the
> + * closest available parent of @mstb that's still connected to the rest of 
> the
> + * topology. This can be used in order to perform operations like releasing
> + * payloads, where the branch device which owned the payload may no longer be
> + * around and thus would require that the payload on the last living relative
> + * be freed instead.
> + *
> + * Returns:
> + * The last connected &drm_dp_mst_branch in the topology that was a parent of
> + * @mstb, if there is one.
> + */
> +static struct drm_dp_mst_branch *
> +drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_mst_branch *mstb,
> + int *port_num)
>  {
>   struct drm_dp_mst_branch *rmstb = NULL;
>   struct drm_dp_mst_port *found_port;
> +
>   mutex_lock(&mgr->lock);
> - if (mgr->mst_primary) {
> + if (!mgr->mst_primary)
> + goto out;
> +
> + do {
>   found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
> + if (!found_port)
> + break;
>  
> - if (found_port) {
> + if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
>   rmstb = found_port->parent;
> - if (drm_dp_mst_topology_try_get_mstb(rmstb)) {
> - *port_num = found_port->port_num;
> - } else {
> - rmstb = NULL;
> - }
> +

Re: [PATCH v4 02/16] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports

[Wentland, Harry]

On 2019-01-04 7:14 p.m., Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things could be simplified.
> 
> To the best of my understanding, the current scheme works like this:
> drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
> this refcount hits 0 for either of the two, they're removed from the
> topology state, but not immediately freed. Both ports and branch devices
> will reinitialize their kref once it's hit 0 before actually destroying
> themselves. The intended purpose behind this is so that we can avoid
> problems like not being able to free a remote payload that might still
> be active, due to us having removed all of the port/branch device
> structures in memory, as per:
> 
> commit 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
> 
> Which may have worked, but then it caused use-after-free errors. Being
> new to MST at the time, I tried fixing it;
> 
> commit 263efde31f97 ("drm/dp/mst: Get validated port ref in 
> drm_dp_update_payload_part1()")
> 
> But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
> are validated in almost every DP MST helper function. Simply put, this
> means we go through the topology and try to see if the given
> drm_dp_mst_branch or drm_dp_mst_port is still attached to something
> before trying to use it in order to avoid dereferencing freed memory
> (something that has happened a LOT in the past with this library).
> Because of this it doesn't actually matter whether or not we keep keep
> the ports and branches around in memory as that's not enough, because
> any function that validates the branches and ports passed to it will
> still reject them anyway since they're no longer in the topology
> structure. So, use-after-free errors were fixed but payload deallocation
> was completely broken.
> 
> Two years later, AMD informed me about this issue and I attempted to
> come up with a temporary fix, pending a long-overdue cleanup of this
> library:
> 
> commit c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, 
> just ref")
> 
> But then that introduced use-after-free errors, so I quickly reverted
> it:
> 
> commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during 
> destruction, just ref"")
> 
> And in the process, learned that there is just no simple fix for this:
> the design is just broken. Unfortuntely, the usage of these helpers are
> quite broken as well. Some drivers like i915 have been smart enough to
> avoid accessing any kind of information from MST port structures, but
> others like nouveau have assumed, understandably so, that
> drm_dp_mst_port structures are normal and can just be accessed at any
> time without worrying about use-after-free errors.
> 
> After a lot of discussion, me and Daniel Vetter came up with a better
> idea to replace all of this.
> 
> To summarize, since this is documented far more indepth in the
> documentation this patch introduces, we make it so that drm_dp_mst_port
> and drm_dp_mst_branch structures have two different classes of
> refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
> the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
> given topology. Once it hits zero, any associated connectors are removed
> and the branch or port can no longer be validated. malloc_kref
> corresponds to the lifetime of the memory allocation for the actual
> structure, and will always be non-zero so long as the topology_kref is
> non-zero. This gives us a way to allow callers to hold onto port and
> branch device structures past their topology lifetime, and dramatically
> simplifies the lifetimes of both structures. This also finally fixes the
> port deallocation problem, properly.
> 
> Additionally: since this now means that we can keep ports and branch
> devices allocated in memory for however long we need, we no longer need
> a significant amount of the port validation that we currently do.
> 
> Additionally, there is one last scenario that this fixes, which couldn't
> have been fixed properly beforehand:
> 
> - CPU1 unrefs port from topology (refcount 1->0)
> - CPU2 refs port in topology(refcount 0->1)
> 
> Since we now can guarantee memory safety for ports and branches
> as-needed, we also can make our main reference counting functions fix
> this problem by using kref_get_unless_zero() internally so that topology
> refcounts can only ever reach 0 once.
> 
> Changes since v2:
> * Fix commit message - checkpatch
> Changes since v1:
> * Remove forward declarations - danvet
> * Move "Branch device and port refcounting" section from documentation
>   into kernel-doc comments - danvet
> * Export internal topology lifetime functions into their own section in
>   the kernel-docs - danvet
> * s/@/&/g for struct references

Re: [PATCH 0/3] drm/amdgpu: Fix suspend/resume issues with MST

[Wentland, Harry]

On 2019-01-07 7:56 p.m., Lyude Paul wrote:
> Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some
> compiler warnings for drivers ignoring the return code of
> drm_dp_mst_topology_mgr_resume() to help ensure we don't need to fix
> this again in the future for someone else's driver.
> 
> Cc: Jerry Zuo 

With the small change Daniel mentioned this series is
Reviewed-by: Harry Wentland 

Harry

> 
> Lyude Paul (3):
>   drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()
>   drm/amdgpu: Don't fail resume process if resuming atomic state fails
>   drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume()
> 
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 37 +--
>  drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
>  include/drm/drm_dp_mst_helper.h   |  3 +-
>  3 files changed, 29 insertions(+), 14 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Fix boolean expression in get_surf_rq_param

[Wentland, Harry]

On 2019-01-03 2:48 p.m., Gustavo A. R. Silva wrote:
> Fix boolean expression by using logical AND operator '&&'
> instead of bitwise operator '&'.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: 6d04ee9dc101 ("drm/amd/display: Restructuring and cleaning up DML")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Harry Wentland 

and applied.

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c 
> b/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c
> index c2037daa8e66..d341b69fdc1a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.c
> @@ -881,7 +881,7 @@ static void get_surf_rq_param(
>   /* the dpte_group_bytes is reduced for the specific case of vertical
>* access of a tile surface that has dpte request of 8x1 ptes.
>*/
> - if (!surf_linear & (log2_dpte_req_height_ptes == 0) & surf_vert) 
> /*reduced, in this case, will have page fault within a group */
> + if (!surf_linear && (log2_dpte_req_height_ptes == 0) && surf_vert) 
> /*reduced, in this case, will have page fault within a group */
>   rq_sizing_param->dpte_group_bytes = 512;
>   else
>   /*full size */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Fix 64-bit division for 32-bit builds

[Wentland, Harry]

On 2018-12-19 3:28 p.m., sunpeng...@amd.com wrote:
> From: Ken Chalmers 
> 
> [Why]
> 32-bit builds break when doing 64-bit division directly.
> 
> [How]
> Use the div_u64() function instead to perform the division.
> 
> Fixes: 
> https://lists.freedesktop.org/archives/dri-devel/2018-December/201008.html
> Signed-off-by: Ken Chalmers 
> Reviewed-by: Leo Li 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c 
> b/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c
> index 5c629ae..8b5ce55 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_timing_generator.c
> @@ -94,7 +94,7 @@ static void program_pix_dur(struct timing_generator *tg, 
> uint32_t pix_clk_100hz)
>   if (pix_clk_100hz == 0)
>   return;
>  
> - pix_dur = 100ull / pix_clk_100hz;
> + pix_dur = div_u64(100ull, pix_clk_100hz);
>  
>   set_reg_field_value(
>   value,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [WIP PATCH 02/15] drm/dp_mst: Refactor drm_dp_update_payload_part1()

[Wentland, Harry]

On 2018-12-14 3:47 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote:
>> There should be no functional changes here
> 
> Would be good to explain what you did refactor here, instead of me trying
> to reconstruct it from the patch. Especially pre-coffee that helps :-)

I concur. Something like "use local variables to improve readability".

With that fixed this is
Reviewed-by: Harry Wentland 

Harry

>>
>> Signed-off-by: Lyude Paul 
>> Cc: Juston Li 
>> ---
>>  drivers/gpu/drm/drm_dp_mst_topology.c | 71 ---
>>  1 file changed, 42 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index 9b1b5c9b1fa0..2ab16c9e6243 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1879,39 +1879,48 @@ int drm_dp_update_payload_part1(struct 
>> drm_dp_mst_topology_mgr *mgr)
>>  
>>  mutex_lock(&mgr->payload_lock);
>>  for (i = 0; i < mgr->max_payloads; i++) {
>> +struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
>> +struct drm_dp_payload *payload = &mgr->payloads[i];
>> +
>>  /* solve the current payloads - compare to the hw ones
>> - update the hw view */
>>  req_payload.start_slot = cur_slots;
>> -if (mgr->proposed_vcpis[i]) {
>> -port = container_of(mgr->proposed_vcpis[i], struct 
>> drm_dp_mst_port, vcpi);
>> +if (vcpi) {
>> +port = container_of(vcpi, struct drm_dp_mst_port,
>> +vcpi);
>>  port = drm_dp_get_validated_port_ref(mgr, port);
>>  if (!port) {
>>  mutex_unlock(&mgr->payload_lock);
>>  return -EINVAL;
>>  }
>> -req_payload.num_slots = 
>> mgr->proposed_vcpis[i]->num_slots;
>> -req_payload.vcpi = mgr->proposed_vcpis[i]->vcpi;
>> +req_payload.num_slots = vcpi->num_slots;
>> +req_payload.vcpi = vcpi->vcpi;
>>  } else {
>>  port = NULL;
>>  req_payload.num_slots = 0;
>>  }
>>  
>> -mgr->payloads[i].start_slot = req_payload.start_slot;
>> +payload->start_slot = req_payload.start_slot;
>>  /* work out what is required to happen with this payload */
>> -if (mgr->payloads[i].num_slots != req_payload.num_slots) {
>> +if (payload->num_slots != req_payload.num_slots) {
>>  
>>  /* need to push an update for this payload */
>>  if (req_payload.num_slots) {
>> -drm_dp_create_payload_step1(mgr, 
>> mgr->proposed_vcpis[i]->vcpi, &req_payload);
>> -mgr->payloads[i].num_slots = 
>> req_payload.num_slots;
>> -mgr->payloads[i].vcpi = req_payload.vcpi;
>> -} else if (mgr->payloads[i].num_slots) {
>> -mgr->payloads[i].num_slots = 0;
>> -drm_dp_destroy_payload_step1(mgr, port, 
>> mgr->payloads[i].vcpi, &mgr->payloads[i]);
>> -req_payload.payload_state = 
>> mgr->payloads[i].payload_state;
>> -mgr->payloads[i].start_slot = 0;
>> +drm_dp_create_payload_step1(mgr, vcpi->vcpi,
>> +&req_payload);
>> +payload->num_slots = req_payload.num_slots;
>> +payload->vcpi = req_payload.vcpi;
>> +
>> +} else if (payload->num_slots) {
>> +payload->num_slots = 0;
>> +drm_dp_destroy_payload_step1(mgr, port,
>> + payload->vcpi,
>> + payload);
>> +req_payload.payload_state =
>> +payload->payload_state;
>> +payload->start_slot = 0;
>>  }
>> -mg

Re: [WIP PATCH 01/15] drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1()

[Wentland, Harry]

On 2018-12-14 3:42 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote:
>> There's no reason we need this, it's just confusing looking.
>>
>> Signed-off-by: Lyude Paul 
>> Cc: Juston Li 
>> ---
>>  drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index ad0fb6d003be..9b1b5c9b1fa0 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1896,9 +1896,7 @@ int drm_dp_update_payload_part1(struct 
>> drm_dp_mst_topology_mgr *mgr)
>>  req_payload.num_slots = 0;
>>  }
>>  
>> -if (mgr->payloads[i].start_slot != req_payload.start_slot) {
>> -mgr->payloads[i].start_slot = req_payload.start_slot;
>> -}
>> +    mgr->payloads[i].start_slot = req_payload.start_slot;
> 
> Entertaining!
> 
> Reviewed-by: Daniel Vetter 
> 

Reviewed-by: Harry Wentland 

Harry

>>  /* work out what is required to happen with this payload */
>>  if (mgr->payloads[i].num_slots != req_payload.num_slots) {
>>  
>> -- 
>> 2.19.2
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Pass app_tf by value rather than by reference

[Wentland, Harry]

On 2018-12-11 5:07 p.m., Nick Desaulniers wrote:
> On Tue, Dec 11, 2018 at 1:42 PM Nathan Chancellor
>  wrote:
>>
>> On Tue, Dec 11, 2018 at 01:25:00PM -0800, Nick Desaulniers wrote:
>>> On Mon, Dec 10, 2018 at 3:42 PM Nathan Chancellor
>>>  wrote:

 Clang warns when an expression that equals zero is used as a null
 pointer constant (in lieu of NULL):

 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4435:3:
 warning: expression which evaluates to zero treated as a null pointer
 constant of type 'const enum color_transfer_func *'
 [-Wnon-literal-null-conversion]
 TRANSFER_FUNC_UNKNOWN,
 ^
 1 warning generated.

 This warning is caused by commit bb47de736661 ("drm/amdgpu: Set FreeSync
 state using drm VRR properties") and it could be solved by using NULL
 instead of TRANSFER_FUNC_UNKNOWN or casting TRANSFER_FUNC_UNKNOWN as a
 pointer. However, after looking into it, there doesn't appear to be a
 good reason to pass app_tf by reference as it is never mutated along the
 way. This is the only code path in which app_tf is used:

 mod_freesync_build_vrr_infopacket ->
 build_vrr_infopacket_v2 ->
 build_vrr_infopacket_fs2_data

 Neither mod_freesync_build_vrr_infopacket or build_vrr_infopacket_v2
 modify app_tf's value and build_vrr_infopacket_fs2_data expects just
 the value so we can avoid dereferencing anything by just passing in
 app_tf's value to mod_freesync_build_vrr_infopacket and
 build_vrr_infopacket_v2.

 There is no functional change because build_vrr_infopacket_fs2_data
 doesn't do anything if TRANSFER_FUNC_UNKNOWN is passed to it, the same
 as not calling build_vrr_infopacket_fs2_data at all like before this
 change when NULL was used for app_tf.
>>>
>>> Nathan,
>>> Thanks for sending this patch.  I was hoping to provide review sooner,
>>> but have been quite busy lately.
>>>
>>
>> Late review is better than no review, I appeciate you taking the time to
>> do this!
>>
>>> Yeah, especially for LP64 targets, the pointer to enum is larger than
>>> just the enum, and if it's not being updated ("in/out paramter")
>>> there's no need to pass by pointer.
>>>
>>
>> Thanks for confirming!
>>

 Signed-off-by: Nathan Chancellor 
 ---
  drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 7 +++
  drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h  | 2 +-
  2 files changed, 4 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
 b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
 index 620a171620ee..520665a9d81a 100644
 --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
 +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
 @@ -656,7 +656,7 @@ static void build_vrr_infopacket_v1(enum signal_type 
 signal,

  static void build_vrr_infopacket_v2(enum signal_type signal,
 const struct mod_vrr_params *vrr,
 -   const enum color_transfer_func *app_tf,
 +   enum color_transfer_func app_tf,
 struct dc_info_packet *infopacket)
  {
 unsigned int payload_size = 0;
 @@ -664,8 +664,7 @@ static void build_vrr_infopacket_v2(enum signal_type 
 signal,
 build_vrr_infopacket_header_v2(signal, infopacket, &payload_size);
 build_vrr_infopacket_data(vrr, infopacket);

 -   if (app_tf != NULL)
 -   build_vrr_infopacket_fs2_data(*app_tf, infopacket);
 +   build_vrr_infopacket_fs2_data(app_tf, infopacket);

 build_vrr_infopacket_checksum(&payload_size, infopacket);

 @@ -676,7 +675,7 @@ void mod_freesync_build_vrr_infopacket(struct 
 mod_freesync *mod_freesync,
 const struct dc_stream_state *stream,
 const struct mod_vrr_params *vrr,
 enum vrr_packet_type packet_type,
 -   const enum color_transfer_func *app_tf,
 +   enum color_transfer_func app_tf,
 struct dc_info_packet *infopacket)
  {
 /* SPD info packet for FreeSync */
 diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h 
 b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
 index 949a8b62aa98..063af6258fd9 100644
 --- a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
 +++ b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
 @@ -145,7 +145,7 @@ void mod_freesync_build_vrr_infopacket(struct 
 mod_freesync *mod_freesync,
 const struct dc_stream_state *stream,
 const struct mod_vrr_params *vrr,
 enum vrr_packet_type packet_type,
 -   const enum color_transfer_func *app_tf,
 +  

Re: [PATCH i-g-t] igt: add timeline test cases v2

[Wentland, Harry]

On 2018-12-11 5:37 a.m., Chunming Zhou wrote:
> v2: adapt to new transfer ioctl
> 
> Signed-off-by: Chunming Zhou 

+igt-dev

I think intel-gfx still works for IGT development but most of the IGT work 
happens on igt-...@lists.freedesktop.org now.

Harry

> ---
>  include/drm-uapi/drm.h   |   33 ++
>  lib/igt_syncobj.c|  206 
>  lib/igt_syncobj.h|   19 +
>  tests/meson.build|1 +
>  tests/syncobj_timeline.c | 1032 ++
>  5 files changed, 1291 insertions(+)
>  create mode 100644 tests/syncobj_timeline.c
> 
> diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
> index 85c685a2..dcd245d9 100644
> --- a/include/drm-uapi/drm.h
> +++ b/include/drm-uapi/drm.h
> @@ -731,6 +731,8 @@ struct drm_syncobj_handle {
>  
>  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
>  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> +/* wait for time point to become available */
> +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2)
>  struct drm_syncobj_wait {
>   __u64 handles;
>   /* absolute timeout */
> @@ -741,11 +743,38 @@ struct drm_syncobj_wait {
>   __u32 pad;
>  };
>  
> +struct drm_syncobj_timeline_wait {
> +__u64 handles;
> +/* wait on specific timeline point for every handles*/
> +__u64 points;
> +/* absolute timeout */
> +__s64 timeout_nsec;
> +__u32 count_handles;
> +__u32 flags;
> +__u32 first_signaled; /* only valid when not waiting all */
> +__u32 pad;
> +};
> +
>  struct drm_syncobj_array {
>   __u64 handles;
>   __u32 count_handles;
>   __u32 pad;
>  };
> +struct drm_syncobj_timeline_array {
> +   __u64 handles;
> +   __u64 points;
> +   __u32 count_handles;
> +   __u32 pad;
> +};
> +
> +struct drm_syncobj_transfer {
> +__u32 src_handle;
> +__u32 dst_handle;
> +__u64 src_point;
> +__u64 dst_point;
> +__u32 flags;
> +__u32 pad;
> +};
>  
>  /* Query current scanout sequence number */
>  struct drm_crtc_get_sequence {
> @@ -902,6 +931,10 @@ extern "C" {
>  #define DRM_IOCTL_MODE_LIST_LESSEES  DRM_IOWR(0xC7, struct 
> drm_mode_list_lessees)
>  #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct 
> drm_mode_get_lease)
>  #define DRM_IOCTL_MODE_REVOKE_LEASE  DRM_IOWR(0xC9, struct 
> drm_mode_revoke_lease)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct 
> drm_syncobj_timeline_wait)
> +#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct 
> drm_syncobj_timeline_array)
> +#define DRM_IOCTL_SYNCOBJ_TRANSFERDRM_IOWR(0xCC, struct 
> drm_syncobj_transfer)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct 
> drm_syncobj_timeline_array)
>  
>  /**
>   * Device specific ioctls should only be in their respective headers
> diff --git a/lib/igt_syncobj.c b/lib/igt_syncobj.c
> index d9114ca8..efa2adc4 100644
> --- a/lib/igt_syncobj.c
> +++ b/lib/igt_syncobj.c
> @@ -286,3 +286,209 @@ syncobj_signal(int fd, uint32_t *handles, uint32_t 
> count)
>  {
>   igt_assert_eq(__syncobj_signal(fd, handles, count), 0);
>  }
> +
> +static int
> +__syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points, 
> uint32_t count)
> +{
> + struct drm_syncobj_timeline_array array = { 0 };
> + int err = 0;
> +
> + array.handles = to_user_pointer(handles);
> + array.points = to_user_pointer(points);
> + array.count_handles = count;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, &array))
> + err = -errno;
> + return err;
> +}
> +
> +/**
> + * syncobj_signal:
> + * @fd: The DRM file descriptor.
> + * @handles: Array of syncobj handles to signal
> + * @points: List of point of handles to signal.
> + * @count: Count of syncobj handles.
> + *
> + * Signal a set of syncobjs.
> + */
> +void
> +syncobj_timeline_signal(int fd, uint32_t *handles, uint64_t *points, 
> uint32_t count)
> +{
> + igt_assert_eq(__syncobj_timeline_signal(fd, handles, points, count), 0);
> +}
> +int
> +__syncobj_timeline_wait_ioctl(int fd, struct drm_syncobj_timeline_wait *args)
> +{
> + int err = 0;
> + if (drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, args))
> + err = -errno;
> + return err;
> +}
> +static int
> +__syncobj_timeline_wait(int fd, uint32_t *handles, uint64_t *points,
> + unsigned num_handles,
> + int64_t timeout_nsec, unsigned flags,
> + uint32_t *first_signaled)
> +{
> + struct drm_syncobj_timeline_wait args;
> + int ret;
> +
> + args.handles = to_user_pointer(handles);
> + args.points = (uint64_t)to_user_pointer(points);
> + args.timeout_nsec = timeout_nsec;
> + args.count_handles = num_handles;
> + args.flags = flags;
> + args.first_signaled = 0;
> + args.pad = 0;
> +
> + ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, &args);
> + if (ret < 0)
> + return -err

Re: [PATCH] drm/amd/display: Fix compile error with ACPI disabled

[Wentland, Harry]

On 2018-11-27 11:18 a.m., David Francis wrote:
> The fallback code for getting default backlight caps was using
> the wrong variable name.  Fix it.
> 
> Fixes: 
> https://lists.freedesktop.org/archives/dri-devel/2018-November/197752.html
> Signed-off-by: David Francis 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  1 file changed, 2 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 27df3ae945be..aa3f8200fa69 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1615,8 +1615,8 @@ static void amdgpu_dm_update_backlight_caps(struct 
> amdgpu_display_manager *dm)
>   AMDGPU_DM_DEFAULT_MAX_BACKLIGHT;
>   }
>  #else
> - dm->backlight_min_input_signal = AMDGPU_DM_DEFAULT_MIN_BACKLIGHT;
> - dm->backlight_max_input_signal = AMDGPU_DM_DEFAULT_MAX_BACKLIGHT;
> + dm->backlight_caps.min_input_signal = AMDGPU_DM_DEFAULT_MIN_BACKLIGHT;
> + dm->backlight_caps.max_input_signal = AMDGPU_DM_DEFAULT_MAX_BACKLIGHT;
>  #endif
>  }
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 3/5] drm: Document variable refresh properties

[Wentland, Harry]

On 2018-11-27 4:22 a.m., Daniel Vetter wrote:
> On Mon, Nov 12, 2018 at 04:12:10PM +0000, Wentland, Harry wrote:
>> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
>>> These include the drm_connector 'vrr_capable' and the drm_crtc
>>> 'vrr_enabled' properties.
>>>
>>> Signed-off-by: Nicholas Kazlauskas 
>>> Cc: Harry Wentland 
>>> Cc: Manasi Navare 
>>> Cc: Pekka Paalanen 
>>> Cc: Ville Syrjälä 
>>> Cc: Michel Dänzer 
>>
>> Looks good. Whole series is
>> Reviewed-by: Harry Wentland 
>>
>> How are we with the userspace patches? We should probably hold off
>> pushing the kernel patches until the userspace work is all reviewed.
> 
> Do some igts exist for this too? Especially for tricky pieces of uapi
> having a non-vendor reference code somewhere would be good, aside from
> testing and all that.

Not yet, unfortunately, although it's on our list of things to do.

Harry

> -Daniel
> 
>>
>> Harry
>>
>>> ---
>>>  Documentation/gpu/drm-kms.rst   |  7 
>>>  drivers/gpu/drm/drm_connector.c | 68 +
>>>  2 files changed, 75 insertions(+)
>>>
>>> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
>>> index 4b1501b4835b..8da2a178cf85 100644
>>> --- a/Documentation/gpu/drm-kms.rst
>>> +++ b/Documentation/gpu/drm-kms.rst
>>> @@ -575,6 +575,13 @@ Explicit Fencing Properties
>>>  .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
>>> :doc: explicit fencing properties
>>>  
>>> +
>>> +Variable Refresh Properties
>>> +---
>>> +
>>> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
>>> +   :doc: Variable refresh properties
>>> +
>>>  Existing KMS Properties
>>>  ---
>>>  
>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>> b/drivers/gpu/drm/drm_connector.c
>>> index 49290060ab7b..0e4287461997 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct 
>>> drm_device *dev)
>>>  }
>>>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>>>  
>>> +/**
>>> + * DOC: Variable refresh properties
>>> + *
>>> + * Variable refresh rate capable displays can dynamically adjust their
>>> + * refresh rate by extending the duration of their vertical front porch
>>> + * until page flip or timeout occurs. This can reduce or remove stuttering
>>> + * and latency in scenarios where the page flip does not align with the
>>> + * vblank interval.
>>> + *
>>> + * An example scenario would be an application flipping at a constant rate
>>> + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank
>>> + * interval and the same contents will be displayed twice. This can be
>>> + * observed as stuttering for content with motion.
>>> + *
>>> + * If variable refresh rate was active on a display that supported a
>>> + * variable refresh range from 35Hz to 60Hz no stuttering would be 
>>> observable
>>> + * for the example scenario. The minimum supported variable refresh rate of
>>> + * 35Hz is below the page flip frequency and the vertical front porch can
>>> + * be extended until the page flip occurs. The vblank interval will be
>>> + * directly aligned to the page flip rate.
>>> + *
>>> + * Not all userspace content is suitable for use with variable refresh 
>>> rate.
>>> + * Large and frequent changes in vertical front porch duration may worsen
>>> + * perceived stuttering for input sensitive applications.
>>> + *
>>> + * Panel brightness will also vary with vertical front porch duration. Some
>>> + * panels may have noticeable differences in brightness between the minimum
>>> + * vertical front porch duration and the maximum vertical front porch 
>>> duration.
>>> + * Large and frequent changes in vertical front porch duration may produce
>>> + * observable flickering for such panels.
>>> + *
>>> + * Userspace control for variable refresh rate is supported via properties
>>> + * on the &drm_connector and &drm_crtc objects.
>>> + *
>>> + * "vrr_capable":
>>> + * Optional &drm_connector boolean property that drivers should attach
>>> + * with drm_connect

Re: [PATCH v7 3/5] drm: Document variable refresh properties

[Wentland, Harry]

On 2018-11-12 12:05 p.m., Kazlauskas, Nicholas wrote:
> On 11/12/18 11:12 AM, Wentland, Harry wrote:
>> On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
>>> These include the drm_connector 'vrr_capable' and the drm_crtc
>>> 'vrr_enabled' properties.
>>>
>>> Signed-off-by: Nicholas Kazlauskas 
>>> Cc: Harry Wentland 
>>> Cc: Manasi Navare 
>>> Cc: Pekka Paalanen 
>>> Cc: Ville Syrjälä 
>>> Cc: Michel Dänzer 
>>
>> Looks good. Whole series is
>> Reviewed-by: Harry Wentland 
>>
>> How are we with the userspace patches? We should probably hold off pushing 
>> the kernel patches until the userspace work is all reviewed.
>>
>> Harry
> 
> Thanks for the review.
> 
> The xf86-video-amdgpu patches have been reviewed and the mesa patches 
> have been partially reviewed.
> 

Alex, Michel,

how do we merge changes like this that provide a kernel API that goes together 
with userspace changes?

I imagine we'd want to get the kernel changes in first, and then merge the 
xf86-video-amdgpu and mesa changes. Please correct me if I'm wrong. Any 
objections to getting this merged via the usual amd-stg?

Thanks,
Harry


> Nicholas Kazlauskas
> 
>>
>>> ---
>>>   Documentation/gpu/drm-kms.rst   |  7 
>>>   drivers/gpu/drm/drm_connector.c | 68 +
>>>   2 files changed, 75 insertions(+)
>>>
>>> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
>>> index 4b1501b4835b..8da2a178cf85 100644
>>> --- a/Documentation/gpu/drm-kms.rst
>>> +++ b/Documentation/gpu/drm-kms.rst
>>> @@ -575,6 +575,13 @@ Explicit Fencing Properties
>>>   .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
>>>  :doc: explicit fencing properties
>>>   
>>> +
>>> +Variable Refresh Properties
>>> +---
>>> +
>>> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
>>> +   :doc: Variable refresh properties
>>> +
>>>   Existing KMS Properties
>>>   ---
>>>   
>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>> b/drivers/gpu/drm/drm_connector.c
>>> index 49290060ab7b..0e4287461997 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct 
>>> drm_device *dev)
>>>   }
>>>   EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>>>   
>>> +/**
>>> + * DOC: Variable refresh properties
>>> + *
>>> + * Variable refresh rate capable displays can dynamically adjust their
>>> + * refresh rate by extending the duration of their vertical front porch
>>> + * until page flip or timeout occurs. This can reduce or remove stuttering
>>> + * and latency in scenarios where the page flip does not align with the
>>> + * vblank interval.
>>> + *
>>> + * An example scenario would be an application flipping at a constant rate
>>> + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank
>>> + * interval and the same contents will be displayed twice. This can be
>>> + * observed as stuttering for content with motion.
>>> + *
>>> + * If variable refresh rate was active on a display that supported a
>>> + * variable refresh range from 35Hz to 60Hz no stuttering would be 
>>> observable
>>> + * for the example scenario. The minimum supported variable refresh rate of
>>> + * 35Hz is below the page flip frequency and the vertical front porch can
>>> + * be extended until the page flip occurs. The vblank interval will be
>>> + * directly aligned to the page flip rate.
>>> + *
>>> + * Not all userspace content is suitable for use with variable refresh 
>>> rate.
>>> + * Large and frequent changes in vertical front porch duration may worsen
>>> + * perceived stuttering for input sensitive applications.
>>> + *
>>> + * Panel brightness will also vary with vertical front porch duration. Some
>>> + * panels may have noticeable differences in brightness between the minimum
>>> + * vertical front porch duration and the maximum vertical front porch 
>>> duration.
>>> + * Large and frequent changes in vertical front porch duration may produce
>>> + * observable flickering for such panels.
>>> + *
>>> + * Userspace control for variable refresh rate is supported via properties

Re: [PATCH v7 3/5] drm: Document variable refresh properties

[Wentland, Harry]

On 2018-11-08 9:43 a.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
> 
> Signed-off-by: Nicholas Kazlauskas 
> Cc: Harry Wentland 
> Cc: Manasi Navare 
> Cc: Pekka Paalanen 
> Cc: Ville Syrjälä 
> Cc: Michel Dänzer 

Looks good. Whole series is
Reviewed-by: Harry Wentland 

How are we with the userspace patches? We should probably hold off pushing the 
kernel patches until the userspace work is all reviewed.

Harry

> ---
>  Documentation/gpu/drm-kms.rst   |  7 
>  drivers/gpu/drm/drm_connector.c | 68 +
>  2 files changed, 75 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 4b1501b4835b..8da2a178cf85 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -575,6 +575,13 @@ Explicit Fencing Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
> :doc: explicit fencing properties
>  
> +
> +Variable Refresh Properties
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> +   :doc: Variable refresh properties
> +
>  Existing KMS Properties
>  ---
>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 49290060ab7b..0e4287461997 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1255,6 +1255,74 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
> +/**
> + * DOC: Variable refresh properties
> + *
> + * Variable refresh rate capable displays can dynamically adjust their
> + * refresh rate by extending the duration of their vertical front porch
> + * until page flip or timeout occurs. This can reduce or remove stuttering
> + * and latency in scenarios where the page flip does not align with the
> + * vblank interval.
> + *
> + * An example scenario would be an application flipping at a constant rate
> + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank
> + * interval and the same contents will be displayed twice. This can be
> + * observed as stuttering for content with motion.
> + *
> + * If variable refresh rate was active on a display that supported a
> + * variable refresh range from 35Hz to 60Hz no stuttering would be observable
> + * for the example scenario. The minimum supported variable refresh rate of
> + * 35Hz is below the page flip frequency and the vertical front porch can
> + * be extended until the page flip occurs. The vblank interval will be
> + * directly aligned to the page flip rate.
> + *
> + * Not all userspace content is suitable for use with variable refresh rate.
> + * Large and frequent changes in vertical front porch duration may worsen
> + * perceived stuttering for input sensitive applications.
> + *
> + * Panel brightness will also vary with vertical front porch duration. Some
> + * panels may have noticeable differences in brightness between the minimum
> + * vertical front porch duration and the maximum vertical front porch 
> duration.
> + * Large and frequent changes in vertical front porch duration may produce
> + * observable flickering for such panels.
> + *
> + * Userspace control for variable refresh rate is supported via properties
> + * on the &drm_connector and &drm_crtc objects.
> + *
> + * "vrr_capable":
> + *   Optional &drm_connector boolean property that drivers should attach
> + *   with drm_connector_attach_vrr_capable_property() on connectors that
> + *   could support variable refresh rates. Drivers should update the
> + *   property value by calling drm_connector_set_vrr_capable_property().
> + *
> + *   Absence of the property should indicate absence of support.
> + *
> + * "vrr_enabled":
> + *   Default &drm_crtc boolean property that notifies the driver that the
> + *   content on the CRTC is suitable for variable refresh rate presentation.
> + *   The driver will take this property as a hint to enable variable
> + *   refresh rate support if the receiver supports it, ie. if the
> + *   "vrr_capable" property is true on the &drm_connector object. The
> + *   vertical front porch duration will be extended until page-flip or
> + *   timeout when enabled.
> + *
> + *   The minimum vertical front porch duration is defined as the vertical
> + *   front porch duration for the current mode.
> + *
> + *   The maximum vertical front porch duration is greater than or equal to
> + *   the minimum vertical front porch duration. The duration is derived
> + *   from the minimum supported variable refresh rate for the connector.
> + *
> + *   The driver may place further restrictions within these minimum
> + *   and maximum bounds.
> + *
> + *   The semantics for the vertical blank timestamp differ when
> + *   variable refresh rate is active. The vertical blank timestamp
> + *   is defined to be an estimate using the curren

Re: [PATCH 2/2] drm/atomic: Create and use __drm_atomic_helper_crtc_reset() everywhere

[Wentland, Harry]

On 2018-11-12 10:01 a.m., Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
> 
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> convert it to the common one.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: David Airlie 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Cc: Boris Brezillon 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Philipp Zabel 
> Cc: CK Hu 
> Cc: Matthias Brugger 
> Cc: Rob Clark 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 
> Cc: Sandy Huang 
> Cc: "Heiko Stübner" 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Eric Anholt 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Tony Cheng 
> Cc: Shirish S 
> Cc: Mikita Lipski 
> Cc: Bhawanpreet Lakha 
> Cc: David Francis 
> Cc: Anthony Koo 
> Cc: Jeykumar Sankaran 
> Cc: Jordan Crouse 
> Cc: Bruce Wang 
> Cc: Sravanthi Kollukuduru 
> Cc: Archit Taneja 
> Cc: Steve Kowalik 
> Cc: Carsten Behling 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Mahesh Kumar 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org

For amdgpu_dm and core changes
Reviewed-by: Harry Wentland 

Harry

> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  4 +--
>  drivers/gpu/drm/arm/malidp_crtc.c |  5 +--
>  .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c|  5 +--
>  drivers/gpu/drm/drm_atomic_state_helper.c | 31 ---
>  drivers/gpu/drm/i915/intel_display.c  |  2 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c  |  5 +--
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |  5 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 12 ++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  6 +---
>  drivers/gpu/drm/nouveau/dispnv50/head.c   | 13 ++--
>  drivers/gpu/drm/omapdrm/omap_crtc.c   |  7 ++---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  4 +--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  7 +++--
>  drivers/gpu/drm/tegra/dc.c|  5 +--
>  drivers/gpu/drm/vc4/vc4_crtc.c|  8 ++---
>  drivers/gpu/drm/vkms/vkms_crtc.c  |  7 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  9 +-
>  include/drm/drm_atomic_state_helper.h |  2 ++
>  18 files changed, 56 insertions(+), 81 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 5064768642f3..770a71726cd1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2802,9 +2802,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
>   if (WARN_ON(!state))
>   return;
>  
> - crtc->state = &state->base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, &state->base);
>  }
>  
>  static struct drm_crtc_state *
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index e1b72782848c..9a924ff27148 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -474,10 +474,7 @@ static void malidp_crtc_reset(struct drm_crtc *crtc)
>  
>   kfree(state);
>   state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = &state->base;
> - crtc->state->crtc = crtc;
> - }
> + __drm_atomic_helper_crtc_reset(crtc, &state->base);
>  }
>  
>  static void malidp_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 96f4082671fe..8084d549c7d1 1006

Re: [PATCH v6 4/5] drm/amdgpu: Correct get_crtc_scanoutpos behavior when vpos >= vtotal

[Wentland, Harry]

On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> When variable refresh rate is active the hardware counter can return
> a position >= vtotal. This results in a vpos being returned from
> amdgpu_display_get_crtc_scanoutpos that's a positive value. The
> positive value indicates to the caller that the display is
> currently in scanout when the display is actually still in vblank.
> 
> This is because the vfront porch duration is unknown with variable
> refresh active and will end when either a page flip occurs or the
> timeout specified by the driver/display is reached.
> 
> The behavior of the amdgpu_display_get_crtc_scanoutpos remains the
> same when the position is below vtotal. When the position is above
> vtotal the function will return a value that is effectively -vbl_end,
> the size of the vback porch.
> 
> The only caller affected by this change is the DRM helper for
> calculating vblank timestamps. This change corrects behavior for
> calculating the page flip timestap from being the previous timestamp
> to the calculation to the next timestamp when position >= vtotal.
> 
> Signed-off-by: Nicholas Kazlauskas 

Reviewed-by: Harry Wentland 

Harry

> Cc: Michel Dänzer 
> Cc: Harry Wentland 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 6748cd7fc129..cb331319f225 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -850,7 +850,12 @@ int amdgpu_display_get_crtc_scanoutpos(struct drm_device 
> *dev,
>   /* Inside "upper part" of vblank area? Apply corrective offset if so: */
>   if (in_vbl && (*vpos >= vbl_start)) {
>   vtotal = mode->crtc_vtotal;
> - *vpos = *vpos - vtotal;
> +
> + /* With variable refresh rate displays the vpos can exceed
> +  * the vtotal value. Clamp to 0 to return -vbl_end instead
> +  * of guessing the remaining number of lines until scanout.
> +  */
> + *vpos = (*vpos < vtotal) ? (*vpos - vtotal) : 0;
>   }
>  
>   /* Correct for shifted end of vbl at vbl_end. */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 3/5] drm: Document variable refresh properties

[Wentland, Harry]

On 2018-11-06 3:24 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
> 
> Signed-off-by: Nicholas Kazlauskas 
> Cc: Harry Wentland 
> Cc: Manasi Navare 
> Cc: Pekka Paalanen 
> Cc: Ville Syrjälä 
> Cc: Michel Dänzer 
> ---
>  Documentation/gpu/drm-kms.rst   |  7 
>  drivers/gpu/drm/drm_connector.c | 61 +
>  2 files changed, 68 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 4b1501b4835b..8da2a178cf85 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -575,6 +575,13 @@ Explicit Fencing Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
> :doc: explicit fencing properties
>  
> +
> +Variable Refresh Properties
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> +   :doc: Variable refresh properties
> +
>  Existing KMS Properties
>  ---
>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 49290060ab7b..a6adf5450db3 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1255,6 +1255,67 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
> +/**
> + * DOC: Variable refresh properties
> + *
> + * Variable refresh rate capable displays can dynamically adjust their
> + * refresh rate by extending the duration of their vertical porch until

vertical porch -> vertical front porch

> + * page flip or timeout occurs. This can reduce or remove stuttering
> + * and latency in scenarios where the page flip does not align with the
> + * vblank interval.
> + *
> + * An example scenario would be an application flipping at a constant rate
> + * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank
> + * interval and the same contents will be displayed twice. This can be
> + * observed as stuttering for content with motion.
> + *
> + * If variable refresh rate was active on a display that supported a
> + * variable refresh range from 35Hz to 60Hz no stuttering would be observable
> + * for the example scenario. The minimum supported variable refresh rate of
> + * 35Hz is below the page flip frequency and the vertical front porch can
> + * be extended until the page flip occurs. The vblank interval will be
> + * directly aligned to the page flip rate.
> + *
> + * Userspace control for variable refresh rate is supported via properties
> + * on the &drm_connector and &drm_crtc objects.
> + *
> + * "vrr_capable":
> + *   Optional &drm_connector boolean property that drivers should attach
> + *   with drm_connector_attach_vrr_capable_property() on connectors that
> + *   could support variable refresh rates. Drivers should update the
> + *   property value by calling drm_connector_set_vrr_capable_property().
> + *
> + *   Absence of the property should indicate absence of support.
> + *
> + * "vrr_enabled":
> + *   Default &drm_crtc boolean property that notifies the driver that the
> + *   content on the CRTC is suitable for variable refresh rate presentation.
> + *   The driver will take this property as a hint to enable variable
> + *   refresh rate support if the receiver supports it, ie. if the
> + *   "vrr_capable" property is true on the &drm_connector object. The
> + *   veritcal front porch duration will be extended until page-flip or

veritcal -> vertical

> + *   timeout when enabled.
> + *
> + *   The minimum vertical front porch duration is defined as the vertical
> + *   front porch duration for the current mode.
> + *
> + *   The maximum vertical front porch duration is greater than or equal to
> + *   the minimum vertical front porch duration. The duration is derived
> + *   from the minimum supported variable refresh rate for the connector.
> + *
> + *   The driver may place further restrictions within these minimum
> + *   and maximum bounds.
> + *
> + *   Some displays may exhibit noticeable differences in brightness when
> + *   varying vertical front porch duration.
> + *

Maybe something like this makes sense here:

 *  Some displays may exhibit noticeable differences in brightness when
 *  varying vertical front porch duration drastically. It is therefore
 *  advised userspace only provide the "vrr_enabled" hint for content
 *  with a render rate that is expected to change gradually frame to frame,
 *  such as games.

> + *   The semantics for the vertical blank timestamp differ when
> + *   variable refresh rate is active. The vertical blank timestamp
> + *   is defined to be an estimate using the current mode's fixed
> + *   refresh rate timings. The semantics for the page-flip event
> + *   timestamp remain the same.
> + */
> +
>  /**
>   * drm_connector_attach_vrr_capable_property - creates the
>   * vrr_capable property
> 
_

Re: [PATCH] drm/amd/amdgpu/dm: Fix dm_dp_create_fake_mst_encoder()

[Wentland, Harry]

On 2018-11-01 9:51 p.m., Lyude Paul wrote:
> [why]
> Removing connector reusage from DM to match the rest of the tree ended
> up revealing an issue that was surprisingly subtle. The original amdgpu
> code for DC that was submitted appears to have left a chunk in
> dm_dp_create_fake_mst_encoder() that tries to find a "master encoder",
> the likes of which isn't actually used or stored anywhere. It does so at
> the wrong time as well by trying to access parts of the drm_connector
> from the encoder init before it's actually been initialized. This
> results in a NULL pointer deref on MST hotplugs:
> 
> [  160.696613] BUG: unable to handle kernel NULL pointer dereference at 
> 
> [  160.697234] PGD 0 P4D 0
> [  160.697814] Oops: 0010 [#1] SMP PTI
> [  160.698430] CPU: 2 PID: 64 Comm: kworker/2:1 Kdump: loaded Tainted: G  
>  O  4.19.0Lyude-Test+ #2
> [  160.699020] Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.22 
> 05/17/2018
> [  160.699672] Workqueue: events_long drm_dp_mst_link_probe_work 
> [drm_kms_helper]
> [  160.700322] RIP: 0010:  (null)
> [  160.700920] Code: Bad RIP value.
> [  160.701541] RSP: 0018:c929fc78 EFLAGS: 00010206
> [  160.702183] RAX:  RBX: 8804440ed468 RCX: 
> 8804440e9158
> [  160.702778] RDX:  RSI: 8804556c5700 RDI: 
> 8804440ed000
> [  160.703408] RBP: 880458e21800 R08: 0002 R09: 
> 5fca0a25
> [  160.704002] R10: 88045a077a3d R11: 88045a077a3c R12: 
> 8804440ed000
> [  160.704614] R13: 880458e21800 R14: 8804440e9000 R15: 
> 8804440e9000
> [  160.705260] FS:  () GS:88045f28() 
> knlGS:
> [  160.705854] CS:  0010 DS:  ES:  CR0: 80050033
> [  160.706478] CR2: ffd6 CR3: 0200a001 CR4: 
> 003606e0
> [  160.707124] DR0:  DR1:  DR2: 
> 
> [  160.707724] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  160.708372] Call Trace:
> [  160.708998]  ? dm_dp_add_mst_connector+0xed/0x1d0 [amdgpu]
> [  160.709625]  ? drm_dp_add_port+0x2fa/0x470 [drm_kms_helper]
> [  160.710284]  ? wake_up_q+0x54/0x70
> [  160.710877]  ? __mutex_unlock_slowpath.isra.18+0xb3/0x110
> [  160.711512]  ? drm_dp_dpcd_access+0xe7/0x110 [drm_kms_helper]
> [  160.712161]  ? drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
> [  160.712762]  ? drm_dp_check_and_send_link_address+0xa3/0xd0 
> [drm_kms_helper]
> [  160.713408]  ? drm_dp_mst_link_probe_work+0x4b/0x80 [drm_kms_helper]
> [  160.714013]  ? process_one_work+0x1a1/0x3a0
> [  160.714667]  ? worker_thread+0x30/0x380
> [  160.715326]  ? wq_update_unbound_numa+0x10/0x10
> [  160.715939]  ? kthread+0x112/0x130
> [  160.716591]  ? kthread_create_worker_on_cpu+0x70/0x70
> [  160.717262]  ? ret_from_fork+0x35/0x40
> [  160.717886] Modules linked in: amdgpu(O) vfat fat snd_hda_codec_generic 
> joydev i915 chash gpu_sched ttm i2c_algo_bit drm_kms_helper 
> snd_hda_codec_hdmi hp_wmi syscopyarea iTCO_wdt sysfillrect sparse_keymap 
> sysimgblt fb_sys_fops snd_hda_intel usbhid wmi_bmof drm snd_hda_codec btusb 
> snd_hda_core intel_rapl btrtl x86_pkg_temp_thermal btbcm btintel coretemp 
> snd_pcm crc32_pclmul bluetooth psmouse snd_timer snd pcspkr i2c_i801 mei_me 
> i2c_core soundcore mei tpm_tis wmi tpm_tis_core hp_accel ecdh_generic 
> lis3lv02d tpm video rfkill acpi_pad input_polldev hp_wireless pcc_cpufreq 
> crc32c_intel serio_raw tg3 xhci_pci xhci_hcd [last unloaded: amdgpu]
> [  160.720141] CR2: 
> 
> Somehow the connector reusage DM was using for MST connectors managed to
> paper over this issue entirely; hence why this was never caught until
> now.
> 
> [how]
> Since this code isn't used anywhere and seems useless anyway, we can
> just drop it entirely. This appears to fix the issue on my HP ZBook with
> an AMD WX4150.
> 
> Signed-off-by: Lyude Paul 

Good catch. Probably got broken with some of the best_encoder cleanup that 
happened in the last few months. I really should've caught it then.

Reviewed-by: Harry Wentland 

Harry

> ---
> Hey! This is the patch that I was talking about, feel free to review
> it-we should make sure this goes in with the rest of the patches you've
> got so far.
> 
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 -
>  1 file changed, 5 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 6aa7359d61a3..5432a1862b41 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_

Re: [PATCH 1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()

[Wentland, Harry]

On 2018-11-05 9:04 a.m., Ville Syrjälä wrote:
> On Mon, Nov 05, 2018 at 10:26:01AM +0100, Daniel Vetter wrote:
>> On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
>>> From: Ville Syrjälä 
>>>
>>> Replace 'crtc->state' with the explicit old crtc state.
>>>
>>> Actually it shouldn't matter whether we use the old or the new
>>> crtc state here since any plane that has been removed from the
>>> crtc since the crtc state was duplicated will have been added
>>> to the atomic state already. That is, you can't call
>>> drm_atomic_set_crtc_for_plane() without having the new
>>> plane state already in hand.
>>>
>>> Signed-off-by: Ville Syrjälä 
>>
>> I think this will break amdgpu_notify_freesync because that doesn't grab
>> the crtc state first. Which worked with the old stuff, because adding a
>> connector or plane will also add it's crtc. But with the new logic we'll
>> just oops I think.
> 
> drm_atomic_add_affected_connectors() will add the crtc to the
> state. So looks like it shouldn't oops.
> 

Thanks. I thought I was too tired on a Monday morning to spot the oops.

This code should be on the way out with the variable refresh patches from Nick. 
It's currently only used by our DKMS driver.

Looks good to me.

Acked-by: Harry Wentland 

Harry

>>
>> Otoh, it's dead code, so what exactly are amd people doing again :-)
> 
> Heh. Thanks for the review.
> 
>>
>> Adding Harry so he's aware, but patch here looks good.
>>
>> Reviewed-by: Daniel Vetter 
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index 3dbfbddae7e6..064c48075917 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -927,6 +927,8 @@ int
>>>  drm_atomic_add_affected_planes(struct drm_atomic_state *state,
>>>struct drm_crtc *crtc)
>>>  {
>>> +   const struct drm_crtc_state *old_crtc_state =
>>> +   drm_atomic_get_old_crtc_state(state, crtc);
>>> struct drm_plane *plane;
>>>  
>>> WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
>>> @@ -934,7 +936,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
>>> *state,
>>> DRM_DEBUG_ATOMIC("Adding all current planes for [CRTC:%d:%s] to %p\n",
>>>  crtc->base.id, crtc->name, state);
>>>  
>>> -   drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
>>> +   drm_for_each_plane_mask(plane, state->dev, old_crtc_state->plane_mask) {
>>> struct drm_plane_state *plane_state =
>>> drm_atomic_get_plane_state(state, plane);
>>>  
>>> -- 
>>> 2.18.1
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2] MAINTAINERS: Add entry for VKMS

[Wentland, Harry]

On 2018-10-21 9:27 p.m., Rodrigo Siqueira wrote:
> Add maintainers and reviewers for VKMS driver
> 
> Signed-off-by: Rodrigo Siqueira 

Acked-by: Harry Wentland 

Harry

> ---
> Changes in v2:
>   - Insert the section in alphabetical order
> 
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 39c3f6682ace..56572f0968ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4733,6 +4733,16 @@ S: Odd Fixes
>  F:   drivers/gpu/drm/udl/
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
>  
> +DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS)
> +M:   Rodrigo Siqueira 
> +R:   Haneen Mohammed 
> +R:   Daniel Vetter 
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +S:   Maintained
> +L:   dri-devel@lists.freedesktop.org
> +F:   drivers/gpu/drm/vkms/
> +F:   Documentation/gpu/vkms.rst
> +
>  DRM DRIVER FOR VMWARE VIRTUAL GPU
>  M:   "VMware Graphics" 
>  M:   Sinclair Yeh 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Allow fd.o to join forces with X.Org

[Wentland, Harry]

On 2018-10-26 7:22 a.m., Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone  wrote:
>>
>> Hi,
>>
>> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter  wrote:
>>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
 On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone  wrote:
>> Yeah, I think it makes sense. Some things we do:
>>   - provide hosted network services for collaborative development,
>> testing, and discussion, of open-source projects
>>   - administer, improve, and extend this suite of services as necessary
>>   - assist open-source projects in their use of these services
>>   - purchase, lease, or subscribe to, computing and networking
>> infrastructure allowing these services to be run
>
> I fully agree that we should document all this. I don't think the
> bylaws are the right place though, much better to put that into
> policies that the board approves and which can be adapted as needed.
> Imo bylaws should cover the high-level mission and procedural details,
> as our "constitution", with the really high acceptance criteria of
> 2/3rd of all members approving any changes. Some of the early
> discussions tried to spell out a lot of the fd.o policies in bylaw
> changes, but then we realized it's all there already. All the details
> are much better served in policies enacted by the board, like we do
> with everything else.
>
> As an example, let's look at XDC. Definitely one of the biggest things
> the foundation does, with handling finances, travel sponsoring grants,
> papers committee, and acquiring lots of sponsors. None of this is
> spelled out in the bylaws, it's all in policies that the board
> deliberates and approves. I think this same approach will also work
> well for fd.o.
>
> And if members are unhappy with what the board does, they can fix in
> the next election by throwing out the unwanted directors.

 yeah, fair call. though IMO in that case we can just reduce to

\item Support free and open source projects through the freedesktop.org
infrastructure.

 because my gripe is less with the fdo bit but more with defining what
 "project hosting" means, given that we use that term to exclude fdo 
 projects
 from getting anything else. I think just dropping that bit is sufficient.
>>>
>>> Hm yeah, through the lens of "everything not explicitly listed isn't in
>>> scope as X.org's purpose", leaving this out is probably clearest. And
>>> under 2.4 (i) the board already has the duty to interpret what exactly
>>> this means wrt membership eligibility.
>>>
>>> Harry, Daniel, what do you think?
>>
>> Yeah, that's fine. I didn't specifically want the enumerated list of
>> what we do in the bylaws, just spelling it out for background as a
>> handy reference I could point to later. I think maybe we could reduce
>> it to something like:
>>   Administer, support, and improve the freedesktop.org hosting
>> infrastructure to support the projects it hosts
> 
> This feels a bit self-referential, not the best for the purpose of
> what X.org does. If we do want to be a bit more specific we could do
> something like with (i) and provide a list that the board can extend:
> 
> \item Support free and open source projects through the freedesktop.org
> infrastructure. This includes, but is not limited to:
> Administering and providing
> project hosting services.
> 

I like this phrasing, but won't that bring us back to David Hutterer's point 
about defining what "project hosting services" means?

Personally I think "project hosting" is quite clear and shouldn't need to be 
defined.

Harry

> That would make it clear that admins&servers are in scope, and
> everything else is up to the board. Similar to how drm, mesa, wayland
> and X are explicitly in scope, and stuff like cros/android gfx stack
> or libinput is up to the board to decide/clarify.
> 
>> Gives us enough scope to grow in the future (e.g. we don't need a
>> bylaws change to move from pure-git to GitLab), avoids the sticky
>> question of what exactly fd.o hosts in the bylaws (e.g. if
>> NetworkManager needs a new repo then we don't have to consult
>> membership to add it), but is still pretty firmly limited in scope.
>>
>> Any of the above have my in-principle ack though, I think they're all
>> reasonable colours for our lovely shed.
> 
> Well, one more bikeshed from me!
> 
> Cheers, Daniel
> 
>>
>> Cheers,
>> Daniel
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/4] drm/amdgpu: Set FreeSync state using drm VRR properties

[Wentland, Harry]

On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Support for AMDGPU specific FreeSync properties and ioctls are dropped
> from amdgpu_dm in favor of supporting drm variable refresh rate
> properties.
> 
> The notify_freesync and set_freesync_property functions are dropped
> from amdgpu_display_funcs.
> 
> The drm vrr_capable property is now attached to any DP/HDMI connector.
> Its value is updated accordingly to the connector's FreeSync capabiltiy.
> 
> The freesync_enable logic and ioctl control has has been dropped in
> favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
> fine grained atomic control over which CRTCs should support variable
> refresh rate.
> 
> To handle state changes for vrr_enabled it was easiest to drop the
> forced modeset on freesync_enabled change. This patch now performs the
> required stream updates when planes are flipped.
> 
> This is done for a few reasons:
> 
> (1) VRR stream updates can be done in the fast update path
> 
> (2) amdgpu_dm_atomic_check would need to be hacked apart to check
> desired variable refresh state and capability before the CRTC
> disable pass.
> 
> (3) Performing VRR stream updates on-flip is needed for enabling BTR
> support.
> 
> VRR packets and timing adjustments are now tracked and compared to
> previous values sent to the hardware.
> 
> Signed-off-by: Nicholas Kazlauskas 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   7 -
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +-
>  3 files changed, 138 insertions(+), 131 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index b9e9e8b02fb7..0cbe867ec375 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -295,13 +295,6 @@ struct amdgpu_display_funcs {
> uint16_t connector_object_id,
> struct amdgpu_hpd *hpd,
> struct amdgpu_router *router);
> - /* it is used to enter or exit into free sync mode */
> - int (*notify_freesync)(struct drm_device *dev, void *data,
> -struct drm_file *filp);
> - /* it is used to allow enablement of freesync mode */
> - int (*set_freesync_property)(struct drm_connector *connector,
> -  struct drm_property *property,
> -  uint64_t val);
>  
>  
>  };
> 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 e224f23e2215..f6af388cc32d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device 
> *adev)
>   /* TODO: implement later */
>  }
>  
> -static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
> - struct drm_file *filp)
> -{
> - struct drm_atomic_state *state;
> - struct drm_modeset_acquire_ctx ctx;
> - struct drm_crtc *crtc;
> - struct drm_connector *connector;
> - struct drm_connector_state *old_con_state, *new_con_state;
> - int ret = 0;
> - uint8_t i;
> - bool enable = false;
> -
> - drm_modeset_acquire_init(&ctx, 0);
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state) {
> - ret = -ENOMEM;
> - goto out;
> - }
> - state->acquire_ctx = &ctx;
> -
> -retry:
> - drm_for_each_crtc(crtc, dev) {
> - ret = drm_atomic_add_affected_connectors(state, crtc);
> - if (ret)
> - goto fail;
> -
> - /* TODO rework amdgpu_dm_commit_planes so we don't need this */
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - goto fail;
> - }
> -
> - for_each_oldnew_connector_in_state(state, connector, old_con_state, 
> new_con_state, i) {
> - struct dm_connector_state *dm_new_con_state = 
> to_dm_connector_state(new_con_state);
> - struct drm_crtc_state *new_crtc_state;
> - struct amdgpu_crtc *acrtc = 
> to_amdgpu_crtc(dm_new_con_state->base.crtc);
> - struct dm_crtc_state *dm_new_crtc_state;
> -
> - if (!acrtc) {
> - ASSERT(0);
> - continue;
> - }
&

Re: [PATCH v5 3/4] drm: Document variable refresh properties

[Wentland, Harry]

On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
> 
> Signed-off-by: Nicholas Kazlauskas 
> ---
>  Documentation/gpu/drm-kms.rst   |  7 +++
>  drivers/gpu/drm/drm_connector.c | 22 ++
>  2 files changed, 29 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 4b1501b4835b..8da2a178cf85 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -575,6 +575,13 @@ Explicit Fencing Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
> :doc: explicit fencing properties
>  
> +
> +Variable Refresh Properties
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> +   :doc: Variable refresh properties
> +
>  Existing KMS Properties
>  ---
>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f0deeb7298d0..2a12853ca917 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
> +/**
> + * DOC: Variable refresh properties
> + *
> + * Variable refresh rate control is supported via properties on the
> + * &drm_connector and &drm_crtc objects.
> + *
> + * "vrr_capable":
> + *   Optional &drm_connector boolean property that drivers should attach
> + *   with drm_connector_attach_vrr_capable_property() on connectors that
> + *   could support variable refresh rates. Drivers should update the
> + *   property value by calling drm_connector_set_vrr_capable_property().
> + *
> + *   Absence of the property should indicate absence of support.
> + *
> + * "vrr_enabled":
> + *   Default &drm_crtc boolean property that notifies the driver that the
> + *   variable refresh rate adjustment should be enabled for the CRTC.
> + *
> + *   Support for variable refresh rate will depend on the "vrr_capable"
> + *   property exposed on the &drm_connector object.

We probably want to make it clear that this is a content hint. Maybe something 
like:

 * "vrr_enabled":
 *  Default &drm_crtc boolean property that notifies the driver that the
 *  content on the CRTC is suitable for variable refresh presentation.
 *  The driver will take that as a hint to enable variable refresh rate
 *  if the receiver supports it, i.e. the "vrr_capable" property on the
 *  &drm_connector_object is true.


Harry

> + */
> +
>  /**
>   * drm_connector_attach_vrr_capable_property - creates the
>   * vrr_capable property
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC

[Wentland, Harry]

On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> This patch introduces the 'vrr_enabled' CRTC property to allow
> dynamic control over variable refresh rate support for a CRTC.
> 
> This property should be treated like a content hint to the driver -
> if the hardware or driver is not capable of driving variable refresh
> timings then this is not considered an error.
> 
> Capability for variable refresh rate support should be determined
> by querying the vrr_capable drm connector property.
> 
> It is worth noting that while the property is intended for atomic use
> it isn't filtered from legacy userspace queries. This allows for Xorg
> userspace drivers to implement support.
> 
> Signed-off-by: Nicholas Kazlauskas 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 4 
>  drivers/gpu/drm/drm_crtc.c| 2 ++
>  drivers/gpu/drm/drm_mode_config.c | 6 ++
>  include/drm/drm_crtc.h| 9 +
>  include/drm/drm_mode_config.h | 5 +
>  5 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..eec396a57b88 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -433,6 +433,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
> *crtc,
>   ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
>   drm_property_blob_put(mode);
>   return ret;
> + } else if (property == config->prop_vrr_enabled) {
> + state->vrr_enabled = val;
>   } else if (property == config->degamma_lut_property) {
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   &state->degamma_lut,
> @@ -491,6 +493,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>   *val = state->active;
>   else if (property == config->prop_mode_id)
>   *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> + else if (property == config->prop_vrr_enabled)
> + *val = state->vrr_enabled;
>   else if (property == config->degamma_lut_property)
>   *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
>   else if (property == config->ctm_property)
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5f488aa80bcd..e4eb2c897ff4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   drm_object_attach_property(&crtc->base, config->prop_mode_id, 
> 0);
>   drm_object_attach_property(&crtc->base,
>  config->prop_out_fence_ptr, 0);
> + drm_object_attach_property(&crtc->base,
> +config->prop_vrr_enabled, 0);
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..5670c67f28d4 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.prop_mode_id = prop;
>  
> + prop = drm_property_create_bool(dev, 0,
> + "VRR_ENABLED");
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_vrr_enabled = prop;
> +
>   prop = drm_property_create(dev,
>   DRM_MODE_PROP_BLOB,
>   "DEGAMMA_LUT", 0);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..39c3900aab3c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -290,6 +290,15 @@ struct drm_crtc_state {
>*/
>   u32 pageflip_flags;
>  
> + /**
> +  * @vrr_enabled:
> +  *
> +  * Indicates if variable refresh rate should be enabled for the CRTC.
> +  * Support for the requested vrr state will depend on driver and
> +  * hardware capabiltiy - lacking support is not treated as failure.
> +  */
> + bool vrr_enabled;
> +
>   /**
>* @event:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 928e4172a0bb..49f2fcfdb5fc 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -639,6 +639,11 @@ struct drm

Re: [PATCH v5 1/4] drm: Add vrr_capable property to the drm connector

[Wentland, Harry]

On 2018-10-12 12:44 p.m., Nicholas Kazlauskas wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces the "vrr_capable" property on the connector to
> allow userspace to query support for variable refresh rates.
> 
> Atomic drivers should attach this property to connectors that are
> capable of driving variable refresh rates using
> drm_connector_attach_vrr_capable_property().
> 
> The value should be updated based on driver and hardware capabiltiy
> by using drm_connector_set_vrr_capable_property().
> 
> Signed-off-by: Nicholas Kazlauskas 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_connector.c | 49 +
>  include/drm/drm_connector.h | 15 ++
>  2 files changed, 64 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..f0deeb7298d0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1254,6 +1254,37 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
> +/**
> + * drm_connector_attach_vrr_capable_property - creates the
> + * vrr_capable property
> + * @connector: connector to create the vrr_capable property on.
> + *
> + * This is used by atomic drivers to add support for querying
> + * variable refresh rate capability for a connector.
> + *
> + * Returns:
> + * Zero on success, negative errono on failure.
> + */
> +int drm_connector_attach_vrr_capable_property(
> + struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + if (!connector->vrr_capable_property) {
> + prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
> + "vrr_capable");
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->vrr_capable_property = prop;
> + drm_object_attach_property(&connector->base, prop, 0);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
> +
>  /**
>   * drm_connector_attach_scaling_mode_property - attach atomic scaling mode 
> property
>   * @connector: connector to attach scaling mode property on.
> @@ -1582,6 +1613,24 @@ void drm_connector_set_link_status_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_connector_set_link_status_property);
>  
> +/**
> + * drm_connector_set_vrr_capable_property - sets the variable refresh rate
> + * capable property for a connector
> + * @connector: drm connector
> + * @capable: True if the connector is variable refresh rate capable
> + *
> + * Should be used by atomic drivers to update the indicated support for
> + * variable refresh rate over a connector.
> + */
> +void drm_connector_set_vrr_capable_property(
> + struct drm_connector *connector, bool capable)
> +{
> + drm_object_property_set_value(&connector->base,
> +   connector->vrr_capable_property,
> +   capable);
> +}
> +EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> +
>  /**
>   * drm_connector_init_panel_orientation_property -
>   *   initialize the connecters panel_orientation property
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 91a877fa00cb..b2263005234a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -910,6 +910,17 @@ struct drm_connector {
>*/
>   struct drm_property *scaling_mode_property;
>  
> + /**
> +  * @vrr_capable_property: Optional property to help userspace
> +  * query hardware support for variable refresh rate on a connector.
> +  * connector. Drivers can add the property to a connector by
> +  * calling drm_connector_attach_vrr_capable_property().
> +  *
> +  * This should be updated only by calling
> +  * drm_connector_set_vrr_capable_property().
> +  */
> + struct drm_property *vrr_capable_property;
> +
>   /**
>* @content_protection_property: DRM ENUM property for content
>* protection. See drm_connector_attach_content_protection_property().
> @@ -1183,6 +1194,8 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev);
>  int drm_connector_attach_content_type_property(struct drm_connector *dev);
>  int drm_connector_attach_scaling_mode_property(struct drm_connector 
> *connector,
>  

Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support

[Wentland, Harry]

On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
 I'm curious to know whether this will/could work over PRIME
>>> I don't see why this shouldn't work over PRIME as long as the
>>> presenting GPU supports the new variable refresh rate API, but I know
>>> very little about prime, so maybe someone else can chime in and give
>>> a better opinion.
>> It won't work for displays connected to a secondary GPU, because those
>> aren't hooked up to the Present extension directly.
>>
>> It can theoretically work with render offloading, if the primary GPU can
>> scan out directly from the shared pixmap. This is only possible with
>> current AMD APUs which support scatter/gather scanout (Carrizo and
>> newer?).
> 
> Actually only Carizzo and Stoney at the moment because this is buggy on 
> Raven. Not sure if that is a pure software or a hardware problem.
> 
> Christian.
> 
>> One gotcha is that xf86-video-amdgpu currently doesn't allow
>> flipping between buffers with different tiling parameters (BTW Harry,
>> does that work with DC?), but that should be easy to fix.
> 

Not currently. Fixable, but unfortunately not as easy as I'd hope. The good 
news is that I'm planning to rework that code so it would be easy to fix or 
should just happen on a per-flip basis.

Harry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Get ref on CRTC commit object when waiting for flip_done

[Wentland, Harry]

On 2018-10-18 1:38 p.m., Wentland, Harry wrote:
> On 2018-10-16 11:48 a.m., Alex Deucher wrote:
>> On Tue, Oct 16, 2018 at 11:00 AM Li, Sun peng (Leo)  
>> wrote:
>>>
>>>
>>>
>>> On 2018-10-16 08:33 AM, Daniel Vetter wrote:
>>>> On Mon, Oct 15, 2018 at 09:46:40AM -0400, sunpeng...@amd.com wrote:
>>>>> From: Leo Li 
>>>>>
>>>>> This fixes a general protection fault, caused by accessing the contents
>>>>> of a flip_done completion object that has already been freed. It occurs
>>>>> due to the preemption of a non-blocking commit worker thread W by
>>>>> another commit thread X. X continues to clear its atomic state at the
>>>>> end, destroying the CRTC commit object that W still needs. Switching
>>>>> back to W and accessing the commit objects then leads to bad results.
>>>>>
>>>>> Worker W becomes preemptable when waiting for flip_done to complete. At
>>>>> this point, a frequently occurring commit thread X can take over. Here's
>>>>> an example where W is a worker thread that flips on both CRTCs, and X
>>>>> does a legacy cursor update on both CRTCs:
>>>>>
>>>>>  ...
>>>>>   1. W does flip work
>>>>>   2. W runs commit_hw_done()
>>>>>   3. W waits for flip_done on CRTC 1
>>>>>   4. > flip_done for CRTC 1 completes
>>>>>   5. W finishes waiting for CRTC 1
>>>>>   6. W waits for flip_done on CRTC 2
>>>>>
>>>>>   7. > Preempted by X
>>>>>   8. > flip_done for CRTC 2 completes
>>>>>   9. X atomic_check: hw_done and flip_done are complete on all CRTCs
>>>>>  10. X updates cursor on both CRTCs
>>>>>  11. X destroys atomic state
>>>>>  12. X done
>>>>>
>>>>>  13. > Switch back to W
>>>>>  14. W waits for flip_done on CRTC 2
>>>>>  15. W raises general protection fault
>>>>>
>>>>> The error looks like so:
>>>>>
>>>>>  general protection fault:  [#1] PREEMPT SMP PTI
>>>>>  **snip**
>>>>>  Call Trace:
>>>>>   lock_acquire+0xa2/0x1b0
>>>>>   _raw_spin_lock_irq+0x39/0x70
>>>>>   wait_for_completion_timeout+0x31/0x130
>>>>>   drm_atomic_helper_wait_for_flip_done+0x64/0x90 [drm_kms_helper]
>>>>>   amdgpu_dm_atomic_commit_tail+0xcae/0xdd0 [amdgpu]
>>>>>   commit_tail+0x3d/0x70 [drm_kms_helper]
>>>>>   process_one_work+0x212/0x650
>>>>>   worker_thread+0x49/0x420
>>>>>   kthread+0xfb/0x130
>>>>>   ret_from_fork+0x3a/0x50
>>>>>  Modules linked in: x86_pkg_temp_thermal amdgpu(O) chash(O)
>>>>>  gpu_sched(O) drm_kms_helper(O) syscopyarea sysfillrect sysimgblt
>>>>>  fb_sys_fops ttm(O) drm(O)
>>>>>
>>>>> Note that i915 has this issue masked, since hw_done is signaled after
>>>>> waiting for flip_done. Doing so will block the cursor update from
>>>>> happening until hw_done is signaled, preventing the cursor commit from
>>>>> destroying the state.
>>>>>
>>>>> v2: The reference on the commit object needs to be obtained before
>>>>>  hw_done() is signaled, since that's the point where another commit
>>>>>  is allowed to modify the state. Assuming that the
>>>>>  new_crtc_state->commit object still exists within flip_done() is
>>>>>  incorrect.
>>>>>
>>>>>  Fix by getting a reference in setup_commit(), and releasing it
>>>>>  during default_clear().
>>>>>
>>>>> Signed-off-by: Leo Li 
>>>>> ---
>>>>>
>>>>> Sending again, this time to the correct mailing list :)
>>>>>
>>>>> Leo
>>>>
>>>> Reviewed-by: Daniel Vetter 
>>>> Cc: sta...@vger.kernel.org
>>>>
>>>> I think it'd be really good if you could get intel-gfx-ci to test this
>>>> patch. Simply submit it to intel-...@lists.freedesktop.org. I'll leave
>>>> applying to one of the amd drm-misc committers, once it's passed CI.
>>
>> Leo, do you or Harry have drm-misc 

Re: [PATCH v2] drm: Get ref on CRTC commit object when waiting for flip_done

[Wentland, Harry]

On 2018-10-16 11:48 a.m., Alex Deucher wrote:
> On Tue, Oct 16, 2018 at 11:00 AM Li, Sun peng (Leo)  
> wrote:
>>
>>
>>
>> On 2018-10-16 08:33 AM, Daniel Vetter wrote:
>>> On Mon, Oct 15, 2018 at 09:46:40AM -0400, sunpeng...@amd.com wrote:
 From: Leo Li 

 This fixes a general protection fault, caused by accessing the contents
 of a flip_done completion object that has already been freed. It occurs
 due to the preemption of a non-blocking commit worker thread W by
 another commit thread X. X continues to clear its atomic state at the
 end, destroying the CRTC commit object that W still needs. Switching
 back to W and accessing the commit objects then leads to bad results.

 Worker W becomes preemptable when waiting for flip_done to complete. At
 this point, a frequently occurring commit thread X can take over. Here's
 an example where W is a worker thread that flips on both CRTCs, and X
 does a legacy cursor update on both CRTCs:

  ...
   1. W does flip work
   2. W runs commit_hw_done()
   3. W waits for flip_done on CRTC 1
   4. > flip_done for CRTC 1 completes
   5. W finishes waiting for CRTC 1
   6. W waits for flip_done on CRTC 2

   7. > Preempted by X
   8. > flip_done for CRTC 2 completes
   9. X atomic_check: hw_done and flip_done are complete on all CRTCs
  10. X updates cursor on both CRTCs
  11. X destroys atomic state
  12. X done

  13. > Switch back to W
  14. W waits for flip_done on CRTC 2
  15. W raises general protection fault

 The error looks like so:

  general protection fault:  [#1] PREEMPT SMP PTI
  **snip**
  Call Trace:
   lock_acquire+0xa2/0x1b0
   _raw_spin_lock_irq+0x39/0x70
   wait_for_completion_timeout+0x31/0x130
   drm_atomic_helper_wait_for_flip_done+0x64/0x90 [drm_kms_helper]
   amdgpu_dm_atomic_commit_tail+0xcae/0xdd0 [amdgpu]
   commit_tail+0x3d/0x70 [drm_kms_helper]
   process_one_work+0x212/0x650
   worker_thread+0x49/0x420
   kthread+0xfb/0x130
   ret_from_fork+0x3a/0x50
  Modules linked in: x86_pkg_temp_thermal amdgpu(O) chash(O)
  gpu_sched(O) drm_kms_helper(O) syscopyarea sysfillrect sysimgblt
  fb_sys_fops ttm(O) drm(O)

 Note that i915 has this issue masked, since hw_done is signaled after
 waiting for flip_done. Doing so will block the cursor update from
 happening until hw_done is signaled, preventing the cursor commit from
 destroying the state.

 v2: The reference on the commit object needs to be obtained before
  hw_done() is signaled, since that's the point where another commit
  is allowed to modify the state. Assuming that the
  new_crtc_state->commit object still exists within flip_done() is
  incorrect.

  Fix by getting a reference in setup_commit(), and releasing it
  during default_clear().

 Signed-off-by: Leo Li 
 ---

 Sending again, this time to the correct mailing list :)

 Leo
>>>
>>> Reviewed-by: Daniel Vetter 
>>> Cc: sta...@vger.kernel.org
>>>
>>> I think it'd be really good if you could get intel-gfx-ci to test this
>>> patch. Simply submit it to intel-...@lists.freedesktop.org. I'll leave
>>> applying to one of the amd drm-misc committers, once it's passed CI.
> 
> Leo, do you or Harry have drm-misc commit access yet?  If not, you should.
> 

I believe I do and will push the patch. Leo's getting the ball rolling to get 
access (fdo account, etc).

Harry

> Alex
> 
>>>
>>> Cheers, Daniel
>>
>> Thanks for the rb!
>>
>> On the topic of CI, is it possible to write a test (maybe one already
>> exists) for this issue? I've attempted to do one here:
>>
>> https://patchwork.freedesktop.org/patch/256319/
>>
>> The problem is finding a surefire way to trigger the sequence, I'm not
>> sure how that can be done. If you have any ideas, I would love to hear them.
>>
>> Leo
>>
>>>

   drivers/gpu/drm/drm_atomic.c|  5 +
   drivers/gpu/drm/drm_atomic_helper.c | 12 
   include/drm/drm_atomic.h| 11 +++
   3 files changed, 24 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
 index 3eb061e..12ae917 100644
 --- a/drivers/gpu/drm/drm_atomic.c
 +++ b/drivers/gpu/drm/drm_atomic.c
 @@ -174,6 +174,11 @@ void drm_atomic_state_default_clear(struct 
 drm_atomic_state *state)
  state->crtcs[i].state = NULL;
  state->crtcs[i].old_state = NULL;
  state->crtcs[i].new_state = NULL;
 +
 +if (state->crtcs[i].commit) {
 +drm_crtc_commit_put(state->crtcs[i].commit);
 +state->

[PATCH 00/29] Enabling new DAL display driver for amdgpu on Carrizo and Tonga

[Wentland, Harry]

Hi Dave, Daniel, others,

The goal with DAL is to provide a unified, full featured display stack to 
service all of our Linux offerings. This driver will have to support our full 
feature set beyond what's supported by amdgpu, e.g.
  - synchronzied timings across different displays
  - freesync
  - solid support of 6 displays in any configuration (HDMI, DVI, DP, DP MST, 
etc)
  - solid support of 4k at 60 timings on APUs
  - power features, such as
- clock-accurate bandwidth formulas
- improved interaction with powerplay to maximize power savings
- Improved audio and other infoframe related features
- Improved stability with powerplay since display hw is involved in the SMC hw 
interactions and improper programming sequences can lead to GPU hangs, etc.

The current amdgpu display stack grew somewhat organically and as such is not 
well suited to handling all of the hardware dependencies involved especially in 
areas like audio.  The drm abstractions used by the old code map less and less 
well to new hw pipelines.  Atomic helps, but if we are going to convert, it 
seemed like a good time to start fresh.

Our DC (Display Core in dc.h, etc.) is the framework to allow us to well 
represent current and future HW architectures. These don't always map 
one-to-one to DRM interfaces. For one we can't make the assumption that 
surfaces map one-to-one to pipes. 

The DAL internal abstractions were used since they match the abstractions used 
by our drivers for other OSes, pre and post silicon validation tools and HW 
team programming models. Keeping it as close to that as possible makes it 
easier to debug and validate and provides the most likely change of success in 
complex display configurations.

Please see the attached DC.png for an overview of the DAL design. 

For an atomic sequence you might want to look at
- enable/disable displays or change display config -> dc_commit_targets
(in dc/core/dc.c, called from amdgpu_dm_atomic_commit in 
amdgpu_dm/amdgpu_dm_types.c)

- commit planes-> 
dc_commit_surfaces_to_targets
(in dc/core/dc_target.c, called from dm_dc_surface_commit in 
amdgpu_dm/amdgpu_dm_types.c)

- validate -> dc_validate_resources
(in dc/core/dc.c, called from amdgpu_dm_atomic_check in 
amdgpu_dm/amdgpu_dm_types.c)


There's still a bunch of legacy stuff in these patches that's on our list of 
things to refactor. Some of that is 
- dc/adapter
- dc/asic_capability
- dc/audio
- dc/bios
- dc/gpio

We should be able to cut the size of this code to about 1/3 of what it is now.

As for the LOC we have about
22k for HW programming
30k legacy stuff
6k  dc/calcs - autogenerated from formulas provided by HW team
15k includes
6k  amdgpu_dm
8k  dc/core

About 14k of those are blank lines (we have a habit of leaving lots of blank 
space) and 16k are comments.

Cheers,
Harry


From: Daniel Vetter  on behalf of Daniel Vetter 

Sent: Friday, February 12, 2016 12:34 AM
To: Dave Airlie
Cc: Wentland, Harry; dri-devel
Subject: Re: [PATCH 00/29] Enabling new DAL display driver for amdgpu on 
Carrizo and Tonga

On Thu, Feb 11, 2016 at 10:06:14PM +0100, Daniel Vetter wrote:
> On Thu, Feb 11, 2016 at 9:52 PM, Dave Airlie  wrote:
> > On 12 February 2016 at 03:19, Harry Wentland  
> > wrote:
> >> This set of patches enables the new DAL display driver for amdgpu on 
> >> Carrizo
> >> Tonga, and Fiji ASICs. This driver will allow us going forward to bring
> >> display features on the open amdgpu driver (mostly) on par with the 
> >> Catalyst
> >> driver.
> >>
> >> This driver adds support for
> >> - Atomic KMS API
> >> - MST
> >> - HDMI 2.0
> >> - Better powerplay integration
> >> - Support of HW bandwidth formula on Carrizo
> >> - Better multi-display support and handling of co-functionality
> >> - Broader support of display dongles
> >> - Timing synchronization between DP and HDMI
> >>
> >> This patch series is based on Alex Deucher's drm-next-4.6-wip tree.
> >>
> > So the first minor criticism is this patch doesn't explain WHY.
> >
> > Why does the Linux kernel need 93k lines of code to run the displays
> > when whole drivers don't even come close.
> >
> > We've spent a lot of time ripping abstraction layers out of drivers (exynos
> > being the major one), what benefits does this major change bring to the
> > Linux kernel and the AMDGPU driver over and above a leaner, more focused
> > work.
> >
> > If were even to consider merging this it would be at a guess considered
> > staging level material which would require a TODO list of major cleanups.
> >
> > I do realise you

[PATCH 06/29] drm/amd/dal: Adapter Service

[Wentland, Harry]

Hi Dave,

There should be one instance of amdgpu per GPU, so one instance of DAL per GPU, 
hence this should be per GPU.

We haven't really done any multi-GPU testing with this code, though, but I 
briefly tried and can light up with two displays connected to a Tonga and 
Bonaire (Bonaire is supported on our internal tree but hasn't been merged into 
these patches yet).

Harry

-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com] 
Sent: February 11, 2016 7:26 PM
To: Wentland, Harry 
Cc: dri-devel 
Subject: Re: [PATCH 06/29] drm/amd/dal: Adapter Service

> +
> +/* Stores entire ASIC features by sets */ uint32_t 
> +adapter_feature_set[FEATURE_MAXIMUM/32];

Is this global, what about multiple GPUs in one machine, is this per GPU or per 
system?

Dave.

[PATCH 00/29] Enabling new DAL display driver for amdgpu on Carrizo and Tonga

[Wentland, Harry]

That applies only to Carrizo, unfortunately.

Harry

From: Mike Lothian [mailto:m...@fireburn.co.uk]
Sent: February 11, 2016 3:03 PM
To: Wentland, Harry ; dri-devel at 
lists.freedesktop.org
Subject: Re: [PATCH 00/29] Enabling new DAL display driver for amdgpu on 
Carrizo and Tonga

Hi

Does that mean Tonga is capable of HDMI 2.0 or is it only Carrizo

Cheers

Mike

On Thu, 11 Feb 2016 at 17:20 Harry Wentland mailto:harry.wentland at amd.com>> wrote:
This set of patches enables the new DAL display driver for amdgpu on Carrizo
Tonga, and Fiji ASICs. This driver will allow us going forward to bring
display features on the open amdgpu driver (mostly) on par with the Catalyst
driver.

This driver adds support for
- Atomic KMS API
- MST
- HDMI 2.0
- Better powerplay integration
- Support of HW bandwidth formula on Carrizo
- Better multi-display support and handling of co-functionality
- Broader support of display dongles
- Timing synchronization between DP and HDMI

This patch series is based on Alex Deucher's drm-next-4.6-wip tree.



Andrey Grodzovsky (1):
  drm/amd/dal: Force bw programming for DCE 10 until we start calculate
BW.

Harry Wentland (27):
  drm/amd/dal: Add dal headers
  drm/amd/dal: Add DAL Basic Types and Logger
  drm/amd/dal: Fixed point arithmetic
  drm/amd/dal: Asic Capabilities
  drm/amd/dal: GPIO (General Purpose IO)
  drm/amd/dal: Adapter Service
  drm/amd/dal: BIOS Parser
  drm/amd/dal: I2C Aux Manager
  drm/amd/dal: IRQ Service
  drm/amd/dal: GPU
  drm/amd/dal: Audio
  drm/amd/dal: Bandwidth calculations
  drm/amd/dal: Add encoder HW programming
  drm/amd/dal: Add clock source HW programming
  drm/amd/dal: Add timing generator HW programming
  drm/amd/dal: Add surface HW programming
  drm/amd/dal: Add framebuffer compression HW programming
  drm/amd/dal: Add input pixel processing HW programming
  drm/amd/dal: Add output pixel processing HW programming
  drm/amd/dal: Add transform & scaler HW programming
  drm/amd/dal: Add Carrizo HW sequencer and resource
  drm/amd/dal: Add Tonga/Fiji HW sequencer and resource
  drm/amd/dal: Add empty encoder programming for virtual HW
  drm/amd/dal: Add display core
  drm/amd/dal: Adding amdgpu_dm for dal
  drm/amdgpu: Use dal driver for Carrizo, Tonga, and Fiji
  drm/amd/dal: Correctly interpret rotation as bit set

Mykola Lysenko (1):
  drm/amd/dal: fix flip clean-up state

 drivers/gpu/drm/amd/amdgpu/Kconfig |3 +
 drivers/gpu/drm/amd/amdgpu/Makefile|   17 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   69 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|   20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   54 +-
 drivers/gpu/drm/amd/amdgpu/vi.c|  250 +
 drivers/gpu/drm/amd/dal/Kconfig|   48 +
 drivers/gpu/drm/amd/dal/Makefile   |   21 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/Makefile |   17 +
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.c  | 1468 ++
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm.h  |  168 +
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_helpers.c  |  474 ++
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.c  |  820 
 drivers/gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_irq.h  |  122 +
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.c|  480 ++
 .../drm/amd/dal/amdgpu_dm/amdgpu_dm_mst_types.h|   36 +
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_services.c |  457 ++
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.c| 2577 ++
 .../gpu/drm/amd/dal/amdgpu_dm/amdgpu_dm_types.h|  100 +
 drivers/gpu/drm/amd/dal/dal_services.h |  266 ++
 drivers/gpu/drm/amd/dal/dal_services_types.h   |   62 +
 drivers/gpu/drm/amd/dal/dc/Makefile|   28 +
 drivers/gpu/drm/amd/dal/dc/adapter/Makefile|   24 +
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.c   | 2089 
 .../gpu/drm/amd/dal/dc/adapter/adapter_service.h   |   71 +
 .../adapter/dce110/hw_ctx_adapter_service_dce110.c |  304 ++
 .../adapter/dce110/hw_ctx_adapter_service_dce110.h |   40 +
 .../diagnostics/hw_ctx_adapter_service_diag.c  |  133 +
 .../diagnostics/hw_ctx_adapter_service_diag.h  |   33 +
 .../amd/dal/dc/adapter/hw_ctx_adapter_service.c|  164 +
 .../amd/dal/dc/adapter/hw_ctx_adapter_service.h|   86 +
 .../drm/amd/dal/dc/adapter/wireless_data_source.c  |  208 +
 .../drm/amd/dal/dc/adapter/wireless_data_source.h  |   80 +
 .../gpu/drm/amd/dal/dc/asic_capability/Makefile|   35 +
 .../amd/dal/dc/asic_capability/asic_capability.c   |  190 +
 .../dc/asic_capability/carrizo_asic_capability.c   |  147 +
 .../dc/asic_capability/carrizo_asic_capability.h   |   36 +
 .../dal/dc/asic_capability/tonga_asic_capability.c |  146 +
 .../dal/dc/asic_capability/tonga_asic_capability.h |   36 +
 drivers/

[PATCH] drm/dp/mst: deallocate payload on port destruction

[Wentland, Harry]

Hi Dave, Daniel,

Have you had a chance to take a look at this patch?

Thanks,
Harry


-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Harry Wentland
Sent: January 27, 2016 9:40 AM
To: dri-devel at lists.freedesktop.org
Cc: Lysenko, Mykola 
Subject: [PATCH] drm/dp/mst: deallocate payload on port destruction

From: Mykola Lysenko 

This is needed to properly deallocate port payload after downstream branch get 
unplugged.

In order to do this unplugged MST topology should be preserved, to find first 
alive port on path to unplugged MST topology, and send payload deallocation 
request to branch device of found port.

For this mstb and port kref's are used in reversed order to track when port and 
branch memory could be freed.

Added additional functions to find appropriate mstb as described above.

Signed-off-by: Mykola Lysenko 
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 91 ---
 1 file changed, 83 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fc589265068b..5662e68ecccd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -803,6 +803,18 @@ static struct drm_dp_mst_branch 
*drm_dp_add_mst_branch_device(u8 lct, u8 *rad)
return mstb;
 }

+static void drm_dp_free_mst_port(struct kref *kref);
+
+static void drm_dp_free_mst_branch_device(struct kref *kref) {
+   struct drm_dp_mst_branch *mstb = container_of(kref, struct 
drm_dp_mst_branch, kref);
+   if (mstb->port_parent) {
+   if (list_empty(&mstb->port_parent->next))
+   kref_put(&mstb->port_parent->kref, 
drm_dp_free_mst_port);
+   }
+   kfree(mstb);
+}
+
 static void drm_dp_destroy_mst_branch_device(struct kref *kref)  {
struct drm_dp_mst_branch *mstb = container_of(kref, struct 
drm_dp_mst_branch, kref); @@ -810,6 +822,15 @@ static void 
drm_dp_destroy_mst_branch_device(struct kref *kref)
bool wake_tx = false;

/*
+* init kref again to be used by ports to remove mst branch when it is
+* not needed anymore
+*/
+   kref_init(kref);
+
+   if (mstb->port_parent && list_empty(&mstb->port_parent->next))
+   kref_get(&mstb->port_parent->kref);
+
+   /*
 * destroy all ports - don't need lock
 * as there are no more references to the mst branch
 * device at this point.
@@ -835,7 +856,8 @@ static void drm_dp_destroy_mst_branch_device(struct kref 
*kref)

if (wake_tx)
wake_up(&mstb->mgr->tx_waitq);
-   kfree(mstb);
+
+   kref_put(kref, drm_dp_free_mst_branch_device);
 }

 static void drm_dp_put_mst_branch_device(struct drm_dp_mst_branch *mstb) @@ 
-883,6 +905,7 @@ static void drm_dp_destroy_port(struct kref *kref)
 * from an EDID retrieval */

mutex_lock(&mgr->destroy_connector_lock);
+   kref_get(&port->parent->kref);
list_add(&port->next, &mgr->destroy_connector_list);
mutex_unlock(&mgr->destroy_connector_lock);
schedule_work(&mgr->destroy_connector_work);
@@ -1617,6 +1640,37 @@ static int drm_dp_send_enum_path_resources(struct 
drm_dp_mst_topology_mgr *mgr,
return 0;
 }

+static struct drm_dp_mst_port 
+*drm_dp_get_last_connected_port_to_mstb(struct drm_dp_mst_branch *mstb) {
+   if (!mstb->port_parent)
+   return NULL;
+
+   if (mstb->port_parent->mstb != mstb)
+   return mstb->port_parent;
+
+   return 
+drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
+}
+
+static struct drm_dp_mst_branch 
*drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
+struct 
drm_dp_mst_branch *mstb,
+int 
*port_num)
+{
+   struct drm_dp_mst_branch *rmstb = NULL;
+   struct drm_dp_mst_port *found_port;
+   mutex_lock(&mgr->lock);
+   if (mgr->mst_primary) {
+   found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
+
+   if (found_port) {
+   rmstb = found_port->parent;
+   kref_get(&rmstb->kref);
+   *port_num = found_port->port_num;
+   }
+   }
+   mutex_unlock(&mgr->lock);
+   return rmstb;
+}
+
 static int drm_dp_payload_send_msg(struct drm_dp_mst_topology_mgr *mgr,
   struct drm_dp_mst_port *port,
   int id,
@@ -1624,13 +1678,18 @@ static int drm_dp_payload_send_msg(struct 
drm_dp_mst_topology_mgr *mgr,  {
struct drm_dp_sideband_msg_tx *txmsg;
struct drm_dp_mst_branch *mstb;
-   int len, r

[PATCH 0/5] Fixes for MST (daisy-chain and 4k tiles)

[Wentland, Harry]

Hi Dave,

I've been running with lockdep with these changes for over a week now. Just ran 
another test with our daisy-chain displays and the 4k tiled display with no 
deadlocks or lockdep prints (other than "RCU lockdep checking is enabled.").

Thanks,
Harry


From: Dave Airlie 
Sent: Sunday, January 24, 2016 11:53 PM
To: Wentland, Harry
Cc: dri-devel
Subject: Re: [PATCH 0/5] Fixes for MST (daisy-chain and 4k tiles)

On 23 January 2016 at 08:07, Harry Wentland  wrote:
> A couple of MST fixes to bugs in the framework that we encountered when
> testing with
>   - three-display daisy-chain configurations
>   - 4k tiled displays

Hi Harry,

these all look pretty good to me, have you tested them with lockdep enabled?

I had started to fix the CSN/GUID one here a little while back but it's sitting
on a laptop I can't access at the moment.

But if you can test with lockdep, and it doesn't deadlock, then I'm happy
to accept these..

Reviewed-by: Dave Airlie 

Dave.
>
> Andrey Grodzovsky (1):
>   drm/dp/mst: Reverse order of MST enable and clearing VC payload table.
>
> Harry Wentland (2):
>   drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil
>   drm/dp/mst: Calculate MST PBN with 31.32 fixed point
>
> Hersen Wu (1):
>   drm/dp/mst: move GUID storage from mgr, port to only mst branch
>
> Mykola Lysenko (1):
>   drm/dp/mst: change MST detection scheme
>
>  drivers/gpu/drm/drm_dp_mst_topology.c | 180 
> +-
>  include/drm/drm_dp_mst_helper.h   |  25 ++---
>  include/drm/drm_fixed.h   |  54 +-
>  3 files changed, 154 insertions(+), 105 deletions(-)
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/dp/mst: always send reply for UP request

[Wentland, Harry]

Thanks, Dave.

Do you have an example when the up reply would be too big to fit into one 
sideband message? We don't expect that to happen.

Mykola, can you see if Dave's patch is a good alternative to your patch?

Harry



On Fri, Dec 18, 2015 at 7:57 PM -0800, "Dave Airlie" mailto:airlied at gmail.com>> wrote:

On 19 December 2015 at 08:14, Harry Wentland  wrote:
> From: Mykola Lysenko 
>
> We should always send reply for UP request in order
> to make downstream device clean-up resources appropriately.
>
> Issue was that reply for UP request was sent only once.

What happens though if the up reply is too big and needs to be cut into pieces,

Since the return value of process_single_tx_qlock is
-value - errno.
0 - part of msg sent
1 - all of msg sent

Does the attached patch make any difference?

It handles the queue like the down queue.

Dave.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH 0/2] Two small patches for MST

[Wentland, Harry]

Awesome. Thanks, Daniel.

Harry


From: Daniel Vetter  on behalf of Daniel Vetter 

Sent: Monday, December 14, 2015 12:32 PM
To: Wentland, Harry
Cc: Alex Deucher; Maling list - DRI developers
Subject: Re: [PATCH 0/2] Two small patches for MST

On Mon, Dec 14, 2015 at 05:14:47PM +, Wentland, Harry wrote:
> Thanks, Alex.
>
> Dave, will you pick these up when pulling from Alex's tree if he includes 
> them?

I stuffed them into drm-misc, should land still for 4.5.

Cheers, Daniel

>
> Thanks,
> Harry
>
> 
> From: Alex Deucher 
> Sent: Monday, December 14, 2015 10:26 AM
> To: Wentland, Harry
> Cc: Maling list - DRI developers
> Subject: Re: [PATCH 0/2] Two small patches for MST
>
> On Mon, Dec 7, 2015 at 1:55 PM, Harry Wentland  
> wrote:
> > Two minor patches for MST here. We were replying NACK to UP requests
> > when we intended to ACK them. We were also not filling in the vcpi
> > field for mst_mgr->payloads although it's defined. Saving the vcpi
> > simplifies the new amdgpu MST implementation that we currently work
> > on.
>
> For the series:
> Reviewed-by: Alex Deucher 
>
>
> >
> > Harry Wentland (1):
> >   drm/dp/mst: save vcpi with payloads
> >
> > Mykola Lysenko (1):
> >   drm/dp/mst: reply with ACK for UP reqs
> >
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > --
> > 2.1.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/2] Two small patches for MST

[Wentland, Harry]

Thanks, Alex.

Dave, will you pick these up when pulling from Alex's tree if he includes them?

Thanks,
Harry


From: Alex Deucher 
Sent: Monday, December 14, 2015 10:26 AM
To: Wentland, Harry
Cc: Maling list - DRI developers
Subject: Re: [PATCH 0/2] Two small patches for MST

On Mon, Dec 7, 2015 at 1:55 PM, Harry Wentland  
wrote:
> Two minor patches for MST here. We were replying NACK to UP requests
> when we intended to ACK them. We were also not filling in the vcpi
> field for mst_mgr->payloads although it's defined. Saving the vcpi
> simplifies the new amdgpu MST implementation that we currently work
> on.

For the series:
Reviewed-by: Alex Deucher 


>
> Harry Wentland (1):
>   drm/dp/mst: save vcpi with payloads
>
> Mykola Lysenko (1):
>   drm/dp/mst: reply with ACK for UP reqs
>
>  drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel