[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199047

--- Comment #5 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
(In reply to Alex Deucher from comment #4)
> Does it work with DC enabled?

With DC it works as expected. Unfortunately this is not a workaround for me,
cause there is still the use-after-free.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Overlay sugar syntax (was: Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes)

[Frank Rowand]

On 03/06/18 18:30, David Gibson wrote:
> On Tue, Mar 06, 2018 at 01:40:20PM -0800, Frank Rowand wrote:
>> On 03/06/18 11:51, Frank Rowand wrote:
>>> On 03/06/18 04:30, Geert Uytterhoeven wrote:

< snip >

>>> And the patched dtc works for a dts file that I was trying to convert
>>> to sugar dts syntax
>>
>> < snip >
>>
>> I noticed that a space in "&{/}" is an error.  I wanted to check whether
>> that was deliberate, or that the patch wasn't fully complete yet.
> 
> That's essentially deliberate - it's not really related to this patch
> at all.  The patch just re-uses the existing syntax for a "path
> reference".  The whole thing is treated as a single token, hence, no
> spaces.
> 
> It might be possible to change that, but it could introduce some
> complications when the path reference syntax is used in other places.
> So I'm disinclined to change it, unless there's a very strong reason
> to.
> 

< snip >

No, please do not change.  I just wanted to make sure I understood the
intended syntax.

BTW, thanks for all the time you've been putting into this recent stuff.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Chanwoo Choi]

Hi Andrzej, Archit,

On 2018년 03월 07일 20:13, Andrzej Hajda wrote:
> Hi Chanwoo, Archit,
> 
> On 07.03.2018 05:48, Chanwoo Choi wrote:
>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
>>> Hi Rob and Andrzej,
>>>
>>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
 Hi Rob, Chanwoo, Krzysztof,


 On 27.02.2018 08:11, Andrzej Hajda wrote:
> Hi,
>
> Thanks for reviews of previous iterations.
>
> This patchset introduces USB physical connector bindings, together with
> working example.
> I have removed RFC prefix - the patchset seems to be heading
> to a happy end :)
>
> v5: fixed extra parenthesis in dts, renamed extcon function.
> v4: improved binding descriptions, added missing reg in dts.
> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
> example.
> v2: I have addressed comments by Rob and Laurent, thanks 
>
> Changes in datail are described in the patches.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (5):
>   dt-bindings: add bindings for USB physical connector
>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>   arm64: dts: exynos: add OF graph between MHL and USB connector
>   extcon: add possibility to get extcon device by OF node
>
> Maciej Purski (1):
>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
 It looks like all patches received R-B or acks (I forgot add Krzysztof's
 acks for dts part).
 Now I have a question how to merge them.
 The only functional dependency is between bridge and extcon, and from
 the formal PoV bindings should be merged 1st.
 I can merge it:
 1. All patches via drm-misc tree.
 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
 samsung-soc tree.

 Is it OK, for all? Better ideas?
>>> Krzysztof picked the dts patches. I'll make the immutable branch based on 
>>> v4.16-rc1
>>> and apply them except for dts patchs. And I'll send the immutable branch to 
>>> Rob and Andrzej.
>>>
>>>
>> I made the immutable branch[1] as following: If you agree, I'll send pull 
>> request.
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>>
>> Or you can make the immutable branch and send pull request to Rob and me.
>>
> 
> It seems you took v5 instead of v6 version of extcon patch.

My mistake. I picked v6 and made the new immutable branch.
After Archit confirm it, I'll send pull request.

> 
> Beside it I am OK with your immutable branch, Archit is it OK to do it
> this way in drm-misc?
> 
> 
> Regards
> 
> Andrzej
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Overlay sugar syntax (was: Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes)

[Frank Rowand]

On 03/06/18 11:51, Frank Rowand wrote:
> On 03/06/18 04:30, Geert Uytterhoeven wrote:
>> Hi David,
>>
>> On Tue, Mar 6, 2018 at 4:54 AM, David Gibson
>>  wrote:
>>> On Fri, Feb 23, 2018 at 09:05:24AM +0100, Geert Uytterhoeven wrote:
 On Fri, Feb 23, 2018 at 3:38 AM, Frank Rowand  
 wrote:
> I was hoping to be able to convert the .dts files to use sugar syntax
> instead of hand coding the fragment nodes, but for this specific set
> of files I failed, since the labels that would have been required do
> not already exist in the base .dts files that that overlays would be
> applied against.

 Indeed, hence the fixup overlays use "target-path".

 BTW, is there any specific reason there is no sugar syntax support in dtc
 for absolute target paths? I guess to prevent adding stuff to a random
 existing node, and to encourage people to use a "connector" API defined in
 term of labels?
>>>
>>> Only because it hasn't been implemented.  Using &{/whatever} should
>>> IMO generate a target-path and the fact it doesn't is a bug.
>>>
 I'm also in the process of converting my collection of DT overlays to sugar
 syntax, and lack of support for "target-path" is the sole thing that holds
 me back from completing this. So for now I use a mix of sugar and
 traditional overlay syntax.

 In particular, I need "target-path" for two things:
   1. To refer to the root node, for adding devices that should live at
  (a board subnode of) the root node, like:
- devices connected to GPIO controllers provided by other base or
  overlay devices (e.g. LEDs, displays, buttons, ...),
- clock providers for other overlays devices (e.g. fixed-clock).
>>
 The former is the real blocker for me.
>>
>>> Below is draft patch adding target-path support.  The pretty minimal
>>> test examples do include a case using &{/}
>>>
>>> From 8f1b35f88395adea01ce1100c5faa27dacbc8410 Mon Sep 17 00:00:00 2001
>>> From: David Gibson 
>>> Date: Tue, 6 Mar 2018 13:27:53 +1100
>>> Subject: [PATCH] Correct overlay syntactic sugar for generating target-path
>>>  fragments
>>>
>>> We've recently added "syntactic sugar" support to generate runtime dtb
>>> overlays using similar syntax to the compile time overlays we've had for
>>> a while.  This worked with the  { ... } syntax, adjusting an existing
>>> labelled node, but would fail with the &{/path} { ... } syntax attempting
>>> to adjust an existing node referenced by its path.
>>>
>>> The previous code would always try to use the "target" property in the
>>> output overlay, which needs to be fixed up, and __fixups__ can only encode
>>> symbols, not paths, so the result could never work properly.
>>>
>>> This adds support for the &{/path} syntax for overlays, translating it into
>>> the "target-path" encoding in the output.  It also changes existing
>>> behaviour a little because we now unconditionally one fragment for each
>>> overlay section in the source.  Previously we would only create a fragment
>>> if we couldn't locally resolve the node referenced.  We need this for
>>> path references, because the path is supposed to be referencing something
>>> in the (not yet known) base tree, rather than the overlay tree we are
>>> working with now.  In particular one useful case for path based overlays
>>> is using &{/} - but the constructed overlay tree will always have a root
>>> node, meaning that without the change that would attempt to resolve the
>>> fragment locally, which is not what we want.
>>>
>>> Signed-off-by: David Gibson 
>>
>> Thank you, seems to work fine on dtc.git.
> 
> And the patched dtc works for a dts file that I was trying to convert
> to sugar dts syntax

< snip >

I noticed that a space in "&{/}" is an error.  I wanted to check whether
that was deliberate, or that the patch wasn't fully complete yet.
cat path_sugar_v1.dts 

$ nl -ba path_sugar_v1.dts
 1  
 2  /dts-v1/;
 3  /plugin/;
 4  &{/} {
 5  #address-cells = <2>;
 6  #size-cells = <2>;
 7  
 8  my_node@feb9 {
 9  compatible = "vendor,device";
10  reg = <0 0xfeb9 0 0x1c>;
11  
12  };
13  
14  };

$ dtc -O dts path_sugar_v1.dts 
/dts-v1/;

/ {

fragment@0 {
target-path = [2f 00];

__overlay__ {
#address-cells = <0x2>;
#size-cells = <0x2>;

my_node@feb9 {
compatible = "vendor,device";
reg = <0x0 0xfeb9 0x0 0x1c>;
};
};
};
};

$ nl -ba path_sugar_v2.dts
 1  
 2  /dts-v1/;
 3  /plugin/;
 4  

[PATCH] drm/vmwgfx: Use kasprintf

[Himanshu Jha]

Use kasprintf instead of combination of kmalloc and sprintf. Also,
remove the local variables used for storing the string length as they
are not required now.

Signed-off-by: Himanshu Jha 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 9700099..cdff992 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -328,7 +328,7 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
 {
struct rpc_channel channel;
char *msg, *reply = NULL;
-   size_t msg_len, reply_len = 0;
+   size_t reply_len = 0;
int ret = 0;
 
 
@@ -338,15 +338,12 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
if (!guest_info_param || !length)
return -EINVAL;
 
-   msg_len = strlen(guest_info_param) + strlen("info-get ") + 1;
-   msg = kzalloc(msg_len, GFP_KERNEL);
+   msg = kasprintf(GFP_KERNEL, "info-get %s", guest_info_param);
if (!msg) {
DRM_ERROR("Cannot allocate memory to get %s", guest_info_param);
return -ENOMEM;
}
 
-   sprintf(msg, "info-get %s", guest_info_param);
-
if (vmw_open_channel(, RPCI_PROTOCOL_NUM) ||
vmw_send_msg(, msg) ||
vmw_recv_msg(, (void *) , _len) ||
@@ -388,7 +385,6 @@ int vmw_host_log(const char *log)
 {
struct rpc_channel channel;
char *msg;
-   int msg_len;
int ret = 0;
 
 
@@ -398,15 +394,12 @@ int vmw_host_log(const char *log)
if (!log)
return ret;
 
-   msg_len = strlen(log) + strlen("log ") + 1;
-   msg = kzalloc(msg_len, GFP_KERNEL);
+   msg = kasprintf(GFP_KERNEL, "log %s", log);
if (!msg) {
DRM_ERROR("Cannot allocate memory for log message\n");
return -ENOMEM;
}
 
-   sprintf(msg, "log %s", log);
-
if (vmw_open_channel(, RPCI_PROTOCOL_NUM) ||
vmw_send_msg(, msg) ||
vmw_close_channel()) {
-- 
2.7.4

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

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Chanwoo Choi]

On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
> Hi Rob and Andrzej,
> 
> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
>> Hi Rob, Chanwoo, Krzysztof,
>>
>>
>> On 27.02.2018 08:11, Andrzej Hajda wrote:
>>> Hi,
>>>
>>> Thanks for reviews of previous iterations.
>>>
>>> This patchset introduces USB physical connector bindings, together with
>>> working example.
>>> I have removed RFC prefix - the patchset seems to be heading
>>> to a happy end :)
>>>
>>> v5: fixed extra parenthesis in dts, renamed extcon function.
>>> v4: improved binding descriptions, added missing reg in dts.
>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>>> example.
>>> v2: I have addressed comments by Rob and Laurent, thanks 
>>>
>>> Changes in datail are described in the patches.
>>>
>>> Regards
>>> Andrzej
>>>
>>>
>>> Andrzej Hajda (5):
>>>   dt-bindings: add bindings for USB physical connector
>>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>>   extcon: add possibility to get extcon device by OF node
>>>
>>> Maciej Purski (1):
>>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>>
>> It looks like all patches received R-B or acks (I forgot add Krzysztof's
>> acks for dts part).
>> Now I have a question how to merge them.
>> The only functional dependency is between bridge and extcon, and from
>> the formal PoV bindings should be merged 1st.
>> I can merge it:
>> 1. All patches via drm-misc tree.
>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
>> samsung-soc tree.
>>
>> Is it OK, for all? Better ideas?
> 
> Krzysztof picked the dts patches. I'll make the immutable branch based on 
> v4.16-rc1
> and apply them except for dts patchs. And I'll send the immutable branch to 
> Rob and Andrzej.
> 
> 

I made the immutable branch[1] as following: If you agree, I'll send pull 
request.
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17

Or you can make the immutable branch and send pull request to Rob and me.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU

[Viresh Kumar]

On 06-03-18, 08:37, Jordan Crouse wrote:
> I'll try to explain but I might need Stephen or some of the other folks to 
> jump
> in and save me.

Maybe you should start using his kernel.org address then ? :)

> On sdm845 there are shared power resources controlled by the RPMh which is
> programed by a series of commands from the regulator driver; but in the case
> of the GPU the votes are passed to the GMU (graphics management unit) which
> communicates with the RPMh on behalf of the GPU.
> 
> In order to construct the RPMh vote we need first need a voltage level that we
> can look up in a database. qcom,arc-level is the voltage level associated with
> a specific OPP.
> 
> I had previously been abusing this with opp-microvolt but that was wrong for
> obvious reasons and then Stephen pointed out that this would be a better way.

Glad that you shared that :)

A solution is already in progress for that and is partially merged as
well.

Look for "performance_state" in genpd and OPP cores (already merged),
followed by this series here:

https://lkml.kernel.org/r/cover.1513926033.git.viresh.ku...@linaro.org

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

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Chanwoo Choi]

Hi Rob and Andrzej,

On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
> Hi Rob, Chanwoo, Krzysztof,
> 
> 
> On 27.02.2018 08:11, Andrzej Hajda wrote:
>> Hi,
>>
>> Thanks for reviews of previous iterations.
>>
>> This patchset introduces USB physical connector bindings, together with
>> working example.
>> I have removed RFC prefix - the patchset seems to be heading
>> to a happy end :)
>>
>> v5: fixed extra parenthesis in dts, renamed extcon function.
>> v4: improved binding descriptions, added missing reg in dts.
>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>> example.
>> v2: I have addressed comments by Rob and Laurent, thanks 
>>
>> Changes in datail are described in the patches.
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (5):
>>   dt-bindings: add bindings for USB physical connector
>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>   extcon: add possibility to get extcon device by OF node
>>
>> Maciej Purski (1):
>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
> 
> It looks like all patches received R-B or acks (I forgot add Krzysztof's
> acks for dts part).
> Now I have a question how to merge them.
> The only functional dependency is between bridge and extcon, and from
> the formal PoV bindings should be merged 1st.
> I can merge it:
> 1. All patches via drm-misc tree.
> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
> samsung-soc tree.
> 
> Is it OK, for all? Better ideas?

Krzysztof picked the dts patches. I'll make the immutable branch based on 
v4.16-rc1
and apply them except for dts patchs. And I'll send the immutable branch to Rob 
and Andrzej.


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Overlay sugar syntax (was: Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes)

[Frank Rowand]

On 03/06/18 04:30, Geert Uytterhoeven wrote:
> Hi David,
> 
> On Tue, Mar 6, 2018 at 4:54 AM, David Gibson
>  wrote:
>> On Fri, Feb 23, 2018 at 09:05:24AM +0100, Geert Uytterhoeven wrote:
>>> On Fri, Feb 23, 2018 at 3:38 AM, Frank Rowand  
>>> wrote:
 I was hoping to be able to convert the .dts files to use sugar syntax
 instead of hand coding the fragment nodes, but for this specific set
 of files I failed, since the labels that would have been required do
 not already exist in the base .dts files that that overlays would be
 applied against.
>>>
>>> Indeed, hence the fixup overlays use "target-path".
>>>
>>> BTW, is there any specific reason there is no sugar syntax support in dtc
>>> for absolute target paths? I guess to prevent adding stuff to a random
>>> existing node, and to encourage people to use a "connector" API defined in
>>> term of labels?
>>
>> Only because it hasn't been implemented.  Using &{/whatever} should
>> IMO generate a target-path and the fact it doesn't is a bug.
>>
>>> I'm also in the process of converting my collection of DT overlays to sugar
>>> syntax, and lack of support for "target-path" is the sole thing that holds
>>> me back from completing this. So for now I use a mix of sugar and
>>> traditional overlay syntax.
>>>
>>> In particular, I need "target-path" for two things:
>>>   1. To refer to the root node, for adding devices that should live at
>>>  (a board subnode of) the root node, like:
>>>- devices connected to GPIO controllers provided by other base or
>>>  overlay devices (e.g. LEDs, displays, buttons, ...),
>>>- clock providers for other overlays devices (e.g. fixed-clock).
> 
>>> The former is the real blocker for me.
> 
>> Below is draft patch adding target-path support.  The pretty minimal
>> test examples do include a case using &{/}
>>
>> From 8f1b35f88395adea01ce1100c5faa27dacbc8410 Mon Sep 17 00:00:00 2001
>> From: David Gibson 
>> Date: Tue, 6 Mar 2018 13:27:53 +1100
>> Subject: [PATCH] Correct overlay syntactic sugar for generating target-path
>>  fragments
>>
>> We've recently added "syntactic sugar" support to generate runtime dtb
>> overlays using similar syntax to the compile time overlays we've had for
>> a while.  This worked with the  { ... } syntax, adjusting an existing
>> labelled node, but would fail with the &{/path} { ... } syntax attempting
>> to adjust an existing node referenced by its path.
>>
>> The previous code would always try to use the "target" property in the
>> output overlay, which needs to be fixed up, and __fixups__ can only encode
>> symbols, not paths, so the result could never work properly.
>>
>> This adds support for the &{/path} syntax for overlays, translating it into
>> the "target-path" encoding in the output.  It also changes existing
>> behaviour a little because we now unconditionally one fragment for each
>> overlay section in the source.  Previously we would only create a fragment
>> if we couldn't locally resolve the node referenced.  We need this for
>> path references, because the path is supposed to be referencing something
>> in the (not yet known) base tree, rather than the overlay tree we are
>> working with now.  In particular one useful case for path based overlays
>> is using &{/} - but the constructed overlay tree will always have a root
>> node, meaning that without the change that would attempt to resolve the
>> fragment locally, which is not what we want.
>>
>> Signed-off-by: David Gibson 
> 
> Thank you, seems to work fine on dtc.git.

And the patched dtc works for a dts file that I was trying to convert
to sugar dts syntax in the thread that Geert was responding to when he
created this thread.

(Laurent -- no need to worry about this for your current series.
Converting your dts files will be an easy task to do in a future
kernel version -- remind me if I forget to send a patch.)

-Frank

> 
> Note that while the dtc part applies on the in-kernel copy of dtc, it
> doesn't work there: "&{/}" behaves the same as "/" (i.e. no overlay
> fragment is generated), but "&{/foo}" does create the overlay fragment.
> Merging in Rob's for-next branch to upgrade Linux' copy of dtc fixes that.
> 
> Thanks a lot!
> Converting my remaining overlay fragments to sugar syntax...
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> .
> 

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

Re: Overlay sugar syntax (was: Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes)

[David Gibson]

