[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
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)
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
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)
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 &label { ... } 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 &{ / } {
5 #address-cells = <2>;
6 #size-cells = <2>;
7
[PATCH] drm/vmwgfx: Use kasprintf
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(&channel, RPCI_PROTOCOL_NUM) ||
vmw_send_msg(&channel, msg) ||
vmw_recv_msg(&channel, (void *) &reply, &reply_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(&channel, RPCI_PROTOCOL_NUM) ||
vmw_send_msg(&channel, msg) ||
vmw_close_channel(&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
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
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
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)
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 &label { ... } 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)
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 &label { ... } 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
> 8my_node@feb9 {
> 9compatible = "vendor,device";
[PATCH] video: fbdev: via_aux_vt1632: remove VLA usage
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(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
+ if (!via_aux_read(&drv, 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
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(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
+ if (!via_aux_read(&drv, 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
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
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&D 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
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
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
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
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&D 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
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, &placement);
+
+ 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, &placement);
ret = ttm_bo_mem_space(bo, &placement, &evict_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, &ghost);
+ 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(&bo->mem, 0, sizeof(bo->mem));
+ bo->mem.mem_type = TTM_PL_SYSTEM;
+ bo->ttm = NULL;
+
+ ttm_bo_unreserve(ghost);
+ ttm_bo_unref(&ghost);
+
+ 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
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
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
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 = &a6xx_gpu->gmu;
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_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 = &a6xx_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 (gpu->nr_rings
[PATCH 5/6] drm/msm/Adreno: Refactor some preemption code
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(&a5xx_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(&gpu->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(&a5xx_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(&a5xx_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(&a5xx_gpu->preempt_state,
+ PREEMPT_ABORT);
update_wptr(gpu, a5xx_gpu->cur_ring);
- set_preempt_state(a5xx_gpu, PREEMPT_NONE);
+ adreno_set_preempt_state(&a5xx_gpu->preempt_state,
+ PREEMPT_NONE);
return;
}
@@ -156,7 +129,7 @@ void
[PATCH 4/6] drm/msm/A6xx: Enable preemption for A6xx targets
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, &funcs, 1);
+ ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 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
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(&queue->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(&ctx->queuelock);
@@ -95,6 +103,9 @@ int msm_submitqueue_create(struct drm_device *drm, struct
msm_file_private *ctx,
write_unlock(&ctx->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
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
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
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
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, &connector->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(&connector->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 *connector)
Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node
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
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.
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
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
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(&obj->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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&action=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
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
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&cleanups 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 f
[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference
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
https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #7 from mercuriete --- Created attachment 137877 --> https://bugs.freedesktop.org/attachment.cgi?id=137877&action=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
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 DP compliant, just follow the spec, limit it to the
max value of 4 with
a warnin
[pull] radeon and amdgpu drm-fixes-4.16
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
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);
> > > > > }
> > > > > EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
> > > > >
> > > >
[PATCH v5] drm/pl111: Use max memory bandwidth for resolution
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",
+&priv->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
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
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&action=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)
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: &struct drm_atomic_state pointer > + * @plane: &struct drm_plane iteration cursor > + * @old_plane_state: &struct drm_plane_state iteration cursor for the old > state > + * @new_plane_state: &struct 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: &struct drm_atomic_state pointer > * @plane: &struct 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
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
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)
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
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
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 pressure, it's unlikely that a
Re: [Mesa-dev] [PATCH 01/21] vulkan: Add KHR_display extension using DRM
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
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
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, >> &image_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 comment to say that
Re: New KFD ioctls: taking the skeletons out of the closet
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 enemy until you've measured it and >> > proven
[Bug 81689] Black screen in info-beamer
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
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
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
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
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
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
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
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
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&action=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
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(&property->head, &dev->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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
Re: [PATCH] drm/pl111: Enable device-specific assigned memory
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 = <&vram>;
> }·;
>
> 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",
>&priv->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
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&action=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)
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
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 + drivers/
[Bug 199047] [amdgpu CARRIZO] disabled backlight after S3 resume
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
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 > >> > >> AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_
Re: [PATCH libdrm] drm/atomic: Refuse to add invalid objects to requests
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
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
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 = &rzg1_du_r8a7743_info },
> { .compatible = "renesas,du-r8a7745", .data = &rzg1_du_r8a7745_info },
> @@ -260,6 +280,7 @@ static const struct of_device_id rcar_du
> { .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info },
> { .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info },
> { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info },
> + { .compatible = "renesas,du-r8a77970", .data = &rcar_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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=105369 --- Comment #6 from cd --- Created attachment 137867 --> https://bugs.freedesktop.org/attachment.cgi?id=137867&action=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
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
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 problem is without a lot o
Re: [PATCH libdrm] omap: add Android build support
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
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(&dev->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 = &connector->display_info;
> >
> > + lockdep_assert_held(&connector->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 = &connector->display_info;
> > u32 quirks = edid_get_quirks(edid);
> >
> > + lockdep_assert_held(&connector->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,
> > enum drm_connector_status old_status;
> > struct drm_m
[PULL] drm-intel-fixes
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
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
