[PATCH] drm/radeon: add a force flush to delay work when radeon
Although radeon card fence and wait for gpu to finish processing current batch
rings,
there is still a corner case that radeon lockup work queue may not be fully
flushed,
and meanwhile the radeon_suspend_kms() function has called
pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
> Configuration and Message requests are the only TLPs accepted by a Function in
> the D3hot state. All other received Requests must be handled as Unsupported
> Requests,
> and all received Completions may optionally be handled as Unexpected
> Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address 8800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [] ra = [] ps = Tainted: G
W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = t0 = fff08800e0008010 t1 = 0001
t2 = 8010 t3 = fff7e3c0 t4 = fff7e3c00258
t5 = t6 = 0001 t7 = fff7ef078000
s0 = fff7e3c016e8 s1 = fff7e3c0 s2 = fff7e3c00018
s3 = fff7e3c0 s4 = fff7fff59d80 s5 =
s6 = fff7ef07bd98
a0 = fff7e3c0 a1 = fff7e3c016e8 a2 = 0008
a3 = 0001 a4 = 8f5c28f5c28f5c29 a5 = 810f4338
t8 = 0275 t9 = 809b66f8 t10 = ff6769c5d964b800
t11= b886 pv = 811bea20 at =
gp = 81d89690 sp = aa814126
Disabling lock debugging due to kernel taint
Trace:
[] si_dma_is_lockup+0x34/0xd0
[] radeon_fence_check_lockup+0xd0/0x290
[] process_one_work+0x280/0x550
[] worker_thread+0x70/0x7c0
[] worker_thread+0x130/0x7c0
[] kthread+0x200/0x210
[] worker_thread+0x0/0x7c0
[] kthread+0x14c/0x210
[] ret_from_kernel_thread+0x18/0x20
[] kthread+0x0/0x210
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
<8821> 4821ed21
So force lockup work queue flush to fix this problem.
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 15692cb241fc..e608ca26780a 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1604,6 +1604,9 @@ int radeon_suspend_kms(struct drm_device *dev, bool
suspend,
if (r) {
/* delay GPU reset to resume */
radeon_fence_driver_force_completion(rdev, i);
+ } else {
+ /* finish executing delayed work */
+ flush_delayed_work(&rdev->fence_drv[i].lockup_work);
}
}
--
2.25.1
No virus found
Checked by Hillstone Network AntiVirus
Re: [PATCH 0/2] Add DP MST DSC support to i915
On Wed, Aug 10, 2022 at 04:02:08PM -0400, Lyude Paul wrote: > Btw, what's the plan for this? Figured I'd ask since I noticed this on the ML, > nd I'm now finishing up getting the atomic only MST patches I've been working > on merged :) Current plan is that I need to fix this, as current implementation doesn't seem to work because of my wrong assumption that drm_dp_mst_find_vcpi_slots will fail if no slots are available and then we can fallback to DSC. In reality that function can return whatever bogus value it wants, like 71 slots, while you have only 63 available. The real check is done in drm_dp_mst_atomic_check, which would of course reject that configuration, however by that moment its going to be too late for swithcing to DSC. So looke like I will have to move that check at least partly to where DSC/no DSC decision is done. However if there are multiple displays we get another problem, lets say we have 2 displays requiring 40 vcpi slots each in DSC mode with certain input bpp. We have now either option to reject the whole config or go back and try with another bpp to check if we can reduce amount of slots. Because by default we choose the first one which fits, however by the time when compute_config is called, we still don't have all config computed, which might lead to that last crtc can either run our of vcpi slots or we will have to go back and try recalculating with higher compression ratio. My other question was that DSC was supposed to be "visually" lossless, wondering why we are still trying with different bpps? Could have just set highest compression ratio right away. So need to sort this out first before floating new series. Stan > > On Wed, 2022-08-10 at 11:17 +0300, Stanislav Lisovskiy wrote: > > Currently we have only DSC support for DP SST. > > > > Stanislav Lisovskiy (2): > > drm: Add missing DP DSC extended capability definitions. > > drm/i915: Add DSC support to MST path > > > > drivers/gpu/drm/i915/display/intel_dp.c | 76 +- > > drivers/gpu/drm/i915/display/intel_dp.h | 17 +++ > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 145 > > include/drm/display/drm_dp.h| 10 +- > > 4 files changed, 203 insertions(+), 45 deletions(-) > > > > -- > Cheers, > Lyude Paul (she/her) > Software Engineer at Red Hat >
Re: [PATCH 1/3] dt-bindings: display/msm: Add binding for SC8280XP MDSS
On 11/08/2022 07:01, Bjorn Andersson wrote: > Add binding for the display subsystem and display processing unit in the > Qualcomm SC8280XP platform. > > Signed-off-by: Bjorn Andersson > --- > .../bindings/display/msm/dpu-sc8280xp.yaml| 284 ++ > 1 file changed, 284 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml > b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml > new file mode 100644 > index ..6c25943e639c > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml qcom prefix is needed (also when file is in msm subdir) The file name should be based on compatible, so "qcom,sc8280xp-mdss.yaml" > @@ -0,0 +1,284 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/dpu-sc8280xp.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Display Processing Unit for SC8280XP > + > +maintainers: > + - Bjorn Andersson > + > +description: > + Device tree bindings for MSM Mobile Display Subsystem (MDSS) that > encapsulates > + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device > tree > + bindings of MDSS and DPU are mentioned for SC8280XP. s/Device tree bindings// so just: SC8280XP MSM Mobile Display Subsystem (MDSS) that encapsulates sub-blocks like DPU display controller, DSI and DP interfaces etc. > + > +properties: > + compatible: > +const: qcom,sc8280xp-mdss > + > + reg: > +maxItems: 1 > + > + reg-names: > +const: mdss You do not need reg names for one item, especially if the name is kind of obvious... unless you re-use existing driver which needs it? Then maybe let's change the driver to take first element? > + > + power-domains: > +maxItems: 1 > + > + clocks: > +items: > + - description: Display AHB clock from gcc > + - description: Display AHB clock from dispcc > + - description: Display core clock > + > + clock-names: > +items: > + - const: iface > + - const: ahb > + - const: core > + > + interrupts: > +maxItems: 1 > + > + interrupt-controller: true > + > + "#address-cells": true > + > + "#size-cells": true I see other DPU bindings also specify both as "true". Why not a fixed number (const)? > + > + "#interrupt-cells": > +const: 1 > + > + iommus: > +items: > + - description: Phandle to apps_smmu node with SID mask for Hard-Fail > port0 > + > + ranges: true > + > + interconnects: > +minItems: 2 No need for minItems in such case. > +maxItems: 2 > + > + interconnect-names: > +items: > + - const: mdp0-mem > + - const: mdp1-mem > + > + resets: > +items: > + - description: MDSS_CORE reset > + > +patternProperties: > + "^display-controller@[0-9a-f]+$": > +type: object > +description: Node containing the properties of DPU. additionalProperties:false on this level which will point to missing properties (e.g. opp-table) > + > +properties: > + compatible: > +const: qcom,sc8280xp-dpu > + Best regards, Krzysztof
Re: [PATCH v3 01/10] drm/fourcc: Add drm_format_info_bpp() helper
Hi Daniel,
On Wed, Aug 10, 2022 at 5:59 PM Daniel Vetter wrote:
> On Fri, Jul 08, 2022 at 08:20:46PM +0200, Geert Uytterhoeven wrote:
> > Add a helper to retrieve the actual number of bits per pixel for a
> > plane, taking into account the number of characters and pixels per
> > block for tiled formats.
> >
> > Signed-off-by: Geert Uytterhoeven
> > Reviewed-by: Javier Martinez Canillas
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -370,6 +370,25 @@ unsigned int drm_format_info_block_height(const struct
> > drm_format_info *info,
> > }
> > EXPORT_SYMBOL(drm_format_info_block_height);
> >
> > +/**
> > + * drm_format_info_bpp - number of bits per pixel
> > + * @info: pixel format info
> > + * @plane: plane index
> > + *
> > + * Returns:
> > + * The actual number of bits per pixel, depending on the plane index.
> > + */
> > +unsigned int drm_format_info_bpp(const struct drm_format_info *info, int
> > plane)
> > +{
> > + if (!info || plane < 0 || plane >= info->num_planes)
> > + return 0;
> > +
> > + return info->char_per_block[plane] * 8 /
> > +(drm_format_info_block_width(info, plane) *
> > + drm_format_info_block_height(info, plane));
>
> Do we really needs this for blocky formats where this is potentially
> ill-defined? I think if there's no need then this should also return 0
> when block_width/height != 1, it doesn't make much sense to compute bpp
> when it's not really bits per _pixel_.
Yes, we do need this. For low-color formats, the number of bits
per pixel is less than eight, and block_width is larger than one.
That is actually the point of this patch.
> Minimally this needs to check whether the division actually makes sense or
> whether there's a reminder, and if there's reminder, then fail. But that
> feels like a bad hack and I think we should avoid it if it's not
> absolutely necessary.
Looking at drivers/gpu/drm/drm_fourcc.c, the only supported format
where there can be a remainder is P030, which has 2 spare bits per
32-bit word, and thus is special anyway.
Still, 4 * 8 / 3 = 10, so you get the correct numbers of bits for
the first plane. For the second plane, you get 8 * 8 / 3 = 21,
but as .is_yuv = true, you have to divide that result by two again,
so you get 10 again.
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
Re: [PATCH 1/3] dt-bindings: display/msm: Add binding for SC8280XP MDSS
On 11/08/2022 10:56, Krzysztof Kozlowski wrote:
> On 11/08/2022 07:01, Bjorn Andersson wrote:
>> Add binding for the display subsystem and display processing unit in the
>> Qualcomm SC8280XP platform.
>>
>> Signed-off-by: Bjorn Andersson
>> ---
>> .../bindings/display/msm/dpu-sc8280xp.yaml| 284 ++
>> 1 file changed, 284 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
>> b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
>> new file mode 100644
>> index ..6c25943e639c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc8280xp.yaml
>
> qcom prefix is needed (also when file is in msm subdir)
>
> The file name should be based on compatible, so "qcom,sc8280xp-mdss.yaml"
>
>> @@ -0,0 +1,284 @@
>> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/msm/dpu-sc8280xp.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm Display Processing Unit for SC8280XP
>> +
>> +maintainers:
>> + - Bjorn Andersson
>> +
>> +description:
>> + Device tree bindings for MSM Mobile Display Subsystem (MDSS) that
>> encapsulates
>> + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device
>> tree
>> + bindings of MDSS and DPU are mentioned for SC8280XP.
>
> s/Device tree bindings//
> so just:
>
> SC8280XP MSM Mobile Display Subsystem (MDSS) that encapsulates
> sub-blocks like DPU display controller, DSI and DP interfaces etc.
>
>> +
>> +properties:
>> + compatible:
>> +const: qcom,sc8280xp-mdss
>> +
>> + reg:
>> +maxItems: 1
>> +
>> + reg-names:
>> +const: mdss
>
> You do not need reg names for one item, especially if the name is kind
> of obvious... unless you re-use existing driver which needs it? Then
> maybe let's change the driver to take first element?
OK, I see the driver expects this. It seems it is legacy from
87729e2a7871 ("drm/msm: unify MDSS drivers") times. So it could be
changed to grab first element always (older MDSS with three reg items
still has mdss_phys at first item).
>
>> +
>> + power-domains:
>> +maxItems: 1
>> +
>> + clocks:
>> +items:
>> + - description: Display AHB clock from gcc
>> + - description: Display AHB clock from dispcc
>> + - description: Display core clock
>> +
>> + clock-names:
>> +items:
>> + - const: iface
>> + - const: ahb
>> + - const: core
>> +
>> + interrupts:
>> +maxItems: 1
>> +
>> + interrupt-controller: true
>> +
>> + "#address-cells": true
>> +
>> + "#size-cells": true
>
> I see other DPU bindings also specify both as "true". Why not a fixed
> number (const)?
>
>> +
>> + "#interrupt-cells":
>> +const: 1
>> +
>> + iommus:
>> +items:
>> + - description: Phandle to apps_smmu node with SID mask for Hard-Fail
>> port0
>> +
>> + ranges: true
>> +
>> + interconnects:
>> +minItems: 2
>
> No need for minItems in such case.
>
>> +maxItems: 2
>> +
>> + interconnect-names:
>> +items:
>> + - const: mdp0-mem
>> + - const: mdp1-mem
>> +
>> + resets:
>> +items:
>> + - description: MDSS_CORE reset
>> +
>> +patternProperties:
>> + "^display-controller@[0-9a-f]+$":
>> +type: object
>> +description: Node containing the properties of DPU.
>
> additionalProperties:false on this level
>
> which will point to missing properties (e.g. opp-table)
I'll fix existing bindings which have similar issue.
Best regards,
Krzysztof
Re: [PATCH v2 06/11] dt-bindings: display/msm: move qcom, sc7180-mdss schema to mdss.yaml
On 10/07/2022 12:00, Dmitry Baryshkov wrote: > Move schema for qcom,sc7180-mdss from dpu-sc7180.yaml to mdss.yaml so > that the dpu file describes only the DPU schema. > > Signed-off-by: Dmitry Baryshkov > --- > .../bindings/display/msm/dpu-sc7180.yaml | 149 +- > .../devicetree/bindings/display/msm/mdss.yaml | 45 +- > 2 files changed, 80 insertions(+), 114 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > index d3c3e4b07897..9d4ec0b60c25 100644 > --- a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > @@ -10,151 +10,78 @@ maintainers: >- Krishna Manikandan > > description: | > - Device tree bindings for MSM Mobile Display Subsystem(MDSS) that > encapsulates > - sub-blocks like DPU display controller, DSI and DP interfaces etc. Device > tree > - bindings of MDSS and DPU are mentioned for SC7180 target. > + Device tree bindings for the DPU display controller for SC7180 target. > > properties: >compatible: > items: > - - const: qcom,sc7180-mdss > + - const: qcom,sc7180-dpu > >reg: > -maxItems: 1 > +items: > + - description: Address offset and size for mdp register set > + - description: Address offset and size for vbif register set > >reg-names: > -const: mdss > - > - power-domains: > -maxItems: 1 > +items: > + - const: mdp > + - const: vbif > >clocks: > items: > - - description: Display AHB clock from gcc > - - description: Display AHB clock from dispcc > + - description: Display hf axi clock > + - description: Display ahb clock > + - description: Display rotator clock > + - description: Display lut clock >- description: Display core clock > + - description: Display vsync clock > >clock-names: > items: > + - const: bus >- const: iface > - - const: ahb > + - const: rot > + - const: lut >- const: core > + - const: vsync > >interrupts: > maxItems: 1 > > - interrupt-controller: true > - > - "#address-cells": true > - > - "#size-cells": true > - > - "#interrupt-cells": > -const: 1 > - > - iommus: > -items: > - - description: Phandle to apps_smmu node with SID mask for Hard-Fail > port0 > - > - ranges: true > - > - interconnects: > -items: > - - description: Interconnect path specifying the port ids for data bus > - > - interconnect-names: > -const: mdp0-mem > + power-domains: > +maxItems: 1 > > - resets: > -items: > - - description: MDSS_CORE reset > + operating-points-v2: true > > -patternProperties: > - "^display-controller@[0-9a-f]+$": > -type: object > -description: Node containing the properties of DPU. > + ports: > +$ref: /schemas/graph.yaml#/properties/ports > +description: | > + Contains the list of output ports from DPU device. These ports > + connect to interfaces that are external to the DPU hardware, > + such as DSI, DP etc. Each output port contains an endpoint that > + describes how it is connected to an external interface. > > properties: > - compatible: > -items: > - - const: qcom,sc7180-dpu > - > - reg: > -items: > - - description: Address offset and size for mdp register set > - - description: Address offset and size for vbif register set > - > - reg-names: > -items: > - - const: mdp > - - const: vbif > - > - clocks: > -items: > - - description: Display hf axi clock > - - description: Display ahb clock > - - description: Display rotator clock > - - description: Display lut clock > - - description: Display core clock > - - description: Display vsync clock > - > - clock-names: > -items: > - - const: bus > - - const: iface > - - const: rot > - - const: lut > - - const: core > - - const: vsync > - > - interrupts: > -maxItems: 1 > - > - power-domains: > -maxItems: 1 > - > - operating-points-v2: true > - > - ports: > -$ref: /schemas/graph.yaml#/properties/ports > -description: | > - Contains the list of output ports from DPU device. These ports > - connect to interfaces that are external to the DPU hardware, > - such as DSI, DP etc. Each output port contains an endpoint that > - describes how it is connected to an external interface. > - > -properties: > - port@0: > -$ref: /schemas/graph.yaml#/properties/port > -description: DPU_INTF1 (DSI1) > - > - port@2: > -$ref: /schemas/graph.yaml#/properties/port > -
Re: [PATCH 1/3] dt-bindings: display/msm: Add binding for SC8280XP MDSS
On 11/08/2022 11:04, Krzysztof Kozlowski wrote: >> >> additionalProperties:false on this level >> >> which will point to missing properties (e.g. opp-table) > > I'll fix existing bindings which have similar issue. Hm, I think Dmitry is already working on this: https://lore.kernel.org/all/20220710090040.35193-5-dmitry.barysh...@linaro.org/ so your patches should be on top of his. Best regards, Krzysztof
Re: [Intel-gfx] [PATCH v6 0/4] drm/i915/display: stop HPD workers before display driver unregister
Hi Imre, Jani, Ville, Since one of CI test machines is back (bat-rpls-2) tests are regularly aborted on this machine due to bugs this patchset resolves [1], reviewing/merging these patches would allow to cure the situation on CI. [1]: https://intel-gfx-ci.01.org/tree/drm-tip/bat-rpls-2.html Regards Andrzej On 02.08.2022 14:24, Gwan-gyeong Mun wrote: Hi Jani, Ville and Imre, If there are no problems after reviewing this patch series, could you please merge it? Many thanks, G.G. On 7/22/22 3:51 PM, Andrzej Hajda wrote: Hi Jani, Ville, Arun, This patchset is replacement of patch "drm/i915/display: disable HPD workers before display driver unregister" [1]. Ive decided to split patch into two parts - fbdev and MST, there are different issues. Ive also dropped shutdown path, as it has slightly different requirements, and more importantly I am not able to test properly. v2 (thx Arun for review): - reword of commit message (Arun) - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun) v3: - new patch adding suspended flag, to handle https://gitlab.freedesktop.org/drm/intel/-/issues/5950 v4: - check suspend flag also in i915_digport_work_func v5: - added patch blocking FB creation in case HPD is supended, - added R-B from Arun to patch 3, thx v6: - finally, after getting direct access to bat-rpls-2, I have found the source of last WARN, intel_fbdev_hpd_set_suspend was not called in case of deferred setup, fixed in patch 2. [1]: https://patchwork.freedesktop.org/series/103811/ Regards Andrzej Andrzej Hajda (4): drm/i915/hpd: postpone HPD cancel work after last user suspension drm/i915/fbdev: suspend HPD before fbdev unregistration drm/i915/display: add hotplug.suspended flag drm/i915/fbdev: do not create fbdev if HPD is suspended drivers/gpu/drm/i915/display/intel_display.c | 3 +++ drivers/gpu/drm/i915/display/intel_fbdev.c | 12 ++-- drivers/gpu/drm/i915/display/intel_hotplug.c | 11 ++- drivers/gpu/drm/i915/display/intel_hotplug.h | 2 +- drivers/gpu/drm/i915/i915_driver.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_irq.c | 1 - 7 files changed, 28 insertions(+), 7 deletions(-)
[PATCH 0/5] dt-bindings: display/msm: dpu: opp-table fixes
Hi, There is a conflicting series of https://lore.kernel.org/all/20220710090040.35193-1-dmitry.barysh...@linaro.org/ but I think this one here should go before to fix the issue before the refactoring. Best regards, Krzysztof Cc: Dmitry Baryshkov Cc: Rob Clark Cc: Sean Paul Cc: Abhinav Kumar Krzysztof Kozlowski (5): dt-bindings: display/msm: dpu-msm8998: add missing DPU opp-table dt-bindings: display/msm: dpu-qcm2290: add missing DPU opp-table dt-bindings: display/msm: dpu-sc7180: add missing DPU opp-table dt-bindings: display/msm: dpu-sc7280: add missing DPU opp-table dt-bindings: display/msm: dpu-sdm845: add missing DPU opp-table Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml | 3 +++ Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml | 2 ++ Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml | 2 ++ Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml | 2 ++ Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml | 3 +++ 5 files changed, 12 insertions(+) -- 2.34.1
[PATCH 2/5] dt-bindings: display/msm: dpu-qcm2290: add missing DPU opp-table
The 'display-controller' child (DPU) of Display SubSystem (MDSS) uses
opp-table, so reference it which allows restricting DPU schema to fixed
list of properties.
Fixes: 164f69d9d45a ("dt-bindings: msm: disp: add yaml schemas for QCM2290 DPU
bindings")
Signed-off-by: Krzysztof Kozlowski
---
Cc: Dmitry Baryshkov
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
---
Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
index 734d14de966d..47759c871429 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
@@ -74,6 +74,7 @@ patternProperties:
"^display-controller@[0-9a-f]+$":
type: object
description: Node containing the properties of DPU.
+additionalProperties: false
properties:
compatible:
@@ -113,6 +114,7 @@ patternProperties:
maxItems: 1
operating-points-v2: true
+ opp-table: true
ports:
$ref: /schemas/graph.yaml#/properties/ports
--
2.34.1
[PATCH 3/5] dt-bindings: display/msm: dpu-sc7180: add missing DPU opp-table
The 'display-controller' child (DPU) of Display SubSystem (MDSS) uses
opp-table, so reference it which allows restricting DPU schema to fixed
list of properties.
Fixes: 3d7a0dd8f39b ("dt-bindings: msm: disp: add yaml schemas for DPU
bindings")
Signed-off-by: Krzysztof Kozlowski
---
Cc: Dmitry Baryshkov
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
---
Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
index d3c3e4b07897..d30b6f9bd9d2 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
@@ -73,6 +73,7 @@ patternProperties:
"^display-controller@[0-9a-f]+$":
type: object
description: Node containing the properties of DPU.
+additionalProperties: false
properties:
compatible:
@@ -114,6 +115,7 @@ patternProperties:
maxItems: 1
operating-points-v2: true
+ opp-table: true
ports:
$ref: /schemas/graph.yaml#/properties/ports
--
2.34.1
[PATCH 1/5] dt-bindings: display/msm: dpu-msm8998: add missing DPU opp-table
The 'display-controller' child (DPU) of Display SubSystem (MDSS) uses
opp-table, so reference it which allows restricting DPU schema to fixed
list of properties.
Fixes: 6e986a8f1cf1 ("dt-bindings: display: msm: Add binding for msm8998 dpu")
Signed-off-by: Krzysztof Kozlowski
---
Cc: Dmitry Baryshkov
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
---
Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
index 2df64afb76e6..7ed438bc7dce 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
@@ -62,6 +62,7 @@ patternProperties:
"^display-controller@[0-9a-f]+$":
type: object
description: Node containing the properties of DPU.
+additionalProperties: false
properties:
compatible:
@@ -105,6 +106,8 @@ patternProperties:
maxItems: 1
operating-points-v2: true
+ opp-table: true
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: |
--
2.34.1
[PATCH 4/5] dt-bindings: display/msm: dpu-sc7280: add missing DPU opp-table
The 'display-controller' child (DPU) of Display SubSystem (MDSS) uses
opp-table, so reference it which allows restricting DPU schema to fixed
list of properties.
Fixes: 57fd4f34ddac ("dt-bindings: msm: add DT bindings for sc7280")
Signed-off-by: Krzysztof Kozlowski
---
Cc: Dmitry Baryshkov
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
---
Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
index f427eec3d3a4..5a4bec99b98a 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
@@ -72,6 +72,7 @@ patternProperties:
"^display-controller@[0-9a-f]+$":
type: object
description: Node containing the properties of DPU.
+additionalProperties: false
properties:
compatible:
@@ -112,6 +113,7 @@ patternProperties:
maxItems: 1
operating-points-v2: true
+ opp-table: true
ports:
$ref: /schemas/graph.yaml#/properties/ports
--
2.34.1
[PATCH 5/5] dt-bindings: display/msm: dpu-sdm845: add missing DPU opp-table
The 'display-controller' child (DPU) of Display SubSystem (MDSS) uses
opp-table, so reference it which allows restricting DPU schema to fixed
list of properties.
Fixes: 3d7a0dd8f39b ("dt-bindings: msm: disp: add yaml schemas for DPU
bindings")
Signed-off-by: Krzysztof Kozlowski
---
Cc: Dmitry Baryshkov
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
---
Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
index 2bb8896beffc..aa99201dae3f 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
@@ -65,6 +65,7 @@ patternProperties:
"^display-controller@[0-9a-f]+$":
type: object
description: Node containing the properties of DPU.
+additionalProperties: false
properties:
compatible:
@@ -102,6 +103,8 @@ patternProperties:
maxItems: 1
operating-points-v2: true
+ opp-table: true
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
description: |
--
2.34.1
[bug report] drm/ttm: Fix dummy res NULL ptr deref bug
Hello Arunpravin Paneer Selvam,
This is a semi-automatic email about new static checker warnings.
The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
from Aug 9, 2022, leads to the following Smatch complaint:
drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
warn: variable dereferenced before check 'bo->resource' (see line 907)
drivers/gpu/drm/ttm/ttm_bo.c
906 */
907 if (!ttm_resource_compat(bo->resource, placement)) {
Unchecked dereference here inside the function.
908 ret = ttm_bo_move_buffer(bo, placement, ctx);
909 if (ret)
910 return ret;
911 }
912 /*
913 * We might need to add a TTM.
914 */
915 if (!bo->resource || bo->resource->mem_type == TTM_PL_SYSTEM) {
Checked too late.
This NULL check was added deliberately based on a report from the kbuild
bot, but it's not clear why bo->resource is NULL at this point. Was the
patch tested? There is a sta...@vger.kernel.org but there is no Fixes
tag.
916 ret = ttm_tt_create(bo, true);
917 if (ret)
regards,
dan carpenter
Re: [PATCH v5] drm: Add initial ci/ subdirectory
On 8/10/22 8:24 PM, Rodrigo Siqueira Jordao wrote:
Hi Tomeu,
First of all, nice patch! I just saw it, and I have some basic questions
(I don't understand many of these CI details). I also CC some CI folks
from the display team at AMD.
Thanks for the feedback!
On 2022-07-26 14:16, Tomeu Vizoso wrote:
And use it to store expectations about what the DRM drivers are
supposed to pass in the IGT test suite.
Also include a configuration file that points to the out-of-tree CI
scripts.
By storing the test expectations along the code we can make sure both
stay in sync with each other, and so we can know when a code change
breaks those expectations.
This will allow all contributors to drm to reuse the infrastructure
already in gitlab.freedesktop.org to test the driver on several
generations of the hardware.
v2:
- Fix names of result expectation files to match SoC
- Don't execute tests that are going to skip on all boards
v3:
- Remove tracking of dmesg output during test execution
v4:
- Move up to drivers/gpu/drm
- Add support for a bunch of other drivers
- Explain how to incorporate fixes for CI from a
${TARGET_BRANCH}-external-fixes branch
- Remove tests that pass from expected results file, to reduce the
size of in-tree files
- Add docs about how to deal with outages in automated testing labs
- Specify the exact SHA of the CI scripts to be used
v5:
- Remove unneeded skips from Meson expectations file
- Use a more advanced runner that detects flakes automatically
- Use a more succint format for the expectations
- Run many more tests (and use sharding to finish in time)
- Use skip lists to avoid hanging machines
- Add some build testing
- Build IGT in each pipeline for faster uprevs
- List failures in the GitLab UI
Signed-off-by: Tomeu Vizoso
Reviewed-by: Neil Armstrong
---
Documentation/gpu/automated_testing.rst | 84 ++
drivers/gpu/drm/ci/amdgpu-stoney-fails.txt | 13 +++
drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt | 20 +
drivers/gpu/drm/ci/amdgpu-stoney-skips.txt | 2 +
drivers/gpu/drm/ci/gitlab-ci.yml | 13 +++
drivers/gpu/drm/ci/i915-amly-flakes.txt | 32 +++
drivers/gpu/drm/ci/i915-amly-skips.txt | 2 +
drivers/gpu/drm/ci/i915-apl-fails.txt | 29 +++
drivers/gpu/drm/ci/i915-apl-flakes.txt | 1 +
drivers/gpu/drm/ci/i915-apl-skips.txt | 2 +
drivers/gpu/drm/ci/i915-cml-flakes.txt | 36
drivers/gpu/drm/ci/i915-glk-flakes.txt | 40 +
drivers/gpu/drm/ci/i915-glk-skips.txt | 2 +
drivers/gpu/drm/ci/i915-kbl-fails.txt | 8 ++
drivers/gpu/drm/ci/i915-kbl-flakes.txt | 24 ++
drivers/gpu/drm/ci/i915-kbl-skips.txt | 2 +
drivers/gpu/drm/ci/i915-tgl-fails.txt | 19
drivers/gpu/drm/ci/i915-tgl-flakes.txt | 6 ++
drivers/gpu/drm/ci/i915-tgl-skips.txt | 8 ++
drivers/gpu/drm/ci/i915-whl-fails.txt | 30 +++
drivers/gpu/drm/ci/i915-whl-flakes.txt | 1 +
drivers/gpu/drm/ci/mediatek-mt8173-fails.txt | 29 +++
drivers/gpu/drm/ci/mediatek-mt8183-fails.txt | 10 +++
drivers/gpu/drm/ci/mediatek-mt8183-flakes.txt | 14 +++
drivers/gpu/drm/ci/meson-g12b-fails.txt | 5 ++
drivers/gpu/drm/ci/meson-g12b-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8016-fails.txt | 15
drivers/gpu/drm/ci/msm-apq8016-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8096-fails.txt | 2 +
drivers/gpu/drm/ci/msm-apq8096-flakes.txt | 4 +
drivers/gpu/drm/ci/msm-apq8096-skips.txt | 2 +
drivers/gpu/drm/ci/msm-sc7180-fails.txt | 22 +
drivers/gpu/drm/ci/msm-sc7180-flakes.txt | 14 +++
drivers/gpu/drm/ci/msm-sc7180-skips.txt | 18
drivers/gpu/drm/ci/msm-sdm845-fails.txt | 44 ++
drivers/gpu/drm/ci/msm-sdm845-flakes.txt | 33 +++
drivers/gpu/drm/ci/msm-sdm845-skips.txt | 2 +
drivers/gpu/drm/ci/rockchip-rk3288-fails.txt | 75
drivers/gpu/drm/ci/rockchip-rk3288-flakes.txt | 5 ++
drivers/gpu/drm/ci/rockchip-rk3288-skips.txt | 46 ++
drivers/gpu/drm/ci/rockchip-rk3399-fails.txt | 86 +++
drivers/gpu/drm/ci/rockchip-rk3399-flakes.txt | 25 ++
drivers/gpu/drm/ci/rockchip-rk3399-skips.txt | 5 ++
drivers/gpu/drm/ci/virtio_gpu-none-fails.txt | 38
drivers/gpu/drm/ci/virtio_gpu-none-flakes.txt | 0
drivers/gpu/drm/ci/virtio_gpu-none-skips.txt | 6 ++
46 files changed, 882 insertions(+)
create mode 100644 Documentation/gpu/automated_testing.rst
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-fails.txt
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-flakes.txt
create mode 100644 drivers/gpu/drm/ci/amdgpu-stoney-skips.txt
create mode 100644 drivers/gpu/drm/ci/gitlab-ci.yml
create mode 100644 drivers/gpu/drm/ci/i915-amly-flakes.txt
create mode 100644 driv
Re: [bug report] drm/ttm: Fix dummy res NULL ptr deref bug
Hi Dan,
drm-misc-fixes doesn't have the updated ttm_bo.c file, we have the
updated ttm_bo.c version in
drm-misc-next branch. Please find below for the line number 907.
On 8/11/2022 3:25 PM, Dan Carpenter wrote:
Hello Arunpravin Paneer Selvam,
This is a semi-automatic email about new static checker warnings.
The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
from Aug 9, 2022, leads to the following Smatch complaint:
drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
warn: variable dereferenced before check 'bo->resource' (see line 907)
drivers/gpu/drm/ttm/ttm_bo.c
906 */
907 if (!ttm_resource_compat(bo->resource, placement)) {
Unchecked dereference here inside the function.
|if (!bo->resource || !ttm_resource_compat(bo->resource, placement)) {
we have this version in drm-misc-next Regards, Arun |
908 ret = ttm_bo_move_buffer(bo, placement, ctx);
909 if (ret)
910 return ret;
911 }
912 /*
913 * We might need to add a TTM.
914 */
915 if (!bo->resource || bo->resource->mem_type == TTM_PL_SYSTEM) {
Checked too late.
This NULL check was added deliberately based on a report from the kbuild
bot, but it's not clear why bo->resource is NULL at this point. Was the
patch tested? There is asta...@vger.kernel.org but there is no Fixes
tag.
916 ret = ttm_tt_create(bo, true);
917 if (ret)
regards,
dan carpenter
[PATCH] drm/amdgpu: use native mode for dp aux transfer
When using amdgpu for e8860, the monitor sometimes haven't any signal, and the kernel reports some errors: [ 17.317302][ 2] [ T1045] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* channel eq failed: 5 tries [ 17.326963][ 2] [ T1045] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* channel eq failed But if I use radeon for e8860, everything are always normal, the reason is that radeon use native mode and amdgpu use atombios mode when init dp aux, so when I use native mode for amdgpu, everything are always normal. Signed-off-by: Zhenneng Li Change-Id: Ia9a2be3ab03e56b1c8337fdbf713461196fbc58f --- drivers/gpu/drm/amd/amdgpu/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c | 273 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 + drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 + drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 5 +- 7 files changed, 290 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile index 3e0e2eb7e235..2913cf46f848 100644 --- a/drivers/gpu/drm/amd/amdgpu/Makefile +++ b/drivers/gpu/drm/amd/amdgpu/Makefile @@ -58,7 +58,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \ amdgpu_vm_sdma.o amdgpu_discovery.o amdgpu_ras_eeprom.o amdgpu_nbio.o \ amdgpu_umc.o smu_v11_0_i2c.o amdgpu_fru_eeprom.o amdgpu_rap.o \ amdgpu_fw_attestation.o amdgpu_securedisplay.o \ - amdgpu_eeprom.o amdgpu_mca.o amdgpu_psp_ta.o amdgpu_lsdma.o + amdgpu_eeprom.o amdgpu_mca.o amdgpu_psp_ta.o amdgpu_lsdma.o amdgpu_dp_auxch.o amdgpu-$(CONFIG_PROC_FS) += amdgpu_fdinfo.o diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 30ce6bb6fa77..15e0288b1997 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -238,6 +238,8 @@ extern int amdgpu_num_kcq; #define AMDGPU_VCNFW_LOG_SIZE (32 * 1024) extern int amdgpu_vcnfw_log; +extern int amdgpu_auxch; + #define AMDGPU_VM_MAX_NUM_CTX 4096 #define AMDGPU_SG_THRESHOLD(256*1024*1024) #define AMDGPU_DEFAULT_GTT_SIZE_MB 3072ULL /* 3GB by default */ diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c index 9ba4817a9148..68c8d79e2937 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c @@ -49,7 +49,10 @@ static struct amdgpu_i2c_bus_rec amdgpu_atombios_get_bus_rec_for_i2c_gpio(ATOM_G memset(&i2c, 0, sizeof(struct amdgpu_i2c_bus_rec)); - i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex); + if (amdgpu_auxch) + i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex) * 4; + else + i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex); i2c.mask_data_reg = le16_to_cpu(gpio->usDataMaskRegisterIndex); i2c.en_clk_reg = le16_to_cpu(gpio->usClkEnRegisterIndex); i2c.en_data_reg = le16_to_cpu(gpio->usDataEnRegisterIndex); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c new file mode 100644 index ..22078f1ca936 --- /dev/null +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c @@ -0,0 +1,273 @@ +/* + * Copyright 2015 Red Hat Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: Dave Airlie + */ + +#include "amdgpu.h" + +#defineAUX_SW_RX_OVERFLOW (1 << 8) +#defineAUX_SW_RX_HPD_DISCON(1 << 9) +#defineAUX_SW_RX_PARTIAL_BYTE (1 << 10) +#defineAUX_SW_NON_AUX_MODE (1 << 11) +#defineAUX_SW_RX_SYNC_IN
Re: [PATCH 0/5] clk/qcom: Support gdsc collapse polling using 'reset' inteface
On 8/10/2022 2:35 AM, Bjorn Andersson wrote:
On Sat 30 Jul 04:17 CDT 2022, Akhil P Oommen wrote:
Some clients like adreno gpu driver would like to ensure that its gdsc
is collapsed at hardware during a gpu reset sequence. This is because it
has a votable gdsc which could be ON due to a vote from another subsystem
like tz, hyp etc or due to an internal hardware signal. To allow
this, gpucc driver can expose an interface to the client driver using
reset framework. Using this the client driver can trigger a polling within
the gdsc driver.
This series is rebased on top of linus's master branch.
Related discussion: https://patchwork.freedesktop.org/patch/493144/
Forgive me if I'm assuming too much, but isn't this an extension of:
85a3d920d30a ("clk: qcom: Add a dummy enable function for GX gdsc")
With the additional requirement that disable should really ensure that
the GDSC is turned off?
Also, gpu driver needs a way to ensure cx gdsc was collapsed at least
once before it goes ahead with re-init.
Btw, the patch you mentioned is about gx gdsc in gpucc which is supposed
to be owned by gmu (except when it is in bad shape). But the current
series is about cx gdsc which is shared with other subsystems/drivers.
-Akhil.
Regards,
Bjorn
Akhil P Oommen (5):
dt-bindings: clk: qcom: Support gpu cx gdsc reset
clk: qcom: Allow custom reset ops
clk: qcom: gpucc-sc7280: Add cx collapse reset support
clk: qcom: gdsc: Add a reset op to poll gdsc collapse
arm64: dts: qcom: sc7280: Add Reset support for gpu
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++
drivers/clk/qcom/gdsc.c | 23 +++
drivers/clk/qcom/gdsc.h | 7 +++
drivers/clk/qcom/gpucc-sc7280.c | 6 ++
drivers/clk/qcom/reset.c | 6 ++
drivers/clk/qcom/reset.h | 2 ++
include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++
7 files changed, 46 insertions(+), 4 deletions(-)
--
2.7.4
Re: [PATCH] drm/fb-helper: add virtual screen size check to drm_fb_helper_check_var()
Hi Andrey,
On Thu, Aug 11, 2022 at 12:23 PM Andrey Strachuk wrote:
> Add virtual screen size check to drm_fb_helper_check_var() in
> order to validate userspace input.
>
> Found by Linux Verification Center (linuxtesting.org) with syzkaller.
>
> Signed-off-by: Andrey Strachuk
Thanks for your patch!
> Fixes: 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()")
This Fixes tag is misleading: the bug has existed since basically
forever.
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1355,6 +1355,16 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> (drm_format_info_block_height(fb->format, 0) > 1))
> return -EINVAL;
>
> + /* verify that virtual resolution >= physical resolution */
> + if (var->xres_virtual < var->xres ||
> + var->yres_virtual < var->yres) {
> + drm_dbg_kms(dev, "requested virtual screen size that is "
> + "below the physical size(%ux%u vs. %ux%u)\n",
> + var->xres_virtual, var->yres_virtual,
> + var->xres, var->yres);
> + return -EINVAL;
According to the fbdev rounding rules, invalid values should be rounded
up, if possible. Hence it is better to not return an error, but round up:
if (var->xres_virtual < var->xres)
var->xres_virtual = var->xres;
if (var->yres_virtual < var->yres)
var->yres_virtual = var->yres;
> + }
> +
> /*
> * Changes struct fb_var_screeninfo are currently not pushed back
> * to KMS, hence fail if different settings are requested.
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
Re: [bug report] drm/ttm: Fix dummy res NULL ptr deref bug
On Thu, Aug 11, 2022 at 04:36:33PM +0530, Arunpravin Paneer Selvam wrote:
> Hi Dan,
>
> drm-misc-fixes doesn't have the updated ttm_bo.c file, we have the updated
> ttm_bo.c version in
> drm-misc-next branch. Please find below for the line number 907.
>
> On 8/11/2022 3:25 PM, Dan Carpenter wrote:
> > Hello Arunpravin Paneer Selvam,
> >
> > This is a semi-automatic email about new static checker warnings.
> >
> > The patch cf4b7387c0a8: "drm/ttm: Fix dummy res NULL ptr deref bug"
> > from Aug 9, 2022, leads to the following Smatch complaint:
> >
> > drivers/gpu/drm/ttm/ttm_bo.c:915 ttm_bo_validate()
> > warn: variable dereferenced before check 'bo->resource' (see line 907)
> >
> > drivers/gpu/drm/ttm/ttm_bo.c
> > 906 */
> > 907 if (!ttm_resource_compat(bo->resource, placement)) {
> >
> > Unchecked dereference here inside the function.
>
> |if (!bo->resource || !ttm_resource_compat(bo->resource, placement)) { we
> have this version in drm-misc-next Regards, Arun |
>
Huh... That's very interesting. It appears there was a bug in
drm-misc-next, we applied the fix to the wrong tree, and now both trees
are wrong. The drm-misc-next tree still has the bug and the other tree
has a static checker warning about nonsensical NULL checks.
Eventually drm-misc-next will get merged and everything will work. Is
it too late to remove the bogus "CC: sta...@vger.kernel.org"?
This could have been avoided if the NULL dereference fix had a Fixes tag.
regards,
dan carpenter
Re: [PATCH] i2c: qcom-geni: Fix GPI DMA buffer sync-back
On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote: > Fix i2c transfers using GPI DMA mode for all message types that do not set > the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte"). > > In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(), > and it has to synced back to the message after the transfer is done. > > Add missing assignment of dma buffer in geni_i2c_gpi(). > > Set xferred in i2c_put_dma_safe_msg_buf() to true in case of no error to > ensure the sync-back of this dma buffer to the message. > > Signed-off-by: Robin Reckmann Applied to for-current, thanks! signature.asc Description: PGP signature
Re: [GIT PULL] printk for 5.20
On Tue, Aug 09, 2022 at 03:18:20AM +0200, Thomas Gleixner wrote: > On Tue, Aug 02 2022 at 20:19, Linus Torvalds wrote: > > On Mon, Aug 1, 2022 at 8:08 AM Petr Mladek wrote: > >> > >> - Completely disable printing on consoles with CONFIG_RT. > > And guys, I want to make it really clear how disappointed I am with > > the printk tree lately. There seems to be some kind of hardline > > religious fervor having taken over to make these kinds of "this is how > > it has to be done, screw any sanity or common sense". > ... > > Put another way: not only am I not pulling this, I'm concerned that I > > will not be pulling printk patches in the future either because of > > where these pull requests seem to be trending. > > I really have to stand up for the printk maintainers here. > > Especially Petr has done an extraordinary job in the past few years. > There have been hickups, but with such a semantically ill defined > mechanism like printk() that's not a surprise at all. > > Let me add some historical background here. > > In Sept. 2019, i.e. almost 3 years ago, we all - including you - sat > together at Plumbers in Lisbon and agreed that printk() in it's back > then form is a nightmare not only for PREEMPT_RT. We also agreed back > then that seperating out the console writes into individual printk > threads makes sense because it also gets rid of the fully serializing > nature of printk() which exists for historical but not for technical > reasons. Also the magic oops_in_progress heuristics have been declared > to be just duct tape, as the still existing (after 25+ years of Linux) > situation with graphics demonstrates on a daily basis. We all agreed > that a dedicated atomic_write() which also allows to prioritize your > favourite pet pieve of making laptops more debugable by utilizing > persistant storage simpler and what's more important more reliable. Cutting the more detail stuff below because I'm justing chiming in on the overall direction. I want this. Where "want" means by default and across the board, and "this" the entire printk/console_lock redesign we discussed in Lisbon with threaded printing and properly separate out emergency output and everything else. Because ffs I'm so fed up having to deal with console_lock in graphcis drivers. This has nothing to do with rt or being niche or whatever but just that Petr, John and others are tackling some really nasty corners that everyone just covered with industrial quantities of duct-tape in the past years (decades?) and finally there's real movement (but a bit slower than I hoped for really). I visted linutronix folks a few weeks ago and we talked a bit what we could all do when this mess is sorted and I want it all. *graphics maintainer out* -Daniel > It took whopping 2.5 years to get to the point to reach this seperation > as it required to rewrite the buffers and other infrastructure. This was > very responsible and cautionosly guided by Petr and the other members of > the printk() maintainer team. Along with that went quite some > improvements like realistic timestamping and other details which matter > for dmesg power users. > > The printk threads were added in the 5.19 merge window and unfortunately > reverted between 5.19-rc3 and 5.19-rc4 for the very wrong reason: > >Some embedded boards failed to boot. > > The root cause is missing locking in the init functions of the > related UART drivers. > > This is not a problem of threaded printk(), Those are existing bugs > in these drivers which can be triggered on a 5.18 kernel. They are > hard to trigger and nobody cared so far because they were neither > bisectable nor reliably reproducible. The threaded printk() change > made them reproducible and the bisect pointed at the messenger and > not at the root cause. > > Nevertheless it was decided to throw away valuable work for no real good > reason. That revert costs me constantly ~2 seconds of boot time on one my > main development machines. Not much, but ~10% and I know that quite some > folks in the fastboot camp give a leg for 10%. > > The right decision would have been to offer this by boot or config > parameter and not to throw the baby out with the bathwater. > > I know it's my fault because I was AFK that week... > > Coming back to the commit in question which made you (rightfully) upset. > > I agree that it should never have happened, but OTOH it's a very clear > message of developer frustration to you: > > On one hand you can't get tired of "praising" the RT people about their > responsible approach to solve fundamental shortcomigs in the kernel, but > at the same time you're pulling whatever new fancy "technology" which > comes around the corner and then makes my and your inbox full of > security issues. That's obviously not a problem, right? > > Neither is it a problem that all of these "feature" developers can > rightfully ignore PREEMPT_RT and offload all the resulting problems to >
[PATCH 0/1] tee: Add tee_shm_register_fd
Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a shared memory from a dmabuf file descriptor. Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor drivers/tee/tee_core.c | 38 +++ drivers/tee/tee_shm.c| 99 +++- include/linux/tee_drv.h | 11 + include/uapi/linux/tee.h | 29 4 files changed, 175 insertions(+), 2 deletions(-) -- 2.25.0
[PATCH 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
From: Etienne Carriere
This change allows userland to create a tee_shm object that refers
to a dmabuf reference.
Userland provides a dmabuf file descriptor as buffer reference.
The created tee_shm object exported as a brand new dmabuf reference
used to provide a clean fd to userland. Userland shall closed this new
fd to release the tee_shm object resources. The initial dmabuf resources
are tracked independently through original dmabuf file descriptor.
Once the buffer is registered and until it is released, TEE driver
keeps a refcount on the registered dmabuf structure.
This change only support dmabuf references that relates to physically
contiguous memory buffers.
New tee_shm flag to identify tee_shm objects built from a registered
dmabuf: TEE_SHM_EXT_DMA_BUF. Such tee_shm structures are flagged with
TEE_SHM_EXT_DMA_BUF.
Co-Developed-by: Etienne Carriere
Signed-off-by: Olivier Masse
From: https://github.com/linaro-swg/linux.git
(cherry picked from commit 41e21e5c405530590dc2dd10b2a8dbe64589840f)
---
drivers/tee/tee_core.c | 38 +++
drivers/tee/tee_shm.c| 99 +++-
include/linux/tee_drv.h | 11 +
include/uapi/linux/tee.h | 29
4 files changed, 175 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index 8aa1a4836b92..7c45cbf85eb9 100644
--- a/drivers/tee/tee_core.c
+++ b/drivers/tee/tee_core.c
@@ -355,6 +355,42 @@ tee_ioctl_shm_register(struct tee_context *ctx,
return ret;
}
+static int tee_ioctl_shm_register_fd(struct tee_context *ctx,
+struct tee_ioctl_shm_register_fd_data
__user *udata)
+{
+ struct tee_ioctl_shm_register_fd_data data;
+ struct tee_shm *shm;
+ long ret;
+
+ if (copy_from_user(&data, udata, sizeof(data)))
+ return -EFAULT;
+
+ /* Currently no input flags are supported */
+ if (data.flags)
+ return -EINVAL;
+
+ shm = tee_shm_register_fd(ctx, data.fd);
+ if (IS_ERR(shm))
+ return -EINVAL;
+
+ data.id = shm->id;
+ data.flags = shm->flags;
+ data.size = shm->size;
+
+ if (copy_to_user(udata, &data, sizeof(data)))
+ ret = -EFAULT;
+ else
+ ret = tee_shm_get_fd(shm);
+
+ /*
+* When user space closes the file descriptor the shared memory
+* should be freed or if tee_shm_get_fd() failed then it will
+* be freed immediately.
+*/
+ tee_shm_put(shm);
+ return ret;
+}
+
static int params_from_user(struct tee_context *ctx, struct tee_param *params,
size_t num_params,
struct tee_ioctl_param __user *uparams)
@@ -829,6 +865,8 @@ static long tee_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
return tee_ioctl_shm_alloc(ctx, uarg);
case TEE_IOC_SHM_REGISTER:
return tee_ioctl_shm_register(ctx, uarg);
+ case TEE_IOC_SHM_REGISTER_FD:
+ return tee_ioctl_shm_register_fd(ctx, uarg);
case TEE_IOC_OPEN_SESSION:
return tee_ioctl_open_session(ctx, uarg);
case TEE_IOC_INVOKE:
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 836872467dc6..55a3fbbb022e 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -4,6 +4,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -12,6 +13,14 @@
#include
#include "tee_private.h"
+/* extra references appended to shm object for registered shared memory */
+struct tee_shm_dmabuf_ref {
+ struct tee_shm shm;
+ struct dma_buf *dmabuf;
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+};
+
static void shm_put_kernel_pages(struct page **pages, size_t page_count)
{
size_t n;
@@ -71,7 +80,16 @@ static void release_registered_pages(struct tee_shm *shm)
static void tee_shm_release(struct tee_device *teedev, struct tee_shm *shm)
{
- if (shm->flags & TEE_SHM_POOL) {
+ if (shm->flags & TEE_SHM_EXT_DMA_BUF) {
+ struct tee_shm_dmabuf_ref *ref;
+
+ ref = container_of(shm, struct tee_shm_dmabuf_ref, shm);
+ dma_buf_unmap_attachment(ref->attach, ref->sgt,
+DMA_BIDIRECTIONAL);
+
+ dma_buf_detach(ref->dmabuf, ref->attach);
+ dma_buf_put(ref->dmabuf);
+ } else if (shm->flags & TEE_SHM_POOL) {
teedev->pool->ops->free(teedev->pool, shm);
} else if (shm->flags & TEE_SHM_DYNAMIC) {
int rc = teedev->desc->ops->shm_unregister(shm->ctx, shm);
@@ -195,7 +213,7 @@ struct tee_shm *tee_shm_alloc_user_buf(struct tee_context
*ctx, size_t size)
* tee_client_invoke_func(). The memory allocated is later freed with a
* call to tee_shm_free().
*
- * @returns a pointer to 'struct tee_shm'
+ * @returns a pointer to 'struct tee_shm' on
Re: [PATCH] drm/amdgpu: use native mode for dp aux transfer
On Thu, Aug 11, 2022 at 7:32 AM Zhenneng Li wrote: > > When using amdgpu for e8860, the monitor sometimes haven't any signal, > and the kernel reports some errors: > [ 17.317302][ 2] [ T1045] [drm:amdgpu_atombios_dp_link_train [amdgpu]] > *ERROR* channel eq failed: 5 tries > [ 17.326963][ 2] [ T1045] [drm:amdgpu_atombios_dp_link_train [amdgpu]] > *ERROR* channel eq failed > But if I use radeon for e8860, everything are always normal, the reason is > that radeon use native mode and amdgpu use atombios mode > when init dp aux, so when I use native mode for amdgpu, everything > are always normal. > > Signed-off-by: Zhenneng Li > Change-Id: Ia9a2be3ab03e56b1c8337fdbf713461196fbc58f > --- > drivers/gpu/drm/amd/amdgpu/Makefile | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + > drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 5 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c | 273 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 + > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 + > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 5 +- > 7 files changed, 290 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile > b/drivers/gpu/drm/amd/amdgpu/Makefile > index 3e0e2eb7e235..2913cf46f848 100644 > --- a/drivers/gpu/drm/amd/amdgpu/Makefile > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile > @@ -58,7 +58,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \ > amdgpu_vm_sdma.o amdgpu_discovery.o amdgpu_ras_eeprom.o amdgpu_nbio.o > \ > amdgpu_umc.o smu_v11_0_i2c.o amdgpu_fru_eeprom.o amdgpu_rap.o \ > amdgpu_fw_attestation.o amdgpu_securedisplay.o \ > - amdgpu_eeprom.o amdgpu_mca.o amdgpu_psp_ta.o amdgpu_lsdma.o > + amdgpu_eeprom.o amdgpu_mca.o amdgpu_psp_ta.o amdgpu_lsdma.o > amdgpu_dp_auxch.o > > amdgpu-$(CONFIG_PROC_FS) += amdgpu_fdinfo.o > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > index 30ce6bb6fa77..15e0288b1997 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > @@ -238,6 +238,8 @@ extern int amdgpu_num_kcq; > #define AMDGPU_VCNFW_LOG_SIZE (32 * 1024) > extern int amdgpu_vcnfw_log; > > +extern int amdgpu_auxch; > + > #define AMDGPU_VM_MAX_NUM_CTX 4096 > #define AMDGPU_SG_THRESHOLD(256*1024*1024) > #define AMDGPU_DEFAULT_GTT_SIZE_MB 3072ULL /* 3GB by default */ > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > index 9ba4817a9148..68c8d79e2937 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c > @@ -49,7 +49,10 @@ static struct amdgpu_i2c_bus_rec > amdgpu_atombios_get_bus_rec_for_i2c_gpio(ATOM_G > > memset(&i2c, 0, sizeof(struct amdgpu_i2c_bus_rec)); > > - i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex); > + if (amdgpu_auxch) > + i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex) > * 4; > + else > + i2c.mask_clk_reg = le16_to_cpu(gpio->usClkMaskRegisterIndex); You can drop this change if you convert your aux code to use dword aligned register addresses. > i2c.mask_data_reg = le16_to_cpu(gpio->usDataMaskRegisterIndex); > i2c.en_clk_reg = le16_to_cpu(gpio->usClkEnRegisterIndex); > i2c.en_data_reg = le16_to_cpu(gpio->usDataEnRegisterIndex); > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > new file mode 100644 > index ..22078f1ca936 > --- /dev/null > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dp_auxch.c > @@ -0,0 +1,273 @@ > +/* > + * Copyright 2015 Red Hat Inc. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + * > + * Au
[PATCH] drm/fb-helper: add virtual screen size check to drm_fb_helper_check_var()
Add virtual screen size check to drm_fb_helper_check_var() in
order to validate userspace input.
Found by Linux Verification Center (linuxtesting.org) with syzkaller.
Signed-off-by: Andrey Strachuk
Fixes: 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()")
---
drivers/gpu/drm/drm_fb_helper.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2d4cee6a10ff..d21fe89358af 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1355,6 +1355,16 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
(drm_format_info_block_height(fb->format, 0) > 1))
return -EINVAL;
+ /* verify that virtual resolution >= physical resolution */
+ if (var->xres_virtual < var->xres ||
+ var->yres_virtual < var->yres) {
+ drm_dbg_kms(dev, "requested virtual screen size that is "
+ "below the physical size(%ux%u vs. %ux%u)\n",
+ var->xres_virtual, var->yres_virtual,
+ var->xres, var->yres);
+ return -EINVAL;
+ }
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
--
2.25.1
Re: [PATCH v2 2/3] drm/amd/display: consider DSC pass-through during mode validation
On 2022-08-05 17:13, Hamza Mahfooz wrote: > Add a mode validation routine for DSC pass-through. Both the link from > source to hub, and the link from hub to monitor are checked, according > to the current link training result and full pbn returned by enum path > resource sideband message. > > Pick up the minimum value as the bandwidth bottleneck for the end to > end link bandwidth constraint, and check if the maximum DSC decompression > bandwidth can fit. > > Co-authored-by: Fangzhi Zuo > Signed-off-by: Hamza Mahfooz Hi, Building an arm64 allmodconfig kernel from todays next tag, next-20220811. I can see the following build error. ERROR: modpost: "dc_dsc_compute_bandwidth_range" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "dc_dsc_get_policy_for_timing" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! When I reverted this patch I was able to build an arm64 allmodconfig kernel. Cheers, Anders
[PATCH v2] drm/fb-helper: add virtual screen size check to drm_fb_helper_check_var()
Add virtual screen size check to drm_fb_helper_check_var() in
order to validate userspace input.
Found by Linux Verification Center (linuxtesting.org) with syzkaller.
Signed-off-by: Andrey Strachuk
Fixes: 785b93ef8c30 ("drm/kms: move driver specific fb common code to helper
functions (v2)")
---
drivers/gpu/drm/drm_fb_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2d4cee6a10ff..5c8b211769eb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1355,6 +1355,12 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
(drm_format_info_block_height(fb->format, 0) > 1))
return -EINVAL;
+ /* verify that virtual resolution >= physical resolution */
+ if (var->xres_virtual < var->xres)
+ var->xres_virtual = var->xres;
+ if (var->yres_virtual < var->yres)
+ var->yres_virtual = var->yres;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
--
2.25.1
Re: [PATCH v2] drm/fb-helper: add virtual screen size check to drm_fb_helper_check_var()
Hi Andrey,
On Thu, Aug 11, 2022 at 4:49 PM Andrey Strachuk wrote:
> Add virtual screen size check to drm_fb_helper_check_var() in
> order to validate userspace input.
>
> Found by Linux Verification Center (linuxtesting.org) with syzkaller.
>
> Signed-off-by: Andrey Strachuk
Thanks for the update!
> Fixes: 785b93ef8c30 ("drm/kms: move driver specific fb common code to helper
> functions (v2)")
I'd drop the Fixes tag completely, as the bug was present in the
intel and radeon drivers before. But probably it doesn't matter, as no one
is gonna backport this to v2.6.31 and earlier ;-)
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH v3] drm/msm/dp: check hpd_state before push idle pattern at dp_bridge_disable()
On 8/10/2022 6:00 PM, Abhinav Kumar wrote:
Hi Stephen
On 8/10/2022 5:09 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-08-10 16:57:51)
On 8/10/2022 3:22 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-08-10 12:25:51)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b36f8b6..678289a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1729,10 +1729,20 @@ void dp_bridge_disable(struct drm_bridge
*drm_bridge)
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ u32 state;
dp_display = container_of(dp, struct dp_display_private,
dp_display);
+ mutex_lock(&dp_display->event_mutex);
+
+ state = dp_display->hpd_state;
+ if (state != ST_DISCONNECT_PENDING && state !=
ST_CONNECTED) {
It's concerning that we have to check this at all. Are we still
interjecting into the disable path when the cable is disconnected?
yes,
The problem is not from cable disconnected.
There is a corner case that this function is called at drm shutdown
(drm_release).
At that time, mainlink is not enabled, hence dp_ctrl_push_idle() will
cause system crash.
The mainlink is only disabled when the cable is disconnected though?
Let me put it this way, if we have to check that the state is
"connected" or "disconnected pending" in the disable path then there's
an issue where this driver is being called in unexpected ways. This
driver is fighting the drm core each time there's a state check. We
really need to get rid of the state tracking entirely, and make sure
that the drm core is calling into the driver at the right time, i.e.
bridge disable is only called when the mainlink is enabled, etc.
So if link training failed, we do not send a uevent to usermode and
will bail out here:
rc = dp_ctrl_on_link(dp->ctrl);
if (rc) {
DRM_ERROR("failed to complete DP link training\n");
goto end;
}
So this commit is not coming from usermode but from the drm_release()
path.
Even then, you do have a valid point. DRM framework should not have
caused the disable path to happen without an enable.
I went through the stack mentioned in the issue.
Lets see this part of the stack:
dp_ctrl_push_idle+0x40/0x88
dp_bridge_disable+0x24/0x30
drm_atomic_bridge_chain_disable+0x90/0xbc
drm_atomic_helper_commit_modeset_disables+0x198/0x444
msm_atomic_commit_tail+0x1d0/0x374
In drm_atomic_helper_commit_modeset_disables(), we call
disable_outputs().
AFAICT, this is the only place which has a protection to not call the
disable() flow if it was not enabled here:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_atomic_helper.c#L1063
But that function is only checking crtc_state->active. Thats set by
the usermode:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_atomic_uapi.c#L407
Now, if usermode sets that to true and then crashed it can bypass this
check and we will crash in the location kuogee is trying to fix.
From the issue mentioned in
https://gitlab.freedesktop.org/drm/msm/-/issues/17, the reporter did
mention the usermode crashed.
So this is my tentative analysis of whats happening here.
Ideally yes, we should have been protected by the location mentioned
above in disable_outputs() but looks to me due to the above hypothesis
its getting bypassed.
Thanks
Abhinav
Ii sound likes that there is a hole either at user space or drm.
But that should not cause dp_bridge_disable() at dp driver to crash.
Therefore it is properly to check hdp_state condition at
dp_bridge_disable() to prevent it from crashing.
[PATCH AUTOSEL 5.19 001/105] fbdev: Restart conflicting fb removal loop when unregistering devices
From: Javier Martinez Canillas
[ Upstream commit 3367aa7d74d240261de2543ddb35531ccad9d884 ]
Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, call to remove_conflicting_framebuffers().
This function takes the registration_lock mutex, to prevent a race when
drivers register framebuffer devices. But if a conflicting framebuffer
device is found, the underlaying platform device is unregistered and this
will lead to the platform driver .remove callback to be called. Which in
turn will call to unregister_framebuffer() that takes the same lock.
To prevent this, a struct fb_info.forced_out field was used as indication
to unregister_framebuffer() whether the mutex has to be grabbed or not.
But this could be unsafe, since the fbdev core is making assumptions about
what drivers may or may not do in their .remove callbacks. Allowing to run
these callbacks with the registration_lock held can cause deadlocks, since
the fbdev core has no control over what drivers do in their removal path.
A better solution is to drop the lock before platform_device_unregister(),
so unregister_framebuffer() can take it when called from the fbdev driver.
The lock is acquired again after the device has been unregistered and at
this point the removal loop can be restarted.
Since the conflicting framebuffer device has already been removed, the
loop would just finish when no more conflicting framebuffers are found.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/2022053039.1252432-1-javi...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbmem.c | 22 +++---
include/linux/fb.h | 1 -
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 7ee6eb2fa715..02b0cf2cfafe 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1568,6 +1568,7 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
{
int i;
+restart_removal:
/* check all firmware fbs and kick off if the base addr overlaps */
for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
@@ -1600,12 +1601,23 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
pr_warn("fb%d: no device set\n", i);
do_unregister_framebuffer(registered_fb[i]);
} else if (dev_is_platform(device)) {
- registered_fb[i]->forced_out = true;
+ /*
+* Drop the lock because if the device is
unregistered, its
+* driver will call to
unregister_framebuffer(), that takes
+* this lock.
+*/
+ mutex_unlock(®istration_lock);
platform_device_unregister(to_platform_device(device));
+ mutex_lock(®istration_lock);
} else {
pr_warn("fb%d: cannot remove device\n", i);
do_unregister_framebuffer(registered_fb[i]);
}
+ /*
+* Restart the removal loop now that the device has been
+* unregistered and its associated framebuffer gone.
+*/
+ goto restart_removal;
}
}
}
@@ -1876,13 +1888,9 @@ EXPORT_SYMBOL(register_framebuffer);
void
unregister_framebuffer(struct fb_info *fb_info)
{
- bool forced_out = fb_info->forced_out;
-
- if (!forced_out)
- mutex_lock(®istration_lock);
+ mutex_lock(®istration_lock);
do_unregister_framebuffer(fb_info);
- if (!forced_out)
- mutex_unlock(®istration_lock);
+ mutex_unlock(®istration_lock);
}
EXPORT_SYMBOL(unregister_framebuffer);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 2892145468c9..07fcd0e56682 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -511,7 +511,6 @@ struct fb_info {
} *apertures;
bool skip_vt_switch; /* no VT switch on suspend/resume required */
- bool forced_out; /* set when being removed by another driver */
};
static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
--
2.35.1
[PATCH AUTOSEL 5.19 002/105] drm/r128: Fix undefined behavior due to shift overflowing the constant
From: Borislav Petkov [ Upstream commit 6556551f8848f98eff356c8aacae42c8dd65b2df ] Fix: drivers/gpu/drm/r128/r128_cce.c: In function ‘r128_do_init_cce’: drivers/gpu/drm/r128/r128_cce.c:417:2: error: case label does not reduce to an integer constant case R128_PM4_64BM_64VCBM_64INDBM: ^~~~ drivers/gpu/drm/r128/r128_cce.c:418:2: error: case label does not reduce to an integer constant case R128_PM4_64PIO_64VCPIO_64INDPIO: ^~~~ See https://lore.kernel.org/r/ykwq6%2btih8gqp...@zn.tnic for the gory details as to why it triggers with older gccs only. Reviewed-by: Randy Dunlap Signed-off-by: Borislav Petkov Cc: David Airlie Cc: Daniel Vetter Cc: Alex Deucher Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220405151517.29753-5...@alien8.de Signed-off-by: Sasha Levin --- drivers/gpu/drm/r128/r128_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h index 2e1bc01aa5c9..970e192b0d51 100644 --- a/drivers/gpu/drm/r128/r128_drv.h +++ b/drivers/gpu/drm/r128/r128_drv.h @@ -300,8 +300,8 @@ extern long r128_compat_ioctl(struct file *filp, unsigned int cmd, # define R128_PM4_64PIO_128INDBM (5 << 28) # define R128_PM4_64BM_128INDBM (6 << 28) # define R128_PM4_64PIO_64VCBM_64INDBM(7 << 28) -# define R128_PM4_64BM_64VCBM_64INDBM (8 << 28) -# define R128_PM4_64PIO_64VCPIO_64INDPIO (15 << 28) +# define R128_PM4_64BM_64VCBM_64INDBM (8U << 28) +# define R128_PM4_64PIO_64VCPIO_64INDPIO (15U << 28) # define R128_PM4_BUFFER_CNTL_NOUPDATE(1 << 27) #define R128_PM4_BUFFER_WM_CNTL0x0708 -- 2.35.1
[PATCH AUTOSEL 5.19 006/105] drm/panfrost: Handle HW_ISSUE_TTRX_2968_TTRX_3162
From: Alyssa Rosenzweig
[ Upstream commit 382435709516c1a7dc3843872792abf95e786c83 ]
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Reviewed-by: Steven Price
Signed-off-by: Alyssa Rosenzweig
Link:
https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-3-alyssa.rosenzw...@collabora.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_regs.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index aa89926742fd..295bef27fb55 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -108,6 +108,9 @@ static void panfrost_gpu_init_quirks(struct panfrost_device
*pfdev)
quirks |= SC_LS_ALLOW_ATTR_TYPES;
}
+ if (panfrost_has_hw_issue(pfdev, HW_ISSUE_TTRX_2968_TTRX_3162))
+ quirks |= SC_VAR_ALGORITHM;
+
if (panfrost_has_hw_feature(pfdev, HW_FEATURE_TLS_HASHING))
quirks |= SC_TLS_HASH_ENABLE;
diff --git a/drivers/gpu/drm/panfrost/panfrost_issues.h
b/drivers/gpu/drm/panfrost/panfrost_issues.h
index 501a76c5e95f..41a714ce6fce 100644
--- a/drivers/gpu/drm/panfrost/panfrost_issues.h
+++ b/drivers/gpu/drm/panfrost/panfrost_issues.h
@@ -125,6 +125,9 @@ enum panfrost_hw_issue {
* kernel must fiddle with L2 caches to prevent data leakage */
HW_ISSUE_TGOX_R1_1234,
+ /* Must set SC_VAR_ALGORITHM */
+ HW_ISSUE_TTRX_2968_TTRX_3162,
+
HW_ISSUE_END
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 0b6cd8fdcb47..accb4fa3adb8 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -195,6 +195,7 @@
#define SC_TLS_HASH_ENABLE BIT(17)
#define SC_LS_ATTR_CHECK_DISABLE BIT(18)
#define SC_ENABLE_TEXGRD_FLAGS BIT(25)
+#define SC_VAR_ALGORITHM BIT(29)
/* End SHADER_CONFIG register */
/* TILER_CONFIG register */
--
2.35.1
[PATCH AUTOSEL 5.19 005/105] drm/nouveau: clear output poll workers before nouveau_fbcon_destroy()
From: Mark Menzynski [ Upstream commit 6b03816f869529393b37d03e5d75b68f7365a7a4 ] Resources needed for output poll workers are destroyed in nouveau_fbcon_fini() before output poll workers are cleared in nouveau_display_fini(). This means there is a time between fbcon_fini() and display_fini(), where if output poll happens, it crashes. This patch introduces another output poll clearing before fbcon resources are destroyed. BUG: KASAN: use-after-free in __drm_fb_helper_initial_config_and_unlock.cold+0x1f3/0x291 [drm_kms_helper] Cc: Ben Skeggs Cc: Karol Herbst Cc: Lyude Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Mark Menzynski Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220523113541.10562-1-mmenz...@redhat.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 4f9b3aa5deda..5226323e55d3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -39,6 +39,7 @@ #include #include +#include #include #include #include @@ -605,6 +606,7 @@ nouveau_fbcon_fini(struct drm_device *dev) if (!drm->fbcon) return; + drm_kms_helper_poll_fini(dev); nouveau_fbcon_accel_fini(dev); nouveau_fbcon_destroy(dev, drm->fbcon); kfree(drm->fbcon); -- 2.35.1
[PATCH AUTOSEL 5.19 007/105] drm/panfrost: Don't set L2_MMU_CONFIG quirks
From: Alyssa Rosenzweig [ Upstream commit d8e53d8a4e0ae842ef5e83e0dfb0796980f710cf ] L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs define slightly different MAX_READS and MAX_WRITES fields, which throttle outstanding reads and writes when set to non-zero values. When left as zero, reads and writes are not throttled. Both kbase and panfrost always zero these registers. Per discussion with Steven Price, there are two reasons these quirks may be used: 1. Simulating slower memory subsystems. This use case is only of interest to system-on-chip designers; it is not relevant to mainline. 2. Working around broken memory subsystems. Hopefully we never see this case in mainline. If we do, we'll need to set this register based on an SoC-compatible, rather than generally matching on the GPU model. To the best of our knowledge, these fields are zero at reset, so the write is not necessary. Let's remove the write to aid porting to new Mali GPUs, which have different layouts for the L2_MMU_CONFIG register. Suggested-by: Steven Price Reviewed-by: Steven Price Signed-off-by: Alyssa Rosenzweig Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-8-alyssa.rosenzw...@collabora.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/panfrost/panfrost_gpu.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c b/drivers/gpu/drm/panfrost/panfrost_gpu.c index 295bef27fb55..e1a6e763d0dc 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c @@ -127,18 +127,6 @@ static void panfrost_gpu_init_quirks(struct panfrost_device *pfdev) gpu_write(pfdev, GPU_TILER_CONFIG, quirks); - quirks = gpu_read(pfdev, GPU_L2_MMU_CONFIG); - - /* Limit read & write ID width for AXI */ - if (panfrost_has_hw_feature(pfdev, HW_FEATURE_3BIT_EXT_RW_L2_MMU_CONFIG)) - quirks &= ~(L2_MMU_CONFIG_3BIT_LIMIT_EXTERNAL_READS | - L2_MMU_CONFIG_3BIT_LIMIT_EXTERNAL_WRITES); - else - quirks &= ~(L2_MMU_CONFIG_LIMIT_EXTERNAL_READS | - L2_MMU_CONFIG_LIMIT_EXTERNAL_WRITES); - - gpu_write(pfdev, GPU_L2_MMU_CONFIG, quirks); - quirks = 0; if ((panfrost_model_eq(pfdev, 0x860) || panfrost_model_eq(pfdev, 0x880)) && pfdev->features.revision >= 0x2000) -- 2.35.1
[PATCH AUTOSEL 5.19 008/105] drm/panfrost: Add arm, mali-valhall-jm compatible
From: Alyssa Rosenzweig
[ Upstream commit 952cd974509251d6b5074bc3677b8297826a6ef1 ]
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
v2: Use arm,mali-valhall-jm compatible.
Reviewed-by: Steven Price
Signed-off-by: Alyssa Rosenzweig
Link:
https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-10-alyssa.rosenzw...@collabora.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index b1e6d238674f..2d870cf73b07 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -665,6 +665,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t860", .data = &default_data, },
{ .compatible = "arm,mali-t880", .data = &default_data, },
{ .compatible = "arm,mali-bifrost", .data = &default_data, },
+ { .compatible = "arm,mali-valhall-jm", .data = &default_data, },
{ .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
{}
};
--
2.35.1
[PATCH AUTOSEL 5.19 013/105] drm/probe-helper: Default to 640x480 if no EDID on DP
From: Douglas Anderson
[ Upstream commit fae7d186403ee5a9375ec75938e0de99718e066a ]
If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. Since we have no true information about the connected
display, these modes are essentially guesses but better than nothing.
At the moment, none of the modes returned is marked as preferred, but
the modes are sorted such that the higher resolution modes are listed
first.
When userspace sees these modes presented by the kernel it needs to
figure out which one to pick. At least one userspace, ChromeOS [1]
seems to use the rules (which seem pretty reasonable):
1. Try to pick the first mode marked as preferred.
2. Try to pick the mode which matches the first detailed timing
descriptor in the EDID.
3. If no modes were marked as preferred then pick the first mode.
Unfortunately, userspace's rules combined with what the kernel is
doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of
the DP 1.4a Link CTS. That test case says that, while it's OK to allow
some implementation-specific fall-back modes if the EDID is bad that
userspace should _default_ to 640x480.
Let's fix this by marking 640x480 as default for DP in the no-EDID
case.
NOTES:
- In the discussion around v3 of this patch [2] there was talk about
solving this in userspace and I even implemented a patch that would
have solved this for ChromeOS, but then the discussion turned back
to solving this in the kernel.
- Also in the discussion of v3 [2] it was requested to limit this
change to just DP since folks were worried that it would break some
subtle corner case on VGA or HDMI.
[1]
https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488
[2]
https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
Signed-off-by: Douglas Anderson
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Acked-by: Jani Nikula
Reviewed-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_probe_helper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 682359512996..2c7902b16321 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -516,8 +516,17 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
count = drm_add_override_edid_modes(connector);
if (count == 0 && (connector->status == connector_status_connected ||
- connector->status == connector_status_unknown))
+ connector->status == connector_status_unknown)) {
count = drm_add_modes_noedid(connector, 1024, 768);
+
+ /*
+* Section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a
+* Link CTS specifies that 640x480 (the official "failsafe"
+* mode) needs to be the default if there's no EDID.
+*/
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ drm_set_preferred_mode(connector, 640, 480);
+ }
count += drm_helper_probe_add_cmdline_mode(connector);
if (count == 0)
goto prune;
--
2.35.1
[PATCH AUTOSEL 5.19 012/105] drm/amd/display: Detect dpcd_rev when hotplug mst monitor
From: Wayne Lin
[ Upstream commit 453b0016a054df0f442fda8a145b97a33816cab9 ]
[Why]
Once mst topology is constructed, later on new connected monitors
are reported to source by CSN message. Within CSN, there is no
carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the
result, we might leave some ports connected to DP but without DPCD
revision number which will affect us determining the capability of
the DP Rx.
[How]
Send out remote DPCD read when the port's dpcd_rev is 0x0 in
detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the
return value is 0x0, it's likely the DP1.2 DP Rx then we reques
revision from DPCD 0x0 again.
Reviewed-by: Hersen Wu
Acked-by: Hamza Mahfooz
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2b9b095e5f03..1c02d873950d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -361,12 +361,48 @@ dm_dp_mst_detect(struct drm_connector *connector,
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct amdgpu_dm_connector *master = aconnector->mst_port;
+ struct drm_dp_mst_port *port = aconnector->port;
+ int connection_status;
if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, ctx, &master->mst_mgr,
+ connection_status = drm_dp_mst_detect_port(connector, ctx,
&master->mst_mgr,
aconnector->port);
+
+ if (port->pdt != DP_PEER_DEVICE_NONE && !port->dpcd_rev) {
+ uint8_t dpcd_rev;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&port->aux, DP_DP13_DPCD_REV,
&dpcd_rev);
+
+ if (ret == 1) {
+ port->dpcd_rev = dpcd_rev;
+
+ /* Could be DP1.2 DP Rx case*/
+ if (!dpcd_rev) {
+ ret = drm_dp_dpcd_readb(&port->aux,
DP_DPCD_REV, &dpcd_rev);
+
+ if (ret == 1)
+ port->dpcd_rev = dpcd_rev;
+ }
+
+ if (!dpcd_rev)
+ DRM_DEBUG_KMS("Can't decide DPCD revision
number!");
+ }
+
+ /*
+* Could be legacy sink, logical port etc on DP1.2.
+* Will get Nack under these cases when issue remote
+* DPCD read.
+*/
+ if (ret != 1)
+ DRM_DEBUG_KMS("Can't access DPCD");
+ } else if (port->pdt == DP_PEER_DEVICE_NONE) {
+ port->dpcd_rev = 0;
+ }
+
+ return connection_status;
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
--
2.35.1
[PATCH AUTOSEL 5.19 011/105] drm/amd/display: fix system hang when PSR exits
From: David Zhang
[ Upstream commit 6cc5c77300afbb285c4f41e04f3435ae3c484c40 ]
[why]
When DC driver send PSR exit dmub command to DMUB FW, it might not
wait until PSR exit. Then it may hit the following deadlock situation.
1. DC driver send HW LOCK command to DMUB FW due to frame update
2. DMUB FW Set the HW lock
3. DMUB execute PSR exit sequence and stuck at polling DPG Pending
register due to the HW Lock is set
4. DC driver ask DMUB FW to unlock HW lock, but DMUB FW is polling
DPG pending register
[how]
The reason why DC driver doesn't wait until PSR exit is because some of
the PSR state machine state is not update the dc driver. So when DC
driver read back the PSR state, it take the state for PSR inactive.
Signed-off-by: David Zhang
Acked-by: Leo Li
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dc_types.h | 7 +++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 16
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index 2ba9f528c0fe..f1f11b3c205f 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -657,10 +657,17 @@ enum dc_psr_state {
PSR_STATE4b,
PSR_STATE4c,
PSR_STATE4d,
+ PSR_STATE4_FULL_FRAME,
+ PSR_STATE4a_FULL_FRAME,
+ PSR_STATE4b_FULL_FRAME,
+ PSR_STATE4c_FULL_FRAME,
+ PSR_STATE4_FULL_FRAME_POWERUP,
PSR_STATE5,
PSR_STATE5a,
PSR_STATE5b,
PSR_STATE5c,
+ PSR_STATE_HWLOCK_MGR,
+ PSR_STATE_POLLVUPDATE,
PSR_STATE_INVALID = 0xFF
};
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index 1d4f0c45b536..f941aa107dc6 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -74,6 +74,22 @@ static enum dc_psr_state convert_psr_state(uint32_t
raw_state)
state = PSR_STATE5b;
else if (raw_state == 0x53)
state = PSR_STATE5c;
+ else if (raw_state == 0x4A)
+ state = PSR_STATE4_FULL_FRAME;
+ else if (raw_state == 0x4B)
+ state = PSR_STATE4a_FULL_FRAME;
+ else if (raw_state == 0x4C)
+ state = PSR_STATE4b_FULL_FRAME;
+ else if (raw_state == 0x4D)
+ state = PSR_STATE4c_FULL_FRAME;
+ else if (raw_state == 0x4E)
+ state = PSR_STATE4_FULL_FRAME_POWERUP;
+ else if (raw_state == 0x60)
+ state = PSR_STATE_HWLOCK_MGR;
+ else if (raw_state == 0x61)
+ state = PSR_STATE_POLLVUPDATE;
+ else
+ state = PSR_STATE_INVALID;
return state;
}
--
2.35.1
[PATCH AUTOSEL 5.19 016/105] drm/amd/display: Correct min comp buffer size
From: Duncan Ma
[ Upstream commit 0c56705d8aae9696348cc320b71d531ede001b79 ]
[Why]
In 3-way mpo pipes, there is a case that we
overbook the CRB buffer size. At rare instances,
overbooking the crb will cause underflow. This only
happens when det_size changes dynamically
based on pipe_cnt.
[How]
Set min compbuff size to 1 segment when preparing BW.
Reviewed-by: Dmytro Laktyushkin
Acked-by: Hamza Mahfooz
Signed-off-by: Duncan Ma
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
index 54db2eca9e6b..1b02f0ebe957 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn31/dcn31_fpu.c
@@ -201,7 +201,7 @@ struct _vcs_dpi_ip_params_st dcn3_15_ip = {
.hostvm_max_page_table_levels = 2,
.rob_buffer_size_kbytes = 64,
.det_buffer_size_kbytes = DCN3_15_DEFAULT_DET_SIZE,
- .min_comp_buffer_size_kbytes = DCN3_15_MIN_COMPBUF_SIZE_KB,
+ .min_comp_buffer_size_kbytes = 64,
.config_return_buffer_size_in_kbytes = 1024,
.compressed_buffer_segment_size_in_kbytes = 64,
.meta_fifo_size_in_kentries = 32,
@@ -297,6 +297,7 @@ struct _vcs_dpi_ip_params_st dcn3_16_ip = {
.hostvm_max_page_table_levels = 2,
.rob_buffer_size_kbytes = 64,
.det_buffer_size_kbytes = DCN3_16_DEFAULT_DET_SIZE,
+ .min_comp_buffer_size_kbytes = 64,
.config_return_buffer_size_in_kbytes = 1024,
.compressed_buffer_segment_size_in_kbytes = 64,
.meta_fifo_size_in_kentries = 32,
--
2.35.1
[PATCH AUTOSEL 5.19 017/105] drm/amd/display: Fix dpp dto for disabled pipes
From: Duncan Ma [ Upstream commit d4965c53b95d7533dfc2309d2fc25838bd33220e ] [Why] When switching from 1 pipe to 4to1 mpc combine, DppDtoClk aren't enabled for the disabled pipes pior to programming the pipes. Upon optimizing bandwidth, DppDto are enabled causing intermittent underflow. [How] Update dppclk dto whenever pipe are flagged to enable. Reviewed-by: Dmytro Laktyushkin Reviewed-by: Nicholas Kazlauskas Reviewed-by: Hansen Dsouza Acked-by: Hamza Mahfooz Signed-off-by: Duncan Ma Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c index ec6aa8d8b251..8b2c15a3cd92 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c @@ -1412,11 +1412,15 @@ static void dcn20_update_dchubp_dpp( struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; struct dc_plane_state *plane_state = pipe_ctx->plane_state; + struct dccg *dccg = dc->res_pool->dccg; bool viewport_changed = false; if (pipe_ctx->update_flags.bits.dppclk) dpp->funcs->dpp_dppclk_control(dpp, false, true); + if (pipe_ctx->update_flags.bits.enable) + dccg->funcs->update_dpp_dto(dccg, dpp->inst, pipe_ctx->plane_res.bw.dppclk_khz); + /* TODO: Need input parameter to tell current DCHUB pipe tie to which OTG * VTG is within DCHUBBUB which is commond block share by each pipe HUBP. * VTG is 1:1 mapping with OTG. Each pipe HUBP will select which VTG -- 2.35.1
[PATCH AUTOSEL 5.19 019/105] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 8c01a7f0e027..84843b3b3aef 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -833,7 +833,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.19 020/105] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 310c322c7112..0981948bd9ed 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(&sa_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(&sa_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 5.19 018/105] drm/amd/display: Reduce frame size in the bouding box for DCN20
From: Rodrigo Siqueira
[ Upstream commit c55300ad4a1814bac9191a4d2c7b0d74273aec7c ]
GCC throw warnings for the function dcn20_update_bounding_box due to its
frame size that looks like this:
error: the frame size of 1936 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
This commit fixes this issue by eliminating an intermediary variable
that creates a large array.
Cc: Stephen Rothwell
Cc: Hamza Mahfooz
Cc: Aurabindo Pillai
Reviewed-by: Harry Wentland
Reviewed-by: Alex Deucher
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 38 +--
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index f79dd40f8d81..48df4f225ac7 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -1428,21 +1428,20 @@ void dcn20_calculate_wm(
void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_st *bb,
struct pp_smu_nv_clock_table *max_clocks, unsigned int
*uclk_states, unsigned int num_states)
{
- struct _vcs_dpi_voltage_scaling_st
calculated_states[DC__VOLTAGE_STATES];
- int i;
int num_calculated_states = 0;
int min_dcfclk = 0;
+ int i;
dc_assert_fp_enabled();
if (num_states == 0)
return;
- memset(calculated_states, 0, sizeof(calculated_states));
+ memset(bb->clock_limits, 0, sizeof(bb->clock_limits));
- if (dc->bb_overrides.min_dcfclk_mhz > 0)
+ if (dc->bb_overrides.min_dcfclk_mhz > 0) {
min_dcfclk = dc->bb_overrides.min_dcfclk_mhz;
- else {
+ } else {
if (ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev))
min_dcfclk = 310;
else
@@ -1453,36 +1452,35 @@ void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_s
for (i = 0; i < num_states; i++) {
int min_fclk_required_by_uclk;
- calculated_states[i].state = i;
- calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
+ bb->clock_limits[i].state = i;
+ bb->clock_limits[i].dram_speed_mts = uclk_states[i] * 16 / 1000;
// FCLK:UCLK ratio is 1.08
min_fclk_required_by_uclk = div_u64(((unsigned long
long)uclk_states[i]) * 1080,
100);
- calculated_states[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
+ bb->clock_limits[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
- calculated_states[i].socclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
- max_clocks->socClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].socclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
+ max_clocks->socClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dcfclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
- max_clocks->dcfClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].dcfclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
+ max_clocks->dcfClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dispclk_mhz =
max_clocks->displayClockInKhz / 1000;
- calculated_states[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
- calculated_states[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
+ bb->clock_limits[i].dispclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
- calculated_states[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
+ bb->clock_limits[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
num_calculated_states++;
}
- calculated_states[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].fabricclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].dcfclk_mhz =
max_clocks->dcfClockInKhz / 1000;
+ bb->clock_limits[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
+ bb->clock
[PATCH AUTOSEL 5.19 021/105] udmabuf: Set the DMA mask for the udmabuf device (v2)
From: Vivek Kasireddy
[ Upstream commit 9e9fa6a9198b767b00f48160800128e83a038f9f ]
If the DMA mask is not set explicitly, the following warning occurs
when the userspace tries to access the dma-buf via the CPU as
reported by syzbot here:
WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188
__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Modules linked in:
CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted
5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0
83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45
31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00
RSP: 0018:c90002a07d68 EFLAGS: 00010293
RAX: RBX: RCX:
RDX: 88807e25e2c0 RSI: 81649e91 RDI: 88801b848408
RBP: 88801b848000 R08: 0002 R09: 88801d86c74f
R10: 81649d72 R11: 0001 R12: 0002
R13: 88801d86c680 R14: 0001 R15:
FS: 56e30300() GS:8880b9d0()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 20cc CR3: 1d74a000 CR4: 003506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264
get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72
begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126
dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164
dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f62fcf530f9
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffe3edab9b8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: RCX: 7f62fcf530f9
RDX: 2200 RSI: 40086200 RDI: 0006
RBP: 7f62fcf170e0 R08: R09:
R10: R11: 0246 R12: 7f62fcf17170
R13: R14: R15:
v2: Dont't forget to deregister if DMA mask setup fails.
Reported-by: syzbot+10e27961f4da37c44...@syzkaller.appspotmail.com
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
Link:
http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasire...@intel.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/dma-buf/udmabuf.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 9631f2fd2faf..38e8767ec371 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -368,7 +368,23 @@ static struct miscdevice udmabuf_misc = {
static int __init udmabuf_dev_init(void)
{
- return misc_register(&udmabuf_misc);
+ int ret;
+
+ ret = misc_register(&udmabuf_misc);
+ if (ret < 0) {
+ pr_err("Could not initialize udmabuf device\n");
+ return ret;
+ }
+
+ ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device,
+ DMA_BIT_MASK(64));
+ if (ret < 0) {
+ pr_err("Could not setup DMA mask for udmabuf device\n");
+ misc_deregister(&udmabuf_misc);
+ return ret;
+ }
+
+ return 0;
}
static void __exit udmabuf_dev_exit(void)
--
2.35.1
[PATCH AUTOSEL 5.19 025/105] drm/amd/display: Fix monitor flash issue
From: Shah Dharati
[ Upstream commit b840b64bc8ed3fc46f6d6aa7f97c43862a33bea5 ]
[Why & How]
For a some specific monitors, when connected on boot or hot plug,
monitor flash for 1/2 seconds can happen during first HDCP query
operation. Ading some delay in the init sequence for these monitors
fixes the issue, so it is implemented as monitor specific patch.
Co-authored-by: Shah Dharati
Reviewed-by: Hansen Dsouza
Reviewed-by: Nicholas Kazlauskas
Acked-by: Hamza Mahfooz
Signed-off-by: Shah Dharati
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
index 1f4095b26409..c5f6c11de7e5 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
@@ -524,7 +524,7 @@ enum mod_hdcp_status mod_hdcp_hdcp2_dp_transition(struct
mod_hdcp *hdcp,
set_watchdog_in_ms(hdcp, 3000, output);
set_state_id(hdcp, output, D2_A6_WAIT_FOR_RX_ID_LIST);
} else {
- callback_in_ms(0, output);
+ callback_in_ms(1, output);
set_state_id(hdcp, output, D2_SEND_CONTENT_STREAM_TYPE);
}
break;
--
2.35.1
[PATCH AUTOSEL 5.19 038/105] drm/bridge/tc358775: Fix DSI clock division for vsync delay calculation
From: Jiri Vanek [ Upstream commit 993a87917c2af59efb0ee1ce43c878ca8790ba1c ] Use the same PCLK divide option (divide DSI clock to generate pixel clock) which is set to LVDS Configuration Register (LVCFG) also for a VSync delay calculation. Without this change an auxiliary variable could underflow during the calculation for some dual-link LVDS panels and then calculated VSync delay is wrong. This leads to a shifted picture on a panel. Tested-by: Jiri Vanek Signed-off-by: Jiri Vanek Reviewed-by: Vinay Simha BN Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/2022061521.1501-3-jirivan...@gmail.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358775.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358775.c b/drivers/gpu/drm/bridge/tc358775.c index 62a7ef352daa..dd18be95207b 100644 --- a/drivers/gpu/drm/bridge/tc358775.c +++ b/drivers/gpu/drm/bridge/tc358775.c @@ -429,7 +429,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge) val = TC358775_VPCTRL_MSF(1); dsiclk = mode->crtc_clock * 3 * tc->bpc / tc->num_dsi_lanes / 1000; - clkdiv = dsiclk / DIVIDE_BY_3 * tc->lvds_link; + clkdiv = dsiclk / (tc->lvds_link == DUAL_LINK ? DIVIDE_BY_6 : DIVIDE_BY_3); byteclk = dsiclk / 4; t1 = hactive * (tc->bpc * 3 / 8) / tc->num_dsi_lanes; t2 = ((10 / clkdiv)) * (hactive + hback_porch + hsync_len + hfront_porch) / 1000; -- 2.35.1
[PATCH AUTOSEL 5.19 044/105] drm/amdkfd: Free queue after unmap queue success
From: Philip Yang
[ Upstream commit ab8529b0cdb271d9b222cbbddb2641f3fca5df8f ]
After queue unmap or remove from MES successfully, free queue sysfs
entries, doorbell and remove from queue list. Otherwise, application may
destroy queue again, cause below kernel warning or crash backtrace.
For outstanding queues, either application forget to destroy or failed
to destroy, kfd_process_notifier_release will remove queue sysfs
entries, kfd_process_wq_release will free queue doorbell.
v2: decrement_queue_count for MES queue
refcount_t: underflow; use-after-free.
WARNING: CPU: 7 PID: 3053 at lib/refcount.c:28
Call Trace:
kobject_put+0xd6/0x1a0
kfd_procfs_del_queue+0x27/0x30 [amdgpu]
pqm_destroy_queue+0xeb/0x240 [amdgpu]
kfd_ioctl_destroy_queue+0x32/0x70 [amdgpu]
kfd_ioctl+0x27d/0x500 [amdgpu]
do_syscall_64+0x35/0x80
WARNING: CPU: 2 PID: 3053 at
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:400
Call Trace:
deallocate_doorbell.isra.0+0x39/0x40 [amdgpu]
destroy_queue_cpsch+0xb3/0x270 [amdgpu]
pqm_destroy_queue+0x108/0x240 [amdgpu]
kfd_ioctl_destroy_queue+0x32/0x70 [amdgpu]
kfd_ioctl+0x27d/0x500 [amdgpu]
general protection fault, probably for non-canonical address
0xdead0108:
Call Trace:
pqm_destroy_queue+0xf0/0x200 [amdgpu]
kfd_ioctl_destroy_queue+0x2f/0x60 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
Signed-off-by: Philip Yang
Reviewed-by: Graham Sider
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 28 +++
.../amd/amdkfd/kfd_process_queue_manager.c| 2 +-
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index e1797657b04c..e017b4240472 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1873,6 +1873,22 @@ static int destroy_queue_cpsch(struct
device_queue_manager *dqm,
}
+ if (q->properties.is_active) {
+ if (!dqm->dev->shared_resources.enable_mes) {
+ retval = execute_queues_cpsch(dqm,
+
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
+ if (retval == -ETIME)
+ qpd->reset_wavefronts = true;
+ } else {
+ retval = remove_queue_mes(dqm, q, qpd);
+ }
+
+ if (retval)
+ goto failed_unmap_queue;
+
+ decrement_queue_count(dqm, qpd, q);
+ }
+
mqd_mgr = dqm->mqd_mgrs[get_mqd_type_from_queue_type(
q->properties.type)];
@@ -1886,17 +1902,6 @@ static int destroy_queue_cpsch(struct
device_queue_manager *dqm,
list_del(&q->list);
qpd->queue_count--;
- if (q->properties.is_active) {
- if (!dqm->dev->shared_resources.enable_mes) {
- decrement_queue_count(dqm, qpd, q);
- retval = execute_queues_cpsch(dqm,
-
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
- if (retval == -ETIME)
- qpd->reset_wavefronts = true;
- } else {
- retval = remove_queue_mes(dqm, q, qpd);
- }
- }
/*
* Unconditionally decrement this counter, regardless of the queue's
@@ -1913,6 +1918,7 @@ static int destroy_queue_cpsch(struct
device_queue_manager *dqm,
return retval;
+failed_unmap_queue:
failed_try_destroy_debugged_queue:
dqm_unlock(dqm);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index dc00484ff484..99f2a6412201 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -419,7 +419,6 @@ int pqm_destroy_queue(struct process_queue_manager *pqm,
unsigned int qid)
}
if (pqn->q) {
- kfd_procfs_del_queue(pqn->q);
dqm = pqn->q->device->dqm;
retval = dqm->ops.destroy_queue(dqm, &pdd->qpd, pqn->q);
if (retval) {
@@ -439,6 +438,7 @@ int pqm_destroy_queue(struct process_queue_manager *pqm,
unsigned int qid)
if (dev->shared_resources.enable_mes)
amdgpu_amdkfd_free_gtt_mem(dev->adev,
pqn->q->gang_ctx_bo);
+ kfd_procfs_del_queue(pqn->q);
uninit_queue(pqn->q);
}
--
2.35.1
[PATCH AUTOSEL 5.19 045/105] amdgpu/pm: Fix possible array out-of-bounds if SCLK levels != 2
From: Darren Powell
[ Upstream commit ceb180361e3851007547c55035cd1de03f108f75 ]
[v2]
simplified fix after Lijo's feedback
removed clocks.num_levels from calculation of loop count
removed unsafe accesses to shim table freq_values
retained corner case output only min,now if
clocks.num_levels == 1 && now > min
[v1]
added a check to populate and use SCLK shim table freq_values only
if using dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL or
AMD_DPM_FORCED_LEVEL_PERF_DETERMINISM
removed clocks.num_levels from calculation of shim table size
removed unsafe accesses to shim table freq_values
output gfx_table values if using other dpm levels
added check for freq_match when using freq_values for when now == min_clk
== Test ==
LOGFILE=aldebaran-sclk.test.log
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
lspci -nn | grep "VGA\|Display" > $LOGFILE
FILES="pp_od_clk_voltage
pp_dpm_sclk"
for f in $FILES
do
echo === $f === >> $LOGFILE
cat $HWMON_DIR/device/$f >> $LOGFILE
done
cat $LOGFILE
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 34 +++
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index fb130409309c..f6ff7942e1b7 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -739,7 +739,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
struct smu_13_0_dpm_table *single_dpm_table;
struct smu_dpm_context *smu_dpm = &smu->smu_dpm;
struct smu_13_0_dpm_context *dpm_context = NULL;
- uint32_t display_levels;
+ int display_levels;
uint32_t freq_values[3] = {0};
uint32_t min_clk, max_clk;
@@ -771,7 +771,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
return ret;
}
- display_levels = clocks.num_levels;
+ display_levels = (clocks.num_levels == 1) ? 1 : 2;
min_clk = pstate_table->gfxclk_pstate.curr.min;
max_clk = pstate_table->gfxclk_pstate.curr.max;
@@ -781,30 +781,20 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
/* fine-grained dpm has only 2 levels */
if (now > min_clk && now < max_clk) {
- display_levels = clocks.num_levels + 1;
+ display_levels++;
freq_values[2] = max_clk;
freq_values[1] = now;
}
- /*
-* For DPM disabled case, there will be only one clock level.
-* And it's safe to assume that is always the current clock.
-*/
- if (display_levels == clocks.num_levels) {
- for (i = 0; i < clocks.num_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i],
- (clocks.num_levels == 1) ?
- "*" :
- (aldebaran_freqs_in_same_level(
-freq_values[i], now) ?
-"*" :
-""));
- } else {
- for (i = 0; i < display_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i], i == 1 ? "*" :
"");
- }
+ for (i = 0; i < display_levels; i++)
+ size += sysfs_emit_at(buf, size, "%d: %uMhz %s\n", i,
+ freq_values[i],
+ (display_levels == 1) ?
+ "*" :
+ (aldebaran_freqs_in_same_level(
+freq_values[i], now) ?
+"*" :
+""));
break;
--
2.35.1
[PATCH AUTOSEL 5.19 046/105] drm/ast: Fixed the casting issue reported by sparse
From: KuoHsiang Chou [ Upstream commit 232b95ba4e83ca0a77f19fc772ccc6581051e5cc ] V1: 1.Fixed sparse:cast truncates bits form constant value ()cast truncates bits from constant value (ff00 becomes 0) Reported-by: kernel test robot Signed-off-by: KuoHsiang Chou Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220623083116.35365-1-kuohsiang_c...@aspeedtech.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/ast/ast_dp.c | 10 +- drivers/gpu/drm/ast/ast_drv.h | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c index f573d582407e..56483860306b 100644 --- a/drivers/gpu/drm/ast/ast_dp.c +++ b/drivers/gpu/drm/ast/ast_dp.c @@ -34,7 +34,7 @@ int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata) * CRE4[7:0]: Read-Pointer for EDID (Unit: 4bytes); valid range: 0~64 */ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE4, - (u8) ~ASTDP_EDID_READ_POINTER_MASK, (u8) i); + ASTDP_AND_CLEAR_MASK, (u8)i); j = 0; /* @@ -274,8 +274,8 @@ void ast_dp_set_mode(struct drm_crtc *crtc, struct ast_vbios_mode_info *vbios_mo * CRE1[7:0]: MISC1 (default: 0x00) * CRE2[7:0]: video format index (0x00 ~ 0x20 or 0x40 ~ 0x50) */ - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE0, (u8) ~ASTDP_CLEAR_MASK, - ASTDP_MISC0_24bpp); - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE1, (u8) ~ASTDP_CLEAR_MASK, ASTDP_MISC1); - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE2, (u8) ~ASTDP_CLEAR_MASK, ModeIdx); + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE0, ASTDP_AND_CLEAR_MASK, + ASTDP_MISC0_24bpp); + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE1, ASTDP_AND_CLEAR_MASK, ASTDP_MISC1); + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE2, ASTDP_AND_CLEAR_MASK, ModeIdx); } diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h index a34db4380f68..2e44b971c3a6 100644 --- a/drivers/gpu/drm/ast/ast_drv.h +++ b/drivers/gpu/drm/ast/ast_drv.h @@ -433,7 +433,7 @@ int ast_mode_config_init(struct ast_private *ast); */ #define ASTDP_MISC0_24bpp BIT(5) #define ASTDP_MISC10 -#define ASTDP_CLEAR_MASK GENMASK(7, 0) +#define ASTDP_AND_CLEAR_MASK 0x00 /* * ASTDP resoultion table: -- 2.35.1
[PATCH AUTOSEL 5.19 052/105] drm/amdgpu/display/dc: Fix null pointer exception
From: Rahul Kumar [ Upstream commit 1c4dae3e4639540fb567e570cc56a3c292afb6fe ] We observed hard hang due to NULL derefrence This issue is seen after running system all the time after two or three days struct dc *dc = plane_state->ctx->dc; Randomly in long run we found plane_state or plane_state->ctx is found NULL which causes exception. BUG: kernel NULL pointer dereference, address: PF: supervisor read access in kernel mode PF: error_code(0x) - not-present page PGD 1dc7f2067 P4D 1dc7f2067 PUD 222c75067 PMD 0 Oops: [#1] SMP NOPTI CPU: 5 PID: 29855 Comm: kworker/u16:4 ... ... Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dcn10_update_pending_status+0x1f/0xee [amdgpu] Code: 41 5f c3 0f 1f 44 00 00 b0 01 c3 0f 1f 44 00 00 41 55 41 54 55 53 48 8b 1f 4c 8b af f8 00 00 00 48 8b 83 88 03 00 00 48 85 db <4c> 8b 20 0f 84 bf 00 00 00 48 89 fd 48 8b bf b8 00 00 00 48 8b 07 RSP: 0018:942941997ab8 EFLAGS: 00010286 RAX: RBX: 8d7fd98d2000 RCX: RDX: RSI: 8d7e3e87c708 RDI: 8d7f2d8c0690 RBP: 8d7f2d8c R08: 942941997a34 R09: R10: 5000 R11: 00f0 R12: 8d7f2d8c0690 R13: 8d8035a41680 R14: 000186a0 R15: 8d7f2d8c1dd8 FS: () GS:8d803734() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 00014803 CR4: 003406e0 Call Trace: dc_commit_state+0x6a2/0x7f0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x460/0x19bb [amdgpu] Tested-by: Rodrigo Siqueira Reviewed-by: Harry Wentland Signed-off-by: Rahul Kumar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index e3a62873c0e7..ffe496131635 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3242,7 +3242,7 @@ void dcn10_update_pending_status(struct pipe_ctx *pipe_ctx) struct dc_plane_state *plane_state = pipe_ctx->plane_state; struct timing_generator *tg = pipe_ctx->stream_res.tg; bool flip_pending; - struct dc *dc = plane_state->ctx->dc; + struct dc *dc = pipe_ctx->stream->ctx->dc; if (plane_state == NULL) return; -- 2.35.1
[PATCH AUTOSEL 5.19 057/105] drm/amdgpu: skip whole ras bad page framework on sriov
From: "Stanley.Yang" [ Upstream commit e0e146d5567317d6ba7d0169bed55d1d9ea05a61 ] It should not init whole ras bad page framework on sriov guest side due to it is handled on host side. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index dac202ae864d..465e7921bba1 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -2148,7 +2148,7 @@ int amdgpu_ras_recovery_init(struct amdgpu_device *adev) bool exc_err_limit = false; int ret; - if (!con) + if (!con || amdgpu_sriov_vf(adev)) return 0; /* Allow access to RAS EEPROM via debugfs, when the ASIC -- 2.35.1
[PATCH AUTOSEL 5.19 058/105] drm/amd/display: Guard against ddc_pin being NULL for AUX
From: Nicholas Kazlauskas
[ Upstream commit bc19909f19fdc8253d720d11c948935786fbfa08 ]
[Why]
In the case where we don't support DMUB aux but we have DPIA links
in the configuration we might try to message AUX using the legacy
path - where DDC pin is NULL. This causes a NULL pointer dereference.
[How]
Guard against NULL DDC pin, return a failure for aux engine acquire.
Reviewed-by: Michael Strauss
Acked-by: Rodrigo Siqueira
Signed-off-by: Nicholas Kazlauskas
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 9e39cd7b203e..49d3145ae8fb 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -572,6 +572,11 @@ int dce_aux_transfer_raw(struct ddc_service *ddc,
memset(&aux_req, 0, sizeof(aux_req));
+ if (ddc_pin == NULL) {
+ *operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
+ return -1;
+ }
+
aux_engine = ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en];
if (!acquire(aux_engine, ddc_pin)) {
*operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
--
2.35.1
[PATCH AUTOSEL 5.19 059/105] drm/amd/display: Fix dmub soft hang for PSR 1
From: Fangzhi Zuo [ Upstream commit 22676bc500c27d987a0b42cbe162aebf783f1c38 ] [Why] Unexpected change of aux hw mapping causes dmub soft hang when initiate aux transation at wrong aux channel. ddc_channel stands for hw dp aux index which is from vbios, but link_index is pure software concept for link count depending on which link is probed first. They are not interchangeable. dmub aux transaction could pass if happens eDP link_index gets the same value as vbios ddc_channel, e.g., ddc_channel = 1, link_index = 1 if they gets different, e.g., ddc_channel = 2, link_index = 0, overwrite ddc_channel with link_index will have wrong ddc channel being used for aux transaction in dmub PSR, cause aux transaction soft hang. [How] ddc_channel mapping to each link is determined by vbios and further parsed in dc. Such info. should not be touched in any kind, otherwise the mapping is screwed up leading to aux transaction timeout. Reviewed-by: Aurabindo Jayamohanan Pillai Acked-by: Rodrigo Siqueira Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3087dd1a1856..a6efd5c1fa2a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8538,7 +8538,7 @@ static int amdgpu_dm_i2c_xfer(struct i2c_adapter *i2c_adap, if (dc_submit_i2c( ddc_service->ctx->dc, - ddc_service->ddc_pin->hw_info.ddc_channel, + ddc_service->link->link_index, &cmd)) result = num; @@ -8574,8 +8574,6 @@ create_i2c(struct ddc_service *ddc_service, snprintf(i2c->base.name, sizeof(i2c->base.name), "AMDGPU DM i2c hw bus %d", link_index); i2c_set_adapdata(&i2c->base, i2c); i2c->ddc_service = ddc_service; - if (i2c->ddc_service->ddc_pin) - i2c->ddc_service->ddc_pin->hw_info.ddc_channel = link_index; return i2c; } -- 2.35.1
[PATCH AUTOSEL 5.19 060/105] drm/amd/display: disable otg toggle w/a on boot
From: Dmytro Laktyushkin
[ Upstream commit 8a077d9caa3a274de36ee2fe7b608041f5690343 ]
This w/a has a bad interaction with seamless boot toggling an
active stream. Most panels recover, however some fail leading
to display corruption.
Reviewed-by: Charlene Liu
Acked-by: Rodrigo Siqueira
Signed-off-by: Dmytro Laktyushkin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
index f4381725b210..36b0cd47c1c7 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
@@ -173,11 +173,14 @@ static void dcn315_update_clocks(struct clk_mgr
*clk_mgr_base,
}
if (should_set_clock(safe_to_lower, new_clocks->dispclk_khz,
clk_mgr_base->clks.dispclk_khz)) {
- dcn315_disable_otg_wa(clk_mgr_base, true);
+ /* No need to apply the w/a if we haven't taken over from bios
yet */
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, true);
clk_mgr_base->clks.dispclk_khz = new_clocks->dispclk_khz;
dcn315_smu_set_dispclk(clk_mgr, clk_mgr_base->clks.dispclk_khz);
- dcn315_disable_otg_wa(clk_mgr_base, false);
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, false);
update_dispclk = true;
}
--
2.35.1
[PATCH AUTOSEL 5.19 062/105] drm/msm/gem: Drop obj lock in msm_gem_free_object()
From: Rob Clark
[ Upstream commit a414fe3a2129b490e1e9b8ad66f0364f4f961887 ]
The only reason we grabbed the lock was to satisfy a bunch of places
that WARN_ON() if called without the lock held. But this angers lockdep
which doesn't realize no one else can be holding the lock by the time we
end up destroying the object (and sees what would otherwise be a locking
inversion between reservation_ww_class_mutex and fs_reclaim).
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/14
Signed-off-by: Rob Clark
Patchwork: https://patchwork.freedesktop.org/patch/489364/
Link: https://lore.kernel.org/r/20220613205032.2652374-1-robdcl...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 8
drivers/gpu/drm/msm/msm_gem.h | 14 +-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 7f92231785a0..e171af15fb11 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1020,8 +1020,6 @@ void msm_gem_free_object(struct drm_gem_object *obj)
list_del(&msm_obj->mm_list);
mutex_unlock(&priv->mm_lock);
- msm_gem_lock(obj);
-
/* object should not be on active list: */
GEM_WARN_ON(is_active(msm_obj));
@@ -1037,17 +1035,11 @@ void msm_gem_free_object(struct drm_gem_object *obj)
put_iova_vmas(obj);
- /* dma_buf_detach() grabs resv lock, so we need to unlock
-* prior to drm_prime_gem_destroy
-*/
- msm_gem_unlock(obj);
-
drm_prime_gem_destroy(obj, msm_obj->sgt);
} else {
msm_gem_vunmap(obj);
put_pages(obj);
put_iova_vmas(obj);
- msm_gem_unlock(obj);
}
drm_gem_object_release(obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 6b7d5bb3b575..4b387c7a0779 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -230,7 +230,19 @@ msm_gem_unlock(struct drm_gem_object *obj)
static inline bool
msm_gem_is_locked(struct drm_gem_object *obj)
{
- return dma_resv_is_locked(obj->resv);
+ /*
+* Destroying the object is a special case.. msm_gem_free_object()
+* calls many things that WARN_ON if the obj lock is not held. But
+* acquiring the obj lock in msm_gem_free_object() can cause a
+* locking order inversion between reservation_ww_class_mutex and
+* fs_reclaim.
+*
+* This deadlock is not actually possible, because no one should
+* be already holding the lock when msm_gem_free_object() is called.
+* Unfortunately lockdep is not aware of this detail. So when the
+* refcount drops to zero, we pretend it is already locked.
+*/
+ return dma_resv_is_locked(obj->resv) || (kref_read(&obj->refcount) ==
0);
}
static inline bool is_active(struct msm_gem_object *msm_obj)
--
2.35.1
[PATCH AUTOSEL 5.19 064/105] drm/amdgpu: Fix one list corruption when create queue fails
From: xinhui pan
[ Upstream commit cc3cb791f19ad0c4f951f38c98aa513b042ab329 ]
Queue would be freed when create_queue_cpsch fails
So lets do queue cleanup otherwise various list and memory issues
happen.
Signed-off-by: xinhui pan
Reviewed-by: Philip Yang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index e017b4240472..06417c7abca4 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -1666,14 +1666,13 @@ static int create_queue_cpsch(struct
device_queue_manager *dqm, struct queue *q,
if (q->properties.is_active) {
increment_queue_count(dqm, qpd, q);
- if (!dqm->dev->shared_resources.enable_mes) {
+ if (!dqm->dev->shared_resources.enable_mes)
retval = execute_queues_cpsch(dqm,
-
KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES, 0);
- } else {
+ KFD_UNMAP_QUEUES_FILTER_DYNAMIC_QUEUES,
0);
+ else
retval = add_queue_mes(dqm, q, qpd);
- if (retval)
- goto cleanup_queue;
- }
+ if (retval)
+ goto cleanup_queue;
}
/*
--
2.35.1
[PATCH AUTOSEL 5.19 069/105] drm/nouveau/nvkm: use list_add_tail() when building object tree
From: Ben Skeggs
[ Upstream commit 61c1f340bc809a1ca1e3c8794207a91cde1a7c78 ]
Fixes resume from hibernate failing on (at least) TU102, where cursor
channel init failed due to being performed before the core channel.
Not solid idea why suspend-to-ram worked, but, presumably HW being in
an entirely clean state has something to do with it.
Signed-off-by: Ben Skeggs
Reviewed-by: Dave Airlie
Signed-off-by: Dave Airlie
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/core/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
index 735cb6816f10..06b2f675f5da 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
@@ -128,7 +128,7 @@ nvkm_ioctl_new(struct nvkm_client *client,
if (ret == 0) {
ret = nvkm_object_init(object);
if (ret == 0) {
- list_add(&object->head, &parent->tree);
+ list_add_tail(&object->head, &parent->tree);
if (nvkm_object_insert(object)) {
client->data = object;
return 0;
--
2.35.1
[PATCH AUTOSEL 5.19 070/105] drm/amdgpu: fix file permissions on some files
From: Alex Deucher [ Upstream commit 0a94608f0f7de9b1135ffea3546afe68eafef57f ] Drop execute. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2085 Reviewed-by: Guchun Chen Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h| 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h | 0 6 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h old mode 100755 new mode 100644 -- 2.35.1
[PATCH AUTOSEL 5.19 075/105] drm/amdgpu: Call trace info was found in dmesg when loading amdgpu
From: lin cao
[ Upstream commit 748262eb400e809aa13e3485f4983c3db3d0ebb3 ]
In the case of SRIOV, the register smnMp1_PMI_3_FIFO will get an invalid
value which will cause the "shift out of bound". In Ubuntu22.04, this
issue will be checked an related call trace will be reported in dmesg.
Signed-off-by: lin cao
Reviewed-by: Jingwen Chen
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 78f3d9e722bb..4db7e32efd08 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -886,6 +886,7 @@ static void sienna_cichlid_stb_init(struct smu_context
*smu);
static int sienna_cichlid_init_smc_tables(struct smu_context *smu)
{
+ struct amdgpu_device *adev = smu->adev;
int ret = 0;
ret = sienna_cichlid_tables_init(smu);
@@ -896,7 +897,8 @@ static int sienna_cichlid_init_smc_tables(struct
smu_context *smu)
if (ret)
return ret;
- sienna_cichlid_stb_init(smu);
+ if (!amdgpu_sriov_vf(adev))
+ sienna_cichlid_stb_init(smu);
return smu_v11_0_init_smc_tables(smu);
}
--
2.35.1
[PATCH AUTOSEL 5.19 091/105] drm/amdkfd: Correct mmu_notifier_get failure handling
From: Philip Yang [ Upstream commit 0593ad215359d51514c1e6c81ce28ea598efed6b ] If process has signal pending, mmu_notifier_get_locked fails and calls ops->free_notifier, kfd_process_free_notifier will schedule kfd_process_wq_release as process refcount is 1, but process structure is already freed. This use after free bug causes system crash with different backtrace. The fix is to increase process refcount and then decrease the refcount after mmu_notifier_get success. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index e3d64ec8c353..b8b185e242d3 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -1404,6 +1404,11 @@ static struct kfd_process *create_process(const struct task_struct *thread) hash_add_rcu(kfd_processes_table, &process->kfd_processes, (uintptr_t)process->mm); + /* Avoid free_notifier to start kfd_process_wq_release if +* mmu_notifier_get failed because of pending signal. +*/ + kref_get(&process->ref); + /* MMU notifier registration must be the last call that can fail * because after this point we cannot unwind the process creation. * After this point, mmu_notifier_put will trigger the cleanup by @@ -1416,6 +1421,7 @@ static struct kfd_process *create_process(const struct task_struct *thread) } BUG_ON(mn != &process->mmu_notifier); + kfd_unref_process(process); get_task_struct(process->lead_thread); return process; -- 2.35.1
[PATCH AUTOSEL 5.19 092/105] drm/amdkfd: Process notifier release callback don't take mutex
From: Philip Yang
[ Upstream commit 74097f9fd2f5ebdae04fcba59da345386415cbf3 ]
Move process queues cleanup to deferred work kfd_process_wq_release, to
avoid potential deadlock circular locking warning:
WARNING: possible circular locking dependency detected
the existing dependency chain (in reverse order) is:
-> #2
((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}:
__flush_work+0x343/0x4a0
svm_range_list_lock_and_flush_work+0x39/0xc0
svm_range_set_attr+0xe8/0x1080 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #1 (&info->lock#2){+.+.}-{3:3}:
__mutex_lock+0xa4/0x940
amdgpu_amdkfd_gpuvm_acquire_process_vm+0x2e3/0x590
kfd_process_device_init_vm+0x61/0x200 [amdgpu]
kfd_ioctl_acquire_vm+0x83/0xb0 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #0 (&process->mutex){+.+.}-{3:3}:
__lock_acquire+0x1365/0x23d0
lock_acquire+0xc9/0x2e0
__mutex_lock+0xa4/0x940
kfd_process_notifier_release+0x96/0xe0 [amdgpu]
__mmu_notifier_release+0x94/0x210
exit_mmap+0x35/0x1f0
mmput+0x63/0x120
svm_range_deferred_list_work+0x177/0x2c0 [amdgpu]
process_one_work+0x2a4/0x600
worker_thread+0x39/0x3e0
kthread+0x16d/0x1a0
Possible unsafe locking scenario:
CPU0CPU1
lock((work_completion)(&svms->deferred_list_work));
lock(&info->lock#2);
lock((work_completion)(&svms->deferred_list_work));
lock(&process->mutex);
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index b8b185e242d3..9ad293fb95af 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -1114,6 +1114,15 @@ static void kfd_process_wq_release(struct work_struct
*work)
struct kfd_process *p = container_of(work, struct kfd_process,
release_work);
+ kfd_process_dequeue_from_all_devices(p);
+ pqm_uninit(&p->pqm);
+
+ /* Signal the eviction fence after user mode queues are
+* destroyed. This allows any BOs to be freed without
+* triggering pointless evictions or waiting for fences.
+*/
+ dma_fence_signal(p->ef);
+
kfd_process_remove_sysfs(p);
kfd_iommu_unbind_process(p);
@@ -1178,20 +1187,8 @@ static void kfd_process_notifier_release(struct
mmu_notifier *mn,
cancel_delayed_work_sync(&p->eviction_work);
cancel_delayed_work_sync(&p->restore_work);
- mutex_lock(&p->mutex);
-
- kfd_process_dequeue_from_all_devices(p);
- pqm_uninit(&p->pqm);
-
/* Indicate to other users that MM is no longer valid */
p->mm = NULL;
- /* Signal the eviction fence after user mode queues are
-* destroyed. This allows any BOs to be freed without
-* triggering pointless evictions or waiting for fences.
-*/
- dma_fence_signal(p->ef);
-
- mutex_unlock(&p->mutex);
mmu_notifier_put(&p->mmu_notifier);
}
--
2.35.1
[PATCH AUTOSEL 5.18 01/93] fbdev: Restart conflicting fb removal loop when unregistering devices
From: Javier Martinez Canillas
[ Upstream commit 3367aa7d74d240261de2543ddb35531ccad9d884 ]
Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, call to remove_conflicting_framebuffers().
This function takes the registration_lock mutex, to prevent a race when
drivers register framebuffer devices. But if a conflicting framebuffer
device is found, the underlaying platform device is unregistered and this
will lead to the platform driver .remove callback to be called. Which in
turn will call to unregister_framebuffer() that takes the same lock.
To prevent this, a struct fb_info.forced_out field was used as indication
to unregister_framebuffer() whether the mutex has to be grabbed or not.
But this could be unsafe, since the fbdev core is making assumptions about
what drivers may or may not do in their .remove callbacks. Allowing to run
these callbacks with the registration_lock held can cause deadlocks, since
the fbdev core has no control over what drivers do in their removal path.
A better solution is to drop the lock before platform_device_unregister(),
so unregister_framebuffer() can take it when called from the fbdev driver.
The lock is acquired again after the device has been unregistered and at
this point the removal loop can be restarted.
Since the conflicting framebuffer device has already been removed, the
loop would just finish when no more conflicting framebuffers are found.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/2022053039.1252432-1-javi...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbmem.c | 22 +++---
include/linux/fb.h | 1 -
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 643383d74edc..82880f59ba67 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1566,6 +1566,7 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
{
int i;
+restart_removal:
/* check all firmware fbs and kick off if the base addr overlaps */
for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
@@ -1600,12 +1601,23 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
*/
do_unregister_framebuffer(registered_fb[i]);
} else if (dev_is_platform(device)) {
- registered_fb[i]->forced_out = true;
+ /*
+* Drop the lock because if the device is
unregistered, its
+* driver will call to
unregister_framebuffer(), that takes
+* this lock.
+*/
+ mutex_unlock(®istration_lock);
platform_device_unregister(to_platform_device(device));
+ mutex_lock(®istration_lock);
} else {
pr_warn("fb%d: cannot remove device\n", i);
do_unregister_framebuffer(registered_fb[i]);
}
+ /*
+* Restart the removal loop now that the device has been
+* unregistered and its associated framebuffer gone.
+*/
+ goto restart_removal;
}
}
}
@@ -1946,13 +1958,9 @@ EXPORT_SYMBOL(register_framebuffer);
void
unregister_framebuffer(struct fb_info *fb_info)
{
- bool forced_out = fb_info->forced_out;
-
- if (!forced_out)
- mutex_lock(®istration_lock);
+ mutex_lock(®istration_lock);
do_unregister_framebuffer(fb_info);
- if (!forced_out)
- mutex_unlock(®istration_lock);
+ mutex_unlock(®istration_lock);
}
EXPORT_SYMBOL(unregister_framebuffer);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 9a77ab615c36..ae399d3ea4f9 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -503,7 +503,6 @@ struct fb_info {
} *apertures;
bool skip_vt_switch; /* no VT switch on suspend/resume required */
- bool forced_out; /* set when being removed by another driver */
};
static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
--
2.35.1
[PATCH AUTOSEL 5.18 02/93] drm/r128: Fix undefined behavior due to shift overflowing the constant
From: Borislav Petkov [ Upstream commit 6556551f8848f98eff356c8aacae42c8dd65b2df ] Fix: drivers/gpu/drm/r128/r128_cce.c: In function ‘r128_do_init_cce’: drivers/gpu/drm/r128/r128_cce.c:417:2: error: case label does not reduce to an integer constant case R128_PM4_64BM_64VCBM_64INDBM: ^~~~ drivers/gpu/drm/r128/r128_cce.c:418:2: error: case label does not reduce to an integer constant case R128_PM4_64PIO_64VCPIO_64INDPIO: ^~~~ See https://lore.kernel.org/r/ykwq6%2btih8gqp...@zn.tnic for the gory details as to why it triggers with older gccs only. Reviewed-by: Randy Dunlap Signed-off-by: Borislav Petkov Cc: David Airlie Cc: Daniel Vetter Cc: Alex Deucher Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220405151517.29753-5...@alien8.de Signed-off-by: Sasha Levin --- drivers/gpu/drm/r128/r128_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h index 2e1bc01aa5c9..970e192b0d51 100644 --- a/drivers/gpu/drm/r128/r128_drv.h +++ b/drivers/gpu/drm/r128/r128_drv.h @@ -300,8 +300,8 @@ extern long r128_compat_ioctl(struct file *filp, unsigned int cmd, # define R128_PM4_64PIO_128INDBM (5 << 28) # define R128_PM4_64BM_128INDBM (6 << 28) # define R128_PM4_64PIO_64VCBM_64INDBM(7 << 28) -# define R128_PM4_64BM_64VCBM_64INDBM (8 << 28) -# define R128_PM4_64PIO_64VCPIO_64INDPIO (15 << 28) +# define R128_PM4_64BM_64VCBM_64INDBM (8U << 28) +# define R128_PM4_64PIO_64VCPIO_64INDPIO (15U << 28) # define R128_PM4_BUFFER_CNTL_NOUPDATE(1 << 27) #define R128_PM4_BUFFER_WM_CNTL0x0708 -- 2.35.1
[PATCH AUTOSEL 5.18 05/93] drm/nouveau: clear output poll workers before nouveau_fbcon_destroy()
From: Mark Menzynski [ Upstream commit 6b03816f869529393b37d03e5d75b68f7365a7a4 ] Resources needed for output poll workers are destroyed in nouveau_fbcon_fini() before output poll workers are cleared in nouveau_display_fini(). This means there is a time between fbcon_fini() and display_fini(), where if output poll happens, it crashes. This patch introduces another output poll clearing before fbcon resources are destroyed. BUG: KASAN: use-after-free in __drm_fb_helper_initial_config_and_unlock.cold+0x1f3/0x291 [drm_kms_helper] Cc: Ben Skeggs Cc: Karol Herbst Cc: Lyude Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Mark Menzynski Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220523113541.10562-1-mmenz...@redhat.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 4f9b3aa5deda..5226323e55d3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -39,6 +39,7 @@ #include #include +#include #include #include #include @@ -605,6 +606,7 @@ nouveau_fbcon_fini(struct drm_device *dev) if (!drm->fbcon) return; + drm_kms_helper_poll_fini(dev); nouveau_fbcon_accel_fini(dev); nouveau_fbcon_destroy(dev, drm->fbcon); kfree(drm->fbcon); -- 2.35.1
[PATCH AUTOSEL 5.18 08/93] drm/panfrost: Add arm, mali-valhall-jm compatible
From: Alyssa Rosenzweig
[ Upstream commit 952cd974509251d6b5074bc3677b8297826a6ef1 ]
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
v2: Use arm,mali-valhall-jm compatible.
Reviewed-by: Steven Price
Signed-off-by: Alyssa Rosenzweig
Link:
https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-10-alyssa.rosenzw...@collabora.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 601e124842e1..c1260532f003 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -664,6 +664,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t860", .data = &default_data, },
{ .compatible = "arm,mali-t880", .data = &default_data, },
{ .compatible = "arm,mali-bifrost", .data = &default_data, },
+ { .compatible = "arm,mali-valhall-jm", .data = &default_data, },
{ .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
{}
};
--
2.35.1
[PATCH AUTOSEL 5.18 07/93] drm/panfrost: Don't set L2_MMU_CONFIG quirks
From: Alyssa Rosenzweig [ Upstream commit d8e53d8a4e0ae842ef5e83e0dfb0796980f710cf ] L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs define slightly different MAX_READS and MAX_WRITES fields, which throttle outstanding reads and writes when set to non-zero values. When left as zero, reads and writes are not throttled. Both kbase and panfrost always zero these registers. Per discussion with Steven Price, there are two reasons these quirks may be used: 1. Simulating slower memory subsystems. This use case is only of interest to system-on-chip designers; it is not relevant to mainline. 2. Working around broken memory subsystems. Hopefully we never see this case in mainline. If we do, we'll need to set this register based on an SoC-compatible, rather than generally matching on the GPU model. To the best of our knowledge, these fields are zero at reset, so the write is not necessary. Let's remove the write to aid porting to new Mali GPUs, which have different layouts for the L2_MMU_CONFIG register. Suggested-by: Steven Price Reviewed-by: Steven Price Signed-off-by: Alyssa Rosenzweig Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-8-alyssa.rosenzw...@collabora.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/panfrost/panfrost_gpu.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c b/drivers/gpu/drm/panfrost/panfrost_gpu.c index 295bef27fb55..e1a6e763d0dc 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c @@ -127,18 +127,6 @@ static void panfrost_gpu_init_quirks(struct panfrost_device *pfdev) gpu_write(pfdev, GPU_TILER_CONFIG, quirks); - quirks = gpu_read(pfdev, GPU_L2_MMU_CONFIG); - - /* Limit read & write ID width for AXI */ - if (panfrost_has_hw_feature(pfdev, HW_FEATURE_3BIT_EXT_RW_L2_MMU_CONFIG)) - quirks &= ~(L2_MMU_CONFIG_3BIT_LIMIT_EXTERNAL_READS | - L2_MMU_CONFIG_3BIT_LIMIT_EXTERNAL_WRITES); - else - quirks &= ~(L2_MMU_CONFIG_LIMIT_EXTERNAL_READS | - L2_MMU_CONFIG_LIMIT_EXTERNAL_WRITES); - - gpu_write(pfdev, GPU_L2_MMU_CONFIG, quirks); - quirks = 0; if ((panfrost_model_eq(pfdev, 0x860) || panfrost_model_eq(pfdev, 0x880)) && pfdev->features.revision >= 0x2000) -- 2.35.1
[PATCH AUTOSEL 5.18 06/93] drm/panfrost: Handle HW_ISSUE_TTRX_2968_TTRX_3162
From: Alyssa Rosenzweig
[ Upstream commit 382435709516c1a7dc3843872792abf95e786c83 ]
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Reviewed-by: Steven Price
Signed-off-by: Alyssa Rosenzweig
Link:
https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-3-alyssa.rosenzw...@collabora.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_regs.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index aa89926742fd..295bef27fb55 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -108,6 +108,9 @@ static void panfrost_gpu_init_quirks(struct panfrost_device
*pfdev)
quirks |= SC_LS_ALLOW_ATTR_TYPES;
}
+ if (panfrost_has_hw_issue(pfdev, HW_ISSUE_TTRX_2968_TTRX_3162))
+ quirks |= SC_VAR_ALGORITHM;
+
if (panfrost_has_hw_feature(pfdev, HW_FEATURE_TLS_HASHING))
quirks |= SC_TLS_HASH_ENABLE;
diff --git a/drivers/gpu/drm/panfrost/panfrost_issues.h
b/drivers/gpu/drm/panfrost/panfrost_issues.h
index 501a76c5e95f..41a714ce6fce 100644
--- a/drivers/gpu/drm/panfrost/panfrost_issues.h
+++ b/drivers/gpu/drm/panfrost/panfrost_issues.h
@@ -125,6 +125,9 @@ enum panfrost_hw_issue {
* kernel must fiddle with L2 caches to prevent data leakage */
HW_ISSUE_TGOX_R1_1234,
+ /* Must set SC_VAR_ALGORITHM */
+ HW_ISSUE_TTRX_2968_TTRX_3162,
+
HW_ISSUE_END
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 0b6cd8fdcb47..accb4fa3adb8 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -195,6 +195,7 @@
#define SC_TLS_HASH_ENABLE BIT(17)
#define SC_LS_ATTR_CHECK_DISABLE BIT(18)
#define SC_ENABLE_TEXGRD_FLAGS BIT(25)
+#define SC_VAR_ALGORITHM BIT(29)
/* End SHADER_CONFIG register */
/* TILER_CONFIG register */
--
2.35.1
[PATCH AUTOSEL 5.18 11/93] drm/amd/display: fix system hang when PSR exits
From: David Zhang
[ Upstream commit 6cc5c77300afbb285c4f41e04f3435ae3c484c40 ]
[why]
When DC driver send PSR exit dmub command to DMUB FW, it might not
wait until PSR exit. Then it may hit the following deadlock situation.
1. DC driver send HW LOCK command to DMUB FW due to frame update
2. DMUB FW Set the HW lock
3. DMUB execute PSR exit sequence and stuck at polling DPG Pending
register due to the HW Lock is set
4. DC driver ask DMUB FW to unlock HW lock, but DMUB FW is polling
DPG pending register
[how]
The reason why DC driver doesn't wait until PSR exit is because some of
the PSR state machine state is not update the dc driver. So when DC
driver read back the PSR state, it take the state for PSR inactive.
Signed-off-by: David Zhang
Acked-by: Leo Li
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dc_types.h | 7 +++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 16
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index 2ba9f528c0fe..f1f11b3c205f 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -657,10 +657,17 @@ enum dc_psr_state {
PSR_STATE4b,
PSR_STATE4c,
PSR_STATE4d,
+ PSR_STATE4_FULL_FRAME,
+ PSR_STATE4a_FULL_FRAME,
+ PSR_STATE4b_FULL_FRAME,
+ PSR_STATE4c_FULL_FRAME,
+ PSR_STATE4_FULL_FRAME_POWERUP,
PSR_STATE5,
PSR_STATE5a,
PSR_STATE5b,
PSR_STATE5c,
+ PSR_STATE_HWLOCK_MGR,
+ PSR_STATE_POLLVUPDATE,
PSR_STATE_INVALID = 0xFF
};
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index 312c68172689..ce2f70134669 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -74,6 +74,22 @@ static enum dc_psr_state convert_psr_state(uint32_t
raw_state)
state = PSR_STATE5b;
else if (raw_state == 0x53)
state = PSR_STATE5c;
+ else if (raw_state == 0x4A)
+ state = PSR_STATE4_FULL_FRAME;
+ else if (raw_state == 0x4B)
+ state = PSR_STATE4a_FULL_FRAME;
+ else if (raw_state == 0x4C)
+ state = PSR_STATE4b_FULL_FRAME;
+ else if (raw_state == 0x4D)
+ state = PSR_STATE4c_FULL_FRAME;
+ else if (raw_state == 0x4E)
+ state = PSR_STATE4_FULL_FRAME_POWERUP;
+ else if (raw_state == 0x60)
+ state = PSR_STATE_HWLOCK_MGR;
+ else if (raw_state == 0x61)
+ state = PSR_STATE_POLLVUPDATE;
+ else
+ state = PSR_STATE_INVALID;
return state;
}
--
2.35.1
[PATCH AUTOSEL 5.18 13/93] drm/probe-helper: Default to 640x480 if no EDID on DP
From: Douglas Anderson
[ Upstream commit fae7d186403ee5a9375ec75938e0de99718e066a ]
If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. Since we have no true information about the connected
display, these modes are essentially guesses but better than nothing.
At the moment, none of the modes returned is marked as preferred, but
the modes are sorted such that the higher resolution modes are listed
first.
When userspace sees these modes presented by the kernel it needs to
figure out which one to pick. At least one userspace, ChromeOS [1]
seems to use the rules (which seem pretty reasonable):
1. Try to pick the first mode marked as preferred.
2. Try to pick the mode which matches the first detailed timing
descriptor in the EDID.
3. If no modes were marked as preferred then pick the first mode.
Unfortunately, userspace's rules combined with what the kernel is
doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of
the DP 1.4a Link CTS. That test case says that, while it's OK to allow
some implementation-specific fall-back modes if the EDID is bad that
userspace should _default_ to 640x480.
Let's fix this by marking 640x480 as default for DP in the no-EDID
case.
NOTES:
- In the discussion around v3 of this patch [2] there was talk about
solving this in userspace and I even implemented a patch that would
have solved this for ChromeOS, but then the discussion turned back
to solving this in the kernel.
- Also in the discussion of v3 [2] it was requested to limit this
change to just DP since folks were worried that it would break some
subtle corner case on VGA or HDMI.
[1]
https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488
[2]
https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
Signed-off-by: Douglas Anderson
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Acked-by: Jani Nikula
Reviewed-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_probe_helper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 682359512996..2c7902b16321 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -516,8 +516,17 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
count = drm_add_override_edid_modes(connector);
if (count == 0 && (connector->status == connector_status_connected ||
- connector->status == connector_status_unknown))
+ connector->status == connector_status_unknown)) {
count = drm_add_modes_noedid(connector, 1024, 768);
+
+ /*
+* Section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a
+* Link CTS specifies that 640x480 (the official "failsafe"
+* mode) needs to be the default if there's no EDID.
+*/
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ drm_set_preferred_mode(connector, 640, 480);
+ }
count += drm_helper_probe_add_cmdline_mode(connector);
if (count == 0)
goto prune;
--
2.35.1
[PATCH AUTOSEL 5.18 12/93] drm/amd/display: Detect dpcd_rev when hotplug mst monitor
From: Wayne Lin
[ Upstream commit 453b0016a054df0f442fda8a145b97a33816cab9 ]
[Why]
Once mst topology is constructed, later on new connected monitors
are reported to source by CSN message. Within CSN, there is no
carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the
result, we might leave some ports connected to DP but without DPCD
revision number which will affect us determining the capability of
the DP Rx.
[How]
Send out remote DPCD read when the port's dpcd_rev is 0x0 in
detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the
return value is 0x0, it's likely the DP1.2 DP Rx then we reques
revision from DPCD 0x0 again.
Reviewed-by: Hersen Wu
Acked-by: Hamza Mahfooz
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index d864cae1af67..bcbb6f6f8c82 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -363,12 +363,48 @@ dm_dp_mst_detect(struct drm_connector *connector,
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct amdgpu_dm_connector *master = aconnector->mst_port;
+ struct drm_dp_mst_port *port = aconnector->port;
+ int connection_status;
if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, ctx, &master->mst_mgr,
+ connection_status = drm_dp_mst_detect_port(connector, ctx,
&master->mst_mgr,
aconnector->port);
+
+ if (port->pdt != DP_PEER_DEVICE_NONE && !port->dpcd_rev) {
+ uint8_t dpcd_rev;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&port->aux, DP_DP13_DPCD_REV,
&dpcd_rev);
+
+ if (ret == 1) {
+ port->dpcd_rev = dpcd_rev;
+
+ /* Could be DP1.2 DP Rx case*/
+ if (!dpcd_rev) {
+ ret = drm_dp_dpcd_readb(&port->aux,
DP_DPCD_REV, &dpcd_rev);
+
+ if (ret == 1)
+ port->dpcd_rev = dpcd_rev;
+ }
+
+ if (!dpcd_rev)
+ DRM_DEBUG_KMS("Can't decide DPCD revision
number!");
+ }
+
+ /*
+* Could be legacy sink, logical port etc on DP1.2.
+* Will get Nack under these cases when issue remote
+* DPCD read.
+*/
+ if (ret != 1)
+ DRM_DEBUG_KMS("Can't access DPCD");
+ } else if (port->pdt == DP_PEER_DEVICE_NONE) {
+ port->dpcd_rev = 0;
+ }
+
+ return connection_status;
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
--
2.35.1
[PATCH AUTOSEL 5.18 16/93] drm/amd/display: Fix dpp dto for disabled pipes
From: Duncan Ma [ Upstream commit d4965c53b95d7533dfc2309d2fc25838bd33220e ] [Why] When switching from 1 pipe to 4to1 mpc combine, DppDtoClk aren't enabled for the disabled pipes pior to programming the pipes. Upon optimizing bandwidth, DppDto are enabled causing intermittent underflow. [How] Update dppclk dto whenever pipe are flagged to enable. Reviewed-by: Dmytro Laktyushkin Reviewed-by: Nicholas Kazlauskas Reviewed-by: Hansen Dsouza Acked-by: Hamza Mahfooz Signed-off-by: Duncan Ma Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c index b627c41713cc..76decaed5acd 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c @@ -1412,11 +1412,15 @@ static void dcn20_update_dchubp_dpp( struct hubp *hubp = pipe_ctx->plane_res.hubp; struct dpp *dpp = pipe_ctx->plane_res.dpp; struct dc_plane_state *plane_state = pipe_ctx->plane_state; + struct dccg *dccg = dc->res_pool->dccg; bool viewport_changed = false; if (pipe_ctx->update_flags.bits.dppclk) dpp->funcs->dpp_dppclk_control(dpp, false, true); + if (pipe_ctx->update_flags.bits.enable) + dccg->funcs->update_dpp_dto(dccg, dpp->inst, pipe_ctx->plane_res.bw.dppclk_khz); + /* TODO: Need input parameter to tell current DCHUB pipe tie to which OTG * VTG is within DCHUBBUB which is commond block share by each pipe HUBP. * VTG is 1:1 mapping with OTG. Each pipe HUBP will select which VTG -- 2.35.1
[PATCH AUTOSEL 5.18 17/93] drm/amd/display: Reduce frame size in the bouding box for DCN20
From: Rodrigo Siqueira
[ Upstream commit c55300ad4a1814bac9191a4d2c7b0d74273aec7c ]
GCC throw warnings for the function dcn20_update_bounding_box due to its
frame size that looks like this:
error: the frame size of 1936 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
This commit fixes this issue by eliminating an intermediary variable
that creates a large array.
Cc: Stephen Rothwell
Cc: Hamza Mahfooz
Cc: Aurabindo Pillai
Reviewed-by: Harry Wentland
Reviewed-by: Alex Deucher
Signed-off-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 38 +--
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index f93af45aeab4..c758f84baaf5 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -1430,21 +1430,20 @@ void dcn20_calculate_wm(
void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_st *bb,
struct pp_smu_nv_clock_table *max_clocks, unsigned int
*uclk_states, unsigned int num_states)
{
- struct _vcs_dpi_voltage_scaling_st
calculated_states[DC__VOLTAGE_STATES];
- int i;
int num_calculated_states = 0;
int min_dcfclk = 0;
+ int i;
dc_assert_fp_enabled();
if (num_states == 0)
return;
- memset(calculated_states, 0, sizeof(calculated_states));
+ memset(bb->clock_limits, 0, sizeof(bb->clock_limits));
- if (dc->bb_overrides.min_dcfclk_mhz > 0)
+ if (dc->bb_overrides.min_dcfclk_mhz > 0) {
min_dcfclk = dc->bb_overrides.min_dcfclk_mhz;
- else {
+ } else {
if (ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev))
min_dcfclk = 310;
else
@@ -1455,36 +1454,35 @@ void dcn20_update_bounding_box(struct dc *dc, struct
_vcs_dpi_soc_bounding_box_s
for (i = 0; i < num_states; i++) {
int min_fclk_required_by_uclk;
- calculated_states[i].state = i;
- calculated_states[i].dram_speed_mts = uclk_states[i] * 16 /
1000;
+ bb->clock_limits[i].state = i;
+ bb->clock_limits[i].dram_speed_mts = uclk_states[i] * 16 / 1000;
// FCLK:UCLK ratio is 1.08
min_fclk_required_by_uclk = div_u64(((unsigned long
long)uclk_states[i]) * 1080,
100);
- calculated_states[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
+ bb->clock_limits[i].fabricclk_mhz = (min_fclk_required_by_uclk
< min_dcfclk) ?
min_dcfclk : min_fclk_required_by_uclk;
- calculated_states[i].socclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
- max_clocks->socClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].socclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->socClockInKhz / 1000) ?
+ max_clocks->socClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dcfclk_mhz =
(calculated_states[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
- max_clocks->dcfClockInKhz / 1000 :
calculated_states[i].fabricclk_mhz;
+ bb->clock_limits[i].dcfclk_mhz =
(bb->clock_limits[i].fabricclk_mhz > max_clocks->dcfClockInKhz / 1000) ?
+ max_clocks->dcfClockInKhz / 1000 :
bb->clock_limits[i].fabricclk_mhz;
- calculated_states[i].dispclk_mhz =
max_clocks->displayClockInKhz / 1000;
- calculated_states[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
- calculated_states[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
+ bb->clock_limits[i].dispclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dppclk_mhz = max_clocks->displayClockInKhz
/ 1000;
+ bb->clock_limits[i].dscclk_mhz = max_clocks->displayClockInKhz
/ (1000 * 3);
- calculated_states[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
+ bb->clock_limits[i].phyclk_mhz = max_clocks->phyClockInKhz /
1000;
num_calculated_states++;
}
- calculated_states[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].fabricclk_mhz =
max_clocks->socClockInKhz / 1000;
- calculated_states[num_calculated_states - 1].dcfclk_mhz =
max_clocks->dcfClockInKhz / 1000;
+ bb->clock_limits[num_calculated_states - 1].socclk_mhz =
max_clocks->socClockInKhz / 1000;
+ bb->clock
[PATCH AUTOSEL 5.18 18/93] drm/radeon: integer overflow in radeon_mode_dumb_create()
From: Xiaohui Zhang
[ Upstream commit feb54650bae25f2a2adfc493e3e254e7c27a3fba ]
Similar to the handling of amdgpu_mode_dumb_create in commit 54ef0b5461c0
("drm/amdgpu: integer overflow in amdgpu_mode_dumb_create()"),
we thought a patch might be needed here as well.
args->size is a u64. arg->pitch and args->height are u32. The
multiplication will overflow instead of using the high 32 bits as
intended.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index f563284a7fac..6c9cc0061a8d 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -830,7 +830,7 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
args->pitch = radeon_align_pitch(rdev, args->width,
DIV_ROUND_UP(args->bpp, 8), 0);
- args->size = args->pitch * args->height;
+ args->size = (u64)args->pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
r = radeon_gem_object_create(rdev, args->size, 0,
--
2.35.1
[PATCH AUTOSEL 5.18 19/93] drm/radeon: Initialize fences array entries in radeon_sa_bo_next_hole
From: Xiaohui Zhang
[ Upstream commit 0381ac3ca2e727d4dfb7264d9416a8ba6bb6c18b ]
Similar to the handling of amdgpu_sa_bo_next_hole in commit 6a15f3ff19a8
("drm/amdgpu: Initialize fences array entries in amdgpu_sa_bo_next_hole"),
we thought a patch might be needed here as well.
The entries were only initialized once in radeon_sa_bo_new. If a fence
wasn't signalled yet in the first radeon_sa_bo_next_hole call, but then
got signalled before a later radeon_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in radeon_sa_bo_new.
Signed-off-by: Xiaohui Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/radeon/radeon_sa.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 310c322c7112..0981948bd9ed 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -267,6 +267,8 @@ static bool radeon_sa_bo_next_hole(struct radeon_sa_manager
*sa_manager,
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
struct radeon_sa_bo *sa_bo;
+ fences[i] = NULL;
+
if (list_empty(&sa_manager->flist[i])) {
continue;
}
@@ -332,10 +334,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
spin_lock(&sa_manager->wq.lock);
do {
- for (i = 0; i < RADEON_NUM_RINGS; ++i) {
- fences[i] = NULL;
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
tries[i] = 0;
- }
do {
radeon_sa_bo_try_free(sa_manager);
--
2.35.1
[PATCH AUTOSEL 5.18 20/93] udmabuf: Set the DMA mask for the udmabuf device (v2)
From: Vivek Kasireddy
[ Upstream commit 9e9fa6a9198b767b00f48160800128e83a038f9f ]
If the DMA mask is not set explicitly, the following warning occurs
when the userspace tries to access the dma-buf via the CPU as
reported by syzbot here:
WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188
__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Modules linked in:
CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted
5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0
83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45
31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00
RSP: 0018:c90002a07d68 EFLAGS: 00010293
RAX: RBX: RCX:
RDX: 88807e25e2c0 RSI: 81649e91 RDI: 88801b848408
RBP: 88801b848000 R08: 0002 R09: 88801d86c74f
R10: 81649d72 R11: 0001 R12: 0002
R13: 88801d86c680 R14: 0001 R15:
FS: 56e30300() GS:8880b9d0()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 20cc CR3: 1d74a000 CR4: 003506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264
get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72
begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126
dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164
dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f62fcf530f9
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffe3edab9b8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: RCX: 7f62fcf530f9
RDX: 2200 RSI: 40086200 RDI: 0006
RBP: 7f62fcf170e0 R08: R09:
R10: R11: 0246 R12: 7f62fcf17170
R13: R14: R15:
v2: Dont't forget to deregister if DMA mask setup fails.
Reported-by: syzbot+10e27961f4da37c44...@syzkaller.appspotmail.com
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
Link:
http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasire...@intel.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/dma-buf/udmabuf.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 9631f2fd2faf..38e8767ec371 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -368,7 +368,23 @@ static struct miscdevice udmabuf_misc = {
static int __init udmabuf_dev_init(void)
{
- return misc_register(&udmabuf_misc);
+ int ret;
+
+ ret = misc_register(&udmabuf_misc);
+ if (ret < 0) {
+ pr_err("Could not initialize udmabuf device\n");
+ return ret;
+ }
+
+ ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device,
+ DMA_BIT_MASK(64));
+ if (ret < 0) {
+ pr_err("Could not setup DMA mask for udmabuf device\n");
+ misc_deregister(&udmabuf_misc);
+ return ret;
+ }
+
+ return 0;
}
static void __exit udmabuf_dev_exit(void)
--
2.35.1
[PATCH AUTOSEL 5.18 24/93] drm/amd/display: Fix monitor flash issue
From: Shah Dharati
[ Upstream commit b840b64bc8ed3fc46f6d6aa7f97c43862a33bea5 ]
[Why & How]
For a some specific monitors, when connected on boot or hot plug,
monitor flash for 1/2 seconds can happen during first HDCP query
operation. Ading some delay in the init sequence for these monitors
fixes the issue, so it is implemented as monitor specific patch.
Co-authored-by: Shah Dharati
Reviewed-by: Hansen Dsouza
Reviewed-by: Nicholas Kazlauskas
Acked-by: Hamza Mahfooz
Signed-off-by: Shah Dharati
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
index 1f4095b26409..c5f6c11de7e5 100644
--- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
+++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp2_transition.c
@@ -524,7 +524,7 @@ enum mod_hdcp_status mod_hdcp_hdcp2_dp_transition(struct
mod_hdcp *hdcp,
set_watchdog_in_ms(hdcp, 3000, output);
set_state_id(hdcp, output, D2_A6_WAIT_FOR_RX_ID_LIST);
} else {
- callback_in_ms(0, output);
+ callback_in_ms(1, output);
set_state_id(hdcp, output, D2_SEND_CONTENT_STREAM_TYPE);
}
break;
--
2.35.1
[PATCH AUTOSEL 5.18 35/93] drm/bridge/tc358775: Fix DSI clock division for vsync delay calculation
From: Jiri Vanek [ Upstream commit 993a87917c2af59efb0ee1ce43c878ca8790ba1c ] Use the same PCLK divide option (divide DSI clock to generate pixel clock) which is set to LVDS Configuration Register (LVCFG) also for a VSync delay calculation. Without this change an auxiliary variable could underflow during the calculation for some dual-link LVDS panels and then calculated VSync delay is wrong. This leads to a shifted picture on a panel. Tested-by: Jiri Vanek Signed-off-by: Jiri Vanek Reviewed-by: Vinay Simha BN Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/2022061521.1501-3-jirivan...@gmail.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/bridge/tc358775.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358775.c b/drivers/gpu/drm/bridge/tc358775.c index 695af3badcc7..0cc047d2a8a1 100644 --- a/drivers/gpu/drm/bridge/tc358775.c +++ b/drivers/gpu/drm/bridge/tc358775.c @@ -429,7 +429,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge) val = TC358775_VPCTRL_MSF(1); dsiclk = mode->crtc_clock * 3 * tc->bpc / tc->num_dsi_lanes / 1000; - clkdiv = dsiclk / DIVIDE_BY_3 * tc->lvds_link; + clkdiv = dsiclk / (tc->lvds_link == DUAL_LINK ? DIVIDE_BY_6 : DIVIDE_BY_3); byteclk = dsiclk / 4; t1 = hactive * (tc->bpc * 3 / 8) / tc->num_dsi_lanes; t2 = ((10 / clkdiv)) * (hactive + hback_porch + hsync_len + hfront_porch) / 1000; -- 2.35.1
[PATCH AUTOSEL 5.18 41/93] amdgpu/pm: Fix possible array out-of-bounds if SCLK levels != 2
From: Darren Powell
[ Upstream commit ceb180361e3851007547c55035cd1de03f108f75 ]
[v2]
simplified fix after Lijo's feedback
removed clocks.num_levels from calculation of loop count
removed unsafe accesses to shim table freq_values
retained corner case output only min,now if
clocks.num_levels == 1 && now > min
[v1]
added a check to populate and use SCLK shim table freq_values only
if using dpm_level == AMD_DPM_FORCED_LEVEL_MANUAL or
AMD_DPM_FORCED_LEVEL_PERF_DETERMINISM
removed clocks.num_levels from calculation of shim table size
removed unsafe accesses to shim table freq_values
output gfx_table values if using other dpm levels
added check for freq_match when using freq_values for when now == min_clk
== Test ==
LOGFILE=aldebaran-sclk.test.log
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
lspci -nn | grep "VGA\|Display" > $LOGFILE
FILES="pp_od_clk_voltage
pp_dpm_sclk"
for f in $FILES
do
echo === $f === >> $LOGFILE
cat $HWMON_DIR/device/$f >> $LOGFILE
done
cat $LOGFILE
Signed-off-by: Darren Powell
Reviewed-by: Kenneth Feng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 34 +++
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index 7f998f24af81..b57750cb27c4 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
@@ -733,7 +733,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
struct smu_13_0_dpm_table *single_dpm_table;
struct smu_dpm_context *smu_dpm = &smu->smu_dpm;
struct smu_13_0_dpm_context *dpm_context = NULL;
- uint32_t display_levels;
+ int display_levels;
uint32_t freq_values[3] = {0};
uint32_t min_clk, max_clk;
@@ -765,7 +765,7 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
return ret;
}
- display_levels = clocks.num_levels;
+ display_levels = (clocks.num_levels == 1) ? 1 : 2;
min_clk = pstate_table->gfxclk_pstate.curr.min;
max_clk = pstate_table->gfxclk_pstate.curr.max;
@@ -775,30 +775,20 @@ static int aldebaran_print_clk_levels(struct smu_context
*smu,
/* fine-grained dpm has only 2 levels */
if (now > min_clk && now < max_clk) {
- display_levels = clocks.num_levels + 1;
+ display_levels++;
freq_values[2] = max_clk;
freq_values[1] = now;
}
- /*
-* For DPM disabled case, there will be only one clock level.
-* And it's safe to assume that is always the current clock.
-*/
- if (display_levels == clocks.num_levels) {
- for (i = 0; i < clocks.num_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i],
- (clocks.num_levels == 1) ?
- "*" :
- (aldebaran_freqs_in_same_level(
-freq_values[i], now) ?
-"*" :
-""));
- } else {
- for (i = 0; i < display_levels; i++)
- size += sysfs_emit_at(buf, size, "%d: %uMhz
%s\n", i,
- freq_values[i], i == 1 ? "*" :
"");
- }
+ for (i = 0; i < display_levels; i++)
+ size += sysfs_emit_at(buf, size, "%d: %uMhz %s\n", i,
+ freq_values[i],
+ (display_levels == 1) ?
+ "*" :
+ (aldebaran_freqs_in_same_level(
+freq_values[i], now) ?
+"*" :
+""));
break;
--
2.35.1
[PATCH AUTOSEL 5.18 47/93] drm/amdgpu/display/dc: Fix null pointer exception
From: Rahul Kumar [ Upstream commit 1c4dae3e4639540fb567e570cc56a3c292afb6fe ] We observed hard hang due to NULL derefrence This issue is seen after running system all the time after two or three days struct dc *dc = plane_state->ctx->dc; Randomly in long run we found plane_state or plane_state->ctx is found NULL which causes exception. BUG: kernel NULL pointer dereference, address: PF: supervisor read access in kernel mode PF: error_code(0x) - not-present page PGD 1dc7f2067 P4D 1dc7f2067 PUD 222c75067 PMD 0 Oops: [#1] SMP NOPTI CPU: 5 PID: 29855 Comm: kworker/u16:4 ... ... Workqueue: events_unbound commit_work [drm_kms_helper] RIP: 0010:dcn10_update_pending_status+0x1f/0xee [amdgpu] Code: 41 5f c3 0f 1f 44 00 00 b0 01 c3 0f 1f 44 00 00 41 55 41 54 55 53 48 8b 1f 4c 8b af f8 00 00 00 48 8b 83 88 03 00 00 48 85 db <4c> 8b 20 0f 84 bf 00 00 00 48 89 fd 48 8b bf b8 00 00 00 48 8b 07 RSP: 0018:942941997ab8 EFLAGS: 00010286 RAX: RBX: 8d7fd98d2000 RCX: RDX: RSI: 8d7e3e87c708 RDI: 8d7f2d8c0690 RBP: 8d7f2d8c R08: 942941997a34 R09: R10: 5000 R11: 00f0 R12: 8d7f2d8c0690 R13: 8d8035a41680 R14: 000186a0 R15: 8d7f2d8c1dd8 FS: () GS:8d803734() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 00014803 CR4: 003406e0 Call Trace: dc_commit_state+0x6a2/0x7f0 [amdgpu] amdgpu_dm_atomic_commit_tail+0x460/0x19bb [amdgpu] Tested-by: Rodrigo Siqueira Reviewed-by: Harry Wentland Signed-off-by: Rahul Kumar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index 83fbea2df410..b12a46c4e872 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3205,7 +3205,7 @@ void dcn10_update_pending_status(struct pipe_ctx *pipe_ctx) struct dc_plane_state *plane_state = pipe_ctx->plane_state; struct timing_generator *tg = pipe_ctx->stream_res.tg; bool flip_pending; - struct dc *dc = plane_state->ctx->dc; + struct dc *dc = pipe_ctx->stream->ctx->dc; if (plane_state == NULL) return; -- 2.35.1
[PATCH AUTOSEL 5.18 51/93] drm/amdgpu: skip whole ras bad page framework on sriov
From: "Stanley.Yang" [ Upstream commit e0e146d5567317d6ba7d0169bed55d1d9ea05a61 ] It should not init whole ras bad page framework on sriov guest side due to it is handled on host side. Signed-off-by: Stanley.Yang Reviewed-by: Hawking Zhang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index 3f96dadf2698..7506b0b9c2cb 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -2062,7 +2062,7 @@ int amdgpu_ras_recovery_init(struct amdgpu_device *adev) bool exc_err_limit = false; int ret; - if (!con) + if (!con || amdgpu_sriov_vf(adev)) return 0; /* Allow access to RAS EEPROM via debugfs, when the ASIC -- 2.35.1
[PATCH AUTOSEL 5.18 52/93] drm/amd/display: Guard against ddc_pin being NULL for AUX
From: Nicholas Kazlauskas
[ Upstream commit bc19909f19fdc8253d720d11c948935786fbfa08 ]
[Why]
In the case where we don't support DMUB aux but we have DPIA links
in the configuration we might try to message AUX using the legacy
path - where DDC pin is NULL. This causes a NULL pointer dereference.
[How]
Guard against NULL DDC pin, return a failure for aux engine acquire.
Reviewed-by: Michael Strauss
Acked-by: Rodrigo Siqueira
Signed-off-by: Nicholas Kazlauskas
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
index 8e814000db62..5620a3345e4d 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
@@ -573,6 +573,11 @@ int dce_aux_transfer_raw(struct ddc_service *ddc,
memset(&aux_req, 0, sizeof(aux_req));
memset(&aux_rep, 0, sizeof(aux_rep));
+ if (ddc_pin == NULL) {
+ *operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
+ return -1;
+ }
+
aux_engine = ddc->ctx->dc->res_pool->engines[ddc_pin->pin_data->en];
if (!acquire(aux_engine, ddc_pin)) {
*operation_result = AUX_RET_ERROR_ENGINE_ACQUIRE;
--
2.35.1
[PATCH AUTOSEL 5.18 53/93] drm/amd/display: Fix dmub soft hang for PSR 1
From: Fangzhi Zuo [ Upstream commit 22676bc500c27d987a0b42cbe162aebf783f1c38 ] [Why] Unexpected change of aux hw mapping causes dmub soft hang when initiate aux transation at wrong aux channel. ddc_channel stands for hw dp aux index which is from vbios, but link_index is pure software concept for link count depending on which link is probed first. They are not interchangeable. dmub aux transaction could pass if happens eDP link_index gets the same value as vbios ddc_channel, e.g., ddc_channel = 1, link_index = 1 if they gets different, e.g., ddc_channel = 2, link_index = 0, overwrite ddc_channel with link_index will have wrong ddc channel being used for aux transaction in dmub PSR, cause aux transaction soft hang. [How] ddc_channel mapping to each link is determined by vbios and further parsed in dc. Such info. should not be touched in any kind, otherwise the mapping is screwed up leading to aux transaction timeout. Reviewed-by: Aurabindo Jayamohanan Pillai Acked-by: Rodrigo Siqueira Signed-off-by: Fangzhi Zuo Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index a2575195c4e0..1991a8a4826e 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8563,7 +8563,7 @@ static int amdgpu_dm_i2c_xfer(struct i2c_adapter *i2c_adap, if (dc_submit_i2c( ddc_service->ctx->dc, - ddc_service->ddc_pin->hw_info.ddc_channel, + ddc_service->link->link_index, &cmd)) result = num; @@ -8599,8 +8599,6 @@ create_i2c(struct ddc_service *ddc_service, snprintf(i2c->base.name, sizeof(i2c->base.name), "AMDGPU DM i2c hw bus %d", link_index); i2c_set_adapdata(&i2c->base, i2c); i2c->ddc_service = ddc_service; - if (i2c->ddc_service->ddc_pin) - i2c->ddc_service->ddc_pin->hw_info.ddc_channel = link_index; return i2c; } -- 2.35.1
[PATCH AUTOSEL 5.18 54/93] drm/amd/display: disable otg toggle w/a on boot
From: Dmytro Laktyushkin
[ Upstream commit 8a077d9caa3a274de36ee2fe7b608041f5690343 ]
This w/a has a bad interaction with seamless boot toggling an
active stream. Most panels recover, however some fail leading
to display corruption.
Reviewed-by: Charlene Liu
Acked-by: Rodrigo Siqueira
Signed-off-by: Dmytro Laktyushkin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
index 2918ad07d489..8f8680e89a8f 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
@@ -173,11 +173,14 @@ static void dcn315_update_clocks(struct clk_mgr
*clk_mgr_base,
}
if (should_set_clock(safe_to_lower, new_clocks->dispclk_khz,
clk_mgr_base->clks.dispclk_khz)) {
- dcn315_disable_otg_wa(clk_mgr_base, true);
+ /* No need to apply the w/a if we haven't taken over from bios
yet */
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, true);
clk_mgr_base->clks.dispclk_khz = new_clocks->dispclk_khz;
dcn315_smu_set_dispclk(clk_mgr, clk_mgr_base->clks.dispclk_khz);
- dcn315_disable_otg_wa(clk_mgr_base, false);
+ if (clk_mgr_base->clks.dispclk_khz)
+ dcn315_disable_otg_wa(clk_mgr_base, false);
update_dispclk = true;
}
--
2.35.1
[PATCH AUTOSEL 5.18 56/93] drm/msm/gem: Drop obj lock in msm_gem_free_object()
From: Rob Clark
[ Upstream commit a414fe3a2129b490e1e9b8ad66f0364f4f961887 ]
The only reason we grabbed the lock was to satisfy a bunch of places
that WARN_ON() if called without the lock held. But this angers lockdep
which doesn't realize no one else can be holding the lock by the time we
end up destroying the object (and sees what would otherwise be a locking
inversion between reservation_ww_class_mutex and fs_reclaim).
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/14
Signed-off-by: Rob Clark
Patchwork: https://patchwork.freedesktop.org/patch/489364/
Link: https://lore.kernel.org/r/20220613205032.2652374-1-robdcl...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 8
drivers/gpu/drm/msm/msm_gem.h | 14 +-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index a4f61972667b..59d5f327047e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -991,8 +991,6 @@ void msm_gem_free_object(struct drm_gem_object *obj)
list_del(&msm_obj->mm_list);
mutex_unlock(&priv->mm_lock);
- msm_gem_lock(obj);
-
/* object should not be on active list: */
GEM_WARN_ON(is_active(msm_obj));
@@ -1008,17 +1006,11 @@ void msm_gem_free_object(struct drm_gem_object *obj)
put_iova_vmas(obj);
- /* dma_buf_detach() grabs resv lock, so we need to unlock
-* prior to drm_prime_gem_destroy
-*/
- msm_gem_unlock(obj);
-
drm_prime_gem_destroy(obj, msm_obj->sgt);
} else {
msm_gem_vunmap(obj);
put_pages(obj);
put_iova_vmas(obj);
- msm_gem_unlock(obj);
}
drm_gem_object_release(obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index af612add5264..f62855134660 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -196,7 +196,19 @@ msm_gem_unlock(struct drm_gem_object *obj)
static inline bool
msm_gem_is_locked(struct drm_gem_object *obj)
{
- return dma_resv_is_locked(obj->resv);
+ /*
+* Destroying the object is a special case.. msm_gem_free_object()
+* calls many things that WARN_ON if the obj lock is not held. But
+* acquiring the obj lock in msm_gem_free_object() can cause a
+* locking order inversion between reservation_ww_class_mutex and
+* fs_reclaim.
+*
+* This deadlock is not actually possible, because no one should
+* be already holding the lock when msm_gem_free_object() is called.
+* Unfortunately lockdep is not aware of this detail. So when the
+* refcount drops to zero, we pretend it is already locked.
+*/
+ return dma_resv_is_locked(obj->resv) || (kref_read(&obj->refcount) ==
0);
}
static inline bool is_active(struct msm_gem_object *msm_obj)
--
2.35.1
[PATCH AUTOSEL 5.18 62/93] drm/nouveau/nvkm: use list_add_tail() when building object tree
From: Ben Skeggs
[ Upstream commit 61c1f340bc809a1ca1e3c8794207a91cde1a7c78 ]
Fixes resume from hibernate failing on (at least) TU102, where cursor
channel init failed due to being performed before the core channel.
Not solid idea why suspend-to-ram worked, but, presumably HW being in
an entirely clean state has something to do with it.
Signed-off-by: Ben Skeggs
Reviewed-by: Dave Airlie
Signed-off-by: Dave Airlie
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/core/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
index 735cb6816f10..06b2f675f5da 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/ioctl.c
@@ -128,7 +128,7 @@ nvkm_ioctl_new(struct nvkm_client *client,
if (ret == 0) {
ret = nvkm_object_init(object);
if (ret == 0) {
- list_add(&object->head, &parent->tree);
+ list_add_tail(&object->head, &parent->tree);
if (nvkm_object_insert(object)) {
client->data = object;
return 0;
--
2.35.1
[PATCH AUTOSEL 5.18 63/93] drm/amdgpu: fix file permissions on some files
From: Alex Deucher [ Upstream commit 0a94608f0f7de9b1135ffea3546afe68eafef57f ] Drop execute. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2085 Reviewed-by: Guchun Chen Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h| 0 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h | 0 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h | 0 6 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h mode change 100755 => 100644 drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/clk/clk_11_0_1_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_2_0_3_sh_mask.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_offset.h old mode 100755 new mode 100644 diff --git a/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/dpcs/dpcs_2_0_3_sh_mask.h old mode 100755 new mode 100644 -- 2.35.1
[PATCH AUTOSEL 5.18 67/93] drm/amdgpu: Call trace info was found in dmesg when loading amdgpu
From: lin cao
[ Upstream commit 748262eb400e809aa13e3485f4983c3db3d0ebb3 ]
In the case of SRIOV, the register smnMp1_PMI_3_FIFO will get an invalid
value which will cause the "shift out of bound". In Ubuntu22.04, this
issue will be checked an related call trace will be reported in dmesg.
Signed-off-by: lin cao
Reviewed-by: Jingwen Chen
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 7a1e225fb823..971a9712fa63 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -758,6 +758,7 @@ static void sienna_cichlid_stb_init(struct smu_context
*smu);
static int sienna_cichlid_init_smc_tables(struct smu_context *smu)
{
+ struct amdgpu_device *adev = smu->adev;
int ret = 0;
ret = sienna_cichlid_tables_init(smu);
@@ -768,7 +769,8 @@ static int sienna_cichlid_init_smc_tables(struct
smu_context *smu)
if (ret)
return ret;
- sienna_cichlid_stb_init(smu);
+ if (!amdgpu_sriov_vf(adev))
+ sienna_cichlid_stb_init(smu);
return smu_v11_0_init_smc_tables(smu);
}
--
2.35.1
[PATCH AUTOSEL 5.18 83/93] drm/amdkfd: Process notifier release callback don't take mutex
From: Philip Yang
[ Upstream commit 74097f9fd2f5ebdae04fcba59da345386415cbf3 ]
Move process queues cleanup to deferred work kfd_process_wq_release, to
avoid potential deadlock circular locking warning:
WARNING: possible circular locking dependency detected
the existing dependency chain (in reverse order) is:
-> #2
((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}:
__flush_work+0x343/0x4a0
svm_range_list_lock_and_flush_work+0x39/0xc0
svm_range_set_attr+0xe8/0x1080 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #1 (&info->lock#2){+.+.}-{3:3}:
__mutex_lock+0xa4/0x940
amdgpu_amdkfd_gpuvm_acquire_process_vm+0x2e3/0x590
kfd_process_device_init_vm+0x61/0x200 [amdgpu]
kfd_ioctl_acquire_vm+0x83/0xb0 [amdgpu]
kfd_ioctl+0x19b/0x600 [amdgpu]
__x64_sys_ioctl+0x81/0xb0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #0 (&process->mutex){+.+.}-{3:3}:
__lock_acquire+0x1365/0x23d0
lock_acquire+0xc9/0x2e0
__mutex_lock+0xa4/0x940
kfd_process_notifier_release+0x96/0xe0 [amdgpu]
__mmu_notifier_release+0x94/0x210
exit_mmap+0x35/0x1f0
mmput+0x63/0x120
svm_range_deferred_list_work+0x177/0x2c0 [amdgpu]
process_one_work+0x2a4/0x600
worker_thread+0x39/0x3e0
kthread+0x16d/0x1a0
Possible unsafe locking scenario:
CPU0CPU1
lock((work_completion)(&svms->deferred_list_work));
lock(&info->lock#2);
lock((work_completion)(&svms->deferred_list_work));
lock(&process->mutex);
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 19d4089a0b1c..3f2383db1b73 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -,6 +,15 @@ static void kfd_process_wq_release(struct work_struct
*work)
struct kfd_process *p = container_of(work, struct kfd_process,
release_work);
+ kfd_process_dequeue_from_all_devices(p);
+ pqm_uninit(&p->pqm);
+
+ /* Signal the eviction fence after user mode queues are
+* destroyed. This allows any BOs to be freed without
+* triggering pointless evictions or waiting for fences.
+*/
+ dma_fence_signal(p->ef);
+
kfd_process_remove_sysfs(p);
kfd_iommu_unbind_process(p);
@@ -1175,20 +1184,8 @@ static void kfd_process_notifier_release(struct
mmu_notifier *mn,
cancel_delayed_work_sync(&p->eviction_work);
cancel_delayed_work_sync(&p->restore_work);
- mutex_lock(&p->mutex);
-
- kfd_process_dequeue_from_all_devices(p);
- pqm_uninit(&p->pqm);
-
/* Indicate to other users that MM is no longer valid */
p->mm = NULL;
- /* Signal the eviction fence after user mode queues are
-* destroyed. This allows any BOs to be freed without
-* triggering pointless evictions or waiting for fences.
-*/
- dma_fence_signal(p->ef);
-
- mutex_unlock(&p->mutex);
mmu_notifier_put(&p->mmu_notifier);
}
--
2.35.1
[PATCH AUTOSEL 5.18 82/93] drm/amdkfd: Correct mmu_notifier_get failure handling
From: Philip Yang [ Upstream commit 0593ad215359d51514c1e6c81ce28ea598efed6b ] If process has signal pending, mmu_notifier_get_locked fails and calls ops->free_notifier, kfd_process_free_notifier will schedule kfd_process_wq_release as process refcount is 1, but process structure is already freed. This use after free bug causes system crash with different backtrace. The fix is to increase process refcount and then decrease the refcount after mmu_notifier_get success. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 59c04b2d383b..19d4089a0b1c 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -1397,6 +1397,11 @@ static struct kfd_process *create_process(const struct task_struct *thread) hash_add_rcu(kfd_processes_table, &process->kfd_processes, (uintptr_t)process->mm); + /* Avoid free_notifier to start kfd_process_wq_release if +* mmu_notifier_get failed because of pending signal. +*/ + kref_get(&process->ref); + /* MMU notifier registration must be the last call that can fail * because after this point we cannot unwind the process creation. * After this point, mmu_notifier_put will trigger the cleanup by @@ -1409,6 +1414,7 @@ static struct kfd_process *create_process(const struct task_struct *thread) } BUG_ON(mn != &process->mmu_notifier); + kfd_unref_process(process); get_task_struct(process->lead_thread); return process; -- 2.35.1
[PATCH AUTOSEL 5.15 01/69] fbdev: Restart conflicting fb removal loop when unregistering devices
From: Javier Martinez Canillas
[ Upstream commit 3367aa7d74d240261de2543ddb35531ccad9d884 ]
Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, call to remove_conflicting_framebuffers().
This function takes the registration_lock mutex, to prevent a race when
drivers register framebuffer devices. But if a conflicting framebuffer
device is found, the underlaying platform device is unregistered and this
will lead to the platform driver .remove callback to be called. Which in
turn will call to unregister_framebuffer() that takes the same lock.
To prevent this, a struct fb_info.forced_out field was used as indication
to unregister_framebuffer() whether the mutex has to be grabbed or not.
But this could be unsafe, since the fbdev core is making assumptions about
what drivers may or may not do in their .remove callbacks. Allowing to run
these callbacks with the registration_lock held can cause deadlocks, since
the fbdev core has no control over what drivers do in their removal path.
A better solution is to drop the lock before platform_device_unregister(),
so unregister_framebuffer() can take it when called from the fbdev driver.
The lock is acquired again after the device has been unregistered and at
this point the removal loop can be restarted.
Since the conflicting framebuffer device has already been removed, the
loop would just finish when no more conflicting framebuffers are found.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/2022053039.1252432-1-javi...@redhat.com
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbmem.c | 22 +++---
include/linux/fb.h | 1 -
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 528c87ff14d8..619d82e20d4e 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1568,6 +1568,7 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
{
int i;
+restart_removal:
/* check all firmware fbs and kick off if the base addr overlaps */
for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
@@ -1602,12 +1603,23 @@ static void do_remove_conflicting_framebuffers(struct
apertures_struct *a,
*/
do_unregister_framebuffer(registered_fb[i]);
} else if (dev_is_platform(device)) {
- registered_fb[i]->forced_out = true;
+ /*
+* Drop the lock because if the device is
unregistered, its
+* driver will call to
unregister_framebuffer(), that takes
+* this lock.
+*/
+ mutex_unlock(®istration_lock);
platform_device_unregister(to_platform_device(device));
+ mutex_lock(®istration_lock);
} else {
pr_warn("fb%d: cannot remove device\n", i);
do_unregister_framebuffer(registered_fb[i]);
}
+ /*
+* Restart the removal loop now that the device has been
+* unregistered and its associated framebuffer gone.
+*/
+ goto restart_removal;
}
}
}
@@ -1945,13 +1957,9 @@ EXPORT_SYMBOL(register_framebuffer);
void
unregister_framebuffer(struct fb_info *fb_info)
{
- bool forced_out = fb_info->forced_out;
-
- if (!forced_out)
- mutex_lock(®istration_lock);
+ mutex_lock(®istration_lock);
do_unregister_framebuffer(fb_info);
- if (!forced_out)
- mutex_unlock(®istration_lock);
+ mutex_unlock(®istration_lock);
}
EXPORT_SYMBOL(unregister_framebuffer);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3d7306c9a706..02f362c661c8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -502,7 +502,6 @@ struct fb_info {
} *apertures;
bool skip_vt_switch; /* no VT switch on suspend/resume required */
- bool forced_out; /* set when being removed by another driver */
};
static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
--
2.35.1
[PATCH AUTOSEL 5.15 02/69] drm/r128: Fix undefined behavior due to shift overflowing the constant
From: Borislav Petkov [ Upstream commit 6556551f8848f98eff356c8aacae42c8dd65b2df ] Fix: drivers/gpu/drm/r128/r128_cce.c: In function ‘r128_do_init_cce’: drivers/gpu/drm/r128/r128_cce.c:417:2: error: case label does not reduce to an integer constant case R128_PM4_64BM_64VCBM_64INDBM: ^~~~ drivers/gpu/drm/r128/r128_cce.c:418:2: error: case label does not reduce to an integer constant case R128_PM4_64PIO_64VCPIO_64INDPIO: ^~~~ See https://lore.kernel.org/r/ykwq6%2btih8gqp...@zn.tnic for the gory details as to why it triggers with older gccs only. Reviewed-by: Randy Dunlap Signed-off-by: Borislav Petkov Cc: David Airlie Cc: Daniel Vetter Cc: Alex Deucher Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220405151517.29753-5...@alien8.de Signed-off-by: Sasha Levin --- drivers/gpu/drm/r128/r128_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h index 2e1bc01aa5c9..970e192b0d51 100644 --- a/drivers/gpu/drm/r128/r128_drv.h +++ b/drivers/gpu/drm/r128/r128_drv.h @@ -300,8 +300,8 @@ extern long r128_compat_ioctl(struct file *filp, unsigned int cmd, # define R128_PM4_64PIO_128INDBM (5 << 28) # define R128_PM4_64BM_128INDBM (6 << 28) # define R128_PM4_64PIO_64VCBM_64INDBM(7 << 28) -# define R128_PM4_64BM_64VCBM_64INDBM (8 << 28) -# define R128_PM4_64PIO_64VCPIO_64INDPIO (15 << 28) +# define R128_PM4_64BM_64VCBM_64INDBM (8U << 28) +# define R128_PM4_64PIO_64VCPIO_64INDPIO (15U << 28) # define R128_PM4_BUFFER_CNTL_NOUPDATE(1 << 27) #define R128_PM4_BUFFER_WM_CNTL0x0708 -- 2.35.1
[PATCH AUTOSEL 5.15 05/69] drm/nouveau: clear output poll workers before nouveau_fbcon_destroy()
From: Mark Menzynski [ Upstream commit 6b03816f869529393b37d03e5d75b68f7365a7a4 ] Resources needed for output poll workers are destroyed in nouveau_fbcon_fini() before output poll workers are cleared in nouveau_display_fini(). This means there is a time between fbcon_fini() and display_fini(), where if output poll happens, it crashes. This patch introduces another output poll clearing before fbcon resources are destroyed. BUG: KASAN: use-after-free in __drm_fb_helper_initial_config_and_unlock.cold+0x1f3/0x291 [drm_kms_helper] Cc: Ben Skeggs Cc: Karol Herbst Cc: Lyude Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Mark Menzynski Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220523113541.10562-1-mmenz...@redhat.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 4f9b3aa5deda..5226323e55d3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -39,6 +39,7 @@ #include #include +#include #include #include #include @@ -605,6 +606,7 @@ nouveau_fbcon_fini(struct drm_device *dev) if (!drm->fbcon) return; + drm_kms_helper_poll_fini(dev); nouveau_fbcon_accel_fini(dev); nouveau_fbcon_destroy(dev, drm->fbcon); kfree(drm->fbcon); -- 2.35.1
[PATCH AUTOSEL 5.15 07/69] drm/panfrost: Don't set L2_MMU_CONFIG quirks
From: Alyssa Rosenzweig [ Upstream commit d8e53d8a4e0ae842ef5e83e0dfb0796980f710cf ] L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs define slightly different MAX_READS and MAX_WRITES fields, which throttle outstanding reads and writes when set to non-zero values. When left as zero, reads and writes are not throttled. Both kbase and panfrost always zero these registers. Per discussion with Steven Price, there are two reasons these quirks may be used: 1. Simulating slower memory subsystems. This use case is only of interest to system-on-chip designers; it is not relevant to mainline. 2. Working around broken memory subsystems. Hopefully we never see this case in mainline. If we do, we'll need to set this register based on an SoC-compatible, rather than generally matching on the GPU model. To the best of our knowledge, these fields are zero at reset, so the write is not necessary. Let's remove the write to aid porting to new Mali GPUs, which have different layouts for the L2_MMU_CONFIG register. Suggested-by: Steven Price Reviewed-by: Steven Price Signed-off-by: Alyssa Rosenzweig Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-8-alyssa.rosenzw...@collabora.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/panfrost/panfrost_gpu.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c b/drivers/gpu/drm/panfrost/panfrost_gpu.c index a3cdf3e86ef3..7e5b2025cd42 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c @@ -127,18 +127,6 @@ static void panfrost_gpu_init_quirks(struct panfrost_device *pfdev) gpu_write(pfdev, GPU_TILER_CONFIG, quirks); - quirks = gpu_read(pfdev, GPU_L2_MMU_CONFIG); - - /* Limit read & write ID width for AXI */ - if (panfrost_has_hw_feature(pfdev, HW_FEATURE_3BIT_EXT_RW_L2_MMU_CONFIG)) - quirks &= ~(L2_MMU_CONFIG_3BIT_LIMIT_EXTERNAL_READS | - L2_MMU_CONFIG_3BIT_LIMIT_EXTERNAL_WRITES); - else - quirks &= ~(L2_MMU_CONFIG_LIMIT_EXTERNAL_READS | - L2_MMU_CONFIG_LIMIT_EXTERNAL_WRITES); - - gpu_write(pfdev, GPU_L2_MMU_CONFIG, quirks); - quirks = 0; if ((panfrost_model_eq(pfdev, 0x860) || panfrost_model_eq(pfdev, 0x880)) && pfdev->features.revision >= 0x2000) -- 2.35.1
[PATCH AUTOSEL 5.15 06/69] drm/panfrost: Handle HW_ISSUE_TTRX_2968_TTRX_3162
From: Alyssa Rosenzweig
[ Upstream commit 382435709516c1a7dc3843872792abf95e786c83 ]
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Reviewed-by: Steven Price
Signed-off-by: Alyssa Rosenzweig
Link:
https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-3-alyssa.rosenzw...@collabora.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_regs.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f8355de6e335..a3cdf3e86ef3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -108,6 +108,9 @@ static void panfrost_gpu_init_quirks(struct panfrost_device
*pfdev)
quirks |= SC_LS_ALLOW_ATTR_TYPES;
}
+ if (panfrost_has_hw_issue(pfdev, HW_ISSUE_TTRX_2968_TTRX_3162))
+ quirks |= SC_VAR_ALGORITHM;
+
if (panfrost_has_hw_feature(pfdev, HW_FEATURE_TLS_HASHING))
quirks |= SC_TLS_HASH_ENABLE;
diff --git a/drivers/gpu/drm/panfrost/panfrost_issues.h
b/drivers/gpu/drm/panfrost/panfrost_issues.h
index 8e59d765bf19..3af7d723377e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_issues.h
+++ b/drivers/gpu/drm/panfrost/panfrost_issues.h
@@ -125,6 +125,9 @@ enum panfrost_hw_issue {
* kernel must fiddle with L2 caches to prevent data leakage */
HW_ISSUE_TGOX_R1_1234,
+ /* Must set SC_VAR_ALGORITHM */
+ HW_ISSUE_TTRX_2968_TTRX_3162,
+
HW_ISSUE_END
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 6c5a11ef1ee8..28f5aae58d9c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -195,6 +195,7 @@
#define SC_TLS_HASH_ENABLE BIT(17)
#define SC_LS_ATTR_CHECK_DISABLE BIT(18)
#define SC_ENABLE_TEXGRD_FLAGS BIT(25)
+#define SC_VAR_ALGORITHM BIT(29)
/* End SHADER_CONFIG register */
/* TILER_CONFIG register */
--
2.35.1
[PATCH AUTOSEL 5.15 08/69] drm/panfrost: Add arm, mali-valhall-jm compatible
From: Alyssa Rosenzweig
[ Upstream commit 952cd974509251d6b5074bc3677b8297826a6ef1 ]
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
v2: Use arm,mali-valhall-jm compatible.
Reviewed-by: Steven Price
Signed-off-by: Alyssa Rosenzweig
Link:
https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-10-alyssa.rosenzw...@collabora.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index de533f372764..344f619508fe 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -654,6 +654,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t860", .data = &default_data, },
{ .compatible = "arm,mali-t880", .data = &default_data, },
{ .compatible = "arm,mali-bifrost", .data = &default_data, },
+ { .compatible = "arm,mali-valhall-jm", .data = &default_data, },
{ .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
{}
};
--
2.35.1
[PATCH AUTOSEL 5.15 11/69] drm/amd/display: fix system hang when PSR exits
From: David Zhang
[ Upstream commit 6cc5c77300afbb285c4f41e04f3435ae3c484c40 ]
[why]
When DC driver send PSR exit dmub command to DMUB FW, it might not
wait until PSR exit. Then it may hit the following deadlock situation.
1. DC driver send HW LOCK command to DMUB FW due to frame update
2. DMUB FW Set the HW lock
3. DMUB execute PSR exit sequence and stuck at polling DPG Pending
register due to the HW Lock is set
4. DC driver ask DMUB FW to unlock HW lock, but DMUB FW is polling
DPG pending register
[how]
The reason why DC driver doesn't wait until PSR exit is because some of
the PSR state machine state is not update the dc driver. So when DC
driver read back the PSR state, it take the state for PSR inactive.
Signed-off-by: David Zhang
Acked-by: Leo Li
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dc_types.h | 7 +++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 16
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index c1532930169b..ac8442f6f4da 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -639,10 +639,17 @@ enum dc_psr_state {
PSR_STATE4b,
PSR_STATE4c,
PSR_STATE4d,
+ PSR_STATE4_FULL_FRAME,
+ PSR_STATE4a_FULL_FRAME,
+ PSR_STATE4b_FULL_FRAME,
+ PSR_STATE4c_FULL_FRAME,
+ PSR_STATE4_FULL_FRAME_POWERUP,
PSR_STATE5,
PSR_STATE5a,
PSR_STATE5b,
PSR_STATE5c,
+ PSR_STATE_HWLOCK_MGR,
+ PSR_STATE_POLLVUPDATE,
PSR_STATE_INVALID = 0xFF
};
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
index aa8403bc4c83..0dac025f8f02 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
@@ -72,6 +72,22 @@ static enum dc_psr_state convert_psr_state(uint32_t
raw_state)
state = PSR_STATE5b;
else if (raw_state == 0x53)
state = PSR_STATE5c;
+ else if (raw_state == 0x4A)
+ state = PSR_STATE4_FULL_FRAME;
+ else if (raw_state == 0x4B)
+ state = PSR_STATE4a_FULL_FRAME;
+ else if (raw_state == 0x4C)
+ state = PSR_STATE4b_FULL_FRAME;
+ else if (raw_state == 0x4D)
+ state = PSR_STATE4c_FULL_FRAME;
+ else if (raw_state == 0x4E)
+ state = PSR_STATE4_FULL_FRAME_POWERUP;
+ else if (raw_state == 0x60)
+ state = PSR_STATE_HWLOCK_MGR;
+ else if (raw_state == 0x61)
+ state = PSR_STATE_POLLVUPDATE;
+ else
+ state = PSR_STATE_INVALID;
return state;
}
--
2.35.1
[PATCH AUTOSEL 5.15 12/69] drm/amd/display: Detect dpcd_rev when hotplug mst monitor
From: Wayne Lin
[ Upstream commit 453b0016a054df0f442fda8a145b97a33816cab9 ]
[Why]
Once mst topology is constructed, later on new connected monitors
are reported to source by CSN message. Within CSN, there is no
carried info of DPCD_REV comparing to LINK_ADDRESS reply. As the
result, we might leave some ports connected to DP but without DPCD
revision number which will affect us determining the capability of
the DP Rx.
[How]
Send out remote DPCD read when the port's dpcd_rev is 0x0 in
detect_ctx(). Firstly, read out the value from DPCD 0x2200. If the
return value is 0x0, it's likely the DP1.2 DP Rx then we reques
revision from DPCD 0x0 again.
Reviewed-by: Hersen Wu
Acked-by: Hamza Mahfooz
Signed-off-by: Wayne Lin
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 652cf108b3c2..424f4cfc0e04 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -335,12 +335,48 @@ dm_dp_mst_detect(struct drm_connector *connector,
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
struct amdgpu_dm_connector *master = aconnector->mst_port;
+ struct drm_dp_mst_port *port = aconnector->port;
+ int connection_status;
if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, ctx, &master->mst_mgr,
+ connection_status = drm_dp_mst_detect_port(connector, ctx,
&master->mst_mgr,
aconnector->port);
+
+ if (port->pdt != DP_PEER_DEVICE_NONE && !port->dpcd_rev) {
+ uint8_t dpcd_rev;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&port->aux, DP_DP13_DPCD_REV,
&dpcd_rev);
+
+ if (ret == 1) {
+ port->dpcd_rev = dpcd_rev;
+
+ /* Could be DP1.2 DP Rx case*/
+ if (!dpcd_rev) {
+ ret = drm_dp_dpcd_readb(&port->aux,
DP_DPCD_REV, &dpcd_rev);
+
+ if (ret == 1)
+ port->dpcd_rev = dpcd_rev;
+ }
+
+ if (!dpcd_rev)
+ DRM_DEBUG_KMS("Can't decide DPCD revision
number!");
+ }
+
+ /*
+* Could be legacy sink, logical port etc on DP1.2.
+* Will get Nack under these cases when issue remote
+* DPCD read.
+*/
+ if (ret != 1)
+ DRM_DEBUG_KMS("Can't access DPCD");
+ } else if (port->pdt == DP_PEER_DEVICE_NONE) {
+ port->dpcd_rev = 0;
+ }
+
+ return connection_status;
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
--
2.35.1
[PATCH AUTOSEL 5.15 13/69] drm/probe-helper: Default to 640x480 if no EDID on DP
From: Douglas Anderson
[ Upstream commit fae7d186403ee5a9375ec75938e0de99718e066a ]
If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. Since we have no true information about the connected
display, these modes are essentially guesses but better than nothing.
At the moment, none of the modes returned is marked as preferred, but
the modes are sorted such that the higher resolution modes are listed
first.
When userspace sees these modes presented by the kernel it needs to
figure out which one to pick. At least one userspace, ChromeOS [1]
seems to use the rules (which seem pretty reasonable):
1. Try to pick the first mode marked as preferred.
2. Try to pick the mode which matches the first detailed timing
descriptor in the EDID.
3. If no modes were marked as preferred then pick the first mode.
Unfortunately, userspace's rules combined with what the kernel is
doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of
the DP 1.4a Link CTS. That test case says that, while it's OK to allow
some implementation-specific fall-back modes if the EDID is bad that
userspace should _default_ to 640x480.
Let's fix this by marking 640x480 as default for DP in the no-EDID
case.
NOTES:
- In the discussion around v3 of this patch [2] there was talk about
solving this in userspace and I even implemented a patch that would
have solved this for ChromeOS, but then the discussion turned back
to solving this in the kernel.
- Also in the discussion of v3 [2] it was requested to limit this
change to just DP since folks were worried that it would break some
subtle corner case on VGA or HDMI.
[1]
https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488
[2]
https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
Signed-off-by: Douglas Anderson
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Acked-by: Jani Nikula
Reviewed-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_probe_helper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 5606bca3caa8..86a5be9a5b17 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -516,8 +516,17 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
count = drm_add_override_edid_modes(connector);
if (count == 0 && (connector->status == connector_status_connected ||
- connector->status == connector_status_unknown))
+ connector->status == connector_status_unknown)) {
count = drm_add_modes_noedid(connector, 1024, 768);
+
+ /*
+* Section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a
+* Link CTS specifies that 640x480 (the official "failsafe"
+* mode) needs to be the default if there's no EDID.
+*/
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+ drm_set_preferred_mode(connector, 640, 480);
+ }
count += drm_helper_probe_add_cmdline_mode(connector);
if (count == 0)
goto prune;
--
2.35.1