On Tue, Mar 06, 2018 at 01:40:20PM -0800, Frank Rowand wrote:
> On 03/06/18 11:51, Frank Rowand wrote:
> > On 03/06/18 04:30, Geert Uytterhoeven wrote:
> >> Hi David,
> >>
> >> On Tue, Mar 6, 2018 at 4:54 AM, David Gibson
> >>  wrote:
> >>> On Fri, Feb 23, 2018 at 09:05:24AM +0100, Geert Uytterhoeven wrote:
>  On Fri, Feb 23, 2018 at 3:38 AM, Frank Rowand  
>  wrote:
> > I was hoping to be able to convert the .dts files to use sugar syntax
> > instead of hand coding the fragment nodes, but for this specific set
> > of files I failed, since the labels that would have been required do
> > not already exist in the base .dts files that that overlays would be
> > applied against.
> 
>  Indeed, hence the fixup overlays use "target-path".
> 
>  BTW, is there any specific reason there is no sugar syntax support in dtc
>  for absolute target paths? I guess to prevent adding stuff to a random
>  existing node, and to encourage people to use a "connector" API defined 
>  in
>  term of labels?
> >>>
> >>> Only because it hasn't been implemented.  Using &{/whatever} should
> >>> IMO generate a target-path and the fact it doesn't is a bug.
> >>>
>  I'm also in the process of converting my collection of DT overlays to 
>  sugar
>  syntax, and lack of support for "target-path" is the sole thing that 
>  holds
>  me back from completing this. So for now I use a mix of sugar and
>  traditional overlay syntax.
> 
>  In particular, I need "target-path" for two things:
>    1. To refer to the root node, for adding devices that should live at
>   (a board subnode of) the root node, like:
> - devices connected to GPIO controllers provided by other base or
>   overlay devices (e.g. LEDs, displays, buttons, ...),
> - clock providers for other overlays devices (e.g. fixed-clock).
> >>
>  The former is the real blocker for me.
> >>
> >>> Below is draft patch adding target-path support.  The pretty minimal
> >>> test examples do include a case using &{/}
> >>>
> >>> From 8f1b35f88395adea01ce1100c5faa27dacbc8410 Mon Sep 17 00:00:00 2001
> >>> From: David Gibson 
> >>> Date: Tue, 6 Mar 2018 13:27:53 +1100
> >>> Subject: [PATCH] Correct overlay syntactic sugar for generating 
> >>> target-path
> >>>  fragments
> >>>
> >>> We've recently added "syntactic sugar" support to generate runtime dtb
> >>> overlays using similar syntax to the compile time overlays we've had for
> >>> a while.  This worked with the  { ... } syntax, adjusting an 
> >>> existing
> >>> labelled node, but would fail with the &{/path} { ... } syntax attempting
> >>> to adjust an existing node referenced by its path.
> >>>
> >>> The previous code would always try to use the "target" property in the
> >>> output overlay, which needs to be fixed up, and __fixups__ can only encode
> >>> symbols, not paths, so the result could never work properly.
> >>>
> >>> This adds support for the &{/path} syntax for overlays, translating it 
> >>> into
> >>> the "target-path" encoding in the output.  It also changes existing
> >>> behaviour a little because we now unconditionally one fragment for each
> >>> overlay section in the source.  Previously we would only create a fragment
> >>> if we couldn't locally resolve the node referenced.  We need this for
> >>> path references, because the path is supposed to be referencing something
> >>> in the (not yet known) base tree, rather than the overlay tree we are
> >>> working with now.  In particular one useful case for path based overlays
> >>> is using &{/} - but the constructed overlay tree will always have a root
> >>> node, meaning that without the change that would attempt to resolve the
> >>> fragment locally, which is not what we want.
> >>>
> >>> Signed-off-by: David Gibson 
> >>
> >> Thank you, seems to work fine on dtc.git.
> > 
> > And the patched dtc works for a dts file that I was trying to convert
> > to sugar dts syntax
> 
> < snip >
> 
> I noticed that a space in "&{/}" is an error.  I wanted to check whether
> that was deliberate, or that the patch wasn't fully complete yet.

That's essentially deliberate - it's not really related to this patch
at all.  The patch just re-uses the existing syntax for a "path
reference".  The whole thing is treated as a single token, hence, no
spaces.

It might be possible to change that, but it could introduce some
complications when the path reference syntax is used in other places.
So I'm disinclined to change it, unless there's a very strong reason
to.

> cat path_sugar_v1.dts 
> 
> $ nl -ba path_sugar_v1.dts
>  1
>  2/dts-v1/;
>  3/plugin/;
>  4&{/} {
>  5#address-cells = <2>;
>  6#size-cells = <2>;
>  7
>  8

[PATCH] video: fbdev: via_aux_vt1632: remove VLA usage

[Gustavo A. R. Silva]

In preparation to enabling -Wvla, remove VLA and replace it
with a fixed-length array instead. Also, remove variable 'len'.

Notice that no new IDs have been added in seven years.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/via/via_aux_vt1632.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/via/via_aux_vt1632.c 
b/drivers/video/fbdev/via/via_aux_vt1632.c
index d24f4cd..0cd0d2a 100644
--- a/drivers/video/fbdev/via/via_aux_vt1632.c
+++ b/drivers/video/fbdev/via/via_aux_vt1632.c
@@ -35,10 +35,10 @@ static void probe(struct via_aux_bus *bus, u8 addr)
.addr   =   addr,
.name   =   name};
/* check vendor id and device id */
-   const u8 id[] = {0x06, 0x11, 0x92, 0x31}, len = ARRAY_SIZE(id);
-   u8 tmp[len];
+   const u8 id[4] = {0x06, 0x11, 0x92, 0x31};
+   u8 tmp[4];
 
-   if (!via_aux_read(, 0x00, tmp, len) || memcmp(id, tmp, len))
+   if (!via_aux_read(, 0x00, tmp, 4) || memcmp(id, tmp, 4))
return;
 
printk(KERN_INFO "viafb: Found %s at address 0x%x\n", name, addr);
-- 
2.7.4

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

[PATCH] video: fbdev: via_aux_vt1636: remove VLA usage

[Gustavo A. R. Silva]

In preparation to enabling -Wvla, remove VLA and replace it
with a fixed-length array instead. Also, remove variable 'len'.

Notice that no new IDs have been added in seven years.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/via/via_aux_vt1636.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/via/via_aux_vt1636.c 
b/drivers/video/fbdev/via/via_aux_vt1636.c
index 9e015c1..d6273a4 100644
--- a/drivers/video/fbdev/via/via_aux_vt1636.c
+++ b/drivers/video/fbdev/via/via_aux_vt1636.c
@@ -35,10 +35,10 @@ void via_aux_vt1636_probe(struct via_aux_bus *bus)
.addr   =   0x40,
.name   =   name};
/* check vendor id and device id */
-   const u8 id[] = {0x06, 0x11, 0x45, 0x33}, len = ARRAY_SIZE(id);
-   u8 tmp[len];
+   const u8 id[4] = {0x06, 0x11, 0x45, 0x33};
+   u8 tmp[4];
 
-   if (!via_aux_read(, 0x00, tmp, len) || memcmp(id, tmp, len))
+   if (!via_aux_read(, 0x00, tmp, 4) || memcmp(id, tmp, 4))
return;
 
printk(KERN_INFO "viafb: Found %s\n", name);
-- 
2.7.4

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

Re: [PATCH v2 00/10] splash screen on the stm32f769 disco board

[Simon Glass]

On 2 March 2018 at 08:44, yannick fertre  wrote:
>
> Version 2:
> - Replace debug log by pr_error, pr_warn or pr_info.
> - Rework bridge between ltdc & dsi panel
> - Rework backligh management (with or witout gpio)
> - Rework panel otm8009a
> - Add new panel raydium rm68200
>
> Version 1:
> - Initial commit
>
> This serie contains all patchsets needed for displaying a splash screen
> on the stm32f769 disco board.
>
> yannick fertre (10):
>   video: stm32: stm32_ltdc: add bridge to display controller
>   video: stm32: stm32_ltdc: update debug log
>   video: add support of MIPI DSI interface
>   video: add support of panel OTM8009A
>   video: add MIPI DSI host controller bridge
>   video: add support of STM32 MIPI DSI controller driver
>   video: add support of panel rm68200
>   arm: dts: stm32: add dsi for STM32F746
>   arm: dts: stm32: add display for STM32F769 disco board
>   board: Add STM32F769 SoC, discovery board support
>
>  arch/arm/dts/stm32f746.dtsi|  12 +
>  arch/arm/dts/stm32f769-disco.dts   |  71 
>  configs/stm32f769-disco_defconfig  |  63 +++
>  drivers/video/Kconfig  |  32 ++
>  drivers/video/Makefile |   4 +
>  drivers/video/dw_mipi_dsi.c| 822 
> +
>  drivers/video/mipi_display.c   | 807 
>  drivers/video/orisetech_otm8009a.c | 329 +++
>  drivers/video/raydium-rm68200.c| 329 +++
>  drivers/video/stm32/Kconfig|  10 +
>  drivers/video/stm32/Makefile   |   1 +
>  drivers/video/stm32/stm32_dsi.c| 427 +++
>  drivers/video/stm32/stm32_ltdc.c   | 144 ---
>  include/dw_mipi_dsi.h  |  32 ++
>  include/mipi_display.h | 257 +++-
>  15 files changed, 3285 insertions(+), 55 deletions(-)
>  create mode 100644 configs/stm32f769-disco_defconfig
>  create mode 100644 drivers/video/dw_mipi_dsi.c
>  create mode 100644 drivers/video/mipi_display.c
>  create mode 100644 drivers/video/orisetech_otm8009a.c
>  create mode 100644 drivers/video/raydium-rm68200.c
>  create mode 100644 drivers/video/stm32/stm32_dsi.c
>  create mode 100644 include/dw_mipi_dsi.h

Does this use driver model? I cannot see it.

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

Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

[Marek Szyprowski]

Hi Inki,

On 2018-03-08 07:50, Inki Dae wrote:

2018년 03월 08일 15:29에 Marek Szyprowski 이(가) 쓴 글:

On 2018-03-08 05:01, Inki Dae wrote:

2018년 03월 08일 02:11에 Sylwester Nawrocki 이(가) 쓴 글:

The #sound-dai-cells DT property is required to describe link between
the HDMI IP block and the SoC's audio subsystem.

Signed-off-by: Sylwester Nawrocki 
---
   Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index 8715ff06c457..6b2a526ec586 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -50,6 +50,9 @@ Required properties for Exynos 5433:
   - clock-names: aliases for above clock specfiers.
   - samsung,sysreg: handle to syscon used to control the system registers.
   +Optional properties for Exynos 4210, 4212, 5420 and 5433:
+ - #sound-dai-cells: should be 0.
+

Just trivial question. 'sound-dai-cells' property could affect hdmi driver? I 
looked into HDMI codec driver but I didn't find relevat code.
I mean that if this property never affect HDMI driver then this property would 
be a dead thing even through this can be declared optionally.

This property is used by ASoC framework when it is building connections
between all elements of the virtual 'sound card'. It allows generic
code to find proper driver for the digital audio interface (DAI) object.

I also assumed that some place of ASoC framework checks this property. For this 
I looked into HDMI codec driver(sound/soc/codecs/hdmi-codec.c) and relevant 
interfaces of ASoC framework.
But I couldn't find it. :( Could you let me know which code of ASoC framework 
checks this? I saw this property only in 'snd_soc_of_get_dai_name' and 
'snd_soc_of_get_dai_link_codecs' functions but seems these functions aren't 
called by the HDMI codec driver.


It is used by snd_soc_of_get_dai_link_codecs() function, which is called
from respective board/machine driver. See sound/soc/samsung/odroid.c for
good example. It allows to automatically create connection to max98090 and
hdmi codec devices, which are specified in 'sound/codec' node (see
exynos5422-odroidxu3-audio.dtsi).

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Jani Nikula]

On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
>
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  6 ++
>  2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..cdb04c9 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);

\n missing.

> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);

\n missing.

> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..1269ef8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> +# define DP_REV_10  0x10
> +# define DP_REV_11  0x11
> +# define DP_REV_12  0x12
> +# define DP_REV_13  0x13
> +# define DP_REV_14  0x14

I am not sure what good these buy us, but if people think they're the
way to go, then so be it. Just bear in mind that per spec, "The DPCD
revision number does not necessarily match the DisplayPort version
number." so "DP_REV" doesn't actually mean *DP* revision.


BR,
Jani.

>  
>  #define DP_MAX_LINK_RATE0x001
>  
> @@ -118,6 +123,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

[Inki Dae]

Hi Marek,

2018년 03월 08일 15:29에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
> 
> On 2018-03-08 05:01, Inki Dae wrote:
>> Hi Sylwester,
>>
>> 2018년 03월 08일 02:11에 Sylwester Nawrocki 이(가) 쓴 글:
>>> The #sound-dai-cells DT property is required to describe link between
>>> the HDMI IP block and the SoC's audio subsystem.
>>>
>>> Signed-off-by: Sylwester Nawrocki 
>>> ---
>>>   Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
>>> b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
>>> index 8715ff06c457..6b2a526ec586 100644
>>> --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
>>> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
>>> @@ -50,6 +50,9 @@ Required properties for Exynos 5433:
>>>   - clock-names: aliases for above clock specfiers.
>>>   - samsung,sysreg: handle to syscon used to control the system registers.
>>>   +Optional properties for Exynos 4210, 4212, 5420 and 5433:
>>> + - #sound-dai-cells: should be 0.
>>> +
>> Just trivial question. 'sound-dai-cells' property could affect hdmi driver? 
>> I looked into HDMI codec driver but I didn't find relevat code.
>> I mean that if this property never affect HDMI driver then this property 
>> would be a dead thing even through this can be declared optionally.
> 
> This property is used by ASoC framework when it is building connections
> between all elements of the virtual 'sound card'. It allows generic
> code to find proper driver for the digital audio interface (DAI) object.

I also assumed that some place of ASoC framework checks this property. For this 
I looked into HDMI codec driver(sound/soc/codecs/hdmi-codec.c) and relevant 
interfaces of ASoC framework.
But I couldn't find it. :( Could you let me know which code of ASoC framework 
checks this? I saw this property only in 'snd_soc_of_get_dai_name' and 
'snd_soc_of_get_dai_link_codecs' functions but seems these functions aren't 
called by the HDMI codec driver.

Thanks,
Inki Dae

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Ramalingam C]

On Tuesday 27 February 2018 04:20 AM, Chris Wilson wrote:

Quoting Ramalingam C (2018-02-26 17:12:39)

DP and HDMI HDCP specifications are varying with respect to
detecting the R0 and ksv_fifo availability.

DP will produce CP_IRQ and set a bit for indicating the R0 and
FIFO_READY status.

Whereas HDMI will set a bit for FIFO_READY but there is no bit
indication for R0 ready. And also polling of READY bit is needed for
HDMI as ther is no CP_IRQ.

So Fielding the CP_IRQ for DP and the polling the READY bit for a
period and blindly waiting for a fixed time for R0 incase of HDMI are
moved into corresponding hdcp_shim.

Signed-off-by: Ramalingam C 
---
+static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
+int timeout)
+{
+   long ret;
+
+   if (completion_done(cp_irq_recved))
+   reinit_completion(cp_irq_recved);
+
+   ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
+   msecs_to_jiffies(
+   timeout));
+   reinit_completion(cp_irq_recved);

This is not thread-safe.

The trick is to use a waitqueue to interrupt the sleeps inside the wait
loops to complete the polling quicker. (As stated, you can't escape the
polling, and you always need to check the IRQ was for the event you
expected anyway.)
-Chris


Chris,

I think I am lost here. Could you please help me understand what are we missing 
here?
Completion also uses the wait_queue and each thread that want to wait for a 
event waits on it.
And on IRQ arrival through complete_all we are marking the completion->done and 
waking up all the thread sleeping at completion wait_queue.

Are you suggesting wait_event_timeout as we have in intel_dp_aux_wait_done?

Thanks,
--Ram


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

Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

[Marek Szyprowski]

Hi Inki,

On 2018-03-08 05:01, Inki Dae wrote:

Hi Sylwester,

2018년 03월 08일 02:11에 Sylwester Nawrocki 이(가) 쓴 글:

The #sound-dai-cells DT property is required to describe link between
the HDMI IP block and the SoC's audio subsystem.

Signed-off-by: Sylwester Nawrocki 
---
  Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index 8715ff06c457..6b2a526ec586 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -50,6 +50,9 @@ Required properties for Exynos 5433:
  - clock-names: aliases for above clock specfiers.
  - samsung,sysreg: handle to syscon used to control the system registers.
  
+Optional properties for Exynos 4210, 4212, 5420 and 5433:

+ - #sound-dai-cells: should be 0.
+

Just trivial question. 'sound-dai-cells' property could affect hdmi driver? I 
looked into HDMI codec driver but I didn't find relevat code.
I mean that if this property never affect HDMI driver then this property would 
be a dead thing even through this can be declared optionally.


This property is used by ASoC framework when it is building connections
between all elements of the virtual 'sound card'. It allows generic
code to find proper driver for the digital audio interface (DAI) object.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

RE: [PATCH 1/6] drm/ttm: add ttm_bo_pipeline_gutting

[He, Roger]

Patch 1,4,5: Acked-by: Roger He 
Patch 2,3,6: Reviewed-by: Roger He 

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Tuesday, March 06, 2018 10:44 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 1/6] drm/ttm: add ttm_bo_pipeline_gutting

Allows us to gut a BO of it's backing store when the driver says that it isn't 
needed any more.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c  | 15 ---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 24 
 include/drm/ttm/ttm_bo_driver.h   |  9 +
 3 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
ad142a92eb80..98e06f8bf23b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -622,14 +622,23 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
 
reservation_object_assert_held(bo->resv);
 
+   placement.num_placement = 0;
+   placement.num_busy_placement = 0;
+   bdev->driver->evict_flags(bo, );
+
+   if (!placement.num_placement && !placement.num_busy_placement) {
+   ret = ttm_bo_pipeline_gutting(bo);
+   if (ret)
+   return ret;
+
+   return ttm_tt_create(bo, false);
+   }
+
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
evict_mem.bus.io_reserved_vm = false;
evict_mem.bus.io_reserved_count = 0;
 
-   placement.num_placement = 0;
-   placement.num_busy_placement = 0;
-   bdev->driver->evict_flags(bo, );
ret = ttm_bo_mem_space(bo, , _mem, ctx);
if (ret) {
if (ret != -ERESTARTSYS) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6d6a3f46143b..1f730b3f18e5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -801,3 +801,27 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
return 0;
 }
 EXPORT_SYMBOL(ttm_bo_pipeline_move);
+
+int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo) {
+   struct ttm_buffer_object *ghost;
+   int ret;
+
+   ret = ttm_buffer_object_transfer(bo, );
+   if (ret)
+   return ret;
+
+   ret = reservation_object_copy_fences(ghost->resv, bo->resv);
+   /* Last resort, wait for the BO to be idle when we are OOM */
+   if (ret)
+   ttm_bo_wait(bo, false, false);
+
+   memset(>mem, 0, sizeof(bo->mem));
+   bo->mem.mem_type = TTM_PL_SYSTEM;
+   bo->ttm = NULL;
+
+   ttm_bo_unreserve(ghost);
+   ttm_bo_unref();
+
+   return 0;
+}
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h 
index f8e2515b401f..39cd6b086d3a 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -849,6 +849,15 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
 struct dma_fence *fence, bool evict,
 struct ttm_mem_reg *new_mem);
 
+/**
+ * ttm_bo_pipeline_gutting.
+ *
+ * @bo: A pointer to a struct ttm_buffer_object.
+ *
+ * Pipelined gutting a BO of it's backing store.
+ */
+int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo);
+
 /**
  * ttm_io_prot
  *
--
2.14.1

___
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

[Bug 105390] Requesting a new account for IGT

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105390

Daniel Vetter  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |sitewranglers@lists.freedes
   |.org|ktop.org
Version|XOrg git|unspecified
  Component|IGT |New Accounts
Product|DRI |freedesktop.org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105390] Requesting a new account for IGT

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105390

--- Comment #1 from Daniel Vetter  ---
Ack (also from Petri and Arek).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/6] drm/msm/A6xx: Implement preemption for A6XX targets

[Sharat Masetty]

This patch implements preemption feature for A6xx targets, this allows
the GPU to switch to a higher priority ringbuffer if one is ready. A6XX
hardware as such supports multiple levels of preemption granularities,
ranging from coarse grained(ringbuffer level) to a more fine grained
such as draw-call level or a bin boundary level preemption. This patch
enables the basic preemption level, with more fine grained preemption
support to follow.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  44 
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 146 +++-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 136 +++
 drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 383 ++
 5 files changed, 708 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_preempt.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 0b6e150..1978312 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -13,6 +13,7 @@ msm-y := \
adreno/a6xx_gpu.o \
adreno/a6xx_gmu.o \
adreno/a6xx_hfi.o \
+   adreno/a6xx_preempt.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 8d732e0..5c2a68a 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1145,6 +1145,50 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
iommu_domain_free(gmu->domain);
 }
 
+#define A6XX_GMU_FENCED_WRITE_SLEEP_US 10 /* Sleep time between reads in us */
+#define A6XX_GMU_FENCED_WRITE_TIMEOUT  600 /* Timeout in us */
+int a6xx_gmu_fenced_write(struct a6xx_gpu *a6xx_gpu, unsigned int reg,
+   unsigned int value, unsigned int fence_mask)
+{
+   struct a6xx_gmu *gmu = _gpu->gmu;
+   struct adreno_gpu *adreno_gpu = _gpu->base;
+   struct msm_gpu *gpu = _gpu->base;
+   unsigned int status;
+   ktime_t timeout = ktime_add_us(ktime_get(),
+   A6XX_GMU_FENCED_WRITE_TIMEOUT);
+
+   /* Write to the GPU register */
+   gpu_write(gpu, reg, value);
+
+   might_sleep_if(A6XX_GMU_FENCED_WRITE_SLEEP_US);
+   for (;;) {
+   status = gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS);
+   /*
+* If no bits of the fence_mask are set in the status, then the
+* write was successful
+*/
+   if (!(status & fence_mask))
+   return 0;
+
+   if (ktime_compare(ktime_get(), timeout) > 0) {
+   /* Timed out, but check one last time */
+   status = gmu_read(gmu, REG_A6XX_GMU_AHB_FENCE_STATUS);
+   if (!(status & fence_mask))
+   return 0;
+
+   break;
+   }
+
+   usleep_range((A6XX_GMU_FENCED_WRITE_SLEEP_US >> 2) + 1,
+   A6XX_GMU_FENCED_WRITE_SLEEP_US);
+
+   /* Try writing again */
+   gpu_write(gpu, reg, value);
+   }
+
+   return -ETIMEDOUT;
+}
+
 int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
 {
struct a6xx_gmu *gmu = _gpu->gmu;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c72434b..b1a80ec 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -151,6 +151,8 @@ bool a6xx_idle(struct msm_gpu *gpu, struct msm_ringbuffer 
*ring)
 
 static void a6xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
 {
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
uint32_t wptr;
unsigned long flags;
 
@@ -167,16 +169,52 @@ static void a6xx_flush(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
/* Make sure everything is posted before making a decision */
mb();
 
-   gpu_write(gpu, REG_A6XX_CP_RB_WPTR, wptr);
+   /* Update HW if this is the current ring and we are not in preempt*/
+   if (a6xx_gpu->cur_ring == ring && !a6xx_in_preempt(a6xx_gpu))
+   gpu_write(gpu, REG_A6XX_CP_RB_WPTR, wptr);
 }
 
 static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx)
 {
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
struct msm_drm_private *priv = gpu->dev->dev_private;
struct msm_ringbuffer *ring = submit->ring;
+   uint64_t scratch_dest = SCRATCH_USER_CTX_IOVA(ring->id, a6xx_gpu);
unsigned int i;
 
+   /*
+* If preemption is enabled, then set the pseudo register for the save
+* sequence
+*/
+   if 

[PATCH 5/6] drm/msm/Adreno: Refactor some preemption code

[Sharat Masetty]

The preemption state machine related code is same across Adreno targets,
so move the common code to a common header file to avoid code
duplication.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 26 ---
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 55 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 26 ---
 drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 55 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   | 54 ++
 5 files changed, 84 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
index 7d71860..45535f7 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
@@ -54,32 +54,6 @@ struct a5xx_gpu {
 #endif
 
 /*
- * In order to do lockless preemption we use a simple state machine to progress
- * through the process.
- *
- * PREEMPT_NONE - no preemption in progress.  Next state START.
- * PREEMPT_START - The trigger is evaulating if preemption is possible. Next
- * states: TRIGGERED, NONE
- * PREEMPT_ABORT - An intermediate state before moving back to NONE. Next
- * state: NONE.
- * PREEMPT_TRIGGERED: A preemption has been executed on the hardware. Next
- * states: FAULTED, PENDING
- * PREEMPT_FAULTED: A preemption timed out (never completed). This will trigger
- * recovery.  Next state: N/A
- * PREEMPT_PENDING: Preemption complete interrupt fired - the callback is
- * checking the success of the operation. Next state: FAULTED, NONE.
- */
-
-enum preempt_state {
-   PREEMPT_NONE = 0,
-   PREEMPT_START,
-   PREEMPT_ABORT,
-   PREEMPT_TRIGGERED,
-   PREEMPT_FAULTED,
-   PREEMPT_PENDING,
-};
-
-/*
  * struct a5xx_preempt_record is a shared buffer between the microcode and the
  * CPU to store the state for preemption. The record itself is much larger
  * (64k) but most of that is used by the CP for storage.
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c 
b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
index 40f4840..faf844b 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
@@ -14,37 +14,6 @@
 #include "msm_gem.h"
 #include "a5xx_gpu.h"
 
-/*
- * Try to transition the preemption state from old to new. Return
- * true on success or false if the original state wasn't 'old'
- */
-static inline bool try_preempt_state(struct a5xx_gpu *a5xx_gpu,
-   enum preempt_state old, enum preempt_state new)
-{
-   enum preempt_state cur = atomic_cmpxchg(_gpu->preempt_state,
-   old, new);
-
-   return (cur == old);
-}
-
-/*
- * Force the preemption state to the specified state.  This is used in cases
- * where the current state is known and won't change
- */
-static inline void set_preempt_state(struct a5xx_gpu *gpu,
-   enum preempt_state new)
-{
-   /*
-* preempt_state may be read by other cores trying to trigger a
-* preemption or in the interrupt handler so barriers are needed
-* before...
-*/
-   smp_mb__before_atomic();
-   atomic_set(>preempt_state, new);
-   /* ... and after*/
-   smp_mb__after_atomic();
-}
-
 /* Write the most recent wptr for the given ring into the hardware */
 static inline void update_wptr(struct msm_gpu *gpu, struct msm_ringbuffer 
*ring)
 {
@@ -89,7 +58,8 @@ static void a5xx_preempt_timer(unsigned long data)
struct drm_device *dev = gpu->dev;
struct msm_drm_private *priv = dev->dev_private;
 
-   if (!try_preempt_state(a5xx_gpu, PREEMPT_TRIGGERED, PREEMPT_FAULTED))
+   if (!adreno_try_preempt_state(_gpu->preempt_state,
+   PREEMPT_TRIGGERED, PREEMPT_FAULTED))
return;
 
dev_err(dev->dev, "%s: preemption timed out\n", gpu->name);
@@ -111,7 +81,8 @@ void a5xx_preempt_trigger(struct msm_gpu *gpu)
 * Try to start preemption by moving from NONE to START. If
 * unsuccessful, a preemption is already in flight
 */
-   if (!try_preempt_state(a5xx_gpu, PREEMPT_NONE, PREEMPT_START))
+   if (!adreno_try_preempt_state(_gpu->preempt_state,
+   PREEMPT_NONE, PREEMPT_START))
return;
 
/* Get the next ring to preempt to */
@@ -134,9 +105,11 @@ void a5xx_preempt_trigger(struct msm_gpu *gpu)
 * and can safely update the write pointer.
 */
 
-   set_preempt_state(a5xx_gpu, PREEMPT_ABORT);
+   adreno_set_preempt_state(_gpu->preempt_state,
+   PREEMPT_ABORT);
update_wptr(gpu, a5xx_gpu->cur_ring);
-   set_preempt_state(a5xx_gpu, PREEMPT_NONE);
+   adreno_set_preempt_state(_gpu->preempt_state,
+   PREEMPT_NONE);
return;
}
 
@@ -156,7 +129,7 @@ void 

[PATCH 4/6] drm/msm/A6xx: Enable preemption for A6xx targets

[Sharat Masetty]

This patch simply increases the number of available ringbuffers,
therefore enabling preemption.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index b1a80ec..e83b066 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1040,7 +1040,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = a6xx_registers;
adreno_gpu->reg_offsets = a6xx_register_offsets;
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
return ERR_PTR(ret);
-- 
1.9.1

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

[PATCH 1/6] drm/msm: Add submitqueue setup and close

[Sharat Masetty]

This patch adds a bit of infrastructure to give the different Adreno
targets the flexibility to setup the submitqueues per their needs.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/msm_gpu.h |  7 +++
 drivers/gpu/drm/msm/msm_submitqueue.c | 15 +--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index b824117..b9b86ef 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -69,6 +69,10 @@ struct msm_gpu_funcs {
int (*debugfs_init)(struct msm_gpu *gpu, struct drm_minor *minor);
 #endif
int (*gpu_busy)(struct msm_gpu *gpu, uint64_t *value);
+   int (*submitqueue_setup)(struct msm_gpu *gpu,
+   struct msm_gpu_submitqueue *queue);
+   void (*submitqueue_close)(struct msm_gpu *gpu,
+   struct msm_gpu_submitqueue *queue);
 };
 
 struct msm_gpu {
@@ -173,6 +177,9 @@ struct msm_gpu_submitqueue {
int faults;
struct list_head node;
struct kref ref;
+   struct msm_gpu *gpu;
+   struct drm_gem_object *bo;
+   uint64_t bo_iova;
 };
 
 static inline void gpu_write(struct msm_gpu *gpu, u32 reg, u32 data)
diff --git a/drivers/gpu/drm/msm/msm_submitqueue.c 
b/drivers/gpu/drm/msm/msm_submitqueue.c
index 5115f75..1e696da 100644
--- a/drivers/gpu/drm/msm/msm_submitqueue.c
+++ b/drivers/gpu/drm/msm/msm_submitqueue.c
@@ -18,6 +18,10 @@ void msm_submitqueue_destroy(struct kref *kref)
 {
struct msm_gpu_submitqueue *queue = container_of(kref,
struct msm_gpu_submitqueue, ref);
+   struct msm_gpu *gpu = queue->gpu;
+
+   if (gpu && gpu->funcs->submitqueue_close)
+   gpu->funcs->submitqueue_close(gpu, queue);
 
kfree(queue);
 }
@@ -65,6 +69,7 @@ int msm_submitqueue_create(struct drm_device *drm, struct 
msm_file_private *ctx,
 {
struct msm_drm_private *priv = drm->dev_private;
struct msm_gpu_submitqueue *queue;
+   struct msm_gpu *gpu = priv->gpu;
 
if (!ctx)
return -ENODEV;
@@ -77,11 +82,14 @@ int msm_submitqueue_create(struct drm_device *drm, struct 
msm_file_private *ctx,
kref_init(>ref);
queue->flags = flags;
 
-   if (priv->gpu) {
-   if (prio >= priv->gpu->nr_rings)
+   if (gpu) {
+   if (prio >= gpu->nr_rings) {
+   kfree(queue);
return -EINVAL;
+   }
 
queue->prio = prio;
+   queue->gpu = gpu;
}
 
write_lock(>queuelock);
@@ -95,6 +103,9 @@ int msm_submitqueue_create(struct drm_device *drm, struct 
msm_file_private *ctx,
 
write_unlock(>queuelock);
 
+   if (gpu && gpu->funcs->submitqueue_setup)
+   gpu->funcs->submitqueue_setup(gpu, queue);
+
return 0;
 }
 
-- 
1.9.1

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

[PATCH 6/6] drm/msm/A6xx: Enable L1 preemption level

[Sharat Masetty]

This patch enables L1 level which is a finer grained preemption
at either a draw call or a bin boundary. The worst case switching
latency is higher in this case but that is a trade off we make for
enabling faster preemption.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_preempt.c 
b/drivers/gpu/drm/msm/adreno/a6xx_preempt.c
index 0d2b612..4e83a4f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_preempt.c
@@ -301,9 +301,17 @@ void a6xx_preempt_init(struct msm_gpu *gpu)
}
 
/* TODO: make this configurable? */
-   a6xx_gpu->preempt_level = 0;
+   /*
+* Use L1 preemption level which is preemption at either the draw call
+* level or the bin boundary level
+*/
+   a6xx_gpu->preempt_level = 1;
a6xx_gpu->uses_gmem = 1;
-   a6xx_gpu->skip_save_restore = 0;
+   /*
+* Skip CP save and restore when preempting between bins, use
+* this only when the preemption level is 1
+*/
+   a6xx_gpu->skip_save_restore = 1;
 
a6xx_gpu->scratch_ptr  = msm_gem_kernel_new(gpu->dev,
gpu->nr_rings * sizeof(uint64_t), MSM_BO_WC,
-- 
1.9.1

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

[PATCH 2/6] drm/msm: Add new PM4 type7 opcodes

[Sharat Masetty]

This patch adds the following two opcodes:

CP_SET_MARKER opcode is a way to tell CP the current mode of GPU
operation(useful if preemption is in use).

CP_SET_PSEUDO_REG opcode will instruct CP to set a bunch of internal
CP registers, again useful for the preemption save/restore sequence.

Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h 
b/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h
index fb605a3..f0fd80e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h
@@ -202,6 +202,8 @@ enum adreno_pm4_type3_packets {
CP_EXEC_CS = 51,
CP_PERFCOUNTER_ACTION = 80,
CP_SMMU_TABLE_UPDATE = 83,
+   CP_SET_MARKER = 101,
+   CP_SET_PSEUDO_REG = 86,
CP_CONTEXT_REG_BUNCH = 92,
CP_YIELD_ENABLE = 28,
CP_SKIP_IB2_ENABLE_GLOBAL = 29,
-- 
1.9.1

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

[PATCH 0/6] Preemption support for A6xx targets

[Sharat Masetty]

This is a revised preemption support patchset follows Jordan's recent
"drm/msm: Add A6XX device support" patch series. Preemption allows the
GPU to switch to a higher priority ringbuffer when one is ready, thereby
improving user experience. A6xx hardware supports various preemption
levels each with different granularities and different switch-out-switch-in
times.

This series starts off by adding basic preemption support for A6xx targets,
leading up to the tip of the stack which enables L1 level preemption.
This is a more fine grained version and faster than the default level.

Sharat Masetty (6):
  drm/msm: Add submitqueue setup and close
  drm/msm: Add new PM4 type7 opcodes
  drm/msm/A6xx: Implement preemption for A6XX targets
  drm/msm/A6xx: Enable preemption for A6xx targets
  drm/msm/Adreno: Refactor some preemption code
  drm/msm/A6xx: Enable L1 preemption level

 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h   |  26 --
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c   |  55 ++---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c   |  44 
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   | 148 ++-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h   | 110 +
 drivers/gpu/drm/msm/adreno/a6xx_preempt.c   | 366 
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  54 
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h |   2 +
 drivers/gpu/drm/msm/msm_gpu.h   |   7 +
 drivers/gpu/drm/msm/msm_submitqueue.c   |  15 +-
 11 files changed, 757 insertions(+), 71 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_preempt.c

--
1.9.1

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

Re: [[RFC]DPU PATCH] drm/msm/dsi: Use one connector for dual DSI mode

[Archit Taneja]

On Friday 02 March 2018 05:57 AM, chand...@codeaurora.org wrote:

On 2018-03-01 07:53, Sean Paul wrote:

On Wed, Feb 28, 2018 at 04:44:49PM -0800, Chandan Uddaraju wrote:

Current DSI driver uses two connectors for dual DSI case even
though we only have one panel. Fix this by implementing one
connector/bridge for dual DSI use case.

Current patch is not yet tested on dual-dsi setup.


This seems like something that might benefit from being part of a 
patch series
that can be tested end-to-end (ie: a patch series to add full dual-dsi 
support
to the dsi driver). It's kind of hard to see where things are going 
with just

this one small piece.



This is more like a initial patch to get early comments/suggestions
regarding this approach on the DSI upstream driver.
We are working on enabling dual-dsi using DPU with upstream dsi driver.
This change will be based on archit's dual DSI changes on SDM845.
Once we have verified, we will post all the relevant patches along with 
this one.


The approach of entirely bypassing msm_dsi_modeset_init() for DSI1 
sounds like a decent idea. However, this may not work well if we need to 
dynamically switch between dual DSI mode vs operating the 2 DSIs

independently. If we don't have this use case in mind, then we should
be okay.

Another approach could be to create 2 separate bridge/connectors for
irrespective of whether we are in dual DSI mode or not, but report one
of the pairs as unavailable (connector's detect() should report 
disconnected).






Signed-off-by: Chandan Uddaraju 
---
 drivers/gpu/drm/msm/dsi/dsi.c |   3 +
 drivers/gpu/drm/msm/dsi/dsi.h |   1 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 100 
+++---

 3 files changed, 24 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c 
b/drivers/gpu/drm/msm/dsi/dsi.c

index b744bcc..ff8164c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,6 +208,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, 
struct drm_device *dev,

 goto fail;
 }

+    if (!msm_dsi_manager_validate_current_config(msm_dsi->id))
+    goto fail;
+
 msm_dsi->encoder = encoder;

 msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h 
b/drivers/gpu/drm/msm/dsi/dsi.h

index 70d9a9a..2d9763f 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -100,6 +100,7 @@ struct msm_dsi {
 void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
 int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
 void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
+bool msm_dsi_manager_validate_current_config(u8 id);

 /* msm dsi */
 static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c

index 4cb1cb6..bf92f25 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -305,67 +305,6 @@ static void dsi_mgr_connector_destroy(struct 
drm_connector *connector)

 kfree(dsi_connector);
 }

-static void dsi_dual_connector_fix_modes(struct drm_connector 
*connector)

-{
-    struct drm_display_mode *mode, *m;
-
-    /* Only support left-right mode */
-    list_for_each_entry_safe(mode, m, >probed_modes, head) {
-    mode->clock >>= 1;
-    mode->hdisplay >>= 1;
-    mode->hsync_start >>= 1;
-    mode->hsync_end >>= 1;
-    mode->htotal >>= 1;
-    drm_mode_set_name(mode);
-    }
-}
-
-static int dsi_dual_connector_tile_init(
-    struct drm_connector *connector, int id)
-{
-    struct drm_display_mode *mode;
-    /* Fake topology id */
-    char topo_id[8] = {'M', 'S', 'M', 'D', 'U', 'D', 'S', 'I'};
-
-    if (connector->tile_group) {
-    DBG("Tile property has been initialized");
-    return 0;
-    }
-
-    /* Use the first mode only for now */
-    mode = list_first_entry(>probed_modes,
-    struct drm_display_mode,
-    head);
-    if (!mode)
-    return -EINVAL;
-
-    connector->tile_group = drm_mode_get_tile_group(
-    connector->dev, topo_id);
-    if (!connector->tile_group)
-    connector->tile_group = drm_mode_create_tile_group(
-    connector->dev, topo_id);
-    if (!connector->tile_group) {
-    pr_err("%s: failed to create tile group\n", __func__);
-    return -ENOMEM;
-    }
-
-    connector->has_tile = true;
-    connector->tile_is_single_monitor = true;
-
-    /* mode has been fixed */
-    connector->tile_h_size = mode->hdisplay;
-    connector->tile_v_size = mode->vdisplay;
-
-    /* Only support left-right mode */
-    connector->num_h_tile = 2;
-    connector->num_v_tile = 1;
-
-    connector->tile_v_loc = 0;
-    connector->tile_h_loc = (id == DSI_RIGHT) ? 1 : 0;
-
-    return 0;
-}
-
 static int dsi_mgr_connector_get_modes(struct drm_connector 

Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

[Inki Dae]

Hi Sylwester,

2018년 03월 08일 02:11에 Sylwester Nawrocki 이(가) 쓴 글:
> The #sound-dai-cells DT property is required to describe link between
> the HDMI IP block and the SoC's audio subsystem.
> 
> Signed-off-by: Sylwester Nawrocki 
> ---
>  Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
> index 8715ff06c457..6b2a526ec586 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
> @@ -50,6 +50,9 @@ Required properties for Exynos 5433:
>  - clock-names: aliases for above clock specfiers.
>  - samsung,sysreg: handle to syscon used to control the system registers.
>  
> +Optional properties for Exynos 4210, 4212, 5420 and 5433:
> + - #sound-dai-cells: should be 0.
> +

Just trivial question. 'sound-dai-cells' property could affect hdmi driver? I 
looked into HDMI codec driver but I didn't find relevat code.
I mean that if this property never affect HDMI driver then this property would 
be a dead thing even through this can be declared optionally.

Thanks,
Inki Dae

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

Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

[Rob Herring]

On Wed, Mar 07, 2018 at 06:11:11PM +0100, Sylwester Nawrocki wrote:
> The #sound-dai-cells DT property is required to describe link between
> the HDMI IP block and the SoC's audio subsystem.
> 
> Signed-off-by: Sylwester Nawrocki 
> ---
>  Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring 

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

[Bug 28433] Mesa DRI Intel 845G GEM Drivers returning artifacts in textures that can lockup PC on glxSwapBuffers.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28433

Timothy Arceri  changed:

   What|Removed |Added

  Component|Other   |Drivers/DRI/i915
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

--- Comment #3 from Timothy Arceri  ---
Reassigning to i915. Probably needs to be retested.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/vgem: Add space around operators

[Rodrigo Siqueira]

This patch fixes the checkpatch.pl check and warning:

vgem_fence.c:28: CHECK: spaces preferred around that '*' (ctx:VxV)
vgem_drv.c:255: CHECK: spaces preferred around that '|' (ctx:VxV)
vgem_drv.c:256: WARNING: line over 80 characters

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vgem/vgem_drv.c   | 8 ++--
 drivers/gpu/drm/vgem/vgem_fence.c | 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index bf704ed51da4..6e6084e3204a 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -252,8 +252,12 @@ static int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,
 }
 
 static struct drm_ioctl_desc vgem_ioctls[] = {
-   DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH,
+ vgem_fence_attach_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL,
+ vgem_fence_signal_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
 };
 
 static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index f5b659463b00..d0bcb5fb33d1 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -25,7 +25,7 @@
 
 #include "vgem_drv.h"
 
-#define VGEM_FENCE_TIMEOUT (10*HZ)
+#define VGEM_FENCE_TIMEOUT (10 * HZ)
 
 struct vgem_fence {
struct dma_fence base;
-- 
2.16.2

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

[PATCH 5/5] drm/vgem: Remove '(' from the end of line

[Rodrigo Siqueira]

This patch fixes the checkpatch.pl check:

vgem_drv.c:91: CHECK: Lines should not end with a '('

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 6e6084e3204a..4ddf3b8c3875 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -87,10 +87,10 @@ static int vgem_gem_fault(struct vm_fault *vmf)
mutex_unlock(>pages_lock);
if (ret) {
struct page *page;
+   struct address_space *mapping;
 
-   page = shmem_read_mapping_page(
-   file_inode(obj->base.filp)->i_mapping,
-   page_offset);
+   mapping = file_inode(obj->base.filp)->i_mapping;
+   page = shmem_read_mapping_page(mapping, page_offset);
if (!IS_ERR(page)) {
vmf->page = page;
ret = 0;
-- 
2.16.2

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

[PATCH 3/5] drm/vgem: Replace uint32_t for u32

[Rodrigo Siqueira]

This patch fixes the checkpatch.pl check:

vgem_drv.c:229: CHECK: Prefer kernel type 'u32' over 'uint32_t'

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 5767030d04a8..bf704ed51da4 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -226,7 +226,7 @@ static int vgem_gem_dumb_create(struct drm_file *file, 
struct drm_device *dev,
 }
 
 static int vgem_gem_dumb_map(struct drm_file *file, struct drm_device *dev,
-uint32_t handle, uint64_t *offset)
+u32 handle, uint64_t *offset)
 {
struct drm_gem_object *obj;
int ret;
-- 
2.16.2

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

[PATCH 2/5] drm/vgem: Remove assignment in if condition

[Rodrigo Siqueira]

This patch fixes the checkpatch.pl error:

vgem_fence.c:196: ERROR: do not use assignment in if condition

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vgem/vgem_fence.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index b28876c222b4..f5b659463b00 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -191,10 +191,13 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
/* Expose the fence via the dma-buf */
ret = 0;
reservation_object_lock(resv, NULL);
-   if (arg->flags & VGEM_FENCE_WRITE)
+   if (arg->flags & VGEM_FENCE_WRITE) {
reservation_object_add_excl_fence(resv, fence);
-   else if ((ret = reservation_object_reserve_shared(resv)) == 0)
-   reservation_object_add_shared_fence(resv, fence);
+   } else {
+   ret = reservation_object_reserve_shared(resv);
+   if (!ret)
+   reservation_object_add_shared_fence(resv, fence);
+   }
reservation_object_unlock(resv);
 
/* Record the fence in our idr for later signaling */
-- 
2.16.2

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

[PATCH 0/5] drm/vgem: Checkpatch cleanup for vgem

[Rodrigo Siqueira]

This patchset fixes warnings and errors found by checkpatch.pl in the
drm/vgem:

* Removes assignment in if condition;
* Removes '(' from the end of line;
* Adds spaces around operators;
* Replaces uint32_t for u32;
* Indents switch and case at the same level.

Rodrigo Siqueira (5):
  drm/vgem: Indent switch and case at the same level
  drm/vgem: Remove assignment in if condition
  drm/vgem: Replace uint32_t for u32
  drm/vgem: Add space around operators
  drm/vgem: Remove '(' from the end of line

 drivers/gpu/drm/vgem/vgem_drv.c   | 21 +
 drivers/gpu/drm/vgem/vgem_fence.c | 11 +++
 2 files changed, 20 insertions(+), 12 deletions(-)

-- 
2.16.2

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

[PATCH 1/5] drm/vgem: Indent switch and case at the same level

[Rodrigo Siqueira]

This patch fixes the checkpatch.pl errors:

vgem_drv.c:97: ERROR: switch and case should be at the same indent
vgem_drv.c:97: ERROR: trailing statements should be on next line

Signed-off-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 2524ff116f00..5767030d04a8 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -94,7 +94,8 @@ static int vgem_gem_fault(struct vm_fault *vmf)
if (!IS_ERR(page)) {
vmf->page = page;
ret = 0;
-   } else switch (PTR_ERR(page)) {
+   } else {
+   switch (PTR_ERR(page)) {
case -ENOSPC:
case -ENOMEM:
ret = VM_FAULT_OOM;
@@ -110,8 +111,8 @@ static int vgem_gem_fault(struct vm_fault *vmf)
WARN_ON(PTR_ERR(page));
ret = VM_FAULT_SIGBUS;
break;
+   }
}
-
}
return ret;
 }
-- 
2.16.2

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

linux-next: manual merge of the drm tree with the drm-misc-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/sun4i/sun4i_tcon.c

between commit:

  e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")

from the drm-misc-fixes tree and commit:

  34d698f6e349 ("drm/sun4i: Add has_channel_0 TCON quirk")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2de586b7c98b,0d6c5ed44795..
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@@ -1143,11 -1155,15 +1164,16 @@@ static const struct sun4i_tcon_quirks s
  };
  
  static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
+   .has_channel_0  = true,
 +  .supports_lvds  = true,
  };
  
+ static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
+   .has_channel_1  = true,
+ };
+ 
  static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
-   /* nothing is supported */
+   .has_channel_0  = true,
  };
  
  /* sun4i_drv uses this list to check if a device node is a TCON */


pgpH63NIQjBfg.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98856] DIRT: Showdown broken graphics with Mesa built with -Ofast

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98856

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #10 from Timothy Arceri  ---
Ofast disregards strict standards compliance. -Ofast enables all -O3
optimizations. It also enables optimizations that are not valid for all
standard-compliant programs.

In other words don't use it with Mesa :)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..cdb04c9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..1269ef8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DP_REV_10  0x10
+# define DP_REV_11  0x11
+# define DP_REV_12  0x12
+# define DP_REV_13  0x13
+# define DP_REV_14  0x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

[Bug 104717] Rocket League: grass rendering broken with nir

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104717

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Timothy Arceri  ---
This should be fixed by:

commit 0c90264da4139805d34f530485a678c53809932e
Author: Timothy Arceri 
Date:   Thu Mar 8 09:46:42 2018 +1100

ac/radeonsi: add emit_kill to the abi

This should fix a regression with Rocket League grass rendering
on the NIR backend.

Reviewed-by: Marek Olšák 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104717

If you are still having problems feel free to reopen the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..6985ff3 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4)
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..1269ef8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DP_REV_10  0x10
+# define DP_REV_11  0x11
+# define DP_REV_12  0x12
+# define DP_REV_13  0x13
+# define DP_REV_14  0x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Manasi Navare]

On Wed, Mar 07, 2018 at 03:44:09PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  4 
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..671b823 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);

I thought there were comments about setting this to a max of 4 if its greater
than 4.

> +
> + if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))
 ^ space needed between if and open bracket

>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4)
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);
> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..5bac397 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,9 @@
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> +# define DP_REV_12  0x012
> +# define DP_REV_13  0x013
> +# define DP_REV_14  0x014
>

IMHO, if we are creating these #defines for revisions then we should
do it for all values so 0x10, 0x11.

Manasi
  
>  #define DP_MAX_LINK_RATE0x001
>  
> @@ -118,6 +121,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue

[akpm]

From: Andrew Morton 
Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union 
initializer issue

gcc-4.4.4 has problems with initalizers of anon unions.

drivers/gpu/drm/i915/intel_guc_log.c: In function 'guc_log_control':
drivers/gpu/drm/i915/intel_guc_log.c:64: error: unknown field 'logging_enabled' 
specified in initializer

Work around this.

Fixes: 35fe703c3161 ("drm/i915/guc: Change values for i915_guc_log_control")
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Signed-off-by: Andrew Morton 
---

 drivers/gpu/drm/i915/intel_guc_log.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff -puN 
drivers/gpu/drm/i915/intel_guc_log.c~drivers-gpu-drm-i915-intel_guc_logc-work-around-gcc-444-union-initializer-issue
 drivers/gpu/drm/i915/intel_guc_log.c
--- 
a/drivers/gpu/drm/i915/intel_guc_log.c~drivers-gpu-drm-i915-intel_guc_logc-work-around-gcc-444-union-initializer-issue
+++ a/drivers/gpu/drm/i915/intel_guc_log.c
@@ -61,8 +61,10 @@ static int guc_log_flush(struct intel_gu
 static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
 {
union guc_log_control control_val = {
-   .logging_enabled = enable,
-   .verbosity = verbosity,
+   {
+   .logging_enabled = enable,
+   .verbosity = verbosity,
+   },
};
u32 action[] = {
INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING,
_
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Ilia Mirkin]

On Wed, Mar 7, 2018 at 6:44 PM,   wrote:
> From: Matt Atwood 
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
>
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  4 
>  2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..671b823 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> +   if (rd_interval > 4)
> +   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);
> +
> +   if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))

Was this meant to be dpcd[DP_DPCD_REV] >= DP_REV_14? It doesn't appear
to be a bitmask...

Also I think you're supposed to say "if (" rather than "if(".

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

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  4 
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..671b823 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4)
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..5bac397 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,9 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DP_REV_12  0x012
+# define DP_REV_13  0x013
+# define DP_REV_14  0x014
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +121,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199047

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Does it work with DC enabled?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104717] Rocket League: grass rendering broken with nir

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104717

--- Comment #3 from Timothy Arceri  ---
This series should fix the regression. Thanks for reporting it.

https://patchwork.freedesktop.org/series/39565/

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199047

--- Comment #3 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
Created attachment 274617
  --> https://bugzilla.kernel.org/attachment.cgi?id=274617=edit
dmesg.log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199047

--- Comment #2 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
(In reply to Alex Deucher from comment #1)
> Are you using DC?  Please attach your dmesg output.

Not using DC. dmesg after a S3 suspend/resume cycle attached

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon, amdgpu, ttm drm-next-4.17

[Alex Deucher]

Hi Dave,

More stuff for 4.17. Highlights:
- More fixes for "wattman" like functionality (fine grained clk/voltage control)
- Add more power profile infrastucture (context based dpm)
- SR-IOV fixes
- Add iomem debugging interface for use with umr
- Powerplay and cgs cleanups
- DC fixes and cleanups
- ttm improvements
- Misc cleanups all over

The following changes since commit 9aff8b2ae71dcf7f02443821a894a736f40e4919:

  Revert "drm/radeon/pm: autoswitch power state when in balanced mode" 
(2018-02-20 16:27:16 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.17

for you to fetch changes up to f6c3b601bd490eda08c27b03607448abd4b4841b:

  drm/amdgpu:Always save uvd vcpu_bo in VM Mode (2018-03-07 16:12:18 -0500)


Alex Deucher (5):
  drm/amdgpu/powerplay/smu7: use proper dep table for mclk
  drm/amdgpu: fix module parameter descriptions
  drm/amdgpu: used cached pcie gen info for SI (v2)
  drm/radeon: fix KV harvesting
  drm/amdgpu: fix KV harvesting

Amber Lin (1):
  drm/amdgpu: Map all visible VRAM at startup

Arnd Bergmann (1):
  radeon: hide pointless #warning when compile testing

Ben Crocker (1):
  drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

Bhawanpreet Lakha (2):
  drm/amd/display: Use MACROS instead of dm_logger
  drm/amd/display: define DC_LOGGER for logger

Christian König (25):
  drm/ttm: set page mapping during allocation
  drm/amdgpu: use the TTM dummy page instead of allocating one
  drm/ttm: add default implementations for ttm_tt_(un)populate
  drm/virtio: remove ttm_pool_* wrappers
  drm/mgag200: remove ttm_pool_* wrappers
  drm/hisilicon: remove ttm_pool_* wrappers
  drm/ast: remove ttm_pool_* wrappers
  drm/qxl: remove ttm_pool_* wrappers
  drm/cirrus: remove ttm_pool_* wrappers
  drm/bochs: remove the default ttm_tt_populate callbacks
  staging: vboxvideo: remove ttm_pool_* wrappers
  drm/ttm: drop bo->glob
  drm/ttm: drop ttm->glob
  drm/ttm: drop ttm->dummy_read_page
  drm/ttm: drop persistent_swap_storage from ttm_bo_init and co
  drm/ttm: move ttm_tt_create into ttm_tt.c v2
  drm/ttm: cleanup ttm_tt_create
  drm/amdgpu: move some functions into amdgpu_ttm.h
  drm/amdgpu: change amdgpu_ttm_set_active_vram_size
  drm/amdgpu: ignore changes of buffer function status because of GPU resets
  drm/amdgpu: use separate status for buffer funcs availability v2
  drm/amd/pp: fix "Delete the wrapper layer of smu_allocate/free_memory"
  drm/amdgpu: add amdgpu_evict_gtt debugfs entry
  drm/amdgpu: drop gtt->adev
  drm/amdgpu: further mitigate workaround for i915

Corentin Labbe (2):
  drm/amd: remove inclusion of non-existing scheduler directory
  drm/amd: Remove inclusion of non-existing include directories

Dmytro Laktyushkin (4):
  drm/amd/display: Update DCN OPTC registers
  drm/amd/display: add per pipe dppclk
  drm/amd/display: add diags clock programming
  drm/amd/display: fix dcn1 dppclk when min dispclk patch applies

Emily Deng (2):
  drm/amdgpu: Correct sdma_v4 get_wptr(v2)
  drm/amdgpu: Clean sdma wptr register when only enable wptr polling

Eric Bernstein (1):
  drm/amd/display: Fix DAL surface change test

Eric Huang (2):
  drm/amd/powerplay: fix thermal interrupts on vega10
  drm/amd/powerplay: fix power over limit on Fiji

Eric Yang (2):
  drm/amd/display: fix missing az disable in reset backend
  drm/amd/display: update infoframe after dig fe is turned on

Harry Wentland (6):
  drm/amd/display: Remove duplicate dm_pp_power_level enum
  drm/amd/display: Use crtc enable/disable_vblank hooks
  drm/amd/display: Return success when enabling interrupt
  drm/amd/display: Clean up formatting in irq_service_dce110.c
  drm/amd/display: Don't blow up if TG is NULL in dce110_vblank_set
  drm/amd/display: Default HDMI6G support to true. Log VBIOS table error.

Hersen Wu (2):
  drm/amd/display: move MST branch initialize to before link training
  drm/amd/display: Check DCN PState ASSERT failure

James Zhu (3):
  drm/amdgpu:Fixed wrong emit frame size for enc
  drm/amdgpu:Correct max uvd handles
  drm/amdgpu:Always save uvd vcpu_bo in VM Mode

John Barberiz (1):
  drm/amd/display: Add passive dongle support for HPD Rearch

Leo (Sunpeng) Li (2):
  drm/amd/display: Use 4096 lut entries
  drm/amd/display: Add regamma lut write mask to SOC base

Matthias Kaehlcke (1):
  drm/radeon/mkregtable: Delete unused list functions and macros

Michel Dänzer (1):
  drm/amdgpu/dce6: Use DRM_DEBUG instead of DRM_INFO for HPD IRQ info

Monk Liu (15):
  drm/amdgpu: fix for wb_clear
  drm/amdgpu: skip ECC for SRIOV in gmc late_init
  drm/amdgpu: only flush hotplug work without DC
  drm/amdgpu: cond_exec only for 

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102553

--- Comment #8 from mercuriete  ---
Thanks you for the response.

I created a very ugly workaround that WORKS_FOR_ME

I need to read the link that you provided me to learn how to debug that stack
trace.
I think in a few days I'll have more time to spend.

Thank you very much.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102553

--- Comment #7 from mercuriete  ---
Created attachment 137877
  --> https://bugs.freedesktop.org/attachment.cgi?id=137877=edit
very ugly patch LOL

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Manasi Navare]

On Wed, Mar 07, 2018 at 02:06:08PM -0800, Rodrigo Vivi wrote:
> On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> > > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
> > > > 
> > > > 
> > > > 
> > > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com 
> > > > > wrote:
> > > > > > From: Matt Atwood 
> > > > > > 
> > > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme 
> > > > > > from 8
> > > > > > bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, 
> > > > > > for
> > > > > > panels that use this new feature, this would cause a wait interval 
> > > > > > for
> > > > > > clock recovery of at least 512 ms, much higher then spec maximum of 
> > > > > > 16 ms.
> > > > > > This behavior is described in table 2-158 of DP 1.4 spec address 
> > > > > > Eh.
> > > > > > To avoid breaking panels 
> > > > 
> > > > See comment below:
> > > > 
> > > > > that are not spec compliant we now warn on
> > > > > > invalid values.
> > > > > > 
> > > > > > V2: commit title/message, masking all 7 bits, warn on out of spec 
> > > > > > values.
> > > > > 
> > > > > this approach is even better imho.
> > > > > 
> > > > > > 
> > > > > > Signed-off-by: Matt Atwood 
> > > > > 
> > > > > Reviewed-by: Rodrigo Vivi 
> > > > > 
> > > > > > ---
> > > > > >  drivers/gpu/drm/drm_dp_helper.c | 18 ++
> > > > > >  include/drm/drm_dp_helper.h |  1 +
> > > > > >  2 files changed, 15 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > > > index adf79be..a718ccc 100644
> > > > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > > > @@ -119,18 +119,28 @@ u8 
> > > > > > drm_dp_get_adjust_request_pre_emphasis(const u8 
> > > > > > link_status[DP_LINK_STATUS_SI
> > > > > >  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> > > > > >  
> > > > > >  void drm_dp_link_train_clock_recovery_delay(const u8 
> > > > > > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > > > > > -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > > > > > +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> > > > > > DP_TRAINING_AUX_RD_MASK;
> > > > > > +
> > > > > > +   if (rd_interval > 4)
> > > > > > +   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> > > > > > rd_interval);
> > > > 
> > > > Some default for panels without a valid value?
> > > > rd_interval = 4;
> > > > "AUX read interval out of range, using max %d ms"
> > > >
> > > 
> > > The problem with setting the upper bound to 4 is that there are panels
> > > that do not follow the spec and expect a longer than 16 ms delay. So
> > > if we set the upper bound to 4 in those cases the panels might not work.
> > > 
> > > So we decided to go with this approach where we tell the users that panel 
> > > is requesting
> > > out of range AUX value but then set it to the value * 4 in the else part.
> > > 
> > 
> > Thanks for the clarification. My concern is if the DPCD is advertizing
> > an out of spec value, it might as well be advertizing a delay that the
> > panel doesn't need. And I thought panel quirks were supposed to be used
> > for working around things like this. To be clear, this is not a big
> > enough concern to block this fix.
> > 
> > Like I said in the other email, this patch refers to DP 1.4, shouldn't
> > the clock recovery delay be updated too (in a separate patch)?
> 
> We clearly need more work here.
> 
> I can see here on DP-v1.2a_d11:
> 
> 00h = 100us for the Main Link Clock Recovery phase 400us for the Main Link 
> Channel
> Equalization phase and for FAUX training.
> 01h = 4ms all.
> 02h = 8ms all.
> 03h = 12ms all.
> 04h = 16ms all.
> 
> So probably the initial mask on this patch should be marked with /* XXX 1.2? 
> */
> because it clearly got introduced in some 1.2 minor release.
> 
> But even for DP 1.2 it doesn't seem we are doing it right on the 0 case.
> It seems that we are using 100us for both channel eq and clock recovery, 
> right?
> or am I missing something?
> 
> Then DP 1.3 keeps same config.
> 
> But DP 1.4 change all values.
> 
> clock recovery is always 100us and channel eq is depending on this bit * 4 
> and 400us when bit is zeroed.
> 
> But limited to 4.
> 
> So we probably need 3 patches here:
> 1. - This one to protect against bad panels masking it and mentioning DP 1.2,
>  nor 1.3 or 1.4. Also limiting rd_interval to 4 as DK suggested. Panels 
> cannot
>  expect all drivers are using this value * 4 blindly since it is not on 
> spec.

So if some panels still expect a greater delay, those will fail link training. 
But
yes if we want them to be 

[pull] radeon and amdgpu drm-fixes-4.16

[Alex Deucher]

Hi Dave,

Fixes for 4.16.  A bit bigger than I would have liked, but most of that
is DC fixes which Harry helped me pull together from the past few weeks.
Highlights:
- Fix DL DVI with DC
- Various RV fixes for DC
- Overlay fixes for DC
- Fix HDMI2 handling on boards without HBR tables in the vbios
- Fix crash with pass-through on SI on amdgpu
- Fix RB harvesting on KV
- Fix hibernation failures on UVD with certain cards

The following changes since commit 93dfdf9fde9f20f1c46738bf184adeebc7d7d66e:

  Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2018-03-01 14:03:14 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.16

for you to fetch changes up to 4a53d9045ec31f3f97719c2e41cc8b2e7151a1fe:

  drm/amd/display: validate plane format on primary plane (2018-03-07 16:31:19 
-0500)


Alex Deucher (3):
  drm/amdgpu: used cached pcie gen info for SI (v2)
  drm/radeon: fix KV harvesting
  drm/amdgpu: fix KV harvesting

Bhawanpreet Lakha (1):
  drm/amd/display: Fix takover from VGA mode

Eric Yang (3):
  drm/amd/display: fix cursor related Pstate hang
  drm/amd/display: update infoframe after dig fe is turned on
  drm/amd/display: early return if not in vga mode in disable_vga

Harry Wentland (11):
  drm/amd/display: Don't blow up if TG is NULL in dce110_vblank_set
  drm/amd/display: Default HDMI6G support to true. Log VBIOS table error.
  drm/amd/display: Move MAX_TMDS_CLOCK define to header
  drm/amd/display: Remove unnecessary fail labels in create_stream_for_sink
  drm/amd/display: Pass signal directly to enable_tmds_output
  drm/amd/display: Don't allow dual-link DVI on all ASICs.
  drm/amd/display: Don't block dual-link DVI modes
  drm/amd/display: Make create_stream_for_sink more consistent
  drm/amd/display: Call update_stream_signal directly from amdgpu_dm
  drm/amd/display: Use crtc enable/disable_vblank hooks
  drm/amd/display: Return success when enabling interrupt

James Zhu (2):
  drm/amdgpu:Correct max uvd handles
  drm/amdgpu:Always save uvd vcpu_bo in VM Mode

Jerry (Fangzhi) Zuo (2):
  drm/amd/display: Fix topology change issue in MST rehook
  drm/amd/display: Fixed non-native modes not lighting up

Leo (Sunpeng) Li (1):
  drm/amd/display: Fix memleaks when atomic check fails.

Michel Dänzer (1):
  drm/amdgpu/dce6: Use DRM_DEBUG instead of DRM_INFO for HPD IRQ info

Mikita Lipski (1):
  drm/amd/display: Set irq state only on existing crtcs

Rex Zhu (1):
  drm/amdgpu: Notify sbios device ready before send request

Roman Li (3):
  drm/amd/display: Fix active dongle hotplug
  drm/amd/display: Fix FBC topology change
  drm/amd/display: fix boot-up on vega10

Shirish S (5):
  drm/amd/display: defer modeset check in dm_update_planes_state
  drm/amd/display: validate plane in dce110 for scaling
  drm/amd/display: update plane params before validation
  drm/amd/display: disable CRTCs with NULL FB on their primary plane (V2)
  drm/amd/display: validate plane format on primary plane

Tom St Denis (1):
  drm/amd/amdgpu: Mask rptr as well in ring debugfs

 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  13 +-
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |   2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  30 +---
 drivers/gpu/drm/amd/amdgpu/si.c|  22 ++-
 drivers/gpu/drm/amd/amdgpu/si_dpm.c|  50 ++-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 165 +++--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  |   6 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|   6 +
 drivers/gpu/drm/amd/display/dc/core/dc.c   |   6 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |   3 +-
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |   3 -
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c|  76 +-
 drivers/gpu/drm/amd/display/dc/dc.h|   3 +-
 drivers/gpu/drm/amd/display/dc/dc_stream.h |   2 +
 drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h |  10 +-
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.c  |  38 +++--
 .../gpu/drm/amd/display/dc/dce/dce_link_encoder.h  |   3 +-
 .../drm/amd/display/dc/dce100/dce100_resource.c|   1 +
 .../amd/display/dc/dce110/dce110_hw_sequencer.c|  91 ++--
 .../drm/amd/display/dc/dce110/dce110_resource.c|  18 +++
 .../drm/amd/display/dc/dce112/dce112_resource.c|   2 +
 .../drm/amd/display/dc/dce120/dce120_resource.c|   2 +
 .../gpu/drm/amd/display/dc/dce80/dce80_resource.c  |   1 +
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  |  65 +++-
 .../gpu/drm/amd/display/dc/inc/hw/link_encoder.h   |  

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
> > > 
> > > 
> > > 
> > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com 
> > > > wrote:
> > > > > From: Matt Atwood 
> > > > > 
> > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8
> > > > > bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, 
> > > > > for
> > > > > panels that use this new feature, this would cause a wait interval for
> > > > > clock recovery of at least 512 ms, much higher then spec maximum of 
> > > > > 16 ms.
> > > > > This behavior is described in table 2-158 of DP 1.4 spec address 
> > > > > Eh.
> > > > > To avoid breaking panels 
> > > 
> > > See comment below:
> > > 
> > > > that are not spec compliant we now warn on
> > > > > invalid values.
> > > > > 
> > > > > V2: commit title/message, masking all 7 bits, warn on out of spec 
> > > > > values.
> > > > 
> > > > this approach is even better imho.
> > > > 
> > > > > 
> > > > > Signed-off-by: Matt Atwood 
> > > > 
> > > > Reviewed-by: Rodrigo Vivi 
> > > > 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_dp_helper.c | 18 ++
> > > > >  include/drm/drm_dp_helper.h |  1 +
> > > > >  2 files changed, 15 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > > index adf79be..a718ccc 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > > @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const 
> > > > > u8 link_status[DP_LINK_STATUS_SI
> > > > >  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> > > > >  
> > > > >  void drm_dp_link_train_clock_recovery_delay(const u8 
> > > > > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > > > > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > > > > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> > > > > DP_TRAINING_AUX_RD_MASK;
> > > > > +
> > > > > + if (rd_interval > 4)
> > > > > + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> > > > > rd_interval);
> > > 
> > > Some default for panels without a valid value?
> > >   rd_interval = 4;
> > >   "AUX read interval out of range, using max %d ms"
> > >
> > 
> > The problem with setting the upper bound to 4 is that there are panels
> > that do not follow the spec and expect a longer than 16 ms delay. So
> > if we set the upper bound to 4 in those cases the panels might not work.
> > 
> > So we decided to go with this approach where we tell the users that panel 
> > is requesting
> > out of range AUX value but then set it to the value * 4 in the else part.
> > 
> 
> Thanks for the clarification. My concern is if the DPCD is advertizing
> an out of spec value, it might as well be advertizing a delay that the
> panel doesn't need. And I thought panel quirks were supposed to be used
> for working around things like this. To be clear, this is not a big
> enough concern to block this fix.
> 
> Like I said in the other email, this patch refers to DP 1.4, shouldn't
> the clock recovery delay be updated too (in a separate patch)?

We clearly need more work here.

I can see here on DP-v1.2a_d11:

00h = 100us for the Main Link Clock Recovery phase 400us for the Main Link 
Channel
Equalization phase and for FAUX training.
01h = 4ms all.
02h = 8ms all.
03h = 12ms all.
04h = 16ms all.

So probably the initial mask on this patch should be marked with /* XXX 1.2? */
because it clearly got introduced in some 1.2 minor release.

But even for DP 1.2 it doesn't seem we are doing it right on the 0 case.
It seems that we are using 100us for both channel eq and clock recovery, right?
or am I missing something?

Then DP 1.3 keeps same config.

But DP 1.4 change all values.

clock recovery is always 100us and channel eq is depending on this bit * 4 and 
400us when bit is zeroed.

But limited to 4.

So we probably need 3 patches here:
1. - This one to protect against bad panels masking it and mentioning DP 1.2,
 nor 1.3 or 1.4. Also limiting rd_interval to 4 as DK suggested. Panels 
cannot
 expect all drivers are using this value * 4 blindly since it is not on 
spec.
2. - Fix channel eq for 0 case since 1.2. It should be 400us.
3. - For DP version >= 1.4 always use 100us for clock req or follow this 
register for
 channel eq.

Thoughts?

> 
> 
> > Manasi
> >  
> > > 
> > > > > +
> > > > > + if (rd_interval == 0)
> > > > >   udelay(100);
> > > > >   else
> > > > > - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > > > > + mdelay(rd_interval * 4);
> > > > >  }
> > > 

[PATCH v5] drm/pl111: Use max memory bandwidth for resolution

[Linus Walleij]

We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.

This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.

Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v4->v5:
- Rebase on top of drm-next and resend so the patch
  applies and produce a reasonable link. I have no clue
  why patch does not apply, it looks like it should, but
  the git moves in mysterious ways.
ChangeLog v3->v4:
- Switch the noisy DRM_INFO for DRM_DEBUG_KMS
- Collect Eric's review tag
ChangeLog v2->v3:
- Account for the case where there is no bandwidth limitation
  so priv->memory_bw is zero. Then just accept any modes.
ChangeLog v1->v2:
- Exploit the new .mode_valid() callback we added to the
  simple KMS helper.
- Use the hardcoded bits per pixel per variant instead of
  trying to be heuristic about this setting for now.
---
 drivers/gpu/drm/pl111/pl111_display.c | 36 +++
 drivers/gpu/drm/pl111/pl111_drm.h |  1 +
 drivers/gpu/drm/pl111/pl111_drv.c |  6 ++
 3 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 5b8368c76734..310646427907 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
return status;
 }
 
+static enum drm_mode_status
+pl111_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+   struct drm_device *drm = crtc->dev;
+   struct pl111_drm_dev_private *priv = drm->dev_private;
+   u32 cpp = priv->variant->fb_bpp / 8;
+   u64 bw;
+
+   /*
+* We use the pixelclock to also account for interlaced modes, the
+* resulting bandwidth is in bytes per second.
+*/
+   bw = mode->clock * 1000; /* In Hz */
+   bw = bw * mode->hdisplay * mode->vdisplay * cpp;
+   bw = div_u64(bw, mode->htotal * mode->vtotal);
+
+   /*
+* If no bandwidth constraints, anything goes, else
+* check if we are too fast.
+*/
+   if (priv->memory_bw && (bw > priv->memory_bw)) {
+   DRM_DEBUG_KMS("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
+ mode->hdisplay, mode->vdisplay,
+ mode->clock * 1000, cpp, bw);
+
+   return MODE_BAD;
+   }
+   DRM_DEBUG_KMS("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
+ mode->hdisplay, mode->vdisplay,
+ mode->clock * 1000, cpp, bw);
+
+   return MODE_OK;
+}
+
 static int pl111_display_check(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *pstate,
   struct drm_crtc_state *cstate)
@@ -348,6 +383,7 @@ static int pl111_display_prepare_fb(struct 
drm_simple_display_pipe *pipe,
 }
 
 static struct drm_simple_display_pipe_funcs pl111_display_funcs = {
+   .mode_valid = pl111_mode_valid,
.check = pl111_display_check,
.enable = pl111_display_enable,
.disable = pl111_display_disable,
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index 2a93e0134061..8639b2d4ddf7 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -65,6 +65,7 @@ struct pl111_drm_dev_private {
struct drm_simple_display_pipe pipe;
 
void *regs;
+   u32 memory_bw;
u32 ienb;
u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index e92a406c9ea9..4621259d5387 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -257,6 +257,12 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
drm->dev_private = priv;
priv->variant = variant;
 
+   if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
+>memory_bw)) {
+   dev_info(dev, "no max memory bandwidth specified, assume 
unlimited\n");
+   priv->memory_bw = 0;
+   }
+
/* The two variants swap this register */
if (variant->is_pl110) {
priv->ienb = CLCD_PL110_IENB;
-- 
2.14.3

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

[Bug 104717] Rocket League: grass rendering broken with nir

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104717

Gregor Münch  changed:

   What|Removed |Added

 CC||t_arc...@yahoo.com.au

--- Comment #2 from Gregor Münch  ---
Looks like the assigning didnt work?
Did that now, I hope you dont mind.

Honestly I dont understand why Intel isnt affected. As far as I understood the
old problem: mesa basically treats OpenGL spec right but nvidia was faster
implementing it thus created a de-facto standard.
Now porting companys agree its wrong but dont want to change treatment because
80% of their users using nvidia binary blob.
To circumvent the problem, a override was created. Fixing the issue for radeon.
I mean, I understand that the RadeonSI NIR port doesnt respect the dri override
yet. But I dont understand that Intel isnt using the dri override at all. Which
would mean that if Intel treats the opengl spec in the same way like RadeonSI
did but doesnt make use of the override, the problems in those games still
appear for Intel users.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105390] Requesting a new account for IGT

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105390

Bug ID: 105390
   Summary: Requesting a new account for IGT
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: michal.winiar...@intel.com

Created attachment 137876
  --> https://bugs.freedesktop.org/attachment.cgi?id=137876=edit
Keys

Hi.

I'd like to request a new account.

Name: Michał Winiarski
Email: michal.winiar...@intel.com
Account_name: knr

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state (V2)

[Harry Wentland]

On 2018-03-06 10:10 PM, Shirish S wrote:
> Add reverse iterator for_each_oldnew_plane_in_state_reverse to
> compliment the for_each_oldnew_plane_in_state way or reading plane
> states.
> 
> The plane states are required to be read in reverse order for
> amd drivers, cause the z order convention followed in linux is
> opposite to how the planes are supposed to be presented to DC
> engine, which is in common to both windows and linux.
> 
> V2: fix compile time errors due to -Werror flag.
> 
> Signed-off-by: Shirish S 
> Signed-off-by: Pratik Vishwakarma 
> Reviewed-by: Daniel Vetter 

Merged to drm-misc-next.

Harry

> ---
>  include/drm/drm_atomic.h | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index cf13842..3fe8dde 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -754,6 +754,28 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
> (new_plane_state) = 
> (__state)->planes[__i].new_state, 1))
>  
>  /**
> + * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an 
> atomic
> + * update in reverse order
> + * @__state:  drm_atomic_state pointer
> + * @plane:  drm_plane iteration cursor
> + * @old_plane_state:  drm_plane_state iteration cursor for the old 
> state
> + * @new_plane_state:  drm_plane_state iteration cursor for the new 
> state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all planes in an atomic update in reverse order,
> + * tracking both old and  new state. This is useful in places where the
> + * state delta needs to be considered, for example in atomic check functions.
> + */
> +#define for_each_oldnew_plane_in_state_reverse(__state, plane, 
> old_plane_state, new_plane_state, __i) \
> + for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1); \
> +  (__i) >= 0;\
> +  (__i)--)   \
> + for_each_if ((__state)->planes[__i].ptr &&  \
> +  ((plane) = (__state)->planes[__i].ptr, \
> +   (old_plane_state) = 
> (__state)->planes[__i].old_state,\
> +   (new_plane_state) = 
> (__state)->planes[__i].new_state, 1))
> +
> +/**
>   * for_each_old_plane_in_state - iterate over all planes in an atomic update
>   * @__state:  drm_atomic_state pointer
>   * @plane:  drm_plane iteration cursor
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105386] Request for a new fd.o account

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105386

--- Comment #1 from Daniel Vetter  ---
Ack from me, also from Petri and Arek (we discussed this all).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105386] Request for a new fd.o account

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105386

Daniel Vetter  changed:

   What|Removed |Added

Product|DRI |freedesktop.org
  Component|IGT |New Accounts
Version|XOrg git|unspecified
   Assignee|dri-devel@lists.freedesktop |sitewranglers@lists.freedes
   |.org|ktop.org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104285

--- Comment #9 from Gregor Münch  ---
(In reply to Alex Vorobyev from comment #8)
> I think it's not the same bug. CS:GO works on my system as it should, while
> SCS games still have broken shadows.

So you also checked that specific map?

Anyway, its either a bug which is already fixed in Mesa git or fixed in LLVM
6.0. In both cases devs will wait till users upgrade to mesa 18.
So the only thing you can do is check things with current mesa git / LLVM 6.0
and see if the problem persists.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #38 from Direx  ---
Just for the record (it might not surprise you): The patch also works on 4.15,
just tested it on the "old" kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: New KFD ioctls: taking the skeletons out of the closet

[Felix Kuehling]

Thanks for the feedback. I'm answering some of your questions inline.

On 2018-03-06 06:09 PM, Dave Airlie wrote:
> On 7 March 2018 at 08:44, Felix Kuehling  wrote:
>> Hi all,
>>
>> Christian raised two potential issues in a recent KFD upstreaming code
>> review that are related to the KFD ioctl APIs:
>>
>>  1. behaviour of -ERESTARTSYS
>>  2. transactional nature of KFD ioctl definitions, or lack thereof
>>
>> I appreciate constructive feedback, but I also want to encourage an
>> open-minded rather than a dogmatic approach to API definitions. So let
>> me take all the skeletons out of my closet and get these APIs reviewed
>> in the appropriate forum before we commit to them upstream. See the end
>> of this email for reference.
>>
>> The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If
>> any of the other APIs raise concerns or questions, please ask.
>>
>> Because of the HSA programming model, KFD memory management APIs are
>> synchronous. There is no pipelining. Command submission to GPUs through
>> user mode queues does not involve KFD. This means KFD doesn't know what
>> memory is used by the GPUs and when it's used. That means, when the
>> map_memory_to_gpu ioctl returns to user mode, all memory mapping
>> operations are complete and the memory can be used by the CPUs or GPUs
>> immediately.
> I've got a few opinions, but first up I still dislike user-mode queues
> and everything
> they entail. I still feel they are solving a Windows problem and not a
> Linux problem,
> and it would be nice if we had some Linux numbers on what they gain us over
> a dispatch ioctl, because they sure bring a lot of memory management issues.
>
> That said amdkfd is here.
>
> The first question you should ask (which you haven't asked here at all) is
> what should userspace do with the ioctl result.
>
>> HSA also uses a shared virtual memory model, so typically memory gets
>> mapped on multiple GPUs and CPUs at the same virtual address.
>>
>> The point of contention seems to be the ability to map memory to
>> multiple GPUs in a single ioctl and the behaviour in failure cases. I'll
>> discuss two main failure cases:
>>
>> 1: Failure after all mappings have been dispatched via SDMA, but a
>> signal interrupts the wait for completion and we return -ERESTARTSYS.
>> Documentation/kernel-hacking/hacking.rst only says "[...] you should be
>> prepared to process the restart, e.g. if you're in the middle of
>> manipulating some data structure." I think we do that by ensuring that
>> memory that's already mapped won't be mapped again. So the restart will
>> become a no-op and just end up waiting for all the previous mappings to
>> complete.
> -ERESTARTSYS at that late stage points to a badly synchronous API,
> I'd have said you should have two ioctls, one that returns a fence after
> starting the processes, and one that waits for the fence separately.
>
> The overhead of ioctls isn't your enemy until you've measured it and
> proven it's a problem.
>
>> Christian has a stricter requirement, and I'd like to know where that
>> comes from: "An interrupted IOCTL should never have a visible effect."
> Christian might be taking things a bit further but synchronous gpu access
> APIs are bad, but I don't think undoing a bunch of work is a good plan either
> just because you got ERESTARTSYS. If you get ERESTARTSYS can you
> handle it, if I've fired off 5 SDMAs and wait for them will I fire off 5 more?
> will I wait for the original SDMAs if I reenter?

It will wait for the original SDMAs to complete.

>
>> 2: Failure to map on some but not all GPUs. This comes down to the
>> question, do all ioctl APIs or system calls in general need to be
>> transactional? As a counter example I'd give incomplete read or write
>> system calls that return how much was actually read or written. Our
>> current implementation of map_memory_to_gpu doesn't do this, but it
>> could be modified to return to user mode how many of the mappings, or
>> which mappings specifically failed or succeeded.
> What should userspace do? if it only get mappings on 3 of the gpus instead
> of say 4? Is there a sane resolution other than calling the ioctl again with
> the single GPU? Would it drop the GPU from the working set from that point on?
>
> Need more info to do what can come out of the API doing incomplete
> operations.

There are two typical use cases where this function is used.

 1. During allocation
 2. Changing access to an existing buffer

There is no retry logic in either case. And given the likely failure
conditions, a retry doesn't really make much sense.

I think the most likely failure I've seen is a failure to validate the
BO under heavy memory pressure. This will affect the first GPU trying to
map the memory. Once it's mapped on one GPU, subsequent GPUs don't need
to validate it again, so that's less likely to fail. Maybe if we're
running out of space for the SDMA command buffers. If you're under that
much memory 

Re: [Mesa-dev] [PATCH 01/21] vulkan: Add KHR_display extension using DRM

[Keith Packard]

Daniel Stone  writes:

> Or better, just use drmModeAddFB2 and pass the format directly. That
> landed back in 3.2 or so, and I don't think there's anyone trying to
> use Vulkan on a kernel from 2011.

Yeah, that's probably a better plan. I've pushed a patch that does this
on top of the long list of patches made in response to Jason's email.

Once he's replied to that, I'll go ahead and smash the new patches back
on top of the original series and re-publish that.

-- 
-keith


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

Re: [Patch 1/4] dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt

[Rob Herring]

On Fri, Mar 02, 2018 at 07:48:01AM -0600, Benoit Parrot wrote:
> Add common DISPC bindings into the top level bindings file.
> Move common bindings here instead of having multiple copies of
> the same information in all of the variant specific files.
> 
> Signed-off-by: Benoit Parrot 
> ---
>  Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt  | 5 -
>  Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt  | 7 +++
>  Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt | 4 
>  Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt | 4 
>  Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt | 4 
>  Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 
>  6 files changed, 7 insertions(+), 21 deletions(-)

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

Re: [PATCH 01/21] vulkan: Add KHR_display extension using DRM

[Keith Packard]

Jason Ekstrand  writes:

Thanks a million for the intense review. I've pushed 15 tiny patches
that address individual questions in this message. If you want to look
at those separately, that would be great. When we're done, I'll merge
them back into the giant patch.

Sorry for the delay in answering; you asked a hard question about GEM
handles and reference counting which I think I've resolved by
eliminating the ability to share the same fd for modesetting and
rendering.

Let me know if I've deleted too much context from your answers.

> With the exception of NIR (which is a bit odd), we usually use ALL_CAPS for
> enum values.

Thanks, fixed.

> Yes, this does seem like the only reasonable mode for now.  I suppose you
> could check to see if the platform supports ASYNC_FLIP and advertise
> IMMEDIATE in that case.  I know intel doesn't advertise it but I thought
> amdgpu does.

Ok, we'll put that on the wish list, along with MAILBOX (which
applications actually want :-)

> vk_outarray, though I suppose you've probably already made that
> change.

Yup, vk_outarray everywhere now.

> I don't see use_prime_blit being set anywhere.  Perhaps that comes in a
> later patch?  The line is obviously correct, so I'm fine with leaving
> it.

You're right -- this was a cult-n-paste error. I don't support prime at
all, so I've removed this bit.

> This will have to be updated for modifiers.  I'm reasonably happy for it to
> be the no-op update for now though KHR_display supporting real modifiers
> would be nice. :-)

Yeah, "patches welcome", of course. I don't have a requirement for them
on Radeon at this point.

>> +   if (result != VK_SUCCESS)
>> +  return result;
>> +
>> +   ret = drmPrimeFDToHandle(wsi->master_fd, image->base.fd,
>> _handle);
>>
>
> This opens up some interesting questions.  GEM handles are not reference
> counted by the kernel.  If the driver that we're running on is using
> master_fd, then we shouldn't close our handle because that would close the
> handle for the driver as well.  If it's not using master_fd, we should
> close the handle to avoid leaking it.  The later is only a worry in the
> prime case but given that I saw a line above about use_prime_blit, you have
> me scared. :-)

Ok, as I mentioned in the header of this message, I've eliminated any
code which talks about potentially sharing master_fd and render_fd. I
removed render_fd from the wsi layer entirely as it is no longer used
anywhere.

In the drivers, when you request KHR_display, I attempt to open the
related primary node and if that succeeds, I pass that to the wsi layer
for use there. That fd is otherwise unused by the driver, and in fact
the driver doesn't need to close it as the wsi layer will.

Obviously having two FDs is "wasteful" at some level as we really don't
need that, but that's what the acquire_xlib extension will have to do
anyways.

> One solution to this connundrum would be to simply never use the master FD
> for the Vulkan driver itself and always open a render node.  If handed a
> master FD, you could check if it matches your render node and set
> use_prime_blit accordingly.  Then the driver and WSI would have separate
> handle domains and this problem would be solved.  You could also just open
> the master FD twice, once for WSI and once for the driver.

Yup, two FDs, one master, one render. That way, the kludge
seen in this patch where it opens the master when you request the
KHR_display extension works the same as the acquire_xlib code in the
later patch.

> You have the format in create_info.  We could add some generic VkFormat
> introspection or we can just handle the 2-4 cases we care about
> directly.

Given that this layer provides the list of valid surface formats which
that image could contain, I've added depth/bpp information to that list
and the image_init code walks over the list of possible formats to find
the associated depth/bpp values.

If the application provides an invalid format, I'm returning
VK_ERROR_DEVICE_LOST as that is a valid error return and I couldn't find
anything else that seemed like a better value. If we get here, the
application made a mistake anyways.

> What happens if we close the handle immediately after calling
> drmModeAddFB?  Does the FB become invalid?  If so, then we probably want to
> stash the handle so we can clean it up when we destroy the swapchain.
> Unless, of course, we're willing to make the assumption (as stated above)
> that the driver and WSI are always using the same FD.

It looks like the FB ends up with a reference to the object, so it would
should be safe to just close the handle at this point.  However, to make
it less dependent on the kernel behavior, I've changed the code to store
the buffer_object handle in the image and then added code to free both
the buffer object and the frame buffer in wsi_display_image_finish.

Thanks for finding the leak.

>> +/* call with wait_mutex held */
>>
>
> It might be worth a line in the 

Re: New KFD ioctls: taking the skeletons out of the closet

[Alex Deucher]

On Wed, Mar 7, 2018 at 11:38 AM, Daniel Vetter  wrote:
> On Wed, Mar 07, 2018 at 09:38:03AM +0100, Christian K??nig wrote:
>> Am 07.03.2018 um 00:09 schrieb Dave Airlie:
>> > On 7 March 2018 at 08:44, Felix Kuehling  wrote:
>> > > Hi all,
>> > >
>> > > Christian raised two potential issues in a recent KFD upstreaming code
>> > > review that are related to the KFD ioctl APIs:
>> > >
>> > >   1. behaviour of -ERESTARTSYS
>> > >   2. transactional nature of KFD ioctl definitions, or lack thereof
>> > >
>> > > I appreciate constructive feedback, but I also want to encourage an
>> > > open-minded rather than a dogmatic approach to API definitions. So let
>> > > me take all the skeletons out of my closet and get these APIs reviewed
>> > > in the appropriate forum before we commit to them upstream. See the end
>> > > of this email for reference.
>> > >
>> > > The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If
>> > > any of the other APIs raise concerns or questions, please ask.
>> > >
>> > > Because of the HSA programming model, KFD memory management APIs are
>> > > synchronous. There is no pipelining. Command submission to GPUs through
>> > > user mode queues does not involve KFD. This means KFD doesn't know what
>> > > memory is used by the GPUs and when it's used. That means, when the
>> > > map_memory_to_gpu ioctl returns to user mode, all memory mapping
>> > > operations are complete and the memory can be used by the CPUs or GPUs
>> > > immediately.
>> > I've got a few opinions, but first up I still dislike user-mode queues
>> > and everything
>> > they entail. I still feel they are solving a Windows problem and not a
>> > Linux problem,
>> > and it would be nice if we had some Linux numbers on what they gain us over
>> > a dispatch ioctl, because they sure bring a lot of memory management 
>> > issues.
>>
>> Well user-mode queues are a problem as long as you don't have recoverable
>> page faults on the GPU.
>>
>> As soon as you got recoverable page faults and push the memory management
>> towards things like HMM I don't see an advantage of using a IOCTL based
>> command submission any more.
>>
>> So I would say that this is a problem which is slowly going away as the
>> hardware improves.
>
> Yeah, but up to the point where the hw actually works (instead of promises
> that maybe it'll work next generation, trust us, for like a few
> generations) it's much easier to hack up an ioctl with workarounds than
> intercepting an mmap write fault all the time (those are slower than
> ioctls).
>
> I think userspace queues are fine once we have known-working hw. Before
> that I'm kinda agreeing with Dave and not seeing the point. At least to my
> knowledge we still haven't arrived in the wonderful promised land of hw
> recoverable (well, restartable really) page faults on any vendors platform
> ...


I think user space queues are a bit of a distraction.  The original
point of KFD and HSA was to have a consistent programming model across
CPU and other devices with relatively seamless access to the same
memory pools.  KFD was originally focused on APUs and when we have an
IOMMUv2 with ATC available, we have support for recoverable page
faults.  It's been working for 3 generations of hw and has been
expanded to GPUVM on newer hw which doesn't have the dependency on
IOMMU and also support vram.  We added support for KFD for older dGPUs
that don't have this capability, but that is certainly not the only
use case we need to consider.

Alex

>
>> > That said amdkfd is here.
>> >
>> > The first question you should ask (which you haven't asked here at all) is
>> > what should userspace do with the ioctl result.
>> >
>> > > HSA also uses a shared virtual memory model, so typically memory gets
>> > > mapped on multiple GPUs and CPUs at the same virtual address.
>> > >
>> > > The point of contention seems to be the ability to map memory to
>> > > multiple GPUs in a single ioctl and the behaviour in failure cases. I'll
>> > > discuss two main failure cases:
>> > >
>> > > 1: Failure after all mappings have been dispatched via SDMA, but a
>> > > signal interrupts the wait for completion and we return -ERESTARTSYS.
>> > > Documentation/kernel-hacking/hacking.rst only says "[...] you should be
>> > > prepared to process the restart, e.g. if you're in the middle of
>> > > manipulating some data structure." I think we do that by ensuring that
>> > > memory that's already mapped won't be mapped again. So the restart will
>> > > become a no-op and just end up waiting for all the previous mappings to
>> > > complete.
>> > -ERESTARTSYS at that late stage points to a badly synchronous API,
>> > I'd have said you should have two ioctls, one that returns a fence after
>> > starting the processes, and one that waits for the fence separately.
>>
>> That is exactly what I suggested as well, but also exactly what Felix tries
>> to avoid :)
>>
>> > The overhead of ioctls isn't your 

[Bug 81689] Black screen in info-beamer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=81689

Sven Arvidsson  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #2 from Sven Arvidsson  ---
Retested with Mesa 17 on radeonsi and info-beamer from Debian (1.0pre3+Lua)
everything seems to be working.

Presumably fixed on the info-beamer side, so I'm closing this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #37 from Harry Wentland  ---
... pick it up for 4.15 is what I meant to say.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #36 from Harry Wentland  ---
Thanks, Direx. I'll get it reviewed and intend to get it into 4.16 as well.
Will send it to the stable tree as well, where GregKH can pick it up.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/16] dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline

[Rob Herring]

On Thu, Mar 01, 2018 at 10:34:31PM +0100, Jernej Skrabec wrote:
> Add missing compatibles for H3 HDMI pipeline. These compatibles can also
> be used with H5 SoC.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 ++
>  1 file changed, 6 insertions(+)

Reviewed-by: Rob Herring 

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

Re: [PATCH v3 04/16] clk: sunxi-ng: h3: h5: export CLK_PLL_VIDEO

[Rob Herring]

On Thu, Mar 01, 2018 at 10:34:30PM +0100, Jernej Skrabec wrote:
> CLK_PLL_VIDEO needs to be referenced in HDMI DT entry as a possible
> PHY clock parent.
> 
> Export it so it can be used later in DT.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.h  | 4 +++-
>  include/dt-bindings/clock/sun8i-h3-ccu.h | 2 ++
>  2 files changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

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

Re: [PATCH v3 2/7] dt-bindings: display: Add Allwinner MIPI-DSI bindings

[Rob Herring]

On Tue, Mar 06, 2018 at 02:55:59PM +0100, Maxime Ripard wrote:
> From: Maxime Ripard 
> 
> The Allwinner SoCs usually come with a DSI encoder. Add a binding for it.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 93 +++-
>  1 file changed, 93 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt

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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #35 from Direx  ---
(In reply to Harry Wentland from comment #34)
> DC seems to take channel_count/audio_count to refer to the actual number of
> channels whereas the CEA EDID extension and our HW represent it as the
> number of channels-1. So as not to break other uses of this count (such as
> check_audio_bandwidth_hdmi()) this patch adds 1 when we get the count from
> the EDID.
> 
> Can someone give it a spin? It's based on the latest amd-staging-drm-next
> branch but should apply on other branches as well.

Just tested it on a fresh amd-staging-drm-next and it is also working. All
audio formats are working correctly. *thumbs up*

Could this be backported to 4.15 / 4.16 as it actually is a simple bug fix?


@lethalwp:

I think your issue is unrelated to this one. I get that too occasionally, but
it has nothing to do with the wrong channel count in this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105021

jam...@amd.com  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #30 from jam...@amd.com  ---
https://lists.freedesktop.org/archives/amd-gfx/2018-March/019801.html 
the above patch should solve this suspend/resume issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #34 from Harry Wentland  ---
Created attachment 137870
  --> https://bugs.freedesktop.org/attachment.cgi?id=137870=edit
[PATCH] Add one to EDID's audio channel count when passing to DC

Thanks everyone for the debug on this one and especially Andrew for the patch.

DC seems to take channel_count/audio_count to refer to the actual number of
channels whereas the CEA EDID extension and our HW represent it as the number
of channels-1. So as not to break other uses of this count (such as
check_audio_bandwidth_hdmi()) this patch adds 1 when we get the count from the
EDID.

Can someone give it a spin? It's based on the latest amd-staging-drm-next
branch but should apply on other branches as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/6] drm: Reject bad property flag combinations

[Ville Syrjälä]

On Tue, Mar 06, 2018 at 07:22:51PM +0100, Daniel Vetter wrote:
> On Tue, Mar 06, 2018 at 06:48:49PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Pimp drm_property_type_valid() to check for more fails with the
> > property flags. Also make the check before adding the property,
> > and bail out if things look bad.
> > 
> > Since we're now chekcing for more than the type let's also
> > change the function name to drm_property_flags_valid().
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_property.c | 29 +++--
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> > index 027a50e55e96..6ac6ee41a6a3 100644
> > --- a/drivers/gpu/drm/drm_property.c
> > +++ b/drivers/gpu/drm/drm_property.c
> > @@ -50,11 +50,27 @@
> >   * IOCTL and in the get/set property IOCTL.
> >   */
> >  
> > -static bool drm_property_type_valid(struct drm_property *property)
> > +static bool drm_property_flags_valid(u32 flags)
> >  {
> > -   if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
> > -   return !(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
> > -   return !!(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
> > +   u32 legacy_type = flags & DRM_MODE_PROP_LEGACY_TYPE;
> > +   u32 ext_type = flags & DRM_MODE_PROP_EXTENDED_TYPE;
> > +
> > +   /* Reject undefined/deprecated flags */
> > +   if (flags & ~(DRM_MODE_PROP_LEGACY_TYPE |
> > + DRM_MODE_PROP_EXTENDED_TYPE |
> > + DRM_MODE_PROP_IMMUTABLE |
> > + DRM_MODE_PROP_ATOMIC))
> > +   return false;
> > +
> > +   /* We want either a legacy type or an extended type, but not both */
> > +   if (!legacy_type == !ext_type)
> > +   return false;
> > +
> > +   /* Only one legacy type at a time please */
> > +   if (legacy_type && !is_power_of_2(legacy_type))
> > +   return false;
> > +
> > +   return true;
> >  }
> 
> I think this catches everything. Well except not-yet-assigned
> EXTENDED_TYPE defines, but really we can overdo this :-)

Hmm. Yeah, I guess that kind of a fail is fairly unlikely because the
defines won't be there. Would require the driver to basically pass in
utter garbage instead of just a bad combination of existing flags.

> 
> Reviewed-by: Daniel Vetter 

Thanks. Series pushed to drm-misc-next.

> >  
> >  /**
> > @@ -79,6 +95,9 @@ struct drm_property *drm_property_create(struct 
> > drm_device *dev,
> > struct drm_property *property = NULL;
> > int ret;
> >  
> > +   if (WARN_ON(!drm_property_flags_valid(flags)))
> > +   return NULL;
> > +
> > if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
> > return NULL;
> >  
> > @@ -108,8 +127,6 @@ struct drm_property *drm_property_create(struct 
> > drm_device *dev,
> >  
> > list_add_tail(>head, >mode_config.property_list);
> >  
> > -   WARN_ON(!drm_property_type_valid(property));
> > -
> > return property;
> >  fail:
> > kfree(property->values);
> > -- 
> > 2.16.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

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH/RFC 00/60] omapdrm: Reverse direction of DSS device (dis)connect operations

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 7 March 2018 16:11:04 EET Tomi Valkeinen wrote:
> On 07/03/18 02:24, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series is a first step towards moving the omapdrm driver away
> > from the custom bridge and panel drivers to drm_bridge and drm_panel.
> > 
> > The main blocker to transition to drm_bridge and drm_panel is the
> > direction of the bridge operations. While the omapdrm driver manages its
> > components from sink to source (panel to DSS output), the drm_bridge API
> > is manages bridges in the source to sink direction. This makes the two
> > models incompatible, and requires reversing the direction of operations
> > inside omapdrm.
> > 
> > Don't rejoice too fast, we're still far from a complete transition, but
> > this first step paves the way by reworking the driver's internals to make
> > source to sink order possible. It then transitions the connect and
> > disconnect operations (the omapdrm equivalent of the drm_bridge attach
> > and detach operations) to the new direction.
> > 
> > I've sent the patches as an RFC as I might not be aware of all the
> > consequences of the numerous changes to the driver's internals, even if I
> > took care to analyze the code flows to the best of my abilities.
> > 
> > The series contains patches previously posted by Jyri and Peter that I
> > have found helpful. Please see the individual patches for changes compared
> > to the original versions (trivial conflict resolutions caused by a rebase
> > are not mentioned).
> > 
> > The patches are based on top of a merge between Tomi's omapdrm-next branch
> > and the drm-misc/drm-misc-next branch for the "drm: fix drm_get_max_iomem
> > type mismatch" compilation fix. They can be found at
> > 
> > git://linuxtv.org/pinchartl/media.git omapdrm/bridge
> > 
> > The series has been tested on a Pandaboard with the HDMI and DVI outputs.
> > All patches have been at least compile-tested individually. I'll now go
> > through the process of making sure each of them gets tested on hardware
> > as well.
> 
> Thanks, nice work!
> 
> I did a read-the-descs-review, and looks good to me. My only comments
> are what I already mentioned in the chat: AM5 EVM doesn't work LCD
> (panel-dpi broken, perhaps?) (AM5 EVM was the only board I tested),

I've now tested the AM5 EVM and the LCD panel worked out of the box. I tried 
to load all modules before panel_dpi and the panel then stopped working. After 
a bit of investigation it turns out that the dpi_init_port() and 
sdi_init_port() functions can return probe deferral, but their return value is 
ignored by the caller. The problem pre-exists this series, the patch below 
fixes it. Surprisingly enough given the extent of the rework, it doesn't 
conflict with this series, I'll thus place it towards the start of v2.

From 82798aa248b30199ab8c6dc3417e6478f1fca8c4 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart 
Date: Wed, 7 Mar 2018 20:34:42 +0200
Subject: [PATCH] drm/omap: dss: Handle DPI and SDI port initialization
 failures

The dpi_init_port() and sdi_init_port() functions can return errors but
their return value is ignored. This prevents both probe failures and
probe deferral from working correctly. Propagate the errors up the call
stack.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c b/drivers/gpu/drm/omapdrm/dss/
dss.c
index 5f7789cf43c7..841256c34d65 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1185,7 +1185,8 @@ static int dss_init_ports(struct dss_device *dss)
struct platform_device *pdev = dss->pdev;
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
-   int i;
+   unsigned int i;
+   int r;
 
for (i = 0; i < dss->feat->num_ports; i++) {
port = of_graph_get_port_by_id(parent, i);
@@ -1194,11 +1195,17 @@ static int dss_init_ports(struct dss_device *dss)
 
switch (dss->feat->ports[i]) {
case OMAP_DISPLAY_TYPE_DPI:
-   dpi_init_port(dss, pdev, port, dss->feat->model);
+   r = dpi_init_port(dss, pdev, port, dss->feat->model);
+   if (r)
+   return r;
break;
+
case OMAP_DISPLAY_TYPE_SDI:
-   sdi_init_port(dss, pdev, port);
+   r = sdi_init_port(dss, pdev, port);
+   if (r)
+   return r;
break;
+
default:
break;
}

> and patch 7 it not correct, as the infoframe is set from omap_encoder.

You're right. I'll drop that patch.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm/pl111: Enable device-specific assigned memory

[Eric Anholt]

Linus Walleij  writes:

> The Versatile Express has 8 MB of dedicated video RAM (VRAM)
> on the motherboard, which is what we should be using for the
> PL111 if available. On this platform, the memory backplane
> is constructed so that only this memory will work properly
> with the CLCD on the motherboard, using any other memory
> region just gives random snow on the display.
>
> The CA9 Versatile Express also has a PL111 instance on its
> core tile. This is OK, it has been tested with the motherboard
> VRAM and that works just as fine as regular CMA memory.
>
> The memory is assigned to the device using the memory-region
> device tree property and a "shared-dma-pool" reserved
> memory pool like this:
>
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> vram: vram@4800 {
> compatible = "shared-dma-pool";
> reg = <0x4800 0x0080>;
> no-map;
> };
> };
>
> clcd@1f000 {
> compatible = "arm,pl111", "arm,primecell";
>   (...)
> memory-region = <>;
> }·;
>
> Cc: Liviu Dudau 
> Cc: Mali DP Maintainers 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpu/drm/pl111/pl111_drv.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index b469aa317d9d..e301f2a719a3 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -60,6 +60,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -262,6 +263,10 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
>   drm->dev_private = priv;
>   priv->variant = variant;
>  
> + ret = of_reserved_mem_device_init(dev);
> + if (!ret)
> + dev_info(dev, "using device-specific reserved memory\n");
> +
>   if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
>>memory_bw)) {
>   dev_info(dev, "no max memory bandwidth specified, assume 
> unlimited\n");
> -- 
> 2.14.3

It looks like you'll want a matching of_reserved_mem_device_release() at
remove / dev_unref time.

This will still allow BO imports from non-reserved memory, I think.
Should we just error out of import_sg_table() on this platform?


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

[Bug 105386] Request for a new fd.o account

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105386

Bug ID: 105386
   Summary: Request for a new fd.o account
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: antonio.argenzi...@intel.com

Created attachment 137868
  --> https://bugs.freedesktop.org/attachment.cgi?id=137868=edit
PGP & SSH PUBLIC KEY

Request for a new account for:
Name: Antonio Argenziano
email addr: antonio.argenzi...@intel.com
preferred account name: aargenzi

Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104932

Robin Kauffman  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Robin Kauffman  ---
Hi Again-
Well, after (repeatedly) breaking the Law of Sysadminning (changing more
than one thing at a time), and upgrading userland (including, but sadly not
limited to, the 3D stack) as well as the kernel, I have a working desktop, and
what little I can divine from where I ended up is that it may well *not* have
been RadeonSI/libdrm/AMDGPU at fault to begin with (almost labeled the
resolution NOTOURBUG, but the probability that there might have been some
slight issue with things actually pertaining to the RadeonSI/AMDGPU graphics
driver is to my mind nonzero, even if scant).
I unfortunately neglected to bisect the kernel driver (or parts of
userland) to see if I could get things working by going back in time and seeing
if there was some commit somewhere that broke things (at least for my
already-rickety userland).  Such a commit may well exist, but going back to try
to find it would be a lengthy endeavor, and given that things more-or-less work
for me now, the motivation for doing so has all but dried up.
If someone wants to follow-up with a likely cause for the kernel complaint
I *did* see earlier, by all means do so, but I have a sneaking suspicion that I
likely made things Not Work by having a haphazard and semi-out-of-date userland
(in this case, *outside* of libdrm/LLVM/Clang/Mesa/etc).
Thanks, and apologies for any time sunk on anyone else's behalf trying to
suss this one out.

-Robin K.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] R-Car DU changes for v4.17

[Laurent Pinchart]

Hi Dave,

Please pull the R-Car DU changes for v4.17. This contains

- Convert LVDS support to a drm_bridge driver
- Add DT bindings for the R8A77995 SoC
- Add DT bindings and driver support for the R8A77970 SoC

Note that the LVDS conversion depends on a patch series from Frank Rowand that 
will make it upstream through Rob Herring's tree. Frank has provided a stable 
branch based on v4.16-rc1 with the patches, and both Rob and I have merged it 
into our trees. This should thus generate no conflict when reaching -next.

The following changes since commit f073d78eeb8efd85718e611c15f9a78647751dea:

  Merge tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/
drm-intel into drm-next (2018-03-01 14:07:22 +1000)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git drm/next/du

for you to fetch changes up to 77f59f895da2fe5526073181c74c3fb85a7c80d1:

  dt-bindings: display: renesas: lvds: Document r8a77995 bindings (2018-03-07 
19:30:11 +0200)


Frank Rowand (5):
  x86: devicetree: fix config option around x86_flattree_get_config()
  of: change overlay apply input data from unflattened to FDT
  of: Documentation: of_overlay_apply() replaced by of_overlay_fdt_apply()
  of: convert unittest overlay devicetree source to sugar syntax
  of: improve reporting invalid overlay target path

Kieran Bingham (2):
  dt-bindings: display: renesas: du: Document r8a77995 bindings
  dt-bindings: display: renesas: lvds: Document r8a77995 bindings

Laurent Pinchart (5):
  Merge tag 'overlay_apply_fdt_v7-for-4.17' of git://git.kernel.org/.../
frowand/linux into drm/next/du
  dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
  dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings
  drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
  drm: rcar-du: Convert LVDS encoder code to bridge driver

Sergei Shtylyov (4):
  dt-bindings: display: renesas: du: Document R8A77970 bindings
  dt-bindings: display: renesas: lvds: Document R8A77970 bindings
  drm: rcar-du: Add R8A77970 support
  drm: rcar-du: lvds: Add R8A77970 support

 .../devicetree/bindings/display/bridge/renesas,lvds.txt |  58 +++
 .../devicetree/bindings/display/renesas,du.txt  |  35 +-
 Documentation/devicetree/overlay-notes.txt  |   4 +-
 MAINTAINERS |   1 +
 arch/x86/kernel/devicetree.c|   2 +-
 drivers/gpu/drm/rcar-du/Kconfig |   6 +-
 drivers/gpu/drm/rcar-du/Makefile|  10 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  42 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c   | 175 +---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h   |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c   |  93 
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h   |  24 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c   | 238 ---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h   |  64 ---
 drivers/gpu/drm/rcar-du/rcar_du_of.c| 322 +
 drivers/gpu/drm/rcar-du/rcar_du_of.h|  20 +
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts |  76 
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts |  50 +++
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts |  50 +++
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts |  50 +++
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts |  50 +++
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 540 +++
 drivers/of/Kconfig  |   1 +
 drivers/of/overlay.c| 134 +-
 drivers/of/resolver.c   |   6 -
 drivers/of/unittest-data/Makefile   |  28 +-
 drivers/of/unittest-data/overlay.dts| 101 ++---
 drivers/of/unittest-data/overlay_0.dts  |  14 +
 drivers/of/unittest-data/overlay_1.dts  |  14 +
 drivers/of/unittest-data/overlay_10.dts |  27 ++
 drivers/of/unittest-data/overlay_11.dts |  28 ++
 drivers/of/unittest-data/overlay_12.dts |  14 +
 drivers/of/unittest-data/overlay_13.dts |  14 +
 drivers/of/unittest-data/overlay_15.dts |  30 ++
 drivers/of/unittest-data/overlay_2.dts  |   9 +
 drivers/of/unittest-data/overlay_3.dts  |   9 +
 drivers/of/unittest-data/overlay_4.dts  |  18 +
 drivers/of/unittest-data/overlay_5.dts  |   9 +
 drivers/of/unittest-data/overlay_6.dts  |  10 +
 

[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199047

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Are you using DC?  Please attach your dmesg output.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Daniel Vetter]

On Thu, Feb 22, 2018 at 04:16:52PM -0500, Alex Deucher wrote:
> On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen
>  wrote:
> > On Thu, Feb 22, 2018 at 7:04 PM, Kristian H??gsberg  
> > wrote:
> >> On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher  wrote:
> >>
> >>> On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace 
> >> wrote:
> >>> > On Thu 21 Dec 2017, Daniel Vetter wrote:
> >>> >> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <
> >> hoegsb...@google.com> wrote:
> >>> >>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <
> >> mvicom...@nvidia.com> wrote:
> >>>  On Wed, 20 Dec 2017 11:54:10 -0800 Kristian H??gsberg <
> >> hoegsb...@gmail.com> wrote:
> >>> > I'd like to see concrete examples of actual display controllers
> >>> > supporting more format layouts than what can be specified with a 64
> >>> > bit modifier.
> >>> 
> >>>  The main problem is our tiling and other metadata parameters can't
> >>>  generally fit in a modifier, so we find passing a blob of metadata a
> >>>  more suitable mechanism.
> >>> >>>
> >>> >>> I understand that you may have n knobs with a total of more than a
> >> total of
> >>> >>> 56 bits that configure your tiling/swizzling for color buffers. What
> >> I don't
> >>> >>> buy is that you need all those combinations when passing buffers
> >> around
> >>> >>> between codecs, cameras and display controllers. Even if you're
> >> sharing
> >>> >>> between the same 3D drivers in different processes, I expect just
> >> locking
> >>> >>> down, say, 64 different combinations (you can add more over time) and
> >>> >>> assigning each a modifier would be sufficient. I doubt you'd extract
> >>> >>> meaningful performance gains from going all the way to a blob.
> >>> >
> >>> > I agree with Kristian above. In my opinion, choosing to encode in
> >>> > modifiers a precise description of every possible tiling/compression
> >>> > layout is not technically incorrect, but I believe it misses the point.
> >>> > The intention behind modifiers is not to exhaustively describe all
> >>> > possibilites.
> >>> >
> >>> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
> >>> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
> >>> >
> >>> > One goal of modifiers in the Linux ecosystem is to enumerate for
> >> each
> >>> > vendor a reasonably sized set of tiling formats that are
> >> appropriate for
> >>> > images shared across processes, APIs, and/or devices, where each
> >>> > participating component may possibly be from different vendors.
> >>> > A non-goal is to enumerate all tiling formats supported by all
> >> vendors.
> >>> > Some tiling formats used internally by vendors are inappropriate for
> >>> > sharing; no modifiers should be assigned to such tiling formats.
> >>
> >>> Where it gets tricky is how to select that subset?  Our tiling mode
> >>> are defined more by the asic specific constraints than the tiling mode
> >>> itself.  At a high level we have basically 3 tiling modes (out of 16
> >>> possible) that would be the minimum we'd want to expose for gfx6-8.
> >>> gfx9 uses a completely new scheme.
> >>> 1. Linear (per asic stride requirements, not usable by many hw blocks)
> >>> 2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
> >>> 3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
> >>> tile split (7 possible), sample split (4 possible), num banks (4
> >>> possible), bank width (4 possible), bank height (4 possible), macro
> >>> tile aspect (4 possible) all of which are asic config specific)
> >>
> >>> I guess we could do something like:
> >>> AMD_GFX6_LINEAR_ALIGNED_64B
> >>> AMD_GFX6_LINEAR_ALIGNED_256B
> >>> AMD_GFX6_LINEAR_ALIGNED_512B
> >>> AMD_GFX6_1D_THIN_DISPLAY
> >>> AMD_GFX6_1D_THIN_DEPTH
> >>> AMD_GFX6_1D_THIN_ROTATED
> >>> AMD_GFX6_1D_THIN_THIN
> >>> AMD_GFX6_1D_THIN_THICK
> >>
> >> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> >>
> >> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> >>
> >> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> >>
> >> AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> >>
> >> AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> >>
> >> AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> >>
> >> AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
> 

Re: [PATCH libdrm] drm/atomic: Refuse to add invalid objects to requests

[Daniel Stone]

On 7 March 2018 at 16:42, Daniel Vetter  wrote:
> On Wed, Mar 07, 2018 at 12:42:15PM +, Daniel Stone wrote:
>> Object and property IDs cannot be zero. Prevent them from being added to
>> the request stream at all, rather than breaking at commit time.
>
> Reviewed-by: Daniel Vetter 
>
> ... and gives us a perfect spot to gdb into a backtrace and figure out wtf
> is going on with drm_hwc :-)

Heh, and pushed now. Thanks Daniel!

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

Re: [Nouveau] Aspirant for GSOC 2018 for Nouveau Vulkan driver

[Karol Herbst]

I would be willing to be a mentor for this project.

On Wed, Mar 7, 2018 at 1:45 PM, Martin Peres  wrote:
> Hi Anusha,
>
> Sorry, I was under the expectation that userspace developers would
> answer you after your first message, and I missed your second one! My
> sincere apologies.
>
> Generally, the process is that the student should research the topic by
> first asking questions to developers about the effort, then they would
> make their own plan. Then you would present this plan while looking for
> a mentor.
>
> Of course, you can expect help from the community in order to better
> understand what needs to be done, but don't expect to be given a
> detailed plan, just pointers.
>
> Sorry again for my lack of feedback,
> Martin
>
> On 07/03/18 05:53, Anusha Srivastava wrote:
>> Hi,
>>
>> I am not been able to contact with mentor of this project.
>> Can someone else from the community help me with this ?
>>
>>
>> Regards,
>> Anusha Srivastava
>>
>>
>> On 3 March 2018 at 11:16, Anusha Srivastava  wrote:
>>> Hi Martin,
>>>
>>> Any update on this ?
>>> Regards,
>>> Anusha Srivastava
>>>
>>>
>>> On 28 February 2018 at 23:37, Anusha Srivastava  
>>> wrote:
 Hi,

 I would like to participate in  GSOC 2018 with Xorg to contribute to
 project "Initial Nouveau Vulkan driver'
 I would need some help in how to get started with the same.

 Regards,
 Anusha Srivastava
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm: rcar-du: add R8A77970 support

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Thursday, 18 January 2018 23:05:59 EET Sergei Shtylyov wrote:
> Add support for the R-Car V3M (R8A77970) SoC to the R-Car DU driver.
> 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Laurent Pinchart 

and applied to my tree.

> ---
> Changes in version 2:
> - removed  the 'model' and 'dpll_ch' field initializers;
> - fixed up the DU port numbers;
> - split the DU bindings and the LVDS driver updates into a separate patches;
> - removed  the check before the DPTSR write (to be done in a separate
> patch).
> 
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c |   21 +
>  1 file changed, 21 insertions(+)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -249,6 +249,26 @@ static const struct rcar_du_device_info
>   .dpll_ch =  BIT(1),
>  };
> 
> +static const struct rcar_du_device_info rcar_du_r8a77970_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> +   | RCAR_DU_FEATURE_EXT_CTRL_REGS
> +   | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .num_crtcs = 1,
> + .routes = {
> + /* R8A77970 has one RGB output and one LVDS output. */
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(0),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 1,
> + },
> + },
> + .num_lvds = 1,
> +};
> +
>  static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
>   { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> @@ -260,6 +280,7 @@ static const struct of_device_id rcar_du
>   { .compatible = "renesas,du-r8a7794", .data = _du_r8a7794_info },
>   { .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
>   { .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
> + { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
>   { }
>  };


-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 1/2] DT: display: renesas, du: document R8A77970 bindings

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Thursday, 18 January 2018 23:05:58 EET Sergei Shtylyov wrote:
> Document the R-Car V3M (R8A77970) SoC in the R-Car DU bindings.
> 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Laurent Pinchart 

and applied to my tree with the subject prefixed changed per Rob's request.

> ---
> Changes in version 2:
> - documented  R8A77970 DU ports;
> - patch split from the main R8A77970 DU support patch.
> 
>  Documentation/devicetree/bindings/display/renesas,du.txt |2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
> ===
> --- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ linux/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -13,6 +13,7 @@ Required Properties:
>  - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
>  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> +- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
> 
>- reg: A list of base address and length of each memory resource, one for
> each entry in the reg-names property.
> @@ -63,6 +64,7 @@ corresponding to each DU output.
>   R8A7794 (R-Car E2)   DPAD 0 DPAD 1 -  -
>   R8A7795 (R-Car H3)   DPAD 0 HDMI 0 HDMI 1 LVDS 0
>   R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
> + R8A77970 (R-Car V3M) DPAD 0 LVDS 0 -  -
> 
> 
>  Example: R8A7795 (R-Car H3) ES2.0 DU


-- 
Regards,

Laurent Pinchart

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

[PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

[Sylwester Nawrocki]

The #sound-dai-cells DT property is required to describe link between
the HDMI IP block and the SoC's audio subsystem.

Signed-off-by: Sylwester Nawrocki 
---
 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index 8715ff06c457..6b2a526ec586 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -50,6 +50,9 @@ Required properties for Exynos 5433:
 - clock-names: aliases for above clock specfiers.
 - samsung,sysreg: handle to syscon used to control the system registers.
 
+Optional properties for Exynos 4210, 4212, 5420 and 5433:
+ - #sound-dai-cells: should be 0.
+
 Example:
 
hdmi {
-- 
2.14.2

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

[Bug 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105369

--- Comment #7 from Alex Deucher  ---
It looks like you built the driver without DC or DCN support.  Please make sure
the following are set in your .config:
CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_DCN1_0=y

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105369

--- Comment #6 from cd  ---
Created attachment 137867
  --> https://bugs.freedesktop.org/attachment.cgi?id=137867=edit
journalctl-amd-drm-staging.txt

I hope I took the correct version, 4.16.0-rc1-085145ebf0e9

The screen freezes with the boot log, no further output is shown and gdm is
constantly trying to launch.

I enclosed the complete journalctl -b -1, only removed the constant retry of
gdm.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] drm/atomic: Refuse to add invalid objects to requests

[Daniel Vetter]

On Wed, Mar 07, 2018 at 12:42:15PM +, Daniel Stone wrote:
> Object and property IDs cannot be zero. Prevent them from being added to
> the request stream at all, rather than breaking at commit time.
> 
> Signed-off-by: Daniel Stone 
> ---
>  xf86drmMode.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 15957ffc..bd59ef25 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -1313,6 +1313,9 @@ int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
>   if (!req)
>   return -EINVAL;
>  
> + if (object_id == 0 || property_id == 0)
> + return -EINVAL;

Reviewed-by: Daniel Vetter 

... and gives us a perfect spot to gdb into a backtrace and figure out wtf
is going on with drm_hwc :-)
-Daniel

> +
>   if (req->cursor >= req->size_items) {
>   drmModeAtomicReqItemPtr new;
>  
> -- 
> 2.14.3
> 
> ___
> 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: New KFD ioctls: taking the skeletons out of the closet

[Daniel Vetter]

On Wed, Mar 07, 2018 at 09:38:03AM +0100, Christian K??nig wrote:
> Am 07.03.2018 um 00:09 schrieb Dave Airlie:
> > On 7 March 2018 at 08:44, Felix Kuehling  wrote:
> > > Hi all,
> > > 
> > > Christian raised two potential issues in a recent KFD upstreaming code
> > > review that are related to the KFD ioctl APIs:
> > > 
> > >   1. behaviour of -ERESTARTSYS
> > >   2. transactional nature of KFD ioctl definitions, or lack thereof
> > > 
> > > I appreciate constructive feedback, but I also want to encourage an
> > > open-minded rather than a dogmatic approach to API definitions. So let
> > > me take all the skeletons out of my closet and get these APIs reviewed
> > > in the appropriate forum before we commit to them upstream. See the end
> > > of this email for reference.
> > > 
> > > The controversial part at this point is kfd_ioctl_map_memory_to_gpu. If
> > > any of the other APIs raise concerns or questions, please ask.
> > > 
> > > Because of the HSA programming model, KFD memory management APIs are
> > > synchronous. There is no pipelining. Command submission to GPUs through
> > > user mode queues does not involve KFD. This means KFD doesn't know what
> > > memory is used by the GPUs and when it's used. That means, when the
> > > map_memory_to_gpu ioctl returns to user mode, all memory mapping
> > > operations are complete and the memory can be used by the CPUs or GPUs
> > > immediately.
> > I've got a few opinions, but first up I still dislike user-mode queues
> > and everything
> > they entail. I still feel they are solving a Windows problem and not a
> > Linux problem,
> > and it would be nice if we had some Linux numbers on what they gain us over
> > a dispatch ioctl, because they sure bring a lot of memory management issues.
> 
> Well user-mode queues are a problem as long as you don't have recoverable
> page faults on the GPU.
> 
> As soon as you got recoverable page faults and push the memory management
> towards things like HMM I don't see an advantage of using a IOCTL based
> command submission any more.
> 
> So I would say that this is a problem which is slowly going away as the
> hardware improves.

Yeah, but up to the point where the hw actually works (instead of promises
that maybe it'll work next generation, trust us, for like a few
generations) it's much easier to hack up an ioctl with workarounds than
intercepting an mmap write fault all the time (those are slower than
ioctls).

I think userspace queues are fine once we have known-working hw. Before
that I'm kinda agreeing with Dave and not seeing the point. At least to my
knowledge we still haven't arrived in the wonderful promised land of hw
recoverable (well, restartable really) page faults on any vendors platform
...

> > That said amdkfd is here.
> > 
> > The first question you should ask (which you haven't asked here at all) is
> > what should userspace do with the ioctl result.
> > 
> > > HSA also uses a shared virtual memory model, so typically memory gets
> > > mapped on multiple GPUs and CPUs at the same virtual address.
> > > 
> > > The point of contention seems to be the ability to map memory to
> > > multiple GPUs in a single ioctl and the behaviour in failure cases. I'll
> > > discuss two main failure cases:
> > > 
> > > 1: Failure after all mappings have been dispatched via SDMA, but a
> > > signal interrupts the wait for completion and we return -ERESTARTSYS.
> > > Documentation/kernel-hacking/hacking.rst only says "[...] you should be
> > > prepared to process the restart, e.g. if you're in the middle of
> > > manipulating some data structure." I think we do that by ensuring that
> > > memory that's already mapped won't be mapped again. So the restart will
> > > become a no-op and just end up waiting for all the previous mappings to
> > > complete.
> > -ERESTARTSYS at that late stage points to a badly synchronous API,
> > I'd have said you should have two ioctls, one that returns a fence after
> > starting the processes, and one that waits for the fence separately.
> 
> That is exactly what I suggested as well, but also exactly what Felix tries
> to avoid :)
> 
> > The overhead of ioctls isn't your enemy until you've measured it and
> > proven it's a problem.
> > 
> > > Christian has a stricter requirement, and I'd like to know where that
> > > comes from: "An interrupted IOCTL should never have a visible effect."
> > Christian might be taking things a bit further but synchronous gpu access
> > APIs are bad, but I don't think undoing a bunch of work is a good plan 
> > either
> > just because you got ERESTARTSYS. If you get ERESTARTSYS can you
> > handle it, if I've fired off 5 SDMAs and wait for them will I fire off 5 
> > more?
> > will I wait for the original SDMAs if I reenter?
> 
> Well it's not only the waiting for the SDMAs. If I understood it correctly
> the IOCTL proposed by Felix allows adding multiple mappings of buffer
> objects on multiple devices with just one IOCTL.
> 
> Now the 

Re: [PATCH libdrm] omap: add Android build support

[Andrew F. Davis]

On 03/02/2018 12:51 PM, Emil Velikov wrote:
> On 28 February 2018 at 18:54, Andrew F. Davis  wrote:
>> From: Gowtham Tammana 
>>
>> Add Android.mk file to build libdrm_omap library.
>>
> Zero objections on my end, but can we have the use case mentioned in
> the commit message.
> Years ago I was looking for users of the library and I could not find any.
> 

We use it in some older versions of our hardware composer for Android
and our user-space graphics stack, but the goal will be to reduce or
eliminate our dependence on the libdrm_omap specifics if we can. So I
don't have any public users right now.

Andrew

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

Re: [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

[Daniel Vetter]

On Tue, Mar 06, 2018 at 01:32:21PM -0500, Harry Wentland wrote:
> 
> 
> On 2018-03-06 12:13 PM, Daniel Vetter wrote:
> > On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote:
> >> On 2018-03-06 07:18 AM, Ville Syrj??l?? wrote:
> >>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
>  On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
> > From: Ville Syrj??l?? 
> >
> > edid and display_info are protected by mode_config.mutex. Add lockdep
> > asserts to make sure we're not accessing things w/o the lock.
> >
> > FIXME: pretty sure this will blow up with amdgpu as they seem
> > to be doing edid updates even from the modeset path. Need to figure
> > out what to do about that. Maybe protect the edid/display info with
> > with connection_mutex instead of mode_config.mutex?
> 
>  Imo not doing EDID udpates from the modeset path is the right fix. I 
>  can't
>  think of any reasonable reason to do that at least. Can you point me at
>  the relevant amdgpu code pls (I'm lazy, sry)?
> >>>
> >>> It was some MST thing I believe... (should have written it down)
> >>>
> >>> amdgpu_dm_atomic_check() -> dm_update_crtcs_state() ->
> >>> create_stream_for_sink() -> dm_dp_mst_dc_sink_create() ->
> >>> get_edid/update_edid_property
> >>>
> >>
> >> Yeah, it's because the dc_sink carries the EDID and is only created at
> >> this point for us. It's bugged me ever since we did this. Might be time
> >> to think of a solution to it now.
> > 
> > But how does this work? Userspace won't do a modeset without the EDID
> > present and the modes listed, which means you'll never ever end up in
> > atomic check. This really sounds rather wrong.
> > 
> 
> Not sure if this works correctly with atomic userspace.
> 
> I think with legacy userspace we might rely on the get_connector call
> doing .fill_modes > drm_helper_probe_single_connector_modes > .get_modes
> > dm_dp_mst_get_modes > drm_dp_mst_get_edid

Atomic userspace users the exact same ioctls for connector probing, no
change there.

That leaves me wondering why exactly you're doing this in atomic_check.
Just nuke it?
-Daniel

> 
> Harry
> 
> 
> > Only idea I can come up with is that you're abusing the regular pageflip
> > request as a worker thread, but that's some seriously backwards design.
> > -Daniel
> > 
> >>
> >> Harry
> >>
> 
>  Otherwise I think this is a real good patch.
> 
>  Thanks, Daniel
> 
> >
> > Cc: Keith Packard 
> > Cc: Daniel Vetter 
> > Cc: Harry Wentland 
> > Signed-off-by: Ville Syrj??l?? 
> > ---
> >  drivers/gpu/drm/drm_connector.c| 4 
> >  drivers/gpu/drm/drm_edid.c | 2 ++
> >  drivers/gpu/drm/drm_probe_helper.c | 2 +-
> >  3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 122060792b6f..a9f3536f4e94 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1374,6 +1374,8 @@ int 
> > drm_mode_connector_update_edid_property(struct drm_connector *connector,
> > size_t size = 0;
> > int ret;
> >  
> > +   lockdep_assert_held(>mode_config.mutex);
> > +
> > /* ignore requests to set edid when overridden */
> > if (connector->override_edid)
> > return 0;
> > @@ -1770,6 +1772,8 @@ void drm_connector_reset_display_info(struct 
> > drm_connector *connector)
> >  {
> > struct drm_display_info *info = >display_info;
> >  
> > +   lockdep_assert_held(>dev->mode_config.mutex);
> > +
> > memset(info, 0, sizeof(*info));
> >  }
> >  EXPORT_SYMBOL_GPL(drm_connector_reset_display_info);
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 618093c4a039..7f9e9236114b 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4440,6 +4440,8 @@ u32 drm_add_display_info(struct drm_connector 
> > *connector, const struct edid *edi
> > struct drm_display_info *info = >display_info;
> > u32 quirks = edid_get_quirks(edid);
> >  
> > +   lockdep_assert_held(>dev->mode_config.mutex);
> > +
> > info->width_mm = edid->width_cm * 10;
> > info->height_mm = edid->height_cm * 10;
> >  
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 7dc7e635d7e4..2a2afcf72788 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -400,7 +400,7 @@ int drm_helper_probe_single_connector_modes(struct 
> > drm_connector *connector,
> 

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Fixes for 2 regressions that got captured by CI.

Here goes drm-intel-fixes-2018-03-07:

- 2 fixes: 1 for perf and 1 execlist submission race.

Thanks,
Rodrigo.

The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:

  Linux 4.16-rc4 (2018-03-04 14:54:11 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-03-07

for you to fetch changes up to 88d3dfb6a69042381161290c7ce19e1f53fc2a66:

  drm/i915: Suspend submission tasklets around wedging (2018-03-05 16:08:31 
-0800)


- 2 fixes: 1 for perf and 1 execlist submission race.


Chris Wilson (1):
  drm/i915: Suspend submission tasklets around wedging

Lionel Landwerlin (1):
  drm/i915/perf: fix perf stream opening lock

 drivers/gpu/drm/i915/i915_gem.c  |  6 +-
 drivers/gpu/drm/i915/i915_perf.c | 40 +---
 drivers/gpu/drm/i915/intel_lrc.c |  5 +
 3 files changed, 23 insertions(+), 28 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/vc4: Check if plane requires background fill

[Eric Anholt]

Ville Syrjälä  writes:

> On Tue, Mar 06, 2018 at 04:10:33PM -0800, Eric Anholt wrote:
>> Ville Syrjälä  writes:
>> 
>> > On Tue, Mar 06, 2018 at 02:48:38AM +0100, Stefan Schake wrote:
>> >> Considering a single plane only, we have to enable background color
>> >> when the plane has an alpha format and could be blending from the
>> >> background or when it doesn't cover the entire screen.
>> >> 
>> >> Signed-off-by: Stefan Schake 
>> >> ---
>> >>  drivers/gpu/drm/vc4/vc4_drv.h   |  6 ++
>> >>  drivers/gpu/drm/vc4/vc4_plane.c | 15 ++-
>> >>  2 files changed, 20 insertions(+), 1 deletion(-)
>> >> 
>> >> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
>> >> index fefa166..7cc6390 100644
>> >> --- a/drivers/gpu/drm/vc4/vc4_drv.h
>> >> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
>> >> @@ -302,6 +302,12 @@ struct vc4_hvs {
>> >>  
>> >>  struct vc4_plane {
>> >>   struct drm_plane base;
>> >> +
>> >> + /* Set when the plane has per-pixel alpha content or does not cover
>> >> +  * the entire screen. This is a hint to the CRTC that it might need
>> >> +  * to enable background color fill.
>> >> +  */
>> >> + bool needs_bg_fill;
>> >
>> > Looks to me like that should really be a bitmask (or something similar)
>> > in the crtc state.
>> 
>> Why?
>> 
>> In particular, VC4 really doesn't have a fixed number of planes, and the
>> fact that we're exposing just a handful so far is probably a bug.
>
> The problem is that this seems to clobber the device state from the
> .atomic_check() hook. So if you do a CHECK_ONLY atomic ioctl (or
> some later check simply fails and the operation is aborted) you've
> already modified the state of the device, and some later operation
> may then end up doing the wrong thing.
>
> I guess you could track this in the plane struct like here, but as
> with the actual hardware state that shouldn't get modified until
> we're sure the checked state is really meant to be commited to the
> hardware.

Oh, I hadn't noticed it was in vc4_plane, not vc4_plane_state.  Yeah, it
should be in the plane state.


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